[01:37] mwhudson: thanks for the pointer to iolaus [01:38] lifeless: sounds similar to some of the ideas you were telling me about: http://github.com/droundy/iolaus [01:38] * james_w crashes [01:43] \o/ it's in haskell [01:46] james_w: yes, there are similarities [01:47] igc, re bug 524177 [01:47] Launchpad bug 524177 in bzr "Doc rebuilds are deleting chm files" [Undecided,New] https://launchpad.net/bugs/524177 [01:47] is that some kind of problem with the scripts on escudero? [01:48] also, when you file bugs, can you please triage them too? [01:48] no point making someone else reopen the bug to do it [01:55] spiv, maybe at the end of the eintr thread we should add something about it to the developer guide [01:56] poolie: yeah [01:56] poolie: and, assuming we keep until_no_eintr (which I think we need to for reading from pipes at least), put a very clear warning in its docstring. [01:56] Probably with a pointer to full treatment in the developer guide. [01:57] hm [01:58] so until_no_eintr is a bit dangerous because it's highly likely to be needed on functions that can return partial results [01:58] and you need to loop separately on them too [01:58] perhaps [01:58] i suppose it's not actively dangerous, just often not sufficient [01:58] so a patch that describes the way these things should be handled might be a good way to get to agreement with gzlist [01:58] just an idea [01:58] also [01:59] we could add a test_source for known broken apis [02:02] Right, so until_no_eintr is right for things that are very close to the underlying syscall, or at least std libc, interface. [02:03] But as soon as you have any layers between that and until_no_eintr it's probably wrong. [02:03] And you either need to push the eintr handling down into a lower layer, or use a different API entirely. [02:04] I think I am converging on agreement with gzlist. [02:05] There was a disconnect because he wasn't aware of the pipe.read issue being a valid and appropriate use of until_no_eintr, so he was of course sure the right thing was to rip out until_no_eintr, whereas I was of course sure we still wanted it :) [02:05] I'm not aware of a better alternative for the pipe.read than just wrapping it in until_no_eintr, but if one comes up we can evaluate that. [02:11] freetown2: hmm, 350mb apt-get update [02:11] erem grade. [02:19] lifeless: ? [02:19] poolie: lucid moving fast === _thumper_ is now known as thumper [03:37] poolie: I am going through your review comment https://code.launchpad.net/~parthm/bzr/2.0_376388_dot_bazaar_ownership/+merge/19593 [03:37] Does http://pastebin.com/m4d62c257 seem like a reasonable approach in osutils? [03:38] I also plan to add osutils.open that optionally takes ownership_src arg. This can then be used succintly for creating files like log and conf. [03:53] parthm: that looks pretty reasonable [03:55] parthm: raise just one warning when it fails, and use trace.warning not warnings.warning [03:55] OK. Thanks. [03:57] I saw your comment regarding making this patch for trunk. That sounds fine to me. I am thinking that for now I will continue working on the same branch so that review comments are not lost. Then it can be merged up? [03:58] yep [03:59] One more question, is there a doc that lists the dependencies we need to have in order to hack bzr? I have been installing packages seperately one at a time as I hit issues (pyrex, testtools, pyftpdlib, subunit etc.). [03:59] Due to time some tests also get skipped. [04:00] is this on ubuntu? [04:00] the easiest way is to say 'apt-get build-deb bzr' [04:02] Theoretically the INSTALL file should list the dependencies, but that part of it seems to be out of date. [04:04] Yes. Its ubuntu. build-deb sounds good. Thanks. [04:05] Yes. INSTALL does look out of date :) [04:50] parthm: what do you think of http://pastebin.ubuntu.com/379525/ [04:50] are there any other questions it should answer? [05:00] poolie: This certainly answers most of my. I wasn't aware of the appendpath trick. Maybe we can have pointers for getting further help (irc, mailing list). Specifically I faced a problem getting into irc (i am new to it) as it required a registered nick, I kept getting "cannot send" messages before I googled and realized what was happening. [05:00] yeah that kind of sucks actually [05:00] i'll add some pointers [05:01] Maybe somewhere a tip can be put in regarding avoiding "resubmit merge request" as comments are lost. I made that mistake. [05:02] The doc looks good. [05:07] I seem to have hit upon an interesting situation. http://pastebin.ubuntu.com/379534/ Not sure what I did (maybe ^C of some test?), I ended up with some unknown file/dir which don't exist on disk. How do I get rid of it? [05:11] parthm: that's pretty weird. [05:14] lifeless: did you or anyone already register #bzr with freenode? [05:18] poolie: yes years ago [05:19] did you register the group too? [05:20] don't know what you mean [05:20] ok, that works [05:20] I've just added you to the channel access list though [05:20] http://freenode.net/group_registration.shtml#groupcontacts [05:21] what does that mode do ? [05:22] allows non-registered users to talk [05:22] isn't it obvious? ;-) [05:22] Nice :) [05:22] poolie: no, its not :P [05:23] poolie: you might like to drop op though; and tell chanserv the mode bits you want, otherwise netsplits can confuse things. === ubott2 is now known as ubottu [05:23] poolie: [dropping op because freenode frown on folk sitting with op on for extended durations, telling chanserv so that it sticks properly] [05:24] ok [05:24] > freenode frown on folk sitting with op on for extended durations [05:24] why? [05:25] something about community spirit; I don't recall really. [05:25] http://freenode.net/using_the_network.shtml [05:25] Use the chanserv "op" command to obtain channel operator status only when needed. This will help to keep your channel temperature low and reduce conflicts. [05:25] [05:25] poolie: I plan to send a new merge request for 2.0_376388_dot_bazaar_ownership against the trunk. Its seems overrideAttr are not available in 2.0. I will be using them for writing the tests as you suggested. [05:26] hm [05:26] poolie: /msg chanserv access #bzr list -- thats what I looked at when you asked, and you weren't there so I did [05:26] yeah, i see [05:26] access #bzr add poolie [05:26] i think all the core devs should have access [05:26] I don't know if that makes you fully-capable; I don't know enough to tell. [05:27] I suggest you try adding e.g. jam [05:27] 'flags #bzr' gives more linenoise [05:27] if you can't I'll dig deeper to find out how to make you as-capable as me [05:27] hang on [05:28] so you have also sRA bits [05:28] I don't know what they mean [05:28] and f [05:28] I didn't want to randomly type stuff in until I check [05:29] are you able to add jam ? [05:29] oh go on :-P [05:29] +f - Enables modification of channel access lists. [05:29] +F - Grants full founder access. [05:29] send chanserv help flags [05:29] so i think i can't grant access, but i'll try [05:30] yeah, i can't grant rights [05:30] so i think i need you to do [05:31] flags #bzr poolie +* [05:31] poolie: you look the same as me now [05:31] ew [05:31] sweet, thanks [05:32] poolie, lifeless: You guys should get the +F flag from Christel (who is a freenode staff member IIRC). [05:32] cody-somerville: thanks for helping out [05:33] cody-somerville: by asking christel, i suppose? [05:33] * cody-somerville nods. [05:33] lifeless, Is that a polite way of telling me to bugger off? :=) [05:33] seems away atm [05:33] no, seriously, thanks [05:34] If you guys register yourself as a group, you can get your own cloaks and then you grant anyone with that cloak certain privileges (ie. ops). [05:34] jelmer: out of intrest, does that subvertpy test need disabling in testing/unstable or only stable? [05:34] cody-somerville: right, i was just asking about that too [05:34] i wonder if we should register our own group or be subsidiary to canonical [05:34] cody-somerville: no, its me saying thanks [05:34] istr some mail about this [05:34] cody-somerville: I so rarely look at IRC modes it all pages out. [05:35] poolie: I think we should be like ubuntu, or perhaps subsidiary to ubuntu - more than staff can help. [05:35] cody-somerville: besides which, I have no politeness chip. [05:35] their policy seems to prefer a company [05:36] whose? [05:37] freenode's policy [05:37] hmm, odd. [05:37] ok, so it's filed now [05:37] we'll see [05:37] poolie, Ubuntu is a registered group. [05:37] i'm glad that's sorted [05:37] ok, i tried to register Bazaar c/o Canonical [05:37] poolie, You have a cloak of canonical/launchpad/poolie [05:38] and i granted flags to some core devs [05:38] cody-somerville: are cloaks like bitmasks ? [05:38] lifeless, They mask your hostname [05:38] yes I know that [05:38] but their value [05:38] can you have e.g. canonical/launchpad/ubuntu/fsf/bazaar/lifeless [05:39] oh, add debian [05:39] i think they are hierarchical [05:39] hmm thats a bit annoying [05:39] community membership is more setlike [05:39] one propeller beanie at a time please [05:39] or can you choose amongst many cloaks you have permission to use ? [05:40] (at login time I mean) [05:40] You can only have one but you can combine them - although its a bit awkward. [05:41] Some people have: pdcp/supporter/ubuntu/member/$nick [05:41] and what not. [05:42] k [05:42] so more to the point is """[+o] attracts the attention of participants who react negatively to authority. Have your nick added to the channel access list and op yourself only when needed. """ [05:43] http://web.media.mit.edu/~marcelo/cornucopia/ [05:43] poolie: OH, LOOK AT *YOU*, MISTER IMPORANT! [05:43] see [05:43] * mneptok pouts in the corner [05:43] * cody-somerville recommends a script created by Dennis Kaarsemaker, http://www.kaarsemaker.net/downloads/code/chanserv.py [05:44] I am getting two failures while running blackbox selftest on unmodified trunk http://pastebin.ubuntu.com/379546/ . Is this expected? [05:44] IIRC, i had a /canonical/staff Freenode cloak when i was an employee [05:44] cody-somerville: sadly its for xchat :P [05:45] parthm: no, because pqm selftests trunk on every commit [05:46] i think "canonical/staff/bzr" would look sexy on poolie [05:46] that's pretty strange [05:46] i pick up my wizard staff and cloak [05:46] parthm: hmm, both in "expectFailure" [05:46] while lifeless should get canonical/staff/i/get/around/more/than/a/monaco/hooker [05:47] parthm: what version of testtools do you have? [05:47] k [05:47] so that's done [05:47] mneptok: how much does a monaco hooker get around? [05:47] now i don't need to document [05:47] spiv: testtools-0.9.2. I installed it locally from a downloaded tarball. [05:47] ok, i think this ^^ is exactly what i was reading about inappropriate behaviour :) [05:47] lifeless: my memories of that time in my life are kinda hazy ... [05:48] wait ... was that out loud? [05:48] but presumably in their maserati [05:48] parthm: hmm, that's what I have (well, a deb saying 0.9.2-1, from the bzr PPA IIRC) [05:48] spiv: doesn't look like testtools to me ? [05:49] its interesting that some extensions are not built [05:49] parthm: try running 'make' [05:50] * parthm running tests again after make [05:50] parthm, lifeless: FWIW, trunk with and without extensions passes those tests for me, as known_failure [05:51] ah [05:51] could be testtools then, but that version should be fine [05:51] I see the same failures even after make. :( [05:51] parthm: are you sure that version of testtools is being loaded? [05:52] parthm: what if you don't use --parallel=fork? [05:52] (and what version of subunit?) [05:52] parthm: you can vote on https://code.edge.launchpad.net/~mbp/bzr/doc/+merge/19682 if you want; I put in your suggestions [05:52] oh, I didn't realise subunit was in there. Smells like an old subunit perhaps. [05:52] lifeless: neither did I at first, but parthm sensibly included the command line in the paste :) [05:52] lifeless: Yes. I see the correct path in the error log. [05:53] subunit is 0.0.2 from packages [05:54] poolie: as a potential user, you might like https://code.edge.launchpad.net/~lifeless/testresources/bug-522338/+merge/19684 [05:54] parthm: thats pretty old [05:54] parthm: what platform are you on? [05:54] poolie: will do. thanks. [05:55] lifeless: I am using ubuntu 9.10 [05:55] will run again w/o fork. [05:57] parthm: you might want to grab the subunit PPA, it has newer subunit, testtools all packaged [05:58] maybe we should add a version assertion to bzr? [05:58] poolie: it doesn't turn up all that often. We can if you like [05:58] maybe next time [06:00] yep. subunit was the problem. all tests pass without fork. will install the latest ppa. [06:01] i agree with poolie, it would be good to have a version check. for someone new to bzr codebase its very helpful if the error message clearly indicates this. [06:01] thanks for the help [06:31] got to go. have a nice day! [06:38] james_w: bzr-builddeb from testing fails to build on stable ( http://paste.debian.net/60457/ ). Would this be a dependencies issue, or is the setup.py file actually broken? [06:39] Hmm. bzr missing defaults to 80 cols with no terminal on stdout? [06:39] that seems nasty. [06:40] quicksilver: it defaults to your terminfo [06:40] and if there is no terminal, we use something that will often be sensible [06:41] Kamping_Kaiser: possibly a parser change in rst [06:41] I'd hoped --line would default to infinitely long lines [06:41] (if there was no terminal) [06:41] we did that for about 3 days [06:41] after gigabytes of output in test runs it got changed [06:41] ok :) [06:42] I can see your argument, perhaps file a bug - we may have solved our issue the wrong way. [06:42] lifeless: rst? [06:42] you could mention that other tools defaults to no-apparent-limit (if they do) [06:42] Kamping_Kaiser: ReST - restructured text [06:42] oh [06:43] the language README is written ni [06:43] NI! [06:43] lifeless: would that be bzr's rest parser? I'll check the changelog incase theres some info [06:43] no [06:43] python module [06:43] ok [06:45] lifeless: what I'm actually doing is writing a command line tool to analyse a bunch of repos with --missing and deduce some things about their topology. [06:45] lifeless: like, which ones have already been merged into "mainline", and which of the non-merged ones shared common parents, etc [06:46] lifeless: are you aware of any prior art? [06:51] quicksilver: bzr removable [06:53] lifeless: looks like its a stray space. whats the preferred way of submitting trivial changes? patch? bzr branch? [06:57] lifeless: thanks. Interesting. I had slightly more ambitious plans but that's definitely the basic function. [07:01] (used a patch :)) [07:24] Kamping_Kaiser: 'whatever works' [07:50] poolie: the apt-cache policy bug is committed to apt trunk [07:51] great [07:55] very small patch for being open for 5 years :( [07:55] many are [07:55] i'd like to do a scatterchart of (open_time,close_time) [08:00] hi .. anyone can help me with this bug 524269 [08:00] Launchpad bug 524269 in bzr "cant bzr update in development trunk" [Undecided,New] https://launchpad.net/bugs/524269 [08:03] Hi [08:03] http://paste.ubuntu.com/379585/ [08:04] bzr branch svn+ssh://... fails on Windows. [08:07] I think it isn't a bug of bzr-svn. [08:14] lifeless: thanks for changing the description .. so confirm its a bugs ? [08:17] ejat: doubt it [08:18] ejat: I suspect you're missing ca-certificates or something [08:19] I read strace. All opened fd is closed correctly. [08:19] I can't find a suspect. [08:20] naoki_: hello! [08:20] naoki_: disable your virus scanner [08:20] the first error looks like one we fixed recently [08:21] lifeless: you're probably right but that's such a bad thing to have to say :-/ [08:21] naoki_: its not hooking in at a low enough level, so it is interfering with normal system calls [08:21] poolie: it is; I blame microsoft. [08:23] lifeless: sorry .. after upgrade .. im missing the bzr-svn .. after reinstall bzr-svn .. working fine [08:26] lifeless: can i change the status to invalid ? [08:27] I hope so [08:29] lifeless: i mean other apps must hit this [08:29] writing a file then reading it is not such a strange thing to do [08:30] perhaps we should show a message and block [08:30] poolie: sure [08:41] In linux, strace shows close() correctly. [08:41] But in Windows, Process Monitor desn't show CloseFile! [08:42] interesting [08:43] http://paste.ubuntu.com/379598/ [08:44] In line 86, CreateFile failse. (rename) [08:44] In line 85, WriteFile happens to pack file. [08:45] There are no CloseFile between line 85 and 86. [08:45] http://paste.ubuntu.com/379599/ [08:46] This is strace in Linux. [08:47] write(7, "E", 1) is writing 1 byte. [08:47] next, close(7), and then, rename() happens. [09:14] poolie: I've fixed the sort performance in testresources [09:14] mm i saw [09:15] i wonder if the effort estimates are actually accurate enough that it's worth sorting carefully [09:20] poolie: well, it takes 0.02 seconds to sort for u1 now [09:20] so there is room to grow :P [09:20] anyhow, its not sorting carefully now [09:20] its sorting quickly [09:42] poolie: you might find http://www.youtube.com/watch?v=1HatEDkNnn8 and the related videos interesting [09:51] igc, you really don't have to finish the explorer bug tonight [10:08] Kamping_Kaiser, it needs disabling when subvertpy is built against svn < 1.5 [10:10] jelmer: <= or < ? I thought i had 1.5.1, since its a stable system [10:10] Kamping_Kaiser, < [10:10] hmm. most odd. [11:11] I want subvertpy binary package... [11:11] naoki: for windows you mean? [11:11] Yes [11:11] naoki: Isn't subvertpy included in the windows installer? [11:12] Yes. But I test bzr-svn with python2.6 and python2.5 I have. [11:12] Yes. But I'd like to test bzr-svn with python2.6 and python2.5 I have. [11:19] Wow! I can build subvertpy! [11:23] I can reproduce svn+ssh: problem with Python 2.6... [11:25] which problem? [11:28] In Windows, bzr branch svn+ssh://.../foo foo fails. [11:28] svn+http is OK. In Linux, all OK [11:29] traceback is http://paste.ubuntu.com/379585/ [11:29] strace in Linux is http://paste.ubuntu.com/379598/ [11:29] Procmon in Windows is http://paste.ubuntu.com/379599/ [11:29] In Linux, close() called after last 1-byte write() [11:30] In Windows, CloseFile() isn't called after last 1-byte WriteFile() [11:31] So rename() fails. [11:36] naoki: that doesn't seem related to bzr-svn [11:36] it happens deep down in bzrlib (though it's perhaps masking another error from bzr-svn) [11:37] naoki: have you tried turning off your virus scanner? just to see? [11:40] I've disabled auto-protect feature in AntiVirus. But I can't totally disable AntiVirus because I am using my company's PC. [11:41] the lack of a close is interesting though [11:41] perhaps a generator in the svn side not completing appropriately === jayne_ is now known as jayne [12:20] jelmer: is the usage of --layout=trunkX (like trunk2) documented somewhere? === mrevell is now known as mrevell-lunch [12:26] radoe: What layouts are available you mean? [12:26] "bzr help svn-layout" [12:28] jelmer: no, I had to used --layout=trunk2 to be able to svn-import a somewhat weird svn repo. And Ihad to look into the source to figure this out, as it is not mendtioned anywhere. bzr help svn-layout only mentions trunk without an additional level. [12:29] Hm, my connection has some serios lag, sorry for the typos... [12:30] the 2 just means two levels of directories before the actual branches [12:34] jelmer: yes, I figured this out, but had to look into the sources to get it. And I'm not sure why I had to use it anyway, because my trunk/branches are directly below the URL I specified. Let me explain about layout used in SVN a bit... [12:36] jelmer: The repo root used is svn+ssh://app/svn/instsrv. The repository has a /packages directory, which holds individual packages, like nagios-client [12:37] jelmer: so I tried to svn-import like "bzr svn-import svn+ssh://somehost/app/svn/instsrv/packages/nagios-client" [12:37] jelmer: and got the error " [12:38] "bzr: ERROR: The specified path is inside a branch." [12:38] radoe: svn-import imports all branches in a repo or all branches under a specific directory [12:38] radoe, it looks like you're trying to retrieve an individual branch [12:38] jelmer: i had to specify layout=trunk2, simply trunk did not work (same error) [12:39] radoe: for an individual branch, use "bzr branch svn+ssh://somehost/app/svn/instsrv/packages/nagios-client nagios-client" [12:40] jelmer: well, like I said, the repo is somewhat weired. It holds different packages below /packages, each with trunk and branches. [12:41] radoe, what is the repo root? [12:42] jelmer: svn+ssh://somehost/app/svn/instsrv/ [12:43] radoe, does it say it's using trunk2 when it starts? [12:46] jelmer: I had to specify trunk2 explicitly like in "bzr svn-import --layout=trunk2 svn+ssh://rdoering@zsl01/app/svn/instsrv/packages/nagios-client" to get what I want. [12:46] radoe: Does the repository also have parts that do not follow the branches/tags/trunk convention? [12:47] or perhaps at different levels? [12:47] that would confuse the heuristics [12:48] jelmer: possible, let me check... [12:50] jelmer: below /packages/*/ there is always a trunk, only some have a branches/ dir [12:50] radoe, and packages is the only top-level directory? [12:51] jelmer: no, I'm lookiong at the others currently. [12:52] jelmer: ah, in parallel to /packages there are two directories which qualify for trunk1 layout. [13:01] why would bzr think a file has been removed/added when its md5sum hasn't changed? [13:02] Because you did "bzr rm" and "bzr add"? [13:02] Or an equivalent merge? [13:02] There's more to a file's identity than its contents. [13:02] I'm merging an update from my pristine upstream branch into my local modified branch, but I haven't explicitly rm'd/add'd these files [13:02] normally when I do this it just merges in the upstream changes [13:03] Ng, maybe the merge deletes it? [13:04] http://paste.ubuntu.com/379718/ that's the pristine branch, with a diff of the revision that relates to the bzr import of the new release zip [13:04] skipping down to the bottom of that, version.php - after the merge that change shows up as a full conflict [13:05] not the whole file, just that one line. I'm sure that's within bzr's merging abilities, it always has been before [13:05] I wonder if this is some subtle, barely visible side effect of bzr import [13:07] hm [13:10] james_w may know [13:11] whu? [13:13] Ng: I'm not too sure [13:14] Ng: why do you say bzr thinks a file has been removed/added? [13:15] james_w: hmm, that might actually just be fallout from trying to correct the conflicts. I just branched afresh and did the merge and it looks more like it thinks that lots of files that are already in the branch have been added [13:16] I got it! [13:16] plink.exe have an pack file handle! [13:16] Ng: can you show me the bzr status of the fresh merge? [13:17] james_w: http://paste.ubuntu.com/379723/ is the merge itself, http://paste.ubuntu.com/379724/ is bzr st [13:17] hi [13:18] Ng: it seems like the root id of your tree changed somehow [13:18] that's not usual [13:18] is there decent bzr completion for zsh yet? [13:18] Ng: I assume that you don't do anything odd on your branch, and the pristine branch just uses "bzr import" each new version? [13:20] james_w: correct [13:21] Ng: care to run a couple of bits of python for me? [13:22] james_w: sure :) [13:23] Ng: python -c "from bzrlib.branch import Branch; print Branch.open('.').basis_tree().path2id('')" [13:23] run that in both branches [13:24] james_w: both say TREE_ROOT [13:25] oddness [13:25] Ng: not different tree roots then apparently [13:25] lets try all the file ids changing [13:25] python -c "from bzrlib.branch import Branch; print Branch.open('.').basis_tree().path2id('license.txt')" [13:26] in both again please [13:26] ok those are different === mrevell-lunch is now known as mrevell [13:27] ok [13:27] python -c "from bzrlib.branch import Branch; b = Branch.open('.'); rev = b.revision_history()[-2]; print b.repository.revision_tree(rev).path2id('license.txt')" [13:27] that in the pristine branch please [13:27] should print the same as the working branch did [13:30] huh, no, it's still different [13:33] I can make both branches available if that would be helpful, there's nothing secret in either [13:33] I hope the answer isn't that I'm doing something stupid ;) [13:34] I can take a look [13:34] easier than IRC-RPC [13:35] hehe [13:35] http://mairukipa.tenshu.net/~cmsj/bzr-wat.tgz - "www" is the working tree, "wordpress" is the upstream imports [13:37] Ping: jelmer [13:37] naoki: pong [13:38] I foud ssh client have "upload/xxxxx.pack" handle. [13:38] I tried cygwin ssh and plink (PuTTY) [13:38] Both client have pack file handle. [13:39] bzr branch from svn+ssh success if I kill ssh client before renaming ".pack" file. [13:40] Is there any way to kill source.transport connection before groupcompress? [13:40] Or bzrlib should not rename but copy .pack file? [13:40] naoki: why would that be necessary? [13:42] Because commit_write_group() renames .bzr/repository/upload/randomname.pack [13:42] So ssh client should not have the handle of the file. [13:45] hi naoki, jelmer [13:45] hi [13:45] naoki: The ssh client doesn't handle the bazaar packs at all [13:46] I don't know why ssh client have a handle of pack file. [13:46] But procmon tells me the ssh client have the handle. [13:46] And I success to branch when I kill the ssh client. [13:48] naoki, can you convert your patch for unicode Popen to merge proposal? [13:48]