[00:00] <jpds> persia: They could of at least put: "This file left intentionally blank".
[00:00] <persia> It's from AT&T, not IBM
[00:04] <persia> geser, Erm.  Seems I broke it.  Sorry.  I'll try to sort that.
[00:06] <geser> persia: the last working upload was done in feisty, I doubt that code still works without changes to keep up with graphviz development
[00:06] <persia> It doesn't.
[00:07] <persia> Or rather, my patch didn't change that stuff: the failures come because the toolchain changed.
[00:08] <persia> Upstream seems to have had a release 2007/01/12, which might help.
[00:08] <geser> if I remember myself it's not only the error about NULL, if it would be only that, I would have fixed it for lucid. Once this error gets fixed others appear which I didn't figure out how to fix
[00:09]  * persia hunts for newer/better upstream stuff
[00:11] <geser> looking at the version numbers of graphviz in feisty, they were also 2.8 (like graphviz-cairo)
[00:11] <geser> graphviz in maverick is at 2.26.3
[00:13] <persia> graphviz-cairo source needs to be removed, based on graphviz 2.12-4 changelog.
[00:14] <persia> So other stuff probably needs adjusted build-deps
[00:15] <geser> nice, we could have dropped that package 3 years ago
[00:15] <persia> Or not (`reverse-build-depends graphviz-cairo seems blank)
[00:16] <persia> I wish I'd noticed this before uploading it.
[00:16] <persia> We probably ought to look more closely at any other main->universe demotions: I wonder how much cruft is about.
[00:20] <geser> persia: if you have some time: could you try to figure out the cause of the build-dependency problem of libfvm?
[00:21] <geser> I tracked it once down to build-depending on two different libhdf5-*-dev package which conflict each other
[00:22] <geser> but I didn't had time to check if Debian has the same problem (at least no bug is filed about it that I could find) and if Debian is not affected why then Ubuntu has this problem
[00:25] <persia> I want to do a powerpc/armel obvious pass first, before digging too much (and have to do some plumbing (the stuff with water and pipes) today) :)
[00:25] <geser> ok, have fun
[00:46] <persia> geser, just FYI, I can replicate the libfvm issue in sid.
[07:12] <AnAnt> Hello
[09:03] <AnAnt> Hello
[10:28] <geser> bilalakhtar: Hi, could you merge nepenthes from Debian unstable? -6 fixes an license issue (RC bug in Debian)
[10:28] <bilalakhtar> Thanks geser for notifying! of course I will!
[10:33] <bilalakhtar> geser: hehe, done on my local sys
[10:45] <bilalakhtar_> sorry, kernel panic
[11:00] <Rhonda> huhm, wesnoth still in maverick, and wesnoth-1.8 still not synced? Was off for a week  %-/
[11:04] <Laney> Rhonda: beta freeze is probably stopping archive admin activities
[11:04] <Laney> (speculation)
[13:03] <bilalakhtar> Thanks geser !
[14:28] <AnAnt> is it possible to upgrade from 9.10 to 10.04.1 ?
[14:30] <bilalakhtar> AnAnt: Yes of course, the only difference between 10.04 and *.1 is that *.1 has slightly more recent packages
[14:31] <blk> i'm trying to add an additional define to my rules file for a cdbs/CMake project but i can't seem to make it work. i've tried adding lines like "DEB_BUILD_OPTIONS += -DFOO=BOOL:ON" or DEB_CMAKE_EXTRA_FLAGS as well as DEB_CMAKE_CXX_FLAGS and others. ideas?
[14:50] <Rhonda> Laney: Going to check the bugreports that I filed.
[22:24] <geser> Given a C header doing #include <endian.h> while a file "endian.h" exists in the upstream source and upstream code gets compiled with -I. Which header file will get included? the system one or the local one?
[22:32] <Bachstelze> geser: the local one
[22:32] <Bachstelze> -I adds the path on top of the search list
[22:33] <geser> as I guessed, that explains http://launchpadlibrarian.net/49745563/buildlog_ubuntu-maverick-i386.uni2ascii_4.14-3_FAILEDTOBUILD.txt.gz
[22:34] <geser> how to fix this? drop -I. from CFLAGS? rename the local endian.h?
[22:35] <Bachstelze> depends
[22:35] <Bachstelze> if there are other header files needed in the source directory, it probably won't work without -I
[22:36] <Bachstelze> probably better to rename the upstream file
[22:36] <Bachstelze> and report the name conflict as a bug upstream
[22:41] <Bachstelze> geser: can you pastebin the contents of the upstream endian.h?
[22:42] <geser> Bachstelze: http://paste.ubuntu.com/485603/
[22:43] <Bachstelze> yeah, I guess there's no way around renaming it
[22:44] <Bachstelze> since endian.h is non-standard, I don't think upstream will be willing to rename it themselves
[22:46] <geser> thanks, renaming the header file fixed the FTBFS
[22:52] <ari-tczew> how can I use cmake's options in debhelper7 in smaller way? debian/rules now looks: http://paste.ubuntu.com/485606/
[22:52] <ari-tczew> I;m interested in one cmake option of these
[23:45] <Laney> make use of override_dh_auto_configure:
[23:47] <ari-tczew> Laney: yea, I looked on other packages for debhelper7. I found also override_dh_auto_build:
[23:47] <Laney> right
[23:47] <Laney> you can override any helper