[01:04] <psusi> so if a program uses egg_debug()... how do you enable those prints?
[02:37] <qnix> hi ppl
[02:37] <qnix> question, how do you version a beta release?
[02:37] <qnix> 6.0.0-1~beta1 ?
[02:40] <micahg> qnix: no, the beta should be part of the upstream version 6.0.0~beta1-1 (for Debian)
[02:40] <qnix> my tar.gz is named soft-6.0.0-beta1.tar.gz
[02:42] <qnix> kk, but I have to rename the tar.gz, right? since the name contains a - ?
[02:43] <micahg> qnix: right
[02:44] <qnix> can it contain a ~?
[02:45] <micahg> qnix: yep, here's an example: https://launchpad.net/ubuntu/+source/firefox/4.0~b12+build1+nobinonly-0ubuntu1
[02:45] <qnix> micahg: thank you.
[04:08] <onehundredthirty> hi. could anyone please review uwsgi package (it's a WSGI server)? http://revu.ubuntuwire.com/p/uwsgi
[04:28] <c2tarun> how can I find the tracker for any problem? like a tracker for new version available, or a tracker for ftbfs or any other?
[04:29] <lifeless> c2tarun: what do you mean?
[04:32] <c2tarun> I mean there are certain trackers like, http://udd.debian.org/cgi-bin/ubuntu_ftbfs.cgi  and http://people.canonical.com/~ubuntu-security/cve/universe how many other are there?
[04:32] <c2tarun> lifeless: ^^
[04:33] <lifeless> how big is the internet
[04:33] <c2tarun> lifeless: enormous ;)
[04:34] <lifeless> exactly
[04:35] <c2tarun> lifeless: hmmm.... so there is no place where I can get the link of such trackers?
[04:35] <lifeless> google ?
[04:35] <lifeless> I don't really know what you mean
[04:35] <c2tarun> lifeless: nevermind :)
[04:36] <lifeless> I don't think there is a big list of reports for ubuntu or debian
[04:37]  * c2tarun there should be one, this makes work a lot easier
[04:38] <micahg> c2tarun: this might be the closest thing we have http://qa.ubuntuwire.org/
[04:39] <c2tarun> micahg: this is good :) thanks
[04:39] <micahg> c2tarun: here's another: http://harvest.ubuntu.com/
[06:37] <wejaeger> Hey, anyone up for reviewing l2tp-ipsec-vpn? It's a little applet to configure and manage L2TP IPsec VPN connections. I've just uploaded a new candidate to fix all problems about which micahg and mok0 complained. http://revu.ubuntuwire.com/p/l2tp-ipsec-vpn
[06:39] <micahg> wejaeger: there's no need to post that whole message every time, you ca\n just ask if someone can review the package
[07:43] <c2tarun> there is package in natty archive named darksnow, this package include few log files and a patch inside the patch folder, but no series of 00list file, what are these log files for?
[07:48] <dholbach> good morning
[07:50] <elricL> Hello
[07:52] <c2tarun> there is package in natty archive named darksnow, this package include few log files and a patch inside the patch folder, but no series of 00list file, what are these log files for?
[08:03] <geser> c2tarun: darksnow uses the "simple-patchsys" from cdbs which simply applies all patches it finds in debian/patches in alphabetical order (it doesn't need a 00list or series file)
[08:04] <c2tarun> geser: is there any manual or walkthrough for this patch system>
[08:06] <geser> c2tarun: https://wiki.ubuntu.com/PackagingGuide/PatchSystems
[08:07] <geser> c2tarun: and what log files? I don't see any in the webview of the packaging branch on LP
[08:08] <c2tarun> geser: these are the files in patches folder gcc -g -O2 -g -O2 -DUSE_TOOLTIP -pthread -lgtk-x11-2.0 -lgdk-x11-2.0 -latk-1.0 -lgio-2.0 -lpangoft2-1.0 -lpangocairo-1.0 -lgdk_pixbuf-2.0 -lm -lcairo -lpango-1.0 -lfreetype -lfontconfig -lgobject-2.0 -lgmodule-2.0 -lgthread-2.0 -lrt -lglib-2.0   -pthread -I/usr/include/gtk-2.0 -I/usr/lib/gtk-2.0/include -I/usr/include/atk-1.0 -I/usr/include/cairo -I/usr/include/gdk-pixbuf-2.0 -I/usr/include/pango-1.0 -I/usr/
[08:08] <c2tarun> include/gio-unix-2.0/ -I/usr/include/glib-2.0 -I/usr/lib/glib-2.0/include -I/usr/include/pixman-1 -I/usr/include/freetype2 -I/usr/include/libpng12 -I/usr/include/libdrm   -DVERSION="\"0.6.1\"" darksnow.o interface.o config_files.o tooltips.o -o darksnow
[08:08] <c2tarun> oopps sorry
[08:08] <c2tarun> geser: http://paste.ubuntu.com/578222/
[08:11] <c2tarun> geser: what is a webview? where can i see a webview?
[08:11] <geser> c2tarun: sorry don't know, but my guess is that they come from the simple-patchsys
[08:11] <c2tarun> geser: ok, may be. thanks :)
[08:12] <geser> c2tarun: e.g. http://bazaar.launchpad.net/~ubuntu-branches/ubuntu/natty/darksnow/natty/files
[08:12] <geser> you get there by following the "Code" tab on LP for a source package
[08:12] <c2tarun> geser: got it, strange there is nothing about these log files there.
[12:13] <dholbach> directhex, do you think somebody can commit the debian/control portion of https://code.launchpad.net/~bhaveekdesai-gmail/ubuntu/maverick/boo/bug-729855/+merge/52735 in Debian? O:-)
[12:16] <directhex> dholbach, at some point. doesn't seem a high-urgency item for a whole release, but it can go into packaging git
[12:16] <dholbach> directhex, awesome
[12:16]  * dholbach hugs directhex
[12:27] <acarpine> morning omniscent people! :)
[12:27] <acarpine> fixing bug and using bzr, I don't understand when to use bzr branch lp:<pkgname> and when to use bzr branch lp:ubuntu/<pkgname>
[12:28] <acarpine> Is there any general rule that I can use?
[12:30] <directhex> dholbach, boo's still in svn, which is scarily retro, committed anyway. at some point Laney will volunteer to do a new upstream update && move to git, which can result in new packages
[12:30] <dholbach> directhex, excellent!
[12:31] <geser> lp:<pkgname> is the upstream branch of a programm, lp:ubuntu/<pkgname> is the auto-imported packaging branch of it (assuming a package exists for it) based on the uploads to the archive
[12:31] <Ampelbein> acarpine: always use lp:ubuntu/pkgname (or ubuntu:pkgname), if you use lp:pkgname you get the PROJECT not the ubuntu package
[12:33] <acarpine> ampelbein: But I thought sometimes can be useful makes change the upstream project...
[12:34] <acarpine> ampelbein: I thought it depends on what i'm changing...
[12:36] <Ampelbein> acarpine: generally, if you want to change something for ubuntu, you use lp:ubuntu/pkg or ubuntu:pkg as branch. you only branch the project if upstream actually uses launchpad for code development (most don't).
[12:38] <acarpine> ampelbein: ok, so when a project use launchpad for code development I imagine is write in the launchpad page...correct?
[12:39] <Ampelbein> acarpine: yes, it should be on the launchpad project page
[12:42] <acarpine> Ampelbein: Really tks, I will use your rule of thumb!
[14:06]  * Laney eyes directhex 
[14:06] <directhex> ?
[14:07] <Laney> boo! it's a terrifying beast
[14:08] <directhex> not too tricksy
[14:09] <Laney> does it want updating?
[14:10] <ari-tczew> hello
[16:52] <kmdm> Hi guys, was hoping for some advice... I've made a package that uses cdbs to install a python module & associated daemon script... however when it tries to start the daemon from postinst the python-central triggers haven't run so the module fails to import into python, the daemon fails to start and thus the package install fails... Is there a standard workaround for this? - thanks :)
[16:58] <tumbleweed> kmdm: yeah, manually do the necessary byte-compilation in postinst rather than waiting for the trigger. Also python-central is deprecated, use dh_python2
[17:08] <kmdm> tumbleweed: hm, thanks :) I'm only using whatever CDBS gives me so I'm assuming that'll be dh_python2 once that gets updated?
[17:16] <geser> kmdm: any reason using cdbs and not debhelper?
[17:21] <kmdm> geser: laziness? ;)
[17:41] <ari-tczew> cjwatson: merge-o-matic is working already, but I see no changes to lp:merge-o-matic. could you tell the secret how did you do it?
[17:57] <debfx> kklimonda: these qt buttons look quite native gtk to me: http://labs.qt.nokia.com/wp-content/uploads/2011/03/Screenshot-6.png
[20:07] <RoAkSoAx> zul: never mind found the error ;)
[20:28] <blueyed> What do you think about including a recent SVN snapshot for (exuberant-)ctags for natty? There are a lot of bugfixes, and no new release in sight.. (I have pinged the author about this a few days ago without any reply)
[20:28] <blueyed> I have prepared one based on the debian version in my ppa.
[20:51] <micahg> blueyed: if the snapshot is stable, why not?
[20:51] <micahg> blueyed: you're still need an FFe if there are new features
[20:52] <micahg> *you'll
[20:52] <blueyed> I have not checked the changelog in detail, just ran across bugs in the latest release several times in the last days.
[20:52] <blueyed> I have prepared a branch now, and will upload/ask-for-ffe it.
[20:53] <blueyed> given how essential ctags is, we should really push this.
[20:53] <micahg> blueyed: if the snapshot isn't stable, maybe backport some of the bugfixes
[20:53] <blueyed> ok
[20:58] <blueyed> I really hate FFe paperwork.. even when doing this for free, I would pay somebody 10€ to do it for me.. :/
[21:09] <ari-tczew> blueyed: write your views about bureaucracy to dholbach :)
[21:12] <blueyed> ari-tczew: do you think he would do it for 10€?
[21:12] <ari-tczew> blueyed: dunno, he might be an expensive employee :)
[21:22] <blueyed> great. it fails to build, but without any error apart from the binary not being existent: http://launchpadlibrarian.net/66079994/exuberant-ctags_5.9%7Esvn20110310-0ubuntu1-i386-20110310-2211 - hints? I'm off for some time, but will come back later.
[21:23] <ari-tczew> install: cannot stat `ctags': No such file or directory
[21:24] <ari-tczew> IMO dirs or d/rules needs fixing.
[21:43] <ari-tczew> ScottK: ping
[21:44] <blueyed> ari-tczew: well. it seems like the binary "ctags" does not get build and then cannot get installed.
[21:47] <blueyed> looks like the whole configure script is missing in the svn snapshot.
[21:48] <Ampelbein> blueyed: yes, but there should be a autogen.sh file to work the necessary automake/conf/libtool/aclocal-black-magic for you
[21:50] <blueyed> Ampelbein: no, there is none. I have taken the tar ball from http://ctags.svn.sourceforge.net/viewvc/ctags/trunk/ (link at the bottom)
[21:56] <arand> Are wildcards availble in package.install files? Can I do excludes?
[21:57] <Ampelbein> blueyed: autotools-dev has an example autogen that should work fine. it just runs the other tools in order
[21:57] <ScottK> ari-tczew: Pong
[22:01] <blueyed> Ampelbein: shouldn't there something in the SVN source itself?
[22:01] <Ampelbein> blueyed: that would be considered nice to have, but isn't strictly needed I guess.
[22:02] <blueyed> Ampelbein: I do not have much experience in autotools land. Will look around. thanks.
[22:06] <blueyed> Ampelbein: How would I integrate this into the build process?
[22:06] <blueyed> or should I maybe just pick configure and other missing files from the last releasE?
[22:08] <Ampelbein> blueyed: the easiest way would be to run the autogen, make distclean, and repack that as orig.tar.gz
[22:24] <blueyed> Ampelbein: not so easy apparently. I am getting some help in #geany now - in case you want to join us.. ツ
[22:25] <Ampelbein> let me get that tarball and have a look ;-)
[22:30] <Ampelbein> blueyed: do you have your packaging somewhere?
[22:32] <blueyed> Ampelbein: lp:~blueyed/ubuntu/natty/exuberant-ctags/upstream-snapshot - b4n in #geany could successfully build it now however.
[22:33] <Ampelbein> blueyed: yeah, me too. I just wanted to get the packaging to see how well it integrates
[22:33] <Ampelbein> switching to geany
[23:24] <blueyed> in case anyone wants too look/vote for the ctags upstream freeze exception: see bug 732860