[Touch-packages] [Bug 1926050] Re: [radeon] Web benchmark freezing and crashing the system (Xorg crashes in Mesa's r600_dri.so)

[Launchpad Bug Tracker]

[Expired for mesa (Ubuntu) because there has been no activity for 60
days.]

** Changed in: mesa (Ubuntu)
   Status: Incomplete => Expired

-- 
You received this bug notification because you are a member of Ubuntu
Touch seeded packages, which is subscribed to mesa in Ubuntu.
https://bugs.launchpad.net/bugs/1926050

Title:
  [radeon] Web benchmark freezing and crashing the system (Xorg crashes
  in Mesa's r600_dri.so)

Status in mesa package in Ubuntu:
  Expired
Status in xserver-xorg-video-ati package in Ubuntu:
  Expired

Bug description:
  Expected behavior: perform the "Basemark Web 3.0" benchmark (Firefox
  87 and 88), at most a loss of performance.

  Real behavior: the benchmark completely crashes the system in one of
  the initial stages (4). The screen presents graphical distortion (it
  never happens), intense crashes and sometimes it is solved with the
  automatic suspension of the computer (which remains on at times). But
  it doesn't usually come back from the crash.

  The problem happens with the onboard ATI RADEON 3000 (RS780 driver)
  and it happens in both xorg and wayland. Ubuntu and kernel duly
  updated to the present date.

  Crash moment: WebGL 1.0.2 Test (test 4/20); "Loading
  scene_uv2.DAE"

  Benchmark website: https://web.basemark.com/
  Motherboard: GA78LMT
  Ubuntu 20.04.2 LTS
  Kernel 5.8.0-50-generic
  ---
  ProblemType: Bug
  ApportVersion: 2.20.11-0ubuntu27.16
  Architecture: amd64
  AudioDevicesInUse:
   USERPID ACCESS COMMAND
   /dev/snd/controlC2:  poe1860 F pulseaudio
   /dev/snd/pcmC2D0p:   poe1860 F...m pulseaudio
   /dev/snd/controlC0:  poe1860 F pulseaudio
   /dev/snd/controlC1:  poe1860 F pulseaudio
  BootLog: Error: [Errno 13] Permissão recusada: '/var/log/boot.log'
  CasperMD5CheckResult: skip
  CompositorRunning: None
  CurrentDesktop: ubuntu:GNOME
  DistUpgraded: 2021-03-25 15:17:02,784 DEBUG /openCache(), new cache size 67025
  DistroCodename: focal
  DistroRelease: Ubuntu 20.04
  DistroVariant: ubuntu
  ExtraDebuggingInterest: Yes, including running git bisection searches
  GraphicsCard:
   Advanced Micro Devices, Inc. [AMD/ATI] RS780L [Radeon 3000] [1002:9616] 
(prog-if 00 [VGA controller])
     Subsystem: Gigabyte Technology Co., Ltd RS780L [Radeon 3000] [1458:d000]
  InstallationDate: Installed on 2021-03-04 (51 days ago)
  InstallationMedia: Ubuntu 20.04.2.0 LTS "Focal Fossa" - Release amd64 
(20210209.1)
  MachineType: Gigabyte Technology Co., Ltd. GA-78LMT-USB3 6.0
  Package: xorg-server (not installed)
  ProcFB: 0 radeondrmfb
  ProcKernelCmdLine: BOOT_IMAGE=/vmlinuz-5.8.0-50-generic 
root=/dev/mapper/vgubuntu-root ro quiet splash radeon.audio=1 vt.handoff=7
  ProcVersionSignature: Ubuntu 5.8.0-50.56~20.04.1-generic 5.8.18
  RelatedPackageVersions:
   linux-restricted-modules-5.8.0-50-generic N/A
   linux-backports-modules-5.8.0-50-generic  N/A
   linux-firmware1.187.11
  Tags:  focal wayland-session wayland-session ubuntu
  Uname: Linux 5.8.0-50-generic x86_64
  UpgradeStatus: Upgraded to focal on 2021-03-25 (30 days ago)
  UserGroups: adm cdrom dip lpadmin lxd plugdev sambashare
  _MarkForUpload: True
  dmi.bios.date: 11/25/2014
  dmi.bios.vendor: Award Software International, Inc.
  dmi.bios.version: F2
  dmi.board.name: GA-78LMT-USB3 6.0
  dmi.board.vendor: Gigabyte Technology Co., Ltd.
  dmi.board.version: SEx
  dmi.chassis.type: 3
  dmi.chassis.vendor: Gigabyte Technology Co., Ltd.
  dmi.modalias: 
dmi:bvnAwardSoftwareInternational,Inc.:bvrF2:bd11/25/2014:svnGigabyteTechnologyCo.,Ltd.:pnGA-78LMT-USB36.0:pvr:rvnGigabyteTechnologyCo.,Ltd.:rnGA-78LMT-USB36.0:rvrSEx:cvnGigabyteTechnologyCo.,Ltd.:ct3:cvr:
  dmi.product.name: GA-78LMT-USB3 6.0
  dmi.sys.vendor: Gigabyte Technology Co., Ltd.
  version.compiz: compiz N/A
  version.libdrm2: libdrm2 2.4.102-1ubuntu1~20.04.1
  version.libgl1-mesa-dri: libgl1-mesa-dri 20.2.6-0ubuntu0.20.04.1
  version.libgl1-mesa-glx: libgl1-mesa-glx N/A
  version.xserver-xorg-core: xserver-xorg-core 2:1.20.9-2ubuntu1.2~20.04.2
  version.xserver-xorg-input-evdev: xserver-xorg-input-evdev N/A
  version.xserver-xorg-video-ati: xserver-xorg-video-ati 1:19.1.0-1
  version.xserver-xorg-video-intel: xserver-xorg-video-intel 
2:2.99.917+git20200226-1
  version.xserver-xorg-video-nouveau: xserver-xorg-video-nouveau 1:1.0.16-1

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/mesa/+bug/1926050/+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 1926050] Re: [radeon] Web benchmark freezing and crashing the system (Xorg crashes in Mesa's r600_dri.so)

[Launchpad Bug Tracker]

[Expired for xserver-xorg-video-ati (Ubuntu) because there has been no
activity for 60 days.]

** Changed in: xserver-xorg-video-ati (Ubuntu)
   Status: Incomplete => Expired

-- 
You received this bug notification because you are a member of Ubuntu
Touch seeded packages, which is subscribed to mesa in Ubuntu.
https://bugs.launchpad.net/bugs/1926050

Title:
  [radeon] Web benchmark freezing and crashing the system (Xorg crashes
  in Mesa's r600_dri.so)

Status in mesa package in Ubuntu:
  Expired
Status in xserver-xorg-video-ati package in Ubuntu:
  Expired

Bug description:
  Expected behavior: perform the "Basemark Web 3.0" benchmark (Firefox
  87 and 88), at most a loss of performance.

  Real behavior: the benchmark completely crashes the system in one of
  the initial stages (4). The screen presents graphical distortion (it
  never happens), intense crashes and sometimes it is solved with the
  automatic suspension of the computer (which remains on at times). But
  it doesn't usually come back from the crash.

  The problem happens with the onboard ATI RADEON 3000 (RS780 driver)
  and it happens in both xorg and wayland. Ubuntu and kernel duly
  updated to the present date.

  Crash moment: WebGL 1.0.2 Test (test 4/20); "Loading
  scene_uv2.DAE"

  Benchmark website: https://web.basemark.com/
  Motherboard: GA78LMT
  Ubuntu 20.04.2 LTS
  Kernel 5.8.0-50-generic
  ---
  ProblemType: Bug
  ApportVersion: 2.20.11-0ubuntu27.16
  Architecture: amd64
  AudioDevicesInUse:
   USERPID ACCESS COMMAND
   /dev/snd/controlC2:  poe1860 F pulseaudio
   /dev/snd/pcmC2D0p:   poe1860 F...m pulseaudio
   /dev/snd/controlC0:  poe1860 F pulseaudio
   /dev/snd/controlC1:  poe1860 F pulseaudio
  BootLog: Error: [Errno 13] Permissão recusada: '/var/log/boot.log'
  CasperMD5CheckResult: skip
  CompositorRunning: None
  CurrentDesktop: ubuntu:GNOME
  DistUpgraded: 2021-03-25 15:17:02,784 DEBUG /openCache(), new cache size 67025
  DistroCodename: focal
  DistroRelease: Ubuntu 20.04
  DistroVariant: ubuntu
  ExtraDebuggingInterest: Yes, including running git bisection searches
  GraphicsCard:
   Advanced Micro Devices, Inc. [AMD/ATI] RS780L [Radeon 3000] [1002:9616] 
(prog-if 00 [VGA controller])
     Subsystem: Gigabyte Technology Co., Ltd RS780L [Radeon 3000] [1458:d000]
  InstallationDate: Installed on 2021-03-04 (51 days ago)
  InstallationMedia: Ubuntu 20.04.2.0 LTS "Focal Fossa" - Release amd64 
(20210209.1)
  MachineType: Gigabyte Technology Co., Ltd. GA-78LMT-USB3 6.0
  Package: xorg-server (not installed)
  ProcFB: 0 radeondrmfb
  ProcKernelCmdLine: BOOT_IMAGE=/vmlinuz-5.8.0-50-generic 
root=/dev/mapper/vgubuntu-root ro quiet splash radeon.audio=1 vt.handoff=7
  ProcVersionSignature: Ubuntu 5.8.0-50.56~20.04.1-generic 5.8.18
  RelatedPackageVersions:
   linux-restricted-modules-5.8.0-50-generic N/A
   linux-backports-modules-5.8.0-50-generic  N/A
   linux-firmware1.187.11
  Tags:  focal wayland-session wayland-session ubuntu
  Uname: Linux 5.8.0-50-generic x86_64
  UpgradeStatus: Upgraded to focal on 2021-03-25 (30 days ago)
  UserGroups: adm cdrom dip lpadmin lxd plugdev sambashare
  _MarkForUpload: True
  dmi.bios.date: 11/25/2014
  dmi.bios.vendor: Award Software International, Inc.
  dmi.bios.version: F2
  dmi.board.name: GA-78LMT-USB3 6.0
  dmi.board.vendor: Gigabyte Technology Co., Ltd.
  dmi.board.version: SEx
  dmi.chassis.type: 3
  dmi.chassis.vendor: Gigabyte Technology Co., Ltd.
  dmi.modalias: 
dmi:bvnAwardSoftwareInternational,Inc.:bvrF2:bd11/25/2014:svnGigabyteTechnologyCo.,Ltd.:pnGA-78LMT-USB36.0:pvr:rvnGigabyteTechnologyCo.,Ltd.:rnGA-78LMT-USB36.0:rvrSEx:cvnGigabyteTechnologyCo.,Ltd.:ct3:cvr:
  dmi.product.name: GA-78LMT-USB3 6.0
  dmi.sys.vendor: Gigabyte Technology Co., Ltd.
  version.compiz: compiz N/A
  version.libdrm2: libdrm2 2.4.102-1ubuntu1~20.04.1
  version.libgl1-mesa-dri: libgl1-mesa-dri 20.2.6-0ubuntu0.20.04.1
  version.libgl1-mesa-glx: libgl1-mesa-glx N/A
  version.xserver-xorg-core: xserver-xorg-core 2:1.20.9-2ubuntu1.2~20.04.2
  version.xserver-xorg-input-evdev: xserver-xorg-input-evdev N/A
  version.xserver-xorg-video-ati: xserver-xorg-video-ati 1:19.1.0-1
  version.xserver-xorg-video-intel: xserver-xorg-video-intel 
2:2.99.917+git20200226-1
  version.xserver-xorg-video-nouveau: xserver-xorg-video-nouveau 1:1.0.16-1

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/mesa/+bug/1926050/+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 1928393] Re: linux-firmware 1.197 causes kernel to report error "amdgpu: [gfxhub0] retry page fault"

[Heinrich Schuchardt]

Also affected:

Ubuntu version: 21.04
Linux kernel: 5.11.0-22-generic  x86_64
CPU model: AMD Ryzen 5 2500U with Radeon Vega Mobile Gfx
GPU: 05:00.0 VGA compatible controller: Advanced Micro Devices, Inc. [AMD/ATI] 
Raven Ridge [Radeon Vega Series / Radeon Vega Mobile Series] (rev c4)
Laptop model: Lenovo Thinkpad E585

-- 
You received this bug notification because you are a member of Ubuntu
Touch seeded packages, which is subscribed to mesa in Ubuntu.
https://bugs.launchpad.net/bugs/1928393

Title:
  linux-firmware 1.197 causes kernel to report error "amdgpu: [gfxhub0]
  retry page fault"

Status in amd:
  New
Status in linux-firmware package in Ubuntu:
  Incomplete
Status in mesa package in Ubuntu:
  Confirmed

Bug description:
  After upgrading linux-firmware from 1.190.5 to 1.197 (as part of the
  upgrade from Ubuntu 20.10 to 21.04), I started experiencing frequent
  and severe GPU instability. When this happens, I see this error in
  dmesg:

  [20061.061069] amdgpu :03:00.0: amdgpu: [gfxhub0] retry page fault 
(src_id:0 ring:0 vmid:1 pasid:32769, for process Xorg pid 1141 thread Xorg:cs0 
pid 1236)
  [20061.061103] amdgpu :03:00.0: amdgpu:   in page starting at address 
0x80401000 from client 27
  [20061.061135] amdgpu :03:00.0: amdgpu: 
VM_L2_PROTECTION_FAULT_STATUS:0x00101031
  [20061.061147] amdgpu :03:00.0: amdgpu:  Faulty UTCL2 client ID: TCP 
(0x8)
  [20061.061157] amdgpu :03:00.0: amdgpu:  MORE_FAULTS: 0x1
  [20061.061167] amdgpu :03:00.0: amdgpu:  WALKER_ERROR: 0x0
  [20061.061174] amdgpu :03:00.0: amdgpu:  PERMISSION_FAULTS: 0x3
  [20061.061183] amdgpu :03:00.0: amdgpu:  MAPPING_ERROR: 0x0
  [20061.061189] amdgpu :03:00.0: amdgpu:  RW: 0x0

  I'll attach a couple of full dmesgs that I collected.

  Many of the times when this happens, the screen and keyboard freeze
  irreversibly (I tried waiting for more than 30 minutes, but it doesn't
  help). I can still log in via ssh though. When there's no freeze, I
  can continue using the computer normally, but the laptop fans keep
  running are always running and the battery depletes fast. There's
  probably something on a permanent loop either in the kernel or in the
  GPU.

  This bug happens several times a day, rendering the machine so
  unstable as to be almost unusable. It is a severe regression and I'm
  aghast that it passed AMD's Quality Assurance.

  After downgrading back to linux-firmware 1.190.5, the machine is back
  to the previous, mostly-reliable state. Which is to say, this bug is
  gone, I'm just left with the other amdgpu suspend bug I've learned to
  live with since I bought this computer.

  Please revert the amdgpu firmware in this package as soon as possible.
  This is unbearable.

  Relevant information:
  Ubuntu version: 21.04
  Linux kernel: 5.11.0-17-generic x86_64
  CPU model: AMD Ryzen 7 3700U with Radeon Vega Mobile Gfx
  GPU: 03:00.0 VGA compatible controller: Advanced Micro Devices, Inc. 
[AMD/ATI] Picasso (rev c1)
  Laptop model: Lenovo Ideapad S145

To manage notifications about this bug go to:
https://bugs.launchpad.net/amd/+bug/1928393/+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 1935570] Re: [HP Compaq Pro 6300 MT, Realtek ALC221, Black Mic, Front] Recording problem

[Rabi Sah]

Did you mean to run this command?

On Fri, Jul 9, 2021, 9:25 PM Hui Wang <1935...@bugs.launchpad.net>
wrote:

> Please try a boot parameter: snd_hda_intel.model=alc221-hp-mic
>
> After booting with this parameter, when you plug a mic to the audio
> jack, a popup dialogue will sho to let you select what audio device you
> plugged.
>
> Let us see if there is that pop-up dialogue first.
>
> --
> You received this bug notification because you are subscribed to the bug
> report.
> https://bugs.launchpad.net/bugs/1935570
>
> Title:
>   [HP Compaq Pro 6300 MT, Realtek ALC221, Black Mic, Front] Recording
>   problem
>
> Status in alsa-driver package in Ubuntu:
>   New
>
> Bug description:
>   Hi,
>
>   the mic does not work in my Ubuntu OS. Can you guys do something i am
>   very frustrated?
>
>   ProblemType: Bug
>   DistroRelease: Ubuntu 20.04
>   Package: alsa-base 1.0.25+dfsg-0ubuntu5
>   ProcVersionSignature: Ubuntu 5.8.0-59.66~20.04.1-generic 5.8.18
>   Uname: Linux 5.8.0-59-generic x86_64
>   ApportVersion: 2.20.11-0ubuntu27.18
>   Architecture: amd64
>   AudioDevicesInUse:
>USERPID ACCESS COMMAND
>/dev/snd/controlC0:  ravisah96   1576 F pulseaudio
>   CasperMD5CheckResult: skip
>   CurrentDesktop: ubuntu:GNOME
>   Date: Thu Jul  8 19:57:18 2021
>   InstallationDate: Installed on 2021-06-08 (30 days ago)
>   InstallationMedia: Ubuntu 20.04.2.0 LTS "Focal Fossa" - Release amd64
> (20210209.1)
>   PackageArchitecture: all
>   ProcEnviron:
>PATH=(custom, no user)
>XDG_RUNTIME_DIR=
>LANG=en_US.UTF-8
>SHELL=/bin/bash
>   SourcePackage: alsa-driver
>   Symptom: audio
>   Symptom_AlsaRecordingTest: ALSA recording test through plughw:PCH failed
>   Symptom_Card: Built-in Audio - HDA Intel PCH
>   Symptom_Jack: Black Mic, Front
>   Symptom_Type: None of the above
>   Title: [HP Compaq Pro 6300 MT, Realtek ALC221, Black Mic, Front]
> Recording problem
>   UpgradeStatus: No upgrade log present (probably fresh install)
>   dmi.bios.date: 10/29/2012
>   dmi.bios.release: 2.83
>   dmi.bios.vendor: Hewlett-Packard
>   dmi.bios.version: K01 v02.83
>   dmi.board.asset.tag: MXL312111Y
>   dmi.board.name: 339A
>   dmi.board.vendor: Hewlett-Packard
>   dmi.chassis.asset.tag: MXL312111Y
>   dmi.chassis.type: 6
>   dmi.chassis.vendor: Hewlett-Packard
>   dmi.modalias:
> dmi:bvnHewlett-Packard:bvrK01v02.83:bd10/29/2012:br2.83:svnHewlett-Packard:pnHPCompaqPro6300MT:pvr:rvnHewlett-Packard:rn339A:rvr:cvnHewlett-Packard:ct6:cvr:
>   dmi.product.family: 103C_53307F G=D
>   dmi.product.name: HP Compaq Pro 6300 MT
>   dmi.product.sku: C6Z93UT#ABA
>   dmi.sys.vendor: Hewlett-Packard
>
> To manage notifications about this bug go to:
>
> https://bugs.launchpad.net/ubuntu/+source/alsa-driver/+bug/1935570/+subscriptions
>

-- 
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/1935570

Title:
  [HP Compaq Pro 6300 MT, Realtek ALC221, Black Mic, Front] Recording
  problem

Status in alsa-driver package in Ubuntu:
  New

Bug description:
  Hi,

  the mic does not work in my Ubuntu OS. Can you guys do something i am
  very frustrated?

  ProblemType: Bug
  DistroRelease: Ubuntu 20.04
  Package: alsa-base 1.0.25+dfsg-0ubuntu5
  ProcVersionSignature: Ubuntu 5.8.0-59.66~20.04.1-generic 5.8.18
  Uname: Linux 5.8.0-59-generic x86_64
  ApportVersion: 2.20.11-0ubuntu27.18
  Architecture: amd64
  AudioDevicesInUse:
   USERPID ACCESS COMMAND
   /dev/snd/controlC0:  ravisah96   1576 F pulseaudio
  CasperMD5CheckResult: skip
  CurrentDesktop: ubuntu:GNOME
  Date: Thu Jul  8 19:57:18 2021
  InstallationDate: Installed on 2021-06-08 (30 days ago)
  InstallationMedia: Ubuntu 20.04.2.0 LTS "Focal Fossa" - Release amd64 
(20210209.1)
  PackageArchitecture: all
  ProcEnviron:
   PATH=(custom, no user)
   XDG_RUNTIME_DIR=
   LANG=en_US.UTF-8
   SHELL=/bin/bash
  SourcePackage: alsa-driver
  Symptom: audio
  Symptom_AlsaRecordingTest: ALSA recording test through plughw:PCH failed
  Symptom_Card: Built-in Audio - HDA Intel PCH
  Symptom_Jack: Black Mic, Front
  Symptom_Type: None of the above
  Title: [HP Compaq Pro 6300 MT, Realtek ALC221, Black Mic, Front] Recording 
problem
  UpgradeStatus: No upgrade log present (probably fresh install)
  dmi.bios.date: 10/29/2012
  dmi.bios.release: 2.83
  dmi.bios.vendor: Hewlett-Packard
  dmi.bios.version: K01 v02.83
  dmi.board.asset.tag: MXL312111Y
  dmi.board.name: 339A
  dmi.board.vendor: Hewlett-Packard
  dmi.chassis.asset.tag: MXL312111Y
  dmi.chassis.type: 6
  dmi.chassis.vendor: Hewlett-Packard
  dmi.modalias: 
dmi:bvnHewlett-Packard:bvrK01v02.83:bd10/29/2012:br2.83:svnHewlett-Packard:pnHPCompaqPro6300MT:pvr:rvnHewlett-Packard:rn339A:rvr:cvnHewlett-Packard:ct6:cvr:
  dmi.product.family: 103C_53307F G=D
  dmi.product.name: HP Compaq Pro 6300 MT
  dmi.product.sku: C6Z93UT#ABA
  dmi.sys.vendor: Hewlett-Packard

To manage notifications about this bug go 

[Touch-packages] [Bug 1935570] Re: [HP Compaq Pro 6300 MT, Realtek ALC221, Black Mic, Front] Recording problem

[Hui Wang]

Please try a boot parameter: snd_hda_intel.model=alc221-hp-mic

After booting with this parameter, when you plug a mic to the audio
jack, a popup dialogue will sho to let you select what audio device you
plugged.

Let us see if there is that pop-up dialogue first.

-- 
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/1935570

Title:
  [HP Compaq Pro 6300 MT, Realtek ALC221, Black Mic, Front] Recording
  problem

Status in alsa-driver package in Ubuntu:
  New

Bug description:
  Hi,

  the mic does not work in my Ubuntu OS. Can you guys do something i am
  very frustrated?

  ProblemType: Bug
  DistroRelease: Ubuntu 20.04
  Package: alsa-base 1.0.25+dfsg-0ubuntu5
  ProcVersionSignature: Ubuntu 5.8.0-59.66~20.04.1-generic 5.8.18
  Uname: Linux 5.8.0-59-generic x86_64
  ApportVersion: 2.20.11-0ubuntu27.18
  Architecture: amd64
  AudioDevicesInUse:
   USERPID ACCESS COMMAND
   /dev/snd/controlC0:  ravisah96   1576 F pulseaudio
  CasperMD5CheckResult: skip
  CurrentDesktop: ubuntu:GNOME
  Date: Thu Jul  8 19:57:18 2021
  InstallationDate: Installed on 2021-06-08 (30 days ago)
  InstallationMedia: Ubuntu 20.04.2.0 LTS "Focal Fossa" - Release amd64 
(20210209.1)
  PackageArchitecture: all
  ProcEnviron:
   PATH=(custom, no user)
   XDG_RUNTIME_DIR=
   LANG=en_US.UTF-8
   SHELL=/bin/bash
  SourcePackage: alsa-driver
  Symptom: audio
  Symptom_AlsaRecordingTest: ALSA recording test through plughw:PCH failed
  Symptom_Card: Built-in Audio - HDA Intel PCH
  Symptom_Jack: Black Mic, Front
  Symptom_Type: None of the above
  Title: [HP Compaq Pro 6300 MT, Realtek ALC221, Black Mic, Front] Recording 
problem
  UpgradeStatus: No upgrade log present (probably fresh install)
  dmi.bios.date: 10/29/2012
  dmi.bios.release: 2.83
  dmi.bios.vendor: Hewlett-Packard
  dmi.bios.version: K01 v02.83
  dmi.board.asset.tag: MXL312111Y
  dmi.board.name: 339A
  dmi.board.vendor: Hewlett-Packard
  dmi.chassis.asset.tag: MXL312111Y
  dmi.chassis.type: 6
  dmi.chassis.vendor: Hewlett-Packard
  dmi.modalias: 
dmi:bvnHewlett-Packard:bvrK01v02.83:bd10/29/2012:br2.83:svnHewlett-Packard:pnHPCompaqPro6300MT:pvr:rvnHewlett-Packard:rn339A:rvr:cvnHewlett-Packard:ct6:cvr:
  dmi.product.family: 103C_53307F G=D
  dmi.product.name: HP Compaq Pro 6300 MT
  dmi.product.sku: C6Z93UT#ABA
  dmi.sys.vendor: Hewlett-Packard

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/alsa-driver/+bug/1935570/+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 1935570] Re: [HP Compaq Pro 6300 MT, Realtek ALC221, Black Mic, Front] Recording problem

[Hui Wang]

A similar bug: https://bugs.launchpad.net/ubuntu/+source/alsa-
driver/+bug/1935570

-- 
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/1935570

Title:
  [HP Compaq Pro 6300 MT, Realtek ALC221, Black Mic, Front] Recording
  problem

Status in alsa-driver package in Ubuntu:
  New

Bug description:
  Hi,

  the mic does not work in my Ubuntu OS. Can you guys do something i am
  very frustrated?

  ProblemType: Bug
  DistroRelease: Ubuntu 20.04
  Package: alsa-base 1.0.25+dfsg-0ubuntu5
  ProcVersionSignature: Ubuntu 5.8.0-59.66~20.04.1-generic 5.8.18
  Uname: Linux 5.8.0-59-generic x86_64
  ApportVersion: 2.20.11-0ubuntu27.18
  Architecture: amd64
  AudioDevicesInUse:
   USERPID ACCESS COMMAND
   /dev/snd/controlC0:  ravisah96   1576 F pulseaudio
  CasperMD5CheckResult: skip
  CurrentDesktop: ubuntu:GNOME
  Date: Thu Jul  8 19:57:18 2021
  InstallationDate: Installed on 2021-06-08 (30 days ago)
  InstallationMedia: Ubuntu 20.04.2.0 LTS "Focal Fossa" - Release amd64 
(20210209.1)
  PackageArchitecture: all
  ProcEnviron:
   PATH=(custom, no user)
   XDG_RUNTIME_DIR=
   LANG=en_US.UTF-8
   SHELL=/bin/bash
  SourcePackage: alsa-driver
  Symptom: audio
  Symptom_AlsaRecordingTest: ALSA recording test through plughw:PCH failed
  Symptom_Card: Built-in Audio - HDA Intel PCH
  Symptom_Jack: Black Mic, Front
  Symptom_Type: None of the above
  Title: [HP Compaq Pro 6300 MT, Realtek ALC221, Black Mic, Front] Recording 
problem
  UpgradeStatus: No upgrade log present (probably fresh install)
  dmi.bios.date: 10/29/2012
  dmi.bios.release: 2.83
  dmi.bios.vendor: Hewlett-Packard
  dmi.bios.version: K01 v02.83
  dmi.board.asset.tag: MXL312111Y
  dmi.board.name: 339A
  dmi.board.vendor: Hewlett-Packard
  dmi.chassis.asset.tag: MXL312111Y
  dmi.chassis.type: 6
  dmi.chassis.vendor: Hewlett-Packard
  dmi.modalias: 
dmi:bvnHewlett-Packard:bvrK01v02.83:bd10/29/2012:br2.83:svnHewlett-Packard:pnHPCompaqPro6300MT:pvr:rvnHewlett-Packard:rn339A:rvr:cvnHewlett-Packard:ct6:cvr:
  dmi.product.family: 103C_53307F G=D
  dmi.product.name: HP Compaq Pro 6300 MT
  dmi.product.sku: C6Z93UT#ABA
  dmi.sys.vendor: Hewlett-Packard

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/alsa-driver/+bug/1935570/+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 1935568] Re: after having a bug reported, locked screen, and coming back, ubuntu-bug -w leaves a gksudo dialog for dmesg open

[Brian Murray]

The reason I mentioned jackd is the bug description shows a listing of
crashes in /var/crash and there is one from July 8th:

CrashReports:
 644:1000:124:0:2021-07-08 04:45:57.713189974 +0200:2021-07-08 
04:45:57.713189974 +0200:/var/crash/_usr_bin_jackd.1000.upload
 600:118:124:37:2021-07-08 04:46:00.914606508 +0200:2021-07-08 
04:46:00.906605467 +0200:/var/crash/_usr_bin_jackd.1000.uploaded

-- 
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/1935568

Title:
  after having a bug reported, locked screen, and coming back, ubuntu-
  bug -w leaves a gksudo dialog for dmesg open

Status in apport package in Ubuntu:
  New

Bug description:
  I reported two bugs today, and both times, after having finished
  reporting the bug, locking my screen, and logging back in, suddenly
  there was a dialog asking for my sudo password so it can execute
  dmesg.

  But I could neither hit cancel nor could I enter my password, it
  apperaded that anything I did, especially clicks, made the window
  *below* the dialog react.

  First time I solved it by rebooting (because I had some packages to
  upgrade anyway), second time by killing gnome-shell and letting it
  restart.

  This dialog definitely did not appear in the process of reporting the
  bug, the first time it appeared on screen was minutes after completing
  the bugreports in launchpad, plus locking and unlocking the screen
  afterwards.

  Might also be a problem with gnome-shell or gksudo(?), but it only
  ever happened to me when using ubuntu-bug -w.

  ProblemType: Bug
  DistroRelease: Ubuntu 20.10
  Package: apport 2.20.11-0ubuntu50.7
  ProcVersionSignature: Ubuntu 5.8.0-59.66-lowlatency 5.8.18
  Uname: Linux 5.8.0-59-lowlatency x86_64
  ApportVersion: 2.20.11-0ubuntu50.7
  Architecture: amd64
  CasperMD5CheckResult: skip
  CrashReports:
   644:1000:124:0:2021-07-08 04:45:57.713189974 +0200:2021-07-08 
04:45:57.713189974 +0200:/var/crash/_usr_bin_jackd.1000.upload
   600:118:124:37:2021-07-08 04:46:00.914606508 +0200:2021-07-08 
04:46:00.906605467 +0200:/var/crash/_usr_bin_jackd.1000.uploaded
  CurrentDesktop: ubuntu:GNOME
  Date: Fri Jul  9 01:44:39 2021
  InstallationDate: Installed on 2020-04-12 (452 days ago)
  InstallationMedia: Ubuntu 19.10 "Eoan Ermine" - Release amd64 (20191017)
  PackageArchitecture: all
  SourcePackage: apport
  UpgradeStatus: Upgraded to groovy on 2020-11-03 (247 days ago)

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/apport/+bug/1935568/+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 1918458] Re: [Swift SF515-51T, Realtek ALC256, Grey Speaker, Internal] Playback problem, no sound from speakers, headphones ok

[Hui Wang]

Please collect a log while the system is playing the sound via speaker:

 check the speaker is the active output device
 play the music via youtu or sth else
 run 'sudo sh -c 'echo 1 > /sys/module/snd_hda_codec/parameters/dump_coef'
 run 'alsa-info --no-upload' to get the alsa-info.txt.
 upload the alsa-info.txt.

thx.

-- 
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/1918458

Title:
  [Swift SF515-51T, Realtek ALC256, Grey Speaker, Internal] Playback
  problem, no sound from speakers, headphones ok

Status in alsa-driver package in Ubuntu:
  Confirmed

Bug description:
  Expect : sound from speaker
  Instead, obtain : no sound.

  
  Tried various configuration of /etc/modprobe.d/alsa-conf with :

  options snd-hda-intel model= and
  options snd-intel-dspcfg dsp_driver=3 or 1
  and systematic reboot.

  Either I get dummy output, or I get proper output detection, alsamixer
  and pavucontrol seems 100% ok, but no sound comes from the speakers.

  I'm under a dualboot with Windows 10, BIOS fast boot disabled.
  Ubuntu 20.04.2 LTS

  ProblemType: Bug
  DistroRelease: Ubuntu 20.04
  Package: alsa-base 1.0.25+dfsg-0ubuntu5
  ProcVersionSignature: Ubuntu 5.8.0-44.50~20.04.1-generic 5.8.18
  Uname: Linux 5.8.0-44-generic x86_64
  ApportVersion: 2.20.11-0ubuntu27.16
  Architecture: amd64
  AudioDevicesInUse:
   USERPID ACCESS COMMAND
   /dev/snd/controlC0:  thibauts   1522 F pulseaudio
   /dev/snd/pcmC0D0p:   thibauts   1522 F...m pulseaudio
  CasperMD5CheckResult: skip
  CurrentDesktop: ubuntu:GNOME
  Date: Wed Mar 10 18:10:30 2021
  InstallationDate: Installed on 2021-03-09 (1 days ago)
  InstallationMedia: Ubuntu 20.04.2.0 LTS "Focal Fossa" - Release amd64 
(20210209.1)
  PackageArchitecture: all
  SourcePackage: alsa-driver
  Symptom: audio
  Symptom_AlsaPlaybackTest: ALSA playback test through plughw:sofhdadsp failed
  Symptom_Card: Cannon Point-LP High Definition Audio Controller - sof-hda-dsp
  Symptom_Jack: Grey Speaker, Internal
  Symptom_Type: Only some of outputs are working
  Title: [Swift SF515-51T, Realtek ALC256, Grey Speaker, Internal] Playback 
problem
  UpgradeStatus: No upgrade log present (probably fresh install)
  dmi.bios.date: 05/24/2019
  dmi.bios.release: 1.4
  dmi.bios.vendor: American Megatrends Inc.
  dmi.bios.version: V1.04
  dmi.board.asset.tag: Default string
  dmi.board.name: Guinness_WL
  dmi.board.vendor: WL
  dmi.board.version: V1.04
  dmi.chassis.type: 10
  dmi.chassis.vendor: Acer
  dmi.chassis.version: V1.04
  dmi.ec.firmware.release: 1.6
  dmi.modalias: 
dmi:bvnAmericanMegatrendsInc.:bvrV1.04:bd05/24/2019:br1.4:efr1.6:svnAcer:pnSwiftSF515-51T:pvrV1.04:rvnWL:rnGuinness_WL:rvrV1.04:cvnAcer:ct10:cvrV1.04:
  dmi.product.family: Swift 5
  dmi.product.name: Swift SF515-51T
  dmi.product.sku: 
  dmi.product.version: V1.04
  dmi.sys.vendor: Acer
  mtime.conffile..etc.modprobe.d.alsa-base.conf: 2021-03-10T18:04:19.277254

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/alsa-driver/+bug/1918458/+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 1935568] Re: after having a bug reported, locked screen, and coming back, ubuntu-bug -w leaves a gksudo dialog for dmesg open

[Henning Sprang]

On Fri 9. Jul 2021 at 16:55, Brian Murray <1935...@bugs.launchpad.net>
wrote:

> What package / application were you reporting a bug about? IIRC most
> apport hooks won't ask for dmesg information.
>

Besides automatic crash reports which i haven’t seen happening for
quite some time,
I only used it yesterday for thunderbird and this bug here…


> If you remove the crash files in /var/crash/ and lock your screen do you
> get another jackd crash in there?


Gonna try when back at the device.


It could be that the crash reporting
> process for jackd actually is asking for dmesg information.


Actually i haven’t been aware of a jackd crash recently.

but maybe i just didn’t perceive it as one, while it regularly quits when
switching off my external audio interface - which might look to apport as
unexpected but to me is expected.

I definitely don’t remember apport doing something about an jackd crash
recently , and this effect described here never appeared before having used
ubuntu-bug -w yesterday.



-- 
Henning Sprang
http://www.sprang.de

-- 
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/1935568

Title:
  after having a bug reported, locked screen, and coming back, ubuntu-
  bug -w leaves a gksudo dialog for dmesg open

Status in apport package in Ubuntu:
  New

Bug description:
  I reported two bugs today, and both times, after having finished
  reporting the bug, locking my screen, and logging back in, suddenly
  there was a dialog asking for my sudo password so it can execute
  dmesg.

  But I could neither hit cancel nor could I enter my password, it
  apperaded that anything I did, especially clicks, made the window
  *below* the dialog react.

  First time I solved it by rebooting (because I had some packages to
  upgrade anyway), second time by killing gnome-shell and letting it
  restart.

  This dialog definitely did not appear in the process of reporting the
  bug, the first time it appeared on screen was minutes after completing
  the bugreports in launchpad, plus locking and unlocking the screen
  afterwards.

  Might also be a problem with gnome-shell or gksudo(?), but it only
  ever happened to me when using ubuntu-bug -w.

  ProblemType: Bug
  DistroRelease: Ubuntu 20.10
  Package: apport 2.20.11-0ubuntu50.7
  ProcVersionSignature: Ubuntu 5.8.0-59.66-lowlatency 5.8.18
  Uname: Linux 5.8.0-59-lowlatency x86_64
  ApportVersion: 2.20.11-0ubuntu50.7
  Architecture: amd64
  CasperMD5CheckResult: skip
  CrashReports:
   644:1000:124:0:2021-07-08 04:45:57.713189974 +0200:2021-07-08 
04:45:57.713189974 +0200:/var/crash/_usr_bin_jackd.1000.upload
   600:118:124:37:2021-07-08 04:46:00.914606508 +0200:2021-07-08 
04:46:00.906605467 +0200:/var/crash/_usr_bin_jackd.1000.uploaded
  CurrentDesktop: ubuntu:GNOME
  Date: Fri Jul  9 01:44:39 2021
  InstallationDate: Installed on 2020-04-12 (452 days ago)
  InstallationMedia: Ubuntu 19.10 "Eoan Ermine" - Release amd64 (20191017)
  PackageArchitecture: all
  SourcePackage: apport
  UpgradeStatus: Upgraded to groovy on 2020-11-03 (247 days ago)

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/apport/+bug/1935568/+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 1858210] Re: timedatectl doesn't list all timezones

[Dan Streetman]

root@lp1858210-f:~# dpkg -l systemd|grep systemd
ii  systemd245.4-4ubuntu3.7 amd64system and service manager
root@lp1858210-f:~# timedatectl list-timezones | grep Eastern
root@lp1858210-f:~# 

root@lp1858210-f:~# dpkg -l systemd|grep systemd
ii  systemd245.4-4ubuntu3.8 amd64system and service manager
root@lp1858210-f:~# timedatectl list-timezones | grep Eastern
Canada/Eastern
US/Eastern


** Tags removed: verification-needed verification-needed-focal 
verification-needed-groovy verification-needed-hirsute
** Tags added: verification-done verification-done-focal 
verification-done-groovy verification-done-hirsute

-- 
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/1858210

Title:
  timedatectl doesn't list all timezones

Status in systemd package in Ubuntu:
  Fix Released
Status in systemd source package in Bionic:
  Won't Fix
Status in systemd source package in Focal:
  Fix Committed
Status in systemd source package in Groovy:
  Fix Committed
Status in systemd source package in Hirsute:
  Fix Committed
Status in systemd source package in Impish:
  Fix Released

Bug description:
  [impact]

  timedatectl list-timezones doesn't show many common timezones that are
  actually considered 'aliases', such as Europe/Bratislava or
  US/Eastern.

  [test case]

  $ timedatectl list-timezones | grep Eastern
  $

  [regression potential]

  any regression would likely result in an incorrect list of timezones
  shown from list-timezones, or failure to correctly set a timezone

  [scope]

  this is needed in f and later

  this is fixed upstream with PR 20066 which was just merged, so this is
  needed in all releases in ubuntu

  in bionic, the 'tzdata.zi' file that the new code uses isn't present,
  so this won't work on bionic, thus marking it wontfix

  [original description]

  Is there some filter determining which timezones are displayed by
  `timedatectl list-timezones`? My zone, Europe/Bratislava, is missing.
  Even stranger, it can successfully be set by timedatectl.

  ProblemType: Bug
  DistroRelease: Ubuntu 19.10
  Package: systemd 242-7ubuntu3.2
  ProcVersionSignature: Ubuntu 5.3.0-1014.16-raspi2 5.3.10
  Uname: Linux 5.3.0-1014-raspi2 aarch64
  ApportVersion: 2.20.11-0ubuntu8.2
  Architecture: arm64
  Date: Fri Jan  3 15:36:03 2020
  Lspci:

  ProcEnviron:
   TERM=xterm-256color
   PATH=(custom, no user)
   LANG=C.UTF-8
   SHELL=/bin/bash
  ProcKernelCmdLine: coherent_pool=1M 8250.nr_uarts=1 bcm2708_fb.fbwidth=1824 
bcm2708_fb.fbheight=984 bcm2708_fb.fbswap=1 vc_mem.mem_base=0x3ec0 
vc_mem.mem_size=0x4000  net.ifnames=0 dwc_otg.lpm_enable=0 
console=ttyS0,115200 console=tty1 root=LABEL=writable rootfstype=ext4 
elevator=deadline rootwait fixrtc
  SourcePackage: systemd
  UpgradeStatus: No upgrade log present (probably fresh install)
  mtime.conffile..etc.systemd.resolved.conf: 2020-01-03T01:02:47.779343

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/systemd/+bug/1858210/+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 1858210] Re: timedatectl doesn't list all timezones

[Dan Streetman]

root@lp1858210-g:~# dpkg -l systemd | grep systemd
ii  systemd246.6-1ubuntu1.4 amd64system and service manager
root@lp1858210-g:~# timedatectl list-timezones | grep Eastern
root@lp1858210-g:~# 

root@lp1858210-g:~# dpkg -l systemd | grep systemd
ii  systemd246.6-1ubuntu1.5 amd64system and service manager
root@lp1858210-g:~# timedatectl list-timezones | grep Eastern
Canada/Eastern
US/Eastern

-- 
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/1858210

Title:
  timedatectl doesn't list all timezones

Status in systemd package in Ubuntu:
  Fix Released
Status in systemd source package in Bionic:
  Won't Fix
Status in systemd source package in Focal:
  Fix Committed
Status in systemd source package in Groovy:
  Fix Committed
Status in systemd source package in Hirsute:
  Fix Committed
Status in systemd source package in Impish:
  Fix Released

Bug description:
  [impact]

  timedatectl list-timezones doesn't show many common timezones that are
  actually considered 'aliases', such as Europe/Bratislava or
  US/Eastern.

  [test case]

  $ timedatectl list-timezones | grep Eastern
  $

  [regression potential]

  any regression would likely result in an incorrect list of timezones
  shown from list-timezones, or failure to correctly set a timezone

  [scope]

  this is needed in f and later

  this is fixed upstream with PR 20066 which was just merged, so this is
  needed in all releases in ubuntu

  in bionic, the 'tzdata.zi' file that the new code uses isn't present,
  so this won't work on bionic, thus marking it wontfix

  [original description]

  Is there some filter determining which timezones are displayed by
  `timedatectl list-timezones`? My zone, Europe/Bratislava, is missing.
  Even stranger, it can successfully be set by timedatectl.

  ProblemType: Bug
  DistroRelease: Ubuntu 19.10
  Package: systemd 242-7ubuntu3.2
  ProcVersionSignature: Ubuntu 5.3.0-1014.16-raspi2 5.3.10
  Uname: Linux 5.3.0-1014-raspi2 aarch64
  ApportVersion: 2.20.11-0ubuntu8.2
  Architecture: arm64
  Date: Fri Jan  3 15:36:03 2020
  Lspci:

  ProcEnviron:
   TERM=xterm-256color
   PATH=(custom, no user)
   LANG=C.UTF-8
   SHELL=/bin/bash
  ProcKernelCmdLine: coherent_pool=1M 8250.nr_uarts=1 bcm2708_fb.fbwidth=1824 
bcm2708_fb.fbheight=984 bcm2708_fb.fbswap=1 vc_mem.mem_base=0x3ec0 
vc_mem.mem_size=0x4000  net.ifnames=0 dwc_otg.lpm_enable=0 
console=ttyS0,115200 console=tty1 root=LABEL=writable rootfstype=ext4 
elevator=deadline rootwait fixrtc
  SourcePackage: systemd
  UpgradeStatus: No upgrade log present (probably fresh install)
  mtime.conffile..etc.systemd.resolved.conf: 2020-01-03T01:02:47.779343

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/systemd/+bug/1858210/+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 1858210] Re: timedatectl doesn't list all timezones

[Dan Streetman]

root@lp1858210-h:~# dpkg -l systemd|grep systemd
ii  systemd247.3-3ubuntu3.1 amd64system and service manager
root@lp1858210-h:~# timedatectl list-timezones | grep Eastern
root@lp1858210-h:~# 

root@lp1858210-h:~# dpkg -l systemd|grep systemd
ii  systemd247.3-3ubuntu3.2 amd64system and service manager
root@lp1858210-h:~# timedatectl list-timezones | grep Eastern
Canada/Eastern
US/Eastern

-- 
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/1858210

Title:
  timedatectl doesn't list all timezones

Status in systemd package in Ubuntu:
  Fix Released
Status in systemd source package in Bionic:
  Won't Fix
Status in systemd source package in Focal:
  Fix Committed
Status in systemd source package in Groovy:
  Fix Committed
Status in systemd source package in Hirsute:
  Fix Committed
Status in systemd source package in Impish:
  Fix Released

Bug description:
  [impact]

  timedatectl list-timezones doesn't show many common timezones that are
  actually considered 'aliases', such as Europe/Bratislava or
  US/Eastern.

  [test case]

  $ timedatectl list-timezones | grep Eastern
  $

  [regression potential]

  any regression would likely result in an incorrect list of timezones
  shown from list-timezones, or failure to correctly set a timezone

  [scope]

  this is needed in f and later

  this is fixed upstream with PR 20066 which was just merged, so this is
  needed in all releases in ubuntu

  in bionic, the 'tzdata.zi' file that the new code uses isn't present,
  so this won't work on bionic, thus marking it wontfix

  [original description]

  Is there some filter determining which timezones are displayed by
  `timedatectl list-timezones`? My zone, Europe/Bratislava, is missing.
  Even stranger, it can successfully be set by timedatectl.

  ProblemType: Bug
  DistroRelease: Ubuntu 19.10
  Package: systemd 242-7ubuntu3.2
  ProcVersionSignature: Ubuntu 5.3.0-1014.16-raspi2 5.3.10
  Uname: Linux 5.3.0-1014-raspi2 aarch64
  ApportVersion: 2.20.11-0ubuntu8.2
  Architecture: arm64
  Date: Fri Jan  3 15:36:03 2020
  Lspci:

  ProcEnviron:
   TERM=xterm-256color
   PATH=(custom, no user)
   LANG=C.UTF-8
   SHELL=/bin/bash
  ProcKernelCmdLine: coherent_pool=1M 8250.nr_uarts=1 bcm2708_fb.fbwidth=1824 
bcm2708_fb.fbheight=984 bcm2708_fb.fbswap=1 vc_mem.mem_base=0x3ec0 
vc_mem.mem_size=0x4000  net.ifnames=0 dwc_otg.lpm_enable=0 
console=ttyS0,115200 console=tty1 root=LABEL=writable rootfstype=ext4 
elevator=deadline rootwait fixrtc
  SourcePackage: systemd
  UpgradeStatus: No upgrade log present (probably fresh install)
  mtime.conffile..etc.systemd.resolved.conf: 2020-01-03T01:02:47.779343

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/systemd/+bug/1858210/+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 1928200] Re: Prompt error message "Failed to unmount /oldroot" when shutdown or reboot

[Dan Streetman]

> Upgraded to systemd 245.4-4ubuntu3.8 on ThinkPad P17, but this issue
is still exist.

you may be seeing some other problem, you should open a new bug

-- 
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/1928200

Title:
  Prompt error message "Failed to unmount /oldroot" when shutdown or
  reboot

Status in OEM Priority Project:
  Confirmed
Status in systemd package in Ubuntu:
  Fix Released
Status in systemd source package in Focal:
  Fix Committed

Bug description:
  [impact]

  root fs is not cleanly unmounted on shutdown

  [test case]

  create a file in /etc/binfmt.d/TestFormat.conf with the following
  content:

  :TestFormat:M::XX::/bin/true:F

  reboot the system, and then shutdown or reboot again, and watch the
  serial console for the error message:

  sd-umount[1334]: Failed to unmount /oldroot: Device or resource busy

  [regression potential]

  any regression would likely cause problems on shutdown and/or reboot,
  or may cause problems with unmounted root fs on shutdown/reboot

  [scope]

  this is needed only for f

  this is fixed upstream with PR 15566 which is included in v246, so
  this is fixed already in g and later

  this isn't reproducable on b

  [original description]

  On ubuntu 20.04, with latest kernel and systemd, it will show error on
  ThinkPad X1.

  sd-umount[1334]: Failed to unmount /oldroot: Device or resource busy

  systemd 245.4-4ubuntu3.6
  kernel: 5.8.0-53

To manage notifications about this bug go to:
https://bugs.launchpad.net/oem-priority/+bug/1928200/+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 1928200] Re: Prompt error message "Failed to unmount /oldroot" when shutdown or reboot

[Dan Streetman]

ubuntu@lp1928200-f:~$ cat /etc/binfmt.d/TestFormat.conf 
:TestFormat:M::XX::/bin/true:F
ubuntu@lp1928200-f:~$ dpkg -l systemd|grep systemd
ii  systemd245.4-4ubuntu3.6 amd64system and service manager

reboot to pick up change...

reboot again to show issue...

[  OK  ] Reached target Reboot.
[   35.164202] sd-umoun[1548]: Failed to unmount /oldroot: Device or resource 
busy
[   35.174070] shutdown[1]: Failed to finalize  file systems, ignoring
[   35.219215] reboot: Restarting system


ubuntu@lp1928200-f:~$ dpkg -l systemd|grep systemd
ii  systemd245.4-4ubuntu3.8 amd64system and service manager

reboot to pick up change...

reboot again to check issue...

[  OK  ] Reached target Reboot.
[   22.494535] reboot: Restarting system



** Tags removed: verification-needed verification-needed-focal
** Tags added: verification-done verification-done-focal

-- 
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/1928200

Title:
  Prompt error message "Failed to unmount /oldroot" when shutdown or
  reboot

Status in OEM Priority Project:
  Confirmed
Status in systemd package in Ubuntu:
  Fix Released
Status in systemd source package in Focal:
  Fix Committed

Bug description:
  [impact]

  root fs is not cleanly unmounted on shutdown

  [test case]

  create a file in /etc/binfmt.d/TestFormat.conf with the following
  content:

  :TestFormat:M::XX::/bin/true:F

  reboot the system, and then shutdown or reboot again, and watch the
  serial console for the error message:

  sd-umount[1334]: Failed to unmount /oldroot: Device or resource busy

  [regression potential]

  any regression would likely cause problems on shutdown and/or reboot,
  or may cause problems with unmounted root fs on shutdown/reboot

  [scope]

  this is needed only for f

  this is fixed upstream with PR 15566 which is included in v246, so
  this is fixed already in g and later

  this isn't reproducable on b

  [original description]

  On ubuntu 20.04, with latest kernel and systemd, it will show error on
  ThinkPad X1.

  sd-umount[1334]: Failed to unmount /oldroot: Device or resource busy

  systemd 245.4-4ubuntu3.6
  kernel: 5.8.0-53

To manage notifications about this bug go to:
https://bugs.launchpad.net/oem-priority/+bug/1928200/+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 1894622] Re: Missing manpage for systemd-resolve

[Dan Streetman]

root@lp1894622-f:~# dpkg -l systemd|grep systemd
ii  systemd245.4-4ubuntu3.7 amd64system and service manager
root@lp1894622-f:~# man systemd-resolve
No manual entry for systemd-resolve

root@lp1894622-f:~# dpkg -l systemd|grep systemd
ii  systemd245.4-4ubuntu3.8 amd64system and service manager
root@lp1894622-f:~# man systemd-resolve | head -1
RESOLVECTL(1)   
   resolvectl   

  RESOLVECTL(1)


** Tags removed: verification-needed verification-needed-focal 
verification-needed-groovy verification-needed-hirsute
** Tags added: verification-done verification-done-focal 
verification-done-groovy verification-done-hirsute

-- 
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/1894622

Title:
  Missing manpage for systemd-resolve

Status in systemd package in Ubuntu:
  Fix Released
Status in systemd source package in Focal:
  Fix Committed
Status in systemd source package in Groovy:
  Fix Committed
Status in systemd source package in Hirsute:
  Fix Committed
Status in systemd source package in Impish:
  Fix Released

Bug description:
  [impact]

  'man systemd-resolve' fails

  [test case]

  $ man systemd-resolve
  No manual entry for systemd-resolve

  [regression potential]

  incorrect man page result for resolvectl or resolvconf, or possibly
  users using deprecated systemd-resolve longer than they should

  [scope]

  this is needed in f and later

  systemd-resolve was replaced with resolvectl between b and f, so the
  man page exists in b

  [other info]

  the systemd-resolve binary is a symlink to the real binary resolvectl, and 
users should use resolvectl for all new uses. A patch to the upstream man page 
was proposed and merged in this PR:
  https://github.com/systemd/systemd/pull/20064

  however that is being discussed and may be reverted in this PR:
  https://github.com/systemd/systemd/pull/20077

  as discussed in the revert PR, it's ok for upstream to elide docs
  about deprecated tooling; however distros should include deprecation
  info and thus I believe it's appropriate to include the man page
  symlink so users trying 'man systemd-resolve' will get the correct
  'resolvectl' man page, which includes doc about how they shoudl start
  using 'resolvectl' instead

  [original description]

  On my Focal machine there is no file /usr/share/man/man1/systemd-resolve.1.gz
  This means that man systemd-resolve fails.

  http://manpages.ubuntu.com/manpages/bionic/en/man1/systemd-
  resolve.1.html exists and has a link on top to 20.04LTS: it points to
  http://manpages.ubuntu.com/manpages/focal/en/man1/systemd-
  resolve.1.html , that however 404's, and one ends up being redirected
  to Bionic's.

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/systemd/+bug/1894622/+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 1894622] Re: Missing manpage for systemd-resolve

[Dan Streetman]

root@lp1894622-g:~# dpkg -l systemd|grep systemd
ii  systemd246.6-1ubuntu1.4 amd64system and service manager
root@lp1894622-g:~# man systemd-resolve | head -1
No manual entry for systemd-resolve

root@lp1894622-g:~# dpkg -l systemd|grep systemd
ii  systemd246.6-1ubuntu1.5 amd64system and service manager
root@lp1894622-g:~# man systemd-resolve | head -1
RESOLVECTL(1)   
   resolvectl   

  RESOLVECTL(1)

-- 
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/1894622

Title:
  Missing manpage for systemd-resolve

Status in systemd package in Ubuntu:
  Fix Released
Status in systemd source package in Focal:
  Fix Committed
Status in systemd source package in Groovy:
  Fix Committed
Status in systemd source package in Hirsute:
  Fix Committed
Status in systemd source package in Impish:
  Fix Released

Bug description:
  [impact]

  'man systemd-resolve' fails

  [test case]

  $ man systemd-resolve
  No manual entry for systemd-resolve

  [regression potential]

  incorrect man page result for resolvectl or resolvconf, or possibly
  users using deprecated systemd-resolve longer than they should

  [scope]

  this is needed in f and later

  systemd-resolve was replaced with resolvectl between b and f, so the
  man page exists in b

  [other info]

  the systemd-resolve binary is a symlink to the real binary resolvectl, and 
users should use resolvectl for all new uses. A patch to the upstream man page 
was proposed and merged in this PR:
  https://github.com/systemd/systemd/pull/20064

  however that is being discussed and may be reverted in this PR:
  https://github.com/systemd/systemd/pull/20077

  as discussed in the revert PR, it's ok for upstream to elide docs
  about deprecated tooling; however distros should include deprecation
  info and thus I believe it's appropriate to include the man page
  symlink so users trying 'man systemd-resolve' will get the correct
  'resolvectl' man page, which includes doc about how they shoudl start
  using 'resolvectl' instead

  [original description]

  On my Focal machine there is no file /usr/share/man/man1/systemd-resolve.1.gz
  This means that man systemd-resolve fails.

  http://manpages.ubuntu.com/manpages/bionic/en/man1/systemd-
  resolve.1.html exists and has a link on top to 20.04LTS: it points to
  http://manpages.ubuntu.com/manpages/focal/en/man1/systemd-
  resolve.1.html , that however 404's, and one ends up being redirected
  to Bionic's.

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/systemd/+bug/1894622/+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 1894622] Re: Missing manpage for systemd-resolve

[Dan Streetman]

root@lp1894622-h:~# dpkg -l systemd| grep systemd
ii  systemd247.3-3ubuntu3.1 amd64system and service manager
root@lp1894622-h:~# man systemd-resolve | head -1
No manual entry for systemd-resolve

root@lp1894622-h:~# dpkg -l systemd| grep systemd
ii  systemd247.3-3ubuntu3.2 amd64system and service manager
root@lp1894622-h:~# man systemd-resolve | head -1
RESOLVECTL(1)   
   resolvectl   

  RESOLVECTL(1)

-- 
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/1894622

Title:
  Missing manpage for systemd-resolve

Status in systemd package in Ubuntu:
  Fix Released
Status in systemd source package in Focal:
  Fix Committed
Status in systemd source package in Groovy:
  Fix Committed
Status in systemd source package in Hirsute:
  Fix Committed
Status in systemd source package in Impish:
  Fix Released

Bug description:
  [impact]

  'man systemd-resolve' fails

  [test case]

  $ man systemd-resolve
  No manual entry for systemd-resolve

  [regression potential]

  incorrect man page result for resolvectl or resolvconf, or possibly
  users using deprecated systemd-resolve longer than they should

  [scope]

  this is needed in f and later

  systemd-resolve was replaced with resolvectl between b and f, so the
  man page exists in b

  [other info]

  the systemd-resolve binary is a symlink to the real binary resolvectl, and 
users should use resolvectl for all new uses. A patch to the upstream man page 
was proposed and merged in this PR:
  https://github.com/systemd/systemd/pull/20064

  however that is being discussed and may be reverted in this PR:
  https://github.com/systemd/systemd/pull/20077

  as discussed in the revert PR, it's ok for upstream to elide docs
  about deprecated tooling; however distros should include deprecation
  info and thus I believe it's appropriate to include the man page
  symlink so users trying 'man systemd-resolve' will get the correct
  'resolvectl' man page, which includes doc about how they shoudl start
  using 'resolvectl' instead

  [original description]

  On my Focal machine there is no file /usr/share/man/man1/systemd-resolve.1.gz
  This means that man systemd-resolve fails.

  http://manpages.ubuntu.com/manpages/bionic/en/man1/systemd-
  resolve.1.html exists and has a link on top to 20.04LTS: it points to
  http://manpages.ubuntu.com/manpages/focal/en/man1/systemd-
  resolve.1.html , that however 404's, and one ends up being redirected
  to Bionic's.

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/systemd/+bug/1894622/+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 1927078] Re: Don't allow useradd to use fully numeric names

[William Wilson]

This change disallows floating point and hexadecimal representations of
numbers as well as purely numeric, which should be a good compromise.
For example, 0x0 is now invalid, as well as 0x123456789 and 0.0, while
0x0x0x0x is considered valid. It also adds these new restrictions to the
man page.

** Patch added: "invalid hexadecimal and floating point"
   
https://bugs.launchpad.net/ubuntu/+source/shadow/+bug/1927078/+attachment/5510089/+files/lp1927078_fully_numeric_and_hex.debdiff

-- 
You received this bug notification because you are a member of Ubuntu
Touch seeded packages, which is subscribed to shadow in Ubuntu.
https://bugs.launchpad.net/bugs/1927078

Title:
  Don't allow useradd to use fully numeric names

Status in shadow package in Ubuntu:
  New
Status in shadow source package in Focal:
  New
Status in shadow source package in Groovy:
  New
Status in shadow source package in Hirsute:
  New
Status in shadow source package in Impish:
  New

Bug description:
  [Description]

  Fully numeric names support in Ubuntu is inconsistent in Focal onwards
  because systemd does not like them[1] but are still allowed by default
  by useradd, leaving the session behavior in hands of the running
  applications. Two examples:

  1. After creating a user named "0", the user can log in via ssh or
  console but loginctl won't create a session for it:

  root@focal:/home/ubuntu# useradd -m 0
  root@focal:/home/ubuntu# id 0
  uid=1005(0) gid=1005(0) groups=1005(0)

  ..

  0@192.168.122.6's password:
  Welcome to Ubuntu 20.04.2 LTS (GNU/Linux 5.8.0-48-generic x86_64)

  Last login: Thu Apr  8 16:17:06 2021 from 192.168.122.1
  $ loginctl
  No sessions.
  $ w
   16:20:09 up 4 min,  1 user,  load average: 0.03, 0.14, 0.08
  USER TTY  FROM LOGIN@   IDLE   JCPU   PCPU WHAT
  0pts/0192.168.122.116:170.00s  0.00s  0.00s w  

  And pam-systemd shows the following message:

  Apr 08 16:17:06 focal sshd[1584]: pam_unix(sshd:session): session opened for 
user 0 by (uid=0)
  Apr 08 16:17:06 focal sshd[1584]: pam_systemd(sshd:session): pam-systemd 
initializing
  Apr 08 16:17:06 focal sshd[1584]: pam_systemd(sshd:session): Failed to get 
user record: Invalid argument

  
  2. With that same username, every successful authentication in gdm will loop 
back to gdm again instead of starting gnome, making the user unable to login.

  
  Making useradd fail (unless --badnames is set) when a fully numeric name is 
used will make the default OS behavior consistent.

  
  [Other info]

  - Upstream does not support fully numeric usernames
  - useradd has a --badnames parameter that would still allow the use of these 
type of names

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/shadow/+bug/1927078/+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 1926843] Re: online accounts integration with fb isn't working

[Lars Martin Hambro]

I find Usage: clevis COMMAND [OPTIONS]

  clevis decrypt  Decrypts using the policy defined at encryption time
  clevis decrypt tpm2plus Encrypts using a TPM2.0 chip binding policy
  clevis encrypt sss  Encrypts using a Shamir's Secret Sharing policy
  clevis encrypt tang Encrypts using a Tang binding server policy
  clevis encrypt tpm2plus Encrypts using a TPM2.0 chip binding policy
  clevis pin tpm2 Encrypts using a TPM2.0 chip binding policy

-- 
You received this bug notification because you are a member of Ubuntu
Touch seeded packages, which is subscribed to gnome-online-accounts in
Ubuntu.
https://bugs.launchpad.net/bugs/1926843

Title:
  online accounts integration with fb isn't working

Status in gnome-online-accounts package in Ubuntu:
  Fix Released
Status in gnome-online-accounts source package in Focal:
  Fix Released
Status in gnome-online-accounts source package in Hirsute:
  Fix Released

Bug description:
  * Impact

  The online accounts setting are proposing a facebook item which isn't
  working

  * Test case

  Go to settings -> online account, browse the accounts option proposed,
  facebook shouldn't be in the list since it doesn't work.

  * Regression potential

  The change is to disable the facebook provider using the upstream
  provided build option. Check that facebook isn't listed anymore but
  that the other providers still are. Since it's a build option change
  it could fail to build so check for that as well on launchpad.

  Since the facebook service currently doesn't consider gnome-online-
  accounts as a valid client there should be no user with that provider
  configured. Even if there were since the service isn't working they
  would see a functional regression.

  ---

  Hi i tryed to use gnome-control-center online-accounts to make easy
  like windows 10 to login to email or add other login so its more easy
  with ID to use pincode or other ID fingerprint and other.

  But its look its much issue compared with windows 10 with thunderbird,
  firefox, and other program.

  Worst is facebook only little windows with issue with login?

  ProblemType: Bug
  DistroRelease: Ubuntu 21.04
  Package: gnome-online-accounts 3.38.1-1ubuntu1
  Uname: Linux 5.12.0-051200-generic x86_64
  NonfreeKernelModules: nvidia_modeset nvidia
  ApportVersion: 2.20.11-0ubuntu65
  Architecture: amd64
  CasperMD5CheckResult: unknown
  CurrentDesktop: ubuntu:GNOME
  Date: Sat May  1 19:38:03 2021
  InstallationDate: Installed on 2019-05-07 (725 days ago)
  InstallationMedia: Kubuntu 19.04 "Disco Dingo" - Release amd64 (20190416)
  SourcePackage: gnome-online-accounts
  UpgradeStatus: Upgraded to hirsute on 2021-04-06 (24 days ago)

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/gnome-online-accounts/+bug/1926843/+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 1853164] Re: systemd: /etc/dhcp/dhclient-enter-hooks.d/resolved error

[Mason Loring Bliss]

Hey there. Thanks for your time on this. I'll try to supply positive
confirmation over the weekend.

-- 
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/1853164

Title:
  systemd: /etc/dhcp/dhclient-enter-hooks.d/resolved error

Status in systemd package in Ubuntu:
  Fix Released
Status in systemd source package in Bionic:
  New
Status in systemd source package in Focal:
  Fix Committed

Bug description:
  [impact]

  with systemd-resolved disabled, dhclient doesn't correctly notify
  resolvconf about dns server(s)

  [test case]

  install resolvconf and ifupdown and disable systemd-resolved and
  systemd-networkd, use ifupdown to get a dhcp address where the lease
  includes a dns nameserver, verify resolvconf is using that dhcp-
  provided nameserver

  [regression potential]

  failure to correctly notify systemd-resolved about new dhclient-
  provided nameserver(s)

  [scope]

  this is needed for f and earlier

  in g and later the hook script is moved to the isc-dhcp package, and
  edited to correctly check is-enabled systemd-resolved instead of only
  checking for the existence of the binary

  [original description]

  The functionality exists to allow users to revert to the traditional ifupdown
  package for network configuration. Alongside this, systemd's often-buggy
  resolver can be disabled. However, there's a logic error in the systemd-
  supplied /etc/dhcp/dhclient-enter-hooks.d/resolved that prevents the system
  from populating /etc/resolv.conf properly when systemd-resolved is disabled.
  The issue is here:

  if [ -x /lib/systemd/systemd-resolved ] ; then

  Instead of checking to see if the systemd-resolved service is enabled or
  active, which would be the correct behaviour, this checks for the existence of
  a binary, assuming that if it exists it's supposed to be used.

  I've not tested this in the absence of resolvconf, but if systemd-resolved
  isn't enabled, it's difficult to imagine this code wanting to run. I've tested
  this with resolvconf and ifupdown driving dhclient, and it corrects the
  behaviour that was broken with the introduction of systemd-resolved.

  I'm attaching a patch, and am also including it here for easy access:

  *** resolved.broken 2019-11-19 15:01:28.785588838 +
  --- resolved2019-11-19 15:08:06.519430073 +
  ***
  *** 14,20 
    #   (D) = master script downs interface
    #   (-) = master script does nothing with this

  ! if [ -x /lib/systemd/systemd-resolved ] ; then
    # For safety, first undefine the nasty default make_resolv_conf()
    make_resolv_conf() { : ; }
    case "$reason" in
  --- 14,21 
    #   (D) = master script downs interface
    #   (-) = master script does nothing with this

  ! systemctl is-active systemd-resolved > /dev/null 2>&1
  ! if [ $? -eq 0 ]; then
    # For safety, first undefine the nasty default make_resolv_conf()
    make_resolv_conf() { : ; }
    case "$reason" in

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/systemd/+bug/1853164/+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 1935570] Re: [HP Compaq Pro 6300 MT, Realtek ALC221, Black Mic, Front] Recording problem

[Rabi Sah]

I am sorry. I did not understand for the first time. I did understand on
second time but I was not sure if I turned on the microphone because I have
a hyper-x headphone which needs to bring it down to turn on the headphones
so I am attaching this file after I turn on the headphone.

I would like to say thank you for your help for trying to fix this issue.
Here is the latest file after i attach the headphone and plugged in.:


On Fri, Jul 9, 2021 at 10:21 AM Rabi Sah  wrote:

> Here is the file:
>
> pa-info > pa-info.txt
>
> On Fri, Jul 9, 2021 at 10:18 AM Rabi Sah  wrote:
>
>> Hi ,
>>
>> i do not see the anything after i run pa-info > pa-info.txt command. I
>> did not understand what to do with your command.
>>
>> On Thu, Jul 8, 2021 at 11:50 PM Hui Wang <1935...@bugs.launchpad.net>
>> wrote:
>>
>>> Please plug the mic in, and run pa-info > pa-info.txt, then upload the
>>> pa-info.txt
>>>
>>> --
>>> You received this bug notification because you are subscribed to the bug
>>> report.
>>> https://bugs.launchpad.net/bugs/1935570
>>>
>>> Title:
>>>   [HP Compaq Pro 6300 MT, Realtek ALC221, Black Mic, Front] Recording
>>>   problem
>>>
>>> Status in alsa-driver package in Ubuntu:
>>>   New
>>>
>>> Bug description:
>>>   Hi,
>>>
>>>   the mic does not work in my Ubuntu OS. Can you guys do something i am
>>>   very frustrated?
>>>
>>>   ProblemType: Bug
>>>   DistroRelease: Ubuntu 20.04
>>>   Package: alsa-base 1.0.25+dfsg-0ubuntu5
>>>   ProcVersionSignature: Ubuntu 5.8.0-59.66~20.04.1-generic 5.8.18
>>>   Uname: Linux 5.8.0-59-generic x86_64
>>>   ApportVersion: 2.20.11-0ubuntu27.18
>>>   Architecture: amd64
>>>   AudioDevicesInUse:
>>>USERPID ACCESS COMMAND
>>>/dev/snd/controlC0:  ravisah96   1576 F pulseaudio
>>>   CasperMD5CheckResult: skip
>>>   CurrentDesktop: ubuntu:GNOME
>>>   Date: Thu Jul  8 19:57:18 2021
>>>   InstallationDate: Installed on 2021-06-08 (30 days ago)
>>>   InstallationMedia: Ubuntu 20.04.2.0 LTS "Focal Fossa" - Release amd64
>>> (20210209.1)
>>>   PackageArchitecture: all
>>>   ProcEnviron:
>>>PATH=(custom, no user)
>>>XDG_RUNTIME_DIR=
>>>LANG=en_US.UTF-8
>>>SHELL=/bin/bash
>>>   SourcePackage: alsa-driver
>>>   Symptom: audio
>>>   Symptom_AlsaRecordingTest: ALSA recording test through plughw:PCH
>>> failed
>>>   Symptom_Card: Built-in Audio - HDA Intel PCH
>>>   Symptom_Jack: Black Mic, Front
>>>   Symptom_Type: None of the above
>>>   Title: [HP Compaq Pro 6300 MT, Realtek ALC221, Black Mic, Front]
>>> Recording problem
>>>   UpgradeStatus: No upgrade log present (probably fresh install)
>>>   dmi.bios.date: 10/29/2012
>>>   dmi.bios.release: 2.83
>>>   dmi.bios.vendor: Hewlett-Packard
>>>   dmi.bios.version: K01 v02.83
>>>   dmi.board.asset.tag: MXL312111Y
>>>   dmi.board.name: 339A
>>>   dmi.board.vendor: Hewlett-Packard
>>>   dmi.chassis.asset.tag: MXL312111Y
>>>   dmi.chassis.type: 6
>>>   dmi.chassis.vendor: Hewlett-Packard
>>>   dmi.modalias:
>>> dmi:bvnHewlett-Packard:bvrK01v02.83:bd10/29/2012:br2.83:svnHewlett-Packard:pnHPCompaqPro6300MT:pvr:rvnHewlett-Packard:rn339A:rvr:cvnHewlett-Packard:ct6:cvr:
>>>   dmi.product.family: 103C_53307F G=D
>>>   dmi.product.name: HP Compaq Pro 6300 MT
>>>   dmi.product.sku: C6Z93UT#ABA
>>>   dmi.sys.vendor: Hewlett-Packard
>>>
>>> To manage notifications about this bug go to:
>>>
>>> https://bugs.launchpad.net/ubuntu/+source/alsa-driver/+bug/1935570/+subscriptions
>>>
>>


** Attachment added: "pa-info.txt"
   
https://bugs.launchpad.net/bugs/1935570/+attachment/5510085/+files/pa-info.txt

-- 
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/1935570

Title:
  [HP Compaq Pro 6300 MT, Realtek ALC221, Black Mic, Front] Recording
  problem

Status in alsa-driver package in Ubuntu:
  New

Bug description:
  Hi,

  the mic does not work in my Ubuntu OS. Can you guys do something i am
  very frustrated?

  ProblemType: Bug
  DistroRelease: Ubuntu 20.04
  Package: alsa-base 1.0.25+dfsg-0ubuntu5
  ProcVersionSignature: Ubuntu 5.8.0-59.66~20.04.1-generic 5.8.18
  Uname: Linux 5.8.0-59-generic x86_64
  ApportVersion: 2.20.11-0ubuntu27.18
  Architecture: amd64
  AudioDevicesInUse:
   USERPID ACCESS COMMAND
   /dev/snd/controlC0:  ravisah96   1576 F pulseaudio
  CasperMD5CheckResult: skip
  CurrentDesktop: ubuntu:GNOME
  Date: Thu Jul  8 19:57:18 2021
  InstallationDate: Installed on 2021-06-08 (30 days ago)
  InstallationMedia: Ubuntu 20.04.2.0 LTS "Focal Fossa" - Release amd64 
(20210209.1)
  PackageArchitecture: all
  ProcEnviron:
   PATH=(custom, no user)
   XDG_RUNTIME_DIR=
   LANG=en_US.UTF-8
   SHELL=/bin/bash
  SourcePackage: alsa-driver
  Symptom: audio
  Symptom_AlsaRecordingTest: ALSA recording test through plughw:PCH failed
  Symptom_Card: Built-in Audio - HDA Intel PCH
  Symptom_Jack: Black Mic, Front
  Symptom_Type: None of the above
  Title: [HP Compaq Pro 6300 MT, Realtek 

[Touch-packages] [Bug 1891215] Re: systemd-resolved re-creates /run/systemd/resolve/*resolv.conf for every IPv6 RA received

[Patrick Naubert]

Confirmed fixed on lxd02 and client site, running Focal.  No reboot was
done.

Thank you.

-- 
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/1891215

Title:
  systemd-resolved re-creates /run/systemd/resolve/*resolv.conf for
  every IPv6 RA received

Status in systemd:
  Unknown
Status in systemd package in Ubuntu:
  Fix Released
Status in systemd source package in Bionic:
  Confirmed
Status in systemd source package in Focal:
  Fix Committed
Status in systemd source package in Groovy:
  Fix Committed
Status in systemd source package in Hirsute:
  Fix Committed

Bug description:
  [impact]

  networking changes, like RA events, can cause systemd-resolved to re-
  write the resolv.conf file, even if the contents didn't change,
  resulting in unnecessary increased amount of inotify events

  [test case]

  see original description for ipv6ra-related reproducer, or simple
  reproducer here:

  configure networkd with some config for (e.g.) eth0, but not a config
  that would result in /etc/resolv.conf changing when the interface goes
  up/down - for example, use static config with no DNS search domains.
  Then bring eth0 up/down while observing the md5sum (file content) does
  not change but the mtime does change.

  root@lp1891215-h:~# ip l set down dev eth0
  root@lp1891215-h:~# md5sum /etc/resolv.conf
  db23e80078515192c312e5f321ff0340  /etc/resolv.conf
  root@lp1891215-h:~# stat -t -L /etc/resolv.conf
  /etc/resolv.conf 740 8 81a4 101 103 fc 188 1 0 0 1625238218 1625238216 
1625238216 0 4096
  root@lp1891215-h:~# ip l set up dev eth0
  root@lp1891215-h:~# md5sum /etc/resolv.conf
  db23e80078515192c312e5f321ff0340  /etc/resolv.conf
  root@lp1891215-h:~# stat -t -L /etc/resolv.conf
  /etc/resolv.conf 740 8 81a4 101 103 fc 188 1 0 0 1625238227 1625238226 
1625238226 0 4096

  [regression potential]

  regressions would result in incorrect or missing data in the
  resolv.conf file, possibly resulting in dns failures or errors

  [scope]

  this is needed for h and eralier

  this is (potentially) fixed upstream by
  f3e1f00d03445911ee73729219cea88c8a70c612 which in first included in
  v248, so this is needed in hirsute and earlier

  [original description]

  # Issue description:

  On 2 Linode VMs that are used as lxd hosts, we noticed that
  /run/systemd/resolve/*resolv.conf were re-created quite frequently (~
  once per second). We noticed because of the log noise from lxd's
  dnsmasq instance using inotify to watch the target of /etc/resolv.conf
  (which points to the stub-resolv.conf in our case). This was (wrongly)
  reported as a lxd bug (https://github.com/lxc/lxd/issues/7765) until
  it became apparent it was more likely to be a problem with
  systemd(-resolved)?.

  The log noise is the observable problem that would be nice to see
  addressed:

    root@lxd02:~# uptime
     17:55:48 up  9:52,  1 user,  load average: 0.18, 0.11, 0.05
    root@lxd02:~# journalctl -b0 | grep -cF dnsmasq
    158609

  Upon further investigation, it seems that systemd-resolved re-creates
  the resolv.conf and stub-resolv.conf files whenever an IPv6 RA is
  received.

  1) One can observe that by setting systemd-resolved's service in debug
  mode:

  $ sudo systemctl edit systemd-resolved

  and in the editor that is opened, add and save this content:

  [Service]
  Environment=SYSTEMD_LOG_LEVEL=debug

  then restart systemd-resolved and watch the logs scroll by with:

  $ journalctl -fu systemd-resolved

  3) In another terminal, watch the files be recreated with:

  watch -d -n 0.1 stat /run/systemd/resolve/stub-resolv.conf

  3) In yet another terminal, run a packet capture and watch "ICMP6,
  router advertisement" messages come by:

  sudo tcpdump -ni eth0 icmp6

  You will see that every time a RA packet comes in, resolved's journal
  will log this:

    Aug 11 17:33:55 lxd02 systemd-resolved[15368]: Sent message
  type=signal sender=n/a destination=n/a path=/org/freedesktop/resolve1
  interface=org.freedesktop.DBus.Properties member=PropertiesChanged
  cookie=244 reply_cookie=0 signature=sa{sv}as error-name=n/a error-
  message=n/a

  And the stat monitoring terminal will blink to highlight the new inode
  and timestamps of the freshly replaced stub-resolv.conf file.

  # Additional information:

  root@lxd02:~# lsb_release -rd
  Description:  Ubuntu 20.04.1 LTS
  Release:  20.04

  root@lxd02:~# apt-cache policy systemd
  systemd:
    Installed: 245.4-4ubuntu3.2
    Candidate: 245.4-4ubuntu3.2
    Version table:
   *** 245.4-4ubuntu3.2 500
  500 http://archive.ubuntu.com/ubuntu focal-updates/main amd64 Packages
  100 /var/lib/dpkg/status
   245.4-4ubuntu3 500
  500 http://archive.ubuntu.com/ubuntu focal/main amd64 Packages

  root@lxd02:~# uname -a
  Linux lxd01 5.4.0-42-generic #46-Ubuntu SMP Fri Jul 10 00:24:02 UTC 2020 
x86_64 x86_64 x86_64 GNU/Linux

To manage 

[Touch-packages] [Bug 1891215] Re: systemd-resolved re-creates /run/systemd/resolve/*resolv.conf for every IPv6 RA received

[Launchpad Bug Tracker]

Status changed to 'Confirmed' because the bug affects multiple users.

** Changed in: systemd (Ubuntu Bionic)
   Status: New => Confirmed

-- 
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/1891215

Title:
  systemd-resolved re-creates /run/systemd/resolve/*resolv.conf for
  every IPv6 RA received

Status in systemd:
  Unknown
Status in systemd package in Ubuntu:
  Fix Released
Status in systemd source package in Bionic:
  Confirmed
Status in systemd source package in Focal:
  Fix Committed
Status in systemd source package in Groovy:
  Fix Committed
Status in systemd source package in Hirsute:
  Fix Committed

Bug description:
  [impact]

  networking changes, like RA events, can cause systemd-resolved to re-
  write the resolv.conf file, even if the contents didn't change,
  resulting in unnecessary increased amount of inotify events

  [test case]

  see original description for ipv6ra-related reproducer, or simple
  reproducer here:

  configure networkd with some config for (e.g.) eth0, but not a config
  that would result in /etc/resolv.conf changing when the interface goes
  up/down - for example, use static config with no DNS search domains.
  Then bring eth0 up/down while observing the md5sum (file content) does
  not change but the mtime does change.

  root@lp1891215-h:~# ip l set down dev eth0
  root@lp1891215-h:~# md5sum /etc/resolv.conf
  db23e80078515192c312e5f321ff0340  /etc/resolv.conf
  root@lp1891215-h:~# stat -t -L /etc/resolv.conf
  /etc/resolv.conf 740 8 81a4 101 103 fc 188 1 0 0 1625238218 1625238216 
1625238216 0 4096
  root@lp1891215-h:~# ip l set up dev eth0
  root@lp1891215-h:~# md5sum /etc/resolv.conf
  db23e80078515192c312e5f321ff0340  /etc/resolv.conf
  root@lp1891215-h:~# stat -t -L /etc/resolv.conf
  /etc/resolv.conf 740 8 81a4 101 103 fc 188 1 0 0 1625238227 1625238226 
1625238226 0 4096

  [regression potential]

  regressions would result in incorrect or missing data in the
  resolv.conf file, possibly resulting in dns failures or errors

  [scope]

  this is needed for h and eralier

  this is (potentially) fixed upstream by
  f3e1f00d03445911ee73729219cea88c8a70c612 which in first included in
  v248, so this is needed in hirsute and earlier

  [original description]

  # Issue description:

  On 2 Linode VMs that are used as lxd hosts, we noticed that
  /run/systemd/resolve/*resolv.conf were re-created quite frequently (~
  once per second). We noticed because of the log noise from lxd's
  dnsmasq instance using inotify to watch the target of /etc/resolv.conf
  (which points to the stub-resolv.conf in our case). This was (wrongly)
  reported as a lxd bug (https://github.com/lxc/lxd/issues/7765) until
  it became apparent it was more likely to be a problem with
  systemd(-resolved)?.

  The log noise is the observable problem that would be nice to see
  addressed:

    root@lxd02:~# uptime
     17:55:48 up  9:52,  1 user,  load average: 0.18, 0.11, 0.05
    root@lxd02:~# journalctl -b0 | grep -cF dnsmasq
    158609

  Upon further investigation, it seems that systemd-resolved re-creates
  the resolv.conf and stub-resolv.conf files whenever an IPv6 RA is
  received.

  1) One can observe that by setting systemd-resolved's service in debug
  mode:

  $ sudo systemctl edit systemd-resolved

  and in the editor that is opened, add and save this content:

  [Service]
  Environment=SYSTEMD_LOG_LEVEL=debug

  then restart systemd-resolved and watch the logs scroll by with:

  $ journalctl -fu systemd-resolved

  3) In another terminal, watch the files be recreated with:

  watch -d -n 0.1 stat /run/systemd/resolve/stub-resolv.conf

  3) In yet another terminal, run a packet capture and watch "ICMP6,
  router advertisement" messages come by:

  sudo tcpdump -ni eth0 icmp6

  You will see that every time a RA packet comes in, resolved's journal
  will log this:

    Aug 11 17:33:55 lxd02 systemd-resolved[15368]: Sent message
  type=signal sender=n/a destination=n/a path=/org/freedesktop/resolve1
  interface=org.freedesktop.DBus.Properties member=PropertiesChanged
  cookie=244 reply_cookie=0 signature=sa{sv}as error-name=n/a error-
  message=n/a

  And the stat monitoring terminal will blink to highlight the new inode
  and timestamps of the freshly replaced stub-resolv.conf file.

  # Additional information:

  root@lxd02:~# lsb_release -rd
  Description:  Ubuntu 20.04.1 LTS
  Release:  20.04

  root@lxd02:~# apt-cache policy systemd
  systemd:
    Installed: 245.4-4ubuntu3.2
    Candidate: 245.4-4ubuntu3.2
    Version table:
   *** 245.4-4ubuntu3.2 500
  500 http://archive.ubuntu.com/ubuntu focal-updates/main amd64 Packages
  100 /var/lib/dpkg/status
   245.4-4ubuntu3 500
  500 http://archive.ubuntu.com/ubuntu focal/main amd64 Packages

  root@lxd02:~# uname -a
  Linux lxd01 5.4.0-42-generic #46-Ubuntu SMP Fri Jul 10 00:24:02 

[Touch-packages] [Bug 1928989] Re: expiring trust anchor compatibility issue

[Marc Deslauriers]

I think the patch in comment #1 looks reasonable.

-- 
You received this bug notification because you are a member of Ubuntu
Touch seeded packages, which is subscribed to openssl in Ubuntu.
https://bugs.launchpad.net/bugs/1928989

Title:
  expiring trust anchor compatibility issue

Status in openssl package in Ubuntu:
  Fix Released
Status in openssl source package in Trusty:
  New
Status in openssl source package in Xenial:
  Confirmed

Bug description:
  [Impact]

   * openssl fails to talk to letsencrypt website past September 2021,
  despite trusting the letsencrypt root certificate.

  [Test Plan]

   * Import staging cert equivalent to ISRG Root X1
  https://letsencrypt.org/certs/staging/letsencrypt-stg-root-x1.pem

   * Import expired staging cert equivalen tto DST Root CA X3
  https://letsencrypt.org/certs/staging/letsencrypt-stg-root-dst.pem

   * Test connectivity to the expired-root-ca test website
  https://expired-root-ca-test.germancoding.com

  setup:

  apt install openssl ca-certificates wget
  wget https://letsencrypt.org/certs/staging/letsencrypt-stg-root-x1.pem
  wget https://letsencrypt.org/certs/staging/letsencrypt-stg-root-dst.pem
  cat letsencrypt-stg-root-x1.pem letsencrypt-stg-root-dst.pem >> ca.pem

  test case:
  openssl s_client -connect expired-root-ca-test.germancoding.com:443 
-servername expired-root-ca-test.germancoding.com -verify 1 -verifyCAfile ca.pem

  bad result:
  connection failed
  verify depth is 1
  CONNECTED(0003)
  depth=3 C = US, O = (STAGING) Internet Security Research Group, CN = 
(STAGING) Doctored Durian Root CA X3
  verify error:num=10:certificate has expired
  notAfter=Jan 30 14:01:15 2021 GMT
  140672978626200:error:14090086:SSL 
routines:ssl3_get_server_certificate:certificate verify failed:s3_clnt.c:1264:

  good result:
  connection successful

  verify depth is 1
  CONNECTED(0003)
  depth=2 C = US, O = (STAGING) Internet Security Research Group, CN = 
(STAGING) Pretend Pear X1
  verify return:1
  depth=1 C = US, O = (STAGING) Let's Encrypt, CN = (STAGING) Artificial 
Apricot R3
  verify return:1
  depth=0 CN = expired-root-ca-test.germancoding.com
  verify return:1
  ---
  Certificate chain
   0 s:/CN=expired-root-ca-test.germancoding.com
     i:/C=US/O=(STAGING) Let's Encrypt/CN=(STAGING) Artificial Apricot R3
   1 s:/C=US/O=(STAGING) Let's Encrypt/CN=(STAGING) Artificial Apricot R3
     i:/C=US/O=(STAGING) Internet Security Research Group/CN=(STAGING) Pretend 
Pear X1
   2 s:/C=US/O=(STAGING) Internet Security Research Group/CN=(STAGING) Pretend 
Pear X1
     i:/C=US/O=(STAGING) Internet Security Research Group/CN=(STAGING) Doctored 
Durian Root CA X3
  ---
  Server certificate
  -BEGIN CERTIFICATE-

  Connection should be successful and trusted with correctly working
  openssl s_client that can manage to ignore expired CA, and build a
  valid trust path using non-expired CA in the chain.

  [Where problems could occur]

   * Changes as to how the trust paths are built in TLS connection may
  result in introducing bugs (failure to connect to valid sites) and/or
  security vulnerabilities (connecting to invalid sites successfully).

  [Other Info]

   * Background info
   * The current chain from letsencrypt is expiring, they are adding a new 
chain, but also keeping the expiring one. This will result in connectivity 
issues when using old gnutls/openssl against websites using the default 
letsencrypt configuration after September 2021.

  
https://community.letsencrypt.org/t/openssl-client-compatibility-changes-for-let-s-encrypt-certificates/143816
  
https://community.letsencrypt.org/t/questions-re-openssl-client-compatibility-changes-for-let-s-encrypt-certificates/143817

  Currently openssl in xenial and earlier will not establish a
  connection, if any parts of the trust chain have expired, even though
  alternative non-expired chains are available.

  This has been fixed in OpenSSL 1.1.0+ by setting
  X509_V_FLAG_TRUSTED_FIRST by default see
  
https://github.com/openssl/openssl/commit/0daccd4dc1f1ac62181738a91714f35472e50f3c

  Note only the new default flag is backported on its own. The other
  changes to more strongly verify additional auxiliary trust OIDs and
  key usage are not backported.

  gnutls bug for this is
  https://bugs.launchpad.net/ubuntu/bionic/+source/gnutls28/+bug/1928648

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/openssl/+bug/1928989/+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 1891215] Re: systemd-resolved re-creates /run/systemd/resolve/*resolv.conf for every IPv6 RA received

[Dan Streetman]

> that was the atime

yep, really no way around updating the atime, as systemd of course needs
to access the file to check if the content is the same or not

-- 
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/1891215

Title:
  systemd-resolved re-creates /run/systemd/resolve/*resolv.conf for
  every IPv6 RA received

Status in systemd:
  Unknown
Status in systemd package in Ubuntu:
  Fix Released
Status in systemd source package in Bionic:
  New
Status in systemd source package in Focal:
  Fix Committed
Status in systemd source package in Groovy:
  Fix Committed
Status in systemd source package in Hirsute:
  Fix Committed

Bug description:
  [impact]

  networking changes, like RA events, can cause systemd-resolved to re-
  write the resolv.conf file, even if the contents didn't change,
  resulting in unnecessary increased amount of inotify events

  [test case]

  see original description for ipv6ra-related reproducer, or simple
  reproducer here:

  configure networkd with some config for (e.g.) eth0, but not a config
  that would result in /etc/resolv.conf changing when the interface goes
  up/down - for example, use static config with no DNS search domains.
  Then bring eth0 up/down while observing the md5sum (file content) does
  not change but the mtime does change.

  root@lp1891215-h:~# ip l set down dev eth0
  root@lp1891215-h:~# md5sum /etc/resolv.conf
  db23e80078515192c312e5f321ff0340  /etc/resolv.conf
  root@lp1891215-h:~# stat -t -L /etc/resolv.conf
  /etc/resolv.conf 740 8 81a4 101 103 fc 188 1 0 0 1625238218 1625238216 
1625238216 0 4096
  root@lp1891215-h:~# ip l set up dev eth0
  root@lp1891215-h:~# md5sum /etc/resolv.conf
  db23e80078515192c312e5f321ff0340  /etc/resolv.conf
  root@lp1891215-h:~# stat -t -L /etc/resolv.conf
  /etc/resolv.conf 740 8 81a4 101 103 fc 188 1 0 0 1625238227 1625238226 
1625238226 0 4096

  [regression potential]

  regressions would result in incorrect or missing data in the
  resolv.conf file, possibly resulting in dns failures or errors

  [scope]

  this is needed for h and eralier

  this is (potentially) fixed upstream by
  f3e1f00d03445911ee73729219cea88c8a70c612 which in first included in
  v248, so this is needed in hirsute and earlier

  [original description]

  # Issue description:

  On 2 Linode VMs that are used as lxd hosts, we noticed that
  /run/systemd/resolve/*resolv.conf were re-created quite frequently (~
  once per second). We noticed because of the log noise from lxd's
  dnsmasq instance using inotify to watch the target of /etc/resolv.conf
  (which points to the stub-resolv.conf in our case). This was (wrongly)
  reported as a lxd bug (https://github.com/lxc/lxd/issues/7765) until
  it became apparent it was more likely to be a problem with
  systemd(-resolved)?.

  The log noise is the observable problem that would be nice to see
  addressed:

    root@lxd02:~# uptime
     17:55:48 up  9:52,  1 user,  load average: 0.18, 0.11, 0.05
    root@lxd02:~# journalctl -b0 | grep -cF dnsmasq
    158609

  Upon further investigation, it seems that systemd-resolved re-creates
  the resolv.conf and stub-resolv.conf files whenever an IPv6 RA is
  received.

  1) One can observe that by setting systemd-resolved's service in debug
  mode:

  $ sudo systemctl edit systemd-resolved

  and in the editor that is opened, add and save this content:

  [Service]
  Environment=SYSTEMD_LOG_LEVEL=debug

  then restart systemd-resolved and watch the logs scroll by with:

  $ journalctl -fu systemd-resolved

  3) In another terminal, watch the files be recreated with:

  watch -d -n 0.1 stat /run/systemd/resolve/stub-resolv.conf

  3) In yet another terminal, run a packet capture and watch "ICMP6,
  router advertisement" messages come by:

  sudo tcpdump -ni eth0 icmp6

  You will see that every time a RA packet comes in, resolved's journal
  will log this:

    Aug 11 17:33:55 lxd02 systemd-resolved[15368]: Sent message
  type=signal sender=n/a destination=n/a path=/org/freedesktop/resolve1
  interface=org.freedesktop.DBus.Properties member=PropertiesChanged
  cookie=244 reply_cookie=0 signature=sa{sv}as error-name=n/a error-
  message=n/a

  And the stat monitoring terminal will blink to highlight the new inode
  and timestamps of the freshly replaced stub-resolv.conf file.

  # Additional information:

  root@lxd02:~# lsb_release -rd
  Description:  Ubuntu 20.04.1 LTS
  Release:  20.04

  root@lxd02:~# apt-cache policy systemd
  systemd:
    Installed: 245.4-4ubuntu3.2
    Candidate: 245.4-4ubuntu3.2
    Version table:
   *** 245.4-4ubuntu3.2 500
  500 http://archive.ubuntu.com/ubuntu focal-updates/main amd64 Packages
  100 /var/lib/dpkg/status
   245.4-4ubuntu3 500
  500 http://archive.ubuntu.com/ubuntu focal/main amd64 Packages

  root@lxd02:~# uname -a
  Linux lxd01 5.4.0-42-generic #46-Ubuntu SMP Fri Jul 10 

[Touch-packages] [Bug 1934286] Re: Update the ModemManager to 1.16.6-2 to support some modems in Focal and Hirsute releases.

[Brian Murray]

A user still might have written a script or a service which calls
/usr/lib/libmbim/mbim-proxy and by moving the binary we would end up
introducing a regression and that's a scenario we should consider.

-- 
You received this bug notification because you are a member of Ubuntu
Touch seeded packages, which is subscribed to modemmanager in Ubuntu.
https://bugs.launchpad.net/bugs/1934286

Title:
  Update the ModemManager to 1.16.6-2 to support some modems in Focal
  and Hirsute releases.

Status in OEM Priority Project:
  Confirmed
Status in libmbim package in Ubuntu:
  New
Status in libqmi package in Ubuntu:
  New
Status in modemmanager package in Ubuntu:
  New
Status in modemmanager source package in Focal:
  Fix Committed
Status in libmbim source package in Hirsute:
  Fix Committed
Status in libqmi source package in Hirsute:
  Fix Committed
Status in modemmanager source package in Hirsute:
  Fix Committed

Bug description:
  [Impact]

  Some IOT products use wireless modems which can be working only when
  recent versions of the ModemManager suite are used.

  The following 2 modems need the ModemManager suite to be upgraded:
  * Foxconn SDX55 T99W175 5G sub6 PCIE Modem
  * Quectel SDX24 EM160R-GL 4G LTE CAT16 PCIE Modem

  The main fix requested is to add the FCC unlock mechanism for Foxconn modems.
  * FCC unlock operation for Foxconn modems
  
https://gitlab.freedesktop.org/mobile-broadband/ModemManager/-/merge_requests/534/commits
  * dms: new 'Foxconn Set FCC authentication' command
  
https://gitlab.freedesktop.org/mobile-broadband/libqmi/-/merge_requests/254/commits

  The minimum versions of the ModemManager suite required to enable the support 
for the above 2 mentioned modems have been verified: (LP: #1928665)
  * ModemManager: 1.16.6
  * libmbim: 1.24.8
  * libqmi : 1.28.6

  The ModemManager suite in the Impish release meets the requirements.

  [Test Plan]

  = How to Reproduce the Bug =

  Execute the following commands to list the modems detected by
  ModemManager in Hirsute and Focal releases:

  $ mmcli --list-modems
  No modems were found

  = Test Procedure =

  1. Install the Ubuntu system on the tested hardware

    The following images will be used to verify the version of the ModemManager 
suite:
    * Impish: 
https://cdimage.ubuntu.com/daily-live/current/impish-desktop-amd64.iso
    * Hirsute: https://releases.ubuntu.com/21.04/ubuntu-21.04-desktop-amd64.iso
    * Focal: 
https://releases.ubuntu.com/focal/ubuntu-20.04.2.0-desktop-amd64.iso

  2. Upgrade the kernel and driver  ( for Foxconn and Quectel modem )

    The kernel needs to get some patches from 5.13 and includes a back ported 
Quectel driver to support these 2 modems.
    We have prepared a kernel packages for testing: 
https://people.canonical.com/~mschiu77/lp1928665/v2/

  3. Install the ModemManager suite ( for Hirsute and Focal releases )

    The ModemManager suite will be installed from the -proposed
  component:

  $ sudo apt update
  $ sudo apt install modemmanager
  $ sudo apt install libqmi-utils

  4. Execute the following commands

  4.1 Get the run-time environment

  $ uname -ar
  $ lsb_release -a
  $ mmcli -V
  $ qmicli -V

  4.2 Check the status of the ModemManager service

  $ sudo systemctl status ModemManager.service

  4.3 List the detected modems

  $ mmcli --list-modems

  4.4 Check the modem’s status

  $ mmcli --modem 0

  4.5 Install and execute Lenovo’s FCC unlock app ( for Quectel modem
  only )

  $ sudo snap install --devmode --dangerous dpr-wwan_1.0-wwan-
  test_amd64.snap

  4.6 Enable the detected modem

  $ sudo mmcli --modem 0 --enable

  4.7 Check the modem’s status

  $ mmcli --modem 0

  = Analyze the Tested Result =

  1. Check if installed packages are working

    The result of test procedure 4.1 and 4.2 can be used to make sure the 
installed packages are working.
    If the Modemmanager.service is active(running), the packages are working.

  2. Check if the supported modem can be detected

    The result of test procedure 4.3 can be used to see if the modem can be 
detected by ModemManager or not.
    The supported modems should be listed.

  3. Check if the modem can be enabled

    If the modem can be enabled, the state of the modem in the test
  procedure 4.7 will be set to be registered.

  = Certification Validation =

  Additionally to the aforementioned test cases, the Certification Team
  will perform some coverage testing across supported devices to make
  sure the other modems still work as expected.

  [Where problems could occur]

  There is a risk that modems supported in the old versions of
  ModemManager suite may not be supported in the newer versions.

  [Other Info]

  We need to upgrade to these 3 packages (in Impish) at the same time:
  * ModemManager: 1.16.6
  * libmbim: 1.24.8
  * libqmi : 1.28.6

  To support the mentioned 2 modems, the system needs to use kernels which 
include specific patches and  kernel config options .
  For ex., there is a patched 

[Touch-packages] [Bug 1934783] Re: Graphical glitches with Mesa 21.0.3 on AMD Radeon RX 5600 XT

[Mateusz Stachowski]

I've found that other people with RX 5600 XT had problems with this
version of mesa.

https://bugs.archlinux.org/task/70554

https://gitlab.freedesktop.org/mesa/mesa/-/issues/4691

There is a new release of mesa (21.0.3-2) that fixes the problem for
those users.

Hope that you upload it to focal-proposed.

** Bug watch added: gitlab.freedesktop.org/mesa/mesa/-/issues #4691
   https://gitlab.freedesktop.org/mesa/mesa/-/issues/4691

-- 
You received this bug notification because you are a member of Ubuntu
Touch seeded packages, which is subscribed to mesa in Ubuntu.
https://bugs.launchpad.net/bugs/1934783

Title:
  Graphical glitches with Mesa 21.0.3 on AMD Radeon RX 5600 XT

Status in mesa package in Ubuntu:
  New
Status in mesa source package in Focal:
  New

Bug description:
  Since the update to Mesa 21.0.3 I have graphical glitches in desktop:
  Unity, Gnome Shell both sessions (X.org and Wayland).

  Also most of the programs have glitches. However Firefox seems
  unaffected.

  CPU:
Info: 6-Core AMD Ryzen 5 3600 [MT MCP] speed: 3916 MHz
min/max: 2200/3600 MHz
  Graphics:
Device-1: AMD Navi 10 [Radeon RX 5600 OEM/5600 XT / 5700/5700 XT]
driver: amdgpu v: kernel
Display: x11 server: X.Org 1.20.11 driver: loaded: amdgpu,ati
unloaded: fbdev,modesetting,radeon,vesa resolution: 1920x1080~60Hz
OpenGL: renderer: AMD Radeon RX 5600 XT (NAVI10 DRM 3.35.0
5.4.0-79-generic LLVM 12.0.0)
v: 4.6 Mesa 21.0.3

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/mesa/+bug/1934783/+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 1928989] Re: expiring trust anchor compatibility issue

[Dimitri John Ledkov]

PPA with these changes available from https://launchpad.net/~ci-train-
ppa-service/+archive/ubuntu/4594

-- 
You received this bug notification because you are a member of Ubuntu
Touch seeded packages, which is subscribed to openssl in Ubuntu.
https://bugs.launchpad.net/bugs/1928989

Title:
  expiring trust anchor compatibility issue

Status in openssl package in Ubuntu:
  Fix Released
Status in openssl source package in Trusty:
  New
Status in openssl source package in Xenial:
  Confirmed

Bug description:
  [Impact]

   * openssl fails to talk to letsencrypt website past September 2021,
  despite trusting the letsencrypt root certificate.

  [Test Plan]

   * Import staging cert equivalent to ISRG Root X1
  https://letsencrypt.org/certs/staging/letsencrypt-stg-root-x1.pem

   * Import expired staging cert equivalen tto DST Root CA X3
  https://letsencrypt.org/certs/staging/letsencrypt-stg-root-dst.pem

   * Test connectivity to the expired-root-ca test website
  https://expired-root-ca-test.germancoding.com

  setup:

  apt install openssl ca-certificates wget
  wget https://letsencrypt.org/certs/staging/letsencrypt-stg-root-x1.pem
  wget https://letsencrypt.org/certs/staging/letsencrypt-stg-root-dst.pem
  cat letsencrypt-stg-root-x1.pem letsencrypt-stg-root-dst.pem >> ca.pem

  test case:
  openssl s_client -connect expired-root-ca-test.germancoding.com:443 
-servername expired-root-ca-test.germancoding.com -verify 1 -verifyCAfile ca.pem

  bad result:
  connection failed
  verify depth is 1
  CONNECTED(0003)
  depth=3 C = US, O = (STAGING) Internet Security Research Group, CN = 
(STAGING) Doctored Durian Root CA X3
  verify error:num=10:certificate has expired
  notAfter=Jan 30 14:01:15 2021 GMT
  140672978626200:error:14090086:SSL 
routines:ssl3_get_server_certificate:certificate verify failed:s3_clnt.c:1264:

  good result:
  connection successful

  verify depth is 1
  CONNECTED(0003)
  depth=2 C = US, O = (STAGING) Internet Security Research Group, CN = 
(STAGING) Pretend Pear X1
  verify return:1
  depth=1 C = US, O = (STAGING) Let's Encrypt, CN = (STAGING) Artificial 
Apricot R3
  verify return:1
  depth=0 CN = expired-root-ca-test.germancoding.com
  verify return:1
  ---
  Certificate chain
   0 s:/CN=expired-root-ca-test.germancoding.com
     i:/C=US/O=(STAGING) Let's Encrypt/CN=(STAGING) Artificial Apricot R3
   1 s:/C=US/O=(STAGING) Let's Encrypt/CN=(STAGING) Artificial Apricot R3
     i:/C=US/O=(STAGING) Internet Security Research Group/CN=(STAGING) Pretend 
Pear X1
   2 s:/C=US/O=(STAGING) Internet Security Research Group/CN=(STAGING) Pretend 
Pear X1
     i:/C=US/O=(STAGING) Internet Security Research Group/CN=(STAGING) Doctored 
Durian Root CA X3
  ---
  Server certificate
  -BEGIN CERTIFICATE-

  Connection should be successful and trusted with correctly working
  openssl s_client that can manage to ignore expired CA, and build a
  valid trust path using non-expired CA in the chain.

  [Where problems could occur]

   * Changes as to how the trust paths are built in TLS connection may
  result in introducing bugs (failure to connect to valid sites) and/or
  security vulnerabilities (connecting to invalid sites successfully).

  [Other Info]

   * Background info
   * The current chain from letsencrypt is expiring, they are adding a new 
chain, but also keeping the expiring one. This will result in connectivity 
issues when using old gnutls/openssl against websites using the default 
letsencrypt configuration after September 2021.

  
https://community.letsencrypt.org/t/openssl-client-compatibility-changes-for-let-s-encrypt-certificates/143816
  
https://community.letsencrypt.org/t/questions-re-openssl-client-compatibility-changes-for-let-s-encrypt-certificates/143817

  Currently openssl in xenial and earlier will not establish a
  connection, if any parts of the trust chain have expired, even though
  alternative non-expired chains are available.

  This has been fixed in OpenSSL 1.1.0+ by setting
  X509_V_FLAG_TRUSTED_FIRST by default see
  
https://github.com/openssl/openssl/commit/0daccd4dc1f1ac62181738a91714f35472e50f3c

  Note only the new default flag is backported on its own. The other
  changes to more strongly verify additional auxiliary trust OIDs and
  key usage are not backported.

  gnutls bug for this is
  https://bugs.launchpad.net/ubuntu/bionic/+source/gnutls28/+bug/1928648

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/openssl/+bug/1928989/+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 1928989] Re: expiring trust anchor compatibility issue

[Dimitri John Ledkov]

ADT results at https://bileto.ubuntu.com/excuses/4594/xenial.html

** Description changed:

  [Impact]
  
   * openssl fails to talk to letsencrypt website past September 2021,
  despite trusting the letsencrypt root certificate.
  
  [Test Plan]
  
   * Import staging cert equivalent to ISRG Root X1
  https://letsencrypt.org/certs/staging/letsencrypt-stg-root-x1.pem
  
   * Import expired staging cert equivalen tto DST Root CA X3
  https://letsencrypt.org/certs/staging/letsencrypt-stg-root-dst.pem
  
   * Test connectivity to the expired-root-ca test website
  https://expired-root-ca-test.germancoding.com
  
  setup:
  
  apt install openssl ca-certificates wget
  wget https://letsencrypt.org/certs/staging/letsencrypt-stg-root-x1.pem
  wget https://letsencrypt.org/certs/staging/letsencrypt-stg-root-dst.pem
  cat letsencrypt-stg-root-x1.pem letsencrypt-stg-root-dst.pem >> ca.pem
  
  test case:
  openssl s_client -connect expired-root-ca-test.germancoding.com:443 
-servername expired-root-ca-test.germancoding.com -verify 1 -verifyCAfile ca.pem
  
  bad result:
  connection failed
  verify depth is 1
  CONNECTED(0003)
  depth=3 C = US, O = (STAGING) Internet Security Research Group, CN = 
(STAGING) Doctored Durian Root CA X3
  verify error:num=10:certificate has expired
  notAfter=Jan 30 14:01:15 2021 GMT
  140672978626200:error:14090086:SSL 
routines:ssl3_get_server_certificate:certificate verify failed:s3_clnt.c:1264:
  
  good result:
  connection successful
  
  verify depth is 1
  CONNECTED(0003)
  depth=2 C = US, O = (STAGING) Internet Security Research Group, CN = 
(STAGING) Pretend Pear X1
  verify return:1
  depth=1 C = US, O = (STAGING) Let's Encrypt, CN = (STAGING) Artificial 
Apricot R3
  verify return:1
  depth=0 CN = expired-root-ca-test.germancoding.com
  verify return:1
  ---
  Certificate chain
   0 s:/CN=expired-root-ca-test.germancoding.com
     i:/C=US/O=(STAGING) Let's Encrypt/CN=(STAGING) Artificial Apricot R3
   1 s:/C=US/O=(STAGING) Let's Encrypt/CN=(STAGING) Artificial Apricot R3
     i:/C=US/O=(STAGING) Internet Security Research Group/CN=(STAGING) Pretend 
Pear X1
   2 s:/C=US/O=(STAGING) Internet Security Research Group/CN=(STAGING) Pretend 
Pear X1
     i:/C=US/O=(STAGING) Internet Security Research Group/CN=(STAGING) Doctored 
Durian Root CA X3
  ---
  Server certificate
  -BEGIN CERTIFICATE-
  
  Connection should be successful and trusted with correctly working
  openssl s_client that can manage to ignore expired CA, and build a valid
  trust path using non-expired CA in the chain.
  
  [Where problems could occur]
  
   * Changes as to how the trust paths are built in TLS connection may
  result in introducing bugs (failure to connect to valid sites) and/or
  security vulnerabilities (connecting to invalid sites successfully).
  
  [Other Info]
  
   * Background info
   * The current chain from letsencrypt is expiring, they are adding a new 
chain, but also keeping the expiring one. This will result in connectivity 
issues when using old gnutls/openssl against websites using the default 
letsencrypt configuration after September 2021.
  
  
https://community.letsencrypt.org/t/openssl-client-compatibility-changes-for-let-s-encrypt-certificates/143816
  
https://community.letsencrypt.org/t/questions-re-openssl-client-compatibility-changes-for-let-s-encrypt-certificates/143817
  
  Currently openssl in xenial and earlier will not establish a connection,
  if any parts of the trust chain have expired, even though alternative
  non-expired chains are available.
  
  This has been fixed in OpenSSL 1.1.0+ by setting
  X509_V_FLAG_TRUSTED_FIRST by default see
  
https://github.com/openssl/openssl/commit/0daccd4dc1f1ac62181738a91714f35472e50f3c
  
+ Note only the new default flag is backported on its own. The other
+ changes to more strongly verify additional auxiliary trust OIDs and key
+ usage are not backported.
+ 
  gnutls bug for this is
  https://bugs.launchpad.net/ubuntu/bionic/+source/gnutls28/+bug/1928648

-- 
You received this bug notification because you are a member of Ubuntu
Touch seeded packages, which is subscribed to openssl in Ubuntu.
https://bugs.launchpad.net/bugs/1928989

Title:
  expiring trust anchor compatibility issue

Status in openssl package in Ubuntu:
  Fix Released
Status in openssl source package in Trusty:
  New
Status in openssl source package in Xenial:
  Confirmed

Bug description:
  [Impact]

   * openssl fails to talk to letsencrypt website past September 2021,
  despite trusting the letsencrypt root certificate.

  [Test Plan]

   * Import staging cert equivalent to ISRG Root X1
  https://letsencrypt.org/certs/staging/letsencrypt-stg-root-x1.pem

   * Import expired staging cert equivalen tto DST Root CA X3
  https://letsencrypt.org/certs/staging/letsencrypt-stg-root-dst.pem

   * Test connectivity to the expired-root-ca test website
  https://expired-root-ca-test.germancoding.com

  setup:

  apt install openssl ca-certificates 

[Touch-packages] [Bug 1928989] Re: expiring trust anchor compatibility issue

[Dimitri John Ledkov]

python3.5 has stopped passing its testsuite due to expried test certs.
Thus upload of openssl has triggered regression in python3.5

I've cherrypicked updated test certs and keys, but to cherry-pick those
cleanly, I also had to cherrypick an earlier bug fix. All of these are
unmodified from 3.5.10 release. With these patches in place python3.5
testsuite passes with both current and proposed update of openssl.

** Patch added: "xenial_python3.5_content.diff"
   
https://bugs.launchpad.net/ubuntu/+source/openssl/+bug/1928989/+attachment/5510069/+files/xenial_python3.5_content.diff

** Changed in: openssl (Ubuntu Xenial)
   Status: New => Confirmed

-- 
You received this bug notification because you are a member of Ubuntu
Touch seeded packages, which is subscribed to openssl in Ubuntu.
https://bugs.launchpad.net/bugs/1928989

Title:
  expiring trust anchor compatibility issue

Status in openssl package in Ubuntu:
  Fix Released
Status in openssl source package in Trusty:
  New
Status in openssl source package in Xenial:
  Confirmed

Bug description:
  [Impact]

   * openssl fails to talk to letsencrypt website past September 2021,
  despite trusting the letsencrypt root certificate.

  [Test Plan]

   * Import staging cert equivalent to ISRG Root X1
  https://letsencrypt.org/certs/staging/letsencrypt-stg-root-x1.pem

   * Import expired staging cert equivalen tto DST Root CA X3
  https://letsencrypt.org/certs/staging/letsencrypt-stg-root-dst.pem

   * Test connectivity to the expired-root-ca test website
  https://expired-root-ca-test.germancoding.com

  setup:

  apt install openssl ca-certificates wget
  wget https://letsencrypt.org/certs/staging/letsencrypt-stg-root-x1.pem
  wget https://letsencrypt.org/certs/staging/letsencrypt-stg-root-dst.pem
  cat letsencrypt-stg-root-x1.pem letsencrypt-stg-root-dst.pem >> ca.pem

  test case:
  openssl s_client -connect expired-root-ca-test.germancoding.com:443 
-servername expired-root-ca-test.germancoding.com -verify 1 -verifyCAfile ca.pem

  bad result:
  connection failed
  verify depth is 1
  CONNECTED(0003)
  depth=3 C = US, O = (STAGING) Internet Security Research Group, CN = 
(STAGING) Doctored Durian Root CA X3
  verify error:num=10:certificate has expired
  notAfter=Jan 30 14:01:15 2021 GMT
  140672978626200:error:14090086:SSL 
routines:ssl3_get_server_certificate:certificate verify failed:s3_clnt.c:1264:

  good result:
  connection successful

  verify depth is 1
  CONNECTED(0003)
  depth=2 C = US, O = (STAGING) Internet Security Research Group, CN = 
(STAGING) Pretend Pear X1
  verify return:1
  depth=1 C = US, O = (STAGING) Let's Encrypt, CN = (STAGING) Artificial 
Apricot R3
  verify return:1
  depth=0 CN = expired-root-ca-test.germancoding.com
  verify return:1
  ---
  Certificate chain
   0 s:/CN=expired-root-ca-test.germancoding.com
     i:/C=US/O=(STAGING) Let's Encrypt/CN=(STAGING) Artificial Apricot R3
   1 s:/C=US/O=(STAGING) Let's Encrypt/CN=(STAGING) Artificial Apricot R3
     i:/C=US/O=(STAGING) Internet Security Research Group/CN=(STAGING) Pretend 
Pear X1
   2 s:/C=US/O=(STAGING) Internet Security Research Group/CN=(STAGING) Pretend 
Pear X1
     i:/C=US/O=(STAGING) Internet Security Research Group/CN=(STAGING) Doctored 
Durian Root CA X3
  ---
  Server certificate
  -BEGIN CERTIFICATE-

  Connection should be successful and trusted with correctly working
  openssl s_client that can manage to ignore expired CA, and build a
  valid trust path using non-expired CA in the chain.

  [Where problems could occur]

   * Changes as to how the trust paths are built in TLS connection may
  result in introducing bugs (failure to connect to valid sites) and/or
  security vulnerabilities (connecting to invalid sites successfully).

  [Other Info]

   * Background info
   * The current chain from letsencrypt is expiring, they are adding a new 
chain, but also keeping the expiring one. This will result in connectivity 
issues when using old gnutls/openssl against websites using the default 
letsencrypt configuration after September 2021.

  
https://community.letsencrypt.org/t/openssl-client-compatibility-changes-for-let-s-encrypt-certificates/143816
  
https://community.letsencrypt.org/t/questions-re-openssl-client-compatibility-changes-for-let-s-encrypt-certificates/143817

  Currently openssl in xenial and earlier will not establish a
  connection, if any parts of the trust chain have expired, even though
  alternative non-expired chains are available.

  This has been fixed in OpenSSL 1.1.0+ by setting
  X509_V_FLAG_TRUSTED_FIRST by default see
  
https://github.com/openssl/openssl/commit/0daccd4dc1f1ac62181738a91714f35472e50f3c

  Note only the new default flag is backported on its own. The other
  changes to more strongly verify additional auxiliary trust OIDs and
  key usage are not backported.

  gnutls bug for this is
  https://bugs.launchpad.net/ubuntu/bionic/+source/gnutls28/+bug/1928648

To manage notifications about this 

[Touch-packages] [Bug 1891215] Re: systemd-resolved re-creates /run/systemd/resolve/*resolv.conf for every IPv6 RA received

[Simon Déziel]

Verification for Groovy (246.6-1ubuntu1.5)


# Initial repro on groovy:

root@groovy:~# md5sum /etc/resolv.conf; stat -t -L /etc/resolv.conf 
6b21d96b644bdafc7a3094fe04ab4e88  /etc/resolv.conf
/etc/resolv.conf 729 8 81a4 102 104 8f 111 1 0 0 1625844827 1625844823 
1625844823 0 4096
root@groovy:~# ip link set eth0 down; sleep 1; ip link set eth0 up
root@groovy:~# md5sum /etc/resolv.conf; stat -t -L /etc/resolv.conf 
6b21d96b644bdafc7a3094fe04ab4e88  /etc/resolv.conf
/etc/resolv.conf 729 8 81a4 102 104 8f 111 1 0 0 1625844838 1625844837 
1625844837 0 4096

# Upgrading to -proposed

root@groovy:~# apt update && apt-get dist-upgrade -V
Get:1 http://security.ubuntu.com/ubuntu groovy-security InRelease [110 kB]
Hit:2 http://archive.ubuntu.com/ubuntu groovy InRelease 
Get:3 http://archive.ubuntu.com/ubuntu groovy-updates InRelease [115 kB]
Get:4 http://archive.ubuntu.com/ubuntu groovy-proposed InRelease [269 kB]
Get:5 http://archive.ubuntu.com/ubuntu groovy-updates/universe amd64 Packages 
[450 kB]
Get:6 http://archive.ubuntu.com/ubuntu groovy-proposed/restricted amd64 
Packages [100 kB]
Get:7 http://archive.ubuntu.com/ubuntu groovy-proposed/restricted 
Translation-en [14.7 kB]
Get:8 http://archive.ubuntu.com/ubuntu groovy-proposed/main amd64 Packages 
[83.6 kB]
Get:9 http://archive.ubuntu.com/ubuntu groovy-proposed/main Translation-en 
[22.3 kB]
Get:10 http://archive.ubuntu.com/ubuntu groovy-proposed/multiverse amd64 
Packages [11.6 kB]
Get:11 http://archive.ubuntu.com/ubuntu groovy-proposed/multiverse 
Translation-en [5,932 B]
Get:12 http://archive.ubuntu.com/ubuntu groovy-proposed/universe amd64 Packages 
[24.9 kB]
Get:13 http://archive.ubuntu.com/ubuntu groovy-proposed/universe Translation-en 
[12.8 kB]
Fetched 1,220 kB in 1s (840 kB/s) 
Reading package lists... Done
Building dependency tree   
Reading state information... Done
12 packages can be upgraded. Run 'apt list --upgradable' to see them.
Reading package lists... Done
Building dependency tree   
Reading state information... Done
Calculating upgrade... Done
The following packages will be upgraded:
   libc-bin (2.32-0ubuntu3 => 2.32-0ubuntu3.2)
   libc6 (2.32-0ubuntu3 => 2.32-0ubuntu3.2)
   libgnutls30 (3.6.15-4ubuntu2 => 3.6.15-4ubuntu2.1)
   libnss-systemd (246.6-1ubuntu1.4 => 246.6-1ubuntu1.5)
   libpam-systemd (246.6-1ubuntu1.4 => 246.6-1ubuntu1.5)
   libsystemd0 (246.6-1ubuntu1.4 => 246.6-1ubuntu1.5)
   libudev1 (246.6-1ubuntu1.4 => 246.6-1ubuntu1.5)
   locales (2.32-0ubuntu3 => 2.32-0ubuntu3.2)
   systemd (246.6-1ubuntu1.4 => 246.6-1ubuntu1.5)
   systemd-sysv (246.6-1ubuntu1.4 => 246.6-1ubuntu1.5)
   systemd-timesyncd (246.6-1ubuntu1.4 => 246.6-1ubuntu1.5)
   udev (246.6-1ubuntu1.4 => 246.6-1ubuntu1.5)
12 upgraded, 0 newly installed, 0 to remove and 0 not upgraded.
Need to get 14.1 MB of archives.
After this operation, 3,072 B of additional disk space will be used.
Do you want to continue? [Y/n] 
Get:1 http://archive.ubuntu.com/ubuntu groovy-proposed/main amd64 libc6 amd64 
2.32-0ubuntu3.2 [2,680 kB]
Get:2 http://archive.ubuntu.com/ubuntu groovy-proposed/main amd64 libc-bin 
amd64 2.32-0ubuntu3.2 [628 kB]
Get:3 http://archive.ubuntu.com/ubuntu groovy-proposed/main amd64 
libnss-systemd amd64 246.6-1ubuntu1.5 [94.6 kB]
Get:4 http://archive.ubuntu.com/ubuntu groovy-proposed/main amd64 udev amd64 
246.6-1ubuntu1.5 [1,340 kB]
Get:5 http://archive.ubuntu.com/ubuntu groovy-proposed/main amd64 libudev1 
amd64 246.6-1ubuntu1.5 [69.2 kB]
Get:6 http://archive.ubuntu.com/ubuntu groovy-proposed/main amd64 systemd-sysv 
amd64 246.6-1ubuntu1.5 [10.3 kB]
Get:7 http://archive.ubuntu.com/ubuntu groovy-proposed/main amd64 
systemd-timesyncd amd64 246.6-1ubuntu1.5 [28.2 kB]
Get:8 http://archive.ubuntu.com/ubuntu groovy-proposed/main amd64 
libpam-systemd amd64 246.6-1ubuntu1.5 [179 kB]
Get:9 http://archive.ubuntu.com/ubuntu groovy-proposed/main amd64 libgnutls30 
amd64 3.6.15-4ubuntu2.1 [770 kB]
Get:10 http://archive.ubuntu.com/ubuntu groovy-proposed/main amd64 systemd 
amd64 246.6-1ubuntu1.5 [4,166 kB]
Get:11 http://archive.ubuntu.com/ubuntu groovy-proposed/main amd64 libsystemd0 
amd64 246.6-1ubuntu1.5 [274 kB]
Get:12 http://archive.ubuntu.com/ubuntu groovy-proposed/main amd64 locales all 
2.32-0ubuntu3.2 [3,879 kB]
Fetched 14.1 MB in 4s (3,313 kB/s)
Preconfiguring packages ...
(Reading database ... 14742 files and directories currently installed.)
Preparing to unpack .../libc6_2.32-0ubuntu3.2_amd64.deb ...
Unpacking libc6:amd64 (2.32-0ubuntu3.2) over (2.32-0ubuntu3) ...
Setting up libc6:amd64 (2.32-0ubuntu3.2) ...
(Reading database ... 14742 files and directories currently installed.)
Preparing to unpack .../libc-bin_2.32-0ubuntu3.2_amd64.deb ...
Unpacking libc-bin (2.32-0ubuntu3.2) over (2.32-0ubuntu3) ...
Setting up libc-bin (2.32-0ubuntu3.2) ...
(Reading database ... 14742 files and directories currently installed.)
Preparing to unpack .../libnss-systemd_246.6-1ubuntu1.5_amd64.deb ...
Unpacking libnss-systemd:amd64 

[Touch-packages] [Bug 1934992] Re: rsync 3.2.x in Groovy depends on broken libxxhash 0.7.x

[Robie Basak]

Sorry, the use cases you describe are not supported by Ubuntu.

You're welcome to hack your system as you wish, but that doesn't mean
that we will necessarily make changes in Ubuntu to accommodate that. We
do try to be helpful, of course. And in this case I agree that it is a
bug that rsync doesn't depend on a higher version of libxxhash
automatically. That's something we should fix, but it is of low priority
but I don't expect such a fix to be backported to Groovy because, as
presented at the moment, this doesn't meet our threshold of disrupting
users to achieve such a change. See
https://wiki.ubuntu.com/StableReleaseUpdates for details of our policies
in this area.

In particular:

> - I make a hypothetical package that depends on libxxhash < 0.8
because I want the "broken/old" xxh128 support

Such a hypothetical package does not exist in the Ubuntu archive in
practice. Adding third party packages is not something that Ubuntu can
realistically support. The scenario you present is exactly why we don't
support third party packages in the general case: they break
distribution release upgrades.

> - libxxhash-dev,
> + libxxhash-dev (>= 0.8),

I don't think your patch will work as-is. You've changed the build
dependency versioning, not the binary package dependency versioning. I
suspect what needs adjusting is the symbols file in the xxhash source
(debian/libxxhash0.symbols). However this needs further investigation
and the low priority of this issue means that I'm not going to spend any
more time on this unless a more important and supported use case is
presented here.

> (Ok, in fact, I think it's ultimately a bug in soname-version/symbol
handling of libxxhash. But that's not where the problem manifests
itself.)

Right. We track bugs and their fixes by following the status of a fix
against the root cause. So I'm going to reassign the bug to that package
as it seems likely to me that this is where the problem lies.

> I'll leave it as is if you still feel it should be closed.

I agree that it's not correct that the binary dependency is wrong, so
this bug can remain open if somebody wants to volunteer a fix. However,
I suggest you find the fix and send it to wherever the problem
originates in our ecosystem (maybe Debian? Or perhaps xxhash upstream?).
Unless a supported use case is presented, I think it's unlikely that
we'll carry a patch for this in Ubuntu.

> But at least it has some visibility/presence on the internet so others
are helped if they also run into this issue.

Sure. People affected by this are welcome to coordinate in this bug.

I'm going to explicitly mark a Groovy task as Won't Fix to make it clear
that we don't expect any change will be made in Groovy to fix this. The
bug remains open to being fixed in a future Ubuntu release if a
volunteer takes the appropriate steps to get the issue resolved at its
actual origin.

** Package changed: rsync (Ubuntu) => xxhash (Ubuntu)

** Also affects: xxhash (Ubuntu Groovy)
   Importance: Undecided
   Status: New

** Changed in: xxhash (Ubuntu Groovy)
   Status: New => Won't Fix

** Changed in: xxhash (Ubuntu)
   Status: New => Triaged

** Changed in: xxhash (Ubuntu)
   Importance: Undecided => Low

-- 
You received this bug notification because you are a member of Ubuntu
Touch seeded packages, which is subscribed to rsync in Ubuntu.
https://bugs.launchpad.net/bugs/1934992

Title:
  rsync 3.2.x in Groovy depends on broken libxxhash 0.7.x

Status in xxhash package in Ubuntu:
  Triaged
Status in xxhash source package in Groovy:
  Won't Fix

Bug description:
  **Problem**

$ rsync root@focal-system:/etc/.pwd.lock . 
ERROR: .pwd.lock failed verification -- update discarded.
rsync error: some files/attrs were not transferred (see previous errors)
  (code 23) at main.c(1816) [generator=3.2.3]

  
$ rsync root@focal-system:/etc/.pwd.lock . --debug=all
opening connection using: ssh -l root focal-system rsync --server --sender \
  -e.LsfxCIvu . /etc/.pwd.lock  (10 args)
(Client) Protocol versions: remote=31, negotiated=31
Client negotiated checksum: xxh128
...

  
  **Cause**

focal-system# dpkg -l | grep -E 'libxxhash|rsync'
ii  libxxhash0:amd64  0.7.3-1 amd64
ii  rsync 3.2.3-2ubuntu1  amd64

  
  **Why this affects only us and not more people?**

  On Ubuntu/Focal, there is no rsync 3.2.3, only 3.1.3-8. But because we
  need the lz4 compression support we've fetched a newer rsync (from
  Groovy).

  However: the rsync 3.2.3 depends on libxxhash0 0.7.1+, while in fact
  it needs 0.8+.

  
  **Details**

  On a Ubuntu/Focal system we have installed a rsync 3.2.3 package from 
Ubuntu/Groovy because we need the lz4 compression support.

  
  focal-system# apt-cache show rsync
  Package: rsync
  ...
  Version: 3.2.3-2ubuntu1
  Depends: lsb-base, libacl1 (>= 2.2.23), libc6 (>= 2.15),
liblz4-1 (>= 0.0~r130), libpopt0 (>= 1.14), libssl1.1 (>= 1.1.0),
libxxhash0 (>= 0.7.1), 

[Touch-packages] [Bug 1858210] Autopkgtest regression report (systemd/246.6-1ubuntu1.5)

[Ubuntu SRU Bot]

All autopkgtests for the newly accepted systemd (246.6-1ubuntu1.5) for groovy 
have finished running.
The following regressions have been reported in tests triggered by the package:

prometheus/2.20.0+ds-1 (amd64)


Please visit the excuses page listed below and investigate the failures, 
proceeding afterwards as per the StableReleaseUpdates policy regarding 
autopkgtest regressions [1].

https://people.canonical.com/~ubuntu-archive/proposed-
migration/groovy/update_excuses.html#systemd

[1] https://wiki.ubuntu.com/StableReleaseUpdates#Autopkgtest_Regressions

Thank you!

-- 
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/1858210

Title:
  timedatectl doesn't list all timezones

Status in systemd package in Ubuntu:
  Fix Released
Status in systemd source package in Bionic:
  Won't Fix
Status in systemd source package in Focal:
  Fix Committed
Status in systemd source package in Groovy:
  Fix Committed
Status in systemd source package in Hirsute:
  Fix Committed
Status in systemd source package in Impish:
  Fix Released

Bug description:
  [impact]

  timedatectl list-timezones doesn't show many common timezones that are
  actually considered 'aliases', such as Europe/Bratislava or
  US/Eastern.

  [test case]

  $ timedatectl list-timezones | grep Eastern
  $

  [regression potential]

  any regression would likely result in an incorrect list of timezones
  shown from list-timezones, or failure to correctly set a timezone

  [scope]

  this is needed in f and later

  this is fixed upstream with PR 20066 which was just merged, so this is
  needed in all releases in ubuntu

  in bionic, the 'tzdata.zi' file that the new code uses isn't present,
  so this won't work on bionic, thus marking it wontfix

  [original description]

  Is there some filter determining which timezones are displayed by
  `timedatectl list-timezones`? My zone, Europe/Bratislava, is missing.
  Even stranger, it can successfully be set by timedatectl.

  ProblemType: Bug
  DistroRelease: Ubuntu 19.10
  Package: systemd 242-7ubuntu3.2
  ProcVersionSignature: Ubuntu 5.3.0-1014.16-raspi2 5.3.10
  Uname: Linux 5.3.0-1014-raspi2 aarch64
  ApportVersion: 2.20.11-0ubuntu8.2
  Architecture: arm64
  Date: Fri Jan  3 15:36:03 2020
  Lspci:

  ProcEnviron:
   TERM=xterm-256color
   PATH=(custom, no user)
   LANG=C.UTF-8
   SHELL=/bin/bash
  ProcKernelCmdLine: coherent_pool=1M 8250.nr_uarts=1 bcm2708_fb.fbwidth=1824 
bcm2708_fb.fbheight=984 bcm2708_fb.fbswap=1 vc_mem.mem_base=0x3ec0 
vc_mem.mem_size=0x4000  net.ifnames=0 dwc_otg.lpm_enable=0 
console=ttyS0,115200 console=tty1 root=LABEL=writable rootfstype=ext4 
elevator=deadline rootwait fixrtc
  SourcePackage: systemd
  UpgradeStatus: No upgrade log present (probably fresh install)
  mtime.conffile..etc.systemd.resolved.conf: 2020-01-03T01:02:47.779343

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/systemd/+bug/1858210/+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 1930910] Autopkgtest regression report (systemd/246.6-1ubuntu1.5)

[Ubuntu SRU Bot]

All autopkgtests for the newly accepted systemd (246.6-1ubuntu1.5) for groovy 
have finished running.
The following regressions have been reported in tests triggered by the package:

prometheus/2.20.0+ds-1 (amd64)


Please visit the excuses page listed below and investigate the failures, 
proceeding afterwards as per the StableReleaseUpdates policy regarding 
autopkgtest regressions [1].

https://people.canonical.com/~ubuntu-archive/proposed-
migration/groovy/update_excuses.html#systemd

[1] https://wiki.ubuntu.com/StableReleaseUpdates#Autopkgtest_Regressions

Thank you!

-- 
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/1930910

Title:
  Fix micmute hotkeys on HP ProBooks

Status in HWE Next:
  New
Status in OEM Priority Project:
  New
Status in systemd package in Ubuntu:
  Fix Released
Status in systemd source package in Focal:
  Fix Committed
Status in systemd source package in Groovy:
  Fix Committed
Status in systemd source package in Hirsute:
  Fix Committed
Status in systemd source package in Impish:
  Fix Released

Bug description:
  [Impact]
  Micmute hotkey on many HP ProBooks don't work.

  [Fix]
  Commit a7161e0288d1 ("hwdb: Add ProBook to use micmute hotkey"), to map AT 
keyboard's scancode to micmute hotkey.

  [Test]
  With the one-liner fix, micmute hotkey works on all the ProBooks I tested.

  [Where problems could occur]
  The hwdb originally only matches a few ProBooks, the fix changes that to 
match all ProBook models. So if there's any ProBook that uses the scancode for 
another purpose, there will be a regression.
  However, the risk is rather slim because HP explicitly states that all 
ProBooks use the same scancode for mic mute hotkey.

To manage notifications about this bug go to:
https://bugs.launchpad.net/hwe-next/+bug/1930910/+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 1931578] Autopkgtest regression report (systemd/246.6-1ubuntu1.5)

[Ubuntu SRU Bot]

All autopkgtests for the newly accepted systemd (246.6-1ubuntu1.5) for groovy 
have finished running.
The following regressions have been reported in tests triggered by the package:

prometheus/2.20.0+ds-1 (amd64)


Please visit the excuses page listed below and investigate the failures, 
proceeding afterwards as per the StableReleaseUpdates policy regarding 
autopkgtest regressions [1].

https://people.canonical.com/~ubuntu-archive/proposed-
migration/groovy/update_excuses.html#systemd

[1] https://wiki.ubuntu.com/StableReleaseUpdates#Autopkgtest_Regressions

Thank you!

-- 
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/1931578

Title:
  ActivationPolicy=down causes delay at boot

Status in systemd package in Ubuntu:
  Fix Released
Status in systemd source package in Bionic:
  Won't Fix
Status in systemd source package in Focal:
  Fix Committed
Status in systemd source package in Groovy:
  Fix Committed
Status in systemd source package in Hirsute:
  Fix Committed
Status in systemd source package in Impish:
  Fix Released

Bug description:
  [impact]

  The ActivationPolicy= parameter was backported in bug 1664844, but
  when this is set to down (or always-down or manual) without also
  specifying RequiredForOnline=no, then there is a hang at boot waiting
  for the network to finish coming online.

  [test case]

  With the latest systemd, which includes support for ActivationPolicy=,
  configure an interface with ActivationPolicy=down and reboot. The boot
  will be delayed waiting for that interface.

  [regression potential]

  any regression would likely cause the system to encounter delay at
  boot, or to boot before configured interface(s) are fully online at
  boot, or to fail to correctly/fully configure interface(s).

  [scope]

  this is needed for all releases

  this is proposed upstream in:
  https://github.com/systemd/systemd/pull/19883

  [other info]

  this is only needed for convenience, as any configuration using
  ActivationPolicy=down can also easily add RequiredForOnline=no

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/systemd/+bug/1931578/+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 1891215] Autopkgtest regression report (systemd/246.6-1ubuntu1.5)

[Ubuntu SRU Bot]

All autopkgtests for the newly accepted systemd (246.6-1ubuntu1.5) for groovy 
have finished running.
The following regressions have been reported in tests triggered by the package:

prometheus/2.20.0+ds-1 (amd64)


Please visit the excuses page listed below and investigate the failures, 
proceeding afterwards as per the StableReleaseUpdates policy regarding 
autopkgtest regressions [1].

https://people.canonical.com/~ubuntu-archive/proposed-
migration/groovy/update_excuses.html#systemd

[1] https://wiki.ubuntu.com/StableReleaseUpdates#Autopkgtest_Regressions

Thank you!

-- 
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/1891215

Title:
  systemd-resolved re-creates /run/systemd/resolve/*resolv.conf for
  every IPv6 RA received

Status in systemd:
  Unknown
Status in systemd package in Ubuntu:
  Fix Released
Status in systemd source package in Bionic:
  New
Status in systemd source package in Focal:
  Fix Committed
Status in systemd source package in Groovy:
  Fix Committed
Status in systemd source package in Hirsute:
  Fix Committed

Bug description:
  [impact]

  networking changes, like RA events, can cause systemd-resolved to re-
  write the resolv.conf file, even if the contents didn't change,
  resulting in unnecessary increased amount of inotify events

  [test case]

  see original description for ipv6ra-related reproducer, or simple
  reproducer here:

  configure networkd with some config for (e.g.) eth0, but not a config
  that would result in /etc/resolv.conf changing when the interface goes
  up/down - for example, use static config with no DNS search domains.
  Then bring eth0 up/down while observing the md5sum (file content) does
  not change but the mtime does change.

  root@lp1891215-h:~# ip l set down dev eth0
  root@lp1891215-h:~# md5sum /etc/resolv.conf
  db23e80078515192c312e5f321ff0340  /etc/resolv.conf
  root@lp1891215-h:~# stat -t -L /etc/resolv.conf
  /etc/resolv.conf 740 8 81a4 101 103 fc 188 1 0 0 1625238218 1625238216 
1625238216 0 4096
  root@lp1891215-h:~# ip l set up dev eth0
  root@lp1891215-h:~# md5sum /etc/resolv.conf
  db23e80078515192c312e5f321ff0340  /etc/resolv.conf
  root@lp1891215-h:~# stat -t -L /etc/resolv.conf
  /etc/resolv.conf 740 8 81a4 101 103 fc 188 1 0 0 1625238227 1625238226 
1625238226 0 4096

  [regression potential]

  regressions would result in incorrect or missing data in the
  resolv.conf file, possibly resulting in dns failures or errors

  [scope]

  this is needed for h and eralier

  this is (potentially) fixed upstream by
  f3e1f00d03445911ee73729219cea88c8a70c612 which in first included in
  v248, so this is needed in hirsute and earlier

  [original description]

  # Issue description:

  On 2 Linode VMs that are used as lxd hosts, we noticed that
  /run/systemd/resolve/*resolv.conf were re-created quite frequently (~
  once per second). We noticed because of the log noise from lxd's
  dnsmasq instance using inotify to watch the target of /etc/resolv.conf
  (which points to the stub-resolv.conf in our case). This was (wrongly)
  reported as a lxd bug (https://github.com/lxc/lxd/issues/7765) until
  it became apparent it was more likely to be a problem with
  systemd(-resolved)?.

  The log noise is the observable problem that would be nice to see
  addressed:

    root@lxd02:~# uptime
     17:55:48 up  9:52,  1 user,  load average: 0.18, 0.11, 0.05
    root@lxd02:~# journalctl -b0 | grep -cF dnsmasq
    158609

  Upon further investigation, it seems that systemd-resolved re-creates
  the resolv.conf and stub-resolv.conf files whenever an IPv6 RA is
  received.

  1) One can observe that by setting systemd-resolved's service in debug
  mode:

  $ sudo systemctl edit systemd-resolved

  and in the editor that is opened, add and save this content:

  [Service]
  Environment=SYSTEMD_LOG_LEVEL=debug

  then restart systemd-resolved and watch the logs scroll by with:

  $ journalctl -fu systemd-resolved

  3) In another terminal, watch the files be recreated with:

  watch -d -n 0.1 stat /run/systemd/resolve/stub-resolv.conf

  3) In yet another terminal, run a packet capture and watch "ICMP6,
  router advertisement" messages come by:

  sudo tcpdump -ni eth0 icmp6

  You will see that every time a RA packet comes in, resolved's journal
  will log this:

    Aug 11 17:33:55 lxd02 systemd-resolved[15368]: Sent message
  type=signal sender=n/a destination=n/a path=/org/freedesktop/resolve1
  interface=org.freedesktop.DBus.Properties member=PropertiesChanged
  cookie=244 reply_cookie=0 signature=sa{sv}as error-name=n/a error-
  message=n/a

  And the stat monitoring terminal will blink to highlight the new inode
  and timestamps of the freshly replaced stub-resolv.conf file.

  # Additional information:

  root@lxd02:~# lsb_release -rd
  Description:  Ubuntu 20.04.1 LTS
  Release:  20.04

  root@lxd02:~# apt-cache policy 

[Touch-packages] [Bug 1894622] Autopkgtest regression report (systemd/246.6-1ubuntu1.5)

[Ubuntu SRU Bot]

All autopkgtests for the newly accepted systemd (246.6-1ubuntu1.5) for groovy 
have finished running.
The following regressions have been reported in tests triggered by the package:

prometheus/2.20.0+ds-1 (amd64)


Please visit the excuses page listed below and investigate the failures, 
proceeding afterwards as per the StableReleaseUpdates policy regarding 
autopkgtest regressions [1].

https://people.canonical.com/~ubuntu-archive/proposed-
migration/groovy/update_excuses.html#systemd

[1] https://wiki.ubuntu.com/StableReleaseUpdates#Autopkgtest_Regressions

Thank you!

-- 
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/1894622

Title:
  Missing manpage for systemd-resolve

Status in systemd package in Ubuntu:
  Fix Released
Status in systemd source package in Focal:
  Fix Committed
Status in systemd source package in Groovy:
  Fix Committed
Status in systemd source package in Hirsute:
  Fix Committed
Status in systemd source package in Impish:
  Fix Released

Bug description:
  [impact]

  'man systemd-resolve' fails

  [test case]

  $ man systemd-resolve
  No manual entry for systemd-resolve

  [regression potential]

  incorrect man page result for resolvectl or resolvconf, or possibly
  users using deprecated systemd-resolve longer than they should

  [scope]

  this is needed in f and later

  systemd-resolve was replaced with resolvectl between b and f, so the
  man page exists in b

  [other info]

  the systemd-resolve binary is a symlink to the real binary resolvectl, and 
users should use resolvectl for all new uses. A patch to the upstream man page 
was proposed and merged in this PR:
  https://github.com/systemd/systemd/pull/20064

  however that is being discussed and may be reverted in this PR:
  https://github.com/systemd/systemd/pull/20077

  as discussed in the revert PR, it's ok for upstream to elide docs
  about deprecated tooling; however distros should include deprecation
  info and thus I believe it's appropriate to include the man page
  symlink so users trying 'man systemd-resolve' will get the correct
  'resolvectl' man page, which includes doc about how they shoudl start
  using 'resolvectl' instead

  [original description]

  On my Focal machine there is no file /usr/share/man/man1/systemd-resolve.1.gz
  This means that man systemd-resolve fails.

  http://manpages.ubuntu.com/manpages/bionic/en/man1/systemd-
  resolve.1.html exists and has a link on top to 20.04LTS: it points to
  http://manpages.ubuntu.com/manpages/focal/en/man1/systemd-
  resolve.1.html , that however 404's, and one ends up being redirected
  to Bionic's.

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/systemd/+bug/1894622/+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 1932352] Autopkgtest regression report (systemd/246.6-1ubuntu1.5)

[Ubuntu SRU Bot]

All autopkgtests for the newly accepted systemd (246.6-1ubuntu1.5) for groovy 
have finished running.
The following regressions have been reported in tests triggered by the package:

prometheus/2.20.0+ds-1 (amd64)


Please visit the excuses page listed below and investigate the failures, 
proceeding afterwards as per the StableReleaseUpdates policy regarding 
autopkgtest regressions [1].

https://people.canonical.com/~ubuntu-archive/proposed-
migration/groovy/update_excuses.html#systemd

[1] https://wiki.ubuntu.com/StableReleaseUpdates#Autopkgtest_Regressions

Thank you!

-- 
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/1932352

Title:
  Fix micmute hotkeys on HP Elite Dragonfly

Status in OEM Priority Project:
  Triaged
Status in systemd package in Ubuntu:
  Fix Released
Status in systemd source package in Focal:
  Fix Committed
Status in systemd source package in Groovy:
  Fix Committed
Status in systemd source package in Hirsute:
  Fix Committed
Status in systemd source package in Impish:
  Fix Released

Bug description:
  [Impact]
  Mic mute key is no function on HP Elite Dragonfly.

  [Fix]
  After confirming with HP, there are two model names for Dragonfly:
  * HP Elite Dragonfly G2 Notebook PC
  * HP Elite Dragonfly Max Notebook PC
  Thus, the commit 
  Commit c1b8c966eccb7be1cae0a30670f5e1fcd88b47fa maps the 81 scan code to mic 
mute key.

  [Test]
  After patching it, the mic mute key could functioned well on my Dragonfly 
laptop.

  [Where problems could occur]
  There is not old rule for Dragonfly dmi string in current hwdb.
  Which means the Dragonfly is using default HP key map:
  ```
  evdev:atkbd:dmi:bvn*:bvr*:bd*:svnHP*:pn*:*

   KEYBOARD_KEY_81=fn_esc
  ```
  This patch will change the HP machine (if product name contains 
pnHPEliteDragonfly*) to map 81 to mic mute key.
  If a machine (pnHPEliteDragonfly*) works good in the past then this patch may 
cause it's mic mute key become malfunction.
  However, this rule is confirmed/provided from HP.

To manage notifications about this bug go to:
https://bugs.launchpad.net/oem-priority/+bug/1932352/+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 1891215] Re: systemd-resolved re-creates /run/systemd/resolve/*resolv.conf for every IPv6 RA received

[Simon Déziel]

Verification for Focal (245.4-4ubuntu3.8)

# Initial repro on focal:

root@focal:~# md5sum /etc/resolv.conf; stat -t -L /etc/resolv.conf 
fbfde622ae28a4dcfbf73a397a10c6ae  /etc/resolv.conf
/etc/resolv.conf 717 8 81a4 101 103 76 123 1 0 0 1625844292 1625844273 
1625844273 0 4096
root@focal:~# ip link set eth0 down; sleep 1; ip link set eth0 up
root@focal:~# md5sum /etc/resolv.conf; stat -t -L /etc/resolv.conf 
fbfde622ae28a4dcfbf73a397a10c6ae  /etc/resolv.conf
/etc/resolv.conf 717 8 81a4 101 103 76 123 1 0 0 1625844310 1625844308 
1625844308 0 4096


# Upgrading to -proposed

root@focal:~# apt update && apt-get dist-upgrade -V
Get:1 http://security.ubuntu.com/ubuntu focal-security InRelease [114 kB]
Hit:2 http://archive.ubuntu.com/ubuntu focal InRelease  
  
Get:3 http://archive.ubuntu.com/ubuntu focal-updates InRelease [114 kB]
Get:4 http://archive.ubuntu.com/ubuntu focal-proposed InRelease [267 kB]
Get:5 http://archive.ubuntu.com/ubuntu focal-updates/main amd64 Packages [1,086 
kB]
Get:6 http://archive.ubuntu.com/ubuntu focal-updates/main Translation-en [239 
kB]
Get:7 http://archive.ubuntu.com/ubuntu focal-updates/universe amd64 Packages 
[840 kB]
Get:8 http://archive.ubuntu.com/ubuntu focal-proposed/restricted amd64 Packages 
[191 kB]
Get:9 http://archive.ubuntu.com/ubuntu focal-proposed/restricted Translation-en 
[27.2 kB]
Get:10 http://archive.ubuntu.com/ubuntu focal-proposed/main amd64 Packages [203 
kB]
Get:11 http://archive.ubuntu.com/ubuntu focal-proposed/main Translation-en 
[42.2 kB]
Get:12 http://archive.ubuntu.com/ubuntu focal-proposed/multiverse amd64 
Packages [18.2 kB]
Get:13 http://archive.ubuntu.com/ubuntu focal-proposed/multiverse 
Translation-en [6,732 B]
Get:14 http://archive.ubuntu.com/ubuntu focal-proposed/universe amd64 Packages 
[56.2 kB]
Get:15 http://archive.ubuntu.com/ubuntu focal-proposed/universe Translation-en 
[24.5 kB]
Fetched 3,229 kB in 2s (1,428 kB/s)   
Reading package lists... Done
Building dependency tree   
Reading state information... Done
9 packages can be upgraded. Run 'apt list --upgradable' to see them.
Reading package lists... Done
Building dependency tree   
Reading state information... Done
Calculating upgrade... Done
The following packages will be upgraded:
   libgnutls30 (3.6.13-2ubuntu1.3 => 3.6.13-2ubuntu1.5)
   libnss-systemd (245.4-4ubuntu3.7 => 245.4-4ubuntu3.8)
   libpam-systemd (245.4-4ubuntu3.7 => 245.4-4ubuntu3.8)
   libsystemd0 (245.4-4ubuntu3.7 => 245.4-4ubuntu3.8)
   libudev1 (245.4-4ubuntu3.7 => 245.4-4ubuntu3.8)
   systemd (245.4-4ubuntu3.7 => 245.4-4ubuntu3.8)
   systemd-sysv (245.4-4ubuntu3.7 => 245.4-4ubuntu3.8)
   systemd-timesyncd (245.4-4ubuntu3.7 => 245.4-4ubuntu3.8)
   udev (245.4-4ubuntu3.7 => 245.4-4ubuntu3.8)
9 upgraded, 0 newly installed, 0 to remove and 0 not upgraded.
Need to get 6,672 kB of archives.
After this operation, 15.4 kB of additional disk space will be used.
Do you want to continue? [Y/n] 
Get:1 http://archive.ubuntu.com/ubuntu focal-proposed/main amd64 libnss-systemd 
amd64 245.4-4ubuntu3.8 [96.1 kB]
Get:2 http://archive.ubuntu.com/ubuntu focal-proposed/main amd64 udev amd64 
245.4-4ubuntu3.8 [1,365 kB]
Get:3 http://archive.ubuntu.com/ubuntu focal-proposed/main amd64 libudev1 amd64 
245.4-4ubuntu3.8 [78.4 kB]
Get:4 http://archive.ubuntu.com/ubuntu focal-proposed/main amd64 systemd-sysv 
amd64 245.4-4ubuntu3.8 [10.3 kB]
Get:5 http://archive.ubuntu.com/ubuntu focal-proposed/main amd64 
systemd-timesyncd amd64 245.4-4ubuntu3.8 [28.1 kB]
Get:6 http://archive.ubuntu.com/ubuntu focal-proposed/main amd64 libpam-systemd 
amd64 245.4-4ubuntu3.8 [186 kB]
Get:7 http://archive.ubuntu.com/ubuntu focal-proposed/main amd64 libgnutls30 
amd64 3.6.13-2ubuntu1.5 [828 kB]
Get:8 http://archive.ubuntu.com/ubuntu focal-proposed/main amd64 systemd amd64 
245.4-4ubuntu3.8 [3,810 kB]
Get:9 http://archive.ubuntu.com/ubuntu focal-proposed/main amd64 libsystemd0 
amd64 245.4-4ubuntu3.8 [271 kB]
Fetched 6,672 kB in 3s (2,541 kB/s)  
(Reading database ... 14718 files and directories currently installed.)
Preparing to unpack .../libnss-systemd_245.4-4ubuntu3.8_amd64.deb ...
Unpacking libnss-systemd:amd64 (245.4-4ubuntu3.8) over (245.4-4ubuntu3.7) ...
Preparing to unpack .../udev_245.4-4ubuntu3.8_amd64.deb ...
Unpacking udev (245.4-4ubuntu3.8) over (245.4-4ubuntu3.7) ...
Preparing to unpack .../libudev1_245.4-4ubuntu3.8_amd64.deb ...
Unpacking libudev1:amd64 (245.4-4ubuntu3.8) over (245.4-4ubuntu3.7) ...
Setting up libudev1:amd64 (245.4-4ubuntu3.8) ...
(Reading database ... 14718 files and directories currently installed.)
Preparing to unpack .../systemd-sysv_245.4-4ubuntu3.8_amd64.deb ...
Unpacking systemd-sysv (245.4-4ubuntu3.8) over (245.4-4ubuntu3.7) ...
Preparing to unpack .../systemd-timesyncd_245.4-4ubuntu3.8_amd64.deb ...
Unpacking systemd-timesyncd (245.4-4ubuntu3.8) over (245.4-4ubuntu3.7) ...
Preparing to unpack .../libpam-systemd_245.4-4ubuntu3.8_amd64.deb ...

[Touch-packages] [Bug 1891215] Re: systemd-resolved re-creates /run/systemd/resolve/*resolv.conf for every IPv6 RA received

[Simon Déziel]

Sorry about the noise, I had a problem in my reproducing steps, the
previous comment should be ignored. I got confused by stat's output
changing but that was the atime, not the mtime that was changing.

** Tags removed: verification-failed-focal
** Tags added: verification-needed-focal

-- 
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/1891215

Title:
  systemd-resolved re-creates /run/systemd/resolve/*resolv.conf for
  every IPv6 RA received

Status in systemd:
  Unknown
Status in systemd package in Ubuntu:
  Fix Released
Status in systemd source package in Bionic:
  New
Status in systemd source package in Focal:
  Fix Committed
Status in systemd source package in Groovy:
  Fix Committed
Status in systemd source package in Hirsute:
  Fix Committed

Bug description:
  [impact]

  networking changes, like RA events, can cause systemd-resolved to re-
  write the resolv.conf file, even if the contents didn't change,
  resulting in unnecessary increased amount of inotify events

  [test case]

  see original description for ipv6ra-related reproducer, or simple
  reproducer here:

  configure networkd with some config for (e.g.) eth0, but not a config
  that would result in /etc/resolv.conf changing when the interface goes
  up/down - for example, use static config with no DNS search domains.
  Then bring eth0 up/down while observing the md5sum (file content) does
  not change but the mtime does change.

  root@lp1891215-h:~# ip l set down dev eth0
  root@lp1891215-h:~# md5sum /etc/resolv.conf
  db23e80078515192c312e5f321ff0340  /etc/resolv.conf
  root@lp1891215-h:~# stat -t -L /etc/resolv.conf
  /etc/resolv.conf 740 8 81a4 101 103 fc 188 1 0 0 1625238218 1625238216 
1625238216 0 4096
  root@lp1891215-h:~# ip l set up dev eth0
  root@lp1891215-h:~# md5sum /etc/resolv.conf
  db23e80078515192c312e5f321ff0340  /etc/resolv.conf
  root@lp1891215-h:~# stat -t -L /etc/resolv.conf
  /etc/resolv.conf 740 8 81a4 101 103 fc 188 1 0 0 1625238227 1625238226 
1625238226 0 4096

  [regression potential]

  regressions would result in incorrect or missing data in the
  resolv.conf file, possibly resulting in dns failures or errors

  [scope]

  this is needed for h and eralier

  this is (potentially) fixed upstream by
  f3e1f00d03445911ee73729219cea88c8a70c612 which in first included in
  v248, so this is needed in hirsute and earlier

  [original description]

  # Issue description:

  On 2 Linode VMs that are used as lxd hosts, we noticed that
  /run/systemd/resolve/*resolv.conf were re-created quite frequently (~
  once per second). We noticed because of the log noise from lxd's
  dnsmasq instance using inotify to watch the target of /etc/resolv.conf
  (which points to the stub-resolv.conf in our case). This was (wrongly)
  reported as a lxd bug (https://github.com/lxc/lxd/issues/7765) until
  it became apparent it was more likely to be a problem with
  systemd(-resolved)?.

  The log noise is the observable problem that would be nice to see
  addressed:

    root@lxd02:~# uptime
     17:55:48 up  9:52,  1 user,  load average: 0.18, 0.11, 0.05
    root@lxd02:~# journalctl -b0 | grep -cF dnsmasq
    158609

  Upon further investigation, it seems that systemd-resolved re-creates
  the resolv.conf and stub-resolv.conf files whenever an IPv6 RA is
  received.

  1) One can observe that by setting systemd-resolved's service in debug
  mode:

  $ sudo systemctl edit systemd-resolved

  and in the editor that is opened, add and save this content:

  [Service]
  Environment=SYSTEMD_LOG_LEVEL=debug

  then restart systemd-resolved and watch the logs scroll by with:

  $ journalctl -fu systemd-resolved

  3) In another terminal, watch the files be recreated with:

  watch -d -n 0.1 stat /run/systemd/resolve/stub-resolv.conf

  3) In yet another terminal, run a packet capture and watch "ICMP6,
  router advertisement" messages come by:

  sudo tcpdump -ni eth0 icmp6

  You will see that every time a RA packet comes in, resolved's journal
  will log this:

    Aug 11 17:33:55 lxd02 systemd-resolved[15368]: Sent message
  type=signal sender=n/a destination=n/a path=/org/freedesktop/resolve1
  interface=org.freedesktop.DBus.Properties member=PropertiesChanged
  cookie=244 reply_cookie=0 signature=sa{sv}as error-name=n/a error-
  message=n/a

  And the stat monitoring terminal will blink to highlight the new inode
  and timestamps of the freshly replaced stub-resolv.conf file.

  # Additional information:

  root@lxd02:~# lsb_release -rd
  Description:  Ubuntu 20.04.1 LTS
  Release:  20.04

  root@lxd02:~# apt-cache policy systemd
  systemd:
    Installed: 245.4-4ubuntu3.2
    Candidate: 245.4-4ubuntu3.2
    Version table:
   *** 245.4-4ubuntu3.2 500
  500 http://archive.ubuntu.com/ubuntu focal-updates/main amd64 Packages
  100 /var/lib/dpkg/status
   245.4-4ubuntu3 500
  500 

[Touch-packages] [Bug 1934505]

[Simark]

Fixed by that commit.

-- 
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/1934505

Title:
  gdb 11 doesn't work on impish/s390x: internal-error:
  displaced_step_prepare_status linux_displaced_step_prepare(gdbarch*,
  thread_info*, CORE_ADDR&): Assertion
  `gdbarch_data->num_disp_step_buffers > 0' failed.

Status in gdb:
  Confirmed
Status in gdb package in Ubuntu:
  Fix Released

Bug description:
  gdb doesn't work on impish/s390x at the minute. Even if you say 'no'
  to both questions you still can't debug:

  ubuntu@laney-bos01-s390x-2:~/glib-networking-2.66.0/build$ gdb ls
  GNU gdb (Ubuntu 11.0.50.20210630-0ubuntu1) 11.0.50.20210630-git
  Copyright (C) 2021 Free Software Foundation, Inc.
  License GPLv3+: GNU GPL version 3 or later 
  This is free software: you are free to change and redistribute it.
  There is NO WARRANTY, to the extent permitted by law.
  Type "show copying" and "show warranty" for details.
  This GDB was configured as "s390x-linux-gnu".
  Type "show configuration" for configuration details.
  For bug reporting instructions, please see:
  .
  Find the GDB manual and other documentation resources online at:
  .

  For help, type "help".
  Type "apropos word" to search for commands related to "word"...
  Reading symbols from ls...
  (No debugging symbols found in ls)
  (gdb) run
  Starting program: /usr/bin/ls
  /build/gdb-Ti35un/gdb-11.0.50.20210630/gdb/linux-tdep.c:2550: internal-error: 
displaced_step_prepare_status linux_displaced_step_prepare(gdbarch*, 
thread_info*, CORE_ADDR&): Assertion `gdbarch_data->num_disp_step_buffers > 0' 
failed.
  A problem internal to GDB has been detected,
  further debugging may prove unreliable.
  Quit this debugging session? (y or n) n

  This is a bug, please report it.  For instructions, see:
  .

  /build/gdb-Ti35un/gdb-11.0.50.20210630/gdb/linux-tdep.c:2550: internal-error: 
displaced_step_prepare_status linux_displaced_step_prepare(gdbarch*, 
thread_info*, CORE_ADDR&): Assertion `gdbarch_data->num_disp_step_buffers > 0' 
failed.
  A problem internal to GDB has been detected,
  further debugging may prove unreliable.
  Create a core file of GDB? (y or n) n
  Command aborted.
  (gdb)

To manage notifications about this bug go to:
https://bugs.launchpad.net/gdb/+bug/1934505/+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 1934505]

[Cvs-commit]

The gdb-11-branch branch has been updated by Simon Marchi
:

https://sourceware.org/git/gitweb.cgi?p=binutils-
gdb.git;h=ff32938d4471ebf6dce462934de8ab47f9fd5d66

commit ff32938d4471ebf6dce462934de8ab47f9fd5d66
Author: Simon Marchi 
Date:   Thu Jul 8 10:05:16 2021 -0400

gdb: don't set Linux-specific displaced stepping methods in 
s390_gdbarch_init

According to bug 28056, running an s390x binary gives:

(gdb) run
Starting program: /usr/bin/ls
/home/ubuntu/tmp/gdb-11.0.90.20210705/gdb/linux-tdep.c:2550: 
internal-error: displaced_step_prepare_status 
linux_displaced_step_prepare(gdbarch*, thread_info*, CORE_ADDR&): Assertion 
`gdbarch_data->num_disp_step_buffers > 0' failed.

This is because the s390 architecture registers some Linux-specific
displaced stepping callbacks in the OS-agnostic s390_gdbarch_init:

set_gdbarch_displaced_step_prepare (gdbarch, 
linux_displaced_step_prepare);
set_gdbarch_displaced_step_finish (gdbarch, 
linux_displaced_step_finish);
set_gdbarch_displaced_step_restore_all_in_ptid
  (gdbarch, linux_displaced_step_restore_all_in_ptid);

But then the Linux-specific s390_linux_init_abi_any passes
num_disp_step_buffers=0 to linux_init_abi:

linux_init_abi (info, gdbarch, 0);

The problem happens when linux_displaced_step_prepare is called for the
first time.  It tries to allocate the displaced stepping buffers, but
sees that the number of displaced stepping buffers for that architecture
is 0, which is unexpected / invalid.

s390_gdbarch_init should not register the linux_* callbacks, that is
expected to be done by linux_init_abi.  If debugging a bare-metal s390
program, or an s390 program on another OS GDB doesn't know about, we
wouldn't want to use them.  We would either register no callbacks, if
displaced stepping isn't supported, or register a different set of
callbacks if we wanted to support displaced stepping in those cases.

The commit that refactored the displaced stepping machinery and
introduced these set_gdbarch_displaced_step_* calls is 187b041e2514
("gdb: move displaced stepping logic to gdbarch, allow starting
concurrent displaced steps").  However, even before that,
s390_gdbarch_init did:

  set_gdbarch_displaced_step_location (gdbarch, 
linux_displaced_step_location);

... which already seemed wrong.  The Linux-specific callback was used
even for non-Linux system.  Maybe that was on purpose, because it would
also happen to work in some other non-Linux case, or maybe it was simply
a mistake.  I'll assume that this was a small mistake when
s390-tdep.{h,c} where factored out of s390-linux-tdep.c, in d6e589456475
("s390: Split up s390-linux-tdep.c into two files").

Fix this by removing the setting of these displaced step callbacks from
s390_gdbarch_init.  Instead, pass num_disp_step_buffers=1 to
linux_init_abi, in s390_linux_init_abi_any.  Doing so will cause
linux_init_abi to register these same callbacks.  It will also mean that
when debugging a bare-metal s390 executable or an executable on another
OS that GDB doesn't know about, gdbarch_displaced_step_prepare won't be
set, so displaced stepping won't be used.

This patch will need to be merged in the gdb-11-branch, since this is a
GDB 11 regression, so here's the ChangeLog entry:

gdb/ChangeLog:

* s390-linux-tdep.c (s390_linux_init_abi_any): Pass 1 (number
of displaced stepping buffers to linux_init_abi.
* s390-tdep.c (s390_gdbarch_init): Don't set the Linux-specific
displaced-stepping gdbarch callbacks.

Change-Id: Ieab2f8990c78fde845ce7378d6fd4ee2833800d5
Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=28056

-- 
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/1934505

Title:
  gdb 11 doesn't work on impish/s390x: internal-error:
  displaced_step_prepare_status linux_displaced_step_prepare(gdbarch*,
  thread_info*, CORE_ADDR&): Assertion
  `gdbarch_data->num_disp_step_buffers > 0' failed.

Status in gdb:
  Confirmed
Status in gdb package in Ubuntu:
  Fix Released

Bug description:
  gdb doesn't work on impish/s390x at the minute. Even if you say 'no'
  to both questions you still can't debug:

  ubuntu@laney-bos01-s390x-2:~/glib-networking-2.66.0/build$ gdb ls
  GNU gdb (Ubuntu 11.0.50.20210630-0ubuntu1) 11.0.50.20210630-git
  Copyright (C) 2021 Free Software Foundation, Inc.
  License GPLv3+: GNU GPL version 3 or later 
  This is free software: you are free to change and redistribute it.
  There is NO WARRANTY, to the extent permitted by law.
  Type "show copying" and "show warranty" for details.
  This GDB was configured as 

[Touch-packages] [Bug 1934505]

[Cvs-commit]

The master branch has been updated by Simon Marchi
:

https://sourceware.org/git/gitweb.cgi?p=binutils-
gdb.git;h=74b10a3219e44ba2585e3f7226a6455d41e92c1b

commit 74b10a3219e44ba2585e3f7226a6455d41e92c1b
Author: Simon Marchi 
Date:   Wed Jul 7 08:57:36 2021 -0400

gdb: don't set Linux-specific displaced stepping methods in 
s390_gdbarch_init

According to bug 28056, running an s390x binary gives:

(gdb) run
Starting program: /usr/bin/ls
/home/ubuntu/tmp/gdb-11.0.90.20210705/gdb/linux-tdep.c:2550: 
internal-error: displaced_step_prepare_status 
linux_displaced_step_prepare(gdbarch*, thread_info*, CORE_ADDR&): Assertion 
`gdbarch_data->num_disp_step_buffers > 0' failed.

This is because the s390 architecture registers some Linux-specific
displaced stepping callbacks in the OS-agnostic s390_gdbarch_init:

set_gdbarch_displaced_step_prepare (gdbarch, 
linux_displaced_step_prepare);
set_gdbarch_displaced_step_finish (gdbarch, 
linux_displaced_step_finish);
set_gdbarch_displaced_step_restore_all_in_ptid
  (gdbarch, linux_displaced_step_restore_all_in_ptid);

But then the Linux-specific s390_linux_init_abi_any passes
num_disp_step_buffers=0 to linux_init_abi:

linux_init_abi (info, gdbarch, 0);

The problem happens when linux_displaced_step_prepare is called for the
first time.  It tries to allocate the displaced stepping buffers, but
sees that the number of displaced stepping buffers for that architecture
is 0, which is unexpected / invalid.

s390_gdbarch_init should not register the linux_* callbacks, that is
expected to be done by linux_init_abi.  If debugging a bare-metal s390
program, or an s390 program on another OS GDB doesn't know about, we
wouldn't want to use them.  We would either register no callbacks, if
displaced stepping isn't supported, or register a different set of
callbacks if we wanted to support displaced stepping in those cases.

The commit that refactored the displaced stepping machinery and
introduced these set_gdbarch_displaced_step_* calls is 187b041e2514
("gdb: move displaced stepping logic to gdbarch, allow starting
concurrent displaced steps").  However, even before that,
s390_gdbarch_init did:

  set_gdbarch_displaced_step_location (gdbarch, 
linux_displaced_step_location);

... which already seemed wrong.  The Linux-specific callback was used
even for non-Linux system.  Maybe that was on purpose, because it would
also happen to work in some other non-Linux case, or maybe it was simply
a mistake.  I'll assume that this was a small mistake when
s390-tdep.{h,c} where factored out of s390-linux-tdep.c, in d6e589456475
("s390: Split up s390-linux-tdep.c into two files").

Fix this by removing the setting of these displaced step callbacks from
s390_gdbarch_init.  Instead, pass num_disp_step_buffers=1 to
linux_init_abi, in s390_linux_init_abi_any.  Doing so will cause
linux_init_abi to register these same callbacks.  It will also mean that
when debugging a bare-metal s390 executable or an executable on another
OS that GDB doesn't know about, gdbarch_displaced_step_prepare won't be
set, so displaced stepping won't be used.

This patch will need to be merged in the gdb-11-branch, since this is a
GDB 11 regression, so here's the ChangeLog entry:

gdb/ChangeLog:

* s390-linux-tdep.c (s390_linux_init_abi_any): Pass 1 (number
of displaced stepping buffers to linux_init_abi.
* s390-tdep.c (s390_gdbarch_init): Don't set the Linux-specific
displaced-stepping gdbarch callbacks.

Change-Id: Ieab2f8990c78fde845ce7378d6fd4ee2833800d5
Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=28056

-- 
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/1934505

Title:
  gdb 11 doesn't work on impish/s390x: internal-error:
  displaced_step_prepare_status linux_displaced_step_prepare(gdbarch*,
  thread_info*, CORE_ADDR&): Assertion
  `gdbarch_data->num_disp_step_buffers > 0' failed.

Status in gdb:
  Confirmed
Status in gdb package in Ubuntu:
  Fix Released

Bug description:
  gdb doesn't work on impish/s390x at the minute. Even if you say 'no'
  to both questions you still can't debug:

  ubuntu@laney-bos01-s390x-2:~/glib-networking-2.66.0/build$ gdb ls
  GNU gdb (Ubuntu 11.0.50.20210630-0ubuntu1) 11.0.50.20210630-git
  Copyright (C) 2021 Free Software Foundation, Inc.
  License GPLv3+: GNU GPL version 3 or later 
  This is free software: you are free to change and redistribute it.
  There is NO WARRANTY, to the extent permitted by law.
  Type "show copying" and "show warranty" for details.
  This GDB was configured as 

[Touch-packages] [Bug 1891215] Re: systemd-resolved re-creates /run/systemd/resolve/*resolv.conf for every IPv6 RA received

[Simon Déziel]

@ddstreet, unfortunately, even with 245.4-4ubuntu3.8 on Focal, the mtime
keeps changing as RAs are received :/

** Tags removed: verification-needed-focal
** Tags added: verification-failed-focal

-- 
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/1891215

Title:
  systemd-resolved re-creates /run/systemd/resolve/*resolv.conf for
  every IPv6 RA received

Status in systemd:
  Unknown
Status in systemd package in Ubuntu:
  Fix Released
Status in systemd source package in Bionic:
  New
Status in systemd source package in Focal:
  Fix Committed
Status in systemd source package in Groovy:
  Fix Committed
Status in systemd source package in Hirsute:
  Fix Committed

Bug description:
  [impact]

  networking changes, like RA events, can cause systemd-resolved to re-
  write the resolv.conf file, even if the contents didn't change,
  resulting in unnecessary increased amount of inotify events

  [test case]

  see original description for ipv6ra-related reproducer, or simple
  reproducer here:

  configure networkd with some config for (e.g.) eth0, but not a config
  that would result in /etc/resolv.conf changing when the interface goes
  up/down - for example, use static config with no DNS search domains.
  Then bring eth0 up/down while observing the md5sum (file content) does
  not change but the mtime does change.

  root@lp1891215-h:~# ip l set down dev eth0
  root@lp1891215-h:~# md5sum /etc/resolv.conf
  db23e80078515192c312e5f321ff0340  /etc/resolv.conf
  root@lp1891215-h:~# stat -t -L /etc/resolv.conf
  /etc/resolv.conf 740 8 81a4 101 103 fc 188 1 0 0 1625238218 1625238216 
1625238216 0 4096
  root@lp1891215-h:~# ip l set up dev eth0
  root@lp1891215-h:~# md5sum /etc/resolv.conf
  db23e80078515192c312e5f321ff0340  /etc/resolv.conf
  root@lp1891215-h:~# stat -t -L /etc/resolv.conf
  /etc/resolv.conf 740 8 81a4 101 103 fc 188 1 0 0 1625238227 1625238226 
1625238226 0 4096

  [regression potential]

  regressions would result in incorrect or missing data in the
  resolv.conf file, possibly resulting in dns failures or errors

  [scope]

  this is needed for h and eralier

  this is (potentially) fixed upstream by
  f3e1f00d03445911ee73729219cea88c8a70c612 which in first included in
  v248, so this is needed in hirsute and earlier

  [original description]

  # Issue description:

  On 2 Linode VMs that are used as lxd hosts, we noticed that
  /run/systemd/resolve/*resolv.conf were re-created quite frequently (~
  once per second). We noticed because of the log noise from lxd's
  dnsmasq instance using inotify to watch the target of /etc/resolv.conf
  (which points to the stub-resolv.conf in our case). This was (wrongly)
  reported as a lxd bug (https://github.com/lxc/lxd/issues/7765) until
  it became apparent it was more likely to be a problem with
  systemd(-resolved)?.

  The log noise is the observable problem that would be nice to see
  addressed:

    root@lxd02:~# uptime
     17:55:48 up  9:52,  1 user,  load average: 0.18, 0.11, 0.05
    root@lxd02:~# journalctl -b0 | grep -cF dnsmasq
    158609

  Upon further investigation, it seems that systemd-resolved re-creates
  the resolv.conf and stub-resolv.conf files whenever an IPv6 RA is
  received.

  1) One can observe that by setting systemd-resolved's service in debug
  mode:

  $ sudo systemctl edit systemd-resolved

  and in the editor that is opened, add and save this content:

  [Service]
  Environment=SYSTEMD_LOG_LEVEL=debug

  then restart systemd-resolved and watch the logs scroll by with:

  $ journalctl -fu systemd-resolved

  3) In another terminal, watch the files be recreated with:

  watch -d -n 0.1 stat /run/systemd/resolve/stub-resolv.conf

  3) In yet another terminal, run a packet capture and watch "ICMP6,
  router advertisement" messages come by:

  sudo tcpdump -ni eth0 icmp6

  You will see that every time a RA packet comes in, resolved's journal
  will log this:

    Aug 11 17:33:55 lxd02 systemd-resolved[15368]: Sent message
  type=signal sender=n/a destination=n/a path=/org/freedesktop/resolve1
  interface=org.freedesktop.DBus.Properties member=PropertiesChanged
  cookie=244 reply_cookie=0 signature=sa{sv}as error-name=n/a error-
  message=n/a

  And the stat monitoring terminal will blink to highlight the new inode
  and timestamps of the freshly replaced stub-resolv.conf file.

  # Additional information:

  root@lxd02:~# lsb_release -rd
  Description:  Ubuntu 20.04.1 LTS
  Release:  20.04

  root@lxd02:~# apt-cache policy systemd
  systemd:
    Installed: 245.4-4ubuntu3.2
    Candidate: 245.4-4ubuntu3.2
    Version table:
   *** 245.4-4ubuntu3.2 500
  500 http://archive.ubuntu.com/ubuntu focal-updates/main amd64 Packages
  100 /var/lib/dpkg/status
   245.4-4ubuntu3 500
  500 http://archive.ubuntu.com/ubuntu focal/main amd64 Packages

  root@lxd02:~# uname -a
  Linux lxd01 

[Touch-packages] [Bug 1933402] Re: net card set VF and altname display blurred character

[dann frazier]

= Verification =
Before:
14: enp1s0f0np0v0:  mtu 1500 qdisc noop state DOWN group 
default qlen 1000
link/ether 92:aa:d8:f1:ae:10 brd ff:ff:ff:ff:ff:ff
altname `�lժ�
altname ��lժ�

After:
15: enp1s0f0np0v0:  mtu 1500 qdisc noop state DOWN group 
default qlen 1000
link/ether 92:aa:d8:f1:ae:10 brd ff:ff:ff:ff:ff:f

ubuntu@d06-3:~$ dpkg-query -W  systemd
systemd 245.4-4ubuntu3.8


** Tags removed: verification-needed verification-needed-focal
** Tags added: verification-done verification-done-focal

-- 
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/1933402

Title:
  net card set VF  and altname display blurred  character

Status in kunpeng920:
  Fix Committed
Status in kunpeng920 ubuntu-20.04-hwe series:
  Fix Committed
Status in systemd package in Ubuntu:
  Fix Released
Status in systemd source package in Focal:
  Fix Committed
Status in systemd source package in Groovy:
  Fix Released
Status in systemd source package in Hirsute:
  Fix Released
Status in systemd source package in Impish:
  Fix Released

Bug description:
  [Impact]
  When running with the HWE kernel (5.4 didn't support altnames), altnames 
containing garbage (uninitialized memory) may get assigned to a NIC. This is 
100% reproducible on arm64. The upstream commit message suggests that this has 
been seen to cause segfaults.

  [Test Case]
  1) echo 1 > /sys/class/net/enp189s0f0/device/sriov_numvfs
  2) ip a
  3)
  10: eno1v0:  mtu 1500 qdisc noop state DOWN group 
default qlen 1000
  link/ether 1e:d8:e1:e9:ae:25 brd ff:ff:ff:ff:ff:ff
  altname @▒ު▒
  altname enp125s0f0v0
  11: enp189s0f0v0:  mtu 1500 qdisc noop state DOWN group 
default qlen 1000
  link/ether 76:ea:f4:65:dd:33 brd ff:ff:ff:ff:ff:ff
  altname ▒b▒ު▒
  altname ▒▒

  [Fix]
  There's a one liner upstream fix that simply initializes a variable:
  
https://github.com/systemd/systemd/commit/61fd7d6720c562c88ab79062ff8d131e5e3c7b1b

  [What Could Go Wrong]
  The fix itself is innocuous - just initializing a variable to NULL. So the 
real risk here would seem to be limited to the common risks in updating a core 
package in the Ubuntu distribution.

To manage notifications about this bug go to:
https://bugs.launchpad.net/kunpeng920/+bug/1933402/+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 1935568] Re: after having a bug reported, locked screen, and coming back, ubuntu-bug -w leaves a gksudo dialog for dmesg open

[Brian Murray]

What package / application were you reporting a bug about? IIRC most
apport hooks won't ask for dmesg information.

If you remove the crash files in /var/crash/ and lock your screen do you
get another jackd crash in there? It could be that the crash reporting
process for jackd actually is asking for dmesg information.

-- 
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/1935568

Title:
  after having a bug reported, locked screen, and coming back, ubuntu-
  bug -w leaves a gksudo dialog for dmesg open

Status in apport package in Ubuntu:
  New

Bug description:
  I reported two bugs today, and both times, after having finished
  reporting the bug, locking my screen, and logging back in, suddenly
  there was a dialog asking for my sudo password so it can execute
  dmesg.

  But I could neither hit cancel nor could I enter my password, it
  apperaded that anything I did, especially clicks, made the window
  *below* the dialog react.

  First time I solved it by rebooting (because I had some packages to
  upgrade anyway), second time by killing gnome-shell and letting it
  restart.

  This dialog definitely did not appear in the process of reporting the
  bug, the first time it appeared on screen was minutes after completing
  the bugreports in launchpad, plus locking and unlocking the screen
  afterwards.

  Might also be a problem with gnome-shell or gksudo(?), but it only
  ever happened to me when using ubuntu-bug -w.

  ProblemType: Bug
  DistroRelease: Ubuntu 20.10
  Package: apport 2.20.11-0ubuntu50.7
  ProcVersionSignature: Ubuntu 5.8.0-59.66-lowlatency 5.8.18
  Uname: Linux 5.8.0-59-lowlatency x86_64
  ApportVersion: 2.20.11-0ubuntu50.7
  Architecture: amd64
  CasperMD5CheckResult: skip
  CrashReports:
   644:1000:124:0:2021-07-08 04:45:57.713189974 +0200:2021-07-08 
04:45:57.713189974 +0200:/var/crash/_usr_bin_jackd.1000.upload
   600:118:124:37:2021-07-08 04:46:00.914606508 +0200:2021-07-08 
04:46:00.906605467 +0200:/var/crash/_usr_bin_jackd.1000.uploaded
  CurrentDesktop: ubuntu:GNOME
  Date: Fri Jul  9 01:44:39 2021
  InstallationDate: Installed on 2020-04-12 (452 days ago)
  InstallationMedia: Ubuntu 19.10 "Eoan Ermine" - Release amd64 (20191017)
  PackageArchitecture: all
  SourcePackage: apport
  UpgradeStatus: Upgraded to groovy on 2020-11-03 (247 days ago)

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/apport/+bug/1935568/+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 1935570] Re: [HP Compaq Pro 6300 MT, Realtek ALC221, Black Mic, Front] Recording problem

[Rabi Sah]

Here is the file:

pa-info > pa-info.txt

On Fri, Jul 9, 2021 at 10:18 AM Rabi Sah  wrote:

> Hi ,
>
> i do not see the anything after i run pa-info > pa-info.txt command. I did
> not understand what to do with your command.
>
> On Thu, Jul 8, 2021 at 11:50 PM Hui Wang <1935...@bugs.launchpad.net>
> wrote:
>
>> Please plug the mic in, and run pa-info > pa-info.txt, then upload the
>> pa-info.txt
>>
>> --
>> You received this bug notification because you are subscribed to the bug
>> report.
>> https://bugs.launchpad.net/bugs/1935570
>>
>> Title:
>>   [HP Compaq Pro 6300 MT, Realtek ALC221, Black Mic, Front] Recording
>>   problem
>>
>> Status in alsa-driver package in Ubuntu:
>>   New
>>
>> Bug description:
>>   Hi,
>>
>>   the mic does not work in my Ubuntu OS. Can you guys do something i am
>>   very frustrated?
>>
>>   ProblemType: Bug
>>   DistroRelease: Ubuntu 20.04
>>   Package: alsa-base 1.0.25+dfsg-0ubuntu5
>>   ProcVersionSignature: Ubuntu 5.8.0-59.66~20.04.1-generic 5.8.18
>>   Uname: Linux 5.8.0-59-generic x86_64
>>   ApportVersion: 2.20.11-0ubuntu27.18
>>   Architecture: amd64
>>   AudioDevicesInUse:
>>USERPID ACCESS COMMAND
>>/dev/snd/controlC0:  ravisah96   1576 F pulseaudio
>>   CasperMD5CheckResult: skip
>>   CurrentDesktop: ubuntu:GNOME
>>   Date: Thu Jul  8 19:57:18 2021
>>   InstallationDate: Installed on 2021-06-08 (30 days ago)
>>   InstallationMedia: Ubuntu 20.04.2.0 LTS "Focal Fossa" - Release amd64
>> (20210209.1)
>>   PackageArchitecture: all
>>   ProcEnviron:
>>PATH=(custom, no user)
>>XDG_RUNTIME_DIR=
>>LANG=en_US.UTF-8
>>SHELL=/bin/bash
>>   SourcePackage: alsa-driver
>>   Symptom: audio
>>   Symptom_AlsaRecordingTest: ALSA recording test through plughw:PCH failed
>>   Symptom_Card: Built-in Audio - HDA Intel PCH
>>   Symptom_Jack: Black Mic, Front
>>   Symptom_Type: None of the above
>>   Title: [HP Compaq Pro 6300 MT, Realtek ALC221, Black Mic, Front]
>> Recording problem
>>   UpgradeStatus: No upgrade log present (probably fresh install)
>>   dmi.bios.date: 10/29/2012
>>   dmi.bios.release: 2.83
>>   dmi.bios.vendor: Hewlett-Packard
>>   dmi.bios.version: K01 v02.83
>>   dmi.board.asset.tag: MXL312111Y
>>   dmi.board.name: 339A
>>   dmi.board.vendor: Hewlett-Packard
>>   dmi.chassis.asset.tag: MXL312111Y
>>   dmi.chassis.type: 6
>>   dmi.chassis.vendor: Hewlett-Packard
>>   dmi.modalias:
>> dmi:bvnHewlett-Packard:bvrK01v02.83:bd10/29/2012:br2.83:svnHewlett-Packard:pnHPCompaqPro6300MT:pvr:rvnHewlett-Packard:rn339A:rvr:cvnHewlett-Packard:ct6:cvr:
>>   dmi.product.family: 103C_53307F G=D
>>   dmi.product.name: HP Compaq Pro 6300 MT
>>   dmi.product.sku: C6Z93UT#ABA
>>   dmi.sys.vendor: Hewlett-Packard
>>
>> To manage notifications about this bug go to:
>>
>> https://bugs.launchpad.net/ubuntu/+source/alsa-driver/+bug/1935570/+subscriptions
>>
>


** Attachment added: "pa-info.txt"
   
https://bugs.launchpad.net/bugs/1935570/+attachment/5510065/+files/pa-info.txt

-- 
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/1935570

Title:
  [HP Compaq Pro 6300 MT, Realtek ALC221, Black Mic, Front] Recording
  problem

Status in alsa-driver package in Ubuntu:
  New

Bug description:
  Hi,

  the mic does not work in my Ubuntu OS. Can you guys do something i am
  very frustrated?

  ProblemType: Bug
  DistroRelease: Ubuntu 20.04
  Package: alsa-base 1.0.25+dfsg-0ubuntu5
  ProcVersionSignature: Ubuntu 5.8.0-59.66~20.04.1-generic 5.8.18
  Uname: Linux 5.8.0-59-generic x86_64
  ApportVersion: 2.20.11-0ubuntu27.18
  Architecture: amd64
  AudioDevicesInUse:
   USERPID ACCESS COMMAND
   /dev/snd/controlC0:  ravisah96   1576 F pulseaudio
  CasperMD5CheckResult: skip
  CurrentDesktop: ubuntu:GNOME
  Date: Thu Jul  8 19:57:18 2021
  InstallationDate: Installed on 2021-06-08 (30 days ago)
  InstallationMedia: Ubuntu 20.04.2.0 LTS "Focal Fossa" - Release amd64 
(20210209.1)
  PackageArchitecture: all
  ProcEnviron:
   PATH=(custom, no user)
   XDG_RUNTIME_DIR=
   LANG=en_US.UTF-8
   SHELL=/bin/bash
  SourcePackage: alsa-driver
  Symptom: audio
  Symptom_AlsaRecordingTest: ALSA recording test through plughw:PCH failed
  Symptom_Card: Built-in Audio - HDA Intel PCH
  Symptom_Jack: Black Mic, Front
  Symptom_Type: None of the above
  Title: [HP Compaq Pro 6300 MT, Realtek ALC221, Black Mic, Front] Recording 
problem
  UpgradeStatus: No upgrade log present (probably fresh install)
  dmi.bios.date: 10/29/2012
  dmi.bios.release: 2.83
  dmi.bios.vendor: Hewlett-Packard
  dmi.bios.version: K01 v02.83
  dmi.board.asset.tag: MXL312111Y
  dmi.board.name: 339A
  dmi.board.vendor: Hewlett-Packard
  dmi.chassis.asset.tag: MXL312111Y
  dmi.chassis.type: 6
  dmi.chassis.vendor: Hewlett-Packard
  dmi.modalias: 

Re: [Touch-packages] [Bug 1935570] Re: [HP Compaq Pro 6300 MT, Realtek ALC221, Black Mic, Front] Recording problem

[Rabi Sah]

Hi ,

i do not see the anything after i run pa-info > pa-info.txt command. I did
not understand what to do with your command.

On Thu, Jul 8, 2021 at 11:50 PM Hui Wang <1935...@bugs.launchpad.net>
wrote:

> Please plug the mic in, and run pa-info > pa-info.txt, then upload the
> pa-info.txt
>
> --
> You received this bug notification because you are subscribed to the bug
> report.
> https://bugs.launchpad.net/bugs/1935570
>
> Title:
>   [HP Compaq Pro 6300 MT, Realtek ALC221, Black Mic, Front] Recording
>   problem
>
> Status in alsa-driver package in Ubuntu:
>   New
>
> Bug description:
>   Hi,
>
>   the mic does not work in my Ubuntu OS. Can you guys do something i am
>   very frustrated?
>
>   ProblemType: Bug
>   DistroRelease: Ubuntu 20.04
>   Package: alsa-base 1.0.25+dfsg-0ubuntu5
>   ProcVersionSignature: Ubuntu 5.8.0-59.66~20.04.1-generic 5.8.18
>   Uname: Linux 5.8.0-59-generic x86_64
>   ApportVersion: 2.20.11-0ubuntu27.18
>   Architecture: amd64
>   AudioDevicesInUse:
>USERPID ACCESS COMMAND
>/dev/snd/controlC0:  ravisah96   1576 F pulseaudio
>   CasperMD5CheckResult: skip
>   CurrentDesktop: ubuntu:GNOME
>   Date: Thu Jul  8 19:57:18 2021
>   InstallationDate: Installed on 2021-06-08 (30 days ago)
>   InstallationMedia: Ubuntu 20.04.2.0 LTS "Focal Fossa" - Release amd64
> (20210209.1)
>   PackageArchitecture: all
>   ProcEnviron:
>PATH=(custom, no user)
>XDG_RUNTIME_DIR=
>LANG=en_US.UTF-8
>SHELL=/bin/bash
>   SourcePackage: alsa-driver
>   Symptom: audio
>   Symptom_AlsaRecordingTest: ALSA recording test through plughw:PCH failed
>   Symptom_Card: Built-in Audio - HDA Intel PCH
>   Symptom_Jack: Black Mic, Front
>   Symptom_Type: None of the above
>   Title: [HP Compaq Pro 6300 MT, Realtek ALC221, Black Mic, Front]
> Recording problem
>   UpgradeStatus: No upgrade log present (probably fresh install)
>   dmi.bios.date: 10/29/2012
>   dmi.bios.release: 2.83
>   dmi.bios.vendor: Hewlett-Packard
>   dmi.bios.version: K01 v02.83
>   dmi.board.asset.tag: MXL312111Y
>   dmi.board.name: 339A
>   dmi.board.vendor: Hewlett-Packard
>   dmi.chassis.asset.tag: MXL312111Y
>   dmi.chassis.type: 6
>   dmi.chassis.vendor: Hewlett-Packard
>   dmi.modalias:
> dmi:bvnHewlett-Packard:bvrK01v02.83:bd10/29/2012:br2.83:svnHewlett-Packard:pnHPCompaqPro6300MT:pvr:rvnHewlett-Packard:rn339A:rvr:cvnHewlett-Packard:ct6:cvr:
>   dmi.product.family: 103C_53307F G=D
>   dmi.product.name: HP Compaq Pro 6300 MT
>   dmi.product.sku: C6Z93UT#ABA
>   dmi.sys.vendor: Hewlett-Packard
>
> To manage notifications about this bug go to:
>
> https://bugs.launchpad.net/ubuntu/+source/alsa-driver/+bug/1935570/+subscriptions
>

-- 
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/1935570

Title:
  [HP Compaq Pro 6300 MT, Realtek ALC221, Black Mic, Front] Recording
  problem

Status in alsa-driver package in Ubuntu:
  New

Bug description:
  Hi,

  the mic does not work in my Ubuntu OS. Can you guys do something i am
  very frustrated?

  ProblemType: Bug
  DistroRelease: Ubuntu 20.04
  Package: alsa-base 1.0.25+dfsg-0ubuntu5
  ProcVersionSignature: Ubuntu 5.8.0-59.66~20.04.1-generic 5.8.18
  Uname: Linux 5.8.0-59-generic x86_64
  ApportVersion: 2.20.11-0ubuntu27.18
  Architecture: amd64
  AudioDevicesInUse:
   USERPID ACCESS COMMAND
   /dev/snd/controlC0:  ravisah96   1576 F pulseaudio
  CasperMD5CheckResult: skip
  CurrentDesktop: ubuntu:GNOME
  Date: Thu Jul  8 19:57:18 2021
  InstallationDate: Installed on 2021-06-08 (30 days ago)
  InstallationMedia: Ubuntu 20.04.2.0 LTS "Focal Fossa" - Release amd64 
(20210209.1)
  PackageArchitecture: all
  ProcEnviron:
   PATH=(custom, no user)
   XDG_RUNTIME_DIR=
   LANG=en_US.UTF-8
   SHELL=/bin/bash
  SourcePackage: alsa-driver
  Symptom: audio
  Symptom_AlsaRecordingTest: ALSA recording test through plughw:PCH failed
  Symptom_Card: Built-in Audio - HDA Intel PCH
  Symptom_Jack: Black Mic, Front
  Symptom_Type: None of the above
  Title: [HP Compaq Pro 6300 MT, Realtek ALC221, Black Mic, Front] Recording 
problem
  UpgradeStatus: No upgrade log present (probably fresh install)
  dmi.bios.date: 10/29/2012
  dmi.bios.release: 2.83
  dmi.bios.vendor: Hewlett-Packard
  dmi.bios.version: K01 v02.83
  dmi.board.asset.tag: MXL312111Y
  dmi.board.name: 339A
  dmi.board.vendor: Hewlett-Packard
  dmi.chassis.asset.tag: MXL312111Y
  dmi.chassis.type: 6
  dmi.chassis.vendor: Hewlett-Packard
  dmi.modalias: 
dmi:bvnHewlett-Packard:bvrK01v02.83:bd10/29/2012:br2.83:svnHewlett-Packard:pnHPCompaqPro6300MT:pvr:rvnHewlett-Packard:rn339A:rvr:cvnHewlett-Packard:ct6:cvr:
  dmi.product.family: 103C_53307F G=D
  dmi.product.name: HP Compaq Pro 6300 MT
  dmi.product.sku: C6Z93UT#ABA
  dmi.sys.vendor: Hewlett-Packard

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/alsa-driver/+bug/1935570/+subscriptions

-- 

[Touch-packages] [Bug 1858210] Autopkgtest regression report (systemd/245.4-4ubuntu3.8)

[Ubuntu SRU Bot]

All autopkgtests for the newly accepted systemd (245.4-4ubuntu3.8) for focal 
have finished running.
The following regressions have been reported in tests triggered by the package:

asterisk/1:16.2.1~dfsg-2ubuntu1 (armhf)
gvfs/1.44.1-1ubuntu1 (amd64)
linux-oem-5.6/5.6.0-1057.61 (amd64)
munin/2.0.56-1ubuntu1 (ppc64el)


Please visit the excuses page listed below and investigate the failures, 
proceeding afterwards as per the StableReleaseUpdates policy regarding 
autopkgtest regressions [1].

https://people.canonical.com/~ubuntu-archive/proposed-
migration/focal/update_excuses.html#systemd

[1] https://wiki.ubuntu.com/StableReleaseUpdates#Autopkgtest_Regressions

Thank you!

-- 
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/1858210

Title:
  timedatectl doesn't list all timezones

Status in systemd package in Ubuntu:
  Fix Released
Status in systemd source package in Bionic:
  Won't Fix
Status in systemd source package in Focal:
  Fix Committed
Status in systemd source package in Groovy:
  Fix Committed
Status in systemd source package in Hirsute:
  Fix Committed
Status in systemd source package in Impish:
  Fix Released

Bug description:
  [impact]

  timedatectl list-timezones doesn't show many common timezones that are
  actually considered 'aliases', such as Europe/Bratislava or
  US/Eastern.

  [test case]

  $ timedatectl list-timezones | grep Eastern
  $

  [regression potential]

  any regression would likely result in an incorrect list of timezones
  shown from list-timezones, or failure to correctly set a timezone

  [scope]

  this is needed in f and later

  this is fixed upstream with PR 20066 which was just merged, so this is
  needed in all releases in ubuntu

  in bionic, the 'tzdata.zi' file that the new code uses isn't present,
  so this won't work on bionic, thus marking it wontfix

  [original description]

  Is there some filter determining which timezones are displayed by
  `timedatectl list-timezones`? My zone, Europe/Bratislava, is missing.
  Even stranger, it can successfully be set by timedatectl.

  ProblemType: Bug
  DistroRelease: Ubuntu 19.10
  Package: systemd 242-7ubuntu3.2
  ProcVersionSignature: Ubuntu 5.3.0-1014.16-raspi2 5.3.10
  Uname: Linux 5.3.0-1014-raspi2 aarch64
  ApportVersion: 2.20.11-0ubuntu8.2
  Architecture: arm64
  Date: Fri Jan  3 15:36:03 2020
  Lspci:

  ProcEnviron:
   TERM=xterm-256color
   PATH=(custom, no user)
   LANG=C.UTF-8
   SHELL=/bin/bash
  ProcKernelCmdLine: coherent_pool=1M 8250.nr_uarts=1 bcm2708_fb.fbwidth=1824 
bcm2708_fb.fbheight=984 bcm2708_fb.fbswap=1 vc_mem.mem_base=0x3ec0 
vc_mem.mem_size=0x4000  net.ifnames=0 dwc_otg.lpm_enable=0 
console=ttyS0,115200 console=tty1 root=LABEL=writable rootfstype=ext4 
elevator=deadline rootwait fixrtc
  SourcePackage: systemd
  UpgradeStatus: No upgrade log present (probably fresh install)
  mtime.conffile..etc.systemd.resolved.conf: 2020-01-03T01:02:47.779343

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/systemd/+bug/1858210/+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 1894622] Autopkgtest regression report (systemd/245.4-4ubuntu3.8)

[Ubuntu SRU Bot]

All autopkgtests for the newly accepted systemd (245.4-4ubuntu3.8) for focal 
have finished running.
The following regressions have been reported in tests triggered by the package:

asterisk/1:16.2.1~dfsg-2ubuntu1 (armhf)
gvfs/1.44.1-1ubuntu1 (amd64)
linux-oem-5.6/5.6.0-1057.61 (amd64)
munin/2.0.56-1ubuntu1 (ppc64el)


Please visit the excuses page listed below and investigate the failures, 
proceeding afterwards as per the StableReleaseUpdates policy regarding 
autopkgtest regressions [1].

https://people.canonical.com/~ubuntu-archive/proposed-
migration/focal/update_excuses.html#systemd

[1] https://wiki.ubuntu.com/StableReleaseUpdates#Autopkgtest_Regressions

Thank you!

-- 
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/1894622

Title:
  Missing manpage for systemd-resolve

Status in systemd package in Ubuntu:
  Fix Released
Status in systemd source package in Focal:
  Fix Committed
Status in systemd source package in Groovy:
  Fix Committed
Status in systemd source package in Hirsute:
  Fix Committed
Status in systemd source package in Impish:
  Fix Released

Bug description:
  [impact]

  'man systemd-resolve' fails

  [test case]

  $ man systemd-resolve
  No manual entry for systemd-resolve

  [regression potential]

  incorrect man page result for resolvectl or resolvconf, or possibly
  users using deprecated systemd-resolve longer than they should

  [scope]

  this is needed in f and later

  systemd-resolve was replaced with resolvectl between b and f, so the
  man page exists in b

  [other info]

  the systemd-resolve binary is a symlink to the real binary resolvectl, and 
users should use resolvectl for all new uses. A patch to the upstream man page 
was proposed and merged in this PR:
  https://github.com/systemd/systemd/pull/20064

  however that is being discussed and may be reverted in this PR:
  https://github.com/systemd/systemd/pull/20077

  as discussed in the revert PR, it's ok for upstream to elide docs
  about deprecated tooling; however distros should include deprecation
  info and thus I believe it's appropriate to include the man page
  symlink so users trying 'man systemd-resolve' will get the correct
  'resolvectl' man page, which includes doc about how they shoudl start
  using 'resolvectl' instead

  [original description]

  On my Focal machine there is no file /usr/share/man/man1/systemd-resolve.1.gz
  This means that man systemd-resolve fails.

  http://manpages.ubuntu.com/manpages/bionic/en/man1/systemd-
  resolve.1.html exists and has a link on top to 20.04LTS: it points to
  http://manpages.ubuntu.com/manpages/focal/en/man1/systemd-
  resolve.1.html , that however 404's, and one ends up being redirected
  to Bionic's.

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/systemd/+bug/1894622/+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 1891215] Autopkgtest regression report (systemd/245.4-4ubuntu3.8)

[Ubuntu SRU Bot]

All autopkgtests for the newly accepted systemd (245.4-4ubuntu3.8) for focal 
have finished running.
The following regressions have been reported in tests triggered by the package:

asterisk/1:16.2.1~dfsg-2ubuntu1 (armhf)
gvfs/1.44.1-1ubuntu1 (amd64)
linux-oem-5.6/5.6.0-1057.61 (amd64)
munin/2.0.56-1ubuntu1 (ppc64el)


Please visit the excuses page listed below and investigate the failures, 
proceeding afterwards as per the StableReleaseUpdates policy regarding 
autopkgtest regressions [1].

https://people.canonical.com/~ubuntu-archive/proposed-
migration/focal/update_excuses.html#systemd

[1] https://wiki.ubuntu.com/StableReleaseUpdates#Autopkgtest_Regressions

Thank you!

-- 
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/1891215

Title:
  systemd-resolved re-creates /run/systemd/resolve/*resolv.conf for
  every IPv6 RA received

Status in systemd:
  Unknown
Status in systemd package in Ubuntu:
  Fix Released
Status in systemd source package in Bionic:
  New
Status in systemd source package in Focal:
  Fix Committed
Status in systemd source package in Groovy:
  Fix Committed
Status in systemd source package in Hirsute:
  Fix Committed

Bug description:
  [impact]

  networking changes, like RA events, can cause systemd-resolved to re-
  write the resolv.conf file, even if the contents didn't change,
  resulting in unnecessary increased amount of inotify events

  [test case]

  see original description for ipv6ra-related reproducer, or simple
  reproducer here:

  configure networkd with some config for (e.g.) eth0, but not a config
  that would result in /etc/resolv.conf changing when the interface goes
  up/down - for example, use static config with no DNS search domains.
  Then bring eth0 up/down while observing the md5sum (file content) does
  not change but the mtime does change.

  root@lp1891215-h:~# ip l set down dev eth0
  root@lp1891215-h:~# md5sum /etc/resolv.conf
  db23e80078515192c312e5f321ff0340  /etc/resolv.conf
  root@lp1891215-h:~# stat -t -L /etc/resolv.conf
  /etc/resolv.conf 740 8 81a4 101 103 fc 188 1 0 0 1625238218 1625238216 
1625238216 0 4096
  root@lp1891215-h:~# ip l set up dev eth0
  root@lp1891215-h:~# md5sum /etc/resolv.conf
  db23e80078515192c312e5f321ff0340  /etc/resolv.conf
  root@lp1891215-h:~# stat -t -L /etc/resolv.conf
  /etc/resolv.conf 740 8 81a4 101 103 fc 188 1 0 0 1625238227 1625238226 
1625238226 0 4096

  [regression potential]

  regressions would result in incorrect or missing data in the
  resolv.conf file, possibly resulting in dns failures or errors

  [scope]

  this is needed for h and eralier

  this is (potentially) fixed upstream by
  f3e1f00d03445911ee73729219cea88c8a70c612 which in first included in
  v248, so this is needed in hirsute and earlier

  [original description]

  # Issue description:

  On 2 Linode VMs that are used as lxd hosts, we noticed that
  /run/systemd/resolve/*resolv.conf were re-created quite frequently (~
  once per second). We noticed because of the log noise from lxd's
  dnsmasq instance using inotify to watch the target of /etc/resolv.conf
  (which points to the stub-resolv.conf in our case). This was (wrongly)
  reported as a lxd bug (https://github.com/lxc/lxd/issues/7765) until
  it became apparent it was more likely to be a problem with
  systemd(-resolved)?.

  The log noise is the observable problem that would be nice to see
  addressed:

    root@lxd02:~# uptime
     17:55:48 up  9:52,  1 user,  load average: 0.18, 0.11, 0.05
    root@lxd02:~# journalctl -b0 | grep -cF dnsmasq
    158609

  Upon further investigation, it seems that systemd-resolved re-creates
  the resolv.conf and stub-resolv.conf files whenever an IPv6 RA is
  received.

  1) One can observe that by setting systemd-resolved's service in debug
  mode:

  $ sudo systemctl edit systemd-resolved

  and in the editor that is opened, add and save this content:

  [Service]
  Environment=SYSTEMD_LOG_LEVEL=debug

  then restart systemd-resolved and watch the logs scroll by with:

  $ journalctl -fu systemd-resolved

  3) In another terminal, watch the files be recreated with:

  watch -d -n 0.1 stat /run/systemd/resolve/stub-resolv.conf

  3) In yet another terminal, run a packet capture and watch "ICMP6,
  router advertisement" messages come by:

  sudo tcpdump -ni eth0 icmp6

  You will see that every time a RA packet comes in, resolved's journal
  will log this:

    Aug 11 17:33:55 lxd02 systemd-resolved[15368]: Sent message
  type=signal sender=n/a destination=n/a path=/org/freedesktop/resolve1
  interface=org.freedesktop.DBus.Properties member=PropertiesChanged
  cookie=244 reply_cookie=0 signature=sa{sv}as error-name=n/a error-
  message=n/a

  And the stat monitoring terminal will blink to highlight the new inode
  and timestamps of the freshly replaced stub-resolv.conf file.

  # Additional information:

  root@lxd02:~# 

[Touch-packages] [Bug 1853164] Autopkgtest regression report (systemd/245.4-4ubuntu3.8)

[Ubuntu SRU Bot]

All autopkgtests for the newly accepted systemd (245.4-4ubuntu3.8) for focal 
have finished running.
The following regressions have been reported in tests triggered by the package:

asterisk/1:16.2.1~dfsg-2ubuntu1 (armhf)
gvfs/1.44.1-1ubuntu1 (amd64)
linux-oem-5.6/5.6.0-1057.61 (amd64)
munin/2.0.56-1ubuntu1 (ppc64el)


Please visit the excuses page listed below and investigate the failures, 
proceeding afterwards as per the StableReleaseUpdates policy regarding 
autopkgtest regressions [1].

https://people.canonical.com/~ubuntu-archive/proposed-
migration/focal/update_excuses.html#systemd

[1] https://wiki.ubuntu.com/StableReleaseUpdates#Autopkgtest_Regressions

Thank you!

-- 
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/1853164

Title:
  systemd: /etc/dhcp/dhclient-enter-hooks.d/resolved error

Status in systemd package in Ubuntu:
  Fix Released
Status in systemd source package in Bionic:
  New
Status in systemd source package in Focal:
  Fix Committed

Bug description:
  [impact]

  with systemd-resolved disabled, dhclient doesn't correctly notify
  resolvconf about dns server(s)

  [test case]

  install resolvconf and ifupdown and disable systemd-resolved and
  systemd-networkd, use ifupdown to get a dhcp address where the lease
  includes a dns nameserver, verify resolvconf is using that dhcp-
  provided nameserver

  [regression potential]

  failure to correctly notify systemd-resolved about new dhclient-
  provided nameserver(s)

  [scope]

  this is needed for f and earlier

  in g and later the hook script is moved to the isc-dhcp package, and
  edited to correctly check is-enabled systemd-resolved instead of only
  checking for the existence of the binary

  [original description]

  The functionality exists to allow users to revert to the traditional ifupdown
  package for network configuration. Alongside this, systemd's often-buggy
  resolver can be disabled. However, there's a logic error in the systemd-
  supplied /etc/dhcp/dhclient-enter-hooks.d/resolved that prevents the system
  from populating /etc/resolv.conf properly when systemd-resolved is disabled.
  The issue is here:

  if [ -x /lib/systemd/systemd-resolved ] ; then

  Instead of checking to see if the systemd-resolved service is enabled or
  active, which would be the correct behaviour, this checks for the existence of
  a binary, assuming that if it exists it's supposed to be used.

  I've not tested this in the absence of resolvconf, but if systemd-resolved
  isn't enabled, it's difficult to imagine this code wanting to run. I've tested
  this with resolvconf and ifupdown driving dhclient, and it corrects the
  behaviour that was broken with the introduction of systemd-resolved.

  I'm attaching a patch, and am also including it here for easy access:

  *** resolved.broken 2019-11-19 15:01:28.785588838 +
  --- resolved2019-11-19 15:08:06.519430073 +
  ***
  *** 14,20 
    #   (D) = master script downs interface
    #   (-) = master script does nothing with this

  ! if [ -x /lib/systemd/systemd-resolved ] ; then
    # For safety, first undefine the nasty default make_resolv_conf()
    make_resolv_conf() { : ; }
    case "$reason" in
  --- 14,21 
    #   (D) = master script downs interface
    #   (-) = master script does nothing with this

  ! systemctl is-active systemd-resolved > /dev/null 2>&1
  ! if [ $? -eq 0 ]; then
    # For safety, first undefine the nasty default make_resolv_conf()
    make_resolv_conf() { : ; }
    case "$reason" in

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/systemd/+bug/1853164/+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 1932352] Autopkgtest regression report (systemd/245.4-4ubuntu3.8)

[Ubuntu SRU Bot]

All autopkgtests for the newly accepted systemd (245.4-4ubuntu3.8) for focal 
have finished running.
The following regressions have been reported in tests triggered by the package:

asterisk/1:16.2.1~dfsg-2ubuntu1 (armhf)
gvfs/1.44.1-1ubuntu1 (amd64)
linux-oem-5.6/5.6.0-1057.61 (amd64)
munin/2.0.56-1ubuntu1 (ppc64el)


Please visit the excuses page listed below and investigate the failures, 
proceeding afterwards as per the StableReleaseUpdates policy regarding 
autopkgtest regressions [1].

https://people.canonical.com/~ubuntu-archive/proposed-
migration/focal/update_excuses.html#systemd

[1] https://wiki.ubuntu.com/StableReleaseUpdates#Autopkgtest_Regressions

Thank you!

-- 
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/1932352

Title:
  Fix micmute hotkeys on HP Elite Dragonfly

Status in OEM Priority Project:
  Triaged
Status in systemd package in Ubuntu:
  Fix Released
Status in systemd source package in Focal:
  Fix Committed
Status in systemd source package in Groovy:
  Fix Committed
Status in systemd source package in Hirsute:
  Fix Committed
Status in systemd source package in Impish:
  Fix Released

Bug description:
  [Impact]
  Mic mute key is no function on HP Elite Dragonfly.

  [Fix]
  After confirming with HP, there are two model names for Dragonfly:
  * HP Elite Dragonfly G2 Notebook PC
  * HP Elite Dragonfly Max Notebook PC
  Thus, the commit 
  Commit c1b8c966eccb7be1cae0a30670f5e1fcd88b47fa maps the 81 scan code to mic 
mute key.

  [Test]
  After patching it, the mic mute key could functioned well on my Dragonfly 
laptop.

  [Where problems could occur]
  There is not old rule for Dragonfly dmi string in current hwdb.
  Which means the Dragonfly is using default HP key map:
  ```
  evdev:atkbd:dmi:bvn*:bvr*:bd*:svnHP*:pn*:*

   KEYBOARD_KEY_81=fn_esc
  ```
  This patch will change the HP machine (if product name contains 
pnHPEliteDragonfly*) to map 81 to mic mute key.
  If a machine (pnHPEliteDragonfly*) works good in the past then this patch may 
cause it's mic mute key become malfunction.
  However, this rule is confirmed/provided from HP.

To manage notifications about this bug go to:
https://bugs.launchpad.net/oem-priority/+bug/1932352/+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 1928200] Autopkgtest regression report (systemd/245.4-4ubuntu3.8)

[Ubuntu SRU Bot]

All autopkgtests for the newly accepted systemd (245.4-4ubuntu3.8) for focal 
have finished running.
The following regressions have been reported in tests triggered by the package:

asterisk/1:16.2.1~dfsg-2ubuntu1 (armhf)
gvfs/1.44.1-1ubuntu1 (amd64)
linux-oem-5.6/5.6.0-1057.61 (amd64)
munin/2.0.56-1ubuntu1 (ppc64el)


Please visit the excuses page listed below and investigate the failures, 
proceeding afterwards as per the StableReleaseUpdates policy regarding 
autopkgtest regressions [1].

https://people.canonical.com/~ubuntu-archive/proposed-
migration/focal/update_excuses.html#systemd

[1] https://wiki.ubuntu.com/StableReleaseUpdates#Autopkgtest_Regressions

Thank you!

-- 
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/1928200

Title:
  Prompt error message "Failed to unmount /oldroot" when shutdown or
  reboot

Status in OEM Priority Project:
  Confirmed
Status in systemd package in Ubuntu:
  Fix Released
Status in systemd source package in Focal:
  Fix Committed

Bug description:
  [impact]

  root fs is not cleanly unmounted on shutdown

  [test case]

  create a file in /etc/binfmt.d/TestFormat.conf with the following
  content:

  :TestFormat:M::XX::/bin/true:F

  reboot the system, and then shutdown or reboot again, and watch the
  serial console for the error message:

  sd-umount[1334]: Failed to unmount /oldroot: Device or resource busy

  [regression potential]

  any regression would likely cause problems on shutdown and/or reboot,
  or may cause problems with unmounted root fs on shutdown/reboot

  [scope]

  this is needed only for f

  this is fixed upstream with PR 15566 which is included in v246, so
  this is fixed already in g and later

  this isn't reproducable on b

  [original description]

  On ubuntu 20.04, with latest kernel and systemd, it will show error on
  ThinkPad X1.

  sd-umount[1334]: Failed to unmount /oldroot: Device or resource busy

  systemd 245.4-4ubuntu3.6
  kernel: 5.8.0-53

To manage notifications about this bug go to:
https://bugs.launchpad.net/oem-priority/+bug/1928200/+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 1930910] Autopkgtest regression report (systemd/245.4-4ubuntu3.8)

[Ubuntu SRU Bot]

All autopkgtests for the newly accepted systemd (245.4-4ubuntu3.8) for focal 
have finished running.
The following regressions have been reported in tests triggered by the package:

asterisk/1:16.2.1~dfsg-2ubuntu1 (armhf)
gvfs/1.44.1-1ubuntu1 (amd64)
linux-oem-5.6/5.6.0-1057.61 (amd64)
munin/2.0.56-1ubuntu1 (ppc64el)


Please visit the excuses page listed below and investigate the failures, 
proceeding afterwards as per the StableReleaseUpdates policy regarding 
autopkgtest regressions [1].

https://people.canonical.com/~ubuntu-archive/proposed-
migration/focal/update_excuses.html#systemd

[1] https://wiki.ubuntu.com/StableReleaseUpdates#Autopkgtest_Regressions

Thank you!

-- 
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/1930910

Title:
  Fix micmute hotkeys on HP ProBooks

Status in HWE Next:
  New
Status in OEM Priority Project:
  New
Status in systemd package in Ubuntu:
  Fix Released
Status in systemd source package in Focal:
  Fix Committed
Status in systemd source package in Groovy:
  Fix Committed
Status in systemd source package in Hirsute:
  Fix Committed
Status in systemd source package in Impish:
  Fix Released

Bug description:
  [Impact]
  Micmute hotkey on many HP ProBooks don't work.

  [Fix]
  Commit a7161e0288d1 ("hwdb: Add ProBook to use micmute hotkey"), to map AT 
keyboard's scancode to micmute hotkey.

  [Test]
  With the one-liner fix, micmute hotkey works on all the ProBooks I tested.

  [Where problems could occur]
  The hwdb originally only matches a few ProBooks, the fix changes that to 
match all ProBook models. So if there's any ProBook that uses the scancode for 
another purpose, there will be a regression.
  However, the risk is rather slim because HP explicitly states that all 
ProBooks use the same scancode for mic mute hotkey.

To manage notifications about this bug go to:
https://bugs.launchpad.net/hwe-next/+bug/1930910/+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 1931578] Autopkgtest regression report (systemd/245.4-4ubuntu3.8)

[Ubuntu SRU Bot]

All autopkgtests for the newly accepted systemd (245.4-4ubuntu3.8) for focal 
have finished running.
The following regressions have been reported in tests triggered by the package:

asterisk/1:16.2.1~dfsg-2ubuntu1 (armhf)
gvfs/1.44.1-1ubuntu1 (amd64)
linux-oem-5.6/5.6.0-1057.61 (amd64)
munin/2.0.56-1ubuntu1 (ppc64el)


Please visit the excuses page listed below and investigate the failures, 
proceeding afterwards as per the StableReleaseUpdates policy regarding 
autopkgtest regressions [1].

https://people.canonical.com/~ubuntu-archive/proposed-
migration/focal/update_excuses.html#systemd

[1] https://wiki.ubuntu.com/StableReleaseUpdates#Autopkgtest_Regressions

Thank you!

-- 
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/1931578

Title:
  ActivationPolicy=down causes delay at boot

Status in systemd package in Ubuntu:
  Fix Released
Status in systemd source package in Bionic:
  Won't Fix
Status in systemd source package in Focal:
  Fix Committed
Status in systemd source package in Groovy:
  Fix Committed
Status in systemd source package in Hirsute:
  Fix Committed
Status in systemd source package in Impish:
  Fix Released

Bug description:
  [impact]

  The ActivationPolicy= parameter was backported in bug 1664844, but
  when this is set to down (or always-down or manual) without also
  specifying RequiredForOnline=no, then there is a hang at boot waiting
  for the network to finish coming online.

  [test case]

  With the latest systemd, which includes support for ActivationPolicy=,
  configure an interface with ActivationPolicy=down and reboot. The boot
  will be delayed waiting for that interface.

  [regression potential]

  any regression would likely cause the system to encounter delay at
  boot, or to boot before configured interface(s) are fully online at
  boot, or to fail to correctly/fully configure interface(s).

  [scope]

  this is needed for all releases

  this is proposed upstream in:
  https://github.com/systemd/systemd/pull/19883

  [other info]

  this is only needed for convenience, as any configuration using
  ActivationPolicy=down can also easily add RequiredForOnline=no

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/systemd/+bug/1931578/+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 1933402] Autopkgtest regression report (systemd/245.4-4ubuntu3.8)

[Ubuntu SRU Bot]

All autopkgtests for the newly accepted systemd (245.4-4ubuntu3.8) for focal 
have finished running.
The following regressions have been reported in tests triggered by the package:

asterisk/1:16.2.1~dfsg-2ubuntu1 (armhf)
gvfs/1.44.1-1ubuntu1 (amd64)
linux-oem-5.6/5.6.0-1057.61 (amd64)
munin/2.0.56-1ubuntu1 (ppc64el)


Please visit the excuses page listed below and investigate the failures, 
proceeding afterwards as per the StableReleaseUpdates policy regarding 
autopkgtest regressions [1].

https://people.canonical.com/~ubuntu-archive/proposed-
migration/focal/update_excuses.html#systemd

[1] https://wiki.ubuntu.com/StableReleaseUpdates#Autopkgtest_Regressions

Thank you!

-- 
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/1933402

Title:
  net card set VF  and altname display blurred  character

Status in kunpeng920:
  Fix Committed
Status in kunpeng920 ubuntu-20.04-hwe series:
  Fix Committed
Status in systemd package in Ubuntu:
  Fix Released
Status in systemd source package in Focal:
  Fix Committed
Status in systemd source package in Groovy:
  Fix Released
Status in systemd source package in Hirsute:
  Fix Released
Status in systemd source package in Impish:
  Fix Released

Bug description:
  [Impact]
  When running with the HWE kernel (5.4 didn't support altnames), altnames 
containing garbage (uninitialized memory) may get assigned to a NIC. This is 
100% reproducible on arm64. The upstream commit message suggests that this has 
been seen to cause segfaults.

  [Test Case]
  1) echo 1 > /sys/class/net/enp189s0f0/device/sriov_numvfs
  2) ip a
  3)
  10: eno1v0:  mtu 1500 qdisc noop state DOWN group 
default qlen 1000
  link/ether 1e:d8:e1:e9:ae:25 brd ff:ff:ff:ff:ff:ff
  altname @▒ު▒
  altname enp125s0f0v0
  11: enp189s0f0v0:  mtu 1500 qdisc noop state DOWN group 
default qlen 1000
  link/ether 76:ea:f4:65:dd:33 brd ff:ff:ff:ff:ff:ff
  altname ▒b▒ު▒
  altname ▒▒

  [Fix]
  There's a one liner upstream fix that simply initializes a variable:
  
https://github.com/systemd/systemd/commit/61fd7d6720c562c88ab79062ff8d131e5e3c7b1b

  [What Could Go Wrong]
  The fix itself is innocuous - just initializing a variable to NULL. So the 
real risk here would seem to be limited to the common risks in updating a core 
package in the Ubuntu distribution.

To manage notifications about this bug go to:
https://bugs.launchpad.net/kunpeng920/+bug/1933402/+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 1858210] Autopkgtest regression report (systemd/247.3-3ubuntu3.2)

[Ubuntu SRU Bot]

All autopkgtests for the newly accepted systemd (247.3-3ubuntu3.2) for hirsute 
have finished running.
The following regressions have been reported in tests triggered by the package:

umockdev/0.15.4-1 (armhf)
initramfs-tools/0.139ubuntu3 (amd64)
apt/2.2.4ubuntu0.1 (armhf)
netplan.io/0.102-0ubuntu3 (amd64)


Please visit the excuses page listed below and investigate the failures, 
proceeding afterwards as per the StableReleaseUpdates policy regarding 
autopkgtest regressions [1].

https://people.canonical.com/~ubuntu-archive/proposed-
migration/hirsute/update_excuses.html#systemd

[1] https://wiki.ubuntu.com/StableReleaseUpdates#Autopkgtest_Regressions

Thank you!

-- 
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/1858210

Title:
  timedatectl doesn't list all timezones

Status in systemd package in Ubuntu:
  Fix Released
Status in systemd source package in Bionic:
  Won't Fix
Status in systemd source package in Focal:
  Fix Committed
Status in systemd source package in Groovy:
  Fix Committed
Status in systemd source package in Hirsute:
  Fix Committed
Status in systemd source package in Impish:
  Fix Released

Bug description:
  [impact]

  timedatectl list-timezones doesn't show many common timezones that are
  actually considered 'aliases', such as Europe/Bratislava or
  US/Eastern.

  [test case]

  $ timedatectl list-timezones | grep Eastern
  $

  [regression potential]

  any regression would likely result in an incorrect list of timezones
  shown from list-timezones, or failure to correctly set a timezone

  [scope]

  this is needed in f and later

  this is fixed upstream with PR 20066 which was just merged, so this is
  needed in all releases in ubuntu

  in bionic, the 'tzdata.zi' file that the new code uses isn't present,
  so this won't work on bionic, thus marking it wontfix

  [original description]

  Is there some filter determining which timezones are displayed by
  `timedatectl list-timezones`? My zone, Europe/Bratislava, is missing.
  Even stranger, it can successfully be set by timedatectl.

  ProblemType: Bug
  DistroRelease: Ubuntu 19.10
  Package: systemd 242-7ubuntu3.2
  ProcVersionSignature: Ubuntu 5.3.0-1014.16-raspi2 5.3.10
  Uname: Linux 5.3.0-1014-raspi2 aarch64
  ApportVersion: 2.20.11-0ubuntu8.2
  Architecture: arm64
  Date: Fri Jan  3 15:36:03 2020
  Lspci:

  ProcEnviron:
   TERM=xterm-256color
   PATH=(custom, no user)
   LANG=C.UTF-8
   SHELL=/bin/bash
  ProcKernelCmdLine: coherent_pool=1M 8250.nr_uarts=1 bcm2708_fb.fbwidth=1824 
bcm2708_fb.fbheight=984 bcm2708_fb.fbswap=1 vc_mem.mem_base=0x3ec0 
vc_mem.mem_size=0x4000  net.ifnames=0 dwc_otg.lpm_enable=0 
console=ttyS0,115200 console=tty1 root=LABEL=writable rootfstype=ext4 
elevator=deadline rootwait fixrtc
  SourcePackage: systemd
  UpgradeStatus: No upgrade log present (probably fresh install)
  mtime.conffile..etc.systemd.resolved.conf: 2020-01-03T01:02:47.779343

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/systemd/+bug/1858210/+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 1931578] Autopkgtest regression report (systemd/247.3-3ubuntu3.2)

[Ubuntu SRU Bot]

All autopkgtests for the newly accepted systemd (247.3-3ubuntu3.2) for hirsute 
have finished running.
The following regressions have been reported in tests triggered by the package:

umockdev/0.15.4-1 (armhf)
initramfs-tools/0.139ubuntu3 (amd64)
apt/2.2.4ubuntu0.1 (armhf)
netplan.io/0.102-0ubuntu3 (amd64)


Please visit the excuses page listed below and investigate the failures, 
proceeding afterwards as per the StableReleaseUpdates policy regarding 
autopkgtest regressions [1].

https://people.canonical.com/~ubuntu-archive/proposed-
migration/hirsute/update_excuses.html#systemd

[1] https://wiki.ubuntu.com/StableReleaseUpdates#Autopkgtest_Regressions

Thank you!

-- 
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/1931578

Title:
  ActivationPolicy=down causes delay at boot

Status in systemd package in Ubuntu:
  Fix Released
Status in systemd source package in Bionic:
  Won't Fix
Status in systemd source package in Focal:
  Fix Committed
Status in systemd source package in Groovy:
  Fix Committed
Status in systemd source package in Hirsute:
  Fix Committed
Status in systemd source package in Impish:
  Fix Released

Bug description:
  [impact]

  The ActivationPolicy= parameter was backported in bug 1664844, but
  when this is set to down (or always-down or manual) without also
  specifying RequiredForOnline=no, then there is a hang at boot waiting
  for the network to finish coming online.

  [test case]

  With the latest systemd, which includes support for ActivationPolicy=,
  configure an interface with ActivationPolicy=down and reboot. The boot
  will be delayed waiting for that interface.

  [regression potential]

  any regression would likely cause the system to encounter delay at
  boot, or to boot before configured interface(s) are fully online at
  boot, or to fail to correctly/fully configure interface(s).

  [scope]

  this is needed for all releases

  this is proposed upstream in:
  https://github.com/systemd/systemd/pull/19883

  [other info]

  this is only needed for convenience, as any configuration using
  ActivationPolicy=down can also easily add RequiredForOnline=no

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/systemd/+bug/1931578/+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 1891215] Autopkgtest regression report (systemd/247.3-3ubuntu3.2)

[Ubuntu SRU Bot]

All autopkgtests for the newly accepted systemd (247.3-3ubuntu3.2) for hirsute 
have finished running.
The following regressions have been reported in tests triggered by the package:

umockdev/0.15.4-1 (armhf)
initramfs-tools/0.139ubuntu3 (amd64)
apt/2.2.4ubuntu0.1 (armhf)
netplan.io/0.102-0ubuntu3 (amd64)


Please visit the excuses page listed below and investigate the failures, 
proceeding afterwards as per the StableReleaseUpdates policy regarding 
autopkgtest regressions [1].

https://people.canonical.com/~ubuntu-archive/proposed-
migration/hirsute/update_excuses.html#systemd

[1] https://wiki.ubuntu.com/StableReleaseUpdates#Autopkgtest_Regressions

Thank you!

-- 
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/1891215

Title:
  systemd-resolved re-creates /run/systemd/resolve/*resolv.conf for
  every IPv6 RA received

Status in systemd:
  Unknown
Status in systemd package in Ubuntu:
  Fix Released
Status in systemd source package in Bionic:
  New
Status in systemd source package in Focal:
  Fix Committed
Status in systemd source package in Groovy:
  Fix Committed
Status in systemd source package in Hirsute:
  Fix Committed

Bug description:
  [impact]

  networking changes, like RA events, can cause systemd-resolved to re-
  write the resolv.conf file, even if the contents didn't change,
  resulting in unnecessary increased amount of inotify events

  [test case]

  see original description for ipv6ra-related reproducer, or simple
  reproducer here:

  configure networkd with some config for (e.g.) eth0, but not a config
  that would result in /etc/resolv.conf changing when the interface goes
  up/down - for example, use static config with no DNS search domains.
  Then bring eth0 up/down while observing the md5sum (file content) does
  not change but the mtime does change.

  root@lp1891215-h:~# ip l set down dev eth0
  root@lp1891215-h:~# md5sum /etc/resolv.conf
  db23e80078515192c312e5f321ff0340  /etc/resolv.conf
  root@lp1891215-h:~# stat -t -L /etc/resolv.conf
  /etc/resolv.conf 740 8 81a4 101 103 fc 188 1 0 0 1625238218 1625238216 
1625238216 0 4096
  root@lp1891215-h:~# ip l set up dev eth0
  root@lp1891215-h:~# md5sum /etc/resolv.conf
  db23e80078515192c312e5f321ff0340  /etc/resolv.conf
  root@lp1891215-h:~# stat -t -L /etc/resolv.conf
  /etc/resolv.conf 740 8 81a4 101 103 fc 188 1 0 0 1625238227 1625238226 
1625238226 0 4096

  [regression potential]

  regressions would result in incorrect or missing data in the
  resolv.conf file, possibly resulting in dns failures or errors

  [scope]

  this is needed for h and eralier

  this is (potentially) fixed upstream by
  f3e1f00d03445911ee73729219cea88c8a70c612 which in first included in
  v248, so this is needed in hirsute and earlier

  [original description]

  # Issue description:

  On 2 Linode VMs that are used as lxd hosts, we noticed that
  /run/systemd/resolve/*resolv.conf were re-created quite frequently (~
  once per second). We noticed because of the log noise from lxd's
  dnsmasq instance using inotify to watch the target of /etc/resolv.conf
  (which points to the stub-resolv.conf in our case). This was (wrongly)
  reported as a lxd bug (https://github.com/lxc/lxd/issues/7765) until
  it became apparent it was more likely to be a problem with
  systemd(-resolved)?.

  The log noise is the observable problem that would be nice to see
  addressed:

    root@lxd02:~# uptime
     17:55:48 up  9:52,  1 user,  load average: 0.18, 0.11, 0.05
    root@lxd02:~# journalctl -b0 | grep -cF dnsmasq
    158609

  Upon further investigation, it seems that systemd-resolved re-creates
  the resolv.conf and stub-resolv.conf files whenever an IPv6 RA is
  received.

  1) One can observe that by setting systemd-resolved's service in debug
  mode:

  $ sudo systemctl edit systemd-resolved

  and in the editor that is opened, add and save this content:

  [Service]
  Environment=SYSTEMD_LOG_LEVEL=debug

  then restart systemd-resolved and watch the logs scroll by with:

  $ journalctl -fu systemd-resolved

  3) In another terminal, watch the files be recreated with:

  watch -d -n 0.1 stat /run/systemd/resolve/stub-resolv.conf

  3) In yet another terminal, run a packet capture and watch "ICMP6,
  router advertisement" messages come by:

  sudo tcpdump -ni eth0 icmp6

  You will see that every time a RA packet comes in, resolved's journal
  will log this:

    Aug 11 17:33:55 lxd02 systemd-resolved[15368]: Sent message
  type=signal sender=n/a destination=n/a path=/org/freedesktop/resolve1
  interface=org.freedesktop.DBus.Properties member=PropertiesChanged
  cookie=244 reply_cookie=0 signature=sa{sv}as error-name=n/a error-
  message=n/a

  And the stat monitoring terminal will blink to highlight the new inode
  and timestamps of the freshly replaced stub-resolv.conf file.

  # Additional information:

  root@lxd02:~# lsb_release -rd
  

[Touch-packages] [Bug 1925827] Autopkgtest regression report (systemd/247.3-3ubuntu3.2)

[Ubuntu SRU Bot]

All autopkgtests for the newly accepted systemd (247.3-3ubuntu3.2) for hirsute 
have finished running.
The following regressions have been reported in tests triggered by the package:

umockdev/0.15.4-1 (armhf)
initramfs-tools/0.139ubuntu3 (amd64)
apt/2.2.4ubuntu0.1 (armhf)
netplan.io/0.102-0ubuntu3 (amd64)


Please visit the excuses page listed below and investigate the failures, 
proceeding afterwards as per the StableReleaseUpdates policy regarding 
autopkgtest regressions [1].

https://people.canonical.com/~ubuntu-archive/proposed-
migration/hirsute/update_excuses.html#systemd

[1] https://wiki.ubuntu.com/StableReleaseUpdates#Autopkgtest_Regressions

Thank you!

-- 
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/1925827

Title:
  [v247] backport routing policy rule fix

Status in systemd package in Ubuntu:
  Fix Released
Status in systemd source package in Hirsute:
  Fix Committed

Bug description:
  [impact]

  routing policy rules not correctly configured

  [test case]

  more detail in upstream bug linked from original description.

  configure interface with:

  [Match]
  Name = ens3

  [Network]
  Address = 10.0.0.1/32

  [RoutingPolicyRule]
  Family = both
  IncomingInterface = ens3
  Table = 42
  Priority = 42

  
  then networkctl reload. then update the network file with:

  [Route]
  Table = 42
  Destination = 10.0.0.0/24
  Gateway = 0.0.0.0

  and run networkctl reload again, checking systemd-networkd for error.

  [regression potential]

  failure to properly configure networking in general, or policy routes.

  [scope]

  this is needed only for h.

  this is fixed already in i, and this is not reproducable in g.

  see original descrption for link to specific upstream issue and pr.

  [original description]

  The original issue can be found at 
https://github.com/systemd/systemd/issues/18107.
  I filed a backport PR (https://github.com/systemd/systemd-stable/pull/96) 
against v247-stable branch, which got merged and released in v247.4.
  However due to the freezing state of Debian bullseye, upstream systemd 
package is frozen at v247.3.
  Please apply this patchset for Ubuntu if possible.
  Thanks.

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/systemd/+bug/1925827/+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 1894622] Autopkgtest regression report (systemd/247.3-3ubuntu3.2)

[Ubuntu SRU Bot]

All autopkgtests for the newly accepted systemd (247.3-3ubuntu3.2) for hirsute 
have finished running.
The following regressions have been reported in tests triggered by the package:

umockdev/0.15.4-1 (armhf)
initramfs-tools/0.139ubuntu3 (amd64)
apt/2.2.4ubuntu0.1 (armhf)
netplan.io/0.102-0ubuntu3 (amd64)


Please visit the excuses page listed below and investigate the failures, 
proceeding afterwards as per the StableReleaseUpdates policy regarding 
autopkgtest regressions [1].

https://people.canonical.com/~ubuntu-archive/proposed-
migration/hirsute/update_excuses.html#systemd

[1] https://wiki.ubuntu.com/StableReleaseUpdates#Autopkgtest_Regressions

Thank you!

-- 
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/1894622

Title:
  Missing manpage for systemd-resolve

Status in systemd package in Ubuntu:
  Fix Released
Status in systemd source package in Focal:
  Fix Committed
Status in systemd source package in Groovy:
  Fix Committed
Status in systemd source package in Hirsute:
  Fix Committed
Status in systemd source package in Impish:
  Fix Released

Bug description:
  [impact]

  'man systemd-resolve' fails

  [test case]

  $ man systemd-resolve
  No manual entry for systemd-resolve

  [regression potential]

  incorrect man page result for resolvectl or resolvconf, or possibly
  users using deprecated systemd-resolve longer than they should

  [scope]

  this is needed in f and later

  systemd-resolve was replaced with resolvectl between b and f, so the
  man page exists in b

  [other info]

  the systemd-resolve binary is a symlink to the real binary resolvectl, and 
users should use resolvectl for all new uses. A patch to the upstream man page 
was proposed and merged in this PR:
  https://github.com/systemd/systemd/pull/20064

  however that is being discussed and may be reverted in this PR:
  https://github.com/systemd/systemd/pull/20077

  as discussed in the revert PR, it's ok for upstream to elide docs
  about deprecated tooling; however distros should include deprecation
  info and thus I believe it's appropriate to include the man page
  symlink so users trying 'man systemd-resolve' will get the correct
  'resolvectl' man page, which includes doc about how they shoudl start
  using 'resolvectl' instead

  [original description]

  On my Focal machine there is no file /usr/share/man/man1/systemd-resolve.1.gz
  This means that man systemd-resolve fails.

  http://manpages.ubuntu.com/manpages/bionic/en/man1/systemd-
  resolve.1.html exists and has a link on top to 20.04LTS: it points to
  http://manpages.ubuntu.com/manpages/focal/en/man1/systemd-
  resolve.1.html , that however 404's, and one ends up being redirected
  to Bionic's.

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/systemd/+bug/1894622/+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 1930910] Autopkgtest regression report (systemd/247.3-3ubuntu3.2)

[Ubuntu SRU Bot]

All autopkgtests for the newly accepted systemd (247.3-3ubuntu3.2) for hirsute 
have finished running.
The following regressions have been reported in tests triggered by the package:

umockdev/0.15.4-1 (armhf)
initramfs-tools/0.139ubuntu3 (amd64)
apt/2.2.4ubuntu0.1 (armhf)
netplan.io/0.102-0ubuntu3 (amd64)


Please visit the excuses page listed below and investigate the failures, 
proceeding afterwards as per the StableReleaseUpdates policy regarding 
autopkgtest regressions [1].

https://people.canonical.com/~ubuntu-archive/proposed-
migration/hirsute/update_excuses.html#systemd

[1] https://wiki.ubuntu.com/StableReleaseUpdates#Autopkgtest_Regressions

Thank you!

-- 
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/1930910

Title:
  Fix micmute hotkeys on HP ProBooks

Status in HWE Next:
  New
Status in OEM Priority Project:
  New
Status in systemd package in Ubuntu:
  Fix Released
Status in systemd source package in Focal:
  Fix Committed
Status in systemd source package in Groovy:
  Fix Committed
Status in systemd source package in Hirsute:
  Fix Committed
Status in systemd source package in Impish:
  Fix Released

Bug description:
  [Impact]
  Micmute hotkey on many HP ProBooks don't work.

  [Fix]
  Commit a7161e0288d1 ("hwdb: Add ProBook to use micmute hotkey"), to map AT 
keyboard's scancode to micmute hotkey.

  [Test]
  With the one-liner fix, micmute hotkey works on all the ProBooks I tested.

  [Where problems could occur]
  The hwdb originally only matches a few ProBooks, the fix changes that to 
match all ProBook models. So if there's any ProBook that uses the scancode for 
another purpose, there will be a regression.
  However, the risk is rather slim because HP explicitly states that all 
ProBooks use the same scancode for mic mute hotkey.

To manage notifications about this bug go to:
https://bugs.launchpad.net/hwe-next/+bug/1930910/+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 1932352] Autopkgtest regression report (systemd/247.3-3ubuntu3.2)

[Ubuntu SRU Bot]

All autopkgtests for the newly accepted systemd (247.3-3ubuntu3.2) for hirsute 
have finished running.
The following regressions have been reported in tests triggered by the package:

umockdev/0.15.4-1 (armhf)
initramfs-tools/0.139ubuntu3 (amd64)
apt/2.2.4ubuntu0.1 (armhf)
netplan.io/0.102-0ubuntu3 (amd64)


Please visit the excuses page listed below and investigate the failures, 
proceeding afterwards as per the StableReleaseUpdates policy regarding 
autopkgtest regressions [1].

https://people.canonical.com/~ubuntu-archive/proposed-
migration/hirsute/update_excuses.html#systemd

[1] https://wiki.ubuntu.com/StableReleaseUpdates#Autopkgtest_Regressions

Thank you!

-- 
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/1932352

Title:
  Fix micmute hotkeys on HP Elite Dragonfly

Status in OEM Priority Project:
  Triaged
Status in systemd package in Ubuntu:
  Fix Released
Status in systemd source package in Focal:
  Fix Committed
Status in systemd source package in Groovy:
  Fix Committed
Status in systemd source package in Hirsute:
  Fix Committed
Status in systemd source package in Impish:
  Fix Released

Bug description:
  [Impact]
  Mic mute key is no function on HP Elite Dragonfly.

  [Fix]
  After confirming with HP, there are two model names for Dragonfly:
  * HP Elite Dragonfly G2 Notebook PC
  * HP Elite Dragonfly Max Notebook PC
  Thus, the commit 
  Commit c1b8c966eccb7be1cae0a30670f5e1fcd88b47fa maps the 81 scan code to mic 
mute key.

  [Test]
  After patching it, the mic mute key could functioned well on my Dragonfly 
laptop.

  [Where problems could occur]
  There is not old rule for Dragonfly dmi string in current hwdb.
  Which means the Dragonfly is using default HP key map:
  ```
  evdev:atkbd:dmi:bvn*:bvr*:bd*:svnHP*:pn*:*

   KEYBOARD_KEY_81=fn_esc
  ```
  This patch will change the HP machine (if product name contains 
pnHPEliteDragonfly*) to map 81 to mic mute key.
  If a machine (pnHPEliteDragonfly*) works good in the past then this patch may 
cause it's mic mute key become malfunction.
  However, this rule is confirmed/provided from HP.

To manage notifications about this bug go to:
https://bugs.launchpad.net/oem-priority/+bug/1932352/+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 1930910] Re: Fix micmute hotkeys on HP ProBooks

[Andy Chi]

[machine]
HP ProBook

[OS]
Focal

[systemd version]
245.4-4ubuntu3.8

[test result]
mic mute key works fine.

** Tags removed: verification-needed verification-needed-focal
** Tags added: verification-done verification-done-focal

-- 
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/1930910

Title:
  Fix micmute hotkeys on HP ProBooks

Status in HWE Next:
  New
Status in OEM Priority Project:
  New
Status in systemd package in Ubuntu:
  Fix Released
Status in systemd source package in Focal:
  Fix Committed
Status in systemd source package in Groovy:
  Fix Committed
Status in systemd source package in Hirsute:
  Fix Committed
Status in systemd source package in Impish:
  Fix Released

Bug description:
  [Impact]
  Micmute hotkey on many HP ProBooks don't work.

  [Fix]
  Commit a7161e0288d1 ("hwdb: Add ProBook to use micmute hotkey"), to map AT 
keyboard's scancode to micmute hotkey.

  [Test]
  With the one-liner fix, micmute hotkey works on all the ProBooks I tested.

  [Where problems could occur]
  The hwdb originally only matches a few ProBooks, the fix changes that to 
match all ProBook models. So if there's any ProBook that uses the scancode for 
another purpose, there will be a regression.
  However, the risk is rather slim because HP explicitly states that all 
ProBooks use the same scancode for mic mute hotkey.

To manage notifications about this bug go to:
https://bugs.launchpad.net/hwe-next/+bug/1930910/+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 1930910] Re: Fix micmute hotkeys on HP ProBooks

[Andy Chi]

[machine]
HP ProBook

[OS]
Groovy

[systemd version]
246.6-1ubuntu1.5

[test result]
mic mute key works fine.

** Tags removed: verification-needed-groovy
** Tags added: verification-done-groovy

-- 
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/1930910

Title:
  Fix micmute hotkeys on HP ProBooks

Status in HWE Next:
  New
Status in OEM Priority Project:
  New
Status in systemd package in Ubuntu:
  Fix Released
Status in systemd source package in Focal:
  Fix Committed
Status in systemd source package in Groovy:
  Fix Committed
Status in systemd source package in Hirsute:
  Fix Committed
Status in systemd source package in Impish:
  Fix Released

Bug description:
  [Impact]
  Micmute hotkey on many HP ProBooks don't work.

  [Fix]
  Commit a7161e0288d1 ("hwdb: Add ProBook to use micmute hotkey"), to map AT 
keyboard's scancode to micmute hotkey.

  [Test]
  With the one-liner fix, micmute hotkey works on all the ProBooks I tested.

  [Where problems could occur]
  The hwdb originally only matches a few ProBooks, the fix changes that to 
match all ProBook models. So if there's any ProBook that uses the scancode for 
another purpose, there will be a regression.
  However, the risk is rather slim because HP explicitly states that all 
ProBooks use the same scancode for mic mute hotkey.

To manage notifications about this bug go to:
https://bugs.launchpad.net/hwe-next/+bug/1930910/+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 1930910] Re: Fix micmute hotkeys on HP ProBooks

[Andy Chi]

[machine]
HP ProBook

[OS]
Hirsute

[systemd version]
247.3-3ubuntu3.2

[test result]
mic mute key works fine.

** Tags removed: verification-needed-hirsute
** Tags added: verification-done-hirsute

-- 
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/1930910

Title:
  Fix micmute hotkeys on HP ProBooks

Status in HWE Next:
  New
Status in OEM Priority Project:
  New
Status in systemd package in Ubuntu:
  Fix Released
Status in systemd source package in Focal:
  Fix Committed
Status in systemd source package in Groovy:
  Fix Committed
Status in systemd source package in Hirsute:
  Fix Committed
Status in systemd source package in Impish:
  Fix Released

Bug description:
  [Impact]
  Micmute hotkey on many HP ProBooks don't work.

  [Fix]
  Commit a7161e0288d1 ("hwdb: Add ProBook to use micmute hotkey"), to map AT 
keyboard's scancode to micmute hotkey.

  [Test]
  With the one-liner fix, micmute hotkey works on all the ProBooks I tested.

  [Where problems could occur]
  The hwdb originally only matches a few ProBooks, the fix changes that to 
match all ProBook models. So if there's any ProBook that uses the scancode for 
another purpose, there will be a regression.
  However, the risk is rather slim because HP explicitly states that all 
ProBooks use the same scancode for mic mute hotkey.

To manage notifications about this bug go to:
https://bugs.launchpad.net/hwe-next/+bug/1930910/+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 1934992] Re: rsync 3.2.x in Groovy depends on broken libxxhash 0.7.x

[wdoekes]

How about this case:

- I make a hypothetical package that depends on libxxhash < 0.8 because
I want the "broken/old" xxh128 support;

- I have libxxhash 0.7.3 (that came with Focal);

- I have rsync 3.1.x (that came with Focal);

- Now I release-upgrade my system from Focal to Groovy;

- I get all kinds of new packages, including rsync 3.2.3;

- Dependency resolution fixes that I _don't_ get libxxhash 0.8 _because_
I have:

- (a) my hypothetical package pinned and it depends on libxxhash<0.8;

- (b) rsync that depends on libxxhash>=0.7.1.

- The dependencies are all still satisfied and I get to keep
libxxhash=0.7.3.

In this new situation I have completed the upgrade to Groovy. As long as
my hypothetical package that depends on libxxhash <0.8 exists, Ubuntu
will not upgrade libxxhash.

And then I'm in the same situation as I am now:


root@groovy-rsync:~# apt-mark hold hypothetical-pkg
hypothetical-pkg set on hold.

root@groovy-rsync:~# apt-cache show hypothetical-pkg | grep ^Depe
Depends: libxxhash0 (<= 0.8)

root@groovy-rsync:~# apt-get install rsync
Reading package lists... Done
Building dependency tree   
Reading state information... Done
Suggested packages:
  openssh-server
The following NEW packages will be installed:
  rsync

root@groovy-rsync:~# dpkg -l | grep -E 'rsync|libxxhash'
hi  hypothetical-pkg 1.0
ii  libxxhash0:amd64 0.7.3-1
ii  rsync3.2.3-2ubuntu1

root@groovy-rsync:~# apt-get dist-upgrade
Reading package lists... Done
Building dependency tree   
Reading state information... Done
Calculating upgrade... Done
The following packages have been kept back:
  libxxhash0
0 upgraded, 0 newly installed, 0 to remove and 1 not upgraded.


This may not be the commonest of cases. But this would be an impossible 
situation if rsync_3.2.3 simply depended on 0.8+ instead of on 0.7.1+. (An 
impossible situation is good in this case, because you have to choose between 
either hypothetical-pkg or rsync.)

So, I still feel that this is a bug in the rsync control file in Groovy.
Not a bug in the rsync source.

(Ok, in fact, I think it's ultimately a bug in soname-version/symbol
handling of libxxhash. But that's not where the problem manifests
itself.)

I'll leave it as is if you still feel it should be closed. But at least
it has some visibility/presence on the internet so others are helped if
they also run into this issue.

Cheers :)
Walter

** Changed in: rsync (Ubuntu)
   Status: Incomplete => New

-- 
You received this bug notification because you are a member of Ubuntu
Touch seeded packages, which is subscribed to rsync in Ubuntu.
https://bugs.launchpad.net/bugs/1934992

Title:
  rsync 3.2.x in Groovy depends on broken libxxhash 0.7.x

Status in rsync package in Ubuntu:
  New

Bug description:
  **Problem**

$ rsync root@focal-system:/etc/.pwd.lock . 
ERROR: .pwd.lock failed verification -- update discarded.
rsync error: some files/attrs were not transferred (see previous errors)
  (code 23) at main.c(1816) [generator=3.2.3]

  
$ rsync root@focal-system:/etc/.pwd.lock . --debug=all
opening connection using: ssh -l root focal-system rsync --server --sender \
  -e.LsfxCIvu . /etc/.pwd.lock  (10 args)
(Client) Protocol versions: remote=31, negotiated=31
Client negotiated checksum: xxh128
...

  
  **Cause**

focal-system# dpkg -l | grep -E 'libxxhash|rsync'
ii  libxxhash0:amd64  0.7.3-1 amd64
ii  rsync 3.2.3-2ubuntu1  amd64

  
  **Why this affects only us and not more people?**

  On Ubuntu/Focal, there is no rsync 3.2.3, only 3.1.3-8. But because we
  need the lz4 compression support we've fetched a newer rsync (from
  Groovy).

  However: the rsync 3.2.3 depends on libxxhash0 0.7.1+, while in fact
  it needs 0.8+.

  
  **Details**

  On a Ubuntu/Focal system we have installed a rsync 3.2.3 package from 
Ubuntu/Groovy because we need the lz4 compression support.

  
  focal-system# apt-cache show rsync
  Package: rsync
  ...
  Version: 3.2.3-2ubuntu1
  Depends: lsb-base, libacl1 (>= 2.2.23), libc6 (>= 2.15),
liblz4-1 (>= 0.0~r130), libpopt0 (>= 1.14), libssl1.1 (>= 1.1.0),
libxxhash0 (>= 0.7.1), libzstd1 (>= 1.3.8), zlib1g (>= 1:1.1.4)
  ...

  
  Alongside this we had libxxhash0 0.7.3-1 from Focal:

  focal-system# apt-cache policy libxxhash0
  libxxhash0:
Installed: 0.7.3-1
Candidate: 0.7.3-1
Version table:
   *** 0.7.3-1 500
  500 http://ARCHIVE/ubuntu focal/universe amd64 Packages
  100 /var/lib/dpkg/status

  
  According to the dependencies, this should work. But the combination does 
not, as this quote from the rsync maintainer would tell you:
  https://github.com/WayneD/rsync/issues/122#issuecomment-737690913
  > Yeah, Cyan4973 could have told you that the 128-bit xxhash only
  > just stabilized in its 0.8.0 release, so anything older than
  > that isn't compatible.

  
  **The fix**

  As the maintainer points 

[Touch-packages] [Bug 1935617] Re: systemd autopkgtest broken on ppc64el with qemu 6.0

[Dan Streetman]

> Unfortunately the ppc maas seems down right now

product engineering has access to PPC systems in maas?!? sigh...that
sure would be nice for sustaining engineering to have access to also :(

-- 
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/1935617

Title:
  systemd autopkgtest broken on ppc64el with qemu 6.0

Status in qemu package in Ubuntu:
  New
Status in systemd package in Ubuntu:
  New

Bug description:
  I'm not sure yet if this is flaky or a real issue, but I'm filing it
  to avoid multiple people analyzing the same.

  The Qemu 6.0 upload 
https://launchpad.net/ubuntu/+source/qemu/1:6.0+dfsg-1~ubuntu2 triggers a test 
failure like
  
https://autopkgtest.ubuntu.com/results/autopkgtest-impish/impish/ppc64el/s/systemd/20210708_223311_e3bbb@/log.gz

  I have tested the new qemu on ppc64 and it worked fine for device emulation 
and migration cases.
  But this is suspicious.
  Of the last tests exactly and only those with the new qemu failed.

  
  impish
ppc64el
  tests-in-lxd   (F  5% f  0% S  0% B  0% => P 95%/) 
F.F.
  systemd-fsckd  (F  0% f  0% S 100% B  0% => P  0%/) 

  upstream-1 (F 15% f  0% S  0% B  0% => P 85%/) 
F..F
  upstream-2 (F 12% f  0% S  0% B  0% => P 87%/) 
F...

  
  For an insight in flakyness/reproducibility I've retriggered the missing qemu 
and the non-qemu cases a few times. If those reproduce all-bad vs all-good 
again this would further indicate a real issue.

  Unfortunately the ppc maas seems down right now and canonistack also
  isn't too nice this week - overall that inhibits the testing a bit :-/

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/qemu/+bug/1935617/+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 1934439] Re: Add Ubuntu Pro banner to Livepatch page

[Sebastien Bacher]

Thanks Robert, I saw that you uploaded to bionic and focal now, any
reason to not merge to impish? If technically the feature doesn't apply
to the current serie maybe we should just merge with a default setting
to false so we just need to turn the option on for the next LTS if
needed?

-- 
You received this bug notification because you are a member of Ubuntu
Touch seeded packages, which is subscribed to software-properties in
Ubuntu.
https://bugs.launchpad.net/bugs/1934439

Title:
  Add Ubuntu Pro banner to Livepatch page

Status in software-properties package in Ubuntu:
  New
Status in software-properties source package in Xenial:
  New
Status in software-properties source package in Bionic:
  New
Status in software-properties source package in Focal:
  New

Bug description:
  [Impact]
  Add a banner to the Livepatch page to invite users to join the Ubuntu Pro for 
Desktop. Note that this is not shown in current releases, as this feature only 
applies to older versions.

  [Test Case]
  1. Open Software Properties.
  2. Go to Livepatch tab.
  Expected result:
  A banner is shown directing the user to Ubuntu Pro.
  The banner can be dismissed, and doesn't return when restarting 
software-properties.

  [Regression Potential]
  Some risk of introducing a new bug, however the change is quite small and 
doesn't have any complex interactions.

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/software-properties/+bug/1934439/+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 1934992] Re: rsync 3.2.x in Groovy depends on broken libxxhash 0.7.x

[Utkarsh Gupta]

Hello Walter,

Thanks for filling the bug and helping in making the Ubuntu server
better.

However, if I get everything right, I think you're mistaken about how it
works and I am sorry but what you're trying to do is not correct! You
cannot just decide to take one of the package from another release and
the other from another release. That is not how it works, I am afraid :/

If you do a fresh installation of rsync on Groovy, everything works
fine! See here:

$ lxc launch images:ubuntu/groovy groovy-rsync
$ lxc shell groovy-rsync
# apt update && apt install rsync
  ### here you'll see that the right version of libxxhash gets installed.
  (cf: `Setting up libxxhash0:amd64 (0.8.0-1ubuntu1.20.10.1) ...)
# ls -lah /usr/lib/x86_64-linux-gnu/libxxhash.so.0
lrwxrwxrwx 1 root root 18 Jan 12 11:17 /usr/lib/x86_64-linux-gnu/libxxhash.so.0 
-> libxxhash.so.0.8.0

...which is linked against the right version. Further libxxhash-
dev/0.8.0-1 is not in Focal but in Groovy, so the patch will not be
right to apply in Focal. That said, I agree that it'd have been nice to
have that version constraints but I don't see this as something that'd
cause problems unless somebody tries to do some sort of manual
intervention. :)

Given this, I am inclined towards believing that this is not really a
bug in rsync but a "local" issue (that is, manually installing a version
of rsync from Groovy to Focal and expecting it to work w/ libxxhash-
dev). So I am setting this to "Incomplete" for now, leaving some space
for discussion - in case I wrongly interpreted your problem and thus
this report.

But should you feel that it's still a bug, please set the status back to
"New" along with some reasoning (and hopefully a reproducer!) as to why
you think that it's indeed a bug rather than a local issue. Thank you,
again! \o/

** Changed in: rsync (Ubuntu)
   Status: New => Incomplete

-- 
You received this bug notification because you are a member of Ubuntu
Touch seeded packages, which is subscribed to rsync in Ubuntu.
https://bugs.launchpad.net/bugs/1934992

Title:
  rsync 3.2.x in Groovy depends on broken libxxhash 0.7.x

Status in rsync package in Ubuntu:
  Incomplete

Bug description:
  **Problem**

$ rsync root@focal-system:/etc/.pwd.lock . 
ERROR: .pwd.lock failed verification -- update discarded.
rsync error: some files/attrs were not transferred (see previous errors)
  (code 23) at main.c(1816) [generator=3.2.3]

  
$ rsync root@focal-system:/etc/.pwd.lock . --debug=all
opening connection using: ssh -l root focal-system rsync --server --sender \
  -e.LsfxCIvu . /etc/.pwd.lock  (10 args)
(Client) Protocol versions: remote=31, negotiated=31
Client negotiated checksum: xxh128
...

  
  **Cause**

focal-system# dpkg -l | grep -E 'libxxhash|rsync'
ii  libxxhash0:amd64  0.7.3-1 amd64
ii  rsync 3.2.3-2ubuntu1  amd64

  
  **Why this affects only us and not more people?**

  On Ubuntu/Focal, there is no rsync 3.2.3, only 3.1.3-8. But because we
  need the lz4 compression support we've fetched a newer rsync (from
  Groovy).

  However: the rsync 3.2.3 depends on libxxhash0 0.7.1+, while in fact
  it needs 0.8+.

  
  **Details**

  On a Ubuntu/Focal system we have installed a rsync 3.2.3 package from 
Ubuntu/Groovy because we need the lz4 compression support.

  
  focal-system# apt-cache show rsync
  Package: rsync
  ...
  Version: 3.2.3-2ubuntu1
  Depends: lsb-base, libacl1 (>= 2.2.23), libc6 (>= 2.15),
liblz4-1 (>= 0.0~r130), libpopt0 (>= 1.14), libssl1.1 (>= 1.1.0),
libxxhash0 (>= 0.7.1), libzstd1 (>= 1.3.8), zlib1g (>= 1:1.1.4)
  ...

  
  Alongside this we had libxxhash0 0.7.3-1 from Focal:

  focal-system# apt-cache policy libxxhash0
  libxxhash0:
Installed: 0.7.3-1
Candidate: 0.7.3-1
Version table:
   *** 0.7.3-1 500
  500 http://ARCHIVE/ubuntu focal/universe amd64 Packages
  100 /var/lib/dpkg/status

  
  According to the dependencies, this should work. But the combination does 
not, as this quote from the rsync maintainer would tell you:
  https://github.com/WayneD/rsync/issues/122#issuecomment-737690913
  > Yeah, Cyan4973 could have told you that the 128-bit xxhash only
  > just stabilized in its 0.8.0 release, so anything older than
  > that isn't compatible.

  
  **The fix**

  As the maintainer points out, version 0.7 is not stable (= broken for
  our intents and purposes) and thus not fit for use with rsync 3.2.

  I would argue that it's a good idea to bump the dependency of rsync
  3.2.3 on Groovy to libxxhash0>=0.8

  After all, in Groovy there is a libxxhash0 0.8.0-1ubuntu1.20.10.1, so
  that would not be a problem. And it would fix issues for those mixing
  and matching packages.

  
  Thanks!

  Walter Doekes
  OSSO B.V.

  
  (*) possible patch:

  $ diff -pu debian/control{.orig,}
  --- debian/control.orig   2021-07-08 09:56:57.646861644 +0200
  +++ debian/control2021-07-08 09:57:38.499029903 +0200

[Touch-packages] [Bug 1892108] Re: ping prints ip address octets backwards on host redirect

[Silvan Diem]

Please fix it asap.
We have the same issue. We have migrated our Nagios to Ubuntu 20.04. Now we 
have flapping hosts, because of this issue!

Is there a timeline when you will able to fix it ?

Thanks

Silvan

-- 
You received this bug notification because you are a member of Ubuntu
Touch seeded packages, which is subscribed to iputils in Ubuntu.
https://bugs.launchpad.net/bugs/1892108

Title:
  ping prints ip address octets backwards on host redirect

Status in iputils package in Ubuntu:
  Confirmed

Bug description:
  Description:  Ubuntu 20.04.1 LTS
  Release:  20.04

  Just noticed a weird thing with ping on Ubuntu 20.04, which I recently
  updated to.

  This is what I get when pinging a host on my network:

  user@ubuntu2004:~$ ping 10.156.0.63
  PING 10.156.0.63 (10.156.0.63) 56(84) bytes of data.
  From 10.15.0.1 icmp_seq=2 Redirect Host(New nexthop: 2.0.15.10)

  The ubuntu2004 machine is located in the 10.15.0.x network.
  10.15.0.1 is a DSL router.
  10.15.0.2 is a firewall between multiple networks.
  10.156.0.63 is a machine on a different local network.

  All traffic not destined for the internet is routed from 10.15.0.1 to
  10.15.0.2, so I would expect the printout to read "New nexthop:
  10.15.0.2".

  However, as you can see this is not the case. Instead the octets are
  printed in reverse order.

  To verify this I tried the same on another machine in the same
  network, running Ubuntu 18.04:

  user@ubuntu1804:~$ ping 10.156.0.63
  PING 10.156.0.63 (10.156.0.63) 56(84) bytes of data.
  From 10.15.0.1: icmp_seq=2 Redirect Host(New nexthop: 10.15.0.2)

  As you can see, the printout is correct here: "New nexthop: 10.15.0.2"

  I further verified the discrepancy by using tcpdump to interpret the
  ICMP packets on the ubuntu2004 machine, and there seems to be no
  problem for tcpdump to display the correct IP address.

  My assumption is that there is something wrong in the print function
  which displays the IP address for a host redirect.

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/iputils/+bug/1892108/+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 1934992] Re: rsync 3.2.x in Groovy depends on broken libxxhash 0.7.x

[wdoekes]

Hi Wayne! Thanks for commenting.

> It's only the 128-bit hash that depends on 0.8.0.
> The 0.7 version works fine with rsync, giving it
> the 64-bit and 32-bit hashes.

Yes. Except it seems that if you switch the libxxhash0 from 0.8 to 0.7,
you get different behaviour.

rsync doesn't check what kind of xxh128 is produced, so we end up with a
mismatch.

Steps to reproduce:

  wget -q
https://launchpad.net/ubuntu/+archive/primary/+files/rsync_3.2.3-2ubuntu1_amd64.deb

  wget -q
https://launchpad.net/ubuntu/+archive/primary/+files/libxxhash0_0.7.3-1_amd64.deb

  wget -q
https://launchpad.net/ubuntu/+archive/primary/+files/libxxhash0_0.8.0-1ubuntu1.20.10.1_amd64.deb

focal-node-1:

  sudo dpkg -i libxxhash0_0.7.3-1_amd64.deb \
rsync_3.2.3-2ubuntu1_amd64.deb
  touch empty-file.txt
  echo A > non-empty-file.txt

focal-node-2:

  sudo dpkg -i rsync_3.2.3-2ubuntu1_amd64.deb \
libxxhash0_0.8.0-1ubuntu1.20.10.1_amd64.deb
  rsync -v --debug=nstr \
focal-node-1:*empty-file.txt \
.

Result:

  Client negotiated checksum: xxh128
  empty-file.txt
  WARNING: empty-file.txt failed verification
-- update discarded (will try again).
  non-empty-file.txt
  WARNING: non-empty-file.txt failed verification
-- update discarded (will try again).
  empty-file.txt
  ERROR: empty-file.txt failed verification
-- update discarded.
  non-empty-file.txt
  ERROR: non-empty-file.txt failed verification
-- update discarded.

  sent 104 bytes  received 255 bytes  239.33 bytes/sec
  total size is 2  speedup is 0.01
  rsync error: some files/attrs were not transferred
(see previous errors) (code 23) at main.c(1816)
[generator=3.2.3]


focal-node-2:

  $ ls *empty*
  ls: cannot access '*empty*': No such file or directory


I don't mind if I don't get xxh128 and get some poorer hash. But I _do_ mind if 
I get a hash that produces different results.

If I install libxxhash0 0.7.3 on both: things work.

If I install libxxhash0 0.8.x on both: things work.

But when there is a mismatch, things break. And uselessly too. I ended
up syncing lots of GBs multiple times because our job kept retrying.

I hope that clarifies the situation.

Walter

P.S. Alternative solutions could be:
- not exporting xxh128 functions from libxxhash0 0.7.3 (but it might be a bit 
late for that);
- checking that xxh128 produces sane values in rsync before choosing that 
option.

-- 
You received this bug notification because you are a member of Ubuntu
Touch seeded packages, which is subscribed to rsync in Ubuntu.
https://bugs.launchpad.net/bugs/1934992

Title:
  rsync 3.2.x in Groovy depends on broken libxxhash 0.7.x

Status in rsync package in Ubuntu:
  New

Bug description:
  **Problem**

$ rsync root@focal-system:/etc/.pwd.lock . 
ERROR: .pwd.lock failed verification -- update discarded.
rsync error: some files/attrs were not transferred (see previous errors)
  (code 23) at main.c(1816) [generator=3.2.3]

  
$ rsync root@focal-system:/etc/.pwd.lock . --debug=all
opening connection using: ssh -l root focal-system rsync --server --sender \
  -e.LsfxCIvu . /etc/.pwd.lock  (10 args)
(Client) Protocol versions: remote=31, negotiated=31
Client negotiated checksum: xxh128
...

  
  **Cause**

focal-system# dpkg -l | grep -E 'libxxhash|rsync'
ii  libxxhash0:amd64  0.7.3-1 amd64
ii  rsync 3.2.3-2ubuntu1  amd64

  
  **Why this affects only us and not more people?**

  On Ubuntu/Focal, there is no rsync 3.2.3, only 3.1.3-8. But because we
  need the lz4 compression support we've fetched a newer rsync (from
  Groovy).

  However: the rsync 3.2.3 depends on libxxhash0 0.7.1+, while in fact
  it needs 0.8+.

  
  **Details**

  On a Ubuntu/Focal system we have installed a rsync 3.2.3 package from 
Ubuntu/Groovy because we need the lz4 compression support.

  
  focal-system# apt-cache show rsync
  Package: rsync
  ...
  Version: 3.2.3-2ubuntu1
  Depends: lsb-base, libacl1 (>= 2.2.23), libc6 (>= 2.15),
liblz4-1 (>= 0.0~r130), libpopt0 (>= 1.14), libssl1.1 (>= 1.1.0),
libxxhash0 (>= 0.7.1), libzstd1 (>= 1.3.8), zlib1g (>= 1:1.1.4)
  ...

  
  Alongside this we had libxxhash0 0.7.3-1 from Focal:

  focal-system# apt-cache policy libxxhash0
  libxxhash0:
Installed: 0.7.3-1
Candidate: 0.7.3-1
Version table:
   *** 0.7.3-1 500
  500 http://ARCHIVE/ubuntu focal/universe amd64 Packages
  100 /var/lib/dpkg/status

  
  According to the dependencies, this should work. But the combination does 
not, as this quote from the rsync maintainer would tell you:
  https://github.com/WayneD/rsync/issues/122#issuecomment-737690913
  > Yeah, Cyan4973 could have told you that the 128-bit xxhash only
  > just stabilized in its 0.8.0 release, so anything older than
  > that isn't compatible.

  
  **The fix**

  As the maintainer points out, version 0.7 is not stable (= broken for
  our intents and purposes) and thus not fit for use with rsync 3.2.

  I would 

[Touch-packages] [Bug 1928200] Re: Prompt error message "Failed to unmount /oldroot" when shutdown or reboot

[Bin Li]

Upgraded to systemd 245.4-4ubuntu3.8 on ThinkPad P17, but this issue is
still exist.

-- 
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/1928200

Title:
  Prompt error message "Failed to unmount /oldroot" when shutdown or
  reboot

Status in OEM Priority Project:
  Confirmed
Status in systemd package in Ubuntu:
  Fix Released
Status in systemd source package in Focal:
  Fix Committed

Bug description:
  [impact]

  root fs is not cleanly unmounted on shutdown

  [test case]

  create a file in /etc/binfmt.d/TestFormat.conf with the following
  content:

  :TestFormat:M::XX::/bin/true:F

  reboot the system, and then shutdown or reboot again, and watch the
  serial console for the error message:

  sd-umount[1334]: Failed to unmount /oldroot: Device or resource busy

  [regression potential]

  any regression would likely cause problems on shutdown and/or reboot,
  or may cause problems with unmounted root fs on shutdown/reboot

  [scope]

  this is needed only for f

  this is fixed upstream with PR 15566 which is included in v246, so
  this is fixed already in g and later

  this isn't reproducable on b

  [original description]

  On ubuntu 20.04, with latest kernel and systemd, it will show error on
  ThinkPad X1.

  sd-umount[1334]: Failed to unmount /oldroot: Device or resource busy

  systemd 245.4-4ubuntu3.6
  kernel: 5.8.0-53

To manage notifications about this bug go to:
https://bugs.launchpad.net/oem-priority/+bug/1928200/+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 1934995] Re: Broken on ppc64el (toolchain bug?)

[Chris Halse Rogers]

Next possible culprit: binutils

-- 
You received this bug notification because you are a member of Ubuntu
Touch seeded packages, which is subscribed to umockdev in Ubuntu.
https://bugs.launchpad.net/bugs/1934995

Title:
  Broken on ppc64el (toolchain bug?)

Status in umockdev package in Ubuntu:
  New

Bug description:
  umockdev appears to be broken on ppc64el in impish. Running it on one
  of Mir's umockdev-using tests results in:

  (impish-ppc64el)root@juju-deb017-porterbox-1:/build/mir-Xn1VqE/umockdev# 
umockdev-run ../mir-2.4.1/build-ppc64el/bin/mir_umock_unit_tests
  MIR_CLIENT_PLATFORM_PATH=../mir-2.4.1/build-ppc64el/bin/../lib/client-modules/
  MIR_SERVER_PLATFORM_PATH=../mir-2.4.1/build-ppc64el/bin/../lib/server-modules/
  LD_LIBRARY_PATH=../mir-2.4.1/build-ppc64el/bin/../lib
  exec=../mir-2.4.1/build-ppc64el/bin/mir_umock_unit_tests.bin
  *** stack smashing detected ***: terminated
  umockdev-run: unable to propagate signal 6 to child 15833: No such process

  (You can also see this in the Mir 2.4.1-0ubuntu1 build log:
  https://launchpadlibrarian.net/546972958/buildlog_ubuntu-impish-
  ppc64el.mir_2.4.1-0ubuntu1_BUILDING.txt.gz )

  Installing umockdev 0.15.4-1 and libumockdev0 0.15.4-1 from hirsute
  results in those tests passing.

  Strangely, rebuilding umockdev 0.15.4-1 in a hirsute sbuild
  environment results in packages that do *not* pass those tests,
  suggesting a toolchain change might be responsible.

  Unfortunately, I've tried rebuilding umockdev with gcc-9, gcc-11, and
  vala 0.48.12-1 in Impish and none of these appear to work.

  ProblemType: Bug
  DistroRelease: Ubuntu 21.10
  Package: umockdev 0.16.1-1
  ProcVersionSignature: Ubuntu 5.11.0-20.21+21.10.1-generic 5.11.21
  Uname: Linux 5.11.0-20-generic x86_64
  NonfreeKernelModules: zfs zunicode zavl icp zcommon znvpair
  ApportVersion: 2.20.11-0ubuntu67
  Architecture: amd64
  CasperMD5CheckResult: pass
  CurrentDesktop: ubuntu:GNOME
  Date: Thu Jul  8 16:04:15 2021
  InstallationDate: Installed on 2021-06-26 (11 days ago)
  InstallationMedia: Ubuntu 21.10.0 2021.05.28 amd64 "bcachefs" (20210622)
  SourcePackage: umockdev
  UpgradeStatus: No upgrade log present (probably fresh install)

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/umockdev/+bug/1934995/+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 1935656] [NEW] Please switch to fuse3

[Graham Inggs]

Public bug reported:

Fuse3 is a requirement for qemu 6 (LP: #1934510).  Since we don't want
to support two versions of fuse in main, we'd like reverse-dependencies
of fuse to switch to fuse3.

e2fsprogs FTBFS in a test rebuild changing the build-dependency on
libfuse-dev to libfuse3-dev.

Excerpt from the build log:

checking for fuse.h... no

** Affects: e2fsprogs (Ubuntu)
 Importance: Undecided
 Status: New


** Tags: rls-ii-incoming

-- 
You received this bug notification because you are a member of Ubuntu
Touch seeded packages, which is subscribed to e2fsprogs in Ubuntu.
https://bugs.launchpad.net/bugs/1935656

Title:
  Please switch to fuse3

Status in e2fsprogs package in Ubuntu:
  New

Bug description:
  Fuse3 is a requirement for qemu 6 (LP: #1934510).  Since we don't want
  to support two versions of fuse in main, we'd like reverse-
  dependencies of fuse to switch to fuse3.

  e2fsprogs FTBFS in a test rebuild changing the build-dependency on
  libfuse-dev to libfuse3-dev.

  Excerpt from the build log:

  checking for fuse.h... no

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/e2fsprogs/+bug/1935656/+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 1905285] Re: socket-activated sshd breaks on concurrent connections

[Launchpad Bug Tracker]

This bug was fixed in the package openssh - 1:8.4p1-5ubuntu2

---
openssh (1:8.4p1-5ubuntu2) impish; urgency=medium

  * d/systemd/ssh@.service: preserve the systemd managed runtime directory to
ensure parallel processes will not disrupt one another when halting
(LP: #1905285) (closes: #934663)

 -- Athos Ribeiro   Mon, 05 Jul 2021
09:21:03 -0300

** Changed in: openssh (Ubuntu)
   Status: Triaged => Fix Released

-- 
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/1905285

Title:
  socket-activated sshd breaks on concurrent connections

Status in openssh package in Ubuntu:
  Fix Released

Bug description:
  This is mostly the same issue as https://bugs.debian.org/cgi-
  bin/bugreport.cgi?bug=934663.

  With the default configuration of openssh-server and systemd, sshd
  will complain and crash when multiple connections are made and
  terminated in a quick succession, e.g. with `ssh-keyscan`. It results
  in the following errors in /var/log/auth.log:

  ```
  Nov 22 20:53:34 {host} sshd[14567]: Unable to negotiate with {client} port 
41460: no matching host key type found. Their offer: 
sk-ecdsa-sha2-nistp...@openssh.com [preauth]
  Nov 22 20:53:34 {host} sshd[14570]: fatal: chroot("/run/sshd"): No such file 
or directory [preauth]
  Nov 22 20:53:34 {host} sshd[14569]: fatal: chroot("/run/sshd"): No such file 
or directory [preauth]
  Nov 22 20:53:34 {host} sshd[14568]: fatal: chroot("/run/sshd"): No such file 
or directory [preauth]
  Nov 22 20:53:34 {host} sshd[14566]: fatal: chroot("/run/sshd"): No such file 
or directory [preauth]
  Nov 22 20:53:47 {host} sshd[14584]: Connection closed by {client} port 59312 
[preauth]
  Nov 22 20:53:47 {host} sshd[14586]: fatal: chroot("/run/sshd"): No such file 
or directory [preauth]
  Nov 22 20:53:48 {host} sshd[14585]: fatal: chroot("/run/sshd"): No such file 
or directory [preauth]
  ```

  as well as e.g. missing responses in ssh-keyscan:

  ```
  $ ssh-keyscan -vvv {host}
  debug2: fd 3 setting O_NONBLOCK
  debug3: conalloc: oname {host} kt 2
  debug2: fd 4 setting O_NONBLOCK
  debug3: conalloc: oname {host} kt 4
  debug2: fd 5 setting O_NONBLOCK
  debug3: conalloc: oname {host} kt 8
  debug2: fd 6 setting O_NONBLOCK
  debug3: conalloc: oname {host} kt 32
  debug2: fd 7 setting O_NONBLOCK
  debug3: conalloc: oname {host} kt 64
  debug1: match: OpenSSH_8.2p1 Ubuntu-4ubuntu0.1 pat OpenSSH* compat 0x0400
  # {host}:22 SSH-2.0-OpenSSH_8.2p1 Ubuntu-4ubuntu0.1
  debug3: send packet: type 20
  debug1: SSH2_MSG_KEXINIT sent
  debug3: receive packet: type 20
  debug1: SSH2_MSG_KEXINIT received
  debug2: local client KEXINIT proposal
  debug2: KEX algorithms: 
curve25519-sha256,curve25519-sha...@libssh.org,ecdh-sha2-nistp256,ecdh-sha2-nistp384,ecdh-sha2-nistp521,diffie-hellman-group-exchange-sha256,diffie-hellman-group16-sha512,diffie-hellman-group18-sha512,diffie-hellman-group14-sha256
  debug2: host key algorithms: sk-ecdsa-sha2-nistp...@openssh.com
  debug2: ciphers ctos: 
chacha20-poly1...@openssh.com,aes128-ctr,aes192-ctr,aes256-ctr,aes128-...@openssh.com,aes256-...@openssh.com
  debug2: ciphers stoc: 
chacha20-poly1...@openssh.com,aes128-ctr,aes192-ctr,aes256-ctr,aes128-...@openssh.com,aes256-...@openssh.com
  debug2: MACs ctos: 
umac-64-...@openssh.com,umac-128-...@openssh.com,hmac-sha2-256-...@openssh.com,hmac-sha2-512-...@openssh.com,hmac-sha1-...@openssh.com,umac...@openssh.com,umac-...@openssh.com,hmac-sha2-256,hmac-sha2-512,hmac-sha1
  debug2: MACs stoc: 
umac-64-...@openssh.com,umac-128-...@openssh.com,hmac-sha2-256-...@openssh.com,hmac-sha2-512-...@openssh.com,hmac-sha1-...@openssh.com,umac...@openssh.com,umac-...@openssh.com,hmac-sha2-256,hmac-sha2-512,hmac-sha1
  debug2: compression ctos: none,z...@openssh.com
  debug2: compression stoc: none,z...@openssh.com
  debug2: languages ctos:
  debug2: languages stoc:
  debug2: first_kex_follows 0
  debug2: reserved 0
  debug2: peer server KEXINIT proposal
  debug2: KEX algorithms: 
curve25519-sha256,curve25519-sha...@libssh.org,ecdh-sha2-nistp256,ecdh-sha2-nistp384,ecdh-sha2-nistp521,diffie-hellman-group-exchange-sha256,diffie-hellman-group16-sha512,diffie-hellman-group18-sha512,diffie-hellman-group14-sha256,diffie-hellman-group14-sha1
  debug2: host key algorithms: 
rsa-sha2-512,rsa-sha2-256,ssh-rsa,ecdsa-sha2-nistp256,ssh-ed25519
  debug2: ciphers ctos: 
chacha20-poly1...@openssh.com,aes128-ctr,aes192-ctr,aes256-ctr,aes128-...@openssh.com,aes256-...@openssh.com
  debug2: ciphers stoc: 
chacha20-poly1...@openssh.com,aes128-ctr,aes192-ctr,aes256-ctr,aes128-...@openssh.com,aes256-...@openssh.com
  debug2: MACs ctos: 
umac-64-...@openssh.com,umac-128-...@openssh.com,hmac-sha2-256-...@openssh.com,hmac-sha2-512-...@openssh.com,hmac-sha1-...@openssh.com,umac...@openssh.com,umac-...@openssh.com,hmac-sha2-256,hmac-sha2-512,hmac-sha1
  debug2: MACs stoc: 

Re: [Touch-packages] [Bug 1918458] Re: [Swift SF515-51T, Realtek ALC256, Grey Speaker, Internal] Playback problem, no sound from speakers, headphones ok

[Thibaut Soubrié]

Hello Hui Wang,

Just ran these commands, still no sound out of the speakers on my side.
Best Regards,

Thibaut Soubrié

Le ven. 9 juil. 2021 à 09:25, Hui Wang <1918...@bugs.launchpad.net> a
écrit :

> Please test this command:
>
> sudo hda-verb /dev/snd/hwC0D0 0x20 SET_COEF_INDEX 0x10
> sudo hda-verb /dev/snd/hwC0D0 0x20 SET_PROC_COEF 0x0e20
> //please test if speaker works.
>
> --
> You received this bug notification because you are subscribed to the bug
> report.
> https://bugs.launchpad.net/bugs/1918458
>
> Title:
>   [Swift SF515-51T, Realtek ALC256, Grey Speaker, Internal] Playback
>   problem, no sound from speakers, headphones ok
>
> Status in alsa-driver package in Ubuntu:
>   Confirmed
>
> Bug description:
>   Expect : sound from speaker
>   Instead, obtain : no sound.
>
>
>   Tried various configuration of /etc/modprobe.d/alsa-conf with :
>
>   options snd-hda-intel model= and
>   options snd-intel-dspcfg dsp_driver=3 or 1
>   and systematic reboot.
>
>   Either I get dummy output, or I get proper output detection, alsamixer
>   and pavucontrol seems 100% ok, but no sound comes from the speakers.
>
>   I'm under a dualboot with Windows 10, BIOS fast boot disabled.
>   Ubuntu 20.04.2 LTS
>
>   ProblemType: Bug
>   DistroRelease: Ubuntu 20.04
>   Package: alsa-base 1.0.25+dfsg-0ubuntu5
>   ProcVersionSignature: Ubuntu 5.8.0-44.50~20.04.1-generic 5.8.18
>   Uname: Linux 5.8.0-44-generic x86_64
>   ApportVersion: 2.20.11-0ubuntu27.16
>   Architecture: amd64
>   AudioDevicesInUse:
>USERPID ACCESS COMMAND
>/dev/snd/controlC0:  thibauts   1522 F pulseaudio
>/dev/snd/pcmC0D0p:   thibauts   1522 F...m pulseaudio
>   CasperMD5CheckResult: skip
>   CurrentDesktop: ubuntu:GNOME
>   Date: Wed Mar 10 18:10:30 2021
>   InstallationDate: Installed on 2021-03-09 (1 days ago)
>   InstallationMedia: Ubuntu 20.04.2.0 LTS "Focal Fossa" - Release amd64
> (20210209.1)
>   PackageArchitecture: all
>   SourcePackage: alsa-driver
>   Symptom: audio
>   Symptom_AlsaPlaybackTest: ALSA playback test through plughw:sofhdadsp
> failed
>   Symptom_Card: Cannon Point-LP High Definition Audio Controller -
> sof-hda-dsp
>   Symptom_Jack: Grey Speaker, Internal
>   Symptom_Type: Only some of outputs are working
>   Title: [Swift SF515-51T, Realtek ALC256, Grey Speaker, Internal]
> Playback problem
>   UpgradeStatus: No upgrade log present (probably fresh install)
>   dmi.bios.date: 05/24/2019
>   dmi.bios.release: 1.4
>   dmi.bios.vendor: American Megatrends Inc.
>   dmi.bios.version: V1.04
>   dmi.board.asset.tag: Default string
>   dmi.board.name: Guinness_WL
>   dmi.board.vendor: WL
>   dmi.board.version: V1.04
>   dmi.chassis.type: 10
>   dmi.chassis.vendor: Acer
>   dmi.chassis.version: V1.04
>   dmi.ec.firmware.release: 1.6
>   dmi.modalias:
> dmi:bvnAmericanMegatrendsInc.:bvrV1.04:bd05/24/2019:br1.4:efr1.6:svnAcer:pnSwiftSF515-51T:pvrV1.04:rvnWL:rnGuinness_WL:rvrV1.04:cvnAcer:ct10:cvrV1.04:
>   dmi.product.family: Swift 5
>   dmi.product.name: Swift SF515-51T
>   dmi.product.sku: 
>   dmi.product.version: V1.04
>   dmi.sys.vendor: Acer
>   mtime.conffile..etc.modprobe.d.alsa-base.conf: 2021-03-10T18:04:19.277254
>
> To manage notifications about this bug go to:
>
> https://bugs.launchpad.net/ubuntu/+source/alsa-driver/+bug/1918458/+subscriptions
>

-- 
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/1918458

Title:
  [Swift SF515-51T, Realtek ALC256, Grey Speaker, Internal] Playback
  problem, no sound from speakers, headphones ok

Status in alsa-driver package in Ubuntu:
  Confirmed

Bug description:
  Expect : sound from speaker
  Instead, obtain : no sound.

  
  Tried various configuration of /etc/modprobe.d/alsa-conf with :

  options snd-hda-intel model= and
  options snd-intel-dspcfg dsp_driver=3 or 1
  and systematic reboot.

  Either I get dummy output, or I get proper output detection, alsamixer
  and pavucontrol seems 100% ok, but no sound comes from the speakers.

  I'm under a dualboot with Windows 10, BIOS fast boot disabled.
  Ubuntu 20.04.2 LTS

  ProblemType: Bug
  DistroRelease: Ubuntu 20.04
  Package: alsa-base 1.0.25+dfsg-0ubuntu5
  ProcVersionSignature: Ubuntu 5.8.0-44.50~20.04.1-generic 5.8.18
  Uname: Linux 5.8.0-44-generic x86_64
  ApportVersion: 2.20.11-0ubuntu27.16
  Architecture: amd64
  AudioDevicesInUse:
   USERPID ACCESS COMMAND
   /dev/snd/controlC0:  thibauts   1522 F pulseaudio
   /dev/snd/pcmC0D0p:   thibauts   1522 F...m pulseaudio
  CasperMD5CheckResult: skip
  CurrentDesktop: ubuntu:GNOME
  Date: Wed Mar 10 18:10:30 2021
  InstallationDate: Installed on 2021-03-09 (1 days ago)
  InstallationMedia: Ubuntu 20.04.2.0 LTS "Focal Fossa" - Release amd64 
(20210209.1)
  PackageArchitecture: all
  SourcePackage: alsa-driver
  Symptom: audio
  Symptom_AlsaPlaybackTest: ALSA playback test through plughw:sofhdadsp 

[Touch-packages] [Bug 1918458] Re: [Swift SF515-51T, Realtek ALC256, Grey Speaker, Internal] Playback problem, no sound from speakers, headphones ok

[Hui Wang]

Please test this command:

sudo hda-verb /dev/snd/hwC0D0 0x20 SET_COEF_INDEX 0x10
sudo hda-verb /dev/snd/hwC0D0 0x20 SET_PROC_COEF 0x0e20
//please test if speaker works.

-- 
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/1918458

Title:
  [Swift SF515-51T, Realtek ALC256, Grey Speaker, Internal] Playback
  problem, no sound from speakers, headphones ok

Status in alsa-driver package in Ubuntu:
  Confirmed

Bug description:
  Expect : sound from speaker
  Instead, obtain : no sound.

  
  Tried various configuration of /etc/modprobe.d/alsa-conf with :

  options snd-hda-intel model= and
  options snd-intel-dspcfg dsp_driver=3 or 1
  and systematic reboot.

  Either I get dummy output, or I get proper output detection, alsamixer
  and pavucontrol seems 100% ok, but no sound comes from the speakers.

  I'm under a dualboot with Windows 10, BIOS fast boot disabled.
  Ubuntu 20.04.2 LTS

  ProblemType: Bug
  DistroRelease: Ubuntu 20.04
  Package: alsa-base 1.0.25+dfsg-0ubuntu5
  ProcVersionSignature: Ubuntu 5.8.0-44.50~20.04.1-generic 5.8.18
  Uname: Linux 5.8.0-44-generic x86_64
  ApportVersion: 2.20.11-0ubuntu27.16
  Architecture: amd64
  AudioDevicesInUse:
   USERPID ACCESS COMMAND
   /dev/snd/controlC0:  thibauts   1522 F pulseaudio
   /dev/snd/pcmC0D0p:   thibauts   1522 F...m pulseaudio
  CasperMD5CheckResult: skip
  CurrentDesktop: ubuntu:GNOME
  Date: Wed Mar 10 18:10:30 2021
  InstallationDate: Installed on 2021-03-09 (1 days ago)
  InstallationMedia: Ubuntu 20.04.2.0 LTS "Focal Fossa" - Release amd64 
(20210209.1)
  PackageArchitecture: all
  SourcePackage: alsa-driver
  Symptom: audio
  Symptom_AlsaPlaybackTest: ALSA playback test through plughw:sofhdadsp failed
  Symptom_Card: Cannon Point-LP High Definition Audio Controller - sof-hda-dsp
  Symptom_Jack: Grey Speaker, Internal
  Symptom_Type: Only some of outputs are working
  Title: [Swift SF515-51T, Realtek ALC256, Grey Speaker, Internal] Playback 
problem
  UpgradeStatus: No upgrade log present (probably fresh install)
  dmi.bios.date: 05/24/2019
  dmi.bios.release: 1.4
  dmi.bios.vendor: American Megatrends Inc.
  dmi.bios.version: V1.04
  dmi.board.asset.tag: Default string
  dmi.board.name: Guinness_WL
  dmi.board.vendor: WL
  dmi.board.version: V1.04
  dmi.chassis.type: 10
  dmi.chassis.vendor: Acer
  dmi.chassis.version: V1.04
  dmi.ec.firmware.release: 1.6
  dmi.modalias: 
dmi:bvnAmericanMegatrendsInc.:bvrV1.04:bd05/24/2019:br1.4:efr1.6:svnAcer:pnSwiftSF515-51T:pvrV1.04:rvnWL:rnGuinness_WL:rvrV1.04:cvnAcer:ct10:cvrV1.04:
  dmi.product.family: Swift 5
  dmi.product.name: Swift SF515-51T
  dmi.product.sku: 
  dmi.product.version: V1.04
  dmi.sys.vendor: Acer
  mtime.conffile..etc.modprobe.d.alsa-base.conf: 2021-03-10T18:04:19.277254

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/alsa-driver/+bug/1918458/+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 1935617] Re: systemd autopkgtest broken on ppc64el with qemu 6.0

[Christian Ehrhardt ]

My Repro-tests indeed seem to indicate that really qemu 6.0 is the trigger for 
this,
but as I said HW is rather unavailable at the moment. I was told that the MAAS 
is serviced but should be back soon - so I'll have a look later when this one 
is available again.

-- 
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/1935617

Title:
  systemd autopkgtest broken on ppc64el with qemu 6.0

Status in qemu package in Ubuntu:
  New
Status in systemd package in Ubuntu:
  New

Bug description:
  I'm not sure yet if this is flaky or a real issue, but I'm filing it
  to avoid multiple people analyzing the same.

  The Qemu 6.0 upload 
https://launchpad.net/ubuntu/+source/qemu/1:6.0+dfsg-1~ubuntu2 triggers a test 
failure like
  
https://autopkgtest.ubuntu.com/results/autopkgtest-impish/impish/ppc64el/s/systemd/20210708_223311_e3bbb@/log.gz

  I have tested the new qemu on ppc64 and it worked fine for device emulation 
and migration cases.
  But this is suspicious.
  Of the last tests exactly and only those with the new qemu failed.

  
  impish
ppc64el
  tests-in-lxd   (F  5% f  0% S  0% B  0% => P 95%/) 
F.F.
  systemd-fsckd  (F  0% f  0% S 100% B  0% => P  0%/) 

  upstream-1 (F 15% f  0% S  0% B  0% => P 85%/) 
F..F
  upstream-2 (F 12% f  0% S  0% B  0% => P 87%/) 
F...

  
  For an insight in flakyness/reproducibility I've retriggered the missing qemu 
and the non-qemu cases a few times. If those reproduce all-bad vs all-good 
again this would further indicate a real issue.

  Unfortunately the ppc maas seems down right now and canonistack also
  isn't too nice this week - overall that inhibits the testing a bit :-/

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/qemu/+bug/1935617/+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