Choice included

Some time ago, Matteo Pescarin created the great "Gentoo Abducted" design. Here are, after some minor doodling for the fun of it, several A0 posters based on that design, pointing out the excellent features of Gentoo. Released under CC BY-SA 2.5 as the original. Enjoy!

PDF SVG	PDF SVG
PDF SVG	PDF SVG
PDF SVG

Cool Gentoo-derived projects (I): SystemRescueCD

Gentoo Linux is the foundation for quite some very cool and useful projects. So, I'm starting (hopefully) a series of blog posts here... and the first candidate is a personal favourite of mine, the famous SystemRescueCD.

Ever needed a powerful Linux boot CD with all possible tools available to fix your system? You switched hardware and now your kernel hangs on boot? You want to shrink your Microsoft Windows installation to the absolute minimum to have more space for your penguin picture collection? Your Microsoft Windows stopped booting but you still need to get your half-finished PhD thesis off the hard drive? Or maybe you just want to install the latest and greatest Gentoo Linux on your new machine?

For all these cases, SystemRescueCD is the Swiss army knife of your choice. With lots of hardware support, filesystem support, software, and boot options ranging from CD and DVD to installation on USB stick and booting from a floppy disc (!), just about everything is covered. In addition, SystemRescueCD comes with a lot of documentation in several languages.

The page on how to create customized versions of SystemRescueCD gives a few glimpses on how Gentoo is used here. (I'm also playing with a running version in a virtual machine while I type this. :) Basically the internal filesystem is a normal Gentoo x86 (i.e. 32bit userland) installation, with distfiles, portage tree, and some development files (headers etc.) removed to decrease disk space usage. (Skimming over the files in /etc/portage, the only really unusual thing which I can see is that >=gcc-4.5 is masked; the installed GCC version is 4.4.7- but who cares in this particular case.) After uncompressing the filesystem and re-adding the Gentoo portage tree, it can be used as a chroot, and (with some re-emerging of dependencies because of the deleted header files) packages can be added, deleted, or modified.

Downsides? Well, not much. Even if you select a 64bit Kernel on boot, the userland will always be 32bit. Which is fine for maximum flexibility and running on ancient hardware, but of course imposes the usual limits. And rsync then runs out of memory after copying a few TByte of data (hi Patrick)... :D

Want to try? Just emerge app-admin/systemrescuecd-x86 and you'll comfortably find the ISO image installed on your harddrive in /usr/share/systemrescuecd/.

---

From the /root/AUTHORS file in the rescue system:

SystemRescueCd (x86 edition)

Homepage: http://www.sysresccd.org/
Forums: http://www.sysresccd.org/forums/

* Main Author:  Francois Dupoux
* Other contributors:
  - Jean-Francois Tissoires (Oscar and many help for testing beta versions)
  - Franck Ladurelle (many suggestions, and help for scripts)
  - Pierre Dorgueil (reported many bugs and improvements)
  - Matmas did the port of linuxrc for loadlin
  - Gregory Nowak (tested the speakup)
  - Fred alias Sleeper (Eagle driver)
  - Thanks to Melkor for the help to port to unicode

DFG magazine "forschung" publishes article about our research group (in German)

The 4/2014 edition of the "forschung" magazine of the DFG, published just a few days ago, includes an article about the work of our research group (in German)! Enjoy!

"Zugfest, leitend, defektfrei"
Kohlenstoff-Nanoröhren sind ein faszinierendes Material. In Experimenten bei ultratiefen Temperaturen versuchen Physiker, ihre verschiedenen Eigenschaften miteinander in Wechselwirkung zu bringen – und so Antworten auf grundlegende Fragen zu finden.
Andreas K. Hüttel
forschung 4/2014, 10-13 (2014) (PDF)

Poppler is contributing to global warming

As you may have noticed by now if you're running ~arch, the Poppler release policies have changed.

Previously Poppler (app-text/poppler) used to have stable branches with even middle version number, say e.g. 0.24, and bug fix releases 0.24.1, 0.24.2, 0.24.3, ... but a (most of the times) stable ABI. This meant that such upgrades could be installed without the need to rebuild any applications using Poppler. Development of new features took place in git master or in the development releases such as, say, 0.25.1, with odd middle number; these we never packaged in Gentoo anyway.

Now, the stable branches are gone, and Poppler has moved to a flat development model, with the 0.28.1 stable release (stable as intended by upstream, not "Gentoo stable") being followed by 0.29.0 and now 0.30.0 another month later. Unsurprisingly the ABI and the soversion of libpoppler.so has changed each time, triggering in Gentoo a rebuild of all applications linking to libpoppler.so. This includes among other things LuaTeX, Inkscape, and LibreOffice (wheee).

From a Gentoo maintainer point of view, the new schedule is not so bad; the API changes are minor (if any), and packages mostly "just compile". The only thing left to do is to check for soversion increases and bump the package subslot for the automated rebuild. We're much better off than all the binary distributions, since we can just keep tracking new Poppler releases and do not need to backport e.g. critical bug fixes ourselves just so the binary package fits to all the other binary packages of the distro.

From a Gentoo user point of view... well, I guess you can turn the heating down a bit. If you are running ~arch you will probably see some more LibreOffice rebuilds in the upcoming future. If things get too bad, you can always mask a new poppler version in /etc/portage/package.mask yourself (but better check for security bugs then, glsa-check from app-portage/gentoolkit is your friend); if the number of rebuilds gets completely out of hand, we may consider adding e.g. every second Poppler version only package-masked to the portage tree.

Broken app-office/libreoffice binary packages generated (NOT app-office/libreoffice-bin)

I'm posting this here because a new LibreOffice version was stabilized two days ago, and at the same time a hidden bug crept in...

Because of an unintended interaction between a python-related eclass and the app-office/libreoffice ebuilds (any version), merging recently self-generated (see below for exact timeframe) libreoffice binary packages can fail to install with the error

* ERROR: app-office/libreoffice-4.3.5.2::gentoo failed (setup phase):
* PYTHON_CFLAGS is invalid for python-r1 suite, please take a look @ https://wiki.gentoo.org/wiki/Project:Python/Python.eclass_conversion#PYTHON_CFLAGS 

The problem is fixed now, but any libreoffice binary packages generated with a portage tree from Fri Jan 2 00:15:15 2015 UTC to Sun Jan 4 22:18:12 2015 UTC will fail to reinstall. Current recommendation is to delete the self-generated binary package and re-install libreoffice from sources (or use libreoffice-bin).

This does NOT affect app-office/libreoffice-bin.

Updates may be posted here or on bug 534726. Happy heating. At least it's winter.

Testers needed for dev-lang/perl-5.20.1-r4 (stabilization candidate)

Most of us in the Gentoo Perl packaging team are already running ~arch Perl even on otherwise stable machines, and Perl 5.20 is looking very good so far. Our current plan is to wait for another month or similar and file the stabilization request for it in February. This would be a real achievement, since we'd at that time actually have the latest and greatest upstream stable Perl release also stable in Gentoo; this hasn't been the case for a very long time.
Of course, we need testers for that; the architecture teams cannot possibly try out all Perl programs in Gentoo with the new version. So, if you're feeling adventurous, and if you are running a fully updated stable system, please help us!
What do you need to do? First, upgrade perl-cleaner to ~arch by placing the following line in your package.keywords (or package.accept_keywords)

app-admin/perl-cleaner

and updating perl-cleaner (to currently 2.19):

emerge -u1a perl-cleaner

Then, upgrade Perl (and only Perl) to ~arch by placing the following exact three lines in your package.keywords (or package.accept_keywords):

dev-lang/perl
virtual/perl-*
perl-core/*

Then, upgrade your system with

emerge -uDNav world
perl-cleaner --all

This should now already be much easier than with previous Perl versions. In theory, all Perl packages should be rebuilt by emerge via the subslot rebuild mechanism, and perl-cleaner should not find anything to do anymore, but we cannot be 100% sure of that yet so far. (Looking forward to feedback.)
Well, and then use Perl and use your system, and if you encounter any problems, file bugs!!!

A final remark, once Perl 5.20 becomes stable you may want to remove above keywording lines from your portage configuration again.