Alien Pastures

My thoughts on Slackware, life and everything

Tag: ktown (Page 2 of 3)

Poll: who needs 32bit packages for latest Plasma 5?

January 25, 2017 / / 81 Comments

During the past week I have been spending time on getting the latest KDE Frameworks, Plasma and Applications built. The new Applications 16.12 was quite a bit of work due to the splitting of tarballs in many smaller ones. Also, the Slackware 14.2 and -current versions have now diverged sufficiently that the packages I compile on 14.2 are no longer guaranteed to work on -current, so that introduces additional work.

This effort took much longer than I am comfortable with. I do not have as much time available as I used to have due to “real life” – meaning my new job is quite a bit more demanding than my previous one.
This made it clear to me that I have to start making decisions about my Slackware activities, with more detail than what I said in the past along the lines of “updates may come less frequent”. It is obvious that I can not keep releasing a new set of ‘ktown‘ packages every month, for both 32bit and 64bit platforms, and for both Slackware 14.2 and -current. I have a few options:

  1. stop releasing 32bit packages for Plasma 5 (ktown repository)
  2. stop releasing Plasma 5 for Slackware 14.2 and start focusing on -current exclusively

I tend to lean into option (1) and therefore wrote this blog post. Who is using my Plasma5 (ktown) packages on a 32bit Slackware OS?

If there are users running a 32bit Slackware-current OS then this could mean a stop to new Plasma5 releases for Slackware 14.2. Updates to the graphical desktop does not have priority at this time in the development cycle of Slackware-current which means I will have to keep maintaining my ‘ktown’ repository for a while to come.

Bottomline: I will have to make one of the two above choices, and I will listen to you – the users of my packages – to help me make that decision.

Ktown for Slackware – development history available in git

December 22, 2014 / / 19 Comments

kde4 For a long time I have been keeping copies of the full source directories for every KDE 4 release I have made for Slackware. That is amounting to a lot of megabytes, since I am also keeping the source tarballs, not just the scripts and patches. Traditionally, I have kept one KDE version publicly available for all recent Slackware releases, in my ‘ktown’ package repository at http://alien.slackbook.org/ktown/ . This repository is also available through rsync, not just http (using my primary mirror at rsync://taper.alienbase.nl/mirrors/alien-kde/).

But what was missing (because I am lazy) is a git interface. Now, you could argue that accessing the ktown scripts and patches through git is somewhat pointless, since you would either want the packages (through direct download or using slackpkg+) or the full sources (inclusing the source tarballs, not just the scripts) and the git interface I intend would not be offering that.

However,  with the advance of KDE 5, it starts making sense to use git: primarily for version control and history keeping.

The old KDE 4 releases were self-contained: all sources would be released at the same time, so that I could simply create a toplevel directory of, say, “4.14.3” and put everything that I needed to compile the packages below that directory. Easy-peasy. KDE 5 on the other hand, has abandoned the big coördinated release effort. Instead, the releases are now done for subsets of the Software Collection (old name, no longer used). You’ll find separate uncoördinated releases for the KDE Frameworks, Plasma and the Applications. Of course these are all dependent on each other and require specific  versions to work together, but there is no longer something like a “KDE 5.2.0”.

You saw in my initial release of KDE 5 packages that I simply named the toplevel directory “5”, i.e. without minor numbers. My plan for the future is to stick to that number until Frameworks and Plasma move away from 5.x. Inside the “5” directory you will see future partial updates: whenever new Frameworks, Plasma and Applications tarballs are released, I will update one or more of these at the same time, but not necessarily all of them at the same time.

This poses a problem for my internal version control. Copying directory trees every time I refresh a subsection, will create a big mess with greater risk of not being able to go back to a previous point in time, in particular for the “deps” packages but I also see a risk of not being able to retrace working combinations of Frameworks, Plasma and Applications.

Therefore I have decided to move my ktown sources and scripts into a git repository. What I did, was take every final increment of every KDE release since KDE 4.6 for which I have ever created packages, and build a git version control history using those sources. The git repository has a master branch which will be the release which I consider most recent and stable. At the moment, that is 4.14.3. Every release will have its own branch too. There are branches for 4.6.5, 4.7.4, 4.8.4, 4.9.5, 4.10.5, 4.11.5, 4.12.5, 4.13.3, 4.14.3 and 5 at the moment, and you’ll find them here:

http://taper.alienbase.nl/gitweb/?p=ktown.git

I think this will work best for future development on KDE. Currently, the patches in there are mostly gzipped, since this is what Slackware wants, but I am thinking about creating “unzipped” branches for recent releases, so that it will be easier to peek into the patches.

Any feedback, tips etc, let me know.

Eric

Edit – Tue Dec 23 12:26:25 UTC 2014:

I have added a cgit interface as well: http://taper.alienbase.nl/cgit/ktown/

Two rebuilt KDE packages.

October 16, 2013 / / 1 Comment

kde44For your information:

I had to rebuild two packages for users of my KDE 4.11.2 on Slackware-current.Both are packages that are being used by a lot of people so I did not want to wait for the next release of KDE (scheduled for November 5th).

  1. ark: this package was broken after the update of the ‘libarchive’ package in Slackware-current
  2. calligra: actually I did not have calligra as part of my KDE 4.11.2 set. However it turns out that the new ‘marble’ package of KDE 4.11.2 breaks Calligra Words! Therefore I have added a rebuilt Calligra 2.7.3 to my KDE 4.11.2 set (the same package as you’ll find in Slackware-current… only this time with a working Calligra Words).

Get them from any of my ‘ktown’ mirrors:

Enjoy!

A look on the sunny side

May 9, 2013 / / 23 Comments

2013-05-04 15.26.25

It will be obvious by now, that I work somewhat like a manic-depressive person. Bursts of frenzied activity are followed by periods of silence and withdrawal.

After I had worked like a maniac to release a usable version of my Slackware ARMv7 port (creating a git repository, cleaning up build scripts, uploading packages and setting up a local infrastructure to keep all of those easily updated) I was exhausted and my work output went down a lot. I have a day-time job and I do take that seriously… there was no energy left in the evenings to work as much on Slackware as I wanted.

Luckily, I had a short holiday scheduled and during the previous week, I have enjoyed life from the sunny side again. Spending a week in a holiday home with my family, sleeping long hours and walking through the hilly landscape of South-Limburg was something I needed to re-gain fresh energy.

And this week too has its pleasantries. Today is Ascension Day, which is a national holiday here in NL, and my employer gives us another day off tomorrow. Long weekend ahead! Time enough to enjoy my birthday (today), eating cake and warming up under the sun in my garden.

But last week I still managed to release some packages even though I did not write blog entries about it (you can always follow the RSS feed of my repository ChangeLog). New calibre, owncloud client and steamclient packages, and virtualenv which I needed in order to play a little with the Django web framework.

And I added a new version of the icedtea-web program, the webbrowser plugin for Java (works with my OpenJDK packages, either jdk or jre). This is a security update, here are the CVE entries it fixes and it is recommended that you upgrade:

  • CVE-2013-1926, RH916774: Class-loader incorrectly shared for applets with same relative-path.
  • CVE-2013-1927, RH884705: fixed gifar vulnerability
  • CVE-2012-3422, RH840592: Potential read from an uninitialized memory location
  • CVE-2012-3423, RH841345: Incorrect handling of not 0-terminated strings

Furthermore I am using my day off to build the recently released KDE 4.10.3 for Slackware 14.0. This version of KDE landed in slackware-current a few days ago but as a result of my holiday, I was not able to build packages for Slackware 14.0 sooner. Tonight I will write a separate blog post about this when the packages are ready and the repository updated.

Cheers, Eric

Slackware-current adopts KDE SC 4.10

February 12, 2013 / / 15 Comments

It happened faster than I had thought, considering the slow pace at which slackware-current has been evolving these past months. But there is a massive flurry of activity and Patrick Volkerding has pushed lots of updates to the development branch of Slackware lately. Quite interesting was the addition of the elilo and gnu-efi packages of course, which indicate future support in Slackware for UEFI-based hardware (UEFI being the sucessor to the good old BIOS). Slackware already supported GPT partition tables (successor of the good old MBR) so this looks promising for buyers of “Secure Boot” computers. Don’t forget to wipe that awful Windows 8 first! It would not make any sense to keep it on a computer if you can install Slackware on it in its place.

But anyway, that was a side-step. I actually wanted to talk about the update of KDE Software Compilation. Slackware-current has now KDE SC 4.10, essentially the same packages that I am offering on my ktown repository, with the same patches and using the same KDE.SlackBuild framework, but then built on Slackware-current as opposed to my Slackware 14 based build. Hooray!

I guess some of you who are running slackware-current, have been wondering how you can most elegantly upgrade from the “alien” packages to the official Slackware KDE packages plus dependencies. Well, here is how I did it today, using slackpkg:

  1. Edit your “/etc/slackpkg/blacklist” and comment the line out that says “[0-9]+alien“. This will allow slackpkg to touch my packages (those that have the “alien” build tag) Note that this should still keep your multilib packages blacklisted, because those have a build tag that ends on “compat32” and for which you have the line “[0-9]+compat32” in the blacklist. Note that the exceptions are the multilib gcc and glibc packages!
  2. Run “slackpkg update” to refresh slackpkg’s knowledge of the Slackware version you are running
  3. Run “slackpkg install-new” to install any new packages like elilo and gnu-efi which were recently added
  4. Run “slackpkg upgrade-all”, and carefully check the list of package upgrades which slackpkg proposes. This step will upgrade KDE and iots dependencies, making the switch from my packages to the official Slackware versions. Make sure that you DE-select the gcc and glibc packages if you are running a multilib 64-bit Slackware-current!
  5. Edit “/etc/slackpkg/blacklist” again, and remove the comment in front of the line “[0-9]+alien“.
  6. Now run “slackpkg clean-system” and carefully inspect the list of packages which slackpkg offers to remove from your computer. Only leave packages selected which you want to get rid of! De-select all other packages (usually those would be 3rd-party packages you want to keep)
  7. Do a final check for remaining KDE packages you may have missed. Run the following two commands to check for left-over Slackware original KDE 4.8.5 packages and my own KDE 4.10 packages – and remove packages which you see listed: “ls /var/log/packages/*4.8.5*” and “ls /var/log/packages/*4.10.0*alien“

That’s it! Reboot the computer and enjoy KDE 4.10!

Remember, if you just upgraded to KDE 4.10 and experience weird problems in the Plasma workspace, this can be related to KDE caches of an older release. Log out of KDE, and run the following commands to get rid of old cache data – don’t worry, these directories will be automatically re-created and re-populated (The “$USER” environment variable is actually your login username):

$ rm -r /tmp/kde-$USER/
$ rm -r /tmp/ksocket-$USER/
$ rm -r /var/tmp/kdecache-$USER/

Cheers, Eric

« Older posts Newer posts »

© 2026 Alien Pastures

Theme by Anders Noren — Up ↑