[00:00] lifeless: nothing wrong with pigs! They're really smart [00:00] RickCogley: to run locally ? [00:00] mathrick: sure; I just didn't mean to say that to poolie, complement or not. [00:02] yes, I have some shell and perl scripts which I'm thinking of making available, and I would like to let people download them and use them. But as painlessly as possible on my side. I.e. the latest version is "just there" for people to get. [00:02] hello [00:02] * bialix waves [00:03] hello bialix [00:03] did you actually mean to ping at all? [00:03] you? me? not. lifeless is === tomtom is now known as Guest69613 [00:04] sorry that line was directed to lifeless [00:04] just saying hello to you [00:04] poolie: hi [00:04] I was confused by your comment not to use fix committed [00:04] I've just reread the guidelines and see now that we've changed our process [00:04] yup [00:05] i don't think the distinction is reliable [00:05] cause things may bounce from review etc [00:05] also launchpad may get rid of the distinction [00:05] there is a thread about it [00:06] are we able to search for 'in progress with commit in a branch' though ? [00:06] I know mpt's opinion on this [00:08] ah yes, I thought it was recent [00:09] anyhow, its trivia [00:09] I will adjust [00:10] poolie: I would like to note though, that in progress is also unreliable, as people can flit from one thing to another [00:12] to me 'in progress' ought to mean 'some work has been invested in this' [00:13] therefore all else being equal, there is a higher return in finishing it off [00:13] just how valuable the work is, is a bit hard to capture in an enum [00:13] a dial would be nicec [00:13] I think you have it on the spot there [00:13] to me 'fix committed' is 'nearly there' [00:13] whereas 'in progress' would be 'I think I can' [00:14] if that makes sense [00:16] [I'm not arguing to use F-C, just saying I see the issue and feel frustrated that LP is such a coarse model of how thins work] [00:27] lifeless: I dunno if it was taken -- it probably was, though. I just don't use it as much anymore. Too many other Pengs around. [00:28] lifeless: i desire a similar thing for mps too [00:28] ie to sort them into 'needs lots more work' and 'pp should jfdi' [00:29] * poolie is getting back into bug 456077; it's now working but needs to suppress the warning during upgrade [00:30] Launchpad bug 456077 in bzr/2.0 "MYSQL/BZR P3: bzr doesn't explain it's doing a slow cross-format fetch" [High,In progress] https://launchpad.net/bugs/456077 [00:30] happily the tests now automatically detect that the message is printed there and shouldn't be [00:42] spiv, hi? [00:44] Hey. [00:45] coffee? :) [00:45] poolie: just had one thanks [00:45] Always :) [00:45] so [00:46] we could actually have coffee or catch up, if vincent will let you [00:46] also just wanted to see how you were getting on [00:47] bialix: i think the import tariff stuff is promising [00:47] poolie: about adding gettext to bzr core [00:47] we can check if we're actually as lazy as we want to be [00:47] gettext is loading mo file from disk and parse it [00:47] Hmm. Today or tomorrow? Tomorrow would probably work better for me. [00:48] poolie: so we can make it lazy till we need translations actually [00:49] poolie: maybe some sort of lazy_registry will help [00:49] poolie: I need to think about it [00:49] tomorrow avo I can do [00:49] bialix: for gettext, I think lazy is pointless [00:49] bialix: is this to avoid loading the .mo file, or loading gettext itself? [00:49] bialix: either we use it, and we'll need it on every invocation, or we don't use it and don't need it. [00:49] lifeless: not so fast! [00:50] poolie: to read/parse mo [00:50] lifeless: you don;t need gettext when you run status and it prints no results, right? [00:50] good point [00:50] today bzr has very long startup [00:50] comparing to hg, you know [00:51] bialix: we long stuff even in that case. [00:51] maybe mo parsing won't be significant [00:51] right, we want to pull that down, not add to it [00:51] bialix: and some of what we log is stuff that we'd also output under other circumstances [00:51] so we need to draw a line as far as what is translatted [00:51] i'm not sure that mutter stuff should be [00:51] though that's true there is not a clear distinction between internal and user-facing messages [00:51] yte [00:51] yet* [00:52] no sense to write translated strings to .bzr.log at all [00:52] I agree we want to reduce the startup time; I'm just saying that *if* we start doing translations, we should expect to pay the gettext library load time + mo parsing on 99% of invocations [00:52] well [00:52] you won't be able to understand bug reports :-P [00:52] we should aim to make it fast enough that even if it is loaded, it doesn't kill us [00:52] :) [00:52] poolie: agreed. [00:53] making the test suite pass under LANG=ru would be nice [00:53] i don't think it does now [00:53] my point is simply that lazy only applies usefully when you *can* avoid work [00:53] yep [00:53] a bit like caching [00:53] oh, and, also like caching, doing lazy is itself work. [00:53] lifeless: actually gettext.py has some cache inside [00:54] but it search the disk anyway every time [00:54] it will be slow on windows [00:54] we can just subclass GNUTranslations class and make it lazy to load mo [00:55] then we pay penalty only on each string that should be translated [00:56] I think this is a case for benchmarking [00:56] poolie: btw, about your recent ui changes, we may want to make the note/info metods to write translated strings only to termina; [00:56] and english to .bzr.log [00:56] interesting [00:56] this is very important IMO [00:56] maybe [00:56] i think we need to detangle the log from the ui a bit more [00:56] perhaps logging everything done to the ui makes sense [00:57] but it's still a bit weird atm [00:57] I'm not quite understand [00:57] so [00:58] for example, some tests that want to know about messages to the user look in the equivalent of .bzr.log [00:58] inside the test [00:58] this is a bit weird [00:58] some of the methods in trace.py are to do with logging, and some with user interaction [00:58] this kind of thing [00:58] I don't follow [00:59] we should not run tests with real translations [00:59] rather with zzz pseudo translations, which was invented by igc [00:59] ok [01:00] at the moment some tests fail just because we expect system exceptions to be in english [01:00] gettext is only half of the i18n and l10n [01:00] ah, yes [01:00] OSError stuff [01:00] yep, they are done so inside python itself [01:01] btw, this was changed only in 2.5 [01:01] 2.4 always prints english [01:01] at least for me [01:01] i agree we don't want the tests to know about every possible translation [01:02] also there will be desire to localize dates in bzr log [01:02] I have no idea how to test such things properly [01:03] it will take some creativity [01:03] i'm suggesting as a first step we avoid any accidental dependency on english in the tests [01:03] or just disable it for selftest [01:04] btw, in qbzr we don't enable gettext when we run selftest [01:04] ditto for bzr-explorer [01:56] james_w: if there's something you think would be a much better main focus than merge/resolve, please do speak up [01:57] I think it has its merits [01:57] and is a focus that will bring something to all stakeholders [01:58] k [01:58] i think so too [01:59] if there are particular bugs you can nominate them too at any point [03:04] spiv, i'm sure you understand this but it's not quite clear in your recent mails [03:04] which is that some things like os.read need special handling but can be handled correctly [03:05] whereas some just cannot be done correctly [03:05] perhaps clarifying this is less useful than just fixing the bug though :) [03:21] poolie: right [03:22] poolie: so until_no_eintr is currently correctly handling basically that case for us, read from a pipe [03:23] Unfortunately it seems all the other uses are broken. [03:24] That said, siginterrupt side-steps the whole mess for us quite nicely. [03:24] k [03:24] it may not work on all platforms [03:24] but it may cover enough of them [03:28] Yeah. [03:33] there are only three platforms anyway these days! [03:34] hello all [03:34] mwhudson: hardy, karmic and lucid? [03:34] lol [03:35] poolie: not quite what i meant, but that'll do [03:35] * fullermd looks disgruntled :p [03:36] fullermd: os x is almost like freebsd, right? [03:36] * mwhudson runs away and stops trolling [03:36] mwhudson: contagious huh ;> [03:36] Don't mach me hurt you! [03:36] actually more seriously perhaps we should only run ppas for them [03:37] if that made it any easier [03:37] it's probably not much easier though [03:37] abentley: i guess you're asleep? [03:37] poolie, hi. [03:37] hi [03:37] i was just running tests in a bzr 2.0 branch [03:37] 2230 or so, I'd guess. [03:37] and bzrtools's fail [03:38] because it checks the version when running the command, not when running the tests [03:38] so i was just thinking about this [03:38] poolie: there is a test_selftest test that fails with bzrtools; its not really bzrtools fault though. I'm sure you are seeing more, I'm just mentioning one that I saw this morning. [03:38] it's not really urgent [03:38] this is different [03:39] essentially it runs its tests regardless of bzr version, but they can't possibly pass on 2.0 [03:39] so anyhow [03:39] - it's interesting not to grumble until someone actually uses the command [03:39] kind of cleaner than failing to load [03:39] - iwbni this was done through the standard channels, perhaps [03:40] - iwbni if the tests also skipped, or refused to load, if the commands aren't going to run [03:40] poolie, I see. The version mismatch checking is only done with the commands now, because people complained about bzrtools warning them when they were running irrelevant commands. [03:40] yeah [03:40] it's quite nice actually [03:40] perhaps that should be the standard thing [03:41] obviously it is a bit more difficult for plugins that act through hooks [03:41] I was just about to say that. [03:41] I guess I can add a version check to the bztools test_suite method. [03:42] and return []? [03:43] (semantically not literally) [03:43] anyhow separately, teddybears, i would like a way to cancel some user warnings systematically [03:43] istm it would be clean to give the uifactory a list of ones that have been squelched [03:43] then upgrade() can squelch the cross-format fetch warning for the duration of its run [03:46] poolie, no, I'd probably just emit a warning. I wouldn't want to interfere with actually testing bzrtools. [03:47] one thing that occurs to me [03:47] if you're doing per command version locking [03:47] ok, but at least some of the tests can't possibly pass, because they will examine the bzrlib version then fail [03:47] is that you could use the test suite to tell you when commands break, and only change those commands to be requiring new versions [03:47] so we could say they are expected to fail [03:47] that would be interesting [03:48] at the moment this is the same check across all commands, but applied at invocation time [03:48] but you could do that [03:48] put an attribute on the class; define a base value so most classes don't need to set it, sort of thing. [03:49] right [03:49] it would be interesting to consider how to do this for other things [03:49] in principle you could only complain about bzr-svn when you actually try to use a svn repo [03:49] lifeless, it's an interesting idea, but would it be useful? Most people will not have mismatches, assuming they use packaged versions. [03:50] it may be overkill [03:50] what i would like to get to is to get myself out of the habit of always testing with --no-plugins [03:50] by removing snags when they appear [03:50] abentley: it would make it easier for devs to run with plugins enabled during test runs of core [03:50] abentley: s/would/might/ [03:51] lifeless, so you would disable the tests for a command if there was a version incompatibility? [03:52] abentley: I think gracefully show that the incompatibility is there, rather than hard-fail [03:52] abentley: so to upgrade bzrtools, one would change the version lock, and they would start executing, and failing if there is a problem. [03:52] lifeless, yes, but what about the functions used by those commands? Those typically also have tests, and would not be version-locked. [03:53] abentley: two angles occur to me: How often do they actually break? And perhaps you will get patches. [03:53] lifeless, and it's the functions that are likely to be incompatible. Most of the commands are thin wrappers. [03:54] lifeless, breaks have become pretty unusual, both in commands and in functions. [03:56] so perhaps you could just relax the maximum-version limit? [03:56] in this case i'm actually going back to an earlier version [03:56] so if it's marked incompatible, it probably really is [03:56] which is fine [03:56] but i just want the tests to do something clean [03:56] like report a missing dependency === [1]herbtea is now known as herbtea [03:59] poolie, I'm thinking of relaxing the limit during test runs. In my testing 2.0 passes with bzrtools trunk when I do that. [04:00] poolie, I can relax the minimum-version limit, but I canna predict tha futurre, so changing the maximum-version limit is riskier. [04:01] yeah it's tough to say if it's better to get some false alarms or to get users complaining about weird attributeerrors when it does go out of date [04:03] How about emitting a warning about possible version-mismatch only when an error occurs? [04:04] could be good [04:04] Ideally only on TypeErrors and AttributeErrors, but probably other kinds will happen sometimes. [04:05] It depends on if the breakage is "doesn't even run" or "starts to run then leaves a broken mess" [04:05] If the latter can occur, you really do want to bias towards fail early. [04:10] hi all, I'm a new bazaar user and I'm using explorer and I hope somebody can answer a question for me [04:10] I've created a shared repository with a trunk [04:11] added project directory and files from a new project [04:11] so far so good [04:12] when I click on the Local Changes tab for this repository there is a message " No parent location defined yet", what do I need to do to define the parent location? [04:16] Typically that's automatically set when you first 'bzr pull', or when you create a branch by doing 'bzr branch URL' [04:16] I'm not sure that it makes sense to set it for your case, but if you want to I'd guess that pulling from another location would do it. [04:17] (I'm not sure how to use explorer to do that, sorry) [04:18] poolie, lifeless, I've made the change in the 2.0, 2.1 and trunk series. [04:19] spiv: thanks for the info. Still not 100% clear on the best process for setting up my project for versioning [04:20] abentley: which one? [04:20] spiv: I did a bzr init-repo on a top level dir, then a bzr init on the trunk [04:21] spiv: I then added my proj dir and files to the trunk and did a commit [04:21] (I'm a bit curious about why you thought you should set that location?) [04:21] which location? [04:22] Well, you asked "what do I need to do to define the parent location?", which suggests you thought you should set it. [04:22] yes [04:22] But that's a tangent to your current question, so ignore that if you like. [04:22] I'm getting what appears to be an error message in explorer [04:23] explorer says "No parent location defined yet" [04:23] The init-repo, init, add, then commit sounds good. [04:23] Ok, sounds like something that could be improved in explorer. [04:24] poolie, disabling the version check while commands are running. [04:24] so, this is all local, I have a server that I want to be the main project repository, do I simply copy this top level dir I just created to the server? [04:25] Ah, ok. You can do that, although you'll want to 'bzr remove-tree' on the server afterwards to be tidy. [04:26] ok, just the rev history on the server? [04:26] Or, you can 'bzr init-repo' the location on the server, then 'bzr push' your trunk to server [04:26] Right. [04:26] kewl [04:26] using the locations.conf, is there a way I can specify the parent location of a branch? [04:27] IIRC it's set in the branch's own .bzr/branch/branch.conf, but it might be possible to set it in locations.conf too [04:27] It would be the 'parent_location' option. [04:28] thanks, I'll give that a go and see if that clears the error message in explorer [04:28] thanks for your help spiv :) [04:28] garyyyyyy [04:29] bye all [04:36] * bialix -> zzz === mordred_ is now known as mtaylor [05:29] Question: Is there a good private hosting system for bzr? Eg, a software suite you can install that matches some of the feature sets Github and BitBucket provide? [05:30] Ie, i need it private and not public.. so Launch won't work for me.. sadly. [05:32] you can run launchpad yourself if you like! [05:32] there's bzr-trac, too [05:41] you can also pay for private launchpad hosting [05:41] if you want [05:44] lifeless: !? They're doing that now? [05:44] lifeless: Last i checked, ages ago, they weren't heh. [05:45] Leemp, https://answers.edge.launchpad.net/launchpad/+faq/208 [05:45] says beta but it's in production [05:47] poolie: Ah, still a bit expensive when compared to Git/HG it seems though [05:47] poolie: Or are they offering different plans eventually/now, than they list in that faq [05:48] And i wonder if that's per project.. [05:48] per project [05:48] Ouch :o [05:48] not that it's not per user or per repo [05:49] or per project group, i would imagine [05:49] s/not/note [05:49] depending on what project means, that's competitive with github at least [05:50] bob2: Well it depends on size i suppose. For me though, a personal small developer, $5/mo gets me 5 projects iirc on github. [05:50] 5 repositories [05:50] Separate issue tracking for each one, etc [05:51] bob2: Does launchpad group all the features it provides per repo? or per "project"? .. We're getting cross terms anyway heh. [05:52] bob2: Eg, would i still have 5 separate issue trackings, and whatnot, with launchpad? Or only a single issue tracking, for a single "project"? [05:52] Leemp: i suggest you mail them or ask in #launchpad [05:53] poolie: Righto, conversation slid that way i guess :) [05:53] So on the bzr side of things [05:53] There's a trac mod, and i can run launchpad myself. [06:02] right [06:03] spiv, lifeless, can i have a quick review on the ui_factory side of https://code.edge.launchpad.net/~mbp/bzr/456077-cross-format-fetch/+merge/20041 [06:03] ie adding a show_user_warning(warning_id, **) that can be turned off by a flag [06:07] poolie: looks ok to me [06:08] I'll add a slightly longer review to the proposal :) [06:10] thanks [06:11] having a problem branching from LaunchPad [06:11] k [06:11] This is my error [06:11] bzr: ERROR: Connection closed: Unexpected end of message. Please check connectivity and permissions, and report a bug if problems persist. [06:12] RyNy_: pastebin the full error? [06:12] Sorry, how? [06:13] RyNy_: paste it into http://pastebin.com/, then share the resulting URL here [06:15] Spiv: sorry how do I get more of an error? That's all I see in Terminal. [06:15] This is the command: bzr branch lp:~pantheon-developers/projectmercury/bcfg2 /var/lib/bcfg2 [06:16] RyNy_: interesting, often there's more text than that [06:17] RyNy_: could you paste the most recent section of you ~/.bzr.log, then? [06:17] RyNy_: at a guess your ssh command to connect is not working [06:17] what does 'ssh bazaar.launchpad.net' do? [06:20] spiv: there's not anything more in the log file. [06:21] I also had this error on a different server trying to branch from the same source: [06:21] bzr: ERROR: Not a branch: "bzr+ssh://bazaar.launchpad.net/~pantheon-developers/projectmercury/bcfg2/". [06:22] That's correct. It's not. [06:23] That branch does not exist,. [06:23] Peng: What am I doing wrong? Is it the ~ ? [06:24] Peng: If it is any help here is the URL for the project: https://code.launchpad.net/projectmercury [06:26] RyNy_: The only existing branch in that project is lp:~pantheon-developers/projectmercury/trunk (which you can also refer to with the shorthand lp:projectmercury) [06:28] Peng: Thanks, so the branch doesn't exist. I see that now by looking at the project site at LaunchPad. [06:29] Question: I suppose if it did exist then it would appear on that URL under the branches tab, right? [06:29] Uh-huh. [06:31] Peng: Cool. I do see a bcfg2 file at http://bazaar.launchpad.net/~pantheon-developers/projectmercury/trunk/files. [06:32] Suppose if I were to guess what the correct path should be, it would be http://bazaar.launchpad.net/~pantheon-developers/projectmercury/trunk/files/head%3A/bcfg2/ [06:32] What are you trying to do, exactly? [06:32] Correct path for what? [06:32] Those two URLs are for the Loggerhead web viewer running in bazaar.launchpad.net. [06:33] That's a correct path for viewing the 'bcfg2' directory of the ~pantheon-developers/projectmercury/trunk branch via the web viewer. [06:33] But it's not a valid location to use with 'bzr branch' [06:34] I'm trying to branch from Project Mercury, which is a high performance Drupal installation. I'm following the install directions, but they broke on that branch command. [06:34] "bzr branch lp:projectmercury" [06:34] You can see the install directions at: http://groups.drupal.org/node/50408 [06:34] Where are these instructi -- thanks. :D [06:35] RyNy_: my guess is those instructions are out of date [06:35] RyNy_: I think someone probably renamed (or deleted?) the ~pantheon-developers/projectmercury/bcfg2 branch [06:35] I commented where I got stuck. Search on the page for bzr branch lp:~pantheon-developers/projectmercury/bcfg2 /var/lib/bcfg2 [06:35] spiv, could it be that https://bugs.edge.launchpad.net/bzr/+bug/280608 has already been fixed by you? [06:35] Launchpad bug 280608 in bzr "Stacked-on branch not unlocked when commit_write_group fails on stacked branch" [Medium,In progress] [06:36] poolie: it could be! [06:37] poolie: off the top of my head, I'm not certain. I have certainly touched code in that area, and may well have fixed that. [06:37] poolie: but I couldn't be sure without trying to reproduce, I think. [06:38] ubottu: sorry, what that directed to me? Launchpad bug 280608 [06:38] poolie: I'd guess about 70% likely to have fixed that [06:38] Launchpad bug 280608 in bzr "Stacked-on branch not unlocked when commit_write_group fails on stacked branch" [Medium,In progress] https://launchpad.net/bugs/280608 [06:38] Error: I am only a bot, please don't think I'm intelligent :) [06:38] RyNy_: no, that bug was for me [06:38] RyNy_: right, I see your comments [06:39] RyNy_: the simple fact is that there is currently no lp:~pantheon-developers/projectmercury/bcfg2 branch [06:39] Spiv: ok so I'm not loco, just bad branching instructions? [06:39] RyNy_: Well, out-of-date instructions. [06:39] That helps I suppose. Just have to wait for the instructions to be updated or better. [06:40] Thanks for your help. [06:40] RyNy_: right. I expect they were good once, but have gone stale because that branch has gone [06:40] RyNy_: If I had to guess, [06:40] RyNy_: I would try either using lp:projectmercury branch instead, and if that fails, using the 'bcfg2' inside that branch instead. [06:40] RyNy_: but that's just guesswork :) [06:41] RyNy_: also, the errors you've pasted into that wiki page have the extra text I was looking for before when you first joined this channel. Argh! :) [06:42] (Even though that turned out to be unimportant) [06:42] :) [06:43] Spiv: sorry the wiki comments were from a couple nights ago. If you were to guess the correct bcfg2 path, what would it be? [06:44] RyNy_: well, https://code.launchpad.net/~pantheon-developers/projectmercury/ only shows one branch [06:44] RyNy_: and as you've noticed that branch has a bcfg2 directory (as you can see at the http://bazaar.launchpad.net/~pantheon-developers/projectmercury/trunk/files/head%3A/bcfg2/ link) [06:45] RyNy_: so there aren't many options; probably those instructions either expect that entire branch, or that subdirectory of that branch, or something that isn't there at all. [06:46] Spiv: so is the command I'm looking for bzr branch lp:~pantheon-developers/projectmercury/trunk/bcfg2 /var/lib/bcfg2 [06:47] RyNy_: I don't know [06:47] RyNy_: Actually [06:47] RyNy_: I know it's not that command, because that's not a branch [06:47] RyNy_: (you can't 'bzr branch' a subdirectory of a branch) [06:48] RyNy_: You might need "bzr branch lp:projectmercury" /var/lib/bcfg2 [06:48] er, [06:48] "bzr branch lp:projectmercury /var/lib/bcfg2" [06:49] RyNy_: Ask the Project Mercury people or, failing that, someone else who knows what bcfg2 is. [06:49] Or you might need "bzr branch lp:projectmercury /tmp/projectmercury && cp -a /tmp/projectmercury/bcfg2 /var/lib/bcfg2" to just grab that subdirectory [06:50] Or maybe something else; I really don't know. [06:50] RyNy_: Try spiv's suggestions first, of course, but you should still report to them that their docs are out-of-date. [06:50] Cool, on the branches page of their LaunchPad page that is the only branch. I'll contact them again and see if I can get some help. [06:51] You guys have been very helpful. Thanks! [06:51] You're welcome. [06:51] :) === RickCogley is now known as RickCogley_ [07:21] spiv, can you suggest anything to https://answers.launchpad.net/bzr/+question/102270 ? === RickCogley_ is now known as Rick_Cogley === Rick_Cogley is now known as rickcogley === rickcogley is now known as RCogley === RCogley is now known as RickCogley [07:25] hi all ! [07:25] * fullermd waves at vila. [07:26] fullermd: \o_ [07:26] vila: BTW, fix to paramiko port committed {to,yester}day, so the unadorned port won't break with setuptools. [07:26] Now if only a new version of paramiko would be released that didn't crap on pycrypto... [07:29] fullermd: good to know ! [07:29] I dislike that kind of workaround otherwise as I tend to forget.... what was I speaking about ? [07:29] Eh? Who're you? [07:33] poolie: sure [07:33] poolie: (short answer: post_branch_tip_change + TipChangeRejected) [07:35] I mean, s/post/pre/, of course [07:35] thanks [07:35] * poolie fixed a bug with 7 dupes, that's a nice feeling [07:38] * spiv finishes for the day, time to swim [07:38] me too [07:38] cheerio [07:38] hi vila, bye vila [07:39] poolie: oh, that looks like a nice bug to have fixed! [07:39] I might review that later tonight. [07:39] * spiv -> really gone [07:39] poolie: lol [08:21] lifeless: pong ? [09:23] hi vila [09:24] poolie: Are you back or a poolie's clone ? :D [09:24] really here [09:24] hi, where can i get something like rebase? [09:24] my desktop is a bit sad [09:24]