After talking with Ben (yngwin), I found that there really wasn't anyone working on documentation related to LXDE inside of Gentoo. So, I decided that I would write a HOWTO for getting it installed and configured. I finished the document this morning, and uploaded it to my Developer webspace. You may see a working copy of the document there, and if you want to see the xml, you have two options. Firstly, when looking at the finished copy, you append the following to the end of the URL:

?passthru=1

making the full URL:

http://dev.gentoo.org/~nathanzachary/documentation/lxde_1.0.xml?passthru=1

and that will show you the XML. Secondly, you can view Bug 281345, and click on the attachment. Hopefully the documentation team will pick up the guide in the near future, and commit it. The only holdup that I can foresee is that LXDE is still available only through the testing (~arch) branch.

|:| Zach |:|

I have made several changes to the Openbox HOWTO. There were many typographical errors that I didn't catch the first time around, and package links that weren't added. Here's a full list of the updates for version 1.4:

• In code listing 2.5, changed the $ to # as the operation requires root actions.
• Added a note to the 2.5 listing about becoming root before the command.
• In code listing 2.6, fixed the typographical error (7gt; instead of gt;).
• In code listing 2.6, made the
• In code listing 2.8, fixed the typographical error (extra > in closing tag).
• In code listing 2.8, fixed the typographical error (missing closing ").
• Added a link to the package information for conky before code listing 2.10.
• Added a link to the package information for feh after code listing 2.10.
• Added a link to the package information for nitrogen after code listing 2.10.
• Removed the library dependency bug reference for nitrogen.
• In terminals section, changed "customized" to "customised" for consistency.
• In file managers, fixed typographical error for Nautilus (a "bit" heavy).

If you would like to see the new document revisions before it gets committed to the official documentation repository, it is available on my Developer webspace. You may also view the XML for version 1.4 via Gentoo Bug 256693.

|:| Zach |:|

It is with sadness that we as Trustees bring forward this news that we have recently received. Ferris Ellsworth McCormick, better known as fmccor, has passed away unexpectedly on the 5th of August. His family does not wish to be contacted. We have expressed our gratitude for his contributions on behalf of the Community.

Ferris studied mathematics in college at Indiana University, graduating in 1968 with a Bachelor of Arts. Later he entered into the Law school at the University of Michigan, earning his Juris Doctor degree in 1991.

He passed the bar in Michigan that same year and has continued to be an actively certified Lawyer with the State of Michigan since then. He was also a member of the Association for Computing Machinery (ACM).

Ferris joined Gentoo on April 16th 2004 as part of the sparc team and improved sparc support for the entire open source community. Within a year he also joined the Developer Relations team to help with mediation of any issues that might come up between people. As time went on Ferris continued to expand and assist Gentoo in many ways including assisting with the User Relations team and growing to become the Strategic Manager of the sparc project. Finally, he became a trustee and the Vice President of the Foundation assisting in getting the foundation back into good standing.

While it is too late to say in person, the Foundation would like to thank Ferris once again for all that he did for both Gentoo and the Open source community. He will be missed.

Please join the community in eulogizing Ferris in our forums here.

This is a quick note for anyone using compiz, that x11-wm/compiz-0.7.8-r3 will allow KDE-4.3.0 and that the KDE use flags were updated now that KDE-4 has become the "default" KDE version and that 3.5 is approaching its final days.
As such, the kde use flag will add support for KDE-4.X and the kde3 use flag will add support for KDE-3.5. So be sure to check your use flags for compiz.
I plan to move compiz-0.7.8-r3 from the overlay to the tree in a few hours.

Following my attempts to deal with bug 259715, I broke libcompizconfig again - bug 278146. Although I've masked libcompizconfig-0.8.2-r2 sometime ago, it was unmasked long enough to break the config files for enough users. If you still have ccsm / compiz failing for you, you need to downgrade to libcompizconfig-0.8.2 and to remove the contents of ~/.config/compiz/compizconfig/. I'm still working on removing the bundled iniparser from libcompizconfig.

After having recently reinstalled Gentoo on my main production machine, I thought I would look into some theming to make things more aesthetically pleasing. I installed a bunch of GTK themes that I ended up not liking, so I got rid of them. I use Openbox with a bunch of LXDE applications installed to ease the process of customisation. One such application is LXappearance. Getting rid of the unwanted themes from the LXappearance menu wasn't all that difficult. I simply went to /usr/share/themes and removed the respective folders. However, I couldn't seem to get the unwanted icon themes to go away. If I'm not mistaken, icon themes are usually installed to /usr/share/icons. When I went to manually delete the icon theme folders, however, there were no such directories. Hmmmmmmmm...

Since searching the web didn't yield any significant results, I thought I would go to the source code and figure out just what happens when one installs an icon theme using LXappearance. In /usr/share/lxappearance there is a script called install-icon-theme.sh, and it contains the following line:

export XDG_DATA_HOME="$HOME/.local/share";

That lead me to check that respective directory. Bingo, there were my icon theme folders. I simply deleted the folders, and the respective icon theme choices were no longer present in LXappearance. I was simply excited as it was my first success of the day.

|:| Zach |:|

So, a couple days in, and I'm still trying to (re)install Gentoo. More on that in a bit. First, let's talk about speed.

It's hard to tell whether or not my new SSDs are really a speedy improvement over the old software RAID1 array of magnetic HDDs. Normally, a bare-bones commandline system feels much faster than an aging graphical desktop, even on the same hardware.

I notice that compile times are slightly faster, though I've also been using tmpfs for Portage and the usual tmp file locations, so putting it all on RAM will lead to a significant speedup anyway.

Boot times are indeed quite zippy; the longest wait is for my media HDD to finish mounting -- it's on ReiserFS, which is known to have very slow mounts.

Now, let's talk filesystems.

The critical showstopper that's made me reinstall two times (and counting) is ext4. So far, ext4 has completely corrupted a whole drive (/var and /usr/portage) and made the other drive (/ and /boot) almost unbootable.

ext4 has eaten my data, hosed my system, and ruined my life.

No amount of fscking has fixed /var and /usr/portage, both on the second SSD. Did you know that you shouldn't let fsck try to resize broken inodes? apparently the resize behavior is known to be broken in the latest versions. It's known to corrupt filesystems. I didn't know that, either. I'm sorry, but what part of "production-ready" applies to ext4? Yeah, it's a new kid on the block, but it's moved out of the "experimental" status into the kernel.

That does not make it ready for your system. The first and second Gentoo installs largely didn't work because (I think) there might have been an invalid mount option. Or something could not be found. Or a superblock was missing. Or the moon was wrong. #$#^#&@ shitty unintelligible error messages. (Here's a tip, developers: don't put every possible thing that could have gone wrong into an error message, then repeat that message for every different error.)

My mount options seemed to be good after double-checking the manpage and around the internet, including kernel.org. Here was my original fstab, from when I had only one partition for / (no separate /boot):

/dev/sda1  /     ext4  noatime,data=writeback,commit=60,nobarrier  0 1
/dev/sdb1  /var  ext4  noatime,data=writeback,commit=60,nobarrier  0 1
/dev/sdb2  /usr/portage  ext4  noatime,data=writeback,commit=60,nobarrier 0 1

Livin' on the edge here. I figured I wouldn't need a separate /boot partition on my first drive, so I lumped it all into one. I did that back in 2005 and 2006 with no problems, right? Right. The rest of the options were designed to maximize SSD performance.

Unfortunately, I couldn't get the system to boot. Made it past grub, the kernel loaded, but when it came time to mount /, it couldn't mount the filesystem rw. No amount of changing options worked -- adding rw to grub.conf, to the fstab options, nothing.

So I figured it must be my one-partition setup, and wiped my disks. Reinstalled again, this time adding a /boot partition on sda. Same ext4 options for /boot as for the other partitions. Rebooted and . . . nope, same errors. Now I'm also seeing a message about a possible bad option or other variable, which I can only assume was in fstab, thanks to the aforementioned shitty nonspecific error messages.

Hit up Google. Not much help. I again backed off on some of the ext4 options, tried playing with Grub parameters, but got the same results. The filesystems mostly weren't mounting, and when a few of them did, it was all readonly.

Sigh. Time to reinstall again. Set up a similar fstab, but this time I changed an ext4 option for /boot to data=ordered, based on this blog post. Reboot and . . . hey, it works. /boot gets mounted. Nothing else does, but it's a start.

I quickly booted back into the LiveCD, changed the other fstab entries to data=ordered, and reboot again. This time, the system seems to boot just fine . . . until it tries to mount /var and /usr/portage from the second SSD. *bzzt*, these cannot be mounted! Something's gone wrong. One more reboot, just for luck, then . . . *bzzt*, now there are filesystem errors! Fsck wants to fix them, so I let it run. Except it completely hoses both partitions. They seem to be so badly scrambled that even running mkfs.ext4 on them from the liveCD results in errors, some of which seem to be emitted from the libata system, which makes me wonder if now the SSD itself has also been corrupted.

I'll have to completely reinitialize and repartition that disk, now. Thanks, ext4. Thanks for hosing my data. Up yours, ext4.

I'm done trying to figure out why ext4 doesn't work. I don't care that it's supposed to be a fast file system for SSDs. I don't care that it's 40 times faster than ReiserFS to mount at bootup. I don't care. ext4 has lost my data three times now. I think my fingers are sufficiently burned to know that "the oven is hot; don't touch."

Up yours, ext4. I'm going back to ReiserFS. At least it works. It's never failed me in more than four years.

---

Update: On top of the initial ext4 errors, fsck problems, and mount issues, the Mobi drive was also going bad. Now the motherboard BIOS can't see it, regardless of which SATA port or cable I plug in. So just a day or so after trying out the device, when it was initially working for the first install (though the filesystem was throwing ext4 errors, at least /var and /usr/portage worked okay), and it finally finished failing. F***. I contacted the seller to request an RMA; I have a feeling that I'll end up having to go through the manufacturer, which will take a long time. Meanwhile, I'm without a workstation for an indefinite time, so I've set my devaway on dev.gentoo.org. I did find a couple other reports on the internets that say that their Mobis also died shortly after they arrived, so maybe there was a batch of bad drives.

But don't get me wrong, the Mobi drive dying doesn't absolve ext4 of any guilt. The ext4 filesystem still completely f**ked itself repeatedly on the system drive, the UltraDrive ME. It still refuses to do what it's told to do. But rather than continue to investigate related LaunchPad bugs on mounting ext4 rw and fsck errors, I'm going to move back to ReiserFS for the UltraDrive, and just live with longer boots. The RMA process will take awhile, so I may have to reinstall everything on a single drive and just avoid syncing Portage for awhile.

On a good note, OCZ (the company that makes the Vertex, an identical drive with an Indilinx controller), has been experimenting with a homegrown beta firmware that lets the drive do online garbage collection in the background. This is important for keeping the performance of the drive as fresh as when it was first used, even after it gets filled up with files and repeated (re)writes. The firmware is still in testing, but I'm hopeful that it'll make it out the door soon. Hopefully the same firmware features will find their way to my Super Talent drive -- and hopefully the TRIM command will also be implemented in the firmware.

Of course, the only Linux filesystem I know of that supports TRIM is ext4 . . .

KDE 4.3 has arrived

Lots of behind-the-scenes fixes, a new pretty (debatable) default plasma theme and various new stuff across the board make kde 4.3 an exciting release!

Gentoo ebuilds were available the moment tarballs were released, thanks to the hard work of our Gentoo KDE team

However, since 4.3 brings some new packages (and dependencies), we’ve hard masked the ebuilds until everything gets the proper keywords.
You can follow the keywording progress in bug 280312.

Instructions on how to unmask kde 4.3 after the screenshot

unmasking & installing kde 4.3
kde 4.3 might be masked but it works fine on x86 and amd64 (for other archs check the bug above).
to install it, you can easily unmask it using the unmask file provided in the kde-testing overlay, [kde-testing]/Documentation/package.unmask/kde-4.3

if you don’t have / don’t want the overlay, you can grab the file here.

you can also use a command similar to

# unmasking kde 4.3
wget -O /etc/portage/package.unmask/kde-4.3 'http://git.overlays.gentoo.org/gitweb/?p=proj/kde.git;a=blob_plain;f=Documentation/package.unmask/kde-4.3'

to automatically save the unmask file to your unmask folder (if you use folders)

for those using stable gentoo, there’s a similar keywords file

# adding kde 4.3 in package.keywords/
wget -O /etc/portage/package.keywords/kde-4.3 'http://git.overlays.gentoo.org/gitweb/?p=proj/kde.git;a=blob_plain;f=Documentation/package.keywords/kde-4.3.keywords'

troubleshooting
if you’re trying to upgrade from kde 4.2, but portage gives you nice little blocks, there are a few things you can check:

• make sure you’ve synced the tree and kde-testing overlay (if using it) :p
• make sure the unmask/keyword files are correct and up-to-date
• check that you don’t have any 4.2 versioned kde-base/* items in /var/lib/portage/world
• check that you don’t have any 4.2 versioned sets in /var/lib/portage/world_sets
• emerge -avDuN world — you’ll probably get some messy output but all blocks should be automatically resolved

if you hit any issues feel free to leave a comment, check the gentoo kde 4 guide (should be up-to-date soon) or visit us @ #gentoo-kde (freenode).

enjoy your shiny new kde!

share this post:

Earlier today Calchan blogged about amending GLEP 39 here. During the council meeting I voted against council being able to change the document and on deciding a process for changing it. Why? First I think as the developer population voted the GLEP I think they should decide about the changes as well. Secondly I think we don't need to decide on a process because we already have one. Using the existing elections team and votify is enough when needed. If council members think we are wrongly skipping items in meetings, I challenge them to step up and take chair in the next meeting making sure items are properly handled.

I'm going to go ahead and assume you have all read the summary of the last council meeting. It can be summarized even further.

• We decided the #gentoo-council channel would be moderated during meetings. Developers and users have plenty of opportunities to tell us what their opinion is prior to and during the meetings.
• We confirmed Thomas Anderson as the council secretary and clarified that the role of the secretary is limited to posting the logs and summaries of council meetings.
• The council decided it wasn't competent to decide how GLEP 39 should be amended.

Some would say that it isn't much. And I wouldn't disagree. I wished this council could be someday called the council that slacked less but we're apparently not taking that direction. Let's see if we can change that. By the way I encourage everybody, anybody, to post discussion topics to the gentoo-council mailing list and debate there.

What I really wanted to discuss today is amending GLEP 39, and more exactly how to proceed. This GLEP serves in certain ways as our constitution and is more critical than any others. It was written almost 4 years ago and as such relects the situation as it was back then. It has been criticized a lot, many want or wanted to replace it at some point in time, some even went as far as writing replacements for it (count me as one of them), but I have yet to see something that is worth discussing in public.

Now, I'm not going to say that it's perfect. No text of that kind can be even close to perfect. My point today isn't about discussing what should be kept in it and what should be changed (don't worry though, I'll discuss that soon), but to make sure we agree on the fact that we need a mechanism to modify it. And by extension replace it if we decide so someday. Not that it wasn't ever amended in the past, it was, but in a way that I can't imagine satisfies the whole developer community. Don't extrapolate from what I just wrote that I disagree with the changes or how they happened, quite the contrary actually. But I talk to a lot of you and many tell me they believe that since GLEP 39 was the result of the vote of all developers, any change to it needs to be again voted by all developers. I disagree with that simply because GLEP 39 itself has provisions that would imply the contrary. However, all opinions need to be taken into account, especially when the same one comes back often.

So, what happened during that last council meeting? One of the questions was whether the council could decide on a process to amend GLEP 39. The vote ended up saying no. The next item on the agenda was then to organize a vote of the whole developer community to decide, since the council declared itself incompetent. Strangely enough this item was skipped. How can that be interpreted? Frankly, I'm not sure.

Someone argued that there was no point bothering with how to amend GLEP 39 since we could always organize a quick vote of all developers. I see two issues with that. One is that we had just voted that we couldn't decide on a process, but arguing that we can always use an all-developer vote is precisely deciding on a process, and it's inconsistent. The second one is that GLEP 39 was already amended a few times, and each time without an all developer vote. I don't seem to remember anybody complaining about that. So there must be at least a significant part of the developer population which is happy with not having to vote on changes of GLEP39, and is comfortable with the "vote out the bums" clause.

Most probably what happened is that we were running late with the meeting and the item was skipped because it didn't seem important to your new council. Yep, you heard me. Your new council doesn't really care about what you think on amending GLEP 39. If you think your council should care more then let it be known.

Lately we updated some of the LXDE packages in Gentoo, and tonight I added a few more. We have now a practically complete LXDE desktop on Gentoo. So if you feel like trying the most lightweight desktop environment, consider to emerge lxde-meta. If you come across any bugs or other issues, please let us know. Bugs should be reported at bugs.gentoo.org. Support questions are welcome in the #gentoo and #gentoo-desktop IRC channels on Freenode, or #lxde on OFTC. You can also go to the forums.

The current version, lxde-meta-0.4.2 and its dependencies, is considered our stable candidate, so we’d like to straighten out any issues there may exist. Also, some documentation would be welcome. So if you want to contribute a “How to configure and use LXDE on Gentoo” guide, we’d be very thankful. Or if you want to help maintaining LXDE in portage, we could always use more people. So contact me if you’re interested in a herd tester or developer position.

We also have an overlay with live ebuilds, but it is basically unmaintained. So I cannot recommend you use it, unless you want to test and update the ebuilds. If you’re on bitbucket, send me a pull request. We used to have several user contributors, but I guess they are too busy with other things now — as am I. Currently my focus for LXDE (whenever I have time for it) is to get the packages up-to-date with the latest released versions and get what we have now tested and marked stable.

So have you tried LXDE yet? What are your thoughts? And are you willing to contribute?

I'm looking for a someone to help out with Planet Gentoo if they are interested.  Specifically, we host a deployment of b2evolution and use it for the developer blogs.  As a maintainer of planet services for Gentoo, that's part of my job to take care of it ... but it drives me a bit nuts and I'd like to rip it out and tell people to use something else.

But, people do like it, and I'm losing interest in taking care of it, so what I'd like to do is give the opportunity to someone else if they are interested.  If you wanna help out with Gentoo a bit as a staffer (not a developer), I can help you take the quiz and get started.  Email me at beandog@gentoo.org and lemme know why you're interested, etc.  Main responsibilities would initially just tweaking our b2evolution install, getting some things cleaned up, maybe helping out with documentation, small patches.  Nothing major or stressful, just minor tasks that need to get done.

Figured I'd visit forums today, seen at least 4 topics about lost menus while updating gnome-menus to 2.26.2, banged head 4 times because of users not reading elog messages and doing random fixes instead of searching the real cause of the change (in changelog, ebuild, elog, bugzilla). Good thing I have added that to the migration guide that will be up for stable users.

For those of you who still don't know about elog, man make.conf.

Update: fix typo.

Today another nice thing for the Linux kernel happened, we got working VME bus drivers and infrastructure submitted to the kernel tree. Now, I don't expect it to generate as much press as the Microsoft kernel driver thing did, but it should, as I feel it's more important in a way.

The VME bus code has lived outside of the kernel for many years, and there was at least three different implementations at the same time floating around. Martyn Welch from GE Faunc took the time, merged all of them together, and rounded up the different copyright holders of the code and got legal approval from all of them to properly release the code under the GPLv2.

Now as someone who has tried to do this kind of thing, I know how thankless and how difficult it can be. So here's a great big thank you to Martyn and his employer for getting this work done, and taking the time to work toward getting it merged into the main kernel tree.

The patches are here, here, here, here, and a good readme for the api is here.

Some more stuff that has happened recently with cleaning up ALSA ebuilds.  We (as in me, mostly) decided to drop support for the optional MIDI support in the alsa-lib and alsa-utils packages.  It originally was implemented as a hack on our end, always caused headaches when disabled, and a whole lot of ebuilds required that it be implemented anyway, so it wasn't so optional to start with.

With alsa-1.0.20, I ripped out the midi use flag completely, but instead of fixing the reverse dependencies to check for an either/or scenario, instead it was decided to just go back and change all versions of the alsa-lib/utils ebuilds and to force it on, and then drop the check on those using it.  Thanks to Samuli (ssuominen) for fixing all the applications that were using it.

If you run into any ebuilds that are failing to merge because of the dependency, that are in the main portage tree (sorry, I can't take responsibility for overlays), try syncing your tree again -- it's possible your last one was during the transition.  If you still find one that isn't working, feel free to file a bug report at bugs.gentoo.org and assign it to alsa-bugs@gentoo.org.

Another change that has needed to happen for a while, though not nearly as dramatic, is that I ripped out the really old config options in the alsasound init script: KILLPROC_ON_STOP and UNLOAD_ON_STOP which would kill process using ALSA, and unload its modules, respectively.  Like before, they caused more problems than they solved (both of which, I might suggest, could be implemented in local.stop if you really needed something like that), and I'm glad to say they are gone.

That's about all the major growing pains for now -- that is, I certainly don't have anything else on my plate for ALSA or its related applications, other than getting 1.0.20 stable and everything previous to that version removed from the tree.

As always, we appreciate any help people would like to give.  There's still old bugs open, and it'd be good to know if they are solved or not in the latest release.

I realize some of these changes may be minor bumps for users, and if so, I apologize ... but Gentoo is always changing goals and directions, and I'm quite glad that we have the flexibility to change things, instead of being stuck with one method.  Part of growth is just shedding the stuff that doesn't work.

So, in between being super busy with Gentoo yet not having enough time to keep up with all the bugs, document updates, and project commitments . . . I've added yet another item to my plate: a fresh install of Gentoo onto a pair of SSDs.

I've never reinstalled Gentoo on this workstation; this is the original install from October 2006. I had thought about just finding some stage4/stage5 backup scripts and tips from the Gentoo Forums, but it seems to be more cumbersome and time-consuming than reinstalling. Besides, installing Gentoo from scratch gives me a chance to create an even more lean, minimal system. No more accumulated packages and cruft that I don't use, just the essentials.

And it'll let me see how good these SSDs really are for compilation times.

I purchased two: a 32GB Super Talent UltraDrive ME for /, and a 16GB Mobi 3000 for /var and /usr/portage.

The Super Talent is a new-generation MLC drive with an Indilinx controller. It's not as good in some areas as Intel's controller for the X-25, but it's better than everything else out there, and it doesn't have the chronic stuttering problems that all cheaper JMicron-based controllers suffer.

The Mobi is an older drive, "only" SATA-150. But it is an SLC drive, so I'll use it for the partitions that see the highest write activity, as SLC is more resilient than MLC. Plus, the contents of the drive are more or less throwaway, so if any corruption does develop, I can just replace it with no issues. /var sees log frequent writes, and there may be some Portage compilation in the tempfiles. I've been using a tmpfs on RAM for /var/tmp/portage for some time now, so I don't really think it will hit up the drive much, not with 4GB of RAM installed:

none  /var/tmp/portage tmpfs	noauto,nr_inodes=1M,size=2000M 0 0

See? A dynamic Portage compilation space, ready to occupy 2GB RAM if need be. During compiles, the only time I ever really see the HDDs light up is during the src_unpack (to RAM) and src_install phases.

So I've figured out my drive and partition usage, but the things that are causing the most headaches, and occupying the majority of my research time, are:

1. Which filesystems
2. Which mount options
3. Which schedulers
4. Partition alignment schemes

See, I will have two SSDs in there with Gentoo installed on 'em, but I'll also have a separate magnetic HDD for media storage, so that means a different for each drive.

For 1, ext4 is looking increasingly attractive for the SSDs. I may continue to use ReiserFS for the media drive, as it's worked very well for a few years now. But, given that the Portage tree is just lots and lots of tiny files, perhaps I could continue using ReiserFS on it? Though I would need to deactivate the journal. The Mobi drive should not have any journaling on it -- too many writes.

NILFS2 is another interesting filesystem, but it seems immature. BtrFS also has potential, especially after reading Val's excellent article, but its developers warn against using it for anything other than testing. So I'll stick with something a little more mainstream, yet not so old and cranky as ext3/ext2.

Which brings me to 2: mount options. I've only just begun to read up on suggested options for ext4. data=writeback seems to be one of the more popular suggestions. noatime is a necessity; I've used this option on every single Gentoo install I've ever had. There are several other options I need to investigate, including the dir_index variations.

If I go with ReiserFS, I'd need to research the performance differences between notail and tail. In theory, the latter option could be more efficient for packing more data into fewer blocks, resulting in fewer writes/rewrites. This is at the expense of slightly more CPU usage. notail may result in more speed, but I haven't found many detailed reports of ReiserFS usage on SSDs. One last thing to look up would be the difference between ReiserFS with the journal and without.

The next piece of the puzzle is 3, schedulers. Most of the schedulers in the kernel are designed to keep spinning magnetic disks happy. But since there aren't any moving heads or rotating disks to spin up, the algorithms that are designed for efficient, minimal motion aren't very helpful for SSDs.

The usual solution proposed is to bypass the traditional HDD seek layer overhead by just using the noop scheduler. It's a very simple FIFO-based scheduler. System requests a file, it gets it. No complex queuing up done in the kernel. It lets the extremely fast drive controller do all the work, since it's capable of getting the data where it's needed without stuttering or delays.

However, the deadline scheduler may be as good as noop, as deadline does a certain amount of prioritizing. My understanding is that it's similar to NCQ in this regard, and that using deadline doesn't have any overhead costs. Still doing the research on this.

These two schedulers may be all well and good for the SSDs, but since I'll have two SSDs, a magnetic hard drive, and an optical drive in my box, I can't use the same scheduler for all of 'em. noop would be a poor choice for the HDD, so I may use deadline or stick with the tried-and-true CFQ scheduler.

Fortunately, using different schedulers for different drives is fairly easy:

# echo deadline > /sys/block/sda/queue/scheduler
# echo noop > /sys/block/sdb/queue/scheduler
# echo cfq > /sys/block/sdc/queue/scheduler

It's just a matter of putting these commands into an initscript to be run at boot.

The last puzzle piece (so far) is 4, partition alignment schemes. This is the most confusing one. The most headache-inducing. The most worrisome one, in that if I screw it up, I could completely hose the performance of the drives, and severely impact the wear and tear on the drive.

The OCZ Vertex is functionally identical to the Super Talent UltraDrive. Same controller and firmware, so Vertex tips will apply to my drive. The OCZ forums have proven rather useful. There's a fair amount of material at the OCZ forums, and even some suggestions by Gentoo users. Unfortunately, some of the threads are rather old, so I'm unsure how much still applies. Given that there have been new hardware revisions, new firmware shipped with the drives, and improvements to the Linux kernel stack (schedulers, libata, etc.).

Ted Ts'o has a pretty good explanation, but it differs from some of the other suggested block sizes. Also, some guides have a radically different approach.

* * *

So, four pieces to the Gentoo installation on an SSD puzzle. Lots of notes so far, and despite four months' research, I feel like I've barely gotten started. I've been thinking and planning to move to an SSD for quite awhile now; it's mostly been a matter of waiting for prices to fall. Now all the components are here, so I'll just have to dive right in and see what I find. Results will, of course, wind up here.

Since release 1.3.2 Smolt comes with a tab “Distribution” to show distribution-specific information:

(The new Qt-based GUI client was introduced somewhere after Smolt 1.2 by Carlos Gonçalves, see here for details.) The currently quasi-empty tab is shown no matter what distro you run Smolt on. However, on my “gentoo” branch it looks slightly different:

I have also been working on simple extractors for dpkg and rpm to better understand the distribution specific interface that I’m introducing on code level. After all one of the long term goals is to feed Smolt statistics with PackageMapped installation data from across distros, not just Gentoo.
So if you read this and feel like bringing support for another distro (say Arch) to Smolt now is a great time to contact me.

PS: Check my “sping” overlay for a Smolt 1.3.2 ebuild.

We are cleaning up the XFCE ebuilds via a new eclass. The current eclasses do not make maintenance any easier, like they should. Some other things on the TODO list include:

• Remove xfce-4.4 from the tree. 4.6.1 has long since been stable. Caveats: We promised mips that they could have a ~month to keyword 4.6.1. Gentoo Prefix can't easily use 4.6.1 due to the xorg-server dependency.
• Rename plugins to match what upstream calls them. For example, what Gentoo calls xfce-extra/xfce4-cpu-freq, upstream calls xfce4-cpufreq-plugin This is true of all plugins.
• Remove the meta extras package, xfce-base/xfce4-extras.

The last bullet point is where I would like to gain input on how to provide the best user experience for xfce users on Gentoo. We are contemplating on removing the meta package because: it is tricky to add new plugins to it (requires more arch team work via rev bumps). Renaming plugins will require more work because of the meta package. And finally, what is the point of this meta package (some would ask) - outdated, etc.

So some possible options:

1. Remove the meta package completely and let the user emerge what they want. We are leaning towards this one.
2. Provide an USE flag for xfce-base/xfce4 to emerge all these extras, since it is a meta package anyway. This allows arch teams to mask the use flag if they don't want to deal with all the plugins. Not a good option though, in my opinion.
3. Revbump the meta package everytime there is a new plugin added to the tree.
4. Other option that I haven't thought of?

So, what is it? What would provide the best XFCE experience on Gentoo?

Update: as reported by Fai Wong, -O1 is actually fine. Obviously, it must be some flag(s) which is(are) enabled at -O2 but not at -O1 caused this problem. However, it is not a priority ATM. Anyone who is interested in it is welcome to investigate it further.

As I have mentioned earlier, sqlite compiled with -O2 may cause xulrunner to segfault in N32 userland on Loongson. Well, I almost forget it.

So to remove the -O2 from CFLAGS once and for all, I adopted the technique described here.

zhangle@2f env $ pwd
/etc/portage/env
zhangle@2f env $ find
.
./dev-db
./dev-db/sqlite
./O2-removal
zhangle@2f env $ cat O2-removal
pre_pkg_setup() {
      elog "bashrc is removing \"-O2\" from CFLAGS for $PN"
      CFLAGS="${CFLAGS/-O2/}"
}
zhangle@2f env $ ls -l dev-db/sqlite
lrwxrwxrwx 1 zhangle zhangle 13 2009-08-01 16:10 dev-db/sqlite -> ../O2-removal

Developer Robin H. Johnson, who is a trustee board member, infrastructure team lead, spoke with David Abbott.

Robin is the backbone of the Gentoo infrastructure team which includes the forums, bugzilla, and most important, the Gentoo Portage tree.

He describes his first open source project, phpMyadmin, how he became a Gentoo developer, and the layout of the infrastructure.

"Nearly 50 percent of the infrastructure hardware is taken up by web applications, because we have a lot of separation between web applications that have a high security exposure. Admittedly some of the web services are a very big deal for Gentoo, like our Bugzilla service, running on 4 machines sponsored by the Dutch social network, Hyves. Very recently we've gotten new hardware for Forums, sponsored by Gossamer Threads. The next largest slice after that is the machines that provides rsync.gentoo.org service. Only then do we get down to individual machines for purposes. There's some cases where having more hardware as fail-over in case we lose a machine would be nice, but I think the place that'd we would benefit the most presently would be a newer mail server infrastructure, so that we can deploy heavier spam filtering."

Robin H. Johnson Interview

Recently one of our developers decided he would raise hell in one of our irc channels. "For the lulz" he said. What ensued was a rather large number of kicks which ended in a ban. I contacted him and tried to talk to him. He wouldn't agree at first, then stopped answering, and went on in another channel. I spent a good amount of time trying to reason him at around midnight my local time knowing I had an early meeting at the office the day after. He stopped and apologized a few seconds before I hit the button to suspend him.

He didn't have any really bad intentions but he still created a shitstorm. In his mind everybody overreacted but there was one thing that he didn't understand. Him behaving like this made a few people unhappy. Whether they were right or wrong to be unhappy, they were, and they showed it. In return they started filling some of your fellow devs' maiboxes, and irc queries started popping faster than it is humanly possible to answer. In short after a few minutes some of us had their screen blinking like Christmas trees.

So, kids: don't make an ass of yourselves in public, whether on irc or elsewhere. And if you absolutely have to do so don't do it in a #gentoo- channel, and preferably not with your gentoo irc cloak. If you don't do it for yourself do it out of respect for those whose task it is to try and maintain a semblance of peace on irc or on our mailing-lists. And think of all those traces you're leaving behind for the next time you'll look for a job. Think also of the image you're projecting for the whole Gentoo community. You're a developer, so if you care show yourself and your distro in good light.

And remember that we're a large project with all kinds of different cultures. Something that may seem totally insignificant and/or funny to you may (and will probably) be seen as abrasive by others. We have to operate on a lowest common denominator. That's unfortunate but there's no way around it.

Thanks for your attention.

I've just punted all the old ALSA ebuilds from the tree.  Tah tah.  I thought they needed to be in there for old kernel compatiblity, but it turns out I was wrong.  Ah well.  The less versions to worry about, the better (from a support point-of-view).

We're going to look at getting 1.0.20 stable here pretty quickly, and then remove *all* the old versions after that.

Oh, and if you are interested in helping out with ALSA bugs, that'd be nicely appreciated as well.

One other note -- I added media-sound/alsa-driver, which is the external modules for the ALSA drivers, into package.mask.  The concept is simply to add a hurdle to users wanting to use it, and to make it clear it won't be landing in stable-ville anytime soon.  However, there are no plans to remove it from the tree, either.  I know some people like to use it, so there ya go.

So i bumped dev-libs/cloog-ppl to a newer version just now. cloog-ppl (and it's buddy PPL) are new dependencies of the new Graphite framework in GCC 4.4 (still masked). They're optional dependencies, and on a whim I wanted to see if configure would fail if they were missing or just detect it and continue on. So I did this:

emerge -C cloog-ppl

Oops.

configure: error: C compiler cannot create executables

Every Gentoo user has seen this at some point. It's a very general error that can range in meaning from "you mispelled a CFLAG" to "wow you're screwed". I knew what the error here would be without looking, but for those following along at home:

/usr/libexec/gcc/x86_64-unknown-linux-gnu/4.4.1/cc1: error while loading shared libraries:
libcloog.so.0: cannot open shared object file: No such file or directory

(usually you would find this in the config.log of the package being compiled)

Ok, so I just hosed the compiler. Dumb mistake. Now, here's how we fix it.

halo ~ # gcc-config -l
 [1] x86_64-unknown-linux-gnu-4.3.3
 [2] x86_64-unknown-linux-gnu-4.4.1 *
 [3] x86_64-unknown-linux-gnu-4.4.2-pre9999
 [4] x86_64-unknown-linux-gnu-4.5.0-pre9999

Usually I would have three or four more versions here (3.4, 4.0, 4.1, 4.2) but this is a relatively new install. As luck would have it though, I have exactly one version that will work here. 4.3.3 doesn't have graphite support and therefore won't be linked against libcloog.

So, gcc-config 1, etc. emerge -av1 cloog-ppl.

libtool: link: x86_64-unknown-linux-gnu-gcc -Wall -fomit-frame-pointer -O2 -g -march=core2 
-msse4.1 -fomit-frame-pointer -pipe -Wl,--hash-style=gnu -o .libs/cloog cloog.o -Wl,--as-needed 
./.libs/libcloog.so -L/usr/lib64 /usr/lib64/libppl_c.so /usr/lib64/libppl.so /usr/lib64
/libgmpxx.so /usr/lib64/libgmp.so
/usr/lib64/libppl_c.so: undefined reference to `std::ctype::_M_widen_init() const@GLIBCXX_3.4.11'

Or not. Yay, symbol versioning. Another thing every Gentoo user has run into when switching GCC versions. To make a long story short, libppl_c.so (PPL) is looking for a versioned symbol in libstdc++.so.6 from GCC 4.4. When we switched to GCC 4.3, that symbol version (here GLIBCXX_3.4.11) no longer exists. Solution? Rebuild PPL. But, this results in a similar error:

libtool: link: x86_64-unknown-linux-gnu-g++ -frounding-math -O2 -g -march=core2 -msse4.1 -fomit-
frame-pointer -pipe -W -Wall -Wl,--as-needed -Wl,--hash-style=gnu -o .libs/ppl-config BUGS.o 
COPYING.o CREDITS.o ppl-config.o  ./.libs/libppl.so -L/usr/lib64 /usr/lib64/libgmpxx.so 
/usr/lib64/libgmp.so
/usr/lib64/libgmpxx.so: undefined reference to `std::ctype::_M_widen_init() const@GLIBCXX_3.4.11'

As you can see, downgrading GCC versions with gcc-config breaks the linking of a lot of C++ libraries. (this is why I hate testing unstable GCC versions on KDE).

So just keep going down the line, attempting to rebuild whatever breaks next, until you actually manage to fix something. If you don't know what package a library belongs to, use one of the many utilities that may be installed on your system, like `equery b` or `qfile`, that maps a filename to package. In this particular case, dev-libs/gmp was the last package needing to be rebuilt. Next, go back up the chain - rebuild ppl, and finally cloog-ppl should build successfully. Switch back to your original GCC version, do a little dance, and go about your day.

When pretesting started I already wrote about the new features of GNU Emacs 23...and now it is there. About two years after the release of 22 this major step in Emacs land has been done and Gentoo provides the version as of today. Have fun, test it and report bugs (not too much, please).

I just found that, it is actually very easy to trigger the problem that the -mfix-ls2f-kernel as option could fix. Like just emerging glibc could hang the system. So if you are using linux-loongson/2.6.30/stable branch from this git tree http://dev.lemote.com/git?p=rt4ls.git;a=summary, you maybe want to line 129 of arch/mips/Makefile:

$(call cc-option,-march=loongson2f,-march=r4600) $(call cc-optoin,-mtune=loongson2f)

to

$(call cc-option,-march=loongson2f,-march=r4600) $(call as-option,-Wa$(comma)-mfix-ls2f-kernel,)

Actually, $(call cc-optoin,-mtune=loongson2f) here is not required.

BTW, glibc-2.10.1 is ready in my overlay. This version could solve the gdb issue:

Error while reading shared library symbols:
find_new_threads_callback: cannot get thread info: generic error
find_new_threads_callback: cannot get thread info: generic error

This happened previously when debugging multithread applications.

So for our Vancouver heatwave (I noted 39C away from the water today, in the shade!), it's finally claimed some of my computer hardware. Most annoying, the battery backup unit (BBU) in the newer fileserver, and 1.5 of the disks of the RAID1 array in the old server...

My website and personal email will be offline for a day or two while I ensure my backups are up to date, and redeploy to the newer fileserver (after I buy a new BBU tomorrow).

In this Screencast, I give an overview of Audacity and recordMyDesktop, the tools I use to record my Podcasts and Screencasts. If you have any questions, you can reach me at david at linuxcrazy dot com, or on freenode irc, channel #linuxcrazy.

Links
Audacity
http://audacity.sourceforge.net/

recordMyDesktop
http://recordmydesktop.sourceforge.net/about.php
http://recordmydesktop.sourceforge.net/manpage.php

PiTiVi
http://en.wikipedia.org/wiki/PiTiVi
http://www.pitivi.org/wiki/Overview

Interview with Edward Hervey about the PiTiVI video editor
http://gnomedesktop.org/node/4082

irc network freenode channel #linuxcrazy

Download

I don't usually do that but here it is: a shameless, although thankful, plug for LGP. I recently bought three games from them during their massive 24-hour sale in May. I wish I had time to play games but I don't. I only bought these games to support them and to thank them for the positive impact which I think they have on Linux. After all, even the almighty vapier came to Linux because of games (or was it pr0n?).

At that price point though I don't know who was supporting who, so I decided I'd write ebuilds for the games I bought. Of the three that I got, Cold War already had one, X3: Reunion wouldn't install due to not enough space on my hard drive (yep, I'm that strapped), so it left me with Sacred Gold. It's now in the tree so feel free to buy the game and play with the ebuild. I have decided that I would only support the provided libraries, mostly to simplify 64-bit support. You can play with LD_LIBRARY_PATH and use your own libraries but I don't want to hear about it. If you don't get any sound in the game, for example, it's probably because your /dev/dsp device is already in use by another application. In order to fix that you need to close the application which is keeping /dev/dsp busy (hint: www-plugins/adobe-flash), or use your own libasound.so.2. But let me say that again: you're on your own.

Anyway. Enjoy Sacred Gold and tell me how it is. I have played it a whole five minutes and it looks like it has potential.

Many thanks to David Molanphy, my brother-in-law, who designed a new theme for Planet Larry.  I just pushed it live, and it's running on the new server.  Personally, I think it's awesome.

I've taken the old theme, which was in a competition by itself to see how ugly things could get, and unceremoniously shot it behind a barn.

http://dev.gentoo.org/~eva/gnome/gnome-2.26.3.html

Many of you might wonder what the hell is the gnome team up to for not stabilizing gnome 2.26 yet. Well gnome 2.26.3 is finally as complete as I want it to be in tree (as of a few hours ago) and we can finally focus on writing an upgrade guide and working out a stabilization list. There are still a few rough edges, like the libsoup problem but things should be a lot smoother than earlier 2.26 revisions.

Update: There have been a few users and devs alike who asked me why is it that my status page only shows ekiga-2. The explanation is simple, since I can't install ekiga-3, it doesn't show up on the page. This is because of a bug which prevents me from compiling it that I should report with a solution soonish.

Nick J. White’s “njw” overlay has been added to the list of “registered” overlays (i.e. to layman-global.txt) recently.

Besides other ebuilds it features an ebuild for the lastest version of GNU IceCat, the GNU project’s zero-non-libre-bytes edition of Mozilla Firefox.

Check it out through

sudo layman -a njw
sudo autounmask www-client/icecat-3.5.1
sudo emerge -av =www-client/icecat

I want Nick to become a Gentoo dev so please tell him if you like his ebuilds

From July 15 to September 15 the

• Git User Survey 2009

is open for participation. It’s fun and you might shape Git’s future a bit.

Please have a look.

I have not blogged here for some time. But that does not necessarily mean I am slacking, ;). Instead I have been doing things. I should've blogged more.

http://www.gentoo-cn.org/gitweb/?p=loongson.git;a=shortlog

Redhatter posted two blogs related to Yeeloong's status. I guess I should say something too.

First of all, I recommend this mailing list http://groups.google.com/group/loongson-dev to those who want to know the latest news about Loongson. If you want to try Gentoo on Yeeloong, you can take this http://www.gentoo-cn.org/~zhangle/loongson_mips3_n32_mplt_20081231.tar.bz2 The file's sha256sum is c94bcd45e58e5f4b8314942a6b3110a2316fd74adb009c8269d1e8e2077d7c72. Please note the userland is N32 ABI, meaning there may be more problems than in O32. But I should've already solved many of them for you.

I have been working on Fuloong 2E/2F and Yeeloong's support, particularly N32 ABI system. Firefox is just one example.

I have 3 Loongson machines, all donated by lemote:

1. One Fuloong 2E box. Now gentoo-cn.org is running on it. O32 ABI userland. Gcc 4.4, -march=loongson2e. MIPS plt. I am not running X on it. I am not sure if Redhatter runs X on it or not. If not, then you can say that Fuloong 2E has not X support in Gentoo. Anyway, I think very few people have it, and even fewer are using it as desktop.
   
2. One Fuloong 2F box. I have two Gentoo on it. One O32 ABI userland, the other is N32 ABI userland. Gcc 4.4, -march=loongson2f. MIPS plt. xorg-server-1.6.2. LXDE. Dev machine.
   
3. One Yeeloong notebook. I have one Gentoo on it. N32 ABI userland. xorg-server-1.6.2. xf86-video-siliconmotion-1.7.2. LXDE. Dev machine.

For the kernel support, please just use this kernel source, all you want is just there: http://groups.google.com/group/loongson-dev/browse_thread/thread/1b0a6a4f7c2485e8 You don't need to have gcc 4.4 if you don't care about -march=loongons2f. There is some magic in the Makefile which could make the compiling just work. And in this source, as option -mfix-ls2f-kernel is not enabled. So that binutils patch is not required for this source to compile. And this patch solves the problem that system sometimes hangs under stress test. So if your system never hang before, then maybe you don't need it.

For firefox, upstream xulrunner 1.9.1 already has O32 ABI patch. So nothing extra need to be done if you want to run Firefox in O32 ABI userland. Just emerge. If you are using N32 ABI userland, please use the ebuild from my overlay, check the link at the top. I haven't tried thunderbird though. I am now using Mutt anyway, :D.

For X, it is quite complicated. You can claim that X server now requires no patch at all, but that actually depends on which machine and which version of xorg-server you are using. On Fuloong 2F, xorg-server-1.6.2 does not need patching, the driver I am using now is the highest version of xf86-video-sis in tree. On Yeeloong, xorg-server-1.6.2 need patching if you use xf86-video-siliconmotion-1.7.2 from xorg (I have a live ebuild for it in my overlay). If you use xorg-server-1.4.x, you can also use xf86-video-siliconmotion-2.2.8 (I will explain it immediately) from lemote, this way xorg-server does not need patching. BTW, this xf86-video-siliconmotion-2.2.8 is actually from siliconmotion card's manufacturer, it should be based on xorg's xf86-video-siliconmotion somewhere before it has got libpciaccess support and later it has got its own version numbering scheme. So this xf86-video-siliconmotion-2.2.8 won't work on xorg-server-1.5.x and later. And I have tried to add libpciaccess support to it, but after done what I think is necessary, I found there are more problems. So I gave up on xf86-video-siliconmotion-2.2.8. I left the sources here: http://www.gentoo-cn.org/gitweb/?p=siliconmotion.git;a=summary Then I tried to fix xorg's siliconmotion driver, and I found the cause http://bugs.freedesktop.org/show_bug.cgi?id=21528. So now xf86-video-siliconmotion-1.7.2 is working on Yeeloong without any patch, only if you use 24 bit depth. If you use 16 bit depth which is required for dual head mode, there are still problems. http://bugs.freedesktop.org/show_bug.cgi?id=21622 Also there maybe some configuration options are needed in xorg.conf for X to work, so please check out my xorg.conf on fuloong2f and yeeloong.

Well… three bits of news to share… I can’t be stuffed doing three separate posts however, so I’ll stuff all three into the one, it puts less load on the servers involved.

X.org working on Yeeloong

I managed to get X going on the Yeeloong within Gentoo… I’m currently battling problems with Python 2.6 not building, but at least X runs.  I hope to get the necessary patches into my overlay shortly.

• latest xorg-server ebuild works… you just need to add the loongson patch for version 1.6.0.  This is already in my overlay, just needs updating.
• xf86-video-siliconmotion needs a patch to detect the video RAM.  This is due to the driver relying on some magic BIOS trickery which naturally doesn’t work on a BIOS-less RISC machine like the Yeeloong.
• xorg.conf needs the LCD panel resolution specified … that is: Options “PanelSize” “1024×600″ in the options for the siliconmotion driver.

VK4MSL contactable via IRLP

I recently put my homebrew 2m vertical back up … this time, using the mounting brackets from my old 2.4GHz vertical, and mounting the thing up as high on the antenna mast as I can push it. The choke balun on the antenna is level with the TV antenna yagi, so most of the radiated power is well above the TV antenna.

With this, I am now not only kinda able to work previously impossible repeaters such as VK4RBS (Bayside/Alex Hills), but also VK4RSS at Ocean View. What’s so good about VK4RSS? Well, I’m tripping it with 500mW of power (therefore good access when using 5W)… and it happens to be accessible via IRLP as node 6215.

I can also be sporadically reached on EchoLink node 37 37 40.

Graduated at last

I did say there were three items in this bulletin. I finally received my academic transcript, confirming that I have formally completed my studies at QUT, graduating with the following qualifications…

• Bachelor of Engineering (Electronics)
• Bachelor of Information Technology (Software Engineering)

This is timely, right at the bottom of the employment market… but I can’t help that.  Now begins the task of finding work in the Brisbane area.  I’m still running to/from Laidley doing some work out there… which may turn into paid employment (I hope so anyway… costs me almost $8 a day with a student discount in transport… That’ll double to about $15 when that card expires).

If anyone’s looking for someone to assist, particularly in the telecommunications field (I have a soft spot for radio and embedded systems)… feel free to get in touch directly.

I recently arrived in Nepal to help the local One Laptop per Child implementation, being run by a local organisation known as OLE Nepal.

One of the things you learn early on is that this deployment is very much focused on content for the Nepali primary school curriculum. OLPC tends to push for a more exploratory “constructionist” learning approach, but it’s clear that the Nepalese project is simply focusing on what is locally appropriate, taking the route that wins one of the key ingredients of any OLPC implementation: support from teachers.

OLE Nepal has an impressively large team who generate content. They take specific points from the Nepali curriculum, and work with teachers to generate games and exercises. The team includes programmers, education specialists, and graphic designers. The outcome of each task is some kind of interactive educational game/exercise, a lesson plan, some help text, and a reference to the specific point of the Nepali curriculum which the activity aims to teach. So far, they have content for English, Maths and Nepali for grades 2, 3 and 6 — the total content is more than can fit on the storage of the XO laptop, so they deliver it in chunks.

And while this kind of approach does limit the children to their curriculum, it’s not like the content is plain or boring. The activities are very interactive and are of high quality. The children take the laptops home, and naturally explore the usual Sugar activities too. An interesting recent development that we experienced on a school visit was that the teachers requested training on how to use more of the Sugar activities on the laptop – they now appear keen to harness more of the benefits of the project and perhaps look a little outside of the rigid curriculum. Or perhaps they just feel outgunned by the children, who are racing ahead with their laptop-using abilities.

The content described above is known as E-Paath. Additionally, OLE Nepal develops E-Pustakayala, an electronic library which is cloned on all of the school servers. Thanks to various supporters, there is an impressive breadth of content available there too.

Another project that has impressed me is Karma, the Nepal-driven project to generate educational content using HTML5 and Javascript. This was born when the organisation decided that they wanted to share their high-quality educational content with other deployments around the world, but realised that the primary technology used (Flash) makes distribution and localisation overly difficult. For me, the great thing about this is to see a deployment really focusing on the question of “How can we help the worldwide OLPC community?” as many deployments are either too drowned in work to make such efforts, or do not realise the benefits of doing so.

For my 3 month stay, my primary roles are to support the deployment manager, pass on some technical skills to the local employees, and to make various improvements to the school server.

The part of the socket(7) man page about setsockopt(.., SOL_SOCKET, SO_PRIORITY…)  says:

« For ip(7), this also sets the  IP  type-of- service  (TOS)  field  for outgoing packets. »

I wanted to know how exactly it mapped the socket priority to the ToS field, so I looked in the kernel code for a while, and it turns out that in recent Linux 2.6 kernel, this is a lie. The ToS field is never set when the application selects the socket priority, only the internal priority of the packet is set. That said, the reverse is true, setting setsockopt(.., IPPROTO_IP, IP_TOS…)  sets both the ToS header field and the internal priority of the packet.

So the question here is: Who is wrong, is the kernel buggy? Or is the man page incorrect?

Also, dear lazyweb, is there any support for applications to set the DiffServ field? Or are they only settable through iptables?

If you happen to be on an AIX 5.x host using Gentoo Prefix. Then you might see something like this eventually:

/bin/sh[3]: /home/jolexa/portage/aix-5.3/bin/chmod: arg list too long

This is caused by build systems that use wildcards or even ebuilds that have no issues on a normal GNU/Linux system. To work around this, you need to change the ARG/ENV list size in 4K byte blocks. The default value in AIX 5.x is 6. This is way too small. You will either need root access or kindly ask your system administrator to change this value. To change it, you have two options: use smitty (a curses sys-admin tool on AIX) or do root# chdev -l sys0 -a ncargs=40 on the command line

If you use smitty, you are looking for this:

root# smitty
=> System Environments
    => Change / Show Characteristics of Operating System
         ARG/ENV list size in 4K byte blocks                [40]

40 seems to be a good number. It would be hard to guess the smallest number possible. This is not a problem in AIX 6.1, because the default seems to be '256'

Well, hal-0.5.13 is in the tree and fully working.  This brings us up to current for the hal world,  and should unblock further udev/devicekit work.

Sorry for the problems getting it it; it was a major change.  Hotplug is working again.

If anything is still broken for you, you know where to go.

HSM (from Paderborn, Germany) is – once again – searching for a Linux/Firewall specialist:

HSM is a renowned, high profile Firewall development company headquartered in Paderborn / Germany.
HSM is searching for Linux specialists with good Gentoo knowledge for further development and customer support for their Linux-based universal firewall-software with a new and unique product concept. (www.octogate.de).
Successfull candidates will have ample Linux experience, which especially covers TCP/IP and Routing, Perl, Java-Script and BASH Scripting, Apache, Bind, DNS, SQUID, Postfix and MySQL, plus communicative skills, organised work habits and consequent customer orientation.

This position offers candidates with the respective long-term professional experience the possibility of ascending to a managing position. For candidates with initial professional experiences we provide attractive training and further qualification possibilities. For further information contact HSM under the following email
Address frank.menne@hsm.de

Well… I’ve been quiet, but slowly, I’m preparing what will become a port of Gentoo/MIPS to the Lemote Yeeloong.

I have it booting off a USB HDD for now, sans X11, but I’m working on that.  The kernel at present needs some patches not yet present in the Linux/MIPS kernel tree.  To build a kernel, you also need GCC 4.4.0 (which supports -march=loongson2f) and binutils (2.19.51.0.2 or later) with this patch.  I’m looking into what is necessary in order to get these patches into our tree.  Patched ebuilds for both are in my overlay.

Once that is done… next attention will be to Mozilla Firefox 3.5 and Mozilla Thunderbird, both of which have been lagging on MIPS since I took my hiatus.  I’m still running to/from Laidley, but with the travel time… this would seem an excellent moment for package testing once I get Gentoo installed on this machine.

Here’s hoping I can return with some goodies for everyone shortly.