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.