My birthday is coming

No, I’m not saying that because I want gifts (although, if you really want, my wishlist has a few items on it — just joking, don’t take me seriously), but to update the situation about my personal birthday present, XMMS removal, that is.

Today we’re about at the middle of the month while XMMS is masked, and thus I decided to proceed with a second phase of the removal: the removal of useflags. I’ve removed all the xmms useflags from the packages, and the infopipe useflag from conky, so that no package should anymore depend on xmms directly, a part the masked ones. If you want to maintain an XMMS overlay, add the support for XMMS plugins like faad2 as a different ebuild, or we’ll start marking INVALID all the bugs reported by users with an xmms overlay in it.

For the people complaining about Amarok unable to play their ID3-tagged FLAC files, or OggFlac files, I’ve also put a new snapshot yesterday (let’s call it “Angel Release”, just because yesterday was the birthday of a friend of mine) that will solve those problems. It’s still masked, but as soon as Luca unleashes the latest FFmpeg, xine-lib-1.1.3_pre20061112 will follow.

Also, I wish to thank Alessio (X-Drum) who’s taking a look at sound bugs for the proaudio software.. I’ll be committing a few things today or tomorrow :)

Okay, now I might go look for something to eat, as I woke up late, and I haven’t had lunch yet.

Experiments, not feeling well, and fixing

First of all, I have to say that I still don’t feel that well, this flu is getting on my nerves, especially since I cannot stay with my nephew (I might be infective) and because I cannot talk enough to continue my jobs.

On the other hand, I’ve been using this time to continue fixing a few of the xine bugs I had in my black list to solve as soon as possible; a part the OggFlac trouble, yesterday I was able to also fix FLAC files with ID3 tags prefix, that was one of the most annoying bugs before a lot of people complained about that for Amarok, and the XCB work is also done, now just waiting review and commit.

Again, I’ve been looking for something to try as an hobby, and I remembered I knew an interesting free operating system, Syllable that I tried but failed to install on my system in the past. Today I downloaded the latest LiveCD (released yesterday, nonetheless), and tried it on Prakesh.. unfortunately there it failed to start at all.. I’ve then tried to set up Odissey (a recovered Pentium 3 533), but that first resulted in one of Defiant’s RAM banks burned (and one of my fingers burnt too)…

Now, I have to say that for a from-scratch operating system, Syllable (well, almost from scratch, as it is based on AtheOS) is not that bad, resembles how Linux was a few years ago to me. I’m not sure if it’s Unix-like enough for it to become a new Gentoo/ALT project, but I’ll surely try to study it some more, maybe I can port libcdio to support it, and then unieject… maybe on the long run I can make xine work, at least partially…

Yes this is my favourite kind of hobby, and now you can see why I end up always on the edge of burning out and come back :)

OggFlac support… done!

Just a quick note, before trying to relax myself a bit, or rather resume working on XCB to get the definite patch, that OggFlac support in xine (and thus in Amarok) is not done.

Well, not entirely, as I don’t load metadata, seekpoints or cuesheets, and the flac demuxer should be changed so to share the headers’ decoding functions, but that’s something for another moment, when I’m more relaxed and I feel better.

My next steps will be to finish to write the shared functions for decoding of FLAC headers, then find a way to get xine to play FLAC files that starts with an ID3 tag (although they shouldn’t be legal, they are still quite used and that makes a lot of noise “Amarok can’t play files that $some_other_player plays!”..

But first, let’s return to XCB :)

Working on a few things

Let’s start by saying that at this very moment my throat hurts, badly, either caused by cold or by the smoke from my boiler (it’s still a wood-fed boiler), my foot also hurts a bit, because of the whole sunday passed with my good shoes on (should have taken the other ones I supposed), and I don’t want to get started on how my personal life is lately.

But I haven’t been taking naps all day, although I’d like to. First of all, since yesterday I got XCB and libX11/XCB working on Gentoo/FreeBSD. The patch is still to be polished before being merged, I’ll do so later on tonight or tomorrow.

I’ve also been working on xine’s FLAC support so to fix both the OggFlac problem and the refusal of FLAC files starting with an IDE3 block rather than the Streaminfo one (that are anyway invalid FLAC files, but that’s beside the point).

I have to say, I never thought a container format would be that messed up as Ogg… every stream type has its own headers, in the case of FLAC, it uses FLAC’s own metadata blocks. And FLAC is a masochist format for audio… It’s a lossless codec, so the size of the encoded files is usually not that low, but the metadata blocks tries to save a few bytes by not aligning the data structures to bytes.. I gone crazy trying to read a value of size 20 bits using bitfields or other similar approach, there’s no way: FLAC’s metadata blocks are not mappable against a machine-independent C structure, which makes parsing quite hard.

Anyway, I’ll try to complete these works as soon as I can, also because I need to return to my paid job as soon as I feel better.. and because when I cannot do something because of the feverish mood I’m in I start to be frustrated and depress myself… so if I’m not able to get something working soon, I’ll start screaming by rage :P

On the bright side, John Palmieri announce D-Bus 1.0 release that hopefully will work out of the box on FreeBSD :)

Too many overlays will bring us down

So, a part closing envelopes, last night and today I’m working to fix as many bug as I can with the time I’m given, as I want ot use the time I have before starting new jobs as much as I can for Gentoo, in the case I won’t have enough time later (although I hope to still have some afterward).

Today I’ll be working on patching a some software for FLAC 1.1.3 support, thanks to Josh Coalson (FLAC upstream) who has provided already three patches: kdemultimedia, k3b and vorbis-tools. Last night instead, as I had the chroot on pitr still opened, I decided to spend more time testing and fixing the bugs for CJK that Patrick reported through his tinderbox effort.

The result is that I’ve dedicated also this morning to fixing CJK bugs.. considering my Japanese is waaay limited, and I decided to help the herd just because I had free time, they missed manpower, and I had a few changes to merge, being able to fix stuff there is something that makes me feel a bit better toward my involvement. Unfortunately as I said I can’t really use most of the software there, and this disallow me from trying it too :(

It’s sad to see so little people involved lately :( Most of the CJK packages are unmaintained.. I fixed cannadic eclass and the canna packages not to have a canna useflag, but this does not entirely help… I’ve been told there’s a gentoo-china overlay, but I cannot find it in layman and I don’t remember seeing much things from that in bugzilla…

Then it comes the news from the sound herd. ReZound is masked and pending removal next month, if nobody steps up to maintain it. The problem is that currently, under the sound herd you can find desktop multimedia applications like Amarok and Audacious, libraries mostly used by video software like a52dec and libdts, and professional audio software like Audacity and ReZound. In the past there were also ALSA drivers and packages, they are now instead on their own herd, which means that if you look up alsa-driver you get a more truthful response (me and phreak being the ones handling its bugs) rather than the whole sound herd… for professional audio software there is almost nobody taking care of it lately, especially now that kito is being retired.

And then, I’m told by lavish on #gentoo-it that there’s a proaudio overlay . Why fraction this way the efforts? Why instead of creating an overlay they cannot become official developers? :|

I’ll try to write an appeal for the next GWN, trying to get more people involved with professional audio software in Portage, and maybe something for CJK could help. The problem is to establish at least some kind of trust relationship, so that the packages can be proxy maintained… I don’t know a thing about pro audio software, but I know quite enough of ebuild development for handling a proxy maintainership I suppose ;)

Anyway, if you’re interested, feel free to drop me a line, I’ll try to answer as soon as I can!

Tiredness

Last night I was able to sleep… maybe a bit late, but I fell on the bed for tiredness. Anyone who tried before to prepare envelopes for sending will know how much tiresome it is… mostly, it’s because it’s repetitive. Today instead the day started bad, as the Samsung laser printer I’m given to print the receipt cards started to behave in a silly way for a while.. luckily the second set of cards started to behave decently and didn’t get me lose too much of the time I spent on this job.

Now, on the FLAC upgrade path, I’ll be talking with upstream about this soon, and in the mean time I’ll have to finish the rest of the packages to check and mark the dependencies. Unfortunately the K3B patches fails for me, and I’m not sure why, nor upstream is.

Fortunately today I feel happy enough, as an article of mine, about CASE tools, was published on the Italian edition of Linux Journal (see here until the next month issue is published). I feel quite satisfied for that, as it’s my first article in Italian that I try to get published, and it was right away without even a request to change, in its integrity and in the centre fold too, yuhuu! :)

The important paid job instead should start soon, but I still haven’t had any information about the contract… which is kinda bad. I just hope they are late (as usual).

And a new ALSA is going to be marked stable now, 1.0.13, but beware! There are some changes to configuration files that might be rewritten because they did change something in the parsing for instance.

Okay now I have to hurry up that the receipt cards of this kind are almost finished and I need to try if the new kind works without changing the page layout.. sigh.

How not to update a library

So today the Gentoo KDE team received a mail from Josh Coalson – flac maintainer – directed to Sebastian Trueg as well as Gentoo, Mandriva and RedHat maintainers, with a patch to let K3B build with the recently released 1.1.3_beta2 version of flac itself.

At this point, I decided it was time to put that version masked in Portage, so that we could at least give a look of how widespread the breakage is… it turned out worse than I imagined.

Now, when you do a micro version bump, you expect either a bugfix only release or a minor feature enhancement release… but this is not the case for flac at all. This version removes two out of four libraries, libOggFLAC and libOggFLAC++, and instead merges a completely different Ogg container support inside libFLAC and libFLAC++ themselves. Also, it changes a wide range of library functions and remove headers.

The result is that almost all the software that uses libFLAC currently in Portage will not build against the new version, a part a few rare cases like mt-daapd, that only use the metadata access. The software that only works “at an arm distance” by using the flac and metaflac commands is instead still working as intended, and this is the only good news.

I’ve been correcting the dependencies of the software in portage to use ~flac-1.1.2 when it does not build with 1.1.3, so that at least, even by creating a up-down cycle, users unmasking flac thinking it will be better than the unmasked version won’t file bugs of software not building. I’ve also opened a bug, and the other devs are helping by testing their software too. Thanks guys!

I’ll be working in the next days to fix the issues, but it might take quite a while considering the changes. I’m also limited in my time as I’ve found another temporary job (labels, envelopes and optical reader, you know what that means if you ever did something like that), and my nephew should be born in a matter of days now, so I’ll be ready to go far away from keyboard at the call of my brother in law :)

At least I was able to update all the patches for flac 1.1.2 (included the visibility ones) for 1.1.3, so there won’t be any regression in Gentoo packaging.

Now, I should be working on cdparanoia, as Release Engineering is begging me to find a way to stop it from failing if the kernel sources aren’t available. Considering the bugs opened on bugzilla for the SG_IO patches, I’m probably just going to drop all of them and ask for a new stable, and add the new beta version, that should include equivalent improvements. It’s not helping to patch a software, losing upstream’s support, and then having bugs opened for it :/

Oh yes, my personal life is more sucky than usual, but that is something I can cope with it… for a while at least.

Finally, the release…

… of xine-lib 1.1.2 of course. Darren packaged the tarball and released it on SourceForge tonight, and now all distributions will have available the fix for FLAC files, hopefully..

I wish to thank Darren a lot, as this release really makes my work simpler, especially since, after this release, I’m going to merge the remaining (3) patches of Gentoo, the visibility one, the textrel one, the m4b.. actually the only remaining is the textrel one, but that I want a couple of tests more before.

I’m also trying to investigate some bugs, after I hunted down some issues that are now fixed in the 1.1.2 release in SourceForge.net’s bug tracker. Unfortunately I don’t have direct access to those bugs to close them down, and I had to ask Darren to do that, one by one, and it’s not that easy after all.

There are a lot of bugs that are caused by xine-ui and those should be fixed when we do another release of that, too, but it might take a while still.

I’m currently working on adding support for Darwin i386 to the configure.ac, that currently assumes Darwin == PowerPC (uncorrectly). This should solve two bugs currently reported in SourceForge.

Not that easy is proving the importing of unieject’s source code from SF.net’s SVN to a GIT repository (as I’m finding myself quite comfortable with GIT, I’m more than happy to move to that). I tried three times already to get the data, but SourceForge’s server is all but stable. I’ll be rsyncing it down and then converting locally later.

So, today not much commits to Gentoo, but a few to ruby-hunspell to prepare the release, a bit to gitarella as I wanted to improve it a bit, considering I’m using it more and more, and now xine. Not a bad mixture, is it?

Oh of course I won’t forget the Wavpack plugin for xine I talked about some time ago, I’ll be working on that as soon as the issue are taken care of, so that people can actually use it, but the problem is that to have it working correctly I also need a TagLib plugin for Amarok to use it, and thus it should be better if TagLib’s plugins would be taken out of Amarok as discussed some time ago.. If you can help somehow, it will be surely appreciated :)

It’s not like I think other distribution sucks but…

… at least some of their maintainers (official or not) don’t care much about users, or simply don’t know how to care.

I’m not saying that just because I’m a “Gentoo or nothing” kind of person, but simply because I have now the evidence that a good deal of other distributions’ maintainers simply don’t care about their users.

I’m not even sure if they are all official maintainers or there are also unofficial maintainers involved, but this whole situation makes me laugh.

So, Amarok 1.4.1 was released, and this one checks if xine-lib supports the stream type before playing, so that it does not crash on unknown streams. Good thing. Too bad that xine-lib 1.1.1 has a bug in the FLAC demuxer that make it tell Amarok there’s no audio stream available, so that it refused to play the FLAC files.

The problem is annoying, albeit not a great loss for many people who don’t care about open formats and music quality, but there are people using FLAC files (I’m one of them), and for them it’s a big loss.

So what the deal is? On Gentoo, I was able to get the fixed xine-lib stable altogether with a security fix, so I just had to make Amarok depend on that version to force upgrade for the few who don’t run full updates, and this is good. For everyone else, I sent to the amarok-packagers list a note about the need for the patch, the actual patch, and told that 1.1.2 version of xine-lib will be released already fixed.

Now it seems that unofficial packagers did package Amarok 1.4.1 for various distributions without supplying a properly patched xine-lib, and maybe some official packager did too, this is out of my sight, but the problem remain: seems like really few distributions actually care about their users :/

Oh well, something Gentoo users has not to worry about is to have a working xine :P Of course if they know how to set useflags.

Changes in VLC’s AAC handling in Gentoo

So, yesterday Andrew Turner (of #amarok), told me that our VLC played AAC files incorrectly, while it works in Ubuntu. Fear to lose to Ubuntu, I tried to find a solution ;)

The cause is probably in the fact that we had to change libfaad2 to be able to use it on 64-bit systems, so VLC is not updated to know how to use our version correctly. This isn’t rare but luckily not even too widespread.

As fixing faad2 was out of discussion for me, considering the whole headaches that I got with it, I looked at ffmpeg, that’s now using faad2 for decoding but soon will have its own full-fledged AAC decoder that will solve all our issues. Unfortunately VLC blacklisted ffmpeg’s AAC decoding part deeming it broken. It doesn’t seem broken to me here, they probably were referring to older version of ffmpeg, so I decided to remove that blacklist.

The new 0.8.5-r2 version of VLC then features the new setup: no more aac useflag on vlc itself, and instead it relies on ffmpeg’s aac useflag. This way it will automatically switch to ffmpeg’s new decoder when it will be present :)

Now that the VLC part is done, a little note about xine. It seems to me like the FLAC demuxer is kinda broken, so I’d actually like to learn better the whole structure of demuxing in xine and try to write a new one that works, unfortunately this plan is probably going to move forward only when I have free time, as between Gentoo and jobs I don’t really have much of it. Sometimes I’d like to find a way to be paid to work on multimedia :P