[00:42] -queuebot:#ubuntu-release- Unapproved: clamav (bionic-proposed/main) [0.103.2+dfsg-0ubuntu0.18.04.2 => 0.103.2+dfsg-0ubuntu0.18.04.3] (ubuntu-server)
[00:51] -queuebot:#ubuntu-release- Unapproved: accepted livecd-rootfs [source] (focal-proposed) [2.664.36]
=== guiverc2 is now known as guiverc
[08:28] <LocutusOfBorg> athos, hello, your python-debian upload adding zstd support broke build of debmutate
[09:27] <LocutusOfBorg> vorlon, can we remove from jammy pdns/armhf? the configure script fails because 32 bit is not supported anymore (due to 2k38)
[09:27] <LocutusOfBorg> e.g. https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=992593
[09:27] <ubottu> Debian bug 992593 in ftp.debian.org "RM: pdns-recursor [armel armhf i386 mipsel] -- ROM; 32bit time_t archs unsupported" [Normal, Open]
[09:27] <LocutusOfBorg> e.g. https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=998816
[09:27] <ubottu> Debian bug 998816 in ftp.debian.org "RM: pdns [armel armhf i386 mipsel] -- ROM; 32bit time_t archs unsupported" [Normal, Open]
[09:29] <LocutusOfBorg> you know, 2038 is too soon to not take care of it now :D
[09:44] -queuebot:#ubuntu-release- New binary: systemd [s390x] (jammy-proposed/main) [249.5-2ubuntu1] (core, i386-whitelist)
[09:45] -queuebot:#ubuntu-release- New binary: systemd [amd64] (jammy-proposed/main) [249.5-2ubuntu1] (core, i386-whitelist)
[09:49] -queuebot:#ubuntu-release- New binary: systemd [i386] (jammy-proposed/main) [249.5-2ubuntu1] (core, i386-whitelist)
[09:50] -queuebot:#ubuntu-release- New binary: systemd [armhf] (jammy-proposed/main) [249.5-2ubuntu1] (core, i386-whitelist)
[09:50] -queuebot:#ubuntu-release- New binary: systemd [ppc64el] (jammy-proposed/main) [249.5-2ubuntu1] (core, i386-whitelist)
[10:08] -queuebot:#ubuntu-release- New binary: systemd [arm64] (jammy-proposed/main) [249.5-2ubuntu1] (core, i386-whitelist)
=== doko_ is now known as doko
[11:57] <foka_> Hi! On https://launchpad.net/ubuntu/+source/golang-github-google-wire/0.5.0-1 , it shows that the armhf build failed, but when I clicked into it at https://launchpad.net/ubuntu/+source/golang-github-google-wire/0.5.0-1/+build/22577414 , it simply says "Failed to build" without any actual link to the build log.
[11:59] <foka_> Should I be concerned? I.e., will the autobuilder try to build it again automatically?  Or does it require a manual trigger to rebuild?  Many thanks!
[12:00] <athos> LocutusOfBorg: ack, I will re-work the patch with upstream this week so we can drop that delta asap :)
[12:01] <LocutusOfBorg> thanks without that fix we can't progress with transitions :(
[12:09] <cjwatson> foka_: it'll need to be retried manually
[12:10] <foka_> cjwatson: Many thanks!  BTW, how come the build log is inaccessible in this particular case?
[12:11] <cjwatson> foka_: It seems to have crashed very early before really getting to the point of creating a build log.  Not quite sure why, maybe network issue
[12:11] <cjwatson> foka_: I've retried it now
[12:11] <foka_> cjwatson: Awesome! Thanks a million!
=== cpaelzer_ is now known as cpaelzer
[12:17] <athos> LocutusOfBorg: The issues lies in debmutate itself: it does not consider the possibility if a non-integer character being present in the debian revision of python-debian
[12:17] <athos> LocutusOfBorg: this was fixed in https://salsa.debian.org/jelmer/debmutate/-/commit/f4e9bd09f05dbd3291804e2c524e5e7dfc1dadbe
[12:17] <ubottu> Commit f4e9bd0 in jelmer/debmutate "Parse python debian version using Version object."
[12:17] <LocutusOfBorg> thanks so I start by uploading debmutate then :D
[12:18] <athos> LocutusOfBorg: It seems that the maintainer alerady cut a new release containing that fix, but he did not upload it yet :(
[12:20] <athos> LocutusOfBorg: would you like me to prepare that patch with the fix and ping the Debian maintainer for the upload? :)
[12:21] <LocutusOfBorg> athos, I'm uploading that fix in Ubuntu
[12:21] <LocutusOfBorg> I'll sync once the maintainer uploads
[12:21] <LocutusOfBorg> if you want to ping for an upload, feel free
[12:27] <LocutusOfBorg> ok as soon as you upload python-debian, debmutate should build fine
[13:15] -queuebot:#ubuntu-release- New: accepted cryptsetup [riscv64] (jammy-proposed) [2:2.4.2-1ubuntu1]
[13:15] -queuebot:#ubuntu-release- New: accepted systemd [arm64] (jammy-proposed) [249.5-2ubuntu1]
[13:15] -queuebot:#ubuntu-release- New: accepted systemd [i386] (jammy-proposed) [249.5-2ubuntu1]
[13:15] -queuebot:#ubuntu-release- New: accepted systemd [s390x] (jammy-proposed) [249.5-2ubuntu1]
[13:15] -queuebot:#ubuntu-release- New: accepted systemd [amd64] (jammy-proposed) [249.5-2ubuntu1]
[13:15] -queuebot:#ubuntu-release- New: accepted systemd [ppc64el] (jammy-proposed) [249.5-2ubuntu1]
[13:15] -queuebot:#ubuntu-release- New: accepted systemd [armhf] (jammy-proposed) [249.5-2ubuntu1]
[14:36] <kanashiro> ubuntu-archive: could any of you please take a look at LP #1953026 ?
[14:36] <ubottu> Launchpad bug 1953026 in ruby-psych (Ubuntu) "[RM] Remove from Jammy to unblock ruby3.0 transition" [Undecided, New] https://launchpad.net/bugs/1953026
[15:10] <xnox> vorlon: schopin: is openssl v3 likely to migrate soon? as it entagles with linux v5.15 migration. In the kernel team, we are discussing if we should rebuild kernel v5.15 against 1.1.1 to make it migrate; and then rebuild against openssl v3 straight after.
[15:10] <schopin> I wouldn't say soon, no :)
[15:12] <xnox> schopin:  do we need creative solution to get the remaining packages over the board?
[15:12] <xnox> schopin:  i'm sure we can afford to demote the remaining leafs to proposed.
[15:13] <sil2100> xnox: are you volunteering to help out with the openssl3 transition?! THANKS :D
[15:13] <sil2100> j/k of course ;)
[15:17] <schopin> I don't know what you mean by "demoting the leafs to proposed" ?
[15:19] -queuebot:#ubuntu-release- New: accepted oem-sutton.newell-carl-meta [sync] (focal-proposed) [20.04~ubuntu1]
[15:20] <xnox> schopin:  remove package from jammy-release, publish it in jammy-proposed, and block it from migrating. For example burp serf
[15:21] <xnox> schopin:  then openssl v3 will be considered for migration, and burp serf become uninstallable mess in jammy-proposed like lots of other broken uninstallable stuff we have in jammy proposed that nobody cares about
[15:21] -queuebot:#ubuntu-release- New binary: oem-sutton.newell-carl-meta [amd64] (focal-proposed/none) [20.04~ubuntu1] (canonical-oem-metapackages)
[15:23] <schopin> There's still work to be done on the "rebuilding the whole world" side of things, but I'm liking this demotion move :)
[15:24] <xnox> schopin:  we always do that in the end of big transitions, cause in the end there is leftovers.
[15:35] -queuebot:#ubuntu-release- New: accepted oem-sutton.newell-carleton-meta [sync] (focal-proposed) [20.04~ubuntu1]
[15:38] -queuebot:#ubuntu-release- New binary: oem-sutton.newell-carleton-meta [amd64] (focal-proposed/none) [20.04~ubuntu1] (canonical-oem-metapackages)
[16:13] <vorlon> xnox, schopin: openssl needs to migrate soon; please don't work around it from the kernel side.
[16:40] -queuebot:#ubuntu-release- New: accepted oem-sutton.newell-carlisle-meta [sync] (focal-proposed) [20.04~ubuntu1]
[16:45] -queuebot:#ubuntu-release- New binary: oem-sutton.newell-carlisle-meta [amd64] (focal-proposed/none) [20.04~ubuntu1] (canonical-oem-metapackages)
[16:45] <juliank> vorlon: Should we actually set SMOOTH_UPDATES = libs oldlibs in britney.conf; such that transitions are smoothed by having new libraries in release pocket asap while keeping the old one around?
[16:46] <juliank> (I don't know the impact and how it interacts with LP)
[16:50] <vorlon> juliank: I don't know anything about the implementation of this, but it sounds on the surface like something we want
[16:51] <vorlon> in practice p-m never deletes binaries from the Ubuntu release pocket, regardless of package section
[16:52] -queuebot:#ubuntu-release- New: accepted oem-sutton.newell-carl-meta [amd64] (focal-proposed) [20.04~ubuntu1]
[16:52] -queuebot:#ubuntu-release- New: accepted oem-sutton.newell-carlisle-meta [amd64] (focal-proposed) [20.04~ubuntu1]
[16:52] -queuebot:#ubuntu-release- New: accepted oem-sutton.newell-carleton-meta [amd64] (focal-proposed) [20.04~ubuntu1]
[16:55] <sil2100> vorlon, bdmurray, seb128: hey! So while looking at some intel-iot issues etc. I noticed that the daily images for focal are uh, super oversized!
[16:55] <sil2100> vorlon, bdmurray, seb128: 5.6G - for example here http://cdimage.ubuntu.com/focal/daily-live/20211202/
[16:58] <bdmurray> any ideas as to why?
[17:02] <sil2100> Didn't have time to investigate yet, sadly
[17:03] <sil2100> Weirdly, the intel-iot images weren't that oversized, ones that I built today
[17:03] <sil2100> And those basically only have a different kernel..?
[17:14] -queuebot:#ubuntu-release- New: accepted oem-sutton.newell-carol-meta [sync] (focal-proposed) [20.04~ubuntu1]
[17:18] -queuebot:#ubuntu-release- New binary: oem-sutton.newell-carol-meta [amd64] (focal-proposed/none) [20.04~ubuntu1] (canonical-oem-metapackages)
[17:23] <bdmurray> I'll try and have a look today
[17:29] <xnox> vorlon:  ok, agree. let me see if i can make any useful contributions for openssl to migrate.
[17:34] <xnox> vorlon:  are you working on fixing up https://github.com/stefanberger/swtpm/pull/620 or do you need someone else to pick up reworking changes from the feedback?
[17:34] <ubottu> Pull 620 in stefanberger/swtpm "Openssl not certtool" [Open]
[17:45] <vorlon> xnox: not actively working on it right now but it's still on my radar
[17:45] <vorlon> xnox: I'm not officially at work right now and am only putting my oar in on openssl so that it doesn't become a bigger problem for me when I'm back next week ;)
[17:49] <bdmurray> Any idea why fenics-basix wasn't autosync'ed? bug 1953038
[17:49] <ubottu> Bug 1953038 in Ubuntu "fenics-basix is missing" [Undecided, New] https://launchpad.net/bugs/1953038
[17:53] <vorlon> xnox: e.g.: https://launchpad.net/ubuntu/+source/burp/2.4.0-3ubuntu1
[17:54] <vorlon> bdmurray: it did sync and was deleted https://launchpad.net/ubuntu/+source/fenics-basix/+publishinghistory
[17:54] <vorlon> sil2100: ^^ you said 'temporarily removed', should it be restored now?
[17:56] <bdmurray> vorlon: ah, thanks!
[18:01] <xnox> uploaded swtpm fixup for openssl v3
[18:09] <vorlon> juliank: why is britney selectively listing output of reverse-dep autopkgtests under https://people.canonical.com/~ubuntu-archive/proposed-migration/update_excuses.html#openssl for packages whose tests have passed on all archs?  I've never known the suppression of excessive verbosity to be buggy before
[18:10] <juliank> vorlon: I'd have to investigate that
[18:12] <foka_> Hi again! https://launchpad.net/ubuntu/+source/golang-github-rogpeppe-go-internal/1.8.0-3/+build/22579307 failed to build with no build log. Does it need to be retried manually too?  :-)  (Thanks in advance!)
[18:12] <xnox> uploaded tpm2-pkcs11 fixup for openssl v3
[18:12] <xnox> foka_:  yes, retried.
[18:13] <foka_> xnox: Wow, that was quick. Many thanks!
[18:15] <xnox> foka_:  yeah s390x is fast =)
[18:15] <xnox> build completed and awaiting publishing
[18:17] <foka_> xnox: Thank you for your quick responses!  And wow, that build on s390x is fast too!
[18:17] <vorlon> hmm hmmm libcrypt-openssl-pkcs12-perl fix or toss
[18:17] <vorlon> no revdeps
[18:17] <vorlon> and I'm not enthusiastic about fixing all this perl
[18:21] <foka_> By the way, is there any automatic mechanism for notifying someone, say, the release team, or the package maintainer, about such failed builds?  Or do they get caught only when someone notices them, e.g. in proposed-migration update_excuses?
[18:28] <xnox> foka_:  +1 / release team, do notice this on update_excuses as missing builds .....
[18:28] <xnox> it is rare
[18:28] <xnox> merging m2crypto to see if it will get better
[18:36] <kanashiro> vorlon, when you have some time could you please take a look at LP #1953026 ?
[18:36] <ubottu> Launchpad bug 1953026 in ruby-psych (Ubuntu) "[RM] Remove from Jammy to unblock ruby3.0 transition" [Undecided, New] https://launchpad.net/bugs/1953026
[18:36] <foka_> xnox: I guess I was "lucky" that it happened to two of my packages uploads two days in a row, i.e. golang-github-google-wire/0.5.0-1 on armhf yesterday (which cjwatson fixed for me), and golang-github-rogpeppe-go-internal/1.8.0-3 on s390x today, probably due to transient network issues.
[18:37] <foka_> xnox: But yeah, normally it is rare, and I suppose these missing builds are usually dealt with before a new release. :-)
[18:39] <foka_> xnox: I happen to be trying to get hugo 0.89.4-2 migrated from proposed, and that's why I happen to be watching its dependency, golang-github-rogpeppe-go-internal-dev (>= 1.8.0)  :)
[18:47] <foka_> xnox: I think I was a bit greedy and hoping for some kind of automatic daily or weekly rebuild mechanism for such fails-before-build-environment-has-sprung-up would exist, but indeed, it is easier said than done.
[18:49] <foka_> xnox: Anyhow, thank you so much for your help!  I am so glad I can always reach out to this channel #ubuntu-release and have my problems solved so promptly!  Thank you all!
[18:51] <vorlon> LocutusOfBorg: pdns/armhf removed (relevantly, because Debian has also done the same and the package has migrated to testing)
[18:53] <vorlon> kanashiro: for future reference, the checks I want to see output from to be sure there are no revdeps are 'reverse-depends src:ruby-ferret' and 'reverse-depends src:ruby-ferret -a source'; to cover a) any binaries of different names without me having to look it up, and b) test-rev-deps in addition to build-deps
[18:55] <kanashiro> vorlon, ack, do you want me to do that now?
[18:55] <vorlon> kanashiro: nah, doing it now
[18:55] <kanashiro> vorlon, sorry for the extra work
[18:55] <vorlon> anyway I've done the first two and will deal with the ruby-psych tree after lunch
[18:55] <kanashiro> ty!
[18:57] <vorlon> kanashiro: did you have a specific recommendation wrt what do do with jruby and its reverse-dependencies?  do you expect these to require further sourceful uploads to be installable again in the future?
[19:00] <kanashiro> vorlon, I am not closely following what happens with jruby but the puppet maintainers were trying to get jruby in shape, I am not sure about the current status
[19:01] <vorlon> right - the purpose of the question is to know, when removing these packages, if I need to tag them for us to re-add on the Ubuntu side if and when Debian fixes ruby-psych without there being uploads of jruby etc
[19:02] <vorlon> if the answer is "the current package will never work again in Debian or Ubuntu with ruby3.0 without a sourceful upload", then I can just delete
[19:03] <kanashiro> it will require a sourceful upload
[19:21] <xnox> vorlon:  sil2100: nodejs, should be built against internal openssl. In the past it was done when nodejs major version declared 1.0.2.x openssl abi for its modules; and then we switched to system one once nodejs itself switched to system openssl.
[19:22] <xnox> vorlon:  sil2100: the next nodejs i.e. 17 will have to use internal openssl too, because they are not using upstream openssl but the quick openssl 3 fork.
[19:28] <xnox> merged m2crypto, and tried to fix a few things in it.
[19:28] <xnox> it does not seem like m2crypto is openssl v3 ready
[19:28] <xnox> i still get some test suite failures which i cannot explain.
[19:38] <xnox> i wonder if we can somehow ship nodejs v18 in 22.04
[20:34] <vorlon> kanashiro: ruby-psych b-d: jruby, jruby b-d: ruby-psych, are we going to have an annoying rebootstrap here?
[20:39] <xnox> uploaded nodejs, and already regret it
[20:39] <xnox> cause it will trigger the world of tests; and like spam me into the new year about failing to migrate
[20:39] <xnox> but it is the right thing to do for the openssl v3 transition.
[20:55] <vorlon> kanashiro: so actually it looks to me like plm will not need a rebuild for ruby3.0, it just needs jruby to be present; therefore I'm adding it to extra-removals
[20:57] <kanashiro> vorlon, ack
[20:58] <vorlon> kanashiro: jruby also has no runtime dependencies on ruby, aside from ruby-psych; so I'm not clear why this would need a sourceful reupload in Debian either. So I'm going to just add it to extra-removals as well to be on the safe side
[20:59] <xnox> mwhudson:  https://launchpadlibrarian.net/571939110/buildlog_ubuntu-jammy-amd64.m2crypto_0.38.0-1ubuntu1_BUILDING.txt.gz if you want to have some fun
[20:59] <xnox> somehow it doesn't like calling readlines()
[20:59] <xnox> and if one skips that test, some other test bombs out, skip that one too, it bombs more.....
[21:00] <xnox> as if something is stuck inside shared library.
[21:02] <vorlon> xnox: any objections to me dropping libcrypt-openssl-pkcs12-perl?
[21:05] <vorlon> xnox: and shall I start looking at serf?
[21:05] <vorlon> n/m that's already fixed
[21:05]  * vorlon refreshes
[21:07] <vorlon> ginggs: do you understand why python3.9 autopkgtest is failing with new openssl only on ppc64el?
[21:10] <sergiodj> I'm looking at groonga and lighttpd (both blocking libxcrypt).  I can't reproduce the failure with the former, and the latter is apparently having problems with the proxy when it accessing 127.0.0.1.  some mistery for this afternoon
[21:11] <xnox> vorlon:  took a stab at improving m2crypto, but don't understand the last failure and if it is safe to ignore or not (and skipping that one bombs out in the next test case, and so on)
[21:11] <xnox> let me see libcrypt-openssl-pkcs12-perl
[21:11] <vorlon> xnox: I've already removed it you took too long to object.  You're welcome to look at it though :)
[21:12] <vorlon> leaf perl package, tries to do high-level pkcs12 stuff and the test suite is laconic
[21:12] <xnox> laconic you say
[21:12] <vorlon> :)
[21:13] <vorlon> well there's plenty of noise, but e.g. it says certificate() doesn't produce desired output but can't be bothered to show the output it does produce
[21:24] -queuebot:#ubuntu-release- Unapproved: rejected liboping [source] (bionic-proposed) [1.10.0-1ubuntu0.1]
[21:26] <xnox> vorlon:  so libcrypt-openssl-pkcs12-perl builds and passes all tests if i export openssl cnf to load legacy provider.
[21:26] <vorlon> xnox: feel free to implement that in the source then :)
[21:26] <xnox> vorlon:  i don't think that perl module itself should be doing it, but also i kind of think it is a pointless module if one needs to load legacy provider externally
[21:27] <xnox> vorlon: i saw you make it do that in blurp thing, which is ok, not sure about doing it here.
[21:27] <vorlon> ok
[21:28] <vorlon> fwiw I just retried a bunch of tests related to the other perl ssl modules since they look like they all want migrating together w/ perl-openssl-defaults
[22:08] <xnox> vorlon:  python3.9 fails on every arch with new setuptools due to module-install-local FAIL stderr: /usr/lib/python3/dist-packages/setuptools/command/install.py:34: SetuptoolsDeprecationWarning: setup.py install is deprecated. Use build and pip and other standards-based tools.
[22:08] <xnox> module-install-user  FAIL stderr: /usr/lib/python3/dist-packages/setuptools/command/install.py:34: SetuptoolsDeprecationWarning: setup.py install is deprecated. Use build and pip and other standards-based tools.
[22:09] <xnox> vorlon:  but it is harmless, because everything passes, i.e. testsuites, it's just allow-stderr on those module install tests
[22:09] <xnox> (or rewritting module install autopkgtest to not use deprecated commands)
=== amurray_ is now known as amurray
[22:33] <vorlon> xnox: ack
[22:33] <vorlon> autopkgtest for python-cryptography: amd64: Test in progress, arm64: Test in progress, armhf: Test in progress, i386: Test in progress (will not be considered a regression), ppc64el: Test in progress, s390x: Test in progress
[22:33] <vorlon> what is this noise
[22:34] <vorlon> new version of the package in -proposed, hmph, lousy reason
[23:10] <vorlon> xnox: erm I just looked at the nodejs upload; how in the world is it right to switch to a vendored openssl instead of keeping openssl1.1 around as a separate source package?
[23:12] <vorlon> also what's the deal with the amd64 ftbfs, I guess it's docs?