| gambler | hi | 00:38 |
|---|---|---|
| gambler | why doesnt the fedora bazaar version commands match the ones in the webpage documentation | 00:38 |
| gambler | ah i c diff pkg | 00:39 |
| gambler | thats really confusing | 00:40 |
| poolie | gambler: you want bzr not baz | 00:41 |
| === mw is now known as mw|out | ||
| Necoro | hey - if I've a working tree ... and want to checkout the tree from to revisions before - how do I do this? | 00:56 |
| Necoro | s/to/two/ | 00:56 |
| Necoro | and I want to do this _in place_ | 00:56 |
| beuno | Necoro, just specify the revision with -r | 00:59 |
| beuno | I suspect -r -2 might work | 00:59 |
| Necoro | but using which command? | 00:59 |
| Necoro | co does not work - as there is already a checkout in place | 00:59 |
| Necoro | merge ... does strange things | 01:00 |
| beuno | Necoro, I don't follow then | 01:00 |
| beuno | you already have a checkout | 01:00 |
| beuno | and you want to go back 2 revisions? | 01:00 |
| Necoro | yes | 01:00 |
| beuno | oh | 01:00 |
| beuno | bzr revert -r X | 01:00 |
| Necoro | that's easy -.- | 01:01 |
| beuno | like most things with bzr :) | 01:01 |
| Necoro | thanks :) | 01:01 |
| Necoro | ah ... some things are just not possible ;) | 01:01 |
| beuno | Necoro, file bugs about it and give it time... we've got amazing developers :) | 01:02 |
| Necoro | I can think of trying to merge two branches that bzr thought don't have a common ancestor ;) | 01:02 |
| Necoro | yeah :) ... I tend to just ignore this issues ;) | 01:02 |
| * Necoro adds #bzr to the list of standard channels | 01:03 | |
| beuno | Necoro, welcome :) | 01:04 |
| Necoro | *g* | 01:04 |
| beuno | jelmer, btw, If there's anything I can help you with the bzr-gtk release, let me know :) I'm eager to see a new version out there | 01:06 |
| fullermd | Hm. I merge unrelated branches with some regularity :p | 01:14 |
| Necoro | fullermd: how? | 01:17 |
| * fullermd shrugs | 01:17 | |
| fullermd | merge -r0..-1 | 01:17 |
| Necoro | hmmk | 01:17 |
| * Necoro adds this to the list of interesting bzr commands | 01:17 | |
| fullermd | Not what you want if you INTEND them to be considered related, of course. But mine really are unrelated. | 01:18 |
| Necoro | oh | 01:18 |
| Necoro | I indeed want to have them considered related ... | 01:18 |
| fullermd | To do that requires the ability to alias file and revision id's. Lot tricksier. | 01:19 |
| fullermd | (both on the code side, and UI-wise doing it I expect) | 01:19 |
| Necoro | fullermd: oh ... than it's not worth it ;) | 01:20 |
| fullermd | Oh, most things are worth it. Someday(tm). | 01:29 |
| Necoro | hehe ... but not to have ~2-3 files merged ;P | 01:30 |
| ubotu | New bug: #220464 in bzr "Bazaar doesn't detect its own stale locks" [Undecided,New] https://launchpad.net/bugs/220464 | 03:26 |
| bob2 | is there any way to get data from rich-root-pack branches into pack-0.92? even bundle doesn't work. | 03:26 |
| jamesh | bob2: no | 03:29 |
| jamesh | bob2: abentley says he's working on one format to rule them all though | 03:29 |
| fullermd | Theoretically, a rich root format (not -pack, but its successor) will be The Format at some coming point. | 03:30 |
| jamesh | fullermd: I think that's what abentley's pack-1.4 (or maybe pack-1.5 now) format is going to be | 03:33 |
| abentley | bob2: rich-root-pack wouldn't exist if pack-0.92 could represent all its data. | 05:50 |
| bob2 | oh, I know, but since I don't care about the root richness, I was hoping I could throw some info away and get it into pack-0.92 :) | 05:52 |
| jamesh | bob2: throwing info away would give you different revisions | 05:56 |
| emgent | hello people | 06:00 |
| === keithy_ is now known as keithy | ||
| poolie | hello emgent | 06:35 |
| poolie | lifeless/spiv: what would you say to a source test that forbids the use of the assert statement? | 07:15 |
| spiv | poolie: I have mixed feelings about that | 07:19 |
| spiv | Because I think that the assert statement is a sane thing to use sometimes. But it's very easy to misuse, so perhaps disallowing it entirely is the best policy. | 07:20 |
| spiv | So I'm +0.5 on it, I guess. | 07:21 |
| poolie | spiv: what kind of thing? | 07:22 |
| poolie | i mean | 07:22 |
| poolie | can you give me a good case for committing it in mainline code? | 07:22 |
| spiv | For a purely internal-to-bzrlib API, an assert that e.g. "type(revision_id) is str" could be reasonable. The sort of thing that would catch misuse of an API within bzrlib. | 07:23 |
| poolie | in C i'd certainly do that | 07:24 |
| poolie | but the combination of not having a clear distinction between debug and other builds | 07:24 |
| poolie | means it just doesn't seem like a good tradeoff | 07:25 |
| spiv | The thing that makes me lean towards banning them is plugins. | 07:25 |
| poolie | all you really gain is slightly shorter syntax, right? | 07:25 |
| poolie | mm? | 07:25 |
| spiv | Because it's too easy for a plugin to accidentally trip over an assert than was intended to catch a bzrlib-only mistake, and really that shouldn't be a user-visible error. | 07:25 |
| spiv | Right, you can explicitly use "raise AssertionError, ..." instead, but it feels a bit funny to raise AssertionError. Probably that's not a hard habit to break. | 07:26 |
| spiv | So I share your feeling regarding debug builds: asserts are the sort of thing that should happen for developers only, to help them know when they've misused an API or similar, to make development go faster. They shouldn't be depended on to preserve the integrity of the system, e.g. in the face of bad user input. | 07:29 |
| spiv | Hmm, lag. | 07:29 |
| spiv | But of course we don't have debug builds, so I guess we never have a good time for an assert :) | 07:29 |
| spiv | I guess I've talked myself into agreeing with you :) | 07:30 |
| thumper | does bzr work on python 2.3? | 07:58 |
| thumper | or does it require 2.4? | 07:58 |
| jamesh | thumper: it uses decorators, which were introduced in 2.4 | 07:58 |
| thumper | jamesh: ta | 07:58 |
| jamesh | do people still use 2.3? :) | 07:59 |
| poolie | jamesh: rhel has something remarkably old iirc | 08:00 |
| jamesh | ah. | 08:01 |
| jamesh | 2.4 is around 3.5 years old, so I guess it'd still be in enterprise distros | 08:01 |
| poolie | and i guess their users are also often (understandably) slow to upgrade | 08:02 |
| poolie | but even that may be changed now | 08:02 |
| Peng | My shared web host has 2.4 installed, but /usr/bin/python points to 2.3. | 08:02 |
| jamesh | poolie: did you see my email about problems with the new bzrtools package? | 08:02 |
| poolie | "import parser" ftw :) | 08:02 |
| jamesh | I remember making pygtk-2.0 depend on Python 2.2 back in 2003 as being a bit contentious | 08:04 |
| jamesh | that was 2 years after 2.2's release | 08:04 |
| poolie | jamesh: i see it now | 08:10 |
| poolie | jamesh: i'm on a call, could you file a bug and assign it to me marked High? | 08:10 |
| poolie | thanks | 08:10 |
| jamesh | poolie: okay. | 08:10 |
| jamesh | poolie: bug filed at https://bugs.edge.launchpad.net/bzrtools/+bug/220519, but I can't change its importance | 08:18 |
| ubotu | Launchpad bug 220519 in bzrtools "bzrtools 1.4.0-1~bazaar1~hardy1 package installs plugin in wrong location" [Undecided,New] | 08:18 |
| poolie | jamesh: hm didn't someone else mention a problem like this in setup.py? | 08:21 |
| jamesh | poolie: the thread about getting bzr to check in extra directories might be the answer to this bug | 08:22 |
| poolie | it seems like the policy regarding this has changed in python? | 08:22 |
| poolie | i guess not | 08:23 |
| jamesh | having bzrtools installed the way it is is not an inherently bad thing (other than the fact that bzr can't find it) | 08:23 |
| poolie | i just don't understand why we got those bugs all this week | 08:23 |
| Peng | Blah, bzr.dev and bzr-svn 0.4.9 don't go together so well. | 08:23 |
| jelmer | beuno: thanks | 09:23 |
| awilkins | jelmer: Branching-schemes in bzr-svn ; is it essential to set them BEFORE pulling things? | 11:37 |
| awilkins | I ask because I had pulled around 9600 revisions, then I tried pulling a branch ; the extra 100MB of revisions told me that this wasn't properly noticing that it was a branch. I've set the branching scheme and now a pull on the trunk wants to start again at r 1 | 11:38 |
| awilkins | I used the list scheme ; I've listed trunk, branches/* | 11:38 |
| awilkins | (lines, not CSV) | 11:38 |
| awilkins | Should you list trunk as a branch, for starters :-) | 11:39 |
| awilkins | Ok, answered that one ... "Yes", or it sulks | 11:40 |
| Peng | It didn't auto-detect the scheme correctly? | 11:50 |
| awilkins | It's a bit of a stinky repo layout | 11:50 |
| Peng | And shouldn't that be trunkN? | 11:50 |
| Peng | Rather than listing them or something? | 11:50 |
| Peng | Ah. | 11:50 |
| awilkins | Peng: There is a "list" branching scheme that just takes a list of paths (or globs) | 11:51 |
| Peng | Ok. | 11:51 |
| awilkins | If you do a --set it pops EDITOR open for you to enter it | 11:51 |
| Peng | If it's just trunk and branches, trunkN should be good enough.. | 11:51 |
| awilkins | Peng: It didn't seem to be - it was adding more than 100MB of extra packs when it should have been a few extra revisions for tweaks to the files (things like changing version numbers) | 11:52 |
| awilkins | It's a large tree, so that's what I'd expect if it was just thinking "hmm, this huge folder has been copied" | 11:53 |
| awilkins | The tree layout has been messed around a bit since r0 as well, so the lack of some file features in bzr (like copy) is probably hurting too. | 11:54 |
| awilkins | But these particular cases should be quick ; and it's doesn't explain the sudden desire for it to pull all 9600 trunk revisions again | 11:55 |
| awilkins | Maybe I pulled it with an old bzr-svn and the new mappings hate the old ones. | 11:56 |
| * awilkins trashes it and schedules a job for it to pull again overnight | 11:56 | |
| awilkins | Takes about 10 hours or more to get a full trunk pull on this repo (oh for horizon history...) | 11:57 |
| awilkins | Horizon history would be even cooler if it automatically worked out the ancestry on a branch you asked for and pull revisions back far enough to get it. | 11:58 |
| awilkins | So the horizon could move backwards even after it had been set at some recent revision in trunk. | 11:59 |
| awilkins | Mind, the svn client has been pulling just a *working copy* of this trunk for the pas 2 hours (over a LAN), so 10 hours sounds almost reasonable for a 9600 revision history right now) | 12:00 |
| awilkins | Not sure if it's the shiny new full-disk encryption crapware they've foisted on us contributing to that either | 12:00 |
| === pmezard_ is now known as pmezard | ||
| === mrevell is now known as mrevell-lunch | ||
| === bigdo2 is now known as bigdog | ||
| === thekorn_ is now known as thekorn | ||
| === mrevell-lunch is now known as mrevell | ||
| black_ | was wondering, if you have two branches, and you want them to diverge say for something like a database connection string, but you still wanted to push and pull and merge between them, how do you mark a revision such that when people pull from you they won't get that revision? I've tried "revert ." to try to mark things but when I start merging back and forth the branches will eventually end up the same. Please excuse the noobness of the que | 14:09 |
| black_ | stion :) | 14:09 |
| Peng | Yeah, I don't think you can do that. | 14:10 |
| black_ | ahh, darn, that stinks then :) | 14:10 |
| LeoNerd | Isn't a DB connection string more of a config item than source code, anyway? | 14:10 |
| black_ | well I through that out as an example | 14:10 |
| black_ | in the past I've had two branches of a website that I had running on two different servers and certain paths had to be different based on which server they were on | 14:11 |
| black_ | but I still wanted to keep them in sync | 14:11 |
| black_ | s/through/threw | 14:12 |
| black_ | I'm a long time svn user, and since you have to manage merges yourself anyway this wasn't much of a problem (other than all the hard work managing the revisions by hand) | 14:12 |
| black_ | bzr seems like just the tool to solve the problem, but I need to be able to mark certain revisions as already merged | 14:13 |
| black_ | without actually merging the content | 14:13 |
| james_w | so you tried merging and then "revert ."? | 14:14 |
| LeoNerd | One idea that occurs to me is you could keep the "abstract" stuff in one branch, then pull two other branches off that for the specific changes | 14:14 |
| LeoNerd | What's really ideally needed in code I suspect would be a postwrite/preread filter hook | 14:14 |
| LeoNerd | So you could filter the changes, so what bzr sees/writes is a generic version | 14:15 |
| black_ | I start out the same, make appropriate changes on one branch, commit the changes to that branch, switch to the other branch merge the changes in but then do a "revert ." to back out the changes while still keeping a record of the change, however in practice this doesn't work because as soon as you start merging back and forth again, bzr is smart enough to be able to reconcile everything and make them the same, which in this case isn't what I w | 14:15 |
| black_ | ant. | 14:15 |
| black_ | I really like the idea of an abstract branch | 14:16 |
| black_ | that might work nicely | 14:16 |
| black_ | just make sure you always make your changes in the abstract branch | 14:16 |
| LeoNerd | Also, you might consider "bzr shelve" to temporarily revert out the local changes, then commit what's "clean", then unshelve it back in again | 14:20 |
| LeoNerd | I often do that for doing partial commits | 14:20 |
| black_ | thanks for the help :) | 14:51 |
| Necoro | hmm ... just noticed that "repository/obsolete_packs" needs the most memory in my .bzr dir | 14:51 |
| Necoro | is this cleaned automatically sometimes, is there a command to clean it - or shouldn't it be cleaned at all? | 14:52 |
| Peng | That's odd. | 14:52 |
| Peng | Oh, never mind, not impossible. | 14:52 |
| Peng | Yes, it's cleaned automatically. | 14:53 |
| Necoro | and when? - running "bzr pack" even increased it ;P | 14:53 |
| Peng | It's cleaned when repacking is done. | 14:54 |
| Peng | When you run "bzr pack" or auto-packing happens, it deletes everything in obsolete_packs, copies the current packs and indexes to it, and then does the packing. | 14:55 |
| jam | howdy all | 15:13 |
| Peng | Wait, so is bialix just on vacation or leaving permanently? | 15:16 |
| === mw|out is now known as mw | ||
| jam | Peng: well, last year he took "vacation" for a short time and came back | 15:18 |
| jam | Not sure how long it will be this time | 15:18 |
| Peng | He said he was leaving permanently last time? | 15:18 |
| jam | no, that he was taking a break/vacation, which is what he said at the beginning of this thread, unless it has changed | 15:19 |
| Peng | Ok. | 15:20 |
| Peng | His message sounded very final though. | 15:21 |
| jam | Peng: it does a bit, now that I've re-read it. We'll see, though. I seem to recall him sounding like he would be going away fairly permanently last time, and then he seemed to come back rather quickly.... It would be a shame to loose him | 15:23 |
| === mrevell_ is now known as mrevell | ||
| * lamont wonders about .bzr.log and when/why it comes to exist | 15:35 | |
| dato | always afaik | 15:35 |
| lamont | so.. when does bzr create it in the tree, instead of $HOME? | 15:40 |
| dato | hm, I was talking about the one in ~ | 15:42 |
| black_ | is there a way to push or otherwise backup an entire repository? can you simply copy a repo and all it's branches to another computer and then reasonably expect to be able to push and pull from the same rep/branches it was copied from? | 15:49 |
| black_ | curious how other people were handling this | 15:51 |
| jam | lamont: the only time I've seen it show up in the tree is when running a test which sets $HOME to $CWD | 16:06 |
| lamont | jam or if $HOME is unset or equal to "", it would appear. | 16:07 |
| lamont | my case was the former | 16:07 |
| statik | black_: yes, you can | 16:22 |
| korpios | black_: yeah, I've been wondering the same thing | 16:29 |
| black_ | I just figured it out | 16:35 |
| black_ | there is a plugin to do it | 16:35 |
| black_ | repo-push | 16:36 |
| Noia | is there a way to pass the password as part of an alias when performing a commit? | 16:51 |
| Noia | I commit and update a whole lot, and one of the slowest things is typing my password >.< | 16:56 |
| james_w | Noia: over ssh> | 16:57 |
| Noia | yea, bzr+ssh:// | 16:57 |
| james_w | have you though about ssh-agent? | 16:58 |
| Noia | ssh-agent? | 17:01 |
| james_w | ah, sorry, you need keys set up to do that, but it is a whole lot easier in the long run | 17:02 |
| Noia | hmm | 17:04 |
| === thekorn_ is now known as thekorn | ||
| Noia | I quite like this way of developing thugh | 17:07 |
| Noia | I have a server which has the repo, then a development server and a production server, both of which build off the same repo | 17:08 |
| Noia | so when I develop something I just push to the repo, and update the dev server, then when I want to roll out I just update the production server | 17:08 |
| Peng | jelmer: bzr.dev isn't compatible with bzr-svn 0.4.9 anymore. What should I do? Use a different version of bzr? Is bzr-svn's 0.4 branch stable now? | 17:17 |
| ubotu | New bug: #220453 in bzr-gentoo-overlay "Branching a read-only HTTP branch (with no working tree) fails with bzr-1.4" [High,Confirmed] https://launchpad.net/bugs/220453 | 17:22 |
| === kiko-afk is now known as kiko | ||
| malept | hi, I've been attempting to install an HTTP smart server via fastcgi using the user guide, and I keep hitting a "NotBranchError" when trying to branch it (using 1.4rc2) | 18:20 |
| === mw is now known as mw|food | ||
| === mw|food is now known as mw | ||
| jelmer | Peng: no, there's nonthing non-experimental you can use with bzr.dev | 20:44 |
| Peng | That's unfortunate. | 20:45 |
| Peng | On the off-chance the PPA works, I could use the system version when I need bzr-svn. | 20:46 |
| Peng | I'm about to wander off, but. | 20:46 |
| Peng | How major are the changes necessary to make 0.4.9 work with bzr.dev? | 20:46 |
| * Peng wanders off. | 20:47 | |
| jam | Peng: I'm sure it is probably rather minor, do you know what the error is? | 20:47 |
| jelmer | Peng: I don't know, 0.4 may not be compatible with bzr.dev yet either | 20:47 |
| Peng | jam: Err. | 20:48 |
| Peng | jam: From knit.py, "ValueError: No default access_method or index any more". | 20:48 |
| jelmer | Peng: that should be a pretty easy fix to backport | 20:49 |
| jelmer | there's a couple of other ones I think though | 20:49 |
| jam | I think it just requires passing a single parameter | 20:49 |
| jelmer | jam: no, it relied on default arguments that lifeless removed in KnitVersionedFile's constructor | 20:50 |
| Peng | Oh, I didn't notice it's a VersionedFile thing. Lots of changes there... | 20:50 |
| * Peng wanders off now, for realz! | 20:50 | |
| jam | jelmer: which means you need to pass the parameter :) | 20:50 |
| jam | (/argument) | 20:51 |
| jelmer | jam: I ended up using a different function to create the knit | 20:51 |
| jelmer | since the only thing way to construct a knit index involves private classes | 20:51 |
| jelmer | I wouldn't mind if bzr releases were less often, that would save me from doing bzr-svn releases as often | 20:58 |
| jelmer | I'll try to do one before 1.4.0 is released though | 20:59 |
| radix | jelmer: is it actually necessary to do bzr-svn releases for every single bzr release? | 21:02 |
| radix | is it using internal bzr APIs that change every release? | 21:02 |
| jam | radix: we have had a tendency to break bzr-svn, we maintain "client" compatibility, but bzr-svn tends to hook in a bit deeper as an "implementor" | 21:03 |
| jam | so if we add an optional parameter, it needs to handle it | 21:03 |
| radix | OK | 21:03 |
| radix | actually I'm more annoyed with bzrtools breaking for every release:) | 21:04 |
| malept | hrm, I fixed my fastcgi problems (I think), but I've hit an AttributeError when trying to branch from the http smart server-enabled branch: http://dpaste.com/46365/ | 21:05 |
| abentley | jam: We don't do a very good job at maintaining client compatibility either. | 21:05 |
| foom | does ianc's benchmark suite have a webpage of historical results somewhere? | 21:06 |
| jam | abentley: we historically have done a fairly decent job at it, I think in the last few releases we've stopped trying as hard | 21:06 |
| foom | I ran across benchmark.bazaar-vcs.org but it seems to be dead. | 21:06 |
| abentley | jam: beg to differ. | 21:06 |
| malept | has anyone seen that particular error before? | 21:06 |
| abentley | Pretty much every release breaks something, and those that don't usually deprecate something. | 21:07 |
| jelmer | radix: yes, because bzr breaks the API every release (one exception so far in the history of bzr-svn) | 21:08 |
| radix | abentley: deprecations are great, I love deprecations | 21:09 |
| Peng | jelmer: Was the exception 1.3.1? :P | 21:09 |
| abentley | radix: Most end-users don't. | 21:09 |
| jam | abentley: I don't consider a deprecation a strict api breakage, though argubly the 'released' bzr should disable the deprecation warnings by default | 21:09 |
| jelmer | Peng: no, 1.2 | 21:10 |
| radix | abentley: well, I don't know about user-facing things, I'm assuming we're only talking about APIs | 21:10 |
| abentley | jam: I made a significant rewrite of graph-ancestry for bzrtools 1.4 just to avoid a deprecation warning. | 21:10 |
| radix | however, I do think deprecations are great compared to immediate breakage :) | 21:10 |
| abentley | radix: If I use a deprecated API, there are user-facing consequences. | 21:10 |
| radix | abentley: what are those? | 21:11 |
| abentley | radix: A deprecation warning is emitted. | 21:11 |
| jam | radix: a warning that you are usinga deprecated function | 21:11 |
| radix | abentley: IMO all python application mainpoints should filter out DeprecationWarning | 21:11 |
| radix | the only ones that shouldn't be are UserWarning (I guess) | 21:11 |
| abentley | radix: wearing my plugin author hat, that's not really relevant to me. bzr's deprecation handling is what it is. I try to cope. | 21:12 |
| radix | I guess I was just curious if bzrlib's API is breaking all the time *without* going through a period of deprecation | 21:12 |
| abentley | radix: Have a look at NEWS. | 21:13 |
| radix | abentley: ok, then switch back to your bzr developer hat and add a filter for DeprecationWarning in main :-) | 21:13 |
| jelmer | radix: it does for some APIs | 21:17 |
| jelmer | radix: but bzr-svn touches a couple of core parts of bzrlib | 21:17 |
| radix | jelmer: right, yeah, I understand bzr-svn is rather "deep" | 21:17 |
| radix | jelmer: thanks | 21:17 |
| Peng | Ba, like 5-10 seconds of network access to download one trivial revision. :P | 21:36 |
| Peng | Bah* | 21:36 |
| === kiko_ is now known as kiko | ||
| ubotu | New bug: #220806 in bzr "PyCurlTransport doesn't define the _remote_is_at_least_1_2 property" [Undecided,New] https://launchpad.net/bugs/220806 | 23:06 |
| igc | morning all | 23:13 |
| abadger1999 | Have there been any backwards incompatible API changes to bzrlib since 1.1? | 23:41 |
| abadger1999 | I saw that there's going to be some deprecations in 1.4 with removal probable in 1.5. | 23:42 |
| abadger1999 | Just checking if I missed anything else. | 23:42 |
| beuno | abadger1999, I don't know of the top of my head, but a quick glance at NEWS should tell you | 23:42 |
| abadger1999 | Ah, good point | 23:43 |
| beuno | :) | 23:43 |
| LaserJock | is there a particular reason why a bzr pull would be giving bzr: ERROR: Not a branch: for a LP branch? | 23:45 |
| beuno | LaserJock, are you in the branch's dir? | 23:45 |
| LaserJock | yeah ... thought so | 23:46 |
| fullermd | What version? | 23:46 |
| LaserJock | 1.3.1rc1 | 23:46 |
| fullermd | Probably not the smart probing thing then. | 23:48 |
| LaserJock | hmm, I did do a bzr reconfigure --branch | 23:49 |
| LaserJock | does that matter? | 23:49 |
| abadger1999 | Darn it, there is but it's not a major break. | 23:49 |
| fullermd | Not directly, I wouldn't think. But it may leave you with a parent location that's not what you want. | 23:49 |
| * abadger1999 figures out how to let the bug reporter persuade him to update over his better judgement. | 23:50 | |
| LaserJock | if the little progress wheel on the left stops turning does that mean it's stalled? | 23:56 |
| * abadger1999 reads scrollback and sees that abentley and jam were talking about exactly his problem earlier. | 23:59 | |
| jam | abadger1999: I would never discuss your problems in public :) | 23:59 |
Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!