| === jasono is now known as Jasono | ||
| poolie | hi all | 00:56 |
|---|---|---|
| spiv | Hi poolie | 00:56 |
| poolie | hi spiv | 00:56 |
| 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:00 |
| 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:07 |
| poolie | jaricanese7, it will, it's just slowly passing through the sru process | 01:09 |
| 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:10 |
| jaricanese7 | I was hoping not having to use the PPA but I guess that'd what I'll have to do | 01:11 |
| poolie | let me check | 01:13 |
| === Fuu` is now known as Fuu | ||
| jaricanese7 | Just curious, is this something I can do? As a community member, package this? Or only Bazaar developers can do this? | 01:24 |
| spiv | Hmm, I'm not sure where the delays are atm. | 01:27 |
| spiv | I don't think it's in packaging. | 01:28 |
| 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:29 |
| jaricanese7 | I see | 01:31 |
| jaricanese7 | That's weird | 01:31 |
| poolie | it's with jelmer or me pushing on it | 01:31 |
| 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:32 |
| 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:45 |
| poolie | - support just __getitem__ | 01:46 |
| poolie | - subclass UserDict? | 01:46 |
| spiv | poolie: you could subclass dict | 01:50 |
| spiv | Although I think any of those options is fine. | 01:50 |
| 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:51 |
| poolie | oh i guess just subclassing dict would be simpler | 01:52 |
| 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:55 |
| 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:56 |
| poolie | no | 01:57 |
| poolie | it shouldn't be | 01:57 |
| poolie | wow, ben always surprises me | 02:54 |
| poolie | why build a package and not even try to install it? | 02:54 |
| 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:55 |
| poolie | i guess it would be like wrestling a pig to ask why | 02:56 |
| === psynaptic is now known as psynaptic|away | ||
| lifeless | spiv: ping | 07:23 |
| 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:24 |
| 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 |
| ubot5 | 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 |
| spiv | Which judging from chatting with wgrant earlier today is probably due to the previously failing imports being relatively stale | 07:25 |
| 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:26 |
| 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:27 |
| lifeless | bug 520412 is 'lp crashes when given bad input' | 07:28 |
| ubot5 | 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 |
| 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:28 |
| 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:29 |
| lifeless | it needs a review_types=[''] I think | 07:30 |
| 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:31 |
| 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:32 |
| vila | I was able to reproduce locally at one point, can try lifeless proposal | 07:33 |
| vila | but we'll still need to deploy on jubany which is... hard these days :-/ | 07:34 |
| vila | ha, rt #44761, nothing happened since friday... | 07:35 |
| 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:36 |
| vila | spiv: and the importer restarted with care | 07:37 |
| 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:38 |
| 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:40 |
| 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:41 |
| spiv | vila: just grep for createMergeProposal | 07:42 |
| vila | spiv: not commented here (lp:udd) | 07:42 |
| vila | spiv: where are you looking ? | 07:43 |
| spiv | vila: http://bazaar.launchpad.net/+branch/udd/view/head:/import_package.py#L513 | 07:44 |
| vila | argh james_w pushed 8-/ | 07:45 |
| vila | spiv: anyway, given the commit dates, this has been deployed after we had the ValueErrors AFAICS | 07:47 |
| 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:48 |
| vila | spiv: given the commit messages, it looks like james_w was working on this though | 07:50 |
| 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:51 |
| 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:52 |
| vila | spiv: trying | 07:53 |
| vila | spiv: don't forget to commit your delete_branch stuff by the way ;) | 07:53 |
| 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:57 |
| 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. | 07:59 |
| 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:00 |
| vila | haa, bad request again for kde-l10n-th | 08:02 |
| 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:03 |
| spiv | vila: 500 | 08:04 |
| vila | gobject-introspection finally passed, pfew | 08:07 |
| spiv | vila: see bug 520412 for the LP bug an incorrect call to createMergeProposal triggers | 08:07 |
| ubot5 | 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:07 |
| vila | bah, I hate software that tells me: "Hey, your input is wrong, here is how to fix it". | 08:09 |
| vila | JFDI ! | 08:09 |
| 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:10 |
| spiv | vila: so long as there is 0 ambiguity about the fix, I tend to agree | 08:11 |
| 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:13 |
| 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:14 |
| 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:15 |
| vila | no idea about that, but I'd be surprised (choked?) that this went unnoticed in the p-i for so long... | 08:16 |
| vila | anyway, if we can fix it in the p-i, we should | 08:17 |
| spiv | vila: http://bazaar.launchpad.net/+branch/udd/revision/410 | 08:18 |
| ubot5 | Error: Launchpad bug 410 not found | 08:18 |
| vila | ubot5: +1 ;) | 08:18 |
| 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:19 |
| vila | spiv: and sorry for being so dense, I need more coffee ;) | 08:20 |
| * vila notes: stop presuming that untested code works | 08:20 | |
| spiv | vila: no worries | 08:21 |
| * spiv logs off for the day | 08:21 | |
| vila | spiv: one last thing: poolie is still having trouble with his ADSL modem right ? | 08:22 |
| vila | 5 babune slaves failing on bzrlib.tests.test_revisionspec.TestRevisionSpec_date.test_yesterday | 08:28 |
| vila | don't tell me, someone didn't fully get what DST is about ? | 08:29 |
| jelmer | moin | 08:39 |
| spiv | vila: yes | 08:50 |
| vila | jelmer: hi ! | 08:51 |
| * jelmer waves to spiv and vila | 08:52 | |
| 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:53 |
| jelmer | spiv: Sorry this was necessary, my review of your fetch tags branch wasn't very good. :-/ | 08:54 |
| 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:55 |
| 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:56 |
| jelmer | spiv: It seems reasonable to have Branch.fetch() as a convenience wrapper around Repository.fetch | 08:57 |
| jelmer | spiv: yeah | 08:57 |
| bialix | heya | 09:21 |
| 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:22 |
| 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:23 |
| 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:24 |
| ubot5 | Error: Launchpad bug 2 not found | 09:24 |
| bialix | vila: ok, I see the 2.4b2 section now. most likely yesterday I've used slightly outdated truk | 09:25 |
| bialix | trunk | 09:26 |
| bialix | vila: thank you | 09:26 |
| vila | bialix: np | 09:26 |
| bialix | oh yes, forgot to update my copy of bzr.dev, heh | 09:28 |
| vila | fullermd: weird, ended up with .. 90 new ports/files only | 09:35 |
| === 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 | ||
| alexKeith | hi there | 13:52 |
| alexKeith | i'm new to VCS and stuff | 13:52 |
| 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:53 |
| jelmer | hi alexKeith | 13:55 |
| jelmer | alexKeith: it looks like either an issue on your side or on Launchpad's side | 13:55 |
| alexKeith | jelmer: in the application on the connection? | 13:56 |
| jelmer | alexKeith: in the connection | 13:57 |
| jelmer | alexKeith: I doubt it's an application issue if it worked ok earlier | 13:57 |
| alexKeith | jelmer: hmmm... thanks for the suggestion.. will wait a few more hours | 13:58 |
| 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:27 |
| Peng | I suppose you could write a plugin... | 14:31 |
| Peng | I believe pygame is your best option for audio output. ;-) | 14:32 |
| 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:37 |
| 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:38 |
| 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:39 |
| vila | lamont: I meant 'bzr alias uncommit=I_HATE_YOU_DONT_DO_THAT' to take screaming into account | 14:40 |
| === 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) | ||
| lamont | vila: yeah - but I want it to affect the branch, not the user... | 14:41 |
| 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:42 |
| 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:43 |
| 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:44 |
| 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:45 |
| vila | lamont: it breaks the shared branch history ? | 14:46 |
| lamont | vi bzr pull in a cronjob | 14:46 |
| lamont | via | 14:46 |
| 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:47 |
| 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:48 |
| vila | lamont: 'bzr config' ? | 14:50 |
| lamont | bzr: ERROR: unknown command "config" | 14:50 |
| vila | :-/ | 14:50 |
| 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:51 |
| 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:52 |
| 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:53 |
| lamont | vila: yay | 14:54 |
| vila | bialix: the translation is done on lp, you have no way to emulate that | 14:55 |
| vila | bialix: what's the need ? | 14:55 |
| vila | bialix: jam has been playing with the xmlrpc code and should have the details in his hot cache ;) | 14:56 |
| lamont | afk | 14:56 |
| 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:57 |
| * vila happily shudders | 14:58 | |
| bialix | vila: we have a code in qbzr to automatically guess the project name based on lp URL | 14:58 |
| 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 | 14:59 |
| 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:00 |
| 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:01 |
| 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:02 |
| 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:03 |
| 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:04 |
| jam | (lp:ubuntu/bzr, for example) | 15:05 |
| jam | bialix: and you are trying to do it now that we have +branch syntax? | 15:05 |
| 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:06 |
| 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:07 |
| 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:08 |
| 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:09 |
| 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:10 |
| 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:11 |
| 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:12 |
| 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:13 |
| 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:14 |
| 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:15 |
| 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:16 |
| 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:17 |
| bialix | vila, maxb: before I always had only scheme://host/~user-id/project-name/branch-name/ | 15:18 |
| 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:19 |
| bialix | ok, that's enough | 15:20 |
| vila | .. scheme | 15:20 |
| 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:21 |
| 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:22 |
| 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:23 |
| vila | bialix: and it seems we are not all on the same page | 15:24 |
| bialix | vila: I'm trying to solve this problem in qbzr-unrelated way | 15:25 |
| 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:26 |
| maxb | http://paste.ubuntu.com/586468/ | 15:27 |
| maxb | I have just typed up a quick refcard to the various URL forms ^^^ | 15:27 |
| vila | bialix: AFAIK, the lp plugin doesn't provide such a feature, but this sounds like a good one to add | 15:28 |
| 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:29 |
| 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:30 |
| 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:31 |
| maxb | Yes | 15:32 |
| vila | and that's good for upstream branches (AIUI) not for packaging branches | 15:32 |
| 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:33 |
| 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:34 |
| 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:35 |
| 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:36 |
| vila | hence the hand wave | 15:37 |
| maxb | Well, for bialix' specific use case it's more like PROJECTNAME ~= DISTRO/SERIES/SOURCEPACKAGE | 15:37 |
| vila | maxb: oh ! Certainly ! (The handwavy operators are very welcoming operators ;) | 15:38 |
| * 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 |
| === med_out is now known as medberry | ||
| vila | :-D | 15:39 |
| vila | the distro/series/sourcepackage is certainly hard to grasp | 15:40 |
| bialix | distro can be only [ubuntu, debian], right? | 15:46 |
| vila | bialix: so far, and AIUI, yes | 15:47 |
| bialix | vila, maxb, jam: what I have in the end: http://paste.ubuntu.com/586484/ | 15:50 |
| jam | bialix: do you care to support "bazaar.qastaging.launchpad.net" and those variants? | 15:52 |
| 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:53 |
| bialix | jam: that check for host has been written by Ian, I'll be happy to extend it if you teach me | 15:54 |
| jam | well, it looks like he was trying to support "qastaging.bazaar.launchpad.net" but that isn't how it is actually spelled | 15:55 |
| jelmer | jam: interesting to read that performance analysis... | 15:56 |
| 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 | 15:59 |
| 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:00 |
| 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:01 |
| jam | 30ms local operation becoming 500ms seemed like something worth poking at | 16:02 |
| bialix | jam: thanks | 16:10 |
| CaMason | can a bzr branch operate/exist without a working copy? | 16:21 |
| CaMason | ah `bzr remove-tree` | 16:24 |
| jelmer | yep | 16:34 |
| jelmer | or, if you didn't want to create the tree in the first place: bzr branch --no-tree | 16:34 |
| === deryck is now known as deryck[lunch] | ||
| === beuno is now known as beuno-lunch | ||
| === beuno-lunch is now known as beuno | ||
| === deryck[lunch] is now known as deryck | ||
| === Ursinha is now known as Ursinha-lunch | ||
| === psynaptic|food is now known as psynaptic | ||
| === Ursinha-lunch is now known as Ursinha | ||
Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!