Gentoo Universe

Raúl Porcel: Autobuilds

Raúl Porcel (armin76) — Tue, 24 Nov 2009 14:50:46 +0000

Hi,

Just wanted to let everyone know about the status on the autobuilds. As you probably know, Gentoo now offers autobuilt stage3s and installcd’s, that means you’ll always have recent stuff to start your Gentoo installation. Those are built automatically in some cases, and some other cases are built manually(as in needing someone to tell it to build them).

I did this page some time ago, so the people asking about when the builds get done could have an answer: http://dev.gentoo.org/~armin76/releng.xml.

I know i’m a bit repetitive, but I still want to offer armv6/armv7 stages, which as i said on the previous blogpost, we’re unable to provide due to lack of reliable hardware. I’ll write about ARMv7 on another blogpost

As you can see in the link, we have pretty much all the arches covered except m68k and mips, along with the bsd’s.
We don’t have hardware for m68k, and the autobuilds for mips and bsds are up to the respective teams. It would be nice to have mips stages, as the current ones are from 2006 and you have some serious issues upgrading them… I could help with an O2 i got from work, but it came with a 2GB SCSI hdd, and i ran out of space. I have some SCSI disks, but they aren’t SCA, which it looks like the O2 needs.

Have fun

Diego E. Pettenò: More tinderbox notes, just to say

Diego E. Pettenò (flameeyes) — Tue, 24 Nov 2009 12:51:31 +0000

To complete the topic I started with the previous post I would like to give you some more notes about the way the tinderbox work, and in particular about the manual fiddling I have to do on it to make sure that it works smooth; and the issues that haven’t been tackled yet.

As I said the tinderbox is a Linux Container; this helps isolating the test environment from my workstation: killall and other unbound arguments are never going to hit my system, which is good. On the other hand, this still have a couple of rough patches to go through. Even with the latest (unreleased) version of lxc, /dev is either statically created or bound: udev does not work properly inside the container, for somewhat obvious reasons. The problem of that is that if you bind the /dev directory (or mount devtmpfs that is basically the same thing with a recent kernel), then you’ll have only one directory were FIFOs and sockets are created.

This not only causes sysvinit to shut down the host instead than the container if you use the shutdown command, but also makes it impossible to have a running, working syslog from within the container. While this shouldn’t hinder the tinderbox work, but seems like it does .

Another problem is with something all users have to fight with every time: incompatible language updates: Python, Perl, OCaml, Haskel, you name it. Almost all of these languages come with an “updater” script that is intended to rebuild their extensions and libraries to make sure that they are again compatible with the new release; failing to run these scripts will introduce quite a few failure cases within the tinderbox that, obviously, will be spurious. The same goes for lafilefixer. I’ll probably have to write a maintenance script to improve the flow of that, so I don’t forget steps around.

Yamato’s hardware is designed to work in parallel (as Mike also found out it seems like the sweet spot for build is number of cores per two); so another problem that adds to the tinderbox is that it does sequential merging of everything: making that parallel it is quite hard because of interdependencies of packages. So to speed stuff up, the build process itself has to be parallel-safe; which you probably know it often is not and which is one of the reasons why I often fix packages around.

One pretty bad example of time wasted because of serial-make runs is boost: almost four hours yesterday for the merge, because the tests are built and executed in series: instead of building all the test binaries and then executing them in series (which is a good compromise if you cannot run them in parallel), it goes on building and testing; the result is obviously pretty bad on my system.

Quite a few times, by the way, the whole situation is exasperated by the fact that the build failures were already reported, often times by me, last year. Yep, we got year-old build failures in tree that hit users. And guess what? At least a couple of time the proposed solution is “use an overlay”. No, the right solution is not to let software bitrot in the tree!

Anyway, thanks Genone who sent me the patch to have better collision diagnostics, and thanks Mauro who’s working on new bashrcng plugins for the QA tests. Hopefully, some of the tests will also find their way into Portage soon; and again, I’ll suggest you consider the idea of contributing somehow (if you cannot contribute by code or fixes) — might not be extremely difficult to deal with the tinderbox, but sure is time-consuming, and time, well, is money…

Raúl Porcel: Status @ 2009-11-23

Raúl Porcel (armin76) — Mon, 23 Nov 2009 18:48:58 +0000

What I’m doing during this days:

-Test KDE-4.3 on SPARC.
Six months ago or so, the KDE team asked to the archteams to keyword KDE-4.2. SPARC was left out because one of its dependencies, webkit, sigbused. I remember some person told me that they were dealing with that upstream, I don’t remember who tbh. At the end nothing came from that, and some weeks ago KDE-3.5 got masked.

Unfortunately no one told me KDE-3.5 was getting masked, leaving the users of all arches except amd64/x86 without a stable KDE. Since on the KDE-4.3 stabilization bug there was only amd64 and x86 CC’ed. I expressed my (bad) thoughts about that to the KDE team. I didn’t expect they would mask KDE-3.5 without caring for the other arches, or without telling me, considering i’m on three of the six affected arches(alpha hppa ia64 ppc ppc64 sparc).

Anyway, the patch from Debian for SPARC not sigbusing on webkit/qt-webkit was applied, since webkit’s upstream hasn’t fixed the problem yet. Both webkit/qt-webkit got ~sparc. ATM i’m still emerging 35 of 348 dependencies KDE-4.3 needs.

-GNOME-2.26 stabilization
Another surprise, the GNOME team dropped ia64 and sparc keywords on gnome-base/gnome. I just discovered this yesterday, but its been that way for a long time. As i said to the GNOME team, i remember keywording some packages, but they didn’t told in any bug that they dropped the keywords on the gnome meta ebuild. Anyway, they understood what i told them and they’ll take care of that next time

For sparc there was a problem, xulrunner-1.9 wasn’t keyworded back when gnome-2.26 made it to the tree, it wasn’t keyworded because…i can’t remember…i think it was related to the included sqlite on xulrunner, which had unaligned accesses and made firefox, and everything using xulrunner sigbus. That mean that i was unable to keyword yelp, as it depends on xulrunner-1.9. But xulrunner-1.9 has been working on sparc for some time So i tested yelp and keyworded it ~sparc today, along with gnome-base/gnome

-Xulrunner-1.9.1/Firefox-3.5 on SPARC
I’ll write about this another day. But it should be working soon.

-ARMv7 stages
Yes! I'm working on this! How? Well, i'm still waiting for someone to provide me an ARMv7 board capable of doing 24h compiling. Once I get one, I will build them. Unfortunately, no one has offered me that kind of board. The Beagleboard is a nice device, but it needs an external power supply and an USB hub for plugging an USB hdd. I'm also waiting for the Efika MX i got assigned to arrive.

Thats it for today.

Raúl Porcel: Salutations, Earth!

Raúl Porcel (armin76) — Mon, 23 Nov 2009 18:07:54 +0000

Hi everyone,

This is my first blog, and to be honest i don’t like it very much, as i’m not a person of writing stuff. But I’ve found this is the only way to spread around Gentoo’s planet what I’m currently doing, which tends to be a lot of things that don’t get published anywhere.

So what do I do in Gentoo? At the moment I am the lead of the IA64 and SPARC architectures, co-lead of Alpha and ARM, member of s390, sh and x86. I’m also member of the non-archteams Mozilla(I only do binary stuff), net-p2p and net-irc(not much time for those, tbh). And i think i’m not leaving anything… If you have any question or anything i’ll be happy to answer.

Let’s see how it goes!

Jeremy Olexa: Gentoo Prefix: How I survive work…

Jeremy Olexa (darkside) — Mon, 23 Nov 2009 17:43:26 +0000

As Dan writes, I too survive work by using Gentoo Prefix.

%% uname -a
HP-UX localhost B.11.31 U 9000/800 HP-UX
%% gcc --version
gcc (GCC) 4.2.4 (Gentoo 4.2.4-r01.2 p1.1)
%% bash --version
GNU bash, version 4.0.35(1)-release (hppa2.0n-hp-hpux11.31)
%% ls --version
ls (GNU coreutils) 8.1
Packaged by Gentoo (8.1 (p1))

Thanks to haubi for putting effort into the necessary upstream changes/patches for hppa-hpux support!

Patrick Lauer: Christmas Wishlist

Patrick Lauer (bonsaikitten) — Mon, 23 Nov 2009 15:57:44 +0000

Oh well. I don't really celebrate Christmas (once in a decade is enough). And it's a bit early to be in the christmas spirit (which most years seems to be a mix of being stressed and being rude to others).
Still there's a few things every geek can use, and maybe there's a magic elf out there who can make a wish come true, eh?
Now if you, by chance, feel the need to help me out there's a few little things I could use. My current buildbox is quite nice, but I'm hitting a ceiling. It's not so much the CPU (quadcore ftw), but the IO that's hurting. And I'm getting a bit cramped with space - 65GB distfiles alone!

So here's the things I would really appreciate:

SSD, SATA-II, 32GB or larger
harddisk, SATA-II, 750G or larger, at least two (RAID-1)
SATA Controller, PCI or PCI-E, "something reliable"
Memory, 4x4GB, for great justice

Having those bits would help a lot - let's see:
an SSD is really nice to compile in. Tremendously helps performance. I currently have "only" 8GB, which limits what I can build (boost with FEATURES="test" needs more!) and how much I can build in parallel.
Harddisks - all the distfiles, binpkgs and other things add up. At current prices a small disk makes little sense, and I'd want some reliability, so I'd want at least two disks (raid1) or more (raid5).
Since I have a "desktop" mainboard there's only four sata ports. This means I can currently add 0 extra disks. Which sucks a bit :) So I'd need a sata controller to really enjoy any goodies.
And lastly even with the current 8GB RAM I'm hitting a saturation point. It's insane, but with 4 or more chroots doing stuff it can get painfully tight. Again, desktop mainboard, so I'd need 4x4GB to have an advantage (or get a new mainboard with all the complications that involves)

All that just to compile faster. Aren't we a decadent bunch of hackers? :)

Jeremy Olexa: Buggy MTRR on Acer Aspire One ZG5

Jeremy Olexa (darkside) — Sun, 22 Nov 2009 21:22:24 +0000

The problem:

$ dmesg |grep mtrr
mtrr: no more MTRRs available

I found on my 'new-to-me' AA1 that MTRR handling in the BIOS was messed up. Thanks to this bug report I figured out that I should compile the kernel with MTRR sanitizer enabled. That is:

$ zgrep -i MTRR /proc/config.gz
CONFIG_MTRR=y
CONFIG_MTRR_SANITIZER=y
CONFIG_MTRR_SANITIZER_ENABLE_DEFAULT=1
CONFIG_MTRR_SANITIZER_SPARE_REG_NR_DEFAULT=1

And output of /proc/mtrr is as follows. Before and after.

$ cat /proc/mtrr
reg00: base=0x0fffe0000 ( 4095MB), size=  128KB, count=1: write-protect
reg01: base=0x0fffc0000 ( 4095MB), size=  128KB, count=1: uncachable
reg02: base=0x000000000 (    0MB), size=  512MB, count=1: write-back
reg03: base=0x020000000 (  512MB), size=  512MB, count=1: write-back
reg04: base=0x03f800000 ( 1016MB), size=    8MB, count=1: uncachable
reg05: base=0x03f600000 ( 1014MB), size=    2MB, count=1: uncachable
reg06: base=0x03f500000 ( 1013MB), size=    1MB, count=1: uncachable
reg07: base=0x000000000 (    0MB), size=  128KB, count=1: uncachable
after kernel modification:
reg00: base=0x000000000 (    0MB), size= 1024MB, count=1: write-back
reg01: base=0x03f500000 ( 1013MB), size=    1MB, count=1: uncachable
reg02: base=0x03f600000 ( 1014MB), size=    2MB, count=1: uncachable
reg03: base=0x03f800000 ( 1016MB), size=    8MB, count=1: uncachable
reg04: base=0x040000000 ( 1024MB), size=  256MB, count=1: write-combining

This is needed for decent video playback with the on-board Intel 945 video.

Diego E. Pettenò: Tinderbox: explaining some works

Diego E. Pettenò (flameeyes) — Sun, 22 Nov 2009 19:44:44 +0000

Many people asked before to explain better how my tinderbox works so that they can propose changes and help. Well, let me try to explain more how the thing is working so I can actually get some suggestions, as right now I’m a bit stuck.

Right now the tinderbox is a Linux Container that runs in Yamato; since Linux Containers are pretty lightweight, that means it has all the power of Yamato (which is actually my workstation, but it’s an 8-way Opteron system, with 16GB of Registered ECC RAM and a couple of terabytes of disk space).

Processing power, memory and disk space are shared between the two so you can guess that while I’m working with power-hungry software (like a virtual machine running a world rebuild for my job), the tinderbox is usually stopped or throttled down. On the other hand this makes it less of a problem to run, since Yamato is usually always running anyway. If I had to keep another box running just for the tinderbox, the cost in electrical power would be probably too high for me to sustain for a long time). The distfiles are also shared in a single tree (among also the virtual machines, other containers and chroots so that makes it very lightweight for Yamato to run in the background).

Since it’s an isolated container, I access the tinderbox through SSH, from there I launch screen and then I start the tinderbox work; yes it’s all manual for now. The main script is tinderbox4a.py that Zac wrote for me some time ago; this lists all the packages that haven’t been merged in the given time limit (6 weeks), or that have been bumped since the last time they were merged. It also spews on the standard error if there are USE-based dependencies that wouldn’t be satisfied with the current configuration (since the dependencies are brought in automatically, I just need to make sure the package.use file is set properly.

The output of this script is sorted by name and category; unfortunately I noticed that doing so would isolate too many of the packages at the bottom of the list, so to make it more useful, I sort it at random before saving it to a file. That file is then passed as argument to two xargs calls: the tinderbox itself, and the fetcher. The tinderbox itself has this command xargs --arg-file list -n1 emerge -1D --keep-going which means that each package listed is tried to install with its dependencies brought in, and if some new dependency fails to build (but the old is present) it’s ignored.

Now that you’ve seen how the tinderbox is executed you can see why I have a separate fetcher: if I were to download all the sources inline with the tinderbox (which is what I did a long time ago) I would end up having to wait for the download to complete before it would start the build, and thus add a network-bound latency to the whole job which is already long enough. So the fetcher runs this: xargs --arg-file list emerge -fO --keep-going which runs a single emerge to fetch all the packages. I didn’t use multiple calls here because the locks on vdb would make the whole thing definitely slower than what it is now; thanks to --keep-going it doesn’t stop when one package is unfetchable at least.

Silly note here: I noticed tonight while looking at the output that sometimes it took more time to resolve the same host name than fetching some smaller source file (since Portage does not yet reuse the connection as it’s definitely non-trivial to implement — if somebody knows of some kind of download manager that keeps itself in the background to reuse connections without using proxies I’d be interested!). The problem was I forgot to start nscd inside the tinderbox… took a huge hit from that, now it’s definitely faster.

This of course only shows the running interface; there are a couple extra steps involved though; there is another script that Zac wrote me: unavailable_installed.py that lists the packages that are installed in the tinderbox but are now unavailable, for instance because they were masked, or removed. This is important so I can keep a clean system from stuff that has been dropped because it was broken and so on. I run this each time I sync, before starting the actual tinderbox list script.

In the past the whole tinderbox was much hairier; Zac provided me with patches that let me do some stuff that the official portage wouldn’t do, that made my job easier, but now all of them are in the official Portage, and I just need to disable the unmerge-logs feature as well as enable the split-log one: the per-category split logs are optimal to submit them to the bugzilla, as Firefox does not end up chocking while trying to load the list of files.

When it’s time to check the logs for failures (of either build/install or tests, since I’m running with FEATURES="test test-fail-continue"), I simply open my lovely emacs and run this grep command: egrep -nH -e "^ .*\*.* ERROR:.*failed" -r /media/chroots/logs/tinderbox/build/*/*:*.log | sort -k 2 -t : -r which gives me the list of logs to look into. Bugs for them are then filed by me, manually with Firefox and my bug templates since I don’t know enough Python to make something useful out of pybugz.

Since I’m actually testing for a few extra things that are currently not checked for by Portage, like documentation to be installed in the proper path, or mis-installed man pages, I’ve got a few more greps rounds to run in the completed logs to identify them and report them, also manually. I should clean up the list of checks but for now you got my bashrc if you want to take a peek.

The whole thing is long, boring, and heavy on maintenance; I have still to polish some rough edges, like a way to handle the updates to the base system before starting the full run, or a way to remove the packages broken by ABI changes if they are not vital for the tinderbox operations (I need some extra stuff which is thus “blessed” and supposedly never going to be removed, like screen, or ruby to use ruby-elf).

There are currently two things I’d like to find a way to tweak in the scripts. The first is a way to identify collision problems: right now those failures gets only listed in the elog output and I have no way to get the correct data out without manually fiddling a lot with the log, which is suboptimal. The second problem is somewhat tied to that: I need a scoring system that drops all the packages that failed to merge to drop down in the list of future merges: build failures and collisions alike. This would let me spend more time building untested packages than rebuilding those that failed before.

If you want to play with the scripts and send me improvements, that’s definitely going to be helpful; a better reporting system, or a bashrcng plugin for the QA tests (hint, this was for you Mauro!) would be splendid.

If you still would like to contribute to the tinderbox effort without having knowledge of the stuff behind it, there are a couple of things you can get me that would definitely be helpful; in particular a pretty useful thing would be more RAM for Yamato; it has to be exactly the same as the one that I got inside, but luckily, I got it from Crucial so you can get it with the right code: CT2KIT51272AB667 — yes the price is definitely high, I paid an even higher price though for it, though. If you’d like to contribute this, you should probably check the comments, in the unlikely case I get four pairs of those. I should be able to run with 24, but the ideal would be to upgrade from the current 16 to 32 GB; that way I would probably be able to build using tmpfs (and find eventual problems tied to that as well). Otherwise check the donations page or this post if you’re looking for more “affordable” contributions.

Diego E. Pettenò: The importance of opaque types

Diego E. Pettenò (flameeyes) — Sat, 21 Nov 2009 18:03:36 +0000

I sincerely don’t remember whether I already discussed about this before or not; if I didn’t, I’ll try to explain here. When developing in C, C++ and other languages that support some kind of objects as type, you usually have two choices for a composited type: transparent or opaque. If the code using the type is able to see the content of the type, it’s a transparent type, if it cannot, it’s an opaque type.

There are though different grades of transparent and opaque types depending on the language and the way they would get implemented; to simplify the topic for this post, I’ll limit myself to the C language (not the C++ language, be warned) and comment about the practises connected to opaque types.

In C, an opaque type is a structure whose content is unknown; this usually is declared in ways such as the following code, in a header:

struct MyOpaqueType;
typedef struct MyOpaqueType MyOpaquetype;

At that point, the code including the header will have some limitations compared to transparent types; not knowing the object size, you cannot declare objects with that type directly, but you can only deal with pointers, which also means you cannot dereference them or allocate new objects. For this reason, you need to provide functions to access and handle the type itself, including allocation and deallocation of them, and these functions cannot simply be inline functions since they would need to access the content of the type to work.

All in all you can see that the use of opaque types tend to be a big hit for what concerns performance; instead of a direct memory dereference you need always to pass through a function call (note that this seems the same as accessor functions in C++, but those are usually inline functions that will be replaced at compile-time with the dereference anyway); and you might even have to pass through the PLT (Procedure Linking Table) which means further complication to get to the type.

So why should you ever use opaque types? Well they are very useful when you need to export the interface of a library: since you don’t know either the size or the internal ordering of an opaque type, the library can change the opaque type without changing ABI, and thus requiring a rebuild of the software using it. Repeat with me: changing the size of a transparent type, or the order of its content, will break ABI.

And this gets also particularly important when you’d like to reorder some structures, so that you can remove padding holes (with tools like pahole from the dwarves package, see this as well if you want to understand what I mean). For this reason, sometimes you might prefer having slower, opaque types in the interface, instead of faster but riskier transparent types.

Another place where opaque types are definitely helpful is when designing a plugin interface especially for software that was never designed as a library and has, thus, had an in-flux API. Which is one more reason why I don’t think feng is ready for plugins just yet.

Patrick Lauer: Random things

Patrick Lauer (bonsaikitten) — Sat, 21 Nov 2009 15:58:06 +0000

Now with 3D working quite well on my radeon (HD4650) I've tested a few games. Somewhere in the last 3 days the performance got a good kick, the improvements are noticeable.
Quake3 by default is limited to 1600x1200 and pretty much maxes out at 90fps all the time. It feels really smooth, and the resolution is quite nice too :)
UT2004 runs at 1920x1200, looks awesome, but is a bit too slow. Around 1280x1024 the performance is high enough to play well.
Nexuiz at 1920x1200 has a rather wobbly performance. Sometimes it goes down to about one frame per second, then spikes back to 30+. Around 1280x1024 it too becomes nicely playable.
That's quite awesome for an open driver, and it's about the first time I've heard the graphics card fan kick in like that.

And people were right, you really only need the -9999 versions of mesa + libdrm + xf86-video-ati.

About the portage options and all that, darkside has blogged about some in the past. It's nice to have some numbers to put next to the --jobs magic :)
And KingTaco had found the CPU hotplugging madness quite some time before me. Plus ca change, plus c'est la meme chose.

I've been slacking a bit, now I'm feeling almost guilty for letting bugs rot. It's interesting to see how motivation works. Sometimes I even wonder why I spend any time on such things - as soon as I fix a bug upstream does a new release, a security issue is found or some other form of breakage. It's a bit frustrating to see this endless stream of "work" coming in ...
But I'm quite happy to see more and more involvement from users. It's good to see people trying to help. Most seem to lack confidence, what they lack in skills they make up for in learning at an insane pace. So as long as there is someone to guide them a bit they are totally awesome. Which means that if I can get some more people motivated I can finally resume infinite slacking because I've been made redundant. I think that should be the goal of every package maintainer :)

Diego E. Pettenò: Garbage-collecting sections is not for production

Diego E. Pettenò (flameeyes) — Sat, 21 Nov 2009 13:59:30 +0000

Some time ago I wrote about using --gc-sections to avoid unused functions to creep into final code. Today instead I’d like to show how that can be quite a problem if it was used indiscriminately.

I’m still using at least for some projects the diagnostic of --gc-sections to identify stuff that is unused but still kept around. Today I noticed one bad thing with it and pulseaudio:

/usr/lib/gcc/x86_64-pc-linux-gnu/4.4.2/../../../../x86_64-pc-linux-gnu/bin/ld: Removing unused section '.data.__padsp_disabled__' in file 'pulseaudio-main.o'

The __padsp_disabled__ symbol is declared in main.c to avoid pulseaudio’s access to OSS devices to be wrapped around by the padsp script. When I first have seen this, I thought the problem was a missing #ifdef directive: if I didn’t ask for the wrapper, it might still have declared the (unused) symbol. That was not the case.

Looking at the code, I found what the problem was: the symbol is (obviously) never used by pulseaudio itself; it is, rather, checked through dlsym() by the DSP wrapper library. For this reason, for compiler and linker, the symbol looks pretty much unused, and when asking for it to be dropped explicitly, it is. Since the symbol is loaded via the runtime linker, neither building nor executing pulseaudio will have any problem. And indeed, the only problem would be when running pulseaudio as a children of padsp, and using the OSS output module (so not on most Linux systems).

This shows how just using -fdata-sections -ffunction-sections -Wl,--gc-sections is not safe at all and why you shouldn’t get excited about GCC and ld optimisations without understanding how they work in detail.

In particular, even I thought that it would be easier to work around than it actually seem to be: while GCC provides a used attribute that allows to declare a variable (or a function) as used even though the compiler can’t tell that by itself (it’s often used together with inline hand-written ASM the compiler doesn’t check for), this does not propagate to the linker, so it won’t save the section from being emitted. The only solution I can think of is adding one instruction that sets the variable to itself, but that’s probably going to be optimised away. Or giving a way for gcc to explicit that the section is used.

Arun Raghavan: The times they are a-changin’

Arun Raghavan (ford_prefect) — Sat, 21 Nov 2009 05:46:37 +0000

Yesterday was my last day at NVidia. I’ve worked with the Embedded Software team there for the last 15 months, specifically on the system software for a Linux based stack that you will see some time next year. I’ve had a great time there, learning new things, and doing everything from tweaking bit-banging I²C implementations with a CRO to tracking down alleged compiler bugs (I’m looking at you -fstrict-aliasing) by wading through ARM assembly.

As some of you might already know, my next step, which has had me bouncing off the walls for the last month, is to join the great folks at Collabora Multimedia working on the PulseAudio sound server. I’ll be working from home here, in Bangalore (in your face, 1.5-hour commute!). It is incredibly exciting for me to be working with a talented bunch of folks and actively contributing to open source software as part of my work!

More updates as they happen. :)

Stuart Longland: Yes… I hate you too Microsoft

Stuart Longland (redhatter) — Sat, 21 Nov 2009 02:53:17 +0000

Just installed a wireless card in the laptop I use at Laidley… the wireless card is a pretty standard Intel Pro/Wireless 2915ABG mini-PCI card. It works flawlessly under Linux. I think it was originally from an IBM Thinkpad T41, as it has “FRU: 93P4239″ which when used as a search keyword, leads me to that page on the ThinkWiki site.

I’ve used it just fine in the Toshiba TE2100 I had no problems under Linux… never did get Windows to work with it.

I gave it another try today, after installing it into the Satellite PRO 6100 that I use at Laidley… The machine runs Windows XP as Texas Instruments likes to play all kinds of ridiculous proprietary games with their DSPs and MCUs (in particular, the TMS320LF2406A and the MSP430). So I’m stuck with this horrid OS.

I popped the card in… no problems, slots in nicely under the keyboard. Windows boots up, recognises the card as being a “network controller”, but doesn’t have the drivers… so far so good. Downloaded the drivers off the Lenovo site, and also grabbed the official Intel ones. I’ve tried both thus far.

Upon installation, I see the following:

Okay… fine… let’s see what the Event Viewer can tell me.

Rightyo… there’s a link I can look at… what does this tell me? I give it a try…

This wireless card works out-of-the-box in Linux with no stuffing around. Yet… Windows won’t touch it…. and people wonder why I bag Microsoft.

If anyone knows of a solution to this gem (that doesn’t involve replacing the hardware or OS) I’m all ears.

David Abbott: Podcast 66 All About Me

David Abbott (dabbott) — Sat, 21 Nov 2009 00:22:11 +0000

In this podcast comprookie talks about Gentoo and podcast procrastination.

LINKS:
SSH access to cvs.gentoo.org
http://www.gentoo.org/proj/en/infrastructure/cvs-sshkeys.xml
cvs
http://www-mrsrl.stanford.edu/~brian/cvstutorial/
http://www.gentoo.org/doc/en/cvs-tutorial.xml
git
http://www.kernel.org/pub/software/scm/git/docs/gittutorial.html
perl-overlay
http://git.overlays.gentoo.org/gitweb/?p=proj/perl-overlay.git;a=summary
tove
http://cia.vc/stats/author/tove
Michele Beltrame
http://www.cattlegrid.info/
Kent Fredric
http://kent-fredric.fox.geek.nz/v1
Gentoo GuideXML
http://www.gentoo.org/doc/en/xml-guide.xml
Gorg
http://gentoo.neysx.org/mystuff/gorg/gorg.xml
Gentoo Tips
http://gentoo-pr.org/

irc network freenode channel #linuxcrazy

Download

Kenneth Prugh: Quirks with Opera

Kenneth Prugh (ken69267) — Fri, 20 Nov 2009 23:31:47 +0000

So I’ve been a long time Opera user, but lately some bugs have really started to agitate me and are killing my user experience.

The first bug is Opera is unable to open certain long URL’s from the commandline, approximately if the URL is 86 characters or longer. This was fixed awhile ago in the Windows version of Opera, but it seems it never got corrected in the Linux builds. This causes me to be greatly annoyed as applications can no longer pass long URLs to Opera to be opened. Most notably in my case is links inside my email client. I click those links expecting Opera to happily open them, but all I get is no response. Manually copying and pasting links into Opera from email is a royal pain and has tempted me to try Chromium a bit more full time. I submitted a bug report about it to Opera but we will see if that changes anything. If it doesn’t get fixed soon I’ll have to switch to just maintain my sanity of clicking URLs.

The second bug is flash freezes all the time in Opera. This is incredibly annoying when I’m watching something on Hulu. The show will be playing fine and then suddenly the video will freeze, but the sound will keep playing. This doesn’t seem to occur in other browsers such as chromium or arora. Based on that, I’d assume its an Opera bug but I can’t be sure. Either way it’s quite annoying. I can’t tell if it was a recent Opera update or flash update that introduced this behavior though.

Hoping the next Opera beta/rc fixes at the least my url length problem

Sune Kloppenborg Jeppesen: B2evolution upgraded to 3.3.2 Part II

Sune Kloppenborg Jeppesen (jaervosz) — Fri, 20 Nov 2009 15:13:55 +0000

Well it turns out that I need more caffeine. Today I fixed the issues I had yesterday after the upgrade to B2evoltuion 3.3.2.

It turns out that PHP error logging was disabled on the server, thus I didn't get to see the error PHP was throwing. Stupid me:-/
b2evolution-3.3.2 needs PHP with ctype support, which is simply enabled with the corresponding USE-flag. The error PHP was throwing was:
[Fri Nov 20 09:57:11 2009] [error] [client 208.115.111.247] PHP Fatal error: Call to undefined function ctype_space() in /var/www/site/htdocs/inc/_core/_misc.funcs.php on line 779

The funny thing is that apparently B2evolution is not using PHP ctype support for all posts, but only some posts (ie. with URLS). Thus making debuggin all the more fun. On top of that B2evolution now prerenders pages eventhough caching is disabled. Oh the fun of debugging.

Also I had a funny problem during the upgrade of the B2evolution MySQL tables. For future reference I'll post the details here as well. The installer threw this one:
Additional information about this error: MySQL error! Can't create table './b2evo/#sql-7735_1.frm' (errno: 135)(Errno=1005) Your query: ALTER TABLE evo_items__item ENGINE=innodb

The MySQL docs lists errno 135 as no space left in the record file and suggests way to fix this here.

At first I misintepreted the proposed solution but it simply turned out that I had to change the following line in MySQL my.cnf:
innodb_data_file_path = ibdata1:10M:autoextend:max:256M

I simply had to increase max.

Now it's time to actually see what new features B2evolution 3.3.x has...

Original post blogged on b2evolution.

Jorge Manuel B. S. Vicetto: Amarok-2.2.0/1 and >=binutils-2.20

Jorge Manuel B. S. Vicetto (jmbsvicetto) — Fri, 20 Nov 2009 03:28:59 +0000

I've just bumped media-sound/amarok in the tree to 2.2.1-r1 which includes some missing deps.
Even though 2.2.1 hit the tree before the official release, I'm a few days behind in the bump and unmasking it - the mask should be out when you read this.
Unfortunately, amarok-2.2.0 and amarok-2.2.1 segfault on start when built with >=binutils-2.20 even though they have no issue starting with >=binutils-2.20 if built with a previous version of binutils - see bug #290662 for more details.
While the issue isn't solved, here is a quick workaround:

# emerge -1 =binutils-2.19.1-r1 && emerge -1 amarok && emerge -1 binutils

Original post blogged on b2evolution.

Diego E. Pettenò: The routed network broadcast problem

Diego E. Pettenò (flameeyes) — Thu, 19 Nov 2009 22:27:27 +0000

You might remember my network diagram that has shown you the absurd setup I have at home to connec tall the rooms where computers are located. Since then, something was reduced, and indeed now the network section between my bedroom and the office is over the usual Ethernet (should be Gigabit, but something doesn’t look right) cable. This actually should also reduce the power consume at home since the old Powerline adaptors were still an extra powered appliance; the main reason why I replaced the, though, was that the green LEDs definitely bothered me while trying to sleep, and at the same time, speed was quite an issue with some files’ streaming.

The result is that only two media are used here: WiFi and cabled Ethernet; unfortunately, I still lack a way to connect Yamato and Deep Space 9 (the router) via Ethernet directly, so they are connected via a standard infrastructure WiFi. This is not really exceptional, in the sense that the connection between them is not very stable (I use an ath9k card on Yamato, with 2.6.32rc7 kernel), and when I’m downloading stuff with bittorrent or similar, I need to restart the network connections about once every five minutes to keep it going properly, which you can guess is not that fun.

Now unfortunately there is one problem here, which I ignored for quite a while but I cannot ignore any longer (because I finally got the table I needed to play with Unreal Tournament 3 with my PlayStation 3!): the cabled ethernet segments fail to get UPnP support.

The whole network inside a single Class B IP range (172.28.0.0/16), fractioned into four main subnetworks (direct, and behind Yamato, known and unknown computers, they have different filters on the firewall) by the DHCP server running on Deep Space 9 (for simplicity, Yamato is the only box in the network to have a static IP address, in an unused subnetwork range together with Deep Space 9, beside the router/DHCP server itself). Yamato has two interfaces enabled: wlan0 which connects to the AP and then to DS9, and br0 which is the bridge of the remaining interfaces (eth0 and eth1 for the cabled network segments – the latter I only bring up when I need more ports for work devices – and vde0 for the virtual networks). Here start the problem: while a WiFi network is usually akin to a switched network, and of course my cabled segment is also switched, the two together are not switched but routed together, by Yamato which is a second router in the network.

Of course I built DS9 to reduce the load of Yamato (even though my original planning involved linking the cabled with that through a another, very long, cable), so the services are currently mostly running on DS9 rather than Yamato: DHCP server, DNS server, UPnP server and so on. The problem is that almost all the “zeroconf” kind of services, which include not only Apple’s Bonjour protocol, but UPnP and DHCP as well use the UDP transport and the broadcast address to look for the servers. And UDP broadcast only works within switched networks, not routed ones.

The obvious solution in these cases, which is more or less the only solution you’ll ever read proposed around when people ask about broadcast repeaters, is to use bridging instead of routing to merge the two networks together; a switch is, after all, just a multi-port bridge, so the result is again a switched network. Unfortunately this brings two issues with it: the first is that you effectively lose the boundary between the two networks, even when that was very transparent, like I’d like it to be, the filtering can still be useful for some things; the latter is that bridging WLAN interfaces is complex and pretty much suboptimal.

The problem with bridging WLAN is that putting the network card in promiscuous mode is not enough: the access point by default only sends over the air the PDUs whose destination is an associated mac address. And telling the access point to send all the PDUs might not be good either; while in my setup the problem is relatively small (the only two devices connected via Ethernet to DS9 are the AP and the Siemens VoIP phone — the Linux bridge software will still understand to only send the VoIP phone data to the connected network card and the rest to the AP), it doesn’t look like a very good long-term solution.

To solve part of the problem, at least the most common part of it, both ISC DHCP and Avahi provide support for transparently join two routed networks that would otherwise be isolated: dhcrelay and Avahi’s refector. The former is not just a simple repeater of DHCP requests, but it also adds a “circuit-id” to the requests, so that requests coming from behind it are tagged and can be treated differently (this is how I handle differently the clients behind Yamato — of course those have to get to a subnet that is routed through Yamato); the latter just picks up the service broadcasts and copy them to the various interfaces it listens on… but neither is perfect.

With dhcrelay the problem is deep inside the way it has been implemented: it has to listen on both the interface the requests will come from, and that where the responses come from… and it doesn’t discriminate between them; this means in the case of Yamato that I have to listen to both br0 and wlan0, but then the requests sent by the clients on WiFi will still reach the relay and would be sent back to DS9 through the relay; for this reason the “circuit-id” contains the interface the request came from, so I only check for that id to be br0 instead of just checking if it exists, before deciding how to divide the clients. The alternative is using iptables to filter the requests from the wlan0 interface, but let’s leave that for a moment.

The problem with Avahi seems more to be a bug, or rather an untested corner case; I have found no way to stop Linux from issuing link-local IPv6 addresses to the interfaces that result “up”; this unfortunately means that eth0, vde0 and br0 all have their IPv6 address… so the broadcasts coming from wlan0 are reflected on all three of them, and all the clients connected to the cabled (or virtual) segment will receive the broadcast twice. This wouldn’t be much of an issue if Apple’s compuers didn’t decide to rename themselves to “Whatever (2)” when they felt somebody else was using their hostname in the network. I should speak with Lennart about it but I haven’t had time to deal with that just yet.

There remains a third protocol there that I found no solution for yet: UPnP; with UPnP the problem is relatively easy: SSDP uses UDP broadcasts on port 1900 to find the router, before talking directly with it, so the only thing that I’d be needing is a repeater over that particular port. The best solution to me would have been using iptables directly, but since that’s not implemented for what I can see, I guess I’ll end up either writing my own UDP repeater, or look for something working, and properly written. If somebody has a clue about that, I’d be happy to hear the solutions.

Interestingly enough, UPnP during my analysis proven to be the only protocol I’m interested in that actually could be just re-broadcasted with a generic repeater; for DHCP, I need to discern proxied requests to assign them to properly routed subnetworks; for Bonjour, the port wouldn’t be free for a repeater since Avahi itself would be using it to begin with.

So bottom-line, I’d have three needs that somebody might want to help me with: get a better dhcrelay the current implementation sucks in more ways than a few, starting for the not being able to specify which is the input and which the output interface, or the lack of a configurable circuit-id string; fix the Avahi IPv6 reflector over bridged network, although I have no idea how (alternative: find a way to tell Linux/OpenRC not to issue a link-local IPv6 address to the interfaces); write a generic UDP broadcast repeater so that UPnP can work with a routed network — the last one is what I’ll probably work on tomorrow so I can get the PS3 to pass through the ports with DS9.

Sune Kloppenborg Jeppesen: B2evolution upgraded to 3.3.2 (sort of)

Sune Kloppenborg Jeppesen (jaervosz) — Thu, 19 Nov 2009 21:51:47 +0000

After a stupid MySQL mistake I got b2evolution upgraded to 3.3.2. However it seems there is some problem in the rendering code, causing rendering to suddenly stop. So far I've hunted it down to being the last part of the function render in
inc/plugins/model/_plugins.class.php (line 1295 to 1327):

1272 function render( & $content, $renderers, $format, $params, $event_prefix = 'Render' ) ... 1295 foreach( $renderer_Plugins as $loop_RendererPlugin ) 1296 { // Go through whole list of renders 1297 // echo ' ',$loop_RendererPlugin->code, ':'; 1298 1299 #return "Test"; 1300 #$this->call_method( $loop_RendererPlugin->ID, $event, $params ); 1301 switch( $loop_RendererPlugin->apply_rendering ) 1302 { 1303 case 'stealth': 1304 case 'always': 1305 // echo 'FORCED '; 1306 $this->call_method( $loop_RendererPlugin->ID, $event, $params ); 1307 break; 1308 1309 case 'opt-out': 1310 case 'opt-in': 1311 case 'lazy': 1312 if( in_array( $loop_RendererPlugin->code, $renderers ) ) 1313 { // Option is activated 1314 // echo 'OPT '; 1315 $this->call_method( $loop_RendererPlugin->ID, $event, $par ams ); 1316 } 1317 // else echo 'NOOPT '; 1318 break; 1319 1320 case 'never': 1321 // echo 'NEVER '; 1322 break; // STOP, don't render, go to next renderer 1323 } 1324 } 1325 1326 return $content; 1327 }

Seems like the above code is trying to determine wether to render stuff, disabling causes some rendering glitches but at least something is being displayed. But I'm not yet sure why it actually dies.

Original post blogged on b2evolution.

Christian Faulhammer: Kernel testing request 2.6.31

Christian Faulhammer (fauli) — Thu, 19 Nov 2009 09:19:35 +0000

Another testing request. Kernel 2.6.31 is planned to be stabled soon on all architectures. Hereby I now ask users on stable x86 systems to upgrade to gentoo-sources 2.6.31-r6 or vanilla-sources 2.6.31.6 and report back to me in all cases (failure or success). The other arches appreciate tests, too, but I can't speak for them. Thanks in advance.

Alex Alexander: Qt 4.6.0 rc1 – in portage – binary incompatibility warning!

Alex Alexander (wired) — Thu, 19 Nov 2009 08:06:23 +0000

So… qt-*-4.6.0_rc1 is now in the portage tree, masked (since its not a final release) and you can begin testing your shiny Qt applications with it.

But there’s a catch.

4.6.0_rc1 is not binary compatible with 4.6.0_beta1. [1]
This means that if you’re upgrading from 4.6.0_beta1 you have to rebuild every single app depending on qt-*, or they won’t start at all. This obviously includes all of KDE 4.

You can get portage to do that by using a command like this:
*update* it seems some shells didn’t like the old command, so I’ve updated it:

emerge -av1 $(for i in $(qlist -IC x11-libs/qt-); do equery -q d $i | grep -v 'x11-libs/qt-' | sed "s/^/=/"; done)

Note that this command assumes your system is up-to-date. If some installed packages don’t have ebuilds available for their version anymore, you’ll have to resolve that manually (probably by removing them and rerunning the command).

You’ll find equery in app-portage/gentoolkit and qlist in app-portage/portage-utils.

You don’t need to do this if you’re upgrading from Qt 4.5.3 (although you should). You’ll also be safe if you upgrade from 4.5.3 to 4.6.0 final when the time comes.

Portage will warn you about this when you upgrade qt-core to 4.6.0_rc1:

* Messages for package x11-libs/qt-core-4.6.0_rc1:

*
* Binary compatibility broke between 4.6.0_beta1 and 4.6.0_rc1.
* If you are upgrading from 4.6.0_beta1, you’ll have to
* re-emerge everything that depends on Qt.
* Use the following command:
*
* emerge -av1 $(for pkg in $(equery -q d \
* $(qlist -IC x11-libs/qt-) | grep -v “x11-libs/qt-” |
* sort -u); do echo “=$pkg”; done)
*
* YOU’VE BEEN WARNED
*

But users (my user side as well :p) tend to ignore ewarns from time to time

Happy rebuilding!

[1] http://labs.trolltech.com/blogs/2009/11/12/bc-break-in-46-against-previous-46/

Patrick Lauer: CPU Hotswapping and how to disable processors

Patrick Lauer (bonsaikitten) — Wed, 18 Nov 2009 23:43:58 +0000

Here's something awesome I found mostly by accident:
In recent kernels the support for hotswapping CPUs works on x86/amd64 architectures. I stumbled over it in the 2.6.32 menuconfig and couldn't wonder if it actually works. So I had a look and found this gem:

# cat /proc/interrupts | grep CPU
            CPU0       CPU1       CPU2       CPU3

Very boring, 4 processors.

echo 0 > /sys/devices/system/cpu/cpu3/online

And we just knocked out one!
We see that in dmesg:

kvm: disabling virtualization on CPU3                                                                                                                       
CPU 3 is now offline

Hmm, are you thinking what I'm thinking?

kvm: disabling virtualization on CPU2                                                                                                                       
CPU 2 is now offline                                                                                                                                        
kvm: disabling virtualization on CPU1                                                                                                                       
CPU 1 is now offline                                                                                                                                        
SMP alternatives: switching to UP code

Wheeee. I just castrated it to a single core! I actually didn't check if the kernel lets me take CPU0 offline. That would be hilarious. Anyway ...

echo  > /sys/devices/system/cpu/cpu1/online

And we just gained a CPU:

SMP alternatives: switching to SMP code                                                                                                                     
Booting processor 1 APIC 0x1 ip 0x6000                                                                                                                      
Initializing CPU#1                                                                                                                                          
Calibrating delay using timer specific routine.. 5200.20 BogoMIPS (lpj=10400418)                                                                            
CPU: L1 I Cache: 64K (64 bytes/line), D cache 64K (64 bytes/line)                                                                                           
CPU: L2 Cache: 512K (64 bytes/line)                                                                                                                         
CPU 1/0x1 -> Node 0                                                                                                                                         
CPU: Physical Processor ID: 0                                                                                                                               
CPU: Processor Core ID: 1                                                                                                                                   
CPU1: AMD Phenom(tm) 9950 Quad-Core Processor stepping 03                                                                                                   
checking TSC synchronization [CPU#0 -> CPU#1]: passed.                                                                                                      
kvm: enabling virtualization on CPU1

This is seriously wicked. Now I just need to figure out how to bolt that onto powermanagement so that the machine knocks out cores when idle and powersaves. Linux never gets boring ...

Diego E. Pettenò: What distributions want

Diego E. Pettenò (flameeyes) — Wed, 18 Nov 2009 12:58:20 +0000

Or A 101 lesson on how to ensure that your software package is available to the distribution users (which, incidentally, are the Linux users; while already the conglomerate Linux marketshare is pretty low when compared with Windows and OS X, the marketshare of not-really-distributions like Slackware or Linux from scratch is probably so trivial that you don’t have to care about them most of the time. That, and their users are usually not so much scared about installing stuff by themselves.

I’m posting this quickie because I’d like to tell one other thing to Ryan… yes, you are a drama queen. And you proven it right with your latest rant and it really upsets me that instead of trying to understand the problem your solution seems to be closing yourslef even more inside your little world. It upsets me because I can see you as a capable programmer and I’d prefer your capacity being used for something that people can benefit from, rather than wasted on stuff pointless, like FatELF.

The fact that instead of trying to understand the technical points that me and others made, and tell us why you think they are not good enough, you’re just closing yourself further. By saying that “lots of people talked about it” you’re just proving what you’re looking for: fame and glory. Without actual substantial results to back it up. Just an hint: the people who matters aren’t those who continue saying “FatELF will make distributions useless, will make it possible to develop cross-platform software, will solve the world’s hunger”; the people who matters are those that review FatELF for its technical side, and most of us already deemed it pointless; I already explained what I think about it.

Any ISV that thinks FatELF will solve their cross-distribution or cross-architecture problems have no idea what an ELF file is; they don’t really understand the whole situation at all. I’m pretty sure there are such ISV out there… but I wouldn’t really look forward for them to decide what to put inside the kernel and the other projects.

Do you want your software (your games) to be available to as many people as possible? Start working with the freaking distributions! You don’t need to have mastered all the possible package managers, you don’t even need to know about any of them directly, but you got to listen if packagers ask for some changes. If a packager asks you to unbundle a library or allow selecting between bundled or system library; do it, they have their reasons and they know how to deal with eventual incompatibilities. If a packager asks you to either change your installation structure or at least make it flexible, that’s because with a very few exceptions, distributions are fine with following the FHS.

Take a look to “Distributions-friendly packages”: part 1 part 2 and part 3 .

But no, Ryan’s solution here is again taking cheap shots to distributions and packagers, without actually noticing that, after more than ten years distributions are not going away .

Oh and the first commenter who will try to say again that FatELF is the solution, can please tell me how’s that going to ensure that the people writing the code will understand the difference between little endian and big endian? Or that the size of a pointer is not always 32-bit? Count that in as a captcha; if you cannot give me an answer to those two questions, your comment supporting FatELF as The Solution will be deleted.

Sune Kloppenborg Jeppesen: Watching Freeview HD DVB-T MPEG-4 channels

Sune Kloppenborg Jeppesen (jaervosz) — Wed, 18 Nov 2009 07:29:54 +0000

Last week before catching the H1N1 I had the chance to play around a bit with DVB-T.

Here in .dk the analog TV signal was turned off at the start of the month, and we got some new digital freeview channels. Most notably DR HD broadcasting unencrypted 720p movies in MPEG-4.

The MPEG-4 encoding can be a bit tricky since TVs from just a few years back (ie. both my Panasonic TVs) only support MPEG-2 decoding, so a lot of people had to buy new hardware MPEG-4 decoders. However not wanting yet another power consuming device I decided to solve it on the cheap (not speaking of yet another redundant remote control).

First off old DVB-T PCI cards/USB sticks should generally be able to receive DVB-T broadcasts in any encoding, including MPEG-4. I just had an old Hauppauge Nova-T DVB-T card lying around in the basement, what luck:)

I've collected a few notes here that might be helpful for others.

First figure out what kernel options you'll have to enable.

Getting the right channel list:
emerge linuxtv-dvb-apps linuxtv-dvb-firmware w_scan w_scan -x > dvb_frequencies dvbscan dvb_frequencies > channels.conf

Now watch the first channel with: vlc channels.conf. Note if vlc doesn't play anything you might have messed up the generation of channels.conf as I somehow managed to do the first time.

Then record the HD content:
gnutv -channels channels.conf -out file drhd.mp4 "DR HD"

Now come the not so great part, it seems like the MPEG-4 used by DR HD is not well supported in Linux or more precisely the HE-AAC audio codec.

Current stable vlc-1.0.2 seems to be slow to tune in to the programs and audio is choppy and stastistics show dropped audio frames. Upgrading to vlc-1.0.3 seems to make it tune in faster, but the audio is still choppy.

Changing the "Caching value in ms" to 1000 seems to have solved most of the stuttering problems (Preferences -> All -> Input/Codec -> Access modules -> DVB).

Current stable ffmpeg-0.5-r1 only shows 3 streams and refuses to encode:
Stream #0.0[0x907]: Video: h264, yuv420p, 1280x720 [PAR 1:1 DAR 16:9], 50 tbr, 90k tbn, 100 tbc Stream #0.1[0x91f](dan): Subtitle: dvbsub Stream #0.2[0x920](dan): Subtitle: dvbsub

However upgrading ffmpeg to 0.5_p20373, results in it detecting another 2 streams:
Stream #0.0[0x7ef]: Data: 0x0006 Stream #0.1[0x907]: Video: h264, yuv420p, 1280x720 [PAR 1:1 DAR 16:9], 50 tbr, 90k tbn, 100 tbc Stream #0.2[0x911](dan): Data: 0x0011 Stream #0.3[0x91f](dan): Subtitle: dvbsub Stream #0.4[0x920](dan): Subtitle: dvbsub

And the live ffmpeg ebuild actually detects the audio stream, but hangs when encoding:
Stream #0.0[0x7ef](dan): Subtitle: 0x0006 Stream #0.1[0x907]: Video: h264, yuv420p, 1280x720 [PAR 1:1 DAR 16:9], 50 tbr, 90k tbn, 100 tbc Stream #0.2[0x911](dan): Audio: aac, 44100 Hz, 2 channels, s16, 450 kb/s Stream #0.3[0x91f](dan): Subtitle: dvbsub Stream #0.4[0x920](dan): Subtitle: dvbsub

So for now I can watch DR HD on one computer, but playback on my PCH-110 is not working either as the audio codec HE-AAC seems to be unsupported too. Later on I might just install a MythTV backend and do some automatic transcoding to the troublesome devices. That is once proper HE-AAC support is in ffmpeg:-)

Original post blogged on b2evolution.

Patrick Lauer: "Random crashes" with glibc 2.10 and 2.11

Patrick Lauer (bonsaikitten) — Tue, 17 Nov 2009 19:15:18 +0000

As documented in this bug (which mirrors an upstream bug here there's a bug in glibc 2.10 and 2.11, and this one seems to be easy to hit. Multithreaded apps "randomly" crash with "Invalid free" and other confusing errors. A hackaround is to unset or empty the environment variable "MALLOC_CHECK_". For me setting MALLOC_CHECK_="" before starting some of the affected packages seems to completely hide the error, now we can only hope that the gentoo glibc gets this patch soon.

Patrick Lauer: Awesome portage options

Patrick Lauer (bonsaikitten) — Tue, 17 Nov 2009 18:47:10 +0000

For the rest of this post I'll only consider portage 2.2. Most options are in portage 2.1 already, but I'm a lazy bum, so I don't compare to see what's what.

You can set PORTAGE_DEFAULT_OPS in /etc/make.conf, but if you add --ask you will have trouble running emerge from a script. --ignore-default-opts disables those defaults so you can run emerge --sync in a cronjob again.

Sets are really great, --list-sets shows you which are available. Just have a look, there are some nice ones - "security", "installed", "unavailable" ... they can help streamline some tasks. I find their names quite self-explanatory.

If you want to put something into the world file without rebuilding it use --noreplace, and if you want to remove it again use --deselect.

--nospinner disables that funny rotating spinner thingy so you can save precious bandwidth when connected remotely, and --quiet hides most of the output, which can be nice if you don't want to be hypnotized by scrolling compile output. For the OCD crowd --quiet-build might be nice as it doesn't show the compile output on console, but redirects to logfiles. --changelog is neat for seeing the log messages for that update, this often shows fixed bugs or other issues you might care about. --color with a parameter y or n toggles colorized output. And of course --alphabetical. The horror of unsorted output!

Sometimes people are confused that emerge -e world tries to update packages that emerge -uND world misses. That is usually caused by build-only dependencies. --with-bdeps=y and --complete-graph are good options to modify portage behaviour.

If you're on a fast machine and in a hurry you can try to set --jobs X with a reasonable value of X. Think about memory needs and such before setting it to infinity minus one! With --keep-going it gets really easy to not have the whole process stopped on the first failed package. This is not without issues, but it avoids the --resume --skipfirst in a loop tricks. If --jobs seems to hard to calibrate to you --load-average=LOAD may help to limit it.

For the scripters --columns might be nice, it tweaks the output to be more script friendly.

Support for binary packages has grown considerably, there's support for local (-k / -K) and remote (-g / -G ) binpkg repositories. And you can --buildpkg and --buildpkgonly to create them (they are stored in PKGDIR). There's --binpkg-respect-use to only install the packages that have useflags set the same as the current configuration - it's a very powerful mechanism if you need to support Gentoo on multiple machines and don't want to compile that much.

I hope y'all enjoyed this little lesson in RTFM, there's plenty of other options to discover. Don't be afraid of the documentation, it doesn't bite and makes your life easier :)

Robert Buchholz: Eine Stunde Bildungsstreik

Robert Buchholz (rbu) — Tue, 17 Nov 2009 11:47:01 +0000

In diesen Minuten demonstrieren (mehr oder weniger) fünftausend Schüler und Studenten auf der Spandauer Straße in Berlin. Ich war auch am Roten Rathaus, doch meine Ideen von besserer Bildung (frühzeitig, durchlässig, besser ausgestattet, kostenfrei) sprachen dort nur wenige aus. “Kritik am Bildungssystem ist immer auch Kritik am Kapitalismus!” schallt es. Man verkauft T-Shirts und protestiert, die Universitäten seien “Steigbügelhalter des neoliberalen Systems”. Ich fühle mich instrumentalisiert von den Ideologen am Mikrofon.

Ich kann mich entscheiden, im “schwarzen Block” der Autonomen, im roten Block der Kommunisten, bei den Antifaschisten oder den Antikapitalisten mitzulaufen. Dann doch lieber zur S-Bahn.

Mounir Lamouri: Lecture about Mozilla at INSA Lyon

Mounir Lamouri (volkmar) — Tue, 17 Nov 2009 10:11:00 +0000

Last Friday (November 13 2009), I gave a lecture/conference titled Mozilla and its technologies in the context of the Mozilla Campus Reps program. Indeed, I am a Mozilla Campus Rep at INSA Lyon, my university.

The lecture had four parts. First of them was a classic presentation of Mozilla and Netscape history. Then, a presentation of some Mozilla projects like applications, libraries, tools and especially Mozilla Labs. The real technical part was about the Mozilla Platform (Gecko, XUL, ...). To complete, the Open Web and web standards.

Everything went well. I planned to give a 30-minute to 45-minute length lecture with 15 minutes of questions but it looks like I had a lot of things to say and I talked one hour long. Fortunately, there wasn't a lot of questions so I finished in time.
The most important is I had only good feedback which is pretty cool for a first experience !

The Mozilla campus Reps program wasn't able to send me a swag pack so I asked to Tristan Nitot (Mozilla Europe) who seemed delighted to help. Paul Rouget (Mozilla Europe too) also helped with some advices. A big thank you to both of them !

Finally, you can download my slides. You can also get the source files here. The slides have been made in latex with beamer. All this stuff is available in Creative Common Attribution 3.0 (CC-BY).
The slides aren't really verbose. They have been made only to get attention of the audience and let them follow me. I've spoke about a lot of subjects that are not even mentioned like JavaScript benchmarking, V8, FOSS work-flow... I find it more dynamic and -I hope- less boring for the audience.

It was a nice experience and I'm glad to have spread Firefox and Mozilla !

Diego E. Pettenò: Configuration file ordeal

Diego E. Pettenò (flameeyes) — Mon, 16 Nov 2009 18:46:31 +0000

Following another lscube problem discussion, here comes another post of the series “why do I prefer one solution over another”, that I started thinking about after I ripped off the plugins interface from the current feng master branch (to be developed separately and brought back to the master once the interface is properly defined, and chosen and so on).

While ripping off the plugin I had to deal with the configuration file parser that we have in feng right now, which was heavily borrowed out of lighttpd. Luca’s idea has been that, since the scope of lighttpd and feng are quite similar, we could share the same configuration file syntax, and even code. Unfortunately, this ended up having a couple of problems: the first is that, as usual for Luca’s idea, they look so much forward that we only implement a small percentage of the right now: vhost, conditionals and all that stuff is something we not even barely start scratching them; the other is that the code used for the parser has changed quite a bit in lighttpd in the mean time; I think the original one was hand-tailored, then they moved to lemon-based parsing (the parser used by SQLite3) and now they are toying with Ragel to rewrite the mess that it’s now.

But in particular why is the current system a mess? Well the first problem is not really in the syntax itself, but rather n the current (lemon-based, I think) implementation: it uses a big table, which is relatively fine, but then it also references its entries with their direct array index, which means any change in the list of entries require to change all the following ones; not the nicest piece of code I had to deal with.

The second problem is also intrinsic in the way the code was written, partly by hand: there are some objects implemented for the configuration file parsing, like high-level pointer arrays and strings, which reinvent what glib already provides. These objects increase the size and complexity of our code with the only good reason that lighttpd does not use glib and thus have a need for them. Decoupling the configuration file code from these objects is non-trivial, and will diverge the code to the point we wouldn’t be able to share it with lighttpd any longer.

Now there is a certain complexity tied to the way we want the configuration file to behave: we want to have conditionals and blocks, and includes, similar to lighttpd and Apache configuration files, like most software that deals with servers and locations. The simplest configuration file formats don’t work very well for this task (for instance I don’t like the way Cherokee configuration files are written; they are designed to work with a web administration package, rather than hand-edited by an human). This kind of solution usually gets solved in two main ways: either by inventing your own syntax or using something like XML for the configuration file.

While XML makes it relatively easy to parse a configuration file (relatively because it’s just moving the issue of complexity; parsing XML is not usually faster than other configuration file syntax, it’s actually slower and much more complex; but generic XML parsers exist already that make the parsing easier for the final software), it definitely makes it obnoxious to read and edit by hand, which is why I don’t think XML is a good format for configuration files.

My favourite format for configuration file is the “good old” INI-like file format; I call it INI-like but I admit I’m not sure if Windows’s INI files were the ones using it first; on the other hand, the same format is nowadays used by so much stuff, including freedesktop’s .desktop files, and there are multiple well-tested parsers for it, including some (very limited, to be honest) support in glib itself.

Now, it’s obviously a no-brainer that the INI format is nowhere near powerful as the language used by Apache configuration files, or by lighttpd, since it bears no conditionals, and only has structure in the sense of sections, variables and values. But it’s exactly in this kind of simplicity that I think it might work well for feng nonetheless, given it works for git as well.

While the lighttpd syntax contains all kind of conditionals that allow setting particular limits based on virtual host, location, and generic headers, it’s quite likely that for feng we can reduce this to a tighter subset of conditions.

What we already have some small predisposition for is per-virtualhost settings, which are handled with an array (right now a single entry) of specific configuration structures, each of which is initialised first with the default value of the configuration and then overridden with the loaded configuration, and then support for some global non-replaceable settings. How does that fare with an INI-like configuration file? Well, to me it’s quite easy to think of it in this terms:

[global]
user = feng
group = feng
logdir = /var/log/feng
errorlog = error.log
sctp = on
listen = 0.0.0.0:554 localhost:8554

[default]
accesslog = access.log

[localhost]
accesslog =
accesslog_syslog = on

[127.0.0.1]
alias = localhost

[my.vhost.tld]
accesslog = my_access.log

[his.vhost.tld]
accesslog = /var/log/feng/another_access.log

This obviously is just a quick draft of how it could be achieved and does not mean that it should be achieved this way at all; but it’s just to say that maybe we should be looking into some alternative, even though keeping syntax-compatibility with lighttpd is a nice feature, it shouldn’t condition the extra complexity we’re currently seeing!

Patrick Lauer: Configuring Portage

Patrick Lauer (bonsaikitten) — Mon, 16 Nov 2009 15:29:32 +0000

Few people take the time to actually read through the documentation, but if you have some time to spare "man make.conf" is a great read.
For example you can pre-set some CLI options like --ask or --verbose in EMERGE_DEFAULT_OPTS so you never have to type them again. Especially the FEATURES variable has some interesting bits:

buildpkg builds packages of everything
buildsyspkg builds only packages of the system set, which is awesome for recovery and doesn't take much space.

keepwork keeps the $WORKDIR and can be quite useful for debugging purposes (but not for general use)
noclean leaves even more there.
fail-clean is the opposite, it always wipes the build directories. Useful if you build on a small (but fast) disk or tmpfs.
installsources installs all the package sources to /usr/src/debug/, which can be used for debugging, but eats lots of space. Together with splitdebug it offers some really great debugging convenience.
test-fail-continue helps when you just want to have the tests run for logging purposes, but don't want the package to not be installed if tests fail. Most people won't need this.

split-elog and split-log features are quite interesting if you do logging.

Logging can be very nice to have, and portage has lots of configuration options for it.
PORTAGE_ELOG_SYSTEM defines how the log data is sent, be it through syslog, email or just to a file. Or completely custom?
And you can do combinations like PORTAGE_ELOG_SYSTEM="mail:warn,error syslog:* save".
PORTAGE_ELOG_CLASSES defines what you want to log - warnings, errors, qa warnings, everything ... it's your choice.

Of course there are lots of other configuration options:
PORTAGE_NICENESS can be useful when you don't want portage to interfere with anything else.
PORTAGE_IONICE_COMMAND needs ionice (or an equivalent tool) and can be used to make the disk activity of portage a bit less distracting. Both features may increase the time needed to install things, but will make portage more benign so you can still do things while it runs.

Also you can change almost all directories - PORTDIR, DISTDIR, PKGDIR and so on. This allows you to make portage behave a lot more like you want it (unless the defaults satisfy you already ...)

Diego E. Pettenò: Virtualisation WTF once again.

Diego E. Pettenò (flameeyes) — Mon, 16 Nov 2009 10:36:27 +0000

To test some more RTSP clients I’ve been working to get more virtual machines available in my system; to do so I first extended the space available in my system by connecting one more half-a-terabyte hard drive (removing the DVD burner from Yamato), and then started again working on a proper init script for KVM/Qemu (as Pavel already asked me before, and provided me with an example).

Speaking about it, if somebody were to send my way an USB or FireWire DVD burner I’d be probably quite happy; while I have other three DVD burners around – iMac, MacBook Pro and Compaq laptop – having one on Yamato from time to time came out useful; not necessary, so wasting a SATA port for it was not really a good idea after all, but still useful.

I started writing a simple script before leaving for my vacation and extended it a bit more yesterday. But in line with the usual virtualisation woes the results aren’t excessively positive:

FreeBSD 8 pre-releases no longer seem to kernel panic when run in qemu (the last beta I tried did, the latest rc available does not); on the other hand it does seem to have problems with the default network (it works if started after boot but not at boot); it works fine with e1000;
NetBSD still is a desperate case: with qemu (and VDE) no network seem to work; e1000 is not even recognised, while the others end up timing out, silently or not; this is without ACPI enabled, if I do enable ACPI, no network card seems to be detected; with KVM, it freezes, no matter with or without ACPI, during boot up;
Pavel already suggested a method using socat and the monitor socket for qemu to shut down the VM cleanly; the shutdown request will cause the qemu or kvm instance to send the ACPI signal (if configured!) and then it would shut down cleanly… the problem is that the method requires socat, which is quite broken (even in the 2-beta branch).

Let me explain what the problem is with socat: its build system tries to identify the size of various POD types that are used by the code; to do so it uses some autoconf trickery, the -Werror switch and relies on pointer comparison to work with two POD types of the same size, even if different. Guess what? That’s no longer the case. A warning sign was already present: the code started failing some time ago when -Wall was added to the flags, so the ebuild strips it. Does that tell you something?

I looked into sanitizing the test; the proper solution would be to use run-test, rather than build-tests, for what I can see; but even if that’s possible, it’s quite intrusive and it breaks cross-compilation. So I went to look why the thing really needed to find the equivalents… and the result is that the code is definitely messy. It’s designed to work on pre-standard systems, and keep compatible with so many different operating systems that fixing the build system up is going to require quite a bit of code hacking as well.

It would be much easier if netcat supported handling of unix local sockets, but no implementation I have used seem to. My solution to this problem is to replace socat with something else; based on a scripting language, such as Perl so that’s as portable, and at the same time less prone to problems like those socat is facing now. I asked a few people to see if they can write up a replacement, hopefully this will bring us a decent replacement so we can kill that.

So if you’re interested in having a vm init script that works with Gentoo without having to deal with stuff like libvirt and so on, then you should probably find a way to coordinate all together and get a socat replacement done.

Patrick Lauer: HOWTO Radeon (opensource) + R700 + 3D / OpenGL

Patrick Lauer (bonsaikitten) — Sun, 15 Nov 2009 18:08:48 +0000

Finally I stopped slacking for long enough to fix a few bits of my desktop, and the results are grrrrrrreat.
Now I have (OpenGL!) full effects in KDE4 as opposed to the slightly less bouncy XRender-accelerated thingies before. Performance is pretty awesome (but then the HD4650 shouldn't even notice those few effects).
What you need:

~arch install (I'm not going to care to find out what minimal versions you need)
x11 overlay
a really recent kernel

And with really recent I mean "at least 2.6.32". At the time of writing that hasn't been released, so a 2.6.32-rc6 git-sources has to substitute for me. From what I've read you might have to disable framebuffer for things to work well, but as I'm usually seeing text mode for ~30 seconds every month I don't care enough to find out. I'm lazy!
In the kernel config you need to enable DRM and especially the radeon bits. Device Drivers -> Graphics -> Direct Rendering Manager is the "most important" bit there.
The following packages were suggested in a few places, I have no idea if that is the minimal set. But you'll have to unmask:

>=x11-libs/libdrm-9999
>=media-libs/mesa-9999
>=x11-base/xorg-server-9999
>=x11-proto/fixesproto-9999
>=x11-proto/xextproto-9999
>=x11-proto/xf86vidmodeproto-9999
>=x11-proto/renderproto-9999
>=x11-proto/recordproto-9999
>=x11-proto/inputproto-9999
>=x11-proto/xineramaproto-9999
>=x11-proto/bigreqsproto-9999
>=x11-proto/xf86driproto-9999
>=x11-proto/xf86dgaproto-9999
>=x11-proto/xcmiscproto-9999
>=x11-base/xorg-drivers-9999
>=x11-libs/libXext-9999
>=x11-libs/libXi-9999
>=x11-proto/xproto-9999
>=x11-libs/libX11-9999
>=x11-libs/libxcb-9999
>=x11-proto/xcb-proto-9999

Now go forth and rebuild all your shiny new packages.
If you managed to build that and reboot your new kernel things should look pretty much as before. The only "obvious" hints I've found to test are the output of glxinfo (has changed quite a bit) and that KDE4 allows me to use OpenGL now. And maybe the wobbly windows effect was a giveaway :)

I'm positively surprised that things have progressed this far, and I'm happy to finally be able to use more of my graphics card :)

EDIT: Seems that this is not the minimal set of packages and configuration needed. Some people suggested -9999 packages of mesa + libdrm + xf86-video-ati only. If that works even better :)

Kenneth Prugh: Eclipse with GTK+ 2.18

Kenneth Prugh (ken69267) — Sun, 15 Nov 2009 17:34:34 +0000

Lately I noticed Eclipse having some issues such as not being able to confirm certain dialogs or press certain buttons. It made Eclipse extremely annoying to use. Before I found the relatively easy fix, I was reduced to clicking the button and the pressing enter to move past the screen, not exactly a desirable scenario to perform every 5 minutes if for example your exporting jars from Eclipse.

The fix is pretty easy, just add GDK_NATIVE_WINDOWS=1 to Eclipse’s launch script.

For example, here’s my launch script:

File: /usr/local/bin/eclipse

#!/bin/sh
cd /home/ken/eclipse && GDK_NATIVE_WINDOWS=1 exec ./eclipse $@

Kenneth Prugh: The KDE adventure continues

Kenneth Prugh (ken69267) — Sat, 14 Nov 2009 00:19:20 +0000

So I’m still using KDE surprisingly, and actually liking it. Finally got most of my keybinds working so I can work efficiently. I found KDE’s ability to easily pass key presses to a specific window quite nifty, allowing me to easily map all my multimedia keys to work with XMMS.

I got around to installing kbluetooth yesterday and was absolutely shocked at the result. My bluetooth actually worked. This was extremely pleasant for me as I have been disappointed with bluetooth in Gentoo for a long time. I effortlessly was able to send a file over to my phone and it just worked after confirming on my phone’s end.

Still using Claws Mail for email for now until I find a better alternative one day. Kmail pulls in too many dependencies for my taste currently and it doesn’t seem to offer anything that would cause me to switch over from claws mail.

I have to say kwin’s “Present all windows” feature thats normally the upper left edge of the screen is extremely nifty. Reminds me a lot of OS X’s expose feature. Handy for when I have 50 terminals floating around and I don’t feel like alt-tabbing for the next 10 minutes searching for the correct terminal or whatever program I’m using.

Klipper has been causing some love/hate so far. While its history function is extremely nifty, I sometimes find myself copying something only to find I can’t paste it for whatever reason. I enabled the option to keep the selection/copy buffer synchronized and the annoyance seems to have disappeared for the most part.

Plasma has been a bit crashy on and off so far. Seems to be something to do with the notification area. I wouldn’t find it as annoying if my applications would rejoin the newly spawned panel instead of floating about on the workspace. NetworkManager, Opera, and Claws Mail being the most notorious for not rejoining the panel after it crashes. Of course, the ideal solution would be to fix the crashing all together. I haven’t figured out a reliable way to introduce the crash yet, so I’m hoping it will just go away on its own.

Gilles Dartiguelongue: Looking for a padawan

Gilles Dartiguelongue (eva) — Fri, 13 Nov 2009 23:58:33 +0000

http://www.gentoo.org/proj/en/devrel/handbook/handbook.xml?part=1&chap=2

Title says it all. It's pretty obvious that gnome team can't currently keep up with the income of new bugs (especially a lot of unexpected 2.26 bugs) and I keep being split between my gnome duties and maintenance of various other stuff (notably freedesktop that no-one seems to care about these days). So I need one, two or more guys/gals that want to get their hands a bit dirty. If you feel up to it, just come and say hello on #gentoo-desktop, if I'm not around, probably other gnome herd members will be waiting for you .

Original post blogged on b2evolution.

Doug Goldstein: NVIDIA legacy drivers update

Doug Goldstein (cardoe) — Fri, 13 Nov 2009 20:57:42 +0000

As I previously noted, the 96.x.y and 173.x.y series had not seen any updates yet for xorg-server 1.7 compatibility, however today that has changed. They both saw updates late last night from NVIDIA and now those drivers are available in the Gentoo tree so feel free to give them a try.

Patrick Lauer: The OOM Killer (and how to make it less annoying)

Patrick Lauer (bonsaikitten) — Fri, 13 Nov 2009 12:20:59 +0000

The linux kernel has lots of complexity in memory management. Swap allows to go beyond the size of real memory to allow applications to use "more". But still, at some point, you might exhaust all available memory.

The next application that requests memory (usually through malloc) will cause the kernel some trouble. It can either deny the request (which often causes hilarious results in the application) or free some memory somehow. (About the hilarity: Many coders assume that a malloc will always succeed. If it doesn't you'll get interesting misbehaviour like segmentation faults. Lots of fun to debug ...)

So, how does the kernel free memory? It can't just ask some other processes to surrender some. But it can terminate processes! It's a terminally stupid idea, but it's so stupid that it often works. And the handler for that is, obviously, the out-of-memory killer.
There's a very nice bit of information hidden in /proc to tell you what the oom-killer would do if it had to run now.

/proc/$pid/oom_score

contains the current value of the process with PID $pid. You could just compare them and see who is good and who is bad. And you can adjust it - a rarely used protection, but it might just help the oom-killer to act more sanely and less psychotic.

/proc/$pid/oom_adj

That's a numerical value used as a multiplier. Valid values are in the range -16 to +15, plus the special value -17, which disables oom-killing altogether for this process. The heuristic is quite complex, to quote:

The process to be killed in an out-of-memory situation is selected among all others
based on its badness score. This value equals the original memory size of the process
and is then updated according to its CPU time (utime + stime) and the
run time (uptime - start time). The longer it runs the smaller is the score.
Badness score is divided by the square root of the CPU time and then by
the double square root of the run time.
Swapped out tasks are killed first. Half of each child's memory size is added to
the parent's score if they do not share the same memory. Thus forking servers
are the prime candidates to be killed. Having only one 'hungry' child will make
parent less preferable than the child.

On some systems you might not ever want to have the oom-killer strike. It's just a hilariously bad idea to kill random processes. And you can even disable it:

The sysctl vm.overcommit_memory variable (also represented in /proc/sys/vm/overcommit_memory ) defines the behaviour. To summarize: 0 is default, where the kernel uses some heuristics and allows allocating more memory than available (which is what can trigger the nice OOM assassin) 1 always allows overcommit. The documentation is a bit sparse, but it seems to be tuned by vm.overcommit_ratio, which gives a percentage to overcommit (unless I misread that). And finally a value of 2 disables overcommitting and limits application memory to the size of (swap + ram*ratio). This means that worst case you'll disallow a request when there's still physical memory available, but you'll never have to trigger Mr.OOM-Killer.

What is best? That depends on what you do and how you want things to fail. overcommit_memory = 2 will cause memory allocation failures, but your machine will always be "alive". overcommit_memory = 0 might allow to allocate more memory, but you risk getting any process killed by oom. Sucks to have sshd killed on a server - maybe it's not the best idea to have a psychotic process assassin? But it's your choice, so do what you want to do :)

Josh Saddler: November Xfce desktop

Josh Saddler (nightmorph) — Thu, 12 Nov 2009 19:23:23 +0000

Decided I'd shake things up a bit this month, after keeping the same look for nearly three straight months. Thus, I present:

icons: Area o.43
gtk+: Rele (Rezlooks engine)
xfwm4: Rezlooks-gtk (yes, it is confusingly named)
background: rassilon

It's grungy, but rather sleek. Surprisingly easy on the eyes, too. The lighter elements of the Rele gtk+ theme aren't overpoweringly white, but are just light enough to provide a decent contrast to the generally darker Area icons.

There's also an uncluttered version here.

I've been looking to assemble themes that are grungy, and themes that are warmer-yet-wintry. I like winter. I still have some hope that these 80 degree weeks will come to an end soon. We're almost to the middle of November. Surely we'll see gray sky, cool breezes, and maybe even rain here in SoCal at some point, right? Right? Well, if not, I can at least put it on my desktop.

Original post from Planet Gentoo.

Alex Alexander: how-to: keep your kde 3.5 after it’s removed from gentoo’s tree, using the kde-sunset overlay

Alex Alexander (wired) — Wed, 11 Nov 2009 23:31:51 +0000

As most of you know, KDE 3.5 is getting off the Gentoo train for various reasons mentioned elsewhere (in short: security, lack of upstream interest).

Some people are still using it though and they have been asking how they can keep it on their system, without emerge screaming each time they try to update world.

I’m writing this post to guide those people (you? ) on how they can achieve that.

1. Adding the kde-sunset overlay
Perhaps the most important thing you need to remember is that the ebuilds will be completely removed from the tree, so you need to add an overlay called kde-sunset to portage which contains a copy of most of them.

To add the overlay you need to have layman with git USE flag enabled:

USE="git" emerge -av layman

make sure you add the git USE flag in your package.use or make.conf

you can then use layman to install the overlay:

layman -f layman -a kde-sunset

if this is your first time using layman, you’ll have to add the following line @ the end of your make.conf:

source /usr/local/portage/layman/make.conf

you can keep the overlay updated by running:

layman -s kde-sunset

2. KDE 3.5 is masked (this is necessary only while KDE 3.5 is still in tree)
Now we have the overlay, but until KDE 3.5 is completely wiped off the tree, there’s a mask to warn users about it.
Portage will scream about this mask each time you try to emerge so you need to unmask KDE 3.5 manually.

There are two (and a half) ways to do this:
a1) if your package.unmask is a folder, symlink the unmask file from kde-sunset to /etc/portage/package.unmask/

ln -s /usr/local/portage/layman/kde-sunset/Documentation/package.unmask/kde-3.5 /etc/portage/package.unmask/kde-3.5

a2) if your package.unmask is not a folder you can append the file (but you’ll have to update it manually)

cat /usr/local/portage/layman/kde-sunset/Documentation/package.unmask/kde-3.5 >> /etc/portage/package.unmask

b) if you don’t like all that, you can emerge autounmask

emerge -av autounmask

and ask it to unmask stuff for you – note that autounmask doesn’t like :slot and will only work with -version

autounmask kde-meta-3.5

3. I don’t want KDE 4 (yet)
So all is great now but portage wants to install KDE 4 when you emerge world.
This is happening because KDE 4 went stable recently and portage thinks you want to upgrade (you should btw ).
To fix this one we need to tell portage that we actually want the 3.5 version of KDE and we don’t care about 4.

we need to edit /var/lib/portage/world and add a version (or a slot) to every kde 3.5 app we have in there.

* be careful with this file *

for example, lets say that you installed kde 3.5 using the kde-meta ebuild.
if you open /var/lib/portage/world you’ll find a line saying

kde-base/kde-meta

you need to add :3.5 which is the 3.5 slot, or -3.5.10 which is the version (or both, version first) at the end. if you add the version, you’ll have to prepend a “=” as well.

the line should now read:

kde-base/kde-meta:3.5

do this for each KDE 3.5 app you have in the world file. If you’re unsure of the slot/version, use eix packagename to find it out.

4. All systems go

emerge -avDuN world

^^ this should now be clean of any KDE 4 traces and mask warnings

If you have any issues or are interested in maintaining kde-sunset, you may visit us over @ #gentoo-kde in freenode’s IRC network or drop us an email at kde _at_ gentoo _dot_ org. We’ll do our best to help you

Maybe after reading this post your KDE 3 installation will last a bit longer

Enjoy and see you w/ KDE 4 soon

Josh Saddler: Tabu Audio Player

Josh Saddler (nightmorph) — Wed, 11 Nov 2009 14:50:05 +0000

Even though I'm currently sick with H1N1, also known as swine flu, this morning I was feeling well enough to write an ebuild for an interesting media app I found: Tabu Audio Player. It's an interesting player -- while it still needs some translation work into English, it's simple and has an appealing UI drawn by Cairo.

It had only a single configure option, "debug," and a very short list of dependencies, so I figured it'd be a simple ebuild to write, right?

Wrong! Turns out that after a half-hours' worth of poking at configure.ac, the package's check for --disable-debug/--enable-debug was completely broken. If you explicitly passed --disable-debug, like "-debug" in IUSE, then it would enable the debug build every time. Thanks to rej and a3li on IRC for nailing this problem down; they were really helpful.

a3li also shared his solution for the same problem in one of his packages, so I used it in my ebuild to ensure that "debug" works properly as a USE variable.

Meanwhile, I sent a bug report to upstream asking for a smarter debug check. I also asked for CFLAGS="-02" to be removed from Makefile.am, that way folks are free to use their own -O levels without having to resort to using sed on the Makefile, as I had to in the ebuild.

Speaking of which: I have an ebuild for Tabu 2.1 waiting for you in my devspace, if you'd like to try it out.

Original post from Planet Gentoo.

Patrick Lauer: The mistery of swappiness

Patrick Lauer (bonsaikitten) — Tue, 10 Nov 2009 19:18:46 +0000

For the longest time operating systems have been able to handle swap. In short swap extends physical memory with slow diskspace so that applications can use more memory than there is available.
On most unix systems the swap is in a dedicated partition because that has the lowest overhead. Plus you don't risk running out of diskspace when you want to swap, so things are quite predictable and nice. Linux has a very nice knob you can turn to affect the swap policy. It will not avoid swapping (in some situations you will have to), but it will affect how and when swap is used. That knob is /proc/sys/vm/swappiness.

The kernel default is a value of 60. The value can be between 0 and 100 and is effectively a percentage. It is used roughly in the following way:
If all available memory is exhausted (application memory, buffers and filesystem cache) and any memory allocation is requested the kernel needs to free a few pages of memory. It can either swap out application memory or drop some filesystem cache. The "swappiness" knob affects the probability which one is chosen.
This means that at a swappiness of 0 the kernel will try to never swap out a process, and at 100 it will try to always swap out processes and keep the filesystem cache intact. So with the default, if you use more than ca. 40% of your memory for applications and the rest is used as filesystem cache it will already start swapping a bit. The hilarious result is that you may up swapping a lot with lots of memory left - think of a machine with 64GB RAM! If you try to use 32G memory you'll be in swap hell.
That default might have been good with machines with less than 256MB RAM, but with current desktops and servers it is usually not optimal.
Now you might be tempted to tune it down to 0. Avoid swap. Swap is slow. All is good?
Not quite. At 0 your machine will try to avoid swapping until the last moment. Then it will have killed all filesystem cache (so every file operation will hit the disks) and in addition to that you start swapping like a madman. The result is usually a "swap storm" that hits very sudden. At the point where you might need some performance your machine doesn't provide it and might just be unresponsive to your input for a few minutes.
The other end (a value near 100) might make sense for a file server, but then it might be cheaper to just not run extra services on a machine that is very loaded already. I don't really see a usecase for a swappiness of 100 except maybe on machines that are very memory-limited.
On my desktop I've found a swappiness of 10-20 to be the sweet spot. This means that when 80%+ of memory is used by applications the machine will start swapping, but it's a more gradual hit and not an instant kill. And because there's still some filesystem cache the responsiveness for starting new processes (like a login shell ;) ) is still high enough to allow recovery from this pessimal system state.
Still your goal for optimal performance should be to avoid swapping. Disk access is slower than RAM by a factor of 1000 or more!
I've seen servers achieve roughly double the throughput with the right swappiness value - it can avoid an expensive hardware upgrade. Of course that's not all the tuning advice I have, so if you wish to discuss that feel free to send me a mail and maybe I can prove to you that Gentoo is the fastest penguin out there ...

Maybe I should discuss the OOM killer too - most people have seen it, but few know who it is and why he goes killing processes.

Christian Faulhammer: Allgemeiner Deutscher Autowahnsinn

Christian Faulhammer (fauli) — Tue, 10 Nov 2009 18:27:23 +0000

Der ADAC ist schon ein lustiger Verein. Bezeichnet sich selbst als größter Fahrradfahrerclub, da als größter Verein Deutschlands eine entsprechende Menge von potenziellen Fahrradfahrern vorhanden ist. Mit derselben Begründung wäre auch eine Selbstbezeichnung als Deutschlands größte Alkoholiker- oder Prostatakrebsvereinigung denkbar. Der Schein des selbstlosen Einsatzes für die Menschheit ist ebenso ein geschicktes Marketinginstrument, denn der ADAC ist nichts anderes als ein Wirtschaftsunternehmen. Gegen Geldverdienen ist prinzipiell nichts einzuwenden, aber wenn es auf so verlogene Weise geschieht wie bei diesem Automobilclub geschieht stinkt es.

Zwei Beispiele: Zum einen die »Gelben Engel«. Verteilen so uneigennützig kleine Geschenke an im Stau steckende Menschen. Wer genug Geld bezahlt, kann seine Produkte als eben genau diese Geschenke an den Mann bringen, in Form von Produktmustern oder verdeckter Werbung. Zum anderen das eigenartige Geschäftsgebahren. Zu Beginn meiner Volljährigkeit war ich Mitglied des ADAC, bis eines Tages der Postmann eine Nachnahmesendung brachte, die ich nicht bestellt hatte. Nach der Verweigerung der Annahme frage ich beim ADAC nach, was es damit auf sich hätte. Antwort: »Das ist eine Versicherung, die wir Ihnen einfach mal anbieten wollen.« Vielleicht gibt es Menschen, die unbesehen eine unbestellte Nachnahmesendung an der Haustür bezahlen, die hätten dann eine ungewollte Versicherung. Ähnlich verfuhr der ADAC mit Atlanten. Bei Nichtgefallen soll man sich selber um die Rücksendung kümmern, andernfalls bezahlen. Für mich der Grund aus diesem Verein auszutreten.

Wer meint, ohne ADAC bei einer Panne aufgeschmissen zu sein, sollte mal einen Blick in seinen Pkw-Versicherungsvertrag werfen. Viele enthalten eine Mobilitätsgarantie, die genau diese Leistungen abdeckt, man besitzt also hier eventuell eine Doppelabdeckung. Krankenrücktransporte aus dem Ausland und ähnliche Leistungen bei der Plus-Mitgliedschaft decken andere Anbieter günstiger ab. Sei es die eigene Krankenversicherung mit einem kleinen Zusatzobulus oder separate Anbieter wie R+V bei jeder genossenschaftlichen Bank. Wer den Maltesern Geld spendet, kriegt diese Leistung sowieso obendrauf.

Wegen der stark autozentrierten und umweltpolitisch fragwürdigen Ansichten ist es sowieso ratsam, sich von diesem rückwärtsgewandten Club fernzuhalten.

Alex Alexander: gentoo-user-el mailing-list – for all the greeks out there :)

Alex Alexander (wired) — Tue, 10 Nov 2009 14:17:01 +0000

Starting today, Greek Gentoo users have their own mailing list to discuss stuff and ask questions: gentoo-user-el.

For more info on how to subscribe, please visit http://www.gentoo.org/main/en/lists.xml

The list is not mentioned there yet, but you can use it normally.

[the rest of this message is in greek]

Θέλετε να συζητήσετε για το αγαπημένο σας Gentoo στα ελληνικά αλλά δεν βρίσκετε κάποια official mailing list?

Πλέον μπορείτε να χρησιμοποιείτε την νέα λίστα gentoo-user-el, που δημιουργήθηκε για να καλύψει αυτό ακριβώς το κενό.

Για να γραφτείτε, αρκεί να στείλετε ένα κενό e-mail στην διεύθυνση gentoo-user-el+subscribe _at_ lists.gentoo.org και να ακολουθήσετε τις οδηγίες.

Μπορείτε να συνομιλήσετε με άλλους χρήστες του Gentoo αλλά και με Gentoo Developers (είμαστε 6 Έλληνες) και να λύσετε κάθε πρόβλημα και απορία σας

Για περισσότερες πληροφορίες σχετικά με τις λίστες του Gentoo μπορείτε να επισκευτείτε την σελίδα http://www.gentoo.org/main/en/lists.xml

Η λίστα δεν αναφέρεται ακόμα σε αυτήν την σελίδα (πρέπει να ενημερωθεί από το κατάλληλο team), αλλά εσείς μπορείτε να γραφτείτε και να την χρησιμοποιήσετε κανονικά.

Επίσης μπορείτε να διαβάσετε το περιεχόμενο της λίστας πηγαίνοντας στην διεύθυνση http://archives.gentoo.org/gentoo-user-el/

Όπως βλέπετε εγώ έκανα την αρχή: http://archives.gentoo.org/gentoo-user-el/msg_4eb9364bded3280c9685356b9e0445d0.xml

Εάν είστε από αυτούς που προτιμούν πιο άμεση επικοινωνία, μπορείτε να επισκευτείτε το κανάλι #gentoo-el στο freenode irc network: http://java.freenode.net/index.php?channel=gentoo-el

Τα λέμε εκεί

Diego E. Pettenò: Vacation time for me!

Diego E. Pettenò (flameeyes) — Tue, 10 Nov 2009 07:47:12 +0000

Just wanted everybody to note that I have a flight to catch for London today at lunch time; will be away till Sunday and will come back for all kind of work on Monday, so if you write me in the mean time I won’t be around, most likely.

Kenneth Prugh: Testing the KDE4 waters

Kenneth Prugh (ken69267) — Tue, 10 Nov 2009 03:21:28 +0000

So after some frustrations with GNOME and various applications flat out breaking, I decided I might as well give KDE4 another chance to redeem itself. Installation was fairly easy, but I was plagued by a problem from the start. I had a dock like application of unknown origin that was starting with my new KDE session. After a lot of hunting down I discovered it wasn’t a dock at all, but actually gnome-do. I had completely forgotten that gnome-do could look like a fancy dock. After sorting that out I decided to keep the dock at the top of the screen at the smallest size which autohides itself when needed.

Next up was getting all those keybinds and shortcuts sorted out. My suspend and lock laptop keys weren’t working nor was my volume keys. This was somewhat disappointing that it wasn’t automagically working, but I managed to mostly solve my issues. Input Actions under system preferences let me do the bulk of my configuration. Volume Up and Volume Down keys were recognized by KDE, so I simply bound them to the commands amixer set Master 5%+ and amixer set Master 5%+. I was surprised to find out that my suspend key was also recognized by KDE, but I needed a way to actually make it suspend. After poking around with qdbus I discovered it was relatively simple. All what was needed was binding the key to this command: /usr/bin/qdbus --system org.freedesktop.DeviceKit.Power /org/freedesktop/DeviceKit/Power org.freedesktop.DeviceKit.Power.Suspend. Relatively easy after poking around the qdbusviewer which let me visually stumble around dbus commands.

I then proceeded to try to bind my lock screen key, but KDE complained that the key was “unsupported” or something similar. Well, it was time to finally figure out all that acpid magic. After reading the man page and a bit of googling, I banged out a relatively simple script to lock the screen for me.

/etc/acpi/events/lock:

event=ibm/hotkey HKEY 00000080 00001002

action=/etc/acpi/actions/lock.sh

/etc/acpi/actions/lock.sh:

#!/bin/sh

export DISPLAY=":0.0"

su ken -c "/usr/bin/qdbus org.kde.krunner /ScreenSaver Lock"

logger "acpi locked screen"

Probably not the best way of doing it, but it works for now so I’m relatively happy.

Didn’t need to do much for adjusting urxvt for KDE4, just added transparency to my existing config so it would fit in. Currently using claws-mail but might try out kmail later this week. I only needed to emerge x11-themes/gtk-engines-qt to make GTK not look so hideous that the default it without styling. Would be nice if I could get some kind of on screen display for when I change the brightness with my laptop keys, I’ll have to look into that a bit later.

Thats all I can remember for now, will need to explore KDE4 a bit more to see if it can replace GNOME full time.

Steve Dibb: my hardware closet

Steve Dibb (beandog) — Mon, 09 Nov 2009 18:15:07 +0000

I finally called and cancelled my Comcast cable TV subscription this weekend. I've been meaning to do it forever. I can't remember the last time I was even watching TV on a regular basis, though I think it was probably around 6 months or so. With my media center up and running so well, I generally just watch something from there or rent it on Netflix these days.

Now, the question is, what to do with all the hardware? I have three (yes, THREE) Tivos with unlimited subscriptions. Two of them are the klunky one-tuner first generation of the Series2 boxes, but the third is an HD Tivo, which is very nice. I could sell them, but considering the price I shelled out (for the HD one, at least, savvy consumerism got me the first two for real cheap ... under $50 each) I hate to part with it. I keep thinking I'll get cable again some day, and by that year sometime in the future, I'll pat myself proudly on the back and say, "way to hang on to a piece of hardware for so long! Now go get the compressed air."

I'm cursed with the pack rat mentality, though. I hang onto stuff far too long in the oft chance that someday, I *might* need it. On Saturday, I woke up a little early, and as is normally the weekend routine, I get the feeling that I must turn my entire world around by 11 a.m. This time, it was the closet in my living room which has the distinction of dedicating 85% of its storage space to electronics that I might need sometime before the next century. The other 15% is a mix between my puzzles, dust bunnies, air, movie posters, and movie t-shirts. I have a red t-shirt promoting "Searching for Bobby Fischer", I kid you not... I'll even take pictures to prove it.

I swear I've been carrying this collection of cables and equipment for at least ten years or so, probably ever since I haven't been living at home. It never really bothered me that I don't use most of the technology anymore (or ever, really), you just never know when you're going to need a floppy IDE cable. Really! I'm all about being prepared, but for the wrong circumstances. I can just see the day when I'll be someone's hero for helping them be able to flash the BIOS on their 15-year old Dell desktop. I still have the floppies to put it on, too.

So, this weekend was the closet's demise. I grabbed a bunch of plastic bags from the kitchen (the bachelor's preferred method of storage and transportation for all things non-essential) and started filling them up with stuff. My method of deciding what to keep and what to throw out was pretty simple: if I couldn't remember the last time I used it, it gets tossed. Normally it could be times like these that a selective memory can cause problems down the road, but I had so much junk anyway, I don't think it'll cause a problem. Besides, the memory problems go both ways -- when I do need a new cable or piece of hardware, I can't get mad at myself because I'll have forgotten I used to own one anyway.

All in all, I filled up something like eight to twelve bags of stuff. I don't remember how many it was, but I do recall that when I took it to the thrift store and started unloading, I had so much stuff that it took two guys to carry it all away, and one of them kept laughing because the stream was endless. I think most of it was cables. There were some notable things that I'd been hanging onto for a long time, "just in case," some of which were: my old Gamecube, an 8 GB IDE harddrive, my old home-theater-in-a-box speakers (which were about as powerful and had as much wattage as two light bulbs), three PCMCIA wireless cards, a few wireless USB dongles, and a slew of PCI slot brackets. I elected to hold onto the floppy drive -- it was a sound investment in 1990, and it's a sound investment today.

That's not really the interesting part, though. There is still all the stuff that I decided to keep because it held some kind of value, but I don't have the energy or drive to see them through the process of being sold on the secondhand market. Nothing makes a closet grow quite like a pack rat mentality combined with the laziness of avoiding the hassle of making spare change. I've still got my Tivos, for instance. There's an old (now) AMD Athlon64 desktop that is pretty nice -- top of the line of about 5 years ago. Runs really quiet, too. Then there's a used Gateway desktop I remember I bought on Craigslist for some reason a while ago, and I've never used. I'm holding onto that one because it came with Windows, and I might someday want *another* Windows XP Home key, so I can just use that one. It probably wouldn't work, anyway, but hey ... hope lingers longer than logic.

I almost dragged off my original Xbox to the thrift store, too. It hasn't been as fun as I'd hoped it would have been, and having one console (PS2) with corded controllers is enough for me. Plus it's a bit wheezy. Probably just needs a new fan, or harddrive. Dunno. I also decided to keep all my TV tuner cards, even though I never use those either ... especially now without a cable subscription. One of them was the Plextor external USB one that has MPEG4 hardware encoding (very nice). I think my brother wanted that one. Maybe it'll be a nice holiday surprise, as in, I'll be surprised if I manage to make it to the post office before Christmas 2010 to mail it off.

Oh yah, and there's an MSI Mini-ITX motherboard with an Intel Atom that I'll probably never try to revive, but I hate to donate it since I still think I could get at least $20 for it somewhere. Then there's my new Motorola RAZR phone that I used for about a week before I switched to Verizon. That's gotta be worth something. I've also got two MP3 players, an iPod Nano and a Sansa something, each 4 GB ... too small for me to do anything with ... but I'll hang onto them just because. I think I still have a portable Sony Walkman cassette player, too.

In actuality, I'd like to get rid of all of the stuff, provided I can do it through a simple way ... meaning I don't have to do any work, and non-creepy people flock to my house with cash in hand. I doubt it'd happen, but hey, if you live near Salt Lake and are interested ... drop me a line. That's about as proactive as I'm gonna get about it. If you ever need your BIOS flashed, too, I could probably do that as well.

Diego E. Pettenò: Can we be not ready for a technology?

Diego E. Pettenò (flameeyes) — Sun, 08 Nov 2009 20:40:35 +0000

İsmail is definitely finding me some topics to write about lately… this time it was in relation to a tweet of mine ranting on about Wave’s futility, I think I should elaborate a bit about this topic.

Regarding the Wave rant, which adds to my first impression posted a few weeks ago, I think things are starting to go downhill. From one side, more and more people started having Google Wave so you can find people to talk with, from the other, of the Waves I received, only one was actually interesting (but still nothing that makes me feel like Wave was useful), the rest falls into two categories: from one side, you get the ping tests, which I admit I also caused – because obviously the first thing you do in something like Wave is pinging somebody you feel comfortable to talk with – and on the other hand I had three different waves of people… discussing Wave itself.

And you know that there is a problem when the medium is mostly used to discuss itself.

And here is where me and İsmail diverge: for him the problem is that “we’re not ready” for the Wave technology; myself, I think that the phrase “we’re not ready” only can come out of a sci-fi book, and that there is something wrong with the technology if people don’t seem to find a reason to use it at all. But I agree with him when he says that some technologies, like Twitter, would have looked definitely silly and out of place a few years ago. I agree because we have had a perfect example that is not hypothetical at all.

You obviously all do know Apple’s Dashboard, from which even the idea of Plasma for KDE seems to have come from, and from which Microsoft seemingly borrowed heavily for the Vista and Win7 desktop. Do you think Apple was the first to think about that stuff? Think again.

It was 1997, and Microsoft released Internet Explorer 4, showing off the Active Desktop … probably one of the biggest failures in their long-running career. The underlying idea is not far at all from that of Apple’s “revolutionary” Dashboard: pieces of web pages to put on your desktop. At the same time. Microsoft released one of their first free development kits: Visual Basic 5 Control Creation Edition (VB5CCE) that allowed you to learn their VB language, and while you couldn’t compile applications to redistribute, you could compile ActiveX controls, which could in turn be used by the Active Desktop page fragments. Yes, I did use VB5CCE; it was what let me make the jump from the good old QBasic to Windows “programming”.

So, if the whole concept of Dashboard (and Plasma, and so on) makes people so happy now, why did it fail at the time? Well, to use İsmail’s words “we weren’t ready for it”; or to use mine, the infrastructure wasn’t ready. At the time, lots of users were still not connected to any network, especially outside of the US; staying connected costed, a lot, and bandwidth was limited, as were the resources of the computers. Those of us (me included) who at the time had no Internet connection at all, were feeling deprived of resources for something totally useless for them; those who had dial-up Internet connections would feel their bandwidth be eaten up by something they probably didn’t care enough about.

Who was at fault here? Us for not wanting such nonsense running on our already underpowered computers, or Microsoft for wanting to push out a technology without proper infrastructure support? Given the way Apple was acclaimed when they brought Dashboard to their computers, I’d say the latter, and they actually paid the price of pushing something out a few years too early. Timing might not be everything, but it’s definitely something.

Zhang Le: Update on building mips64el cross toolchain

Zhang Le (r0bertz) — Sun, 08 Nov 2009 08:48:00 +0000

1. git clone git://www.gentoo-cn.org/var/git/loongson.git

2. Don't include loongson overlay's directory directly in your PORTDIR_OVERLAY. But in your own overlay, like /usr/local/portage, create symlinks pointing to sys-devel/ and sys-libs/glibc in loongson overlay. This is because you may not want to install packages from loongson overlay in your host machine. Also you need to make sure your own overlay is the first overlay containing binutils/gcc/glibc in your PORTDIR_OVERLAYS list. You may check the value of this list using command:

portageq envvar PORTDIR_OVERLAY

3. Then, just run crossdev -t mips64el-unknown-linux-gnu. This command installed the following components on my host machine:

linux-headers-2.6.27-r2 from portage.
binutils-2.19.1-r1 from loongson overlay.
gcc-4.4.2 from portage. The gcc in loongson overlay currently is just a symlink to portage gcc.
glibc-2.9_p2009042 from loongson overlay. However if you build the toolchain now, glibc-2.10.1 will be installed instead, I just updated it.

Steve Dibb: packages website going offline for a while

Steve Dibb (beandog) — Sat, 07 Nov 2009 16:35:07 +0000

I've been on a roll to clean house lately, and part of that is simplifying my hardware setup. One thing that needs to be ripped out completely is my old server, which is getting to be a real pain to maintain. Mostly it's just my personal stuff on there, but the ebuild packages website is also running on there right now. Between now and Tuesday, I'm going to take it down since I'm going to be rearranging my hardware setup anyway. I'm not going to bring the old website back online, either. The code for the new one is almost complete, and it will use a lot less resources. There's gonna bet lots of cool stuff on the new one: better feeds, simpler interface, new domain name and hopefully a new design as well. Oh, and the scripts aren't dependent upon portage anymore, which is the real crutch right now. I have to run an old version of portage (2.1.4.5) that isn't even in the tree anymore, and it's making updates painful or impossible.

The new site will also run on my dedicated Linode, where I think I've finally correctly managed the apache issues, so that means there will be less arbitrary downtime as I screw around with my box here at home. I really hate running servers at home that other people are dependent on, because I like the freedom to change things around without affecting anyone. Right now, the old site is so CPU intensive, that I can't move it over to the VPS.

The code for the new site is much cleaner. The entire thing is rewritten in OOP classes to access the portage tree, which makes my job incredibly easier. Not to mention it's a lot faster. It'll still be a bit before I get it online, but killing it will inspire me to push it along. I'm tired of having this thing limp around when it's just a dead albatross around my neck right now. So, farewell. The new one will be better.

Donnie Berkholz: links for 2009-11-06

Donnie Berkholz (dberkholz) — Sat, 07 Nov 2009 01:56:11 +0000

The trough of disillusionment for Ubuntu?

“The Hype Cycle describes the way that new technologies and projects are perceived over time, if they do a good job of handling themselves, going from a technology trigger, inflated expectations, disillusionment, enlightenment, before arriving at “the plateau of productivity” – a state where there is no more hype and the new technology is simply a normal part of our lives.”

The perception over the past few years that Gentoo is dying is in reality Gentoo’s arrival at the plateau of productivity. Hype has gone away and remaining is a distribution with a true niche that fits into the broader Linux ecosystem.

(tags: gentoo communication)

Tagged: communication, gentoo, greatness, pr