some updates are not be visible on Github i see. Would like to help test while on devel channel

Note that upgrading to 5.12 also means even more work on 18.04 on top of the work needed on 16.04, since it likely also breaks compatibility for Qt/KDE apps and libraries there, necessitating we provide rebuilds of the packages broken by the upgrade. With 5.9, we only really need to do this on 16.04 (though the install on x86 is still broken there anyway).

We also have no idea what parts of our own stuff (UITK, etc…) might be broken by 5.12. If it is significant, upgrading Qt could turn into another quite lengthy project, and one that brings numerous new bugs along with it.

Alarm clock now seems to work (3 days in a row). Looks like existing alarms were ignored after an ota-update. This should not happen, it makes the device unreliable for daily use.
The indicator on the lock screen still does not show the alarm, maybe because it is a repeating alarm. I think that should be fixed too.
I will change the bug report in this way, thanks for testing to find the problem.

As we near the OTA-6 release, I would like to gather what I believe are the most important points from this post:

Everyone wants "release faster", without a doubt. "Release faster" depends on having enough confidence that software being released to stable is well-tested, which we do not have. Some things which would translate into more release confidence include: Automated tests on all system components Integration tests between system components Automated full-device testing, such as Canonical's fabled "Frankenstein device lab" Formalized manual testing by users who can confirm stability Even with full release confidence (but especially without), an automatic release model requires the ability to roll back to a previous version of apps and the full system image Aside: I want to experiment with one of the new atomic release models like OSTree which allows agnostic packaging formats to be installed on top. From my quick foray, I see: Benefits: Automatic and manual rollbacks, automatic diffing, and switchable roots Drawbacks that make this a long-term or impossible idea for our existing devices Probably requires newer kernel versions than 3.4 or 3.10 We don't have enough engineering power to concoct a solution which would allow converting a system-image system to OSTree in-flight, so we'd probably require users to manually switch.

I think that bringing up the edge channel as a place to do a large migrations out-of-band with the normal release cadence is going to have a huge impact on how quickly we can release in the future. Previously, @mariogrip's work on bringing us to upstream Libhybris would have had to wait until after OTA-6 lands, and then it would have delayed OTA-7 until we had proper confidence in it. With edge, we can have people help us test these huge changes with the ability to roll back and without disrupting current users.

To respond to my earlier hindsight: OTA-6 was not (yet 😛 ) taken away by TDS. We did not hit the original deadline set, but we will still be within our 6-8 week cycle when it releases. This includes our testing and release admin stage, which we are currently in. All of this while I'm not sweating bullets from pushing a release on ourselves before we're sure we're ready.

We have ended up in "Gotta release slower" in this cycle without a doubt. I hope to make the improvements we've identified here so "gotta release fast" can become a reality. I also hope to be able to take our release management up so that we hit 2-4 weeks development, 2 weeks testing. This means we'll get faster releases, but we still won't hit fast releases. 😛

Important note for anyone interested in contributing to... basically anything I've said here: I'll be holding an OTA-7 development meeting at the start of the cycle where we'll discuss how we want to improve during the OTA-7 cycle and taking bugs from the tracker for the release. Only assigned tickets will be added to this milestone, so if you have a pet bug that you want fixed now is the time to get involved to help fix it! Subscribe to this GitLab issue for more information as the day draws nearer.

You're not that horrible, @unisuperbox. 😉

@dobey said in Language packs as click packages: call to arms!:

@mardy Are we discussing language packs as clicks, or a more general solution to "what apps are installed by default" when flashing a phone? Because those seem like two separate things, and we should not use one of them as a reason to do another thing (or to not do some other different thing instead), I think.

I'm not using one as a reason to do the other, but rather I'm explaining how I imagine this evolving into, to convince you that we can get a nice user experience even with selectable language packs.

I also disagree with the idea of anecdotal argumentation of well, it's a waste in the rootfs for me, so why should it be there for others. I think it would be best to not go down this route. There are plenty of things in the rootfs which are meaningless for me too.

And what I'm suggesting is that, if those things could easily be installed as clicks, and if doing so would save a considerable amount of space, then it's something we might want to try out. It's a question on whether it's worth the effort.
I did start with language packs because I thought that it would be an easy pick, since they are data-only. And so far it looks like it's something easily doable.

[...]

Maybe having langpacks is something we will need to do in the future. But I think right now, we should not rush into this as a solution to the problems we have, as there are plenty of larger concerns at the moment. And if we rush into it, we will be stuck for a long time, even if we discover some other solutions to whatever problem this is meant to solve, instead.

I'm not requesting that people spend their time on this. If @bhdouglass told me that he has no time to review the changes I'll eventually submit to the Open Store, then I certainly wouldn't force him, but it looks like he likes the idea as well.
And I'll try not to rush: I do want to see a good implementation of this (especially because, as I said, I plan to apply a similar scheme for navigation data, later on).

Could I spend my time in a better way? Probably, but I'm doing this as a hobby in my spare time, so I tend to work on those things that interest me first 🙂

I tried to find a pattern to reproduce this issue. But there is none. The best way is to restart the phone, open the browser + uapp-explorer+youtube-app. Load something and begin switching. Mostly it works in the actual RC channel well, then something starts hanging which makes the browser restart and reload the startpage.
Same thing happens with browser+N5-camera that crashes. Email i didnt test since dekko2 has problems.
I also saw with systemsettings., but not often.
Could be an out of memory issue, but i could not trigger it...

Hi! I don't think there are any tutorials out there, but the source for all the different calendar layouts are here: https://github.com/ubports/keyboard-component
They are basically collections of qml files, but that's about the extent of my knowledge.

The recovery image is based on an older version of TWRP. However, as UT is not an Android ROM, we cannot really support most of the features of TWRP which are designed around Android, rather than alternate systems. This is why the recovery is stripped down.

Just a little sideways move to a better location.

@domubpkm Morph Browser is found in the RC channel as well - more stable than the developement one...

@flohack Perhaps I misread the canonical write-up as to why snaps couldn't run then, but I was under the assumption that snaps couldn't work on the Flo because of some LXC features being unavailable. If that's incorrect, that's awesome and makes me wanna try to get Anbox up and running on the Flo!

I was also unable to create a LXC container when I attempted on my Flo last, claimed it was missing some sort of kernel support (I can't remember the exact message, but I'm going to be reinstalling UT here soon, so I can attempt again!) and was the same reason Libertine hardcoded itself to chroot if running on a vivid-based device iirc (unless I misunderstood that requirement, in which case, my apologies for the misinformation then!)

Also, I mis-spoke in my previous reply, Flo is on 3.4.0, not 3.5.0 ^_^; (EDIT: I also want to mention that I had forgotten to state that I was writing using what I had thought was the case from Vivid, I admit I haven't tried LXC on Xenial yet)

Btw, I'm literally ALWAYS happy to learn, so if I'm incorrect about ANYthing, please don't hesitate to correct me and let me know. I realize I'm human and can misunderstand what I read a lot.

EDIT: just finished attempting LXC inside UT, nope. fails initializing CGroup support, and libertine-container-manager claims "System kernel does not support lxc type containers. Please either use chroot or omit the -t option."

Treble is more about easing the process of updating the device and making it harder for an update to brick the device.

Treble requires the phone to maintain two system partitions, similar to ChromeOS. When an update comes in, it's applied to the unused system partition and then boot is switched it it.

Unfortunately, it doesn't solve the issue of drivers because, as stated above, it's simply a more safe and efficient update system. The drivers are still installed via the system update being applied to the unused partition as they were traditionally (they'd have to be, otherwise you'd have say 7.1 blobs on an 8.x systemand be unable to boot), and not coming from someplace else stored on the phone.

So sadly, other than making use of Treble's A/B partition update style, it doesn't help the issue of propreitary blobs.

@Flohack that explains a lot then. I had tried previously to being up Halium with the mainline Flo kernel and had problem after problem because the Android image wouldn't compile under it due to some missing APIs that the camera libraries we're expecting. Good to know it wasn't because I was being an idiot and missing repos or something like that!

@jezek : Hum, I don't know ...
It seems to be scripts using rfcomm.
bt-serial : Connects to a specific RFCOMM based service on a remote device and then creates a RFCOMM TTY device for it

Not installed by default I think. So, a bit out of scope.

Best regards
Pulsar33