[00:30] <idnar> http://blog.launchpad.net/ppa/failed-to-fetch-errors-for-ppas contains what is, as far as I can determine, a really confusing typo
[00:31] <idnar> it looks like "All of these refer to different components within the same PPA. You only need the first four PPAs" should read "for" instead of "four"
[00:31] <wgrant> idnar: Hah, indeed. Fixing.
[00:33] <wgrant> Fixed.
[00:34] <wgrant> idnar: I thought it was right when I reviewed it.
[00:34] <wgrant> Someone actually corrected it to 'four' afterwards...
[00:34] <idnar> heh
[00:37] <lifeless> I would say 'PPAs only need the first component'
[00:37] <lifeless> and avoid the ambiguity
[00:38] <wgrant> Only need, or only have?
[00:42] <lifeless> have would be better
[00:42] <lifeless> I was rephrasing the existing sentence
[00:43] <wgrant> Right, was just proposing further alterations.
[00:43] <wgrant> Is done.
[01:22] <kalikiana> Is there a way to mark all Committed bugs as Released?
[01:31] <wgrant> kalikiana: There's no way to do it directly in Launchpad, but you can do it easily through the API, and there are several existing launchpadlib scripts that do that.
[01:34] <wgrant> lp:~mgiuca/+junk/launchpad-tools is one I've used.
[01:34] <wgrant> But there are many around that are slightly different. Some close all Fix Committed bugs in a milestone, others all in a project, some add comments, some don't...
[01:39] <kalikiana> wgrant: that looks perfectly like what I need, thanks a lot. I have only used the UI so far
[02:00] <lostogre> who here was working on bind 9.8.0rc1?
[02:20] <kalikiana> wgrant: I can't seem to use the script, it eats all my memory + swap and I need to kill it before it does anything :-(
[02:20] <kalikiana> Would you have any idea why that happens?
[02:22] <wgrant> kalikiana: What's the traceback if you kill it while it is eating?
[02:24] <kalikiana> it seems to be in File "/usr/lib/python2.7/site-packages/launchpadlib/credentials.py", line 242, in __call__
[02:24] <kalikiana> webbrowser.open(self.authorization_url)
[02:24] <kalikiana> it doesn't really make sense that opening a browser would need much memory
[02:26] <wgrant> One would think not...
[02:26] <kalikiana> wgrant: would you happen to know what url I need to open?
[02:27] <wgrant> It varies, because it contains the token URL.
[02:27] <kalikiana> hmm
[02:27] <wgrant> What happens if you strace it?
[02:28] <kalikiana> oh, very good idea, it seems to choke on xdg-open
[02:28] <wgrant> I've never seen that before. Does xdg-open work if you invoke it manually?
[02:34] <kalikiana> looks like it loops. and changing $BROWSER to not be xdg-open fixes it. which is odd because I didn't touch that variables in months
[02:35] <kalikiana> but not an lp issue in any case then
[02:40] <kalikiana> wgrant: works now, thanks again
[08:11] <micahg> uh, I just had a bugzilla.gnome status just go to unknown
[08:29] <lifeless> bug ?
[08:30] <micahg> bug 657227
[08:34] <lifeless> its marked resolved duplicate in the bug watch portlet
[08:36] <lifeless> and the duplication was just now
[08:36] <micahg> lifeless: ok, but still, should it go to unknown
[08:37] <micahg> should I set the new upstream or do you need this for testing?
[08:37] <lifeless> micahg: https://bugzilla.gnome.org/show_bug.cgi?id=636868
[08:37] <lifeless> unconfirmed
[08:37] <micahg> ok, but unconfirmed = New
[08:37] <lifeless> micahg: I don't know quite what the expected behaviour is here
[08:37] <lifeless> I would file a question about this and leave it be
[08:37] <lifeless> we should be able to do better
[08:37] <micahg> question as opposed to bug
[08:38] <lifeless> yes
[08:38] <lifeless> bugs are for defects
[08:38] <lifeless> questions are for, well, questions
[08:38] <lifeless> 'whats meant to happen' is not a bug :)
[08:40] <micahg> https://answers.launchpad.net/launchpad/+question/146088
[10:41] <slangasek> is there a way someone here could kill https://launchpad.net/~vorlon/+archive/multiarch/+buildjob/2274512 for me?
[10:42] <slangasek> it wasn't meant to try to build in that ppa, it was supposed to get binaries copied from a different ppa but I was too hasty and tried to copy before the binaries were fully published
[10:44] <wgrant> slangasek: Hm, it shouldn't have let you copy if there were unpublished builds...
[10:44] <slangasek> oops ;)
[10:46] <wgrant> Unfortunately we can't sensibly kill a building build without poking the builder directly.
[10:46] <wgrant> And even if I was to do that, it's possible the aborted build would block you from copying the i386 binaries in later.
[10:48] <slangasek> wgrant: well, I'm already routing around the need to copy by playing towers of hanoi with another ppa, but y'all might want that builder back sooner than 9 hours from now
[10:49] <wgrant> Heh. Let me try to kill it...
[10:50] <wgrant> Ah, actually, I can't.
[10:50] <wgrant> I can do it for recipe builds, but not binary builds yet.
[10:50] <slangasek> ok :/
[16:21] <lvh> Hello!
[16:21] <lvh> Is it possible to rename a project, or do I ask for it to be removed and create a new one?
[16:21] <lvh> Removal might actually be better: it's a replacement of a dead project.
[16:49] <micahg> lvh: file a question on answers.launchpad.net/launchpad
[16:58] <maxb> lvh: Renaming is possible, if it makes sense to do so
[17:03] <JoshBrown> How do I remove tags from a Bazaar branch on Launchpad?
[17:05] <maxb> JoshBrown: 'bzr tag --delete -d lp:.... tagname'
[17:06] <maxb> However... any merging of pushing from another branch which still has the tag will re-add it
[17:06] <maxb> s/of/or/
[17:08] <JoshBrown> maxb: Thanks, that's exactly what I'm looking for!
[17:27] <lvh> micahg: Thanks, I just did.
[17:48] <JoshBrown> When you create an original deb package on Launchpad, what should it be called? Am I correct in thinking it should be something along the lines of `name_1.0-0ubuntu1~ppa1_all.deb`?
[17:50] <micahg> JoshBrown: launchpad only accepts source uploads
[17:51] <JoshBrown> micahg: Okay, but nonetheless, what should the package be designated as? Do I include ubuntu1, ~ppa1, etc?
[17:54] <micahg> JoshBrown: I usually do ~series~ppa1 where series is the release targeted, if this is the first upload of that version, you can use UPSTREAMVERSION-0ubuntu1~series~ppa1
[17:58] <JoshBrown> micahg: I was mainly wondering whether it was `0ubuntu1` or just `0`. Thanks, that answers my question!
[17:59] <micahg> JoshBrown: technically either would be fine since 0 is lower than 0ubuntu1
[18:56] <maxb> JoshBrown: People exercise varying degrees of care about version numbers in PPAs, and there are several different schools of thought
[18:57] <maxb> For example, I think micahg's example is inverted, in the sense that series is usually the least significant part of your packaging efforts, so goes at the end.
[18:57] <micahg> maxb: the problem with that is you override official backports
[18:58] <maxb> Also, I'll explicitly avoid including 0ubuntu1 in versions unless I'm actually deriving a PPA package from an official ubuntu package version including that
[18:59] <maxb> hmm. I cynically care little about that on the basis that official backports seldom seem to actually happen :-/
[19:00] <JoshBrown> maxb: So you'd package as `name_1.0-0~ppa1~maverick`, for example?
[19:01] <maxb> I usually go with ~maverick1, and increment that number if I need to make a series-specific build fix
[19:02] <JoshBrown> maxb: Great, thanks!
[19:02] <maxb> Also, I tend to call things 0ppa1 rather than 0~ppa1
[19:03] <maxb> Mainly because I believe in using the magical ~ operator only when relevant, rather than as an arbitrary separator
[19:04] <maxb> Though I admit that I'm relying on the happenstance that 'ppa' < 'ubuntu' in doing so
[19:09] <micahg> maxb: actually, now with the extras repo, that isn't necessarily a good idea as it's 0series1 for the versioninig