[00:07] Hi [00:08] 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] 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] mtaylor: odd, which branch? [00:23] spiv: lp:~mordred/libdrizzle/pandora-build [00:23] mtaylor: and you've tried 'bzr break-lock lp:~mordred/libdrizzle/pandora-build' ? [00:23] spiv: yup [00:23] spiv: http://pastebin.flamingspork.com/3789 [00:24] spiv: ass... that's not the right lines... [00:24] spiv: http://pastebin.flamingspork.com/3790 [00:25] break-lock doesn't prompt you to remove the lock? [00:26] And the error is pretty weird too, that's not a regular 'cannot lock' error. [00:26] spiv: yeah. I'm not sure what's up with that [00:26] * spm pokes into the filesystem.... [00:26] 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] spiv: https://pastebin.canonical.com/26125/ ?? [00:29] "You do not currently have access to the pastebin." [00:29] :( [00:29] oh - heh. that wasn't intended for me :) [00:29] mtaylor: oh. sorry - that's our internal one - force of habit :-) [00:32] mtaylor, spm: that's weird, the lock dir should not be empty [00:32] oh, maybe it should be [00:32] Oh, hmm, so empty means no lock held... [00:35] mtaylor: I don't think your problem is a held lock [00:35] spiv: oh, ok [00:35] 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] mtaylor: could you add -Dhpss to your command line and then pastebin the corresponding part of your ~/.bzr.log ? [00:37] spiv: sure [00:37] someone here who can help me with lp? [00:37] Demophobie: hopefully :) [00:37] The languages of my branch wont be imported to launchpad :( [00:38] i changed them the day before yesterday. still no change [00:38] ah nvm! [00:38] my fault [00:38] now i see it [00:39] spiv: http://pastebin.flamingspork.com/3791 [00:40] mtaylor: do you have any plugins installed? [00:40] spiv: yeah [00:40] spiv: http://pastebin.flamingspork.com/3792 [00:41] 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] spiv: LOVELY! [00:42] mtaylor: hmm, none of those plugins are likely suspects, but try with --no-plugins anyway, just in case? [00:42] mtaylor: (you may need to use bzr+ssh://bazaar.launchpad.net/~mordred/libdrizzle/pandora-build/ rather than the lp:... URL) [00:42] spiv: k. [00:43] spiv: nope. same thing [00:44] Huh. [00:45] 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] ...but no open_branch attempt immediately before the create_branch call. Hmm. [00:49] 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] mtaylor: I have no idea [00:55] 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] mtaylor: which version of bzr are you using? [01:25] spiv: 2.0.3 [01:25] mtaylor: Ok. Please file a bug. I'm mystified! [01:26] spiv: :) [03:58] hmm [03:58] -rw-r--r-- 1 crimsun crimsun 1415 2010-01-03 22:49 scratchbox2_2.0-3ubuntu1_source.changes [03:58] sorry [03:59] should have been accepted at :55, no? -> 2010-01-03 22:53 scratchbox2_2.0-3ubuntu1_source.ubuntu.upload [04:03] crimsun: Already "Done". [04:03] ( https://launchpad.net/ubuntu/lucid/+queue?queue_state=3&queue_text= ) [04:12] 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] Odd. [04:33] crimsun: I've seen the same lag, but I'm new here and thought that was normal [05:40] i have a branch of a project using bzr, from launchpad (lp:txgenshi) [05:40] i want to put this branch somewhere, so i can refer to it in bugs and make a merge request [05:40] what bzr command is that? :) [05:41] MFen: often something like `bzr push lp:~${your-lp-username}/txgenshi\${your-branch-name}` [05:41] Err, s/\\/\// [05:41] 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] 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:03] https://lp-oops.canonical.com/oops.py/?oopsid=1465D737 [07:04] Also, I'm pretty sure that build should have come out of depwait on it's own by now. [07:04] ScottK: is it because the web UI is timing out> [07:04] ? [07:04] 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] All of a sudden they fail and also packages that should be coming out of depwait, don't seem to be. [07:04] Thanks. [07:05] hmm .. takes a while to open that page [07:07] The depwaits I was expecting just arrived. [07:07] So that's good news. [07:07] OK [07:07] al-maisan: Not sure what you'll get off that page now, since it came out of depwait on it's own [07:08] ScottK: fair enough. [07:08] They landed 10 or 15 minutes later than the normally do. [07:08] ScottK: I see .. so, you're fine for the time being? [07:09] 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] ScottK: there were no changes in that area that I am aware off .. so thy should work. [07:11] OK. Hopefully it's just a case of 'stuff happens' and it'll be fine tomorrow. [07:11] 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] Sounds like. [07:12] al-maisan: a db hiccup is likely to be evil locking somewhere? [07:12] al-maisan: hello/HNY as well btw. :-) [07:13] 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] 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] spm: .. and hello and an even happier new year to you :) [07:13] heh [07:14] Good night. I should have been in bed 3 hours ago. [07:14] ScottK: OK .. thanks for pointing that out. [07:14] ScottK: Good night! [07:24] 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] (the chroot has been removed, so any attempt to dispatch them will fail anyway) [07:25] wgrant: thanks, will try that. [07:31] wgrant: did that. [07:31] ScottK: ^^ hope this helps. [07:31] al-maisan: Great, thanks. [07:31] wgrant: thank you. === noodles775_ is now known as noodles775 === sale_ is now known as sale [11:48] we requested a ppa quota increase through a question, and we were told to request it here, anybody can help ? [11:48] bencer: yes [11:49] which question? [11:49] bigjools: https://answers.edge.launchpad.net/soyuz/+question/93569 [11:50] 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] is 2Gb enough? [11:50] 2G for ebox/1.3 should be enough [11:50] yeah [11:50] ok done [11:51] bigjools: can we request a ppa removal as well ? [11:51] yes, please file another question [11:51] ok, we'll do, thank you very much [11:51] we don't do "proper" removal yet, but we can disable it [11:52] btw, is the ppa access stats on the roadmap ? [11:52] not really :( but wgrant did some work on that [11:53] bigjools: is that work public ? or could we have access to the logs somehow ? [11:54] you can't see the logs unfortunately. If wgrant pushed his branch up then you can see it [11:54] s/it/the work/ [11:54] * wgrant doesn't have much further of significance. [11:55] ok, thanks your help :) [12:00] how can i upload to my ppa? [12:00] om26er: https://help.launchpad.net/Packaging/PPA [12:00] Hi om26er, there are instructions on your ppa for the exact dput command too. [12:03] sorry got disconnected [12:04] om26er: https://help.launchpad.net/Packaging/PPA [12:04] Hi om26er, there are instructions on your ppa for the exact dput command too. === mrevell is now known as mrevell-lunch [12:09] where is .dput.cf? [12:10] om26er_: Why are you trying to edit it? Recent Ubuntu releases have all the necessary configuration already. [12:10] Ah. Those old docs. [12:10] wgrant: yes [12:11] om26er_: Try reading the documentation linked to from the PPA itself. That is less outdated. [12:11] Hm, they just link to the same place. That sucks. [12:11] But the dput command is there. [12:12] Ignore the instructions to edit .dput.cf. That is wrong. [12:14] * om26er_ is so confused [12:15] is this what i should be reading? https://help.launchpad.net/Packaging/PPA/Uploading#Uploading a package to a PPA [12:16] 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] what comes instead of this? [12:21] om26er_: That's the __source.changes file that was generated when you built your source package. [12:23] ok [12:25] i have built 3 different packages and none seem to have a .changes file [12:26] om26er_: How did you build them? [12:27] It should be generated by debuild when called with the '-S' flag. [12:27] sudo ./configure then sudo make then sudo checkinstall [12:29] 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] wgrant: is this the exact link https://wiki.ubuntu.com/PackagingGuide/Complete ? [12:33] om26er: That's right. [12:33] wgrant: thanx === jtv1 is now known as jtv [14:12] 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] ^ more fallout from the v3 change? (sync-source.py -a) === salgado_ is now known as salgado === t- is now known as t [14:44] hi [14:47] 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] rockstar, abentley, is deleting branches exported over the API? [14:53] my guess would be that james_w` would of already requested something like that :) === salgado is now known as salgado-afk [14:56] beuno: I believe it is not, though poolie suggests jelmer is working on that. [14:56] it is bug 491944 [14:56] Launchpad bug 491944 in launchpad-code "No API call to delete a branch" [Undecided,In progress] https://launchpad.net/bugs/491944 === salgado-afk is now known as salgado-lunch [14:56] abentley, ah, is that what the "commit message" discussion is about? [14:57] beuno: No, I don't think it's related. [14:57] abentley: There's an approved branch from me that adds support for deleting branches over the API [14:57] abentley: But launchpadlib doesn't like the fact that the object you have a handle to and call "delete()" on suddenly disappears [14:57] ripps, I think this means "soon on edge" :) [14:57] thanks jelmer, abentley [14:58] abentley: So I've waited with landing it until I had the chance to talk to Leonard [14:58] abentley: (also, this was stuff I [14:58] did in my spare time, not work :-) [14:58] jelmer: I understand. [14:59] jelmer, spare time? you don't get anymore of that around here! ;) [14:59] :-) [15:00] thanks jelmer [15:01] jelmer: you have a traceback for the launchpadlib issue? I've been elbow deep in that code over the weekend [15:01] james_w: Basically, launchpadlib tries to access the branch after delete() has been called on it [15:02] so it gets back a 404 [15:02] I can also get you the full traceback if that would help. [15:03] I get the concept at least [15:03] I guess there's an issue that you can't make the object kill itself [15:03] yeah [15:03] if http_method == 'post': [15:03] # The method call probably modified this resource in [15:03] # an unknown way. Refresh its representation. [15:03] self.resource.lp_refresh() [15:04] .delete() is explicitly exported as a delete operation isn't it? [15:05] yep [15:05] It's named 'delete' I mean, is there anything else? [15:05] is it just done with @export, or something like @export_delete_operation [15:06] I suspect it's just @export, I wasn't aware of the latter [15:06] will that make a difference on the client side? === ripps is now known as ripps|sleep [15:07] I don't know [15:08] it would at least allow us to differentiate client side [15:08] well, we could have == "delete", but y'know [15:10] james_w: I'll see if @export_delete_operation makes a difference tonight [15:10] james_w: Special-casing seems like a bad idea, indeed. [15:12] export_destructor_operation [15:12] """Decorator indicating that an exported method destroys an entry. [15:12] The method will be invoked when the client sends a DELETE request to [15:12] the entry. [15:12] """ [15:13] However, it may not work due to the parameters === matsubara is now known as matsubara-lunch === mpt_ is now known as mpt === matsubara-lunch is now known as matsubara [16:16] Hi [16:16] I'm trying to upload a package into a PPA [16:17] I want it built for all Ubuntu versions, so I uploaded it multiple times with different ubuntu-versions in the changelog [16:17] Launchpad rejected it, because 'File bitcron_2.0-20091231.02.tar.gz already exists in bitcron' [16:18] Hi Jeeves_ , have you seen https://help.launchpad.net/Packaging/PPA/BuildingASourcePackage#Versioning [16:20] noodles775: Hmm, thanks. [16:20] np [16:20] Not a very efficient method, imho, but it'll do === beuno is now known as beuno-lunch === salgado-lunch is now known as salgado === abentley1 is now known as abentley === abentley1 is now known as abentley === abentley1 is now known as abentley === beuno-lunch is now known as beuno === yofel_ is now known as yofel === kfogel is now known as kfogel-lunch === mrevell-lunch is now known as mrevell [18:11] al-maisan: hi, still around by any chance? [18:19] hello james_w` , how are things? === deryck is now known as deryck[lunch] [18:19] hello al-maisan, good thanks, how about you? [18:20] james_w`: doing well, thanks! [18:20] glad to hear it [18:20] .. and happy new year to you! [18:20] I have a packageset question [18:20] OK [18:20] and to you too :-) [18:20] I have a person and a source package name [18:20] aha [18:20] and I want to know if LP would accept and upload from that person for that package name in the current series [18:21] right. [18:21] whether that be from packageset, component, or package-specific right [18:21] is there an existing API call to do this? [18:21] I believe so, please let me look quickly. [18:23] I found isSourceUploadAllowed [18:23] but the documentation for that suggests it is just packageset based [18:24] yes .. but that's package set specific [18:24] just a minute .. I know there's such a method but I need to locate it [18:24] ok [18:24] I'm putting that together with getPermissionsForPerson [18:24] but the documentation for that is pretty poor, so it's not clear what sort of permissions you can get [18:24] I'm checking component and package name from that [18:25] james_w`: you'll get all permissions with getPermissionsForPerson() [18:25] but it's not very user friendly [18:25] 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] you basically want a yes/no answer [18:25] ah, I see it can give package_set_name [18:25] but then I would have to look up the package sets for the package name as well [18:26] so yeah, a yes/no call would be great [18:26] like isSourceUploadAllowed [18:26] ah .. there's verify_upload() [18:26] but that's probably not exported [18:26] let me check [18:27] james_w`: so, your best bet is to use getPermissionsForPerson() it would seem and look at the permissions you get back [18:28] http://paste.ubuntu.com/351377/ is what I have currently [18:28] * al-maisan looks [18:30] james_w`: http://pastebin.ubuntu.com/351379/ [18:31] yeah, not quite the API I want, but that would be usable [18:31] that's from lib/lp/archiveuploader/permission.py|176| def verify_upload() [18:33] james_w`: .. and then there's trunk/lib/lp/archiveuploader/permission.py|128| def check_upload_to_archive() that ueses it [18:34] http://pastebin.ubuntu.com/351381/ [18:34] 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] *it [18:36] james_w`: looks reasonable .. but requires a previous publishing record. [18:36] yes [18:37] for the script that is using it that's a safe assumption [18:37] james_w`: that's good. It should work then. [18:37] 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] wait a minute [18:38] there's an IArchive.canUpload() method but it's not exposed on the LP API [18:41] 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] I can do that [18:43] That would be good if you could file a bug .. maybe we can even nail it down next week? [18:43] ah, good point [18:44] anyway, it's getting late, have a good night! [18:47] you too === deryck[lunch] is now known as deryck === bryce__ is now known as bryyce === Nafallo_ is now known as Nafallo [19:48] morning [19:51] just got a crash on +filebug, Error ID: OOPS-1465ED620 [19:51] https://lp-oops.canonical.com/oops.py/?oopsid=1465ED620 === matsubara is now known as matsubara-afk === salgado is now known as salgado-afk === james_w` is now known as james_w === doctormo_ is now known as doctormo === EdwinGrubbs is now known as Edwin-afk [22:18] anyone want to guess what "I: gnuchess [universe] -> gnuchess_5.07-5ubuntu1 [universe]. [22:18] not ubuntu: debian [22:18] " is trying to tell me? [22:18] sync-source.py [22:20] oh, it's mass-sync.py, that makes more sense [22:20] james_w: I believe that's showing the produced binaries. [22:20] sync-source.py produces such messages. [22:21] yeah, it's the "not ubuntu: debian" error that is unusual [22:21] Ah. [22:38] hi [22:38] how can I get sources of a particular version ? [22:38] with apt-get source [22:59] 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] vadi2: That looks like a bug. [23:02] vadi2: The state of that build is somehow corrupted. [23:10] Yeah. [23:10] I don't know how and it doesn't matter to me, but I guess it would be nice to remove it === RAOF_ is now known as RAOF