=== _doko is now known as doko [13:25] Since I asked for faster rmadison I want to state the solution here as well [13:25] Creating an apt-mirror and running madison-lite locally works fine for me [13:26] speedup of the overall task I have from ~6 -> ~2 minutes \o/ [13:26] and more the mroe I do due to caching [13:26] rbasak: ^^ FYI since you suggested options [13:27] Great! [13:27] I've avoided having a local apt mirror, though I do have a squid proxy [13:28] Because I fear it'll creep into all architectures and all non-EOL releases, and I'm not sure I want to commit to that much space. [13:28] (and bandwidth) [13:30] I think something here, rmadison doesn't normally take 6 minutes, but is *very* slow for Ubuntu. :3 [13:30] I missed, ironic. >_> [16:36] rbasak: sru question, procedures [16:36] rbasak: golang-1.18 | 1.18.1-1ubuntu1~18.04.2 | bionic-proposed/universe | source [16:36] that's in proposed already, and I have 1.18.1-1ubuntu1~18.04.3 that includes another fix [16:37] the tooling is giving me a warning. Do I need an AA to remove the 18.04.2 package from proposed? [16:38] the changes file in the .3 upload correctly references the previous versions [16:43] bbl [16:43] That sounds fine. [16:43] You can accept an SRU over the top of something in proposed. Technically it'll let you. You have to check it will have the intended effect, but it sounds like it will. [16:44] I usually check that's what the uploader wants though, as it'll delay what's already in proposed, and requires re-verification of everything. [16:44] And yeah, it needs to have been uploaded with -v as appropriate, as you already checked. [17:56] ok, I'll accept, let's see what the tooling will do [18:25] seb128: hi, why did you skip kinetic in your https://bugs.launchpad.net/ubuntu/+source/evince/+bug/1915910 upload? [18:25] -ubottu:#ubuntu-devel- Launchpad bug 1915910 in evince (Debian) "evince does not print (apparmor, pxgsettings)" [Unknown, New] [18:35] Any ideas how siridb-server could go from taking 2h 48m to 24s? https://ci.debian.net/packages/s/siridb-server/unstable/amd64/ [18:36] bdmurray: all of the 2h48m runs look like failures, so probably a hung lock & timeout in the failures? [18:37] So just keep retrying then? [18:39] bdmurray: given that it happens for the baseline tests I'd say yes. Actually my preference would be to try to get the baseline to fail ;P [18:39] (and then make it Debian's problem to fix their flakiness) [19:17] ahasenack, because I forgot we had to care about non LTS series for minor bugfixes, I can do it as well in a bit [19:17] thx [19:39] ahasenack, uploaded to kinetic, thanks for asking about it! [20:06] Could someone moderate ubuntu-release@ please? I got a request from ItzSwirlz but he's offline now. [20:08] rbasak: I can have a look [20:08] Oh but I don't have that one [20:12] OK well we tried. Thanks. [21:11] bdmurray: I fixed a similar problem in siridb-server last cycle (bug 1987558). [21:11] -ubottu:#ubuntu-devel- Bug 1987558 in siridb-server (Ubuntu) "libuv1 breaks siridb-server autopkgtest: test times out" [Undecided, Fix Released] https://launchpad.net/bugs/1987558 [21:11] Are you looking at siridb-server vs libcleri? [21:12] enr0n: not any more, I retried them all with migration-reference/0 triggers [21:13] where all is every arch [21:13] bdmurray: okay, my guess from experience with that package (and seeing that the failures only occur with libcleri), my guess is this is a real failure which causes the http server to crash [21:14] Which makes the test http client hang until it timesout [21:18] enr0n: Could you open an update-excuse bug so we don't lose your guess? [21:21] bdmurray: yeah will do [21:32] bdmurray: bug 1999184 [21:32] -ubottu:#ubuntu-devel- Bug 1999184 in siridb-server (Ubuntu) "siridb-server autopkgtest times out with libcleri 1.0.0-1" [Undecided, New] https://launchpad.net/bugs/1999184 [21:35] enr0n: ah, now I see it timing out in debian testing https://ci.debian.net/packages/s/siridb-server/testing/amd64/ [22:06] Please join me in congratulating arraybolt3 on becoming a Lubuntu Developer (PPU) today. 🎉 [22:09] cool :) congrats arraybolt3[m] :D [22:13] sarnold: :) Thank you! [23:01] congrats arraybolt3! [23:20] mmikowski: \o/ It was **hard**! [23:40] arraybolt3[m] what was hard about it (not doubting, just curious. I don't know the process!) [23:43] mmikowski: Tons of technical knowledge about Ubuntu necessary. The meeting was basically an intensive grilling to see how much I knew about all the stuff I didn't do a whole lot of :P Thank goodness for documentation! [23:43] Ah, packaging? systemd? X11? Wayland? Etc? [23:44] Packaging, proposed-migration, policies related to DFSG, etc. [23:44] DFSG? [23:44] Debian Free Software Guidelines (basically "can this be part of Debian and Ubuntu or not?") [23:44] (From a copyright and licensing perspective.) [23:45] ah yes. That's a big deal. [23:45] Is there a study guide? [23:46] Kinda? There's a guide to help you know how much you need to know, but basically the existing Lubuntu developers and contributors trained me for long. It was really fun, and I'm very thankful for their help. They're the reason I'm able to help with Ubuntu stuff at all. [23:47] Cool; it would be good to document what's needed, both as a reference and to recruit more users. Of course, who has the time, right? [23:49] The documentation is very scattered. I would love to eventually work on that. [23:50] I don't want to take up the IRC, but congrats again. I might hit you up with DM for more info!