Unifying the Console Keyboard Layouts for SLE and openSUSE

The way of managing internationalization in Linux systems has changed through the years, as well as the technologies used to represent the different alphabets and characters used in every language. YaST tries to offer a centralized way of managing the system-wide settings in that regard. An apparently simple action like changing the language in the YaST interface implies many aspects like setting the font and the keyboard map to be used in the text-based consoles, doing the same for the graphical X11 environment and keeping those fonts and keyboard maps in sync, ensuring the compatibility between all the pieces.

For that purpose, YaST maintains a list with all the correspondences between keyboard layouts and its corresponding "keymap" files living under /usr/share/kbd/keymaps. Some time ago the content of that list diverged between openSUSE and SLE-based products. During this sprint we took the opportunity to analyze the situation and try to unify criteria in that regard.

We analyzed the status and origin of all the keymap files used in both families of distributions (you can see a rather comprehensive research starting in comment #18 of bug#1124921) and we came to the conclusions that:

• The openSUSE list needed some minor adjustments.
• Leaving that aside, the keymaps used in openSUSE were in general a better option because they are more modern and aligned with current upstream development.

So we decided to unify all systems to adopt the openSUSE approach. That will have basically no impact for our openSUSE users but may have some implications for users installing the upcoming SLE-15-SP2. In any case, we hope that change will be for the better in most cases. Time will tell.

Exporting User Defined Repositories to AutoYaST Configuration File.

With the call yast clone_system an AutoYaST configuration file will be generated which reflects the state of the running system. Up to now only SUSE Add-Ons have been defined in the AutoYaST configration module. Now also user defined repositories will be exported in an own subsection <add_on_others> of the <add-on> section.

<add-on>
  <add_on_others config:type="list">
    <listentry>
      <alias>yast_head</alias>
      <media_url>https://download.opensuse.org/repositories/YaST:/Head/openSUSE_Leap_15.1/</media_url>
      <name>Yast head</name>
      <priority config:type="integer">99</priority>
      <product_dir>/</product_dir>
    </listentry>
  </add_on_others>
  <add_on_products config:type="list">
    <listentry>
      <media_url>dvd:/?devices=/dev/sr1</media_url>
      <product>sle-module-desktop-applications</product>
      <product_dir>/Module-Desktop-Applications</product_dir>
    </listentry>
    <listentry>
      <media_url>dvd:/?devices=/dev/sr1</media_url>
      <product>sle-module-basesystem</product>
      <product_dir>/Module-Basesystem</product_dir>
    </listentry>
  </add_on_products>
</add-on>

The format of the <add_on_others> section is the same as the <add_on_products> section.

Better Handling of Broken Bootloader Setups during Upgrade

With the current versions of SLE and openSUSE, using the installation media to upgrade a system which contains a badly broken GRUB2 configuration (e.g. contains references to udev links that do not longer exist) can result in an ugly internal error during the process.

The first possible problem could arise in the summary screen. Like shown in this screenshot.

If the error didn’t pop-up or if the user managed to recover from it, it was possible to reach the final phase of the upgrade process. But then the same internal error could still pop up in a different place:

Those errors will be fixed in the upcoming releases of SLE-12-SP5 and SLE-15-SP2 and, of course, in the corresponding openSUSE Leap version and in Tumbleweed. Now if such a broken setup is detected in the summary screen, a proper warning is displayed, including the technical details and a tip on what to do to fix the problem.

The user can ignore the problem or click on "booting" to fix it. In the latter case, the usual pop-up with instructions will appear.

If the final stage of the upgrade process is reached without fixing the error, the wild internal error is now replaced by an informative message that does not interrupt the process.

Hopefully most of our users will never see these improvements. But users with a broken system will likely appreciate the extra guidance.

Old Storage, New Features

If you are an usual reader of this blog, most likely you already know that YaST has a completely re-implemented Storage stack (a.k.a. storage-ng). That new storage code did its debut with the SLE 15 (and openSUSE Leap 15.0) family. And thanks to this revamped code, our beloved users can enjoy today some new great features in YaST like Bcache, partitionable Software RAIDs or multi-device Btrfs file system (just to mention a few examples). But SLE 12 (openSUSE 42) products are still alive and getting improvements with every maintenance update! Of course, the old Storage stack is not an exception, and now on a new installation scenario is supported.

Thanks to a bug report, we realized that Snapper could not be configured in some cases. More specifically, the reporter was trying to install with AutoYaST over a directly formatted Software RAID by using Btrfs for root and enabling snapper. The installation was perfectly performed, but it turned out that snapper was not correctly enabled in the installed system. After having a deeper look into the problem, we discovered that this was not a bug exactly but a completely missing feature. But no problems, YaST got down to work and now it is nicely supported.

With the invaluable work and effort from Petr Gajdos, Takashi Iwai, and all the creative designers, we now have more than 100 open source fonts in the M17N:fonts repository. Most fonts are licensed under the OFL or other open/free licenses. Thanks a lot to all! This repository contains fonts like the previously mentioned Exo typeface, the famous Linux Libertine, or fonts from the Google Webfonts page to name a few. With all these fonts available at your hand, you have many choices to make your text readable and attractive as you like, be it on the Web or in print.

Previous to openSUSE 12.1, all the fonts had a terrible naming convention: some contained a “fonts” prefix, other don’t. Now all fonts follow a naming convention to make it easy to find. So don’t be surprised when your font package has been renamed. If you need further information, check out my original idea from FATE#313035. Packagers will probably find the article about Packaging Fonts in the openSUSE Wiki helpful.

The new M17N:fonts repository collects all fonts now and in the future. New fonts will appear and developed there. To use it, add the repository to your list:

zypper ar http://download.opensuse.org/repositories/M17N:/fonts/openSUSE_12.1/M17N:fonts.repo

Currently, the supported distributions are openSUSE 11.4, 12.1, Evergreen 11.1, 11.2, Factory, Tumbleweed, as well as SLE11 SP1 and SP2.

Have fun and be creative with the new fonts!

now following an List from my last updated/worked Packages:

1. boinc-client 6.4.5 (last stable and recommended Version)
2. boinctray 2.3
3. kde4-skrooge 0.2.4 (also published in openSUSE:Factory:contrib and KDE:KDE4:Community)
4. libatlas3 3.8.2 (also published in Education)
5. libdbus++ 0.6.0
6. libtinyxml0 2.5.3 (also published in openSUSE:Factory:contrib)
7. libtktray1 1.1
8. lynis 1.2.3 (also published in openSUSE:Factory:contrib)
9. mountmanager 0.2.6 (also published in openSUSE:Factory:contrib and KDE:KDE4:Community)
10. necpp 1.2.6+cvs20070816
11. python-iCalendar 1.2 (also published in openSUSE_Factory:contrib)
12. qantenna 0.2.1
13. rkhunter 1.3.4 (also published in openSUSE:Factory:contrib)

Have a lot of Fun

So for production purposes, we always recommend to use our frozen repositories on http://download.opensuse-education.org/. But as “frozen” implies, the repositories there are frozen at the time, the openSUSE-Education team declares them as “Goldmaster” (which is the case for all except the 11.1 repo at the moment) – and no package update or changes happens for this repositories.

The openSUSE-Education team has relatively long development and testing cycles – but as everywhere, shi* happens, and so it might be that some of the packages in the frozen repository are broken or need a security fix. For this, we have created update repositories (for at least 11.0 and the upcomming 11.1 Edu-Release) which are disabled per default, but added to the system during installation of the openSUSE-Education-release  package. (Reason behind this decision: if an administrator installs openSUSE-Education in a school, he wants to “mirror” the update repositories and not point every client to the official ones. All a user has to do is to enable this update repository via YaST or via “zypper mr -e ‘openSUSE-Education Updates'”.

We’re using the “updateinfo.xml” file formal described in the openSUSE-Wiki. Currently, we’ve 5 package updates/fixes for 11.0 in the update repository – and this might grow over the time. The updates are shown in the current online-update-applets as “normal” updates like the openSUSE ones. Interestingly, the user can’t see if an update is from the official openSUSE or the openSUSE-Education update repository – even if we use a different “from” tag. Perhaps we have to “play” with the “release” or other tags: testing is needed as it looks like nobody tries this before…