[10:21] <Quintasan> Hiho, if any REVU admin is online please ping me.
[13:11] <nekohayo> hey there, would someone be kind enough to enlighten me on what's going on with http://code.google.com/p/specto/issues/detail?id=266 ?
[13:12] <nekohayo> it seems like whenever the user has python 2.4, it insists on trying to compile the package even though python 2.6 is the default
[13:12] <nekohayo> thus making .debs fail
[13:33] <geser> when installing a python module it gets made available for all installed python versions
[13:41] <artfwo> hello! I'm looking for a second advocation of http://revu.ubuntuwire.com/p/scantailor - an interactive post-processing tool for scanned books (c++/qt/cmake/cdbs)
[13:41] <artfwo> could anybody help with that one? :)
[14:00] <nekohayo> geser: well, even if the code compatibility breaks from one python version to the next?
[14:00] <nekohayo> that doesn't quite make sense to me
[14:02] <kklimonda> nekohayo: you can define in package which versions of python is it compatible with
[14:03] <nekohayo> you mean make the package conflict with python2.4, or something else?
[14:07] <kklimonda> nekohayo: I don't know how is specto packaged but in general (if you use python-central or python-support) you can specify a versions of python that the module is compatible with - either using XS-Python-Version: field or some magic file in debian/ directory
[14:26] <nekohayo> thanks for the advice folks :)
[16:09] <dreamcat4> Hi guys, I've been having an autoconf issue, but only for the ppa builds
[16:09] <dreamcat4> i can build locally ok, from the unpacked source dir
[16:10] <dreamcat4> its driving me crazy
[16:14] <dreamcat4> going to try 'debuild -B php5_5.2.10.dfsg.1-1ubuntu18.dsc'
[16:14] <dreamcat4> but i won't get the error, i just know it
[16:44] <directhex> dreamcat4, how about with pbuilder?
[16:45] <dreamcat4> yeah, i run pbuilder locally and can't reproduce the error
[16:46] <nixternal> dreamcat4: what is the autoconf error you are getting in the PPA builds?
[16:47] <dreamcat4> i'll put you the link to the build log
[16:47] <nixternal> groovy :)
[16:47] <dreamcat4> https://launchpad.net/~dreamcat4/+archive/karmic/+build/1154420/+files/buildlog_ubuntu-karmic-i386.php5_5.2.10.dfsg.1-1ubuntu18_FAILEDTOBUILD.txt.gz
[16:48] <dreamcat4> i'm gonna put up a 'success' log too, so you can compare the two together
[16:50] <dreamcat4> The success case (on local) https://dl.getdropbox.com/u/588496/Terminal%20Saved%20Output.txt
[16:52] <nixternal> hrmm...confdefs.h is part of libsnack2-dev correct?
[16:54] <nixternal> dreamcat4: can you link me to the .dsc file for this package so I can see something?
[16:54] <dreamcat4> okay
[16:55] <dreamcat4> https://launchpad.net/~dreamcat4/+archive/karmic
[16:56] <nixternal> thank you
[16:57] <dreamcat4> confdefs.h is a generated autoconf file
[16:58] <dreamcat4> just building again (locally) with pdebuild
[16:59] <nixternal> ahh, right
[16:59] <dreamcat4> no missing confdefs.h
[16:59] <dreamcat4> its so off. There was a different autoconf error which was about the build stamps for the make targets
[17:00] <dreamcat4> I added 'sleep 1' to fix that. Then i get this error
[17:01] <dreamcat4> If I look at the successful build, the './configure' script is different
[17:01] <dreamcat4> and there is no references at those lines about the ac_fn_... undefined constant either
[17:02] <dreamcat4> So it's like the configure script is totally different (on the Launchapad build farm)
[17:06] <nixternal> do you get a lot of dpkg-source warnings with debuild?
[17:07] <dreamcat4> yes
[17:07] <nixternal> k, just making sure
[17:08] <dreamcat4> those warnings don't appear on the buildfarm log files
[17:09] <dreamcat4> which seems the only discernable difference between the two log files
[17:09] <nixternal> wonder if they have a poopy libtool
[17:10] <dreamcat4> The only thing I can think to do is add a link in the rules file before it falls over
[17:10] <dreamcat4> like "cat ../configure"
[17:11] <nixternal> dreamcat4: it crashed out in my pbuilder as well
[17:11] <nixternal> same exact error
[17:11] <dreamcat4> okay. Do you have the work source dir ?
[17:12] <dreamcat4> maybe there's some temporary files left over by the autoconf tools
[17:12] <dreamcat4> Mainly i'd like to know if the confdefs.h was generated (in a different directory)
[17:23] <nixternal> had to reenable my hooks as they were removed for some reason
[17:23] <nixternal> at least I hope I just reenabled them :)
[17:23] <dreamcat4> hooks ?
[17:24] <nixternal> ya, so when it FTBFS it drops me to a shell instead of cleaning everything out :)
[17:24] <dreamcat4> ahh
[17:31] <nixternal> apache2-build/confdefs.h
[17:31] <nixternal> dreamcat4: ^^
[17:32] <dreamcat4> thanks that makes (a bit more sense)
[17:33] <dreamcat4> if you can,  please bzip the whole thing and upload to: http://www.snapdrive.net/pupload/   (500MB Max filesize)
[17:34] <dreamcat4> or email just the ./configure file to dreamcat4 {at} gmail.com
[17:34] <nixternal> hrmm
[17:34] <nixternal> ya, I can do that one, as I have no clue how to get a tarball out of the buildd
[17:35] <dreamcat4> yeah - i don't know either
[17:36] <dreamcat4> scp it over ssh?
[17:39] <nixternal> ooh, I installed ssh into the buildd, lets see if this works, as that configure file is huge
[17:39] <nixternal> so, do you want the tarball or just the configure?
[17:40] <dreamcat4> well thank you - erm the tarball might quite big but i'd really like it pretty please !!
[17:40] <nixternal> doing it now
[17:45] <jtimberman> Need another MOTU / Developer for Chef, Merb and Syntax ruby lib: https://bugs.launchpad.net/ubuntu/+bug/404403 (merb/syntax bugs linked in latest comment) please.
[17:46] <nixternal> dreamcat4: http://people.ubuntu.com/~nixternal/php5.tar.bz2
[17:51] <dreamcat4> unpacking tarball...
[18:02] <AndrewGee> Are there any MOTUs around that can help me with a proposed SRU patch I've attached to a bug? https://bugs.launchpad.net/ubuntu/jaunty/+source/osm-gps-map/+bug/387043
[18:32] <ximion> Hello! Could someone (who has enough time) please review the Smile-package ( http://revu.ubuntuwire.com/p/smile )? It should be finde now.
[19:10] <ripps> Is it worth keeping backports for hardy in the gmpc-trunk ppa? It's getting harder to get things to build for it because it's getting so out of date
[19:11] <ripps> I was hoping to keep hardy until the next LTS came out, but it's getting pretty difficult to do so.
[19:12] <Aquina> Why? I'm using hardy too.
[19:14] <ripps> Aquina: I maintain a ppa for bleeding egde ppa package, but the developer is moving on to vala and automake1.11 and it's making it difficult to backport all the necesary packages just to build the packages
[19:14] <ripps> vala0.7 to be precise
[19:15] <ripps> He's thinking I should just discontinue hardy/intrepid support, but I'm unsure if anybody else is still using it or not.
[19:15] <Aquina> oh. I never heard about that one.
[19:16] <Aquina> A language?
[19:16] <kklimonda> Vala? yes
[19:16] <ripps> Technically, automake1.11 isn't even in Karmic, but I easily add some packages fo build-depends.
[19:17] <kklimonda> ripps: if it's getting too troublesome then just drop it. People who use bleeding edge most likely aren't using Hardy anymore
[19:17] <ripps> Do Hardy users even using bleeding-edge package ppa's?
[19:17] <kklimonda> exactly my though
[19:17] <Aquina> Hey! We use harrdy because of the *big* LTS.
[19:17] <Aquina> That's way some KMU's don't use SuSe, RHEL, etc.
[19:18] <ripps> Man, why aren't there ppa download counters, this would be alot easier to decide if I knew what the userbase for my ppa was.
[19:18] <Aquina> We are 20+ people in our organization and need LTS since we do not have the time and resources to make a dent every 6 months.
[19:19] <kklimonda> Aquina: but do you use all those bleeding edge PPAs?
[19:19] <Aquina> What about the Ubuntu/Xubuntu popularity contest?
[19:19] <dhillon-v10> Ubuntu is better
[19:19] <kklimonda> :D
[19:19] <Aquina> It runs as a cron job or s.th. Can't we use that one?
[19:20] <kklimonda> Aquina: only if ppa packages has different name from the ones from distribution.
[19:21] <Aquina> No, we intentionally avoid bleeding edge stuff. But a language that avaoids problems of C (and is yet powefull) can't be bleeding edge but must be a standard ASAP. Please correct me in case I'm wrong with my assumptions.
[19:21] <Aquina> oh I see.
[19:21] <kklimonda> Aquina: Vala isn't stble yet :/
[19:21] <kklimonda> stable*
[19:21] <Aquina> hm.
[19:22] <Aquina> Ok... the other way round...
[19:22] <kklimonda> Aquina: I think we were discussing gmpc all the time
[19:22] <Aquina> who much time whould it take to bacckport it and what intervals are necessary?
[19:22] <kklimonda> Aquina: vala is just a language and a) it generates C code and b) isn't widely used
[19:22] <Aquina> gmpc?
[19:23] <ripps> Aquina: the GNOME Music Player Clinet. A gtk client for MPD
[19:23] <kklimonda> Aquina: that's what ripps was talking about - he just mentioned that the author is rewriting (parts of) it in vala
[19:23] <Aquina> hence.. I'm using Audacious :-)
[19:23] <Aquina> (I loved Winamp)
[19:23] <kklimonda> ripps: fwiw I wouldn't loose time for hardy if it was that troublesome
[19:24] <ripps> Well, the guys at #mpd are constantly pointing to my ppa's for bleeding-edge packages, so I'm unsure of the userbase, and I don't want to just cut out a bunch of people just because it's a little difficult to backport a few packages
[19:25] <Aquina> Ok I see. But how can I help you without to estimate a man hour-count or something?
[19:26] <Aquina> You need to estimate the userbase, appraise who long it will prevent you from doing differnt work, and take into account wether there are more important projects to do atm.
[19:30] <Aquina> You could temporarily create a package with a totaly weird name to check userbase?
[20:30] <Quintasan> nixternal: ping
[21:24] <Aquina> pong
[21:43] <doctormo> Stupid question: Does anyone here know how to do packaging for init.d based services and would like to spend 10 mins packaging a wakeonlan-enable scripts which turn on ethtool wol for a client computer.
[21:43] <dtchen> i'm happy to help you if you want assistance, but i won't do it instead of fixing my current plate.
[21:44] <doctormo> dtchen: You have so much on your plate you broke it?
[21:45] <dtchen> in a manner of speaking
[21:49] <doctormo> dtchen: Then can you advise on the best way of setting of a run once on boot package with single etc config and single sbin script?
[21:53] <dtchen> doctormo: take a look at procps for hints
[22:04] <doctormo> dtchen: Awe, I figured you'd tell me rather than getting me to chase docs.
[22:05] <doctormo> dtchen: Although it doesn't appear to be that useful, not from the first docs. It talks a lot about /rpoc
[22:05] <doctormo> proc*
[22:07] <doctormo> dtchen: Maybe I don't understand the context I should be searching these docs for
[22:08] <dtchen> take a look at debian/init
[22:09] <doctormo> dtchen: Or maybe you want me to download the source package for it and look at the debian directory?
[22:09] <dtchen> yes, sorry for not making that explicit
[22:11] <doctormo> dtchen: Ah then that is most helpful, thanks for the pointer.