| Noldorin | do bzr branches maintain soft links? | 00:13 |
|---|---|---|
| jelmer | Noldorin, bzr can version sym links | 00:35 |
| Noldorin | jelmer, symbolic links = soft links no? | 00:50 |
| jelmer | Noldorin, yes | 00:51 |
| Noldorin | ok | 00:51 |
| Noldorin | cool | 00:51 |
| Noldorin | jelmer, btw how is bzr-svn these days? does it work with codeplex servers yet? | 00:52 |
| Noldorin | or bzr-tfs even | 00:52 |
| jelmer | Noldorin, bzr-svn doesn't work with codeplex servers; codeplex servers aren't real svn servers, and they provide inconsistent data | 00:53 |
| Noldorin | so it seems yeah | 00:53 |
| Noldorin | jelmer, how about tfS? | 00:53 |
| jelmer | Noldorin, it seems unlikely bzr-svn will ever work with codeplex servers until the server side is fixed | 00:53 |
| Noldorin | they probably hacked SVN to work with TFS over there | 00:53 |
| Noldorin | so maybe never :-( | 00:54 |
| jelmer | bzr-tfs would be a better candidate, but I haven't seen much movement on it recently | 00:54 |
| Noldorin | yeah, nor have i it seems | 00:54 |
| Noldorin | oh well | 00:54 |
| Noldorin | cheers for the update. | 00:54 |
| jelmer | sorry I can't give you better news | 00:54 |
| jelmer | it'd be interesting to see a bzr-tfs happen | 00:54 |
| Noldorin_ | jelmer, no worries. yeah, i check bzr-tfs regularly and will probably continue. nothing exciting there yet though | 01:38 |
| BlindWolf8 | Hey spiv | 02:39 |
| bignose | I need to “cherry-pick” the removal of a specific change a while ago on a branch. | 02:58 |
| bignose | (temporarily, to demonstrate a failure for a regression test) | 02:58 |
| lifeless | merge . -r x..x-1 | 02:58 |
| bignose | would that involve some funky ‘--revision’ spec? | 02:58 |
| bignose | ah yes | 02:59 |
| bignose | hmm. the revision I'm interested in targeting is from a merge. | 03:00 |
| bignose | can I say ‘1658.1.1575..before:1658.1.1575’? | 03:00 |
| bignose | would that be equivalent? | 03:00 |
| lifeless | bignose: it will take the left hand side of that | 03:03 |
| lifeless | but yes, should do what you want | 03:03 |
| === BasicPRO is now known as BasicOSX | ||
| === hunger_ is now known as hunger | ||
| === hunger is now known as hunger__ | ||
| === hunger__ is now known as hunger | ||
| === BasicPRO is now known as BasicOSX | ||
| Lo-lan-do | Hi all :-) | 09:39 |
| Lo-lan-do | I'd like to gently poke jelmer (or anyone) about #628973… | 09:40 |
| jelmer | bug 628973 ? | 09:40 |
| ubot5 | Launchpad bug 628973 in Nikki and the Robots "FEATURE: move camera in terminal OEM" [High,Fix released] https://launchpad.net/bugs/628973 | 09:40 |
| Lo-lan-do | Nah, the other 628973, http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=628973 | 09:40 |
| ubot5 | Debian bug 628973 in bzr-svn "bzr-svn uninstallable in unstable" [Grave,Open] | 09:40 |
| jelmer | :) | 09:40 |
| jelmer | Lo-lan-do, there is a weird bug in subvertpy/libapr that's preventing uploads of bzr-svn at the moment | 09:42 |
| jelmer | launchpad bug 803353 | 09:42 |
| ubot5 | Launchpad bug 803353 in subvertpy "segfault during iconv close from ra cleanup" [High,Triaged] https://launchpad.net/bugs/803353 | 09:42 |
| Lo-lan-do | Ah. Okay. I'll mark the packages as on hold in my aptitude, then. | 09:43 |
| Lo-lan-do | Thanks for the info. | 09:43 |
| * jelmer comments o nthe debian bug | 09:44 | |
| maxb | jelmer: Oh, also, bzr-pipeline needs an update too, though there's no bug about that. I was thinking of doing a snapshot merge into the alioth branch and asking you to sponsor, if that's ok? | 09:44 |
| jelmer | maxb: sure, happy to | 09:45 |
| maxb | Just checking I wasn't going to duplicate work :-) | 09:46 |
| maxb | Ok, I'll have something pushed by tomorrow | 09:46 |
| jelmer | maxb: thanks for checking. I should probably do that more too | 09:54 |
| jelmer | I think we should get the commit email notifications back up for alioth | 09:54 |
| __yhvh__ | hey so is there a way to revert files modified like (properties changed: -x to +x) ? | 09:58 |
| __yhvh__ | I even tried feeding the list through xargs chmod but not happening | 10:01 |
| jelmer | __yhvh__, revert should also revert property changes | 10:01 |
| __yhvh__ | yeah I imagine it should but it doesn't seem to work, the files end with * is that significant? | 10:02 |
| __yhvh__ | to be clear the list of modified files all get appended * | 10:03 |
| jelmer | __yhvh__, that * indicates they have changed properties | 10:03 |
| __yhvh__ | yeah I really don't know what's happening here, bzr revert lists all the files with changed permissions, does the resolution passes, no effect | 10:09 |
| __yhvh__ | it did revert an actual edit I made | 10:09 |
| jelmer | __yhvh__: what platform are you on? Does "bzr st" still list the reverted files as modified? | 10:16 |
| __yhvh__ | fedora 15, and yes it does | 10:17 |
| __yhvh__ | bzr 2.3.3 | 10:17 |
| jelmer | are you specifying any arguments to revert? | 10:17 |
| __yhvh__ | no | 10:17 |
| jelmer | __yhvh__: that definitely sounds like a bug (but a quite unusual one) | 10:19 |
| __yhvh__ | might just be me being dumb, chmod -x file fails silently | 10:19 |
| jelmer | oh, interesting - is this on a vfat fs perhaps? | 10:19 |
| poolie | hi all | 10:20 |
| jelmer | 'morning poolie | 10:20 |
| __yhvh__ | fuseblk | 10:20 |
| jelmer | __yhvh__, it sounds like a file system bug if it's silently ignoring requests to change the mode; it should set some sort of error (ENOSYS?) | 10:22 |
| __yhvh__ | jelmer: yup touched a new file and it's created a+x | 10:25 |
| __yhvh__ | sorry for noise and thanks | 10:25 |
| poolie | hi all | 12:56 |
| brad_ | does bazaar have anything like hg update null? | 13:23 |
| LeoNerd | Maybe? But since most of us in here probably don't use hg we're unlikely to know what that is. Could you describe it generally? | 13:26 |
| brad_ | it basically is a state of the working directory that precedes the first revision, so the working directory has no files checked out | 13:27 |
| LeoNerd | Oh.. Hmm.. | 13:28 |
| LeoNerd | Well, you can blow away the checkout, and leave only the branch. Is that what you're after/ | 13:28 |
| brad_ | sort of | 13:28 |
| brad_ | but I want an easy way to get it to the state from any other state | 13:28 |
| brad_ | so in mercurial, it is just hg update null | 13:28 |
| LeoNerd | I believe it's bzr zap | 13:29 |
| LeoNerd | To remove the checkout | 13:29 |
| brad_ | let me try that | 13:29 |
| fullermd | remove-tree | 13:29 |
| brad_ | that worked | 13:30 |
| brad_ | remove-tree | 13:30 |
| brad_ | what do I do to get the tree back, since update doesn't seem to be working | 13:30 |
| LeoNerd | bzr checkout | 13:30 |
| fullermd | checkout | 13:30 |
| brad_ | thanks | 13:30 |
| brad_ | I see the help mentions that | 13:30 |
| brad_ | my bad | 13:30 |
| brad_ | very nice | 13:30 |
| brad_ | ok, that seems to be essentially what I was looking for | 13:31 |
| brad_ | does bzr have plugins out of the box for doing a clone of a subversion repository? | 13:31 |
| maxb | Most definitely | 13:31 |
| LeoNerd | Depends what "box" you mean :) | 13:31 |
| brad_ | hehehe | 13:31 |
| brad_ | well, from the official release on the website | 13:31 |
| LeoNerd | There's bzr-svn which is available in Debian/Ubuntu/.. probably others.. I don't think it's corecore though... | 13:32 |
| brad_ | mercurial at least has a convert plugin included that does a convert, but it isn't exactly a clone | 13:32 |
| LeoNerd | bzr-svn lets you branch from svn, or just use the bzr tool as an svn client; so your workdir can either be a bzr branch/checkout or svn | 13:32 |
| LeoNerd | Depends what you're wanting | 13:32 |
| brad_ | yeah, I want to clone it, and be able to pull down changes, push changes back up | 13:32 |
| brad_ | basically, have bzr act like a svn client | 13:33 |
| brad_ | I was able to do that in mercurial with hgsubversion | 13:33 |
| brad_ | but it seems a bit buggy | 13:33 |
| brad_ | so trying to find the version control I feel most comfortable with, and which one makes the process as effortless as possible to setup. | 13:33 |
| LeoNerd | So, your question still seems a bit mixed. These are two different use-cases... | 13:35 |
| LeoNerd | 1. Branching a native bzr branch off a svn repo, working on it natively in bzr, then pushing it back. 2. Using the bzr commandline tool as a client for your svn checkout workdir. | 13:35 |
| brad_ | well, 1 I think it what I want primarily | 13:36 |
| brad_ | I don't need bzr to work from an svn checkout | 13:36 |
| LeoNerd | Ahrighty. Yes; that's the common use-case.. but I just wanted to clear up the question to be sure :) | 13:37 |
| brad_ | I just want to be sure that I can pull down changes from svn as other people commit stuff, and be sure that I could push stuff back to svn if I have something I'd want/need to commit | 13:37 |
| brad_ | so I just need the bzr-svn plugin? | 13:38 |
| LeoNerd | Should do, yup | 13:45 |
| LeoNerd | Admittedly a year since I last used it, but that's how it worked when I did | 13:45 |
| LeoNerd | maxb: How is that going, by the way? Are your bzr-related evangelisms getting anywhere? | 13:45 |
| maxb | Hah, at MX you mean? | 13:46 |
| maxb | Mainly stalled on lack of a true need for a DVCS given current development practices | 13:46 |
| poolie | hi maxb, lenerd | 13:49 |
| poolie | *leonerd | 13:49 |
| LeoNerd | Ahyes.. | 13:51 |
| thumper | poolie: if I use set_append_revisions_only(true) on a remote branch (i.e. LP) will it do the right thing? | 14:04 |
| poolie | it should | 14:05 |
| thumper | cool | 14:05 |
| Red15 | How does one remove all traces of a branch inside a shared repo ? | 14:46 |
| Red15 | i'm having difficulty (those who were here yesterday might recall) | 14:46 |
| Red15 | commiting, because the commit is quite large and bzr is souping up all the memory available in the server | 14:46 |
| Red15 | finally the kernel kicks in and kills the process | 14:47 |
| jelmer | Red15, the easiest way is to create a new repository and clone all branches you do not want to remove into that | 14:48 |
| Red15 | ouch ... | 14:48 |
| Red15 | sounds like quite the hassle | 14:48 |
| Red15 | do shared-repositories complain when you move then around or do they not care for their parent directory ? | 14:49 |
| briandealwis | Red15: as I understand it, shared repos are self contained — it's the branches that are contained under the repo that are position sensitive. So as long as you move the shared repo further up (towards the root), you'll be ok — providing there isn't a shared repo there already | 15:01 |
| Red15 | ok, that's what i figured thanks for confirming briandealwis | 15:01 |
| Red15 | am noticing shared-repos are quite bad for bzr memory usage | 15:01 |
| briandealwis | Red15: how so? A standalone branch has a repo too — it's just not shared (bar lightweight checkouts) | 15:03 |
| Red15 | i was maintaining a big-shared-repo for our company | 15:03 |
| Red15 | but the hosted server has ~1gb of ram | 15:03 |
| Red15 | the total dirsize of the shared repo is ~1gb | 15:04 |
| Red15 | when committing the bzr smart server process uses all the memory in the server causing kernel-oom-measures to fire | 15:04 |
| briandealwis | Red15: I wonder if you're hitting a repacking threshold. | 15:05 |
| Red15 | briandealwis, how can i tell? | 15:05 |
| briandealwis | I've just hit one myself with one branch, and it's painful | 15:05 |
| briandealwis | Red15: look at the logs | 15:05 |
| Red15 | this was on server side : http://paste.ubuntu.com/635054/ | 15:06 |
| briandealwis | You'll need to look before that. Mine has sometime like "648.407 Auto-packing repository GCRepositoryPackCollection(CHKInventoryReposito | 15:07 |
| briandealwis | ry('file:///Users/bsd/Manumitting/Projects/e4/.bzr/repository/')), which has 28 | 15:07 |
| briandealwis | pack files, containing 28102 revisions. Packing 21 files into 1 affecting 21102" | 15:07 |
| briandealwis | Red15: but it sounds like you could really benefit from adding some more RAM to your server | 15:07 |
| Red15 | this one is today : http://paste.ubuntu.com/635806/ | 15:07 |
| briandealwis | But that didn't fail, right? | 15:08 |
| Red15 | actually nvm that one | 15:08 |
| Red15 | http://paste.ubuntu.com/635807/ that one failed | 15:09 |
| briandealwis | Red15: that one is definitely repacking. I wonder if there's a way to avoid repacking — it's an optimization, not a requirement, as I understand it. | 15:10 |
| Red15 | https://bugs.launchpad.net/bzr/+bug/184237 | 15:11 |
| ubot5 | Ubuntu bug 184237 in Bazaar "autopacking should be optional" [Undecided,Invalid] | 15:11 |
| Red15 | or this one : https://bugs.launchpad.net/bzr/+bug/736001 | 15:11 |
| ubot5 | Ubuntu bug 736001 in Bazaar "Re-packing happens at inconvenient times and blocks further operations" [Medium,Confirmed] | 15:11 |
| briandealwis | Red15: I've installed John's bzr-prompt-repack plugin; you could adapt it for your server to always skip repacks on your server, and schedule a repack for the evenings (once you've added more memory) | 15:29 |
| Red15 | for now i've decided to not use shared repo's anymore and i think that should steer clear of the problem for now | 15:29 |
| mgz | ah, jml just proposed his bug 660852 branch | 16:34 |
| ubot5 | Launchpad bug 660852 in testtools "text failure report is too gassy" [Wishlist,In progress] https://launchpad.net/bugs/660852 | 16:34 |
| jml | yes what? | 16:34 |
| jml | mgz: please play with it. Am interested in feedback. | 16:34 |
| jml | (also, interested in better ways to code it) | 16:35 |
| mgz | I saw a few nits looking at an earlier iteration, will review and see if there's anything still needing sorting if you like | 16:36 |
| mgz | the general plan looked good. | 16:36 |
| mgz | okay, so, you have u"" literals in tests, python 3 gets sad at them. | 16:37 |
| jml | mgz: oops. sorry. | 16:40 |
| * jml really needs to tweak 'make check' to run with all local Pythons | 16:41 | |
| mgz | also, using doctestmatches with unicode is asking for pain. | 16:41 |
| jml | yeah, there's a bug about that isn't there | 16:41 |
| mgz | there's a bug against testtools I've got a branch for, but also, | 16:41 |
| mgz | doctest screws us majorly on that front | 16:41 |
| mgz | because inside an innocently named `_indent` function, they encode to whatever the sys.stdout encoding is | 16:42 |
| jml | mgz: ok. I'll stick with Equals. | 16:42 |
| mgz | which... clearly is no good for testtools/subunit passing things cross process | 16:42 |
| jml | mgz: once this patch is ok, I want to resurrect your tb stack frame patch | 16:42 |
| jml | but I guess a bunch of other bugs ought to get fixed first. | 16:43 |
| mgz | yup, we need to find a near(ish) way of doing that. | 16:43 |
| mgz | *neat | 16:43 |
| jml | mgz: as far as I'm concerned, we can use __unittest and make sure that testtools' own runner re-sets __unittest to False. | 16:43 |
| mgz | sticking __unittest = True at the top of all modules is ugly, but adding our own _is_relevant_tb_level would work too | 16:44 |
| mgz | the changes to _details_to_str look sensible to me. | 16:47 |
| mgz | I wonder if it shouldn't become a public api, or some part of it. bzrlib doesn't want to stay doing str(_StringException) forever and needs to have some means to show the test information during the run. | 16:49 |
| === beuno is now known as beuno-lunch | ||
| jml | mgz: hmm. interesting thought re details_to_str becoming public. | 16:52 |
| jml | mgz: I've pushed up changes to make tests pass with Python 3 | 16:53 |
| mgz | that all looks good. removing the underscore can probably wait till I find whether I need to delve into privates for bzr. | 16:56 |
| jml | mgz: poolie was just trying my branch w/ bzr. The traceback still comes up in curly braces. I'm not sure why that's the case. | 17:00 |
| jml | (I don't really know much about bzrlib.tests any more0 | 17:00 |
| mgz | yeah, that's the traceback-1 stuff probably | 17:00 |
| poolie | jml, i put an example failure on the bug | 17:01 |
| mgz | remember spiv hacking around a test duplication issue where each test grew a new traceback every time an instance of it failed? | 17:01 |
| poolie | o/ mgz | 17:01 |
| jml | mgz: ? it says 'traceback', not 'traceback-1' | 17:01 |
| mgz | hm. wrong guess then. | 17:01 |
| spiv | mgz: yeah, I'm pretty sure I fixed that issue | 17:02 |
| mgz | jml: _details_to_exc_info needs changing to mkae bzrlib work | 17:06 |
| jml | mgz: ah, I see. | 17:07 |
| jml | mgz: I have to say, I don't really understand what the purpose of the code path is, why things would go down it | 17:08 |
| mgz | I'm a little worried about 'reason' vs 'traceback' too, I don't quite see where that'll be handled | 17:08 |
| mgz | as in, skip vs error | 17:08 |
| jml | except TypeError: | 17:08 |
| jml | # have to convert | 17:08 |
| mgz | ^it's confusing, basically, it's the compat with the unittest api | 17:09 |
| mgz | which deals in exc_info not details dicts | 17:09 |
| jml | so it catches the decorated thing not understanding the details kwarg? | 17:11 |
| mgz | yup. | 17:11 |
| jml | and what about this bit: | 17:12 |
| jml | # extract the reason if it's available | 17:12 |
| jml | try: | 17:12 |
| jml | reason = ''.join(details['reason'].iter_text()) | 17:12 |
| jml | except KeyError: | 17:12 |
| jml | reason = _details_to_str(details) | 17:12 |
| jml | I mean, I don't see how that squares with your reason vs traceback worries. | 17:12 |
| mgz | ah, that's me answering my own question | 17:12 |
| jml | :) | 17:12 |
| mgz | hey, spiv and poolie were both awake... aus has migrated to the northern hemisphere? | 17:13 |
| jml | mgz: Canonical hack-a-thon in Dublin. | 17:15 |
| mgz | aha. | 17:16 |
| === beuno-lunch is now known as beuno | ||
| poolie | thanks for looking at the subunit unicode bug | 17:54 |
| jamdahl | Hi, I'm having a problem with directories when using bzr through the command line | 18:00 |
| jamdahl | I run the command \ | 18:01 |
| jamdahl | bzr init "C:\Users\jamdahl\Documents\New folder (2)\" | 18:01 |
| jamdahl | and it says the directory does not exist | 18:02 |
| mgz | jamdahl: what does `mkdir "C:\Users\jamdahl\Documents\New folder (2)\"` say? | 18:03 |
| jamdahl | it says it already exits | 18:04 |
| jamdahl | Ah, I found the problem, it's the \ at the end | 18:05 |
| mgz | okay, then try removing th... | 18:06 |
| mgz | you got there first :) | 18:06 |
| mgz | file a bug. | 18:06 |
| mgz | your command line was wrong, and bzr does tell you how, but could be clearer | 18:08 |
| jml | mgz: can you please take a look at https://code.launchpad.net/~jml/testtools/doctest-unicode-safety-672056/+merge/66500 | 18:14 |
| mgz | jml: that's not enough unfortunately. | 18:19 |
| jml | mgz: oh? | 18:19 |
| MadGirl | well, oh is that all? | 18:19 |
| mgz | is DocTestMatches designed to take arbitrary objects and stringify them though? | 18:20 |
| jml | mgz: it does make the test pass :) | 18:20 |
| mgz | jml: printing the output also gets messed up | 18:20 |
| mgz | I need to leave in a sec but I'll see if I can throw my branch up somewhere for you to look at | 18:20 |
| jml | mgz: ok, thanks. | 18:20 |
| mgz | jml: see lp:~gz/testtools/unicode_doctestmatches_764170 | 18:27 |
| jml | mgz: thanks. | 18:27 |
| mgz | there are... all kinds of annoying interactions here with different python versions | 18:28 |
| jml | mgz: yeah. | 18:28 |
| mgz | I'm not sure the bug you duped against was the same thing either, will look at when I get back. | 18:28 |
| jml | mgz: I'm wondering whether it's acceptable to just mangle output | 18:29 |
| jml | mgz: as the least of all evils. | 18:29 |
| mgz | yeah, that sometimes happens currently, and it's better than breaking entirely (which that branch does currently on 2.6) | 18:29 |
| mgz | okay, I'm gone. | 18:30 |
| Noldorin_ | jelmer, hello, you around? | 18:37 |
| jelmer | Noldorin_, hey | 18:38 |
| Noldorin_ | jelmer, yesterday you told me bzr supports symlinks...does it support them on windows though? | 18:38 |
| jelmer | Noldorin_, no, it doesn't support them on Windows (how would it?) | 18:38 |
| Noldorin_ | well Windows does have symlinks... | 18:38 |
| Noldorin_ | they just require admin rights to create :-S | 18:38 |
| Noldorin_ | jelmer, guess it still doesn't support them though | 18:42 |
| jelmer | Noldorin_: yeah, bzr doesn't create them - we should probably just not be creating any files in disk but remembering the existing symlinks that are already in the tree | 18:43 |
| Noldorin_ | jelmer, yes that would probably be a good idea. | 18:44 |
| Noldorin_ | what's the easiest way to get the tag of a certain revision? | 19:00 |
| LarstiQ | mgz: here by chance? | 19:14 |
| LarstiQ | the behaviour on 803796 seems to be weird, or I'm doing something rather wrong | 19:17 |
| mgz | LarstiQ: it is weird, but with the latest bzr you should get a neat error message rather than a traceback, if you could confirm that | 20:40 |
| LarstiQ | mgz: "Tree is up to date at revision 0 of branch /tmp/bzr" | 20:40 |
| mgz | hm, that's not as useful as I thought it'd be. | 20:41 |
| LarstiQ | mgz: I filed bug 804037 about the weirdness I ran into | 20:41 |
| ubot5 | Launchpad bug 804037 in Bazaar "bzr branch -r 0 downloads more than expected" [Medium,Confirmed] https://launchpad.net/bugs/804037 | 20:41 |
| * LarstiQ didn't dig very deep | 20:42 | |
| LarstiQ | so could be wildly off, but I'm suspecting a null: vs None conversion problem | 20:42 |
| mgz | blast, riddell's branch isn't linked from bug 242175 | 20:42 |
| ubot5 | Launchpad bug 242175 in Bazaar "Better error message when merging into empty branch" [High,Fix released] https://launchpad.net/bugs/242175 | 20:42 |
| mgz | https://code.launchpad.net/~jr/bzr/242175-empty-branch-merge/+merge/61152 | 20:43 |
| mgz | okay, so somehow we're not hitting that error message codepath, but also not getting the old traceback | 20:44 |
| mgz | or do you get it when you run `bzr update` in your -r 0 branch? | 20:47 |
| LarstiQ | mgz: that message is `bzr update` in my -r0 branch | 20:50 |
| * LarstiQ doesn't get a traceback | 20:50 | |
| mgz | okay, so that part is okay then, it's just the transfer that I agree is suprising. | 20:51 |
| Noldorin_ | how cna i find out which revisions in a branch have tags and what they are? | 20:52 |
| mgz | `bzr tags`? | 20:53 |
| Noldorin_ | mgz, oh dear, how did i miss that! thank you | 20:54 |
| === yofel_ is now known as yofel | ||
| timrc | I'm getting http://pastebin.ubuntu.com/636053/ when I create (bzr init) a new tree and then push it to an existing project... any idea how I can rectify this? Appears to be some sort of compatibility issue... | 23:43 |
| jelmer | timrc, your branch is in a bzr format with more capabilities than the format the default development branch is in | 23:43 |
| timrc | jelmer, it throws an exception in Python, but is it actually problematic? | 23:44 |
| jelmer | timrc: the development branch appears to be in an old format, so you might want to upgrade it to the current format unless it needs to be accessible by hardy bzr | 23:44 |
| jelmer | timrc: IIRC it doesn't actually push any data if it gives this error | 23:45 |
| === medberry is now known as med_out | ||
| timrc | jelmer, thanks for the assistance :) | 23:53 |
Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!