Surgut

Looks like there is a recent trend to publicize one's debian activities, so I thought I should join in =) Not so sure if MDA acronym would work for these types of posts... Multiarch I have been working on multi-arching additional libraries. In particular I am working on multiarching boost libraries. At the moment boost1.53 multiarched libraries are uploaded in the experimental, and I am still working out the quirks with those. At the same time I have submitted a patch to multiarch libicu-dev, which has been accepted by the maintainer and is currently waiting in new queue.  This brings us closer to multiarching all of boost libraries. But as it has been pointed out at the Multiarch BOF at Debconf'13, one doesn't have to wait for dependencies (be it libs or lib-devs) to be Multiarched before multi-arching your own library. If you do it right (put all or arch-specifi headers in multiarch location, and place libraries in multiarch location, split utilities into a separate p...

configure, Makefile.in, config.guess & config.sub Are static, included copies of code that should always be rebuild during build. If they are not rebuild at build time, it should be documented/automated the relevant helpers that are needed to rebuild the package. If they are failing to rebuild it's RC since source code is provided that is effectively cannot be modified in the preferred form. They also should not be modified in patch form, as editing generated code is not preferred form of modification. Also it constantly hurts us when bringing up new kernels and architectures (recently kfreebsd, armhf, aarch64). dh_autoreconf is a great tool to achieve thiis s. no native packages Generally if software is useful in Debian Project it can be useful for other debian-like and unlike projects. In particular native packages do not offer the same patching flexibility as 3.0 (quilt), thus forcing downstream distributions to inline modify packages without DEP-3 headers. This hurts u...

$ bzr branch https://mingw-w64.svn.sourceforge.net/svnroot/mingw-w64/trunk $ cd trunk/ $ svn proplist -v -R https://mingw-w64.svn.sourceforge.net/svnroot/mingw-w64/trunk | grep externals -C1 Properties on 'svn-checkout/mingw-w64-headers/ddk/include': svn:externals ddk svn://svn.reactos.org/reactos/trunk/reactos/include/ddk $ bzr branch svn://svn.reactos.org/reactos/trunk/reactos/include/ddk mingw-w64-headers/ddk/include/ddk $ bzr join mingw-w64-headers/ddk/include/ddk/ $ bzr ci -m "Merging svn:externals" $ bzr merge :parent https://mingw-w64.svn.sourceforge.net/svnroot/mingw-w64/trunk is permanently redirected to https://mingw-w64.svn.sourceforge.net/svnroot/mingw-w64/trunk/ +N mingw-w64-crt/misc/wcstof.c +N mingw-w64-headers/direct-x/include/d3dx9shape.h M mingw-w64-crt/ChangeLog #snip M mingw-w64-headers/include/ChangeLog M mingw-w64-headers/include/dbghelp.h All changes applied successfully. $ bzr ci -m "merged from upstream svn" $ bzr merge svn://sv...

This advice has been posted on the debian-mentors mailing list. A quick how to generate symbols file $ apt-get source libsword6 $ cd sword-1.5.9 $ debuild binary $ rm -f debian/*.symbols dpkg-gensymbols* $ dpkg-gensymbols -plibsword6 -Pdebian/libsword6 | patch -p0 $ mv dpkg-gensymbols* debian/libsword6.symbols $ perl -pi -e 's/-\d.*//' debian/libsword6.symbols

dpkg-shlibdeps: warning: dependency on $(lib) could be avoided if $(object) were not uselessly linked against it (they use none of its symbols). I didn't like this build time warning at all. In the library packaging guide a found a nifty trick, add this line to the debian/rules (this is cdbs, don't know how it is done with debhelper scripts) DEB_CONFIGURE_SCRIPT_ENV += LDFLAGS=" -Wl,--as-needed" This worked for the executable and I've saved 300 bytes!!!!! Yeah =D It didn't work for the library though =( Bummer.