Welcome to Planet openSUSE

This is a feed aggregator that collects what openSUSE contributors are writing in their respective blogs.

To have your blog added to this aggregator, please read the instructions.


Monday
24 June, 2019


face

BionicPup review title.png

A distribution of Linux that I have heard about for many, many years, considered trying but have not ever given a spin has been Puppy Linux. It is known for being small and low resource intensive distribution. I have played with some other low resource distributions but this one might be the smallest resource usage of them all. 

This is my biased review as an openSUSE user of Puppy Linux. I have been running it for a few days in VM and also on 32 Bit hardware. I am a fan of old hardware so anything that keeps my old hardware going and going usefully is fantastic.

Bottom Line up front, Puppy Linux is great for specific use cases like old hardware and a great way to set up a live USB environment for troubleshooting hardware or a network. It isn’t for me for full time usage on my main machine but this most certainly is not just “yesterday’s Linux.”

If you want to know more, keep reading but it’s kind of long, otherwise, this is a good time to bail or jump down to my likes and dislikes.

Installation

The installation of Puppy Linux isn’t quite as straight forward as the mainline distributions out there. That is, it takes several more steps It’s not bad but you sort of have to know what you are doing to get this set up. I decided to install BionicPup from here.

It boots into a live environment with a nice welcome and some initial settings configurations. I think that this is particularly fantastic. My understanding is, Puppy has been greeting you like this, before it was the thing to do.

I included the screenshot of the desktop, not because I want to show you how cluttered it is or that it looks dated but to show the coolest looking dog I have ever seen. I’d get a dog like this… maybe… I mean, assuming it doesn’t become my robotic overlord.

PuppyLinux VM 5

When you select to install it, as I am doing here after dinking around a while with it, you are given two basic options: Universal Installer, which is a typical installation you would have to the internal storage or a Boot flash USB Installer. For this testing and my initial purpose, I selected the Universal Installer as my ultimate intended target is an old Dell Inspiron 5100. Before I committed to install, I wanted to look at the Install Applications tab and take note on that for later. The Puppy Package Manger is the place to go to install your software.

After selecting Universal Installer you are presented with four options: USB Flash Drive, USB Hard Drive, Internal Hard Drive, Internal Flash Drive. I am curious about some of the other options, as in what they are doing different but for my purpose, I chose the internal hard drive.

After selecting the drive type to which I am installing, I was presented the need to


Thursday
20 June, 2019


face

ATTENTION ALL DISTRIBUTIONS: this is for you. THE SONAME MAY CHANGE!

I am preparing a bzip2-1.0.7 release. You can see the release notes, which should be of interest:

  • Many historical patches from various distributions are integrated now.

  • We have a new fix for the just-published CVE-2019-12900, courtesy of Albert Astals Cid.

  • Bzip2 has moved to Meson for its preferred build system, courtesy of Dylan Baker. For special situations, a CMake build system is also provided, courtesy of Micah Snyder.

What's with the soname?

From bzip2-1.0.1 (from the year 2000), until bzip2-1.0.6 (from 2010), release tarballs came with a special Makefile-libbz2_so to generate a shared library instead of a static one.

This never used libtool or anything; it specified linker flags by hand. Various distributions either patched this special makefile, or replaced it by another one, or outright replaced the complete build system for a different one.

Some things to note:

  • This hand-written Makefile-libbz2_so used a link line like $(CC) -shared -Wl,-soname -Wl,libbz2.so.1.0 -o libbz2.so.1.0.6. This means, make the DT_SONAME field inside the ELF file be libbz2.so.1.0 (note the two digits in 1.0), and make the filename of the shared library be libbz2.so.1.0.6.

  • Fedora patched the soname in a patch called "saneso" to just be libbz2.so.1.

  • Stanislav Brabec, from openSUSE, replaced the hand-written makefiles with autotools, which meant using libtool. It has this interesting note:

Incompatible changes:

soname change. Libtool has no support for two parts soname suffix (e. g. libbz2.so.1.0). It must be a single number (e. g. libbz2.so.1). That is why soname must change. But I see not a big problem with it. Several distributions already use the new number instead of the non-standard number from Makefile-libbz2_so.

(In fact, if I do objdump -x /usr/lib64/*.so | grep SONAME, I see that most libraries have single-digit sonames.)

In my experience, both Fedora and openSUSE are very strict, and correct, about obscure things like library sonames.

With the switch to Meson, bzip2 no longer uses libtool. It will have a single-digit soname — this is not in the meson.build yet, but expect it to be there within the next couple of days.

I don't know what distros which decided to preserve the 1.0 soname will need to do; maybe they will need to patch meson.build on their own.

Fortunately, the API/ABI are still exactly the same. You can preserve the old soname which your distro was using and linking libbz2 will probably keep working as usual.

(This is a C-only release as usual. The Rust branch is still experimental.)


Wednesday
19 June, 2019


face

Since the YaST team rewrote the software stack for managing the storage devices, we have been adding and presenting new capabilities in that area regularly. That includes, among other features, the unpaired ability to format and partition all kind of devices and the possibility of creating and managing Bcache devices. Time has come to present another largely awaited feature that is just landing in openSUSE Tumbleweed: support for multi-device Btrfs file systems.

As our usual readers surely know, Btrfs is a modern file system for Linux aimed at implementing advanced features that go beyond the scope and capabilities of traditional file systems. Such capabilities include subvolumes (separate internal file system roots), writable and read-only snapshots, efficient incremental backup and our today’s special: support for distributing a single file system over multiple block devices.

Multi-device Btrfs at a glance

Ok, you got it. YaST now supports multi-device Btrfs file system… but, what that exactly means? Well, as simple as it sounds, it’s possible to create a Btrfs file system over several disks, partitions or any other block devices. Pretty much like a software-defined RAID. In fact, you can use it to completely replace software RAIDs.

Let’s see an example. Imagine you have two disks, /dev/sda and /dev/sdb, and you also have some partitions on the first disk. You can create a Btrfs file system over some devices at the same time, e.g., over /dev/sda2 and /dev/sdb, so you will have a configuration that looks like this.

        /dev/sda                /dev/sdb
            |                       |   
            |                       |   
     ---------------                |   
    |               |               |   
    |               |               |   
/dev/sda1       /dev/sda2           |   
                    |               |   
                    |               |   
                     ---------------
                            |   
                          Btrfs
                            |   
                            |   
                            @ (default subvolume)
                            |   
                            |   
                 -----------------------
                |       |       |       |   
                |       |       |       |   
              @/home  @/log   @/srv    ...

Once you have the file system over several devices, you can configure it to do data striping, mirroring, striping + mirroring, etc. Basically everything that RAID can do. In fact, you can configure how to treat the data and the Btrfs meta-data separately. For example, you could decide to do striping with your data (by setting the data RAID level to the raid0 value) and to do mirroring with the Btrfs meta-data (setting it as raid1 level). For both, data and meta-data, you can use the following levels: single, dup, raid0, raid1, raid10, raid5 and raid6.

The combination of this feature and Btrfs subvolumes opens an almost endless world of possibilities. It basically allows you to manage your whole storage configuration from the file system itself. Usage of separate tools and layers like software-defined RAID or LVM are simply dispensable when using Btrfs in all its glory.

Managing multi-device Btrfs with the YaST Partitioner

Interesting feature indeed, but where to start? As usual, YaST brings you the answer! Let’s see how the YaST version that is currently being integrated in openSUSE Tumbleweed will ease the management of this cool Btrfs feature. SLE and Leap users will have to wait to the next release (15.2) to enjoy all the bells and whistles.

First of all, the Btrfs section of our beloved Expert Partitioner has been revamped as shown in the following picture.

New Btrfs section of the Partitioner

It


Tuesday
18 June, 2019


face

On the 22nd of May, openSUSE released (1) Leap 15.1. A couple of days later I took the plunge to update my laptop and desktop from openSUSE Leap 15.0. In this blog, I will detail my update experience.

Updating my laptop

My laptop is a ASUS VivoBook X402NA-FA112T. This is a laptop with an Intel Pentium N4200 processor, 4 GB of RAM and a 128 GB SSD. The upgrade to Leap 15.1 went flawless.

I have used the SUSE studio image writer to burn the Leap 15.1 ISO to a USB thumb drive. This is an excellent program that does just one thing and does it right. After plugging in this USB drive, I checked the UEFI menu to make sure that I would boot from the USB drive instead of the SSD harddrive.

To start the upgrade, just select the right option from the USB boot menu.

Then accept the license agreement, which states that this is free and open source software! You own it outright, but you have to share the source code if you want to distribute or change it.

The installer kicks off and finds my previous installation of openSUSE Leap 15.0.

The next thing to do is to Disable the additional repositories. The default setting is for these repositories to be Removed. I don’t want to re-enter these additional repositories from scratch. So I simply disable them. After installation, I open YaST and then Software Repositories. And I change the name of the URL from Leap 15 to Leap 15.1. For example:

https://download.opensuse.org/repositories/mozilla/openSUSE_Leap_15.0/

becomes

https://download.opensuse.org/repositories/mozilla/openSUSE_Leap_15.1/

After that, I set the repository to Enabled and Auto-refresh.

Most of these repositories were available from the get go. The only exception were 2 gaming repositories which took 2 more days to become available.

The ‘update settings’ page stated that there were package conflicts that couldn’t be resolved automatically. So I needed to go in and make these decisions manually. The amazing thing is, that even with all additional package repositories disabled, the installer still goes out of its way to find an updated package from various additional package repositories and proposes to install it. Its these kind of little things that make a big difference!

After I went through the list with all the proposed changes, I got a nice summary of everything that would happen. This is the default YaST Software Manager installation overview. But its a nice touch to present the user with such a summary.

Once I clicked on Accept, I was returned to the ‘update settings’ page. After clicking install, there is no way back.

I restarted my laptop and Leap 15.1 was successfully installed! Great job openSUSE!

Updating my desktop

My desktop is a HP Pavilion Power 580-146nd. This is a midsize PC with an AMD Ryzen 5 1400 CPU, an AMD Radeon RX 580 GPU, 16 GB of RAM


Monday
17 June, 2019


face

We have released the beta of the upcoming Open Build Service (OBS) version 2.10. This version is the first one with the revamped user interface. For details on this, please refer to our blog where we have written a series of post on the matter. Known Issues None. New Features Add binary release tracking data for containers Add support to collect performance metrics with InfluxDB Amazon EC2/ Microsoft Azure cloud upload support Text fields are...


Saturday
15 June, 2019


face

As everyone seems to like to put kernel trees up on github for random projects (based on the crazy notifications I get all the time), I figured it was time to put up a semi-official mirror of all of the stable kernel releases on github.com

It can be found at: https://github.com/gregkh/linux and I will try to keep it up to date with the real source of all kernel stable releases at https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/

It differs from Linus’s tree at: https://github.com/torvalds/linux in that it contains all of the different stable tree branches and stable releases and tags, which many devices end up building on top of.

So, mirror away!

Also note, this is a read-only mirror, any pull requests created on it will be gleefully ignored, just like happens on Linus’s github mirror.

If people think this is needed on any other git hosting site, just let me know and I will be glad to push to other places as well.

This notification was also cross-posted on the new http://people.kernel.org/ site, go follow that for more kernel developer stuff.


Friday
14 June, 2019


face

Dear Tumbleweed users and hackers

The last week has been rather ‘slow’ when it comes to snapshots published. Unfortunately, OBS had a small bug last Friday, which was fixed rather quickly, but its effects were devastating on the staging process and on the product builds. It took us several iterations of identifying missing binaries and rebuilding the missing bits and pieces. For this reason, I can only report about two snapshots published this week *0607 and 0712) – and for this, I’m even cheating and including the latest snapshot which is only just in progress of being distributed to mirrors.

The changes included in those two snapshots are:

  • gdb 8.3
  • libvirt 5.4.0
  • KDE Plasma 5.16.0
  • LibreOffice 6.2.4.2
  • SQLite 3.28.0

The list of major changes in Staging areas did not change drastically – and the main topics worked on are still:

  • KDE Applications 19.04.2
  • LLVM 8.0
  • openssl 1.1.1c
  • Texlive 2019
  • Qt 5.13
  • swig 4.0
  • cmake 3.14

Thursday
13 June, 2019


Michael Meeks: 2019-06-13 Thursday.

13:23 UTCmember

face
  • B&B Hotel - lots of traffic noise through the closed window, ambulances to dream of; up lateish, train, Eurostar, train and so on. Reasonable connectivity - built ESC agenda a tad late while on the train encouraging using Collabora Online rather effectively; good.

face

The three openSUSE Tumbleweed snapshots released this week updated some key packages for users of the rolling release.

One of those key packages was an update of the GNU Debugger, gdb 8.3, which was released in the 20190607 snapshot. The debugger enabled ada tests on ppc64le and riscv64; multitarget builds for riscv64 were also enabled. The snapshot also added unit test for Logical Volume Manager (LVM) over Modular Disk (MD) with the update of libstorage-ng 4.1.127. Several patches and bug fixes were applied with the update of libvirt 5.4.0, which also made an improvement to avoided unnecessary static linking that results in both the disk and memory footprint being reduced. Libvirt also introduced support for the md-clear CPUID bit. The python-libvirt-python 5.4.0 package added all new Application Programming Interfaces (APIs) and constants in libvirt 5.4.0. Text editor vim 8.1.1467 had multiple fixes, but the Tumbleweed snapshot introduced some new bugs and is currently trending at an 86 rating, according to the snapshot reviewer.

The two previous snapshots recorded an exceptional stable rating of 98 according to the snapshot reviewer.

Snapshot 20190606 updated just two packages. The nodejs10 package put out a new upstream Long-Term-Support (LTS) version with nodejs10 10.16.0, which upgraded upgrade openssl sources to 1.1.1b and libuv to 1.28.0. The other package update in the snapshot was xfdesktop 4.12.5; the package for the Xfce 4 Desktop Environment fixed icon sizes in settings, reset the desktop icon order and fixed a timer leak.

The 20190605 snapshot had three packages updated. Linux Kernel 5.1.7 had some fixes pertaining to Btrfs like fixing the in-core state with a storage device between ranged fsync and writeback of adjacent ranges. The kernel update also removed dependencies with the arch_timer driver internals for the arm architecture and added Ice Lake support for Intel’s x86 power mode or c-state. Time Zones were updated with the libical 3.0.5 package and the libinput 1.13.2 package made some changes for Wacom touchpads and Apple bluetooth touchpad.

Release manager Dominique Leuenberger wrote a review of the previous two weeks and stated that openssl 1.1.1c, Texlive 2019, KDE Plasma 5.16, Qt 5.13, LLVM 8, swig 4.0, and cmake 3.14 were all progressing in the staging projects and will be released soon in upcoming Tumbleweed snapshots.


face

After today’s deployment, we faced a downtime of our reference server for users in our beta program. We want to give you some insight into what happened. Problems/Timeline Around 09:50 (CEST), we ran a deployment. After the deployment finished, we noticed that some URLs were responding fine (/about) while others did not and produced an exception. After looking into our exception tracker, we noticed that this had something to do with how we run our...


Wednesday
12 June, 2019


Michael Meeks: 2019-06-12 Wednesday.

21:00 UTCmember

face
  • Up early, a couple of dismal, late trains to Kings Cross, and the Eurostar to OW2Con / Paris. Dodgy taxi ride, arrived somewhat late for the session. Gave a talk on LibreOffice Online and then C'bras role in it briefly.
  • Caught up with Sigmund, Philippe from Arawa, Simon, and enjoyed a fine evening together with friends old & new.

face

Gratitude. This is the title of the email thread1 that started a debate over privacy & data protection within the AFRINIC community. The email was sent on the “community discuss” mailing list of AfriNIC. It was a reaction to something that was found in the minutes of a special board meeting that was held on 5 March 2019. The minutes were published2 on the AfriNIC website. The author of the email expressed his gratitude towards the current CEO of AfriNIC and one board director for their “efforts to keep the community involved in AfriNIC matters in an open and transparent way”.


Tuesday
11 June, 2019


Michael Meeks: 2019-06-11 Tuesday.

21:00 UTCmember

face
  • More admin, project planning, prototype acceptance criteria construction. Three lots of maths revision in the evening. Worked late putting documentation together with Kendy.

face

Here is a straightforward port of some easy code.

randtable.c has a lookup table with seemingly-random numbers. This table is used by the following macros in bzlib_private.h:

extern Int32 BZ2_rNums[512];

#define BZ_RAND_DECLS                          \
   Int32 rNToGo;                               \
   Int32 rTPos                                 \

#define BZ_RAND_INIT_MASK                      \
   s->rNToGo = 0;                              \
   s->rTPos  = 0                               \

#define BZ_RAND_MASK ((s->rNToGo == 1) ? 1 : 0)

#define BZ_RAND_UPD_MASK                       \
   if (s->rNToGo == 0) {                       \
      s->rNToGo = BZ2_rNums[s->rTPos];         \
      s->rTPos++;                              \
      if (s->rTPos == 512) s->rTPos = 0;       \
   }                                           \
   s->rNToGo--;

Here, BZ_RAND_DECLS is used to declare two fields, rNToGo and rTPos, into two structs (1, 2). Both are similar to this:

typedef struct {
   ...
   Bool     blockRandomised;
   BZ_RAND_DECLS
   ...
} DState;

Then, the code that needs to initialize those fields calls BZ_RAND_INIT_MASK, which expands into code to set the two fields to zero.

At several points in the code, BZ_RAND_UPD_MASK gets called, which expands into code that updates the randomization state, or something like that, and uses BZ_RAND_MASK to get a useful value out of the randomization state.

I have no idea yet what the state is about, but let's port it directly.

Give things a name

It's interesting to see that no code except for those macros uses the fields rNToGo and rTPos, which are declared via BZ_RAND_DECLS. So, let's make up a type with a name for that. Since I have no better name for it, I shall call it just RandState. I added that type definition in the C code, and replaced the macro-which-creates-struct-fields with a RandState-typed field:

-#define BZ_RAND_DECLS                          \
-   Int32 rNToGo;                               \
-   Int32 rTPos                                 \
+typedef struct {
+   Int32 rNToGo;
+   Int32 rTPos;
+} RandState;

...

-      BZ_RAND_DECLS;
+      RandState rand;

Since the fields now live inside a sub-struct, I changed the other macros to use s->rand.rNToGo instead of s->rNToGo, and similarly for the other field.

Turn macros into functions

Now, three commits (1, 2, 3) to turn the macros BZ_RAND_INIT_MASK, BZ_RAND_MASK, and BZ_RAND_UPD_MASK into functions.

And now that the functions live in the same C source file as the lookup table they reference, the table can be made static const to avoid having it as read/write unshared data in the linked binary.

Premature optimization concern: doesn't de-inlining those macros cause performance problems? At first, we will get the added overhead from a function call. When the whole code is ported to Rust, the Rust compiler will probably be able to figure out that those tiny functions can be inlined (or we can #[inline] them by hand if we have proof, or if we have more hubris than faith in LLVM).

Port functions and table to Rust

The functions are so tiny, and the table so cut-and-pasteable, that it's easy to port them to Rust in a single shot:

#[no_mangle]
pub unsafe extern "C" fn BZ2_rand_init() -> RandState {
    RandState {
        rNToGo: 0,
        rTPos: 0,
    }
}

#[no_mangle]
pub unsafe extern "C" fn BZ2_rand_mask(r: &RandState) -> i32 {
    if r.rNToGo == 1 {
        1
    } else {
        0
    }
}

#[no_mangle]
pub unsafe extern "C" fn BZ2_rand_update_mask(r: &mut RandState) {
    if r.rNToGo == 0 {
        r.rNToGo = RAND_TABLE[r.rTPos as usize];
        r.rTPos 

Monday
10 June, 2019


Michael Meeks: 2019-06-10 Monday.

21:00 UTCmember

face
  • Mail chew, worked away at project planning and acceptance criteria. Couple of project calls and sync with Kendy.

Sunday
09 June, 2019


Michael Meeks: 2019-06-09 Sunday.

21:00 UTCmember

face
  • All Saints, band in the morning. Back for a fine lunch, and out for another, much less used stretch of walk along the nearby ancient, defensive Dyke.
  • Slept while H. did Organ practice, encouraging progres with the quartet. Slugged in front of a movie in the evening.

face

What is Bedrock Linux?

From their website:

Bedrock Linux is a meta Linux distribution which allows users to utilize features from other, typically mutually exclusive distributions. Essentially, users can mix-and-match components as desired. For example, one could have:

  • The bulk of the system from an old/stable distribution such as CentOS or Debian.
  • Access to cutting-edge packages from Arch Linux.
  • Access to Arch’s AUR.
  • The ability to automate compiling packages with Gentoo’s portage
  • Library compatibility with Ubuntu, such as for desktop-oriented proprietary software.
  • Library compatibility with CentOS, such as for workstation/server oriented proprietary software.

All at the same time, all working together like one, largely cohesive operating system.

So, what is this thing? Bedrock Linux is a package manager compatibility overlay. Ever wanted to use CentOS or Arch packages on your Debian system? Bedrock Linux will let you do that.

Strata

A stratos in Bedrock Linux is a package management overlay. For example, if you want to add a CentOS Strata, you run:

$ sudo brl fetch centos

The BRL app will then download yum and it’s required apps and libraries into the overlay. Once it’s done you can then yum install whatever you want.

Have multiple versions of the same package? Use:

$ strat [stratus name] [packagename]

For example with the Nano editor:

tux@debian:~$ strat arch nano -V
GNU nano, version 4.2
(C) 1999-2011, 2013-2019 Free Software Foundation, Inc.
(C) 2014-2019 the contributors to nano
Email: nano@nano-editor.org Web: https://nano-editor.org/
Compiled options: --enable-utf8
tux@debian:~$ strat debian nano -V
GNU nano, version 2.7.4
(C) 1999..2016 Free Software Foundation, Inc.
(C) 2014..2016 the contributors to nano
Email: nano@nano-editor.org Web: https://nano-editor.org/
Compiled options: --disable-libmagic --disable-wrapping-as-root --enable-utf8
tux@debian:~$ strat centos nano -V
GNU nano version 2.3.1 (compiled 04:47:52, Jun 10 2014)
(C) 1999, 2000, 2001, 2002, 2003, 2004, 2005, 2006, 2007,
2008, 2009 Free Software Foundation, Inc.
Email: nano@nano-editor.org Web: http://www.nano-editor.org/
Compiled options: --enable-color --enable-extra --enable-multibuffer --enable-nanorc --enable-utf8

There are problems

It’s not as easy as it sounds. In order to install Bedrock Linux, you must have a compatible base OS. Here is the list that’s currently on the website:

Distro Hijack-able Fetch-able Maintainer
Alpine Linux Yes Yes paradigm
Arch Linux Yes Yes paradigm
CentOS Known issues Yes paradigm
Clear Linux Mixed reports Experimental support N/A
CRUX Known issues No N/A
Debian Yes Yes paradigm
Devuan Needs investigation Yes paradigm
Elementary OS Yes, but limited testing No N/A
Exherbo Yes In development Wulf C. Krueger
Fedora Yes Yes paradigm
Gentoo Linux Yes Yes paradigm
GoboLinux Known issues No N/A
GuixSD Needs investigation No N/A
Manjaro Yes, but pamac/octopi broken No N/A
Mint Needs investigation No N/A
MX Linux Known issues No N/A
NixOS Known issues No N/A
OpenSUSE Yes Experimental support N/A
OpenWRT Needs investigation Experimental support N/A
Raspbian Yes

Saturday
08 June, 2019


Michael Meeks: 2019-06-08 Saturday.

21:00 UTCmember

face
  • Up late; did some maths with H, N. and E. variously. More work - attacked various problems with long re-build times.
  • Finally, after some weeks, got space to get around to repairing the toilet flush in the upstairs toilet. One good opportunity for Goverments would be to ban pointless, self- defeating and environmentally damaging cost-engineering. A non-servicable, polythene flush membranes is an abomination. Hours of work, waste and expense to replace a sub-penny worth of plastic. Siliconed everything in sight to get it watertight.
  • Why is it that when my daughters invite their friends over, one of them inevitably appears used to turning the bathroom tap off with the moral equivalent of a spanner - making it come loose & rotate. Mended that too.

Friday
07 June, 2019


Michael Meeks: 2019-06-07 Friday.

21:00 UTCmember

face
  • Mail chew, show & tell call with Ivan, patch review, Board call. Ferried babes around while J. took E. to her birthday 'football golf' party. Ran games for the babes in the garden: running noughts and crosses, stilt walking, and a movie. Back to work until late.

face

Dear Tumbleweed users and hackers

During the last two weeks, openSUSE Tumbleweed has seen a total of 9 snapshots being released. As you come to expect from Tumbleweed, those snapshots are filled with updates. And as usual, the snapshots are tested by openQA before they are shipped out (in the last two weeks, for example, three snapshots were tested and discarded before publishing). The snapshots that did get published were 0524, 0525, 0527, 0529, 0601, 0603, 0604, 0605 and 0606 (hot off the press), summing up to those major changes:

  • Linux kernel 5.1.4, 5.1.5 & 5.1.7
  • Switch to GCC 9 as distro default compiler (full rebuild)
  • Mozilla Firefox 67.0 & Thunderbird 60.7.0
  • libopenraw 0.1.3 (beware: .pc file was renamed from *-1.0.pc to *-0.1.pc)
  • Mesa 19.0.5
  • flatpak 1.4.0
  • strace 5.1
  • nodejs10.16.0

The distro keeps on rolling, and based on the staging projects I can predict those updates coming soon to Tumbleweed:

  • openssl 1.1.1c
  • Texlive 2019
  • KDE Plasma 5.16
  • Qt 5.13
  • LLVM 8
  • swig 4.0
  • cmake 3.14

face

There is a lot of activity in the bzip2 repository!

Perhaps the most exciting thing is that Dylan Baker made a merge request to add Meson as a build system for bzip2; this is merged now into the master branch.

The current status is this:

  • Both Meson and Autotools are supported.
  • We have CI runs for both build systems.

A plea for help: add CI runners for other platforms!

Do you use *BSD / Windows / Solaris / etc. and know how to make Gitlab's CI work for them?

The only runners we have now for bzip2 are for well-known Linux distros. I would really like to keep bzip2 working on non-Linux platforms. If you know how to make Gitlab CI runners for other systems, please send a merge request!

Why two build systems?

Mainly uncertainty on my part. I haven't used Meson extensively; people tell me that it works better than Autotools out of the box for Windows.

Bzip2 runs on all sorts of ancient systems, and I don't know whether Meson or Autotools will be a better fit for them. Time will tell. Hopefully in the future we can have only a single supported build system for bzip2.


face

Introduction

I’m LCP, or Stasiek if you can pronounce that. Just a 20 years old guy from Poland who spends way too much time in front of computers. That’s how all my potted plants end up dead.

My Journey

I’ve been using computers for as long as I can remember, playing Solitaire, The Settlers, and other simple DOS games, because that’s what my parents and grandma liked to play. I started with Win95, 98, and 2000, before learning about Linux.

My interest in design was sparked by the original iPhone icons, which I loved. In contrast with my hatred toward the Faenza icon theme, both have fairly similar style yet widely different results. That’s how I began exploring and learned from there.

Correspondingly, my Linux journey started back in 2007 when my dad showed me Ubuntu, and just like what I did with Windows 2000 before, my pastime became installing and reinstalling Linux alongside Windows in different configurations (I apparently was consumed by the concept of installation and configuration, which might explain my YaST obsession?).

Later in 2010, I had a tough time with a machine that wouldn’t take any distro with the exception of openSUSE (although it did end up with a few Linuxrc errors). Besides, I really liked its GNOME 2 config back then; it was really user friendly yet powerful. I gave KDE a shot but to this day I never really liked it.

Contributing, how it all started…

My first contribution was because of my consistent and annoying complaining to Richard Brown on Linux Gaming Discord about the sorrow state of artwork in Tumbleweed. I didn’t like anything there. I, it seemed too dark, too boring; stuff was barely visible due to contrast issues. He pointed me to contribute and make it better then, so I did. Around the same time me and some of other people from Linux Gaming Discord created the openSUSE Discord, and I reused some assets from the Discord to create the new branding.

Even though my main focus has been artwork, I also take part in some coding, translations, and obviously testing. I enjoy all of it in general. It is a great way to make computing easier and more pleasant for other less experienced users.

Actually, to me, my most valuable contribution has been encouraging people to use openSUSE and contribute to it, while doing my best to help them out when needed. Otherwise, I wouldn’t have been able to provide anything on my own because I rely on community to actively help me out with their judgment; just as I do help them out with mine.

Side projects

Outside of openSUSE I also work on Pixelfed, some Discord distros collaboration (artwork for Fedora and Gentoo discords on top of openSUSE one) and more recently been working on User Interface (UI) design for SuperTuxKart and some custom tiles for OpenSkyscraper in order to replace injecting the EXE file (but gamedev is hard


Thursday
06 June, 2019


Michael Meeks: 2019-06-06 Thursday.

21:00 UTCmember

face
  • Mail chew, build testing, code reading variously. Re-factored clipboard logic in master.
  • Read theregister while unit tests are running; Collabora has done a huge amount of work (and continues to do so) on behalf of our customers on Document Redaction:
    Paper based redaction

    There are lots of cool features from many individuals and organizations in LibreOffice 6.3 (far more than are listed there too) - but this is an interesting example of how the LibreOffice brand & marketing tends to bury sensible crediting for "the most notable" new feature, in the (otherwise beloved) el reg Then again, Dennis seems to have re-located to France as well.
  • Worked late, babes at music, scouts etc.

face

Three openSUSE Tumbleweed snapshots have been released in the first four days of June, which bring several minor package updates to the rolling release.

The 20190604 snapshot brought babl  0.1.64, which provided some code consistency, gitlab Continuous Integration (CI), autotools and meson build improvements. An accident in naming caused the 0.3.2 version of bubblewrap to become version 0.3.3. However, bubblewrap 0.3.3. did address a Common Vulnerabilities and Exposures (CVE), provided a few smaller fixes and added the JSON Application Programming Interface (API) that allows reading the inner process exit code. GNU Compiler Collection 8 had some updates that included a couple patches with one that makes builds without profiling reproducible. Generic Graphics Library gegl 0.4.16 also added gitlab CI and uses a custom allocator for tile data, which aligns data and groups allocations in blocks; this was achieved on Linux by using the GNU extension malloc_trim to permit forcing invocation of the glibc malloc/free allocators garbage collection function. Oracle’ virtualbox 6.0.8 had a minor maintenance release that fixed a crash when powering off a Virtual Machine without a graphics controller and xorg-x11-server 1.20.5 fixed some input. The snapshot is currently trending at a 96 rating, according to the snapshot reviewer.

Snapshot 20190603 updated Mesa and Mesa-drivers to version 19.0.5 and took care of some core code and drivers. NetworkManager 1.16.2 fixed some wrong permissions of the /var/lib/NetworkManager/secret_key file. Ceph’s minor version update disabled Link Time Optimisation in spec when being used. GNOME 3.32.2 had several package updates and fixes including the fix of a regression that caused the fonts category to go missing. Tumbleweed skipped over the 1.3.0 series of Flatpak directly to version 1.4.0. The major changes since 1.2.4 is the improved I/O use for system-installed applications, and the new format for pre-configured remotes. Glib2 2.60.3 updated translations and provided various fixes to small key/value support in GHashTable. Scripting language php7 7.3.6 added a missing curl_version and fixed several other bugs. The snapshot is currently trending at a 95 rating, according to the snapshot reviewer.

The snapshot that started out the month, 20190601, update the Linux Kernel to 5.1.5 that fixed a data loss bug. Flatpak-builder 1.0.7 fixed some details in how to create platform commits to fix font cache mtime issues. Among the other package updates in the snapshot were GNOME’s image viewer gthumb 3.8.0, ibus-libpinyin 1.11.1, libopenmpt 0.4.5, qalculate 3.2.0, rdesktop 1.8.6, which fixed the protocol code handling new licenses, and yast2-support 4.1.1. The snapshot is currently trending at a 90 rating, according to the snapshot reviewer.


face

I have just done a git push --force-with-lease to bzip2's master branch, which means that if you had a previous clone of this repository, you'll have to re-fetch it and rebase any changes you may have on top.

I apologize for the inconvenience!

But I have a good excuse: Julian Seward pointed me to a repository at sourceware where Mark Wielaard reconstructed a commit history for bzip2, based on the historical tarballs starting from bzip2-0.1. Bzip2 was never maintained under revision control, so the reconstructed repository should be used mostly for historical reference (go look for bzip2.exe in the initial commit!).

I have rebased all the post-1.0.6 commits on top of Mark's repository; this is what is in the master branch now.

There is a new rustify branch as well, based on master, which is where I will do the gradual port to Rust.

I foresee no other force-pushes to the master branch in the future. Apologies again if this disrupts your workflow.

Update: Someone did another reconstruction. If they weave the histories together, I'll do another force-push, the very last one, I promise. If you send merge requests, I'll rebase them myself if that happens.


face

Revamping Cloud and Monitor We’re getting closer to completing the Bootstrap migration and this time, we have revamped the Cloud and Monitor pages. This is part 7 of a series of posts about revamping the user interface of OBS. We started off with the Package pages in October 2018, moved on to the Project, User and Group pages in December 2018, continued with the Request pages in February 2019 and migrated the Configuration pages in...


Wednesday
05 June, 2019


Michael Meeks: 2019-06-05 Wednesday.

21:00 UTCmember

face
  • Practice with M, mail, patch reading, calls, booked hotel for the interesting OW2Con next week. Worked late.

face

Today I had a very pleasant conversation with Julian Seward, of bzip2 and Valgrind fame. Julian has kindly agreed to cede the maintainership of bzip2 to me.

Bzip2 has not had a release since 2010. In the meantime, Linux distros have accumulated a number of bug/security fixes for it. Seemingly every distributor of bzip2 patches its build system. The documentation generation step is a bit creaky. There is no source control repository, nor bug tracker. I hope to fix these things gradually.

This is the new repository for bzip2.

Ways in which you can immediately help by submitting merge requests:

  • Look at the issues; currently they are around auto-generating the version number.

  • Create a basic continuous integration pipeline that at least builds the code and runs the tests.

  • Test the autotools setup, courtesy of Stanislav Brabec, and improve it as you see fit.

The rustification will happen in a separate branch for now, at least until the Autotools setup settles down.

I hope to have a 1.0.7 release soon, but this really needs your help. Let's revive this awesome little project.


Tuesday
04 June, 2019


Michael Meeks: 2019-06-04 Tuesday.

21:00 UTCmember

face
  • Mail chew, ticket review & estimation, tech mgmt. call, built ESC proto-agenda. Sync. with Philippe. Dinner, 'cello and math's with M. put H. to bed. Read a lot of disappointing Chrome clipboard code, seems I'm far from alone in that regard. Still, a synchronous population of the complete clipboard from the get-go is also quite silly. The solution will have to be in the HTML.

Monday
03 June, 2019


Michael Meeks: 2019-06-03 Monday.

21:00 UTCmember

face
  • Mail chew, sync with Kendy, team calls, status report. Customer call(s). Attempted to minute an All Saints PCC meeting in the evening, iteresting.

<- Current blog entries