[Touch-packages] [Bug 1898547] Re: neutron-linuxbridge-agent fails to start with iptables 1.8.5

2020-11-12 Thread Alex Murray
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")

2020-11-12 Thread Ubuntu Foundations Team Bug Bot
** 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")

2020-11-12 Thread Launchpad Bug Tracker
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

2020-11-12 Thread Daniel van Vugt
** 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

2020-11-12 Thread Brian Foster
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

2020-11-12 Thread Marcus Aurelius
@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

2020-11-12 Thread Alex Murray
** 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

2020-11-12 Thread Sebastien Bacher
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)

2020-11-12 Thread Alex Murray
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 

Re: [Touch-packages] [Bug 1903048] Re: [SRU] Bluetooth won't activate on the pi 400

2020-11-12 Thread Dave Jones
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], 

[Touch-packages] [Bug 1719355] Re: Switcher widget background goes outside its border

2020-11-12 Thread dejw
** 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

2020-11-12 Thread Brian Murray
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

2020-11-12 Thread Matthieu Clemenceau
@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

2020-11-12 Thread Chris Wayne
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

2020-11-12 Thread deniz örnek
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”

2020-11-12 Thread Balint Reczey
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"

2020-11-12 Thread dev
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

2020-11-12 Thread Brian Murray
** 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

2020-11-12 Thread Brian Murray
>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

2020-11-12 Thread Brian Murray
** 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

2020-11-12 Thread Bug Watch Updater
** 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

2020-11-12 Thread Matthieu Clemenceau
** 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

2020-11-12 Thread Matthieu Clemenceau
** 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

2020-11-12 Thread Matthieu Clemenceau
** 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

2020-11-12 Thread Matthieu Clemenceau
** 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

2020-11-12 Thread David Krauser
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

2020-11-12 Thread Dimitri John Ledkov
** 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

2020-11-12 Thread Marc Deslauriers
** 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=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

2020-11-12 Thread Dimitri John Ledkov
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

2020-11-12 Thread Hans de Goede
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

2020-11-12 Thread Łukasz Zemczak
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

2020-11-12 Thread Łukasz Zemczak
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

2020-11-12 Thread Launchpad Bug Tracker
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

2020-11-12 Thread Launchpad Bug Tracker
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

2020-11-12 Thread Mushfiqur Rahman Abir
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

2020-11-12 Thread Sabrina
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

2020-11-12 Thread Sebastien Bacher
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

2020-11-12 Thread Bert Hekman
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

2020-11-12 Thread Sebastien Bacher
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

2020-11-12 Thread Sebastien Bacher
> 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

2020-11-12 Thread Sebastien Bacher
> 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

2020-11-12 Thread Pablo Catalina
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

2020-11-12 Thread Łukasz Zemczak
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

2020-11-12 Thread Launchpad Bug Tracker
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

2020-11-12 Thread Paride Legovini
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

2020-11-12 Thread Paride Legovini
** 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

2020-11-12 Thread Henry Sprog
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

2020-11-12 Thread Julian Andres Klode
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

2020-11-12 Thread Owen
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

2020-11-12 Thread Sebastien Bacher
> 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

2020-11-12 Thread Łukasz Zemczak
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

2020-11-12 Thread Dimitri John Ledkov
"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

2020-11-12 Thread Launchpad Bug Tracker
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

2020-11-12 Thread Sebastien Bacher
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

2020-11-12 Thread Launchpad Bug Tracker
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

2020-11-12 Thread Sabrina
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

2020-11-12 Thread Tanguero
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

2020-11-12 Thread seahawk1986
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).

2020-11-12 Thread Aurélien PRAGA
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