[00:07] <thumper> towski: there is an RSS feed
[00:07] <thumper> towski: go to the person's code page
[00:08] <thumper> towski: there is a link there for the revision feed for the person, you should be able to see the link in the browser RSS support
[00:08] <towski> ah ok awesome
[00:08] <towski> thanks
[00:27] <CynthiaG> Repeat from 1 hour ago: ~codedread gave me trunk writing access to the Scour project as part of the team Scouring Pads (LP ID: ~scouring), and Launchpad is saying "Updating branch, will take a few minutes" for the trunk. However, it's been an hour and a half now. Is something up with Launchpad?
[00:28] <CynthiaG> [Update: It's been 2:30 h now]
[00:36] <thumper> CynthiaG: hmm...
[00:37] <thumper> CynthiaG: yes I think we have a bug somewhere
[00:37] <CynthiaG> I do have bug supervisor permissions though
[00:37] <thumper> CynthiaG: is launchpad showing the lastest revision for that branch?
[00:37] <CynthiaG> It is showing the lastest; ~codedread hasn't committed any code lately
[00:37] <thumper> when was the last update?
[00:38] <CynthiaG> and I couldn't push a change (it's a Python file, so I just added a line with # [a comment] to test)
[00:38] <CynthiaG> The last update was 4 weeks ago
[00:38] <CynthiaG> $ bzr push lp:scour
[00:38] <CynthiaG> bzr: ERROR: Cannot lock LockDir(lp-69481744:///~codedread/scour/trunk/.bzr/branchlock): Transport operation not possible: readonly transport
[00:38] <thumper> CynthiaG: ah ha
[00:38] <thumper> CynthiaG: you need to do a bzr launchpad-login
[00:38] <CynthiaG> Did that
[00:39] <CynthiaG> so I could write to my branch
[00:39] <thumper> hmm...
[00:39]  * thumper looks at trunk
[00:39] <CynthiaG> I think Launchpad is stuck updating the permissions. Formerly, ~codedread was the owner, but ~codedread said that ~scouring is now the owner, and asked me to test if I could write to the trunk.
[00:39] <thumper> CynthiaG: why do you think you have rights to edit the branch?
[00:40] <thumper> ~codedread is still the owner AFAICS
[00:40] <CynthiaG> ~codedread sent me a mail through Launchpad saying so, and I got a membership notice for Scouring Pads
[00:40] <CynthiaG> Hm. So ~codedread might have messed up a little in changing the owner of the branch?
[00:40] <thumper> CynthiaG: but the trunk branch is still owned by ~coddread
[00:41] <thumper> https://code.edge.launchpad.net/~codedread/scour/trunk
[00:41] <CynthiaG> Perhaps this is the change that Launchpad is processing, because seriously the code hasn't been touched in weeks
[00:42] <thumper> CynthiaG: no, it doesn't work that way
[00:42] <CynthiaG> The permission/ownership change
[00:42] <CynthiaG> Ah ok
[00:42] <CynthiaG> I'm stumped then
[00:42] <thumper> when was the ownership supposedly changed?
[00:43] <CynthiaG> thumper: 16:45:02 GMT-4, or about 3 hours ago now
[00:44] <thumper> CynthiaG: we'll I'd say something went wrong with the renaming
[00:44] <thumper> where renaming == ownership of trunk
[00:44] <CynthiaG> I'll recontact ~codedread then, thanks for taking the time to investigate this
[00:45] <thumper> np
[00:47]  * thumper wonders of the intent of ~codedread, was it "coded read" or "code dread"
[00:48] <CynthiaG> I don't know :) I think it's code dread
[04:21] <CynthiaG> https://code.launchpad.net/~louis-simard/scour/rework  "Updating branch"... has been for 7 minutes now. Usually branch updates take 1 minute, and exceptionally 2. The trunk for Scour is still frozen from 6 hours ago. I think something's really up now.
[04:47] <CynthiaG> [Repeat from 26 min ago] https://code.launchpad.net/~louis-simard/scour/rework  "Updating branch"... has been for 33 minutes now. Usually branch updates take 1 minute, and exceptionally 2. The trunk for Scour is still frozen from 6 hours ago. I think something's really up with Launchpad...
[04:50] <spm> CynthiaG: looking...
[04:50] <CynthiaG> spm: Thanks
[04:55] <thumper> spm: does it have next_mirror_time not null?
[04:55] <spm> thumper: haven't tried the DB yet - was still looking logs
[04:55] <thumper> spm: it'll be the db
[04:55] <spm> hookay, ta
[04:57] <thumper> spm: I think there is some code path calling requestMirror
[04:57] <thumper> spm: which doesn't make sense for hosted branches any more
[04:57] <thumper> spm: I should update the method to barf and run the test suite
[04:57] <spm> :-)
[04:59] <spm> thumper: https://pastebin.canonical.com/33277/ ?
[04:59] <spm> oh yuk. formatting hell.
[05:00] <spm> next_mirror_time is a null by the look of it
[05:00] <spm> last mirroed 2010-06-10 03:07:04.337808
[05:00] <thumper> spm: better formatting next time plz
[05:01] <spm> truly, not sure what happened there
[05:01] <thumper> spm: can you paste again, I need to check other attributes
[05:02] <spm> thumper: https://pastebin.canonical.com/33278/ better
[05:02] <thumper> ta
[05:03] <thumper> ok, it thinks there are pending writes as the last scanned id differs from the last mirrored id
[05:05] <CynthiaG> For the record, I did just try to commit something, but I don't think ~codedread committed anything to the trunk. What he did was to change the trunk's ownership from himself to a team called Scouring Pads.
[05:05] <thumper> spm: can you do a 'select branchjob.*, job.* from branchjob, job where branchjob.job = job.id and branchjob.branch =352900' ?
[05:05] <spm> thumper: https://pastebin.canonical.com/33279/
[05:06] <thumper> actually it actually looks like it hasn't been scanned from an hour ago
[05:06]  * thumper sighs
[05:08] <thumper> spm: actually this appears to be a scan issue
[05:08] <thumper> spm: back to the logs
[05:08] <spm> heh
[05:08] <spm> thumper: there must be some way we can blame mwh for this tho surely?
[05:09] <spm> no bzrsyncd hung processes fwiw
[05:10] <thumper> 2010-06-10 03:07:15 ERROR   Job execution raised an exception.
[05:10] <thumper>  -> http://launchpadlibrarian.net/50049410/rabeY1Z39czhtbmsxFBVMfGBvUu.txt (CHKInventoryRepository('
[05:10] <thumper> lp-internal:///~codedread/scour/trunk/.bzr/repository')
[05:10] <thumper> is not compatible with
[05:10] <thumper> KnitPackRepository('lp-internal:///~louis-simard/scour/rework/.bzr/repository')
[05:10] <thumper> CynthiaG: the branch that you are stacked upon has been upgraced
[05:10] <thumper> upgraded
[05:10] <CynthiaG> Great
[05:10] <thumper> you should just be able to say upgrade on your branch
[05:10] <thumper> and it should just work again
[05:11] <CynthiaG> What would I need to do to upgrade my branch without losing commits? Just 'bzr upgrade' in my local version of the branch?
[05:11] <thumper> CynthiaG: there is a button on the launchpad page
[05:11] <thumper> well, a link I think
[05:11] <thumper> near the bottom
[05:12] <thumper> CynthiaG: you should also upgrade your local copy
[05:12] <CynthiaG> Aha
[05:12] <thumper> although something seems wrong with lp:scour
[05:13] <CynthiaG> The branch lp:scour is under format 6
[05:13] <thumper> it says it is 2a
[05:13] <CynthiaG> Actually 6 is what the page for lp:scour says
[05:13] <thumper> the page is wrong
[05:13] <thumper> you've just reminded me of the other bug
[05:13] <CynthiaG> Awesome :(
[05:13] <thumper> the upgrade process is one of the places calling the wrong method
[05:14] <thumper> if you upgrade your branch
[05:14] <thumper> it should be fine
[05:14]  * thumper crosses fingers
[05:14] <CynthiaG> I did upgrade my branch just now, with the link on my branch page and 'bzr upgrade'
[05:14] <thumper> ok
[05:14] <CynthiaG> However, only ~codedread would have access to upgrade the trunk to unfreeze things
[05:14] <CynthiaG> if applicable
[05:14] <thumper> CynthiaG: trunk is upgraded
[05:15] <thumper> it is just showing that it isn't
[05:15]  * thumper tweaks
[05:17] <thumper> showing 2a now
[05:17] <thumper> although needs to be tweaked at the db to remove the next_mirror_time
[05:18]  * thumper looks at the other branch
[05:19] <thumper> CynthiaG: you branch upgrade is in progress
[05:19] <thumper> I'll check on it later
[05:19]  * CynthiaG nods
[05:19] <CynthiaG> Thanks a lot for your time by the way
[05:20]  * thumper goes to make some fud
[05:52] <thumper> CynthiaG: there is a problem with your branch upgrade
[05:52] <thumper> CynthiaG: the simplest solution would be to rename the current branch on launchpad so we can track down the problem
[05:53] <CynthiaG> Is there anything I can do to fix the problem?
[05:53] <thumper> CynthiaG: upgrade your local repo to 2a
[05:53] <thumper> CynthiaG: then repush your local branch
[05:53] <CynthiaG> Did
[05:53] <CynthiaG> ok
[05:53] <thumper> CynthiaG: I don't think there is anything you can do with the LP branch
[05:53]  * thumper dashes again
[05:57] <CynthiaG> renamed the old rework to rework-2, created rework, pushing to it now
[05:57] <CynthiaG> push done, it didn't complain about repository incompatibilities
[08:59] <netshine> good morning all, i have some question
[08:59] <netshine> when i finish translating some program, why its still not on 100%?
[09:00] <netshine> and the other part is on "newly translated in launchpad"
[10:08] <FullFlannelJacke> Why are so many i386 build machines disabled?
[10:08] <wgrant> Argh, not again.
[10:08] <cody-somerville> Its already being worked on.
[11:13] <bigjools> builders are back
[11:21] <fta> there are plenty of actions i can no longer do in edge, because of timeouts
[14:38] <vish> hi, we setup milestones for maverick , but are now not sure how to close the lucid milestones. could someone mention how it is to be done? > https://launchpad.net/hundredpapercuts/+milestones
[14:39] <vish> the problem is , when we try to set a milestone for the maverick , we can still see the lucid ones
[15:15] <thekorn> vish, not sure if I understand your question correctly, but you can deactivate a milestone,
[15:15] <thekorn> un-tick the "active" control on the /+edit page
[15:16] <thekorn> like https://edge.launchpad.net/hundredpapercuts/+milestone/lucid-round-10/+edit
[15:17] <vish> hmm , i dont have the access to that page :s
[15:17] <asac> hola ... whats the process for getting a new bugzilla tracker enabled in launchpad?
[15:17] <asac> just file a bug against malone or a question?
[15:18] <vish> thekorn: are you able to access that link/page?
[15:18] <thekorn> vish, no, but the project owner should be able to access this page
[15:19] <vish> hmm , weird , i can access the maverick page :(
[15:21] <thekorn> vish, sorry, don't know what's going on there, but there seems to be one difference, you are release manager of the maverick series, but not of the lucid one
[15:22] <vish> yeah , might be the cause :s
[15:23] <mwhudson> asac: https://bugs.edge.launchpad.net/bugs/bugtrackers/+newbugtracker
[15:40] <asac> mwhudson: thx
[16:36] <vish> thekorn: yeah , the release manager was the blocker . fixed thanks.
[16:45] <barry> hi folks, are there any soyuz admins around?  noodles775 or bigjools perhaps?
[16:45] <noodles775> what's up barry?
[16:46] <barry> noodles775: hi.  i'm trying to figure out some build problems.  could you do me a favor and bump up the priority of a rebuild request?
[16:46] <noodles775> Sure... but do you know you can use pbuilder to diagnose those locally?
[16:46] <barry> noodles775: yeah, but the problem is it works locally :)
[16:47] <noodles775> oh, can you also point me to the log of the failure?
[16:47] <bigjools> barry: URL to your build pls :)
[16:47] <barry> bigjools: https://edge.launchpad.net/~barry/+archive/py27stack/+build/1782546
[16:48] <bigjools> barry: how long does it take to build?
[16:48] <barry> noodles775: http://launchpadlibrarian.net/50044452/buildlog_ubuntu-maverick-i386.distribute_0.6.10-4ubuntu2~ppa5_FAILEDTOBUILD.txt.gz
[16:48] <barry> bigjools: it should be fairly quick, it's just a python package
[16:48] <noodles775> I've updated the score.
[16:48] <noodles775> shoud build in 6mins
[16:48] <bigjools> "python-sphinx: Depends: python-jinja2 (>= 2.1) but it is not going to be installed"
[16:49] <barry> noodles775, bigjools there is an apparent build dep circularity i'm trying to work out, but debtree doesn't indicate the circularity.  mvo and i are looking at why this is happening
[16:49] <bigjools> ok
[16:49] <barry> bigjools: yep.  it *seems* like there's a loop: python-setuptools -> python-sphinx -> python-jinja2 -> python-setuptools
[16:50] <barry> bigjools: but i can't see how that should possibly work in a normal archive rebuild.  mvo thinks that my python-defaults package might be confusing things
[16:50] <noodles775> barry: can you let me know when you figure out why it works using a pbuilder environ, but not on the PPA builders?
[16:51] <barry> noodles775: sure :)  i suspect pebkac
[16:51] <barry> noodles775: thanks for the bump btw
[16:51] <noodles775> np :)
[16:52] <barry> noodles775, bigjools oooh, pretty animation!
[16:53] <bigjools> o_O
[16:54] <noodles775> Night all!
[16:54] <barry> noodles775, bigjools okay, same failure.  which does tell me something useful.  i'm going to test mvo's theory
[16:54] <barry> noodles775: night, and thanks!
[16:54] <barry> bigjools: thanks
[16:55] <bigjools> np
[17:46] <fta> can i see -security & -updates using lp.distributions['ubuntu'].main_archive.getPublishedSources()?
[18:03] <mwhudson> fta: yes, i think so
[18:03] <mwhudson> you can filter by pocket if you want
[18:06] <fta> mwhudson, yep, seems to work fine: http://people.ubuntu.com/~fta/ppa-dashboard/chromium-daily.html
[18:07] <fta> i wanted to add the arches too but there's probably too much stuff on the page already
[19:56] <kb9vqf> Any idea what "format '1.0' is not permitted in lucid" would refer to?
[19:56] <kb9vqf> That came from a local PPA rejection Email
[19:57]  * kb9vqf doesn't know where to start troubleshooting unfortunately
[20:06] <idnar> kb9vqf: at a guess, that's referring to the source package format (as in dpkg-source)
[20:06] <idnar> kb9vqf: see the man page for more details
[20:06] <kb9vqf> OK, I'll look
[20:07] <idnar> I'm not sure of the details as they relate to Launchpad / Ubuntu though
[20:08] <leighman> hiya, cc by-nc-sa is not suitable for free use of Luanchpad, is that right?
[20:22] <stefanlsd> using lplib, i have a bug_task object, but am struggling to get the bug id.  I see thats a property of bug object, and bug_task could return bug_link, but not sure how to use that to get the id then. any suggestion?
[20:28] <stefanlsd> launchpad.bugs[link].id works
[20:28] <thekorn> stefanlsd, just use task.bug.id
[20:29] <thekorn> stefanlsd, like http://pastebin.ubuntu.com/447913/
[20:30] <antileet> Hi, I am not able to upload to my ppa
[20:31] <antileet> I am able to run debuild and generate the "changes" file properly, but if I run dput, it uploads but I am not seeing anything on my ppa
[20:31] <antileet> This is my debian folder http://github.com/ninjagod/Screenlapse/tree/master/debian/
[20:32] <antileet> Unfortunately I am working on a different computer and cannot sign packages with my old key so I created a new key for my backup id ad added it to launchpad
[20:32] <antileet> and I used that email address in the changelog and tried to sign using that, could that be causing the problem?
[20:34] <stefanlsd> thekorn: heh. works. thanks. i had a really long way round
[20:39] <stefanlsd> is there a way to download files (attachments from lp) using wget or something. I see there is file handling code, but wget in this case would be better. my url is https://api.staging.launchpad.net/1.0/bugs/474917/+attachment/988668
[20:39] <stefanlsd> thanks ubot5 :)
[20:39] <stefanlsd> hehe
[20:40] <stefanlsd> wget gives unauthorized
[20:40] <thekorn> just use the python methos to save this file
[20:41] <stefanlsd> thekorn: kk. thanks.
[20:41] <thekorn> e.g. write the content of this attachment object to a local file
[20:52] <oojah> Which component of launchpad should I file questions/bugs against when code imports are failing?
[21:12] <maxb> oojah: launchpad-code, but first, which import?
[21:14] <maxb> antileet: Most likely your signature is not correct. Verify that your .changes file really is signed, and that the key it's signed with *is* registered with your Launchpad accunt
[21:14] <maxb> *account
[21:17] <antileet> maxb, there is a gpg signature at the end, but I don't know which key it's signed with
[21:18] <antileet> how do I find that out (sorry, I'm new)
[21:18] <maxb> antileet: gpg --verify foo.changes
[21:19] <antileet> maxb, the RSA key and email address are both verified by launchpad
[21:19] <maxb> check the key-id against the list of key ids appearing on your launchpad profile page
[21:25] <antileet> maxb, it's the same
[21:25] <antileet> does it take some time?
[21:25] <maxb> 5 minutes
[21:25] <antileet> this is the second key and I registered it an hour go
[21:25] <antileet> okay
[21:25] <antileet> lemme try again. hate that I have to add to the changelog every time I update
[21:25] <maco> how do we find hardware profiles?
[21:26] <maco> there used to be a spot in our lp profiles that showed hardware info we'd uploaded from ubuntu's checkbox thingy. where'd that go?
[21:26] <beuno> maco, API only
[21:26] <maco> bahh
[21:26] <beuno> I don't think it was ever exposed on the UI
[21:26] <maco> it was
[21:26] <maco> you used to be able to click on and download the tarballs
[21:27] <maco> or maybe they were txt.gz
[21:27] <maco> some sort of files
[21:27] <beuno> maybe 2 years ago?   I don't remember them every being there, so maybe it was before my time
[21:27] <antileet> maxb I build my .changes file using "debuild -S -sa" is that the appropriate command to use?
[21:27] <maco> possibly
[21:28] <maco> but bahhh this means unless i go do programming and fight with python for a few hours, i cant compare my hardware with someone else's on a bug
[21:28] <beuno> I've seen scripts around to play with this
[21:28] <beuno> but I don't know the specifics
[21:29] <maxb> antileet: yes
[21:29] <antileet> maxb, one last question: no matter what error my rules file, install etc might have it'll still send me an email that it's failed right?
[21:30] <antileet> I need to figure out where the error is first :\
[21:30] <maxb> it should send you an email when it accepts an upload, too
[21:32] <oojah> maxb: Sorry, got moved away from the computer. The import is a mercurial import: https://code.edge.launchpad.net/~mosquitto-dev/mosquitto/trunk
[21:33] <antileet> maxb, in the worst case, can I run pbuilder build ../foo.dsc and get a deb file and distribute that instead?
[21:33] <maxb> oojah: Hmm. I know nothing about the guts of bzr-hg, but as it seems to be exploding within bzr-hg rather than the Launchpad import system, I'd probably file that against bzr-hg itself
[21:34] <maxb> You can't distribute .deb files you build via PPAs
[21:34] <antileet> okay. but I can distribute them standalone right?
[21:34] <oojah> maxb: Ok, thanks for your help.
[21:35] <maxb> oojah: Although, bzr-hg seems to work branching that locally
[21:36] <antileet> maxb, I'll try thatfor now. thanks for your help
[21:36] <maxb> oojah: It might be worth reviewing recently closed bug reports for bzr-hg (since it seems to work using bzr-hg trunk)
[21:37] <maxb> Also, maybe it would be informative to try a clean import into launchpad... let me try registering another import
[21:43] <maxb> oojah: https://code.edge.launchpad.net/~maxb/mosquitto/trunk succeeded
[21:43] <maxb> So, I suppose it is some bug in bzr-hg relating to the current state of the branch
[21:45] <oojah> Ok
[21:46] <oojah> I haven't found any related bugs.
[22:39] <CynthiaG> The trunk branch of Scour is still updating:  https://code.launchpad.net/~codedread/scour/trunk  as last reported yesterday afternoon. Looks like that branch is completely frozen too.
[22:40] <CynthiaG> Should I ask ~codedread to rename trunk to trunk-2 and make a new trunk?
[22:56] <maxb> CynthiaG: I'd suggest filing a question on launchpad-code asking for an admin to fix the existing branch
[23:00] <CynthiaG> maxb: Done, thanks