[00:00] oh, igcs updated loom, right [00:00] Yes, the patches igc submitted recently. [00:00] abentley: what was the bug? [00:00] didn't jml have a patch for clone already? [00:00] I did [00:01] it got merged into abentley's branch too. [00:01] lifeless: yes, and it was my modification of that patch which exposed the bad behavior. [00:01] lifeless: Anyhow, when I thought it was about all_revision_ids, I thought I should confirm that it should work across fallbacks. [00:02] The bug is that we open a repository before opening a branch, and we attempt to use that repository even if we find a branch later. [00:03] oh yes, references won't like that [00:03] Exactly. [00:03] It doesn't follow branch references and it also doesn't set fallback repositories. [00:06] Anyhow, I've got a fix now. I only pinged because I misdiagnosed the problem at first. [00:06] abentley: sweet [00:22] another newbie question. just tried my first commit, and got this error: bzr: ERROR: Cannot lock LockDir [00:23] nosecow, is this on a checkout? [00:24] beuno: no, the checkout was successful. created a test directory with one file, then tried to commit, and got that error [00:24] nosecow, this was using a lp:~yadayada type for URL? As in, from Launchpad? [00:25] beuno: no. bzr co ftp://myhost/var/www/mysite c:\apache\htdocs\mysite [00:26] that's odd then. Can you paste in the full error? [00:26] yes [00:26] bzr: ERROR: Cannot lock LockDir(ftp://linuxdev01/var/www/propertypartner/.bzr/re / pository/lock): File exists: '/var/www/propertypartner/.bzr/repository/lock/un7w / nlmbyp.tmp': 550 Create directory operation failed. [00:27] nosecow, what version of bzr are you using? [00:27] ms windows ftp server? [00:27] nosecow: thats strange. Can you use 'sftp' instead of 'ftp' - it is a much nicer protocol and less problematic [00:27] bueno: 1.5, just downloaded [00:28] lifeless: had trouble with setting up sftp; will go edit my conf file...can i just checkout again once i change? [00:28] nosecow: yes === mw is now known as mw|out [00:32] lifeless: changed default scheme in authentication.conf to sftp; but bzr does not seem to be picking up the proper username - is still using it's 'guess' [00:33] nosecow: put the username before the url like: [00:33] sftp://USERNAME@hostname/..... [00:33] okeydokey [00:34] sigh: bzr: ERROR: File exists: u'C:/apache/htdocs/propertypartner/.bzr': [Error 183] C / annot create a file when that file already exists: u'C:/apache/htdocs/propertypa / rtner/.bzr' [00:34] * igc back in a few hours [00:34] should i just delete it? [00:35] and, i really appreciate this help... [00:36] yes, you can just delete that if its where you want to checkout to [00:36] back in a little bit : food [00:40] Okay, sftp protocol used, checkout from linux server to windows machine works fine, adding a directory and attempting to commit yields: [00:40] bzr: ERROR: Cannot lock LockDir(sftp://nosecow@linuxdev01/var/www/project/.bzr/repository/lock): Permission denied: "/var/www/project/.bzr/repository/lock/ctb89f5sh3.tmp": [Errno 13] Permission denied [00:41] nosecow: Does your sftp user have read/write access to the repo? [00:41] ooh good question. can you tell it's been a long time since I used unix? :) === mwhudson__ is now known as mwhudson [00:47] peng: excellent advice, thank you [00:48] yesssssssssssss [00:48] peng,bob2,lifeless: thank you all for the help. i have the basics working now. I appreciate all of your help! [00:48] :) [01:01] bye [01:11] spiv: were you going to come down here today? [01:19] poolie: yeah. I'm just about to head out the door. I slept badly, and was just trying to figure out if I was sick or just tired before I came down and possibly spread contagion :) [01:19] poolie: it seems I was just tired, which is good (relatively speaking...) [01:20] beuno: what do you think of the new loggerhead bugs? [01:23] lifeless: https://bugs.edge.launchpad.net/loggerhead/+bug/240504 is a bit interesting [01:23] Launchpad bug 240504 in loggerhead "Should not generate revisioned URLs unless specifically needed" [Undecided,Confirmed] [01:24] because if you want to generate a link to "file X in rev Y" i think you need to load the inventory for rev Y [01:24] which is a pain, probably [01:24] mwhudson: well [01:25] spiv, oh np, just wondered [01:25] glad you're not ill [01:25] mwhudson: first approximation: load the inventory for .tip. If the modification revision is the same as in .tip, then you don't need to specify a revision [01:26] mwhudson: anyhow, this is why bzr search has phrase searches for (file_id, revision_id) -> 'p', '', PATH [01:26] ah interesting [01:27] so if we demanded bzr-search, we could do this more quickly? [01:27] mwhudson: its how 'bzr search foo' can return README as a path [01:27] (not sure this is sane, of course) [01:27] mwhudson: well, there are multiple answers. In particular I wanted to say to Olav that we agree its not friendly [01:27] sure [01:28] right now I'd do the low hanging fruit [01:28] jam: spiv: I've mailed a sample of how to do it easily [01:28] well, i think the priority with loggerhead is to get some of the branches floating around merged [01:28] jam: spiv: feedback + things that would make it easier appreciated [01:29] using tango stuff would be cute; cuter still if it was just an optional theme [01:31] i don't think the visual stuff is going to be ready for merging for a while [01:31] (well, a week or so, let's say) [01:31] mwhudson: :P [01:31] * mwhudson is running on internet time [01:34] blog aggregators must die [01:34] http://www.asofterworld.com/oq-display.php?id=58 [02:13] http://datacharmer.blogspot.com/2008/06/mysql-sandbox-122-and-joys-of.html [02:14] lifeless: nice [02:28] sweet [02:32] lifeless: assertRaises where? [02:33] in the test [02:33] you raise a specific exception [02:33] and fail if its not raised [02:33] that fits assertRaises doesn't it ? [02:33] hum [02:34] i want to generate an ImportError [02:34] if it doesn't thats fine - but its close enough people will get confused IMO so a note to that effect would help clarity [02:34] i don't see how assertRaises can do that for me [02:34] possibly i should remove the 'else' clause; if for some reason that module is loaded it will fail in a different way [02:35] the raise is just to generate the input for the real test [02:35] which is the call to format_exception [02:35] right [02:35] i guess i could pass a lambda to assertRaises but i don't see the point [02:35] there is a bit of action at a distance happening I think. Specifically - are the args to ImportError well defined across python versions? If they are why don't you just 'raise ImportError' [02:36] i do... [02:36] if they are not well defined then presumably the code is fragile, or we need python version based conditional logic [02:36] oh in the other test [02:36] + try: [02:36] + import ImaginaryModule [02:37] it seems like this is more realistic and no harder than just raising ImportError [02:37] so I guess I'm saying I'd have done a test that 'import MissingModule' resulted in an ImportError with a specific value in the args, to catch python variations, and then all the other tests as 'raise ImportError(...)' [02:37] which is close to what you've done ;) [02:38] ok [02:38] that would also work [02:38] that would be a bit more precise, i don't think it's needed here [02:38] thanks for the prompt review [02:38] anyhow, its bb:approve'd [02:38] the rest is sugar [02:38] can you also read my comment on https://bugs.edge.launchpad.net/bzr/+bug/205230 [02:38] Launchpad bug 205230 in bzr "error message recommending incorrect setting of PYTHONPATH" [Low,Confirmed] [02:38] at the end [02:39] want to trivilaly fix that too [02:40] thats an improvement [02:41] a note though - folk with .zips (e.g. windows) may need 'bzr.zip' on the path. [02:41] 205230 is good as is [02:41] just speculating about potential further tweaks [03:09] time to pkill firefox [03:10] ah look, 20% cpu back just like that [03:34] That must be nice. I get 100% (well, 100% of one CPU) back when I SIGSTOP it while not actively using it :| [04:43] * beuno looks at new LH bugs [04:45] ah, fun [04:46] mwhudson, I was thinking, it shouldn't be too hard for us to be able to optionally serve branches over http [04:46] beuno: you have a few to look ;) [04:46] would be a nice feature to have [04:46] * mwhudson loves how fast bzr log --short | less starts up now [04:46] hey Verterok [04:46] beuno: um, true i guess [04:47] beuno: broadly speaking, i would tend to leave serving static files to apache... but i guess it wouldn't be hard [04:47] mwhudson, we could even provide URLs to branch ay any given point in time, for your copy'n'paste comfort [04:47] * mwhudson hmms [04:47] I agree, although as a plugin for bzr that would rock :) [04:47] yeah, interesting idea [04:48] file a bug on that too :) [04:48] heheh [04:48] more bugs? :p [04:48] beuno: there's more stuff in my wsgi-ify branch now [04:48] beuno: bugs are great [04:48] absolutely, makes it clearer what to do! [04:48] * beuno looks at the whisky branch [04:49] also, we should have export on there. "Download tar.gz for this revision" [04:49] that sounds resource intensive [04:49] but, well, sure :) [04:50] so long as we can turn it off for lp... [04:50] probably, but, well, generate it once, keep it forever :) [04:51] well, that just consumes a different resource [04:52] storage is cheaper, but yes, all these things should be optional [04:56] getting a tar is not expensive [04:56] compressing it is somewhat [05:00] mwhudson, what do you think about setting a milestone for 1.3 in LP, and filing bugs on what we absolutely want for it, and target them. That way it should be easier to focus [05:00] beuno: i think that's a good idea [05:01] mwhudson, cool, because only you can do that :p [05:02] beuno: i've just made you a 'driver', does that let you do it? :) [05:03] mwhudson, heh, no :) [05:03] darn [05:04] I wonder what that does anyway, I don't see anything new I can do [05:04] maybe it means you can target bugs to milestones? [05:05] not even [05:05] beuno: do you think i should create a new productseries? [05:05] beuno: you should apply to join the loggerhead-team, btw [05:06] i'll poke robey to make me an admin [05:06] jml: "i'd love to" cute :) [05:06] like Robert's thing that "the code will do X" meaning "will after it's written" :) [05:06] mwhudson, requested. I'm not sure about the series thing, that always confuses me. I think you *have* to [05:07] * beuno applies [05:07] i guess that it confuses me too points to a problem in launchpad... [05:07] beuno: do we call it 1.3 or 2.0 do you think? :) [05:07] poolie: well, the first email was sent *before* I consulted my calendar :) [05:08] mwhudson, 2.0 sounds cooler :p Maybe we can try releasing the same as bzr versions, to me it less confusing and obvious with what version it works with [05:09] beuno: that's probably a good idea [05:09] i guess that means 1.6 then as we'll probably release between 1.6 and 1.7 [05:09] yeap, sounds good [05:09] I love how versioning is so flexible :) [05:12] hello beuno, mwh [05:13] howdy poolie [05:13] beuno: i think maybe you can "nominate a bug for the 1.6 release" [05:14] mwhudson, nope, I can for bzr, not for LH [05:14] beuno: how strange [05:15] https://bugs.edge.launchpad.net/loggerhead/+bug/236702/+nominate says "The loggerhead release manager is Martin Albisetti. " :) [05:15] Launchpad bug 236702 in loggerhead "No permalink to "latest revision of file" in Loggerhead" [Undecided,Confirmed] [05:15] oh, I can access that link :/ [05:16] releases, productseries and milestones do not have entirely obvious interactions in launchpad [05:16] * mwhudson adjusts his understatement settings [05:16] I can't find anywhere in the UI to do it... [05:16] beuno: "nominate for release" in the actions portlet? [05:17] ah, target to release [05:17] and bzr uses "milestones" [05:18] well, i can add a milestone to the 1.6 series [05:18] i'm not quite sure if i want to though [05:19] don't worry about it, I'll use that [05:19] it's odd, in bzr it *does* say Nominate for... [05:20] oh, maybe all i can do is nominate for a release [05:20] but because you're the driver you can actually target it? [05:20] but you're part of the group and I'm not [05:20] but it makes sense [05:20] sort of [05:21] :) [05:21] i could actually read the code to figure this out, but it feels rather like cheating [05:21] right. " Bug nominations are evaluated by release managers and accepted or declined for fixing in a release. " [05:21] hahaha, and, from the looks of it, you may get lost for a while :p [05:22] oh, https://help.launchpad.net/Projects/SeriesMilestonesReleases seems relevant [05:25] mwhudson, bug #156453 probably should go away with the release of the zpt branch, right? [05:25] Launchpad bug 156453 in loggerhead "production loggerhead branch leaks memory" [Critical,Fix committed] https://launchpad.net/bugs/156453 [05:25] beuno: hope so, let's see [05:29] lifeless: is it ok with you if i disable test_35_wait_lock_changing (patch for this on the list) [05:29] poolie: if you must; I thought we'd discussed a simple way using a closure to test it with being timing dependent or threading [05:30] not as simple as this :) [05:30] i do want to finish that but i don't want to detour into it too much [05:30] let me rephrase - no, I don't think its a good idea to disable it. Its (I estimate) < 2 hours to fix properly. If we disable it, just delete it because noone will ever fix it.. [05:31] hm [05:31] should i fix it now or read the VF patch? [05:31] lets ask spiv where is review is up to [05:31] (biab) [05:31] spiv: where is your review up to [05:51] lifeless: he was working on his hpss version handling patch [05:51] we are both going back to that now [05:54] poolie: so, I don't know the answer to 'should i fix it now or read the VF patch?' [05:55] lifeless: fwiw, I'm reading your knit.py changes atm [06:06] beuno: :) [06:06] ok, sending an incremental diff with the stuff I've improved so far [06:08] spiv/lifeless, i'm reading log.py [06:08] lifeless: i'll read it now and do this [06:08] will try to fix it properly later [06:09] if its timeslice expires i will just disable the test though [06:09] poolie: can I help with the VF review? [06:09] otherwise, I'll review jam's annotate patch [06:11] merge.py [06:11] igc, hi! [06:11] i think it's ok with spiv and me [06:11] hi poolie! [06:11] time to stop for me today [06:12] beuno: another day without reviewing your urls branch, sorry about that :( [06:12] poolie: I'd like a chat with an intelligent teddy bear [06:13] mwhudson, no problem. wsgi thing is more important. I still have a few tweaks to add to it. I'll try and get those done tomorrow so you can review all if it in one batch [06:13] ok [06:13] poolie: so I'm going to ring you :) [06:14] lifeless: be careful with intelligent teddy bears [06:14] lifeless: they can talk back! [06:14] mwhudson, I reorganized the bugs a bit, but feel free to change around anything you'd like. I targeted more or less what we've been discussing. I assume we're going to release with the new theme, right? [06:15] beuno: i think we should [06:15] so new templating engine, new look, new http front end, ... [06:15] anything left for us to change? :) [06:15] tests :p [06:15] most of history.py isn't changing i guess [06:15] ah yes, good point :) [06:16] no, but I saw you have a blueprint to replace that with something more sensible [06:16] maybe we can discuss that after this release, and work out a plan for that [06:17] oh, er, that blueprint is way out of date [06:17] the idea behind it is still good perhaps [06:18] it's worth looking in to. I get the impression we should change it too, so we should have a talk about it after we get this release out, and see if it still makes sense [06:18] and, well, tests. Which can be the main focus of the next release, apart from maybe bug fixing :) [06:34] (back) [06:47] poolie: jam asked this morning if you'd send an email to the list at the close of your day explaining where you and spiv were up to in reviewing the VFs stuff. That way, he can pick it up overnight. He'd also said it was fine if you completed the review before then. :-) [06:47] heh thanks :) [06:47] ok [06:47] i think we can probably finish it today [06:47] i should send an update mail anyhow [06:48] * beuno is off to bed. Night all [06:53] lifeless: in so many places the key list is the mapping of a function over some other list it kind of seems like there should be a more direct idiom [06:54] like that you should pass in a closure that does the mapping [06:54] however i suppose this would not actually make it any cleaner [06:59] I think it would make it less clean [06:59] because it would pollute the interface [07:06] mm [07:06] it was not a suggestion, just a thought [07:06] yah [07:06] merge.py done, looking at your incremental patch [07:07] I was just saying what I thought of the thought :) [07:07] * lifeless eats lunch [07:08] > + Tuple based apis below, string based, and key based apis above [07:08] i don't understand that sentence [07:08] oh hmm [07:09] so I'm trying to say that below the line the code deals only with tuples [07:09] and above you have either plain strings [07:09] or for some apis (existing ones!) tuples that are types in that tuple[0] means 'fileid', tuple[1] means 'revisionid' (for that specific interface) [07:22] lifeless: ok, some feedback sent; if you want me to take a stab at rephrasing it i can [07:22] um [07:22] there is the risk that by the time we get there i will just understand it and not need the docs [07:22] but i think the initial review experience shows its worthwhile [07:24] + if content._lines and content._lines[-1][1][-1] != '\n': [07:24] Ow :) === timchen1` is now known as nasloc__ [07:25] poolie: I think there is value in that yes [07:25] spiv: yes, but thats already in mainline :P [07:25] spiv: I think. [07:26] lifeless: Not that my quick search of the diff finds :P [07:26] lifeless: I blame AnnotatedKnitContent rather than you, though ;) [07:26] spiv: hmm, must have been pulled out with poolies other fix; I do recall not liking that line [07:26] spiv: I think we can delete it [07:26] lifeless: awesome :) [07:27] oh, that reminds me [07:27] that bug is indeed fixed [07:35] lifeless, spiv, some comments sent [07:35] thanks [07:41] + suffix_parents = self._kndx_cache[prefix][0][key[-1]][4] [07:41] That's perhaps even more impressive ;) [07:43] doing reconcile.py [08:03] spiv, i guess you did all of remote.py etc [08:05] poolie: My notes say I've done remote.py, smart/repository.py, branch.py, bundle/serializer/v4.py, bzrdir.py, check.py and fetch.py. And just sent knit.py [08:06] yay way to go [08:16] poolie: oh, and annotate.py, builtins.py and inventory.py (which are all pretty trivial) [08:35] ok will do revisiontree [08:42] poolie: asking now to avoid latency... [08:42] iter_topo_keys - why is it a good time now to fix a bug in existing code ?:P [09:01] lifeless: in that it accepts keys=None? [09:02] let's not add a new api that propagates problems [09:02] Done knitrepo.py [09:02] i suspect you can just delete those lines/words and it will work [09:02] if not it's ok to leave it [09:05] still on revisiontree [09:07] ok reading store/__init__.py [09:08] poolie: I'm fairly sure I can't :P [09:18] ok well don't then [09:19] at least i'm sure it's never given one parameter [09:19] you could do that [09:19] it's possible it's sometimes indirectly given None [09:19] * spiv starts reading tests/* [09:20] lifeless: it's a new function and there's only a handful of callers that do seem to pass a value [09:21] if it fals with that removed i guess it's not worth debugging [09:21] at the moment [09:21] lifeless: about the changes in store/__init__.py, changing _iter_files_recursive [09:21] you changed the way escaping is done there [09:22] ah, np [09:22] the diff context is a bit misleading === RAOF_ is now known as RAOF [09:49] good night [09:58] gnight poolie [10:26] In python if I create a variable holding a value and don't use it I assume it takes up memory until the next gc, is that correct? [10:27] and if I immediately create another variable with the same value then that takes up the same amount of memory again? [10:30] why does bzr blame display the email adresses instread of the names on the lines? [10:31] I'd prefer to see the names there instead and maybe the initial would be even better [10:31] (displaying the initials if the initials on a project do not clash) [10:36] hi Leonidas, I'm not sure, you could file a bug requesting the change. [10:37] james_w: on launchpad? [10:37] Leonidas: yuppers [10:38] https;//bugs.launchpad.net/bzr/+filebug [10:38] almost [10:38] https://bugs.launchpad.net/bzr/+filebug [10:38] james_w: yeah, ok. It's not that important, though :) [10:38] Leonidas: still nice to record these things. [10:39] james_w: ok, writing it now. [10:39] hanks [10:39] thanks [10:40] man, I should get off my ass and go to the shop to get some milk so I can have breakfast [10:50] james_w: when you do 'foo = bar' [10:50] james_w: 'foo' is bound to the result of evaluating 'bar' [10:50] there it is: https://bugs.launchpad.net/bzr/+bug/240633 (lp does not allow me to set 'enhancement' on this) [10:50] Launchpad bug 240633 in bzr "Display names in bzr blame" [Undecided,New] [10:50] breakfast sounds like a great idea. [10:51] james_w: if foo goes out of scope, then in CPython the ref count for whatever foo what bound to is decremented [10:51] Leonidas: done, thanks. [10:51] hi lifeless [10:51] james_w: if there are no cycles this results in it being freed immediately [10:51] james_w: if there are cycles then yes, a gc run is needed to free it [10:51] james_w: if you rebind foo, by doing 'foo = bar2' [10:52] then the old thing referenced by foo has its refcount decremented, see above [10:52] thanks [10:52] so a = foo; b = foo; would increase the chances of a MemoryError? [10:53] this is a long winded way of saying: yes|no to the first question and yes|no to the second [10:53] this is for the patch I just sent if you didn't guess. [10:53] :-) [10:55] lifeless: if you're not heading off then I have a question about the package work. [10:55] shoot [10:55] i"m playing games [10:56] I'm adding handling of native packages. The simple case is just that. [10:56] the difficulty is when a package moves between native and non-native. [10:56] so I'm biased here [10:56] I think non-native -> native should just import the native package as a merge of the packaging and upstream branches. [10:56] I think native packages are a premature optimisation and a bug in dpgs [10:56] *dpkg* [10:57] non-native->native should do a merge commit yes [10:57] and the reverse seems clear to me [10:58] to move from native to non-native there are two branches made, both which derive from the last commit on the native one [10:58] I was leaning that way, I just wanted confirmation that it was sensible, thanks. [10:59] in the new upstream branch the packaging data is deleted [10:59] in the new packaging branch a merge from the new upstream is recorded, and the version metadata is changed [10:59] jam: hi [11:00] yep, that sounds fine, I've just got to think about how to figure out what should happen from the history we have available, it shouldn't be too hard. [11:00] upstream content == tarball [11:01] upstream parent == last native [11:01] packaging content == tarball + diff [11:01] the other question is how, and indeed whether, we should indicate that the package is native at that point. [11:01] packaging parents = [last native, upstream] [11:01] or perhaps the other way around [11:01] well, its not native now, its now non-native :P [11:02] I think that's the right way round. [11:02] I dunno, I'd need to think :P [11:02] yeah, sorry, indicate that the package is native when it is. [11:02] I think just the version number :P [11:02] there's two things that impacts, one is when importing the next version so that we know to use the packaging branch as the upstream branch as well, and the other is when building. [11:03] there should always be a packaging branch, thats the one people get [11:03] if only :-) [11:03] seriously, the version number is the only way to detect a native package AIU [11:04] nope, a native package is a native package, i.e. the .dsc just describes a tarball, not a tarball and diff. [11:04] this can happen at any moment, with any version number. [11:04] e.g. lvm2 just goes native at something.something-1ubuntu4, and then back to non-native at the next revision [11:05] argh [11:05] see, native is a bug [11:05] I think it's a bug in dpkg that you get a native just because you didn't have a correctly named tarball/directory in the parent directory. [11:05] native's _existence_ is a bug [11:05] so totally convinced of this [11:06] well, trying to deal with this makes me dislike any variation, so I'd agree at this point. [11:06] ok [11:06] what builddeb currently does is versions a file in the tree which just says "native = True" [11:06] so detecting native. hmm - think on it during your day, mail me if you don't have a good answer at the end :P [11:06] I can detect native fine. [11:07] 20:01 < james_w> the other question is how, and indeed whether, we should indicate that the package is native at that point. [11:07] so, whatever you mean by ^^^ [11:07] ah, I meant indicate in the branch. [11:07] the .dsc tells you fine, but we don't version that. [11:07] right [11:08] so the dsc represents a 'commit' to the 'debian vcs' [11:08] why don't we preserve it [11:09]