Merge ~waveform/ubiquity:prepare-package into ubiquity:main

given that the intention is to drop ubiquity out of main entirely for 24.04 (either leaving it for community flavors to maintain in universe if they continue to rely on it, or dropping it from the archive), I'm uncomfortable with the introduction of new code here related to oem-config, the bit of ubiquity that we don't yet have replaced in main. What is the larger plan for superseding this bit of code in 24.04, and can we accelerate that instead?

I'm told the plan is for subiquity to grow this functionality, but I've no details on delivery (which makes me at least want a backup plan in place). Incidentally, this isn't new code as such: it's code from livecd-rootfs that should've been in oem-config all along. One of the merges in the associated ticket [1] removes that code from livecd-rootfs, this merge places it in an extra package here, and then the final merge from the ticket [2] uses this package in the image definition yaml (which is currently missing all the user setup stuff).

[1]: https://code.launchpad.net/~waveform/livecd-rootfs/+git/livecd-rootfs/+merge/456463

[2]: https://code.launchpad.net/~waveform/ubuntu-images/+git/ubuntu-images/+merge/456465

Frankly I do prefer keeping that in livecd-rootfs until we have dropped ubiquity and a final solution rather than add a binary here for a couple of weeks.

Re: keeping it in livecd-rootfs: we don't use livecd-rootfs for building the Pi images anymore, so if I wind up needing this as a fallback for the desktop images, it's not going to do any good there.

Having now trawled the desktop engineering Jira, it appears the plan is to deliver this via the Ubuntu Welcome application in 24.04, and things appear to be progressing well (I'll see if I can find some time to play with it in the new year). Still, I like having a plan B to fall back on, just in case (having needed them in the past!). If Ubuntu Welcome lands in time, all well and good, everyone can ignore this extra package and/or remove ubiquity entirely from the archive -- it won't make any difference. If Ubuntu Welcome *doesn't* land in time, this will be required for the Pi desktop images to work at all.

On Fri, 15 Dec 2023 at 05:56, Dave Jones <email address hidden>
wrote:

> Having now trawled the desktop engineering Jira, it appears the plan is to
> deliver this via the Ubuntu Welcome application in 24.04, and things appear
> to be progressing well (I'll see if I can find some time to play with it in
> the new year).

Please do this uh, conversationally :-) (i.e. talk to the desktop people
about your needs!)

> Still, I like having a plan B to fall back on, just in case (having needed
> them in the past!). If Ubuntu Welcome lands in time, all well and good,
> everyone can ignore this extra package and/or remove ubiquity entirely from
> the archive -- it won't make any difference. If Ubuntu Welcome *doesn't*
> land in time, this will be required for the Pi desktop images to work at
> all.
>

I think plan B on the desktop side is to use gnome-initial-setup. Can that
be made to work for the pi desktop image?

Cheers,
mwh

Circling back to this; my understanding was the gnome-initial-setup was considered at some stage but rejected in favour of modifying the new installer to fit the pre-installed use-case. Obviously this didn't happen in noble, and we wound up sticking with oem-config there for the initial release.

I'm still not entirely clear on how those image builds even work because without this patch, the oem user *shouldn't* exist in the images for oem-config-prepare to run successfully (to be clear: the image *doesn't* build successfully in ubuntu-image locally without this patch). Probably something buried in livefs somewhere.

I don't have enough context to know what part of the oem config mode the pi image needs but on a standard desktop installation if there is no user created gnome-initial-setup will start in initial-user mode which allows creating the account and setting up language/keyboard/timezone for the system

The pi images use (and have always used) oem-config for the initial user setup (and language, timezone, keyboard, etc). The only bit that gnome-initial-setup takes care of is the greeter after the (freshly created) user first logs in.

Incidentally, I've now discussed the requirements of the pi desktop with the installer team; while support for pre-installed images is planned this cycle, it is unlikely that the specific pi case will be supported this cycle (it'd be "nice to have", but I take that as "unlikely"). So, given we'll likely have oem-config again this cycle, I'd really like to get this merged so I can build test images cleanly.