So, you’re in the middle of a review, and have couple of commits but one of the comments is asking you to modify a line that belongs to second to last, or even the first commit in your list, and you’re not willing to do:

git commit -m "Add fixes from the review" $file

Or you simply don’t know, and have no idea what squash or rebase means?, well I won’t explain squash today, but I will explain rebase

See how I do it, and also how do I screw up!

It all boils down to making sure that you trust git, and hope that things are small enough so that if you lose the stash, you can always rewrite it.

So in the end, for me it was:

git fetch origin
git rebase -i origin/master # if your branch is not clean, git will complain and stop
git stash # because my branch was not clean, and my desired change was already done
git rebase -i origin/master # now, let's do a rebase
# edit desired commits, for this add the edit (or an e) before the commit
# save and quit vim ([esc]+[:][x] or [esc]+[:][w][q], or your editor, if you're using something else
git stash pop # because I already had my change
$HACK # if you get conflicts or if you want to modify more
      # be careful here, if you rewrite history too much
      # you will end up in Back to the Future II
      # Luckly you can do git rebase --abort
git commit --amend $files #(alternatively, git add $files first then git commit --amend
git rebase --continue
git push -f # I think you will need to add remote+branch, git will remind you
# go on with your life

Note: A squash is gonna put all of the commits together, just make sure that there’s an order:

I lied, here’s a very quick and dirty squash guide

• pick COMMIT1
• pick COMMIT2
• squash COMMIT3 # (Git will combine this commit, with the one above iir, so COMMIT2+COMMIT3 and git will ask you for a new commit message)

If something is not broken, do not fix it. Following that principle, the YaST Team spent almost no time on the latest sprint working on SUSE Linux Enterprise 15 SP3 or openSUSE Leap 15.3. But that doesn’t mean we remained idle. Quite the opposite, we invested our time reorganizing some of the YaST internals. An effort that hopefully will pay off in the mid term and that affects topics like:

• Management of local users, specially during installation.
• Unification of the code for configuring the network.
• Error handling and reporting.
• Reorganization of our UI toolkit.

So let’s take a closer look to all that.

In our previous blog post we already announced we were considering to refactor the YaST Users modules to improve the management of local users and to reduce the risk associated to the current complexity of the module. We can now say we are making good progress in that front. We are working on a separate branch of the development repository that is not submitted to Tumbleweed or any other available distribution, which means we still have nothing concrete our users can test. But we hope to have the creation of users during installation completely rewritten by the end of next sprint, while still remaining compatible with all other YaST components that rely on user management.

Another milestone we reached on the latest sprint regarding YaST internal organization was the removal of the legacy network component known as LanItems. Everything started with the report of bug#1180085 that was produced because the installer, which uses the new Y2Network (a.k.a. network-ng) infrastructure for most tasks, was still relying on that legacy component for proposing the installation of the wpa_supplicant package. So we took the opportunity to seek and destroy all usage of the old component all along YaST, replacing the calls to it with the equivalent ones in the new infrastructure. Less code to maintain in parallel, less room for bugs.

That was not the only occasion during this sprint in which we turned a bug into an opportunity to improve YaST internals. It was also reported that using an invalid value for the bootmode or startmode fields of a network configuration file could produce a crash in YaST. In addition to fixing that problem, we took the opportunity to introduce a whole new general mechanism to handle errors in YaST and report them to the user in a structured and centralized way. Apart from the YaST Network module, that new internal infrastructure will be adopted by several parts of YaST during subsequent sprints. In fact, it’s already being used in the rewritten management of local users mentioned at the beginning of this post.

Last but not least, we would like to mention that we keep working to improve the new unified repository of LibYUI. Apart from revamping the README file that serves as landing page, we created new scripts for a more pleasant and flexible building process, we are improving the compatibility with the Gtk backend and with libyui-mga (the extra components developed and maintained by Mageia) and we published the API documentation in a central location that is now automatically updated on every change of the repository.

Of course, during the process of implementing all the mentioned improvements, we fixed several other bugs for SLE-15-SP3 and openSUSE Leap 15.3 and also for older releases and Tumbleweed. But, who wants to write about boring bug fixes? We prefer to go back to work and prepare more exciting news for our next report in two weeks from now. See you then!

Dear Tumbleweed users and hackers,

This week seemed rather calm except for a minor glitch with the Linux kernel 5.11.16, which, due to a build failure, was out of sync between the various kernel sub-packages for one snapshot. The pace of the snapshots was averaged at 5 snapshots (0423, 0425, 0426, 0427, and 0428).

The changes included things like:

• Linux kernel 5.11.16 & 5.12.0
• KDE Gear 21.04.0 (formerly KDE Applications)
• Mozilla Firefox 88.0
• NetworkManager 1.30.4
• Virtualbox 6.1.20: some services were renamed; e.g. vboxautostart.service” is replaced by “vboxautostart-service.service

The plan for the upcoming snapshots currently includes:

• TeXLive 2021
• Move openmpi default from openmpi2 to openmpi4
• GNOME 40.1
• icu 69.1: for the ring packages, nodejs15 seems to be the last blocker
• Switch from go 1.15 to go 1.16: most packages fixed, the last failure in Staging:M is cilium
• GCC 11 as default compiler: Move from special-purpose Staging:Gcc7 to Staging:O (incl. openQA test coverage). There are a few more build failures to be addressed.
• UsrMerge: The current state is that we checked in all changes and are planning on actually doing the switch somewhen in the not too far future, likely together with the planned distro-rebuild for GCC 11

Six openSUSE Tumbleweed were released this week.

The snapshots delivered updated versions of curl, KDE Gear, LLVM, GNOME 40, Mozilla’s Firefox and Thunderbird and much more.

The 20210428 snapshot updated the Linux Kernel to version 5.12 and text editor vim to version 8.2.2800. The virtualbox update to 6.1.20 took care of a hang for guest operating systems under circumstances where Hyper-V is used and the VM packaged added support for kernel versions 5.11 and 5.12. Domaine name cacher dnsmasq 2.85 added --dynamic-host options and debugger strace 5.12.0 made improvements and implemented an option to display SELinux contexts.

Daniel Stenberg detailed the patch release of curl 7.76.1 in a video on April 14, which made it into snapshot 20210427. No new features were made with the curl release, but Stenberg acknowledged contributions in the video and highlighted the selection of HTTP/2 over HTTPS. Open-source file pager less updated to version 581, which fixed some crashes and added several new options in the release. Utility probing package os-prober updated to version 1.78 and firmware package shim-leap updated to version 15.4.

Snapshot 20210426 updated about 15 packages, which included the 5.11.16 Linux Kernel and an updated 11.0.11.0 version of java-11-openjdk, which had a very large update and addressed two Common Vulnerabilities and Exposures. A fix for container runtime binary labels were made in the update of container-selinux 2.160.1. A major version of ncompress 5.0 cleaned up some code and fixed the recursive mode. General purpose cryptographic library libgcrypt provided some accelerated implementations for x86_64 in the 1.9.3 update. Other packages to update in the snapshot are pipewire 0.3.26, rubygem-nokogiri 1.11.3, python-pydot 1.4.2 and more.

KDE Gear 21.04.0, which is the new name for KDE apps, arrived in snapshot 20210425. A new menu option was added in the file archiver Ark to show the about dialog for kpart. File manager Dolphin removed some input methods and fixed the alignment of the location bar during the first startup. KDE’s text editor Kate fixed a memory leak and some compiler warnings. Video editor Kdenlive fixed a few crashes and the keyframe limit on imports from the clipboard. GNOME 40 had multiple updates. Translations were made with gedit 40.1, Document viewer evince 40.1 added three patches to remove more SyncTeX, and gnome-tweaks 40.0 made a fix bumping up from the beta version, which failed to recognize when GNOME Shell was running in the release candidate version. Both gtk3 and gtk4 were updated to 3.24.28 and 4.2.0 respectively. GTK4 brought some event matching fixes for missed layouts for Wayland. Other packages updated in the snapshot were NetworkManager 1.30.4, glib2 2.68.1, pango 1.48.4, rsyslog 8.2104.0 and wireshark 3.4.5, which fixed the printing of GeoIP information.

Snapshot 20210423 updated Mozilla’s Firefox to version 88.0 and Thunderbird to version 78.10.0. The browser has a new feature with PDF forms now supporting JavaScript embedded in PDF files. The open-source browser also made a change to the microphone and camera prompts reducing the number of times a prompt asks to grant device access on a website. Nine CVEs were fixed with the Thunderbird email client; one of which could have executed an arbitrary FTP command on FTP servers using an encoded URL. Regressions were fixed with redis 6.2.2 and a Xen update restored a change that was silently removed almost two years ago. YaST had multiple packages updated and many of those entailed some spec file cleanups.

The week’s opening snapshot, 20210422, gave audio users an update with Audacity 3.0.2; the audio software added some new preferences for output and improved diagnostics reporting. The major version of llvm12 12.0.0 arrived and the compiler brought in a ton of changes. There were changes for architecture targets, the WebAssembly target, go bindings, C Application Programming Interfaces and much more. AppStream made some parsing improvements and improved a text wrap for when words could be excessively long. Text shaping package harfbuzz, developed by everyone’s favorite font expert Behdad Esfahbod, improved some shape joining scripts and provided documentation improvements. Other packages updated in the snapshot were hwinfo 21.73, sqlite 3.35.5, sudo 1.9.6 and more.

Unlike application icons, the symbolic icons don't convey application identity, but rely on visual metaphor to describe an action (what a button in the UI does).

GNOME has not used fullcolor icons in toolbars and most of the UI in many years. Instead we use symbols, adjusting legibility and their rendering the same way we do with text (recoloring the foreground and background as you can demo switching the dark theme on this blog post).

But how does one create such an icon? Here's a walkthrough of the process, using our 2021 tooling. While the actual drawing of shapes still happens in Inkscape, the workflow is now heavily supported by a suite of design tools.

Before we dive into creation though, let's start with a more common case: In many cases developers just want to pick and use an existing icon rather than attempting to create it or commission a designer.

Finding an Icon

Historically, looking up icons has been a matter of familiarizing yourself with the icon naming spec, which was built on the concept of semantic naming. However, it turns out developers really just want that symbol that looks like a door, rather than adhering to the strict semantic constraints. Combined with icon themes and evolving visual trends this semantic dream gradually faded over time.

The very basic set of icons is provided directly by the toolkit. For the most part it still adheres to the semantic names such as edit-copy or menu-open rather than descriptive names like scissors or pencil. The coverage of the set is quite conservative and you're likely to need something that isn't provided by GTK itself.

Sounds like a lot of work? Lucky for you we have Icon Library to make this easy!

Icon Library

The app can help you not only to search for an appropriate icon using keywords, it can assist you distributing the assets along with your app (as a gresource). While it's on you as a developer to maintain the assets you bundle, no longer will your app break when you've used the the wrench icon when the designers followed a trend of using a pegged wheel for preferences or decided to drop an old or unused icon.

It's worth noting the app is also quite useful for designers, since you can also copy & paste icons into mockups easily.

The application is currently being ported to GTK 4 so there's a lot of moving parts in the air at the moment, but the latest release on Flathub is perfectly usable.

Creation

So let's assume the icons available don't really fit your need and you need to create one from scratch. I should boldly proclaim that with no API-like maintenance burden, the design team is more than happy to fulfill app developers' requests. Especially apps aiming to be listed in GNOME Circle, feel free to request an icon on Gitlab.

The first step is always to figure out the metaphor. Sketching out some ideas on paper is a solid recommendation. Even if you think you're no good at sketching, try it. In fact, especially when you're not good at sketching, the process will help you identify very strong metaphors that convey the meaning even using a few squibbly lines. The more definition you provide, the harder it is to tell whether the function isn't overshadowed by the form.

Once you're somewhat convinced a fitting metaphor can be executed on the 16x16 pixel grid, it's time to reach for the tool to guide your throughout the process, Symbolic Preview.

A Handful

Let's assume you have a small app that is very early in development and you decided to make it easy to report issues with it and need a report bug icon for the headerbar.

Symbolic Preview either allows you to create a single symbolic or a sheet with many symbolics. In our first case, we'll go for just one.

After providing a name for your icon (prefixing with app name can avoid some theming issues) a template is saved. Currently you have to do some file system surfing to open up the asset in Inkscape.

Symbolic preview can be used as its name suggests. Currently it doesn't auto-reload on changes, but hopefully that will come soon.

There are some basic guidelines on how to produce a GNOME symbolic icons, but to provide a tl;dr —

• Use filled shapes to provide enough contrast
• Maintain the overall contrast not going edge to edge
• Main outline should not use a hairline stroke, 2px strokes are advised
• Convert strokes to outlines. The old toolchain allowed to use strokes as long as no fill was used on the same object, but it has been the source of many misrenderings. Just convert all strokes to outlines with Path>Stroke to Path in Inkscape.

The app provides different color contexts and displays your icon among existing symbolics, not unlike what App Icon Preview does for app icons. Again, this is when you only need to ship a handful of icons with your app.

Your needs may, however, exceed just a few. Maintaining lots of individual icons in separate files becomes daunting. Also, there is no need to see your icons in the context of others when they form a large enough set on their own.

The same app we just used to create and test a single symbolic icon can be used to maintain a large set of symbolics in a single library file. The icon-development-kit that is the source for most of the icons you can search with Icons Library is also maintained this way. Let's take a look how you can maintain a whole set of symbolics icons.

A Lot

Unlike individual icons, for preview and export to work, this workflow is very Inkscape centered and there are numerous constraints to be mindful of, so let's dive in.

Export Conventions

There are a few conventions you need to follow in order for the export to work. Icon devel kit describes the conventions in detail, but let's sum them up here:

• Each icon is a group (<g>). To force its size to be 16x16px, the icon should include a <rect> with no stroke or fill, that is exactly 16x16 and aligns to the pixel grid. This rectangle is removed during export.
• The name of the icon is taken from the title property of the group in the object properties in Inkscape (Object>Object Properties). (<title/>).
• If you wish to omit an icon in the preview and export, don't provide a name for it or append -old to it. This can be useful for some 'build assets'.

Metadata

While it's mainly useful for maintaining a collection like icon-development-kit, you will save yourself time looking up your own assets if you provide some metadata describing your icon.

Keywords for an icon are given as space separated words in the label attribute in object properties in Inkscape (inkscape:label attribute).

Acknowledgments

Jokingly we refer to the design tool page as the Bilal page. A huge thank you goes to Bilal Elmoussaoui for writing brilliant apps for GNOME and making the design process a little less punishing.

Announcement

The Kubic Project is proud to announce that Snapshot 20210426 has been released containing Kubernetes 1.21.0.

Release Notes are avaialble HERE.

Upgrade Steps

All newly deployed Kubic clusters will automatically be Kubernetes 1.21.0 from this point.

For existing clusters, please follow our new documentation our wiki HERE

Thanks and have a lot of fun!

The Kubic Team

The openSUSE Project and its community, contributors and release engineers have entered the Release Candidate phase for the upcoming openSUSE Leap 15.3 version today after a snapshot was released, which transitions the release to a new phase.

The RC signals the package freeze for software that will make it into the distribution, which is used on server, workstation, desktop and for virtualization and container use.

openSUSE Leap offers a clear advantage for servers by providing at least 18 months of updates for each release. There is a projection as of April 2021 that Leap 15 will extend to Leap 15.5. Leap Major Release (15.x) extends maintenance and support until a successor. At present, a successor has not been declared; Leap 15’s lifecycle fully aligns with SUSE Linux Enterprise and uses the source code and Leap is built with the exact same binary packages..

Desktop environments for the release include KDE’s Long-Term-Support version of Plasma 5.18, GNOME 3.34 and Xfce 4.16. Packages for artificial Intelligence and Machine Learning are available for data scientists who use the release. A list of some of the packages in openSUSE Leap 15.3 can be found on the Wiki.

Leap release manager Lubos Kocman recommends Beta and RC testers use the “zypper dup” command in the terminal when upgrading to the General Availability (GA) once it’s released.

During the development stage of Leap versions, contributors, packagers and the release team use a rolling development method that are categorized into phases rather than a single milestone release; snapshots are released with minor version software updates once passing automated testing until the final release of the Gold Master (GM). At that point, the GM becomes available to the public (GA expected on June 2) and the distribution shifts from a rolling development method into a supported release where it receives updates until its End of Life (EOL).

Kocman listed the following important dates related to the release:

• May 14 - Translation deadline
• May 21 - Gold Master
• June 2 - Public Availability of the Release (5 to 10 days after GM)
• June 2 - Start of Release retrospective survey
• June 16 - Collect feedback from the retrospective

Users upgrading to openSUSE Leap 15.3 need to be aware that upgrading directly from versions before openSUSE Leap 15.2 is not recommended. Due to the upgrade path, it is highly recommended to upgrade to Leap 15.2 before upgrading to Leap 15.3.

The community is supportive and engages with people who use older versions of Leap through community channels like the mailing lists, Matrix, Discord, Telegram, and Facebook.

Dear Tumbleweed users and hackers,

Tumbleweed is in full swing – with a staggering 6 snapshots published since the last weekly review. And this, despite me having to discard 2 snapshots (one for being totally broken, and one was discarded because it took too long to test). The six snapshots published were 0415, 0416, 0417, 0418, 0420, and 0422.

The major changes included:

• Mozilla Thunderbird 78.9.1
• Poppler 21.04.0
• Postfix 3.5.10
• Mesa 21.0.2
• Linux kernel 5.11.15
• Pipewire 0.3.25
• Ffmpeg 4.4
• LXQt 0.17.0
• GCC 10.3.0
• RPM 4.16.1.3
• Lua 5.4.3
• SQLite 3.35.5
• LLVM 12
• Python 3.9 modules: besides python36-FOO and python38-FOO, we are testing to also shop python39-FOO modules; we already have the interpreter after all. Python 3.8 will remain the default for now. Building in snapshot 0415

This was quite a list of things happening, and the python 3.9 module introduction definitively took a while to enusre we don’t just trip over our own feet.

Things keep on moving, and we are currently testing integration of the following bits and pieces for Tumbleweed:

• Linux kernel 5.11.16+
• KDE Applications 21.04.0
• Mozilla Firefox 88.0
• GCC 11 as default compiler
• TeXLive 2021
• UsrMerge is progressing well, thanks to Ludwig for his continued work here. The current state is that we checked in all changes and are planning on actually doing the switch somewhen in the not too far future

Integrated development environemnts (IDE) are using their own folders within your code repositories to store their settings. This can become annoying when working on a git repository and they keep popping up as untracked files: