[Touch-packages] [Bug 1898547] Re: neutron-linuxbridge-agent fails to start with iptables 1.8.5
jdstrand sponsored this to groovy-proposed and autopkgtests have all passed - ~ubuntu-sru - could you please review? -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to iptables in Ubuntu. https://bugs.launchpad.net/bugs/1898547 Title: neutron-linuxbridge-agent fails to start with iptables 1.8.5 Status in Ubuntu on IBM z Systems: Fix Committed Status in iptables package in Ubuntu: Fix Released Status in neutron package in Ubuntu: Invalid Status in iptables source package in Groovy: Fix Committed Status in neutron source package in Groovy: Invalid Status in iptables source package in Hirsute: Fix Released Status in neutron source package in Hirsute: Invalid Bug description: [Impact] With iptables 1.8.5 neutron-linuxbridge-agent fails to properly start. The log file shows many errors like: 2020-10-05 10:20:37.998 551 ERROR neutron.plugins.ml2.drivers.agent._common_agent ; Stdout: ; Stderr: iptables-restore: line 29 failed This can be demonstrated with a simple test case: iptables-restore
[Touch-packages] [Bug 1904075] Re: [NJ5x_NJ7xLU, Realtek ALC293, Speaker, Internal] No sound at all (or so KDE "thinks")
** Package changed: ubuntu => alsa-driver (Ubuntu)
--
You received this bug notification because you are a member of Ubuntu
Touch seeded packages, which is subscribed to alsa-driver in Ubuntu.
https://bugs.launchpad.net/bugs/1904075
Title:
[NJ5x_NJ7xLU, Realtek ALC293, Speaker, Internal] No sound at all (or
so KDE "thinks")
Status in alsa-driver package in Ubuntu:
New
Bug description:
This is an odd one (or so it seems to me)...
Sometimes, after booting, my log is filled with messages similar to:
[ 208.746660] snd_hda_intel :00:1f.3: No response from codec,
resetting bus: last cmd=0x20a3b000
[ 209.758633] snd_hda_intel :00:1f.3: No response from codec,
resetting bus: last cmd=0x20a70740
[ 210.770511] snd_hda_intel :00:1f.3: No response from codec,
resetting bus: last cmd=0x20bf0015
See bug #1886626 ("after login to gnome with snd_hda_intel :00:1f.3: No
response from codec")
for a very similar problem; or at least the same-ish message.
The KDE volume thingy says there are no audio input or output devices.
I cannot configure anything audio-H/w related with KDE.
HOwEVER, whilst generating this bug report with apport-cli(1), the tests it
ran clearly showed
(heard!) the built-in (internal) speakers are working. Intrigued, I tried a
wireless Bluetooth
headset (it also worked), a wireless USB headset (also worked), and a wired
headset (also worked).
So there *is* sound, but KDE thinks there is no H/w... SOMETIMES.
At other times, everything is fine. There is no known pattern here (e.g.,
warm- or cold-boot
does not seem to matter, etc.). And then, just to confuse things further, at
least once the
system booted up in the KDE-no-sound state (complete with module "No response
from codec"),
but later (a few minutes?) began to work; a check of the log (dmesg(1))
showed those messages
had stopped and everything from then on appeared normal. (I'll see if I can
find that incident
in the logs, *IF* I can, I'll attach it later.) That "not"-working to
working does not usually
seem to happen (that one incident may be the only time it has happened?)
I have no idea if, when in the KDE-no-sound state, if I can control the
volume from the computer.
I have also NOT tested the input (microphone(s)) whilst in the KDE-no-sound
state, but I presume
it's like the output (works but KDE doesn't know it?).
It sort-of looks like, at the moment, to me, there is sometime amiss in the
"kernel sound stuff"
which is having a knock-on effect on the "KDE sound stuff". Apologies I
cannot be any more
specific... ;-(
ProblemType: Bug
DistroRelease: Ubuntu 20.04
Package: alsa-base 1.0.25+dfsg-0ubuntu5
ProcVersionSignature: Ubuntu 5.4.0-53.59-generic 5.4.65
Uname: Linux 5.4.0-53-generic x86_64
ApportVersion: 2.20.11-0ubuntu27.12
Architecture: amd64
AudioDevicesInUse:
USERPID ACCESS COMMAND
/dev/snd/controlC0: blf3447 F pulseaudio
CasperMD5CheckResult: skip
CurrentDesktop: KDE
Date: Fri Nov 13 00:30:59 2020
InstallationDate: Installed on 2020-10-19 (24 days ago)
InstallationMedia: Kubuntu 20.04 LTS "Focal Fossa" - Release amd64 (20200423)
PackageArchitecture: all
SourcePackage: alsa-driver
Symptom: audio
Symptom_AlsaPlaybackTest: ALSA playback test through plughw:PCH successful
Symptom_Card: Built-in Audio - HDA Intel PCH
Symptom_DevicesInUse:
USERPID ACCESS COMMAND
/dev/snd/controlC0: blf3447 F pulseaudio
Symptom_Jack: Speaker, Internal
Symptom_PulsePlaybackTest: PulseAudio playback test successful
Symptom_Type: No sound at all
Title: [NJ5x_NJ7xLU, Realtek ALC293, Speaker, Internal] No sound at all
UpgradeStatus: No upgrade log present (probably fresh install)
dmi.bios.date: 07/16/2020
dmi.bios.vendor: INSYDE Corp.
dmi.bios.version: 1.07.03
dmi.board.asset.tag: Tag 12345
dmi.board.name: NJ5x_NJ7xLU
dmi.board.vendor: Notebook
dmi.board.version: Not Applicable
dmi.chassis.asset.tag: No Asset Tag
dmi.chassis.type: 10
dmi.chassis.vendor: No Enclosure
dmi.chassis.version: N/A
dmi.modalias:
dmi:bvnINSYDECorp.:bvr1.07.03:bd07/16/2020:svnNotebook:pnNJ5x_NJ7xLU:pvrNotApplicable:rvnNotebook:rnNJ5x_NJ7xLU:rvrNotApplicable:cvnNoEnclosure:ct10:cvrN/A:
dmi.product.family: Not Applicable
dmi.product.name: NJ5x_NJ7xLU
dmi.product.sku: Not Applicable
dmi.product.version: Not Applicable
dmi.sys.vendor: Notebook
To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/alsa-driver/+bug/1904075/+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 1904075] [NEW] [NJ5x_NJ7xLU, Realtek ALC293, Speaker, Internal] No sound at all (or so KDE "thinks")
You have been subscribed to a public bug:
This is an odd one (or so it seems to me)...
Sometimes, after booting, my log is filled with messages similar to:
[ 208.746660] snd_hda_intel :00:1f.3: No response from codec, resetting
bus: last cmd=0x20a3b000
[ 209.758633] snd_hda_intel :00:1f.3: No response from codec, resetting
bus: last cmd=0x20a70740
[ 210.770511] snd_hda_intel :00:1f.3: No response from codec, resetting
bus: last cmd=0x20bf0015
See bug #1886626 ("after login to gnome with snd_hda_intel :00:1f.3: No
response from codec")
for a very similar problem; or at least the same-ish message.
The KDE volume thingy says there are no audio input or output devices.
I cannot configure anything audio-H/w related with KDE.
HOwEVER, whilst generating this bug report with apport-cli(1), the tests it ran
clearly showed
(heard!) the built-in (internal) speakers are working. Intrigued, I tried a
wireless Bluetooth
headset (it also worked), a wireless USB headset (also worked), and a wired
headset (also worked).
So there *is* sound, but KDE thinks there is no H/w... SOMETIMES.
At other times, everything is fine. There is no known pattern here (e.g.,
warm- or cold-boot
does not seem to matter, etc.). And then, just to confuse things further, at
least once the
system booted up in the KDE-no-sound state (complete with module "No response
from codec"),
but later (a few minutes?) began to work; a check of the log (dmesg(1)) showed
those messages
had stopped and everything from then on appeared normal. (I'll see if I can
find that incident
in the logs, *IF* I can, I'll attach it later.) That "not"-working to working
does not usually
seem to happen (that one incident may be the only time it has happened?)
I have no idea if, when in the KDE-no-sound state, if I can control the volume
from the computer.
I have also NOT tested the input (microphone(s)) whilst in the KDE-no-sound
state, but I presume
it's like the output (works but KDE doesn't know it?).
It sort-of looks like, at the moment, to me, there is sometime amiss in the
"kernel sound stuff"
which is having a knock-on effect on the "KDE sound stuff". Apologies I cannot
be any more
specific... ;-(
ProblemType: Bug
DistroRelease: Ubuntu 20.04
Package: alsa-base 1.0.25+dfsg-0ubuntu5
ProcVersionSignature: Ubuntu 5.4.0-53.59-generic 5.4.65
Uname: Linux 5.4.0-53-generic x86_64
ApportVersion: 2.20.11-0ubuntu27.12
Architecture: amd64
AudioDevicesInUse:
USERPID ACCESS COMMAND
/dev/snd/controlC0: blf3447 F pulseaudio
CasperMD5CheckResult: skip
CurrentDesktop: KDE
Date: Fri Nov 13 00:30:59 2020
InstallationDate: Installed on 2020-10-19 (24 days ago)
InstallationMedia: Kubuntu 20.04 LTS "Focal Fossa" - Release amd64 (20200423)
PackageArchitecture: all
SourcePackage: alsa-driver
Symptom: audio
Symptom_AlsaPlaybackTest: ALSA playback test through plughw:PCH successful
Symptom_Card: Built-in Audio - HDA Intel PCH
Symptom_DevicesInUse:
USERPID ACCESS COMMAND
/dev/snd/controlC0: blf3447 F pulseaudio
Symptom_Jack: Speaker, Internal
Symptom_PulsePlaybackTest: PulseAudio playback test successful
Symptom_Type: No sound at all
Title: [NJ5x_NJ7xLU, Realtek ALC293, Speaker, Internal] No sound at all
UpgradeStatus: No upgrade log present (probably fresh install)
dmi.bios.date: 07/16/2020
dmi.bios.vendor: INSYDE Corp.
dmi.bios.version: 1.07.03
dmi.board.asset.tag: Tag 12345
dmi.board.name: NJ5x_NJ7xLU
dmi.board.vendor: Notebook
dmi.board.version: Not Applicable
dmi.chassis.asset.tag: No Asset Tag
dmi.chassis.type: 10
dmi.chassis.vendor: No Enclosure
dmi.chassis.version: N/A
dmi.modalias:
dmi:bvnINSYDECorp.:bvr1.07.03:bd07/16/2020:svnNotebook:pnNJ5x_NJ7xLU:pvrNotApplicable:rvnNotebook:rnNJ5x_NJ7xLU:rvrNotApplicable:cvnNoEnclosure:ct10:cvrN/A:
dmi.product.family: Not Applicable
dmi.product.name: NJ5x_NJ7xLU
dmi.product.sku: Not Applicable
dmi.product.version: Not Applicable
dmi.sys.vendor: Notebook
** Affects: alsa-driver (Ubuntu)
Importance: Undecided
Status: New
** Tags: amd64 apport-bug focal
--
[NJ5x_NJ7xLU, Realtek ALC293, Speaker, Internal] No sound at all (or so KDE
"thinks")
https://bugs.launchpad.net/bugs/1904075
You received this bug notification because you are a member of Ubuntu Touch
seeded packages, which is subscribed to alsa-driver in Ubuntu.
--
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 1719355] Re: Switcher widget background goes outside its border
** Changed in: ubuntu-themes Assignee: dejw (lilcashpl) => Carlo Lobrano (c-lobrano) -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to ubuntu-themes in Ubuntu. https://bugs.launchpad.net/bugs/1719355 Title: Switcher widget background goes outside its border Status in Ubuntu theme: Fix Released Status in Ubuntu UX: New Status in ubuntu-themes package in Ubuntu: Fix Released Status in ubuntu-themes source package in Artful: Fix Released Bug description: [Impact] In both Ambiance and Radiance themes, the switcher background is visible outside the widget border when inside a headerbar. See picture from Gnome Control Settings -> Search [Test case] 1. Open Gnome Control Settings -> Search 2. Ensure that no extra border is around the switcher (especially in the headerbar) [Regression potential] Switchers borders are incorrect To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu-themes/+bug/1719355/+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 1886626] Re: after login to gnome with snd_hda_intel 0000:00:1f.3: No response from codec
I had what I _thought_ originally was a very similar issue with Kubuntu 20.04.1
LTS
on a Clevo-NJ70, but further investigation suggests my problem,
despite the same-ish messages, is somewhat different.
See bug #1904075 ("[NJ5x_NJ7xLU, Realtek ALC293, Speaker, Internal] No
sound at all (or so KDE 'thinks'").
--
You received this bug notification because you are a member of Ubuntu
Touch seeded packages, which is subscribed to alsa-driver in Ubuntu.
https://bugs.launchpad.net/bugs/1886626
Title:
after login to gnome with snd_hda_intel :00:1f.3: No response from
codec
Status in alsa-driver package in Ubuntu:
Fix Released
Bug description:
After login to gnome, login takes an unsual amount of time.
Goes back to login screen.
On second login, works normally but audio sliders are not showing correctly.
After a while, it operates normally.
Logs are showing a lot of
snd_hda_intel :00:1f.3: No response from codec, resetting bus:last
cmd0x20a70500
+pci::00:1f.3
ProblemType: Bug
DistroRelease: Ubuntu 18.04
Package: alsa-base 1.0.25+dfsg-0ubuntu5
ProcVersionSignature: Ubuntu 5.0.0-1063.68-oem-osp1 5.0.21
Uname: Linux 5.0.0-1063-oem-osp1 x86_64
ApportVersion: 2.20.9-0ubuntu7.15
Architecture: amd64
AudioDevicesInUse:
USERPID ACCESS COMMAND
/dev/snd/controlC0: killian68 1816 F pulseaudio
CurrentDesktop: ubuntu:GNOME
Date: Tue Jul 7 08:56:11 2020
DistributionChannelDescriptor:
# This is the distribution channel descriptor for the OEM CDs
# For more information see
http://wiki.ubuntu.com/DistributionChannelDescriptor
canonical-oem-somerville-bionic-amd64-20190418-59+beaver-osp1+X00
InstallationDate: Installed on 2020-04-02 (96 days ago)
InstallationMedia: Ubuntu 18.04 "Bionic" - Build amd64 LIVE Binary
20190418-12:10
PackageArchitecture: all
ProcEnviron:
TERM=xterm-256color
PATH=(custom, no user)
XDG_RUNTIME_DIR=
LANG=fr_FR.UTF-8
SHELL=/bin/bash
SourcePackage: alsa-driver
Symptom: audio
Symptom_AlsaPlaybackTest: ALSA playback test through plughw:PCH successful
Symptom_Card: Audio interne - HDA Intel PCH
Symptom_Jack: Speaker, Internal
Symptom_PulsePlaybackTest: PulseAudio playback test successful
Symptom_Type: None of the above
Title: [XPS 13 9300, Realtek ALC289, Speaker, Internal] Playback problem
UpgradeStatus: No upgrade log present (probably fresh install)
dmi.bios.date: 05/08/2020
dmi.bios.vendor: Dell Inc.
dmi.bios.version: 1.0.11
dmi.board.name: 077Y9N
dmi.board.vendor: Dell Inc.
dmi.board.version: A00
dmi.chassis.type: 10
dmi.chassis.vendor: Dell Inc.
dmi.modalias:
dmi:bvnDellInc.:bvr1.0.11:bd05/08/2020:svnDellInc.:pnXPS139300:pvr:rvnDellInc.:rn077Y9N:rvrA00:cvnDellInc.:ct10:cvr:
dmi.product.family: XPS
dmi.product.name: XPS 13 9300
dmi.product.sku: 096D
dmi.sys.vendor: Dell Inc.
To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/alsa-driver/+bug/1886626/+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 1901926] Re: [HDA-Intel - HDA Intel PCH, playback] No sound at all from headphones
@hui.wang Thanks for looking into it and explaining how it works. What you describe is compatible with what I'm seeing, but I don't think I misclicked on that dialog that many times :-) I will test it again soon though. Is there any possibility that the dialog has some kind of issue where it can't apply the user selection or that its default option has changed when the dialog doesn't pop up or something else goes wrong? It's extremely unlikely that I misclicked "Mic" everytime (I may have clicked on it once or twice just to experiment a little). Do you know if there's some command or tool that will show that popup again allowing me to confirm/fix my selection after plugging it in and getting no sound? That would be easier to test than unplugging the headphones over and over. If there's a command-line tool that does the same thing and prints out better diagnostics, that would be helpful to understand what's going on. -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to alsa-driver in Ubuntu. https://bugs.launchpad.net/bugs/1901926 Title: [HDA-Intel - HDA Intel PCH, playback] No sound at all from headphones Status in alsa-driver package in Ubuntu: Confirmed Bug description: There is no sound at all from the headphones (p3 out). Speakers work fine. ProblemType: Bug DistroRelease: Ubuntu 20.04 Package: alsa-base 1.0.25+dfsg-0ubuntu5 ProcVersionSignature: Ubuntu 5.4.0-52.57-generic 5.4.65 Uname: Linux 5.4.0-52-generic x86_64 ApportVersion: 2.20.11-0ubuntu27.10 Architecture: amd64 AudioDevicesInUse: USERPID ACCESS COMMAND /dev/snd/controlC1: sartojr2255 F pulseaudio /dev/snd/controlC0: sartojr2255 F pulseaudio CasperMD5CheckResult: skip CurrentDesktop: ubuntu:GNOME Date: Wed Oct 28 13:48:59 2020 InstallationDate: Installed on 2020-01-14 (287 days ago) InstallationMedia: Ubuntu 18.04.3 LTS "Bionic Beaver" - Release amd64 (20190805) PackageArchitecture: all ProcEnviron: LANGUAGE=pt_BR:pt:en PATH=(custom, no user) XDG_RUNTIME_DIR= LANG=pt_BR.UTF-8 SHELL=/bin/bash SourcePackage: alsa-driver Symptom: audio Symptom_AlsaPlaybackTest: ALSA playback test through plughw:PCH successful Symptom_Card: HDA NVidia - HDA NVidia Symptom_DevicesInUse: USERPID ACCESS COMMAND /dev/snd/controlC1: sartojr2255 F pulseaudio /dev/snd/controlC0: sartojr2255 F pulseaudio Symptom_PulsePlaybackTest: PulseAudio playback test successful Symptom_Type: No sound at all Title: [HDA-Intel - HDA Intel PCH, playback] No sound at all UpgradeStatus: Upgraded to focal on 2020-10-04 (24 days ago) dmi.bios.date: 11/04/2019 dmi.bios.vendor: American Megatrends Inc. dmi.bios.version: P03REZ.041.191104.FL dmi.board.asset.tag: No Asset Tag dmi.board.name: NP760XBE-XW1BR dmi.board.vendor: SAMSUNG ELECTRONICS CO., LTD. dmi.board.version: SGL9947A0Y-C01-G003-S0001+10.0.17763 dmi.chassis.asset.tag: No Asset Tag dmi.chassis.type: 10 dmi.chassis.vendor: SAMSUNG ELECTRONICS CO., LTD. dmi.chassis.version: N/A dmi.modalias: dmi:bvnAmericanMegatrendsInc.:bvrP03REZ.041.191104.FL:bd11/04/2019:svnSAMSUNGELECTRONICSCO.,LTD.:pn760XBE:pvrP03REZ:rvnSAMSUNGELECTRONICSCO.,LTD.:rnNP760XBE-XW1BR:rvrSGL9947A0Y-C01-G003-S0001+10.0.17763:cvnSAMSUNGELECTRONICSCO.,LTD.:ct10:cvrN/A: dmi.product.family: Notebook 7 Series dmi.product.name: 760XBE dmi.product.sku: SCAI-A5A5-A5A5-A5A5-PREZ dmi.product.version: P03REZ dmi.sys.vendor: SAMSUNG ELECTRONICS CO., LTD. mtime.conffile..etc.modprobe.d.alsa-base.conf: 2020-04-11T15:48:00.584083 To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/alsa-driver/+bug/1901926/+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 1898547] Re: neutron-linuxbridge-agent fails to start with iptables 1.8.5
** Tags removed: verification-needed -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to iptables in Ubuntu. https://bugs.launchpad.net/bugs/1898547 Title: neutron-linuxbridge-agent fails to start with iptables 1.8.5 Status in Ubuntu on IBM z Systems: Fix Committed Status in iptables package in Ubuntu: Fix Released Status in neutron package in Ubuntu: Invalid Status in iptables source package in Groovy: Fix Committed Status in neutron source package in Groovy: Invalid Status in iptables source package in Hirsute: Fix Released Status in neutron source package in Hirsute: Invalid Bug description: [Impact] With iptables 1.8.5 neutron-linuxbridge-agent fails to properly start. The log file shows many errors like: 2020-10-05 10:20:37.998 551 ERROR neutron.plugins.ml2.drivers.agent._common_agent ; Stdout: ; Stderr: iptables-restore: line 29 failed This can be demonstrated with a simple test case: iptables-restore
[Touch-packages] [Bug 1899262] Re: Broken dbus GetAll message to wpa supplicant interface properties
Thanks, it finally makes sense now and I can confirm the patch works, it would have helped if the description stated the issue was in bionic and fixed in newer version... Anyway, the patch was fixed in the upload https://launchpad.net/ubuntu/+source/wpa/2:2.6-16ubuntu1 where it's noted that it was changed to not error out when not in AP mode. The patch is similar to the one attached earlier on the bug ** Description changed: - dbus-send is able to read the properties of interface using GetAll. Those information include interface name, status, encryption method, etc. + * Impact + One of the distro patch is incorrect and create issues when trying to query dbus properties + + * Test Case + + $ sudo dbus-send --system --print-reply --dest=fi.w1.wpa_supplicant1 + /fi/w1/wpa_supplicant1/Interfaces/1 + org.freedesktop.DBus.Properties.GetAll + string:fi.w1.wpa_supplicant1.Interface + + shouldn't error out + + (the /1 reflect the interface number and could be a different value, + check with d-feet if needed) + + * Regression potential + + The fixes is in the dbus interface, check that communication with + desktop clients (indicator, applet, settings) still works correctly, + returning expected informations on the signal, etc + + - + + dbus-send is able to read the properties of interface using GetAll. Those information include interface name, status, encryption method, etc. The regression was introduced when someone try to have the Station attribute supported -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to wpa in Ubuntu. https://bugs.launchpad.net/bugs/1899262 Title: Broken dbus GetAll message to wpa supplicant interface properties Status in wpa package in Ubuntu: In Progress Bug description: * Impact One of the distro patch is incorrect and create issues when trying to query dbus properties * Test Case $ sudo dbus-send --system --print-reply --dest=fi.w1.wpa_supplicant1 /fi/w1/wpa_supplicant1/Interfaces/1 org.freedesktop.DBus.Properties.GetAll string:fi.w1.wpa_supplicant1.Interface shouldn't error out (the /1 reflect the interface number and could be a different value, check with d-feet if needed) * Regression potential The fixes is in the dbus interface, check that communication with desktop clients (indicator, applet, settings) still works correctly, returning expected informations on the signal, etc - dbus-send is able to read the properties of interface using GetAll. Those information include interface name, status, encryption method, etc. The regression was introduced when someone try to have the Station attribute supported To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/wpa/+bug/1899262/+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 1904068] [NEW] apt(-get) source fails to use credentials from /etc/apt/auth.conf(.d)
Public bug reported: I have configured apt-src access to the private ESM PPAs via entries in /etc/apt/sources.list.d/ubuntu-security.list as follows: deb-src https://private-ppa.launchpad.net/ubuntu-esm/esm-infra- security/ubuntu trusty main and then added credentials as follows to /etc/apt/auth.conf.d/ubuntu- security.conf: machine private-ppa.launchpad.net/ubuntu-esm/esm-infra-security/ubuntu login alexmurray password Running apt-get update then succeeds - but if I then try and run `apt- get source` to download from the PPA it fails: $ apt-get source --only-source intel-microcode/trusty Reading package lists... Done Selected version '3.20201110.0ubuntu0.14.04.2' (trusty) for intel-microcode NOTICE: 'intel-microcode' packaging is maintained in the 'Git' version control system at: https://salsa.debian.org/hmh/intel-microcode.git Please use: git clone https://salsa.debian.org/hmh/intel-microcode.git to retrieve the latest (possibly unreleased) updates to the package. Need to get 3,447 kB of source archives. Err:1 https://private-ppa.launchpad.net/ubuntu-esm/esm-infra-security/ubuntu trusty/main intel-microcode 3.20201110.0ubuntu0.14.04.2 (tar) 401 Unauthorized [IP: 2001:67c:1560:8008::15 443] Err:2 https://private-ppa.launchpad.net/ubuntu-esm/esm-infra-security/ubuntu trusty/main intel-microcode 3.20201110.0ubuntu0.14.04.2 (dsc) 401 Unauthorized [IP: 2001:67c:1560:8008::15 443] E: Failed to fetch https://private-ppa.launchpad.net/ubuntu-esm/esm-infra-security/ubuntu/pool/main/i/intel-microcode/intel-microcode_3.20201110.0ubuntu0.14.04.2.tar.xz 401 Unauthorized [IP: 2001:67c:1560:8008::15 443] E: Failed to fetch https://private-ppa.launchpad.net/ubuntu-esm/esm-infra-security/ubuntu/pool/main/i/intel-microcode/intel-microcode_3.20201110.0ubuntu0.14.04.2.dsc 401 Unauthorized [IP: 2001:67c:1560:8008::15 443] E: Failed to fetch some archives. However if I edit /etc/apt/sources.list.d/ubuntu-security.list above to specify the credentials in-line then it succeeds: deb-src https://alexmurray:x...@private-ppa.launchpad.net/ubuntu-esm /esm-infra-security/ubuntu trusty main $ apt-get source --only-source intel-microcode/trusty Reading package lists... Done Selected version '3.20201110.0ubuntu0.14.04.2' (trusty) for intel-microcode NOTICE: 'intel-microcode' packaging is maintained in the 'Git' version control system at: https://salsa.debian.org/hmh/intel-microcode.git Please use: git clone https://salsa.debian.org/hmh/intel-microcode.git to retrieve the latest (possibly unreleased) updates to the package. Need to get 3,447 kB of source archives. Get:1 https://private-ppa.launchpad.net/ubuntu-esm/esm-infra-security/ubuntu trusty/main intel-microcode 3.20201110.0ubuntu0.14.04.2 (tar) [3,446 kB] Get:2 https://private-ppa.launchpad.net/ubuntu-esm/esm-infra-security/ubuntu trusty/main intel-microcode 3.20201110.0ubuntu0.14.04.2 (dsc) [1,604 B] Fetched 3,447 kB in 5s (657 kB/s) dpkg-source: info: extracting intel-microcode in intel-microcode-3.20201110.0ubuntu0.14.04.2 dpkg-source: info: unpacking intel-microcode_3.20201110.0ubuntu0.14.04.2.tar.xz However now apt(-get) update complains about having credentials manually listed in the apt sources: $ sudo apt update ... N: Usage of apt_auth.conf(5) should be preferred over embedding login information directly in the sources.list(5) entry for 'https://private-ppa.launchpad.net/ubuntu-esm/esm-infra-security/ubuntu' ProblemType: Bug DistroRelease: Ubuntu 20.10 Package: apt 2.1.10 ProcVersionSignature: Ubuntu 5.8.0-28.30-generic 5.8.14 Uname: Linux 5.8.0-28-generic x86_64 NonfreeKernelModules: zfs zunicode zavl icp zcommon znvpair ApportVersion: 2.20.11-0ubuntu50 Architecture: amd64 CasperMD5CheckResult: skip CurrentDesktop: ubuntu:GNOME Date: Fri Nov 13 09:09:54 2020 InstallationDate: Installed on 2020-10-11 (32 days ago) InstallationMedia: Ubuntu 20.10 "Groovy Gorilla" - Beta amd64 (20200930) SourcePackage: apt UpgradeStatus: No upgrade log present (probably fresh install) ** Affects: apt (Ubuntu) Importance: Undecided Status: New ** Tags: amd64 apport-bug groovy -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to apt in Ubuntu. https://bugs.launchpad.net/bugs/1904068 Title: apt(-get) source fails to use credentials from /etc/apt/auth.conf(.d) Status in apt package in Ubuntu: New Bug description: I have configured apt-src access to the private ESM PPAs via entries in /etc/apt/sources.list.d/ubuntu-security.list as follows: deb-src https://private-ppa.launchpad.net/ubuntu-esm/esm-infra- security/ubuntu trusty main and then added credentials as follows to /etc/apt/auth.conf.d/ubuntu- security.conf: machine private-ppa.launchpad.net/ubuntu-esm/esm-infra-security/ubuntu login alexmurray password Running apt-get update then succeeds - but if I then try and run `apt- get source` to download f
Re: [Touch-packages] [Bug 1903048] Re: [SRU] Bluetooth won't activate on the pi 400
On Thu, Nov 12, 2020 at 11:11:23AM -, Sebastien Bacher wrote: >Sorry but I'm reverting that upload for now until the patches are >properly upstreamed. We have been bitten too often by unforwarded >changes that create issues or create maintainance burden over the years >and we currently don't have the team capacity to deal with extra cost. >If foundations would like to step up and take over bluez though that's a >discussion we could have... My apologies; I omitted to note in the patch that the Pi 400 is a certified platform, i.e. we're effectively committed to making it work as best we can, which makes the status of whether upstream accept the patches or not rather moot: If upstream say "yes" to the patches, without further discussion: that's great, but there'd presumably still be some delay before another version makes its way down to us, so we'd be applying *some* patch to make it work in the interim. If upstream say "with these changes" to the patches: again great, but in the interim, we'd again be applying *some* patch to make things work on a certified platform while working through changes upstream. If upstream say "not in a month of Sundays" to these patches: we'd be left carrying *some* patch, and we'd do it because it's a certified platform and we're committed to making it work. From our end user's perspective therefore, the application of this patch-set, whether via upstream or not, and whether in this form or not, is not a matter of "if", but "when". Given we have in our possession a patch-set that fixes the problem, I at least don't have a good answer to the hypothetical user's obvious follow-up question: "why not now?" Anyway, onto technical matters: >I'm not asking for the patches to be merged upstream but at least to be >sent there for review and have the appropriate tagging, it's easy to >unblock from your side. Also I would like to see if we can get for a >better way to probe for the system to be ready rather than relying on a >random sleep The following involves a certain amount of educated guessing. I haven't dug into this extensively, but I can offer some reasons for why sleep(1) is being used (and how this could be refined a bit, but not much): Consider the bcm43xx_load_firmware routine in hciattach_bcm43xx.c [1] which is being called prior to the apparently arbitrarily inserted sleep(1) line in the patch. It's a fairly typical firmware load routine by all accounts: 1. Calls write() with a command (0x2e 0xfc) to place the device into a state where it's read to receive new firmware 2. Calls read_hci_event() to check the device responded "okay!" 3. Calls nanosleep() to wait a short while (50ms) for the device to be ready 4. Calls read() and write() repeatedly to write the firmware blob from a file to the UART 5. Calls nanosleep() again to wait another short while (200ms) after the firmware load So the existing (pre-patch) firmware load routine already has a seemingly arbitrary post-firmware-load delay of 200ms. If we have a look at the BCM4334 datasheet [2], p.159 we can see "wait at least 150ms after [power on] before initiating SDIO accesses" (SDIO being one of several interfaces for this particular module). However, that's just for the BCM4334. There's also the BCM4330, BCM4329, and the Cypress 305 (on the Pi 400, which uses the BCM43xx interface; Cypress, incidentally, acquired Broadcom's wireless business which explains why their chips suddenly have Broadcom's interfaces). The bluez interface *could* presumably check precisely which device it was dealing with and adjust its post-firmware-load delay accordingly. Or it could simply go with a delay that's "long enough" to cover all the supported chipsets, and avoid all that logic (which appears to be what's favoured in the original code). Given it's a one-time setup delay, and it's likely to occur during boot-up (or system wake-up) when half a dozen other things are happening in parallel, it's unlikely the user will notice a difference between a 150ms, 200ms, or even 1.2s delay to their Bluetooth module becoming available. Hence one possibility for the sleep(1) delay is that the Cypress 305, being a later and more feature-rich device, requires a longer delay. I can't confirm that as I can't find the datasheet online; sadly, this isn't remotely surprising, but I could reasonably assume that the Pi Foundation *do* have access to it and thus the 1 second delay isn't *entirely* arbitrary. In some of the BCM43xx modules it does appear that the UART CTS line is asserted to indicate the device is "ready" (e.g. the BCM4330 datasheet mentions this under the Bluetooth PMU section). However, one of the configurations (not the default, but a supported configuration nonetheless) for the Bluetooth module on all Pi models is to be operated via the mini-UART instead of the PL011. The mini-UART, as noted previously, explicitly lacks any hardware flow-control ([3], p
[Touch-packages] [Bug 1719355] Re: Switcher widget background goes outside its border
** Changed in: ubuntu-themes Assignee: Carlo Lobrano (c-lobrano) => dejw (lilcashpl) -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to ubuntu-themes in Ubuntu. https://bugs.launchpad.net/bugs/1719355 Title: Switcher widget background goes outside its border Status in Ubuntu theme: Fix Released Status in Ubuntu UX: New Status in ubuntu-themes package in Ubuntu: Fix Released Status in ubuntu-themes source package in Artful: Fix Released Bug description: [Impact] In both Ambiance and Radiance themes, the switcher background is visible outside the widget border when inside a headerbar. See picture from Gnome Control Settings -> Search [Test case] 1. Open Gnome Control Settings -> Search 2. Ensure that no extra border is around the switcher (especially in the headerbar) [Regression potential] Switchers borders are incorrect To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu-themes/+bug/1719355/+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 1818918] Re: gdb doesn't search in debug-file-directory for .gnu_debugaltlink
This is also true with gdb 10.1 from hirsute-proposed.
--
You received this bug notification because you are a member of Ubuntu
Touch seeded packages, which is subscribed to apport in Ubuntu.
https://bugs.launchpad.net/bugs/1818918
Title:
gdb doesn't search in debug-file-directory for .gnu_debugaltlink
Status in Apport:
Fix Released
Status in apport package in Ubuntu:
New
Status in gdb package in Ubuntu:
Confirmed
Bug description:
As far as I can tell gdb version 8.2.90 isn't searching the debug-
file-directory, which I set, for the '.gnu_debugaltlink' which is in
the debug symbols. Here's the error I'm seeing:
Type "apropos word" to search for commands related to "word".
Reading symbols from /srv/vms/apport-sandbox-dir/Ubuntu
19.04/amd64/report-sandbox//usr/bin/gnome-calculator...
Reading symbols from /srv/vms/apport-sandbox-dir/Ubuntu
19.04/amd64/report-sandbox/usr/lib/debug/.build-id/95/59c4c5ee30eb66d47bb9bd64784a69c9a6de6b.debug...
could not find '.gnu_debugaltlink' file for
/srv/vms/apport-sandbox-dir/Ubuntu
19.04/amd64/report-sandbox/usr/lib/debug/.build-id/95/59c4c5ee30eb66d47bb9bd64784a69c9a6de6b.debug
(No debugging symbols found in /srv/vms/apport-sandbox-dir/Ubuntu
19.04/amd64/report-sandbox/usr/lib/debug/.build-id/95/59c4c5ee30eb66d47bb9bd64784a69c9a6de6b.debug)
Here's part of an strace of what's going on behind the scenes:
lstat("/srv/vms/apport-sandbox-dir/Ubuntu
19.04/amd64/report-sandbox/usr/lib/debug/.build-id/95/59c4c5ee30eb66d47bb9bd64784a69c9a6de6b.debug",
{st_mode=S_IFREG|0644, st_size=839744, ...}) = 0
openat(AT_FDCWD,
"/usr/lib/debug/.dwz/x86_64-linux-gnu/gnome-calculator.debug",
O_RDONLY|O_CLOEXEC) = -1 ENOENT (No such file or directory)
This is the only time "/usr/lib/debug" is searched, generally
"/srv/vms/apport-sandbox-dir/Ubuntu 19.04/amd64/report-
sandbox/usr/lib/debug/" is used. I'll attach the full strace though.
For completeness here's the gdb command I'm using:
Calling gdb command: '/srv/vms/apport-sandbox-dir/Ubuntu 19.04/amd64
/report-sandbox/lib/x86_64-linux-gnu/ld-linux-x86-64.so.2' '/srv/vms
/apport-sandbox-dir/Ubuntu 19.04/amd64/report-sandbox/usr/bin/gdb'
--ex 'set debug-file-directory /srv/vms/apport-sandbox-dir/Ubuntu
19.04/amd64/report-sandbox/usr/lib/debug' --ex 'set solib-absolute-
prefix /srv/vms/apport-sandbox-dir/Ubuntu 19.04/amd64/report-sandbox'
--ex 'add-auto-load-safe-path /srv/vms/apport-sandbox-dir/Ubuntu
19.04/amd64/report-sandbox' --ex 'set solib-search-path /srv/vms
/apport-sandbox-dir/Ubuntu 19.04/amd64/report-sandbox/lib/x86_64
-linux-gnu' --ex 'set data-directory /srv/vms/apport-sandbox-
dir/Ubuntu 19.04/amd64/report-sandbox/usr/share/gdb' --ex 'file
"/srv/vms/apport-sandbox-dir/Ubuntu 19.04/amd64/report-
sandbox//usr/bin/gnome-calculator"' --ex 'core-file
/tmp/apport_core_1b6dn6np'
To manage notifications about this bug go to:
https://bugs.launchpad.net/apport/+bug/1818918/+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 1903048] Re: [SRU] Bluetooth won't activate on the pi 400
@seb128: Do you think you can re-revert this change? we are going to work with upstream and give them access to the patch. I don't think we should should prevent the device to work until this is done. As Chris said in #20, there's a lot of hype on the pi400 and bluetooth not working is definitely affecting user experience. Thx in Advance -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to bluez in Ubuntu. https://bugs.launchpad.net/bugs/1903048 Title: [SRU] Bluetooth won't activate on the pi 400 Status in bluez package in Ubuntu: Triaged Status in bluez source package in Hirsute: Triaged Bug description: [Impact] Without these patches, Bluetooth is inoperable on the recently released Raspberry Pi 400. [Test Case] * Boot the Ubuntu Desktop for Pi image on a Pi 400. * Start the Settings application and switch to the Bluetooth tab * Verify that Bluetooth is not enabled and attempting to activate it fails * sudo add-apt-repository ppa:waveform/pi-bluetooth * sudo apt update * sudo apt install bluez * sudo reboot * Start the Settings application and switch to the Bluetooth tab * Verify that Bluetooth is active and that Bluetooth devices (e.g. mice, mobile phones, headphones, etc.) can connect and operate correctly [Regression Potential] Extremely low (on groovy in particular, this has the same version of bluez as hirsute). The only significant risk is to non-Pi platforms or dongles which also use the Broadcom 43xx (or Cypress 305) chips for Bluetooth which might be inadvertently affected by these patches. [Original Description] The new Pi 400 has a slightly different Wifi/BT chip to the Pi4. Whilst wifi works happily, Bluetooth fails to operate. This doesn't appear to be an issue with either the firmware (the latest versions from upstream Raspbian have been tried), or the kernel (a known-good raspi kernel has been tested under Ubuntu), but with Bluez itself. Specifically, tracing the initialization with btmon on Raspbian and Ubuntu, the stack consistently fails when attempting to "Set Default PHY" on the latter. Curiously, under Ubuntu the adapter also appears to lack a MAC address. To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/bluez/+bug/1903048/+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 1903048] Re: [SRU] Bluetooth won't activate on the pi 400
What's the status of this? We desperately need this fix in Groovy, as we're making lots of noise about the pi400 and this is a pretty glaring hole in functionality. -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to bluez in Ubuntu. https://bugs.launchpad.net/bugs/1903048 Title: [SRU] Bluetooth won't activate on the pi 400 Status in bluez package in Ubuntu: Triaged Status in bluez source package in Hirsute: Triaged Bug description: [Impact] Without these patches, Bluetooth is inoperable on the recently released Raspberry Pi 400. [Test Case] * Boot the Ubuntu Desktop for Pi image on a Pi 400. * Start the Settings application and switch to the Bluetooth tab * Verify that Bluetooth is not enabled and attempting to activate it fails * sudo add-apt-repository ppa:waveform/pi-bluetooth * sudo apt update * sudo apt install bluez * sudo reboot * Start the Settings application and switch to the Bluetooth tab * Verify that Bluetooth is active and that Bluetooth devices (e.g. mice, mobile phones, headphones, etc.) can connect and operate correctly [Regression Potential] Extremely low (on groovy in particular, this has the same version of bluez as hirsute). The only significant risk is to non-Pi platforms or dongles which also use the Broadcom 43xx (or Cypress 305) chips for Bluetooth which might be inadvertently affected by these patches. [Original Description] The new Pi 400 has a slightly different Wifi/BT chip to the Pi4. Whilst wifi works happily, Bluetooth fails to operate. This doesn't appear to be an issue with either the firmware (the latest versions from upstream Raspbian have been tried), or the kernel (a known-good raspi kernel has been tested under Ubuntu), but with Bluez itself. Specifically, tracing the initialization with btmon on Raspbian and Ubuntu, the stack consistently fails when attempting to "Set Default PHY" on the latter. Curiously, under Ubuntu the adapter also appears to lack a MAC address. To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/bluez/+bug/1903048/+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 1904048] [NEW] ı have amd64 cpu but . updater want installed intel microcode firmware
Public bug reported: software updater wants install some and ı want see whats new intel-microcode changelog: installed: 3.20200609.0ubuntu0.18.04.1 new: 3.20201110.0ubuntu0.18.04.2 when ı see 5 minutes a go , ı said Aao!!? when ,? and yes, my laptop is very slow , why , maybe this ? Ubuntu 18.04.5 LTS AMD® C-60 apu with radeon(tm) hd graphics × 2 3,5 GiB Ram ** Affects: initramfs-tools (Ubuntu) Importance: Undecided Status: New ** Tags: amd64 intelmicrocode ** Summary changed: - ı have amd64 cpu but . updater want installed intel microcode firware + ı have amd64 cpu but . updater want installed intel microcode firmware -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to initramfs-tools in Ubuntu. https://bugs.launchpad.net/bugs/1904048 Title: ı have amd64 cpu but . updater want installed intel microcode firmware Status in initramfs-tools package in Ubuntu: New Bug description: software updater wants install some and ı want see whats new intel-microcode changelog: installed: 3.20200609.0ubuntu0.18.04.1 new: 3.20201110.0ubuntu0.18.04.2 when ı see 5 minutes a go , ı said Aao!!? when ,? and yes, my laptop is very slow , why , maybe this ? Ubuntu 18.04.5 LTS AMD® C-60 apu with radeon(tm) hd graphics × 2 3,5 GiB Ram To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/initramfs-tools/+bug/1904048/+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 1644541] Re: Update stuck at “configuring unattended-upgrades”
Has this issue been seen with the latest unattended-upgrades version on Xenial or on any later release? ** Changed in: unattended-upgrades (Ubuntu) Status: Confirmed => Incomplete -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to unattended-upgrades in Ubuntu. https://bugs.launchpad.net/bugs/1644541 Title: Update stuck at “configuring unattended-upgrades” Status in unattended-upgrades package in Ubuntu: Incomplete Bug description: On basically fresh install from ubuntu-16.04.1-desktop-amd64.iso; no updates or installs had been applied since installing the OS from the media. During execution of "Software Updater", it freezes indefinitely while "Installing updates..." at the step marked "Configuring unattended- upgrades." It appears that this happens if System Settings->Software & Updates->Updates, "Automatically check for updates" has been set to "Never." If that is instead set to "Daily" and the following are then set in /etc/apt/apt.conf.d/10periodic then the update succeeds: APT::Periodic::Update-Package-Lists "1"; APT::Periodic::Download-Upgradeable-Packages "1"; APT::Periodic::AutocleanInterval "7"; APT::Periodic::Unattended-Upgrade "1"; Someone else had asked about this issue at AskUbuntu. Their question along with my answer (from Kevin) provide some further details: http://askubuntu.com/questions/851371/update-stuck-at-configuring- unattended-upgrades-software-updater-turned-black/852110#852110 To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/unattended-upgrades/+bug/1644541/+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 1896137] Re: syslog flooded with "Lockdown: systemd-logind: hibernation is restricted; see man kernel_lockdown.7"
I am affected with this. My kernel yells "Lockdown: systemd[1]: hibernation is restricted; see man kernel_lockdown.7" during boot. And make my system impossible to boot. Some day it take time upto 10 MIN. -- 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/1896137 Title: syslog flooded with "Lockdown: systemd-logind: hibernation is restricted; see man kernel_lockdown.7" Status in systemd package in Ubuntu: Incomplete Bug description: When I close the lid on my laptop, syslog goes crazy with the message systemd-logind: hibernation is restricted; see man kernel_lockdown.7 repeated ad infinitum, using up all the CPU and GBs of disk space. I am not even trying to hibernate; everything in /etc/systemd/login.conf is commented out. So nothing much should happen when I close the lid, but systemd is trying to kill me with these messages. I am running Ubuntu 20.04. To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/systemd/+bug/1896137/+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 1903351] Re: ignore_eacces and ignore_erofs patches don't work properly
** Tags removed: rls-gg-incoming -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to procps in Ubuntu. https://bugs.launchpad.net/bugs/1903351 Title: ignore_eacces and ignore_erofs patches don't work properly Status in procps package in Ubuntu: Confirmed Bug description: The patches used to ignore errors in containers no longer work as of 3.3.16 due to upstream commit https://gitlab.com/procps- ng/procps/-/commit/7af88da373bb4d515a98ec2f0f5d56c63904f932 The ignore_eacces patch was fuzzed and gets applied to ReadSetting, not WriteSetting Both patches ignore the change that rc is no longer propagated up and instead everything is trapped by: if (!ignore_failure && errno != ENOENT) rc = -1; Versions affected: focal+ root@bfee89058713:/tmp# cat /etc/os-release NAME="Ubuntu" VERSION="20.10 (Groovy Gorilla)" ID=ubuntu ID_LIKE=debian PRETTY_NAME="Ubuntu 20.10" VERSION_ID="20.10" HOME_URL="https://www.ubuntu.com/"; SUPPORT_URL="https://help.ubuntu.com/"; BUG_REPORT_URL="https://bugs.launchpad.net/ubuntu/"; PRIVACY_POLICY_URL="https://www.ubuntu.com/legal/terms-and-policies/privacy-policy"; VERSION_CODENAME=groovy UBUNTU_CODENAME=groovy root@bfee89058713:/# dpkg -l procps Desired=Unknown/Install/Remove/Purge/Hold | Status=Not/Inst/Conf-files/Unpacked/halF-conf/Half-inst/trig-aWait/Trig-pend |/ Err?=(none)/Reinst-required (Status,Err: uppercase=bad) ||/ Name Version Architecture Description +++-==-=--= ii procps 2:3.3.16-5ubuntu2 amd64/proc file system utilities root@bfee89058713:/# echo "kernel.shmmax = 17179869184" > shmmax.conf root@bfee89058713:/# sysctl -e -p shmmax.conf; echo $? sysctl: setting key "kernel.shmmax": Read-only file system 255 root@bfee89058713:/# echo "-kernel.shmmax = 17179869184" > shmmax.conf root@bfee89058713:/# sysctl -e -p shmmax.conf; echo $? sysctl: setting key "kernel.shmmax": Read-only file system 0 To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/procps/+bug/1903351/+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 1902760] Re: Please merge linker bugfix into Ubuntu 20.04 LTS
>From #ubuntu-meeting on 2020-11-12 08:26 < doko> that binutils fix is not yet on the 2.34 branch ** Tags removed: rls-ff-incoming -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to binutils in Ubuntu. https://bugs.launchpad.net/bugs/1902760 Title: Please merge linker bugfix into Ubuntu 20.04 LTS Status in binutils: Fix Released Status in intel: New Status in binutils package in Ubuntu: New Bug description: Binutils bug https://sourceware.org/bugzilla/show_bug.cgi?id=26262 fixes a problem that Intel Fortran is running into when using the -ipo option to request link time optimization. Please merge the fix into Ubuntu 20.04 LTS To manage notifications about this bug go to: https://bugs.launchpad.net/binutils/+bug/1902760/+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 1903567] Re: /usr/share/apport/apport:AttributeError:/usr/share/apport/apport@447:parse_arguments:print_usage:_print_message
** Tags removed: rls-hh-incoming -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to apport in Ubuntu. https://bugs.launchpad.net/bugs/1903567 Title: /usr/share/apport/apport:AttributeError:/usr/share/apport/apport@447:parse_arguments:print_usage:_print_message Status in apport package in Ubuntu: Confirmed Status in apport source package in Xenial: Confirmed Status in apport source package in Bionic: Confirmed Bug description: The Ubuntu Error Tracker has been receiving reports about a problem regarding apport. This problem was most recently seen with package version 2.20.1-0ubuntu2.26, the problem page at https://errors.ubuntu.com/problem/c39b4b2ced24aa71d85b0995a56bd3813a39 contains more details, including versions of packages affected, stacktrace or traceback, and individual crash reports. If you do not have access to the Ubuntu Error Tracker and are a software developer, you can request it at http://forms.canonical.com/reports/. To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/apport/+bug/1903567/+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 1903814] Re: [binutils] Prevent GOT access rewrite for certain symbols
** Changed in: binutils (Debian) Status: Unknown => New -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to binutils in Ubuntu. https://bugs.launchpad.net/bugs/1903814 Title: [binutils] Prevent GOT access rewrite for certain symbols Status in Ubuntu on IBM z Systems: Triaged Status in binutils package in Ubuntu: Fix Released Status in binutils source package in Bionic: New Status in binutils package in Debian: New Bug description: Please backport the following bugfix into Ubuntu LTS: https://sourceware.org/git/?p=binutils-gdb.git;a=commit;h=e6213e09ed0e Some relevant historic links: Debian bugreport: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=961736 glibc bugreport: https://sourceware.org/bugzilla/show_bug.cgi?id=18960 In s390 kernel context, this bug manifests itself as random errors and infinite loops, so it's fairly severe. These are the current versions of binutils: Package binutils xenial (16.04LTS) (devel): GNU assembler, linker and binary utilities 2.26.1-1ubuntu1~16.04.8 [security]: amd64 i386 2.26-8ubuntu2 [ports]: arm64 armhf powerpc ppc64el s390x xenial-updates (devel): GNU assembler, linker and binary utilities 2.26.1-1ubuntu1~16.04.8: amd64 arm64 armhf i386 powerpc ppc64el s390x bionic (18.04LTS) (devel): GNU assembler, linker and binary utilities 2.30-21ubuntu1~18.04.4 [security]: amd64 i386 2.30-15ubuntu1 [ports]: arm64 armhf ppc64el s390x bionic-updates (devel): GNU assembler, linker and binary utilities 2.30-21ubuntu1~18.04.4: amd64 arm64 armhf i386 ppc64el s390x focal (20.04LTS) (devel): GNU assembler, linker and binary utilities 2.34-6ubuntu1: amd64 arm64 armhf i386 ppc64el s390x groovy (devel): GNU assembler, linker and binary utilities 2.35.1-1ubuntu1: amd64 arm64 armhf i386 ppc64el s390x The patch applies fine to 2.26 and 2.30 (except for tests, but we don't need them). We don't need it on 2.32+. To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu-z-systems/+bug/1903814/+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 1902760] Re: Please merge linker bugfix into Ubuntu 20.04 LTS
** Tags added: fr-926 -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to binutils in Ubuntu. https://bugs.launchpad.net/bugs/1902760 Title: Please merge linker bugfix into Ubuntu 20.04 LTS Status in binutils: Fix Released Status in intel: New Status in binutils package in Ubuntu: New Bug description: Binutils bug https://sourceware.org/bugzilla/show_bug.cgi?id=26262 fixes a problem that Intel Fortran is running into when using the -ipo option to request link time optimization. Please merge the fix into Ubuntu 20.04 LTS To manage notifications about this bug go to: https://bugs.launchpad.net/binutils/+bug/1902760/+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 1903351] Re: ignore_eacces and ignore_erofs patches don't work properly
** Tags added: fr-924 -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to procps in Ubuntu. https://bugs.launchpad.net/bugs/1903351 Title: ignore_eacces and ignore_erofs patches don't work properly Status in procps package in Ubuntu: Confirmed Bug description: The patches used to ignore errors in containers no longer work as of 3.3.16 due to upstream commit https://gitlab.com/procps- ng/procps/-/commit/7af88da373bb4d515a98ec2f0f5d56c63904f932 The ignore_eacces patch was fuzzed and gets applied to ReadSetting, not WriteSetting Both patches ignore the change that rc is no longer propagated up and instead everything is trapped by: if (!ignore_failure && errno != ENOENT) rc = -1; Versions affected: focal+ root@bfee89058713:/tmp# cat /etc/os-release NAME="Ubuntu" VERSION="20.10 (Groovy Gorilla)" ID=ubuntu ID_LIKE=debian PRETTY_NAME="Ubuntu 20.10" VERSION_ID="20.10" HOME_URL="https://www.ubuntu.com/"; SUPPORT_URL="https://help.ubuntu.com/"; BUG_REPORT_URL="https://bugs.launchpad.net/ubuntu/"; PRIVACY_POLICY_URL="https://www.ubuntu.com/legal/terms-and-policies/privacy-policy"; VERSION_CODENAME=groovy UBUNTU_CODENAME=groovy root@bfee89058713:/# dpkg -l procps Desired=Unknown/Install/Remove/Purge/Hold | Status=Not/Inst/Conf-files/Unpacked/halF-conf/Half-inst/trig-aWait/Trig-pend |/ Err?=(none)/Reinst-required (Status,Err: uppercase=bad) ||/ Name Version Architecture Description +++-==-=--= ii procps 2:3.3.16-5ubuntu2 amd64/proc file system utilities root@bfee89058713:/# echo "kernel.shmmax = 17179869184" > shmmax.conf root@bfee89058713:/# sysctl -e -p shmmax.conf; echo $? sysctl: setting key "kernel.shmmax": Read-only file system 255 root@bfee89058713:/# echo "-kernel.shmmax = 17179869184" > shmmax.conf root@bfee89058713:/# sysctl -e -p shmmax.conf; echo $? sysctl: setting key "kernel.shmmax": Read-only file system 0 To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/procps/+bug/1903351/+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 1903567] Re: /usr/share/apport/apport:AttributeError:/usr/share/apport/apport@447:parse_arguments:print_usage:_print_message
** Tags added: fr-922 -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to apport in Ubuntu. https://bugs.launchpad.net/bugs/1903567 Title: /usr/share/apport/apport:AttributeError:/usr/share/apport/apport@447:parse_arguments:print_usage:_print_message Status in apport package in Ubuntu: Confirmed Status in apport source package in Xenial: Confirmed Status in apport source package in Bionic: Confirmed Bug description: The Ubuntu Error Tracker has been receiving reports about a problem regarding apport. This problem was most recently seen with package version 2.20.1-0ubuntu2.26, the problem page at https://errors.ubuntu.com/problem/c39b4b2ced24aa71d85b0995a56bd3813a39 contains more details, including versions of packages affected, stacktrace or traceback, and individual crash reports. If you do not have access to the Ubuntu Error Tracker and are a software developer, you can request it at http://forms.canonical.com/reports/. To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/apport/+bug/1903567/+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 1903849] Re: vim ftbfs
** Tags added: fr-921 -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to vim in Ubuntu. https://bugs.launchpad.net/bugs/1903849 Title: vim ftbfs Status in vim package in Ubuntu: Confirmed Bug description: see https://launchpad.net/ubuntu/+source/vim/2:8.2.1913-1ubuntu1 blocking the perl transition To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/vim/+bug/1903849/+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 1903048] Re: [SRU] Bluetooth won't activate on the pi 400
On Ubuntu 20.10 MATE on a pi400, I ran through the following steps: * Boot the Ubuntu 20.10 MATE for Pi image on a Pi 400 (Was not a fresh installation) * Start the Settings application and switch to the Bluetooth tab * Verify that Bluetooth is not enabled and attempting to activate it fails * sudo add-apt-repository ppa:waveform/pi-bluetooth * sudo apt update * sudo apt install bluez # I noticed there were other packages in the PPA that I did not install * sudo nvi /etc/apt/sources.list.d/waveform-ubuntu-pi-bluetooth-groovy.list # Comment out PPA * sudo apt update && sudo apt upgrade -y * sudo reboot * Start the Settings application and switch to the Bluetooth tab * Pair a set of AirPods * Ensure I can hear audio through the AirPods Everything seemed to work as expected. Thank you for the patches :-) -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to bluez in Ubuntu. https://bugs.launchpad.net/bugs/1903048 Title: [SRU] Bluetooth won't activate on the pi 400 Status in bluez package in Ubuntu: Triaged Status in bluez source package in Hirsute: Triaged Bug description: [Impact] Without these patches, Bluetooth is inoperable on the recently released Raspberry Pi 400. [Test Case] * Boot the Ubuntu Desktop for Pi image on a Pi 400. * Start the Settings application and switch to the Bluetooth tab * Verify that Bluetooth is not enabled and attempting to activate it fails * sudo add-apt-repository ppa:waveform/pi-bluetooth * sudo apt update * sudo apt install bluez * sudo reboot * Start the Settings application and switch to the Bluetooth tab * Verify that Bluetooth is active and that Bluetooth devices (e.g. mice, mobile phones, headphones, etc.) can connect and operate correctly [Regression Potential] Extremely low (on groovy in particular, this has the same version of bluez as hirsute). The only significant risk is to non-Pi platforms or dongles which also use the Broadcom 43xx (or Cypress 305) chips for Bluetooth which might be inadvertently affected by these patches. [Original Description] The new Pi 400 has a slightly different Wifi/BT chip to the Pi4. Whilst wifi works happily, Bluetooth fails to operate. This doesn't appear to be an issue with either the firmware (the latest versions from upstream Raspbian have been tried), or the kernel (a known-good raspi kernel has been tested under Ubuntu), but with Bluez itself. Specifically, tracing the initialization with btmon on Raspbian and Ubuntu, the stack consistently fails when attempting to "Set Default PHY" on the latter. Curiously, under Ubuntu the adapter also appears to lack a MAC address. To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/bluez/+bug/1903048/+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 1903814] Re: [binutils] Prevent GOT access rewrite for certain symbols
** Bug watch added: Debian Bug tracker #961736 https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=961736 ** Also affects: binutils (Debian) via https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=961736 Importance: Unknown Status: Unknown -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to binutils in Ubuntu. https://bugs.launchpad.net/bugs/1903814 Title: [binutils] Prevent GOT access rewrite for certain symbols Status in Ubuntu on IBM z Systems: Triaged Status in binutils package in Ubuntu: Fix Released Status in binutils source package in Bionic: New Status in binutils package in Debian: Unknown Bug description: Please backport the following bugfix into Ubuntu LTS: https://sourceware.org/git/?p=binutils-gdb.git;a=commit;h=e6213e09ed0e Some relevant historic links: Debian bugreport: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=961736 glibc bugreport: https://sourceware.org/bugzilla/show_bug.cgi?id=18960 In s390 kernel context, this bug manifests itself as random errors and infinite loops, so it's fairly severe. These are the current versions of binutils: Package binutils xenial (16.04LTS) (devel): GNU assembler, linker and binary utilities 2.26.1-1ubuntu1~16.04.8 [security]: amd64 i386 2.26-8ubuntu2 [ports]: arm64 armhf powerpc ppc64el s390x xenial-updates (devel): GNU assembler, linker and binary utilities 2.26.1-1ubuntu1~16.04.8: amd64 arm64 armhf i386 powerpc ppc64el s390x bionic (18.04LTS) (devel): GNU assembler, linker and binary utilities 2.30-21ubuntu1~18.04.4 [security]: amd64 i386 2.30-15ubuntu1 [ports]: arm64 armhf ppc64el s390x bionic-updates (devel): GNU assembler, linker and binary utilities 2.30-21ubuntu1~18.04.4: amd64 arm64 armhf i386 ppc64el s390x focal (20.04LTS) (devel): GNU assembler, linker and binary utilities 2.34-6ubuntu1: amd64 arm64 armhf i386 ppc64el s390x groovy (devel): GNU assembler, linker and binary utilities 2.35.1-1ubuntu1: amd64 arm64 armhf i386 ppc64el s390x The patch applies fine to 2.26 and 2.30 (except for tests, but we don't need them). We don't need it on 2.32+. To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu-z-systems/+bug/1903814/+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 1903332] Re: Apport get_config incorrectly drops privileges
** Information type changed from Private Security to Public Security -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to apport in Ubuntu. https://bugs.launchpad.net/bugs/1903332 Title: Apport get_config incorrectly drops privileges Status in apport package in Ubuntu: Fix Released Bug description: Privilege dropping code here drops uid before gid instead of the correct order of gid before uid. Likely this code fails and is caught by the try statement: https://git.launchpad.net/ubuntu/+source/apport/tree/apport/fileutils.py?h=applied/ubuntu /focal-devel&id=94d98694e19b5614f3a764a9e4dcf171ad5039a5#n339 To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/apport/+bug/1903332/+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 1884514] Re: [FFe][20.10 FEAT] zlib/gzip hardware compression enablement
so gzip has the accel patches, and it is built
+ifeq (${DEB_TARGET_ARCH},s390x)
+CONFIGURE_ARGS+= --enable-dfltcc
+endif
+
However, I don't see that there is -DDFLTCC_LEVEL_MASK=0x7e let me open
gzip task.
** Also affects: gzip (Ubuntu)
Importance: Undecided
Status: New
--
You received this bug notification because you are a member of Ubuntu
Touch seeded packages, which is subscribed to zlib in Ubuntu.
https://bugs.launchpad.net/bugs/1884514
Title:
[FFe][20.10 FEAT] zlib/gzip hardware compression enablement
Status in Ubuntu on IBM z Systems:
Fix Released
Status in gzip package in Ubuntu:
New
Status in zlib package in Ubuntu:
Fix Released
Bug description:
[Feature Freeze Exception]
1. Feature:
The latest s390x hardware comes with a new concept for hardware
assisted compression/decompression, based on a 'Next Accelerator
Function unit' (NXU). This is an on-chip concept, a co-processor for
compression available to all cores on the same chip. It provides
functions as normal 'problem state' instructions (in other words user
space instructions that are directly consumable by libraries and
applications) and supports DEFLATE compliant compression/decompression
+ GZIP CRC/ZLIB Adler.
To enable this hardware support for zlib and gzip, zlib needs to be compiled
with CFLAGS="-O2 -DDFLTCC -DDFLTCC_LEVEL_MASK=0x7e".
The value of 0x7e enables hardware compression for the compression levels 1-6
(out of 0-9).
There is a significant business value of having the enablement active by
default, since tests on a system with 4 IFLs and hardware compression enabled
this way offered (especially for DEFLATE as best case) a speed up of more than
40x.
2. Changes
Adding CFLAGS="-O2 -DDFLTCC -DDFLTCC_LEVEL_MASK=0x7e" attributes/macro
during build of zlib and gzip.
3. Regression risk
The concept is new and comes with IBM z15 and LinuxONE III only and is with
that specific and limited to s390x.
Hence a potential regressions of this late addition would be limited to s390x
and there again with the above changes to zlib (and gzip).
In case of unforeseen issues with the NXU hardware component, a fallback to
software is done.
On top a modified zlib package was build and made available in a PPA for
further testing.
This change should have been included earlier, but was blocked by other zlib
tickets/bugs that needed to be fixed and integrated first (like LP 1893170),
hence this request for late addition.
__
HW Compression need to be enabled with Default-Compression-Level 6.
Adding following CFLAGS attributes during build of zlib and gzip
"-DDFLTCC_LEVEL_MASK=0x7e"
CFLAGS="-O2 -DDFLTCC -DDFLTCC_LEVEL_MASK=0x7e" ./configure
To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu-z-systems/+bug/1884514/+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 1903995] Re: upower report wrong battery percentage for Logitech Unify devices
So this seems to be a kernel issue. The hid-logitech-hidpp kernel driver
supports 2 battery reporting modes:
1. Status reporting, here the device basically reports 3 levels low /
normal / high
2. mileage reporting, this is where an actual percentage left gets
reported. I would expect at least the master mx to support this, but the
info shown by upower where there is an "ignore" next to the percentage
suggests that that is not the case (when only low/normal/high reporting
is supported upower makes up a percentage for apps which rely on that
part of the dbus API, which no modern app does).
So I believe that the problem here is that the kernel is using method 1,
where as solaar seems to using 2. (mileage style reporting).
Can you provide full "solaar show" output please?
--
You received this bug notification because you are a member of Ubuntu
Touch seeded packages, which is subscribed to upower in Ubuntu.
https://bugs.launchpad.net/bugs/1903995
Title:
upower report wrong battery percentage for Logitech Unify devices
Status in upower package in Ubuntu:
Triaged
Bug description:
The battery percentage reported by upower for Logitech devices
connected using Unify receiver are wrong. Below are the results for
two devices: Mouse and Keyboard:
* Battery percentages reported by Unify receiver using Solaar:
$ solaar show | grep -iP "^(( \d: )|(.*batt.*))"
1: Wireless Keyboard K270(unifying)
4: BATTERY STATUS {1000}
Battery: 70%, discharging.
2: Wireless Mouse MX Master
7: BATTERY STATUS {1000}
Battery: 20%, discharging.
* Battery percentages reported by upower:
$ upower -i /org/freedesktop/UPower/devices/keyboard_hidpp_battery_0
native-path: hidpp_battery_0
model:Wireless Keyboard K270
serial: 4003-1a-39-5f-c1
power supply: no
updated: Thu 12 Nov 2020 13:59:18 CET (119 seconds ago)
has history: yes
has statistics: yes
keyboard
present: yes
rechargeable:yes
state: discharging
warning-level: none
battery-level: normal
percentage: 55% (should be ignored)
icon-name: 'battery-low-symbolic'
$ upower -i /org/freedesktop/UPower/devices/mouse_hidpp_battery_1
native-path: hidpp_battery_1
model:Wireless Mouse MX Master
serial: 4071-f8-eb-bf-d1
power supply: no
updated: Thu 12 Nov 2020 14:03:14 CET (27 seconds ago)
has history: yes
has statistics: yes
mouse
present: yes
rechargeable:yes
state: discharging
warning-level: low
battery-level: low
percentage: 10% (should be ignored)
icon-name: 'battery-caution-symbolic'
Basically the difference is big so I'm getting a lot of notifications
related to low battery even if the battery is OK:
* Mouse, upower: 10%real (Solaar): 20%
* Keyboard: upower: 70%real (Solaar): 55%
ProblemType: Bug
DistroRelease: Ubuntu 20.04
Package: upower 0.99.11-1build2
ProcVersionSignature: Ubuntu 5.4.0-53.59-generic 5.4.65
Uname: Linux 5.4.0-53-generic x86_64
NonfreeKernelModules: nvidia_modeset nvidia
ApportVersion: 2.20.11-0ubuntu27.11
Architecture: amd64
CasperMD5CheckResult: skip
CurrentDesktop: ubuntu:GNOME
Date: Thu Nov 12 13:58:35 2020
InstallationDate: Installed on 2020-04-19 (206 days ago)
InstallationMedia: Ubuntu 20.04 LTS "Focal Fossa" - Beta amd64 (20200417)
SourcePackage: upower
UpgradeStatus: No upgrade log present (probably fresh install)
mtime.conffile..etc.apport.crashdb.conf: 2020-06-17T11:02:56.934699
To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/upower/+bug/1903995/+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 1902225] Update Released
The verification of the Stable Release Update for gdb has completed successfully and the package is now being released to -updates. Subsequently, the Ubuntu Stable Release Updates Team is being unsubscribed and will not receive messages about this bug report. In the event that you encounter a regression using the package from -updates please report a new bug using ubuntu-bug and tag the bug report regression-update so we can easily find any regressions. -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to gdb in Ubuntu. https://bugs.launchpad.net/bugs/1902225 Title: SRU: update gdb 8.1.1 for 18.04 LTS Status in gdb package in Ubuntu: New Status in gdb source package in Bionic: Fix Released Bug description: gdb 8.1.1 is a minor bug fix release for 8.1. Some of the issues fixed in 8.1.1 are already fixed in the branch update in 8.1-0ubuntu3: * gdb 8.1.1 release. This is a minor corrective release over GDB 8.1, fixing following issues: - PR gdb/23028 (inconsistent disassemble of vcvtpd2dq) - PR gdb/23053 (Fix -D_GLIBCXX_DEBUG gdb-add-index regression) - PR gdb/23127 ([AArch64] GDB cannot be used for debugging software that uses high Virtual Addresses) - PR server/23158 (gdbserver no longer functional on Windows) - PR breakpoints/23210 ([8.1/8.2 Regression] Bogus Breakpoint address adjusted from 0xf7fe7dd3 to 0xf7fe7dd3) Already fixed in 8.1-0ubuntu3: - PR gdb/22824 (misleading description of new rbreak Python function in GDB 8.1 NEWS file) - PR gdb/22849 (ctrl-c doesn't work in extended-remote) - PR gdb/22907 ([Regression] gdbserver doesn't work with filename-only binaries). * Allow remote debugging over a Unix local domain socket. LP: #1901026. This minor version update fixes four upstream issues (not counting the Windows specific issue), plus allows remote debugging over a Unix local domain socket., a patch taken from the 8.2 development. Validation: The tests run during build time are passing, and the remote debugging is checked to be working (no automated test case). To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/gdb/+bug/1902225/+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 1901026] Update Released
The verification of the Stable Release Update for gdb has completed successfully and the package is now being released to -updates. Subsequently, the Ubuntu Stable Release Updates Team is being unsubscribed and will not receive messages about this bug report. In the event that you encounter a regression using the package from -updates please report a new bug using ubuntu-bug and tag the bug report regression-update so we can easily find any regressions. -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to gdb in Ubuntu. https://bugs.launchpad.net/bugs/1901026 Title: [GDB] No socket file connection support Status in gdb package in Ubuntu: New Status in gdb source package in Bionic: Fix Released Bug description: GDB on Ubuntu 18.04 (GNU gdb (Ubuntu 8.1-0ubuntu3.2) 8.1.0.20180409-git) does not support connecting to a remote target via a socket file. This is the error we get: (gdb) target remote /run/user/1000/at-spi2-QTZBS0/socket /run/user/1000/at-spi2-QTZBS0/socket: No such device or address. Commit c1168a2f66553cd4730931cf59e3be8378a1a03f enables this in GDB. It would be nice to have it backported. Here's the commit link: https://sourceware.org/git/?p=binutils- gdb.git;a=commit;h=c1168a2f66553cd4730931cf59e3be8378a1a03f To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/gdb/+bug/1901026/+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 1901026] Re: [GDB] No socket file connection support
This bug was fixed in the package gdb - 8.1.1-0ubuntu1 --- gdb (8.1.1-0ubuntu1) bionic-proposed; urgency=medium * SRU: LP: #1902225: gdb 8.1.1 release. This is a minor corrective release over GDB 8.1, fixing following issues: - PR gdb/23028 (inconsistent disassemble of vcvtpd2dq) - PR gdb/23053 (Fix -D_GLIBCXX_DEBUG gdb-add-index regression) - PR gdb/23127 ([AArch64] GDB cannot be used for debugging software that uses high Virtual Addresses) - PR server/23158 (gdbserver no longer functional on Windows) - PR breakpoints/23210 ([8.1/8.2 Regression] Bogus Breakpoint address adjusted from 0xf7fe7dd3 to 0xf7fe7dd3) Already fixed in 8.1-0ubuntu3: - PR gdb/22824 (misleading description of new rbreak Python function in GDB 8.1 NEWS file) - PR gdb/22849 (ctrl-c doesn't work in extended-remote) - PR gdb/22907 ([Regression] gdbserver doesn't work with filename-only binaries). * Allow remote debugging over a Unix local domain socket. LP: #1901026. -- Matthias Klose Fri, 30 Oct 2020 12:45:46 +0100 ** Changed in: gdb (Ubuntu Bionic) Status: Fix Committed => Fix Released -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to gdb in Ubuntu. https://bugs.launchpad.net/bugs/1901026 Title: [GDB] No socket file connection support Status in gdb package in Ubuntu: New Status in gdb source package in Bionic: Fix Released Bug description: GDB on Ubuntu 18.04 (GNU gdb (Ubuntu 8.1-0ubuntu3.2) 8.1.0.20180409-git) does not support connecting to a remote target via a socket file. This is the error we get: (gdb) target remote /run/user/1000/at-spi2-QTZBS0/socket /run/user/1000/at-spi2-QTZBS0/socket: No such device or address. Commit c1168a2f66553cd4730931cf59e3be8378a1a03f enables this in GDB. It would be nice to have it backported. Here's the commit link: https://sourceware.org/git/?p=binutils- gdb.git;a=commit;h=c1168a2f66553cd4730931cf59e3be8378a1a03f To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/gdb/+bug/1901026/+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 1902225] Re: SRU: update gdb 8.1.1 for 18.04 LTS
This bug was fixed in the package gdb - 8.1.1-0ubuntu1 --- gdb (8.1.1-0ubuntu1) bionic-proposed; urgency=medium * SRU: LP: #1902225: gdb 8.1.1 release. This is a minor corrective release over GDB 8.1, fixing following issues: - PR gdb/23028 (inconsistent disassemble of vcvtpd2dq) - PR gdb/23053 (Fix -D_GLIBCXX_DEBUG gdb-add-index regression) - PR gdb/23127 ([AArch64] GDB cannot be used for debugging software that uses high Virtual Addresses) - PR server/23158 (gdbserver no longer functional on Windows) - PR breakpoints/23210 ([8.1/8.2 Regression] Bogus Breakpoint address adjusted from 0xf7fe7dd3 to 0xf7fe7dd3) Already fixed in 8.1-0ubuntu3: - PR gdb/22824 (misleading description of new rbreak Python function in GDB 8.1 NEWS file) - PR gdb/22849 (ctrl-c doesn't work in extended-remote) - PR gdb/22907 ([Regression] gdbserver doesn't work with filename-only binaries). * Allow remote debugging over a Unix local domain socket. LP: #1901026. -- Matthias Klose Fri, 30 Oct 2020 12:45:46 +0100 ** Changed in: gdb (Ubuntu Bionic) Status: Fix Committed => Fix Released -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to gdb in Ubuntu. https://bugs.launchpad.net/bugs/1902225 Title: SRU: update gdb 8.1.1 for 18.04 LTS Status in gdb package in Ubuntu: New Status in gdb source package in Bionic: Fix Released Bug description: gdb 8.1.1 is a minor bug fix release for 8.1. Some of the issues fixed in 8.1.1 are already fixed in the branch update in 8.1-0ubuntu3: * gdb 8.1.1 release. This is a minor corrective release over GDB 8.1, fixing following issues: - PR gdb/23028 (inconsistent disassemble of vcvtpd2dq) - PR gdb/23053 (Fix -D_GLIBCXX_DEBUG gdb-add-index regression) - PR gdb/23127 ([AArch64] GDB cannot be used for debugging software that uses high Virtual Addresses) - PR server/23158 (gdbserver no longer functional on Windows) - PR breakpoints/23210 ([8.1/8.2 Regression] Bogus Breakpoint address adjusted from 0xf7fe7dd3 to 0xf7fe7dd3) Already fixed in 8.1-0ubuntu3: - PR gdb/22824 (misleading description of new rbreak Python function in GDB 8.1 NEWS file) - PR gdb/22849 (ctrl-c doesn't work in extended-remote) - PR gdb/22907 ([Regression] gdbserver doesn't work with filename-only binaries). * Allow remote debugging over a Unix local domain socket. LP: #1901026. This minor version update fixes four upstream issues (not counting the Windows specific issue), plus allows remote debugging over a Unix local domain socket., a patch taken from the 8.2 development. Validation: The tests run during build time are passing, and the remote debugging is checked to be working (no automated test case). To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/gdb/+bug/1902225/+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 972077] Re: apt repository disk format has race conditions
Affected me too -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to apt in Ubuntu. https://bugs.launchpad.net/bugs/972077 Title: apt repository disk format has race conditions Status in APT: Fix Released Status in apt package in Ubuntu: Fix Released Bug description: Apt archives are accessed over HTTP; this has resulted in a cluster of bugs (reported here, and upstream) about problems behind intercepting caches, problems with squid etc. There are 3 interlocking issues: A - mirror networks may be out of sync with each other (e.g. a file named on one mirror may no longer exist, or may not yet exist, on another mirror) B - updating files on a single mirror is not atomic - and even small windows of inconsistency will, given enough clients, cause headaches. C - caches exacerbate race conditions - when one happens, until the cached data expires, all clients of the cache will suffer from the race Solving this requires one of several things: - file system transactions - an archive format that requires only weakly ordered updates to the files at particular urls with the assumption that only one file may be observed to change at a time (because a lookup of file A, then B, may get a cache miss on A and a cache hit on B, so even if all clients strictly go A, then B, updates may still see old files when paths are reused). - super robust clients that repeatedly retry with progressively less cache friendly headers until they have a consistent view. (This is very tricky to do). It may be possible to do a tweak to the apt repository format though, which would allow publishing a race-free format in parallel with the existing layout, while clients migrate. To be safe against issue (A) the mirror network would need some care around handling of dns round- robin mirrors [to minimise the situation where referenced data is not available], but this should be doable - or alternatively clients doing 'apt-get update' may need to be willing to retry to accommodate round- robin skew. What would such an archive format look like? It would have only one well known file name (InRelease), which would be internally signed. Rather than signing e.g. Packages.gz, it would sign a uniquely named packages and sources file - e.g. Packages-$HASH.gz or Packages-$serialno.gz. Backwards compatibility is achieved by using the same filenames for deb's and the like. We need to keep writing Packages.gz though, and Releases, until we no longer worry about old apt clients. We can optimise disk space a little by making Packages.gz a symlink to a Packages-$HASH.gz (and so on for Sources..), but it may be simpler and less prone to unexpected behaviour to keep using regular files. tl;dr * Unique file names for all unique file content with one exception * InRelease, a self-signed file that provides hashes and names the index files (Packages, Sources, Translations etc) * Coexists with existing archive layout Related bugs: * bug 804252: Please support InRelease files * bug 1430011: support apt by-hash mirrors To manage notifications about this bug go to: https://bugs.launchpad.net/apt/+bug/972077/+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 1903975] Re: Hashsum mismatch Commands-amd64.xz rsync://archive.ubuntu.com
Should not be package apt. Changed to project debmirror. ** Package changed: apt (Ubuntu) => debmirror ** Changed in: debmirror Status: Invalid => New -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to apt in Ubuntu. https://bugs.launchpad.net/bugs/1903975 Title: Hashsum mismatch Commands-amd64.xz rsync://archive.ubuntu.com Status in debmirror: New Bug description: Package syncronisation on rsync://archive.ubuntu.com fails with error: $ time rsync rsync://archive.ubuntu.com This is an Ubuntu mirror - treat it kindly maas-images Ubuntu Old Releases releasesUbuntu Releases CD Images simple-streams Juju Simple Streams Mirror cloud-imagesUbuntu Cloud Images cdimage Ubuntu CD Images ubuntu Ubuntu Archive ubuntu-cloud-archiveUbuntu Cloud Archive old-releasesUbuntu Old Releases ubuntu-portsUbuntu Ports Archive real2m57.968s user0m0.000s sys 0m0.003s Nov 12 06:53:20 XXX XXX: Checking file:///srv/mirror/ubuntu/dists/focal-updates... Nov 12 06:53:20 XXX XXX: main/cnf/Commands-amd64.xz: Hashsum mismatch. Expected: 6404594deb82bdbe27b34d9b6e245c44bfc0a7319a456f94046814a7bcbfe1ad Found: 8ac1ce39639806e308b85efa4a323afaf6448c082a5728d1d7e99c3e1e431369 Nov 12 06:53:20 XXX XXX: main/cnf/Commands-i386.xz: Hashsum mismatch. Expected: 3d1e38232e7550131e09c210d1e4e94c92070812f3cf4aaebf7dc841ad7d6ead Found: c250b8713c4c357cdd097922ae8332eec26aef9159f48df9e3ab1194d3c44307 Nov 12 06:53:20 XXX XXX: Checking file:///srv/mirror/ubuntu/dists/focal-security... Nov 12 06:53:20 XXX XXX: main/cnf/Commands-amd64.xz: Hashsum mismatch. Expected: aabc61d5a794fd7cc5cb5100633abfbedc6e241657458e7d09cfda85600fc756 Found: c8922ff82fbd02a7f6b80ca5e13b0a6ba3f694e231b65973fa0621d7c2ad5ded Nov 12 06:53:20 XXX XXX: main/cnf/Commands-i386.xz: Hashsum mismatch. Expected: 4f0b2ffa3e742e99278c0abe6eda69cd2d7a18d3e8de8e1e5b363b8289abf6c0 Found: 63434a5ca02388a3c6a06b973c3341a7a31bde4027bc91123e7f2fb8a5efb4d8 (…) To manage notifications about this bug go to: https://bugs.launchpad.net/debmirror/+bug/1903975/+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 1903995] Re: upower report wrong battery percentage for Logitech Unify devices
The notification issue is also discussed on
https://gitlab.gnome.org/GNOME/gnome-settings-daemon/-/issues/108
--
You received this bug notification because you are a member of Ubuntu
Touch seeded packages, which is subscribed to upower in Ubuntu.
https://bugs.launchpad.net/bugs/1903995
Title:
upower report wrong battery percentage for Logitech Unify devices
Status in upower package in Ubuntu:
Triaged
Bug description:
The battery percentage reported by upower for Logitech devices
connected using Unify receiver are wrong. Below are the results for
two devices: Mouse and Keyboard:
* Battery percentages reported by Unify receiver using Solaar:
$ solaar show | grep -iP "^(( \d: )|(.*batt.*))"
1: Wireless Keyboard K270(unifying)
4: BATTERY STATUS {1000}
Battery: 70%, discharging.
2: Wireless Mouse MX Master
7: BATTERY STATUS {1000}
Battery: 20%, discharging.
* Battery percentages reported by upower:
$ upower -i /org/freedesktop/UPower/devices/keyboard_hidpp_battery_0
native-path: hidpp_battery_0
model:Wireless Keyboard K270
serial: 4003-1a-39-5f-c1
power supply: no
updated: Thu 12 Nov 2020 13:59:18 CET (119 seconds ago)
has history: yes
has statistics: yes
keyboard
present: yes
rechargeable:yes
state: discharging
warning-level: none
battery-level: normal
percentage: 55% (should be ignored)
icon-name: 'battery-low-symbolic'
$ upower -i /org/freedesktop/UPower/devices/mouse_hidpp_battery_1
native-path: hidpp_battery_1
model:Wireless Mouse MX Master
serial: 4071-f8-eb-bf-d1
power supply: no
updated: Thu 12 Nov 2020 14:03:14 CET (27 seconds ago)
has history: yes
has statistics: yes
mouse
present: yes
rechargeable:yes
state: discharging
warning-level: low
battery-level: low
percentage: 10% (should be ignored)
icon-name: 'battery-caution-symbolic'
Basically the difference is big so I'm getting a lot of notifications
related to low battery even if the battery is OK:
* Mouse, upower: 10%real (Solaar): 20%
* Keyboard: upower: 70%real (Solaar): 55%
ProblemType: Bug
DistroRelease: Ubuntu 20.04
Package: upower 0.99.11-1build2
ProcVersionSignature: Ubuntu 5.4.0-53.59-generic 5.4.65
Uname: Linux 5.4.0-53-generic x86_64
NonfreeKernelModules: nvidia_modeset nvidia
ApportVersion: 2.20.11-0ubuntu27.11
Architecture: amd64
CasperMD5CheckResult: skip
CurrentDesktop: ubuntu:GNOME
Date: Thu Nov 12 13:58:35 2020
InstallationDate: Installed on 2020-04-19 (206 days ago)
InstallationMedia: Ubuntu 20.04 LTS "Focal Fossa" - Beta amd64 (20200417)
SourcePackage: upower
UpgradeStatus: No upgrade log present (probably fresh install)
mtime.conffile..etc.apport.crashdb.conf: 2020-06-17T11:02:56.934699
To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/upower/+bug/1903995/+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 1903516] Re: aborted (core dumped) when using ConnectTimeout > 2147483
Hi Paride, Thanks for filing the upstream bug report. I totally agree that this bug is of low importance. My colleague actually encountered this problem because he really didn't want a SSH tunnel to time out. He could not figure out what was causing the crash but I found it out after some digging. So I thought it would be useful if the client would give a proper error message, so other people who might encounter this who can't figure it out will also be able to know why it crashes. -- 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/1903516 Title: aborted (core dumped) when using ConnectTimeout > 2147483 Status in portable OpenSSH: Unknown Status in openssh package in Ubuntu: Triaged Bug description: The ssh client fails with the message "Aborted (core dumped)" when setting the ConnectTimeout to 2147484 or higher. lsb_release: Linux Mint 20 (but also tested this on latest ubuntu:20.04 docker container) openssh-client version: 1:8.2p1-4ubuntu0.1 I expected that either the connect timeout would be used correctly, or that it would fail with a proper error message saying the connect timeout can't be higher than 2147483. What happened: $ ssh -o "ConnectTimeout=2147484" localhost Aborted (core dumped) To manage notifications about this bug go to: https://bugs.launchpad.net/openssh/+bug/1903516/+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 1903995] Re: upower report wrong battery percentage for Logitech Unify devices
Thank you for your bug report, there are similar reports upstream
https://gitlab.freedesktop.org/upower/upower/-/issues/119
not that upower does label them 'should be ignored' which hint it's a
known limitation or problematic value
** Bug watch added: gitlab.freedesktop.org/upower/upower/-/issues #119
https://gitlab.freedesktop.org/upower/upower/-/issues/119
** Changed in: upower (Ubuntu)
Importance: Undecided => High
** Changed in: upower (Ubuntu)
Status: New => Triaged
** Bug watch added: gitlab.gnome.org/GNOME/gnome-settings-daemon/-/issues #108
https://gitlab.gnome.org/GNOME/gnome-settings-daemon/-/issues/108
--
You received this bug notification because you are a member of Ubuntu
Touch seeded packages, which is subscribed to upower in Ubuntu.
https://bugs.launchpad.net/bugs/1903995
Title:
upower report wrong battery percentage for Logitech Unify devices
Status in upower package in Ubuntu:
Triaged
Bug description:
The battery percentage reported by upower for Logitech devices
connected using Unify receiver are wrong. Below are the results for
two devices: Mouse and Keyboard:
* Battery percentages reported by Unify receiver using Solaar:
$ solaar show | grep -iP "^(( \d: )|(.*batt.*))"
1: Wireless Keyboard K270(unifying)
4: BATTERY STATUS {1000}
Battery: 70%, discharging.
2: Wireless Mouse MX Master
7: BATTERY STATUS {1000}
Battery: 20%, discharging.
* Battery percentages reported by upower:
$ upower -i /org/freedesktop/UPower/devices/keyboard_hidpp_battery_0
native-path: hidpp_battery_0
model:Wireless Keyboard K270
serial: 4003-1a-39-5f-c1
power supply: no
updated: Thu 12 Nov 2020 13:59:18 CET (119 seconds ago)
has history: yes
has statistics: yes
keyboard
present: yes
rechargeable:yes
state: discharging
warning-level: none
battery-level: normal
percentage: 55% (should be ignored)
icon-name: 'battery-low-symbolic'
$ upower -i /org/freedesktop/UPower/devices/mouse_hidpp_battery_1
native-path: hidpp_battery_1
model:Wireless Mouse MX Master
serial: 4071-f8-eb-bf-d1
power supply: no
updated: Thu 12 Nov 2020 14:03:14 CET (27 seconds ago)
has history: yes
has statistics: yes
mouse
present: yes
rechargeable:yes
state: discharging
warning-level: low
battery-level: low
percentage: 10% (should be ignored)
icon-name: 'battery-caution-symbolic'
Basically the difference is big so I'm getting a lot of notifications
related to low battery even if the battery is OK:
* Mouse, upower: 10%real (Solaar): 20%
* Keyboard: upower: 70%real (Solaar): 55%
ProblemType: Bug
DistroRelease: Ubuntu 20.04
Package: upower 0.99.11-1build2
ProcVersionSignature: Ubuntu 5.4.0-53.59-generic 5.4.65
Uname: Linux 5.4.0-53-generic x86_64
NonfreeKernelModules: nvidia_modeset nvidia
ApportVersion: 2.20.11-0ubuntu27.11
Architecture: amd64
CasperMD5CheckResult: skip
CurrentDesktop: ubuntu:GNOME
Date: Thu Nov 12 13:58:35 2020
InstallationDate: Installed on 2020-04-19 (206 days ago)
InstallationMedia: Ubuntu 20.04 LTS "Focal Fossa" - Beta amd64 (20200417)
SourcePackage: upower
UpgradeStatus: No upgrade log present (probably fresh install)
mtime.conffile..etc.apport.crashdb.conf: 2020-06-17T11:02:56.934699
To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/upower/+bug/1903995/+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 1903048] Re: [SRU] Bluetooth won't activate on the pi 400
> Was the revert discussed somewhere before being performed? I pinged you guys on IRC some days ago but didn't get any comment back -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to bluez in Ubuntu. https://bugs.launchpad.net/bugs/1903048 Title: [SRU] Bluetooth won't activate on the pi 400 Status in bluez package in Ubuntu: Triaged Status in bluez source package in Hirsute: Triaged Bug description: [Impact] Without these patches, Bluetooth is inoperable on the recently released Raspberry Pi 400. [Test Case] * Boot the Ubuntu Desktop for Pi image on a Pi 400. * Start the Settings application and switch to the Bluetooth tab * Verify that Bluetooth is not enabled and attempting to activate it fails * sudo add-apt-repository ppa:waveform/pi-bluetooth * sudo apt update * sudo apt install bluez * sudo reboot * Start the Settings application and switch to the Bluetooth tab * Verify that Bluetooth is active and that Bluetooth devices (e.g. mice, mobile phones, headphones, etc.) can connect and operate correctly [Regression Potential] Extremely low (on groovy in particular, this has the same version of bluez as hirsute). The only significant risk is to non-Pi platforms or dongles which also use the Broadcom 43xx (or Cypress 305) chips for Bluetooth which might be inadvertently affected by these patches. [Original Description] The new Pi 400 has a slightly different Wifi/BT chip to the Pi4. Whilst wifi works happily, Bluetooth fails to operate. This doesn't appear to be an issue with either the firmware (the latest versions from upstream Raspbian have been tried), or the kernel (a known-good raspi kernel has been tested under Ubuntu), but with Bluez itself. Specifically, tracing the initialization with btmon on Raspbian and Ubuntu, the stack consistently fails when attempting to "Set Default PHY" on the latter. Curiously, under Ubuntu the adapter also appears to lack a MAC address. To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/bluez/+bug/1903048/+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 1903048] Re: [SRU] Bluetooth won't activate on the pi 400
> in the meantime maintain the patches ourselves as many others related to the Pi (as in various other projects) I'm not asking for the patches to be merged upstream but at least to be sent there for review and have the appropriate tagging, it's easy to unblock from your side. Also I would like to see if we can get for a better way to probe for the system to be ready rather than relying on a random sleep -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to bluez in Ubuntu. https://bugs.launchpad.net/bugs/1903048 Title: [SRU] Bluetooth won't activate on the pi 400 Status in bluez package in Ubuntu: Triaged Status in bluez source package in Hirsute: Triaged Bug description: [Impact] Without these patches, Bluetooth is inoperable on the recently released Raspberry Pi 400. [Test Case] * Boot the Ubuntu Desktop for Pi image on a Pi 400. * Start the Settings application and switch to the Bluetooth tab * Verify that Bluetooth is not enabled and attempting to activate it fails * sudo add-apt-repository ppa:waveform/pi-bluetooth * sudo apt update * sudo apt install bluez * sudo reboot * Start the Settings application and switch to the Bluetooth tab * Verify that Bluetooth is active and that Bluetooth devices (e.g. mice, mobile phones, headphones, etc.) can connect and operate correctly [Regression Potential] Extremely low (on groovy in particular, this has the same version of bluez as hirsute). The only significant risk is to non-Pi platforms or dongles which also use the Broadcom 43xx (or Cypress 305) chips for Bluetooth which might be inadvertently affected by these patches. [Original Description] The new Pi 400 has a slightly different Wifi/BT chip to the Pi4. Whilst wifi works happily, Bluetooth fails to operate. This doesn't appear to be an issue with either the firmware (the latest versions from upstream Raspbian have been tried), or the kernel (a known-good raspi kernel has been tested under Ubuntu), but with Bluez itself. Specifically, tracing the initialization with btmon on Raspbian and Ubuntu, the stack consistently fails when attempting to "Set Default PHY" on the latter. Curiously, under Ubuntu the adapter also appears to lack a MAC address. To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/bluez/+bug/1903048/+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 1903995] [NEW] upower report wrong battery percentage for Logitech Unify devices
Public bug reported:
The battery percentage reported by upower for Logitech devices connected
using Unify receiver are wrong. Below are the results for two devices:
Mouse and Keyboard:
* Battery percentages reported by Unify receiver using Solaar:
$ solaar show | grep -iP "^(( \d: )|(.*batt.*))"
1: Wireless Keyboard K270(unifying)
4: BATTERY STATUS {1000}
Battery: 70%, discharging.
2: Wireless Mouse MX Master
7: BATTERY STATUS {1000}
Battery: 20%, discharging.
* Battery percentages reported by upower:
$ upower -i /org/freedesktop/UPower/devices/keyboard_hidpp_battery_0
native-path: hidpp_battery_0
model:Wireless Keyboard K270
serial: 4003-1a-39-5f-c1
power supply: no
updated: Thu 12 Nov 2020 13:59:18 CET (119 seconds ago)
has history: yes
has statistics: yes
keyboard
present: yes
rechargeable:yes
state: discharging
warning-level: none
battery-level: normal
percentage: 55% (should be ignored)
icon-name: 'battery-low-symbolic'
$ upower -i /org/freedesktop/UPower/devices/mouse_hidpp_battery_1
native-path: hidpp_battery_1
model:Wireless Mouse MX Master
serial: 4071-f8-eb-bf-d1
power supply: no
updated: Thu 12 Nov 2020 14:03:14 CET (27 seconds ago)
has history: yes
has statistics: yes
mouse
present: yes
rechargeable:yes
state: discharging
warning-level: low
battery-level: low
percentage: 10% (should be ignored)
icon-name: 'battery-caution-symbolic'
Basically the difference is big so I'm getting a lot of notifications
related to low battery even if the battery is OK:
* Mouse, upower: 10%real (Solaar): 20%
* Keyboard: upower: 70%real (Solaar): 55%
ProblemType: Bug
DistroRelease: Ubuntu 20.04
Package: upower 0.99.11-1build2
ProcVersionSignature: Ubuntu 5.4.0-53.59-generic 5.4.65
Uname: Linux 5.4.0-53-generic x86_64
NonfreeKernelModules: nvidia_modeset nvidia
ApportVersion: 2.20.11-0ubuntu27.11
Architecture: amd64
CasperMD5CheckResult: skip
CurrentDesktop: ubuntu:GNOME
Date: Thu Nov 12 13:58:35 2020
InstallationDate: Installed on 2020-04-19 (206 days ago)
InstallationMedia: Ubuntu 20.04 LTS "Focal Fossa" - Beta amd64 (20200417)
SourcePackage: upower
UpgradeStatus: No upgrade log present (probably fresh install)
mtime.conffile..etc.apport.crashdb.conf: 2020-06-17T11:02:56.934699
** Affects: upower (Ubuntu)
Importance: Undecided
Status: New
** Tags: amd64 apport-bug focal
** Description changed:
The battery percentage reported by upower for Logitech devices connected
using Unify receiver are wrong. Below are the results for two devices:
Mouse and Keyboard:
-
* Battery percentages reported by Unify receiver using Solaar:
$ solaar show | grep -iP "^(( \d: )|(.*batt.*))"
- 1: Wireless Keyboard K270(unifying)
- 4: BATTERY STATUS {1000}
- Battery: 70%, discharging.
- 2: Wireless Mouse MX Master
- 7: BATTERY STATUS {1000}
- Battery: 20%, discharging.
+ 1: Wireless Keyboard K270(unifying)
+ 4: BATTERY STATUS {1000}
+ Battery: 70%, discharging.
+ 2: Wireless Mouse MX Master
+ 7: BATTERY STATUS {1000}
+ Battery: 20%, discharging.
* Battery percentages reported by upower:
+
$ upower -i /org/freedesktop/UPower/devices/keyboard_hidpp_battery_0
- native-path: hidpp_battery_0
- model:Wireless Keyboard K270
- serial: 4003-1a-39-5f-c1
- power supply: no
- updated: Thu 12 Nov 2020 13:59:18 CET (119 seconds ago)
- has history: yes
- has statistics: yes
- keyboard
- present: yes
- rechargeable:yes
- state: discharging
- warning-level: none
- battery-level: normal
- percentage: 55% (should be ignored)
- icon-name: 'battery-low-symbolic'
+ native-path: hidpp_battery_0
+ model:Wireless Keyboard K270
+ serial: 4003-1a-39-5f-c1
+ power supply: no
+ updated: Thu 12 Nov 2020 13:59:18 CET (119 seconds ago)
+ has history: yes
+ has statistics: yes
+ keyboard
+ present: yes
+ rechargeable:yes
+ state: discharging
+ warning-level: none
+ battery-level: normal
+ percentage: 55% (should be ignored)
+ icon-name: 'battery-low-symbolic'
- $ upower -i /org/freedesktop/UPower/devices/mouse_hidpp_battery_1
- native-path: hidpp_battery_1
- model:Wireless Mouse MX Master
- serial:
[Touch-packages] [Bug 1903048] Re: [SRU] Bluetooth won't activate on the pi 400
I personally think the revert is a bit extreme. Even though we are not maintainers of bluez, this being a critical feature for the Pi400 we would of course make sure that the changes get upstreamed as much as possible and in the meantime maintain the patches ourselves as many others related to the Pi (as in various other projects). Without this fix the Pi400 is basically broken, so we wanted to unblock users as soon as possible (for groovy) - the certification team is pushing hard on this since a while. Was the revert discussed somewhere before being performed? -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to bluez in Ubuntu. https://bugs.launchpad.net/bugs/1903048 Title: [SRU] Bluetooth won't activate on the pi 400 Status in bluez package in Ubuntu: Triaged Status in bluez source package in Hirsute: Triaged Bug description: [Impact] Without these patches, Bluetooth is inoperable on the recently released Raspberry Pi 400. [Test Case] * Boot the Ubuntu Desktop for Pi image on a Pi 400. * Start the Settings application and switch to the Bluetooth tab * Verify that Bluetooth is not enabled and attempting to activate it fails * sudo add-apt-repository ppa:waveform/pi-bluetooth * sudo apt update * sudo apt install bluez * sudo reboot * Start the Settings application and switch to the Bluetooth tab * Verify that Bluetooth is active and that Bluetooth devices (e.g. mice, mobile phones, headphones, etc.) can connect and operate correctly [Regression Potential] Extremely low (on groovy in particular, this has the same version of bluez as hirsute). The only significant risk is to non-Pi platforms or dongles which also use the Broadcom 43xx (or Cypress 305) chips for Bluetooth which might be inadvertently affected by these patches. [Original Description] The new Pi 400 has a slightly different Wifi/BT chip to the Pi4. Whilst wifi works happily, Bluetooth fails to operate. This doesn't appear to be an issue with either the firmware (the latest versions from upstream Raspbian have been tried), or the kernel (a known-good raspi kernel has been tested under Ubuntu), but with Bluez itself. Specifically, tracing the initialization with btmon on Raspbian and Ubuntu, the stack consistently fails when attempting to "Set Default PHY" on the latter. Curiously, under Ubuntu the adapter also appears to lack a MAC address. To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/bluez/+bug/1903048/+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 1897620] Re: ABI breakage: paths changed for sysusers.d/sysctl.d/binfmt/modules-load.d
This bug was fixed in the package systemd - 246.6-2ubuntu1 --- systemd (246.6-2ubuntu1) hirsute; urgency=medium [ Dan Streetman ] * d/t/boot-smoke: update test to avoid false negatives File: debian/tests/boot-smoke https://git.launchpad.net/~ubuntu-core-dev/ubuntu/+source/systemd/commit/?id=205c30ca53b0e421db28bb56afaf5f88650ce592 * d/t/boot-and-services: remove unneeded test lines File: debian/tests/boot-and-services https://git.launchpad.net/~ubuntu-core-dev/ubuntu/+source/systemd/commit/?id=71853082af4e668996db574915c5a156f9897fd3 * d/t/systemd-fsckd: rewrite test to try to fix false negatives (LP: #1892358) Files: - debian/tests/control - debian/tests/systemd-fsckd https://git.launchpad.net/~ubuntu-core-dev/ubuntu/+source/systemd/commit/?id=6ae6be039ec582410769d2d6d131e12bdcd19a68 [ Balint Reczey ] * debian/gbp.conf: Update debian-branch to ubuntu-hirsute File: debian/gbp.conf https://git.launchpad.net/~ubuntu-core-dev/ubuntu/+source/systemd/commit/?id=e0b78512dbb5141458468ba5e9c2a4e966ada088 * Merge from Debian unstable - Move sysusers.d/sysctl.d/binfmt.d/modules-load.d back to /usr (LP: #1897620) * debian/tests/systemd-fsckd: Plymouth-start stays active in 20.10 and later (LP: #1892358) File: debian/tests/systemd-fsckd https://git.launchpad.net/~ubuntu-core-dev/ubuntu/+source/systemd/commit/?id=c46eda821e97df5595a4cdc5f5c41a9b49a51745 systemd (246.6-2) unstable; urgency=medium * XDG autostart improvements - Add support for Path= in XDG Desktop File - Ignore more common XDG Desktop Entry fields - Lower most info messages to debug level (Closes: #968116) * Re-enable seccomp support on riscv64. This should be safe now, as the code has fallbacks for systems with older libseccomp versions. * Move sysusers.d/sysctl.d/binfmt.d/modules-load.d back to /usr. In Debian, late mounting of /usr is no longer supported, so it is safe to install those files in /usr. We want those facilities in /usr, not /, as this will make an eventual switch to a merged-usr setup easier. (Closes: #971282) * units: update serial-getty@.service to support 57600 baud rate (Closes: #969144) * bootspec: don't fail with EIO if searching for ESP and finding one without an enveloping partition table (Closes: #970534) -- Balint Reczey Thu, 29 Oct 2020 18:38:15 +0100 ** Changed in: systemd (Ubuntu) Status: New => Fix Released -- 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/1897620 Title: ABI breakage: paths changed for sysusers.d/sysctl.d/binfmt/modules- load.d Status in systemd package in Ubuntu: Fix Released Status in systemd package in Debian: New Bug description: Imported from Debian bug http://bugs.debian.org/971282: Package: systemd Version: 246.6-1 Severity: important Upstream changed the paths in systemd.pc from prefix to rootprefix in v246 for sysusers_dir, sysctl_dir, binfmt_dir and modules-load_dir: https://github.com/systemd/systemd/commit/4a56315a990b802860170ecd1bbd3eb68e14a38b This breaks packages which use pkg-config to determine those paths and where .install files reference /usr/. An example is mandos. I think we should revert this change. I don't see a compelling reason to move those files from /usr to /lib given that we require /usr to be pre-mounted by initramfs, if it's separate. Moving files from /usr to /lib files kinda backwards nowadays. I intend to apply a patch like the attached one in Debian. That said, I hope I can convince Lennart to revert this change upstream as well. Thoughts, Comments? Michael To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/systemd/+bug/1897620/+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 1903516] Re: aborted (core dumped) when using ConnectTimeout > 2147483
Hello Bert and thanks for this bug report. I could easily reproduce the issue you described, but I think it would best be fixed upstream rather than with an Ubuntu specific patch. I filed an upstream bug report [1] and linked it to this one. Given that triggering this bug requires a very odd setting I'm marking this report with Importance: Low. Should there be an actual use case for such a high timeout please explain it in a comment and we'll re-evaluate the bug importance. Thanks! [1] https://bugzilla.mindrot.org/show_bug.cgi?id=3229 ** Changed in: openssh (Ubuntu) Importance: Undecided => Low ** Changed in: openssh (Ubuntu) Status: Incomplete => Triaged -- 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/1903516 Title: aborted (core dumped) when using ConnectTimeout > 2147483 Status in portable OpenSSH: Unknown Status in openssh package in Ubuntu: Triaged Bug description: The ssh client fails with the message "Aborted (core dumped)" when setting the ConnectTimeout to 2147484 or higher. lsb_release: Linux Mint 20 (but also tested this on latest ubuntu:20.04 docker container) openssh-client version: 1:8.2p1-4ubuntu0.1 I expected that either the connect timeout would be used correctly, or that it would fail with a proper error message saying the connect timeout can't be higher than 2147483. What happened: $ ssh -o "ConnectTimeout=2147484" localhost Aborted (core dumped) To manage notifications about this bug go to: https://bugs.launchpad.net/openssh/+bug/1903516/+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 1903516] Re: aborted (core dumped) when using ConnectTimeout > 2147483
** Bug watch added: OpenSSH Portable Bugzilla #3229 https://bugzilla.mindrot.org/show_bug.cgi?id=3229 ** Also affects: openssh via https://bugzilla.mindrot.org/show_bug.cgi?id=3229 Importance: Unknown Status: Unknown -- 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/1903516 Title: aborted (core dumped) when using ConnectTimeout > 2147483 Status in portable OpenSSH: Unknown Status in openssh package in Ubuntu: Incomplete Bug description: The ssh client fails with the message "Aborted (core dumped)" when setting the ConnectTimeout to 2147484 or higher. lsb_release: Linux Mint 20 (but also tested this on latest ubuntu:20.04 docker container) openssh-client version: 1:8.2p1-4ubuntu0.1 I expected that either the connect timeout would be used correctly, or that it would fail with a proper error message saying the connect timeout can't be higher than 2147483. What happened: $ ssh -o "ConnectTimeout=2147484" localhost Aborted (core dumped) To manage notifications about this bug go to: https://bugs.launchpad.net/openssh/+bug/1903516/+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
Re: [Touch-packages] [Bug 1903048] Re: [SRU] Bluetooth won't activate on the pi 400
I understand the logic of the of doing this and don't disagree. However, as this is an entry level device and I believe the only true 64bit O/S advertised for this device, the fact that it does not not work out of the box may impact on the perception of potential new Ubuntu users? Reading Tony's post the Mate website does not say it will work on the PI400 where as the Ubuntu site does. I think the main issue is that people think it is the same board as the Pi4 and it is not. Just my opinion. On Thu, 2020-11-12 at 11:11 +, Sebastien Bacher wrote: > Sorry but I'm reverting that upload for now until the patches are > properly upstreamed. We have been bitten too often by unforwarded > changes that create issues or create maintainance burden over the > years > and we currently don't have the team capacity to deal with extra > cost. > If foundations would like to step up and take over bluez though > that's a > discussion we could have... > > ** Changed in: bluez (Ubuntu Hirsute) >Status: Fix Released => Triaged > -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to bluez in Ubuntu. https://bugs.launchpad.net/bugs/1903048 Title: [SRU] Bluetooth won't activate on the pi 400 Status in bluez package in Ubuntu: Triaged Status in bluez source package in Hirsute: Triaged Bug description: [Impact] Without these patches, Bluetooth is inoperable on the recently released Raspberry Pi 400. [Test Case] * Boot the Ubuntu Desktop for Pi image on a Pi 400. * Start the Settings application and switch to the Bluetooth tab * Verify that Bluetooth is not enabled and attempting to activate it fails * sudo add-apt-repository ppa:waveform/pi-bluetooth * sudo apt update * sudo apt install bluez * sudo reboot * Start the Settings application and switch to the Bluetooth tab * Verify that Bluetooth is active and that Bluetooth devices (e.g. mice, mobile phones, headphones, etc.) can connect and operate correctly [Regression Potential] Extremely low (on groovy in particular, this has the same version of bluez as hirsute). The only significant risk is to non-Pi platforms or dongles which also use the Broadcom 43xx (or Cypress 305) chips for Bluetooth which might be inadvertently affected by these patches. [Original Description] The new Pi 400 has a slightly different Wifi/BT chip to the Pi4. Whilst wifi works happily, Bluetooth fails to operate. This doesn't appear to be an issue with either the firmware (the latest versions from upstream Raspbian have been tried), or the kernel (a known-good raspi kernel has been tested under Ubuntu), but with Bluez itself. Specifically, tracing the initialization with btmon on Raspbian and Ubuntu, the stack consistently fails when attempting to "Set Default PHY" on the latter. Curiously, under Ubuntu the adapter also appears to lack a MAC address. To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/bluez/+bug/1903048/+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 1903975] Re: Hashsum mismatch Commands-amd64.xz rsync://archive.ubuntu.com
How is this a bug in apt? I don't see you use apt anywhere. ** Changed in: apt (Ubuntu) Status: New => Invalid -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to apt in Ubuntu. https://bugs.launchpad.net/bugs/1903975 Title: Hashsum mismatch Commands-amd64.xz rsync://archive.ubuntu.com Status in apt package in Ubuntu: Invalid Bug description: Package syncronisation on rsync://archive.ubuntu.com fails with error: $ time rsync rsync://archive.ubuntu.com This is an Ubuntu mirror - treat it kindly maas-images Ubuntu Old Releases releasesUbuntu Releases CD Images simple-streams Juju Simple Streams Mirror cloud-imagesUbuntu Cloud Images cdimage Ubuntu CD Images ubuntu Ubuntu Archive ubuntu-cloud-archiveUbuntu Cloud Archive old-releasesUbuntu Old Releases ubuntu-portsUbuntu Ports Archive real2m57.968s user0m0.000s sys 0m0.003s Nov 12 06:53:20 XXX XXX: Checking file:///srv/mirror/ubuntu/dists/focal-updates... Nov 12 06:53:20 XXX XXX: main/cnf/Commands-amd64.xz: Hashsum mismatch. Expected: 6404594deb82bdbe27b34d9b6e245c44bfc0a7319a456f94046814a7bcbfe1ad Found: 8ac1ce39639806e308b85efa4a323afaf6448c082a5728d1d7e99c3e1e431369 Nov 12 06:53:20 XXX XXX: main/cnf/Commands-i386.xz: Hashsum mismatch. Expected: 3d1e38232e7550131e09c210d1e4e94c92070812f3cf4aaebf7dc841ad7d6ead Found: c250b8713c4c357cdd097922ae8332eec26aef9159f48df9e3ab1194d3c44307 Nov 12 06:53:20 XXX XXX: Checking file:///srv/mirror/ubuntu/dists/focal-security... Nov 12 06:53:20 XXX XXX: main/cnf/Commands-amd64.xz: Hashsum mismatch. Expected: aabc61d5a794fd7cc5cb5100633abfbedc6e241657458e7d09cfda85600fc756 Found: c8922ff82fbd02a7f6b80ca5e13b0a6ba3f694e231b65973fa0621d7c2ad5ded Nov 12 06:53:20 XXX XXX: main/cnf/Commands-i386.xz: Hashsum mismatch. Expected: 4f0b2ffa3e742e99278c0abe6eda69cd2d7a18d3e8de8e1e5b363b8289abf6c0 Found: 63434a5ca02388a3c6a06b973c3341a7a31bde4027bc91123e7f2fb8a5efb4d8 (…) To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/apt/+bug/1903975/+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 1763584] Re: ureadahead service fails with error Error while tracing: No such file or directory
This is affecting me running Ubuntu 20.10. Is ureadahead still used, 2 years on, or should I remove it? -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to ureadahead in Ubuntu. https://bugs.launchpad.net/bugs/1763584 Title: ureadahead service fails with error Error while tracing: No such file or directory Status in ureadahead package in Ubuntu: Confirmed Bug description: I'm reporting this as duplicate of #1176536 to provide more info. dmig@dmig-Inspiron-5379:~$ systemctl status ureadahead.service ● ureadahead.service - Read required files in advance Loaded: loaded (/lib/systemd/system/ureadahead.service; enabled; vendor preset: enabled) Active: failed (Result: exit-code) since Fri 2018-04-13 13:09:41 +07; 10min ago Main PID: 379 (code=exited, status=5) Apr 13 13:09:41 dmig-Inspiron-5379 ureadahead[379]: ureadahead: Error while tracing: No such file or directory Apr 13 13:09:41 dmig-Inspiron-5379 ureadahead[379]: Counted 8 CPUs ProblemType: Bug DistroRelease: Ubuntu 18.04 Package: ureadahead 0.100.0-20 Uname: Linux 4.16.2-041602-generic x86_64 ApportVersion: 2.20.9-0ubuntu4 Architecture: amd64 CurrentDesktop: ubuntu:GNOME Date: Fri Apr 13 13:13:26 2018 InstallationDate: Installed on 2018-03-27 (16 days ago) InstallationMedia: Ubuntu 18.04 LTS "Bionic Beaver" - Alpha amd64 (20180327) SourcePackage: ureadahead UpgradeStatus: No upgrade log present (probably fresh install) To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/ureadahead/+bug/1763584/+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 1903048] Re: [SRU] Bluetooth won't activate on the pi 400
> I'm not convinced it's worth investing the time required to figure out the minimum. The value of the sleep is not really the issue but it feels like there should be a better way to tell when the system is ready, what are we waiting for? Is there any api call we could do to check if the thing we need is ready? -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to bluez in Ubuntu. https://bugs.launchpad.net/bugs/1903048 Title: [SRU] Bluetooth won't activate on the pi 400 Status in bluez package in Ubuntu: Triaged Status in bluez source package in Hirsute: Triaged Bug description: [Impact] Without these patches, Bluetooth is inoperable on the recently released Raspberry Pi 400. [Test Case] * Boot the Ubuntu Desktop for Pi image on a Pi 400. * Start the Settings application and switch to the Bluetooth tab * Verify that Bluetooth is not enabled and attempting to activate it fails * sudo add-apt-repository ppa:waveform/pi-bluetooth * sudo apt update * sudo apt install bluez * sudo reboot * Start the Settings application and switch to the Bluetooth tab * Verify that Bluetooth is active and that Bluetooth devices (e.g. mice, mobile phones, headphones, etc.) can connect and operate correctly [Regression Potential] Extremely low (on groovy in particular, this has the same version of bluez as hirsute). The only significant risk is to non-Pi platforms or dongles which also use the Broadcom 43xx (or Cypress 305) chips for Bluetooth which might be inadvertently affected by these patches. [Original Description] The new Pi 400 has a slightly different Wifi/BT chip to the Pi4. Whilst wifi works happily, Bluetooth fails to operate. This doesn't appear to be an issue with either the firmware (the latest versions from upstream Raspbian have been tried), or the kernel (a known-good raspi kernel has been tested under Ubuntu), but with Bluez itself. Specifically, tracing the initialization with btmon on Raspbian and Ubuntu, the stack consistently fails when attempting to "Set Default PHY" on the latter. Curiously, under Ubuntu the adapter also appears to lack a MAC address. To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/bluez/+bug/1903048/+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 1891632] Update Released
The verification of the Stable Release Update for network-manager has completed successfully and the package is now being released to -updates. Subsequently, the Ubuntu Stable Release Updates Team is being unsubscribed and will not receive messages about this bug report. In the event that you encounter a regression using the package from -updates please report a new bug using ubuntu-bug and tag the bug report regression-update so we can easily find any regressions. -- 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/1891632 Title: The network manager does not check the NM_SETTING_WIRELESS_WAKE_ON_WLAN_IGNORE bit Status in OEM Priority Project: New Status in OEM Priority Project focal series: Invalid Status in network-manager package in Ubuntu: Fix Released Status in network-manager source package in Focal: Fix Released Bug description: [Impact] In some cases, the wow is not configured and the NM_SETTING_WIRELESS_WAKE_ON_WLAN_IGNORE is set (for to disable management of wake-on-LAN in NetworkManager). The network manager only checks the NM_SETTING_WIRELESS_WAKE_ON_WLAN_NONE bit. But, the NM_SETTING_WIRELESS_WAKE_ON_WLAN_IGNORE does not be check. So, the management of wake-on-LAN still is done by NetworkManager. The killer 500s Wi-Fi does not want the network-manger to manager the wake-on-LAN so the NM_SETTING_WIRELESS_WAKE_ON_WLAN_IGNORE is set. (The driver will manager itself.) When the network-manager managers the wake-on-LAN, all of the Wi-Fi functions will be lost after the OS resumed from suspend. [Test Case] On a machine with killer 500s Wi-Fi and install the Qualcomm's driver. Step 1. Enter suspend (s2idle) Setp 2. Resume from suspend After resume from suspend, the Wi-Fi function still is normal. You can download the kernel and linux-firmware that backport the Qucalcomm's dirver fro focal from below link: https://launchpad.net/~vicamo/+archive/ubuntu/ppa-1879633 [Regression Potential] * This patch modifies the wake on lan parameters, please test that the corresponding feature still works fine with the different configuration values. 1. Magic packet test: Set Wake on Wireless to off Send magic packet to the system Ensure it does not wake up Set Wake on Wirless to on Send magic packet to the system Ensure it does wake up 2. Wi-Fi function test after resumed from suspend: After resume from suspend, the Wi-Fi should work normally. Scan APs. Connect to an AP. [Other Info] * platform: add the NM_SETTING_WIRELESS_WAKE_ON_WLAN_IGNORE status check (!597) · Merge Requests · NetworkManager / NetworkManager · GitLab - https://gitlab.freedesktop.org/NetworkManager/NetworkManager/-/merge_requests/597#note_588639 To manage notifications about this bug go to: https://bugs.launchpad.net/oem-priority/+bug/1891632/+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 1903814] Re: [binutils] Prevent GOT access rewrite for certain symbols
"The patch applies fine to 2.26 and 2.30 (except for tests, but we don't need them)." but we do. normally whenever doing toolchain fixes and updates, unittests are expected to be backported as all of them are exercised before allowing to release the update. -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to binutils in Ubuntu. https://bugs.launchpad.net/bugs/1903814 Title: [binutils] Prevent GOT access rewrite for certain symbols Status in Ubuntu on IBM z Systems: Triaged Status in binutils package in Ubuntu: Fix Released Status in binutils source package in Bionic: New Bug description: Please backport the following bugfix into Ubuntu LTS: https://sourceware.org/git/?p=binutils-gdb.git;a=commit;h=e6213e09ed0e Some relevant historic links: Debian bugreport: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=961736 glibc bugreport: https://sourceware.org/bugzilla/show_bug.cgi?id=18960 In s390 kernel context, this bug manifests itself as random errors and infinite loops, so it's fairly severe. These are the current versions of binutils: Package binutils xenial (16.04LTS) (devel): GNU assembler, linker and binary utilities 2.26.1-1ubuntu1~16.04.8 [security]: amd64 i386 2.26-8ubuntu2 [ports]: arm64 armhf powerpc ppc64el s390x xenial-updates (devel): GNU assembler, linker and binary utilities 2.26.1-1ubuntu1~16.04.8: amd64 arm64 armhf i386 powerpc ppc64el s390x bionic (18.04LTS) (devel): GNU assembler, linker and binary utilities 2.30-21ubuntu1~18.04.4 [security]: amd64 i386 2.30-15ubuntu1 [ports]: arm64 armhf ppc64el s390x bionic-updates (devel): GNU assembler, linker and binary utilities 2.30-21ubuntu1~18.04.4: amd64 arm64 armhf i386 ppc64el s390x focal (20.04LTS) (devel): GNU assembler, linker and binary utilities 2.34-6ubuntu1: amd64 arm64 armhf i386 ppc64el s390x groovy (devel): GNU assembler, linker and binary utilities 2.35.1-1ubuntu1: amd64 arm64 armhf i386 ppc64el s390x The patch applies fine to 2.26 and 2.30 (except for tests, but we don't need them). We don't need it on 2.32+. To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu-z-systems/+bug/1903814/+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 1891632] Re: The network manager does not check the NM_SETTING_WIRELESS_WAKE_ON_WLAN_IGNORE bit
This bug was fixed in the package network-manager - 1.22.10-1ubuntu2.2 --- network-manager (1.22.10-1ubuntu2.2) focal; urgency=medium * platform: add the NM_SETTING_WIRELESS_WAKE_ON_WLAN_IGNORE status check (LP: #1891632) -- Li-Hao Liao (Leon Liao) Wed, 16 Sep 2020 17:05:18 +0100 ** Changed in: network-manager (Ubuntu Focal) Status: Fix Committed => Fix Released -- 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/1891632 Title: The network manager does not check the NM_SETTING_WIRELESS_WAKE_ON_WLAN_IGNORE bit Status in OEM Priority Project: New Status in OEM Priority Project focal series: Invalid Status in network-manager package in Ubuntu: Fix Released Status in network-manager source package in Focal: Fix Released Bug description: [Impact] In some cases, the wow is not configured and the NM_SETTING_WIRELESS_WAKE_ON_WLAN_IGNORE is set (for to disable management of wake-on-LAN in NetworkManager). The network manager only checks the NM_SETTING_WIRELESS_WAKE_ON_WLAN_NONE bit. But, the NM_SETTING_WIRELESS_WAKE_ON_WLAN_IGNORE does not be check. So, the management of wake-on-LAN still is done by NetworkManager. The killer 500s Wi-Fi does not want the network-manger to manager the wake-on-LAN so the NM_SETTING_WIRELESS_WAKE_ON_WLAN_IGNORE is set. (The driver will manager itself.) When the network-manager managers the wake-on-LAN, all of the Wi-Fi functions will be lost after the OS resumed from suspend. [Test Case] On a machine with killer 500s Wi-Fi and install the Qualcomm's driver. Step 1. Enter suspend (s2idle) Setp 2. Resume from suspend After resume from suspend, the Wi-Fi function still is normal. You can download the kernel and linux-firmware that backport the Qucalcomm's dirver fro focal from below link: https://launchpad.net/~vicamo/+archive/ubuntu/ppa-1879633 [Regression Potential] * This patch modifies the wake on lan parameters, please test that the corresponding feature still works fine with the different configuration values. 1. Magic packet test: Set Wake on Wireless to off Send magic packet to the system Ensure it does not wake up Set Wake on Wirless to on Send magic packet to the system Ensure it does wake up 2. Wi-Fi function test after resumed from suspend: After resume from suspend, the Wi-Fi should work normally. Scan APs. Connect to an AP. [Other Info] * platform: add the NM_SETTING_WIRELESS_WAKE_ON_WLAN_IGNORE status check (!597) · Merge Requests · NetworkManager / NetworkManager · GitLab - https://gitlab.freedesktop.org/NetworkManager/NetworkManager/-/merge_requests/597#note_588639 To manage notifications about this bug go to: https://bugs.launchpad.net/oem-priority/+bug/1891632/+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 1903048] Re: [SRU] Bluetooth won't activate on the pi 400
Sorry but I'm reverting that upload for now until the patches are properly upstreamed. We have been bitten too often by unforwarded changes that create issues or create maintainance burden over the years and we currently don't have the team capacity to deal with extra cost. If foundations would like to step up and take over bluez though that's a discussion we could have... ** Changed in: bluez (Ubuntu Hirsute) Status: Fix Released => Triaged -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to bluez in Ubuntu. https://bugs.launchpad.net/bugs/1903048 Title: [SRU] Bluetooth won't activate on the pi 400 Status in bluez package in Ubuntu: Triaged Status in bluez source package in Hirsute: Triaged Bug description: [Impact] Without these patches, Bluetooth is inoperable on the recently released Raspberry Pi 400. [Test Case] * Boot the Ubuntu Desktop for Pi image on a Pi 400. * Start the Settings application and switch to the Bluetooth tab * Verify that Bluetooth is not enabled and attempting to activate it fails * sudo add-apt-repository ppa:waveform/pi-bluetooth * sudo apt update * sudo apt install bluez * sudo reboot * Start the Settings application and switch to the Bluetooth tab * Verify that Bluetooth is active and that Bluetooth devices (e.g. mice, mobile phones, headphones, etc.) can connect and operate correctly [Regression Potential] Extremely low (on groovy in particular, this has the same version of bluez as hirsute). The only significant risk is to non-Pi platforms or dongles which also use the Broadcom 43xx (or Cypress 305) chips for Bluetooth which might be inadvertently affected by these patches. [Original Description] The new Pi 400 has a slightly different Wifi/BT chip to the Pi4. Whilst wifi works happily, Bluetooth fails to operate. This doesn't appear to be an issue with either the firmware (the latest versions from upstream Raspbian have been tried), or the kernel (a known-good raspi kernel has been tested under Ubuntu), but with Bluez itself. Specifically, tracing the initialization with btmon on Raspbian and Ubuntu, the stack consistently fails when attempting to "Set Default PHY" on the latter. Curiously, under Ubuntu the adapter also appears to lack a MAC address. To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/bluez/+bug/1903048/+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 1903966] Re: Loading keymaps via udev is not reliable, please use upstream rule
Status changed to 'Confirmed' because the bug affects multiple users. ** Changed in: v4l-utils (Ubuntu) Status: New => Confirmed -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to v4l-utils in Ubuntu. https://bugs.launchpad.net/bugs/1903966 Title: Loading keymaps via udev is not reliable, please use upstream rule Status in v4l-utils package in Ubuntu: Confirmed Bug description: Dear Maintainer, the udev rule installed from debian/ir-keytable.udev is not guaranteed to be run at the appropriate moment during bootup which can cause the remote not to be configured according to the settings in /etc/rc_maps.cfg. This seems to occur more often with newer kernel versions. Please use the upstream version (https://git.linuxtv.org/v4l-utils.git/tree/utils/keytable/70-infrared.rules) instead. This commit message explains the need for this change: https://git.linuxtv.org/v4l-utils.git/commit/utils/keytable/70-infrared.rules?id=e440918467868a5f3e7f73f54ef2cbd85d68f3f1 Description:Ubuntu 20.04.1 LTS Release:20.04 ir-keytable version: 1.18.0-2build1 and later To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/v4l-utils/+bug/1903966/+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 1903975] [NEW] Hashsum mismatch Commands-amd64.xz rsync://archive.ubuntu.com
Public bug reported: Package syncronisation on rsync://archive.ubuntu.com fails with error: $ time rsync rsync://archive.ubuntu.com This is an Ubuntu mirror - treat it kindly maas-images Ubuntu Old Releases releasesUbuntu Releases CD Images simple-streams Juju Simple Streams Mirror cloud-imagesUbuntu Cloud Images cdimage Ubuntu CD Images ubuntu Ubuntu Archive ubuntu-cloud-archiveUbuntu Cloud Archive old-releasesUbuntu Old Releases ubuntu-portsUbuntu Ports Archive real2m57.968s user0m0.000s sys 0m0.003s Nov 12 06:53:20 XXX XXX: Checking file:///srv/mirror/ubuntu/dists/focal-updates... Nov 12 06:53:20 XXX XXX: main/cnf/Commands-amd64.xz: Hashsum mismatch. Expected: 6404594deb82bdbe27b34d9b6e245c44bfc0a7319a456f94046814a7bcbfe1ad Found: 8ac1ce39639806e308b85efa4a323afaf6448c082a5728d1d7e99c3e1e431369 Nov 12 06:53:20 XXX XXX: main/cnf/Commands-i386.xz: Hashsum mismatch. Expected: 3d1e38232e7550131e09c210d1e4e94c92070812f3cf4aaebf7dc841ad7d6ead Found: c250b8713c4c357cdd097922ae8332eec26aef9159f48df9e3ab1194d3c44307 Nov 12 06:53:20 XXX XXX: Checking file:///srv/mirror/ubuntu/dists/focal-security... Nov 12 06:53:20 XXX XXX: main/cnf/Commands-amd64.xz: Hashsum mismatch. Expected: aabc61d5a794fd7cc5cb5100633abfbedc6e241657458e7d09cfda85600fc756 Found: c8922ff82fbd02a7f6b80ca5e13b0a6ba3f694e231b65973fa0621d7c2ad5ded Nov 12 06:53:20 XXX XXX: main/cnf/Commands-i386.xz: Hashsum mismatch. Expected: 4f0b2ffa3e742e99278c0abe6eda69cd2d7a18d3e8de8e1e5b363b8289abf6c0 Found: 63434a5ca02388a3c6a06b973c3341a7a31bde4027bc91123e7f2fb8a5efb4d8 (…) ** Affects: apt (Ubuntu) Importance: Undecided Status: New -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to apt in Ubuntu. https://bugs.launchpad.net/bugs/1903975 Title: Hashsum mismatch Commands-amd64.xz rsync://archive.ubuntu.com Status in apt package in Ubuntu: New Bug description: Package syncronisation on rsync://archive.ubuntu.com fails with error: $ time rsync rsync://archive.ubuntu.com This is an Ubuntu mirror - treat it kindly maas-images Ubuntu Old Releases releasesUbuntu Releases CD Images simple-streams Juju Simple Streams Mirror cloud-imagesUbuntu Cloud Images cdimage Ubuntu CD Images ubuntu Ubuntu Archive ubuntu-cloud-archiveUbuntu Cloud Archive old-releasesUbuntu Old Releases ubuntu-portsUbuntu Ports Archive real2m57.968s user0m0.000s sys 0m0.003s Nov 12 06:53:20 XXX XXX: Checking file:///srv/mirror/ubuntu/dists/focal-updates... Nov 12 06:53:20 XXX XXX: main/cnf/Commands-amd64.xz: Hashsum mismatch. Expected: 6404594deb82bdbe27b34d9b6e245c44bfc0a7319a456f94046814a7bcbfe1ad Found: 8ac1ce39639806e308b85efa4a323afaf6448c082a5728d1d7e99c3e1e431369 Nov 12 06:53:20 XXX XXX: main/cnf/Commands-i386.xz: Hashsum mismatch. Expected: 3d1e38232e7550131e09c210d1e4e94c92070812f3cf4aaebf7dc841ad7d6ead Found: c250b8713c4c357cdd097922ae8332eec26aef9159f48df9e3ab1194d3c44307 Nov 12 06:53:20 XXX XXX: Checking file:///srv/mirror/ubuntu/dists/focal-security... Nov 12 06:53:20 XXX XXX: main/cnf/Commands-amd64.xz: Hashsum mismatch. Expected: aabc61d5a794fd7cc5cb5100633abfbedc6e241657458e7d09cfda85600fc756 Found: c8922ff82fbd02a7f6b80ca5e13b0a6ba3f694e231b65973fa0621d7c2ad5ded Nov 12 06:53:20 XXX XXX: main/cnf/Commands-i386.xz: Hashsum mismatch. Expected: 4f0b2ffa3e742e99278c0abe6eda69cd2d7a18d3e8de8e1e5b363b8289abf6c0 Found: 63434a5ca02388a3c6a06b973c3341a7a31bde4027bc91123e7f2fb8a5efb4d8 (…) To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/apt/+bug/1903975/+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 1341890] Re: [X550LA, Realtek ALC3236, Mic, Internal] No sound at all
The problem still persists but I found a curious thing: in my X550LA if I start the computer directly in Ubuntu, the microphone doesn't work, no matter what I do. If I start the notebook with Windows 7, access the built-in microphone with any tool or website and then restart in Ubuntu, the problem is gone: the microphone works perfecty. I don't know why but it works like this... -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to alsa-driver in Ubuntu. https://bugs.launchpad.net/bugs/1341890 Title: [X550LA, Realtek ALC3236, Mic, Internal] No sound at all Status in alsa-driver package in Ubuntu: Confirmed Bug description: I've been trying to fix this myself for a while now, and just a day or two ago, the speakers stopped working, too. Neither the internal nor external speakers I've been using with my laptop have been working, with two exceptions: the bongos noise when the login screen comes up, and the tones made during a system test. I have tried the commands "alsamixer" and "gstreamer-properties" in terminal and have had success with neither of them, and have also tried using the pulse audio volume controls to no avail. My assumption is that there is an issue with the drivers, as even the microphone produced a few sporadic noises ONLY when I was playing with the mic volume controls, but at no other point in no other program has it been so responsive. ProblemType: Bug DistroRelease: Ubuntu 14.04 Package: alsa-base 1.0.25+dfsg-0ubuntu4 ProcVersionSignature: Ubuntu 3.13.0-30.55-generic 3.13.11.2 Uname: Linux 3.13.0-30-generic x86_64 ApportVersion: 2.14.1-0ubuntu3.2 Architecture: amd64 AudioDevicesInUse: USERPID ACCESS COMMAND /dev/snd/controlC1: jake 1815 F pulseaudio /dev/snd/controlC0: jake 1815 F pulseaudio /dev/snd/pcmC0D3p: jake 1815 F...m pulseaudio CurrentDesktop: Unity Date: Mon Jul 14 20:25:02 2014 InstallationDate: Installed on 2014-05-23 (52 days ago) InstallationMedia: Ubuntu 14.04 LTS "Trusty Tahr" - Release amd64 (20140417) PackageArchitecture: all SourcePackage: alsa-driver Symptom: audio Symptom_AlsaRecordingTest: ALSA recording test through plughw:PCH failed Symptom_Card: Built-in Audio - HDA Intel PCH Symptom_DevicesInUse: USERPID ACCESS COMMAND /dev/snd/controlC1: jake 1815 F pulseaudio /dev/snd/controlC0: jake 1815 F pulseaudio /dev/snd/pcmC0D3p: jake 1815 F...m pulseaudio Symptom_Jack: Mic, Internal Symptom_Type: No sound at all Title: [X550LA, Realtek ALC3236, Mic, Internal] No sound at all UpgradeStatus: No upgrade log present (probably fresh install) dmi.bios.date: 11/26/2013 dmi.bios.vendor: American Megatrends Inc. dmi.bios.version: X550LA.403 dmi.board.asset.tag: ATN12345678901234567 dmi.board.name: X550LA dmi.board.vendor: ASUSTeK COMPUTER INC. dmi.board.version: 1.0 dmi.chassis.asset.tag: ATN12345678901234567 dmi.chassis.type: 10 dmi.chassis.vendor: ASUSTeK COMPUTER INC. dmi.chassis.version: 1.0 dmi.modalias: dmi:bvnAmericanMegatrendsInc.:bvrX550LA.403:bd11/26/2013:svnASUSTeKCOMPUTERINC.:pnX550LA:pvr1.0:rvnASUSTeKCOMPUTERINC.:rnX550LA:rvr1.0:cvnASUSTeKCOMPUTERINC.:ct10:cvr1.0: dmi.product.name: X550LA dmi.product.version: 1.0 dmi.sys.vendor: ASUSTeK COMPUTER INC. To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/alsa-driver/+bug/1341890/+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 1903966] [NEW] Loading keymaps via udev is not reliable, please use upstream rule
Public bug reported: Dear Maintainer, the udev rule installed from debian/ir-keytable.udev is not guaranteed to be run at the appropriate moment during bootup which can cause the remote not to be configured according to the settings in /etc/rc_maps.cfg. This seems to occur more often with newer kernel versions. Please use the upstream version (https://git.linuxtv.org/v4l-utils.git/tree/utils/keytable/70-infrared.rules) instead. This commit message explains the need for this change: https://git.linuxtv.org/v4l-utils.git/commit/utils/keytable/70-infrared.rules?id=e440918467868a5f3e7f73f54ef2cbd85d68f3f1 Description:Ubuntu 20.04.1 LTS Release:20.04 ir-keytable version: 1.18.0-2build1 and later ** Affects: v4l-utils (Ubuntu) Importance: Undecided Status: New -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to v4l-utils in Ubuntu. https://bugs.launchpad.net/bugs/1903966 Title: Loading keymaps via udev is not reliable, please use upstream rule Status in v4l-utils package in Ubuntu: New Bug description: Dear Maintainer, the udev rule installed from debian/ir-keytable.udev is not guaranteed to be run at the appropriate moment during bootup which can cause the remote not to be configured according to the settings in /etc/rc_maps.cfg. This seems to occur more often with newer kernel versions. Please use the upstream version (https://git.linuxtv.org/v4l-utils.git/tree/utils/keytable/70-infrared.rules) instead. This commit message explains the need for this change: https://git.linuxtv.org/v4l-utils.git/commit/utils/keytable/70-infrared.rules?id=e440918467868a5f3e7f73f54ef2cbd85d68f3f1 Description:Ubuntu 20.04.1 LTS Release:20.04 ir-keytable version: 1.18.0-2build1 and later To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/v4l-utils/+bug/1903966/+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 1838151] Re: Poor quality audio with modern Bluetooth headsets in HSP/HFP. Missing wide band speech support (Bluetooth A2DP codecs).
I'm also interested by such Bluetooth adapter, which one do you recommend between the Avantree Leaf and 1Mii b10? -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to bluez in Ubuntu. https://bugs.launchpad.net/bugs/1838151 Title: Poor quality audio with modern Bluetooth headsets in HSP/HFP. Missing wide band speech support (Bluetooth A2DP codecs). Status in PulseAudio: New Status in bluez package in Ubuntu: Fix Released Status in linux package in Ubuntu: Fix Released Status in pulseaudio package in Ubuntu: In Progress Status in Arch Linux: New Bug description: Bluetooth HSP/HFP audio quality is poor on Ubuntu comparative to all other major platforms (Windows, MacOS, ChromeOS, Android, iOS). Modern Bluetooth headsets (such as the Bose QC series headphones, many others) are capable of using HFP 1.6 with mSBC 16kHz audio encoding. As it currently stands, Ubuntu defaults to only supporting HSP headsets using 8kHz CVSD, and is incapable of supporting HFP 1.6 at this time. The ChromiumOS team recently tackled this issue - https://bugs.chromium.org/p/chromium/issues/detail?id=843048 Their efforts may assist in bringing this to Ubuntu, however it appears that there are quite a lot of differences considering they have developed their own audio server solution etc. The Bluetooth Telephony Working Group published the HFP 1.6 spec in May 2011 - https://www.bluetooth.org/docman/handlers/downloaddoc.ashx?doc_id=238193 Patches have been proposed in the past for this issue to the kernel and PulseAudio: PulseAudio: https://patchwork.freedesktop.org/patch/245272/ Kernel: https://www.spinics.net/lists/linux-bluetooth/msg76982.html It appears that the Chromium OS team applied the same kernel patch: https://chromium.googlesource.com/chromiumos/third_party/kernel/+/77dd0cb94c1713a8a12f6e392955dfa64c430e54 ProblemType: Bug DistroRelease: Ubuntu 19.04 Package: pulseaudio 1:12.2-2ubuntu3 ProcVersionSignature: Ubuntu 5.0.0-20.21-generic 5.0.8 Uname: Linux 5.0.0-20-generic x86_64 ApportVersion: 2.20.10-0ubuntu27.1 Architecture: amd64 AudioDevicesInUse: USERPID ACCESS COMMAND /dev/snd/controlC0: jnappi 2777 F pulseaudio CurrentDesktop: ubuntu:GNOME Date: Sat Jul 27 11:08:29 2019 EcryptfsInUse: Yes InstallationDate: Installed on 2017-11-04 (629 days ago) InstallationMedia: Ubuntu 17.10 "Artful Aardvark" - Release amd64 (20171018) ProcEnviron: PATH=(custom, no user) XDG_RUNTIME_DIR= LANG=en_US.UTF-8 SHELL=/bin/bash SourcePackage: pulseaudio UpgradeStatus: Upgraded to disco on 2019-07-18 (9 days ago) dmi.bios.date: 06/07/2016 dmi.bios.vendor: LENOVO dmi.bios.version: R07ET67W (2.07 ) dmi.board.asset.tag: Not Available dmi.board.name: 20FW000TUS dmi.board.vendor: LENOVO dmi.board.version: SDK0J40705 WIN dmi.chassis.asset.tag: No Asset Information dmi.chassis.type: 10 dmi.chassis.vendor: LENOVO dmi.chassis.version: None dmi.modalias: dmi:bvnLENOVO:bvrR07ET67W(2.07):bd06/07/2016:svnLENOVO:pn20FW000TUS:pvrThinkPadT460p:rvnLENOVO:rn20FW000TUS:rvrSDK0J40705WIN:cvnLENOVO:ct10:cvrNone: dmi.product.family: ThinkPad T460p dmi.product.name: 20FW000TUS dmi.product.sku: LENOVO_MT_20FW_BU_Think_FM_ThinkPad T460p dmi.product.version: ThinkPad T460p dmi.sys.vendor: LENOVO To manage notifications about this bug go to: https://bugs.launchpad.net/pulseaudio/+bug/1838151/+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
