[00:00] lifeless: so reading Martin's mail, I think error code 2 makes more sense here. [00:00] mlh_: I think we've lost the context to the question [00:02] Urgk. What's the way to make a command throw a specific error code? Do I raise() something (such as BzrCommandError)? [00:04] thumper: yeah sorry I didn't want to distract people from the current one. [00:04] 10:30 < mlh_> a bit OT but do any DVCs support having the repo on one disk and the checkout/tree on another? [00:04] 10:30 < lifeless> mlh_: bzr does [00:04] 10:30 < lifeless> mlh_: bzr does [00:04] oops === mark1 is now known as markh [00:07] mlh_: I use lightweight checkouts for this [00:21] kfogel: see e.g. cmd_diff [00:21] kfogel: I have replied to the original thread btw [00:21] I think that its ok to do this [00:21] but commit needs attention [00:22] and it needs to be more visible; this is an exceptional case [00:22] As stephen said, its nonsense to argue that this matters for vc-el [00:22] lifeless: reading your reply [00:22] from the user perspective I grant the argument about just-another-status [00:24] yay, I finally have a scrubbed repo [00:24] weirdness from 2005 eliminated :P [00:32] lifeless: dang it, I hate how mail archives are always a bit behind. I'd like to refer to lifeless's mail in a commit message right now, but I don't have the archive URL yet. [00:32] kfogel: in an implementation sense, do the status operation, then raise an error [00:32] lifeless: already done :-) [00:32] just writing the log message now [00:32] I went with code 3. Still need to make sure that commit also behaves that way, but I think it does. [00:34] kfogel: oh, have I introduced you to bzr-search? [00:35] lifeless: ? [00:35] https://edge.launchpad.net/bzr-search [00:35] oh, nice! [00:35] SVN has needed that for years, and no production-ready solution exists still. [00:36] :) [00:36] lifeless: be interesting to have it index the diffs of the commits too, as in "Show me changes containing string S" [00:36] it indexes the diffs [00:36] lifeless: ! [00:36] lifeless: home page doesn't say that [00:36] unique text of merges too [00:37] content of files ;P [00:37] I can tweak it [00:37] lifeless: "content of files" means something different :-) [00:37] well you get the content by starting with nothing and patching :) [00:37] I started with whole text every time, it was useless [00:37] I'm not sure I even committed that version :P [00:39] anyhow, give it a spin [00:40] if you have bzr-search present, loggerhead will do ajax search completion stuff [00:51] wishlist item, tab completion of deleted files [00:58] lifeless: is there a way to automate bzr-search reindexing/ [00:59] davidstrauss: how do you mean? [00:59] lifeless: I have Loggerhead showing some server-side branches, but nothing handles reindexing them automatically, it seems. [00:59] davidstrauss: what bzr version are the clients? [01:00] davidstrauss: its meant to index new revisions automatically [01:00] I presume thats what you mean, rather than delete the index and start over [01:00] lifeless: yes [01:00] are you pushing/committing with bzr+ssh? [01:00] lifeless: does the smart server automatically handle that? [01:01] theres a post branch tip change hook [01:03] I get Errno 13 when doing bzr update [01:03] how do I know which file is permission denied? [01:04] onox: bzr doesn't tell you? Hm, please file a bug. [01:04] onox: and I'll give you a workaround - [01:04] bzr: ERROR: [Errno 13] Permission denied [01:04] run with [01:04] BZR_PDB=1 bzr ..... [01:04] then you will be dropped into pdb [01:04] you can use that to find the filename and print it, probably [01:04] and a lot of -D and M [01:04] pdb? [01:04] python debugger [01:05] this clearly isn't user friendly, but it will help get you going again :) [01:05] the bug report will help us fix the root cause [01:06] lifeless: http://dpaste.com/115462/ [01:06] how to proceed? :) [01:07] type in [01:07] bt [01:08] and [01:08] list [01:09] lifeless: http://dpaste.com/115463/ [01:09] onox: pp from_, to [01:10] (u'/home/mark/workspaces/python/awn-extras/src/tomboy-applet/icons/Makefile.am', u'/home/mark/workspaces/python/awn-extras/.bzr/checkout/pending-deletion/new-85') [01:10] morning all [01:11] The permission denied happened while renaming that Makefile.am to that second filename. [01:11] Possibly you lack write permission in either the source or destination directory? [01:12] pending-deletion/ doesn't exist [01:13] onox: that's weird! That directory is created by the TreeTransform constructor. [01:13] ah, lol [01:13] found it [01:13] src/tomboy-applet/icons/tomboy.png was root:root [01:14] but has nothing to do with the revisions I tried to fetch [01:14] :S [01:15] so, bzr tried to delete src/tomboy-applet/icons/Makefile.am (among other files), but it failed because icons/tomboy.png was root:root [01:17] onox: please do file a bug [01:17] bugtracker at LP? [01:17] onox: right === kiko is now known as kiko-zzz [01:28] spiv: bug report filed === asac_ is now known as asac === RAOF_ is now known as RAOF__ === RAOF__ is now known as RAOF [02:10] trying for zen-hacking mode, will poll back here hourly or so === timchen119 is now known as nasloc__ [02:15] memo to self, tell vila 13:08 < cortana> however it uses M2Crypto.HTTPSConnection which can possibly be used as a replacement for the default HTTPSConnection class [02:29] igc: ping [02:29] hi fullermd [02:29] Hey. You did some log change recently that sped it up with a specified revision range, right? [02:30] I did but it's not yet landed [02:30] jam voted tweak and I'm yet to do the tweaks [02:30] today possibly [02:30] Hm. Ok. I came across a really weird performance thing, thought it might be related. [02:31] namely? [02:31] (flog = log --forward --short) [02:31] On bzr.dev, bzr flog -r-16.. takes 2.88 seconds. [02:31] -r-16..-1 takes .55. [02:31] my patch fixes that [02:31] so they both take 2.88 seconds? [02:31] :P [02:31] :-) [02:32] Maybe they take 1.44 each ;) [02:32] sorry to surprse but they both take .55 now :-) [02:32] Sweet. [02:33] igc++ [02:33] fullermd: in case your curious, bzr.dev loads all of mainline history for -10.. but not for -10..-1 :-( [02:34] igc: why? [02:34] kind of sucks on an emacs repo with 93K revisions on the mainline [02:34] Leprechauns. [02:34] thumper: a bug [02:35] well, a bug in that it search all of history to find '' instead of realising that it's the tip when at the end of a revisionspec [03:01] :) [03:01] igc: at least that sounds simple [03:18] * igc lunch [03:56] is there a way with bzr to grab a tarball of a remote branch (for buildout) ? [03:57] bzr export ? [03:58] thumper: bzr export foo.tar.gz lp:foo, iirc [03:58] ta [04:24] is there any way to set the parent branch for a light weight checkout? [04:25] we have a utility that uses sed to check for the parent branch in `bzr info` [04:25] my branch doesn't have a parent set [04:27] bzr pull --remember [04:28] You could probably even abuse -r to avoid actually pulling anything, e.g. "bzr pull -r revid:FAKE --remember $parent_url"... [04:46] thumper: parent branch is in the branch, not the tree === samurai is now known as samiam [06:18] night all [06:19] night, lifeless [07:18] hi all === AfC1 is now known as AfC === mark1 is now known as markh [07:30] vila: urllib2 https possible hint: 13:08 < cortana> however it uses M2Crypto.HTTPSConnection which can possibly be used as a replacement for the default HTTPSConnection class [07:32] lifeless: I looked into M2Crypto long ago, except if some serious upgrade has been made, I'll prefer to use the ssl module introduced by python-2.6, for which 2.5 and 2.4 support exists via dedicated module, but thanks for the hint [07:32] lifeless: and hi ! Always a pleasure to cross you here ;) [07:32] I wouldn't cross lifeless if I could help it ;) [07:33] damn... cross doesn't carry the idea of meeting briefly ? [07:34] vila: it does somewhat, but it also carries the meaning of "To run counter to; to thwart; to obstruct; to hinder; to clash or interfere with." :) [07:35] Ouch :-) [07:35] its ok, I took your meaning as intended [07:35] What common verb or expression should I use then ? (In case I came across less tolerant people :) [07:35] vila: "overlap" is probably more unambiguous, unless someone wants to be interpret it in a physical rather than temporal sense ;) [07:36] Cross is fine, I was just being silly. [07:36] more unambiguous... you try to lose me again :) [07:36] Well, nothing's *totally* unambiguous in English. [07:37] meet [07:37] encounter [07:37] intersect if you're feeling geeky. [07:38] * davidstrauss also has an English degree. Is this a debate about diction? [07:38] Yeah, I think intersect carries the time scale I wanted to point to :-) [07:38] Basically the problem isn't English, it's my enthusiasm for creative misinterpretation... [07:40] spiv: Oh, I see, strangely enough fullermd haven't intersect with the discussion yet.... :) [07:40] Oh, I see now that nothing of substance is being debated. Carry on. ;-) [07:40] Heh. [08:32] Hmmwhat? Did I miss a chance to screw English around? [08:33] * fullermd gets rather cross. [08:38] * igc dinner [09:00] lifeless, yeah [09:06] jelmer: moin [09:06] jelmer: I'm back at dizzy, want me to do anything? [09:08] LarstiQ, see privmsg === gdmfsob is now known as mishok13 === mark1 is now known as markh [10:24] * AfC wonders what we'd have to do to get ohloh to support bzr [10:25] given it's open source now and already supports hg, it shouldn't be that hard [10:28] is it open source now? [10:28] AfC: the +1s from users have been ignored so far [10:29] AfC: jelmer (iirc) and myself offering to help implementing notwithstanding [10:29] apparently not the right avenue to get things done [10:30] http://thechaw.com/ohloh_scm/ [10:41] LarstiQ: I know. Lots of us have offered [10:52] the source code for Ohloh has been published [10:52] at least the SCM-related bit [10:53] so somebody *could* contribute bzr support [10:53] how about you just create a patch, send it in and see what the feedback is? [10:53] unfortunately it's all ruby :-( [10:53] AfC: do you know any ruby ? [10:57] Pieter: that is now indeed possible, it wasn't before. [11:07] jelmer: not a line === AfC1 is now known as AfC [11:19] jelmer: I have the pickaxe book, does that count? ;) [12:14] night all [13:21] vila: just wondering if you had a chance to play with my updated fix277537, and see how it worked for you [13:21] I'm going to be offline in about 10 min [13:23] I guesss a bit earlier, as my machine wants to reboot. hopefully bbiab [13:23] jam: rats, too late [15:28] is there a bzr-html plugin, like the qt one? === joshuablount is now known as jblount === kiko-zzz is now known as kiko [16:02] is there a way to include in a file the rev and the date each time I commit a change on that particular file? [16:03] There's a keywords plugin IIRC [16:03] But that kind of thing is kinda nasty IMO [16:03] The context is that I would like to update this piece of information on the documentation store in the bzr branch. === abentley1 is now known as abentley [16:04] As I said, I think there's a plugin which may help you === apw is now known as cafetiere === cafetiere is now known as apw [17:04] will bzr-git work with bzr 1.5? [17:04] I think it requires a newer version. [17:05] Hm, actually I'm not so sure. The code doesn't seem to check. [17:09] I tried doing a branch with 1.5, and got an error message saying bzr couldn't load the git plugin, but I didn't know if I'd done something wrong, or if the version was incompatible [17:12] What was the error message? [17:21] oh, sorry: "Unable to load plugin 'git' from '/home/lbar4/.bazaar/plugins'" [17:22] Nothing else? [17:23] nope [17:25] Tak, anything in ~/.bzr.log ? [17:25] jelmer: He uses bzr 1.5, but I didn't see any requirement for a greater version in git/__init__.py [17:25] Lo-lan-do, oh, you need bzr 1.12 [17:25] or perhaps 1.11 [17:26] the bzr API call to check the bzrlib version probably isn't in 1.5 [17:26] ok [17:26] I guess I'll just use git for now then [17:26] hi btw :-) [17:26] * Tak cry [17:28] jelmer: have you looked at/tried my md-bzr branch recently? [17:29] Tak: Yeah, but I haven't managed to build it yet [17:29] dinner time, back in ~an hour [17:29] Uh, that time already? [17:30] Damn, the day went past without me noticing. [17:30] * Tak nods [17:30] Lo-lan-do, well, Dutch traditionally eat at 18:00, I think it's more like 20:00 for the French? [17:31] or later [17:31] I'm usually hungyr (and tired of work ;-) at around 19:00, but I was just generally wondering how it was already half past six and I thought I still had some time to do stuff. [17:37] hmm [17:37] argh dammit [17:38] jelmer: how fast can you guys get rid of the single head branch thing - its the main gipe i always run into over and over [17:38] Is that the "colocated branches" thing? [17:41] not exactly [17:41] i dont care if they are named, but i want more than one head on the same branch [17:48] well, not exactly branch - i just want multiple heads accessible from the same workingtree as easy as possible [17:56] ronny, ...referring to a git-like workflow? [17:58] ronny, "bzr switch foo" strikes me as pretty similar in effect, even if the implementation is different. [17:58] nDuff: mostly monotone and hg alike [17:58] bzr switch is a lot more for me to do [17:59] ronny, how so? if only providing the last element (not the full path), it reuses the location of your existing branch except for the last element, so it really does only need the branch name as the argument, not the URL. [18:01] doesnt fit my workflow [18:02] santagada, loggerhead [18:02] ronny, ...hmm; I haven't worked with monotone at all, and hg fairly little, so I'm not entirely sure what you're looking for... would it be similar to looms? [18:03] no [18:05] ...hmm; as I don't grok the workflow distinction between using switch within a shared repo and multiple heads within a branch, I don't think I can help. === abadger19991 is now known as abadger1999 [18:09] nDuff: i mainly want to have a as simple structure in the fs as possible [18:10] i dont care how exactly management works - but it should stay the hell outa my fs [18:11] ronny, ...oh, so it's not a workflow issue, but an aesthetics issue. [18:12] i did set up my whole env to deal with the projects being in their place [18:13] if they are suddenly in another place, its fucked [18:14] ronny, I need to get comments on my proposal for colocated branches first [18:14] hmm [18:14] jelmer: whats the url again [18:14] for the spec? It was posted to the mailing list? [18:16] jelmer: i dont follow the ml and google didnt find it [18:16] ronny, one sec [18:16] oh yikes [18:16] i just noticed how broken the new bzr support for anyvc is [18:17] ronny, https://lists.ubuntu.com/archives/bazaar/2009q1/051320.html [18:21] jelmer: as for collated branches in url's - how about a http get param? [18:23] jelmer: alternatively collated branches can just be mapped to a directory containing multiple branches on a remote [18:23] magic chatacters wont be nice [18:24] ronny: yes, but what if there is a on-disk branch with the same name? [18:24] ronny, this has already been discussed separately on the list, in a different thread [18:24] there wasn't a conclusive outcome [18:26] jelmer: repo/branchname vs repo/collation/branchname or repo/collation?branch=branchname [18:27] since collated branches wont have a physical path i think a get param maps the intend better, but a path maps it more restfull [18:27] ronny, GET-style parameters is more typing [18:28] ronny, martin has suggested using regular path separators and using GET-style parameters in case there is ambiguity [18:28] but if one uses collated branches for git-alikeness wont he actually sync with the main url of the collation [18:29] ronny: ? [18:29] Hi guys. I'm getting "bzr_log.random-" files appearing in my working copy after commits (all successful). Any ideas how to prevent that? [18:29] jelmer: as far as i understand git users usualy deal with paths to repos, not paths to branches [18:30] the contents of the files are the prefilled commit templates [18:30] so they would deal with repo/collation instead of repo/collation/branch [18:31] jelmer: also would there be an issue in just adding an extra path element to let the whole collation have a name? [18:31] ronny, yes, ambiguity with any actually existing branches on disk [18:31] Hi! Can I push a bzr branch into a subdirectory of a svn repository using bzr-svn, even though the two are unrelated at first? How would I specify a merge base revision, as the error message "Branches have no common ancestor, and no merge base revision was specified." indicates? [18:32] jelmer: can people do things like get a collation a repo/foo and a branch at repo/foo/bar [18:32] ronny: bzr's UI is very much oriented towards branches, git only uses URLs for repositories [18:32] ronny: yes, there can be a (nested) branch or regular branch at repo/foo/bar [18:32] MvG, you can merge in that case using -r0..-1 [18:33] MvG, I mean "bzr merge -r0..-1 " [18:33] jelmer: But I want to push, not merge. I can't merge from a nonexistant directory, can I? [18:33] MvG, are you using "bzr svn-push" ? [18:33] jelmer: No. Should I? [18:34] MvG, yes - see the bzr-svn FAQ [18:34] jelmer: oh :/ then it needs an url param [18:35] OK, will do. Once I've reestablished my bzr-svn setup, which I've just nuked by pulling and deleting subvertpy... [18:35] ronny, See my lines earlier - Martin suggested using path separators but falling back to GET-style parameters to deal with ambiguity [18:36] jelmer: there is a major issue - how does a user decide if he needs to fall back [18:36] hmm [18:37] now i need the docs for workingtree - is there anything beside source/pydoc? [18:37] jelmer: what about adding a -b option flag ? [18:37] ronny, pydoc should be pretty comprehensive [18:38] or would that break a lot of things UI wise ? [18:38] asabil, impractical and that would mean adding a branch parameter in the API everywhere as well [18:39] yes I see [18:48] jelmer: Is there an easy way to install bzr-svn + subvertpy as user - preferably with unmodified branches symlinked to dirs like ~/.bazaar/plugins? Used to work before subvertpy got factored out, but I can't seem to get it working now. [18:49] MvG, you can install subvertpy into the system or set PYTHONPATH appropriately [18:50] Both feel ugly, but I'll use this for now I think. === abadger19991 is now known as abadger1999 [19:02] ronny, also feel free to ask questions here if you have them, of course [19:05] jelmer: just started fixing stuff, seems like the bzr stuff someone else added to anyvc is highly bugged [19:05] beuno: sorry, what was it [19:05] ? [19:08] santagada, if you want a web UI for bzr, you can use loggerhead [19:09] hmm [19:09] beuno: no I wanted something like a plugin that output html [19:09] god i wish anyvc was already usable for web ui's [19:10] so I could use the result of bzr blame inside some other tool (in my case textmate) [19:10] santagada, you can use bzr-xmloutput [19:10] beuno: then use a xslt transform to transform it to xhtml? [19:11] santagada, maybe, yes :) [19:12] beuno: Hi Martin :-) [19:12] beuno: not a big fan of xslt... maybe I will use the bzr api and generate html using something like jinja templates [19:12] beuno: thanks [19:13] what package defines the NotBranchError? [19:13] ronny, bzrlib.errors [19:13] santagada, as an aside, if you're trying to generate xhtml, I'd consider using Genshi as a way to be certain that your output is always well-formed. [19:14] nDuff: I don't care much about well formed, and it will be any html that webkit can grok [19:14] and I don't like genshi [19:14] it's better than xslt [19:18] I've done 'bzr init-repo .; bzr branch lp:bkrpr bkrpr-trunk; <>; bzr branch bkrpr-trunk bkrpr-task-branch-foo; cd bkrpr-task-branch-foo; <>; bzr commit -m 'Finish my task.' " [19:19] Is 'bzr push lp:bkrpr' the right way to send my change to the upstream? [19:20] I'm reading '6.2.5 Merging a feature into the trunk' in the User's Guide, but I'm not 100% sure 'bzr push' is the right thing... [19:28] CaMason: ping [19:29] CaMason: you has asked your question about bzr_log files [19:30] bialix: yes :) [19:30] CaMason: these files have created by your editor when you type the commit message. I suppose it's auto-backup. What is your editor? [19:30] I'm actually wondering if it is anything to do with vim... I did vimtutor the other day (which helped set up a .vimrc) [19:31] I recall this question has raised in the past [19:31] IMO you can delete these files safely. I don [19:31] I do delete them.. it's just messy having them in my wc :) [19:32] must be a setting within this .vimrc then [19:32] I don't use vim, so I can't help and suggest how to prevent them [19:32] jelmer: Hi, can I ask you a bzr-svn question? [19:32] rblasch, yeah, np [19:32] CaMason: something like :w!-+?@ combinaion needed. more or less [19:32] bialix: no worries, thanks either way.. it's help me pinpoint my thoughts :) [19:33] Great! I've set up thing to work with the latest 0.5 version. [19:33] When doing a branch, bzr suddenly hangs. [19:33] CaMason: It's just silly to see how you ask this question several days in row and nobody answer [19:33] The last message I get is "determining revisions to fetch 11111/36167", without any further progress. [19:34] CPU load stays high, though. [19:34] bialix: I was thinking.. if this was an editor issue, somebody would have seen it before :s [19:34] Same thing with 0.4 works fine. [19:34] yep [19:34] CaMason: that's all I know. good luck [19:35] Is there any diagnostics I can enable to track this down? [19:35] rblasch: Could it be the same as http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=513412 ? [19:35] Debian bug 513412 in bzr-svn "bzr-svn: Fetching revisions from SVN is slow" [Normal,Open] [19:35] bialix: aha, I think i've spotted the line. An if statement was overriding my set nobackup :) [19:35] rblasch: you can run with -Dtransport -Dcache and see what it is doing [19:35] rblasch: Try with -Dtransport -Dcacne [19:35] rblasch, also, you can try with bzr.dev, that will have better progress indication [19:35] :-) [19:36] bialix: ahh I've seen what confused me now. I'm used to vim making backup files with a tilde. However, for some reason my terminal is showing tilde more like a dash [19:36] so the 'backup' files didn't look like normal vim backups to me [19:36] jelmer: Will do. Actually I'm using bzr.dev. [19:36] CaMason: so now you know kung-fu ;-) [19:36] bialix: oh yes >:) [19:37] great [19:37] rblasch, it will write status messages to ~/.bzr.log [19:40] jelmer: Yes, it looks like the same issue. "revprop list" counting down. [19:41] jelmer: It's just that I got 36k+ revisions, that's why it feels like it's taking forever. [19:42] rblasch, ah, k [19:45] jelmer: So it's already a known issue. Thanks for your time, and a whole lot more thanks for this brilliant plugin! [19:45] rblasch, np! [19:45] rblasch, Hopefully this will be fixed in 0.5.1 [19:46] \o/ [19:46] (One more beer for jelmer on Friday night :-) [19:48] jelmer: whats the correct way to get a diff of the workingtree? [19:49] "Lightweight checkout (format: 1.6 or 1.6.1-rich-root or 1.9 or 1.9-rich-root or dirstate or dirstate-tags or pack-0.92 or rich-root or rich-root-pack)" [19:49] http://paste.pocoo.org/show/102476/ <- see the diff method in line 148 for the current broken way :( [19:49] Wow, that's incredibly useful :-) [19:50] ronny, yikes, that *is* broken [19:50] ronny, you're trying to get the changes against the last committed revision here right? [19:50] jelmer: yeah [19:50] jelmer: im fixing javiers stuff :( [19:51] ronny, call show_diff_trees(self.wt.basis_tree(), self.wt, strdiff, specific_files=relpaths) [19:51] ronny: new_tree.branch.revision_history()[-2] will always be wrong, the last committed revision is (obviously) [-1] [19:52] jelmer: i noticed by accident that the diff was bewen tip and tip-1 [19:53] ronny, also, some other notes (while I'm looking at this code anyway): [19:53] ronny, wt.remove() can take a list of files, there's no need to iterate over all files [19:53] ronny, revert() seems right only in the case paths=None [19:54] ronny, is this for pida? [19:54] I've done 'bzr init-repo .; bzr branch lp:bkrpr bkrpr-trunk; <>; bzr branch bkrpr-trunk bkrpr-task-branch-foo; cd bkrpr-task-branch-foo; <>; bzr commit -m 'Finish my task.' " [19:54] Is 'bzr push lp:bkrpr' the right way to send my change to the upstream? [19:54] I'm reading '6.2.5 Merging a feature into the trunk' in the User's Guide, but I'm not 100% sure 'bzr push' is the right thing... [19:54] beuno: yeah [19:54] ronny, many bugs in the bzr integration? [19:55] it was less when i used subprocess [19:55] then i merged the work of someone else [19:55] now i do myself [19:55] and of course i lack unittests :( [19:55] ronny, I also don't think the converting to relative paths is necessary [19:56] jelmer: absolute paths is necessary, since i pass paths relative to the repo base, i have to reiterate a few time till its more nice [19:56] ronny, but there's no need to convert *back* to relative paths afaik, as is done in a few places [19:57] k [19:57] ronny, this is Javier Derderian's work? is it not good quality? [19:58] unfortunately it seems like this part of his work isnt good [20:00] ronny, I'm sorry to hear that :( [20:02] jelmer: hmm, is there a tool to do globing? [20:02] i think i could use that [20:03] ronny, not that I'm aware of, the shell takes care of that for us I think. There may be something in the win32-specific code [20:03] hmk [20:04] ronny, what would you need globbing for anyway, it seems like a bad thing to be part of a UI.. [20:04] eeuhm, API [20:05] jelmer: probably right, shell mindset sometimes is nasty [20:09] hmm === kiko is now known as kiko-afk [20:22]