Getting the apt packages needs to be first, as processing probert is
more than a trivial git clone and needs some of those apt packages.
Drop probert as a requirement since it's redundant with the git
checkout.
a while ago I rewrote inject-subiquity-snap in python, generalized it
and put it at https://github.com/mwhudson/livefs-editor. TBH, it's
always been better than the shell version but now there's a reason to
switch to it: the impish live server ISO use layers, which the current
shell scripts do not support and livefs-editor now does.
The original design for timezone intentionally set the system timezone
based on geoip results, before a POST /timezone. After the feedback on
LP: #1936310 I'm having second thoughts on that and wish for GET to be
a simple informational query with no such side effects.
* Add new schema comparison, robust to timezone changes
Improve the schema comparison - mostly I'm worried about the
non-timezone items, spot check the timezone list for a few that should
be there.
* Incorporate feedback - pop
Subquity looking up various resources from SNAP is causing problems for
ubuntu-desktop-installer. Hide this detail away with SUBIQUITY_ROOT so
that other clients don't have to do magic with the SNAP env variable.
* Abstract resource file lookup relative to SNAP
Using SNAP to find the resource files is a bit of an odd requirement for
non-subiquity clients. Start abstracting that away so it's easier to
change later.
Also move loadkeys to lookup from this, since the previous solution is
still a problem for ubuntu-desktop-installer.
* Move loadkeys / configure-apt to bin
loadkeys / configure-apt are in usr/bin only when we specially put them
there by way of snapcraft, which makes things a little harder on
non-subiquity clients. Move them to bin, which is to say don't have
snapcraft put them in usr/bin.
Impish is adding more timezones, which is cool, but breaks my schema
check, so disable this there for now and come back later with a better
answer.
Also schema check seems to need curtin.
* TimeZone: autoinstall and API
Add support for Get/Set timezone methods. Get means that we inquire
with GeoIP as to which timezone is suggested. Non-availability of
GeoIP, or a previous explicit Set, means that we return the system
timezone. Set of timezone by Post results in set of the live system
timzeone, and queuing a set of the target system by way of cloud-init.
* Add clarifying comment about _request.
Dan Bungert