[00:20] hi all [00:20] Hi poolie [00:20] You have some approved branches to land :) [00:21] moinmoin :) [00:21] hey, thanks [00:21] that's not very dutch :) [00:22] apparently it is, though not the area of the Netherlands I'm from [00:22] http://en.wikipedia.org/wiki/Moin [00:33] oh, cool, i was just wondering after i asked [00:33] spiv there was one patch i think about adding options to diff that was a bit old and that needed tests [00:33] maybe you/we should finish it [00:35] jelmer, i liked your mail about lazy imports [00:35] great title too [00:36] ahoyhoy. if i have a lightweight checkout whose branch has moved, can i point it at the branch's new location or do I have to blow it away? [00:38] poolie: thanks :) [00:39] dash, you should be able to redirect it with 'bzr switch' [00:39] oh, hup. switch works if I remove the loom plugin. [00:39] maybe 'switch --force'? [00:39] yeah. [00:40] should've immediately gotten suspicious when that error message said 'thread' in it. [00:40] that sounds like a bug in the loom plugin? [00:41] quite likely [00:41] it wraps the switch command to add some extra functionality [00:41] I also had a terribly old version of it hanging around [00:41] (just upgraded this box from karmic to natty) [00:48] that would be such a good case for refactoring commands to allow cleaner extension [00:48] in fact, that refactoring may already exist in cmd_status and just need to be used === psynaptic|away is now known as psynaptic === psynaptic is now known as psynaptic|away === 5EXACGT2D is now known as deepti [05:22] btw [05:22] some kind of anonymous smart server access to lp would be nice! [05:22] i guess this is still lurking at the "not important enough" level [05:25] well [05:25] loggerhead does it [05:25] probably just need: [05:25] - permit the url through [05:25] - resource it [05:39] there is a bug for it [07:37] poolie: any objections to me landing https://code.launchpad.net/~bialix/bzr/2.3-py2exe/+merge/55103 ? [07:38] poolie: it's been sitting around for a while and looks safe enough. My main hesistation is that it's sort-of adding a feature to a stable release series. [07:39] poolie: but my I'm inclined to think it's worthwhile despite that. I guess you could say that it's fixing a bug (not being able to install plugins when using the windows .exe) rather than adding a feature. [07:41] it's ok with me [07:42] bialix is probably best placed to judge the risk of it [07:42] let's not let it sit anyhow [07:42] hi all ! [07:42] poolie: thanks! [07:43] oh i was going to ask you to do a pp report [07:43] we've got a bit out of the habit but there were a lot of patches this week [07:43] spiv: +1, I think the issue here is that it's landing into core when it's really a windows installer bug [07:43] and you did a lot on them [07:44] poolie (et al. ;): config stuff sneak preview available at lp:~vila/bzr/new-config, [07:44] beware, it's a loom, but it contains the minimal implementation of the needed building blocks [07:45] it still lacks doc (which I will write today) [07:46] it's currently ~1000 lines tests + code (evenly split, amazing...) and define 9 threads for review (the upper two are not relevant) [07:47] so, to really see where I'm heading you can look at the config-concrete-stores and config-concrete-stacks threads to get an idea [07:49] vila: speaking of configs… https://code.launchpad.net/~abentley/bzr/appenddir/+merge/50060 is stalled, and you're probably the best person to unstall it [07:50] vila: is it still Needs Info for you, after the reply from Aaron? [07:50] spiv: yeah, that's part of the motivation for focusing on config :) [07:50] basically I'd like to get rid of policies as they are today and I'm still unclear about whether this can land soon enough to provide an alternative [07:51] vila: well, at the least put a comment on the merge proposal saying what we're waiting for [07:51] vila: so other people (like patch pilots ;) can understand where it's at, and why [08:01] hi vila [08:01] spiv: done [08:01] poolie: hey ! [08:01] vila i'm not a big fan of policies either, and i'm not very keen to add more of them [08:02] poolie: rationale added in the comment [08:02] i think it complicates the user model a fair bit for what it actually buys us [08:02] +1 [08:02] vila, do you think you could send a short overview of that loom [08:02] like, 3 paragraphs? [08:03] poolie: I was about to make a "fake" merge proposal for it with a bit of high level description of the goals, sounds good ? [08:07] mm [08:07] rather than the goals i'd be more interested in [08:07] what changes to the user experience there are, if any [08:07] and what changes to the api there are, if any [08:08] i think we pretty much agree on the goals in your previous mail [08:08] ha right, bad words again [08:09] I thought new API and what is still needed to actually use it in bzrlib [08:10] but also mentioning some issues that this new design is ought to address [08:12] * poolie branches it [08:18] vila: thanks! [08:19] spiv: does my comment makes sense ? Explain why I was apparently silent on the subject ? [08:19] vila: yes [08:19] thanks [08:19] vila, one comment on your docs [08:19] https://code.launchpad.net/~vila/bzr/new-config/+merge/56887 [08:19] (i've done the opposite on this myself in the past) [08:19] and that is, describing the current problems in documentation that is intended to be merged and carry on into the future is bad [08:20] forget about the doc in this loom, I plan to rewrite it from the ground up separating user and dev povs [08:20] the config doc starts off with what will be, in september 2011, a description of primitive history [08:20] ok [08:20] poolie: should https://code.launchpad.net/~mbp/bzr/506265-command-deprecation/+merge/55030 be marked Work In Progress rather than Needs Review? The last comment suggests you're going to do more work. [08:20] spiv tbh i wouldn't mind a tie-breaker there [08:20] poolie: at most, I will outline issues with specific markup or something so they stay up-to-date with the code [08:21] it is not perfect but in some ways i want to just land it [08:21] and then add a general configuration option to turn off particular warnings [08:21] for which i think there is a bug [08:21] poolie: oh, I wouldn't mind landing incomplete stuff if it makes further submissions easier to review [08:21] * vila LOL [08:21] vila, perhaps the "here's what's bad today" belongs in a bug or a set of bugs [08:21] nice, but i was talking to spiv [08:22] poolie: it belongs to devnotes in my mind [08:22] poolie: yeah, I understood, was just being silly ;) [08:23] poolie: I also thought about easy ways to deprecate config options so if you work on easily deprecating commands I know I [08:23] I'll benefit from it (damn badly placed return key !) [08:24] poolie: so what's the downside? That there's no way for a user to suppress the warnings currently, even if they alias get=branch? [08:24] yes [08:24] that's the only problem i know of [08:24] there may be others [08:25] poolie: Ok, in that case I agree let's just land it and find out if there are any others :) [08:25] poolie: (but file a bug for being able to suppress the warning, if there isn't already) [08:25] * spiv updates the MP [08:25] poolie: Is the cover letter for https://code.launchpad.net/~vila/bzr/new-config/+merge/56887 answer your needs ? [08:26] poolie: or do you want more details on say, policies for example, or option converters or [08:26] spiv, we're more likely to find the unknown unknowns if we land it [08:26] vila it's a good start [08:27] poolie: precisely [08:27] poolie: Be Bold, as wikipedia would say… [08:27] poolie: you said 2 or 3 paragraphs, I tried to make it short ;) [08:29] poolie: that makes three approved patches you have waiting to be fed to PQM. Is there any reason not to run those through feed-pqm now (aside from any inconsequential stuff like needing to set commit messages)? [08:30] * spiv is hoping to get http://webnumbr.com/bzr-active-reviews back down to pre-April heights. [08:38] spiv, please do [08:39] i did get some pqm failures earlier but i have not worked them out yet [08:39] you might as well feed all the approved ones though [08:45] Ok, that should keep PQM busy for a while. [08:45] vila: i replied [08:47] poolie: hmm, food for thought... [08:48] poolie: at first glance I think we agree but don't understand each other yet [08:48] :) [08:48] ha, right, I misread 'reusing existing objects' at first read, [08:49] you mean we should reuse config files that has been already read from disk ? [08:49] (I misread it as: we should reuse python classes we already defined) [08:49] vila: it sounds more like 'reuse instances' than 'reuse classes' to me [08:50] yeah, I agree with that, this is not apparent in the implementation but it's definitely on my agenda [08:50] so, not apparent *yet* [08:51] but roughly there should be something ~like possible_transports for config Stores [08:51] vila: hmm. [08:52] vila, wow, interesting point about fixed bugs [08:52] it reminds me how much i dislike all the 'fix released' bugspam you can get [08:52] spiv: the intent being that a given config file should not be read more than once for a given bzrlib operation (as opposed to read once by option today) [08:52] perhaps that idea should really go into lp [08:53] ie merge those states and say the milestone the fix is in is released, or not [08:53] vila: for configs tied to branches or working trees, that might be good. For globals though I think it'd be weird to have to pass around a param everywhere when it's "global" [08:53] spiv: yup, I think we *shouldn't* pass it around *because* it's global [08:54] vila: off the top of my head, poolie's suggestion that it could be stored on the library_state sounds good to me [08:54] spiv: it's even defined *outside* of bzrlib: inf files on disks [08:54] spiv: yup, agreeing to that too, replying [08:54] vila: cool [08:55] spiv: in fact, it's either user (or site) specific and should be tied to libstate, or it's branch/wt specific and should be tied to that [08:55] vila https://bugs.launchpad.net/launchpad/+bug/163694 [08:55] Ubuntu bug 163694 in Launchpad itself "Fix Committed/Released distinction is inconsistent and unproductive" [High,Triaged] [08:55] vila, one specific point for the library_state is: [08:56] if that was done properly, there would not need to be any config-specific test isolation code [08:56] which would be nice [08:56] spiv: which should be ... yeah to what poolie said ;) [08:56] (well, there may need to be some to isolate it from the environment in which the tests are run, but we should get for free isolation of one test from the next) [08:56] poolie: e-x-a-c-t-l-y [08:57] use TestCase and rest assured you're isolated [08:58] the more I think about it, the more I view global configs as... compilation options. But because we use python, we can handle them dynamically [08:58] Still, you want the code associated with the options to be well tested [08:59] and you want easy ways to test them [09:02] well [09:02] even in TestCase, it would be good to have fewer things that specifically isolate different aspects [09:03] spiv thanks for feeding in https://code.launchpad.net/~mbp/bzr/659763-non-ascii-gecos/+merge/55862 [09:03] yup, but some existing things could find their way in configs too [09:04] it could have been polished more but finishing it is more important than getting the skip message precisely right [09:04] that too! [09:04] i have seen many tests that could be better with this [09:04] also it will give them a less ad-hoc way to control what happens in the code under test [09:12] poolie: replied, second read mad more sense, I confirm my original feeling ;D [09:15] poolie, spiv: Also note that the proposal doesn't make any assumption about what name space is used nor what section names are used/enforced whatever [09:15] I knowingly limit myself there to what is used *today* [09:16] I still have some strong opinions about how we should change that though ;) [09:16] vila, i need to go soon [09:16] to meet spiv, actually [09:17] But hopefully these opinions can be expressed in further submissions focusing the discussion and more importantly *not* blocking the building blocks to land [09:17] poolie: no worries, I still have plenty to do [09:17] poolie: and I optimistically consider that we agree enough to continue ;) [09:28] poolie: gee, bug #163694 has a real high S/N ratio... still reading [09:28] Launchpad bug 163694 in Launchpad itself "Fix Committed/Released distinction is inconsistent and unproductive" [High,Triaged] https://launchpad.net/bugs/163694 [09:30] it is nice [09:31] hrm [09:31] * maxb gets an unexpected need to re-oauth hydrazine to lp [09:32] poolie: Would it upset you if I set append_revisions_only on hydrazine trunk? :-) [09:32] maxb: bad symptom, I remember poolie venting (first time I ever witness that ;) about a lp API change.. may be related [09:32] ironically I think it's poolie's changes which probably caused it for me :-) [09:33] But yes, I am deeply disappointed about launchpadlib's cavalier approach to api compatibility [09:35] maxb, sorry for the bump, please do [09:35] i would like that to actually become the builtin default [09:35] but it will take a bit of consideration [09:35] that reminds me to comment again on that bug [09:36] Well - I think it should be the default for server-hosted always-remote branches, but probably not for local working areas [09:37] or maybe it should be the default even there, but there should be a y/n prompt or dedicated option to say it's ok [09:37] or maybe it should be on for push but off for pull :-) [09:38] * maxb stops brainstorming into the channel [09:39] options, options, so many gems waiting to be used from inside bzrlib, so little ways to get there (so far ;) [09:40] OK, so to finish the hydrazine point I raised: Yes, hydrazine has changed its credentials storage path and you will need to reauthenticate. [09:40] I wonder if it's worth migrating old credentials [09:41] maxb, are you going to come and meet us in london? [09:41] some of the time? [09:41] it's from the 16th of may on [09:41] oh, that reminds me [09:41] . o O (Please say yes) [09:41] ah i was thinking of https://bugs.launchpad.net/launchpadlib/+bug/752095 [09:41] Ubuntu bug 752095 in launchpadlib "Launchpad constructor parameters changed incompatibly in natty" [Undecided,New] [09:42] I was going to send a "Hi, what do you do at these things, and how much is worth attenting for non-employees?" email [09:42] I have holiday allotment to spare, so I might turn up for the entire week if it's sensible to do so [09:43] so, we'll mostly just pair on things together [09:43] there will be some talking but mostly hacking [09:44] and just hanging out together [09:44] in the evenings or whatever [09:44] hmm. I could finish off some of my limbo-ed bzr-rewrite and udd branches :-) [09:44] that would be nice; you could probably get someone to work on it with you [09:44] it is pretty non-corporate, i would say [09:45] in canonical's early days there was a lot of spec-writing at UDS and other sprints [09:46] maxb: It tremendously helps understand each other better to have face-to-face discussions and the consequences are still seen months after a sprint [09:47] Well - sounds like it could be fun, so you'll be seeing me there for some, if not all of the week :-) [09:47] \o/ [09:48] I still remember AfC face from years ago and it gives a different color to everything he said since then, for example [09:48] ok good night guys [09:48] :) [09:48] poolie: enjoy your week-end ! [09:49] maxb: and that's without counting the high bandwidth during the sprint itself of course [10:14] poolie: (too bad you're gone) https://bugs.launchpad.net/launchpad/+bug/163694/comments/28 ... nicely summarized and cross-linked, S/N enhanced :-) [10:14] Ubuntu bug 163694 in Launchpad itself "Fix Committed/Released distinction is inconsistent and unproductive" [High,Triaged] [10:40] Tried yesterday, trying again today: === dije-away is now known as dije [10:41] Doing a checkout to my home directory from a branch at ~/bzr_scm/dot, I [10:41] get the following error: [10:42] bzr: ERROR: Failed to rename /Users/phil/Library/Preferences to [10:42] /Users/phil/.bzr/checkout/limbo/new-159/Preferences: [Errno 13] Permission [10:42] denied [10:42] (On Mac OS X 10.5.8, Titanium PowerBook G4) [10:42] dije: from an OSX pov, renaming /Users/phil/Library/Preference sounds really dangerous [10:43] vila: right, so why is bzr doing it? [10:43] dije: what do you version in ~/bzr_scm/dot ? [10:43] vila: My home config [10:43] dije: cause you asked it to :) Why you asked it to is the question [10:43] dije: more precisely ? [10:43] vila: config files for: [10:43] tcsh [10:43] emacs [10:43] screen [10:43] you version files that are under library/preferences ? [10:44] ratpoison [10:44] vila: I think so [10:44] vila: Probably Mozilla* [10:44] dije: ok, so to clarify, try to branch in a different directory to see which files are versioned [10:45] dije: different from your home directory that is, so ~/test will do [10:45] vila: Everything in bzr_scm/dot is versioned, that's its only purpose [10:45] dije: I'm searching for specifics, *everything* is not specific [10:46] vila: Sorry, answered too soon (after you typed "versioned") [10:47] vila: So I'm looking for specific diffs in permissions only, and/or existence vs. non-existence, and/or content diffs? [10:47] hard to tell :-/ [10:47] start for searching for files/dies under lib/prefs [10:47] vila: Will get started [10:47] dirs not dies [10:48] vila: You said branch, I'm trying to checkout; which do I need for this exercise? [10:49] also, *why* do you get permission denied there ? what does 'ls -dl lib/prefs' says ? [10:49] vila: Set-group-id. Weird [10:49] vila: (until I chmod'ed it) [10:50] hmm, can you check what is the default chmod for another user ? [10:50] * vila curses not having an osx setup at hand [10:51] I did, against my own (the machine under discussion is my parents') [10:51] I'm maintaining it remotely over ssh [10:51] My machine differs in being Intel not PowerPC, but same OS release. [10:52] The perms on ~/Library/Preferences show as drwx------+ on my machine [10:52] and on theirs as drwx------@ (after I chmod'ed it) [10:52] hmm, so that @ is for extended attributes IIRC, but no idea what they are [10:52] bzr is still failing after your chmod / [10:53] ? [10:53] OS X (HFS+) does ACLs, but they've never been used on either machine to my knowledge [10:53] bzr is still failing [10:53] Same error [10:53] attrs can be more than just ACLs IIRC [10:54] ok, try to rename it from the finder ? [10:54] Rename ~/Library/Preferences? [10:54] Sounds dangerous [10:54] oh, wait, you don't have weird mounts or something where ~ and ~/lib/prefs are on different volumes right ? [10:54] No. Good check though. [10:55] dije: yes, this one, you can revert it [10:55] if it works from the finder, try from a terminal, I'm trying to see how to reproduce without bzr being involved, it's a file system issue at the root [10:55] Oh no, remote machine is gone! Parents are coming to lunch, I think they're bringing it [10:56] Sorry [10:56] dije: and yes, it's dangerous in itself but [10:56] It's near 11am here [10:56] oh wait ! You said accessed thru ssh ? [10:56] Right, I run screen on their machine and (re-)attach to it over ssh [10:57] ha, ok, so bzr runs locally not on top of an ssh fs right ? [10:57] Right [10:57] * vila rules sshfs fuse bugs [10:57] out [10:57] yes [10:58] It's a single-disk, single-cpu, single-user (mainly), router-and-one-computer-LAN home office setup, absolutely nothing fancy apart from DynDNS and my remote access [10:59] ha, finally found an OSX host I can look at with ssh [10:59] cd Library ; mv Preferences toto [10:59] mv: rename Preferences to toto: Permission denied [11:00] ok, so, we can't do that, that's a point, we can now switch to *why* are we trying ;) [11:00] ditto on my Intel machine [11:00] dije: can you retry your failing co with -Derror [11:01] that should give us a traceback, pastebin it and I can look at where it's coming from [11:01] Not til they arrive with the laptop! Sorry [11:01] lol, oh right, try again later then [11:01] Will do, thanks for help so far [11:02] dije: or file a bug explaining our discussion a bit, that will make it easier to track for everybody [11:02] ok [11:02] dije: https://bugs.launchpad.net/bzr/+filebug [11:04] dije: oh, and don't forget to mention your bzr version and where you installed it from (in case the traceback is not clear enough for that) === psynaptic|away is now known as psynaptic [11:10] vila: will do [11:11] FYI: MacPorts package [11:12] dije: >-/ We don't often hear about it (as opposed to the installers) but while there are some dark areas regarding the dependencies, we didn't hear about blatant bugs there either [11:13] vila: Python should isolate the platform to a degree [11:13] hehe, yeah, to a degree and for some values of isolate ;) [11:13] Right :-) [11:14] I've had MacPorts bzr working on multiple Macs for x > 3 years [11:14] but nothing that should be related to your bug anyway, I still can't think of a cause so far [11:14] wow, great [11:14] and kudos for admin'ing with bzr ;) [11:14] * dije blushes [11:15] Works great across linux and cygwin too [11:16] dije: it it turns out to be a bug related to some internal design, it may be hard (and long) to fix, so, as a *workaround*, I admin some osx hosts myself but instead of versioning the files directly, I use a mix of symlinks or copies of the system files [11:17] I don't version any *system files*, just config files under (in this case) system dirs [11:17] First time the issue has arisen [11:17] right, but the issue is kind of the same, if you need special rights for some operations, using copies works around the issue [11:18] Need to take that into account, maybe redesign my repo [11:18] I can;t think of why we want to rename Preferences though, unless some weird side-effect ends up triggering it [11:18] Already use symlinks extensively [11:19] Yes, that does seem strange [11:19] yeah, me too, but nothing under prefs so far, only under LaunchAgents in fact [11:21] I know Preferences is localized when looked at from the finder, but at the fs level, it's always Preferences [11:21] so this should *also* rules out any fancy language change from your parents [11:22] had not thought of that! [11:26] More weird detail: the target dir *used* to be versioned, but when I tried to sync up for the first time in quite a while (x > 6 months) I found no .bzr dir [11:27] oops, someone deleted it ? [11:27] The branch in ~/bzr_scm/dot was intact and synced fine with my remote machine [11:27] or moved it ? [11:27] Well, "someone" could only have been me [11:27] no restore from backup ? [11:27] In a fugue state [11:28] This *is* my restore-from-backup strategy [11:28] dije, well, your parents can too no ? They have physical access to the mac I presume ;) [11:28] Yes but not admin, and they have nothing like the skills to single-user-boot [11:28] maybe moved somewhere else ? [11:28] Maybe [11:28] err, wait, oh you mean that's inside your own account ? [11:28] Right [11:28] aaah [11:29] yeah, of course, makes sense [11:29] * dije spots light going on over vila's head [11:29] eheh [11:30] * dije holds breath [11:31] no no keep breathing ;) [11:31] phew [11:32] ha, one possible scenario (but hairy) [11:32] you somehow, by working on two different branches (one local, one remote), added Preferences twice [11:33] each add creating its own file-ID for it [11:33] omg [11:33] sounds feasible [11:33] now, updating the remote tree, creates a conflict to tell you that (A so-called Content Conflict: the same name for two different objects) [11:34] *This* could lead to an attempt to rename the dir [11:34] ha no, wait, that's simpler than that ! [11:34] Really? [11:34] You're trying to checkout an existing branch onto an existing tree and bzr try to move the items that are on its way ! [11:35] Yes, lots and lots of them [11:35] damn, I didn't realize the fallouts of 'the .bzr dir has disappear' [11:35] wow, hmm, how to recover from that... [11:36] Can't checkout to some new dir, then move files including .bzr/ ? [11:36] the most obvious will be to create a clean tree somewhere and just move the .bzr dir [11:36] That answers that :-) [11:37] So the move of .bzr is necessary; is it sufficient, or do I need to move all the checked-out files (that differ) as well? [11:37] dije: hmm, I think you found a nice bug, trying to do a checkout in an already populated directory is likely to cause chaos and we shouldn't even try (unless there are use cases that escape me at the moment) [11:37] dije: no, that's the nice bit [11:38] move the .bzr dir only (restore it in fact) [11:38] and 'bzr st' will tell you about the changes [11:38] Use cases like this PEBKAC ? [11:38] from there you can decide if you want to 'bzr commit' or 'bzr revert' [11:38] dije: It's hard to say [11:39] as you present it, you're just trying to restore order and bzr answer is creating even more chaos, not *that* helpful ;) [11:39] Now, recovery plans are not always the cleanest process in the world... [11:40] vila: Great, this gives me hope. So, I checkout to ~/foo, then mv ~/foo/.bzr ~/, then either bzr commit or bzr revert. [11:40] dije: 'bzr st' first ! [11:40] Where do I bzr st first, in ~ or ~/foo? [11:40] dije: both :) [11:41] dije: to make sure we don't run into path issues: [11:41] Hang on, can't 'bzr st' in ~ ... no ~/.bzr! [11:41] cd ~/foo ; bzr st; bzr info [11:41] OK [11:41] check the paths mentioned by the later if some are relative you may run into trouble by moving .bzr [11:41] if they are absolute, you should be fine, so: [11:42] mv ~/foo/.bzr ~/ [11:42] cd ~ [11:42] bzr st [11:42] OK [11:42] should tell you the differences between the basis revision (the one defined in the branch) and the actual content on disk [11:43] from that, it should be obvious to you, either the tree is correct: bzr commit [11:43] or the tree is wrong: bzr revert [11:43] Got it. You are a genius. [11:43] What if paths are relative? [11:43] if it's a mix, well, 'bzr revert ' or 'bzr commit -m 'recover from ???' ' [11:44] Can I edit something under ~/.bzr to fix paths? [11:44] dije: you will need to edit them in /.bzr/branch/branch.conf probably [11:44] Cool [11:44] dije: you're a fast learner :) [11:45] dije: really, the missing bit was '.bzr disappear' and I'm trying to recover [11:45] Right [11:45] dije: I may have understood faster what was going on if you started with that, but, hey, bug reporting when you know what the bug is is so easy ;D [11:46] Right, hindsight helps [11:46] dije: worth filing a bug *anyway* if only to remind us how confusing the error was for you (and even for me) [11:46] Techie view is to start with the detail instead of the big picture [11:47] yeah, not blaming you here, just sharing thoughts [11:47] I'm not sure I would have done better... [11:48]