Gentoo Logo
Gentoo Logo Side
Gentoo Spaceship

Contributors:
. Alec Warner
. Alex Alexander
. Alex Legler
. Alexis Ballier
. Andreas Proschofsky
. Andrew Gaffney
. Arun Raghavan
. Ben de Groot
. Bernard Cafarelli
. Bjarke Istrup Pedersen
. Brent Baude
. Caleb Tennis
. Christian Faulhammer
. Christian Zoffoli
. Damien Krotkine
. Daniel Drake
. Daniel Gryniewicz
. Daniel Ostrow
. David Abbott
. David Shakaryan
. Davide Italiano
. Denis Dupeyron
. Diego E. Pettenò
. Donnie Berkholz
. Doug Goldstein
. Gentoo Haskell Herd
. Gentoo News
. Gilles Dartiguelongue
. Greg KH
. Gunnar Wrobel
. Gustavo Felisberto
. Hanno Böck
. Hans de Graaff
. Ioannis Aslanidis
. Jan Kundrát
. Jeffrey Gardner
. Jeremy Olexa
. Joe Peterson
. Jonathan Smith
. Jorge Manuel B. S. Vicetto
. Joseph Jezak
. Josh Saddler
. José Alberto Suárez López
. Kenneth Prugh
. Krzysiek Pawlik
. Lance Albertson
. Luca Barbato
. Luis Francisco Araujo
. Marcus Hanwell
. Mark Kowarsky
. Mark Loeser
. Markos Chandras
. Markus Ullmann
. Mart Raudsepp
. Matthias Geerdsen
. Michael Marineau
. Michal Januszewski
. Mike Doty
. Mike Pagano
. Nathan Zachary
. Ned Ludd
. Nirbheek Chauhan
. Olivier Crête
. Patrick Kursawe
. Patrick Lauer
. Patrick McLean
. Paul de Vrieze
. Peter Weller
. Petteri Räty
. Pieter Van den Abeele
. Piotr Jaroszyński
. Remi Cardona
. Renat Lumpau
. Rob Cakebread
. Robert Buchholz
. Robin Johnson
. Romain Perier
. Ryan Hill
. Sebastian Pipping
. Serkan Kaba
. Shyam Mani
. Steev Klimaszewski
. Stefan Schweizer
. Steve Dibb
. Stuart Longland
. Sune Kloppenborg Jeppesen
. Sven Wegener
. Thilo Bangert
. Thomas Anderson
. Timothy Redaelli
. Tiziano Müller
. Tobias Klausmann
. Tobias Scherbaum
. Yuval Yaari
. Zack Medico
. Zhang Le

Last updated:
September 09, 2009, 23:04 UTC

Disclaimer:
Views expressed in the content published here do not necessarily represent the views of Gentoo Linux or the Gentoo Foundation.


Bugs? Comments? Suggestions? Contact us: planet@gentoo.org

Powered by:
Planet Venus

Welcome to Gentoo Universe, an aggregation of weblog articles on all topics written by Gentoo developers. For a more refined aggregation of Gentoo-related topics only, you might be interested in Planet Gentoo.

September 09, 2009
Greg KH a.k.a. gregkh (homepage, stats, bugs)
Staging tree status for the .32 kernel merge (September 09, 2009, 21:48 UTC)

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.

Bernard Cafarelli a.k.a. voyageur (homepage, stats, bugs)
neatx and chromium in portage status updates (September 09, 2009, 12:05 UTC)

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.

Diego E. Pettenò a.k.a. flameeyes (homepage, stats, bugs)
Proper dependencies aren't overcomplex (September 09, 2009, 11:12 UTC)

It seems like somebody read my previous post about using Gentoo for building embedded-system filesystems as a mission that would increase the complexity of the work for Gentoo, and would waste time for no god reason. And if you look at the post, I do call that bullshit, for a good reason: proper dependencies are not going to increase complexity of either ebuilds nor the work needed by the packager, they are only extensions to the standard procedure.

Let’s take, as example, the zlib package: it’s part of the system set and some people say that this is enough to ignore adding it to the dependencies. Why? Well that’s a very good question: most of the times the reason I’ve been given was to avoid cyclic dependencies, but given zlib has no dependencies itself… Instead, what do we gain, if we actually add it to all the packages that do use it, you have proper reverse-dependency information, which can be used for instance by a much more sophisticated tinderbox to identify which packages need to be rebuilt when one changes.

At the same time, the correct depgraph will be used by Portage to properly order zlib before any other package that do use it is merged; this is quite useful when you broke your system and you need to rebuild everything. And it’s not all, the idea is that you only need to specify dependencies on system packages only for other packages possibly in the system set; the problem is: how can you be certain you’re not in the system set? If you start to consider that pambase can bring gnome in the system set, it’s not really easy, and it’s a moving target as well.

So I beg to differ regarding complexity: if you simply follow the rule if it uses foo, it depends on foo the complexity will be reduced over time rather than increased: you don’t have to check whether foo and your package are in system set or not. The only two packages that QA approves of not depending upon are the C library and the compiler: all the rest has to be depended upon properly.

And in respect of the already-noted bug with distutils eclass: the same problem exists for other eclasses like apache, webapp and java, that would add their own dependencies by default… but have an explicit way to disable the dependencies and the code or tie them to an USE flag. You know, that is not complexity; that is a properly-designed eclass.

Dante e.V. mit neuer Homepage (September 09, 2009, 10:32 UTC)

Nach so vielen Jahren mit dem alten Desing, gibt es jetzt endlich ein schönes Layout, dass den modernen Zeiten besser steht. Dante ist die Deutschsprachige Anwendervereinigung TeX und widmet sich der Förderung rund um das Textsatzsystem TeX

texmfind, finally updated (September 09, 2009, 08:12 UTC)

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.

September 08, 2009
Alex Alexander a.k.a. wired (homepage, stats, bugs)

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.

share this post: Digg del.icio.us Google Bookmarks Identi.ca Slashdot Facebook Twitter

Nathan Zachary a.k.a. nathanzachary (homepage, stats, bugs)
I wish (September 08, 2009, 19:55 UTC)

I wish...

the justice system would actually promote, foster, and protect virtue instead of corruption; that the systems and safeguards the nation has in place would function based on the spirit of the law instead of the bureaucratic letter of the law; that our lives were not governed by the myth of meritocracy, but rather that those most deserving would obtain, instead of being shunned by a modus operandi desperately trying to placate the proprietors of wealth and subsequent power that they do not readily deserve; that we would eradicate not only the lexeme of "toleration," but also the surrounding mentality, and instead replace it with a disposition of love and understanding; that we as members of humanity could unanimously realise the tyranny of the "compete and conquer" mindset, replacing it with a "collaborate and coalesce" worldview; that we would sustain Carpenter's "Bless the Beasts and Children" notion, helping those incapable of promoting their own eudaemonia, and that when doing so, we were not falsely accused of wicked, despicable, and self-serving motives, especially by the hypocrites engaging in such deploration;

I wish...

...that this dreadfully painful contention which I'm currently enduring would result in, if nothing else, this beautiful child's recognition that somebody loves him above all else.

|:| Zach |:|

Diego E. Pettenò a.k.a. flameeyes (homepage, stats, bugs)
Preparing a router; improving Gentoo (September 08, 2009, 06:34 UTC)

I’m finally working on setting up my home gateway with a Gentoo-based system, as I wrote about some time ago, since I didn’t find anything that looked even barely like what I wanted, off the shelf.

But since the router is going to be working on CF flash drives, I’m also using some tricks to get it up, and this is binging me to find even more problems within Gentoo, but that’s as usual and to be expected, isn’t it?

The first problem is that I don’t want to have superfluous stuff in the router: Portage (I don’t want to live update it), Perl, Python, autotools, other build-related tools, all that stuff should not be there at all. So the obvious is to buil dup my own profile to reduce the system set. This is actually quite boring and a problem in my opinion. Given the stage3 is system itself, to have autotools in the stages (which we do want) we need to have them in system… but they shouldn’t be.

The second problem is that not having either Portage nor autotools in the final system means that the dependencies over Python and Perl of the rest of the packages need to be perfect_: no more and no less. Unfortunately sys-apps/file depends on Python unconditionallybug.cgi?id=284051 and util-linux installs a Perl script without depending on it (or having a perl USE flag). If the runtime dependencies are not properly expressed, my router won’t work as intended and that’s going t make me sad, depressed, and probably very angry with those who don’t express dependencies fully. And C++ dependencies will also be a problem.

I’ll be posting some tips and tricks soonish, for now I’m still working on defining what should I add to my router, and how. In particular I’ve been able to do stuff like enabling graphite n the GCC used for building, but not enabling it on the gcc needed on the system, so that it won’t bring in ppl and cloog-ppl, in a quite decent fashion.

Again, being able to prepare this kind of systems programmatically needs more work than just a few tricks and a lot of fighting so you probably will read more about this, and find more bugs about this in the future.

And as a bottom-line: since this is working mostly on stable tree, I also noticed that a few packages that should have been stable already weren’t… so I started opening a few stable requests for my packages; I really need to find a way to make sure they don’t excessively slack off…

Nathan Zachary a.k.a. nathanzachary (homepage, stats, bugs)
Microsoft and Best Buy work together to spread FUD (September 08, 2009, 03:43 UTC)

I found this very interesting article about Best Buy's training program. The RetailAccess program (sponsored by Intel) and the ExpertZone training program (sponsored by Microsoft) provide readings about the newly-released and upcoming technologies. Every employee at the tech bench (now called the Geek Squad) had to read these articles and take quizzes over their content in order to keep their jobs. Interestingly, a new article in ExpertZone compared Windows with Linux. However, instead of an objective comparison, Microsoft continued their trend of spreading fear, uncertainty, and doubt (FUD) in a desperate attempt to maintain their market share. Some of the flat-out lies that they mentioned were 1) that Linux doesn't support cameras, or portable media devices very well, 2) that we don't have any way to play Windows-based games, and 3) that video chat isn't possible. There were many more, including my personal favourite that Linux is too difficult to learn.

Don't take my word for it though, check out the full article by Steven Vaugh-Nichols of Computer World, complete with screenshots of the "quizzes."

|:| Zach |:|

September 07, 2009
Knitting and Gentoo (September 07, 2009, 19:00 UTC)

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.

Diego E. Pettenò a.k.a. flameeyes (homepage, stats, bugs)
Tokenizing in Ragel (September 07, 2009, 11:36 UTC)

For feng I’m currently working toward getting the parser(s) rewritten using Ragel the state machine generator. Using Ragel for the parsers usually means having a much faster conversion from the RFC822-based RTSP protocol to something that the program can access and understand directly.

One of the interesting things that I’ve been working on, though, is proper tokenisation of the protocol, for instance converting an header name into an enumerated type. The reason why that’s a problem is that it’s not really straightforward to produce, with Ragel, a state machine that can parse a string into an enumerated code, and still discern between invalid and unsupported values; and this in particular is important for us because we have to either ignore or give a 400-response (bad request) depending on that.

The first obvious way to define a token is this one:

MyToken = "FOO" % { token  = MyTokenFoo; } |
    "BAR" % { token = MyTokenBar; } |
    [A-Z]{3};

This works, but does not distinguish extremely well between invalid and unsupported; yes of course you can check in the code whether the parser reached the first final, but it can be made, in my opinion, more solid by setting the validity at the end of the last transition as well; unfortunately code like the following:

MyToken = "FOO" % { token  = MyTokenFoo; } |
    "BAR" % { token = MyTokenBar; } |
    [A-Z]{3} % { token = MyTokenUnsupported };

Will always hit the unsupported case, because the general rule is a superset of the rest of the rules. To solve this problem, you should use priorities, which are documented in the Ragel documentation, but not really explained. In this case, we must give the priority to entering in a given state so that the known token beat the general token; one way to do that is using this:

MyToken = "FOO" > 2 % { token  = MyTokenFoo; } |
    "BAR" > 2 % { token = MyTokenBar; } |
    [A-Z]{3} > 1 % { token = MyTokenUnsupported };

Higher priority means that the state will be considered before the others and the first one wins. Unfortunately this can mess up when you have multiple state machines, since you risk conflicts between priorities. To solve this, you can use named priorities:

MyToken = "FOO" > (mytoken, 2) % { token  = MyTokenFoo; } |
    "BAR" > (mytoken, 2) % { token = MyTokenBar; } |
    [A-Z]{3} > (mytoken, 1) % { token = MyTokenUnsupported };

At that point the states can have priority one over the other only inside the same namespace. And this solves the parser completely; just make sure your variable is set by default to Invalid, and don’t forget to make sure that you still got to make sure that the parser reached the correct final state.

September 06, 2009
Marcus Hanwell a.k.a. cryos (homepage, stats, bugs)
What a Crazy August (September 06, 2009, 18:36 UTC)

August was without doubt one of the craziest months in the last few years. It started off with the normal "getting used to being a new Dad" type of stuff. Then as we were thinking about our upcoming trip to find a new house our car started acting funny. Long story short it was not good, and we made the decision to get a new one. We should have probably done that in the first place, hindsight is always a great thing...

So we had some fun and games as we picked out a new car, checked our already stretched summer finances and finally took delivery of a shiny Subaru Forester on Wednesday 5 August. It immediately produced some awful, loud static noise as we drove it home from the showroom. By Friday they had given us a courtesy car while they figured out what was wrong. Friday night they had it back to us with a new audio system installed.

Subaru ForesterAir and Space Smithsonian

Then we figured it would be great to catch up with Adam in Washington DC, and to iron out any further car bugs before our house hunting trip. So 8-9 August we stayed with Adam and checked out the Air and Space Museum. We also took William to the White House, and a few other touristy spots. He won't remember it, but he got to see the capital, along with lots of rockets, planes and satellites.

Family outside the WhitehouseWilliam in hospital

On Monday I went back into work, left a little early and William was making some strange noises. When we got home I felt his head, and it was really hot. As Louise was getting the thermometer William was sick for the first time ever - all over me. When I checked his temperature it was up at 39.8C, in excess of 103F (checked with two thermometers). This scared us so we rushed him to the children's hospital, as any nervous first time parent would.

As they were looking at him we started to realise that it might be quite serious. They ran a battery of tests, including urine and blood tests, cultures, X-rays, spinal fluid and constant vitals. They found a bacterial infection, I have never been so scared and stressed before. I found out that I am a very protective father, and was disheartened as more and more tests came in and we were admitted for an extended stay.

All of our friends were out of town at the time too, which made things more difficult. It turned out he had an E. Coli infection in his blood. We were lucky in some senses, the antibiotic they started him on as we were admitted was one of the best for the strain of E. Coli he had been infected with. His blood only showed bacteria in the first culture they took. Still, they were talking about 14 days on IV antibiotics using a central line as an inpatient.

Thankfully after talking with them they found an alternative oral antibiotic therapy that recent studies showed were just as effective. So he could come home on the Thursday evening. It was great to be home again, although very stressful to have William get so ill so quickly. I had never imagined he could get so ill so quickly, it reminded me off the waiting for them to tell us he was OK after he was born.

After that we tried to get back to life as normal. Until the end of the month when we had our big trip up to Clifton Park, NY to look for houses. Friday went very badly, we saw one house which was terrible and everything else we had lined up had been rented before we got into town. Saturday we saw another house before leaving for Boston - it was OK, but not really what we were looking for.

William's first wedding

Saturday afternoon we drove over to Boston, MA to go to Jeff's wedding. It was great to have a break from looking at houses. We had a great time looking around Cambridge and Boston, the wedding was really nice and William managed to get lots of attention. Thanks for inviting us Jeff - it was a really nice day. William's first formal event. Before leaving on Sunday we visited the Harpoon brewery to sample some of their beers.

We found several new places listed on Sunday before leaving Boston, so we set up appointments for Monday. Monday was something of a three bears type of day. The first house we saw was close to work, but too small. The second house we saw was about the right size, good state of repair but a little expensive and too far from work. The third place we saw advertised as we were thinking about how to compromise, saw it at 6:30pm and it was just right.

William relaxing in the hotelNew house

So in the end we didn't have to extend our stay, found a nice place that is close to where I will work and Louise really likes it. We just had a 500 mile drive back home. That was pretty much August, I did manage to squeeze some time in for hacking on code, taking care of the cluster at work, and general work stuff. September we just need to do our first 500 mile interstate move. It should be relatively simple after an intercontinental move surely ;-)

September 05, 2009
Diego E. Pettenò a.k.a. flameeyes (homepage, stats, bugs)
The Ruby packager blues (September 05, 2009, 21:32 UTC)

Okay after ranting and implementing it’s time for crying. Because this whole day of work depressed me in a way that I wouldn’t have expected to be possible for Free Software.

Indeed, even though I added support for using the gems as base for the installation of packages in Gentoo, this does not solve one of my most important issues: tests that weren’t run and that’s bothering me.

It bothers me because for instance, running gruff’s tests, I found two bugs that are now in github (but not yet merged in the original master). It bothers me because it would take very little extra steps to get the things working properly, and nobody follows it.

If I started listing all the problems I found and I needed to cope with or workaround, I’d probably be feeling even more depressed. So I’ll just try to repeat some of the rules-of-thumb that you should follow:

  • please try to provide tgz as well as gems: while even Gentoo can deal with gems at this point, it still requires a double-extraction;
  • provide the tests and the framework to run them; without those, it’s difficult to understand whether the code works as intended or not;
  • always good, but especially if you don’t release the tgz: tag your releases! This allows to go look at eventually missing files (in tgz or gem) for executing tests, or to look for further changes that might have fixed things; if you use github, providing proper tags also provides automatic tarball downloads, so you don’t have to do anything else than provide the gem and tags;
  • try your own tests before releasing so that you’ll avoid releasing code that does not pass the tests in the first place; this is true also when the bugs are in the testsuite rather than in the code logic.

Unfortunately, the more I try to package software for Ruby, the more I see that these rules are blatantly ignored and people just release out whatever crap works for them. I’m seriously surprised that this stuff can be used in production, most of the times!

And if you feel like my work is worth something, and you’d like to say “thank you”, you can always look at my wishlist which also has useful technical elements; for instance I’d really like to read that OpenMP book so that I could learn some new tricks for making software behave better with multicore systems.

More on Ruby, JRuby and Gems. (September 05, 2009, 17:49 UTC)

Okay, after my previous rant about ruby I’ve decided to get to work and try to fix at least part of the problems. The first was getting rmagick, and thus gruff, to work on Ruby 1.9. The solution, obviously, was to use ruby-ng.eclass. And this brought me at extending it further.

The good new is that now ruby-fakegem.eclass can unpack gems! This means that we have an almost total coverage: software not available in tarballs can be fetched and unpacked as gem and then installed with a fake gem. This does not seem to comply with what Hans wanted, but gives us enough space for improvement in the future. This also means I can finally package a few more extensions that I had to ignore before, like hoe for instance.

I also wanted to package an updated version of jruby-openssl (and looking at the downloads I also noticed there’s a rmagick compatible package for JRuby there, I’ll have to look at it so maybe I can do all the work in a single pass with JRuby itself); the new versions actually come in tarball as well as gems (the tarball is still preferred, it’s one step less after all). Unfortunately it turns out that both the gem and the tarball are missing the Rakefile for the tests (which makes it quite impossible to get the tests running). It also comes with two bundled jar for dev-java/bcprov and dev-java/bcmail, but that’s for another moment.

But to test the git version of jruby-openssl (spoiler: it still does not work!), I ended up having to package hoe, and from that rubyforge, which was a stopping bucked before, as it doesn’t come in tarball form… which is no longer a problem! Unfortunately the testsuite of hoe (oh did I say that the gems installed this way can run test and don’t install them any longer? oh yeah it’s sweet!) broke, seems like for an internal error in ruby 1.9 itself!

/usr/bin/ruby19 -w -Ilib:ext:bin:test -e 'require "rubygems"; require "test/unit"; require "test/test_hoe.rb"' 
Loaded suite -e
Started
....
Finished in 0.172264 seconds.

4 tests, 34 assertions, 0 failures, 0 errors, 0 skips
/usr/lib64/ruby19/1.9.1/pathname.rb:270: warning: `*' interpreted as argument prefix
rake aborted!
Command failed with status (1): [/usr/bin/ruby19 -w -Ilib:ext:bin:test -e '...]

(The pathname warning is what is causing the error further down the road).

So while this is no real improvement for my job task; this is actually a good improvement for Gentoo and Ruby; now if my fellow devs wouldn’t mind helping me polishing out the eclasses and testing the overlay then we might even get this in the tree one day so that all users could make use of the new shiny support for Ruby 1.8, Ruby 1.9 and JRuby at once.

The following step would probably be supporting even other Ruby implementations, has anybody said Ruby EE, Rubinius or IronRuby? (Indeed it’s theoretically possible to support all of those as well, as far as I can tell, as long as they are commandline-compatible with the original Ruby).

Something is fundamentally wrong with Ruby (September 05, 2009, 13:54 UTC)

Okay, here I am ranting once again about Ruby. And yes, I do rant a lot about Ruby even though I like the language a lot; my beef is usually (and in this case as well) about the various implementations.

For one of my job tasks right now I have to parse some CSV file and produce a series of graphs; while any language would work just as fine to produce this kind of graphs, I wanted to use Ruby because that’s my usual language of choice, and it also provides all the needed interfaces and libraries I needed, or so I thought. Reality smacked me down hard.

First problem: the speed. I know already that Ruby processing isn’t exactly fast; luckily there’s JRuby to solve that, usually. With the exception of the startup overhead, JRuby can process data much faster, and thus would be the candidate of choice for producing some less rough cut of the data, so my first choice was to use JRuby to read and condition the input. I had, though, the bad idea of wanting to try fastercsv to read the data, which as the name suggest should be faster (given it’s going to handle over 20MB of raw data, it seemed like a good idea)… an ebuild (using ruby-ng of course) later, I discover that the testsuite of the library fails under JRuby (I guess I should report it but I’m not sure to who).

Okay, second choice: Ruby 1.9, which is faster than 1.8 in many ways, and includes fastercvs bundled in the standard library. At that point, I thought I could also draw the graphs directly in Ruby, with gruff, which works quite nicely. Unfortunately gruff requires rmagick, which is not ported to Ruby 1.9 at least in Gentoo (the ebuild is probably too complex to write supporting both with the current infastructure; maybe porting to ruby-ng works, but I’ll have to find more time to try that as well).

Finally, I’m left with Ruby 1.8 that could do what I want but I’m sure will be the slowest option out there, and I’m not sure I want to try it. I really hope that Hans and Alex can find time to help me validating the new ebuilds, so that we can actually move to use those, maybe that will give enough support for Ruby 1.9, and for JRuby, and we could finally get to have a single implementation with all the feature people are going to need (speed and library support).

September 03, 2009
Diego E. Pettenò a.k.a. flameeyes (homepage, stats, bugs)
Testsuites are important, once again. (September 03, 2009, 14:32 UTC)

I start sincerely to get tired about this, but here it comes: testsuites are important to know whether a package is good or not; so the package you’re developing should have a testsuite. And the ebuild you’re writing should execute it. And you should run it!

This is something I noticed first in the tinderbox, but some people even complained about that directly to me: a lot of ebuilds make a mess with testsuites. The problems with them range from not running them at all and restricting without really good reasons, to testsuites that are blatantly broken because they were never tested before.

I guess the first problem here is the fact that while the test feature that executes the actual testuites is disabled by default, Portage provides a default src_test. Why is this a problem, you say? After all, it really does add some value when the testsuite is present, even if the maintainer in the ebuild didn’t spend some extra minutes writing it down. Unfortunately, while it adds test phases to lots of ebuilds where they are correctly executed, it also adds them to packages that don’t have testsuites at all (but, if they use automake, it’ll still run a long make chain, recursive if the build system wasn’t built properly!), to packages that have different meanings for the check or test targets (like all the qmail-related packages, for which make check checks the installation paths and not the just-built software), and to packages whose testsuite is not only going to fail, but also to hog a computer down for a pretty long time (did somebody say qemu?).

Now, the problems with tests does not stop here with the default src_test, otherwise it would also be pretty easy to fix; the problem is that we don’t really have a clear policy on how to deal with the testsuites, especially those that fails. And I have to say that I’m as bad as the rest of the group when it comes to deal with the testsuites. I can, first thing, bring up two packages I deal with that have problems with their testsuites.

  • PulseAudio, which is a pretty important package, you’d say, has a complex testsuite; for quite a long time in the test releases (that in Gentoo become RCs even though they really are not, but that’s another issue here) one of the tests (mix_test) failed, because the test itself wasn’t being updated to support the new sample format, this was only fixed recently (there were other tests failure, but those I fixed myself at the first chance); on the other hand, the tests for the translations, that are also part of the package’s testsuite, are still not executed: the current version of intltool (0.40) does not interpret correctly the configure.ac file (it parses it like it was a text file, rather than accepting that it’s a macro file), and causes the test to fail in a bad way; the solution for this part is to package and add a dependency over intltool 0.41, but seems like nobody is sure whether that’s an official release or a development release. For now, only the software tests are executed;
  • speaking of docbook the XSL stylesheet for Docbook used to have a complex testsuite that checked that the output was what it was supposed to be; now they weren’t really comprehensive and indeed at least one bug was missed by the testsuite in the whole 1.74 series. Starting from 1.75 the new testsuite should probably be tighter and support more than just one XSLT engine… the problem is that upstream doesn’t seem to have described the testing procedure anywhere, and I haven’t figured out how it works yet, with the result that the testsuite is now restricted in the ebuilds (with a test USE flag that is not masked, I already filed an enhancement request for Portage to handle this case).

At this point what I’m brought to wonder is: how harsh should we be on the packages with flawed, broken, or incomplete testsuites? Should they be kept in package.mask? Should they not reach stable? The stable-stopper for this kind of problems used to be Ferris, and it’s one reason I’m really going to miss him badly. On the other hand it seems like a few other arch team members started applying the same strictness, which I don’t dislike at all (although it’s now keeping libtool-2.2 from going stable, and with that PulseAudio as well). But what about the packages that already fail in stable? What about the packages failing because of mistakes in the testsuites?

There are also arch-specific issues, for instance I remember some time ago Linux-PAM requiring a newer glibc than it was available on some arches for its testsuite to proceed correctly… the running logic of PAM, though, seemed to work fine beside the test. What should have been the correct approach? Make the whole of Linux-PAM depend on the new glibc, making it unusable by some arches, or just the tests? I decided for the tests, because the new version was really needed, but on a pure policy point of view I’m not sure if it was the right step.

I guess the only thing I can add here is, once again, if you need to restrict or skip tests, keep the bug open, so that people will know that the problem has only been worked around and not properly fixed. And maintainers, always remember to run the testsuites of your packages when bumping, patching or otherwise changing your packages. Please!

Nokia doesn’t get it (September 03, 2009, 14:03 UTC)

Okay, I'm no longer cautiously optimistic about the N900.  I've officially crossed it off my list, and any claims that Nokians make about the N900 being an actual open source platform are patently false.

This reminded me of bug #176  opened in 2005 (yes, 4 years and 4.5 hardware iterations ago): The N900 still does not have native ogg support.  This means to me that Nokia deliberately removed that support.  They must have; all the underlying software (gstreamer, etc) has it by default.

If the N900 was, in fact, an open source project, ogg support would have been added by the community.  Heck, I looked at adding it myself back in the day.  But it's not there, therefore the N900 is not open source.   Oh well.  There's always the N910, that's sure to come out in 6 months.  Maybe Nokia will have gotten their act together by then.

Diego E. Pettenò a.k.a. flameeyes (homepage, stats, bugs)

Strangely enough this post is not brought but something that happened recently (I usually write in response of stuff that happens), but it’s a generic indication that I’ve had to explain to too many people in the past. The most recent thing that might link to my writing this is my note about Pidgin crashing more on Fedora and a little discussion on the matter with a friend of mine.

So, we all know compiler optimisation flags in Gentoo, and most users trying some exotic ones probably know that a lot of ebuilds tend to filter, strip or otherwise reduce the number of flags actually used at build time. This is, in many cases, a violation of Gentoo policies, and Mark being both QA and Toolchain master usually get upset by them. Since this is often abused I’d like to explain here what the problem is.

First of all, not all compiler flags are the same: there are flags that change behaviour of the source code, and others that should not change that behaviour. For instance the -ffast-math flag enables some more loose mathematical rules, this change the behaviour of the math source code as it’s no longer perfect; on the other hand the -ftree-vectorize only changes the output code and not the meaning of the source code, and should then be counted in as a safe flag.

You can see already the gist here: -ftree-vectorize has been called for build and runtime errors in the past few years, so it’s often not considered safe at all and indeed it’s often considered one of the less safe flags. But there are a few catches here: the first is that yes, the implementation of the flag might be at fault, and in the past it caused quite a few internal compiler errors, or miscompilation of source code into something that fails at runtime. But both these issues has to be reported to the GCC developers to be fixed because they are bug in GCC to begin with, so if the issue is just ignored by disabling the flag, they won’t be fixed any time soon.

Sometimes, though, the issues are neither a problem of miscompilation nor a bug in GCC, yet the package fails to execute properly or fails to build entirely; the latter happened with mplayer not too long ago. In these cases there’s still a bug, and it’s in the software itself, and needs to be fixed. In the case of mplayer for instance it has shown that the inline assembler code was using global labels rather than local lables like it should have been in the first place. Fixing the code wasn’t that hard, compared with the flag’s filtering.

Now, don’t get me wrong, I know there are at least a few issues with the approach I just noted: the first is that as the FFmpeg developers found out, -ftree-vectorize is not often a good idea, and can actually produce slower code on most systems, at least for the common multimedia usage methods. The second problem is that, with the exception of the mplayer bug, most of the build and runtime failures aren’t straightforward to fix; and when the problem is in GCC, it might take quite a while before the issue is fixed; how should we work those situations out then, if not by filtering?

Well, filtering works fine as a temporary option, a workaround, a band-aid to hide the problem from users. So indeed we should use filtering; on the other hand, this is a problem akin to those related to parallel make or --as-needed: you should not let the user be bitten by the problem, but at the same time you should accept that you haven’t fixed the bug just yet. My indication is thus keep the bug open if you “solved” it by filtering flags!

I know lots of developers dislike having bugs open at all, but it’s not really fixed if you just applied a workaround. And if you close it, nobody will ever see it again, and this will result in a phantom bug that will take a much longer time to reproduce, verify, and fix properly. This is for instance the problem when I hit a package that, without any comment in either ebuild or change log, has a strip-flags call, which reduces the amount of flags passed to the compiler: finding whether the call is there because of a reported bug, or just because the Gentoo developer involved couldn’t be bothered by following the policy, requires time.

And finally, users please understand that the flags like -ffast-math or -fvisibility that do change the meaning of the source code should not be used by users but should rather be applied directly by upstream if they are safe!

September 02, 2009
g-CTAN has made...nearly (September 02, 2009, 16:47 UTC)

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.

Diego E. Pettenò a.k.a. flameeyes (homepage, stats, bugs)
Fedora, good and bad (September 02, 2009, 15:11 UTC)

In the past few days, since I’ve been spending time at my sister’s house, I’ve used as single system the laptop I bought a few months ago, with runs Fedora 11. This has been my first time, since I started working in Gentoo, that I had to work with just a laptop (if you exclude the hospitalisations) and especially the first time since I started using Gentoo that I had to work with just another Linux distribution.

Indeed, with the already noted exceptions, the last time I had to work with just a laptop was when Defiant (the box I had before Enterprise) died and I had to replace it (with Enterprise); at the time I was limited at working with the iBook G4 and, I think, Tiger (or Panther, I don’t remember to be honest). Luckily the work that I had to do at the time (translating Ian Sommerville’s Software Engineering 7th Edition to Italian) didn’t require me much more and it worked out quite fine with just that laptop.

But still, up to a few months ago all my laptops has been Apple and mostly using Mac OS X (even though I had Gentoo installed in both for a time). Now instead I have a laptop running Fedora; I have also to say that since I started using Gentoo, any other distribution has just been something to try out but never something used on a daily basis, up to now at least.

Now I have to say, I’m not really feeling extremely out of place in Fedora either. The system works mostly well although there are a few things that, I think, Gentoo gets better. The most obvious one is the gstreamer plugins: they are not split at all, they are a single package for each source tarball; this means that if you need, for instance, the plugin to play aac files, you also have to get the one that plays sid files, and that in turn requires you to install the libsidplay library. I guess the USE flag concept here works much better.

Almost all software that I need is one of the repositories, either the official ones or RPM fusion with the exception of the libdvdcss library that has to be found on ATrpms . Even Emacs 23 is now available on the updates, and that makes it much much nicer to use Fedora as development box for me: I cannot stand the graphical interface in Emacs 22.

Interestingly enough, Random mode works here with Rhythmbox, I have to check whether it was fixed upstream and thus fixed in Gentoo as well. It still does not seem to check the “skip when playing random” flag that iTunes add to the files, but I guess either I or someone else can fix that up one day (so that I wouldn’t get BBC Radio shows to play when I’m expecting music!). I also had the pleasure to see that connecting my iPod to the laptop, Rhythmbox is able to play the music from it like it was an external hard drive (using the tags without having to copy and rename the files), which has come very useful to play my music without having to use the earphones.

Connectivity hasn’t been an enormous issue, although it wasn’t a cakewalk either: at least in Fedora 11, NetworkManager does not support Bluetooth DUN (Dial-Up Networking) which means that I cannot use my phone over bluetooth (which would have allowed to leave the phone upstairs, where H3G network is reachable, and move the laptop downstairs), but I have to use the provided cable. This was of course after I updated enough packages so that they didn’t segfault on me while trying to configure the connection. By the way, I have to find out who “owns” the list of providers’ data: the Italian H3G options are only valid for the consumer-side, not the business-side that I use.

The one thing that actually upset me quite a bit, though, was related to the Mono development tools handling in Fedora: while the mono package comes with the mcs compiler, it doesn’t bring in all the development tools. And, at the same time, MonoDevelop does not depend on the mono-devel package with the remaining tools. I installed most of that stuff before coming here (because I didn’t want to use too much traffic from my almost-flatrate), but when I imported an external project into my main one (the vCard library I might have to hack on) it failed to rebuild the project because it was lacking the resource compiler. This really sounds strange to me!

Also, Pidgin here seems to crash much more than on Gentoo (and there goes the theory that Gentoo’s CFLAGS handling makes software crash). And I’m not even using OTR! And the keypad toggle button didn’t work by default, I had to use xbindkeys and a custom script calling synclient (upon Eva’s suggestions) to make it work, and I needed it badly because writing a long text minding the touchpad is quite hard; if anybody wish to send me something useful, order for me an Apple bluetooth keyboard, with US layout, and you’ll make me quite happy, and more productive as well!

All in all, it doesn’t look too bad, although it could use some extra polishing I guess; I’ll see how it goes with Fedora 12, once it’s released (given it’s now in Alpha it shouldn’t be too long). Unfortunately, the one thing that I was hoping for in 11 (the nouveau driver for nVidia cards) didn’t really work here…

Steve Dibb a.k.a. beandog (homepage, stats, bugs)
gmail smtp + custom from email address (September 02, 2009, 13:03 UTC)

Oh, man, I just solved a problem that has been horribly hounding me *for a year now*, and I just had to write about it.

At work, we use Microsoft Exchange for our email, which doesn't really bother me that much.  I'm not the calendaring / scheduling / whatever fool that cares about all the advanced crap, I just want to be able to send and receive email.  I don't get a lot here at work, and I send less, but when I do it's always a painful experience.  The reason is because I haven't been able to get anything on my Linux desktop (I've been using Gentoo as my workstation OS for about 6 years now, all at different jobs, nyah!) to actually send mail out on the Exchange server, and I've tried everything.  I can get mail just fine using POP3 or IMAP, but no SMTP love.

Anyway, I won't go through what I tried to get working, because it didn't work, and who cares anyway.  What does work is using GMail to provide an external SMTP service.  Now, the problem I anticipated, and what it does, is it munges the From: email address to force it to your GMail account name.  I wanted it the email to look like me@workinghard.com though.  What I didn't know until today is you can set that up.

Just open up the GMail interface, click on the Settings link then the "Accounts and Import" tab.  There's a section labeled "Send mail as".  Just take it from there.  Add another account, and it will verify that you have access to the one you are wanting to send it from.  Then, when you setup your email client (Thunderbird, in my case) to send through gmail's SMTP server (smtp.gmail.com), and you send from me@workinghard.com, your From address will no longer be munged.  Success!

Oh man, I'm so glad I don't have to battle with Exchange any more.  Or the web interface.  Or my dedicated Windows box I use mostly for Outlook.  *wave of relief* :)

Alex Alexander a.k.a. wired (homepage, stats, bugs)
kde 4.3.1 released, in gentoo (September 02, 2009, 12:42 UTC)

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

share this post: Digg del.icio.us Google Bookmarks Identi.ca Slashdot Facebook Twitter

Diego E. Pettenò a.k.a. flameeyes (homepage, stats, bugs)
Why moderated comments can be a problem (September 02, 2009, 12:10 UTC)

You might know already that I don’t like moderating comments; I did for a long time because of spam, but nowadays I prefer filtering comments out with mod_security based on User-Agent and other diagnostics. One of the reasons why I don’t like moderated comments is that, often times, comments can correct a wrong blog post and make it not extremely bad.

I don’t pretend I’m extremely good at what I do and that I never make mistakes; I’m sure I do, but if I say something very stupid, usually somebody corrects me on the comments, and the post still keep a value. When I see posts about people reinventing the wheel, and making it hexagonal for some reason (like reinventing grep --include -r with a script using find and a for loop), and find out that the comments are moderated, then I’m usually appalled. First, because lots of users that don’t know better will read the post and apply what it says without thinking twice about it. Second, because in the comments, that appeared in a batch right away, beside a number of duplicate suggestions, there has been even more suggestions in a number of polygons, but just a couple of really round wheels. You probably know what I’m referring to if you follow some of the planets out there, I don’t really want to name names here.

Today, another example of moderated comments that hinder clearing up a blog post that isn’t really proper. When you rant about a software or a feature, especially when you explicitly say you don’t understand why it does what it does, leaving open comments allows for people to actually solve the mystery for you; if you moderate it, you’re probably wasting time of more than one person who has the answer, since they’ll probably try to explain it when they see no comments present already.

Sigh.

September 01, 2009
Steve Dibb a.k.a. beandog (homepage, stats, bugs)
three ways to install alsa drivers (September 01, 2009, 16:18 UTC)

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

alsa 1.0.21 released (September 01, 2009, 13:33 UTC)

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.

August 31, 2009
Jan Kundrát a.k.a. jkt (homepage, stats, bugs)
Introducing Trojitá, a Qt IMAP e-mail client (August 31, 2009, 21:14 UTC)

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: A screenshot of Trojitá, a Qt IMAP e-mail client

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.

Steve Dibb a.k.a. beandog (homepage, stats, bugs)
disney + marvel (August 31, 2009, 16:07 UTC)

Oh, man.  Sucktitude.

From the PR, "This transaction combines Marvel’s strong global brand and world-renowned library of characters ... with Disney’s creative skills ..."  That's what worries me.

Makes sense, though.  I was actually surprised that Marvel wasn't bought out sooner by a big studio, considering that DC was purchased by Warner Bros. a while ago, who have, IMO, done a marvelous job of putting out really good content.

I would have expected them to go with Fox though (who produced the X-Men movies) instead of Disney.  Oh well.  Another interesting legacy is going to be flushed down the toilet.

Although, I wouldn't mind seeing a Mickey Mouse vs. Magneto game.

Jeremy Olexa a.k.a. darkside (homepage, stats, bugs)
Gentoo Prefix/Windows (August 31, 2009, 16:03 UTC)

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)

Peter Weller a.k.a. welp (homepage, stats, bugs)
eBooks vs. Real Books (August 31, 2009, 12:03 UTC)

As I mentioned in my last blog post, I do enjoy my reading, even though it does come at a cost (which I do tend to complain about…). A number of my friends have suggested getting an eBook reader and getting my books in a digital format, which is quite often cheaper. There are a number of benefits to eBooks:

  • Portability – Ever wanted to take your entire book collection on holiday with you? eBooks make it possible! (Okay, perhaps not quite depending on memory restrictions, but eBooks are definitely more portable than their paper counterparts).
  • Searching – Obviously, with academic texts this can be a great boon, but I find it very rare that I attempt to search for a particular word or phrase in a novel of some form.
  • Backlighting – To the best of my knowledge, modern e-Ink eBook readers do not have backlighting available, and so are only readable in the same conditions as regular paper. I could be wrong here, so please feel free to correct me!
  • Price – If you’re going to quote monetary savings as a reason to get an eBook reader, I’m probably going to ignore you. eBooks are generally only £1-2 cheaper than their paper counterparts (in the UK, at least), and Amazon often offer bigger discounts on their real books.
  • DRM – If you’re a publisher, this might be a good thing. But I think a lot of people would quite like to be able to lend books to their friends and family without having to worry about DRM restrictions and so on… Paper books are so easy to lend, you just hand the book on to someone else. How do you lend someone an eBook?

I can see why eBook readers would definitely be an ideal solution for reading and distributing academic texts, but I really can’t see the benefits (at this moment in time) over “real” books. I also quite like to be able to flick through books, jump back and forth, quickly refer to something on the previous page (without having to wait for the lengthy “refresh” on e-Ink eBook readers) and various other things like that…

Oh! One more thing! I love good cover art. I know I’m not supposed to, but I often do judge a book by its cover…

Nathan Zachary a.k.a. kalos (homepage, stats, bugs)
Kindle...the future of book burning (August 31, 2009, 03:55 UTC)

Amazon's Kindle is appropriately named, as to kindle means to "catch fire" or to "cause to start burning" (Wordnet 3.0, n.d.). The newest generation of Kindle products support the downloading of books without even having a computer connection, allowing the consumer to get a new book "anytime, anywhere" (Amazon.com: Kindle, 2009). At first glance, this type of technology seems to offer the consumer amazing freedom, flexibility, and opportunity. Coupled with this convenience, however, is the ability of Amazon to control what one reads, censor materials, violate a user's privacy, and even attempt to circumvent their own Terms of Service and renege on the customer's "non-exclusive right to keep a permanent copy of the applicable Digital Content and to view, use, and display such Digital Content an unlimited number of times, solely on the Device or as authorized by Amazon as part of the Service and solely for your personal, non-commercial use" (Amazon Kindle: License Agreement and Terms of Use, 2009).

In June and July of 2009, Amazon.com removed a few titles (including Rand's The Fountainhead, and Orwell's 1984) from their Kindle Store, citing a seemingly noble cause of attempting to protect the intellectual property of the publishers (Manjoo, 2009). Though this action may be a disappointment to consumers wishing to purchase the respective eBooks, the removal of these titles is not, in itself, unethical, illegal, or cause for any type of alarm. However, Amazon.com took their supposed pursuit of nobility a step further and wirelessly connected to their customers' Kindle devices and removed their already-purchased copies of said titles. Not only did this action break their Terms of Service mentioned above, but it also brought digital censorship to a daunting new level.

Before digital copies of books, physical copies could be sold without any method of recovery. To clarify, when one purchases a book from a store (assuming cash is used instead of a cheque or credit card), there is no method for the vendor to attain information about that individual's identity, including his or her whereabouts. This means that if the book is recalled, banned by a government, or goes out of print the publishers, vendors, and law enforcement authorities have no hope in retrieving previously-sold copies of the book without the individual's consent. Thus, the individual would have complete ownership of the copy, and could do with it what he or she wills. Further, this lack of circulation tracking means that it is very likely that a printed copy of a work will exist somewhere in the world, even after publication has ceased. With Amazon's ability to track, modify, and even remove titles from Kindle devices, this 'complete removal from circulation' security is no longer present. In theory, a book that is distributed solely in electronic form could be tracked and completely eradicated from existence! What seemed at first to be a lovely convenience can also be seen as a surveillance tactic and, worse yet, a totalitarian approach to censorship.

Fortunately, one has other choices than just Amazon's Kindle for an eReader, including the Sony PRS-600BC Touch Edition. This reader does not offer the user wireless downloads of books, and does require a computer to transfer the eBooks to the device. While at first this may seem like an inconvenience, it also promotes more security for the consumer's purchased property. To ensure that Sony cannot remove a purchased title requires a couple steps that might not be readily apparent. Firstly, one downloads the desired title from the internet, whether from Sony's official store, or from another vendor. Secondly, one disconnects the internet connection (either by putting the wired or wireless interface down, or by physically disconnecting the ethernet cable, router, or modem). Thirdly, one then transfers the title to the eBook reader device. In this fashion, the reader device is never connected to a medium (like the internet) which will allow for the manufacturer to modify or remove the previously-purchased content.

If one runs an operating system (e.g. Windows) on which the manufacturer can install proprietary software, then there is always the possibility that said software can run when the user connects the reader device to the computer. To circumvent such possibilities, one can either connect the reader device to a computer with an operating system that does not support the manufacturer's proprietary software (usually Linux will do the trick here), or better yet, one can boot into a live environment on CD, completely eliminating the chance of the software loading and subsequently running. Tutorials on using LiveCDs can be found all over the internet, and the process is quite simple.

Should Amazon be allowed to modify or delete a customer's content, or even have access to a listing of what one purchases? Is it their right as the distributor of the electronic titles, or are they violating the users' privacy, and encouraging a digital reenactment of the censorship that was book-burning in Hitler's Germany?

--N. Zachary

__________________
REFERENCES:

Amazon.com: Kindle: Amazon's Wireless Reading Device (Latest Generation): Kindle Store (2009). Retrieved August 30, 2009, from http://www.amazon.com/Kindle-Amazons-Wireless-Reading-Generation/dp/B00154JDAI/ref=amb_link_85181491_2?pf_rd_m=ATVPDKIKX0DER&pf_rd_s=center-1&pf_rd_r=1SRH81QG6XRTP3PPX092&pf_rd_t=101&pf_rd_p=489513211&pf_rd_i=507846.

Amazon Kindle: License Agreement and Terms of Use (2009). Retrieved August 30, 2009 from http://www.amazon.com/gp/help/customer/display.html?nodeId=200144530.

Manjoo, F. (2009, July 20). Why 2024 will be like nineteen eighty-four: How Amazon's remote deletion of e-books from the Kindle paves the way for book-banning's digital future. Slate. Retrieved August 30, 2009, from http://www.slate.com/id/2223214/.

Wordnet 3.0 (n.d.). Retrieved August 30, 2009, from http://wordnetweb.princeton.edu/perl/webwn?s=kindle.

August 30, 2009
Nathan Zachary a.k.a. kalos (homepage, stats, bugs)
Arch Linux server maintenance page (August 30, 2009, 01:35 UTC)

You may look at the title and wonder why I didn't post this topic under "Computers" or even the "Linux" subtopic. My reasoning is that this isn't really any type of discussion relating to computers, but rather just an image that I found to be priceless. Instead of just making their "server down for maintenance" page bland, they chose to use this image to sum it up. When I saw it, I thought that I was at Denny's getting ready to order by the "point-to-the-image" method. :-D

Click for full size:
Arch Linux maintenance page

|:| Zach |:|

August 29, 2009
N900 (August 29, 2009, 13:36 UTC)

There's been a lot of chatter on the planets about the N900.  I have to admit, I've been very blah about Maemo for the past 6 months or so, despite having a 770 and a n810.   And it's related to why I'm not exceptionally exited about the n900.  I'll get to that.

You see, I was hugely excited about the 770.  It was a great little device, and I bought it as soon as it was available.  I skipped the n800, because it wasn't any improvement for my uses, and because I was pissed that Nokia had EOL'd my 770 after about a year.  But, I was seduced by the hardware keyboard, daylight-visible screen, and extreme prettiness of the n810 to ignore my misgiving about Nokia, and get one.  Again, early adopter.  And the n810 is a fabulous device: well made, very useful, etc.

However, I noticed trend.  Bugs for Maemo on the n810 got ignore, or closed "fixed in freemantle".   Features and development for the n810 (and n800) stopped. Everything added was not backwards compatible.  Barely a year into my n810 ownership, and Nokia was already quietly EOLing it.  Now, it sits in my car and acts as a GPS.

So, on to the n900.  The hardware looks awesome.  The software, ditto.  I'm extremely excited about it as a device.  But I can't bring myself to actually care about it, because twice now, Nokia has screwed me.  Come on guys:  for a $400 - $500 device, you have to support it longer than a year!  3-4 minimum!

So, I'm not excited about the n900.  I can't afford to be burned again.   I'll stick with my Android phones for now.

August 28, 2009
Nathan Zachary a.k.a. kalos (homepage, stats, bugs)
My podcast on LinuxCrazy (August 28, 2009, 17:28 UTC)

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

Tech support (August 28, 2009, 03:41 UTC)

Hello all,

A friend of mine sent me this really funny video yesterday. For all of us "computer nerds," this should put some things in perspective.

Monk Tech Support:


If for some reason the embedded player above doesn't work for you, here's a link to it on YouTube:
http://www.youtube.com/watch?v=0z84F1fHABw

|:| Zach |:|

August 27, 2009

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.

David Abbott a.k.a. dabbott (homepage, stats, bugs)

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

ogg

mp3

Nathan Zachary a.k.a. kalos (homepage, stats, bugs)
Quotes update (August 27, 2009, 03:54 UTC)

I just wanted to make a quick note (nothing urgent at all) that I have updated my random quotes database with about 20 new quotations. I hope you enjoy them, and come back to visit often to see new ones. :-)

|:| Zach |:|

August 26, 2009
RIP, nemesis (August 26, 2009, 23:48 UTC)

Nemesis, my main fileserver/webserver/dhcp/etc. just bit the big one.  Bad, too: no response to the power button.  The power supply is probably okay, because several LEDs on the motherboard light up, but no fan spin, no HD spin up.

Yay.

So, I get to try to replace it.  Temporarily, I'm going to try to put the drives in my desktop (thanatos), and re-purpose it.  But that's not a long term solution, since I need thanatos to be my desktop.

One possibility is to buy a new desktop.  I'm planning on getting a new gaming machine when Diablo 3 comes out anyway, so maybe I should buy it early.  However, with no ETA for Diablo 3, I can get much more machine by waiting.  Then, too, I'm not done with Fallout 3, and the DLC isn't even out yet for the PS3, and I have to go back and finish InFamous at some point, so I probably won't have time for Diablo 3 any time soon anyway.  So buying a new desktop is probably out.

Another possibility is to just replace nemesis with the cheapest setup I can find.   That's certainly quick, and easy.  Another possibility, which I've been considering for a while, is to get a NAS.  Some of them are quite nice, and I'm too old to enjoy administering a box anymore.  I've also read some good things about some of them.  I guess some serious pricing of options is in order...

Of course, my decision may be made for me if something happened to the drives in the crash of nemesis.  There may be no point in trying to build a quick-and-easy replacement.  Time to find out I guess.

Patrick Lauer a.k.a. bonsaikitten (homepage, stats, bugs)
Funtoo Halucinations (August 26, 2009, 11:03 UTC)

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.

August 25, 2009
Steve Dibb a.k.a. beandog (homepage, stats, bugs)
common alsa issues (August 25, 2009, 17:18 UTC)

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.

Linux Mint, logos and wallpapers (August 25, 2009, 07:03 UTC)

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.

August 24, 2009
Hanno Böck a.k.a. hanno (homepage, stats, bugs)
Trip to the UK (August 24, 2009, 13:45 UTC)

I'm currently in Scottland on a trip through the UK. I'm trying to get some contacts to the much more active environmental movement here. For those who don't know, the UK has probably the most active climate movement in the world. I just came from a gathering in the Lake District and now I want to visit a protest site against open cast coal mining in Mainshill.

Afterwards I'll visit the Climate Camp.

It's quite interesting to see discussions here. The main topics at the moment are the third runway at the heathrow airport (see e. g. Plane Stupid) and the building of a new coal plant in Kingsnorth (done by the german company e-on). I heared quotes like »we shouldn't wait till they build the new plant, they're burning coal every day in the existing ones«, which is a large difference compared to the discussion in germany.

August 23, 2009
Stuart Longland a.k.a. redhatter (homepage, stats, bugs)
Progress Update (August 23, 2009, 09:39 UTC)

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.

August 21, 2009
Patrick Lauer a.k.a. bonsaikitten (homepage, stats, bugs)
FROSCON (August 21, 2009, 09:48 UTC)

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

August 20, 2009
Steve Dibb a.k.a. beandog (homepage, stats, bugs)
tromping around mythvideo code again (August 20, 2009, 17:11 UTC)

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

More on the Yeeloong including kernel config (August 20, 2009, 13:41 UTC)

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

Architecture work the way I do it (August 20, 2009, 11:00 UTC)

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)

August 19, 2009
Writer’s Community and Store (August 19, 2009, 22:41 UTC)

My friend the reporter (who still has a job this week...) was visiting today, and we were talking about the newspaper industry, and how reporters everywhere are getting laid off.  In fact, my "home town" newspaper (the Ann Arbor News)  recently folded, fired their reporters, and became some kind of online monstrosity (named after my city with "dot com" on the end; I won't give them Google Juice by listing the name) that does nothing interesting with news, and dumps printed ads (not news or content, mind you, just ads) on my lawn all the time.  They're basically paper spammers... Anyway, we were talking, and it occurred to me that there is probably a fairly large set of out-of-work writers at the moment.  People with lots of skill, and love of writing.  What we need is a business model to take advantage of that to make everyone involved a bit of money.  What model should this be,  I wonder?Here's my idea: iTunes for ebooks, but done right.

See, ebook readers are becoming good right about now, and Kindle has shown that they can even become popular.  And people are buying iPhone and Android apps for a buck or two right and left.  What if we could come up with a way to get these writers to be able to write good content, and get that content to consumers, all at low enough overhead that you could charge a buck?  What I want is two things:  A community and a ratings system.  It works like this.

There's a community for writers, where they can collaborate on, edit, comment on, rate, and so on each other's work.  The community provides appropriate licenses (in collaboration with Creative Commons, probably), and hosting, and forums, and mailing lists, and all the snazzy web 2.0 things that fan-fic sites have.   The community also provides, and here's the important part, a store.

The store would support Kindle, Sony's reader, Plastic Logic's reader, at least one decent iPhone app, at least one decent Android app, at least one decent Pre app, and at least one decent blackberry app.  Probably a Windows Mobile app too, but that's a pain.  Buyers would be able to rate things, tag things, and link things.  Each book would link to the authors community page, so that people could follow and interact with their favorite authors.  Authors, subjects, tags, and so on, should have feeds that you can follow: blog-like, twitter like, and so on.  Integration with other services (such as twitter, facebook, myspace, and so on) would be a plus.Prices should be low; $.50 - $1.

The idea is to encourage people to buy.  Overhead should be low: 5-10%, maybe.  Some works could (and probably would) be given away, as teasers or other incentives.  There should be no DRM; it wouldn't help, and isn't really necessary.The point of the store/community should be convenience: get things for your device easily and cheaply, support people providing your content, and get good content our the deal.

The point of this whole thing is to make an opportunity out of the failure of the newspaper industry: we have a surplus of talented, professional, skilled writers, who need money.  We also have the beginnings of devices that make reading ebooks a good experience.  Let's put them together, and allow the fans to help pay for the works of the writers.

Kenneth Prugh a.k.a. ken69267 (homepage, stats, bugs)
The terminal based email client clobbering (August 19, 2009, 01:11 UTC)

So I recently have been trying out the various different terminal based emails clients to see if any of them were suitable to my needs. Sadly I have to report that I have yet to find one that does everything I need of it.

The first client I tried was alpine. I have to say setting up the program and using it was really easy. Adding accounts was a snap and it was decently performing. Sorting into threads was a bit slow but I suspect that was gmails fault. However, alpine falls short in showing me if I have new emails in folders other than the main Inbox or the folder I have open. I didn’t find a quick at a glance type view listing all the folders and an unread count next to them. Bummer, I really need this. I can’t simply open every folder to check if there’s new mail as some of them are very large and take a long time to open. Alpine gets brownie points for being able to use vim as an editor by default, but looks like I need to keep looking.

The next client I tried was cone. Cone seemed very familiar to alpine and was slightly easier to set up and get going, but lacked as many configuration options that alpine had. I also have to say the colorscheme it chose on my urxvt terminal wasn’t exactly pleasing to the eye, but bearable. I was extremely pleased that cone’s folder list did list unread message counts and did almost everything I asked of it. I could even use vim in the place of leaf if I wanted. The wall I hit, however, is deal breaking. It’s not even particularly cone’s fault but from google’s refusal to follow IMAP standards. As such, I cannot mark emails as read when using cone on my gmail IMAP account. Shame, this is all that I found on the net about it. I figured if I could just get cone to fire off \Send when it should have been marked read by gmail anyway would work but I just can’t quite grasp the internals of cone. Sigh. I tried to hack cone’s sourcecode to implement sending UID STORE +FLAGS \Seen but couldn’t get it working. The functions weren’t documented and my knowledge of C was lacking so I was just clobbering things together. I gave up after it would open a message and simply segfault.

Next I attempted to try mutt. Mutt seems overly complicated for my needs and I don’t think it would play very nice with over 5 IMAP accounts. It’s configuration is a nightmare and I gave up after barely just getting one account functioning.

So for now I’m still using Claws-Mail which is the best graphical client I’ve tried so far. There are times when I don’t have access to a graphical display , however, and wanted a nice email client in a terminal which is why I started this search. Would also be handy as I could ssh in from anywhere and read email with a terminal email client.

Now that I’ve wasted half a day stabbing email clients I suppose I should start reading my unread email :/

August 18, 2009
New toy...the Lemote Yeeloong netbook (August 18, 2009, 20:39 UTC)

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.