[00:41] igc: lifeless is just my irc handle [01:15] beuno: I feel bad that everytime I follow your link it calls bzr garbage [01:16] jam, hahah, so do I :) [01:16] beuno: right now I'm getting a timeout trying to connect [01:16] is it down? [01:16] I tend to name stuff that will need deleting _garbage [01:16] I'm home [01:16] lemme get you the IP [01:17] http://200.127.6.219:8080/bazaar/bzr/changes [01:18] (remove the "garbage" bit, may also throw off googlebot) [01:18] :) [01:18] beuno: when I type "robert" it selects robert for a second, then a huge list of entries, and then goes back to robert [01:18] any idea why it "flickers" ? [01:19] beuno: also, it doesn't seem to match "collins" as it doesn't seem to be indexing the committer name [01:19] oh, and switching windows and switching back causes it to flicker again [01:19] hrm, it shouldn't [01:19] FF3? [01:20] yep [01:20] ah, yes. I know what's happening [01:21] I don't stop calls to the server when you type faster than 200ms per ketstroke [01:21] *keystroke [01:21] I also tried "Refactoring" as I see that in a commit message right away [01:21] and it doesn't find the rev [01:21] so you get delayed calls thrown at you [01:21] it's in my ToDo [01:22] actually, I haven't gotten a successful hit from any of the recent commit messages [01:22] Though it will put it in the helper list [01:22] interesting, I may of broken something [01:22] 'logic' worked [01:23] 'crude' did not [01:23] maybe you just need to regenerate it? [01:23] * beuno tries [01:24] well, running "bzr search Refactoring" from terminal works [01:25] is it case sensitive? [01:25] shouldn't be, no [01:30] ok, so I'm doing something wrong in my logic, bzr-search does sent me those results [01:39] whats up? [01:39] LH is failing at some point, and I don't quite understand why... [01:40] jam: the index is case sensitive for now - Foo vs foo in c++ is important [01:40] lifeless: sure, but it was still failing [01:40] I tried both forms [01:41] anyway, I'm done for the night [01:41] jam: yah, just letting you know the guts [01:41] yes, I'm getting back a list with sets instead of a list with strings [01:41] beuno: from search ? [01:43] it seems RevisionHit gives me a set, and FileTextHit a string, so I'm not showing RevisionHits [01:43] beuno: point me at your code [01:45] * beuno waits for LH to load in LP [01:45] lifeless, http://bazaar.launchpad.net/~beuno/loggerhead/bzr-search_integration/annotate/argentina%40gmail.com-20080620063154-mztu3hdo7t70l781?file_id=search.py-20080614235103-lpt63f7b2drplju8-1 [01:45] line 52 [01:45] I wonder how I managed to miss this up to now... [01:48] ah [01:48] needed a [0] [01:48] thanks for pointing it out jam :) [01:49] pushing the fix now.. [01:50] * Peng stares at bzr-svn. [01:51] bzr-svn stares back [01:51] :P === blueyed_ is now known as blueyed [01:51] It's complaining about my svn Python bindings. [01:51] beuno: well I was complaining about funky results ;P [01:52] man [01:52] linkedin is such a fanboyclubthing [01:52] lifeless, heh, right. Well, jam found the search term I could debug :P [01:53] * beuno has avoided linkedin up to now [01:54] anyway, search results seem coherent with the CLI [01:57] lifeless: you are the one who asked *me* to join... and now you say it is just fanboy. I feel... dirty [01:57] jam: :) [01:57] jam: You're not a acquaintance rather than trusted colleague/friend [01:57] jam: its folk I've met twice wanting to 'link up' than I was complaining about [01:58] beuno: cool [01:58] It is just that you are so amazing everyone wants to be your friend [01:58] And I thought I had ego problems [01:58] :) [01:59] If I can import svn.delta, why can't bzr-svn? [01:59] Oh. [02:00] Word of advice: don't go scattering things called "svn" around your PYTHONPATH. [02:02] :P [02:02] absolute imports ftw [02:04] That wouldn't help. bzr-svn tries to import svn.delta, but found my thing instead. [02:05] k [02:06] Oh well. The only damage done is a little wasted CPU and disk I/O. [02:06] Sorry for the interruption. :) [02:10] lol np === mw is now known as mw|out [02:41] * Verterok wonders why utf-8 isn't used by everyone... [02:45] Verterok: oh, I wish [02:46] lifeless: I have bundleBugggy running on mysql, but I have some problems with blob encodings :P [02:47] Verterok, really? didn't have to change any queries for it? [02:48] altright. I won't take that personal [02:49] (and type properly either) [02:49] sorry...pushed the wrong button :P [02:50] beuno: I think the problem is in the migration code, not in BB itself or it queries [02:50] ah, thought you already had it running [02:51] abentley did mention that encodings where really wierd and mixed up [02:51] yes, if I don't import the mergerequests from sqlite, it work like a charm :P [02:51] can't you convert it as you migrate? [02:51] indeed, they are [02:52] beuno: I don't know in what encoding is each blob...so I basically try:...catch: until it works :) [02:52] ah, sounds fun [02:53] try: except [02:53] * Verterok is writtin too much java code [02:53] * beuno is glad he passed that on [02:53] * Verterok too :) [02:58] beuno: something is wrong with the inserts in mysql, i get some warnings about data truncated... :( [02:59] Verterok, that's odd. Truncated for blobs? [02:59] yep.. [02:59] and came directly from MySQLdb module [03:00] hello [03:00] congrats for MySQL switching to Bazaar. [03:01] beuno: here is the traceback http://rafb.net/p/T5fBZX72.html [03:01] xif: hi, thanks [03:01] is there any way to implement a form of locking with bzr? [03:02] Verterok, very odd. On the other hand, we may be able to get help from mysql now :p [03:02] or generally, any way to make sure no more than one developer is working on a particular file? [03:03] beuno: that would be great, but first I want to be sure I'm not doing something wrong ;) [03:03] Verterok, I don't see where it's been truncated there, just an encoding error [03:04] oh, I wasn't clear... I get the truncate warnings when I'm running the migration script [03:05] beuno: sqlite2mysql.py:95: Warning: Data truncated for column 'text' at row 1 [03:05] Verterok, it may be worth a try changing that column's name [03:05] I suspect it may be a reserved name [03:05] so it could confuse mysql [03:06] xif: no, because you can have two independent branches [03:06] xif: imagine that there is only one file in your tree; two branches being independent implies concurrent editing of that file [03:06] beuno: yes, but that is the 2dn warning, the firstone is: sqlite2mysql.py:95: Warning: Data truncated for column 'patch_text' at row 1 [03:07] Verterok, ah, that throws my theory off the table :/ [03:07] Verterok, probably a mysql configuration [03:07] max_something [03:07] lifeless: hm, too bad. we're trying to manage some binaries here. merging never works for that, of course. so we simply must find a way to prevent - or at least alert - when someone tries to edit a file that somebody else is working on. [03:07] (not helpful, I know, finishing the bzr-upload [ANN]) [03:08] beuno: ok, i'll check [03:08] beuno: thanks [03:08] I'm not sure this can't be done (at least in a "cover 90% of the need" way) by a bazaar plugin.... [03:08] xif: if you had a single branch, a plugin could conceptually write a file describing advisory locks [03:09] xif: I suggest bringing it up on the list; may strike someone's interest. [03:09] lifeless: yeah, that's what I was thinking too. a master branch for the binaries. [03:09] thanks! [03:09] xif, maybe by having a similar file to .bzrignore [03:09] version that [03:09] make sure everyone pulls [03:09] and write a plugin on top of that [03:10] looks in that file, does magic [03:10] beuno: yeah, sort of what I was thinking... [03:10] that way you could have a lock with regexes! [03:10] "no one else touch my jpgs" [03:10] or something more professional [03:12] pre_commit hook that checks if that has been changed... [03:12] seems fairly possible, if someone puts some work into it [03:16] * xif nods [03:27] * beuno is off to the movies [03:31] enjoy! === cprov is now known as cprov-away [03:41] have fun beuno [03:51] is there a way to copy a file and have bzr recognize it as a copy? is there a copy command? [03:52] bzr cp [03:53] Bazaar (bzr) 1.5 [03:53] bzr: ERROR: unknown command "cp" [03:53] Nevermind, thought I used that today but I didn't... [03:55] jshaffer: not yet; its been discussed [03:55] ok. thanks [07:17] anyone know how to make bzr-svn work on remote SVN repositories that require authentication? I get an error: bzr: ERROR: Invalid http response for https://svn2.hosted-projects.com/Phoenix/PCP/branches/fxcm-3/.bzr/branch-format: Unable to handle http code 401: Authorization Required [07:18] you should be able to provide a username in the url and then get prompted for a password [07:19] ah, I found the problem: https://answers.launchpad.net/bzr-svn/+question/24177 [08:05] anyone looked at clearsilver ? [08:35] in bzr each branch has only one head, right? [08:38] yes, we define branch as being a head [08:38] you can have many heads in a repository, and many branches in a repository, repositories give you storage sharing across branches [09:04] lifeless: I see, but a branch is a head? [09:08] well, its an entry to the graph, it doesn't acctually have to be a head [09:18] lifeless: ah, perhaps we have different definitions of "head" [09:18] lifeless: by head I mean a node with no childs [09:19] yes, thats what head means [09:19] so, we have two separate objects involved [09:19] we have Branch, which has a 'tip', that points into the revision graph [09:20] the revision graph is stored in a Repository. An instance of Repository is one part of the distributed database [09:20] there is no requirement that the tip of a branch be a head in the distributed database (because that would be logically inconsistent with people being able to branch and commit without affecting the source branch) [09:21] but [09:21] we only include revisions reachable from the tip when we do log and other operations [09:22] so being a head in a graph sense really doesn't matter - it only matters for systems like git and hg that conflate branch storage with history storage [09:23] (For instance, I have a repository with 13000 heads; I can make a branch from it to a new project in 0.2 seconds or so) [09:24] lifeless: ah, true, being a head doesn't matter [09:24] lifeless: in that example you would only have one head in the new branch, right? [09:25] if I branched into an empty repository yes; the tip of the branch and what it references gets copied, which would leave the tip as the head (when you consider only the data in that repository) [09:27] lifeless: but why you say git and hg conflate branch storage with history storage? [09:27] well, its possibly more true for hg than git [09:28] in hg when you have 2 heads in its history storage, it shows up as have two branches [09:28] in git you have a list of 'heads' and 'refs' [09:29] AFAICT they won't scale to very large numbers of branches [09:29] (though it is very cheap to enumerate the branches because its in a single file) [09:30] felipec: anyhow, why were you asking whether we have more than one head per branch? [09:30] lifeless: in git a branch is just a pointer to a commit (a ref) [09:31] lifeless: I'm writing a document explaining why mtn sucks, and although I'm a git fan I want to show how things are dong in other decent DSCMs [09:31] s/dong/done/ [09:32] felipec: monotones management of divergence is a little awkard [09:32] lifeless: I think having multiple heads in a branch is chaos [09:32] so for bzr heads in teh repository is entirely unrelated to whats in a branch [09:33] a branch has a tip, which is a ref to a commit; same as git [09:33] branches also have tags, which themselves are ref's to commits [09:33] lifeless: tags are part of the branch or the repo? [09:34] felipec: each branch has its own tags; the point into the repo [09:34] s/the /they / [09:34] so, two branches can have a 1.0 tag, for example [09:34] right [09:35] a concrete use case would be a single repository storing project A and project B which is a fork of A [09:35] they may both have done 1.0 releases that are different code bases. [09:35] yeah, I get it [09:36] lifeless: by the way, do you know about any reference to the internal design of bzr? [09:36] but storage is shared between their history, and any merges as well [09:36] felipec: doc/developer/, the wiki has a Classes/ sub area [09:38] and there is all the docs in the code itself - docstrings [09:56] lifeless: I couldn't find much on doc/developer [09:57] http://doc.bazaar-vcs.org/bzr.dev/developers/index.html [10:47] lifeless: http://doc.bazaar-vcs.org/bzr.dev/developers/repository.html [10:48] lifeless: http://doc.bazaar-vcs.org/bzr.dev/developers/container-format.html [10:48] that's the most similar I can find to branch representation, but not really useful [10:50] felipec: obviously this is more work, but if you were to read the archive of this list over the last 18 months or so you'd find a fair amount of anecdotal information you could use towards your research. [10:50] pydoc bzrlib.branch/Branch [10:50] erm, bzrlib.branch.Branch, thats the Branch object [10:50] s/this/the Bazaar project's/ [10:52] felipec: that talks about the serialization of the packs in the repository [10:53] felipec: I guess it depends on what you mean by design [10:53] felipec: we are _very_ modular [10:53] felipec: as we learn better ways of doing things we implement them [10:54] felipec: so to us design really talks about responsibilities and layers, not about disk formats per se [10:54] felipec: (in part because svn can be considered an implementation detail of bzr due to how deep bzr-svn hooks in) [10:55] lifeless: I thought so, so there's no way I can for example create a test application independent of bzrlib to find all the branches in a repo? [10:55] without looking at the code of bzrlib [10:56] uh, [10:56] 'bzr branches' [10:56] but no, no more so than you can for git or hg [10:56] (I've looked at doing it independent of git's tools, and had to go to the code to get details) [10:58] it doesn't seem particularly useful to me to try to pin disk details down so that other folk can implement when the code is free; anyone that wants to know can read the /actual/ spec (not a poor proxy); also they can just use the code directly in the first place. [10:58] things like bzrlib.dirstate do offer EBNF descriptions of the file format [10:59] but this isn't intended for external reimplementation (though I know that DVCS for emacs actually used that to write a parser for the dirstate) [11:04] lifeless: I've tried to understand the repository format by looking at bzrlib but I couldn't, I guess I will have to try harder [11:09] I suppose different repository implementations have different formats. [11:09] {shrug} [11:11] felipec: pydoc bzrlib.repofmt.pack_repo [11:11] felipec: that should get you somewhere [11:13] felipec: with our current default repository format (the best performing one to date :)) [11:18] felipec: to all appearances the Bazaar hackers have worked very hard to give bzrlib a decent public face capable of manipulating arbitrary Bazaar branches, working trees, repositories etc. If you do speak Python then you'll probably do well to use bzrlib directly to ask the questions you have of a given branch. [11:42] I'm off, bbiab [12:57] does anybody know if pushing to a remote location triggers a post_pull hook at the remote location? [13:27] cdleary: if you are using a recent enough bzr, and bzr+ssh, it should I think; it will certainly trigger your local bzr's post_push hook locally with the remote location as the target parameter [13:32] lifeless: yeah, I was trying to avoid a push-and-update style hook, because I feel like the whole "ssh in after and clean up" thing is a little too hackish when there's a bzr instance running on the other end of the transport [13:33] I hear it works quite well [13:33] or you can look at bzr-upload I think it is; if you are deploying via bzr [13:35] ah that's a cool plugin, but I was thinking more about modifying bzr-email to send email after pushing to a "central" branch [13:36] well, my understanding is that that is available [13:36] but you need to be using bzr+ssh so that there is a bzr process on the other end [13:38] oh, it's already available? do you know if there's a recommended way to go about doing it, or do I switch bzr-email from a post_commit to post_pull hook like I thought? [13:38] beuno: ping [13:38] cdleary: you'll need to read the list archives and recent release notes I think [13:39] cdleary: it would be a post-push, not post-pull [13:39] cdleary: you are pushing after all [13:39] Jc2k: his midnight I think [13:39] Jc2k: argentinian [13:40] lifeless: thanks for the tips :) didn't know that post-push got triggered at both ends, and I'll go check out the lists [13:40] cdleary: I'm hazy on details, I know andrew bennets was working on this, and email was one of the primary use cases [13:40] sorry I can't be more useful :P [13:40] lifeless: yeah i thought he'd be asleep [13:41] well if I get a solution working that's not a total hack I'll be sure to propose a merge on launchpad ;) [13:41] but if it's already done then I'm golden [13:45] lifeless: (oh, and thanks for bzr-email :) [13:47] cdleary: my pleasure [14:35] Hi there! [14:35] Just wondering, what is the preferred way to set up Bazaar on the server to share a single push repo in a team of 5+ developers? [14:36] I mean I could do with bzr+ssh, but how about permissions for different projects, etc.? [14:58] http://pastey.net/89808 [14:59] The part that isn't working is straight out of the guide [15:00] I'm not sure, but I think install_named_hook may be pretty new. Maybe your bzr is too old. [15:00] Also, ew, complicated os.system(). [15:02] Also, isn't it executing Ruby code that only executes something else and does a trivial check on the output? Python can handle that... [15:02] yeah, I'm sure with a little effort I could easily convert it to python, but I don't really know python [15:40] matid: what do you mean by "single push"? [15:40] I should say a common push repository. [15:40] So that all devs can push to it. [15:42] matid: Well if you've only got ~5 people I'm not terribly sure what you need permission barriers for, but regardless, standard unix permissions apply. If they own the repository (ie, the .bzr/repository) directory at . or .. then they can push to it. [15:42] etc [15:42] If you want them to be able to push to each others', then I'd suggest they all be in a "bzr" group or something and make the directories appropriately sticky and/or umasked. [15:45] OK, I think I found what I was looking for... [15:45] I had the directory chmoded 02770 but it wasn't enough to make the permissions work as I wanted them to work. [15:45] I had to add a shell script to change umask before running bzr. [16:06] teratorn, see the bzr-svn FAQ [16:21] jelmer: Hi. You're the maintainer of bzr-svn, right? [16:21] matid, yep [16:21] jelmer: A quick question: which version of bzr is best suited for bzr-svn as of now? [16:21] matid: Depends on the version of bzr-svn you're using [16:22] Hi guys! when is bzr 1.6 coming out? [16:22] matid: There's a list on the wiki [16:23] jelmer: I currently use bzr 1.3.1 with bzr-svn 0.4.9 [16:23] jelmer: I wanted to upgrade bzr and I was wondering if it's going to break bzr-svn or not. [16:23] matid: Yes, you'd have to upgrade bzr-svn as well [16:24] jelmer: how about my question? :-D [16:24] jelmer: Does bzr-svn work with 1.6 or it's 1.5 only? [16:24] antoranz, Sorry, I don't know what the release plans for 1.6 are [16:24] k [16:25] matid: 1.6 isn't out yet [16:25] I saw 1.6 beta 2 was released almost 2 weeks ago. how did it go? [16:25] jelmer: I should go with 1.5 and newest bzr-svn then, right/ [16:25] ? [16:26] matid: I guess so. [16:26] matid: Yes, 0.4.10 [16:28] what repository for gutsy and hardy) do I have to enable to get the beta? [16:29] or it has to be done by hand? [16:33] I think you can only get it from the source tarball [16:34] jelmer: What version of svn should I get to have bzr-svn working? [16:34] jelmer: I upgraded bzr and bzr-svn and now I get this error: http://pastie.org/219489 [16:35] jelmer: That's after I try bzr pull on an svn branch I used to use with bzr 1.3.1 and bzr-svn 0.4.9 [16:35] matid: That's an issue with 0.4.10 and Subversion 1.5 [16:35] I think there's an open bug about it [16:36] jelmer: What should I do then? [16:36] matid: Use Subversion 1.4, comment out that particular assert in Subversion 1.5 or stay with bzr-svn 0.4.9 for now [16:38] OK... I added the repositories for betas and release candidates [16:38] Commenting this assert out and recompiling subversion should do the trick, right? [16:38] matid, yep [16:38] but now bzr is kept from updating [16:45] jelmer: Thanks! That fixed the issue. [16:46] antoranz, how do you mean? [16:50] beuno, ping [16:54] http://www.pastebin.ca/1052494 [17:09] you probably have some plugin installed that can't be upgraded [17:09] but relies on the version of bzr you have currently installed [17:31] let me see [17:34] the problem is the version of python-central [17:35] bzr: Depends: python-central (>= 0.6.5) but 0.5.15ubuntu2 is to be installed [17:35] any ideas? [18:37] lo all [18:38] i have a launchpad question, just grabbing a link.. [18:38] so... [18:38] jelmer created https://code.edge.launchpad.net/~gnome-bzr-mirror [18:39] which is awesome [18:39] does launchpad use shared repositories? [18:40] i.e. by the simple fact that bzr-mirror.gnome.org is getting mirrored by launchpad, do personal branches become really cheap? [18:40] * Jc2k goes to test [18:40] No. [18:40] ah [18:41] * fullermd dashes hopes in only 2 letters! [18:41] that would have been wicked levels of cool === awilkins_ is now known as awilkins [19:02] Hi, I'm still unable to run bzr from the bzr branch, since when I do ./bzr, it still uses the bzrlib from /usr/lib, that means the old one which was installed on the system [19:03] I have this problem each time I want to run a Python program without installing it... [19:03] clemente: you need to modify your PYTHONPATH envvar [19:04] Verterok: however that doesn't work. I tried: PYTHONPATH=/w/bzr.dev/ /w/bzr.dev/bzr fast-import ...... [19:04] And I still get in „plugins“: bzrtools /usr/lib/python2.5/site-packages/bzrlib/plugins/bzrtools [19:05] clemente: couldd you paste the output of YTHONPATH=/w/bzr.dev/ /w/bzr.dev/bzr version [19:05] Bazaar (bzr) 1.6b3 [19:05] The problem is not with the bzr executable but with bzrlib [19:08] clemente: it's clearly a pythonpath issue, for some reason python is looking first in /usr/lib [19:09] clemente: something is overriding your pythonpath :( [19:10] Ok, thanks, I will search the cause [19:11] clemente: sorry I can give you more help with this issue [20:09] is there any way to convert a rich-root-pack repo into a pack-0.98 [20:09] ? [20:12] create a brand new repo as pack-0.98 and pull from the old one to the new one? [20:13] tro: No, that's not possible [20:13] (I think you mean pack-0.92, btw) [20:18] right. 0.92 [20:18] looks like this branch i'm working with was imported using bzr-svn [20:18] i guess it uses rich-root-pack by default? [20:18] tro: Yep [20:19] tro: rich-root-pack will hopefully become the defualt format in bzr 1.6 [20:19] hmm ... so how will people upgrade from pack-0.92? [20:21] "bzr upgrade --rich-root-pack" will upgrade a branch [20:23] does the same go for shared repos? i'm setting one up right now [20:37] tro: yep [20:38] tro: You can also create a rrp one using "bzr init-repo --rich-root-pack" (saves you an upgrade) [20:38] jelmer: so if i run that command on a shared-repo, will all the branches it hosts be converted as well? [20:39] tro: yes [20:39] neat [20:39] thanks [21:15] Hey guys, is there an alternative to "darcs amend-record" ?? [21:16] If you don't know what it means well it will record new changes under the old revision.. [21:16] Add to it not replace it [22:40] eMxyzptlk: no there is not, because in a distributed database a revision id needs to have a single unique value [22:40] lifeless, ah ok [22:41] eMxyzptlk: however, you can for the mst recent commit do 'bzr uncommit; bzr commit' to pop off the last commit and then make a new one [22:41] lifeless, thanks anyway :) [22:41] lifeless, yea that's what I am actually doing right now [22:42] lifeless, but it would be nice to create something that does this ( maybe a plugin ), it saves me time copying/pasting the log of the commit [23:03] * Verterok dances [23:03] BB now runs on mysql :D [23:18] Verterok: cool [23:18] beuno: hi [23:18] hi, lifeless [23:19] I finally won the encodings battle :P [23:19] hey lifeless [23:19] Verterok, oh, yay! does that mean BB working with MySQL? [23:19] beuno: yep :D [23:19] oh, very cool [23:20] is it reproducable? the migration I mean [23:20] http://steppenwolf.selfip.net:8089 [23:20] beuno: it should, I'm writting the README ATM [23:21] Verterok, push to LP, mail the list! ;) [23:22] beuno: there is only one unresolved issue, that odd warning about "data truncated" in a blob :P [23:23] I'll push to LP as soon I finish the docs.. [23:23] Verterok, ah. Have you mean able to track down if it actually removes data or not? [23:24] not yet, I focued on fighting against encoding errors :) [23:24] beuno: next iteration is to track down the warning [23:25] Verterok, congrats! [23:25] thx beuno [23:26] Well, blob/text only store 65k... bundles can get bigger than that fairly commonly. [23:26] lo beuno [23:26] You can get 16 meg in a mediumblob, which is probably enough. But might as well just go to the 4 gig in longblob. [23:27] jelmer: around? [23:27] lifeless, jup [23:27] fullermd: thanks for the tip [23:27] beuno: have you show jelmer loggerhead-super-search? [23:27] * Verterok cheking what kind of blob is using [23:28] lifeless, I don't think so... [23:28] jelmer, http://200.127.6.219:8080/bazaar/bzr/changes [23:28] beuno: got time to run up your demo ? [23:29] lifeless, I left it up. Googlebot keeps trying revids :p [23:29] hey Jc2k [23:29] * Verterok waves fullermd (0 warnings) [23:29] :) [23:29] fullermd: thanks!! it worked like a charm [23:29] jelmer: go to that url, and type into the search box [23:30] * fullermd has his uses 8-} [23:30] Jc2k, did you get my ping yesterday? [23:31]