date:20230405

To clarify, you are saying that this issue occurs any time you run
`systemctl daemon-reexec`, right? It is not isolated to that command
being run during a package upgrade?

I am not familiar with OpenVZ, but I am confused by the kernel
situation. Are you saying that the containers which are running Ubuntu
(and where you are seeing this problem) are running different kernels
than the host?

Like I said, I am not familiar with OpenVZ, but from my understanding of
other container environments like LXD, I would expect the containers to
share the host's kerenl (and therefore report the same uname -a output).

** Also affects: systemd (Ubuntu Jammy)
   Importance: Undecided
   Status: New

** Changed in: systemd (Ubuntu Jammy)
   Status: New => Incomplete

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

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

Title:
  systemctl daemon-reexec forgets running services and starts everything
  new

Status in systemd package in Ubuntu:
  Incomplete
Status in systemd source package in Jammy:
  Incomplete

Bug description:
  # Our problem #

  During a regular update of our container environment, `systemd` (and
  the related packages libpam-systemd, libsystemd0, libudev1, systemd-
  sysv and udev) were updated from `249.11-0ubuntu3.6` to
  `249.11-0ubuntu3.7`. We're talking only about Ubuntu 22.04. Our Ubuntu
  20.04 is working fine with `systemctl daemon-reexec`.

  In my opinion, the update was not the problem because we've tried
  downgrading and tried these versions: (current) `249.11-0ubuntu3.7`,
  `249.11-0ubuntu3.6`, `249.11-0ubuntu3.4` and `249.11-0ubuntu3.3`. The
  symptoms were the same.

  # Symptoms #

  The `/var/lib/dpkg/info/systemd.postinst` executes a `systemctl
  daemon-reexec` and that ended in a disaster. It seems that `systemd`
  is forgetting all it started children and tries to start nearly every
  configured service again. Naturally, the old services are still
  running, and the ports can't be opened twice and `systemd` won't give
  up. Here are some(!) of the logfiles:

  Mar 31 12:51:39 FQDN_REDACTED systemd[1]: Starting Create Volatile Files and 
Directories...
  Mar 31 12:51:39 FQDN_REDACTED systemd[1]: systemd-udevd.service: Found 
left-over process 130 (systemd-udevd) in control group while starting unit. 
Ignoring.
  Mar 31 12:51:39 FQDN_REDACTED systemd[1]: This usually indicates unclean 
termination of a previous run, or service implementation deficiencies.
  Mar 31 12:51:39 FQDN_REDACTED systemd[1]: systemd-udevd.service: Found 
left-over process 31475 (systemd-udevd) in control group while starting unit. 
Ignoring.
  Mar 31 12:51:39 FQDN_REDACTED systemd[1]: This usually indicates unclean 
termination of a previous run, or service implementation deficiencies.
  Mar 31 12:51:39 FQDN_REDACTED systemd[1]: systemd-udevd.service: Found 
left-over process 31476 (systemd-udevd) in control group while starting unit. 
Ignoring.
  Mar 31 12:51:39 FQDN_REDACTED systemd[1]: This usually indicates unclean 
termination of a previous run, or service implementation deficiencies.

  And...

  Mar 31 12:51:39 FQDN_REDACTED systemd[1]: Reached target System 
Initialization.
  Mar 31 12:51:39 FQDN_REDACTED systemd[1]: Started Daily apt download 
activities.
  Mar 31 12:51:39 FQDN_REDACTED systemd[1]: Started Daily apt upgrade and clean 
activities.
  Mar 31 12:51:39 FQDN_REDACTED systemd[1]: Started Daily dpkg database backup 
timer.
  Mar 31 12:51:39 FQDN_REDACTED systemd[1]: Started Periodic ext4 Online 
Metadata Check for All Filesystems.
  Mar 31 12:51:39 FQDN_REDACTED systemd[1]: Condition check resulted in Discard 
unused blocks once a week being skipped.
  Mar 31 12:51:39 FQDN_REDACTED systemd[1]: Started Daily rotation of log files.
  Mar 31 12:51:39 FQDN_REDACTED systemd[1]: Started Daily man-db regeneration.
  Mar 31 12:51:39 FQDN_REDACTED systemd[1]: Started Message of the Day.
  Mar 31 12:51:39 FQDN_REDACTED systemd[1]: Started Clean PHP session files 
every 30 mins.
  Mar 31 12:51:39 FQDN_REDACTED systemd[1]: Started Update the plocate database 
daily.
  Mar 31 12:51:39 FQDN_REDACTED systemd[1]: Started Daily Cleanup of Temporary 
Directories.
  Mar 31 12:51:39 FQDN_REDACTED systemd[1]: Reached target Basic System.
  Mar 31 12:51:39 FQDN_REDACTED systemd[1]: System is tainted: cgroupsv1
  Mar 31 12:51:39 FQDN_REDACTED systemd[1]: Reached target Timer Units.

  And...

  Mar 31 12:51:39 FQDN_REDACTED systemd[1]: atd.service: Found left-over 
process 206 (atd) in control group while starting unit. Ignoring.
  Mar 31 12:51:39 FQDN_REDACTED systemd[1]: This usually indicates unclean 
termination of a previous run, or service implementation deficiencies.
  Mar 31 12:51:39 FQDN_REDACTED systemd[1]: Starting Deferred execution 
scheduler...
  Mar 31 12:51:39 FQDN_REDACTED systemd[1]: cron.service:

[Touch-packages] [Bug 1981697] Re: KDC: weak crypto in default settings

** Merge proposal linked:
   
https://code.launchpad.net/~ahasenack/ubuntu/+source/krb5/+git/krb5/+merge/440427

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

Title:
  KDC: weak crypto in default settings

Status in krb5 package in Ubuntu:
  Fix Released
Status in krb5 source package in Jammy:
  In Progress
Status in krb5 source package in Kinetic:
  Fix Released
Status in krb5 package in Debian:
  Fix Released

Bug description:
  [ Impact ]

  The default crypto algorithm suite selected for the master key in the
  ubuntu krb5-kdc package is des3-hmac-sha1. This comes from a config
  file shipped with the packaging which overrides upstream's default
  choice.

  Users who deploy a KDC using this package will be using an algorithm
  deprecated since many years ago, and considered broken nowadays for
  security applications. Furthermore, the KDC will highlight this fact
  with "deprecated" warnings in the logs and elsewhere. For example:

  root@j-kdc-weak-crypto:~# klist -ke /etc/krb5kdc/stash
  Keytab name: FILE:/etc/krb5kdc/stash
  KVNO Principal
   
--
     1 K/M@LXD (DEPRECATED:des3-cbc-sha1)

  And in the kdc logs:
  Apr 05 14:20:01 j-kdc-weak-crypto krb5kdc[7323]: Stash file 
/etc/krb5kdc/stash uses DEPRECATED enctype des3-cbc-sha1!

  This update removes the specification of an algorithm and leaves it to
  the upstream default, which is aes256-cts-hmac-sha1-96[1].

  Kerberos is quite conservative when it comes to updating encryption
  algorithms, and one could argue that the default should be something
  like aes256-cts-hmac-sha384-192, but in this SRU we are sticking to
  the upstream default (by not specifying any value). This is also what
  debian is doing, and what we have in kinetic and later.

  1. https://manpages.ubuntu.com/manpages/jammy/man5/kdc.conf.5.html
  search for "master_key_type"

  [ Test Plan ]

  The test plan will involve two main aspects:
  - upgrades must not change the existing encryption type, and won't get a dpkg 
conf prompt
  - fresh installs must use the new crypto algorithm

  a) Upgrade does not change algorithm
  Start by installing a kdc with the released packages (not from proposed):

  # When prompted, accept the defaults
  sudo apt install krb5-kdc krb5-admin-server

  # Verify that master_key_type is set to the deprecated des3-hmac-sha1 value:
  $ sudo grep master_key_type /etc/krb5kdc/kdc.conf
  master_key_type = des3-hmac-sha1

  # bootstrap a new realm, type in a password of your choosing (you
  won't need it again):

  $ sudo krb5_newrealm

  # Verify the actual encryption used in the stash file and confirm it's
  the same, and that you get a DEPRECATED warning:

  $ sudo klist -ke /etc/krb5kdc/stash
  Keytab name: FILE:/etc/krb5kdc/stash
  KVNO Principal
   
--
     1 K/M@LXD (DEPRECATED:des3-cbc-sha1)

  # Upgrade to the packages in proposed. Confirm there is no dpkg conf
  prompt, and repeat the two checks above (the grep, and the klist
  command). Their output must not have changed, i.e., the system will
  still be using the deprecated 3des-sha1 algorithm for the master
  key/stash file.

  b) Fresh install of proposed packages

  # Perform a fresh install of the packages in proposed. As before,
  accept the defaults when asked debconf questions:

  sudo apt install krb5-kdc krb5-admin-server

  # Verify that the master_key_type is now commented ("#" in front) and no 
longer shows the deprecated "3des-hmac-sha1" value, but instead shows 
"aes256-cts":
  $ sudo grep master_key_type /etc/krb5kdc/kdc.conf
  #master_key_type = aes256-cts

  # bootstrap a new realm, type in a password of your choosing (you
  won't need it again):

  $ sudo krb5_newrealm

  # Verify the actual encryption used in the stash file, and confirm
  it's no longer "des3-cbc-sha1", but instead "aes256-cts-hmac-sha1-96":

  $ sudo klist -ke /etc/krb5kdc/stash
  Keytab name: FILE:/etc/krb5kdc/stash
  KVNO Principal
   
--
     1 K/M@LXD (aes256-cts-hmac-sha1-96)

  [ Where problems could occur ]

  The crypto that is being changed for new fresh installations affects
  the /etc/krb5kdc/stash file[2], and the K/M@REALM principal key (which
  are the same: it's called the master key). This is the key that
  encrypts the database.

  For deployments with a primary KDC and a secondary KDC (replication),
  the stash file has to be copied to the secondary so that it can
  decrypt the replicated database. If that secondary has no support for
  the crypto algorithm that was chosen for the stash file (for example,
  it could be an older KDC version that only supports 3des-sha1, and not
  aes256), then it won't be able to decrypt

[Touch-packages] [Bug 1981697] Re: KDC: weak crypto in default settings

** Description changed:

  [ Impact ]
  
  The default crypto algorithm suite selected for the master key in the
  ubuntu krb5-kdc package is des3-hmac-sha1. This comes from a config file
  shipped with the packaging which overrides upstream's default choice.
  
  Users who deploy a KDC using this package will be using an algorithm
  deprecated since many years ago, and considered broken nowadays for
  security applications. Furthermore, the KDC will highlight this fact
  with "deprecated" warnings in the logs and elsewhere. For example:
  
  root@j-kdc-weak-crypto:~# klist -ke /etc/krb5kdc/stash
  Keytab name: FILE:/etc/krb5kdc/stash
  KVNO Principal
   
--
     1 K/M@LXD (DEPRECATED:des3-cbc-sha1)
  
  And in the kdc logs:
  Apr 05 14:20:01 j-kdc-weak-crypto krb5kdc[7323]: Stash file 
/etc/krb5kdc/stash uses DEPRECATED enctype des3-cbc-sha1!
  
  This update removes the specification of an algorithm and leaves it to
  the upstream default, which is aes256-cts-hmac-sha1-96[1].
  
  Kerberos is quite conservative when it comes to updating encryption
  algorithms, and one could argue that the default should be something
  like aes256-cts-hmac-sha384-192, but in this SRU we are sticking the
  upstream default (by not specifying any value). This is also what debian
  is doing, and what we have in kinetic and later.
  
  1. https://manpages.ubuntu.com/manpages/jammy/man5/kdc.conf.5.html
  search for "master_key_type"
  
  [ Test Plan ]
  
  The test plan will involve two main aspects:
  - upgrades must not change the existing encryption type, and won't get a dpkg 
conf prompt
  - fresh installs must use the new crypto algorithm
  
  a) Upgrade does not change algorithm
  Start by installing a kdc with the released packages (not from proposed):
  
  # When prompted, accept the defaults
  sudo apt install krb5-kdc krb5-admin-server
  
  # Verify that master_key_type is set to the deprecated des3-hmac-sha1 value:
  $ sudo grep master_key_type /etc/krb5kdc/kdc.conf
  master_key_type = des3-hmac-sha1
  
  # bootstrap a new realm, type in a password of your choosing (you won't
  need it again):
  
  $ sudo krb5_newrealm
  
  # Verify the actual encryption used in the stash file and confirm it's
  the same, and that you get a DEPRECATED warning:
  
  $ sudo klist -ke /etc/krb5kdc/stash
  Keytab name: FILE:/etc/krb5kdc/stash
  KVNO Principal
   
--
     1 K/M@LXD (DEPRECATED:des3-cbc-sha1)
  
  # Upgrade to the packages in proposed. Confirm there is no dpkg conf
  prompt, and repeat the two checks above (the grep, and the klist
  command). Their output must not have changed.
  
  b) Fresh install of proposed packages
  
  # Perform a fresh install of the packages in proposed. As before, accept
  the defaults when asked debconf questions:
  
  sudo apt install krb5-kdc krb5-admin-server
  
  # Verify that the master_key_type is now commented ("#" in front) and no 
longer shows the deprecated "3des-hmac-sha1" value, but instead shows 
"aes256-cts":
  $ sudo grep master_key_type /etc/krb5kdc/kdc.conf
  #master_key_type = aes256-cts
  
  # bootstrap a new realm, type in a password of your choosing (you won't
  need it again):
  
  $ sudo krb5_newrealm
  
  # Verify the actual encryption used in the stash file, and confirm it's
  no longer "des3-cbc-sha1", but instead "aes256-cts-hmac-sha1-96":
  
  $ sudo klist -ke /etc/krb5kdc/stash
  Keytab name: FILE:/etc/krb5kdc/stash
  KVNO Principal
   
--
     1 K/M@LXD (aes256-cts-hmac-sha1-96)
  
  [ Where problems could occur ]
  
-  * Think about what the upload changes in the software. Imagine the change is
-    wrong or breaks something else: how would this show up?
+ The crypto that is being changed for new fresh installations affects the
+ /etc/krb5kdc/stash file[2], and the K/M@REALM principal key (which are
+ the same: it's called the master key). This is the key that encrypts the
+ database.
  
-  * It is assumed that any SRU candidate patch is well-tested before
-    upload and has a low overall risk of regression, but it's important
-    to make the effort to think about what ''could'' happen in the
-    event of a regression.
+ For deployments with a primary KDC and a secondary KDC (replication),
+ the stash file has to be copied to the secondary so that it can decrypt
+ the replicated database. If that secondary has no support for the crypto
+ algorithm that was chosen for the stash file (for example, it could be
+ an older KDC version that only supports 3des-sha1, and not aes256), then
+ it won't be able to decrypt it, and thus won't be able to read the
+ database.
  
-  * This must '''never''' be "None" or "Low", or entirely an argument as to why
-    your upload is low risk.
  
-  * This both shows the SRU team that the

[Touch-packages] [Bug 2015355] Re: Please backport patches for false atari partition detection to Ubuntu 20.04

2023-04-05 Thread oldman

I did a test dpkg-buildpackage after applying the patch and confirmed
the fix works as expected.

With libblkid1 2.34-0.1ubuntu9.3
$ blkid example.img
example.img: UUID="b4290c76-d481-4c8b-8407-8e7b6c3f11d5" TYPE="crypto_LUKS" 
PTTYPE="atari"
# wipefs example.img
DEVICE  OFFSET TYPEUUID LABEL
example.img 0x0crypto_LUKS b4290c76-d481-4c8b-8407-8e7b6c3f11d5
example.img 0x4000 crypto_LUKS b4290c76-d481-4c8b-8407-8e7b6c3f11d5
example.img 0x1c6  atari

Imported patch and bumped dch to build 2.34-0.1ubuntu9.4

curl --fail -sSL -o debian/patches/2015355.patch 
"https://bugs.launchpad.net/ubuntu/+source/util-linux/+bug/2015355/+attachment/5661201/+files/2015355.patch;
quilt import debian/patches/2015355.patch
quilt push -a && quilt refresh && quilt pop -a
dch -n "Apply atari fix from #2015355."
dpkg-buildpackage -us -uc

Tested with libblkid1 2.34-0.1ubuntu9.4
# blkid  example.img
example.img: UUID="b4290c76-d481-4c8b-8407-8e7b6c3f11d5" TYPE="crypto_LUKS"
# wipefs example.img
DEVICE  OFFSET TYPEUUID LABEL
example.img 0x0crypto_LUKS b4290c76-d481-4c8b-8407-8e7b6c3f11d5
example.img 0x4000 crypto_LUKS b4290c76-d481-4c8b-8407-8e7b6c3f11d5

(no more false positive PTTYPE="atari")

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

Title:
  Please backport patches for false atari partition detection to Ubuntu
  20.04

Status in util-linux package in Ubuntu:
  New

Bug description:
  There are three patches in util-linux upstream that were released in
  util-linux 2.37 and prevent false detection of the atari partition
  table with blkid and wipefs. We see this mostly on LUKS devices
  initialised via luksFormat reporting there is an atari partition table
  on the device when it is empty. This causes issues in various places,
  but one key example for us is in kubernetes where mount-utils will
  refuse to format the device (https://github.com/kubernetes/mount-
  utils/blob/732a08ae47571516020ef99c303c70c1fa5b3e6c/mount_linux.go#L437-L441)

  RedHat backported these fixes to RHEL 8 under
  https://bugzilla.redhat.com/show_bug.cgi?id=2060030 and it would be
  helpful if Ubuntu also backported them to Ubuntu 20.04 which is still
  running util-linux 2.34

  The request is to backport patches based on the
  https://github.com/util-linux/util-linux/issues/1159 upstream report.

  Upstream commits to cherry-pick the changes to 
libblkid/src/partitions/atari.c from: 
  2cc76d50d7a14bef8e7b07fab11b26c9e49d36a2
  282ceadc3a72fc07dd0388b8880fd751490bb87f
  c70b4f2a5b99876d230b8f4f413c3bb3ee6647f1

  # lsb_release -a
  Distributor ID: Ubuntu
  Description:Ubuntu 20.04.6 LTS
  Release:20.04
  Codename:   focal
  # blkid -V
  blkid from util-linux 2.34  (libblkid 2.34.0, 14-Jun-2019)
  # blkid -p -s TYPE -s PTTYPE -o export 
/dev/mapper/pvc-7b331195-cd5a-4ab6-8fdc-552af4b9139d_encrypted
  DEVNAME=dev/mapper/pvc-7b331195-cd5a-4ab6-8fdc-552af4b9139d_encrypted
  PTTYPE=atari
  # lsblk
  ...
  sdccrypto_LUKS
 a79d2982-74f2-44c7-bb29-460768ebfe64
  `-3600a09803830474a735d4c63744c4a56crypto_LUKS
 a79d2982-74f2-44c7-bb29-460768ebfe64
`-pvc-7b331195-cd5a-4ab6-8fdc-552af4b9139d_encrypted

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/util-linux/+bug/2015355/+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 2015386] Re: gnome-shell crashes after "switching to" a new user from an existing login

2023-04-05 Thread dann frazier

** Attachment added: "_usr_bin_gnome-shell.1002.crash"
   
https://bugs.launchpad.net/ubuntu/+source/xorg/+bug/2015386/+attachment/5661328/+files/_usr_bin_gnome-shell.1002.crash

** Also affects: gnome-shell (Ubuntu)
   Importance: Undecided
   Status: New

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

Title:
  gnome-shell crashes after "switching to" a new user from an existing
  login

Status in gnome-shell package in Ubuntu:
  New
Status in xorg package in Ubuntu:
  New

Bug description:
  When logged into a desktop session, I created a new user account and
  then tried to "switch to" it. A new gnome session started for that
  user (test1), but after a few seconds, gnome-shell appears to have
  crashed. This only seems to happen on the first attempt to "switch to"
  a new user.

  ProblemType: Bug
  DistroRelease: Ubuntu 22.04
  Package: xorg 1:7.7+23ubuntu2
  ProcVersionSignature: Ubuntu 5.15.0-69.76-generic 5.15.87
  Uname: Linux 5.15.0-69-generic x86_64
  NonfreeKernelModules: nvidia_modeset nvidia
  .proc.driver.nvidia.capabilities.gpu0: Error: path was not a regular file.
  .proc.driver.nvidia.capabilities.gpu1: Error: path was not a regular file.
  .proc.driver.nvidia.capabilities.gpu2: Error: path was not a regular file.
  .proc.driver.nvidia.capabilities.gpu3: Error: path was not a regular file.
  .proc.driver.nvidia.capabilities.mig: Error: path was not a regular file.
  .proc.driver.nvidia.gpus..07.00.0: Error: path was not a regular file.
  .proc.driver.nvidia.gpus..08.00.0: Error: path was not a regular file.
  .proc.driver.nvidia.gpus..0e.00.0: Error: path was not a regular file.
  .proc.driver.nvidia.gpus..0f.00.0: Error: path was not a regular file.
  .proc.driver.nvidia.registry: Binary: ""
  .proc.driver.nvidia.suspend: suspend hibernate resume
  .proc.driver.nvidia.suspend_depth: default modeset uvm
  .proc.driver.nvidia.version:
   NVRM version: NVIDIA UNIX x86_64 Kernel Module  525.89.02  Wed Feb  1 
23:23:25 UTC 2023
   GCC version:
  ApportVersion: 2.20.11-0ubuntu82.3
  Architecture: amd64
  CasperMD5CheckResult: unknown
  Date: Wed Apr  5 17:23:28 2023
  DistUpgraded: Fresh install
  DistroCodename: jammy
  DistroVariant: ubuntu
  ExtraDebuggingInterest: Yes, including running git bisection searches
  MachineType: NVIDIA DGX Station
  ProcEnviron:
   TERM=xterm-256color
   PATH=(custom, no user)
   LANG=C.UTF-8
   SHELL=/bin/bash
  ProcKernelCmdLine: BOOT_IMAGE=/boot/vmlinuz-5.15.0-69-generic 
root=UUID=88df95a6-4fd9-475a-8b59-ad14df1ada5a ro
  SourcePackage: xorg
  Symptom: display
  Title: Xorg crash
  UpgradeStatus: No upgrade log present (probably fresh install)
  dmi.bios.date: 08/27/2018
  dmi.bios.release: 5.11
  dmi.bios.vendor: American Megatrends Inc.
  dmi.bios.version: 0406
  dmi.board.asset.tag: Default string
  dmi.board.name: X99-E-10G WS
  dmi.board.vendor: EMPTY
  dmi.board.version: Rev 1.xx
  dmi.chassis.asset.tag: Default string
  dmi.chassis.type: 3
  dmi.chassis.vendor: EMPTY
  dmi.chassis.version: Default string
  dmi.modalias: 
dmi:bvnAmericanMegatrendsInc.:bvr0406:bd08/27/2018:br5.11:svnNVIDIA:pnDGXStation:pvrSystemVersion:rvnEMPTY:rnX99-E-10GWS:rvrRev1.xx:cvnEMPTY:ct3:cvrDefaultstring:sku920-22587-2510-000:
  dmi.product.family: DGX
  dmi.product.name: DGX Station
  dmi.product.sku: 920-22587-2510-000
  dmi.product.version: System Version
  dmi.sys.vendor: NVIDIA
  version.compiz: compiz N/A
  version.libdrm2: libdrm2 2.4.113-2~ubuntu0.22.04.1
  version.libgl1-mesa-dri: libgl1-mesa-dri 22.2.5-0ubuntu0.1~22.04.1
  version.libgl1-mesa-glx: libgl1-mesa-glx N/A
  version.nvidia-graphics-drivers: nvidia-graphics-drivers-* N/A
  version.xserver-xorg-core: xserver-xorg-core 2:21.1.3-2ubuntu2.9
  version.xserver-xorg-input-evdev: xserver-xorg-input-evdev N/A
  version.xserver-xorg-video-ati: xserver-xorg-video-ati 1:19.1.0-2ubuntu1
  version.xserver-xorg-video-intel: xserver-xorg-video-intel 
2:2.99.917+git20210115-1
  version.xserver-xorg-video-nouveau: xserver-xorg-video-nouveau 
1:1.0.17-2build1

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/gnome-shell/+bug/2015386/+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 2015386] [NEW] gnome-shell crashes after "switching to" a new user from an existing login

2023-04-05 Thread dann frazier

Public bug reported:

When logged into a desktop session, I created a new user account and
then tried to "switch to" it. A new gnome session started for that user
(test1), but after a few seconds, gnome-shell appears to have crashed.
This only seems to happen on the first attempt to "switch to" a new
user.

ProblemType: Bug
DistroRelease: Ubuntu 22.04
Package: xorg 1:7.7+23ubuntu2
ProcVersionSignature: Ubuntu 5.15.0-69.76-generic 5.15.87
Uname: Linux 5.15.0-69-generic x86_64
NonfreeKernelModules: nvidia_modeset nvidia
.proc.driver.nvidia.capabilities.gpu0: Error: path was not a regular file.
.proc.driver.nvidia.capabilities.gpu1: Error: path was not a regular file.
.proc.driver.nvidia.capabilities.gpu2: Error: path was not a regular file.
.proc.driver.nvidia.capabilities.gpu3: Error: path was not a regular file.
.proc.driver.nvidia.capabilities.mig: Error: path was not a regular file.
.proc.driver.nvidia.gpus..07.00.0: Error: path was not a regular file.
.proc.driver.nvidia.gpus..08.00.0: Error: path was not a regular file.
.proc.driver.nvidia.gpus..0e.00.0: Error: path was not a regular file.
.proc.driver.nvidia.gpus..0f.00.0: Error: path was not a regular file.
.proc.driver.nvidia.registry: Binary: ""
.proc.driver.nvidia.suspend: suspend hibernate resume
.proc.driver.nvidia.suspend_depth: default modeset uvm
.proc.driver.nvidia.version:
 NVRM version: NVIDIA UNIX x86_64 Kernel Module  525.89.02  Wed Feb  1 23:23:25 
UTC 2023
 GCC version:
ApportVersion: 2.20.11-0ubuntu82.3
Architecture: amd64
CasperMD5CheckResult: unknown
Date: Wed Apr  5 17:23:28 2023
DistUpgraded: Fresh install
DistroCodename: jammy
DistroVariant: ubuntu
ExtraDebuggingInterest: Yes, including running git bisection searches
MachineType: NVIDIA DGX Station
ProcEnviron:
 TERM=xterm-256color
 PATH=(custom, no user)
 LANG=C.UTF-8
 SHELL=/bin/bash
ProcKernelCmdLine: BOOT_IMAGE=/boot/vmlinuz-5.15.0-69-generic 
root=UUID=88df95a6-4fd9-475a-8b59-ad14df1ada5a ro
SourcePackage: xorg
Symptom: display
Title: Xorg crash
UpgradeStatus: No upgrade log present (probably fresh install)
dmi.bios.date: 08/27/2018
dmi.bios.release: 5.11
dmi.bios.vendor: American Megatrends Inc.
dmi.bios.version: 0406
dmi.board.asset.tag: Default string
dmi.board.name: X99-E-10G WS
dmi.board.vendor: EMPTY
dmi.board.version: Rev 1.xx
dmi.chassis.asset.tag: Default string
dmi.chassis.type: 3
dmi.chassis.vendor: EMPTY
dmi.chassis.version: Default string
dmi.modalias: 
dmi:bvnAmericanMegatrendsInc.:bvr0406:bd08/27/2018:br5.11:svnNVIDIA:pnDGXStation:pvrSystemVersion:rvnEMPTY:rnX99-E-10GWS:rvrRev1.xx:cvnEMPTY:ct3:cvrDefaultstring:sku920-22587-2510-000:
dmi.product.family: DGX
dmi.product.name: DGX Station
dmi.product.sku: 920-22587-2510-000
dmi.product.version: System Version
dmi.sys.vendor: NVIDIA
version.compiz: compiz N/A
version.libdrm2: libdrm2 2.4.113-2~ubuntu0.22.04.1
version.libgl1-mesa-dri: libgl1-mesa-dri 22.2.5-0ubuntu0.1~22.04.1
version.libgl1-mesa-glx: libgl1-mesa-glx N/A
version.nvidia-graphics-drivers: nvidia-graphics-drivers-* N/A
version.xserver-xorg-core: xserver-xorg-core 2:21.1.3-2ubuntu2.9
version.xserver-xorg-input-evdev: xserver-xorg-input-evdev N/A
version.xserver-xorg-video-ati: xserver-xorg-video-ati 1:19.1.0-2ubuntu1
version.xserver-xorg-video-intel: xserver-xorg-video-intel 
2:2.99.917+git20210115-1
version.xserver-xorg-video-nouveau: xserver-xorg-video-nouveau 1:1.0.17-2build1

** Affects: gnome-shell (Ubuntu)
 Importance: Undecided
 Status: New

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


** Tags: amd64 apport-bug crash jammy ubuntu uec-images

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

Title:
  gnome-shell crashes after "switching to" a new user from an existing
  login

Status in gnome-shell package in Ubuntu:
  New
Status in xorg package in Ubuntu:
  New

Bug description:
  When logged into a desktop session, I created a new user account and
  then tried to "switch to" it. A new gnome session started for that
  user (test1), but after a few seconds, gnome-shell appears to have
  crashed. This only seems to happen on the first attempt to "switch to"
  a new user.

  ProblemType: Bug
  DistroRelease: Ubuntu 22.04
  Package: xorg 1:7.7+23ubuntu2
  ProcVersionSignature: Ubuntu 5.15.0-69.76-generic 5.15.87
  Uname: Linux 5.15.0-69-generic x86_64
  NonfreeKernelModules: nvidia_modeset nvidia
  .proc.driver.nvidia.capabilities.gpu0: Error: path was not a regular file.
  .proc.driver.nvidia.capabilities.gpu1: Error: path was not a regular file.
  .proc.driver.nvidia.capabilities.gpu2: Error: path was not a regular file.
  .proc.driver.nvidia.capabilities.gpu3: Error: path was not a regular file.
  .proc.driver.nvidia.capabilities.mig: Error: path was not a regular file.
  .proc.driver.nvidia.gpus..07.00.0: Error: path was not a regular file.

[Touch-packages] [Bug 1981697] Re: KDC: weak crypto in default settings

** Description changed:

  [ Impact ]
  
  The default crypto algorithm suite selected for the master key in the
  ubuntu krb5-kdc package is des3-hmac-sha1. This comes from a config file
  shipped with the packaging which overrides upstream's default choice.
  
  Users who deploy a KDC using this package will be using an algorithm
  deprecated since many years ago, and considered broken nowadays for
  security applications. Furthermore, the KDC will highlight this fact
  with "deprecated" warnings in the logs and elsewhere. For example:
  
  root@j-kdc-weak-crypto:~# klist -ke /etc/krb5kdc/stash
  Keytab name: FILE:/etc/krb5kdc/stash
  KVNO Principal
   
--
     1 K/M@LXD (DEPRECATED:des3-cbc-sha1)
  
  And in the kdc logs:
  Apr 05 14:20:01 j-kdc-weak-crypto krb5kdc[7323]: Stash file 
/etc/krb5kdc/stash uses DEPRECATED enctype des3-cbc-sha1!
  
  This update removes the specification of an algorithm and leaves it to
  the upstream default, which is aes256-cts-hmac-sha1-96[1].
  
  Kerberos is quite conservative when it comes to updating encryption
  algorithms, and one could argue that the default should be something
  like aes256-cts-hmac-sha384-192, but in this SRU we are sticking the
  upstream default (by not specifying any value). This is also what debian
  is doing, and what we have in kinetic and later.
  
  1. https://manpages.ubuntu.com/manpages/jammy/man5/kdc.conf.5.html
  search for "master_key_type"
  
  [ Test Plan ]
  
  The test plan will involve two main aspects:
  - upgrades must not change the existing encryption type, and won't get a dpkg 
conf prompt
  - fresh installs must use the new crypto algorithm
  
  a) Upgrade does not change algorithm
  Start by installing a kdc with the released packages (not from proposed):
  
  # When prompted, accept the defaults
  sudo apt install krb5-kdc krb5-admin-server
  
  # Verify that master_key_type is set to the deprecated des3-hmac-sha1 value:
  $ sudo grep master_key_type /etc/krb5kdc/kdc.conf
  master_key_type = des3-hmac-sha1
  
  # bootstrap a new realm, type in a password of your choosing (you won't
  need it again):
  
  $ sudo krb5_newrealm
  
  # Verify the actual encryption used in the stash file and confirm it's
  the same, and that you get a DEPRECATED warning:
  
  $ sudo klist -ke /etc/krb5kdc/stash
  Keytab name: FILE:/etc/krb5kdc/stash
  KVNO Principal
   
--
     1 K/M@LXD (DEPRECATED:des3-cbc-sha1)
  
  # Upgrade to the packages in proposed. Confirm there is no dpkg conf
  prompt, and repeat the two checks above (the grep, and the klist
  command). Their output must not have changed.
  
  b) Fresh install of proposed packages
  
  # Perform a fresh install of the packages in proposed. As before, accept
  the defaults when asked debconf questions:
  
  sudo apt install krb5-kdc krb5-admin-server
  
  # Verify that the master_key_type is now commented ("#" in front) and no 
longer shows the deprecated "3des-hmac-sha1" value, but instead shows 
"aes256-cts":
  $ sudo grep master_key_type /etc/krb5kdc/kdc.conf
  #master_key_type = aes256-cts
  
  # bootstrap a new realm, type in a password of your choosing (you won't
  need it again):
  
  $ sudo krb5_newrealm
  
  # Verify the actual encryption used in the stash file, and confirm it's
  no longer "des3-cbc-sha1", but instead "aes256-cts-hmac-sha1-96":
  
  $ sudo klist -ke /etc/krb5kdc/stash
  Keytab name: FILE:/etc/krb5kdc/stash
  KVNO Principal
   
--
     1 K/M@LXD (aes256-cts-hmac-sha1-96)
  
  [ Where problems could occur ]
  
   * Think about what the upload changes in the software. Imagine the change is
     wrong or breaks something else: how would this show up?
  
   * It is assumed that any SRU candidate patch is well-tested before
     upload and has a low overall risk of regression, but it's important
     to make the effort to think about what ''could'' happen in the
     event of a regression.
  
   * This must '''never''' be "None" or "Low", or entirely an argument as to why
     your upload is low risk.
  
   * This both shows the SRU team that the risks have been considered,
     and provides guidance to testers in regression-testing the SRU.
  
+ 
  [ Other Info ]
- The master_key_type setting does not affect the crypto algorithms that are 
used for tickets and the like. Even with the deprecated 3des setting, the 
tickets obtained by users will be typically using aes256. The master_key_type 
only affects the crypto algorithm used to protect the stash file.
+ 
+ The master_key_type setting does not affect the crypto algorithms that
+ are used for tickets and the like. Even with the deprecated 3des
+ setting, the tickets obtained by users will be typically using aes256.
+ The master_key_type only affects the crypto

[Touch-packages] [Bug 1981697] Re: KDC: weak crypto in default settings

** Description changed:

  [ Impact ]
  
  The default crypto algorithm suite selected for the master key in the
  ubuntu krb5-kdc package is des3-hmac-sha1. This comes from a config file
  shipped with the packaging which overrides upstream's default choice.
  
  Users who deploy a KDC using this package will be using an algorithm
  deprecated since many years ago, and considered broken nowadays for
  security applications. Furthermore, the KDC will highlight this fact
  with "deprecated" warnings in the logs and elsewhere. For example:
  
  root@j-kdc-weak-crypto:~# klist -ke /etc/krb5kdc/stash
  Keytab name: FILE:/etc/krb5kdc/stash
  KVNO Principal
   
--
     1 K/M@LXD (DEPRECATED:des3-cbc-sha1)
  
  And in the kdc logs:
  Apr 05 14:20:01 j-kdc-weak-crypto krb5kdc[7323]: Stash file 
/etc/krb5kdc/stash uses DEPRECATED enctype des3-cbc-sha1!
  
  This update removes the specification of an algorithm and leaves it to
  the upstream default, which is aes256-cts-hmac-sha1-96[1].
  
  Kerberos is quite conservative when it comes to updating encryption
  algorithms, and one could argue that the default should be something
  like aes256-cts-hmac-sha384-192, but in this SRU we are sticking the
  upstream default (by not specifying any value). This is also what debian
  is doing, and what we have in kinetic and later.
  
  1. https://manpages.ubuntu.com/manpages/jammy/man5/kdc.conf.5.html
  search for "master_key_type"
  
  [ Test Plan ]
  
  The test plan will involve two main aspects:
  - upgrades must not change the existing encryption type, and won't get a dpkg 
conf prompt
  - fresh installs must use the new crypto algorithm
  
  a) Upgrade does not change algorithm
  Start by installing a kdc with the released packages (not from proposed):
  
  # When prompted, accept the defaults
  sudo apt install krb5-kdc krb5-admin-server
  
  # Verify that master_key_type is set to the deprecated des3-hmac-sha1 value:
  $ sudo grep master_key_type /etc/krb5kdc/kdc.conf
  master_key_type = des3-hmac-sha1
  
  # bootstrap a new realm, type in a password of your choosing (you won't
  need it again):
  
  $ sudo krb5_newrealm
  
  # Verify the actual encryption used in the stash file and confirm it's
  the same, and that you get a DEPRECATED warning:
  
  $ sudo klist -ke /etc/krb5kdc/stash
  Keytab name: FILE:/etc/krb5kdc/stash
  KVNO Principal
   
--
     1 K/M@LXD (DEPRECATED:des3-cbc-sha1)
  
  # Upgrade to the packages in proposed. Confirm there is no dpkg conf
  prompt, and repeat the two checks above (the grep, and the klist
  command). Their output must not have changed.
  
  b) Fresh install of proposed packages
  
  # Perform a fresh install of the packages in proposed. As before, accept
  the defaults when asked debconf questions:
  
  sudo apt install krb5-kdc krb5-admin-server
  
  # Verify that the master_key_type is now commented ("#" in front) and no 
longer shows the deprecated "3des-hmac-sha1" value, but instead shows 
"aes256-cts":
  $ sudo grep master_key_type /etc/krb5kdc/kdc.conf
  #master_key_type = aes256-cts
  
  # bootstrap a new realm, type in a password of your choosing (you won't
  need it again):
  
  $ sudo krb5_newrealm
  
  # Verify the actual encryption used in the stash file, and confirm it's
  no longer "des3-cbc-sha1", but instead "aes256-cts-hmac-sha1-96":
  
  $ sudo klist -ke /etc/krb5kdc/stash
  Keytab name: FILE:/etc/krb5kdc/stash
  KVNO Principal
   
--
     1 K/M@LXD (aes256-cts-hmac-sha1-96)
  
  [ Where problems could occur ]
  
   * Think about what the upload changes in the software. Imagine the change is
     wrong or breaks something else: how would this show up?
  
   * It is assumed that any SRU candidate patch is well-tested before
     upload and has a low overall risk of regression, but it's important
     to make the effort to think about what ''could'' happen in the
     event of a regression.
  
   * This must '''never''' be "None" or "Low", or entirely an argument as to why
     your upload is low risk.
  
   * This both shows the SRU team that the risks have been considered,
     and provides guidance to testers in regression-testing the SRU.
  
  [ Other Info ]
- The master_key_type setting does not affect the crypto algorithms that are 
used for tickets and the like. Even with the deprecated 3des setting, the 
tickets obtained by users will be typically using aes256.
+ The master_key_type setting does not affect the crypto algorithms that are 
used for tickets and the like. Even with the deprecated 3des setting, the 
tickets obtained by users will be typically using aes256. The master_key_type 
only affects the crypto algorithm used to protect the stash file.
  
  [ Original Description ]
  
  Default setting in

[Touch-packages] [Bug 2015380] [NEW] slapd crash when using pwdMinDelay of ppolicy

Public bug reported:

Bug reported upstream[1], and confirmed in the mailing list[2].

PR at [3].

From the mailing list post[2], we can see that slapd crashes:
"""
But if I test with a wrong password ( yyy) I got:
root@zeus:/usr/lib/python3/dist-packages# ldapsearch -xLLLZZD
uid=pauloric,ou=users,dc=contatogs,dc=com,dc=br -w yyy |wc -l
ldap_result: Can't contact LDAP server (-1)
0

my openldap stop working.Active: inactive (dead)

root@zeus:/usr/lib/python3/dist-packages# systemctl status -l slapd
○ slapd.service - LSB: OpenLDAP standalone server (Lightweight Director>
 Loaded: loaded (/etc/init.d/slapd; generated)
Drop-In: /usr/lib/systemd/system/slapd.service.d
 └─slapd-remain-after-exit.conf
 Active: inactive (dead) since Tue 2023-04-04 14:44:49 -03; 20s ago
   Docs: man:systemd-sysv-generator(8)
Process: 986673 ExecStart=/etc/init.d/slapd start (code=exited, sta>
Process: 986688 ExecStop=/etc/init.d/slapd stop (code=exited, statu>
CPU: 47ms
"""


1. https://bugs.openldap.org/show_bug.cgi?id=10028
2. 
https://lists.openldap.org/hyperkitty/list/openldap-techni...@openldap.org/thread/3LYIPMT6TYJM4C7NUFXVYJS7YMODB5ZH/
3. https://git.openldap.org/openldap/openldap/-/merge_requests/609

** Affects: openldap (Ubuntu)
 Importance: Medium
 Status: New


** Tags: regression-update

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

Title:
  slapd crash when using pwdMinDelay of ppolicy

Status in openldap package in Ubuntu:
  New

Bug description:
  Bug reported upstream[1], and confirmed in the mailing list[2].

  PR at [3].

  From the mailing list post[2], we can see that slapd crashes:
  """
  But if I test with a wrong password ( yyy) I got:
  root@zeus:/usr/lib/python3/dist-packages# ldapsearch -xLLLZZD
  uid=pauloric,ou=users,dc=contatogs,dc=com,dc=br -w yyy |wc -l
  ldap_result: Can't contact LDAP server (-1)
  0

  my openldap stop working.Active: inactive (dead)

  root@zeus:/usr/lib/python3/dist-packages# systemctl status -l slapd
  ○ slapd.service - LSB: OpenLDAP standalone server (Lightweight Director>
   Loaded: loaded (/etc/init.d/slapd; generated)
  Drop-In: /usr/lib/systemd/system/slapd.service.d
   └─slapd-remain-after-exit.conf
   Active: inactive (dead) since Tue 2023-04-04 14:44:49 -03; 20s ago
 Docs: man:systemd-sysv-generator(8)
  Process: 986673 ExecStart=/etc/init.d/slapd start (code=exited, sta>
  Process: 986688 ExecStop=/etc/init.d/slapd stop (code=exited, statu>
  CPU: 47ms
  """


  1. https://bugs.openldap.org/show_bug.cgi?id=10028
  2. 
https://lists.openldap.org/hyperkitty/list/openldap-techni...@openldap.org/thread/3LYIPMT6TYJM4C7NUFXVYJS7YMODB5ZH/
  3. https://git.openldap.org/openldap/openldap/-/merge_requests/609

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/openldap/+bug/2015380/+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 2012599] Re: tzdata 2023a/2023b/2023c release - Egypt restoring DST

2023-04-05 Thread Benjamin Drung

The successful autopkgtest results can also be seen on
https://autopkgtest.ubuntu.com/packages/tzdata (ignore the failing i386;
this is due to missing dependencies).

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

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

Title:
  tzdata 2023a/2023b/2023c release - Egypt restoring DST

Status in tzdata package in Ubuntu:
  Fix Released
Status in tzdata source package in Bionic:
  Fix Committed
Status in tzdata source package in Focal:
  Fix Committed
Status in tzdata source package in Jammy:
  Fix Committed
Status in tzdata source package in Kinetic:
  Fix Committed
Status in tzdata source package in Lunar:
  Fix Released

Bug description:
  [ Impact ]

  Recently the Egyptian authorities decided to restore DST. The first
  switch after the change is expected to take place on last Friday of
  April. The upstream tzdata 2023a release already reflects this change.

  The 2023a release contains the following changes:

  * Egypt now uses DST again, from April through October.
  * This year Morocco springs forward April 23, not April 30.
  * Palestine delays the start of DST this year.
  * Much of Greenland still uses DST from 2024 on.

  The 2023c release reverts the changes done in 2023b.

  [ Test Plan ]

  Test cases were added to the autopkgtest to cover the testing:

  * python: test_2023a
  * python: test_2023c
  * python: test_systemv_timezones (for releases <= 20.04 LTS)
  * python-icu: test_2023a (only for kinetic, jammy, focal)

  So the test plan is to check that the autopkgtest succeeds.

  Alternatively the python test_2023a can be run manually:

   * Set system timezone to Egypt (e.g. Africa/Cairo).
   * Set system time to 2023-04-27 23:59.
   * Wait and observe what happens at 2023-04-28 0:00

  [Test Case for releases <= 20.04 LTS]

  Additionally, an upstream update of tzdata removed the 'old' SystemV 
timezones, so we should ensure that they are kept in Ubuntu 20.04 LTS and 
earlier releases. This is done by the test_systemv_timezones test case or can 
be checked manually with the following:
  diff <(zdump -v America/Phoenix | cut -d' ' -f2-) <(zdump -v SystemV/MST7 | 
cut -d' ' -f2-)

  [ Where problems could occur ]

   * Systems with incorrect timezone set (e.g. located outside of Egypt
  but still using Egyptian time) may observe unexpected time shift.

  [ Other Info ]

  The autopkgtest for chrony is flaky on jammy and kinetic (see bug
  #2002910).

   * More information with sources:
  
https://en.wikipedia.org/wiki/Daylight_saving_time_in_Egypt#:~:text=Daylight%20saving%20time%20(DST)%20has,(DST)%20as%20of%202023.

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/tzdata/+bug/2012599/+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 2015126] Re: systemd doesn't successfully enforce RuntimeMaxSec for gnome session

Jammy version with my fix is in ppa:enr0n/systemd-249.

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

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

Title:
  systemd doesn't successfully enforce RuntimeMaxSec for gnome session

Status in systemd package in Ubuntu:
  Triaged

Bug description:
  On Jammy, I have configured systemd to set RuntimeMaxSec on certain
  user sessions:

  # cat /run/systemd/transient/session-43.scope 
  # This is a transient unit file, created programmatically via the systemd 
API. Do not edit.
  [Scope]
  Slice=user-1000.slice

  [Unit]
  Description=Session 43 of User xavier
  Wants=user-runtime-dir@1000.service
  Wants=user@1000.service
  After=systemd-logind.service
  After=systemd-user-sessions.service
  After=user-runtime-dir@1000.service
  After=user@1000.service
  RequiresMountsFor=/home/xavier

  [Scope]
  SendSIGHUP=yes
  TasksMax=infinity
  RuntimeMaxSec=2h
  #

  I have verified that this does what's expected on an ssh session, and
  kills the session when the runtime max has been reached.

  But on a GNOME login session (using X), this apparently doesn't work:
  the session is still running 17 hours after it should have been
  terminated.

  My guess is that systemd is ending the session by sending a signal
  that is being ignored by the GNOME login session?

  RuntimeMaxSec is not very useful if it's advisory...

  ProblemType: Bug
  DistroRelease: Ubuntu 22.04
  Package: systemd 249.11-0ubuntu3.7
  ProcVersionSignature: Ubuntu 5.19.0-38.39~22.04.1-generic 5.19.17
  Uname: Linux 5.19.0-38-generic x86_64
  ApportVersion: 2.20.11-0ubuntu82.3
  Architecture: amd64
  CasperMD5CheckResult: pass
  CurrentDesktop: ubuntu:GNOME
  Date: Mon Apr  3 12:20:22 2023
  InstallationDate: Installed on 2023-01-22 (70 days ago)
  InstallationMedia: Ubuntu 22.04.1 LTS "Jammy Jellyfish" - Release amd64 
(20220809.1)
  MachineType: LENOVO 2306CTO
  ProcEnviron:
   TERM=xterm-256color
   PATH=(custom, no user)
   XDG_RUNTIME_DIR=
   LANG=en_US.UTF-8
   SHELL=/bin/bash
  ProcKernelCmdLine: BOOT_IMAGE=/boot/vmlinuz-5.19.0-38-generic 
root=UUID=c415e6a8-5cd2-4d08-913d-14c00b792374 ro quiet splash vt.handoff=7
  SourcePackage: systemd
  UpgradeStatus: No upgrade log present (probably fresh install)
  dmi.bios.date: 10/25/2013
  dmi.bios.release: 2.57
  dmi.bios.vendor: LENOVO
  dmi.bios.version: G2ET97WW (2.57 )
  dmi.board.asset.tag: Not Available
  dmi.board.name: 2306CTO
  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: Not Available
  dmi.ec.firmware.release: 1.13
  dmi.modalias: 
dmi:bvnLENOVO:bvrG2ET97WW(2.57):bd10/25/2013:br2.57:efr1.13:svnLENOVO:pn2306CTO:pvrThinkPadX230:rvnLENOVO:rn2306CTO:rvrNotDefined:cvnLENOVO:ct10:cvrNotAvailable:skuLENOVO_MT_2306:
  dmi.product.family: ThinkPad X230
  dmi.product.name: 2306CTO
  dmi.product.sku: LENOVO_MT_2306
  dmi.product.version: ThinkPad X230
  dmi.sys.vendor: LENOVO

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/systemd/+bug/2015126/+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 2015129] Re: gstreamer 1.22.1 bugfix release

This bug was fixed in the package gstreamer1.0 - 1.22.1-1

---
gstreamer1.0 (1.22.1-1) experimental; urgency=medium

  * Team upload
  * New upstream bugfix release (LP: #2015129)

 -- Jeremy Bicha   Mon, 03 Apr 2023 16:03:42 -0400

** Changed in: gstreamer1.0 (Ubuntu)
   Status: Triaged => Fix Released

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

Title:
  gstreamer 1.22.1 bugfix release

Status in gst-plugins-bad1.0 package in Ubuntu:
  Fix Released
Status in gst-plugins-base1.0 package in Ubuntu:
  Triaged
Status in gst-plugins-good1.0 package in Ubuntu:
  Triaged
Status in gstreamer1.0 package in Ubuntu:
  Fix Released

Bug description:
  Impact
  --
  This is a stable bugfix release

  See https://gstreamer.freedesktop.org/releases/1.22/#1.22.1 for more
  details.

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/gst-plugins-bad1.0/+bug/2015129/+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 2012599] Re: tzdata 2023a/2023b/2023c release - Egypt restoring DST

Bionic verification. Procedure unchanged.

tzdata 2023c-0ubuntu0.18.04

test_2023a (__main__.TestZoneinfo)
Test Egypt uses DST again from 2023a release. ... ok
test_2023c (__main__.TestZoneinfo)
Test Lebanon's reverted DST delay from 2023c release. ... ok
(...)
test_systemv_timezones (__main__.TestZoneinfo)

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

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

Title:
  tzdata 2023a/2023b/2023c release - Egypt restoring DST

Status in tzdata package in Ubuntu:
  Fix Released
Status in tzdata source package in Bionic:
  Fix Committed
Status in tzdata source package in Focal:
  Fix Committed
Status in tzdata source package in Jammy:
  Fix Committed
Status in tzdata source package in Kinetic:
  Fix Committed
Status in tzdata source package in Lunar:
  Fix Released

Bug description:
  [ Impact ]

  Recently the Egyptian authorities decided to restore DST. The first
  switch after the change is expected to take place on last Friday of
  April. The upstream tzdata 2023a release already reflects this change.

  The 2023a release contains the following changes:

  * Egypt now uses DST again, from April through October.
  * This year Morocco springs forward April 23, not April 30.
  * Palestine delays the start of DST this year.
  * Much of Greenland still uses DST from 2024 on.

  The 2023c release reverts the changes done in 2023b.

  [ Test Plan ]

  Test cases were added to the autopkgtest to cover the testing:

  * python: test_2023a
  * python: test_2023c
  * python: test_systemv_timezones (for releases <= 20.04 LTS)
  * python-icu: test_2023a (only for kinetic, jammy, focal)

  So the test plan is to check that the autopkgtest succeeds.

  Alternatively the python test_2023a can be run manually:

   * Set system timezone to Egypt (e.g. Africa/Cairo).
   * Set system time to 2023-04-27 23:59.
   * Wait and observe what happens at 2023-04-28 0:00

  [Test Case for releases <= 20.04 LTS]

  Additionally, an upstream update of tzdata removed the 'old' SystemV 
timezones, so we should ensure that they are kept in Ubuntu 20.04 LTS and 
earlier releases. This is done by the test_systemv_timezones test case or can 
be checked manually with the following:
  diff <(zdump -v America/Phoenix | cut -d' ' -f2-) <(zdump -v SystemV/MST7 | 
cut -d' ' -f2-)

  [ Where problems could occur ]

   * Systems with incorrect timezone set (e.g. located outside of Egypt
  but still using Egyptian time) may observe unexpected time shift.

  [ Other Info ]

  The autopkgtest for chrony is flaky on jammy and kinetic (see bug
  #2002910).

   * More information with sources:
  
https://en.wikipedia.org/wiki/Daylight_saving_time_in_Egypt#:~:text=Daylight%20saving%20time%20(DST)%20has,(DST)%20as%20of%202023.

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/tzdata/+bug/2012599/+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 2015355] Re: Please backport patches for false atari partition detection to Ubuntu 20.04

2023-04-05 Thread Ubuntu Foundations Team Bug Bot

The attachment "2015355.patch" seems to be a patch.  If it isn't, please
remove the "patch" flag from the attachment, remove the "patch" tag, and
if you are a member of the ~ubuntu-reviewers, unsubscribe the team.

[This is an automated message performed by a Launchpad user owned by
~brian-murray, for any issues please contact him.]

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

Title:
  Please backport patches for false atari partition detection to Ubuntu
  20.04

Status in util-linux package in Ubuntu:
  New

Bug description:
  There are three patches in util-linux upstream that were released in
  util-linux 2.37 and prevent false detection of the atari partition
  table with blkid and wipefs. We see this mostly on LUKS devices
  initialised via luksFormat reporting there is an atari partition table
  on the device when it is empty. This causes issues in various places,
  but one key example for us is in kubernetes where mount-utils will
  refuse to format the device (https://github.com/kubernetes/mount-
  utils/blob/732a08ae47571516020ef99c303c70c1fa5b3e6c/mount_linux.go#L437-L441)

  RedHat backported these fixes to RHEL 8 under
  https://bugzilla.redhat.com/show_bug.cgi?id=2060030 and it would be
  helpful if Ubuntu also backported them to Ubuntu 20.04 which is still
  running util-linux 2.34

  The request is to backport patches based on the
  https://github.com/util-linux/util-linux/issues/1159 upstream report.

  Upstream commits to cherry-pick the changes to 
libblkid/src/partitions/atari.c from: 
  2cc76d50d7a14bef8e7b07fab11b26c9e49d36a2
  282ceadc3a72fc07dd0388b8880fd751490bb87f
  c70b4f2a5b99876d230b8f4f413c3bb3ee6647f1

  # lsb_release -a
  Distributor ID: Ubuntu
  Description:Ubuntu 20.04.6 LTS
  Release:20.04
  Codename:   focal
  # blkid -V
  blkid from util-linux 2.34  (libblkid 2.34.0, 14-Jun-2019)
  # blkid -p -s TYPE -s PTTYPE -o export 
/dev/mapper/pvc-7b331195-cd5a-4ab6-8fdc-552af4b9139d_encrypted
  DEVNAME=dev/mapper/pvc-7b331195-cd5a-4ab6-8fdc-552af4b9139d_encrypted
  PTTYPE=atari
  # lsblk
  ...
  sdccrypto_LUKS
 a79d2982-74f2-44c7-bb29-460768ebfe64
  `-3600a09803830474a735d4c63744c4a56crypto_LUKS
 a79d2982-74f2-44c7-bb29-460768ebfe64
`-pvc-7b331195-cd5a-4ab6-8fdc-552af4b9139d_encrypted

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/util-linux/+bug/2015355/+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 2012599] Re: tzdata 2023a/2023b/2023c release - Egypt restoring DST

Same procedure again, this time for focal.

tzdata 2023c-0ubuntu0.20.04.0

test_2023a (__main__.TestZoneinfo)
Test Egypt uses DST again from 2023a release. ... ok
test_2023c (__main__.TestZoneinfo)
Test Lebanon's reverted DST delay from 2023c release. ... ok
(...)
test_2023a (__main__.TestICU)
Test Egypt uses DST again from 2023a release. ... ok

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

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

Title:
  tzdata 2023a/2023b/2023c release - Egypt restoring DST

Status in tzdata package in Ubuntu:
  Fix Released
Status in tzdata source package in Bionic:
  Fix Committed
Status in tzdata source package in Focal:
  Fix Committed
Status in tzdata source package in Jammy:
  Fix Committed
Status in tzdata source package in Kinetic:
  Fix Committed
Status in tzdata source package in Lunar:
  Fix Released

Bug description:
  [ Impact ]

  Recently the Egyptian authorities decided to restore DST. The first
  switch after the change is expected to take place on last Friday of
  April. The upstream tzdata 2023a release already reflects this change.

  The 2023a release contains the following changes:

  * Egypt now uses DST again, from April through October.
  * This year Morocco springs forward April 23, not April 30.
  * Palestine delays the start of DST this year.
  * Much of Greenland still uses DST from 2024 on.

  The 2023c release reverts the changes done in 2023b.

  [ Test Plan ]

  Test cases were added to the autopkgtest to cover the testing:

  * python: test_2023a
  * python: test_2023c
  * python: test_systemv_timezones (for releases <= 20.04 LTS)
  * python-icu: test_2023a (only for kinetic, jammy, focal)

  So the test plan is to check that the autopkgtest succeeds.

  Alternatively the python test_2023a can be run manually:

   * Set system timezone to Egypt (e.g. Africa/Cairo).
   * Set system time to 2023-04-27 23:59.
   * Wait and observe what happens at 2023-04-28 0:00

  [Test Case for releases <= 20.04 LTS]

  Additionally, an upstream update of tzdata removed the 'old' SystemV 
timezones, so we should ensure that they are kept in Ubuntu 20.04 LTS and 
earlier releases. This is done by the test_systemv_timezones test case or can 
be checked manually with the following:
  diff <(zdump -v America/Phoenix | cut -d' ' -f2-) <(zdump -v SystemV/MST7 | 
cut -d' ' -f2-)

  [ Where problems could occur ]

   * Systems with incorrect timezone set (e.g. located outside of Egypt
  but still using Egyptian time) may observe unexpected time shift.

  [ Other Info ]

  The autopkgtest for chrony is flaky on jammy and kinetic (see bug
  #2002910).

   * More information with sources:
  
https://en.wikipedia.org/wiki/Daylight_saving_time_in_Egypt#:~:text=Daylight%20saving%20time%20(DST)%20has,(DST)%20as%20of%202023.

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/tzdata/+bug/2012599/+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 2015373] Re: massive yellow screen color corruption

2023-04-05 Thread Dan

** Description changed:

  using the "try ubuntu" feature, this is what the entire experience looks
- like (see the 2nd attached screenshot in comment #2).
+ like (see the 2nd attached image in comment #2).
  
  ProblemType: Bug
  DistroRelease: Ubuntu 22.04
  Package: xorg 1:7.7+23ubuntu2
  ProcVersionSignature: Ubuntu 5.19.0-32.33~22.04.1-generic 5.19.17
  Uname: Linux 5.19.0-32-generic x86_64
  NonfreeKernelModules: zfs zunicode zavl icp zcommon znvpair
  ApportVersion: 2.20.11-0ubuntu82.3
  Architecture: amd64
  BootLog: Error: [Errno 13] Permission denied: '/var/log/boot.log'
  CasperMD5CheckResult: pass
  CasperVersion: 1.470.2
  CompositorRunning: None
  CurrentDesktop: ubuntu:GNOME
  Date: Wed Apr  5 15:37:32 2023
  DistUpgraded: Fresh install
  DistroCodename: jammy
  DistroVariant: ubuntu
  ExtraDebuggingInterest: Yes
  GraphicsCard:
   NVIDIA Corporation TU104 [GeForce RTX 2060] [10de:1e89] (rev a1) (prog-if 00 
[VGA controller])
     Subsystem: Gigabyte Technology Co., Ltd TU104 [GeForce RTX 2060] 
[1458:402b]
  LiveMediaBuild: Ubuntu 22.04.2 LTS "Jammy Jellyfish" - Release amd64 
(20230223)
  MachineType: To Be Filled By O.E.M. A320M Pro4 R2.0
  ProcEnviron:
   PATH=(custom, no user)
   XDG_RUNTIME_DIR=
   LANG=en_US.UTF-8
   SHELL=/bin/bash
  ProcKernelCmdLine: BOOT_IMAGE=/casper/vmlinuz 
file=/cdrom/preseed/hostname.seed maybe-ubiquity quiet splash ---
  SourcePackage: xorg
  Symptom: display
  UpgradeStatus: No upgrade log present (probably fresh install)
  dmi.bios.date: 10/26/2022
  dmi.bios.release: 5.17
  dmi.bios.vendor: American Megatrends Inc.
  dmi.bios.version: P7.40
  dmi.board.name: A320M Pro4 R2.0
  dmi.board.vendor: ASRock
  dmi.chassis.asset.tag: To Be Filled By O.E.M.
  dmi.chassis.type: 3
  dmi.chassis.vendor: To Be Filled By O.E.M.
  dmi.chassis.version: To Be Filled By O.E.M.
  dmi.modalias: 
dmi:bvnAmericanMegatrendsInc.:bvrP7.40:bd10/26/2022:br5.17:svnToBeFilledByO.E.M.:pnA320MPro4R2.0:pvrToBeFilledByO.E.M.:rvnASRock:rnA320MPro4R2.0:rvr:cvnToBeFilledByO.E.M.:ct3:cvrToBeFilledByO.E.M.:skuToBeFilledByO.E.M.:
  dmi.product.family: To Be Filled By O.E.M.
  dmi.product.name: A320M Pro4 R2.0
  dmi.product.sku: To Be Filled By O.E.M.
  dmi.product.version: To Be Filled By O.E.M.
  dmi.sys.vendor: To Be Filled By O.E.M.
  version.compiz: compiz N/A
  version.libdrm2: libdrm2 2.4.113-2~ubuntu0.22.04.1
  version.libgl1-mesa-dri: libgl1-mesa-dri 22.2.5-0ubuntu0.1~22.04.1
  version.libgl1-mesa-glx: libgl1-mesa-glx N/A
  version.xserver-xorg-core: xserver-xorg-core 2:21.1.3-2ubuntu2.7
  version.xserver-xorg-input-evdev: xserver-xorg-input-evdev N/A
  version.xserver-xorg-video-ati: xserver-xorg-video-ati 1:19.1.0-2ubuntu1
  version.xserver-xorg-video-intel: xserver-xorg-video-intel 
2:2.99.917+git20210115-1
  version.xserver-xorg-video-nouveau: xserver-xorg-video-nouveau 
1:1.0.17-2build1

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

Title:
  massive yellow screen color corruption

Status in xorg package in Ubuntu:
  New

Bug description:
  using the "try ubuntu" feature, this is what the entire experience
  looks like (see the 2nd attached image in comment #2).

  ProblemType: Bug
  DistroRelease: Ubuntu 22.04
  Package: xorg 1:7.7+23ubuntu2
  ProcVersionSignature: Ubuntu 5.19.0-32.33~22.04.1-generic 5.19.17
  Uname: Linux 5.19.0-32-generic x86_64
  NonfreeKernelModules: zfs zunicode zavl icp zcommon znvpair
  ApportVersion: 2.20.11-0ubuntu82.3
  Architecture: amd64
  BootLog: Error: [Errno 13] Permission denied: '/var/log/boot.log'
  CasperMD5CheckResult: pass
  CasperVersion: 1.470.2
  CompositorRunning: None
  CurrentDesktop: ubuntu:GNOME
  Date: Wed Apr  5 15:37:32 2023
  DistUpgraded: Fresh install
  DistroCodename: jammy
  DistroVariant: ubuntu
  ExtraDebuggingInterest: Yes
  GraphicsCard:
   NVIDIA Corporation TU104 [GeForce RTX 2060] [10de:1e89] (rev a1) (prog-if 00 
[VGA controller])
     Subsystem: Gigabyte Technology Co., Ltd TU104 [GeForce RTX 2060] 
[1458:402b]
  LiveMediaBuild: Ubuntu 22.04.2 LTS "Jammy Jellyfish" - Release amd64 
(20230223)
  MachineType: To Be Filled By O.E.M. A320M Pro4 R2.0
  ProcEnviron:
   PATH=(custom, no user)
   XDG_RUNTIME_DIR=
   LANG=en_US.UTF-8
   SHELL=/bin/bash
  ProcKernelCmdLine: BOOT_IMAGE=/casper/vmlinuz 
file=/cdrom/preseed/hostname.seed maybe-ubiquity quiet splash ---
  SourcePackage: xorg
  Symptom: display
  UpgradeStatus: No upgrade log present (probably fresh install)
  dmi.bios.date: 10/26/2022
  dmi.bios.release: 5.17
  dmi.bios.vendor: American Megatrends Inc.
  dmi.bios.version: P7.40
  dmi.board.name: A320M Pro4 R2.0
  dmi.board.vendor: ASRock
  dmi.chassis.asset.tag: To Be Filled By O.E.M.
  dmi.chassis.type: 3
  dmi.chassis.vendor: To Be Filled By O.E.M.
  dmi.chassis.version: To Be Filled By O.E.M.
  dmi.modalias:

[Touch-packages] [Bug 2012599] Re: tzdata 2023a/2023b/2023c release - Egypt restoring DST

Verification for jammy. Same procedure as for kinetic above.

tzdata 2023c-0ubuntu0.22.04.0

test_2023a (__main__.TestZoneinfo)
Test Egypt uses DST again from 2023a release. ... ok
test_2023c (__main__.TestZoneinfo)
Test Lebanon's reverted DST delay from 2023c release. ... ok
(...)
test_2023a (__main__.TestICU)
Test Egypt uses DST again from 2023a release. ... ok


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

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

Title:
  tzdata 2023a/2023b/2023c release - Egypt restoring DST

Status in tzdata package in Ubuntu:
  Fix Released
Status in tzdata source package in Bionic:
  Fix Committed
Status in tzdata source package in Focal:
  Fix Committed
Status in tzdata source package in Jammy:
  Fix Committed
Status in tzdata source package in Kinetic:
  Fix Committed
Status in tzdata source package in Lunar:
  Fix Released

Bug description:
  [ Impact ]

  Recently the Egyptian authorities decided to restore DST. The first
  switch after the change is expected to take place on last Friday of
  April. The upstream tzdata 2023a release already reflects this change.

  The 2023a release contains the following changes:

  * Egypt now uses DST again, from April through October.
  * This year Morocco springs forward April 23, not April 30.
  * Palestine delays the start of DST this year.
  * Much of Greenland still uses DST from 2024 on.

  The 2023c release reverts the changes done in 2023b.

  [ Test Plan ]

  Test cases were added to the autopkgtest to cover the testing:

  * python: test_2023a
  * python: test_2023c
  * python: test_systemv_timezones (for releases <= 20.04 LTS)
  * python-icu: test_2023a (only for kinetic, jammy, focal)

  So the test plan is to check that the autopkgtest succeeds.

  Alternatively the python test_2023a can be run manually:

   * Set system timezone to Egypt (e.g. Africa/Cairo).
   * Set system time to 2023-04-27 23:59.
   * Wait and observe what happens at 2023-04-28 0:00

  [Test Case for releases <= 20.04 LTS]

  Additionally, an upstream update of tzdata removed the 'old' SystemV 
timezones, so we should ensure that they are kept in Ubuntu 20.04 LTS and 
earlier releases. This is done by the test_systemv_timezones test case or can 
be checked manually with the following:
  diff <(zdump -v America/Phoenix | cut -d' ' -f2-) <(zdump -v SystemV/MST7 | 
cut -d' ' -f2-)

  [ Where problems could occur ]

   * Systems with incorrect timezone set (e.g. located outside of Egypt
  but still using Egyptian time) may observe unexpected time shift.

  [ Other Info ]

  The autopkgtest for chrony is flaky on jammy and kinetic (see bug
  #2002910).

   * More information with sources:
  
https://en.wikipedia.org/wiki/Daylight_saving_time_in_Egypt#:~:text=Daylight%20saving%20time%20(DST)%20has,(DST)%20as%20of%202023.

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/tzdata/+bug/2012599/+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 2015373] Re: massive yellow screen color corruption

2023-04-05 Thread Ubuntu Foundations Team Bug Bot

** Package changed: ubuntu => xorg (Ubuntu)

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

Title:
  massive yellow screen color corruption

Status in xorg package in Ubuntu:
  New

Bug description:
  using the "try ubuntu" feature, this is what the entire experience
  looks like (see the 2nd attached screenshot in comment #2).

  ProblemType: Bug
  DistroRelease: Ubuntu 22.04
  Package: xorg 1:7.7+23ubuntu2
  ProcVersionSignature: Ubuntu 5.19.0-32.33~22.04.1-generic 5.19.17
  Uname: Linux 5.19.0-32-generic x86_64
  NonfreeKernelModules: zfs zunicode zavl icp zcommon znvpair
  ApportVersion: 2.20.11-0ubuntu82.3
  Architecture: amd64
  BootLog: Error: [Errno 13] Permission denied: '/var/log/boot.log'
  CasperMD5CheckResult: pass
  CasperVersion: 1.470.2
  CompositorRunning: None
  CurrentDesktop: ubuntu:GNOME
  Date: Wed Apr  5 15:37:32 2023
  DistUpgraded: Fresh install
  DistroCodename: jammy
  DistroVariant: ubuntu
  ExtraDebuggingInterest: Yes
  GraphicsCard:
   NVIDIA Corporation TU104 [GeForce RTX 2060] [10de:1e89] (rev a1) (prog-if 00 
[VGA controller])
     Subsystem: Gigabyte Technology Co., Ltd TU104 [GeForce RTX 2060] 
[1458:402b]
  LiveMediaBuild: Ubuntu 22.04.2 LTS "Jammy Jellyfish" - Release amd64 
(20230223)
  MachineType: To Be Filled By O.E.M. A320M Pro4 R2.0
  ProcEnviron:
   PATH=(custom, no user)
   XDG_RUNTIME_DIR=
   LANG=en_US.UTF-8
   SHELL=/bin/bash
  ProcKernelCmdLine: BOOT_IMAGE=/casper/vmlinuz 
file=/cdrom/preseed/hostname.seed maybe-ubiquity quiet splash ---
  SourcePackage: xorg
  Symptom: display
  UpgradeStatus: No upgrade log present (probably fresh install)
  dmi.bios.date: 10/26/2022
  dmi.bios.release: 5.17
  dmi.bios.vendor: American Megatrends Inc.
  dmi.bios.version: P7.40
  dmi.board.name: A320M Pro4 R2.0
  dmi.board.vendor: ASRock
  dmi.chassis.asset.tag: To Be Filled By O.E.M.
  dmi.chassis.type: 3
  dmi.chassis.vendor: To Be Filled By O.E.M.
  dmi.chassis.version: To Be Filled By O.E.M.
  dmi.modalias: 
dmi:bvnAmericanMegatrendsInc.:bvrP7.40:bd10/26/2022:br5.17:svnToBeFilledByO.E.M.:pnA320MPro4R2.0:pvrToBeFilledByO.E.M.:rvnASRock:rnA320MPro4R2.0:rvr:cvnToBeFilledByO.E.M.:ct3:cvrToBeFilledByO.E.M.:skuToBeFilledByO.E.M.:
  dmi.product.family: To Be Filled By O.E.M.
  dmi.product.name: A320M Pro4 R2.0
  dmi.product.sku: To Be Filled By O.E.M.
  dmi.product.version: To Be Filled By O.E.M.
  dmi.sys.vendor: To Be Filled By O.E.M.
  version.compiz: compiz N/A
  version.libdrm2: libdrm2 2.4.113-2~ubuntu0.22.04.1
  version.libgl1-mesa-dri: libgl1-mesa-dri 22.2.5-0ubuntu0.1~22.04.1
  version.libgl1-mesa-glx: libgl1-mesa-glx N/A
  version.xserver-xorg-core: xserver-xorg-core 2:21.1.3-2ubuntu2.7
  version.xserver-xorg-input-evdev: xserver-xorg-input-evdev N/A
  version.xserver-xorg-video-ati: xserver-xorg-video-ati 1:19.1.0-2ubuntu1
  version.xserver-xorg-video-intel: xserver-xorg-video-intel 
2:2.99.917+git20210115-1
  version.xserver-xorg-video-nouveau: xserver-xorg-video-nouveau 
1:1.0.17-2build1

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/xorg/+bug/2015373/+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 2012599] Re: tzdata 2023a/2023b/2023c release - Egypt restoring DST

Verification for kinetic.
I've run autopkgtests locally on tzdata from the proposed pocket using [1]. All 
newly added tests were successful. Additionally I've run the Egypt DST test 
manually, like described for the previously tested version.

test_2023a (__main__.TestZoneinfo)
Test Egypt uses DST again from 2023a release. ... ok
test_2023c (__main__.TestZoneinfo)
Test Lebanon's reverted DST delay from 2023c release. ... ok

test_2023a (__main__.TestICU)
Test Egypt uses DST again from 2023a release. ... ok

[1] https://packaging.ubuntu.com/html/auto-pkg-test.html

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

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

Title:
  tzdata 2023a/2023b/2023c release - Egypt restoring DST

Status in tzdata package in Ubuntu:
  Fix Released
Status in tzdata source package in Bionic:
  Fix Committed
Status in tzdata source package in Focal:
  Fix Committed
Status in tzdata source package in Jammy:
  Fix Committed
Status in tzdata source package in Kinetic:
  Fix Committed
Status in tzdata source package in Lunar:
  Fix Released

Bug description:
  [ Impact ]

  Recently the Egyptian authorities decided to restore DST. The first
  switch after the change is expected to take place on last Friday of
  April. The upstream tzdata 2023a release already reflects this change.

  The 2023a release contains the following changes:

  * Egypt now uses DST again, from April through October.
  * This year Morocco springs forward April 23, not April 30.
  * Palestine delays the start of DST this year.
  * Much of Greenland still uses DST from 2024 on.

  The 2023c release reverts the changes done in 2023b.

  [ Test Plan ]

  Test cases were added to the autopkgtest to cover the testing:

  * python: test_2023a
  * python: test_2023c
  * python: test_systemv_timezones (for releases <= 20.04 LTS)
  * python-icu: test_2023a (only for kinetic, jammy, focal)

  So the test plan is to check that the autopkgtest succeeds.

  Alternatively the python test_2023a can be run manually:

   * Set system timezone to Egypt (e.g. Africa/Cairo).
   * Set system time to 2023-04-27 23:59.
   * Wait and observe what happens at 2023-04-28 0:00

  [Test Case for releases <= 20.04 LTS]

  Additionally, an upstream update of tzdata removed the 'old' SystemV 
timezones, so we should ensure that they are kept in Ubuntu 20.04 LTS and 
earlier releases. This is done by the test_systemv_timezones test case or can 
be checked manually with the following:
  diff <(zdump -v America/Phoenix | cut -d' ' -f2-) <(zdump -v SystemV/MST7 | 
cut -d' ' -f2-)

  [ Where problems could occur ]

   * Systems with incorrect timezone set (e.g. located outside of Egypt
  but still using Egyptian time) may observe unexpected time shift.

  [ Other Info ]

  The autopkgtest for chrony is flaky on jammy and kinetic (see bug
  #2002910).

   * More information with sources:
  
https://en.wikipedia.org/wiki/Daylight_saving_time_in_Egypt#:~:text=Daylight%20saving%20time%20(DST)%20has,(DST)%20as%20of%202023.

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/tzdata/+bug/2012599/+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 2015373] [NEW] massive yellow screen color corruption

You have been subscribed to a public bug:

using the "try ubuntu" feature, this is what the entire experience looks
like (see the 2nd attached screenshot in comment #2).

ProblemType: Bug
DistroRelease: Ubuntu 22.04
Package: xorg 1:7.7+23ubuntu2
ProcVersionSignature: Ubuntu 5.19.0-32.33~22.04.1-generic 5.19.17
Uname: Linux 5.19.0-32-generic x86_64
NonfreeKernelModules: zfs zunicode zavl icp zcommon znvpair
ApportVersion: 2.20.11-0ubuntu82.3
Architecture: amd64
BootLog: Error: [Errno 13] Permission denied: '/var/log/boot.log'
CasperMD5CheckResult: pass
CasperVersion: 1.470.2
CompositorRunning: None
CurrentDesktop: ubuntu:GNOME
Date: Wed Apr  5 15:37:32 2023
DistUpgraded: Fresh install
DistroCodename: jammy
DistroVariant: ubuntu
ExtraDebuggingInterest: Yes
GraphicsCard:
 NVIDIA Corporation TU104 [GeForce RTX 2060] [10de:1e89] (rev a1) (prog-if 00 
[VGA controller])
   Subsystem: Gigabyte Technology Co., Ltd TU104 [GeForce RTX 2060] [1458:402b]
LiveMediaBuild: Ubuntu 22.04.2 LTS "Jammy Jellyfish" - Release amd64 (20230223)
MachineType: To Be Filled By O.E.M. A320M Pro4 R2.0
ProcEnviron:
 PATH=(custom, no user)
 XDG_RUNTIME_DIR=
 LANG=en_US.UTF-8
 SHELL=/bin/bash
ProcKernelCmdLine: BOOT_IMAGE=/casper/vmlinuz file=/cdrom/preseed/hostname.seed 
maybe-ubiquity quiet splash ---
SourcePackage: xorg
Symptom: display
UpgradeStatus: No upgrade log present (probably fresh install)
dmi.bios.date: 10/26/2022
dmi.bios.release: 5.17
dmi.bios.vendor: American Megatrends Inc.
dmi.bios.version: P7.40
dmi.board.name: A320M Pro4 R2.0
dmi.board.vendor: ASRock
dmi.chassis.asset.tag: To Be Filled By O.E.M.
dmi.chassis.type: 3
dmi.chassis.vendor: To Be Filled By O.E.M.
dmi.chassis.version: To Be Filled By O.E.M.
dmi.modalias: 
dmi:bvnAmericanMegatrendsInc.:bvrP7.40:bd10/26/2022:br5.17:svnToBeFilledByO.E.M.:pnA320MPro4R2.0:pvrToBeFilledByO.E.M.:rvnASRock:rnA320MPro4R2.0:rvr:cvnToBeFilledByO.E.M.:ct3:cvrToBeFilledByO.E.M.:skuToBeFilledByO.E.M.:
dmi.product.family: To Be Filled By O.E.M.
dmi.product.name: A320M Pro4 R2.0
dmi.product.sku: To Be Filled By O.E.M.
dmi.product.version: To Be Filled By O.E.M.
dmi.sys.vendor: To Be Filled By O.E.M.
version.compiz: compiz N/A
version.libdrm2: libdrm2 2.4.113-2~ubuntu0.22.04.1
version.libgl1-mesa-dri: libgl1-mesa-dri 22.2.5-0ubuntu0.1~22.04.1
version.libgl1-mesa-glx: libgl1-mesa-glx N/A
version.xserver-xorg-core: xserver-xorg-core 2:21.1.3-2ubuntu2.7
version.xserver-xorg-input-evdev: xserver-xorg-input-evdev N/A
version.xserver-xorg-video-ati: xserver-xorg-video-ati 1:19.1.0-2ubuntu1
version.xserver-xorg-video-intel: xserver-xorg-video-intel 
2:2.99.917+git20210115-1
version.xserver-xorg-video-nouveau: xserver-xorg-video-nouveau 1:1.0.17-2build1

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


** Tags: amd64 apport-bug corruption jammy ubuntu
-- 
massive yellow screen color corruption
https://bugs.launchpad.net/bugs/2015373
You received this bug notification because you are a member of Ubuntu Touch 
seeded packages, which is subscribed to xorg in Ubuntu.

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

[Touch-packages] [Bug 2012734] Re: no audio after update

2023-04-05 Thread malko

reboot with kernel 5.19.0-32-generic and the problem is gone, so it must
be at the kernel level

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

Title:
  no audio after update

Status in pulseaudio package in Ubuntu:
  Confirmed

Bug description:
  Description:  Ubuntu 22.10
  Release:  22.10

  
  during normal patching Ubuntu pushed from kernel 5.19.0-31 to 5.19.0-35. 
After this push, I lost audio from my AMD RX570 hdmi. I booted back to -31 
waiting for the next kernel push in the hopes the problem would be caught and 
addressed. It wasn't, and still persists in -38. The card info is below and was 
taken while booted into -38.

  01:00.0 VGA compatible controller: Advanced Micro Devices, Inc. [AMD/ATI] 
Ellesmere [Radeon RX 470/480/570/570X/580/580X/590] (rev ef)
  01:00.1 Audio device: Advanced Micro Devices, Inc. [AMD/ATI] Ellesmere HDMI 
Audio [Radeon RX 470/480 / 570/580/590]

  root@x:~# hwinfo --sound
  35: PCI 100.1: 0403 Audio device
  [Created at pci.386]
  Unique ID: NXNs.TsyFmhFLPLA
  Parent ID: mnDB.fA+tdbAkMSD
  SysFS ID: /devices/pci:00/:00:01.1/:01:00.1
  SysFS BusID: :01:00.1
  Hardware Class: sound
  Model: "ATI Ellesmere HDMI Audio [Radeon RX 470/480 / 570/580/590]"
  Vendor: pci 0x1002 "ATI Technologies Inc"
  Device: pci 0xaaf0 "Ellesmere HDMI Audio [Radeon RX 470/480 / 570/580/590]"
  SubVendor: pci 0x1458 "Gigabyte Technology Co., Ltd"
  SubDevice: pci 0xaaf0
  Driver: "snd_hda_intel"
  Driver Modules: "snd_hda_intel"
  Memory Range: 0xfcf6-0xfcf63fff (rw,non-prefetchable)
  IRQ: 86 (5 events)
  Module Alias: "pci:v1002dAAF0sv1458sdAAF0bc04sc0 3i00"
  Driver Info #0:
  Driver Status: snd_hda_intel is active
  Driver Activation Cmd: "modprobe snd_hda_intel"
  Config Status: cfg=new, avail=yes, need=no, active=unknown
  Attached to: #31 (PCI bridge)


  The errors I am getting during intialization are:

  [ 4.895282] hdaudio hdaudioC0D0: no AFG or MFG node found
  [ 4.895306] snd_hda_intel :01:00.1: no codecs initialized

  
  and if I try to validate the card

  root@x:~# aplay -l
  aplay: device_list:274: no soundcards found...

  I have tried passing numerous arguments to the module but to no avail.
  Booting back to -31 brings the card right back to fully functioning. I
  believe there has been an update to snd_hda_intel which is causing
  this issue and is most likely a regression situation. Can anyone
  assist? I have searched for a model to be passed specific to AMD
  cards, but can't find one. Any suggestions would be greatly
  appreciated. Additionally, I'm wondering if this should be directed to
  Ubuntu, or should it go to kernel.org the HD-Audio group? Again,
  thanks for your thoughts.

  options snd_hda_intel dmic_detect=0
  options snd_hda_intel model=generic
  options snd_hda_intel model=auto
  options snd_hda_intel probe_mask=1
  options snd-intel-dspcfg dsp_driver=1

  Under -31 the error messages are not displayed, sound works. If I
  again validate, I get the below:

  root@media2:~# aplay -l
   List of PLAYBACK Hardware Devices 
  card 0: HDMI [HDA ATI HDMI], device 3: HDMI 0 [HDMI 0]
Subdevices: 1/1
Subdevice #0: subdevice #0
  card 0: HDMI [HDA ATI HDMI], device 7: HDMI 1 [HDMI 1]
Subdevices: 1/1
Subdevice #0: subdevice #0
  card 0: HDMI [HDA ATI HDMI], device 8: HDMI 2 [HDMI 2]
Subdevices: 1/1
Subdevice #0: subdevice #0
  card 0: HDMI [HDA ATI HDMI], device 9: HDMI 3 [65Q825]
Subdevices: 1/1
Subdevice #0: subdevice #0
  card 0: HDMI [HDA ATI HDMI], device 10: HDMI 4 [HDMI 4]
Subdevices: 1/1
Subdevice #0: subdevice #0
  card 0: HDMI [HDA ATI HDMI], device 11: HDMI 5 [HDMI 5]
Subdevices: 1/1
Subdevice #0: subdevice #0

  ProblemType: Bug
  DistroRelease: Ubuntu 22.10
  Package: pulseaudio 1:16.1+dfsg1-1ubuntu3.1
  ProcVersionSignature: Ubuntu 5.19.0-38.39-generic 5.19.17
  Uname: Linux 5.19.0-38-generic x86_64
  NonfreeKernelModules: zfs zunicode zavl icp zcommon znvpair
  ApportVersion: 2.23.1-0ubuntu3
  Architecture: amd64
  AudioDevicesInUse:
   USERPID ACCESS COMMAND
   /dev/snd/seq:gdm1585 F pipewire
  CasperMD5CheckResult: unknown
  Date: Fri Mar 24 07:45:50 2023
  InstallationDate: Installed on 2019-05-09 (1415 days ago)
  InstallationMedia: Ubuntu 19.04 "Disco Dingo" - Release amd64 (20190416)
  ProcEnviron:
   TERM=xterm-256color
   PATH=(custom, no user)
   LANG=en_US.UTF-8
   SHELL=/bin/bash
  PulseList: Error: command ['pacmd', 'list'] failed with exit code 1: No 
PulseAudio daemon running, or not running as session daemon.
  SourcePackage: pulseaudio
  Symptom: audio
  UpgradeStatus: Upgraded to kinetic on 2023-01-13 (69 days ago)
  dmi.bios.date: 11/27/2019
  dmi.bios.release: 5.14
  dmi.bios.vendor: American Megatrends Inc.
  dmi.bios.version: F50
  dmi.board.asset.tag: Default

[Touch-packages] [Bug 2012734] Re: no audio after update

2023-04-05 Thread malko

the output of uname -r
5.19.0-38-generic

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

Title:
  no audio after update

Status in pulseaudio package in Ubuntu:
  Confirmed

Bug description:
  Description:  Ubuntu 22.10
  Release:  22.10

  
  during normal patching Ubuntu pushed from kernel 5.19.0-31 to 5.19.0-35. 
After this push, I lost audio from my AMD RX570 hdmi. I booted back to -31 
waiting for the next kernel push in the hopes the problem would be caught and 
addressed. It wasn't, and still persists in -38. The card info is below and was 
taken while booted into -38.

  01:00.0 VGA compatible controller: Advanced Micro Devices, Inc. [AMD/ATI] 
Ellesmere [Radeon RX 470/480/570/570X/580/580X/590] (rev ef)
  01:00.1 Audio device: Advanced Micro Devices, Inc. [AMD/ATI] Ellesmere HDMI 
Audio [Radeon RX 470/480 / 570/580/590]

  root@x:~# hwinfo --sound
  35: PCI 100.1: 0403 Audio device
  [Created at pci.386]
  Unique ID: NXNs.TsyFmhFLPLA
  Parent ID: mnDB.fA+tdbAkMSD
  SysFS ID: /devices/pci:00/:00:01.1/:01:00.1
  SysFS BusID: :01:00.1
  Hardware Class: sound
  Model: "ATI Ellesmere HDMI Audio [Radeon RX 470/480 / 570/580/590]"
  Vendor: pci 0x1002 "ATI Technologies Inc"
  Device: pci 0xaaf0 "Ellesmere HDMI Audio [Radeon RX 470/480 / 570/580/590]"
  SubVendor: pci 0x1458 "Gigabyte Technology Co., Ltd"
  SubDevice: pci 0xaaf0
  Driver: "snd_hda_intel"
  Driver Modules: "snd_hda_intel"
  Memory Range: 0xfcf6-0xfcf63fff (rw,non-prefetchable)
  IRQ: 86 (5 events)
  Module Alias: "pci:v1002dAAF0sv1458sdAAF0bc04sc0 3i00"
  Driver Info #0:
  Driver Status: snd_hda_intel is active
  Driver Activation Cmd: "modprobe snd_hda_intel"
  Config Status: cfg=new, avail=yes, need=no, active=unknown
  Attached to: #31 (PCI bridge)


  The errors I am getting during intialization are:

  [ 4.895282] hdaudio hdaudioC0D0: no AFG or MFG node found
  [ 4.895306] snd_hda_intel :01:00.1: no codecs initialized

  
  and if I try to validate the card

  root@x:~# aplay -l
  aplay: device_list:274: no soundcards found...

  I have tried passing numerous arguments to the module but to no avail.
  Booting back to -31 brings the card right back to fully functioning. I
  believe there has been an update to snd_hda_intel which is causing
  this issue and is most likely a regression situation. Can anyone
  assist? I have searched for a model to be passed specific to AMD
  cards, but can't find one. Any suggestions would be greatly
  appreciated. Additionally, I'm wondering if this should be directed to
  Ubuntu, or should it go to kernel.org the HD-Audio group? Again,
  thanks for your thoughts.

  options snd_hda_intel dmic_detect=0
  options snd_hda_intel model=generic
  options snd_hda_intel model=auto
  options snd_hda_intel probe_mask=1
  options snd-intel-dspcfg dsp_driver=1

  Under -31 the error messages are not displayed, sound works. If I
  again validate, I get the below:

  root@media2:~# aplay -l
   List of PLAYBACK Hardware Devices 
  card 0: HDMI [HDA ATI HDMI], device 3: HDMI 0 [HDMI 0]
Subdevices: 1/1
Subdevice #0: subdevice #0
  card 0: HDMI [HDA ATI HDMI], device 7: HDMI 1 [HDMI 1]
Subdevices: 1/1
Subdevice #0: subdevice #0
  card 0: HDMI [HDA ATI HDMI], device 8: HDMI 2 [HDMI 2]
Subdevices: 1/1
Subdevice #0: subdevice #0
  card 0: HDMI [HDA ATI HDMI], device 9: HDMI 3 [65Q825]
Subdevices: 1/1
Subdevice #0: subdevice #0
  card 0: HDMI [HDA ATI HDMI], device 10: HDMI 4 [HDMI 4]
Subdevices: 1/1
Subdevice #0: subdevice #0
  card 0: HDMI [HDA ATI HDMI], device 11: HDMI 5 [HDMI 5]
Subdevices: 1/1
Subdevice #0: subdevice #0

  ProblemType: Bug
  DistroRelease: Ubuntu 22.10
  Package: pulseaudio 1:16.1+dfsg1-1ubuntu3.1
  ProcVersionSignature: Ubuntu 5.19.0-38.39-generic 5.19.17
  Uname: Linux 5.19.0-38-generic x86_64
  NonfreeKernelModules: zfs zunicode zavl icp zcommon znvpair
  ApportVersion: 2.23.1-0ubuntu3
  Architecture: amd64
  AudioDevicesInUse:
   USERPID ACCESS COMMAND
   /dev/snd/seq:gdm1585 F pipewire
  CasperMD5CheckResult: unknown
  Date: Fri Mar 24 07:45:50 2023
  InstallationDate: Installed on 2019-05-09 (1415 days ago)
  InstallationMedia: Ubuntu 19.04 "Disco Dingo" - Release amd64 (20190416)
  ProcEnviron:
   TERM=xterm-256color
   PATH=(custom, no user)
   LANG=en_US.UTF-8
   SHELL=/bin/bash
  PulseList: Error: command ['pacmd', 'list'] failed with exit code 1: No 
PulseAudio daemon running, or not running as session daemon.
  SourcePackage: pulseaudio
  Symptom: audio
  UpgradeStatus: Upgraded to kinetic on 2023-01-13 (69 days ago)
  dmi.bios.date: 11/27/2019
  dmi.bios.release: 5.14
  dmi.bios.vendor: American Megatrends Inc.
  dmi.bios.version: F50
  dmi.board.asset.tag: Default string
  dmi.board.name: B450 AORUS PRO WIFI-CF

[Touch-packages] [Bug 2012734] Re: no audio after update

2023-04-05 Thread malko

Same problem here on ubuntu 22.04, since last update I can't output
sound through HDMI, the card is not listed anymore in any sound settings
app i tested (alasmixer, pavucontrol or system sound settings)

Here some commands output:

lspci | grep Audio
2d:00.1 Audio device: Advanced Micro Devices, Inc. [AMD/ATI] Ellesmere HDMI 
Audio [Radeon RX 470/480 / 570/580/590]
2f:00.4 Audio device: Advanced Micro Devices, Inc. [AMD] Starship/Matisse HD 
Audio Controller

cat /proc/asound/cards
 1 [Microphone ]: USB-Audio - HD Pro Webcam C920
  HD Pro Webcam C920 at usb-:25:00.0-3.2, high speed
 2 [Generic]: HDA-Intel - HD-Audio Generic
  HD-Audio Generic at 0xfcc0 irq 80

aplay -l  
 Liste des périphériques matériels PLAYBACK 
carte 2 : Generic [HD-Audio Generic], périphérique 0 : ALC1220 Analog [ALC1220 
Analog]
  Sous-périphériques : 1/1
  Sous-périphérique #0 : subdevice #0
carte 2 : Generic [HD-Audio Generic], périphérique 1 : ALC1220 Digital [ALC1220 
Digital]
  Sous-périphériques : 1/1
  Sous-périphérique #0 : subdevice #0

So lscpi report the correctly the Ellesmere HDMI Audio which has
disappear from all other listings.

How can we fix that please

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

Title:
  no audio after update

Status in pulseaudio package in Ubuntu:
  Confirmed

Bug description:
  Description:  Ubuntu 22.10
  Release:  22.10

  
  during normal patching Ubuntu pushed from kernel 5.19.0-31 to 5.19.0-35. 
After this push, I lost audio from my AMD RX570 hdmi. I booted back to -31 
waiting for the next kernel push in the hopes the problem would be caught and 
addressed. It wasn't, and still persists in -38. The card info is below and was 
taken while booted into -38.

  01:00.0 VGA compatible controller: Advanced Micro Devices, Inc. [AMD/ATI] 
Ellesmere [Radeon RX 470/480/570/570X/580/580X/590] (rev ef)
  01:00.1 Audio device: Advanced Micro Devices, Inc. [AMD/ATI] Ellesmere HDMI 
Audio [Radeon RX 470/480 / 570/580/590]

  root@x:~# hwinfo --sound
  35: PCI 100.1: 0403 Audio device
  [Created at pci.386]
  Unique ID: NXNs.TsyFmhFLPLA
  Parent ID: mnDB.fA+tdbAkMSD
  SysFS ID: /devices/pci:00/:00:01.1/:01:00.1
  SysFS BusID: :01:00.1
  Hardware Class: sound
  Model: "ATI Ellesmere HDMI Audio [Radeon RX 470/480 / 570/580/590]"
  Vendor: pci 0x1002 "ATI Technologies Inc"
  Device: pci 0xaaf0 "Ellesmere HDMI Audio [Radeon RX 470/480 / 570/580/590]"
  SubVendor: pci 0x1458 "Gigabyte Technology Co., Ltd"
  SubDevice: pci 0xaaf0
  Driver: "snd_hda_intel"
  Driver Modules: "snd_hda_intel"
  Memory Range: 0xfcf6-0xfcf63fff (rw,non-prefetchable)
  IRQ: 86 (5 events)
  Module Alias: "pci:v1002dAAF0sv1458sdAAF0bc04sc0 3i00"
  Driver Info #0:
  Driver Status: snd_hda_intel is active
  Driver Activation Cmd: "modprobe snd_hda_intel"
  Config Status: cfg=new, avail=yes, need=no, active=unknown
  Attached to: #31 (PCI bridge)


  The errors I am getting during intialization are:

  [ 4.895282] hdaudio hdaudioC0D0: no AFG or MFG node found
  [ 4.895306] snd_hda_intel :01:00.1: no codecs initialized

  
  and if I try to validate the card

  root@x:~# aplay -l
  aplay: device_list:274: no soundcards found...

  I have tried passing numerous arguments to the module but to no avail.
  Booting back to -31 brings the card right back to fully functioning. I
  believe there has been an update to snd_hda_intel which is causing
  this issue and is most likely a regression situation. Can anyone
  assist? I have searched for a model to be passed specific to AMD
  cards, but can't find one. Any suggestions would be greatly
  appreciated. Additionally, I'm wondering if this should be directed to
  Ubuntu, or should it go to kernel.org the HD-Audio group? Again,
  thanks for your thoughts.

  options snd_hda_intel dmic_detect=0
  options snd_hda_intel model=generic
  options snd_hda_intel model=auto
  options snd_hda_intel probe_mask=1
  options snd-intel-dspcfg dsp_driver=1

  Under -31 the error messages are not displayed, sound works. If I
  again validate, I get the below:

  root@media2:~# aplay -l
   List of PLAYBACK Hardware Devices 
  card 0: HDMI [HDA ATI HDMI], device 3: HDMI 0 [HDMI 0]
Subdevices: 1/1
Subdevice #0: subdevice #0
  card 0: HDMI [HDA ATI HDMI], device 7: HDMI 1 [HDMI 1]
Subdevices: 1/1
Subdevice #0: subdevice #0
  card 0: HDMI [HDA ATI HDMI], device 8: HDMI 2 [HDMI 2]
Subdevices: 1/1
Subdevice #0: subdevice #0
  card 0: HDMI [HDA ATI HDMI], device 9: HDMI 3 [65Q825]
Subdevices: 1/1
Subdevice #0: subdevice #0
  card 0: HDMI [HDA ATI HDMI], device 10: HDMI 4 [HDMI 4]
Subdevices: 1/1
Subdevice #0: subdevice #0
  card 0: HDMI [HDA ATI HDMI], device 11: HDMI 5 [HDMI 5]
Subdevices: 1/1

[Touch-packages] [Bug 1981697] Re: KDC: weak crypto in default settings

** Description changed:

  [ Impact ]
  
  The default crypto algorithm suite selected for the master key in the
  ubuntu krb5-kdc package is des3-hmac-sha1. This comes from a config file
  shipped with the packaging which overrides upstream's default choice.
  
  Users who deploy a KDC using this package will be using an algorithm
  deprecated since many years ago, and considered broken nowadays for
  security applications. Furthermore, the KDC will highlight this fact
  with "deprecated" warnings in the logs and elsewhere. For example:
  
  root@j-kdc-weak-crypto:~# klist -ke /etc/krb5kdc/stash
  Keytab name: FILE:/etc/krb5kdc/stash
  KVNO Principal
   
--
     1 K/M@LXD (DEPRECATED:des3-cbc-sha1)
  
  And in the kdc logs:
  Apr 05 14:20:01 j-kdc-weak-crypto krb5kdc[7323]: Stash file 
/etc/krb5kdc/stash uses DEPRECATED enctype des3-cbc-sha1!
  
  This update removes the specification of an algorithm and leaves it to
  the upstream default, which is aes256-cts-hmac-sha1-96[1].
  
  Kerberos is quite conservative when it comes to updating encryption
  algorithms, and one could argue that the default should be something
  like aes256-cts-hmac-sha384-192, but in this SRU we are sticking the
  upstream default (by not specifying any value). This is also what debian
  is doing, and what we have in kinetic and later.
  
  1. https://manpages.ubuntu.com/manpages/jammy/man5/kdc.conf.5.html
  search for "master_key_type"
  
  [ Test Plan ]
  
- The test plan will involve two major aspects:
+ The test plan will involve two main aspects:
  - upgrades must not change the existing encryption type, and won't get a dpkg 
conf prompt
- - verify that fresh installs are indeed using the new crypto algorithm
+ - fresh installs must use the new crypto algorithm
  
  a) Upgrade does not change algorithm
  Start by installing a kdc with the released packages (not from proposed):
  
  # When prompted, accept the defaults
  sudo apt install krb5-kdc krb5-admin-server
  
  # Verify that master_key_type is set to the deprecated des3-hmac-sha1 value:
  $ sudo grep master_key_type /etc/krb5kdc/kdc.conf
  master_key_type = des3-hmac-sha1
  
  # bootstrap a new realm, type in a password of your choosing (you won't
  need it again):
  
  $ sudo krb5_newrealm
  
  # Verify the actual encryption used in the stash file and confirm it's
  the same, and that you get a DEPRECATED warning:
  
  $ sudo klist -ke /etc/krb5kdc/stash
  Keytab name: FILE:/etc/krb5kdc/stash
  KVNO Principal
   
--
     1 K/M@LXD (DEPRECATED:des3-cbc-sha1)
  
  # Upgrade to the packages in proposed. Confirm there is no dpkg conf
  prompt, and repeat the two checks above (the grep, and the klist
  command). Their output must not have changed.
  
- 
  b) Fresh install of proposed packages
  
  # Perform a fresh install of the packages in proposed. As before, accept
  the defaults when asked debconf questions:
  
  sudo apt install krb5-kdc krb5-admin-server
  
- 
  # Verify that the master_key_type is now commented ("#" in front) and no 
longer shows the deprecated "3des-hmac-sha1" value, but instead shows 
"aes256-cts":
  $ sudo grep master_key_type /etc/krb5kdc/kdc.conf
- #master_key_type = aes256-cts
+ #master_key_type = aes256-cts
  
  # bootstrap a new realm, type in a password of your choosing (you won't
  need it again):
  
  $ sudo krb5_newrealm
  
  # Verify the actual encryption used in the stash file, and confirm it's
  no longer "des3-cbc-sha1", but instead "aes256-cts-hmac-sha1-96":
  
  $ sudo klist -ke /etc/krb5kdc/stash
  Keytab name: FILE:/etc/krb5kdc/stash
  KVNO Principal
   
--
-1 K/M@LXD (aes256-cts-hmac-sha1-96) 
- 
+    1 K/M@LXD (aes256-cts-hmac-sha1-96)
  
  [ Where problems could occur ]
  
   * Think about what the upload changes in the software. Imagine the change is
     wrong or breaks something else: how would this show up?
  
   * It is assumed that any SRU candidate patch is well-tested before
     upload and has a low overall risk of regression, but it's important
     to make the effort to think about what ''could'' happen in the
     event of a regression.
  
   * This must '''never''' be "None" or "Low", or entirely an argument as to why
     your upload is low risk.
  
   * This both shows the SRU team that the risks have been considered,
     and provides guidance to testers in regression-testing the SRU.
  
  [ Other Info ]
  The master_key_type setting does not affect the crypto algorithms that are 
used for tickets and the like. Even with the deprecated 3des setting, the 
tickets obtained by users will be typically using aes256.
  
  [ Original Description ]
  
  Default setting in /etc/krb5kdc/kdc.conf, as installed from krb5-kdc in 
Ubuntu 22.04 Server:
  master_key_type =

[Touch-packages] [Bug 1981697] Re: KDC: weak crypto in default settings

** Description changed:

  [ Impact ]
  
  The default crypto algorithm suite selected for the master key in the
  ubuntu krb5-kdc package is des3-hmac-sha1. This comes from a config file
  shipped with the packaging which overrides upstream's default choice.
  
  Users who deploy a KDC using this package will be using an algorithm
  deprecated since many years ago, and considered broken nowadays for
  security applications. Furthermore, the KDC will highlight this fact
  with "deprecated" warnings in the logs and elsewhere. For example:
  
  root@j-kdc-weak-crypto:~# klist -ke /etc/krb5kdc/stash
  Keytab name: FILE:/etc/krb5kdc/stash
  KVNO Principal
   
--
     1 K/M@LXD (DEPRECATED:des3-cbc-sha1)
  
  And in the kdc logs:
  Apr 05 14:20:01 j-kdc-weak-crypto krb5kdc[7323]: Stash file 
/etc/krb5kdc/stash uses DEPRECATED enctype des3-cbc-sha1!
  
  This update removes the specification of an algorithm and leaves it to
  the upstream default, which is aes256-cts-hmac-sha1-96[1].
  
  Kerberos is quite conservative when it comes to updating encryption
  algorithms, and one could argue that the default should be something
  like aes256-cts-hmac-sha384-192, but in this SRU we are sticking the
  upstream default (by not specifying any value). This is also what debian
  is doing, and what we have in kinetic and later.
  
  1. https://manpages.ubuntu.com/manpages/jammy/man5/kdc.conf.5.html
  search for "master_key_type"
  
  [ Test Plan ]
  
  The test plan will involve two major aspects:
  - upgrades must not change the existing encryption type, and won't get a dpkg 
conf prompt
  - verify that fresh installs are indeed using the new crypto algorithm
  
  a) Upgrade does not change algorithm
  Start by installing a kdc with the released packages (not from proposed):
  
  # When prompted, accept the defaults
  sudo apt install krb5-kdc krb5-admin-server
  
  # Verify that master_key_type is set to the deprecated des3-hmac-sha1 value:
  $ sudo grep master_key_type /etc/krb5kdc/kdc.conf
  master_key_type = des3-hmac-sha1
  
  # bootstrap a new realm, type in a password of your choosing (you won't
  need it again):
  
  $ sudo krb5_newrealm
  
  # Verify the actual encryption used in the stash file and confirm it's
  the same, and that you get a DEPRECATED warning:
  
  $ sudo klist -ke /etc/krb5kdc/stash
  Keytab name: FILE:/etc/krb5kdc/stash
  KVNO Principal
   
--
     1 K/M@LXD (DEPRECATED:des3-cbc-sha1)
  
  # Upgrade to the packages in proposed. Confirm there is no dpkg conf
  prompt, and repeat the two checks above (the grep, and the klist
  command). Their output must not have changed.
  
+ 
+ b) Fresh install of proposed packages
+ 
+ # Perform a fresh install of the packages in proposed. As before, accept
+ the defaults when asked debconf questions:
+ 
+ sudo apt install krb5-kdc krb5-admin-server
+ 
+ 
+ # Verify that the master_key_type is now commented ("#" in front) and no 
longer shows the deprecated "3des-hmac-sha1" value, but instead shows 
"aes256-cts":
+ $ sudo grep master_key_type /etc/krb5kdc/kdc.conf
+ #master_key_type = aes256-cts
+ 
+ # bootstrap a new realm, type in a password of your choosing (you won't
+ need it again):
+ 
+ $ sudo krb5_newrealm
+ 
+ # Verify the actual encryption used in the stash file, and confirm it's
+ no longer "des3-cbc-sha1", but instead "aes256-cts-hmac-sha1-96":
+ 
+ $ sudo klist -ke /etc/krb5kdc/stash
+ Keytab name: FILE:/etc/krb5kdc/stash
+ KVNO Principal
+  
--
+1 K/M@LXD (aes256-cts-hmac-sha1-96) 
+ 
+ 
  [ Where problems could occur ]
  
   * Think about what the upload changes in the software. Imagine the change is
     wrong or breaks something else: how would this show up?
  
   * It is assumed that any SRU candidate patch is well-tested before
     upload and has a low overall risk of regression, but it's important
     to make the effort to think about what ''could'' happen in the
     event of a regression.
  
   * This must '''never''' be "None" or "Low", or entirely an argument as to why
     your upload is low risk.
  
   * This both shows the SRU team that the risks have been considered,
     and provides guidance to testers in regression-testing the SRU.
  
  [ Other Info ]
  The master_key_type setting does not affect the crypto algorithms that are 
used for tickets and the like. Even with the deprecated 3des setting, the 
tickets obtained by users will be typically using aes256.
  
  [ Original Description ]
  
  Default setting in /etc/krb5kdc/kdc.conf, as installed from krb5-kdc in 
Ubuntu 22.04 Server:
  master_key_type = des3-hmac-sha1
  
  3DES was deprecated by NIST in 2017, i.e. give years ago! Reference:
  https://csrc.nist.gov/News/2017/Update-to-Current-Use-and-Deprecation-
  of-TDEA . This

[Touch-packages] [Bug 2012599] Please test proposed package

Hello Dariusz, or anyone else affected,

Accepted tzdata into bionic-proposed. The package will build now and be
available at
https://launchpad.net/ubuntu/+source/tzdata/2023c-0ubuntu0.18.04 in a
few hours, and then in the -proposed repository.

Please help us by testing this new package.  See
https://wiki.ubuntu.com/Testing/EnableProposed for documentation on how
to enable and use -proposed.  Your feedback will aid us getting this
update out to other Ubuntu users.

If this package fixes the bug for you, please add a comment to this bug,
mentioning the version of the package you tested, what testing has been
performed on the package and change the tag from verification-needed-
bionic to verification-done-bionic. If it does not fix the bug for you,
please add a comment stating that, and change the tag to verification-
failed-bionic. In either case, without details of your testing we will
not be able to proceed.

Further information regarding the verification process can be found at
https://wiki.ubuntu.com/QATeam/PerformingSRUVerification .  Thank you in
advance for helping!

N.B. The updated package will be released to -updates after the bug(s)
fixed by this package have been verified and the package has been in
-proposed for a minimum of 7 days.

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

Title:
  tzdata 2023a/2023b/2023c release - Egypt restoring DST

Status in tzdata package in Ubuntu:
  Fix Released
Status in tzdata source package in Bionic:
  Fix Committed
Status in tzdata source package in Focal:
  Fix Committed
Status in tzdata source package in Jammy:
  Fix Committed
Status in tzdata source package in Kinetic:
  Fix Committed
Status in tzdata source package in Lunar:
  Fix Released

Bug description:
  [ Impact ]

  Recently the Egyptian authorities decided to restore DST. The first
  switch after the change is expected to take place on last Friday of
  April. The upstream tzdata 2023a release already reflects this change.

  The 2023a release contains the following changes:

  * Egypt now uses DST again, from April through October.
  * This year Morocco springs forward April 23, not April 30.
  * Palestine delays the start of DST this year.
  * Much of Greenland still uses DST from 2024 on.

  The 2023c release reverts the changes done in 2023b.

  [ Test Plan ]

  Test cases were added to the autopkgtest to cover the testing:

  * python: test_2023a
  * python: test_2023c
  * python: test_systemv_timezones (for releases <= 20.04 LTS)
  * python-icu: test_2023a (only for kinetic, jammy, focal)

  So the test plan is to check that the autopkgtest succeeds.

  Alternatively the python test_2023a can be run manually:

   * Set system timezone to Egypt (e.g. Africa/Cairo).
   * Set system time to 2023-04-27 23:59.
   * Wait and observe what happens at 2023-04-28 0:00

  [Test Case for releases <= 20.04 LTS]

  Additionally, an upstream update of tzdata removed the 'old' SystemV 
timezones, so we should ensure that they are kept in Ubuntu 20.04 LTS and 
earlier releases. This is done by the test_systemv_timezones test case or can 
be checked manually with the following:
  diff <(zdump -v America/Phoenix | cut -d' ' -f2-) <(zdump -v SystemV/MST7 | 
cut -d' ' -f2-)

  [ Where problems could occur ]

   * Systems with incorrect timezone set (e.g. located outside of Egypt
  but still using Egyptian time) may observe unexpected time shift.

  [ Other Info ]

  The autopkgtest for chrony is flaky on jammy and kinetic (see bug
  #2002910).

   * More information with sources:
  
https://en.wikipedia.org/wiki/Daylight_saving_time_in_Egypt#:~:text=Daylight%20saving%20time%20(DST)%20has,(DST)%20as%20of%202023.

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/tzdata/+bug/2012599/+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 2012599] Re: tzdata 2023a/2023b/2023c release - Egypt restoring DST

13:51  bdrung: tzdata in Bionic has quite a bit of churn in
debian/tzdata.templates, including the removal of Pacific-New from
tzdata/Zones/US. I didn't see any removals in the later series. Do we
have anything that demonstrates that this is safe? Shouldn't the choice
be preserved somehow?

14:53  rbasak, previous SRUs forgot to regenerate
debian/tzdata.templates. You could use 2022g and regenerate
debian/tzdata.templates to see what previous SRUs should have included
in their debdiff.

14:54  rbasak, Pacific-New was added but was never used.
upstream removed Pacific-New some time ago.

15:13  rbasak, checked that. 2018a removed Pacific-New

15:19  bdrung: yeah but I wouldn't expect removals to be
followed in SRUs. If it was user-selectable, then wouldn't dropping it
be a regression for users who might have selected it previously?

15:22  rbasak, yes. That regression would have been happened
years ago when upstream removed Pacific-New.

15:26  bdrung: OK, so Pacific-New in bionic-updates today is
already broken?

15:27  If that's the case then there will be no SRU regression
so that's fine, but I'd like to document that somewhere. Can you confirm
and I'll just stick this conversation into a bug comment?

15:28  rbasak, I checked the history. Even 2018d-1 did not have
Pacific-New as option (the source package has an outdated
tzdata.templates). So it was never selectable for bionic users.

15:29  2018d-1 was the version of the bionic release.

** Changed in: tzdata (Ubuntu Bionic)
   Status: Triaged => Fix Committed

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

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

Title:
  tzdata 2023a/2023b/2023c release - Egypt restoring DST

Status in tzdata package in Ubuntu:
  Fix Released
Status in tzdata source package in Bionic:
  Fix Committed
Status in tzdata source package in Focal:
  Fix Committed
Status in tzdata source package in Jammy:
  Fix Committed
Status in tzdata source package in Kinetic:
  Fix Committed
Status in tzdata source package in Lunar:
  Fix Released

Bug description:
  [ Impact ]

  Recently the Egyptian authorities decided to restore DST. The first
  switch after the change is expected to take place on last Friday of
  April. The upstream tzdata 2023a release already reflects this change.

  The 2023a release contains the following changes:

  * Egypt now uses DST again, from April through October.
  * This year Morocco springs forward April 23, not April 30.
  * Palestine delays the start of DST this year.
  * Much of Greenland still uses DST from 2024 on.

  The 2023c release reverts the changes done in 2023b.

  [ Test Plan ]

  Test cases were added to the autopkgtest to cover the testing:

  * python: test_2023a
  * python: test_2023c
  * python: test_systemv_timezones (for releases <= 20.04 LTS)
  * python-icu: test_2023a (only for kinetic, jammy, focal)

  So the test plan is to check that the autopkgtest succeeds.

  Alternatively the python test_2023a can be run manually:

   * Set system timezone to Egypt (e.g. Africa/Cairo).
   * Set system time to 2023-04-27 23:59.
   * Wait and observe what happens at 2023-04-28 0:00

  [Test Case for releases <= 20.04 LTS]

  Additionally, an upstream update of tzdata removed the 'old' SystemV 
timezones, so we should ensure that they are kept in Ubuntu 20.04 LTS and 
earlier releases. This is done by the test_systemv_timezones test case or can 
be checked manually with the following:
  diff <(zdump -v America/Phoenix | cut -d' ' -f2-) <(zdump -v SystemV/MST7 | 
cut -d' ' -f2-)

  [ Where problems could occur ]

   * Systems with incorrect timezone set (e.g. located outside of Egypt
  but still using Egyptian time) may observe unexpected time shift.

  [ Other Info ]

  The autopkgtest for chrony is flaky on jammy and kinetic (see bug
  #2002910).

   * More information with sources:
  
https://en.wikipedia.org/wiki/Daylight_saving_time_in_Egypt#:~:text=Daylight%20saving%20time%20(DST)%20has,(DST)%20as%20of%202023.

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/tzdata/+bug/2012599/+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 2015268] Re: sudo

** Changed in: sudo (Ubuntu)
   Status: Incomplete => Invalid

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

Title:
  sudo

Status in sudo package in Ubuntu:
  Invalid

Bug description:
  sudo fix bug logs

  ProblemType: Bug
  DistroRelease: Ubuntu 22.04
  Package: sudo 1.9.9-1ubuntu2.3
  ProcVersionSignature: Ubuntu 5.19.0-38.39~22.04.1-generic 5.19.17
  Uname: Linux 5.19.0-38-generic x86_64
  ApportVersion: 2.20.11-0ubuntu82.3
  Architecture: amd64
  CasperMD5CheckResult: pass
  CurrentDesktop: ubuntu:GNOME
  Date: Tue Apr  4 18:26:35 2023
  InstallationDate: Installed on 2023-03-12 (23 days ago)
  InstallationMedia: Ubuntu 22.04.2 LTS "Jammy Jellyfish" - Release amd64 
(20230223)
  ProcEnviron:
   PATH=(custom, no user)
   XDG_RUNTIME_DIR=
   LANG=fi_FI.UTF-8
   SHELL=/bin/bash
  SourcePackage: sudo
  UpgradeStatus: No upgrade log present (probably fresh install)
  VisudoCheck:
   /etc/sudoers: jäsentäminen valmis
   /etc/sudoers.d/README: jäsentäminen valmis
  modified.conffile..etc.sudoers: [inaccessible: [Errno 13] Lupa evätty: 
'/etc/sudoers']
  modified.conffile..etc.sudoers.d.README: [inaccessible: [Errno 13] Lupa 
evätty: '/etc/sudoers.d/README']

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/sudo/+bug/2015268/+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 2015269] Re: apt

** Changed in: apt (Ubuntu)
   Status: Incomplete => Invalid

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

Title:
  apt

Status in apt package in Ubuntu:
  Invalid

Bug description:
  apt fix bug logs informations

  ProblemType: Bug
  DistroRelease: Ubuntu 22.04
  Package: apt 2.4.8
  ProcVersionSignature: Ubuntu 5.19.0-38.39~22.04.1-generic 5.19.17
  Uname: Linux 5.19.0-38-generic x86_64
  ApportVersion: 2.20.11-0ubuntu82.3
  Architecture: amd64
  CasperMD5CheckResult: pass
  CurrentDesktop: ubuntu:GNOME
  Date: Tue Apr  4 18:27:27 2023
  InstallationDate: Installed on 2023-03-12 (23 days ago)
  InstallationMedia: Ubuntu 22.04.2 LTS "Jammy Jellyfish" - Release amd64 
(20230223)
  ProcEnviron:
   PATH=(custom, no user)
   XDG_RUNTIME_DIR=
   LANG=fi_FI.UTF-8
   SHELL=/bin/bash
  SourcePackage: apt
  UpgradeStatus: No upgrade log present (probably fresh install)

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/apt/+bug/2015269/+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 2015343] Re: systemd logs

** Changed in: systemd (Ubuntu)
   Status: Incomplete => Invalid

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

Title:
  systemd logs

Status in systemd package in Ubuntu:
  Invalid

Bug description:
  systemd logs

  ProblemType: Bug
  DistroRelease: Ubuntu 22.04
  Package: systemd 249.11-0ubuntu3.7
  ProcVersionSignature: Ubuntu 5.15.0-69.76-generic 5.15.87
  Uname: Linux 5.15.0-69-generic x86_64
  ApportVersion: 2.20.11-0ubuntu82.3
  Architecture: amd64
  CasperMD5CheckResult: pass
  CurrentDesktop: ubuntu:GNOME
  Date: Wed Apr  5 14:22:45 2023
  InstallationDate: Installed on 2023-03-12 (23 days ago)
  InstallationMedia: Ubuntu 22.04.2 LTS "Jammy Jellyfish" - Release amd64 
(20230223)
  MachineType: MSI MS-7817
  ProcEnviron:
   PATH=(custom, no user)
   XDG_RUNTIME_DIR=
   LANG=fi_FI.UTF-8
   SHELL=/bin/bash
  ProcKernelCmdLine: BOOT_IMAGE=/boot/vmlinuz-5.15.0-69-generic 
root=UUID=7937a7b0-31fc-4dec-b3c2-51df4e876c20 ro quiet splash vt.handoff=7
  SourcePackage: systemd
  UpgradeStatus: No upgrade log present (probably fresh install)
  dmi.bios.date: 04/21/2015
  dmi.bios.release: 4.6
  dmi.bios.vendor: American Megatrends Inc.
  dmi.bios.version: V10.9
  dmi.board.asset.tag: To be filled by O.E.M.
  dmi.board.name: B85M-E45 (MS-7817)
  dmi.board.vendor: MSI
  dmi.board.version: 2.0
  dmi.chassis.asset.tag: To be filled by O.E.M.
  dmi.chassis.type: 3
  dmi.chassis.vendor: MSI
  dmi.chassis.version: 2.0
  dmi.modalias: 
dmi:bvnAmericanMegatrendsInc.:bvrV10.9:bd04/21/2015:br4.6:svnMSI:pnMS-7817:pvr2.0:rvnMSI:rnB85M-E45(MS-7817):rvr2.0:cvnMSI:ct3:cvr2.0:skuTobefilledbyO.E.M.:
  dmi.product.family: To be filled by O.E.M.
  dmi.product.name: MS-7817
  dmi.product.sku: To be filled by O.E.M.
  dmi.product.version: 2.0
  dmi.sys.vendor: MSI

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/systemd/+bug/2015343/+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 1981697] Re: KDC: weak crypto in default settings

** Description changed:

  [ Impact ]
  
  The default crypto algorithm suite selected for the master key in the
  ubuntu krb5-kdc package is des3-hmac-sha1. This comes from a config file
  shipped with the packaging which overrides upstream's default choice.
  
  Users who deploy a KDC using this package will be using an algorithm
  deprecated since many years ago, and considered broken nowadays for
  security applications. Furthermore, the KDC will highlight this fact
  with "deprecated" warnings in the logs and elsewhere. For example:
  
- root@j-kdc-weak-crypto:~# klist -ke /etc/krb5kdc/stash 
+ root@j-kdc-weak-crypto:~# klist -ke /etc/krb5kdc/stash
  Keytab name: FILE:/etc/krb5kdc/stash
  KVNO Principal
   
--
-1 K/M@LXD (DEPRECATED:des3-cbc-sha1) 
+    1 K/M@LXD (DEPRECATED:des3-cbc-sha1)
  
  And in the kdc logs:
  Apr 05 14:20:01 j-kdc-weak-crypto krb5kdc[7323]: Stash file 
/etc/krb5kdc/stash uses DEPRECATED enctype des3-cbc-sha1!
  
  This update removes the specification of an algorithm and leaves it to
  the upstream default, which is aes256-cts-hmac-sha1-96[1].
  
  Kerberos is quite conservative when it comes to updating encryption
  algorithms, and one could argue that the default should be something
  like aes256-cts-hmac-sha384-192, but in this SRU we are sticking the
  upstream default (by not specifying any value). This is also what debian
  is doing, and what we have in kinetic and later.
  
  1. https://manpages.ubuntu.com/manpages/jammy/man5/kdc.conf.5.html
  search for "master_key_type"
  
  [ Test Plan ]
  
-  * detailed instructions how to reproduce the bug
+ The test plan will involve two major aspects:
+ - upgrades must not change the existing encryption type
+ - verify that fresh installs are indeed using the new crypto algorithm
  
-  * these should allow someone who is not familiar with the affected
-    package to reproduce the bug and verify that the updated package fixes
-    the problem.
+ a) Upgrade does not change algorithm
+ Start by installing a kdc with the released packages (not from proposed):
  
-  * if other testing is appropriate to perform before landing this update,
-    this should also be described here.
+ # When prompted, accept the defaults
+ sudo apt install krb5-kdc krb5-admin-server
+ 
+ 
+ # Verify that master_key_type is set to the deprecated des3-hmac-sha1 value:
+ $ sudo grep master_key_type /etc/krb5kdc/kdc.conf
+ master_key_type = des3-hmac-sha1
+ 
+ # bootstrap a new realm, type in a password of your choosing (you won't
+ need it again):
+ 
+ $ sudo krb5_newrealm
+ 
+ # Verify the actual encryption used in the stash file and confirm it's
+ the same, and that you get a DEPRECATED warning:
+ 
+ $ sudo klist -ke /etc/krb5kdc/stash
+ Keytab name: FILE:/etc/krb5kdc/stash
+ KVNO Principal
+  
--
+1 K/M@LXD (DEPRECATED:des3-cbc-sha1) 
+ 
+ 
+ # Upgrade to the packages in proposed, and repeat the two checks above (the 
grep, and the klist command). Their output must not have changed.
+ 
  
  [ Where problems could occur ]
  
   * Think about what the upload changes in the software. Imagine the change is
     wrong or breaks something else: how would this show up?
  
   * It is assumed that any SRU candidate patch is well-tested before
     upload and has a low overall risk of regression, but it's important
     to make the effort to think about what ''could'' happen in the
     event of a regression.
  
   * This must '''never''' be "None" or "Low", or entirely an argument as to why
     your upload is low risk.
  
   * This both shows the SRU team that the risks have been considered,
     and provides guidance to testers in regression-testing the SRU.
  
  [ Other Info ]
+ The master_key_type setting does not affect the crypto algorithms that are 
used for tickets and the like. Even with the deprecated 3des setting, the 
tickets obtained by users will be typically using aes256.
  
-  * Anything else you think is useful to include
-  * Anticipate questions from users, SRU, +1 maintenance, security teams and 
the Technical Board
-  * and address these questions in advance
+ 
+ [ Original Description ]
  
  Default setting in /etc/krb5kdc/kdc.conf, as installed from krb5-kdc in 
Ubuntu 22.04 Server:
  master_key_type = des3-hmac-sha1
  
  3DES was deprecated by NIST in 2017, i.e. give years ago! Reference:
  https://csrc.nist.gov/News/2017/Update-to-Current-Use-and-Deprecation-
  of-TDEA . This should not be a default since a very long time, and
  particularly not for new installations. If a compatibility with out-of-
  date installations is necessary, this should be explicitly made be the
  administrator.
  
  SHA-1 was deprecated as well, in 2011, i.e. eleven years ago! Reference:
  https://nvlpubs.nist.gov/nistpubs/Legacy/SP/nistspecialpublication800-131a.pdf
  .
  
  A reasonable default

[Touch-packages] [Bug 1981697] Re: KDC: weak crypto in default settings

** Description changed:

  [ Impact ]
  
  The default crypto algorithm suite selected for the master key in the
  ubuntu krb5-kdc package is des3-hmac-sha1. This comes from a config file
  shipped with the packaging which overrides upstream's default choice.
  
  Users who deploy a KDC using this package will be using an algorithm
  deprecated since many years ago, and considered broken nowadays for
- security applications.
+ security applications. Furthermore, the KDC will highlight this fact
+ with "deprecated" warnings in the logs and elsewhere. For example:
+ 
+ root@j-kdc-weak-crypto:~# klist -ke /etc/krb5kdc/stash 
+ Keytab name: FILE:/etc/krb5kdc/stash
+ KVNO Principal
+  
--
+1 K/M@LXD (DEPRECATED:des3-cbc-sha1) 
+ 
+ And in the kdc logs:
+ Apr 05 14:20:01 j-kdc-weak-crypto krb5kdc[7323]: Stash file 
/etc/krb5kdc/stash uses DEPRECATED enctype des3-cbc-sha1!
  
  This update removes the specification of an algorithm and leaves it to
  the upstream default, which is aes256-cts-hmac-sha1-96[1].
  
  Kerberos is quite conservative when it comes to updating encryption
  algorithms, and one could argue that the default should be something
  like aes256-cts-hmac-sha384-192, but in this SRU we are sticking the
  upstream default (by not specifying any value). This is also what debian
  is doing, and what we have in kinetic and later.
  
  1. https://manpages.ubuntu.com/manpages/jammy/man5/kdc.conf.5.html
  search for "master_key_type"
  
  [ Test Plan ]
  
   * detailed instructions how to reproduce the bug
  
   * these should allow someone who is not familiar with the affected
     package to reproduce the bug and verify that the updated package fixes
     the problem.
  
   * if other testing is appropriate to perform before landing this update,
     this should also be described here.
  
  [ Where problems could occur ]
  
   * Think about what the upload changes in the software. Imagine the change is
     wrong or breaks something else: how would this show up?
  
   * It is assumed that any SRU candidate patch is well-tested before
     upload and has a low overall risk of regression, but it's important
     to make the effort to think about what ''could'' happen in the
     event of a regression.
  
   * This must '''never''' be "None" or "Low", or entirely an argument as to why
     your upload is low risk.
  
   * This both shows the SRU team that the risks have been considered,
     and provides guidance to testers in regression-testing the SRU.
  
  [ Other Info ]
  
   * Anything else you think is useful to include
   * Anticipate questions from users, SRU, +1 maintenance, security teams and 
the Technical Board
   * and address these questions in advance
  
  Default setting in /etc/krb5kdc/kdc.conf, as installed from krb5-kdc in 
Ubuntu 22.04 Server:
  master_key_type = des3-hmac-sha1
  
  3DES was deprecated by NIST in 2017, i.e. give years ago! Reference:
  https://csrc.nist.gov/News/2017/Update-to-Current-Use-and-Deprecation-
  of-TDEA . This should not be a default since a very long time, and
  particularly not for new installations. If a compatibility with out-of-
  date installations is necessary, this should be explicitly made be the
  administrator.
  
  SHA-1 was deprecated as well, in 2011, i.e. eleven years ago! Reference:
  https://nvlpubs.nist.gov/nistpubs/Legacy/SP/nistspecialpublication800-131a.pdf
  .
  
  A reasonable default would probably be:
  master_key_type = aes256-cts-hmac-sha384-192
  
  ProblemType: Bug
  DistroRelease: Ubuntu 22.04
  Package: krb5-kdc 1.19.2-2
  ProcVersionSignature: Ubuntu 5.15.0-40.43-generic 5.15.35
  Uname: Linux 5.15.0-40-generic x86_64
  ApportVersion: 2.20.11-0ubuntu82.1
  Architecture: amd64
  CasperMD5CheckResult: pass
  Date: Thu Jul 14 12:34:22 2022
  InstallationDate: Installed on 2022-05-30 (45 days ago)
  InstallationMedia: Ubuntu-Server 22.04 LTS "Jammy Jellyfish" - Release amd64 
(20220421)
  ProcEnviron:
   TERM=xterm-256color
   PATH=(custom, no user)
   XDG_RUNTIME_DIR=
   LANG=en_IE.UTF-8
   SHELL=/bin/bash
  SourcePackage: krb5
  UpgradeStatus: No upgrade log present (probably fresh install)

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

Title:
  KDC: weak crypto in default settings

Status in krb5 package in Ubuntu:
  Fix Released
Status in krb5 source package in Jammy:
  In Progress
Status in krb5 source package in Kinetic:
  Fix Released
Status in krb5 package in Debian:
  Fix Released

Bug description:
  [ Impact ]

  The default crypto algorithm suite selected for the master key in the
  ubuntu krb5-kdc package is des3-hmac-sha1. This comes from a config
  file shipped with the packaging which overrides upstream's default
  choice.

  Users who deploy a KDC using this package will be using an algorithm
  deprecated

[Touch-packages] [Bug 1981697] Re: KDC: weak crypto in default settings

** Description changed:

+ [ Impact ]
+ 
+ The default crypto algorithm suite selected for the master key in the
+ ubuntu krb5-kdc package is 3des-sha1. This comes from a config file
+ shipped with the packaging which overrides upstream's default choice.
+ 
+ Users who deploy a KDC using this package will be using an algorithm
+ deprecated since many years ago, and considered broken nowadays for
+ security applications.
+ 
+ This update removes the specification of an algorithm and leaves it to
+ the upstream default, which is aes256-cts-hmac-sha1-96[1].
+ 
+ Kerberos is quite conservative when it comes to updating encryption
+ algorithms, and one could argue that the default should be something
+ like aes256-cts-hmac-sha384-192, but in this SRU we are sticking the
+ upstream default (by not specifying any value). This is also what debian
+ is doing, and what we have in kinetic and later.
+ 
+ 1. https://manpages.ubuntu.com/manpages/jammy/man5/kdc.conf.5.html
+ search for "master_key_type"
+ 
+ 
+ [ Test Plan ]
+ 
+  * detailed instructions how to reproduce the bug
+ 
+  * these should allow someone who is not familiar with the affected
+package to reproduce the bug and verify that the updated package fixes
+the problem.
+ 
+  * if other testing is appropriate to perform before landing this update,
+this should also be described here.
+ 
+ [ Where problems could occur ]
+ 
+  * Think about what the upload changes in the software. Imagine the change is
+wrong or breaks something else: how would this show up?
+ 
+  * It is assumed that any SRU candidate patch is well-tested before
+upload and has a low overall risk of regression, but it's important
+to make the effort to think about what ''could'' happen in the
+event of a regression.
+ 
+  * This must '''never''' be "None" or "Low", or entirely an argument as to why
+your upload is low risk.
+ 
+  * This both shows the SRU team that the risks have been considered,
+and provides guidance to testers in regression-testing the SRU.
+ 
+ [ Other Info ]
+  
+  * Anything else you think is useful to include
+  * Anticipate questions from users, SRU, +1 maintenance, security teams and 
the Technical Board
+  * and address these questions in advance
+ 
+ 
  Default setting in /etc/krb5kdc/kdc.conf, as installed from krb5-kdc in 
Ubuntu 22.04 Server:
  master_key_type = des3-hmac-sha1
  
  3DES was deprecated by NIST in 2017, i.e. give years ago! Reference:
  https://csrc.nist.gov/News/2017/Update-to-Current-Use-and-Deprecation-
  of-TDEA . This should not be a default since a very long time, and
  particularly not for new installations. If a compatibility with out-of-
  date installations is necessary, this should be explicitly made be the
  administrator.
  
  SHA-1 was deprecated as well, in 2011, i.e. eleven years ago! Reference:
  https://nvlpubs.nist.gov/nistpubs/Legacy/SP/nistspecialpublication800-131a.pdf
  .
  
  A reasonable default would probably be:
  master_key_type = aes256-cts-hmac-sha384-192
  
  ProblemType: Bug
  DistroRelease: Ubuntu 22.04
  Package: krb5-kdc 1.19.2-2
  ProcVersionSignature: Ubuntu 5.15.0-40.43-generic 5.15.35
  Uname: Linux 5.15.0-40-generic x86_64
  ApportVersion: 2.20.11-0ubuntu82.1
  Architecture: amd64
  CasperMD5CheckResult: pass
  Date: Thu Jul 14 12:34:22 2022
  InstallationDate: Installed on 2022-05-30 (45 days ago)
  InstallationMedia: Ubuntu-Server 22.04 LTS "Jammy Jellyfish" - Release amd64 
(20220421)
  ProcEnviron:
-  TERM=xterm-256color
-  PATH=(custom, no user)
-  XDG_RUNTIME_DIR=
-  LANG=en_IE.UTF-8
-  SHELL=/bin/bash
+  TERM=xterm-256color
+  PATH=(custom, no user)
+  XDG_RUNTIME_DIR=
+  LANG=en_IE.UTF-8
+  SHELL=/bin/bash
  SourcePackage: krb5
  UpgradeStatus: No upgrade log present (probably fresh install)

** Description changed:

  [ Impact ]
  
  The default crypto algorithm suite selected for the master key in the
- ubuntu krb5-kdc package is 3des-sha1. This comes from a config file
+ ubuntu krb5-kdc package is des3-hmac-sha1. This comes from a config file
  shipped with the packaging which overrides upstream's default choice.
  
  Users who deploy a KDC using this package will be using an algorithm
  deprecated since many years ago, and considered broken nowadays for
  security applications.
  
  This update removes the specification of an algorithm and leaves it to
  the upstream default, which is aes256-cts-hmac-sha1-96[1].
  
  Kerberos is quite conservative when it comes to updating encryption
  algorithms, and one could argue that the default should be something
  like aes256-cts-hmac-sha384-192, but in this SRU we are sticking the
  upstream default (by not specifying any value). This is also what debian
  is doing, and what we have in kinetic and later.
  
  1. https://manpages.ubuntu.com/manpages/jammy/man5/kdc.conf.5.html
  search for "master_key_type"
  
- 
  [ Test Plan ]
  
-  * detailed instructions how to reproduce the bug
+  * detailed instructions how to

[Touch-packages] [Bug 2015355] Re: Please backport patches for false atari partition detection to Ubuntu 20.04

2023-04-05 Thread oldman

git format-patch --stdout --no-signoff tags/v2.34... --
libblkid/src/partitions/atari.c

** Patch added: "2015355.patch"
   
https://bugs.launchpad.net/ubuntu/+source/util-linux/+bug/2015355/+attachment/5661201/+files/2015355.patch

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

Title:
  Please backport patches for false atari partition detection to Ubuntu
  20.04

Status in util-linux package in Ubuntu:
  New

Bug description:
  There are three patches in util-linux upstream that were released in
  util-linux 2.37 and prevent false detection of the atari partition
  table with blkid and wipefs. We see this mostly on LUKS devices
  initialised via luksFormat reporting there is an atari partition table
  on the device when it is empty. This causes issues in various places,
  but one key example for us is in kubernetes where mount-utils will
  refuse to format the device (https://github.com/kubernetes/mount-
  utils/blob/732a08ae47571516020ef99c303c70c1fa5b3e6c/mount_linux.go#L437-L441)

  RedHat backported these fixes to RHEL 8 under
  https://bugzilla.redhat.com/show_bug.cgi?id=2060030 and it would be
  helpful if Ubuntu also backported them to Ubuntu 20.04 which is still
  running util-linux 2.34

  The request is to backport patches based on the
  https://github.com/util-linux/util-linux/issues/1159 upstream report.

  Upstream commits to cherry-pick the changes to 
libblkid/src/partitions/atari.c from: 
  2cc76d50d7a14bef8e7b07fab11b26c9e49d36a2
  282ceadc3a72fc07dd0388b8880fd751490bb87f
  c70b4f2a5b99876d230b8f4f413c3bb3ee6647f1

  # lsb_release -a
  Distributor ID: Ubuntu
  Description:Ubuntu 20.04.6 LTS
  Release:20.04
  Codename:   focal
  # blkid -V
  blkid from util-linux 2.34  (libblkid 2.34.0, 14-Jun-2019)
  # blkid -p -s TYPE -s PTTYPE -o export 
/dev/mapper/pvc-7b331195-cd5a-4ab6-8fdc-552af4b9139d_encrypted
  DEVNAME=dev/mapper/pvc-7b331195-cd5a-4ab6-8fdc-552af4b9139d_encrypted
  PTTYPE=atari
  # lsblk
  ...
  sdccrypto_LUKS
 a79d2982-74f2-44c7-bb29-460768ebfe64
  `-3600a09803830474a735d4c63744c4a56crypto_LUKS
 a79d2982-74f2-44c7-bb29-460768ebfe64
`-pvc-7b331195-cd5a-4ab6-8fdc-552af4b9139d_encrypted

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/util-linux/+bug/2015355/+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 2011415] Re: /usr/bin/software-properties-gtk:AttributeError:on_pktask_finish:net_status_changed

I've set the bug statuses to Incomplete for the benefit of future SRU
reviewers; please reset to their correct statuses once you've answered.

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

Title:
  /usr/bin/software-properties-
  gtk:AttributeError:on_pktask_finish:net_status_changed

Status in software-properties package in Ubuntu:
  Incomplete
Status in software-properties source package in Focal:
  Incomplete

Bug description:
  * Impact

  The change from the previous revision to handle connectivity change
  use an API not available on focal and trigger an exception

  * Test case

  - detach the system from ubuntu pro if it's attached
  - open software-properties
  - go the ubuntu pro tab
  - click on 'enable ubuntu pro'
  - while the dialog is open disconnect and reconnect the network
  - change the selection from manual token to PIN

  the UI should update and no error should be triggered

  Check also that the error reports stop for the new version (url
  referenced below)

  * Regression potential

  If the callback were not working as expected the UI could end up not
  responding to status change or not accepting the PIN or token entered,
  validate that the different methods still work as expected to register

  --

  The Ubuntu Error Tracker has been receiving reports about a problem regarding 
software-properties.  This problem was most recently seen with package version 
0.99.9.11, the problem page at 
https://errors.ubuntu.com/problem/22525c20f3bbf4ac03854d8a844e8d5f746b2959 
contains more details, including versions of packages affected, stacktrace or 
traceback, and individual crash reports.
  If you do not have access to the Ubuntu Error Tracker and are a software 
developer, you can request it at http://forms.canonical.com/reports/.

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/software-properties/+bug/2011415/+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 2011415] Re: /usr/bin/software-properties-gtk:AttributeError:on_pktask_finish:net_status_changed

Could you please confirm that this fix isn't relevant for releases after
Focal - ie. that the necessary API exists in Jammy onwards? It may be
that you implied this already, but the bug status isn't set separately
and I can't find anything that states this unambiguously so I want to
make sure it isn't being accidentally missed.

** Also affects: software-properties (Ubuntu Focal)
   Importance: Undecided
   Status: New

** Changed in: software-properties (Ubuntu Focal)
   Status: New => Incomplete

** Changed in: software-properties (Ubuntu)
   Status: Fix Committed => Incomplete

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

Title:
  /usr/bin/software-properties-
  gtk:AttributeError:on_pktask_finish:net_status_changed

Status in software-properties package in Ubuntu:
  Incomplete
Status in software-properties source package in Focal:
  Incomplete

Bug description:
  * Impact

  The change from the previous revision to handle connectivity change
  use an API not available on focal and trigger an exception

  * Test case

  - detach the system from ubuntu pro if it's attached
  - open software-properties
  - go the ubuntu pro tab
  - click on 'enable ubuntu pro'
  - while the dialog is open disconnect and reconnect the network
  - change the selection from manual token to PIN

  the UI should update and no error should be triggered

  Check also that the error reports stop for the new version (url
  referenced below)

  * Regression potential

  If the callback were not working as expected the UI could end up not
  responding to status change or not accepting the PIN or token entered,
  validate that the different methods still work as expected to register

  --

  The Ubuntu Error Tracker has been receiving reports about a problem regarding 
software-properties.  This problem was most recently seen with package version 
0.99.9.11, the problem page at 
https://errors.ubuntu.com/problem/22525c20f3bbf4ac03854d8a844e8d5f746b2959 
contains more details, including versions of packages affected, stacktrace or 
traceback, and individual crash reports.
  If you do not have access to the Ubuntu Error Tracker and are a software 
developer, you can request it at http://forms.canonical.com/reports/.

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/software-properties/+bug/2011415/+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 2015355] [NEW] Please backport patches for false atari partition detection to Ubuntu 20.04

2023-04-05 Thread oldman

Public bug reported:

There are three patches in util-linux upstream that were released in
util-linux 2.37 and prevent false detection of the atari partition table
with blkid and wipefs. We see this mostly on LUKS devices initialised
via luksFormat reporting there is an atari partition table on the device
when it is empty. This causes issues in various places, but one key
example for us is in kubernetes where mount-utils will refuse to format
the device (https://github.com/kubernetes/mount-
utils/blob/732a08ae47571516020ef99c303c70c1fa5b3e6c/mount_linux.go#L437-L441)

RedHat backported these fixes to RHEL 8 under
https://bugzilla.redhat.com/show_bug.cgi?id=2060030 and it would be
helpful if Ubuntu also backported them to Ubuntu 20.04 which is still
running util-linux 2.34

The request is to backport patches based on the https://github.com/util-
linux/util-linux/issues/1159 upstream report.

Upstream commits to cherry-pick the changes to libblkid/src/partitions/atari.c 
from: 
2cc76d50d7a14bef8e7b07fab11b26c9e49d36a2
282ceadc3a72fc07dd0388b8880fd751490bb87f
c70b4f2a5b99876d230b8f4f413c3bb3ee6647f1

# lsb_release -a
Distributor ID: Ubuntu
Description:Ubuntu 20.04.6 LTS
Release:20.04
Codename:   focal
# blkid -V
blkid from util-linux 2.34  (libblkid 2.34.0, 14-Jun-2019)
# blkid -p -s TYPE -s PTTYPE -o export 
/dev/mapper/pvc-7b331195-cd5a-4ab6-8fdc-552af4b9139d_encrypted
DEVNAME=dev/mapper/pvc-7b331195-cd5a-4ab6-8fdc-552af4b9139d_encrypted
PTTYPE=atari
# lsblk
...
sdccrypto_LUKS  
   a79d2982-74f2-44c7-bb29-460768ebfe64
`-3600a09803830474a735d4c63744c4a56crypto_LUKS  
   a79d2982-74f2-44c7-bb29-460768ebfe64
  `-pvc-7b331195-cd5a-4ab6-8fdc-552af4b9139d_encrypted

** Affects: util-linux (Ubuntu)
 Importance: Undecided
 Status: New


** Tags: patch

** Tags added: patch

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

Title:
  Please backport patches for false atari partition detection to Ubuntu
  20.04

Status in util-linux package in Ubuntu:
  New

Bug description:
  There are three patches in util-linux upstream that were released in
  util-linux 2.37 and prevent false detection of the atari partition
  table with blkid and wipefs. We see this mostly on LUKS devices
  initialised via luksFormat reporting there is an atari partition table
  on the device when it is empty. This causes issues in various places,
  but one key example for us is in kubernetes where mount-utils will
  refuse to format the device (https://github.com/kubernetes/mount-
  utils/blob/732a08ae47571516020ef99c303c70c1fa5b3e6c/mount_linux.go#L437-L441)

  RedHat backported these fixes to RHEL 8 under
  https://bugzilla.redhat.com/show_bug.cgi?id=2060030 and it would be
  helpful if Ubuntu also backported them to Ubuntu 20.04 which is still
  running util-linux 2.34

  The request is to backport patches based on the
  https://github.com/util-linux/util-linux/issues/1159 upstream report.

  Upstream commits to cherry-pick the changes to 
libblkid/src/partitions/atari.c from: 
  2cc76d50d7a14bef8e7b07fab11b26c9e49d36a2
  282ceadc3a72fc07dd0388b8880fd751490bb87f
  c70b4f2a5b99876d230b8f4f413c3bb3ee6647f1

  # lsb_release -a
  Distributor ID: Ubuntu
  Description:Ubuntu 20.04.6 LTS
  Release:20.04
  Codename:   focal
  # blkid -V
  blkid from util-linux 2.34  (libblkid 2.34.0, 14-Jun-2019)
  # blkid -p -s TYPE -s PTTYPE -o export 
/dev/mapper/pvc-7b331195-cd5a-4ab6-8fdc-552af4b9139d_encrypted
  DEVNAME=dev/mapper/pvc-7b331195-cd5a-4ab6-8fdc-552af4b9139d_encrypted
  PTTYPE=atari
  # lsblk
  ...
  sdccrypto_LUKS
 a79d2982-74f2-44c7-bb29-460768ebfe64
  `-3600a09803830474a735d4c63744c4a56crypto_LUKS
 a79d2982-74f2-44c7-bb29-460768ebfe64
`-pvc-7b331195-cd5a-4ab6-8fdc-552af4b9139d_encrypted

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/util-linux/+bug/2015355/+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 2015126] Re: systemd doesn't successfully enforce RuntimeMaxSec for gnome session

Er, I built and tested on kinetic, but I can build the fix for jammy
too.

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

Title:
  systemd doesn't successfully enforce RuntimeMaxSec for gnome session

Status in systemd package in Ubuntu:
  New

Bug description:
  On Jammy, I have configured systemd to set RuntimeMaxSec on certain
  user sessions:

  # cat /run/systemd/transient/session-43.scope 
  # This is a transient unit file, created programmatically via the systemd 
API. Do not edit.
  [Scope]
  Slice=user-1000.slice

  [Unit]
  Description=Session 43 of User xavier
  Wants=user-runtime-dir@1000.service
  Wants=user@1000.service
  After=systemd-logind.service
  After=systemd-user-sessions.service
  After=user-runtime-dir@1000.service
  After=user@1000.service
  RequiresMountsFor=/home/xavier

  [Scope]
  SendSIGHUP=yes
  TasksMax=infinity
  RuntimeMaxSec=2h
  #

  I have verified that this does what's expected on an ssh session, and
  kills the session when the runtime max has been reached.

  But on a GNOME login session (using X), this apparently doesn't work:
  the session is still running 17 hours after it should have been
  terminated.

  My guess is that systemd is ending the session by sending a signal
  that is being ignored by the GNOME login session?

  RuntimeMaxSec is not very useful if it's advisory...

  ProblemType: Bug
  DistroRelease: Ubuntu 22.04
  Package: systemd 249.11-0ubuntu3.7
  ProcVersionSignature: Ubuntu 5.19.0-38.39~22.04.1-generic 5.19.17
  Uname: Linux 5.19.0-38-generic x86_64
  ApportVersion: 2.20.11-0ubuntu82.3
  Architecture: amd64
  CasperMD5CheckResult: pass
  CurrentDesktop: ubuntu:GNOME
  Date: Mon Apr  3 12:20:22 2023
  InstallationDate: Installed on 2023-01-22 (70 days ago)
  InstallationMedia: Ubuntu 22.04.1 LTS "Jammy Jellyfish" - Release amd64 
(20220809.1)
  MachineType: LENOVO 2306CTO
  ProcEnviron:
   TERM=xterm-256color
   PATH=(custom, no user)
   XDG_RUNTIME_DIR=
   LANG=en_US.UTF-8
   SHELL=/bin/bash
  ProcKernelCmdLine: BOOT_IMAGE=/boot/vmlinuz-5.19.0-38-generic 
root=UUID=c415e6a8-5cd2-4d08-913d-14c00b792374 ro quiet splash vt.handoff=7
  SourcePackage: systemd
  UpgradeStatus: No upgrade log present (probably fresh install)
  dmi.bios.date: 10/25/2013
  dmi.bios.release: 2.57
  dmi.bios.vendor: LENOVO
  dmi.bios.version: G2ET97WW (2.57 )
  dmi.board.asset.tag: Not Available
  dmi.board.name: 2306CTO
  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: Not Available
  dmi.ec.firmware.release: 1.13
  dmi.modalias: 
dmi:bvnLENOVO:bvrG2ET97WW(2.57):bd10/25/2013:br2.57:efr1.13:svnLENOVO:pn2306CTO:pvrThinkPadX230:rvnLENOVO:rn2306CTO:rvrNotDefined:cvnLENOVO:ct10:cvrNotAvailable:skuLENOVO_MT_2306:
  dmi.product.family: ThinkPad X230
  dmi.product.name: 2306CTO
  dmi.product.sku: LENOVO_MT_2306
  dmi.product.version: ThinkPad X230
  dmi.sys.vendor: LENOVO

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/systemd/+bug/2015126/+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 2015126] Re: systemd doesn't successfully enforce RuntimeMaxSec for gnome session

I was able to re-produce this in a different way, but I'm pretty sure
it's the same bug that affects you. For scope units in particular, the
RuntimeMaxSec property is not applied correctly when systemd is
reloaded. E.g., if I run:

$ systemd-run --scope -u foo-1.scope /usr/bin/foo
$ mkdir -p /etc/systemd/system/foo-.scope.d/
$ cat > /etc/systemd/system/foo-.scope.d/override.conf << EOF
[Scope]
RuntimeMaxSec=10s
$ systemctl daemon-reload

Then foo-1.scope just keeps running. The setting is applied correctly if
I restart foo-1.scope, however. Running the same test for a service unit
results in the RuntimeMaxSec value being applied correctly, and the unit
is terminated.

I have built and tested a fix in ppa:enr0n/systemd-251. Does that fix
your issue?

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

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

Title:
  systemd doesn't successfully enforce RuntimeMaxSec for gnome session

Status in systemd package in Ubuntu:
  New

Bug description:
  On Jammy, I have configured systemd to set RuntimeMaxSec on certain
  user sessions:

  # cat /run/systemd/transient/session-43.scope 
  # This is a transient unit file, created programmatically via the systemd 
API. Do not edit.
  [Scope]
  Slice=user-1000.slice

  [Unit]
  Description=Session 43 of User xavier
  Wants=user-runtime-dir@1000.service
  Wants=user@1000.service
  After=systemd-logind.service
  After=systemd-user-sessions.service
  After=user-runtime-dir@1000.service
  After=user@1000.service
  RequiresMountsFor=/home/xavier

  [Scope]
  SendSIGHUP=yes
  TasksMax=infinity
  RuntimeMaxSec=2h
  #

  I have verified that this does what's expected on an ssh session, and
  kills the session when the runtime max has been reached.

  But on a GNOME login session (using X), this apparently doesn't work:
  the session is still running 17 hours after it should have been
  terminated.

  My guess is that systemd is ending the session by sending a signal
  that is being ignored by the GNOME login session?

  RuntimeMaxSec is not very useful if it's advisory...

  ProblemType: Bug
  DistroRelease: Ubuntu 22.04
  Package: systemd 249.11-0ubuntu3.7
  ProcVersionSignature: Ubuntu 5.19.0-38.39~22.04.1-generic 5.19.17
  Uname: Linux 5.19.0-38-generic x86_64
  ApportVersion: 2.20.11-0ubuntu82.3
  Architecture: amd64
  CasperMD5CheckResult: pass
  CurrentDesktop: ubuntu:GNOME
  Date: Mon Apr  3 12:20:22 2023
  InstallationDate: Installed on 2023-01-22 (70 days ago)
  InstallationMedia: Ubuntu 22.04.1 LTS "Jammy Jellyfish" - Release amd64 
(20220809.1)
  MachineType: LENOVO 2306CTO
  ProcEnviron:
   TERM=xterm-256color
   PATH=(custom, no user)
   XDG_RUNTIME_DIR=
   LANG=en_US.UTF-8
   SHELL=/bin/bash
  ProcKernelCmdLine: BOOT_IMAGE=/boot/vmlinuz-5.19.0-38-generic 
root=UUID=c415e6a8-5cd2-4d08-913d-14c00b792374 ro quiet splash vt.handoff=7
  SourcePackage: systemd
  UpgradeStatus: No upgrade log present (probably fresh install)
  dmi.bios.date: 10/25/2013
  dmi.bios.release: 2.57
  dmi.bios.vendor: LENOVO
  dmi.bios.version: G2ET97WW (2.57 )
  dmi.board.asset.tag: Not Available
  dmi.board.name: 2306CTO
  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: Not Available
  dmi.ec.firmware.release: 1.13
  dmi.modalias: 
dmi:bvnLENOVO:bvrG2ET97WW(2.57):bd10/25/2013:br2.57:efr1.13:svnLENOVO:pn2306CTO:pvrThinkPadX230:rvnLENOVO:rn2306CTO:rvrNotDefined:cvnLENOVO:ct10:cvrNotAvailable:skuLENOVO_MT_2306:
  dmi.product.family: ThinkPad X230
  dmi.product.name: 2306CTO
  dmi.product.sku: LENOVO_MT_2306
  dmi.product.version: ThinkPad X230
  dmi.sys.vendor: LENOVO

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/systemd/+bug/2015126/+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 2010561] Re: The Netplan Everywhere NetworkManager fails to supply Netplan with networking information until a connection is deleted and re-created

** Merge proposal linked:

https://code.launchpad.net/~slyon/network-manager/+git/network-manager/+merge/440401

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

Title:
The Netplan Everywhere NetworkManager fails to supply Netplan with
networking information until a connection is deleted and re-created

Status in netplan:
Triaged
Status in network-manager package in Ubuntu:
In Progress

Bug description:
Steps to reproduce:

1. Install Ubuntu Lunar or a flavor thereof onto physical hardware with a
WiFi adapter. (I used Lubuntu Lunar.)
2. Connect to WiFi and install all updates.
3. Enable the Netplan Everywhere PPA and install the updated NetworkManager
from it (further details at
https://discourse.ubuntu.com/t/call-for-testing-networkmanager-yaml-settings/32420?u=arraybolt3)
4. When the installation finishes, run "sudo netplan get".

Expected result: Networking information related to the WiFi connection
should appear in the "sudo netplan get" output.

Actual result: "sudo netplan get" returns the following:

** (process:4088): WARNING **: 12:41:41.394; Permissions for
/etc/netplan/01-network-manager-all.yaml are too open. Netplan configuration
should NOT be accessible by others.
network:
version: 2
renderer: NetworkManager

End of output. Additionally, the /etc/netplan folder does not contain
files that I would expect to be there that would contain the
networking info.

Additional information:

If I disconnect from WiFi, then delete my WiFi connection entirely in
nmtui, and *then* reconnect to the same WiFi network, "sudo netplan
get" returns the expected networking information. /etc/netplan is also
properly populated after doing this.

This bug seems like it will probably cause unintended behavior after
an upgrade from 23.04 (which uses normal NetworkManager) to 23.10
(which is supposed to be using the Netplan Everywhere NetworkManager).
People probably won't know to entirely delete the WiFi and other
connections and then reconnect them in order for the netplan output to
be usable.

To manage notifications about this bug go to:
https://bugs.launchpad.net/netplan/+bug/2010561/+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 2010561] Re: The Netplan Everywhere NetworkManager fails to supply Netplan with networking information until a connection is deleted and re-created

2023-04-05 Thread Lukas Märdian

First part is fixed in https://git.launchpad.net/network-
manager/commit/?h=netplan/lunar-gu=ed1837f

Second part is up for review in:
https://code.launchpad.net/~slyon/network-manager/+git/network-
manager/+merge/440401

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

Title:
The Netplan Everywhere NetworkManager fails to supply Netplan with
networking information until a connection is deleted and re-created

Status in netplan:
Triaged
Status in network-manager package in Ubuntu:
In Progress

Bug description:
Steps to reproduce:

Expected result: Networking information related to the WiFi connection
should appear in the "sudo netplan get" output.

Actual result: "sudo netplan get" returns the following:

End of output. Additionally, the /etc/netplan folder does not contain
files that I would expect to be there that would contain the
networking info.

Additional information:

To manage notifications about this bug go to:
https://bugs.launchpad.net/netplan/+bug/2010561/+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 2015129] Re: gstreamer 1.22.1 bugfix release

This bug was fixed in the package gst-plugins-bad1.0 - 1.22.1-1ubuntu1

---
gst-plugins-bad1.0 (1.22.1-1ubuntu1) lunar; urgency=medium

  * Merge with Debian (LP: #2015129). Remaining changes:
- Don't build wpewebkit plugins
- Stop installing camerabin2 basecamerabin jpegformat - plugins which have
  moved to -good.
- Have gstreamer-plugins-bad-1.0.pc Require gstreamer-plugins-good-1.0 -
  the package we've moved the referenced plugins to. This maintains
  compatibility with upstream software and other distributions.
- Don't build the opencv binary packages on i386, avoiding a large tree
  of numeric-related dependencies for a binary package it's not required
  to support.
- d/control, d/gstreamer1.0-plugins-bad.install, d/rules:
  + Don't require these Build-Depends on i386:
- libltc-dev, libfreeaptx-dev, libopenh264-dev, libqrencode-dev,
  libzxingcore-dev, glslc, libdirectfb-dev, liblrdf0-dev, libneon27-dev

gst-plugins-bad1.0 (1.22.1-1) experimental; urgency=medium

  * Team upload

  [ Jeremy Bicha ]
  * New upstream bugfix release

  [ Laurent Bigonville ]
  * debian/rules: Explicitly disable wayland on non-linux architectures

gst-plugins-bad1.0 (1.22.0-4) unstable; urgency=medium

  * Team upload
  * debian/rules: Disable vulkan on non-linux architectures
  * Disable zxing element on architectures where opencv doesn't build

 -- Jeremy Bicha   Tue, 04 Apr 2023 10:00:40 -0400

** Changed in: gst-plugins-bad1.0 (Ubuntu)
   Status: Triaged => Fix Released

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

Title:
  gstreamer 1.22.1 bugfix release

Status in gst-plugins-bad1.0 package in Ubuntu:
  Fix Released
Status in gst-plugins-base1.0 package in Ubuntu:
  Triaged
Status in gst-plugins-good1.0 package in Ubuntu:
  Triaged
Status in gstreamer1.0 package in Ubuntu:
  Triaged

Bug description:
  Impact
  --
  This is a stable bugfix release

  See https://gstreamer.freedesktop.org/releases/1.22/#1.22.1 for more
  details.

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/gst-plugins-bad1.0/+bug/2015129/+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 2012599] Re: tzdata 2023a/2023b/2023c release - Egypt restoring DST

Hello Dariusz, or anyone else affected,

Accepted tzdata into focal-proposed. The package will build now and be
available at
https://launchpad.net/ubuntu/+source/tzdata/2023c-0ubuntu0.20.04.0 in a
few hours, and then in the -proposed repository.

Please help us by testing this new package.  See
https://wiki.ubuntu.com/Testing/EnableProposed for documentation on how
to enable and use -proposed.  Your feedback will aid us getting this
update out to other Ubuntu users.

If this package fixes the bug for you, please add a comment to this bug,
mentioning the version of the package you tested, what testing has been
performed on the package and change the tag from verification-needed-
focal to verification-done-focal. If it does not fix the bug for you,
please add a comment stating that, and change the tag to verification-
failed-focal. In either case, without details of your testing we will
not be able to proceed.

Further information regarding the verification process can be found at
https://wiki.ubuntu.com/QATeam/PerformingSRUVerification .  Thank you in
advance for helping!

N.B. The updated package will be released to -updates after the bug(s)
fixed by this package have been verified and the package has been in
-proposed for a minimum of 7 days.

** Changed in: tzdata (Ubuntu Focal)
   Status: Triaged => Fix Committed

** Tags removed: verification-done-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 tzdata in Ubuntu.
https://bugs.launchpad.net/bugs/2012599

Title:
  tzdata 2023a/2023b/2023c release - Egypt restoring DST

Status in tzdata package in Ubuntu:
  Fix Released
Status in tzdata source package in Bionic:
  Triaged
Status in tzdata source package in Focal:
  Fix Committed
Status in tzdata source package in Jammy:
  Fix Committed
Status in tzdata source package in Kinetic:
  Fix Committed
Status in tzdata source package in Lunar:
  Fix Released

Bug description:
  [ Impact ]

  Recently the Egyptian authorities decided to restore DST. The first
  switch after the change is expected to take place on last Friday of
  April. The upstream tzdata 2023a release already reflects this change.

  The 2023a release contains the following changes:

  * Egypt now uses DST again, from April through October.
  * This year Morocco springs forward April 23, not April 30.
  * Palestine delays the start of DST this year.
  * Much of Greenland still uses DST from 2024 on.

  The 2023c release reverts the changes done in 2023b.

  [ Test Plan ]

  Test cases were added to the autopkgtest to cover the testing:

  * python: test_2023a
  * python: test_2023c
  * python: test_systemv_timezones (for releases <= 20.04 LTS)
  * python-icu: test_2023a (only for kinetic, jammy, focal)

  So the test plan is to check that the autopkgtest succeeds.

  Alternatively the python test_2023a can be run manually:

   * Set system timezone to Egypt (e.g. Africa/Cairo).
   * Set system time to 2023-04-27 23:59.
   * Wait and observe what happens at 2023-04-28 0:00

  [Test Case for releases <= 20.04 LTS]

  Additionally, an upstream update of tzdata removed the 'old' SystemV 
timezones, so we should ensure that they are kept in Ubuntu 20.04 LTS and 
earlier releases. This is done by the test_systemv_timezones test case or can 
be checked manually with the following:
  diff <(zdump -v America/Phoenix | cut -d' ' -f2-) <(zdump -v SystemV/MST7 | 
cut -d' ' -f2-)

  [ Where problems could occur ]

   * Systems with incorrect timezone set (e.g. located outside of Egypt
  but still using Egyptian time) may observe unexpected time shift.

  [ Other Info ]

  The autopkgtest for chrony is flaky on jammy and kinetic (see bug
  #2002910).

   * More information with sources:
  
https://en.wikipedia.org/wiki/Daylight_saving_time_in_Egypt#:~:text=Daylight%20saving%20time%20(DST)%20has,(DST)%20as%20of%202023.

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/tzdata/+bug/2012599/+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 1981697] Re: KDC: weak crypto in default settings