[11:54] <Odd_Bloke> o/ I've noticed that a universe package (pxe-kexec) which we use was dropped from the archive sometime between jammy and now (I think in the mantic cycle based on git-ubuntu having branches up to lunar).  Where can I look to figure out why that happened?
[11:59] <rbasak> Odd_Bloke: start from https://launchpad.net/ubuntu/+source/pxe-kexec/+publishinghistory
[11:59] <rbasak> Odd_Bloke: ah the first entry. FTBFS. Debian https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=984300
[11:59] -ubottu:#ubuntu-devel- Debian bug 984300 in src:pxe-kexec "pxe-kexec: ftbfs with GCC-11" [Serious, Open]
[12:00] <Odd_Bloke> rbasak: Perfect, thank you!
[12:00] <rbasak> Odd_Bloke: FWIW, git-ubuntu currently completely ignores deletions from the archive. There's https://bugs.launchpad.net/git-ubuntu/+bug/1852389 though it's not entirely clear what the correct thing to do would be in this case. So investigation means looking beyond git-ubuntu currently.
[12:00] -ubottu:#ubuntu-devel- Launchpad bug 1852389 in git-ubuntu "Branch pointers do not follow deletions, breaking ubuntu/devel and such" [Wishlist, New]
[12:00] <rbasak> You're welcome!
[12:08] <ginggs> @pilot in
[15:05] <ginggs> @pilot out
[15:05] <ginggs> Thank you for flying Ubuntu Air!
[15:07] <jbicha> @pilot in
[15:33] <genii> http://ppa.launchpad.net/  seems currently broken
[15:36] <cjwatson> #launchpad's topic was just changed to record that as a known issue
[15:40] <genii> cjwatson: OK, thanks
[18:07] <ahasenack> mwhudson: hi, are you the one driving the time_t transition this week, in vorlon's absence?
[18:08] <ahasenack> or is it another michael
[18:08] <ahasenack> and if it's you, I suppose you are not around at this time
[18:08] <ahasenack> (rightfully so)
[18:11] <mitya57> schopin: Hi! You uploaded qtwebengine just a few minutes before I attempted to do the same :)
[18:11] <mitya57> Can you explain why time-bits.diff is needed? I got a successful build without it, does it fix some runtime issues?
[18:11] <mitya57> Also maybe you know upstream status of it?
[20:05] <jbicha> @pilot out
[20:24] <Eickmeyer> dbungert: https://bugs.launchpad.net/ubuntu-desktop-provision/+bug/2055077/comments/17
[20:24] -ubottu:#ubuntu-devel- Launchpad bug 2055077 in livecd-rootfs (Ubuntu) "cloudinit.sources.DataSourceEc2:583 Calling 'None' failed" [Undecided, In Progress]
[20:25] <Eickmeyer> TL;DR: Spinner with "Preparing Edubuntu..." but nothing else. It's stalled. Same symptoms as before.
[20:29] <dbungert> Eickmeyer: thanks.  I have dailup speeds from cdimage right now so I will test when I can
[20:29] <Eickmeyer> dbungert: Oof, I know that feeling. I zsync and it gets painful with that, too.
[20:34] <mwhudson> ahasenack: hi and yes
[20:35] <ahasenack> mwhudson: ok, was wondering how I could help, if you have a list or something of actionable work
[20:35] <ahasenack> I could try pick some up outside my work hours to begin with
[20:35] <mwhudson> ahasenack: search for "missing build on armhf" on excuses and dig in?
[20:36] <ahasenack> any coordination going on? To avoid stepping on someone elses work
[20:36] <mwhudson> i was about to ask if someone wants to figure out the arm64 gtk4 failure but that's not really the highest priority right now
[20:36] <mwhudson> ahasenack: yeah i'm not sure on coordination. i'm not even sure who is actively working right on it right now
[20:37] <mwhudson> ahasenack: i'm working on shepharding my cups rebuilds
[20:37] <ahasenack> someone working on openssl? I saw that openssh in noble-proposed removes libssl3, in favor of libssl3t64, and that leaves the system in a bad state
[20:37] <ahasenack> to say the least
[20:37] <ahasenack> maybe pending rebuilds?
[20:38] <mwhudson> would be good to ponder the things that still depend on libssl3 indeed
[20:38] <mwhudson> i think rebuilds have been scheduled for them all so it's a matter of finding out why they didn't build
[20:38] <ahasenack> the builders are idle: https://launchpad.net/builders
[20:39] <ahasenack> autopkgtests on the other hand...
[20:39] <ahasenack> we will only know if a retrigger now worked, a few days later
[20:39] <mwhudson> i think the autopkgtests are next week's problem
[20:40] <ahasenack> ok, so noble-proposed containers, try installing things, see what is keeping old libs around
[20:40] <mwhudson> ahasenack: i find it very useful to have a noble-armhf chdist around
[20:40] <ahasenack> I have a pi4, but yes, it's slow
[20:40] <ahasenack> i/o specially
[20:41] <mwhudson> https://paste.ubuntu.com/p/Qg4FqgCpsC/
[20:41] <mwhudson> juliank just made this as well https://magenta.jak-linux.org/ubuntu-archive/distcheck/noble.armhf/proposed-binaries.txt
[20:41] <mwhudson> (a report on what is currently uninstallable)
[20:42] <mwhudson> it's um fairly arcane but the output of this command
[20:42] <mwhudson> comm -23 <(chdist grep-dctrl-packages noble-armhf  -FDepends -w libssl3 -nsSource:Package | sort -u)  <(chdist grep-dctrl-packages noble-armhf  -FDepends -w libssl3t64 -nsSource:Package | sort -u)
[20:42] <ahasenack> is that report continuously updated?
[20:42] <ahasenack> timestamp is recent enough
[20:42] <mwhudson> are all things that need looking into to finish the libssl3t64 transition i think
[20:42] <mwhudson> i think it's on a cron, juliank can confirm if he's looking at irc
[20:44] <juliank> Hourly cron job
[20:44] <ahasenack> awesome
[20:45] <juliank> https://magenta.jak-linux.org/ubuntu-archive/distcheck/noble.armhf/proposed.txt shows uninstallable build-depends and is smaller but perhaps less powerful
[20:45] <juliank> :)
[20:45] <juliank> I'd like to make this more meaningful somehow but I don't want to overly invest in tooling
[20:59] <juliank> The human readable reports now include, for missing (build-)depends, the dependency chain that leaad to the missing dependency
[21:01] <juliank> i.e.   * lombok                                   build-depends on missing libswt-gtk-4-java:armhf via libeclipse-jdt-ui-java:armhf -> libeclipse-compare-java:armhf
[21:02] <juliank> meaing libeclipse-compare-java depends on libswt-gtk-4-java:armhf causing lombok to not build
[21:03] <juliank> I wonder if this would be enough information for the conflicts chains at the end as well
[21:03] <juliank> vs including all the metadata
[21:03] <juliank> you can find the entire metadata in the .yml variants
[21:04] <juliank> Then you'd see something like
[21:05] <juliank> * foo build-depends X via a->b->c; but also conflicting Y via x->y->z
[21:14] <juliank> OK the report is now more succinct in rendering the chains
[21:14] <juliank> consider:
[21:14] <juliank>   * plasma-desktop build-depends has conflicts: libqt5core5t64=5.15.12+dfsg-3ubuntu6 vs libqt5core5a=5.15.12+dfsg-3ubuntu1
[21:14] <juliank>     - chain 1: libkf5sysguard-dev:armhf (>= 4:5.27.11~) -> libqt5core5t64:armhf (>= 5.15.2~)
[21:14] <juliank>     - chain 2: kscreenlocker-dev:armhf (>= 5.27.11~) -> libkscreenlocker5:armhf (= 5.27.11-0ubuntu1) -> libkf5xmlgui5:armhf (>= 5.102.0~) -> libqt5core5a:armhf (>= 5.15.2~)
[21:15] <mwhudson> ahasenack: are you working on anything now?
[21:16] <juliank> mwhudson: can you tell me if the short chain rendering above is easier to read? are you missing anything?
[21:16] <mwhudson> juliank: well for example bobcat seems not to have installable b-ds but isn't on the list?
[21:17] <juliank> I don't know why that is
[21:17] <juliank> It is possible the build-depends are satisfiable but apt is too stupid
[21:17] <juliank> dose's solver sometimes is a bit more powerful
[21:18] <mwhudson> seems to be circular build deps
[21:19] <mwhudson> bobcat b-d on icmake depends on libbobcat6 depends on libssl3 but bobcat b-d on libssl-dev which depends on libssl3t64
[21:19] <mwhudson> i don't think dose is going to solve that
[21:20] <dbungert> Eickmeyer: I see some exceptions from ubuntu-desktop-bootstrap that seem to be related to the slideshow.  Does studio have the same problems?  I wonder if something in the slideshow for edubuntu doesn't quite match assumptions in bootstrap.
[21:20] <mwhudson> unless it takes libssl-dev from releasw ehich would be unhelpful
[21:23] <juliank> I told it to only take the latest version of each package
[21:23] <juliank> but it may have bugs
[21:25] <juliank> I sent an email about the new reports and new report features
[21:27] <Eickmeyer> dbungert: No, not at all.
[21:28] <Eickmeyer> I'm not using anything out of the ordinary or otherwise presented in the default template.
[21:28] <Eickmeyer> It was working before.
[21:41] <juliank> "Trivial conflicts in the same package (probably hardcoded dependency vs shlibs): " are now shown at the top
[21:42] <juliank> So e.g. zurl in there had a hardcoded "Depends: libcurl4" and a libcurl4t64 via shlibs
[21:42] <juliank> Hope this helps
[21:44] <juliank>   * bitlbee-plugin-facebook depends has conflicts: libglib2.0-0t64=2.79.3-3ubuntu5 vs libglib2.0-0=2.79.2-1~ubuntu1
[21:44] <juliank>     - chain 1: libglib2.0-0t64:armhf (>= 2.79.0)
[21:44] <juliank>     - chain 2: libglib2.0-0:armhf (>= 2.28)
[21:44] <juliank> so much fun
[21:46] <mwhudson> well at least these are mostly very easy to fix
[21:46] <juliank> Yes that's why I put them at the top for people to easily pick up :)
[21:48] <mitya57> schopin: Follow-up on my question above: I see that for qt6-webengine, doko added time-bits.diff because the package FTBFS without it on armhf: https://launchpad.net/ubuntu/+source/qt6-webengine/6.4.2-final+dfsg-12ubuntu4/+build/27929271.
[21:48] <mitya57> However, the Qt5 version builds fine without it: https://launchpad.net/~ci-train-ppa-service/+archive/ubuntu/4979/+packages. Are you sure it's needed there? (If yes, I will commit it to my packaging repo in salsa.)
[21:49] <doko> mitya57: does the qt5 version build the third_party libs? for qt6 it looks like they are built and then discarded
[21:49] <juliank> I expect them all cleaned up when I get back to work :)
[21:53] <mitya57> doko: According to the build log, breakpad and zlib/google/* are built, but not sqlite and the main part of zlib.
[22:05] <doko> mitya57: yes, that was a quick and dirty upload ... I was just guessing what else could go wrong ...
[22:20] <mitya57> doko: no problem, I was just wondering if Simon had reasons for copying that patch to Qt 5 other than "it exists in Qt 6".
[22:56] <ahasenack> I'll take a look at clamav
[22:56] <Eickmeyer> mitya57: One of those probably trying to be proactive things.... a little TOO proactive.