[00:00] lifeless: is finish_commit -> post_commit a tweak or a resubmit? [00:00] lifeless: btw, I choose finish_commit to mirror the other mutabletree hook - start_commit [00:00] igc: I can appreciate that; there is some room for cleanup here. I specifically want to reserve finish_commit for a hook that actually is part of the guts of commit [00:01] as this hook isn't; it happens afterwards, I think post_commit is the right name [00:01] lifeless: sure [00:01] its a tweak, the rest of it looked fine with s/finish/post/ [00:01] uhm [00:02] this close to 2.0, I'm happy to resubmit [00:02] you mimght like to consider getting the delta of the commit into the parameters object or something [00:02] it will only take a minute to check my tweak [00:02] but we can do that later [00:02] igc: sure [00:02] I'll look at it asap [00:02] bbs, shower time [00:03] also, I'm ~ done for the day - as per my mail a couple of days back, I have a half day leave today and all wed + thur [00:03] igc: BTW, something occured to me in skimming past that hook merge... [00:04] igc: What happens to my expanded keywords when I uncommit? [00:04] is there a visual (GUI) tool to inspect a repo? to quickly look at the different branches? [00:05] fullermd: questions, questions ... I have no idea just yet [00:05] zsquareplusc: qlog [00:05] Well, I suspect the answer is 'nothing'. And it's probably not as big a deal, since uncommit most often will preceed either 'revert' or 'commit', both of which would update them to the appropriate reality. [00:06] fullermd: I suspect that's the case [00:07] fullermd: maybe a post_uncommit hook is needed too [00:07] I get uncomfortable combinatoric hot flashes just thinking down that path, though :| [00:09] Anyway. Just a thought to squirrel away. [00:10] Keywords not updating on commit is a flat day-to-day deal-breaker. Keywords pointing off into hyperspace after uncommit is a weird corner case behavior that will hardly ever matter. [00:10] igc: thanks, that displays something :-) i'm not yet sure if the display is complicated or the cvsps conversion was strange (branch names look OK though) [00:17] Should bzr not warn during a commit if the whoami doesn't look sane (eg. the default)? [00:19] wgrant: the default is sane some of the time [00:19] wgrant: it looks up user@mailname for instances [00:19] lifeless: HAhahaha. [00:19] but perhaps we should revisit this [00:19] lifeless: And which normal desktops have the email address set proprely? [00:20] A different population of users, I suspect [00:20] lifeless: Most people don't realise they need to do it, and those commits sit around forever. [00:26] i used cvsps-import. is it save to just delete the unneeded branches it created or is that destroying the repositories integrity (or isn't it a repository at all?) [00:26] zsquareplusc: delete what you don't want [00:31] ok. that looks good. glog shows the two branches and it makes sense what it shows :-) [00:33] how do i get those on launchpad? push each branch separately? or is there a more efficient way to upload the repository? [02:03] Well, that's interesting. Gentoo has bzr 1.18 now, and they've (re) hard masked bzr 2.0-rc1. So I'll be downgrading apparently (unless I intervene, of course, but this you-can't-upgrade bug in 2.0-rc1 seems pretty frightening). So should I be reverting to 1.18 now that it's released? [02:04] hi spiv [02:05] poolie: welcome to the other side (of the netsplit) [02:05] mm [02:05] presumably the other side will eventually evolve into marsupial megafauna or something :) [02:07] AfC: if you aren't using 2a repositories, there's no real difference. If you're using 2a, but not doing upgrades, then either should be ok I think, but 2.0-rc1 is probably a little better. [02:07] poolie: how far away is rc2? [02:08] good question, probably if your change is merged we should do it soon [02:08] spiv: well we were about to upgrade to 2a everywhere last week but then fortunately we saw Robert's warning and held off [02:08] AfC: phew! [02:08] spiv: apparently! [02:09] Hmm. Actually, you should avoid 2.0-rc1 if there's any likelihood of doing cross-format fetches between local branches. [02:10] Which would trip over the same bug as we saw in upgrade. [02:10] ok, well, in that case I'll let the version downgrade propagate. [02:10] thanks [02:10] Yeah. Better safe than sorry. [02:11] 2.0-rc2 should be strictly better than both 1.18 and 2.0-rc1, I hope :) [02:19] igc, i want to say that bug 385879 is not a blocker for 2.0 [02:19] Launchpad bug 385879 in bzr/2.0 "EOL filter only applied to files when first checked out" [High,In progress] https://launchpad.net/bugs/385879 [02:19] though still appropriate to fix in that series [02:20] i suspect this will be just the first cut of several similar bugs and i don't want to block 2.0 on all of them [02:22] poolie: I don't want to block shipping rc2 ... [02:23] poolie: but I do want that patch reviewed and landed if it's all ok [02:23] yep [02:23] i'll read it before doing 2.0rc2 [02:23] but if we can't merge it with tweaks, i think we should do rc2 anyhow [02:23] then i'll do more on that bug [02:24] please [02:26] igc, oh btw i didn't read your doc patch itself, just the cover letter [02:27] i saw you moved the developer guide [02:27] there was some kind of kludge where the source was stored separately from the destination, requiring it to be copied during the build [02:27] did you get rid of that ? it would be nice to [02:27] poolie: np. lifeless pointed out some tweaks I want to do anyway so I'm 75% of the way through those, ... [02:27] e.g. removing old cruft from the Makefile [02:28] poolie: the doc build in the new Makefile I'm hacking on is very simple now [02:28] is it possible to create a new branch, containing only parts of an existing one? i.e. the entire CVS repository was converted and there are some sub-projects that now all shown in one big bzr branch. [02:29] igc :) [02:30] zsquareplusc: i think bzr-rebase can help you do this? [02:35] hm. maybe. it would be easiest if it was possible to just branch from a path. (bzr-svn can do that from svn repos, so that the new branch only contains files from the given path) [02:49] zsquareplusc: well, if you branch, then just quickly `bzr rm` everything you don't want, then you'll have a Branch that has just what you want in it. Or, you can start a fresh branch {shrug} All depends on whether you need to preserve history, I guess [02:50] zsquareplusc: see bzr split [03:06] spiv, what's the state of https://code.edge.launchpad.net/~spiv/bzr/insert-stream-check-references linked to bug 406687? [03:06] Launchpad bug 406687 in bzr/2.0 "insert_stream doesn't check references are satisfied" [Critical,Fix committed] https://launchpad.net/bugs/406687 [03:06] is that an abandoned attempt? [03:07] Yeah. (It has some code that tries to reuse code from 'bzr check') [03:23] AfC: yep but in this case i'd like to have the history cleaned. Raim 's split seems to provide that. but the help output of the command is a bit terse. i'll try it later again. [03:27] zsquareplusc: Huh. I didn't know about `bzr split`. I wonder what it does. "This command will produce a target tree in a format that supports rich roots" doesn't seem much help. [03:28] spiv, ok, reading now, and noting in passing bug 426046 [03:28] Launchpad bug 426046 in bzr "diff against remote branch does many vfs operations" [Medium,Confirmed] https://launchpad.net/bugs/426046 [03:29] No, split just automates 'branch ; rm a bunch of stuff ; mv remaining stuff' [04:20] * igc lunch [04:59] vila_: 'morning. === vila_ is now known as vila [05:00] * vila waves ;-) [05:01] Forgot to ask if you ran into any other problems getting that VM working right. I guess no serious ones, since you're apparently using it :) [05:01] hi vila, you're up early? [05:01] I'm not really there in fact :-) I woke up an hour ago and was just passing around :) I may go back to sleep for another hour [05:02] Also, I had a thought on that group permissions thing. Would it be Bad to just take out the condition and always chgrp it? Should be a noop on SysV FSen, and would save chaining if's when the next platform needing it comes around. [05:02] I broke a coast biking last Friday so I wake up easily :-/ [05:03] fullermd: I was thinking about checking the group explicitely instead of sys.platform (which is ugly) [05:03] but yes, we shouldn't check platforms there [05:04] a coast? [05:04] fullermd: there may be some situations where files get a group you can't always set [05:05] also, this may cause delays over sftp [05:05] hmm, that thing in the upper chest [05:05] rib [05:05] ouch [05:05] poolie: it's only in tests not in code [05:05] rib yes ! [05:06] not really broken but I don't know how that is said, and it hurts only when I laugh, cough or try to turn in my bed :-) [05:06] It WAS comforting to see that all the test failures fixes involved fixing _tests_, not _code_ ;) [05:06] hehe, that's why we are so happy when we see test failures [05:07] hi all, how do I change the branch that bzr push is saved to? [05:08] timClicks: bzr push --remember [05:08] vila: thanks :) [05:09] i think the muscle is called the intercostal in english/latin [05:09] "Hey! My intercostal clavicle!" [05:10] (what a great film...) [05:10] vila: works perfectly, thanks for the prompt reply! [05:10] c\^ote is th French word for both coast and rib [05:11] timClicks: always happt to help (tm) :-) [05:11] timClicks: always happy to help (tm) :-) [05:11] fullermd: that's clavicule for you (not pointing any typo of course, not me ) [05:12] not canicule, which is something completely different [05:13] much more enjoyable when you're in that kind of hotness [05:13] (I learnt that word on a day in Paris where it was 35 degrees!) [05:13] > Côte-Rôtie can be rendered in English as "the roasted slope" or "the burning coast" and refers to the long hours of sunlight that these steep slopes receive. [05:14] Oh, I'm pretty sure it's always 'clavicle' anatomically, whether human or brontosaur. [05:14] poolie: perfect timing to surd on jml joke, I'm impressed :) [05:14] mm :) [05:14] s/surd/surf/ [05:14] heh [05:14] I was wondering what irrational square roots had to do with dog days on the coast :) [05:14] ohhh, clavicle.... one more French word in English [05:15] spiv, i'm back to your patch, going to send soon [05:15] go on go on... you won't make me laugh [05:15] oh how mean :) [05:16] i have some tweaks but i think we can merge it today [05:16] * fullermd delves into his quote file. [05:16] ``We don't just borrow words; on occasion, English has pursued other languages down alleyways to beat them unconscious and rifle their pockets for new vocabulary.'' [05:16] vila, actually, it's not a French word in English. [05:17] vila, it's a Latin word in French and English. [05:17] vila, from 'clavicula', arrived in English in the 17th century. [05:17] I'm pretty sure it got to English via [Middle] French, though, not via direct transplant. [05:17] jml: Pff, leave us some please [05:17] :) [05:18] * mwhudson lofts the issue of -ise vs -ize and runs away, terribly fast [05:18] * fullermd thinks that just emphasizes the color of the issue. [05:18] * jml throws a copy of Fowler's at mwhudson [05:19] fullermd, the OED says otherwise [05:19] * vila ouch, laughing hurts [05:19] Pfft. OED can be changed; it's not cast out of aluminum. [05:19] haha [05:21] spiv https://code.edge.launchpad.net/~spiv/bzr/insert-stream-check-chks-part-2/+merge/11290 review done [06:53] poolie: btw, when are you going to disable the [ascii] tests that PQM runs? [06:57] spiv, i thought it was done in trunk [06:57] i wasn't going to do it soon for 2.0 [06:57] just out of general risk aversion [07:05] vila, what's the overall story on shell [07:05] shell-like tests now? did they merge? [07:06] poolie: waiting for review :-) [07:06] spiv: I think they have been disabled and pqm *is* faster now [07:07] ha, hmm, yeah, trunk :-) [07:07] boring old trunk :) [07:07] igc, re bug 402623, it sounds like jam has a good handle on it [07:07] Launchpad bug 402623 in bzr ".cix thrashing causes us to re-download the whole index multiple times" [Critical,Triaged] https://launchpad.net/bugs/402623 [07:07] would it be better to reassign it back to him? [07:08] poolie: how busy is he? [07:08] spiv: nudge https://code.edge.launchpad.net/~vila/bzr/controversial/+merge/11295 should be trivial now [07:08] and hi all, here for good now :) [07:09] poolie: I'm knee deep pulling the windows installer out of the core and enhacing it right now [07:09] mm, that's what i thought [07:09] poolie: I'm happy to do other stuff but getting this out will allow multiple people to work on it [07:09] therefore probably not active on that patch at the moment [07:09] i'm not asking you to switch back to this, just the contrary [07:09] i was just looking at the non-2.0 critical list [07:10] poolie: not today [07:10] poolie: though my list for today did include looking over jam's reply [07:10] k [07:10] he seems to outline a patch for it, it might be simpler to let him just actually write it [07:11] poolie: no complaints from me! [07:11] poolie: my personal focus today is anything core related: doc patch, post-commit hook, content-filtering follow-up if any [07:12] cool [07:12] poolie: so I'm waiting on a review of cf and doc patch [07:12] ok [07:12] i'm doing the doc one now [07:12] i'll read your cf patches and then maybe look for more cf things myself, you never know [07:12] and working on getting the installer out of the core while I'm waiting [07:13] poolie: so my thinking wrt cf is that that particular patch ought to get it 'working in the common cases' [07:13] which is good enough for 2.0 - other fixes can come later [07:14] bzr-keywords needs to use that new hook that landed this morning but, again, that can come post rc2 [07:17] sounds good to me [07:18] wow that's a huge patch? [07:18] s/?// [07:18] also you get some kind of distinction for writing batch files, if you did :) [07:19] vila: ta, yes. [07:19] spiv: ok for landing then ? [07:20] ok commented on the docs patch [07:22] Hello! I'm trying to figure out how best to integrate my bzr depots into my rsnapshot backups. My first inclination is to simply bzr init a repo on the backup drive for every repo I want, and then simply 'pull' every hour/night/period. Is this what's normally done? [07:26] Furthermore: if that is the preferred way; is there a better storage type to use to maximize rsnapshot's hardlinking facilities? (i.e., something that keeps deltas in separate files, so I don't have X copies of non-changing data around?) [07:28] KhaZ: a recent pack-based format will come fairly close to that behaviour [07:28] that sounds reasonable [07:28] poolie: pushing tweaks now, about to submit to PQM for 2.0 [07:28] though maybe you'd rather backup the whole directory, including working trees, from your workstation/laptop? [07:28] that's what i do [07:28] woo spiv [07:31] vila: so the full test suite should pass now on FreeBSD? [07:31] vila: that's pretty neat! [07:32] spiv: yes, at least on my FreeBSD vm, I'm waiting confirmation from fullermd but that will be easier with both patches landed [07:33] vila: was it just test suite bugs, or were there real bugs too? [07:34] only test bugs [07:42] igc, i guess https://code.edge.launchpad.net/~ian-clatworthy/bzr/pdf-chm-docs-for-2.0/+merge/11182 is needed as well as doc-per-site-language? [07:42] they look like they overlap a bit? [07:43] poolie: doc-site-per-language is a superset of the other [07:43] so i might mark it superseded then [07:43] poolie: I left the other one there because it was the barest minimum required [07:43] sure [07:47] spiv: I think vila's not seeing the weird errors with revisions disappearing that I do. It may be py2.6 related, though I'm sure I've reproduced it on 2.5 in the past. [07:48] Probably be a while before I can try out the changes; I haven't gone to 2a yet, probably won't have time 'till later this week at least. [07:48] fullermd: oh, do you have the loom plugin installed ? [07:48] Nyet. [07:48] any othe plugin ? [07:48] any other plugin ? [07:49] Several, but I ran the tests with --no-plugins. [07:49] ok [07:54] After I do the 2a switch and catch up, I'll see if I can get a run in on both systems (amd64/8.x/py26 and i386/7.x/py25. That should nicely isolate the root of the problem :P) [07:55] 8.x ? [07:56] OS version. [07:56] Is that released ? [07:56] Who needs releases when you have CVS/SVN? :p [07:56] :-) [07:57] Ok, wrong question, same player tries again, [07:57] It's actually branched though, so next update I'll be on 9.x. [07:57] Should I setup my slave with 8.x instead of 7.2 ? [07:57] Well, if 8 were out, maybe. It's on beta... beta4, I think? [07:57] I doubt it would matter for the purposes of testing bzr. [07:58] But which one is considered stable or is the most used ? [07:59] ha, sry, missed that line [07:59] so 8 is not out, ok, let me know when it is then :) [07:59] 7 at this point, probably. 6 is fading out, 5 and earlier are probably dead outside of special cases. [08:00] Last schedule update suggests ~end of the month. It'll probably slip, like schedules always do. [08:00] ('course, it'll probably be announced without a Windows installer available ;> [08:03] pff, those lazy packagers.... [08:05] good day gentlemen [08:05] * fullermd waves at bialix. [08:06] * vila waves [08:06] * bialix waves back [08:06] . o O (waves lead to tsunami...) [08:06] :-D [08:07] That's OK, I'm a hundred miles or so inland. [08:07] same here ;) [08:07] what's wrong with windows installer again? [08:09] bialix: ?? [08:09] [10:00] ('course, it'll probably be announced without a Windows installer available ;> [08:09] Excess therbligs. [08:10] bialix: Ooooh you mean the FreeBDS installers ? :-D [08:10] BSD even [08:10] therbligs? [08:11] oh. I see [08:11] Well, I was being a little facetious. [08:11] (but 'excess therbligs' DOES seem to be a problem with making it, so...) [08:11] yes, you do [08:14] hi bialix [08:15] hi igc [08:15] igc: ru-chm content is so small for some special reason? [08:15] bialix: I alomst have the win32 installer stuff out of core btw [08:15] igc: cool [08:15] igc: why you want 2.6? [08:16] bialix: if I publish the project, are you able to test it at all? I'm still get c compilers installed, etc on vista [08:16] bialix: just felt I ought to ask re 2.5 vs 2.6 [08:17] I still use 2.5 because 2.6 is the whole new thing [08:18] poolie said there is something faster with 2.6. I dunno what exactly but I think it should be measured on win32 separately [08:18] poolie: oh, drat, it failed pqm. There's a test that tries to create a broken repo as part of the fixture that now fails at commit_write_group time... [08:19] igc: publish the project? I think I can try it [08:20] poolie: fixing now [08:21] (by skipping the test in that case) === BjornT_ is now known as BjornT [08:28] I guess it's extra proof that the code works.. [08:33] Hmm. [08:33] I wonder if this last failure is actually a real bug or not... [08:38] It sure looks like a real bug uncovered by this patch... [08:42] bialix: https://code.edge.launchpad.net/~bzr/bzr-windows-installers/trunk [08:43] bialix: some questions ... [08:43] 1. does the Makefile look ok? [08:43] 2. What inside tools/win32 needs to remain in the bzr core project? [08:44] I'm guessing most of it is redundant with this stuff pulled out? === JaredWigmore is now known as JaredW [08:48] Say, I'm getting the following message and I'm not sure what it means: 'No handlers could be found for logger "bzr"' [08:50] tonyyarusso: where are you seeing that? [08:50] In a program that imports bzrlib, or from the "bzr" command-line tool itself? [08:50] spiv: 'bzr' itself [08:50] That's pretty weird. [08:50] Are you using any plugins? [08:51] Not that I'm aware of? I just started using it. [08:51] What command are you running? [08:51] It's a harmless message, but you shouldn't be getting it. [08:51] init, add, I think commit did it [08:51] Also, what version of bzr? [08:51] 1.3.1 [08:52] Hmm. That's pretty old. Possibly this is something that's fixed in a newer version. [08:52] Wait a sec, I think I found something relevant [08:53] Yup [08:54] For some reason my .bzr.log was owned by root [08:54] which apparently confuses it [08:56] Oh, right. I do remember something about that bug. [08:56] I'm not sure if that got fixed since 1.3.1. [08:57] meh, either way, as long as I know nothing's going to explode I can go to bed ;) [08:58] igc: tools/win32/ostools.py used by main Makefile [08:59] igc: sorry, I'm a bit busy right now, will look shortly [08:59] bialix: np [09:04] poolie: Hah, yes, this patch did find a real bug. [09:07] poolie: Although not really an important one. The "push inventory-deltas to server without RPC that supports inventory-deltas" case had a subtle bug; it wasn't doing target_repo.refresh_data between stopping the RPC insert and falling back to the VFS insert. [09:08] So the new paranoia erroneously believed a text was missing in some cases (depending on autopacking, I think). [09:08] igc: about new Makefile: there is no docs bundled into installer? [09:08] bialix: the intention is to bundle the new chm files [09:09] and? [09:09] bialix: possibly by pulling them from the downloads area on doc.bazaar-vcs.org [09:09] ok, so bzr.iss should be updated [09:09] and probably the buildout.cfg file as well [09:09] * bialix real prefer scons for complex builds [09:10] poolie: resending now. [09:11] igc: I think bzr.iss.cog should be retired and special python script just used to generate the bzr.iss [09:12] but maybe post 2.0 [09:19] igc: how you expect to marry this separated project with bzr.dev at build time? [09:20] buildout.cfg grabs the bzr code from lp [09:20] bialix: ^^ [09:21] igc: ok re-phrase queston: you're using Makefile in the same position like in bzr.dev Makefile [09:22] so they will clash [09:23] bialix: ah ok - I guess the Makefile for this project needs to delegate down to build-win32/Makefile or something like that? [09:24] delegate down? [09:26] G'day all === Ng_ is now known as Ng [09:28] I'd like to help getting dulwich/bzr-git working (with bzr-receive-pack and bzr-upload-pack). [09:28] I guess I'll be poking the usual suspects, aka jelmer, james_w and Jc2k (if memory serves) :-) [09:29] igc: may be you need to start from the desired layout of components at build time? [09:29] igc: I'd prefer to have bzr.dev and win32 tools in separate directories [09:35] bialix: I need to have dinner now and spend some time with the kids [09:35] bbl [09:35] kk === bialix is now known as bialix-afk [09:35] bialix: I've emailed bzr-windows with some brief details on the new project so hopefully a few people can help me pull this together [09:36] * igc dinner [10:09] jelmer: I've gotten to the point where I can "git clone" a bzr branch, with a small patch in bzr-git, see http://pastebin.com/f4e3d0434 [10:09] Can't fetch or pull or push yet, but I'm on it :-) [10:09] Lo-lan-do: cool :-) [10:11] My test setup is "described" at http://pastebin.com/f14c3c80d [10:11] Stuff between the ----- lines is done as guest, the rest as myself [10:11] (guest being a trashable account, completely emptied from time to time) [10:14] jelmer: Can I also bother you with dulwich, or is that more james_w's turf? [10:14] Lo-lan-do: no, dulwich is fine too [10:14] Okay :-) [10:16] Oh, by the way, I believe the patch is incomplete, there are probably other places in bzr-git where the branch location is interpreted as a transport. I just haven't faced them yet. [10:19] As for dulwich, there are several places where progress() is called with informative messages. These messages are unfortunately sent on the wire, and for some reason they don't conform to the git protocol so the client barfs on receiving them. [10:19] Lo-lan-do: I think the intention was actually to use a transport there [10:19] rather than a path [10:21] Maybe. But my short-sighted patch makes it work :-) [10:21] Example for dulwich: http://pastebin.com/f4adf44d1 [10:22] jelmer__: ji [10:24] lifeless: ji! [10:25] Ni? [10:25] Lo-lan-do: hmm, is that a recent change? I'm pretty sure that progress reporting worked in the past [10:26] jelmer__: No idea. I've neglected this bzr-git stuff for too long. [10:28] jelmer__: so, subunit. [10:28] jelmer__: I want to release 0.0.2; your perl diff is incomplete. [10:28] jelmer__: ~ a week+ ago you said a few days :P [10:29] jelmer__: I'm here to nah [10:29] *nag* [10:31] Aehm. It appears my git client doesn't like sideband stuff… [10:32] Or maybe it doesn't like that the server doesn't announce it. [10:35] Or maybe I suck, since the server does announce it. [10:41] lifeless: sorry about that [10:41] lifeless: I took some time to look into it two days ago but I ended up fighting with automake [10:41] jelmer__: I can help, but you need to point me in the right direction :) [10:42] lifeless: automake doesn't have a way to install perl stuff by itself, so we have to call out to a perl makefile [10:43] That Makefile can be generated by running perl/Makefile.PL [10:43] but I can't figure out a way to get automake to trigger that rebuild before recursing down into the perl subdir [10:45] so, you need configure to run perl/Makefile.PL [10:45] or you need make to [10:45] uhm [10:46] put . into SUBDIRS [10:46] in /Makefile.am [10:46] SUBDIRS = . perl [10:47] perl/Makefile: [10:47] $(PERL) $@ [10:47] or whatever [10:48] in fact [10:48] perl/Makefile: perl/Makefile.PL [10:48] $(PERL) $@ [10:49] lifeless: that doesn't work, it recurses before making perl/Makefile [10:50] no [10:50] thats what SUBDIRS = . perl [10:50] is for [10:50] you'll need one more target to tell it that it needs perl/Makefile to recurse [10:52] lifeless: how do I tell it that? [10:52] add [10:53] $(RECURSIVE_TARGETS): perl/Makefile.PL [10:54] just that? [10:54] yes [10:54] no rule [10:54] or you will replace the big rule for recursive targets [10:54] complains about a undefined user variable [10:54] automake does? [10:55] yes [10:55] add distclean-local: [10:55] -rm perl/Makefile [10:56] while we are here [10:56] can you pastebin your patcfh ? [10:56] also, #subunit might be more appropriate at this point :O [10:56] lifeless: I'm there (-: [10:57] not on my server ;P [10:57] http://pastebin.com/m2ec94176 [10:58] jelmer__: as in, I can't see you in #subunit [10:58] hmm, that's odd [11:01] it had lost me [11:31] lifeless: merge req submitted [11:32] sweet === bialix-afk is now known as bialix [12:04]