Re: Upcoming upload of glibc 2.39 in noble-proposed
Hi Erich, > Hi Simon, > > So, not that this relieves stress on anyone as we're all going to want > to beat this (or wait for the long, long queues), but I assume you mean Unless your package lands in the huge queue, you wouldn't be stuck behind the glibc tests, the entire system will "just" be slower processing the normal queue. Now that said, I apologize and empathise. It is squarely my fault, I must have missed a line when checking what I had written in the transition schedule. > Friday, February 2nd? Looks like I'm really having issues with reading dates these days. It will indeed be the 2nd, thanks for pointing it out. > On 1/31/24 09:07, Simon Chopin wrote: > > Hi there! > > > > Small timeline update: I'm actually aiming at uploading the new glibc on > > Friday, 3rd, so two days from now. > > > >> Hi folks! > >> > >> As usual in this time of the cycle, the new version of glibc is about to > >> be released upstream (scheduled next Thursday, Feb 1st), and should thus be > >> uploaded to the archive shortly thereafter, presumably around Feb 7th. > >> > >> Have a look at the upstream changelog if you're interested in the > >> details: > >> > >> https://sourceware.org/git/?p=glibc.git;a=blob;f=NEWS;h=199f079f2764ccd2a1973fdd927bc291fdd1d0a9;hb=HEAD > >> > >> Note that we are not impacted by the libcrypt removal as we > >> haven't built libcrypt for glibc for a while. If some of your projects > >> use a third-party malloc implementation, see at bottom to try a > >> snapshot. > >> > >> A number of potential issues have already been identified through a test > >> rebuild done with a development snapshot of glibc. All glibc-related > >> regressions have been identified and reported (thanks to Ravi Kant > >> Sharma for his tremendous help on that front), and we're currently > >> working our way through the list: > >> > >> https://bugs.launchpad.net/ubuntu/+bugs?field.tag=test-rebuild-glibc-noble > >> > >> There's a fresh snapshot package available in a PPA: > >> > >> https://launchpad.net/~ubuntu-toolchain-r/+archive/ubuntu/glibc > >> > >> (i386 build is currently broken, WIP) > >> > >> > >> This upload usually has the immediate consequence of blowing up the > >> autopkgtest huge queue, meaning any other package that uses this queue > >> for its rdep tests will be directly impacted. In addition, the added > >> load usually means there's a higher failure rate on tests (e.g. timeouts > >> due to resource attrition). Furthermore, it is possible that a package > >> built after the glibc upload would pick up a versioned dependency on the > >> newer glibc due to changes in ABIs for existing functions. In that case, > >> said package would need to wait until glibc has migrated, which can take > >> a little while. > >> > >> Feel free to reach out to me (schopin) on IRC if you have questions. > >> > >> Cheers, > >> Simon > > -- > -- > Erich Eickmeyer > Project Leader - Ubuntu Studio > Technical Lead - Edubuntu > > > -- > ubuntu-devel mailing list > ubuntu-devel@lists.ubuntu.com > Modify settings or unsubscribe at: > https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel -- ubuntu-devel mailing list ubuntu-devel@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel
Re: Upcoming upload of glibc 2.39 in noble-proposed
Hi Simon, So, not that this relieves stress on anyone as we're all going to want to beat this (or wait for the long, long queues), but I assume you mean Friday, February 2nd? On 1/31/24 09:07, Simon Chopin wrote: Hi there! Small timeline update: I'm actually aiming at uploading the new glibc on Friday, 3rd, so two days from now. Hi folks! As usual in this time of the cycle, the new version of glibc is about to be released upstream (scheduled next Thursday, Feb 1st), and should thus be uploaded to the archive shortly thereafter, presumably around Feb 7th. Have a look at the upstream changelog if you're interested in the details: https://sourceware.org/git/?p=glibc.git;a=blob;f=NEWS;h=199f079f2764ccd2a1973fdd927bc291fdd1d0a9;hb=HEAD Note that we are not impacted by the libcrypt removal as we haven't built libcrypt for glibc for a while. If some of your projects use a third-party malloc implementation, see at bottom to try a snapshot. A number of potential issues have already been identified through a test rebuild done with a development snapshot of glibc. All glibc-related regressions have been identified and reported (thanks to Ravi Kant Sharma for his tremendous help on that front), and we're currently working our way through the list: https://bugs.launchpad.net/ubuntu/+bugs?field.tag=test-rebuild-glibc-noble There's a fresh snapshot package available in a PPA: https://launchpad.net/~ubuntu-toolchain-r/+archive/ubuntu/glibc (i386 build is currently broken, WIP) This upload usually has the immediate consequence of blowing up the autopkgtest huge queue, meaning any other package that uses this queue for its rdep tests will be directly impacted. In addition, the added load usually means there's a higher failure rate on tests (e.g. timeouts due to resource attrition). Furthermore, it is possible that a package built after the glibc upload would pick up a versioned dependency on the newer glibc due to changes in ABIs for existing functions. In that case, said package would need to wait until glibc has migrated, which can take a little while. Feel free to reach out to me (schopin) on IRC if you have questions. Cheers, Simon -- -- Erich Eickmeyer Project Leader - Ubuntu Studio Technical Lead - Edubuntu -- ubuntu-devel mailing list ubuntu-devel@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel
RE: Upcoming upload of glibc 2.39 in noble-proposed
Hi there! Small timeline update: I'm actually aiming at uploading the new glibc on Friday, 3rd, so two days from now. > Hi folks! > > As usual in this time of the cycle, the new version of glibc is about to > be released upstream (scheduled next Thursday, Feb 1st), and should thus be > uploaded to the archive shortly thereafter, presumably around Feb 7th. > > Have a look at the upstream changelog if you're interested in the > details: > > https://sourceware.org/git/?p=glibc.git;a=blob;f=NEWS;h=199f079f2764ccd2a1973fdd927bc291fdd1d0a9;hb=HEAD > > Note that we are not impacted by the libcrypt removal as we > haven't built libcrypt for glibc for a while. If some of your projects > use a third-party malloc implementation, see at bottom to try a > snapshot. > > A number of potential issues have already been identified through a test > rebuild done with a development snapshot of glibc. All glibc-related > regressions have been identified and reported (thanks to Ravi Kant > Sharma for his tremendous help on that front), and we're currently > working our way through the list: > > https://bugs.launchpad.net/ubuntu/+bugs?field.tag=test-rebuild-glibc-noble > > There's a fresh snapshot package available in a PPA: > > https://launchpad.net/~ubuntu-toolchain-r/+archive/ubuntu/glibc > > (i386 build is currently broken, WIP) > > > This upload usually has the immediate consequence of blowing up the > autopkgtest huge queue, meaning any other package that uses this queue > for its rdep tests will be directly impacted. In addition, the added > load usually means there's a higher failure rate on tests (e.g. timeouts > due to resource attrition). Furthermore, it is possible that a package > built after the glibc upload would pick up a versioned dependency on the > newer glibc due to changes in ABIs for existing functions. In that case, > said package would need to wait until glibc has migrated, which can take > a little while. > > Feel free to reach out to me (schopin) on IRC if you have questions. > > Cheers, > Simon -- ubuntu-devel mailing list ubuntu-devel@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel
Re: PAM module ordering with pam-auth-update
Hi Philip, On Tue, Jan 30, 2024 at 05:13:41PM -0700, Philip Prindeville wrote: > Looking at the Perl, it doesn't seem like that difficult a change to make. > > Is it worth filing a bug, and how likely is this to be fixed? Thank you for the suggestion. This doesn't sound like something we'd want to maintain in Ubuntu separately from Debian, but if Debian does it then we would follow. In particular it could be really confusing for users if ordering were different between Debian and Ubuntu for the same configuration. I suggest you file a bug against the package (libpam-runtime) in Debian to seek the maintainer's opinion there. HTH, Robie signature.asc Description: PGP signature -- Ubuntu-devel-discuss mailing list Ubuntu-devel-discuss@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel-discuss
