[Touch-packages] [Bug 1944741] Re: HiFive Unmatched partitions are named "Unleashed"

2021-09-24 Thread Mathew Hodson
** Changed in: util-linux (Ubuntu)
   Importance: Undecided => Low

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

Title:
  HiFive Unmatched partitions are named "Unleashed"

Status in util-linux package in Ubuntu:
  New
Status in util-linux package in Debian:
  New

Bug description:
  Both HiFive Unleashed and HiFive Unmatched bootloaders seek for the same
  UUIDs to load the next stage bootloader: the current name makes partitions
  on Unmatched board appear as 'Unleashed'.
  
  Fix that by removing the 'Unleashed' part of the current name so that it
  fits both.

  The attached debdiff contains the patch that was merged upstream
  (https://github.com/karelzak/util-
  linux/commit/10fd91d389497d8be435cc66abbdeb2eb6ea2f07).

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/util-linux/+bug/1944741/+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 1944621] Re: sshd in chroot has regression with glibc 2.34

2021-09-24 Thread Mathew Hodson
** Changed in: openssh (Ubuntu)
   Importance: Undecided => Medium

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

Title:
  sshd in chroot has regression with glibc 2.34

Status in openssh package in Ubuntu:
  Confirmed

Bug description:
  A regression to sshd running in a chroot exists under the following
  conditions:

  1) sshd was built with glibc 2.34
  2) sshd is running with a kernel that does not define the close_range syscall 
(kernel <= 5.8)
  3) /proc/self/fd does not exist in the chroot

  The glibc 2.34 implementation of fallback_closefrom fails if
  /proc/self/fd is not present, which is a valid sshd use case.

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/openssh/+bug/1944621/+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 1929854] Re: Vital and critical configuration files get overridden by system updates without warning

2021-09-24 Thread Launchpad Bug Tracker
[Expired for openssh (Ubuntu) because there has been no activity for 60
days.]

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

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

Title:
  Vital and critical configuration files get overridden by system
  updates without warning

Status in grub2 package in Ubuntu:
  Invalid
Status in libx11 package in Ubuntu:
  Invalid
Status in openssh package in Ubuntu:
  Expired

Bug description:
  • In my /usr/share/X11/locale/en_US.UTF-8/Compose I have about 10'000 lines 
of special compose keys defined.
  • In my /boot/grub/grub.cfg I have a very complicated special setup for my 
various boot configurations, and a 5-sec timout for my EFI-config.
  • My /etc/ssh/sshd_config contains a well-balanced configuration 

  All these files are regularly overridden WITHOUT EVEN A SINGLE WARNING
  or ASKING BACK by ubuntu system setups (discover).

  I set all of them to read-only by root and no-access for group and
  other users, but they still get overridden by every other system
  update.  I even have a shutdown process in place which should actually
  make sure that changes to these files are reverted by writing a backup
  copy over any newly installed override — unfortunately, everything I
  did to run either a custom shutdown process or a startup process with
  systemd turned out to not work and be a nightmare to make work.

  How somebody could be as bold as to override vital configuration files
  like this without even asking  for consent is one of the strange
  miracles in this world which I'll probably never understand.  However,
  if "ubuntu" is really what it translates to, it should take a little
  bit more care about pre-existing configurations on systems on which it
  is set up and running well — until one system update suddenly
  jeopardizes the functioning of the entire system.  I'm pretty sure
  these are not the only configuration files which are carelessly just
  overridden.  They're just the ones every other update breaks my system
  and inflinges on my the costs of hours of research until I find out
  that — of course — it was an overridden critical system configuration
  again.  The really mean thing is that you don't notice anything when
  you run the update … only next time you start your system and of
  course are not aware anymore that you did a system update, the new
  (absolutely wrong and/or insufficent) settings are in place and shoot
  you in the leg.

  Take an example from gentoo's etc-update feature which lets you merge
  new configuration files with pre-existing ones using a diff3-update.
  I went away from gentoo for other reasons, but I always praised that
  feature.

  Please make sure immediately that critical configuration files do not
  get overridden if they are non-writable by root, and then gradually
  introduce a system that merges changes to configuration files with the
  current situation on the target system.  Or at least present the
  configs that would be changed in a particular directory, so that
  anybody who is interested in preserving local settings could merge
  them in a suitable way.

  Thanks

  ProblemType: Bug
  DistroRelease: Ubuntu 20.10
  Package: xorg 1:7.7+19ubuntu15
  ProcVersionSignature: Ubuntu 5.8.0-53.60-generic 5.8.18
  Uname: Linux 5.8.0-53-generic x86_64
  ApportVersion: 2.20.11-0ubuntu50.7
  Architecture: amd64
  BootLog: Error: [Errno 13] Permission denied: '/var/log/boot.log'
  CasperMD5CheckResult: skip
  CompositorRunning: None
  CurrentDesktop: KDE
  Date: Thu May 27 18:48:15 2021
  DistUpgraded: Fresh install
  DistroCodename: groovy
  DistroVariant: ubuntu
  ExtraDebuggingInterest: Yes
  GraphicsCard:
   NVIDIA Corporation TU117GLM [Quadro T1000 Mobile] [10de:1fb9] (rev a1) 
(prog-if 00 [VGA controller])
 Subsystem: Lenovo TU117GLM [Quadro T1000 Mobile] [17aa:2297]
  InstallationDate: Installed on 2021-01-15 (132 days ago)
  InstallationMedia: Kubuntu 20.10 "Groovy Gorilla" - Release amd64 (20201022)
  MachineType: LENOVO 20QQS0KL13
  ProcKernelCmdLine: BOOT_IMAGE=/@/boot/vmlinuz-5.8.0-53-generic 
root=UUID=35cef147-e021-4bdd-b8db-31a3192c8a6a ro rootflags=subvol=@ quiet 
splash vt.handoff=7
  SourcePackage: xorg
  Symptom: display
  UpgradeStatus: No upgrade log present (probably fresh install)
  dmi.bios.date: 06/04/2020
  dmi.bios.release: 1.23
  dmi.bios.vendor: LENOVO
  dmi.bios.version: N2NET38W (1.23 )
  dmi.board.asset.tag: Not Available
  dmi.board.name: 20QQS0KL13
  dmi.board.vendor: LENOVO
  dmi.board.version: SDK0J40697 WIN
  dmi.chassis.asset.tag: ZF211710
  dmi.chassis.type: 10
  dmi.chassis.vendor: LENOVO
  dmi.chassis.version: None
  dmi.ec.firmware.release: 1.14
  dmi.modalias: 
dmi:bvnLENOVO:bvrN2NET38W(1.23):bd06/04/2020:br1.23:efr1.14:svnLENOVO:pn20QQS0KL13:pvrThinkPadP53:rvnLENOVO:rn20QQS0KL13:rvrSDK0J40697WIN:cvnLENOVO:ct10:cv

[Touch-packages] [Bug 1937919] Re: Fails to start pulseaudio (No card found by this name or index.)

2021-09-24 Thread Launchpad Bug Tracker
[Expired for pulseaudio (Ubuntu) because there has been no activity for
60 days.]

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

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

Title:
  Fails to start pulseaudio (No card found by this name or index.)

Status in pulseaudio package in Ubuntu:
  Expired

Bug description:
  First pulseaudio fails for some reason. Pulseaudio Plugin i.e. the
  volume control in Xfce panel shows mute after I start session, but I
  can not change it. This does not happen every time.

  ProblemType: Bug
  DistroRelease: Ubuntu 20.04
  Package: pulseaudio 1:13.99.1-1ubuntu3.11
  ProcVersionSignature: Ubuntu 5.4.0-77.86-generic 5.4.119
  Uname: Linux 5.4.0-77-generic x86_64
  ApportVersion: 2.20.11-0ubuntu27.18
  Architecture: amd64
  AudioDevicesInUse: Error: command ['fuser', '-v', '/dev/snd/by-path', 
'/dev/snd/by-id', '/dev/snd/controlC0', '/dev/snd/hwC0D3', '/dev/snd/hwC0D0', 
'/dev/snd/pcmC0D7p', '/dev/snd/pcmC0D3p', '/dev/snd/pcmC0D0c', 
'/dev/snd/pcmC0D0p', '/dev/snd/controlC1', '/dev/snd/pcmC1D1p', 
'/dev/snd/pcmC1D0p', '/dev/snd/seq', '/dev/snd/timer'] failed with exit code 1:
  CasperMD5CheckResult: skip
  CurrentDesktop: XFCE
  Date: Sun Jul 25 00:21:17 2021
  InstallationDate: Installed on 2019-12-05 (597 days ago)
  InstallationMedia: Xubuntu 19.10 "Eoan Ermine" - Release amd64 (20191017)
  PulseList: Error: command ['pacmd', 'list'] failed with exit code 1: No 
PulseAudio daemon running, or not running as session daemon.
  SourcePackage: pulseaudio
  UpgradeStatus: Upgraded to focal on 2020-07-10 (379 days ago)
  dmi.bios.date: 06/28/2018
  dmi.bios.vendor: Dell Inc.
  dmi.bios.version: A30
  dmi.board.name: 051FJ8
  dmi.board.vendor: Dell Inc.
  dmi.board.version: A00
  dmi.chassis.type: 15
  dmi.chassis.vendor: Dell Inc.
  dmi.modalias: 
dmi:bvnDellInc.:bvrA30:bd06/28/2018:svnDellInc.:pnOptiPlex9010:pvr01:rvnDellInc.:rn051FJ8:rvrA00:cvnDellInc.:ct15:cvr:
  dmi.product.name: OptiPlex 9010
  dmi.product.sku: OptiPlex 9010
  dmi.product.version: 01
  dmi.sys.vendor: Dell Inc.

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/pulseaudio/+bug/1937919/+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 1943704] Re: lxc fails autopkgtests on (pure) cgroups v2 enabled system

2021-09-24 Thread Launchpad Bug Tracker
This bug was fixed in the package lxc - 1:4.0.10-0ubuntu5

---
lxc (1:4.0.10-0ubuntu5) impish; urgency=medium

  * d/t/exercise: Skip tests that are incompatible with cgroups v2
(LP: #1943704)

 -- Lukas Märdian   Fri, 17 Sep 2021 15:00:26 +0200

** Changed in: lxc (Ubuntu)
   Status: New => Fix Released

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

Title:
  lxc fails autopkgtests on (pure) cgroups v2 enabled system

Status in lxc package in Ubuntu:
  Fix Released

Bug description:
  lxc fails 4 autopkgtests if ran on a cgroups v2 enabled systemd
  (248.3-1ubuntu7) using a pure unified hierarchy (in favor of the
  hybrid hierarchy used before).

  https://autopkgtest.ubuntu.com/packages/lxc

  FAIL: lxc-tests: lxc-test-apparmor-mount (0s)
  FAIL: lxc-tests: lxc-test-autostart (360s)
  FAIL: lxc-tests: lxc-test-no-new-privs (361s)
  FAIL: lxc-tests: lxc-test-unpriv (0s)

  I needed to skip the "lxc-test-exit-code" test to avoid my local autopkgtest 
to hang but that seems to be working on the Ubuntu infrastructure, so its 
probably related to my local environment:
  diff --git a/debian/tests/exercise b/debian/tests/exercise
  index 4a22f33..70231ee 100755
  --- a/debian/tests/exercise
  +++ b/debian/tests/exercise
  @@ -88,6 +88,10 @@ for testbin in lxc-test-*; do
   echo "${testbin}" | grep -qv "\.in$" || continue
   STRING="lxc-tests: $testbin"

  +# Skip some tests because for testing
  +[ "$testbin" = "lxc-test-exit-code" ] && \
  +ignore "$STRING" && continue
  +
   # Some tests can't be run standalone
   [ "$testbin" = "lxc-test-may-control" ] && continue

  Reproducer (while being connected to the Canonical VPN, or setup another 
squid proxy):
  $ autopkgtest-buildvm-ubuntu-cloud -v -r impish
  $ autopkgtest lxc -s -U --apt-pocket=proposed=src:systemd --env 
"http_proxy=http://squid.internal:3128"; --env 
"https_proxy=http://squid.internal:3128"; --env 
"no_proxy=127.0.0.1,127.0.1.1,localhost,localdomain,novalocal,internal,archive.ubuntu.com,security.ubuntu.com,ddebs.ubuntu.com,changelogs.ubuntu.com,launchpad.net,10.24.0.0/24"
 -- qemu autopkgtest-impish-amd64.img

  I used "../lxc_4.0.10-0ubuntu4+wip0_amd64.changes" instead of the
  "lxc" SRCPKG name, to use a custom package, skipping the additional
  "lxc-test-exit-code" test.

  Interestingly, the same set of tests fails if I run the test using the
  old (non cgroups v2) systemd (248.3-1ubuntu3), i.e. by leaving out the
  "--apt-pocket=proposed=src:systemd" parameter. Although, they fail in
  a slightly different way (see attached lxc-vs-old-systemd.log).
  Running a baseline test using the old systemd passed on the Ubuntu
  infrastructure. – I cannot really explain this infra-baseline vs
  local-autopkgtest difference... But it doesn't matter too much either,
  as we need to fix the situation for the new (cgroupv2) enabled
  systemd.


  Logs (full logs attached):

  FAIL: lxc-tests: lxc-test-apparmor-mount (0s)
  ---
  /usr/sbin/deluser: The user `lxcunpriv' does not exist.
  ./lxc-test-apparmor-mount: 152: cannot create 
/sys/fs/cgroup/-.mount/lxctest/tasks: Permission denied
  lxc-destroy: tmp.6hX6BylHCU: tools/lxc_destroy.c: main: 242 Container is not 
defined
  umount: /sys/kernel/security/apparmor/features/mount: not mounted.
  sed: can't read /run/lxc/nics: No such file or directory
  ---
  => "./lxc-test-apparmor-mount: 152: cannot create 
/sys/fs/cgroup/-.mount/lxctest/tasks: Permission denied" seems to be 
relevant/related to unified cgroup hierarchy here.
  => fails in a different way with old (non cgroup v2) systemd, locally

  FAIL: lxc-tests: lxc-test-autostart (21s)
  ---
  Setting up the GPG keyring
  Downloading the image index
  ERROR: Failed to download 
http://images.linuxcontainers.org//meta/1.0/index-system
  lxc-create: lxc-test-auto: lxccontainer.c: create_run_template: 1621 Failed 
to create container from template
  lxc-create: lxc-test-auto: tools/lxc_create.c: main: 319 Failed to create 
container lxc-test-auto
  FAIL
  ---
  => fails in the same way with old (non cgroup v2) systemd, locally.

  FAIL: lxc-tests: lxc-test-no-new-privs (22s)
  ---
  + DONE=0
  + trap cleanup EXIT SIGHUP SIGINT SIGTERM
  + '[' '!' -d /etc/lxc ']'
  + ARCH=i386
  + type dpkg
  ++ dpkg --print-architecture
  + ARCH=amd64
  + lxc-create -t download -n c1 -- -d ubuntu -r xenial -a amd64
  Setting up the GPG keyring
  Downloading the image index
  ERROR: Failed to download 
http://images.linuxcontainers.org//meta/1.0/index-system
  lxc-create: c1: lxccontainer.c: create_run_template: 1621 Failed to create 
container from template
  lxc-create: c1: tools/lxc_create.c: main: 319 Failed to create container c1
  + cleanup
  + cd /
  + lxc-destroy -n c1 -f
  lxc-destroy: c1: tools/lxc_destroy.c: main: 242 Container is not defined
  + true
  + '[' 0 -eq 0 ']'
  + echo F

[Touch-packages] [Bug 1940818] Re: FFe diffutils 3.8

2021-09-24 Thread Brian Murray
diffutils (1:3.8-0ubuntu1) impish; urgency=medium

  * New upstream version.
  * d/patches/03-translations.patch: remove, as translations have now been
updated upstream.
  * Remove d/patches/gnulib-ftbfs.patch, applied upstream.

 -- Michael Hudson-Doyle   Mon, 23 Aug 2021
22:20:30 +1200

** Changed in: diffutils (Ubuntu)
   Status: Fix Committed => Fix Released

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

Title:
  FFe diffutils 3.8

Status in diffutils package in Ubuntu:
  Fix Released

Bug description:
  diffutils ftbfs with glibc 2.34 because of gnulib issues around
  SIGSTKSZ no longer being constant. diffutils 3.8 was released with an
  updated gnulib and builds fine with glibc 2.34
  
(https://launchpad.net/~mwhudson/+archive/ubuntu/devirt/+packages?field.name_filter=diffutils)
  so I'd prefer to upload that rather than try to cherry pick the (large
  and not completely straightforward) gnulib fixes. The changelog for
  3.8 indicates one obscure incompatible change:

  https://savannah.gnu.org/forum/forum.php?forum_id=10031

  but as we're only just past FF, this seems like the best way forward
  to me.

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/diffutils/+bug/1940818/+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 1943840] Re: [FFe] Update the ubuntu-desktop-minimal seed to use the firefox snap

2021-09-24 Thread Brian Murray
** Changed in: ubuntu-meta (Ubuntu Impish)
   Status: Fix Committed => Fix Released

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

Title:
  [FFe] Update the ubuntu-desktop-minimal seed to use the firefox snap

Status in ubuntu-meta package in Ubuntu:
  Fix Released
Status in ubuntu-release-upgrader package in Ubuntu:
  Fix Released
Status in ubuntu-settings package in Ubuntu:
  Fix Released
Status in ubuntu-meta source package in Impish:
  Fix Released
Status in ubuntu-release-upgrader source package in Impish:
  Fix Released
Status in ubuntu-settings source package in Impish:
  Fix Released

Bug description:
  Per Canonical's distribution agreement with Mozilla, we're making the
  snap¹ the default installation of firefox on desktop ISOs starting
  with Ubuntu 21.10.

  The snap is built and published for amd64, armhf and arm64. It is
  jointly maintained by Mozilla and the Ubuntu desktop team, and
  published by Mozilla.

  This requires updating the desktop-minimal seed, as well as ubuntu-
  release-upgrader.

  ¹ https://snapcraft.io/firefox

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/ubuntu-meta/+bug/1943840/+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 1850964] Re: Always explain why packages are held back in logs even without debugging enabled

2021-09-24 Thread Martin Konôpka
I see this annoying bug on a quite recently installed ubuntu 20.04.3 LTS
(GNU/Linux 5.11.0-36-generic x86_64):

1 updates could not be installed automatically. For more details,
see /var/log/unattended-upgrades/unattended-upgrades.log

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

Title:
  Always explain why packages are held back in logs even without
  debugging enabled

Status in unattended-upgrades package in Ubuntu:
  Fix Released
Status in unattended-upgrades package in Debian:
  Fix Released

Bug description:
  [Impact]

   * Unattended-upgrades' log does not contain information about why
  held packages are kept back unless debugging is enabled. Users should
  be explained why packages are kept back to let them easily resolve the
  issues keeping the packages from being upgraded.

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/unattended-upgrades/+bug/1850964/+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 1857345] Re: Misleading login message from unattended-upgrades

2021-09-24 Thread Launchpad Bug Tracker
*** This bug is a duplicate of bug 1850964 ***
https://bugs.launchpad.net/bugs/1850964

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

** Changed in: unattended-upgrades (Ubuntu)
   Status: New => Confirmed

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

Title:
  Misleading login message from unattended-upgrades

Status in unattended-upgrades package in Ubuntu:
  Confirmed

Bug description:
  A recent update to unattended-upgrades causes messages to be displayed
  at login similar to this: "1 updates could not be installed
  automatically. For more details,see /var/log/unattended-
  upgrades/unattended-upgrades.log"

  However, when the user has pinned/held a package, this is expected
  behavior, and should not cause a warning or error. Additionally, in
  this case, the the logfile that the user is directed to reference
  contains no useful information.

  Either the message should not be issued for pinned packages
  (preferred) or the logfile that the user is directed to reference
  should contain useful information.

  ProblemType: Bug
  DistroRelease: Ubuntu 18.04
  Package: unattended-upgrades 1.1ubuntu1.18.04.13
  ProcVersionSignature: Ubuntu 5.0.0-37.40~18.04.1-generic 5.0.21
  Uname: Linux 5.0.0-37-generic x86_64
  ApportVersion: 2.20.9-0ubuntu7.9
  Architecture: amd64
  CurrentDesktop: LXDE
  Date: Mon Dec 23 07:16:09 2019
  InstallationDate: Installed on 2016-08-27 (1213 days ago)
  InstallationMedia: Lubuntu 16.04.1 LTS "Xenial Xerus" - Release amd64 
(20160720)
  PackageArchitecture: all
  SourcePackage: unattended-upgrades
  UpgradeStatus: Upgraded to bionic on 2018-08-04 (505 days ago)
  modified.conffile..etc.apt.apt.conf.d.10periodic:
   APT::Periodic::Update-Package-Lists "1";
   APT::Periodic::Download-Upgradeable-Packages "1";
   APT::Periodic::AutocleanInterval "0";
   APT::Periodic::Unattended-Upgrade "1";
  mtime.conffile..etc.apt.apt.conf.d.10periodic: 2017-08-18T18:55:52.439072

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/unattended-upgrades/+bug/1857345/+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 1944481] Re: Distrust "DST Root CA X3"

2021-09-24 Thread Seth Arnold
You can find older packages on the "full publishing history" from
launchpad:

https://launchpad.net/ubuntu/+source/ca-certificates/+publishinghistory

You can either download it manually or use the pull-lp-debs(1) command
from the ubuntu-dev-tools package.

Thanks

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

Title:
  Distrust "DST Root CA X3"

Status in ca-certificates package in Ubuntu:
  Fix Committed
Status in ca-certificates source package in Trusty:
  Fix Released
Status in ca-certificates source package in Xenial:
  Fix Released
Status in ca-certificates source package in Bionic:
  Fix Released
Status in ca-certificates source package in Focal:
  Fix Released
Status in ca-certificates source package in Hirsute:
  Fix Released
Status in ca-certificates source package in Impish:
  Fix Committed

Bug description:
  [Impact]

   * ca-certificates trusts the letsencrypt CA certificate "ISRG Root X1"
   * ca-certificates also trusts the CA certificate "DST Root CA X3" which 
cross-signs letencrypt CA
   * "DST Root CA X3" is about to expire, however it has issued an updated 
cross-signature to letsencrypt beyond its own expiry
   * This causes issues with older implementations of openssl & gnutls that 
reject such chains when offered to clients by servers.
   * We have provided fixes for openssl in xenial and gnutls in bionic/xenial, 
however trusty systems remain affected. Also any self built old copies of 
openssl/gnutls remain suspeptible to this expiry.
   * One solution is to blacklist the "DST Root CA X3" from the ca-certificates 
package as described at 
https://blog.devgenius.io/rhel-centos-7-fix-for-lets-encrypt-change-8af2de587fe4
 - connectivity to sites chained to "DST Root CA X3" will be unaffected, and 
servers that chain to both "ISRG Root X1" and "DST Root CA X3" should start to 
work unmodified.
   * This is similar to how this was handled for AddTrust before

  "* mozilla/blacklist.txt: blacklist expired AddTrust External Root
  CA."

  [Test Plan]

   * Install old/current ca-certificates faketime wget curl
  libcurl3-gnutls

  # faketime 2021-10-01 wget https://pskov.surgut.co.uk
  --2021-10-01 00:00:00--  https://pskov.surgut.co.uk/
  Resolving pskov.surgut.co.uk (pskov.surgut.co.uk)... 2a01:4f8:c17:3dd8::1, 
49.12.37.5
  Connecting to pskov.surgut.co.uk 
(pskov.surgut.co.uk)|2a01:4f8:c17:3dd8::1|:443... connected.
  ERROR: cannot verify pskov.surgut.co.uk's certificate, issued by 
'/C=US/O=Let\'s Encrypt/CN=R3':
    Issued certificate has expired.
  To connect to pskov.surgut.co.uk insecurely, use `--no-check-certificate'.

  # LD_PRELOAD=/usr/lib/x86_64-linux-gnu/libcurl-gnutls.so.4 faketime 
2021-10-01 curl https://pskov.surgut.co.uk >/dev/null
    % Total% Received % Xferd  Average Speed   TimeTime Time  
Current
   Dload  Upload   Total   SpentLeft  Speed
    0 00 00 0  0  0 --:--:-- --:--:-- --:--:-- 0
  curl: (60) SSL certificate problem: certificate has expired

   * Install new ca-certificates package

  # faketime 2021-10-01 wget https://pskov.surgut.co.uk
  --2021-10-01 00:00:00--  https://pskov.surgut.co.uk/
  Resolving pskov.surgut.co.uk (pskov.surgut.co.uk)... 2a01:4f8:c17:3dd8::1, 
49.12.37.5
  Connecting to pskov.surgut.co.uk 
(pskov.surgut.co.uk)|2a01:4f8:c17:3dd8::1|:443... connected.
  HTTP request sent, awaiting response... 200 OK
  Length: 612 [text/html]
  Saving to: 'index.html.3'

  100%[>] 612
  --.-K/s   in 0s

  2021-10-01 00:00:00 (71.7 MB/s) - 'index.html.3' saved [612/612]

   LD_PRELOAD=/usr/lib/x86_64-linux-gnu/libcurl-gnutls.so.4 faketime 2021-10-01 
curl https://pskov.surgut.co.uk >/dev/null
    % Total% Received % Xferd  Average Speed   TimeTime Time  
Current
   Dload  Upload   Total   SpentLeft  Speed
  100   612  100   6120 0   5794  0 --:--:-- --:--:-- --:--:--  5828

  Download is successful.

  [Where problems could occur]

   * Connectivity to "DST Root CA X3" websites only, even under faketime
  set to dates prior to 30th of September 2021 will not work, as "DST
  Root CA X3" certificate is no longer installed. users should locally
  install and enable that CA certificate, or allow dangerous unverified
  connectivity to websites using expired CA certs.

  [Other Info]

   * Related openssl and gnutls28 bugs are
  https://bugs.launchpad.net/ubuntu/+source/openssl/+bug/1928989 and
  https://bugs.launchpad.net/ubuntu/+source/gnutls28/+bug/1928648

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/ca-certificates/+bug/1944481/+subscriptions


-- 
Mailing list: https://launchpad.net/~touch-packages
Post to : touch-packages@lists.launchpad.net
Unsubscribe : https://launchpad.net

[Touch-packages] [Bug 1944453] Re: PDF documents signed with DocuSign show the error message "The document contains no pages"

2021-09-24 Thread Sebastien Bacher
It's not right, basically it's the case described in
https://wiki.ubuntu.com/Bugs/Responses#Fixed_in_Development_release_while_still_existing_in_a_previous_release.

The report here is the first one we get about the issue and no other
user marked itself as affected. If we had unlimited resources we would
SRU every single fix but we don't so have to focus on important issues,
it's not likely at this point that the problem will rank high enough to
be worked on by us.

It doesn't mean a fix can't be uploaded, it's opensource and a community
project, if someone was wanting to do the work to figure out which
commit fixed the problem and work on a stable update include it then
finding a sponsor should be doable

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

Title:
  PDF documents signed with DocuSign show the error message "The
  document contains no pages"

Status in poppler package in Ubuntu:
  Fix Released

Bug description:
  Steps to reproduce:
  ---

  1. Open a document signed with DocuSign

  Expected behaviour:
  ---

  Document opens fine

  Actual behaviour:
  ---

  Evince refuses to display the document, with the error message "The
  document contains no pages".

  If document is opened with `pdftotext`, the output is:

  ```
  Syntax Error: Gen inside xref table too large (bigger than INT_MAX)
  Syntax Error: Invalid XRef entry 3
  Syntax Error: Top-level pages object is wrong type (null)
  Command Line Error: Wrong page range given: the first page (1) can not be 
after the last page (0).
  ```

  Other information
  ---

  This appears to be a bug in libpoppler, described at
  https://stackoverflow.com/questions/66636441/pdf2image-library-
  failing-to-read-pdf-signed-using-docusign and
  https://gitlab.freedesktop.org/poppler/poppler/-/issues/1014 . I
  believe that bumping the version of Poppler and/or Evince will solve
  the issue, though I have no way to test this as compiling from source
  is a significant undertaking.

  I do not have a public sample document that I could share, but
  examples of DocuSigned documents should be available online.

  Ubuntu version: 20.04 LTS (up to date)
  Evince version: 3.36.10 (official package)
  Poppler version: 0.86.1-0ubuntu1 (official package)

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/poppler/+bug/1944453/+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 1944453] Re: PDF documents signed with DocuSign show the error message "The document contains no pages"

2021-09-24 Thread Peter
@seb128 I am aware that this has been fixed in hirsuite, but it remains
unfixed in focal. I am committed to staying on an LTS release.

If this is not the right place to report this bug, could you please
point me to how I can navigate the relevant backporting request process?

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

Title:
  PDF documents signed with DocuSign show the error message "The
  document contains no pages"

Status in poppler package in Ubuntu:
  Fix Released

Bug description:
  Steps to reproduce:
  ---

  1. Open a document signed with DocuSign

  Expected behaviour:
  ---

  Document opens fine

  Actual behaviour:
  ---

  Evince refuses to display the document, with the error message "The
  document contains no pages".

  If document is opened with `pdftotext`, the output is:

  ```
  Syntax Error: Gen inside xref table too large (bigger than INT_MAX)
  Syntax Error: Invalid XRef entry 3
  Syntax Error: Top-level pages object is wrong type (null)
  Command Line Error: Wrong page range given: the first page (1) can not be 
after the last page (0).
  ```

  Other information
  ---

  This appears to be a bug in libpoppler, described at
  https://stackoverflow.com/questions/66636441/pdf2image-library-
  failing-to-read-pdf-signed-using-docusign and
  https://gitlab.freedesktop.org/poppler/poppler/-/issues/1014 . I
  believe that bumping the version of Poppler and/or Evince will solve
  the issue, though I have no way to test this as compiling from source
  is a significant undertaking.

  I do not have a public sample document that I could share, but
  examples of DocuSigned documents should be available online.

  Ubuntu version: 20.04 LTS (up to date)
  Evince version: 3.36.10 (official package)
  Poppler version: 0.86.1-0ubuntu1 (official package)

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/poppler/+bug/1944453/+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 1944764] Re: APN command line : 'username' and 'user' are transposed

2021-09-24 Thread Donald Mah
The problem is that I was referring to the man pages for the embedded
Ubuntu version on my devices. I saw the incorrect info in multiple
places and lost a couple of days of online access until someone pointed
out the mistake with the man pages.  Just trying to help anyone else
with the same situation.

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

Title:
  APN command line : 'username' and 'user' are transposed

Status in network-manager package in Ubuntu:
  Fix Released

Bug description:
  Pertains to the following man page's Connection Management Commands section : 
 
 https://manpages.ubuntu.com/manpages/xenial/man1/nmcli.1.html

  Man page currently shows:

 type gsm [apn APN] [username user] [password passwd]

 apn
 APN - GSM Access Point Name.

 user
 user name.

 password
 password.

 type cdma [username user] [password passwd]

 user
 user name.

 password
 password.


  The man page should be corrected to show:

 type gsm [apn APN] [user username] [password passwd]

 type cdma [user username] [password passwd]


  
  I suggest correcting the man page so it's correct for people trying to use 
this version of Ubuntu.

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/network-manager/+bug/1944764/+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 1943840] Re: [FFe] Update the ubuntu-desktop-minimal seed to use the firefox snap

2021-09-24 Thread Launchpad Bug Tracker
This bug was fixed in the package ubuntu-release-upgrader - 1:21.10.8

---
ubuntu-release-upgrader (1:21.10.8) impish; urgency=medium

  [ Olivier Tilloy ]
  * DistUpgrade/deb2snap.json: seed the snaps for firefox (which replaces the
deb package) and gnome-3-38-2004. (LP: #1943840)

  [ Brian Murray ]
  * DistUpgrade/DistUpgradeFetcherCore.py: when running in non-interactive
mode do not show the release notes. (LP: #1944475)
  * Run pre-build.sh: updating mirrors, demotions, and translations.

 -- Brian Murray   Wed, 22 Sep 2021 11:22:12 -0700

** Changed in: ubuntu-release-upgrader (Ubuntu Impish)
   Status: Confirmed => Fix Released

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

Title:
  [FFe] Update the ubuntu-desktop-minimal seed to use the firefox snap

Status in ubuntu-meta package in Ubuntu:
  Fix Committed
Status in ubuntu-release-upgrader package in Ubuntu:
  Fix Released
Status in ubuntu-settings package in Ubuntu:
  Fix Released
Status in ubuntu-meta source package in Impish:
  Fix Committed
Status in ubuntu-release-upgrader source package in Impish:
  Fix Released
Status in ubuntu-settings source package in Impish:
  Fix Released

Bug description:
  Per Canonical's distribution agreement with Mozilla, we're making the
  snap¹ the default installation of firefox on desktop ISOs starting
  with Ubuntu 21.10.

  The snap is built and published for amd64, armhf and arm64. It is
  jointly maintained by Mozilla and the Ubuntu desktop team, and
  published by Mozilla.

  This requires updating the desktop-minimal seed, as well as ubuntu-
  release-upgrader.

  ¹ https://snapcraft.io/firefox

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/ubuntu-meta/+bug/1943840/+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 1944481] Re: Distrust "DST Root CA X3"

2021-09-24 Thread Collin Anderson
Yes, I'm running into the issue above, where a windows server is not
correctly serving the new certificate chain (which means it's going to
fail for everyone else on Sept 30th.) Windows server might need an
update or might need to be rebooted.
https://community.certifytheweb.com/t/upcoming-expiry-of-dst-root-
ca-x3-and-r3-intermediate-for-lets-encrypt/1480

In the meantime, from the ubuntu point of view, how do I roll this
update back? The cert is still valid for another week. `sudo apt install
ca-certificates=20210119~20.04.1` says `E: Version '20210119~20.04.1'
for 'ca-certificates' was not found`.

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

Title:
  Distrust "DST Root CA X3"

Status in ca-certificates package in Ubuntu:
  Fix Committed
Status in ca-certificates source package in Trusty:
  Fix Released
Status in ca-certificates source package in Xenial:
  Fix Released
Status in ca-certificates source package in Bionic:
  Fix Released
Status in ca-certificates source package in Focal:
  Fix Released
Status in ca-certificates source package in Hirsute:
  Fix Released
Status in ca-certificates source package in Impish:
  Fix Committed

Bug description:
  [Impact]

   * ca-certificates trusts the letsencrypt CA certificate "ISRG Root X1"
   * ca-certificates also trusts the CA certificate "DST Root CA X3" which 
cross-signs letencrypt CA
   * "DST Root CA X3" is about to expire, however it has issued an updated 
cross-signature to letsencrypt beyond its own expiry
   * This causes issues with older implementations of openssl & gnutls that 
reject such chains when offered to clients by servers.
   * We have provided fixes for openssl in xenial and gnutls in bionic/xenial, 
however trusty systems remain affected. Also any self built old copies of 
openssl/gnutls remain suspeptible to this expiry.
   * One solution is to blacklist the "DST Root CA X3" from the ca-certificates 
package as described at 
https://blog.devgenius.io/rhel-centos-7-fix-for-lets-encrypt-change-8af2de587fe4
 - connectivity to sites chained to "DST Root CA X3" will be unaffected, and 
servers that chain to both "ISRG Root X1" and "DST Root CA X3" should start to 
work unmodified.
   * This is similar to how this was handled for AddTrust before

  "* mozilla/blacklist.txt: blacklist expired AddTrust External Root
  CA."

  [Test Plan]

   * Install old/current ca-certificates faketime wget curl
  libcurl3-gnutls

  # faketime 2021-10-01 wget https://pskov.surgut.co.uk
  --2021-10-01 00:00:00--  https://pskov.surgut.co.uk/
  Resolving pskov.surgut.co.uk (pskov.surgut.co.uk)... 2a01:4f8:c17:3dd8::1, 
49.12.37.5
  Connecting to pskov.surgut.co.uk 
(pskov.surgut.co.uk)|2a01:4f8:c17:3dd8::1|:443... connected.
  ERROR: cannot verify pskov.surgut.co.uk's certificate, issued by 
'/C=US/O=Let\'s Encrypt/CN=R3':
    Issued certificate has expired.
  To connect to pskov.surgut.co.uk insecurely, use `--no-check-certificate'.

  # LD_PRELOAD=/usr/lib/x86_64-linux-gnu/libcurl-gnutls.so.4 faketime 
2021-10-01 curl https://pskov.surgut.co.uk >/dev/null
    % Total% Received % Xferd  Average Speed   TimeTime Time  
Current
   Dload  Upload   Total   SpentLeft  Speed
    0 00 00 0  0  0 --:--:-- --:--:-- --:--:-- 0
  curl: (60) SSL certificate problem: certificate has expired

   * Install new ca-certificates package

  # faketime 2021-10-01 wget https://pskov.surgut.co.uk
  --2021-10-01 00:00:00--  https://pskov.surgut.co.uk/
  Resolving pskov.surgut.co.uk (pskov.surgut.co.uk)... 2a01:4f8:c17:3dd8::1, 
49.12.37.5
  Connecting to pskov.surgut.co.uk 
(pskov.surgut.co.uk)|2a01:4f8:c17:3dd8::1|:443... connected.
  HTTP request sent, awaiting response... 200 OK
  Length: 612 [text/html]
  Saving to: 'index.html.3'

  100%[>] 612
  --.-K/s   in 0s

  2021-10-01 00:00:00 (71.7 MB/s) - 'index.html.3' saved [612/612]

   LD_PRELOAD=/usr/lib/x86_64-linux-gnu/libcurl-gnutls.so.4 faketime 2021-10-01 
curl https://pskov.surgut.co.uk >/dev/null
    % Total% Received % Xferd  Average Speed   TimeTime Time  
Current
   Dload  Upload   Total   SpentLeft  Speed
  100   612  100   6120 0   5794  0 --:--:-- --:--:-- --:--:--  5828

  Download is successful.

  [Where problems could occur]

   * Connectivity to "DST Root CA X3" websites only, even under faketime
  set to dates prior to 30th of September 2021 will not work, as "DST
  Root CA X3" certificate is no longer installed. users should locally
  install and enable that CA certificate, or allow dangerous unverified
  connectivity to websites using expired CA certs.

  [Other Info]

   * Related openssl and gnutls28 bugs are
  https://bugs.launchpad.net/ubuntu/+source/openssl/+bug/1928989 an

[Touch-packages] [Bug 1944481] Re: Distrust "DST Root CA X3"

2021-09-24 Thread Matt Jones
@jsing You may well be correct that the server was incorrectly
configured, unfortunately it was a Windows server managed by a third
party and I don't know precisely how it was set up. Given that the cert
in question was issued on 9th September 2021 I suspect it was a
misconfiguration of their intermediate cert they were sending.

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

Title:
  Distrust "DST Root CA X3"

Status in ca-certificates package in Ubuntu:
  Fix Committed
Status in ca-certificates source package in Trusty:
  Fix Released
Status in ca-certificates source package in Xenial:
  Fix Released
Status in ca-certificates source package in Bionic:
  Fix Released
Status in ca-certificates source package in Focal:
  Fix Released
Status in ca-certificates source package in Hirsute:
  Fix Released
Status in ca-certificates source package in Impish:
  Fix Committed

Bug description:
  [Impact]

   * ca-certificates trusts the letsencrypt CA certificate "ISRG Root X1"
   * ca-certificates also trusts the CA certificate "DST Root CA X3" which 
cross-signs letencrypt CA
   * "DST Root CA X3" is about to expire, however it has issued an updated 
cross-signature to letsencrypt beyond its own expiry
   * This causes issues with older implementations of openssl & gnutls that 
reject such chains when offered to clients by servers.
   * We have provided fixes for openssl in xenial and gnutls in bionic/xenial, 
however trusty systems remain affected. Also any self built old copies of 
openssl/gnutls remain suspeptible to this expiry.
   * One solution is to blacklist the "DST Root CA X3" from the ca-certificates 
package as described at 
https://blog.devgenius.io/rhel-centos-7-fix-for-lets-encrypt-change-8af2de587fe4
 - connectivity to sites chained to "DST Root CA X3" will be unaffected, and 
servers that chain to both "ISRG Root X1" and "DST Root CA X3" should start to 
work unmodified.
   * This is similar to how this was handled for AddTrust before

  "* mozilla/blacklist.txt: blacklist expired AddTrust External Root
  CA."

  [Test Plan]

   * Install old/current ca-certificates faketime wget curl
  libcurl3-gnutls

  # faketime 2021-10-01 wget https://pskov.surgut.co.uk
  --2021-10-01 00:00:00--  https://pskov.surgut.co.uk/
  Resolving pskov.surgut.co.uk (pskov.surgut.co.uk)... 2a01:4f8:c17:3dd8::1, 
49.12.37.5
  Connecting to pskov.surgut.co.uk 
(pskov.surgut.co.uk)|2a01:4f8:c17:3dd8::1|:443... connected.
  ERROR: cannot verify pskov.surgut.co.uk's certificate, issued by 
'/C=US/O=Let\'s Encrypt/CN=R3':
    Issued certificate has expired.
  To connect to pskov.surgut.co.uk insecurely, use `--no-check-certificate'.

  # LD_PRELOAD=/usr/lib/x86_64-linux-gnu/libcurl-gnutls.so.4 faketime 
2021-10-01 curl https://pskov.surgut.co.uk >/dev/null
    % Total% Received % Xferd  Average Speed   TimeTime Time  
Current
   Dload  Upload   Total   SpentLeft  Speed
    0 00 00 0  0  0 --:--:-- --:--:-- --:--:-- 0
  curl: (60) SSL certificate problem: certificate has expired

   * Install new ca-certificates package

  # faketime 2021-10-01 wget https://pskov.surgut.co.uk
  --2021-10-01 00:00:00--  https://pskov.surgut.co.uk/
  Resolving pskov.surgut.co.uk (pskov.surgut.co.uk)... 2a01:4f8:c17:3dd8::1, 
49.12.37.5
  Connecting to pskov.surgut.co.uk 
(pskov.surgut.co.uk)|2a01:4f8:c17:3dd8::1|:443... connected.
  HTTP request sent, awaiting response... 200 OK
  Length: 612 [text/html]
  Saving to: 'index.html.3'

  100%[>] 612
  --.-K/s   in 0s

  2021-10-01 00:00:00 (71.7 MB/s) - 'index.html.3' saved [612/612]

   LD_PRELOAD=/usr/lib/x86_64-linux-gnu/libcurl-gnutls.so.4 faketime 2021-10-01 
curl https://pskov.surgut.co.uk >/dev/null
    % Total% Received % Xferd  Average Speed   TimeTime Time  
Current
   Dload  Upload   Total   SpentLeft  Speed
  100   612  100   6120 0   5794  0 --:--:-- --:--:-- --:--:--  5828

  Download is successful.

  [Where problems could occur]

   * Connectivity to "DST Root CA X3" websites only, even under faketime
  set to dates prior to 30th of September 2021 will not work, as "DST
  Root CA X3" certificate is no longer installed. users should locally
  install and enable that CA certificate, or allow dangerous unverified
  connectivity to websites using expired CA certs.

  [Other Info]

   * Related openssl and gnutls28 bugs are
  https://bugs.launchpad.net/ubuntu/+source/openssl/+bug/1928989 and
  https://bugs.launchpad.net/ubuntu/+source/gnutls28/+bug/1928648

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/ca-certificates/+bug/1944481/+subscriptions


-- 
Mailing list: https://launchpad.net/~touch-packages
Post to : touc

[Touch-packages] [Bug 1944481] Re: Distrust "DST Root CA X3"

2021-09-24 Thread Joel Sing
@mattjones86 that does not seem expected - Let's Encrypt have been
issuing certificate from their R3 intermediate since December 2021
(https://community.letsencrypt.org/t/beginning-issuance-from-r3/139018)
and have been supplying two intermediates (an Let's Encrypt R3 to ISRG
Root X1 and a Let's Encrypt R3 to DST Root CA X3) in the default chain
since 4th May 2021 (https://community.letsencrypt.org/t/production-
chain-changes/150739). Given that certificates issued by Let's Encrypt
have a maximum validity period of 90 days, all certificates that are
still valid after the 4th of August would have been issued in this
manner.

The only thing I could think of that would explain the behaviour
mentioned, is if your ACME client was failing to update the certificate
chain/bundle (or your server was configured to serve and old/stale
bundle). Most browsers (including Chrome) will also automatically fetch
issuer intermediate certificates if they're not supplied by the server.

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

Title:
  Distrust "DST Root CA X3"

Status in ca-certificates package in Ubuntu:
  Fix Committed
Status in ca-certificates source package in Trusty:
  Fix Released
Status in ca-certificates source package in Xenial:
  Fix Released
Status in ca-certificates source package in Bionic:
  Fix Released
Status in ca-certificates source package in Focal:
  Fix Released
Status in ca-certificates source package in Hirsute:
  Fix Released
Status in ca-certificates source package in Impish:
  Fix Committed

Bug description:
  [Impact]

   * ca-certificates trusts the letsencrypt CA certificate "ISRG Root X1"
   * ca-certificates also trusts the CA certificate "DST Root CA X3" which 
cross-signs letencrypt CA
   * "DST Root CA X3" is about to expire, however it has issued an updated 
cross-signature to letsencrypt beyond its own expiry
   * This causes issues with older implementations of openssl & gnutls that 
reject such chains when offered to clients by servers.
   * We have provided fixes for openssl in xenial and gnutls in bionic/xenial, 
however trusty systems remain affected. Also any self built old copies of 
openssl/gnutls remain suspeptible to this expiry.
   * One solution is to blacklist the "DST Root CA X3" from the ca-certificates 
package as described at 
https://blog.devgenius.io/rhel-centos-7-fix-for-lets-encrypt-change-8af2de587fe4
 - connectivity to sites chained to "DST Root CA X3" will be unaffected, and 
servers that chain to both "ISRG Root X1" and "DST Root CA X3" should start to 
work unmodified.
   * This is similar to how this was handled for AddTrust before

  "* mozilla/blacklist.txt: blacklist expired AddTrust External Root
  CA."

  [Test Plan]

   * Install old/current ca-certificates faketime wget curl
  libcurl3-gnutls

  # faketime 2021-10-01 wget https://pskov.surgut.co.uk
  --2021-10-01 00:00:00--  https://pskov.surgut.co.uk/
  Resolving pskov.surgut.co.uk (pskov.surgut.co.uk)... 2a01:4f8:c17:3dd8::1, 
49.12.37.5
  Connecting to pskov.surgut.co.uk 
(pskov.surgut.co.uk)|2a01:4f8:c17:3dd8::1|:443... connected.
  ERROR: cannot verify pskov.surgut.co.uk's certificate, issued by 
'/C=US/O=Let\'s Encrypt/CN=R3':
    Issued certificate has expired.
  To connect to pskov.surgut.co.uk insecurely, use `--no-check-certificate'.

  # LD_PRELOAD=/usr/lib/x86_64-linux-gnu/libcurl-gnutls.so.4 faketime 
2021-10-01 curl https://pskov.surgut.co.uk >/dev/null
    % Total% Received % Xferd  Average Speed   TimeTime Time  
Current
   Dload  Upload   Total   SpentLeft  Speed
    0 00 00 0  0  0 --:--:-- --:--:-- --:--:-- 0
  curl: (60) SSL certificate problem: certificate has expired

   * Install new ca-certificates package

  # faketime 2021-10-01 wget https://pskov.surgut.co.uk
  --2021-10-01 00:00:00--  https://pskov.surgut.co.uk/
  Resolving pskov.surgut.co.uk (pskov.surgut.co.uk)... 2a01:4f8:c17:3dd8::1, 
49.12.37.5
  Connecting to pskov.surgut.co.uk 
(pskov.surgut.co.uk)|2a01:4f8:c17:3dd8::1|:443... connected.
  HTTP request sent, awaiting response... 200 OK
  Length: 612 [text/html]
  Saving to: 'index.html.3'

  100%[>] 612
  --.-K/s   in 0s

  2021-10-01 00:00:00 (71.7 MB/s) - 'index.html.3' saved [612/612]

   LD_PRELOAD=/usr/lib/x86_64-linux-gnu/libcurl-gnutls.so.4 faketime 2021-10-01 
curl https://pskov.surgut.co.uk >/dev/null
    % Total% Received % Xferd  Average Speed   TimeTime Time  
Current
   Dload  Upload   Total   SpentLeft  Speed
  100   612  100   6120 0   5794  0 --:--:-- --:--:-- --:--:--  5828

  Download is successful.

  [Where problems could occur]

   * Connectivity to "DST Root CA X3" websites only, even under faketime
  set to dates prio

[Touch-packages] [Bug 1944606] Re: [EDIFIER X3 R, recording] Microphone is not detected as an audio input

2021-09-24 Thread Amanda Arenales
I added the screenshot of the window where the input devices appear.
There is only one available to select, which is the built-in mic. The
headset is not there.

** Attachment added: "Screenshot from 2021-09-24 11-12-07.png"
   
https://bugs.launchpad.net/ubuntu/+source/alsa-driver/+bug/1944606/+attachment/5527687/+files/Screenshot%20from%202021-09-24%2011-12-07.png

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

Title:
  [EDIFIER X3 R, recording] Microphone is not detected as an audio input

Status in alsa-driver package in Ubuntu:
  New

Bug description:
  Device doesn't appear in the input options inside gnome sound
  controls. It appears in pavucontrol, but there is no port associated
  to it, and no sound is captured.

  ProblemType: Bug
  DistroRelease: Ubuntu 20.04
  Package: alsa-base 1.0.25+dfsg-0ubuntu5
  ProcVersionSignature: Ubuntu 5.11.0-34.36~20.04.1-generic 5.11.22
  Uname: Linux 5.11.0-34-generic x86_64
  ApportVersion: 2.20.11-0ubuntu27.20
  Architecture: amd64
  AudioDevicesInUse:
   USERPID ACCESS COMMAND
   /dev/snd/controlC0:  amanda 2204 F pulseaudio
  CasperMD5CheckResult: skip
  CurrentDesktop: Unity
  Date: Wed Sep 22 14:46:42 2021
  InstallationDate: Installed on 2021-09-09 (13 days ago)
  InstallationMedia: Ubuntu 20.04.3 LTS "Focal Fossa" - Release amd64 (20210819)
  PackageArchitecture: all
  SourcePackage: alsa-driver
  Symptom: audio
  Symptom_Card: EDIFIER X3 R
  Symptom_Type: None of the above
  Title: [EDIFIER X3 R, recording] Recording problem
  UpgradeStatus: No upgrade log present (probably fresh install)
  dmi.bios.date: 03/30/2021
  dmi.bios.release: 1.4
  dmi.bios.vendor: Dell Inc.
  dmi.bios.version: 1.4.1
  dmi.board.name: 0TMFFT
  dmi.board.vendor: Dell Inc.
  dmi.board.version: A00
  dmi.chassis.type: 10
  dmi.chassis.vendor: Dell Inc.
  dmi.modalias: 
dmi:bvnDellInc.:bvr1.4.1:bd03/30/2021:br1.4:svnDellInc.:pnVostro5402:pvr:sku0A03:rvnDellInc.:rn0TMFFT:rvrA00:cvnDellInc.:ct10:cvr:
  dmi.product.family: Vostro
  dmi.product.name: Vostro 5402
  dmi.product.sku: 0A03
  dmi.sys.vendor: Dell Inc.

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/alsa-driver/+bug/1944606/+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 1785383] Re: missing EDNS0 record confuses systemd-resolved

2021-09-24 Thread Paride Legovini
I dropped the verification-* as there were about the systemd SRU, while
I'm preparing the dnsmasq one at the moment.

** Description changed:

  [Impact]
- dnsmasq 2.79 and below omits EDNS0 OPT records when returning an empty answer 
for a domain it is authoritative for. systemd-resolved seems to get confused by 
this in certain circumstances; when using the stub resolver and requesting an 
address for which there are no  records, there can sometimes be a five 
second hang in resolution.
  
- [Fix]
- This is fixed by upstream commit 
http://thekelleys.org.uk/gitweb/?p=dnsmasq.git;a=commit;h=1682d15a744880b0398af75eadf68fe66128af78
+ dnsmasq 2.79 and below omits EDNS0 OPT records [1] when returning an
+ empty answer for a domain it is authoritative for. systemd-resolved
+ seems to get confused by this in certain circumstances; when using the
+ stub resolver and requesting an address for which there are no 
+ records, there can sometimes be a five second hang in resolution.
  
- Not sure if it is worth cherry picking? I imagine the most likely
- trigger will be dnsmasq on routers which are not likely to be running
- Ubuntu, but maybe just in case.
+ [1] https://en.wikipedia.org/wiki/Extension_Mechanisms_for_DNS
  
- I also think there are some logic issues in systemd-resolved, upstream
- bug filed:
+ [Test Plan]
  
- https://github.com/systemd/systemd/issues/9785
+ Test case for bionic:
  
- [Test Case]
- Simple-ish test case for bionic:
- 
- ---
+ -
  IFACE=dummy0
  SUBNET=10.0.0
  
  ip link add $IFACE type dummy
  ifconfig $IFACE ${SUBNET}.1/24
  dnsmasq -h -R -d -C /dev/null -2 $IFACE -z -i $IFACE -I lo 
--host-record=test.test,${SUBNET}.1 --server=/test/ &
  
  dig -t a test.test @10.0.0.1 | grep EDNS
  # should return "; EDNS ..."
  dig -t  test.test @10.0.0.1 | grep EDNS
  # again, should return "; EDNS ..." but doesn't
- ---
+ -
  
- To reproduce the systemd-resolved side of the problem
+ [Where problems could occur]
  
- ---
- # as above, but
- # now configure systemd-resolved to look at only 10.0.0.1, then
+ Problems may occur in case a client queries dnsmasq and relies on EDNS0
+ not being available for behaving correctly. This covers cases where the
+ software querying dnsmasq is buggy or misconfigured.
  
- systemd-resolve --reset-server-features
- # should exhibit five second delay then connect, assuming sshd is running :)
- ssh test.test
- ---
+ [Development Fix]
  
+ Fixed upstream in dnsmasq >= 2.80.
  
- More detailed test case for focal and later:
+ [Stable Fix]
  
- install dnsmasq on a bionic system and start it, listening to an
- interface that is externally reachable, e.g. for a normal libvirt vm
- with interface name 'ens3':
+ Partial cherry-pick of upstream commit
+ 
http://thekelleys.org.uk/gitweb/?p=dnsmasq.git;a=commit;h=1682d15a744880b0398af75eadf68fe66128af78
  
- IFACE=ens3
- dnsmasq -h -R -d -C /dev/null -2 $IFACE -z -i $IFACE -I lo 
--host-record=test.test,1.2.3.4 --server=/test/
- 
- note that the '1.2.3.4' address doesn't matter, any addr is ok.
- 
- then setup a test system that can reach the dnsmasq system, and
- configure networkd to use the dnsmasq server, e.g. using config like:
- 
- [Match]
- Name=ens3
- 
- [Network]
- DHCP=yes
- DNS=DNSMASQ_IP_ADDRESS
- Domains=test
- 
- [DHCPv4]
- UseDNS=no
- UseDomains=no
- 
- replace 'DNSMASQ_IP_ADDRESS' with the addr of the bionic system where
- dnsmasq is running, and replace 'ens3' with whatever the test system
- interface name is. Then restart systemd-networkd, and test:
- 
- systemd-resolve --reset-server-features
- systemd-resolve --flush-caches
- host test.test
- 
- The lookup using 'host' should complete immediately;.
- 
- [Discussion]
- ProblemType: Bug
- DistroRelease: Ubuntu 18.04
- Package: dnsmasq-base 2.79-1
- ProcVersionSignature: Ubuntu 4.15.0-23.25-generic 4.15.18
- Uname: Linux 4.15.0-23-generic x86_64
- ApportVersion: 2.20.9-0ubuntu7.2
- Architecture: amd64
- Date: Sat Aug  4 11:33:56 2018
- InstallationDate: Installed on 2018-05-31 (64 days ago)
- InstallationMedia: Xubuntu 18.04 LTS "Bionic Beaver" - Release amd64 
(20180426)
- ProcEnviron:
-  TERM=xterm
-  PATH=(custom, no user)
-  LANG=en_GB.UTF-8
-  SHELL=/bin/bash
- SourcePackage: dnsmasq
- UpgradeStatus: No upgrade log present (probably fresh install)
+ The cherry-pick is partial because half if it is already in the package
+ .diff we have in Bionic.

** Tags removed: verification-done verification-done-bionic
verification-done-focal verification-done-groovy verification-done-
hirsute

** Description changed:

  [Impact]
  
  dnsmasq 2.79 and below omits EDNS0 OPT records [1] when returning an
  empty answer for a domain it is authoritative for. systemd-resolved
  seems to get confused by this in certain circumstances; when using the
  stub resolver and requesting an address for which there are no 
  records, there can sometimes be a five second hang in resolu

[Touch-packages] [Bug 1944481] Re: Distrust "DST Root CA X3"

2021-09-24 Thread Matt Jones
I ran into an SSL verification issue today, caused by this change.

It seems that some older LetsEncrypt clients have still recently been
issuing valid certificates signed by the DST Root CA X3 root.

These certificates would have otherwise continued to work normally until
the root expired (September 30th 2021), but have been distrusted early
due to this change. (Indeed the certificate in question in my case was
still trusted by the latest Chrome etc.)

The best fix is to make sure the ACME client is up-to-date and re-issue
the certificates under the new root cert.

Posting for awareness - surprised I'm the first!

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

Title:
  Distrust "DST Root CA X3"

Status in ca-certificates package in Ubuntu:
  Fix Committed
Status in ca-certificates source package in Trusty:
  Fix Released
Status in ca-certificates source package in Xenial:
  Fix Released
Status in ca-certificates source package in Bionic:
  Fix Released
Status in ca-certificates source package in Focal:
  Fix Released
Status in ca-certificates source package in Hirsute:
  Fix Released
Status in ca-certificates source package in Impish:
  Fix Committed

Bug description:
  [Impact]

   * ca-certificates trusts the letsencrypt CA certificate "ISRG Root X1"
   * ca-certificates also trusts the CA certificate "DST Root CA X3" which 
cross-signs letencrypt CA
   * "DST Root CA X3" is about to expire, however it has issued an updated 
cross-signature to letsencrypt beyond its own expiry
   * This causes issues with older implementations of openssl & gnutls that 
reject such chains when offered to clients by servers.
   * We have provided fixes for openssl in xenial and gnutls in bionic/xenial, 
however trusty systems remain affected. Also any self built old copies of 
openssl/gnutls remain suspeptible to this expiry.
   * One solution is to blacklist the "DST Root CA X3" from the ca-certificates 
package as described at 
https://blog.devgenius.io/rhel-centos-7-fix-for-lets-encrypt-change-8af2de587fe4
 - connectivity to sites chained to "DST Root CA X3" will be unaffected, and 
servers that chain to both "ISRG Root X1" and "DST Root CA X3" should start to 
work unmodified.
   * This is similar to how this was handled for AddTrust before

  "* mozilla/blacklist.txt: blacklist expired AddTrust External Root
  CA."

  [Test Plan]

   * Install old/current ca-certificates faketime wget curl
  libcurl3-gnutls

  # faketime 2021-10-01 wget https://pskov.surgut.co.uk
  --2021-10-01 00:00:00--  https://pskov.surgut.co.uk/
  Resolving pskov.surgut.co.uk (pskov.surgut.co.uk)... 2a01:4f8:c17:3dd8::1, 
49.12.37.5
  Connecting to pskov.surgut.co.uk 
(pskov.surgut.co.uk)|2a01:4f8:c17:3dd8::1|:443... connected.
  ERROR: cannot verify pskov.surgut.co.uk's certificate, issued by 
'/C=US/O=Let\'s Encrypt/CN=R3':
    Issued certificate has expired.
  To connect to pskov.surgut.co.uk insecurely, use `--no-check-certificate'.

  # LD_PRELOAD=/usr/lib/x86_64-linux-gnu/libcurl-gnutls.so.4 faketime 
2021-10-01 curl https://pskov.surgut.co.uk >/dev/null
    % Total% Received % Xferd  Average Speed   TimeTime Time  
Current
   Dload  Upload   Total   SpentLeft  Speed
    0 00 00 0  0  0 --:--:-- --:--:-- --:--:-- 0
  curl: (60) SSL certificate problem: certificate has expired

   * Install new ca-certificates package

  # faketime 2021-10-01 wget https://pskov.surgut.co.uk
  --2021-10-01 00:00:00--  https://pskov.surgut.co.uk/
  Resolving pskov.surgut.co.uk (pskov.surgut.co.uk)... 2a01:4f8:c17:3dd8::1, 
49.12.37.5
  Connecting to pskov.surgut.co.uk 
(pskov.surgut.co.uk)|2a01:4f8:c17:3dd8::1|:443... connected.
  HTTP request sent, awaiting response... 200 OK
  Length: 612 [text/html]
  Saving to: 'index.html.3'

  100%[>] 612
  --.-K/s   in 0s

  2021-10-01 00:00:00 (71.7 MB/s) - 'index.html.3' saved [612/612]

   LD_PRELOAD=/usr/lib/x86_64-linux-gnu/libcurl-gnutls.so.4 faketime 2021-10-01 
curl https://pskov.surgut.co.uk >/dev/null
    % Total% Received % Xferd  Average Speed   TimeTime Time  
Current
   Dload  Upload   Total   SpentLeft  Speed
  100   612  100   6120 0   5794  0 --:--:-- --:--:-- --:--:--  5828

  Download is successful.

  [Where problems could occur]

   * Connectivity to "DST Root CA X3" websites only, even under faketime
  set to dates prior to 30th of September 2021 will not work, as "DST
  Root CA X3" certificate is no longer installed. users should locally
  install and enable that CA certificate, or allow dangerous unverified
  connectivity to websites using expired CA certs.

  [Other Info]

   * Related openssl and gnutls28 bugs are
  https://bugs.launchpad.net/ubuntu/+source/openssl/+

[Touch-packages] [Bug 1785383] Re: missing EDNS0 record confuses systemd-resolved

2021-09-24 Thread Paride Legovini
** Changed in: dnsmasq (Ubuntu Bionic)
   Status: Triaged => In Progress

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

Title:
  missing EDNS0 record confuses systemd-resolved

Status in systemd:
  Fix Released
Status in dnsmasq package in Ubuntu:
  Fix Released
Status in systemd package in Ubuntu:
  Fix Released
Status in dnsmasq source package in Bionic:
  In Progress
Status in systemd source package in Bionic:
  Fix Released
Status in dnsmasq source package in Focal:
  Fix Released
Status in systemd source package in Focal:
  Fix Released
Status in dnsmasq source package in Groovy:
  Fix Released
Status in systemd source package in Groovy:
  Fix Released
Status in dnsmasq source package in Hirsute:
  Fix Released
Status in systemd source package in Hirsute:
  Fix Released
Status in dnsmasq source package in Impish:
  Fix Released
Status in systemd source package in Impish:
  Fix Released

Bug description:
  [Impact]
  dnsmasq 2.79 and below omits EDNS0 OPT records when returning an empty answer 
for a domain it is authoritative for. systemd-resolved seems to get confused by 
this in certain circumstances; when using the stub resolver and requesting an 
address for which there are no  records, there can sometimes be a five 
second hang in resolution.

  [Fix]
  This is fixed by upstream commit 
http://thekelleys.org.uk/gitweb/?p=dnsmasq.git;a=commit;h=1682d15a744880b0398af75eadf68fe66128af78

  Not sure if it is worth cherry picking? I imagine the most likely
  trigger will be dnsmasq on routers which are not likely to be running
  Ubuntu, but maybe just in case.

  I also think there are some logic issues in systemd-resolved, upstream
  bug filed:

  https://github.com/systemd/systemd/issues/9785

  [Test Case]
  Simple-ish test case for bionic:

  ---
  IFACE=dummy0
  SUBNET=10.0.0

  ip link add $IFACE type dummy
  ifconfig $IFACE ${SUBNET}.1/24
  dnsmasq -h -R -d -C /dev/null -2 $IFACE -z -i $IFACE -I lo 
--host-record=test.test,${SUBNET}.1 --server=/test/ &

  dig -t a test.test @10.0.0.1 | grep EDNS
  # should return "; EDNS ..."
  dig -t  test.test @10.0.0.1 | grep EDNS
  # again, should return "; EDNS ..." but doesn't
  ---

  To reproduce the systemd-resolved side of the problem

  ---
  # as above, but
  # now configure systemd-resolved to look at only 10.0.0.1, then

  systemd-resolve --reset-server-features
  # should exhibit five second delay then connect, assuming sshd is running :)
  ssh test.test
  ---

  
  More detailed test case for focal and later:

  install dnsmasq on a bionic system and start it, listening to an
  interface that is externally reachable, e.g. for a normal libvirt vm
  with interface name 'ens3':

  IFACE=ens3
  dnsmasq -h -R -d -C /dev/null -2 $IFACE -z -i $IFACE -I lo 
--host-record=test.test,1.2.3.4 --server=/test/

  note that the '1.2.3.4' address doesn't matter, any addr is ok.

  then setup a test system that can reach the dnsmasq system, and
  configure networkd to use the dnsmasq server, e.g. using config like:

  [Match]
  Name=ens3

  [Network]
  DHCP=yes
  DNS=DNSMASQ_IP_ADDRESS
  Domains=test

  [DHCPv4]
  UseDNS=no
  UseDomains=no

  replace 'DNSMASQ_IP_ADDRESS' with the addr of the bionic system where
  dnsmasq is running, and replace 'ens3' with whatever the test system
  interface name is. Then restart systemd-networkd, and test:

  systemd-resolve --reset-server-features
  systemd-resolve --flush-caches
  host test.test

  The lookup using 'host' should complete immediately;.

  [Discussion]
  ProblemType: Bug
  DistroRelease: Ubuntu 18.04
  Package: dnsmasq-base 2.79-1
  ProcVersionSignature: Ubuntu 4.15.0-23.25-generic 4.15.18
  Uname: Linux 4.15.0-23-generic x86_64
  ApportVersion: 2.20.9-0ubuntu7.2
  Architecture: amd64
  Date: Sat Aug  4 11:33:56 2018
  InstallationDate: Installed on 2018-05-31 (64 days ago)
  InstallationMedia: Xubuntu 18.04 LTS "Bionic Beaver" - Release amd64 
(20180426)
  ProcEnviron:
   TERM=xterm
   PATH=(custom, no user)
   LANG=en_GB.UTF-8
   SHELL=/bin/bash
  SourcePackage: dnsmasq
  UpgradeStatus: No upgrade log present (probably fresh install)

To manage notifications about this bug go to:
https://bugs.launchpad.net/systemd/+bug/1785383/+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 1944951] Re: delayed display update / konsole artifacts

2021-09-24 Thread Horst Schirmeier
Additional notes:
- Nice reproducer: rsync --progress (the progress output is constantly littered 
with artifacts)
- Artifacts vanish (temporarily) when I press e.g. the ALT key.

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

Title:
  delayed display update / konsole artifacts

Status in xorg package in Ubuntu:
  New

Bug description:
  Since one of the recent Impish updates, konsole shows artifacts and
  reacts slowly.  In fact, it looks like screen updates are pipelined on
  pixel-group granularity somehow, and the pipeline isn't drained
  completely: When more text goes to the terminal (e.g., I type
  something), existing artifacts vanish, but new ones (in the new text)
  appear.

  Unfortunately, I don't see any of the previous konsole .deb releases
  (e.g. 4:21.08.1-1 or 4:21.08.0-1) on the Ubuntu mirrors, so I cannot
  go back and simply check whether the newest konsole updates are the
  culprit.  I'm actually not sure whether konsole is responsible at all,
  I originally intended to file against xorg; however, I see those
  artifacts in neither xterm nor gnome-terminal.

  Find attached a screenshot (taken with an external camera; these
  artifacts cannot be recorded using a screenshot tool such as
  imagemagick's "import") where I ran "ls" in /tmp, and cleared the
  terminal with ^L afterwards.  The screen is still littered with
  remains of the "ls" output.  It took a few tries to get artifacts this
  pronounced, though; usually they only concern small parts of the
  terminal.

  ProblemType: Bug
  DistroRelease: Ubuntu 21.10
  Package: xorg 1:7.7+22ubuntu1
  ProcVersionSignature: Ubuntu 5.13.0-16.16-generic 5.13.13
  Uname: Linux 5.13.0-16-generic x86_64
  ApportVersion: 2.20.11-0ubuntu69
  Architecture: amd64
  CasperMD5CheckResult: unknown
  CompizPlugins: No value set for 
`/apps/compiz-1/general/screen0/options/active_plugins'
  CompositorRunning: None
  CurrentDesktop: KDE
  Date: Fri Sep 24 08:09:18 2021
  DistUpgraded: 2021-08-08 15:09:23,066 DEBUG Running PostInstallScript: 
'/usr/lib/ubuntu-advantage/upgrade_lts_contract.py'
  DistroCodename: impish
  DistroVariant: ubuntu
  GraphicsCard:
   Intel Corporation HD Graphics 530 [8086:191b] (rev 06) (prog-if 00 [VGA 
controller])
 Subsystem: Lenovo HD Graphics 530 [17aa:5050]
 Subsystem: Lenovo GM108M [GeForce 940MX] [17aa:5050]
  InstallationDate: Installed on 2016-11-26 (1762 days ago)
  InstallationMedia: Kubuntu 16.10 "Yakkety Yak" - Release amd64 (20161012.1)
  MachineType: LENOVO 20FXS05500
  ProcKernelCmdLine: BOOT_IMAGE=/vmlinuz-5.13.0-16-generic 
root=/dev/mapper/vgubuntu-root ro kopt=root=/dev/mapper/vgubuntu-root 
resume=/dev/mapper/vgubuntu-swap nouveau.runpm=0 mitigations=off 
i915.i915_enable_fbc=0
  SourcePackage: xorg
  UpgradeStatus: Upgraded to impish on 2021-08-08 (46 days ago)
  dmi.bios.date: 10/24/2019
  dmi.bios.release: 2.30
  dmi.bios.vendor: LENOVO
  dmi.bios.version: R07ET90W (2.30 )
  dmi.board.asset.tag: Not Available
  dmi.board.name: 20FXS05500
  dmi.board.vendor: LENOVO
  dmi.board.version: Not Defined
  dmi.chassis.asset.tag: No Asset Information
  dmi.chassis.type: 10
  dmi.chassis.vendor: LENOVO
  dmi.chassis.version: None
  dmi.ec.firmware.release: 1.5
  dmi.modalias: 
dmi:bvnLENOVO:bvrR07ET90W(2.30):bd10/24/2019:br2.30:efr1.5:svnLENOVO:pn20FXS05500:pvrThinkPadT460p:skuLENOVO_MT_20FX_BU_Think_FM_ThinkPadT460p:rvnLENOVO:rn20FXS05500:rvrNotDefined:cvnLENOVO:ct10:cvrNone:
  dmi.product.family: ThinkPad T460p
  dmi.product.name: 20FXS05500
  dmi.product.sku: LENOVO_MT_20FX_BU_Think_FM_ThinkPad T460p
  dmi.product.version: ThinkPad T460p
  dmi.sys.vendor: LENOVO
  version.compiz: compiz N/A
  version.libdrm2: libdrm2 2.4.107-1
  version.libgl1-mesa-dri: libgl1-mesa-dri 21.2.1-2ubuntu2
  version.libgl1-mesa-glx: libgl1-mesa-glx 21.2.1-2ubuntu2
  version.xserver-xorg-core: xserver-xorg-core 2:1.20.13-1ubuntu1
  version.xserver-xorg-input-evdev: xserver-xorg-input-evdev 1:2.10.6-2build1
  version.xserver-xorg-video-ati: xserver-xorg-video-ati 1:19.1.0-2
  version.xserver-xorg-video-intel: xserver-xorg-video-intel N/A
  version.xserver-xorg-video-nouveau: xserver-xorg-video-nouveau N/A

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/xorg/+bug/1944951/+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 1944951] Re: delayed display update / konsole artifacts

2021-09-24 Thread Horst Schirmeier
I went back to konsole 20.04.0 (built from upstream sources) and still
see these artifacts.  Consequently, something else in the xorg/KDE
software stack must be responsible; I'm not sure how to proceed with
debugging, though.

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

Title:
  delayed display update / konsole artifacts

Status in xorg package in Ubuntu:
  New

Bug description:
  Since one of the recent Impish updates, konsole shows artifacts and
  reacts slowly.  In fact, it looks like screen updates are pipelined on
  pixel-group granularity somehow, and the pipeline isn't drained
  completely: When more text goes to the terminal (e.g., I type
  something), existing artifacts vanish, but new ones (in the new text)
  appear.

  Unfortunately, I don't see any of the previous konsole .deb releases
  (e.g. 4:21.08.1-1 or 4:21.08.0-1) on the Ubuntu mirrors, so I cannot
  go back and simply check whether the newest konsole updates are the
  culprit.  I'm actually not sure whether konsole is responsible at all,
  I originally intended to file against xorg; however, I see those
  artifacts in neither xterm nor gnome-terminal.

  Find attached a screenshot (taken with an external camera; these
  artifacts cannot be recorded using a screenshot tool such as
  imagemagick's "import") where I ran "ls" in /tmp, and cleared the
  terminal with ^L afterwards.  The screen is still littered with
  remains of the "ls" output.  It took a few tries to get artifacts this
  pronounced, though; usually they only concern small parts of the
  terminal.

  ProblemType: Bug
  DistroRelease: Ubuntu 21.10
  Package: xorg 1:7.7+22ubuntu1
  ProcVersionSignature: Ubuntu 5.13.0-16.16-generic 5.13.13
  Uname: Linux 5.13.0-16-generic x86_64
  ApportVersion: 2.20.11-0ubuntu69
  Architecture: amd64
  CasperMD5CheckResult: unknown
  CompizPlugins: No value set for 
`/apps/compiz-1/general/screen0/options/active_plugins'
  CompositorRunning: None
  CurrentDesktop: KDE
  Date: Fri Sep 24 08:09:18 2021
  DistUpgraded: 2021-08-08 15:09:23,066 DEBUG Running PostInstallScript: 
'/usr/lib/ubuntu-advantage/upgrade_lts_contract.py'
  DistroCodename: impish
  DistroVariant: ubuntu
  GraphicsCard:
   Intel Corporation HD Graphics 530 [8086:191b] (rev 06) (prog-if 00 [VGA 
controller])
 Subsystem: Lenovo HD Graphics 530 [17aa:5050]
 Subsystem: Lenovo GM108M [GeForce 940MX] [17aa:5050]
  InstallationDate: Installed on 2016-11-26 (1762 days ago)
  InstallationMedia: Kubuntu 16.10 "Yakkety Yak" - Release amd64 (20161012.1)
  MachineType: LENOVO 20FXS05500
  ProcKernelCmdLine: BOOT_IMAGE=/vmlinuz-5.13.0-16-generic 
root=/dev/mapper/vgubuntu-root ro kopt=root=/dev/mapper/vgubuntu-root 
resume=/dev/mapper/vgubuntu-swap nouveau.runpm=0 mitigations=off 
i915.i915_enable_fbc=0
  SourcePackage: xorg
  UpgradeStatus: Upgraded to impish on 2021-08-08 (46 days ago)
  dmi.bios.date: 10/24/2019
  dmi.bios.release: 2.30
  dmi.bios.vendor: LENOVO
  dmi.bios.version: R07ET90W (2.30 )
  dmi.board.asset.tag: Not Available
  dmi.board.name: 20FXS05500
  dmi.board.vendor: LENOVO
  dmi.board.version: Not Defined
  dmi.chassis.asset.tag: No Asset Information
  dmi.chassis.type: 10
  dmi.chassis.vendor: LENOVO
  dmi.chassis.version: None
  dmi.ec.firmware.release: 1.5
  dmi.modalias: 
dmi:bvnLENOVO:bvrR07ET90W(2.30):bd10/24/2019:br2.30:efr1.5:svnLENOVO:pn20FXS05500:pvrThinkPadT460p:skuLENOVO_MT_20FX_BU_Think_FM_ThinkPadT460p:rvnLENOVO:rn20FXS05500:rvrNotDefined:cvnLENOVO:ct10:cvrNone:
  dmi.product.family: ThinkPad T460p
  dmi.product.name: 20FXS05500
  dmi.product.sku: LENOVO_MT_20FX_BU_Think_FM_ThinkPad T460p
  dmi.product.version: ThinkPad T460p
  dmi.sys.vendor: LENOVO
  version.compiz: compiz N/A
  version.libdrm2: libdrm2 2.4.107-1
  version.libgl1-mesa-dri: libgl1-mesa-dri 21.2.1-2ubuntu2
  version.libgl1-mesa-glx: libgl1-mesa-glx 21.2.1-2ubuntu2
  version.xserver-xorg-core: xserver-xorg-core 2:1.20.13-1ubuntu1
  version.xserver-xorg-input-evdev: xserver-xorg-input-evdev 1:2.10.6-2build1
  version.xserver-xorg-video-ati: xserver-xorg-video-ati 1:19.1.0-2
  version.xserver-xorg-video-intel: xserver-xorg-video-intel N/A
  version.xserver-xorg-video-nouveau: xserver-xorg-video-nouveau N/A

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/xorg/+bug/1944951/+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 1944951] [NEW] delayed display update / konsole artifacts

2021-09-24 Thread Horst Schirmeier
Public bug reported:

Since one of the recent Impish updates, konsole shows artifacts and
reacts slowly.  In fact, it looks like screen updates are pipelined on
pixel-group granularity somehow, and the pipeline isn't drained
completely: When more text goes to the terminal (e.g., I type
something), existing artifacts vanish, but new ones (in the new text)
appear.

Unfortunately, I don't see any of the previous konsole .deb releases
(e.g. 4:21.08.1-1 or 4:21.08.0-1) on the Ubuntu mirrors, so I cannot go
back and simply check whether the newest konsole updates are the
culprit.  I'm actually not sure whether konsole is responsible at all, I
originally intended to file against xorg; however, I see those artifacts
in neither xterm nor gnome-terminal.

Find attached a screenshot (taken with an external camera; these
artifacts cannot be recorded using a screenshot tool such as
imagemagick's "import") where I ran "ls" in /tmp, and cleared the
terminal with ^L afterwards.  The screen is still littered with remains
of the "ls" output.  It took a few tries to get artifacts this
pronounced, though; usually they only concern small parts of the
terminal.

ProblemType: Bug
DistroRelease: Ubuntu 21.10
Package: xorg 1:7.7+22ubuntu1
ProcVersionSignature: Ubuntu 5.13.0-16.16-generic 5.13.13
Uname: Linux 5.13.0-16-generic x86_64
ApportVersion: 2.20.11-0ubuntu69
Architecture: amd64
CasperMD5CheckResult: unknown
CompizPlugins: No value set for 
`/apps/compiz-1/general/screen0/options/active_plugins'
CompositorRunning: None
CurrentDesktop: KDE
Date: Fri Sep 24 08:09:18 2021
DistUpgraded: 2021-08-08 15:09:23,066 DEBUG Running PostInstallScript: 
'/usr/lib/ubuntu-advantage/upgrade_lts_contract.py'
DistroCodename: impish
DistroVariant: ubuntu
GraphicsCard:
 Intel Corporation HD Graphics 530 [8086:191b] (rev 06) (prog-if 00 [VGA 
controller])
   Subsystem: Lenovo HD Graphics 530 [17aa:5050]
   Subsystem: Lenovo GM108M [GeForce 940MX] [17aa:5050]
InstallationDate: Installed on 2016-11-26 (1762 days ago)
InstallationMedia: Kubuntu 16.10 "Yakkety Yak" - Release amd64 (20161012.1)
MachineType: LENOVO 20FXS05500
ProcKernelCmdLine: BOOT_IMAGE=/vmlinuz-5.13.0-16-generic 
root=/dev/mapper/vgubuntu-root ro kopt=root=/dev/mapper/vgubuntu-root 
resume=/dev/mapper/vgubuntu-swap nouveau.runpm=0 mitigations=off 
i915.i915_enable_fbc=0
SourcePackage: xorg
UpgradeStatus: Upgraded to impish on 2021-08-08 (46 days ago)
dmi.bios.date: 10/24/2019
dmi.bios.release: 2.30
dmi.bios.vendor: LENOVO
dmi.bios.version: R07ET90W (2.30 )
dmi.board.asset.tag: Not Available
dmi.board.name: 20FXS05500
dmi.board.vendor: LENOVO
dmi.board.version: Not Defined
dmi.chassis.asset.tag: No Asset Information
dmi.chassis.type: 10
dmi.chassis.vendor: LENOVO
dmi.chassis.version: None
dmi.ec.firmware.release: 1.5
dmi.modalias: 
dmi:bvnLENOVO:bvrR07ET90W(2.30):bd10/24/2019:br2.30:efr1.5:svnLENOVO:pn20FXS05500:pvrThinkPadT460p:skuLENOVO_MT_20FX_BU_Think_FM_ThinkPadT460p:rvnLENOVO:rn20FXS05500:rvrNotDefined:cvnLENOVO:ct10:cvrNone:
dmi.product.family: ThinkPad T460p
dmi.product.name: 20FXS05500
dmi.product.sku: LENOVO_MT_20FX_BU_Think_FM_ThinkPad T460p
dmi.product.version: ThinkPad T460p
dmi.sys.vendor: LENOVO
version.compiz: compiz N/A
version.libdrm2: libdrm2 2.4.107-1
version.libgl1-mesa-dri: libgl1-mesa-dri 21.2.1-2ubuntu2
version.libgl1-mesa-glx: libgl1-mesa-glx 21.2.1-2ubuntu2
version.xserver-xorg-core: xserver-xorg-core 2:1.20.13-1ubuntu1
version.xserver-xorg-input-evdev: xserver-xorg-input-evdev 1:2.10.6-2build1
version.xserver-xorg-video-ati: xserver-xorg-video-ati 1:19.1.0-2
version.xserver-xorg-video-intel: xserver-xorg-video-intel N/A
version.xserver-xorg-video-nouveau: xserver-xorg-video-nouveau N/A

** Affects: xorg (Ubuntu)
 Importance: Undecided
 Status: New


** Tags: amd64 apport-bug impish ubuntu

** Attachment added: "screenshot-konsole-artifacts.jpg"
   
https://bugs.launchpad.net/bugs/1944951/+attachment/5527627/+files/screenshot-konsole-artifacts.jpg

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

Title:
  delayed display update / konsole artifacts

Status in xorg package in Ubuntu:
  New

Bug description:
  Since one of the recent Impish updates, konsole shows artifacts and
  reacts slowly.  In fact, it looks like screen updates are pipelined on
  pixel-group granularity somehow, and the pipeline isn't drained
  completely: When more text goes to the terminal (e.g., I type
  something), existing artifacts vanish, but new ones (in the new text)
  appear.

  Unfortunately, I don't see any of the previous konsole .deb releases
  (e.g. 4:21.08.1-1 or 4:21.08.0-1) on the Ubuntu mirrors, so I cannot
  go back and simply check whether the newest konsole updates are the
  culprit.  I'm actually not sure whether konsole is responsible at all,
  I originally intended to file against xorg; however, I see those
  artifacts in neithe

[Touch-packages] [Bug 1944712] Re: systemd/237-3ubuntu10.52 ADT test failure with linux-aws-5.4/5.4.0-1057.60~18.04.1

2021-09-24 Thread Lukas Märdian
In more recent kernels (i.e. linux-meta-aws/azure 5.13) I can see
messages like this: " watchdog: BUG: soft lockup - CPU#3 stuck for
238s!" that seems to indicate the kernel is not giving back control to
the userspace/systemd.

Also a message about a missing autofs4 module, that might be related:
"systemd[1]: Failed to find module 'autofs4'"

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

Title:
  systemd/237-3ubuntu10.52 ADT test failure with linux-
  aws-5.4/5.4.0-1057.60~18.04.1

Status in linux-aws-5.4 package in Ubuntu:
  Confirmed
Status in systemd package in Ubuntu:
  Confirmed

Bug description:
  This is a scripted bug report about ADT failures while running systemd
  tests for linux-aws-5.4/5.4.0-1057.60~18.04.1 on bionic. Whether this
  is caused by the dep8 tests of the tested source or the kernel has yet
  to be determined.

  Testing failed on:
  amd64: 
https://autopkgtest.ubuntu.com/results/autopkgtest-bionic/bionic/amd64/s/systemd/20210923_022411_52338@/log.gz

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/linux-aws-5.4/+bug/1944712/+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 1944764] Re: APN command line : 'username' and 'user' are transposed

2021-09-24 Thread Sebastien Bacher
Thank you for your bug report, it seems like the page has been reworked
in newer version and that isn't an issue anymore

https://manpages.ubuntu.com/manpages/focal/man1/nmcli.1.html

** Changed in: network-manager (Ubuntu)
   Importance: Undecided => Low

** Changed in: network-manager (Ubuntu)
   Status: New => Fix Released

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

Title:
  APN command line : 'username' and 'user' are transposed

Status in network-manager package in Ubuntu:
  Fix Released

Bug description:
  Pertains to the following man page's Connection Management Commands section : 
 
 https://manpages.ubuntu.com/manpages/xenial/man1/nmcli.1.html

  Man page currently shows:

 type gsm [apn APN] [username user] [password passwd]

 apn
 APN - GSM Access Point Name.

 user
 user name.

 password
 password.

 type cdma [username user] [password passwd]

 user
 user name.

 password
 password.


  The man page should be corrected to show:

 type gsm [apn APN] [user username] [password passwd]

 type cdma [user username] [password passwd]


  
  I suggest correcting the man page so it's correct for people trying to use 
this version of Ubuntu.

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/network-manager/+bug/1944764/+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