[00:01] <jelmer> mwhudson: how long does it take on average for a branch to be scanned?
[00:03] <mwhudson> jelmer: 30s
[00:03] <mwhudson> jelmer: given the scanner runs every minute
[00:05] <spiv> mwhudson: surely "30s + the average time it takes to do the scanning work"?
[00:05] <mwhudson> yes ok
[00:05] <mwhudson> but that's not very long on the whole
[00:05] <mwhudson> since we un****ed the scanner
[00:05] <spiv> (sorry, I haven't been pedantic for *hours*)
[00:05] <spiv> (because I was asleep)
[00:12] <spm> spiv: perhaps for your directory entry then: coder of bizarre, and pedantical chatter; start python faster
[00:12] <spiv> spm: :)
[00:12] <spm> spiv: feel very free to improve (not hard) ;-)
[00:27] <jelmer> mwhudson: so my lp:~jelmer/git/trunk branch doesn't work again, any chance you can check?
[00:32] <jelmer> it won't use older revisions?
[00:32] <jelmer> I mean, revisions that I pushed using my previous push
[00:34] <Leon_Nardella> Are ARM buildbots planned for the PPAs?
[00:34] <jelmer> it's uploading a 130Mb repo in 50 seconds, that can't be right..
[00:48] <thumper> jelmer: you're right, that is much too fast :)
[00:49]  * thumper looks
[00:49] <thumper> jelmer: what is the new branch you're pushing?
[00:49] <jelmer> thumper: I've just pushed to ~jelmer/git/trunk
[00:50] <thumper> jelmer: have the revision ids changed?
[00:51] <jelmer> thumper: no, the revision ids haven't changed
[00:51]  * thumper ponders
[00:51] <jelmer> (I added a workaround for a bug in bzr's revision serialization mwhudson pointed out)
[00:54] <thumper> jelmer: our OSA has gone walk-about, I'll check and get back to you
[00:54] <thumper> jelmer: mwhudson is at PyCon :)
[00:55] <jelmer> thumper: thanks
[00:55] <jelmer> ahh, I was wondering why he was less responsive than usual :-)
[00:58] <fta> it seems that ppa builders are completely broken
[00:58] <fta> https://edge.launchpad.net/~ubuntu-mozilla-daily/+archive/ppa
[00:58] <fta> 6 hours doing nothing?
[00:59] <fta> https://edge.launchpad.net/builders/bohrium: it's beeing doing that for ~5h
[01:01] <wgrant> Primary is the same too.
[01:01] <wgrant> No jobs have been started for 4 hours or so.
[01:02] <wgrant> spm: ^^
[01:06] <spm> wgrant, fta ta. am fighting some rather nasty fires at the moment. will get back to you asap.
[01:13] <_steven_> anyone know if the upcoming milestone to release conversion on april 1st will include linking bugs to newly created milestones?
[01:15] <jml> _steven_: I don't know off-hand.
[01:15] <jml> _steven_: are you subscribed to the launchpad-users mailing list?
[01:15] <_steven_> no
[01:15] <jml> hmm.
[01:15] <_steven_> was just reading the blog post
[01:17] <jml> _steven_: there's nothing in the announcement to launchpad-users either.
[01:18] <jml> _steven_: sinzui & others likely to know are asleep right now. If you really want to know then I suggest either asking a question on answers.launchpad.net/launchpad-registry, or emailing launchpad-users.
[01:18] <jml> or waiting until US working hours.
[01:19] <cpscotti> hello there, is there any particular reason why all but one PPA i386 building machines are idle even though there are 51 build in the queue? Should I just wait a little time or should I go to bed and check this tomorrow?
[01:19] <_steven_> if they're from US, I doubt they're asleep, just not working
[01:19] <sinzui> _steven_: Bugs are not linked to milestones by the migration script.
[01:19] <jml> sure. I used the word in the figurative sense :)
[01:20]  * sinzui thinks how that could be done
[01:20] <jml> oh. hurrah.
[01:20] <jml> cpscotti: it's a known problem. we're working on it now.
[01:20] <cpscotti> hmmm thanx!
[01:20] <cpscotti> =]
[01:20] <_steven_> sinzui: my project has never used milestones before, but I'd like all my old bugs that I fixed in a certain release to be targeted to the newly created milestones
[01:21] <_steven_> it might not be trivial to do though
[01:21] <sinzui> _steven_: We intend to create a unified milestone/release page what will show the changelog and closed bugs.
[01:21] <_steven_> that would be a nice addition
[01:22] <_steven_> is that part of 2.2.3 or coming later?
[01:23] <sinzui> _steven_: I'm hacking on it right now. I'm going to beg permission to landed it for the 22.3 release.
[01:23] <_steven_> hehe, ok
[01:23] <jml> sinzui: :D
[01:24] <sinzui> _steven_: The act of associating a bug with a milestone is manual. However, there are rules to link (html anchor) a bug in changelog, so I image that if we trust the changelog/release notes, we could mine that to link bugs milestones.
[01:26] <_steven_> ok, any documentation on the correct format?
[01:27] <sinzui> _steven_:  if the text or a changelog contain bug 1234, bug #1234, lp: 1234, we assume that that is a Launchpad bug
[01:27] <ubottu> Launchpad bug 1234 in launchpad-foundations "Gina is an unmaintainable mess of command line options, environment variables and shell scripts" [Medium,Fix released] https://launchpad.net/bugs/1234
[01:27] <sinzui> oops
[01:27] <_steven_> sinzui: would lp#287995 match?
[01:28] <sinzui> _steven_: yes. We have a nicer report for blueprints an bugs that are explicitly targets to milestone
[01:29] <_steven_> sinzui: I always put my changelog in the release description because I can never get the changelog to show on the release page
[01:30] <_steven_> sinzui: for example, this release has the changelog contents in the description and the changelog fields, but only description shows: https://launchpad.net/linuxdcpp/1.0/1.0.3
[01:31] <_steven_> will that be modified with the changes you are working on?
[01:31] <sinzui> _steven_: yeah. most projects do. I am proposing that we include (but hide the changelog). I have no explanation why the change log is hidden.
[01:31] <sinzui> only the RDF published the changelog
[01:33] <sinzui> We wont be modifying. I think putting the changelog in a expanding section is a good way to expose the information while minimising the duplication. beuno will review the design to finalise how we reconcile this historical oversight.
[01:34] <_steven_> ok, so if you guys happen to implement milestone to bug conversion, it should work with my changelog
[01:37] <_steven_> sinzui, jml: thanks for the help
[01:38] <jml> _steven_: np
[01:41] <spm> wgrant: fta: stuff seems to be processing again. leastways, the buildd's are busy again.
[03:03] <thumper> jelmer: you branch is failing to scan with the SyntaxError: not well-formed (invalid token): line 6, column 46 from bzrlib.xml_serializer, line 101, in read_revision_from_string
[03:06] <jelmer> thumper: thanks
[03:07] <thumper> jelmer: I thought you'd be asleep :)
[03:07] <thumper> jelmer: do you want the entire stacktrace for bzrlib?
[03:08] <jelmer> thumper: no, thanks, I think this is an indication the bug I thought was fixed is still around
[03:08] <thumper> ok
[03:08] <thumper> jelmer: can I delete that branch then?
[03:08] <thumper> jelmer: otherwise it is going to try every minute or so
[03:09] <thumper> jml: we need a way to tell the scanner not to try...:-|
[03:10] <jml> thumper: easy easy easy :)
[03:12] <jelmer> thumper: I've already done so
[03:12] <thumper> jelmer: thanks
[03:12] <jelmer> thumper: daylight savings is messing with me
[03:12] <thumper> :)
[03:24] <jml> thumper: is it still DST in NZ?
[03:24] <thumper> jml: until this weekend I think
[03:25] <jml> *nod*
[03:25] <jml> fun and games and 8am start times :(
[03:25] <jelmer> thumper: seems to work ok now: http://bazaar.launchpad.net/~jelmer/git/trunk/changes
[03:25]  * jelmer gets some sleep
[03:34] <mwhudson> jelmer: your git branch got scanned in the end i see
[03:35] <mwhudson> jelmer: it occurred to me that the case like this, when there are lots of revisions new to launchpad being scanned, is still pretty slow
[03:35] <thumper> mwhudson: not entirely scanned :(
[03:36] <thumper> mwhudson: loggerhead says last rev was 3000
[03:36] <thumper> mwhudson: LP says 1000
[03:36] <mwhudson> huh what
[03:36] <mwhudson> oh yes
[03:36] <thumper> mwhudson: I'm guessing that the commits done after chunks has meant that the first 1000 were fine
[03:36] <thumper> mwhudson: but something went wrong in the second 1000
[03:36] <thumper> mwhudson: or it could still be scanning :(
[03:37] <thumper> mwhudson: with new revisions
[03:37] <mwhudson> but it's all one transaction
[03:37] <mwhudson> isn't it?
[03:37] <thumper> nope
[03:37] <thumper> hasn't been for ages
[03:37] <thumper> otherwise it was holding the transaction open for too long
[03:40] <mwhudson> ah
[03:42] <TheMuso> I have recieved an upload failure for the latest revision of pulseaudio for amd64. I retried the build once thinking the failure to upload was a transient error: https://launchpad.net/ubuntu/+source/pulseaudio/0.9.14-0ubuntu15/+build/923086
[03:42] <TheMuso> All other architectures have built and uploaded successfully.
[04:14] <jamesh> TheMuso: you'll probably have better luck asking at the end of the day, given the time zones where the soyuz guys work
[04:15] <jamesh> or file a bug
[04:15] <TheMuso> jamesh: Thanks, will do
[04:17] <spm> TheMuso: can you see the upload log? has a 'duplicate key value' fail. I call bug.
[04:18] <TheMuso> spm: Yes, I can bounce the upload failure to you if you would like.
[04:18] <jamesh> hmm.  I think someone else came up with that one recently
[04:19] <jamesh> https://bugs.edge.launchpad.net/soyuz/+bug/347194
[04:19] <ubottu> Ubuntu bug 347194 in soyuz "IntegrityError: duplicate key value violates unique constraint "binarypackagerelease_binarypackagename_key"" [Low,Triaged]
[04:19] <TheMuso> spm: bounced
[04:20] <jamesh> TheMuso: last comment on the above bug is cprov saying he thinks the problem is fixed
[04:20] <TheMuso> jamesh: sounds about right
[04:20] <jamesh> TheMuso: you seem to have proved the opposite
[04:20] <jamesh> so it'd be helpful to tell him
[04:20] <TheMuso> jamesh: seems so
[04:20] <TheMuso> ok
[04:20]  * TheMuso replies to teh bug
[04:20] <TheMuso> but in another twist, it seems the amd64 debs are now on a.u.c.
[04:21] <spm> TheMuso: ta. fwiw I could read the log - I'm just never quite sure how much of what I can see is common to those without super-duck powers :-)
[04:21] <TheMuso> spm: ok
=== abentley1 is now known as abentley
[06:53] <dholbach> hiya
[06:53] <dholbach> somebody aware of OOPSES like OOPS-1185B627 happening?
[06:53] <ubottu> https://devpad.canonical.com/~jamesh/oops.cgi/1185B627
[06:54] <dholbach> (just tried to open a https://launchpad.net/bugs/123456 URL)
[06:54] <ubottu> Error: Could not parse data returned by Ubuntu: HTTP Error 500: Internal Server Error (https://launchpad.net/bugs/123456/+text)
[06:54] <dholbach> ah :)
[06:55] <spm> dholbach: something has *really* broken. :-(
[06:55] <spm> dholbach: i expect to be hairless from excessive hair pulling rsn.
[06:55] <dholbach> oh yeah, openid is broken too
[06:55] <dholbach> launchpad.net too FWIW :-/
[06:55]  * dholbach hugs spm
[06:55] <spm> yah. something has really gone boom in a big way
[06:56] <jfroy> mmm, I'm getting ProtocolError for xmlrpc.lp.internal:8097/branchfilesystem: -1 errors from launchdpad
[06:56]  * wgrant just found the world was broken too.
[06:56] <jfroy> started not too long ago
[06:56] <dholbach> I'm sure the best people possible are working on this.
[06:59] <wgrant> Looks more healthy now.
[06:59] <dholbach> yeah, nice work! :-)
[06:59] <wgrant> Not bad recovery time.
[07:00] <jml> not even 9 minutes.
[07:00] <spm> all seems ok? do yell if you notice any funkies and I'll start bouncing app servers or whatever
[07:00] <jml> spm: looks good to me so far.
[07:13] <jfroy> urg, my branch is locked on launchdpad, and the break-lock command is failing :|
[07:14] <wgrant> jfroy: Make sure you're giving break-lock an lp: URL and not an lp-123456: URL.
[07:14] <jfroy> ahhh
[07:15] <jfroy> that's a lame UI bug >.>
[07:15] <wgrant> It is.
[07:15] <wgrant> Particularly because I was able to guess with good certainty what the problem was.
[07:21] <jml> yes.
[07:53] <AnAnt> Hello, Steve McInerney here ?
[07:54] <spm> AnAnt: that'd be me. what's up?
[07:55] <AnAnt> spm: regarding question 62612
[07:55] <AnAnt> thanks, but the links on https://launchpad.net/~sabily.team/+archive/ppa still won't work
[07:55] <spm> arrgrghhh!
[07:55] <AnAnt> for example: https://launchpad.net/~sabily.team/+archive/ppa/+sourcepub/504630/+files/sabily-keyring_2009.01.20~ppa1_all.deb
[07:56]  * AnAnt hides under the table
[07:57] <spm> AnAnt: heh. No, is not your fault. no need to hide :-)
[07:57]  * AnAnt pops his head to check that everything is clear
[07:57] <spm> :-)
[07:58] <spm> AnAnt: is that link off the PPA pages somewhere? ah yes tehre it is. nm
[08:00] <spm> AnAnt: ahhh. I see the problem. :-( if you use edge, it works. use prod, it doesn't. :-(
[08:01] <spm> AnAnt: eg https://edge.launchpad.net/~sabily.team/+archive/ppa and browse
[08:01] <AnAnt> ok, but for those downloading using, apt-get, no probs ?
[08:01] <spm> I'm not sure tbh....
[08:01] <spm> shouldn't be a problem now I engage brain.
[08:01] <spm> AnAnt: check the sources URL if it's like this: http://ppa.launchpad.net/sabily.team/ppa/ubuntu/ you'll be fine
[08:02] <AnAnt> errm, didn't work with edge btw
[08:02] <wgrant> Drop the +sourcepub/123456
[08:03] <AnAnt> ah, that worked !
[08:04] <spm> AnAnt: sorry to run on you like this, but I'm really afk now. :-( If no joy, drop a new question, reffing the old and we'll sort from there.
[08:04] <AnAnt> ok
[08:05] <AnAnt> thanks
[09:06] <YokoZar> ok I can't link to an upstream bug report because the "also affects distribution" page is giving me an error as though I wanted to add a distribution rather than just link an upstream bug
[10:19] <wgrant> YokoZar: The "Also affects distribution" wil lexpect you to add a distribution task, yes.
[10:19] <YokoZar> wgrant: yeah I was supposed to be clicking also affects project
[10:20] <YokoZar> which didn't have the familiar place to paste the upstream bug link since the bug already had an upstream link (I wanted to add a second)
[10:20] <YokoZar> so I assumed I was on the wrong page since it wasn't familiar
[10:20] <wgrant> Ahh.
[10:23] <slangasek> are there known issues with LP right now?  I've just gotten two oopses in the past 5 minutes, that cleared up on reload
[10:23] <slangasek> the last specifically said it was a timeout
[10:23] <wgrant> slangasek: There was a huge problem a few hours ago.
[10:23] <wgrant> But it was plain OOPSing.
[10:27] <slangasek> wgrant: perhaps related, perhaps not; but this was definitely more recent than a few hours ago
[10:27]  * slangasek keeps an eye out
=== AnMaster_ is now known as AnMaster
[11:13] <slangasek> another timeout - OOPS-1185A1418
[11:13] <ubottu> https://devpad.canonical.com/~jamesh/oops.cgi/1185A1418
[12:06] <serola> Question... Ubuntu teams like Ubuntu Netbook Remix seem to use Launchpad as a server for their repositories. Is it okay for other open source projects to do the same?
[12:08] <wgrant> serola: Launchpad is intended to be used by any open source project.
[12:10] <serola> Thanks wgrant :)
=== beuno_ is now known as beuno
[13:15] <SiDi> Hello
[13:15] <SiDi> I've got a question regarding launchpad's bug tracker
[13:16] <intellectronica> SiDi: what's the question?
[13:16] <SiDi> Someone just reported a bug on one of my projects, but the bug obviously doesnt concern my project (i anyways didnt post any code yet), and i'd like to know how to push the bug report out
[13:16] <SiDi> is there a way to say that a bug doesnt affect a project ?
[13:16] <intellectronica> SiDi: url?
[13:17] <intellectronica> SiDi: you can change the target of a bug task
[13:17] <SiDi> https://bugs.launchpad.net/reztorrent/+bug/351489
[13:17] <ubottu> Ubuntu bug 351489 in reztorrent "vuze java problem" [Undecided,New]
[13:18] <intellectronica> SiDi: i think azureus has an LP project registered. so you can simply retarget that bug
[13:18] <intellectronica> azureus == vuze iirc
[13:18] <SiDi> alright, gonna check for azureus
[13:19] <intellectronica> SiDi: just expand the form and input 'azureus' into the textbox that currently says 'reztorrent' and save
[13:19] <SiDi> thanks intellectronica
[13:21] <SiDi> When a bug report is obviously wrong / is fake, is there a way to link it to no project btw ?
[13:21] <SiDi> or should i just make it invalid ?
[13:25] <intellectronica> SiDi: you should mark it invalid. we don'y currently have a way to remove bug reports entirely. a common convention is to retarget them to the project 'null'
[13:25] <SiDi> Alright, thanks for the tip
[13:29] <wgrant> bigjools: Is there a good reason that the user's display name is always part of the PPA title?
[13:29] <noodles775> wgrant: I'm guessing it's left over from when users had only one ppa and couldn't change the name...
[13:31] <noodles775> Now that users will be able to rename ppa's, it won't be the case any longer...
[13:31] <wgrant> '“name” PPA for Some User' is better than the current 'PPA named name for Some User', but just showing the display name would be even better.
[13:32] <noodles775> Yep, I agree... although it might give the PPA some sort of context that it wouldn't otherwise have..
[13:32] <noodles775> eg, user creates a ppa 'kde-releases'
[13:32] <wgrant> There's context in the breadcrumbs. But I guess that doesn't help for the OpenPGP keys.
[13:33]  * wgrant notices that the PPA vocab is a bit broken now.
[13:34] <wgrant> Actually, completely broken.
[13:34] <wgrant> Or at least one use of it.
[13:34] <wgrant> (+edit-dependencies' selector)
[13:35] <wgrant> Ah, bug #340457
[13:35] <ubottu> Launchpad bug 340457 in soyuz "Allow users to set the PPA displayname" [High,In progress] https://launchpad.net/bugs/340457
[13:35] <noodles775> :)
[13:36] <wgrant> Bug #334883 is where the initial naming was decided :(
[13:36] <ubottu> Launchpad bug 334883 in soyuz "Fix PPA titles to cope with multiple PPAs per user" [Undecided,Fix committed] https://launchpad.net/bugs/334883
[13:36] <wgrant> Didn't notice that :(
[13:36] <wgrant> maxb: ^^
[13:37]  * noodles775 is surprised that a bug got through wgrant's filters!
=== thunderstruck is now known as gnomefreak
[14:37] <stani> is it possible to delete a branch from launchpad (I've created by one by accident)?
[14:38] <jpds> stani: Go to the branch's page and press the rubbish bin next to the name.
[14:40] <stani> jpds: thanks, that worked! great
[14:41] <jpds> No problem.
[14:52] <dominiks> hey guys... I'm getting error when trying to access my build logs (e.g. https://launchpad.net/~dominik-smatana/+archive/ppa/+build/923742 ) any idea please?
[14:59] <bigjools> dominiks: ugh. please file a bug on "soyuz" about that
[15:00] <dominiks> bigjools: ok
[15:01] <bigjools> thank you
[15:06] <bigjools> dominiks: try it again
[15:06] <dominiks> bigjools: everything looks fine now.. thank you
[15:44] <RainCT> Hey
[15:44] <RainCT> Aren't sponsored uploads displayed under "Related Software" anymore?
[15:47] <thewrath> hello all i am new to launchpad have set it up fo rmy project
[15:47] <thewrath> i have some questions
[15:47] <beuno> thewrath, shoot
[15:48] <thewrath> i did a test bug i want that related to a specific version
[15:48] <thewrath> i have created a series
[15:48] <thewrath> called 2.1 but dont know and didnt see where i can relate the bug to that serial
[15:48] <thewrath> *series
[15:48] <thewrath> and how to change the status and what not for the bug
[15:49] <thewrath> bc i am not suing bazaar adn not using blueprints
[15:49] <thewrath> if that helps at all
[15:49]  * beuno pokes gmb, BjornT and intellectronica and runs off for 10'
[15:49] <thewrath> so my quesiton is how to i related a bug to a series and how do i change the status important, etc
[15:49] <RainCT> thewrath: click on the arrow next to the project name / status / importance
[15:49] <intellectronica> whassup?
[15:50] <thewrath> k
[15:50] <RainCT> thewrath: then you can set Status, Improtance, Milestone and Assignee. Afaik you can't set it to a series, but have to use Milestones instead
[15:50] <thewrath> how do i realted it to a series i created
[15:50] <thewrath> ok
[15:51] <thewrath> hold on let me finsih this survey
[15:51] <RainCT> (a series can contain several releases and milestones, and it's the milestones which you use for bugs)
[15:51] <thewrath> ok
[15:52] <thewrath> how do i create a milestone
[15:52] <thewrath> and remove a series
[15:53] <thewrath> think i found it
[15:54] <thewrath> whats the difference between release and milestone
[15:55] <RainCT> thewrath: a release is for downloads and a milestone for bugs
[15:55] <thewrath> k
[15:55] <RainCT> iirc soon all releases will automatically get a milestone with the same name
[15:56] <thewrath> ok
[15:56] <thewrath> how can you remove a relase
[15:58] <thewrath> RainCT: thank you so much
[15:59] <thewrath> RainCT: how can the bug reporter set up where the bug is like what release or is that always the issue of the person in charge?
[16:01] <RainCT> thewrath: the later. You're welcome :)
[16:02] <RainCT> You can set a text with instructions for bug reporters so you can tell them there "please note what version you're using [in the bug description]" or whatever
[16:04] <thewrath> i mean they wont be able to pick the milestone
[16:16] <MTecknology> kiko: you around?
[16:16] <kiko> no
[16:17] <MTecknology> kiko: can I pm you? absolutely nothing to do with launchpad
[16:17] <kiko> I'm on the phone, that's why
[16:18] <MTecknology> kiko: could you let me know when you're done? I need to talk with a Canonical employee that I trust fully
[16:19] <MTecknology> or - that I trust that will do something
[16:23] <kiko> MTecknology, okay, privmsg me
=== salgado is now known as salgado-lunch
=== matsubara is now known as matsubara-lunch
=== salgado-lunch is now known as salgado
[18:12] <jsmidt> I have a PPA for Git.  Launchpad keeps saying the i386 build fails but the build log says: "Built successfully"
[18:13] <jsmidt> Does anybody know how this couldbe?
[18:27] <geser> I'm currently looking at the LP API and there on the 'build' object: is it currently possible to get back from the build log to the source package?
[18:27] <geser> and is it possible to get infomations about the current version in e.g. jaunty for a source package?
[18:28] <james_w> build.build_log_url
[18:28] <geser> and parsing that?
[18:28] <james_w> ah, sorry
[18:29] <james_w> no, there's no way back yet by the look of it
[18:29] <geser> I've a 'build' object and want to get the source package name and the version of it the build log applies
[18:29] <james_w> you can do the second thing though
[18:30] <james_w> ubuntu.main_archive.getPublishedSources()
[18:31] <geser> thanks
[18:31] <geser> so I only need to extract the source package name from the build log
[18:32] <cprov> jsmidt: what's the build URL ?
[18:33] <jsmidt> cprov, it's: https://launchpad.net/~git-core/+archive/ppa/+build/922979
[18:35] <james_w> geser: yeah, but file a bug requesting the build->source package link be exposed
[18:36] <cprov> jsmidt: I've updated the build record to 'successfully_built' since it was built correctly. I'm still investigating what is causing this problem.
[18:38] <cprov> jsmidt: the hardy source will fail in the same way, once it settles I will update it as well.
[18:38] <jsmidt> cprov, thank you a lot
=== matsubara-lunch is now known as matsubara
[18:50] <bromic94> hey all
=== bromic94 is now known as thewrath
[18:51] <thewrath> under where it says milestone, etc how can i add a area that it says what issue it is like waht category?
=== ejat is now known as e-jat
[19:09] <djsiegel1> Hello, how do I delete a project/team?
[19:10] <cody-somerville> djsiegel1, File a question against launchpad requesting it
[19:10] <djsiegel1> Thank you
=== beuno_ is now known as beuno
=== mcasadevall is now known as NCommander
=== mwhudson_ is now known as mwhudson
[19:25] <bdmurray> In the API documentation participants_collection refers to "IPerson.inTeam()" but I can't find that documented anywhere.  Does it exist?
[19:30] <salgado> bdmurray, not in the API
[19:31] <bdmurray> salgado: did it used to?  I want to find out if a specific person is a participant in a team w/o grabbing all the team's participants
[19:31] <salgado> bdmurray, it's an internal method that was exported at some point but we had to unexport it because of privacy reasons
=== beuno_ is now known as beuno
[19:35] <fta> could you guys not use a red cross (failed) when a package is in depwait mode? (https://edge.launchpad.net/~ubuntu-mozilla-daily/+archive/ppa)
[19:36] <fta> please :)
=== mtaylor_ is now known as mtaylor
[20:02] <thewrath> where can i learn about the launchpad bug status meanings/
[20:04] <dominiks> https://wiki.ubuntu.com/Bugs/Status
[20:05] <intellectronica> thewrath: https://help.launchpad.net/Bugs/Statuses
[20:10] <thewrath> ty
[20:39] <MTecknology> Ursinha: https://edge.launchpad.net/people/?name=Trefný%2C+Vojtěch&searchfor=all
[20:39] <MTecknology> _Ursinha: OOPS happens when searching for users with certain symbols in their name
[20:41] <Ursinha> MTecknology, a min please
[20:43] <Ursinha> MTecknology, bug 251569
[20:43] <ubottu> Launchpad bug 251569 in launchpad-foundations "UnicodeEncodeError when browser submits non-utf-8 data" [Low,Triaged] https://launchpad.net/bugs/251569
[20:44] <MTecknology> Ursinha: ok - just wanted to make a note of it. I popped over to google for those users to find a link :P
[20:47] <Ursinha> MTecknology, :)
[20:54] <jkakar> Bug team: Ooh, I just got my first glimpse of the activity log work in the bug tracker, "tags changed: added review".  Very awesome, thanks! :)
[20:56] <tux_> hi
[20:56] <tux_> are there any?
[21:11] <vadi2> Why is https://bugs.launchpad.net/bugs/346754 inaccessible?
[21:11] <ubottu> Error: This bug is private
[21:11] <vadi2> Oh. mk.
[21:12] <vadi2> It's just on https://wiki.ubuntu.com/UbuntuBugDay/20090402
[21:13] <cody-somerville> vadi2, you should be able to see it now
[21:13] <vadi2> yes
[21:20] <vadi2> same with https://bugs.launchpad.net/bugs/349741
[21:20] <ubottu> Error: This bug is private
=== beuno_ is now known as beuno
=== barry is now known as tehsuck
=== tehsuck is now known as barry
[21:36] <vagrantc> i've noticed recently one of the bzr projects stopped sending out commit notifications, but another related project continues to send them. others also stopped receiving commit notifications... https://code.launchpad.net/~ltsp-upstream/ltsp/ldm-trunk
[21:36] <cody-somerville> vadi2, btw, the reason that those bugs are private is because they contain potentially private information. Usually a bug triage team member will mark them as public after they've made sure no private information is in the report.
[21:36] <vadi2> eh, ok
[21:39] <cody-somerville> vagrantc, is ~ltsp-upstream/ltsp/ldm-trunk an example of a branch that no longer sends out commit notifications?
[21:39] <vagrantc> cody-somerville: yes.
[21:39] <cody-somerville> vagrantc, what is your launchpad id?
[21:39] <vagrantc> cody-somerville: vagrantc
[21:40] <vagrantc> cody-somerville: another person, i think ryan52, didn't receive anything after 1140 either.
[21:40] <vagrantc> cody-somerville: https://code.launchpad.net/~ltsp-upstream/ltsp/ltsp-trunk works fine. seem to be configured identically.
[21:41] <cody-somerville> What does it say on https://code.edge.launchpad.net/~ltsp-upstream/ltsp/ldm-trunk/+edit-subscription ? Can you post a screenshot?
[21:42] <vagrantc> cody-somerville: notification level: branch attribute and revision notifications   generated diff size limit: 500 lines  code review level: status changes only ...
[21:42] <vagrantc> cody-somerville: both are configured identically for me.
[21:42] <cody-somerville> vagrantc, can you try making a commit?
[21:46] <vagrantc> cody-somerville: ok, pushing ...
[21:49] <cody-somerville> vagrantc, I got notified. Did you?
[21:50] <vagrantc> cody-somerville: i'm checking... Ryan52 was also experiencing the problem
[21:51] <vagrantc> cody-somerville: well, i got that one. though nothing between 1140 - 1150 ...
[21:52] <vagrantc> cody-somerville: and 1150 was committed just a short while earlier
[21:52] <cody-somerville> vagrantc, is it possible you simply missed them in your inbox?
[21:52]  * Ryan52 doubts that me and vagrantc would both miss the same exact 10 emails..
[21:52] <vagrantc> cody-somerville: pretty doubtful
[21:53] <vagrantc> cody-somerville: perhaps you subscribing to it somehow corrected the problem?
[21:53] <cody-somerville> Tough to say
[21:53] <vagrantc> cody-somerville: well, thanks for looking at it ... it appears to be working now, in any case. :)
[21:53] <cody-somerville> :)
[21:53] <cody-somerville> np
[21:53] <vagrantc> i've gotta run...
[22:02] <fta> http://launchpadlibrarian.net/24546525/cb1TWHeZAb1ZYclOUas44ivnbEl.txt
[22:03] <wgrant> fta: Known - cprov's working on it.
[22:04] <wgrant> fta: The package built fine, and the binaries will be in the archive already, so you can ignore the error.
[22:04] <fta> wgrant, ok, thanks
=== salgado is now known as salgado-afk
[22:05] <cprov> fta: crap-crap-crap! Sorry for this inconvenience, I'm working on it.
[22:05] <fta> cprov, np :)
[22:06] <wgrant> cprov: buildd-manager is racing with itself?
[22:07] <cprov> wgrant: sort of, it's waiting for a db update that never happens.
=== AnMaster_ is now known as AnMaster
[22:09] <wgrant> cprov: I don't see how that can cause it to retry the build, but okay.
[22:10] <cprov> wgrant: a collected build is not updated, so it's still pending and is dispatched again.
[22:11] <wgrant> cprov: Oh, ouch.
[22:11] <cprov> wgrant: yes, pretty much it ;)
[23:36] <wgrant> cprov: I just had a thought about multiple PPA key naming - why do they have different keys at all?
[23:37] <cprov> wgrant: different repositories
[23:37] <wgrant> cprov: Controlled by the same set of people, which removes a big reason to have them split.
[23:38] <wgrant> But there's probably another few good reasons to have them split, and it was just a quick thought on how to resolve this issue.
[23:38] <cprov> wgrant: I can see some few cases where sharing signing-keys would be beneficial
[23:39] <cprov> for instance ubuntu primary and partner share a key
[23:39] <wgrant> Erk, I have to run to catch a bus to uni that leaves in 4 minutes.
[23:39]  * wgrant -> gone
[23:39] <cprov> wgrant: but for the vast majority of cases, independent keys is the safest path
[23:40] <cprov> wgrant: talk to you later ;)
[23:45] <maxb> I get the point of using separate keys for separate trust domains.... but when the entity you are trusting is identical in either case... that suggests separate keys are not actually a win
[23:50] <fta> cprov, should i retry my builds or just wait?
[23:51] <cprov> fta: you probably don't have to retry them, they were already successfully built and uploaded the first time they got dispatched
[23:52] <cprov> fta: the second dispatch messes with the build status, only, but the original binaries should be published already
[23:52] <cprov> fta: what's the build URL ?
[23:52] <fta> cprov, the page is still red
[23:53] <fta> here is one https://edge.launchpad.net/~ubuntu-mozilla-daily/+archive/ppa/+build/924017
[23:55] <cprov> fta: but the resulting binaries are in LP (the second portlet)
[23:56] <cprov> fta: I will fix it, one sec