Hi!

Your package failed to build on the kfreebsd-* buildds:

gcc -DPACKAGE=\"pmacctd\" -DVERSION=\"0.14.0\" -DPROGNAME=1 -DIM_LITTLE_ENDIAN=1 -DHAVE_L2=1 -DHAVE_INET_PTON=1 -DHAVE_INET_NTOP=1 -DENABLE_IPV6=1 -DHAVE_PCAP_H=1 -DHAVE_LIBPCAP=1 -DPCAP_7=1 -DPCAP_TYPE_bpf=1 -DHAVE_LIBMYSQLCLIENT=1 -DWITH_MYSQL=1 -DWITH_PGSQL=1 -DHAVE_LIBSQLITE3=1 -DWITH_SQLITE3=1 -DHAVE_DLOPEN=1 -DSTDC_HEADERS=1 -DHAVE_SYS_WAIT_H=1 -DHAVE_GETOPT_H=1 -DHAVE_SYS_SELECT_H=1 -DHAVE_SYS_TIME_H=1 -DHAVE_U_INT64_T=1 -DHAVE_U_INT32_T=1 -DHAVE_U_INT16_T=1 -DHAVE_U_INT8_T=1 -DHAVE_64BIT_COUNTERS=1 -DENABLE_THREADS=1 -DRETSIGTYPE=void -DHAVE_VSNPRINTF=1  -I. -I.. -O2 -Wall -g -O2  -I/usr/include/postgresql   -c -o sockunion.o sockunion.c
sockunion.c: In function 'sockunion_print':
sockunion.c:628:26: error: dereferencing pointer to incomplete type
In file included from sockunion.c:25:0:
sockunion.c: At top level:
isis.h:41:31: warning: '_isis_devices' defined but not used [-Wunused-variable]
make[3]: *** [sockunion.o] Error 1

Full build log at
https://buildd.debian.org/status/fetch.php?pkg=pmacct&arch=kfreebsd-amd64&ver=0.14.0-1&stamp=1337846537

Regards

    Christoph

If you have further questions please mail debian-bsd@lists.debian.org

I don't understand, how is this ftbfs blocking the mysql transition?   I
can't read your mind; please try to overcommunicate in your bug updates in
the future.

Jamie,
	It simply means that it has not built against the new mysql on all
archirectures  yet. It does not imply that it is mysql related.

Jamie,

I have a proposed  fix as attached. It's built, signed and ready to go.
If you have intentions to fix it yourself please reply and do so
promptly. I'll run my fix past a few people for feedback but after that
I'll upload with a 2-day delay.

Hmm, it seems I got the debdiff the wrong way round. Resent.

Steven,
	Sorry I didn't notice the FTBS on hurd as I was concentrating on the
red. I guess I should have trusted the bug report title more.

However I am confused at what your are proposing. For a start I cannot
find a net/if_dl.h file on Hurd. Secondly I am not clear if using
AF_LINK as a conditional is a good idea. Surely that would change the
code on Linux, which is surely not what we want to do. Also googling for
Hurd and  sockaddr_dl has not so far turned up anything useful. What
bugs such as #636510 and #256669 do suggest is that AF_LINK is a bad
indicator of the presence of sockaddr_dl. Maybe the solution is to
furher guard the #ifdef AF_LINK bits by requiring that the OS not be Hurd.

Thanks for this.  It looks okay and seems it would fix the FTBFS.

However... I'm wondering if a more generic test could be used instead of
FreeBSD || FreeBSD_kernel.  Other BSD's would need this header too for
the sockaddr_dl definition[1].  And it looks like GNU/Hurd was failing
on this same code so it possibly has (or should have) the same.

[1] http://fxr.watson.org/fxr/trackident?v=FREEBSD9;i=sockaddr_dl
[2]
https://buildd.debian.org/status/fetch.php?pkg=pmacct&arch=hurd-i386&ver=0.14.0-1&stamp=1339115492

What about using AF_LINK as a test of whether to include this header?
It looks to me like it would work.

This way we'd be helping out GNU/Hurd at the same time, the fix would be
more appropriate for upstream and it helps with future portability.

Thanks again,
Regards,

Hi Nicholas,

I only noticed on buildd.d.o that the failure was the same there.

If you're not convinced, then the patch you have is fine.  It would fix
the immediate FTBFS on kfreebsd-* and this could be revisited later.

I was only trying to kill two (or more) birds with one stone here, by
accommodating GNU/Hurd, and keeping portability to some other future
k*BSD port, and if the patch is forwarded upstream they might like it to
fix this on other arches they support.

I'm not sure...  be warned that packages.d.o might not be indexing
package contents for GNU/Hurd.  (At least once before this has caught me
out).

For the Hurd, I thought, if the header inclusion test was AF_LINK:

1. if it supports sockaddr_dl, and has net/if_dl.h, it would be fixed

2. if it supports sockaddr_dl, but currently lacks net/if_dl.h, the new
build error would make the problem clearer, and it could build in future
without changes after they provide the missing net/if_dl.h

3. if it doesn't support sockaddr_dl, the AF_LINK test is wrong in
_both_ places so it wouldn't be able to build anyway;  we'd be no worse-off.

I was assuming that platforms without sockaddr_dl don't define AF_LINK.
 I don't see it in the Linux headers.

And the FXR pages also showed a correlation between AF_LINK being
defined on a platform, and the existence of a net/if_dl.h containing the
definition of sockaddr_dl.

Regards,

Jamie,
	Based upon the feedback I have received (including #debian-hurd) I am
attaching a new debdiff. Unless I get any more feedback I'll probably
upload it tomorrow with a 2-day delay.

This debdiff doesn't address the main point of my original mail:
sockaddr_dl and net/if_dl.h are not (k)FreeBSD-specific, so a test for
FreeBSD || FreeBSD_kernel would not be appropriate.  It might "work" but
would only replace one portability issue with another.

The new test for AF_LINK && !GNU looks even worse to me.  Does GNU/Hurd
_really_ define AF_LINK and yet not provide a net/if_dl.h with a
definition for sockaddr_dl?

Regards,

Steven,
	As I understood it you wanted the build to fail on Hurd so everyone
would know there was an AF_LINK/sockaddr_dl bug on Hurd. I am not
convinced that that is the right tack to take. I discussed the more
general AF_LINK/sockaddr_dl issue with Pino today, and he's going to
follow up on. But for now I'm just trying to get this package to build
in a sane - if not ideal - way. I'm still open to arguments of course
especially from the maintainer.

You still didn't address that in your reply.

If there is really an issue in GNU/Hurd, such as a missing header, then
yes, I'd prefer that the build fails[1], rather than add a workaround
(with whatever consequences) to this package (which someone would have
to remember to remove at the appropriate time, to restore the intended
functionality).

As it happens, if a workaround for the current FTBFS is all that's
needed, the attached diff would be able to do that very cleanly.

[1] Just to make sure this isn't the cause of any confusion:  FTBFS on
GNU/Hurd is not a blocker for Wheezy, testing migration or transitions.

Regards,

	You seem to have three issues:

1.) feature based tests rather than platform based tests.
I totally get the desirability of this. It means new OS 's or
improvements to OS's get picked up automatically. My issue was that this
does not work in *this* case. Furthermore I was ignorant of certain
specifics - which is why I was widely circulating the NMU - and so
improperly cautious.
2.) a proper audit trail and making Hurd accountable for the actual issue
Again I totally get this.
3.) You seem to see it fit to willfully cause an FTBS on Hurd, to make a
point.
I don't get that. Any point you might make would be lost in all the
other Hurd FTBS's. Surely it is much better to do something positive.

So I have raised a bug: #678358 to address the underlying issue.
I will clone this bug to a follow up bug blocked by #678358.
I will check the source code of the other packages that I am aware might
have this issue and do the same if I find anything.
I will not delay any more with this NMU and my proposed patch will

* use #if defined(AF_LINK) && !defined(__GNU__) in  both places as that
is as close to a feature check as we can get
* Have a comment explaining the issues in both the code and the patch
header.