[00:56] <poolie> hi all
[00:56] <spiv> Hi poolie
[00:56] <poolie> hi spiv
[01:00] <poolie> spiv i'm going to just try to get through some of my currently assigned bugs today:
[01:00] <poolie> stale lock detection, automatic whoami, some others
[01:07] <jaricanese7> Hey guys. Not sure if this has been asked before, but I can't seem to find an answer on the Internet
[01:07] <jaricanese7> Why doesn't Maverick get Bazaar 2.2.2+ packages?
[01:09] <poolie> jaricanese7, it will, it's just slowly passing through the sru process
[01:10] <poolie> you can get an update now from the ~bzr ppa
[01:10] <jaricanese7> Because I was doing some research, and I noticed I have Bzr 2.2.1
[01:10] <jaricanese7> and 2.2.4 is already out
[01:10] <jaricanese7> If the update takes a longer, there may not be a point since I assume Natty will come with Bazaar 2.3
[01:11] <jaricanese7> I was hoping not having to use the PPA but I guess that'd what I'll have to do
[01:13] <poolie> let me check
[01:24] <jaricanese7> Just curious, is this something I can do?  As a community member, package this? Or only Bazaar developers can do this?
[01:27] <spiv> Hmm, I'm not sure where the delays are atm.
[01:28] <spiv> I don't think it's in packaging.
[01:29] <spiv> 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] <jaricanese7> I see
[01:31] <jaricanese7> That's weird
[01:31] <poolie> it's with jelmer or me pushing on it
[01:32] <poolie> or nagging for it to get uploaded
[01:32] <poolie> you can ask on the bug for it, um
[01:32] <poolie> my net connection here is very slow so i can't find it
[01:32] <poolie> basically someone just needs to ask an authorized developer to upload it and to push it through that process
[01:45] <poolie> spiv, i want to change lockdirs to return real objects for the lock info, not dicts
[01:45] <poolie> should i
[01:45] <poolie> - just break the api, and update in-tree callers
[01:46] <poolie> - support just __getitem__
[01:46] <poolie> - subclass UserDict?
[01:50] <spiv> poolie: you could subclass dict
[01:50] <spiv> Although I think any of those options is fine.
[01:51] <spiv> Are there any out-of-tree callers in any of the common plugins?
[01:51] <spiv> If there are and they only need e.g. __getitem__ support then that's probably the way to go.
[01:52] <poolie> oh i guess just subclassing dict would be simpler
[01:55] <poolie> it's a bit hard to grep for
[01:55] <poolie> but i don't think any of them use it
[01:55] <spiv> I'd probably just break the API then
[01:56] <spiv> 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] <poolie> no
[01:57] <poolie> it shouldn't be
[02:54] <poolie> wow, ben always surprises me
[02:54] <poolie> why build a package and not even try to install it?
[02:55] <fullermd> '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] <poolie> i guess it would be like wrestling a pig to ask why
[07:23] <lifeless> spiv: ping
[07:24] <spiv> lifeless: pong
[07:24] <lifeless> spiv: the branchmergeproposal creation error the package importer is having
[07:24] <lifeless> I want to make sure that we're not talking past each other :)
[07:24] <lifeless> AIUI it was crashing a lot
[07:24] <spiv> It was crashing a lot due to a bzr bug
[07:25] <lifeless> I think this is a bug in the API parameters being passed to LP
[07:25] <lifeless> ah, ok, cool
[07:25] <spiv> The bzr bug is fixed, and the fixed bzr deployed
[07:25] <lifeless> sweet
[07:25] <spiv> Now it is crashing with what appears to be bug 520412
[07:25] <spiv> Which judging from chatting with wgrant earlier today is probably due to the previously failing imports being relatively stale
[07:26] <spiv> 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] <wgrant> Two bugs that I see:
[07:26] <spiv> I'm hoping to catch vila when he gets online to ask him about it
[07:26] <wgrant> 1) The importer is calling the API incorrectly.
[07:27] <wgrant> 2) The API is raising a ValueError and OOPSing, instead of doing something even slightly useful.
[07:27] <lifeless> spiv: oh, ok - so what I am saying is valid
[07:28] <lifeless> bug 520412 is 'lp crashes when given bad input'
[07:28] <lifeless> 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] <lifeless> AIUI is the importer is saying something like
[07:29] <wgrant> It's pretty clear what the problem is...
[07:29] <lifeless> reviewers=[x,y,x], review_types=[1,2]
[07:29] <wgrant> It's passing reviewers=[ubuntu_dev] without review_types
[07:29] <vila> hi all !
[07:30] <lifeless> it needs a review_types=[''] I think
[07:31] <lifeless> spiv: I hope thats clearer/cleared this up
[07:31] <lifeless> I'll check back in a while
[07:31] <spiv> lifeless: well, it was pretty to *me* :P
[07:32] <spiv> s/pretty/pretty clear/
[07:32] <spiv> vila: read the last 10 minutes of backlog? :)
[07:32] <vila> lifeless, wgrant, spiv : There are several patches for the p-i in the queue waiting on RT #<can't find it>
[07:32] <vila> spiv: done
[07:33] <vila> I was able to reproduce locally at one point, can try lifeless proposal
[07:34] <vila> but we'll still need to deploy on jubany which is... hard these days :-/
[07:35] <vila> ha, rt #44761, nothing happened since friday...
[07:36] <spiv> vila: we need RT to update lp:udd on jubany?
[07:36] <vila> spiv: read the ticket, the web server needs to be updated
[07:37] <vila> spiv: and the importer restarted with care
[07:38] <spiv> vila: I guess make sure poolie knows about it, it hasn't had a priority set yet
[07:38] <vila> spiv: he knows, but he's not online now
[07:40] <vila> 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] <spiv> vila, wgrant: I notice there's a commented out line in the code to pass #reviewers=[ubuntu_dev.self_link], review_types=[""]
[07:40] <spiv> vila: https://lp-oops.canonical.com/oops.py/?oopsid=1910A1064
[07:41] <vila> spiv: commented where ?
[07:41] <wgrant> spiv: Last I saw that wasn't commented out, and didn't have review_types=[""]
[07:41] <wgrant> spiv: It was changed on 2011-03-03, IIRC.
[07:42] <spiv> vila: just grep for createMergeProposal
[07:42] <vila> spiv: not commented here (lp:udd)
[07:43] <vila> spiv: where are you looking ?
[07:44] <spiv> vila: http://bazaar.launchpad.net/+branch/udd/view/head:/import_package.py#L513
[07:45] <vila> argh james_w pushed 8-/
[07:47] <vila> spiv: anyway, given the commit dates, this has been deployed after we had the ValueErrors AFAICS
[07:48] <spiv> vila: I don't know that recent changes to that currently commented out line have caused the problem
[07:48] <spiv> vila: I do know that our call to createMergeProposal is incorrect
[07:50] <vila> spiv: given the commit messages, it looks like james_w was working on this though
[07:51] <spiv> vila: ok
[07:51] <spiv> vila: so I'll just give gst-plugins-bad0.10 a kick, as that is the one named in the OOPS
[07:52] <spiv> 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] <vila> spiv: trying
[07:53] <vila> spiv: don't forget to commit your delete_branch stuff by the way ;)
[07:57] <vila> 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] <vila> gs-t-bad-plugins passed
[07:59] <spiv> 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] <spiv> vila: well, retry the rest I guess
[08:00] <vila> spiv: already done
[08:00] <spiv> Thanks
[08:00] <vila> spiv: thanks to you and james_w ;)
[08:02] <vila> haa, bad request again for kde-l10n-th
[08:03] <vila> spiv: you confirmed HTTP 500 or did you mean HTTP 400
[08:03] <vila> s/confirmed/confirm/
[08:03] <vila> and s/$/?/ gee
[08:04] <spiv> vila: 500
[08:07] <vila> gobject-introspection finally passed, pfew
[08:07] <spiv> vila: see bug 520412 for the LP bug an incorrect call to createMergeProposal triggers
[08:09] <vila> bah, I hate software that tells me: "Hey, your input is wrong, here is how to fix it".
[08:09] <vila> JFDI !
[08:10] <soren> vila: +1
[08:10] <soren> "Remember: The URL you enter must end with a slash!"  Uh... Just add it, if I forget, mkay?
[08:11] <spiv> vila: so long as there is 0 ambiguity about the fix, I tend to agree
[08:13] <vila> 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] <vila> s/valid item/valid parameter/
[08:13] <spiv> vila: nothing in LP has changed here lately
[08:14] <spiv> vila: (that the bug number is in the 500000s gives a pretty strong hint about that)
[08:14] <vila> 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] <vila> so there are some reasons to believe the behavior was desired
[08:15] <spiv> Yes, it does, but that's unrelated to "it used to work before right"
[08:15] <spiv> It's "the web UI gets it right, the API doesn't"
[08:16] <vila> no idea about that, but I'd be surprised (choked?) that this went unnoticed in the p-i for so long...
[08:17] <vila> anyway, if we can fix it in the p-i, we should
[08:18] <spiv> vila: http://bazaar.launchpad.net/+branch/udd/revision/410
[08:18] <vila> ubot5: +1 ;)
[08:19] <spiv> vila: So, it's not that it was an old bug unnoticed
[08:19] <spiv> vila: it's a new bug in udd
[08:19] <spiv> vila: a few weeks old
[08:19] <vila> :-(
[08:19] <vila> spiv: thanks for the analysis...
[08:20] <vila> spiv: and sorry for being so dense, I need more coffee ;)
[08:20]  * vila notes: stop presuming that untested code works
[08:21] <spiv> vila: no worries
[08:21]  * spiv logs off for the day
[08:22] <vila> spiv: one last thing: poolie is still having trouble with his ADSL modem right ?
[08:28] <vila> 5 babune slaves failing on bzrlib.tests.test_revisionspec.TestRevisionSpec_date.test_yesterday
[08:29] <vila> don't tell me, someone didn't fully get what DST is about ?
[08:39] <jelmer> moin
[08:50] <spiv> vila: yes
[08:51] <vila> jelmer: hi !
[08:52]  * jelmer waves to spiv and vila
[08:53] <jelmer> spiv: Did you see my review request for ~jelmer/bzr/move-interbranch-fetch2 ?
[08:53] <spiv> vila: down to 466 failures, hurrah
[08:53] <vila> spiv: yeah ;)
[08:54] <jelmer> spiv: Sorry this was necessary, my review of your fetch tags branch wasn't very good.  :-/
[08:55] <spiv> jelmer: I have, haven't looked at it closely yet
[08:55] <spiv> jelmer: I'm not sure that I like the more limited API.  I wonder about other options other branches might have.
[08:55] <spiv> fetch_loom_thread?
[08:56] <spiv> That sort of thing
[08:56] <jelmer> spiv: API users wouldn't really know what to specify in that case though
[08:56] <spiv> Although 'fetch' is a sort of weird thing to have on Branch in a sense
[08:57] <jelmer> spiv: It seems reasonable to have Branch.fetch() as a convenience wrapper around Repository.fetch
[08:57] <jelmer> spiv: yeah
[09:21] <bialix> heya
[09:22] <bialix> bonjour vila
[09:22] <vila> fullermd: wow, 10072 freebsd patches since 2011-03-09 ? Should I worry or did I just miss some important news ?
[09:22] <vila> bialix: _o/
[09:22] <bialix> vila: we don't have a dedicated 2.4 branch yet, have we?
[09:22] <vila> bialix: for bzr ? No. Not until 2.4.0
[09:23] <vila> bialix: but the series exists already nvertheless
[09:23] <bialix> ok, I need to put the news for my py2exe patch, I think I should wait till you cut out 2.4b1?
[09:23] <vila> bialix: 2.4b1 *has* been cut, I still need to announce it though
[09:24] <vila> bialix: until 2.4.0 we release from trunk
[09:24] <bialix> hmm
[09:24] <vila> bialix: https://launchpad.net/bzr/2.4/2.4b1
[09:25] <bialix> vila: ok, I see the 2.4b2 section now. most likely yesterday I've used slightly outdated truk
[09:26] <bialix> trunk
[09:26] <bialix> vila: thank you
[09:26] <vila> bialix: np
[09:28] <bialix> oh yes, forgot to update my copy of bzr.dev, heh
[09:35] <vila> fullermd: weird, ended up with .. 90 new ports/files only
[13:52] <alexKeith> hi there
[13:52] <alexKeith> i'm new to VCS and stuff
[13:53] <alexKeith> yesterday bzr commands were working fine but today i get the following error
[13:53] <alexKeith> bzr: ERROR: Connection error: while sending CONNECT xmlrpc.edge.launchpad.net:443: [Errno 110] Connection timed out
[13:53] <alexKeith> does that mean my net connection in not proper or something else?
[13:55] <jelmer> hi alexKeith
[13:55] <jelmer> alexKeith: it looks like either an issue on your side or on Launchpad's side
[13:56] <alexKeith> jelmer: in the application on the connection?
[13:57] <jelmer> alexKeith: in the connection
[13:57] <jelmer> alexKeith: I doubt it's an application issue if it worked ok earlier
[13:58] <alexKeith> jelmer: hmmm... thanks for the suggestion.. will wait a few more hours
[14:27] <lamont> 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] <Peng> I suppose you could write a plugin...
[14:32] <Peng> I believe pygame is your best option for audio output. ;-)
[14:37] <vila> 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] <alexKeith1> jelmer: found a 6 month old log on the same problem on launchpad channel...
[14:38] <vila> lamont: aren't you after 'append_revisions_only' on the target branch instead ?
[14:39] <alexKeith1> jelmer: though no solution is given
[14:39] <vila> 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] <vila> ghaa, history editing fail
[14:40] <vila> lamont: I meant 'bzr alias uncommit=I_HATE_YOU_DONT_DO_THAT' to take screaming into account
[14:41] <lamont> vila: yeah - but I want it to affect the branch, not the user...
[14:42] <lamont> rather, I want it to affect all users of the branch, not just the one
[14:42] <vila> lamont: strictly speaking, uncommit is for the working tree, not the branch , hence append_revisions_only
[14:43] <lamont> 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] <lamont> vila: ah
[14:43] <vila> but even that can be overridden with --push --overwrite (IIRC)
[14:43] <lamont> so short answer is that there's no trivial solution to the administrative issue at hand
[14:43] <lamont> and I suppose that's ok
[14:44] <vila> lamont: I still don't clearly understand your problem :-/
[14:44] <vila> lamont: I'm sure there is a valid use case here, I just don't get it (so far)
[14:44] <lamont> 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] <bialix> who can talk with me about lp:branches and how they becomes bzr+ssh://b.l.n/+branch URs?
[14:45] <vila> lamont: not reasonable because ?
[14:45] <lamont> vila: because the branch is actually published to other machines
[14:46] <vila> lamont: it breaks the shared branch history ?
[14:46] <lamont> vi bzr pull in a cronjob
[14:46] <lamont> via
[14:47] <vila> ha right, then, yeah, append_revisions_only, so the users are gently nudged to *add* revisions (even to revert a silly change)
[14:47] <lamont> vila:  and that's something I can set on the branch?
[14:48] <vila> lamont: yes, in branch.conf
[14:48] <lamont> oh, nice
[14:48] <vila> we should really make it the default
[14:48] <bialix> 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] <lamont> 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] <lamont> mind you, I still frequently cat .bzr/branch/branch.conf rather than bzr info
[14:50] <vila> lamont: 'bzr  config' ?
[14:50] <lamont> bzr: ERROR: unknown command "config"
[14:50] <vila> :-/
[14:51] <vila> lamont: import from future ;  bzr config
[14:51] <vila> lamont: so, without bzr config, you need to edit manually
[14:51] <lamont> 2.2 or 2.3?
[14:51] <vila> 2.3
[14:52] <alexKeith1> jelmer: restarting solved the problem
[14:52] <lamont> and I assume 2.3 still has the "momma knows best" belief of forcing me to have run bzr whoami?
[14:52] <lamont> because breaking cronjobs is better than not breaking them, or some such
[14:52] <alexKeith1> jelmer: i had changed the proxy settings after booting and then connected as i did a few hours before
[14:52] <vila> 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] <alexKeith1> jelmer: so now i tried restarting and it worked
[14:53] <vila> lamont: yes
[14:53] <alexKeith1> jelmer: does this classify as a bug?
[14:53] <vila> lamont: on the other hand, we heard you and poolie is working on fixing it ;)
[14:53] <vila> lamont: should be in 2.4 (AIUI)
[14:54] <lamont> vila: yay
[14:55] <vila> bialix: the translation is done on lp, you have no way to emulate that
[14:55] <vila> bialix: what's the need ?
[14:56] <vila> bialix: jam has been playing with the xmlrpc code and should have the details in his hot cache ;)
[14:56] <lamont> afk
[14:57] <fullermd> 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] <bialix> vila: we have a code in qbzr to automatically guess the project name based on lp URL
[14:59] <bialix> vila: that code does not like +branch, and I don't like it either
[14:59] <vila> bialix: just deleting it from the start should make your guesses as good as they were before
[14:59] <bialix> vila: if I do `bzr branch lp:qbzr` then I got parent URL as bzr+ssh://b.l.n/+branch/qbzr
[15:00] <vila> bialix: you know how to guess: bzr+ssh:/b.l.n/qbzr ?
[15:00] <bialix> 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] <bialix> vila: do you know how to create it?
[15:01] <vila> create what ?
[15:01] <bialix> that parent URL: bzr+ssh:/b.l.n/qbzr
[15:01] <jam> bialix: that is the wrong parent, though
[15:01] <jam> that path doesn't exist
[15:01] <jam> +branch/qbzr does
[15:01] <bialix> I've just showed you what bzr creates for different cases
[15:01] <vila> bialix: I think it doesn't exist, that's why +branch has been created
[15:01] <jam> bialix: +branch was specifically created to allow server-side expansion of lp: urls
[15:01] <vila> bialix: so lp can redirect properly
[15:01] <jam> To support private branches
[15:01] <jam> etc
[15:01] <jam> vila: no redirect
[15:02] <jam> it maps the virtual fs to include those paths
[15:02] <bialix> before it was always bzr+ssh://b.l.n/~team/project/branch
[15:02] <jam> bialix: It was about 3-6months ago Launchpad switched
[15:02] <vila> jam: yeah, redirect not in the HTTP sense, bzr+ssh is not HTTP anyway
[15:02] <jam> because XMLRPC can't expand private branches
[15:02] <jam> vila: sure, just mentioning that "cat +branch/bzr/.bzr/branch-format" is a valid thing to do in the VFS
[15:02] <bialix> jam: I need a cheap way to extract project name from new urls
[15:03] <jam> bialix: if you look at the new bzr.dev LaunchpadDirectory, you can see the basic rules
[15:03] <jam> lp:ONE
[15:03] <jam> ONE must be the project name
[15:03] <bialix> will it work locally?
[15:03] <jam> lp:ONE/TWO
[15:03] <jam> ONE is the project name, TWO is the series name
[15:03] <jam> not related to branch
[15:03] <jam> though it maps to a branch
[15:03] <jam> if there is a ~ then it must be a fully qualified path
[15:04] <jam> lp:~user/PROJECT/BRANCH
[15:04] <bialix> jam: I'm reading lp_directory.py but I don't see what can help me?
[15:04] <jam> there are a few special cases for handling "ubuntu" and "debian"
[15:04] <maxb> OR one/two is a distro/series
[15:04] <maxb> nuh-uh, they are not special casea
[15:04] <jam> maxb: one/two can only be distro/project
[15:04] <bialix> jam: I need a way to extract project name from bzr+ssh://b.l.n/something
[15:04] <jam> maxb: unless you can somehow branch an entire series
[15:05] <jam> (lp:ubuntu/bzr, for example)
[15:05] <jam> bialix: and you are trying to do it now that we have +branch syntax?
[15:06] <maxb> jam: lp:one/two can be project/series or distro/series
[15:06] <bialix> 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] <maxb> um, no
[15:06] <maxb> I mean...
[15:06] <maxb> jam: lp:one/two can be project/series or distro/package
[15:06] <bialix> jam: yes
[15:07] <jam> 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] <jam> which we can hint at, by just hard-coding the obvious ones
[15:07] <jam> aka, special cased
[15:07] <maxb> Ah, sure. Yes, the syntax doesn't tell you the type of pillar involved
[15:08] <jam> 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] <jam> so you'll still want that logic
[15:08] <jam> for everything else
[15:08] <jam> bzr+ssh://b.lp.net/+branch/SOMETHING
[15:08] <jam> I would treat it as:
[15:08] <jam> parts = something.split('/')
[15:08] <jam> if len(parts) == 1:
[15:08] <jam>   project = parts[0]
[15:08] <jam> elif:
[15:09] <jam>   parts[0] in ( 'debian', 'ubuntu'):
[15:09] <jam>  # punt for now
[15:09] <jam> else:
[15:09] <jam>   project = parts[0]
[15:09] <jam> the debian/ubuntu rules are a bit complex
[15:09] <jam> because you can have
[15:09] <jam> ubuntu/bzr
[15:09] <jam> ubuntu/natty/bzr
[15:09] <jam> ubuntu/natty/bzr/branch
[15:10] <jam> I don't think you can have 'ubuntu/bzr/branch'
[15:10] <bialix> omg
[15:10] <maxb> You can't have the 4-part one
[15:10] <jam> (If you specify a branch, you have to specify the distroseries)
[15:10] <jam> maxb: ah, you have to specify the user in that case as well?
[15:10] <maxb> yes
[15:10] <jam> in which case it becomes ~user/ubuntu/natty/bzr/branch
[15:10] <maxb> I think there's a much simpler way to describe this:
[15:11] <maxb> If it starts with a ~, then it's a fully qualified unique name starting with a user
[15:11] <bialix> jam: all that stuff scaries me almost to death; may I file a feature request to add decoder into lp plugin?
[15:11] <maxb> 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] <maxb> 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] <bialix> maxb: do you mean the case bzr+ssh://b.l.n/+branch/~user/ubuntu/natty/bzr/branch ?
[15:13] <maxb> 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] <bialix> maxb: no, this won't work for me
[15:14] <maxb> why not?
[15:14] <bialix> maxb: I need project name to create a push url suggestion as: lp:~user/PROJECT/new-branch
[15:15] <maxb> yes?
[15:15] <maxb> I just suggested a simple algorithm to get it
[15:15] <bialix> yes, thanks, but I need project name
[15:16] <vila> bialix: that's what maxb suggested: how to get the project name
[15:16] <vila> bialix: presumably from the remember parent location
[15:16] <bialix> yes, that's exactly my case
[15:17] <vila> 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] <vila> citing maxb^
[15:18] <bialix> vila, maxb: before I always had only scheme://host/~user-id/project-name/branch-name/
[15:19] <bialix> I don't need to stick lp: on the front
[15:19] <bialix> today I see more cases:
[15:19] <bialix> scheme://host/+branch/project-name
[15:19] <bialix> scheme://host/+branch/project-name/series-name
[15:19] <vila> 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] <bialix> ok, that's enough
[15:20] <vila> .. scheme
[15:21] <vila> 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] <bialix> that was my initial question: can I use launchpad plugin to do this or not
[15:22] <vila> 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] <maxb> 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] <vila> bialix: are you trying to solve this problem in a server-agnostic way ?
[15:23] <vila> bialix: because we only answered about the lp specifics so far
[15:24] <vila> bialix: and it seems we are not all on the same page
[15:25] <bialix> vila: I'm trying to solve this problem in qbzr-unrelated way
[15:26] <vila> bialix: but in a lp-specific way ?
[15:26] <bialix> I can live with the suggested way, but if I can use lp plugin for that I'd be happy
[15:26] <bialix> vila: yes, for generic case we have different code
[15:26] <bialix> I can point you to the real code, if you wish
[15:27] <maxb> http://paste.ubuntu.com/586468/
[15:27] <maxb> I have just typed up a quick refcard to the various URL forms ^^^
[15:28] <vila> bialix: AFAIK, the lp plugin doesn't provide such a feature, but this sounds like a good one to add
[15:29] <bialix> maxb: what should I use for distro/package then?
[15:29] <vila> bialix: so file a wishlist bug and add a patch or a pointer to your implementation
[15:29] <vila> bialix: if you want to propose a push location, you should probably respect dsitro/package
[15:30] <vila> 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] <vila> maxb: isn't it ? ^
[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:31] <maxb> vila: Mostly not, no.
[15:31] <maxb> bialix: lp:~user/ubuntu/current-ubuntu-development-series/bzr/somename
[15:31] <bialix> 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] <maxb> Yes
[15:32] <vila> and that's good for upstream branches (AIUI) not for packaging branches
[15:33] <bialix> so? should I ignore any attempts to suggest URL for distro or not?
[15:33] <maxb> 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] <maxb> 15:31 < maxb> bialix: lp:~user/ubuntu/current-ubuntu-development-series/bzr/somename
[15:33] <bialix> vila: http://paste.ubuntu.com/586468/
[15:33] <bialix> DISTRO/SOURCEPACKAGE, DISTRO/SERIES/SOURCEPACKAGE, DISTRO/POCKET/SOURCEPACKAGE ?
[15:34] <bialix> what will be "project-name" here?
[15:34] <maxb> THERE IS NO PROJECT NAME
[15:34] <bialix> what is "current-ubuntu-development-series"?
[15:34] <maxb> The name of the current ubuntu development series
[15:35] <maxb> natty, for now. Later it will be oneiric
[15:35] <vila> bialix: PROJECTNAME ~= SOURCEPACKAGE (/me runs before maxb yells)
[15:35]  * maxb wonders what kind of operator ~= is :-?
[15:35] <vila> bialix: the difference is that a "project* can be the source for several packages
[15:36] <vila> maxb: the handwavy version of = :D
[15:36] <maxb> well, it could be, but yuck. It nearly never is
[15:36] <maxb> (one project multiple packages, that is)
[15:36] <vila> maxb: right, but in bialix case it would be what his code recognize as project name in the parent location
[15:37] <vila> hence the hand wave
[15:37] <maxb> Well, for bialix' specific use case it's more like PROJECTNAME ~= DISTRO/SERIES/SOURCEPACKAGE
[15:38] <vila> maxb: oh ! Certainly ! (The handwavy operators are very welcoming operators ;)
[15:39]  * maxb needs to step afk for a bit, back later
[15:39] <bialix> I'm going to blacklist distro case, it drives me crazy. no need to yell, I'm not totally stupid, just a bit
[15:39] <vila> :-D
[15:40] <vila> the distro/series/sourcepackage is certainly hard to grasp
[15:46] <bialix> distro can be only [ubuntu, debian], right?
[15:47] <vila> bialix: so far, and AIUI, yes
[15:50] <bialix> vila, maxb, jam: what I have in the end: http://paste.ubuntu.com/586484/
[15:52] <jam> bialix: do you care to support "bazaar.qastaging.launchpad.net" and those variants?
[15:53] <bialix> jam: should I?
[15:53] <jam> it also looks like you aren't handling "lp:ubuntu/bzr" but that's up to you
[15:53] <jam> bialix: none of those are long-term available (if you push data there, it gets wiped later)
[15:53] <jam> people use it for testing
[15:53] <bialix> jam: I don't understand how to handle distros case
[15:54] <bialix> jam: that check for host has been written by Ian, I'll be happy to extend it if you teach me
[15:55] <jam> well, it looks like he was trying to support "qastaging.bazaar.launchpad.net" but that isn't how it is actually spelled
[15:56] <jelmer> jam: interesting to read that performance analysis...
[15:59] <jam> bialix: http://paste.ubuntu.com/586487/
[15:59] <jam> handles DISTRO and special launchpad servers
[15:59] <jam> jelmer: the twisted stuff?
[15:59] <jelmer> jam: yeah
[16:00] <jam> jelmer: it is a bit tricky to dig in. For some reason Twisted is breaking cProfile/lsprof linking
[16:00] <jam> so you see "A called B", but a *different* "B' called C"
[16:00] <jam> works ok in text mode, but KCacheGrind doesn't give nice graphs
[16:01] <jam> jelmer: I originally wasn't sure how much to pull on this, but it certainly yielded some interesting results
[16:01] <jelmer> jam: Yeah, indeed. It looks like there is a lot of time to be gained here.
[16:02] <jam> 30ms local operation becoming 500ms seemed like something worth poking at
[16:10] <bialix> jam: thanks
[16:21] <CaMason> can a bzr branch operate/exist without a working copy?
[16:24] <CaMason> ah `bzr remove-tree`
[16:34] <jelmer> yep
[16:34] <jelmer> or, if you didn't want to create the tree in the first place: bzr branch --no-tree