[00:18] <xnox> thank you
[00:18] <xnox> gonna resintall now
[00:25] <xnox> vorlon: can you please at least add one test case? like normal install to http://iso.qa.ubuntu.com/qatracker/milestones/446/builds/287742/testcases because otherwise nobody can report neither success nor failure.
[01:06] -queuebot:#ubuntu-release- Unapproved: rust-ashpd (mantic-proposed/universe) [0.6.2-2ubuntu1 => 0.6.2-2ubuntu2] (no packageset)
[01:08] -queuebot:#ubuntu-release- Unapproved: accepted rust-ashpd [source] (mantic-proposed) [0.6.2-2ubuntu2]
=== chris14_ is now known as chris14
[01:14] <xnox> found it
[01:18] <xnox> https://code.launchpad.net/~xnox/casper/+git/casper/+merge/452494
[01:59] <vorlon> xnox: the thing is I can't link test /cases/, I have to link test /suites/, and that's what wants refactoring/cleanup.  In the meantime I've linked the Ubuntu Desktop testsuite (lucky me that I got the right one by that name!) so there are places to link test reports
[02:01] <vorlon> xnox: kernel-meta-package hnngh dbungert mwhudson_ and I had discussed that this cycle, and I distinctly remember a "maybe we shouldn't do that in casper"
[03:06] -queuebot:#ubuntu-release- Unapproved: partitionmanager (mantic-proposed/universe) [23.08.1-0ubuntu1 => 23.08.1-0ubuntu2] (kubuntu)
[09:29] -queuebot:#ubuntu-release- Unapproved: accepted partitionmanager [source] (mantic-proposed) [23.08.1-0ubuntu2]
[13:14] -queuebot:#ubuntu-release- Unapproved: rust-xkb (mantic-proposed/universe) [0.2.1-2 => 0.3.0-1] (no packageset) (sync)
[13:15] -queuebot:#ubuntu-release- Unapproved: accepted rust-xkb [sync] (mantic-proposed) [0.3.0-1]
[13:34] -queuebot:#ubuntu-release- Unapproved: rust-xkbcommon-sys (mantic-proposed/universe) [0.7.5-2 => 1.4.1-2~ubuntu1] (no packageset)
[13:35] -queuebot:#ubuntu-release- Unapproved: accepted rust-xkbcommon-sys [source] (mantic-proposed) [1.4.1-2~ubuntu1]
[14:25] -queuebot:#ubuntu-release- Unapproved: rust-xkbcommon-sys (mantic-proposed/universe) [1.4.1-2~ubuntu1 => 1.4.1-2~ubuntu2] (no packageset)
[14:26] -queuebot:#ubuntu-release- Unapproved: accepted rust-xkbcommon-sys [source] (mantic-proposed) [1.4.1-2~ubuntu2]
[17:52] <vorlon> fossfreedom_: in reviewing casper vs livecd-rootfs stuff for the new arm64+x13s image, I noticed that the new budgie image is not able to do offline installs due to the way subiquity handles kernels.  If this is something you want to support, you'll need to seed a copy of the kernel in the package pool on the ISO
[17:52] <vorlon> fossfreedom_: (the 'ship-live' seed)
[17:52] <vorlon> (see ubuntu for reference)
[18:00] <Eickmeyer> vorlon: Not sure if you got the memo, but one of the takeaways from this past Ubuntu Flavor Sync meeting was that ubiquity *must* be sunset before 24.04's release to avoid supporting it for the duration of the LTS, which means all flavors will be making a gigantic effort to switch to subiquity/u-d-i in the next cycle.
[18:03] <Eickmeyer> (except Lubuntu)
[18:04] <vorlon> Eickmeyer: who decided that it must be sunset?
[18:05] <Eickmeyer> Desktop team.
[18:05] <vorlon> I am in principle in favor of the idea of getting flavors to re-consolidate on an installer that is actively maintained and developed
[18:06] <vorlon> but also, just as the Desktop Team doesn't maintain calamares, the Desktop Team wouldn't be responsible for maintaining a ubiquity that's in universe, if flavors insisted on sticking with that
[18:07] <Eickmeyer> Flavors don't want to maintain something they don't have 1) commit access to, and 2) don't have general community support from.
[18:07] <Eickmeyer> Flavors *are* Ubuntu, not separate distributions.
[18:08] <jbicha> I don't think it's the Ubuntu Desktop team position that flavors "must" switch away from ubiquity for 24.04 LTS; but it is a good goal
[18:10] <Eickmeyer> jbicha: The general consensus is that flavors don't want to use something that they're not getting the promised support from Canonical for.
[18:10] <Eickmeyer> Being an offical flavor has "perks", and that's one of them.
[18:10] <jbicha> Eickmeyer: that's saying something than your original statement
[18:10] <jbicha> *something different
[18:10] <Eickmeyer> jbicha: Maybe I'm misinterpreting Oliver's position?
[18:11] <jbicha> https://discourse.ubuntu.com/t/flavor-sync-meeting-notes-september-11-2023
[18:11] <Eickmeyer> jbicha: It's not in the notes, but it was definitely discussed.
[18:12] <jbicha> discussed as a goal to stop using ubiquity or as a mandate?
[18:13] <jbicha> Ubuntu Desktop needs to stop shipping a separate legacy ISO. Doing that & dropping ubiquity to universe relieves the 10 year support commitment
[18:13] <Eickmeyer> A mandate, iirc. No flavor lead currently has commit access to Ubiquity, so what advantage would it give us to keep using it and repair issues on our own?
[18:14] <Eickmeyer> Historically (not recently) it has been like pulling teeth to get MPs in.
[18:14] <Eickmeyer> That's why Lubuntu switched installers altogether.
[18:17] <vorlon> "don't have commit access to" - it's self-evident to me that if the Desktop Team (and Canonical) discontinued maintenance of ubiquity, that would change
[18:17] <vorlon> just like it did for unity
[18:18] <vorlon> if the flavors have all concluded that their preference is to adopt ubuntu-desktop-installer for 24.04, though, then I'm thrilled, because that's more code I can delete from livecd-rootfs
[18:18] <Eickmeyer> Still, I have no interest in maintaining something that is like a patchwork quilt of python files upon python files. subiquity is much more solid, and the other flavor leads agree.
[18:20] <vorlon> I do dispute the claim that Lubuntu switched to calamares because it was "pulling teeth" to get MPs in
[18:27] -queuebot:#ubuntu-release- Unapproved: refpolicy (mantic-proposed/universe) [2:2.20230821-1 => 2:2.20230929-1] (no packageset) (sync)
[18:28] -queuebot:#ubuntu-release- Unapproved: accepted refpolicy [sync] (mantic-proposed) [2:2.20230929-1]
[18:28] <Eickmeyer> vorlon: Ask tsimonq2 .