The pep8 binary package was a transitional package. It would install a
symlink /usr/bin/pep8 -> pycodestyle
pep8 does not exist anymore in mantic.
pycodestyle would be the right binary package going forward. That said,
we stopped using the pep8 command back in 2018 with this commit:
af9427561 Make tox and Makefile more similar.
Let's drop the dependency instead.
Signed-off-by: Olivier Gayot <olivier.gayot@canonical.com>
curtin_install before this assembled a list of steps and then executed
them one by one. As far as I can tell/remember (I was at least partly
responsible for this) there is no reason to do it this way: it feels
more Pythonic to just execute the steps!
This required removing some indirection in how the config for each step
was constructed, which I think also makes things a bit clearer.
For a dictionary, the type hint should be dict[key_type, value_type] as
opposed to dict[key_type: value_type].
Signed-off-by: Olivier Gayot <olivier.gayot@canonical.com>
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>
Olivier Gayot