Sunday, 21 October 2018

New blog site

The blog has been moved to Please update your RSS feed to the new one!

Tuesday, 23 August 2016

Our new extra repository

You might have noticed that just before the Salix Xfce 14.2RC1 release a new repository, named extra-14.2 has appeared in our servers. This has been enabled by default in the 14.2RC1 and 14.2RC2 releases and will be also available in the final 14.2 release.

This new repository is present for both i486 and x86_64 architectures and its purpose it to include packages built from SlackBuilds found at At this moment, it's not that full, only about 20 packages are included in it. These are mostly there as proof of concept and for initial testing. Eventually, the extra repository will be filled with packages for almost every SlackBuild present in SBo.

For the purpose of automatically building the packages, a new tool, sbobuild, has been developed. This takes a list of SlackBuild names as input and continues to build the respective packages, create complete source code trees and keep a log of every build. It's not perfect (yet), it was written in a hurry, but it does the job it is supposed to do for now. Other similar tools exist, like slackrepo, but they are only meant to be used in Slackware. As such, they don't take into account the many packages that are already included in the Salix repositories and may introduce conflicts. What sbobuild does, is check if any given software available in SBo is already availabe in the Salix repositories and if it is, it just skips it. For building and uploading the packages that are created to our main repository, we now have a new server, which was only made possible due to user donations.

Currently, the libraries directory of SBo is being processed and packages keep coming out. As soon as this batch is finished, they will all be uploaded to the main repository and the next batch will follow. The libraries directory alone consists of more than 800 packages and SBo holds more than 5000 SlackBuilds. Considering that most SlackBuilds do not take advantage of multiple processors/cores to spawn multiple build instances, this task is going to take some time.

Now, SBo has a few known shortcomings. There are some SlackBuilds that are just unmaintained and have not been updated for a long time, in some cases for years. Then, there are others that have broken download links for their respective source tarballs, sometimes intermittently. And then there are cases of conflicts and incompatibilities that sometimes are known, but in other cases are not and nobody has noticed. Finally, there are a few SlackBuilds that are about software that is really meant to only be built from source. One such examples is ATLAS, which needs to be tuned for every single CPU it runs on. Due to this nature of SBo, not every SlackBuild is guaranteed to work and that is the reason why not everything will be finally built. Of course we're keeping logs with everything that fails and we will try to fix some of those builds that failed for any reason.

Additionally, SBo has a policy of constantly updating its contents with new versions, which in my opinion is competely against Slackware's policy (as well as our own) for stability. For that reason, our extra repository will remain mostly static. That means that we will not update packages with newer versions just for the sake of having a newer version. However if we receive reports that something is terribly broken or severely compromised, we will definitely try to fix it. Newer versions, as they are updated in SBo, will be available through Sourcery/slapt-src for any users that want them, but users then will have to take care of any conflicts that might arise.

Also, the packages in the extra repository have not been thoroughly tested, certainly not in the level that packages in the standard Salix repositories have. Think of it as an equivalent to the Universe repository in Ubuntu, if you're familiar with it.

In some cases, mostly with Python and Perl libraries and software, not all dependencies will be listed. If you find such a case, please notify us (in the forums or the mailing list) and we'll try to fix it.

Since the extra repository has a lower priority in the slapt-getrc settings than the standard Salix repositories, Salix specific packages will always override their counterparts in the extra repository and the users will have no problem updating their systems just by using slapt-get from the command line or gslapt from the GUI.

I think this is very exciting news for Salix. The new 14.2 release is going to include more software than was ever available in the repositories for previous releases.

Thursday, 9 October 2014

Our SBo mirrors

We have been mirroring the (SBo) repository and at the same time applying slight changes to it for some time now. These changes are essential to Salix, for a few reasons.

First of all, the SBo maintainers have decided that they will only list SlackBuild dependencies only if these are not part of a Slackware full installation. While this may be a decision that is fine for Slackware itself, since they don't offer any kind of support for users doing anything other than a full Slackware installation, it's generally not good for Salix, since a Salix installation of any edition, is slimmer than a full Slackware installation, by far. For example, in Slackware it is expected that everyone has the Qt libraries installed, but this is definitely not true for Salix (except from our KDE edition of course). So, a lot of the SlackBuilds at SBo end up having missing dependencies when it comes to a Salix installation.

Then, there is a problem with package/SlackBuild naming. We have a lot of packages in the Salix package repositories that are also present in the SBo repository. While we try to keep the package naming consistent with the one they're using in SBo, that is not always possible. For example, at this moment, there is a package named "python-configobj" in our package repositories and another one named "configobj" in SBo, which are actually the exact same piece of software. Even if we made every effort and named everything at the time of release according to the SBo names, SBo is constantly changing and SlackBuilds may be renamed.

Another problem (for lack of a better word) is that SlackBuild maintainers choose to update their SlackBuilds as soon as a new version of the software they are packaging is out. While this might not be bad in itself, it kind of conflicts with the way things work for the binary package repositories in Slackware and also in Salix, which generally follow the idea that upgrades should only be done for security reasons. And since there is a very wide overlap between packages offered in the Salix binary package repositories and the SlackBuilds provided by SBo, there are often newer versions available in SBo than in the Salix binary package repositories. This might confuse users, because by opening Gslapt, they find one version and by opening Sourcery, they find another, often newer, version. What's more, if they were to "upgrade" to the version available in SBo, they would find that Gslapt/slapt-get would want to "downgrade" that package to the version available in the Salix binary repositories and the only way to stop that would be to put the package in the EXCLUDE list in their slapt-getrc file.

So, in Salix, we have to deal with these problems. Here's what we do...

Our own copy of the SBo repository, the one that is available by default to Salix users through our package management tools is synced with the main SBo repository every few hours.

For the first problem mentioned above, we have a mechanism for adding "missing" dependencies in our copy of the SBo repository. For example, the ardour SlackBuild requires cmake to build. Now, cmake is always thought to be present in a Slackware installation, otherwise it is not a full Slackware installation and it is not supported in any way. In Salix though, cmake is definitely not part of a standard installation and so we add it as an extra dependency for ardour.

For the second problem, we have created a list of packages/SlackBuilds that are named in a different way between repositories. Every SlackBuild that is also present as a binary package in the Salix repositories with a different name, is removed from our own copy of the SBo repository and every reference to it in dependencies is replaced with the name that the package has in our own binary package repository. This way, the package in the Salix binary package repositories is always used, even if it is originally named otherwise in the original SBo repository.

Finally, all software that is present in both the Salix binary package repositories and SBo, is removed from our own copy of the SBo repository, so there is no way users will be confused and go back and forth between versions. Actually, the SlackBuilds themselves are not removed from the repositories, rather the reference for them in the SLACKBUILDS.TXT file is removed, so it isn't used by our SlackBuild management tools, slapt-src, Sourcery or spi.

With SBo being a moving target though, this process will always be ongoing and will never be 100% complete. If you find a SlackBuild that is missing some dependency, please report it, either in our mailing list or in our forums. Similarly, if you find the same SlackBuild present in both the Salix binary package repositories (hence available in Gslapt) and our own copy of SBo repositories (hence available in Sourcery), please report that too. Of course feel free to report any other problem you might find with our repositories.

Wednesday, 26 March 2014

MATE is around the corner

MATE 1.8 has been released in source code form by its developers about 3 weeks ago and I have been working on packages for Salix for about as long. The good news is that I think I'm almost done! So, expect MATE 1.8 packages to hit the repos sometime in the following days. We didn't have any MATE release for Salix 14.0, but it looks like we are going to have one for 14.1!

We have already included some MATE 1.6 packages in our repositories and we have used those for our Xfce release as well, but a complete MATE 1.6 desktop was not included. The packages that we already had included were mate-document-viewer (atril), mate-file-archiver (engrampa), mate-dialogs and their dependencies and that's about it. These are also the packages that were built first for 1.8. In total there are about 30 packages that will be pushed to the repositories, so any of these packages that you might have on your system will be upgraded to their 1.8 counterpart in the next days. The upgrade should be competely harmless, so nothing to worry about. In fact I had already patched the 1.6 packages with some fixes from the 1.8 branch, so the most important changes were already there.

I had considered using packages from the MATE SlackBuilds project, but only very briefly. While the guys there have done a good work on their packages, I realized that in most cases, we had to built our own packages.

Some of the packages from the MATE SlackBuilds project were built using dependencies that we would never have in Salix, at least not by default. Several packages were built with support for NetworkManager, which we do not ship by default. There was even a case where one package was built using GTK+ (version 1, that is ancient!) which would definitely not work for us.

One other thing that I didn't like at all about these packages, was that help wouldn't work at all (used from the Help menu or using the respective buttons in any application). It would just show an error message, because it needs yelp. The problem is that they haven't included yelp and what's worse, they have removed the actual help files from the packages. So, even if we built a package for yelp, help would still not work and there would still be an error message. And having an error message pop up doing something really normal, like selecting a menu option that is right there, everywhere, is something I don't like at all. Now, I also don't care about yelp though and mostly everything that comes from GNOME. So what I did was that I patched every single MATE application/plugin and pointed the help menu items/buttons to the MATE webpage. Works a lot better than any error message.

And then there was the default settings issue. The packages we use, should include default configuration that will fit with Salix, including panel location, panel applets selection, icon theme used, window manager theme, stuff like that. The default menus that ship with MATE also include two separate "System" menus, one under the "Applications" submenu and one under the "System" menu, which is kind of confusing in my opinion. So, I edited the default menu specifications to keep only the latter and have all "System" applications in one place. Also, I "had" to change the default menu icon to the Salix icon.

Once again, like we did with the MATE 1.2 packages that we offered with Salix 13.37 and the MATE 1.4 packages that we offered for Salix 14.0, we are not building the complete set of MATE packages. We are building all the "base" packages, that make up the actual MATE Desktop Environment, like mate-desktop, the Caja file manager, the panel, panel applets etc, but we are not including Pluma, the text editor, Eye of MATE, the graphics viewer etc. This is only just because I think we already have better alternatives for them and we wouldn't use them anyway. For example Geany, our default text editor/IDE that is also part of the default Xfce release is a much better editor than Pluma and Viewnior a better viewer than Eye of MATE.

Once packages show up in the repositories, you should be able to install the MATE desktop using:

sudo slapt-get --install-set mate

and a beta release shouldn't be that far off.

Here's a screenshot in case you're wondering what it looks like...

Monday, 24 February 2014

New Startup Guide

We've been working on this for a while and were hoping to have it ready by the time 14.1 is released and it seems that we managed to make it! You can now find the new guide linked from our main website.

The startup guide was left with no updates since the 13.37 release, so it was getting a bit old. It was still mostly OK, but there were things that were out of date.

Another thing that was getting in the way was the format that the guide was written in. A tool called Publican was used to create the previous guide, but newer versions of it seemed to only work in Debian (or was it Fedora?). Anyway, it wouldn't work on Salix/Slackware anymore, so we had to switch and convert everything to the new format. Once again, the solution was to go with txt2tags.

So, we converted everything to the txt2tags format. From the txt2tags format, we can acquire the equivalent in html output very easily. Then, in turn, the html output is processed through htmldoc to split it in multiple pages and create a table of contents and a lot of sed magic is used to apply css formatting to the output so it looks nice.

The upside of using txt2tags is that it's not only html output that it can produce. Using the same source file, tex files can be created. These can be processed throught TexLive to create a pdf file. And since this is LaTeX we're talking about the result looks absolutely professional. Still, some sed magic was needed here too, in order to make fine changes, but after initial setup, pdf generation is completely automated.

Producing ebooks is the next step. Creating epub and mobi files from the html output is almost ready and these will also be available for download soon. So, you could read the Salix Startup Guide in your favourite ebook reader.

The only downside of using txt2tags like that, is that currently there is no provision for translations. There is simply no way to do it in a sane way. Truth is that translators put a lot of work in the previous versions of the guide, but it seems that we won't be able to provide localized versions of the guide anymore.

The guide may not be 100% ready yet, there might still be small issues that need taking care of, but we think that it's ready for public release as it is. If you find anything that you may think needs fixing, please contact us through our mailing list.

Tuesday, 14 January 2014

Kernel decisions

I've had a few chats lately, either through email, in our forums and in IRC about the kernels that we're including with our 32-bit releases and I thought it would be best if I explained things a bit.

First of all, 32-bit Slackware ships with two different kernels. The first one, which is the most used of the two is an i686 optimized, PAE enabled, SMP capable kernel. The second one is an i486 optimized, non-PAE, non-SMP capable kernel. The options with which these kernels have been built is a decision made by Slackware and it is our policy that we don't change major things like that.

While all previous 32-bit Salix releases included both kernels, since the Salix Xfce 14.0 release, we do not ship the i486 kernel anymore for our "big desktop" releases. That includes all Xfce, KDE and MATE releases (we skipped the last one for 14.0, but that's another subject). And that's the same thing that we're going to do for our 14.1 releases.

The reason for this is a simple one: size. The nature of software is to grow and while the iso images for our first Salix Xfce 13.0 releases was no more than 550MB, since 14.0, we are struggling to keep the size within 700MB. And that's with keeping the software that is installed by default the same, more or less. The 700MB limit is a very important one, because it means that the iso image can be burned to a CD-ROM disc. If we exceed that limit, there are mainly two options, either burn and use a DVD-ROM or transfer the image to a USB flash drive and install using that.

I'm only referring to our 32-bit releases, since anyone with a 64-bit capable PC probably has a DVD-ROM drive anyway and certainly can boot using a flash drive. So, I don't really care much if we exceed the limit in our 64-bit releases. But a big portion of older PCs do not support booting from USB and several of them do not have a DVD-ROM drive and our 32-bit releases need to cover for those.

Right now, the latest Salix Xfce 14.1beta1 32-bit iso image is exactly 702MB. That still fits into a CD-ROM disc, the actual limit being a bit higher than that. But it only includes the i686 kernel. If we were to add the i486 kernel as well, that would mean that the iso size would increase by at least another 50MB. And that would definitely put it over the CD-ROM size limit (yes, I know that 800MB CD-ROM discs exist, but they were never that popular, mainly because there were never reliable).

So, we had to make a choice. Either we include the i486 kernel too and require a DVD-ROM to burn and install the iso, or ditch it and keep it within the CD-ROM size limit. We went with the latter.

Now, let's see which CPUs we are excluding exactly with that choice, because there is a lot of misunderstanding going on about that.

A lot of people seem to think that since the i686 kernel is an SMP capable kernel, that immediately excludes all single core CPUs for some reason. But SMP capable just means that the kernel can support multiple cores (or motherboards with multiple CPUs) if it happens to find them and there is no problem at all running such a kernel with a single core CPU.

Then of course there is the issue that the kernel is built for i686. All CPUs that were manufactured after and including the Pentium Pro though, support the i686 instruction set. And Pentium Pro was introduced in 1995. The only CPUs that are actually excluded by the architecture choice are Pentium 1 chips (max 200MHz), i486 chips and compatibles (AMD and Cyrix equivalents) from that era.

The most important issue is actually that the i686 kernel is built with PAE support. Unfortunately that excludes all CPUs that do not support PAE. But still, every CPU that has been manufactured after and including the Pentium Pro supports PAE! The only exception being some Pentium M CPUs, but still not all of those, only the ones with a 400MHz bus, which were marketed using the term "Centrino". By the way, the Pentium M is a CPU that came out in 2003.

So there you have it. The PCs that can't be used to install Salix Xfce, KDE or MATE to, are ones that have an i486, a Pentium 1 or a specific kind of Pentium M CPU, with the only really loss being those few Pentium M PCs. I don't think anyone in their right minds would want to use Xfce or KDE or MATE on an i486 or Pentium 1 PC. And really, nobody would probably want to use KDE on a Pentium M PC either. Xfce and MATE might work modestly, but for that CPU, faster and more spartan alternatives exist.

If we had made a different choice and kept the i486 kernel, sure we would be also covering all PCs with those CPUs as well. But then we would be excluding most of them all over again, requiring a DVD-ROM drive. And in the process we would be excluding all PCs that have a better CPU but only a CD-ROM drive instead of a DVD-ROM drive and also the people that have a bunch of CD-writable media they would want to use. I'm fairly certain that this is a much more significant number of people.

However, all is not lost even for those with those very old CPUs. As we did with our Salix Ratpoison 14.0, release, all our "lighter desktop" releases will also include the i486 kernel. That will certainly include a Ratpoison release and maybe we'll come back to a Fluxbox or LXDE release and I know someone is considering an Openbox release. We might even have a core-only iso, we'll see. These will include both i486 and i686 kernels simply because even if they do, the iso size stays well within the 700MB limit.

Wednesday, 13 November 2013

The gksu problem

We had a real problem with ktsuss/gksu while developing for 14.1. It seems that newer versions of the shadow package, and certainly the one that is included in Slackware 14.1, don't allow su to be executed in any other way except directly from a terminal. That means that su cannot be executed as a subprocess from inside ktsuss or the original gksu anymore and these become effectively useless. This is a critical issue for us, because if we don't fix it, almost nothing in the System part of the menu would actually work.

gksu-polkit works around this problem by using policykit for getting superuser proviliges, but it doesn't seem to be developed and it has terrible bugs that cause the CPU to hit 100% and stay there. It would fry your PC.

So, one solution, was to patch ktsuss to actually open a terminal and execute su from inside a terminal. But that would mean a terminal popping on the screen and staying there for the duration that you had the application that you launched open. And if you actually closed the terminal, the app would close too. Ugly.

The other solution would be to stick with the shadow version that came with 14.0. ktsuss works fine with that. But we can't rely on older versions of software like that. We can't keep the old version forever and this was no real solution.

So, in the absense of anything else out there that fixes this problem, there was nothing else left but writing my own. Enter gnsu (Gnsu's Not SU). It's actually a couple of rather simple shell scripts that use yad to display a window requesting the user password to get superuser rights using sudo as a backend.

That means that you don't have to provide (or know) the root user password to launch an app with superuser priviliges. But you need to be included in the sudoers list. So you would have to run visudo from a root terminal and add something like the following somewhere in the file:
george ALL=(ALL) ALL
to allow user george to run apps with superuser priviliges, or something like:
%users ALL=(ALL) ALL
to allow anyone in the users group to do the same.

I chose yad for displaying the password request window, for the reason that it has more features than other similar apps out there and would allow me to make the window a bit more beatiful, by displaying an icon in it. It would be trivial to patch gnsu to use zenity, matedialogs, xdialog or any other similar app out there.

The code for gnsu is up on github. It's in early stages, but it works. I still want to add some things, like support for translations and a Makefile, but these can come later. Oh, I could use the strings from our ktssuss translation project, so it would be already translated.

Now, just symlink gnsu to gksu (not necessary if you install the gnsu package) and everything should work.

There is an added benefit by using sudo as the backend; if you launch something with gnsu from a terminal and then launch something else with gnsu again from the same terminal in a short time after the first one, you don't get a password request the second time (or third, or forth...). This behaviour can be tweaked by editing sudo settings.

Can't get any more simple than that.

Plus, I always wanted to name something with a recursive acronym. :D