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