/srv/irclogs.ubuntu.com/2022/01/21/#ubuntu-release.txt

guivercthank 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
LocutusOfBorghello, should I start a new ocaml transition?10:27
LocutusOfBorglots of ocaml packages are bd unistallable now, but maybe its better to wait for python?10:27
juliankit seems s390x autopkgtest cloud is broken, investigating10:38
juliankhmm systemd[1]: systemd-journald.service: Main process exited, code=exited, status=127/n/a10:41
julianki created an instance myself and it rebooted fine, but real ones mostly fail to come back up10:47
-queuebot:#ubuntu-release- New binary: python2-pip [amd64] (jammy-proposed/universe) [20.3.4+dfsg-3] (no packageset)11:17
juliankIt seems libxcrypt is borked11:48
juliankI noticed all failed tests where with libxcrypt from proposed11:49
juliankI created a VM, installed it, and restarted systemd-timesyncd to end up with11:49
juliankJan 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 object11:49
juliankubuntu-archive ^ please remove broken libxcrypt from proposed11:49
* apw looks11:50
juliankInvestigating what's going on further11:50
julianksil2100: apw is looking at it11:50
sil2100o/11:51
juliankSo the odd thing is systemd-timesyncd runs fine *outside* the service, I think *something* in new libcrypt1 is just not compatible with systemd sandboxing11:51
seb128juliank, 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
juliankseb128: Yes, that happens in parallel11:52
juliankseb128: Just want to avoid stuff building against the potentially borked library11:52
seb128ack11:52
juliankseb128: So, turns out that sudo  systemd-run -P -p MemoryDenyWriteExecute=yes /lib/systemd/systemd-timesyncd11:54
juliank/lib/systemd/systemd-timesyncd: error while loading shared libraries: libcrypt.so.1: failed to map segment from shared object11:54
juliankseb128: I think maybe the new gcc is the broken thing11:54
juliankthe new libxcrypt was effectively a no-change rebuild11:54
juliankApparently something is marked both writable and executable in new library build11:55
juliankslyon: So sudo  systemd-run -P -p MemoryDenyWriteExecute=yes /lib/systemd/systemd-timesyncd11:55
juliank/lib/systemd/systemd-timesyncd: error while loading shared libraries: libcrypt.so.1: failed to map segment from shared object11:55
juliankslyon: It works fine without MemoryDenyWriteExecute, so I figure some toolchain update broke stuff11:56
juliankginggs: doko ^ toolchain seems to spew out libraries with writable *and* executable sections now, I guess11:56
juliankon s390x11:57
julianklibcrypt1 from jammy -> good, libcrypt1 from proposed -> bad, only doc packaging change in libxcrypt upload itself12:00
juliankIndeed12:02
juliank│ -  LOAD           0x000000 0x0000000000000000 0x0000000000000000 0x02f36c 0x02f36c R E 0x100012:02
juliank│ -  LOAD           0x02fa28 0x0000000000030a28 0x0000000000030a28 0x0005e0 0x008730 RW  0x100012:02
juliank│ +  LOAD           0x000000 0x0000000000000000 0x0000000000000000 0x030008 0x038158 RWE 0x100012:02
juliankPrevious version of libcrypt1 had one LOAD header with R E and one with RW, new one has only one combined one with RWE12:02
juliankWonder if it's new binutils or the gcc that landed in release12:03
apw(for the record i have removed libxcrypt from -proposed while this is investigated.)12:05
juliankthanks apw12:06
juliankbuilding libcrypt with old binutils now12:06
apwthat sounds like a negative change even if it is not the cause.12:07
juliankapw: It is the cause, the old binutils binary works fine12:11
juliankSo, we should remove binutils from proposed before we end up breaking more libraries on s390x12:12
juliankwriting some bug report12:13
apw(for the record i have removed binutils from -proposed while this is investigated.)12:13
apwjuliank, removed ....12:13
juliankapw: Thanks12:14
juliankI filed https://bugs.launchpad.net/ubuntu/+source/binutils/+bug/1958642 to track this bug12:14
ubottuLaunchpad bug 1958642 in binutils (Ubuntu) "New 2.37.50.20220119-0ubuntu1 Produces RWE load header on s390x" [High, New]12:14
slyonthank you for quickly dealing with this juliank and apw!12:14
apwjuliank, nice analysis, thanks ...12:30
apwjuliank, i've added the removals we have performed to the bug for tracking.12:35
apwthat might be somethign we need to ask launchpad12:52
cjwatsonhm?12:54
juliankcjwatson: 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 archive12:55
juliankcjwatson: um12:55
juliankcjwatson: sorry since the broken binutils did12:55
juliankcjwatson: Like "which package has built with/since https://launchpad.net/ubuntu/+source/binutils/2.37.50.20220119-0ubuntu1/+build/23076488 landed"12:56
cjwatsonWe don't have any better tools for finding that than you do12:56
cjwatsonEasiest thing would probably be to go through https://launchpad.net/ubuntu/jammy/+builds?build_text=&build_state=all&arch_tag=s390x since the relevant time12:57
juliankcjwatson: yeah that's what I was looking for12:57
juliank:D12:57
cjwatson(and check build logs to confirm which binutils was used)12:57
juliankfirst let's see when libxcrypt upload was "done", it was 11:18 UTC yesterday12:58
juliankso s390x build of acl 2.3.1-1 in ubuntu jammy PROPOSED was the first one12:59
juliankI guess we need to download them all and check if they have RWE sections12:59
juliankhmm or not13:01
juliankI guess the timing is weirder than that13:01
juliankJan 19 17:25 UTC was when binutils landed13:02
juliankI accidentally looked at libxcrypt again13:02
juliankSo "s390x build of soci 4.0.1-5ubuntu1 in ubuntu jammy PROPOSED" seems the first build with that binutils13:06
juliankNow 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 then13:09
ahasenackugh13:09
juliankThere are two alternatives: Just ignore the issue, just issue no-change rebuilds for them all13:10
utkarsh2102ubuntu-archive: hey, can we please remove php-doctrine-persistence and doctrine from jammy-proposed?13:10
utkarsh2102this will be re-syned in later; it's causing problems for the php-defaults migration13:16
utkarsh2102sil2100, cjwatson, RAOF^13:17
utkarsh2102LP: #195864613:23
ubottuLaunchpad 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/195864613:23
sil2100utkarsh2102: on it14:07
utkarsh2102sil2100: thank you v much! :D14:09
sil2100o/14:17
LocutusOfBorgjamespage, FYI I synced python-hvac, overriding your source hvac, so it goes in sync with Debian14:20
-queuebot:#ubuntu-release- New sync: python-hvac (jammy-proposed/primary) [0.11.2-1]14:21
LocutusOfBorgsame for libfli14:23
-queuebot:#ubuntu-release- New sync: libfli (jammy-proposed/primary) [2.0-2]14:23
LocutusOfBorgxnox, dwarves-dfsg had delta, now included upstream and in Debian, got renamed into dwarves so the auto sync failed to pick it up. syncing14:27
-queuebot:#ubuntu-release- New sync: dwarves (jammy-proposed/primary) [1.22-1]14:27
utkarsh2102sil2100: thank you very much!14:36
utkarsh2102LocutusOfBorg: what about esys-particles? :)14:36
LocutusOfBorgutkarsh2102, ENOIDEA14:37
utkarsh2102heh14:37
LocutusOfBorgI hope with python transition moving forward something will auto heal14:37
utkarsh2102the more I look at it, the more I go crazy14:37
utkarsh2102indeed! that's what I thought, too14:37
michagogoHi, 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
michagogoe.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
ubottuBug 1935082 in egl-wayland (Ubuntu) "[MIR] egl-wayland" [Undecided, In Progress] https://launchpad.net/bugs/193508214: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 exists14:40
LocutusOfBorg  in destination archive with different contents.)   -- janitor  Fri, 2114:40
LocutusOfBorg  Jan 2022 11:11:22 +000014:40
LocutusOfBorgcjwatson, hello is that a bug? there is no difference from what I can see...14:40
cjwatsonLocutusOfBorg: 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
xnoxLocutusOfBorg:  nice!14:55
slyonmichagogo: 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
slyonif 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
michagogoslyon: 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
michagogoAnd also in this case, the MIR was done regarding impish, which is now no longer in development14:59
slyonmichagogo: 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 functionality15:00
slyonfor this MIR, I assume the change would just be promoted in the current development release (jammy)15:01
michagogoIt’s not a requirement as much as a significant performance regression AIUI15:01
xnoxAA 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-linux15:02
-queuebot:#ubuntu-release- Unapproved: accepted update-manager [source] (focal-proposed) [1:20.04.10.10]15:03
slyonmichagogo: 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 is915:03
michagogoslyon: yeah, my understanding (as an observer from the side) is that as of driver 470 GPU acceleration requires this package15:04
michagogoOr something along those lines15:05
slyonmichagogo: 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 it15:10
LocutusOfBorgcjwatson, auto sync fails over it15:26
tseliot83michagogo, I was thinking of adding the dependency in a new release. This, however, only makes sense where we are actually using Wayland15:26
LocutusOfBorgand also manual sync fails15:27
LocutusOfBorgsyncpackage plib-doc tries to download the log of previous failures?15:27
cjwatsonLocutusOfBorg: 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
cjwatsonLocutusOfBorg: 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 ago15:38
cjwatsonLocutusOfBorg: I think a fakesync is going to be by far the easiest way out, though15:39
LocutusOfBorgyep thanks for confirming15:40
LocutusOfBorgI was already wondering about fakesync...15:41
LocutusOfBorgbut meh, "intrepid" :D15:41
LocutusOfBorgwell, difficult to do a fakesync15:42
cjwatsonI'm not *certain* a fakesync will work, but maybe?15:45
LocutusOfBorgcjwatson, I don't like fakesync either, now people upgrading from -3.1 to -4 will get different tarball...15:45
LocutusOfBorgit did work15:45
LocutusOfBorgbut I think I'll change to xz and upload in debian :D15:45
cjwatsonthat works too15:46
cjwatsonor bump the upstream version with +repack or something15:46
cjwatsonThis is one of those things that dak should check but doesn't (or maybe didn't always)15:46
cjwatsonhttps://tracker.debian.org/pkg/plib-doc shows the error if you dig15:47
LocutusOfBorgI can't find the error but I trust you15:57
cjwatsonNot 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 checksums16:04
cjwatsonWhich is a thing dak ought to have rejected16:04
cjwatson(but it was in 2008, so ...)16:05
coreycbhello, 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 proposed16:26
ubottuLaunchpad bug 1957001 in python-sqlsoup (Ubuntu) "[RM] python-sqlsoup" [Undecided, New]16:26
coreycbthe 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 it16:28
coreycbhttps://gitlab.com/mailman/mailman/-/issues/84516:31
ubottuIssue 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
coreycbforgot 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
LocutusOfBorgcjwatson,18:18
LocutusOfBorg 2022-01-21 16:45:09 CETPendingJammyproposeduniversedoc1:1.8.5-4fakesync118:18
LocutusOfBorglooks like publisher is failing at it18:18
LocutusOfBorganyway Uploading plib-doc_1.8.5-5.debian.tar.xz18:18
LocutusOfBorg 18:18
LocutusOfBorgnot an issue anymore 😈18:19
cjwatson2022-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
cjwatsonyeah, indeed18:23
LocutusOfBorg-5~build1 uploaded and published successfully18:31
LocutusOfBorgso I think autosync will do its job on next run, thanks for the great support18: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!