[00:22] lifeless: hi [00:55] hi igc, spiv, https://bugs.edge.launchpad.net/bzr/+bugs?field.tag=udd [00:55] hi all [00:59] hi [01:01] poolie, hi [01:01] hi there jml! [01:01] poolie, you should unify some accounts: https://www.ohloh.net/search?q=martin+pool [01:02] oh ok [01:02] i did a bunch of them the other week [01:02] jml, when was that stakeholder meeting going to be? [01:03] poolie, 21 June, 1800UTC [01:03] ok [01:37] igc, spiv, https://edge.launchpad.net/bzr/+milestone/2.2.0 [01:51] https://bugs.edge.launchpad.net/bzr/+bugs?field.searchtext=&orderby=-number_of_duplicates&search=Search&field.status:list=NEW&field.status:list=INCOMPLETE&field.status:list=CONFIRMED&field.status:list=TRIAGED&field.status:list=INPROGRESS&field.status:list=FIXCOMMITTED&field.importance:list=HIGH&field.assignee=&field.bug_reporter=&field.omit_dupes=on&field.has_patch=&field.has_no_package= [01:51] blah [01:52] which is high priority bugs by number of dupes [01:53] new bug. LP needs shortly (cryptic) get request fields for sharing searches. Won't Somebody Think Of The IRC Channels!!!! [01:53] shorter. even. [01:58] Why does the Ubuntu package "bzr" depend on "bzrtools". Shouldn't that be "recommends" or something? === AfC1 is now known as AfC [02:00] AfC: it doesn't depend on bzrtools [02:01] AfC: it's in the Recommends in the original debian package and as far as I can tell that hasn't been changed in ubuntu [02:01] Oh. Have I done something wrong, then? I just did "apt-get install bzr" on a (very) fresh system and it dragged in bzrtools. I was a bit surprised by that [02:02] i think apt is configured to install recommends by default [02:02] AfC: apt-get installs Recommends by default these days [02:02] there's a way to change this- [02:02] ew [02:02] jelmer do you think https://bugs.edge.launchpad.net/bzr/+bug/481748 is now ready to implement based on the list discussion about revision specs in urls? [02:02] Launchpad bug 481748 in bzr-builder "revspecs in recipes should be part of the URL (affected: 1, heat: 6)" [Low,Triaged] [02:04] hm [02:04] poolie: yeah, I think so. Though that'll also need some generic work on supporting extra arguments in URLs [02:04] it's a bit hard to find [02:04] AfC: aptitude -R will ignore recommends [02:04] I'm not sure if -R will work for apt-get [02:09] jelmer: thanks, will try that [02:09] brb [02:15] jelmer: hi? [02:16] jelmer: I'm back off out in a minute, perhaps more content than ping, and I'll reply when I get back :) [02:17] afc, you can set something in /etc if you want this permanently [02:17] cheerio lifeless [06:00] hi poolie [06:00] poolie: I think I have the same hardware issue you had [06:01] hi there! [06:01] loose cpu heatsink [06:01] ah, really? [06:01] my games machine is powering off frequently [06:01] after yours was posted across the tasman? [06:01] yes [06:01] :( [06:01] erk [06:01] it was -very- occasionally doing it first [06:01] and I've inspected the CPU heatsink, and one corner screw is loosish [06:01] i'm still waiting for the 2GB DDR3 to come in so i can get it rebuilt [06:01] mm mine were too [06:01] its a twist-lock thing [06:02] and i just kind of shrugged [06:02] right [06:02] but that one won't lock firmly [06:02] exactly [06:02] yeah [06:02] I'm going to take a little time tomorrow [06:02] and drop this in to get addressed [06:02] also [06:02] heh i just found in my office the other day one of the special torx keys to tighten an ia64 heat sink [06:02] we've put an offer in on a house [06:02] _that_ won't come loose :) [06:02] congrats [06:03] Ooh :) [06:03] so I need to do a little run around dance for that with lawyers, inspectors etc [06:03] lifeless: Nice! [06:03] mm [06:03] so we had a look here into https://bugs.edge.launchpad.net/bzr/+bug/582157 [06:03] Launchpad bug 582157 in Bazaar "pull from launchpad is slow (affected: 1, heat: 6)" [High,In progress] [06:03] without really reproducing it [06:03] poolie: long story short - I'll be around on basically .au hours tomorow [06:03] istm there are two classes of problems here [06:04] ah you're not working so i won't bother you with it [06:04] poolie: cool, thank you for pulling on the string [06:04] ok, np [06:04] no, no bother [06:04] its not like Canonical has traditional boundaries [06:04] ok so the two classes are: things where we know we're going slower than we should; and secondly things where we are unexpectedly slow [06:04] this bug would be in the second class [06:05] we have some ideas for shots in the dark that are probably useful anyhow, and for improving debuggability/supportability [06:05] I can't wait for steams Linux port. [06:05] one thing I thought of doing [06:05] as a fairly immediately useful thing [06:05] after that, i'm going to put this back to incomplete [06:05] was to make a per-invocation server side log [06:06] mm [06:06] so the ideas were [06:06] 1- use a socketpair to the ssh client, not a pipe [06:06] that is, $ISO16whatever-$PID.log in ~/.local/bzr/ or some such [06:06] - not proven to fix this but a generally good idea; may alleviate poor blocking behaviour [06:06] ok [06:06] that's good too [06:07] and then get that cherrypicked into LP production, add -Dhpss on the server side and get the logs synced every 5 minutes or so [06:07] 2- when TERM=spiv, server sends its hpss log over stderr so you can see on the client where it thinks it's spending time [06:07] so we could see chunking, groupcompress stats etc [06:07] 3- log into that how much cpu time we spend per request [06:07] right [06:07] this would be quicker than getting it off lp via losas etc [06:07] I like the idea of getting more data [06:07] I think we should aim for getting more data all the time [06:08] 4- print a few more stats at the end: number of rpcs, number of ~mtu and < so that when someone says 'man it was slow this morning', we can see why [06:08] that doesn't conflict with getting more in an immediate mode like you are describing [06:08] right [06:10] and i think that's it [06:10] I agree that that bug should be used for 'lp is slower than bzr+ssh in general' [06:11] I'm not sure where 'bzr+ssh around the world is slower than bzr+ssh locally' should go, if anywhere. [06:11] [one theory about bzr+ssh performance is window choking on the tcp links - I was doing tcptrace analysis with spm a couple weeks back on this] [06:11] ah [06:11] that's possible [06:12] on spm's recommendation I filed an RT ticket to increase the buffer limits on chokecherry or whatever the server is [06:12] crowberry? [06:12] its in the lp queue if you want to dig it up [06:12] i wish the machine list page was up to date [06:12] $suitablemachinename [06:12] and did you actually find anything from tcptrace? [06:12] i was just wondering if there was a machine like that [06:12] was something a little suspicious, then PPing [06:12] then looming [06:13] that said, changing on crowberry live isn't the best place to test theories [06:13] using a socketpair may help there [06:13] right [06:13] so we'll want to repurpose tungsten probably [06:13] to be a testbed [06:13] something tcp related would be compatible with different people observing very different results [06:13] I'm not sure why a socketpair would help [06:14] i think that they allow partial reads while a pipe does not [06:14] interesting [06:14] imbw [06:15] oh the other possibility is that it's load-related on the server [06:15] holy cow steam installs fast on SSD [06:15] yes, load is a big concern [06:15] under windows? [06:15] cedega [06:16] more detailed logs would let us ascertain the concurrent bzr processes, and their activity, after the fact [06:33] lifeless: What were your thoughts as bzr's TestCase as a fixture? [06:33] *blink* [06:36] StevenK: what do you mean [06:38] lifeless: Context is your comment on this MP: https://code.edge.launchpad.net/~stevenk/launchpad/poppy-sftp-test-isolation/+merge/26717 === radoe_ is now known as radoe [07:58] hi all [08:03] hey vila! [08:04] spm: _o/ [08:42] what is the simplest way to get a time zone aware datetime object for the revision time? [08:42] a revision has a timestamp and timezone [08:42] is there a simple way? [08:45] thumper: My memory may be a bit dusty, but I think I recall that the timezone and datetime should be supplied both or none of them [08:45] thumper: so, short answer: no [08:47] is the timestamp of the revision in UTC or local time? [08:49] gee, let me check, I'd say UTC, but I'm sure there are tests for that [08:58] thumper: I was wrong, it's in local time (AFAICS) [08:58] vila: I think I'm going to agree with your first answer [08:58] vila: it is UTC [08:59] if I go: datetime.utcfromtimestamp(r.timestamp) it is right [08:59] where r is a revision object [08:59] thumper: you checked that with a timezone != 0 ? [08:59] I'm not sure why a timezone is also recorded [08:59] r.timezone is 43200 [09:00] hang on [09:01] it's a shame it's not better documented anyway :-/ [09:02] * thumper is a little frustrated [09:02] it seems to be UTC [09:02] even though a timezone is recorded [09:06] hmm, so I looked at the wrong place and we may have bugs there.. [09:07] but looking at how log process that, yes, it seems to be UTC [09:56] hi [09:56] so, I have 2 branches who have diverged for some unclear reason. [09:56] nor merge or dif --old shows anythinig useful, [09:57] besides that my current branch is all extra to the push location - which was not like this before my laptop commit. [09:57] How to solve this? [10:03] sivang: have you tried "bzr missing" ? [10:03] that should tell you the revisions that are present in one branch but missing in the other [10:07] vila: when are you arriving in cambridge? [10:08] mwhudson: tomorrow, around ~14h30 if all goes well [10:08] vila: ok [10:28] jelmer: I have, it suddenly shows me that all of the commits on the local branch I am working on are extras [10:30] mgz: thanks for the bzr-grep patches. i am going through no-match-fast path right now. [10:41] sivang: that certainly explains why it's giving you that error [10:49] jelmer: right, but how is that that suddenly all those revision are extra? [10:50] jelmer: this wasn't so a day before. [10:55] jelmer: so it seems the only way to solve this is to rebranch [10:57] sivang: Have you perhaps rebase your branch or something like that? [11:01] jelmer: not that I know of. [11:01] jelmer: This should be explicit enough for me to remember, from a bzr user POV [11:01] :) [11:04] jelmer: I'm rebranching, this takes too long to resolve with no apparent stuff to merg [11:04] jelmer: e.g. merge says there's nothing to do [12:55] ls [13:15] parthm: are you there? [13:28] C-S: hi [14:16] in .bzr/repository/indices I have many duplicate files. Can I unlink or hard link them all? [14:16] and not break anything? [15:16] feckser: This should not be the case [15:17] feckser: I suggest pastebinning the output of 'ls -lR .bzr/repository/' so people here can understand the situation better [15:21] maxb: what should not be the case? There should not be binary duplicate indices? [15:21] It's pretty unexpected, yes [15:31] http://www.pastey.net/137418-3kta [15:54] feckser: What? All your concern is about 4 60-byte files? [15:54] stop worrying [15:54] maxb: they obscure the duplicate list. [15:55] They make it harder to process removal of duplicates. [15:55] huh?! [15:55] When I perform a search for duplicates they are always returned. [15:55] So? Why does this bother you? [15:56] It makes the process of finding and removing unwanted duplicates harder [15:57] and that was only an example. There are more in other bzr repositories. [16:01] Unless you can find duplicates of substantial size, I feel this is a non-issue [16:23] maxb: it is not just about finding duplicates in bzr repositories, it is about finding them all my files. [16:24] some of the directories under ~ are bzr repositories. [16:24] Make your dupefinder ignore .bzr then [16:24] inore list [16:24] it has no ignore list [16:26] Personally, I see no problem with Bazaar happening to produce identical byte content in a few small files as an implementation detail [16:26] I did not say it was a Bazaar problem. I asked whether I can delete them without harm. [16:26] Answer: no [16:27] Can I hard link them without harm? [16:28] The duplicate finder (fdupes) smartly considers multiple links to same file as not duplicates. === IslandUsurper is now known as IslandUsurperAFK === beuno is now known as beuno-lunch [18:01] feckser: don't ever hardlink these files, they contain the signatures (and appear to be empty in your case). If you start signing your commits... they won't be empty anymore [18:02] vila: so as long as I don't sign, they can be hard linked or removed? [18:03] feckser: no, their presence is mandatory [18:03] vila: hard linked? [18:03] feckser: if you hardlink them, you will be doomed the day someone in the project sign a commit [18:03] it really sounds like you want fdupes to have an exclusions list :) [18:04] feckser: besides, new ones will be created when the repo is repacked === deryck is now known as deryck[lunch] === IslandUsurperAFK is now known as IslandUsurper === beuno-lunch is now known as beuno === deryck[lunch] is now known as deryck [18:55] hi [18:55] i'm having more issues with obtaining the directory of a branch [18:56] this result.branch.base isn't cutting it anymore [18:56] because "filtered-154314860:///bzr/~mysticgalaxies/citrine-blender/" is not a file path [18:56] at least not to me it isn't [18:57] hm, a lot of stuff is undocumented [18:57] i can't even find Branch.base in the docs [21:09] meoblast001: branch.base is in the api docs [21:09] pydoc bzrlib.branch [21:09] ... [21:09] :ivar base: ... [21:09] meoblast001: that filtered: prefix is the soft chroot I was telling you about [21:10] meoblast001: and why taking a suffix is needed, or unwrapping the filtering [21:10] meoblast001: or, taking a config option from the branch (which I think is preferrable anyway) [21:10] meoblast001: but you'll know what works best for your needs [21:17] lifeless: oh, why wasn't it in these docs http://people.canonical.com/~mwh/bzrlibapi/bzrlib.branch.BzrBranch7.html [21:17] hm, those seem to be personal docs [21:17] nvm [21:18] http://people.canonical.com/~mwh/bzrlibapi/bzrlib.branch.Branch.html [21:18] ah [21:19] looks like a bug in pydoctor [21:19] config option? [21:19] its showing inherited methods [21:19] but not inherited variables [21:19] attributes I mean [21:19] meoblast001: config option - setting a key in branch.conf that you can look for [21:21] lifeless: does Bazaar call plugins with .bzr as the working directory or is there something i need to use to set and get keys in branch.conf? [21:21] branch.get_config() [21:21] hm, undocumented [21:21] its a decorator [21:22] decorator? [21:22] I think [21:22] ah no, it is genuinely undoced, I'll fix [21:23] lifeless: does that return a bzrlbi.config.Config? [21:23] bzrlib* [21:25] bzrlib.config.BranchConfig [21:25] which has get_config, set_config etc apis [21:27] lifeless: i seem to have a limited array of options [21:27] i see no get_config or set_config [21:27] i see get_user_option [21:27] but not even a set_user_option [21:28] http://people.canonical.com/~mwh/bzrlibapi/bzrlib.config.BranchConfig.html [21:28] there is a set_user_option [21:28] and get_user_option [21:29] ah, at top [21:29] as well as typed methods for email, signature checking, aliases and so on [21:29] lifeless: so i want to use those, correct? [21:29] in your plugin you want to use get_user_option [21:29] you can just set the value in branch.conf with a text editor [21:29] result.branch.get_config().get_user_option ('blahblahblah') [21:30] yep [21:30] since the return value of that get_config() is still sort of ambiguous [21:30] ok, thanks [21:31] generally speaking that will return None if the option isn't set [21:41] ah, a lifeless. [21:41] did you suggest I look at testrepository for my traceback matcher thing? [21:42] yes [21:42] testrepository.tests.matchers.MatchesException [21:42] needs a little more suger [21:42] sugar [21:43] will grab and look at. [21:44] hm, yeah, that's looking at exc_info [21:44] possibly it should be built via composed subclass/equality style matches for each element of the tuple [21:44] which isn't a bad thing in general, but in this case we care about how the strings actually get passed through to the final stream [21:46] having something that takes an input of extract_tb style tuples might be okay though [21:48] lifeless: ok, thanks... and i should have the config option set manually? [21:48] yes [21:50] lifeless: how goes the househunt? [21:50] great [21:51] cool [22:57] So, if you have a branch, stacked on another branch, and the base branch has been upgraded to 2a but the stacked one is still 1.x .... can you recover? [22:58] yes [22:58] upgrade the stacked one [23:10] lifeless: testr is pretty cool, thanks [23:10] james_w: thanks! [23:10] I'm glad you like it [23:11] lifeless: I'd prefer different output, like a big green light when all the tests pass [23:12] james_w: I'd be delighted to incorporate patches [23:12] if you wanted to include an arduino control module to drive a traffic light, we could even include that [23:12] heh [23:12] did you see that? [23:13] I saw one that did lava lamps [23:13] I ported soupmatchers to use the discovery stuff today, makes for a pretty nice setup. [23:13] awesome [23:13] could you comment on the testtools bug about how that hangs together ? [23:14] I find the output on failure a little unpleasant, but can live with it [23:14] or in some fashion write it up? That would be _most_ useful [23:14] sure [23:15] lifeless: if you could review the merge proposal that would be great [23:17] which one ? [23:17] bah [23:17] which one ? [23:19] lifeless: https://code.edge.launchpad.net/~james-w/subunit/discovery/+merge/26893 [23:19] thanks! [23:19] I shall peruse [23:20] james_w: ah, I see [23:21] lifeless: feel free to suggest alternative implementation strategies, it was more of an exploratory hack, but it works :-) [23:21] so TestProgram can take the name of a callable [23:21] or callables [23:22] one way to do discover would be: [23:22] make a series of callables, assign them to global names [23:23] globals()[thunkN] = lambda:loader.discover(arg, pattern=options.discover_pattern) [23:23] or something like that [23:23] I don't think what you've done is all that ugly [23:23] have a play, see what you think [23:23] if you decide that the current stuff is better [23:23] then lets ditch TestProgram entirely [23:24] so that we don't have two different paths. [23:24] ideally though, lets get a fixed TestProgram class in that file, which we can use appropriately, and submit a patch to python to make the stdlib one sufficient. [23:25] ah, you're saying that TestProgram should be able to take a list of callables, rather than it being a current feature? [23:31] no [23:31] it currently takes a list of names [23:31] and does introspection [23:32] see the testr.conf for testrepository, for instance [23:32] (testrepository.tests.test_suite) [23:32] oh bleh [23:32] yes [23:32] I'm saying that if we need to change TestProgram to accept callables as well as names [23:32] or some such [23:32] then we should [23:32] or if we need to separate the concerns more [23:32] then we should do that [23:34] james_w: to put it most broadly: [23:34] - subunit.run should be a trivial change to testtools.run [23:35] - testtools.run should be a trivial wrapper for python's TestProgram [23:35] so lets make things better up the stack, and where we have to wait for patches to be accepted / propogate to old versions etc, we should have a subclass that implements what our patch does, with a 'XXX: delete when python2.7 is the oldest version we support', or similar. [23:37] right [23:37] I don't see TestProgram taking a list of callables right now [23:37] agreed [23:37] it does take a list *of the names of callables* [23:37] right [23:38] but serialising the discovered tests back to that seems wrong [23:38] so here's the review - please change subunit to use testtools more, it hasn't needed to for run as it was sufficient in the stdlib [23:38] and do the discovery work in testtools [23:38] and in testtools; either: [23:38] - subclass TestProgram and make it more suitable [23:39] - use a thunk to pass to TestProgram [23:39] james_w: it wouldn't be serialising [23:39] james_w: it would just call indirect the call to discover; I don't have a preference though [23:39] should we push --discover in to TestProgram? [23:40] ultimately, yes. In fact 2.7 may do that already [23:40] so it may be a 'copy from python' case [23:40] as far as licencing goes [23:40] testtools is license compatible with python, deliberately. [23:40] so is subunit. [23:40] just need to update the list of external copyright holders in the docs. [23:40] it doesn't yet, I was just checking that [23:41] oh, hang on [23:41] I'm sure 2.7 supports discovery in some fashion [23:41] it does [23:41] COPYING has the external copyright refs [23:41] but not --discover [23:41] it would be "python -m testtools.run discover" [23:45] thats ... interesting [23:50] uhm [23:51] I don't have a strong opinion here, if it works +1. If its maintainable +1. If its the same as python has ended up upstream thats nice; if you think its nicer to be different, thats ok too. [23:51] Just, where we are different, put patches forwardds. [23:51] if you think we should try it differently, and decide later what is nicest, thats fine too - we can put a patch in once we are convinced one way or the other. [23:52] back shortly, popping down to the bank.