This (extended) weekend features:

pkg-phototools

• Update libgphoto2 which is used (surprise!) by gphoto2 and others to access digital cameras. Some hours after 2.4.1-1 got uploaded, 2.4.2 got released. Got to get back to it soon…

• Prepare an SVN snapshot of hugin, which is a panorama sticher, using libpano13 from panotools. People are so active with their GSOC students that the long-awaited 0.7.0 version isn’t released yet, hence the snapshot.

  Testing is very welcome: binaries for i386 and amd64 will be available on people.d.o until the upload.

  Thanks to Julien Valroff and Johan Kiviniemi for their patches, and to the NMUers who took care of hugin in the meanwhile.

• Bug triaging for both of them has been quite missing lately, but hopefully that’ll get fixed soon.

collab-maint

• Fix blender, which could have migrated, if ftgl wouldn’t be still missing on alpha — being optional:uncompiled doesn’t help. It started to FTBFS: bug #490317. Against crappy upstream build system, strace -v to the rescue (-v is needed to get all variables, so that one can figure out why that execve call failed). Here’s the fixing-an-RC-bug dance for Stephen Frost, as promised: \o_ /o/ \o\ _o/.

  The Add > Text crash (bug #487890) got fixed too, although I didn’t get any ACK from upstream.

  Oh, and I know about this tiny bug (which appears during the byte-compilation phase). I’m not very keen on trying to get it fixed myself and possibly breaking stuff, especially when upstream doesn’t care, and when the following commits are looking even more messy.

• Update sunflow, a rendering system for photo-realistic image synthesis, it can now happily depend on better Java packages now that openjdk-6 made it through NEW.

More to come…

• A new graphviz upstream bugfix release is available.

• As written above, a new libgphoto2 upstream release is available.

• A new module, python-ssl (bug #453101), might be nice. Python 2.6 got a real ssl module and this python-ssl module would be a backport of this new ssl module to Python versions 2.4 and 2.5. Interested people can compare the current ssl module API against the one available in the new ssl module.

• And the sponsor queue is growing, too.

While building and testing LiveCDs, QEMU and VirtualBox can speed up development cycles… until a bug is encountered: apt-get update hanging on a rename operation. Maybe aufs is at fault? Its author then asks for some data, including what happens when some SysRq keys are pressed. What they are is already quite extensively explained in Documentation/sysrq.txt (Linux sources), but I’d like to point to a nice trick for people using emulation and virtualization tools (ever tried to send Ctrl+Alt+Delete to a virtual machine?):

# echo $letter > /proc/sysrq-trigger

where $letter is any of the supported SysRq keys. As an example:

# echo d > /proc/sysrq-trigger
# dmesg | tail -1
[558193.423427] SysRq : HELP : loglevel0-8 reBoot Crashdump tErm Full kIll
saK showMem Nice powerOff showPc show-all-timers(Q) unRaw Sync showTasks
Unmount shoW-blocked-tasks

Just a quick word: Blender 2.46 has been uploaded to experimental a week ago, and is available on the following architectures:

$ rmadison -s experimental blender
blender | 2.46+dfsg-1 |  experimental | source, alpha, amd64, i386, ia64, mipsel, powerpc, s390

The move to unstable is planned once ftgl 2.1.3 has been released and uploaded to unstable.

This release’s highlight: Big Buck Bunny, as seen on the splash screen:

This was meant to echo Jeff Bailey’s Out and about!, where Jeff wrote about blood transfusion.

Every country has its own values, rules, and methods for blood donation (be it about anonymity, retribution, etc.), but please consider getting informed, and donate.

According to the Établissement Français du Sang (roughly translated to: French Blood Institute), the key point is to donate again, possibly on a regular basis.

Various possibilities in France: donate “full” blood (2 months delay between each, takes about 10 minutes), or selectively (plasma or platelets, 2 to 4 weeks delay between each, takes about a full hour).

You can save lives. Will you do it?

Many thanks to Helen for reminding me to write a note about important things.

As outlined some days ago, patience is a requirement. That said, I'm glad that all things come to (s)he who waits, Lufthansa hardware finally landed!

Ganneff, already very busy with his well-known DAM and ftpmaster hats, managed to also handle shipping some hardware donated by the Lufthansa some months ago.

pkg-games was promised a powerful box, look: Pentium 4 (2400 MHz, 1024 MB); we will finally be able to try and provide backports in a semi-automated fashion, so as to ease stable users' life, when it comes to installing bleeding-edge versions of their favourite games!

Thank you for making this possible and keeping everyone posted about the status of that hardware donation. Hopefully, it'll be possible to also communicate through “bits of the DAMs”, as suggested some weeks ago on debian-newmaint@.

Yay for communication! \o/

Random things you can't do without being a DD (and no, DM isn't the answer).

• Access porter box to try and reproduce build failures, test patches (I know about experimental, but building isn't sufficient in some cases, e.g. when runtime errors come into play).

• Introduce NEW packages on your own (Christian, you know I'm pointing to crappy packages to get them removed, so my karma shouldn't be that bad, at least regarding this particular point).

• Sponsor people you're working with, on a regular basis.

• More generally, sponsor people who have addressed each and every problem you could find in their prospective packages, and that aren't getting any more answer on debian-mentors@.

• Vote.

• Cancel by yourself a DELAYED/n NMU in case the maintainer reacts and has good reasons to postpone an upload, without having to bug the original uploader (who also has stuff to do and sometimes happens not to be available in due time).

• Access interesting data directly, like the cause of previous REJECTs for this or that package.

Being able to read debian-private@, having a nice^Wspammed @d.o address, or getting an lwn access could be added here, but that's only bonus stuff compared to the previous items (and I'm probably forgetting others).

Oh, yeah, I know, patience is the key. I'm not sure about how many months we're supposed to wait for an answer from James.

I'm not sure how many years we're supposed to wait for the various DAM problems to be solved.

Lucas is very worried about bringing fresh blood into Debian. Maybe there's some already, but it's not allowed to flow in.

Many thanks to all developers who are making it less frustrating by doing mass-sponsoring; and to everyone showing sympathy. Not listing you all, you know who you are.

emacs-goodies-el

• Test debian-mr-copyright-mode and report suggestions to Vincent Fourmond: done.

  Next todo: include it, probably in dpkg-dev-el.

pkg-games

• Prepare latest Bos Wars upstream, ask for a sponsor: done.

  Bos Wars is a futuristic real time strategy game.

  It used to have copyright and license troubles, but upstreams kindly addressed that.

pkg-phototools

• Finish libpuzzle packaging: done.

  Libpuzzle is a library to compare images, which also comes with a simple puzzle-diff binary scoring image similarity.

  Next todo: Wait for a review of the PHP bindings by Emmanuel Bouthenot (who already kindly rewrote upstream's manpages in a proper manner), then ask for a sponsor.

  Another todo: Check upstream status of CLSimilarImages, see whether it might be worth packaging it, and point the upstream authors to each others.

• Check LuxRender's upstream status: done.

  LuxRender is a rendering system for physically correct, unbiased image synthesis.

  The packaging has been ready for weeks, waiting for a released tarball (rather than working on a CVS snapshot). RC5 is on its way.

Misc.

• Suggest an option for fork()-based rendering to Blender upstreams: done.

  Blender is a free open source 3D content creation suite, including modelling and animating tools, as well as an internal renderer.

  For some reasons, one might want to use a fork()-based solution rather than one (only) based on threads (limited to 8 by default through a #define), when it comes to using a cluster.

  Next todo: try and hack it myself.

• Check appletouch's bug #465278 with latest kernel: done.

  appletouch is the mouse driver on iBook G4 machines, and tends to break badly when resuming from suspend2ram: it's unusuable until the next reboot. Not any better with 2.6.25-rc5-powerpc.

  Next todo: Report it upstream, following Maximilian's request.

• Check the status of a nasty xfwm4 bug: done.

  When the “switch back to previous workspace” option is enabled, and one keeps the key for switching to another workspace pressed too long, xfwm4 starts flickering between both workspaces, endlessly. Restarting X helps. That was previously reported to happen only on “low” machines, but it's easy to trigger this bug by lowering the delay before character repetition in the “keyboard” settings.

Of course, that's just an excerpt of the actual todo-list…

While rebuilding packages FTBFS'ing with gcc-4.3, I stumbled upon various quality/sanity levels for code & build systems: from very clean to not-so-nice, dirty, and even scary.

Fortunately, upstreams are sometimes funny and want to make us smile. This one succeeded.

That one is clanlib, bug #454818.

Like pusling already pointed out, there's still a lot to do with RC/RG bugs (although some of them are just prospective/incomplete patches, ls -1 *_gcc-4.3.diff | wc -l reports 133 right now).

Introductory reading for GCC 4.3: Porting to the New Tools.

Please fix your bugs, prepare NMUs and so on, instead of just trolling like/with a bird.

Looks like we (almost) have a candidate:

And since that has to be signed:

Photographs courtesy of Aurore D.

Problem present in openscenegraph 1.9.x and 2.x series: bug #425837.

Looking at the build logs of unstable or experimental for the hppa architecture, there's a linking problem around.

Shorten error message:

/usr/bin/g++ -fPIC -shared -Wl,-soname,libosgUtil.so.6 
    -o ../../lib/libosgUtil.so.6.0.0 "many *.o"
    -L/build/buildd/openscenegraph-2.2/build/osg/lib  -losg
    -lOpenThreads -lGLU -lGL -lSM -lICE -lX11 -lXext -lm -lpthread
    -Wl,-rpath,/build/buildd/openscenegraph-2.2/build/osg/lib 

/usr/bin/ld: CMakeFiles/osgUtil.dir/Optimizer.o(.text._ZNSt8_Rb_tree…
    …IjSt4pairIKjSt3setIPN3osg9Texture2DESt4lessIS5_ESaIS5_EEESt10_S…
    …elect1stISA_ES6_IjESaISA_EE9_M_insertEPSt18_Rb_tree_node_baseSH…
    …_RKSA_("unmangled name"): cannot reach 0000393f__ZNSt10_Select1…
    …stISt4pairIKjSt3setIPN3osg9Texture2DESt4lessIS5_ESaIS5_EEEEC1Ev+0,
    recompile with -ffunction-sections

/usr/bin/ld: final link failed: Bad value

First, just in case demangling is needed (that's not the case, but imagine), there's a nice tool to get the signature back (output skipped, it is very huge, that C++!). That's c++filt from the binutils package:

c++filt _ZNSt8_Rb_treeIjSt4pairIKjSt3setIPN3osg9Texture2DESt4lessIS\
5_ESaIS5_EEESt10_Select1stISA_ES6_IjESaISA_EE9_M_insertEPSt18_Rb_tr\
ee_node_baseSH_RKSA_

Then, one tends to trust the compiler. Added the following to the cmake command in debian/rules:

-D CMAKE_CXX_CFLAGS='-ffunction-sections'

But not much better. Oh wait, there's a quite interesting string in the build log now: cannot handle R_PARISC_PCREL17F, which looks like quite arch-dependant and perfect to be searched through the internets.

Some old bugreports came out: bug #334959 and bug #416496 and the solution: use -mlong-calls.

From http://www.projectblackdog.com/3rdParty/gcc/HPPA-Options.html, the relevant parts:

Generate code that uses long call sequences. This ensures that a call is always able to reach linker generated stubs. […] It is normally not desirable to use this option as it will degrade performance. However, it may be useful in large applications, particularly when partial linking is used to build the application.

It looks like it might do the job. And indeed it does. Conditionally added for the hppa architecture. And -ffunction-sections isn't even needed.

Thanks to the http://www.parisc-linux.org/ folks for the access to their cluster, which really helped finding out a fix very quickly!

And it looks like the number of blockers for the transition to testing has been reduced. \o/