[00:45] <Legendario> any hint here: http://ubuntu.pastebin.com/EJ3dPfKT ?????????
[02:01] <stevecrozz> micahg: have you had a chance to look at http://revu.ubuntuwire.com/p/uwsgi again?
[02:04] <micahg> stevecrozz: you still need to run update-maintainer, but I'd like to chat with the ITP person a little more
[02:05] <stevecrozz> micahg: i did run update-maintainer, does still look like I haven't?
[02:05] <micahg> stevecrozz: ah, maybe w/out an internet connection?
[02:05] <micahg> oh, hmm
[02:06] <stevecrozz> hm, i don't think so... is something wrong with it?
[02:06] <micahg> nm, it's because it's not in the archive yet
[02:08] <stevecrozz> micahg: I'll let leonid know you want to talk with him, maybe i can get him to pop in here again
[02:09] <micahg> stevecrozz: he's got almost everything
[02:11] <stevecrozz> micahg: is there anything I can do to help?
[02:12] <micahg> I just don't see the need for dynamic build-deps
[02:15] <stevecrozz> i have no strong feelings on that, i guess we'll see if leo can convince you
[02:28] <stevecrozz> hey micahg: leo just arrived, he's onehundredthirty
[02:29] <micahg> hi again onehundredthirty
[02:29] <onehundredthirty> hi
[02:29] <micahg> I saw your modifications, why the need for build-deps being variable?
[02:29]  * micahg sees no evidence in control.in
[02:31] <onehundredthirty> yes, I didn't put it into control.in. but could you please try to clone repository and build it? it will fail because of Build-Depends
[02:32] <micahg> onehundredthirty: sure, but do you know what needs to be changed?
[02:33] <ebroder> onehundredthirty: by the way, i was wrong yesterday when i said that other packages didn't support multiple interpreters. libapache2-mod-wsgi actually builds both a py2.6 and py2.7 module in the same package
[02:36] <pabelanger> So, if I had a Ubuntu package, could I recompile it twice? Once for <package> and another time for <package-dbg>?   There are some specific compile time flags I would need to set for a -dbg version of the package
[02:36] <onehundredthirty> ebroder: yes, i see it. yesterday I talk with member of Debian Python Modules Team on #debian-python and he pointed out this package. it was after I posted comment on REVU. and now I think to change the uWSGI package in something like mod_wsgi
[02:36] <ebroder> onehundredthirty: excellent. sounds much better than a bunch of dynamically generated packages
[02:37] <pabelanger> sorry, wrong channel
[02:38] <onehundredthirty> micahg: d/rules looks into d/control and invokes different Python interpreter for different uwsgi-python* packages. and some of these Python interpreters aren't in Build-Depends
[02:38] <micahg> onehundredthirty: python-all-dev doesn't pull them in?
[02:41] <onehundredthirty> micahg: yeah. the same thought comes into my mind now. python-all-dev it really must pull all Python interprestes in. well, maybe my comment on REVU was wrong. but before posting it i tried to build 'control.in' branch on Maverick and it fails on wrong Build-Depends
[02:42] <ebroder> onehundredthirty: you should be able to build-dep on python-all-dev, then use pyversions to figure out what to build against
[02:45] <onehundredthirty> ebroder: yeah, I saw pyversions usage in mod_wsgi package. I'll use it too.
[02:45] <ebroder> onehundredthirty: awesome. sounds like you have things under control
[02:47] <onehundredthirty> ebroder: but there is one disadvantage in packing all pythonX.Y-related executables in package uwsgi-pythonX. Package will contain executables linked to different libpythonX.Y, but the package will Depends only on one libpython
[02:47] <onehundredthirty> ebroder: when user will  try to invoke executable with missing libpython, it wil fails
[02:47] <ebroder> onehundredthirty: that's not true. you should have a ${shlibs:Depends} in your depends: line, and call dh_shlibdeps in your rules file (or if you're using the %: dh $@ rules file, it'll do it for you)
[02:48] <ebroder> dh_shlibdeps finds all of the executables and makes sure the libraries they link are substituted for ${shlibs:Depends}
[02:49] <onehundredthirty> ebroder: but then my package will pull-in ALL python interpreters. say, I 'apt-get uwsgi-python2' and it pulls in python2.6 and python2.7. is it good idea? mod_wsgi didn't so this
[02:49] <ebroder> onehundredthirty: they don't pull in python2.6 and python2.7, just libpython2.6 and libpython2.7
[02:50] <ebroder> and yes, mod_wsgi does do this
[02:50] <ebroder> in fact, it would be a bug in your package if you did *not* depend on the libraries needed to link the executables in the package
[02:50] <onehundredthirty> ebroder: libpythonX.Y Depends on pythonX.Y
[02:50] <ebroder> huh. so they do. hadn't noticed that
[02:51] <ebroder> in any case, yes, that's what mod_wsgi does as well
[02:51] <onehundredthirty> and mod_wsgi Depends on (only python-related): libpython2.6 (>= 2.6), python (>= 2.5), python (<< 2.7)
[02:51] <ebroder> onehundredthirty: you're looking at maverick, not natty
[02:52] <onehundredthirty> ebroder: no I'm looking at Debian Unstable :)
[02:52] <ebroder> onehundredthirty: unstable doesn't even have py2.7 yet, does it?
[02:52] <onehundredthirty> yeah, but nevertheless, mod_wsgi doesn't depends on all libpython
[02:53] <ebroder> it does in natty
[02:53] <onehundredthirty> ebroder: just on libpython for default Python
[02:55] <onehundredthirty> ebroder: I see. it really depends on all available libpython in natty. well,
[02:55] <ebroder> that's odd that it doesn't in sid, though, and seems like a bug
[02:55] <ebroder> or possibly a change in how linking in an interpreter works between py2.5 and py2.6?
[02:56] <ebroder> the mod-wsgi in experimental depends libpython2.6 and libpython2.7 but not libpython2.5
[02:56] <ebroder> i guess that's probably because there is no libpython2.5
[02:58] <onehundredthirty> ebroder: I see. yes there is definitely no libpython2.5, so this is the reason.
[03:00] <onehundredthirty> so, I will try to change my package to something like mod_wsgi with uwsgi-python2 and uwsgi-python3.
[03:01] <micahg>  \o/
[03:01] <micahg> thanks onehundredthirty
[03:01] <onehundredthirty> guess, it takes away need for separate packages for Debian and Ubuntu
[03:01] <onehundredthirty> will see
[03:02] <micahg> onehundredthirty: if you run into issues, please come back, we'll be glad to help
[03:02] <onehundredthirty> micahg: thanks, I'll do
[06:04] <slangasek> who manages revu these days?  I've tried to use it for the first time today, and it seems to think I'm not a MOTU?
[06:04] <slangasek> ah, wiki says contact an admin to be marked as a reviewer
[06:05] <slangasek> persia: can I be a REVUer?
[06:06] <persia> Absolutely.  Please log into REVU to make sure your account is initialised so I can grant you rights.
[06:08] <persia> Basic guidelines: be picky, so save the archive-admins work, be helpful, so folks can get it right.  Everyone appreciates a licensing review.
[06:10] <persia> OK.  All set.  Please review.  Be sure to advocate that which warrants it.  Best to get two pairs of eyes on things: everyone makes mistakes.
[06:11] <persia> Oh, and REVU doesn't run lintian against binaries: if you want those results, run a test-build.
[06:54] <dholbach> good morning
=== almaisan-away is now known as al-maisan
=== hannesw_ is now known as hannesw
=== al-maisan is now known as almaisan-away
=== apachelogger is now known as releaselogger
[13:24] <ari-tczew> mr_pouit: I guess you might be interested in bug 705734
[13:24] <ubottu> Launchpad bug 705734 in xubuntu-docs (Ubuntu) "Xubuntu-docs for lucid are out-dated" [Undecided,New] https://launchpad.net/bugs/705734
=== Quintasan_ is now known as Quintasan
[13:46] <ari-tczew> micahg: ping
=== dholbach_ is now known as dholbach
[14:07] <pabelanger> Daviey: ping?
[14:36] <micahg> ari-tczew: [ong
[14:37] <ari-tczew> micahg: do you running natty?
[14:37] <micahg> ari-tczew: not yet
[14:37] <Daviey> pabelanger, o/
[14:37] <ari-tczew> micahg: :( I have a problem with java on natty and I'd like to get in touch with someone who has a knowledge.
=== almaisan-away is now known as al-maisan
[14:41] <micahg> ari-tczew: have you tried #ubuntu+1?
[14:41] <ari-tczew> micahg: perhaps in the past, but no response
[14:47] <micahg> ari-tczew: do you want to talk about it in there?
[14:47] <micahg> bdrung: ping
[14:47] <ari-tczew> micahg: place doesn't matter, I just would like to fix problem
[14:47] <bdrung> micahg: pong
[14:48] <micahg> bdrung: so, I missed the e-mail about upstream vlc EOLing the 1.0 branch, doesn't this cause an issue for us with Security support for Lucid?
[14:49] <bdrung> micahg: probably no, because backporting the fixes from the 1.1 branch used to be easy.
[14:49] <micahg> bdrung: ok, so we should let this go?
[14:50] <micahg> I guess 1.1 will stay around for a while for squeeze?
[14:50] <bdrung> micahg: upstream will EOLing 1.1 probably before squeeze EOL
=== yofel_ is now known as yofel
[15:19] <dholbach> jdong, is the backporters team still looking for help?
[15:20] <dholbach> ScottK too: ^
[15:20] <ScottK> dholbach: Yes.
[15:21] <dholbach> ScottK, I was reaching out to some new contributors and asked about their experience - there was one who put a lot of work into backporting applications. Would it be OK if I passed him on to the team mailing list?
[15:21] <ScottK> dholbach: We don't have a team mailing list.
[15:21] <dholbach> oh, I thought that was what ubuntu-backports@lists.u.c was for?
[15:22] <ScottK> It may be.  I'm not subscribed to it though.
[15:22] <dholbach> aha
[15:22] <dholbach> ok
[15:22] <ScottK> I'll clarify and say we aren't using a mailing lists.
[15:22] <ScottK> dholbach: You can suggest he give me a ping on irc or email me.
[15:22] <dholbach> sweet, thanks a lot Scott!
[15:36] <Legendario> does anyone know the answer for this error: http://ubuntu.pastebin.com/EJ3dPfKT
[15:41] <tumbleweed> Legendario: you mustn't install to /usr/bin, the package build happens as non-root (fakeroot) and the install should happen into debian/$packagename. You can achieve this via DESTDIR
[15:51] <pabelanger> Daviey: howdy! Figured I'd try and ping you about getting more active with the Asterisk packaging.
=== hanska is now known as dapal
[17:11] <pmjdebruijn> hi I'm trying to package a cmake project with debhelper 7
[17:11] <pmjdebruijn> except that it has no CMakeList in it's package root, but only in one of the subdirectories
[17:11] <pmjdebruijn> how can I point debhelper to that subdirectory
=== al-maisan is now known as almaisan-away
[17:15] <tumbleweed> pmjdebruijn: see --sourcedirectory in debhelper(7)
[17:16] <pmjdebruijn> ok thanks
[17:17] <tumbleweed> you might need --buildsystem too (without the CMakeList it won't autodetect cmake{
[17:20] <pmjdebruijn> but to which db_audo ?
[17:20] <pmjdebruijn> I've only override configure thus far
[17:21] <tumbleweed> to all of them. DH_OPTIONS can make that easier
[17:21] <tumbleweed> well, to all of the dh_auto_*
[17:21]  * Laney thought it was to 'dh'
[17:21] <Laney> dh $@ --buildsystem=blah --sourcedirectory=bleh
[17:22] <jpds> dh, duh.
[17:22] <tumbleweed> Laney: yes, but if he's overridding some of them
[17:22] <Laney> hmm?
[17:22] <tumbleweed> or does it pass it through? I've always passed it to dh and dh_auto_x
[17:22] <Laney> it does
[17:22] <Laney> see man dh
[17:25] <pmjdebruijn> Laney: that seems to work
[17:25] <pmjdebruijn> thanks
[17:26] <Laney> :)
[17:28] <tumbleweed> Laney: aah, it exports DH_INTERNAL_OPTIONS. Nice to know
[17:29] <Laney> I think that using DH_OPTIONS can be problematic in compat 8 mode
[17:29] <pmjdebruijn> tumbleweed: see, now we've both learned something
[17:29]  * pmjdebruijn giggles
[17:30] <tumbleweed> Laney: yes I can see that would be an issue
[17:30] <tumbleweed> pmjdebruijn: that's one of the reasons this is fun :)
[17:32] <bdrung> tumbleweed: hi, do you have time to review release-info?
[17:32] <tumbleweed> bdrung: sure, I'll look in 10 mins
[17:32] <bdrung> tumbleweed: pushed
[17:52] <hakermania> Hello guys
[17:53] <pmjdebruijn> Laney, tumbleweed thank again!
[17:55] <micahg> err, I how do I build a native package from bzr?
[17:59] <tumbleweed> micahg: easiest way is to tell bzr-builddeb that it's native. echo -e '[BUILDDEB]\nnative = True' > .bzr-builddeb/default.conf
[18:01] <micahg> no go
[18:01] <micahg> still trying to run get-orig-source
[18:02] <tumbleweed> micahg: add that file and commit it first
[18:02] <micahg> ah
[18:04] <micahg> tumbleweed: works, thanks
[18:20] <bdrung> tumbleweed: pushed.
[18:20] <bdrung> r962
[18:21] <tumbleweed> bdrung: thanks, just busy reading it
[18:24] <bdrung> tumbleweed: bug #706010
[18:24] <ubottu> Launchpad bug 706010 in ubuntu-dev-tools (Ubuntu) "[backportpackage] upload fails" [Undecided,New] https://launchpad.net/bugs/706010
[18:39] <bdrung> tumbleweed: i'll be away for some hours. cul8r
=== _iron is now known as i_ron
=== releaselogger is now known as apachelogger
[20:35] <c2tarun> besides bug triaging and fixing how else can we contribute to ubuntu development?
[20:39] <Daviey> pabelanger, still around?
[20:41] <tumbleweed> c2tarun: what do you have in mind? there are a lot of bugs to fix... Areas: FTBFSs, important fixes to sync/merge from debian, security issues, upstream develompent of packages, etc.
[20:42] <c2tarun> tumbleweed: actually I was wondering that by learning packaging how can i contribute?
[20:43] <tumbleweed> understanding packaging is important to solving many bugs
[20:43] <tumbleweed> and obviously rather necessary for packaging up new software
[21:01] <c2tarun> tumbleweed: solving bugs often requires good programming skills. I am not familiar with GTK programming, so most of the time I m not able to fix bugs.
[21:05] <tumbleweed> c2tarun: I'm not very familiar with GTK either (haven't written any in years). Most of the bugs I deal with day to day are either packaging issues, build failures, or simple bugs that I can fix without knowing too much about the codebase I'm fixing.
[21:06] <tumbleweed> c2tarun: harvest.ubuntu.com has a good set of things to look at
[21:06] <c2tarun> tumbleweed: Can you please give me example of any packaging issue? I really want to understand how everything works.
[21:12] <tumbleweed> c2tarun: follow the natty-changes list, see what people are doing. In natty we've had some big toolchain changes that make many packages fail to build, the fixes generally involve explicitly linking to libraries.
[21:14] <c2tarun> tumbleweed: sorry to say :( but I didn't understand most of what you said. I think I'll go through various source codes and do the fixing :)
[21:20] <c2tarun> tumbleweed: gotta go. Thanks for you help :)
[21:58] <pabelanger> Daviey: Yup
[23:20] <matttbe> Hello,
[23:20] <matttbe> I'm looking for a sponsoring about this bug: https://bugs.launchpad.net/ubuntu/+source/cairo-dock-plug-ins/+bug/704032
[23:20] <ubottu> Ubuntu bug 704032 in cairo-dock-plug-ins (Ubuntu) "Please update cairo-dock-plug-ins and cairo-dock metapackage to depend on libwebkitgtk-1.0-0" [Undecided,Fix committed]
[23:20] <matttbe> I've proposed my branch for merging into lp:ubuntu/cairo-dock-plug-ins => https://code.launchpad.net/~cairo-dock-team/cairo-dock-plug-ins/ubuntu/+merge/46668
[23:21] <matttbe> And the (short) debdiff is available there: http://launchpadlibrarian.net/62602053/cairo-dock-plug-ins_2.2.0~4-0ubuntu4.debdiff
[23:22] <matttbe> Currently, cairo-dock won't start on Natty. It's due to libwebkit, just need to be recompiled with libwebkitgtk.
[23:22] <matttbe> Anyone can help me? :)
[23:23] <tumbleweed> matttbe: about to go to bed, so can't help you, but don't mark a bug as committed if you want anyone to look at it.
[23:24] <matttbe> tumbleweed: ok thank you
[23:24] <matttbe> tumbleweed: but which status?
[23:25] <tumbleweed> triaged is probably best
[23:25] <happyaron> anyone knows about CMake?
[23:25] <matttbe> tumbleweed: thank you
[23:25] <matttbe> tumbleweed: (except that I can't change this status :) )
[23:25] <matttbe> (to this status)
[23:26] <tumbleweed> matttbe: that merge is massive for just a rebuild
[23:26] <matttbe> tumbleweed: yes, it seems there was a problem with the branch
[23:27] <tumbleweed> ok, I recommend you delete the merge proposal then
[23:27] <matttbe> ok
[23:27] <matttbe> about the bug with the branch https://bugs.launchpad.net/udd/+bug/704694
[23:27] <ubottu> Ubuntu bug 704694 in Ubuntu Distributed Development "import has failed with cairo-dock-plug-ins" [High,Confirmed]
[23:28] <tumbleweed> unfortunatly there are a few of those...
[23:32] <tumbleweed> matttbe: ok, a quick rebuild I can help with
[23:33] <matttbe> tumbleweed: thank you for your help ;)
[23:34] <tumbleweed> matttbe: editing your changelog entry to "Build-Depend on libwebkitgtk-dev instead of libwebkit-dev (LP: #704032)"
[23:35] <matttbe> tumbleweed: thank you :)
[23:36] <matttbe> tumbleweed: just another question: why can't the cairo-dock team change the importance of all bugs from "cairo-dock (Ubuntu)" and "cairo-dock-plug-ins (Ubuntu)" projects?
[23:37] <tumbleweed> matttbe: only ubuntu bugcontrol members can, distribution wide
[23:37] <matttbe> how ok :)
[23:37] <matttbe> -how
[23:40] <tumbleweed> matttbe: https://wiki.ubuntu.com/UbuntuBugControl
[23:43] <pabelanger> So, I'm trying to setup schroot, following: https://help.ubuntu.com/community/SbuildLVMHowto
[23:44] <pabelanger> $ mk-sbuild --vg=storagevg lucid ; fails because I don't have a LVM called storagevg
[23:44] <pabelanger> if I use my local LVM, I get back the following error:
[23:44] <pabelanger>   Insufficient free extents (4) in volume group astpkglucid64: 1280 required
[23:45] <pabelanger> I don't understand what a extents is
[23:45] <ebroder> pabelanger: that means you don't have any unallocated space in the volume group
[23:45] <ebroder> it's all allocated to logical volumes
[23:45] <ebroder> it may be easier to use the aufs support - don't pass --vg, just do "mk-sbuild lucid"
[23:46] <ebroder> it'll create the chroot in /var/lib/schroot/chroots
[23:46] <pabelanger> ebroder: Okay, that looks better
[23:46] <pabelanger> Thanks, let me read up on the differences between LVM and aufs
[23:54] <matttbe> tumbleweed: thank you for your help! ;)