Archive for the 'p.d.o' Category

Anyone can speak Troll, all you have to do is point and grunt.

Your results:
You are Spider-Man

Spider-Man 75% Green Lantern 65% Superman 60% Batman 50% Robin 47% Supergirl 45% Hulk 40% Iron Man 40% The Flash 35% Wonder Woman 20% Catwoman 20%

You are intelligent, witty, a bit geeky and have great power and responsibility.

Click here to take the "Which Superhero are you?" quiz...

Firefox 1.5 has been released by Eric in unstable, with a package name change, thus I provide a new branding package.

As for compatibility with plugins and extensions (#341682 and #342788), the patch is ready and should go in with the next upload. Stay tuned.

Seems there's been a lot of talking about revision control systems on p.d.o, recently. I am no SCM guru, and until quite recently, all I knew was CVS and its drawbacks, main one being that you lose file history whenever you rename, or even worse, move, it.

Then a few years ago I tried out svn and I liked the way it used similar command lines as cvs, while giving me what I missed the most in CVS. But SVN has its drawbacks too.

A few weeks ago, I took a look to different distributed SCM solutions. I gave a try to tla and baz waaaaay too different from CVS and svn, bzr, looking very promising and amazingly simple, and svk, compatible with svn, and bringing a brand new world to svn users.

And I made my choice : svk. Its compatibility with svn made the conversion painless, I could just use my svn repositories without any modifications. And I can now track my local changes on alioth's svn repositories while offline. The fact that there's no .svn/CVS/whatever directory inside a checkout can also be quite useful. As a bonus, svk is a much faster than svn to handle a repository, which can seem odd, svn being written in C while svk in Perl and using parts of svn...

Isaac, there is actually a cleaner way to do the same as your hook. Just add the following to your .pbuilderrc file :

export CCACHE_DIR="/var/cache/pbuilder/ccache"
export PATH="/usr/lib/ccache:${PATH}"

EXTRAPACKAGES=ccache
BINDMOUNTS="${CCACHE_DIR}"

That will need bug #341453 to be fixed first, though, but if you set both BUILDUSERID and BUILDUSERNAME it will work out of the box (with the default configuration, PATH is not preserved because of the bug).

Note that you can also set HOOKDIR instead of using the --hookdir command line argument, thus not needing your wrapper.

I knew that hard disks had a limited time-life park/unpark-wise, but I didn't know that was that bad. I always thought that because of ext3's commit every 5 seconds, disk would never spin out and park the head. I was wrong. It seems that whether or not the disk is accessed, every put here the time it is for your disk minutes, it does park and unpark the head. Well, at least on laptop disks, because it seems this is not the case for desktops.

My 3 year-old vaio, which is now this web server, has a Load_Cycle_Count of 580465 for 9775 Power_On_Hours, which is about 1 load cycle per minute.
My 1 year-old vaio, has a Load_Cycle_Count of 83718 for 4043 Power_On_Hours, which is about 1 load cycle every 3 minutes.

While I managed to actually stop the load cycles to occur on the older vaio, with hdparm -B254, nothing actually stopped it on the newer one. I tried to change some other parameters with hdparm -S but nothing did work. I still have to take a look at the BIOS, though.

Now, the question is : why the fuck are the heads parked/unparked every little while even when accesses occur ? Is it a conspiracy so that laptop disks won't last forever ?

Well, at least, I've never experienced a hard disk failure in 12 years of using computers with hard disks. For how long ?...

[Note: the Dell laptop provided by my company, running Windows XP (which also has a somewhat journalled filesystem and commits the journal every few seconds) has around 24000 load cycles for about 800 hours of use, which is 1 load cycle every 2 minutes, so this is not a Linux issue.]

How surprised am I.

Well, seems I belong to the Shire.

To which race of Middle Earth do you belong?

... and for now, it's 1.5rc2 that got in experimental.

I made some changes to the firefox wrapper script so that it should be quicker to launch firefox in most cases. We don't try to find the JVM version, since the ones we wanted to set LD_ASSUME_KERNEL for have been ABI incompatible for a while, and we don't remove the XUL.mfasl and other problematic files since it is now correctly (I hope) by firefox itself. And if bugs arise again, we'll try to fix in upstream code, not in wrapper script...

I also fixed the dash bug and another one in xpidl.

For what it's worth, I did some testing with JVMs and firefox. I got success with

• Sun JRE 1.5update5,
• Sun 1.4.2_10,
• IBM 1.4.2SR3 (but not with java-package, see bug #338277),
• Blackdown 1.4.2-02 and 1.4.1-01.

On the other hand,

• IBM 1.3.1SR8 segfaults,
• Blackdown 1.3.1+02a and 1.3.0-FCS are built against libxpcom.so with older C++ ABI, so ld can't find __vt_17nsGetServiceByCID,
• Sun 1.3.1_10 can't load libstdc++-libc6.1-1.so.2.

I'm not sure I have to be proud of the fact that my name has a meaning in klingon.