Back in September at the Linux Plumbers Conference in New Orleans, James Hunt and I presented Upstart roadmap, which included porting Upstart to kFreeBSD/glibc. The first milestone is now complete.

Libnih is ported to kFreeBSD/eglibc. During the course to get there the following has happened:

• Petr Salinger (ps-guest) adds waitid() support to eglibc-2.18 packaging branch using wait6 syscall

• Later libnih test-suite gets a test case failure, which is then reported to FreeBSD.org. Turns out some syscalls on FreeBSD returned bogus siginfo_t.si_status information in some cases. Luckily there is now a full test-case and kernel patch posted by Jilles Tjoelker. Once that's committed upstream, I'll push for uploads to the affected kernels in Debian.

• A few small patches applied to libnih, mostly adding POSIX compliant header includes and the like.

So with a patched libc and patched kernel one can compile libnih & run its test-suite. There are however some caveats feature miss-partiy:

• nih_watch / inotify support is disabled. This is TODO on my list to port nih_watch to use kevent/kqueue EVFILT_VNODE.

• FreeBSD kernel doesn't have abstract namespace domain sockets, so at the moment I have disabled some abstract namespace test-cases & changed dbus-connection tests to use pathname sockets instead. This is still a TODO because unlink before bind is not done, and the socket is not cleaned up after servers close it at the moment.

With all caveats above, here are the test-suite results:

================================================
libnih 1.0.4: nih-dbus-tool/test-suite.log
================================================

# TOTAL: 2492
# PASS: 2492
# SKIP: 0
# XFAIL: 0
# FAIL: 0
# XPASS: 0
# ERROR: 0

.. contents:: :depth: 2

===========================================
libnih 1.0.4: nih-dbus/test-suite.log
===========================================

# TOTAL: 110
# PASS: 110
# SKIP: 0
# XFAIL: 0
# FAIL: 0
# XPASS: 0
# ERROR: 0

.. contents:: :depth: 2

======================================
libnih 1.0.4: nih/test-suite.log
======================================

# TOTAL: 788
# PASS: 787
# SKIP: 0
# XFAIL: 1
# FAIL: 0
# XPASS: 0
# ERROR: 0

.. contents:: :depth: 2

PASS: test_watch
================

not ok 1 - nih_watch not supprted yet # TODO
XFAIL: test_watch 1 - nih_watch not supprted yet # TODO

at tests/test_watch.c:1594 (main).
1..1

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...
MultiarchI 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 package), you can go and multiarch your libraries ahead of time. Maybe it's time to default to debhelper 9 in dh-make, and default to multiarch locations for all libraries?

Boost also has libraries which depend on mpi, and at the moment that's not multiarched. I'm not sure if there are additional considerations there given the support for alternative mpi implementations in Debian.

Boost also depends on libpython. At the moment it's shipping libboost_python-py2.7.so & libbost-py3.3.so, with a libboost_python.so symlink to libbost_python-py2.7.so. I do wonder if it's a sensible approach, or should the boosty_python library be simply shipped in arch specific & python implementation specific paths e.g. /usr/lib/pythonX.Y/config-X.Y$(abi_tag)-$(DEB_HOST_MULTIARCH)/ that way we'll be able to support python debug interpreter in python_boost. I guess I should seek expert opinion on other multiarch wizards.

In addition to boost, I've now started looking at qmake and how it handles multiarch. At the moment, it doesn't handle it much. All paths are statically copied around and hard-coded in each module qmake provides. I have now been working at abusing qmake's $$system to call into dpkg-architecture, and actually choose native or cross compiler & adjust settings and paths to Qt libraries. There are a couple of bugs to fix, but I should be able to propose a "debian-multiarch" qmake spec soon. Such that in calls dpkg-architecture & properly adjust compilers & locations for the DEB_HOST. qmake by the way has its quirks. For example all variable assignments seemed to default to be "by value" & not "by reference" (i.e. upon assignment all variables on the right hand side get expanded and the literal string is stored, instead of storing $(prefix)/lib/$(arch), and evaluating that later.) Hence my current qmakespec is less elegant than I hoped.
upstart on kFreeBSDFreeBSD 9.2 and up have implemented the wait6 and with it waitid is also exposed. At the moment there are some differences between glibc and FreeBSD waitid usage. I am not well versed in glibc, FreeBSD and POSIX, but the bug at hand & POSIX reference lead me to believe that POSIX is slightly ambiguous about it.

Why is waitid support is interesting? Well, kFreeBSD/libc maintainer in Debian is working on exposing it with/after (e)glibc2.18 is in Debian, which will remove one more blocker from porting Upstart to kFreeBSD. To this extend, I have in the mean time setup FreeBSD & kFreeBSD virtual machines and got libnih to compile on both (sans waitid on kFreeBSD). One of the optional upstart's features is to use inotify to spot & reload configuration files, at the moment I haven't ported that functionality to use native kevent/kqueues (EVFILT_AIO) instead I have cheated and packaged for Debian the Google Summer of Code 2011 project libinotify-kevent which provides inotify compatible API, implemented with kevent. Which is kind of the reverse strategy of libkqueue and/or libevent. It would be interesting to see kernels and/or those libraries to unify/standartise on common APIs. Unfortunately, it still seems like using native API for each kernel is best to avoid dependencies and leverage all features and semantics. Nonetheless I did package it for now. To further progress with actually porting upstart, I'd like to get my hands at (e)glibc 2.18 compiled for kFreeBSD with waitid patches. I got pointers to the patches, but I haven't yet succeeded at compiling (e)glibc with those applied. So no upstart booting kFreeBSD VM yet, but rather work in progress. It's quite fun. It's been years since I have touched a FreeBSD boxes and it's first time me using kFreeBSD. The semantics, differences and benefits of each do shine and it's a promising platform.
Multiarch on kFreeBSD?

dh-autoreconf is an amazing addon for running autoreconf, I just love it.
abi-compliance-checker is an amazing tool for tracking API/ABI.
Wouldn't it be great to glue abi-compliance-checker into dh / cdbs packaging?!

abi-compliance-checker (1.98.8-1~exp1) experimental; urgency=low
.
* New upstream release
* Add dh_acc to generate and compare library dumps at build time,
together with addons for dh(7) and cdbs.
* Bump standards version, bump debhelper to 9, use 3.0 (quilt) format,
update Vcs-Svn field to canonical form, remove obsolete
DM-Upload-Allowed.
* Apply a patch to allow suffixes on a-c-c abi dumps.

Horay! So how does one use it?

• build-depend on dh-acc
• In your debian/rules
• call dh_acc somewhere appropriate
• dh $@ --with acc
• include /usr/share/cdbs/1/rules/acc.mk
• In your debian/libpackage-dev.acc
• Write a abi-compliance-checker descriptor (no need to include version)
• Build your package
• Copy the generated /usr/lib/$(multiarch)/dh-acc/*.abi.tar.gz as ./debian/lib-package-dev.abi.tar.gz.ARCH
• Now at each build ABI/API checks will be executed and compat reports will be generated

Wheeze is planned to release very soon! There is still a fair amount of work to push the release out, but it does mean that a lot of fun can begin for jessie.

Over the past cycle in Ubuntu, many packages where synced from experimental, many fixes were applied and many packages were upgraded ahead of debian version strings.

If one goes to your package PTS page at:

• Useless irrelevant changes =) oh well, it happens
• FTBFS fixes due to GCC 4.8 (*)
• FTBFS fixes due to new GlibC
• FTBFS fixes due to multiarched Python2.7 and Python3.3
• FTBFS fixes due to multiarched Tcl/Tk
• FTBFS fixes due to Python hash randomisation enabled
• FTBFS fixes due to Boost 1.53 (*)
• Fixes to minimise dependencies when bootstrapping packages
• Fixes to multiarch more and more libraries
• Fixes to enable package cross-building
• Updates to new upstream releases
• Usage of pybuild
• Completed migration away from guile1.6

On debian:

Squid-deb-proxy-client is not packaged just fetch and install it. It's really just one python script & one conffile. Or I have published the python script and the config as part of this posts gist.

Next all of the avahi magic, really is just publishing a service file & letting the python-script from the squid-deb-proxy-client package find it, and adding apt-conf.d snippet which calls the above mentioned script and generate correct proxy line.

But we are running apt-cacher-ng! So on the server where apt-cacher-ng is running drop this:

/etc/avahi/services/apt-cacher-ng.service

<?xml version="1.0" standalone='no'?>
<!DOCTYPE service-group SYSTEM "avahi-service.dtd">
<service-group>
 <name replace-wildcards="yes">apt-cacher-ng proxy on %h</name>
 <service protocol="ipv4">
  <type>_apt_proxy._tcp</type>
  <port>3142</port>
 </service>
</service-group>

Now on any host that you want automatic apt-proxy discovery, simply install squid-deb-proxy-client & your apt-cacher-ng will be auto-discovered.

What about sbuild? Well, you don't really want to install avahi-daemon and start it inside the chroot, so we can cheat with creating an executable hook:

/etc/schroot/setup.d/51aptproxy
#!/bin/sh
set -e

. "$SETUP_DATA_DIR/common-data"
. "$SETUP_DATA_DIR/common-functions"
. "$SETUP_DATA_DIR/common-config"

APT_AVAHI_DISCOVER=/usr/share/squid-deb-proxy-client/apt-avahi-discover

if [ $STAGE = "setup-start" ]   [ $STAGE = "setup-recover" ]; then
    if type apt-avahi-discover 1>/dev/null; then
        APT_AVAHI_DISCOVER=apt-avahi-discover
    fi
    APT_PROXY= $APT_AVAHI_DISCOVER 
    if [ -n "$APT_PROXY" ]; then
        info "Setting apt-proxy to avahi proxy at $ APT_PROXY "
        printf 'Acquire::http   Proxy "%s"; ;\n' $ APT_PROXY  > "$ CHROOT_PATH /etc/apt/apt.conf.d/30schrootautoproxy"
    fi
fi

Tadah. Now I'm using my apt-cacher-ng whenever I'm on my home WiFi =)

• apt-cacher-ng should auto-create avahi service file in it's init script
• apt-get or some other package should ship apt-avahi-discover script (there is also a C implementation available)
• apt-get or some other package should ship the apt.conf.d snippet
• sbuild / pbuilder / cowbuilder / mk-sbuild / [p cow]builder-dist should have hooks to retrieve hosts' apt proxy settings and use them in the chroots

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 us, when trying to merge useful stuff from derivatives back into Debian, as changes are not split into individual patches.

shared maintainership
I'd like to put all my packages under "Debian Developers <debian-devel d.o="">" maintainership. There is no need for NMU, QA, TEAM upload. If you have a patch, I don't want a bug in BTS nor commits, I'd like you to simply upload it into the archive. Especially blanket changes must be welcomed across the whole archive: translations, unit tests, porting to new debhelper versions, FTBFS fixes against next versions of compilers and interpreters, multiarch & cross-building fixes, porting to latest best packaging practices.</debian-devel>

ps. comments are turned off. All further discussion is redirected to your choice of: debian-devel or my personal email.

<iframe allowfullscreen="allowfullscreen" frameborder="0" height="480" src="https://www.youtube-nocookie.com/embed/Ke1Ilm6joO0" width="853"></iframe>

I'm going to Debconf12

Hello Debian Planet!