The road to Manchester

September 6, 2010 · Posted in Gentoo, Linux, Travelling · 5 Comments

Some of you might already know that I am moving to Manchester/UK this year ( at least ) to attend a MSc course at the University of Manchester. The Computer Science Department offers a variety of courses hance I am not sure which pathway I am gonna choose yet. The Computer System Engineering MSc looks rather good but I will have to wait for the 1st week of lectures before I make my choice. In any case, moving to UK is quite an experience, and I am really excited about that :)

Even though the motivation about Gentoo development is anything but high, I was quite worried about the fact that I couldn’t bring my two “dev” machines[1][2] with me so all I have is my laptop and my netbook, but lets face it, you can’t do much development on such hardware :-/. I could easily forward a dozen of ports on my router in order to remotely administer all my services but, when it comes to security, this is a serious drawback. This really left me with one choice: Openvpn :). Thanks to this guide, the whole setup was easier than I originally thought. Now, I am able to access my local network from anywhere. Furthermore, tmux[3] makes the whole /remote/development process much easier :). What a great app \o/

[1] Linux Phoenix 2.6.34-gentoo-r6-darth-vader

#1 PREEMPT Wed Aug 25 02:09:42 EEST 2010 x86_64

AMD Athlon(tm) 64 Processor 2800+ AuthenticAMD GNU/Linux

Just for stable amd64 keywording and Server services

[2] Linux Mystical 2.6.35-zen2-dark-jedi #1

ZEN SMP PREEMPT Thu Sep 2 21:19:07 EEST 2010 x86_64

AMD Phenom(tm) II X6 1055T Processor AuthenticAMD GNU/Lin

This is actually a *good* dev machine. The 6-core power combined with 4GB@1066 RAM

is an ideal platform for extensive development and compilation 24/7

* dev-db/mysql-5.1.50-r1: Merge time 2 hours, 7 minutes, 45 seconds ( tests enabled )

* sys-devel/gcc-4.4.4-r1: Merge time 15 minutes, 36 seconds

* sys-libs/glibc-2.12.1-r1: Merge time 11 minutes, 5 seconds

This devbox hosts 6 chroors to test all the Qt4 live versions and one 1 gcc-4.5.X chroot

[3]

Tags: <Gentoo, Manchester, MSc, OpenVPN, UK>

Orphaned packages

August 20, 2010 · Posted in Gentoo, Linux · 5 Comments

Orphaned ( aka maintainer-needed ) packages, are those that nobody, neither a maintainer nor a herd, is looking after them. Such packages oftet get removed from portage because either they don’t work anymore or there are just too many open bugs and nobody really cares about them.

Recently the TreeCleaner Project, as a decent way to inform everybody ( both devs and users ) about packages that are candidates for removal, introduced a new package to track them.

http://www.gentoo.org/proj/en/qa/treecleaners/maintainer-needed.xml

If you want to proxy maintain one of them, just send an e-mail to gentoo-dev mailing list and who knows, maybe a dev will pop up and work with you :-). If you haven’t heard about proxy maintainers before just take a look here and here.

Tags: <Gentoo, proxy-maintainer, treeclaners>

Halevt: A replacement for ivman

August 17, 2010 · Posted in Gentoo, Linux · 2 Comments

It’s been a while since kargig and I worked together to bring sys-apps/halevt to Gentoo portage tree. To be honest, I didn’t quite use it, since all of my PCs where configured to use ivman, so I was too lazy to do any changes. However, due to the upcoming removal of ivman, I decided to migrate all of my PCs to halevt. The migration was quite smooth except a minor ( or major, depends on your point of view ) issue; Removal devices such us USB disks or external HDDs, were mounted just fine, but regular users didn’t have write access to them. Digging around, I found this post on Gentoo forums. What I had to do was to replace every

exec=”halevt-mount -u $hal.udi$ -o sync -m 002″

exec=”halevt-mount -s”

It seems to me that the default conf file that gets installed with halevt is rather useless for normal users because they are unable to write on external devices. If you feel like I should ship another configuration file, optimized for your needs, I am willing to hear your suggestions and come up with a rather convenient file :)

Tags: <Gentoo, halevt>

Why should a package respect LDFLAGS anyway

August 13, 2010 · Posted in Gentoo, Linux · 1 Comment

Following my last post about Gentoo QA and Diego’s one , I will try to explain why this QA issue is that important. As you already know, the Gentoo Council decided to add -Wl,–as-needed to default LDFLAGS. If you don’t know what does this mean, you may want to read this article from the QA documentation. However looking at this traker, I see more than 90 bugs not respecting LDFLAGS at all. Can you see any *doh* here? Yeah thats right. While the move towards -Wl,–as-needed addition to LDFLAGS is a big step forward, the tree is not ready for this just yet. Thanks to Diego’s tinderbox for filling all those bugs, we are now able to fix these packages once and for all.

Recently, a discussion took place on gentoo-dev ML about this issue and as it turned out, few developers didn’t actually know how to track packages that don’t respect LDFLAGS. One way is to read the build system or just observe the output during build time. Another decent way is to add –Wl,–hash-style=gnu to default LDFLAGS. This is how it works: The hash-style ( in our case GNU ) ends up in the final binary. If portage can’t find it there, it simply means that the ldflags where just ignored ( Thanks to Samuli for the explanation ). More info about –hash-style can be found on ld man page.

For our fellow Arch Testers, amd64/x86 pages[1][2] have just been updated to include this piece of information, so unless you want to use my QA powerzz against you, simply adjust your LDFLAGS before you perform any kind of testing.

Update (24/8/2010):

-Wl,–hash-style=gnu is now default on linux/amd64/10.0/developer profile. Lets see if this help us spot more broken packages

[1]http://www.gentoo.org/proj/en/base/x86/arch-testers-faq.xml

[2]http://www.gentoo.org/proj/en/base/amd64/at/index.xml

Tags: <Gentoo, QA>

Should we care about the numbers or the quality?

July 11, 2010 · Posted in Gentoo, Linux · 16 Comments

Today, I am gonna rant a little bit wrt the QA status of many packages residing in Gentoo portage tree. Few of my fellow colleagues think that all that matters is the # of ebuilds in our portage tree. Adding more and more ebuilds in our tree is a good way to prove that Gentoo is an active and cutting-edge distro. Sorry, but you failed :-)

Looking through our QA bugs[1] it looks pretty obvious ( at least to me ) that the ebuild QA level has lower priority than it should be. The most common bugs are

packages that don’t respect the user CC/C{XX}FLAGS/LDFLAGS
wrong dependencies ( listed build dependencies as runtime dependencies )
packages that bundle external libraries == security problems
Badly written ebuilds. Missing || die statements, install precompiled binaries to /usr
etc etc etc

Whilst I do understand that it is not possible to always spot these type of QA errors, this looks quite bad to the rest of the community. Honestly I would prefer a much lower ebuild number on portage but with QA level than having broken ebuilds everywhere just to claim that “Gentoo has the latest version of each package” available.

The lack of manpower problem is more than obvious, so do not be afraid to ask help from our user community. Let them become proxy-maintainers[2] for the packages that you have little or no interest in maintain them anymore. Teach some of them to write proper ebuilds and/or bring them to developer family by mentoring them. Furthermore, if you do not care for a package anymore, just say it out loud and let somebody else maintain it :)

[1]: QA bugs

[2]: proxy-maintainer

Tags: <Gentoo, QA>