A new job now runs on PRs. It will automatically run mypy on the target
branch and on the source branch. It will generate a diff of the errors,
showing the new ones and showing the ones that have been fixed.
It will also show a summary with the number of errors before/after the
PR.
Because we have so many false positive, it makes no sense to mark this
job red. So we always make it green (unless mypy can't run).
As for now, it's up to developers to go check if any new error is
introduced.
If a line that used to produce a mypy error gets moved, it will be
reported as:
* a fixed error
* a newly introduced error
This is suboptimal and ideally we should have a way to detect moves.
Signed-off-by: Olivier Gayot <olivier.gayot@canonical.com>
bind_mount_tree really wants to mount to places that don't exist yet,
and to unmount them later. Simply creating these files or directories
gets weird. Manage this process in the Mounter, so that any of these
temporary mountpoints get cleaned up on unmount.
Given disk layout like so
[p1 g1 p2 p3 g2]
The code attempting to create p4 used the largest_gap() method to
attempt to select g2. If the disk was small enough, below 28GiB with
current numbers, g1 would actually be larger, but the sizing math was
done with the offset that was correct for g2, so p4 would be created
a very incorrect size (-800MiB or so).
Just select gap by offset - we have the info needed.
By default, curthooks will automatically reorder the UEFI boot entries
so that the media used during installation is set as the first boot
entry.
This is something that MAAS wants because MAAS typically boots over the
network.
This is not typically something we would want for a server or desktop
installer though. Most of the time, the media is a removable device.
Ideally, we would want the new installed grub to be the first boot
entry.
Furthermore, on some UEFI implementations, the BootCurrent does not
correspond to a Boot#### entry when booting from a removable media. When
this happens, curtin fails at making the media the first boot entry,
resulting in the following error:
Invalid BootOrder order entry valueXXXX
^
efibootmgr: entry XXXX does not exist
Fixed by disabling the UEFI boot entries reordering when invoking
curthooks.
Signed-off-by: Olivier Gayot <olivier.gayot@canonical.com>
Some people who installed a previous version of Ubuntu on a DOS
partition table ended up with a logical, ESP partition (which is marked
bootable).
This is an unsupported use-case. An ESP partition should always be a
primary partition. Ideally, an ESP partition should be on a GPT.
However, curtin's storage_config makes it clear that expecting the flag
of a logical partition to be set to 'logical' is a bad idea.
# if the boot flag is set, use this as the flag, logical
# flag is not required as we can determine logical via
# partition number
Other people want to create a swap partition in an extended partition.
This is a perfectly valid use-case and we set flag='swap' for those
partitions.
Therefore, in subiquity code, we cannot just check if a partition has a
flag set to 'logical'. We need to look at the partition number too.
Signed-off-by: Olivier Gayot <olivier.gayot@canonical.com>
If a probert run finished in the middle of partitioning, the probing
data would be loaded automatically and this would essentially discard
changes made so far by the user. This is not a desirable behavior.
Upon starting partitioning, we now prevent later probert runs from
automatically loading the probe data. Instead, the data is stored and
only loaded after after a reset.
Signed-off-by: Olivier Gayot <olivier.gayot@canonical.com>
For mirror testing, we run apt-get update on the host. By default,
external commands run by subiquity inherit the environment variables set
by the snap (including LD_LIBRARY_PATH).
We don't ship apt-get or its dependencies in the subiquity snap, so we
want to reset LD_LIBRARY_PATH and other variables when running the
command.
Not doing so leads to the following error when running the subiquity
snap on a focal-based system:
* apt-get: /lib/x86_64-linux-gnu/libc.so.6: version `GLIBC_2.33' not
found (required by /snap/subiquity/4675/usr/lib/x86_64-linux-gnu/libsystemd.so.0)
* apt-get: /lib/x86_64-linux-gnu/libc.so.6: version `GLIBC_2.32' not
found (required by /snap/subiquity/4675/usr/lib/x86_64-linux-gnu/libsystemd.so.0)
* apt-get: /lib/x86_64-linux-gnu/libc.so.6: version `GLIBC_2.34' not
found (required by /snap/subiquity/4675/usr/lib/x86_64-linux-gnu/libsystemd.so.0)
* apt-get: /lib/x86_64-linux-gnu/libc.so.6: version `GLIBC_2.33' not
found (required by /snap/core22/current/lib/x86_64-linux-gnu/libcap.so.2)
Signed-off-by: Olivier Gayot <olivier.gayot@canonical.com>
When we create a swap partition using v2_add_partition, the mount
parameter always has the value of None.
We do however, create a fake mountpoint object and assign it the value
of "" (empty string) so we know the swap partition is used although it's
not really mounted anywhere in the filesystem hierarchy.
Subsequently, when editing the swap partition, the mount parameter is
set to the empty string, not None.
This causes trouble in the create_mount function, which normally returns
immediately upon encountering None as the mountpoint.
Fixed by skipping the call to create_mount for a swap partition.
Signed-off-by: Olivier Gayot <olivier.gayot@canonical.com>
Subiquity snap doesn't stage language-selector-common nor locales
packages.
Attempting to run those commands require respecting the env previously
prepared by the caller, as well as fixing the commands paths
(or changing the PATH env var in the env preparation step).
Since the apt commands were already ran with a fixed path,
I'm applying the same principle in here.
Yet, for now, Jammy doesn't ship the l-s-c package seeded,
so a condition was preserved to avoid future crashes.
Olivier Gayot