[08:52] <jamespage> My local issue is entirely self inflicted (need to check what apt is going todo before confirming actions - not enough coffee) but noble-release pocket upgrade resulted in removal of quite a bit of Ubuntu desktop - I think it’s some missing amd64 builds for some gnome packages?
[09:24] <wgrant> jamespage: Things are still very much in flux because of the xz-utils mitigation rebuilds. ~8000 sources had amd64 binaries removed from the release pocket and rebuilds are making their way through proposed-migration.
[09:25] <wgrant> It's very much not wise to full-upgrade atm, heh.
[09:25] <wgrant> The last known-good versions of removed binaries are in noble-updates for the moment, if that's helpful.
[09:53] <pitti_> hello everyone, how are you? Long time no see!
[09:53] <pitti_> I'm scratching my head about the current archive state of noble -- is there a summary somewhere what's going on?
[09:53] <pitti_> (1)  cloud images are almost a month old, not quite "daily": https://cloud-images.ubuntu.com/daily/server/noble/
[09:54] <pitti_> (2) noble-updates has *older* versions than noble release, even though -updates isn't even supposed to have anything before the release; see e.g. https://launchpad.net/ubuntu/+source/openssh but I've seen it on a lot of packages
[09:54] <pitti_> i.e. none of the recent updates are actually visible in apt upgrade, it keeps installing the old version
[09:56] <wgrant> pitti_: This is part of the xz-utils backdoor mitigation. We removed several thousand recent amd64 sources' binaries, revived the known-good versions in noble-updates (because we needed a third pocket :)), and then started a bunch of no-change rebuilds through -proposed. They're still making their way back to the release pocket, so the release pocket is indeed missing a bunch of amd64
[09:56] <wgrant> binaries.
[09:56] <ogra_> pitti_, https://discourse.ubuntu.com/t/xz-liblzma-security-update-post-2/43801
[09:56] <ogra_> (and moin !!)
[09:57] <pitti_> wgrant: Ah I see, thanks!
[09:57] <pitti_> ogra_: cheers! *hug*
[09:57] <ogra_> 😄
[10:01] <adrien> and all that after t64, which is the reason for the initial delay
[10:01] <adrien> but also the reason xz-utils remained in proposed (and hardly installable)
[10:03] <adrien> pitti_: also, hey, I would maybe have mailed you instead but I have a question specifically for you! have you used (authored?) sbuild->autopkgtest->LXD?
[10:04] <pitti_> adrien: I did write the autopkgtest lxd backend, yes (in a previous lifetime)
[10:05] <pitti_> nothing in sbuild though, but perhaps you mean britney
[10:07] <adrien> pitti_: ah, that's probably the bit that I was missing: I thought the whole thing had been done by a single person
[10:07] <adrien> man sbuild says "[--chroot‐mode=schroot|sudo|autopkgtest|unshare]"
[10:08] <jamespage> wgrant: that was my guess; I've unpicked my laptops mess by using proposed for the time being
[10:08] <jamespage> I shall avoid any further updates for now!
[10:08] <adrien> my goal was to offload builds to another machine that way but it seems it's a *really* uncommon setup
[10:10] <pitti_> adrien: I'm afraid I've never seen that; isn't that more a case of just running sbuild *on* the remote machine?  But it's an interesting idea, as autopkgtest totally can build packages, and supports half a dozen backends (even podman these days); and lxd remote is cool
[10:14] <adrien> I'm not sure and I can't really tell if it was my understanding which was wrong or if the feature in sbuild is not working (it's documented as experimental): I was seeing sbuild trying to use schroot inside ephemeral lxd containers it created which doesn't make sense (they were created without setting up schroot and using them failed on schroot not being set up)
[10:15] <adrien> I probably need to talk to sbuild maintainers about that but I had thought you had used that based on one of your blog posts years ago
[12:42] <bdrung> @pilot in
[17:24] <xypron> The time_t problems seem to persist: "libelf1t64 : Breaks: libelf1 (< 0.190-1.1build3) but 0.190-1 is to be installed" in Launchpad on armhf when trying to build u-boot.
[18:19] <liushuyu> I wonder if there is currently a patch pilot shift?
[18:22] <john-cabaj> vorlon, it seems sbuild is also having trouble pulling the apt deb for noble, same as pbuilder.
[18:39] <ginggs> liushuyu: topic says bdrung, but he must have fallen asleep at the wheel
[18:40] <ginggs> calendar says kanashiro
[18:48] <liushuyu> ginggs: sleeping behind the wheels is illegal in many territories though
[19:22] <vorlon> john-cabaj: yes, "things are in flux due to xz-utils"
[19:23] <john-cabaj> ack, will try back later and get by with a VM for now
[20:41] <kanashiro> sorry, it is me indeed, I will work on it now
[20:41] <kanashiro> @pilot in
[20:43] <kanashiro> liushuyu any specific request?
[20:44] <liushuyu> kanashiro: https://code.launchpad.net/~liushuyu-011/ubuntu/+source/libcdio/+git/libcdio/+merge/463629 this one, for fixing time_t issues for armhf
[20:44] <liushuyu> It's also blocking seeded packages
[21:06] <kanashiro> liushuyu done
[21:07] <liushuyu> kanashiro: Thanks!
[21:09] <bdmurray> arraybolt3: Is the milestone regarding lubuntu-update-notifier in bug 1673258 still important?
[21:09] -ubottu:#ubuntu-devel- Bug 1673258 in lubuntu-update-notifier (Ubuntu) "Remove aptdaemon and drop or port its reverse-dependencies" [Medium, Confirmed] https://launchpad.net/bugs/1673258
[21:41] <kanashiro> doko are you working on gcc-13? I am trying to sponsor some uploads to noble but I cannot build them due to unmet dependencies
[21:41] <kanashiro> https://chat.debianbsb.org/file/3/YLYcMabgq74lDDR7
[22:03] <arraybolt3> bdmurray: that's actually fixed in Noble and has been for a while
[22:03] <arraybolt3> I should mark it as Fixed Released.
[22:04] <arraybolt3> done
[22:04] <arraybolt3> s/Fixed/Fix/
[23:37] <bdrung> Attention! This is your captain speaking. I have got good news and bad news. The good news is we'll be landing immediately. The bad news is we are crash landing.
[23:37] <bdrung> @pilot out