Dave's SlackBuilds

An annexe of The Daves Collective

The aim of this site is to provide an up to date collection of SlackBuilds in a few specialist areas of applications -- geospatial, photography and the Raspberry Pi. These SlackBuilds are mostly taken from SlackBuilds.org and Ponce's current branch on GitHub, but in many cases are updated for a more recent version. Thanks to the contributors and maintainers. See the SlackBuilds.org HOWTO for details of how to use them. To verify the tarballs you'll need the GPG key.

Prebuilt packages are available, if you value convenience over geek purity.

There's a whole page of notes and resources for running Slackware ARM on the Raspberry Pi.

News

16 July 2012: There are new Raspberry Pi kernels and other system packages, and a new installer image. The Raspberry Pi stuff has moved back to my other site, along with the prebuilt packages.

Blog

Last time (see below) I had a pop at luminance-hdr for untarring to a random new subdirectory every new release. Well, since then, there's been a new release, and guess what? This time, everything's in the top level :O Maybe I should mention this upstream :-/

Meanwhile, over in the OpenJDK debacle (caused by Oracle's recent crazy delicensing of redistributable Java), this is what happens when you try a boostrap build of icedtea-2.2.1.

/usr/lib64/gcc/x86_64-slackware-linux/4.7.1/../../../../x86_64-slackware-linux/bin/ld: /tmp/ccuFS2pi.o: undefined reference to symbol '_Jv_MonitorEnter'
/usr/lib64/gcc/x86_64-slackware-linux/4.7.1/../../../../x86_64-slackware-linux/bin/ld: note: '_Jv_MonitorEnter' is defined in DSO /usr/lib64/libgcj.so.13 so try adding it to the linker command line

Yes, you read that right. gcj refuses to link against libgcj unless asked very very nicely. And apparently upstream's testing doesn't involve boostrap builds on recent compilers.

Previously...

This site won't just be a boring respository; there will be occasional rants about the difficulties of packaging other people's software.

For example, if you build spatialindex using cmake, it installs headers into a subdirectory that its own headers can't find. And there are projects (eg, darktable) that Debianite committers have broken supporting their bizarro new multilib setup. And there's the upstream tarballs (eg, hugin) from paranoid Fedorites that have nonstandard selinux headers in them. (Yes! I'd love four error messages for every file in the tarball, thanks!) And there are projects (eg, luminance-hdr) that untar to a random new subdirectory every new release.

Usually it's easiest just to fix this crap in the SlackBuild.

And then there's the joy of -Werror. The net is full of zombie developers with no self discipline who apparently can't otherwise sufficiently arouse themselves to fix their own warnings. This would be merely sad but harmless, if it wasn't for the policy of new releases of gcc to issue new warnings for old bad code; whereupon the upstream release suddenly won't build at all until some poor fool like me fixes the bad code or the bad Makefile/cmake/whatever.

ACHTUNG DEVELOPER IDIOTS!
DON'T **EVER** PUT -Werror INTO RELEASES!

About

Maintained by David Spencer, Baildon, West Riding of Yorkshire, aka idlemoor on GitHub and 55020 on LinuxQuestions


This page was last modified on 16 July 2012

Web Hosting