My thoughts on Slackware, life and everything

Tracking development of slackware in git

Something had been nagging me for a long time, and I finally had enough of that itch and decided to deal with it.

As you know, there’s a private and a public side to Slackware’s development. The discussions and decisions are handled internally among the members of ‘the team’ and are not shared with the public at large until an update is done to the ‘slackware-current’ tree which can be found on every Internet mirror.
Thus you have access to the latest state of development always. But for some people it is a compelling idea to be able to access the development updates in a public repository like git – where you can track the changes over time.

A recent discussion on LinuxQuestions brought up the topic of SlackBuild scripts in Slackware-current. The scripts you can find in the -current directory tree on the Slackware mirrors are always the latest version. Sometimes there’s a good reason to want to go back in time and fetch an earlier version. In the thread post with the appropriate number “1337” it is ponce (Matteo Bernardini) who replies with a link to a git repository maintained by Adrien Nader which already has been tracking the development in -current for nearly 8 years!. So it’s quite a convenient way to retrieve a historical version of any script.

Me being me, it’s the existence of that repository which has been nagging me for a couple of years. Why? Because I wondered how it was done. And if I question an issue long enough, I will eventually create my own solution – as a learning exercise of course, but also to give back to the community.

And so, today arrived. I was pondering – if I were to create a git repository for tracking the developments in -current, what would I want in there? Exactly the same as Adrien’s? The answer has been “no” for a while. The most important capability that is missing from Adrien’s repo is that it contains a lot of compressed files that are impossible to read. Think of patches and scripts, and more. So I gave myself the task to implement a git repository with uncompressed files, as an improvement on the original effort. Also, it should track all relevant files in the complete tree, not just in the “./source/” subdirectory. In particular the documentation files (various .TXT files).

The result is a script,, and a repository, .
The repository just had its first commit. For those who want to check out a commit in order to compile a package from there, the script generates another script called ‘‘ and stores that script in the root directory of the repository. When you run this recompress script in the root directory of the repository, it will re-compress all the files that had been un-compressed before committing them to git. That way, a SlackBuild script will find the correct files and will function as intended. Note that you would still have to download the source tarballs from somewhere, because this repository of mine will only track the Slackware-specific files.

I decided that it is prudent and more respectful to not import Adrien’s work into my own repository. The two are similar but different and I think everyone of you can choose which repository suits your needs better.

I have scheduled the above script to run twice a day and update the git repository when new updates become available.
As with all my scripts, this one has a “-h” parameter to explain its usage. Let me know if it – and the git repository – are useful to you.
This particular script may be a bit messy because I have not spent a lot of time polishing it. I hope that’s OK 😉

Have fun!


  1. lamerix


  2. DaveO

    Thanks, I particularly like the log tab which lets you know which packages have changed when with a simple click.

  3. p431i7o

    Great, for people curious to know what happens in the day by day, is great!
    Thanks Eric!

  4. alienbob

    For those wondering what you can do with the “post_current” function mentioned near the end of the script, this is what I put in a “maintain_current_git.conf” file in the same directory as the .sh script file:

    # The function post_commit() will be run just before exiting the script;
    # you can use this to push your git updates to a remote origin server:
    post_current() {
    # Add your own stuff here which is not covered in the main script:
    cd ${GITDIR}
    git push origin master

    I.e. you can define a function in a .conf file, with the function name “post_current”, and anything you add in that function will be executed by the script. I use it to automatically push the local changes to the remote repository.

  5. Deny Dias

    Finally someone did it the right way! Thanks, Eric.

    PS: wondering when someone will clone this into github for convenience. 😉

  6. alienbob

    Deny Dias, perhaps trhey should wait a bit…
    I think that ppr:kut has convinced me to re-create the repository from scratch but then adding historical releases with branches and tags.
    Of course I don’t have commit histories for a historical release development cycle, but you’ll be able to see what changed between releases.
    So hold off your cloning activities for a day or so…

  7. alienbob

    OK, so I added some history to

    I have imported the latest status of all Slackware releases 13.0 and newer (basically that’s all 64bit releases) and gave them their own branches and tags.
    Automatic updates will only occur in the master branch as -current evolves.
    You may have to force-refresh your browser window.

  8. Wael Hammoudeh

    Thank you Eric, I am trying to learn “git” and this will be a great tool in this journey.


  9. Wael Hammoudeh

    Great project Eric,
    I am trying to learn “git” and this will be a good tool towards that. I follow this tutorial
    Any other recommendation?
    Thank you again,

  10. alienbob

    Wael, I think that URL may be a good tutorial. I would also recommend

  11. alienbob

    After conferring again with ppr:kut and accepting his opinions about what could have been done better, I will be wiping the content of the ‘current’ repository for a second time and this time:
    – use loo-mounted official DVD ISO images to check-in the actual releases
    – create a branch per release
    – apply all the patches that came after a release as an additional commit to the release branch
    This way, the resulting git history will be much nicer to read.
    Hopefully finish this tonight because I first need to download all the ISO images (I downloaded all ISOs just now, only to discover after committing several releases that I had downloaded all 32bit versions instead of the 64bit ones I need).

  12. alienbob

    The auto-updates of the git repository are working great. And I added a RSS feed containing item URLs for every update that point directly to the tagged commit in git.
    If you add to your favorite feed-reader you’ll always be two clicks away from the actual latest changes in the source.

  13. SM

    Hi alienbob,

    This seems the right thread to ask, so I was wondering if you plan to recompile glibc for multilib. Slackware has updated the libraries twice.
    Thank you.

  14. alienbob

    Hi manciuleas

    I will get to it sometime soon. I am currently otherwise occupied: KDE Plasma 5 updates will arrive soon, and I need to migrate stuff at home from an ageing server to a new machine. Twenty+ years of legacy scripts/jobs/data to migrate from Slackware 13 where it is currently running.

  15. SM

    Hi alienbob,

    Thank you for the reply and the great job you’re doing

  16. SM

    Hi alienbob,

    Thank you for recompiling glibc.

  17. pants

    Hey alienbob,

    Thank you for your work putting this together!

    I’m wondering if it is possible to obtain/regenerate the missing components necessary to build a Slackware ISO image from the contents of this repo? The last update to Adrien’s repo was 2020-11-04 so there is a bit of a gap for anyone looking to install an older revision of Slackware current. I tried running after downloading and packaging the appropriate kernel but ran into many other missing dependencies (dropbear, isolinux.bin, initrd.img, etc). I took a look at the “–exclude” flags in the rsync command that pulls data into the repo to try to get a sense for what might be missing but was not sure which exclusions are relevant to build an ISO and which are superfluous. Do you know which artifacts are needed to create an ISO and whether there is any way to obtain or recreate them?

    rsync ${VRSYNC} –delete -rlptD \
    –exclude=”.git*” –exclude=LATEST_ADDITION_TO_CURRENT \
    –exclude=”*,v” \
    –exclude=”*.tar.?z” –exclude=”*.tar.bz2″ –exclude=”*.t?z” \
    –exclude=”*.zip” \
    –exclude=”CHECKSUMS*” –exclude=”FILE_LIST” –exclude=”FILELIST.txt” \
    –exclude=”MANIFEST.**” –exclude=”PACKAGES.TXT” \
    –exclude=”*.bin” –exclude=”*.img” –exclude=”*.iso” –exclude=”*.dsk” \
    –exclude=”*.rpm” \
    –exclude=”*.efi” –exclude=”*.EFI” –exclude=”*.s” \
    –exclude=”*.exe” –exclude=”*.EXE” \
    –exclude=”*.exe.?z” –exclude=”*.EXE.?z” \
    –exclude=”*.asc” –exclude=”*.sig” –exclude=”*.sign” –exclude=”*.pgp” \
    –exclude=”*.md5 –exclude=*.sha256 –exclude=*.sha512″ \

    • alienbob

      There are no packages in my git repositories, just sources, it will not be possible to create a ‘historical’ ISO image from this.

Leave a Reply

Your email address will not be published. Required fields are marked *

This site uses Akismet to reduce spam. Learn how your comment data is processed.

© 2024 Alien Pastures

Theme by Anders NorenUp ↑