Alien Pastures

My thoughts on Slackware, life and everything

Tag: current (Page 6 of 7)

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

New multilib packages for slackware-current

June 25, 2012 / / 17 Comments

 Earlier today, there was a massive update to Slackware-current. The ride was fun, and I am fairly certain we’ll see some breakage. In fact, we found some already and fixed that in a quick update (mounting of Samba shares was broken after splitting the mount utility for Samba shares into its own “cifs-utils” package).

So, what was updated? The highlights of this batch are:

  • the version of the next release is known: it will be “Slackware 14”.
  • kernel is now 3.2.21 – we will likely stick with the 3.2 series since that will get long-term support.
  • KDE moved up to 4.8.4 (meaning that I can remove my own packages for that version from my ktown repository).
  • gcc was bumped to 4.7.1 to accompany the new kernel.
  • glibc was patched to fix a regression
  • python got updated to 2.7.3 (the switch from the old 2.6.x version meant that every package needed to be recompiled which depends on python)
  • the network scripts (rc.inet1) got support for setting up betwork bridges – something I use every day because it allows me to make my Virtual Machines accessible from other computers in my LAN.
  • lots of other individual updates (the complete ChangeLog.txt entry of “Mon Jun 25 05:17:48 UTC 2012” measures more than 300 lines)

And since glibc was rebuilt and gcc updated, I needed to create multilib versions of those.

They can be found here (all of the mirrors below also offer rsync access):

 NOTE:

The update to attica-0.4.0 in slackware-current broke many packages of my KDE 4.9-beta2 set. Head over to my other blog post to find out how to fix that easily!

Have fun! Eric

Slackware-current gets KDE 4.8.2, hooray

April 15, 2012 / / 49 Comments

It was bound to happen, and while I was asleep Pat updated slackware-current with a fresh batch of packages… containing KDE 4.8.2 and all the stuff that it depends on!

The update to the ChangeLog.txt makes up almost 20% of the full ChangeLog length so far! Finally we have a beefy update to -current. It’s playtime for those who had not used my own unofficial “ktown” builds yet.

Note that Slackware’s version of Calligra (the successor to Koffice) is now at the official stable release, version 2.4. My own package was still a release candidate.

Also note that Networkmanager was added to Slackware! So, what I had kept separately in a “testing” directory because I was not sure what Pat would want to do with it, is now being used in the distribution after all. Enabling NetworkManager is done like in my own instructions: make the rc script executable (Slackware will ship NM disabled by default) using the command “chmod +x /etc/rc.d/rc.networkmanager”, and add the NetworkManager plasmoid (widget) to your KDE desktop in order to configure it.

The good old way of using rc.inet1 to configure your network is still available of course, this will not change! Also, you can still use WICD instead if you prefer that. Users of XFCE will want to stick with WICD anyway, since Slackware does not have a graphical configuration tool for managing NM connections, apart from the KDE widget.

Upgrade instructions:

If you are currently running “alien” packages for KDE 4.8.2 and want to upgrade to the official packages in Slackware-current, then you’ll have to be prepared for some manual labour. But it may not be that hard after all, except when you have a lot of my other packages installed as well (like multilib versions of gcc/glibc and lots of “compat32” packages).

  1. If you are using slackpkg to maintain your Slackware,  then probably you have blacklisted all of my packages.In this case, temporarily remove or comment the line in “/etc/slackpkg/blacklist” that goes “[0-9]+alien”. Then use slackpkg to upgrade to slackware-current as usual, with this condition: do not blindly accept the list of packages to be upgraded, but review every single package shown by slackpkg as a candidate for upgrading. De-select every package which you want to keep! All the “alien” packages related to KDE and its dependencies must stay in a “selected” state. Then let slackpkg do its upgrade work and you’ll end up with a proper slackware-current.
  2. If you want to upgrade using slackpkg but are not prepared to review lots of packages manually to see if they should be upgraded or left alone, then a very fast way of upgrading from my own to Slackware’s packages will be the following four commands followed by a regular upgrade using slackpkg (example paths are for 64-bit Slackware, so if you are running 32-bit Slackware then you have to ignore the “64”):
  1. upgradepkg /path/to/local-mirror-of/slackware64-current/slackware64/a/*.t?z
  2. upgradepkg /path/to/local-mirror-of/slackware64-current/slackware64/l/*.t?z
  3. upgradepkg /path/to/local-mirror-of/slackware64-current/slackware64/kde/*.t?z
  4. upgradepkg /path/to/local-mirror-of/slackware64-current/slackware64/kdei/*.t?z

Note that if you blindly ran these four commands and you are on a multilib system, you will have overwritten the multilib versions of the glibc packages with original (non-multilib) Slackware versions. You will have to download and upgrade to my multilib glibc packages again. Note that this will not break your Slackware installation… it merely disables the use of 32-bit software until you re-install my multilib glibc packages.

Have fun! Eric

Huge update to slackware-current and what it meant to my laptop

November 15, 2010 / / 36 Comments

Today, you may be watching the slackware-current ChangeLog.txt slack-faced, with a feeling of horror…

… because the update is HUGE. There are well over 300 lines of updates! That amounts to one-third of the full length of ChangeLog for the current development cycle. Those of you who thought Slackware was calmly drifting toward another stable release, will have to brace themselves for a round of fun and thorough testing.

I think the most obvious intrusive change is that Slackware-current moved to using the “new” X.Org which no longer depends on HAL for hardware detection and initialization. Instead, the new X.Org talks directly to udev.

Robby Workman has put a lot of work in assembling a coherent set of X.Org sources as well as getting this stuff tested widely before it got added to Slackware (see http://www.linuxquestions.org/questions/slackware-14/call-for-testing-xorg-updates-20100830-a-829336/).

There is also a newer GTK+2 (version 2.22). The new GTK proves to be a difficult bugger with apparent incompatibilities with previous releases. We have to see what the extent of these incompatibilities is; for instance I came across software does not compile anymore and needs patching or updating (gtk-chtheme).

When upgrading your slackware-current please note that several packages have been added, and others have been removed! If you are using slackpkg to do the upgrades for you, you can use the command “slackpkg clean-system” to remove the deprecated (mostly X.Org related) packages. In the package overview that presents itself, make sure to first deselect those you installed yourself before hitting the “OK” button! Likewise, running “slackpkg install-new” will install the newly added packages for you.

What were the bumps when I upgraded my Lenovo T400 laptop?

Well, several… but they were easy to fix.

X.Org configuration of the hardware:

Since the new X.Org no longer uses HAL, my old method of configuring the TrackPoint in a file “/etc/hal/fdi/policy/11-x11-trackpoint.fdi” no longer works. Instead, the new X.Org uses a configuration directory “/etc/X11/xorg.conf.d/” where you can add configuration files for your hardware. You’ll see the similarities; my old HAL file looks like this:

<match key="info.product" string_outof="TPPS/2 IBM TrackPoint;PS/2 Generic Mouse">
 <merge key="input.x11_options.EmulateWheel" type="string">true</merge>
 <merge key="input.x11_options.EmulateWheelButton" type="string">2</merge>
 <merge key="input.x11_options.YAxisMapping" type="string">4 5</merge>
 <merge key="input.x11_options.XAxisMapping" type="string">6 7</merge>
 <merge key="input.x11_options.Emulate3Buttons" type="string">true</merge>
 <merge key="input.x11_options.EmulateWheelTimeout" type="string">200</merge>
</match>

While the new way of configuring requires a file (I aptly named it “/etc/X11/xorg.conf.d/20-thinkpad.conf” but any name that ends on “conf” will do) in which I wrote:

Section "InputClass"
Identifier    "Trackpoint Wheel Emulation"
MatchProduct    "TPPS/2 IBM TrackPoint|DualPoint Stick|Synaptics Inc. Composite TouchPad / TrackPoint|ThinkPad USB Keyboard with TrackPoint|USB Trackpoint pointing device|Composite TouchPad / TrackPoint"
MatchDevicePath    "/dev/input/event*"
Option        "EmulateWheel"        "true"
Option        "EmulateWheelButton"    "2"
Option        "EmulateWheelTimeout"    "200"
Option        "XAxisMapping"        "6 7"
Option        "YAxisMapping"        "4 5"
Option        "Emulate3Buttons"    "true"
EndSection

You will have perform a similar exercise if you previously had configured a non-US keyboard in a HAL “fdi” file. I will leave it up to you to figure out how to repeat this for the new X.Org.

Hardware accelerated graphics:

Actually, this is where the updated packages shine! The combination of mesa, Intel graphics and KDE 4.5 proved to be quite disastrous a month ago when the kernel was updated in slackware-current. My KDE 4.5 packages froze the computer solid, the very moment when “desktop effects” (compositing) was enabled. This graphics hard lock is not caused by X.Org. Rather, it is the kernel’s DRI (direct rendering interface) and the way mesa interacts with it where all the trouble started. However,the real cause was not apparent at first (and some people were pointing at the open source graphics drivers). I had reported about this problem before – my Asus Eeepc 1000H which has an Intel graphics chip started having these compositing problems after the upgrade of the slackware-current kernel to 2.6.35.7 (i.e. before the upgrade of X.Org or mesa). As long as you were not using compositing in KDE 4.5, you would not see this problem at all.
The issue has been addressed in mesa (the library used by X.Org to enable software and hardware accelerated graphics). Slackware’s mesa was updated to 7.9 today and KDE’s compositing desktop is working now! My T400 with Intel graphics is happy again, as will be my EeePC after I upgrade that!

VLC and fullscreen video:

I had not expected this one, and I have not been able to find out what caused it. When resizing the VLC window, the dimensions of the embedded video would not grow beyond the actual pixel size of the video stream (i.e. there was no video scaling). I tried downgrading to an earlier version of VLC, I tried running XFCE instead of KDE, but the problem remained painfully visible as a big black border surrounding a tiny video. In the end, I ruthlessly removed the VLC configuration directories “~/.local/share/vlc/” and “~/.config/vlc/”. That helped! But it left behind a feeling of dissatisfaction.

xz (liblzma.so.0):

The xz package (used as the compression tool for the .txz package format) was updated too. The new dynamic library has another version number. I first noticed that I must have forgotten something when KDE refused to start after I finished upgrading. Several applications were spitting out errors about a missing “liblzma.so.0” library. This old library file was added to the “aaa_elflibs” package for compatibility reasons (along with a version of libtalloc.so), but this package is blacklisted in the “slackpkg” program so  “aaa_elflibs” was not getting upgraded. Usually (upgrading between two stable releases) this is the correct approach, because aaa_elflibs should contain redundant libraries. However, right after an update to this package you should run “upgradepkg” on it. I did that, and KDE started up normally again.

And thus starts a period of new play-testing, folks. Have fun, and give us good feedback!

Eric

Section “InputClass”
Identifier      “Trackpoint Wheel Emulation”
MatchProduct    “TPPS/2 IBM TrackPoint|DualPoint Stick|Synaptics Inc. Composite TouchPad / TrackPoint|ThinkPad USB Keyboard with TrackPoint|USB Trackpoint pointing device|Composite TouchPad / TrackPoint”
MatchDevicePath “/dev/input/event*”
Option          “EmulateWheel”          “true”
Option          “EmulateWheelButton”    “2”
Option          “EmulateWheelTimeout”   “200”
Option          “XAxisMapping”          “6 7”
Option          “YAxisMapping”          “4 5”
Option          “Emulate3Buttons”       “true”
EndSection

KDE 4.5.1 will get Slackware packages… not sure when and where

September 2, 2010 / / 3 Comments

Some of you may have noticed that source tarballs for KDE 4.5.1 are available now.

I talked to Pat about this last week, to see if this release could end up in Slackware-current. He answered that that would be a possibility. There are several other things brewing for slackware-current, so I have no real good estimate of when that will happen.

If it takes too long, I will just build packages for KDE 4.5.1 myself. There are no new dependencies and slackware-current is fully up to date with regard to support for KDE 4.5.1.

Here’s hoping!

Eric

« Older posts Newer posts »

© 2025 Alien Pastures

Theme by Anders Noren — Up ↑