… did FAI switch to that stinking pile of shit known as live-initramfs?
Things that were possible before aren’t possible anymore due to the extreme brokenness of live-initramfs. Nothing that can’t be fixed by some heavy-handed patching here and there, but what a waste of time.
Not happy. Hammer time.
pommed v1.27 is out as a maintenance release adding support for 3 of the newer machines:
Some machines are still missing, as I haven’t got any report about them yet.
Looks like the keyboard backlight behaviour and keys handling will have to be modified slightly for the new machines, but it’s really touchy to get right. I’ll need to try it out on the actual hardware.
Look what just got added to all the packages maintained by the Debian Forensics team:
--- md5deep-3.4.orig/debian/source.lintian-overrides
+++ md5deep-3.4/debian/source.lintian-overrides
@@ -0,0 +1,3 @@
+# Avoid warnings if non-uploaders to uploads.
+md5deep source: changelog-should-mention-nmu
+md5deep source: source-nmu-has-incorrect-version-number
You’re doing it wrong.
This is yet another “beta” release from Digi from a few months ago.
I had to patch the driver to build with a 2.6.26 kernel, as neither versions of the code would build against that version. Lenny ships with 2.6.26, so that would have meant no dgap drivers on Lenny. I’ve tested the patched driver and haven’t noticed anything obvious while doing so.
The drivers are now built for Lenny; if you need them on Etch, a simple rebuild from source will do. Previous versions are still available in the pool, under the old/ directory.
APT source line, now changed:
deb http://debian.technologeek.org/ lenny non-free
Feedback at the usual address.
About a year ago, I bought a SoundBridge, having grown tired of running a media player on one machine or another to listen to music. The SoundBridge really fits my needs perfectly.
The server-side counterpart, mt-daapd (Firefly Media Server), on the other hand… not so much. Feature-wise, it works and does what it’s supposed to do, so the issues aren’t there.
The first issue was with the crappy, below-average packaging of mt-daapd in Debian. I’ve fixed that since I think, at least now it’s in a state where I’m not looking away from the screen while typing apt-get install mt-daapd.
The second issue came after looking at the code, while writing patches for Debian. Eek. It’s horrible in about every aspect you can think of. No coding standard, outdated comments, cruft everywhere, either #ifdef’d out or not, useless code left lying around inside functions, obvious memory leaks, and way more levels of indirection than is actually needed, let alone sane. Also, someone is clearly in deep and urgent need of taking “Pointers in C 101″. My eyes still hurt.
Well anyway, I’ve been contemplating either fixing it or rewriting it because I can’t stand such crappy code. Also, mt-daapd has been unmaintained upstream for something like 2 years, given that the upstream developer just pretty much disappeared.
So, with way more time on my hands than I’d like these days, I’ve finally jumped in, pulled the whole SVN into a git repository and started cleaning things up then rewriting it piece by piece. Good way to keep myself busy, producing something useful while doing so and playing with a couple new things.
This rewrite is called forked-daapd, for lack of a better name at the moment, it’s GPLv2+, and the code is available in a git repository at
git://git.debian.org/~jblache/forked-daapd.git
It’s not a feature-for-feature rewrite. I’ve tossed out a few things.
It’s Linux-only for a start, and then I’ve thrown out the web interface, the XML-RPC interface that goes with it, the iTunes XML playlist support (only useful on Mac OS X) and the smart playlists. Maybe a couple other minor things I can’t think of right now.
It’s Linux-only because it uses signalfd and inotify. It’s built on libevent and pthreads, but doesn’t abuse threads either like mt-daapd does (spawning one thread per HTTP request … seriously). Parsers for the RSP and DAAP queries are built with ANTLR v3. Media handling is mostly done by ffmpeg, though ffmpeg suckiness in parsing metadata in some formats had to be compensated by dedicated metadata parsers. It’s a shame ffmpeg can’t handle raw FLAC streams with VORBIS comments, that is, bog-standard .flac files, while it goes to great length to support proprietary formats (though I should note it fails miserably on WMA too).
So, new things I played with: signalfd, libevent, threads, ANTLR, ffmpeg. Threads aren’t really a first, but I did some new things. inotify isn’t a first either, but it’s the first time I use it to watch events other than IN_CREATE or IN_MODIFY; that leads to quite some unhappiness towards the inotify API, which has some real shortcomings. I’m still shaking my head in disbelief.
It will happily support multiple concurrent clients, even when decoding media files to WAV, without abusing the machine it’s running on. I thought of adding more threading, especially in the decoding case, but I doubt this will be needed by anyone. Unless you’re streaming to hundreds of clients at the same time, which doesn’t look like a plausible usage scenario to me.
I don’t know where I’m going with this project. Right now it works for me and covers my needs. I’ve tested both the RSP and DAAP protocols with my SoundBridge, and DAAP with iTunes. I’m not an iTunes user so I may have skipped on the complicated things with iTunes, although I looked hard.
If there’s enough interest in this project, it can become a full-blown project on Alioth (it can even have a name that doesn’t suck!).
The patch you submitted has 0 chance of getting applied, and you know it. It’s nothing more than a bad joke.
The best solution for this issue is most probably to provide a xserver-xorg-nohal package that is a duplicate of xserver-xorg minus the HAL dependency.
Don’t like HAL? X.org now forces it upon you via xserver-xorg.
#515214, currently wishlist/wontfix.
From the Bits from the Debian Installer team mail to d-d-a:
It has been decided that, in order to not slow down the development processes, D-I SVN should be branched when the work on preparing a release starts. Even if SVN doesn’t make the process very easy, changing the VCS we use is currently not an option we prefer.
SVN, branching, d-i. There’s no word to describe how painful it is to work on d-i using SVN. d-i is big, SVN is slow in about everything it does. Now add branches to the mix.
That mail left me very disappointed; first because I thought switching to git was sort-of planned for after the release of Lenny, and now it’s off the table, second because some things in this mail are just wrong.
Oh well. No d-i for me, I guess, then.
I’ve just released a maintenance release of pommed. Nothing new under the sun in this one:
There are a couple of ideas floating around, we’ll see if any one of those lands into a future release.
So, Kodak announced the availability of Linux drivers for some of its scanners, together with a frontend application.
While the effort is laudable, they’re not quite there yet. Let’s have a look.
First of all, and contrary to what a few people believe after reading the press release, the drivers themselves aren’t OpenSource, let alone Free Software. They’re all proprietary; read better, the press release clearly mentions that only the frontend application is GPLv2.
Now let’s look at what Kodak offers in its drivers packages. I’ve downloaded LinuxSoftware_i1200_v3.5.tar.gz from the Kodak website, these are the drivers for the Kodak i1200 series.
The archive contains a set of RPM packages, one Debian package corresponding to one of the RPM packages, and a setup script.
One of the packages contains the OpenUSB library, which is released under the LGPL; sources aren’t there, I haven’t asked for the sources, don’t plan on doing so, and am not implying anything regarding license compliance whatsoever. I’ll note that I haven’t seen any written offer for the sources, though, be it in the archive (there’s not even a README in there) or on the website.
So, although Ubuntu is listed as supported, we can say that no Debian packages are provided.
The setup script actually relies on alien to convert them if it thinks it’s running on a Debian-based system, which is determined by the availability of dpkg in the PATH. Using alien is far from ideal.
The packages ship libraries and components under /usr/lib, /usr/local/lib and even /opt, pretty randomly it seems. Let’s repeat here that /usr/local and /opt are strictly reserved for the local administrator and packages must not install anything here. There are other oddities in the paths used by the software stack, like /var/kodak.
It looks like the SANE backend is only a bridge to Kodak’s TWAIN data source, so you’d actually need the whole stack to use it.
All in all, Kodak does no better, I’d even venture to say it does worse, than Epson (Avasys). At least part of Epson’s backend is Free Software, even if it relies on proprietary libraries for some scanners, though unfortunately most if not all of the recent ones.
I also have to mention that Epson is offering both RPM and Debian packages, and by that I mean proper Debian packages. Kodak are far from that, even the RPM aren’t that great (I think the RPM packages even lack dependency information, based on what I’ve read in the setup script, though I haven’t checked).
What Kodak offers here is a GPL frontend for TWAIN that not many people will be using, while keeping the drivers proprietary. Unfortunately their SANE backend isn’t a backend so to speak, and even if it was OpenSource it’d still rely on the rest of the TWAIN software stack.
So, in a nutshell, while I’m very happy to see yet another vendor go down the road of Linux support for its products, I am immensely disappointed by the proprietary nature of the drivers and the low quality of the packages.
I was, of course, investigating the drivers to possibly package them for Debian; as you’ve probably understood, it’s not possible, both technically and legally.
And I kept a little gem from the setup script for the end:
# We need to create a link for the libdbus-1 requirement for openusb,
# but only on Fedora.
if [ -f /etc/fedora-release ]; then
ln -s /lib/libdbus-1.so.3 /lib/libdbus-1.so.2 2>> /dev/null
fi
As we all know, sonames and soversions are useless and they just keep getting in the way. Duh.