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]

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.

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

to

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 :)

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

Beer

Before..

.

After…

The Castle

The Port:

Yeah, so Greece is not just Mykonos ;)

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

There are a number of factors that should be considered before pushing a package into tree. From {C,CXX,LD}FLAGS, use flags, documentation, to multilib support for amd64 platforms, 64bit stability for common 64bit issues such as implicit pointer conversion and many many more. Due to this, we tend to spend many hours digging around the source code, trying to understand how it works, especially when we need to write patches about it. What we usually do is to fix stuff and then send our patches upstream. To be honest I don’t know how other distros work :)

If someone take a look on our bugzilla he will notice many bugs about version bumps of existing packages, feature requests and many more.  One may consider that bumping a package is a trivial process. Well it is NOT!

Every time a new version is available, a series of tests need to be run to make sure we retain a high level of QA in our tree. Such tests involve multiple compilations with various compilation flags, compilers, use flags, etc etc

However, the pressure to ship a ‘famous’ package to the portage tree  is quite stressful leading to broken ebuilds or badly behaved applications. Whilst I do understand the thirst for bleeding edge packages as soon as possble ( I am still a Gentoo user after all ), I try not to distract from my target for high QA on tree packages.

This is basically a reminder to our users that we ( developers ) are users like them, so we do want new and working packages as soon as possible like they do. We enjoy what we do, we want to do that and we want everything to work as expected :)

Gentoo is running again[1] a screenshot contest[2] :)

If you would like to show us your pretty desktop, compare it to others, and see it in our official screenshot page[3], join our competition now.

Rules, details etc can be found on the Contest page.

We are currenlty looking for judges ( from the Gentoo user community ). If you would like to become one please contact us at screenshots[at]gentoo[dot]org

Further discussion is taking place on Gentoo Forums[4]

Happy screenshot taking :)

[1] http://www.gentoo.org/proj/en/pr/2009-screenshot-winners.xml

[2] http://www.gentoo.org/proj/en/pr/2010-screenshot-contest.xml

[3] http://www.gentoo.org/main/en/shots.xml

[4] http://forums.gentoo.org/viewtopic-t-830956.html

I recently purchased a HP Pavilion dm1-1110ev netbook.

First think to do was to stick a nice Gentoo logo  :).

Moving along, since this netbook doesn’t have a cd/dvd rom drive, I used unetbootin to make my usb stick bootable. Using that, I booted up the Gentoo amd64 image and here we are. HP webpage failed ( as usual ) to list the exact hardware specifications so I used lspci to retrieve the hardware information:

00:00.0 Host bridge: Intel Corporation Mobile 4 Series Chipset Memory Controller Hub (rev 07)
00:02.0 VGA compatible controller: Intel Corporation Mobile 4 Series Chipset Integrated Graphics Controller (rev 07)
00:02.1 Display controller: Intel Corporation Mobile 4 Series Chipset Integrated Graphics Controller (rev 07)
00:1a.0 USB Controller: Intel Corporation 82801I (ICH9 Family) USB UHCI Controller #4 (rev 03)
00:1a.7 USB Controller: Intel Corporation 82801I (ICH9 Family) USB2 EHCI Controller #2 (rev 03)
00:1b.0 Audio device: Intel Corporation 82801I (ICH9 Family) HD Audio Controller (rev 03)
00:1c.0 PCI bridge: Intel Corporation 82801I (ICH9 Family) PCI Express Port 1 (rev 03)
00:1c.1 PCI bridge: Intel Corporation 82801I (ICH9 Family) PCI Express Port 2 (rev 03)
00:1d.0 USB Controller: Intel Corporation 82801I (ICH9 Family) USB UHCI Controller #1 (rev 03)
00:1d.1 USB Controller: Intel Corporation 82801I (ICH9 Family) USB UHCI Controller #2 (rev 03)
00:1d.2 USB Controller: Intel Corporation 82801I (ICH9 Family) USB UHCI Controller #3 (rev 03)
00:1d.3 USB Controller: Intel Corporation 82801I (ICH9 Family) USB UHCI Controller #6 (rev 03)
00:1d.7 USB Controller: Intel Corporation 82801I (ICH9 Family) USB2 EHCI Controller #1 (rev 03)
00:1e.0 PCI bridge: Intel Corporation 82801 Mobile PCI Bridge (rev 93)
00:1f.0 ISA bridge: Intel Corporation ICH9M-E LPC Interface Controller (rev 03)
00:1f.2 SATA controller: Intel Corporation ICH9M/M-E SATA AHCI Controller (rev 03)
00:1f.3 SMBus: Intel Corporation 82801I (ICH9 Family) SMBus Controller (rev 03)
00:1f.6 Signal processing controller: Intel Corporation 82801I (ICH9 Family) Thermal Subsystem (rev 03)
02:00.0 Network controller: Atheros Communications Inc. AR9285 Wireless Network Adapter (PCI-Express) (rev 01)
03:00.0 Ethernet controller: Realtek Semiconductor Co., Ltd. RTL8101E/RTL8102E PCI Express Fast Ethernet controller (rev 02)

Quite unexpected. Seems like the whole hardware is compatible with Linux  :)

Since I will use a Phenom II x6 machine to build binary packages for this netbook, I thought it was a good chance to try KDE4 again since as far as I remember it used to work perfectly on my older laptop ( which uses openbox now by the way ). To be honest I got little scared to use openbox here cause I need to make sure that most of the netbook features ( suspend, key maps, hdmi output etc ) will work out of the (DE)box without much scripting/hacking/digging around anyway. However, I am pretty sure I will install openbox on that as well. Anyway…

Surprisingly, KDE4 worked better than I originally expected.

The only thing that didn’t work was the wireless switch so I wasn’t able to switch off my wireless card. Hence I wrote a simple bash script that loads or unloads the atheros modules and putted in on taskbar for quick access. Since loading kernel modules requires root priviledges, I allowed my used to execute that specific command using sudo :)

#!/bin/bash
#check if module is loaded
loaded="$(lsmod|grep -o ^ath[^0-9])"
if [[ "${loaded//[[:space:]]}" == "ath" ]];then
	#modules are loaded so unload them
	rmmod ath9k ath9k_common ath9k_hw ath
else
	#modules are not loaded so load them
	modprobe ath9k
fi
exit 0

and this is the line in /etc/sudoers

hwoarang ALL:NOPASSWD: /home/hwoarang/scripts/atheros

What I haven’t tested yet is the bluetooth and camera support but I can’t say that I really care about them :)

Qt-4.7 now brings Qt-declarative module which allows you to create flexible applications based on QML language. A designer plugin is already implemented on qt-creator in order to help you quickly develop such applications.

Unfortunately, this plugins requires private headers for Qt4 library so I needed to edit qt-{core,gui,script,declarative} ebuilds to install those private headers. Qt upstream inserted a special configure switch to use when you build your Qt4 library (-developer-build) but I decided that rebuilding the whole Qt library for that was too much.

What I did was to introduce a new use flag ‘private-headers‘ on those ebuilds.  So if you want to have a fully working qml+designer support on qt-creator do the following:

edit /etc/make.conf and add private-headers use flag on USE variable. Then run

USE=”qml” emerge qt-creator

Before merging qt-creator, portage will rebuild qt-{core,gui,script,declarative} ebuilds in order to have those private headers installed.

Then Qt-creator *should* merge fine and here is the expected result :)