[00:03] <guiverc> thank you bdmurray :)
[00:55] -queuebot:#ubuntu-release- New binary: pyfltk [riscv64] (jammy-proposed/universe) [1.3.7+repack-1] (no packageset)
[01:00] -queuebot:#ubuntu-release- Unapproved: vitis-ai (focal-proposed/universe) [1.3.2-0ubuntu5~20.04.1 => 1.3.2-0ubuntu5~20.04.2] (no packageset)
[01:02] -queuebot:#ubuntu-release- Unapproved: accepted vitis-ai [source] (focal-proposed) [1.3.2-0ubuntu5~20.04.2]
[04:17] -queuebot:#ubuntu-release- New binary: rustc [armhf] (jammy-proposed/universe) [1.57.0+dfsg1+llvm-0ubuntu1] (i386-whitelist)
[05:17] -queuebot:#ubuntu-release- New binary: node-postcss-preset-evergreen [amd64] (jammy-proposed/universe) [0.2.1+~cs33.0.7-2] (no packageset)
[05:18] -queuebot:#ubuntu-release- New binary: rust-condure [amd64] (jammy-proposed/universe) [1.3.1-1] (no packageset)
[05:20] -queuebot:#ubuntu-release- New binary: pyfltk [amd64] (jammy-proposed/universe) [1.3.7+repack-2] (no packageset)
[05:22] -queuebot:#ubuntu-release- New binary: pyfltk [s390x] (jammy-proposed/universe) [1.3.7+repack-2] (no packageset)
[05:22] -queuebot:#ubuntu-release- New binary: rust-condure [ppc64el] (jammy-proposed/universe) [1.3.1-1] (no packageset)
[05:23] -queuebot:#ubuntu-release- New binary: pyfltk [ppc64el] (jammy-proposed/universe) [1.3.7+repack-2] (no packageset)
[05:23] -queuebot:#ubuntu-release- New binary: rust-condure [arm64] (jammy-proposed/universe) [1.3.1-1] (no packageset)
[05:24] -queuebot:#ubuntu-release- New binary: rust-condure [s390x] (jammy-proposed/universe) [1.3.1-1] (no packageset)
[05:26] -queuebot:#ubuntu-release- New binary: rust-condure [armhf] (jammy-proposed/universe) [1.3.1-1] (no packageset)
[05:28] -queuebot:#ubuntu-release- New binary: pyfltk [armhf] (jammy-proposed/universe) [1.3.7+repack-2] (no packageset)
[05:29] -queuebot:#ubuntu-release- New binary: pyfltk [arm64] (jammy-proposed/universe) [1.3.7+repack-2] (no packageset)
[05:59] -queuebot:#ubuntu-release- New binary: rust-condure [riscv64] (jammy-proposed/universe) [1.3.1-1] (no packageset)
[06:42] -queuebot:#ubuntu-release- New binary: pyfltk [riscv64] (jammy-proposed/universe) [1.3.7+repack-2] (no packageset)
[07:57] -queuebot:#ubuntu-release- New binary: rustc [i386] (jammy-proposed/universe) [1.57.0+dfsg1+llvm-0ubuntu1] (i386-whitelist)
[10:15] -queuebot:#ubuntu-release- New binary: rustc [arm64] (jammy-proposed/universe) [1.57.0+dfsg1+llvm-0ubuntu1] (i386-whitelist)
[10:27] <LocutusOfBorg> hello, should I start a new ocaml transition?
[10:27] <LocutusOfBorg> lots of ocaml packages are bd unistallable now, but maybe its better to wait for python?
[10:38] <juliank> it seems s390x autopkgtest cloud is broken, investigating
[10:41] <juliank> hmm systemd[1]: systemd-journald.service: Main process exited, code=exited, status=127/n/a
[10:47] <juliank> i created an instance myself and it rebooted fine, but real ones mostly fail to come back up
[11:17] -queuebot:#ubuntu-release- New binary: python2-pip [amd64] (jammy-proposed/universe) [20.3.4+dfsg-3] (no packageset)
[11:48] <juliank> It seems libxcrypt is borked
[11:49] <juliank> I noticed all failed tests where with libxcrypt from proposed
[11:49] <juliank> I created a VM, installed it, and restarted systemd-timesyncd to end up with
[11:49] <juliank> Jan 21 11:47:26 jak-test-s390x systemd-timesyncd[1305]: /lib/systemd/systemd-timesyncd: error while loading shared libraries: libcrypt.so.1: failed to map segment from shared object
[11:49] <juliank> ubuntu-archive ^ please remove broken libxcrypt from proposed
[11:50]  * apw looks
[11:50] <juliank> Investigating what's going on further
[11:50] <juliank> sil2100: apw is looking at it
[11:51] <sil2100> o/
[11:51] <juliank> So the odd thing is systemd-timesyncd runs fine *outside* the service, I think *something* in new libcrypt1 is just not compatible with systemd sandboxing
[11:52] <seb128> juliank, shouldn't someone work on understanding the issue and fix it properly rather than deleting the update and potentially getting the issue again later?
[11:52] <juliank> seb128: Yes, that happens in parallel
[11:52] <juliank> seb128: Just want to avoid stuff building against the potentially borked library
[11:52] <seb128> ack
[11:54] <juliank> seb128: So, turns out that sudo  systemd-run -P -p MemoryDenyWriteExecute=yes /lib/systemd/systemd-timesyncd
[11:54] <juliank> /lib/systemd/systemd-timesyncd: error while loading shared libraries: libcrypt.so.1: failed to map segment from shared object
[11:54] <juliank> seb128: I think maybe the new gcc is the broken thing
[11:54] <juliank> the new libxcrypt was effectively a no-change rebuild
[11:55] <juliank> Apparently something is marked both writable and executable in new library build
[11:55] <juliank> slyon: So sudo  systemd-run -P -p MemoryDenyWriteExecute=yes /lib/systemd/systemd-timesyncd
[11:55] <juliank> /lib/systemd/systemd-timesyncd: error while loading shared libraries: libcrypt.so.1: failed to map segment from shared object
[11:56] <juliank> slyon: It works fine without MemoryDenyWriteExecute, so I figure some toolchain update broke stuff
[11:56] <juliank> ginggs: doko ^ toolchain seems to spew out libraries with writable *and* executable sections now, I guess
[11:57] <juliank> on s390x
[12:00] <juliank> libcrypt1 from jammy -> good, libcrypt1 from proposed -> bad, only doc packaging change in libxcrypt upload itself
[12:02] <juliank> Indeed
[12:02] <juliank> │ -  LOAD           0x000000 0x0000000000000000 0x0000000000000000 0x02f36c 0x02f36c R E 0x1000
[12:02] <juliank> │ -  LOAD           0x02fa28 0x0000000000030a28 0x0000000000030a28 0x0005e0 0x008730 RW  0x1000
[12:02] <juliank> │ +  LOAD           0x000000 0x0000000000000000 0x0000000000000000 0x030008 0x038158 RWE 0x1000
[12:02] <juliank> Previous version of libcrypt1 had one LOAD header with R E and one with RW, new one has only one combined one with RWE
[12:03] <juliank> Wonder if it's new binutils or the gcc that landed in release
[12:05] <apw> (for the record i have removed libxcrypt from -proposed while this is investigated.)
[12:06] <juliank> thanks apw
[12:06] <juliank> building libcrypt with old binutils now
[12:07] <apw> that sounds like a negative change even if it is not the cause.
[12:11] <juliank> apw: It is the cause, the old binutils binary works fine
[12:12] <juliank> So, we should remove binutils from proposed before we end up breaking more libraries on s390x
[12:13] <juliank> writing some bug report
[12:13] <apw> (for the record i have removed binutils from -proposed while this is investigated.)
[12:13] <apw> juliank, removed ....
[12:14] <juliank> apw: Thanks
[12:14] <juliank> I filed https://bugs.launchpad.net/ubuntu/+source/binutils/+bug/1958642 to track this bug
[12:14] <ubottu> Launchpad bug 1958642 in binutils (Ubuntu) "New 2.37.50.20220119-0ubuntu1 Produces RWE load header on s390x" [High, New]
[12:14] <slyon> thank you for quickly dealing with this juliank and apw!
[12:30] <apw> juliank, nice analysis, thanks ...
[12:35] <apw> juliank, i've added the removals we have performed to the bug for tracking.
[12:52] <apw> that might be somethign we need to ask launchpad
[12:54] <cjwatson> hm?
[12:55] <juliank> cjwatson: We need to know which libraries got built on s390x since https://launchpad.net/ubuntu/+source/libxcrypt/1:4.4.27-1.1/+build/23079201 landed in the archive
[12:55] <juliank> cjwatson: um
[12:55] <juliank> cjwatson: sorry since the broken binutils did
[12:56] <juliank> cjwatson: Like "which package has built with/since https://launchpad.net/ubuntu/+source/binutils/2.37.50.20220119-0ubuntu1/+build/23076488 landed"
[12:56] <cjwatson> We don't have any better tools for finding that than you do
[12:57] <cjwatson> Easiest thing would probably be to go through https://launchpad.net/ubuntu/jammy/+builds?build_text=&build_state=all&arch_tag=s390x since the relevant time
[12:57] <juliank> cjwatson: yeah that's what I was looking for
[12:57] <juliank> :D
[12:57] <cjwatson> (and check build logs to confirm which binutils was used)
[12:58] <juliank> first let's see when libxcrypt upload was "done", it was 11:18 UTC yesterday
[12:59] <juliank> so s390x build of acl 2.3.1-1 in ubuntu jammy PROPOSED was the first one
[12:59] <juliank> I guess we need to download them all and check if they have RWE sections
[13:01] <juliank> hmm or not
[13:01] <juliank> I guess the timing is weirder than that
[13:02] <juliank> Jan 19 17:25 UTC was when binutils landed
[13:02] <juliank> I accidentally looked at libxcrypt again
[13:06] <juliank> So "s390x build of soci 4.0.1-5ubuntu1 in ubuntu jammy PROPOSED" seems the first build with that binutils
[13:09] <juliank> Now I need to write a script that downloads all debs built since then and checks for RWE sections, because it's been 100 builds since then
[13:09] <ahasenack> ugh
[13:10] <juliank> There are two alternatives: Just ignore the issue, just issue no-change rebuilds for them all
[13:10] <utkarsh2102> ubuntu-archive: hey, can we please remove php-doctrine-persistence and doctrine from jammy-proposed?
[13:16] <utkarsh2102> this will be re-syned in later; it's causing problems for the php-defaults migration
[13:17] <utkarsh2102> sil2100, cjwatson, RAOF^
[13:23] <utkarsh2102> LP: #1958646
[13:23] <ubottu> Launchpad bug 1958646 in php-doctrine-persistence (Ubuntu) "Please drop php-doctrine-persistence/2.3.0-2 and  doctrine/2.11.0+dfsg-1 from jammy-proposed" [Undecided, New] https://launchpad.net/bugs/1958646
[14:07] <sil2100> utkarsh2102: on it
[14:09] <utkarsh2102> sil2100: thank you v much! :D
[14:17] <sil2100> o/
[14:20] <LocutusOfBorg> jamespage, FYI I synced python-hvac, overriding your source hvac, so it goes in sync with Debian
[14:21] -queuebot:#ubuntu-release- New sync: python-hvac (jammy-proposed/primary) [0.11.2-1]
[14:23] <LocutusOfBorg> same for libfli
[14:23] -queuebot:#ubuntu-release- New sync: libfli (jammy-proposed/primary) [2.0-2]
[14:27] <LocutusOfBorg> xnox, dwarves-dfsg had delta, now included upstream and in Debian, got renamed into dwarves so the auto sync failed to pick it up. syncing
[14:27] -queuebot:#ubuntu-release- New sync: dwarves (jammy-proposed/primary) [1.22-1]
[14:36] <utkarsh2102> sil2100: thank you very much!
[14:36] <utkarsh2102> LocutusOfBorg: what about esys-particles? :)
[14:37] <LocutusOfBorg> utkarsh2102, ENOIDEA
[14:37] <utkarsh2102> heh
[14:37] <LocutusOfBorg> I hope with python transition moving forward something will auto heal
[14:37] <utkarsh2102> the more I look at it, the more I go crazy
[14:37] <utkarsh2102> indeed! that's what I thought, too
[14:38] <michagogo> Hi, quick question - how do MIRs work with respect to intersecting with SRUs?
[14:38] -queuebot:#ubuntu-release- New sync: djbdns (jammy-proposed/primary) [1:1.05-15]
[14:38] <michagogo> e.g. on bug #1935082, assuming I’m correct that the correct action would be adding the MIR’d package as a dependency of the Nvidia graphics drivers, would the correct course of action then be to SRU the graphics drivers in older releases to depend on the package as well?
[14:38] <ubottu> Bug 1935082 in egl-wayland (Ubuntu) "[MIR] egl-wayland" [Undecided, In Progress] https://launchpad.net/bugs/1935082
[14:39] <michagogo> (/are MIRs release-specific?)
[14:40] <LocutusOfBorg>   plib-doc 1:1.8.5-4 in sid (plib-doc_1.8.5.orig.tar.gz already exists
[14:40] <LocutusOfBorg>   in destination archive with different contents.)   -- janitor  Fri, 21
[14:40] <LocutusOfBorg>   Jan 2022 11:11:22 +0000
[14:40] <LocutusOfBorg> cjwatson, hello is that a bug? there is no difference from what I can see...
[14:49] <cjwatson> LocutusOfBorg: is that from an auto-sync attempt, an API request, ...?
[14:53] -queuebot:#ubuntu-release- Unapproved: accepted livecd-rootfs [source] (focal-proposed) [2.664.37]
[14:55] <xnox> LocutusOfBorg:  nice!
[14:56] <slyon> michagogo: SRU and MIR are usually handled individually. And MIRs are usually granted for a package version in a specific release and then maintained into the future release (until demoted)
[14:57] <slyon> if a change is needed in an older release, this would first need a SRU of the specific change for that package and then (once landed) a MIR check for that (possibly older version of the package)
[14:57] <michagogo> slyon: and what happens in HWE-type situations, where new driver versions are pushed to the older releases that then require the new package?
[14:59] <michagogo> And also in this case, the MIR was done regarding impish, which is now no longer in development
[15:00] <slyon> michagogo: I guess that is a case-to-case decision. maybe the driver could be patched to not require any new package? Or alternatively that required package might need to be patched to provide the new, required functionality
[15:01] <slyon> for this MIR, I assume the change would just be promoted in the current development release (jammy)
[15:01] <michagogo> It’s not a requirement as much as a significant performance regression AIUI
[15:02] <xnox> AA ubuntu-archive please remove libzpool4linux .deb binary alone from jammy-proposed, NBS abi transition to libzpool5linux see old binaries left on https://people.canonical.com/~ubuntu-archive/proposed-migration/update_excuses.html#zfs-linux
[15:03] -queuebot:#ubuntu-release- Unapproved: accepted update-manager [source] (focal-proposed) [1:20.04.10.10]
[15:03] <slyon> michagogo: in case of a regression, where the performance was good before and is bad now in the old release, that would be a candidate for an SRU IMO (depending on how big of a change it is9
[15:04] <michagogo> slyon: yeah, my understanding (as an observer from the side) is that as of driver 470 GPU acceleration requires this package
[15:05] <michagogo> Or something along those lines
[15:10] <slyon> michagogo: I'm not an expert on GPU acceleration and don't know how those HWE updates are pulled into default setups. I guess it would be best to file a bug about this regression at https://bugs.launchpad.net/ubuntu/+source/nvidia-graphics-drivers-470/+filebug and have the responsible team comment on it
[15:26] <LocutusOfBorg> cjwatson, auto sync fails over it
[15:26] <tseliot83> michagogo, I was thinking of adding the dependency in a new release. This, however, only makes sense where we are actually using Wayland
[15:27] <LocutusOfBorg> and also manual sync fails
[15:27] <LocutusOfBorg> syncpackage plib-doc tries to download the log of previous failures?
[15:38] <cjwatson> LocutusOfBorg: So the question is in fact how the current version managed to get in there in the first place: https://paste.ubuntu.com/p/4bqmPVGFsF/
[15:38] <cjwatson> LocutusOfBorg: We may have got a bit stricter on ensuring uniqueness of source package file names within archives since 2017, I suppose; I remember doing something along those lines a few years ago
[15:39] <cjwatson> LocutusOfBorg: I think a fakesync is going to be by far the easiest way out, though
[15:40] <LocutusOfBorg> yep thanks for confirming
[15:41] <LocutusOfBorg> I was already wondering about fakesync...
[15:41] <LocutusOfBorg> but meh, "intrepid" :D
[15:42] <LocutusOfBorg> well, difficult to do a fakesync
[15:45] <cjwatson> I'm not *certain* a fakesync will work, but maybe?
[15:45] <LocutusOfBorg> cjwatson, I don't like fakesync either, now people upgrading from -3.1 to -4 will get different tarball...
[15:45] <LocutusOfBorg> it did work
[15:45] <LocutusOfBorg> but I think I'll change to xz and upload in debian :D
[15:46] <cjwatson> that works too
[15:46] <cjwatson> or bump the upstream version with +repack or something
[15:46] <cjwatson> This is one of those things that dak should check but doesn't (or maybe didn't always)
[15:47] <cjwatson> https://tracker.debian.org/pkg/plib-doc shows the error if you dig
[15:57] <LocutusOfBorg> I can't find the error but I trust you
[16:04] <cjwatson> Not literally the error message, but if you look at the uploads of 1.8.5-1 and 1:1.8.5-1, you can see that they share an identical file name with different checksums
[16:04] <cjwatson> Which is a thing dak ought to have rejected
[16:05] <cjwatson> (but it was in 2008, so ...)
[16:26] <coreycb> hello, can an archive admin take a look at this package removal bug? https://bugs.launchpad.net/bugs/1957001 - that should help with the sqlalchemy blocking in proposed
[16:26] <ubottu> Launchpad bug 1957001 in python-sqlsoup (Ubuntu) "[RM] python-sqlsoup" [Undecided, New]
[16:28] <coreycb> the other issue blocking sqlalchemy from migrating is mailman lacking of support for sqlalchemy 1.4.x, and upstream doesn't seem to be in a hurry to fix it
[16:31] <coreycb> https://gitlab.com/mailman/mailman/-/issues/845
[16:31] <ubottu> Issue 845 in mailman/mailman "sqlalchemy 1.4.0 is incompatible with current Mailman core" [Opened]
[17:18] -queuebot:#ubuntu-release- New binary: node-postcss-preset-evergreen [amd64] (jammy-proposed/universe) [0.2.1+~cs33.0.7-3] (no packageset)
[17:18] -queuebot:#ubuntu-release- New binary: node-postcss-loader [amd64] (jammy-proposed/none) [4.2.0+~cs11.2.14-2] (no packageset)
[18:01] <coreycb> forgot to hightlight ubuntu-archive for my msg above ^
[18:03] -queuebot:#ubuntu-release- New binary: rustc [riscv64] (jammy-proposed/universe) [1.57.0+dfsg1+llvm-0ubuntu1] (i386-whitelist)
[18:18] <LocutusOfBorg> cjwatson,
[18:18] <LocutusOfBorg>  	2022-01-21 16:45:09 CET	Pending	Jammy	proposed	universe	doc	1:1.8.5-4fakesync1
[18:18] <LocutusOfBorg> looks like publisher is failing at it
[18:18] <LocutusOfBorg> anyway Uploading plib-doc_1.8.5-5.debian.tar.xz
[18:18] <LocutusOfBorg>  
[18:19] <LocutusOfBorg> not an issue anymore 😈
[18:23] <cjwatson> 2022-01-21 16:08:55 ERROR   PoolFileOverwriteError: c0f93cb2d6090779bed9777c5e56e184584f5b0d != 05a0273cbee72bd96f51f88a615bb300239ebb46 for /srv/launchpad.net/ubuntu-archive/ubuntu/pool/universe/p/plib-doc/plib-doc_1.8.5.orig.tar.gz, skipping. (OOPS-971593ea6433a115fe59ea0ea80e8af8)
[18:23] <cjwatson> yeah, indeed
[18:31] <LocutusOfBorg> -5~build1 uploaded and published successfully
[18:31] <LocutusOfBorg> so I think autosync will do its job on next run, thanks for the great support
=== mfo_ is now known as mfo
[23:19] -queuebot:#ubuntu-release- New binary: storm-lang [amd64] (jammy-proposed/none) [0.5.10-1] (no packageset)