This Time Self-Hosted
dark mode light mode Search

When your upstream need patching

Ok today here in Italy is holiday and I stopped working on the translation I’m paid for (it’s also sunday so it’s “double holiday” 🙂 ).
The day is good and the sun is shining so I’m out on my garden with my iBook working on gentoo via ssh to the main box and screen. X-Chat Aqua let me maintain the link with #gentoo-dev and other chans.

The cell phone is off an I feel more free than usual. So I’m in a good mood for a blog entry 🙂

One of the most annoying task when maintaining packages on gentoo is maintain clean the patches which, by version to version, doesn’t apply and needs to be re-created mainly manually. This task is needed because sometime we have to change the way packages works to make them follow gentoo’s structure in installing files or other things.
Other usual patches you need to prepare are when upstream didn’t cared about 64-bit architectures (which were pretty rare until a few monhts ago we can say, as amd64 (Athlon64 and Opterons), ppc64 (G5) and ia64 (Itanium) are recent processors. In those case you can have a lot of warnings about int casted to pointers and the other way ‘round. The problem here is that the size of a pointer in a 64-bit arch is 64-bit instead the size of int is just 32-bit. long type is usually the same size of the pointers, and ptrdiff_t should be used to do arithmetic computation with pointers.
Also with the newest gcc (4.0.0) most of those warnings are became erros and need a complete fix. This is good as code ingoring those warnings usually produce wrong binaries.

Another kind of problem is when borked configures doesn’t like passing —enable to commandline (for example when they consider every —enable|disable-something as a —disable) or when they just use automagical test for libraries presence, which makes useflag not honourable.
In video category there are many apps which has a lot of dependencies in external libraries to mangle file formats, and many of them doesn’t provide enough configure params to satisfy our useflags needs, so I have hacked most of those configure scripts to add params and sent them upstream. Most of them was applied upstream, a few weren’t and I’m still hoping for them being applied as they are a big pain.

One of the package for which I’m having most patches is xine-lib. Mainly because it’s a popular package which is installed in a lot of different machines with different setups, but also because its configure.ac was really messy, and for a long time the package wasn’t able to exclude some plugins and the ebuild used to depend on something line aalib which was useless for most users. Then there was my rewrite which used autoconf cache tricks, but it was probably not working with confcache so I preferred to patch xine-lib to add the needed params. Still the patch is not applied and it needs a lot more work to have it clean anyway.

But it’s onot only the configures which are a pain to fix because they aren’t complete or just suits the setups of the developers, there is also the PIC PIC stuff: libtool used to define -DPIC to select between PIC and non-PIC stuff, but gcc already defines PIC if -fPIC is passed, and sometimes the -DPIC is simply missing for some reasons and the things need to be changed accordlinh.

Most of those errors are things which gots warning or which needs to pay attention to to be sure that they works, but they can be real pain when the complier start to be stricter (which occours every gcc release).

Now, I hope the new patches I’m working on for xine-lib can be applied upstream so next release would simply drop the patches.. it’s being a few versions in which the patches aren’t being dropped but added (well, a part from the security fixes and the wma stuff added in -r2, -r4 and removed in 1.0.1.

Oh I forgot to say what I’m working on at the moment… it’s just a little little patch to enable vidix support on amd64 (I had a report for a gcc4 problem in vidix driver, I fixed it and tried to compile it but vidix support wasn’t being built at all, then I started looking at it and I found out that it wasn’t supported on amd64, and I’ve make it be accepted and compile. Now the vidix output plugin is on my system, but it seems not to work at runtime. I’m investigating this.

Oh you’ll find that post in an hour not suited to be outside in my timezone (20:30), but that’s because I had a friend here and stopped blogging.

Leave a Reply

This site uses Akismet to reduce spam. Learn how your comment data is processed.