Katana’s metadata support

Hi there,

It is rare that I post about Katana but I think this one is worth letting you know – Katana now can show metadata about files and directories via Dolphin (the file manager) without Nepomuk. The changes required to make this happen were trivial and the only difference between the stock KDE and Katana now in terms of the metadata types is that KDE supports tags, comments and ratings via Nepomuk in addition to the those Katana supports. This fixes KDE bug 270842.

Here is something for the eye:

tooltips

We hope you enjoy using Katana, cheers!

Going for the fix

Hello,

There is an issue triage on going with fixes to BFP[1], live-tools[2] and the ports[3]. Most of the attention is now on the ports, cleaning and sanitizing them (e.g. most of the depends are made into makedepends, see this post). Your input is invaluable, as always, so if you face issues you can report them as a task.

Cheers!

[1] https://bitbucket.org/smil3y/bfp/commits
[2] https://bitbucket.org/smil3y/live-tools/commits
[3] https://bitbucket.org/smil3y/mini/commits

JFS is now officially supported

Hello,

For a long time JFS was not supported but is now. The changes required for it were simple but reasons not to support it were so too.

First of all, it was not supported until now because it can cause data loss in some situations, especially on sudden power cut, but it has some advantages[1][2] in some situations. XFS and Btrfs are not as mature as JFS and only recently they have been “announced” as production ready and XFS certainly has some quircks[3]. But anyway, the userspace utilities for JFS are part of the base group now and will be shipped with the next snapshot (comming soon), the kernel module for the filesystem is built-in. For those of you who like fancy partitions setup – go ahead and test it out. I’ve converted the root filesystem on one of my machines already and it works fine. Getting your system to support JFS is (or should be) as simple as executing:

sudo spm repo -s && sudo spm source -aDu linux jfsutils

As for switching a system from ext4 (or other filesystem) to JFS you can backup the content of your existing / partition (and others like /usr, if neccessary) and copy it back after creating JFS filesystem on the partitions you want from a Live CD to external Hard-Drive or even a partition on the same disk like /home. And yeah, I talk about partitions but give examples with mounting points as I can not guess if that would be /dev/sda1, /dev/sdb3, etc.

Cheers!

[1] http://www.phoronix.com/scan.php?page=article&item=linux_313fs_8way
[2] http://www.phoronix.com/scan.php?page=article&item=9way_linux317_fs
[3] http://xfs.org/index.php/XFS_FAQ

LibreSSL replacing OpenSSL

Hello,

Just wanted to let you know that the ports now depend on LibreSSL instead of OpenSSL. There will be problems on upgrades so this post is about how to handle those.

First thing first, make sure that you have the latest checkout of the ports repository:
sudo spm repo -s

After that you must build and merge libressl:
sudo spm --conflicts=False source -a libressl

Then you can optionally rebuild everything linked to openssl:
sudo spm source -aDR $(spm local -pr openssl)

Removing completely openssl from your system will lead to various issues so you better keep it until everything has linked against libressl but you can remove the package entry for it, that is:
sudo rm -vrf /var/local/spm/openssl

We are truly sorry for the inconvenience.

If you wondering what’s the state of Entropy…

…it’s in good shape! There will be a third bugfix release of BFP soon, “world” rebuild to ensure everything in the repos builds and binary tarballs are available on the mirrors, live-tools fixes, along with other housekeeping duties. The initscripts may need some changes to make them more pluggable but that’s it. Once those tasks are complete there are a few to work on mentioned in the tasks tracker.

What’s next? Porting KDE5, maybe. If you have a wish you can open a task or ping us at the forum.

Cheers!

Why bootsplash implementations suck

Hello,

Let me quickly explain why current bootsplash implementations suck, including Plymouth, FbSplash, Splashy and some other outdated.

For best experience there are three main stages in which those are usuful:

1. early initial RAM disk (initrd/initramfs)
2. system initialization
3. system shutdown

For all of them either framebuffer or KMS must be supported and initialized before starting the respective daemon depending on the application (FbSplash for an example can only make use of framebuffer). For the system initialization a proper transition from the initrd/initramfs must be performed and for the system shutdown, well, there isn’t anything special.

Because of those requirements if the processing and transition from initrd/initramfs to the real root filesystem happens too fast none of the bootsplash implementations have the time to react and since upon the switch resources are cleaned up it is not rare that the splash will not appear at all. In our case, Entropy GNU/Linux, the initramfs does only devices setup via eudev that’s it – there is no magic happening in it and the time spend in the initramfs stage is minimal. And if bootsplash did not work in initrd/initramfs it will highly likely not work in the system initialization phase either.

If one puts a sleep statement in the “hook” of the initrd/initramfs all is fine but that’s just plain stupid and the time to be set for the system to sleep will vary but none of the implementations can tell if they actually performed the operations requested (e.g. splash_util -c pain -c setmode will not report failure) so the sleep workaround is the only solution for systems booting too fast.

Default to Homerun desktop in Katana in seconds

Hello,

If you have tried Katana (the fork of KDE we use) than you may notice that the Notebook workspace is not available. As an alternative you can setup and use the Homerun desktop to make use of the screen space well and be more touch friendly if you are using it on that kind of devices, the following video shows how to do it:

SPM binary mode pitfail

Hello,

This post is going to be long so sit tight. First, I will lay down some history, then explain some of the design desicions that had to be made when writing Source Package Manager and finally I’m going to write about one pitfail and how it was solved.

Source Package Manager started as a project to take the best of some of the package maagers out there and improving on that where possible. The idea behind it is that building software should be easy and efficient. So, the SRCBUILD format was made up that holds everything needed for particular software to be build in a single file. It has all of the information needed – sources (tarballs, patches, configs, etc.), pre-defined static dependencies (runtime, build and check), intructions how to build and install the software and what to do when the software is installed, upgraded or removed. The format is Bash, so most of the advanced users out there can write a SRCBUILD in no time without the requirement to learn a new set of skills.

So, as the name entitles it – Source Package Manager was never ment to be a binary package manager. Yet, the feature was requested so many times that something had to be done thus nowdays it has a binary mode – and used to sucks! Why? Because it used the dependencies (depends array) from the respective SRCBUILD to resolve them. And to demonstrate the difference here are the dependencies defined in the SRCBUILD for libreoffice:

boost clucene cairo curl expat graphite harfbuzz icu libjpeg-turbo lcms2 libpng libxml2 mesalib neon nss unixodbc openldap openssl poppler redland zlib gst-plugins-base npapi-sdk zip busybox perl-archive-zip

NOTE: for reference see http://www.entropy-linux.com/wports/web/libreoffice.html

And here are the actual dependencies which SPM detected and has set for it after installation with those detected in bold:

boost clucene cairo curl expat graphite harfbuzz icu libjpeg-turbo lcms2 libpng libxml2 mesalib neon nss unixodbc openldap openssl poppler redland zlib gst-plugins-base npapi-sdk zip busybox perl-archive-zip gcc glibc libxslt raptor xorg-libraries python bzip2 gstreamer glib dbus glu nspr cups fontconfig freetype2 kdelibs qt4

NOTE: for reference see /var/local/spm/libreoffice/metadata if you have libreoffice installed

Now, those dependencies are something that the binary mode did not know of and could lead to faulty software installation because SPM did not pull them and libreoffice would have missing runtime dependencies if one decides to install libreoffice on minimal setup where those are not pre-installed. But here is another thing – explicit runtime dependencies are bad! What I mean by that is that packagers/porters should rarely define them in the depends array of their SRCBUILDs because that’s what SPM was made for – to detect them – and it does that for the most part with some exceptions like Python modules because there are a lot of quircks (try importing .pyc file) to handle with different interpreted languages so SPM does not do that (yet?).

So, to avoid forcing packagers specifying the runtime dependencies only for the binary mode a solution I came up recently – let SPM create .depends file for use with the binary mode. An acompaning .depends file will be create for every software tarball created by spm source -a , spm-tools upload will upload the file and finally spm binary will fetch the file (if neccessary) to read it and resolve the dependencies for the binary tarball. That way, clean SRCBUILDs can be used letting SPM do its thing.

With this change, which is not yet part of a stable release but is pending, the binary mode will be much more robust making SPM closer to what a state of completeness. The only major thing left to fix now is the removal of target that is not in any repository (not a remote) but is installed on the system (local) which can happen when a port gets removed from a repository.

What’s cooking

Hello,

If you have not noticed EFI/UEFI support has been enabled for the kernel and GRUB. The latest snapshot (i686, as of 20150327) should be bootable and installable on such hardware but not everyone has the hardware to test it and feedback is welcome.

Network manager is about to become the default networking tool for the future Live CD/DVD snapshots because there isn’t a featurefull and even complete GUI for connman.

A fresh x86_64/amd64 will be build soon for you to pick, by now it does not have the latest kernel, package manager and even Live CD/DVD installer which are one of the most essential components because they affect hardware support, software management and newcomers the most.

What’s next? You tell us – share your thoughts and experience on the forums, we are looking forward to it.

Cheers!

1 2 3 4