| poolie | more seriously i think it will create more of an impression that this is actually something that's going to happen as an ongoing custom | 00:00 |
|---|---|---|
| poolie | not just you randomly doing reviews | 00:00 |
| dOxxx | poolie: just read your reply about outf and the UIFactory stuff | 00:01 |
| poolie | i'll put up the branches soon | 00:01 |
| poolie | that'd be better than describing them | 00:01 |
| dOxxx | poolie: cool. code is good :) | 00:01 |
| dOxxx | I think once I've adapted my changes to the updated UIFactory, I'm definitely going to need a review of what should be going through the normal message methods vs make_output_stream. Some of it is obvious like diff and log, but for others it's more of a grey area. | 00:03 |
| dOxxx | do the blackbox tests run out-of-process? | 00:04 |
| lifeless | dOxxx: some do | 00:06 |
| lifeless | dOxxx: most don't, too slow. | 00:06 |
| lifeless | dOxxx: run_bzr is in process. run_bzr_subprocess is out of process | 00:06 |
| dOxxx | gotcha | 00:06 |
| dOxxx | I had to do a lot of tweaking of the tests for my initial set of changes because quite a few of the messages moved from stdout to stderr as a result of using trace.note | 00:07 |
| lifeless | dOxxx: what were you changing? | 00:07 |
| lifeless | dOxxx: by which I mean, generally, we've chosen stdout or stderr, so that sounds like a set of bugs. | 00:07 |
| dOxxx | lifeless: I started out fixing a bug for the mv command not obeying the --quiet option | 00:07 |
| dOxxx | lifeless: when I noticed that a lot of the other commands were using self.outf.write directly instead of trace.note and thus ignoring the --quiet option too | 00:08 |
| dOxxx | lifeless: so I thought I would clean it up and make sure everything that wasn't bulk data, as poolie describes it, was using trace.note | 00:08 |
| lifeless | so, its not 'bulk data' but rather 'the output of the command' | 00:08 |
| lifeless | that should be using outf.write | 00:09 |
| dOxxx | yeah | 00:09 |
| lifeless | bzr 2>/dev/null should never hide data the user needs | 00:09 |
| dOxxx | like the output of log or diff | 00:09 |
| lifeless | or the list of files moved | 00:09 |
| dOxxx | now that's where I'm talking about grey areas | 00:10 |
| dOxxx | the purpose of the mv command is not to output a list of moved files. it's to actually move the files. the list of moved files is incidental to it's actual purpose. | 00:10 |
| lifeless | mmm | 00:10 |
| dOxxx | but I don't feel like I have the right to make those sorts of judgement calls :) | 00:10 |
| lifeless | dOxxx: so, a progress bar would be definitely incidental | 00:13 |
| dOxxx | yes | 00:13 |
| lifeless | dOxxx: the list of files moved is more important, to me. | 00:13 |
| dOxxx | hmm | 00:13 |
| lifeless | its the return value | 00:13 |
| lifeless | if you think of mv as a function call | 00:14 |
| dOxxx | perhaps it's the difference between the primary output of the command and out-of-band information | 00:14 |
| lifeless | thats right, we use stderr for out of band | 00:14 |
| dOxxx | hmm | 00:14 |
| lifeless | stuff that isn't needed for scripting | 00:14 |
| lifeless | or capturing | 00:14 |
| dOxxx | yeah | 00:15 |
| poolie | dOxxx: btw did you do the contributor agreement http://www.canonical.com/contributors | 00:20 |
| dOxxx | Oh, no I haven't. | 00:21 |
| dOxxx | I'll have a look at that now. | 00:21 |
| dOxxx | hmm legalese :P | 00:22 |
| dOxxx | I'm glad #11 is in there ;) | 00:22 |
| === dOxxx is now known as dOxxx_ | ||
| === dOxxx_ is now known as dOxxx | ||
| dOxxx | poolie: agreement signed and emailed | 00:57 |
| maxb | There doesn't seem to be any command for "just merge the WT back to r9" | 01:34 |
| maxb | er, ignore me, scrollback fail | 01:34 |
| * maxb was attempting to jump into a conversation from 3 and a half hours ago | 01:34 | |
| * igc lunch | 01:37 | |
| spiv | dOxxx: still around? I like the sound of a more general fix, but in the meantime how about just changing cmd_mv to check is_quiet as some other commands already do? | 01:38 |
| dOxxx | spiv: I was just about to reply that I agree. For the purposes of fixing that bug, I'll change it back to use self.outf.write but check is_quiet first. | 01:39 |
| spiv | dOxxx: great. Thanks! | 01:39 |
| dOxxx | spiv: what should I do about your added bits? do I just apply that patch to my own branch? | 01:39 |
| spiv | dOxxx: you can either 'bzr merge lp:~spiv/bzr/271790 && bzr commit -m "Merge from spiv."', or just build on your own and I'll merge them before I land. | 01:42 |
| lifeless | spiv: I was a little surprised you'd sent merge 14812 to pqm | 01:43 |
| lifeless | spiv: given it only had one core review | 01:43 |
| maxb | Is there any way to ask bzr to diff against the pending merge tip? | 01:52 |
| maxb | or indeed, any way to get the revid of the pending merge tip | 01:52 |
| lifeless | via python | 01:55 |
| lifeless | we need a rev spec | 01:55 |
| fullermd | I'm kinda grumpy that stat --show-ids doesn't show 'em... | 02:01 |
| lifeless | fullermd: patchit :P | 02:04 |
| fullermd | Right, in my CFT :p | 02:06 |
| maxb | Hrm. The Ubuntu Distributed Development initiative seems to be a great way to run straight into file-id conflict nightmares. | 02:06 |
| * maxb wishes for bzr diff --ignore-file-ids | 02:07 | |
| === dOxxx is now known as dOxxx_ | ||
| elnovato1 | Help!! | 02:13 |
| elnovato1 | different rich-root support << i got this error when i push | 02:13 |
| bob2 | what are you pushing, and to where? | 02:13 |
| spiv | lifeless: well, it looked so simple... | 02:16 |
| lifeless | spiv: Personally, I'd only submit something without 2 core +1s if I'd be willing to do it with no other review at all | 02:17 |
| spiv | lifeless: and the patch had been lingering for several days. | 02:17 |
| lifeless | spiv: sure; thats nag for a review space isn't it? | 02:17 |
| spiv | Well, it looked safe enough when I reviewed it and tested it. PQM proved me wrong, of course. | 02:18 |
| lifeless | spiv: I'm not talking about safety per se | 02:19 |
| spiv | Well, by "safe" I guess I mean "trivial" | 02:20 |
| lifeless | well, +1 for experience :) | 02:20 |
| spiv | :) | 02:20 |
| lifeless | all the same, I think the only things I'd land that have only one core review would be docstring and whitespace fixes. | 02:22 |
| lifeless | because anything else that I wrote, I'd want a second eyeball on. | 02:23 |
| lifeless | and I don't trust folk that aren't core to have the experience of the library etc to catch corner concerns in a review. | 02:23 |
| spiv | elnovato: what are you pushing, and to where? | 02:25 |
| elnovato | got it, they are diff versions | 02:26 |
| jdub | is it possible to get loggerhead to dump tracebacks if it dies? | 03:04 |
| jdub | every now and then the process barfs, would love to file bugs | 03:05 |
| lifeless | in principle yes | 03:09 |
| lifeless | there is wsgi stuff around | 03:10 |
| * jdub just flicked his eyes over this window and read "barFS"... oh dear. | 03:10 | |
| AfC | jdub: you need to get out more, mate | 03:36 |
| AfC | [but if you do come up with a bar-fs, I want to use it for my /home partition] | 03:36 |
| dOxxx_ | spiv: are you around? | 03:57 |
| === dOxxx_ is now known as dOxxx | ||
| dOxxx | well maybe somebody else knows this... I've made some changes in my branch as suggested in a review of my merge proposal and I've pushed these changes up to the branch I made the proposal for. Do I use the Resubmit proposal link or is it handled automatically? | 03:58 |
| spiv | dOxxx: I am | 03:58 |
| dOxxx | hmm | 03:59 |
| dOxxx | ok it seems to have updated by itself | 04:00 |
| spiv | dOxxx: the diff will be automatically updated, but I think use resubmit if it needs a fresh round of review. In this case I don't think it's necessary, because I'll just send it in now. | 04:00 |
| dOxxx | ok | 04:01 |
| spiv | Although I'll have to fix the NEWS conflict, but that's easy. | 04:01 |
| dOxxx | yeah I just noticed that | 04:01 |
| dOxxx | I suppose I should get into the habit of pulling before I push :) | 04:02 |
| dOxxx | I've just dealt with the conflict locally. If you haven't done it yet, I can push it up. | 04:04 |
| fullermd | Well, if you wait 5 minutes, NEWS conflicts un-resolve themselves again :p | 04:06 |
| spiv | dOxxx: Ah, thanks, I already did that, just waiting for PQM now. :) | 04:06 |
| spiv | Ah, there it is: http://pqm.bazaar-vcs.org/ | 04:06 |
| dOxxx | thanks, I'll get the hang of this :) | 04:06 |
| poolie | spiv, nice work with the patches | 04:12 |
| dOxxx | he's been very helpful :) | 04:16 |
| spiv | poolie: Thanks. Next one I'm dealing with is https://code.edge.launchpad.net/~slyguy/bzr/bug-440952-bzrdir/+merge/13431, which I'd actually promised to finish off a while ago before we thought of patch pilots, just because the submitter had obviously put a bunch of good work in that I didn't want to waste. | 04:17 |
| poolie | k | 04:17 |
| spiv | That's part of why I volunteered, so I'd have a good excuse to get to it sooner rather than later :) | 04:17 |
| poolie | :) | 04:17 |
| poolie | you can ask me or others for help too | 04:17 |
| poolie | though i wouldn't recommend asking me in particular today :) | 04:18 |
| spiv | :) | 04:18 |
| dOxxx | bzr has an astounding number of tests. | 04:23 |
| dOxxx | I wish the --parallel selftest option worked on windows. | 04:24 |
| spiv | dOxxx: patches welcome :) | 04:26 |
| dOxxx | hehe | 04:26 |
| dOxxx | maybe I will have a look | 04:26 |
| dOxxx | do I need to install testtools into my python site-packages? | 04:29 |
| spiv | Yes, I think so. | 04:34 |
| dOxxx | ah, subunit is the problem. not ported to windows I guess? | 04:35 |
| jelmer_ | dOxxx, at least the python bits of subunit should work without problems on Windows I think | 04:36 |
| dOxxx | jelmer_: but aren't they just bindings into the c library? | 04:36 |
| jelmer_ | dOxxx, no, they don't rely on the C library in any way | 04:37 |
| dOxxx | oh! | 04:37 |
| poolie | hi jelmer | 04:37 |
| * poolie tries to fix doc builds again | 04:41 | |
| jelmer_ | moin poolie | 04:44 |
| * jelmer_ waves from UDS | 04:44 | |
| mwhudson | hello jelmer_ | 04:45 |
| poolie | hello | 04:45 |
| poolie | did you get my pm? | 04:45 |
| jelmer_ | hey mwhudson | 04:45 |
| jelmer_ | poolie: mwhudson or me? | 04:46 |
| mwhudson | jelmer_: you i presume :) | 04:46 |
| poolie | you | 04:46 |
| poolie | you, jelmer | 04:47 |
| dOxxx | lifeless: are you here? | 04:47 |
| lifeless | somewhat | 04:51 |
| lifeless | don't ask to ask, just ask ;)( | 04:51 |
| dOxxx | heh ok | 04:52 |
| dOxxx | lifeless: I was wondering if there was any particular reason why reinvoke_for_tests manually executes bzr instead of reusing the run_bzr_subprocess code? | 04:53 |
| lifeless | not offhand; possibly trust issues | 04:57 |
| RenatoSilva | dOxxx: hi | 04:57 |
| dOxxx | RenatoSilva: heya | 04:57 |
| dOxxx | lifeless: right... | 04:58 |
| RenatoSilva | dOxxx: is bug 398997 really fixed? it's more than one test error... | 04:58 |
| ubottu | Launchpad bug 398997 in bzr-xmloutput "Test failures and errors on Windows" [Medium,Fix committed] https://launchpad.net/bugs/398997 | 04:58 |
| dOxxx | RenatoSilva: when I was testing it, I was only getting the test_version failure | 04:59 |
| dOxxx | RenatoSilva: are you still getting errors? | 05:00 |
| RenatoSilva | dOxxx: will pull the changes and check, but I can't recall how to run it :( | 05:01 |
| dOxxx | RenatoSilva: if you have it in the correct location to be picked up as plugin by bzr, 'bzr selftest xmloutput' should do it | 05:02 |
| RenatoSilva | dOxxx: error: QtHelp4.dll not found | 05:03 |
| dOxxx | RenatoSilva: Hmm... | 05:03 |
| RenatoSilva | Anyone knows how to solve this? | 05:07 |
| spiv | RenatoSilva: I wish I did | 05:07 |
| RenatoSilva | there's the bug 448389 about it | 05:08 |
| ubottu | Launchpad bug 448389 in bzr "[win] 2.0 selftest fails, missing Qt dll" [Undecided,New] https://launchpad.net/bugs/448389 | 05:08 |
| dOxxx | yes, I see that too | 05:09 |
| dOxxx | I thought it was just a screwed up setting in my environment | 05:09 |
| dOxxx | RenatoSilva: but otherwise, that bug is fixed as far as I can tell. | 05:10 |
| RenatoSilva | dOxxx: I have to confirm that | 05:12 |
| RenatoSilva | dOxxx: after clicking ok in the qt error message, the test go on, and I'm getting a lot of errors here :( | 05:16 |
| RenatoSilva | dOxxx: Ran 82 tests in 49.125s, FAILED (errors=14, known_failure_count=1) | 05:16 |
| dOxxx | RenatoSilva: wow... | 05:17 |
| dOxxx | RenatoSilva: could you pastebin the errors? | 05:18 |
| RenatoSilva | dOxxx: do you get the QT dll error too? winXP? | 05:18 |
| dOxxx | RenatoSilva: yes I do. on vista 64. | 05:19 |
| dOxxx | RenatoSilva: I suspect it's something introduced with bzr 2.0.2 | 05:19 |
| RenatoSilva | dOxxx: so you get the qt error, click on, then all tests pass? | 05:20 |
| dOxxx | yes | 05:21 |
| RenatoSilva | dOxxx: there is stdout and stderr, will paste stdout | 05:22 |
| RenatoSilva | dOxxx: http://pastie.org/702167.txt | 05:24 |
| RenatoSilva | dOxxx: same errors of bzr-java-lib tests... | 05:24 |
| RenatoSilva | dOxxx: I think it's a bug with bzr in Windows | 05:24 |
| dOxxx | RenatoSilva: yeah... I think you've got something wrong with your environment. | 05:24 |
| RenatoSilva | dOxxx: I think something wrong with bzr, I tried everything possible to solve this problem | 05:25 |
| RenatoSilva | dOxxx: do you have wXP or some vm there? | 05:26 |
| RenatoSilva | dOxxx: I would like at least to understand what happens exactly, beyond "something regarding locks" | 05:27 |
| RenatoSilva | dOxxx: if I knew bzr internals maybe I could undertsand better the error and be working on a fix | 05:27 |
| dOxxx | RenatoSilva: my guess would be that it has something to do with non-ascii characters in the paths | 05:28 |
| lifeless | RenatoSilva: you have a locked working tree | 05:28 |
| RenatoSilva | dOxxx: what paths? | 05:28 |
| lifeless | thats not getting unlocked. | 05:28 |
| dOxxx | RenatoSilva: the paths to the temp dir | 05:29 |
| RenatoSilva | lifeless: hi, in bzr-java-lib I used procmon to get track of the problem. I watched bzr.exe and found one access denied error about lock/held file/dir (mentioned yesterday here, don't know if you saw). The most interesting thing in that line is that in the details column, there's a random text about another file, lock/*.tmp | 05:31 |
| RenatoSilva | dOxxx: if it was non-ascii paths, the problem would be fixes with changing it, and it is not | 05:31 |
| RenatoSilva | *fixed | 05:31 |
| RenatoSilva | lifeless: I would like to understand why the xxx.tmp file is randomly reported as detail for the access denied in lock/held | 05:32 |
| dOxxx | RenatoSilva: I do use bzr at work on winxp sp3 box | 05:32 |
| RenatoSilva | dOxxx: can you test now? | 05:33 |
| lifeless | RenatoSilva: I don't understand why you say its random | 05:33 |
| RenatoSilva | lifeless: random because it does not explain the relation | 05:33 |
| lifeless | we use temporary files a lot, because many network file systems don't have an atomic write to a file | 05:33 |
| dOxxx | gimme a few minutes, gotta vpn and it breaks my net connection here | 05:33 |
| RenatoSilva | lifeless: random like saying the sky is blue in details column for a given error | 05:33 |
| lifeless | what details column, you've lost me | 05:33 |
| RenatoSilva | lifeless: there's a too called procmon for windows | 05:34 |
| RenatoSilva | lifeless: you can watch what a process does | 05:34 |
| RenatoSilva | http://technet.microsoft.com/en-us/sysinternals/bb896645.aspx | 05:34 |
| RenatoSilva | * tool | 05:34 |
| lifeless | RenatoSilva: I don't have windows | 05:35 |
| RenatoSilva | lifeless: I tell the full to watch bzr.exe, and the I run the test in bzr-java-lib that fails randomly | 05:35 |
| RenatoSilva | I tell the *tool | 05:35 |
| RenatoSilva | lifeless: it lists all files accessed, dlls loaded, registry keys accessed, all the bz.exe activity, including the files in the temp dirs for the tests | 05:36 |
| spiv | RenatoSilva: the lockdir code will attempt to perform operations like "rename RANDOM.tmp held" and "rename held releasing.RANDOM.tmp" | 05:36 |
| RenatoSilva | lifeless: there's one entry saying that there was an access denied in lock/help | 05:36 |
| lifeless | well, that could well cause problems in the tests | 05:36 |
| RenatoSilva | lifeless: and there's a detail column for that where you expect to hrrr get details about it | 05:37 |
| spiv | RenatoSilva: where "RANDOM" is a string of random letters and digits, obviously. | 05:37 |
| spiv | RenatoSilva: perhaps that's what procmon was reporting? | 05:37 |
| RenatoSilva | lifeless: now imagine the detail column says "nice day today", it doesn't give detail about anything right? the same way, the actual text there in just the file path to lock/*.tmp | 05:38 |
| RenatoSilva | spiv: oh so the error was about renaming files, hum... | 05:38 |
| spiv | RenatoSilva: so, it appears it is giving relevant detail :P | 05:39 |
| RenatoSilva | spiv: at least for me that had no idea :P | 05:39 |
| dOxxx1 | RenatoSilva: I don't get the permission errors running the xmloutput tests on winxp | 05:40 |
| dOxxx1 | RenatoSilva: sorry to say but I think it's just you :P | 05:40 |
| RenatoSilva | dOxxx1: is it updated? | 05:40 |
| RenatoSilva | dOxxx1: what's your antivirus | 05:40 |
| dOxxx1 | RenatoSilva: symantec corporate thingy | 05:40 |
| RenatoSilva | spiv: what could make bzr not release a lock | 05:41 |
| dOxxx1 | RenatoSilva: checkout of branch: bzr+ssh://bazaar.launchpad.net/~verterok/bzr-xmloutput/trunk/ | 05:41 |
| dOxxx1 | switching back | 05:42 |
| RenatoSilva | oh sorry just /cleared the screen, what one jsut told me? | 05:42 |
| spiv | What makes you ask that question? From the information you've given here I'm not sure that's the right question to ask. | 05:42 |
| RenatoSilva | spiv: why | 05:42 |
| RenatoSilva | spiv: what's the right question to ask | 05:42 |
| lifeless | RenatoSilva: generally, not calling 'tree.unlock()' will cause a lock not to be unlocked. | 05:42 |
| spiv | I think you want to be asking "why am I getting 'access denied' errors when bzr is attempting to release (or acquire?) that lock?" | 05:43 |
| RenatoSilva | lifeless: or maybe tree.unlock() failing? e.g. an external os error? | 05:44 |
| lifeless | bzr should be reporting any errors like that that might turn up | 05:44 |
| RenatoSilva | where's the log for this channel? | 05:44 |
| lifeless | something is messing with the reporting/output, *or* you're simply not unlocking it | 05:44 |
| lifeless | race conditions and finalizers can be to blame too, | 05:45 |
| lifeless | and as you're testing some java lib stuff, I'd look there first | 05:45 |
| RenatoSilva | lifeless: the above link is just stdout, I can't recall how to mix stdout and stderr to send to a file in Windows, let me try... | 05:45 |
| spiv | RenatoSilva: there's some at http://irclogs.ubuntu.com/2009/11/17/%23bzr.html, not sure how frequently they are updated | 05:45 |
| dOxxx1 | RenatoSilva: command > file 2>&1 | 05:47 |
| RenatoSilva | lifeless: http://pastie.org/702167.txt | 05:50 |
| RenatoSilva | dOxxx1: thanks | 05:50 |
| dOxxx1 | how long does it take for an old nick to timeout | 05:51 |
| dOxxx1 | from the irc server? | 05:51 |
| RenatoSilva | dOxxx1: /msg nickserv ghost <pwd> iirc | 05:51 |
| === dOxxx1 is now known as dOxxx | ||
| dOxxx | woot... got bzr selftest --parallel=subprocess working on windows | 05:53 |
| lifeless | RenatoSilva: then as it says, something has the held file locked | 05:54 |
| lifeless | dOxxx: +1 | 05:54 |
| dOxxx | lifeless: and I think it might even still work on unix ;) | 05:54 |
| lifeless | RenatoSilva: figure out what process that is (sysmon all processes probably - including system) | 05:54 |
| lifeless | dOxxx: well, I surely hope so :) | 05:54 |
| RenatoSilva | lifeless: so I watch the file, not the process, ok let me try... | 05:55 |
| dOxxx | lifeless: it's pretty noisy. far more output than the normal selftest | 05:56 |
| RenatoSilva | spiv: thanks for the log link | 05:56 |
| dOxxx | lifeless: lots of stuff like this: successful: bzrlib.tests.per_tree.test_path_content_summary.TestPathContentSummary.test_file_content_summary_executable(DirStateRevisionTree,WT5) | 05:57 |
| lifeless | dOxxx: thats subunit output, it shouldn't show up unless you supply --subunit | 05:58 |
| RenatoSilva | is the qt dll in the error about the qt ui? | 05:58 |
| lifeless | dOxxx: and you should pipe it through a subunit filter. e.g. subunit-stats | 05:59 |
| lifeless | bbiaw | 05:59 |
| dOxxx | lifeless: I'm using --parallel=subprocess because fork doesn't work on windows, at that seems to have implied --subunit | 05:59 |
| dOxxx | anyway, I gotta hit the sack | 06:00 |
| dOxxx | seeya guys later | 06:00 |
| RenatoSilva | dOxxx: see you | 06:01 |
| poolie | igc, why does only doc/ja have a sphinx configuration file? | 06:07 |
| RenatoSilva | lifeless: even including System, there are only two process invloved with lock/held: bzr.exe and avgchsvx.exe (AVG real time scanner) | 06:07 |
| RenatoSilva | lifeless: so ok, the antivirus is the problem, what I don't get is why still doesn't it work when I turn it off :( | 06:08 |
| poolie | well, i see it came in inada's recent mail | 06:10 |
| igc | poolie: I'll take a look | 06:11 |
| poolie | nevermind, i'll look into it | 06:11 |
| poolie | i thought it was your change | 06:11 |
| poolie | so, really, don't worry | 06:11 |
| spiv | igc: if you're in the mood, feel like taking a look at https://code.edge.launchpad.net/~amanica/bzr/325618_log_returns_too_much/+merge/14275 ? | 06:11 |
| poolie | i think they're not actually needed? | 06:11 |
| igc | poolie: I think sphinx_conf.py is redundant | 06:14 |
| igc | spiv: I'll take a look tomorrow | 06:14 |
| igc | poolie: maybe it was there for bootstrapping or it proceeded the shorter conf.py approach | 06:15 |
| spiv | igc: cool, ta | 06:20 |
| poolie | OK | 06:23 |
| RenatoSilva | Hey folks what antivirus do you use? I'm thinking about abandoning AVG9 as it seems to be locking Bazaar | 06:36 |
| * wgrant uses Ubuntu. | 06:37 | |
| * RenatoSilva too | 06:37 | |
| RenatoSilva | I want to install an antivirus that is friend of Bazaar | 06:38 |
| * RenatoSilva will restart the computer and come back soon | 06:38 | |
| AfC | Uh, "av that's a friend of a dvcs"? weird | 06:39 |
| poolie | afc: i think he means "that doesn't hold locks on files" | 06:39 |
| poolie | spiv/igc: verbal +1 to remove it and fix the builds? | 06:39 |
| AfC | poolie: ah! | 06:40 |
| AfC | poolie: (that would be reminiscent of Tracker using inotify and blowing out the kernel's hard limit of monitorable files) | 06:40 |
| spiv | poolie: remove what, doc/ja/sphinx_conf.py? Sure, if that fixes builds then +1 from me. I guess you'd need to tweak doc/ja/conf.py to import bzrlib.doc_generate.sphinx_conf instead? | 07:07 |
| poolie | oh good point | 07:10 |
| spiv | The improved consistency makes sense. | 07:11 |
| poolie | yep, i just did a two-way merge against the english version | 07:14 |
| RenatoSilva | lifeless: removed ABG and the lock errors stopped | 07:14 |
| spiv | RenatoSilva: that's good to know | 07:14 |
| spiv | Although a shame that it interacts so poorly. | 07:14 |
| RenatoSilva | it who, bzr or avg? or both :P | 07:15 |
| poolie | both | 07:15 |
| poolie | though | 07:15 |
| RenatoSilva | avg9 is weird, you deactivate the watch dog, but the process is still active | 07:15 |
| poolie | i think the onus is on the scanner not to interfere with applications | 07:16 |
| RenatoSilva | it was active in lock/held, although less than before, but it was | 07:16 |
| RenatoSilva | poolie: I tired to exclude my profile dir and bzr dir from runtime scan but didn't work, and as I said above the realtime scanner doesn't really stop working it seems | 07:17 |
| RenatoSilva | poolie: do you know of any "friend" antivirus? | 07:17 |
| RenatoSilva | poolie: if I don't find one, I think I'll just reinstall AVG and live with these failures... at least we --know-- what's the problem now | 07:18 |
| RenatoSilva | bzr-java-lib tests are ok now too | 07:18 |
| RenatoSilva | this is normal output for bzr selftest xmloutput right? http://pastie.org/702237.txt | 07:19 |
| RenatoSilva | the xfail is the known failure? | 07:20 |
| poolie | yes | 07:21 |
| poolie | poor name, we should change it | 07:21 |
| RenatoSilva | ok, waiting for the qt dll fix then | 07:22 |
| lifeless | poolie: what do you thinkof the idea of turning language translations into branches | 07:26 |
| lifeless | doc language translations, I mean. | 07:26 |
| poolie | i'm not sure what you mean | 07:26 |
| lifeless | well, seems to me that each language is kindof like a branch, of the docs | 07:26 |
| fullermd | I've thought on that sort of thing. The big problem is that every merge is just a giant pile of conflicts. | 07:27 |
| lifeless | 'bzr cp' + merges from those files on an ongoing basis would model it too, if we had copies | 07:27 |
| poolie | mm | 07:27 |
| poolie | interesting in theory | 07:27 |
| poolie | the assumption under this is that folks do a diff on the english text to see what needs to be translated? | 07:28 |
| poolie | s//newly translated | 07:28 |
| lifeless | well, that they need to figure out what has gone on to update the translation, yes. | 07:28 |
| lifeless | a conceptual diff, for sure. | 07:28 |
| poolie | i guess i'd like to know more about how people actually do doc translation | 07:34 |
| lifeless | yeah | 07:34 |
| lifeless | it was a drive by thought based on the ja branch | 07:34 |
| lifeless | which had one of the conf files we had initially | 07:34 |
| RenatoSilva | spiv: maybe bzr does something that makes AVG angry | 07:38 |
| RenatoSilva | spiv: would you recommend to try 2.1 beta? (using 2.0 and previously 1.18) | 07:39 |
| fullermd | Presumably, "making the file and then trying to delete it pretty quickly before AVG gets done screwing with it" | 07:39 |
| fullermd | Go the other way. Try 0.11 or something. That may be slow enough for AVG to finish up in time. | 07:40 |
| lifeless | RenatoSilva: no, its not bzr | 07:40 |
| lifeless | RenatoSilva: avg is taking a read lock rather than opening share_delete or whatever it is. We've had this problem reported before - as I said days ago, 'probably your virus scanner' | 07:40 |
| RenatoSilva | lifeless: well I'm not sure. but why would AVG suspect of bzr as a potential problem? | 07:41 |
| lifeless | RenatoSilva: who says it thinks bzr is a problem | 07:41 |
| RenatoSilva | fullermd: 0.11? | 07:41 |
| * fullermd was being a little facetious... | 07:41 | |
| lifeless | RenatoSilva: fullermd was making a joke. bzr 0.11 was a lot slower, so it might not collide with avg as much | 07:42 |
| RenatoSilva | fullermd: so the problem is that bzr creates a file, then AVG starts to scan it, then in the meanwhile bzr wants to delete or rename the file, and so the error | 07:42 |
| lifeless | yes | 07:43 |
| fullermd | 's my guess. | 07:43 |
| RenatoSilva | then why does AVG8 has no problem with it? | 07:43 |
| lifeless | different versions of software behave differently | 07:43 |
| lifeless | see my comments on locking above | 07:43 |
| RenatoSilva | ok just was, I see | 07:44 |
| RenatoSilva | *saw | 07:44 |
| poolie | pyc files lingering after the source removed strikes again | 07:44 |
| poolie | spiv: you were right btw | 07:44 |
| RenatoSilva | lifeless: I think it's the .0 problem | 07:44 |
| poolie | about fixing conf.py | 07:45 |
| lifeless | RenatoSilva: what do you mean? | 07:45 |
| RenatoSilva | lifeless: maybe it's the right thing to do, imagine the file is a virus, and another softwate deletes it after AVG detecting, maybe AVG 9 will always behave this way | 07:45 |
| RenatoSilva | lifeless: i.e. not the .0 problem (foo bar 2.0, 3.0 etc) | 07:46 |
| lifeless | RenatoSilva: I don't understand | 07:46 |
| RenatoSilva | lifeless: AVG locks the file to scan it right? then bzr tries to delete/rename it and can't (it could in AVG8) | 07:47 |
| RenatoSilva | lifeless: I think that's the right thing to do | 07:47 |
| lifeless | thats our working theory. | 07:47 |
| lifeless | RenatoSilva: I don't see why its right. | 07:47 |
| RenatoSilva | lifeless: the file can't be deleted while being scanned | 07:47 |
| lifeless | virus scanners should not change system behaviour | 07:48 |
| RenatoSilva | lifeless: maybe it should just copy the file and scan the copy | 07:48 |
| lifeless | RenatoSilva: avg could hard link it and scan. Or it could lock it share_delete and handle client code deleting the file. | 07:48 |
| lifeless | RenatoSilva: that would be bad if the file is large. | 07:48 |
| lifeless | RenatoSilva: I think its very clearly a bug in AVG | 07:48 |
| RenatoSilva | hard links in windows? | 07:49 |
| lifeless | yes | 07:49 |
| lifeless | been supported for a while | 07:49 |
| RenatoSilva | one more reason to not use .0 software :-/ | 07:50 |
| RenatoSilva | but thank you all you guys for helping me, I think I'll live with this error while waiting a fix | 07:53 |
| lifeless | RenatoSilva: you realise AVG probably don't know there is a problem, and its not a bzr problem... | 07:54 |
| lifeless | RenatoSilva: you really should tell them :) | 07:54 |
| * poolie spams out the review queue | 08:08 | |
| === maxb is now known as Guest71681 | ||
| === quicksil1er is now known as quicksilver | ||
| maxb | Does bzr ever discard dead heads? Is there a command somewhere for that? | 13:08 |
| beuno | maxb, dead heads? | 13:50 |
| beuno | (I'm pretty sure the answer is no) | 13:50 |
| beuno | like when you uncommit? | 13:51 |
| maxb | yes, heads not referenced by any branch | 13:51 |
| beuno | maxb, there is no way to clean them up | 13:53 |
| === r0bby is now known as r0bby|android_ | ||
| === r0bby|android_ is now known as r0bby|android__ | ||
| === r0bby|android__ is now known as r0bby | ||
| === raimue is now known as Raim | ||
| henninge | Hi, I have a conflict situation that I don't know how to resolve. | 15:35 |
| henninge | A file was created both in my current branch and the branch that I am merging from, with different content. | 15:36 |
| henninge | Merge looks like this: http://paste.ubuntu.com/320877/ | 15:36 |
| henninge | I want to keep the file as it is and discarded the merged version, so effectively renaming the .moved file to the original name. | 15:37 |
| henninge | I just don't know how. I tried a few things but they did not work. | 15:38 |
| NfNitLoop | henninge: you should be able to bzr revert <filename> to revert just that file (without blowing away your merge) | 15:38 |
| NfNitLoop | if you commit that merge, then, that has rejected the remote change. | 15:38 |
| * henninge tries | 15:39 | |
| henninge | NfNitLoop: Great! that worked! http://paste.ubuntu.com/320879/ | 15:40 |
| henninge | NfNitLoop: thanks a lot | 15:40 |
| NfNitLoop | henninge you're welcome. | 15:45 |
| NET||abuse | hey guys. i'm trying to push a repo of graphic work, from windows, over to a samba share on a linux box, but i'm getting errors. | 15:52 |
| NfNitLoop | NET||abuse: such as...? | 15:55 |
| NfNitLoop | (please use pastebin if they're large) | 15:55 |
| NET||abuse | bzr: ERROR: [Errno 22] Invalid argument | 15:56 |
| NET||abuse | that's it. | 15:56 |
| NET||abuse | weird stuff. | 15:56 |
| NfNitLoop | what command did you use to do the push? | 15:56 |
| NET||abuse | bzr push P:\projects\sitegraphics\ | 15:58 |
| NET||abuse | I had a dir with 800MB of graphics work, i did bzr init in that directory | 15:58 |
| NET||abuse | bzr add *; bzr commit ; | 15:58 |
| LarstiQ | NET||abuse: could you try `bzr push P:/projecs/sitegraphics/` instead? | 16:01 |
| NET||abuse | yeh, i could. | 16:01 |
| LarstiQ | might be paranoid, but worht a try | 16:01 |
| LarstiQ | if note, check the .bzr.log | 16:01 |
| NET||abuse | just trying to branch to a local directory right now. | 16:01 |
| LarstiQ | _not_ | 16:01 |
| NET||abuse | seemed to work wen branching.. | 16:01 |
| NET||abuse | right trying to push,, i need it up on the share so other people can get at the graphics. | 16:01 |
| * LarstiQ nods | 16:01 | |
| NET||abuse | i could try branching while in the P: drive. | 16:02 |
| LarstiQ | that's an option | 16:02 |
| LarstiQ | or just copying the folder should work too | 16:03 |
| Tak | export? | 16:03 |
| NET||abuse | hmm, copy,, seems like cheating ;) | 16:03 |
| NET||abuse | maybe it's timing out. | 16:04 |
| NET||abuse | trying to branch now,,, it's saying "Fetching revisions:Get stream source | 16:04 |
| LarstiQ | that's ok | 16:05 |
| LarstiQ | NET||abuse: which version of bzr is this btw? | 16:05 |
| NET||abuse | i'll check. | 16:05 |
| NET||abuse | python25.dll version 2.5.4, bzr 2.0 seems to be what it's saying,, | 16:06 |
| NET||abuse | no wait,, bzr 1.18.1 | 16:06 |
| LarstiQ | NET||abuse: ok | 16:06 |
| phoenixz | I have two projects based on the same framework in BZR. They basically share libraries and I want functionality from project one shared with project 2 and vice versa.... Is it possible to only merge the libraries directory of these two projects, and leave the other directories untouched? | 16:10 |
| GaryvdM | phoenixz: Have you been visioning these 2 projects in bzr allready? | 16:14 |
| GaryvdM | phoenixz: The idea is that you have 3 branches. 1 for the framework and 1 for each project. | 16:16 |
| GaryvdM | phoenixz: then you use nested trees (Which is not complete) | 16:16 |
| phoenixz | GaryvdM: actually, thats where I want to go to, yes | 16:16 |
| phoenixz | GaryvdM: nested trees? thats like a BZR tree inside a BRZ tree? | 16:17 |
| GaryvdM | phoenixz: untill nested trees is finished, you can use scmproj | 16:17 |
| NfNitLoop | Hrmm, https://bugs.launchpad.net/bzr/+bug/81844 seems to be keeping me from checking out an upstream SVN repo. >.< | 16:18 |
| GaryvdM | phoenixz: http://bazaar-vcs.org/NestedTreesDesign | 16:18 |
| ubottu | Launchpad bug 81844 in bzr-svn "Handle backslashes in filenames more gracefully" [Low,Invalid] | 16:18 |
| GaryvdM | phoenixz: https://edge.launchpad.net/bzr-scmproj | 16:19 |
| phoenixz | GaryvdM: reading... | 16:20 |
| clemente | NfNitLoop: me too. It is one of the bugs with most duplicates | 16:22 |
| NfNitLoop | apparnetly svn is interpreting backslashes as directory separators. | 16:22 |
| NfNitLoop | apparently* (Guh, this keyboard!) | 16:22 |
| NfNitLoop | but bzr-svn isn't cool with that. | 16:23 |
| NfNitLoop | soooo, no bzr for this codebase. :~( | 16:23 |
| jelmer | NfNitLoop, that's not the problem, there are backslashes in filenames | 16:23 |
| jelmer | NfNitLoop, and bzr doesn't support backslashes in filenames | 16:23 |
| NfNitLoop | Oh, hrmm. I'm seenig backslashes as file separators in SVN. | 16:34 |
| NfNitLoop | let me double check that. | 16:34 |
| NfNitLoop | yeah, they're directory separators, I can browse the directories in the svn checkout. | 16:36 |
| NfNitLoop | bzr: ERROR: Unable to convert Subversion path eclipse/plugins/a.b.c\src\x\y\z because it contains characters invalid in Bazaar. | 16:36 |
| NfNitLoop | I can cd into eclipse/plugins/a.b.c/src/x/y/z | 16:36 |
| NfNitLoop | Oooh. Hrmm. | 16:41 |
| NfNitLoop | Looking at the log of the directory, apparently it was copied from a directory with backslashes in its name. | 16:41 |
| NfNitLoop | so they fixed it, but it's not fixed in history. | 16:41 |
| NfNitLoop | >.< | 16:41 |
| NfNitLoop | Is there any workaround other than blowing away the history? | 16:43 |
| jelmer | NfNitLoop, no, there's no way around that at the moment | 16:50 |
| NfNitLoop | aww, ok. Thanks. | 16:55 |
| === Ng_ is now known as Ng | ||
| clemente | jelmer: the importer could convert the \ in 'file_id's and leave names with \, right? It was suggested in bug 81844 comment 6 but there's no specific bug for it | 17:08 |
| ubottu | Launchpad bug 81844 in bzr-svn "Handle backslashes in filenames more gracefully" [Low,Invalid] https://launchpad.net/bugs/81844 | 17:08 |
| jelmer | NfNitLoop, it basically needs a fix in bzr | 17:08 |
| jelmer | clemente: we can't leave \ in names because bzr doesn't allow it | 17:09 |
| clemente | jelmer: the comment I mentioned also suggests allowing \ in names in bzr | 17:10 |
| jelmer | clemente, yes, that's the way to go | 17:10 |
| jelmer | clemente, there's a separate bug in bzr for that I think | 17:10 |
| clemente | True, bug 163858. I will link to it from the former bug | 17:13 |
| ubottu | Launchpad bug 163858 in bzr "backslashes in filenames not allowed (dup-of: 81844)" [Medium,Triaged] https://launchpad.net/bugs/163858 | 17:13 |
| ubottu | Launchpad bug 81844 in bzr-svn "Handle backslashes in filenames more gracefully" [Low,Invalid] https://launchpad.net/bugs/81844 | 17:13 |
| === mordred_ is now known as mtaylor | ||
| === henninge_ is now known as henninge | ||
| === vednis is now known as mars | ||
| Peng | "Fatal Python error: deletion of interned StaticTuple failed" \o/ | 17:45 |
| Peng | I wonder if SimpleSet is thread-safe? | 18:05 |
| mgedmin | http://doc.bazaar-vcs.org/migration/en/why-switch-to-bazaar.html is a very nice and convincing document | 19:11 |
| === jam1 is now known as jam | ||
| Peng | jam: ping | 19:49 |
| jam | hey Peng | 19:49 |
| Peng | Hi. :D | 19:49 |
| pickscrape | Is it possible to get back the message of a commit that failed? | 19:50 |
| pickscrape | i.e. I don't want to have to type it again :) | 19:50 |
| Peng | jam: I wanted to pester you about StaticTuple, as usual. Today, Loggerhead crashed with "deletion of interned StaticTuple failed". Any idea why that would happen? Is interning/uninterning thread-safe? | 19:50 |
| jam | Peng: I don't include any locking primitives | 19:51 |
| jam | however, I also don't release the GIL | 19:51 |
| jam | Looking at the code: | 19:52 |
| jam | if (SimpleSet_Discard(_interned_tuples, (PyObject*)self) != 1) | 19:52 |
| jam | Py_FatalError("deletion of interned StaticTuple failed"); | 19:52 |
| jam | It would indicate that the interned dict claims to not have the st present | 19:52 |
| jam | but the tuple itself claims to be interned | 19:52 |
| jam | well, the SimpleSet (vs dict) | 19:52 |
| Peng | Or there was an exception of some sort. | 19:52 |
| jam | note that right after that | 19:52 |
| jam | self->flags &= ~STATIC_TUPLE_INTERNED_FLAG; | 19:52 |
| jam | so it shouldn't be possible to try and remote it twice | 19:52 |
| Peng | Plus... I don't think it's worth throwing a fatal error if the st wasn't present. Maybe a warning, but it's not actually *dangerous*, though it does mean something has gone wrong. | 19:53 |
| jam | Peng: correct, some sort of failure while removing the st from the dict | 19:53 |
| jam | Peng: internal state being inconsistent seems dangerous to me | 19:53 |
| Peng | Yeah, but this specific error isn't hard to recover from. Meh, I could go either way, I guess. | 19:54 |
| jam | Peng: and you can't raise exceptions from _dealloc | 19:55 |
| jam | so you have to PyErr_Clear if there is a real failure | 19:55 |
| jam | etc. | 19:55 |
| Peng | Equivalent to __del__ in Python code? | 19:55 |
| jam | Peng: basically | 19:55 |
| jam | except it doesn't cause the gc to puke | 19:55 |
| Peng | Ah, ok. | 19:55 |
| Peng | (The gc pukes?) | 19:55 |
| jam | you can reclaim objects with _dealloc | 19:55 |
| jam | gc can't reclaim objects in a refcycle that have __del__ | 19:56 |
| jam | you *could* reclaim objects in a refcycle with _dealloc | 19:56 |
| jam | as it is done at a different level, I guess | 19:56 |
| Peng | What did SimpleSet_Discard return, -1 (exception) or 0 (wasn't present)? Either one? | 19:56 |
| jam | Peng: I don't know. Something other than 1 did exist | 19:56 |
| jam | bbiab, getting lunch | 19:57 |
| Peng | jam: Have fun. :) | 19:57 |
| * Peng has fun causing crashes by manipulating _interned_tuples. | 19:58 | |
| jam | Peng: manipulating? | 20:11 |
| jam | that sounds seriously bad | 20:11 |
| jam | certainly you shouldn't (even be able) mutate these once their created | 20:12 |
| jam | and definitely not after you've called .intern() on them | 20:12 |
| Peng | jam: _interned_tuples.discard(something_in_it) causes the dealloc crash. :) | 20:13 |
| Peng | jam: It's not like I'm doing that in real code; I just think it's funny (I'm easily amused). | 20:13 |
| Peng | python -c "from bzrlib._static_tuple_c import _empty_tuple, _interned_tuples; _interned_tuples.discard(_empty_tuple)" -> crash | 20:13 |
| jam | Peng: if you are going to do something like that, I'm going to hide _interned_tuples from you | 20:13 |
| Peng | jam: Yes sir :( | 20:13 |
| jam | certainly you can crash things easily by something like that, though | 20:13 |
| jam | I suppose I could expose it as | 20:14 |
| jam | _peng_you_really_dont_want_to_touch_these_interned_tuples | 20:14 |
| jam | Peng: would that be better? | 20:14 |
| fullermd | I'd rather have API's with specific injunctions against me than a statue :p | 20:14 |
| Peng | jam: It would make the line-wrapping in _static_tuple_c.c a pain. | 20:15 |
| jam | Peng: :) I wouldn't change the C name, just the name exposed to python | 20:15 |
| Peng | Ooooo, clever. | 20:15 |
| jam | fullermd: meaning... you'd rather be able to shoot yourself in the foot than not be given a gun? | 20:16 |
| Peng | Just out of curiousity, is it possible to mutate a StaticTuple from C code, if you're evil? | 20:16 |
| fullermd | Well, obviously. But I just think of it as a fitting tribute of me to send down through the ages. | 20:16 |
| fullermd | Centuries from now, archaeologists will try to reconstruct my life from fragments of code berating me for my use of them. | 20:17 |
| fullermd | It'll be awesome! | 20:17 |
| jam | Peng: raw pointers can do anything in C | 20:17 |
| Peng | Good point. | 20:17 |
| jam | StaticTuple_SetItem specifically should not be called for any object that has been exposed to python | 20:18 |
| jam | same as PyTuple_SetItem | 20:18 |
| jam | but you have to have *some* api for creating them in the first place | 20:18 |
| Peng | Anyway... that Loggerhead crash isn't good. Sure, it's only happened once, but if there's a race condition, users who get significant traffic (Launchpad) might experience it frequently. | 20:19 |
| Peng | But it's also probably not easy to track down. :\ | 20:19 |
| jam | Peng: I understand from mwhudson that loggerhead crashes regularly on LP regardless of StaticTuple | 20:19 |
| jam | bzrlib itself isn't particularly threadsafe | 20:20 |
| Peng | Haha. | 20:20 |
| Peng | Since 2a, it crashes for me every day or two cuz it runs out of memory. :) | 20:20 |
| Peng | I really need to set something up to restart it automatically... I wonder what LP uses? | 20:20 |
| jam | In mooloolaba mwhudson mentioned that he had it fairly stable for a while ~6 months ago | 20:20 |
| jam | and just hasn't had much time since to maintain that | 20:20 |
| jam | Peng: cron, I believe | 20:20 |
| mwhudson | jam: sysadmins | 20:21 |
| jam | mwhudson: ah l-o-s-as what can't they do :) | 20:21 |
| Peng | Unlike losas, I sleep sometimes, so it's often down for many hours. Fortunately, nobody uses it so it doesn't matter! | 20:22 |
| jam | mwhudson: so how often does it crash? And how does that get reported for a restart. Is it manual? | 20:27 |
| mwhudson | jam: a few times a day, nagios | 20:34 |
| mwhudson | it usually doesn't crash per se, but go unresponsive | 20:34 |
| jam | mwhudson: I also had a question that I was hoping you might have some knowledge to answer | 20:35 |
| jam | if you look at bug #423804 | 20:35 |
| ubottu | Launchpad bug 423804 in bzr "Failure to saturate bandwidth downloading lp:bzr" [High,Confirmed] https://launchpad.net/bugs/423804 | 20:35 |
| jam | You can see that streaming data off of launchpad has a very strange shape | 20:35 |
| jam | (see the last .png file: http://launchpadlibrarian.net/35795705/get_stream_lp.png) | 20:35 |
| mwhudson | jam: that's a little odd | 20:36 |
| jam | I was wondering if it might be something with LP, but I'm not really sure how to test | 20:36 |
| jam | also, what is the deal with 'staging' | 20:36 |
| mwhudson | jam: how does it compare to say bzr+ssh off chinstrap? | 20:37 |
| jam | mwhudson: I haven't tried that yet, but I'll go there next | 20:37 |
| mwhudson | jam: please do | 20:37 |
| jam | mwhudson: how does one get a new ssh key onto chinstrap? | 20:37 |
| jam | file an rt request? | 20:37 |
| mwhudson | jam: "what is the deal with 'staging'" <- more pls? | 20:37 |
| jam | mwhudson: back to staging... does it have any data from lp: ? | 20:38 |
| jam | or is it only new stuff you upload? | 20:38 |
| jam | (It looks like the latter to me) | 20:38 |
| mwhudson | jam: i think there's some magic email address you can email, look on wiki.c.c? | 20:38 |
| mwhudson | jam: it has a few branches from production | 20:38 |
| jam | mwhudson: as for other comparisons, http://launchpadlibrarian.net/35795404/get_stream_babune.png is from Vincent's server | 20:38 |
| mwhudson | but not many | 20:38 |
| jam | though he seems to have a 100k download cap | 20:38 |
| jam | sorry upload cap | 20:38 |
| jam | which is 1/3rd my download cap | 20:38 |
| jam | mwhudson: ok, does staging run a newer bzr? | 20:39 |
| jam | (my last test suggested that both live and staging were running 2.0.0) | 20:39 |
| mwhudson | jam: only when we land a newer bzr in rf | 20:39 |
| mwhudson | which we haven't done for a while for a variety of bad reasons | 20:39 |
| mwhudson | it doesn't track bzr.dev or anything like that | 20:39 |
| jam | k | 20:41 |
| jam | babune has 2.0.2 as does chinstrap | 20:41 |
| Peng | Think it's worth filing a bug about the crash? | 20:41 |
| jam | but I don't think there is anything significant there versus 2.0.0 | 20:41 |
| jam | Peng: it is worth *something*, but without being able to reproduce it, I'm not sure what a good answer is | 20:42 |
| jam | If you want to create a patch that just improves debugging | 20:42 |
| jam | like, perhaps writing out the actual response from the set | 20:42 |
| jam | checking if there is an exception | 20:42 |
| Peng | Oh wait, my StaticTuple branch hasn't even landed in LH's trunk yet. | 20:42 |
| jam | if so, debugging that | 20:42 |
| jam | I'd be willing to land that in bzr | 20:42 |
| jam | mwhudson: ahh local bandwith. Chinstrap is downloading a copy of bzr at about 1.8MB/s | 20:43 |
| jam | /glee | 20:43 |
| mwhudson | jam: running bzr get lp:bzr on chinstrap? | 20:43 |
| jam | mwhudson: yeah | 20:43 |
| mwhudson | sounds a bit slow :) | 20:44 |
| jam | course, it almost seems hung at the "Inserting missing keys" stage | 20:44 |
| jam | which is a bit strange | 20:44 |
| jam | mwhudson: well, interestingly enough "time bzr branch lp://staging/~jameinel/bzr/bzr-test" on babune was 1m49s, on chinstrap was 3m4s | 20:44 |
| Peng | mwhudson: Do graphs in the revgraph cache ever get mutated? If a new revision is added to the branch, is the graph regenerated from scratch? | 20:44 |
| jam | so it doesn't seem to be network speed that matters at that point | 20:44 |
| wadesworld | hi guys...looking for some advice...using the latest bzr, both myself and my colleague have expereienced bzr hangs when trying to merge from our shared repository....I went so far as to upgrade the shared repositories OS last night to see if it was perhaps a bug in OpenSSH | 20:45 |
| mwhudson | Peng: yes, regenerated from scratch | 20:45 |
| mwhudson | Peng: which is terrible | 20:45 |
| mwhudson | jam: crowberry is fairly heavily loaded basically all of the time | 20:45 |
| wadesworld | the symptom is, you type in your ssh passworld and bzr just sits there....been sitting there for 45 minutes now | 20:45 |
| mwhudson | (crowberry == bazaar.launchpad.net) | 20:46 |
| jam | mwhudson: hm... this won't be exactly identical as I have to go through 'openssh' to access chinstrap, rather than paramiko | 20:46 |
| Peng | mwhudson: OK, thanks. | 20:46 |
| jam | wadesworld: do you happen to be on Windows using plink as your ssh implementation? | 20:46 |
| jam | (I expect not, but figured I'd start with that) | 20:46 |
| Peng | Stupid question: does each thread have its own revgraph cache? | 20:46 |
| wadesworld | nope...we're both on Macs, and the "server" is OpenBSD 4.6 | 20:46 |
| wadesworld | using sftp as the access method | 20:47 |
| jam | wadesworld: generally sftp is slow, but I wouldn't expect indefinite hangs | 20:47 |
| jam | are you sure it isn't doing a cross-format conversion? | 20:47 |
| jam | (bzr info $REMOTE; bzr info $LOCAL should help tracking that down) | 20:47 |
| wadesworld | positive, everything is 2a | 20:47 |
| jam | mwhudson: ah wait, chinstrap *is* the forwarding host, right? | 20:49 |
| jam | so I don't actually require a double connect | 20:50 |
| mwhudson | jam: yes | 20:50 |
| jam | mwhudson: chinstrap is a lot 'flatter' than crowberry, I'll upload in a bit | 20:51 |
| jam | though also, this source is a freshly packed repo | 20:52 |
| jam | rather than the organic version on lp:bzr | 20:52 |
| jam | I may try to use lftp and see if that makes a difference | 20:52 |
| mwhudson | jam: would be interesting to quantify the differences | 20:52 |
| mwhudson | jam: the main ones i would suspect are (1) twisted.conch rather than openssh (2) system load on crowberry | 20:53 |
| jam | mwhudson: quantify the diff between crowberry and chinstrap? | 20:53 |
| mwhudson | jam: perhaps not the word i really meant | 20:53 |
| mwhudson | understand | 20:53 |
| mwhudson | and yes, difference in the details of the repo being served | 20:54 |
| mwhudson | jam: did you say branching from staging was faster? | 20:54 |
| mwhudson | the staging codehost is much less loaded than the prod once | 20:54 |
| jam | mwhudson: I haven't tested download-to-local | 20:54 |
| jam | I was going to try download from staging as part of all this | 20:55 |
| jam | and just noted that staging => chinstrap was 3m+ while staging => vila's babune was 1m50s | 20:55 |
| jam | which is probably local cpu load on the target machine | 20:55 |
| wadesworld | hmm...actually, I just noticed something...this project was a conversion from CVS...it appears that it created a 2a branch at project, but it created another branch at project/branches/HEAD which has a format of "unnamed" | 20:56 |
| jam | wadesworld: if you use 'info -v' I would guess you'll find the repo is the same format, but the Branch at HEAD is different | 20:57 |
| mwhudson | jam: so yes measurements of identical repos from staging chinstrap and prod would be very interesting i suspect | 20:57 |
| jam | this doesn't really matter for what you're doing | 20:57 |
| jam | mwhudson: hmm... looks like paramiko versus openssh might also play a significant role | 20:58 |
| jam | (locally) | 20:58 |
| mwhudson | jam: oh | 20:59 |
| wadesworld | yeah, HEAD is branch format 6, meta directory format 1 | 21:00 |
| wadesworld | was the "doesn't matter" comment direct at me or mwhudson? | 21:00 |
| jam | mwhudson: well, it didn't make a big difference in the 'total time spent' | 21:01 |
| jam | paramiko was actually slightly faster in that regard | 21:01 |
| jam | 236s vs 240s | 21:01 |
| jam | mwhudson: I've uploaded 2 more graphs | 21:01 |
| mwhudson | jam: i'm not sure i have any time to spend on this today | 21:02 |
| mwhudson | jam: happy to look when you have some conclusions though! | 21:02 |
| servilio | hi! I am reading on how to track multiple svn branches of a project in one source tree from https://lists.ubuntu.com/archives/bazaar/2008q3/047779.html | 21:03 |
| wadesworld | jam - should I run upgrade on HEAD? | 21:03 |
| servilio | wouldn't it be the same to do a bzr pull for the main parent? | 21:04 |
| servilio | instead of a merge, I mean | 21:04 |
| jam | wadesworld: I think you can without any problems | 21:04 |
| jam | wadesworld: doesn't matter is for you | 21:04 |
| jam | servilio: I don't know why he is recommending 'merge', I would have thought "pull" would have been better | 21:05 |
| jam | however, that is 2008, so it may just be old info | 21:05 |
| servilio | jam: I know, that's the other reason for asking here | 21:07 |
| jam | servilio: so *I* would say keep the branches pristine at those locations | 21:07 |
| jam | and only run 'bzr pull' | 21:07 |
| jam | and then do other things manually | 21:08 |
| jam | however, from what I can tell | 21:08 |
| jam | he is talking about merging a feature into the 'trunk' branch | 21:08 |
| jam | and once you've done a local action | 21:08 |
| jam | you can no longer 'pull' | 21:08 |
| jam | you have to 'merge' | 21:08 |
| servilio | jam: the source tree wouldn't contain any changes, is a hosting location | 21:08 |
| jam | servilio: if you are just tracking 'trunk' and not doing any local changes, I'm pretty sure 'bzr pull' is what you want | 21:09 |
| servilio | jam: great, thanks! will give it a test | 21:12 |
| jam | mwhudson: interestingly, things are looking pretty shoddy with the 'real-world' repo from chinstrap | 21:12 |
| mwhudson | jam: aha! your problem :) | 21:12 |
| * mwhudson runs away dodging to avoid the gunfire | 21:12 | |
| jam | mwhudson: :) | 21:13 |
| jam | mwhudson: lots of "245.277 creating new compressed block on-the-fly" lines in .bzr.log on chinstrap | 21:13 |
| wadesworld | as predicted, rununing upgrade on HEAD had no effect - bzr merge still hangs | 21:16 |
| jam | wadesworld: right, the only change I would expect is that 'bzr info' will show you 2a now | 21:21 |
| wadesworld | yep | 21:21 |
| MTecknology | launchpad source code was only recently released publicly | 21:21 |
| MTecknology | ^wrong chan | 21:22 |
| wadesworld | still hanging as soon as I enter my password after bzr merge though :( | 21:22 |
| jam | wadesworld: just to confirm 'bzr info' locally also says 2a, right? | 21:22 |
| wadesworld | correct | 21:22 |
| MTecknology | I'm going to start a pretty big project. I plan to have a core branch then sub branches for each "module". For example, the core will only check if a module exists if the page is requested. If the module exists then it's loaded. I want different users working on each of these modules. I think LP is organized dlike this, but I have no idea how to setup branches liek this. The last I knew, bzr can handle these types of branches. | 21:30 |
| MTecknology | Any suggestions how to setup branches like this? | 21:33 |
| jam | MTecknology: well, if you just do "bzr init" in the subdirectories first, things generally work ok | 21:38 |
| jam | but in the parent tree it will show as "unknown" and not let you add them (though you can ignore them) | 21:38 |
| jam | you may want to look at the project 'scmproj' | 21:39 |
| jam | which is an initial attempt at making something like "bzr checkout" grab all of the branches needed, and build the whole collection | 21:39 |
| jam | there is also "bzr-externals" though that code base is quite new | 21:39 |
| MTecknology | jam: when I make a commit on the parent, will that commit all the changes in the others or just parts required to pull? | 21:42 |
| MTecknology | I think bzr-externals is what I heard of | 21:42 |
| jam | MTecknology: I'm pretty sure scmproj uses a "project-commit" to do a recursive commit | 21:43 |
| jam | bzr-externals was just announced ~last week | 21:43 |
| * GaryvdM is away: I'm sleeping | 21:43 | |
| MTecknology | stu mentioned something a while ago about it | 21:44 |
| MTecknology | jam: is bzr-externals something I could use with launchpad? | 21:45 |
| MTecknology | jam: I'm looking at this - http://bazaar-vcs.org/NestedTreesDesign | 21:49 |
| jam | MTecknology: I'm pretty sure both bzr-externals and scmproj can be used with Launchpad, I think they mostly define stuff as regular branches | 21:52 |
| jam | MTecknology: NestedTrees is not fully implemented | 21:52 |
| jam | It may get specific priority in the next 6 months, depending on how it relates to some of the other stuff we are working on. | 21:52 |
| MTecknology | ok, thanks :) | 21:53 |
| MTecknology | iteresting... michael@panther:~$ aptitude search bzr | 21:56 |
| MTecknology | Bus error | 21:56 |
| MTecknology | this is wierd....... | 21:59 |
| jam | I wouldn't have expected that from aptitud | 22:04 |
| MTecknology | jam: even after reboot.... and aptitude update - trying to upgrade w/ apt-get :S | 22:05 |
| wadesworld | jam any suggestions on other help I might get for troubleshooting this merge hang? I copied my local repo over to a completely different machine and still get the same hang....should I file a bug or hit a developer mailing list? | 22:07 |
| MTecknology | !info bzr-externals | 22:08 |
| ubottu | Package bzr-externals does not exist in karmic | 22:08 |
| jam | wadesworld: you said you are using sftp, rigth? | 22:08 |
| jam | I would make sure that you can sftp data off that machine | 22:08 |
| wadesworld | correct | 22:08 |
| jam | MTecknology: given that bzr-externals is < 1 week old | 22:09 |
| jam | I'm sure it hasn't been packaged yet | 22:09 |
| jam | bzr branch lp:bzr-externals should get you the code, though | 22:09 |
| jam | mkdir -p ~/.bazaar/plugins | 22:09 |
| jam | bzr branch lp:bzr-externals ~/.bazaar/plugins/externals | 22:09 |
| jam | *I* have not audited the code, etc. And given its age, I wouldn't trust it a whole lot yet | 22:09 |
| wadesworld | jam...the hang is only happening on a merge...bzr branch/pull with sft work fine | 22:10 |
| wadesworld | er, sftp | 22:10 |
| MTecknology | jam: thanks - I'll try it soon | 22:10 |
| wadesworld | and push works fine too | 22:10 |
| jam | wadesworld: well, then a workaround is "bzr branch sftp://... temp; cd trunk, bzr merge ../temp" | 22:10 |
| pickscrape | Is it possible to get back the message of a commit that failed without having to type it in all over again? | 22:10 |
| jam | merge not working is quite strange | 22:10 |
| jam | pickscrape: given that you're asking, I'd probably say no | 22:11 |
| wadesworld | agreed - that's what we've done so far - but I'm just trying to figure out who can help me get to the bottom of it | 22:11 |
| jam | some things like 'qcommit' stash the message and try to use it again | 22:11 |
| jam | wadesworld: you can try starting merge | 22:11 |
| jam | and then doing Ctrl+| | 22:11 |
| jam | to interrupt the process, which should drop you into a debugger | 22:11 |
| jam | and then you can do "bt" to get a backtrace to see what it thinks it is trying to do | 22:11 |
| jam | The only problem is that ^| may interrupt the ssh connection | 22:12 |
| jam | (It is SIGQUIT) | 22:12 |
| * pickscrape adds to the "MyTopUiComplaints" page | 22:12 | |
| mwhudson | poolie: mildly curious why you nominated me as a reviewer on https://code.edge.launchpad.net/~mbp/bzr/remove-logging/+merge/14942 | 22:16 |
| wadesworld | jam http://pastebin.org/54668 | 22:16 |
| poolie | because it might break your integraiton | 22:16 |
| thumper | who is working on the daily ppa builds? | 22:17 |
| poolie | if you don't rely on logging, no problem | 22:17 |
| jam | wadesworld: that would hint that we may be trying to open a directory as a file, and your sftp server is letting open it, but not return any content | 22:17 |
| thumper | or 2.1b3 into the beta ppa? | 22:17 |
| jam | which is a bit strange | 22:17 |
| jam | thumper: dailies are from james_w I though | 22:17 |
| jam | thought | 22:17 |
| jam | johnf is doing the releases | 22:17 |
| jam | but IIRC has not built any of the 2.1 releases | 22:17 |
| jam | because of concerns about getting a coherent set of plugins into the ~bzr-beta-ppa | 22:18 |
| wadesworld | hmm...that actually makes a little sense, since the sftp server is the only commonality in the problem | 22:18 |
| poolie | jam: it's ctrl\ | 22:18 |
| jam | poolie: sure, though whatever it is worked for wade :) | 22:18 |
| jam | \ and | are on the same key at least | 22:18 |
| wadesworld | hmm...I was hoping for a permissions problem, but don't see anything obvious...still looking | 22:20 |
| wadesworld | strange that pull works though and merge doesn't - one would think they would use the same sftp functionality | 22:21 |
| jam | wadesworld: I'm not positive if pull allows 'mergeables' which would be a bundle, and thus a file to read | 22:21 |
| jam | I thought it did, though | 22:21 |
| jam | the underlying sftp implementation is identical for sure | 22:22 |
| jam | wadesworld: so looking at the code, both call read_mergeable | 22:22 |
| jam | wadesworld: one possiblity is to do "bzr merge" rather than "bzr merge location" | 22:23 |
| jam | as if you don't supply a location, we don't try to read mergeable | 22:23 |
| jam | which may be why "bzr pull" is working for you | 22:23 |
| jam | since I assume you did "bzr branch $location" at some earlier time | 22:23 |
| jam | and then just plain "bzr pull" to update it | 22:23 |
| jam | can you try "bzr pull $location" ? | 22:24 |
| jam | wadesworld: ^^ | 22:24 |
| wadesworld | sure thing - and you're correct | 22:24 |
| bpierre | Hi | 22:24 |
| jam | wadesworld: so I think we've seen this in the past... | 22:25 |
| jam | and we had a workaround that if the path ended in '/' we wouldn't try to read it as a file | 22:25 |
| jam | but that code path got updated | 22:25 |
| jam | and people thought that was hackish, etc. | 22:25 |
| jam | and apparently nobody has been using sftp as much recently | 22:25 |
| bpierre | I'm trying to debug one of my plugins, and even when using -Derror, not all stack traces get outputted to stderr, is this normal? | 22:26 |
| jam | hmm.. that said, everything works here even with sftp | 22:26 |
| jam | bpierre: I would think that with -Derror things should get written, however I wouldn't say it always works | 22:27 |
| bpierre | so it's a bug? | 22:28 |
| jam | bpierre: I don't know the details, but sounds like one | 22:29 |
| bpierre | jam: I modified it like this: http://pastie.org/703349 | 22:29 |
| jam | bpierre: I'm not sure that "print exception(..." is the same as displaying the traceback. I'd have to dig into the code a bit more to understand your patch | 22:30 |
| wadesworld | jam, you're right - it appears that bzr pull $location is suffering the same hang | 22:31 |
| bpierre | this move the code from 'report_user_error' to 'report_exception' | 22:31 |
| bpierre | I'll make a merge request, and we'll see | 22:31 |
| jam | bpierre: did it give you the tracebacks you expected? | 22:35 |
| jam | wadesworld: I'll note that I'm unable to reproduce the hang here | 22:36 |
| jam | are you on Mac? | 22:36 |
| jam | (I think I remember that) | 22:36 |
| wadesworld | yep | 22:36 |
| jam | I tried paramiko, and openssh as the local connection | 22:36 |
| jam | both worked | 22:37 |
| wadesworld | happens on both my Intel Mac and PowerPC Mac | 22:37 |
| jam | my old laptop used to be a Mac PPC | 22:37 |
| jam | so it may be something with mac's openssh | 22:37 |
| jam | well, whatever ssh they use | 22:37 |
| jam | though I would have thought the server would matter more than the client | 22:37 |
| wadesworld | openssh | 22:37 |
| jam | wadesworld: try "export BZR_SSH=paramiko" | 22:37 |
| jam | and then try again | 22:37 |
| wadesworld | OK | 22:37 |
| jam | bzr pull $location | 22:37 |
| bpierre | bpierre: yes | 22:38 |
| bpierre | ... | 22:38 |
| bpierre | must be tired, obviously I meant to respond to you jam! | 22:39 |
| wadesworld | appears to not have any effect...one thing I can do later tonight is copy the shared repo on the server over to a different box running Ubuntu rather than OpenBSD and see if that makes a difference | 22:39 |
| jam | wadesworld: so the *server's* sftp implementation would make a lot of sense | 22:40 |
| jam | my server is a really old FC3 box running OpenSSH_4.2p1 | 22:40 |
| jam | please report a bug about sftp trying to read a directory as a file | 22:40 |
| jam | and include your ssh implementation versions | 22:40 |
| jam | we might just restore the old "if this really looks like a dir, don't try it" code path | 22:41 |
| wadesworld | Ok, will do | 22:41 |
| jam | but I remember abentley objecting because "http://.../" could be a file | 22:41 |
| jam | even though, we actually try to read from ".../foo" always in the current code path | 22:41 |
| jam | (rather than .../foo/) | 22:41 |
| wadesworld | hmm...there's no call to determine if it is a dir before trying to read? (I guess not, or you would have used it) | 22:42 |
| jam | bpierre: ahh, I see the issue. The formatting of your patch hid the '_' from me | 22:43 |
| jam | print_exception does indeed print the traceback | 22:43 |
| jam | do you have apport installed? | 22:43 |
| jam | looking at the code | 22:43 |
| jam | IOError, KeyboardInterrupt, and MemoryError are never given full tracebacks | 22:43 |
| jam | and report_bug which is the catchall for unknown errors | 22:44 |
| jam | will try to use apport first | 22:44 |
| jam | and then falls back to showing a traceback, etc. | 22:44 |
| jam | bpierre: so you may want to clarify the bug with "when a plugin raises IOError" or something like that | 22:44 |
| jam | depending on what exception you are actually getting. | 22:45 |
| spiv | wadesworld, jam: IIRC, BSDs tend to allow you to open directories as if they are files | 22:45 |
| jam | spiv: which is fine, as long as trying to read them would return something other than a hang | 22:45 |
| spiv | The results are rather nonsensical, but the open syscall doesn't actually fail. | 22:45 |
| jam | if it raised an error | 22:45 |
| jam | or returned no content | 22:45 |
| jam | but this seems to just hang indefinitely | 22:45 |
| spiv | Yeah, that's odd. | 22:45 |
| jam | spiv: I thought you could always open() a directory, since that lets you fchdir() | 22:45 |
| spiv | Well, I've also seen read on the opened directory work. | 22:46 |
| wadesworld | I'll file a bug tonight with complete details - I'm also happy to give whomever works it access to my server for testing | 22:46 |
| jam | spiv: orig_dir_fd = open(".", O_RDONLY, 0) is what we do in _readdir_pyx.pyx | 22:46 |
| jam | so it better work :) | 22:46 |
| spiv | "work", in that it gave the on-disk representation of the directory! But my first-hand knowledge of BSDs is rather old. | 22:46 |
| jam | wadesworld: mua ha ha | 22:46 |
| jam | spiv: well, that would be fine too, as we would realize right away that it wasn't a bundle | 22:47 |
| wadesworld | thanks so much for your help jam - I'll file the bug tonight | 22:47 |
| wadesworld | this has really been hurting my efforts to bzr-convert my colleague :) | 22:48 |
| jam | wadesworld: also, if you could give the result of something like manually doing | 22:48 |
| jam | sftp host | 22:48 |
| jam | get directory | 22:48 |
| mwhudson | bugs like https://bugs.edge.launchpad.net/launchpad-code/+bug/484197 make me want to cry | 23:04 |
| ubottu | Launchpad bug 484197 in launchpad-code "Branches stacked on another project report errors" [Undecided,New] | 23:04 |
| bpierre | jam: ok, done: https://code.launchpad.net/~benoit.pierre/bzr/fix-error-debug-flag/+merge/14971 | 23:05 |
| bpierre | thanks | 23:05 |
| jam | mwhudson: I've shed my tears for stacking. Now I just soldier on | 23:06 |
| mwhudson | jam: probably wise | 23:06 |
| jam | bpierre: I'm pretty surprised that ValueError wasn't being reported correctly. | 23:07 |
| jam | also, your patch is going to cause double-tracebacks in some cases | 23:07 |
| jam | so I don't think it is quite the right answer | 23:07 |
| bpierre | which cases? | 23:09 |
| jam | bpierre: noted in a review of your patch | 23:09 |
| jam | bpierre: I'm pretty sure that report_bug(exc_info, err_file) always displays the traceback | 23:09 |
| jam | def report_bug_legacy(exc_info, err_file): | 23:09 |
| jam | """Report a bug by just printing a message to the user.""" | 23:09 |
| jam | trace.print_exception(exc_info, err_file) | 23:09 |
| jam | so if you don't have apport installed | 23:09 |
| jam | we always print the exception traceback | 23:10 |
| jam | I realize this is only with -Derror, but it is still a bit ugly to see it twice | 23:10 |
| bpierre | but report_bug is not going to be called, no? | 23:10 |
| bpierre | I do return before the bulk of report_exception's body, where different functions get called depending on the type of exception | 23:12 |
| bpierre | or am I missing something obvious? | 23:12 |
| poolie | igc, hi, good morning? | 23:16 |
| lifeless | poolie: call over? | 23:17 |
| jam | bpierre, then I'd have to review your code more thoroughly. I should have stopped working 15 min ago | 23:18 |
| bpierre | :) | 23:18 |
| jam | bpierre: I would quickly caution that I don't think print_exception calls log_exception_quietly which dumps the data into .bzr.log | 23:20 |
| jam | which I think we want | 23:20 |
| * jam runs away | 23:21 | |
| mwhudson | um, sanity check please? http://pastebin.ubuntu.com/321152/ <- this is insane, right? | 23:36 |
| spiv | mwhudson: that does seem crazy, and I can reproduce using lp:subvertpy | 23:42 |
| spiv | mwhudson: bug report please :) | 23:43 |
| spiv | mwhudson: at a quick guess it's pushed the working tree with tip's contents, but then set the parent revids correctly. | 23:44 |
| mwhudson | spiv: yes, the wts are the same | 23:44 |
| spiv | Yeah, and diff -r tag:subvert-0.7.0.. gives the same diff as found in the new tree | 23:45 |
| mwhudson | spiv: push -r3 is even stranger | 23:46 |
| mwhudson | spiv: https://bugs.edge.launchpad.net/bzr/+bug/484516 | 23:52 |
| ubottu | Launchpad bug 484516 in bzr "bzr push -r $revspec ../foo creates branch with working tree from tip, not that of $revspec" [Undecided,New] | 23:52 |
| * mwhudson upgrades things | 23:53 | |
| mwhudson | oh good (?) it happens with everything upgraded to 2a too | 23:55 |
Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!
