[00:01] <jtaylor> hurray powerpc has finally reached the universe queue :)
[10:50] <l3on> Ampelbein, hey :)
[10:51] <l3on> about merge proposal number 93715, I have never understood if it's possible update directly my branch or I have to create a new one
[11:11] <Ampelbein> l3on: Hi! You can push to the old one and repropose for merging.
[11:12] <l3on> too late, I've already deleted the old branch and created a new one
[11:12] <l3on> thanks :)
[11:13] <Ampelbein> l3on: I find it much better if the branch stays the same, so I can just do 'bzr pull' and get the update.
[11:14] <Ampelbein> But no problem for now.
[11:14] <l3on> I'll do it next time :)
[13:17] <jtaylor> if a core-dev is bored, libvigraimpex needs a no change rebuild :)
[13:17] <jtaylor> for numpy
[13:37] <tumbleweed> jtaylor: are you doing to do the syncs you got FFes for?
[13:37] <jtaylor> tumbleweed: yes
[13:37] <jtaylor> gnudatalanguage still needs to wait for ppc build
[13:37] <jtaylor> pyzmq will be uploaded to debian today
[13:38] <tumbleweed> good, just making sure :)
[13:39] <jtaylor> I wonder what this private job is that is blocking on of the two ppc builders since 2 days
[13:40] <tumbleweed> I can't see what it is, either. ppc is badly backed up already, without things like that.
[13:41] <jtaylor> it must be one package as the other one is free, which package builds two days?
[13:42] <tumbleweed> presumably it's an embargoed security upload. And some of the likely candidates for that have pretty long build times
[14:03] <jtaylor> ajmitch: did you manage to fix the revu problem?
[14:03] <jtaylor> "Directory to upload to does not exist"
[14:30] <l3on>  Hi all... I've a question about packages have files (script) in /usr/lib/NAME/ directory
[14:30] <l3on> for instance → http://packages.ubuntu.com/precise/all/ivtools-bin/filelist
[14:31] <l3on> are files in the right place?
[14:31] <tumbleweed> that's a reasonable place to have them if they won't be invoked directly by users
[14:31] <l3on> some other packages are affected by bug like this:
[14:31] <l3on> `pkglibdir' is not a legitimate directory for `SCRIPTS'
[14:31] <l3on> ok, problem is pkglibdir_SCRIPT is incompatbile with automake 1.11.3
[14:32] <tumbleweed> well, scripst are probably be architecture-independant, so /usr/share is preferable...
[14:32] <l3on> ok :)
[14:32] <jtaylor> thats some weird autotools change
[14:32] <jtaylor> hit the mono apps too
[14:32] <jtaylor> directhex: ^ what was the fix again?
[14:38] <jtaylor> I think using programfilesdir as pkglibdir and programfiles_DATA for the scripts
[14:39] <l3on> I did this for ivtools:
[14:39] <l3on> -pkglib_DATA = src/ComUtil/comterp.err Idemo InterViews
[14:39] <l3on> +pkgdata_DATA = src/ComUtil/comterp.err Idemo InterViews
[14:39] <l3on> the location changes in this way:
[14:40] <l3on> -usr/lib/ivtools/Idemo
[14:40] <l3on> -usr/lib/ivtools/InterViews
[14:40] <l3on> +usr/share/ivtools/Idemo
[14:40] <l3on> +usr/share/ivtools/InterViews
[14:40] <l3on> what do you think ?
[14:41] <tumbleweed> if they are arch-independant (and the things that call them were also updated), then yes
[14:42] <l3on> no, I don't think they are arch-independant
[14:42] <l3on> this is a buildlog → http://debomatic.debian.net/precise/pool/ivtools_1.2.8a1-5build2/ivtools_1.2.8a1-5build2.buildlog
[14:44] <l3on> ah no, I'm wrong... they are text files
[14:45] <l3on> here the content of the files → http://paste.ubuntu.com/848626/
[14:46] <directhex> jtaylor, that was the fix, yes
[14:47] <directhex> autofoo 1.11.2 forbids use of pkglib_SCRIPTS, and enforces ELF-only got pkglib_LIBS
[14:47] <directhex> and pkgdata_DATA is wrong, since it installs to the wrong location
[14:47] <l3on> yep in /usr/share/NAME/
[14:48] <l3on> so, what may be a reasonable fix for this ?
[14:48] <directhex> let me find an example git commit for you
[14:49] <directhex> -pkglib_SCRIPTS = $(ASSEMBLY)
[14:49] <directhex> +programfilesdir = $(pkglibdir)
[14:49] <directhex> +programfiles_DATA = $(ASSEMBLY)
[14:49] <directhex> adapt that as appropriate for your project
[14:49] <l3on> mm ok
[14:49] <directhex> i.e. define your own dir (self-defined dirs have no restrictions) which is the same as pkglibdir, then use it
[14:50] <l3on> anyway, this not fix the problem.. this is just a workaround
[14:51] <l3on> I mean, effectly /usr/lib/NAME/ is a right place to locate scripts ?
[14:53] <jtaylor> it depends on the script
[14:53] <jtaylor> those in the paste look arch independent so share is correct
[14:54] <jtaylor> assuming the application expects them there
[14:54] <jtaylor> if not you need to either fix the application or install them in the old path
[14:54] <jtaylor> you should inform upstream about this autotools change
[14:54] <jtaylor> they may not know about it
[15:08] <l3on> directhex, thanks, it works perfectly!
[15:09] <directhex> l3on, /usr/lib/NAME is a reasonable place to locate things which are not ELF libraries. for example, GRUB .mod files
[15:26] <ari-tczew> could someone change the status of package in bug 931154 cause it's fixed upstream, not ubuntu?
[15:28] <jtaylor> ari-tczew: done
[15:28] <ari-tczew> jtaylor: thanks
[15:28] <jtaylor> ari-tczew: are you going to fix it in precise?
[15:29] <ari-tczew> jtaylor: yes I can
[15:29] <jtaylor> thanks
[15:30] <ari-tczew> when I got time I need to check whether oneiric needs SRU
[16:13] <jtaylor> Laney: could it the person responsible for transitions be added to the tracker?
[16:13] <jtaylor> might be useful information
[16:14] <tumbleweed> we could put it as a note (I see Debian has notes)
[16:15] <tumbleweed> linking to the tracking bug for the transition would be a pretty sane thing to do :)
[16:56] <jtaylor> hm I want to file a ffe for spyder there is already a upgrade request bug, should I convert that or just create a new bug?
[16:57] <tumbleweed> either works
[17:43] <jtaylor> nice new meld release, looks like its finally a general release
[17:43] <jtaylor> yet another ffe to file :(
[18:29] <directhex> poor jtaylor
[19:16]  * tumbleweed syncs pypy and prays to the buildd gods
[19:24] <stefanct> is there a way to prepare a bug report in launchpad without filing it yet?
[19:24] <tumbleweed> in a text editor?
[19:25] <stefanct> how does the text editor select the package, attach files, sets up affected distributions, subscribe other ppl...? :)
[19:26] <Ampelbein> stefanct: You can file bugs per mail.
[19:27] <Ampelbein> stefanct: https://help.launchpad.net/Bugs/EmailInterface
[20:34] <GCS> Hi! I'd like to ask sync for Debian packages in Ubuntu.
[20:34] <GCS> Who should I mail to?
[20:35] <Ampelbein> !sync | GCS
[20:38] <tumbleweed> GCS: however, Ubuntu is curretly in feature freeze, so we're only syncing things that fix important bugs without adding features
[20:38] <tumbleweed> (of course, there are exceptions)
[20:39] <GCS> OK, as I see ceph was synced meanwhile.
[20:39] <GCS> For a long time, Ubuntu had 0.38 , even if there was newer versions I've uploaded to Debian.
[20:40] <GCS> tumbleweed: ... and you sync from testing, right?
[20:41] <tumbleweed> by default, but that was before Debian Import Freeze, which was a while ago http://wiki.ubuntu.com/PreciseReleaseSchedule
[20:42] <tumbleweed> we can sync from any release, manually
[20:43] <GCS> tumbleweed: Do you see chance of syncing syslog-ng ? It contains important fixes, including but not limited to deadlocks and memleaks.
[20:43] <geofft> I believe Ubuntu syncs from unstable (before DebianImportFreeze) except for LTSes, and this is an LTS
[20:43] <GCS> geofft: Yes, that's why I've mentioned the testing sync.
[20:44] <tumbleweed> GCS: https://wiki.ubuntu.com/FreezeExceptionProcess
[20:44] <GCS> geofft: That's also the reason why syncing syslog-ng would be advised. Contains important bugfixes.
[20:45] <tumbleweed> GCS: note that syslog-ng is currently modified in Ubuntu, so it couldn't be synced anyway. It'd be a merge.
[20:45] <GCS> tumbleweed: Checking...
[20:48] <stefanct> Ampelbein: thx
[21:07] <jtaylor> I should probably have put some builds into the ppc queue before pypy :(
[21:07] <jtaylor> how long will that build?
[21:22] <tumbleweed> jtaylor: I see why you are concerned, the last Ubuntu build took 13 hours before timing out
[21:22] <tumbleweed> this'd probably be about the same, if it's going ot time out
[21:24] <tumbleweed> I don't mind you asking anyone to score it down
[21:24] <jtaylor> should be ok, I have nothing really urgent
[21:25] <jtaylor> as long as some slots are free until beta 1 I'm happy
[21:25] <jtaylor> if just this private job would end ..
[21:25] <tumbleweed> there's currently no jit on powerpc, so it's for completion more than anything else
[21:28] <micahg> jtaylor: should finish in ~1hr
[21:29] <jtaylor> good
[21:29] <jtaylor> I shoud make use of that an dput in my builds before the canonical guys start working :)
[21:30] <micahg> jtaylor: it's a 37 hour build :)
[21:30] <jtaylor> :O
[21:31]  * tumbleweed fondly remembers insanetoolkit (before it got saner)
[21:32] <micahg> tumbleweed: does bug 936483 need an FFe?
[21:33] <tumbleweed> no
[21:33] <micahg> thanks
[21:33] <jtaylor> micahg: can you do a no change rebuild of libvigraimpex?
[21:33] <jtaylor> for numpy
[21:34] <micahg> jtaylor: yeah
[21:34] <jtaylor> thx
[21:53] <micahg> jtaylor: libvigraimpex done
[21:54] <jtaylor> great, then numpy transition is done, only a arm armhf issue of pytables remaining :/
[21:54] <ajmitch> jtaylor: revu shoudl be fixed, are you having issues with it?
[21:55] <jtaylor> ajmitch: no but someone else, I'll tell him it should be fixed now
[21:55] <ajmitch> jtaylor: when were they having problems?
[21:55] <jtaylor> a few weeks ago
[21:55]  * ajmitch fixed it middle of last week
[21:57] <tumbleweed> jtaylor: that test suite seems to be problematic on a bunch of archs https://buildd.debian.org/status/package.php?p=pytables
[22:01] <jtaylor> yes I saw, was probably always the case it was just never executed before
[22:06] <jtaylor> it needs a new upload anyway, it has no compressors due to multiarch
[22:07] <jtaylor> upstream tried patching it with "%s-linux-gnu" % platform.machine() :/
[22:08] <jtaylor> is there some wiki page for upstreams how to handle multiarch?
[22:08] <jtaylor> I fear that these kinds of broken patches may start to spread
[22:09] <RAOF> I'm not aware of any.  Why is upstream doing that madness?
[22:09] <RAOF> aka: what is it trying to locate?
[22:09] <jtaylor> libraries
[22:10] <jtaylor> I told them its wrong and they now use a sane approach (ccompiler.has_function)
[22:13] <RAOF> Oh, that's a part of the build system?
[22:13] <jtaylor> yes
[22:14] <jtaylor> like numpy it just searched a set of constant folders
[22:14] <jtaylor> if it didn't find anything there it compiled without the feature
[22:16] <RAOF> Ah.
[22:17] <RAOF> Can we hit upstream with pkg-config?  Or, I guess, ccompiler.has_function.
[22:17] <jtaylor> there is no pkg-config integration in python distutils
[22:17] <jtaylor> so that is not such a good solution
[22:17] <jtaylor> also pkg-config is quite linux specific
[22:18] <jtaylor> and many python projects do also target windows and mac
[22:18] <jtaylor> ccompiler.has_function is apparently not so well known
[22:19] <RAOF> Perhaps it should be publicised.
[22:19] <jtaylor> it took me a while to find that in the api :/
[22:40] <l3on> Hi all..
[22:40] <l3on> someone knows if this can considered a bug?
[22:41] <l3on> libxml2-dev has header files in /usr/include/libxml2/libxml/*h
[22:41] <l3on> but, when you try to use it, problems occur:
[22:41] <l3on> /usr/include/libxml2/libxml/tree.h:16:31: fatal error: libxml/xmlversion.h: No such file or directory
[22:42] <jtaylor> did you set -I ?
[22:42] <jtaylor> -I/usr/include/libxml2/
[22:42] <l3on> jtaylor...
[22:42] <l3on> let me explain :)
[22:42] <l3on> I'm looking at /usr/include/augeas.h
[22:43] <l3on> it has a:
[22:43] <l3on> #include <libxml/tree.h>
[22:43] <l3on> so, when I try to run a configure from an application use that header, I get error
[22:43] <l3on> "libxml/tree.h" didn't found
[22:44] <l3on> s/didn't/not/
[22:45] <RAOF> l3on: It sounds a lot like you don't have the right include paths set.
[22:46] <geofft> "pkg-config --cflags libxml-2.0" prints -I/usr/include/libxml2
[22:46] <l3on> RAOF, I forced to use libxml2/libxml/tree.h in augeas.h and I get:
[22:46] <geofft> l3on: so you should put $(pkg-config --cflags libxml-2.0) in your compiler line
[22:47] <geofft> l3on: editing augeas.h is wrong
[22:47] <l3on> /usr/include/libxml2/libxml/tree.h:16:31: fatal error: libxml/xmlversion.h: No such file or directory
[22:47] <l3on> geofft, ok I now
[22:47] <l3on> geofft, problem is build fails during configure!
[22:47] <RAOF> And if augeas needs libxml2, it should Requires.private: libxml-2.0 in it's pkg-config.
[22:47] <l3on> http://debomatic.debian.net/precise/pool/haskell-augeas_0.4.0-1ubuntu1/haskell-augeas_0.4.0-1ubuntu1.buildlog
[22:48] <RAOF> l3on: So, I'd fix this by patching configure.ac to use pkg-config, and then submitting it upstream.
[22:49] <RAOF> l3on: They're using AC_CHECK_HEADER, which, as you can see, is easily broken.
[22:49] <l3on> mmm ok, so the bug is in augeas ?
[22:51] <RAOF> l3on: No, the bug is in configure for haskell-augeas.
[22:52] <l3on> ah ok... :)
[22:53] <RAOF> haskell-augeas' configure script should use PKG_CHECK_MODULES to find augeas, rather than AC_CHECK_HEADER.  Because AC_CHECK_HEADER will fail when non-trivial include paths are required, such as - as you can see - libxml2.
[22:53] <l3on> ok, thanks :)
[22:55] <jtaylor> would it still be possible to get the new git-buildpackage?
[22:55] <jtaylor> it has a couple of useful new features
[23:17] <Laney> l3on: ta for looking at it. I'd already fixed it locally but didn't do anything with it. It would be nice if you could submit a Debian bug with the patch and X-Debbugs-CC the upstream author.
[23:18] <Laney> the other haskell FTBFS (about the threaded runtime) can be closed as wontfix until ghc supports that
[23:18] <Laney> if you want to do that.
[23:20] <l3on> Laney, well.. :D actually I'm still studing PKG_CHECK_MODULES manpage :)
[23:20] <Laney> more valuable experience for you then
[23:22] <l3on> well I don't uderstand what's wrong:
[23:22] <l3on>   PKG_CHECK_MODULES([AUGEAS], [augeas >= 0.8])
[23:22] <l3on> ./configure: line 2625: `  PKG_CHECK_MODULES(AUGEAS, augeas >= 0.8)'
[23:22] <l3on> ./configure: line 2625: syntax error near unexpected token `AUGEAS,'
[23:36] <l3on> ok, I'm out. I don't know why I get that error.
[23:37] <micahg> tumbleweed: are we doing FFe's for dh_python2 conversions again?
[23:47] <tumbleweed> micahg: they are considered build-system changes, and could generally benefit from extra review