My thoughts on Slackware, life and everything

Tag: glibc (Page 1 of 4)

Slackware-current has absorbed my multilib gcc and glibc packages

Ever since the birth of 64-bit Slackware in 2009, I have been maintaining a multilib repository. Today, 15 years later, things are changing!

You may know it or not, depending on your age, but I have created 64-bit Slackware from scratch late 2008 and early 2009 as a project to deal with an inguinal hernia which was really painful, and the subsequent surgery caused me to be stuck to a bed for a while. I re-wrote the SlackBuild for every package in Slackware, and created SlackBuild scripts for a whole lot of other packages that had nothing more than a ‘build’ script. I also wrote all scripts in such a way that they were capable of building 32-bit and 64-bit Slackware from the same source. Pat would not have accepted the burden of having to maintain two trees instead of one.

Not everybody needs a multilib setup, but historically there has been a need, particularly to be able to run old proprietary programs that were available only as 32-bit binaries. And then there’s the whole Microsoft Windows ecosystem of 32-bit commercial programs and games, to be run in emulators such as Wine and a platform like Steam.

I had setup the 64-bit Slackware to be “multilib-ready”. It was a pure 64-bit system but by swapping a few packages (glibc and gcc) and adding a 32-bit compatibility layer, the 64-bit Slackware would be able to run and compile 32-bit binaries. That process has always been reversible too.
Pat was clear about his own goals: he wanted the new platform to be a pure 64-bit Slackware when he was going to publish it. I had no problem with that,  and thus alien’s multilib repository was born.

As said, this worked extremely well for the past 15 years. Pat would give me a heads-up whenever he was planning an upgrade to either the gcc or glibc packages, so that I would have time to prepare my own multilib versions and could release those on the heels of the official Slackware update.
Lately, Pat and me discussed our multilib collaboration occasionally and I saw his opinion shift bit-wise 🙂
Today, Pat has pushed an update to Slackware-current which effectively merges my multlib versions of gcc and glibc SlackBuild scripts with the official distro versions. This means that my own gcc and glibc multilib packages are obsolete, and I have removed them from the ‘current’ directory of the multilib repository.

In 64-bit Slackware-current you finally have multilib-capable gcc and glibc packages! All you need to add to Slackware64 now is my collection of ‘compat32’ packages. And if you want, use the massconvert32.sh script in my compat32-tools package to create these ‘compat32’ packages yourself. It does not involve any compilation – all that happens is that some official Slackware 32-bit packages are downloaded, cleaned-up a bit and then re-packaged into ‘-compat32’ versions.

Thanks Pat!

Security updates for glibc and chromium

Two reminders about security related package updates in my repositories.

Google released an update to its chromium sources last week and I built packages for Slackware (14.2 and -current). You may already have seen them appear if you follow the ChangeLog.txt for my repository.
Get Chromium 97.0.4692.99 now, because it addresses one critical vulnerability (CVE-2022-0289): https://slackware.nl/people/alien/slackbuilds/chromium/

The GNU C Library (glibc) package for Slackware was rebuilt and hence also my multilib packages for glibc needed an update, after two security vulnerabilities were fixed (CVE-2021-3998 and CVE-2021-3999).
The multilib glibc packages (release 2.33, build ‘5alien’) can be found at http://www.slackware.com/~alien/multilib/current/ .

 

Eric

Slackware 15.0 alpha1

Hold the press! There’s good news on Slackware development front.
Slackware 14.2, the last stable release, saw the light on 30 June 2016. Since then, it has received many security patches but nothing has changed functionally and although 14.2 is super stable, it is also getting stale, in particular its default KDE desktop.
In all that time since the release of Slackware 14.2, the distro has been heavily worked on, and the slackware-current development release is a joy to work with, containing the latest tools and desktop environments.

The frequent and sometimes intrusive updates to -current are keeping the less knowledgeable Slackware users at bay, they prefer 14.2 since that requires minimal maintenance and won’t break after a careless upgrade.
But after almost 5 years of rising anxiety, there is now real movement toward a new stable release.

From the ChangeLog.txt today:

Mon Feb 15 19:23:44 UTC 2021
Here we go again... upgraded to glibc-2.33 and one last mass rebuild for
Slackware 15.0. The only packages upgraded in this batch are glibc and the
kernels - everything else is just a rebuild against the new glibc. Not
rebuilt in this batch: devs (best to just leave this alone), glibc-zoneinfo,
kernel-firmware, rust, linux-faqs, linux-howtos, aspell-en, mozilla-firefox,
mozilla-thunderbird, and seamonkey. There's a new Rust compiler but Firefox
and Thunderbird will need to be patched to use it, so we'll hold off on
those until they're ready for the new Rust either with patches or new
upstream releases. Until we have that and a few more scheduled upgrades I'm
not quite ready to call this beta yet, but you can call it 15.0-alpha1. :-)
Cheers!

I will do my best to update the multilib repository ASAP, I have multilib versions of the rebuilt gcc and upgraded glibc packages ready but occupied with other stuff at the moment.

Have fun upgrading 1550+ packages… again.
Eric

Some thoughts on the recent updates in Slackware-current

 Last week, a new LTS kernel (4.9.26), new glibc (2.25) and a new gcc compiler suite (7.1.0) landed in Slackware-current. Note that gcc no longer contains the Java compiler (gcj): subsequently Slackware’s gcc-java package has been removed from slackware-current.
We are at the head of the herd again folks. There is not yet any other distro that ships with the gcc-7 compiler by default. This will certainly pose some challenges for people who compile their stuff themselves – the SBo team warned their community about scripts that require patches to compile against gcc-7.

I have my set of challenges myself too… until now, I have not been able to compile the multilib versions of the gcc compiler suite. That’s infuriating, I can tell you. Specifically, I have issues with brig, gnat, go and objc compilers; the 7.1.0 versions of c and c++ compilers are just fine. I hope to resolve this soon-ish… until then, you will have to wait for new multilib compilers. If you really need a gcc 7.1.0 compiler (for instance, to compile a kernel module) I suggest that you (temporarily) switch to Slackware-current’s gcc 7.1.0 packages. Running your multilib system is of course not affected by this – gcc is only needed to compile stuff. I will probably release glibc-2.25_multilib packages ahead of the problematic gcc multilib packages to give you at least something.

Another interesting addition is lame. After the last Fraunhofer MP3 patent expired on 16 April 2017, the doors were opened to enable MP3 encoding support in Slackware. Several packages have been recompiled to take advantage of the new MP3 encoding capability (cdrdao, sox, ffmpeg, MPlayer, audacious-plugins) and the gstreamer packages were updated for good measure.

I have added ‘lame’ to the ‘massconvert32.sh‘ script of my compat32-tools package and updated the set of “compat32” packages in my multilib repository.

Multilib glibc patched for GHOST vulnerability (CVE-2015-0235)

There was some unrest about the most recent glibc update in the stable releases of Slackware (slackware-current excluded). Glibc was patched against a new vulnerability, CVE-2015-0235, for which the only known exploit currently is in the MTA Exim (software which is not part of Slackware) and an exploit for this vulnerability is difficult to write apparently. I usually am quite fast in following up on Slackware updates for gcc and especially glibc. This time, I was busy with answering questions about the new KDE 5 at night, and buried in shit at work during the day.

Nevertheless, when there were no updated multilib versions of glibc the next day, some people asked when they could expect a patched package. Others were less polite and demanded updated packages. That sucked.

Here is where you can find the updated packages:

For the un-initiated: multilib is needed if you want to use binary-only 32-bit software on 64-bit Slackware. Examples of that are Skype, Valve’s Steam Client, the WINE emulator, the Pipelight browser plugin, Citrix client etc.

Instructions on how to add or update multilib on your 64-bit Slackware can be found on the Slackware Documentation Project.

Cheers, Eric

 

« Older posts

© 2024 Alien Pastures

Theme by Anders NorenUp ↑