[00:40] <vorlon> ok well python-apt is fixed now but I don't know what package ahasenack was trying to build that we should retry
[01:00] <twb> Is systemd-ukify  available in noble?  It ought to be in systemd 253+ and Debian has it, but I don't see it being disabled in the debian->ubuntu diff (https://patches.ubuntu.com/s/systemd/systemd_255.2-3ubuntu2.patch) and I also don't see it in apt-file
[01:01] <twb> I'm trying to port this from trixie to noble: https://github.com/cyberitsolutions/bootstrap2020/blob/twb/debian-13-minimal.py (as the build target, not the build host)
[01:02] <vorlon> twb: I see the package present in noble, not sure why you do not?
[01:02] <twb> Hrm OK must be an issue on my end, let me look deeper...
[01:03] <twb> Oh!  I somehow wrote "focal" still
[01:03] <vorlon> yes that would be slightly older
[01:04] <twb> yeah I know this is post-focal
[01:26] <twb> Huh.  Ubuntu defaults to link_in_boot=yes (i.e. /boot/vmlinuz not /vmlinuz)
[01:27] <vorlon> sure? why wouldn't it
[01:28] <vorlon> might be a separate partition from /boot so why is a symlink in / a sensible thing in the general case
[01:28] <vorlon> \/
[01:28] <vorlon> ok whatever irc
[01:28] <vorlon> \/ might be a separate partition from /boot so why is a symlink in / a sensible thing in the general case
[01:28] <twb> Right, I've been adding it by hand to every Debian system forever
[01:28] <twb> But I thought everyone else had stopped using those symlinks at all
[01:29] <vorlon> frankly I think we should drop support for link_in_boot=no altogether, if we haven't already
[01:30] <vorlon> twb: there are some bootloader scenarios other than your typical grub-on-Ubuntu-classic that rely on resolving the kernel via these symlinks
[01:30] <twb> I definitely like having the symlinks where /boot is symlink-capable.
[01:30] <twb> But if you instead change it so /boot can be part of a FAT32 ESP, that'd also be nice :-)
[01:31] <vorlon> sure, do_symlinks=no is valid; but link_in_boot=no is not
[01:31] <twb> (Right now it can't because dpkg directly manages /boot/vmlinuz-X-Y-Z, so it needs hard link support to do an atomic replace)
[01:31] <vorlon> well yes
[01:32] <twb> Sorry I'm just chatting while I wait for this build :-)
[01:32] <twb> Success!
[01:46] <twb> Hrm, live-config on Ubuntu 24.04 is still trying to configure networking via /etc/network/interfaces instead of netplan or systemd-networkd.
[01:47] <sarnold> o_O
[01:48] <sarnold> ah, universe package, that's why it didn't sound familiar
[01:48] <twb> Is it just part of "casper" on Ubuntu still?
[01:49] <twb> I don't really care what package I use to provide "sensible defaults for a live image"
[01:53] <vorlon> live-config is nothing we use
[01:56] <twb> Yeah from was I saw last week it looks like there's no first-party equivalent anymore, for a long time
[01:59] <twb> Looks like Ubuntu's systemd integration ignores .preset and "systemctl preset-all" infrastructure, the same as Debian.  That's mildly irritating.
[02:00] <twb> (My evidence is just that "systemctl preset-all" enables a bunch of things, rather than being a no-op)
[02:10] <twb> FYI this is working enough™ that I can go back to my real job: https://github.com/cyberitsolutions/bootstrap2020/blob/twb/ubuntu-24-minimal.py
[02:11] <twb> It's kinda slow (126 seconds) but I think that's just because Ubuntu's smallest bootable install is bigger
[02:20] <twb> Wow, yeah.  It's 4 times bigger >_<  https://paste.rs/JrLXV
[03:27] <amurray> does anyone know what time feature freeze comes into effect tomorrow?
[03:30]  * twb wonders whether amurray is planning a party, or a supply-chain attack ;-)
[03:30] <amurray> heh just a new apparmor upload...
[03:37] <vorlon> amurray: end of day US
[03:37] <vorlon> juliank: mmk so is https://launchpad.net/~ubuntu-cdimage/+livefs/ubuntu/noble/cpc/+build/584685 a debootstrap failure within noble....
[03:37] <amurray> vorlon: ack
[04:41] <arraybolt3> amurray: *just* a new apparmor upload? One can never be too sure of those things...
[04:41] <arraybolt3> *ducks*
[05:50] <amurray> arraybolt3: 😀
[06:09] <juliank> vorlon: it looks like it, but it's a pi build , which uses the Ubuntu-Image snap, which has debootstrap from jammy staged
[06:10] <vorlon> juliank: oh yes doh sorry
[06:10] <vorlon> juliank: and good morning
[06:13] <juliank> And good I guess evening to you! So dropping gnupg2 from proposed arguably will unbreak dependency resolution on armhf
[06:14] <vorlon> juliank: I had dropped it for the python-apt build but then added it back. shall I drop it again?  not many things build-depend on gnupg I think
[06:14] <juliank> Ah ok
[06:17] <juliank> vorlon: did you try building release pocket one locally for comparison? I don't believe the patch could cause the regression because all it does is add a new option and then it verifies algorithms if set - which nothing in the test suite uses (Werner!)
[06:18] <vorlon> juliank: I did not
[06:18] <juliank> OK, one thing for me to try
[06:18] <vorlon> I'm busy managing 3 simultaneous streams of mass uploads :)
[06:18] <juliank> I guess I should setup an armhf container on the arm64 Chromebook
[06:25] <juliank> The tests in gnupg are annoying. That thing ships its own scheme interpreter (gpgscm) and then the tests are written in scheme
[06:27] <vorlon> hahahahaha
[13:17] <seb128> hum, for things like https://launchpadlibrarian.net/716712884/buildlog_ubuntu-noble-armhf.glib-networking_2.80~alpha-2_BUILDING.txt.gz
[13:17] <seb128>  dconf-service : Depends: libglib2.0-0 (>= 2.55.2) but it is not installable
[13:17] <seb128> should I just upload a no change rebuild for dconf?
[13:18] <seb128> jbicha, ^ you might know
[13:24] <jbicha> seb128: I haven't heard what Foundation's plan is for the rebuilds. dconf isn't quite at the bottom but it might work https://ubuntu-archive-team.ubuntu.com/transitions/html/auto-glib2.0.html
[13:25] <seb128> jbicha, ok, I will try, it's sort of a special case because it's pulled in gnome builds
[13:29] <adrien> can someone sync xz-utils 5.6.0-0.2 from experimental? thanks  (see #2055422 )
[13:29] <adrien> https://bugs.launchpad.net/ubuntu/+source/xz-utils/+bug/2055422
[13:29] -ubottu:#ubuntu-devel- Launchpad bug 2055422 in xz-utils (Ubuntu) "Please sync xz-utils 5.6.0-0.2 from Debian experimental" [Undecided, New]
[13:30] <jbicha> seb128: btw, I had briefly synced glib 2.79.3-2 from experimental last night but we quickly backed it out because glib at the time had uninstallability/bootstrap problems
[13:31] <seb128> jbicha, right, I saw the irclog backlog
[13:31] <jbicha> on armhf
[13:31] <jbicha> cool
[13:31] <seb128> adrien, _o/
[13:32] <ginggs> adrien: xz-utils 5.6.0-0.2 was uploaded to unstable and autosync'd
[13:32] <ginggs> https://launchpad.net/ubuntu/+source/xz-utils/5.6.0-0.2
[13:40] <adrien> \o seb128
[13:41] <adrien> ginggs: doh! sorry for the noise, I didn't pay attention, that was stupid of me
[13:41] <seb128> adrien, and what ginggs said :-)
[13:41] <seb128> anyway it is in noble which is what matters!
[13:41] <adrien> (I have an excuse for today but not for monday and tuesday when I thought of this first :P )
[13:42] <ahasenack> is someone working on this:
[13:42] <ahasenack> The following packages have unmet dependencies:
[13:42] <ahasenack>  libhogweed6t64 : Breaks: libhogweed6 (< 3.9.1-2.1) but 3.9.1-2 is to be installed
[13:42] <ahasenack>  libnettle8t64 : Breaks: libnettle8 (< 3.9.1-2.1) but 3.9.1-2 is to be installed
[13:42] <ahasenack> armhf
[13:42] <adrien> yes, I think it's going to be useful in noble! and I'll keep an eye on the migration :)
[13:57] <jbicha> ahasenack: there will be thousands of rebuilds to get armhf working normally again
[13:58] <ahasenack> yep
[13:58] <ricotz> hello, is gcc-14 still aiming to be default in noble?
[13:58] <ahasenack> but I care more about mine, of course :D
[13:58] <ahasenack> j/k
[13:58] <jbicha> ahasenack: me too! :)
[16:01] <sergiodj> @pilot in
[17:05] <nubuntu> yo
[17:07] <nubuntu> 24.04 default layers for minimal.squashfs, minimal.standard.squashfs and minimal.standard.live.quashfs or filesystem.squashfs is back release?
[17:08] <dbungert> nubuntu: rephrase the question please, not following
[17:11] <nubuntu> I need to customize a version of ubuntu(noble) to use at school. But in this new version there are 3 squashfs files (minimal, minimal.standard and minimal.standard.live) before is only filesystem.squashfs. I'm not sure which one to modify the system now since it's so "divided". Would anyone have any documentation about this layers and who i can
[17:11] <nubuntu> edit?
[17:12] <dbungert> minimal.standard.live is the installer layer, which I presume is not what you want to modify
[17:13] <dbungert> directly modifying layers above that can work if you're careful but it can also get weird
[17:13] <dbungert> generally you're better off letting the install proceed with the stock image and fixing after-the-fact
[17:13] <dbungert> if you want to proceed with an edit anyhow https://github.com/mwhudson/livefs-editor may help
[17:14] <dbungert> we're borderline on the content for this channel though
[17:14] <nubuntu> Thanks a lot
[17:14] <dbungert> Welcome!
[17:20] <nubuntu> dbungert at public release, will noble still into layers?
[17:20] <dbungert> yes
[17:26] <nubuntu> https://help.ubuntu.com/community/LiveCDCustomization need updated!
[17:26] <nubuntu> haha
[18:08] <ahasenack> xnox: hi, still around? :)
[18:08] <ahasenack> xnox: back in 2019, you added this change to multipath-tools: https://git.launchpad.net/ubuntu/+source/multipath-tools/commit/?id=8adefeb66a6628d1e27d3da32ddac70e73149796
[18:08] -ubottu:#ubuntu-devel- Commit 8adefeb in ubuntu/+source/multipath-tools "0.7.4-2ubuntu6 (patches unapplied) import/0.7.4-2ubuntu6"
[18:08] <ahasenack> xnox: we have been carrying it as delta since then, as debian rejected it (https://salsa.debian.org/linux-blocks-team/multipath-tools/-/merge_requests/4/diffs?commit_id=43b060cfdcf18c76efd12f17ebc7bbb241b39598)
[18:08] -ubottu:#ubuntu-devel- Merge 4 in linux-blocks-team/multipath-tools "Install friendly names multipath.conf by default" [Closed]
[18:08] <ahasenack> we (I) don't quite understand it, and there is an MP up to drop it. Is that wise? Drop it?
[18:08] <ahasenack> what's the impact?
[18:09] <ahasenack> there was no bug attached to the change or any other source of discussion I could find
[18:09] <ahasenack> mwhudson_: would you know what that was about? use friendly names by default in multipath-tools? Would that impact our installer by any chance, if we dropped it?
[18:10] <ahasenack> (if anybody else knows, please chime in)
[18:10] <mwhudson_> ahasenack: i don't know, no
[18:11] <ahasenack> mwhudson_: do you know if we have some installer test case that covers multipath devices?
[18:11] <ahasenack> paride: do you know? ^
[18:12] <paride> ahasenack, yes we do, but just a basic case
[18:12] <ahasenack> paride: booting from it?
[18:12] <mwhudson_> ahasenack: i doubt we test it very extensively
[18:17] <paride> ahasenack, yes, but again it'
[18:17] <paride> it's a rather simple test. this is the libvirt conf we use: https://paste.ubuntu.com/p/Qq94f22whW/
[18:17] <paride> see the <shareable> and <wwn> elements
[18:19] <paride> but that's it. then on the booted system we check that we're actually using those disks as multipath devices
[18:20]  * paride looking for the test
[18:21]  * paride finds a slow launchpad
[18:22] <paride> ahasenack, here is the test https://bazaar.launchpad.net/~subiquity/ubuntu-test-cases/live-server/view/head:/testsuites/multipath/test_multipath/test.py
[18:25] <ahasenack> thx
[18:25] <ahasenack> paride: got a 503
[18:25] <ahasenack> bazaar, is that right?
[18:26] <ahasenack> loaded now
[18:30] <nubuntu> 503 Service Unavailable
[20:48] <sergiodj> @pilot out
[21:44] <cpete> hey LocutusOfBorg, I made a mistake and running-autopkgtest wasn't actually made available in the new version of ubuntu-dev-tools. Since you sponsored my original merge, I thought you might be interested in the fix. I opened #2055466
[21:45] <UnivrslSuprBox> (That's lp:2055466 for the bots among us)
[21:45] -ubottu:#ubuntu-devel- Launchpad bug 2055466 in ubuntu-dev-tools (Ubuntu) "running-autopkgtests isn't installed" [Undecided, In Progress] https://launchpad.net/bugs/2055466
[21:46] <cpete> Ah I was just wondering how to get the bot to do its thing. Thanks UnivrslSuprBox
[21:50] <LocutusOfBorg> done
[21:53] <LocutusOfBorg> and uploaded
[22:02] <cpete> Nice. Thanks a bunch!