[00:09] mtaylor: btw [00:09] mtaylor: please tell me if my fix works for you in builddeb [00:10] lifeless: I will check it [00:10] mgz: yes, interbranch multimethod was extracted from previously plan branch methods [00:10] mgz: most of the tests are just copies of the old branch ones [00:13] thanks. [00:13] lp:launchpad still hasn't finished branching... [00:14] harh [00:14] its a tad big [00:16] ha! ran out of disk space [00:17] >< [00:17] are you hoping to patch launchpad ? [00:18] mgz: ^ [00:19] I thought I'd see if the problem with group membership being seen as more important than direct subscription was something as simple as a badly-ordered if chain [00:20] ah cool [00:20] you'll want about 1.5GB [00:20] I think I'll check via the web interface before finding a big enough drive :) [00:20] + a bit of slack [00:21] I have a 4G VM [00:21] with 550M free in it, to do LP development [00:21] I documented that on the dev.launchpad.net wiki under running/vm, or something like htat [00:22] I'm off to do various things; shall be back online periodically. [00:26] I'm having difficulties merging some changes from one branch into another. [00:27] http://pastebin.com/PQ2hFcCd [00:27] Is something wrong with that? [00:30] branching rev 0 isn't something I've every tried personally. [01:02] Good morning. [01:03] exarkun: there's a bug about that [01:03] exarkun: are you aware that branching rev 0 is essentially the same as doing "bzr init"? [01:04] exarkun: IIRC there's a bug that rev 1 cannot be a merge commit. [01:07] exarkun: See https://bugs.edge.launchpad.net/bzr/+bug/242175, and the bug it links to (and the bugs linked to from its comments...) [01:07] Launchpad bug 242175 in Bazaar "Better error message when merging into empty branch (affected: 1, heat: 0)" [Wishlist,Confirmed] [02:25] How about this one, http://pastebin.com/h1Z2U7Qk [02:25] It seems odd to get conflicts when merging like that. [02:27] exarkun: that seems odd to me too [02:27] exarkun: file a bug :/ [02:42] will do [02:42] I don't know if I'll file all the bugs I ran into tonight :/ [02:42] it's five so far, that seems excessive [02:43] I can't seem to bring myself to try isolating the most recent [03:00] Oh, hmm. [03:01] exarkun: oh! [03:02] exarkun: I'm silly; it would be because "bzr merge -r 2..16" doesn't include the changes from 1->2. [03:02] :( [03:02] That explains some issues, I guess [03:03] exarkun: Usually the way you'd express "merge up to point X" is by simply "bzr merge -r X" [03:04] I think we could give better feedback in this case, perhaps. [03:04] This whole thing I'm doing has problems. But on the other hand, I'm done now, so I hopefully I don't have to care. [03:04] Like explicitly announcing if the merge is a cherrypick. [03:11] mmm sadness [03:11] bzr-builddeb has no direct merge-upstream tests [07:07] Hmm, I think I may have stumbled upon a reason why 'get_stream_for_missing_keys' is needed even for initial fetches which. [07:07] ...which should be able to easily enough send a complete stream. [07:08] ghosts? [07:20] lifeless: overly aggressive calculation of "uninteresting" chk root nodes. The logic doesn't seem to allow for the possibility that two different inventories might refer to the same chk_maps. [07:20] Still digging into the details. [07:59] hi all [08:19] I'm using the development version of a project that uses Bazaar. Instead of pulling updates from the repository on the Internet onto both my laptop and desktop, I want to pull them from the Internet to only my dekstop and then push them to my laptop. How do I do this? [08:19] (Without using shared directories.) [08:19] on your desktop run bzr pull [08:19] Right, figured that much out. :) [08:19] then bzr push bzr+ssh://laptop/path/to/branch [08:20] Is there a way to not use SSH? [08:20] finally on the laptop run 'bzr update' if there is a tree where the branch is (if there is the push will alert you to that fact) [08:20] btw, shared repositories are totaly unrelated to your request; can I ask why you said you didn't want to use them? [08:20] Shared? [08:20] I haven't heard of that. [08:21] ah sorry [08:21] I misread, you said 'shared directories'. My bad - ignore my question. [08:21] uhm yes, you can use any protocol bzr supports. [08:21] lol OK :) [08:21] But ssh is best. Is it a problem for you? [08:21] I don't want to set up ssh on my system. [08:22] I only do this kind of thing at home on a fairly secure LAN. [08:22] So, for syncing my files, I've been using Unison's unsecure protocol. [08:22] Because I have good physical security. [08:23] its not about security [08:23] ssh runs the bzr server at the far end so its very very effiicent [08:23] I'll take a look at the list of protocols bzr supports. [08:24] In this case, the recommendation to use ssh is not about security, but because it's an excellent way of making two machines talk to each other [08:24] Unless you're stuck running Windows? [08:25] Convenience is more important than efficiency for me. [08:25] maxb: No, thank heavens. [08:27] Setting up ssh on Linux *is* convenient [08:27] Because every distro provides it packaged [08:27] bzr serve looks like a good option. [08:28] I agree it's convenient, but I'd rather not run a system daemon if I don't have to. [08:41] What's the LOCATION syntax? [08:41] I ran bzr serve --port=X on my desktop. [08:42] Not I need to run bzr pull [something] on my laptop, right? [09:13] hmm [09:13] i seem to be getting bzr bugmail now [09:13] \o/ ? [09:13] You received this bug notification because you are a member of bzr-qa, which is subscribed to Bazaar. [09:13] oh right [09:13] thats unexpected ;) [09:13] it might be because you're in bazaar-canonical. [09:13] I think the group layout isn't quite right. [09:14] err [09:14] are you in bazaar-canonical ? [09:14] i'm in ~bzr, indirectly, which owns ~bzr-qa, but i'm not _in_ ~bzr-qa [09:14] oh [09:14] lifeless: yeah [09:14] so i don't know why i'm getting these emails [09:14] right, so poolie rearranged things this morning [09:15] * mwhudson looks at some headers [09:15] ~bzr is meant to give you that bugmail anyway [09:18] i guess i'll see how much mail this results in before complaining further :) [09:19] I'll try to look tomorrow [09:20] feel free to drop me a mail your midday if its driving you batty ;) [09:23] * lifeless changes a few things, just because [09:27] Hi, I can't use recorded passwords with bzr-svn [09:27] I tried authentication.conf [09:28] and tried some settings, but bzr either asks for password, or gives the error message : [09:28] hayalci: svn handles its own cache which bzr-svn is able to use [09:28] bzr: ERROR: Permission denied: ".": OPTIONS of 'http://...." : authorization failed: Could not authenticate to server: rejected Basic challenge [09:29] hayalci: do one successful auth with svn and things should be fine [09:31] vila: thanks for the info [09:32] that worked with a tweak. I am using KDE, and kwallet for password storage. While svn can store and access passwords in kwallet, bzr-svn couldn't [09:33] after forcing svn to not use kwallet, and storing password in a file, bzr-svn could access the svn repo [09:33] Actually, that's ok with me. That password is not important. [09:38] hayalci: may be worth filing a wishlist bug against bzr-svn for the record [09:57] spiv, hi? [09:59] does https://bugs.edge.launchpad.net/bzr/+bug/601798 ring any bells for you? [09:59] Launchpad bug 601798 in Bazaar "'NoneType' object has no attribute 'get_config' in filename_matches_config executing bzr switch (dup-of: 559436)" [Undecided,New] [09:59] Launchpad bug 559436 in Bazaar 2.1 "AttributeError: 'NoneType' object has no attribute 'get_config' (affected: 7, heat: 31)" [High,Fix released] [10:00] * spiv looks [10:02] poolie_: that's weird, it looks like 559436, but that was fixed in exactly 2.1.1, which is what they are running [10:03] Or at least, that's when NEWS claims it was fixed... [10:04] The NEWS file in -rtag:bzr-2.1.1 agrees, though. [10:05] sorry i was offline, more maverick/hardware problems :-( [10:06] poolie_: what did they say ? [10:09] poolie_: ouch :( [10:09] poolie_: I left a comment on the bug with my thoughts [10:11] thanks [10:11] lifeless, it's working now [10:11] poolie_: \o/ [10:11] burned a cd at low speed, booted from that, reset bios back to ahci [10:11] despite appearances it can boot from cds in ahci mode, they just appear as a different device [10:11] glub [10:12] ah [10:14] vila: tell me about this config lock patch [10:14] vila: where do you think its up to, is it ready, are you happy with it? [10:15] lifeless: given the discussions I'm more inclined to wait for the sprint to discuss it, there so many things to do with configs that I didn't even mention in the patch that I think we need to talk about [10:15] lifeless: the patch itself... [10:16] well, it needs at least to be split (once or several times) to make my intents and constraints clearer [10:17] using a transport for example was required to use lockdir but also a good thing in itself if we want all IOs to go thru a transport object [10:17] _get_parser() is currently abused by tests as a way to create a config file and we need something better [10:18] whats wrong with that ? [10:18] by which I mean [10:18] what problems does that cause [10:18] overall, far too many things stuffed in this patch were not related to the bugfix itself [10:19] _get_parser() ? Well, in some cases if the config is not empty, supposing that it came from a file make things simpler [10:20] I don't remember the exact context/failing test, but at one point it was obvious/knee-jerk that this wasn't worth maintaining (I tried to nevertheless) [10:21] I think it was related to the ability to use _parser.reload() which itself requires a file name rather than rebuilding a configobj object [10:22] rebuilding the configobj object helped with failures with the intrumented one (hence the addition of reload() there) [10:22] and this last addition was a bit silly since its implementation is a no-op [10:23] kind of: ok this bug fix is simple: oh wait, I need a small refactoring here, oh wait, unrelated tests are failing, one more bit of refactoring, oh wait, etc [11:16] hi there vila [11:16] and good night [11:16] vila, would it make any sense to send an rfc email about config locking just to summarize the progress at a higher level than an mp? [11:18] poolie_: it would, I have a list of other points I haven't mentioned so far regarding config [11:23] the python-ideas thread on their use of hg makes me sad [11:23] consensus emerging seems to be to not accept branches from non-committers. [11:23] ! [11:25] really [11:25] really [11:25] bai [11:27] lifeless: ! [11:28] yeah [11:28] doesn't that almost completely miss the point? [11:28] 'pulling all the patches generates too much noise people won't review, so people should make a single patch and put that in the bug tracker'. [11:28] mwhudson: you'd think so. [11:28] err [11:28] does hg not have merge --preview? [11:28] or some moral equivalent [11:40] I think there are lots of people who still want linear histories [11:40] even though they're using DVCS [11:40] they consider the extra non-linear history to be noise rather than valuable information [11:42] yes [11:42] add to that [11:42] hg doesn't do nonlinear history - it logs all left-aligned, all patches show. [11:45] they should fix that [12:53] gnight [14:33] Hi, I'm looking for docs on bzr formats (bzr 2.1.1), `bzr info` says format: rich-root-pack and `bzr checkout` says "on-the-fly conversion from RepositoryFormat2a() to RepositoryFormatKnitPack4()". But I didn't find info about those formats in docs (http://doc.bazaar.canonical.com/bzr.2.1/en/user-reference/formats-help.html) [14:33] anywhere I can find info on that/those formats? [14:36] knielsen: 'RepositoryFormat2a()' is the internal name for the '2a' format [14:36] knielsen: and 'RepositoryFormat2a()' is the internal name for the 'rich-root-pack' format [14:37] spiv: right, so RepositoryFormatKnitPack4 and rich-root-pack are two different names for the same format? [14:37] Oops, copy-and-paste screwup [14:38] Right, 'RepositoryFormatKnitPack4' is the same format as 'rich-root-pack' [14:38] 'rich-root-pack' is quite old, it dates back to bzr 1.0 [14:38] spiv: right, so the question is, where can I read about that rick-root-pack format? [14:38] ok, yes I suspected that it was old, that's the main info I need, thanks [14:38] Basically you should be using '2a' for everything. [14:39] Please file a bug about the documentation being a bit lacking there. [14:40] ok, will do [14:40] Thanks! [14:40] * spiv goes to bed [14:42] knielsen: there is bug #567064 about improving the message. [14:42] Launchpad bug 567064 in Bazaar "message about on-the-fly conversion is unclear (affected: 2, heat: 6)" [Medium,Confirmed] https://launchpad.net/bugs/567064 [14:45] parthm: that's a related but different bug, I think [14:47] spiv: yes. i suppose it could avoid using internal names + give a suggestion of upgrading to 2a. [15:08] Hi mgz [15:14] filed as https://bugs.launchpad.net/bzr/+bug/601912 [15:14] Launchpad bug 601912 in Bazaar "Missing documentation about repo format rich-root-pack (internal nameRepositoryFormatKnitPack4) (affected: 1, heat: 6)" [Undecided,New] [16:26] I've written an app which I now want to use bazaar to do version control. If I do bzr init will it pick up everything that is already there, or should I create it blank and then add the files and commit them? [16:29] rioch: You can do bzr init in you existing dir. You will then need to do bzr add and bzr commit. [16:31] GaryvdM: thanks :) [16:52] I created a branch with bzr init, then decided to start again and deleted the project, copied the files across from a backup, and now when I do bzr init I get this error: bzr: ERROR: Already a branch: ".". [16:55] Sounds like you deleted all the visible contents of a directory, but kept the .bzr subdir [16:56] maxb: I thought that too, but that's gone as well. [16:57] That error message is a clear indication there is a .bzr in the location you are trying to init [16:58] maxb: well, I emptied my trash and now it works, so maybe it was aware I deleted it? === abentley is now known as abentley-lunch === abentley-lunch is now known as abentley- === abentley- is now known as abentley [20:17] morning [20:25] Hi lifeless [20:27] hey all. [20:27] Hi mgz [20:28] mgz: re py2exe extraction - It work for just bzr, but not with plugins. I've not debug much... [20:29] you also have a slight problem with both me and you changing the bzr setup.py and those new bits not being copied across yet [20:29] easy to fix though. [20:29] I'm working on been able to specify revision specs. [20:29] \o/ [20:29] mgz: Yes - I'll fix that when I get it to work. :-) [20:34] I've just been tracking down the double-auth thing from the other day, it's a mess of abstractions. [20:35] basic issue is the http connection creation is deeper than the try-smart-protocol-then-dumb, so if the first bit fails it throws away everything it has set up so far including the auth information [20:36] also it doesn't store the credentials unless it actually gets a 200, so 401-404 will raise without recording that it actually got past the auth correctly. [20:36] \o/ [20:37] so, it's what I expected, which I might be able to fix, plus a bigger issue in bzrdir that I have no idea for. [20:38] whats the bigger issue? [20:43] well, when it's probing for formats, it has no concept of an http connection [20:43] yes [20:44] so I don't see any clear way of preserving the auth credentials, that are stored on the connection, across two seperate probes [20:44] except some global store, which is sort of what the text file on disk is. [20:44] the probes don't make a new transport object [20:45] how do I find out what changed between bzr version 1.18.1 and 2.1.1 [20:45] but the auth stuff is on the request, not the transport [20:46] iocor: read the NEWS file for 2.1.1 [20:46] lifeless: is that online anywhere? [20:47] iocor: http://doc.bazaar.canonical.com/latest/en/release-notes/index.html [20:48] sure [20:48] ah, or is it... [20:48] or http://bazaar.launchpad.net/~bzr-pqm/bzr/2.1/head:/annotate/NEWS [20:48] I think thats the url anyway, :) [20:50] http://bazaar.launchpad.net/~bzr-pqm/bzr/2.1/annotate/head:/NEWS [20:50] But it breaks because annotate takes to long. [20:50] 's on ConnectedTransport._shared_connection which I guess I'll poke and see if it survives [20:53] ...does seem to have the same id [20:54] mgz: thats a feature [20:54] tcp is slow. [20:54] reuse is good. [20:54] goodie, so, it's cleverer than I feared [20:55] I like to think of it as simpler. [20:55] :P [20:55] if it was simple, wouldn't have taken this long to find out ;) [21:12] ...now I have to look into writing http tests that don't leak horribly [21:12] \o/ [21:14] semi-related, if you get the username or password wrong is it expected to get: [21:14] bzr: ERROR: Invalid http response for http://float.endofinternet.org/bazaar/testauth/.bzr/branch-format: Unable to handle http code 401: Authorization Required [21:15] it seems... unhelpful. [21:15] mmm, I wouldn't say expected. [21:15] if its a single line then its just the regular exception-printout [21:26] i've got some pythoncode that uses bzrlib, and we're attempting to make commits, and for some reason we're unable to make updates to files [21:26] anyone got any ideas why? [21:26] paste the code [21:26] I have a few minutes, I'll have a peek for you [21:26] thanks man [21:27] http://dpaste.com/214900/ [21:27] this is the commit function [21:28] http://dpaste.com/214902/ class initialiser [21:28] http://dpaste.com/214903/ [21:28] function to update files [21:29] ok, so you don't have a tree on disk ? [21:30] calling commit is meant to write the tree out to disk [21:30] uhm [21:30] some terms [21:30] iocor: small nit pick: line 16 of http://dpaste.com/214900/ should not be necessary. [21:31] "self.b = bzrlib.branch.Branch.open(self.b.base)" [21:31] iocor: a branch is a line of development [21:31] iocor: a Tree is a single collection of the users files, either editable (a WorkingTree) or immutable (a RevisionTree) [21:32] iocor: a 'commit' takes a Tree and puts it into the branch's Repository, and updates the branch last_revision. [21:32] iocor: so if you have a WorkingTree, to commit you just do 'tree.commit()' [21:32] lifeless: ok, so I'm looking to take in some changes, apply them to the current branch to get a new branch [21:33] or [21:33] an update to the branch [21:33] it's very simple linear style committing [21:34] iocor: your code won't work properly prior to 1.18 anyway, I would just not support it. [21:34] also, I'm using bzr 2.1.1 but the branch isn't getting updated [21:34] not your fault, just bzrlib internals. [21:34] what is in _update_tree ? [21:34] and the #as of 1.18 thing isn't executed [21:34] self.PrevTree = self.TransPrev.get_preview_tree() [21:34] one line [21:35] also, I inherited this system and it isn't particularly well documented or functional on anything other than bzr 1.18.1 [21:35] at all [21:35] uhm [21:35] so that one line [21:35] is discarding all the data you've got [21:36] to work with PreviewTree there is a strict sequence you have to follow [21:36] 1) make a Transformpreview [21:36] (happens at class init) [21:36] 2) call methods on it to create/move/delete files [21:36] lifeless: I note that creating files and deleting files works just fine [21:36] 3) call get_preview_tree() [21:36] modifying their contents doesn't [21:37] ohic [21:37] 4) call that-tree.commit() [21:37] so in fact, this is pretty broken? [21:37] aaaaaaaaaaaaaaaaaaaaah [21:37] I may be wrong [21:37] but looking at _PreviewTree.__init__ [21:37] lifeless: is this going to be massively painful to fix? [21:37] I don't see why [21:38] just don't call _update_tree where you are [21:38] ok [21:38] and don't call self.PrevTree = self.TransPrev.get_preview_tree() in init [21:38] instead, do that line in your commit [21:39] I have a merge function also [21:39] should I call it there? [21:40] actually [21:40] I may be wrong about risk of making new trees [21:40] jus tshove a self.PrevTree = self.TransPrev.get_preview_tree() call into your commit function [21:42] and don't remove the updatetree calls elsewhere? [21:42] yeah [21:42] see how that works [21:42] can I ask, what this is for? [21:42] to cut a long story short, an online ide for python that controls robots and has to be deployed in an environment where we can't install software, so it's web-based [21:43] * lifeless whistles [21:43] thats pretty cool [21:43] :D [21:44] lifeless: http://studentrobotics.org [21:44] :O [21:44] :OI [21:44] :O [21:44] I think [21:44] you just fixed it [21:45] * iocor waits for the tests to finish [21:45] oh my god [21:45] lifeless: I owe you all my internets for a wek [21:45] glad I could help [21:49] :D:D:D:D [21:56] Bla - just realised, the feature I've been planing for the last hour, was already implement by Ian, just not in use : [21:56] :-) [21:56] :P [22:00] Superrelativistic implementation FTW. [22:03] nah [22:03] guido's time machine [22:04] dude just can't seem to keep it locked up [22:05] Well, it's a time machine. If you forget to lock it up ONCE, it's the same as never locking it up. [22:11] Bla - SEACOM down for 6-8 days: http://www.seacom.mu/news/news_details.asp?iID=143 [22:12] I nice reminder of how slow SAT3 is. === jfroy_ is now known as jfroy [22:45] For Ian's new window installer build script, he added the ability to define more than one series. [22:45] See http://bazaar.launchpad.net/~bzr/bzr-windows-installers/trunk/annotate/head:/bazaar_releases.py [22:46] For 2.2 I need to specify defined revisions. [22:46] But for .dev, I want it to use the latest version for each plugin. [22:47] You can specify a revision spec per Project/Plugin object. [22:49] But the way that is currently defined, you can only define the 2 series to have the same plugin versions, as they are shared. [22:50] I'm not sure how to change this so that I can have different plugin versions, but not have to repeat plugin details, and be syntactical clean. [22:52] Maybe add a copy_write method, define the plugins globally, and copy_write with the specific revision for the series. [22:53] Any better ideas? [23:13] hi GaryvdM [23:13] hi jam [23:13] Hi poolie [23:14] hm, got another mail with team membership overriding direct subscription for X-Launchpad-Message-Rationale and bottom note [23:14] heh [23:14] hi poolie [23:15] as I completely failed to branch launchpad, guess I better just file a bug [23:15] poolie: I was out by 2 hours on my thing this morning :O [23:19] in which direction [23:19] just finished