Home Home
Sign up | Login

Highlights of YaST development sprint 21

June 23rd, 2016 by

Installation Video Mode

If you need to make screenshots of the installation it is useful to influence their size. You could press F3 in the boot menu and choose from a menu, but that is not well suited for scripts such as openQA.

The installer now obeys an option from the boot command line: xvideo.


(Available in yast2-installation-3.1.195 + yast2-x11-3.1.5. bsc#974821)

How to Install with a Self-Signed Certificate

You can now install from a repository served with HTTPS that has a self-signed certificate. Use a ssl_certs=0 boot option.

(Available in yast2-packager-3.1.104. bsc#982727)

Installation: Local SMT Servers are Pre-filled

Last sprint (S#20) we improved the registration UI. Now we’ve made one more improvement: pre-filling the Register System via local SMT Server field.

Before, the widget was a single text field and a little helpful smt.example.com was always shown (no matter what your actual domain was). local-smt-server-1-before

Now, if your local SMT servers are advertised via SLP they will be offered as choices. (Here acme.com stands for your domain) local-smt-server-2-after

(Available in yast2-registration-3.1.176. bsc#981633.)

New Storage: ISO

We have started building an installation ISO image with the new storage library. The first build contains all the pieces but they don’t work together yet.

New Storage: Boot Scenarios

We have documented the supported scenarios regarding booting in the new storage layer.

(Tooling note: We made this with a Markdown formatter for RSpec invoked like this.)

Network Settings are Less Eager to Restart

If you opened Network Settings to review something, made no changes, and closed the dialog with OK, the network would be restarted. That may be undesirable if you have an Important Application running. We originally thought that everyone would close the dialog with Cancel, but we were proven wrong.

Now the module properly checks whether you have made changes to the settings, and omits the restart if appropriate.

(Available in yast2-network-3.1.155. FATE#318787)

Network in AutoYaST

Due to a problem in the AutoYaST version shipped with SLE 12 SP1 and openSUSE Leap 42.1, the network configuration used during the first stage was always copied to the installed system regardless the value of keep_install_network.

Upcoming SLE 12 SP2 and Leap 42.2 behaves as expected and keep_install_network will be set to true by default.

(Available in yast2-network-3.1.157 + autoyast2-3.1.133. Fixes bsc#984146.)

Highlights of YaST development sprint 20

June 7th, 2016 by

The latest Scrum sprint of the YaST team was shorter than the average three weeks and also a little bit “under-powered” with more people on vacation or sick leave than usual. The bright side of shorter sprints is that you don’t have to wait three full weeks to get an update on the status. Here you have it!

Debugger in the installer

Until now debugging the YaST installation was usually done by checking the logs. If you needed more details you would add more log calls. This is inconvenient and takes too much time but, as every Ruby developer know, there is a better way.

Being a fully interpreted and highly introspective language, Ruby offers the possibility of simply intercept the execution of the program and open a interpreter in which is not only possible to inspect the status of the execution, but to take full control of it.

From now on, you can access those unbeatable debugging capabilities during the installation. All you have to do is boot the installer with Y2DEBUGGER=1.

Debugger during installation

Moreover the same mechanism is also available when running YaST in a installed system. Just make sure the rubygem-byebug package is installed and start the YaST module like this:

Y2DEBUGGER=1 yast2 <client>

For more details see the brand new documentation. You can also see several examples and screenshots of the debugger running in text mode, through the network and in other scenarios in the description of the corresponding pull request.

Interface improvements for SSH host keys importing

Most software enthusiasts and developers, specially free software lovers, will know the mantra “release early, release often“. The earlier you allow your users and contributors to put their eyes and hands on your software, the better feedback you will get in return. And that proved to be true one more time with YaST and the awesome openSUSE community.

In the previous post we introduced a new functionality being added to YaST2 – more explicit and interactive importing of SSH host keys. Some users quickly spotted some usability problems, right in time for the fixes to be planned for this sprint.

In the description of this pull request you can see several screenshots of the new interface in several situations, with the new main dialog looking like this.

New dialog for SSH keys importing

Iterative development rocks when you have involved users. Keep the constructive criticism!

AutoYaST support for SSH host keys importing

The user interface was not the only aspect of SSH host keys importing that got improved. For every feature we add to the interactive installer, we always take care of making it accessible from AutoYaST as well. Thus, an AutoYaST profile file can now contain a section like this to control the behavior of the new functionality.

  <import config:type="boolean">true</import>
  <copy_config config:type="boolean">true</copy_config>

Firewalld support in YaST2-Firewall

Another success story about collaboration in the YaST world. In the report about sprint 18 we mentioned we had received some contributions in order to add Firewalld support to YaST2-Firewall and that we were collaborating with the authors of those patches to get the whole thing merged in Tumbleweed. After a couple of sprints allocating some time to keep that ball rolling, we can happily announce that YaST2-Firewall in Tumbleweed already supports the “classic” SUSEFirewall2 backend and the brand new Firewalld one!

Support for vncmanager 3

SUSE’s VNC guru Michal Srb has been working lately in improving the ability to share and reconnect to VNC sessions. Until now, YaST always created a new separate VNC session for every client and closed the session when the client disconnected. There was no simple way to share the session with additional clients or to keep it running after disconnecting.

Now, thanks to Michal, the remote module can be set up in three different VNC modes: disabled, xinetd and vncmanager. Check the definition of each mode in the description of the pull request.

New registration UI

Six sprints ago, the “Local User” screen got some love and the UI was greatly improved. During this sprint, and according to bug #974626, we have improved the registration UI to make it consistent with the “Local User” screen.

The old interface, displayed below, was pretty confusing. Although it was not obvious at first sight, it offered three options:

  1. Register the system using scc.suse.com by introducing an e-mail and a registration code.
  2. Register the system using a local SMT server (no e-mail or registration code are used).
  3. Skip the registration step.

Old registration UI

Options 1 and 2 are mutually exclusive but, if you look at the interface, that fact is not clear. Moreover, we wanted this dialog to be consistent with the new “Local User” one.

The new dialog looks like this, with the three mutually exclusive options being directly presented to the user.

New Registration UI

As always, redesigning a UI in YaST implies making sure it works nicely in the NCurses interface with screens with a resolution of 80 columns and 25 lines of text. Doesn’t it look nice (provided the reader has a geeky aesthetic sense)?

Text-based Registration UI

Progress in the new storage layer

As usual, progress goes steady in the rewrite of the storage layer. In this sprint we invested some time into the partitioning proposal, which is now able to propose a good layout in some very complex scenarios with highly fragmented disks with limited partition schemas.

In addition, preliminary support for LVM was added although is still far from being complete and full-featured.

Will be back… very soon

We always finish our reports saying something like “this was just a sample of all the work done, stay tuned for another report in three weeks”. But the weeks ahead will be a little bit unusual. This week a SUSE internal workshop is taking place. That means that many YaST developers are focusing on stuff different from their daily duty. In addition, openSUSE Conference’16 and Hackweek 14 are both round the corner. As a result of all those “distractions”, next sprint will be shorter than usual (just one week) and will not start immediately. Expect next report at some point close to the start of openSUSE Conference. By the way… see you there!

Highlights of YaST development sprint 19

May 18th, 2016 by

Here we are after another Scrum sprint with our usual report about the activity in YaST development.

Trusted boot

YaST bootloader module got a new option, Trusted Boot (FATE#316553). It installs TrustedGRUB2 instead of the regular GRUB2. Trusted Boot means measuring the integrity of the boot process, with the help from the hardware (a TPM, Trusted Platform Module, chip).

It enables some interesting things which we unfortunately haven’t provided out of the box. We give you a bootloader which measures the boot integrity and places the results in Platform Configuration Registers (PCRs).

First you need to make sure Trusted Boot is enabled in the BIOS setup (the setting is named Security / Security Chip on Thinkpads, for example). Then you can enable the new YaST Bootloader option that will install TrustedGRUB2.

Trusted boot in YaST Bootloader

In the description of this pull request you can find a more detailed explanation including some commands and hexadecimal dumps to check the result. Geek pr0n!

SSH keys importing… and a glance at a YaST Developer’s life

When looking at any software project, it’s common to find some feature or piece of code that is there due to the so-called “historical reasons”. YaST2 code-base has been around since 1999, adapting to changes and new requirements in a (almost literally) daily basis since then. That leads to a new level of heritage – the “prehistoric reasons”. Working in the YaST Team implies coding, debugging, testing… and archaeological research.

We got a bug report about the installer “stealing” some SSH host keys (but not all of them) from previously installed systems. It was actually the effect of a little-known YaST feature that can look surprising (not to say weird) at first sight. Ten years ago, somebody decided that when installing SUSE in a networked environment, where people use SSH to log in, it was better to import SSH keys from a previously installed Linux than to get that “ssh host key changed” for everybody who tries to connect. The rational was that forcing everybody to change the ~/.ssh/known_hosts file often could become a security breach, since people could get used to ignore the security warnings. Welcome to the world of historical reasons. 🙂 Moreover, it was decided that the operation should be performed without showing any information to the users, in order to not confuse them.

More or less at the same time (we are still talking about 2006), it was decided to introduce importing of users from an existing system, this time with user interaction. The YaST developers decided that it would be fine to share some mechanisms in the implementation of both features. Another step into the historical reasons void.

Fast forward to the present. After several fate entries, bug reports and redesigns over the years, we decided to make the importing of SSH host keys more visible and usable, to make both functionalities (SSH import and users import) more independent and more clean and to take the first step to clean up the insanity introduced through the years (see fate#320873 for details).

The installer does not longer silently just import the SSH host keys from the most recent Linux installation on the disk (remember, you might have several distributions installed), it has now become a part of the installation proposal dialog:

SSH host keys proposal

And from there you can change it:

SSH host keys selection

Notice that one of the options is “none”, so copying of previous keys is not longer enforced. In addition, now is also possible to import the rest of the SSH configuration in addition to the keys.

Disabling local repositories

When installing from a local media, like a CD/DVD or an USB stick, those sources were still enabled after the installation. It potentially could cause problems during software installation, upgrade, migration, etc. because an old or obsolete installation source is still there. On the other hand, if the source is physically removed (for instance, ejecting the CD/DVD), zypper will complain about that source not being available.

Fortunately, this behavior will change in future SUSE/openSUSE versions. Now, at the end of the installation, YaST will check every local source disabling those whose products are available also through a remote repository (so they’re not needed at all).

Smart bonding with NPAR and SR-IOV interfaces

Support for bonding interfaces with NPar or SR-IOV capabilities has also been improved during this sprint. Too many weird words in one sentence? Don’t worry, we actually love to explain things.

Bonding is a way to combine multiple network connections to increase the throughput and bandwidth and to provide redundancy. On the other hand, NPAR and SR-IOV are technologies that provide the capability to create multiple virtual devices from the same physical or ethernet port.

Until this sprint, YaST offered no way to know whether two interfaces with these capabilities were sharing the same physical port. As a result, users could bond them without realizing that they were not getting the desired effect in terms of redundancy.

Information about the physical port ID has been added to all the relevant dialogs for all devices supporting it, like it’s shown in the following screenshots.

Physical ports

More physical ports

Additionally, the user will be alerted when trying to bond devices sharing the same physical port.

Bonding warning

Last but not least, following the Boy Scout Rule (also known as opportunistic refactoring), we took the opportunity to fix some small quirks in YaST Network, like the counter-intuitive sorting of devices in some lists.

Paying our debts: much better cleanup rules in Snapper

Somebody said once “a promise made is a debt unpaid“. In the previous post we promised you all an article on Snapper.io detailing the new space-aware cleanup introduced in Snapper. Here you are!

That’s all folks

Enough for a blog post. That’s of course not all we did during the last sprint (to the contrary, it’s just around 20% of the finished work according to the story points count) but, you know, we need to go back to hacking!

Highlights of YaST development sprint 18

May 2nd, 2016 by

The wait is over, the report of the latest Scrum sprint of the YaST Team is here! In the previous post we promised that after this sprint we would have much more to show… and now we do. This sprint was quite productive, so let’s go straight to the most interesting bits.

More improvements in the self-update

The YaST self-update feature mentioned in the two previous blog posts (sprint 16 and sprint 17) has also received a couple of improvements.

At this gist (with screenshots) you can see some of the fixes done when going back and forward in the work-flow after an installer self-update.

But even more important are the improvements done in AutoYaST to properly handle the new feature. If you want to use your own self-update repository you have to specify it on the boot command line. This is easy in a single installation, but if you want to install many machines using AutoYaST then writing the possibly long URL at each installation again sounds annoying.

In this sprint we improved handling of the custom update URL so that it can be read from the AutoYaST XML profile. Now you need to write the custom URL only once into the profile and it will be used automatically in every AutoYaST installation.

There is not much to show in the UI, the log proves that the self update was really loaded.

AutoYaST self-update

You can find more details about specifying the URL in the profile and evaluating the self-update repository URL at the documentation.

Goodbye perl-Bootloader

For quite some time, we have had the plan to stop using Perl-Bootloader as library for yast2-Bootloader and finally we managed to make it happen. There were many reasons for this change.

From the user point of view, the most visible reasons were speed and size. Getting rid of Perl-Bootloader means that we not longer perform hardware probing twice (one for Perl-Bootloader and another one for grub2-config), making kernel updates faster. In addition, we are not only simplifying and reducing the size of yast2-bootloader itself. Dropping the Perl libraries and other associated dependencies, makes possible to have a smaller minimal system, something quite relevant in various environments and scenarios.

From the developer point of view, the main reason was to unify the used programming languages and also reuse existing solution for file reading and parsing. Now yast2-bootloader uses an Augeas file parser and serializer, which does not only allow us to have less code to maintain, but also offers smarter editing and better handling of the comments in the configuration files.

As nice side effects, this change also leaded to the removal of a lot of work-arounds, the simplification of the installation work-flow for bootloader and a very visible improvement in the source code quality. In addition, we improved the test coverage of the whole module to make sure we didn’t break things too much. But all those would be bold statements if we wouldn’t have some geeky numbers to prove then, so here they are.

Of course, after such a big rewrite is not unlikely that some new bugs will pop up, but we really believe the improvements are worth the price.

Storage reimplementation: calculation of partition location

For the storage-ng project we made a big step towards a modern system. We do not use geometries and cylinders for disks any longer. Instead we only use sectors.

The advantage for the user is much better control over the size of new partitions. Since so far the size had to be a multiple of the cylinder size, often 7.84 MiB, it was not possible to create very small partitions, e.g. for the BIOS boot partition. Also the size of partitions was usually not the exact number entered in YaST, e.g. 509.88 MiB instead of 512 MiB.

Now the size of partitions is as accurate as possible with the hardware, so usually a multiple of 512 B or 4 KiB.

Like in the past we also takes care of optimal partition alignment to avoid performance loss due to read-modify-write cycles.

Snapper: much better cleanup rules

Snapper is a great tool, but the current default configuration usually causes it to be a little bit too greedy with disk space. During this sprint a new set of cleanup rules was implemented, allowing a much more reasonable usage of the disk.

The feature is already developed, submitted to Factory and even integrated into the next version of SUSE Enterprise that is right now being cooked. But, as you all know, the testing work-flow of openSUSE Tumbleweed (staging projects, openQA and so on) can sometimes cause some delay until the new feature appears in the distribution. As soon as the new feature reaches Tumbleweed, a blog post explaining the new functionality will be published at snapper.io. Stay tuned!

Improved password protection for bootloader

The password protection widget in YaST2-Bootloader had not been changed since the GRUB1 times, but GRUB2 allows more fine tunning of the password settings. In fact, it contains a whole user management system with multiple users that can have different permissions and different passwords. For YaST we like to keep things simple, so we support only password for “root” user. That was confusing for some people, so we decided to improve the user experience by adjusting some labels… and fixing some typos in the process. 😉

Two pictures are worth a thousand words, so here you can see how the dialog looked before the change

BEFORE: boot password dialog

and below the new appearance, which adds more explanation to the password specification. Of course, the help text (not displayed in the screenshots) was also improved to reflect the changes.

AFTER: boot password dialog

Handling of default product patterns

The YaST installer implements several possibilities how the default patterns for the installed product should be specified. One of them is using Recommends RPM dependencies for the product package. (The other possibilities include control.xml file or the content file on the medium.)

The installer by default installs the recommended packages so the default patterns are automatically installed in the initial installation.

However, this approach makes troubles during system upgrade. If you remove some packages or patterns which are installed by default and then you do a system upgrade the installer will (silently) add the removed packages or patterns back as the Recommends dependencies will pull them in again.

The solution is to provide another mechanism for selecting the default patterns. The new implementation allows using a specific Provides RPM package tag which specifies the default pattern name for the product.

The new tag is defaultpattern(pattern) where “pattern” is the name of the default pattern. YaST looks for these specific tags and collects the pattern names for all installed or updated products. This step is skipped during package based system upgrade so this should avoid adding unnecessary packages in system upgrade.

Obviously it depends on the products themselves to switch from the RPM dependencies to this new style. So far it is supported only by the SLES12 SP2 High Availability addon.

See more details at https://github.com/yast/yast-packager/wiki/Selecting-the-default-product-patterns.

Storage reimplementation: another step closer to the perfect booting layout

A couple of reports ago we made public our intention to squeeze some booting experts brains in order to create Ruby classes capable of always proposing a sensible partitioning schema. The delicious result is finally at the repository, accompanied with a rather complete document explaining the logic behind the code.

If reading Ruby code is not your thing but you are geeky enough, you can also review the output generated by the RSpec unit tests, which shows how the new partitioning proposal will behave in all scenarios from the booting requirements point of view.

Storage reimplementation: other improvements in the new proposal

Apart from the already mentioned improvements in setting the boot-related partitions, the brand new partitioning proposal gained the ability of shrinking Windows partitions when needed (in a sensible and gentle way) and reusing partitions that can be shared with other installed systems, like swap of PReP. Even when sharing a swap partition is not possible and the proposal needs to delete an existing swap partitions to create a different one, it will take care of reusing the old label and UUID, so other systems in the same computer can still find a suitable swap for them even after changing the partitioning layout. Because we all can be better citizens…

In addition, we took the first steps to develop a smarter way of proposing a solid partitioning schema when the free space is split over several different disks or disk chunks. Is still a work in progress, but you can trust that in the future (open)SUSE will do a nice job when looking for a home for itself in your sparse hard disk space.

Prevent wrong usage of LDL DASD disks in S/390 mainframes

The management of storage devices in a Linux system running in a S/390 mainframe is a tricky topic full of corner cases. Depending on the type of disk, its format and other factors, some apparently simple operations (like creating partitions) are not possible. If you are interested in the subject and want to learn a lot of weird acronyms, we would recommend this article.

We realized that the expert partitioner allowed the user to specify some operations that were actually not supported, which resulted in the installation being aborted at a subsequent step. To avoid that situation, we improved the expert partitioner to detect those unsupported S/390 configurations and alert the user, like it’s shown in the screenshot below.

LDL DADS popup

AutoYaST: moving network device renaming to first stage of installation

We refactored the network module to unify the handling of device naming. Now AutoYaST assigns the naming udev rules in the 1st stage of the installation already. (yast2-network-3.1.147, autoyast2-3.1.121)

New toys for the team

We got a new server to run integration tests via openQA and AutoYaST.

The AutoYaST tests now used to take 8 hours but now finish in 1.5 hours.

Collaboration with other (open)SUSE Teams

Even though we call ourselves “the YaST team” we are happy to share the project with other teams in the company and people in the community. During this sprint, we had a chance to review code for two significant features.

The authentication client module, dealing with LDAP, Kerberos, Active Directory, NSS, PAM, and SSSD, got a big upgrade (yast2-auth-client-3.3.7).

Since a couple of months, Tumbleweed has had a package for firewalld (see FATE#318356 ). Work is underway to make YaST aware of it but it has not been merged yet. If you are interested you will have to find it in the git repo.

In closing

Definitely, this was a very productive sprint and, as usual, this report is just a sample of the total work delivered by the team. To be precise and to please number lovers, the features and fixes covered by this report represent 85 Scrum story points out of a total of 124 delivered ones. Hopefully enough to keep you entertained until the next report in about three weeks. See you then!

Highlights of development sprint 17

April 6th, 2016 by

This is the fifth report since we started blogging about our development sprints and we have to admit that is the less impressive one so far. We probably underestimated the impact of the combination of Easters holidays and vacations of some team members.

But although we were less productive than expected, we still have a couple of cool things to show to our beloved users and fellow developers.

Handling of file conflicts in packages

Until now the package installation in YaST ignored possible file conflicts in the installed packages. In contrast zypper already supports that check for some time.

File conflicts happen when two packages attempt to install files with the same name but different contents. If such conflicting packages are installed the conflicting files will be replaced losing the previous content. The final file content will also depend on the installation order so some issues might look “random”. The package which file has been overwritten is actually broken.

YaST now displays a confirmation dialog which asks whether to continue with installation despite the conflicts or abort. Previously YaST silently continued with the package installation which could cause serious troubles later.

File conflicts

File conflicts should normally not happen, at least when you use the original distribution repositories. The OBS build checks for some file conflicts during package build and if there really is a file conflict that it should be marked on the RPM level (so you should not be allowed to select the conflicting packages for installation at first place).

It is up to the user to decide whether it is OK to ignore the conflict or not. If the conflict is for example in a documentation file then ignoring the conflict is usually no problem, but if the conflict is in a binary file or in a system library then it is potentially risky. If you are not sure “Abort” is the safe choice here.

In the description of this pull request you can see several additional animations showcasing the new feature in a variety of interfaces (Qt, NCurses, command line) and scenarios (software manager, inline installation of extra packages).

Improvements in the installer self-update

During this sprint, the self-update feature has received several improvements and changes. The most important one is that now it uses libzypp to fetch the updates, delegating signatures checking and that kind of stuff. Obviously, it also means that installer updates will be distributed using regular RPM repositories (instead of Driver Update Disks).

Self-Update installer - Unknown GPG

On the other hand, user’s driver updates (specified through dud option) will take precedence over installer updates. They will be applied by Linuxrc anyway, but they’ll remain on top of installer updates.

Fun with Ruby and proxies

This is not exactly a new feature or fix in YaST, but something we learned and we decided could be worth sharing in order to save headaches to other people.

We got a report about YaST ignoring the no_proxy setting in /etc/sysconfig/proxy. After some investigation, it turned out the problem was not in YaST but in the underlying tools, that are also implemented in Ruby. Looks like Ruby have an unexpected (by us, at least) behavior dealing with proxy settings. If you are interested in the details, don’t miss the information we collected in this page in the YaST2-Registration wiki, which includes some background and a set of recommendations to follow when setting no_proxy.

Unification of network setup during installation

As a result of the analysis about how the network settings affect different installation modes and steps, we unified the position and shortcuts of the “Network Setup” button. That affected three installation steps.

A button was added to “Add On Product” to avoid going back and forth just to setup some special configuration for some of our network interfaces.

Add On Product

In the “Disk Activation” step, the button was moved to the top-right corner to be consistent with other steps.

Disk Activation

And to round off consistency we also adjusted the keyboard shortcut in the registration screen.


New storage library keeps evolving

This time we don’t have any big headline about the development of the new storage layer. We keep collaborating with experts in our attempt to ensure solid solutions for all situations. In addition to booting experts, the input from Parted guru Petr Uzel was really valuable during this sprint. We took some important decisions about the integration of the new libstorage and libparted and we made progress in implementing a partitioning proposal that ensures a bootable system in all architectures and configurations, backed with highly readable tests and specs.

If time and bug reports permit, we’ll have much more to show after the next sprint… but that would be in three weeks from now. Meanwhile, have a lot of fun!

AMD Catalyst 15.12 for openSUSE – new makerpm-amd-script is available

March 17th, 2016 by

AMD has released the new AMD Catalyst 15.12 (Radeon Crimson Edition). My script replaces the existing packaging script with an updated packaging script. It supports up to Kernel 4.5. (Official support up to Kernel 3.19)

Important note: The driver does not work on openSUSE Tumbleweed. Unfortunately, the version of X-server is too new for the driver.

SHA1 is obsolete by now. The script used SHA256 for integrity of the downloaded files.

New Feature from packaging script:

  • systemd support

Resolved Issues:

  • [SWDEV-82980] Ubuntu 15.10 fails when building the .deb packages

Link: AMD Catalyst 15.12 Release Notes


Installation guide (English):

Bruno Friedmann will build the new RPM packages in the fglrx repository. Stay tune!

If you find any issue with the driver. Don’t hesitate to contact me. I am in contact with AMD and can forward your issue to the right place. Feedback are welcome.

A report of your system is very helpful beside your feedback. You can generate it with the script:
su -c 'sh makerpm-amd-15.12.sh -ur'

Have a lot of fun!

openSUSE member / Official AMD Packaging Script Maintainer for openSUSE
German Blog: openSUSE – proprietĂ€ren Grafik-Treiber AMD Catalyst 15.12 als RPM installieren

Highlights of development sprint 16

March 15th, 2016 by

After three weeks of work, another development sprint is over. So time for another report for our fellow geckos. As usual, quite some time was invested in boring bug fixes and small non-obvious improvements, but we also have some interesting stuff to talk about.

Improved UI for the encrypted partitioning proposal

We wanted to talk about this feature not only because it has a visible impact in the user interface, but also because it’s a great example of collaboration among the different roles present in a Scrum Team. Formerly our Scrum development team was only formed by the developers of the YaST Team at SUSE. For this sprint (and future ones) the Scrum Team has been powered up with the addition of Ken Wimer as UI/UX expert and Jozef Pupava, one of the openQA.opensuse.org and openQA.suse.de operators.

We got a feature request to make encryption more visible in this dialog.

Old partitioning proposal dialog

Being software developers used to tools like Vim and Git, we have to admit that the YaST team found the dialog perfectly usable and was having hard times thinking on a better alternative. Fortunately, we now have a UI/UX expert able to bring better alternatives like this one we finally implemented.

New dialog for partitioning proposal

This kind of visual changes in the installer used to cause delays in openQA, because adapting the tests while keeping the openQA machinery running is not always trivial. The great news is that it didn’t happen this time because our particular openQA superhero was already watching over our steps all along the process.

So welcome into our Scrum process, Ken and Jozef!

System roles

A new feature was added to the installer making it possible to quickly adjust several settings for the installation with one shot. You can see a detailed description of the feature, including several screenshots and configurations options in this wiki page at the Github repository of yast2-installation. And yes, for the impatient we also have a glorious screenshot!

System Role dialog

Storage reimplementation: resizing partitions

We have already explained in previous reports that we are performing an integral rewrite of the code managing partitioning and other storage tasks. During this sprint, the brand new library gained the ability to resize all kind of partitions (Linux, Windows, swap, etc.). It’s nothing that is going to hit the users in the short term but at least we have a couple of screenshots to see the premiere working (yes, we know that screenshots of terminals are not the most fancy stuff).



Installer self-update

Starting on version 3.1.175, YaST is able to update itself during system installation. This feature will help to solve problems in the installer even after the media has been released. That’s a huge step towards improving YaST reliability.

The workflow is pretty simple: during system analysis YaST will search automatically for an update. If such update is found, YaST will download, verify (using GPG) and apply it. Finally, the installation will be resumed using the new version. Nice!

In the future, self update will be enabled by default. However, if for some reason you don’t want such a nice feature, you’re free to disable it. What is more: you can also craft your own update and use it instead the official one passing a custom URL to the installer.

If you’re curious, you can check the technical details.

Storage reimplementation: the search for the perfect bootloader

One of the goals of rewriting the storage layer was to make possible to cope with all the over-complicated requirements involved in the proposal of a good bootloader configuration. This time we don’t want the different scenarios to simply pop-up over time in a bug-report-oriented basis and start aggregating more and more branches to the existing code in order to support every one of those “new” scenarios.

Changes will come, for sure, but we need a solid ground based in experts knowledge to start building a flexible future-proof code to handle partitioning regarding bootloader. Thus, we started a round of contacts with several experts in all the hardware architectures supported by YaST in order to capture all the knowledge from their brains into a set of Ruby classes. It’s still a work in progress since squeezing people’s brains is not always easy, but we already have some preliminary document.

Consolidating continuous integration tools

Continuous integration is a key aspect of software development, specially with methodologies like Scrum. Currently we use both Travis and Jenkins for it. Travis builds the pushed commits and pull requests at GitHub, while Jenkins takes care of the integration with the Open Build Service.

We are investing quite some effort trying to use Jenkins for everything. If you want to know more about the reasons or how the progress is going, check the detailed documentation.

And much more!

As usual, this is just a small sample of the total work delivered by the team during the latest sprint (for Scrum and statistic’s lovers, it represents 34 story points out of a total of 87 delivered ones). Hopefully enough to keep you informed… and if it’s not, you know where you can reach us for more information!

TOSprint or not to sprint?

February 27th, 2016 by

TOSprint Paris 2016

Report of a week of sprint

TOSprint in Paris has just ended (wiki page).

What a week!

First of all I want to warmfully thank the sponsors, especially Olivier Courtin from Oslandia for the organization, and Mozilla France for hosting us.

What is TOSprint?

Once a year a bunch of hackers from projects under OsGeo umbrella, meet in a face to face sprint.
This year it happenned in Paris with great number of participants (52).

There was globally five big groups, and if each community was running its own schedule,
there was a lot of cross echanges too.

TOSprint Mozilla
Mateusz Ɓoskot

Personal objectives

My main objective, except being enough luckly to be a sponsor, was to go there and be in direct contact with upstream.

This can help a lot to improve packages, and create new ones.

Moreover, as one of my openSUSE’s Application:Geo peer maintainer, Angelos Kalkas was also participating, we decided to make somes changes, and improve the situation of the repository.

Read the rest of this entry »

Highlights of development sprint 15

February 25th, 2016 by

We know you have missed the usual summary from the YaST trenches. But don’t panic, here you got it! As usual, we will only cover some highlights, saving you from the gory details of the not so exciting regular bugfixing.

Package notifications

libzypp has a nice feature that enables packages to display notifications when they’re installed/upgraded. Zypper takes advantages of this feature and shows that information when a package is installed/upgraded. For example, if you install mariadb package, Zypper will inform you about setting up a database root password and so on.

If you installed any of those packages with YaST, you missed that piece of information
 until now! Starting on yast2 3.1.175 YaST will show packages notifications.



The only exception is when doing a regular installation (or autoinstallation), as we want to show as few dialogs as possible.

Registration Codes from a USB Stick

During the installation of a SUSE Linux Enterprise product, you are asked for a registration code. Previously you had to remember it and type it by hand. Now the code can be read from USB storage.


Insert a USB stick at installation boot time or at the latest before you proceed from the first installation screen (Language, Keyboard and License Agreement). That stick should contain the registration codes either at /regcodes.txt or at /regcodes.xml. In the registration dialogs, the input fields will be prefilled.

The syntax of the files is as follows. In the file identify the product with the name quoted by zypper search --type product or SUSEConnect --list-extensions (without the /version/architecture part).


SLES    cc36aae1
SLED    309105d4

sle-we  5eedd26a
sle-live-patching 8c541494

regcodes.xml: (xml wins if both xml and txt are present)

<?xml version="1.0"?>
<profile xmlns="http://www.suse.com/1.0/yast2ns" xmlns:config="http://www.suse.com/1.0/configns">
    <!-- See https://www.suse.com/documentation/sles-12/singlehtml/book_autoyast/book_autoyast.html#CreateProfile.Register.Extension -->
    <addons config:type="list">
        <!-- Name of add-on as listed by "zypper search --type product" -->
        <!-- SLES is not an add-on but listing it here allows for combining
             several base product registration codes in a single file -->

Lot of Btrfs-related improvements in the expert partitioner

We also invested quite some time improving the support for Btrfs in the expert partitioner. Implementing one requested feature and closing five bugs.

The following animation shows the feature #320296 (user friendly handling of subvolumes) in action, together with the fix to 965279 (Btrfs settings always overridden with default values).


But we have even more screenshots and animations for the improvements in the expert partitioner. In the description of this pull request, you have screenshots displaying the new dialog that was implemented to fix bug#928641. And in this other pull request, you can see in action the fixes for bug#944252 (snapshots were offered for partitions other than root) and for bug#954691 (fstab options being forgotten for Btrfs partitions).

Improving testability of the new storage code

In recent posts, we reported how we are about to refactor the storage subsystem of YaST. The improved partition proposal for installation presented in the previous summary performs a lot of operations – like analyzing what disks are there and what is on each one of them, checking if there already is enough free space and making a best guess on what partitions may be candidates to be removed to make space for a new Linux installation.

If there are many disks with many partitions, this can get complicated really quickly. So we need a reliable way to test it. Thus, we created a testing framework to build fake storage hardware (disks) with fake partitions and file systems. Although it’s fake hardware (we can’t create hard disks out of thin air… yet), it enables us to do unit tests without setting up virtual machines. With those tests we can cover a lot more scenarios that would otherwise be really difficult to test, with one or many disks, with many partitions of different kinds, with a previously existing RAID array or whatever.

One nice thing about the new libstorage is that it operates on “device graphs” that can be transformed into the GraphViz format for easy visualization. Here you have a nice diagram generated by libstorage based on some fake hardware created from this YAML specification.


Better handling of wrong registration code for extensions

We also spent some time improving the usability of the section for registration of extensions and modules. Now if the user selects several modules and the registration of some of them fails, the user will be kindly redirected back to the same dialog but only with inputs for the unregistered ones. From there, they can go back to unselect the failing extensions or retry with different (or even with the same) codes.

Say goodbye to the “receive system mail” checkbox

As the last step of the improvements done to the user creation dialog (see the previous post for more details). We removed the long-ago meaningless checkbox titled “Receive System Mail”. That leaded to the removal of quite some code… and removing code is usually a good thing. 🙂

Many other things

As usual, this is just a short summary with some highlights. Many other stuff was implemented and several other bugs were fixed but, you know, we cannot blog about everything if we want to invest some time in debugging and coding. 🙂

See you in the highlights for next sprint, in around three weeks.

PS.- If you want to be part of the fun, take a look to the YaST-related summer projects we have on the openSUSE mentoring page.

Sugar on openSUSE

February 17th, 2016 by

Built openSUSE Leap based Sugar test images on SUSE Studio, get it from here.

If you wish to get involved with the project maintaining packages, fixing/reporting bugs, follow the links on the X11:Sugar build service project page.