[09:34] <rbasak> sergiodj: have you seen bug 2020913? I just hit it.
[09:34] -ubottu:#ubuntu-devel- Bug 2020913 in elfutils (Ubuntu) "/etc/profile.d/debuginfd.{sh,csh} are created with 600 permissions" [Undecided, Confirmed] https://launchpad.net/bugs/2020913
[09:35] <rbasak> It isn't obvious to me why looking at the postinst, but that's the case on a default 22.04.1 desktop install.
[14:47] <sergiodj> rbasak: I haven't; thanks for the heads up
[15:06] <athos> @pilot in
[16:27] <hjd> Could someone retrigger a build of golang-sourcehut-rockorager-tcell-term and golang-github-go-kit-kit in Mantic? Seems like they were synced and attempted built before the new version of golang-golang-x-mod-dev
[16:29] <hjd> Also, is there a way to see why some builds are flagged as dep-wait and some build failures, is it in the launchpad code or somewhere separate? I assume if this had been marked as waiting for dependencies, it would have been retried automatically.
[16:37] <athos> hjd: builds re-triggered. Do you have any examples of those dep-waiting vs failure instances?
[16:46] <hjd> athos: thanks :)
[16:48] <hjd> One example is some of the ocaml packages in Mantic.
[16:48] <hjd> https://launchpad.net/ubuntu/+source/ocaml-pp/1.1.2-2/+build/26395929 is marked as waiting for dependencies because these packages cannot be installed, however
[16:48] <hjd> https://launchpad.net/ubuntu/+source/ocaml-ipaddr/5.5.0-1/+build/26390650 is marked as a build failure even though that also seems to be due to dependencies which cannot be installed
[17:22] <athos> oh, so the first one is waiting o a build dependency which is not available in the archive yet
[17:22] <athos> its build failed (see https://launchpad.net/ubuntu/+source/ppx-expect)
[17:23] <athos> the second has all its build deps in the archive, however, when trying to install some b-deps, it ended up that some of these b-deps runtime deps were not available, hence the failure
[17:34] <athos> enr0n: hey! I added some comments in https://code.launchpad.net/~enr0n/ubuntu/+source/rdflib-sqlalchemy/+git/rdflib-sqlalchemy/+merge/445579. I suspect that more packages will FTBFS due to this issue. It would be nice to chat with the folks in #debian-python to check if this is the expected fix for all the affected packages or if they have something else in mind - given I am right about the dh-python
[17:34] <athos> changes in experimental
[17:36] <hjd> Hm, but it is not clear to my why the first one is marked as waiting while the other gets marked as just a general failure. Is it "these packages/versions cannot be resolved at all" vs "everything exists and should be installable, but it just does't work at the moment"?
[17:48] <cjwatson> hjd: It's because in the second case the missing dependencies are indirect.  That case can't be turned into a straightforward dependency-wait, because there are multiple ways the failure could be resolved - the intermediate package could change, or the quoted dependency could become available directly - and that can't be expressed in a simple "wait until a package with this name matching this
[17:48] <cjwatson> version constraint exists"
[17:49] <cjwatson> The full logic is in https://git.launchpad.net/launchpad-buildd/tree/lpbuildd/binarypackage.py#n378 (the analyseDepWait method)
[17:50] <cjwatson> (And a bunch of things around that)
[17:50] <cjwatson> https://git.launchpad.net/launchpad-buildd/tree/lpbuildd/binarypackage.py#n422 is more like the top of the logic, I guess
[17:54] <hjd> cjwatson: aha, that makes sense :)
[17:56] <cjwatson> I remember that taking quite a bit of hard thinking to work out
[18:12] <jbicha> cjwatson: is it possible for depwait to retry once missing virtual packages appear? I end up having to manually retry rust-* packages because of this
[19:00] <vorlon> jbicha: I believe that's only blocked on someone implementing it
[19:34] <athos> @pilot out
[20:25] <bluca> did lxc on focal bork yesterday or so? our CI running on focal and starting lxc containers has been failing since yesterday with:
[20:25] <bluca> ERROR: meta tarball is missing the configuration file
[20:25] <bluca> lxc-create: bookworm-amd64: lxccontainer.c: create_run_template: 1627 Failed to create container from template
[20:25] <bluca> https://the-real-systemd.semaphoreci.com/jobs/cae6348b-301a-41d9-a42a-1a78e9501d7c
[20:25] <bluca> anybody seen that?
[20:30] <sarnold> bluca: try asking in #lxc, there's more folks there more familiar with the different templates
[20:32] <bluca> will do
[20:33] <bluca> looks like it's https://github.com/lxc/lxc/issues/4325
[20:33] -ubottu:#ubuntu-devel- Issue 4325 in lxc/lxc "Container configurations missing for most distributions" [Open]
[20:36] <sarnold> that looks likely yeah
[23:05] <cjwatson> jbicha: https://bugs.launchpad.net/launchpad/+bug/335913 - retry-depwait is pretty horrible at the moment though, I think it'd need some re-engineering for performance first
[23:05] -ubottu:#ubuntu-devel- Launchpad bug 335913 in Launchpad itself "depwait builds do not retry even though the dep can be met via a virtual package" [High, Triaged]