My thoughts on Slackware, life and everything

Month: June 2016

June ’16 security fixes for Adobe Flash

adobe_flash_8s600x600_2Earlier this week, there was already some talk about a zero-day exploit in Flash for which Adobe would be releasing a fix. And indeed they issued a Flash player  security update yesterday.

The updated plugin for the Chromium browser (chromium-pepperflash-plugin) has the version number 22.0.0.192 while the plugin for Mozilla browsers (flashplayer-plugin) moves up a tiny bit; to version 11.2.202.626.

Slackware packages for these Flash plugins are available for download & install in the following locations:

Note that the Chromium plugin comes as a 64bit package only. Google has ceased providing 32bit versions of their Chrome browser from which I take the plugin library. I do offer a 32bit Chromium package of course; it’s just lacking the proprietary 32bit plugins now (pepperflash & widevine).

If you are using the slackpkg+ extension for slackpkg, then you just run “slackpkg update && slackpkg upgrade flash”. Alternatively, you can subscribe to my repository RSS feed to stay informed of any updates.

Eric

Slackware Live Edition 1.1.0 comes with the latest Plasma5 on ISO

blueSW-64pxISO images for Slackware Live Edition based on the liveslak 1.1.0 scripts and using Slackware-current dated “Wed Jun 15 06:13:17 UTC 2016” are available as of now (I missed the 3rd update Pat made to slackware-current today but I think that’s acceptible). The Plasma5 variant contains the latest packages which I made publicly available earlier today.

Please give one or more of these ISO’s a test run, at least the full Slackware one (to check for Slackware 14.2 showstoppers) and the Plasma5 variant. If you already employ a Live USB stick that you do not want to re-format, you should definitely try the new “-r” parameter to the “iso2usb.sh” script that allows you to refresh the liveslak files on your USB stick without touching your custom content.

Remember, to find out what’s on the ISO you downloaded, try this command:

$ isoinfo -d  -i your_downloaded.iso | egrep “Volume id|Publisher id|Data preparer id|Application id”

And if you want to know what ISO was used to create your USB stick, check the content of the /.isoversion file in the root of its Live partition (partition number 3).

As usual, you will find ISO images for a full Slackware (64bit and 32bit versions), 64bit Plasma5 and MATE variants and the 700MB small XFCE variant (64bit and 32bit versions).

The changes between liveslak 1.0.1 and 1.1.0

  • Add ‘-r’ option to iso2usb.sh to refresh an existing Live USB stick with content from a newer Live ISO image file.
  • New boot parameter ‘nop=wipe’ allows you to wipe persistent data in case of boot- or usability issues.
  • Deal properly with new kernel drivers that are introduced to the Live OS, such as when using the boot parameter ‘load=broadcom_sta’. Now the kernel can use them immediately after boot.

Download the ISO images

The ISO variants of Slackware Live Edition are: SLACKWARE, XFCE, PLASMA5 and MATE. These ISO images (with MD5 checksum and GPG signature)have been uploaded to the master server (bear) and should be available on the mirror servers within the next 24 hours.

Download liveslak sources

The liveslak project can be found in my git repository: http://bear.alienbase.nl/cgit/liveslak/ . That’s all you need to create a Slackware Live ISO from scratch. Documentation for end users and for Live OS developers is available in the Slack Docs Wiki.

Have fun! Eric

KDE 5_16.06 for Slackware -current

plasma5_startupIt’s that time of the month again, where the three main software collections of the KDE community have had new releases. Time to package and release for Slackware!

KDE 5_16.06 is the June release of the combined KDE Frameworks 5.23.0, Plasma 5.6.5 and Applications 16.04.2 for Slackware.

plasma5_about_distro

You will certainly have noticed that I am still using the words “current” and “testing” in the URLs for my Plasma5 Slackware repository. With the release of Slackware 14.2, I want to change that. The Plasma5 repository on http://alien.slackbook.org/ktown/ will move from “current/testing” to “14.2/latest” to indicate that I no longer consider Plasma5 a “testing ground”. Plasma5 is production-ready as far as I am concerned. When a new iteration of slackware-current starts rolling post-14.2 I will see if there is again something that needs “testing” otherwise “current” and “14.2” will become equal in the repository for the time being.

What’s new in KDE 5_16.06?

This upgrade should be straightforward if you already have Plasma 5 installed. See below for install/upgrade instructions. And if you want to check it out before installing, I am currently generating new Live ISO’s for all variants, PLASMA5 included. They will become available at http://bear.alienbase.nl/mirrors/slackware-live/latest/ soon. Check the timestamp of the “slackware64-live-plasma5-current.iso” ISO.

Installing or upgrading Frameworks 5, Plasma 5 and Applications

You can skip the remainder of the article if you already have my Plasma 5 installed and are familiar with the upgrade process. Otherwise, stay with me and read the rest.

As always, the accompanying README file contains full installation & upgrade instructions. Note that the packages are available in several subdirectories below “kde”, instead of directly in “kde”. This makes it easier for me to do partial updates of packages. The subdirectories are “kde4”, “kde4-extragear”, “frameworks”, “kdepim”, “plasma”, “plasma-extra”, “applications”, “applications-extra” and “telepathy”.

Upgrading to this KDE 5 is not difficult, especially if you already are running KDE 5_16.04. You will have to remove old KDE 4 packages manually. If you do not have KDE 4 installed at all, you will have to install some of Slackware’s own KDE 4 packages manually.

What I usually do is: download all the ‘ktown’ packages for the new release to a local disk. Then run “upgrade –install-new” on all these packages. Then I check the status of my Slackware-current, upgrading the stock packages where needed. The slackpkg tool is invaluable during this process of syncing the package installation status to the releases.

Note:

If you are using slackpkg+, have already moved to KDE 5_16.05 and are adventurous, you can try upgrading using the following set of commands. This should “mostly” work but you still need to check the package lists displayed by slackpkg to verify that you are upgrading all the right packages. Feel free to send me improved instructions if needed. In below example I am assuming that you tagged my KDE 5 repository with the name “ktown_testing” in the configuration file “/etc/slackpkg/slackpkgplus.conf“):
# slackpkg update
# slackpkg install ktown_testing (to get the newly added packages from my repo)
# slackpkg install-new (to get the new official Slackware packages that were part of my deps previously)
# slackpkg upgrade ktown_testing (upgrade all existing packages to their latest versions)
# removepkg xembed-sni-proxy ktux amor kde-base-artwork kde-wallpapers kdeartwork (they don’t exist in the repo anymore)
# slackpkg upgrade-all (upgrade the remaining dependencies that were part of my repo previously)

And doublecheck that you have not inadvertently blacklisted my packages in “/etc/slackpkg/blacklist“! Check for the existence of a line in that blacklist file that looks like “[0-9]+alien” and remove it if you find it!

Recommended reading material

There have been several posts now about KDE 5 for Slackware-current. All of them contain useful information, tips and gotchas that I do not want to repeat here, but if you want to read them, here they are: http://alien.slackbook.org/blog/tag/kde5/

A note on Frameworks

The KDE Frameworks are extensions on top of Qt 5.x and their usability is not limited to the KDE Software Collection. There are other projects such as LXQT which rely (in part) on the KDE Frameworks, and if you are looking for a proper Frameworks repository which is compatible with Slackware package managers such as slackpkg+, then you can use these URL’s to assure yourself of the latest Frameworks packages for Slackware-current (indeed, this is a sub-tree of my KDE 5 “testing” repository):

Where to get the new packages for Plasma 5

Download locations are listed below (you will find the sources in ./source/5/ and packages in /current/5/ subdirectories). If you are interested in the development of KDE 5 for Slackware, you can peek at my git repository too.

Using a mirror is preferred because you get more bandwidth from a mirror and it’s friendlier to the owners of the master server!

Have fun! Eric

Ten years of SlackBuilds.org

sbologo This week marks the tenth anniversary of SlackBuilds.org.

Many of us will remember the time when a true Slacker did not bother herself with build scripts. The “configure && make && make install” mantra was at the forefront of everyone’s mind when it came to installing new software. Slackware made this possible. Unlike the other big distros, the Slackware package management did (and does!) not get in your way. If you want to compile your software by hand, bypassing the package management ‘database’ (which in Slackware is nothing more than a directory), then nothing or no one is stopping you.

But when you compile and upgrade a lot of software, or when you have to re-install your computer, all that hand-compiled stuff is quite tricky, if not pretty hard, to replicate unless you wrote down all that you did. And if you had been writing your compile and build steps down anyway, then it was a small step towards formalizing this documentation into an actual build script. And Slackware was (mostly) developed using build scripts, called “SlackBuilds” because of these scripts’ extension “.SlackBuild”. So, these scripts used by Slackware became gradually more common among users of Slackware. And once you had compiled a package using a build script, other advantages would become obvious: if you owned more than one computer you did not have to compile your software twice. You would transfer the package to your other computer(s) and use the Slackware ‘pkgtools’ to install or upgrade the package. Fast and deterministic.

In those days, there was a web site called “linuxpackages.net” – formerly known as “linuxmafia.org” but I guess that name had a negative vibe to it. Linuxpackages.net would offer binaries for Slackware, nicely packaged in case you were not inclined to compile stuff yourself. The site was pretty popular, but it had a major disadvantage: the packages did not have a proper quality control and it would happen ever so often that people’s computers broke after installing one of their packages. The ‘LP‘ packages were apparently built on unclean systems, introducing unknown dependencies, and the build scripts would often be absent. Good old NoobFarm has a lot of nice LP related quotes taken from the regular Slackware meeting places on the Net.

Also in those days, somewhere end of May, beginning of June 2006 (don’t have exact records of our first contact) there was a relative Slackware freshman called Robby Workman. He and his pal Erik Hanson (who initiated the GWare project, a Gnome build for Slackware after Slackware dropped that Desktop Environment from the distro) envisioned a web site where one would be able to find – not binaries, but SlackBuild scripts. These scripts would be quality-tested by a small team of people who carried trust in the community. High-quality scripts and skilled, trustworthy people at the helm, this would certainly gain some traction and be generally beneficial to the Slackware ecosystem. Robby and Erik contacted me because I knew Pat, some of my work had landed in Slackware releases, and my SlackBuilds repository (scripts plus packages) was already quite well-known but not well-organized (no proper ChangeLog.txt).

At that time I was not yet a part of the Slackware coreteam by the way – that would take until August of that same year. Robby and Erik asked me if I would be interested to join them and become part of the admin team of this new SlackBuilds.org (SBo) project they had in mind and I said “yes”. We talked this through with Pat and in particular, we discussed our scope. We wanted Pat to be sympathetic of our cause and we did not want to become a possible burden to him on the long run. For that reason, the golden rule was established that all SlackBuild entries at slackbuilds.org would follow the style of the “mother” scripts. Basically, a SBo script should be transferable into the Slackware core distro without feeling out of place. I think it was this rule that made Pat give the nod of approval. Just think of the scenario where the SBo site would become popular using a style of SlackBuild scripts that did not look at all like Slackware’s own. There was a good chance that people would start demanding that Slackware must adopt the scripting style of SBo. This was a big no-no.

In contrast, my own SlackBuild scripts do a whole lot more than a basic Slackware script – notably my scripts will download the source tarballs for you. You will not find any of those scripts on slackbuilds.org for the exact reason I just explained.

I dug through my email logs and the oldest record I still have is this, the first test email of the then already functional project:

testing_SBo

Coïncidentally this day (8 June 2006) also marks the start of formalizing my own SlackBuilds repository. I had been working on my gen_repos_files.sh script since April 2006 and used it for the first time on June 8th. The first entry in the ChangeLog.txt says:

+--------------------------+
Thu Jun  8 15:10:57 UTC 2006
Starting the ChangeLog.txt for Alien's SlackBuild repository.

Ten years have passed since those days, and SlackBuilds.org has brought a lot of good to Slackware. SBo submissions find their way into the Slackware distro core quite regularly. Which is nice, but more important is the fact that users of the distro are no longer tied to the “small” (other distros’ judgement) official repository but can tap into a vast repository of high-quality build scripts. I don’t think that anybody can concieve today of the idea that there would not be a SlackBuilds.org repository.

The fact that the SlackBuild scripts of SBo remained so basic allowed several “third party” tools to be conceived that wrap themselves around the SBo content as it were, providing queue control and automation for the process of building your own packages as well as all their dependencies. Well-known examples are sbopkg, sbotools and slpkg. The queue management feature is special. Slackware is a distro that does not concern itself with dependency management – you install the full distro, it is small enough, and that fulfills all the dependencies. Working with 3rd party packages and scripts is different though, and these tools around SBo have found ways to build and install all the required dependencies along with the package that you want to have in the first place. All of that is made possible by the SBo “info” file which is part of every submission. It contains the essential information about the software that is to be packaged, it is easily parseable and therefore ideal source material for the 3rd party tools:

PRGNAM="name of application"
VERSION="version of application"
HOMEPAGE="homepage of application"
DOWNLOAD="direct download link(s) of application source tarball(s) arch-independent or x86"
MD5SUM="md5sum(s) of the source tarball(s) defined in DOWNLOAD"
DOWNLOAD_x86_64="direct download link(s) of application source tarball(s), x86_64 only"
MD5SUM_x86_64="md5sum(s) of the source tarball(s) defined in DOWNLOAD_x86_64"
REQUIRES="%README%"
MAINTAINER="name of SlackBuild script maintainer"
EMAIL="email address of author"

I have since retired as a SBo admin, although I still hang out in the users- and admin-channels on IRC. Others have come and gone as well, and the current team is still going strong (and with Robby & Erik still at the wheel). I admire these guys a lot, because just look at the size of the repository! The package database for Slackware 11.0 (which we started with in 2006) contains 429 submissions. Compare that number to the Slackware 14.1 repository’s 5745 entries. That’s more than 13 times as many! And now imagine that this small team (the admin team has grown a bit bigger since the beginning but not much) still QA’s every script by compiling it and checking the outcome. On top of that, the team has to test all these scripts against the upcoming Slackware 14.2 release and make sure that there will be a high-quality SBO repository for Slackware 14.2 when that gets released. The project is using GIT to manage this transition process. Learning about and understanding git is one of the most important things that I took from the SBo project.

These guys need your praise and support. Go tell them in the slackbuilds-users mailing list!

 

© 2024 Alien Pastures

Theme by Anders NorenUp ↑