Best posts made by RayCulp

I would like to contribute to the documentation and have a few questions.

• There are a number of open issues in the Github repo for the documentation. If there are no objections, I would suggest beginning with these: evaluating them to see if they are still relevant, closing the ones that are not immediately, and making updates / creating new content for the ones that still are. Who would be the right person to coordinate with, i.e. who is in charge of the documentation?
• The move from UT 16.04 to 20.04 may have rendered some sections of the existing documentation outdated. Will UT 16.04 continue to exist alongside UT 20.04? If so, might it be a good idea to preserve the existing documentation as it is, create a copy, and update the copy / create new content to reflect the current functionality of UT 20.04?

I have solved the problem and will post a detailed guide on how to set up automated Syncevolution sychronization of contacts with Nextcloud (CardDav) using a systemd service and timer in the next few days.

@mrt10001 said in Does Ubuntu Touch actually replace Android or does it somehow run on top of it?:

unless its' Apple or Google, most users are not interested

To be perfectly honest, if the choice were between Apple and Google, I would choose not to have a smartphone at all. I'm absolutely serious about that.

@kristatos said in Few thoughts regarding coming back after several years:

I don't understand why people want to change from iOS/Android to UT but on the other hand still want to use all their services. In my opinion one effort of UT is, that you don't have to use accounts and services from these big companies and still have a functional and free phone in your hand.

I agree. Big Tech surveils you 24/7, exploits your most private data, and tries to control what information you have access to. I am so not down for that. If the only choice was Apple or Android, I would not have a smart phone.

UPDATE

I just discovered that if I reset the system (basically what amounts to a "factory reset"), the Camera app comes back. The Barcode Reader app is also back, but now when I start it the first time, it asks permission to use the camera. Maybe I had given the app permission to use the camera a long time ago and forgotten about it. Nevertheless, my original question still stands.

Short version:

Is it possible to do a "fresh install" of UT 20 over UT 16 using the UBports Installer, without first flashing Android back onto the phone?

Long version:

I updated my Google Pixel 3a XL from 16.04 to 20.04 a few days ago without starting over fresh, and at first everything seemed to be working fine.

Then I noticed that some apps were marked as "not found in the Open Store", so I decided to re-install all apps just to make sure.

One of the apps I uninstalled was the Camera app. I mainly decided to do this is because I saw a Barcode Reader app in the list of installed app, but every time I tried to start it, the Camera app would start instead, so I figured something was not working right.

Now I can't re-install the Camera app. Every time I try, it gets about half-way, then rolls back.

Instead of trying to repair the existing installation, I think now might be the right time to start over with a fresh install.

So the question is: Is it possible to do a "fresh install" of UT 20 over UT 16 using the UBports Installer, without first flashing Android back onto the phone?

@moem Yay! It works! Thanks!

@Keneda said in Possible to install UT 20 over UT 16 on Google Pixel 3a XL using UBports Installer without first flashing Android back onto the phone?:

If the android version needed for a device to run UT 20.04 is the same than for UT 16.04, i guess it's a yes.

Thank you for this info, but it actually resurrects an old question of mine from a long time ago: When I install UT, do I need to be concerned that there is some vestige of Android left on the phone that might spy on me, i.e. does UT somehow run on top of Android? The answer I received back then was "no",

However, if UT replaces Android completely, then how does the version of Android needed to install UT 16 vs. 20 on a phone that is not yet running UT affect whether I can install it on a phone that already is running UT, unless there is some remnant of that previous Android OS still lurking on my phone?

@Moem said in How to sign up to telegram on ut?:

Wow, that's suboptimal. It used to be, you only needed a phone that could receive an SMS to verify your phone number. I guess those days are over.

I tried that several times at first, but it never worked. I also contacted support, but they never responded. On the bright side, the process isn't too bad:

1. Insert your SIM card into any Android or iOS phone that has the Telegram app installed
2. If someone else is already logged in on the phone, log them out
3. Create and verify your account on the phone
4. While still logged in on the phone, initiate login process on any Telegram desktop app
5. Use logged in account on phone to verify login attempt from desktop app (QR code, verification code via Telegram message)
6. Log out on the phone, remove your SIM card, put other person's SIM card back in, etc.
7. Done. As long as you always have at least one active, valid session on any device, you can use it to verify other devices and never need the phone again.

I was just browsing the documentation and I found some info on repo2.ubports.com, so I decided to check it out. If you just copy/paste the name of the server (without "https://") you get an unencrypted connection. SSL is enabled, and navigating to https://repo2.ubports.com/ gives you an encrypted connection. I think a permanent redirect http > https might be good.

I'm afraid I can't spend any more time on this right now, so I'm going to have to wrap it up: Here are the key points:

• cron is gone in UT 20 and is not coming back
• Anything that relied on cron previously does not work anymore.
• The recommendation I received from a member of UT's core development team is to use systemd timers instead.
• I have tried countless variations and combinations of bash script files and systemd services over the past two days, but I am unable to get a systemd service to sucessfully execute a Syncevolution synchronization.
• I suspect that this has something to do with the requirement to export the DISPLAY and DBUS_SESSION_BUS_ADDRESS variables as well as the user account used to execute the syncevolution command, but I do not have the expertise to solve the problem at this time.

@arubislander said in Cron not installed?:

That implies the promise or possibility of future work.

As does "outside of the (current) goals of the project and design of the software", I would say. In that case, I would simply state "outside of the goals of the project and design of the software". This leaves no ambiguity regarding possible future work on whatever it is that the user is trying to achieve.

Now we can use that to nail down what the red line is that makes an action "unsupported". If I derive it from the above definition, then I arrive at a red line that is much more stringent than just making your system image writeable. Maybe some procedures/tutorials show you how to do advanced things that don't require making the system image writable. It's irrelevant. If what you're trying to achieve is not within the scope of the goals of the project and design of the software, then it's "unsupported".

@arubislander said in Cron not installed?:

I feel that if you are going to do 'unsupported stuff', it is best to know what you are doing and be willing to do the research if and when it breaks stuff.

And I agree with you.

The vibe that I'm getting is that if something is "supported", or more precisely "within the scope of the goals of the project and design of the software", then if a user tries it and gets in trouble, the likelihood that someone can help is high. On the other hand, if something is "unsupported", or "outside of the goals of the project and design of the software", and a user attempts it and messes things up, then there may not be anyone with the knowledge to help, and, as a consequence, a complete reinstall may be the only solution.

If we can agree on this, I think it is a very good basis for a clear message to users, and it also enables us to unambiguously label tutorials as "supported" or "unsupported".

Thinking further ahead, one thing that we might communicate to users is that if they want to attempt something "unsupported", then they should be aware that they may brick the system and a full re-install may be the only solution, so they should be comfortable with re-installing UT from scratch before they attempt it. What do you think?