This update will cover the last two weeks.Pop!_OS is a Linux distribution by System76, a Linux-based desktop hardware OEM. It is based on Ubuntu, with many enhancements specific to our vision of the desktop, and provides an optimal platform for our hardware, which is thoroughly tested throughout each release. These weekly posts highlight the developments that have been made each week in Pop!_OS.
Rust 1.35 Released
Canonical has updated the version of Rust in the repositories for all supported Ubuntu releases to 1.35.0. This brings a handful of quality of life improvements to the language, adds support for futures from the standard library, and will allow us to use the latest version of the gtk-rs crate (0.7), so that we can create GTK dialogs without using an unsafe scope, and set the header function on list boxes.
A new binary sub-project was added to the Firmware Manager that provides desktop notification support. On login, this binary will check if firmware updates are available, and then provides a clickable notification that opens either the Firmware panel in GNOME Settings, or the standalone GTK application. It does so by checking if
/usr/share/applications/gnome-firmware-panel.desktopexists, then executing either
gnome-control-center firmware, or
To support this new binary, the GTK portion of the project was split into a library + binary sub-project of its own, and the remaining UI-agnostic code is now shared between the desktop notification and GTK widget library. If anyone wished to do so, this UI-agnostic library could be used to write the UI in toolkits other than GTK.
Pop UpgradeDue to the recent Rust 1.35 update, the project has been updated to 1.35, and list boxes now set the header function, which is used to place separators in the header of each list entry.
The upgrade daemon now splits its debian packages between the daemon, CLI binary, and GTK widget library. An error callback was also added so that C and Rust frontends may display errors to the user. The GNOME Settings integration takes this and uses it insert the error message into an info bar. Some testing was performed on a bionic installation, which successfully upgraded to disco. The same patch is also available for cosmic.
ECS Disk Manager
In my previous post about the WIP disk manager, the project had entities and components, but only a single system for scanning device information and populating the world with entities and components found from scanning. As of today, many systems have been added to the world in varying stages of completion; and many changes were made to the world, and how it stores components, to accommodate the features needed by these systems.
A separate component storage collection holds all of the queued operations and their theoretical components to be applied by the system. Keeping queued operations in a separate storage collection ensures that operations can be cancelled, and simplifies the design of the systems which can readily access the queued components that they interact with, migrating these components into the world after each successful operation.
The first system to be executed is the removal system. It will apply all devices that have been tagged for removal, supporting the removal of partitions and wiping disk signatures. Removing a logical volume from a LVM volume group is not yet supported, but support will be trivial once the required methods are added to the
The second system, currently unimplemented, will be the resizing system, which will resize partitions. In addition to resizing partitions, it will need to be able to activate and deactivate LVM PVs on LVM VGs. This is currently a low priority, so it will be the last system to be implemented.
The third, and the most complex, system added was the creation system. This system is nearing completion, and is responsible for applying all operations that create partitions, LVM PVs, LVM VGs, and LVM LVs. In order to support this system, methods have been added to the disk manager to specify creation operations. The challenge has been supporting not only the creation of partitions on partitionable devices, but also the creation of partition tables, LUKS-encrypted partitions, LVM volume groups, and the LVM logical volumes that are assigned to LVM volume groups. Some further work will be necessary to support creating LVM and LUKS devices.
Finally, the modification system is the last system to be executed. It will format all devices that can be formatted in parallel, and will also relabel partitions in GUID partition tables. This is the easiest system to support, as it will essentially run the
mkfscommand in parallel for each entity that is marked for receiving a new file system. Parallel execution won't be limited to this system, however, as technically all of these systems are fully capable of performing parallel operations, and have been designed with that goal in mind.
In addition to the new systems, the beginnings of a DBus API was added as a sub-project. This will be responsible for interacting with distinst, and other disk management client frontends. In addition to the benefits that this will provide to distinst, this will open the door to new disk management utilities which could support execution in Wayland sessions, and in Flatpak confinement.
README.mdwas updated to reflect the current design. By the time the next weekly update is posted, I hope to have completed the vast majority of the systems, and have a CLI binary to test the disk manager with real world hardware in practice. Once the disk manager is complete, the DBus daemon will become the focus, followed by porting the disk manager to distinst, and removing all the complex disk management logic from it.