autopackage stuff

Slowly getting back my energy to code. The last 6 months took a lot out of me, more than I had anticipated.

double compiling

The original approach of using apbuild to compile each object twice, once with each compiler, was very complex and didn’t work. Specifically when compiling something like taglib that combines objects from multiple directories into a single static archive we lost information required to rebuild the 2nd ABI version of that archive.

I have modified makeinstaller to take a different approach – actually running the entire build system twice then installing into a second build root. The code is a bit hacky and a bit lazy: it assumes “make clean” will work for instance, but it’s getting ready to commit. Once done a major 1.2 blocker will be sorted.

selinux

I recently wrote about the latest shenanigans surrounding Fedora and SELinux. Don’t get me wrong, I think it’s great they’re focussing on security like this, I just (strongly) disagree that this latest move will have any positive impact. There are more important things to be working on. We’re far too complacent about spyware in the Linux community still. I’m considering writing some of my own to demonstrate just how vulnerable we are. Lots of difficult issues surrounding how to distribute such a demo though.

At any rate, I summed up a couple of the more immediate issues for us in [this mailing list post](http://article.gmane.org/gmane.comp.autopackage.devel/5300).

binary relocatability

The current binreloc works OK but leaves a lot to be desired – most critically, we messed up the memory allocation semantics so that they were rather non-obvious and unintuitive. I’ve written a new system that should be an improvement over the old one:

* It hardly ever requires code modification. All you have to do is link another object into the final binary. This could even be done automatically by apbuild.
* No need to think about “raw” vs “glib” style or anything like that.

It works by opening a file descriptor to the prefix and dup2ing to a magic, pre-defined number – currently 200. You then “./configure –prefix=/proc/self/fd/200″. There are security checks to prevent suid+hardlinked binaries being attacked via this approach. If paths are passed to child processes it’ll work as the FD is inherited across exec. If the child process could *also* be using fd-binreloc then you can simply realpath() it to an absolute path, however, remember that in the new Linux world file paths are always process relative.

Unfortunately Tim hasn’t got back to me yet, so I’d appreciate it if somebody could try it out and let me know how they find it! [Get it here](http://article.gmane.org/gmane.comp.autopackage.devel/5278)

elf alternative

I had started writing a journal entry talking about a “next gen” binary format, but I seem to have lost interest. It was reliant on a 64 bit universal address space and wasn’t likely to be implemented anytime soon. Binary formats, it turn out, are just not very interesting, hence the reason that all of the ones in use today are variants of 10+ year old designs which optimise for the wrong things.

other stuff

* Does anybody know what it means in Nintendogs when a bone appears underneath the dog? I’m guessing it means you re-inforced the dogs last behaviour but the manual doesn’t seem to mention it.

* If you live in the UK and ever got a text message from T-Mobile or Virgin from “>pers” that contained garbage or somehow deleted itself when you tried to open it, join the club. It appears the mystery message is a SIM upload from the network – presumably one that only works on some phones.

* Had a strange dream last night. Manya was in it, but she wasn’t with Tony, instead there was some other guy I didn’t recognise. I’m not superstitious but I hope she’s OK. Would be good to see her again sometime.