 Welcome to Gentoo Universe, an aggregation of weblog articles on all topics written by Gentoo developers. For a more refined aggregation of Gentoo-related topics only, you might be interested in Planet Gentoo.
August 14, 2009
August 13, 2009
After talking with Ben (yngwin), I found that there really wasn't anyone working on documentation related to LXDE inside of Gentoo. So, I decided that I would write a HOWTO for getting it installed and configured. I finished the document this morning, and uploaded it to my Developer webspace. You may see a working copy of the document there, and if you want to see the xml, you have two options. Firstly, when looking at the finished copy, you append the following to the end of the URL:
?passthru=1
making the full URL:
http://dev.gentoo.org/~nathanzachary/documentation/lxde_1.0.xml?passthru=1
and that will show you the XML. Secondly, you can view Bug 281345, and click on the attachment. Hopefully the documentation team will pick up the guide in the near future, and commit it. The only holdup that I can foresee is that LXDE is still available only through the testing (~arch) branch.
|:| Zach |:|
|
I have made several changes to the Openbox HOWTO. There were many typographical errors that I didn't catch the first time around, and package links that weren't added. Here's a full list of the updates for version 1.4:
- In code listing 2.5, changed the $ to # as the operation requires root actions.
- Added a note to the 2.5 listing about becoming root before the command.
- In code listing 2.6, fixed the typographical error (7gt; instead of gt;).
- In code listing 2.6, made the
- In code listing 2.8, fixed the typographical error (extra > in closing tag).
- In code listing 2.8, fixed the typographical error (missing closing ").
- Added a link to the package information for conky before code listing 2.10.
- Added a link to the package information for feh after code listing 2.10.
- Added a link to the package information for nitrogen after code listing 2.10.
- Removed the library dependency bug reference for nitrogen.
- In terminals section, changed "customized" to "customised" for consistency.
- In file managers, fixed typographical error for Nautilus (a "bit" heavy).
If you would like to see the new document revisions before it gets committed to the official documentation repository, it is available on my Developer webspace. You may also view the XML for version 1.4 via Gentoo Bug 256693.
|:| Zach |:|
|
August 12, 2009
It is with sadness that we as Trustees bring forward this news that we have
recently received. Ferris Ellsworth McCormick, better known as fmccor, has
passed away unexpectedly on the 5th of August. His family does not wish to be
contacted. We have expressed our gratitude for his contributions on behalf of
the Community.
Ferris studied mathematics in college at Indiana University, graduating in 1968
with a Bachelor of Arts. Later he entered into the Law school at the University
of Michigan, earning his Juris Doctor degree in 1991.
He passed the bar in Michigan that same year and has continued to be an
actively certified Lawyer with the State of Michigan since then. He was also a
member of the Association for Computing Machinery (ACM).
Ferris joined Gentoo on April 16th 2004 as part of the sparc team and improved
sparc support for the entire open source community. Within a year he also
joined the Developer Relations team to help with mediation of any issues that
might come up between people. As time went on Ferris continued to expand and
assist Gentoo in many ways including assisting with the User Relations team and
growing to become the Strategic Manager of the sparc project. Finally, he
became a trustee and the Vice President of the Foundation assisting in getting
the foundation back into good standing.
While it is too late to say in person, the Foundation would like to thank
Ferris once again for all that he did for both Gentoo and the Open source
community. He will be missed.
Please join the community in eulogizing Ferris in our forums here.
|
August 11, 2009
This is a quick note for anyone using compiz, that x11-wm/compiz-0.7.8-r3 will allow KDE-4.3.0 and that the KDE use flags were updated now that KDE-4 has become the "default" KDE version and that 3.5 is approaching its final days.
As such, the kde use flag will add support for KDE-4.X and the kde3 use flag will add support for KDE-3.5. So be sure to check your use flags for compiz.
I plan to move compiz-0.7.8-r3 from the overlay to the tree in a few hours.
Following my attempts to deal with bug 259715, I broke libcompizconfig again - bug 278146. Although I've masked libcompizconfig-0.8.2-r2 sometime ago, it was unmasked long enough to break the config files for enough users. If you still have ccsm / compiz failing for you, you need to downgrade to libcompizconfig-0.8.2 and to remove the contents of ~/.config/compiz/compizconfig/. I'm still working on removing the bundled iniparser from libcompizconfig.
|
August 10, 2009
LXappearance and icon themes (August 10, 2009, 23:24 UTC)
After having recently reinstalled Gentoo on my main production machine, I thought I would look into some theming to make things more aesthetically pleasing. I installed a bunch of GTK themes that I ended up not liking, so I got rid of them. I use Openbox with a bunch of LXDE applications installed to ease the process of customisation. One such application is LXappearance. Getting rid of the unwanted themes from the LXappearance menu wasn't all that difficult. I simply went to /usr/share/themes and removed the respective folders. However, I couldn't seem to get the unwanted icon themes to go away. If I'm not mistaken, icon themes are usually installed to /usr/share/icons. When I went to manually delete the icon theme folders, however, there were no such directories. Hmmmmmmmm...
Since searching the web didn't yield any significant results, I thought I would go to the source code and figure out just what happens when one installs an icon theme using LXappearance. In /usr/share/lxappearance there is a script called install-icon-theme.sh, and it contains the following line:
export XDG_DATA_HOME="$HOME/.local/share";
That lead me to check that respective directory. Bingo, there were my icon theme folders. I simply deleted the folders, and the respective icon theme choices were no longer present in LXappearance. I was simply excited as it was my first success of the day. 
|:| Zach |:|
|
PostBot test (August 10, 2009, 20:01 UTC)
Post from PostBot on my G1.
Nice app. I wonder if it will make me post more?
|
I’ve been playing around more with Linux Containers after my post about init scripts and I start to think they are quite near being working for Gentoo. I hope once I come back from my vacations to get them in the tree together with Tiziano.
Right now the problems we have are:
- the standard stage3 needs to be heavily tweaked or it’ll be a massacre when started;
- if I do set ttys in the configuration, at start time it moves me to the real tty1, which causes a domino effect with X11 that is annoying, although not critical;
- OpenRC needs to be tweaked to add support for Linux-Containers; there are quite a few things that could be eased up by having a working OpenRC that ignores some init scripts when running in containers; the code seems to be in
src/librc/librc.c (look for openvz) and should be easy to check whether we’re running on containers, by checking the running cgroup (/proc/self/cgroup);
- the current ebuild in Tiziano’s overlay creates a
/var/lib/lib directory and installs the lxc- binaries in /usr/bin, both of which shouldn’t happen in Gentoo once installed;
- running
rc shutdown inside the container will stop all the services properly, but will not kill init and thus not kill the vserver, I’m not sure why; running kill 1 also seems not to work, I have yet to check whether sending the kill signal from outside will properly shut down the rc inside, if yes, then it’ll be a good way to shut down the container.
Once I’ll be back and I’ll be working on the init scripts, they’ll be in a separate package, kinda like mysql’s, since what I have for now is slightly more complex, will add a few more standard locations (for instance they’ll use a /var/log/lxc directory that is not part of the standard install of lxc) and will require a couple of packages that are not part of lxc.
|
Booting up my productivity (August 10, 2009, 06:56 UTC)
So, I’ve lately not been blogging or generally doing anything other than being lazy. Now that the next semester of college is starting to ramp up in the near future I’ve decided to attempt to jump-start my productivity. The first step was updating my machines into a usable environment which meant clobbering portage blockers and such until I had my world fully updated to the latest ~amd64 and my developer chroot to the latest stable amd64. The latter was a bit more work, with tons of perl blockages and fetch restricted packages on the java side. All in all not too bad, after a series of
emerge -avuD world --keep-going; revdep-rebuild; dispatch-conf
the chroot was sane again and ready for developer work. Now I can stop slacking so much and help squish some amd64 bugs. (Also, why isn’t –keep-going default? Sigh, maybe I’ll just alias it along with nice and ionice.)
Besides working on Gentoo I’ll be ramping development back up on my two pet projects: GPytage and Zito.
GPytage is currently undergoing a near complete rewrite to support recursive folders and file structures under /etc/portage/. Currently reading in all the files and constructing the internal database is functional and so is a basic UI. Saving still needs to be reimplemented among a variety of other things. I plan to eventually redo all of the accelerator shortcuts into something more sane and to recode glade-based dialogs and windows into pure pygtk.
Zito is currently still in development and undergoing Internationalization refactoring. After that is done, some code tidying and perhaps UI changes are due. I’m still at a loss on how to actually package something like Zito being a java project. I know Ant can do it, but I’m still not exactly sure how to use Ant in the sense of coding a build and install file for it. Seems quite a pain setting up the XML file for Ant.
On a related note, I can say that I am fairly happy with bzr now. I used to be a large git supporter, but many git commands require extensive knowledge of syntax, flags to pass, and just isn’t as user friendly. Bzr I’ve found is very easy to work with and I have not had any problems with it so far. Most of my projects I’ve converted locally to bzr repositories. In my observation, Bzr knows what “the right thing to do” is most of the time and prevents most repository screwups.
|
August 09, 2009
The tree fasting has started (August 09, 2009, 19:25 UTC)
Today I finally went around writing a script that could help me with sending QA last rites, without using Evolution; this way, I was able to send out quite a few last rites before I went to have my vacations. It actually took me a bit of tinkering because my first try was using bash and sendmail to prepare the messages, and in particular to sign them. Since encoding my name properly is quite hard, I gave up and I now use mutt to send the stuff; unfortunately i was unable to find how to sign the messages with mutt and gpgme; if somebody can help me with that, it’s very welcome.
With the script at hand I then went on checking some of my older bugs to send some of them out; some bugs weren’t really correct before (caused by the older tinderbox attempts, which used --buildpkg) and I fixed them up, others were fixed with time, others were still valid. All the packages that failed to build for whatever reason the past October (or at least, most of those) have been last-rited, masked and ready for removal. There are other packages that have been masked and prepared for removal, for failures to build, QA concerns and other stuff.
Now, since these are last rites for QA reasons, they get a 60-days grace period (I usually just did two months, but since I’m now running it through the script, it’s easier to use a real 60-days time). If the package maintainers, other developers, or users, have interested in keeping these packages alive, they should have enough time to do so. Keeping them broken as they are now, though, is not an option, and just fixing them to build, and keep them rotting forever, is not an option either.
Now, while Samuli and Victor are going through to fix all the possible glibc 2.10 and gcc 4.4 failure for the tree, I’m trying to find the problems that are not related to those, and decide on a number of reasons whether to remove the packages or not. These include, but don’t limit to, build failures not stopping the ebuild, broken dependencies, old ebuild not touched for years (sometimes fixes are made but no major change is present, some of those have to go as well), and a sum of minor QA issues.
Since minor issues are, as the name imply, not big enough to call for a removal of a package, I don’t stop at one or two of those, but when I get a package that fails to build, for whatever reason, and then I find that it doesn’t respect flags, CC, and fails with --as-needed as well, then the package is as good as broken to me, and it’s deemed to go.
At the same time, spending eight months or so being broken, in ~arch, is enough for the package to be deemed broken, even if it works fine in stable. Why this? Because it’ll be keeping other packages from going stable, or it’ll break when they go, so it’s not something ignorable.
The date for the start of the final cleanup is October 8th 2009, that day, about 20 packages will be removed (probably even more); while this is just a minimal part of the tree, that keeps growing and growing with time (I also have quite a few packages to add myself), it is part of the standard maintenance that we have to do to make sure that the tree is healthy.
The added advantage is that the packages that are masked will not be rebuilt repeatedly by the tinderbox in the future, which reduces the amount of work and thus the time needed for a full rebuild (it’s already pretty long as it is running all the testsuites: some take hours to complete, some even freeze in the middle and require manual handling (which is why I won’t be leaving the tinderbox running while I’m in London). And on a related note, glib’s testsuite completely freezes Gentoo/FreeBSD to a stop. Scary!
|
SSDs and filesystems, part 2 (August 09, 2009, 10:07 UTC)
So, a couple days in, and I'm still trying to (re)install Gentoo. More on that in a bit. First, let's talk about speed.
It's hard to tell whether or not my new SSDs are really a speedy improvement over the old software RAID1 array of magnetic HDDs. Normally, a bare-bones commandline system feels much faster than an aging graphical desktop, even on the same hardware.
I notice that compile times are slightly faster, though I've also been using tmpfs for Portage and the usual tmp file locations, so putting it all on RAM will lead to a significant speedup anyway.
Boot times are indeed quite zippy; the longest wait is for my media HDD to finish mounting -- it's on ReiserFS, which is known to have very slow mounts.
Now, let's talk filesystems.
The critical showstopper that's made me reinstall two times (and counting) is ext4. So far, ext4 has completely corrupted a whole drive (/var and /usr/portage) and made the other drive (/ and /boot) almost unbootable.
ext4 has eaten my data, hosed my system, and ruined my life.
No amount of fscking has fixed /var and /usr/portage, both on the second SSD. Did you know that you shouldn't let fsck try to resize broken inodes? apparently the resize behavior is known to be broken in the latest versions. It's known to corrupt filesystems. I didn't know that, either. I'm sorry, but what part of "production-ready" applies to ext4? Yeah, it's a new kid on the block, but it's moved out of the "experimental" status into the kernel.
That does not make it ready for your system. The first and second Gentoo installs largely didn't work because (I think) there might have been an invalid mount option. Or something could not be found. Or a superblock was missing. Or the moon was wrong. #$#^#&@ shitty unintelligible error messages. (Here's a tip, developers: don't put every possible thing that could have gone wrong into an error message, then repeat that message for every different error.)
My mount options seemed to be good after double-checking the manpage and around the internet, including kernel.org. Here was my original fstab, from when I had only one partition for / (no separate /boot):
/dev/sda1 / ext4 noatime,data=writeback,commit=60,nobarrier 0 1
/dev/sdb1 /var ext4 noatime,data=writeback,commit=60,nobarrier 0 1
/dev/sdb2 /usr/portage ext4 noatime,data=writeback,commit=60,nobarrier 0 1
Livin' on the edge here. I figured I wouldn't need a separate /boot partition on my first drive, so I lumped it all into one. I did that back in 2005 and 2006 with no problems, right? Right. The rest of the options were designed to maximize SSD performance.
Unfortunately, I couldn't get the system to boot. Made it past grub, the kernel loaded, but when it came time to mount /, it couldn't mount the filesystem rw. No amount of changing options worked -- adding rw to grub.conf, to the fstab options, nothing.
So I figured it must be my one-partition setup, and wiped my disks. Reinstalled again, this time adding a /boot partition on sda. Same ext4 options for /boot as for the other partitions. Rebooted and . . . nope, same errors. Now I'm also seeing a message about a possible bad option or other variable, which I can only assume was in fstab, thanks to the aforementioned shitty nonspecific error messages.
Hit up Google. Not much help. I again backed off on some of the ext4 options, tried playing with Grub parameters, but got the same results. The filesystems mostly weren't mounting, and when a few of them did, it was all readonly.
Sigh. Time to reinstall again. Set up a similar fstab, but this time I changed an ext4 option for /boot to data=ordered, based on this blog post. Reboot and . . . hey, it works. /boot gets mounted. Nothing else does, but it's a start.
I quickly booted back into the LiveCD, changed the other fstab entries to data=ordered, and reboot again. This time, the system seems to boot just fine . . . until it tries to mount /var and /usr/portage from the second SSD. *bzzt*, these cannot be mounted! Something's gone wrong. One more reboot, just for luck, then . . . *bzzt*, now there are filesystem errors! Fsck wants to fix them, so I let it run. Except it completely hoses both partitions. They seem to be so badly scrambled that even running mkfs.ext4 on them from the liveCD results in errors, some of which seem to be emitted from the libata system, which makes me wonder if now the SSD itself has also been corrupted.
I'll have to completely reinitialize and repartition that disk, now. Thanks, ext4. Thanks for hosing my data. Up yours, ext4.
I'm done trying to figure out why ext4 doesn't work. I don't care that it's supposed to be a fast file system for SSDs. I don't care that it's 40 times faster than ReiserFS to mount at bootup. I don't care. ext4 has lost my data three times now. I think my fingers are sufficiently burned to know that "the oven is hot; don't touch."
Up yours, ext4. I'm going back to ReiserFS. At least it works. It's never failed me in more than four years.
Update: On top of the initial ext4 errors, fsck problems, and mount issues, the Mobi drive was also going bad. Now the motherboard BIOS can't see it, regardless of which SATA port or cable I plug in. So just a day or so after trying out the device, when it was initially working for the first install (though the filesystem was throwing ext4 errors, at least /var and /usr/portage worked okay), and it finally finished failing. F***. I contacted the seller to request an RMA; I have a feeling that I'll end up having to go through the manufacturer, which will take a long time. Meanwhile, I'm without a workstation for an indefinite time, so I've set my devaway on dev.gentoo.org. I did find a couple other reports on the internets that say that their Mobis also died shortly after they arrived, so maybe there was a batch of bad drives.
But don't get me wrong, the Mobi drive dying doesn't absolve ext4 of any guilt. The ext4 filesystem still completely f**ked itself repeatedly on the system drive, the UltraDrive ME. It still refuses to do what it's told to do. But rather than continue to investigate related LaunchPad bugs on mounting ext4 rw and fsck errors, I'm going to move back to ReiserFS for the UltraDrive, and just live with longer boots. The RMA process will take awhile, so I may have to reinstall everything on a single drive and just avoid syncing Portage for awhile.
On a good note, OCZ (the company that makes the Vertex, an identical drive with an Indilinx controller), has been experimenting with a homegrown beta firmware that lets the drive do online garbage collection in the background. This is important for keeping the performance of the drive as fresh as when it was first used, even after it gets filled up with files and repeated (re)writes. The firmware is still in testing, but I'm hopeful that it'll make it out the door soon. Hopefully the same firmware features will find their way to my Super Talent drive -- and hopefully the TRIM command will also be implemented in the firmware.
Of course, the only Linux filesystem I know of that supports TRIM is ext4 . . .
|
August 08, 2009
Katzenjammer… (August 08, 2009, 18:33 UTC)
Today I stumbled upon an interesting band from Norway: Katzenjammer (MySpace, last.fm). They got an refreshing mix of genres combined with great vocals and quite some instruments. Besides that they are currently on tour and selling their debut album (Le Pop)… Definately worth to check out…
|
Evolution: Broken IMAP Sync (August 08, 2009, 04:16 UTC)
Since I already use evolution for my calendar needs on my laptop, I thought it would be ideal to also use it for email. So I went through adding all of my email accounts tediously to evolution and all seemed good as they started to sync.
However, suddenly multiple folders failed to sync on my gmail IMAP account. I tried to refresh the account and download everything again but Evolution fails out on downloading all of my email. So I open up the debug log and see errors like Incomplete server response: no information provided for message 1401. Wonderful. After some googling around, I found this bug which describes my exact problem.
Good right? Nope! Unfortunately it looks like an ancient bug that no one cares to fix and it’s “working as intended” as far as I can tell from the responses. This effectively terminates my ability to use Evolution as my email client as I don’t have the time or patience to go through 500 broken emails and deleting them manually just so Evolution doesn’t throw a wobbly over a corrupt email.
If anyone knows a fix for this problem I’d love to hear it, but as far as I can tell I’m effectively barred from using Evolution for email without manually going in and nuking crap off gmail. Quite disappointing really, considering almost every other email client such as Claws Mail or Thunderbird does not have this problem.
|
Against to avoid the problem of bus factor, I’m going to write down here what the plans are, for what concerns me, with PulseAudio and Gentoo for this end of Summer 2009, mostly related to what will happen when I’ll come back from my vacations in London, after mid August.
This actually is also out of candrews asking for it as I haven’t really thought about writing this before that.
So the first thing to say is that I am following PulseAudio pretty well; or rather I’m following Lennart pretty well (he’s also the one that suggested me to rewrite udev’s build system to use non-recursive automake — something I’ll write more about another day), so I’m not sleeping waiting.
Indeed, the 0.9.16 test releases are available in Gentoo already, although masked, and since recently they both support udev hotplug (preferring it over HAL), and also pass all the checks already. A note on the tests is needed though: the mix-test lacks a few entries, in particular regarding 24-in-32-bit samples, and is for this reason disabled in the current ebuild (Lennart should be working on it); at the same time, the ebuild is running test specifically in the source directory, because the intltool checks fail; badly. In theory the problem should be fixed in 0.41 series of intltool, but I am unsure whether that should be packaged or not by us.
In the next release, whether it’ll be another test release or the final release, there will also be a few differences in the handling of audio APIs. The OSS support will be restricted, masking the USE flag on Linux (leaving it enabled for FreeBSD obviously); this means that users wanting to use stuff like OSS4, which is not in Portage and if it’s for me will never be, will have to go a slightly longer way to get it to work with PulseAudio. The reason for this is that Lennart really don’t want to support that, and I can agree with him. Now, if you know the package well, you’ll probably be wondering “what about the OSS-compatibility wrapper?” this is solved already: in GIT the OSS output and wrapper supports are split in two different options, the former will be tied to the oss USE flag, the latter will be left in “auto-mode”, which will create the padsp rapper on all Gentoo Linux and FreeBSD systems. And this should fix your problem Luca!
As for some of the new features, like for instance Rygel UPnP support, well, I’ll probably be working on the sometime in the future; I do want to get Rygel in portage, especially if that will allow me to look at my vacation’s photos directly on my Sony Bravia networked TV.
|
August 07, 2009
swearing off radio (August 07, 2009, 16:30 UTC)
I'm not sure if I'm getting older and more cranky, or am just starting to wake up to the fact that so much of media that is presented is not really what I asked for or what, but this time it's terrestrial radio that is on the chopping block.

One thing I am sure of, it's a sign I'm getting older because I'm starting that phase where I'm unimpressed with music with arbitrary lyrics. I think to myself, "what the heck are they even talking about?" My tastes in music have always been a bit volatile though ... every few years, I'll completely shake up what I want to listen to, and I guess the turning point has finally hit again. I just didn't think it'd hit me so hard.
I was on the way to work this morning, and had a CD in the player (more on hardware specs later), but I switched to the radio. First of all, listening to the radio in the morning is a huge gamble that you'll find anything worth listening to. It is, of course, always that way since most of the airtime is devoted to commercials, but in the morning, there is also morning shows. I loathe morning shows on the radio. They are, in my opinion, the *lowest* form of mass media entertainment out there. A couple of DJs guffawing to themselves over the air, while running stupid contests and commenting on the stupid "news of the days" stories on the wire. Mostly, I just can't stand the pretense, that they treat their audience like everyone is involved in this big insider's joke and we are all just laughing along.
Anyway, that wasn't the thing that ticked me off. What ticked me off is I switched to a different channel, and I heard the same song for the 800th time playing. I was so sick of hearing it even being played, again, that I just shut off the radio in disgust. For good, this time, I decided.
The whole business market around over the air radio is totally whacked, in my opinion. The only explanation I have for the reason they keep playing the *very same* songs over and over again is because they don't want the idea of the top 40 songs to die off. Now, from a business standpoint, I can understand that approach IF it was easier on their supply and demand chain -- that is, you want to produce a large number of records that will sell, and create them en masse so you can project good sales and get a good return on your investment. That would be well and good, but it's totally out of sync with the way music works now. Thanks to the Internet, all music can be easily distributed and deployed to everyone on the planet at the same cost. So, the rationale should be -- instead of selling as much as one album as possible, let's sell as much *different music* as possible!
That is, in fact, one of the reasons I absolutely loved XM Radio when I first signed up for it years ago. They would constantly play new music I had never heard of, and I was always taking notes to write down what artist and song I had just heard so I can get myself a copy. But, XM was having serious cash flow issues, and it looks like the way they started to fix that problem was by bowing to the more traditional method of just playing the same songs over and over. I remember more than once finding the same song playing on three of my preset stations *at the same time*. That's about when I knew it was time to jump ship. I don't miss XM, I miss how it used to be.
Obviously, this whole situation could be solved if I had Internet access in my car, but I doubt that'll be happening for the next 10 years or so, so it's up to me to find a solution in the meantime. Right now, I've just got a CD player in my car, the stereo is the still the same one as the stock one that I bought it with. I've started looking around for stereos, but I was pretty pessimistic about the whole thing. The last time I looked at the idea, years ago, was when they were first starting to get support for iPods. I have an old Nano that I play with every now and then, but it only holds 4 GB of data, which is a drop in the bucket compared to today's MP3 players. Plus, the hardware and the company is very much against sharing and openness, so syncing it with Linux is not worth the pain and hassle.
I've since found in my more recent research, that there are radios on the market now that you can directly plug in a USB stick. That would be awesome, since you can buy a 32 GB stick for not a lot of money. There are also some that have support for MicroSD, but they cap out in size limit pretty quickly right now too.
Either way, I gotta get something soon. I needs my music.
As a postscript, I wanna point a couple of things out. I don't want to make it sound like I'm complaining, because I'm not. I'm more upset with the state of mass media in general than I am with anything else. Listening to the radio, like watching over the air television, is free, and I don't expect too much out of them in the first place. It's just my opinion, however, that things have gotten so out of control. They have been the dominant pipe for media input for so long, that they long ago stopped caring about what consumers wanted since there was no alternative. Thank goodness that the Internet is slowly breaking up those archaic fiefdoms, and I'm glad to see them go. If nothing else, choice is finally starting to drive market forces again. It's obviously been painful to watch the old school businesses try and adapt, but they either will, or die. I can't imagine I'm the only one bothered by the whole scenario.
The second thing that makes me sad is that I have to spend so much money just to avoid being constantly bombarded with advertisements and less-than-mediocre playtime. I realize that what I'm really doing is buying into luxuries, but the fact is, unless I wanna listen to classical music on the radio, there's no station to tune into where I won't hear a car dealer's advertisement every 7 minutes.
There's a lot of parallels to me building up my own library at home of TV shows to watch. Sure, it costs a lot more building up my own collection, but the convenience and reward of never having to hear another forced advertisement or commercial again is absolutely priceless. Plus, you can set the standard of quality yourself and cater to it how you want. The entire process is driven by personal taste.
Now, get off my lawn.
|
So in the past few days the new apr version marked stable in Gentoo for a series of security problems and all the stable users are suggested to upgrade. Pay attention if you do.
I went updating it today on this server, and found out that Apache failed to start afterward, lamenting inability to open the listening socket; after finding this in the change log for apr itself, I found the problem:
Set CLOEXEC flags where appropriate. Either use new O_CLOEXEC flag and associated functions, such as dup3(), accept4(), epoll_create1() etc., or simply set CLOEXEC flag using fcntl(). PR 46425. [Stefan Fritsch, Arkadiusz Miskiewicz]
Checking the configure.in file, this came out, as well:
AC_CACHE_CHECK([for SOCK_CLOEXEC support], [apr_cv_sock_cloexec],
[AC_TRY_RUN([
#include <sys/types.h>
#include <sys/socket.h>
int main()
{
return socket(AF_INET, SOCK_STREAM|SOCK_CLOEXEC, 0) == -1;
}], [apr_cv_sock_cloexec=yes], [apr_cv_sock_cloexec=no], [apr_cv_sock_cloexec=no])])
if test "$apr_cv_sock_cloexec" = "yes"; then
AC_DEFINE([HAVE_SOCK_CLOEXEC], 1, [Define if the SOCK_CLOEXEC flag is supported])
fi
It’s testing if the build system supports CLOEXEC to forcefully enable it on the host system without fallback. This is failing for me because the build system is Yamato and the host sytsem is Vanguard; the former supports CLOEXEC, the latter doesn’t. Just forcing cloexec to be turned off (by setting apr_cv_sock_cloexec=no before merging, fooling the cache system) stops it from requesting CLOEXEC and thus let Apache listen to the socket.
Unfortunately this doesn’t really fix the issue entirely: after that, Apache starts but all its children segfault; since I don’t have enough debug information on Vanguard, I stopped debugging here; I’m not happy about this happening just before my vacation, I guess I’ll have to spend this weekend debugging the issue…
Update!
After thinking about it a bit, I noticed that the code also checks for epoll_create1() even if CLOEXEC is not found (quite foolish); as it turns out, that is what makes Apache children’s crash. So if you are crossbuilding like I am (quite common for servers), you want to set these two variables in your make.conf until apr upstream solves the issue:
apr_cv_sock_cloexec=no
apr_cv_epoll_create1=no
Update #2!
I’ve reported this upstream with a tentative solution proposal, but I probably won’t work on it before my vacation.
|
August 06, 2009
traffic court (August 06, 2009, 15:08 UTC)
So, I have to go to traffic court next week, and I'm a bit freaked out about the whole thing. I got pulled over the other night for speeding (which doesn't really bother me, I got ticketed for 10 over), but the real shocker was when the officer came back and said "You wanna explain to me why your license is suspended?" My jaw totally dropped and it took me a few seconds to even respond since I had no idea *why* it would be suspended to start with.
Turns out I made a stupid mistake -- I need to send in a medical form signed by my doctor that states I can drive. The reason I need to do that is that I take some prescription meds, and when I got my renewal notice in the mail last year, they ask if you are taking anything regularly, so I answered yes and put my info down. I figured that was the end of that. Except that I got a longer form in the mail asking for more specifics and demanding that the doctor sign it, and I had to send it in before I could get my license. Well, poop, more paperwork. I took care of that, and got my license okay.
What happened, though, and I had no idea, is that you have to send one in every year after that, too. I probably would have known that except that my address on my driver's license was still at my old address -- I had moved a few months after getting it renewed and forgot to update it. The officer kept saying, "they would have sent you something in the mail if it was suspended," and I just replied, "I'm pretty sure I wouldn't have missed something like that."
So, I have two charges against me -- speeding, and driving with a suspended license. Getting my license reinstated was simple. I just had to go to my doctor the next day, have her fill out a new form, and dropped it off at the driver's license division and was cleared to drive again right away. Oh, and I updated my address at the same time.
I have to go to court now, and I have no idea what I'm gonna plead (probably either guilty or no contest), but I hope I at least get a chance to explain myself. I'd never *intentionally* drive without a suspended license (it was revoked back in March), it's just that I had no idea, and I probably would have if I had my address updated. So, I have no idea what to expect, and of course, being the nervous type that I am, all these fear-mongering scenarios race through my head. Not really looking forward to this one.
On the plus side, my driving record is mostly really clean -- I've never been in an accident before and I think this is only the fourth or fifth ticket I've ever gotten for speeding ever since I started driving, so maybe it won't be that bad. I just hope I can explain to the judge that I'm a dumb cluck who forgot to do some paperwork, and it's probably not a good idea to demote me to just skating to work after that.
|
August 05, 2009
While preparing for my first vacation ever next week, I’ve been trying to write up more content on my guide so that at least my fellow developers in LScube have a references of what I’ve been doing, and Gentoo developers as well, as lately I’ve been asked quite a few interesting questions (and not just them).
So, first of all, thanks to David (user99) who cleaned up the introduction chapter, and to Gilles (eva) who gave me the new stylesheet (so that it doesn’t look as rough as it did before, it also narrows the lines so that it reads better. It might not be the final style, but it really is an improvement now.
As for my changes, I’ve been trying to change slightly the whole take of the guide, trying to write up complete working examples for the readers to use, that are listed in the main page. At the same time, I’m trying to cover the most important, or less known, topics, with particular attention to what people asked me, or what I’ve been using on projects which is not very well known. The list of topics added include:
- using
AC_CHECK_HEADERS to get one out of a prioritised list of headers;
- using
AC_ARG_* macros (enable, with and environment variables);
- using
AS_HELP_STRING to document the arguments;
- using
AC_ARG_WITH to set up automatic but not automagic dependencies;
- using automake with non-recursive makefiles (including some of the catches);
- improved automake silent-rules documentation;
- using external macro files with autoconf (work in progress, for now only autoconf with no extras is documented).
I’m considering the idea of merging in some of the For A Paralllel World articles, at least those dealing with automake, to complete the documentation. The alternative would be to document all these kind of problems and writing something along the lines of “A Distributor’s Bible”… the problem with that idea is that almost surely somebody will complain if I use the name “Bible” (warning: I’m not a Catholic, I’m an atheist!)… and if I am to call it “The Sacred Book of Distributors” I’ll just be having to dig up all the possible mocks and puns over various religions, ‘cause I’ll be almost surely writing the ten commandments for upstream projects (“Thou shall not ignore flags”, “Thou shall version your packages”), and that also will enter a politically correctness problem.
Oh well, remember that I do accept gifts (and I tried not putting there the stuff that I’ll be buying next week… I already told my friends not to let me enter too many shops, but I’ll be following them and that’s not going to be a totally safe tour anyway…).
|
KDE 4.3 has arrived
Lots of behind-the-scenes fixes, a new pretty (debatable) default plasma theme and various new stuff across the board make kde 4.3 an exciting release!
Gentoo ebuilds were available the moment tarballs were released, thanks to the hard work of our Gentoo KDE team
However, since 4.3 brings some new packages (and dependencies), we’ve hard masked the ebuilds until everything gets the proper keywords.
You can follow the keywording progress in bug 280312.
Instructions on how to unmask kde 4.3 after the screenshot

unmasking & installing kde 4.3
kde 4.3 might be masked but it works fine on x86 and amd64 (for other archs check the bug above).
to install it, you can easily unmask it using the unmask file provided in the kde-testing overlay, [kde-testing]/Documentation/package.unmask/kde-4.3
if you don’t have / don’t want the overlay, you can grab the file here.
you can also use a command similar to
# unmasking kde 4.3
wget -O /etc/portage/package.unmask/kde-4.3 'http://git.overlays.gentoo.org/gitweb/?p=proj/kde.git;a=blob_plain;f=Documentation/package.unmask/kde-4.3'
to automatically save the unmask file to your unmask folder (if you use folders)
for those using stable gentoo, there’s a similar keywords file
# adding kde 4.3 in package.keywords/
wget -O /etc/portage/package.keywords/kde-4.3 'http://git.overlays.gentoo.org/gitweb/?p=proj/kde.git;a=blob_plain;f=Documentation/package.keywords/kde-4.3.keywords'
troubleshooting
if you’re trying to upgrade from kde 4.2, but portage gives you nice little blocks, there are a few things you can check:
- make sure you’ve synced the tree and kde-testing overlay (if using it) :p
- make sure the unmask/keyword files are correct and up-to-date
- check that you don’t have any 4.2 versioned kde-base/* items in /var/lib/portage/world
- check that you don’t have any 4.2 versioned sets in /var/lib/portage/world_sets
emerge -avDuN world — you’ll probably get some messy output but all blocks should be automatically resolved
if you hit any issues feel free to leave a comment, check the gentoo kde 4 guide (should be up-to-date soon) or visit us @ #gentoo-kde (freenode).
enjoy your shiny new kde!
share this post:
|
The Hip in S'toon (August 05, 2009, 11:50 UTC)
a) just saw the almighty Hip in Saskatoon. best concert ever. b) drove four hours home on Saskatchewan "highways" in the middle of the night, having to watch the road for wildlife the entire time (had to slam on the brakes for 3 deer, 5 raccoons, 2 badgers, a cat, and a pillow (?!)), with a hangover. worst headache ever.
still worth it.
|
My take on amending GLEP 39 (August 05, 2009, 05:43 UTC)
Earlier today Calchan blogged about amending GLEP 39 here. During the council meeting I voted against council being able to change the document and on deciding a process for changing it. Why? First I think as the developer population voted the GLEP I think they should decide about the changes as well. Secondly I think we don't need to decide on a process because we already have one. Using the existing elections team and votify is enough when needed. If council members think we are wrongly skipping items in meetings, I challenge them to step up and take chair in the next meeting making sure items are properly handled.
|
Amending GLEP 39 (August 05, 2009, 02:53 UTC)
I'm going to go ahead and assume you have all read the summary of the last council meeting. It can be summarized even further.
- We decided the #gentoo-council channel would be moderated during meetings. Developers and users have plenty of opportunities to tell us what their opinion is prior to and during the meetings.
- We confirmed Thomas Anderson as the council secretary and clarified that the role of the secretary is limited to posting the logs and summaries of council meetings.
- The council decided it wasn't competent to decide how GLEP 39 should be amended.
Some would say that it isn't much. And I wouldn't disagree. I wished this council could be someday called the council that slacked less but we're apparently not taking that direction. Let's see if we can change that. By the way I encourage everybody, anybody, to post discussion topics to the gentoo-council mailing list and debate there.
What I really wanted to discuss today is amending GLEP 39, and more exactly how to proceed. This GLEP serves in certain ways as our constitution and is more critical than any others. It was written almost 4 years ago and as such relects the situation as it was back then. It has been criticized a lot, many want or wanted to replace it at some point in time, some even went as far as writing replacements for it (count me as one of them), but I have yet to see something that is worth discussing in public.
Now, I'm not going to say that it's perfect. No text of that kind can be even close to perfect. My point today isn't about discussing what should be kept in it and what should be changed (don't worry though, I'll discuss that soon), but to make sure we agree on the fact that we need a mechanism to modify it. And by extension replace it if we decide so someday. Not that it wasn't ever amended in the past, it was, but in a way that I can't imagine satisfies the whole developer community. Don't extrapolate from what I just wrote that I disagree with the changes or how they happened, quite the contrary actually. But I talk to a lot of you and many tell me they believe that since GLEP 39 was the result of the vote of all developers, any change to it needs to be again voted by all developers. I disagree with that simply because GLEP 39 itself has provisions that would imply the contrary. However, all opinions need to be taken into account, especially when the same one comes back often.
So, what happened during that last council meeting? One of the questions was whether the council could decide on a process to amend GLEP 39. The vote ended up saying no. The next item on the agenda was then to organize a vote of the whole developer community to decide, since the council declared itself incompetent. Strangely enough this item was skipped. How can that be interpreted? Frankly, I'm not sure.
Someone argued that there was no point bothering with how to amend GLEP 39 since we could always organize a quick vote of all developers. I see two issues with that. One is that we had just voted that we couldn't decide on a process, but arguing that we can always use an all-developer vote is precisely deciding on a process, and it's inconsistent. The second one is that GLEP 39 was already amended a few times, and each time without an all developer vote. I don't seem to remember anybody complaining about that. So there must be at least a significant part of the developer population which is happy with not having to vote on changes of GLEP39, and is comfortable with the "vote out the bums" clause.
Most probably what happened is that we were running late with the meeting and the item was skipped because it didn't seem important to your new council. Yep, you heard me. Your new council doesn't really care about what you think on amending GLEP 39. If you think your council should care more then let it be known.
|
August 04, 2009
LXDE updates (August 04, 2009, 21:30 UTC)
Lately we updated some of the LXDE packages in Gentoo, and tonight I added a few more. We have now a practically complete LXDE desktop on Gentoo. So if you feel like trying the most lightweight desktop environment, consider to emerge lxde-meta. If you come across any bugs or other issues, please let us know. Bugs should be reported at bugs.gentoo.org. Support questions are welcome in the #gentoo and #gentoo-desktop IRC channels on Freenode, or #lxde on OFTC. You can also go to the forums.
The current version, lxde-meta-0.4.2 and its dependencies, is considered our stable candidate, so we’d like to straighten out any issues there may exist. Also, some documentation would be welcome. So if you want to contribute a “How to configure and use LXDE on Gentoo” guide, we’d be very thankful. Or if you want to help maintaining LXDE in portage, we could always use more people. So contact me if you’re interested in a herd tester or developer position.
We also have an overlay with live ebuilds, but it is basically unmaintained. So I cannot recommend you use it, unless you want to test and update the ebuilds. If you’re on bitbucket, send me a pull request. We used to have several user contributors, but I guess they are too busy with other things now — as am I. Currently my focus for LXDE (whenever I have time for it) is to get the packages up-to-date with the latest released versions and get what we have now tested and marked stable.
So have you tried LXDE yet? What are your thoughts? And are you willing to contribute?
|
Why is it that… (August 04, 2009, 20:26 UTC)
… I always seem to pick the expensive hobbies? Seriously. Sailing, skiing and shooting are the three primary sports in which I participate. None of these sports come cheap – both in terms of costs associated with purchasing boats/skis/guns, but in actually doing the sport – you need to pay for mooring and fuel costs for boats, you have to pay for flights and accommodation when you go skiing and you have to pay for cartridges and other costs when shooting.
I’ve recently taken up photography as a new hobby – if one shoots with a digital camera, the cost of a new camera is more often than not over £500 for a half-decent one. Let’s not even think about the lenses, which can easily sell for multiple hundreds of pounds for relatively “basic” models, and over £1000 for the “pro” models. If one shoots film, one has to pay for film and development costs. These all add up in a big way (not to mention the cost of the high-end film cameras – especially MF (Medium-Format) cameras).
One “hobby” I’ve been involved in since a really young age is reading. Okay, so at first glance reading isn’t that expensive. But when you’re finishing a £6-8 novel every other day or so (as I tend to do during the holiday season when I attempt to take a break from computers), it gets really fucking expensive. Since coming back from Aberystwyth on the 19th July (less than two weeks ago), I’ve read £73.91 worth of books. That’s almost three quarters of a hundred pounds. My wallet is crying (as is my bank account). It doesn’t help that I have another £49.95 worth of books on order… And that’s for five books alone.
I think my main issue is the fact that I like to buy my own physical books. And I like them to be new. This leads to two major problems:
- I can’t buy books second-hand (well, I can. I just don’t want to and would probably refuse to do so)
- I can’t borrow books from the library (see above)
- I can’t read eBooks (they “feel” wrong)
Buggeration. Anyone want to recommend some cheaper hobbies for me? Pretty please?
On a side note, I’m starting the Infinite Summer project when my copy of the book arrives tomorrow (albeit about a month and a bit behind schedule), Infinite Jest is apparently about 1000 pages long and relatively difficult to read. Hopefully this means I’ll put buying new books on the backburner for a wee while – especially as I’ll have another 3 books to finish after it.
|
helping out planet gentoo (August 04, 2009, 04:43 UTC)
I'm looking for a someone to help out with Planet Gentoo if they are interested. Specifically, we host a deployment of b2evolution and use it for the developer blogs. As a maintainer of planet services for Gentoo, that's part of my job to take care of it ... but it drives me a bit nuts and I'd like to rip it out and tell people to use something else.
But, people do like it, and I'm losing interest in taking care of it, so what I'd like to do is give the opportunity to someone else if they are interested. If you wanna help out with Gentoo a bit as a staffer (not a developer), I can help you take the quiz and get started. Email me at beandog@gentoo.org and lemme know why you're interested, etc. Main responsibilities would initially just tweaking our b2evolution install, getting some things cleaned up, maybe helping out with documentation, small patches. Nothing major or stressful, just minor tasks that need to get done.
|
On ELOG (August 04, 2009, 00:45 UTC)
Figured I'd visit forums today, seen at least 4 topics about lost menus while updating gnome-menus to 2.26.2, banged head 4 times because of users not reading elog messages and doing random fixes instead of searching the real cause of the change (in changelog, ebuild, elog, bugzilla). Good thing I have added that to the migration guide that will be up for stable users.
For those of you who still don't know about elog, man make.conf.
Update: fix typo.
|
August 03, 2009
Okay for tonight I’ll post something quite personal, rather than a technical post (don’t worry guys tomorrow you’ll get to learn what happened after pam_mktemp I have the post written already).
I’m posting it here, after telling about it to a few people so I can actually find the courage to go on with the plan (you have no idea how much I have to force myself to overcome the fear of planes): next week I’m going, with a few friends, to London. And that means boarding a plane.
Preparations are already ongoing, luckily my cellphone is already set (thanks 3 for the free roaming among branches!), although I have some problems with my debit and credit cards (I haven’t learned the PIN code of the credit card since we don’t use it in Italy, and I’m afraid it won’t work in UK without it; the debit card has some limits for foreign operations, I’ve requested for them to be unlocked now).
What does this mean for you who are reading my blog? Well not really much; I’ll probably post one thing either before going, or while I’m there (thanks to the E75 phone), which is going to be up on August 12th, deadlined. For the rest of the week the blog is going to be silent, since I’m not bringing my laptop with me. It wouldn’t be able to connect either because I cannot seem to get the bluetooth tethering working on Fedora 11 (although wifi still would work). Gentoo work will all be postponed till I come back, given that yamato is going to stay off for a few days (off and detached so my mother can also clean my office, likely). Since I have some removal scheduled for the time, I’ve shoved the tasks back to Luca, who’s also going to take care of anything I might have to do in that timeframe for what concerns my packages.
Why the rushed decision? Well… it’s the only way I can make such a decision: if I were to postpone, or if I have more than a day or two to decide, I would probably look back and find a way to drop out. This way, I really cannot. Thus also why I’m repeating it here. I’m going to be there, one way or another, next week, whatever it takes me to do! And if I can get rid of my fear, you’re probably going to find me at conferences here and there from time to time, finally.
And just to convince my subconscious further, I’m seeing the fact that I ordered an USB hub from Amazon, that has a British power supply (I guess I’ll have to get some converters, both ways), as a sign. I don’t believe in signs usually (I do believe in Murphy’s law though!), but I know the power they have. Not in the usual “new agey” sense of power, but rather in the way they can help trick the mind. And since my fear is mind-created (if I ever boarded a plane before, it would have been different), I’ll just have to trick it long enough till it stops tricking me.
So anyway, trying to tie down the loose ends this week so I can be relaxed for the vacation week, and come back rested, and ready to do more work without risking burning out.
|
VME bus support for Linux (August 03, 2009, 21:25 UTC)
Today another nice thing for the Linux kernel happened, we got working
VME bus drivers and infrastructure submitted to the kernel tree.
Now, I don't expect it to generate as much press as the
Microsoft kernel driver thing did, but it should, as I feel it's more
important in a way.
The VME bus code has lived outside of the kernel for many years, and there was
at least three different implementations at the same time floating around.
Martyn Welch from GE Faunc took the time, merged all of them together,
and rounded up the different copyright holders of the code and got legal
approval from all of them to properly release the code under the GPLv2.
Now as someone who has tried to do this kind of thing, I know how thankless
and how difficult it can be. So here's a great big thank you to Martyn and
his employer for getting this work done, and taking the time to work
toward getting it merged into the main kernel tree.
The patches are here, here, here, here, and a good
readme for the api is here.
|
While Firefox 3.5 has some good improvements, it’s not all good. We geeks are quite disappointed by the decision to disable the backspace key. In previous versions backspace would take you back a page in history. Which is great when you are on the keyboard already — no need to grab the mouse. But in 3.5 this has been disabled.
Fortunately, this is a setting that you can change. Here’s how:
- Open a new tab and type about:config in the address bar.
- In the Filter search field type backspace — this should bring up the browser.backspace_action preference.
- Right-click on the value (defaults to 2) and select Modify.
- In the pop-up window change the value to 0 (that’s zero) and accept.
- Enjoy your backspace key to go back a page in history again.
For more information see the mozillazine knowledge base page on about:config.
|
Some more stuff that has happened recently with cleaning up ALSA ebuilds. We (as in me, mostly) decided to drop support for the optional MIDI support in the alsa-lib and alsa-utils packages. It originally was implemented as a hack on our end, always caused headaches when disabled, and a whole lot of ebuilds required that it be implemented anyway, so it wasn't so optional to start with.
With alsa-1.0.20, I ripped out the midi use flag completely, but instead of fixing the reverse dependencies to check for an either/or scenario, instead it was decided to just go back and change all versions of the alsa-lib/utils ebuilds and to force it on, and then drop the check on those using it. Thanks to Samuli (ssuominen) for fixing all the applications that were using it.
If you run into any ebuilds that are failing to merge because of the dependency, that are in the main portage tree (sorry, I can't take responsibility for overlays), try syncing your tree again -- it's possible your last one was during the transition. If you still find one that isn't working, feel free to file a bug report at bugs.gentoo.org and assign it to alsa-bugs@gentoo.org.
Another change that has needed to happen for a while, though not nearly as dramatic, is that I ripped out the really old config options in the alsasound init script: KILLPROC_ON_STOP and UNLOAD_ON_STOP which would kill process using ALSA, and unload its modules, respectively. Like before, they caused more problems than they solved (both of which, I might suggest, could be implemented in local.stop if you really needed something like that), and I'm glad to say they are gone.
That's about all the major growing pains for now -- that is, I certainly don't have anything else on my plate for ALSA or its related applications, other than getting 1.0.20 stable and everything previous to that version removed from the tree.
As always, we appreciate any help people would like to give. There's still old bugs open, and it'd be good to know if they are solved or not in the latest release.
I realize some of these changes may be minor bumps for users, and if so, I apologize ... but Gentoo is always changing goals and directions, and I'm quite glad that we have the flexibility to change things, instead of being stuck with one method. Part of growth is just shedding the stuff that doesn't work.
|
August 02, 2009
SSDs and filesystems (August 02, 2009, 22:31 UTC)
So, in between being super busy with Gentoo yet not having enough time to keep up with all the bugs, document updates, and project commitments . . . I've added yet another item to my plate: a fresh install of Gentoo onto a pair of SSDs.
I've never reinstalled Gentoo on this workstation; this is the original install from October 2006. I had thought about just finding some stage4/stage5 backup scripts and tips from the Gentoo Forums, but it seems to be more cumbersome and time-consuming than reinstalling. Besides, installing Gentoo from scratch gives me a chance to create an even more lean, minimal system. No more accumulated packages and cruft that I don't use, just the essentials.
And it'll let me see how good these SSDs really are for compilation times. 
I purchased two: a 32GB Super Talent UltraDrive ME for /, and a 16GB Mobi 3000 for /var and /usr/portage.
The Super Talent is a new-generation MLC drive with an Indilinx controller. It's not as good in some areas as Intel's controller for the X-25, but it's better than everything else out there, and it doesn't have the chronic stuttering problems that all cheaper JMicron-based controllers suffer.
The Mobi is an older drive, "only" SATA-150. But it is an SLC drive, so I'll use it for the partitions that see the highest write activity, as SLC is more resilient than MLC. Plus, the contents of the drive are more or less throwaway, so if any corruption does develop, I can just replace it with no issues. /var sees log frequent writes, and there may be some Portage compilation in the tempfiles. I've been using a tmpfs on RAM for /var/tmp/portage for some time now, so I don't really think it will hit up the drive much, not with 4GB of RAM installed:
none /var/tmp/portage tmpfs noauto,nr_inodes=1M,size=2000M 0 0
See? A dynamic Portage compilation space, ready to occupy 2GB RAM if need be. During compiles, the only time I ever really see the HDDs light up is during the src_unpack (to RAM) and src_install phases.
So I've figured out my drive and partition usage, but the things that are causing the most headaches, and occupying the majority of my research time, are:
1. Which filesystems
2. Which mount options
3. Which schedulers
4. Partition alignment schemes
See, I will have two SSDs in there with Gentoo installed on 'em, but I'll also have a separate magnetic HDD for media storage, so that means a different for each drive.
For 1, ext4 is looking increasingly attractive for the SSDs. I may continue to use ReiserFS for the media drive, as it's worked very well for a few years now. But, given that the Portage tree is just lots and lots of tiny files, perhaps I could continue using ReiserFS on it? Though I would need to deactivate the journal. The Mobi drive should not have any journaling on it -- too many writes.
NILFS2 is another interesting filesystem, but it seems immature. BtrFS also has potential, especially after reading Val's excellent article, but its developers warn against using it for anything other than testing. So I'll stick with something a little more mainstream, yet not so old and cranky as ext3/ext2.
Which brings me to 2: mount options. I've only just begun to read up on suggested options for ext4. data=writeback seems to be one of the more popular suggestions. noatime is a necessity; I've used this option on every single Gentoo install I've ever had. There are several other options I need to investigate, including the dir_index variations.
If I go with ReiserFS, I'd need to research the performance differences between notail and tail. In theory, the latter option could be more efficient for packing more data into fewer blocks, resulting in fewer writes/rewrites. This is at the expense of slightly more CPU usage. notail may result in more speed, but I haven't found many detailed reports of ReiserFS usage on SSDs. One last thing to look up would be the difference between ReiserFS with the journal and without.
The next piece of the puzzle is 3, schedulers. Most of the schedulers in the kernel are designed to keep spinning magnetic disks happy. But since there aren't any moving heads or rotating disks to spin up, the algorithms that are designed for efficient, minimal motion aren't very helpful for SSDs.
The usual solution proposed is to bypass the traditional HDD seek layer overhead by just using the noop scheduler. It's a very simple FIFO-based scheduler. System requests a file, it gets it. No complex queuing up done in the kernel. It lets the extremely fast drive controller do all the work, since it's capable of getting the data where it's needed without stuttering or delays.
However, the deadline scheduler may be as good as noop, as deadline does a certain amount of prioritizing. My understanding is that it's similar to NCQ in this regard, and that using deadline doesn't have any overhead costs. Still doing the research on this.
These two schedulers may be all well and good for the SSDs, but since I'll have two SSDs, a magnetic hard drive, and an optical drive in my box, I can't use the same scheduler for all of 'em. noop would be a poor choice for the HDD, so I may use deadline or stick with the tried-and-true CFQ scheduler.
Fortunately, using different schedulers for different drives is fairly easy:
# echo deadline > /sys/block/sda/queue/scheduler
# echo noop > /sys/block/sdb/queue/scheduler
# echo cfq > /sys/block/sdc/queue/scheduler
It's just a matter of putting these commands into an initscript to be run at boot.
The last puzzle piece (so far) is 4, partition alignment schemes. This is the most confusing one. The most headache-inducing. The most worrisome one, in that if I screw it up, I could completely hose the performance of the drives, and severely impact the wear and tear on the drive.
The OCZ Vertex is functionally identical to the Super Talent UltraDrive. Same controller and firmware, so Vertex tips will apply to my drive. The OCZ forums have proven rather useful. There's a fair amount of material at the OCZ forums, and even some suggestions by Gentoo users. Unfortunately, some of the threads are rather old, so I'm unsure how much still applies. Given that there have been new hardware revisions, new firmware shipped with the drives, and improvements to the Linux kernel stack (schedulers, libata, etc.).
Ted Ts'o has a pretty good explanation, but it differs from some of the other suggested block sizes. Also, some guides have a radically different approach.
* * *
So, four pieces to the Gentoo installation on an SSD puzzle. Lots of notes so far, and despite four months' research, I feel like I've barely gotten started. I've been thinking and planning to move to an SSD for quite awhile now; it's mostly been a matter of waiting for prices to fall. Now all the components are here, so I'll just have to dive right in and see what I find. Results will, of course, wind up here. 
|
Please use HTTP features (August 02, 2009, 12:36 UTC)
I know I’m pretty needy on this matters, but there is one thing that drives me crazy about software using HTTP and that is the non-use of the HTTP features that have been created to save bandwidth. I hate that kind of software because from one side, I don’t always connect via flatrate (my phone provider has a semi-flatrate by the traffic) and from the other, I know that servers don’t always have free bandwidth.
So when I find a free software project designed to warn you about changes in web pages that does not seem to know about If-Modified-Since and If-None-Match, I tend to discard it; I especially am worried if the software does not warn you against setting the polling every minute.
But it doesn’t stop at free software; in the last week I’ve noticed an extensive increase in the traffic generated from my blog; rather than the usual 200/300 MB a day, it started generating 500/600MB a day, constantly, without any new referrer that might explain the increase. After looking at the statistics for a little longer I noticed that someone from Germany were making over 1000 requests a day.. quick check on the logs and it turned out that the user was requesting my main article feed once per minute, via his feed reader.
Now, already checking once per minute is a bit too much; most planets and other feed readers check at most once per hour; I usually try hard not to post more than twice per day. But the problem there is that the feed reader software (FeedReader by NewsBrain) is actually braindamanged. It does not use the HTTP headers to only request if the feed has changed, so it kept requesting the same content over and over and over and over. Given that it seems to be a commercial proprietary software, and it doesn’t seem to have a clue about the protocol it’s designed to use, that feed reader is now blacklisted in my server and will not work with the websites hosted there.
So please, if you develop a software that make use of the HTTP protocol, learn to use its features!
|
Why DRM on news is a bad idea (August 02, 2009, 11:31 UTC)
As Techdirt writes:
This has been said before (multiple times) but you don’t rescue your business model by “protecting” against what people want to do. You don’t rescue your business model by wasting resources trying to hold back what people want to do. You rescue your business by providing more value and figuring out a way to monetize that value. Putting bogus DRM on news does none of that. It only hastens failure.
I’ve been saying that all along, but the old media don’t get it. If they refuse to evolve, they will go extinct, like dinosaurs.
|
Looking at Smolt (August 02, 2009, 06:57 UTC)
Since release 1.3.2 Smolt comes with a tab “Distribution” to show distribution-specific information:
(The new Qt-based GUI client was introduced somewhere after Smolt 1.2 by Carlos Gonçalves, see here for details.) The currently quasi-empty tab is shown no matter what distro you run Smolt on. However, on my “gentoo” branch it looks slightly different:
I have also been working on simple extractors for dpkg and rpm to better understand the distribution specific interface that I’m introducing on code level. After all one of the long term goals is to feed Smolt statistics with PackageMapped installation data from across distros, not just Gentoo.
So if you read this and feel like bringing support for another distro (say Arch) to Smolt now is a great time to contact me.
PS: Check my “sping” overlay for a Smolt 1.3.2 ebuild.
|
August 01, 2009
We are cleaning up the XFCE ebuilds via a new eclass. The current eclasses do not make maintenance any easier, like they should. Some other things on the TODO list include:
- Remove xfce-4.4 from the tree. 4.6.1 has long since been stable. Caveats: We promised mips that they could have a ~month to keyword 4.6.1. Gentoo Prefix can't easily use 4.6.1 due to the xorg-server dependency.
- Rename plugins to match what upstream calls them. For example, what Gentoo calls
xfce-extra/xfce4-cpu-freq, upstream calls xfce4-cpufreq-plugin This is true of all plugins.
- Remove the meta extras package,
xfce-base/xfce4-extras.
The last bullet point is where I would like to gain input on how to provide the best user experience for xfce users on Gentoo. We are contemplating on removing the meta package because: it is tricky to add new plugins to it (requires more arch team work via rev bumps). Renaming plugins will require more work because of the meta package. And finally, what is the point of this meta package (some would ask) - outdated, etc.
So some possible options:
- Remove the meta package completely and let the user emerge what they want. We are leaning towards this one.
- Provide an USE flag for
xfce-base/xfce4 to emerge all these extras, since it is a meta package anyway. This allows arch teams to mask the use flag if they don't want to deal with all the plugins. Not a good option though, in my opinion.
- Revbump the meta package everytime there is a new plugin added to the tree.
- Other option that I haven't thought of?
So, what is it? What would provide the best XFCE experience on Gentoo?
|
Two years ago, today (August 01, 2009, 21:56 UTC)
Two years ago, today, August 12th 2007, in the early hours of the morning (3 AM) I was being brought to the hospital for my first hospitalisation ever: the start of my Pancreatitis saga (that’s the last post I was able to write in that month, a few hours before). It took me forty-two days to come home from the hospital, with sixteen spent in the intensive care unit.
After that, I’ve spent another week in hospital last year in July, and then almost the whole month of September (in a centre specialised on pancreatic diseases), in the middle of which I finally had surgery. And from there on I was finally able to say I recovered. Right now, while still having to keep sugar levels under control, I can seem to live my life normally (given I didn’t drink alcohol before, the fact that it’s now poisonous for me is no problem; and since I took my coffee without sugar before too, that’s also not much of a problem).
Two years after the fact, I’m working as hard as then, and I get the same amount of stress, which aren’t really extremely good things to be honest. On the other hand it mean I probably fully recovered by now and I can live more lightly from now on that I had in the past two years. Unfortunately I cannot simply ignore what happened; my gallbladder problems may as well be hereditary, which means that if I’ll ever have a life and a family, I’ll have to take extra care for that.
On the other hand, my reason to write this post is mostly to remind you that while I’m happy to receive appreciation tokens there are more important things in this world, so if you do find yourself willing to donate something, please do so, but in favour of research .
|
Since the tinderbox is now running on Linux containers I’m also experimenting with making more use of those. Since containers are, as the name implies, self contained, I can use them in place of chroots for testing stuff that I’d prefer wouldn’t contaminate my main system, for instance I can use them instead of the Python virtualenv to get a system where I can use easy_install to copy in the stuff that is not packaged in Portage as a temporary measure.
But after some playing around I came to the conclusion that we got essentially two problems with init scripts. Two very different problems actually, and one involves more than just Linux Containers, but I’ll just state both here.
The first problem is specific to Linux Containers and relates to one limitation I think I wrote of before; while the guest (tinderbox) cannot see the processes of the host (yamato) the opposite is not true, and indeed the host cannot really distinguish between its processes and the ones from the guest. This isn’t much of a problem, since the start and stop of daemons is usually done through pidfiles that list the started process id, rather than doing a search and destroy over all the processes.
But the “usually” part here is the problem: there are init scripts that use the killall command (which as far as I can tell does not take namespaces into consideration) to identify which process to send signals to. It’s not just a matter of using it to kill processes; most of the times, it seems to be used to send signals to the daemon (like SIGHUP for reloading configuration or stuff like that). This was probably done in response to changes to start-stop-daemon that asked for it not to be used for that task. Fortunately, there is a quick way to fix this: instead of using killall we can almost always use kill and take the PID to send the signal to through the pidfile created either by the daemon itself or by s-s-d.
Hopefully this won’t require especially huge changes, but it brings up the issue of improving the quality assurance over the init scripts we currently ship. I found quite a few that dependent on services that weren’t in the dependencies of the ebuild (either because they are "sample configurations’ or because they lacked some runtime dependencies), a few that had syntax mistakes in them (some due to the new POSIX-correctness introduced by OpenRC, but not all of them), and quite a bit of them which run commands in global scope that slow down the dependencies regeneration. I guess this is something else that we have to decide upon.
The other problem with init script involves KVM and QEmu as well. While RedHat has developed some tools for abstracting virtual machine management, I have my doubts about them as much now as I had some time ago for what concerns both configuration capabilities (they still seem to bring in a lot of unneeded stuff – to me – like dnsmasq), and now code quality as well (the libvirt testsuite is giving me more than a few headaches to be honest).
Luca already proposed some time ago that we could just write a multiplex-capable init script for KVM and QEmu so that we could just configure the virtual machines like we do for the network interfaces, and then use the standard rc system to start and stop them. While it should sound trivial, this is no simple task: starting is easy, but stopping the virtual machine? Do you just shut it down, detaching the virtual power cord? Or do you go stopping the services internal to the VM as you should? And how do you do that, with ACPI signals, with SSH commands?
The same problem applies to Linux containers, but with a twist: trying to run shutdown -h now inside a Linux container seem to rather stop the host, rather than the guest! And there you cannot rely on ACPI signals either.
If somebody has a suggestion, they are very welcome.
|
Last week, I wrote about my experimentation with pam_namespace to replace pam_mktemp (that breaks samba and does not cover all software). Unfortunately, a couple of days after starting this I gave up on it entirely, I did write down a quick comment about that, and promised to write down what the issue is exactly.
But since I know that people like to have some context on why I’m doing something and why that’s important for users, I’ll first post some summary on what the problem is with insecure temporary files and why it’s useful to mitigate them. And while I’m at it, I’ll explain the drawbacks of my original approach that is currently available through pambase.
Software often have security problems with temporary files, that might lead to information disclosure, or worse . This is caused both by manually-created temporary files, and by old, broken functions like tmpnam() which are deemed insecure. For this reason there are two main movements trying to work on this: from one side, Debian security team has developed a script that can identify a large amount of insecure temporary files creation (tracker from Gentoo); on the other hand, OpenWall developed pam_mktemp (do not confuse it with the pam_mktemp from the Debian-Athena distribution, that used the same name with a different version and with a totally different interface — not a very good choice there), which creates per-user directories, properly set up so that insecure temporary files from an user cannot be exploited from another… that is if the software supports TMPDIR.
Yes because the pam_mktemp module does not rely on anything particular, either from the kernel or from the PAM implementation: it works fine with Linux-PAM and OpenPAM, on Linux and FreeBSD and most likely on any operating system and PAM implementation. What it mostly does is setting up the directory structure, and then sets the TMPDIR environment variable to the new one. All the software knowing about this variable (knowing about it is part of the GNU coding standards), or are using the proper commands and functions to create the temporary files, will be using the user-private temporary directory and this reduces the impact of insecure temporary file creation.
Unfortunately, this does not work as flawlessly as I hoped: first problem is that Samba, for instance, has some problems with the idea of having per-user temporary directories: indeed, after it starts (with user nobody) it moves to the temporary directory as CWD (Current Work Directory) and tries to stay there after changing user to the one you’re authenticating with. Since the directory for nobody is not accessible by the rest of the users, Samba stops working there.
The second problem is more insidious, because while the previous one can be deemed an incompatibility and thus would simply require users to change their setup slightly, this one moots the main reason why we want to use pam_mktemp: vulnerability mitigation. We want to reduce the chance that insecure temporary file creation might be exploited for information disclosure or worse, but if the code is unable to create properly secured temporary files, it’s very likely that it will not respect the TMPDIR setting either.
At the end, what pam_mktemp is actually able to prevent is insecure temporary file creation by mistake in code that is otherwise sound. While this happens, and thus the module is not totally useless, this is quite rare; most of the code that would have this kind of problems would also have to be modified to accept TMPDIR too. And you have to add to this the software that insists on _not _ supporting that setting: GnuPG for instance, where upstream has claimed multiple mirror-climbing reasons for not abiding to the coding standards it should abide to, being a GNU project (just to qualify this statement, one of the reasons I was given is that if they abided to TMPDIR, the user could set that to his home directory, which could be stored on NFS, and that would open a security risk as it would expose the agent to other machines – if you got any idea how local unix sockets work, you know this is not the case since the socket is local to the kernel, and at the same time, such misconfiguration is likely to be a problem for other reasons and something that exists between keyboard and chair).
An alternative to all this is the pam_namespace module, but that also has its share of problems, but those, will be posted tomorrow. (For once, I already have the post written so it will happen! I just wanted to give this drop by drop since people keep saying I write too much).
|
Update: as reported by Fai Wong, -O1 is actually fine. Obviously, it must be some flag(s) which is(are) enabled at -O2 but not at -O1 caused this problem. However, it is not a priority ATM. Anyone who is interested in it is welcome to investigate it further.
As I have mentioned earlier, sqlite compiled with -O2 may cause xulrunner to segfault in N32 userland on Loongson. Well, I almost forget it.
So to remove the -O2 from CFLAGS once and for all, I adopted the technique described here.
zhangle@2f env $ pwd /etc/portage/env zhangle@2f env $ find . ./dev-db ./dev-db/sqlite ./O2-removal zhangle@2f env $ cat O2-removal pre_pkg_setup() { elog "bashrc is removing \"-O2\" from CFLAGS for $PN" CFLAGS="${CFLAGS/-O2/}" } zhangle@2f env $ ls -l dev-db/sqlite lrwxrwxrwx 1 zhangle zhangle 13 2009-08-01 16:10 dev-db/sqlite -> ../O2-removal
|
Developer Robin H. Johnson, who is a trustee board member, infrastructure team lead, spoke with
David Abbott.
Robin is the backbone of the Gentoo infrastructure team which includes the
forums, bugzilla, and most important, the Gentoo Portage tree.
He describes his first open source project, phpMyadmin, how he became a Gentoo
developer, and the layout of the infrastructure.
"Nearly 50 percent of the infrastructure hardware is taken up by web
applications, because we have a lot of separation between web applications that
have a high security exposure. Admittedly some of the web services are a very
big deal for Gentoo, like our Bugzilla service, running on 4 machines sponsored
by the Dutch social network, Hyves. Very recently we've gotten new hardware for
Forums, sponsored by Gossamer Threads. The next largest slice after that is the
machines that provides rsync.gentoo.org service. Only then do we get down to
individual machines for purposes. There's some cases where having more hardware
as fail-over in case we lose a machine would be nice, but I think the place
that'd we would benefit the most presently would be a newer mail server
infrastructure, so that we can deploy heavier spam filtering."
Robin H. Johnson
Interview
|
For the lulz (August 01, 2009, 00:15 UTC)
Recently one of our developers decided he would raise hell in one of our irc channels. "For the lulz" he said. What ensued was a rather large number of kicks which ended in a ban. I contacted him and tried to talk to him. He wouldn't agree at first, then stopped answering, and went on in another channel. I spent a good amount of time trying to reason him at around midnight my local time knowing I had an early meeting at the office the day after. He stopped and apologized a few seconds before I hit the button to suspend him.
He didn't have any really bad intentions but he still created a shitstorm. In his mind everybody overreacted but there was one thing that he didn't understand. Him behaving like this made a few people unhappy. Whether they were right or wrong to be unhappy, they were, and they showed it. In return they started filling some of your fellow devs' maiboxes, and irc queries started popping faster than it is humanly possible to answer. In short after a few minutes some of us had their screen blinking like Christmas trees.
So, kids: don't make an ass of yourselves in public, whether on irc or elsewhere. And if you absolutely have to do so don't do it in a #gentoo- channel, and preferably not with your gentoo irc cloak. If you don't do it for yourself do it out of respect for those whose task it is to try and maintain a semblance of peace on irc or on our mailing-lists. And think of all those traces you're leaving behind for the next time you'll look for a job. Think also of the image you're projecting for the whole Gentoo community. You're a developer, so if you care show yourself and your distro in good light.
And remember that we're a large project with all kinds of different cultures. Something that may seem totally insignificant and/or funny to you may (and will probably) be seen as abrasive by others. We have to operate on a lowest common denominator. That's unfortunate but there's no way around it.
Thanks for your attention.
|
July 31, 2009
alsa cleanup (July 31, 2009, 22:30 UTC)
I've just punted all the old ALSA ebuilds from the tree. Tah tah. I thought they needed to be in there for old kernel compatiblity, but it turns out I was wrong. Ah well. The less versions to worry about, the better (from a support point-of-view).
We're going to look at getting 1.0.20 stable here pretty quickly, and then remove *all* the old versions after that.
Oh, and if you are interested in helping out with ALSA bugs, that'd be nicely appreciated as well.
One other note -- I added media-sound/alsa-driver, which is the external modules for the ALSA drivers, into package.mask. The concept is simply to add a hurdle to users wanting to use it, and to make it clear it won't be landing in stable-ville anytime soon. However, there are no plans to remove it from the tree, either. I know some people like to use it, so there ya go.
|
setup a few terabytes or so (July 31, 2009, 18:48 UTC)
I'm getting to the point with my little media library where I'm running out of space, and I need to find a way to expand my diskspace a bit. I'd like to find a next-generation solution, one that I can use as I expand from 1.5 terabytes to (eventually) 12 or so. That's what I project the final size I'll need is. Right now, I only need about 4.
There are a couple of ways to do this, obviously, but I'm not sure what the best way to approach it is, or the one that is the least cost-prohibitive. Generally speaking, all I need is some *way* that I can access multiple harddrives (of various sizes, since I have old ones I can use) through one mountpoint, either using LVM or RAID (I'm not that picky).
Now I could spend lots of $$$ on a Drobos or something similar, where I just cram them into one box and let it fly, but I don't need that level of sophistication. The idea I'm currently toying with, is just getting a bunch of eSATA HDD enclosures, and hooking those up to my fileserver. My server currently has six internal SATA ports on it, along with one eSATA port on the back, giving me seven drives I could plug in (either internally or externally). So that's not a problem. I'm curious, though, how realistic getting a bunch of external enclosures is gonna be. Typically, the drives I use (Western Digital) don't run that hot, so cooling doesn't seem like a big problem. I already have one external SATA drive that I'm using, and it silently runs and sits on my desk without a problem.
That's not my only option though. I'm thinking of switching out the server completely for something less beefy and much more quiet. In fact, that's my biggest annoyance right now, is that it's loud. I'm not sure what it is, and I really should pinpoint the source before I rip everything out and buy lots of hardware. I'm fairly certain though, that it's just the CPU fan first and the power supply second.
If I did replace the server's hardware, then I have a few options there -- I could go with a Mini ITX motherboard that doesn't need a PSU with a fan (just get a Morex power connector that uses 120W max or something). Since I'd be hooking up everything externally anyway, they wouldn't draw on the PSU for power, so the chipset could be really low wattage. I'm not sure if I want to spend money on that, though.
Ideally, I'd have a place in my apartment where I could stick a server that can be as loud and as noisy as it wants, and I wouldn't have to hear it. Sadly, that's not the case, and I doubt I'll be moving anytime soon. So, noise pollution is a factor in this as well.
Anyway, I'm still trying to think of what the best way to go is. There's a few directions this could take.
|
links for 2009-07-31 (July 31, 2009, 12:03 UTC)
So i bumped dev-libs/cloog-ppl to a newer version just now. cloog-ppl (and it's buddy PPL) are new dependencies of the new Graphite framework in GCC 4.4 (still masked). They're optional dependencies, and on a whim I wanted to see if configure would fail if they were missing or just detect it and continue on. So I did this:
emerge -C cloog-ppl Oops. configure: error: C compiler cannot create executables Every Gentoo user has seen this at some point. It's a very general error that can range in meaning from "you mispelled a CFLAG" to "wow you're screwed". I knew what the error here would be without looking, but for those following along at home: /usr/libexec/gcc/x86_64-unknown-linux-gnu/4.4.1/cc1: error while loading shared libraries:
libcloog.so.0: cannot open shared object file: No such file or directory (usually you would find this in the config.log of the package being compiled) Ok, so I just hosed the compiler. Dumb mistake. Now, here's how we fix it. halo ~ # gcc-config -l
[1] x86_64-unknown-linux-gnu-4.3.3
[2] x86_64-unknown-linux-gnu-4.4.1 *
[3] x86_64-unknown-linux-gnu-4.4.2-pre9999
[4] x86_64-unknown-linux-gnu-4.5.0-pre9999 Usually I would have three or four more versions here (3.4, 4.0, 4.1, 4.2) but this is a relatively new install. As luck would have it though, I have exactly one version that will work here. 4.3.3 doesn't have graphite support and therefore won't be linked against libcloog. So, gcc-config 1, etc. emerge -av1 cloog-ppl. libtool: link: x86_64-unknown-linux-gnu-gcc -Wall -fomit-frame-pointer -O2 -g -march=core2
-msse4.1 -fomit-frame-pointer -pipe -Wl,--hash-style=gnu -o .libs/cloog cloog.o -Wl,--as-needed
./.libs/libcloog.so -L/usr/lib64 /usr/lib64/libppl_c.so /usr/lib64/libppl.so /usr/lib64
/libgmpxx.so /usr/lib64/libgmp.so
/usr/lib64/libppl_c.so: undefined reference to `std::ctype::_M_widen_init() const@GLIBCXX_3.4.11' Or not. Yay, symbol versioning. Another thing every Gentoo user has run into when switching GCC versions. To make a long story short, libppl_c.so (PPL) is looking for a versioned symbol in libstdc++.so.6 from GCC 4.4. When we switched to GCC 4.3, that symbol version (here GLIBCXX_3.4.11) no longer exists. Solution? Rebuild PPL. But, this results in a similar error: libtool: link: x86_64-unknown-linux-gnu-g++ -frounding-math -O2 -g -march=core2 -msse4.1 -fomit-
frame-pointer -pipe -W -Wall -Wl,--as-needed -Wl,--hash-style=gnu -o .libs/ppl-config BUGS.o
COPYING.o CREDITS.o ppl-config.o ./.libs/libppl.so -L/usr/lib64 /usr/lib64/libgmpxx.so
/usr/lib64/libgmp.so
/usr/lib64/libgmpxx.so: undefined reference to `std::ctype::_M_widen_init() const@GLIBCXX_3.4.11' As you can see, downgrading GCC versions with gcc-config breaks the linking of a lot of C++ libraries. (this is why I hate testing unstable GCC versions on KDE). So just keep going down the line, attempting to rebuild whatever breaks next, until you actually manage to fix something. If you don't know what package a library belongs to, use one of the many utilities that may be installed on your system, like `equery b` or `qfile`, that maps a filename to package. In this particular case, dev-libs/gmp was the last package needing to be rebuilt. Next, go back up the chain - rebuild ppl, and finally cloog-ppl should build successfully. Switch back to your original GCC version, do a little dance, and go about your day.
|
One step forward (July 31, 2009, 07:37 UTC)
I know I haven’t written anything here for a while but there was a reason. I finally managed to finished my thesis and done with my university studies. Now, I am officially qualified to wreck up your systems…
Damn, I am not a student anymore .
Apart from that, I had to pack everything (~40 boxes omg ) and move out by the end of July. I am moving back to my beautiful island which I miss so much. But not for too long. In three weeks I am supposed to join the army as a radio engineer ( or something ) until May 2010. Ok this sucks big time.
Anyway. I wont be around much but I am sure that our new (qt herd) recruits will do a great job during my absence.
|
July 30, 2009
GNU Emacs 23 is in the tree (July 30, 2009, 20:23 UTC)
When pretesting started I already wrote about the new features of GNU Emacs 23...and now it is there. About two years after the release of 22 this major step in Emacs land has been done and Gentoo provides the version as of today. Have fun, test it and report bugs (not too much, please).
|
I just found that, it is actually very easy to trigger the problem that the -mfix-ls2f-kernel as option could fix. Like just emerging glibc could hang the system. So if you are using linux-loongson/2.6.30/stable branch from this git tree http://dev.lemote.com/git?p=rt4ls.git;a=summary, you maybe want to line 129 of arch/mips/Makefile:
$(call cc-option,-march=loongson2f,-march=r4600) $(call cc-optoin,-mtune=loongson2f) to $(call cc-option,-march=loongson2f,-march=r4600) $(call as-option,-Wa$(comma)-mfix-ls2f-kernel,) Actually, $(call cc-optoin,-mtune=loongson2f) here is not required. BTW, glibc-2.10.1 is ready in my overlay. This version could solve the gdb issue: Error while reading shared library symbols: find_new_threads_callback: cannot get thread info: generic error find_new_threads_callback: cannot get thread info: generic error This happened previously when debugging multithread applications.
|
So for our Vancouver heatwave (I noted 39C away from the water today, in the shade!), it's finally claimed some of my computer hardware. Most annoying, the battery backup unit (BBU) in the newer fileserver, and 1.5 of the disks of the RAID1 array in the old server...
My website and personal email will be offline for a day or two while I ensure my backups are up to date, and redeploy to the newer fileserver (after I buy a new BBU tomorrow).
|
|