[00:05] <ahasenack> waveform: quick review? I will still run the dep8 tests on all arches before upload: https://pastebin.ubuntu.com/p/GFWqgCfS5F/
[00:07] <waveform> I'm afraid that won't quite work -- getattr(os, "O_LARGEFILE", None) is going to return 0 (evaluating to False) on amd64
[00:07] <ahasenack> smucks
[00:08] <waveform> best to just do the try..except AttributeError
[00:08] <ahasenack> ok
[00:11] <ahasenack> waveform: https://pastebin.ubuntu.com/p/p4XgnRXhcx/
[00:11] <waveform> looks good to me!
[00:13] <waveform> (I'd be very surprised if any of our python builds didn't have O_LARGEFILE defined, in other words if they were limited to 4GB file-pointers, but it's good to cover our bases just in case)
[00:13] <ahasenack> I believe this will be temporary
[00:13] <ahasenack> next step will be to yank that script
[00:13] <waveform> :)
[00:55]  * ahasenack chants "ppa: publish! ppa: publish!"
[00:55]  * sarnold chants "ppa: publish! ppa: publish!"
[00:55] <ahasenack> let's get the energy flowing!
[01:08] <ahasenack> published!
[01:10] <ahasenack> tests triggered, now let's play some Assassin's Creed while I wait
[01:11]  * sarnold starts swordfighting from his chair
[01:23] <ahasenack> all passed so far, including armhf
[01:23] <ahasenack> just waiting on s390x
[01:23] <ahasenack> running for 10min, should be almost done
[01:25] <ahasenack> actually, there is zero output for s390x: https://autopkgtest.ubuntu.com/running#pkg-update-motd
[01:26] <ahasenack> I'll upload, the others were green
[06:48] <arraybolt3> mkukri: You don't happen to be the same Mate Kukri who made this happen, are you? https://libreboot.org/docs/hardware/dell9020.html If you are, this is extremely awesome :D
[07:29] <mkukri> it is me yep :)
[07:30] <mkukri> still occasionally dabble in coreboot thingies but mostly ENOTIME
[08:50] <dviererbe> Can someone sponsor https://code.launchpad.net/~dviererbe/ubuntu/+source/libapache2-mod-python/+git/libapache2-mod-python/+merge/460705 ?
[08:50] <dviererbe> It build in a PPA and the tests pass
[11:11] <zhsj> could someone retry this build https://launchpad.net/ubuntu/+source/golang-1.20/1.20.14-1/+build/27809168 there's no log, looks like infra problem.
[11:14] <cjwatson> zhsj: done
[11:15] <zhsj> cjwatson: thx
[11:50] <bluca> is there any way to force a PPA to create a release file even if there's no packages targeted at that release?
[11:50] <bluca> autopkgtest is refusing to run without ppa= but I have no need for any custom packages for noble
[11:51] <cjwatson> bluca: use mark-suite-dirty from ubuntu-archive-tools
[11:51] <cjwatson> give it the right --archive and --suite, then wait for a publisher cycle
[12:03] <ahasenack> ok, so just ansible is blocking the python3 migration now
[12:03] <ahasenack> any ideas?
[12:03] <ahasenack> doko: you said you tried something with ansible?
[12:07]  * ahasenack sets sights on ansible
[12:08] <bluca> cjwatson thanks - but I can't figure out the right incantation, the ppa is http://ppa.launchpad.net/upstream-systemd-ci/systemd-ci/ubuntu
[12:08] <cjwatson> bluca: -A ppa:upstream-systemd-ci/ubuntu/systemd-ci noble
[12:08] <cjwatson> oops
[12:08] <cjwatson> bluca: -A ppa:upstream-systemd-ci/ubuntu/systemd-ci -s noble
[12:08] <bluca> ah thanks, I was missing ppa:
[12:24] <ginggs> ahasenack: ansible's autopkgtests seem a bit flaky
[12:24] <ahasenack> failing on just arm* now
[12:24] <ahasenack> I updated https://bugs.launchpad.net/ubuntu/+source/ansible/+bug/2052530
[12:24] -ubottu:#ubuntu-devel- Launchpad bug 2052530 in python-ansible-compat (Ubuntu) "ansible-core fails its autopkg tests with Python 3.12" [Undecided, New]
[12:24] <ginggs> on its own it has passed everywhere except arm64 and armhf
[12:25] <ginggs> and with python3-defaults it passed everywhere except armhf and ppc64el
[12:25] <ginggs> i spammed a bunch of retries
[12:26] <ginggs> it looks like it passed 1 of 3 attempts on arm64
[12:27] <ginggs> and 1 of 4 attempts on armhf against python3-defaults
[12:34] <ahasenack> armhf passed now
[12:35] <ahasenack> that test might need a sleep between starting the thing that owns the socket, and the check for the socket
[12:35] <ahasenack> I see it has a couple of sleeps already
[12:35] <ahasenack> 0.5 and 0.8
[12:51] <bdrung> @pilot in
[13:42] <dviererbe> I have an i386 autopkgtest that fails because it tries to install the amd64 version of a test dependency. Is there a recommendation what I can do? My first thought is to either do add the skip-not-installable for i386 or exclude the architecture.
[13:45] <bdrung> dviererbe, which package?
[13:45] <dviererbe> https://autopkgtest.ubuntu.com/results/autopkgtest-noble-dviererbe-unzip6-0-28ubuntu2/noble/i386/u/unzip/20240222_111008_6ae09@/log.gz
[13:46] <dviererbe> To add more context, this is a new test. So it would not decrease the test coverage
[13:59] <bdrung> it's strange that this test wants to install diffutils:amd64 instead of diffutils:i386
[14:02] <dviererbe> bdrung: Yes it is, that you don't have an immediate explanation comforts me :D
[14:02] <bdrung> dviererbe, ask the QA experts
[14:02] <dviererbe> ack
[14:56] <flag> britnet hint:
[14:56] <flag> https://code.launchpad.net/~p-pisati/britney/+git/hints-ubuntu/+merge/461040
[14:56] <flag> can anyone review/merge it?
[14:56] <flag> thanks!
[14:59] <adrien> bryyce: I did some filtering and the result is https://pastebin.notk.org/pastebin.php?show=f3be9ab ; for display purposes, I put one per line but in a terminal for a single package, I would print \r each time and erase and overwrite the current line
[14:59] <adrien> there's room for bikeshedding (especially since terms don't display emojis as well as web browsers)
[15:00] <adrien> if there are several packages, I would probably prepend each line with the package name (or prepend a line with it) and don't attempt to \r or do anything fancy
[15:01] <bdrung> ppisati, commented
[15:02] <adrien> there are tons of things that could be done better but I used post-processing and an awk script... ; the main missing part are whether a given arch is enabled in the PPA and whether the build for an arch is finished (the script assumes that if there is nothing said about an arch anymore, it's a full success)
[15:14] <ppisati> bdrung: replied
[15:21] <bdrung> ppisati, Module 'network-legacy' is a dracut module and not a kernel module.
[15:31] <ppisati> bdrung: apologize, merge request deleted
[15:47] <ppisati> bdrung: i really need to take a break
[15:47] <ppisati> bdrung: https://code.launchpad.net/~p-pisati/britney/+git/hints-ubuntu/+merge/461043
[15:47] <ppisati> here is what i really meant
[15:48] <ppisati> i wanted to release linux 6.8.0-11.11+1, not dracut
[15:51] <bryyce> adrien ooh interesting.  I'd love to hear more and/or see the script.  I like how concise it is.  Did you have thoughts on how multiple packages could be handled, or would this be a single-package only kind of display?
[15:55] <adrien> bryyce: the script is stupid-ish awk which I'll be testing in a few dozen minutes (when something is done running here because I've put that as part of larger plumbing); I'll upload it soon
[15:56] <adrien> bryyce: I'm definitely using ppa-dev-tools for single-package PPAs usually; I have some rough ideas on how to handle multi-packages but this might not be very doable as part of a post-processing script (or at least it might be a waste of time to do it that way)
[16:00] <bdrung> @pilot out
[16:10] <adrien> I'm inclined to write on the NN release notes that coreutils' *sum programs now use libcrypto and are therefore faster but I'm not sure where/how to put it
[16:12] <adrien> bryyce: https://pastebin.ubuntu.com/p/CK8ykyxfX4/ ; I never said it was not brittle :P
[16:30] <bryyce> adrien, thanks
[16:43] <adrien> well, obviously, something is broken but it's still usable (I guess iterating over awk arrays happens in an undefined order or something like that)
[17:12] <kanashiro> @pilot in
[17:42] <ppisati> can anyone merge this?
[17:42] <ppisati> https://code.launchpad.net/~p-pisati/britney/+git/hints-ubuntu/+merge/461043
[17:43] <ppisati> we would like to get a 6.8 kernel as soon as possible in release, and we a have a couple of tests blocking us
[17:43] <ppisati> it's a britney hint ^
[18:08] <tjaalton> needs release team
[20:39] <Elliria> Hey there. If anyone in here has editing power on the https://lists.ubuntu.com page, it could use an edit.
[20:39] <Elliria> The ubuntu-motu entry needs to be moved from the "Development Lists" section to the "Discontinued (Historical) Lists" section since the ubuntu-motu list has been merged with the ubuntu-devel-discuss list.
[20:39] <Elliria> More info is here: https://lists.ubuntu.com/archives/ubuntu-motu/2023-November/008400.html
[20:51] <Eickmeyer> Elliria: There's a lot going on with lists.ubuntu.com, it won't happen overnight, sadly. And, sadly, nobody here has editing power over that.
[20:51] <Elliria> Ah, you're one of the people who wrote in that thread. Do you know if the Ubuntu Doc team has editing powere? I posted in their channel, too, but no reply so far.
[20:52] <Eickmeyer> Elliria: nope, Ubuntu Doc team has no editing power. That's strictly Canonical IS.
[20:52] <Elliria> Ah, I've never dealt with them directly. Do they welcome hearing from users?
[20:52] <kanashiro> @pilot out
[20:53] <Eickmeyer> It's a complicated mess right now that I'm not at liberty to talk about.
[20:53] <Elliria> Okay, no worries. Sorry for the noise.
[20:53] <Eickmeyer> No worries. :)
[20:55] <Eickmeyer> juliank: Hey! With deb822, I've noticed that the ddeb entry updates don't point to the keyring (`ubuntu-dbgsym-kyring` package) and that this wiki entry (https://wiki.ubuntu.com/Debug%20Symbol%20Packages) probably needs some new instructions or, better yet, something on Discourse in lieu of that. Ideas? Thoughts?
[21:00] <bdmurray> What thread?
[21:03] <Eickmeyer> bdmurray: I believe it had something to do with the movement of ubuntu-motu@ to ubuntu-devel-discuss@.
[21:05] <bdmurray> I wonder if an admin updating the list description would be reflected on the main page.
[21:14] <juliank> Eickmeyer: You wanna give it a go? :D
[21:15] <juliank> ginggs: I peeked and my phone told me glibc migrated, hooray
[21:16] <juliank> time to let all hell break loose
[21:20] <ginggs> juliank: \o/
[21:21] <ginggs> one britney run later than i expected
[21:21] <ginggs> but it does say:
[21:21] <ginggs> Trying hint from ubuntu-release: glibc/2.39-0ubuntu1 dante/1.4.2+dfsg-7build9 gcc-9/9.5.0-5ubuntu1 libnss-db/2.2.3pre1-9build1 unscd/0.54-1build7 zzuf/0.15-2build3
[21:21] <juliank> yeah
[21:24] <Eickmeyer> juliank: Sure, I can try. :)
[21:25] <Eickmeyer> juliank: Though, I guess that's outdated information with dbudginfod. 😅
[21:26] <Eickmeyer> bdmurray: Not sure, but they were talking about moving it down into the deprecated lists area.
[21:28] <juliank> Eickmeyer: to some extend debuginfod is nicer yeah
[21:28] <juliank> Eickmeyer: But like corporations can mirror dbgsym behind their firewalls which is nice, I guess debuginfod is less straightforward
[21:28] <juliank> Eickmeyer: I'd make sure to mention that as the preferred solution!
[21:28] <Eickmeyer> juliank: Yeah, that's very true.
[21:30] <Eickmeyer> juliank: So, two options: Copy the entire document to Discourse mentioning dbuginfod as the preferred method, or simply edit the wiki entry?
[21:31] <juliank> Eickmeyer: I honestly don't know
[21:31] <juliank> Eickmeyer: I think this will all move more, so feel free to do what feels natural to you
[21:31] <Eickmeyer> juliank: Then I'll go with option 2 for now, and it can then be copied over later and forwarded.
[21:42] <Eickmeyer> juliank: Merely added under the "Debuginfod" heading: If you are on Ubuntu Noble (24.04) or later, Debuginfod is the preferred method as the following information is outdated and, due to a new format for the sources.list entries being moved to the deb822 format."
[23:01] <UnivrslSuprBox> adrien: Sorry for the ping, I asked in lp:2053071 as well but didn't hear back. Is there anything you need from me to get faketime fixed up in noble given it currently fails dh_auto_test and stops the builder on 32-bit archs? armhf may fix itself after the 64-bit time transition.
[23:01] -ubottu:#ubuntu-devel- Launchpad bug 2053071 in faketime (Ubuntu) "faketime i386 and armhf fail to fake timestamps through date(1) in lunar and above" [Undecided, Won't Fix] https://launchpad.net/bugs/2053071