=== bjf is now known as bjf[afk]
[00:21] <bdrung> i have some issue with the daily build: Unable to load plugin 'builder' from '/usr/lib/python2.6/dist-packages/bzrlib/plugins' https://launchpadlibrarian.net/59824676/buildlog.txt.gz
[00:28] <wgrant> soren: We've just fixed that build. But it failed to upload because a newer one finished already.
[00:28] <wgrant> soren: So everything looks OK now.
[00:29] <wallyworld> bdrung: looking now
[00:45] <wallyworld> bdrung: it appears there's a config problem on Canonical's end, which is being looked at. I'll ping you when I have some more information
[00:56] <bdrung> wallyworld: thanks
[00:58] <wallyworld> bdrung: np. the person i am waiting for input on may not be able to respond straight away. want me to email you any status update?
[01:34] <wallyworld> bdrung: you still there? do you have a link to the actual build in addition to the log you posted?
[01:48] <wallyworld> bdrung: seems like an issue with just the one server. you could try building again and it should work, fingers crossed
[02:22] <thumper> wallyworld: it could be 10 builders... it seems that several new builders were added
[02:22] <thumper> wallyworld: we should check with bigjools later
[02:38] <wallyworld> thumper: ok, i'll send him an email. i've already mailed james_w and lamont
[02:58] <lamont> wallyworld: thanks for the email, fixing that machine now :(
[02:58] <lamont> there may still be a machine or two, I'd love to hear about any similar ones
[02:59] <wallyworld> lamont: np. thanks for looking at it so promptly :-) would it be wise to check the other newly added machines too?
[02:59] <lamont> it's actually the ones that were new sometime (specific) last week. :(
[03:00] <lamont> and checking them is problematic
[03:00] <wallyworld> lamont: i only know about that one case so far - i'll be sure to tell you if any more come by way :-)
[03:00] <lamont> or at least annoyiung
[03:00] <wallyworld> s/by/my
[03:00] <lamont> should be a quantity approximating zero.
[03:00] <wallyworld> here's hoping :-)
[03:02] <lamont> wallyworld: and the build url is much more helpful to me than the buildlog, should a similar occasion arise.. (I can get from the url -> log, but not the other way without pain)
[03:03] <wallyworld> lamont: np. i think i included the url in the email? i only got the log from the user who reported the problem but got help from aaron to get the url
[03:05] <lamont> you did included it (and you clearly understand the pain I feel when they give me just the log)
[03:05] <wallyworld> well, aaron does, and i'm starting to :-)
[03:06] <lamont> to be fair, I've thus far gotten away with "give me a url if you want me to check on that, kthx"
[03:06] <wgrant> lamont: Are they not running the latest lp-buildd?
[03:06] <lamont> wgrant: there were a few, it seems, that got missed
[03:07] <wgrant> lamont: It seems like buildd-manager should disable them.
[03:07] <lamont> on the bright side, I can now actually log in and check these things
[03:07] <lamont> build-manager can't even query them to find out what version they're running
[03:07] <wgrant> Well, it *should* be able to.
[03:08] <wgrant> And then we have FFs or something specifying the allowable versions.
[03:08] <wgrant> And anything else gets disabled.
[03:08] <lamont> +99
[05:51] <matthewg42> Hi.  I have a local bzr repository with a bound copy of the trunk of my project (lp:stellarium).  It's quite a big project and my pipe is not so fat.  I branched a local feature branch, which i wish to upload to launchpad.  How can I do this efficiently?  I did this before, but it uploaded the whole thing and took forever.  Is there a way I can branch from lp:stellarium on the lp servers without havin to upload every
[05:54] <matthewg42> If figure if I can do the main branch on the lp servers directly (and fast), I can then merge in my local branch to that to sync them up.  This means I don't have to download or upload the whole repo...  Is this a sane expectation?
[05:59] <exarkun> I don't understand https://edge.launchpad.net/twisted/main/+addrelease
[05:59] <exarkun> Can I skip the milestone part?
[06:02] <wgrant> exarkun: A release is a special case of a milestone. So you need to select an existing milestone or create a new one.
[06:03] <lifeless> exarkun: you can automate it
[06:03] <lifeless> exarkun: but not skip it
[06:03] <lifeless> exarkun: there are a few scripts around already that automate it
[06:04] <exarkun> maybe someday I'll want to use one of those
[06:04] <exarkun> right now, it only takes about 2 clicks to create a milestone, so I'm not extremely concerned with the manual labor
[06:04] <matthewg42> maybe my question is better suited to #bzr eh?
[06:05] <exarkun> it's mostly a problem because I have no idea what a milestone is, or what any of its attributes might be
[06:05] <wgrant> matthewg42: Which version of bzr are you using?
[06:05] <matthewg42> 2.2.1
[06:05] <wgrant> matthewg42: Where'd you push the branch to?
[06:06] <matthewg42> I didn't push anywhere yet.  My question is essentially...  push takes too long because it sends then entire local repository branch over the network, when 99% of the data already exists in the trunk branch in lp.
[06:06] <wgrant> matthewg42: Branches should automatically stack on lp:stellarium -- that is, they will only upload new data.
[06:06] <matthewg42> I /will/ push to lp:~matthew-porpoisehead/stellarium/nightmode
[06:06] <wgrant> Your '
[06:07] <wgrant> Your 'satellites' branch stacked.
[06:07] <matthewg42> hmm.  didn't last time
[06:07] <wgrant> Your 'deltat' branch did not.
[06:07] <wgrant> Not sure why.
[06:07] <matthewg42> yeah, I created satellites before I started using a local repo
[06:07] <wgrant> You should see a message about stacking when you push up your next one.
[06:07] <matthewg42> so originally my local satellites was a full checkout of lp:stellarium
[06:08] <wgrant> matthewg42: So, just push it up. It should work.
[06:09] <matthewg42> since then I did bzr init-repo, checked out lp:stellarium into a branch called "trunk" locally, and made deltat as a local branch of that.  then when I pushed deltat, lp didn't figure out that it was a branch of lp:stellarium
[06:10] <wgrant> You didn't terminate the first push then push again?
[06:10] <wgrant> Or create the branch through the UI first?
[06:10] <matthewg42> what do you mean "create the branch through the UI first"?
[06:10] <matthewg42> via the web site?
[06:10] <wgrant> Sorry, the web UI, yes.
[06:10] <matthewg42> I was working from the bzr docs which talk about doing stuff on the lp site.
[06:10] <matthewg42> how do I do that?
[06:10] <wgrant> There is a (pointless) link there to create a branch.
[06:10] <wgrant> You don't want to use it.
[06:11] <wgrant> Just wondering if you did last time.
[06:11] <matthewg42> sorry... new to distributed vcs!
[06:11] <matthewg42> I don't think I used the GUI
[06:11] <wgrant> So, try pushing to lp:~matthew-porpoisehead/stellarium/nightmode. It should tell you at the start that it's stacking on lp:stellarium or similar.
[06:12] <matthewg42> k
[06:12] <wgrant> If not, we will debug.
[06:13] <matthewg42> "Using default stacking branch /~stellarium/stellarium/trunk at lp-67423056:///~matthew-porpoisehead/stellarium"
[06:13] <matthewg42> looks like it's working.  :D
[06:13] <wgrant> Yep.
[06:13] <wgrant> Stacked on:
[06:13] <wgrant> lp:stellarium
[06:13] <matthewg42> thanks.  don't know what I did the delta-t branch!
[06:13] <wgrant> Success.
[06:13] <matthewg42> must have done something differently.
[06:15] <matthewg42> I have no clue what.  OK, well that makes me feel a lot better about making feature branches in this way now.
[06:15] <matthewg42> Well thank you for your help.
[06:15] <wgrant> matthewg42: If you work out what you did different with the other one, I'd be interested to know.
[06:16] <matthewg42> me too
[06:17] <matthewg42> and I'd like to fix it if possible.  I assume the deltat branch is taking up a lot of unnecessary disk space on lp's servers
[06:18] <matthewg42> wgrant: I see a difference when I do bzr info...
[06:18] <matthewg42> deltat has one additional line of output: submit branch: /media/loop/stellarium/trunk
[06:18] <matthewg42> hang on, I'll pastebin the whole thing for you
[06:19] <matthewg42> wgrant: http://pastebin.ca/2006542
[06:19] <matthewg42> what sets this submit branch?
[06:19] <wgrant> That's probably unimportant. It was something different about the way you pushed.
[06:19] <matthewg42> oh
[06:20] <matthewg42> the command I pushed with just now (successfully) is: bzr push lp:~matthew-porpoisehead/stellarium/night
[06:20] <wgrant> Right.
[06:20] <matthewg42> Perhaps...  I had uncommitted changes in my local trunk when I pushed deltat... would that do it?
[06:22] <matthewg42> I don't generally have uncommitted changes in my local trunk, but it is possible.
[06:23] <wgrant> I doubt it. The most common cause is that you start a push, terminate it before it finishes, then repush.
[06:24] <matthewg42> That is also possible.  I'm control-C happy.
[06:24] <matthewg42> Is there anything I can check to see what I might have done?
[06:25] <wgrant> ~/.bzr.log should have timestamps for each command.
[06:25] <matthewg42> aha
[06:27] <matthewg42> I think you're right:  bzr arguments: [u'push', u'--remember', u'lp:~matthew-porpoisehead/stellarium/deltat'] .... KeyboardInterrupt
[06:27] <matthewg42> It appears I remembered that I should check to see if there were any changes to merge from lp:stellarium because the next thing I did was:
[06:28] <wgrant> There's apparently a bug for that. But I can't find it.
[06:28] <matthewg42> bzr arguments: [u'commit', u'-m', u'merge from trunk']
[06:28] <matthewg42> then I pushed again
[06:28] <wgrant> Hah.
[06:28] <wgrant> Yeah, so you should try to avoid Ctrl+C'ing the initial push.
[06:28] <matthewg42> OK, noted.
[06:29] <matthewg42> I don't want to clog up lp's servers with full branches
[06:29] <matthewg42> if I remove the branch on lp now, and push again my deltat will it create a stakced branch ok?
[06:30] <wgrant> Yup.
[06:30] <matthewg42> (I just want to check that removing the branch on lp actually removes it and clears state, and doesn't do some "clever" stuff just making it as removed until I try to push again)
[06:30] <matthewg42> OK, I'll do that.
[06:30] <wgrant> You'll probably have to reasociate the blueprint, but apart from that it'll work fine.
[06:30] <matthewg42> wgrant: thank you for your help.  most useful.
[07:01] <matthewg42> Are there plans to implemented a "feature request" system?  I find the wishlist bug status to be unsatisfying.
[07:04] <lifeless> matthewg42: not that I'm aware of
[07:04] <fta2> hi. is there a problem with the ppa publishing task?
[07:05] <fta2> https://launchpad.net/~chromium-daily/+archive/ppa/+sourcepub/1379136/+listing-archive-extra  says "i386 - Pending publication", but https://launchpad.net/~chromium-daily/+archive/ppa/+build/2070063 says it "Finished 1 hour ago"
[07:06] <fta2> isn't it supposed to be 15min?
[07:21] <wallyworld> fta2: not sure, i'll have a look
[07:22] <fta2> wallyworld, thanks
[07:25] <wallyworld> wgrant: ^^^^^^ any ideas?
[07:33] <wallyworld> fta2: i am trying to find a packaging person to help with your issue; i'll email or irc once we know something
[07:52] <wgrant> fta2: It's meant to be every 5 minutes, but it was down to every 20 earlier this morning. I'm not sure what's happening now.
[08:06] <soren> wgrant: Yes, it eventually failed because a newer one landed before it. It still took hours for it to upload.
[08:07] <wgrant> soren: It was hit by a race condition which knocked it out of the incoming queue. We manually moved it back in, and a minute later it was processed (and rejected) as expected.
[08:07] <wgrant> We believe that the race is fixed, but the fix is not yet deployed.
[08:09] <soren> wgrant: Ah, ok. Cool, thanks.
[08:15] <wallyworld> wgrant: with the above issue, the amd64 build got published fine, it's just the i386 build that's busted
[08:16] <wgrant> wallyworld: The i386 build finished half an hour later.
[08:17] <wallyworld> wgrant: yes, but it's *still* pending publication all this time later?
[08:17] <wgrant> Right, something must have broken in that half-hour interval.
[08:19] <wallyworld> wgrant: i've been called for dinner. is there something that needs to be poked to fix it?
[08:20] <wgrant> wallyworld: Julian should be around soonish, so you can probably eat.
[08:20] <wallyworld> wgrant: thanks :-) i'll ping him after dinner
[08:46] <wgrant> fta2: Should all be good now.
[09:10] <wallyworld_> wgrant: you fix something?
[09:11] <wgrant> wallyworld_: No -- see #launchpad-dev.
[09:12] <wallyworld_> wgrant: ok. thanks
[10:14] <ali1234> i just noticed a bug i reported on bugs.meego.com in my launchpad page and i was wondering why...
[10:15] <ali1234> this is the bug: https://bugs.launchpad.net/rpm/+bug/635491
[10:15] <ubot5> Launchpad bug 635491 in RPM "rpm-python.spec refers to non-existing rpm.spec (affected: 1, heat: 5)" [Low,Triaged]
[10:15] <ali1234> is someone automatically pulling in all bugs from BMO or something?
[10:16] <nigelb> There is a remote watch enabled
[10:16] <nigelb> Is launchpad.net/~n3npq you?
[10:16] <ali1234> no
[10:16] <ali1234> the original description of the bug is verbatim copy of what i wrote on meego bugzilla
[10:17] <ali1234> and accredited to me
[10:17] <ali1234> so it's not like someone independantly reported it and then set up the watch
[10:17] <nigelb> Probably
[10:17] <nigelb> Its the other way around I guess
[10:18] <ali1234> sorry, i don't understand
[10:18] <nigelb> If you notice in the oringal description
[10:18] <nigelb> It says "In Meego #5546, Alistair Buxton wrote on 2010-08-18"
[10:18] <ali1234> yes, that's me
[10:18] <nigelb> So, its pulling from the meego bug tracker into lp
[10:18] <nigelb> And because you use the same email id on the meego bugzilla and your lp account, lp accredited it to you
[10:19] <nigelb> (yes, lp does remote bug watches, but I'm not sure how far, perhaps somone from the lp team will answer that)
[10:19] <ali1234> yeah i am familiar with remote watches, but normally they don't look like this
[10:19]  * nigelb pokes wallyworld_ 
[10:20] <ali1234> anyway i was just curious :)
[10:20] <wallyworld_> nigelb: hi
[10:20] <nigelb> Oh, great :)
[10:20] <nigelb> wallyworld_: Can clear up ali1234's query (you're the CHR :D )
[10:20] <wallyworld_> nigelb: let me read the previous context :-)
[10:21] <nigelb> I think this has something to do with remote bug tracker importing that we enabled some time back :-)
=== matsubara-afk is now known as matsubara
[10:21] <wallyworld_> nigelb: i just finished dinner :-)
[10:21] <nigelb> wallyworld_: I was afraid it was EOD and was just typing "he probably is at EOD.." when you said Hi ;)
[10:21] <wallyworld_> nigelb: np. i'll see what i can do to help
[10:21] <nigelb> \o/
[10:22]  * nigelb hugs wallyworld_ 
[10:24] <wallyworld_> nigelb: ali1234: i'm not an launchpad expert (yet) so let me look into it a bit. if i can't resolve it now, i'll pass it on and ensure someone can follow up
[10:24] <wallyworld_> ali1234: you want the remote watch removed? or just an explanation?
[10:24] <ali1234> just an explanation
[10:25] <ali1234> afaik to make a remote watch there needs to be an existing bug in launchpad, but that doesn't seem to be the case here
[10:25] <wgrant> ali1234: Ah, there's a bit of a bug here.
[10:25] <ali1234> so looks like the bug was imported some other way, and that got me interested
[10:25] <wgrant> ali1234: We now import comments from remote bugs.
[10:25] <wgrant> ali1234: And Launchpad assumes that the earliest comment in a bug is the original description.
[10:26] <wallyworld_> ali1234: hmmm. i have a poke around and see what i can find. what's your launchpad nick?
[10:26] <wgrant> ali1234: One of the imported comments predates the Launchpad bug, so Launchpad thinks it's the original description.
[10:27] <ali1234> wgrant: that would make sense, but shouldn't there be a comment somewhere like "bug watch added by ..."
[10:27] <nigelb> wgrant: So, this is like some kind of race case and a bug in lp?
[10:27] <ali1234> ah, full activity log...
[10:27] <wgrant> Is it just me, or have all the sprites vanished?
[10:28] <ali1234> ok thanks everyone, i think i understand what is going on now :)
[10:28] <wallyworld_> wgrant: thanks again for helping :-)
[10:29] <nigelb> wgrant: sprites?
[10:29] <wgrant> nigelb: Icons.
[10:29] <nigelb> I got that bit, but I can figure out which ones are missing.
[10:29] <wgrant> Hm, no, just Chromium being stupid.
[10:30] <nigelb> I see all the icons I should see except the ones I got used to with the greasemonkey plugin
[10:31] <tseliot> bigjools: are you there?
[10:31] <bigjools> tseliot: yep
[11:20] <bdrung> wallyworld_: here's the link: https://code.edge.launchpad.net/~audacity-team/+recipe/daily.karmic
[11:20] <wallyworld_> bdrung: thanks. we figured it out :-) there was an issue on a build server which should now be fixed
[11:22] <bdrung> wallyworld_: thanks. now even natty works!
[11:22] <wallyworld_> \o/
[11:25] <bdrung> wallyworld_: but karmic still fails: https://code.edge.launchpad.net/~audacity-team/+recipe/daily.karmic/+build/9537
[11:27] <wallyworld_> bdrung: ok. that's a different server. may be a problem on that one too :-( wanna try building again? i'll take a closer look at the logs
[11:29] <bdrung> wallyworld_: should i trigger it again?
[11:31] <wallyworld_> bdrung: give it a go - it will hopefully pick a different server to run on. in the meantime i'll see what can be found
[11:36] <wallyworld_> bdrung: confirmed - it appears to be another server with the same config issue. getting a sys admin onto it
[11:40] <wallyworld_> bdrung: sys admin tells me that server is now fixed. hopefully last one, but....
[11:42] <bdrung> wallyworld_: this time it works. so at least radium is fixed. ;)
[11:42] <wallyworld_> bdrung: cool :-)
[11:44] <bdrung> wallyworld_: how do i get rid of the "Failed to build" item at the top of https://code.edge.launchpad.net/~videolan/+recipe/master-daily
[11:46] <wallyworld_> bdrung: not sure. i can ask the guy who did a lot of that work when he comes online
[11:47] <bdrung> wallyworld_: thanks
[11:47] <wallyworld_> bdrung: np. he may well just say that it will disappear in time when more builds are done but i'm not sure
[11:47] <bdrung> wallyworld_: last question: where can i subscribe for build failures (recipe and ppa)?
[11:48] <bdrung> wallyworld_: this item has no value in the time column
[11:48] <wallyworld_> bdrung: you should be notified of your own recipe builds, no?
[11:48] <bdrung> wallyworld_: yes, but i am not notified for the team recipe builds
[11:49] <wallyworld_> bdrung: the time column will be the last successfult build, but there's also a "started" time too
[11:49] <wallyworld_> bdrung: ah ok. i would have thought you would be. i'll check that too
[11:50] <wallyworld_> bdrung: i know recipes are still a bit of work in progress so that notification bit may still be being worked on
[11:50] <bdrung> wallyworld_: the strange is that i get notifications for the audacity team, but not for the videolan team
[11:51] <bdrung> therefore i have to manually check if the daily vlc builds were successful
[11:54] <wallyworld_> bdrung: do you have access to the videolan team settings you can look at?
[11:57] <bdrung> wallyworld_: i am administrator in the videolan team
[11:57] <wallyworld_> bdrung: but you are the owner of the audaciity team so maybe there's an issue there.
[11:58] <wallyworld_> bdrung: i will look into it
[11:58] <bdrung> wallyworld_: yes
[12:05] <wallyworld_> bdrung: i'm told that the videolan team has a contact address set, hence notifications will go there, no tto team members
[12:06] <bdrung> wallyworld_: and there is no way for a user to subscribe to the notifications?
[12:08] <wallyworld_> bdrung: don't believe so :-(
[12:08] <wallyworld_> bdrung: but will double check
[12:11] <wallyworld_> bdrung: sorry, it appears there's no way around it
[12:12] <bdrung> wallyworld_: is there a whishlist bug for it?
[12:13] <wallyworld_> bdrung: i wouldn't be surpised if there were but you could create one and see if any dups are shown
[12:14] <bdrung> wallyworld_: against which project should i file the bug?
[12:14] <wallyworld_> bdrung: launchpad-foundations
[12:14] <bigjools> there's already a soyuz bug
[12:14] <bigjools> it's not a foundations bug
[12:15] <bigjools> wallyworld_, bdrung: ^
[12:16] <wallyworld_> bigjools: oh sorry, i assummed that notification infrastructure was foundatrions. oops
[12:16] <bdrung> bigjools: do you have the bug number?
[12:16] <bigjools> wallyworld_: what notification infrastructure? :)
[12:16] <bigjools> not at hand, one sec
[12:17] <bigjools> https://bugs.edge.launchpad.net/soyuz/+bug/341973 and https://bugs.edge.launchpad.net/soyuz/+bug/408278
[12:17] <ubot5> Launchpad bug 341973 in Soyuz "PPA build notifications go to entire team (affected: 0, heat: 0)" [Medium,Triaged]
[12:18] <wgrant> It's Soyuz/Code/Registry/Foundations.
[12:20] <bdrung> bigjools: these two bugs are about the opposite - i want the mails, the bug reporter don't want them
[12:20] <bigjools> bdrung: see the latter bug.  It's all connected, I might dupe them.
[12:21] <bigjools> we need a configurable system
[12:21] <bdrung> bigjools: yes, something like the system for bzr branches
[12:23] <maxb> Actually I find the behaviour complained against in bug 341973 to be intensely helpful for checking up on breakage by other people in team PPAs :-)
[12:23] <ubot5> Launchpad bug 341973 in Soyuz "PPA build notifications go to entire team (affected: 1, heat: 8)" [Medium,Triaged] https://launchpad.net/bugs/341973
[12:24] <bigjools> if you do a search for "notification" in the soyuz bugs, there's plenty of opinions :)
=== wallyworld_ changed the topic of #launchpad to: Launchpad: https://launchpad.net/ : pulling (imports, mirrors) now fixed | Read https://help.launchpad.net/ for help | On-call help contact: - | Join https://launchpad.net/~launchpad-users | This channel is logged: http://irclogs.ubuntu.com/ | Launchpad is open source: https://dev.launchpad.net/
[12:41] <geekosopher> I am getting this error when I try to visit http://bazaar.launchpad.net/~duanedesign/clicompanion/trunk/files since last 10 mins... 'Sorry, there was a problem connecting to the Launchpad server.'
[12:51] <geekosopher> still the same error
=== mrevell is now known as mrevell-lunch
=== oubiwann is now known as oubiwann_
=== oubiwann is now known as oubiwann_
=== oubiwann is now known as oubiwann_
=== doko_ is now known as doko
=== mrevell-lunch is now known as mrevell
=== yofel_ is now known as yofel
=== menesis1 is now known as menesis
=== matsubara is now known as matsubara-lunch
[14:15]  * CardinalFang reports Bug #683129.
[14:15] <ubot5> Launchpad bug 683129 in Launchpad itself "importing subversion branch causes empty error message (affected: 1, heat: 6)" [Undecided,New] https://launchpad.net/bugs/683129
=== zyga is now known as zyga-sick
=== zyga is now known as zyga-bed
=== matsubara-lunch is now known as matsubara
=== bjf[afk] is now known as bjf
=== beuno is now known as beuno-lunch
[16:10] <abentley> jml: I would like there to be a PPA with the latest testtools crack for Maverick.  Do you want to set it up, or should I?
[16:10] <jml> abentley: launchpad.net/~testing-cabal/+archive/archive
[16:10] <jml> abentley: that's builds of trunk
[16:11] <abentley> jml: great, thanks.
[16:11] <abentley> jml: we really need to make PPAs more discoverable.
[16:11] <jml> abentley: heck yes
[16:12] <bigjools> jml: we discussed that once before, didn't we have some ideas?
[16:12] <bigjools> there's a search page but nobody seems to use it
[16:14] <jml> bigjools: we might have, I don't remember.
[16:14] <jml> I want to get project archives sometime very soon, if I can.
[16:14] <bigjools> yes
[16:14] <_Groo_> hi/2 all
[16:14] <jml> and that will help
[16:14] <_Groo_> could anyone take a look at the kubuntu-ninjas ppa? we have a publish upload stuck since yesterday
[16:15] <abentley> jml: I want PPAs listed right under the download tarball.  No, dammit, *above* the download tarball.
[16:16] <bigjools> _Groo_: I can help, what's the build URL?
[16:16] <bigjools> PM me if you want, that's a private archive
[16:17] <jml> abentley: yeah. something like that would be good.
[16:38] <abentley> jml: In the meantime, a link to the PPA in the project description would be helpful.
[16:39] <jml> abentley: yeah. we probably want that even if we have project archives
[16:39] <jml> especially highlighting ppas that we know contain daily builds of trunk or other series branches
[16:41] <abentley> bigjools: I clicked the "all packages" link on the project page, and I didn't find any of the testing-cabal packages.  Which made me assume there was none.
[16:49] <fta> dpm, do you know if it's possible to link to a particular string in lp (for my converter logs html page)
[16:53] <askhl> fta: what do you mean by particular string?  It's possible to link to a "particular string" until the string numbering in the template changes
[16:53] <fta> askhl, in http://people.ubuntu.com/~fta/chromium/translations/trunk/converter-output.html  i want to link the errors to lp
[16:55] <fta> askhl, as i have 3k strings, a direct link to the faulty translations would be nice to have
[16:55] <fta> 3k x 50 langs
[16:57] <dpm> fta, you can have a direct link, but only if you know the string number within the template, e.g. https://translations.launchpad.net/chromium-browser/translations/+pots/webkit-strings/ca/2/+translate
[16:57] <askhl> fta: to me it looks like a job for direct po-file processing, something that wouldn't be possible in LP until there's a full interface in launchpadlib
[16:57] <fta> hm, i don't
[16:58] <askhl> Although one can of course construct an URL which results in a string search.  But that sort of thing is probably not so great for the servers in the long run
[16:59] <askhl> i.e. the URL https://translations.launchpad.net/jmol/trunk/+pots/jmol/da/+translate?batch=10&show=all&search=hydrogen
[17:00] <askhl> But it wouldn't work because the search doesn't support regexes, so you can't make sure to only get the exact string :)
[17:01] <fta> ok, too bad
[17:02] <askhl> fta: which programme are you using to generate those error messages?
[17:02] <askhl> is it the translate toolkit?
[17:03] <fta> askhl, https://code.edge.launchpad.net/~chromium-team/chromium-browser/chromium-translations-tools.head
[17:04] <fta> askhl, something like that: http://people.ubuntu.com/~fta/chromium/chromium-translations.png
[17:06] <askhl> Ah, interesting
[17:08] <fta> askhl, and i use that to improve the upstream translations of 4 channels: http://people.ubuntu.com/~fta/chromium/translations/
=== beuno-lunch is now known as beuno
[17:44] <bdmurray> @pilot in
=== menesis1 is now known as menesis
[18:17] <mounir> Is there a way to subscribe to all blueprints under a project, without subscribing to each blueprint?
=== apachelogger is now known as releaselogger
=== releaselogger is now known as apachelogger
[18:50] <shadeslayer> hi, i wish to rename this branch https://launchpad.net/kubuntu-konqueror-shortcuts
[18:50] <shadeslayer> the new name is supposed to be kubuntu-web-shortcuts
[18:50] <shadeslayer> how do i proceed?
[18:56] <micahg> shadeslayer: that's a project, not a branch
[18:56] <shadeslayer> micahg: right the project also has a branch, so is it possible to rename the whole thing?
[18:56] <shadeslayer> ( the whole project )
[19:01] <maxb> IIUC, only launchpad administrators can rename project ids
[19:02] <maxb> It's a measure to prevent that being gratuitously done, since it will cause major upset for people used to the old name
[19:02] <shadeslayer> hmm.. so do i have to post it on launchpad answers etc?
=== bilalakhtar_ is now known as bilalakhtar
[19:11] <cjohnston> jamesh: ping
=== henninge_ is now known as henninge
[19:40] <zanoi> i'm trying to import a SVN branch into launchpad but it fails with: bzrlib.errors.NotBranchError: Not a branch: "/trunk/playground/network/videocatcher".
[19:40] <zanoi> any ideas why?
[19:47] <maxb> zanoi: What is the full source URL?
[19:47] <maxb> shadeslayer: Yes, post a question
[19:49] <zanoi> maxb: svn://anonsvn.kde.org/home/kde/trunk/playground/network/videocatcher
[19:50] <maxb> zanoi: bzr-svn has "special" handling embedded in it for the KDE repository. This handling is quite often wrong.
[19:50] <zanoi> maxb: so how can i get it to work?
[19:51] <maxb> You would have to import it locally, or work to get the issue fixed in bzr-svn and launchpad
[19:51] <jelmer> maxb: Unfortunately it's /always/ wrong without the special handling..
[19:52] <zanoi> maxb: ok, thx :/
[19:57] <yshavit> Hi all, I'm trying to reach staging.launchpad.net and it's been down for a while. Any idea when it'll be back up?
[19:58] <yshavit> And in general, is it the appropriate place to create a test sandbox? My company is considering moving to launchpad, and we want to first make sure we like the VCS
[20:00] <thumper> yshavit: yes staging is the correct place
[20:00] <thumper> yshavit: I believe it is in the middle of a db restore
[20:00] <thumper> yshavit: the staging database gets reset periodically
[20:00] <yshavit> thumper: alright, thanks. So I'll just try again later.
[20:23] <jasonlife> I'm trying to upload a custom kernel to my ppa.. After I ran "debuild -S -sa", I noticed that .dsc and .diff.gz doesn't have the suffix I added in the changelog file.. Is this normal?
[20:35] <maxb> jasonlife: Show us the line with the suffix from your changelog file
[20:40] <joey> leonardr: around?
=== matsubara is now known as matsubara-afk
[20:41] <joey> leonardr: do you know of any way to speed this loop up? http://paste.ubuntu.com/538414/
[20:44] <joey> cody-somerville: ^^ that's the big time killer in lp-scanner
[20:44] <cody-somerville> joey, assign bug_task.bug to a local variable
[20:45] <komsas> hello, I'm searching how to export launchpad translations with suggessions, till now I could'nt find any solution, someone know how to do this? Thanks.
[20:45] <jasonlife> maxb: linux (2.6.32-26.48ppa1) lucid; urgency=low
[20:46] <joey> cody-somerville: I think it's the .searchTasks in the for loop which is the slow down but am not sure
[20:46] <maxb> jasonlife: So, I'd expect a linux_2.6.32-26.48ppa1.dsc from that, what did you actually get?
[20:47] <jasonlife> I got "linux_2.6.32-26.48.dsc"
[20:47] <jasonlife> and after I ran debuild -S -sa, the changes I made in changelog has also gone..
[20:47] <jasonlife> :(
[20:47] <maxb> erm. wtf
[20:48] <jasonlife> actually I did the same thing for normal package, and everything worked as expected..
[20:48] <cody-somerville> joey, do a time before you make my change and then a time afterwards and see if it makes a difference
[20:48] <jasonlife> but, kernel seems different..
[20:51] <joey> cody-somerville: no appreciable change (I called the local variable "boog" :-)
[20:52] <cody-somerville> joey, did you use boog instead of calling bug_task.bug.blah a bunch of times?
[20:52] <joey> cody-somerville: yeah I just made the assignment at the top and used boog everywhere else
[20:52] <jasonlife> I'm wondering there is a special way to upload custom kernel..  Since kernel modules depend on kernel version, I assumed uploading kernel to ppa is different than normal package..
[20:54] <cody-somerville> joey, odd. that trick usually speeds things up for me. maybe launchpadlib is better at caching things now.
[20:54] <yofel> jasonlife: kernel is a bit more complicated, there is a second changelog file you need to update
[20:57] <jasonlife> oh..
[20:57] <jasonlife> yofel: where is the second changelog?
[20:57] <yofel> jasonlife: just looked at it, debian/changelog and debian.master/changelog need to be the same
[20:58] <joey> cody-somerville: I just did this and it helped a little. Let me add your caching trick too:  for bug_task in [m for m in project.searchTasks(order_by='id')]:
[20:58] <yofel> the *right* procedure is probably different, but I only bothered with custom kernel packages once a while ago
[20:58] <yofel> that's how I did it
[20:58] <yofel> and there was something else...
[20:58] <jasonlife> oh.. I see..
[20:59] <jasonlife> yofel: thanks.. I will try again..
[20:59] <yofel> you also need to update the contents debian.master/abi/
[20:59] <yofel> there was a script for that in the package, let me look
[21:01] <jasonlife> yofel: once I change the version, then how can I handle the kernel module like nvidia kernel module?  Do I have to build that too?
[21:02] <yofel> if you use the package it should trigger a dkms build
[21:02] <jasonlife> good.. than I don't need to worry about some special kernel modules then..
[21:04] <yofel> jasonlife: for the abis you need to run debian/scripts/misc/getabis, but I forgot how to actually use that :/
[21:05] <yofel> jasonlife: you can ask in #ubuntu-kernel for the proper procedure too, if they're in the mood to help
[21:05] <jasonlife> :)
[21:06] <jasonlife> ok.. thank you very much..
[21:07] <yofel> ah, remembered it, for natty it would be './debian/scripts/misc/getabis 2.6.37 7.18' and move the abi files to debian.master/abi you'll probably need to use '2.6.32 26.48 ' as arguments
[21:08] <jasonlife> oh.. thanks..
[21:08] <yofel> needs quite a bit of bandwidth :/
[21:08] <jasonlife> Is it?
[21:09] <jasonlife> I've setup a free ppa.. Is it enough?
[21:09] <yofel> for uploading and building the package? yes, I used one of my ppas back then too
[21:10] <maxb> Disabling the abi checking entirely is often more what you want to do for PPA builds
[21:10] <maxb> Depends on the target audience of the PPA
[21:10] <yofel> maxb: how to do that?
[21:10] <maxb> And the magnitude of the changes you are making
[21:10] <maxb> yofel: not sure off hand, but there's definitely a toggle in there somewhere
[21:11] <joey> cody-somerville: well it looks like after doing more timings it's the IF that's slow
[21:12] <joey> cody-somerville: I can change up the for loop in many ways but it really doesn't make much difference
[21:14] <joey> cody-somerville: I've stripped out the if and that loop just cranks
[21:14] <joey> cody-somerville: so that's what I need to optimize
=== zyga-sick is now known as zyga
[21:22] <wgrant> joey: It's somewhere between very difficult and impossible to optimise that sort of thing right now.
[21:22] <wgrant> joey: But there's a new API design in progress which will make it possible and simple.
[21:22]  * joey nods.
[21:22] <joey> wgrant: I've made a little progress but it's not great
[21:23] <joey> wgrant: it checks about 2 bugs a second instead of like 200 :-)
[21:24] <wgrant> joey: Right, at the moment you'll be making at least one request for each bug.
[21:25] <joey> wgrant: ah exactly.
[21:25] <joey> wgrant: I split the IF so it's only 1 request at a time
[21:26] <joey> wgrant: 99.9% don't pass the first condition in the IF so I split it out into a nested if
[21:29] <wgrant> joey: Ah.
[21:29] <wgrant> joey: So, in the new API design you'll be able to tell it to retrieve a collection of bugs and some of their attributes, all in one request.
[21:30] <wgrant> Which should make this sort of thing far less slow.
[21:30] <joey> wgrant: oh absolutely!
[22:28] <MTecknology> I forgot... how to you mark that a bug has been filed upstream?
[22:29] <MTecknology> ah.. there we are