guiverc | thank you bdmurray :) | 00:03 |
---|---|---|
-queuebot:#ubuntu-release- New binary: pyfltk [riscv64] (jammy-proposed/universe) [1.3.7+repack-1] (no packageset) | 00:55 | |
-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:00 | |
-queuebot:#ubuntu-release- Unapproved: accepted vitis-ai [source] (focal-proposed) [1.3.2-0ubuntu5~20.04.2] | 01:02 | |
-queuebot:#ubuntu-release- New binary: rustc [armhf] (jammy-proposed/universe) [1.57.0+dfsg1+llvm-0ubuntu1] (i386-whitelist) | 04:17 | |
-queuebot:#ubuntu-release- New binary: node-postcss-preset-evergreen [amd64] (jammy-proposed/universe) [0.2.1+~cs33.0.7-2] (no packageset) | 05:17 | |
-queuebot:#ubuntu-release- New binary: rust-condure [amd64] (jammy-proposed/universe) [1.3.1-1] (no packageset) | 05:18 | |
-queuebot:#ubuntu-release- New binary: pyfltk [amd64] (jammy-proposed/universe) [1.3.7+repack-2] (no packageset) | 05:20 | |
-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:22 | |
-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:23 | |
-queuebot:#ubuntu-release- New binary: rust-condure [s390x] (jammy-proposed/universe) [1.3.1-1] (no packageset) | 05:24 | |
-queuebot:#ubuntu-release- New binary: rust-condure [armhf] (jammy-proposed/universe) [1.3.1-1] (no packageset) | 05:26 | |
-queuebot:#ubuntu-release- New binary: pyfltk [armhf] (jammy-proposed/universe) [1.3.7+repack-2] (no packageset) | 05:28 | |
-queuebot:#ubuntu-release- New binary: pyfltk [arm64] (jammy-proposed/universe) [1.3.7+repack-2] (no packageset) | 05:29 | |
-queuebot:#ubuntu-release- New binary: rust-condure [riscv64] (jammy-proposed/universe) [1.3.1-1] (no packageset) | 05:59 | |
-queuebot:#ubuntu-release- New binary: pyfltk [riscv64] (jammy-proposed/universe) [1.3.7+repack-2] (no packageset) | 06:42 | |
-queuebot:#ubuntu-release- New binary: rustc [i386] (jammy-proposed/universe) [1.57.0+dfsg1+llvm-0ubuntu1] (i386-whitelist) | 07:57 | |
-queuebot:#ubuntu-release- New binary: rustc [arm64] (jammy-proposed/universe) [1.57.0+dfsg1+llvm-0ubuntu1] (i386-whitelist) | 10:15 | |
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:27 |
juliank | it seems s390x autopkgtest cloud is broken, investigating | 10:38 |
juliank | hmm systemd[1]: systemd-journald.service: Main process exited, code=exited, status=127/n/a | 10:41 |
juliank | i created an instance myself and it rebooted fine, but real ones mostly fail to come back up | 10:47 |
-queuebot:#ubuntu-release- New binary: python2-pip [amd64] (jammy-proposed/universe) [20.3.4+dfsg-3] (no packageset) | 11:17 | |
juliank | It seems libxcrypt is borked | 11:48 |
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:49 |
* apw looks | 11:50 | |
juliank | Investigating what's going on further | 11:50 |
juliank | sil2100: apw is looking at it | 11:50 |
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:51 |
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:52 |
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:54 |
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:55 |
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:56 |
juliank | on s390x | 11:57 |
juliank | libcrypt1 from jammy -> good, libcrypt1 from proposed -> bad, only doc packaging change in libxcrypt upload itself | 12:00 |
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:02 |
juliank | Wonder if it's new binutils or the gcc that landed in release | 12:03 |
apw | (for the record i have removed libxcrypt from -proposed while this is investigated.) | 12:05 |
juliank | thanks apw | 12:06 |
juliank | building libcrypt with old binutils now | 12:06 |
apw | that sounds like a negative change even if it is not the cause. | 12:07 |
juliank | apw: It is the cause, the old binutils binary works fine | 12:11 |
juliank | So, we should remove binutils from proposed before we end up breaking more libraries on s390x | 12:12 |
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:13 |
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:14 |
apw | juliank, nice analysis, thanks ... | 12:30 |
apw | juliank, i've added the removals we have performed to the bug for tracking. | 12:35 |
apw | that might be somethign we need to ask launchpad | 12:52 |
cjwatson | hm? | 12:54 |
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:55 |
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:56 |
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:57 |
juliank | first let's see when libxcrypt upload was "done", it was 11:18 UTC yesterday | 12:58 |
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 | 12:59 |
juliank | hmm or not | 13:01 |
juliank | I guess the timing is weirder than that | 13:01 |
juliank | Jan 19 17:25 UTC was when binutils landed | 13:02 |
juliank | I accidentally looked at libxcrypt again | 13:02 |
juliank | So "s390x build of soci 4.0.1-5ubuntu1 in ubuntu jammy PROPOSED" seems the first build with that binutils | 13:06 |
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:09 |
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:10 |
utkarsh2102 | this will be re-syned in later; it's causing problems for the php-defaults migration | 13:16 |
utkarsh2102 | sil2100, cjwatson, RAOF^ | 13:17 |
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 | 13:23 |
sil2100 | utkarsh2102: on it | 14:07 |
utkarsh2102 | sil2100: thank you v much! :D | 14:09 |
sil2100 | o/ | 14:17 |
LocutusOfBorg | jamespage, FYI I synced python-hvac, overriding your source hvac, so it goes in sync with Debian | 14:20 |
-queuebot:#ubuntu-release- New sync: python-hvac (jammy-proposed/primary) [0.11.2-1] | 14:21 | |
LocutusOfBorg | same for libfli | 14:23 |
-queuebot:#ubuntu-release- New sync: libfli (jammy-proposed/primary) [2.0-2] | 14:23 | |
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:27 | |
utkarsh2102 | sil2100: thank you very much! | 14:36 |
utkarsh2102 | LocutusOfBorg: what about esys-particles? :) | 14:36 |
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:37 |
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:38 |
michagogo | (/are MIRs release-specific?) | 14:39 |
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:40 |
cjwatson | LocutusOfBorg: is that from an auto-sync attempt, an API request, ...? | 14:49 |
-queuebot:#ubuntu-release- Unapproved: accepted livecd-rootfs [source] (focal-proposed) [2.664.37] | 14:53 | |
xnox | LocutusOfBorg: nice! | 14:55 |
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:56 |
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:57 |
michagogo | And also in this case, the MIR was done regarding impish, which is now no longer in development | 14:59 |
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:00 |
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:01 |
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:02 |
-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:03 |
michagogo | slyon: yeah, my understanding (as an observer from the side) is that as of driver 470 GPU acceleration requires this package | 15:04 |
michagogo | Or something along those lines | 15:05 |
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:10 |
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:26 |
LocutusOfBorg | and also manual sync fails | 15:27 |
LocutusOfBorg | syncpackage plib-doc tries to download the log of previous failures? | 15:27 |
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:38 |
cjwatson | LocutusOfBorg: I think a fakesync is going to be by far the easiest way out, though | 15:39 |
LocutusOfBorg | yep thanks for confirming | 15:40 |
LocutusOfBorg | I was already wondering about fakesync... | 15:41 |
LocutusOfBorg | but meh, "intrepid" :D | 15:41 |
LocutusOfBorg | well, difficult to do a fakesync | 15:42 |
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:45 |
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:46 |
cjwatson | https://tracker.debian.org/pkg/plib-doc shows the error if you dig | 15:47 |
LocutusOfBorg | I can't find the error but I trust you | 15:57 |
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:04 |
cjwatson | (but it was in 2008, so ...) | 16:05 |
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:26 |
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:28 |
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] | 16:31 |
-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) | 17:18 | |
coreycb | forgot to hightlight ubuntu-archive for my msg above ^ | 18:01 |
-queuebot:#ubuntu-release- New binary: rustc [riscv64] (jammy-proposed/universe) [1.57.0+dfsg1+llvm-0ubuntu1] (i386-whitelist) | 18:03 | |
LocutusOfBorg | cjwatson, | 18:18 |
LocutusOfBorg | 2022-01-21 16:45:09 CETPendingJammyproposeduniversedoc1: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:18 | |
LocutusOfBorg | not an issue anymore 😈 | 18:19 |
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:23 |
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 | 18:31 |
=== mfo_ is now known as mfo | ||
-queuebot:#ubuntu-release- New binary: storm-lang [amd64] (jammy-proposed/none) [0.5.10-1] (no packageset) | 23:19 |
Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!