=== verterok_ is now known as verterok [00:14] can I set remote locations in locations.conf? [00:15] like Launchpad? [00:21] yes === kiko is now known as kiko-zzz [01:05] hm [01:05] 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:06] not offhand [01:06] -i **/.bzr or something, I guess [01:13] ah, i'd missed the top down application of rules [01:45] \o/ :!./bzr --no-plugins selftest intertree.test_compare.*test_specific -x '$C$' [01:45] passing [01:50] poolie: spiv: review requested please [01:50] my dirstate infrstructure change will be blocking a later review in about 2 hours. Maybe less [02:04] what is the preferred way to assert that something is either an iterable or None? [02:08] SamB in a test? [02:09] SamB i guess i'd first ask, is that really what you want to test? [02:09] don't you know which one it should be? [02:09] but, if you did want that then i guess i'd do [02:10] if result != None: [02:10] l = list(result) [02:10] poolie: not in a test [02:10] in a method [02:10] then either assert something about l or just add a comment that the cast will fail [02:11] poolie: 'result is not None' [02:11] actually, now I'm not sure what type this argument is supposed to be [02:11] oh noes [02:11] SamB: in general we don't make assertions about arguments [02:11] unless either the api changed or it's error prone [02:11] and in the second case it's better to change it [02:11] poolie: change it to what? [02:12] so just go ahead and use it in the way it should be used [02:12] if thing is not none: [02:12] return ', '.join(thing) [02:12] I just want to make sure that all the callers are passing things with a compatible interface ... [02:12] 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:13] SamB: we don't do that in bzr, as a stylistic choice. [02:13] igc: what is the file_iter argument to CommitCommand.__init__ *supposed* to be? [02:14] poolie: well, some of the tests here are passing callables that return iterables, and some of them are passing iterators [02:14] 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:15] igc is away this week [02:15] oh :-( [02:15] sick [02:16] SamB: this might just be the python generator pattern here? [02:16] you can often treat those things as the same [02:16] (kind of vague description) [02:16] i.e., iterators are iterables. [02:17] well, the most key difference is that some of the tests pass *callables* returning iterables, but some just pass iterables [02:17] SamB: whats CommitCommand? [02:17] it's in bp.fastimport.commands [02:18] oh [02:18] so, no idea. [02:18] what we generally do is; [02:18] - ensure the docstring is clear [02:18] yeah [02:18] - let the caller do what they want [02:19] and I guess [02:19] - make sure the tests are consistant with the docstring [02:21] * SamB wishes fast-import had a --dry-run mode where it did *everything* except actually create the branches ... [02:23] Samb, nice idea [02:23] spiv, there is a 1.17 branch, https://launchpad.net/bzr/1.17 [02:23] afaics you should be able to target bugs to it [02:23] spiv: ping [02:23] note that the control is hugely mislabelled as 'target to release' [02:23] and there's a bug for that [02:24] 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:25] well, quibble [02:25] they don't always have precisely the same information content [02:26] poolie: Ah ok. I don't fully understand the difference between setting a milestone on a bugtask and targetting to a release. [02:26] spiv: hi you promisedish me a review yesterday. [02:26] launchpad has succeeded then :) [02:27] spiv: targetting is a new bugtask [02:27] with its cunning strategy of labelling one as the other [02:27] spiv: there is a link 'nominate for ...' [02:27] lifeless: yeah ... maybe [02:27] depends how often those attributes get used, possibly ... [02:27] Especially when targetting to a release then offers me a list of series, not releases, to choose from... [02:27] Bug #132733 in Launchpad Bugs: “Confusing use of the term "Target to release" on bug pages.” [02:27] Launchpad bug 132733 in malone "Confusing use of the term "Target to release" on bug pages." [Medium,Triaged] [02:27] Launchpad bug 132733 in malone "Confusing use of the term "Target to release" on bug pages." [Medium,Triaged] https://launchpad.net/bugs/132733 [02:28] that was odd [02:28] lifeless: anyway, I figured out that using "bzr fast-import" definately results in callables being passed ... [02:28] poolie: possibly because you gave the bug # and the url? [02:28] i guess so, though it's odd the first one didn't include the url [02:29] oh maybe that's for the one that did have the url [02:29] must be! [02:33] spiv: ping [review] - I'll keep pinging till I get ack or nack [02:33] 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] (uncommitted changes) [02:33] lifeless: quick suggestion about setup versioning. Instead of bzr-setup-1.17-1.exe, bzr-1.17-setup-1.exe [02:33] in git I would just not stage those files [02:33] how do I get around this in bzr [02:33] psynaptic: bzr commit takes a list of files to commit [02:33] psynaptic: or ytou can shelve the changes [02:33] RenatoSilva: good idea! please put in a bug [02:34] psynaptic: bzr commit -x foo -x bar, I think [02:34] bob2: I already committed what I wanted [02:34] by cding to the dir and bzr commit . -m "message" [02:34] psynaptic: so what do you want to have happen? [02:35] but now it won't let me push or pull [02:35] shelve them [02:35] psynaptic: push --no-strict [02:35] 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] what's the rationale for strict push? [02:36] I see.. my version of bzr seems old [02:36] no such option [02:36] psynaptic: ok, what actually error are you getting then? [02:36] psynaptic: we're really trying to guess at the moment [02:36] ok.. [02:37] bob2: it's clearly not a good enough rationale ;-) [02:37] bzr push bzr+ssh://user@example.com/home/cnpopen/public_html/dev [02:37] 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] bzr: ERROR: These branches have diverged. Try using "merge" and then "push". [02:37] so I tried $ bzr pull [02:37] bzr: ERROR: These branches have diverged. Use the merge command to reconcile them. [02:37] so I tried $ bzr merge [02:37] bzr: ERROR: Working tree "/private/var/www/subdomains/cnp/" has uncommitted changes. [02:38] psynaptic: someone else (or you from another macine) has pushed to that branch [02:38] psynaptic: do this: [02:38] bzr shelve --all [02:38] bzr merge bzr+ssh://user@example.com/home/cnpopen/public_html/dev [02:38] bzr commit [02:38] bzr push [02:38] bzr unshelve [02:38] 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:39] bzr: ERROR: Working tree "/private/var/www/subdomains/cnp/" has uncommitted changes. [02:39] Macbook-Pro: /var/www/subdomains/cnp> bzr diff [02:39] === modified file 'sites/default/default.settings.php' (properties changed: +x to -x) [02:40] psynaptic: the shelve didn't remove the change? Interesting (and a bug) [02:40] well [02:40] it removed 2 other files [02:40] with content changes [02:40] but not the property change [02:41] Macbook-Pro: /var/www/subdomains/cnp> bzr diff [02:41] === modified file 'sites/default/default.settings.php' (properties changed: +x to -x) [02:41] Macbook-Pro: /var/www/subdomains/cnp> bzr shelve --all [02:41] No changes to shelve. [02:41] I'll change it to +x [02:41] save the hassle :) [02:41] I'll file a bug on shelve now for you [02:41] thanks a lot [02:42] are you on MacOSX/linux/win32? [02:42] mac os x [02:42] sent in [02:43] sorry about that; its disconcerting to suggest a recipe that fails [02:43] * lifeless pings spiv again [02:43] spiv: hai [02:43] where should constructor arguments be documented -- in the class' docstring, or __init__'s? [02:43] I prefer __init__ [02:43] some folk use the class [02:43] any good examples? [02:44] lifeless: no, thanks a lot for your help [02:44] I like to put instance and class attributes in the class docstring, and constructor params in the __init__ [02:44] SamB: not offhand [02:44] so this bzr commit after the merge [02:44] seems to only contain the merge changes [02:45] should I add a merge commit message [02:45] then bzr add my stuff and commit/push again [02:46] yes, something like 'Sync with dev' [02:46] thanks [02:47] lifeless: hi [02:47] lifeless: I'll look at it in about 15 minutes. [02:47] spiv: thanks! [02:47] lifeless: thanks for the nags :) [02:47] lifeless++ [02:47] spiv: I've finished all the python changes in the patch on top of it [02:48] spiv: so I'm porting to pyrex, updating docs, and submitting [02:54] hmm, very odd [02:54] now I can't see my changes [02:54] I asked another dev to pull and it just says nothing to pull [02:55] there files are there in my working copy! [02:55] *the [02:55] bzr diff only shows the files that were unstashed [02:55] *unshelved [02:56] lifeless: bug 406099 [02:56] Launchpad bug 406099 in bzr "Better file name for bzr windows installer" [Undecided,New] https://launchpad.net/bugs/406099 [02:59] what am I doing wrong! lol [03:00] bzr missing remotebranch [03:01] I think I did something stupid earlier [03:01] bzr push origin [03:01] bzr branch origin [03:01] randomly did those 2 [03:01] :/ [03:02] I don't even know the branch I'm supposed to be working on [03:02] in git you can view your available branches using $ git branch [03:02] RenatoSilva: thanks [03:03] in bzr the command seems to do something differnent [03:03] psynaptic: it makes a new branch [03:03] psynaptic: 'bzr branches' will list branches [03:03] or you can just look on your filesystem [03:03] Macbook-Pro: /var/www/subdomains/cnp> bzr branches [03:03] origin [03:03] not sure I was supposed to have origin [03:04] 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] but does that mean I had zero branches? [03:04] lifeless: hah [03:04] spiv: its worth getting your feedback on the conceptual change and how its presented, regardless [03:05] psynaptic: branches are directories [03:05] oh ok [03:05] psynaptic: it means you had no other branches under your current branch [03:05] psynaptic: you can give a url to push - bzr push [03:06] so I can just delete /origin in the filesystem,? [03:06] psynaptic: ./origin, yes [03:06] thanks [03:06] I'm a bit confused because bzr diff is not showing anything but the changes I don't want to push [03:07] * RenatoSilva gtg [03:07] I added the dir with the files I wanted to commit and committed them [03:07] but this was before this merge [03:08] maybe I have committed changes [03:08] that I haven't pushed [03:09] right ok [03:09] bzr log shows the history [03:09] bzr missing remotebranch [03:09] ^ changesets that aren't in both [03:09] what is remotebranch though? [03:09] Macbook-Pro: /var/www/subdomains/cnp> bzr missing remotebranch [03:09] bzr: ERROR: Not a branch: "/private/var/www/subdomains/cnp/remotebranch/". [03:10] I don't know what remotebranch is [03:10] whatever branch you think is missing things [03:11] I don't know ANY branches [03:11] maybe HEAD? [03:11] master [03:11] this isn't git [03:11] something like that? [03:11] psynaptic: bzr missing bzr+ssh://cnpopen@openlyconnected.com/home/cnpopen/public_html/dev/ [03:11] ahh [03:11] psynaptic: thats where you pushed to before [03:11] its therefor a branch [03:12] riiight [03:12] You have 2 extra revision(s): [03:12] bzr push bzr+ssh://cnpopen@openlyconnected.com/home/cnpopen/public_html/dev/ [03:12] if you want to save that as the default this branch pushes to do [03:12] bzr push bzr+ssh://cnpopen@openlyconnected.com/home/cnpopen/public_html/dev/ --remember [03:13] 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] Pushed up to revision 53. [03:13] thanks for the tip [03:16] bzr update then? [03:16] why am I at a different revision to the repo? [03:16] a fellow developer says he is at rev 56 and I am at 53 [03:17] Macbook-Pro: /var/www/subdomains/cnp> bzr update [03:17] Tree is up to date at revision 53. [03:18] psynaptic: 'update' is only useful if you are using a checkout [03:18] right [03:18] you are using a separate branch, so update just checks locally and has nothing much to do [03:19] so do you think this method I'm using is inefficient? [03:19] as for your fellow, they have some different stuff in their branch [03:20] I was given instruction on how to use their bzr repo [03:20] bzr missing will tell them whether they have additional things, or are missing what you pushed [03:20] branches and checkouts work very similarly [03:20] why can't we push to the same branch? [03:21] you can, but you'll end up changing commit orders a lot [03:21] right [03:21] checkouts automate that for you [03:22] * psynaptic pasted http://pastie.textmate.org/private/makewfs23qan1jwpxwuu0a [03:22] this is what we were told to do [03:22] there are 5 devs [03:22] spiv, i filed bug 406113 [03:22] Launchpad bug 406113 in bzr "need checks or tests that compiled extensions are loaded properly" [High,Confirmed] https://launchpad.net/bugs/406113 [03:22] all working in their own environment [03:23] did you catch jam at all? [03:23] psynaptic: for that situation I'd be inclined to use two branches [03:24] how would that work? [03:24] one sec [03:26] http://paste.ubuntu.com/235578/ [03:27] lifeless: ahh I see [03:28] thanks for taking the time to do that for us [03:28] looks like a good idea [03:30] I have added it to our project wiki so hopefully we can start using it [03:31] 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] is it important? [03:31] working tree = checked out files [03:32] are my changes actually in the central repo? [03:32] yeah, I get that bit [03:32] push will update the branch data, but it won't update the checked out files [03:32] ok, so in this case it will update the central server but not my own working copy [03:33] "push will update the branch data, but it won't update the checked out files" [on the remote server] [03:33] push has nothing to do with updating your local working copy [03:34] that's what I thought was the working copy [03:34] but you have a working copy on the server too, yes [03:34] right [03:35] I'm still no closer to understanding [03:35] spiv: actually, the bug is in a local change anyway; that branch should be independently golden [03:35] it's probably just too late for me today [03:35] 3.35am [03:35] not a great time to be trying to work out somewhat abstract ideas [03:36] 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] ok [03:36] lifeless/spiv: quick yeah/nay sought on bug 406113 - specifically, whining about missing extensions unless BZR_PURE_PYTHON=1 [03:36] Launchpad bug 406113 in bzr "need checks or tests that compiled extensions are loaded properly" [High,Confirmed] https://launchpad.net/bugs/406113 [03:36] push updates the remote branch and repository, but not the working copy. "update" updates the working copy [03:37] right [03:37] poolie: I don't think we should whine [03:37] so how do I see that my changes where pushed into the remote repo? [03:37] or erorr [03:37] so I can happily go to bed [03:37] bzr missing urltoremotebranch [03:37] 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:38] that would be another option [03:38] not very obvious though [03:38] Branches are up to date. [03:38] excellent! [03:38] could also go in backtraces, though lack of them is unlikely to cause tracebacks [03:38] ah, also, "bzr log urltoremotebranch" [03:38] 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] lifeless: but, anyhow - why not? [03:39] poolie: its only for people that grab a tarball or branch bzr themselves that the obviousness matters [03:39] or for cases where there's a hole in the previous process [03:39] and we already make setup.py die if the extensions don't build [03:39] poolie: which is why I'm suggesting we patch the previous process usin the same logic as whining would [03:39] thanks bob2 [03:40] as for why not, well I don't like programs that whine at me [03:40] it gives a bad impression [03:40] and I don't think our users will like it either [03:41] you think most people who don't have extensions loading have made an informed decision not to have them? [03:41] if I do bzr commit and I have added files, modified and unknown.. will only added get committed? [03:41] or at least would agree with it if asked? [03:41] poolie: most people with the power to fix it, yes. [03:41] or should I back out and shelve [03:41] psynaptic: added and modified will be committed [03:42] thanks [03:42] psynaptic: if you run 'bzr commit',it will list the things being committed in the editor window [03:42] I did that :) [03:42] hm, i don't think so [03:42] but it doesn't make a distinction in that output [03:42] why would they want that? [03:42] I know now tho [03:42] thanks [03:43] psynaptic: everything it lists will be committed ;) [03:43] psynaptic: except for unknowns [03:43] poolie: e-thread-lost [03:44] i think running without compiled extensions should be very opt-in [03:44] more so than at present [03:47] thanks lifeless and bob2, I can get some sleep now! [03:47] poolie: so, I'd like to discuss this, but not now. [03:48] lifeless: how to I tell pqm-submit that I don't have a local copy of a branch? [03:48] c u :D [03:48] thumper: I don't know; pqm-submit --help may. [03:48] i'll try it, if it works propose a merge, and we can handle it there [03:48] damn [03:48] I don't think I can [03:48] poolie: What I think is that the people *doing builds* should do the QA [03:48] which kinda sucks [03:48] poolie: not everyone executing bzr [03:48] I'm trying to submit jml's branch for him [03:48] thumper: either branch it yourself [03:49] or make up a submit message by hand [03:49] use --dry-run to see a template [03:49] huh, good point [03:49] thumper: bzr pqm-submit LOCATION [03:49] thumper: did you try LOCATIOn? [03:49] yes [03:49] also please do merges inside launchpad, thanks :) [03:49] poolie: :) [03:49] poolie: do you mean landing target stuff? lp can [03:49] it is on my mega plan [03:50] just need a queue hooked in for pqm [03:50] lifeless: we don't have queues in LP yet [03:50] lifeless: well, not exposed anyway [03:50] thumper: how does tarmac work then? :P [03:50] lifeless: it just grabs all approved ones [03:50] hello [03:50] thumper: thats a queue, effectively. [03:50] lifeless: it isn't an ordered queue [03:51] grr! [03:51] though personally, I would really want a button to say 'ok land this now', separate from approval to dosol [03:51] Is there any way to shelve changes to binary files? [03:51] JoaoJoao: bzr shelve --all, should do so [03:52] 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:53] ... because there's a large number of user who're using the slow python implementations and like it that way? [03:54] lifeless: does it also work with bzrtool's shelve? (shelve1 on windows) [03:54] JoaoJoao: no [03:54] :( [03:54] poolie: no, because *when a bad deb is made* a lot of users get flipped from C to python in one hit. [03:55] no go to me then [03:55] JoaoJoao: sorry :( [03:55] JoaoJoao: you could commit the file, uncommit and revert it [03:55] and then use merge -r revid:xxxx, to restore it later [03:55] yeah, if we add this we'd presumably want to check it in the deb build process [03:56] 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] we already check in setup.py [03:56] lifeless: that would work, but too much of a hassle to me... thanks for the tip anyway [03:56] its just that the setup.py check doesn't check that the things built are used afterwards [03:57] (there is a bug about builds on karmic, they put the .so's in bzrlib/bzrlib/*.so [03:57] which setup.py should arguably catch as well [04:16] 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:21] 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:22] meaton2veggies: it's probably easy enough to build from source using the source package bits in the ppa? [04:24] mwhudson: ok great, is there any doco for building bzr from src [04:24] meaton2veggies: it's just 'debuild' isn't it? [04:27] debget <<.....dsc>> [04:27] then dpkg-buildpackage [04:27] or debuild [04:27] lifeless: thanks [05:01] spiv: I'm landing that branch w/o the fixes- they are in my next patch anyhoo, ok ? [05:02] I'm down to three failures on the pyx code [05:10] lifeless: sure [05:12] 2 failures [05:30] \o/ [05:30] guess what [05:38] way to go robot [05:40] I'm integrating/improving the docs now [05:40] then its up for review, and qa to see if it improves commit :) [05:55] lifeless: installed deps for building, however error on install of packages trying to do 'make DEST=blah install' [05:55] lifeless: should this be changed to something in debian/rules? [05:59]