[00:00] <ubottu> Launchpad bug 675108 in gnome-power-manager (Ubuntu) "gnome-power-manager adds battery to indicator twice when battery hot-unplugged and plugged back in" [Medium,In progress] https://launchpad.net/bugs/675108
=== medberry is now known as med_out
[03:37] <benonsoftware> Question: Is the MOTU mentor programme still running?
[03:57] <benonsoftware> is the MOTU mentor programe dead?
[03:59] <hyperair> i think it's been suspended indefinitely?
[03:59] <hyperair> or something
[03:59] <hyperair> i haven't heard of anyone being mentored recently
[04:00] <micahg> benonsoftware: you can just ask any questions you have here
[04:00] <hyperair> if you have any questions you can always come to irc and have someone here answer it anyway
[04:00] <benonsoftware> OK.
[04:00] <benonsoftware> hyperair: Why has it been suspended?
[04:00] <hyperair> benonsoftware: because having people post on the list or on the irc channel is much better.
[04:00] <hyperair> it takes the load of a single person to answer
[04:01] <hyperair> and having more opinions on things are usually better
[04:01] <hyperair> (this is my speculation)
[04:01] <benonsoftware> hyperair: I would perfear mentor rather than IRC or the list
[04:02] <hyperair> reason being?
[04:06] <benonsoftware> Alot
[07:52] <oier> hi, I am trying to use dh_python2 to package my python app.  Do I have to drop distutils and remove the setup.py?
[07:56] <dholbach> good morning
[07:58] <oier> Hi Daniel, do you know if in order to use dh_python2, you have to drop distutils (and remove the setup.py)?
[08:24] <dholbach> oier, I'm no expert when it comes to this, but AFAIK dh_python2 only works on the packaging level, so changing any of the upstream project installation code sounds like too much
[08:25] <dholbach> does http://wiki.debian.org/Python/TransitionToDHPython2 help?
[08:29] <oier> yeah I checked that link
[08:30] <oier> I am trying to package my python app, which installs fine using distutils
[08:30] <oier> but I am not sure if I have to remove the setup.py and replace it in the rules file
[08:31] <geser> oier: try asking in #debian-python on OFTC
[08:32] <geser> I'm pretty sure you don't need to remove it, the automagic python packaging relies on distutils
[08:32] <oier> ok, thanks
[09:05] <christitze> hi, i'm trying to do a debuild -S but i get the following error: make: *** No rule to make target `/usr/share/quilt/quilt.make'.  Stop. dpkg-buildpackage: error: /usr/bin/fakeroot debian/rules clean gave error exit status 2
[09:05] <christitze> does anybody know what i need to to do to make it work?
[09:07] <geser> "sudo apt-get install quilt"
[09:09] <christitze> thank you but now i get the error "make: dh_testdir: Command not found"
[09:10] <geser> install "debhelper"
[09:10] <nigelb> isn't there a meta package for all of those? devscripts?
[09:11] <jtaylor> yes devscripts installs everything
[09:13] <christitze> yes! it works now, thank you very much!
[09:15] <christitze> i think someone should edit the "fixing a bug in ubuntu" guide as there is no mention of the package devscripts and that's very bad for newbies like me
[09:16] <geser> nigelb: devscripts not really fulfills that role, the new meta-package "packaging-dev" (or similar) was made for this
[09:17] <nigelb> geser: Ah, If we pull the depds with ubuntu-dev-tools, I'd say that makes sense too.
[09:24] <geser> nigelb: there was a discussion about it, u-d-t shouldn't depend on them as the tools don't need them, and u-d-t should be abused for that. the meta-package is the right way to do it
[09:26] <nigelb> geser: Yeah, it does make sense. I was only suggesting a workaround :)
[10:10] <jtaylor> please set bug 771114 to triaged, thx
[10:10] <ubottu> Launchpad bug 771114 in gnubik (Ubuntu Oneiric) "gnubik version 2.3-2 failed to build on amd64 with GCC-4.6/oneiric" [High,Confirmed] https://launchpad.net/bugs/771114
[10:12] <jtaylor> forwarding upstream not necessary, seems fixed in the new unpackaged upstream version
=== dholbach_ is now known as dholbach
[11:16] <jtaylor> bug 749096 too
[11:16] <ubottu> Launchpad bug 749096 in idzebra (Ubuntu Oneiric) "idzebra version 2.0.44-2 failed to build on i386" [Undecided,Confirmed] https://launchpad.net/bugs/749096
=== chrisccoulson_ is now known as chrisccoulson
[11:22] <jtaylor> tumbleweed: you might want to nmu http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=554863, if you need a full debdiff ping me
[11:22] <ubottu> Debian bug 554863 in src:idzebra "FTBFS with binutils-gold" [Serious,Open]
[13:34] <oier> hi
[13:35] <oier> I am trying to package my first python app
[13:35] <oier> if I use debuild the package builds fine and works as expected
[13:35] <oier> but if I use pbuilder it fails
[13:35] <geser> missing build-dependencies?
[13:36] <oier> I don't understand the error message very much, could you please help me?
[13:36] <geser> I can try
[13:36] <oier> https://launchpadlibrarian.net/74791069/buildlog_ubuntu-natty-i386.indicator-bug_0.1-0~23~natty1_FAILEDTOBUILD.txt.gz
[13:36] <oier> the error is where it says"dh_auto_install: python setup.py install --force --root=/build/buildd/indicator-bug-0.1/debian/indicator-bug --no-compile -O0 --install-layout=deb returned exit code 1"
[13:37] <oier> BTW you can grab the source at https://code.launchpad.net/~oier/indicator-bug/trunk
[13:41] <geser> the command you pasted didn't exit successfully (it exited with exit code 1 instead of 0). This means something went wrong before that
[13:41] <geser> here most likely the "error: Inappropriate ioctl for device" in the previous line is the real error
[13:42] <oier> any idea on what that means?
[13:45] <geser> not really in this case
=== med_out is now known as medberry2
[13:48] <geser> oier: as the warning from InstallAndUpdateDataDirectory() is printed the next call would be to create_cfg_file
[13:49] <geser> and as that function doesn't print the uid and gid to the log I'd assume that either the os.getlogin() or pwd.getpwnam() fails
[13:49] <oier> the ioctl error is only present when I try to build it in launchpad
[13:49] <oier> with pbuilder that part looks like this http://paste.ubuntu.com/640142/
[13:50] <geser> the buildds (and also pbuilder) use a minimal chroot for building
[13:51] <geser> you can try "pbuilder login" to get a shell inside a pbuilder and experiment which of the both funktions fails
[13:52] <oier> so the best guess is that the control file is wrong because debuild works and pbuilder doesn't?
[13:55] <geser> debuild runs in your normal system
[13:55] <oier> could you maybe take a quick look at the control file to see if you spot a mistake?
[14:01] <geser> oier: I suspect the problem in setup.py as I'm not sure if create_cfg_file() will work on the buildds
[14:02] <geser> try commenting out the call to create_cfg_file() in setup.py
[14:02] <oier> ok
[14:03] <geser> you create there a config file for the buildd user which won't end in the deb file anyways
[14:04] <oier> how should I create the cfg file instead?
[14:10] <oier> geser: your theory was correct!
[14:14] <geser> oier: during the first start of the application: if the config file isn't there then create it
[14:14] <geser> that way every user gets a config file and not only that who installed the application
[14:15] <oier> ok
[14:15] <oier> thank you very much
[14:15] <oier> geser: you have saved me a lot of time
=== ximion1 is now known as ximion
=== and`_ is now known as and`
=== medberry2 is now known as medberry
=== vish is now known as jcastro_away
=== jcastro_away is now known as vish
=== paultag is now known as clearly_not_jcas
=== clearly_not_jcas is now known as paultag
=== micahg_ is now known as micahg
[16:47] <tumbleweed> jtaylor: have you pushed your source-highlight-qt patch upstream?
[16:49] <jtaylor> hm weirdly no
[16:50] <jtaylor> even though its sf
[16:50]  * jtaylor forwarding
[16:55] <jtaylor> done
[16:55] <tumbleweed> jtaylor: ok, I'll upload it now
[16:55] <jtaylor> the depends have been rebuilt against new boost?
[16:56] <tumbleweed> yes
[18:13] <tumbleweed> jtaylor: want to prepare an NMU for idzebra?
[18:45] <jtaylor> k
[18:48] <tumbleweed> jtaylor: and it looks like gpac needs some openssl 1.0 porting (note the amd64 build failure)
[18:51] <jtaylor> urg
[18:52] <tumbleweed> yeah, those are easy to miss when test building :/
[19:04] <jtaylor> tumbleweed: zebra debdiff http://paste.ubuntu.com/640304/
[19:08] <jtaylor> gpac does not seem to use sslv2, so just comment out the sslv2 function should do it
[19:20] <tumbleweed> jtaylor: please give some NMU warning on the bug (nmudiff --delay 2), and subscribe to its source package for a while (pts-subscribe does 30 days by default)
=== Quintasan_ is now known as Quintasan
=== yofel_ is now known as yofel
[20:11] <jtaylor> isn't delay 2 a little short?
[20:27] <tumbleweed> jtaylor: actually the maintainer is in LowThresholdNmu, no delay is necessary
[20:28] <tumbleweed> jtaylor: anyway, the maintainer uploaded it :)
[20:28] <jtaylor> good problem solved :)
[20:29] <jtaylor> fastest reaction to one of my patches so far :)
[20:30] <tumbleweed> being a reaction at all was a good start
[20:30] <jtaylor> paps will get fixed within the month too
=== medberry is now known as med_out