=== JanC is now known as Guest4834
=== genii is now known as genii-core
[06:14] <KBar> Hello. Is this page up to date: https://packaging.ubuntu.com/? Would I know how to create .deb packages by the end of it?
[06:22] <KBar> By the way, the "Other ways to get involved" box still contains links to Google+, which was abandoned a while ago.
[06:25] <KBar> Nevermind, the PDF version of the documentation has all the answers.
=== doko_ is now known as doko
[10:55] <cjwatson> smoser: by-hash doesn't break debmirror.  debmirror doesn't yet mirror the by-hash directories, indeed, but that just means you don't get the benefit of them - the mirror still works without that
[10:56] <cjwatson> smoser: same goes for any other mirroring tools.  by-hash is an opt-in addition
[13:34] <seb128> cpaelzer, hey, MIR question for you about suitesparse-graphblas ... can we get away without having to comply to tests requirements if it's a split of an existing source in main which was already lacking those?
[13:37] <seb128> cpaelzer, ideally we would improve the situation and add those but we just don't have the resources for that atm and the alternative is to keep using the oudated copy included in suitesparse but that isn't putting us in a better situation
[13:46] <schopin> ahasenack: ACK on the Debian upload of krb5. AFAIK they're pretty much identical, the backported OpenSSL patch was actually provided by the Debian maintainer.
[13:48] <schopin> ahasenack: unrelated, have you noticed the armhf test failure for python-cryptography against openssl 3.0.1?
[13:52] <ahasenack> noticed, yes
[13:52] <ahasenack> so openssl still stuck?
[13:53] <ahasenack> I did a retry, it failed again
[13:53] <ahasenack> another internal error, but with no error message this time :/
[13:57] <schopin> python3.* should be fixed but were still building last I checked.
[14:00] <ahasenack> can you reproduce the armhf failure?
[14:01] <ahasenack> I don't have armhf boxes, we would need an arm64 that can do 32bits emulation
[14:01] <ahasenack> don't know if canonistack can do that, and even if it can, it also needs to be available ;)
[14:01] <ahasenack> aka, working
[14:01] <schopin> i'll work on reproducing it.
[14:02] <schopin> (assuming I manage to find that pesky microSD adapter...)
[14:08] <ahasenack> schopin: I got an armhf vm running in canonistack (!)
[14:08] <ahasenack> I can import your key
[14:09] <ahasenack> just 1gb of ram, hope it's enough. Maybe be generous with swap
[14:10] <ahasenack> hm, uname shows aarch64, so we may need the lxd trick for 32 bits
[14:10] <ahasenack> ah, I launched arm64
[14:10] <ahasenack> ok, makes sense. STill need a 32b container, let me see if I can start one
[14:11] <schopin> hmm, lemonldap-ng also fails on armhf on some openssl-related issue. :/
[14:13] <schopin> oh wait. THe correct version just hasn't caught up yet.
[14:14] <ahasenack> https://autopkgtest.ubuntu.com/packages/l/lemonldap-ng/jammy/armhf it needs a trigger for openssl 3.0.1?
[14:15] <ahasenack> I don't see it pulling in openssl 3.0.x
[14:15] <ahasenack> in the test logs
[14:16] <smoser> cjwatson: right. but i thought there were some issues with apt, where it didn't fall back correctly. at least at some point.  i know i saw that. then, also, i want the benefits of by-hash. i don't like hash sum mismatches.
[14:16] <smoser> thank you for the response.
[14:17] <schopin> ahasenack: it's transitively depending on it via various perl packages
[14:17] <ahasenack> ah, the test was in the old package
[14:17] <ahasenack> that failure is old-ish
[14:17] <schopin> yup, I was just startled of the coincidence.
=== cpaelzer_ is now known as cpaelzer
[14:19] <cpaelzer> slyon: about the systemd<->dnsmasq issue I asked on monday. I think it is resolved on the systemd side but I fail to see where
[14:19] <cpaelzer> slyon: I filed you https://bugs.launchpad.net/ubuntu/+source/systemd/+bug/1957086 - maybe you can spot it?
[14:19] <ubottu> Launchpad bug 1957086 in systemd (Ubuntu) "Autopkgtest systemd fail against dnsmasq 2.86 (22.04)" [Undecided, New]
[14:28] <slyon> cpaelzer: thanks, I'll have a look soon!
=== genii-core is now known as genii
[16:25] <schopin> ahasenack: running the tests on my RPi4 (armhf image, LXD adt runner, --apt-pocket=proposed=src:openssl) didn't fail :/
[16:33] <ahasenack> hm
[16:42] <bdmurray> schopin: doesn't an RPi4 have more memory than our autopkgtest env?
[16:48] <dbungert> May I get assistance with a retest click? https://autopkgtest.ubuntu.com/request.cgi?release=jammy&arch=armhf&package=dgit&trigger=apt/2.3.14&trigger=sqlite3/3.37.2-1
[16:50] <schopin> dbungert: clicked
[16:54] <dbungert> schopin: thanks!
[16:56] <schopin> bdmurray: could be it. I was more thinking of it having multiple cores.
[16:59] <schopin> bdmurray: according to this, I actually think my pi is undersized: https://autopkgtest-cloud.readthedocs.io/en/latest/lxd.html#managing-cluster-nodes
=== unixlab is now known as nicoz-
[17:01] <bdmurray> schopin: oh, that contradicts what is in https://wiki.ubuntu.com/ProposedMigration#autopkgtests . juliank which documentation is a liar?
[17:02] <schopin> ironically I found my doc from this very paragraph, first link in there
=== nicoz- is now known as nicoz
[17:11] <juliank> bdmurray: I don't see a contradiction
[17:11] <juliank> bdmurray: lxd just shares the memory between parallel tests, you can't control memory there
[17:12] <juliank> I mean we could use lxd profiles and apply resource limits, but we don't
[17:13] <juliank> Like You might get spurious failures if one test uses up all ram while your test is running in a different container.
[17:14] <bdmurray> juliank: are armhf tests run on m1.small unit by default? 1 vCPU and 1592 MiB of memory?
[17:14] <juliank> In any case the readthedocs is the canonical documentation
[17:14] <juliank> bdmurray: no, they run in lxd. Each lxd host has 4 cores, 8gb ram, and runs 3 tests in parallel
[17:15] <juliank> There are no limits on individual tests on armhf
[17:15] <juliank> Because we do not spin up VMS to run tests
[17:15] <schopin> so the wiki is the liar then.
[17:16] <bdmurray> Well or it could be incomplete if armhf is a special snowflake
[17:16] <juliank> The wiki page only documents other architectures as it stands
[17:17] <juliank> Those details should not be on the wiki page anyway, they should refer to the mojo spec imo
[17:17] <juliank> I think applying resource limits on the lxd runners makes a lot of sense, we should implement that
[17:18] <juliank> Need to add a card to the autopkgtest board
[17:52] <schopin> Any core-dev willing to sponsor a lintian merge ? LP: #1957100
[17:52] <ubottu> Launchpad bug 1957100 in lintian (Ubuntu) "Merge lintian 2.114.0 from Debian uinstable" [Undecided, New] https://launchpad.net/bugs/1957100
[22:00] <ckie> hey, nvidia-cuda-toolkit is missing a pkg-config file. where do i poke? debian seems to have it
[22:46] <sarnold> ckie: the easy thing is 'ubuntu-bug nvidia-cuda-toolkit', that should get you to the right place
[22:46] <ckie> sarnold: hah, yeah I just finished figuring out how to use launchpad: https://bugs.launchpad.net/ubuntu/+source/nvidia-cuda-toolkit/+bug/1957119
[22:46] <ubottu> Launchpad bug 1957119 in nvidia-cuda-toolkit (Ubuntu) "pkg-config definition file is missing" [Undecided, New]
[22:47] <sarnold> ckie: nice, thanks :)
[22:47] <ckie> it seems like everything assumes you are running ubuntu which is reasonable, but I am not :P
[22:48] <ckie> i already had an account but it was with an old username so i had to fight the SSO stuff, launchpad was pretty nice about it
[22:49] <sarnold> heh, yeah, that first bug report in N years is always a bit of an uphill struggle
[22:49] <ckie> mhm! (: