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.
Pop GTK Theme
It was detected that GTK’s CSS renders SVG files as PNGs before scaling them, resulting in blurry switches, check boxes, and radio buttons in HiDPI mode. This has been fixed. In preparation for the latest version of GNOME in the upcoming 19.04 release, the styling of hdy widgets have also been fixed.
Some icons lack background shadows in the shop, and may appear to blend in with the background. This is soon to be addressed in the CSS theme of the application, which will automatically apply a background shadow to icons.
System76 Power Daemon Improvements
Although these changes have not yet been merged, system76-power has gained a pull request which allows the daemon to track the currently-active power profile, which thereby allows the daemon to send signals to applications which are listening for power profile changes, and the ability for applications to query the currently-active state.
This will be important for fixing a long-standing issue with the system76-power GNOME Shell extension, which would always reset to "balanced" after suspension, or would not update to display the currently-active profile if the profile was modified from the command line. This PR will bring the required functionality to the daemon. Whereas this PR will integrate the new features in the shell extension.
CUDA 10.1 & Tensorflow 13.1
The CUDA 10.1 toolkit was recently released, so the packaging process for that has started. Tensorflow 13.1 packaging has also begun, and will be released at the same time that the CUDA 10.1 toolkit is added to our repository. I hope to have this completed by the end of the next week. This includes updated 10.1 packages for CUDNN and NCCL, as well.
Pop Upgrade Daemon
This week was dominated by the continued development on the
pop-upgrade daemon. Throughout the week, it has been incrementally tested and improved, but there is still much work to be done. The offline upgrade option has been the focus of testing for this week, and is almost complete. Debian packaging has also been added to the repository, so it is now being built in our proposed repository.
One of the important features implemented this week was prohibiting suspension while the daemon is actively processing an event. There are some potentially dangerous operations that occur when an upgrade is in process. The daemon begins an upgrade by fetching packages for the current release, upgrading the current release with those packages, switching the apt sources lists to the new release, fetching all the packages required for release upgrade, and then creating some files to initiate the upgrade on the next reboot.
Having a system suspend or shut down during one of these events may leave the system in a bad state on the next boot. Thus, these will be prohibited. However, there’s no guarantee that an unfortunate event will still occur during the process, which causes the system to power off anyway. So, some files are created before the upgrade process begins, and if that file exists the next time the system starts, the daemon will attempt to correct any changes that were made.
The only potentially-dangerous change that’s made when setting up the upgrade process is modifying the apt source lists to point from the active release to the next release, so recovering from that is a matter of simply doing the reverse.
The system may also be in a bad state even before the daemon has made any changes. A repair option has been added to the client and daemon, and integrated into the upgrade process, which will correct some easily-correctable issues. Duplicate entries in apt sources lists, and UUIDs being specified instead of PartUUIDs for FAT partitions in the fstab file.
Improving systemd Offline Updates
Progress callbacks were added to the offline update script, so that the Plymouth splash screen can be updated with the current progress, as progress is made. Much error handling has also been added to that script, to handle certain scenarios where failures may occur, and how the script may be able to automatically recover from those failures. Testing uncovered a lot of possible corner cases. Testing will continue from here on out.