Home Home
Sign up | Login

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.

Registration

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

Downloads:

Installation guide (English):
http://en.opensuse.org/SDB:AMD_fglrx#Building_the_rpm_yourself

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!

Sebastian
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).

shrink-vfat

grow-ntfs


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.

installation-messages-qt

installation-messages-ncurses

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.

regcode-from-usb
regcode-from-usb-extensions

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).

regcodes.txt:

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">
  <suse_register>
    <!-- See https://www.suse.com/documentation/sles-12/singlehtml/book_autoyast/book_autoyast.html#CreateProfile.Register.Extension -->
    <addons config:type="list">
      <addon>
        <!-- Name of add-on as listed by "zypper search --type product" -->
        <name>sle-we</name>
        <reg_code>5eedd26a</reg_code>
      </addon>
      <addon>
        <name>sle-live-patching</name>
        <reg_code>8c541494</reg_code>
      </addon>
      <addon>
        <!-- SLES is not an add-on but listing it here allows for combining
             several base product registration codes in a single file -->
        <name>SLES</name>
        <reg_code>cc36aae1</reg_code>
      </addon>
      <addon>
        <name>SLED</name>
        <reg_code>309105d4</reg_code>
      </addon>
    </addons>
  </suse_register>
</profile>

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).

subvolumes-opt

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.

fake-devicegraphs

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.

Highlights of development sprint 14

February 3rd, 2016 by

Another three weeks period and another report from the YaST Team (if you don’t know what we are talking about, see highlights of sprint 13 and the presentation post). This was actually a very productive sprint although, as usual, not all changes have such an obvious impact on final users, at least in the short term.

Redesign and refactoring of the user creation dialog

One of the most visible changes, at least during the installation process, is the revamped dialog for creating local users. There is a full screenshots-packed description of the original problems (at usability and code levels) and the implemented solution in the description of this pull request at Github.com.

Spoilers: the new dialog looks like the screenshot below and the openSUSE community now needs to decide the default behavior we want for Tumbleweed regarding password encryption methods. To take part in that discussion, read the mentioned description and reply to this thread in the openSUSE Factory mailing list.

b12a8f90-c51b-11e5-9ceb-659b6c77bac4

Beyond the obvious changes for the final user, the implementation of the new dialogs resulted in a much cleaner and more tested code base, including a new reusable class to greatly streamline the development of new installation dialogs in the future.

One step further in the new libstorage: installation proposal

In the highlights of the previous sprint, we already explained the YaST team is putting a lot of effort in rewriting the layer that access to disks, partitions, volumes and all that. One important milestone in such rewrite is the ability to examine a hard disk with a complex partitioning schema (including MS Windows partitions, a Linux installation and so on) and propose the operations that need to be performed in order to install (open)SUSE. It’s a more complex topic that it could look at the first glance.

During this sprint we created a command line tool that can perform that task. Is still not part of the installation process and will take quite some time until it gets there, but it’s already a nice showcase of the capabilities of the new library.

new-storage-proposal-2016-01-27-1900

Fixed a crash when EULA download fails

If a download error occurred during the installation of any module or extension requiring an EULA, YaST simply exited after displaying a pop-up error, as you can see here.

0c444926-bb75-11e5-8e6e-029d018c14d3

Now the workflow goes back to the extension selection, to retry or to deselect the problematic extension. Just like this.

46fb22a6-bb75-11e5-9830-aff1d516e77e

Continuous integration for Snapper and (the current) libstorage

Snapper and libstorage now build the Git “master” branch continuously on ci.opensuse.org (S, L), and commit a passing build to the OBS development project (S, L), and if the version number has changed, submit the package to Factory (S, L).

The same set-up works on ci.suse.de (S, L), committing to the SUSE’s internal OBS instance (S, L) and submitting to the future SLE12-SP2 (S, L).

This brings these two packages up to the level of automation that the YaST team uses for the yast2-* packages, and allows releasing simple fixes even by team members who do not work on these packages regularly.

Disk usage stats in installation and software manager: do not list subvolumes

While installing software, YaST provides a visual overview of the free space in the different mount points of the system. With Btrfs and its subvolumes feature, the separation between a physical disk and its mount point is not that clear anymore. That resulted in wrong reports in YaST, like the one displayed in the left bottom corner of this screen.

broken-disk-usage

The actual calculation of free space is performed by libzypp (the Zypper library), YaST only takes care of rendering the result of that calculation in the screen. Thus, we closely collaborated with the Zypper developer, Michael Andres, to teach libzypp how to deal with Btrfs subvolumes. Thanks to his work, with any version of libzypp >= 15.21 (already available in Tumbleweed), you can enjoy an error-free disk usage report.

fixed-disk-usage

To ensure we have no regressions, the YaST team also contributed a new test to openQA. See it in action.

Cleanup dependencies in YaST systemd services

We have received several bug reports about problems executing AutoYaST or YasT2-Firstboot in combination with complex network settings or third party services… and even in some simple scenarios. Many of these problems boil down to a single culprit – the dependencies of the YaST related systemd units.

During this sprint we have simplified the unit files for Tumbleweed and SLE, as you can see in this pull request. It’s a small change but with a huge impact and several implications, so a lot of time was invested into testing during the sprint. The problems seem to be gone, but more AutoYaST and YaST-Firstboot testing would be highly appreciated.

Many other things

As usual, this is only a brief collection of highlights of all the job done during the sprint. Using Scrum terminology, this represents only 27 story points out of a total of 81 story points delivered by the team during this sprint. Using more mundane words, this is just a third part of what we have achieved during the last three weeks.

Hopefully, enough to keep you entertained until the next report in other three weeks!

Running live image from RAM

January 29th, 2016 by

Some time back I wrote a patch to KIWI that allows running openSUSE live entirely from RAM(tmpfs).
Read the rest of this entry »

A brief 360° overview of my first board turn

January 18th, 2016 by

You’ve certainly noticed that I didn’t run for a second turn, after my first 2 years. This doesn’t mean the election time and the actual campaign are boring :-)

If you are an openSUSE Member, we really want to have your vote, so go to Board Election Wiki and make your own opinion.

The ballot should open tomorrow.

board-leaving-tigerfoot

Why not a second turn?

Being a board member (present at almost every conference call, reading the mailing lists and other task) consume free time. It has increased during the last semester too. And we’ve got some new business opportunities here at Ioda-Net SĂ rl in 2015, and those need also my attention for the next year(s). I prefer to be a retired Board member, than not being able to handle my responsabilities.
But I’m not against the idea of a "I’ll be back" in a near future. Moreover with a bit more bandwidth in my free time, I will be able to continue my packaging stuff, and other contributions.

What a journey!

With the new campaign running, I found funny to bring back to light my 2013 platform written 2 years ago. And spent 5 minutes on checking the differences with today. I’m inviting you to discover the small interview between me and myself :-)

1. Which sentences would you say again today?

I’m a "Fucking Green Dreamer" of a world of collaboration, which will one day offer Freedom for everyone.

Clearly still a day by day mantra and leitmotiv. But even if I’m dreaming, I never forget that
Freedom has a price : Freedom will only be what you do for it.

Read the rest of this entry »