In case you were wondering what the hell is happening with gnome 2.26 still sitting in the overlay, well, we started moving it to the tree. It's going to take a while before everything is in tree but it is on its way. Don't forget to fill bugs if you find one that is really new so we can write a nice upgrade guide if needs be. For now the only issue is the gnome-desktop upgrade that needs a nice message for non-portage-2.2 users but we are not there yet.

For a small team, deploying 3500 XO laptops in 10 schools is a significant challenge. The difficulties include assigning the correct number of laptops to each class, ensuring that each child has a laptop, and having some way of tracking which child owns which laptop for the purpose of future tech support and repairs. Additionally, the handout process can be difficult - children are extremely excited to receive their laptops, hence the classroom environment can easily ascend into chaos, becoming rather stressful. The children also need some initial guidance to complete the installation (entering your name, and choosing colours for the sugar interface).

For the OLPC Paraguay deployments in Caacupé, we created a system which worked rather well. Actually, the basis of it was shamelessly copied from Uruguay, as recently observed by Sebastian Codas.

First, the preparatory stages:

1. The teacher of each class creates a register of their students, including their national ID number. (In Paraguay, the children are required to obtain national ID before receiving a laptop, whereas having national ID at that age is ordinarily quite rare. The huge increase in the number of children with ID in Caacupé is another significant success of this project.)
2. The principal of each school submits all the registers to ParaguayEduca.
3. The registers are entered into ParaguayEduca’s inventory system.
4. The inventory system generates a label for each laptop, including: student’s name, class, school, and a random, unique ID. The unique ID is also printed on the label as a barcode.
5. When printing the laptop labels, the inventory system also generates the labels to go on the laptop boxes (up to 5 laptops per box), including: school, class, and total number of boxes that should be received by that class. Laptops are combined into boxes by classes - no box ever has more than 1 destination.

Secondly, the process of applying the labels:

1. Each box of 5 laptops is unboxed individually.
2. The pages of labels (many per page, grouped by destination classroom) are cut up into individual labels.
3. The laptop labels are stuck to the laptops, inside the battery compartment.
4. Each laptop is scanned into the inventory system using a USB barcode scanner. Note that two barcodes are scanned per laptop (which are next to each other): First, the label with student information as described above; second, the already-present barcode that shows the serial number of the laptop. This creates an association between the unique serial number of each laptop, and the student that will receive it.
5. The laptops are reboxed, with the appropriate labels being stuck to the box.
6. The laptop boxes are stacked according to which school they are heading to.

Labelling laptops in the warehouse

Finally, the delivery:

1. The laptops for an entire school are loaded into a truck.
2. We drive to the school.
3. We request the help of 15 or so of children from upper grades, ones that can carry laptop boxes.
4. We unload each laptop box from the truck, giving it to a child. An accompanying teacher clarifies the exact location of the classroom, and the children move the boxes.
5. In the classroom, a volunteer explains the process to the teacher: 5 laptops per box, each laptop has a label. Simply read out the student’s name as printed on the laptop, insert the battery, hand over the laptop and a charger, and move onto the next one. Note that no registration or paperwork is needed here (it was done much earlier), it is literally handing out the laptops to excited children.

Easy laptop handout process

There are several nice points about this system. Firstly, laptop handout, which can be a stressful and difficult process, is now incredibly easy and can be done by anyone (all the difficult parts including paperwork have been done beforehand), allowing us to harness a group of local volunteers without any prior involvement in the project. Secondly, the information (student name and class) visible on the label can be easily used by anyone to return a misplaced XO to its owner, and further enforces the principle of child ownership. Thirdly, it’s quite failure-proof: the label is inside the battery compartment so is unlikely to be lost or damaged, but even if so, a new label can be easily generated from the serial number of the laptop (which is very difficult to displace, being additionally stored on a chip inside the laptop!).

However, no system is perfect. Any system which requires someone to do something 3500 times — such as slicing and applying labels — is time consuming and prone to human error. We were a little low on space, in a hot and smelly warehouse. Nevertheless, the project itself and the experiences in the schools were more than enough to keep us motivated.

It’s amazing to look back on the week and to see how much work was done, even if we did start at 5am every day! Within 4 days, we completed entering the registers into the inventory system, finalizing and testing connectivity and electricity at schools, printing labels and labelling laptops, and of course delivering laptops to schools and assisting the handout.

For quite a while now, Gentoo has used the plugdev group as a catch-all for Things-You-Need-Special-Permission-For-On-Desktops.  This includes automounting (what it was originally for), dbus policy, networkmanager policy, and so on.

As of today, modulo bug # 268223, I have what appears to be a full working desktop without being in the plugdev group.  This means, in my opinion, that policykit/consolekit is fully useful on Gentoo.

If you’re not using eix, you probably are not (or shouldn’t be) using Gentoo. It’s simply so powerful and fast, that I can’t imagine working on Linux without it. For those not following Planet Larry, I’d like to point out the tip posted by Matija Šuklje about eix-sync. Use it!

My quest for MIPS N32 firefox could finally come to an end, since I just got it scores the same as X86 firefox.

Remember I said it would encounter bus error on a few websites in my last related post. But I didn't plan to look into this issue before dealing with cache aliasing problem.

However, since Rayson Ho helped me to locate the exact cause of this issue, I decided to finish it first.

The problem is caused by unaligned access of ldc1/sdc1 instruction. These two instructions' operand must be 8 bytes aligned. But when crashing, the operand is only 4 bytes aligned.

After some discussion and experimenting, I found a workaround for sina.com.cn crashing problem. Yeah, a padding pointer sounds scary and fragile, but it did work. Before posting any comment to this, please make sure you have read all the emails in that thread.

Then Fai Wong reported to me that it still crash in acid3 test. So I took another look. This time the problem happened in a different location, and it is harder to solve. Because the object in question sometimes is 8 bytes aligned, but sometimes it is only 4 bytes aligned, which does not make any sense, since the object contains double variable. So, either way, the double variable just can't get aligned in both case. I thought of kernel exception handler. I did come up with a patch and it worked! But since Ralf refused to accept it, I had to move on. And I found the reason is because of the way the memory is allocated - placement new. Thanks to LI Daobing for telling me this. And this is what the final patch looks like.

I recently moved from using pidgin to using bitlbee (net-im/bitlbee). Bitlebee is sweet because it allows me to access "traditional IM" via irssi in a screen session from anywhere that I am via my co-located server. Of course, you can use any irc client that you are familiar with. As more and more of my friends move away from traditional IM, I don't feel a need to pay as much attention to the various networks. So, it can stay off my desktop without worries. Do you use bitbee? Any fun tips?

Gentoo has been accepted for its 4th consecutive year in the Google Summer of Code! Check out our GSoC 2009 homepage if you are interested in this year's GSoC for Gentoo.

If you'd like to apply to be a mentor, you can do so on the webapp. Please read the mentoring guide before applying.

Interested students can browse Gentoo's project ideas and student applications will be accepted starting March 23rd.

The Gentoo embedded team would like to announce that we will be automatically building and releasing stages for ARM and SuperH/SH. We hope these stages will help out people interested in developing embedded linux applications.

On the ARM side, we are currently releasing stages for the following CHOSTs:

• arm-unknown-linux-gnu (old ABI, in progress)
• armv4l-unknown-linux-gnu (old ABI, in progress)
• armv4tl-softfloat-linux-gnueabi (EABI)
• armv5tel-softfloat-linux-gnueabi (EABI)

On the SuperH/SH side, we are currently releasing stages for the following processors:

• sh4
• sh4a

The stages are available under the /releases/arm/autobuilds directory for ARM and /releases/sh/autobuilds for SH at your favorite mirror.

Because building stages for these architectures takes a while, we plan on releasing stages on a monthly or bi-monthly basis. If you would like to talk about Gentoo on those architectures, please join us on #gentoo-embedded @ irc.freenode.net.

We would like to thank QNAP Inc. and Marvell Technology Group for providing us with support and hardware for ARM based chips. However we would like to expand our ARM support to the armv6 and armv7 processors. If you or your company can provide us with some hardware we would greatly appreciate it. Please contact the Gentoo ARM team if you or your company are able to assist us.

We would like to also thank Renesas Technology Corp. who has graciously provided us hardware and support for the SuperH platform.

As you can see, your favorite website now displays more information, reflecting the activity that's been going on behind the scenes all along. Thanks to popular demand, the latest blog posts from planet.gentoo.org, packages from packages.gentoo.org and security announcements are summed up on Gentoo's home page.

Discuss this!

What: Gentoo contributors get together to help each other fix bugs

Where: irc.freenode.net, #gentoo-bugs

When: Saturday, January 3, in a timezone near you

What do you need to bring?

• A Gentoo system, an Internet connection and an IRC client
• Your bug. If you don't have one, we will find you one to suit your area of interest and your skills
• Your favorite editor
• A way to test that your bug is fixed (asking people counts!)
• You don't need to know C, C++, or bash

What's a bug? Gentoo's way of tracking change requests. A change request can be anything from "I've found a typo in foo" to "I've built this really useful program called bar but there's no ebuild for it." Bugs have various levels of helpfulness, from identifying the existence of a problem to localizing the problem to providing the patch to fix it.

There are bugs in documentation such as man pages as well as ebuilds and the source code that Gentoo distributes. These bugs are problem reports. Bugs for things Gentoo doesn't do yet but you think should be done are feature requests. Bugday is more about fixing problems than adding features, but you won't be turned away if you want help with a new feature.

Want to know more about Bugday? It's held on the first Saturday of every month. It's an opportunity for everyone to contribute to making Gentoo better, and eventually you might even become a Gentoo developer. See the Bugday project page for more details.

Bugday is about community spirit. Gentoo is a community—there is no "me" and "them", there is only "we," so instead of lobbying for "them" to fix your particular bug, work together to fix it! Bugday is an opportunity to get help to help yourself.

If you've been wanting to get involved but weren't sure how, Bugday is a great way for you to see what goes on in making a distribution and get involved in Gentoo.

Discuss this!

Roy Bamford contributed the draft for this announcement.

The time has come! Our release engineers have been refining their automated builds of the minimal CD and stage3 tarballs, and the first builds are uploaded to our mirrors. Select your favorite mirror and navigate to the /experimental/ directory. Under the x86, amd64, ia64, alpha, and sparc64 architectures, the autobuilds directory contains stages. So far, minimal CD images are only available for x86 and amd64.

We're still working to add automated builds for ppc, ppc64 and hppa as well as CD images for architectures lacking them. We built the stage3 tarballs from the latest stable packages. Fresh builds will show up every week, although sometimes we might skip a week if build problems crop up.

Because these builds are automated, they have not been rigorously tested as the old releases. Occasionally, you might run into problems. If that happens, just try a file from a different week.

Please try out these new builds and leave your feedback on the forums. As always, please report any bugs on Bugzilla.

Happy holidays!

Discuss this!

Ben de Groot contributed the draft for this announcement.

The November issue of the Gentoo Monthly Newsletter has been released. In this month's issue: Kernel team, Incognito, Gentoo-wiki returns, and more!

Discuss This!

The September issue of the Gentoo Monthly Newsletter has been released. In this month's issue: EAPI-2 approved, Gentoo-Quebec training, learn to use iotop, and more!

Discuss This!

In future releases, Gentoo will focus on a more back-to-basics approach that will give you up-to-date install media on a regular basis and make much better use of our human resources. We're looking into automated weekly builds of the minimal CDs and stage tarballs as well as maybe an annual LiveCD release. We will keep you updated as we decide on the details of this new approach.

Consequently, we're canceling the 2008.1 release. The release engineering team has to reconsider its priorities—we overstretched our human resources during the prolonged 2008.0 release process. This caused too much stress for our release engineers and multiple postponements of the release.

You can help! The release engineering team is looking for new volunteers because it perpetually has a severe lack of manpower. We are particularly looking for people with a good grasp of ebuild development and the ability to debug/fix problems that crop up during building and testing of the stage tarballs and ISO images. We will update the staffing needs page with more details.

Discuss this!

Ben de Groot contributed the draft for this announcement.

What: Gentoo contributors get together to help each other fix bugs

Where: irc.freenode.net, #gentoo-bugs

When: Saturday, September 6, in a timezone near you

What do you need to bring?

• A Gentoo system, an Internet connection and an IRC client
• Your bug. If you don't have one, we will find you one to suit your area of interest and your skills
• Your favorite editor
• A way to test that your bug is fixed (asking people counts!)
• You don't need to know C, C++, or bash

What's a bug? Gentoo's way of tracking change requests. A change request can be anything from "I've found a typo in foo" to "I've built this really useful program called bar but there's no ebuild for it." Bugs have various levels of helpfulness, from identifying the existence of a problem to localizing the problem to providing the patch to fix it.

There are bugs in documentation such as man pages as well as ebuilds and the source code that Gentoo distributes. These bugs are problem reports. Bugs for things Gentoo doesn't do yet but you think should be done are feature requests. Bugday is more about fixing problems than adding features, but you won't be turned away if you want help with a new feature.

Want to know more about Bugday? It's held on the first Saturday of every month. It's an opportunity for everyone to contribute to making Gentoo better, and eventually you might even become a Gentoo developer. See the Bugday project page for more details.

Bugday is about community spirit. Gentoo is a community—there is no "me" and "them", there is only "we," so instead of lobbying for "them" to fix your particular bug, work together to fix it! Bugday is an opportunity to get help to help yourself.

If you've been wanting to get involved but weren't sure how, Bugday is a great way for you to see what goes on in making a distribution and get involved in Gentoo.

Discuss this!

Roy Bamford contributed the draft for this announcement.

The August issue of the Gentoo Monthly Newsletter has been released. In this month's issue: PHP4 removal, GSOC interview, new Gentoo-based distributions, and more!

Discuss This!

After many years of good service my old HP Compax nx9005 had to be replaced by a younger model...and there it is the Dell Vostro 1510. Although I wanted to buy an AMD-based laptop again my choices where so limited I went with Intel. Anyway, the processor is a T8100, 3GB of RAM (so I stay with x86), 250GB of hard disk space, a non-glare TFT panel with 1440x900. Really a nice piece of hardware although the keyboard sounds a bit flaky. Gentoo is now installed on it and apart from some glitches (no working backlight dimming yet) it is rock-solid.

I have been experimenting with Qt Creator since the first release. I have always preferred a minimal editor for development work, with my main needs being good syntax highlighting, the ability to switch between different files quickly and something that stays out of my way as much as possible. Previously I had used Vim, Kate and several konsole instances the majority of the time.

Recently I have been looking for something with better integration, and so had been slowly keeping an eye out for a lightweight IDE. My main requirements were something lightweight, good C++ support, ideally good Qt support and CMake integration. Over the weekend I tried the latest Qt Creator 1.1 release and was really impressed.

Seb Ruiz made a great post on Qt Creator 1.1 that summed up many of my thoughts, and gave a quick walkthrough. It was not immediately obvious how to import a CMake project, I was looking for an import project option. All that is necessary is to go to file and open. You can then open the base CMakeLists.txt file for your project and the CMake plugin will do the rest.

From there on in you get great integration with the build system, version control (Git and friends), and your friendly GDB debugger. Under projects you might want to quickly add -j5 (if you are lucky enough to have a quad core machine) to the additional arguments input for make, and select the main executable target for your project if you also have several other executable targets (unit tests etc).

The first time you debug a project you will be prompted to build the Qt debugger helper. Then the integration with GDB really wins over using GDB directly, or using ddd which I had been using more and more recently. I would highly recommend trying Qt Creator if you are looking for a lightweight, cross platform IDE. There are certainly other great IDEs out there, but I think that Qt Creator is a great fit for my development style (and may be yours).

I recently ran into an issue where I wanted to move several KVM based virtual machines from one server to another server. There’s several ways you can accomplish this depending on what you want to do. In my case I was using LVM for the disk backend, so simply copying the disk image files wasn’t an option. It boiled down to two basic options.

• Put system in single-user mode, rsync the contents over, and reinstall grub
• Use dd and copy the whole LVM volume over piped through ssh

The advantage using the rsync method is that you’re only copying the files you need over, thus less data transfer happens. But then you run into needing to re-run grub (which generally isn’t a problem). In addition, if you’re using LVM within the LVM volume for the VM and the volume group is named the same, you run into some interesting issues. The advantage for using dd is that you can get a literal copy of the disk image and just start the VM back up without any other steps. Of course, this will only work if the volumes are the same on both ends.

So I decided to go with dd but ran into a problem of seeing the progress of a 15G volume copy. I did some digging around and found a blog post that mentioned using a command line application called ‘bar‘ so I decided to give it a shot! Its a fairly simple application that just creates a basic progress bar based on the data being piped into it. If you’re running Gentoo, the package is called app-admin/bar.

Here’s the command I ended up running:

dd if=/dev/lvm/cholula-disk | bar -s 15g | \
    ssh -c arcfour $host "dd of=/dev/lvm/cholula-disk"

When ran, it gives you output similar to:

6.0GB at   17.9MB/s  eta:   0:08:32   40 [=========================                 ]

The downside is that you need to specify the block device size before hand, but for something simple like this its quite nice. Of course I could just use one of the many dd forks out there which include progress bars but this is quick, dirty, and simple!

I used the arcfour cipher mainly to reduce the CPU overhead and increase the throughput, but you should probably never use this cipher on an untrusted network as it does have weaknesses. I didn’t try doing throughput tests on other ciphers, but it would be interesting. It took me approximately 10-12 minutes to copy a 15G volume over a gigabit network which isn’t too bad.

Another trick you can do is utilitize the LVM snapshot feature and create a snapshot of the running volume. If any data changes on the volume, it won’t be copied over obviously, but it will at least let you do a cold “live” migration of sorts.

Are you tired of laying around the apartment, wishing you had something fun and productive to do?

NOW YOU DO!

We have 400* open bugs assigned or CC'd to maintainer-needed in bugzilla. Many of these are easy fixes, like packages not respecting CFLAGS, or CC hardcoded, or missing dependencies. You (yes, you) can earn the admiration and respect of your peers** simply by fixing _one_ maintainer-needed bug per day. How much easier could it be? And, in a limited time offer, if you go as far as to find a maintainer or herd for a maintainer-needed package, you'll receive a miniature Larry the Gender-Confused Cow bobblehead absolutely free of charge***.

Act now, repoman is standing by.






* okay, 399.
** okay, just me.
*** okay, not really

Continuing from part 1:

After several hours of preparation in the gloomy hours of Tuesday morning, we hopped in the truck and returned to the school of Tiniente Fariña to deliver laptops to the students who attend the morning shift. Everything went smoothly, as the teachers had already learned the handout process from doing it in the previous afternoon.

Following on, we delivered to the rural school of Daniel Ortellado. Like many schools, this one has now been themed for OLPC by the students and community. You can see one of the several XO logos freshly painted on the exterior in the photo below, and note the new colours of the classroom interior.

Next up was the lovely school of Profesor Cabrera, slightly off out into the countryside. We arrived with perfect timing; the children were lined up in the courtyard, teachers and parents seated, ready to commence the ceremony. This video captures the excitement. Soon after, the children began to chant ‘X-O-X-O’ at the tops of their voices. After some brief talks including one from the governor of Caacupé, we handed over 6 laptops (one to each child from each grade) and then moved into the classrooms to hand over the rest.

In the afternoon, we headed to Cristo Rey. This school was a little different, as at least for the younger grades, all the parents were present and they were the recipients of the laptops (before passing them onto their children later). The sheer number of people in the school made things a little more chaotic, but it was evident that the teachers had planned the procedure in advance and were well prepared for the handout.

We used Wednesday to take care of some of the smaller schools. Bright and early was Raúl Peña. It was interesting to see children head straight for the internet in this school, whereas in other places, Speak and Record were the first instant-hit activity epidemics. This school is located near the main WiMaX base station which provides internet to all 10 schools, and hence has an impressively speedy connection. The internet connections are provided for free by Personal, a loyal sponsor of the project.

Next up, we delivered to Santa Teresita Cabañas, a rural school. This school is tiny but in some ways that made the event even more significant; the children and parents had actually turned up eagerly in the morning even though we told them that we would not be arriving until the afternoon! They held a very cute ceremony with an impressive dance performance, and then we handed out laptops to the entire school on-stage.

Somehow still on schedule, we headed to Dr Pino to conclude the day, another rural school. Many parents were in attendance of the handout.

more photos on flickr.
Continue reading part 3.

Continuing from part 2:

We finished the deployment on Thursday morning with two of the larger schools. First thing, we went to Tiniente Aquino, in time for their ceremony. While quite used to these now (various talks and testmonials, press, the national anthem and a dance performance) it was again exciting to witness the excitement in the air. At the close of ceremony we went into the classes and initiated the handout.

Now experts in the art, we arrived at the final school (for now), Herminia Machada. The introductory ceremony featured a dance including an XO laptop! Everyone was very friendly and after a small hiccup with the server, everything was fine.

To mark the end of the deployment, we returned to the school of Daniel Ortellado, where a lunch had been prepared for the whole team. We then spent some time with children exploring their laptops. As we sat down for a group photo, more and more children came over to take photos using their laptops, refusing to let us leave before they had captured the moment for themselves. For us, it was a nice point on which to end the week.

Of course, with only a small team distributing almost 1000 laptops per day, some hiccups are inevitable. The worst error was when we accidentally missed 6 classes when deploying at one school, but with support from the teachers we finished everything off a few hours later.

Some children had not been correctly registered with us, so did not receive laptops initially. Try telling a child that there is no laptop for them when all of the other children are turning theirs on for the first time. Raúl was so touched by one teary-eyed girl in this situation that he actually gave her his personal laptop, but after a few minutes of exploring she was considerate enough to hand it back and wait a day or two for us to solve the problem.

Another difficulty is with faulty laptops; only a few have been reported so far, but it’s difficult when you encounter them. Our strategy for this and for missing laptops was for the teachers to make a list of problems to hand to the principal of the school. With our tight schedule, it was simply not possible to fix the problems on-the-spot, but we managed to attack them school-by-school in timely fashion.

ParaguayEduca officially formed less than a year ago, so it is a great achievement for them to have now saturated 50% of a big city through deployments in 5 rural and 5 urban schools. Funds have already been secured to purchase laptops to saturate the other 50%. The support from sponsors, teachers, parents and communities here is incredible; the combination of public and private sector interest plus links to government seems to be the perfect recipe for such a project in this country.

Of course, this is not the end of the OLPC Paraguay implementation, it is merely the start.

Man, it's been awhile since I blogged. I meant to keep putting up a monthly Xfce desktop, share some tips, talk about the latest Gentoo work, etc. And then real life got in the way.

Laptop

I killed yet another piece of hardware when updating my Thinkpad R61i on Friday. I've been sick this whole week, so I had some free time. The laptop hadn't been updated since early February, so there were 176 packages, including the big move to GCC 4.3, which necessitated a system rebuild. Unfortunately, I left the battery in while the system was on AC power for the compiling work. I guess the heat must have built up too much, because the battery got fried. Got the dreaded "battery light flashes amber rapidly" error. So now I only have the extended-life battery, which is heavier and bulkier.

Add that to the list of hardware that compiling Gentoo has killed over the years. The list includes another battery, an external power brick, an internal PSU, two motherboards, two RAM sticks, one RAM slot, two hard drives, and a fan. I'm really on a roll, here.

I still can't find a replacement battery for less than $90, even on eBay, so I may hold off. What I did do was order two more gigs of RAM, to bring the total up to 4GB. Only cost $40 at Amazon, free shipping. Why the RAM? While updating, I ran into the dreaded OOM-killer! The GCC 4.3 compile uses more than the 2GB available and it aborted the merge. This was with nothing else running, too. So be warned: if GCC dies when you move to 4.3, back off on your MAKEOPTS. I had to adjust mine from -j3 to -j2 while compiling GCC and glibc.

Also, while I was updating my whole system, I decided to move the rest of my X/kernel stack to ~arch, as I wanted the new Intel KMS/GEM/UXA hotness. This necessitated using ~arch xf86-video-intel and Mesa, as well as ~arch gentoo-sources, as 2.6.29 has some needed code not present in 2.6.28. I discovered that while this part of the graphical stack was just fine for KMS and fast graphical login, xorg-server-1.5.3 resulted in hard lockups as soon as I opened any windows. I had to grab xorg-server-1.6, libXfont, and randrproto from the X11 overlay in order to get a usable environment. It works great! No more lockups.

So, how much of an improvement is the new stack over what was available in February? I'll let the following numbers speak for themselves. These are the median-high numbers recorded. For the old stack, the numbers varied from 48FPS to 59FPS. For the new stack, from 489FPS to 504FPS. Sync to vblank and vsync have never been enabled.

xorg-server-1.5.3-r1, libdrm-2.4.4, xf86-video-intel-2.6.1, mesa-7.3, gentoo-sources-2.6.27-r8

$ glxgears 
Failed to initialize GEM.  Falling back to classic.
292 frames in 5.0 seconds = 58.272 FPS

xorg-server-1.6, libdrm-2.4.6, xf86-video-intel-2.6.3-r1, mesa-7.4, gentoo-sources-2.6.29-r1

$ glxgears 
2516 frames in 5.0 seconds = 503.174 FPS

Now, the usual caveat about glxgears not being a good benchmarking tool applies here. However, it is useful for relative comparison from one version to the next. And as you can see, it's an order of magnitude better. I notice that stuff is drawn much smoother; there's less flickering especially when shifting Terminal windows around. And I haven't hardly begun to tweak my system for best UXA performance. KMS is nice and smooth; it happens pretty quick in the boot process. No more flickering, just fast loading of SLiM and then Xfce.

My xorg.conf is pretty minimal; the only changes I've specified for the Intel driver section are these:

Option	    "FramebufferCompression" "false"
Option	    "AccelMethod" "UXA"
Option      "Tiling" "false"
Option      "EnablePageFlip" "true"

There are probably some other things I should add for maximum performance, so I'll have to spend several more days hunting for 'em. But out-of-the-box, I'm extremely impressed with the current X stack.

Now all I need is smooth full-screen Flash video performance . . .

Xfce 4.6

The other thing I put on the laptop was Xfce 4.6.1. Decided that as long as my core graphics stack is part ~arch, it wouldn't hurt to try out the latest and greatest Xfce hotness. Now that some outstanding bugs were fixed from 4.6.0 (including a remote security bug, and an icons issue), I thought it'd be worth it. It's pretty slick. The desktop environment is initialized a bit faster than even a fully tweaked 4.4.3.

About the only outstanding issue I have with it is that there is no graphical menu editor. At first, I couldn't get a satisfactory menu even editing the XML file by hand; it was just too different from the old one. So my menu was cluttered with useless toplevel entries, such as Web Browser, File Manager, and so on. Fortunately, Mike pointed me to the solution, so now all offending stuff has been cleared out. Right now my menu works just fine, so I only really need a graphical menu editor for convenience's sake.

I really like 4.6 a lot. The artwork packaged with it is outstanding; I'm using one of the stock backgrounds because it's just that sexy.

Xfce 4.6 is a smash hit, so well done, guys. Very well done. And there's even more good stuff planned for the future. There's a great interview on Planet Xfce with one of the core developers. He discusses some of the exciting stuff coming down the pipe for Thunar, so make sure to read it.

Gentoo

I've been rather quiet on the Gentoo front for the last three months, because life in the outside world has a way of unexpectedly intruding on me. I've been on devaway since February while I try to get stuff into some semblance of order. Sadly, however, I've had to do much more documentation work than I originally scheduled, which keeps cutting into my plans for other areas. I've made a bunch of bugfixes and commits over the last couple of weeks especially. One of the most visible changes is in the Get Gentoo page, putting the automated weekly builds at the top. The handbooks will be updated, too, but they require a tremendous overhaul, so I'll need all the resources of my fellow GDP members to accomplish that. If I can get 'em, that is.

One of the other things I like to do is find some interesting little-known application, determine its usefulness, then hack up an ebuild for it. It's really good practice, actually.

Out of all the applications I've written and updated ebuilds for, the only one that's got me stumped is WordGrinder. I've been in contact with WordGrinder's upstream author, who's a really helpful guy, but I still can't get the ebuild working. While compiling and installing by hand works great, something happens during the compile phase as run by Portage where it violates the sandbox, killing the merge.

Plus, given the pmfile used by the package, it doesn't really respect a user's CFLAGS/CHOST and related configuration. That has to be altered somehow, so I've been trying to work out a similar solution to the one used by our dev-lang/lua ebuilds. No real luck there, but it's not my first priority. What I really want to do is have the merge workin' with Portage. So it's an interesting, informative, occasionally frustrating learning process.

Anyway, take a look at all the stuff in there. I recently reorganized the ebuilds by category/package, instead of dumping everything into a single directory. Some of these have since moved into Portage sometime after I wrote the ebuild for 'em, and some (like Songbird and WordGrinder) are works in progress. I've run into quite a few nifty apps; places like GnomeFiles are excellent resources. Most of the stuff in here I discovered on GnomeFiles, and a lot of the packages on the website are simple enough that it's just a few minutes' work to hack up an ebuild.

This marks the end of an unforgettable week for me and the team at ParaguayEduca. Within 4 days, we completed the deployment of 3500 laptops in the city of Caacupé, Paraguay, reaching about 50% of the city’s children aged 6-12. After working close to 16 hours every day, we may have lost out on some eating and sleeping but every minute was worth it!

The week really started on Saturday, when a couple of team members headed to Caacupé to start the process of labelling laptops which I will write more about the other time. They were assisted by a group of volunteers.

On Sunday, the rest of us travelled to Caacupé with high spirits. We are lucky enough to have been given a beautiful, enormous old house in the city which we stayed in for most of the week. We did some planning and set up camp.

Monday started at 4am, a pattern which repeated for the whole week. Most of the team went to the warehouse to continue labelling; I went to finish off some infrastructure and testing work in some schools. When 9am arrived, I had already been working in 6 schools that day. The next step was preparing for the grand symbolic event representing the introduction of the laptops, at the school of Tiniente Fariña. Everything was wonderfully prepared; we had a large audience, lots of press, and had the presence of various important people including the minister of education and the vice president. After various talks and a performance from a well known Paraguayan music group, we handed over the first 10 laptops, to 1 child from each school.

At the close of the event, the children went to their classes and we started the laptop handout for the afternoon students at Tiniente Fariña. Everything went smoothly, I will be writing more about the actual logistics another time. There was much excitement in the air.

Late in the afternoon, we went to the second school, Municipal Santa Teresita. As we walked in carrying boxes, we were greeted with a huge cheer and many smiling children! Another symbolic ceremony was underway, for the parents and children of the school. We began handing out the laptops on stage and moved inside when it got dark. The children were very excited, applauding every single recipient of a laptop, but to my amazement were obedient enough to leave the school without turning on their laptops. The teachers wanted them to wait until the following day, when they would have time to assist the students getting started.

One of the most amazing aspects of the week was simply the excitement of the children. With all of the media attention of the Paraguayan project and the amazing support of teachers and the community, the children were very aware that they would be receiving laptops! Most schools had an opening ceremony, and many have been decorated accordingly. The students had produced various artwork and posters.

More photos on Flickr.
Continue reading part 2.

Last night I keyworded vanilla-sources-2.6.30-rc3. If you're an alpha user, please test this kernel as it's our first shot in months to get Xorg-1.5 into working order. If you feel adventurous, you can also keyword Xorg (and all it needs) and give it a spin. Currently, the glint/Permedia driver is broken, but nv/nvidia cards should work.

I know, I know, I should post more often. I have no excuse and as such will cut to the chase: where we are alpha-wise at the moment.

Xorg 1.5+

The patch from Ivan has finally made it into the mainline kernel. The earliest vanilla version having it is 2.6.30-rc2. I'm currently running that kernel and xorg-1.5 on my dev/testing machine and it's looking good so far. There still is a problem with the glint driver, but I suspect that is independent of the PCI access patches. The "nv" driver works perfectly.

Originally, I had hoped I could get them included in .29 or 29.N, but it was not to be. In the course of working for that I asked myself how much pestering a kernel developer is willing to put up with (and what a sign of annoyance would look like with Ivan). I would have loved to see more/quicker progress, but when people stop reacting to your mails at all, you start to second-guess yourself.

AGP on the UP1500

Matt has done a superb job of finding out email addresses and other contact info regarding the PALCode sources. For those don't know: the PALCode is a sort-of BIOS the Alpha architecture uses. As such it is one of the key reasons why the AGP port on the UP1500 is little more than a glorified PCI slot currently: AGP 4x does not work at all because there are bugs in the PALCode. Since the source to that was never published and binary-patching such a crucial piece of software (without knowing what you're doing) is an exceedingly bad idea, getting the PALCode for the UP1500 is just about the only way this will ever get fixed. Unfortunately, there are several different owners of the IP in the PALCode source. We'll keep you posted on the progress regarding that.

In a related note, Matt keeps trying to get Hewlett-DEC-Compaq and subsidiaries to release any piece of source code from the CCC (C compiler) and related libraries (especially the math library). No luck yet, but Matt can be very persistent, I have learned. ;)

Moreover, Matt has created a patch page on the AlphaLinux wiki. Right now, there are patches for the kernel futex implementation (what caused the tst-robust1 freezes in the glibc test suite), a patch for several math functions in the glibc (have been broken since forever) and a patch for ed which fixes a certain set of compile-time optimizations.

General package status and workforce/load

Armin76 and I are able to stem the package work tide (testing, keywording, stabilizing) as it is now. But if one of us can't commit the necessary time (several hours a week, I'd guess), things will start to pile up. Fortunately, Matt has sent in his archtester's quiz and as soon as I find the time, I will give it a thorough look and work with him to get him up to speed. Even if he hasn't commit rights, not having to watch stuff compile all the time will bring down our workload.

Security bugs

Nothing terribly newsworthy, I'm trying to get to them quickly. If you see a slow sec bug that we might have overlooked, feel free to bug me by mail or us by IRC (Freenode/#gentoo-alpha).

Hardware and Performance

I recently benchmarked the UP1500s IDE controller (ALi M5229) with a Maxtor 120G disk against a SymBIOS Logic 53C895 with a 33G Seagate Barracuda. Even through the SCSI disk is quite a ways older than the IDE disk, it outperformed the IDE disk in all disciplines (except seek times, but the IDE disk won by a hair there). So I went and looked up pricing for U2W/LVD160/LVD320 disks on the major hardware retailer websites. The prices are simply insane. 73GB cost about 160 Euros, bigger disks have a better price/GB ratio, but are still too expensive. 300GB would set me back 320 Euros. Not going to happen. I have a few other ideas up my sleeve, but I will need to work on them a bit more. Oh, and on ebay.de you only find small U2W disks - the big ones are SCA only.

It’s time for a great summer in Germany again! And what better  opportunity to spend it than with Gentoo friends at LinuxTag?

The largest Linux consumer and developer fair in Europe will be taking place Wednesday, June 24th to Saturday, June 27th.  And of course Gentoo will be there with a booth. Meet some of the developers of your favourite distribution, and satisfy all your ebuild needs, maybe even have us fix  one or the other bug. We even hope to bring some merchandise this time. So if you haven’t registered for a hostel or hotel, you might want to do that now.

You are also more than welcome to contribute to the booth, either by attending as a staff member (free entrance to the show is only one of the many benefits!), or by organising t-shirts, flyers and maybe even cups. Please contact me via email if you’re up for that.

And now back to hacking on my thesis and some security bugs… oh, and NetworkManager 0.7.1 is coming, thanks to Robert Piasek and Gilles Dartiguelongue who have been contributing a lot to the ebuilds while I was slacking.

The release of Xfce-4.6.1 was announced approximately 36 hours ago on the xfce-announce mailing list. It is my pleasure to say that it is now in the Gentoo tree as well. You can find a shiny 4.6.1 bugfix release upon your next --sync.

Due to the number of bugfixes by the Xfce team upstream, the Gentoo Xfce team has decided to remove 4.6.0 related ebuilds and focus on bringing 4.6.1 to the stable tree. As always, please test and report bugs. Upstream issues should goto the Xfce bug tracker.

Since portage-2.2_rc29 there is support for a metadata/layout.conf file in an overlay which is used to specify names of repositories which satisfy dependencies on eclasses and/or ebuilds. See the QA Overlay Layout support thread on the gentoo-dev mailing list for information about why this is necessary, and refer to the portage(5) man page for details about the layout.conf format

If you want overlay eclasses to override eclasses from other repos then you'll want to refer to the portage(5) man page for information about the /etc/portage/repos.conf file which can be used to specify site-specific repository configuration information. Note that configuration settings which are specified in repos.conf do not apply to tools such as repoman(1) and egencache(1), since operations performed by these tools are inherently not site-specific.

Since portage-2.2_rc31, repos.conf can be used to create repository aliases, in case you want to substitute one repo for another one that is specified in layout.conf. This is especially useful for funtoo users, who may want something like this in /etc/portage/repos.conf:

[funtoo]
aliases = gentoo

Usually I use yakuake whenever I need to do terminal job. But having to press the shortcut key again and again in order to hide  and unhide yakuake is not that handy , especially when somebody wants to monitor the emerge progress :). So , two days ago, I decided to write a simple kde4 plasmoid to monitor emerge progress for me .  The plasmoid monitors /var/log/emerge.log file, so make sure that you have at least ‘read’ access before you use it.

There is no tarball for this yet, but you can install it using two different ways

1) Cloning git repo

git clone git://github.com/hwoarang/plasma-emergelog.git

cd plasma-emergelog

cmake -DCMAKE_INSTALL_PREFIX=/usr

make

make install ( as root )

2) Using the ebuild from kde-testing overlay

I did push an ebuild for this plasmoid on kde-testing overlay. Feel free to try it

Credits: Filewatcher plasmoid helped me a lot to create this plasmoid

You can browse the git repository here

Update 02-05-2009

Version 0.0.1 released on kde-look.org

Link

For those owning a laptop with a bitten apple on it and everyone else that is afflicted with a Broadcom 43xx chipset that is not supported by in-kernel drivers, you might be interested in the following facts:

• gentoo has net-wireless/broadcom-sta which I happily discovered just after writing a sucky ebuild for it.
• you absolutely need to disable SSB and b43 or blacklist them if you compiled these as modules because it will interfere very badly with wl driver (as in eth1 won't show up at all). For some reason it worked just fine in 2.6.24-gentoo-r8 and that's why I was stuck with it until today but in 2.6.28 and 2.6.29, it just silently failed and I was left with no wireless interface at all.

Ladies and Gentlemen, PolicyKit has been unmasked.  I've tested it, and it seems to work well enough, and to not be too intrusive in it's current default setup.

If you have issues, please file bugs.  If there's missing policy, please file bugs.  If something is too annoying, please file bugs.  If something is horribly insecure, please file bugs.  We want to get this right.

In the meantime, I'm going to be going through the policy installed by other Distros to see how it differs from what we're shipping by default.  Probably packages that currently have policykit hard disabled will start adding USE flags to enable it.

It's unlikely at this point that PK will become required on Gentoo; we don't generally work that way, and the Gnome team, at least, has been patching the heck out of upstream packages to keep it optional.  I don't see that changing for 2.26 at least.

*EDIT* s/packagekit/policykit/, thanks to MiKeL

i wrote my route survey final today, the last one. this semester was a lot rougher than the last one and i really had to work at it. after missing a week early in the year due to the worst flu i've had in ten years, and then my grandma dying a month or so later, i was perpetually a class or two behind. and when i'm stressed i don't sleep, so that meant missing more classes. in the end i think i did alright though. i think i passed at least, but my high eighties average is going to take a big hit. oh well, two more weeks of field camp and then i'm back to work in Yorkton.

gentoo-wise, due largely to the efforts of loki_val, darkside, and fauli, we got GCC 4.3 stable on the major archs. i've been running 4.4 on my laptop for a few months now and things are moving nicely. the gcc-porting overlay is filling out thanks to Daniel J, who keeps throwing patches at me.

i stopped reading g-dev around March-ish. i poke my nose in every once in a while but for the most part i just ignore it. it was just getting me frustrated and then i'd end up yelling at someone and feeling bad. i really have nothing to contribute besides arguments and bikeshedding so i figured i'd just leave it to the experts.

one thing i do want to work on now is getting maintainer-needed cleaned up. we have 750 orphaned packages in the tree, many of which look like they can be herded. once that's done i want to go through the remainders and kick anything redundant, broken, unmaintained, or old. it's amazing how much crap we have that hasn't been touched in years. flameeyes' tinderbox runs have turned up a bunch of broken junk that i've never even heard of before.

of course, the problem is knowing what to kick and what to keep. gentoo-stats would be awesome here, if it existed, to tell if anyone is actually using this stuff. right now the best we can do is mask it and wait til someone complains, which is painful for everyone involved. i guess we can wait another 3 years until someone implements it or we can buckle down and bear it.

other than that, business as usual. i still wish people would fix their damned testsuites, but i'm not holding my breath. i'm really looking forward to the git migration, not because i like git but because i really really hate CVS. EAPI 3 has some promising stuff in it, as long as it doesn't get debated into mediocrity by the gentoo development process(tm). etc etc..

http://www.linux-mips.org/archives/linux-mips/2009-04/msg00112.html

So I confirmed that this MIPS ftrace support is really working. Thanks to Wu Zhangjin (吴章金). However, I have no interest in finding out what kind of difference between my loongson2f patch and wu's caused wu's ftrace patch does not work on top of my loongson 2f patch. What I would like to see now is to get loongson2f patch merged into mainline.

Plus, I wish I could make loongson linux to be able to use 4k page(Now, loongson could only use 16k page in order to avoid d-cache aliasing). I have already started working on it now. Even if it turns out that I can't, I could tell others what I have done in order to achieve this goal. And by that time, I would've got a much deeper understanding of Linux's memory management subsystem.

So for all of those waiting for ignuit to hit the portage tree, it has finally happened. After receiving some requests from users to add it to the tree, I decided to stop being lazy and actually move it to the tree.  Ignuit should be hitting the sync mirrors shortly.

I await the massive surge of zomg you coded this ebuild completely wrong and/or bug reports

Recently, Luca made a post comparing the speed of CMake and autotools in which some timings were posted. I have to say that I am not sure I agreed with the conclusion and have had a very different experience with the projects I am involved in. As with anything your mileage may vary, and I have not looked at Wesnoth.

I think it is questionable at best to include the time it takes to build CMake, but not autotools. Seems like this is a one time cost and the build time is not that high for either. All tests were performed on my quad core Gentoo box at work. Each step is for the first cold run as would normally be the case when compiling Open Babel from source. The make step used `time make -j5` and I have listed the real time in each case.

The timings are shown in the table below. They seem somewhat similar to the experiences of the QGIS developers who made this move quite some time ago. All times shown are in seconds and are the real time reported by the time command.

For those interested, on this system the total CMake compilation/installation time (cmake-gui disabled) was 1 minute and 54 seconds. The compilation/installation time for automake, autoconf, libtool, m4 was 2 minute and 14 seconds. I am not sure how relevant either of those times are, other than to show neither of them take that long to compile and install. Gentoo users/developers may or may not have CMake installed, most other developers will install the binary packages for either one and are likely to be much more interested in how well it integrates with their development environment, compile and install times.

As a developer I prefer CMake, and have been using/maintaining the CMake based build system for Open Babel for over a year now. It was originally contributed by the KDE Windows porting team, but I found that I spent less time waiting for it to do things when I was working on code too. Add to that the extras CMake comes with, such as CTest, CDash and CPack I think it makes a very attractive option for many projects. I am also hoping that it will allow Open Babel to drop maintaining a totally separate build system for MSVC.

I am sure the Open Babel autotools build system could be optimized (I never tried), but when you add in the additional benefits mentioned above, support for multiple targets such as makefiles, XCode, MSVC, Eclipse etc, one shared language/syntax for all build files and an increasingly polished competitor to autotools, I honestly think it is a sensible choice for projects to move to CMake. There are a few less well known features such as Fortran module dependency parsing that I think are fairly unique and valuable, in scientific coding at least (and I have used the Fortran module dependency parsing at least once and was pleasantly surprised).

Full disclosure: I recently accepted a job offer with Kitware, and will start in the Fall assuming all the visa paperwork falls into place. The opinions expressed here are my own. I think it is great to discuss issues like this objectively, and hope to be a part of making CMake a better build system. As with most software - there are areas that need improving.

For users of older hardware and fans of light-weight systems, Dillo is probably not an unknown name. It’s a very light-weight web browser. That comes with its limitations, of course. It used to have a GTK1 GUI, which no one in his right mind would use anymore today. But last year Dillo 2.0 was released, which was reimplemented using FLTK2. This sports modern features like anti-aliasing (smooth fonts) and unicode

Currently the Dillo developers are working on exciting new features, such as basic CSS and JavaScript support. I figured some people may want to try out this new code, so I added an ebuild for the “live” development version to portage today (or yesterday, depending on your timezone). There is definitely some progress to see, so this little browser may grow in popularity again. And they manage to keep it small. The binary is only 629K on my amd64 system.

The OLPC Paraguay project gets a lot of media attention here, especially in this important time. Word spread that an Englishman is in town, which has resulted in newspaper publicity:

First, an interview in La Nacion: Paraguay se convierte en foco regional del proyecto OLPC (Paraguay becomes the regional focus of the OLPC project). I’m not too proud of this one, there are numerous inaccuracies and I’m given far too much credit.

Secondly, two very good articles in the highly-popular ABC newspaper:

• El voluntario que cruzó un océano para dar “Una computadora por niño” (The volunteer that crossed an ocean to give one laptop to every child)
• “Las laptops pueden ayudar de muchas maneras”, dijo Daniel (”The laptops can help in many ways”, says Daniel)

In print form, both of the ABC articles appeared on 1 page in the main section of the newspaper, occupying the whole page. And it was published on a Sunday, which is a day when seemingly everyone in Paraguay reads this newspaper. In addition to receiving emails from other parts of the country, various friends-of-friends have been in contact after seeing it, and seemingly everyone I visit now also knows about it!

Normally I only use open source software, but for some reason I'd like to try out Google Earth. However it refuses to start on my amd64 workstation with the generic error "Could not access graphics card" and when I click OK it crashes.

It's the same issue wether I use Google Earth 5.0.11337.1968_beta or the latest stable 4.2.205.5730.

I updated to latest masked emul-linux-x86-gtklibs-20081109 and got rid of some OpenGL warnings, but Google Earth still refuse to start. OpenGL and DRI (with vblank_mode 0) is working fine with KDE4 desktop effects. Glxgears yields around 500 FPS.

I'm using a Intel Corporation Mobile GM965/GL960 Integrated Graphics Controller with the following X versions:

x11-base/xorg-server-1.5.3-r5
x11-libs/libdrm-2.4.5
media-libs/mesa-7.3-r1
x11-drivers/xf86-video-intel-2.6.3-r1

Oh the joy of proprietary software:-/

Update: Actually it works with a 32 bit chroot as described in 32Bit Chroot Guide for Gentoo/AMD64, emerging mesa glib libXrandr, then Google Earth actually runs. To remove graphics artefacts I had to disable Desktop effects in KDE4. See comments for further details.