[00:01] moldy: where did the branches come from? [00:02] moldy: iiuic, no common ancestor implies they have no history in common [00:07] igc: they come from a converted svn repository [00:08] moldy: converted via bzr-svn or bzr-fastimport? [00:08] igc: bzr-svn [00:09] moldy: I don't know much about bzr-svn sorry [00:09] jelmer: still around today? [00:09] igc: as a last resort, i could manually create another branch off of branch a, apply the differences to branch b, and use that one as the new branch b (i don't desperately need all the history), but i am wondering if there is a better way [00:09] moldy: see if jelmer or anyone else has a better idea first [00:10] moldy: if not, that sounds ok to me === Noldorin_ is now known as Noldorin [00:19] moldy: were the branches in the svn repo created by doing 'cp', or by separate imports? [00:20] lifeless: i have no idea :) [00:20] lifeless: hm, now that i thinj about it, probably by "cp", but i cannot vouch for it :) [00:21] if they were, I would expect bzr-svn to have joined them [00:21] uhm, I suggest filing a bug on bzr-svn, if they have common ancestry in svn [00:22] hm, they have common history in svn [00:23] i ran bzr-svn on the whole repository [00:24] is it kosher to use 2a repo format for all new repos if you only care about 1.17+ support? [00:24] but i also changed the layout a bit, so i joined stuff into the branches that had their own svn modules before, maybe that was the problem [00:34] S11001001: yes, thats fine. [00:34] 2a is usable [but not ideal] from 1.16 on [00:34] S11001001: we will be strongly recommending 2.0 and above everywhere [00:40] probably silly question, but was the 2a upgrade issue fixed before trunk switched? === thumper-afk is now known as thumper [01:08] igc, hi [01:08] hi poolie [01:08] so if putting sphinx onto hardy is hard, um [01:09] dangit, bzr help needs some sort of close-match spell checking when the edit distance is just a few characters between the user entry and what they actually wanted help on ... [01:09] SamB: i don't think bzr-guess does this but it would be an easy extension [01:09] say, "help revision-specs" instead of "help revisionspec" [01:09] poolie: heck, I think this is important enough to be in core! [01:09] igc, did it turn out you can't run it from source [01:10] poolie: yet to try [01:10] especially for the non-command topics [01:10] which have rather arbitrary names [01:10] poolie: I might get to it today [01:10] i just wondered [01:10] polie: need to upgrade to 2a first [01:10] the issues lamont mentions may block it running from source too [01:10] in which case we might [01:10] poolie: maybe [01:10] hm, i guess we could ask for a karmic chroot there [01:11] poolie: let me try from source first [01:12] poolie: karmic may be out before they get to it either way :-( [01:12] igc, from recent mail it looks like karmic may not be LTS [01:13] poolie: I thought 10.4 was LTS [01:13] you also get into the problem that slightly exotic server hardware may not be supported by newer kernels [01:13] at least i think i recall that happening in going to hardy [01:13] right but karmic is not 10.4 [01:13] it will be 9.10 [01:13] right [01:14] hmm ... my "bzr log" is silly and only looks in the current branch for revisions even when they're in the same repo, it seems :-( [01:14] so the earliest they'll probably want to upgrade the base os there is may 2010 [01:19] poolie: it shouldn't be _hard_ to put sphinx in hardy [01:20] it just needs to not be self-build-depending... [01:20] for a round [01:20] i'm not sure what that means [01:20] is it getting rid of the circular dependency? [01:20] SamB: Well, if they're not in the current branch, it's tough to get the revno... [01:21] bah! [01:21] poolie: I expect that the reason jinja2 build-depends sphinx is for its own docs? is it possible to strip the sphinx-needs from jinja enough to build and have it work enough to build sphinx enough to build jinja-with-sphinx to build sphinx-with-full-jinja? [01:21] why can't it just skip that? [01:21] I think the typical answer to things like that is "because your patch for it hasn't been merged' :p [01:21] lamont: i expect that's true too, and that it is possible [01:22] or at least give a less scary-looking error that explains what went wrong a bit better ... [01:22] but i haven't looked at the source at all [01:22] poolie: it has to be.. it's just a question of how far back in history one has to go [01:22] (note that the error you get is a NoSuchRevision, but it doesn't come from looking up the rev, it comes from branch.revision_id_to_dotted_revno() [01:22] oh, because it was not circular at the time it originally went into debian or ubuntu? [01:22] of course, I'm on an old build atm because I was hoping to figure out how to look at the changelog ... [01:22] Samb, i agree, file or dupe a bug [01:22] I admit I haven't been watching, but I expect that the decision on next-LTS won't be made until at least the next UDS, so it'll either be 10.04 or 10.10 [01:24] hi sidnei [01:25] igc: oi [01:25] sidnei: a questions fro you ... [01:25] circular deps are sadness [01:25] igc: shoot [01:25] can I use/test the buildout stuff on linux [01:25] I'm thinking of getting the image right ... [01:25] lifeless: did you see bialix's comments about 'apport's dependencies are so hard on windows'? [01:26] then worrying about how the installer does something with it [01:26] poolie: yes [01:26] poolie: and the real issue is that it needs a file that isn't even delivered by python in hardy... :( [01:27] jml: poolie: 12 for lunch? [01:27] igc: uhm. if i recall correctly, you should be able to run bootstrap.py then bin/buildout on linux [01:27] igc: but after that it invokes a batch file [01:27] lifeless: sure, where? [01:28] you had two restaurants you wanted to revisit [01:28] so lets hunt down the second [01:28] wfm, i think you'll like it [01:28] igc: that won't give you much other than fetching the dependencies though === thumper is now known as thumper-fud [01:28] sidnei: and do you know how it packages python, qt and pyqt? [01:29] igc: pyqt needs to be installed manually using the .exe installer into your global python interpreter, and so does a few other dependencies. [01:29] sidnei: my xp partition is only a few G so I want to do as much work as I can elsewhere [01:30] igc: and finally it uses py2exe which is basically black magic to me to pull all the dlls and dependent libs into library.zip [01:30] sidnei: ah - so the qt stuff ends up in there? [01:31] igc: i'm pretty confident that it does. haven't paid close attention. [01:31] igc: the final step is just packaging it up with innosetup [01:31] sidnei: and that's the bit I had planned to improve but ... [01:31] it seems that's about 10% of the job [01:32] igc: correct [01:32] vs gathering everything, compiling it, etc. [01:32] jelmer: how come bzr-rebase is so outdated? [01:33] sidnei: so adding more plugins basically comes down to editing the buildout.cfg file and build-installer.bat.in file right? [01:33] igc: yes [01:35] sidnei: I don't want to install cygwin. I have make installed. Does that sound ok? [01:35] igc: yup, that's how i have it here [01:35] igc: i actually install cygwin but don't use bash. i only put c:\cygwin\bin in %PATH% [01:37] igc: i believe that a different way of achieving what you wanted would be to not use py2exe, but instead build a custom python install [01:37] igc: i have code for doing that which we could possibly borrow [01:38] igc: in fact, i think that would make things a lot easier for everyone including people building plugins [01:38] bbiab [01:39] me too. *wink* [01:40] SamB: outdated in what sense? [01:46] SamB_XP: outdated in what sense? [01:50] poolie: so where should I meet thou? [01:50] lifeless: ping? [personal] [01:54] spm: procedure change: [01:55] new pqm branches need: [01:55] - bzr-core set as reviewer [01:55] - bzr-core subscribed to the branch [01:55] because *reviewers are not notified* [01:56] lifeless: oki; will add to docco. I assume the new branch we did last night needs this asap? [01:56] done it [01:56] awesome, ta. [01:56] for 2.0 and bzr.dev [01:56] only cause I'm in bzr-core and can thus do it [01:56] :-) [01:57] so..... what I'm hearing is you've got the tools to do this yourself; therefore our update needs are minimised? :-P [01:58] * spm looks forward in great anticipation to the response to that unsubtle troll [02:01] lifeless: i guess here [02:02] poolie: ok, I'll drift your way [02:02] jml: ^ [02:18] lifeless, I just got off the phone :) [02:18] poolie, I'll probably be a little later than 12 [02:22] np === thumper-fud is now known as thumper === sidnei is now known as sidnei-away [02:58] bzr does not work directly over ssh, without a bzr server? [02:59] moldy: you can use sftp [03:00] moldy: but having bzr installed on the remote side and using bzr+ssh will be faster. [03:00] spiv: is it enough to have bzr installed, or do i need to have a server running? [03:01] It simply needs to be installed. [03:01] hm, does not seem to work for me [03:01] (And on PATH) [03:02] which bzr versions are compatible? [03:02] Does "ssh yourhost bzr --version" work? [03:02] yes [03:02] Basically all of them. [03:02] What specifically does "not seem to work" mean? [03:02] well, i have 1.15.1 against 0.11.0 [03:02] Oh, ok. [03:03] Server does not understand Bazaar network protocol 3, reconnecting. (Upgrade the server to avoid this.) [03:03] 0.11 is pretty ancient, probably 1.15.1 won't work with that. [03:03] Server does not understand Bazaar network protocol 2, reconnecting. (Upgrade the server to avoid this.) [03:03] bzr: ERROR: Generic bzr smart protocol error: Server is not a Bazaar server: Received bad protocol version marker: "error\x01Generic bzr smart protocol error: bad request u'bzr request 2'\ [03:03] 0.11 was the very first version to have any sort of "bzr serve" support. [03:03] And it was basically just a glorified sftp, you may as well just use sftp :) [03:03] unfortunately, sftp doesn't work either :) [03:03] Oh? [03:04] That's pretty weird. [03:04] The error message is correct though, that upgrading the bzr on the server would fix your problem. [03:04] i think i will look for a backport of a more recent bzr version to debian etch [03:05] It's very unusual for sftp not to work. Is that an intentional server configuration I wonder? [03:06] (0.11 is almost 3 years old, btw) [03:06] might be that my local bzr is broken, sftp itself works [03:06] What error do you get? [03:07] ah, it seems to be related to the svn plugin [03:07] i'm not sure why it uses that plugin when trying sftp, though [03:07] Ah. You can try "bzr --no-plugins ..." [03:10] hello spiv [03:11] igc, did you file a bug or talk to someone about packaging explorer on ubuntu? [03:11] it'd be nice to have it [03:12] spm: thanks for your help. with a recent bzr on the remote side, it works [03:12] moldy: great! [03:12] poolie: good afternoon [03:13] oh so it is [03:13] how's stuff? [03:13] Well, my local repo passed "bzr check" so now it's in the throes of upgrade --2a. [03:14] Can I unshelve a change from branch a/ onto branch b/ [03:14] if it was shelved inside branch a/ [03:14] xnox: unshelve in a/ and then do "bzr merge --uncommitted ../a/" in b/ is probably simplest. [03:15] Otherwise all I can think of is copying the .bzr/checkout/shelf directory. [03:16] would be nice if you could [03:17] poolie: and I'm wondering what happened to my merge request yesterday, and wondering what the most painless way to resend it is when I'm in the middle of an upgrade... [03:18] spiv: thanks [03:18] whoever came up with merge --uncommitted was a genius [03:22] poolie: it was with james_w I believe - I can't recall raising a bug, only emailing [03:22] thumper: yes, I use it a lot (and no it wasn't me) [04:10] One more questions =) I've started to use bzr-svn to push to an svn repo. Is there a way to remember push login & password? [04:47] xnox: in auth.conf i think? [04:48] poolie: ok thanks I'll look into that [05:13] ... is there a way to commit in the style of "darcs record", which has a slightly better interface than "bzr shelve" to select what to inclue in the patch? [05:13] SamB: interactive plugin [05:14] why does searchiong for "bzr darcs commit" (sans quotes) not seem to help me find that? [05:14] branch http://bazaar.launchpad.net/~asabil/bzr-interactive/trunk as interactive into your plugins directory [05:14] S11001001: I know how to install a plugin [05:14] just in case :) [05:14] and if I was having trouble finding it now that you told me the name, I would have asked ;-) [05:16] * igc lunch [05:16] take care, because it doesn't work in dumb terminals (like emacs shell) [05:17] that's fine [05:17] I wasn't really going to use it there [05:17] and I don't think darcs really likes that either ;-) [05:17] I have used it for some time now with darcs just fine [05:17] also, the hunk finder is more eager in bzr-interactive [05:18] whereas I think if hunks are separated by 1 line of context in darcs they will be treated separately, this is not so in interactive [05:18] oh, really? [05:18] doesn't the red highlighting confuse emacs? [05:18] S11001001: hmm, I don't remember darcs being that smart [05:18] what highlighting? [05:19] well, usually of either things that darcs didn't get (non-ascii bytes) or a $ to mark the end of a line with trailing whitespace [05:19] (instead of the actual byte, it prints a red escape sequence) [05:20] hmm, possibly I've never recorded any such things [05:20] (really annoying when you're writing programs using UTF-8 operators!) [05:21] well, I guess it would at worst look just slightly more horrible and less eyecatching than in a real terminal ;-) [05:21] ... and of course you can always use the Emacs terminal *emulator* [05:21] icky, I like moving around my shell history like a text buffer [05:21] it can't do that? [05:21] aww :-( [05:22] well, I guess you'd have to switch modes first if it could [05:22] I mean, toggle something [05:22] to change the key bindings [05:22] so that they wouldn't go to the app [05:25] Less than 500 revisions left to upgrade. Oof. [05:26] * SamB wonders how to get emacs to describe a keymap in an intelligable manner -- wishes it had more types :-( [05:29] S11001001: hmm, needs abit of work ... [05:30] the developer is open to bundles :) [05:30] is it you? [05:30] anyway, was just pondering it ;-) [05:30] not at all, I merely contributed -F support [05:31] ah [05:31] what's that for? [05:32] it's supported by built-in commit, just was broken in the wrapper commit that interactive provides [05:32] ah [05:32] is that the one that takes the commit message from a file? [05:32] I name my log files ++log in honor of arch [05:33] you ... honor ... arch ?!? :-( [05:34] I liked arch, kept using it until about the time bazaar-ng 1.5 was released [05:36] S11001001: and you call temp files ,,foo? :) [05:36] I can't like arch [05:36] just 1 , actually [05:36] it has too many damn pointless concepts! [05:36] Heh. [05:36] , is garbage that tla promises not to delete [05:36] or, at least, too many damn pointless components in a name [05:37] S11001001: my precioussss [05:37] well I don't name my log files ++log instead of ++log.myproject--mainline--0.1.scompall@nocandysw.com--2009-ddi for nothing [05:41] I guess the thing is that I never tried arch until I was already hooked on darcs for the time being [05:41] now I'm not so much hooked on darcs, but still use it as one of my VCS yardsticks [05:42] I don't think darcs existed back in 2004 [05:43] not sure [05:43] I don't remember exactly when #haskell got me hooked [05:43] hmm, actually it seems to have, but I didn't hear about it until 2007 anyway [05:44] yeah, I was pretty sure it was older than that ;-) [05:44] it was the community standard for common lisp projects until recently [05:47] darcs? [05:47] or arch? [05:48] darcs [05:49] did they start using git too or something? [05:49] or git, bzr. & hg too? [05:49] oops, s/./,/ [05:49] git, hg, and svn have all insinuated themselves [05:49] what the? [05:49] why svn? [05:49] ... is it because of google code? [05:50] bknr.net svn is the new host for Edi Weitz's popular libraries, and clozure (an implementation increasing in popularity) also uses svn for source and binary distribution [05:50] oh, is clozure JVM-based? [05:50] you're thinking of clojure :) [05:50] oh. [05:50] okay. [05:51] I was just trying to find an excuse for brain-deadedness [05:51] hmm ... how would I use emacs to search for a line that has $(HIDE) on it and isn't immediately preceded by one with $(SHOW) in it? [05:52] Clozure was once OpenMCL, but MCL went and changed its license, and Clozure added GNU/Linux and Windows support, then x64 and x86 [05:53] surprisingly, porting to platforms other than OS X/PPC was a surefire way to increase popularity [05:53] no duh [05:54] especially with the PPC macs being discontinued [05:54] hmm, so they ... added support for PPC Windows before support for x86 anything? [05:55] was there even an MS Windows for PPC? [05:55] it's a little weird, they added linux/x64, then windows/x64, then similarly for the x86 [05:56] IIRC, porting to the register-starved x86 was harder than amd64 support [05:56] SamB: yes [05:56] ... I mean, I know arty in #reactos was working on porting that to PPC, but I forgot about whether there was an MS predecessor ;-) [05:56] SamB: NT 3.5 was released for PPC. there may have been others. [05:57] anyhow, such discussions are not really on-topic for #bzr [05:58] mneptok: yeah, but, was anyone asking a bzr question? [05:58] oh, I've got one! [05:58] SamB: that's not really the point. [05:58] does bzr work on NT 3.5 PPC? [05:59] SamB: walk into a police station at 3am and do a striptease. when they tell you that it's not a strip club, ask "well, was anyone being arrested?!" [05:59] mneptok: that's a bit different [05:59] I think they'd be arresting you for indecent exposure [06:00] SamB: so please don't risk the same here. [06:00] or because they didn't want to see your dick [06:01] SamB: such language *definitely* is not welcome in #bzr [06:01] oh, sorry. [06:01] should I have said "penis"? [06:02] you should probably keep your mouth shut and be thought a fool, rather than open it and remove all doubt. [06:04] fine, fine, #haskell-blah, here I come ... [06:04] I should be fine there as long as I remember not to talk about Haskell ;-) [06:24] jml: regarding your comment about the puller from about 7:30pm yesterday: bug #424136 [06:24] Launchpad bug 424136 in launchpad-code "Cannot upgrade stacked branches from 1.9 to 2a on Launchpad" [High,Confirmed] https://launchpad.net/bugs/424136 [06:24] oh yes? [06:25] jml: the problem appears to be that the assumption that "Branch.open" succeeds in tha face of rich-root mismatch in stacked-on/stackee is wrong. [06:25] * jml tries to parse that for the third time [06:25] jml: stacked-on: just changed from 1.9->2a [06:26] jml: my branch: just changed from 1.9->2a the hosted area, still 1.9 in the mirrored area [06:27] jml: puller: tries Branch.open(mirrored-my-branch), fails because 1.9 can't stack on 2a because 1.9 and 2a have different rich-root support. [06:27] jml: puller therefore gives an error rather than propagating the upgrade that would fix the error. [06:27] spiv, I see. [06:28] spiv, so we ought to catch those errors and upgrade as if we detected a format change? [06:28] jml: or open in a way that doesn't fail if stacking won't work. [06:28] spiv, you're bringing back bad memories [06:28] spiv, is that even possible? [06:28] e.g. BzrDir.open(...).open_repository() [06:28] hmm [06:29] (because stacking is configured by the branch) [06:29] Or perhaps BzrDir.open(...).open_branch(ignore_fallbacks=True). [06:29] perhaps. [06:29] Or potentially just catch the relevant exception. [06:29] catching the exception seems like the most robust to me. [06:30] bzrlib.errors.IncompatibleRepositories I believe. [06:31] Well, not making inspecting the format of object A dependent on details like "A's config says stack on B, but B is not compatible" seems more robust to me :) [06:31] spiv, yeah, fix bzr [06:32] spiv, in the meantime the integration team will integrate :) [06:32] But I can understand that having a separate "check formats" and "now open it for actual use" phases might be awkward in your code. [06:32] spiv, we already do something like that... icbw [06:32] bzr is working fine: it's refusing to do Branch.open because it can't be opened. [06:33] * jml actually dials up the code [06:33] The problem is your code says "give me a full branch object with fallbacks and everything" when (at this point) it just wants "give me the branch and repository formats" [06:34] and what's the bzr API for that? [06:35] pretty sure there isn't one, or at least wasn't back when we wrote this [06:37] the_bzrdir.find_branch_format() / RepositoryFormat.find_format(the_bzrdir) [06:38] Or I suppose you could use BranchFormat.find_format(the_bzrdir) for consistency. [06:49] lifeless: I find the motu process/system quite frustrating [06:50] lifeless: not that you can do anything about it - I'm just complaining :) [06:55] spiv, how do they interact with RemoteRepository [06:55] et al [07:00] jml: IIRC you'd probably get back a RemoteRepository, still. [07:01] jml: anyway, catching IncompatibleRepositories would work fine for this case, and would probably be the most minimal change. [07:01] I don't really mind what you do so long as it works ;) [07:08] spiv: can I request a 30 second review ... [07:08] spiv: https://code.edge.launchpad.net/~ian-clatworthy/bzr/422533/+merge/10976 [07:09] hello igc [07:13] hi all [07:13] igc: heh [07:14] igc: 30 seconds was perhaps pessimistic :) [07:14] igc: Can I request a 30 secs test for that one-liner since you obviously found a hole in the coverage ? :) [07:15] igc: at least don't close the bug until you had that test... [07:17] vila: it's a formatting issue of very low priority - I don't feel a test is necessary sorry [07:19] it's untested code for which you had the test almost written since you encounter it, anybody else will spend more time on it [07:20] vila: I don't think a test is worth it. [07:22] It would be a test for the contents an error string; it's unlikely to regress, but adding a test would likely add needless friction if anyone *does* tweak the wording. [07:24] It's a different case I feel to what we test in test_errors (which are generally worthwhile tests). [07:30] A test about an invalid property value is not worth it ? [07:30] right, I'm still dreaming, let's reboot [07:30] hi all, have a good day [07:30] vila: w.r.t. bzr-upload, what version should I include in the Windows installer? [07:30] vila: and in terms of help for it, all you need to do is ... [07:31] add whatever text makes sense to the module docstring [07:31] and the plugin guide generator will find it [07:31] igc: thanks ! Time to move the README there [07:31] vila: the Plugin Guide has one chapter per plugin [07:32] the first section for each is the plugin help, then one section per command provided by the plugin [07:32] igc: I intend to release 1.0 before bzr-2.0 so I'd like to have 1.0 there [07:33] vila: if required, I guess plugins could have extra help topics, e.g. upload-tips [07:33] vila: but if they do, I don't currently go looking for them .., [07:33] and I'm not sure how hard or otherwise it would be [07:33] module doc string if perfect [07:34] at least to address the problem of giving more exposure to the doc :) [07:34] so for now, it's in the plugin top-level help or it's in help on a plugin command (or it doesn't make it into the Plugin Guide) === vila is now known as vila-dentist === abentley1 is now known as abentley [08:20] mtaylor: tell me more later :) [08:21] lifeless: I will :) [08:22] Conflict: can't delete lib/lazr because it is not empty. Not deleting. [08:22] 1 conflicts encountered. [08:22] rm -rf lib/lazr [08:22] bzr resolve lib/lazr [08:22] (guess how many times I've had to do that this week!) [08:25] poolie: I've done the bug status tweak I was mentioning earlier :) [08:25] * lifeless waves ciao [08:25] lifeless, ciao === vila-dentist is now known as vila [08:43] * quicksilver tries running bzr pull over GPRS. should be fun. [08:44] * quicksilver reflects that bzr+ssh would have been a better choice for a high latency link. [08:58] hey guys, trying to use the upload command here,, [08:58] the documentation is a little vague, [08:58] however i've done bzr help upload. [08:58] NET||abuse: did you read the README ? [08:58] now what do i do to point it at a location? [08:58] oh, it's in bzr by default on jaunty it looks like. [08:58] didn't load the plugin files into my ~/.bazzar [09:01] * igc dinner [09:02] NET||abuse: http://paste.ubuntu.com/264826/ [09:03] vila, yeh, i pulled down the source into my projects folder, have a copy of it now and am reading the README [09:03] much appreciated, [09:03] just trying to figure out, [09:03] how do i upload a subdirectory of the main branch? [09:04] i have other configurations for local testing and things in directories here, so i was just going to upload parts [09:04] and i have an extra directory layer that isn't on the live server [09:04] NET||abuse: You can't do that yet [09:05] means i should be able to just upload the src/server directory, it holds my www application system and etc directories. [09:05] arrg [09:05] You can only upload a full branch working tree [09:05] that's annoying. [09:05] that's pretty much useless then. [09:05] just have to do big scp transfers then [09:05] there are various ways to address it, none available yet [09:05] overwriting the whole site [09:06] one way is to create a dedicated branch as a fork of your trunk and delete all unwanted stuff there [09:06] you can then merge in that reduced branch and upload that [09:08] NET||abuse: filing a bug report explaining your use case can only help defining the feature [09:09] NET||abuse: or add your case description in bug #212677 [09:09] Launchpad bug 212677 in bzr-upload "Should allow uploading specific files" [High,Confirmed] https://launchpad.net/bugs/212677 [09:12]