This was originally sent to the linux-kernel and driver-devel mailing lists. Based on some of the feedback I got, I figured I should post it here as well.

Here's a summary of the state of the drivers/staging/ tree, basically what will be coming in the 2.6.32 merge, and what the status of the different drivers are so far.

First off, drivers/staging/ is NOT a dumping ground for dead code. If no one steps up to maintain and work to get the code merged into the main portion of the kernel, the drivers will be removed.

As proof of that, the epl (Ethernet Power Link) driver will be removed in the .32 kernel, as no one is working on it, the upstream developers never respond to my emails, and no one seems to care about it.

The pata_rdc driver is also going to be removed, as there is a "better" one being merged through the libata tree for this hardware.

So, taking the drivers in chunks, here's some that have had active development on for the .32 release:

• rt* wireless drivers. Bart has done amazing work merging all of these together into something much better than they originally were. And even better, they still work! Great job Bart!

• rtl* wireless drivers. Again, Bart has been doing great work here.

• wlan-ng driver: a bit of work here, but this seems to be dropping off, with the loss of a test platform for the driver. Hopefully someone has a device around and can help out here.

• comedi drivers had only a bit of work done, lots more is needed here, let's not loose the fact that this is getting closer to a mergable shape.

• android drivers have had a bit of work done, but upstream seems to not care at all about what is going on here, as they are working to forward port their code to the 2.6.29! kernel. {sigh}. If this keeps up, the drivers will be dropped in the 2.6.32 kernel release. Note, Pavel has been adding some of the Dream hardware drivers, which are separate from the core Android drivers. I have no objection to those, but they should work to get merged to their "correct" places in the tree in another release or so.

• w35und driver. It's slowly being worked on.

• echo driver. This one is now in good enough shape to merge into the main kernel tree. I'll send out review patches soon for this.

• eth131x driver. Alan Cox is working on fixing up the issues in this driver. Hopefully it will get into mergable shape soon.

New drivers that will show up in the .32 kernel release:

• vt66* wireless drivers. These VIA drivers are being actively worked on to get into a much better shape. Nice job.

• new rt3090, and rtl8192e wireless drivers have been added and worked on cleaning up issues involved in them.

• hv (Microsoft Hyper-V) drivers. Over 200 patches make up the massive cleanup effort needed to just get this code into a semi-sane kernel coding style (someone owes me a bit bottle of rum for that work!) Unfortunately the Microsoft developers seem to have disappeared, and no one is answering my emails. If they do not show back up to claim this driver soon, it will be removed in the 2.6.33 release. So sad...

• quatech_usb2 driver. I don't know if it quite works, but someone is developing it, so I'm not complaining :)

• VME bus drivers. Yeah! They are progressing nicely.

• SEP and RAR drivers. Alan Cox has been working on cleaning these up a lot.

• IIO (Industrial I/O), these are new drivers that are being actively worked on.

• pohmelfs and dst. It seems that DST is dead, so I think I will remove it in .33. pohmelfs is under active development outside of the tree, and hopefully patches start moving in here to help out with keeping it up to date.

• cowloop. Yes, another COW driver! :) Seriously, this does things that DM can't do, so it might be useful. The upstream developer is interested in getting this merged properly, and is working on cleaning it up.

Drivers not being actively worked on:

• otus This is sitting here until a "real" wireless driver will be merged through the wireless tree. Hopefully that happens soon.

• agnx wireless driver. No one seems to care about it. If no one steps up soon, it will be removed in .33.

• altpciechdma Upstream developers seem to have disappeared. Again, if no one steps up, it will be removed in .33

• asus_oled This only needs minor cleanups to get merged properly into the main tree. If someone wants an easy project, this would be it.

• at76_usb wireless driver. Again, no one working on it, it will be dropped in .33.

• b3dfg I really do not think anyone cares about this. again, will be dropped if this is true in .33.

• cpc-usb After the initial flurry of development, everyone seems to have run away. Was it the fact that I hadn't showered in a few days? Again, will be removed if no one comes back. And I am wearing deodorant now...

• frontier A nice driver, again, should not be hard to get merged into the main tree, if someone wants an easy project...

• go7007 Ugh. Unless someone steps up now to take this over, it's going to be removed in .33. There is no hardware made with this anymore, and no specs around that I know of, and the code isn't the nicest in the world.

• heci A wonderful example of a company throwing code over the wall, watching it get rejected, and then running away as fast as possible, all the while yelling over their shoulder, "it's required on all new systems, you will love it!" We don't, it sucks, either fix it up, or I am removing it.

• line6 Another nice driver that should be simple to get merged. Please, if you are looking for something to do, this is it.

• me4000 and meilhaus They work on the same hardware, and they duplicate the existing COMEDI drivers. Someone thinks that custom userspace interfaces are fun and required. Turns out that being special and unique is not what to do here, use the COMEDI drivers instead. These will be removed. Heck, I'll go remove them for .32, there is no reason these should still be around, except to watch the RT guys squirm as they try to figure out the byzantine locking and build logic here (which certainly does count for something, cheap entertainment is always good.)

• mimio Another driver that should be simple to get merged. Someone just step up to do this please, there are users of this hardware out there.

• p9auth While it seemed like a good idea, I don't think that anyone actually uses this. It will be removed in .33 unless someone comes forward.

• panel Another one that should be simple to merge. Anyone?

• phison What? I thought I asked for this to be merged a while ago, sorry about that, no reason it should still be in staging anymore, it's just so small it slipped through the cracks...

• poch A long-suffering company is enduring the slowest developers in the world here. Hopefully the code will be replaced with a UIO driver, but testing the userspace side seems to be difficult and slow. I have to give Redrapids major credit for being patient here, they are being amazing.

• rspiusb A weird, very expensive camera, from a company that does not want to release the specs, and wants custom userspace interfaces. The code hasn't built since the 2.6.20 days. I'll go delete it now from .32, it doesn't deserve to live as no one cares about it, least of all, the original authors of the code :(

• slicoss and sxg These are being developed by a consulting company for the main producer of the chips. Yet they seem to have disappeared half-way through the job. Odd. Hopefully they come back soon.

• stlc45xx Another wireless driver that no one seems to care about. So sad. I guess no one will miss it when it goes away in .33.

• udlfb Video over USB, it doesn't get anymore whacked than that. This is still being developed but the developer doesn't like to do incremental updates for some odd reason. Hopefully he pops up again with an update. But for now, it is quite workable for a number of developers.

• usbip USB over IP. I guess if you ran video over IP to your USB device, that would be more whacked than just video over USB. This did get one big update during the .32 development cycle, hopefully the developer can come back again when they get some free time to continue working on it. Rumor has it that some major distros are starting to rely on this code, so it would be nice to get their help to get it working better...

That should cover all of the 600+ patches in the staging tree for the .32 kernel merge, and the existing drivers/staging/ tree. If I missed anything, please let me know.

Yesterday, I finally found the bug which prevented neatx from working on my system (thanks upstream for the debugging), so in your next portage sync, you'll find net-misc/neatx-0.3.1_p43 ready for your testing! If you don't need vnc/sound/printer tunneling or load-balancing, neatx is easier to set up than freenx and works great out-of-the-box. Thanks again to Mike Auty (ikelos) for his work on the ebuild.

Another work-in-progress for me these days is a source ebuild for chromium (open-source version of Google Chrome). A binary version (chromium-bin) has been available in portage for some time now (with amd64 support added recently), but source version ebuild had some problems. Now my current version (available in my overlay for the curious) has fixed most of them, including use of system libraries, makefiles use instead of scons, --as-needed support, ... So why is it not yet in portage? Well, for now the tarballs from upstream are not yet available, so you won't go past the fetch phase These should be available soon, once available you can expect chromium to quickly land in a portage tree near you.

By the way, if chromium crashes at startup for you (either binary or source version), they finally found the cause: you are probably using nvidia-drivers and nvidia opengl (via eselect opengl). However the libGL.so from nvidia overrides dlsym/dlopen (dynamic linker functions) with broken replacements, breaking applications relying on these functions! Chromium devs implemented a workaround, available for -bin in versions >=4.0.208.0_p25708, but expect some breakage in time-related functions. All the gory details are here: http://code.google.com/p/chromium/issues/detail?id=16800

And now to change a bit from technical talks, I wanted to say a big "thank you" to all of you Gentoo users who spend time filing bugreports, fixing, writing or rewriting ebuilds, debugging and finding the cause for all sorts of bugs (finding that some dynamic linkers break with specific video cards for example...), in short to all of you who work to make your distro a better one! And recently, a special thanks to Bernd Lommerzheim, who helps me a lot in proftpd maintenance, up to providing an entirely new ebuild for latest version, with lots of fixes and new features.

Originally texmfind has been written by a Gentoo user to find out which TeX file (LaTeX, too) is available in which package so you can emerge the correct one. Unfortunately it has not been updated for TeXLive 2008 and so looses some functionality, although some entries are still valid. Now I forked the project and updated it. The ebuild 2008.1 is already available in testing. Check it out, a stabilisation should happen soon.

Nokia switched their Qt git master to version 4.7 recently, creating a new branch for 4.6.

They also created two new branches, master-stable and 4.6-stable. Commits pushed to those branches are tested in Nokia’s testing farms, ensuring that they’ll always build.

The Gentoo Qt team provides various live Qt ebuilds in our official overlay, qting-edge [1]. These ebuilds now include x11-libs/qt-*-4.6.9999, building code from the 4.6 Qt branch, as well as a new USE flag called stable-branch, available (and enabled by default) in 4.6.9999 and 4.9999. This USE flag enables/disables the use of the stable branches, allowing you to choose between last-minute code VS tested, known to compile code.

Either way, its bleeding edge!

If you need help, leave a comment or visit us @ Freenode IRC, #gentoo-kde

[1] to install qting-edge, make sure you have layman installed and configured, then run layman -a qting-edge.

Ravelry is a knit and crochet community. In an interview with Tim Bray of ongoing,  their site engineer Casey Forbes says: “We have 7 servers running Gentoo Linux and virtualized into a total of 13 virtual servers with Xen.” On these servers they use nginx, HAProxy, Apache, MySQL, and of course Ruby on Rails (with Passenger). And how they use it!

We’ve got 430,000 registered users, in a month we’ll see 200,000 of those, about 135,000 in a week and about 70,000 in a day.
We peak at 3.6 million pageviews per day. That’s registered users only (doesn’t include the very few pages that are Google accessible) and does not include the usual API calls, RSS feeds, AJAX.
Actual requests that hit Rails per day is 10 million.
900 new users sign up per day.
The forums are very active with about 50,000 new posts being written each day.

Thanks for sharing the details, it’s what keeps us developers running. At least those as vain as me.

Now a live ebuild for g-CTAN has been added to the tree as I now want some real life testing: Please go and emerge app-portage/g-ctan. g-CTAN is similar to g-cpan which creates an ebuild for packages from the Comprehensive TeX Archive Network (CTAN). The usage is easy, just call the --help option to learn more after you emerged it. There are two posts by me, that explain some more details about it. There are still rough edges, but please don't hesitate to report bugs either over Gentoo Bugzilla, Launchpad or email. The one thing I still would like to solve is to filter out all packages from the listing that have not been updated since the release of TeXLive.

UPDATE: 4.3.1 is now unmasked for amd64/x86 and the masking issue has been fixed by jmbsvicetto, so we won’t have this issue again in the future! The post below is updated to reflect on it.

The first bugfix release for KDE 4.3, 4.3.1, is now available.

You can read about the improvements it brings here.

Ebuilds for KDE 4.3.1 are already available in gentoo for architectures amd64 and x86.

To upgrade from 4.3.0 you simply need to

emerge --sync
emerge -avDuN world

This should be a straightforward update for most people.

If you’re upgrading from an older KDE 4 version (or clean-installing KDE 4 on a stable system) you should keyword-unmask KDE 4.3 by following this post’s instructions. You’ll also find some troubleshooting hints there.

The ebuilds are hard.masked for all other architectures due to bug 280312.

As usual, if you have any issues, feel free to leave a comment or visit us @ IRC: freenode/#gentoo-kde

One thing I'm noticing a bit of confusion on in general online is what the docs or me mean when it says to install the ALSA sound card drivers as modules.  So, lemme clarify real quick.

There are two *places* to get the drivers from: either in the kernel, or from the alsa-driver package.  But, when using the kernel drivers, like many other drivers there, they can either be compiled in statically or loaded as modules as the computer is booting up.  So, there are actually two ways to install the drivers as modules, which could be a bit confusing.

So, a quick list:

1) In-kernel drivers (statically compiled)

2) In-kernel drivers (modules)

3) External drivers (alsa-driver package, modules)

The first two are the officially supported methods by the ALSA team, so I'll quickly focus on those two.  Now the, recommended way to do things is #2 -- select them as modules in the kernel and build them that way when you are setting up ALSA for the very first time.  Why?  Well, the answer is really that it gives you a lot more options.

Let's say, for instance, that you aren't sure which driver your card requires.  So, you flip on a few that look like it's the right one, and set them to be installed as modules.  Once they are there,  you can run alsaconf, which is a part of alsa-utils.  The alsaconf program will do the detective work for you by looking at the modules that are available on the system, and the cards that you have on your box, and then load the modules and update your module list so that they will load up the next time you boot your box as well.  Pretty simple, right?  It sure is a lot faster than compiling one driver in the kernel, rebooting, testing if that works, trying a separate one, rebooting, etc.

Another reason is that there may be some options you need to pass to your module.  This is rare, but it does happen.  If you are loading them as modules already, then it's just a simple tweak to do change the settings, again, without having to reboot and re-test everything.

So, that's the reason we recommend you load them as modules.  It's just gonna make life a bit easier the first time around, as you are trying to determine what you have.  Once you know what driver is required, you can always go back into the kernel and compile it in statically, and be done with it.  There's no reason to keep it as a module, unless you want to.

Finally, a quick note about the alsa-driver package.  It's often said that it is unmaintained, and the reason for that is because I, personally, am the only one who is keeping it on life support.  That is, I'm the maintainer, not the ALSA herd.  It's only in the tree as a convenience to people who need to use it for whatever reason.  Some of the reasons could be that you needed to see if the latest release from upstream is fixing some issues of yours, so you'd use the live ebuild.  Or, you may want to use an older kernel but still keep the newer version of ALSA.  Or whatever.  The problem, though, is that I don't have the technical skills to troubleshoot your issues if something goes wrong.  My solution every time is  pretty much going to shrug and say "Sorry, that sucks.  Try the live ebuild, or something else."  It's not that I don't want to help, it's that in this case, I can't.

Anyway, that's it ... I hope that clears up a few issues.  When I have time, I'll be revising the ALSA docs.  No idea when that'll be though.  Don't hold your breath.  In the meantime, if you have issues, my recommendation is to post on the Gentoo Forums in the Multimedia forum and ask for some help, or there's always bugzilla.  Chances are you'll get a response faster on the forums, though.  Good luck, and God speed.

I caught the news yesterday via Phoronix that a new version of ALSA libraries and utilties came out.  I went to go bump them in the portage tree, but Tony (chainsaw) already beat me to it.  Thanks, man!

Looking at the detailed changelog, there are a lot of updates for the *hda cards, which is just what the world needed.  I haven't ever had any problems with them myself, but they are the de facto chipset on desktop motherboards right now, and it's awesome to see support getting improved.  Hopefully it'll fix some of the countless issues Gentoo users are experiencing.

History

When I looked at the state of graphical IMAP e-mail clients several years ago, I was not really impressed. KMail from then-current KDE3 did not do a proper job for me (numerous IMAP bugs like its inability to work as about every other IMAP client when deleting messages, bug 26986 -- there were more issues than that, but years have left my memories washed out a bit), Thunderbird would crash for me every once a week, at least, and I just happened to like KDE applications more than Gnome stuff, so I did not spend much time looking at Evolution. Many MUAs looked like a classic generic e-mail clients designed with POP3 in mind with IMAP added late in the development cycle, while others supported wide range of IMAP features, yet lacked in the GUI part of the problem. In short, using none of these applications made me feel happy.

A programmer not feeling happy is a receipt for disaster. I was about to finish my high school, so I had plenty of time at hand. I was experimenting with Python, so that seemed like a natural implementation language, too. In the end, I started a project called trojita whose remnants could still be seen in an abandoned SVN repo.

Coding in Python was fun. I tried several different approaches to the design of my pet program, I was playing with technologies I had no experience with, I even showed my "IMAP library" at my final exam as an example of a project I made. It did not have much functionality, in fact, only the IMAP parser had been completed, but it was an educative experience nonetheless and I passed the exam.

After some time, however, I discovered Qt and C++ and felt in love. I joyfully returned to the realm of statically-typed languages and suddenly felt a lot better. I began porting my Python library to Qt/C++. It was not really a port, rather a first complete rewrite of my project. Anyway, it did not take long and the C++ version suddenly offered more functions than the old Python branch, with unit tests as a nice added bonus.

Qt's Interview architecture, the Model/View classes, seemed like a decent implementation of the MVC patter I was poking around to use. Several months have passed, and suddenly trojita was able to show a tree of mailboxes stored on a remote IMAP server, listing messages contained therein and showing message bodies. I choose to finish the program as a part of my bachelor's thesis, and ultimately, I succeeded.

The Code

So, in a few blogposts starting with this one I'm going to introduce a new Qt IMAP e-mail client to the world. I hope I will get some attention and folks looking at the code and trying to run the application. I'd love to get some feedback on program design, code quality and general usability as well.

The code is hosted at Gitorious, and a bachelor thesis about Trojitá (PDF) (mirror) which explains its design and compares it against several alternatives is available, too. Perhaps the most interesting part is Chapter 3 which describes the architecture of the application, and Chapter 4 in which I compare Trojitá to several other MUAs on the market. All information about Trojitá are also aggregated on Trojitá's homepage (any web designer listening? :) ). Here is the obligatory screenshot:

Trojitá's Features

Some highlights of Trojitá are:

• A pure Qt4 application with no additional dependencies
• Robust IMAP core implemented using Qt's Model-View framework
• Standards compliance is a design goal
• Support for bandwidth-saving mode aimed at mobile users with expensive connection
• IMAP over SSH -- instead of going over an SSL socket, the server could be accessed via SSH
• On-demand body part loading
• Offline IMAP support (you can access data you already have; there's no complete "offline mail access" yet, though)
• Safe dealing with HTML mail (actually more robust than Thunderbird's)

The thesis was completed several months ago. Since that time, I've removed the dependency on std::tr1::shared_ptr and switched to Qt's QSharedPointer which in turn requires Qt-4.5 or newer. There wasn't much more changes since then, as I enjoyed quite a long vacation, but I guess I can tell the development is getting faster again.

How to Use it

It's a fairly standard CMake setup:

git clone git://gitorious.org/trojita/trojita.git
cd trojita
mkdir _build
cd _build
cmake -DCMAKE_BUILD_TYPE=RelWithDebInfo ..
make -j4
./trojita

Please do join the #trojita channel on Freenode and tell me how you like this application. I'm open to any suggestions and would love to hear any feedback, too.

As you can see, this blog is a static HTML page, so you can't post any comments here. However, I'm eager to answer any questions sent to my mail, both via e-mail and in subsequent blog posts.

Markus Duft writes:

I'm preparing to conquer the world (again) . To achieve my goal, I have
prepared a new Gentoo Prefix on Windows Setup, and the according
documentation.

Video demonstrating the installation of Gentoo Prefix/Windows: http://www.youtube.com/watch?v=az1RR60s5n4

Grab the latest iso's from: http://distfiles.gentoo.org/experimental/prefix/x86-interix/20090826/

Docs: http://dev.gentoo.org/~mduft/gpx-installation-20090820.pdf (also available on the DVD installer)

Hello all,

Yesterday (Thursday, 27 August 2009), David Abbott from LinuxCrazy, and Gentoo-PR interviewed me for his 62nd podcast. We discussed many aspects of Gentoo, including my involvement with the fora, documentation, project strengths, areas of concern, Openbox and LXDE, and more. This is a two-part podcast, and the first portion is an interview with Zachary (son of Gentoo user weirdedout) about one of his favourite Linux games, Warzone 2100. Thank you Zachary for your review of WZ2100!

If you would like to listen to the podcast, it is available in Ogg format (preferred), or in MP3. The Ogg format is available here on the Z-Issue, while the Ogg and MP3 versions are both available on LinuxCrazy.

OGG format of the podcast (please right-click and hit "save as" to download a copy)

If you don't want to listen to the podcast, there is a transcription of most of it (not verbatim, but hits many of the key points) on the Gentoo Fora.

Thanks for the interview David!

|:| Zach |:|

All,

Many of you have, no doubt, learned of the recent loss to the Gentoo community. Known fondly as fmccor, Mr. Ferris E. McCormick's death was tragic and unexpected. His many contributions to the greater open source community will always be remembered as well as his generous friendship. It is in due honor to his life and good name that the Gentoo Foundation has donated a sum of $500 to the Electronic Frontier Foundation (EFF). The board of trustees believe that our donation is reflective of his wishes, given fmccor's professional life as a lawyer, and that this gift will further the movements he cared a great deal about, open source software and protecting our freedom.

The board would like to take this opportunity to encourage any and all individuals that personally knew fmccor or were benefiting from his life long contributions to donate, in kind and to the best of your ability, either to the EFF, the Gentoo Foundation, or another organization that you feel expresses these ideas.

In this podcast we have the two Zach's. The first Zach is one of weirdedout's twin boys, Zachary, and he will tell us about one of his favorite games, Warzone2100. The second Zach is Nathan Zachary, Gentoo Developer. Zach talks about ways users can get involved and the steps to become a Gentoo Staff member, full Gentoo Developer, and much more.

If you would prefer to read the interview;
http://forums.gentoo.org/viewtopic-p-5948487.html#5948487

LINKS:
Warzone2100
About Warzone2100
http://en.wikipedia.org/wiki/Warzone_2100
Warzone 2100 Open Source Project
http://wz2100.net/

Nathan Zachary
Gentoo Forums
http://forums.gentoo.org/profile.php?mode=viewprofile&u=158400
Gentoo Developer Web Space
http://dev.gentoo.org/~nathanzachary/
The OpenBox Configuration HOWTO
http://www.gentoo.org/doc/en/openbox.xml
The LXDE Configuration HOWTO Beta
http://dev.gentoo.org/~nathanzachary/documentation/lxde_1.0.xml
Bugzilla
https://bugs.gentoo.org/show_bug.cgi?id=230279

irc network freenode channel #linuxcrazy

Download

So I'm reading through my RSS feeds and stumble across this gem:

Ciaranm quoting something from the funtoo.org FAQ about how funtoo.org only works with Internet Explorer or something

So, like, I look at the Funtoo FAQ that is linked from that blog.
Read it.
Don't find any mention of Firefox
Do a fulltext search just in case

So now I'm wondering, wtf is happening?
Is this a fast edit from the funtoo people in under 30 minutes? I find that unlikely. Or is Ciaran hallucinating badly (as seen with PMS and other works of fiction) and needs to have his medication adjusted?

I'd guess it's the usual FUD, and most likely ignoring it would be the "right" thing to do, but if you catch a kid urinating in the pool you usually spank it in the hope of teaching it not to do it again.

I started a thread on the Gentoo Forums the other week, trying to get users to post what are common issues that they run into collectively. I'm hoping to see if I can find some patterns and either update the documentation or write a FAQ. If you have anything to share, please do.

And for the record, here is my first line of defense that I will tell anyone when they have no sound / wrong driver issues:

- Use latest ALSA (and kernel) in the tree. In this case, it's 1.0.20, and we've cleaned up a lot of crap that was causing issues.

- Compile everything sound-related in the kernel as a module. Yes, everything. No, not just the stuff that you *think* you can statically compile in --- *ev-e-ry-thing.* Once you've done that, run alsaconf. If your card doesn't show up, it's either completely unsupported (unlikely) or you didn't pick the right drivers. Go back in and flip on more stuff. As modules.

- If the correct drivers are loaded (aplay -L works), and you have no sound, then your mixer levels are probably wrong.

Apologies for coming across so heavy-handed, but that's the approach that has always worked for me, and works for most everyone when I tell them to do that: latest kernel, latest ALSA, everything as modules, alsaconf, then mixer.

Edit: Just as a postscript, the reason for the bluntness is that I recently started taking a more active role in the ALSA herd. Normally, I would just do version bumps and leave it at that. But, I'm trying to get practical issues resolved, and the one common thread I see over and over and over again on the forums and IRC is people just going off on their own little path and stabbing in the dark to see if they can get their sound to work, and then acting surprised that some random configuration didn't work.

I want to very much find both the source of this disinformation and correct it, and make sure that setting up sound is a really simple process. The *problem* though, is that it's always been pretty extremely easy for me, and so I am having a really difficult time understanding *why* people are hitting these issues -- hence, the reason for the forum post asking people why they are running into problems, and what thoughts and conclusions lead to that direction. Once I figure that out, then I can go back and tweak the docs to clarify situations and attack the common confusion.

I keep getting the idea that we could use a really simplified version of the ALSA doc, one that is a quick basic howto get setup for people with one soundcard, and then include examples using the most popular hardware out there right now (intel-hda). Then, have a separate doc for more advanced issues, for people who need help and information on alsa plugins, or have multiple sound cards and things like that. I think that lumping them together into one, as it is now, makes it hard for people who just want to get up and running.

So, apologies if it feels like I'm browbeating here, but the reality is that I'm really motivated to streamline the process of getting sound in Linux. Nothing but love, yo.

I think I stumbled upon Linux Mint on DistroWatch, upon this screnshot:

Somehow I wanted to see that wallpaper on my desk. Finally I found the image and put it up my desk:

It didn’t take long to where I wanted a version without the mint logo on it. The logo is nice but I don’t like to look at logos all day long. So I contacted the wallpaper’s author Zwopper who sent me a no-logo version in both green and blue in no time also allowed me to share it with you under a CC-BY-SA-3.0 license here. As far as I understand they have not been published like that elsewhere before. Here they are.

Click the thumbnails for PNG downloads with 2560×1600 pixels size.

Well… I’ve been busy getting the boxes into shape ready for new stagebuilds and a heap of other activities.

I have Firefox 3.5 going on mipsel… albeit a little shakey. I’ve got 99% of KDE 4.3 going also, again, a few glitches. I have turned my attention for the time being to the SGI machines here, since the kernels on all of them are out of date… and the userland is in a bit of a mess. Particularly on the Indy… which hasn’t been touched in a couple of years (e2fsck complained the disk wasn’t checked in over 1000 days).

The Indy (R4600SC) needs a new kernel, as its current one is too unstable to do anything useful. I remember kernel 2.6 being a royal bitch on this machine, hopefully things have improved. The IP28 is up and running… old kernel and userland, but it’s not quite as bad as the Indy… at least it’s stable. The O2 is similarly suffering an old kernel, but at least parts of its userland are in reasonable shape.

The two Fulongs are also getting an overhaul which is badly needed. The Yeeloong too, is undergoing further work to get things running.

Tonight, I managed to figure out battery monitoring within KDE 4.3… the trick was to unmask the apm USE-flag and re-merge hal with this feature enabled. Now the system displays the battery status as it should… if only I could get NetworkManager working properly, then everything would be sweet there.

I have a couple of tracker bugs relating to this work… bug 282264 is a tracking bug for KDE 4.x related tasks, and bug 282265 pertains to the changes needed for in-tree Lemote system support.

I intend to do a bit of work on both as I run between Brisbane and Laidley using the Yeeloong as a test platform, so hopefully we will have something for public release soon. In addition, I’ll be doing stagebuilds for the Gentoo/MIPS port generally, once my systems are back online.

Hi y'all,

If you're unsure what to do this (22. and 23. of August) weekend and you're accidentally near Bonn or Cologne in Germania ...

FROSCON is happening again. And Gentoo will have a presence there. So if you find the time, feel free to visit (and the 5Eur entrance fee are really worth it!) and meet us. This year we have a booth and a dev room where we can demonstrate out superior slacking skills (and, of course, the most awesome metadistribution ever!)

Experience from last years suggests a very nice, filled-with-fun, meeting of geeks, nerds and people that just like meeting other people. There's a nice program filled with interesting speeches and discussion rounds, lots 'o beer and quite likely some nice grilling or other kinds of food.
At the moment it looks like the weather will be good, so that'll make it even more fun. And if all that still doesn't convince you that you have to be there ... well ... then you don't deserve it anyway!

Hope to see y'all there,

Patrick the bonsaikitten

I'm still trying to decide where I wanna go with my media browser/frontend solution -- if I'm going to write my own or keep hacking on MythVideo. I only have one really nagging issue left now, and that is that the file structure presented is static once you enter the "Watch Videos" menu. I'd like it to be dynamic (that is, upon entering a new folder, check the contents again) so that I can add stuff like symlinks to series that I'm currently watching, or whatever. Doing that is pretty tricky.

I spent a few hours last night digging through the code, trying to find out exactly how the code is operating and what it's doing. What I learned was that, well Myth was doing exactly what I thought it was -- it builds a file list upon first entering, and then it doesn't examine it at all until you re-enter the video browser through the main myth menu. (I wish I had a decent screenshot about now, it's a bit confusing if you don't know what I'm talking about.)

There's a couple of problems with this approach, in my mind. First of all, the time it takes to actually load the mythvideo plugin grows in relation to how much media you have that it needs to parse. That is, it iterates over *every* single file that is in your media storage, and adds it to one variable. It's essentially like running find on your filesystem, saving it into one variable, and then when browsing, just using that snapshot that you took.

The simpler way, in my opinion, would be to just refresh the directory structure and metadata for the directory you are in. While I was poking at it, one thing I tried was to get the directory scan to not go more than one level deep. That reduced the startup time from about 8 seconds to less than one. Nice.

Ideally, I'd like to change it so it just updates the directory scan as it enters a new one, progressively growing the variable as you jump around the directory tree, but I couldn't figure out how to do that in the code (and if someone wants to help, that'd be awesome). MythVideo calls fetchVideos() only when first entering, and not anytime after that. The real problem is that it in turn calls about eight other levels of functions that eventually get to scanning the directory tree. I could probably hack it together to pass the current directory I'm in and update the directory scan from there, but again, I'm so limited in my C++ skills, at this point it's just code and guess. So, I can find and explain the problem, but not fix it myself.

Fortunately, it's a minor wish list item of mine, and so it's not a show stopper. I can live with not being able to do it, and it's probably just a matter of me learning how to code a bit more that I could figure it out. On the plus side, I'm learning more about the internals of the code, and each time I go in there, I find a few small inefficiencies that I can cleanup myself, which is fun. Making progress, I suppose.

Just a short comparison after the initial report: The shipped Debian takes 60 seconds till the Gnome desktop appears, while the LXDE of my Gentoo installation needs 40 seconds. Of course less features (or cruft) is available with the latter, so no real benchmark. Also Ubuntu has formed a team to do a port to the Loongson CPU.

The kernel provided by Lemote is 2.6.31-rc5 and I used the attached configuration to succcessfully built and run the kernel on my Loongson 2F-based Yeeloong netbook.

CONFIG_MIPS=y
CONFIG_MACH_LOONGSON=y
CONFIG_ARCH_SPARSEMEM_ENABLE=y
CONFIG_LEMOTE_YEELOONG2F=y
CONFIG_CS5536=y
CONFIG_SYS_HAS_MACH_PROM_INIT_CMDLINE=y
CONFIG_CS5536_MFGPT=y
CONFIG_UCA_SIZE=0x400000
CONFIG_RWSEM_GENERIC_SPINLOCK=y
CONFIG_ARCH_SUPPORTS_OPROFILE=y
CONFIG_GENERIC_FIND_NEXT_BIT=y
CONFIG_GENERIC_HWEIGHT=y
CONFIG_GENERIC_CALIBRATE_DELAY=y
CONFIG_GENERIC_CLOCKEVENTS=y
CONFIG_GENERIC_TIME=y
CONFIG_GENERIC_CMOS_UPDATE=y
CONFIG_SCHED_OMIT_FRAME_POINTER=y
CONFIG_GENERIC_HARDIRQS_NO__DO_IRQ=y
CONFIG_DMA_NONCOHERENT=y
CONFIG_DMA_NEED_PCI_MAP_STATE=y
CONFIG_EARLY_PRINTK=y
CONFIG_SYS_HAS_EARLY_PRINTK=y
CONFIG_SYS_SUPPORTS_HOTPLUG_CPU=y
CONFIG_I8259=y
CONFIG_GENERIC_ISA_DMA=y
CONFIG_GENERIC_ISA_DMA_SUPPORT_BROKEN=y
CONFIG_CPU_LITTLE_ENDIAN=y
CONFIG_SYS_SUPPORTS_LITTLE_ENDIAN=y
CONFIG_IRQ_CPU=y
CONFIG_BOOT_ELF32=y
CONFIG_MIPS_L1_CACHE_SHIFT=5
CONFIG_CPU_LOONGSON2F=y
CONFIG_CPU_LOONGSON2=y
CONFIG_SYS_HAS_CPU_LOONGSON2F=y
CONFIG_SYS_SUPPORTS_32BIT_KERNEL=y
CONFIG_SYS_SUPPORTS_64BIT_KERNEL=y
CONFIG_CPU_SUPPORTS_32BIT_KERNEL=y
CONFIG_CPU_SUPPORTS_64BIT_KERNEL=y
CONFIG_64BIT=y
CONFIG_PAGE_SIZE_16KB=y
CONFIG_BOARD_SCACHE=y
CONFIG_MIPS_MT_DISABLED=y
CONFIG_CPU_HAS_WB=y
CONFIG_CPU_HAS_SYNC=y
CONFIG_GENERIC_HARDIRQS=y
CONFIG_GENERIC_IRQ_PROBE=y
CONFIG_CPU_SUPPORTS_HIGHMEM=y
CONFIG_SYS_SUPPORTS_HIGHMEM=y
CONFIG_ARCH_FLATMEM_ENABLE=y
CONFIG_ARCH_POPULATES_NODE_MAP=y
CONFIG_SELECT_MEMORY_MODEL=y
CONFIG_FLATMEM_MANUAL=y
CONFIG_FLATMEM=y
CONFIG_FLAT_NODE_MEM_MAP=y
CONFIG_SPARSEMEM_STATIC=y
CONFIG_PAGEFLAGS_EXTENDED=y
CONFIG_SPLIT_PTLOCK_CPUS=4
CONFIG_PHYS_ADDR_T_64BIT=y
CONFIG_ZONE_DMA_FLAG=0
CONFIG_VIRT_TO_BUS=y
CONFIG_HAVE_MLOCK=y
CONFIG_HAVE_MLOCKED_PAGE_BIT=y
CONFIG_DEFAULT_MMAP_MIN_ADDR=4096
CONFIG_TICK_ONESHOT=y
CONFIG_NO_HZ=y
CONFIG_HIGH_RES_TIMERS=y
CONFIG_GENERIC_CLOCKEVENTS_BUILD=y
CONFIG_HZ_1024=y
CONFIG_SYS_SUPPORTS_ARBIT_HZ=y
CONFIG_HZ=1024
CONFIG_PREEMPT=y
CONFIG_SECCOMP=y
CONFIG_LOCKDEP_SUPPORT=y
CONFIG_STACKTRACE_SUPPORT=y
CONFIG_DEFCONFIG_LIST="/lib/modules/$UNAME_RELEASE/.config"
CONFIG_CONSTRUCTORS=y
CONFIG_EXPERIMENTAL=y
CONFIG_BROKEN_ON_SMP=y
CONFIG_LOCK_KERNEL=y
CONFIG_INIT_ENV_ARG_LIMIT=32
CONFIG_LOCALVERSION="-fauli"
CONFIG_HAVE_KERNEL_GZIP=y
CONFIG_HAVE_KERNEL_BZIP2=y
CONFIG_HAVE_KERNEL_LZMA=y
CONFIG_KERNEL_LZMA=y
CONFIG_SWAP=y
CONFIG_SYSVIPC=y
CONFIG_SYSVIPC_SYSCTL=y
CONFIG_POSIX_MQUEUE=y
CONFIG_POSIX_MQUEUE_SYSCTL=y
CONFIG_BSD_PROCESS_ACCT=y
CONFIG_BSD_PROCESS_ACCT_V3=y
CONFIG_TREE_RCU=y
CONFIG_RCU_FANOUT=64
CONFIG_IKCONFIG=y
CONFIG_IKCONFIG_PROC=y
CONFIG_LOG_BUF_SHIFT=15
CONFIG_GROUP_SCHED=y
CONFIG_FAIR_GROUP_SCHED=y
CONFIG_RT_GROUP_SCHED=y
CONFIG_USER_SCHED=y
CONFIG_CGROUPS=y
CONFIG_CGROUP_DEBUG=y
CONFIG_CGROUP_NS=y
CONFIG_CGROUP_FREEZER=y
CONFIG_CGROUP_DEVICE=y
CONFIG_CGROUP_CPUACCT=y
CONFIG_RESOURCE_COUNTERS=y
CONFIG_CGROUP_MEM_RES_CTLR=y
CONFIG_CGROUP_MEM_RES_CTLR_SWAP=y
CONFIG_MM_OWNER=y
CONFIG_RELAY=y
CONFIG_NAMESPACES=y
CONFIG_UTS_NS=y
CONFIG_IPC_NS=y
CONFIG_USER_NS=y
CONFIG_PID_NS=y
CONFIG_NET_NS=y
CONFIG_BLK_DEV_INITRD=y
CONFIG_INITRAMFS_SOURCE=""
CONFIG_RD_GZIP=y
CONFIG_SYSCTL=y
CONFIG_ANON_INODES=y
CONFIG_EMBEDDED=y
CONFIG_SYSCTL_SYSCALL=y
CONFIG_KALLSYMS=y
CONFIG_HOTPLUG=y
CONFIG_PRINTK=y
CONFIG_BUG=y
CONFIG_ELF_CORE=y
CONFIG_PCSPKR_PLATFORM=y
CONFIG_BASE_FULL=y
CONFIG_FUTEX=y
CONFIG_EPOLL=y
CONFIG_SIGNALFD=y
CONFIG_TIMERFD=y
CONFIG_EVENTFD=y
CONFIG_SHMEM=y
CONFIG_AIO=y
CONFIG_VM_EVENT_COUNTERS=y
CONFIG_PCI_QUIRKS=y
CONFIG_COMPAT_BRK=y
CONFIG_SLUB=y
CONFIG_HAVE_OPROFILE=y
CONFIG_HAVE_SYSCALL_WRAPPERS=y
CONFIG_RT_MUTEXES=y
CONFIG_BASE_SMALL=0
CONFIG_MODULES=y
CONFIG_MODULE_FORCE_LOAD=y
CONFIG_MODULE_UNLOAD=y
CONFIG_MODULE_FORCE_UNLOAD=y
CONFIG_MODVERSIONS=y
CONFIG_BLOCK=y
CONFIG_BLOCK_COMPAT=y
CONFIG_IOSCHED_NOOP=y
CONFIG_IOSCHED_CFQ=y
CONFIG_DEFAULT_CFQ=y
CONFIG_DEFAULT_IOSCHED="cfq"
CONFIG_FREEZER=y
CONFIG_HW_HAS_PCI=y
CONFIG_PCI=y
CONFIG_PCI_DOMAINS=y
CONFIG_ISA=y
CONFIG_MMU=y
CONFIG_BINFMT_ELF=y
CONFIG_BINFMT_MISC=y
CONFIG_MIPS32_COMPAT=y
CONFIG_COMPAT=y
CONFIG_SYSVIPC_COMPAT=y
CONFIG_MIPS32_O32=y
CONFIG_MIPS32_N32=y
CONFIG_BINFMT_ELF32=y
CONFIG_ARCH_HIBERNATION_POSSIBLE=y
CONFIG_ARCH_SUSPEND_POSSIBLE=y
CONFIG_PM=y
CONFIG_PM_SLEEP=y
CONFIG_SUSPEND=y
CONFIG_SUSPEND_FREEZER=y
CONFIG_HIBERNATION_NVS=y
CONFIG_HIBERNATION=y
CONFIG_PM_STD_PARTITION="/dev/sda2"
CONFIG_CPU_FREQ=y
CONFIG_CPU_FREQ_TABLE=y
CONFIG_CPU_FREQ_STAT=y
CONFIG_CPU_FREQ_DEFAULT_GOV_ONDEMAND=y
CONFIG_CPU_FREQ_GOV_PERFORMANCE=y
CONFIG_CPU_FREQ_GOV_POWERSAVE=y
CONFIG_CPU_FREQ_GOV_ONDEMAND=y
CONFIG_LOONGSON2F_CPU_FREQ=y
CONFIG_NET=y
CONFIG_PACKET=y
CONFIG_PACKET_MMAP=y
CONFIG_UNIX=y
CONFIG_XFRM=y
CONFIG_XFRM_USER=y
CONFIG_XFRM_IPCOMP=y
CONFIG_NET_KEY=y
CONFIG_INET=y
CONFIG_IP_MULTICAST=y
CONFIG_IP_ADVANCED_ROUTER=y
CONFIG_ASK_IP_FIB_HASH=y
CONFIG_IP_FIB_HASH=y
CONFIG_IP_MULTIPLE_TABLES=y
CONFIG_IP_ROUTE_MULTIPATH=y
CONFIG_INET_AH=y
CONFIG_INET_ESP=y
CONFIG_INET_IPCOMP=y
CONFIG_INET_XFRM_TUNNEL=y
CONFIG_INET_TUNNEL=y
CONFIG_INET_XFRM_MODE_TRANSPORT=y
CONFIG_INET_XFRM_MODE_TUNNEL=y
CONFIG_INET_XFRM_MODE_BEET=y
CONFIG_INET_LRO=y
CONFIG_INET_DIAG=y
CONFIG_INET_TCP_DIAG=y
CONFIG_TCP_CONG_CUBIC=y
CONFIG_DEFAULT_TCP_CONG="cubic"
CONFIG_FIB_RULES=y
CONFIG_WIRELESS=y
CONFIG_CFG80211=y
CONFIG_WIRELESS_OLD_REGULATORY=y
CONFIG_WIRELESS_EXT=y
CONFIG_WIRELESS_EXT_SYSFS=y
CONFIG_LIB80211=y
CONFIG_MAC80211=y
CONFIG_MAC80211_DEFAULT_PS=y
CONFIG_MAC80211_DEFAULT_PS_VALUE=1
CONFIG_MAC80211_RC_PID=y
CONFIG_MAC80211_RC_MINSTREL=y
CONFIG_MAC80211_RC_DEFAULT_PID=y
CONFIG_MAC80211_RC_DEFAULT="pid"
CONFIG_MAC80211_LEDS=y
CONFIG_UEVENT_HELPER_PATH="/sbin/hotplug"
CONFIG_STANDALONE=y
CONFIG_PREVENT_FIRMWARE_BUILD=y
CONFIG_FW_LOADER=m
CONFIG_FIRMWARE_IN_KERNEL=y
CONFIG_EXTRA_FIRMWARE=""
CONFIG_CONNECTOR=y
CONFIG_PROC_EVENTS=y
CONFIG_PNP=y
CONFIG_BLK_DEV=y
CONFIG_BLK_DEV_LOOP=y
CONFIG_BLK_DEV_CRYPTOLOOP=y
CONFIG_BLK_DEV_RAM=y
CONFIG_BLK_DEV_RAM_COUNT=16
CONFIG_BLK_DEV_RAM_SIZE=8192
CONFIG_EEPROM_93CX6=y
CONFIG_HAVE_IDE=y
CONFIG_SCSI=y
CONFIG_SCSI_DMA=y
CONFIG_BLK_DEV_SD=y
CONFIG_BLK_DEV_SR=y
CONFIG_CHR_DEV_SG=y
CONFIG_SCSI_WAIT_SCAN=m
CONFIG_ATA=y
CONFIG_ATA_SFF=y
CONFIG_PATA_AMD=y
CONFIG_NETDEVICES=y
CONFIG_NET_ETHERNET=y
CONFIG_MII=y
CONFIG_NET_PCI=y
CONFIG_8139TOO=y
CONFIG_8139TOO_PIO=y
CONFIG_8139TOO_TUNE_TWISTER=y
CONFIG_WLAN_80211=y
CONFIG_RTL8187B=y
CONFIG_INPUT=y
CONFIG_INPUT_MOUSEDEV=y
CONFIG_INPUT_MOUSEDEV_SCREEN_X=1024
CONFIG_INPUT_MOUSEDEV_SCREEN_Y=768
CONFIG_INPUT_EVDEV=y
CONFIG_INPUT_KEYBOARD=y
CONFIG_KEYBOARD_ATKBD=y
CONFIG_INPUT_MOUSE=y
CONFIG_MOUSE_PS2=y
CONFIG_SERIO=y
CONFIG_SERIO_I8042=y
CONFIG_SERIO_LIBPS2=y
CONFIG_VT=y
CONFIG_CONSOLE_TRANSLATIONS=y
CONFIG_VT_CONSOLE=y
CONFIG_HW_CONSOLE=y
CONFIG_DEVKMEM=y
CONFIG_SERIAL_NONSTANDARD=y
CONFIG_SERIAL_8250=y
CONFIG_SERIAL_8250_CONSOLE=y
CONFIG_SERIAL_8250_PCI=y
CONFIG_SERIAL_8250_PNP=y
CONFIG_SERIAL_8250_NR_UARTS=16
CONFIG_SERIAL_8250_RUNTIME_UARTS=4
CONFIG_SERIAL_8250_EXTENDED=y
CONFIG_SERIAL_8250_MANY_PORTS=y
CONFIG_SERIAL_8250_FOURPORT=m
CONFIG_SERIAL_8250_ACCENT=m
CONFIG_SERIAL_8250_BOCA=m
CONFIG_SERIAL_8250_EXAR_ST16C554=m
CONFIG_SERIAL_8250_HUB6=m
CONFIG_SERIAL_8250_SHARE_IRQ=y
CONFIG_SERIAL_8250_RSA=y
CONFIG_SERIAL_CORE=y
CONFIG_SERIAL_CORE_CONSOLE=y
CONFIG_UNIX98_PTYS=y
CONFIG_LEGACY_PTYS=y
CONFIG_LEGACY_PTY_COUNT=16
CONFIG_HW_RANDOM=y
CONFIG_RTC=y
CONFIG_RAW_DRIVER=m
CONFIG_MAX_RAW_DEVS=256
CONFIG_DEVPORT=y
CONFIG_I2C=y
CONFIG_I2C_BOARDINFO=y
CONFIG_I2C_CHARDEV=y
CONFIG_I2C_HELPER_AUTO=y
CONFIG_HWMON=y
CONFIG_SENSORS_PCF8591=y
CONFIG_THERMAL=y
CONFIG_THERMAL_HWMON=y
CONFIG_SSB_POSSIBLE=y
CONFIG_FB=y
CONFIG_FIRMWARE_EDID=y
CONFIG_FB_CFB_FILLRECT=y
CONFIG_FB_CFB_COPYAREA=y
CONFIG_FB_CFB_IMAGEBLIT=y
CONFIG_FB_MODE_HELPERS=y
CONFIG_FB_SM7XX=y
CONFIG_FB_SM7XX_ACCEL=y
CONFIG_FB_SM7XX_DUALHEAD=y
CONFIG_BACKLIGHT_LCD_SUPPORT=y
CONFIG_BACKLIGHT_CLASS_DEVICE=y
CONFIG_BACKLIGHT_GENERIC=y
CONFIG_DUMMY_CONSOLE=y
CONFIG_FRAMEBUFFER_CONSOLE=y
CONFIG_FRAMEBUFFER_CONSOLE_ROTATION=y
CONFIG_FONT_8x8=y
CONFIG_FONT_8x16=y
CONFIG_LOGO=y
CONFIG_LOGO_LINUX_CLUT224=y
CONFIG_SOUND=y
CONFIG_SND=y
CONFIG_SND_TIMER=y
CONFIG_SND_PCM=y
CONFIG_SND_HRTIMER=y
CONFIG_SND_VERBOSE_PROCFS=y
CONFIG_SND_VMASTER=y
CONFIG_SND_AC97_CODEC=y
CONFIG_SND_DRIVERS=y
CONFIG_SND_AC97_POWER_SAVE=y
CONFIG_SND_AC97_POWER_SAVE_DEFAULT=10
CONFIG_SND_PCI=y
CONFIG_SND_CS5535AUDIO=y
CONFIG_AC97_BUS=y
CONFIG_HID_SUPPORT=y
CONFIG_HID=y
CONFIG_USB_HID=y
CONFIG_USB_HIDDEV=y
CONFIG_USB_SUPPORT=y
CONFIG_USB_ARCH_HAS_HCD=y
CONFIG_USB_ARCH_HAS_OHCI=y
CONFIG_USB_ARCH_HAS_EHCI=y
CONFIG_USB=y
CONFIG_USB_ANNOUNCE_NEW_DEVICES=y
CONFIG_USB_DEVICEFS=y
CONFIG_USB_SUSPEND=y
CONFIG_USB_EHCI_HCD=y
CONFIG_USB_EHCI_ROOT_HUB_TT=y
CONFIG_USB_OHCI_HCD=m
CONFIG_USB_OHCI_LITTLE_ENDIAN=y
CONFIG_USB_UHCI_HCD=m
CONFIG_USB_STORAGE=y
CONFIG_MMC=m
CONFIG_MMC_BLOCK=m
CONFIG_MMC_BLOCK_BOUNCE=y
CONFIG_NEW_LEDS=y
CONFIG_LEDS_TRIGGERS=y
CONFIG_LOONGSON_PLATFORM_DEVICES=y
CONFIG_EC_KB3310B=y
CONFIG_EXT2_FS=m
CONFIG_EXT3_FS=y
CONFIG_EXT3_DEFAULTS_TO_ORDERED=y
CONFIG_EXT3_FS_XATTR=y
CONFIG_EXT3_FS_POSIX_ACL=y
CONFIG_EXT3_FS_SECURITY=y
CONFIG_EXT4_FS=y
CONFIG_EXT4_FS_XATTR=y
CONFIG_EXT4_FS_POSIX_ACL=y
CONFIG_JBD=y
CONFIG_JBD2=y
CONFIG_FS_MBCACHE=y
CONFIG_FS_POSIX_ACL=y
CONFIG_FILE_LOCKING=y
CONFIG_FSNOTIFY=y
CONFIG_DNOTIFY=y
CONFIG_INOTIFY=y
CONFIG_INOTIFY_USER=y
CONFIG_FAT_FS=m
CONFIG_VFAT_FS=m
CONFIG_FAT_DEFAULT_CODEPAGE=437
CONFIG_FAT_DEFAULT_IOCHARSET="utf8"
CONFIG_NTFS_FS=m
CONFIG_NTFS_RW=y
CONFIG_PROC_FS=y
CONFIG_PROC_KCORE=y
CONFIG_PROC_SYSCTL=y
CONFIG_PROC_PAGE_MONITOR=y
CONFIG_SYSFS=y
CONFIG_TMPFS=y
CONFIG_CONFIGFS_FS=m
CONFIG_NETWORK_FILESYSTEMS=y
CONFIG_CIFS=m
CONFIG_CIFS_XATTR=y
CONFIG_CIFS_POSIX=y
CONFIG_MSDOS_PARTITION=y
CONFIG_NLS=y
CONFIG_NLS_DEFAULT="iso8859-1"
CONFIG_NLS_CODEPAGE_437=y
CONFIG_NLS_CODEPAGE_850=y
CONFIG_NLS_ISO8859_1=y
CONFIG_NLS_ISO8859_15=y
CONFIG_NLS_UTF8=y
CONFIG_TRACE_IRQFLAGS_SUPPORT=y
CONFIG_FRAME_WARN=1024
CONFIG_TRACING_SUPPORT=y
CONFIG_HAVE_ARCH_KGDB=y
CONFIG_CMDLINE=""
CONFIG_CRYPTO=y
CONFIG_CRYPTO_ALGAPI=y
CONFIG_CRYPTO_ALGAPI2=y
CONFIG_CRYPTO_AEAD=y
CONFIG_CRYPTO_AEAD2=y
CONFIG_CRYPTO_BLKCIPHER=y
CONFIG_CRYPTO_BLKCIPHER2=y
CONFIG_CRYPTO_HASH=y
CONFIG_CRYPTO_HASH2=y
CONFIG_CRYPTO_RNG2=y
CONFIG_CRYPTO_PCOMP=y
CONFIG_CRYPTO_MANAGER=y
CONFIG_CRYPTO_MANAGER2=y
CONFIG_CRYPTO_WORKQUEUE=y
CONFIG_CRYPTO_AUTHENC=y
CONFIG_CRYPTO_CBC=y
CONFIG_CRYPTO_ECB=y
CONFIG_CRYPTO_HMAC=y
CONFIG_CRYPTO_CRC32C=m
CONFIG_CRYPTO_MD5=y
CONFIG_CRYPTO_SHA1=y
CONFIG_CRYPTO_AES=y
CONFIG_CRYPTO_ARC4=y
CONFIG_CRYPTO_DES=y
CONFIG_CRYPTO_DEFLATE=y
CONFIG_BITREVERSE=y
CONFIG_GENERIC_FIND_LAST_BIT=y
CONFIG_CRC_CCITT=m
CONFIG_CRC16=y
CONFIG_CRC_ITU_T=m
CONFIG_CRC32=y
CONFIG_LIBCRC32C=m
CONFIG_ZLIB_INFLATE=y
CONFIG_ZLIB_DEFLATE=y
CONFIG_DECOMPRESS_GZIP=y
CONFIG_HAS_IOMEM=y
CONFIG_HAS_IOPORT=y
CONFIG_HAS_DMA=y
CONFIG_NLATTR=y

Every one of us dumb workhorses called architecture developers has its own way of scripting all the commands necessary to stabilise/test a package on its architecture, but I would like to describe how I do it, for the curious. The bug list of the architecture (x86 in my case) with all keywording and stabilisation requests is the starting point here.

Normally I install the packages in a chroot and I follow the never-uninstall-a-package policy to catch file collisions, while others keep the system lean to find missing dependencies (they probably use the buildpkg feature of Portage to keep compile times for dependencies down). To put all needed packages in the package.keywords file, I use the Gentoo Arch Testing Tool (app-portage/gatt) which does that automatically. Compile test includes up to three runs: With all USE flags enabled, then all disabled and then finally what make.conf and the profile defines. The last iteration is then tested, either by starting the program and using it for some time (games usually get a longer testing period) or by building packages that depend upon the package to be stabilised. I have a little script that extracts that information from the tinderbox' rindex and determines which package is in stable and needs to be rebuilt. Manual work includes a short glance if USE flags are needed to activate the support for that package. Installing as most depending packages as possible makes sure all reverse dependencies still build, this sometimes leads to other stabilisation requests or bug reports blocking the stabilisation of the initial package.

After everything went successfully I tell Gatt to create a script in the /tmp/ directory which is shared with my main system. From there I call that script which is quite capable and there is an extensive manual for it.

That's how your package hits stable on x86 usually. Big things like KDE or Gnome are handled differently, the script is shorter:

• Install it with the package list provided by the team (normally that's the case)
• Test it
• Keyword all packages and add ChangeLog entries (without commit)
• Run QA checks with repoman over the whole category
• Run commit with --force to disable QA checks to speed up process (it still takes hours for KDE)

Before the netbook-boom called 'mini notebook', Lemote now promotes it as netbook (what it really is). The specialty of that little thing is the hardware: Not an Intel Atom or some AMD CPU, but a 900Mhz Mips chip. Honestly, after my disaster with something ARM-based (NSLU2, it still is bricked and will never be revived I think), I wanted something more end-user friendly and the Lemote is just that. Equipped with a full-fledged desktop installation (the Debian mipsel variant) it allows installing Gentoo with few problems. Chrooting and installing the stage tarball from Zhang Le gets you off quite fast. The provided kernel did not boot, but Le gave me a newer one, which worked just fine after creating some missing device files (console, tty* and pty*, see man mknod). Meanwhile I have compiled my own kernel and the system just runs with LXDE...so finally a possibility to have the third Gtk-based destop installed. Gnome on sol (the big iron desktop), Xfce on the main lappy (called terra) and LXDE now on mars. Performance is good, for surfing and mailing it is more than sufficient, compile times are ok (even GNU Emacs runs), but the battery is way too small (1.5 hours only, but a peak of 14W consumption, while having 12W during normal surf sessions).

The Loongson processor seems to me as the future of the Gentoo Mips port. Supporting the old SGI machines is nice but they will eventually die out, while Lemote actively works on new machines and supports Linux as its main platform (they don't have any other choice apart from the BSDs anyway). Ordering is really simple: Either use Lemote directly (and handle all customs yourself), use KD85 (what I did, really pleasing experience, shipped from Belgium) or Tekmote from the Netherlands.

Zhang Le (r0bertz) and Stuart Longland (redhatter) wrote enough about the Loongson processor and the Gentoo support in various entries on their blogs, so I won't go into more details.

Gentoo-quebec is a project which aims to meet people around gentoo stuffs.
At the origin it was created on 1st December 2007 per 5 guys

-Laurent Duchesne
-Sylvain Alain
-Patrick Blanchard
-Éric Langlois
-Mathieu Bouchard

Providing great documentations as PDF format (generated using LaTeX ) and excellents wiki howtos pages, this is the right place to share and learn experiences.

There is also an useful and powerful forum for our community, to get feedbacks and ask all your questions, don't worry admins didn't forget an english section .

Actually I help them when I've time enough, my areas of responsability are mostly fix or write articles in the wiki, and share my experiences (and learn too) on the forum.

Gentoo-quebec always search great users with good gentoo skills, or developer who want to share their knowledges (like zmedico with portage, thanks to him).

so because you finished to read this entry don't wait and join gentoo-quebec !

Well… after much building by one of the older Lemote systems, I finally have a Gentoo desktop with KDE 4.3.0 on the Lemote Yeeloong.

I’m still working on the rest of the KDE suite… and will have to track down the necessary bits and pieces for battery monitoring and other goodies… but it seems everything is working. It also is slightly more responsive on Gentoo than Debian (which I still have in a chroot).

This post is being written in Konqueror 4.3.0 on the said installation… it passes the Acid 2 test, but has a few stability glitches here and there… so far both the Acid 3 test, and Google Groups crashes it. I’ll sort this out later.

In short, this does mean I’ll be coaxing my O2 into making the same journey and making the necessary tree modifications in order to allow KDE 4.3 on Gentoo/MIPS.

I always thought that writting documentation is much more difficult than coding. This is because, writting documenation and guides, is kinda boring(?), requires a lot of our free time and it is not as fun as coding. All of these arguments IMHO are true but is documentation really needed?

During my six month Gentoo journey I faced a common problem: “I want to write a python/gnome/qt ebuild. How on earth am I suppose to do it??”

Looking through Gentoo docs I ‘ve found some guides about writting games and python ebuilds. Maybe there are more, I haven’t checked. Those guides are quite handy for anybody who wants to write a quick ebuild without making serious mistakes.

Eclasses usage is another tricky thing. Based on my experiense, I believe that the most difficult part is to understand how they work and when they should be used on an ebuild. E.g., a Qt4 ebuild doesn’t always require to inherit qt4 eclass because it might wants cmake functions to build and install. In this case, despite the fact that it is a pure Qt4 package, you need to inherit the cmake-utils eclass. That was a simple example but I believe you got the point

This blog post is a kind request to all fellow developers,  to make some time and write proper ebuild guides ( and keep them updated based according to eclasses’ latest changes ) for the sake of developers and users. People tend to believe that ebuild writting is quite hard because of all the e-* functions ( wrappers ) and ebuild  phases. Prove them wrong

ps: A Qt4 ebuild guide, can be found here

Nothing fancy in this podcast just an update about what has been going on in my Linux World. I am now a member of the Gentoo PR Project as a staff member. What this means is that I am not a developer for Gentoo, just a staff member to help out with Gentoo. The first thing I did was put together a page for the Gentoo 10 year anniversary, yes Gentoo is celebrating a birthday. I am going to be talking about a lot of different links, so instead of saying all of them during this podcast, if there are any topics you would like more info or a clearer explanation, please visit linuxcrazy.com for all the links

LINKS:
My Gentoo PR site
http://gentoo-pr.org/
Gentoo Anniversary page
http://www.gentoo.org/news/20090722-anniversary.xml
Screenshot contest
http://www.gentoo.org/proj/en/pr/2009-screenshot-contest.xml
Screenshot Contestants
http://gentoo-pr.org/node/6
http://gentoo-pr.org/node/7
http://gentoo-pr.org/node/9
Contest Forum Post
http://forums.gentoo.org/viewtopic-t-780092-highlight-.html
Gentoo GuideXML
http://www.gentoo.org/doc/en/xml-guide.xml
Robin H. Johnson (robbat2) interview
http://www.gentoo.org/proj/en/pr/20090724-robbat2-interview.xml
Perl 5.10 testing
http://pythontoo.com/?q=node/22
Bash
Advanced Bash-Scripting Guide
http://tldp.org/LDP/abs/html/
Gentoo Development Guide
Tools Reference
http://devmanual.gentoo.org/tools-reference/index.html
Linux Command Line and Shell Scripting Bible
http://www.amazon.com/Linux-Command-Shell-Scripting-Bible/dp/047025128X/...
Touch Typing
GNU Typist
http://www.gnu.org/software/gtypist/#TOCdocumentation
Klavaro
http://klavaro.sourceforge.net/en/index.html
Three typing tutors and a boy
http://www.linux.com/archive/feature/146602
PulseAudio
http://forums.gentoo.org/viewtopic-t-789181-highlight-.html

irc network freenode channel #linuxcrazy

Download

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

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!

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.