Julius Plenz – Blog

I’m very pleased to announce that a little program of mine called nocache has officially made it into the Debian distribution and migrated to Debian testing just a few days ago.

The tool started out as a small hack that employs mmap and mincore to check which blocks of a file are already in the Linux FS cache, and uses this info in the intercepted libc’s open/close syscall wrappers and related functions in an effort to restore the cache to its pristine state after every file access.

I only wrote this tool as a little “proof of concept”, but it seems there are people out there actually using this, which is nice.

A couple of links:

• The development repo on GitHub
• The Debian Package page
• The Debian Package QA page
• Build statistics

My thanks go out to Dmitry who packaged and will be maintaining the tool for Debian – as well as the other people who engaged in the lively discussions in the issue tracker.

Update: Chris promptly provided an Arch Linux package, too! Thanks!

I'm not sure why, but AFAIR I've never done a dist-upgrade that was entirely successful. That is true to my Debian system at home as well as to various other Ubuntu systems I've laid hands on.

My Debian system was a mix of stable and testing packages, and somehow aptitude came to a point where it'd just not be able to resolve some dependencies, meaning I could not install nor remove any new packages. So I opted for a dist-upgrade to Testing. Here's how it went, roughly:

• Everything installs fine, until aptitude tries installing libc, where the installation process will go into a deadlock. Error message and solution is posted here (yes, you have to manually patch a Perl module). linux-base has the same problem.
• System is left in a half-upgraded state, but aptitude won't do any further upgrading. apt-get dist-upgrade continues, though.
• Reboot because of new kernel.
• Sound is all gone. pcspkr module is appearently now called snd_pcsp and is thus loaded, strangely overriding all other sound drivers. I blacklist it manually, reboot.
• Seems to work. Now install the new package I did all the upgrading for... right. There's still some 500 upgrades left to do! Ok, now...
• Upgrade aborts with a problem: libcaca0 wants to overwrite a file which is also present in libcucul0. Purging libcucul0 will reinstall libcaca0, which in turn will fail. Turn to manual override and uninstall all packages libcaca* and libcucul* using dpkg.
• Upgrade runs through fine. I go to sleep.
• Today, I power up the computer. Alt+Enter to start a terminal – duh, nothing happens. Start an xterm. Inspect the situation: rxvt and rxvt-unicode are missing. Well, thanks, so here I go, aptitude install rxvt. But guess what: apt-get uninstalled aptitude! Yeah, great.
• apt-get install rxvt-unicode, finally a decent terminal. Fire up mplayer. It's not installed any more. Like, what?!
• Install mplayer, start it on a file. No sound. After various tries, a pattern evolvesdissolves: Sometimes it just won't play (like muted), sometime's there's an error message of various audio drivers. aplay works just fine.
• mplayer -ao alsa works. Put it into the config. Happy now with music.

Now, what I ask myself: Manually patching a Perl module, manually resolving dependencies and invoking dpkg, being (momentarily) deprived of the few programs I use on a daily basis ... how will this packaging system ever be remotely feasible for someone who's not an expert of sorts and well-versed in debugging in a Unix wold?

Update: Some crap program said it depended on DECnet stuff. After a reboot, this caused the MAC addresses of all my interfaces (yes, both wireless and wired!) to be the same, i.e.: aa:00:04:00:0a:04. Solution is removing libdnet* and dnet-common. – You kidding me?!