UBports Robot Logo UBports Forum
    • Categories
    • Recent
    • Tags
    • Popular
    • Users
    • Groups
    • Search
    • Register
    • Login
    1. Home
    2. peat_psuwit
    3. Best
    Offline
    • Profile
    • Following 0
    • Followers 5
    • Topics 20
    • Posts 103
    • Groups 0

    Posts

    Recent Best Controversial
    • Status update on Ubuntu Touch 24.04-1.x, March/April 2025

      Apologize for the late update this time. Let's get into it:

      For everyone: the next Ubuntu Touch release will be called 24.04-1.0

      You'll notice that this status update has a different headline format. After a discussion with UBports Foundation Board of Trustee (BoT) and with the community in general, we've decided on naming the next Ubuntu Touch release based on Ubuntu 24.04 as "Ubuntu Touch 24.04-1.0". 24.04 signifies the base Ubuntu version we're based on, and 1.0 represents whether it's a major upgrade or it's a minor update.

      For now, the system-image channel will still be called utnext/{arch}/{hybris|android9plus|mainline}/daily. We will provide more updates on system-image channel in the future.

      For app developers: it's now possible to build against Ubuntu Touch 24.04-1.x

      Finalizing on versioning scheme means we're now able to finalize the name of Click framework. The new framework is called ubuntu-touch-24.04-1.x, with -qml variant for QML-only applications and -papi for applications without QML part. Due to the limitation of the Click file format, the AppArmor policy version is 2404.1.

      Support in Clickable has been added in the recently released version 8.3.0. This means that if you specify the correct framework and AppArmor policy version, Clickable will choose the correct Docker image by itself and will produce Click packages compatible with 24.04-1.x series.

      Open-Store will not yet accept applications built against Ubuntu Touch 24.04-1.x, as the framework is not quite stable yet. However, it's stable enough for developers to compile and test their applications against newer versions of libraries (such as Qt 5.15) available in Ubuntu Touch 24.04-1.x.

      We intend to maintain full app compatibility between minor updates, but the same can't be said on major upgrade even when we stay on the same Ubuntu version. However, in practice the app compatibility on the same Ubuntu base version should be possible, and we'll try to maintain backwards compatibility where it makes sense.

      For app developers: Ubuntu Touch 24.04-1.x will support apps built against Ubuntu Touch 20.04

      Related to my last point, it turns out that it's relatively easy to maintain compatibility with apps built against Ubuntu Touch 20.04, with only a couple of compatibility libraries added to Ubuntu Touch 24.04-1.x. So, we've decided to maintain compatibility with applications which use ubuntu-sdk-20.04 framework and its variants.

      This applies to most phones which has a modern 64-bit ARM processor (this applies to all devices which we currently have stable releases of Ubuntu Touch 20.04). On older phones with 32-bit ARM processor, due to a large-scale transition in Ubuntu and Debian (64-bit time_t transition), this is not possible, and compatibility will be limited to QML-only apps which use -qml variant of framework.

      Status of Ubuntu Touch 24.04-1.x

      At the moment, a few key items still has to be done, including but not limited to:

      • Fix MMS and contacts/calendar sync.
      • Re-test push notification and hotspot to ensure they actually work.
      • Re-building our core applications against the new framework.
      • Update our artworks to go with the new Ubuntu icon, introduced at part of Ubuntu 22.04.
      • A more streamlined mechanism to upgrade Ubuntu Touch major releases.
      • Infrastructure-side work to support the new Ubuntu Touch release scheme.

      We still need help in many of these items. If you're interested in lending hands, please reach us on our Telegram group.

      posted in OS utnext noble 24.04-1.x
      peat_psuwitP
      peat_psuwit
    • [Call for testing] Announcing out-of-schedule Ubuntu Touch 20.04 OTA-7

      We're going to release Ubuntu Touch 20.04 OTA-7 earlier than schedule to fix a number of security issues affecting Pulseaudio, our audio server. One of the issue affects privacy of Ubuntu Touch users, and thus we've decided to release an out-of-schedule update.

      The issues are as follow:

      • Confined applications can remove the Trust Store permission system module from Pulseaudio, allowing such applications to access the phone's microphone without user knowing, amongst a number of privileged actions.
      • Confined applications are able to crash Pulseaudio by performing a volume control on a specific virtual device when a Bluetooth headset is connected.

      Both of the issues are specific to the way Ubuntu Touch patches and uses Pulseaudio. However, the second issue has a potential to affect some Ubuntu 16.04 installations running non-default configuration (newer versions are not affected). As such, we've coordinated with Canonical on the timing before making this announcement.

      Due to the way our release pipeline works, Ubuntu Touch 20.04 OTA-7 will also contain a number of fixes which are not related to the aforementioned issues. Thus, we'll release an RC for 20.04 OTA-7 in upcoming days and we'll announce a call-for-testing. We plan to release Ubuntu Touch 20.04 OTA-7 on Friday 29 November 2024.

      Updated: Ubuntu Touch 20.04 OTA-7 RC is out, which should have version 2024-W47. Please take some time to switch your spare/development phone to the 20.04 RC channel and test this OTA.

      Update: Ubuntu Touch 20.04 OTA-7 is released. Thank you everyone involved in testing.

      posted in OS
      peat_psuwitP
      peat_psuwit
    • RE: On the subject of Ubuntu Touch versioning scheme

      In the Board of Trustees meeting on 4th February, I've brought the release version numbering up as a discussion topic. The attendees considered the comments on this post and have agreed that it's important to still reference Ubuntu version in our versioning scheme, while it would be beneficial development-wise to have a major-minor release system in place.

      As such, we've come up with a versioning scheme of "Ubuntu Touch [Ubuntu version]-[release version]" (a variant of option 3). For example, the next version of Ubuntu Touch would be referred to as "Ubuntu Touch 24.04-1.0".

      We believe this versioning scheme is both understandable and practical.

      posted in General
      peat_psuwitP
      peat_psuwit
    • Status update on the next, Noble-based Ubuntu Touch release, December 2024

      I just realize that there has been a lack of a long-form communication from the Ubuntu base upgrade side, which causes some frictions and confusions when trying to contribute to Ubuntu Touch during this transition period. This post aims to provide status updates and information that I think everyone has to know.

      Name changes for Noble-based images

      Due to some confusion in the word devel which has been used differently before, I've decided to rename the word devel that is used in various places to just next or utnext. In practice, this means:

      • The image name from the rootfs job will be in the format of e.g. ubuntu-touch-android9plus-rootfs-next-arm64.tar.gz
      • The system-image channel for testing out Noble-based is now called utnext/arm64/android9plus/daily. Note that we've set up redirection in place, so if you're already on the old channel, you'll automatically be redirected to this new name.
      • The Clickable images (which we're still working on) will be available under the version next.

      The name next is chosen to represent that this will become the "next" major release of Ubuntu Touch. When we enters the phase where we stabilize the release, we'll produce another set of channels, rootfs and Clickable images with the release number (which is yet to be finalized).

      Status of Noble-based Ubuntu Touch

      Since the last time I made a forum post, the following features has become usable:

      • Web Browser
      • Media Playback
      • Sensor

      This may seem not much, but more features are already in the code review phase. It could even be possible that we'll have the image in the state ready for wider testing before the Chrismas. We'll see...

      Please be careful when submitting changes to core applications

      Mike Gabriel and his team is currently working to package up a number of UT/Lomiri core applications for Debian, making them available on a more up-to-date OS with newer Qt compared to Ubuntu 20.04 our current images are based on. Meanwhile, our Noble-based Ubuntu Touch image is start to be more usable. Both of these expose our applications to new warnings which has not appeared before on Ubuntu Touch 20.04 with Qt 5.12.

      However, in many cases, the only way to solve those warnings is to migrate the code to the new syntax. Syntax which is not compatible with Qt 5.12. In particular, those syntax changes include:

      • Using function onFoo () { } form for Connection { } component.
      • Setting restoreMode property of Binding { } component.

      Since we've not make a separated branch for 20.04 just yet (and we can't do so because Clickable support for Noble-based Ubuntu Touch is not available yet), please don't introduce those changes into our core application repositories (more specifically, repositories under "ubports/development/apps" GitLab group). We've yet to decided if we need a separated branch for Ubuntu Touch 20.04 compatibility, but personally I would prefer that we don't need one.

      Also, please be reminded that these applications are first and foremost core applications for Ubuntu Touch. When submitting changes for them, please be mindful of this fact. When reviewing changes, please think of a possible breakage on phone (and wrt. Click packaging). Preferably test them on a phone first if the change seems big.

      Side note: we're planing to ship an environment variable drop-in file to silence deprecation warnings for the 2 syntax changes above. This should ease your eyes when reading through the log on the device.

      Heads up for porters: please drop touch.pa overlay if possible

      We expect ports that are available on Ubuntu Touch 20.04 to require only minimal changes in order to run on Noble-based Ubuntu Touch (unlike the 16.04 -> 20.04 transition). We've yet to finalize all changes that will be required. However, one change is certain: touch.pa will have to be updated, or be dropped if possible.

      This is due to how a newer Pulseaudio changes how it handles Bluetooth audio, requiring us to update the configuration for the Bluetooth module. However, if touch.pa file is overlaid from ports, the old configuration would be used, preventing voice call over Bluetooth headset to work properly.

      If your port requires overlaying touch.pa to hard-code the API level of pulseaudio-module-droid to 30, then you'll be glad to know that it will no longer required when MR at [1] is merged, as it will now happen automatically when required. If, however, your port requires overlaying touch.pa to specify quirks to pulseaudio-module-droid, we'll soon provide a way to specify this quirk without overlaying touch.pa. And if you need to overlay touch.pa for other reasons, please tell us so that we can understand your need better.

      [1]: https://gitlab.com/ubports/development/core/hybris-support/pulseaudio-module-droid-discover/-/merge_requests/6

      Another thing that might require special consideration is that, if your port overlays binary files (which we would not recommend, for security update reason and other reasons), please make sure that your overlaid binary can be executed on Noble-based images, as not every library retains its interface and/or soname.

      Heads-up for app developers: you'll need to re-build your app

      Due to changes in Ubuntu 24.04, we cannot guarantee that every application built against Ubuntu Touch 20.04 will run on Noble-based Ubuntu Touch. As such, we'll enforce it through Click's framework system that every native applications must be re-built against the next Ubuntu Touch version.

      However, we've not finalized how the Clickable support for the new release scheme will look like. So you can't quite do that just yet. Sorry for the delay.

      Meanwhile, if your application is QML-only, and the Click package declare this fact through Click framework (i.e. by using ubuntu-sdk-20.04-qml framework), your application should work as-is without any change. However, due to a shortcoming in Clickable, you might not be able to do that just yet. Please follow issue at [2] to see if this has been solved.

      [2]: https://gitlab.com/clickable/clickable/-/issues/444


      Phew! That's a lot of stuffs. I didn't expect it to be this long when I first decided to sit down and start writing this up. But here we are.

      If you still have any question, feel free to reply to this post or to ping me on Telegram in the "UBports Development" channel. I'll try to answer as much as I can.

      posted in OS
      peat_psuwitP
      peat_psuwit
    • Status update on the next, Noble-based Ubuntu Touch release, February 2025

      Status of Noble-based Ubuntu Touch (UTNext)

      Since the last time I made a forum post, the following features has become usable:

      • GPS
      • NFC
      • Phone call & SMS
        • Note that MMS is blocked until very recently. We'll have to recheck if it has been fixed or not.
      • Camera, include picture and video recording.

      Progress is a bit slower than we expected. But we still are progressing nicely.

      For app developers: it's now possible to build & test your apps against UTNext

      After a long await, you can now start attempting to rebuild your app against Noble-based UTNext. This should allow you to test whether your app has any problem with the Noble-based images, especially if the app was unable to start on them before due to shared library changes.

      For now, you'll need to get a nightly build of Clickable. After that, specify ubuntu-touch-next-internal as the framework inside clickable.yaml and specify policy_version of the AppArmor profile to 9999. You may also also have to make sure your manifest.json specifies @CLICK_FRAMEWORK@ in the framework field so that the correct version is filled in automatically by Clickable (sadly a similar mechanism doesn't exist yet for AppArmor policy - see this issue). When building, you'll have to specify --accept-review-errors for now, as click-reviewer-tools has not been updated.

      ubuntu-touch-next-internal is a framework which corresponds to the on-going development of UTNext. The -internal part indicates that there is no formal "contract" for this framework. In other words, we don't guarantee forward- and backward- compatibility with any past and future Ubuntu Touch versions. The framework is intended for testing only and is not intended to be published to the Open Store; you'll have to switch to the final framework when it's available.

      Due to delays and ongoing discussions, we at the core team are still unable to settle on what versioning scheme and what version number we will use for the next Ubuntu Touch release, and subsequently as the final framework name. We'll have a separated post discussing this in more details and allow you to chime in. We're sorry for this; as soon as we're able to finalize this detail, we'll provide an update to you.

      Update: please see a separated post for a discussion around version number: https://forums.ubports.com/post/84517

      For porters: it's now possible to drop touch.pa overlay (for UTNext, at least) now possible on both UTNext and 20.04

      If your port is one of the port which has to overlay /etc/pulse/touch.pa to provide additional arguments to pulseaudio-module-droid-discover or pulseaudio-modules-droid-card-<API>, it's now possible to instead provide extra arguments using an Deviceinfo property. The property is called PulseaudioModulesDroid_ExtraCardArgs [1] and accept all arguments which you may add to pulseaudio-modules-droid-card-<API>. For example, you can put this in your Deviceinfo overlay to set sampling rate of your device's audio chip:

        PulseaudioModulesDroid_ExtraCardArgs: "rate=48000"
      

      Combined with a change which allow you not to hard-code API level, it should now be possible to drop touch.pa overlay entirely. This feature is now merged into UTNext and 20.04, so you'll be able to share your device tarball between 20.04 and UTNext.

      [1]: In case you're wondering, yes, there are PulseaudioModulesDroid_ExtraGlueArgs and PulseaudioModulesDroid_ExtraHidlArgs as well. However, I believe you won't need them.

      posted in OS
      peat_psuwitP
      peat_psuwit
    • Noble-based devel images now available on most devices with 20.04 devel image

      For those that are interested in development of Noble-based Ubuntu Touch, we've now published a new system-image channel devel/arm64/android9plus/daily, available on most devices which has 20.04 devel image [1]. You can switch to it using the following command:

      sudo system-image-cli -v --progress=dots --switch=devel/arm64/android9plus/daily
      

      The channel has actually been existed for some time. However, up until today images are available only on a handful of devices due to system-image server configuration limitation. Note that I haven't tested the images on devices other than a handful of devices I have, so please make sure you have a way to recover your phone before trying this.

      Note that at the time of posting, the Noble-based images are still missing quite a number of functionalities. At the moment, the following features are either known to be not working, or is not tested but is likely not to be working:

      • Web browser
      • Media playback
      • Camera
      • Libertine
      • Sensor
      • Push notification
      • Dialer, Messaging UI
      • Hotspot

      If you're interested in helping bringing up these features to Noble-based images, please ping me either here or on Telegram.

      Do not install this image on your daily driving phone. Things will be broken. You have been warned.

      [1]: more specifically, devices with 64-bit ARM architecture and Halium 9 or newer.

      posted in OS
      peat_psuwitP
      peat_psuwit
    • Call for testing: Updated Pulseaudio & better Bluetooth headset support

      This is the followup from my previous call-for-testing. This time, in addition to updated PulseAudio from 16.04, this also includes:

      • a fix to Bluez which should improve the experience for users that use a Bluetooth headset for calling.
      • an update to the modern pulseaudio-module-droid to make sure they work with the updated version.

      All devices are welcome to participate in the test.

      How to test:

      Make sure your device runs the latest devel image. Run the following command in the ADB shell or SSH session:

      # Mount a tmpfs so apt can breathe
      sudo mount -t tmpfs tmpfs /var/cache/apt/archives 
      # Prevent Bluez from restarting & get stuck.
      sudo mount -o remount,rw /
      sudo tee /usr/sbin/policy-rc.d >/dev/null <<EOF
      #!/bin/sh
      exit 101
      EOF
      sudo chmod +x /usr/sbin/policy-rc.d
      # Actually install the packages.
      sudo ubports-qa install xenial_-_pulseaudio-updates-to-0ubuntu3.10
      # Reboot the phone.
      sudo reboot; exit
      

      What to test:

      See if there's any regression in both built-in speaker, wired headset, and Bluetooth headset. If possible, use a Bluetooth headset that can be in both music mode (hi-fidelity audio) and call mode (low-latency 2-way audio).

      Two possible regressions that can happen are

      • issue #528 ([xenial] Sound does not go to bluetooth headset)
      • a call via Bluetooth does work but cuts off after a few seconds

      I believe they're fixed, but please report if you encountered these issues.

      Also, if you have a Bluetooth headset with an accept/hangup button, try pressing the button while in call and see if the call hangs up. Accepting the call or last number redial might not work, and is a known issue.

      You may want to also follow this test plan from Canonical if you want to be extra sure there's no issue. However, even in the current version of PulseAudio, not all tests in this test plan pass. Thus, you may want to double-check if it's a regression or not.
      https://wiki.ubuntu.com/Process/Merges/TestPlan/pulseaudio

      If you found any issue/regression:

      Luckily, someone has written a script that automates enabling, disabling, and collecting debug logs [1]. It's located at https://github.com/bergotorino/bt-debugging-tools

      To enable debugging, run ./bt-device-enable.sh -e -p <lockscreen password>. The device will reboot automatically. Then, after reproducing the issue, run ./bt-collect-logs.sh <password>. A tarball will be produced. Please send that to me via PM or Telegram (@peat_psuwit) as it can contain sensitive information. Please also mention the brands of all devices you used to test in the PM; they'll be used to match up with what's in the log.

      To disable debugging, run ./bt-device-enable.sh -d -p <password>

      [1] For devices with ADB anyway. If you use a Halium 7.1 devices without ADB, you may take a look at the script, or you can ask me.

      Known issues:

      • The issue that the playing streams won't switch to the headset after a re-connect/connecting another device is issue #1045. The fix requires that this update works first. To workaround, please close and reopen the app playing the sound.
      • Even though using the button on the headset to hangup work, using it to accept a call or redial might not work.
      • It's been reported that Bluetooth on OnePlus One is unstable in general. Thus, you may want to skip testing Bluetooth on this particular device.
      posted in OS
      peat_psuwitP
      peat_psuwit
    • Call for testing: Ubuntu Touch 20.04 OTA-8

      We've just released the RC image for the Ubuntu Touch 20.04 OTA-8, which should have version 2025-W08 or newer. Please take some time to switch your spare/development phone to the 20.04 RC channel and test this OTA.

      Ubuntu Touch 20.04 OTA-8 is a maintenance release with only a minimal number of changes. That said, we still have a number of changes in this OTA. We would love some extra attention to the following areas:

      • Basic phone functionality (calls, SMS, MMS and cellular data)
      • Address book app
      • Web browser
      • Wi-Fi settings
      • If you were affected by mobile data breakage issue in OTA-6 testing cycle, please check if mobile data is working for you in this RC. You might be affected if you use Volla Phone X23, live in Germany, and Telekom is your carrier.
      • If you're using Volla Phone 22 with a new replacement screen, we would appreciated it if you can spare your time testing this RC.

      Please note that only critical and security fixes will be able to enter Ubuntu Touch 20.04 OTA-8 as this point. Normal bug fixes and new features will need to wait for our next release. Please do not discuss normal bug fixes and new features here.

      Ubuntu Touch 20.04 OTA-8 is expected to be released on 28 Februrary 2025. We appreciate all testing we will receive.

      Update 19 Feb 13:40 UTC: earlier version of the announcement mentioned contact syncing as an area of interest for testing. It was included by accident, and has been removed.

      Update 20 Feb 7:00 UTC: a new RC has been published which include a fix for Pixel 3a XL cellular breakage.

      Update 25 Feb 13:40 UTC: a new RC has been published which fixes mobile data issue on some Volla Phone X23 users depending on SIM slot being used.

      posted in OS
      peat_psuwitP
      peat_psuwit
    • Call for testing: Ubuntu Touch 20.04 OTA-5

      We've just released the RC image for the Ubuntu Touch 20.04 OTA-5, which should have version 2024-W30 or newer. Please take some time to switch your spare/development phone to the 20.04 RC channel and test this OTA.

      Ubuntu Touch 20.04 OTA-5 is a maintenance release with only a minimal number of changes. That said, we still have a number of changes in this OTA. Please have a look if:

      • The battery life, compared to the previous OTA, doesn't not get worse.
      • There's no settings being overwritten (you don't have to be exhaustive. Just report if you remembered a setting being different before receiving this update).
      • Morph Browser works as well as it was in the previous OTA (please don't report known website incompatibilities).

      Please note that only critical and security fixes will be able to enter Ubuntu Touch 20.04 OTA-5 as this point. Normal bug fixes and new features will need to wait for our next release. Please do not discuss normal bug fixes and new features here.

      Ubuntu Touch 20.04 OTA-5 is expected to be released on 29 July 2024. We appreciate all testing we will receive.

      posted in OS
      peat_psuwitP
      peat_psuwit
    • RE: No new stuff for xenial, but what about old new stuff?

      Hello jEzEk,

      There are both technical and societal reasons as to why we have decided to not accept new features into the Xenial line of update anymore, even the ones which is developed against Xenial and is near ready.

      First, the technical reason: due to a large number of changes involve in making all Ubuntu Touch components works with the new version of Ubuntu, compound with desire to realize the rename in this release, we've decided early on to have a separated branch of code for almost every component we have. Unfortunately, this resulted in a largely separated development between Xenial and Focal, and while one is busy making a component runs on Focal, another proceeds to add new features onto the existing codebase on Xenial. And because we didn't realize this problem early enough, this means now we have quite a backlog to visit. Also, since the code diverged a lot since we start the branches for Focal, sometimes it's not straight forward to port changes to Focal. So, limiting the amount of changes that enters Xenial directly reduces the amount of work needed to make Ubuntu Touch based on Focal a reality.

      Now, the societal reason: as mentioned by many people above, we're a small group of people and unfortunately can't do everything at once. In addition to adding the amount of changes we need to carry to Focal, time spent reviewing changes for Xenial is time not spent developing or reviewing changes for Focal. Given that Xenial has been out of support for over a year at this point, it has become our priority to provide our users with the up-to-date base for the security of our users, and that means we need to reduce as much work as possible.

      In addition, many people might consider Focal complete when it reaches feature parity to Xenial. However, if more changes keeps being added to Xenial, it becomes harder to realize that objective. Having to chase a moving target is not fun, and personally I already have that feeling when I realized that the contact backend changes will land in OTA-24. Fortunately that didn't happen in the end, but even for smaller features it can easily be unexpectedly hard to bring to Focal.

      So, please accept my apology that we cannot accept more changes into Xenial line of update anymore. We want to have an up-to-date and secure operating system, and we cannot have that with an out-of-date base.


      On the side of device support, the primary limiting factor at the moment is due to the inevitable change of the init system from Upstart to Systemd. Systemd uses a number of modern features of Linux kernel, and as such requires a (moderately) modern Linux kernel. The version of systemd requires Linux >= 3.13, however the recent version raised that a bit.

      It's possible to backport certain changes into an older kernel to make systemd runs, but it's a tedious manual task that has to be done per kernel tree [1]. A rule of thumb is that if the device launches with Android 9 it should be fine, but for older devices one must check the Linux kernel version.

      [1] For example, I've done such job on FP2, which allows me to run an old image of Plasma Mobile which uses systemd.

      posted in General
      peat_psuwitP
      peat_psuwit
    • GitHub mass archival starts Monday 18 December

      Starting from Monday 18 December 2023, I'll start to brutally archive GitHub projects in ubports group that should have been archived for some time. This includes (but isn't limited to) unity8 and indicator-*, amongst others (probably).

      By brutally, I mean I'll archive them without further modifications to the repository. No updating README, no issues & PRs closing, no per-issue notification, and no further migration. The only change I'll make with archiving is modifying the description so that it points to the relevant, migrated repo (our GitLab for most, but AyatanaIndicators when applicable).

      We once planned to actually use GitLab's migration tool to migrate those repos over, and then notify each of the issue and PR of the new location of it. However, as we (accidentally?) create a new, corresponding repo on GitLab, migrating the repo from GitHub suddenly becomes more complicated. As such, I've decided that it's no longer worth an effort to do the migration, as code-wise, we're pretty much self-hosted on GitLab now.

      Some repository will still live on GitHub and won't yet be archived in this round. This includes installer-config, build-tools, and various Android trees. Efforts are being made to migrate the rest of repositories to GitHub, to avoid confusions in the future.

      If you happen to have some issue filed on GitHub that will be archived, I'm sorry for the inconvenience. If it still occurs on Focal, today, please file a new issue on GitLab. We now have a meta-repo for issues, so please go to https://gitlab.com/ubports/ubuntu-touch for new issues.

      posted in OS
      peat_psuwitP
      peat_psuwit
    • RE: ubports/focal branching will happen on 14 February

      The branching is finished. I have to run the script twice since in the first run the script did not take the archived state into account. Luckily, the script is already idempotent, so I can just code that in and re-run the script.

      For accountability, these are the log of both runs: https://gitlab.com/-/snippets/3673980

      Also, since I noticed it, I also go ahead and delete ubports/focal branch after the fact for these repositories since they are not actually code repositories.

      • https://gitlab.com/ubports/development/core/devscripts
      • https://gitlab.com/ubports/development/core/focal-projectmanagement-missing-packages

      As mentioned, this means CI for main branch will fail for a while, so it's probably not a good idea yet to merge MRs. I'm working on the CI change as we speak. Thank you for your patience.

      posted in OS
      peat_psuwitP
      peat_psuwit
    • CI is now fixed and freeze is lifted

      The new CI code is now fully functional, and will build packages against both Ubuntu Noble and Debian testing. So we can now accept MRs again!

      Note that since I start the new APT archive here, a few dependencies are still missing and your MR may still fail. I'm working to bootstrap the most important dependencies. Also, I've configured the CI so that the failure against Debian testing is not fatal (but will show up as "unstable"). However, due to GitLab's limitation it may show up in GitLab as failure. Please take Jenkin's comment in the MR as it gives more detailed status.

      The rule that everything must land in main branch first still apply. After an MR is merged, we can have the MR backported to the ubports/focal branch if wanted. I'm working on wiring up the backport automation, but in the mean time I can also run the backport automation manually.

      I'll work to document everything up by this week. In the mean time, if you have any questions or the CI is not working as expected, please ping me on Telegram. Also, if you have a fix that you want to land into Focal image quickly, please also ping me so that I prioritize fixing that component's dependencies.

      posted in OS
      peat_psuwitP
      peat_psuwit
    • Fairphone 2 (FP2)

      This is a Halium 7.1 based port for Fairphone 2. The current port is based on Android 5.1 and has quite a few band-aids and workarounds. This port is completely new and isn't based on the current port.

      Sources:
      Kernel: https://github.com/Halium/android_kernel_fairphone_msm8974/tree/halium-7.1
      Device: https://github.com/Halium/android_device_fairphone_FP2/tree/halium-7.1_ubuntu
      Manifest: https://github.com/Halium/halium-devices/blob/halium-7.1/manifests/fairphone_FP2.xml (This manifest doesn't point to the Ubuntu Touch additions. Add revision="refs/heads/halium-7.1_ubuntu" to the device tree tag to retrieve them.)

      Status:

      • Working:
        • Display, Wi-Fi, Audio, Battery indicator, Bluetooth, Video playback, Vibration, GPS, Accelerometer
        • Camera (Needs gst-droid, see the instruction in another post.)
        • Audio (Headphone detection now works correctly.)
        • Cellular (Both SIM slots work. Voice call, SMS, MMS, mobile data works.)
        • Front LED (fixed in the rootfs)
      • Not working:
        • Flashlight
        • Abysmal battery life with the Wi-Fi on.

      Install:
      No prebuilt image has been made yet. Thus, you're required to build the image from source.

      posted in Fairphone 2 fp2 fairphone 2
      peat_psuwitP
      peat_psuwit
    • How to: test GStreamer-droid based camera support in Ubuntu Touch (for Halium 7.1 based port)

      As you might already know, I'm currently making GStreamer-droid works properly in Ubuntu Touch as a replacement for qtubuntu-camera. This will make video recording works for Halium 7.1 based port, as otherwise a set of custom patches on the Android side (which isn't easy to forward-port) is required.

      How can you test this out?

      If you're interested in testing this out, please follow these instructions:

      Halium side preparation

      Due to breaking API change in droidmedia, you'll need to make sure you have a recently-built Halium image. If you build your own Android image, make sure your Halium tree is recently synced as of 8 June 2020. Otherwise, please make sure you have the latest image built on or after that date.

      Install GStreamer-droid

      1. Make sure you're running the latest devel or edge channel image. If you're interested in testing video recording too, please make sure that audio for your port works correctly.
      2. Run sudo umount /lib/udev/rules.d/70-android.rules. This prevents failure in the following step.
      3. Run sudo ubports-qa install xenial_-_gst-droid to add the repository containing the packages. UBports-qa will upgrade the already installed packages to the latest version and install the new packages.
        • If you encountered unable to make backup link of '<a path>' before installing new version: Invalid cross-device link error, unmount it by running sudo umount <path without the prepending dot> it and try again.
        • The error ERROR:ubports-qa:Failed to remount root filesystem read-only. is normal and expected. Proceed to the next step.
      4. Reboot your phone to make sure everything is in place.

      Install updated camera-app

      You'll also need the updated camera-app. To install, grab the correct binary for armhf or arm64, then install with pkcon install-local --allow-untrusted <file name>. UPDATED to version 3.1.3.

      If you're interested in the changes I've made, take a look here.

      How to debug

      If things don't go as it should, you can add additional debug information by running the camera-app from the command line.

      (cd /opt/click.ubuntu.com/com.ubuntu.camera/current && GST_DEBUG=droidcamsrc:4 ./camera-app --desktop_file_hint=com.ubuntu.camera_camera)
      

      About the upgrading

      Please note that by installing packages via ubports-qa or apt, you should not install system updates via the system settings app anymore (you'll overwrite this change otherwise). Instead, you'll need to use sudo apt update and sudo apt upgrade like on the desktop. This is temporary, and won't be required after this is merged into the proper xenial branch.

      Also, even though this procedure works on devices on the stable channel, note that following this procedure essentially upgrades the entire device to devel channel. Please test responsibly and don't use it on your daily driver. This will be merged to the xenial branch soon and testing should be easier when that happens.

      posted in OS
      peat_psuwitP
      peat_psuwit
    • RE: Fairphone 2 (FP2)

      @Fla We're working towards that goal, but the base system requires more changes to support Halium 7.1 ports better before we can release any Halium 7.1 port as an official port.

      posted in Fairphone 2
      peat_psuwitP
      peat_psuwit
    • Call for testing: updated Pulseaudio from Ubuntu 16.04

      I've (re-)imported the changes made to Pulseaudio in Ubuntu 16.04. This primarily improves the experience of using Bluetooth headsets with the phone. However, there's a report of regression due to these changes before. I've fixed that one specific regression, but I'm not sure if there's any other regression due to these changes.

      Please only test this change on a device running the latest images from the devel channel, and test responsibly! In other words, try it on a spare device or when you know you'll be near a computer you can use for reflashing. [1]

      To test, please follow the instruction:

      1. Mount a tmpfs so apt can breathe: sudo mount -t tmpfs tmpfs /var/cache/apt/archives
      2. Install the repository: sudo ubports-qa install xenial_-_pulseaudio-updates-to-0ubuntu3.10
      3. Reboot your phone.

      See if there's any regression in both built-in speaker, wired headset and Bluetooth headset. If possible, use a Bluetooth headset that can be in both music mode (hi-fidelity audio) and call mode (low-latency 2-way audio).

      You may want to also follow this test plan from Canonical if you want to be extra sure there's no regression: https://wiki.ubuntu.com/Process/Merges/TestPlan/pulseaudio

      Note for OnePlus One users: It's been reported that Bluetooth on OnePlus One is unstable in general. Thus, you may want to skip testing Bluetooth on this particular device.

      Known issue: The issue that the playing streams won't switch to the headset after a re-connect is known, and will be fixed after this [2].

      [1] This specific instruction courtesy of Dalton Durst.
      [2] https://github.com/ubports/ubuntu-touch/issues/1045

      posted in OS
      peat_psuwitP
      peat_psuwit
    • ubports/focal branching will happen on 14 February

      As announced on the blog, we will start creating ubports/focal on our git repositories. I intend to start creating these branches on 14 February 2024, 18:00 UTC.

      This post serves as an FAQ for both the announcement and for the upcoming branching, as well as the place to ask additional questions.

      What is the scope of this branch creation?

      For this round, it will include most Git repositories under ubports/development/core GitLab group. Since I expect that most applications, including core apps, should not require much changes for 24.04 base upgrade, I've decided that I won't create branches for core apps for now. Should the need arise, we can decide later.

      Also excluded in this round is repositories under ubports/development/core/packaging, which contains ubports/focal branch but not ubports/latest. Since this usually means the packaging is not applicable if the base changes, we will probably want to start a new ubports/latest from scratch instead of forking from current ubports/focal.

      What will happen with the CI after branching?

      At the moment of branching, hopefully nothing. I will config Jenkins so that it ignore new branches, so new builds should not be triggered because of this. I will actively monitor Jenkins to ensure this, and will cancel any excess jobs that happen because of branch creation.

      After that, new commits added to ubports/focal will be built & published to the Focal APT archive on repo.ubports.com as expected. However, new commits added to main will fail to build with No distro is included in multidist. Maybe "main" shouldn't exist?. This is expected, since our CI code isn't yet updated to support new branching scheme. Updating CI code is the next on my agenda.

      What about focal_-_<extension> branches? What do you mean by "explicit dependency declaration"?

      Since the "branch extension" concept doesn't translate well into the new branching model, it was decided to drop this out of the specification. While the old ubports/focal_-_<extension> will continue to work (grandfathered), do not expect this to be the case for future releases.

      As for "explicit dependency declaration", the plan is to let you specify the dependent MRs in the MR description, and the CI will read that description and pull in that MR's APT archive. I will work on this as part of CI code work. Long term, I would prefer that we also get GitLab's MR dependencies, but GitLab is still figuring out how to expose that via API.

      How will you create all the branches across all repositories?

      The creation of the branches is automated using this Python script. It talks to GitLab API to fetch the current status of all repositories, then decides what branch to create (and from what branch). It then asks for confirmation, and when confirmed, create all the branches. The script is designed to be idempotent, and take into account that some repositories have ubports/focal branch but not main.

      What will happen with the devel system-image channel?

      At the moment, nothing. Since our devel channels are already prefixed, the 20.04/*/*/devel channels will continue to receive Focal-based images, which subsequently will continue to be built from focal APT archive.

      I have not decided the new system-image channel to publish the noble-based images yet.

      posted in OS
      peat_psuwitP
      peat_psuwit
    • RE: Call for testing: Ubuntu Touch 20.04 OTA-8

      Ubuntu Touch 20.04 OTA-8 is released. Thank you everyone involved in testing.

      https://ubports.com/blog/ubports-news-1/post/ubuntu-touch-ota-8-focal-release-3953

      posted in OS
      peat_psuwitP
      peat_psuwit
    • RE: Documentation temporarily offline

      Hello. After sorting out some billing issue with Cloudflare and re-adding our domain to Read the Docs, https://docs.ubports.com/ is now online again. We apologize for any inconvenience caused by this.

      posted in General
      peat_psuwitP
      peat_psuwit