[Touch-packages] [Bug 2037604] Re: Backport packages for 22.04.4 HWE stack
Technically, the verification from prior comments was performed on 23.2.1-1ubuntu3.1~22.04.1, not 23.2.1-1ubuntu3.1~22.04.2. I think they need to be done on the mesa package that is in proposed now, which is .2. -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to mesa in Ubuntu. https://bugs.launchpad.net/bugs/2037604 Title: Backport packages for 22.04.4 HWE stack Status in directx-headers package in Ubuntu: Invalid Status in mesa package in Ubuntu: Invalid Status in rust-bindgen package in Ubuntu: Invalid Status in rust-clang-sys package in Ubuntu: Invalid Status in directx-headers source package in Jammy: Fix Committed Status in mesa source package in Jammy: Fix Committed Status in rust-bindgen source package in Jammy: Invalid Status in rust-clang-sys source package in Jammy: Invalid Bug description: [Impact] The graphics HWE stack from mantic needs to be backported for 22.04.4 directx-headers - build-dep of the new Mesa mesa - new major release (23.2.x) - new HW support, Meteor Lake.. [Test case] We want to cover at least 2-3 different, widely used and already previously supported GPU generations from both AMD and Intel which are supported by this release, as those are the ones that cover most bases; nouveau users tend to switch to the NVIDIA blob after installation. No need to test ancient GPU's supported by mesa-amber. And best to focus on the newer generations (~5y and newer) as the older ones are less likely to break at this point. - AMD: Vega, Navi1x (RX5000*), Navi2x (RX6000*), Navi3x (RX7000*) - Intel: gen9 (SKL/APL/KBL/CFL/WHL/CML), gen11 (ICL), gen12 (TGL/ADL/RKL/RPL/DG2) Install the new packages and run some tests: - check that the desktop is still using hw acceleration and hasn't fallen back to swrast/llvmpipe - run freely available benchmarks that torture the GPU (Unigine Heaven/Valley/Superposition) - run some games from Steam if possible and in each case check that there is no gfx corruption happening or worse. Note that upstream releases have already been tested for OpenGL and Vulkan conformance by their CI. [Where things could go wrong] This is a major update of Mesa, there could be regressions but we'll try to catch any with testing. And since it shares bugs with mantic, we'd already know if there are serious issues. We will backport the final 23.2.x at a later stage, the first backport is needed for enabling Intel Meteor Lake. To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/directx-headers/+bug/2037604/+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 2037604] Re: Backport packages for 22.04.4 HWE stack
** Tags removed: verification-done-jammy ** Tags added: verification-needed-jammy -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to mesa in Ubuntu. https://bugs.launchpad.net/bugs/2037604 Title: Backport packages for 22.04.4 HWE stack Status in directx-headers package in Ubuntu: Invalid Status in mesa package in Ubuntu: Invalid Status in rust-bindgen package in Ubuntu: Invalid Status in rust-clang-sys package in Ubuntu: Invalid Status in directx-headers source package in Jammy: Fix Committed Status in mesa source package in Jammy: Fix Committed Status in rust-bindgen source package in Jammy: Invalid Status in rust-clang-sys source package in Jammy: Invalid Bug description: [Impact] The graphics HWE stack from mantic needs to be backported for 22.04.4 directx-headers - build-dep of the new Mesa mesa - new major release (23.2.x) - new HW support, Meteor Lake.. [Test case] We want to cover at least 2-3 different, widely used and already previously supported GPU generations from both AMD and Intel which are supported by this release, as those are the ones that cover most bases; nouveau users tend to switch to the NVIDIA blob after installation. No need to test ancient GPU's supported by mesa-amber. And best to focus on the newer generations (~5y and newer) as the older ones are less likely to break at this point. - AMD: Vega, Navi1x (RX5000*), Navi2x (RX6000*), Navi3x (RX7000*) - Intel: gen9 (SKL/APL/KBL/CFL/WHL/CML), gen11 (ICL), gen12 (TGL/ADL/RKL/RPL/DG2) Install the new packages and run some tests: - check that the desktop is still using hw acceleration and hasn't fallen back to swrast/llvmpipe - run freely available benchmarks that torture the GPU (Unigine Heaven/Valley/Superposition) - run some games from Steam if possible and in each case check that there is no gfx corruption happening or worse. Note that upstream releases have already been tested for OpenGL and Vulkan conformance by their CI. [Where things could go wrong] This is a major update of Mesa, there could be regressions but we'll try to catch any with testing. And since it shares bugs with mantic, we'd already know if there are serious issues. We will backport the final 23.2.x at a later stage, the first backport is needed for enabling Intel Meteor Lake. To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/directx-headers/+bug/2037604/+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 2016303] Re: Rebuild NSS with support for system-wide config file
> Quick question: is pkcs11.txt a default filename used anywhere else? Where did the filename come from? ¯\_(ツ)_/¯ There is a lot (a lot) of history here, buried deep somewhere in the internet... -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to nss in Ubuntu. https://bugs.launchpad.net/bugs/2016303 Title: Rebuild NSS with support for system-wide config file Status in nss package in Ubuntu: Confirmed Bug description: NSS should be rebuilt with this patch: diff --git a/debian/libnss3.dirs b/debian/libnss3.dirs new file mode 100644 index ..0f796964 --- /dev/null +++ b/debian/libnss3.dirs @@ -0,0 +1 @@ +etc/nss diff --git a/debian/rules b/debian/rules index 5ab1ced0..51bee160 100755 --- a/debian/rules +++ b/debian/rules @@ -128,6 +128,8 @@ override_dh_auto_build: NSS_USE_SYSTEM_SQLITE=1 \ NSS_ENABLE_ECC=1 \ CHECKLOC= \ + POLICY_FILE=pkcs11.txt \ + POLICY_PATH=/etc/nss \ $(TOOLCHAIN) override_dh_auto_clean: The directory could be another one, of course. This will allow us to create a system-wide /etc/nss/pkcs11.txt file which could load the NSS policy module. The upstream documentation is quite poor and outdated, unfortunately: https://firefox-source-docs.mozilla.org/security/nss/legacy/nss_config_options/ https://firefox-source-docs.mozilla.org/security/nss/legacy/pkcs11/module_specs/index.html The current source code is the best documentation, and has a ton of tests that show how to use the policy module: - allow/disallow options: https://git.launchpad.net/ubuntu/+source/nss/tree/nss/lib/pk11wrap/pk11pars.c#n144 - versions and key sizes: https://git.launchpad.net/ubuntu/+source/nss/tree/nss/lib/pk11wrap/pk11pars.c#n437 - other qualifiers for algorithms (which types of signatures): https://git.launchpad.net/ubuntu/+source/nss/tree/nss/lib/pk11wrap/pk11pars.c#n451 - tons of policy tests: https://git.launchpad.net/ubuntu/+source/nss/tree/nss/tests/ssl/sslpolicy.txt and https://git.launchpad.net/ubuntu/+source/nss/tree/nss/tests/policy Here is a sample /etc/nss/pkcs11.txt which enables the policy module with certain values: library= name=Policy NSS=flags=policyOnly,moduleDB config="disallow=ALL allow=HMAC-SHA256:HMAC-SHA1:HMAC-SHA384:HMAC-SHA512:CURVE25519:SECP256R1:SECP384R1:SECP521R1:aes256-gcm:chacha20-poly1305:aes256-cbc:aes128-gcm:aes128-cbc:SHA256:SHA384:SHA512:SHA224:ECDHE-RSA:ECDHE-ECDSA:RSA:DHE-RSA:ECDSA:RSA-PSS:RSA-PKCS:tls-version-min=tls1.2:dtls-version-min=dtls1.2:DH-MIN=2048:DSA-MIN=2048:RSA-MIN=2048" The same config snippet can of course be used in ~/.pki/nssdb/pkcs11.txt or in any of the other many places we have a pkcs11.txt file on the system (hence the need for this build option: to have just one place): - firefox: ~/snap/firefox/common/.mozilla/firefox/pqx65eu1.default/pkcs11.txt - thunderbid: ~/.thunderbird/6mxs87xg.default-release/pkcs11.txt - chrome and system-provided libnss3: ~/.pki/nssdb/pkcs11.txt Note thunderbird ships its own libnss3 (zomg), and would not be affected by this build change (unless it's done in the thunderbird source package too). To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/nss/+bug/2016303/+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 2047450] Re: tail emits no output for sysfs files when using large page kernels
The migration-reference/0 runs passed, to the dep8 results are still not good. I retriggered the failing arm64 tests one more time. -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to coreutils in Ubuntu. https://bugs.launchpad.net/bugs/2047450 Title: tail emits no output for sysfs files when using large page kernels Status in coreutils package in Ubuntu: Fix Released Status in coreutils source package in Jammy: Fix Committed Status in coreutils source package in Lunar: Won't Fix Status in coreutils source package in Mantic: Fix Committed Status in coreutils source package in Noble: Fix Released Bug description: [Impact] Ubuntu provides 64K page size kernels for ppc64el (always) and arm64 (optional -64k flavors). When booted on 64K kernels, tail emits no output when tailing a sysfs file. The difference in behavior can be a source for bugs in scripts that use tail, and general user confusion. [Test Plan] The upstream fix includes a test case that tails the /sys/kernel/profiling file, if it exists. That case would fail with an unfixed coreutils package as shown below: = When booted on a 4K kernel = ubuntu@gunyolk:~$ tail /sys/kernel/profiling 0 = When booted on a 64K kernel = ubuntu@gunyolk:~$ tail /sys/kernel/profiling ubuntu@gunyolk:~$ Since the upstream test cases are executed at build time, the existing tests and this new test will be used to regression test behavior. This should cover both 4K (!ppc64el) and 64K (ppc64el) cases. We should also do a manual verification on arm64 w/ the 64K kernel since that case is not covered by our builders. [Where Problems Could Occur] The biggest risk for a regression I see is due to the side-effect of the fix now allocating a dynamic buffer instead of the stack. An error in logic there could cause a crash or a memory leak in scenarios undetected during testing. I used valgrind when developing the fix to derisk the memory leak scenario. To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/coreutils/+bug/2047450/+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 2047450] Re: tail emits no output for sysfs files when using large page kernels
mantic is releseable, but I'll wait for the jammy results until the end of my shift. If they are still red, I can release just mantic. -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to coreutils in Ubuntu. https://bugs.launchpad.net/bugs/2047450 Title: tail emits no output for sysfs files when using large page kernels Status in coreutils package in Ubuntu: Fix Released Status in coreutils source package in Jammy: Fix Committed Status in coreutils source package in Lunar: Won't Fix Status in coreutils source package in Mantic: Fix Committed Status in coreutils source package in Noble: Fix Released Bug description: [Impact] Ubuntu provides 64K page size kernels for ppc64el (always) and arm64 (optional -64k flavors). When booted on 64K kernels, tail emits no output when tailing a sysfs file. The difference in behavior can be a source for bugs in scripts that use tail, and general user confusion. [Test Plan] The upstream fix includes a test case that tails the /sys/kernel/profiling file, if it exists. That case would fail with an unfixed coreutils package as shown below: = When booted on a 4K kernel = ubuntu@gunyolk:~$ tail /sys/kernel/profiling 0 = When booted on a 64K kernel = ubuntu@gunyolk:~$ tail /sys/kernel/profiling ubuntu@gunyolk:~$ Since the upstream test cases are executed at build time, the existing tests and this new test will be used to regression test behavior. This should cover both 4K (!ppc64el) and 64K (ppc64el) cases. We should also do a manual verification on arm64 w/ the 64K kernel since that case is not covered by our builders. [Where Problems Could Occur] The biggest risk for a regression I see is due to the side-effect of the fix now allocating a dynamic buffer instead of the stack. An error in logic there could cause a crash or a memory leak in scenarios undetected during testing. I used valgrind when developing the fix to derisk the memory leak scenario. To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/coreutils/+bug/2047450/+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 2002043] Re: Python extension modules get built using wrong compiler flags with python2
Maybe it's just me, but could we please clarify in the test plan exactly what flag changes are we expecting? Given the change is to honor or not the "OPT" flags, I was expecting an additional test plan that would set those, and then show that they are included when the workaround var is set. That's much easier to verify. Keep the tests you have, please, but what do you think about this extra test? It would clearly show when OPT is used and not. -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to python2.7 in Ubuntu. https://bugs.launchpad.net/bugs/2002043 Title: Python extension modules get built using wrong compiler flags with python2 Status in python2.7 package in Ubuntu: Invalid Status in python2.7 source package in Bionic: Won't Fix Status in python2.7 source package in Focal: In Progress Status in python2.7 source package in Jammy: Fix Committed Status in python2.7 source package in Kinetic: Invalid Status in python2.7 source package in Lunar: Invalid Status in python2.7 source package in Mantic: Invalid Bug description: [ Impact ] When compiling Python extensions using Python2, CFLAGS optimization flags are dropped. This behavior has been caused by our update in this patch http://archive.ubuntu.com/ubuntu/pool/universe/p/python2.7/python2.7_2.7.18-1~20.04.3.diff.gz which differs from upstream. The fix modifies the portion of code in Lib/distutils/sysconfig.py which gets the cflags from the environments, and includes the dropped OPT flag from get_config_vars(). [ Test Plan ] There will be 2 separate tests for this bug: * Ensuring no-change rebuilds are not changed * Ensuring local builds are not changed unless environment variable is set Test 1) No-change rebuilds To test that no-change rebuilds are not changed, the package python- stdlib-extensions will be built against the new python2.7, and confirm the compiler flags are not altered. This will be a manual test and visual inspection of the build logs. Test 2) Functional test 1. Create test container $ lxc launch ubuntu:jammy jammy-2002043 $ lxc shell ubuntu:jammy jammy-2002043 2. Install required packages For Jammy # apt update -y && apt install -y python2 python-pip For Focal # apt update -y && apt install -y python2 python-setuptools 3. Create test files # mkdir testprog # cd testprog # cat >setup.py
[Touch-packages] [Bug 2002043] Re: Python extension modules get built using wrong compiler flags with python2
Hello Nafees, or anyone else affected, Accepted python2.7 into focal-proposed. The package will build now and be available at https://launchpad.net/ubuntu/+source/python2.7/2.7.18-1~20.04.4 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: python2.7 (Ubuntu Focal) Status: In Progress => Fix Committed ** Tags added: verification-needed-focal -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to python2.7 in Ubuntu. https://bugs.launchpad.net/bugs/2002043 Title: Python extension modules get built using wrong compiler flags with python2 Status in python2.7 package in Ubuntu: Invalid Status in python2.7 source package in Bionic: Won't Fix Status in python2.7 source package in Focal: Fix Committed Status in python2.7 source package in Jammy: Fix Committed Status in python2.7 source package in Kinetic: Invalid Status in python2.7 source package in Lunar: Invalid Status in python2.7 source package in Mantic: Invalid Bug description: [ Impact ] When compiling Python extensions using Python2, CFLAGS optimization flags are dropped. This behavior has been caused by our update in this patch http://archive.ubuntu.com/ubuntu/pool/universe/p/python2.7/python2.7_2.7.18-1~20.04.3.diff.gz which differs from upstream. The fix modifies the portion of code in Lib/distutils/sysconfig.py which gets the cflags from the environments, and includes the dropped OPT flag from get_config_vars(). [ Test Plan ] There will be 2 separate tests for this bug: * Ensuring no-change rebuilds are not changed * Ensuring local builds are not changed unless environment variable is set Test 1) No-change rebuilds To test that no-change rebuilds are not changed, the package python- stdlib-extensions will be built against the new python2.7, and confirm the compiler flags are not altered. This will be a manual test and visual inspection of the build logs. Test 2) Functional test 1. Create test container $ lxc launch ubuntu:jammy jammy-2002043 $ lxc shell ubuntu:jammy jammy-2002043 2. Install required packages For Jammy # apt update -y && apt install -y python2 python-pip For Focal # apt update -y && apt install -y python2 python-setuptools 3. Create test files # mkdir testprog # cd testprog # cat >setup.py
Re: [Touch-packages] [Bug 2002043] Re: Python extension modules get built using wrong compiler flags with python2
You can add something obvious, like -DMITCHELL_WAS_HERE :)
On Thu, 8 Feb 2024, 18:35 Mitchell Dzurick, <2002...@bugs.launchpad.net>
wrote:
> That's a great idea Andreas! It's a little difficult to pinpoint the
> exact OPT flags as they are bunched up with the other compiler flags, so
> I'll add a test in addition to the current ones which makes it easier to
> see what's happening.
>
> --
> You received this bug notification because you are a member of Ubuntu
> Pythoneers, which is subscribed to python2.7 in Ubuntu.
> https://bugs.launchpad.net/bugs/2002043
>
> Title:
> Python extension modules get built using wrong compiler flags with
> python2
>
> Status in python2.7 package in Ubuntu:
> Invalid
> Status in python2.7 source package in Bionic:
> Won't Fix
> Status in python2.7 source package in Focal:
> Fix Committed
> Status in python2.7 source package in Jammy:
> Fix Committed
> Status in python2.7 source package in Kinetic:
> Invalid
> Status in python2.7 source package in Lunar:
> Invalid
> Status in python2.7 source package in Mantic:
> Invalid
>
> Bug description:
> [ Impact ]
>
> When compiling Python extensions using Python2, CFLAGS optimization
> flags are dropped.
>
> This behavior has been caused by our update in this patch
>
> http://archive.ubuntu.com/ubuntu/pool/universe/p/python2.7/python2.7_2.7.18-1~20.04.3.diff.gz
> which differs from upstream.
>
> The fix modifies the portion of code in Lib/distutils/sysconfig.py
> which gets the cflags from the environments, and includes the dropped
> OPT flag from get_config_vars().
>
> [ Test Plan ]
>
> There will be 2 separate tests for this bug:
> * Ensuring no-change rebuilds are not changed
> * Ensuring local builds are not changed unless environment variable is
> set
>
> Test 1) No-change rebuilds
>
> To test that no-change rebuilds are not changed, the package python-
> stdlib-extensions will be built against the new python2.7, and confirm
> the compiler flags are not altered. This will be a manual test and
> visual inspection of the build logs.
>
> Test 2) Functional test
>
> 1. Create test container
> $ lxc launch ubuntu:jammy jammy-2002043
> $ lxc shell ubuntu:jammy jammy-2002043
>
> 2. Install required packages
> For Jammy
> # apt update -y && apt install -y python2 python-pip
> For Focal
> # apt update -y && apt install -y python2 python-setuptools
>
> 3. Create test files
> # mkdir testprog
> # cd testprog
> # cat >setup.py < from setuptools import setup, Extension
>
> setup(
> name="test",
> ext_modules=[Extension("test", sources=["testmodule.c"])],
> zip_safe=False
> )
> EOL
> # cat >testmodule.c < #include
>
> int main(void)
> {
> printf("This is test program");
> return 0;
> }
> EOL
>
> 4. Compile a test program
> # python2 setup.py build_ext --inplace
>
> 5. Check CFLAGS
> # python2 -c "import sysconfig;
> print(sysconfig.get_config_var('CFLAGS'))"
> -fno-strict-aliasing -DNDEBUG -g -fwrapv -O2 -Wall -Wstrict-prototypes
> -Wdate-time -D_FORTIFY_SOURCE=2 -g
> -ffile-prefix-map=/build/python2.7-W40Ff2/python2.7-2.7.18=. -flto=auto
> -ffat-lto-objects -flto=auto -ffat-lto-objects -fstack-protector-strong
> -Wformat -Werror=format-security
>
> 6. Check the flags used to compile the test wheel
> # strings build/lib.linux-x86_64-2.7/test.so | grep -- -O
> GNU GIMPLE 11.4.0 -mtune=generic -march=x86-64 -g -g -g -g -O2
> -fno-openmp -fno-openacc -fcf-protection=full -fno-strict-aliasing -fwrapv
> -fstack-protector-strong -ffat-lto-objects -fstack-protector-strong -fPIC
> -fltrans
>
> 7. Install fixed python
> Once updated, this will simply be an apt update && apt upgrade
> # add-apt-repository ppa:mitchdz/python2.7-optimization-flags -y
> # apt install -y python2.7
> # dpkg -s python2.7 | grep Version:
> Version: 2.7.18-13ubuntu1.2~jammy9
>
> 8. Clean build
> # rm -rf build/ test.so
>
> 9. Enable opt-in environment variable
> # export APPLY_LP2002043_UBUNTU_CFLAGS_WORKAROUND=""
>
> 9. Rebuild with new python2.7 installed
> # python2 setup.py build_ext --inplace
>
> 10. Check build flags
> # strings build/lib.linux-x86_64-2.7/test.so | grep -- -O
> GNU GIMPLE 11.4.0 -mtune=generic -march=x86-64 -g -g -g -g -O2 -O2
> -fno-openmp -fno-openacc -fcf-protection=full -fno-strict-aliasing -fwrapv
> -fstack-protector-strong -ffat-lto-objects -fstack-protector-strong -fPIC
> -fltrans
> GNU C17 11.4.0 -mtune=generic -march=x86-64 -g -g -O2
> -fno-strict-aliasing -fwrapv -flto -flto -ffat-lto-objects
> -fstack-protector-strong -fPIC -fasynchronous-unwind-tables
> -fstack-protector-strong -fstack-clash-protection -fcf-protection
>
> [ Where problems could occur ]
>
> * Changing optimization flags can cause a myriad of unattended side
> effects, but the change being opt-in means the users should be aware a
> change is being made
> * The change is opt-in, so an infor
[Touch-packages] [Bug 2040465] Re: New upstream microrelease 2.5.17
Hello Bryce, or anyone else affected, Accepted openldap into jammy-proposed. The package will build now and be available at https://launchpad.net/ubuntu/+source/openldap/2.5.17+dfsg-0ubuntu0.22.04.1 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- jammy to verification-done-jammy. If it does not fix the bug for you, please add a comment stating that, and change the tag to verification- failed-jammy. 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: openldap (Ubuntu Jammy) Status: In Progress => Fix Committed ** Tags added: verification-needed verification-needed-jammy -- 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/2040465 Title: New upstream microrelease 2.5.17 Status in openldap package in Ubuntu: Invalid Status in openldap source package in Jammy: Fix Committed Bug description: [ Impact ] * MRE for the latest stable OpenLDAP 2.5.x release, 2.5.17. This update includes bugfixes only following the SRU policy exception defined at https://wiki.ubuntu.com/OpenLDAPUpdates. [ Major Changes ] * See the list of bugs fixed in this release here: https://lists.openldap.org/hyperkitty/list/openldap- annou...@openldap.org/thread/XRQE4CVQDLTG4EYPKVEU2L76DYGIFR2Q/ [ Test Plan ] * Upstream gitlab pipeline results: https://git.openldap.org/openldap/openldap/-/commit/99a124bb434052a71cf4ff115d0f949f6c6b7208/pipelines?ref=OPENLDAP_REL_ENG_2_5 * Upstream "call for testing": https://lists.openldap.org/hyperkitty/list/openldap- techni...@openldap.org/thread/4744NWC2HJP7L24WOUMZF4VCYGGUMRI7/ * As described in the MRE wiki page for OpenLDAP, the test plan is to build the package in a PPA and make sure that (1) all build-time tests pass and (2) all autopkgtest runs (from reverse dependencies) also pass. * Build log (amd64) confirming that the build-time testsuite has been performed and completed successfully: - https://launchpadlibrarian.net/679769800/buildlog_ubuntu-jammy-amd64.openldap_2.5.16+dfsg-0ubuntu0.22.04.1~ppa1_BUILDING.txt.gz [ Where problems could occur ] * Upstream tests are always executed during build-time. There are many reverse dependencies whose dep8 tests depend on OpenLDAP so the coverage is good. Nevertheless, there is always a risk for something to break since we are dealing with a microrelease upgrade. Whenever a test failure is detected, we will be on top of it and make sure it doesn't affect existing users. [ Other Info ] * This is a reoccurring MRE. See below for links to previous OpenLDAP MREs. * CVEs fixed by this release: - None. Current versions in supported releases that got updates: openldap | 2.5.16+dfsg-0ubuntu0.22.04.2 | jammy-security | source Special cases: - None. Previous MREs for OpenLDAP: - https://pad.lv/1977627 - https://pad.lv/1983618 - https://pad.lv/2007625 - https://pad.lv/2027079 - https://pad.lv/2029170 As usual we test and prep from the PPA and then push through SRU/Security as applicable. To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/openldap/+bug/2040465/+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 2052739] Re: tzdata 2024a release
The SRU documentation[1] on tzdata describes other, or additional, tests, to be performed in this package. Is that: a) assumed, and will be done? b) autopkgtests cover it? c) was forgotten, and should be added to the test plan? 1. https://wiki.ubuntu.com/StableReleaseUpdates#tzdata -- 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/2052739 Title: tzdata 2024a release Status in tzdata package in Ubuntu: Fix Released Status in tzdata source package in Focal: Confirmed Status in tzdata source package in Jammy: Confirmed Status in tzdata source package in Mantic: Confirmed Bug description: [ Impact ] The 2024a release contains the following changes: * Kazakhstan unifies on UTC+5 beginning 2024-03-01. * Palestine springs forward a week later after Ramadan. * zic no longer pretends to support indefinite-past DST. * localtime no longer mishandles Ciudad Juárez in 2422. [ Test Plan ] Test cases were added to the autopkgtest to cover the testing: * python: test_2024a * python-icu: test_2024a (only for focal and newer) So the test plan is to check that the autopkgtest succeeds. [ Other Info ] The autopkgtest for chrony is flaky on jammy and newer (see bug #2002910). To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/tzdata/+bug/2052739/+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 2052739] Re: tzdata 2024a release
I'm not familiar with this package, so maybe not the best person to review this SRU, but here is another question. The SRU docs on tzdata also mention python3-icu, but I don't see an update for that package here or in the unapproved queue. Is that necessary? Or is it just about verifying that python3-icu does not break after bin:tzdata-icu was updated? -- 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/2052739 Title: tzdata 2024a release Status in tzdata package in Ubuntu: Fix Released Status in tzdata source package in Focal: Confirmed Status in tzdata source package in Jammy: Confirmed Status in tzdata source package in Mantic: Confirmed Bug description: [ Impact ] The 2024a release contains the following changes: * Kazakhstan unifies on UTC+5 beginning 2024-03-01. * Palestine springs forward a week later after Ramadan. * zic no longer pretends to support indefinite-past DST. * localtime no longer mishandles Ciudad Juárez in 2422. [ Test Plan ] Test cases were added to the autopkgtest to cover the testing: * python: test_2024a * python-icu: test_2024a (only for focal and newer) So the test plan is to check that the autopkgtest succeeds. [ Other Info ] The autopkgtest for chrony is flaky on jammy and newer (see bug #2002910). To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/tzdata/+bug/2052739/+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 2052739] Re: tzdata 2024a release
Finally, the SRU doc also says this: "Uploads should also be made to any releases supported via ESM." Are you going to drive that as well? -- 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/2052739 Title: tzdata 2024a release Status in tzdata package in Ubuntu: Fix Released Status in tzdata source package in Focal: Confirmed Status in tzdata source package in Jammy: Confirmed Status in tzdata source package in Mantic: Confirmed Bug description: [ Impact ] The 2024a release contains the following changes: * Kazakhstan unifies on UTC+5 beginning 2024-03-01. * Palestine springs forward a week later after Ramadan. * zic no longer pretends to support indefinite-past DST. * localtime no longer mishandles Ciudad Juárez in 2422. [ Test Plan ] Test cases were added to the autopkgtest to cover the testing: * python: test_2024a * python-icu: test_2024a (only for focal and newer) So the test plan is to check that the autopkgtest succeeds. [ Other Info ] The autopkgtest for chrony is flaky on jammy and newer (see bug #2002910). To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/tzdata/+bug/2052739/+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 2052739] Re: tzdata 2024a release
Hello Benjamin, or anyone else affected, Accepted tzdata into mantic-proposed. The package will build now and be available at https://launchpad.net/ubuntu/+source/tzdata/2024a-0ubuntu0.23.10 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- mantic to verification-done-mantic. If it does not fix the bug for you, please add a comment stating that, and change the tag to verification- failed-mantic. 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 Mantic) Status: Confirmed => Fix Committed ** Tags added: verification-needed verification-needed-mantic ** Changed in: tzdata (Ubuntu Jammy) Status: Confirmed => Fix Committed ** Tags added: verification-needed-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/2052739 Title: tzdata 2024a release Status in tzdata package in Ubuntu: Fix Released Status in tzdata source package in Focal: Fix Committed Status in tzdata source package in Jammy: Fix Committed Status in tzdata source package in Mantic: Fix Committed Bug description: [ Impact ] The 2024a release contains the following changes: * Kazakhstan unifies on UTC+5 beginning 2024-03-01. * Palestine springs forward a week later after Ramadan. * zic no longer pretends to support indefinite-past DST. * localtime no longer mishandles Ciudad Juárez in 2422. [ Test Plan ] Test cases were added to the autopkgtest to cover the testing: * python: test_2024a * python-icu: test_2024a (only for focal and newer) So the test plan is to check that the autopkgtest succeeds. [ Other Info ] The autopkgtest for chrony is flaky on jammy and newer (see bug #2002910). To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/tzdata/+bug/2052739/+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 2052739] Please test proposed package
Hello Benjamin, or anyone else affected, Accepted tzdata into jammy-proposed. The package will build now and be available at https://launchpad.net/ubuntu/+source/tzdata/2024a-0ubuntu0.22.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- jammy to verification-done-jammy. If it does not fix the bug for you, please add a comment stating that, and change the tag to verification- failed-jammy. 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: Confirmed => Fix Committed ** 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/2052739 Title: tzdata 2024a release Status in tzdata package in Ubuntu: Fix Released Status in tzdata source package in Focal: Fix Committed Status in tzdata source package in Jammy: Fix Committed Status in tzdata source package in Mantic: Fix Committed Bug description: [ Impact ] The 2024a release contains the following changes: * Kazakhstan unifies on UTC+5 beginning 2024-03-01. * Palestine springs forward a week later after Ramadan. * zic no longer pretends to support indefinite-past DST. * localtime no longer mishandles Ciudad Juárez in 2422. [ Test Plan ] Test cases were added to the autopkgtest to cover the testing: * python: test_2024a * python-icu: test_2024a (only for focal and newer) So the test plan is to check that the autopkgtest succeeds. [ Other Info ] The autopkgtest for chrony is flaky on jammy and newer (see bug #2002910). To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/tzdata/+bug/2052739/+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 2052739] Please test proposed package
Hello Benjamin, or anyone else affected, Accepted tzdata into focal-proposed. The package will build now and be available at https://launchpad.net/ubuntu/+source/tzdata/2024a-0ubuntu0.20.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- 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. -- 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/2052739 Title: tzdata 2024a release Status in tzdata package in Ubuntu: Fix Released Status in tzdata source package in Focal: Fix Committed Status in tzdata source package in Jammy: Fix Committed Status in tzdata source package in Mantic: Fix Committed Bug description: [ Impact ] The 2024a release contains the following changes: * Kazakhstan unifies on UTC+5 beginning 2024-03-01. * Palestine springs forward a week later after Ramadan. * zic no longer pretends to support indefinite-past DST. * localtime no longer mishandles Ciudad Juárez in 2422. [ Test Plan ] Test cases were added to the autopkgtest to cover the testing: * python: test_2024a * python-icu: test_2024a (only for focal and newer) So the test plan is to check that the autopkgtest succeeds. [ Other Info ] The autopkgtest for chrony is flaky on jammy and newer (see bug #2002910). To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/tzdata/+bug/2052739/+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 2052739] Re: tzdata 2024a release
@security, could you please sign off on this tzdata SRU, according to the SRU procedure[1] for this package? 1. https://wiki.ubuntu.com/StableReleaseUpdates#tzdata -- 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/2052739 Title: tzdata 2024a release Status in tzdata package in Ubuntu: Fix Released Status in tzdata source package in Focal: Fix Committed Status in tzdata source package in Jammy: Fix Committed Status in tzdata source package in Mantic: Fix Committed Bug description: [ Impact ] The 2024a release contains the following changes: * Kazakhstan unifies on UTC+5 beginning 2024-03-01. * Palestine springs forward a week later after Ramadan. * zic no longer pretends to support indefinite-past DST. * localtime no longer mishandles Ciudad Juárez in 2422. [ Test Plan ] Test cases were added to the autopkgtest to cover the testing: * python: test_2024a * python-icu: test_2024a (only for focal and newer) So the test plan is to check that the autopkgtest succeeds. [ Other Info ] The autopkgtest for chrony is flaky on jammy and newer (see bug #2002910). To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/tzdata/+bug/2052739/+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 2052739] Re: tzdata 2024a release
The 7 day aging period will be hit later today. Releasing it now. -- 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/2052739 Title: tzdata 2024a release Status in tzdata package in Ubuntu: Fix Released Status in tzdata source package in Focal: Fix Released Status in tzdata source package in Jammy: Fix Released Status in tzdata source package in Mantic: Fix Released Bug description: [ Impact ] The 2024a release contains the following changes: * Kazakhstan unifies on UTC+5 beginning 2024-03-01. * Palestine springs forward a week later after Ramadan. * zic no longer pretends to support indefinite-past DST. * localtime no longer mishandles Ciudad Juárez in 2422. [ Test Plan ] Test cases were added to the autopkgtest to cover the testing: * python: test_2024a * python-icu: test_2024a (only for focal and newer) So the test plan is to check that the autopkgtest succeeds. [ Other Info ] The autopkgtest for chrony is flaky on jammy and newer (see bug #2002910). To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/tzdata/+bug/2052739/+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 2052739] Update Released
The verification of the Stable Release Update for tzdata has completed successfully and the package is now being released to -updates. Subsequently, the Ubuntu Stable Release Updates Team is being unsubscribed and will not receive messages about this bug report. In the event that you encounter a regression using the package from -updates please report a new bug using ubuntu-bug and tag the bug report regression-update so we can easily find any regressions. -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to tzdata in Ubuntu. https://bugs.launchpad.net/bugs/2052739 Title: tzdata 2024a release Status in tzdata package in Ubuntu: Fix Released Status in tzdata source package in Focal: Fix Released Status in tzdata source package in Jammy: Fix Released Status in tzdata source package in Mantic: Fix Released Bug description: [ Impact ] The 2024a release contains the following changes: * Kazakhstan unifies on UTC+5 beginning 2024-03-01. * Palestine springs forward a week later after Ramadan. * zic no longer pretends to support indefinite-past DST. * localtime no longer mishandles Ciudad Juárez in 2422. [ Test Plan ] Test cases were added to the autopkgtest to cover the testing: * python: test_2024a * python-icu: test_2024a (only for focal and newer) So the test plan is to check that the autopkgtest succeeds. [ Other Info ] The autopkgtest for chrony is flaky on jammy and newer (see bug #2002910). To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/tzdata/+bug/2052739/+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 2055718] [NEW] Regression after update: timezone changed unexpectedly
Public bug reported: A user reported this regression on https://bugs.launchpad.net/ubuntu/+source/tzdata/+bug/2052739: """ Hello. After automatic upgrade of tzdata from 2023c-0ubuntu0.22.04.2 to 2024a-0ubuntu0.22.04 the previously set EST time zone was automatically changed to "America/Adak" or "America/Indiana/Indianapolis" on all our servers (50+). Look like a bug in tzdata configure script. """ ** Affects: tzdata (Ubuntu) Importance: High Status: New ** Tags: regression-update -- 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/2055718 Title: Regression after update: timezone changed unexpectedly Status in tzdata package in Ubuntu: New Bug description: A user reported this regression on https://bugs.launchpad.net/ubuntu/+source/tzdata/+bug/2052739: """ Hello. After automatic upgrade of tzdata from 2023c-0ubuntu0.22.04.2 to 2024a-0ubuntu0.22.04 the previously set EST time zone was automatically changed to "America/Adak" or "America/Indiana/Indianapolis" on all our servers (50+). Look like a bug in tzdata configure script. """ To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/tzdata/+bug/2055718/+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 2052739] Re: tzdata 2024a release
Hi Vladimir, I'm sorry to hear that. What was the previously timezone that you had set? Just EST? I filed https://bugs.launchpad.net/ubuntu/+source/tzdata/+bug/2055718 about your report, if you could please amend it with more details. ** Tags added: regression-update -- 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/2052739 Title: tzdata 2024a release Status in tzdata package in Ubuntu: Fix Released Status in tzdata source package in Focal: Fix Released Status in tzdata source package in Jammy: Fix Released Status in tzdata source package in Mantic: Fix Released Bug description: [ Impact ] The 2024a release contains the following changes: * Kazakhstan unifies on UTC+5 beginning 2024-03-01. * Palestine springs forward a week later after Ramadan. * zic no longer pretends to support indefinite-past DST. * localtime no longer mishandles Ciudad Juárez in 2422. [ Test Plan ] Test cases were added to the autopkgtest to cover the testing: * python: test_2024a * python-icu: test_2024a (only for focal and newer) So the test plan is to check that the autopkgtest succeeds. [ Other Info ] The autopkgtest for chrony is flaky on jammy and newer (see bug #2002910). To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/tzdata/+bug/2052739/+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 2055718] Re: Regression after update: timezone changed unexpectedly
I did a quick test in a jammy VM, and didn't observe this change: ubuntu@j:~$ date Fri Mar 1 13:29:18 EST 2024 ubuntu@j:~$ dpkg -l tzdata Desired=Unknown/Install/Remove/Purge/Hold | Status=Not/Inst/Conf-files/Unpacked/halF-conf/Half-inst/trig-aWait/Trig-pend |/ Err?=(none)/Reinst-required (Status,Err: uppercase=bad) ||/ Name Version Architecture Description +++-==---=== ii tzdata 2023d-0ubuntu0.22.04 all time zone and daylight-saving time data (update in another terminal) ubuntu@j:~$ date Fri Mar 1 13:30:12 EST 2024 ubuntu@j:~$ dpkg -l tzdata Desired=Unknown/Install/Remove/Purge/Hold | Status=Not/Inst/Conf-files/Unpacked/halF-conf/Half-inst/trig-aWait/Trig-pend |/ Err?=(none)/Reinst-required (Status,Err: uppercase=bad) ||/ Name Version Architecture Description +++-==---=== ii tzdata 2024a-0ubuntu0.22.04 all time zone and daylight-saving time data ubuntu@j:~$ ** Changed in: tzdata (Ubuntu) Status: New => Incomplete -- 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/2055718 Title: Regression after update: timezone changed unexpectedly Status in tzdata package in Ubuntu: Incomplete Bug description: A user reported this regression on https://bugs.launchpad.net/ubuntu/+source/tzdata/+bug/2052739: """ Hello. After automatic upgrade of tzdata from 2023c-0ubuntu0.22.04.2 to 2024a-0ubuntu0.22.04 the previously set EST time zone was automatically changed to "America/Adak" or "America/Indiana/Indianapolis" on all our servers (50+). Look like a bug in tzdata configure script. """ To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/tzdata/+bug/2055718/+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 2054681] Re: Merge console-setup (1.226) from Debian
Left comments in the MP. ** Changed in: console-setup (Ubuntu) Status: New => Incomplete -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to console-setup in Ubuntu. https://bugs.launchpad.net/bugs/2054681 Title: Merge console-setup (1.226) from Debian Status in console-setup package in Ubuntu: Incomplete Bug description: In Debian console-setup (1.226) is available. It should be merged into Noble. To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/console-setup/+bug/2054681/+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 2055088] Re: debian/control incorrectly installs gnome-session dependencies in ubuntu-budgie
> d/control is used on the official gtk desktops such as budgie. Excuse my unfamiliarity with desktop packages, but I don't understand the above statement. Until someone from desktop reviews this, my question would be very basic: what is the problem this is trying to solve? What is happening, that shouldn't happen? ** Changed in: software-properties (Ubuntu) Status: New => 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/2055088 Title: debian/control incorrectly installs gnome-session dependencies in ubuntu-budgie Status in software-properties package in Ubuntu: Incomplete Bug description: d/control is used on the official gtk desktops such as budgie. budgie-desktop for noble now uses budgie-session instead of gnome- session. software-properties needs an update to its dependency list To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/software-properties/+bug/2055088/+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 2036761] Re: [mantic] ppa-purge no longer purges what add-apt-repository adds
Sponsored for noble. ** Changed in: ppa-purge (Ubuntu Noble) Status: Triaged => Fix Committed -- 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/2036761 Title: [mantic] ppa-purge no longer purges what add-apt-repository adds Status in ppa-purge package in Ubuntu: Fix Committed Status in software-properties package in Ubuntu: Confirmed Status in ppa-purge source package in Mantic: Triaged Status in software-properties source package in Mantic: Confirmed Status in ppa-purge source package in Noble: Fix Committed Status in software-properties source package in Noble: Confirmed Bug description: Thank you @jbicha for the original bug report! [ Impact ] Currently ppa-purge fails to purge packages on distribution using the deb822 source format. Currently mantic and noble make use of this format and are affected by this issue. When running ppa-purge to remove a custom PPA, ppa-purge fails to disable the custom PPA since it cannot disable deb822 sources and leads to apt still querying the ppa when running: $ apt update In older versions of ubuntu, PPAs used the ".list" format which could be disabled by simply commenting out the "deb" line with a "#". This was the method that ppa-purge used to disable PPAs. This new patch allows ppa-purge to detect and disable deb822 source files by adding an "Enabled: no" field in each component section of the deb822 file. It also removes any line that starts with "Enabled:" to make sure the resulting file is clean. [ Test Plan ] The changes were tested on both mantic and noble in a lxc container using the oibaf mesa PPA (https://launchpad.net/~oibaf/+archive/ubuntu/graphics-drivers) as the test PPA. The following steps were recorded in a noble lxc container. - First make sure that mesa-utils is installed in your environment: $ sudo apt update && sudo apt install mesa-utils - Add the oibaf PPA to your system using the following command: $ sudo add-apt-repository ppa:oibaf/graphics-drivers - Make sure that the mesa-utils packages were upgraded after adding the PPA: $ sudo apt update && sudo apt upgrade $ dpkg - l | grep mesa - output should be similar to the following: ii libegl-mesa0:amd64 24.1~git2402280600.41722c~oibaf~n amd64free implementation of the EGL API -- Mesa vendor library ii libgl1-mesa-dri:amd64 24.1~git2402280600.41722c~oibaf~n amd64free implementation of the OpenGL API -- DRI modules ii libglapi-mesa:amd64 24.1~git2402280600.41722c~oibaf~n amd64free implementation of the GL API -- shared library ii libglx-mesa0:amd64 24.1~git2402280600.41722c~oibaf~n amd64free implementation of the OpenGL API -- GLX vendor library ii mesa-utils 9.0.0-2 amd64Miscellaneous Mesa utilities -- symlinks ii mesa-utils-bin:amd649.0.0-2 amd64Miscellaneous Mesa utilities -- native applications ii mesa-vulkan-drivers:amd64 24.1~git2402280600.41722c~oibaf~n amd64Mesa Vulkan graphics drivers - Install and run ppa-purge: $ sudo apt install ppa-purge $ sudo ppa-purge ppa:oibaf/graphics-drivers - ppa-purge will report at the end that none of the oibaf packages need to be downgraded/removed: libglapi-mesa is already the newest version (24.1~git2402280600.41722c~oibaf~n). libglapi-mesa set to manually installed. libglx-mesa0 is already the newest version (24.1~git2402280600.41722c~oibaf~n). libglx-mesa0 set to manually installed. mesa-vulkan-drivers is already the newest version (24.1~git2402280600.41722c~oibaf~n). mesa-vulkan-drivers set to manually installed. Selected version '2.4.120+git2402271331.1b4e04~oibaf~n' (Updated Open Graphics Drivers - since 2011!:24.04/noble [amd64]) for 'libdrm-amdgpu1' Selected version '2.4.120+git2402271331.1b4e04~oibaf~n' (Updated Open Graphics Drivers - since 2011!:24.04/noble [all]) for 'libdrm-common' Selected version '2.4.120+git2402271331.1b4e04~oibaf~n' (Updated Open Graphics Drivers - since 2011!:24.04/noble [amd64]) for 'libdrm-intel1' Selected version '2.4.120+git2402271331.1b4e04~oibaf~n' (Updated Open Graphics Drivers - since 2011!:24.04/noble [amd64]) for 'libdrm-nouveau2' Selected version '2.4.120+git2402271331.1b4e04~oibaf~n' (Updated Open Graphics Drivers - since 2011!:24.04/noble [amd64]) for 'libdrm-radeon1' Selected version '2.4.120+git2402271331.1b4e04~oibaf~n' (Updated Open Graphics Drivers - since 2011!:24.04/noble [amd64]) for 'libdrm2' Selected version '24.1~git2402280600.41722c~oibaf~n' (Updated Open G
[Touch-packages] [Bug 2055718] Re: Regression after update: timezone changed unexpectedly
That happens also with the current version of tzdata. Starting with: $ dpkg -l tzdata|grep tzdata ii tzdata 2022a-0ubuntu1 all $ date Mon Mar 4 12:22:38 UTC 2024 # the current timezone (UTC) was configured via dpkg-reconfigure tzdata $ sudo apt reinstall tzdata=2022a-0ubuntu1 Reading package lists... Done Building dependency tree... Done Reading state information... Done 0 upgraded, 0 newly installed, 1 reinstalled, 0 to remove and 0 not upgraded. Need to get 342 kB of archives. After this operation, 0 B of additional disk space will be used. Get:1 http://br.archive.ubuntu.com/ubuntu jammy/main amd64 tzdata all 2022a-0ubuntu1 [342 kB] Fetched 342 kB in 0s (11.1 MB/s) Preconfiguring packages ... (Reading database ... 31964 files and directories currently installed.) Preparing to unpack .../tzdata_2022a-0ubuntu1_all.deb ... Unpacking tzdata (2022a-0ubuntu1) over (2022a-0ubuntu1) ... Setting up tzdata (2022a-0ubuntu1) ... Current default time zone: 'Etc/UTC' Local time is now: Mon Mar 4 12:22:55 UTC 2024. Universal Time is now: Mon Mar 4 12:22:55 UTC 2024. Run 'dpkg-reconfigure tzdata' if you wish to change it. Timezone is kept, as expected. Now I set it via timedatectl: ubuntu@j-tz:~$ sudo timedatectl set-timezone EST ubuntu@j-tz:~$ date Mon Mar 4 07:23:42 EST 2024 Reinstall same tzdata: $ sudo apt reinstall tzdata=2022a-0ubuntu1 Reading package lists... Done Building dependency tree... Done Reading state information... Done 0 upgraded, 0 newly installed, 1 reinstalled, 0 to remove and 0 not upgraded. Need to get 342 kB of archives. After this operation, 0 B of additional disk space will be used. Get:1 http://br.archive.ubuntu.com/ubuntu jammy/main amd64 tzdata all 2022a-0ubuntu1 [342 kB] Fetched 342 kB in 0s (14.6 MB/s) Preconfiguring packages ... (Reading database ... 31964 files and directories currently installed.) Preparing to unpack .../tzdata_2022a-0ubuntu1_all.deb ... Unpacking tzdata (2022a-0ubuntu1) over (2022a-0ubuntu1) ... Setting up tzdata (2022a-0ubuntu1) ... Current default time zone: 'America/Adak' Local time is now: Mon Mar 4 02:23:57 HST 2024. Universal Time is now: Mon Mar 4 12:23:57 UTC 2024. Run 'dpkg-reconfigure tzdata' if you wish to change it. And we get America/Adak: $ date Mon Mar 4 02:24:08 HST 2024 So I don't think it's a regression, and am updating the tags accordingly. ** Tags removed: regression-update -- 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/2055718 Title: Regression after update: timezone changed unexpectedly Status in tzdata package in Ubuntu: Incomplete Bug description: A user reported this regression on https://bugs.launchpad.net/ubuntu/+source/tzdata/+bug/2052739: """ Hello. After automatic upgrade of tzdata from 2023c-0ubuntu0.22.04.2 to 2024a-0ubuntu0.22.04 the previously set EST time zone was automatically changed to "America/Adak" or "America/Indiana/Indianapolis" on all our servers (50+). Look like a bug in tzdata configure script. """ To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/tzdata/+bug/2055718/+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 2052739] Re: tzdata 2024a release
Given https://bugs.launchpad.net/ubuntu/+source/tzdata/+bug/2055718/comments/5, I don't think it's a regression in the update. Removing the regression- update tag. ** Tags removed: regression-update -- 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/2052739 Title: tzdata 2024a release Status in tzdata package in Ubuntu: Fix Released Status in tzdata source package in Focal: Fix Released Status in tzdata source package in Jammy: Fix Released Status in tzdata source package in Mantic: Fix Released Bug description: [ Impact ] The 2024a release contains the following changes: * Kazakhstan unifies on UTC+5 beginning 2024-03-01. * Palestine springs forward a week later after Ramadan. * zic no longer pretends to support indefinite-past DST. * localtime no longer mishandles Ciudad Juárez in 2422. [ Test Plan ] Test cases were added to the autopkgtest to cover the testing: * python: test_2024a * python-icu: test_2024a (only for focal and newer) So the test plan is to check that the autopkgtest succeeds. [ Other Info ] The autopkgtest for chrony is flaky on jammy and newer (see bug #2002910). To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/tzdata/+bug/2052739/+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 2055718] Re: Regression after update: timezone changed unexpectedly
** Changed in: tzdata (Ubuntu) Status: Incomplete => Confirmed ** Summary changed: - Regression after update: timezone changed unexpectedly + timezone changed unexpectedly ** Description changed: A user reported this regression on https://bugs.launchpad.net/ubuntu/+source/tzdata/+bug/2052739: + + UPDATE: I don't think it's a regression anymore, see comment #5 """ Hello. After automatic upgrade of tzdata from 2023c-0ubuntu0.22.04.2 to 2024a-0ubuntu0.22.04 the previously set EST time zone was automatically changed to "America/Adak" or "America/Indiana/Indianapolis" on all our servers (50+). Look like a bug in tzdata configure script. """ -- 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/2055718 Title: timezone changed unexpectedly Status in tzdata package in Ubuntu: Confirmed Bug description: A user reported this regression on https://bugs.launchpad.net/ubuntu/+source/tzdata/+bug/2052739: UPDATE: I don't think it's a regression anymore, see comment #5 """ Hello. After automatic upgrade of tzdata from 2023c-0ubuntu0.22.04.2 to 2024a-0ubuntu0.22.04 the previously set EST time zone was automatically changed to "America/Adak" or "America/Indiana/Indianapolis" on all our servers (50+). Look like a bug in tzdata configure script. """ To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/tzdata/+bug/2055718/+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 2052925] Re: lpoptions -d as root
I noticed this SRU was prepared without the SRU Template[1] filled in. While most of the data we want is in the bug description as is (what's wrong, test plan), it's lacking an analysis of what could go wrong. That boat has sailed now, and doing an analysis of the patch right now, basically what could go wrong is if someone was relying on the old behavior, of the command only changing the local user's (root in this case) config, instead of system-wide. The lpoptions[1] manpage doesn't really special case root when the -d option is used: -d destination[/instance] Sets the user default printer to destination. If instance is supplied then that particular instance is used. This option overrides the system default printer for the current user. But later down, in "FILES", we see: ~/.cups/lpoptions - user defaults and instances created by non-root users. /etc/cups/lpoptions - system-wide defaults and instances created by the root user. So it does seem the intention of that option when used by the root user was to update the system-wide /etc/cups/lpoptions file instead. So even if someone was relying on the previous behavior, it was incorrect, and the documentation (which could be clearer, but isn't) seems to agree that the previous behavior was incorrect. That's the kind of analysis we would like to see in "what could go wrong", and "other info" sections of the SRU template. 1. https://manpages.ubuntu.com/manpages/jammy/en/man1/lpoptions.1.html -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to cups in Ubuntu. https://bugs.launchpad.net/bugs/2052925 Title: lpoptions -d as root Status in cups package in Ubuntu: Fix Released Status in cups source package in Jammy: Fix Released Bug description: Copied from https://github.com/OpenPrinting/cups/issues/454 Yair Yarom submitted Debian bug 1008053 and observed that running lpoptions as root does not update /etc/cups/lpoptions but /root/.cups/lpoptions. Running lpoptions as root (e.g. "lpoptions -d HP-OfficeJet") should update /etc/cups/lpoptions to be the defaults for all users. But instead it tries to update /root/.cups/lpoptions. This has been fixed upstream in cups, in debian sid, and mantic. Proposing to add this change in jammy and older (still supported) series as well. The fix is a one line change in https://github.com/OpenPrinting/cups/pull/456 Thanks. 1) The release of Ubuntu you are using, via 'lsb_release -rd' or System -> About Ubuntu ubuntu@jammy-vm:~$ lsb_release -rd Description: Ubuntu 22.04.3 LTS Release: 22.04 2) The version of the package you are using, via 'apt-cache policy pkgname' or by checking in Software Center ubuntu@jammy-vm:~$ apt-cache policy cups cups: Installed: 2.4.1op1-1ubuntu4.7 Candidate: 2.4.1op1-1ubuntu4.7 Version table: *** 2.4.1op1-1ubuntu4.7 500 500 http://archive.ubuntu.com/ubuntu jammy-updates/main amd64 Packages 500 http://security.ubuntu.com/ubuntu jammy-security/main amd64 Packages 100 /var/lib/dpkg/status 2.4.1op1-1ubuntu4 500 500 http://archive.ubuntu.com/ubuntu jammy/main amd64 Packages 3) What you expected to happen: root@jammy-vm:~# lpstat -p printer HP-Officejet-Pro-8710 is idle. enabled since Thu 01 Feb 2024 03:17:49 PM UTC root@jammy-vm:~# root@jammy-vm:~# lpoptions -d HP-Officejet-Pro-8710 copies=1 device-uri=lpd://10.20.135.153:515/PASSTHRU finishings=3 job-cancel-after=10800 job-hold-until=no-hold job-priority=50 job-sheets=none,none marker-change-time=0 number-up=1 print-color-mode=color printer-commands=none printer-info=HP-Officejet-Pro-8710 printer-is-accepting-jobs=true printer-is-shared=true printer-is-temporary=false printer-location printer-make-and-model='HP Officejet Pro 8710, hpcups 3.21.12' printer-state=3 printer-state-change-time=1706800669 printer-state-reasons=none printer-type=4124 printer-uri-supported=ipp://localhost/printers/HP-Officejet-Pro-8710 root@jammy-vm:~# root@jammy-vm:~# cat /etc/cups/lpoptions Default HP-Officejet-Pro-8710 root@jammy-vm:~# root@jammy-vm:~# cat /root/.cups/lpoptions cat: /etc/cups/lpoptions: No such file or directory root@jammy-vm:~# 4) What happened instead: root@jammy-vm:~# lpstat -p printer HP-Officejet-Pro-8710 is idle. enabled since Thu 01 Feb 2024 03:17:49 PM UTC root@jammy-vm:~# root@jammy-vm:~# lpoptions -d HP-Officejet-Pro-8710 copies=1 device-uri=lpd://10.20.135.153:515/PASSTHRU finishings=3 job-cancel-after=10800 job-hold-until=no-hold job-priority=50 job-sheets=none,none marker-change-time=0 number-up=1 print-color-mode=color printer-commands=none printer-info=HP-Officejet-Pro-8710 printer-is-accepting-jobs=true printer-is-shared=true printer-is-temporary=false printer-location printer-make-and-model='HP Officejet Pro 8710,
[Touch-packages] [Bug 2052925] Update Released
The verification of the Stable Release Update for cups has completed successfully and the package is now being released to -updates. Subsequently, the Ubuntu Stable Release Updates Team is being unsubscribed and will not receive messages about this bug report. In the event that you encounter a regression using the package from -updates please report a new bug using ubuntu-bug and tag the bug report regression-update so we can easily find any regressions. -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to cups in Ubuntu. https://bugs.launchpad.net/bugs/2052925 Title: lpoptions -d as root Status in cups package in Ubuntu: Fix Released Status in cups source package in Jammy: Fix Released Bug description: Copied from https://github.com/OpenPrinting/cups/issues/454 Yair Yarom submitted Debian bug 1008053 and observed that running lpoptions as root does not update /etc/cups/lpoptions but /root/.cups/lpoptions. Running lpoptions as root (e.g. "lpoptions -d HP-OfficeJet") should update /etc/cups/lpoptions to be the defaults for all users. But instead it tries to update /root/.cups/lpoptions. This has been fixed upstream in cups, in debian sid, and mantic. Proposing to add this change in jammy and older (still supported) series as well. The fix is a one line change in https://github.com/OpenPrinting/cups/pull/456 Thanks. 1) The release of Ubuntu you are using, via 'lsb_release -rd' or System -> About Ubuntu ubuntu@jammy-vm:~$ lsb_release -rd Description: Ubuntu 22.04.3 LTS Release: 22.04 2) The version of the package you are using, via 'apt-cache policy pkgname' or by checking in Software Center ubuntu@jammy-vm:~$ apt-cache policy cups cups: Installed: 2.4.1op1-1ubuntu4.7 Candidate: 2.4.1op1-1ubuntu4.7 Version table: *** 2.4.1op1-1ubuntu4.7 500 500 http://archive.ubuntu.com/ubuntu jammy-updates/main amd64 Packages 500 http://security.ubuntu.com/ubuntu jammy-security/main amd64 Packages 100 /var/lib/dpkg/status 2.4.1op1-1ubuntu4 500 500 http://archive.ubuntu.com/ubuntu jammy/main amd64 Packages 3) What you expected to happen: root@jammy-vm:~# lpstat -p printer HP-Officejet-Pro-8710 is idle. enabled since Thu 01 Feb 2024 03:17:49 PM UTC root@jammy-vm:~# root@jammy-vm:~# lpoptions -d HP-Officejet-Pro-8710 copies=1 device-uri=lpd://10.20.135.153:515/PASSTHRU finishings=3 job-cancel-after=10800 job-hold-until=no-hold job-priority=50 job-sheets=none,none marker-change-time=0 number-up=1 print-color-mode=color printer-commands=none printer-info=HP-Officejet-Pro-8710 printer-is-accepting-jobs=true printer-is-shared=true printer-is-temporary=false printer-location printer-make-and-model='HP Officejet Pro 8710, hpcups 3.21.12' printer-state=3 printer-state-change-time=1706800669 printer-state-reasons=none printer-type=4124 printer-uri-supported=ipp://localhost/printers/HP-Officejet-Pro-8710 root@jammy-vm:~# root@jammy-vm:~# cat /etc/cups/lpoptions Default HP-Officejet-Pro-8710 root@jammy-vm:~# root@jammy-vm:~# cat /root/.cups/lpoptions cat: /etc/cups/lpoptions: No such file or directory root@jammy-vm:~# 4) What happened instead: root@jammy-vm:~# lpstat -p printer HP-Officejet-Pro-8710 is idle. enabled since Thu 01 Feb 2024 03:17:49 PM UTC root@jammy-vm:~# root@jammy-vm:~# lpoptions -d HP-Officejet-Pro-8710 copies=1 device-uri=lpd://10.20.135.153:515/PASSTHRU finishings=3 job-cancel-after=10800 job-hold-until=no-hold job-priority=50 job-sheets=none,none marker-change-time=0 number-up=1 print-color-mode=color printer-commands=none printer-info=HP-Officejet-Pro-8710 printer-is-accepting-jobs=true printer-is-shared=true printer-is-temporary=false printer-location printer-make-and-model='HP Officejet Pro 8710, hpcups 3.21.12' printer-state=3 printer-state-change-time=1706800669 printer-state-reasons=none printer-type=4124 printer-uri-supported=ipp://localhost/printers/HP-Officejet-Pro-8710 root@jammy-vm:~# root@jammy-vm:~# cat /etc/cups/lpoptions cat: /etc/cups/lpoptions: No such file or directory root@jammy-vm:~# root@jammy-vm:~# cat /root/.cups/lpoptions Default HP-Officejet-Pro-8710 root@jammy-vm:~# To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/cups/+bug/2052925/+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 2002043] Re: Python extension modules get built using wrong compiler flags with python2
I grabbed one of the focal failures from comment #49, mercurial: focal amd64 mercurial 5.3.1-1ubuntu1 4 python2.7/2.7.18-1~20.04.4 That is indeed mostly red in [1], including the recent run with python2.7 from this SRU. And it's not showing up as a failure in the excuses[2] report. But it's hinted[3] on s390x: # mercurial tests are flakey in focal https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=956697 force-badtest mercurial/5.3.1-1ubuntu1/s390x So that would explain it not being flagged for s390x, but not for amd64. I'm still puzzled: I didn't find another hint. I retriggered the mercurial amd64 test, let's see if a new result refreshes the report. 1. https://autopkgtest.ubuntu.com/packages/m/mercurial/focal/amd64 2. https://ubuntu-archive-team.ubuntu.com/proposed-migration/focal/update_excuses.html#python2.7 3. https://git.launchpad.net/~ubuntu-release/britney/+git/hints-ubuntu/commit/?id=8f4fd5462e98199c76909d3510911c573f0fa071 ** Bug watch added: Debian Bug tracker #956697 https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=956697 -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to python2.7 in Ubuntu. https://bugs.launchpad.net/bugs/2002043 Title: Python extension modules get built using wrong compiler flags with python2 Status in python2.7 package in Ubuntu: Invalid Status in python2.7 source package in Bionic: Won't Fix Status in python2.7 source package in Focal: Fix Committed Status in python2.7 source package in Jammy: Fix Committed Status in python2.7 source package in Kinetic: Invalid Status in python2.7 source package in Lunar: Invalid Status in python2.7 source package in Mantic: Invalid Bug description: [ Impact ] When compiling Python extensions using Python2, CFLAGS optimization flags are dropped. This behavior has been caused by our update in this patch http://archive.ubuntu.com/ubuntu/pool/universe/p/python2.7/python2.7_2.7.18-1~20.04.3.diff.gz which differs from upstream. The fix modifies the portion of code in Lib/distutils/sysconfig.py which gets the cflags from the environments, and includes the dropped OPT flag from get_config_vars(). [ Test Plan ] There will be 2 separate tests for this bug: * Ensuring no-change rebuilds are not changed * Ensuring local builds are not changed unless environment variable is set Test 1) No-change rebuilds To test that no-change rebuilds are not changed, the package python- stdlib-extensions will be built against the new python2.7, and confirm the compiler flags are not altered. This will be a manual test and visual inspection of the build logs. Test 2) Functional test 1. Create test container $ lxc launch ubuntu:jammy jammy-2002043 $ lxc shell jammy-2002043 2. Install required packages For Jammy # apt update -y && apt install -y python2 python-pip For Focal # apt update -y && apt install -y python2 python-setuptools gcc 3. Create test files # mkdir testprog # cd testprog # cat >setup.py
[Touch-packages] [Bug 2002043] Re: Python extension modules get built using wrong compiler flags with python2
> So that would explain it not being flagged for s390x, but not for amd64. I'm > still puzzled: I didn't find > another hint. Ah, it's because of a migration-reference/0 run from last year: 5.3.1-1ubuntu1 migration-reference/0 None2023-06-20 09:25:36 UTC 0h 37m 11s schopin fail @mfo, I think your query is indeed showing the raw data, but not the interpretation of the results. The analysis seems to be missing: - hints - migration-reference/0 runs I don't know if there is another db-like file that has "final" results that take all of this into account, or if it has to be analyzed each time by the excuses report when deciding if a failure should be flagged or not. But at least on the above mercurial failure, I think it's a failure that is correctly not being shown in the excuses report. -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to python2.7 in Ubuntu. https://bugs.launchpad.net/bugs/2002043 Title: Python extension modules get built using wrong compiler flags with python2 Status in python2.7 package in Ubuntu: Invalid Status in python2.7 source package in Bionic: Won't Fix Status in python2.7 source package in Focal: Fix Committed Status in python2.7 source package in Jammy: Fix Committed Status in python2.7 source package in Kinetic: Invalid Status in python2.7 source package in Lunar: Invalid Status in python2.7 source package in Mantic: Invalid Bug description: [ Impact ] When compiling Python extensions using Python2, CFLAGS optimization flags are dropped. This behavior has been caused by our update in this patch http://archive.ubuntu.com/ubuntu/pool/universe/p/python2.7/python2.7_2.7.18-1~20.04.3.diff.gz which differs from upstream. The fix modifies the portion of code in Lib/distutils/sysconfig.py which gets the cflags from the environments, and includes the dropped OPT flag from get_config_vars(). [ Test Plan ] There will be 2 separate tests for this bug: * Ensuring no-change rebuilds are not changed * Ensuring local builds are not changed unless environment variable is set Test 1) No-change rebuilds To test that no-change rebuilds are not changed, the package python- stdlib-extensions will be built against the new python2.7, and confirm the compiler flags are not altered. This will be a manual test and visual inspection of the build logs. Test 2) Functional test 1. Create test container $ lxc launch ubuntu:jammy jammy-2002043 $ lxc shell jammy-2002043 2. Install required packages For Jammy # apt update -y && apt install -y python2 python-pip For Focal # apt update -y && apt install -y python2 python-setuptools gcc 3. Create test files # mkdir testprog # cd testprog # cat >setup.py
[Touch-packages] [Bug 2002043] Re: Python extension modules get built using wrong compiler flags with python2
Taking a look at another focal result from the table in comment 49: focal amd64 pam-python 1.0.7-1ubuntu1 4 python2.7/2.7.18-1~20.04.4 No hints in the hints-ubuntu repository, focal branch. But there is a migration-reference/0 run that failed that exact same version: 1.0.7-1ubuntu1 migration-reference/0 None2021-12-13 19:37:26 UTC 0h 02m 11s - fail So the recent failure is not reported in the excuses page. I'm starting to think that's the same for all cases (heh, sample of 2). @mfo, do you agree? -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to python2.7 in Ubuntu. https://bugs.launchpad.net/bugs/2002043 Title: Python extension modules get built using wrong compiler flags with python2 Status in python2.7 package in Ubuntu: Invalid Status in python2.7 source package in Bionic: Won't Fix Status in python2.7 source package in Focal: Fix Committed Status in python2.7 source package in Jammy: Fix Committed Status in python2.7 source package in Kinetic: Invalid Status in python2.7 source package in Lunar: Invalid Status in python2.7 source package in Mantic: Invalid Bug description: [ Impact ] When compiling Python extensions using Python2, CFLAGS optimization flags are dropped. This behavior has been caused by our update in this patch http://archive.ubuntu.com/ubuntu/pool/universe/p/python2.7/python2.7_2.7.18-1~20.04.3.diff.gz which differs from upstream. The fix modifies the portion of code in Lib/distutils/sysconfig.py which gets the cflags from the environments, and includes the dropped OPT flag from get_config_vars(). [ Test Plan ] There will be 2 separate tests for this bug: * Ensuring no-change rebuilds are not changed * Ensuring local builds are not changed unless environment variable is set Test 1) No-change rebuilds To test that no-change rebuilds are not changed, the package python- stdlib-extensions will be built against the new python2.7, and confirm the compiler flags are not altered. This will be a manual test and visual inspection of the build logs. Test 2) Functional test 1. Create test container $ lxc launch ubuntu:jammy jammy-2002043 $ lxc shell jammy-2002043 2. Install required packages For Jammy # apt update -y && apt install -y python2 python-pip For Focal # apt update -y && apt install -y python2 python-setuptools gcc 3. Create test files # mkdir testprog # cd testprog # cat >setup.py
[Touch-packages] [Bug 2002043] Re: Python extension modules get built using wrong compiler flags with python2
Checking the jammy amd64 autopkgtest runs[1], we can see that the top most one is the run for this sru. Its log[2] is showing, at the end, a good run, but if you look more carefully, there are some test failures that apparently are being ignored. In particular: 1910s == 1910s FAIL: test_customize_compiler (distutils.tests.test_sysconfig.SysconfigTestCase) 1910s -- 1910s Traceback (most recent call last): 1910s File "/usr/lib/python2.7/distutils/tests/test_sysconfig.py", line 110, in test_customize_compiler 1910s 'env_cc --sc-cflags --env-cflags --env-cppflags') 1910s AssertionError: 'env_cc -fno-strict-aliasing --env-cflags --env-cppflags' != 'env_cc --sc-cflags --env-cflags --env-cppflags' That is exactly the function being touched by this patch. Could we have a bit of an investigation on what's going on? Was it failing before, and keeps failing now? Is this SRU patch affecting this test? 1. https://autopkgtest.ubuntu.com/packages/python2.7/jammy/amd64 2. https://autopkgtest.ubuntu.com/results/autopkgtest-jammy/jammy/amd64/p/python2.7/20240202_171211_eb91c@/log.gz -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to python2.7 in Ubuntu. https://bugs.launchpad.net/bugs/2002043 Title: Python extension modules get built using wrong compiler flags with python2 Status in python2.7 package in Ubuntu: Invalid Status in python2.7 source package in Bionic: Won't Fix Status in python2.7 source package in Focal: Fix Committed Status in python2.7 source package in Jammy: Fix Committed Status in python2.7 source package in Kinetic: Invalid Status in python2.7 source package in Lunar: Invalid Status in python2.7 source package in Mantic: Invalid Bug description: [ Impact ] When compiling Python extensions using Python2, CFLAGS optimization flags are dropped. This behavior has been caused by our update in this patch http://archive.ubuntu.com/ubuntu/pool/universe/p/python2.7/python2.7_2.7.18-1~20.04.3.diff.gz which differs from upstream. The fix modifies the portion of code in Lib/distutils/sysconfig.py which gets the cflags from the environments, and includes the dropped OPT flag from get_config_vars(). [ Test Plan ] There will be 2 separate tests for this bug: * Ensuring no-change rebuilds are not changed * Ensuring local builds are not changed unless environment variable is set Test 1) No-change rebuilds To test that no-change rebuilds are not changed, the package python- stdlib-extensions will be built against the new python2.7, and confirm the compiler flags are not altered. This will be a manual test and visual inspection of the build logs. Test 2) Functional test 1. Create test container $ lxc launch ubuntu:jammy jammy-2002043 $ lxc shell jammy-2002043 2. Install required packages For Jammy # apt update -y && apt install -y python2 python-pip For Focal # apt update -y && apt install -y python2 python-setuptools gcc 3. Create test files # mkdir testprog # cd testprog # cat >setup.py
[Touch-packages] [Bug 2053146] Re: openssh 8.9p1 for Jammy auth2-gss patch for gssapi-keyex method is slightly wrong
** Changed in: openssh (Ubuntu)
Status: Incomplete => In Progress
--
You received this bug notification because you are a member of Ubuntu
Touch seeded packages, which is subscribed to openssh in Ubuntu.
https://bugs.launchpad.net/bugs/2053146
Title:
openssh 8.9p1 for Jammy auth2-gss patch for gssapi-keyex method is
slightly wrong
Status in openssh package in Ubuntu:
In Progress
Bug description:
The Authmethod struct now have 4 entries but the initialization of the
method_gsskeyex in the debian/patches/gssapi.patch only have 3
entries.
The struct was changed in upstream commit
dbb339f015c33d63484261d140c84ad875a9e548 as
===
@@ -104,7 +104,8 @@ struct Authctxt {
struct Authmethod {
char*name;
- int (*userauth)(struct ssh *);
+ char*synonym;
+ int (*userauth)(struct ssh *, const char *);
int *enabled;
};
===
The incorrect code does
===
+Authmethod method_gsskeyex = {
+ "gssapi-keyex",
+ userauth_gsskeyex,
+ &options.gss_authentication
+};
===
but should have a NULL between the "gssapi-keyex" string and userauth_gsskeyex
This is now (change from Focal) causing gssapi-keyex to be disabled.
===
lsb_release -rd
Description: Ubuntu 22.04.3 LTS
Release: 22.04
===
apt-cache policy openssh-server
openssh-server:
Installed: 1:8.9p1-3ubuntu0.6
Candidate: 1:8.9p1-3ubuntu0.6
Version table:
*** 1:8.9p1-3ubuntu0.6 500
500 http://faiserver.hpc2n.umu.se/mirrors/ubuntu/ubuntu
jammy-updates/main amd64 Packages
500 http://faiserver.hpc2n.umu.se/mirrors/ubuntu/ubuntu
jammy-security/main amd64 Packages
100 /var/lib/dpkg/status
1:8.9p1-3 500
500 http://faiserver.hpc2n.umu.se/mirrors/ubuntu/ubuntu jammy/main
amd64 Packages
===
To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/openssh/+bug/2053146/+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 2054609] Re: package ntp Jammy 1:4.2.8p15+dfsg-1ubuntu2 failed to install/upgrade: installed ntp package post-installation script subprocess returned error exit status 1
Checked and focal-fips and bionic-fips are not affected. Jammy is, as reported here. -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to ntp in Ubuntu. https://bugs.launchpad.net/bugs/2054609 Title: package ntp Jammy 1:4.2.8p15+dfsg-1ubuntu2 failed to install/upgrade: installed ntp package post-installation script subprocess returned error exit status 1 Status in ntp package in Ubuntu: Confirmed Bug description: ntp postinstall attempts to perform a MD5 sum, which is a no-no with FIPS. I have not encountered this bug on previous LTS versions of Ubuntu with FIPS. Description: Ubuntu 22.04.4 LTS Release: 22.04 ntp: Installed: 1:4.2.8p15+dfsg-1ubuntu2 Candidate: 1:4.2.8p15+dfsg-1ubuntu2 Version table: *** 1:4.2.8p15+dfsg-1ubuntu2 500 500 file:/home... 100 /var/libdpkg/status [Actions performed] I attempted to install ntp onto jammy 22.04.4 LTS with FIPS. $ sudo pro attach key-goes-here $ sudo pro enable fips-updates $ reboot --after reboot-- $ sudo apt update $ sudo apt install ntp [What you expected to happen] ntp tool installs prior to personal configuration, does not report anything in red [What happened instead] Job for ntp.service failed because the control process exited with error code. [...] Feb 21 15:53:32 user ntpd[35638]: MD5 init failed Feb 21 15:53:32 user ntpd[35632]: daemon child exited with code 1 --- ProblemType: Bug ApportVersion: 2.20.11-0ubuntu82.3 Architecture: amd64 CasperMD5CheckResult: pass CurrentDesktop: ubuntu:GNOME DistroRelease: Ubuntu 22.04 InstallationDate: Installed on 2024-02-25 (0 days ago) InstallationMedia: Ubuntu 22.04.2 LTS "Jammy Jellyfish" - Release amd64+intel-iot (20230316.2) NtpStatus: ntpq: read: Connection refused Package: ntp 1:4.2.8p15+dfsg-1ubuntu2 PackageArchitecture: amd64 ProcCmdline: BOOT_IMAGE=/boot/vmlinuz-5.15.0-97-fips root=UUID=f8b9334a-bf79-4a19-8e05-461a4c1a2e4c ro quiet splash fips=1 vt.handoff=7 ProcEnviron: TERM=xterm-256color PATH=(custom, no user) XDG_RUNTIME_DIR= LANG=en_US.UTF-8 SHELL=/bin/bash ProcVersionSignature: Ubuntu 5.15.0-97.107+fips1-fips 5.15.136 Tags: wayland-session jammy third-party-packages Uname: Linux 5.15.0-97-fips x86_64 UpgradeStatus: No upgrade log present (probably fresh install) UserGroups: adm cdrom dip lpadmin lxd plugdev sambashare sudo _MarkForUpload: True To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/ntp/+bug/2054609/+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 2053146] Re: openssh 8.9p1 for Jammy auth2-gss patch for gssapi-keyex method is slightly wrong
https://src.fedoraproject.org/rpms/openssh/c/c04e468b07b38471377fc7a648e1737021ea7148
--
You received this bug notification because you are a member of Ubuntu
Touch seeded packages, which is subscribed to openssh in Ubuntu.
https://bugs.launchpad.net/bugs/2053146
Title:
openssh 8.9p1 for Jammy auth2-gss patch for gssapi-keyex method is
slightly wrong
Status in openssh package in Ubuntu:
In Progress
Bug description:
The Authmethod struct now have 4 entries but the initialization of the
method_gsskeyex in the debian/patches/gssapi.patch only have 3
entries.
The struct was changed in upstream commit
dbb339f015c33d63484261d140c84ad875a9e548 as
===
@@ -104,7 +104,8 @@ struct Authctxt {
struct Authmethod {
char*name;
- int (*userauth)(struct ssh *);
+ char*synonym;
+ int (*userauth)(struct ssh *, const char *);
int *enabled;
};
===
The incorrect code does
===
+Authmethod method_gsskeyex = {
+ "gssapi-keyex",
+ userauth_gsskeyex,
+ &options.gss_authentication
+};
===
but should have a NULL between the "gssapi-keyex" string and userauth_gsskeyex
This is now (change from Focal) causing gssapi-keyex to be disabled.
===
lsb_release -rd
Description: Ubuntu 22.04.3 LTS
Release: 22.04
===
apt-cache policy openssh-server
openssh-server:
Installed: 1:8.9p1-3ubuntu0.6
Candidate: 1:8.9p1-3ubuntu0.6
Version table:
*** 1:8.9p1-3ubuntu0.6 500
500 http://faiserver.hpc2n.umu.se/mirrors/ubuntu/ubuntu
jammy-updates/main amd64 Packages
500 http://faiserver.hpc2n.umu.se/mirrors/ubuntu/ubuntu
jammy-security/main amd64 Packages
100 /var/lib/dpkg/status
1:8.9p1-3 500
500 http://faiserver.hpc2n.umu.se/mirrors/ubuntu/ubuntu jammy/main
amd64 Packages
===
To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/openssh/+bug/2053146/+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 2053146] Re: openssh 8.9p1 for Jammy auth2-gss patch for gssapi-keyex method is slightly wrong
** Also affects: openssh (Ubuntu Jammy)
Importance: Undecided
Status: New
** Also affects: openssh (Ubuntu Noble)
Importance: Critical
Assignee: Andreas Hasenack (ahasenack)
Status: In Progress
** Also affects: openssh (Ubuntu Mantic)
Importance: Undecided
Status: New
** Changed in: openssh (Ubuntu Mantic)
Status: New => In Progress
** Changed in: openssh (Ubuntu Jammy)
Status: New => In Progress
--
You received this bug notification because you are a member of Ubuntu
Touch seeded packages, which is subscribed to openssh in Ubuntu.
https://bugs.launchpad.net/bugs/2053146
Title:
openssh 8.9p1 for Jammy auth2-gss patch for gssapi-keyex method is
slightly wrong
Status in openssh package in Ubuntu:
In Progress
Status in openssh source package in Jammy:
In Progress
Status in openssh source package in Mantic:
In Progress
Status in openssh source package in Noble:
In Progress
Bug description:
The Authmethod struct now have 4 entries but the initialization of the
method_gsskeyex in the debian/patches/gssapi.patch only have 3
entries.
The struct was changed in upstream commit
dbb339f015c33d63484261d140c84ad875a9e548 as
===
@@ -104,7 +104,8 @@ struct Authctxt {
struct Authmethod {
char*name;
- int (*userauth)(struct ssh *);
+ char*synonym;
+ int (*userauth)(struct ssh *, const char *);
int *enabled;
};
===
The incorrect code does
===
+Authmethod method_gsskeyex = {
+ "gssapi-keyex",
+ userauth_gsskeyex,
+ &options.gss_authentication
+};
===
but should have a NULL between the "gssapi-keyex" string and userauth_gsskeyex
This is now (change from Focal) causing gssapi-keyex to be disabled.
===
lsb_release -rd
Description: Ubuntu 22.04.3 LTS
Release: 22.04
===
apt-cache policy openssh-server
openssh-server:
Installed: 1:8.9p1-3ubuntu0.6
Candidate: 1:8.9p1-3ubuntu0.6
Version table:
*** 1:8.9p1-3ubuntu0.6 500
500 http://faiserver.hpc2n.umu.se/mirrors/ubuntu/ubuntu
jammy-updates/main amd64 Packages
500 http://faiserver.hpc2n.umu.se/mirrors/ubuntu/ubuntu
jammy-security/main amd64 Packages
100 /var/lib/dpkg/status
1:8.9p1-3 500
500 http://faiserver.hpc2n.umu.se/mirrors/ubuntu/ubuntu jammy/main
amd64 Packages
===
To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/openssh/+bug/2053146/+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 2053146] Re: openssh 8.9p1 for Jammy auth2-gss patch for gssapi-keyex method is slightly wrong
Prepping builds, and I also want to add an autopkgtest for this.
--
You received this bug notification because you are a member of Ubuntu
Touch seeded packages, which is subscribed to openssh in Ubuntu.
https://bugs.launchpad.net/bugs/2053146
Title:
openssh 8.9p1 for Jammy auth2-gss patch for gssapi-keyex method is
slightly wrong
Status in openssh package in Ubuntu:
In Progress
Status in openssh source package in Jammy:
In Progress
Status in openssh source package in Mantic:
In Progress
Status in openssh source package in Noble:
In Progress
Bug description:
The Authmethod struct now have 4 entries but the initialization of the
method_gsskeyex in the debian/patches/gssapi.patch only have 3
entries.
The struct was changed in upstream commit
dbb339f015c33d63484261d140c84ad875a9e548 as
===
@@ -104,7 +104,8 @@ struct Authctxt {
struct Authmethod {
char*name;
- int (*userauth)(struct ssh *);
+ char*synonym;
+ int (*userauth)(struct ssh *, const char *);
int *enabled;
};
===
The incorrect code does
===
+Authmethod method_gsskeyex = {
+ "gssapi-keyex",
+ userauth_gsskeyex,
+ &options.gss_authentication
+};
===
but should have a NULL between the "gssapi-keyex" string and userauth_gsskeyex
This is now (change from Focal) causing gssapi-keyex to be disabled.
===
lsb_release -rd
Description: Ubuntu 22.04.3 LTS
Release: 22.04
===
apt-cache policy openssh-server
openssh-server:
Installed: 1:8.9p1-3ubuntu0.6
Candidate: 1:8.9p1-3ubuntu0.6
Version table:
*** 1:8.9p1-3ubuntu0.6 500
500 http://faiserver.hpc2n.umu.se/mirrors/ubuntu/ubuntu
jammy-updates/main amd64 Packages
500 http://faiserver.hpc2n.umu.se/mirrors/ubuntu/ubuntu
jammy-security/main amd64 Packages
100 /var/lib/dpkg/status
1:8.9p1-3 500
500 http://faiserver.hpc2n.umu.se/mirrors/ubuntu/ubuntu jammy/main
amd64 Packages
===
To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/openssh/+bug/2053146/+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 2053146] Re: openssh 8.9p1 for Jammy auth2-gss patch for gssapi-keyex method is slightly wrong
I have an autopkgtest for gssapi, adding one now for keyex.
--
You received this bug notification because you are a member of Ubuntu
Touch seeded packages, which is subscribed to openssh in Ubuntu.
https://bugs.launchpad.net/bugs/2053146
Title:
openssh 8.9p1 for Jammy auth2-gss patch for gssapi-keyex method is
slightly wrong
Status in openssh package in Ubuntu:
In Progress
Status in openssh source package in Jammy:
In Progress
Status in openssh source package in Mantic:
In Progress
Status in openssh source package in Noble:
In Progress
Bug description:
The Authmethod struct now have 4 entries but the initialization of the
method_gsskeyex in the debian/patches/gssapi.patch only have 3
entries.
The struct was changed in upstream commit
dbb339f015c33d63484261d140c84ad875a9e548 as
===
@@ -104,7 +104,8 @@ struct Authctxt {
struct Authmethod {
char*name;
- int (*userauth)(struct ssh *);
+ char*synonym;
+ int (*userauth)(struct ssh *, const char *);
int *enabled;
};
===
The incorrect code does
===
+Authmethod method_gsskeyex = {
+ "gssapi-keyex",
+ userauth_gsskeyex,
+ &options.gss_authentication
+};
===
but should have a NULL between the "gssapi-keyex" string and userauth_gsskeyex
This is now (change from Focal) causing gssapi-keyex to be disabled.
===
lsb_release -rd
Description: Ubuntu 22.04.3 LTS
Release: 22.04
===
apt-cache policy openssh-server
openssh-server:
Installed: 1:8.9p1-3ubuntu0.6
Candidate: 1:8.9p1-3ubuntu0.6
Version table:
*** 1:8.9p1-3ubuntu0.6 500
500 http://faiserver.hpc2n.umu.se/mirrors/ubuntu/ubuntu
jammy-updates/main amd64 Packages
500 http://faiserver.hpc2n.umu.se/mirrors/ubuntu/ubuntu
jammy-security/main amd64 Packages
100 /var/lib/dpkg/status
1:8.9p1-3 500
500 http://faiserver.hpc2n.umu.se/mirrors/ubuntu/ubuntu jammy/main
amd64 Packages
===
To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/openssh/+bug/2053146/+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 2053146] Re: openssh 8.9p1 for Jammy auth2-gss patch for gssapi-keyex method is slightly wrong
Quick test with
https://launchpad.net/~ahasenack/+archive/ubuntu/openssh-
gsskeyex-2053146/+packages on jammy (but there are builds for other
releases too), seems to work:
Mar 13 20:52:58 j-keyex sshd[1638]: Authorized to ubuntu, krb5 principal
andreas@LOWTECH (krb5_kuserok)
Mar 13 20:52:58 j-keyex sshd[1638]: Accepted gssapi-keyex for ubuntu from
10.0.102.1 port 48450 ssh2: andreas@LOWTECH
--
You received this bug notification because you are a member of Ubuntu
Touch seeded packages, which is subscribed to openssh in Ubuntu.
https://bugs.launchpad.net/bugs/2053146
Title:
openssh 8.9p1 for Jammy auth2-gss patch for gssapi-keyex method is
slightly wrong
Status in openssh package in Ubuntu:
In Progress
Status in openssh source package in Jammy:
In Progress
Status in openssh source package in Mantic:
In Progress
Status in openssh source package in Noble:
In Progress
Bug description:
The Authmethod struct now have 4 entries but the initialization of the
method_gsskeyex in the debian/patches/gssapi.patch only have 3
entries.
The struct was changed in upstream commit
dbb339f015c33d63484261d140c84ad875a9e548 as
===
@@ -104,7 +104,8 @@ struct Authctxt {
struct Authmethod {
char*name;
- int (*userauth)(struct ssh *);
+ char*synonym;
+ int (*userauth)(struct ssh *, const char *);
int *enabled;
};
===
The incorrect code does
===
+Authmethod method_gsskeyex = {
+ "gssapi-keyex",
+ userauth_gsskeyex,
+ &options.gss_authentication
+};
===
but should have a NULL between the "gssapi-keyex" string and userauth_gsskeyex
This is now (change from Focal) causing gssapi-keyex to be disabled.
===
lsb_release -rd
Description: Ubuntu 22.04.3 LTS
Release: 22.04
===
apt-cache policy openssh-server
openssh-server:
Installed: 1:8.9p1-3ubuntu0.6
Candidate: 1:8.9p1-3ubuntu0.6
Version table:
*** 1:8.9p1-3ubuntu0.6 500
500 http://faiserver.hpc2n.umu.se/mirrors/ubuntu/ubuntu
jammy-updates/main amd64 Packages
500 http://faiserver.hpc2n.umu.se/mirrors/ubuntu/ubuntu
jammy-security/main amd64 Packages
100 /var/lib/dpkg/status
1:8.9p1-3 500
500 http://faiserver.hpc2n.umu.se/mirrors/ubuntu/ubuntu jammy/main
amd64 Packages
===
To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/openssh/+bug/2053146/+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 2053146] Re: openssh 8.9p1 for Jammy auth2-gss patch for gssapi-keyex method is slightly wrong
I think you missed the extra arg to userauth_gsskeyex()
--
You received this bug notification because you are a member of Ubuntu
Touch seeded packages, which is subscribed to openssh in Ubuntu.
https://bugs.launchpad.net/bugs/2053146
Title:
openssh 8.9p1 for Jammy auth2-gss patch for gssapi-keyex method is
slightly wrong
Status in openssh package in Ubuntu:
In Progress
Status in openssh source package in Jammy:
In Progress
Status in openssh source package in Mantic:
In Progress
Status in openssh source package in Noble:
In Progress
Bug description:
The Authmethod struct now have 4 entries but the initialization of the
method_gsskeyex in the debian/patches/gssapi.patch only have 3
entries.
The struct was changed in upstream commit
dbb339f015c33d63484261d140c84ad875a9e548 as
===
@@ -104,7 +104,8 @@ struct Authctxt {
struct Authmethod {
char*name;
- int (*userauth)(struct ssh *);
+ char*synonym;
+ int (*userauth)(struct ssh *, const char *);
int *enabled;
};
===
The incorrect code does
===
+Authmethod method_gsskeyex = {
+ "gssapi-keyex",
+ userauth_gsskeyex,
+ &options.gss_authentication
+};
===
but should have a NULL between the "gssapi-keyex" string and userauth_gsskeyex
This is now (change from Focal) causing gssapi-keyex to be disabled.
===
lsb_release -rd
Description: Ubuntu 22.04.3 LTS
Release: 22.04
===
apt-cache policy openssh-server
openssh-server:
Installed: 1:8.9p1-3ubuntu0.6
Candidate: 1:8.9p1-3ubuntu0.6
Version table:
*** 1:8.9p1-3ubuntu0.6 500
500 http://faiserver.hpc2n.umu.se/mirrors/ubuntu/ubuntu
jammy-updates/main amd64 Packages
500 http://faiserver.hpc2n.umu.se/mirrors/ubuntu/ubuntu
jammy-security/main amd64 Packages
100 /var/lib/dpkg/status
1:8.9p1-3 500
500 http://faiserver.hpc2n.umu.se/mirrors/ubuntu/ubuntu jammy/main
amd64 Packages
===
To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/openssh/+bug/2053146/+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 2040465] Update Released
The verification of the Stable Release Update for openldap has completed successfully and the package is now being released to -updates. Subsequently, the Ubuntu Stable Release Updates Team is being unsubscribed and will not receive messages about this bug report. In the event that you encounter a regression using the package from -updates please report a new bug using ubuntu-bug and tag the bug report regression-update so we can easily find any regressions. -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to openldap in Ubuntu. https://bugs.launchpad.net/bugs/2040465 Title: New upstream microrelease 2.5.17 Status in openldap package in Ubuntu: Invalid Status in openldap source package in Jammy: Fix Released Bug description: [ Impact ] * MRE for the latest stable OpenLDAP 2.5.x release, 2.5.17. This update includes bugfixes only following the SRU policy exception defined at https://wiki.ubuntu.com/OpenLDAPUpdates. [ Major Changes ] * See the list of bugs fixed in this release here: https://lists.openldap.org/hyperkitty/list/openldap- annou...@openldap.org/thread/XRQE4CVQDLTG4EYPKVEU2L76DYGIFR2Q/ [ Test Plan ] * Upstream gitlab pipeline results: https://git.openldap.org/openldap/openldap/-/commit/99a124bb434052a71cf4ff115d0f949f6c6b7208/pipelines?ref=OPENLDAP_REL_ENG_2_5 * Upstream "call for testing": https://lists.openldap.org/hyperkitty/list/openldap- techni...@openldap.org/thread/4744NWC2HJP7L24WOUMZF4VCYGGUMRI7/ * As described in the MRE wiki page for OpenLDAP, the test plan is to build the package in a PPA and make sure that (1) all build-time tests pass and (2) all autopkgtest runs (from reverse dependencies) also pass. * Build log (amd64) confirming that the build-time testsuite has been performed and completed successfully: - https://launchpadlibrarian.net/679769800/buildlog_ubuntu-jammy-amd64.openldap_2.5.16+dfsg-0ubuntu0.22.04.1~ppa1_BUILDING.txt.gz [ Where problems could occur ] * Upstream tests are always executed during build-time. There are many reverse dependencies whose dep8 tests depend on OpenLDAP so the coverage is good. Nevertheless, there is always a risk for something to break since we are dealing with a microrelease upgrade. Whenever a test failure is detected, we will be on top of it and make sure it doesn't affect existing users. [ Other Info ] * This is a reoccurring MRE. See below for links to previous OpenLDAP MREs. * CVEs fixed by this release: - None. Current versions in supported releases that got updates: openldap | 2.5.16+dfsg-0ubuntu0.22.04.2 | jammy-security | source Special cases: - None. Previous MREs for OpenLDAP: - https://pad.lv/1977627 - https://pad.lv/1983618 - https://pad.lv/2007625 - https://pad.lv/2027079 - https://pad.lv/2029170 As usual we test and prep from the PPA and then push through SRU/Security as applicable. To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/openldap/+bug/2040465/+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 2002043] Update Released
The verification of the Stable Release Update for python2.7 has completed successfully and the package is now being released to -updates. Subsequently, the Ubuntu Stable Release Updates Team is being unsubscribed and will not receive messages about this bug report. In the event that you encounter a regression using the package from -updates please report a new bug using ubuntu-bug and tag the bug report regression-update so we can easily find any regressions. -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to python2.7 in Ubuntu. https://bugs.launchpad.net/bugs/2002043 Title: Python extension modules get built using wrong compiler flags with python2 Status in python2.7 package in Ubuntu: Invalid Status in python2.7 source package in Bionic: Won't Fix Status in python2.7 source package in Focal: Fix Released Status in python2.7 source package in Jammy: Fix Released Status in python2.7 source package in Kinetic: Invalid Status in python2.7 source package in Lunar: Invalid Status in python2.7 source package in Mantic: Invalid Bug description: [ Impact ] When compiling Python extensions using Python2, CFLAGS optimization flags are dropped. This behavior has been caused by our update in this patch http://archive.ubuntu.com/ubuntu/pool/universe/p/python2.7/python2.7_2.7.18-1~20.04.3.diff.gz which differs from upstream. The fix modifies the portion of code in Lib/distutils/sysconfig.py which gets the cflags from the environments, and includes the dropped OPT flag from get_config_vars(). [ Test Plan ] There will be 2 separate tests for this bug: * Ensuring no-change rebuilds are not changed * Ensuring local builds are not changed unless environment variable is set Test 1) No-change rebuilds To test that no-change rebuilds are not changed, the package python- stdlib-extensions will be built against the new python2.7, and confirm the compiler flags are not altered. This will be a manual test and visual inspection of the build logs. Test 2) Functional test 1. Create test container $ lxc launch ubuntu:jammy jammy-2002043 $ lxc shell jammy-2002043 2. Install required packages For Jammy # apt update -y && apt install -y python2 python-pip For Focal # apt update -y && apt install -y python2 python-setuptools gcc 3. Create test files # mkdir testprog # cd testprog # cat >setup.py
[Touch-packages] [Bug 2029473] Re: Backport Ubuntu Pro to Xenial
Version 0.96.20.10 passed in xenial/amd64 about 10 days ago (via an ubuntu-advantage-tools update), but version 0.96.20.12 failed a few days before. I triggered another run just in case. If that new run also fails, then something is going on, and it has to be sorted out before this update can be released. -- 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/2029473 Title: Backport Ubuntu Pro to Xenial Status in software-properties package in Ubuntu: Fix Released Status in software-properties source package in Xenial: Fix Committed Bug description: * Impact We want desktop integration with Ubuntu Pro * Test case - ensure that the machine isn't attached to ubuntu pro (otherwise the screen would not be displayed) and is online $ pro status and `$ pro detach` if needed - $ software-properties-gtk -> the list of tabs should include an 'Ubuntu Pro' one The Ubuntu Pro tab should state 'This machine is not covered by an Ubuntu Pro subscription', display a 'Enable Ubuntu Pro' button and have other controls inactive - click 'Enable Ubuntu Pro' -> A dialog 'Enable Ubuntu Pro' opens -> the first option 'Enter code on ubuntu.com/pro/attach' is selected -> a pincode is displayed under the option - go to http//ubuntu.com/pro/attach and enter the pincode -> after some seconds the software-properties UI should update and display a green mark and 'Valid token' label on the right of the pincode - click 'Confirm' -> you should get an authentification prompt - enter your password -> a spinner starts animating instead of the 'Valid token' label -> once the attachment job is done the dialog is autoclosed -> the UI should now state 'Ubuntu Pro support is enabled', under Security 'ESM Infra', 'ESM Apps' and 'Kernel Livepatch' should be displayed an enabled (or without 'ESM Apps' if you don't have the current ubuntu-advantage-tools) - check that the '$ pro status' output matches the UI one - try enabling/disable options -> verify that the 'pro status' change accordingly - Click 'Disable Ubuntu Pro' -> you get asked for confirmation and password -> confirm that the UI is back to the original state and that 'pro status' confirm the system isn't attached to Ubuntu Pro anymore - Go through the testcase again but selecting the 'Or add token manually' option, the steps should be similar * Regression Potential There could be problems in the UI The new service could be not working as expected Strings are new and currently have no translations The livepatch checkbox is also inactive because the current update- notifier version in xenial doesn't include livepatch support - Ubuntu Pro enables extended support for 10 years for long term support Ubuntu series. Xenial is therefore currently also supported under Ubuntu Pro. Xenial's software-properties-gtk, however, doesn't have the Ubuntu Pro functionality that exists in Bionic, Focal etc. Thus this request to backport the Ubuntu Pro functionality to Xenial. This depends on LP:2029089. To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/software-properties/+bug/2029473/+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 2029473] Re: Backport Ubuntu Pro to Xenial
Queued where? I don't see it in xenial unapproved. If it's just fixing the autopkgtests, not the software-properties code or anything else in debian/*, then no need for a new SRU bug. Just make sure to build it with the appropriate -v parameter to include all changes since 0.96.20.10 (IIRC). -- 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/2029473 Title: Backport Ubuntu Pro to Xenial Status in software-properties package in Ubuntu: Fix Released Status in software-properties source package in Xenial: Fix Committed Bug description: * Impact We want desktop integration with Ubuntu Pro * Test case - ensure that the machine isn't attached to ubuntu pro (otherwise the screen would not be displayed) and is online $ pro status and `$ pro detach` if needed - $ software-properties-gtk -> the list of tabs should include an 'Ubuntu Pro' one The Ubuntu Pro tab should state 'This machine is not covered by an Ubuntu Pro subscription', display a 'Enable Ubuntu Pro' button and have other controls inactive - click 'Enable Ubuntu Pro' -> A dialog 'Enable Ubuntu Pro' opens -> the first option 'Enter code on ubuntu.com/pro/attach' is selected -> a pincode is displayed under the option - go to http//ubuntu.com/pro/attach and enter the pincode -> after some seconds the software-properties UI should update and display a green mark and 'Valid token' label on the right of the pincode - click 'Confirm' -> you should get an authentification prompt - enter your password -> a spinner starts animating instead of the 'Valid token' label -> once the attachment job is done the dialog is autoclosed -> the UI should now state 'Ubuntu Pro support is enabled', under Security 'ESM Infra', 'ESM Apps' and 'Kernel Livepatch' should be displayed an enabled (or without 'ESM Apps' if you don't have the current ubuntu-advantage-tools) - check that the '$ pro status' output matches the UI one - try enabling/disable options -> verify that the 'pro status' change accordingly - Click 'Disable Ubuntu Pro' -> you get asked for confirmation and password -> confirm that the UI is back to the original state and that 'pro status' confirm the system isn't attached to Ubuntu Pro anymore - Go through the testcase again but selecting the 'Or add token manually' option, the steps should be similar * Regression Potential There could be problems in the UI The new service could be not working as expected Strings are new and currently have no translations The livepatch checkbox is also inactive because the current update- notifier version in xenial doesn't include livepatch support - Ubuntu Pro enables extended support for 10 years for long term support Ubuntu series. Xenial is therefore currently also supported under Ubuntu Pro. Xenial's software-properties-gtk, however, doesn't have the Ubuntu Pro functionality that exists in Bionic, Focal etc. Thus this request to backport the Ubuntu Pro functionality to Xenial. This depends on LP:2029089. To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/software-properties/+bug/2029473/+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 2029473] Re: Backport Ubuntu Pro to Xenial
Ah, software-properties, sorry, I still had update-manager in my mind. -- 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/2029473 Title: Backport Ubuntu Pro to Xenial Status in software-properties package in Ubuntu: Fix Released Status in software-properties source package in Xenial: Fix Committed Bug description: * Impact We want desktop integration with Ubuntu Pro * Test case - ensure that the machine isn't attached to ubuntu pro (otherwise the screen would not be displayed) and is online $ pro status and `$ pro detach` if needed - $ software-properties-gtk -> the list of tabs should include an 'Ubuntu Pro' one The Ubuntu Pro tab should state 'This machine is not covered by an Ubuntu Pro subscription', display a 'Enable Ubuntu Pro' button and have other controls inactive - click 'Enable Ubuntu Pro' -> A dialog 'Enable Ubuntu Pro' opens -> the first option 'Enter code on ubuntu.com/pro/attach' is selected -> a pincode is displayed under the option - go to http//ubuntu.com/pro/attach and enter the pincode -> after some seconds the software-properties UI should update and display a green mark and 'Valid token' label on the right of the pincode - click 'Confirm' -> you should get an authentification prompt - enter your password -> a spinner starts animating instead of the 'Valid token' label -> once the attachment job is done the dialog is autoclosed -> the UI should now state 'Ubuntu Pro support is enabled', under Security 'ESM Infra', 'ESM Apps' and 'Kernel Livepatch' should be displayed an enabled (or without 'ESM Apps' if you don't have the current ubuntu-advantage-tools) - check that the '$ pro status' output matches the UI one - try enabling/disable options -> verify that the 'pro status' change accordingly - Click 'Disable Ubuntu Pro' -> you get asked for confirmation and password -> confirm that the UI is back to the original state and that 'pro status' confirm the system isn't attached to Ubuntu Pro anymore - Go through the testcase again but selecting the 'Or add token manually' option, the steps should be similar * Regression Potential There could be problems in the UI The new service could be not working as expected Strings are new and currently have no translations The livepatch checkbox is also inactive because the current update- notifier version in xenial doesn't include livepatch support - Ubuntu Pro enables extended support for 10 years for long term support Ubuntu series. Xenial is therefore currently also supported under Ubuntu Pro. Xenial's software-properties-gtk, however, doesn't have the Ubuntu Pro functionality that exists in Bionic, Focal etc. Thus this request to backport the Ubuntu Pro functionality to Xenial. This depends on LP:2029089. To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/software-properties/+bug/2029473/+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 2029473] Re: Backport Ubuntu Pro to Xenial
I just looked at the changes, and I would prefer to have a new SRU bug for those, yes please. -- 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/2029473 Title: Backport Ubuntu Pro to Xenial Status in software-properties package in Ubuntu: Fix Released Status in software-properties source package in Xenial: Fix Committed Bug description: * Impact We want desktop integration with Ubuntu Pro * Test case - ensure that the machine isn't attached to ubuntu pro (otherwise the screen would not be displayed) and is online $ pro status and `$ pro detach` if needed - $ software-properties-gtk -> the list of tabs should include an 'Ubuntu Pro' one The Ubuntu Pro tab should state 'This machine is not covered by an Ubuntu Pro subscription', display a 'Enable Ubuntu Pro' button and have other controls inactive - click 'Enable Ubuntu Pro' -> A dialog 'Enable Ubuntu Pro' opens -> the first option 'Enter code on ubuntu.com/pro/attach' is selected -> a pincode is displayed under the option - go to http//ubuntu.com/pro/attach and enter the pincode -> after some seconds the software-properties UI should update and display a green mark and 'Valid token' label on the right of the pincode - click 'Confirm' -> you should get an authentification prompt - enter your password -> a spinner starts animating instead of the 'Valid token' label -> once the attachment job is done the dialog is autoclosed -> the UI should now state 'Ubuntu Pro support is enabled', under Security 'ESM Infra', 'ESM Apps' and 'Kernel Livepatch' should be displayed an enabled (or without 'ESM Apps' if you don't have the current ubuntu-advantage-tools) - check that the '$ pro status' output matches the UI one - try enabling/disable options -> verify that the 'pro status' change accordingly - Click 'Disable Ubuntu Pro' -> you get asked for confirmation and password -> confirm that the UI is back to the original state and that 'pro status' confirm the system isn't attached to Ubuntu Pro anymore - Go through the testcase again but selecting the 'Or add token manually' option, the steps should be similar * Regression Potential There could be problems in the UI The new service could be not working as expected Strings are new and currently have no translations The livepatch checkbox is also inactive because the current update- notifier version in xenial doesn't include livepatch support - Ubuntu Pro enables extended support for 10 years for long term support Ubuntu series. Xenial is therefore currently also supported under Ubuntu Pro. Xenial's software-properties-gtk, however, doesn't have the Ubuntu Pro functionality that exists in Bionic, Focal etc. Thus this request to backport the Ubuntu Pro functionality to Xenial. This depends on LP:2029089. To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/software-properties/+bug/2029473/+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 2053146] Re: openssh 8.9p1 for Jammy auth2-gss patch for gssapi-keyex method is slightly wrong
** Description changed:
- The Authmethod struct now have 4 entries but the initialization of the
- method_gsskeyex in the debian/patches/gssapi.patch only have 3 entries.
+ [ Impact ]
+
+ * An explanation of the effects of the bug on users and
+
+ * justification for backporting the fix to the stable release.
+
+ * In addition, it is helpful, but not required, to include an
+explanation of how the upload fixes this bug.
+
+ [ 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
+
+
+ [ Original Description ]
+
+
+ The Authmethod struct now have 4 entries but the initialization of the
method_gsskeyex in the debian/patches/gssapi.patch only have 3 entries.
The struct was changed in upstream commit
dbb339f015c33d63484261d140c84ad875a9e548 as
===
@@ -104,7 +104,8 @@ struct Authctxt {
-
- struct Authmethod {
- char*name;
+
+ struct Authmethod {
+ char*name;
- int (*userauth)(struct ssh *);
+ char*synonym;
+ int (*userauth)(struct ssh *, const char *);
- int *enabled;
- };
+ int *enabled;
+ };
===
The incorrect code does
===
+Authmethod method_gsskeyex = {
+ "gssapi-keyex",
+ userauth_gsskeyex,
+ &options.gss_authentication
+};
===
but should have a NULL between the "gssapi-keyex" string and userauth_gsskeyex
-
This is now (change from Focal) causing gssapi-keyex to be disabled.
-
===
lsb_release -rd
Description: Ubuntu 22.04.3 LTS
Release: 22.04
===
apt-cache policy openssh-server
openssh-server:
- Installed: 1:8.9p1-3ubuntu0.6
- Candidate: 1:8.9p1-3ubuntu0.6
- Version table:
- *** 1:8.9p1-3ubuntu0.6 500
- 500 http://faiserver.hpc2n.umu.se/mirrors/ubuntu/ubuntu
jammy-updates/main amd64 Packages
- 500 http://faiserver.hpc2n.umu.se/mirrors/ubuntu/ubuntu
jammy-security/main amd64 Packages
- 100 /var/lib/dpkg/status
- 1:8.9p1-3 500
- 500 http://faiserver.hpc2n.umu.se/mirrors/ubuntu/ubuntu jammy/main
amd64 Packages
+ Installed: 1:8.9p1-3ubuntu0.6
+ Candidate: 1:8.9p1-3ubuntu0.6
+ Version table:
+ *** 1:8.9p1-3ubuntu0.6 500
+ 500 http://faiserver.hpc2n.umu.se/mirrors/ubuntu/ubuntu
jammy-updates/main amd64 Packages
+ 500 http://faiserver.hpc2n.umu.se/mirrors/ubuntu/ubuntu
jammy-security/main amd64 Packages
+ 100 /var/lib/dpkg/status
+ 1:8.9p1-3 500
+ 500 http://faiserver.hpc2n.umu.se/mirrors/ubuntu/ubuntu jammy/main
amd64 Packages
===
--
You received this bug notification because you are a member of Ubuntu
Touch seeded packages, which is subscribed to openssh in Ubuntu.
https://bugs.launchpad.net/bugs/2053146
Title:
openssh 8.9p1 for Jammy auth2-gss patch for gssapi-keyex method is
slightly wrong
Status in openssh package in Ubuntu:
In Progress
Status in openssh source package in Jammy:
In Progress
Status in openssh source package in Mantic:
In Progress
Status in openssh source package in Noble:
In Progress
Bug description:
[ Impact ]
The gssapi-keyex authentication mechanism has been inadvertently
broken in openssh. It comes from a distro patch[1], and while the
patch still applied, it was no longer correct.
Without the fix, sshd will fail to start if gssapi-keyex is listed in
the AuthenticationMethods of the server, and if not, sshd will still
start, but gssapi-keyex will not be available.
[ Test Plan ]
This update adds a new autopkgtest to the package, which tests both
gssapi-with-mic ("normal" gssapi, which is not affected by this bug),
and gssapi-keyex, which, before this update, does not work.
The test plan is to run the new ssh-gssapi autopkgtest and verify it
succeeds.
[ Where problems could
[Touch-packages] [Bug 2053146] Re: openssh 8.9p1 for Jammy auth2-gss patch for gssapi-keyex method is slightly wrong
** Description changed:
[ Impact ]
- * An explanation of the effects of the bug on users and
+ The gssapi-keyex authentication mechanism has been inadvertently broken
+ in openssh. It comes from a distro patch[1], and while the patch still
+ applied, it was no longer correct.
- * justification for backporting the fix to the stable release.
+ Without the fix, sshd will fail to start if gssapi-keyex is listed in
+ the AuthenticationMethods of the server, and if not, sshd will still
+ start, but gssapi-keyex will not be available.
- * In addition, it is helpful, but not required, to include an
-explanation of how the upload fixes this bug.
[ Test Plan ]
- * detailed instructions how to reproduce the bug
+ This update adds a new autopkgtest to the package, which tests both
+ gssapi-with-mic ("normal" gssapi, which is not affected by this bug),
+ and gssapi-keyex, which, before this update, does not work.
- * 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.
+ The test plan is to run the new ssh-gssapi autopkgtest and verify it
+ succeeds.
- * 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?
+ ssh is a critical piece of infrastructure, and problems with it could
+ have catastrophic consequences. The service itself has a test command
+ before it starts up to verify the syntax of the config file, but that
+ test is not applied on shutdown, so a restart with an invalid config
+ file could still leave sshd dead.
- * 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.
+ The patch adds a change to an authentication structure, but that change
+ is already present in the upstream code, and we are just updating it in
+ the new gssapi-keyex code (introduced by the distro[1] patch, already
+ present). Therefore, mistakes here should manifest themselves just in
+ the gssapi-keyex code, which wasn't working anyway. Effectively, though,
+ we are enabling a new authentication mechanism in sshd, one that was not
+ supposed to have been removed, but was broken by mistake.
- * 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
+ The fact no-one noticed this problem for more than two years could be
+ telling that there are not many users of this authentication mechanism
+ out there. The same applies to debian: it has also been broken for a
+ while there. Maybe we should drop it for future ubuntu releases, since
+ upstream refuses to take it in.
[ Original Description ]
-
- The Authmethod struct now have 4 entries but the initialization of the
method_gsskeyex in the debian/patches/gssapi.patch only have 3 entries.
+ The Authmethod struct now have 4 entries but the initialization of the
+ method_gsskeyex in the debian/patches/gssapi.patch only have 3 entries.
The struct was changed in upstream commit
dbb339f015c33d63484261d140c84ad875a9e548 as
===
@@ -104,7 +104,8 @@ struct Authctxt {
struct Authmethod {
char*name;
- int (*userauth)(struct ssh *);
+ char*synonym;
+ int (*userauth)(struct ssh *, const char *);
int *enabled;
};
===
The incorrect code does
===
+Authmethod method_gsskeyex = {
+ "gssapi-keyex",
+ userauth_gsskeyex,
+ &options.gss_authentication
+};
===
but should have a NULL between the "gssapi-keyex" string and userauth_gsskeyex
This is now (change from Focal) causing gssapi-keyex to be disabled.
===
lsb_release -rd
Description: Ubuntu 22.04.3 LTS
Release: 22.04
===
apt-cache policy openssh-server
openssh-server:
Installed: 1:8.9p1-3ubuntu0.6
Candidate: 1:8.9p1-3ubuntu0.6
Version table:
*** 1:8.9p1-3ubuntu0.6 500
500 http://faiserver.hpc2n.umu.se/mirrors/ubuntu/ubuntu
jammy-updates/main amd64 Packages
500 http://faiserver.hpc2n.umu.se/mirrors/ubuntu/ubuntu
jammy-security/main amd64 Packages
100 /var/lib/dpkg/status
1:8.9p1-3 500
500 http://faiserver.hpc2n.umu.se/mirrors/ubuntu/ubuntu jammy/main
amd64 Packages
[Touch-packages] [Bug 2053146] Re: openssh 8.9p1 for Jammy auth2-gss patch for gssapi-keyex method is slightly wrong
** Changed in: openssh (Ubuntu Noble)
Importance: Critical => High
** Changed in: openssh (Ubuntu Mantic)
Importance: Undecided => High
** Changed in: openssh (Ubuntu Jammy)
Importance: Undecided => High
** Changed in: openssh (Ubuntu Jammy)
Assignee: (unassigned) => Andreas Hasenack (ahasenack)
** Changed in: openssh (Ubuntu Mantic)
Assignee: (unassigned) => Andreas Hasenack (ahasenack)
--
You received this bug notification because you are a member of Ubuntu
Touch seeded packages, which is subscribed to openssh in Ubuntu.
https://bugs.launchpad.net/bugs/2053146
Title:
openssh 8.9p1 for Jammy auth2-gss patch for gssapi-keyex method is
slightly wrong
Status in openssh package in Ubuntu:
In Progress
Status in openssh source package in Jammy:
In Progress
Status in openssh source package in Mantic:
In Progress
Status in openssh source package in Noble:
In Progress
Bug description:
[ Impact ]
The gssapi-keyex authentication mechanism has been inadvertently
broken in openssh. It comes from a distro patch[1], and while the
patch still applied, it was no longer correct.
Without the fix, sshd will fail to start if gssapi-keyex is listed in
the AuthenticationMethods of the server, and if not, sshd will still
start, but gssapi-keyex will not be available.
[ Test Plan ]
This update adds a new autopkgtest to the package, which tests both
gssapi-with-mic ("normal" gssapi, which is not affected by this bug),
and gssapi-keyex, which, before this update, does not work.
The test plan is to run the new ssh-gssapi autopkgtest and verify it
succeeds.
[ Where problems could occur ]
ssh is a critical piece of infrastructure, and problems with it could
have catastrophic consequences. The service itself has a test command
before it starts up to verify the syntax of the config file, but that
test is not applied on shutdown, so a restart with an invalid config
file could still leave sshd dead.
The patch adds a change to an authentication structure, but that
change is already present in the upstream code, and we are just
updating it in the new gssapi-keyex code (introduced by the distro[1]
patch, already present). Therefore, mistakes here should manifest
themselves just in the gssapi-keyex code, which wasn't working anyway.
Effectively, though, we are enabling a new authentication mechanism in
sshd, one that was not supposed to have been removed, but was broken
by mistake.
[ Other Info ]
The fact no-one noticed this problem for more than two years could be
telling that there are not many users of this authentication mechanism
out there. The same applies to debian: it has also been broken for a
while there. Maybe we should drop it for future ubuntu releases, since
upstream refuses to take it in.
[ Original Description ]
The Authmethod struct now have 4 entries but the initialization of the
method_gsskeyex in the debian/patches/gssapi.patch only have 3
entries.
The struct was changed in upstream commit
dbb339f015c33d63484261d140c84ad875a9e548 as
===
@@ -104,7 +104,8 @@ struct Authctxt {
struct Authmethod {
char*name;
- int (*userauth)(struct ssh *);
+ char*synonym;
+ int (*userauth)(struct ssh *, const char *);
int *enabled;
};
===
The incorrect code does
===
+Authmethod method_gsskeyex = {
+ "gssapi-keyex",
+ userauth_gsskeyex,
+ &options.gss_authentication
+};
===
but should have a NULL between the "gssapi-keyex" string and userauth_gsskeyex
This is now (change from Focal) causing gssapi-keyex to be disabled.
===
lsb_release -rd
Description: Ubuntu 22.04.3 LTS
Release: 22.04
===
apt-cache policy openssh-server
openssh-server:
Installed: 1:8.9p1-3ubuntu0.6
Candidate: 1:8.9p1-3ubuntu0.6
Version table:
*** 1:8.9p1-3ubuntu0.6 500
500 http://faiserver.hpc2n.umu.se/mirrors/ubuntu/ubuntu
jammy-updates/main amd64 Packages
500 http://faiserver.hpc2n.umu.se/mirrors/ubuntu/ubuntu
jammy-security/main amd64 Packages
100 /var/lib/dpkg/status
1:8.9p1-3 500
500 http://faiserver.hpc2n.umu.se/mirrors/ubuntu/ubuntu jammy/main
amd64 Packages
===
To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/openssh/+bug/2053146/+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 2058276] [NEW] Improve ssh-gssapi DEP8 test
Public bug reported:
The DEP8 test introduced in
https://bugs.launchpad.net/ubuntu/+source/openssh/+bug/2053146 could
still show s PASS even when the login didn't work. This is because it's
relying on `set -e` to work inside functions, but that's not the case.
For example, here I forced a failure by using an invalid user (I added "x" to
the username):
```
## ssh'ing into localhost using gssapi-keyex auth
testuser229...@sshd-gssapi.example.fake: Permission denied (gssapi-keyex).
## checking that we got a service ticket for ssh (host/)
03/18/24 12:16:55 03/18/24 22:16:55 host/sshd-gssapi.example.fake@
Ticket server: host/sshd-gssapi.example.f...@example.fake
## Checking ssh logs to confirm gssapi-keyex auth was used
Mar 18 12:16:55 sshd-gssapi.example.fake sshd[22994]: Failed gssapi-keyex for
invalid user testuser22924x from 127.0.0.1 port 39550 ssh2:
testuser22...@example.fake
## PASS test_gssapi_keyex_login
```
Furthermore, the --grep option used in journalctl is not specific
enough, as can also be seen above. It's just looking for the
authentication method name, not whether is succeeded or not.
** Affects: openssh (Ubuntu)
Importance: High
Assignee: Andreas Hasenack (ahasenack)
Status: In Progress
--
You received this bug notification because you are a member of Ubuntu
Touch seeded packages, which is subscribed to openssh in Ubuntu.
https://bugs.launchpad.net/bugs/2058276
Title:
Improve ssh-gssapi DEP8 test
Status in openssh package in Ubuntu:
In Progress
Bug description:
The DEP8 test introduced in
https://bugs.launchpad.net/ubuntu/+source/openssh/+bug/2053146 could
still show s PASS even when the login didn't work. This is because
it's relying on `set -e` to work inside functions, but that's not the
case.
For example, here I forced a failure by using an invalid user (I added "x" to
the username):
```
## ssh'ing into localhost using gssapi-keyex auth
testuser229...@sshd-gssapi.example.fake: Permission denied (gssapi-keyex).
## checking that we got a service ticket for ssh (host/)
03/18/24 12:16:55 03/18/24 22:16:55 host/sshd-gssapi.example.fake@
Ticket server: host/sshd-gssapi.example.f...@example.fake
## Checking ssh logs to confirm gssapi-keyex auth was used
Mar 18 12:16:55 sshd-gssapi.example.fake sshd[22994]: Failed gssapi-keyex for
invalid user testuser22924x from 127.0.0.1 port 39550 ssh2:
testuser22...@example.fake
## PASS test_gssapi_keyex_login
```
Furthermore, the --grep option used in journalctl is not specific
enough, as can also be seen above. It's just looking for the
authentication method name, not whether is succeeded or not.
To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/openssh/+bug/2058276/+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 2058276] Re: Improve ssh-gssapi DEP8 test
** Merge proposal linked: https://code.launchpad.net/~ahasenack/ubuntu/+source/openssh/+git/openssh/+merge/462619 -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to openssh in Ubuntu. https://bugs.launchpad.net/bugs/2058276 Title: Improve ssh-gssapi DEP8 test Status in openssh package in Ubuntu: In Progress Bug description: The DEP8 test introduced in https://bugs.launchpad.net/ubuntu/+source/openssh/+bug/2053146 could still show s PASS even when the login didn't work. This is because it's relying on `set -e` to work inside functions, but that's not the case. For example, here I forced a failure by using an invalid user (I added "x" to the username): ``` ## ssh'ing into localhost using gssapi-keyex auth testuser229...@sshd-gssapi.example.fake: Permission denied (gssapi-keyex). ## checking that we got a service ticket for ssh (host/) 03/18/24 12:16:55 03/18/24 22:16:55 host/sshd-gssapi.example.fake@ Ticket server: host/sshd-gssapi.example.f...@example.fake ## Checking ssh logs to confirm gssapi-keyex auth was used Mar 18 12:16:55 sshd-gssapi.example.fake sshd[22994]: Failed gssapi-keyex for invalid user testuser22924x from 127.0.0.1 port 39550 ssh2: testuser22...@example.fake ## PASS test_gssapi_keyex_login ``` Furthermore, the --grep option used in journalctl is not specific enough, as can also be seen above. It's just looking for the authentication method name, not whether is succeeded or not. To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/openssh/+bug/2058276/+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 2051181] Update Released
The verification of the Stable Release Update for apt has completed successfully and the package is now being released to -updates. Subsequently, the Ubuntu Stable Release Updates Team is being unsubscribed and will not receive messages about this bug report. In the event that you encounter a regression using the package from -updates please report a new bug using ubuntu-bug and tag the bug report regression-update so we can easily find any regressions. -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to apt in Ubuntu. https://bugs.launchpad.net/bugs/2051181 Title: apt cannot upgrade phased updates if the current security version is same as updates Status in apt package in Ubuntu: Fix Released Status in apt source package in Jammy: Fix Committed Status in apt source package in Mantic: Fix Released Status in apt source package in Noble: Fix Released Bug description: [Impact] A package that has the same version in -security and -updates, with the latter having a Phased-Update-Percentage set is subject to phasing which is not expected by the security team. [Test plan] An automatic test case has been added to apt's comprehensive integration test suite that simulates the problem. Passing of the autopkgtests is a successful test. [Where problems could occur] The fix in question changes the behavior, some people may have relied on that, but also this should not have happened server side (normally security updates do not receive a value but the real one in this case went a different route). Otherwise the fix is fairly contained, it removes a single OtherVer++ increment which made it go one version below the current version, so we do not expect any problems; setting aside the usual regression potential from bugs in the compiler and so on. [Original bug report] When I finished installation with Jammy 22.04.3, I noticed that nvidia-driver-535 cannot be upgrade by either `apt upgrade` nor `apt dist-upgrade`. Below is the log of apt upgrade: ubuntu@ubuntu:~$ sudo apt -o Debug::pkgProblemResolver=1 upgrade --dry-run [2/1878] Reading package lists... Done Building dependency tree... Done Reading state information... Done Entering ResolveByKeep 10% Dependencies are not satisfied for nvidia-driver-535:amd64 < 535.129.03-0ubuntu0.22.04.1 | 535.154.05-0ubuntu0.22.04.1 @ii pumH NPb Ib > Package nvidia-driver-535:amd64 nvidia-driver-535:amd64 Depends on nvidia-dkms-535:amd64 < none | 535.154.05-0ubuntu0.22.04.1 @un umH > (<= 535.129.03-1) Keeping Package linux-modules-nvidia-535-oem-22.04c:amd64 due to Depends Dependencies are not satisfied for linux-modules-nvidia-535-oem-22.04c:amd64 < 6.1.0-1027.27 | 6.1.0-1028.28+2 @ii umH Ib > Keeping package linux-modules-nvidia-535-oem-22.04c:amd64 Dependencies are not satisfied for linux-modules-nvidia-535-oem-22.04c:amd64 < 6.1.0-1027.27 | 6.1.0-1028.28+2 @ii umH Ib > Package linux-modules-nvidia-535-oem-22.04c:amd64 linux-modules-nvidia-535-oem-22.04c:amd64 Depends on linux-modules-nvidia-535-6.1.0-1027-oem:amd64 < 6.1.0-1027.27 -> 6.1.0-1027.27+1 @ii umU Ib > (= 6.1.0-1027.27) Keeping Package linux-modules-nvidia-535-6.1.0-1027-oem:amd64 due to Depends Dependencies are not satisfied for linux-modules-nvidia-535-6.1.0-1028-oem:amd64 < none -> 6.1.0-1028.28+2 @un uN Ib > Keeping package linux-modules-nvidia-535-6.1.0-1028-oem:amd64 Dependencies are not satisfied for linux-modules-nvidia-535-6.1.0-1027-oem:amd64 < 6.1.0-1027.27 | 6.1.0-1027.27+1 @ii umH Ib > Keeping package linux-modules-nvidia-535-6.1.0-1027-oem:amd64 Dependencies are not satisfied for linux-modules-nvidia-535-6.1.0-1027-oem:amd64 < 6.1.0-1027.27 | 6.1.0-1027.27+1 @ii umH Ib > Package linux-modules-nvidia-535-6.1.0-1027-oem:amd64 linux-modules-nvidia-535-6.1.0-1027-oem:amd64 Depends on linux-signatures-nvidia-6.1.0-1027-oem:amd64 < 6.1.0-1027.27 -> 6.1.0-1027.27+1 @ii umU > (= 6.1.0-1027.27) Keeping Package linux-signatures-nvidia-6.1.0-1027-oem:amd64 due to Depends Dependencies are not satisfied for linux-modules-nvidia-535-6.1.0-1027-oem:amd64 < 6.1.0-1027.27 | 6.1.0-1027.27+1 @ii umH Ib > Dependencies are not satisfied for linux-modules-nvidia-535-6.1.0-1027-oem:amd64 < 6.1.0-1027.27 | 6.1.0-1027.27+1 @ii umH Ib > Dependencies are not satisfied for linux-modules-nvidia-535-6.1.0-1027-oem:amd64 < 6.1.0-1027.27 | 6.1.0-1027.27+1 @ii umH Ib > Package linux-modules-nvidia-535-6.1.0-1027-oem:amd64 linux-modules-nvidia-535-6.1.0-1027-oem:amd64 Depends on linux-objects-nvidia-535-6.1.0-1027-oem:amd64 < 6.1.0-1027.27 -> 6.1.0-1027.27+1 @ii umU > (= 6.1.0-1027.27) Keeping Package linux-objects-nvidia-535-6.1.0-1027-oem:amd64 due to Depends https://pastebin.canonical.com/p/7frwTKZG6D/ To m
[Touch-packages] [Bug 1995790] Update Released
The verification of the Stable Release Update for apt has completed successfully and the package is now being released to -updates. Subsequently, the Ubuntu Stable Release Updates Team is being unsubscribed and will not receive messages about this bug report. In the event that you encounter a regression using the package from -updates please report a new bug using ubuntu-bug and tag the bug report regression-update so we can easily find any regressions. -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to apt in Ubuntu. https://bugs.launchpad.net/bugs/1995790 Title: regression: ?garbage does not work correctly in install commands Status in apt package in Ubuntu: Fix Released Status in apt source package in Jammy: Fix Committed Status in apt source package in Lunar: Won't Fix Status in apt source package in Mantic: Fix Released Status in apt source package in Noble: Fix Released Bug description: [Impact] The '?garbage' pattern doesn't work with install/remove commands which is confusing, and the fix for it is trivial. [Test plan] Successful autopkgtest. The comprehensive test suite run as an autopkgtest has been updated in test/integration/test-apt-get-autoremove to test for the correct behavior of '?garbage' with install and remove. [Where problems could occur] You can see we had to tweak the test suite in a bunch of places because it relies on exact debug output format and because we now call "markandsweep" there's additional mark flags in the debug output. It's unlikely that this is a problem for others. We have not seen regressions in noble in the past 2 weeks or noble- proposed since 2023-11-23 (it was stuck for other reasons there), hence other places the code change may affect have been thoroughly exercised in the builders and autopkgtest runners. [Original bug report] The awesome apt has a some wonderful tips on their EXAMPLES section (printed below). The choice of name to "garbage" might not have been the best but the function is extremely useful. $ man apt-patterns | sed '/EXAMPLES/,/^[^ ]/!d;/^[^ ]/d' apt remove ?garbage Remove all packages that are automatically installed and no longer needed - same as apt autoremove apt purge ?config-files Purge all packages that only have configuration files left apt list '~i !~M (~slibs|~sperl|~spython)' List all manually-installed packages in sections matching libs, perl, or python. Lets mark a package as automatically installed, and use the examples. $ sudo apt-mark auto shotwell shotwell set to automatically installed. $ sudo apt remove ?garbage Reading package lists... Done Building dependency tree... Done Reading state information... Done The following packages were automatically installed and are no longer required: libraw20 shotwell shotwell-common Use 'sudo apt autoremove' to remove them. 0 upgraded, 0 newly installed, 0 to remove and 0 not upgraded. $ sudo apt autoremove Reading package lists... Done Building dependency tree... Done Reading state information... Done The following packages will be REMOVED: libraw20 shotwell shotwell-common 0 upgraded, 0 newly installed, 3 to remove and 0 not upgraded. After this operation, 9.806 kB disk space will be freed. Do you want to continue? [Y/n] N Abort. Apt-patterns works as it should everywhere else, as far as I can see, it works wonders with ie `apt list '~g|~c'` and many other applications. I used `apt purge '~g|~c'` successfully in Ubuntu 20.04 for years, so I feel this is a regression. ProblemType: Bug DistroRelease: Ubuntu 22.04 Package: apt 2.4.8 ProcVersionSignature: Ubuntu 5.15.0-52.58-generic 5.15.60 Uname: Linux 5.15.0-52-generic x86_64 NonfreeKernelModules: zfs zunicode zavl icp zcommon znvpair ApportVersion: 2.20.11-0ubuntu82.1 Architecture: amd64 CasperMD5CheckResult: unknown CurrentDesktop: ubuntu:GNOME Date: Sun Nov 6 10:57:52 2022 SourcePackage: apt UpgradeStatus: Upgraded to jammy on 2022-03-26 (224 days ago) To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/apt/+bug/1995790/+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 2059078] Re: proposed-migration for faketime 0.9.10-2.1ubuntu1
I added an sssd task due to the workaround we had to add to it in https://bugs.launchpad.net/ubuntu/+source/sssd/+bug/2058576 (we don't install faketime). Should faketime be fixed, then we can revert that change in sssd. ** Also affects: sssd (Ubuntu) Importance: Undecided Status: New -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to bash in Ubuntu. https://bugs.launchpad.net/bugs/2059078 Title: proposed-migration for faketime 0.9.10-2.1ubuntu1 Status in bash package in Ubuntu: New Status in faketime package in Ubuntu: New Status in sssd package in Ubuntu: New Bug description: faketime 0.9.10-2.1ubuntu1 is stuck in -proposed with build failures on armhf. On armhf, the testsuite confusingly fails with a stack smash error. But this error happens in bash, which isn't even meant to be the process under test. Minimal reproducer: # LD_PRELOAD=./src/libfaketime.so.1 bash -c 'exit 0' *** stack smashing detected ***: terminated Aborted (core dumped) # Confusingly, ltrace shows different results for the newly-built binary than from one built without 64-bit time_t. # LD_PRELOAD=./src/libfaketime.so.1 ltrace --library '*faketime*' bash -c 'exit 0' bash->getrandom(0x1f3bf08, 1, 0x9683b0, 0) = 0xc8202 bash->getrandom(0xc8203, 0xf7fad53c, 1023, 0xf7eef801) = 0xc8202 *** stack smashing detected ***: terminated --- SIGABRT (Aborted) --- +++ killed by SIGABRT +++ # LD_PRELOAD=/usr/lib/arm-linux-gnueabihf/faketime/libfaketime.so.1 ltrace --library '*faketime*' bash -c 'exit 0' bash->gettimeofday(0x8b07a0, 0) = 0 bash->getpid() = 819717 bash->gettimeofday(0xffb88714, 0)= 0 bash->getpid() = 819717 bash->gettimeofday(0xffb8871c, 0)= 0 bash->getpid() = 819717 +++ exited (status 0) +++ # Unsetting -DFAKE_RANDOM in debian/rules does not fix the problem however. So simply loading the LD_PRELOAD library without executing it seems to be enough to break bash. To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/bash/+bug/2059078/+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 2053146] Re: openssh 8.9p1 for Jammy auth2-gss patch for gssapi-keyex method is slightly wrong
** Description changed:
[ Impact ]
The gssapi-keyex authentication mechanism has been inadvertently broken
in openssh. It comes from a distro patch[1], and while the patch still
applied, it was no longer correct.
Without the fix, sshd will fail to start if gssapi-keyex is listed in
the AuthenticationMethods of the server, and if not, sshd will still
start, but gssapi-keyex will not be available.
-
[ Test Plan ]
This update adds a new autopkgtest to the package, which tests both
gssapi-with-mic ("normal" gssapi, which is not affected by this bug),
and gssapi-keyex, which, before this update, does not work.
The test plan is to run the new ssh-gssapi autopkgtest and verify it
succeeds.
-
[ Where problems could occur ]
ssh is a critical piece of infrastructure, and problems with it could
have catastrophic consequences. The service itself has a test command
before it starts up to verify the syntax of the config file, but that
test is not applied on shutdown, so a restart with an invalid config
file could still leave sshd dead.
The patch adds a change to an authentication structure, but that change
is already present in the upstream code, and we are just updating it in
the new gssapi-keyex code (introduced by the distro[1] patch, already
present). Therefore, mistakes here should manifest themselves just in
the gssapi-keyex code, which wasn't working anyway. Effectively, though,
we are enabling a new authentication mechanism in sshd, one that was not
supposed to have been removed, but was broken by mistake.
-
[ Other Info ]
The fact no-one noticed this problem for more than two years could be
telling that there are not many users of this authentication mechanism
out there. The same applies to debian: it has also been broken for a
while there. Maybe we should drop it for future ubuntu releases, since
upstream refuses to take it in.
+
+
+ 1.
https://git.launchpad.net/ubuntu/+source/openssh/tree/debian/patches/gssapi.patch
+
[ Original Description ]
The Authmethod struct now have 4 entries but the initialization of the
method_gsskeyex in the debian/patches/gssapi.patch only have 3 entries.
The struct was changed in upstream commit
dbb339f015c33d63484261d140c84ad875a9e548 as
===
@@ -104,7 +104,8 @@ struct Authctxt {
struct Authmethod {
char*name;
- int (*userauth)(struct ssh *);
+ char*synonym;
+ int (*userauth)(struct ssh *, const char *);
int *enabled;
};
===
The incorrect code does
===
+Authmethod method_gsskeyex = {
+ "gssapi-keyex",
+ userauth_gsskeyex,
+ &options.gss_authentication
+};
===
but should have a NULL between the "gssapi-keyex" string and userauth_gsskeyex
This is now (change from Focal) causing gssapi-keyex to be disabled.
===
lsb_release -rd
Description: Ubuntu 22.04.3 LTS
Release: 22.04
===
apt-cache policy openssh-server
openssh-server:
Installed: 1:8.9p1-3ubuntu0.6
Candidate: 1:8.9p1-3ubuntu0.6
Version table:
*** 1:8.9p1-3ubuntu0.6 500
500 http://faiserver.hpc2n.umu.se/mirrors/ubuntu/ubuntu
jammy-updates/main amd64 Packages
500 http://faiserver.hpc2n.umu.se/mirrors/ubuntu/ubuntu
jammy-security/main amd64 Packages
100 /var/lib/dpkg/status
1:8.9p1-3 500
500 http://faiserver.hpc2n.umu.se/mirrors/ubuntu/ubuntu jammy/main
amd64 Packages
===
** Description changed:
[ Impact ]
The gssapi-keyex authentication mechanism has been inadvertently broken
in openssh. It comes from a distro patch[1], and while the patch still
applied, it was no longer correct.
Without the fix, sshd will fail to start if gssapi-keyex is listed in
the AuthenticationMethods of the server, and if not, sshd will still
start, but gssapi-keyex will not be available.
[ Test Plan ]
- This update adds a new autopkgtest to the package, which tests both
- gssapi-with-mic ("normal" gssapi, which is not affected by this bug),
- and gssapi-keyex, which, before this update, does not work.
+ This update, besides fixing the patch, also adds a new autopkgtest to
+ the package, which tests both gssapi-with-mic ("normal" gssapi, which is
+ not affected by this bug), and gssapi-keyex, which, before this update,
+ did not work.
The test plan is to run the new ssh-gssapi autopkgtest and verify it
succeeds.
[ Where problems could occur ]
ssh is a critical piece of infrastructure, and problems with it could
have catastrophic consequences. The service itself has a test command
before it starts up to verify the syntax of the config file, but that
test is not applied on shutdown, so a restart with an invalid config
file could still leave sshd dead.
The patch adds a change to an authentication structure, but that change
is already present in the upstream code,
[Touch-packages] [Bug 2053146] Re: openssh 8.9p1 for Jammy auth2-gss patch for gssapi-keyex method is slightly wrong
Jammy verification In all architectures (except i386, which is a known failure everywhere) the new ssh-gssapi test passed. Here is the run on amd64[1]: 3438s autopkgtest [16:33:21]: test ssh-gssapi: [--- 3438s ## Setting up test environment 3438s ## Creating Kerberos realm EXAMPLE.FAKE 3438s Loading random data 3438s Initializing database '/var/lib/krb5kdc/principal' for realm 'EXAMPLE.FAKE', 3438s master key name 'K/m...@example.fake' 3438s ## Creating principals 3438s Authenticating as principal root/ad...@example.fake with password. 3438s Principal "testuser1...@example.fake" created. 3438s Authenticating as principal root/ad...@example.fake with password. 3438s Principal "host/sshd-gssapi.example.f...@example.fake" created. 3438s ## Extracting service principal host/sshd-gssapi.example.fake 3438s Authenticating as principal root/ad...@example.fake with password. 3438s Entry for principal host/sshd-gssapi.example.fake with kvno 2, encryption type aes256-cts-hmac-sha1-96 added to keytab WRFILE:/etc/krb5.keytab. 3438s Entry for principal host/sshd-gssapi.example.fake with kvno 2, encryption type aes128-cts-hmac-sha1-96 added to keytab WRFILE:/etc/krb5.keytab. 3438s ## Adjusting /etc/krb5.conf 3438s ## TESTS 3438s 3438s ## TEST test_gssapi_login 3438s ## Configuring sshd for gssapi-with-mic authentication 3438s ## Restarting ssh 3438s ## Obtaining TGT 3438s Password for testuser1...@example.fake: 3438s Ticket cache: FILE:/tmp/krb5cc_0 3438s Default principal: testuser1...@example.fake 3438s 3438s Valid starting ExpiresService principal 3438s 04/05/24 16:33:20 04/06/24 02:33:20 krbtgt/example.f...@example.fake 3438s renew until 04/06/24 16:33:20 3438s 3438s ## ssh'ing into localhost using gssapi-with-mic auth 3438s Warning: Permanently added 'sshd-gssapi.example.fake' (ED25519) to the list of known hosts. 3439s Fri Apr 5 16:33:21 UTC 2024 3439s 3439s ## checking that we got a service ticket for ssh (host/) 3439s 04/05/24 16:33:21 04/06/24 02:33:20 host/sshd-gssapi.example.fake@ 3439s Ticket server: host/sshd-gssapi.example.f...@example.fake 3439s 3439s ## Checking ssh logs to confirm gssapi-with-mic auth was used 3439s Apr 05 16:33:21 sshd-gssapi.example.fake sshd[1518]: Accepted gssapi-with-mic for testuser1457 from 127.0.0.1 port 50668 ssh2: testuser1...@example.fake 3439s ## PASS test_gssapi_login 3439s 3439s ## TEST test_gssapi_keyex_login 3439s ## Configuring sshd for gssapi-keyex authentication 3439s ## Restarting ssh 3439s ## Obtaining TGT 3439s Password for testuser1...@example.fake: 3439s Ticket cache: FILE:/tmp/krb5cc_0 3439s Default principal: testuser1...@example.fake 3439s 3439s Valid starting ExpiresService principal 3439s 04/05/24 16:33:21 04/06/24 02:33:21 krbtgt/example.f...@example.fake 3439s renew until 04/06/24 16:33:21 3439s 3439s ## ssh'ing into localhost using gssapi-keyex auth 3439s Fri Apr 5 16:33:21 UTC 2024 3439s 3439s ## checking that we got a service ticket for ssh (host/) 3439s 04/05/24 16:33:21 04/06/24 02:33:21 host/sshd-gssapi.example.fake@ 3439s Ticket server: host/sshd-gssapi.example.f...@example.fake 3439s 3439s ## Checking ssh logs to confirm gssapi-keyex auth was used 3439s Apr 05 16:33:21 sshd-gssapi.example.fake sshd[1558]: Accepted gssapi-keyex for testuser1457 from 127.0.0.1 port 50670 ssh2: testuser1...@example.fake 3439s ## PASS test_gssapi_keyex_login 3439s 3439s ## ALL TESTS PASSED 3439s ## Cleaning up 3439s autopkgtest [16:33:22]: test ssh-gssapi: ---] 3439s autopkgtest [16:33:22]: test ssh-gssapi: - - - - - - - - - - results - - - - - - - - - - 3439s ssh-gssapi PASS 3440s autopkgtest [16:33:23]: summary 3440s regress PASS 3440s ssh-gssapi PASS Jammy verification succeeded. 1. https://autopkgtest.ubuntu.com/results/autopkgtest-jammy/jammy/amd64/o/openssh/20240405_163345_c46fa@/log.gz ** 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 openssh in Ubuntu. https://bugs.launchpad.net/bugs/2053146 Title: openssh 8.9p1 for Jammy auth2-gss patch for gssapi-keyex method is slightly wrong Status in openssh package in Ubuntu: Fix Released Status in openssh source package in Jammy: Fix Committed Status in openssh source package in Mantic: Fix Committed Status in openssh source package in Noble: Fix Released Bug description: [ Impact ] The gssapi-keyex authentication mechanism has been inadvertently broken in openssh. It comes from a distro patch[1], and while the patch still applied, it was no longer correct. Without the fix, sshd will fail to start if gssapi-keyex is listed in the AuthenticationMethods of the server, and if not, sshd will still start, but gssapi-keyex will not be available. [ Test Plan ] This updat
[Touch-packages] [Bug 2053146] Re: openssh 8.9p1 for Jammy auth2-gss patch for gssapi-keyex method is slightly wrong
Mantic verification In all architectures, except i386, the new test passed. Here is a log from the amd64 run[1]: 4333s autopkgtest [16:47:27]: test ssh-gssapi: [--- 4333s ## Setting up test environment 4333s ## Creating Kerberos realm EXAMPLE.FAKE 4333s Initializing database '/var/lib/krb5kdc/principal' for realm 'EXAMPLE.FAKE', 4333s master key name 'K/m...@example.fake' 4333s ## Creating principals 4333s Authenticating as principal root/ad...@example.fake with password. 4333s Principal "testuser1...@example.fake" created. 4333s Authenticating as principal root/ad...@example.fake with password. 4333s Principal "host/sshd-gssapi.example.f...@example.fake" created. 4333s ## Extracting service principal host/sshd-gssapi.example.fake 4333s Authenticating as principal root/ad...@example.fake with password. 4333s Entry for principal host/sshd-gssapi.example.fake with kvno 2, encryption type aes256-cts-hmac-sha1-96 added to keytab WRFILE:/etc/krb5.keytab. 4333s Entry for principal host/sshd-gssapi.example.fake with kvno 2, encryption type aes128-cts-hmac-sha1-96 added to keytab WRFILE:/etc/krb5.keytab. 4333s ## Adjusting /etc/krb5.conf 4333s ## TESTS 4333s 4333s ## TEST test_gssapi_login 4333s ## Configuring sshd for gssapi-with-mic authentication 4333s ## Restarting ssh 4333s ## Obtaining TGT 4333s Password for testuser1...@example.fake: 4333s Ticket cache: FILE:/tmp/krb5cc_0 4333s Default principal: testuser1...@example.fake 4333s 4333s Valid starting ExpiresService principal 4333s 04/05/24 16:47:27 04/06/24 02:47:27 krbtgt/example.f...@example.fake 4333s renew until 04/06/24 16:47:27 4333s 4333s ## ssh'ing into localhost using gssapi-with-mic auth 4333s Warning: Permanently added 'sshd-gssapi.example.fake' (ED25519) to the list of known hosts. 4334s Fri Apr 5 16:47:27 UTC 2024 4334s 4334s ## checking that we got a service ticket for ssh (host/) 4334s 04/05/24 16:47:27 04/06/24 02:47:27 host/sshd-gssapi.example.fake@ 4334s Ticket server: host/sshd-gssapi.example.f...@example.fake 4334s 4334s ## Checking ssh logs to confirm gssapi-with-mic auth was used 4334s Apr 05 16:47:27 sshd-gssapi.example.fake sshd[1688]: Accepted gssapi-with-mic for testuser1620 from 127.0.0.1 port 44922 ssh2: testuser1...@example.fake 4334s ## PASS test_gssapi_login 4334s 4334s ## TEST test_gssapi_keyex_login 4334s ## Configuring sshd for gssapi-keyex authentication 4334s ## Restarting ssh 4334s ## Obtaining TGT 4334s Password for testuser1...@example.fake: 4334s Ticket cache: FILE:/tmp/krb5cc_0 4334s Default principal: testuser1...@example.fake 4334s 4334s Valid starting ExpiresService principal 4334s 04/05/24 16:47:28 04/06/24 02:47:28 krbtgt/example.f...@example.fake 4334s renew until 04/06/24 16:47:28 4334s 4334s ## ssh'ing into localhost using gssapi-keyex auth 4334s Fri Apr 5 16:47:28 UTC 2024 4334s 4334s ## checking that we got a service ticket for ssh (host/) 4334s 04/05/24 16:47:28 04/06/24 02:47:28 host/sshd-gssapi.example.fake@ 4334s Ticket server: host/sshd-gssapi.example.f...@example.fake 4334s 4334s ## Checking ssh logs to confirm gssapi-keyex auth was used 4334s Apr 05 16:47:28 sshd-gssapi.example.fake sshd[1758]: Accepted gssapi-keyex for testuser1620 from 127.0.0.1 port 44930 ssh2: testuser1...@example.fake 4334s ## PASS test_gssapi_keyex_login 4334s 4334s ## ALL TESTS PASSED 4334s ## Cleaning up 4334s autopkgtest [16:47:28]: test ssh-gssapi: ---] 4335s ssh-gssapi PASS 4335s autopkgtest [16:47:29]: test ssh-gssapi: - - - - - - - - - - results - - - - - - - - - - 4335s autopkgtest [16:47:29]: summary 4335s regress PASS 4335s systemd-socket-activation PASS 4335s ssh-gssapi PASS Mantic verification succeeded. 1. https://autopkgtest.ubuntu.com/results/autopkgtest- mantic/mantic/amd64/o/openssh/20240405_164750_3a52b@/log.gz ** Tags removed: verification-needed-mantic ** Tags added: verification-done-mantic -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to openssh in Ubuntu. https://bugs.launchpad.net/bugs/2053146 Title: openssh 8.9p1 for Jammy auth2-gss patch for gssapi-keyex method is slightly wrong Status in openssh package in Ubuntu: Fix Released Status in openssh source package in Jammy: Fix Committed Status in openssh source package in Mantic: Fix Committed Status in openssh source package in Noble: Fix Released Bug description: [ Impact ] The gssapi-keyex authentication mechanism has been inadvertently broken in openssh. It comes from a distro patch[1], and while the patch still applied, it was no longer correct. Without the fix, sshd will fail to start if gssapi-keyex is listed in the AuthenticationMethods of the server, and if not, sshd will still start, but gssapi-keyex will not be available. [ Test Plan ] This update, besides fixing the
[Touch-packages] [Bug 2059859] Re: pam_env(sshd:session): deprecated reading of user environment enabled
Fixing this in noble at this time will require a feature freeze exception, because we would be changing behavior. The default for user_readenv in pam_env is 0 (off). In the sshd config, ubuntu/debian ship a pam config that sets it to on (1), therefore ~/.pam_environment will be read if it exists. Upstream has flagged that this feature (of reading user-provided env var files) will be removed in the future, and is thus catching the setting of user_readenv=1 and showing the deprecation notice warning. To get rid of the warning, we have to stop setting user_readenv=1, which will *disable* the feature. Meaning, in noble, if we make this change, ~/.pam_environment (or the file specified by user_envfile) will NOT be read anymore. -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to openssh in Ubuntu. https://bugs.launchpad.net/bugs/2059859 Title: pam_env(sshd:session): deprecated reading of user environment enabled Status in openssh package in Ubuntu: Triaged Bug description: Ubuntu 24.04 / openssh-server/noble-updates 1:9.6p1-3ubuntu3 sshd complains about "deprecated reading of user environment". This should have been solved upstream, as far as I understand: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1018106 Enclosed /etc/pam.d/sshd file is amended according to the debian bug report. ProblemType: Bug DistroRelease: Ubuntu 24.04 Package: openssh-server 1:9.6p1-3ubuntu3 ProcVersionSignature: Ubuntu 6.8.0-11.11-generic 6.8.0-rc4 Uname: Linux 6.8.0-11-generic x86_64 ApportVersion: 2.28.0-0ubuntu1 Architecture: amd64 CasperMD5CheckResult: unknown Date: Sun Mar 31 11:56:25 2024 ProcEnviron: LANG=de_DE.UTF-8 PATH=(custom, no user) SHELL=/bin/bash TERM=xterm-256color XDG_RUNTIME_DIR= SourcePackage: openssh UpgradeStatus: No upgrade log present (probably fresh install) modified.conffile..etc.init.d.apport: [modified] mtime.conffile..etc.init.d.apport: 2024-02-22T15:20:00 mtime.conffile..etc.pam.d.sshd: 2024-03-31T11:56:12.949543 To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/openssh/+bug/2059859/+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 2059859] Re: pam_env(sshd:session): deprecated reading of user environment enabled
Deprecation warning introduced here: https://github.com/linux-pam/linux- pam/releases/tag/v1.5.0 Release notes for all releases up to 1.6.1 don't mention this again, so it's still there: https://github.com/linux-pam/linux-pam/releases -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to openssh in Ubuntu. https://bugs.launchpad.net/bugs/2059859 Title: pam_env(sshd:session): deprecated reading of user environment enabled Status in openssh package in Ubuntu: Triaged Bug description: Ubuntu 24.04 / openssh-server/noble-updates 1:9.6p1-3ubuntu3 sshd complains about "deprecated reading of user environment". This should have been solved upstream, as far as I understand: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1018106 Enclosed /etc/pam.d/sshd file is amended according to the debian bug report. ProblemType: Bug DistroRelease: Ubuntu 24.04 Package: openssh-server 1:9.6p1-3ubuntu3 ProcVersionSignature: Ubuntu 6.8.0-11.11-generic 6.8.0-rc4 Uname: Linux 6.8.0-11-generic x86_64 ApportVersion: 2.28.0-0ubuntu1 Architecture: amd64 CasperMD5CheckResult: unknown Date: Sun Mar 31 11:56:25 2024 ProcEnviron: LANG=de_DE.UTF-8 PATH=(custom, no user) SHELL=/bin/bash TERM=xterm-256color XDG_RUNTIME_DIR= SourcePackage: openssh UpgradeStatus: No upgrade log present (probably fresh install) modified.conffile..etc.init.d.apport: [modified] mtime.conffile..etc.init.d.apport: 2024-02-22T15:20:00 mtime.conffile..etc.pam.d.sshd: 2024-03-31T11:56:12.949543 To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/openssh/+bug/2059859/+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 2059859] Re: pam_env(sshd:session): deprecated reading of user environment enabled
Commit that added the warning to pam_env.c: https://github.com/linux- pam/linux-pam/commit/ecd526743a27157c5210b0ce9867c43a2fa27784 -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to openssh in Ubuntu. https://bugs.launchpad.net/bugs/2059859 Title: pam_env(sshd:session): deprecated reading of user environment enabled Status in openssh package in Ubuntu: Triaged Bug description: Ubuntu 24.04 / openssh-server/noble-updates 1:9.6p1-3ubuntu3 sshd complains about "deprecated reading of user environment". This should have been solved upstream, as far as I understand: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1018106 Enclosed /etc/pam.d/sshd file is amended according to the debian bug report. ProblemType: Bug DistroRelease: Ubuntu 24.04 Package: openssh-server 1:9.6p1-3ubuntu3 ProcVersionSignature: Ubuntu 6.8.0-11.11-generic 6.8.0-rc4 Uname: Linux 6.8.0-11-generic x86_64 ApportVersion: 2.28.0-0ubuntu1 Architecture: amd64 CasperMD5CheckResult: unknown Date: Sun Mar 31 11:56:25 2024 ProcEnviron: LANG=de_DE.UTF-8 PATH=(custom, no user) SHELL=/bin/bash TERM=xterm-256color XDG_RUNTIME_DIR= SourcePackage: openssh UpgradeStatus: No upgrade log present (probably fresh install) modified.conffile..etc.init.d.apport: [modified] mtime.conffile..etc.init.d.apport: 2024-02-22T15:20:00 mtime.conffile..etc.pam.d.sshd: 2024-03-31T11:56:12.949543 To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/openssh/+bug/2059859/+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 2059859] Re: pam_env(sshd:session): deprecated reading of user environment enabled
We won't fix this in openssh for Ubuntu 24.04 due to the change in behavior that it introduces at this stage in the cycle, but it should be fixed in 24.10. As for 24.04, what we will attempt to do is suppress the pam_env warning in the src:pam package. ** Also affects: pam (Ubuntu) Importance: Undecided Status: New ** Changed in: openssh (Ubuntu) Milestone: None => later ** Changed in: pam (Ubuntu) Status: New => In Progress ** Changed in: pam (Ubuntu) Assignee: (unassigned) => Andreas Hasenack (ahasenack) ** Changed in: pam (Ubuntu) Milestone: None => ubuntu-24.04 -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to openssh in Ubuntu. https://bugs.launchpad.net/bugs/2059859 Title: pam_env(sshd:session): deprecated reading of user environment enabled Status in openssh package in Ubuntu: Triaged Status in pam package in Ubuntu: In Progress Bug description: Ubuntu 24.04 / openssh-server/noble-updates 1:9.6p1-3ubuntu3 sshd complains about "deprecated reading of user environment". This should have been solved upstream, as far as I understand: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1018106 Enclosed /etc/pam.d/sshd file is amended according to the debian bug report. ProblemType: Bug DistroRelease: Ubuntu 24.04 Package: openssh-server 1:9.6p1-3ubuntu3 ProcVersionSignature: Ubuntu 6.8.0-11.11-generic 6.8.0-rc4 Uname: Linux 6.8.0-11-generic x86_64 ApportVersion: 2.28.0-0ubuntu1 Architecture: amd64 CasperMD5CheckResult: unknown Date: Sun Mar 31 11:56:25 2024 ProcEnviron: LANG=de_DE.UTF-8 PATH=(custom, no user) SHELL=/bin/bash TERM=xterm-256color XDG_RUNTIME_DIR= SourcePackage: openssh UpgradeStatus: No upgrade log present (probably fresh install) modified.conffile..etc.init.d.apport: [modified] mtime.conffile..etc.init.d.apport: 2024-02-22T15:20:00 mtime.conffile..etc.pam.d.sshd: 2024-03-31T11:56:12.949543 To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/openssh/+bug/2059859/+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 2059859] Re: pam_env(sshd:session): deprecated reading of user environment enabled
New pam package uploaded to noble-proposed. It's in the unapproved queue. -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to openssh in Ubuntu. https://bugs.launchpad.net/bugs/2059859 Title: pam_env(sshd:session): deprecated reading of user environment enabled Status in openssh package in Ubuntu: Triaged Status in pam package in Ubuntu: In Progress Bug description: Ubuntu 24.04 / openssh-server/noble-updates 1:9.6p1-3ubuntu3 sshd complains about "deprecated reading of user environment". This should have been solved upstream, as far as I understand: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1018106 Enclosed /etc/pam.d/sshd file is amended according to the debian bug report. ProblemType: Bug DistroRelease: Ubuntu 24.04 Package: openssh-server 1:9.6p1-3ubuntu3 ProcVersionSignature: Ubuntu 6.8.0-11.11-generic 6.8.0-rc4 Uname: Linux 6.8.0-11-generic x86_64 ApportVersion: 2.28.0-0ubuntu1 Architecture: amd64 CasperMD5CheckResult: unknown Date: Sun Mar 31 11:56:25 2024 ProcEnviron: LANG=de_DE.UTF-8 PATH=(custom, no user) SHELL=/bin/bash TERM=xterm-256color XDG_RUNTIME_DIR= SourcePackage: openssh UpgradeStatus: No upgrade log present (probably fresh install) modified.conffile..etc.init.d.apport: [modified] mtime.conffile..etc.init.d.apport: 2024-02-22T15:20:00 mtime.conffile..etc.pam.d.sshd: 2024-03-31T11:56:12.949543 To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/openssh/+bug/2059859/+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 2060335] Re: upower/1.90.2-8build3 autopkgtest failure on arm64
At the moment, noble-proposed has https://launchpad.net/ubuntu/+source/upower/1.90.3-1, uploaded a few hours ago: upower (1.90.3-1) unstable; urgency=medium * New upstream version 1.90.3 * Drop patches, merged upstream * Bump Build-Depends on meson to (>= 0.60.0) and libglib2.0-dev to (>= 2.66) as per meson.build * Switch Build-Depends on pkg-config to pkgconf * Bump Standards-Version to 4.7.0 -- Michael Biebl Mon, 08 Apr 2024 09:42:45 +0200 According to https://autopkgtest.ubuntu.com/packages/u/upower/noble/arm64 arm64 tests with that version have passed already: (...) 905s Ran 67 tests in 174.527s 905s 905s OK 905s PASS: upower/upower-integration.test 905s SUMMARY: total=1; passed=1; skipped=0; failed=0; user=11.5s; system=4.9s; maxrss=33304 906s autopkgtest [06:17:15]: test installed-tests: ---] 907s installed-tests PASS Closing bug (fix committed, since it's not yet in the release pocket). ** Changed in: upower (Ubuntu) Status: In Progress => Fix Committed -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to upower in Ubuntu. https://bugs.launchpad.net/bugs/2060335 Title: upower/1.90.2-8build3 autopkgtest failure on arm64 Status in upower package in Ubuntu: Fix Committed Bug description: autopkgtests fail, only on arm64, after a no-change-rebuild, with the following output: 689s [32mTI:22:39:23 [34mHandling SIGTERM 689s [0m. 689s == 689s ERROR: test_daemon_restart (__main__.Tests.test_daemon_restart) 689s -- 689s Traceback (most recent call last): 689s File "/usr/lib/python3.12/shutil.py", line 785, in rmtree 689s _rmtree_safe_fd(fd, path, onexc) 689s File "/usr/lib/python3.12/shutil.py", line 717, in _rmtree_safe_fd 689s onexc(os.unlink, fullname, err) 689s File "/usr/lib/python3.12/shutil.py", line 715, in _rmtree_safe_fd 689s os.unlink(entry.name, dir_fd=topfd) 689s FileNotFoundError: [Errno 2] No such file or directory: 'history-time-full-G935_Gaming_Headset.dat.KL0SL2' 689s 689s == 689s FAIL: test_daemon_restart (__main__.Tests.test_daemon_restart) 689s -- 689s Traceback (most recent call last): 689s File "/usr/libexec/upower/integration-test.py", line 2558, in test_daemon_restart 689s self.stop_daemon() 689s File "/usr/libexec/upower/integration-test.py", line 239, in stop_daemon 689s self.assertEqual(self.daemon.wait(timeout=5.0), 0) 689s AssertionError: -15 != 0 689s 689s == 689s FAIL: test_daemon_restart (__main__.Tests.test_daemon_restart) 689s -- 689s Traceback (most recent call last): 689s File "/usr/libexec/upower/integration-test.py", line 173, in tearDown 689s self.stop_daemon() 689s File "/usr/libexec/upower/integration-test.py", line 239, in stop_daemon 689s self.assertEqual(self.daemon.wait(timeout=5.0), 0) 689s AssertionError: -15 != 0 689s 689s -- 689s Ran 66 tests in 194.378s 689s 689s FAILED (failures=2, errors=1) full log: https://autopkgtest.ubuntu.com/results/autopkgtest- noble/noble/arm64/u/upower/20240405_224518_5cff1@/log.gz These test passed in the previous version: https://autopkgtest.ubuntu.com/results/autopkgtest-noble/noble/arm64/u/upower/20240405_224754_d187c@/log.gz To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/upower/+bug/2060335/+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 2060335] Re: upower/1.90.2-8build3 autopkgtest failure on arm64
And unsubscribing sponsors. -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to upower in Ubuntu. https://bugs.launchpad.net/bugs/2060335 Title: upower/1.90.2-8build3 autopkgtest failure on arm64 Status in upower package in Ubuntu: Fix Committed Bug description: autopkgtests fail, only on arm64, after a no-change-rebuild, with the following output: 689s [32mTI:22:39:23 [34mHandling SIGTERM 689s [0m. 689s == 689s ERROR: test_daemon_restart (__main__.Tests.test_daemon_restart) 689s -- 689s Traceback (most recent call last): 689s File "/usr/lib/python3.12/shutil.py", line 785, in rmtree 689s _rmtree_safe_fd(fd, path, onexc) 689s File "/usr/lib/python3.12/shutil.py", line 717, in _rmtree_safe_fd 689s onexc(os.unlink, fullname, err) 689s File "/usr/lib/python3.12/shutil.py", line 715, in _rmtree_safe_fd 689s os.unlink(entry.name, dir_fd=topfd) 689s FileNotFoundError: [Errno 2] No such file or directory: 'history-time-full-G935_Gaming_Headset.dat.KL0SL2' 689s 689s == 689s FAIL: test_daemon_restart (__main__.Tests.test_daemon_restart) 689s -- 689s Traceback (most recent call last): 689s File "/usr/libexec/upower/integration-test.py", line 2558, in test_daemon_restart 689s self.stop_daemon() 689s File "/usr/libexec/upower/integration-test.py", line 239, in stop_daemon 689s self.assertEqual(self.daemon.wait(timeout=5.0), 0) 689s AssertionError: -15 != 0 689s 689s == 689s FAIL: test_daemon_restart (__main__.Tests.test_daemon_restart) 689s -- 689s Traceback (most recent call last): 689s File "/usr/libexec/upower/integration-test.py", line 173, in tearDown 689s self.stop_daemon() 689s File "/usr/libexec/upower/integration-test.py", line 239, in stop_daemon 689s self.assertEqual(self.daemon.wait(timeout=5.0), 0) 689s AssertionError: -15 != 0 689s 689s -- 689s Ran 66 tests in 194.378s 689s 689s FAILED (failures=2, errors=1) full log: https://autopkgtest.ubuntu.com/results/autopkgtest- noble/noble/arm64/u/upower/20240405_224518_5cff1@/log.gz These test passed in the previous version: https://autopkgtest.ubuntu.com/results/autopkgtest-noble/noble/arm64/u/upower/20240405_224754_d187c@/log.gz To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/upower/+bug/2060335/+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 2060692] Re: cupsd 2.4.7-1.2ubuntu5 on noble crashes due to recently backported commits from 2.4.x git
https://launchpad.net/ubuntu/+source/cups/2.4.7-1.2ubuntu6 is in noble- proposed claiming to fix this bug. Comment #6 above says there is a missing patch still. In any case, doesn't look like there is anything to sponsor here, so unsubscribing ubuntu-sponsors. -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to cups in Ubuntu. https://bugs.launchpad.net/bugs/2060692 Title: cupsd 2.4.7-1.2ubuntu5 on noble crashes due to recently backported commits from 2.4.x git Status in cups package in Ubuntu: In Progress Bug description: While checking out the latest versions of cups (2.4.7-1.2ubuntu4 and 2.4.7-1.2ubuntu5), I noticed that cupsd crashes consistently after closing my Firefox tab / window. The title of the crash (from the bug-report window) is "cupsd crashed with SIGSEGV in ???()" I'm running the noble-desktop-amd64.iso from 2024-03-25 after applying some updates from the noble and noble-proposed pockets. Reproduction steps: 1. Open Firefox and manage CUPS on http://localhost:631 2. Go to Administration -> Printers -> Add Printer and choose your printer 3. Add your printer (I used the ipps:// protocol to manage the printer) 4. After clicking the "Add printer" button, immediately close your Firefox tab 5. cupsd will crash and Ubuntu will display a bug-report popup Versions: Firefox - 124.0.1-1 r4033 CUPS - 2.4.7-1.2ubuntu5 Printer: Lexmark MS415dn (supported) I am unable to reproduce this bug on versions prior to 2.4.7-1.2ubuntu4 (Tried with 2.4.7-1.2ubuntu1 and 2.4.7-1.2ubuntu2). Versions 2.4.7-1.2ubuntu4 and 2.4.7-1.2ubuntu5 only backported commits from the 2.4.x upstream git branch, so I also opened an issue on GitHub: https://github.com/OpenPrinting/cups/issues/934 To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/cups/+bug/2060692/+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 2060967] Re: noble/rsync buffer overflow detected
I'm surprised this wasn't caught by the DEP8 tests. Care to also perhaps add a simple smoke test, like (note it's not using ssh or any network): $ rsync -F --delete-after --archive /etc/os-release /tmp/ *** buffer overflow detected ***: terminated rsync: connection unexpectedly closed (34 bytes received so far) [sender] rsync error: error in rsync protocol data stream (code 12) at io.c(231) [sender=3.2.7] ** Changed in: rsync (Ubuntu) Importance: Undecided => High ** Changed in: rsync (Ubuntu) Importance: High => Critical -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to rsync in Ubuntu. https://bugs.launchpad.net/bugs/2060967 Title: noble/rsync buffer overflow detected Status in rsync package in Ubuntu: In Progress Status in rsync source package in Focal: Invalid Status in rsync source package in Jammy: Invalid Status in rsync source package in Mantic: Invalid Bug description: Hi, running the following test case in a current (today/2024-04-11) Noble install leads to a "buffer overflow detected": $ rsync -F --delete-after --archive /etc/fstab 127.0.0.1:/tmp/ *** buffer overflow detected ***: terminated rsync: connection unexpectedly closed (11 bytes received so far) [sender] rsync error: error in rsync protocol data stream (code 12) at io.c(231) [sender=3.2.7] Original use case for the above striped down rsync options is the ansible module "synchronize". ProblemType: Bug ApportVersion: 2.28.0-0ubuntu1 Architecture: amd64 CasperMD5CheckResult: unknown Date: Thu Apr 11 14:38:46 2024 Dependencies: gcc-14-base 14-20240330-1ubuntu2 init-system-helpers 1.66ubuntu1 libacl1 2.3.2-1 libc6 2.39-0ubuntu8 libgcc-s1 14-20240330-1ubuntu2 libidn2-0 2.3.7-2 liblz4-1 1.9.4-1 libpopt0 1.19+dfsg-1 libunistring5 1.1-2 libxxhash0 0.8.2-2 libzstd1 1.5.5+dfsg2-2 lsb-base 11.6 sysvinit-utils 3.08-6ubuntu2 zlib1g 1:1.3.dfsg-3.1ubuntu2 DistroRelease: Ubuntu 24.04 Package: rsync 3.2.7-1build2 PackageArchitecture: amd64 ProcCpuinfoMinimal: processor: 0 vendor_id: GenuineIntel cpu family : 6 model: 60 model name : Intel Core Processor (Haswell, no TSX, IBRS) stepping : 1 microcode: 0x1 cpu MHz : 2397.222 cache size : 16384 KB physical id : 0 siblings : 1 core id : 0 cpu cores: 1 apicid : 0 initial apicid : 0 fpu : yes fpu_exception: yes cpuid level : 13 wp : yes flags: fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov pat pse36 clflush mmx fxsr sse sse2 syscall nx rdtscp lm constant_tsc rep_good nopl xtopology cpuid tsc_known_freq pni pclmulqdq ssse3 fma cx16 pcid sse4_1 sse4_2 x2apic movbe popcnt tsc_deadline_timer aes xsave avx f16c rdrand hypervisor lahf_lm abm cpuid_fault pti ssbd ibrs ibpb fsgsbase bmi1 avx2 smep bmi2 erms invpcid xsaveopt arat md_clear bugs : cpu_meltdown spectre_v1 spectre_v2 spec_store_bypass l1tf mds swapgs itlb_multihit srbds mmio_unknown bogomips : 4794.44 clflush size : 64 cache_alignment : 64 address sizes: 40 bits physical, 48 bits virtual power management: ProcEnviron: LANG=en_US.UTF-8 PATH=(custom, no user) SHELL=/bin/bash TERM=xterm-256color XDG_RUNTIME_DIR= ProcVersionSignature: Ubuntu 6.8.0-22.22-generic 6.8.1 SourcePackage: rsync Tags: noble Uname: Linux 6.8.0-22-generic x86_64 UpgradeStatus: No upgrade log present (probably fresh install) _MarkForUpload: True To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/rsync/+bug/2060967/+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 2063257] [NEW] Noble: default pam config for login tries do load non-existent pam_lastlog.so
Public bug reported: pam_lastlog.so was dropped by upstream in 1.5.3[1][4]. It's still there in the code, but not built by default. And indeed, in noble (1.5.3) we don't have it, while mantic (1.5.2) does. This does not prevent console logins, but generates an error in the logs: Apr 23 20:02:09 n1 login[835]: PAM unable to dlopen(pam_lastlog.so): /usr/lib/security/pam_lastlog.so: cannot open shared object file: No such file or directory Apr 23 20:02:09 n1 login[835]: PAM adding faulty module: pam_lastlog.so Debian's shadow package is also still shipping this config[2]. If you think we should re-enable pam_lastlog, then this becomes a bug in the src:pam package, but keep in mind upstream is keen on removing it, and we might be better off switching to an alternative, perhaps pam_lastlog2[3]. 1. https://github.com/linux-pam/linux-pam/blob/cec36a8cd2c69cc87eacc21da471334fbef128ee/NEWS#L65 2. https://salsa.debian.org/debian/shadow/-/blob/master/debian/login.pam?ref_type=heads#L82 3. https://wiki.debian.org/PamLastlog2 4. https://github.com/linux-pam/linux-pam/commit/357a4ddbe9b4b10ebd805d2af3e32f3ead5b8816 ** Affects: shadow (Ubuntu) Importance: Undecided Status: New ** Affects: shadow (Ubuntu Noble) Importance: Undecided Status: New ** Affects: shadow (Debian) Importance: Unknown Status: Unknown ** Summary changed: - Default pam config for login tries do load non-existent pam module pam_lastlog.so + Noble: default pam config for login tries do load non-existent pam module pam_lastlog.so ** Also affects: shadow (Ubuntu Noble) Importance: Undecided Status: New ** Summary changed: - Noble: default pam config for login tries do load non-existent pam module pam_lastlog.so + Noble: default pam config for login tries do load non-existent pam_lastlog.so ** Description changed: pam_lastlog.so was dropped by upstream in 1.5.3[1]. It's still there in the code, but not built by default. And indeed, in noble (1.5.3) we don't have it, while mantic (1.5.2) does. - This does not prevent console logins, but generates an error in the logs: Apr 23 20:02:09 n1 login[835]: PAM unable to dlopen(pam_lastlog.so): /usr/lib/security/pam_lastlog.so: cannot open shared object file: No such file or directory Apr 23 20:02:09 n1 login[835]: PAM adding faulty module: pam_lastlog.so + Debian's shadow package is also still shipping this config[2]. - Debian's shadow package is also still shipping this config[2]. + If you think we should re-enable pam_lastlog, then this becomes a bug in + the src:pam package, but keep in mind upstream is keen on removing it, + and we might be better off switching to an alternative, perhaps + pam_lastlog2[3]. 1. https://github.com/linux-pam/linux-pam/blob/cec36a8cd2c69cc87eacc21da471334fbef128ee/NEWS#L65 2. https://salsa.debian.org/debian/shadow/-/blob/master/debian/login.pam?ref_type=heads#L82 + 3. https://wiki.debian.org/PamLastlog2 ** Bug watch added: Debian Bug tracker #1068229 https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1068229 ** Also affects: shadow (Debian) via https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1068229 Importance: Unknown Status: Unknown ** Description changed: - pam_lastlog.so was dropped by upstream in 1.5.3[1]. It's still there in - the code, but not built by default. + pam_lastlog.so was dropped by upstream in 1.5.3[1][4]. It's still there + in the code, but not built by default. And indeed, in noble (1.5.3) we don't have it, while mantic (1.5.2) does. This does not prevent console logins, but generates an error in the logs: Apr 23 20:02:09 n1 login[835]: PAM unable to dlopen(pam_lastlog.so): /usr/lib/security/pam_lastlog.so: cannot open shared object file: No such file or directory Apr 23 20:02:09 n1 login[835]: PAM adding faulty module: pam_lastlog.so Debian's shadow package is also still shipping this config[2]. If you think we should re-enable pam_lastlog, then this becomes a bug in the src:pam package, but keep in mind upstream is keen on removing it, and we might be better off switching to an alternative, perhaps pam_lastlog2[3]. - 1. https://github.com/linux-pam/linux-pam/blob/cec36a8cd2c69cc87eacc21da471334fbef128ee/NEWS#L65 2. https://salsa.debian.org/debian/shadow/-/blob/master/debian/login.pam?ref_type=heads#L82 3. https://wiki.debian.org/PamLastlog2 + 4. https://github.com/linux-pam/linux-pam/commit/357a4ddbe9b4b10ebd805d2af3e32f3ead5b8816 -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to shadow in Ubuntu. https://bugs.launchpad.net/bugs/2063257 Title: Noble: default pam config for login tries do load non-existent pam_lastlog.so Status in shadow package in Ubuntu: New Status in shadow source package in Noble: New Status in shadow package in Debian: Unknown Bug description: pam_lastlog.so was dropped by
[Touch-packages] [Bug 2063381] Re: NFS Client can't mount via NFS version 4.0
Ryan, I think you are experiencing https://bugs.launchpad.net/ubuntu/+source/nfs-utils/+bug/2059197 which is a regression on focal from a previous update that also tried to address the version negotiation. There is a new nfs-utils package in focal-proposed to address that, would you mind trying it out? The instructions are in that bug. ** Package changed: util-linux (Ubuntu) => nfs-utils (Ubuntu) ** Changed in: nfs-utils (Ubuntu) Status: New => Incomplete -- 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/2063381 Title: NFS Client can't mount via NFS version 4.0 Status in nfs-utils package in Ubuntu: Incomplete Bug description: When specifying vers=4.0 or nfsvers=4.0 in NFSv4 mount options, the client ends up using version 4.2 instead. This option seems to be ignored. This happens with pam_mount and manual mount. We have been using pam_mount for years with the option vers=4.0, but now it appears to be broken. Just recently noticed this is happening while troubleshooting root causes of some other issues on our servers. Test: mounting manually with option: minorversion=0, the client does not mount, no errors are seen with -vvv, no errors in logs either, it just fails silently. With pam_mount this option fails as well but is logged as mount failed into auth.log ex: Apr 24 17:15:22 servername sshd[666278]: (pam_mount.c:522): mount of /mnt/nfs/home/admin_username failed other nfs4 mount options we are using: sec=krb5p,noatime,nodiratime,async I see that something similar was fixed in autofs, but this is not autofs related, as we do not use it. https://bugs.launchpad.net/bugs/1818121 Found a similar [oracle] issue but cannot read it= https://support.oracle.com/knowledge/Oracle%20Linux%20and%20Virtualization/2528012_1.html --- Description:Ubuntu 20.04.6 LTS Release:20.04 --- util-linux: Installed: 2.34-0.1ubuntu9.6 Candidate: 2.34-0.1ubuntu9.6 Version table: *** 2.34-0.1ubuntu9.6 500 500 http://us.archive.ubuntu.com/ubuntu focal-updates/main amd64 Packages 500 http://us.archive.ubuntu.com/ubuntu focal-security/main amd64 Packages 100 /var/lib/dpkg/status 2.34-0.1ubuntu9 500 500 http://us.archive.ubuntu.com/ubuntu focal/main amd64 Packages mount: Installed: 2.34-0.1ubuntu9.6 Candidate: 2.34-0.1ubuntu9.6 Version table: *** 2.34-0.1ubuntu9.6 500 500 http://us.archive.ubuntu.com/ubuntu focal-updates/main amd64 Packages 500 http://us.archive.ubuntu.com/ubuntu focal-security/main amd64 Packages 100 /var/lib/dpkg/status 2.34-0.1ubuntu9 500 500 http://us.archive.ubuntu.com/ubuntu focal/main amd64 Packages nfs-common: Installed: 1:1.3.4-2.5ubuntu3.6 Candidate: 1:1.3.4-2.5ubuntu3.6 Version table: *** 1:1.3.4-2.5ubuntu3.6 500 500 http://us.archive.ubuntu.com/ubuntu focal-updates/main amd64 Packages 100 /var/lib/dpkg/status 1:1.3.4-2.5ubuntu3.3 500 500 http://us.archive.ubuntu.com/ubuntu focal-security/main amd64 Packages 1:1.3.4-2.5ubuntu3 500 500 http://us.archive.ubuntu.com/ubuntu focal/main amd64 Packages To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/nfs-utils/+bug/2063381/+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 827151] Re: Annoying log message "DIGEST-MD5 common mech free"
** Changed in: cyrus-sasl2 (Ubuntu Jammy) Status: In Progress => Fix Released ** Changed in: cyrus-sasl2 (Ubuntu Jammy) Status: Fix Released => Confirmed ** Changed in: cyrus-sasl2 (Ubuntu) Status: Triaged => Fix Released -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to cyrus-sasl2 in Ubuntu. https://bugs.launchpad.net/bugs/827151 Title: Annoying log message "DIGEST-MD5 common mech free" Status in Cyrus-sasl2: Fix Released Status in cyrus-sasl2 package in Ubuntu: Fix Released Status in cyrus-sasl2 source package in Trusty: Won't Fix Status in cyrus-sasl2 source package in Xenial: Incomplete Status in cyrus-sasl2 source package in Yakkety: Fix Released Status in cyrus-sasl2 source package in Focal: Triaged Status in cyrus-sasl2 source package in Impish: Triaged Status in cyrus-sasl2 source package in Jammy: Confirmed Status in cyrus-sasl2 package in Debian: Fix Released Bug description: I recently updated the libsasl2-modules to 2.1.24~rc1.dfsg1+cvs2011-05-23-4ubuntu1 in oneiric. That triggered the bug also described in Debian here: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=631932 The annoying message is logged in auth.log. In my case, it is associated with svnserve: svnserve: DIGEST-MD5 common mech free I'm not exactly sure what action triggers the message, but I can investigate more if required. $ lsb_release -rd Description:Ubuntu oneiric (development branch) Release:11.10 To manage notifications about this bug go to: https://bugs.launchpad.net/cyrus-sasl2/+bug/827151/+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 827151] Re: Annoying log message "DIGEST-MD5 common mech free"
Ok, specifically this log message is fixed in 2.1.28: DIGEST-MD5 common mech free Via https://git.launchpad.net/ubuntu/+source/cyrus- sasl2/tree/debian/patches/0001-plugins-digestmd5-Remove-debug-log-mech- free.patch That patch is just in Ubuntu Kinetic for now. But I still see a lot of DIGEST-MD5 noise in the logs when I just attempt a DIGEST-MD5 auth: May 25 19:15:01 k1-sasl-digest ldapwhoami: DIGEST-MD5 client step 2 May 25 19:15:01 k1-sasl-digest ldapwhoami: DIGEST-MD5 parse_server_challenge() May 25 19:15:01 k1-sasl-digest ldapwhoami: DIGEST-MD5 ask_user_info() May 25 19:15:03 k1-sasl-digest ldapwhoami: DIGEST-MD5 client step 2 May 25 19:15:03 k1-sasl-digest ldapwhoami: DIGEST-MD5 ask_user_info() May 25 19:15:03 k1-sasl-digest ldapwhoami: DIGEST-MD5 make_client_response() May 25 19:15:03 k1-sasl-digest ldapwhoami: DIGEST-MD5 create_layer_keys() May 25 19:15:03 k1-sasl-digest ldapwhoami: DIGEST-MD5 client mech dispose May 25 19:15:03 k1-sasl-digest ldapwhoami: DIGEST-MD5 common mech dispose All except the "common mech free" one ;) The fix for that was committed 22 days ago: https://github.com/cyrusimap/cyrus- sasl/commit/cb549ef71c5bb646fe583697ebdcaba93267a237 And also affects kinetic. I'll reopen this bug then, as it's the same type of noise in the same plugin. ** Changed in: cyrus-sasl2 (Ubuntu) Status: Fix Released => Triaged -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to cyrus-sasl2 in Ubuntu. https://bugs.launchpad.net/bugs/827151 Title: Annoying log message "DIGEST-MD5 common mech free" Status in Cyrus-sasl2: Fix Released Status in cyrus-sasl2 package in Ubuntu: Triaged Status in cyrus-sasl2 source package in Trusty: Won't Fix Status in cyrus-sasl2 source package in Xenial: Incomplete Status in cyrus-sasl2 source package in Yakkety: Fix Released Status in cyrus-sasl2 source package in Focal: Triaged Status in cyrus-sasl2 source package in Impish: Triaged Status in cyrus-sasl2 source package in Jammy: Confirmed Status in cyrus-sasl2 package in Debian: Fix Released Bug description: I recently updated the libsasl2-modules to 2.1.24~rc1.dfsg1+cvs2011-05-23-4ubuntu1 in oneiric. That triggered the bug also described in Debian here: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=631932 The annoying message is logged in auth.log. In my case, it is associated with svnserve: svnserve: DIGEST-MD5 common mech free I'm not exactly sure what action triggers the message, but I can investigate more if required. $ lsb_release -rd Description:Ubuntu oneiric (development branch) Release:11.10 To manage notifications about this bug go to: https://bugs.launchpad.net/cyrus-sasl2/+bug/827151/+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 827151] Re: Annoying log message "DIGEST-MD5 common mech free"
I applied that patch in cyrus-sasl2 2.1.28 from kinetic, and it did get rid of the other DIGEST-MD5 messages. But I'm having difficulties in finding a client sasl app where I can set log_level to see if with a high log_level I can restore that logging, to make sure it's working. I tried ldapwhoami from openldap, smtptest from cyrus, and sasl-sample- client from cyrus-sasl2, but they don't seem to read a sasl-specific config file (like in /etc/sasl2/.conf) where I could set "log_level: 7" for example. I confirmed with strace that they don't even try to open such a config file. I asked upstream for some guidance, but it's probably just a minor thing. I'll give it some time and then land this, or wait for 2.1.29 which has this committed. -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to cyrus-sasl2 in Ubuntu. https://bugs.launchpad.net/bugs/827151 Title: Annoying log message "DIGEST-MD5 common mech free" Status in Cyrus-sasl2: Fix Released Status in cyrus-sasl2 package in Ubuntu: Triaged Status in cyrus-sasl2 source package in Trusty: Won't Fix Status in cyrus-sasl2 source package in Xenial: Incomplete Status in cyrus-sasl2 source package in Yakkety: Fix Released Status in cyrus-sasl2 source package in Focal: Triaged Status in cyrus-sasl2 source package in Impish: Triaged Status in cyrus-sasl2 source package in Jammy: Confirmed Status in cyrus-sasl2 package in Debian: Fix Released Bug description: I recently updated the libsasl2-modules to 2.1.24~rc1.dfsg1+cvs2011-05-23-4ubuntu1 in oneiric. That triggered the bug also described in Debian here: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=631932 The annoying message is logged in auth.log. In my case, it is associated with svnserve: svnserve: DIGEST-MD5 common mech free I'm not exactly sure what action triggers the message, but I can investigate more if required. $ lsb_release -rd Description:Ubuntu oneiric (development branch) Release:11.10 To manage notifications about this bug go to: https://bugs.launchpad.net/cyrus-sasl2/+bug/827151/+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 827151] Re: Annoying log message "DIGEST-MD5 common mech free"
Got a reply[1] from upstream, and this is expected. I'll go ahead and MP this patch. 1. https://github.com/cyrusimap/cyrus- sasl/commit/cb549ef71c5bb646fe583697ebdcaba93267a237#r74534186 -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to cyrus-sasl2 in Ubuntu. https://bugs.launchpad.net/bugs/827151 Title: Annoying log message "DIGEST-MD5 common mech free" Status in Cyrus-sasl2: Fix Released Status in cyrus-sasl2 package in Ubuntu: Triaged Status in cyrus-sasl2 source package in Trusty: Won't Fix Status in cyrus-sasl2 source package in Xenial: Incomplete Status in cyrus-sasl2 source package in Yakkety: Fix Released Status in cyrus-sasl2 source package in Focal: Triaged Status in cyrus-sasl2 source package in Impish: Triaged Status in cyrus-sasl2 source package in Jammy: Confirmed Status in cyrus-sasl2 package in Debian: Fix Released Bug description: I recently updated the libsasl2-modules to 2.1.24~rc1.dfsg1+cvs2011-05-23-4ubuntu1 in oneiric. That triggered the bug also described in Debian here: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=631932 The annoying message is logged in auth.log. In my case, it is associated with svnserve: svnserve: DIGEST-MD5 common mech free I'm not exactly sure what action triggers the message, but I can investigate more if required. $ lsb_release -rd Description:Ubuntu oneiric (development branch) Release:11.10 To manage notifications about this bug go to: https://bugs.launchpad.net/cyrus-sasl2/+bug/827151/+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 827151] Re: Annoying log message "DIGEST-MD5 common mech free"
** Changed in: cyrus-sasl2 (Ubuntu Jammy) Assignee: Andreas Hasenack (ahasenack) => (unassigned) ** Changed in: cyrus-sasl2 (Ubuntu Jammy) Status: Confirmed => Triaged ** Changed in: cyrus-sasl2 (Ubuntu) Assignee: (unassigned) => Andreas Hasenack (ahasenack) -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to cyrus-sasl2 in Ubuntu. https://bugs.launchpad.net/bugs/827151 Title: Annoying log message "DIGEST-MD5 common mech free" Status in Cyrus-sasl2: Fix Released Status in cyrus-sasl2 package in Ubuntu: Triaged Status in cyrus-sasl2 source package in Trusty: Won't Fix Status in cyrus-sasl2 source package in Xenial: Incomplete Status in cyrus-sasl2 source package in Yakkety: Fix Released Status in cyrus-sasl2 source package in Focal: Triaged Status in cyrus-sasl2 source package in Impish: Triaged Status in cyrus-sasl2 source package in Jammy: Triaged Status in cyrus-sasl2 package in Debian: Fix Released Bug description: I recently updated the libsasl2-modules to 2.1.24~rc1.dfsg1+cvs2011-05-23-4ubuntu1 in oneiric. That triggered the bug also described in Debian here: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=631932 The annoying message is logged in auth.log. In my case, it is associated with svnserve: svnserve: DIGEST-MD5 common mech free I'm not exactly sure what action triggers the message, but I can investigate more if required. $ lsb_release -rd Description:Ubuntu oneiric (development branch) Release:11.10 To manage notifications about this bug go to: https://bugs.launchpad.net/cyrus-sasl2/+bug/827151/+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 1976508] [NEW] sasl/gssapi tests are disabled due to missing build-deps
Public bug reported: Openldap has an extensive test suite that is run during build. The sasl/gssapi tests are being skipped because of missing build dependencies: > Starting test077-sasl-gssapi for mdb... running defines.sh Starting KDC for SASL/GSSAPI tests... Trying Heimdal KDC... Trying MIT KDC... No KDC available, skipping GSSAPI tests > test077-sasl-gssapi completed OK for mdb after 0 seconds. With this diff, the test was finally run: --- a/debian/control +++ b/debian/control @@ -22,7 +22,12 @@ Build-Depends: debhelper-compat (= 12), perl:any, pkg-config (>= 0.29), po-debconf, - unixodbc-dev + unixodbc-dev , + krb5-admin-server, + krb5-user, + krb5-kdc, + libsasl2-modules-gssapi-mit, + sasl2-bin Build-Conflicts: libbind-dev, bind-dev, autoconf2.13 Standards-Version: 4.6.0 Homepage: https://www.openldap.org/ Result: > Starting test077-sasl-gssapi for mdb... > running defines.sh Starting KDC for SASL/GSSAPI tests... Trying Heimdal KDC... Trying MIT KDC... Configuring slapd... Starting ldap:/// slapd on TCP/IP port 9011 and ldaps:/// slapd on 9012... Using ldapsearch to check that slapd is running... supportedSASLMechanisms: GSSAPI Using ldapwhoami with SASL/GSSAPI: success Validating mapped SASL/GSSAPI ID: success Using ldapwhoami with SASL/GSSAPI with start-tls: success Using ldapwhoami with SASL/GSSAPI with ldaps: success SASL has no channel-binding support in GSSAPI, test skipped > Test succeeded > > test077-sasl-gssapi completed OK for mdb after 2 seconds. About the missing channel binding support, I filed bug #1976507 against cyrus-sasl2. ** Affects: openldap (Ubuntu) Importance: Undecided Status: New -- 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/1976508 Title: sasl/gssapi tests are disabled due to missing build-deps Status in openldap package in Ubuntu: New Bug description: Openldap has an extensive test suite that is run during build. The sasl/gssapi tests are being skipped because of missing build dependencies: > Starting test077-sasl-gssapi for mdb... running defines.sh Starting KDC for SASL/GSSAPI tests... Trying Heimdal KDC... Trying MIT KDC... No KDC available, skipping GSSAPI tests > test077-sasl-gssapi completed OK for mdb after 0 seconds. With this diff, the test was finally run: --- a/debian/control +++ b/debian/control @@ -22,7 +22,12 @@ Build-Depends: debhelper-compat (= 12), perl:any, pkg-config (>= 0.29), po-debconf, - unixodbc-dev + unixodbc-dev , + krb5-admin-server, + krb5-user, + krb5-kdc, + libsasl2-modules-gssapi-mit, + sasl2-bin Build-Conflicts: libbind-dev, bind-dev, autoconf2.13 Standards-Version: 4.6.0 Homepage: https://www.openldap.org/ Result: > Starting test077-sasl-gssapi for mdb... running defines.sh Starting KDC for SASL/GSSAPI tests... Trying Heimdal KDC... Trying MIT KDC... Configuring slapd... Starting ldap:/// slapd on TCP/IP port 9011 and ldaps:/// slapd on 9012... Using ldapsearch to check that slapd is running... supportedSASLMechanisms: GSSAPI Using ldapwhoami with SASL/GSSAPI: success Validating mapped SASL/GSSAPI ID: success Using ldapwhoami with SASL/GSSAPI with start-tls: success Using ldapwhoa
[Touch-packages] [Bug 1976507] [NEW] Missing channel binding for gssapi
Public bug reported: The cyrus-sasl2 package in Ubuntu is still lacking the channel binding support in gssapi, which was/is required by a certain patch level of Windows Active Directory. I have an old ppa[1] of when I was working on this, before I was moved to other projects. The patches I used there seem to be committed upstream now, just not yet part of a release. And there seem to be some follow-up commits as well. Once this is fixed and tested, it's also probably a good SRU candidate. 1. https://launchpad.net/~ahasenack/+archive/ubuntu/sasl-channel-binding ** Affects: cyrus-sasl2 (Ubuntu) Importance: Medium Status: Triaged -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to cyrus-sasl2 in Ubuntu. https://bugs.launchpad.net/bugs/1976507 Title: Missing channel binding for gssapi Status in cyrus-sasl2 package in Ubuntu: Triaged Bug description: The cyrus-sasl2 package in Ubuntu is still lacking the channel binding support in gssapi, which was/is required by a certain patch level of Windows Active Directory. I have an old ppa[1] of when I was working on this, before I was moved to other projects. The patches I used there seem to be committed upstream now, just not yet part of a release. And there seem to be some follow-up commits as well. Once this is fixed and tested, it's also probably a good SRU candidate. 1. https://launchpad.net/~ahasenack/+archive/ubuntu/sasl-channel- binding To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/cyrus-sasl2/+bug/1976507/+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 1976509] [NEW] totp test not run, claims python env not found
Public bug reported: > Starting test081-totp for mdb... running defines.sh ../../../tests/scripts/test081-totp: 31: cannot create /home/ubuntu/git/packages/openldap/openldap/debian/build/tests/testrun/test.out: Directory nonexistent ../../../tests/scripts/test081-totp: 31: cannot create /home/ubuntu/git/packages/openldap/openldap/debian/build/tests/testrun/test.out: Directory nonexistent ../../../tests/scripts/test081-totp: 31: cannot create /home/ubuntu/git/packages/openldap/openldap/debian/build/tests/testrun/test.out: Directory nonexistent ../../../tests/scripts/test081-totp: 31: cannot create /home/ubuntu/git/packages/openldap/openldap/debian/build/tests/testrun/test.out: Directory nonexistent ../../../tests/scripts/test081-totp: 31: cannot create /home/ubuntu/git/packages/openldap/openldap/debian/build/tests/testrun/test.out: Directory nonexistent Useable Python environment not found, skipping test > test081-totp completed OK for mdb after 0 seconds. The python env error might be misleading, and perhaps is caused by the other errors prior to that message. This needs a bit of troubleshooting. ** Affects: openldap (Ubuntu) Importance: Undecided Status: New -- 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/1976509 Title: totp test not run, claims python env not found Status in openldap package in Ubuntu: New Bug description: > Starting test081-totp for mdb... running defines.sh ../../../tests/scripts/test081-totp: 31: cannot create /home/ubuntu/git/packages/openldap/openldap/debian/build/tests/testrun/test.out: Directory nonexistent ../../../tests/scripts/test081-totp: 31: cannot create /home/ubuntu/git/packages/openldap/openldap/debian/build/tests/testrun/test.out: Directory nonexistent ../../../tests/scripts/test081-totp: 31: cannot create /home/ubuntu/git/packages/openldap/openldap/debian/build/tests/testrun/test.out: Directory nonexistent ../../../tests/scripts/test081-totp: 31: cannot create /home/ubuntu/git/packages/openldap/openldap/debian/build/tests/testrun/test.out: Directory nonexistent ../../../tests/scripts/test081-totp: 31: cannot create /home/ubuntu/git/packages/openldap/openldap/debian/build/tests/testrun/test.out: Directory nonexistent Useable Python environment not found, skipping test > test081-totp completed OK for mdb after 0 seconds. The python env error might be misleading, and perhaps is caused by the other errors prior to that message. This needs a bit of troubleshooting. To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/openldap/+bug/1976509/+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 1976507] Re: Missing channel binding for gssapi
*** This bug is a duplicate of bug 1912256 *** https://bugs.launchpad.net/bugs/1912256 ** This bug has been marked a duplicate of bug 1912256 Missing channel binding prevents authentication to ActiveDirectory -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to cyrus-sasl2 in Ubuntu. https://bugs.launchpad.net/bugs/1976507 Title: Missing channel binding for gssapi Status in cyrus-sasl2 package in Ubuntu: Triaged Bug description: The cyrus-sasl2 package in Ubuntu is still lacking the channel binding support in gssapi, which was/is required by a certain patch level of Windows Active Directory. I have an old ppa[1] of when I was working on this, before I was moved to other projects. The patches I used there seem to be committed upstream now, just not yet part of a release. And there seem to be some follow-up commits as well. Once this is fixed and tested, it's also probably a good SRU candidate. 1. https://launchpad.net/~ahasenack/+archive/ubuntu/sasl-channel- binding To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/cyrus-sasl2/+bug/1976507/+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 1977751] [NEW] Merge ust from Debian for 22.10
Public bug reported: New minor upstream release available: 2.13.3-1 2022-06-03 (National Repeat Day) (National Repeat Day) lttng-ust 2.13.3 * Document ust lock async-signal-safety * Fix: don't use strerror() from ust lock nocheck * Fix: remove non-async-signal-safe fflush from ERR() * Fix: Pointers are rejected by integer element compile time assertion for array and sequence * Fix: statedump: invalid read during iter_end * Fix: bytecode interpreter context_get_index() leaves byte order uninitialized ust (2.13.3-1) unstable; urgency=medium * [92abdd1] New upstream version 2.13.3 -- Michael Jeanson Fri, 03 Jun 2022 16:37:11 -0400 ** Affects: ust (Ubuntu) Importance: Undecided Assignee: Andreas Hasenack (ahasenack) Status: New ** Tags: needs-merge ** Changed in: ust (Ubuntu) Assignee: (unassigned) => Andreas Hasenack (ahasenack) -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to ust in Ubuntu. https://bugs.launchpad.net/bugs/1977751 Title: Merge ust from Debian for 22.10 Status in ust package in Ubuntu: New Bug description: New minor upstream release available: 2.13.3-1 2022-06-03 (National Repeat Day) (National Repeat Day) lttng-ust 2.13.3 * Document ust lock async-signal-safety * Fix: don't use strerror() from ust lock nocheck * Fix: remove non-async-signal-safe fflush from ERR() * Fix: Pointers are rejected by integer element compile time assertion for array and sequence * Fix: statedump: invalid read during iter_end * Fix: bytecode interpreter context_get_index() leaves byte order uninitialized ust (2.13.3-1) unstable; urgency=medium * [92abdd1] New upstream version 2.13.3 -- Michael Jeanson Fri, 03 Jun 2022 16:37:11 -0400 To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/ust/+bug/1977751/+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 1647285] Re: SSL trust not system-wide
Related: https://bugs.launchpad.net/ubuntu/+source/crypto- policies/+bug/1926664 (I might create a task here for crypto-policies and close the bug above) -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to ca-certificates in Ubuntu. https://bugs.launchpad.net/bugs/1647285 Title: SSL trust not system-wide Status in ca-certificates package in Ubuntu: Confirmed Status in firefox package in Ubuntu: Confirmed Status in nss package in Ubuntu: Confirmed Status in p11-kit package in Ubuntu: Fix Released Status in sssd package in Ubuntu: Confirmed Status in thunderbird package in Ubuntu: Confirmed Bug description: When I install a corporate CA trust root with update-ca-certificates, it doesn't seem to work everywhere. Various things like Firefox, Evolution, Chrome, etc. all fail to trust the newly-installed trusted CA. This ought to work, and does on other distributions. In p11-kit there is a module p11-kit-trust.so which can be used as a drop-in replacement for NSS's own libnssckbi.so trust root module, but which reads from the system's configured trust setup instead of the hard- coded version. This allows us to install the corporate CAs just once, and then file a bug against any package that *doesn't* then trust them. See https://fedoraproject.org/wiki/Features/SharedSystemCertificates for some of the historical details from when this feature was first implemented, but this is all now supported upstream and not at all distribution-specific. There shouldn't be any significant work required; it's mostly just a case of configuring and building it to make use of this functionality. (With 'alternatives' to let you substitute p11-kit-trust.so for the original NSS libnssckbi.so, etc.) To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/ca-certificates/+bug/1647285/+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 1970634] Re: FTBFS: mariadb fails to start due to low MEMLOCK limit
** Also affects: systemd (Ubuntu Jammy) Importance: Undecided Status: New ** Also affects: mariadb-10.6 (Ubuntu Jammy) Importance: Undecided Status: New ** Changed in: mariadb-10.6 (Ubuntu Jammy) Assignee: (unassigned) => Andreas Hasenack (ahasenack) ** Changed in: mariadb-10.6 (Ubuntu Jammy) Status: New => Triaged ** Changed in: mariadb-10.6 (Ubuntu Jammy) Importance: Undecided => High -- 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/1970634 Title: FTBFS: mariadb fails to start due to low MEMLOCK limit Status in mariadb-10.6 package in Ubuntu: Fix Released Status in systemd package in Ubuntu: Confirmed Status in mariadb-10.6 source package in Jammy: Triaged Status in systemd source package in Jammy: New Bug description: ahasenack: IIRC, originally Launchpad was FTBFSing on mariadb that included io_uring support because upstream were doing a build time test for io_uring (and I think still are), which is wrong because it should be done at runtime since the lack of io_uring availablity at build time doesn't tell us about its availablity at runtime. But then the Launchpad builders got updated to a newer release and therefore a newer kernel that supported it. AIUI, that's how we ended up with a successful build in the Jammy release pocket (of 10.6). I think the lp builders are using the focal hwe kernel 5.4.0-something let me check that build log But then something changed that caused this current FTBFS, and I haven't tracked down what that is. hm, both are 10.6.7 release and proposed What puzzles me is that if the root cause is a memlock rlimit issue then why did it work before? So since there's a contradiction somewhere, maybe one or more of my "facts" above is wrong. this is the current failure 2022-04-14 8:11:49 0 [Warning] mariadbd: io_uring_queue_init() failed with ENOMEM: try larger memory locked limit, ulimit -l, or https://mariadb.com/kb/en/systemd/#configuring-limitmemlock under systemd (262144 bytes required) and ulimit -l confirms that the limit is lower Max locked memory 6553665536 bytes just 64kbytes Yeah but then how did the release pocket build work? either the limit was different back then or ... stuff To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/mariadb-10.6/+bug/1970634/+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 1970634] Re: FTBFS: mariadb fails to start due to low MEMLOCK limit
** Changed in: systemd (Ubuntu Jammy) Assignee: (unassigned) => Andreas Hasenack (ahasenack) ** Changed in: systemd (Ubuntu Jammy) Status: New => In Progress ** Changed in: systemd (Ubuntu Jammy) Importance: Undecided => High -- 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/1970634 Title: FTBFS: mariadb fails to start due to low MEMLOCK limit Status in mariadb-10.6 package in Ubuntu: Fix Released Status in systemd package in Ubuntu: Confirmed Status in mariadb-10.6 source package in Jammy: Triaged Status in systemd source package in Jammy: In Progress Bug description: ahasenack: IIRC, originally Launchpad was FTBFSing on mariadb that included io_uring support because upstream were doing a build time test for io_uring (and I think still are), which is wrong because it should be done at runtime since the lack of io_uring availablity at build time doesn't tell us about its availablity at runtime. But then the Launchpad builders got updated to a newer release and therefore a newer kernel that supported it. AIUI, that's how we ended up with a successful build in the Jammy release pocket (of 10.6). I think the lp builders are using the focal hwe kernel 5.4.0-something let me check that build log But then something changed that caused this current FTBFS, and I haven't tracked down what that is. hm, both are 10.6.7 release and proposed What puzzles me is that if the root cause is a memlock rlimit issue then why did it work before? So since there's a contradiction somewhere, maybe one or more of my "facts" above is wrong. this is the current failure 2022-04-14 8:11:49 0 [Warning] mariadbd: io_uring_queue_init() failed with ENOMEM: try larger memory locked limit, ulimit -l, or https://mariadb.com/kb/en/systemd/#configuring-limitmemlock under systemd (262144 bytes required) and ulimit -l confirms that the limit is lower Max locked memory 6553665536 bytes just 64kbytes Yeah but then how did the release pocket build work? either the limit was different back then or ... stuff To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/mariadb-10.6/+bug/1970634/+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 1970634] Re: FTBFS: mariadb fails to start due to low MEMLOCK limit
Hi Michal, I'm going over the test procedure for this bug and turns out the scenario where we encountered it is a bit convoluted, specially for users: you need to be running a 5.4 kernel on a jammy userspace (jammy itself has 5.15 kernel). Could you please elaborate on how this bug affects you? Are you included in the above scenario, or is it something else? -- 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/1970634 Title: FTBFS: mariadb fails to start due to low MEMLOCK limit Status in mariadb-10.6 package in Ubuntu: Fix Released Status in systemd package in Ubuntu: Confirmed Status in mariadb-10.6 source package in Jammy: Triaged Status in systemd source package in Jammy: In Progress Bug description: ahasenack: IIRC, originally Launchpad was FTBFSing on mariadb that included io_uring support because upstream were doing a build time test for io_uring (and I think still are), which is wrong because it should be done at runtime since the lack of io_uring availablity at build time doesn't tell us about its availablity at runtime. But then the Launchpad builders got updated to a newer release and therefore a newer kernel that supported it. AIUI, that's how we ended up with a successful build in the Jammy release pocket (of 10.6). I think the lp builders are using the focal hwe kernel 5.4.0-something let me check that build log But then something changed that caused this current FTBFS, and I haven't tracked down what that is. hm, both are 10.6.7 release and proposed What puzzles me is that if the root cause is a memlock rlimit issue then why did it work before? So since there's a contradiction somewhere, maybe one or more of my "facts" above is wrong. this is the current failure 2022-04-14 8:11:49 0 [Warning] mariadbd: io_uring_queue_init() failed with ENOMEM: try larger memory locked limit, ulimit -l, or https://mariadb.com/kb/en/systemd/#configuring-limitmemlock under systemd (262144 bytes required) and ulimit -l confirms that the limit is lower Max locked memory 6553665536 bytes just 64kbytes Yeah but then how did the release pocket build work? either the limit was different back then or ... stuff To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/mariadb-10.6/+bug/1970634/+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 1970634] Re: FTBFS: mariadb fails to start due to low MEMLOCK limit
I can't reproduce this bug anymore with the package currently in jammy (1:10.6.7-2ubuntu1): lxc launch ubuntu:focal f --vm lxc shell f lxd init # just hit enter for all questions lxc launch ubuntu:jammy j lxc shell j ulimit -l # confirm it's less than 256 apt update && apt install mariadb-server -y I wonder if it was just an interim issue in jammy's 1:10.6.7-3 package. I'm doing a test rebuild of 1:10.6.7-2ubuntu1 in jammy. -- 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/1970634 Title: FTBFS: mariadb fails to start due to low MEMLOCK limit Status in mariadb-10.6 package in Ubuntu: Fix Released Status in systemd package in Ubuntu: Confirmed Status in mariadb-10.6 source package in Jammy: Triaged Status in systemd source package in Jammy: In Progress Bug description: ahasenack: IIRC, originally Launchpad was FTBFSing on mariadb that included io_uring support because upstream were doing a build time test for io_uring (and I think still are), which is wrong because it should be done at runtime since the lack of io_uring availablity at build time doesn't tell us about its availablity at runtime. But then the Launchpad builders got updated to a newer release and therefore a newer kernel that supported it. AIUI, that's how we ended up with a successful build in the Jammy release pocket (of 10.6). I think the lp builders are using the focal hwe kernel 5.4.0-something let me check that build log But then something changed that caused this current FTBFS, and I haven't tracked down what that is. hm, both are 10.6.7 release and proposed What puzzles me is that if the root cause is a memlock rlimit issue then why did it work before? So since there's a contradiction somewhere, maybe one or more of my "facts" above is wrong. this is the current failure 2022-04-14 8:11:49 0 [Warning] mariadbd: io_uring_queue_init() failed with ENOMEM: try larger memory locked limit, ulimit -l, or https://mariadb.com/kb/en/systemd/#configuring-limitmemlock under systemd (262144 bytes required) and ulimit -l confirms that the limit is lower Max locked memory 6553665536 bytes just 64kbytes Yeah but then how did the release pocket build work? either the limit was different back then or ... stuff To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/mariadb-10.6/+bug/1970634/+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 1970634] Re: FTBFS: mariadb fails to start due to low MEMLOCK limit
Ok, a plain jammy rebuild in a launchpad ppa failed: 2022-06-17 14:18:27 0 [Warning] mariadbd: io_uring_queue_init() failed with ENOMEM: try larger memory locked limit, ulimit -l, or https://mariadb.com/kb/en/systemd/#configuring-limitmemlock under systemd (262144 bytes required) The binary package that is currently in jammy was probably rebuilt before the lto changes I'm guessing, because it's not affected by this. So I wonder how current jammy users could be affected by this (besides the rebuild). Let's see if Michal has something to say about my comment #15. -- 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/1970634 Title: FTBFS: mariadb fails to start due to low MEMLOCK limit Status in mariadb-10.6 package in Ubuntu: Fix Released Status in systemd package in Ubuntu: Confirmed Status in mariadb-10.6 source package in Jammy: Triaged Status in systemd source package in Jammy: In Progress Bug description: ahasenack: IIRC, originally Launchpad was FTBFSing on mariadb that included io_uring support because upstream were doing a build time test for io_uring (and I think still are), which is wrong because it should be done at runtime since the lack of io_uring availablity at build time doesn't tell us about its availablity at runtime. But then the Launchpad builders got updated to a newer release and therefore a newer kernel that supported it. AIUI, that's how we ended up with a successful build in the Jammy release pocket (of 10.6). I think the lp builders are using the focal hwe kernel 5.4.0-something let me check that build log But then something changed that caused this current FTBFS, and I haven't tracked down what that is. hm, both are 10.6.7 release and proposed What puzzles me is that if the root cause is a memlock rlimit issue then why did it work before? So since there's a contradiction somewhere, maybe one or more of my "facts" above is wrong. this is the current failure 2022-04-14 8:11:49 0 [Warning] mariadbd: io_uring_queue_init() failed with ENOMEM: try larger memory locked limit, ulimit -l, or https://mariadb.com/kb/en/systemd/#configuring-limitmemlock under systemd (262144 bytes required) and ulimit -l confirms that the limit is lower Max locked memory 6553665536 bytes just 64kbytes Yeah but then how did the release pocket build work? either the limit was different back then or ... stuff To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/mariadb-10.6/+bug/1970634/+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 1970634] Re: FTBFS: mariadb fails to start due to low MEMLOCK limit
I got a report on IRC that the existing jammy package of mariadb does exhibit this problem: (link will expire soon) https://storage.bhs.cloud.ovh.net/v1/AUTH_dcaab5e32b234d56b626f72581e3644c/zuul_opendev_logs_bd5/839585/23/check/kolla-ansible-ubuntu-source/bd5a051/primary/logs/kolla/mariadb/mariadb.txt: """ 2022-06-15 12:38:03 0 [Warning] mariadbd: io_uring_queue_init() failed with ENOMEM: try larger memory locked limit, ulimit -l, or https://mariadb.com/kb/en/systemd/#configuring-limitmemlock under systemd (262144 bytes required) 220615 12:38:03 [ERROR] mysqld got signal 6 ; This could be because you hit a bug. It is also possible that this binary or one of the libraries it was linked against is corrupt, improperly built, or misconfigured. This error can also be caused by malfunctioning hardware. To report this bug, see https://mariadb.com/kb/en/reporting-bugs We will try our best to scrape up some info that will hopefully help diagnose the problem, but since we have already crashed, something is definitely wrong and this may fail. Server version: 10.6.7-MariaDB-2ubuntu1-log key_buffer_size=67108864 read_buffer_size=131072 max_used_connections=0 max_threads=10002 thread_count=0 It is possible that mysqld could use up to key_buffer_size + (read_buffer_size + sort_buffer_size)*max_threads = 22090304 K bytes of memory Hope that's ok; if not, decrease some variables in the equation. (...) """ The scenario is very similar to the lxd testing I've been using to confirm the bug. Above it's a docker container running mariadb from jammy, on a focal host. The docker image was built with just pulling in mariadb from jammy, without rebuilding it, so it's the same binary as published. I probably made a mistake in my testing with the jammy package just now. I'll repeat it and inspect it more carefully. -- 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/1970634 Title: FTBFS: mariadb fails to start due to low MEMLOCK limit Status in mariadb-10.6 package in Ubuntu: Fix Released Status in systemd package in Ubuntu: Confirmed Status in mariadb-10.6 source package in Jammy: Triaged Status in systemd source package in Jammy: In Progress Bug description: ahasenack: IIRC, originally Launchpad was FTBFSing on mariadb that included io_uring support because upstream were doing a build time test for io_uring (and I think still are), which is wrong because it should be done at runtime since the lack of io_uring availablity at build time doesn't tell us about its availablity at runtime. But then the Launchpad builders got updated to a newer release and therefore a newer kernel that supported it. AIUI, that's how we ended up with a successful build in the Jammy release pocket (of 10.6). I think the lp builders are using the focal hwe kernel 5.4.0-something let me check that build log But then something changed that caused this current FTBFS, and I haven't tracked down what that is. hm, both are 10.6.7 release and proposed What puzzles me is that if the root cause is a memlock rlimit issue then why did it work before? So since there's a contradiction somewhere, maybe one or more of my "facts" above is wrong. this is the current failure 2022-04-14 8:11:49 0 [Warning] mariadbd: io_uring_queue_init() failed with ENOMEM: try larger memory locked limit, ulimit -l, or https://mariadb.com/kb/en/systemd/#configuring-limitmemlock under systemd (262144 bytes required) and ulimit -l confirms that the limit is lower Max locked memory 6553665536 bytes just 64kbytes Yeah but then how did the release pocket build work? either the limit was different back then or ... stuff To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/mariadb-10.6/+bug/1970634/+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 1970634] Re: FTBFS: mariadb fails to start due to low MEMLOCK limit
Ok, phew, my test was incorrect, the bug is present in jammy. That makes this SRU simpler. I'll proceed with it, without a block-proposed tag. -- 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/1970634 Title: FTBFS: mariadb fails to start due to low MEMLOCK limit Status in mariadb-10.6 package in Ubuntu: Fix Released Status in systemd package in Ubuntu: Confirmed Status in mariadb-10.6 source package in Jammy: Triaged Status in systemd source package in Jammy: In Progress Bug description: [Impact] * An explanation of the effects of the bug on users and * justification for backporting the fix to the stable release. * In addition, it is helpful, but not required, to include an explanation of how the upload fixes this bug. [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 [Original Description] ahasenack: IIRC, originally Launchpad was FTBFSing on mariadb that included io_uring support because upstream were doing a build time test for io_uring (and I think still are), which is wrong because it should be done at runtime since the lack of io_uring availablity at build time doesn't tell us about its availablity at runtime. But then the Launchpad builders got updated to a newer release and therefore a newer kernel that supported it. AIUI, that's how we ended up with a successful build in the Jammy release pocket (of 10.6). I think the lp builders are using the focal hwe kernel 5.4.0-something let me check that build log But then something changed that caused this current FTBFS, and I haven't tracked down what that is. hm, both are 10.6.7 release and proposed What puzzles me is that if the root cause is a memlock rlimit issue then why did it work before? So since there's a contradiction somewhere, maybe one or more of my "facts" above is wrong. this is the current failure 2022-04-14 8:11:49 0 [Warning] mariadbd: io_uring_queue_init() failed with ENOMEM: try larger memory locked limit, ulimit -l, or https://mariadb.com/kb/en/systemd/#configuring-limitmemlock under systemd (262144 bytes required) and ulimit -l confirms that the limit is lower Max locked memory 6553665536 bytes just 64kbytes Yeah but then how did the release pocket build work? either the limit was different back then or ... stuff To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/mariadb-10.6/+bug/1970634/+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 1970634] Re: FTBFS: mariadb fails to start due to low MEMLOCK limit
** Description changed: + [Impact] + + * An explanation of the effects of the bug on users and + + * justification for backporting the fix to the stable release. + + * In addition, it is helpful, but not required, to include an +explanation of how the upload fixes this bug. + + [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 + + + [Original Description] + ahasenack: IIRC, originally Launchpad was FTBFSing on mariadb that included io_uring support because upstream were doing a build time test for io_uring (and I think still are), which is wrong because it should be done at runtime since the lack of io_uring availablity at build time doesn't tell us about its availablity at runtime. But then the Launchpad builders got updated to a newer release and therefore a newer kernel that supported it. AIUI, that's how we ended up with a successful build in the Jammy release pocket (of 10.6). I think the lp builders are using the focal hwe kernel 5.4.0-something let me check that build log But then something changed that caused this current FTBFS, and I haven't tracked down what that is. hm, both are 10.6.7 release and proposed What puzzles me is that if the root cause is a memlock rlimit issue then why did it work before? So since there's a contradiction somewhere, maybe one or more of my "facts" above is wrong. this is the current failure 2022-04-14 8:11:49 0 [Warning] mariadbd: io_uring_queue_init() failed with ENOMEM: try larger memory locked limit, ulimit -l, or https://mariadb.com/kb/en/systemd/#configuring-limitmemlock under systemd (262144 bytes required) and ulimit -l confirms that the limit is lower - Max locked memory 6553665536 bytes + Max locked memory 6553665536 bytes just 64kbytes Yeah but then how did the release pocket build work? either the limit was different back then or ... stuff -- 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/1970634 Title: FTBFS: mariadb fails to start due to low MEMLOCK limit Status in mariadb-10.6 package in Ubuntu: Fix Released Status in systemd package in Ubuntu: Confirmed Status in mariadb-10.6 source package in Jammy: Triaged Status in systemd source package in Jammy: In Progress Bug description: [Impact] * An explanation of the effects of the bug on users and * justification for backporting the fix to the stable release. * In addition, it is helpful, but not required, to include an explanation of how the upload fixes this bug. [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 use
[Touch-packages] [Bug 1970634] Re: FTBFS: mariadb fails to start due to low MEMLOCK limit
** Description changed: [Impact] - * An explanation of the effects of the bug on users and + Jammy's MariaDB was built with io_uring support, and it tries to enable + it at runtime if it deems it's running on a supported kernel. There is a + range of kernel versions it checks, but of interest for this SRU, the + Focal (5.4.x) kernel is inside this range and io_uring will be enabled. + The jammy kernel (5.15) is not, so io_uring will not be enabled there. - * justification for backporting the fix to the stable release. + Common scenarios where this combination exists is a focal host, running + a jammy container (lxd or docker), or even a chroot (the launchpad + builders). - * In addition, it is helpful, but not required, to include an -explanation of how the upload fixes this bug. + If io_uring is enabled, a higher MEMLOCK limit is required than what is + set by default in focal or jammy (64Mb is what we get, 256Mb or more is + required). + + The systemd unit file for mariadb tries to raise this limit, but in an + unprivileged container, or a root-less chroot, this won't work. + + MariaDB has checks in place to catch when MEMLOCK is too low, in which + case it will not use io_uring, but these checks are failing because of + the LTO build flags that were used in the jammy build of mariadb. It's + unclear if it's a bug in gcc. There is more information in comment #1, + comment #5 and later. + + The suggested fix here is to disable LTO for the jammy build. This has + been done for kinetic already, and is also applied to the debian + packaging (inside a distro-specific conditional). + [Test Plan] - * detailed instructions how to reproduce the bug + * 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. + * 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. + * 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? + * 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. + * 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 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. + * 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 + * 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] ahasenack: IIRC, originally Launchpad was FTBFSing on mariadb that included io_uring support because upstream were doing a build time test for io_uring (and I think still are), which is wrong because it should be done at runtime since the lack of io_uring availablity at build time doesn't tell us about its availablity at runtime. But then the Launchpad builders got updated to a newer release and therefore a newer kernel that supported it. AIUI, that's how we ended up with a successful build in the Jammy release pocket (of 10.6). I think the lp builders are using the focal hwe kernel 5.4.0-something let me check that build log But then something changed that caused this current FTBFS, and I haven't tracked down what that is. hm, both are 10.6.7 release and proposed What puzzles me is that if the root cause is a memlock rlimit issue then why did it work before? So since there
[Touch-packages] [Bug 1970634] Re: FTBFS: mariadb fails to start due to low MEMLOCK limit
** Description changed: [Impact] Jammy's MariaDB will fail to build, and also fail to start, if the underlying kernel is 5.4.x (focal's) and if it's running in an unprivileged container (lxd, docker). It will also fail to build in launchpad builders. Common scenarios where this combination exists is a focal host, running an unprivileged jammy container (lxd or docker), or even a chroot (the launchpad builders). Jammy's MariaDB was built with io_uring support, and it tries to enable it at runtime if it deems it's running on a supported kernel. There is a range of kernel versions it checks, but of interest for this SRU, the Focal (5.4.x) kernel is inside this range and io_uring will be enabled. The jammy kernel (5.15) is not, so io_uring will not be enabled there, and thus the bug is not manifested in that case. If io_uring is enabled, a higher MEMLOCK limit is required than what is set by default in focal or jammy (64Mb is what we get, 256Mb or more is required). The systemd unit file for mariadb tries to raise this limit, but in an unprivileged container this won't work. MariaDB has checks in place to catch when MEMLOCK is too low, in which case it will not use io_uring, but these checks are failing because of the LTO build flags that were used in the jammy build of mariadb. It's unclear if it's a bug in gcc or something else. There is more information in comment #1, comment #5 and later. The suggested fix here is to disable LTO for the jammy build. This has been done for kinetic already, and is also applied to the debian packaging (inside a distro-specific conditional). [Test Plan] The test plan is to launch mariadb in a jammy lxd container running on a focal host. lxc launch ubuntu:focal f --vm lxc shell lxd init # just hit enter for all questions lxc launch ubuntu:jammy j lxc shell j ulimit -l # confirm it's less than 256 apt update && apt install mariadb-server -y After the installation, mariadb will not be running, and this can be checked with: systemctl status mariadb-server or journalctl -u mariadb.server You will see something like this: Jun 17 18:32:01 jammy-mariadb systemd[1]: Starting MariaDB 10.6.7 database server... Jun 17 18:32:01 jammy-mariadb mariadbd[1864]: 2022-06-17 18:32:01 0 [Note] /usr/sbin/mariadbd (server 10.6.7-MariaDB-2ubuntu1) starting as process 1864 ... Jun 17 18:32:01 jammy-mariadb mariadbd[1864]: 2022-06-17 18:32:01 0 [Note] InnoDB: The first data file './ibdata1' did not exist. A new tablespace will be created! Jun 17 18:32:01 jammy-mariadb mariadbd[1864]: 2022-06-17 18:32:01 0 [Note] InnoDB: Compressed tables use zlib 1.2.11 Jun 17 18:32:01 jammy-mariadb mariadbd[1864]: 2022-06-17 18:32:01 0 [Note] InnoDB: Using transactional memory Jun 17 18:32:01 jammy-mariadb mariadbd[1864]: 2022-06-17 18:32:01 0 [Note] InnoDB: Number of pools: 1 Jun 17 18:32:01 jammy-mariadb mariadbd[1864]: 2022-06-17 18:32:01 0 [Note] InnoDB: Using crc32 + pclmulqdq instructions Jun 17 18:32:01 jammy-mariadb mariadbd[1864]: 2022-06-17 18:32:01 0 [Warning] mariadbd: io_uring_queue_init() failed with ENOMEM: try larger memory locked limit, ulimit -l, or https://mariadb.com/kb/en/systemd/#configuring-limitmemlock under systemd (262144 bytes required) Jun 17 18:32:01 jammy-mariadb mariadbd[1864]: 220617 18:32:01 [ERROR] mysqld got signal 6 ; And a crash dump. With the fixed version, the service will be running normally after installation. [Where problems could occur] + The proposed fix is not a surgical strike. It's unfortunate that we didn't get to the bottom of why LTO is causing this behavior. Reverting it is still the quickest and less risky change at the moment, though. This gets us on par with upstream binary builds, and debian builds, and these also have wide test coverage and ample user base. - * Think about what the upload changes in the software. Imagine the change is - wrong or breaks something else: how would this show up? + The other regression possibility is that this is a rebuild of mariadb in + the current jammy environment, and the package that is currently in + jammy was built on March 10th, 2022. Most likely the reverse + dependencies were updated in jammy since then. - * 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. + It's unclear how 10.6.7-2ubuntu1 migrated in jammy. I checked build logs + and dep8 logs, and can't tell why the tests passed. At least the build + log in jammy shows the host kernel was 5.4.x, so it should have been + affected. My only explanation is that at that time, the MEMLOCK limit + was higher in that environment for some reason, and didn't trigger this + bug. Then at some point later, launchpa
[Touch-packages] [Bug 1970634] Re: FTBFS: mariadb fails to start due to low MEMLOCK limit
** Changed in: systemd (Ubuntu Jammy) Status: In Progress => New ** Changed in: systemd (Ubuntu Jammy) Assignee: Andreas Hasenack (ahasenack) => (unassigned) ** Changed in: mariadb-10.6 (Ubuntu Jammy) Status: Triaged => In Progress ** Description changed: [Impact] Jammy's MariaDB will fail to build, and also fail to start, if the underlying kernel is 5.4.x (focal's) and if it's running in an unprivileged container (lxd, docker). It will also fail to build in launchpad builders. Common scenarios where this combination exists is a focal host, running an unprivileged jammy container (lxd or docker), or even a chroot (the launchpad builders). Jammy's MariaDB was built with io_uring support, and it tries to enable it at runtime if it deems it's running on a supported kernel. There is a range of kernel versions it checks, but of interest for this SRU, the Focal (5.4.x) kernel is inside this range and io_uring will be enabled. The jammy kernel (5.15) is not, so io_uring will not be enabled there, and thus the bug is not manifested in that case. If io_uring is enabled, a higher MEMLOCK limit is required than what is set by default in focal or jammy (64Mb is what we get, 256Mb or more is required). The systemd unit file for mariadb tries to raise this limit, but in an unprivileged container this won't work. MariaDB has checks in place to catch when MEMLOCK is too low, in which case it will not use io_uring, but these checks are failing because of the LTO build flags that were used in the jammy build of mariadb. It's unclear if it's a bug in gcc or something else. There is more information in comment #1, comment #5 and later. The suggested fix here is to disable LTO for the jammy build. This has been done for kinetic already, and is also applied to the debian packaging (inside a distro-specific conditional). [Test Plan] The test plan is to launch mariadb in a jammy lxd container running on a focal host. lxc launch ubuntu:focal f --vm lxc shell lxd init # just hit enter for all questions lxc launch ubuntu:jammy j lxc shell j ulimit -l # confirm it's less than 256 apt update && apt install mariadb-server -y After the installation, mariadb will not be running, and this can be checked with: - systemctl status mariadb-server + systemctl status mariadb.service or journalctl -u mariadb.server You will see something like this: Jun 17 18:32:01 jammy-mariadb systemd[1]: Starting MariaDB 10.6.7 database server... Jun 17 18:32:01 jammy-mariadb mariadbd[1864]: 2022-06-17 18:32:01 0 [Note] /usr/sbin/mariadbd (server 10.6.7-MariaDB-2ubuntu1) starting as process 1864 ... Jun 17 18:32:01 jammy-mariadb mariadbd[1864]: 2022-06-17 18:32:01 0 [Note] InnoDB: The first data file './ibdata1' did not exist. A new tablespace will be created! Jun 17 18:32:01 jammy-mariadb mariadbd[1864]: 2022-06-17 18:32:01 0 [Note] InnoDB: Compressed tables use zlib 1.2.11 Jun 17 18:32:01 jammy-mariadb mariadbd[1864]: 2022-06-17 18:32:01 0 [Note] InnoDB: Using transactional memory Jun 17 18:32:01 jammy-mariadb mariadbd[1864]: 2022-06-17 18:32:01 0 [Note] InnoDB: Number of pools: 1 Jun 17 18:32:01 jammy-mariadb mariadbd[1864]: 2022-06-17 18:32:01 0 [Note] InnoDB: Using crc32 + pclmulqdq instructions Jun 17 18:32:01 jammy-mariadb mariadbd[1864]: 2022-06-17 18:32:01 0 [Warning] mariadbd: io_uring_queue_init() failed with ENOMEM: try larger memory locked limit, ulimit -l, or https://mariadb.com/kb/en/systemd/#configuring-limitmemlock under systemd (262144 bytes required) Jun 17 18:32:01 jammy-mariadb mariadbd[1864]: 220617 18:32:01 [ERROR] mysqld got signal 6 ; And a crash dump. With the fixed version, the service will be running normally after installation. [Where problems could occur] The proposed fix is not a surgical strike. It's unfortunate that we didn't get to the bottom of why LTO is causing this behavior. Reverting it is still the quickest and less risky change at the moment, though. This gets us on par with upstream binary builds, and debian builds, and these also have wide test coverage and ample user base. The other regression possibility is that this is a rebuild of mariadb in the current jammy environment, and the package that is currently in jammy was built on March 10th, 2022. Most likely the reverse dependencies were updated in jammy since then. It's unclear how 10.6.7-2ubuntu1 migrated in jammy. I checked build logs and dep8 logs, and can't tell why the tests passed. At least the build log in jammy shows the host kernel was 5.4.x, so it should have been affected. My only explanation is that at that time, the MEMLOCK limit was higher in that environment for some reason, and didn't trigger this bug. Then at some point later,
[Touch-packages] [Bug 1889548] Re: ssh using gssapi will enforce FILE: credentials cache
** Also affects: openssh via
https://bugzilla.mindrot.org/show_bug.cgi?id=3203
Importance: Unknown
Status: Unknown
--
You received this bug notification because you are a member of Ubuntu
Touch seeded packages, which is subscribed to openssh in Ubuntu.
https://bugs.launchpad.net/bugs/1889548
Title:
ssh using gssapi will enforce FILE: credentials cache
Status in portable OpenSSH:
Unknown
Status in openssh package in Ubuntu:
Confirmed
Bug description:
Hi,
ssh connections from a client with the following in ssh_config...
GSSAPIAuthentication yes
GSSAPIDelegateCredentials yes
... to an ubuntu 20.04 machine result in KRB5CCNAME being set to
'FILE:/tmp/krb5cc_[uid]_[random]' despite the following in
/etc/krb5.conf:
[libdefaults]
...
default_ccache_name = KEYRING:persistent:%{uid}
This means that we cannot enforce a policy to use KEYRING ccaches
across our systems. Authentications which go via the pam stack (e.g.
login to the machine at the console or over ssh using a password) can
be configured to use a KEYRING ccache, via libpam-krb5 settings in
/etc/krb5.conf.
The FILE: setting seems to be hard-coded in the openssh code (auth-
krb5.c). It would be great if ssh(gssapi-with-mic) connections either
(a) set KRB5CCNAME to the default_ccache_name value, if set in
/etc/krb5.conf, or (b) didn't set KRB5CCNAME at all, so the system
default is used.
Many thanks
Toby Blake
School of Informatics
University of Edinburgh
To manage notifications about this bug go to:
https://bugs.launchpad.net/openssh/+bug/1889548/+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 1889548] Re: ssh using gssapi will enforce FILE: credentials cache
Toby, you are mostly interested in this because you have some sort of
policy, perhaps one that doesn't allow secrets to be stored on disk in
clear text and protected just by filesystem permissions?
--
You received this bug notification because you are a member of Ubuntu
Touch seeded packages, which is subscribed to openssh in Ubuntu.
https://bugs.launchpad.net/bugs/1889548
Title:
ssh using gssapi will enforce FILE: credentials cache
Status in portable OpenSSH:
Unknown
Status in openssh package in Ubuntu:
Confirmed
Bug description:
Hi,
ssh connections from a client with the following in ssh_config...
GSSAPIAuthentication yes
GSSAPIDelegateCredentials yes
... to an ubuntu 20.04 machine result in KRB5CCNAME being set to
'FILE:/tmp/krb5cc_[uid]_[random]' despite the following in
/etc/krb5.conf:
[libdefaults]
...
default_ccache_name = KEYRING:persistent:%{uid}
This means that we cannot enforce a policy to use KEYRING ccaches
across our systems. Authentications which go via the pam stack (e.g.
login to the machine at the console or over ssh using a password) can
be configured to use a KEYRING ccache, via libpam-krb5 settings in
/etc/krb5.conf.
The FILE: setting seems to be hard-coded in the openssh code (auth-
krb5.c). It would be great if ssh(gssapi-with-mic) connections either
(a) set KRB5CCNAME to the default_ccache_name value, if set in
/etc/krb5.conf, or (b) didn't set KRB5CCNAME at all, so the system
default is used.
Many thanks
Toby Blake
School of Informatics
University of Edinburgh
To manage notifications about this bug go to:
https://bugs.launchpad.net/openssh/+bug/1889548/+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 1977751] Re: Merge ust from Debian for 22.10
** Changed in: ust (Ubuntu) Milestone: None => ubuntu-22.07 -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to ust in Ubuntu. https://bugs.launchpad.net/bugs/1977751 Title: Merge ust from Debian for 22.10 Status in ust package in Ubuntu: New Bug description: New minor upstream release available: 2.13.3-1 2022-06-03 (National Repeat Day) (National Repeat Day) lttng-ust 2.13.3 * Document ust lock async-signal-safety * Fix: don't use strerror() from ust lock nocheck * Fix: remove non-async-signal-safe fflush from ERR() * Fix: Pointers are rejected by integer element compile time assertion for array and sequence * Fix: statedump: invalid read during iter_end * Fix: bytecode interpreter context_get_index() leaves byte order uninitialized ust (2.13.3-1) unstable; urgency=medium * [92abdd1] New upstream version 2.13.3 -- Michael Jeanson Fri, 03 Jun 2022 16:37:11 -0400 To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/ust/+bug/1977751/+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
Here is a collection of guides from upstream MIT kerberos: https://web.mit.edu/kerberos/krb5-latest/doc/admin/enctypes.html#migrating- away-from-older-encryption-types -- 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: Confirmed Status in krb5 package in Debian: Unknown Bug 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 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) To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/krb5/+bug/1981697/+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 1912256] Re: Missing channel binding prevents authentication to ActiveDirectory
** Changed in: cyrus-sasl2 (Ubuntu) Status: Confirmed => In Progress -- 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/1912256 Title: Missing channel binding prevents authentication to ActiveDirectory Status in cyrus-sasl2 package in Ubuntu: In Progress Status in openldap package in Ubuntu: Confirmed Bug description: > Are you uncertain if your issue is really a bug? Effect is an authentication error. Root case is a "missing feature" (see below) and requires updating dependencies, downporting. > If you are certain this is a bug please include the source package the bug is in. It's in the interaction between three libraries: openldap, cyrus-sasl, krb5 > 1) The release of Ubuntu you are using, via 'lsb_release -rd' or System -> About Ubuntu Broken in 18.04 and also in 20.10 (I guess it's also broken in anything inbetween) > 2) The version of the package you are using, via 'apt-cache policy pkgname' or by checking in Software Center libsasl2-modules-gssapi-mit: 2.1.27+dfsg-2ubuntu1 ldap-utils: 2.4.53+dfsg-1ubuntu1.2 libgssapi-krb5-2: 1.17-10ubuntu0.1 > 3) What you expected to happen # kinit $ export LDAPSASL_CBINDING=tls-endpoint $ ldapwhoami -O minssf=0,maxssf=0 -N -Y GSSAPI -H ldaps:// SASL/GSSAPI authentication started SASL username: SASL SSF: 0 u: > 4) What happened instead SASL/GSSAPI authentication started ldap_sasl_interactive_bind_s: Invalid credentials (49) additional info: 80090346: LdapErr: DSID-0C090597, comment: AcceptSecurityContext error, data 80090346, v4563 --- Microsoft ActiveDirectory has "LDAP Channel Binding" and recommends activating this as a required feature. See https://access.redhat.com/articles/4661861 Authentication to any AD DC which has mandatory channel binding fails. Channel binding requires at least an update to cyrus-sasl, which is not in any release as far as I can see: https://github.com/cyrusimap/cyrus- sasl/commit/975edbb69070eba6b035f08776de771a129cfb57 It also needs this commit in openldap: https://git.openldap.org/openldap/openldap/-/commit/3cd50fa8b32a21040a9892e2a8a7a9dfc7541ce6 Which as far as I can tell is v2.5 (branch OPENLDAP_REL_ENG_2_5). RH also mentions it needs up-to-date krb5 libraries, but I can't tell what minimum version this needs. I can build all libraries from source, current master (except for krb5 where I've used 1.18.3) and can confirm that channel binding works when using those libraries. I'm not sure if Samba is affected, but at least adcli, ldap-utils, and I would guess by extension also SSSD and realmd. To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/cyrus-sasl2/+bug/1912256/+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 1912256] Re: Missing channel binding prevents authentication to ActiveDirectory
I have a build for kinetic which has two changes:
- enable channel binding
- allow setting maxssf=0 when using GSS-SPNEGO
The later might not be needed, as GSSAPI already supports maxssf=0, and
adcli will forcibly select GSSAPI instead of GSS-SPNEGO if ldaps (ssl)
is being used, exactly because not everybody might have that patch:
https://git.launchpad.net/ubuntu/+source/adcli/tree/library/adconn.c?h=ubuntu/kinetic-
devel#n1090
const char *mech = "GSSAPI";
(...)
/* There are issues with cryrus-sasl and GSS-SPNEGO with TLS even if
* ssf_max is set to 0. To be on the safe side GSS-SPNEGO is only used
* without LDAPS. */
if (adcli_conn_server_has_sasl_mech (conn, "GSS-SPNEGO")
&& !adcli_conn_get_use_ldaps (conn)) {
mech = "GSS-SPNEGO";
}
But without the second patch, using GSS-SPNEGO over ldaps:// against
windows won't work (because -O maxssf=0 is ignored), so it's good to
have I think.
I tested this against windows 2016 with LdapEnforceChannelBinding=2 and
LDAPServerIntegrity=2 in the registry, and could verify that without the
sasl changes, joining the domain with adcli/realmd run with --use-ldaps
would not work. On kinetic so far.
I'm now trying to determine if I also need to pull in
https://github.com/cyrusimap/cyrus-
sasl/commit/8735185e9d5550e0f11e1ce4b77e391a16e4145b. There was a very
technical discussion in the related issue at
https://github.com/cyrusimap/cyrus-sasl/issues/637 involving RFCs and in
the end the above commit landed, but only in master/main. I'm still
unsure why that was needed if SASL_CBINDING defaults to "none":
SASL_CBINDING
The channel-binding type to use, see also LDAP_OPT_X_SASL_CBINDING. The
default is none.
I'm currently testing the patched library with other sasl-enabled
services via gssapi and gss-spnego, to see if any of them complain about
the channel binding patch.
The openldap test suite has a nice test for this at
https://git.launchpad.net/ubuntu/+source/openldap/tree/tests/scripts/test077-sasl-
gssapi?h=ubuntu/kinetic-devel#n175
I was expecting to be able to get ldap to fail if I enable it on the
server, and not on the client, i.e.:
dn: cn=config
changetype: modify
replace: olcSaslCBinding
olcSaslCBinding: tls-unique
But whatever SASL_CBINDING setting I used on the client, the bind always
worked (gssapi/gss-spnego + ldaps), so I'm still unsure if it's working
as expected.
This on kinetic with openldap 2.5.12.
** Bug watch added: github.com/cyrusimap/cyrus-sasl/issues #637
https://github.com/cyrusimap/cyrus-sasl/issues/637
--
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/1912256
Title:
Missing channel binding prevents authentication to ActiveDirectory
Status in cyrus-sasl2 package in Ubuntu:
In Progress
Status in openldap package in Ubuntu:
Confirmed
Bug description:
> Are you uncertain if your issue is really a bug?
Effect is an authentication error. Root case is a "missing feature" (see
below) and requires updating dependencies, downporting.
> If you are certain this is a bug please include the source package the bug
is in.
It's in the interaction between three libraries: openldap, cyrus-sasl, krb5
> 1) The release of Ubuntu you are using, via 'lsb_release -rd' or System ->
About Ubuntu
Broken in 18.04 and also in 20.10 (I guess it's also broken in anything
inbetween)
> 2) The version of the package you are using, via 'apt-cache policy
pkgname' or by checking in Software Center
libsasl2-modules-gssapi-mit: 2.1.27+dfsg-2ubuntu1
ldap-utils: 2.4.53+dfsg-1ubuntu1.2
libgssapi-krb5-2: 1.17-10ubuntu0.1
> 3) What you expected to happen
# kinit
$ export LDAPSASL_CBINDING=tls-endpoint
$ ldapwhoami -O minssf=0,maxssf=0 -N -Y GSSAPI -H ldaps://
SASL/GSSAPI authentication started
SASL username:
SASL SSF: 0
u:
> 4) What happened instead
SASL/GSSAPI authentication started
ldap_sasl_interactive_bind_s: Invalid credentials (49)
additional info: 80090346: LdapErr: DSID-0C090597, comment:
AcceptSecurityContext error, data 80090346, v4563
---
Microsoft ActiveDirectory has "LDAP Channel Binding" and recommends
activating this as a required feature. See
https://access.redhat.com/articles/4661861
Authentication to any AD DC which has mandatory channel binding fails.
Channel binding requires at least an update to cyrus-sasl, which is
not in any release as far as I can see:
https://github.com/cyrusimap/cyrus-
sasl/commit/975edbb69070eba6b035f08776de771a129cfb57
It also needs this commit in openldap:
https://git.openldap.org/openldap/openldap/-/commit/3cd50fa8b32a21040a9892e2a8a7a9dfc7541ce6
Which as far as I can tell is v2.5 (branch OPENLDAP_REL_ENG_2_5).
RH also mentions it needs up-to-date krb5 libraries, but I can't tell what
[Touch-packages] [Bug 1912256] Re: Missing channel binding prevents authentication to ActiveDirectory
Ok, the -o SASL_CBINDING command-line parameter seems to work. Against that window 2016 server the ldapwhoami command only works when I set the channel binding mode to tls-unique: ubuntu@k1:~$ ldapwhoami -H ldaps://WIN-KRIET1E5ELO.internal.example.fake -Y GSSAPI -O maxssf=0 -o SASL_CBINDING=none SASL/GSSAPI authentication started ldap_sasl_interactive_bind: Invalid credentials (49) additional info: 80090346: LdapErr: DSID-0C09059A, comment: AcceptSecurityContext error, data 80090346, v3839 ubuntu@k1:~$ ldapwhoami -H ldaps://WIN-KRIET1E5ELO.internal.example.fake -Y GSSAPI -O maxssf=0 -o SASL_CBINDING=tls-unique SASL/GSSAPI authentication started ldap_sasl_interactive_bind: Invalid credentials (49) additional info: 80090346: LdapErr: DSID-0C09059A, comment: AcceptSecurityContext error, data 80090346, v3839 ubuntu@k1:~$ ldapwhoami -H ldaps://WIN-KRIET1E5ELO.internal.example.fake -Y GSSAPI -O maxssf=0 -o SASL_CBINDING=tls-endpoint SASL/GSSAPI authentication started SASL username: ubu...@internal.example.fake SASL SSF: 0 u:INTEXAMPLE\ubuntu -- 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/1912256 Title: Missing channel binding prevents authentication to ActiveDirectory Status in cyrus-sasl2 package in Ubuntu: In Progress Status in openldap package in Ubuntu: Confirmed Bug description: > Are you uncertain if your issue is really a bug? Effect is an authentication error. Root case is a "missing feature" (see below) and requires updating dependencies, downporting. > If you are certain this is a bug please include the source package the bug is in. It's in the interaction between three libraries: openldap, cyrus-sasl, krb5 > 1) The release of Ubuntu you are using, via 'lsb_release -rd' or System -> About Ubuntu Broken in 18.04 and also in 20.10 (I guess it's also broken in anything inbetween) > 2) The version of the package you are using, via 'apt-cache policy pkgname' or by checking in Software Center libsasl2-modules-gssapi-mit: 2.1.27+dfsg-2ubuntu1 ldap-utils: 2.4.53+dfsg-1ubuntu1.2 libgssapi-krb5-2: 1.17-10ubuntu0.1 > 3) What you expected to happen # kinit $ export LDAPSASL_CBINDING=tls-endpoint $ ldapwhoami -O minssf=0,maxssf=0 -N -Y GSSAPI -H ldaps:// SASL/GSSAPI authentication started SASL username: SASL SSF: 0 u: > 4) What happened instead SASL/GSSAPI authentication started ldap_sasl_interactive_bind_s: Invalid credentials (49) additional info: 80090346: LdapErr: DSID-0C090597, comment: AcceptSecurityContext error, data 80090346, v4563 --- Microsoft ActiveDirectory has "LDAP Channel Binding" and recommends activating this as a required feature. See https://access.redhat.com/articles/4661861 Authentication to any AD DC which has mandatory channel binding fails. Channel binding requires at least an update to cyrus-sasl, which is not in any release as far as I can see: https://github.com/cyrusimap/cyrus- sasl/commit/975edbb69070eba6b035f08776de771a129cfb57 It also needs this commit in openldap: https://git.openldap.org/openldap/openldap/-/commit/3cd50fa8b32a21040a9892e2a8a7a9dfc7541ce6 Which as far as I can tell is v2.5 (branch OPENLDAP_REL_ENG_2_5). RH also mentions it needs up-to-date krb5 libraries, but I can't tell what minimum version this needs. I can build all libraries from source, current master (except for krb5 where I've used 1.18.3) and can confirm that channel binding works when using those libraries. I'm not sure if Samba is affected, but at least adcli, ldap-utils, and I would guess by extension also SSSD and realmd. To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/cyrus-sasl2/+bug/1912256/+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 1912256] Re: Missing channel binding prevents authentication to ActiveDirectory
I'm concerned about interoperability issues... https://github.com/cyrusimap/cyrus-imapd/issues/3317 ** Bug watch added: github.com/cyrusimap/cyrus-imapd/issues #3317 https://github.com/cyrusimap/cyrus-imapd/issues/3317 -- 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/1912256 Title: Missing channel binding prevents authentication to ActiveDirectory Status in cyrus-sasl2 package in Ubuntu: In Progress Status in openldap package in Ubuntu: Confirmed Bug description: > Are you uncertain if your issue is really a bug? Effect is an authentication error. Root case is a "missing feature" (see below) and requires updating dependencies, downporting. > If you are certain this is a bug please include the source package the bug is in. It's in the interaction between three libraries: openldap, cyrus-sasl, krb5 > 1) The release of Ubuntu you are using, via 'lsb_release -rd' or System -> About Ubuntu Broken in 18.04 and also in 20.10 (I guess it's also broken in anything inbetween) > 2) The version of the package you are using, via 'apt-cache policy pkgname' or by checking in Software Center libsasl2-modules-gssapi-mit: 2.1.27+dfsg-2ubuntu1 ldap-utils: 2.4.53+dfsg-1ubuntu1.2 libgssapi-krb5-2: 1.17-10ubuntu0.1 > 3) What you expected to happen # kinit $ export LDAPSASL_CBINDING=tls-endpoint $ ldapwhoami -O minssf=0,maxssf=0 -N -Y GSSAPI -H ldaps:// SASL/GSSAPI authentication started SASL username: SASL SSF: 0 u: > 4) What happened instead SASL/GSSAPI authentication started ldap_sasl_interactive_bind_s: Invalid credentials (49) additional info: 80090346: LdapErr: DSID-0C090597, comment: AcceptSecurityContext error, data 80090346, v4563 --- Microsoft ActiveDirectory has "LDAP Channel Binding" and recommends activating this as a required feature. See https://access.redhat.com/articles/4661861 Authentication to any AD DC which has mandatory channel binding fails. Channel binding requires at least an update to cyrus-sasl, which is not in any release as far as I can see: https://github.com/cyrusimap/cyrus- sasl/commit/975edbb69070eba6b035f08776de771a129cfb57 It also needs this commit in openldap: https://git.openldap.org/openldap/openldap/-/commit/3cd50fa8b32a21040a9892e2a8a7a9dfc7541ce6 Which as far as I can tell is v2.5 (branch OPENLDAP_REL_ENG_2_5). RH also mentions it needs up-to-date krb5 libraries, but I can't tell what minimum version this needs. I can build all libraries from source, current master (except for krb5 where I've used 1.18.3) and can confirm that channel binding works when using those libraries. I'm not sure if Samba is affected, but at least adcli, ldap-utils, and I would guess by extension also SSSD and realmd. To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/cyrus-sasl2/+bug/1912256/+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
This was fixed in debian and is currently in kinetic-proposed: https://launchpad.net/ubuntu/+source/krb5/1.20-1 I'm unsure how to approach this from an SRU perspective, given it's a configuration setting in the default config file that is ship: --- a/debian/kdc.conf +++ b/debian/kdc.conf @@ -10,7 +10,7 @@ kdc_ports = 750,88 max_life = 10h 0m 0s max_renewable_life = 7d 0h 0m 0s -master_key_type = des3-hmac-sha1 +#master_key_type = aes256-cts #supported_enctypes = aes256-cts:normal aes128-cts:normal default_principal_flags = +preauth } -- 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: Confirmed Status in krb5 package in Debian: Unknown Bug 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 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) To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/krb5/+bug/1981697/+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
