Main menu:

Sponsoring

Please consider a small donation:

 

 

Or you can donate bitcoin:

 

Thanks to TekLinks in Birmingham, AL, for providing colocation and bandwidth.

Page Rank

Fame

FOSS Force Best Blog--2013 Award

Recent posts

Recent comments

About this blog

I am Eric Hameleers, and this is where I think out loud.
More about me.

Search

Subscribe to Blog via Email

Enter your email address to subscribe to this blog and receive notifications of new posts by email.

Join 299 other subscribers

My Favourites

Slackware

Calendar

June 2017
M T W T F S S
« May    
 1234
567891011
12131415161718
19202122232425
2627282930  

RSS Alien's Slackware packages

RSS Alien's unofficial KDE Slackware packages

RSS Alien's multilib packages

RSS Slackware64-current

Meta

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.

Comments

Comment from Didier Spaier
Posted: May 7, 2017 at 15:54

It won’t take long to see again one of the traditional threads about the ETA and/or the numbering of Slackware-next on LQ, I presume 😀

Comment from alienbob
Posted: May 7, 2017 at 15:55

Hehe…
I assume it will be safe to say that as long as you do not see Plasma 5 added to -current, talk about a next release is not yet prudent.

Comment from eleksir
Posted: May 7, 2017 at 21:31

Repeat this mantra continiously (until full enlightenment) if you plasma desktop user:
“Plasma is stable enough. It won’t crash.”

And no, we will not bring your plasma up if it is already down 🙂

Comment from alienbob
Posted: May 7, 2017 at 21:36

eleksir – I assume you have never tried Plasma 5 as of late.

Comment from Ricardo J. Barberis
Posted: May 7, 2017 at 21:56

Good to know, I noticed lame and kernel in the changelog but completely missed the big gcc upgrade… -ENOCOFFEE

Comment from Ricardo J. Barberis
Posted: May 7, 2017 at 22:03

FWIW I’m a very happy Plasma 5 user, sure there’s some crash from time to time, but they’re so rare lately.

The most common is kwin sometimes crashing when under memory pressure, but it restarts itself automatically so it’s not a big deal.

But YMMV depending on your graphics stack, I’m on Intel i915 using UXA acceleration method:

$ cat /etc/X11/xorg.conf.d/20-intel.conf
Section “Device”
Identifier “Intel Graphics”
Driver “intel”
Option “AccelMethod” “uxa”

Whoithout that snippet, the driver uses EXA, which is extremely unstable with my hardware (Intel Core i54200U, Haswell-ULT Integrated Graphics Controller)

Comment from eleksir
Posted: May 7, 2017 at 22:11

Quite correct.
And continuing offtopic thread:
I checked out KDE4 with its plasma-on-a-desktop – well, they try to re-invent the wheel, as of early releases of KDE4. But when authors of this idea actually saw how users and distro-maintainers typically configure their working evironments, KDE4 team drop the original idea and try to adopt plasma back to, well, “normal desktop usage experince”…
And in last stable Slack (14.2) KDE4 looks and works well, if you will not leave it for a long time (say, 1+ month uptime). And it notable memory hog during its normal usage cycle 🙂 KDE3 has less appetite in this case.
Speaking about resource leaks, you can leave Xfce (gtk-2) for more than 4 months and it will no leak whole memory on desktop.
And as i talking about DE, i have to admit, that i’m not currently use any DE. On my work and at home, i use i3-wm, and, btw, humbly hope that it will be considered for inclusion for next Slackware release 🙂 it’s very easy and good alternative for traditional WM like fluxbox, blackbox, that are already in Slackware default base.

Returning back on topic.
I use stable Slack at home, it is x86 flavour and considering to switch to x86_64 in some non-too-distant future. And very fresh gcc with multilib… looks like i’ll get some interesting amusement. And it is time for bringing up builder instance in lxc environment for clean builds.

Comment from Darth Vader
Posted: May 7, 2017 at 23:18

@alien, IF the the KDE4 would be put down certainly in the near future, how about replacing it instead with LinuxPAM?

That would dramatically improve the Slackware usability, while cutting its shipped size to half. Imagine everything sent in a DVD!

Comment from alienbob
Posted: May 7, 2017 at 23:31

Darth Vader… yawn.

Comment from alienbob
Posted: May 7, 2017 at 23:36

Note that I am not opposed to adding PAM. Just don’t expect that I am in favour of dropping KDE.

Comment from John Culleton
Posted: May 8, 2017 at 00:34

Why doesn’t Slack current use Qt4 rather than Qt5? This is more an inconvenience than a deal breaker, but the applications like Scribus moved on to Qt5 many moons ago.

Comment from LoneStar
Posted: May 8, 2017 at 01:22

about gcj… frankly speaking, I always only install gcc and gcc-c++ … all the rest I’ve always found it just a waste of disk space and internet traffic when updating… O:-)

Comment from Widya Walesa
Posted: May 8, 2017 at 11:06

Hello,

I’ve been working on building gcc/glibc multilib from scratch (using native slackware64 gcc/glibc) using your SlackBuild for several days. And about gcc ADA/GNAT, I’m able to build ADA by removing –host option from configure. But I still don’t know what is the effect from removing it from the compiler. But at least I can install the gcc multilib suite.

Comment from Widya Walesa
Posted: May 8, 2017 at 12:59

Forgot to mention, I also using guide from here to build ADA support: http://www.linuxfromscratch.org/blfs/view/svn/general/gcc-ada.html

So yes, I’m installing and using temporary gnat binary from the guide to build ADA lang support in gcc.

Comment from alienbob
Posted: May 8, 2017 at 17:14

Hi Widya,

In the meantime I have been able to compile the gcc 7.1.0_multilib packages and uploaded them to my repository.
The issue I had was two-fold. At least, there were two important things that stopped the errors.
One is to define PKG_CONFIG_PATH. The other was to create a “compat32” version of Slackware’s “gc” package and install that on my system.
With those two changes (compared to older gcc release builds) I was able to compile 7.1.0 compilers using the old gcc 5.4.0 compilers and glibc-2.25_multilib.
I did not have a need for a private version of “isl”.

The ADA compiler (gnat) does indeed require a (temporary) existing ada compiler to be present. That is a chicken & egg problem.

Comment from alienbob
Posted: May 8, 2017 at 17:27

John Culleton; Slackware-current DOES use Qt4.
The Qt5 is something you can add, for instance when you install my Plasma 5 desktop.
There is currently no program in Slackware that requires Qt5. Therefore, it will probably get added as an official Slackware package, the moment some program in Slackware starts requiring Qt5.

Comment from tomac
Posted: May 8, 2017 at 23:09

Today I updated my slackware64(multilib)-current and it’s really great to see gcc 7.1 here. Many, many thanks, Eric, for all your hard work that made this possible!

Pingback from Links 14/5/2017: Linux 4.12 RC1 and KDE Frameworks 5.34.0 | Techrights
Posted: May 14, 2017 at 20:12

[…] Some thoughts on the recent updates in Slackware-current […]

Write a comment