[Touch-packages] [Bug 2058690] Re: aa-easyprof: allow mmap and link from easyprof generated profiles
Hmm... indeed! I'll re-investigate why we need `m` permission by the default. I assume that if there's something that actually need `m` permission, a new key in the easyprof manifest would be needed, right? As for `l` rule for writes, do you think it's safe to add? Given that "the new link MUST have a subset of permissions as the original file" [1], this shouldn't be able to be used to open up more permission. [1]: https://manpages.debian.org/bookworm/apparmor/apparmor.d.5.en.html#l~2 -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to apparmor in Ubuntu. https://bugs.launchpad.net/bugs/2058690 Title: aa-easyprof: allow mmap and link from easyprof generated profiles Status in apparmor package in Ubuntu: New Bug description: Currently, an easyprof-generated profile will list the reads with `rk` and the writes as `rwk`. With recent Qt, this breaks because newer Qt versions use hard-linking of temporary files to perform atomic writes. Also, `rk` doesn't allow mmap()'ing shared library for execution. We at UBports are carrying a patch in Ubuntu Touch which changes the read rules to `mrk` and write rules to `mrwkl`, and are upstreaming this patch at [1]. When the MR is merged, I would like this patch to be included in Ubuntu 24.04, so that Ubuntu Touch doesn't have to package AppArmor separately from Ubuntu. If we agree that we want this patch, I can provide an MR on Salsa. [1] https://gitlab.com/apparmor/apparmor/-/merge_requests/1189 To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/apparmor/+bug/2058690/+subscriptions -- Mailing list: https://launchpad.net/~touch-packages Post to : touch-packages@lists.launchpad.net Unsubscribe : https://launchpad.net/~touch-packages More help : https://help.launchpad.net/ListHelp
[Touch-packages] [Bug 2061128] [NEW] `add-apt-repository --pocket` doesn't work on Noble (Deb822?)
Public bug reported: It seems like `add-apt-repository` doesn't know how to enable a new pocket when Ubuntu's sources are defined in Deb822 (.sources) source file. Step to reproduce: 1. Create a Noble chroot with e.g. Docker. Verify that in such chroot, Deb822 is used for Ubuntu's source (`ls /etc/apt/sources.list.d/ubuntu.sources`). 2. Run `add-apt-repository --pocket proposed`. Accept the prompt. 3. Run `apt policy`. - Expected result: `noble-proposed` is listed. - Actual result: `noble-proposed` is not listed. This might be related to LP: #2060331, but since I'm not sure how it works, I'm filing a new bug here. ProblemType: Bug DistroRelease: Ubuntu 24.04 Package: software-properties-common 0.99.46 ProcVersionSignature: Ubuntu 6.5.0-27.28~22.04.1-generic 6.5.13 Uname: Linux 6.5.0-27-generic x86_64 ApportVersion: 2.28.0-0ubuntu1 Architecture: amd64 CasperMD5CheckResult: unknown CloudSerial: 20240225 Date: Fri Apr 12 18:38:12 2024 PackageArchitecture: all ProcEnviron: PATH=(custom, no user) TERM=xterm SourcePackage: software-properties UpgradeStatus: No upgrade log present (probably fresh install) ** Affects: software-properties (Ubuntu) Importance: Undecided Status: New ** Tags: amd64 apport-bug cloud-image noble -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to software-properties in Ubuntu. https://bugs.launchpad.net/bugs/2061128 Title: `add-apt-repository --pocket` doesn't work on Noble (Deb822?) Status in software-properties package in Ubuntu: New Bug description: It seems like `add-apt-repository` doesn't know how to enable a new pocket when Ubuntu's sources are defined in Deb822 (.sources) source file. Step to reproduce: 1. Create a Noble chroot with e.g. Docker. Verify that in such chroot, Deb822 is used for Ubuntu's source (`ls /etc/apt/sources.list.d/ubuntu.sources`). 2. Run `add-apt-repository --pocket proposed`. Accept the prompt. 3. Run `apt policy`. - Expected result: `noble-proposed` is listed. - Actual result: `noble-proposed` is not listed. This might be related to LP: #2060331, but since I'm not sure how it works, I'm filing a new bug here. ProblemType: Bug DistroRelease: Ubuntu 24.04 Package: software-properties-common 0.99.46 ProcVersionSignature: Ubuntu 6.5.0-27.28~22.04.1-generic 6.5.13 Uname: Linux 6.5.0-27-generic x86_64 ApportVersion: 2.28.0-0ubuntu1 Architecture: amd64 CasperMD5CheckResult: unknown CloudSerial: 20240225 Date: Fri Apr 12 18:38:12 2024 PackageArchitecture: all ProcEnviron: PATH=(custom, no user) TERM=xterm SourcePackage: software-properties UpgradeStatus: No upgrade log present (probably fresh install) To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/software-properties/+bug/2061128/+subscriptions -- Mailing list: https://launchpad.net/~touch-packages Post to : touch-packages@lists.launchpad.net Unsubscribe : https://launchpad.net/~touch-packages More help : https://help.launchpad.net/ListHelp
[Touch-packages] [Bug 2058690] [NEW] aa-easyprof: allow mmap and link from easyprof generated profiles
Public bug reported: Currently, an easyprof-generated profile will list the reads with `rk` and the writes as `rwk`. With recent Qt, this breaks because newer Qt versions use hard-linking of temporary files to perform atomic writes. Also, `rk` doesn't allow mmap()'ing shared library for execution. We at UBports are carrying a patch in Ubuntu Touch which changes the read rules to `mrk` and write rules to `mrwkl`, and are upstreaming this patch at [1]. When the MR is merged, I would like this patch to be included in Ubuntu 24.04, so that Ubuntu Touch doesn't have to package AppArmor separately from Ubuntu. If we agree that we want this patch, I can provide an MR on Salsa. [1] https://gitlab.com/apparmor/apparmor/-/merge_requests/1189 ** Affects: apparmor (Ubuntu) Importance: Undecided Status: New -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to apparmor in Ubuntu. https://bugs.launchpad.net/bugs/2058690 Title: aa-easyprof: allow mmap and link from easyprof generated profiles Status in apparmor package in Ubuntu: New Bug description: Currently, an easyprof-generated profile will list the reads with `rk` and the writes as `rwk`. With recent Qt, this breaks because newer Qt versions use hard-linking of temporary files to perform atomic writes. Also, `rk` doesn't allow mmap()'ing shared library for execution. We at UBports are carrying a patch in Ubuntu Touch which changes the read rules to `mrk` and write rules to `mrwkl`, and are upstreaming this patch at [1]. When the MR is merged, I would like this patch to be included in Ubuntu 24.04, so that Ubuntu Touch doesn't have to package AppArmor separately from Ubuntu. If we agree that we want this patch, I can provide an MR on Salsa. [1] https://gitlab.com/apparmor/apparmor/-/merge_requests/1189 To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/apparmor/+bug/2058690/+subscriptions -- Mailing list: https://launchpad.net/~touch-packages Post to : touch-packages@lists.launchpad.net Unsubscribe : https://launchpad.net/~touch-packages More help : https://help.launchpad.net/ListHelp
[Touch-packages] [Bug 1962214] Re: The documentation around NM's 10-globally-managed-devices.conf is inadequate
*** This bug is a duplicate of bug 1951653 *** https://bugs.launchpad.net/bugs/1951653 While the bug #1951653 is solved, it does not change the design of this process. With a quick inspection of repos, NM and livecd-rootfs still ship the file with no explanation, and netplan still place an empty file. So, the heart of this bug (which is documentation, please read the title again) is still not solved. Please de-duplicate this bug. -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to network-manager in Ubuntu. https://bugs.launchpad.net/bugs/1962214 Title: The documentation around NM's 10-globally-managed-devices.conf is inadequate Status in netplan: New Status in network-manager package in Ubuntu: New Bug description: So, we're UBports, porting Ubuntu Touch stack to Ubuntu 20.04. While debugging why NM won't manage the phone's USB network interface, I stumbled upon /usr/lib/NetworkManager/conf.d/10-globally-managed- devices.conf. This file prevents NM from managing ethernet connection, which confuses me since this file also exists on my laptop, yet NM happily manages its ethernet port. This file exists at part of NetworkManager package in Ubuntu without any documentation. And the reason given in the commit that add it [1] does not mention any specific reason why it's added. Only when looking in the log on my laptop do I see that something places the file with the same name in /run/NetworkManager/conf.d/, and requires greping in /usr/lib to find out that the thing is Netplan's generator binary. Now, that file in /run is empty, which requires another round of searching to find out that Netplan places this file when it's configured to use NM as a renderer. With that in mind, I discovered that /etc/netplan/01-network-manager-all.yaml exists on my laptop but not the phone. Now, because 'dpkg -S' returns empty result, I need to search again what places this file, with no avail. Luckily, I happen to have a clone of livecd-rootfs on my laptop, which leads me to this commit [2] which finally reveals the reason why this is done: to prevent systems which installs NM after-the-fact to have NM conflicts with e.g. systemd-networkd. All of these knowledge should not require this much searching plus grepping through _binary_ file. If either my laptop was not running Ubuntu or I didn't have livecd-rootfs cloned, it would be much harder to figure this out. They should be more properly documented, probably both in the /usr/lib/ and /run/ files. Thus, this issue is filled against both Netplan and NetworkManager packages. [1] https://git.launchpad.net/network-manager/commit?id=1ab4db73c1f0db30f3af1845a9c41e3c3952dea1 [2] https://git.launchpad.net/livecd-rootfs/commit/?id=d9ce44d73a0a6d91156bb94e03063d541b0f7579 P.S. Arguably, this behavior might be even wrong. According to https://netplan.io: > Obviously, without configuration, netplan will not do anything. This is not really the expected "not do anything". IMO the NM's behavior should be left at the default, unless e.g. the networkd renderer is used, in which case Netplan will disable NetworkManager to not manage interfaces configured by Netplan. However the reason above of preventing conflict with networkd is a valid one, and my proposal doesn't help with that particular case. To manage notifications about this bug go to: https://bugs.launchpad.net/netplan/+bug/1962214/+subscriptions -- Mailing list: https://launchpad.net/~touch-packages Post to : touch-packages@lists.launchpad.net Unsubscribe : https://launchpad.net/~touch-packages More help : https://help.launchpad.net/ListHelp
[Touch-packages] [Bug 1962214] [NEW] The documentation around NM's 10-globally-managed-devices.conf is inadequate
Public bug reported: So, we're UBports, porting Ubuntu Touch stack to Ubuntu 20.04. While debugging why NM won't manage the phone's USB network interface, I stumbled upon /usr/lib/NetworkManager/conf.d/10-globally-managed- devices.conf. This file prevents NM from managing ethernet connection, which confuses me since this file also exists on my laptop, yet NM happily manages its ethernet port. This file exists at part of NetworkManager package in Ubuntu without any documentation. And the reason given in the commit that add it [1] does not mention any specific reason why it's added. Only when looking in the log on my laptop do I see that something places the file with the same name in /run/NetworkManager/conf.d/, and requires greping in /usr/lib to find out that the thing is Netplan's generator binary. Now, that file in /run is empty, which requires another round of searching to find out that Netplan places this file when it's configured to use NM as a renderer. With that in mind, I discovered that /etc/netplan/01-network-manager-all.yaml exists on my laptop but not the phone. Now, because 'dpkg -S' returns empty result, I need to search again what places this file, with no avail. Luckily, I happen to have a clone of livecd-rootfs on my laptop, which leads me to this commit [2] which finally reveals the reason why this is done: to prevent systems which installs NM after-the-fact to have NM conflicts with e.g. systemd- networkd. All of these knowledge should not require this much searching plus grepping through _binary_ file. If either my laptop was not running Ubuntu or I didn't have livecd-rootfs cloned, it would be much harder to figure this out. They should be more properly documented, probably both in the /usr/lib/ and /run/ files. Thus, this issue is filled against both Netplan and NetworkManager packages. [1] https://git.launchpad.net/network-manager/commit?id=1ab4db73c1f0db30f3af1845a9c41e3c3952dea1 [2] https://git.launchpad.net/livecd-rootfs/commit/?id=d9ce44d73a0a6d91156bb94e03063d541b0f7579 P.S. Arguably, this behavior might be even wrong. According to https://netplan.io: > Obviously, without configuration, netplan will not do anything. This is not really the expected "not do anything". IMO the NM's behavior should be left at the default, unless e.g. the networkd renderer is used, in which case Netplan will disable NetworkManager to not manage interfaces configured by Netplan. However the reason above of preventing conflict with networkd is a valid one, and my proposal doesn't help with that particular case. ** Affects: netplan Importance: Undecided Status: New ** Affects: network-manager (Ubuntu) Importance: Undecided Status: New ** Also affects: network-manager (Ubuntu) Importance: Undecided Status: New -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to network-manager in Ubuntu. https://bugs.launchpad.net/bugs/1962214 Title: The documentation around NM's 10-globally-managed-devices.conf is inadequate Status in netplan: New Status in network-manager package in Ubuntu: New Bug description: So, we're UBports, porting Ubuntu Touch stack to Ubuntu 20.04. While debugging why NM won't manage the phone's USB network interface, I stumbled upon /usr/lib/NetworkManager/conf.d/10-globally-managed- devices.conf. This file prevents NM from managing ethernet connection, which confuses me since this file also exists on my laptop, yet NM happily manages its ethernet port. This file exists at part of NetworkManager package in Ubuntu without any documentation. And the reason given in the commit that add it [1] does not mention any specific reason why it's added. Only when looking in the log on my laptop do I see that something places the file with the same name in /run/NetworkManager/conf.d/, and requires greping in /usr/lib to find out that the thing is Netplan's generator binary. Now, that file in /run is empty, which requires another round of searching to find out that Netplan places this file when it's configured to use NM as a renderer. With that in mind, I discovered that /etc/netplan/01-network-manager-all.yaml exists on my laptop but not the phone. Now, because 'dpkg -S' returns empty result, I need to search again what places this file, with no avail. Luckily, I happen to have a clone of livecd-rootfs on my laptop, which leads me to this commit [2] which finally reveals the reason why this is done: to prevent systems which installs NM after-the-fact to have NM conflicts with e.g. systemd-networkd. All of these knowledge should not require this much searching plus grepping through _binary_ file. If either my laptop was not running Ubuntu or I didn't have livecd-rootfs cloned, it would be much harder to figure this out. They should be more properly documented, probably both in the /usr/lib/ and /run/ files. Thus, this
[Touch-packages] [Bug 1650688] Re: timedatectl set-timezone fails on UC16
Anything else has to be done for this? -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to systemd in Ubuntu. https://bugs.launchpad.net/bugs/1650688 Title: timedatectl set-timezone fails on UC16 Status in Snappy: Triaged Status in systemd package in Ubuntu: Fix Released Status in systemd source package in Bionic: Fix Committed Status in systemd source package in Focal: Fix Committed Status in systemd source package in Hirsute: Won't Fix Status in systemd source package in Impish: Won't Fix Status in systemd source package in Jammy: Fix Released Bug description: SRU === [Impact] * The bug prevents timedated from recognizing and correctly set the system's timezone when running Ubuntu Core 16, 18 and 20. * This causes by timedated fails to take Ubuntu Core's /etc/writable redirection into account. * The recognizing part is fixed by making the code take writable redirection into account. * The set part is fixed by making the code link to the absolute path instead of a relative one. * Currently core snaps worked around the set part by providing a wrapper script which re-create /etc/writable/localtime afterward. However this does not cover DBus users. [Test Plan] * On classics systems: ensure the proposed systemd package is installed. On Ubuntu Core systems: build a new core snap including proposed package, and install it. Replaces timedatectl with timedatectl.real to test skipping the wrapper. (Note that one can simulate core snap's /etc/writable redirection by running this image creation hook [1] on the system.) [1] https://git.launchpad.net/livecd-rootfs/tree/live-build/ubuntu- core/hooks/08-etc-writable.chroot?h=ubuntu/focal * On freshly boot system: query the timezone using `timedatectl`. The timezone should corresponds to `readlink -f /etc/localtime` and does not show `n/a`. * Set a new timezone: `sudo timedatectl set-timezone Asia/Bangkok`. `readlink -f /etc/localtime` should points to an existing file. * Run `sudo systemctl restart systemd-timedated.service`. Then, query the timezone again: `timedatectl`. It should show the previously set timezone and not `n/a`. * Run `sudo systemctl status systemd-timedated.service`. This should show no sign of timedated crashing. [Where problems could occur] * It's possible that the redirection handling code will be sub-par and causes crash. However, it's not likely because the similar pieces of code is in the previous patch since Ubuntu 16.04. * If it does: the patched `get_timezone()` function is used in 2 places: the networkd's DHCP server [3] and the timedated itself. - Networkd is used primarily on servers where NetworkManage is absent. It's possible that this patch causes the user to loss access to the server due to networkd crash when setting up network interfaces, and requires physical access to fix. However, the code path is executed when DHCP is enabled only. I think it's not common for users to have networkd's DHCP server enabled: the feature seems to gear towards desktop users wanting to share internet connection, and in those cases they're more likely to use NetworkManager. - The timedated itself is likely used by the programs that involves in time-related functions. If a crash occur, in the worst case users won't be able to set time or timezone via timedated. However, users should still be able to e.g. set time using `date` or set timezone using /etc/localtime (assuming online guides still consider systems without systemd). Timedated is DBus-activated, and thus a crash should be self-healing. * The set part would also affects the clasic systems. However, I believe nothing else actually rely on /etc/localtime being a relative path, otherwise the /etc/writable redirection would causes even more problem, and would have been reported. [3] Yes, I'm surprised that there's a DHCP server inside systemd codebase. [Other Info] * This is also useful for UBports's Ubuntu Touch. We continue using system-image system where the rootfs is read-only, and thus is affected by this bug similarly to Ubuntu Core. I've tested the Focal version of the package on our (currently in development) Focal Ubuntu Touch image, and the fix works. [Original bug description] On a system running UC16, the file /etc/localtime is a link that points to /etc/writable/localtime. On a freshly installed system, /etc/writable/localtime is a fully- qualified link that points at /usr/share/zoneinfo/UTC. If timedatectl is used to set the timezone to something else, timedated updates the localtime symbolic link with a relative path to the zoneinfo directory, which results in an invalid link. $ sudo timedatectl set-timezone America/Detroit $ sudo timedatectl Local time: Fri 2016-12-16 18:18:49
[Touch-packages] [Bug 1650688] Re: timedatectl set-timezone fails on UC16
Test result on Focal (245.4-4ubuntu3.14): - Normal environment: Tested on my desktop. timedatectl output is correct. Setting the timezone works, and doesn't put the link inside /etc/writable/. - System-image environment (UBports image): timedatectl output is correct. Setting timezone works; readlink -f /etc/localtime points to an existing file. - Ubuntu Core environment: test with snapcore/core20 commit 2d970050. focal-proposed is enabled and src:systemd is pinned in overlay. timedatectl output is correct. Setting timezone works; readlink -f /etc/localtime points to an existing file. Test result on Bionic (237-3ubuntu10.53): - Normal environment: Tested in an LXD container. timedatectl output is correct. Setting the timezone works, and doesn't put the link inside /etc/writable/. - Ubuntu Core environment: test with snapcore/core18 commit b8ad5ed4. bionic-proposed is enabled and src:systemd is pinned in overlay. timedatectl output is correct. Setting timezone works; readlink -f /etc/localtime points to an existing file. - System-image enviroment: We at UBports doesn't have a port of Ubuntu Touch based on Bionic, and as such I cannot test in this environment. Note: in Ubuntu Core environments, timedatectl.real is used to test timedated instead of the wrapper. Note: according to [1], seems like verification-needed* has to be left as-is until another positive testimony appears or the test is done by an SRU verification team member. [1] https://wiki.ubuntu.com/QATeam/PerformingSRUVerification#Updating_the_bug_report -- Oh, BTW, I looked at the autopkgtests failure earlier. One of the failure (can't remember which) was because of an out-of-space error. It seems to be gone by now though. -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to systemd in Ubuntu. https://bugs.launchpad.net/bugs/1650688 Title: timedatectl set-timezone fails on UC16 Status in Snappy: Triaged Status in systemd package in Ubuntu: Fix Released Status in systemd source package in Bionic: Fix Committed Status in systemd source package in Focal: Fix Committed Status in systemd source package in Hirsute: Won't Fix Status in systemd source package in Impish: Won't Fix Status in systemd source package in Jammy: Fix Released Bug description: SRU === [Impact] * The bug prevents timedated from recognizing and correctly set the system's timezone when running Ubuntu Core 16, 18 and 20. * This causes by timedated fails to take Ubuntu Core's /etc/writable redirection into account. * The recognizing part is fixed by making the code take writable redirection into account. * The set part is fixed by making the code link to the absolute path instead of a relative one. * Currently core snaps worked around the set part by providing a wrapper script which re-create /etc/writable/localtime afterward. However this does not cover DBus users. [Test Plan] * On classics systems: ensure the proposed systemd package is installed. On Ubuntu Core systems: build a new core snap including proposed package, and install it. Replaces timedatectl with timedatectl.real to test skipping the wrapper. (Note that one can simulate core snap's /etc/writable redirection by running this image creation hook [1] on the system.) [1] https://git.launchpad.net/livecd-rootfs/tree/live-build/ubuntu- core/hooks/08-etc-writable.chroot?h=ubuntu/focal * On freshly boot system: query the timezone using `timedatectl`. The timezone should corresponds to `readlink -f /etc/localtime` and does not show `n/a`. * Set a new timezone: `sudo timedatectl set-timezone Asia/Bangkok`. `readlink -f /etc/localtime` should points to an existing file. * Run `sudo systemctl restart systemd-timedated.service`. Then, query the timezone again: `timedatectl`. It should show the previously set timezone and not `n/a`. * Run `sudo systemctl status systemd-timedated.service`. This should show no sign of timedated crashing. [Where problems could occur] * It's possible that the redirection handling code will be sub-par and causes crash. However, it's not likely because the similar pieces of code is in the previous patch since Ubuntu 16.04. * If it does: the patched `get_timezone()` function is used in 2 places: the networkd's DHCP server [3] and the timedated itself. - Networkd is used primarily on servers where NetworkManage is absent. It's possible that this patch causes the user to loss access to the server due to networkd crash when setting up network interfaces, and requires physical access to fix. However, the code path is executed when DHCP is enabled only. I think it's not common for users to have networkd's DHCP server enabled: the feature seems to gear towards desktop users wanting to share internet connection, and in those cases they're more likely to use NetworkManager. -
[Touch-packages] [Bug 1650688] Re: timedatectl set-timezone fails on UC16
Now that Jammy series is opened, I've opened another merge proposal on Jammy branch with the same patch as in Focal's. Please take another look; this patch is important for us at UBports, and having the patches in Jammy would be nice because there will be Ubuntu Core 22. The Impish-related section has been removed from the description. Should I also delete the merge proposal for Impish branch? ** Description changed: - Impish feature freeze bug fix (sort of) exception request - = - - I (Ratchanan) would like ubuntu-release to verify if the proposed merge - for Impish qualify as a bug fix per [1]. - - Strictly speaking, as there's no core snap from an interim release, this - issue doesn't directly effect Impish. However, to comply with the SRU - requirement, and to let the patches carry to the 22.04 release, I would - like this to be included in Impish. One of the patch has a small - possibility to create a problem on classic systems, so testing in a - development release is a good idea. - - Note that one can simulate core snap's /etc/writable redirection by - running this image creation hook [2] on the system. - - [1] https://wiki.ubuntu.com/FreezeExceptionProcess#FeatureFreeze_for_bugfix-only_updates - [2] https://git.launchpad.net/livecd-rootfs/tree/live-build/ubuntu-core/hooks/08-etc-writable.chroot?h=ubuntu/focal - - - - SRU === [Impact] - * The bug prevents timedated from recognizing and correctly set the + * The bug prevents timedated from recognizing and correctly set the system's timezone when running Ubuntu Core 16, 18 and 20. - * This causes by timedated fails to take Ubuntu Core's /etc/writable + * This causes by timedated fails to take Ubuntu Core's /etc/writable redirection into account. - * The recognizing part is fixed by making the code take writable + * The recognizing part is fixed by making the code take writable redirection into account. - * The set part is fixed by making the code link to the absolute path + * The set part is fixed by making the code link to the absolute path instead of a relative one. - * Currently core snaps worked around the set part by providing a + * Currently core snaps worked around the set part by providing a wrapper script which re-create /etc/writable/localtime afterward. However this does not cover DBus users. [Test Plan] - * On classics systems: ensure the proposed systemd package is installed. -On Ubuntu Core systems: build a new core snap including proposed package, and install it. Replaces timedatectl with timedatectl.real to test skipping the wrapper. + * On classics systems: ensure the proposed systemd package is installed. + On Ubuntu Core systems: build a new core snap including proposed package, and install it. Replaces timedatectl with timedatectl.real to test skipping the wrapper. - * On freshly boot system: query the timezone using `timedatectl`. The + (Note that one can simulate core snap's /etc/writable redirection by + running this image creation hook [1] on the system.) + + [1] https://git.launchpad.net/livecd-rootfs/tree/live-build/ubuntu- + core/hooks/08-etc-writable.chroot?h=ubuntu/focal + + * On freshly boot system: query the timezone using `timedatectl`. The timezone should corresponds to `readlink -f /etc/localtime` and does not show `n/a`. - * Set a new timezone: `sudo timedatectl set-timezone Asia/Bangkok`. + * Set a new timezone: `sudo timedatectl set-timezone Asia/Bangkok`. `readlink -f /etc/localtime` should points to an existing file. - * Run `sudo systemctl restart systemd-timedated.service`. Then, query + * Run `sudo systemctl restart systemd-timedated.service`. Then, query the timezone again: `timedatectl`. It should show the previously set timezone and not `n/a`. - * Run `sudo systemctl status systemd-timedated.service`. This should + * Run `sudo systemctl status systemd-timedated.service`. This should show no sign of timedated crashing. [Where problems could occur] - * It's possible that the redirection handling code will be sub-par and + * It's possible that the redirection handling code will be sub-par and causes crash. However, it's not likely because the similar pieces of code is in the previous patch since Ubuntu 16.04. - * If it does: the patched `get_timezone()` function is used in 2 + * If it does: the patched `get_timezone()` function is used in 2 places: the networkd's DHCP server [3] and the timedated itself. -- Networkd is used primarily on servers where NetworkManage is + - Networkd is used primarily on servers where NetworkManage is absent. It's possible that this patch causes the user to loss access to the server due to networkd crash when setting up network interfaces, and requires physical access to fix. However, the code path is executed when DHCP is enabled only. I think it's not
[Touch-packages] [Bug 1650688] Re: timedatectl set-timezone fails on UC16
** Also affects: systemd (Ubuntu) Importance: Undecided Status: New -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to systemd in Ubuntu. https://bugs.launchpad.net/bugs/1650688 Title: timedatectl set-timezone fails on UC16 Status in Snappy: Triaged Status in systemd package in Ubuntu: New Bug description: Impish feature freeze bug fix (sort of) exception request = I (Ratchanan) would like ubuntu-release to verify if the proposed merge for Impish qualify as a bug fix per [1]. Strictly speaking, as there's no core snap from an interim release, this issue doesn't directly effect Impish. However, to comply with the SRU requirement, and to let the patches carry to the 22.04 release, I would like this to be included in Impish. One of the patch has a small possibility to create a problem on classic systems, so testing in a development release is a good idea. Note that one can simulate core snap's /etc/writable redirection by running this image creation hook [2] on the system. [1] https://wiki.ubuntu.com/FreezeExceptionProcess#FeatureFreeze_for_bugfix-only_updates [2] https://git.launchpad.net/livecd-rootfs/tree/live-build/ubuntu-core/hooks/08-etc-writable.chroot?h=ubuntu/focal - SRU === [Impact] * The bug prevents timedated from recognizing and correctly set the system's timezone when running Ubuntu Core 16, 18 and 20. * This causes by timedated fails to take Ubuntu Core's /etc/writable redirection into account. * The recognizing part is fixed by making the code take writable redirection into account. * The set part is fixed by making the code link to the absolute path instead of a relative one. * Currently core snaps worked around the set part by providing a wrapper script which re-create /etc/writable/localtime afterward. However this does not cover DBus users. [Test Plan] * On classics systems: ensure the proposed systemd package is installed. On Ubuntu Core systems: build a new core snap including proposed package, and install it. Replaces timedatectl with timedatectl.real to test skipping the wrapper. * On freshly boot system: query the timezone using `timedatectl`. The timezone should corresponds to `readlink -f /etc/localtime` and does not show `n/a`. * Set a new timezone: `sudo timedatectl set-timezone Asia/Bangkok`. `readlink -f /etc/localtime` should points to an existing file. * Run `sudo systemctl restart systemd-timedated.service`. Then, query the timezone again: `timedatectl`. It should show the previously set timezone and not `n/a`. * Run `sudo systemctl status systemd-timedated.service`. This should show no sign of timedated crashing. [Where problems could occur] * It's possible that the redirection handling code will be sub-par and causes crash. However, it's not likely because the similar pieces of code is in the previous patch since Ubuntu 16.04. * If it does: the patched `get_timezone()` function is used in 2 places: the networkd's DHCP server [3] and the timedated itself. - Networkd is used primarily on servers where NetworkManage is absent. It's possible that this patch causes the user to loss access to the server due to networkd crash when setting up network interfaces, and requires physical access to fix. However, the code path is executed when DHCP is enabled only. I think it's not common for users to have networkd's DHCP server enabled: the feature seems to gear towards desktop users wanting to share internet connection, and in those cases they're more likely to use NetworkManager. - The timedated itself is likely used by the programs that involves in time-related functions. If a crash occur, in the worst case users won't be able to set time or timezone via timedated. However, users should still be able to e.g. set time using `date` or set timezone using /etc/localtime (assuming online guides still consider systems without systemd). Timedated is DBus-activated, and thus a crash should be self-healing. * The set part would also affects the clasic systems. However, I believe nothing else actually rely on /etc/localtime being a relative path, otherwise the /etc/writable redirection would causes even more problem, and would have been reported. [3] Yes, I'm surprised that there's a DHCP server inside systemd codebase. [Other Info] * This is also useful for UBports's Ubuntu Touch. We continue using system-image system where the rootfs is read-only, and thus is affected by this bug similarly to Ubuntu Core. I've tested the Focal version of the package on our (currently in development) Focal Ubuntu Touch image, and the fix works. [Original bug description] On a system running UC16, the file /etc/localtime is
[Touch-packages] [Bug 1933880] Re: systemd-logind crash when suspend with nvidia-suspend.service masked, bringing session down with it
** Attachment added: "journalctl --boot --unit systemd-logind.service" https://bugs.launchpad.net/ubuntu/+source/systemd/+bug/1933880/+attachment/5507752/+files/systemd-logind.log -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to systemd in Ubuntu. https://bugs.launchpad.net/bugs/1933880 Title: systemd-logind crash when suspend with nvidia-suspend.service masked, bringing session down with it Status in systemd package in Ubuntu: New Bug description: Steps to reproduce: 1. Run `sudo apt install nvidia-driver-465`. Then, without a need for a restart, run `sudo apt autoremove nvidia-driver-465`. 2. Leaving the terminal open, suspend the machine. Expected behavior: the machine suspend successfully and can be woken up successfully. Actual behavior: the machine doesn't suspend. It either: - hang with no respond other than SysRq+REISUB (or maybe network, but I didn't test), or - return you back to the login screen. Upon logging in, you'll notice that the terminal you opened is gone. Upon further inspection (on a session that doesn't hang), it's been found that X server died with: Fatal server error: [66.422] (EE) systemd-logind disappeared (stopped/restarted?) And checking journal for systemd-logind log, it said: Error during inhibitor-delayed operation (already returned success to client): Unit nvidia-suspend.service is masked. before the new process takes it place. The system is Ubuntu 20.04, X.org session. ProblemType: Bug DistroRelease: Ubuntu 20.04 Package: systemd 245.4-4ubuntu3.7 ProcVersionSignature: Ubuntu 5.11.0-22.23~20.04.1-generic 5.11.21 Uname: Linux 5.11.0-22-generic x86_64 ApportVersion: 2.20.11-0ubuntu27.18 Architecture: amd64 CasperMD5CheckResult: skip CurrentDesktop: ubuntu:GNOME Date: Tue Jun 29 03:34:00 2021 InstallationDate: Installed on 2021-03-15 (105 days ago) InstallationMedia: Ubuntu 20.04.2.0 LTS "Focal Fossa" - Release amd64 (20210209.1) MachineType: LENOVO 82B5 ProcEnviron: TERM=xterm-256color PATH=(custom, no user) XDG_RUNTIME_DIR= LANG=th_TH.UTF-8 SHELL=/bin/bash ProcKernelCmdLine: BOOT_IMAGE=/boot/vmlinuz-5.11.0-22-generic root=UUID=06f2a676-a62c-443a-8bc8-4e0eda4600f4 ro log_buf_len=2M quiet splash vt.handoff=7 SourcePackage: systemd UpgradeStatus: No upgrade log present (probably fresh install) dmi.bios.date: 01/01/2021 dmi.bios.release: 1.31 dmi.bios.vendor: LENOVO dmi.bios.version: EUCN31WW dmi.board.asset.tag: NO Asset Tag dmi.board.name: LNVNB161216 dmi.board.vendor: LENOVO dmi.board.version: SDK0Q55756 WIN dmi.chassis.asset.tag: NO Asset Tag dmi.chassis.type: 10 dmi.chassis.vendor: LENOVO dmi.chassis.version: Lenovo Legion 5 15ARH05 dmi.ec.firmware.release: 1.31 dmi.modalias: dmi:bvnLENOVO:bvrEUCN31WW:bd01/01/2021:br1.31:efr1.31:svnLENOVO:pn82B5:pvrLenovoLegion515ARH05:rvnLENOVO:rnLNVNB161216:rvrSDK0Q55756WIN:cvnLENOVO:ct10:cvrLenovoLegion515ARH05: dmi.product.family: Legion 5 15ARH05 dmi.product.name: 82B5 dmi.product.sku: LENOVO_MT_82B5_BU_idea_FM_Legion 5 15ARH05 dmi.product.version: Lenovo Legion 5 15ARH05 dmi.sys.vendor: LENOVO To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/systemd/+bug/1933880/+subscriptions -- Mailing list: https://launchpad.net/~touch-packages Post to : touch-packages@lists.launchpad.net Unsubscribe : https://launchpad.net/~touch-packages More help : https://help.launchpad.net/ListHelp
[Touch-packages] [Bug 1933880] [NEW] systemd-logind crash when suspend with nvidia-suspend.service masked, bringing session down with it
Public bug reported: Steps to reproduce: 1. Run `sudo apt install nvidia-driver-465`. Then, without a need for a restart, run `sudo apt autoremove nvidia-driver-465`. 2. Leaving the terminal open, suspend the machine. Expected behavior: the machine suspend successfully and can be woken up successfully. Actual behavior: the machine doesn't suspend. It either: - hang with no respond other than SysRq+REISUB (or maybe network, but I didn't test), or - return you back to the login screen. Upon logging in, you'll notice that the terminal you opened is gone. Upon further inspection (on a session that doesn't hang), it's been found that X server died with: Fatal server error: [66.422] (EE) systemd-logind disappeared (stopped/restarted?) And checking journal for systemd-logind log, it said: Error during inhibitor-delayed operation (already returned success to client): Unit nvidia-suspend.service is masked. before the new process takes it place. The system is Ubuntu 20.04, X.org session. ProblemType: Bug DistroRelease: Ubuntu 20.04 Package: systemd 245.4-4ubuntu3.7 ProcVersionSignature: Ubuntu 5.11.0-22.23~20.04.1-generic 5.11.21 Uname: Linux 5.11.0-22-generic x86_64 ApportVersion: 2.20.11-0ubuntu27.18 Architecture: amd64 CasperMD5CheckResult: skip CurrentDesktop: ubuntu:GNOME Date: Tue Jun 29 03:34:00 2021 InstallationDate: Installed on 2021-03-15 (105 days ago) InstallationMedia: Ubuntu 20.04.2.0 LTS "Focal Fossa" - Release amd64 (20210209.1) MachineType: LENOVO 82B5 ProcEnviron: TERM=xterm-256color PATH=(custom, no user) XDG_RUNTIME_DIR= LANG=th_TH.UTF-8 SHELL=/bin/bash ProcKernelCmdLine: BOOT_IMAGE=/boot/vmlinuz-5.11.0-22-generic root=UUID=06f2a676-a62c-443a-8bc8-4e0eda4600f4 ro log_buf_len=2M quiet splash vt.handoff=7 SourcePackage: systemd UpgradeStatus: No upgrade log present (probably fresh install) dmi.bios.date: 01/01/2021 dmi.bios.release: 1.31 dmi.bios.vendor: LENOVO dmi.bios.version: EUCN31WW dmi.board.asset.tag: NO Asset Tag dmi.board.name: LNVNB161216 dmi.board.vendor: LENOVO dmi.board.version: SDK0Q55756 WIN dmi.chassis.asset.tag: NO Asset Tag dmi.chassis.type: 10 dmi.chassis.vendor: LENOVO dmi.chassis.version: Lenovo Legion 5 15ARH05 dmi.ec.firmware.release: 1.31 dmi.modalias: dmi:bvnLENOVO:bvrEUCN31WW:bd01/01/2021:br1.31:efr1.31:svnLENOVO:pn82B5:pvrLenovoLegion515ARH05:rvnLENOVO:rnLNVNB161216:rvrSDK0Q55756WIN:cvnLENOVO:ct10:cvrLenovoLegion515ARH05: dmi.product.family: Legion 5 15ARH05 dmi.product.name: 82B5 dmi.product.sku: LENOVO_MT_82B5_BU_idea_FM_Legion 5 15ARH05 dmi.product.version: Lenovo Legion 5 15ARH05 dmi.sys.vendor: LENOVO ** Affects: systemd (Ubuntu) Importance: Undecided Status: New ** Tags: amd64 apport-bug focal ** Attachment added: "Xorg.0.log" https://bugs.launchpad.net/bugs/1933880/+attachment/5507736/+files/Xorg.0.log -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to systemd in Ubuntu. https://bugs.launchpad.net/bugs/1933880 Title: systemd-logind crash when suspend with nvidia-suspend.service masked, bringing session down with it Status in systemd package in Ubuntu: New Bug description: Steps to reproduce: 1. Run `sudo apt install nvidia-driver-465`. Then, without a need for a restart, run `sudo apt autoremove nvidia-driver-465`. 2. Leaving the terminal open, suspend the machine. Expected behavior: the machine suspend successfully and can be woken up successfully. Actual behavior: the machine doesn't suspend. It either: - hang with no respond other than SysRq+REISUB (or maybe network, but I didn't test), or - return you back to the login screen. Upon logging in, you'll notice that the terminal you opened is gone. Upon further inspection (on a session that doesn't hang), it's been found that X server died with: Fatal server error: [66.422] (EE) systemd-logind disappeared (stopped/restarted?) And checking journal for systemd-logind log, it said: Error during inhibitor-delayed operation (already returned success to client): Unit nvidia-suspend.service is masked. before the new process takes it place. The system is Ubuntu 20.04, X.org session. ProblemType: Bug DistroRelease: Ubuntu 20.04 Package: systemd 245.4-4ubuntu3.7 ProcVersionSignature: Ubuntu 5.11.0-22.23~20.04.1-generic 5.11.21 Uname: Linux 5.11.0-22-generic x86_64 ApportVersion: 2.20.11-0ubuntu27.18 Architecture: amd64 CasperMD5CheckResult: skip CurrentDesktop: ubuntu:GNOME Date: Tue Jun 29 03:34:00 2021 InstallationDate: Installed on 2021-03-15 (105 days ago) InstallationMedia: Ubuntu 20.04.2.0 LTS "Focal Fossa" - Release amd64 (20210209.1) MachineType: LENOVO 82B5 ProcEnviron: TERM=xterm-256color PATH=(custom, no user) XDG_RUNTIME_DIR= LANG=th_TH.UTF-8 SHELL=/bin/bash ProcKernelCmdLine: BOOT_IMAGE=/boot/vmlinuz-5.11.0-22-generic root=UUID=06f2a676-a62c-443a-8bc8-4e0eda4600f4 ro log_buf_len=2M quiet splash
[Touch-packages] [Bug 1848865] Re: Spurious "key_press_event" when focus on entry widget using LANG=th_TH.UTF-8
Sorry for the delay. This has fallen through the crack. I've, in fact, reduced the testing environment down to just X, twm, and xterm and the bug is still reproducible. Also, I've tested it on Fedora 31 XFCE spin, and cannot reproduce it. -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to gtk+3.0 in Ubuntu. https://bugs.launchpad.net/bugs/1848865 Title: Spurious "key_press_event" when focus on entry widget using LANG=th_TH.UTF-8 Status in GTK+: Fix Released Status in gtk+3.0 package in Ubuntu: New Bug description: GTK+3 will emit spurious "key_press_event" if the focus is currently on "GtkEntry" and the locale is set to th_TH.UTF-8. This issue seems to disappear if the locale is set to something else (tested with C.UTF-8 and en_US.UTF-8), and the presence of iBus and gnome-shell affects this. Step to reproduce: 1. Boot into Xubuntu. Install package "language-pack-th" (for locale) and "libgtk-3-dev" for compiling demo program. 2. Download & compile the demo program "gtk3-entry-keyboard-event" attached in this bug. (The program is licensed under MIT.) 3. Run the program with LANG=th_TH.UTF-8. The window will contain an input box on top and a button on the bottom. 4. Click in the input box, then press a key on the keyboard. The program will print one line for each "key_press_event" delivered to the window, with keyval and hardware_keycode. Expected result: only a single line is printed. For example for "a": "window: 0x0061 0x0026" Actual result: - With LANG=th_TH.UTF-8, two lines are printed. The first line is the above line, while the second line has both values as zero: "window: 00 00" - If, instead, the locale is LANG=C.UTF-8, the program will print only one line as expected. - If iBus is installed and enabled, then 2 lines are printed with both lines containing the same code, no matter which locale it runs under. - If this same program is run in Gnome-based Ubuntu session, then only one line is printed no matter which locale it runs under. This program is tested on Fedora and Manjaro with the correct result. Thus, this issue is Ubuntu-specific. I've tested it on Ubuntu 19.10 with pretty much the same result, except the iBus case is now working correctly. ProblemType: Bug DistroRelease: Ubuntu 18.04 Package: libgtk-3-0 3.22.30-1ubuntu4 ProcVersionSignature: Ubuntu 4.15.0-65.74-generic 4.15.18 Uname: Linux 4.15.0-65-generic x86_64 ApportVersion: 2.20.9-0ubuntu7.7 Architecture: amd64 CurrentDesktop: XFCE Date: Sat Oct 19 18:06:23 2019 InstallationDate: Installed on 2018-05-03 (533 days ago) InstallationMedia: Xubuntu 18.04 LTS "Bionic Beaver" - Release amd64 (20180426) SourcePackage: gtk+3.0 UpgradeStatus: No upgrade log present (probably fresh install) To manage notifications about this bug go to: https://bugs.launchpad.net/gtk/+bug/1848865/+subscriptions -- Mailing list: https://launchpad.net/~touch-packages Post to : touch-packages@lists.launchpad.net Unsubscribe : https://launchpad.net/~touch-packages More help : https://help.launchpad.net/ListHelp
[Touch-packages] [Bug 1848865] Re: Spurious "key_press_event" when focus on entry widget using LANG=th_TH.UTF-8
After mentioning that I cannot reproduce the problem on Fedora and Manjaro, they replied that this is probably the Ubuntu-specific bug and promptly closed the bug. Note that the status from Bug Watcher updater is incorrect. -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to gtk+3.0 in Ubuntu. https://bugs.launchpad.net/bugs/1848865 Title: Spurious "key_press_event" when focus on entry widget using LANG=th_TH.UTF-8 Status in GTK+: Fix Released Status in gtk+3.0 package in Ubuntu: New Bug description: GTK+3 will emit spurious "key_press_event" if the focus is currently on "GtkEntry" and the locale is set to th_TH.UTF-8. This issue seems to disappear if the locale is set to something else (tested with C.UTF-8 and en_US.UTF-8), and the presence of iBus and gnome-shell affects this. Step to reproduce: 1. Boot into Xubuntu. Install package "language-pack-th" (for locale) and "libgtk-3-dev" for compiling demo program. 2. Download & compile the demo program "gtk3-entry-keyboard-event" attached in this bug. (The program is licensed under MIT.) 3. Run the program with LANG=th_TH.UTF-8. The window will contain an input box on top and a button on the bottom. 4. Click in the input box, then press a key on the keyboard. The program will print one line for each "key_press_event" delivered to the window, with keyval and hardware_keycode. Expected result: only a single line is printed. For example for "a": "window: 0x0061 0x0026" Actual result: - With LANG=th_TH.UTF-8, two lines are printed. The first line is the above line, while the second line has both values as zero: "window: 00 00" - If, instead, the locale is LANG=C.UTF-8, the program will print only one line as expected. - If iBus is installed and enabled, then 2 lines are printed with both lines containing the same code, no matter which locale it runs under. - If this same program is run in Gnome-based Ubuntu session, then only one line is printed no matter which locale it runs under. This program is tested on Fedora and Manjaro with the correct result. Thus, this issue is Ubuntu-specific. I've tested it on Ubuntu 19.10 with pretty much the same result, except the iBus case is now working correctly. ProblemType: Bug DistroRelease: Ubuntu 18.04 Package: libgtk-3-0 3.22.30-1ubuntu4 ProcVersionSignature: Ubuntu 4.15.0-65.74-generic 4.15.18 Uname: Linux 4.15.0-65-generic x86_64 ApportVersion: 2.20.9-0ubuntu7.7 Architecture: amd64 CurrentDesktop: XFCE Date: Sat Oct 19 18:06:23 2019 InstallationDate: Installed on 2018-05-03 (533 days ago) InstallationMedia: Xubuntu 18.04 LTS "Bionic Beaver" - Release amd64 (20180426) SourcePackage: gtk+3.0 UpgradeStatus: No upgrade log present (probably fresh install) To manage notifications about this bug go to: https://bugs.launchpad.net/gtk/+bug/1848865/+subscriptions -- Mailing list: https://launchpad.net/~touch-packages Post to : touch-packages@lists.launchpad.net Unsubscribe : https://launchpad.net/~touch-packages More help : https://help.launchpad.net/ListHelp
[Touch-packages] [Bug 1848865] Re: Spurious "key_press_event" when focus on entry widget using LANG=th_TH.UTF-8
** Bug watch added: gitlab.gnome.org/GNOME/gtk/issues #2216 https://gitlab.gnome.org/GNOME/gtk/issues/2216 ** Also affects: gtk via https://gitlab.gnome.org/GNOME/gtk/issues/2216 Importance: Unknown Status: Unknown -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to gtk+3.0 in Ubuntu. https://bugs.launchpad.net/bugs/1848865 Title: Spurious "key_press_event" when focus on entry widget using LANG=th_TH.UTF-8 Status in GTK+: New Status in gtk+3.0 package in Ubuntu: New Bug description: GTK+3 will emit spurious "key_press_event" if the focus is currently on "GtkEntry" and the locale is set to th_TH.UTF-8. This issue seems to disappear if the locale is set to something else (tested with C.UTF-8 and en_US.UTF-8), and the presence of iBus and gnome-shell affects this. Step to reproduce: 1. Boot into Xubuntu. Install package "language-pack-th" (for locale) and "libgtk-3-dev" for compiling demo program. 2. Download & compile the demo program "gtk3-entry-keyboard-event" attached in this bug. (The program is licensed under MIT.) 3. Run the program with LANG=th_TH.UTF-8. The window will contain an input box on top and a button on the bottom. 4. Click in the input box, then press a key on the keyboard. The program will print one line for each "key_press_event" delivered to the window, with keyval and hardware_keycode. Expected result: only a single line is printed. For example for "a": "window: 0x0061 0x0026" Actual result: - With LANG=th_TH.UTF-8, two lines are printed. The first line is the above line, while the second line has both values as zero: "window: 00 00" - If, instead, the locale is LANG=C.UTF-8, the program will print only one line as expected. - If iBus is installed and enabled, then 2 lines are printed with both lines containing the same code, no matter which locale it runs under. - If this same program is run in Gnome-based Ubuntu session, then only one line is printed no matter which locale it runs under. This program is tested on Fedora and Manjaro with the correct result. Thus, this issue is Ubuntu-specific. I've tested it on Ubuntu 19.10 with pretty much the same result, except the iBus case is now working correctly. ProblemType: Bug DistroRelease: Ubuntu 18.04 Package: libgtk-3-0 3.22.30-1ubuntu4 ProcVersionSignature: Ubuntu 4.15.0-65.74-generic 4.15.18 Uname: Linux 4.15.0-65-generic x86_64 ApportVersion: 2.20.9-0ubuntu7.7 Architecture: amd64 CurrentDesktop: XFCE Date: Sat Oct 19 18:06:23 2019 InstallationDate: Installed on 2018-05-03 (533 days ago) InstallationMedia: Xubuntu 18.04 LTS "Bionic Beaver" - Release amd64 (20180426) SourcePackage: gtk+3.0 UpgradeStatus: No upgrade log present (probably fresh install) To manage notifications about this bug go to: https://bugs.launchpad.net/gtk/+bug/1848865/+subscriptions -- Mailing list: https://launchpad.net/~touch-packages Post to : touch-packages@lists.launchpad.net Unsubscribe : https://launchpad.net/~touch-packages More help : https://help.launchpad.net/ListHelp
[Touch-packages] [Bug 1848865] Re: Spurious "key_press_event" when focus on entry widget using LANG=th_TH.UTF-8
I'll report this upstream. However, as I cannot reproduce it on other distros, this might as well be an Ubuntu-specific bug. -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to gtk+3.0 in Ubuntu. https://bugs.launchpad.net/bugs/1848865 Title: Spurious "key_press_event" when focus on entry widget using LANG=th_TH.UTF-8 Status in gtk+3.0 package in Ubuntu: New Bug description: GTK+3 will emit spurious "key_press_event" if the focus is currently on "GtkEntry" and the locale is set to th_TH.UTF-8. This issue seems to disappear if the locale is set to something else (tested with C.UTF-8 and en_US.UTF-8), and the presence of iBus and gnome-shell affects this. Step to reproduce: 1. Boot into Xubuntu. Install package "language-pack-th" (for locale) and "libgtk-3-dev" for compiling demo program. 2. Download & compile the demo program "gtk3-entry-keyboard-event" attached in this bug. (The program is licensed under MIT.) 3. Run the program with LANG=th_TH.UTF-8. The window will contain an input box on top and a button on the bottom. 4. Click in the input box, then press a key on the keyboard. The program will print one line for each "key_press_event" delivered to the window, with keyval and hardware_keycode. Expected result: only a single line is printed. For example for "a": "window: 0x0061 0x0026" Actual result: - With LANG=th_TH.UTF-8, two lines are printed. The first line is the above line, while the second line has both values as zero: "window: 00 00" - If, instead, the locale is LANG=C.UTF-8, the program will print only one line as expected. - If iBus is installed and enabled, then 2 lines are printed with both lines containing the same code, no matter which locale it runs under. - If this same program is run in Gnome-based Ubuntu session, then only one line is printed no matter which locale it runs under. This program is tested on Fedora and Manjaro with the correct result. Thus, this issue is Ubuntu-specific. I've tested it on Ubuntu 19.10 with pretty much the same result, except the iBus case is now working correctly. ProblemType: Bug DistroRelease: Ubuntu 18.04 Package: libgtk-3-0 3.22.30-1ubuntu4 ProcVersionSignature: Ubuntu 4.15.0-65.74-generic 4.15.18 Uname: Linux 4.15.0-65-generic x86_64 ApportVersion: 2.20.9-0ubuntu7.7 Architecture: amd64 CurrentDesktop: XFCE Date: Sat Oct 19 18:06:23 2019 InstallationDate: Installed on 2018-05-03 (533 days ago) InstallationMedia: Xubuntu 18.04 LTS "Bionic Beaver" - Release amd64 (20180426) SourcePackage: gtk+3.0 UpgradeStatus: No upgrade log present (probably fresh install) To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/gtk+3.0/+bug/1848865/+subscriptions -- Mailing list: https://launchpad.net/~touch-packages Post to : touch-packages@lists.launchpad.net Unsubscribe : https://launchpad.net/~touch-packages More help : https://help.launchpad.net/ListHelp
[Touch-packages] [Bug 1848865] [NEW] Spurious "key_press_event" when focus on entry widget using LANG=th_TH.UTF-8
Public bug reported: GTK+3 will emit spurious "key_press_event" if the focus is currently on "GtkEntry" and the locale is set to th_TH.UTF-8. This issue seems to disappear if the locale is set to something else (tested with C.UTF-8 and en_US.UTF-8), and the presence of iBus and gnome-shell affects this. Step to reproduce: 1. Boot into Xubuntu. Install package "language-pack-th" (for locale) and "libgtk-3-dev" for compiling demo program. 2. Download & compile the demo program "gtk3-entry-keyboard-event" attached in this bug. (The program is licensed under MIT.) 3. Run the program with LANG=th_TH.UTF-8. The window will contain an input box on top and a button on the bottom. 4. Click in the input box, then press a key on the keyboard. The program will print one line for each "key_press_event" delivered to the window, with keyval and hardware_keycode. Expected result: only a single line is printed. For example for "a": "window: 0x0061 0x0026" Actual result: - With LANG=th_TH.UTF-8, two lines are printed. The first line is the above line, while the second line has both values as zero: "window: 00 00" - If, instead, the locale is LANG=C.UTF-8, the program will print only one line as expected. - If iBus is installed and enabled, then 2 lines are printed with both lines containing the same code, no matter which locale it runs under. - If this same program is run in Gnome-based Ubuntu session, then only one line is printed no matter which locale it runs under. This program is tested on Fedora and Manjaro with the correct result. Thus, this issue is Ubuntu-specific. I've tested it on Ubuntu 19.10 with pretty much the same result, except the iBus case is now working correctly. ProblemType: Bug DistroRelease: Ubuntu 18.04 Package: libgtk-3-0 3.22.30-1ubuntu4 ProcVersionSignature: Ubuntu 4.15.0-65.74-generic 4.15.18 Uname: Linux 4.15.0-65-generic x86_64 ApportVersion: 2.20.9-0ubuntu7.7 Architecture: amd64 CurrentDesktop: XFCE Date: Sat Oct 19 18:06:23 2019 InstallationDate: Installed on 2018-05-03 (533 days ago) InstallationMedia: Xubuntu 18.04 LTS "Bionic Beaver" - Release amd64 (20180426) SourcePackage: gtk+3.0 UpgradeStatus: No upgrade log present (probably fresh install) ** Affects: gtk+3.0 (Ubuntu) Importance: Undecided Status: New ** Tags: amd64 apport-bug bionic ** Attachment added: "The demo program demonstrating the bug." https://bugs.launchpad.net/bugs/1848865/+attachment/5298410/+files/gtk3-entry-keyboard-event.c -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to gtk+3.0 in Ubuntu. https://bugs.launchpad.net/bugs/1848865 Title: Spurious "key_press_event" when focus on entry widget using LANG=th_TH.UTF-8 Status in gtk+3.0 package in Ubuntu: New Bug description: GTK+3 will emit spurious "key_press_event" if the focus is currently on "GtkEntry" and the locale is set to th_TH.UTF-8. This issue seems to disappear if the locale is set to something else (tested with C.UTF-8 and en_US.UTF-8), and the presence of iBus and gnome-shell affects this. Step to reproduce: 1. Boot into Xubuntu. Install package "language-pack-th" (for locale) and "libgtk-3-dev" for compiling demo program. 2. Download & compile the demo program "gtk3-entry-keyboard-event" attached in this bug. (The program is licensed under MIT.) 3. Run the program with LANG=th_TH.UTF-8. The window will contain an input box on top and a button on the bottom. 4. Click in the input box, then press a key on the keyboard. The program will print one line for each "key_press_event" delivered to the window, with keyval and hardware_keycode. Expected result: only a single line is printed. For example for "a": "window: 0x0061 0x0026" Actual result: - With LANG=th_TH.UTF-8, two lines are printed. The first line is the above line, while the second line has both values as zero: "window: 00 00" - If, instead, the locale is LANG=C.UTF-8, the program will print only one line as expected. - If iBus is installed and enabled, then 2 lines are printed with both lines containing the same code, no matter which locale it runs under. - If this same program is run in Gnome-based Ubuntu session, then only one line is printed no matter which locale it runs under. This program is tested on Fedora and Manjaro with the correct result. Thus, this issue is Ubuntu-specific. I've tested it on Ubuntu 19.10 with pretty much the same result, except the iBus case is now working correctly. ProblemType: Bug DistroRelease: Ubuntu 18.04 Package: libgtk-3-0 3.22.30-1ubuntu4 ProcVersionSignature: Ubuntu 4.15.0-65.74-generic 4.15.18 Uname: Linux 4.15.0-65-generic x86_64 ApportVersion: 2.20.9-0ubuntu7.7 Architecture: amd64 CurrentDesktop: XFCE Date: Sat Oct 19 18:06:23 2019 InstallationDate: Installed on 2018-05-03 (533 days ago) InstallationMedia: Xubuntu 18.04 LTS "Bionic
[Touch-packages] [Bug 1689299] Re: ssh-agent systemd user service failed to start, trying to set environment in Upstart way.
Colin, could you please SRU this fix to Zesty as well? -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to openssh in Ubuntu. https://bugs.launchpad.net/bugs/1689299 Title: ssh-agent systemd user service failed to start, trying to set environment in Upstart way. Status in openssh package in Ubuntu: Fix Committed Bug description: "systemctl --user status ssh-agent.service" give me the following info: agent-launch[11327]: initctl: Name "com.ubuntu.Upstart" does not exist As I'm running Systemd session instead of Upstart one, it shouldn't try to run initctl. So, I take a look at /usr/lib/openssh/agent- launcher. And this is what's in the file: if type initctl >/dev/null 2>&1; then initctl set-env --global SSH_AUTH_SOCK=$S fi So, the script checks if Upstart is installed, but doesn't actually check if the current session is Upstart session or not. It has to check if $UPSTART_SESSION is defined or not. $ lsb_release -a LSB Version: core-9.20160110ubuntu5-amd64:core-9.20160110ubuntu5-noarch:printing-9.20160110ubuntu5-amd64:printing-9.20160110ubuntu5-noarch:security-9.20160110ubuntu5-amd64:security-9.20160110ubuntu5-noarch Distributor ID: Ubuntu Description: Ubuntu 17.04 Release: 17.04 Codename: zesty $ LANG=C apt policy openssh-client openssh-client: Installed: 1:7.4p1-10 Candidate: 1:7.4p1-10 Version table: *** 1:7.4p1-10 500 500 http://th.archive.ubuntu.com/ubuntu zesty/main amd64 Packages 100 /var/lib/dpkg/status ProblemType: Bug DistroRelease: Ubuntu 17.04 Package: openssh-client 1:7.4p1-10 ProcVersionSignature: Ubuntu 4.10.0-20.22-generic 4.10.8 Uname: Linux 4.10.0-20-generic x86_64 ApportVersion: 2.20.4-0ubuntu4 Architecture: amd64 CurrentDesktop: Unity:Unity7 Date: Mon May 8 17:51:09 2017 InstallationDate: Installed on 2013-04-23 (1475 days ago) InstallationMedia: Ubuntu 13.04 "Raring Ringtail" - Alpha amd64 (20130402.1) RelatedPackageVersions: ssh-askpass N/A libpam-sshN/A keychain N/A ssh-askpass-gnome 1:7.4p1-10 SSHClientVersion: OpenSSH_7.4p1 Ubuntu-10, OpenSSL 1.0.2g 1 Mar 2016 SourcePackage: openssh UpgradeStatus: Upgraded to zesty on 2017-04-29 (9 days ago) To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/openssh/+bug/1689299/+subscriptions -- Mailing list: https://launchpad.net/~touch-packages Post to : touch-packages@lists.launchpad.net Unsubscribe : https://launchpad.net/~touch-packages More help : https://help.launchpad.net/ListHelp
[Touch-packages] [Bug 1689299] [NEW] ssh-agent systemd user service failed to start, trying to set environment in Upstart way.
Public bug reported: "systemctl --user status ssh-agent.service" give me the following info: agent-launch[11327]: initctl: Name "com.ubuntu.Upstart" does not exist As I'm running Systemd session instead of Upstart one, it shouldn't try to run initctl. So, I take a look at /usr/lib/openssh/agent-launcher. And this is what's in the file: if type initctl >/dev/null 2>&1; then initctl set-env --global SSH_AUTH_SOCK=$S fi So, the script checks if Upstart is installed, but doesn't actually check if the current session is Upstart session or not. It has to check if $UPSTART_SESSION is defined or not. $ lsb_release -a LSB Version: core-9.20160110ubuntu5-amd64:core-9.20160110ubuntu5-noarch:printing-9.20160110ubuntu5-amd64:printing-9.20160110ubuntu5-noarch:security-9.20160110ubuntu5-amd64:security-9.20160110ubuntu5-noarch Distributor ID: Ubuntu Description:Ubuntu 17.04 Release:17.04 Codename: zesty $ LANG=C apt policy openssh-client openssh-client: Installed: 1:7.4p1-10 Candidate: 1:7.4p1-10 Version table: *** 1:7.4p1-10 500 500 http://th.archive.ubuntu.com/ubuntu zesty/main amd64 Packages 100 /var/lib/dpkg/status ProblemType: Bug DistroRelease: Ubuntu 17.04 Package: openssh-client 1:7.4p1-10 ProcVersionSignature: Ubuntu 4.10.0-20.22-generic 4.10.8 Uname: Linux 4.10.0-20-generic x86_64 ApportVersion: 2.20.4-0ubuntu4 Architecture: amd64 CurrentDesktop: Unity:Unity7 Date: Mon May 8 17:51:09 2017 InstallationDate: Installed on 2013-04-23 (1475 days ago) InstallationMedia: Ubuntu 13.04 "Raring Ringtail" - Alpha amd64 (20130402.1) RelatedPackageVersions: ssh-askpass N/A libpam-sshN/A keychain N/A ssh-askpass-gnome 1:7.4p1-10 SSHClientVersion: OpenSSH_7.4p1 Ubuntu-10, OpenSSL 1.0.2g 1 Mar 2016 SourcePackage: openssh UpgradeStatus: Upgraded to zesty on 2017-04-29 (9 days ago) ** Affects: openssh (Ubuntu) Importance: Undecided Status: New ** Tags: amd64 apport-bug zesty -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to openssh in Ubuntu. https://bugs.launchpad.net/bugs/1689299 Title: ssh-agent systemd user service failed to start, trying to set environment in Upstart way. Status in openssh package in Ubuntu: New Bug description: "systemctl --user status ssh-agent.service" give me the following info: agent-launch[11327]: initctl: Name "com.ubuntu.Upstart" does not exist As I'm running Systemd session instead of Upstart one, it shouldn't try to run initctl. So, I take a look at /usr/lib/openssh/agent- launcher. And this is what's in the file: if type initctl >/dev/null 2>&1; then initctl set-env --global SSH_AUTH_SOCK=$S fi So, the script checks if Upstart is installed, but doesn't actually check if the current session is Upstart session or not. It has to check if $UPSTART_SESSION is defined or not. $ lsb_release -a LSB Version: core-9.20160110ubuntu5-amd64:core-9.20160110ubuntu5-noarch:printing-9.20160110ubuntu5-amd64:printing-9.20160110ubuntu5-noarch:security-9.20160110ubuntu5-amd64:security-9.20160110ubuntu5-noarch Distributor ID: Ubuntu Description: Ubuntu 17.04 Release: 17.04 Codename: zesty $ LANG=C apt policy openssh-client openssh-client: Installed: 1:7.4p1-10 Candidate: 1:7.4p1-10 Version table: *** 1:7.4p1-10 500 500 http://th.archive.ubuntu.com/ubuntu zesty/main amd64 Packages 100 /var/lib/dpkg/status ProblemType: Bug DistroRelease: Ubuntu 17.04 Package: openssh-client 1:7.4p1-10 ProcVersionSignature: Ubuntu 4.10.0-20.22-generic 4.10.8 Uname: Linux 4.10.0-20-generic x86_64 ApportVersion: 2.20.4-0ubuntu4 Architecture: amd64 CurrentDesktop: Unity:Unity7 Date: Mon May 8 17:51:09 2017 InstallationDate: Installed on 2013-04-23 (1475 days ago) InstallationMedia: Ubuntu 13.04 "Raring Ringtail" - Alpha amd64 (20130402.1) RelatedPackageVersions: ssh-askpass N/A libpam-sshN/A keychain N/A ssh-askpass-gnome 1:7.4p1-10 SSHClientVersion: OpenSSH_7.4p1 Ubuntu-10, OpenSSL 1.0.2g 1 Mar 2016 SourcePackage: openssh UpgradeStatus: Upgraded to zesty on 2017-04-29 (9 days ago) To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/openssh/+bug/1689299/+subscriptions -- Mailing list: https://launchpad.net/~touch-packages Post to : touch-packages@lists.launchpad.net Unsubscribe : https://launchpad.net/~touch-packages More help : https://help.launchpad.net/ListHelp
[Touch-packages] [Bug 1656851] [NEW] Memory leak in EvalInstructionSelection.
Public bug reported:
QV4::EvalInstructionSelection::compile(bool generateUnitData) in
src/qml/compiler/qv4isel_p.cpp, line 369-370:
if ((unit->data == nullptr) && (do_save || generateUnitData))
unit->data = jsGenerator->generateUnit();
Above this line, I see that do_save is always true. So, unit->data is always
generated, regardless of the value of generateUnitData.
However, by tracing to callers of this function, it's revealed that
callers expect unit->data to be NULL if generateUnitData is false. And
by this assumption, they overwrite this variable. As it's allocated by
malloc, this chunk of memory gets lost. For example, this is a trace
from running unity8-dash under Valgrind:
==4360== 601,072 bytes in 96 blocks are definitely lost in loss record 1,495 of
1,495
==4360==at 0x483E358: malloc (vg_replace_malloc.c:296)
==4360==by 0x4C3120B:
QV4::Compiler::JSUnitGenerator::generateUnit(QV4::Compiler::JSUnitGenerator::GeneratorOption)
(qv4compiler.cpp:221)
==4360==by 0x4C3CB8F: QV4::EvalInstructionSelection::compile(bool)
(qv4isel_p.cpp:370)
==4360==by 0x4C6BE0F: QQmlTypeCompiler::compile() (qqmltypecompiler.cpp:223)
==4360==by 0x4D4AD7D: QQmlTypeData::compile() (qqmltypeloader.cpp:2359)
(the rest is omitted as they're not relavant.)
QQmlTypeCompiler::compile() in src/qml/compiler/qqmltypecompiler.cpp, line
201-233:
// Compile JS binding expressions and signal handlers
if (!document->javaScriptCompilationUnit) {
(line 203-222 omitted)
document->javaScriptCompilationUnit = isel->compile(/*generated unit
data*/false);
}
// Generate QML compiled type data structures
QmlIR::QmlUnitGenerator qmlGenerator;
QV4::CompiledData::Unit *qmlUnit = qmlGenerator.generate(*document);
Q_ASSERT(document->javaScriptCompilationUnit);
// The js unit owns the data and will free the qml unit.
document->javaScriptCompilationUnit->data = qmlUnit;
You'll see that isel->compile() is called with generateUnitData set to
false. Then, document->javaScriptCompilationUnit->data is set to the
value of qmlUnit. This means that the old value of
document->javaScriptCompilationUnit->data is overwritten without being
freed properly.
I think the solution is to free this memory at the end of
EvalInstructionSelection::compile() if generateUnitData is false.
All codes come from qtdeclarative-opensource-src version
5.4.1-1ubuntu11~overlay9~1 from stable-phone-overlay.
** Affects: qtdeclarative-opensource-src (Ubuntu)
Importance: Undecided
Status: New
--
You received this bug notification because you are a member of Ubuntu
Touch seeded packages, which is subscribed to qtdeclarative-opensource-
src in Ubuntu.
https://bugs.launchpad.net/bugs/1656851
Title:
Memory leak in EvalInstructionSelection.
Status in qtdeclarative-opensource-src package in Ubuntu:
New
Bug description:
QV4::EvalInstructionSelection::compile(bool generateUnitData) in
src/qml/compiler/qv4isel_p.cpp, line 369-370:
if ((unit->data == nullptr) && (do_save || generateUnitData))
unit->data = jsGenerator->generateUnit();
Above this line, I see that do_save is always true. So, unit->data is always
generated, regardless of the value of generateUnitData.
However, by tracing to callers of this function, it's revealed that
callers expect unit->data to be NULL if generateUnitData is false. And
by this assumption, they overwrite this variable. As it's allocated by
malloc, this chunk of memory gets lost. For example, this is a trace
from running unity8-dash under Valgrind:
==4360== 601,072 bytes in 96 blocks are definitely lost in loss record 1,495
of 1,495
==4360==at 0x483E358: malloc (vg_replace_malloc.c:296)
==4360==by 0x4C3120B:
QV4::Compiler::JSUnitGenerator::generateUnit(QV4::Compiler::JSUnitGenerator::GeneratorOption)
(qv4compiler.cpp:221)
==4360==by 0x4C3CB8F: QV4::EvalInstructionSelection::compile(bool)
(qv4isel_p.cpp:370)
==4360==by 0x4C6BE0F: QQmlTypeCompiler::compile()
(qqmltypecompiler.cpp:223)
==4360==by 0x4D4AD7D: QQmlTypeData::compile() (qqmltypeloader.cpp:2359)
(the rest is omitted as they're not relavant.)
QQmlTypeCompiler::compile() in src/qml/compiler/qqmltypecompiler.cpp, line
201-233:
// Compile JS binding expressions and signal handlers
if (!document->javaScriptCompilationUnit) {
(line 203-222 omitted)
document->javaScriptCompilationUnit = isel->compile(/*generated unit
data*/false);
}
// Generate QML compiled type data structures
QmlIR::QmlUnitGenerator qmlGenerator;
QV4::CompiledData::Unit *qmlUnit = qmlGenerator.generate(*document);
Q_ASSERT(document->javaScriptCompilationUnit);
// The js unit owns the data and will free the qml unit.
document->javaScriptCompilationUnit->data = qmlUnit;
You'll see that isel->compile() is called with generateUnitData set to
false. Then,
[Touch-packages] [Bug 1495974] Re: [android] renogotiation of pixel formats is not supported, leading to potential stride/pixelformat issues
Dear everyone in this bug, This seems to also happen in Fairphone 2 in the client context. Could anyone explain more about this bug if this bug is talking about the client or the server? -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to mir in Ubuntu. https://bugs.launchpad.net/bugs/1495974 Title: [android] renogotiation of pixel formats is not supported, leading to potential stride/pixelformat issues Status in Mir: Triaged Status in mir package in Ubuntu: Confirmed Bug description: Some drivers will call android's perform hook with: NATIVE_WINDOW_SET_BUFFERS_FORMAT. In the case that the pixel formats are the same depth, we accommodate this by just setting the format to the newly-requested format. (ie, mir_pixel_format_rgbx_ to mir_pixel_format_rgba_ is accommodated, as no reallocation is needed). However, we've encountered a device that will try to set the format to HAL_PIXEL_FORMAT_RGB_888 when mir has selected HAL_PIXEL_FORMAT_RGBX_. Since we're going from a 32 bit format to a 24 bit format, the stride information becomes incorrect. To manage notifications about this bug go to: https://bugs.launchpad.net/mir/+bug/1495974/+subscriptions -- Mailing list: https://launchpad.net/~touch-packages Post to : touch-packages@lists.launchpad.net Unsubscribe : https://launchpad.net/~touch-packages More help : https://help.launchpad.net/ListHelp
[Touch-packages] [Bug 1653373] [NEW] [gst-hybris] Support COLOR_QCOM_FormatYVU420SemiPlanar32mMultiView color format.
Public bug reported: >From gstamc-constants.h: /* NV12 but with stride and plane heights aligned to 32, Stores two images, * one after the other in top-bottom layout */ COLOR_QCOM_FormatYVU420SemiPlanar32mMultiView = 0x7fa30c05, Support is added by adding android-gst color format mapping, using the same code as COLOR_QCOM_FormatYUV420SemiPlanar to handle software conversion (as in gstamc.c) and adding special handling for multi-view nature of the format (as in gstamcvideodec.c). Adding support for this format fixes video playback on Fairphone 2. gst-plugins-bad1.0 version 1.8.2-1ubuntu0.1~overlay1 ** Affects: gst-plugins-bad1.0 (Ubuntu) Importance: Undecided Status: New ** Patch added: "androidmedia-support-COLOR_QCOM_FormatYVU420SemiPlanar32mMultiView.patch" https://bugs.launchpad.net/bugs/1653373/+attachment/4798604/+files/androidmedia-support-COLOR_QCOM_FormatYVU420SemiPlanar32mMultiView.patch -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to gst-plugins-bad1.0 in Ubuntu. https://bugs.launchpad.net/bugs/1653373 Title: [gst-hybris] Support COLOR_QCOM_FormatYVU420SemiPlanar32mMultiView color format. Status in gst-plugins-bad1.0 package in Ubuntu: New Bug description: From gstamc-constants.h: /* NV12 but with stride and plane heights aligned to 32, Stores two images, * one after the other in top-bottom layout */ COLOR_QCOM_FormatYVU420SemiPlanar32mMultiView = 0x7fa30c05, Support is added by adding android-gst color format mapping, using the same code as COLOR_QCOM_FormatYUV420SemiPlanar to handle software conversion (as in gstamc.c) and adding special handling for multi-view nature of the format (as in gstamcvideodec.c). Adding support for this format fixes video playback on Fairphone 2. gst-plugins-bad1.0 version 1.8.2-1ubuntu0.1~overlay1 To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/gst-plugins-bad1.0/+bug/1653373/+subscriptions -- Mailing list: https://launchpad.net/~touch-packages Post to : touch-packages@lists.launchpad.net Unsubscribe : https://launchpad.net/~touch-packages More help : https://help.launchpad.net/ListHelp
[Touch-packages] [Bug 1603520] [NEW] mm linker's soinfo::call_constructors: don't assume that soname_ is available.
Public bug reported:
I'm porting Ubuntu Touch to Samsung Galaxy Tab 2 7.0. As I investigate
unity-system-compositor crash, it's found that the crash happens in mm's linker
(https://git.launchpad.net/~libhybris-maintainers/libhybris/+git/libhybris/tree/hybris/common/mm/linker.cpp#n2180),
where soname_ is NULL. Digging further, it's found that the library it's
trying to load (gralloc.omap4.so) indeed doesn't have soname in it.
My current workaround is applying this patch so that it checks whether soname_
is NULL:
--- a/hybris/common/mm/linker.cpp
+++ b/hybris/common/mm/linker.cpp
@@ -2177,7 +2177,7 @@
return;
}
- if (strcmp(soname_, "libc.so") == 0) {
+ if (soname_ && strcmp(soname_, "libc.so") == 0) {
DEBUG("HYBRIS: => Skipping libc.so\n");
return;
}
Although I'm not sure if this is the correct fix. So, I open this bug so that
the people familiar with the codebase can put in the correct fix.
Channel: ubuntu-touch/rc-proposed/ubuntu
Ubuntu build description: 20160715.1
Result from a gdb session:
phablet@ubuntu-phablet:~/deb$ sudo HYBRIS_LOGGING_LEVEL=debug gdb
unity-system-compositor
GNU gdb (Ubuntu 7.9-1ubuntu1) 7.9
Copyright (C) 2015 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law. Type "show copying"
and "show warranty" for details.
This GDB was configured as "arm-linux-gnueabihf".
Type "show configuration" for configuration details.
For bug reporting instructions, please see:
[Touch-packages] [Bug 1594420] [NEW] Ship an Upstart job to set boot completion property in Android container
Public bug reported: In some device, there init.rc has something like "on property:init.svc.bootanim=stopped" or "on property:sys.boot_completed=1". Its purpose is to run something when the system has finished booting. As far as I know, and with a conversation with ogra, there's nothing in Ubuntu touch that set these properties. So, I think it'd be good to ship an Upstart job to set these properties so that devices' init.rc that depends on these properties will "just works". I've attached an Upstart job that could do that. The job (which is a task) will set those properties when Lightdm emits "desktop-session- start" event, which I believe to be the best places to set these properties. ** Affects: lxc-android-config (Ubuntu) Importance: Undecided Status: New ** Attachment added: "android-set-boot-completion-property.conf" https://bugs.launchpad.net/bugs/1594420/+attachment/4687318/+files/android-set-boot-completion-property.conf -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to lxc-android-config in Ubuntu. https://bugs.launchpad.net/bugs/1594420 Title: Ship an Upstart job to set boot completion property in Android container Status in lxc-android-config package in Ubuntu: New Bug description: In some device, there init.rc has something like "on property:init.svc.bootanim=stopped" or "on property:sys.boot_completed=1". Its purpose is to run something when the system has finished booting. As far as I know, and with a conversation with ogra, there's nothing in Ubuntu touch that set these properties. So, I think it'd be good to ship an Upstart job to set these properties so that devices' init.rc that depends on these properties will "just works". I've attached an Upstart job that could do that. The job (which is a task) will set those properties when Lightdm emits "desktop-session- start" event, which I believe to be the best places to set these properties. To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/lxc-android-config/+bug/1594420/+subscriptions -- Mailing list: https://launchpad.net/~touch-packages Post to : touch-packages@lists.launchpad.net Unsubscribe : https://launchpad.net/~touch-packages More help : https://help.launchpad.net/ListHelp
[Touch-packages] [Bug 1583099] [NEW] [phone] Brightness slider should show value set by user or auto-brightness, not screen's actual brightness.
Public bug reported: Reproduce step #1: 1. For convenience, set screen time out to 30 seconds. 2. Pull power indicator down, then set brightness to some value above the lowest. 3. Leave the indicator open and wait until screen dims the brightness. Expected result: Brightness slider stays at value set in step 2. Actual result: Brightness slider jumps (actually, slides smoothly) to lowest value. Reproduce step #2: 1. Set brightness to the maximum. 2. Slide brightness slider to minimum quickly. Expected result: Slider sticks to the finger. Actual result: The slider seems to jumps around. And it seems like it tries to jump to actual screen brightness. This seems to related to LP #1562898 Device: LG L 90 Dual (my port) Ubuntu image: 20160514-020303 (This come from build description because somehow UBPorts stop sending image number.) ** Affects: indicator-power (Ubuntu) Importance: Undecided Status: New ** Summary changed: - [phone] Brightness slider should show value set by user or auto-brightness, not screen's actual brightsens. + [phone] Brightness slider should show value set by user or auto-brightness, not screen's actualbrightness. ** Summary changed: - [phone] Brightness slider should show value set by user or auto-brightness, not screen's actualbrightness. + [phone] Brightness slider should show value set by user or auto-brightness, not screen's actual brightness. -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to indicator-power in Ubuntu. https://bugs.launchpad.net/bugs/1583099 Title: [phone] Brightness slider should show value set by user or auto- brightness, not screen's actual brightness. Status in indicator-power package in Ubuntu: New Bug description: Reproduce step #1: 1. For convenience, set screen time out to 30 seconds. 2. Pull power indicator down, then set brightness to some value above the lowest. 3. Leave the indicator open and wait until screen dims the brightness. Expected result: Brightness slider stays at value set in step 2. Actual result: Brightness slider jumps (actually, slides smoothly) to lowest value. Reproduce step #2: 1. Set brightness to the maximum. 2. Slide brightness slider to minimum quickly. Expected result: Slider sticks to the finger. Actual result: The slider seems to jumps around. And it seems like it tries to jump to actual screen brightness. This seems to related to LP #1562898 Device: LG L 90 Dual (my port) Ubuntu image: 20160514-020303 (This come from build description because somehow UBPorts stop sending image number.) To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/indicator-power/+bug/1583099/+subscriptions -- Mailing list: https://launchpad.net/~touch-packages Post to : touch-packages@lists.launchpad.net Unsubscribe : https://launchpad.net/~touch-packages More help : https://help.launchpad.net/ListHelp
[Touch-packages] [Bug 1577123] Re: Video resolution changes by itself after suspend and resume the app
** Description changed: When camera app is suspended and resume, the recorded video's resolution will change to 1280x720 without being reflected on the app. Steps to reproduce: 1.Open camera app, switch to video mode, and change resolution (swipe up and press "HD" button) to 1080p. 2.Record some video. 3.Go to launcher, then open camera app again. Camera app should stay in video mode. 4.Verify that resolution in the app is still 1080p. 5.Record another video. 6.Connect to a computer, then check resolution of just-recorded videos. Expected result: Both videos' resolution is 1920x1080. Actual result: First video's resolution is 1920x1080, but second video's resolution is 1280x720. + + Device: LG L90 Dual (my port) + Image version: 20160429 on rc-proposed (equivalent to mako's build 428 on rc-proposed) -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to camera-app in Ubuntu. https://bugs.launchpad.net/bugs/1577123 Title: Video resolution changes by itself after suspend and resume the app Status in camera-app package in Ubuntu: New Bug description: When camera app is suspended and resume, the recorded video's resolution will change to 1280x720 without being reflected on the app. Steps to reproduce: 1.Open camera app, switch to video mode, and change resolution (swipe up and press "HD" button) to 1080p. 2.Record some video. 3.Go to launcher, then open camera app again. Camera app should stay in video mode. 4.Verify that resolution in the app is still 1080p. 5.Record another video. 6.Connect to a computer, then check resolution of just-recorded videos. Expected result: Both videos' resolution is 1920x1080. Actual result: First video's resolution is 1920x1080, but second video's resolution is 1280x720. Device: LG L90 Dual (my port) Image version: 20160429 on rc-proposed (equivalent to mako's build 428 on rc-proposed) To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/camera-app/+bug/1577123/+subscriptions -- Mailing list: https://launchpad.net/~touch-packages Post to : touch-packages@lists.launchpad.net Unsubscribe : https://launchpad.net/~touch-packages More help : https://help.launchpad.net/ListHelp
[Touch-packages] [Bug 1577123] [NEW] Video resolution changes by itself after suspend and resume the app
Public bug reported: When camera app is suspended and resume, the recorded video's resolution will change to 1280x720 without being reflected on the app. Steps to reproduce: 1.Open camera app, switch to video mode, and change resolution (swipe up and press "HD" button) to 1080p. 2.Record some video. 3.Go to launcher, then open camera app again. Camera app should stay in video mode. 4.Verify that resolution in the app is still 1080p. 5.Record another video. 6.Connect to a computer, then check resolution of just-recorded videos. Expected result: Both videos' resolution is 1920x1080. Actual result: First video's resolution is 1920x1080, but second video's resolution is 1280x720. ** Affects: camera-app (Ubuntu) Importance: Undecided Status: New -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to camera-app in Ubuntu. https://bugs.launchpad.net/bugs/1577123 Title: Video resolution changes by itself after suspend and resume the app Status in camera-app package in Ubuntu: New Bug description: When camera app is suspended and resume, the recorded video's resolution will change to 1280x720 without being reflected on the app. Steps to reproduce: 1.Open camera app, switch to video mode, and change resolution (swipe up and press "HD" button) to 1080p. 2.Record some video. 3.Go to launcher, then open camera app again. Camera app should stay in video mode. 4.Verify that resolution in the app is still 1080p. 5.Record another video. 6.Connect to a computer, then check resolution of just-recorded videos. Expected result: Both videos' resolution is 1920x1080. Actual result: First video's resolution is 1920x1080, but second video's resolution is 1280x720. To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/camera-app/+bug/1577123/+subscriptions -- Mailing list: https://launchpad.net/~touch-packages Post to : touch-packages@lists.launchpad.net Unsubscribe : https://launchpad.net/~touch-packages More help : https://help.launchpad.net/ListHelp
[Touch-packages] [Bug 1547864] Re: libinput doesn't handle EV_KEY event with a value of 255 (BUTTON_CANCLED), to support virtual Android home buttons
Well, it isn't actually a virtual buttons. It's part of touchscreen but is outside of screen display area, like in this picture: http://www.mxphone.net/wordpress/wp-content/uploads/2014/03/L90-front-bottom-500x281.jpg -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to mir in Ubuntu. https://bugs.launchpad.net/bugs/1547864 Title: libinput doesn't handle EV_KEY event with a value of 255 (BUTTON_CANCLED), to support virtual Android home buttons Status in Mir: New Status in libinput package in Ubuntu: New Status in mir package in Ubuntu: New Bug description: I port Ubuntu Touch to LG L90 Dual. When I press a button below the screen (it's the touch button and is part of the touch screen), then slide the finger up, a letter will repeatedly appear in any text field selected (for instance, if the button is a menu button, letter 'e' will appear repeatedly). Using evtest with the touch screen device, I can see what happened: Event: time 75.605520, type 1 (EV_KEY), code 139 (KEY_MENU), value 1 Event: time 75.605525, -- EV_SYN Event: time 75.707065, type 1 (EV_KEY), code 139 (KEY_MENU), value 255 (See the full log here: http://paste.ubuntu.com/15112114/) When I place the finger down, touch screen will send an event with type 1 (EV_KEY), code 139 (KEY_MENU), and value 1, indicating that the button is placed. And when I move the finger away from the button, touch screen will send an event with type 1 (EV_KEY), code 139 (KEY_MENU), and value 255. Digging in kernel code reveals that this is defined as "BUTTON_CANCLED". Looking in libevent code, it seems that it always assume that anything that is not 0 will be considered as pressed, which makes it looks like the button is hold. To manage notifications about this bug go to: https://bugs.launchpad.net/mir/+bug/1547864/+subscriptions -- Mailing list: https://launchpad.net/~touch-packages Post to : touch-packages@lists.launchpad.net Unsubscribe : https://launchpad.net/~touch-packages More help : https://help.launchpad.net/ListHelp
[Touch-packages] [Bug 1530384] Re: Touchscreen stop working on LG L90 Dual
I confirmed that the rule that add ID_INPUT_TOUCHSCREEN=1 to the device makes touchscreen works. Meanwhile, I'll ship the rule with my device tarball. Glad to know that you found the cause. -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to mir in Ubuntu. https://bugs.launchpad.net/bugs/1530384 Title: Touchscreen stop working on LG L90 Dual Status in Canonical System Image: Confirmed Status in udev: Confirmed Status in mir package in Ubuntu: New Bug description: I ports Ubuntu touch to LG L90 Dual. When I upgraded my device from 20151218.1 to 20151221 (channel rc-proposed), the touchscreen stopped working. A discussion in IRC with @anpok_ suggesting that it may come from changing input system to udev/libevdev/libinput. The following udevadm output is most likely from the Touch Screen: $ udevadm test-builtin input_id /devices/virtual/input/input0/ calling: test-builtin === trie on-disk === tool version: 219 file size: 6711498 bytes header size 80 bytes strings1721914 bytes nodes 4989504 bytes Load module index Network interface NamePolicy= disabled on kernel command line, ignoring. timestamp of '/etc/systemd/network' changed timestamp of '/usr/lib/systemd/network' changed Parsed configuration file /lib/systemd/network/99-default.link Parsed configuration file /etc/systemd/network/00-rmnet-kernel.link Created link configuration context. ID_INPUT=1 capabilities/ev raw kernel attribute: b capabilities/ev decoded bit map: bit0: 000B capabilities/abs raw kernel attribute: 6718000 0 capabilities/abs decoded bit map: bit0: bit 32: 06718000 capabilities/rel raw kernel attribute: 0 capabilities/rel decoded bit map: capabilities/key raw kernel attribute: 400 0 0 200 0 1000 4800 10 0 1000 0 capabilities/key decoded bit map: bit0: bit 32: 1000 bit 64: bit 96: 0010 bit 128: 4800 bit 160: 1000 bit 192: bit 224: 0200 bit 256: bit 288: bit 320: 0400 properties raw kernel attribute: 0 properties decoded bit map: test_key: checking bit block 0 for any keys; found=0 test_key: checking bit block 32 for any keys; found=1 test_key: checking bit block 64 for any keys; found=1 test_key: checking bit block 96 for any keys; found=1 test_key: checking bit block 128 for any keys; found=1 test_key: checking bit block 160 for any keys; found=1 test_key: checking bit block 192 for any keys; found=1 test_key: checking bit block 224 for any keys; found=1 ID_INPUT_KEY=1 Unload module index Unloaded link configuration context. The driver claims that is provides the multi touch axis touch major, touch minor, tracking id, x, y, tool type and slot id. So apart from missing properties like DIRECT it seems to be a normal touch screen, but udev clearly does not detect it properly. -- The other devices are probably not the touchscreen... $ udevadm test-builtin input_id /devices/gpio_keys.70/input/input2/ calling: test-builtin === trie on-disk === tool version: 219 file size: 6711498 bytes header size 80 bytes strings1721914 bytes nodes 4989504 bytes Load module index Network interface NamePolicy= disabled on kernel command line, ignoring. timestamp of '/etc/systemd/network' changed timestamp of '/usr/lib/systemd/network' changed Parsed configuration file /lib/systemd/network/99-default.link Parsed configuration file /etc/systemd/network/00-rmnet-kernel.link Created link configuration context. ID_INPUT=1 capabilities/ev raw kernel attribute: 3 capabilities/ev decoded bit map: bit0: 0003 capabilities/abs raw kernel attribute: 0 capabilities/abs decoded bit map: capabilities/rel raw kernel attribute: 0 capabilities/rel decoded bit map: capabilities/key raw kernel attribute: 400 0 0 0 c0040 0 0 0 capabilities/key decoded bit map: bit0: bit 32: bit 64: bit 96: 000C0040 bit 128: bit 160: bit 192: bit 224: 0400 properties raw kernel attribute: 0 properties decoded bit map: test_key: checking bit block 0 for any keys; found=0 test_key: checking bit block 32 for any keys; found=0 test_key: checking bit block 64 for any keys; found=0 test_key: checking bit block 96 for any keys; found=1 test_key: checking bit block 128 for any keys; found=1 test_key: checking bit block 160 for any keys; found=1 test_key: checking bit block 192 for any keys; found=1 test_key: checking bit block 224 for any keys; found=1 ID_INPUT_KEY=1 Unload module index Unloaded
[Touch-packages] [Bug 1530384] Re: Touchscreen stop working on LG L90 Dual
** Attachment added: "unity-system-compositor.log" https://bugs.launchpad.net/canonical-devices-system-image/+bug/1530384/+attachment/4542630/+files/unity-system-compositor.log -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to mir in Ubuntu. https://bugs.launchpad.net/bugs/1530384 Title: Touchscreen stop working on LG L90 Dual Status in Canonical System Image: New Status in mir package in Ubuntu: New Bug description: I ports Ubuntu touch to LG L90 Dual. When I upgraded my device from 20151218.1 to 20151221 (channel rc-proposed), the touchscreen stopped working. A discussion in IRC with @anpok_ suggesting that it may come from changing input system to libevent. $ udevadm test-builtin input_id /devices/gpio_keys.70/input/input2/ calling: test-builtin === trie on-disk === tool version: 219 file size: 6711498 bytes header size 80 bytes strings1721914 bytes nodes 4989504 bytes Load module index Network interface NamePolicy= disabled on kernel command line, ignoring. timestamp of '/etc/systemd/network' changed timestamp of '/usr/lib/systemd/network' changed Parsed configuration file /lib/systemd/network/99-default.link Parsed configuration file /etc/systemd/network/00-rmnet-kernel.link Created link configuration context. ID_INPUT=1 capabilities/ev raw kernel attribute: 3 capabilities/ev decoded bit map: bit0: 0003 capabilities/abs raw kernel attribute: 0 capabilities/abs decoded bit map: capabilities/rel raw kernel attribute: 0 capabilities/rel decoded bit map: capabilities/key raw kernel attribute: 400 0 0 0 c0040 0 0 0 capabilities/key decoded bit map: bit0: bit 32: bit 64: bit 96: 000C0040 bit 128: bit 160: bit 192: bit 224: 0400 properties raw kernel attribute: 0 properties decoded bit map: test_key: checking bit block 0 for any keys; found=0 test_key: checking bit block 32 for any keys; found=0 test_key: checking bit block 64 for any keys; found=0 test_key: checking bit block 96 for any keys; found=1 test_key: checking bit block 128 for any keys; found=1 test_key: checking bit block 160 for any keys; found=1 test_key: checking bit block 192 for any keys; found=1 test_key: checking bit block 224 for any keys; found=1 ID_INPUT_KEY=1 Unload module index Unloaded link configuration context. $ udevadm test-builtin input_id /devices/virtual/input/input0/ calling: test-builtin === trie on-disk === tool version: 219 file size: 6711498 bytes header size 80 bytes strings1721914 bytes nodes 4989504 bytes Load module index Network interface NamePolicy= disabled on kernel command line, ignoring. timestamp of '/etc/systemd/network' changed timestamp of '/usr/lib/systemd/network' changed Parsed configuration file /lib/systemd/network/99-default.link Parsed configuration file /etc/systemd/network/00-rmnet-kernel.link Created link configuration context. ID_INPUT=1 capabilities/ev raw kernel attribute: b capabilities/ev decoded bit map: bit0: 000B capabilities/abs raw kernel attribute: 6718000 0 capabilities/abs decoded bit map: bit0: bit 32: 06718000 capabilities/rel raw kernel attribute: 0 capabilities/rel decoded bit map: capabilities/key raw kernel attribute: 400 0 0 200 0 1000 4800 10 0 1000 0 capabilities/key decoded bit map: bit0: bit 32: 1000 bit 64: bit 96: 0010 bit 128: 4800 bit 160: 1000 bit 192: bit 224: 0200 bit 256: bit 288: bit 320: 0400 properties raw kernel attribute: 0 properties decoded bit map: test_key: checking bit block 0 for any keys; found=0 test_key: checking bit block 32 for any keys; found=1 test_key: checking bit block 64 for any keys; found=1 test_key: checking bit block 96 for any keys; found=1 test_key: checking bit block 128 for any keys; found=1 test_key: checking bit block 160 for any keys; found=1 test_key: checking bit block 192 for any keys; found=1 test_key: checking bit block 224 for any keys; found=1 ID_INPUT_KEY=1 Unload module index Unloaded link configuration context. $ udevadm test-builtin input_id /devices/virtual/input/input1/ calling: test-builtin === trie on-disk === tool version: 219 file size: 6711498 bytes header size 80 bytes strings1721914 bytes nodes 4989504 bytes Load module index Network interface NamePolicy= disabled on kernel command line, ignoring. timestamp of '/etc/systemd/network' changed timestamp of '/usr/lib/systemd/network' changed Parsed
[Touch-packages] [Bug 1530384] [NEW] Touchscreen stop working on LG L90 Dual
Public bug reported: I ports Ubuntu touch to LG L90 Dual. When I upgraded my device from 20151218.1 to 20151221 (channel rc-proposed), the touchscreen stopped working. A discussion in IRC with @anpok_ suggesting that it may come from changing input system to libevent. $ udevadm test-builtin input_id /devices/gpio_keys.70/input/input2/ calling: test-builtin === trie on-disk === tool version: 219 file size: 6711498 bytes header size 80 bytes strings1721914 bytes nodes 4989504 bytes Load module index Network interface NamePolicy= disabled on kernel command line, ignoring. timestamp of '/etc/systemd/network' changed timestamp of '/usr/lib/systemd/network' changed Parsed configuration file /lib/systemd/network/99-default.link Parsed configuration file /etc/systemd/network/00-rmnet-kernel.link Created link configuration context. ID_INPUT=1 capabilities/ev raw kernel attribute: 3 capabilities/ev decoded bit map: bit0: 0003 capabilities/abs raw kernel attribute: 0 capabilities/abs decoded bit map: capabilities/rel raw kernel attribute: 0 capabilities/rel decoded bit map: capabilities/key raw kernel attribute: 400 0 0 0 c0040 0 0 0 capabilities/key decoded bit map: bit0: bit 32: bit 64: bit 96: 000C0040 bit 128: bit 160: bit 192: bit 224: 0400 properties raw kernel attribute: 0 properties decoded bit map: test_key: checking bit block 0 for any keys; found=0 test_key: checking bit block 32 for any keys; found=0 test_key: checking bit block 64 for any keys; found=0 test_key: checking bit block 96 for any keys; found=1 test_key: checking bit block 128 for any keys; found=1 test_key: checking bit block 160 for any keys; found=1 test_key: checking bit block 192 for any keys; found=1 test_key: checking bit block 224 for any keys; found=1 ID_INPUT_KEY=1 Unload module index Unloaded link configuration context. $ udevadm test-builtin input_id /devices/virtual/input/input0/ calling: test-builtin === trie on-disk === tool version: 219 file size: 6711498 bytes header size 80 bytes strings1721914 bytes nodes 4989504 bytes Load module index Network interface NamePolicy= disabled on kernel command line, ignoring. timestamp of '/etc/systemd/network' changed timestamp of '/usr/lib/systemd/network' changed Parsed configuration file /lib/systemd/network/99-default.link Parsed configuration file /etc/systemd/network/00-rmnet-kernel.link Created link configuration context. ID_INPUT=1 capabilities/ev raw kernel attribute: b capabilities/ev decoded bit map: bit0: 000B capabilities/abs raw kernel attribute: 6718000 0 capabilities/abs decoded bit map: bit0: bit 32: 06718000 capabilities/rel raw kernel attribute: 0 capabilities/rel decoded bit map: capabilities/key raw kernel attribute: 400 0 0 200 0 1000 4800 10 0 1000 0 capabilities/key decoded bit map: bit0: bit 32: 1000 bit 64: bit 96: 0010 bit 128: 4800 bit 160: 1000 bit 192: bit 224: 0200 bit 256: bit 288: bit 320: 0400 properties raw kernel attribute: 0 properties decoded bit map: test_key: checking bit block 0 for any keys; found=0 test_key: checking bit block 32 for any keys; found=1 test_key: checking bit block 64 for any keys; found=1 test_key: checking bit block 96 for any keys; found=1 test_key: checking bit block 128 for any keys; found=1 test_key: checking bit block 160 for any keys; found=1 test_key: checking bit block 192 for any keys; found=1 test_key: checking bit block 224 for any keys; found=1 ID_INPUT_KEY=1 Unload module index Unloaded link configuration context. $ udevadm test-builtin input_id /devices/virtual/input/input1/ calling: test-builtin === trie on-disk === tool version: 219 file size: 6711498 bytes header size 80 bytes strings1721914 bytes nodes 4989504 bytes Load module index Network interface NamePolicy= disabled on kernel command line, ignoring. timestamp of '/etc/systemd/network' changed timestamp of '/usr/lib/systemd/network' changed Parsed configuration file /lib/systemd/network/99-default.link Parsed configuration file /etc/systemd/network/00-rmnet-kernel.link Created link configuration context. ID_INPUT=1 capabilities/ev raw kernel attribute: 3 capabilities/ev decoded bit map: bit0: 0003 capabilities/abs raw kernel attribute: 0 capabilities/abs decoded bit map: capabilities/rel raw kernel attribute: 0 capabilities/rel decoded bit map: capabilities/key raw kernel attribute: 10 0 0 0 capabilities/key decoded bit map: bit0: bit 32: bit 64: bit 96: 0010 properties raw kernel attribute: 10 properties decoded bit map: bit0: 0010 test_key: checking bit block 0 for any
[Touch-packages] [Bug 1460752] Re: Can't read Thai character.
Excuse me @jibel, why do you think this is critical? -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to ubuntu-touch-meta in Ubuntu. https://bugs.launchpad.net/bugs/1460752 Title: Can't read Thai character. Status in Canonical System Image: Fix Committed Status in ubuntu-touch-meta package in Ubuntu: Fix Committed Status in webbrowser-app package in Ubuntu: Invalid Status in ubuntu-touch-meta package in Ubuntu RTM: Fix Released Bug description: Step to reproduce: Use browser on the phone, go to http://www.alanwood.net/unicode/thai.html Expected result:Thai character is readable. See "Readable Thai character.png" What happens:They're unreadable. See "Unreadable Thai character.png" Version: Ubuntu Touch 15.10 channel devel-proposed image revision 211 Device: LG L90 Dual (I'm doing a port) To manage notifications about this bug go to: https://bugs.launchpad.net/canonical-devices-system-image/+bug/1460752/+subscriptions -- Mailing list: https://launchpad.net/~touch-packages Post to : touch-packages@lists.launchpad.net Unsubscribe : https://launchpad.net/~touch-packages More help : https://help.launchpad.net/ListHelp
[Touch-packages] [Bug 1460752] Re: Can't read Thai character.
Ok. Installed those packages and now I can read Thai text. -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to ubuntu-touch-meta in Ubuntu. https://bugs.launchpad.net/bugs/1460752 Title: Can't read Thai character. Status in ubuntu-touch-meta package in Ubuntu: In Progress Status in webbrowser-app package in Ubuntu: Invalid Status in ubuntu-touch-meta package in Ubuntu RTM: In Progress Bug description: Step to reproduce: Use browser on the phone, go to http://www.alanwood.net/unicode/thai.html Expected result:Thai character is readable. See "Readable Thai character.png" What happens:They're unreadable. See "Unreadable Thai character.png" Version: Ubuntu Touch 15.10 channel devel-proposed image revision 211 Device: LG L90 Dual (I'm doing a port) To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/ubuntu-touch-meta/+bug/1460752/+subscriptions -- Mailing list: https://launchpad.net/~touch-packages Post to : touch-packages@lists.launchpad.net Unsubscribe : https://launchpad.net/~touch-packages More help : https://help.launchpad.net/ListHelp
[Touch-packages] [Bug 1460752] Re: Can't read Thai character.
@Lukasz Sorry for the long delay. I've talked with Thai font maintainer (Theppitak Karoonboonyanan), he has recommend me to include the following: -UI font: fonts-tlwg-waree -San Serif font: fonts-tlwg-garuda and fonts-tlwg-laksaman -Serif font: fonts-tlwg-kinnari -Monospace font: fonts-tlwg-typo -Handwriting font: fonts-tlwg-purisa (optionnal) Can you tell me how to test these things? -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to ubuntu-touch-meta in Ubuntu. https://bugs.launchpad.net/bugs/1460752 Title: Can't read Thai character. Status in ubuntu-touch-meta package in Ubuntu: In Progress Status in webbrowser-app package in Ubuntu: Invalid Status in ubuntu-touch-meta package in Ubuntu RTM: In Progress Bug description: Step to reproduce: Use browser on the phone, go to http://www.alanwood.net/unicode/thai.html Expected result:Thai character is readable. See "Readable Thai character.png" What happens:They're unreadable. See "Unreadable Thai character.png" Version: Ubuntu Touch 15.10 channel devel-proposed image revision 211 Device: LG L90 Dual (I'm doing a port) To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/ubuntu-touch-meta/+bug/1460752/+subscriptions -- Mailing list: https://launchpad.net/~touch-packages Post to : touch-packages@lists.launchpad.net Unsubscribe : https://launchpad.net/~touch-packages More help : https://help.launchpad.net/ListHelp
[Touch-packages] [Bug 1460752] Re: Can't read Thai character.
I think not all are required. Probably only 1 (or maybe 2, each for serif and sans-serif) would be enough, and that should be default font using to render Thai text on desktop. I'll take a look at my Ubuntu computer to see which font is used when I get home. -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to ubuntu-touch-meta in Ubuntu. https://bugs.launchpad.net/bugs/1460752 Title: Can't read Thai character. Status in ubuntu-touch-meta package in Ubuntu: In Progress Status in webbrowser-app package in Ubuntu: Invalid Status in ubuntu-touch-meta package in Ubuntu RTM: In Progress Bug description: Step to reproduce: Use browser on the phone, go to http://www.alanwood.net/unicode/thai.html Expected result:Thai character is readable. See "Readable Thai character.png" What happens:They're unreadable. See "Unreadable Thai character.png" Version: Ubuntu Touch 15.10 channel devel-proposed image revision 211 Device: LG L90 Dual (I'm doing a port) To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/ubuntu-touch-meta/+bug/1460752/+subscriptions -- Mailing list: https://launchpad.net/~touch-packages Post to : touch-packages@lists.launchpad.net Unsubscribe : https://launchpad.net/~touch-packages More help : https://help.launchpad.net/ListHelp
[Touch-packages] [Bug 1460752] Re: Can't read Thai character.
So, ubuntu-touch-meta guys, could you please consider adding Thai fonts in Ubuntu Touch? -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to ubuntu-touch-meta in Ubuntu. https://bugs.launchpad.net/bugs/1460752 Title: Can't read Thai character. Status in ubuntu-touch-meta package in Ubuntu: Confirmed Status in webbrowser-app package in Ubuntu: Invalid Status in ubuntu-touch-meta package in Ubuntu RTM: Confirmed Bug description: Step to reproduce: Use browser on the phone, go to http://www.alanwood.net/unicode/thai.html Expected result:Thai character is readable. See Readable Thai character.png What happens:They're unreadable. See Unreadable Thai character.png Version: Ubuntu Touch 15.10 channel devel-proposed image revision 211 Device: LG L90 Dual (I'm doing a port) To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/ubuntu-touch-meta/+bug/1460752/+subscriptions -- Mailing list: https://launchpad.net/~touch-packages Post to : touch-packages@lists.launchpad.net Unsubscribe : https://launchpad.net/~touch-packages More help : https://help.launchpad.net/ListHelp
[Touch-packages] [Bug 1460752] Re: Can't read Thai character.
This seems to be missing fonts issue. Maybe this isn't a bug in webbrowser-app? -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to webbrowser-app in Ubuntu. https://bugs.launchpad.net/bugs/1460752 Title: Can't read Thai character. Status in webbrowser-app package in Ubuntu: Confirmed Bug description: Step to reproduce: Use browser on the phone, go to http://www.alanwood.net/unicode/thai.html Expected result:Thai character is readable. See Readable Thai character.png What happens:They're unreadable. See Unreadable Thai character.png Version: Ubuntu Touch 15.10 channel devel-proposed image revision 211 Device: LG L90 Dual (I'm doing a port) To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/webbrowser-app/+bug/1460752/+subscriptions -- Mailing list: https://launchpad.net/~touch-packages Post to : touch-packages@lists.launchpad.net Unsubscribe : https://launchpad.net/~touch-packages More help : https://help.launchpad.net/ListHelp
[Touch-packages] [Bug 1460752] [NEW] Can't read Thai character.
Public bug reported: Step to reproduce: Use browser on the phone, go to http://www.alanwood.net/unicode/thai.html Expected result:Thai character is readable. See Readable Thai character.png What happens:They're unreadable. See Unreadable Thai character.png Version: Ubuntu Touch 15.10 channel devel-proposed image revision 211 Device: LG L90 Dual (I'm doing a port) ** Affects: webbrowser-app (Ubuntu) Importance: Undecided Status: New ** Attachment added: Readable Thai chracter.png https://bugs.launchpad.net/bugs/1460752/+attachment/4408162/+files/Readable%20Thai%20chracter.png -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to webbrowser-app in Ubuntu. https://bugs.launchpad.net/bugs/1460752 Title: Can't read Thai character. Status in webbrowser-app package in Ubuntu: New Bug description: Step to reproduce: Use browser on the phone, go to http://www.alanwood.net/unicode/thai.html Expected result:Thai character is readable. See Readable Thai character.png What happens:They're unreadable. See Unreadable Thai character.png Version: Ubuntu Touch 15.10 channel devel-proposed image revision 211 Device: LG L90 Dual (I'm doing a port) To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/webbrowser-app/+bug/1460752/+subscriptions -- Mailing list: https://launchpad.net/~touch-packages Post to : touch-packages@lists.launchpad.net Unsubscribe : https://launchpad.net/~touch-packages More help : https://help.launchpad.net/ListHelp
[Touch-packages] [Bug 1460752] Re: Can't read Thai character.
** Attachment added: Unreadable Thai character.png https://bugs.launchpad.net/ubuntu/+source/webbrowser-app/+bug/1460752/+attachment/4408163/+files/Unreadable%20Thai%20character.png -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to webbrowser-app in Ubuntu. https://bugs.launchpad.net/bugs/1460752 Title: Can't read Thai character. Status in webbrowser-app package in Ubuntu: New Bug description: Step to reproduce: Use browser on the phone, go to http://www.alanwood.net/unicode/thai.html Expected result:Thai character is readable. See Readable Thai character.png What happens:They're unreadable. See Unreadable Thai character.png Version: Ubuntu Touch 15.10 channel devel-proposed image revision 211 Device: LG L90 Dual (I'm doing a port) To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/webbrowser-app/+bug/1460752/+subscriptions -- Mailing list: https://launchpad.net/~touch-packages Post to : touch-packages@lists.launchpad.net Unsubscribe : https://launchpad.net/~touch-packages More help : https://help.launchpad.net/ListHelp
[Touch-packages] [Bug 1452386] [NEW] [gst-hybris] Support COLOR_QCOM_FormatYVU420SemiPlanar32m color format.
Public bug reported: COLOR_QCOM_FormatYVU420SemiPlanar32m is essentially GST_VIDEO_FORMAT_NV12, but with stride and plane heights aligned to 32. Adding support is as simple as adding android-gst color format mapping, and using same code as COLOR_QCOM_FormatYUV420SemiPlanar to handle software conversion. ** Affects: gst-plugins-bad1.0 (Ubuntu) Importance: Undecided Status: New ** Patch added: androidmedia-support-COLOR_QCOM_FormatYVU420SemiPlanar32m-for-hybris.patch https://bugs.launchpad.net/bugs/1452386/+attachment/4392312/+files/androidmedia-support-COLOR_QCOM_FormatYVU420SemiPlanar32m-for-hybris.patch -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to gst-plugins-bad1.0 in Ubuntu. https://bugs.launchpad.net/bugs/1452386 Title: [gst-hybris] Support COLOR_QCOM_FormatYVU420SemiPlanar32m color format. Status in gst-plugins-bad1.0 package in Ubuntu: New Bug description: COLOR_QCOM_FormatYVU420SemiPlanar32m is essentially GST_VIDEO_FORMAT_NV12, but with stride and plane heights aligned to 32. Adding support is as simple as adding android-gst color format mapping, and using same code as COLOR_QCOM_FormatYUV420SemiPlanar to handle software conversion. To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/gst-plugins-bad1.0/+bug/1452386/+subscriptions -- Mailing list: https://launchpad.net/~touch-packages Post to : touch-packages@lists.launchpad.net Unsubscribe : https://launchpad.net/~touch-packages More help : https://help.launchpad.net/ListHelp
[Touch-packages] [Bug 1452386] Re: [gst-hybris] Support COLOR_QCOM_FormatYVU420SemiPlanar32m color format.
It's LG L90 Dual. I'm porting Ubuntu Touch into this device. I've applied this patch with my custom build, and got a success. -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to gst-plugins-bad1.0 in Ubuntu. https://bugs.launchpad.net/bugs/1452386 Title: [gst-hybris] Support COLOR_QCOM_FormatYVU420SemiPlanar32m color format. Status in gst-plugins-bad1.0 package in Ubuntu: New Bug description: COLOR_QCOM_FormatYVU420SemiPlanar32m is essentially GST_VIDEO_FORMAT_NV12, but with stride and plane heights aligned to 32. Adding support is as simple as adding android-gst color format mapping, and using same code as COLOR_QCOM_FormatYUV420SemiPlanar to handle software conversion. To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/gst-plugins-bad1.0/+bug/1452386/+subscriptions -- Mailing list: https://launchpad.net/~touch-packages Post to : touch-packages@lists.launchpad.net Unsubscribe : https://launchpad.net/~touch-packages More help : https://help.launchpad.net/ListHelp
