My thoughts on Slackware, life and everything

Tag: repository (Page 1 of 2)

Repository purge coming up soon-ish

After I built a fresh Avidemux (see previous post) I realized how many old packages I still have in my repositories. They are taking up space on many server mirrors.

I have decided that I will start a cleansing process, a purge if you want, of all the older stuff. The reason is not just disk space of course. It’s my realization that there may be vulnerabilities in these old packages that I never addressed; and I really hope that people have migrated their machines to Slackware 14.2 (servers or conservative desktop users) or went with -current (modern desktop users, let’s call those).

From time to time, you need to clean house. I myself am infamous for not throwing away anything… just take a look at my attic. So these packages will be gone from online servers, but live on in my own local package archive.

Because of the time involved (manual checks to ensure that I don’t remove too much by mistake) this will be done in several ‘waves’. My repositories already don’t have packages for Slackware releases older than 13.37 and tomorrow I will purge all packages targeting Slackware 13.37. Later, that will be followed by a purge of all packages for Slackware 14.0, and finally those that were meant for Slackware 14.1 will also be removed. I will stick with package support for Slackware 14.2 (and 15.0 when that gets released) and always -current.

In case you still run one of these older versions of Slackware, you would want to make local copies of the following repositories ASAP:

And also these:

I will leave the multilib repositories ( and its mirrors) untouched.


Introducing slackpkg+, an extension to slackpkg for 3rd party repositories

I want to introduce you to a tool written by Matteo Rossini (nicknamed zerouno of the Italian community and contributor of several SlackBuild scripts at as well as creator of the Slackware package search site with some serious contributions from phenixia2003, author of compat32pkg.

The tool is “slackpkg+“. It is not a stand-alone piece of software. In fact, it is an extension to Slackware’s package manager “slackpkg“. I will first describe the strengths of “slackpkg” and then come to the reasons why “slackpkg+” was written.

Slackpkg itself is a wrapper around the Slackware pkgtools (installpkg, upgradepkg, removepkg) with built-in package search capabilities and very useful when you want to keep your Slackware installation up to date. It was written with a modular design in mind: it can be extended with new functionality by adding new or extending existing functions in the “/usr/libexec/slackpkg/functions.d/” directory.

Slackpkg is my preferred tool for system upgrades (i.e. upgrading from one Slackware release to the next). People who do not use slackpkg usually have to do much more handywork like reading ChangeLog.txt entries for package additions, updates and removals, and/or follow the official Slackware guideline as found in “UPGRADE.TXT“. One disadvantage of the instructions found in UPGRADE.TXT is that the suggested “upgradepkg –install-new *.t?z” command will install every package you did not yet have installed – not just the packages that were introduced in the latest Slackware release but also the packages which you did not want to install anyway in the past.

Slackpkg allows you to keep full control over the packages that get installed, by showing you lists of candidate packages for every action you want to perform. You can de-select any package you do not want to be acted upon.

So far its strengths. The most heard “complaint” about slackpkg is that it will install and upgrade packages only from official Slackware repositories – it does not support 3rd party package repositories. This is why some users switch to other (unofficial) package managers like slapt-get, which do support 3rd party repositories. Slackware spin-offs like Salix and Vector use slapt-get. Slackpkg also does not allow you to keep a Slackware multilib installation correctly updated. The community tool compat32pkg was written for that purpose.

Both these issues (3rd party repository support and multilib support) are addressed in the slackpkg+ extension to slackpkg.

Slackpkg+ is NOT a new tool with new commands. Because it extends slackpkg, you can continue to use the well-known slackpkg commands after adding your 3rd party repository configuration:

# slackpkg update gpg
# slackpkg update
# slackpkg install openjdk
# slackpkg upgrade-all


The slackpkg+ extension also extends the search functionality in slackpkg:

# slackpkg search vlc    


The list below shows all packages with name matching "vlc".

[ Status           ] [ Repository               ] [ Package                                  ]
   installed           alienbob                     phonon-vlc-0.6.0-x86_64-1alien            
  upgrade              alienbob                     npapi-vlc-20130818-x86_64-1alien --> npapi-vlc-20130408-x86_64-1alien  
  upgrade              alienbob                     vlc-20130819-x86_64-1alien --> vlc-2.0.8-x86_64-1alien  
   installed           alienbob_current             npapi-vlc-20130818-x86_64-1alien          
   installed           alienbob_current             vlc-20130819-x86_64-1alien                
  upgrade              restricted                   npapi-vlc-20130818-x86_64-1alien --> npapi-vlc-20130408-x86_64-1alien  
  upgrade              restricted                   vlc-20130819-x86_64-1alien --> vlc-2.0.8-x86_64-1alien  
   installed           restricted_current           npapi-vlc-20130818-x86_64-1alien          
   installed           restricted_current           vlc-20130819-x86_64-1alien                

You can search specific files using "slackpkg file-search file".

You probably noticed that the package “vlc” is listed several times in this search exxample. That happens because I have this package in several repositories. You can (as shown further down) configure slackpkg+ with the correct priority in which these repositories are consulted when installing/upgrading software, so that the correct package will always be used.

Let me show you how I use slackpkg+ to maintain my computers.

I run Slackware-current 64-bit, with multilib added. I install my packages from multilib-current as well as my Slackware 14.0 package repository. Sometimes, I create a package specifically for Slackware-current (such as calibre, vlc, …) because the Slackware 14.0 version of that package will not work on Slackware-current. In such a case I want slackpkg to install the -current package and not the 14.0 package.

This is my configuration file “/etc/slackpkg/slackpkgplus.conf”:

PKGS_PRIORITY=( multilib:.* restricted_current:.* restricted:.* alienbob_current:.* alienbob:.* ktown:.* )
REPOPLUS=( slackpkgplus multilib ktown alienbob alienbob_current restricted )

A breakdown of these lines:

  • You will notice that I have a local webserver running in my LAN (IP address but you can use any public webserver which hosts these repositories. Having the repositories mirrored locally in the LAN has benefits for download speeds of course.
  • The variable “SLACKPKGPLUS” determines whether the functionality of slackpkg+ will be enabled at all. If you set it to”off” then slackpkg will not use any of the new code. The default is “on”
  • The “MIRRORPLUS” variables define an array of 3rd party repositories which you want slackpkg to know about.The array indices of the MIRRORPLUS array (like ‘alienbob’, ‘restricted’, ‘ktown’, etc…) are used in other variables, as will be explained next:
  • The “REPOPLUS” variable defines which of the 3rd party repositories you have defined in MIRRORPLUS are actually actively used. The order in which the repositories are mentioned is not important.
  • That repository order is important in the “PKGS_PRIORITY” variable. With this variable, you can force priority for certain repositories, or even for individual packages in these repositories. For instance, having “multilib:.*” listed first, means that my multilib package always have priority over the Slackware versions of these packages (gcc and glibc to be specific). Also, by defining the order “alienbob_current:.* alienbob:.*” I will ensure that when a package (such as calibre) is found in both repositories, slackpkg will install the one from the “-current” repository. The “.*” behind the repository’s name is a wildcard meaning “any package“. If you want you can make that more specific, like “restricted:vlc” which means “the vlc package in the ‘restricted’ repository“.


You will probably have added 3rd party packages to your slackpkg blacklist. When you install slackpkg+ you should of course remove those blacklist lines! If you don’t, then slackpkg will never show those blacklisted packages…

For instance, the lines you need to remove from “/etc/slackpkg/blacklist” in order to let slackpkg/slackpkg+ manage my packages, are:


Similar to enabling a Slackware repository for your specific Slackware version and architecture in /etc/slackpkg/mirrors , you will add additional 3rd party repositories in /etc/slackpkg/slackpkgplus.conf . Take good care that you only add repositories which contain packages compatible with your particular version and architecture of Slackware ! The example repositories which I showed you above are suited for my Slackware64-current-with-multilib installation. If you are running Slackware 14.1 you should add repositories that offer packages for Slackware 14.1.

As a rule of thumb, do not mix packages for different versions of Slackware. Specifically, do not attempt to install packages for a more recent version of Slackware than you have installed on your computer. Most packages built for an older release of Slackware will still work on newer versions of Slackware (as an example, Slackware64-current contains several packages that have not changed since 13.0 and those still work).


The slackpkg tool parses the Slackware ChangeLog.txt to determine which packages are being added to Slackware. It looks for strings like “Added.” in the changelog when you run the command “slackpkg install-new”. This functionality does not work for 3rd party repositories. That means I can not simply run “slackpkg upgrade kde” to get my newest KDE “ktown” release installed – any package which is not present in Slackware itself, will not be installed with that command. On the other hand; keeping your “ktown” installed packages up to date afterwards, is easy with slackpkg+ because it will detect any upgrade to individual packages. .

The “slackpkg+” extension has its homepage on You can find more of slackpkg+ here:

If you have a set of packages that are not part of any repository yet, and you want to create your own slackpkg+-compatible repository for them, you should check out an older article on this blog: . In there you will find an explanation about how to use my “” script.

Have fun! Eric

KDE SC 4.4.5 for Slackware 13.1

Well folks, we had short discussion about who would do the first build of KDE SC 4.4.5 for Slackware. But since Pat is on other duties at the moment, I took the opportunity to release a set of packages for the recently released KDE Software Compilation 4.4.5. ( KDE people, there is a lack of Slackware team members at Akademy this year… let us know in advance next year and I will make an effort to be there! )

Anyway, you can find the packages for Slackware 13.1 (32-bit as well as 64-bit) in my ktown repository. This time, there are several non-KDE packages which received an update, Qt being the largest of those. Qt 4.6.3 is supposed to fix a few bugs that affect KDE’s plasma desktop. You will find the updated dependencies in the “deps” directory.

There is a README which explains the straight-forward  installation/upgrade steps.

I expect that slackware-current will follow suit (soon-ish… perhaps in one of two weeks?) with an official set of packages from Pat, and with the same updates to non-KDE packages which should make the upgrade from my packages to slackware-current real easy.

I invite you to check out my KDE packages  before that time (your feedback gives us the chance to iron out any wrinkles before KDE 4.4.5 enters slackware-current).

In case you had not noticed earlier, there are koffice-2.2.0 packages too, inside the KDE 4.4.5 directory tree. I had built them after I uploaded KDE 4.4.4 but they never got a real good announcement. By the way, if you subscribe to my ktown RSS feed, you will not miss out on updates like that!

Now that koffice-2.2.1 is about to be released, I hope that Pat uses that for the next Slackware update.

Have fun!


Asleep at the wheel, or…?

I realize that I have not been updating my SlackBuilds repository at all that much lately. That does not mean that I stopped caring! On the contrary, I’d say.

Apart from several small-ish updates to articles in my Wiki (thanks for the feedback which enables me to improve the existing pages!) I have been busy in the background, following the progress of VLC developers who are working towards a 0.9.9 and eventually a 1.0.0 release, and in particular laboring on packages for the official Slackware tree. There are KDE 4.2.1 and XFCE 4.6.0 (both not officially released yet). And be prepared to see some other major updates in slackware-current as well, soon.

I do hope to get some time next month to skim through my repository and update packages that are popular. I was thinking about wine, ekiga, ffmpeg and adding avidemux, but I am open to suggestions about what other packages would need my immediate attention.

Cheers, Eric

Sixty four bits

Question to the readers of this blog who are also users of my SlackBuild scripts…

Who would be interested to see 64bit versions of the packages I have in my repository? Currently I have built and tested “x86_64” packages for ffmpeg, flashplayer-plugin, fontforge, gcc34, mozilla-nss, mplayer, mplayerplug-in, qemu, recordmydesktop, sshfs-fuse, tightvnc, vlc and yasm. Some are simply re-using my unmodified SlackBuild scripts but some were painful to get right on x86_64.

I am a bit hesitant to add them to the repository, (1) because there is no 64bit Slackware and (2) it would mean again higher storage requirements which force me to remove packages for Slackware 11 and older.

The packages will work on slamd64, and probably on bluewhite64 too. I kept the lib64 approach dictated by the Filesystem Hierarchy Standard (fhs) which is what slamd64 uses as well.

I would appreciate if you leave a comment- whatever your opinion.

Cheers, Eric

« Older posts

© 2024 Alien Pastures

Theme by Anders NorenUp ↑