[00:00] <wgrant> I see.
[00:00] <wgrant> That is indeed odd.
[00:00] <wgrant> Distinct users?
[00:01] <persia> Probably a documentation bug: somewhere it says "to get the code ready to branch, open a question requesting a vcs-imports branch of upstream" or similar.
[00:15] <maxb> urgh
[00:15] <maxb> Well, reviewing code imports has certaintly tought me the reason for needing code import reviews
[00:16] <maxb> Of this current batch, I think I've only been able to approve one unmodified, out of about 8
[03:36] <micahg> hi lifeless
[03:46] <lifeless> hi
[03:47] <micahg> lifeless: just wanted to let you know that karma calculation has been broke for about a week
[03:48] <lifeless> thanks
[07:18] <happyaron> could anyone tell me am I possible to get the content of this branch? https://code.edge.launchpad.net/~registry/gnome-paint/trunk
[07:21] <spiv> happyaron: hmm, looks like the branch is broken; it's stacked on a branch that no longer exists, or has been renamed :/
[07:21] <spiv> Although, hmm.
[07:22] <happyaron> spiv: so is there any chance to get the content?
[07:22] <spiv> That's weird.
[07:22] <wgrant> A branch owned by ~registry? That's a little odd.
[07:22] <wgrant> Sounds like the owning team might have been deleted.
[07:22] <spiv> wgrant: also odd is that web page says it's stacked on another ~registry branch
[07:22] <spiv> wgrant: but the branch itself says it's stacked on a ~gp-team branch
[07:22] <wgrant> Yeah, ~gp-team must have been deleted.
[07:23] <spiv> Ah
[07:23] <spiv> And presumably the DB record for e.g. the stacked-on details got updated
[07:23] <spiv> But the branch's branch.conf didn't
[07:23] <wgrant> Right.
[07:23] <wgrant> Deleting reassigns all artifacts to ~registry
[07:23] <wgrant> So the branch's path changed.
[07:23]  * spiv -> afk for a bit
[07:23] <wgrant> happyaron: I'll push a good copy up somewhere. Give me a sec.
[07:24] <happyaron> wgrant: thanks
[07:35] <wgrant> happyaron: https://code.edge.launchpad.net/~wgrant/gnome-paint/trunk-good/
[07:37] <happyaron> wgrant: thank you
[07:42] <spm> wgrant: for my own documenting purposes; how did you solve that? roughly?
[07:44] <wgrant> spm: For admins it's easy (just edit .bzr/branch/branch.conf in broken branch, fixing stacked_on_location to point to the new URL). But because I can't edit that branch, I just grabbed both over SFTP, correct stacked_on_location, then pushed.
[07:45] <spm> huh. cool, thanks!
[07:45]  * spm fires up the wiki editor. again.
[07:46] <spm> ho ho ho ho. LPHowTo/FixingBrokenBranches <== already existed
[07:51] <spm> wgrant: fwiw: scripts/get-stacked-on-branches.py | grep "<PROJECT>" | scripts/update-stacked-on.py --dry-run <== in the tree. obviously this is for our use, but fyi.
[07:51] <wgrant> spm: Ah, handy.
[07:54] <spm> in any event, having more than one way to solve it, is useful. you've been wiki immortalised. ;-)
[07:57] <wgrant> Heh.
[09:32] <fta2> hi, question about translations exports. i want a different branch from the one used for the daily imports, how should i create that export branch? should it be a "branch" of the imported branch? or could it be unrelated?
[09:47] <thumper> jtv: ^^^
[09:47] <jtv> thumper: thx
[09:47] <jtv> hi fta2, reading backscroll now
[09:48] <fta2> jtv: it's for https://translations.edge.launchpad.net/chromium-browser/translations
[09:49] <fta2> jtv, for the import, i use https://code.edge.launchpad.net/~chromium-team/chromium-browser/chromium-translations.head
[09:49] <jtv> fta2: the answer depends on what you want to do with the branch later.  If you ever want to feed the results back into the development branch, you should make them related.  If you don't, and probably care more about getting a clean directory tree without translations stuff in it, then create a fresh branch.
[09:49] <fta2> but it's populated by a script, translating upstream xslt files into gettext
[09:50] <fta2> so i don't want lp to export to that branch
[09:50] <jtv> fta2: then by all means create a fresh branch.  You'll have to create it on your local machine, then push it to launchpad.
[09:50] <fta2> i will have to write another converter to recreate xslt files
[09:51] <fta2> jtv, a new branch with just an empty commit?
[09:51] <jtv> Yes.
[09:52] <fta2> jtv, ok. any location? i remember something about a limitation to the user dir... i want a team branch at the end
[09:52] <jtv> fta2: you personally have to be the owner in order to set it; you can transfer it to a team later.
[09:52] <jtv> (Something we still have to fix, but since there's a workaround, it's not quite as urgent as other stuff)
[09:53] <jtv> You'll want to push it into the project, but there's no actual requirement to do that.
[09:55] <jtv> fta2: the branch can't be stacked on another branch for the exports to work, but the export will automatically un-stack it for you if needed.
[09:56] <fta2> looks overly complicated (and undocumented)..
[10:02] <jtv> fta2: well the unstacking is automatic so there's no particular need to document it.  I only mentioned it because you seemed familiar enough with bzr that it might interest you.
[10:03] <fta2> jtv, i meant, the export to a dedicated branch
[10:04] <jtv> fta2: it's very brief (has to be, given how much there is to document) but the basics are here: https://help.launchpad.net/Translations/YourProject/Exports
[10:15] <fta2> well, it doesn't work. 1 error, invalid value. doesn't like my branch
[10:15] <fta2> jtv, ^^
[10:15] <fta2> i used ~fta/chromium-browser/chromium-browser-exports.head
[10:15] <jtv> fta2: :(    Did it say that when you selected the branch as the export branch!?
[10:15] <fta2> yes
[10:16] <jtv> fta2: I don't see a branch by that name—did you mean chromium-translations-exports.head?
[10:19] <fta2> jtv, https://code.edge.launchpad.net/~fta/chromium-browser/chromium-translations-exports.head  => http://people.ubuntu.com/~fta/chromium/lp-translation-exports.png
[10:20] <jtv> fta2: I'm not sure I follow.  This time you do say chromium-translations-exports.head, but the picture shows chromium-browser-exports.head like you said before.
[10:20] <fta2> oops
[10:21] <jtv> Hence the "no items matched" I guess.
[10:21] <fta2> i initially tried with just chromium in the search box, no answer at all (while i have dozens of chromium branches)
[10:23] <fta2> seems ok now. can i force an initial export? or should i wait for the next daily export?
[10:26] <jtv> fta2: you'll have to wait for the daily run tomorrow.  I can estimate the time it should run, if you have a moment.
[10:26] <fta2> sure
[10:29] <jtv> fta2: should run around 05:00 UTC.  YMMV, standard disclaimer, I know nothing etc.
[10:31] <fta2> jtv, ok, so tomorrow morning for me. thanks
[10:32] <jtv> no worries
[12:00] <wgrant> Is deathrow still broken? Or is the topic outdated?
[12:03] <bigjools> fix0red
[12:04] <wgrant> Thanks.
[12:50] <fta2> bigjools, wgrant: ho, any news about the imminent ppa stats?
[13:02] <zyga> hi, how can I use launchpad API to check if given prerequisite branch for a merge request is already merged?
[13:02] <zyga> I want to improve tarmac so that it can process merge requests produced by bzr-pipeline without any conflicts
[13:02] <zyga> to do that I need to move along the pipeline, branch by branch
[13:03] <zyga> starting with the first branch that has no prerequisite
[13:18] <soren> I've been logged out and awful lot over the last couple of days. Is that a known problem?
[13:19] <wgrant> soren: More recently than last Thursday?
[13:19] <soren> Like 15 minutes ago.
[13:19] <wgrant> DB master swaps caused sessions to vanish twice last week.
[13:20] <wgrant> Hm, I'm still logged in on both edge and production.
[13:21] <soren> I had a tab that I had used less than an hour ago where I was logged in. When I opened another tab, I was logged out.
[13:21] <wgrant> lamont: What's up with platinum, litembilla, lakoocha and iridium?
[13:21] <wgrant> lamont: They've been idle for half an hour, but the queue is large.
[13:22] <soren> I'm positive I've used launchpad in the time in between and about 15 minutes ago, I was suddenly logged out.
[13:22] <soren> Hmm... It only happened in Chrome. My session in Firefox survived.
[13:24] <soren> Weird. Unless of course sessions are sharded and a shard left and my Chrome session was in there and my firefox session was elsewhere.
[13:24] <soren> meh
[13:25] <lamont> wgrant: looking
[13:26] <lamont> 2010-10-11 11:37:21+0000 [-] Processing successful build i386 build of ppatest 0.0.20101011.12.15 in ubuntu hardy RELEASE from builder litembilla
[13:26] <lamont> that's the last litembilla build
[13:26] <lamont> in fact, that's the last mention of litembilla in the log at all
[13:26] <wgrant> Hm.
[13:26] <wgrant> That's a little odd.
[13:26] <wgrant> Has it forgotten about all four?
[13:28] <lamont> lakoocha wins as last seen:  11:47:21 we harvested there.  not quite 2 hours ago..
[13:28] <lamont> so I'm gonna guess they got lost
[13:28] <wgrant> What do the lines after the 'Processing successful [...]' say?
[13:29] <wgrant> It looks like the upload was queued successfully.
[13:29] <lamont> 2010-10-11 11:47:22+0000 [-] Grabbing file: qgis-plugin-grass-common_1.6.0-svn14366~maverick_all.deb
[13:29] <lamont> 2010-10-11 11:47:22+0000 [-] Gathered BinaryPackageBuild 1993835 completely. Moving 20101011-114722-1998458-PACKAGEBUILD-1998989 to uploader queue.
[13:29] <lamont> 2010-10-11 11:47:23+0000 [-] Starting templates build trunk-3881859 for lp:openobject-server.
[13:29] <lamont> oh hahahahahahahahaha
[13:29] <lamont> 2010-10-11 11:47:23+0000 [-] Scanning failed with: 'NoneType' object has no attribute 'content'
[13:29] <wgrant> Aha.
[13:29] <wgrant> Except what.
[13:30] <wgrant> Ah.
[13:30] <wgrant> Hm.
[13:30] <wgrant> But the LFA shouldn't be deleted yet.
[13:30] <wgrant> Hmmm.
[13:31] <wgrant> Aha.
[13:31] <lamont> http://paste.ubuntu.com/510854/
[13:31] <wgrant> Yeah.
[13:31] <wgrant> Fail.
[13:31] <wgrant> I guess restarting b-m will fix it, now that natty has chroots.
[13:32] <lamont> oh
[13:32] <lamont> heh
[13:32] <lamont> I'll get that done
[13:32] <wgrant> And the archive is published now.
[13:32] <wgrant> At least internally.
[13:32] <wgrant> So it should roughly work.
[13:32] <wgrant> (currentseries picks FROZEN, then DEVELOPMENT, then CURRENT, then anything else... so this didn't show up until natty was changed from FUTURE to FROZEN just before it was initialised)
[13:34] <lamont> you'll file the bug?
[13:34] <wgrant> Yeah.
[13:34] <wgrant> Just working out who to blame first.
[13:34] <lamont> because it'd be a shame to hit this with natty+1, too
[13:34] <wgrant> Translations, Registry, or Soyuz... that is the question.
[13:34] <lamont> and slapped over the head
[13:34] <wgrant> Looks good. Thanks.
[13:35] <lamont> blame translations - soyuz shouldn't get all the fun
[13:35] <lamont> :-D
[13:36] <wgrant> Indeed. I'm sure they'll be happy enough to fob it off to us if they think I'm wrong.
[13:55] <bigjools> wgrant, lamont: translations for sure - their build behaviour class needs to check for stuff like that, although it could be argued that it can be factored away in the buildmaster itself.  But that would not remove the behaviour's responsibility to check, still.
[13:55] <wgrant> bigjools: Yeah, bug #658318
[14:00] <lamont> affected: EVERYONE
[15:58] <cr3> how can I set someone as administrator of a team when there are no administrator yes/no radio buttons when attempting to modify the person within the team?
[15:58] <cr3> I looked at the following help page: https://help.launchpad.net/Teams/CreatingAndRunning
[15:58] <cr3> but the screenshot doesn't contain the Administrator row I'm seeing on Launchpad
[15:59] <cr3> I can unset someone who is an administrator, but I can't set someone as an administrator
[16:00] <cr3> is this a bug or feature?
[16:20] <magelan> Hello
[16:20] <magelan> I'm trying to report a bug on Launchpad but I get a Timeout error
[16:22] <magelan> Error ID: OOPS-1745K1887 if it can help
[16:26] <maxb> cr3: I think the permissions may be a bit silly - such that Administrators can remove other Administrators, but only the team Owner can bless new Administrators
[17:10] <czajkowski> what is the difference in a team and a project when setting up one on launchpad ?
[17:11] <oubiwann> czajkowski: a project is the place where code lives, where bugs get filed, etc.
[17:11] <czajkowski> oubiwann: ok so a team is what I need, thank you
[17:11] <oubiwann> czajkowski: a team is used where more than one person is working on a project
[17:11] <czajkowski> oubiwann: that clears that up
[17:12] <czajkowski> thanks
[17:12] <oubiwann> so they can all get access to branches saved in the team namespace, have upload access to PPA, etc.
[17:12] <oubiwann> okay, cool
[17:12] <oubiwann> also, teams can have mail lists created for them
[18:45] <ronnie_vd_c> is it possible with launchpadlib to reject propsed members of a team?
[18:46] <ronnie_vd_c> with launchpad.people['teamname'].proposed_members i already got the members
[18:46] <ronnie_vd_c> but i cant find any method to decline these persons
[18:58] <jelmer> ronnie_vd_c: As far as I can tell that is not (yet) possible.
[18:58] <ronnie_vd_c> ok, thx jelmer. Any idea how to decline 113 proposed members the quickest?
[19:03] <maxb> Write support for declining via the API. Submit a merge proposal. Wait for it to be deployed. Use the API? :-)
[19:04] <ronnie_vd_c> step1, learn programming ;)
[19:04] <ronnie_vd_c> step2, got familiar with the lp code...
[19:05] <ronnie_vd_c> i guess the easiest way atm is to do it all by hand
[19:17] <LinuxJedi> grrr... these hard lockups are really hurting :(
[19:46] <warp10> Does anybody knows if daily builds still have problems with maverick? I just tried to build a package and got a weird message about a missing .orig.tar.gz file
[19:55] <maxb> warp10: paste a link to the message and we can probably interpret :-)
[19:56] <warp10> maxb: http://launchpadlibrarian.net/57458643/buildlog.txt.gz
[19:58] <maxb> Oh, recipes don't support .orig.tar.gz builds yet
[19:59] <maxb> Only the native packaging style
[19:59] <maxb> So, the first thing you might want to do is change '3.0 (quilt)' to '3.0 (native)', possibly making other changes to the packaging as a consequence
[20:00] <warp10> maxb: Good point. Anyway, I am wondering why the same recipe works on lucid and karmic, see: http://launchpadlibrarian.net/57458680/buildlog.txt.gz
[20:00] <maxb> erm, well that's certainly confusing
[20:01] <maxb> urgh
[20:02] <maxb> Why does lucid-cat-lpbuildd have bzr-builder 0.2+bzr78, but maverick-cat-lpbuildd have 0.3.1 ?
[20:03] <warp10> maxb: no idea. Didn't noticed that difference
[20:03] <maxb> warp10: So, I'm inclined to pin the difference on a completely different version of bzr-builder being in use
[20:04]  * warp10 looks for the bzr-builder changelog
[20:05] <warp10> maxb: ah, looks like bzr-builder in the maverick builder is not taken from the ubuntu archive
[20:07] <maxb> warp10: Actually, the key is in these lines of logging in lucid:
[20:07] <maxb> dpkg-source: info: source format `3.0 (quilt)' discarded: no orig.tar file found
[20:07] <maxb> dpkg-source: info: using source format `1.0'
[20:08] <maxb> v.s. in maverick:
[20:08] <maxb> dpkg-source: error: can't build with source format '3.0 (quilt)': no orig.tar file found
[20:08] <maxb> So the answer is that maverick's dpkg behaviour is stricter and picks up on broken packaging that lucid's tolerated and worked around
[20:10] <warp10> maxb: I suppose reading the dpkg changelog since lucid to maverick would take me the whole night :)
[20:10] <warp10> maxb: anyway, your explanation sounds reasonable. I'll try again, after switching to 3.0 (native)
[20:10] <warp10> maxb: thank you!
[20:13] <nevans> according to https://wiki.ubuntu.com/DistributedDevelopment/Documentation/GettingTheSource, I've tried to `bzr branch lp:ubuntu/screen` and lp:ubuntu/byobu, but I'm getting errors.
[20:13] <nevans> "Unexpected Zope exception: CannotHaveLinkedBranch: <Distribution \'Ubuntu\' (ubuntu)> cannot have linked branches."
[20:14] <nevans> Am I missing something? (is this the correct channel to ask?)
[20:17] <maxb> nevans: Yes, it's the correct channel
[20:18] <maxb> I would have expected those commands to work
[20:18]  * maxb tries
[20:18] <maxb> nevans: oh
[20:18] <maxb> I know why this isn't working
[20:18] <nevans> :)
[20:19] <maxb> lp:ubuntu/screen is resolving to lp:ubuntu/natty/screen, but the natty branches haven't been created yet
[20:19] <nevans> maxb: I did notice that I could get what I wanted via lp:ubuntu/{lucid,maverick}/screen
[20:48] <niemeyer> Hey there
[20:49] <niemeyer> Is there any known timeout issues with LP now?
[20:49] <niemeyer> Trying to add someone to a team for the last 2h or so without success
[20:49] <niemeyer> (timeout with "Loading results failed")
[21:51] <thumper> niemeyer: there have been some fallout from the postgresql 8.4 upgrade with some old fast queries getting slower
[21:51] <thumper> niemeyer: best to file a bug
[21:52] <niemeyer> thumper: Aw, thanks
[21:54] <niemeyer> thumper: Probably not.. was just talking to mwhudson, which suggested using the non-AJAX page, and that worked very fast.
[21:54] <thumper> niemeyer: ok
[21:55] <wgrant> There were other timeout issues ~8 hours ago.
[21:55] <wgrant> Normally fast pages were timing out for a few minutes.
[21:55] <wgrant> Not sure if that's related.
[21:57] <mwhudson> it's because the ajax interface always searches
[21:57] <mwhudson> (it turns out)
[22:02] <soren> How does one choose to use the non-AJAX page?
[22:03] <wgrant> Navigate manually to +addmember.
[22:03] <wgrant> Or disable JS.
[22:04] <mwhudson> or middle click
[22:04] <wgrant> True.
[22:04] <soren> Aha!
[22:05]  * soren was waiting for something like that :)
[23:17] <achiang> i've an API question, regarding source_package_publishing_history. it has a date_published attribute, but i can't seem to figure out a way to learn *who* published it on that date
[23:18] <achiang> package_[creator|signer] only tell me who initially created/signed the package in the pocket
[23:18] <wgrant> achiang: That's all that's recorded at the moment.
[23:19] <wgrant> Partly because the command-line tools used by archive admins don't know who is making the change.
[23:19] <achiang> oh. ouch. :(
[23:19] <wgrant> Yes.
[23:19] <achiang> that won't do very well for my tool that tries to figure out if you've done work in a PPA in the past week.
[23:26] <achiang> how does the +archive page figure out who the "Uploader" is?
[23:26] <wgrant> achiang: package_signer.
[23:27] <achiang> hm
[23:33] <achiang> wgrant: thanks, i was seeing a really stupid error. i got 'next' and 'continue' confused in python.
[23:33] <achiang> keying off package_signer does what i want. and python's next() doesn't do what one thinks it might. :-/
[23:33] <wgrant> Hah.
[23:34] <achiang> vim confused me too. it highlighted "next" as if it was special somehow
[23:35] <mwhudson> it's a builtin
[23:39] <popey> https://code.edge.launchpad.net/projects/?text=apt
[23:39] <popey> is that how we present search results now?
[23:39] <popey> as a massive cloud of random words?
[23:40] <popey> (with no descriptions)
[23:44] <elmo> popey: https://edge.launchpad.net/projects/+index?text=apt
[23:45] <popey> now thats much nicer
[23:45]  * popey wonders what maze of twisting paths led him to that tag cloud hell
[23:46] <popey> thanks
[23:46] <popey> https://code.launchpad.net/ -> apt -> find a project
[23:46] <popey> (was looking for the code behind apt.ubuntu.com )
[23:53] <lifeless> popey: our search story is hugely fragmented.
[23:53] <lifeless> https://dev.launchpad.net/LEP/Search
[23:55] <popey> lifeless: ok, i would be interested to know which of those use cases/stories the tag cloud fits :)
[23:55] <lifeless> popey: well the point is I think we'd benefit by having a cohesive story, searching on tags is one aspect
[23:56] <popey> sure
[23:57] <popey> https://code.edge.launchpad.net/ the word 'tag' doesn't appear anywhere on the page I used to search though.
[23:57] <lifeless> yeah
[23:57] <popey> 'find a project' to me says 'look for projects with $searchterm in the name/description'
[23:57] <lifeless> like I say, its all fragmented
[23:57] <popey> ok
[23:57] <popey> I guess I don't need to file a bug about this? or should I?
[23:58] <lifeless> up to you
[23:58] <lifeless> I don't think it will be acted on in the near term, and I think we'll work comprehensively on it in the long term.
[23:59] <popey> if you don't mind I'll file it or I'll forget it