=== not_phunyguy is now known as phunyguy
[04:21] <theloudspeaker[m> Is GNOME 42 making it to 22.04?
[04:45] <Eickmeyer> theloudspeaker[m: That's the plan per the release schedule: https://discourse.ubuntu.com/t/jammy-jellyfish-release-schedule/23906
[08:47] <schopin> <
[08:47] <schopin> erm, mistype, sorry :)
[11:04] <Fantu> hi, about freeipmi migration blocked I tried to check the armhf slurm-wlm test failing but I not found the issue, I saw an RC bug related to autopkgtest (https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=985725) and I suppose can be related, someone can tell me the fastest way to test build+autopkgtest on armhf on ubuntu please? launchpad don't use it or I'm wrong?
[11:04] <ubottu> Debian bug 985725 in src:slurm-wlm "slurm-wlm: flaky autopkgtest: srun: Required node not available (down, drained or reserved)" [Serious, Open]
[11:11] <rbasak> utkarsh2102: o/ any progress on ruby-mysql2 dep8 vs. mysql-8.0 yet please?
[11:35] <bluca> mmh weren't i386 builds restricted to a few libraries in the past few releases?
[11:35] <bluca> init-system-helpers 1.62 is not migrating from proposed because i386 build is missing
[11:35] <bluca> https://launchpad.net/ubuntu/+source/init-system-helpers/1.62/+build/23171404
[11:35] <bluca> (because libfakeroot is not build for i386)
[11:37] <bluca> what should I do here to fix this?
[12:52] <ahasenack> schopin: hi, I have a freeradius 3.0.25+patches branch. It passes the dep8 tests, but does not have all openssl3-related commits in it
[12:52] <ahasenack> just enough to pass the test that was failing in moonshot
[12:53] <ahasenack> I want to test it a bit more with tls, I was digging through the freeradius docs to see where it uses tls, and try to set that up
[12:53] <ahasenack> figure a possible FFe for 3.0.25->3.0.26 would be easier than 3.0.21->3.0.26
[12:56] <schopin> It does make sense, yes :)
[14:03] <slyon> jamespage: coreycb: would you mind me uploading this? https://code.launchpad.net/~slyon/ubuntu/+source/barbican/+git/barbican/+merge/415847 It fixes barbican compatibility with python 3.10
[14:21] <bluca> cpaelzer: any idea about the above i386 issue, or who to ask for help? TIA!
[15:07] <gombara> hello. I am trying to get a definitive answer to the question "can Ubuntu 20.04 desktop installation be automated?" it looks like d-i presee file format has been abandoned. is that correct?
[15:08] <gombara> thus the only way to autoinstall a Ubuntu desktop is to autoinstall a Ubuntu server and addthe desktop as post install step. is that right?
[15:12] <oerheks> gombara, yes
[15:13] <oerheks> this change came with ubiquity > subiquity
[15:14] <ogra> not in 20.04 though ...
[15:14] <ogra> that still uses ubiquity (and should still be able to use ubiquitys (limited) preseed support)
[15:15] <oerheks> indeed, started with 21.10 , based on curtin
[15:15] <oerheks> https://launchpad.net/curtin
[15:17] <gombara> I have not been able to start the auto install tough. I have been providing the name of the preseed file in grub.cfg file (since IsoLinux has been removed). any ideas why auto install does not start and I land into the live desktop?
[15:37] <ogra> did you add "automatic-ubiquity" too ?
[15:37] <ogra> https://wiki.ubuntu.com/UbiquityAutomation
[15:37] <ogra> not sure how relevant it still is (it is a very old wiki page), but it used to work at some point
[16:42] <bluca> I opened a bug to request a libfakechroot i386 build as per wiki procedure: https://bugs.launchpad.net/ubuntu/+source/ubuntu-meta/+bug/1961610
[16:42] <ubottu> Launchpad bug 1961610 in ubuntu-meta (Ubuntu) "i386: seed inclusion for libfakechroot" [Undecided, New]
[16:43] <bluca> is there anybody from the archive team around who could please have a look? this is blocking init-system-helpers migration from proposed
[16:53] <xnox> it is president's day so many AAs are out, and other AAs are busy with preparing focal point release. it may take some time to get to the above request.
[16:55] <bluca> got it thanks - does the jammy feature freeze apply to packages currently in proposed?
[16:59] <schopin> bluca: if they've been uploaded before FF, they should migrate normally.
[17:00] <bluca> thanks
[17:34] <gombara> ogra, oerheks just realized that I meant 21.04 instead of 20.04. With 20.04 d-i preseed file syntax works
[19:03] <rbasak> !dmb-ping
[19:03] <ubottu> ddstreet, rafaeldtinoco, rbasak, sil2100, slashd, teward, tsimonq2: DMB ping
[19:20] <ahasenack> do we have some practical rules for packaging a git version of an upstream project?
[19:20] <ahasenack> like 3.0.26~git<date>.<hash>-0ubuntu1
[19:20] <ahasenack> or 3.0.25+git<date>.<hash>-0ubuntu1
[19:20] <ahasenack> I feel there should still be an index after the date, because the git hash can be later in time, but lower in version
[19:20] <ahasenack> so 3.0.25+git<date>.<n>.<hash>-0ubuntu1?
[19:20] <ahasenack> wfyt?
[19:21] <ahasenack> looking at dpkg -l output, I see all sorts of things
[19:21] <ahasenack> 4.11.1+git32-gd0b85fb-1
[19:21] <ahasenack> 0.9.5git20210406-0ubuntu2
[19:22] <ahasenack> 2.4+20151223.gitfa8646d.1-2build3
[19:22] <ahasenack> this is a mouthful
[19:22] <ahasenack> 3:6.04~git20190206.bf6db5b4+dfsg1-3ubuntu1
=== roehling is now known as roehling_
=== roehling_ is now known as roehling
[19:32] <rbasak> ahasenack: https://help.launchpad.net/Packaging/SourceBuilds/Recipes#Version_numbers_and_substitution_variables has some discussion on this question
[19:32] <ahasenack> bzr revno's are always incrementing
[19:32] <rbasak> (but not an answer really)
[19:33] <ahasenack> that helps in this case
[19:33] <rbasak> I just mention it because it's the only doc I know about that covers this question, so it might be worthwhile following what it says
[19:33] <rbasak> Though that's still not really an answer
[19:34] <jbicha> my opinion is that I like revdate; the git hash adds clutter for only a small amount of extra usefulness
[19:36] <rbasak> The commit hash could also go into debian/changelog as text, so putting it in the version only serves to save that lookup when (rarely?) it is needed.
[19:37] <rbasak> The gd0b85fb matches "git describe" FWIW
[19:37] <rbasak> The style that is
[19:38] <ahasenack> I don't expect this to be permanent (knock on wood)
[19:38] <ahasenack> I kind of like having it in the version
[19:39] <ahasenack> it's an at-a-glance feature
[19:42] <rbasak> To be clear, I'm not opposed to that. I was just trying to distil the facts in my statements above.
[19:44] <mwhudson> yuck https://autopkgtest.ubuntu.com/packages/c/cluster-glue/jammy/amd64
[19:45] <mwhudson> hmm always passes in debian though
[19:45] <bdmurray> embiggen it
[19:45] <mwhudson> not sure that's it, from a very quick look it's a race around service startup
[19:46] <mwhudson> i guess big instances have more cpus too?
[19:47] <mwhudson> also there is ubuntu delta talking about the test that is failing
[19:48] <bdmurray> Okay, I hadn't looked really. ;-)
[19:49] <mwhudson> oh it's in main and the server team is subscribed so it might actually be worth filing a bug!
[20:35] <ahasenack> schopin: I packaged freeradius git snapshot, 3.0.26~something. Dropped my openssl3 patches as expected, and the tests pass. I also did a bunch of manual eap-tls tests
[20:36] <ahasenack> just found out that eap-md5 tunneled through tls didn't work, the message implied the client (the eap tester from src:wpa) had it disabled, but I couldn't find out where
[20:36] <ahasenack> maybe some new openssl3 restriction on md5 for security applications
[20:36] <ahasenack> it was clearly a client decision
[20:36] <ahasenack> plain eap-md5 works