| === verterok_ is now known as verterok | ||
| thumper | can I set remote locations in locations.conf? | 00:14 |
|---|---|---|
| thumper | like Launchpad? | 00:15 |
| lifeless | yes | 00:21 |
| === kiko is now known as kiko-zzz | ||
| mwhudson | hm | 01:05 |
| mwhudson | does anyone have a nice rsync recipe for copying all the .bzr directories and contents out of a directory tree, but not the working trees? | 01:05 |
| lifeless | not offhand | 01:06 |
| lifeless | -i **/.bzr or something, I guess | 01:06 |
| mwhudson | ah, i'd missed the top down application of rules | 01:13 |
| lifeless | \o/ :!./bzr --no-plugins selftest intertree.test_compare.*test_specific -x '\(C\)' | 01:45 |
| lifeless | passing | 01:45 |
| lifeless | poolie: spiv: review requested please | 01:50 |
| lifeless | my dirstate infrstructure change will be blocking a later review in about 2 hours. Maybe less | 01:50 |
| SamB | what is the preferred way to assert that something is either an iterable or None? | 02:04 |
| poolie | SamB in a test? | 02:08 |
| poolie | SamB i guess i'd first ask, is that really what you want to test? | 02:09 |
| poolie | don't you know which one it should be? | 02:09 |
| poolie | but, if you did want that then i guess i'd do | 02:09 |
| poolie | if result != None: | 02:10 |
| poolie | l = list(result) | 02:10 |
| SamB | poolie: not in a test | 02:10 |
| SamB | in a method | 02:10 |
| poolie | then either assert something about l or just add a comment that the cast will fail | 02:10 |
| lifeless | poolie: 'result is not None' | 02:11 |
| SamB | actually, now I'm not sure what type this argument is supposed to be | 02:11 |
| poolie | oh noes | 02:11 |
| poolie | SamB: in general we don't make assertions about arguments | 02:11 |
| poolie | unless either the api changed or it's error prone | 02:11 |
| poolie | and in the second case it's better to change it | 02:11 |
| SamB | poolie: change it to what? | 02:11 |
| poolie | so just go ahead and use it in the way it should be used | 02:12 |
| poolie | if thing is not none: | 02:12 |
| poolie | return ', '.join(thing) | 02:12 |
| SamB | I just want to make sure that all the callers are passing things with a compatible interface ... | 02:12 |
| poolie | for instance, by change the api, i mean that apis that take either a string or list of strings are a really bad idea, because strings look so much like lists | 02:12 |
| lifeless | SamB: we don't do that in bzr, as a stylistic choice. | 02:13 |
| SamB | igc: what is the file_iter argument to CommitCommand.__init__ *supposed* to be? | 02:13 |
| SamB | poolie: well, some of the tests here are passing callables that return iterables, and some of them are passing iterators | 02:14 |
| SamB | right now I'm not sure which tests are right, but wouldn't it be best to check in the constructor that the arguments are remotely like we want them to be? | 02:14 |
| poolie | igc is away this week | 02:15 |
| SamB | oh :-( | 02:15 |
| poolie | sick | 02:15 |
| poolie | SamB: this might just be the python generator pattern here? | 02:16 |
| poolie | you can often treat those things as the same | 02:16 |
| poolie | (kind of vague description) | 02:16 |
| spiv | i.e., iterators are iterables. | 02:16 |
| SamB | well, the most key difference is that some of the tests pass *callables* returning iterables, but some just pass iterables | 02:17 |
| lifeless | SamB: whats CommitCommand? | 02:17 |
| SamB | it's in bp.fastimport.commands | 02:17 |
| lifeless | oh | 02:18 |
| lifeless | so, no idea. | 02:18 |
| lifeless | what we generally do is; | 02:18 |
| lifeless | - ensure the docstring is clear | 02:18 |
| SamB | yeah | 02:18 |
| lifeless | - let the caller do what they want | 02:18 |
| SamB | and I guess | 02:19 |
| SamB | - make sure the tests are consistant with the docstring | 02:19 |
| * SamB wishes fast-import had a --dry-run mode where it did *everything* except actually create the branches ... | 02:21 | |
| poolie | Samb, nice idea | 02:23 |
| poolie | spiv, there is a 1.17 branch, https://launchpad.net/bzr/1.17 | 02:23 |
| poolie | afaics you should be able to target bugs to it | 02:23 |
| lifeless | spiv: ping | 02:23 |
| poolie | note that the control is hugely mislabelled as 'target to release' | 02:23 |
| poolie | and there's a bug for that | 02:23 |
| lifeless | SamB: we don't generally need the last one :) if the tests are inconsistent with the docstring, so is the code, or the tests are failing. | 02:24 |
| poolie | well, quibble | 02:25 |
| poolie | they don't always have precisely the same information content | 02:25 |
| spiv | poolie: Ah ok. I don't fully understand the difference between setting a milestone on a bugtask and targetting to a release. | 02:26 |
| lifeless | spiv: hi you promisedish me a review yesterday. | 02:26 |
| poolie | launchpad has succeeded then :) | 02:26 |
| lifeless | spiv: targetting is a new bugtask | 02:27 |
| poolie | with its cunning strategy of labelling one as the other | 02:27 |
| lifeless | spiv: there is a link 'nominate for ...' | 02:27 |
| SamB | lifeless: yeah ... maybe | 02:27 |
| SamB | depends how often those attributes get used, possibly ... | 02:27 |
| spiv | Especially when targetting to a release then offers me a list of series, not releases, to choose from... | 02:27 |
| poolie | Bug #132733 in Launchpad Bugs: “Confusing use of the term "Target to release" on bug pages.” <https://bugs.edge.launchpad.net/malone/+bug/132733> | 02:27 |
| ubottu | Launchpad bug 132733 in malone "Confusing use of the term "Target to release" on bug pages." [Medium,Triaged] | 02:27 |
| ubottu | Launchpad bug 132733 in malone "Confusing use of the term "Target to release" on bug pages." [Medium,Triaged] https://launchpad.net/bugs/132733 | 02:27 |
| poolie | that was odd | 02:28 |
| SamB | lifeless: anyway, I figured out that using "bzr fast-import" definately results in callables being passed ... | 02:28 |
| spiv | poolie: possibly because you gave the bug # and the url? | 02:28 |
| poolie | i guess so, though it's odd the first one didn't include the url | 02:28 |
| poolie | oh maybe that's for the one that did have the url | 02:29 |
| SamB | must be! | 02:29 |
| lifeless | spiv: ping [review] - I'll keep pinging till I get ack or nack | 02:33 |
| psynaptic | so I have 2 files which I have modified which I don't want to have anything to do with what I'm doing | 02:33 |
| psynaptic | (uncommitted changes) | 02:33 |
| RenatoSilva | lifeless: quick suggestion about setup versioning. Instead of bzr-setup-1.17-1.exe, bzr-1.17-setup-1.exe | 02:33 |
| psynaptic | in git I would just not stage those files | 02:33 |
| psynaptic | how do I get around this in bzr | 02:33 |
| bob2 | psynaptic: bzr commit takes a list of files to commit | 02:33 |
| bob2 | psynaptic: or ytou can shelve the changes | 02:33 |
| lifeless | RenatoSilva: good idea! please put in a bug | 02:33 |
| lifeless | psynaptic: bzr commit -x foo -x bar, I think | 02:34 |
| psynaptic | bob2: I already committed what I wanted | 02:34 |
| psynaptic | by cding to the dir and bzr commit . -m "message" | 02:34 |
| bob2 | psynaptic: so what do you want to have happen? | 02:34 |
| psynaptic | but now it won't let me push or pull | 02:35 |
| bob2 | shelve them | 02:35 |
| lifeless | psynaptic: push --no-strict | 02:35 |
| lifeless | psynaptic: the --no-strict thing is recent, and we don't like it. we're going to make it warn rather than error | 02:35 |
| bob2 | what's the rationale for strict push? | 02:35 |
| psynaptic | I see.. my version of bzr seems old | 02:36 |
| psynaptic | no such option | 02:36 |
| lifeless | psynaptic: ok, what actually error are you getting then? | 02:36 |
| lifeless | psynaptic: we're really trying to guess at the moment | 02:36 |
| psynaptic | ok.. | 02:36 |
| SamB | bob2: it's clearly not a good enough rationale ;-) | 02:37 |
| psynaptic | bzr push bzr+ssh://user@example.com/home/cnpopen/public_html/dev | 02:37 |
| psynaptic | This transport does not update the working tree of: bzr+ssh://cnpopen@openlyconnected.com/home/cnpopen/public_html/dev/. See 'bzr help working-trees' for more information. | 02:37 |
| psynaptic | bzr: ERROR: These branches have diverged. Try using "merge" and then "push". | 02:37 |
| psynaptic | so I tried $ bzr pull | 02:37 |
| psynaptic | bzr: ERROR: These branches have diverged. Use the merge command to reconcile them. | 02:37 |
| psynaptic | so I tried $ bzr merge | 02:37 |
| psynaptic | bzr: ERROR: Working tree "/private/var/www/subdomains/cnp/" has uncommitted changes. | 02:37 |
| lifeless | psynaptic: someone else (or you from another macine) has pushed to that branch | 02:38 |
| lifeless | psynaptic: do this: | 02:38 |
| lifeless | bzr shelve --all | 02:38 |
| lifeless | bzr merge bzr+ssh://user@example.com/home/cnpopen/public_html/dev | 02:38 |
| lifeless | bzr commit | 02:38 |
| lifeless | bzr push | 02:38 |
| lifeless | bzr unshelve | 02:38 |
| lifeless | if this is a shared branch between multiple developers, you may wish to work with a checkout, which won't let you commit if someone else has pushed stuff up | 02:38 |
| psynaptic | bzr: ERROR: Working tree "/private/var/www/subdomains/cnp/" has uncommitted changes. | 02:39 |
| psynaptic | Macbook-Pro: /var/www/subdomains/cnp> bzr diff | 02:39 |
| psynaptic | === modified file 'sites/default/default.settings.php' (properties changed: +x to -x) | 02:39 |
| lifeless | psynaptic: the shelve didn't remove the change? Interesting (and a bug) | 02:40 |
| psynaptic | well | 02:40 |
| psynaptic | it removed 2 other files | 02:40 |
| psynaptic | with content changes | 02:40 |
| psynaptic | but not the property change | 02:40 |
| psynaptic | Macbook-Pro: /var/www/subdomains/cnp> bzr diff | 02:41 |
| psynaptic | === modified file 'sites/default/default.settings.php' (properties changed: +x to -x) | 02:41 |
| psynaptic | Macbook-Pro: /var/www/subdomains/cnp> bzr shelve --all | 02:41 |
| psynaptic | No changes to shelve. | 02:41 |
| psynaptic | I'll change it to +x | 02:41 |
| psynaptic | save the hassle :) | 02:41 |
| lifeless | I'll file a bug on shelve now for you | 02:41 |
| psynaptic | thanks a lot | 02:41 |
| lifeless | are you on MacOSX/linux/win32? | 02:42 |
| psynaptic | mac os x | 02:42 |
| lifeless | sent in | 02:42 |
| lifeless | sorry about that; its disconcerting to suggest a recipe that fails | 02:43 |
| * lifeless pings spiv again | 02:43 | |
| lifeless | spiv: hai | 02:43 |
| SamB | where should constructor arguments be documented -- in the class' docstring, or __init__'s? | 02:43 |
| lifeless | I prefer __init__ | 02:43 |
| lifeless | some folk use the class | 02:43 |
| SamB | any good examples? | 02:43 |
| psynaptic | lifeless: no, thanks a lot for your help | 02:44 |
| lifeless | I like to put instance and class attributes in the class docstring, and constructor params in the __init__ | 02:44 |
| lifeless | SamB: not offhand | 02:44 |
| psynaptic | so this bzr commit after the merge | 02:44 |
| psynaptic | seems to only contain the merge changes | 02:44 |
| psynaptic | should I add a merge commit message | 02:45 |
| psynaptic | then bzr add my stuff and commit/push again | 02:45 |
| lifeless | yes, something like 'Sync with dev' | 02:46 |
| psynaptic | thanks | 02:46 |
| spiv | lifeless: hi | 02:47 |
| spiv | lifeless: I'll look at it in about 15 minutes. | 02:47 |
| lifeless | spiv: thanks! | 02:47 |
| spiv | lifeless: thanks for the nags :) | 02:47 |
| psynaptic | lifeless++ | 02:47 |
| lifeless | spiv: I've finished all the python changes in the patch on top of it | 02:47 |
| lifeless | spiv: so I'm porting to pyrex, updating docs, and submitting | 02:48 |
| psynaptic | hmm, very odd | 02:54 |
| psynaptic | now I can't see my changes | 02:54 |
| psynaptic | I asked another dev to pull and it just says nothing to pull | 02:54 |
| psynaptic | there files are there in my working copy! | 02:55 |
| psynaptic | *the | 02:55 |
| psynaptic | bzr diff only shows the files that were unstashed | 02:55 |
| psynaptic | *unshelved | 02:55 |
| RenatoSilva | lifeless: bug 406099 | 02:56 |
| ubottu | Launchpad bug 406099 in bzr "Better file name for bzr windows installer" [Undecided,New] https://launchpad.net/bugs/406099 | 02:56 |
| psynaptic | what am I doing wrong! lol | 02:59 |
| bob2 | bzr missing remotebranch | 03:00 |
| psynaptic | I think I did something stupid earlier | 03:01 |
| psynaptic | bzr push origin | 03:01 |
| psynaptic | bzr branch origin | 03:01 |
| psynaptic | randomly did those 2 | 03:01 |
| psynaptic | :/ | 03:01 |
| psynaptic | I don't even know the branch I'm supposed to be working on | 03:02 |
| psynaptic | in git you can view your available branches using $ git branch | 03:02 |
| lifeless | RenatoSilva: thanks | 03:02 |
| psynaptic | in bzr the command seems to do something differnent | 03:03 |
| lifeless | psynaptic: it makes a new branch | 03:03 |
| lifeless | psynaptic: 'bzr branches' will list branches | 03:03 |
| lifeless | or you can just look on your filesystem | 03:03 |
| psynaptic | Macbook-Pro: /var/www/subdomains/cnp> bzr branches | 03:03 |
| psynaptic | origin | 03:03 |
| psynaptic | not sure I was supposed to have origin | 03:03 |
| lifeless | spiv: you may, if you're clever find bugs in the thing I've asked you to review; I won't land it independently as I'm fixing them now :) | 03:04 |
| psynaptic | but does that mean I had zero branches? | 03:04 |
| spiv | lifeless: hah | 03:04 |
| lifeless | spiv: its worth getting your feedback on the conceptual change and how its presented, regardless | 03:04 |
| bob2 | psynaptic: branches are directories | 03:05 |
| psynaptic | oh ok | 03:05 |
| lifeless | psynaptic: it means you had no other branches under your current branch | 03:05 |
| lifeless | psynaptic: you can give a url to push - bzr push <URL> | 03:05 |
| psynaptic | so I can just delete /origin in the filesystem,? | 03:06 |
| lifeless | psynaptic: ./origin, yes | 03:06 |
| psynaptic | thanks | 03:06 |
| psynaptic | I'm a bit confused because bzr diff is not showing anything but the changes I don't want to push | 03:06 |
| * RenatoSilva gtg | 03:07 | |
| psynaptic | I added the dir with the files I wanted to commit and committed them | 03:07 |
| psynaptic | but this was before this merge | 03:07 |
| psynaptic | maybe I have committed changes | 03:08 |
| psynaptic | that I haven't pushed | 03:08 |
| psynaptic | right ok | 03:09 |
| psynaptic | bzr log shows the history | 03:09 |
| bob2 | bzr missing remotebranch | 03:09 |
| bob2 | ^ changesets that aren't in both | 03:09 |
| psynaptic | what is remotebranch though? | 03:09 |
| psynaptic | Macbook-Pro: /var/www/subdomains/cnp> bzr missing remotebranch | 03:09 |
| psynaptic | bzr: ERROR: Not a branch: "/private/var/www/subdomains/cnp/remotebranch/". | 03:09 |
| psynaptic | I don't know what remotebranch is | 03:10 |
| bob2 | whatever branch you think is missing things | 03:10 |
| psynaptic | I don't know ANY branches | 03:11 |
| psynaptic | maybe HEAD? | 03:11 |
| psynaptic | master | 03:11 |
| bob2 | this isn't git | 03:11 |
| psynaptic | something like that? | 03:11 |
| lifeless | psynaptic: bzr missing bzr+ssh://cnpopen@openlyconnected.com/home/cnpopen/public_html/dev/ | 03:11 |
| psynaptic | ahh | 03:11 |
| lifeless | psynaptic: thats where you pushed to before | 03:11 |
| lifeless | its therefor a branch | 03:11 |
| psynaptic | riiight | 03:12 |
| psynaptic | You have 2 extra revision(s): | 03:12 |
| lifeless | bzr push bzr+ssh://cnpopen@openlyconnected.com/home/cnpopen/public_html/dev/ | 03:12 |
| lifeless | if you want to save that as the default this branch pushes to do | 03:12 |
| lifeless | bzr push bzr+ssh://cnpopen@openlyconnected.com/home/cnpopen/public_html/dev/ --remember | 03:12 |
| psynaptic | This transport does not update the working tree of: bzr+ssh://cnpopen@openlyconnected.com/home/cnpopen/public_html/dev/. See 'bzr help working-trees' for more information. | 03:13 |
| psynaptic | Pushed up to revision 53. | 03:13 |
| psynaptic | thanks for the tip | 03:13 |
| psynaptic | bzr update then? | 03:16 |
| psynaptic | why am I at a different revision to the repo? | 03:16 |
| psynaptic | a fellow developer says he is at rev 56 and I am at 53 | 03:16 |
| psynaptic | Macbook-Pro: /var/www/subdomains/cnp> bzr update | 03:17 |
| psynaptic | Tree is up to date at revision 53. | 03:17 |
| lifeless | psynaptic: 'update' is only useful if you are using a checkout | 03:18 |
| psynaptic | right | 03:18 |
| lifeless | you are using a separate branch, so update just checks locally and has nothing much to do | 03:18 |
| psynaptic | so do you think this method I'm using is inefficient? | 03:19 |
| lifeless | as for your fellow, they have some different stuff in their branch | 03:19 |
| psynaptic | I was given instruction on how to use their bzr repo | 03:20 |
| lifeless | bzr missing will tell them whether they have additional things, or are missing what you pushed | 03:20 |
| lifeless | branches and checkouts work very similarly | 03:20 |
| psynaptic | why can't we push to the same branch? | 03:20 |
| lifeless | you can, but you'll end up changing commit orders a lot | 03:21 |
| psynaptic | right | 03:21 |
| lifeless | checkouts automate that for you | 03:21 |
| * psynaptic pasted http://pastie.textmate.org/private/makewfs23qan1jwpxwuu0a | 03:22 | |
| psynaptic | this is what we were told to do | 03:22 |
| psynaptic | there are 5 devs | 03:22 |
| poolie | spiv, i filed bug 406113 | 03:22 |
| ubottu | Launchpad bug 406113 in bzr "need checks or tests that compiled extensions are loaded properly" [High,Confirmed] https://launchpad.net/bugs/406113 | 03:22 |
| psynaptic | all working in their own environment | 03:22 |
| poolie | did you catch jam at all? | 03:23 |
| lifeless | psynaptic: for that situation I'd be inclined to use two branches | 03:23 |
| psynaptic | how would that work? | 03:24 |
| lifeless | one sec | 03:24 |
| lifeless | http://paste.ubuntu.com/235578/ | 03:26 |
| psynaptic | lifeless: ahh I see | 03:27 |
| psynaptic | thanks for taking the time to do that for us | 03:28 |
| psynaptic | looks like a good idea | 03:28 |
| psynaptic | I have added it to our project wiki so hopefully we can start using it | 03:30 |
| psynaptic | so what does "This transport does not update the working tree of: bzr+ssh://cnpopen@openlyconnected.com/home/cnpopen/public_html/dev/. See 'bzr help working-trees' for more information." actually mean? | 03:31 |
| psynaptic | is it important? | 03:31 |
| bob2 | working tree = checked out files | 03:31 |
| psynaptic | are my changes actually in the central repo? | 03:32 |
| psynaptic | yeah, I get that bit | 03:32 |
| bob2 | push will update the branch data, but it won't update the checked out files | 03:32 |
| psynaptic | ok, so in this case it will update the central server but not my own working copy | 03:32 |
| bob2 | "push will update the branch data, but it won't update the checked out files" [on the remote server] | 03:33 |
| bob2 | push has nothing to do with updating your local working copy | 03:33 |
| psynaptic | that's what I thought was the working copy | 03:34 |
| psynaptic | but you have a working copy on the server too, yes | 03:34 |
| psynaptic | right | 03:34 |
| psynaptic | I'm still no closer to understanding | 03:35 |
| lifeless | spiv: actually, the bug is in a local change anyway; that branch should be independently golden | 03:35 |
| psynaptic | it's probably just too late for me today | 03:35 |
| psynaptic | 3.35am | 03:35 |
| psynaptic | not a great time to be trying to work out somewhat abstract ideas | 03:35 |
| bob2 | so, your "branch" is really three things: a working copy (the checked out files), the repository (all the revision data) and the branch (a pointer to a series revisions in the repository). they're each in a separate dir in .bzr | 03:36 |
| psynaptic | ok | 03:36 |
| poolie | lifeless/spiv: quick yeah/nay sought on bug 406113 - specifically, whining about missing extensions unless BZR_PURE_PYTHON=1 | 03:36 |
| ubottu | Launchpad bug 406113 in bzr "need checks or tests that compiled extensions are loaded properly" [High,Confirmed] https://launchpad.net/bugs/406113 | 03:36 |
| bob2 | push updates the remote branch and repository, but not the working copy. "update" updates the working copy | 03:36 |
| psynaptic | right | 03:37 |
| lifeless | poolie: I don't think we should whine | 03:37 |
| psynaptic | so how do I see that my changes where pushed into the remote repo? | 03:37 |
| poolie | or erorr | 03:37 |
| psynaptic | so I can happily go to bed | 03:37 |
| bob2 | bzr missing urltoremotebranch | 03:37 |
| lifeless | poolie: I think we should make bzr --version, or similar, make it clear if there are any missing extensions, and get build scripts to grep the output | 03:37 |
| poolie | that would be another option | 03:38 |
| poolie | not very obvious though | 03:38 |
| psynaptic | Branches are up to date. | 03:38 |
| bob2 | excellent! | 03:38 |
| poolie | could also go in backtraces, though lack of them is unlikely to cause tracebacks | 03:38 |
| bob2 | ah, also, "bzr log urltoremotebranch" | 03:38 |
| lifeless | poolie: for debs etc it doesn't matter how obvious it is, as we should be checking it and failing the build anyway | 03:38 |
| poolie | lifeless: but, anyhow - why not? | 03:38 |
| lifeless | poolie: its only for people that grab a tarball or branch bzr themselves that the obviousness matters | 03:39 |
| poolie | or for cases where there's a hole in the previous process | 03:39 |
| lifeless | and we already make setup.py die if the extensions don't build | 03:39 |
| lifeless | poolie: which is why I'm suggesting we patch the previous process usin the same logic as whining would | 03:39 |
| psynaptic | thanks bob2 | 03:39 |
| lifeless | as for why not, well I don't like programs that whine at me | 03:40 |
| lifeless | it gives a bad impression | 03:40 |
| lifeless | and I don't think our users will like it either | 03:40 |
| poolie | you think most people who don't have extensions loading have made an informed decision not to have them? | 03:41 |
| psynaptic | if I do bzr commit and I have added files, modified and unknown.. will only added get committed? | 03:41 |
| poolie | or at least would agree with it if asked? | 03:41 |
| lifeless | poolie: most people with the power to fix it, yes. | 03:41 |
| psynaptic | or should I back out and shelve | 03:41 |
| lifeless | psynaptic: added and modified will be committed | 03:41 |
| psynaptic | thanks | 03:42 |
| lifeless | psynaptic: if you run 'bzr commit',it will list the things being committed in the editor window | 03:42 |
| psynaptic | I did that :) | 03:42 |
| poolie | hm, i don't think so | 03:42 |
| psynaptic | but it doesn't make a distinction in that output | 03:42 |
| poolie | why would they want that? | 03:42 |
| psynaptic | I know now tho | 03:42 |
| psynaptic | thanks | 03:42 |
| lifeless | psynaptic: everything it lists will be committed ;) | 03:43 |
| lifeless | psynaptic: except for unknowns | 03:43 |
| lifeless | poolie: e-thread-lost | 03:43 |
| poolie | i think running without compiled extensions should be very opt-in | 03:44 |
| poolie | more so than at present | 03:44 |
| psynaptic | thanks lifeless and bob2, I can get some sleep now! | 03:47 |
| lifeless | poolie: so, I'd like to discuss this, but not now. | 03:47 |
| thumper | lifeless: how to I tell pqm-submit that I don't have a local copy of a branch? | 03:48 |
| psynaptic | c u :D | 03:48 |
| lifeless | thumper: I don't know; pqm-submit --help may. | 03:48 |
| poolie | i'll try it, if it works propose a merge, and we can handle it there | 03:48 |
| thumper | damn | 03:48 |
| thumper | I don't think I can | 03:48 |
| lifeless | poolie: What I think is that the people *doing builds* should do the QA | 03:48 |
| thumper | which kinda sucks | 03:48 |
| lifeless | poolie: not everyone executing bzr | 03:48 |
| thumper | I'm trying to submit jml's branch for him | 03:48 |
| poolie | thumper: either branch it yourself | 03:48 |
| poolie | or make up a submit message by hand | 03:49 |
| poolie | use --dry-run to see a template | 03:49 |
| thumper | huh, good point | 03:49 |
| lifeless | thumper: bzr pqm-submit LOCATION | 03:49 |
| lifeless | thumper: did you try LOCATIOn? | 03:49 |
| thumper | yes | 03:49 |
| poolie | also please do merges inside launchpad, thanks :) | 03:49 |
| thumper | poolie: :) | 03:49 |
| lifeless | poolie: do you mean landing target stuff? lp can | 03:49 |
| thumper | it is on my mega plan | 03:49 |
| lifeless | just need a queue hooked in for pqm | 03:50 |
| thumper | lifeless: we don't have queues in LP yet | 03:50 |
| thumper | lifeless: well, not exposed anyway | 03:50 |
| lifeless | thumper: how does tarmac work then? :P | 03:50 |
| thumper | lifeless: it just grabs all approved ones | 03:50 |
| JoaoJoao | hello | 03:50 |
| lifeless | thumper: thats a queue, effectively. | 03:50 |
| thumper | lifeless: it isn't an ordered queue | 03:50 |
| thumper | grr! | 03:51 |
| lifeless | though personally, I would really want a button to say 'ok land this now', separate from approval to dosol | 03:51 |
| JoaoJoao | Is there any way to shelve changes to binary files? | 03:51 |
| lifeless | JoaoJoao: bzr shelve --all, should do so | 03:51 |
| lifeless | poolie: anyhow, I'm worried that bzr whinging will not prevent bad debs, and will annoy a very large number of users very quickly | 03:52 |
| poolie | ... because there's a large number of user who're using the slow python implementations and like it that way? | 03:53 |
| JoaoJoao | lifeless: does it also work with bzrtool's shelve? (shelve1 on windows) | 03:54 |
| lifeless | JoaoJoao: no | 03:54 |
| JoaoJoao | :( | 03:54 |
| lifeless | poolie: no, because *when a bad deb is made* a lot of users get flipped from C to python in one hit. | 03:54 |
| JoaoJoao | no go to me then | 03:55 |
| lifeless | JoaoJoao: sorry :( | 03:55 |
| lifeless | JoaoJoao: you could commit the file, uncommit and revert it | 03:55 |
| lifeless | and then use merge -r revid:xxxx, to restore it later | 03:55 |
| poolie | yeah, if we add this we'd presumably want to check it in the deb build process | 03:55 |
| lifeless | poolie: and thats my point, if we check it in the deb, I don't think we need to be obvious at runtime for users. | 03:56 |
| lifeless | we already check in setup.py | 03:56 |
| JoaoJoao | lifeless: that would work, but too much of a hassle to me... thanks for the tip anyway | 03:56 |
| lifeless | its just that the setup.py check doesn't check that the things built are used afterwards | 03:56 |
| lifeless | (there is a bug about builds on karmic, they put the .so's in bzrlib/bzrlib/*.so | 03:57 |
| lifeless | which setup.py should arguably catch as well | 03:57 |
| thumper | just for a laugh: bzr branch lp:hg-git :-) | 04:16 |
| * SamB hopes the LP devs remembered to use bignum for bug numbers rather than fixnum ;-) | 04:16 | |
| meaton2veggies | Hey all, I'm after a bzr pkg (v1.17.1) for Ubuntu Jaunty powerpc (arch)? Can't use Karmic as want to install Launchpad | 04:21 |
| mwhudson | meaton2veggies: it's probably easy enough to build from source using the source package bits in the ppa? | 04:22 |
| meaton2veggies | mwhudson: ok great, is there any doco for building bzr from src | 04:24 |
| mwhudson | meaton2veggies: it's just 'debuild' isn't it? | 04:24 |
| lifeless | debget <<.....dsc>> | 04:27 |
| lifeless | then dpkg-buildpackage | 04:27 |
| lifeless | or debuild | 04:27 |
| meaton2veggies | lifeless: thanks | 04:27 |
| lifeless | spiv: I'm landing that branch w/o the fixes- they are in my next patch anyhoo, ok ? | 05:01 |
| lifeless | I'm down to three failures on the pyx code | 05:02 |
| spiv | lifeless: sure | 05:10 |
| lifeless | 2 failures | 05:12 |
| lifeless | \o/ | 05:30 |
| lifeless | guess what | 05:30 |
| poolie | way to go robot | 05:38 |
| lifeless | I'm integrating/improving the docs now | 05:40 |
| lifeless | then its up for review, and qa to see if it improves commit :) | 05:40 |
| meaton2veggies | lifeless: installed deps for building, however error on install of packages trying to do 'make DEST=blah install' | 05:55 |
| meaton2veggies | lifeless: should this be changed to something in debian/rules? | 05:55 |
| lifeless | meaton2veggies: hmm? | 05:59 |
| meaton2veggies | python setup.py? | 06:00 |
| lifeless | meaton2veggies: dpkg-buildpackage | 06:00 |
| lifeless | this will build a debfor you | 06:00 |
| lifeless | then you can install the ppc deb | 06:00 |
| lifeless | isn't that what you wanted? | 06:00 |
| meaton2veggies | yes | 06:01 |
| meaton2veggies | but its failing on install part, compiles fine | 06:01 |
| lifeless | pastebin? | 06:01 |
| lifeless | spiv: now, if you want dirstate patches to review | 06:02 |
| lifeless | 112K of bundle on its way to lp now | 06:02 |
| meaton2veggies | http://pastebin.com/d3905e25a | 06:03 |
| lifeless | meaton2veggies: thats odd; are you using the source package from launchpad? | 06:04 |
| meaton2veggies | lifeless: yes from launchpad | 06:04 |
| meaton2veggies | theres no install target in the Makefile i think, that correct? | 06:05 |
| lifeless | thats correct | 06:05 |
| lifeless | so the debian/rules file you have is broken or something | 06:05 |
| meaton2veggies | yeah | 06:05 |
| lifeless | which is confusing, as to have a binary buld it has to have been correct when we uploaded it | 06:05 |
| lifeless | what url did you use to get the source from? | 06:06 |
| meaton2veggies | the debian/rules were created locally | 06:06 |
| lifeless | meaton2veggies: don't do that | 06:06 |
| meaton2veggies | the source didnt come with debian/ | 06:06 |
| lifeless | use debget and get the whole source package from the ppa | 06:06 |
| meaton2veggies | i did do that im sure | 06:06 |
| lifeless | if you did that you would have gotten a debian dir | 06:06 |
| meaton2veggies | ok | 06:06 |
| meaton2veggies | using this package https://launchpad.net/~bzr/+archive/ppa] | 06:07 |
| meaton2veggies | using this package https://launchpad.net/~bzr/+archive/ppa | 06:07 |
| lifeless | yes | 06:07 |
| meaton2veggies | lifeless: u use debget with the *.dsc file? | 06:12 |
| lifeless | thats my recollection | 06:12 |
| meaton2veggies | i'm not getting anything for some reason | 06:13 |
| lifeless | yes, ddsc | 06:15 |
| lifeless | I'll test | 06:15 |
| lifeless | oh | 06:19 |
| lifeless | debget is apparently toast | 06:19 |
| lifeless | an easier way | 06:20 |
| meaton2veggies | ok | 06:20 |
| lifeless | add the https://launchpad.net/~bzr/+archive/ppa to your sources.list, as per the web page | 06:20 |
| lifeless | apt-get source bzr | 06:20 |
| lifeless | then do | 06:20 |
| meaton2veggies | yeah im not gettin source for 1.17 though for some wierd reason | 06:20 |
| meaton2veggies | its giving me 1.13 from ubuntu repos | 06:21 |
| lifeless | have you added the ppa? | 06:21 |
| meaton2veggies | wait correction | 06:21 |
| lifeless | done apt-get update? | 06:21 |
| meaton2veggies | its fine | 06:21 |
| meaton2veggies | YAY! | 06:22 |
| lifeless | :) | 06:23 |
| meaton2veggies | lifeless: cool, bzr (powerpc) deb created and installed thanks for assistance | 06:35 |
| lifeless | my pleasure | 06:35 |
| lifeless | EODing | 07:12 |
| lifeless | poolie: ping | 07:27 |
| chrispitzer | i'm having problems with bzr upload. when I try to upload a repo, i get bzr: ERROR: Invalid url supplied to transport: "README.txt" | 07:34 |
| chrispitzer | what's up - is this a permissions issue or something...? | 07:34 |
| lifeless | what url are you giving bzr upload to push to? | 07:34 |
| chrispitzer | bzr upload bzr+ssh://my.server.com/srv/foo | 07:35 |
| poolie | lifeless: pong | 07:36 |
| chrispitzer | it should be using the user 'chris' just like when i ssh in. | 07:36 |
| poolie | this sounds familiar | 07:36 |
| poolie | is there a backtrace in .bzr.log? | 07:36 |
| chrispitzer | when i ssh in I can make files in that folder easily | 07:36 |
| lifeless | poolie: I'm done with the most recent arc, modulo review feedback and excludes (which we can defer a little, I think) | 07:37 |
| chrispitzer | there is no .bzr.log | 07:37 |
| poolie | ~/.bzr.log | 07:37 |
| poolie | nice one | 07:37 |
| lifeless | poolie: Unless you have specific requests, I'm just going to be popping 2.0 things off the milestone | 07:38 |
| lifeless | poolie: as I start before you, you have until I wake up to leave something here giving a specific request ;P | 07:39 |
| * lifeless is gone but can be rung | 07:39 | |
| poolie | sounds good to me :) | 07:40 |
| poolie | lifeless: bombs away re 6m cycle rfc | 07:41 |
| chrispitzer | http://dpaste.com/72786/ | 07:41 |
| poolie | chrispitzer: so it looks like a bug or an incompatibility between bzr and the upload plugin | 07:43 |
| poolie | i assume you do actually want the tree contents uploaded? | 07:43 |
| poolie | i mean, that you want a full checkout on the server | 07:45 |
| chrispitzer | yea | 07:47 |
| chrispitzer | it works great for a bunch of sites I use it on... bzr upload that is. | 07:47 |
| chrispitzer | it just doesn't want to work this time. | 07:47 |
| chrispitzer | *shrug* time to get on with my life I guess. :P | 07:48 |
| chrispitzer | thanks anyway - later | 07:57 |
| mdke_ | hi all. Is there an easy way to merge a git branch into a bzr one? I tried using a simple "bzr merge" command but no luck | 08:20 |
| poolie | mdke_: what happened? | 08:21 |
| poolie | you probably need to specify the revision range | 08:21 |
| poolie | and obviously you need the bzr-git plugin | 08:22 |
| lifeless | if the bzr branch wasn't made from git, you can't trivially merge | 08:22 |
| mdke_ | poolie: it said that it wasn't a branch | 08:23 |
| mdke_ | lifeless: ah, damn | 08:23 |
| mdke_ | lifeless: I'm working on an Ubuntu branch which was imported from the upstream svn project (gnome), but now that gnome has moved to git, I need to figure out some way of merging in the changes | 08:24 |
| mdke_ | short of using the "cp" command... | 08:24 |
| mdke_ | lifeless: I suppose the solution is to use Launchpad's import service to import the upstream project into bzr and then merge from that | 08:24 |
| mdke_ | poolie: is the bzr-git plugin available in Ubuntu, do you know? | 08:26 |
| mdke_ | I couldn't see it | 08:27 |
| mdke_ | brb | 08:32 |
| lifeless | mdke_: you need to essentially recreate your history on top of the git import | 08:40 |
| lifeless | we should make a tool to do this for you | 08:40 |
| lifeless | but you can approximate it with bzr fast-export and then fast-import on top of a bzr-git import | 08:40 |
| lifeless | lp does bzr-git imports | 08:41 |
| mdke_ | lifeless: ok, so I'll wait for the Launchpad import to take place, and then try those two commands. So I'm basically going to have to scrap the Ubuntu branch and make another one, right? | 08:43 |
| AfC | Is bzr-git built into bzr-1.17? | 08:43 |
| AfC | (my distro hasn't posted a new package yet, so I can't see for myself) | 08:43 |
| lifeless | AfC: no | 08:44 |
| lifeless | mdke_: sadly yes | 08:44 |
| mdke_ | lifeless: that's ok, we'll blame gnome for switching | 08:44 |
| lifeless | mdke_: you'll need to provide -r parameters to the export :P | 08:45 |
| mdke_ | ok | 08:45 |
| lifeless | oh AfC hi | 08:45 |
| lifeless | I want to make a little progress bar | 08:45 |
| AfC | lifeless: hello Robert | 08:45 |
| lifeless | sitting on the right hand side of my screen, at the bottom | 08:45 |
| lifeless | is there a precanned gtk thing for this? | 08:45 |
| mdke_ | thanks for the help lifeless, gtg now | 08:45 |
| lifeless | I knowof the ProgressBar widget, I mean the rest | 08:45 |
| AfC | lifeless: I'm sure you want to make "a little progress". The rest of us are also hoping you'll make "a little progress". | 08:45 |
| lifeless | feh | 08:46 |
| AfC | lifeless: by "at the bottom" do you mean "on the panel" or "always on top (ie, small docked [sic] window)" or... | 08:46 |
| lifeless | its the output from test runs | 08:47 |
| * AfC presumes that if lifeless meant on the panel, he would have said "applet" in there somewhere. | 08:47 | |
| lifeless | so I want something reasonably unobtrusive | 08:47 |
| AfC | yeah | 08:47 |
| lifeless | I guess having a window that shows on the task list, with the content on the task list being a progress bar would be lovely. | 08:47 |
| AfC | lifeless: that's gonna be hard | 08:47 |
| fullermd | What do you want more than a little window with geometry -0-0 or some such? | 08:48 |
| lifeless | AfC: yeah, I'm not shooting for that today. Just completing a TUIT I've had for a while for subunit. | 08:48 |
| AfC | lifeless: [as an aside, it's a shame that applets are such an insanely convoluted API, since applets are what most of us want in these cases] | 08:48 |
| lifeless | I can pipe subunit through subunit2pyunit --progress, to get bzr progress bars | 08:48 |
| lifeless | but thats nowhere near as bling | 08:49 |
| AfC | lifeless: well, there's the "shell bindings", ie `zenity` | 08:49 |
| AfC | so if you're already thinking in terms of pipes that might do the trick | 08:49 |
| AfC | let me russle up an example for oyu | 08:49 |
| lifeless | zenity progress bars? | 08:49 |
| * lifeless looks around in alarm | 08:49 | |
| AfC | zenity anything, really | 08:50 |
| lifeless | wheee | 08:50 |
| lifeless | http://library.gnome.org/users/zenity/stable/zenity-progress-options.html.en | 08:50 |
| lifeless | its scary | 08:50 |
| MT- | What does an error like this mean? No handlers could be found for logger "bzr" | 08:51 |
| lifeless | MT-: commonly it means that your ~/.bzr.log is readonly | 08:51 |
| MT- | Is 770 ok, or does other need read permissions? | 08:52 |
| AfC | lifeless: so, try | 08:53 |
| AfC | $ zenity --progress --title "bzr test" --auto-close --percentage 80 --text "Current module: format stabiltiy" | 08:53 |
| lifeless | AfC: yeah, thing is I need a subunit converter on it anway; that makes me inclined to just do the whole thing in python | 08:53 |
| AfC | as I recall, you feed stdout 0-100 and #blah | 08:53 |
| lifeless | cleaner for the user than typing | 08:53 |
| AfC | lifeless: in that cast, yes, just use pygtk | 08:54 |
| lifeless | <setup stream> | subunit2zenity | zenity ... | 08:54 |
| lifeless | AfC: yah | 08:54 |
| lifeless | I'm going to crib from http://www.andrew.cmu.edu/user/skey/research_prev/checker/working%20now/gui/pygtk2tutorial/pygtk2tutorial/sec-ProgressBars.html I think | 08:54 |
| MT- | lifeless: I added o+rx to everything... | 08:54 |
| AfC | lifeless: dunno. I'm not a Python guy :) | 08:54 |
| lifeless | MT-: your ~/.bzr.log needs to be _writable_:) | 08:54 |
| MT- | lifeless: that is | 08:55 |
| lifeless | MT-: try stracing bzr | 08:55 |
| MT- | um.. | 08:55 |
| lifeless | MT-: or file a bug | 08:55 |
| lifeless | I'm actually not really here right now | 08:55 |
| AfC | lifeless: [but you might want to ask if there's anything newer. The screenshot there looks OOOOOOLD] | 08:55 |
| MT- | I screwed up somewhere.. | 08:55 |
| AfC | always a give away | 08:55 |
| MT- | I doubt it's a bug | 08:55 |
| MT- | lifeless: does that file need to exist on the setver? | 08:55 |
| lifeless | MT-: the path to it does | 08:55 |
| lifeless | bzr will create the file in the directory if it doesn't exist, and needs to be able to do so to do log rotation | 08:56 |
| AfC | lifeless: a slightly better idea might be notification area icon + a docked window with the progress bar in it | 08:56 |
| AfC | (ie, click icon, see progress bar) | 08:56 |
| lifeless | AfC: how hard is it to do rendered icons? | 08:57 |
| AfC | lifeless: you mean ... what do you mean? | 08:57 |
| MT- | lifeless: so, the .bzr.log you're referring to - is that my system or the server? | 08:57 |
| AfC | lifeless: you mean how hard is it to design icons | 08:57 |
| AfC | lifeless: or, | 08:57 |
| AfC | lifeless: how hard it is to change icons through a series to visually represent progress? | 08:57 |
| lifeless | AfC: I mean, to create the icon on the fly using code to create the pixmap/svg/whateverthebackendneeds | 08:58 |
| MT- | has to be server... | 08:58 |
| AfC | lifeless: (gnome-power-manager's battery indicator being a good example of that, although last I saw Ubuntu they heavily fuck with the theme & icon set there, so as usual all bets off for people who don't use upstream) | 08:58 |
| lifeless | all of the code I've seen so far wants icons paths on disk, I think. | 08:58 |
| AfC | lifeless: ah | 08:58 |
| AfC | lifeless: not too hard, actually. | 08:58 |
| AfC | lifeless: Cairo is good at that sort of thing | 08:58 |
| lifeless | so, I don't want to make 100 icons all 1% further complete | 08:58 |
| AfC | yeah | 08:59 |
| lifeless | or, better | 08:59 |
| AfC | disk? Hm. | 08:59 |
| * AfC looks | 08:59 | |
| lifeless | a complete mix of fractions for pass/not run/error/fail | 08:59 |
| lifeless | actually, -> gnome-hackers I think | 09:00 |
| AfC | we've got StatusBar's setFromPixbuf(), so worst case you can draw the image to a Pixbuf and then feed that to that method | 09:00 |
| AfC | [there is an IPC barrier in the way, so it's not like you're going to be able to talk to an XlibSurface / GdkPixmap directly] | 09:01 |
| MT- | lifeless: any packages not installed that could cause that? | 09:01 |
| lifeless | AfC: yeah, I don't care about htat :P | 09:02 |
| lifeless | MT-: if the error only shows when you do something with your server, then its probably permissions on the server. | 09:03 |
| MT- | lifeless: if I set 777 on them, it still shows up :S | 09:03 |
| lifeless | MT-: then its something else. | 09:04 |
| MT- | When I create the repo, everything is michael:bzr | 09:04 |
| lifeless | MT-: Like I said, I'm not really here right now. Your best bet is to file a bug, so that we can gather some data and help you solve the problem. | 09:04 |
| lifeless | We'll likely also find why bzr is giving an opaque output to you and fix that so its easier for other people. | 09:04 |
| MT- | hm - bzr:bzr did the same | 09:05 |
| MT- | lifeless: any reason 770 wouldn't be good enough? | 09:07 |
| lifeless | please file a bug | 09:07 |
| lifeless | I'm having dinner and stuff like that | 09:07 |
| lifeless | I can't help you at the moment, for all that I can feel your pain. | 09:07 |
| MT- | well... I verified it's not permissions | 09:09 |
| MT- | it's something with the system | 09:09 |
| MT- | I'll file a bug later on it | 09:09 |
| MT- | If I can't figure it out | 09:09 |
| MT- | anybody else have any other ideas? | 09:10 |
| MT- | Sleep time - If anybody does know though, please hilight - I installed bzr on the server using aptitude install bzr and let it install its deps. Then I setup permissions and did bzr push bzr+ssh://x.x.60.226/bazaar/branches/test. It seems to work, but I get the error No handlers could be found for logger "bzr" | 09:15 |
| lifeless | MT-: as I said, _please_ file a bug | 09:17 |
| lifeless | its the best way to help us help you | 09:17 |
| MT- | lifeless: ok, I'll do that tomorrow - it's too late to make sense when I detail it | 09:20 |
| MT- | lifeless: thanks | 09:20 |
| sabdfl1 | hi folks | 11:23 |
| === sabdfl1 is now known as sabdfl | ||
| Kinnison | hihi mark. | 11:24 |
| Kinnison | como esta? | 11:24 |
| sabdfl | Kinnison! long time no speak | 11:24 |
| sabdfl | well thank you, and you? | 11:24 |
| sabdfl | is there work afoot to make explicit commit (bzr commit a b c) follow the new codepath for bzr 2.0? | 11:25 |
| Kinnison | sabdfl: getting on, getting on. | 11:25 |
| Kinnison | sabdfl: gearing up for the final production run on http://www.entropykey.co.uk/ | 11:25 |
| Kinnison | sabdfl: Lots of interest here at debconf for it. | 11:25 |
| sabdfl | i hear debconf has been fun | 11:25 |
| Kinnison | It has been good. Lots of "interesting" announcements, especially the release team's announcement about trying to sync up debian releases with Ubuntu LTS releases | 11:26 |
| fullermd | sabdfl: I think lifeless posted a patch for it earlier. | 11:28 |
| sabdfl | thanks fullermd | 11:28 |
| sabdfl | Kinnison: how was that received? | 11:28 |
| Kinnison | sabdfl: mixed. At the conf itself, reasonably well. On -project and -release, marginally more whinging. | 11:28 |
| Kinnison | sabdfl: I'm not yet convinced we won't see an attempted GR to reverse the decision | 11:29 |
| sabdfl | anything can happen in Debian | 11:30 |
| Kinnison | Aye. | 11:31 |
| Kinnison | So, congrats on the Launchpad/AGPL release | 11:31 |
| sabdfl | thanks much | 11:33 |
| LarstiQ | sabdfl: I admit to not knowing what you mean by that codepath, but coupled with fullermd's remark http://www.advogato.org/person/robertc/diary.html?start=104 seems to fit | 11:41 |
| jelmer | LarstiQ, dude! | 12:10 |
| === chad_ is now known as CardinalFang | ||
| LarstiQ | jelmer: I see you're not plaintexting over untrusted networks anymore ;) | 12:11 |
| === chad_ is now known as CardinalFang | ||
| jelmer | LarstiQ, I'm not sure how I can be signed in, I don't recall sending my password.. | 12:21 |
| fullermd | Don't worry, I sent it for you 8-} | 12:24 |
| fullets_ | Is this an appropriate channel for bzr-svn questions? | 12:26 |
| jelmer | fullets_, yeah | 12:26 |
| jelmer | fullermd, (-: | 12:26 |
| fullets_ | I pushed a commit to a Subversion repo using bzr, and it was the first commit to that repo via bzr. The bzr:base-revision property of the commit was set to the commit preceding its immediate ancestor though | 12:27 |
| fullets_ | So my commit via bzr is revision 15993, it thinks its ancestor is 15991, and new bzr branches of that repo omit completely 15992 | 12:28 |
| fullets_ | Is there an easy way to fix this? | 12:28 |
| jelmer | fullets_, what sort of operation happened in svn ? | 12:28 |
| fullets_ | From subversion's point of view it's all just a bunch of commits | 12:29 |
| jelmer | fullets_: does "svn log <branch-url>" include that particular commit? | 12:29 |
| fullets_ | Yes | 12:29 |
| jelmer | Not on the repository URL but on the branch URL? | 12:30 |
| fullets_ | Oh, one sec | 12:30 |
| fullets_ | Sorry, what do you mean by branch URL? | 12:30 |
| jelmer | The URL to the branch in the Subversion repository | 12:31 |
| jelmer | e.g. if the repository is at svn://svn.gnome.org/svn/gnome-specimen then perhaps the branch is located at svn://svn.gnome.org/svn/gnome-specimen/trunk | 12:32 |
| fullets_ | Ah, then yes, it shows up via svn log http://stuff/trunk | 12:32 |
| jelmer | hmm, odd | 12:38 |
| jelmer | bzr-svn should be warning when the order of the commits in svn doesn't match the bzr metadata | 12:39 |
| jelmer | do you get any warnings during a clone? | 12:39 |
| fullets_ | No. There have been warning during pulls into an existing bzr branch about tags moving round, which I shut up with --overwrite, but the problem is still present in a fresh clone in a fresh repo | 12:40 |
| jelmer | fullets_, So, the easiest way to cope with this problem would be to simply remove that property | 12:40 |
| jelmer | I would be interested to know though how you ended up with that property | 12:41 |
| fullets_ | A-ha, but it's a versioned property on the branch root - is there a better way to do that than svnadmin dump -> hack hack hack -> svnadmin load into a fresh svn repository? | 12:41 |
| fullets_ | Oh, wait, no | 12:41 |
| jelmer | it would be a revision property | 12:42 |
| fullets_ | I deleted *all* the non-versioned revision properties, including bzr;base-revision, from subversion | 12:42 |
| jelmer | bzr-svn doesn't set base revision information in file properties | 12:42 |
| jelmer | fullets_, did you also remove the bzr-svn cache? | 12:42 |
| fullets_ | A-ha! | 12:42 |
| fullets_ | I was thinking of the bzr:see-revprops property | 12:43 |
| fullets_ | That lives under ~/.bazaar somewhere, no? | 12:43 |
| LarstiQ | fullets_: ~/.cache/bzr/svn or ~/.bazaar/svn-cache (legacy) | 12:44 |
| fullets_ | Thank you | 12:45 |
| === kiko-zzz is now known as kiko | ||
| LarstiQ | SamB: you asked about Ubuntu packaging branches, right? https://code.edge.launchpad.net/ubuntu | 13:09 |
| === mrevell is now known as mrevell-lunch | ||
| === sabdfl1 is now known as sabdfl | ||
| aquarius | when trying to check out a branch, I get this error: bzr: ERROR: KnitPackRepository('file:///home/aquarius/canonical/ubunet/.bzr/repository/') is not compatible with RemoteRepository(bzr+ssh://bazaar.launchpad.net/~ken-vandine/ubuntu/karmic/desktopcouch/karmic/.bzr/) different rich-root support | 14:01 |
| aquarius | what do I have to do to upgrade my local repository? | 14:01 |
| === mrevell-lunch is now known as mrevell | ||
| === JamalFanaian|afk is now known as JamalFanaian | ||
| LarstiQ | aquarius: upgrading your local repository is one option, or you could branch --standalone to tell it to not use your repository | 14:21 |
| LarstiQ | aquarius: bzr info will tell you what formats are for each branch | 14:22 |
| Chocobo | Hi all. I am setting up my first vcs and I am considering bzr. The only problem I am having so far is how to handle users... I will be following mostly the centralized layout and when users push I want them to be able to use a unique username/password. sftp seems like it will not fit the bill for this application. | 14:25 |
| LarstiQ | Chocobo: why not? | 14:25 |
| LarstiQ | with sftp or bzr+ssh://, the straightforward setup is to have everyone use their own username/password | 14:26 |
| Chocobo | Hrmmm... would each user just be part of a group for the bzr repo? I am trying to figure out permissions, where to out the repo, etc. | 14:27 |
| LarstiQ | Chocobo: yes | 14:29 |
| LarstiQ | Chocobo: and I highly recommend making use of posix acls | 14:29 |
| Chocobo | Do you know of any documentation that describes setting up bzr this way? | 14:30 |
| LarstiQ | Chocobo: I'd check the user guide | 14:33 |
| Chocobo | ohhh I see, so I would do something like "setfacl -m user:USERNAME:rwx bzr-repo" | 14:35 |
| aquarius | LarstiQ, if I upgrade my local repository will it upgrade all the branches that are in it? | 14:36 |
| LarstiQ | aquarius: all branches will have their revision storage upgraded (by definition). | 14:39 |
| LarstiQ | aquarius: can you tell me what format `bzr info` thinks the desktopcouch branch is? | 14:40 |
| aquarius | LarstiQ, cool; I'll do that, then. How do I upgrade my repository? | 14:40 |
| aquarius | bzr info bzr+ssh://bazaar.launchpad.net/~ken-vandine/ubuntu/karmic/desktopcouch/karmic/ -> Standalone branch (format: unnamed) | 14:40 |
| LarstiQ | Chocobo: I'd go for group:bzr:rwx and default:group:bzr:rwx | 14:41 |
| LarstiQ | Chocobo: but yes, that's basically it, since standard Unix permissions are a bit fidgetty in this regard, but posix acls solve it properly | 14:41 |
| LarstiQ | oh feh | 14:41 |
| Chocobo | Ok, thanks. I have never used acl so I will have to look into it some more. Basically I need to make sure that files added have the appropriate permissions. | 14:42 |
| LarstiQ | aquarius: do note that since in this case there is rich-root discrepancy, if you have branches that need to interact with other non rich-root branches this will then shift the problem | 14:42 |
| LarstiQ | Chocobo: yes | 14:43 |
| LarstiQ | aquarius: do you only have desktopcouch branches in that repository? | 14:43 |
| aquarius | LarstiQ, no, I have loads of branches of loads of things | 14:43 |
| LarstiQ | aquarius: then I would not recommend upgrading all of that to a rich root format just yet, the pain with the distinction will soon be something of the past with 2a | 14:46 |
| LarstiQ | aquarius: so, my recommendation is to either branch it standalone, or use a seperate repository for it | 14:46 |
| aquarius | LarstiQ, ok, cheers | 14:47 |
| SamB | LarstiQ: I don't think I would be able to find anything on that page ;-P | 15:01 |
| SamB | LarstiQ: also, what is this "password" thing of which you speak? | 15:03 |
| LarstiQ | SamB: where? | 15:04 |
| LarstiQ | SamB: to Chocobo? ssh | 15:04 |
| Chocobo | hrmm? | 15:05 |
| SamB | LarstiQ: do you want me to be quiet, or are you talking about secure shell? | 15:06 |
| LarstiQ | SamB: I still am not sure what you were referring to, but we discussed secure shell accces to a centralized server, yes | 15:07 |
| SamB | LarstiQ: I'm being facetious, actually ;-) | 15:11 |
| SamB | pretending I forgot that SSH supports password-based authentication | 15:11 |
| LarstiQ | SamB: ah, I didn't catch on to that :p | 15:11 |
| Mez | what does | 15:19 |
| Mez | bzr: ERROR: Server sent an unexpected error: ('error', 'No repository present: "chroot-139854732:///home/sites/"') | 15:19 |
| Mez | mean? | 15:19 |
| Mez | (I'm trying to branch from another server in our local network) | 15:19 |
| Mez | bzr branch bzr+ssh://root@webutils/home/sites/ | 15:19 |
| jelmer | Mez: The error should be formatted better, but it usually means the server on the remote site was unable to find a repository related to the branch it has opened. | 15:20 |
| jelmer | if you log in as root@webutils and run "bzr log /home/sites", does that work? | 15:20 |
| Mez | how would that happen? I can branch locally | 15:20 |
| Mez | bzr: ERROR: No repository present: "file:///home/sites/" | 15:21 |
| Mez | root@webutils:/home/sites# bzr log | head -n 2 | 15:21 |
| Mez | ------------------------------------------------------------ | 15:21 |
| Mez | revno: 513 | 15:21 |
| Mez | works though | 15:21 |
| LarstiQ | Mez: `bzr info` says the repository is where? | 15:21 |
| Mez | shared repository: /home/webteam/bzr | 15:22 |
| Chocobo | WOW! ACL's are awesome. | 15:23 |
| Mez | ah, ok, I see. | 15:23 |
| * LarstiQ blinks | 15:23 | |
| LarstiQ | Chocobo: they are! :) | 15:23 |
| Mez | /home/sites is a symlink | 15:23 |
| Chocobo | that default: thing is crazy cool. :) | 15:23 |
| * LarstiQ nods at Chocobo | 15:23 | |
| LarstiQ | Mez: aha. | 15:24 |
| Mez | Thats better, 10000kB/s rather than 18 | 15:24 |
| === lamont` is now known as lamont | ||
| awilkins | Can ConfigObj return lists of values? | 15:28 |
| * awilkins RTFS | 15:30 | |
| bialix | hi guys, anybody has copy of monotone's document about daggy fixes? their wiki is down during last several weeks and I can't find the way how to get it from google cahce | 16:18 |
| awilkins | bialix: I think the gist of it is "find the revision that introduced the bug and branch from there to fix it", but you probably knew that | 16:36 |
| awilkins | bialix: Frustratingly, many of the wiki pages are in the google cache but I couldn't coax this one out | 16:36 |
| bialix | I knew the gist, I'm interesting in document to show to other people | 16:37 |
| bialix | me too | 16:37 |
| === thekorn_ is now known as thekorn | ||
| === reggie is now known as reggie_bzr_newbi | ||
| reggie_bzr_newbi | what does it mean when bzr 1.17 complains that a folder is not versioned but has versioned children? | 16:44 |
| bialix | in one branch child file was changed, but in other branch folder+child were deleted | 16:47 |
| reggie_bzr_newbi | bialix, that doesn't seem to be the case here. I can't seem to find much in google about this. is there a command to show me what bzr thinks is the status of my folders? | 16:48 |
| bialix | bzr status | 16:48 |
| bialix | bzr ls -v | 16:48 |
| luks | bialix: maybe an older version, but http://web.archive.org/web/20071115025521/http://venge.net/mtn-wiki/DaggyFixes | 16:51 |
| bialix | luks: many thanks, it's enough | 16:52 |
| ronny | how do i get a tree for a specific revision? | 16:54 |
| bialix | see revisiontree | 16:55 |
| ronny | hmm | 16:58 |
| ronny | its not exactly self explaining :( | 16:59 |
| luks | repository.get_revision_tree(revision_id) or something like that | 17:04 |
| luks | it's simple enough | 17:04 |
| bialix | found mirror for mtn site: http://mtn-wiki.1erlei.de/wiki/DaggyFixes/ | 17:04 |
| kfogel | loggerhead 1.10 works fine with Bazaar 1.17, right? | 17:13 |
| kfogel | (the 1.10 release is from so long ago, it seems like a good idea to ask) | 17:13 |
| LarstiQ | kfogel: its require_any_api includes 1.17 | 17:14 |
| LarstiQ | kfogel: so it should, yes | 17:18 |
| LarstiQ | oh wait | 17:19 |
| * LarstiQ slaps self | 17:19 | |
| kfogel | ? | 17:19 |
| LarstiQ | kfogel: ahem, that was the loggerhead copy for my bzr.dev | 17:19 |
| kfogel | LarstiQ: I'm not sure I understand. Do you have local mods? | 17:19 |
| LarstiQ | no, but it is very likely not 1.10 | 17:20 |
| * LarstiQ downloads and checks 1.10 | 17:20 | |
| LarstiQ | kfogel: which has required_bzrlib = (1, 6) | 17:21 |
| kfogel | LarstiQ: does that translate to "1.6"? | 17:21 |
| LarstiQ | kfogel: so 1.10 might complain with 1.17 | 17:21 |
| kfogel | meaning anything higher than 1.6 will work? | 17:21 |
| LarstiQ | kfogel: I think so | 17:22 |
| LarstiQ | beuno: time for a new loggerhead release? | 17:22 |
| Tak | is the progress indicator with "Fetching revisions: Inserting stream" the revision-fetching progress, or the overall (branch) operation progress? | 17:22 |
| Chocobo | hrm: No handlers could be found for logger "bzr" | 18:04 |
| reggie_bzr_newbi | I need a bzr expert. I have two repos that have the exact same directory structure but bzr apparently thinks that one of them has folders that are non-versioned | 18:18 |
| === mrevell is now known as mrevell-dinner | ||
| ronny | LarstiQ: any idea where jelmer is? | 18:38 |
| CardinalFang | reggie_bzr_newbi, hey hey. | 18:42 |
| beuno | LarstiQ, ooooh yes | 18:50 |
| beuno | I dream about it | 18:50 |
| jfroy | bah | 18:56 |
| jfroy | Just converted a large repository (used for bzr-svn) to 2a | 18:56 |
| jfroy | Repacking it now, bzr is taking upward of 1 GB of memory | 18:57 |
| jfroy | Seems to be an endemic problem with bzr -- several operates take incredible amounts of memory... | 18:57 |
| jfroy | *operations | 18:57 |
| maxb | Is there a convenient command to find the common ancestor revision between two branches? | 19:12 |
| Tak | bzr merge --show-base? | 19:13 |
| CardinalFang | maxb, The revision specifier can do that. See "ancestor" under $ bzr help revisionspec | 19:14 |
| CardinalFang | reggie_bzr_newbi, Still have a problem? | 19:16 |
| reggie_bzr_newbi | CardinalFang, yes. this is really maddening | 19:17 |
| CardinalFang | reggie_bzr_newbi, Ignoring the directory bit for a moment -- what is it you're trying to do? | 19:18 |
| reggie_bzr_newbi | CardinalFang, I have two branches in a repo that I can't merge between. do folders have to have the same id between branches? | 19:18 |
| reggie_bzr_newbi | CardinalFang, we have a small svn repo that we are converting to bzr. we just did a fresh bzr svn-import that finished without error | 19:18 |
| reggie_bzr_newbi | branches and tags all look ok | 19:18 |
| reggie_bzr_newbi | we did a series of null merges so that bzr thinks that everything is merged up | 19:20 |
| reggie_bzr_newbi | essentially cd verY; bzr merge ../verX; for each topleveldir bzr revert X; bzr revert .; bzr commit | 19:20 |
| reggie_bzr_newbi | at that point, doing a bzr merge ..\verX in verY shows 'nothing to do' | 19:21 |
| reggie_bzr_newbi | now we make a small change in verX and try to merge to verY. it gives conflicts complaining about a directory not being versioned. pretty sure I've found the problem but not surehow to fix | 19:23 |
| reggie_bzr_newbi | doing a bzr ls --show-ids in the root of verX shows that one of my folders (the one that is causing the problem) has an id that is different than what it has under verY | 19:23 |
| CardinalFang | reggie_bzr_newbi, That final "bzr revert ." should revert all file contents and leave all metadata. That's special. "bzr revert $subdir" will undo changes, file contents and metadata, for files beneath that directory. | 19:23 |
| CardinalFang | Is that what you intended? | 19:24 |
| reggie_bzr_newbi | well, I had 3 files in the root that existed in verX but not verY | 19:24 |
| reggie_bzr_newbi | so after the merge I had file.base and file.other | 19:24 |
| reggie_bzr_newbi | I couldn't revert by filename, it just gave me an error | 19:24 |
| reggie_bzr_newbi | bzr revert . removed them | 19:25 |
| reggie_bzr_newbi | it was correct for them not to exist in verY, but I didn't bzr to understand that | 19:25 |
| reggie_bzr_newbi | but I wanted bzr to understand that | 19:25 |
| CardinalFang | reggie_bzr_newbi, I'm not sure what "bzr revert $dir" will do for a merge. I'm trying to decide if it makes sense. | 19:25 |
| CardinalFang | We take it to a private discussion. | 19:28 |
| LarstiQ | ronny: jelmer is at Debconf | 19:32 |
| * jelmer waves | 19:33 | |
| ronny | oh, sup | 19:33 |
| ronny | jelmer: what are the future plasn for dulwich, stay protocols + data formats, or more | 19:34 |
| jelmer | ronny, Basically fix bugs, improve performance | 19:34 |
| ronny | i see | 19:34 |
| jelmer | ronny, If git ends up implementing a new format (which seems unlikely at this point) dulwich will implement it as well | 19:35 |
| ronny | jelmer: i'd like to be able to do in-memory-merges at some point for all vcs's | 19:36 |
| ronny | so i want to see if they have things to offload the tricky bits | 19:36 |
| jelmer | ronny: Ah | 19:36 |
| jelmer | ronny: I'm not particularly interested in maintaining an implementation of merge in Dulwich, to me it is mainly about the formats and the protocols | 19:37 |
| ronny | basic retarded commit building works | 19:37 |
| ronny | jelmer: a rename finder might suffice to make my life easy thon | 19:38 |
| ronny | (i kind of dont want to do that one) | 19:38 |
| jelmer | ronny: I don't have any plans to do one, but there might just be somebody else who is interested in contributing one | 19:40 |
| ronny | jelmer: dont you need one for bzr-git anyway? | 19:43 |
| jelmer | ronny: A rename finder? | 19:43 |
| ronny | jelmer: yes | 19:43 |
| jelmer | ronny: Eventually we'll need a rename finder for bzr-git, but there already is one in bzr that we might be able to use there. | 19:43 |
| jelmer | ronny, And it doesn't look like it will happen in the short term since tracking renames means changing the bzr-git mapping format and that will cause all revision ids to change. | 19:44 |
| ronny | i see | 19:44 |
| jelmer | ronny: I'm open to the idea of having one in Dulwich, it's just not really something I particularly care about myself. | 19:44 |
| ronny | i'll take a look at implementing one later on | 19:45 |
| ronny | hmm, i despiese the launchpad bugtracker, so many clicks, so long loading times | 19:46 |
| kfogel | ronny: it does have a hugely redeeming feature, though: you can interact with it entirely by email. That's a huge win. | 19:47 |
| kfogel | ronny: not saying that long load times are a good thing, of course. | 19:48 |
| ronny | kfogel: given todays email clients neither is nice | 19:48 |
| kfogel | ronny: are you saying that today's email clients are worse than yesterday's, in certain ways? (Couldn't quite tell.) | 19:49 |
| ronny | kfogel: no | 19:54 |
| ronny | kfogel: they are shit since ages | 19:54 |
| kfogel | ronny: :-) | 19:54 |
| ronny | this might be the fault of the email protocols | 19:55 |
| ronny | i dont expect anyone that touched a imap implementation to be able to do reasonable userinterfaces | 19:55 |
| * Tak blink | 19:56 | |
| === reggie_bzr_newbi is now known as reggie | ||
| abentley | salgado is reporting that he can reproducibly create a branch that is unpullable using "bzr branch" and "bzr push": "A request was made for key: ('sha1:f4bb3cbd77a7fa6ed7b4a9df79d4e3b69c0cc1c6',), but that content is not available" | 20:10 |
| LarstiQ | ronny: I'm rather happy with mutt actually | 20:31 |
| ronny | LarstiQ: never managed to warm myself up to that one | 20:31 |
| LarstiQ | ronny: somehow it seems to mesh well with my vi mindset | 20:32 |
| ronny | LarstiQ: not with mine tho | 20:32 |
| ronny | LarstiQ: whats the usual amount of mail you manage, i got hundreds if megabytes of dozens of mailinglists | 20:33 |
| LarstiQ | ronny: I switched my non-work mail around november of 2006, the Maildir since then is 730M | 20:38 |
| ronny | LarstiQ: i see, sounds like a fit quantiy | 20:40 |
| LarstiQ | but I've removed a lot of mailinglists from that I'm no longer subscribed to | 20:41 |
| LarstiQ | like debian-devel, really can't keep up anymore | 20:41 |
| LarstiQ | (and low on disk space, so..) | 20:41 |
| ronny | i keep buying larger harddisks | 20:41 |
| * LarstiQ wants to move to a new server but has some inertia there | 20:42 | |
| LarstiQ | ronny: work mail since the same period, 11051 entries, but that also has seen a bunch of deletions | 20:42 |
| ronny | those are quite good amounts | 20:42 |
| ronny | hmm | 20:43 |
| LarstiQ | good as in not yet too much that clients croak? | 20:43 |
| ronny | ops | 20:43 |
| ronny | i just noticed i that anyvc doesnt deal with ignored files | 20:44 |
| ronny | (in bzr) | 20:44 |
| === [1]reggie is now known as reggie | ||
| Savvas_P | want to ask something regarding "removed" files | 21:00 |
| Savvas_P | lets say i remove some files from one branch and i "keep" them, when I push the changes to another branch , when the branch is updated the files are removed, how can I keep them on the other branches as well? | 21:02 |
| LarstiQ | ronny: that should be easy to fix? | 21:03 |
| ronny | LarstiQ: well, as soon as i have tests, and a generic working ignore command | 21:04 |
| ronny | LarstiQ: so its more work, but a easy fix | 21:04 |
| ronny | i"ll give vellum some love now | 21:04 |
| LarstiQ | Savvas_P: you can't (got mentioned in https://bugs.launchpad.net/bugs/402196 but I don't think a specific feature request got filed) | 21:05 |
| ubottu | Launchpad bug 402196 in bzr "remove --keep deletes files from disk in remote branches" [Wishlist,Triaged] | 21:05 |
| LarstiQ | ronny: right. | 21:05 |
| LarstiQ | ronny: vellum? | 21:05 |
| ronny | LarstiQ: a task based build tool | 21:06 |
| * LarstiQ looks it up | 21:06 | |
| LarstiQ | ronny: like (n)ant? | 21:06 |
| LarstiQ | (or, not that I think of them that way, scons or waf) | 21:07 |
| Savvas_P | LarstiQ: OK thanks | 21:08 |
| ronny | LarstiQ: its not an inference machine | 21:08 |
| ronny | LarstiQ: its supposed to automate things around a python style project | 21:08 |
| abentley | lifeless: Salgado is reliably producing corrupt branches when he pushes to launchpad. He was unable to reproduce it locally, even pushing stacked over the smart server. | 21:10 |
| abentley | lifeless: He is using 1.18dev. | 21:10 |
| LarstiQ | ronny: Zed Shaw is involved with pida? | 21:12 |
| ronny | LarstiQ: nope, i just kind of started working on vellum and he stopped for now | 21:12 |
| LarstiQ | k | 21:16 |
| lifeless | abentley: hi | 21:19 |
| lifeless | salgado: have you filed a bug? | 21:20 |
| abentley | lifeless: Hi. | 21:20 |
| lifeless | abentley: whats the nature of the corruption? ACF on pull/scan ? | 21:20 |
| abentley | lifeless: https://pastebin.canonical.com/20552/ | 21:21 |
| salgado | lifeless, not yet | 21:21 |
| abentley | lifeless: On my stale version of bzr.dev, it gave an ACF, but when I updated, I got the same error. | 21:21 |
| lifeless | abentley: this is ACF still, jam added a method to raise | 21:22 |
| lifeless | I'm not sure ValueError was the best exception to raise, but anyhow | 21:23 |
| lifeless | it does the job | 21:23 |
| abentley | The ACF is on branch. | 21:23 |
| lifeless | this is missing a CHK page | 21:23 |
| abentley | lifeless: I thought so. It wasn't created using a bundle, though. | 21:24 |
| abentley | lifeless: Or at least, salgado can reproduce it with push. | 21:24 |
| lifeless | salgado: when did this start happening? | 21:25 |
| salgado | lifeless, I first noticed it yesterday | 21:25 |
| lifeless | salgado: does it happen to all branches, or just this specific one? | 21:25 |
| salgado | lifeless, any branches on this project | 21:25 |
| salgado | lifeless, other than (my own) trunk | 21:26 |
| lifeless | are you working from a shared repo? | 21:26 |
| salgado | yes | 21:26 |
| lifeless | so, this suggests several bugs to me | 21:27 |
| lifeless | the smart server isn't asking for enough follow up data | 21:27 |
| lifeless | or the smart server is trying to read data it doesn't need | 21:27 |
| lifeless | the former would be on push,the latter on pull | 21:28 |
| lifeless | salgado: could you please file a bug | 21:28 |
| lifeless | so we can start recordin the data we gather | 21:28 |
| salgado | will do | 21:29 |
| salgado | abentley, got the same error when branching from a branch pushed with bzr-1.17 | 21:29 |
| lifeless | one possibility is that you have managed to trip the trie size expansion in your branch | 21:30 |
| * salgado tries branching with bzr-1.17 | 21:30 | |
| lifeless | but that doesn't seem likely if *all* your branches that you push are bong | 21:31 |
| salgado | right | 21:31 |
| salgado | lifeless, when I branch from within my shared repo I don't get the error. (not sure you've seen that in the discussion) | 21:33 |
| salgado | actually, when I'm within the shared repo and branch from lp.net, I don't get the error | 21:34 |
| lifeless | is the bug filed? | 21:34 |
| salgado | filing now | 21:35 |
| salgado | lifeless, https://bugs.edge.launchpad.net/bzr/+bug/406597 | 21:36 |
| ubottu | Launchpad bug 406597 in bzr "ACF when trying to branch from any of my canonical-identity-provider branches" [Undecided,New] | 21:36 |
| lifeless | is this a new project? | 21:39 |
| lifeless | cd /tmp/ | 21:41 |
| === JamalFanaian is now known as JamalFanaian|afk | ||
| lifeless | salgado: ok, so I've got a handle on it. | 21:57 |
| lifeless | data that is referenced isn't being copied | 21:58 |
| lifeless | if you just 'bzr push /tmp/new', does that work? | 21:58 |
| salgado | lifeless, yes, it works and I can later branch from there | 21:59 |
| salgado | same thing when using bzr+ssh | 21:59 |
| lifeless | how about this | 22:03 |
| lifeless | bzr branch lp:<trunk> /tmp/trunk | 22:03 |
| lifeless | bzr push --stacked-on /tmp/trunk /tmp/mine | 22:04 |
| salgado | the initial branch is going to take a while, but we'll see | 22:06 |
| === cprov is now known as cprov-afk | ||
| === salgado is now known as salgado-afk | ||
| salgado-afk | lifeless, the push succeeded and I'm now branching (bzr branch mine/ mine2), which is working fine -- it'd have failed already if the problem existed | 22:30 |
| lifeless | salgado-afk: ok | 22:35 |
| lifeless | salgado-afk: now, please try with bzr 1.17 | 22:36 |
| lifeless | it should be fast as the trunk is reusable | 22:36 |
| salgado-afk | lifeless, redoing just the push with 1.17? | 22:39 |
| jam | lifeless: so in your iter-changes-partial-parents patch, what part of that is "already present in a branch that will be merged" ? | 22:40 |
| jam | ah, the set_tags_bytes stuff? | 22:40 |
| salgado-afk | lifeless, worked as well | 22:41 |
| lifeless | jam: the change to the signature of _process_entry, which has now landed so hopefully isn't visible in the diff | 22:42 |
| jam | lifeless, salgado-afk: This is the missing chk page issue? | 22:42 |
| lifeless | jam: yes | 22:42 |
| lifeless | salgado-afk: redo the push --stacked-on, yes | 22:42 |
| lifeless | salgado-afk: using bzr 1.17 for the push and then branching from it and so on | 22:42 |
| jam | lifeless: unfortunately: + result, changed = self._process_entry(entry, self.root_dir_info) | 22:42 |
| jam | is, indeed, present in the diff | 22:42 |
| jam | I'll create my own, I guess | 22:43 |
| lifeless | salgado-afk: lp is running bzr 1.17, so if its a 1.17 bug we'll need to use 1.17 to trigger it | 22:43 |
| salgado-afk | lifeless, right; I did the push with 1.17 and was later able to branch from the pushed branch | 22:44 |
| lifeless | salgado-afk: branching from it using 1.17 ? | 22:45 |
| lifeless | and [obviously] branching into /tmp as well, because we want the failure case | 22:46 |
| salgado-afk | lifeless, both 1.17 and 1.18, but I'm not waiting until it finishes because the error happens early on | 22:46 |
| lifeless | salgado-afk: erm, the backtrace shows that it happens during tree building, which is nearly the very end of it | 22:48 |
| salgado-afk | lifeless, it takes exactly 20s for the error to happen when I branch lp:~salgado/canonical-identity-provider/test4 | 22:49 |
| === psynaptic is now known as psynaptic|afk | ||
| salgado-afk | (just timed it) | 22:50 |
| lifeless | salgado-afk: outside your shared repo? | 22:52 |
| salgado-afk | yes | 22:52 |
| lifeless | thats nuts | 22:53 |
| lifeless | jam: so, were you ok with the test progress patch? | 22:56 |
| jam | lifeless: truth be told, I think it makes figuring out the test suite one step harder to understand | 22:56 |
| jam | And I don't quite understand when you know to use SEEK_SET vs SEEK_CUR | 22:57 |
| lifeless | so, the concept is being built in subunit | 22:57 |
| lifeless | I'll be taking it to testing-in-python once its a tad more mature | 22:57 |
| jam | At least, when I saw it originally | 22:57 |
| jam | I would have thought you would be doing SEEK_CUR, but you have SEEK_SET | 22:57 |
| lifeless | generator tests (that we don't have) would use SEEK_CUR | 22:58 |
| jam | ah, I see now, you are still calling countTestCases | 22:58 |
| jam | you just do it in a decorator | 22:58 |
| lifeless | right, I move from using it as part of the contract, to it being used by the public contract | 22:58 |
| jam | I guess I'm just really confused by the layering | 22:59 |
| jam | As in, I barely have an idea what is going on | 22:59 |
| jam | level of confused | 22:59 |
| lifeless | wow ok | 22:59 |
| lifeless | uhm | 22:59 |
| jam | you're wrapping this with that | 22:59 |
| jam | at a random time | 22:59 |
| jam | and expecting it to have all the values | 22:59 |
| jam | or not | 22:59 |
| lifeless | so, we have some main steps | 22:59 |
| lifeless | we make a suite, something honouring run(result) | 22:59 |
| lifeless | we pass that into TextTestRunner.run(suite) | 23:00 |
| lifeless | which creates a result and does some UI stuff | 23:00 |
| jam | k, following so far | 23:00 |
| lifeless | currently, TTR.run calls countTestCases | 23:00 |
| lifeless | which removes any opportunity for lazy evaluation | 23:01 |
| lifeless | (and subunit doesn't support countTestCases at all) | 23:01 |
| lifeless | so, layering wise, test cases should be responsible for knowing if they are lazy or know how many tests they have | 23:02 |
| lifeless | this patch doesn't go all the way to achieve that. But it does change TTR so that it no longer assumes the test case its running does know | 23:03 |
| jam | lifeless: but unittest.TestSuite *does* support countTestCases, right? | 23:04 |
| lifeless | yes | 23:04 |
| lifeless | its a design bug that that method exists at all | 23:05 |
| jam | Why wouldn't a TestSuite know how many tests it has aggregated? | 23:05 |
| jam | Given that you have a separate TestCase instance for each test | 23:05 |
| jam | AFAIK | 23:05 |
| lifeless | the method returns it transitively | 23:05 |
| lifeless | countTestCases isn't len(self._tests) | 23:05 |
| lifeless | its sum(test.countTestCases for test in self) | 23:06 |
| lifeless | its a Composite pattern | 23:06 |
| lifeless | the problem though, is that if one of the tests *doesn't* know | 23:06 |
| jam | well, self._tests can contain a TestSuite as well, right? | 23:06 |
| lifeless | (say its a generator test) | 23:06 |
| lifeless | then you have to actually run that test to find out how many tests it has | 23:06 |
| jam | given that we don't have generator tests... | 23:06 |
| jam | nor does unittest support it, afaik | 23:07 |
| lifeless | yes, but I'm not doing this for bzr I'm doing it so that I can reuse TTR outside bzr | 23:07 |
| lifeless | unittest supports it fine | 23:07 |
| lifeless | except for countTestCases | 23:07 |
| lifeless | one example of a generator test is LazyLoadingTestSuite, which I posted to TIP a couple months back | 23:08 |
| jam | so some of the confusion is just Unittest issues | 23:11 |
| jam | like having a Runner.run(suite) which calls suite.run(result) etc | 23:11 |
| lifeless | right | 23:12 |
| jam | and then you are decorating run() | 23:12 |
| jam | to do all sorts of random stuff | 23:12 |
| jam | like call *back* into Runner.progress() | 23:12 |
| lifeless | startTesetRun and stopTestRun go some way to allowing the deletion of Runner | 23:12 |
| jam | or is that result.progress() | 23:12 |
| jam | i guess it is result | 23:12 |
| lifeless | Test.run calls into result.progress | 23:12 |
| lifeless | the decorators run that is | 23:12 |
| jam | right,which is actually the suite, but TestSuite conforms to the TestCase api? | 23:13 |
| lifeless | yes | 23:13 |
| lifeless | suites are tests are suites | 23:13 |
| jam | well, *a* suite | 23:13 |
| jam | well, to clarify, *a* suite is *a* test, as well as being a collection of tests. | 23:14 |
| lifeless | externally its just *a* test; the fact it is composed of many children is hidden from the public API that TestRunner is allowed to use | 23:14 |
| jam | so... | 23:15 |
| jam | I think your patch adds complexity | 23:15 |
| jam | if it is necessary, then so be it | 23:15 |
| lifeless | so without it, TTR calls test.countTestCases, and subunit (because its just reading from a socket) can't answer that sensibly | 23:15 |
| jam | but it certainly isn't something that I'd go "oh yeah, that is what I want" | 23:16 |
| jam | lifeless: sure, but it could return 0, which is what we are doing now anyway | 23:16 |
| jam | since you just aren't setting num_tests | 23:16 |
| jam | which means it stays 0 | 23:16 |
| lifeless | nope, it gets set | 23:16 |
| jam | or you could return a sentinel "-1" | 23:16 |
| lifeless | this is what happens with the patch: | 23:17 |
| lifeless | TTR.run(test) | 23:17 |
| lifeless | result = result_class(num_tests=0) | 23:17 |
| lifeless | test.run(result) | 23:17 |
| lifeless | now, for bzr's normal runs, the next step is | 23:17 |
| lvh | Hi! | 23:17 |
| lifeless | (inside test), result.progress(self.countTestCases, SEEK_SET) | 23:18 |
| lifeless | which sets result.num_tests | 23:18 |
| lifeless | for subunit2pyunit --progress, the same thing happens, except rather than calling self.countTestCases, the subunit stream has a progress: item in it | 23:19 |
| jam | so given that you are trying to show progress, it is a little bit icky to have the "num tests" keep getting bigger, as that means whatever progress indicator you have is invalid anyway. | 23:21 |
| lifeless | jam: yes, and this is one of the main difficulties with doing progress of things with unknown length | 23:22 |
| jam | and if the stream has "progress:" why couldn't it return that as part of countTestCases... because it hasn't read it yet at the time of "result=XXX" ? | 23:22 |
| lifeless | right | 23:22 |
| lifeless | also because cat stream1 stream2 | subunit2pynit --progress | 23:22 |
| jam | lifeless: though that again doesn't have any valid meaning for progress info... | 23:25 |
| jam | not to mention... does it have any meaning anyway? | 23:25 |
| jam | catting a saved stream doesn't seem like it is actually running anything | 23:26 |
| jam | and hence... who cares about its progress | 23:26 |
| jam | or is that "cat FIFO1 FIFO2" ? | 23:26 |
| lifeless | jam: so the point is to decouple things such that the result object doesn't know or care | 23:28 |
| lifeless | saved streams are useful for timing analysis | 23:28 |
| jam | lifeless: I can understand why one would save the output | 23:29 |
| jam | I'm not sure why you would want --progress with saved output | 23:29 |
| lifeless | jam: pragmatically, one is unlikely to do that | 23:29 |
| jam | lifeless: anyway, it sounds like you solved a problem you're having, which isn't one I'm having. And it adds complexity, though not a tremendous amount. | 23:29 |
| jam | personally | 23:29 |
| lifeless | combining FIFO's is a very common case though, ec2test does that | 23:29 |
| jam | just having subunit.countTestCases() == 0 | 23:29 |
| jam | seems like a perfectly reasonable alternative | 23:30 |
| jam | lifeless: though again, combining FIFOs would mean that your info is a bit bogus | 23:30 |
| jam | and you really should intermix them | 23:30 |
| jam | rather than read one and then the next | 23:30 |
| lifeless | right, we do | 23:30 |
| jam | but you can use something fancier than 'cat' I'm sure | 23:30 |
| lifeless | we get progress from both | 23:30 |
| jam | so I certainly wouldn't block your patch | 23:30 |
| lifeless | and transform them into CUR as you combine them | 23:31 |
| jam | I'm not *happy* about it, but if you need it, do it. | 23:31 |
| lifeless | ok; I wish I knew how to make you happy about it :) | 23:31 |
| jam | well, I'm not "super happy that this has finally landed" | 23:31 |
| jam | lifeless: I'm not *unhappy* either | 23:31 |
| lifeless | ah good | 23:31 |
| === psynaptic|afk is now known as psynapticx | ||
| === psynapticx is now known as psynaptic | ||
| poolie | hello jam, hello all | 23:47 |
| jam | hi poolie | 23:47 |
| poolie | can i call you briefly? | 23:48 |
Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!