=== jasono is now known as Jasono [00:56] hi all [00:56] Hi poolie [00:56] hi spiv [01:00] spiv i'm going to just try to get through some of my currently assigned bugs today: [01:00] stale lock detection, automatic whoami, some others [01:07] Hey guys. Not sure if this has been asked before, but I can't seem to find an answer on the Internet [01:07] Why doesn't Maverick get Bazaar 2.2.2+ packages? [01:09] jaricanese7, it will, it's just slowly passing through the sru process [01:10] you can get an update now from the ~bzr ppa [01:10] Because I was doing some research, and I noticed I have Bzr 2.2.1 [01:10] and 2.2.4 is already out [01:10] If the update takes a longer, there may not be a point since I assume Natty will come with Bazaar 2.3 [01:11] I was hoping not having to use the PPA but I guess that'd what I'll have to do [01:13] let me check === Fuu` is now known as Fuu [01:24] Just curious, is this something I can do? As a community member, package this? Or only Bazaar developers can do this? [01:27] Hmm, I'm not sure where the delays are atm. [01:28] I don't think it's in packaging. [01:29] But if not I'm not sure where, because bzr is one of the approved micro-release exceptions to the typical SRU process (https://wiki.ubuntu.com/StableReleaseUpdates/MicroReleaseExceptions) [01:31] I see [01:31] That's weird [01:31] it's with jelmer or me pushing on it [01:32] or nagging for it to get uploaded [01:32] you can ask on the bug for it, um [01:32] my net connection here is very slow so i can't find it [01:32] basically someone just needs to ask an authorized developer to upload it and to push it through that process [01:45] spiv, i want to change lockdirs to return real objects for the lock info, not dicts [01:45] should i [01:45] - just break the api, and update in-tree callers [01:46] - support just __getitem__ [01:46] - subclass UserDict? [01:50] poolie: you could subclass dict [01:50] Although I think any of those options is fine. [01:51] Are there any out-of-tree callers in any of the common plugins? [01:51] If there are and they only need e.g. __getitem__ support then that's probably the way to go. [01:52] oh i guess just subclassing dict would be simpler [01:55] it's a bit hard to grep for [01:55] but i don't think any of them use it [01:55] I'd probably just break the API then [01:56] Assuming that it wouldn't be too hard for a hypothetical plugin that did use it to support both old and new APIs. [01:57] no [01:57] it shouldn't be [02:54] wow, ben always surprises me [02:54] why build a package and not even try to install it? [02:55] 'cuz it's really hard to install a package that isn't built. So logically, the opposite of something really hard is something really easy; hence, !(install && !build) == !install && build 8-} [02:56] i guess it would be like wrestling a pig to ask why === psynaptic is now known as psynaptic|away [07:23] spiv: ping [07:24] lifeless: pong [07:24] spiv: the branchmergeproposal creation error the package importer is having [07:24] I want to make sure that we're not talking past each other :) [07:24] AIUI it was crashing a lot [07:24] It was crashing a lot due to a bzr bug [07:25] I think this is a bug in the API parameters being passed to LP [07:25] ah, ok, cool [07:25] The bzr bug is fixed, and the fixed bzr deployed [07:25] sweet [07:25] Now it is crashing with what appears to be bug 520412 [07:25] Launchpad bug 520412 in Launchpad itself "fix review_types argument of the API's Branch.createMergeProposal method" [Critical,In progress] https://launchpad.net/bugs/520412 [07:25] Which judging from chatting with wgrant earlier today is probably due to the previously failing imports being relatively stale [07:26] And thus there's some sort of divergence that the importer is apparently trying to make merge proposals about? I think vila knows about that, I think it may have been a recent change [07:26] Two bugs that I see: [07:26] I'm hoping to catch vila when he gets online to ask him about it [07:26] 1) The importer is calling the API incorrectly. [07:27] 2) The API is raising a ValueError and OOPSing, instead of doing something even slightly useful. [07:27] spiv: oh, ok - so what I am saying is valid [07:28] bug 520412 is 'lp crashes when given bad input' [07:28] Launchpad bug 520412 in Launchpad itself "fix review_types argument of the API's Branch.createMergeProposal method" [Critical,In progress] https://launchpad.net/bugs/520412 [07:28] spiv: if I were working on this I would get the parameters being given to lp to be printed in my log, and then look [07:28] AIUI is the importer is saying something like [07:29] It's pretty clear what the problem is... [07:29] reviewers=[x,y,x], review_types=[1,2] [07:29] It's passing reviewers=[ubuntu_dev] without review_types [07:29] hi all ! [07:30] it needs a review_types=[''] I think [07:31] spiv: I hope thats clearer/cleared this up [07:31] I'll check back in a while [07:31] lifeless: well, it was pretty to *me* :P [07:32] s/pretty/pretty clear/ [07:32] vila: read the last 10 minutes of backlog? :) [07:32] lifeless, wgrant, spiv : There are several patches for the p-i in the queue waiting on RT # [07:32] spiv: done [07:33] I was able to reproduce locally at one point, can try lifeless proposal [07:34] but we'll still need to deploy on jubany which is... hard these days :-/ [07:35] ha, rt #44761, nothing happened since friday... [07:36] vila: we need RT to update lp:udd on jubany? [07:36] spiv: read the ticket, the web server needs to be updated [07:37] spiv: and the importer restarted with care [07:38] vila: I guess make sure poolie knows about it, it hasn't had a priority set yet [07:38] spiv: he knows, but he's not online now [07:40] spiv: also, the ValueError I see (locally) doesn't seem to be related to merge proposals so I may have been wrong above or we have more than one bug [07:40] vila, wgrant: I notice there's a commented out line in the code to pass #reviewers=[ubuntu_dev.self_link], review_types=[""] [07:40] vila: https://lp-oops.canonical.com/oops.py/?oopsid=1910A1064 [07:41] spiv: commented where ? [07:41] spiv: Last I saw that wasn't commented out, and didn't have review_types=[""] [07:41] spiv: It was changed on 2011-03-03, IIRC. [07:42] vila: just grep for createMergeProposal [07:42] spiv: not commented here (lp:udd) [07:43] spiv: where are you looking ? [07:44] vila: http://bazaar.launchpad.net/+branch/udd/view/head:/import_package.py#L513 [07:45] argh james_w pushed 8-/ [07:47] spiv: anyway, given the commit dates, this has been deployed after we had the ValueErrors AFAICS [07:48] vila: I don't know that recent changes to that currently commented out line have caused the problem [07:48] vila: I do know that our call to createMergeProposal is incorrect [07:50] spiv: given the commit messages, it looks like james_w was working on this though [07:51] vila: ok [07:51] vila: so I'll just give gst-plugins-bad0.10 a kick, as that is the one named in the OOPS [07:52] vila: if the current state has fixed the problem, as implied by james_w commit messages, it won't fail with that error [07:53] spiv: trying [07:53] spiv: don't forget to commit your delete_branch stuff by the way ;) [07:57] spiv: just got the oops (first attempt gave a blank page), right, I was talking about a list.remove(x): x not in list, ValueError, definitively different :) [07:59] gs-t-bad-plugins passed [07:59] vila: yes, the ValueError here isn't seen by the package-importer, it happens in LP and show as a HTTP 500 to the client. [08:00] vila: well, retry the rest I guess [08:00] spiv: already done [08:00] Thanks [08:00] spiv: thanks to you and james_w ;) [08:02] haa, bad request again for kde-l10n-th [08:03] spiv: you confirmed HTTP 500 or did you mean HTTP 400 [08:03] s/confirmed/confirm/ [08:03] and s/$/?/ gee [08:04] vila: 500 [08:07] gobject-introspection finally passed, pfew [08:07] vila: see bug 520412 for the LP bug an incorrect call to createMergeProposal triggers [08:07] Launchpad bug 520412 in Launchpad itself "fix review_types argument of the API's Branch.createMergeProposal method" [Critical,In progress] https://launchpad.net/bugs/520412 [08:09] bah, I hate software that tells me: "Hey, your input is wrong, here is how to fix it". [08:09] JFDI ! [08:10] vila: +1 [08:10] "Remember: The URL you enter must end with a slash!" Uh... Just add it, if I forget, mkay? [08:11] vila: so long as there is 0 ambiguity about the fix, I tend to agree [08:13] well, it used to work before right ? If the list is of the right length with '' items, it's still a valid item right ? Just default to it then no ? [08:13] s/valid item/valid parameter/ [08:13] vila: nothing in LP has changed here lately [08:14] vila: (that the bug number is in the 500000s gives a pretty strong hint about that) [08:14] right but the bug report also says: "On the other hand this behavior is different to the behavior of the web interface, where the review type argument is optional." [08:15] so there are some reasons to believe the behavior was desired [08:15] Yes, it does, but that's unrelated to "it used to work before right" [08:15] It's "the web UI gets it right, the API doesn't" [08:16] no idea about that, but I'd be surprised (choked?) that this went unnoticed in the p-i for so long... [08:17] anyway, if we can fix it in the p-i, we should [08:18] vila: http://bazaar.launchpad.net/+branch/udd/revision/410 [08:18] Error: Launchpad bug 410 not found [08:18] ubot5: +1 ;) [08:19] vila: So, it's not that it was an old bug unnoticed [08:19] vila: it's a new bug in udd [08:19] vila: a few weeks old [08:19] :-( [08:19] spiv: thanks for the analysis... [08:20] spiv: and sorry for being so dense, I need more coffee ;) [08:20] * vila notes: stop presuming that untested code works [08:21] vila: no worries [08:21] * spiv logs off for the day [08:22] spiv: one last thing: poolie is still having trouble with his ADSL modem right ? [08:28] 5 babune slaves failing on bzrlib.tests.test_revisionspec.TestRevisionSpec_date.test_yesterday [08:29] don't tell me, someone didn't fully get what DST is about ? [08:39] moin [08:50] vila: yes [08:51] jelmer: hi ! [08:52] * jelmer waves to spiv and vila [08:53] spiv: Did you see my review request for ~jelmer/bzr/move-interbranch-fetch2 ? [08:53] vila: down to 466 failures, hurrah [08:53] spiv: yeah ;) [08:54] spiv: Sorry this was necessary, my review of your fetch tags branch wasn't very good. :-/ [08:55] jelmer: I have, haven't looked at it closely yet [08:55] jelmer: I'm not sure that I like the more limited API. I wonder about other options other branches might have. [08:55] fetch_loom_thread? [08:56] That sort of thing [08:56] spiv: API users wouldn't really know what to specify in that case though [08:56] Although 'fetch' is a sort of weird thing to have on Branch in a sense [08:57] spiv: It seems reasonable to have Branch.fetch() as a convenience wrapper around Repository.fetch [08:57] spiv: yeah [09:21] heya [09:22] bonjour vila [09:22] fullermd: wow, 10072 freebsd patches since 2011-03-09 ? Should I worry or did I just miss some important news ? [09:22] bialix: _o/ [09:22] vila: we don't have a dedicated 2.4 branch yet, have we? [09:22] bialix: for bzr ? No. Not until 2.4.0 [09:23] bialix: but the series exists already nvertheless [09:23] ok, I need to put the news for my py2exe patch, I think I should wait till you cut out 2.4b1? [09:23] bialix: 2.4b1 *has* been cut, I still need to announce it though [09:24] bialix: until 2.4.0 we release from trunk [09:24] hmm [09:24] bialix: https://launchpad.net/bzr/2.4/2.4b1 [09:24] Error: Launchpad bug 2 not found [09:25] vila: ok, I see the 2.4b2 section now. most likely yesterday I've used slightly outdated truk [09:26] trunk [09:26] vila: thank you [09:26] bialix: np [09:28] oh yes, forgot to update my copy of bzr.dev, heh [09:35] fullermd: weird, ended up with .. 90 new ports/files only === mr-russ1 is now known as mr-russ === hunger_ is now known as hunger === psynaptic|away is now known as psynaptic === mrevell is now known as mrevell-lunch === mrevell-lunch is now known as mrevell [13:52] hi there [13:52] i'm new to VCS and stuff [13:53] yesterday bzr commands were working fine but today i get the following error [13:53] bzr: ERROR: Connection error: while sending CONNECT xmlrpc.edge.launchpad.net:443: [Errno 110] Connection timed out [13:53] does that mean my net connection in not proper or something else? [13:55] hi alexKeith [13:55] alexKeith: it looks like either an issue on your side or on Launchpad's side [13:56] jelmer: in the application on the connection? [13:57] alexKeith: in the connection [13:57] alexKeith: I doubt it's an application issue if it worked ok earlier [13:58] jelmer: hmmm... thanks for the suggestion.. will wait a few more hours [14:27] so if I wanted bzr uncommit (either in a particular branch, or even machinewide if need be) to scream at the user and die horribly rather than uncommitting, is that trivial to do? [14:31] I suppose you could write a plugin... [14:32] I believe pygame is your best option for audio output. ;-) [14:37] lamont: 'bzr alias uncommit=logout' could be a start, but since this is stored (and read only from) bazaar.conf, it will affect only a single user [14:38] jelmer: found a 6 month old log on the same problem on launchpad channel... [14:38] lamont: aren't you after 'append_revisions_only' on the target branch instead ? [14:39] jelmer: though no solution is given [14:39] lamont: 'bzr alias uncommit=logout' could be a start, but since this is stored (and read only from) bazaar.conf, it will affect only a single user [14:39] ghaa, history editing fail [14:40] lamont: I meant 'bzr alias uncommit=I_HATE_YOU_DONT_DO_THAT' to take screaming into account === vila changed the topic of #bzr to: Bazaar version control | try https://answers.launchpad.net/bzr for more help | http://irclogs.ubuntu.com/ | Patch pilot: jelmer | 2.4b1 is officially out (ppa:bzr/beta needs love) [14:41] vila: yeah - but I want it to affect the branch, not the user... [14:42] rather, I want it to affect all users of the branch, not just the one [14:42] lamont: strictly speaking, uncommit is for the working tree, not the branch , hence append_revisions_only [14:43] which I suppose gets back to the whole "zomg can't have scripts in the branch, because we'd insist on copying them when you branch and that'd be bad" [14:43] vila: ah [14:43] but even that can be overridden with --push --overwrite (IIRC) [14:43] so short answer is that there's no trivial solution to the administrative issue at hand [14:43] and I suppose that's ok [14:44] lamont: I still don't clearly understand your problem :-/ [14:44] lamont: I'm sure there is a valid use case here, I just don't get it (so far) [14:44] vila: group of users who have become trained that bzr uncommit is perfectly reasonable, transitioning into a new use model where it is absolutely NOT reasonable, and still doing it sometimes [14:45] who can talk with me about lp:branches and how they becomes bzr+ssh://b.l.n/+branch URs? [14:45] lamont: not reasonable because ? [14:45] vila: because the branch is actually published to other machines [14:46] lamont: it breaks the shared branch history ? [14:46] vi bzr pull in a cronjob [14:46] via [14:47] ha right, then, yeah, append_revisions_only, so the users are gently nudged to *add* revisions (even to revert a silly change) [14:47] vila: and that's something I can set on the branch? [14:48] lamont: yes, in branch.conf [14:48] oh, nice [14:48] we should really make it the default [14:48] does launchpad plugin has any cheap way to decode +branch URL and extract the project name, instead of parsing the parts of URL in my code? [14:48] I've been told that I should never edit branch.conf directly... what's the offically blessed way (and syntax) for setting this? [14:48] mind you, I still frequently cat .bzr/branch/branch.conf rather than bzr info [14:50] lamont: 'bzr config' ? [14:50] bzr: ERROR: unknown command "config" [14:50] :-/ [14:51] lamont: import from future ; bzr config [14:51] lamont: so, without bzr config, you need to edit manually [14:51] 2.2 or 2.3? [14:51] 2.3 [14:52] jelmer: restarting solved the problem [14:52] and I assume 2.3 still has the "momma knows best" belief of forcing me to have run bzr whoami? [14:52] because breaking cronjobs is better than not breaking them, or some such [14:52] jelmer: i had changed the proxy settings after booting and then connected as i did a few hours before [14:52] lamont: and, when in the right dir, 'bzr config appen_revisions_only=True (http://doc.bazaar.canonical.com/bzr.dev/en/user-reference/configuration-help.html) should work [14:53] jelmer: so now i tried restarting and it worked [14:53] lamont: yes [14:53] jelmer: does this classify as a bug? [14:53] lamont: on the other hand, we heard you and poolie is working on fixing it ;) [14:53] lamont: should be in 2.4 (AIUI) [14:54] vila: yay [14:55] bialix: the translation is done on lp, you have no way to emulate that [14:55] bialix: what's the need ? [14:56] bialix: jam has been playing with the xmlrpc code and should have the details in his hot cache ;) [14:56] afk [14:57] vila: Sweep of MD5 checksums that touched files all over the place. Kinda cosmetic/internals, so it doesn't have anything to do with needed upgrades. [14:58] * vila happily shudders [14:58] vila: we have a code in qbzr to automatically guess the project name based on lp URL [14:59] vila: that code does not like +branch, and I don't like it either [14:59] bialix: just deleting it from the start should make your guesses as good as they were before [14:59] vila: if I do `bzr branch lp:qbzr` then I got parent URL as bzr+ssh://b.l.n/+branch/qbzr [15:00] bialix: you know how to guess: bzr+ssh:/b.l.n/qbzr ? [15:00] vila: if I do `bzr get lp:qbzr/0.20` then I got parent URL as bzr+ssh://b.l.n/+branch/qbzr/0.20 [15:00] vila: do you know how to create it? [15:01] create what ? [15:01] that parent URL: bzr+ssh:/b.l.n/qbzr [15:01] bialix: that is the wrong parent, though [15:01] that path doesn't exist [15:01] +branch/qbzr does [15:01] I've just showed you what bzr creates for different cases [15:01] bialix: I think it doesn't exist, that's why +branch has been created [15:01] bialix: +branch was specifically created to allow server-side expansion of lp: urls [15:01] bialix: so lp can redirect properly [15:01] To support private branches [15:01] etc [15:01] vila: no redirect [15:02] it maps the virtual fs to include those paths [15:02] before it was always bzr+ssh://b.l.n/~team/project/branch [15:02] bialix: It was about 3-6months ago Launchpad switched [15:02] jam: yeah, redirect not in the HTTP sense, bzr+ssh is not HTTP anyway [15:02] because XMLRPC can't expand private branches [15:02] vila: sure, just mentioning that "cat +branch/bzr/.bzr/branch-format" is a valid thing to do in the VFS [15:02] jam: I need a cheap way to extract project name from new urls [15:03] bialix: if you look at the new bzr.dev LaunchpadDirectory, you can see the basic rules [15:03] lp:ONE [15:03] ONE must be the project name [15:03] will it work locally? [15:03] lp:ONE/TWO [15:03] ONE is the project name, TWO is the series name [15:03] not related to branch [15:03] though it maps to a branch [15:03] if there is a ~ then it must be a fully qualified path [15:04] lp:~user/PROJECT/BRANCH [15:04] jam: I'm reading lp_directory.py but I don't see what can help me? [15:04] there are a few special cases for handling "ubuntu" and "debian" [15:04] OR one/two is a distro/series [15:04] nuh-uh, they are not special casea [15:04] maxb: one/two can only be distro/project [15:04] jam: I need a way to extract project name from bzr+ssh://b.l.n/something [15:04] maxb: unless you can somehow branch an entire series [15:05] (lp:ubuntu/bzr, for example) [15:05] bialix: and you are trying to do it now that we have +branch syntax? [15:06] jam: lp:one/two can be project/series or distro/series [15:06] jam: right now I have to code this decoder logic directly into qbzr. if I can use some code from lp plugin then I will save my dude in the future when bzr/lp team will decide to change again [15:06] um, no [15:06] I mean... [15:06] jam: lp:one/two can be project/series or distro/package [15:06] jam: yes [15:07] maxb: sure. But how do you know it is a distro rather than a project? By having specifically listed distros that are encoded in the lp db? [15:07] which we can hint at, by just hard-coding the obvious ones [15:07] aka, special cased [15:07] Ah, sure. Yes, the syntax doesn't tell you the type of pillar involved [15:08] bialix: so if I do "lp:~user/project/branch" that will still be expanded to "bzr+ssh://b.lp.net/~user/project/branch" (at least at the moment) [15:08] so you'll still want that logic [15:08] for everything else [15:08] bzr+ssh://b.lp.net/+branch/SOMETHING [15:08] I would treat it as: [15:08] parts = something.split('/') [15:08] if len(parts) == 1: [15:08] project = parts[0] [15:08] elif: [15:09] parts[0] in ( 'debian', 'ubuntu'): [15:09] # punt for now [15:09] else: [15:09] project = parts[0] [15:09] the debian/ubuntu rules are a bit complex [15:09] because you can have [15:09] ubuntu/bzr [15:09] ubuntu/natty/bzr [15:09] ubuntu/natty/bzr/branch [15:10] I don't think you can have 'ubuntu/bzr/branch' [15:10] omg [15:10] You can't have the 4-part one [15:10] (If you specify a branch, you have to specify the distroseries) [15:10] maxb: ah, you have to specify the user in that case as well? [15:10] yes [15:10] in which case it becomes ~user/ubuntu/natty/bzr/branch [15:10] I think there's a much simpler way to describe this: [15:11] If it starts with a ~, then it's a fully qualified unique name starting with a user [15:11] jam: all that stuff scaries me almost to death; may I file a feature request to add decoder into lp plugin? [15:11] If it does not start with a ~, then the first component is a pillar (project/distro), with a reasonable hierarchy of aliases underneath it [15:12] bialix: If all you want is a project name and you are willing to temporarily disregard distro package branches, then you just need to take the first component, unless it has a ~, in which case the second [15:13] maxb: do you mean the case bzr+ssh://b.l.n/+branch/~user/ubuntu/natty/bzr/branch ? [15:13] That is speaking about lp: URLs, of course. If you're working with bzr+ssh://b.l.n/ ones, then chop off that prefix, additionally chop off +branch/ if present, and stick a lp: on the front, then proceed as before [15:14] maxb: no, this won't work for me [15:14] why not? [15:14] maxb: I need project name to create a push url suggestion as: lp:~user/PROJECT/new-branch [15:15] yes? [15:15] I just suggested a simple algorithm to get it [15:15] yes, thanks, but I need project name [15:16] bialix: that's what maxb suggested: how to get the project name [15:16] bialix: presumably from the remember parent location [15:16] yes, that's exactly my case [15:17] If you're working with bzr+ssh://b.l.n/ ones, then chop off that prefix, additionally chop off +branch/ if present, and stick a lp: on the front, then proceed as before [15:17] citing maxb^ [15:18] vila, maxb: before I always had only scheme://host/~user-id/project-name/branch-name/ [15:19] I don't need to stick lp: on the front [15:19] today I see more cases: [15:19] scheme://host/+branch/project-name [15:19] scheme://host/+branch/project-name/series-name [15:19] bialix: we don't know what you had :) Just adapt, may be you just need to fake a 'bzr+ssh://bl.n/+branch' [15:20] ok, that's enough [15:20] .. scheme [15:21] bialix: but keep in mind that you will always try to guess what is happening on a remote server and if things change there, you'll need to catch up anyway [15:21] that was my initial question: can I use launchpad plugin to do this or not [15:22] same answer applis to the launchpad plugin: it guesses, unless it asks explicitely to lp (and even there I'm not sure it get the true branch) [15:22] bialix: However, given the current URL structure, getting the project is trivial: Remove "bzr+ssh://bazaar.launchpad.net/". Remove "+branch/" if present. Remove "~user/" if present. Next component is the project or distro [15:23] bialix: are you trying to solve this problem in a server-agnostic way ? [15:23] bialix: because we only answered about the lp specifics so far [15:24] bialix: and it seems we are not all on the same page [15:25] vila: I'm trying to solve this problem in qbzr-unrelated way [15:26] bialix: but in a lp-specific way ? [15:26] I can live with the suggested way, but if I can use lp plugin for that I'd be happy [15:26] vila: yes, for generic case we have different code [15:26] I can point you to the real code, if you wish [15:27] http://paste.ubuntu.com/586468/ [15:27] I have just typed up a quick refcard to the various URL forms ^^^ [15:28] bialix: AFAIK, the lp plugin doesn't provide such a feature, but this sounds like a good one to add [15:29] maxb: what should I use for distro/package then? [15:29] bialix: so file a wishlist bug and add a patch or a pointer to your implementation [15:29] bialix: if you want to propose a push location, you should probably respect dsitro/package [15:30] bialix: and in most cases *add* ~user if not already there as I think most users *can't* push to the official branch [15:30] maxb: isn't it ? ^ [15:30] maxb: qbzr intent is to provide suggestion for push of feature branch back to lp. so if one have lp:ubuntu/bzr what should be suggested URL for new branch? [15:31] vila: Mostly not, no. [15:31] bialix: lp:~user/ubuntu/current-ubuntu-development-series/bzr/somename [15:31] vila, maxb: again, please look: if I have project-name, and I know local user name, then suggestion will be: lp:~user-name/project-name/new-branch-name [15:32] Yes [15:32] and that's good for upstream branches (AIUI) not for packaging branches [15:33] so? should I ignore any attempts to suggest URL for distro or not? [15:33] 15:30 < bialix> maxb: qbzr intent is to provide suggestion for push of feature branch back to lp. so if one have lp:ubuntu/bzr what should be suggested URL for new branch? [15:33] 15:31 < maxb> bialix: lp:~user/ubuntu/current-ubuntu-development-series/bzr/somename [15:33] vila: http://paste.ubuntu.com/586468/ [15:33] DISTRO/SOURCEPACKAGE, DISTRO/SERIES/SOURCEPACKAGE, DISTRO/POCKET/SOURCEPACKAGE ? [15:34] what will be "project-name" here? [15:34] THERE IS NO PROJECT NAME [15:34] what is "current-ubuntu-development-series"? [15:34] The name of the current ubuntu development series [15:35] natty, for now. Later it will be oneiric [15:35] bialix: PROJECTNAME ~= SOURCEPACKAGE (/me runs before maxb yells) [15:35] * maxb wonders what kind of operator ~= is :-? [15:35] bialix: the difference is that a "project* can be the source for several packages [15:36] maxb: the handwavy version of = :D [15:36]