[00:07] <RainCT> Hi
[00:08] <RainCT> There seems to be some problem with translations.edge.launchpad.net/gnome-activity-journal/trunk/+link-translations-branch, it doesn't find the branch ~gnome-zeitgeist/gnome-activity-journal/trunk, while trunk/+linkbranch does show it
[00:18] <mtaylor> hey all ... I've got an issue pushing a bzr branch to launchpad - it says I've got a lock, but break-lock doesn't remove it
[00:23] <spiv> mtaylor: odd, which branch?
[00:23] <mtaylor> spiv: lp:~mordred/libdrizzle/pandora-build
[00:23] <spiv> mtaylor: and you've tried 'bzr break-lock lp:~mordred/libdrizzle/pandora-build' ?
[00:23] <mtaylor> spiv: yup
[00:23] <mtaylor> spiv: http://pastebin.flamingspork.com/3789
[00:24] <mtaylor> spiv: ass... that's not the right lines...
[00:24] <mtaylor> spiv: http://pastebin.flamingspork.com/3790
[00:25] <spiv> break-lock doesn't prompt you to remove the lock?
[00:26] <spiv> And the error is pretty weird too, that's not a regular 'cannot lock' error.
[00:26] <mtaylor> spiv: yeah. I'm not sure what's up with that
[00:26]  * spm pokes into the filesystem....
[00:26] <mtaylor> spiv: it's not huge - I just pushed to a different branch... mainly pointing it out in case it's an intersting thing for you guys
[00:28] <spm> spiv: https://pastebin.canonical.com/26125/ ??
[00:29] <mtaylor> "You do not currently have access to the pastebin."
[00:29] <mtaylor> :(
[00:29] <mtaylor> oh - heh. that wasn't intended for me :)
[00:29] <spm> mtaylor: oh. sorry - that's our internal one - force of habit :-)
[00:32] <spiv> mtaylor, spm: that's weird, the lock dir should not be empty
[00:32] <spiv> oh, maybe it should be
[00:32] <spiv> Oh, hmm, so empty means no lock held...
[00:35] <spiv> mtaylor: I don't think your problem is a held lock
[00:35] <mtaylor> spiv: oh, ok
[00:35] <spiv> mtaylor: that error from the smart server is apparently attempting to create .bzr/branch/lock, which is weird; that should always exist once the branch is created.
[00:36] <spiv> mtaylor: could you add -Dhpss to your command line and then pastebin the corresponding part of your ~/.bzr.log ?
[00:37] <mtaylor> spiv: sure
[00:37] <Demophobie> someone here who can help me with lp?
[00:37] <spiv> Demophobie: hopefully :)
[00:37] <Demophobie> The languages of my branch wont be imported to launchpad :(
[00:38] <Demophobie> i changed them the day before yesterday. still no change
[00:38] <Demophobie> ah nvm!
[00:38] <Demophobie> my fault
[00:38] <Demophobie> now i see it
[00:39] <mtaylor> spiv: http://pastebin.flamingspork.com/3791
[00:40] <spiv> mtaylor: do you have any plugins installed?
[00:40] <mtaylor> spiv: yeah
[00:40] <mtaylor> spiv: http://pastebin.flamingspork.com/3792
[00:41] <spiv> mtaylor: that trace merrily does all the right things, it opens the remote branch, inserts the new revisions into the remote repo... then it tries to do BzrDir.create_branch!
[00:41] <mtaylor> spiv: LOVELY!
[00:42] <spiv> mtaylor: hmm, none of those plugins are likely suspects, but try with --no-plugins anyway, just in case?
[00:42] <spiv> mtaylor: (you may need to use bzr+ssh://bazaar.launchpad.net/~mordred/libdrizzle/pandora-build/ rather than the lp:... URL)
[00:42] <mtaylor> spiv: k.
[00:43] <mtaylor> spiv: nope. same thing
[00:44] <spiv> Huh.
[00:45] <spiv> That code path is hit when self.open_branch() on that BzrDir fails with NotBranchError, but that network conversation clearly shows that open_branch earlier succeeded.
[00:46] <spiv> ...but no open_branch attempt immediately before the create_branch call.  Hmm.
[00:49] <spiv> Oh, no, it does the fetch in between.  So that all looks fine, except that somehow the successful open_branch remote call is treated like a NotBranchError.
[00:54] <spiv> mtaylor: I have no idea
[00:55] <spiv> mtaylor: I suspect that if you push over sftp rather than bzr+ssh you'll workaround the bug, but I really don't see how that code can go wrong like that.
[00:55] <spiv> mtaylor: which version of bzr are you using?
[01:25] <mtaylor> spiv: 2.0.3
[01:25] <spiv> mtaylor: Ok.  Please file a bug.  I'm mystified!
[01:26] <mtaylor> spiv: :)
[03:58] <crimsun> hmm
[03:58] <crimsun> -rw-r--r--  1 crimsun crimsun   1415 2010-01-03 22:49 scratchbox2_2.0-3ubuntu1_source.changes
[03:58] <crimsun> sorry
[03:59] <crimsun> should have been accepted at :55, no? ->   2010-01-03 22:53 scratchbox2_2.0-3ubuntu1_source.ubuntu.upload
[04:03] <persia> crimsun: Already "Done".
[04:03] <persia> ( https://launchpad.net/ubuntu/lucid/+queue?queue_state=3&queue_text= )
[04:12] <crimsun> persia: for the past week I've been seeing some really strange processing lag, e.g., I'll upload by :49 and won't see the processing/accept until :00
[04:14] <persia> Odd.
[04:33] <Some_Person> crimsun: I've seen the same lag, but I'm new here and thought that was normal
[05:40] <MFen> i have a branch of a project using bzr, from launchpad (lp:txgenshi)
[05:40] <MFen> i want to put this branch somewhere, so i can refer to it in bugs and make a merge request
[05:40] <MFen> what bzr command is that? :)
[05:41] <persia> MFen: often something like `bzr push lp:~${your-lp-username}/txgenshi\${your-branch-name}`
[05:41] <persia> Err, s/\\/\//
[05:41] <MFen> aha. http://doc.bazaar.canonical.com/bzr.dev/en/tutorials/using_bazaar_with_launchpad.html  agrees with what you just said. ok then
[07:03] <ScottK> Seems somethings just gone off on the soyuz web U/I (at least).  I can't retry package builds now: (Error ID: OOPS-1465D737)
[07:04] <ScottK> Also, I'm pretty sure that build should have come out of depwait on it's own by now.
[07:04] <al-maisan> ScottK: is it because the web UI is timing out>
[07:04] <al-maisan> ?
[07:04] <ScottK> al-maisan: Right, but I've been doing quite a number of retries tonight with no trouble.
[07:04]  * al-maisan looks at the OOPS
[07:04] <ScottK> All of a sudden they fail and also packages that should be coming out of depwait, don't seem to be.
[07:04] <ScottK> Thanks.
[07:05] <al-maisan> hmm .. takes a while to open that page
[07:07] <ScottK> The depwaits I was expecting just arrived.
[07:07] <ScottK> So that's good news.
[07:07] <al-maisan> OK
[07:07] <ScottK> al-maisan: Not sure what you'll get off that page now, since it came out of depwait on it's own
[07:08] <al-maisan> ScottK: fair enough.
[07:08] <ScottK> They landed 10 or 15 minutes later than the normally do.
[07:08] <al-maisan> ScottK: I see .. so, you're fine for the time being?
[07:09] <ScottK> al-maisan: Yes, but I'll need to do some more retries after I sleep for a few hours, so I hope they work ....
[07:09] <al-maisan> ScottK: there were no changes in that area that I am aware off .. so thy should work.
[07:11] <ScottK> OK.  Hopefully it's just a case of 'stuff happens' and it'll be fine tomorrow.
[07:11] <al-maisan> ScottK: the query that caused the OOPS to occur is pretty trivial but took 20 seconds to perform .. might have been a db hiccup
[07:11] <ScottK> Sounds like.
[07:12] <spm> al-maisan: a db hiccup is likely to be evil locking somewhere?
[07:12] <spm> al-maisan: hello/HNY as well btw. :-)
[07:13] <ScottK> al-maisan: Something else to look into (not urgent) is due to the frozen lpia builds in Lucid, there are backports builds for hardy, jaunty, and karmic that can't get a build try on lpia.  It would be nice if that could get fixed.
[07:13] <al-maisan> spm: maybe .. maybe there was a deadlock and the other transaction was the deadlock victim .. can't see it from the OOPS though
[07:13] <al-maisan> spm: .. and hello and an even happier new year to you :)
[07:13] <spm> heh
[07:14] <ScottK> Good night.  I should have been in bed 3 hours ago.
[07:14] <al-maisan> ScottK: OK .. thanks for pointing that out.
[07:14] <al-maisan> ScottK: Good night!
[07:24] <wgrant> al-maisan: Rescoring all 9 builds at https://edge.launchpad.net/ubuntu/lucid/lpia/+builds?build_text=&build_state=pending to -11 will alleviate ScottK's final issue.
[07:25] <wgrant> (the chroot has been removed, so any attempt to dispatch them will fail anyway)
[07:25] <al-maisan> wgrant: thanks, will try that.
[07:31] <al-maisan> wgrant: did that.
[07:31] <al-maisan> ScottK: ^^ hope this helps.
[07:31] <wgrant> al-maisan: Great, thanks.
[07:31] <al-maisan> wgrant: thank you.
[11:48] <bencer> we requested a ppa quota increase through a question, and we were told to request it here, anybody can help ?
[11:48] <bigjools> bencer: yes
[11:49] <bigjools> which question?
[11:49] <bencer> bigjools:  https://answers.edge.launchpad.net/soyuz/+question/93569
[11:50] <bigjools> bencer: ok I already replied to that and asked how much space you want - but tell me now and I'll fix it
[11:50] <bigjools> is 2Gb enough?
[11:50] <bencer> 2G for ebox/1.3 should be enough
[11:50] <bencer> yeah
[11:50] <bigjools> ok done
[11:51] <bencer> bigjools: can we request a ppa removal as well ?
[11:51] <bigjools> yes, please file another question
[11:51] <bencer> ok, we'll do, thank you very much
[11:51] <bigjools> we don't do "proper" removal yet, but we can disable it
[11:52] <bencer> btw, is the ppa access stats on the roadmap ?
[11:52] <bigjools> not really :(  but wgrant did some work on that
[11:53] <bencer> bigjools: is that work public ? or could we have access to the logs somehow ?
[11:54] <bigjools> you can't see the logs unfortunately.  If wgrant pushed his branch up then you can see it
[11:54] <bigjools> s/it/the work/
[11:54]  * wgrant doesn't have much further of significance.
[11:55] <bencer> ok, thanks your help :)
[12:00] <om26er> how can i upload to my ppa?
[12:00] <bigjools> om26er: https://help.launchpad.net/Packaging/PPA
[12:00] <noodles775> Hi om26er, there are instructions on your ppa for the exact dput command too.
[12:03] <om26er_> sorry got disconnected
 om26er: https://help.launchpad.net/Packaging/PPA
 Hi om26er, there are instructions on your ppa for the exact dput command too.
[12:09] <om26er_> where is .dput.cf?
[12:10] <wgrant> om26er_: Why are you trying to edit it? Recent Ubuntu releases have all the necessary configuration already.
[12:10] <wgrant> Ah. Those old docs.
[12:10] <om26er_> wgrant: yes
[12:11] <wgrant> om26er_: Try reading the documentation linked to from the PPA itself. That is less outdated.
[12:11] <wgrant> Hm, they just link to the same place. That sucks.
[12:11] <wgrant> But the dput command is there.
[12:12] <wgrant> Ignore the instructions to edit .dput.cf. That is wrong.
[12:14]  * om26er_ is so confused
[12:15] <om26er_> is this what i should be reading? https://help.launchpad.net/Packaging/PPA/Uploading#Uploading a package to a PPA
[12:16] <wgrant> om26er_: Go to https://launchpad.net/people/+me/+archive, and use the dput command provided there.
[12:16]  * wgrant files a bug about the documentation.
[12:20] <om26er> what comes instead of this? <source.changes>
[12:21] <wgrant> om26er_: That's the <PACKAGE>_<VERSION>_source.changes file that was generated when you built your source package.
[12:23] <om26er> ok
[12:25] <om26er> i have built 3 different packages and none seem to have a .changes file
[12:26] <wgrant> om26er_: How did you build them?
[12:27] <wgrant> It should be generated by debuild when called with the '-S' flag.
[12:27] <om26er> sudo ./configure then sudo make then sudo checkinstall
[12:29] <wgrant> om26er: That does not produce a source package, nor even a binary package that can be particularly safely used. You probably want to have a read of https://wiki.ubuntu.com/PackagingGuide -- that documents the procedure for generating a policy-compliant source package.
[12:31]  * om26er looks into it
[12:32] <om26er> wgrant: is this the exact link https://wiki.ubuntu.com/PackagingGuide/Complete  ?
[12:33] <wgrant> om26er: That's right.
[12:33] <om26er> wgrant: thanx
[14:12] <james_w> E: java3ds-fileloader_1.2.orig.tar.bz2 (from java3ds-fileloader) is in the DB but isn't an orig.tar.gz.  (Probably published in an older release)
[14:12] <james_w> ^ more fallout from the v3 change? (sync-source.py -a)
[14:44] <ivoks> hi
[14:47] <ripps> I have over a dozen old branches from an old ppabot project on Launchpad, is there an easy way to delete them from commandline so I don't have to manually delete all of them over the web interface?
[14:53] <beuno> rockstar, abentley, is deleting branches exported over the API?
[14:53] <beuno> my guess would be that james_w` would of already requested something like that  :)
[14:56] <abentley> beuno: I believe it is not, though poolie suggests jelmer is working on that.
[14:56] <thekorn> it is bug 491944
[14:56] <beuno> abentley, ah, is that what the "commit message" discussion is about?
[14:57] <abentley> beuno: No, I don't think it's related.
[14:57] <jelmer> abentley: There's an approved branch from me that adds support for deleting branches over the API
[14:57] <jelmer> abentley: But launchpadlib doesn't like the fact that the object you have a handle to and call "delete()" on suddenly disappears
[14:57] <beuno> ripps, I think this means "soon on edge"  :)
[14:57] <beuno> thanks jelmer, abentley
[14:58] <jelmer> abentley: So I've waited with landing it until I had the chance to talk to Leonard
[14:58] <jelmer> abentley: (also, this was stuff I
[14:58] <jelmer> did in my spare time, not work :-)
[14:58] <abentley> jelmer: I understand.
[14:59] <beuno> jelmer, spare time?  you don't get anymore of that around here!  ;)
[14:59] <jelmer> :-)
[15:00] <james_w`> thanks jelmer
[15:01] <james_w`> jelmer: you have a traceback for the launchpadlib issue? I've been elbow deep in that code over the weekend
[15:01] <jelmer> james_w: Basically, launchpadlib tries to access the branch after delete() has been called on it
[15:02] <jelmer> so it gets back a 404
[15:02] <jelmer> I can also get you the full traceback if that would help.
[15:03] <james_w`> I get the concept at least
[15:03] <james_w`> I guess there's an issue that you can't make the object kill itself
[15:03] <jelmer> yeah
[15:03] <james_w`>             if http_method == 'post':
[15:03] <james_w`>                 # The method call probably modified this resource in
[15:03] <james_w`>                 # an unknown way. Refresh its representation.
[15:03] <james_w`>                 self.resource.lp_refresh()
[15:04] <james_w`> .delete() is explicitly exported as a delete operation isn't it?
[15:05] <jelmer> yep
[15:05] <jelmer> It's named 'delete' I mean, is there anything else?
[15:05] <james_w`> is it just done with @export, or something like @export_delete_operation
[15:06] <jelmer> I suspect it's just @export, I wasn't aware of the latter
[15:06] <jelmer> will that make a difference on the client side?
[15:07] <james_w`> I don't know
[15:08] <james_w`> it would at least allow us to differentiate client side
[15:08] <james_w`> well, we could have == "delete", but y'know
[15:10] <jelmer> james_w: I'll see if @export_delete_operation makes a difference tonight
[15:10] <jelmer> james_w: Special-casing seems like a bad idea, indeed.
[15:12] <james_w`> export_destructor_operation
[15:12] <james_w`>     """Decorator indicating that an exported method destroys an entry.
[15:12] <james_w`>     The method will be invoked when the client sends a DELETE request to
[15:12] <james_w`>     the entry.
[15:12] <james_w`>     """
[15:13] <james_w`> However, it may not work due to the parameters
[16:16] <Jeeves_> Hi
[16:16] <Jeeves_> I'm trying to upload a package into a PPA
[16:17] <Jeeves_> I want it built for all Ubuntu versions, so I uploaded it multiple times with different ubuntu-versions in the changelog
[16:17] <Jeeves_> Launchpad rejected it, because 'File bitcron_2.0-20091231.02.tar.gz already exists in bitcron'
[16:18] <noodles775> Hi Jeeves_ , have you seen https://help.launchpad.net/Packaging/PPA/BuildingASourcePackage#Versioning
[16:20] <Jeeves_> noodles775: Hmm, thanks.
[16:20] <noodles775> np
[16:20] <Jeeves_> Not a very efficient method, imho, but it'll do
[18:11] <james_w`> al-maisan: hi, still around by any chance?
[18:19] <al-maisan> hello james_w` , how are things?
[18:19] <james_w`> hello al-maisan, good thanks, how about you?
[18:20] <al-maisan> james_w`: doing well, thanks!
[18:20] <james_w`> glad to hear it
[18:20] <al-maisan> .. and happy new year to you!
[18:20] <james_w`> I have a packageset question
[18:20] <al-maisan> OK
[18:20] <james_w`> and to you too :-)
[18:20] <james_w`> I have a person and a source package name
[18:20] <al-maisan> aha
[18:20] <james_w`> and I want to know if LP would accept and upload from that person for that package name in the current series
[18:21] <al-maisan> right.
[18:21] <james_w`> whether that be from packageset, component, or package-specific right
[18:21] <james_w`> is there an existing API call to do this?
[18:21] <al-maisan> I believe so, please let me look quickly.
[18:23] <james_w`> I found isSourceUploadAllowed
[18:23] <james_w`> but the documentation for that suggests it is just packageset based
[18:24] <al-maisan> yes .. but that's package set specific
[18:24] <al-maisan> just a minute .. I know there's such a method but I need to locate it
[18:24] <james_w`> ok
[18:24] <james_w`> I'm putting that together with getPermissionsForPerson
[18:24] <james_w`> but the documentation for that is pretty poor, so it's not clear what sort of permissions you can get
[18:24] <james_w`> I'm checking component and package name from that
[18:25] <al-maisan> james_w`: you'll get all permissions with getPermissionsForPerson()
[18:25] <al-maisan> but it's not very user friendly
[18:25] <james_w`> so put the two methods together and I think I have it, but if you can find a single call that would be perfect
[18:25] <al-maisan> you basically want a yes/no answer
[18:25] <james_w`> ah, I see it can give package_set_name
[18:25] <james_w`> but then I would have to look up the package sets for the package name as well
[18:26] <james_w`> so yeah, a yes/no call would be great
[18:26] <james_w`> like isSourceUploadAllowed
[18:26] <al-maisan> ah .. there's verify_upload()
[18:26] <al-maisan> but that's probably not exported
[18:26] <al-maisan> let me check
[18:27] <al-maisan> james_w`: so, your best bet is to use getPermissionsForPerson() it would seem and look at the permissions you get back
[18:28] <james_w`> http://paste.ubuntu.com/351377/ is what I have currently
[18:28]  * al-maisan looks
[18:30] <al-maisan> james_w`: http://pastebin.ubuntu.com/351379/
[18:31] <james_w`> yeah, not quite the API I want, but that would be usable
[18:31] <al-maisan> that's from lib/lp/archiveuploader/permission.py|176| def verify_upload()
[18:33] <al-maisan> james_w`: .. and then there's trunk/lib/lp/archiveuploader/permission.py|128| def check_upload_to_archive() that ueses it
[18:34] <al-maisan> http://pastebin.ubuntu.com/351381/
[18:34] <james_w`> as long as isSourceUploadAllowed considers team memberships then I think the code I have will work?
[18:34]  * al-maisan is still looking at iot
[18:34] <al-maisan> *it
[18:36] <al-maisan> james_w`: looks reasonable .. but requires a previous publishing record.
[18:36] <james_w`> yes
[18:37] <james_w`> for the script that is using it that's a safe assumption
[18:37] <al-maisan> james_w`: that's good. It should work then.
[18:37] <james_w`> I can't remember LPs rules on new publications, but I can rework it to not fail in that case if/when this script needs to consider those cases
[18:37] <al-maisan> wait a minute
[18:38] <al-maisan> there's an IArchive.canUpload() method but it's not exposed on the LP API
[18:41] <al-maisan> james_w`: so, maybe this is worth a bug report? There really should be one LP API method that you can use to get a yes/no answer.
[18:42] <james_w`> I can do that
[18:43] <al-maisan> That would be good if you could file a bug .. maybe we can even nail it down next week?
[18:43] <james_w`> ah, good point
[18:44] <al-maisan> anyway, it's getting late, have a good night!
[18:47] <james_w`> you too
[19:48] <thumper> morning
[19:51] <mdz> just got a crash on +filebug, Error ID: OOPS-1465ED620
[22:18] <james_w> anyone want to guess what "I: gnuchess [universe] -> gnuchess_5.07-5ubuntu1 [universe].
[22:18] <james_w> not ubuntu: debian
[22:18] <james_w> " is trying to tell me?
[22:18] <james_w> sync-source.py
[22:20] <james_w> oh, it's mass-sync.py, that makes more sense
[22:20] <wgrant> james_w: I believe that's showing the produced binaries.
[22:20] <wgrant> sync-source.py produces such messages.
[22:21] <james_w> yeah, it's the "not ubuntu: debian" error that is unusual
[22:21] <wgrant> Ah.
[22:38] <mirak> hi
[22:38] <mirak> how can I get sources of a particular version ?
[22:38] <mirak> with apt-get source
[22:59] <vadi2> When I look here: https://launchpad.net/~mudlet-makers/+archive/ppa/+builds?build_state=building it shows that a 1.0.4 build of mudlet, ordered eons ago and not necessary anymore, is still pending. I wanted to cancel it, so I clicked on it by that generated an OOPS.
[23:02] <wgrant> vadi2: That looks like a bug.
[23:02] <wgrant> vadi2: The state of that build is somehow corrupted.
[23:10] <vadi2> Yeah.
[23:10] <vadi2> I don't know how and it doesn't matter to me, but I guess it would be nice to remove it