Ten years ago, pretty much to the day, I was installing my first Debian system, a frozen Potato, using a release-candidate version of the boot-floppies. A few days later, I was reading the Policy, New Maintainer’s Guide and Developer’s Reference while building my first package.
It’s been a fun ten years, with ups and downs, and I’m looking forward to what’s coming next.
Mostly an update to my previous post on the subject, I’ve just completed the FreeBSD port. It also builds and runs on GNU/kFreeBSD, by the way.
The filescanner for forked-daapd on FreeBSD is now up to par with its Linux counterpart, as much as possible. Contrary to the latter, it will lose some metadata (play count, for instance) when files get moved around, because it’s not possible to track moves and renames accurately. It also performs more rescans than the Linux/inotify implementation. Still, it works just as good.
On a related note, the machine I tried to install FreeBSD 8.0 on and finally ended up installing GNU/kFreeBSD on just seemingly committed suicide. I’m not sure what message it’s trying to send me. It’s previously been my main workstation for the best part of 10 years, so this is a bit sad.
At least I found some bugs in the process and fixed some too:
Not bad, is it?
Since I released forked-daapd, I’ve got a couple of emails about porting it to FreeBSD. Apart from isolating and reimplementing the parts of the code using signalfd and inotify, there isn’t much work to do beside taking care of the usual libc/platform issues. However, when you don’t know the codebase and don’t know the APIs you’re replacing, it makes it a bigger job.
So, I’ve just spent a day going through FreeBSD documentation, installing FreeBSD 8.0 in qemu (because it wouldn’t install on my spare machine due to a bootloader issue that’s at least 5 years old…), and started porting the codebase.
A dozen or so commits later, forked-daapd builds and runs on FreeBSD.
With one caveat: the filescanner doesn’t update the database on the fly when the library directory is modified. While I’ve put in support for kqueue/kevent to replace inotify, it’s only a stub for now. Someone will have to write the code to actually act on the events and trigger the rescans/database updates.
kqueue/kevent delivers a lot less information compared to inotify, which means there’s a lot of work needed to track renames and moves. And I didn’t feel like doing it.
So, FreeBSD users: send patches! :)
I’ve spent the last week packaging VMware Workstation 7.0.0 at work. Looking around on the net, I’ve been unable to find anything helpful about packaging this new version, so it seems nobody’s got around to packaging it yet.
I’ve asked our customer for its approval for releasing our packaging scripts to the community and got it, so here are our packaging scripts for this version, courtesy of EDF. See the instructions in debian/README.source for what has to be done to turn it into a full source package.
The packaging is based on our previous 6.5.2 packaging, which was itself based (partially, at least) upon the Gento 6.5.2 ebuild. It uses a tweaked vmware-installer to install the products to debian/tmp, then makes use of the vmware-installer database to populate the packages.
I think this method should work with any VMware product using vmware-installer 1.1.
Packages have been built and tested on Etch and Lenny.
Hope it helps! Bugs, comments, questions to the email address listed as Maintainer in debian/control, please :-)
Over the past weeks, a couple of contributors sent me fixes and new features for forked-daapd. Thanks to you all!
The biggest change is the addition of TV shows metadata as found, for instance, in TV shows bought on the iTunes store. Together with the added support for FrontRow and QuickTime clients, this means forked-daapd is a lot more able at streaming video files than it ever was. Kudos to Ace Jones for his work!
Note, however, that you’ll need a patched version of ffmpeg to pick up the TV shows metadata from your MP4 files. At the time of writing, the patches have not landed into ffmpeg upstream yet, and it’s a bit unclear when this will happen. Contact Ace for the patch and instructions, see the commits in the git tree for his email address.
Git tree on Alioth: http://git.debian.org/?p=users/jblache/forked-daapd.git (git URIs on the page)
I’ve just bought a Packard Bell OneTwo (M3700), a 600 Euros all-in-one computer with a 20″ multipoint touch screen (there are bigger models with 23″ touch screen, wifi and some other options). This machine will be used to run OpenBravoPOS, a free (libre) point of sale software. So far, I think this machine is just perfect for the job.
Getting it to run smoothly under Linux is not a walk in the park, however. There are some quirks and some assembly is required, but once you’re done (that takes a couple of hours at most once you’ve got all the info, which you have if you’re reading this) this machine is just great.
It’s fast, with a 2.1 GHz Pentium Dual-Core (T4300) CPU, 4 GB of RAM, an Intel GM45 GPU with up to 256 MB of shared RAM, gigabit networking, a fast 320 GB SATA disk and a combo DVD-drive (not a slot-in, too bad). The screen is nice, and the touchscreen is incredibly smooth, precise and sensitive. The sound is good, the webcam is great and it works out of the box, too!
Update: added a note about the card reader.
Update 2: the instructions can also be found on the Debian wiki now.
Pommed v1.30 is a bug fix release fixing two small bugs:
If you are running on a recent MacBook/MacBook Pro with a recent kernel, you’ll probably want to upgrade to this release.
pommed v1.29 is a bugfix release, kind of. The fix is an architectural one related to the video mode switch feature.
When pressing the video switch key, your graphical pommed client of choice checks which VT its X server is running on and whether this VT is the active one before executing your video mode switch script.
To check that the VT is currently active, it is necessary to open one VT (we use the one our X server is running on) and perform an ioctl() call on it.
Depending on your setup (login manager or startx, basically), your user will or will not have any right on the device node associated to the VT. Which means the VT state checking code would always fail in some setups.
This is now fixed by moving that code into pommed itself, with a DBus method for the clients to call. You’ll need to update both pommed and the clients for this to work, for obvious reasons.
You want to revitalize a dying, inactive free software project. How do you proceed?
There’s this saying about opensource/free software that says the logo and about box are the very first (and only) things that work in new/young projects (and sometimes that’s also true for more “mature” projects, as we all come to know).
Choice 2 above is the About Box 2.0. Unfortunately, that’s the way a handful of people choose to revitalize mt-daapd/Firefly Media Server. Of course, not one among them can code or has actually got a clue about the current codebase.
FAIL of epic proportions. Facepalm.
pommed v1.28 is a minor update adding support for the MacBookPro5,3.