[04:25] <sagaci> i've tried to create an environment using pbuilder-dist unstable create but it spits out errors and aborts, do I need to add any other options to get it to proceed
[04:26] <micahg> sagaci: cna you pastebin the errors?
[04:35] <sagaci_> micahg: http://pastebin.ubuntu.com/549710/
[04:40] <micahg> sagaci_: I think that's bug 599695
[04:43] <sagaci_> ah ok, thanks. Reading through it now
[07:07] <mneptok> street signage in my city - http://farm5.static.flickr.com/4097/4747440725_09fed08e38.jpg
[07:07] <mneptok> that is all.
[11:09] <ripps> It seems that the wingpanel project has started using waf to build the program, but it requires installing a binary into the source directory. I find this a bit untrustworthy, but it seems that waf has only been in Karmic and no other ubuntu release since, what are the reasons for this?
[11:10] <sebner> ripps: IIRC it was considered evil and pretty broken, DktrKranz knows
[11:16] <DktrKranz> ripps: upstream wanted Debian (hence Ubuntu) to drop waf package because users were reporting bugs because of version mismatch (e.g. software was compatible with waf 1.5.0, while we packaged 1.5.11)
[11:17] <ripps> DktrKranz: should I advice the wingpanel devs to not use it? I have trouble trusting a project that requires an unknown binary to build and install
[11:18] <DktrKranz> ripps: while I personally think having a software which is tremendous backward and forward incompatible every version is plain crazy, upstream thinks this is safe because you have to stick with a given binary blob
[11:19] <DktrKranz> ripps: if I were a project, I'd avoid using waf as buildsystem of choice. If they're sure of waf, make them aware they have to include waf binary in every tarball they release
[11:20] <directhex> and bundling means unpackageable
[11:21] <DktrKranz> ripps: waf binary is basically a self-unpacking bzip2 archive, upstream doesn't want distribution to provide it unpacked, we argued a lot about that and we were threatened to be removed an important part of it just for the sake of making our life harder.
[11:21] <Bachstelze> that's insane
[11:21] <DktrKranz> at that point, I didn't want to fork a project just because of that :)
[11:22] <ripps> DktrKranz: Are you a Motu?
[11:22] <DktrKranz> ripps: yes
[11:26] <DktrKranz> ripps: see http://article.gmane.org/gmane.linux.debian.devel.general/149572 for a summary
[11:32] <ripps> should I mark as a security vulnerability?
[12:12] <ripps> I don't know enough about waf to be making any arguments for or against it, so maybe you guys can take a look: https://bugs.launchpad.net/wingpanel/+bug/696756
[12:12] <ripps> He says he uses waf in midori without issue, and that autotools is just as untrustworthy.
[12:16] <askhl_> Hi.  I have a PPA with some translators' tools for ubuntu, originally written by Sebastian Heinlein and others.  Would someone like to help getting this into universe?  This will make it easier for non-expert translators to fix translation errors.  URL: https://launchpad.net/~askhl/+archive/ppa .
[13:04] <DktrKranz> ripps: yeah, it's just running in cyrcles, everyone has something to say about every buildsystem. waf is free software (if you exclude some doc, deliberately non-free to discourage packagers), but the rest of the code is dfsg-free. It's just a matter of being comfortable with a method.
[13:05] <DktrKranz> personally, I don't like it, as you *cant* simply update to new waf in case embedded waf has security issues or other bugs, as you have to redesign buildsystem due to incompatible changes. If upstream is happy with that, fine.
[13:06]  * DktrKranz hugs sebner for having thrown the first stone :)
[13:07] <sebner> hahaha
[13:07]  * sebner hugs DktrKranz back
[15:20] <ari-tczew> ScottK: could you look at backport clementine? bug 694475
[15:23] <ScottK> ari-tczew: You already have ubuntu4 in Natty.
[15:23] <ari-tczew> ScottK: bug title is out of date
[15:24] <ScottK> ari-tczew: Please update it and then ask again.
[15:25] <ScottK> It's important for backports to specify the exact version you want.
[16:01] <c2tarun> I have a question regarding gpg key? where should i ask?
[16:01] <ari-tczew> c2tarun: here on #launchpad
[16:02] <ari-tczew> s/on/or
[16:03] <ari-tczew> ScottK: if I want to backport to lucid, which target should I point - maverick or natty?
[16:04] <ScottK> ari-tczew: Backport to maverick and lucid from natty.
[16:04] <ari-tczew> ScottK: updated bug 694475
[16:40] <aboudreault> hi
[16:40] <aboudreault> is there a way to make the version 1.1 greater than 1.06 ??
[16:41] <aboudreault> initially, the maintainer didn't know 1.0x was treated as 1.x.
[16:42] <micahg> aboudreault: why wouldn't that be greater?
[16:42] <dapal> micahg: (it isn't indeed :))
[16:42] <dapal> aboudreault: you have two options
[16:42] <dapal> a) epoch. But that's forever
[16:42] <dapal> b) use something like 1.06+really1.1, that will vanish as soon as >= 1.7 arrives
[16:43] <aboudreault> I see.
[16:43] <micahg> 1.10 seems to work as well
[16:44]  * micahg is confused still, but dpkg --compare-versions doesn't lie
[16:45] <dapal> micahg: 1.10 is different from 1.1, isn't it?
[16:45] <dapal> those are version numbers, not "math numbers" :)
[16:45] <micahg> dapal: yes, that's what dpkg --compare-versions says
[16:46] <aboudreault> will use something 1.06+SOMETHING1.1
[16:46] <aboudreault> is there something standard I should use, rather than "really" ?
[16:46] <maco> really is the standard
[16:47] <aboudreault> Ok
[16:47] <maco> or at least its what everybody does, so...de facto standard!
[16:47] <dapal> one could always use "omg-damn-you-upstream"
[16:50] <aboudreault> +upstream sounds better
[16:51] <dapal> (I'd vote for +really)
[16:51] <dapal> but, anything really is ok
[16:51] <aboudreault> ok ok. will use +really :P
[16:51] <dapal> even 1.06+1.1
[16:57] <jdstrand> fyi for anyone building natty python packages: https://lists.ubuntu.com/archives/ubuntu-devel/2011-January/032299.html
[17:12] <sebner> jdstrand: is this also a pbuilder issue?
[17:13] <tumbleweed> aboudreault: I use 1.0.6 for upstreams that do that (of course you have to know they do that, first :) )
[17:15] <aboudreault> yeah ^^
[17:18] <jdstrand> sebner: yeah. ari-tczew uses pbuilder and he is the reporter
[17:19] <geser> I checked my natty pbuilder and python2.6-minimal was in state "rc" for me
[17:19] <ari-tczew> I'm checking pbuilder right now
[17:45] <ari-tczew> how can I delete release from pbuilder-dist?
[17:48] <ari-tczew> RainCT, Laney, persia: are you familiar with pbuilder-dist? looking from manpage
[17:51] <RainCT> ari-tczew: Just delete the <release>-base.tgz and <release>_result directory (and the pbuilder-<release> symlink if you created one)
[17:52] <ari-tczew> RainCT: would be nice to create a command 'pbuilder-dist remove' :)
[17:54] <RainCT> Yeah, maybe
[17:54] <RainCT> «pbuilder-dist create <foo>» could also ask if you want a «pbuilder-<foo>» symlink
[17:57] <ari-tczew> RainCT: I have aliases in ~/.bashrc like alias pbuilder-natty='pbuilder-dist natty'
[18:13] <Laney> ari-tczew: a symlink achieves that without the need for an alias
[18:14] <directhex> i use env vars
[18:14] <directhex> 'cos that's what i've always used
[18:15] <directhex> DIST=sid ARCH=armel pbuilder build foobar.dsc
[18:52] <BlackZ> micahg: can you please have a look at bug #695728 ?
[18:58] <micahg> BlackZ: weird, it has a py2.7 library
[18:59] <BlackZ> micahg: the problem can be reproduced with python 2.6 too
[19:00] <micahg> ok, that makes more sense then, probably needs tweaking for xul2.0
[19:01] <BlackZ> micahg: there's a newest version in my PPA. I did some tests with it
[19:01] <micahg> BlackZ: of which?
[19:01] <BlackZ> micahg: pytrainer
[19:02] <micahg> BlackZ: ah, ok, any other gtkmozembed apps having issues?
[19:03] <BlackZ> micahg: hmm, I didn't check but you can try with "miro"
[19:07] <micahg> BlackZ: ok, I probably won't be able to look at it until later this week
[19:08] <BlackZ> micahg: not a problem at all. Thanks! :)
[19:10] <ari-tczew> jdstrand: you're right. everyone should recreate his chroot.
[19:11] <ari-tczew> I've recreated natty chroot and python-django built fine.
[19:17] <aboudreault> it seems that my dh_shlibdeps fails
[19:17] <aboudreault> dpkg-shlibdeps: error: no dependency information found for debian/libgaul/usr/lib/libgaul.so.0 (used by debian/gaul-bin/usr/bin/gaul_diagnostics).
[19:17] <aboudreault> here's how I execute dh_shlibsdeps: dh_shlibdeps -a -L libgaul -l debian/tmp/usr/lib
[19:17] <aboudreault> where am I wrong?
[19:19] <tumbleweed> micahg: it's completely unimportable, so yes they are all probably having issues
[19:20] <micahg> tumbleweed: ok
[20:23] <ari-tczew> ScottK: ping
[20:23] <ScottK> ari-tczew: Pong
[20:26] <maco> can someone please try making a natty pbuilder and tell me if it hangs interminably on    I: Unpacking makedev...
[20:26] <maco> thanks
[20:28] <ari-tczew> ScottK: You wrote on clementine backport bug, that feedbacks should be commented on backport bug. It's pretty bureaucratic and requires me to force that activity on testers. I believe that you can understand that I wouldn't disencourage my testers due to commenting in several places.
[20:28] <maco> (I'm doing this from lucid--just added a symlink to make natty available for pbuilder-dist, but i dont think host system should matter...)
[20:29] <tumbleweed> maco: works for me (on squeeze)
[20:30] <ScottK> ari-tczew: If you had just said in that bug that it runs on maverick (with a reference to the other bugs) that would have been fine.  I don't have time to hunt through multiple bugs to find out if it's been tested.  I think being unwilling to at least mention in the bug report that it's been properly tested is not respectful of the time I invest in reviewing backports requests.
[20:31] <ari-tczew> ScottK: Does the way which I did was OK? Paste links to feedbacks?
[20:31] <ScottK> ari-tczew: Yes.
[20:32] <ScottK> Somehow the bug needs to say that the packages builds, installs, and runs in the target environment.
[20:32] <ari-tczew> ScottK: Then it's fine. I thought that I was clear on bug. In future I'll link comments.
[20:34] <BlackZ> maco: works fine here, too
[20:35] <maco> hrmm thanks
[20:35] <maco> BlackZ: are you on lucid?
[20:35] <BlackZ> maco: yes
[20:35] <maco> maybe the lucidyness *does* matter...
[20:35] <maco> oh
[20:35] <maco> hrmph
[20:35] <maco> oh!
[20:35] <BlackZ> maco: works fine on maverick too
[20:35] <maco> well i just learned something new about screen...
[20:36] <maco> when you use ctrl+A,Esc to get into "i can scroll now" mode, it stops having any output below where you entered that mode so things LOOK hung til you ctrl+c
[20:36] <BlackZ> maco: right :P
[21:13] <SpamapS> micahg: Reading through the gnome shell bugs and I see you're working on it. Is there any way to install gnome shell in natty?
[21:13] <SpamapS> I have the PPA added but I can't install it
[21:14] <micahg> SpamapS: ATM, not really, I would like to have a build working from the GNOME3 PPA soon, but my list of urgent things is growing
[21:14] <SpamapS> blast
[21:15] <SpamapS> If Unity would just work w/ nvidia + multi-monitor I'd use that.. but..
[21:16] <micahg> SpamapS: isn't the classic desktop available
[21:16] <micahg> ?
[21:17] <SpamapS> Probably
[21:17] <SpamapS> but I've never been very happy with that either