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

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

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

Please turn your KDE radio on, and make sure to increase the volume to its maximum level for this important message.

After multiple setbacks we have finally managed to stabilise KDE4 on both major desktop architectures (amd64 and x86), with other teams to follow.

For this and other reasons as discussed , those of you who still use KDE3 should be seriously considering an upgrade in the near future.

The KDE3 support is being deprecated with immediate effect. This means that ebuilds are dropping KDE3 support where they were broken, or clashing with KDE4.

If you wish to still use KDE3, and you want to help others with having KDE3 around, drop a mail to kde@gentoo.org, where we can give you commit access to the special overlay which will specifically contain only KDE3 packages.
This overlay (named kde3) can be easily used via layman.

Sadly upstream is not supporting KDE3 anymore and we simply lack the manpower to keep support for both (as you might have noticed in the past few months KDE3 has become more and more rusty for which we humbly apologize).

Sorry to bring you the bad news and with hope that KDE4 will suit your needs,

Tomas Chvatal
KDE Teams substituting Lead

KUDOS to Nirbheek Chauhan and David Abbott for helping to put this announcement together and Alec Warner for proofreading it.

KDE 4.3.3 was released on Tuesday, with ebuilds instantly available to users in the main tree.

We also have KDE 4.3.1 in stable \o/

KDE 3.5 is on its way out of portage, with kde-sunset being the overlay that will (hopefully) be maintained by users still interested in it.

Finally, KDE 4.4 Beta 1 is due December 1st and you’ll find it in the kde-testing overlay as usual

Yesterday, I wanted to see if I could rip a Blu-Ray disc using my PS3.  I really want to get a BD-ROM drive, but they are so expensive still, and since I can install Linux on my PS3, I figured maybe I'd try and save myself some money and see if I could manage to get one ripped and decrypted.  It actually worked, which surprised me.  Ripping the disc was the simplest thing in the world, but the key on the movie I tried (Willy Wonka and the Chocolate Factory) was too new, and currently only AnyDVD has support for it.  I'd love to buy a copy of that, but it only runs in Windows, and it's really expensive.  Instead, I'll just have to wait for the keys to pop up eventually on the doom9 forums.

The first step, though, was getting the PS3 to run Linux.  I took the shamelessly easy way out (and I don't regret it either) and installed Xubuntu.  I won't go into details about how I got Linux on my PS3 since that's well documented.  I will say that I remember quite vividly now why I can't stand binary distros.  Bleh.

The BD filesystem is UDF.  Providing you have a recent kernel (2.6.20, I think) with UDF v2.5 support, you are good to go.  I mounted a remote share and just dumped the disc to an ISO file onto my desktop.

$ cat /media/cdrom0 > wonka.iso

That was the easy part.

The hard part was trying to get it decrypted.  I had to use Java tools (bleh) to get to the source.  There are three applications you need.  And if you hate digging through forums and using download services, then I've got direct links for yah:

• aacskeys-0.4.0c.tar.gz
• bdvmdbg-0.1.5.7z
• dumphd-0.61.tar.gz

For Gentoo, you'll need to install the JDK to build the aacskeys library and binary.  I just emerged dev-java/sun-jdk and it worked for me (I know absolutely nothing about Java, but my stabbing in the dark miraculously worked).  You'll also need a runtime environment to actually execute the stuff, and I emerged dev-java/sun-jre-bin and that worked fine, too on my amd64 box.

For aacskeys and Gentoo, you'll need to apply this patch that I cobbled together from what I found on the doom9 forums to get it to compile.  It just fixes the Java include directorys for the Makefile.

Now, I'm still a bit fuzzy about what each program does, and whether you need all of them or not, so I won't go into a lot of detail.  What you want to use, though, is the dumphd program.  But to use it, you'll need to copy the aacskeys library and a file from the bdvmdbg package as well into the path or same directory as the dumphd program.

Once you have that, you can just run dumphd.sh and it'll fire up a simple little GUI telling you if it has all the libraries it needs.  Then you just specify the source and destination, and aacskeys will see if it has a working key to access the disc.

I can't really give much more detail than that, since I'm so new to this.  Suffice it to say, if you read the accompanying README doc that comes with each one, you'll get along just fine.

It took me a long time last night to get just one disc ripped and transferred over my subnet to try it out, and by the time I managed to get it mounted (mount -o loop -t udf wonka.iso /mnt/udf) and access it, it was pretty late.  The keys I had didn't work for my disc, and I didn't want to try the whole procedure over to try another disc.

Anyway, good luck if you try it.  One thing that impressed me is how much simpler it was than I thought it'd be, but what a pain it was trying to figure out where things went wrong.  The doom9 forums are a good resource, but not exactly the best place to find clear, concise information for a beginner.  That part was frustrating.

Personally, I don't think it's worth the hassle right now, the way I did it.  I'll get a BD-ROM sooner or later so I don't have to transfer the content over the network and can instead just test it directly.  But, I started out to see if I could at least get a copy of the ISO and get the tools running all without Windows, and I can.  So, that's progress right there.

In ripping my DVDs, I try to future-proof it as much as I can, by putting in as many elements as I *think* I might need or want someday down the road.  One of those elements is subtitles.  There are three types of subtitles that can be on DVDs -- VobSub, closed captioning and SDH -- and the first two can be extracted fairly easily.  I have no idea how to access the SDH ones.  I think you need either a newer DVD player or a Blu-Ray one.

I've been ripping my TV shows, and so far I haven't seen any really hard and fast rules on what to expect with them on DVD.   Part of the reason is that I just haven't been paying much attention to subtitles until recently.

I was playing with ripping one show last night, and I saw the CC logo on the back of the case, so I went to check the rest of my library to see which other ones had it.  Nearly my entire library of Warner Bros. DVDs displayed the logo -- even for much older cartoons (Looney Tunes, Scooby Doo) -- once again staying consistent with the fact that the studio puts a lot of effort into the quality of their releases.

I just started playing with extracting CC though, and just barely wrote the code to my DVD ripper to extract them, so I have no idea what the other series are like, if they have subtitles or not -- VobSub or CC.  I usually don't find out until I actually go to rip them.

Extracting the closed captioning subtitles is a lot easier and faster than getting the VobSub streams.  For Linux (and Mac and Windows) there's a nifty OSS program called ccextractor.  Once you have your VOB video file on your harddrive, just run that on the movie, and it will create an SRT subtitle file of the closed captioning text.  It's great, and really fast, taking probably under a minute on a 60-minute video on my box.  Comparatively, when ripping a VobSub stream, you need to read the DVD directly which causes its own bottleneck, and then demux the entire stream.  It takes probably around 3 to 5 minutes for an episode of the same length.

Another thing I like about the closed captioning titles is that because they are extracted as SRT, it's easy to look through them since they are just text files.  If you're really anal, you can correct typos yourself.  The VobSub subtitles are all bitmaps.  I've also noticed that on some DVDs, where there were issues with framerates or something else, that the VobSub timestamps will be off ... and sometimes either they will show up clumped together at the beginning of the film or the sync will be way off.  I think that this has to do with the dumping process, somewhere, but I'm not sure.  I've never really taken the time to pin down the source.

So, with closed captioning being easier and faster to extract, as well as editable and the timestamps haven't had any issues for me (yet), it's quickly becoming my preferred subtitle format.

There's only one small issue with using ccextractor, and that is you won't know if there are any captions in the VOB until after it's made its trial run.  The program will create an .srt file regardless when you run it, but the file will be empty if it couldn't find any.  That's the only drawback.  With VobSub, you can know if there are subtitles just by probing the DVD using lsdvd or something similar.

Muxing it into matroska is simple, too.  Just pass it as a file argument and you're done.

As a sidenote, while my bend application that I wrote and use to rip DVDs would be a major pain to setup for someone else, I've rewritten it recently so that it uses individual classes to access every object directly: DVD, DVD track, DVD VOB, Matroska file.  They are standalone classes written in PHP if anyone wanted to use them, feel free.  You would also need my tiny class of shell functions as well, since they all make calls to it.

The DVDVOB one makes it simple to extract the subtitle stream.  In fact, all the classes make things relatively simple.  They have made writing my code so much simpler.

After few months of delay, Curses::Toolkit is now available on CPAN.

Curses::Toolkit tries to be a modern toolkit to implement semi-graphical interfaces using Curses. It's inspired by Gtk.

I gave a presentation of Curses::Toolkit at the French Perl Workshop 2009, and at the Open Source Developers conference France 2009. BooK presented it as part of a Lightning Talk at YAPC EU 2009 where I couldn't participate. Thanks to him for that. I will try to participate to London Perl Workshop this year and give a talk about it as well. I have received quite good feedback from people and users about it.

I'd like to mention that Jerome Quelin helped me with the initial release, injecting some Dist::Zilla magic into Curses::Toolkit. Thanks, Jerome.

What next ? I'll try to post a video of what is currently possible with Curses::Toolkit. I need to add more widgets and signals, and fix some bugs. Also, migrating to Moose is on the todo list. The module is usable now, but you can't really build a very nice big application with it.

Want to help ? If you have some free time, please consider helping me on next development of the module. You don't need to be a coder, here are some of the things you could help with :

• Improve documentation : current documentation has some errors, and a better front page for the module would be good.
• Create a Tutorial : preferably in POD, but not tied to follow sub-modules' names
• Help implementing additional widgets
• Create new themes : it's all about colors
• Help the migration to Moose

As Linux-Mag points out (Gentoo Optimizations Benchmarked) using gcc optimizations for "omg, teh speed" is not all that practical. Sure, I'll add some compiler flags here and there as long as I am compiling everything anyway but I don't consider that a feature of Gentoo Linux.

I actually prefer Gentoo for the package management and customization via USE flags (even with the headaches that they cause sometimes).

Recently, Aaron Plattner from NVIDIA announce libvdpau 0.2, which a wrapper for driver specific VDPAU implementations. You may have noticed that nvidia-drivers shipped a libvdpau.so library for a while now for apps to link against while placing their actual implementation in libvdpau_nvidia.so. Newer ebuilds of nvidia-drivers will no longer install libvdpau.so, nor any of the headers and install will rely on this being installed. Other applications, like MythTV will instead depend on x11-libs/libvdpau.

In addition to this change, there’s a new package called vdpauinfo in the tree. Some people might know it from the NVNews forums as vdpinfo. However, Aaron got the author’s permission to add it to freedesktop.org and rename it to vdpauinfo to match the library.

As always happens when we see a new xorg-server release people start to wonder why the Gentoo ebuilds for nvidia-drivers have blockers for the new release. To help clarify this I’ll post an ASCII table showing the current support.

driver series   maximum ABI
-------------   -----------
71.86.*         2.x
96.43.*         5.x
173.14.*        5.x
190.*           6.x

xorg server     video ABI
-----------     ---------
1.7.*           6.x
1.6.*           5.x
1.5.*           2.x

As you can see from the above, the 71.86.x series has gone into very limited maintenance mode. I would be surprised to see very many updates, if any at all to it in the future. However, for users of the 96.43.x and 173.14.x series, NVIDIA has confirmed to me that there will be an update to the latest xorg-server ABI change. This update though does not have any definite dates so I can’t provide any. I recommend users of that series stay with xorg-server-1.6.x releases for the time being so they can have a smooth X experience.

I had this genius idea about using sshfs with rtorrent. I thought that this use case would fit best in situations where you have good bandwidth but not much diskspace, such as my linode VPS (review). So, I'll attempt to share my findings in this regard.

If you are not familiar with rtorrent. You just need to know that it is a powerful, lightweight bittorrent client. It has a "watch" feature that watches a directory for new torrents, and obviously it can put downloaded files in a specified location. I tried both of these with sshfs.

First, I was having trouble with rtorrent just 'freezing' up when I put a torrent file in the sshfs accessible watch dir. I didn't quite know what was wrong here. Research led me to rtorrent bug 322 and that sshfs did not support filesystems without mmap properly. Darn. More research led me to a recent kernel commit that looked promising. Low and behold, reboot my host with 2.6.31.x kernel and rtorrent works with sshfs watch and destination directory. Yay.

Well, not so fast...

The performance is quite poor with the destination directory on sshfs. This is to be expected because now your download speed for torrents is limited to the download speed of your final destination. But, rtorrent was only giving me a sustained speed of 1/4 of that demonstrated with a simple file copy to the destination. I speculate that this is from the rtorrent overhead or maybe fragmenting? Not sure exactly and I don't care. My solution to this was to use the rtorrent "move on finished" feature that downloads the file to local disk and then moves it to sshfs destination after it is finished. Amazingly, this works quite well.

My testing scenario was the following:
-79MB Gentoo 2008.0 install cd torrent. With the complete sshfs solution, it took ~6 minutes to download (to the sshfs destination) and then 5 minutes to check the hash. So, roundtrip of 11 minutes from start download to seeding. With the on_finished solution, it took 1 minute to download (to local disk) and 1 minute to check the hash and move to the sshfs destination. For a roundtrip of ~2 minutes from start of download to seeding.

In conclusion, this isn't the perfect solution because you impose a large bottleneck into the mix and unintended I/O activity on the local disk. However, it works for me and what I am doing. Maybe it will give someone else some ideas in the future.

http://cia.vc/stats/author/eva

My CIA profile went from about one commit every 17.35 housr to one every 16.56. The difference does not seem big but the calculation is diluted on about 6 years due to a KDE dev sharing the same nick. This amounts to 158 commits tonight.

~arch is now at about 85% of completeness for Gnome 2.28.1, a few commits are missing due extra complexity (hey it still took my 3 hours to do that). Beware that this release still has a few rough edges, especially policykit migration buts. So if you get cut, please come to bugzilla but do not expect sweet words and attention if I see comments like "dude why do you keep on breaking ~arch". It's ~arch, beat it.

The new server I had setup few weeks ago got hacked, brute force ssh attacks being made from it... I had spent some time setting it up, and now I'm bored.

So, I decided to migrate my blog to a hosted solution. As I'm a big fan of movable type, I decided to give Typepad a go. So this is yet another rebirth of my blog (I think it's the 6th time now).

I'll use that opportunity to catch up with the Perl blogging Iron Man competition.

More to come about Perl and Curses::Toolkit, my baby :)

In this podcast I talk about my progress learning Bash for Gentoo ebuild development.

LINKS:
Bash By Example
http://www.ibm.com/developerworks/library/l-bash3.html
Linux Command Line and Shell Scripting Bible
http://xrl.us/bfzigo
Learning the Bash Shell
http://oreilly.com/catalog/9780596009656
Gentoo Tools
http://devmanual.gentoo.org/tools-reference/index.html
Sed By Example
http://www.gentoo.org/doc/en/articles/l-sed1.xml
Bash Guide
http://mywiki.wooledge.org/BashGuide
Grep
http://www.panix.com/~elflord/unix/grep.html
Awk
http://www.grymoire.com/Unix/Awk.html

irc network freenode channel #linuxcrazy

Download

Benjamin wrote a comment on my last post, and I'll share my answers here because those questions come up every now and then, so it's better to try to inform everyone. (That and I never write on this blog, so this is a perfect excuse to do so)

If you assume compile problems, why is that thing unmasked?

Xorg-server 1.7 is not getting stabilized, it's just getting unleashed onto unstable. Unstable means exactly that. Of course we try to do our best and we won't release something we know will break. The idea behind unstable is for users to test the new and shiny stuff before it hits stable.

If you don't want to help fix bugs, use stable. It's as simple as that.

I've always been irritated by the way the xorg team handled masked/unstable/stable releases, as even rc's were unmasked at times.

Releases in X-land are tough. The numbers almost mean nothing. For instance, the last stable version in the 1.5 series was 1.5.3-r6. And despite the apparently stable version number, it currently has 80 patches to make it run smoothly.

On the opposite side, the current stable server is 1.6.3.901-r2, which is indeed a "pre point release" only has a couple patches. And 1.7.1 doesn't have any patches.

So don't let the version number fool you, they mean almost nothing.

As for what we put in portage, well X is a complex piece of software. It used to have more than a million lines of code and it's been getting some tough love these last 2 or 3 years. And up until recently, drivers were a mess. I had shivers every time a new driver was released : "How many systems will this break?" was a question I asked myself over and over.

There are probably a lot of people who put the xorg-server in package.keywords because they needed/wanted feature X/Y or because it fixed some bug for them (it did for me). So now I get a release that possibly breaks build in unstable?

Again, unstable is for power users who are not afraid of filing bug reports if something breaks. We try to make sure that things don't break every day, but Gentoo being a source distro with billions of possibilities (USE flags, CFLAGS, arches, packages, ...),you can't reasonably expect us to try every possible combination.

So we ask for you help (via bugzilla) in return. Gentoo is a community distro, after all.

So there, that's it for today, I hope y'all know a bit more about how we manage X and unstable packages.

Right now at work we’re currently having an issue with branch offices and SVN. We’ve got a machine with some decent power with decent disk space handling our SVN repos. We’re running a 1.6 version repo that was dumped and reloaded with 1.6 so its using the newer format fully. However we still have employees at branch offices that often complain about the poor speed of SVN. Oddly the biggest complainers were Windows based devs and people using obscure (at least to me) GUI SVN tools. Currently our branch offices are all linked back to our main office over a VPN link with a dedicated 1.5mbit up and down to each remote office, with a possibility to burst up to 80% of total VPN bandwidth. A few complaints were attributed to poorly coded SVN clients (i.e. one employee’s client would perform an ‘svn log’ on the top level of the repo and filter out the correct level of messages on the client side). However the complaints have remained constant. To mitigate our guy handling our infrastructure configured SVN hotcopy repos at the branch office servers that allow everyone to get their data off those SVN servers (repo UUIDs were sync’d) and then commit back to the main office.

To remedy this I’ve created a new capability in SVN trunk. I’ve called it ‘commit-redir’. Basically a branch office employee can now checkout their code from a local SVN repo and commit as they normally would to that server instead of having to go through the time consuming steps of switching back to the main office repo. Transparent to them, the client advertises the ‘commit-redir’ capability to their local server, which then sees that its a read only mirror and replies back with the correct URL they should present the commit to. The client takes this response and re-submits the commit back to the main office. Net result, employees can enjoy the full speed of having a local mirror of SVN except when committing. They don’t have to jump through loops to use that local mirror and commit back.

Now I’ve still got some bugs in the code and some touch ups to do. We’re also not actually running the code at the office yet due to the afore mentioned bugs but I’m hoping this week to submit the code upstream and to start running it at our offices.

NVIDIA has officially blessed the 190.x driver series to replace the 185.18.x series. Release highlights include:

• xorg-server-1.7 support
• OpenGL 3.2 support
• VDPAU decoding of MPEG-4 Part 2, DivX 4, and DivX 5 depending on your GPU
• Support additional GPUs in the GeForce GT series

For more details read their release notes, here.

Gentoo has had a few different developers maintaining “unofficial” drivers in the 190.x series. However there’s a few outstanding issues with those ebuilds that still need to be resolved before they’re unmasked. I’ll hopefully push 190.42-r2 unmasked later on this evening.

Last night I installed UT2004 on my laptop, after not playing it since June. The laptop in question is an older ThinkPad R61i, with an Intel X3100 graphics chip. I know -- not the best for gaming. However, most online reports I found indicate that it's acceptable for such an old game as UT2004, so I figured it'd be worth a shot. The Intel graphics drivers have made a lot of progress in the last two years, especially on the 3D front, right? Right?

Kinda. After reducing all settings to "low" and dialing back the resolution to 1024x768 (native is 1280x800), the game is playable, but with very uneven framerates. Looking toward the middle of a map, or anyplace with a lot of action, introduces a good stutterfest; frames are down to between 8 and 18FPS. I enabled a few extra options such as pixel shaders and VBOs in UT2004.ini to add a bit more performance, but it's still marginal.

I'm rather disappointed. I'm not having nearly as great an experience as other Linux users, and certainly not as good as the Windows gamers who've benchmarked Unreal on this hardware. However, I did also catch the huge xorg-server 1.7 update as well, so maybe there have been some performance regressions since 1.6. It makes it a little hard to determine the areas that could use tweaking. I don't have anything special in my xorg.conf, just a default resolution. It's possible there's a setting I'm missing.

I'd like to try UT2004 on my desktop workstation, which has a RadeonHD 4550 card, but all reports indicate that even the latest git checkouts of the open-source drivers still don't work with Unreal. Apparently the game can't even launch, much less run at playable speeds. But as rapidly as the drivers are maturing, I'm hoping this'll be fixed in a month or so. Call me optimistic.

* * *

It looks like Abiword 2.8.0 was released today, so I wrote an ebuild and made it available in my devspace. I've been hand-writing these things for awhile. It took quite a bit of research to determine what went into the 2.7 betas, and now I'll have to do another overhaul of the 2.8 ebuild to account for the new plugin system. There's no longer a separate abiword-plugins package; they're all distributed in the base 2.8.0 archive. This means there will be a lot more tricky configure checks and USE flags, which sucks from a flexibility standpoint. Keeping the plugins in an external package was much simpler, so I'm a bit disappointed by this upstream decision.

Still, right now you can download and install Abiword 2.8.0 using my ebuild. While it needs a few cleanups, it will get you set up with a fully functioning basic Abiword install, though the only available plugin (as shown in the "Plugins" dialog) is .odt support.

This new version launches much quicker than 2.7.10, and it seems to have fixed all the rendering errors and even the crashes that happened with basic operations. Basically, you can click stuff now without worrying.

Cleaning up my ebuild is a long task, thanks to those darned plugins. Patches welcome, or I suppose you could always just wait and see what ends up in Bugzilla.

It's out there now, available in ~arch. Like always, you'll need to rebuild your drivers, just look-up the command given by the server's ebuild (use eread if you've lost the output).

This release took a little longer to unmask not because of the server (it's a nice change). It's because a lot of headers were moved around from library packages to proto packages and vice versa. The ABI of X libraries has not changed, but I'm pretty sure there will be compile errors in some packages.

If that's the case, please file bugs in bugzilla.

Thanks for reading this public service announcement.

Edit: There will not be a package.keywords list for stable users. Xorg-server 1.7 is intended for ~arch users only, at this moment. And all bugs from stable users will be closed INVALID. We will start creating lists when we want to stabilize it.

I've been having a slew of issues running Apache on my Linode VPS, which I'm still trying to pin down, so in an attempt to offload some of the usage, I'm now going to use Feedburner to provide the RSS feed for Planet Larry.

I know I've played with Feedburner in the past, and kind of flip-flopped on whether to use it or not, but this time I'm sure I'm gonna stick with it.  It's better for users, since they will always have a feed available (whether I have issues or not), and it's better for me since I can offload that part of the network traffic, which is actually quite a lot.

I've already updated the feeds and my apache config to do a permanent redirect, but if you want the feed URLs directly, here they are:

• Planet Larry: http://feeds.feedburner.com/planet_larry
• Larry the Universe: http://feeds.feedburner.com/universe_larry

Sorry for the inconvenience.  It seems like everytime I post about Planet it's bad news or maintenance.  Believe me when I say that it aggravates me far more than it does you.

Specifically, the issues I'm having is that Apache is sucking up all the available RAM, of which I only have 360 megs on my account.  It's then rolling over to using all the swap space as well, which only slows things down even more.  I've just started playing with tweaking the MPM configuration a bit, and I'm still trying to find a reasonable solution for my configuration.

In the past, the Linode had been seizing up occassionally, and I'd normally just reboot it and get on with my life.  Recently, I installed monit (an awesome app), and pinpointed that the issue seems to always be with apache.  Now, I'm just trying to narrow it down even  more from there, but offloading the RSS feeds seems like a good step to take anyway ... I get gigabytes of traffic per month just on that, believe it or not.

I'm toying with the idea of setting up lighthttpd instead, but I really prefer apache, and would rather set it up to behave in a low memory environment instead.  So, for any downtime in the near future, chances are it's just me tweaking something.  At least now, thanks to monit, I have a much better idea of when something goes wrong.

Oh, one other tweak I've made is that the planet script itself is more robust as well.  That thing used to run out of control, but I've made some changes that will ensure that if it runs away, at least it won't bring down the system.  I also started playing around with the idea of writing my own feed parser to replace the Planet software completely, and it looks like it's going to be much simpler than I imagine.  I haven't actually started down that path yet, since I have bigger projects to complete, but I'm actually enthusiastic that it'd be far, far simpler than I imagined.

Shortly everyone will start seeing MythTV 0.22 Release Candidate packages (you won’t see Release Candidate 1 but a newer revision) appearing in the tree available to ~arch. Gentoo users need to know that the upgrade path won’t be smooth sailing. Unfortunately, the MythTV developers incorrectly use MySQL which results in data corruption which must be manually fixed. The steps to fix this are available on their website at, http://wiki.mythtv.org/wiki/Fixing_Corrupt_Database_Encoding.

Now you might say to yourself, “hey! That page blames distros specifically Gentoo for the data corruption!” I’ve discussed the issue in length with several developers in the #mythtv-dev channel and unfortunately I can’t change their tune. So all I can do is explain the issue to you, the reader, and let you be better informed.

MythTV originated as a project created by a US based developer and such it only needed to support the needs of the basic US English language set. As time wore on the project gained overseas attention and needed to support non-English character sets and data. A wise decision was made to switch to UTF-8 string handling in all of MythTV so that it would work no matter the language. However, the change was implemented poorly. The MythTV developers implemented UTF-8 conversion within MythTV while leaving their database encoding the same. This wasn’t a problem technically at first because MySQL pre-5.0 defaulted to latin1 encoding (this change was made when MySQL 3.23 was all the rage, especially for the MythTV devs who were overwhelmingly Debian based devs at the time). Fast forward a few years when MySQL released 5.0 and finally acknowledged they need to support UTF-8 out of the box. Gentoo followed upstream’s wishes and shipped their MySQL with UTF-8 as the default and worked with many package maintainers to resolve issues. Several distros (Red Hat, Fedora, Debian, Ubuntu) chose to remain at latin1 as their default so they wouldn’t have to deal with any package issues. Fast forward a few more years (hey let’s be realistic, MythTV releases take forever to come out) and MythTV finally switches to Qt4 (cause its only been almost a year and half since Qt3 was completely end of life’d) and their data conversion code needs to go through some changes. Unfortunately, this changed the on disk representation which is where we’re left now.

The real fix would have been for the developers to read the MySQL Character Set Support page and properly use the database to store the data its suppose to store instead of assuming everyone’s MySQL database would always be hard coded to latin1. And not just the database, but the server, the client libraries, the database and the connection. When they’re in fact sending UTF-8 data.

As a follow-up for those that will ask, no forcing MySQL to be recompiled with latin1 before the MythTV 0.22 upgrade will not fix the issue. In fact it will make it worse since MythTV 0.22 will error if it detects your connection character set is UTF-8 but if you recompile MySQL with latin1, then it won’t know that your database may be corrupt. I recommend following their instructions to fix the issue.

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

Just added gnome-2.28.1 ebuild to the overlay, only had to keep two dependencies down. Since we are now finished with gnome-2.28 core, time to squash bugs, there is quite a number of them already, if you want to participate, just visit the overlay status/TODO or status/BUGS files, or visit gnome 2.28 official release tracker bug

Played with gnome-shell, kind of nice but still needs applet work done as I can't use gnome-globalmenu applet anymore and I'd like to keep to vertical space real estate. Plus I don't like the actual replacements for notification area and clock applet, they do less. I bit worried about speed in activities menu as well, it's damn slow on my Core2@2.2Ghz which I can't understand.

Also worked on some other ebuilds like geoclue, emerillion and seed, not easy on downstream packaging so delayed until further notice.

So, after being completely betrayed[1] by Ext4 not once, but twice, I decided to evaluate my FS options for /home .

• FAT* are not an option, neither is NTFS.
• Ext2 is primitive and HFS/HFS+ is just not Linux.
• JFS is nice, but (atleast parted) doesn't support grow/shrink.
• I've used XFS before, and found it to be more reliable than Ext4. However, deleting dirs with thousands of small files is too slow (a common operation when compiling)
• ZFS would've been an option if my earlier experiences with ZFS-FUSE weren't so horrid.
• Did not even consider NILFS. It's too new, and I don't know much about it.

It ended up being a choice between the reliable Ext3, or the new-fangled Btrfs. Why Btrfs? Because I've been using it as my Gentoo Distfiles and Portage tmpdir since v0.16, and found it to be the /most/ resilient to power failures of all my partitions.

I ended up selecting Ext3 for /home, but let's see why.

What's missing in Btrfs:

1. Growing the filesystem to the "left" of the partition. The error message when you try this is cryptic (common in btrfs-progs). However, since for other FSes this essentially involves "move to left and grow to right", I suppose the "move" part is what's missing in btrfsctl.
2. Pathetic ENOSPC handling. It either throws an ENOSPC at around 75% or when the metadata space fills up. Not sure which, but it's supposedly fixed for 2.6.32.
3. Volumes once created cannot be deleted. Again, fixed in 2.6.32.
4. Parted doesn't support editing/creating Btrfs partitions. Support for detecting it was proposed recently; but, I still don't see it in either "master" or "next". This is not a Btrfs problem, but certainly affects whether I'd use it.
5. There were other minor irritants (with btrfs-progs, mostly), but those will go away with time

Ext3 might have bad performance (especially w.r.t fsync), but atleast it's more reliable. In conclusion, I'll use Ext3 in data=ordered mode for /home till 2.6.33 is out; and then I'll convert my Ext3 partition to Btrfs and forever be happy :}

Well… it has been a while… No, I haven’t gone AWOL, just been busy with other things for the past few months.

I’m now in the process of updating my MIPS boxes so that I can resume testing packages. I now have a stable kernel on my O2 (I nicked Debian’s kernel image… to install you just run ar x on the .deb, then unpack the data.tar.gz created into your /) and can seriously look at the userland.

First priority will be developer-related tools that I know well and can test quickly… Subversion is one that I’ll probably tackle, since the version we currently have keyworded is masked. Ditto for git. I’m sure I’ll find other things to get started on, but those two will make doing everyhing else easier.

I’ve also started on some new profiles. People can have a look at http://git.longlandclan.yi.org/?p=gentoo-mips-profiles.git or clone the repository at git://git.longlandclan.yi.org/gentoo-mips-profiles.git to give them a try. When I’ve given them a good thrashing and am satisfied, I’ll look at merging them into the tree, but for now, this is my staging area.

Hopefully with a stable base system upcoming, and new profiles, then I’ll look at new stages, and get this show back on the road.

You are running a stable x86 system (at least almost, and for the core components like kernel, system set and X)? Great, we are looking for your help. If you want to try out the following packages and report back (even if everything is running smooth) to me (fauli AT gentoo.org) or the team (x86 AT gentoo.org), we would be happy. Stabilising so many core compontents that might render you system unusable is a big thing, so a lot of testing is appreciated. The packages in detail:

• sys-fs/udev-146-r1
• sys-apps/util-linux-2.16.1
• sys-fs/e2fsprogs-1.41.9 and sys-libs/e2fsprogs-libs-1.41.9
• sys-apps/hal-0.5.13-r2
• sys-apps/usbutils-0.82
• sys-fs/mdadm-3.0
• sys-fs/lvm2-2.02.51-r1

Thanks in advance to everyone who cares

Attention Gentoo Community,

After numerous bug fixes and enhancements the Ten Team would like to encourage everyone to try out the 10.1 release.

A FAQ is available to assist you. We have also started a thread in our Forum. Please post any BUGS you encounter.

Please download the latest testing release for your architecture Gentoo Ten Live DVD 10.1 x86 | Gentoo Ten Live DVD 10.1 amd64.

Thanks for your continued support,

The Gentoo-Ten Project

David Abbott contributed to the draft for this announcement.

Recently, I've noticed some behaviour by package maintainers that really annoys me. I'm talking about the way stabilization requests are made. Normally, a package maintainer opens a stabilization request bug (STABLEREQ) detailing which version(s) of which package(s) he wants the arch teams to test and stabilize.

Another closely related request which suffers from the same problems I'll detail below are keyword requests. Those are pretty much the same as STABLEREQ, but for "~arch" instead of "arch". Also, the testing required usually is not as strict as that for STABLEREQ for obvious reasons.

For simple packages, neither usually causes problems. For complex packages, this may mean that dependencies need testing and keywording, in some cases five to ten packages on top of the one requested. Unfortunately, some package maintainers have taken up the habit of just dumping the request for their package in bugzilla without checking what dependencies might be needed. Checking the dependencies also involves which versions of the dependencies actually work, which ones are stable (yes, this might mean talking to other package maintainers!).

Another related gripe I have is being pushy with time frames when stuff should be tested and stable and when trouble comes up (test suite fails etc), completely ignoring the bug report the arch team files for half a year or longer.

This kind of added workload (of rather dreary work, to boot) is what makes arch testing so tedious sometimes. Not to mention the burn-out it causes. Not getting any positive feedback (from either users or other devs) doesn't help, either.

Guess I'm turning into a grumpy old dev. But still, try to be a bit nicer to the arch testers, mkay?

PS: Note that there are very positive counterexamples, too: the emacs guys always provide test plans, the security guys are always nice to work with, too. And of course several individuals who are just nice to work with.

It is with great pleasure that I announce the release of Avogadro 1.0.0. After many years of work we have released what we consider to be a stable Avogadro release on Mole Day, which seems appropriate given the projects's name. There are still some rough edges, but I think this is a good release. With your help we can fix bugs in the release while working on new features in trunk.

What better time to look back to the beginnings of Avogadro. There was a blog post made today by Sourceforge about Avogadro detailing a little of that history. I have also made a code_swarm movie visualizing the history of the Avogadro project. There have been quite some changes in that time both at a project level and a personal level.

I would like to thank Google for sponsoring me for a GSoC project in the summer of 2007. Also Geoff Hutchison for giving me the opportunity to work with him at the University of Pittsburgh on interesting computational and visualization projects. Then there is my new employer, Kitware, who have provided me with an exciting opportunity to push scientific visualization and cross platform development to its limits.

To finish off a great day, my wife has informed me my new espresso machine has arrived! I am going to Camp KDE in January too!

I had to spend a few hours trying to get Machinarium(flash required) running on my laptop the other night. Turns out the solution was too easy:

  # USE=32bit emerge -av www-plugins/adobe-flash

Damn.

PS. if you like old-school adventure games, puzzles, or desolate post-apocalyptic cityscapes populated by melancholy anthropomorphized robots (yay), you could do worse than support Linux gaming by dropping 20 bucks on this fine piece of work.

Well, I finally broke down and created a blog. I’ll mainly be posting Gentoo-related stuff here, assuming I remember to update it.

That's not the first post about elog, previously Gilles (eva) posted an excellent entry about that (he was a slightly angry probably ). All these entries are published in order to warn users and they have its importance...So based on that fact it would be really nice if users start reading them

Last week, I did read at least 4 bugs about a problem due the newer version of shared-mime-info (which includes a new database format)... If you as users would read your elogs, guess what? Yes you would find the solution in elog messages.

Important...why ?

When a developer has a important message to deliver to a set of users for a given package, usually he uses elog (elog is logged => no excuses..).
Consider the previous example with shared-mime-info, you will have a lot of problems when you try to open some files (typically gnome/kde startup) which would have not happened if you have a look at your logs.

awesome... but how I can read them ?

That's seriously simple :

1. If you're a geek who loves GTK+ based applications (like me ) have a look at elogviewer
2. Use eread (c.f: man eread)

But for our sanity and peace in our souls "READ THEM" before you post a bug .
That will help us a lot, by implicitly reducing the number of useless bugs, and in this way, we will not have to repeat things 50 times.

have fun with gentoo

edit: many thanks to scarab for typos & grammar

Again today I was hit by Stunnel's excessive logging behaviour, causing my log files to grow rapidly with messages like:

stunnel: warning: can't get client address: Bad file descriptor


Which is caused by my Wifi going offline, I fail to see why Stunnel should log hundreds of lines each second if the network is unavailable....

In my five minute search I couldn't really see how I could get Stunnel to change logging behaviour, without disable logging alltogether.

However I finally figured out how to suppress repeat messages with Syslog-ng, like Metalog did back in the old days when I used that. Stunnel from 2.1.1 and up has a suppress(X) option that is not documented very good. With the suppress option Syslog-ng will apparently suppress repeat messages in X second intervals. You can use it simply like this:

destination messages { file("/var/log/messages" suppress(30)); };


So with a bit of luck I should not be hit by Stunnel logging again.

Yeah, this bug is back again. Turns out the code that fixes the paths in gcc's own .la files was broken on new version installs. This means that everyone in stable that updated to gcc-4.3.4 and anyone in unstable that updated to 4.4.2 in the last week or so should resync their portage tree and rebuild gcc now.

See https://bugs.gentoo.org/283761 for the poop.

We won't be doing a revbump because this wasn't version specific. It just sucks that no one noticed the problem until a new version was released.


edit: if you're still getting errors when building, such as

  /bin/grep: /usr/lib/gcc/x86_64-unknown-linux-gnu/4.4.1/libgomp.la: No such file or directory
  /bin/sed: can't read /usr/lib/gcc/x86_64-unknown-linux-gnu/4.4.1/libgomp.la: No such file or directory
  libtool: link: `/usr/lib/gcc/x86_64-unknown-linux-gnu/4.4.1/libgomp.la' is not a valid libtool archive

where "4.4.1" is the previous version of gcc you upgraded from, run

  # fix_libtool_files.sh <old gcc version>

The last news I wrote about the Ebuild mode for both GNU Emacs and XEmacs is some days old and covered version 1.10. Meanwhile we added some functionality that will greatly improve your user experience. All detailed changes are to be found in the shipped ChangeLog file, but I want to give a rough overview about the most important features and the main contributor.

• faster and more elegant code (ulm)
• a manual in Info format (fauli), see C-h i under section Gentoo or Emacs, needs fine-tuning, patches welcome
• support for GLEP 42 news items (ulm)
• add skeleton support for ebuilds/news items from scratch (ulm)
• keep eselect mode in sync with eselect features (ulm)
• keep keywords in sync with eclasses and adding new ones, like mono and kde4 (fauli)
• reinstate compatability with GNU Emacs 21 (ulm)
• support for eblit files (ulm)

Now I want to move the spotlight onto the skeleton modes: Pressing C-c C-n in an empty file with ebuild extension, or whose file name matches the GLEP 42 requirements for a news file, will guide you through the creation of a new ebuild. You are asked for the needed items and with the tab key you can often choose from a list with sane entries. Especially news item creation gets easier as this is a seldom task for developers and thus error-prone while being a good measure to communicate important changes to users.

Ok guys, buckle up, I've finished reviewing Gnome 2.28 ebuilds except for the gnome-shell stuff. Now Gnome 2.28.1 is expected on wednesday so we can start bumping like crazy to be half-decently on time this time (feels like we'll never be done with the catch-up). There are still quite a few problems with packages as noted in my papers and files under status/ in overlay but upgrade experience should be smoother.

If you are about to test the overlay, please keep us posted on your problems (or your non-problems too) by contacting us on #gentoo-desktop or by filling bug reports. Thanks again to everyone who kept the overlay updated during 2.27 cycle.

edit: fix typo thanks to remi.

Disclaimer: Please correct me if you know better. Thank you.

Back in KDE 3 I’ve been using WIN+D repeatedly to minimize all open windows (”show desktop”). In KDE 4 the “show desktop” feature seems to have been replaced by “show dashboard” (CTRL+F12), which is quite a different thing and not what I want.

As missing the minimize-all hotkey started really bugging me I invested a little time to find out if this is really the end. Luckily it’s not though I can only present a workaround rather than a “real solution”.

The easiest (only?) way to assign global hotkeys to programs in KDE 4 is adding an item to the KDE menu. So if we had a program/command to trigger a toggle on “show desktop” we were done. I found a tiny Bash script to do that:

#!/bin/sh
target=on
if xprop -root  _NET_SHOWING_DESKTOP | fgrep '= 1' ; then
    target=off
fi
wmctrl -k ${target}

(requires xprop and wmctrl, i.e. x11-apps/xprop and x11-misc/wmctrl in Gentoo)

Put that in a file called toggle-show-desktop.sh or so, make it executable and add a KDE menu entry for it:
(The Menu Editor can be found in the contect menue of the “KDE button” also know as Application Launcher Menu.)

My next post/rant on KDE4 will probably be about the removal of vertical gradiants as desktop backgrounds. No, I don’t wat to do that with Gimp. Seems like I’m the only one ever having used it. Anyway…

I've been prodding at the concept of the new network script in OpenRC-0.5, and I'm at a loss to try and see why Roy has decided to toss the old network config system away. The new system doesn't have a lot of capabilities, and most significantly totally loses the ability to restart a single interface without affecting the rest of the system. If it's just for a rewrite, then I'm not too worried, but unless all the functionality is still there, I'm worried we are going to move backwards with it.

At the same time, I don't think many people are aware of how powerful the "old" network configuration mechanism is. The net.examples file is only the start, once you start mixing in the pre/post calls, there's a lot of power. It's capable of some feats that I don't see used even in certain parts of the Gentoo documentation^[1]. I've put together some of my gems of conf.d/net, and if you have some, I'd love to hear them. Leave a comment or email me the scripts, along with a description.

Configurations available

• Easy to maintain HE.net (Hurricane Electric) IPv6 tunnels - Download
• Running two ISPs at home (basic multi-homing) - Download
• "Enterprise" multi-homing setup, with 4 paths to the Internet - Download

Hosting

I've also started a bit of storage in my Gentoo webspace for these collected works of network configuration, with a bit more documentation.

Notes

1. The Gentoo docs have this for IPv6: Gentoo IPv6 Router Guide, Tunnel Configuration. You could bring it up manually, or you could just take the IPv6 config above and use it straight with your variables filled in. Volunteers welcome to help merge that config into the Gentoo IPv6 documentation.

Having been a crazy ‘zen-sources’ user,  I really miss those kernel patches nowadays. So I took up the bug 288512 and zen-sources are again available for all Gentoo users[1]
I haven’t committed them yet on portage tree because I want to ensure that they are safe enough for everyday usage. So until then, you can get them via a new overlay hosted on github

• git clone git://github.com/hwoarang/zen-sources.git

or via layman

• layman -a zen-sources

Special thanks to Brandon Berhent for providing the initial Gentoo ebuilds, and for developing the zen-sources

Thanks Brandon

Have fun with your brand new kernel sources[2]

[1] http://github.com/hwoarang/zen-sources

[2] http://www.zen-kernel.org

Vor rund 14 Tagen schrieb ich über die anstehende Auflösung des Förderverein Gentoo e.V. – nun 14 Tage später sieht erst einmal vieles danach aus, als wenn auf der kommenden Mitgliederversammlung ein neuer Vorstand gewählt werden kann und zumindest die Auflösung (vorerst?) vom Tisch ist. Die angedachte Mitgliederversammlung am Wochenende 07./08.11. in Bottrop findet ebenso nicht statt. Anstelle dessen wird voraussichtlich im Rahmen des 26C3 in Berlin (vermutlich am 27.12.) eine außerordentliche Mitgliederversammlung stattfinden. Alle Mitglieder des Vereins werden selbstverständlich zeitig hierzu eingeladen.

Ich möchte mich ausdrücklich bei denen entschuldigen, die mir in den vergangenen Wochen Mails mit Hilfsangeboten etc. zukommen lassen haben – ich konnte nicht alle Mails beantworten, aber es tut durchaus gut, zu sehen, dass auch andere noch ein Interesse am Verein haben. Dafür Danke!

Möglichst kurzfristig soll die Webseite des Vereins ein Facelift erhalten und ab dann im Idealfall regelmäßig mit frischen Informationen versorgt werden.

It's over 1AM again, and I'm still not finished with Gnome 2.28 review. I've spent quite some time this weekend and tonight looking at what was wrong with gnote, gnome-system-monitor, gparted and a few other c++ apps suddendly starting to crash after I updated glib on Friday. Turns out something in the mm stack is doing something wrong so I filled Gnome bug #598209.

Updated to epiphany-2.28 since I got sick of epiphany-2.26 crashing when I wanted to make it remember a new password. Turns out it's not as nice as I would have thought a nearly two years efforts would be. Lots of problems where loading of a page would stop in the middle of the process. I had to install firefox to fill bug reports and access the pages that fails. That's quite a regression but upstream is now aware of it through Gnome bug #598115. Hopefully it'll be fixed for Gnome 2.28.1.

I also spent some time cleaning up unneeded revisions in tree since I had to occupy myself when building all those c++ bindings. So where are we now, a bit less than 41 packages to go for review and about 80% of completeness on my gnome 2.28 status page.