| *** zoli__ has joined #baserock | 06:09 | |
| *** Albert has joined #baserock | 07:10 | |
| *** a1exhughe5 has joined #baserock | 07:28 | |
| straycat | https://gerrit.baserock.org/#/c/230/ | 08:03 |
|---|---|---|
| straycat | franred, i think you misunderstand the suggestion | 08:04 |
| straycat | in any case i'm kinda getting tired of arguing over every little detail in baserock | 08:04 |
| *** rdale has joined #baserock | 08:05 | |
| pedroalvarez | straycat: the thing is that only moving configobj is not enough | 08:10 |
| pedroalvarez | cloud-init is already missing things that are in python-common | 08:11 |
| pedroalvarez | I don't know what is failing in this conversation, really | 08:11 |
| pedroalvarez | straycat: maybe you are missing the fact that cloudinit in the base systems is already broken, since we moved things from cloudinit-support to python-common | 08:12 |
| pedroalvarez | at that point we should have included python common to base systems, but we forgot | 08:12 |
| perryl | can anyone tell me how to set PYTHONPATH to run a specific version of morph? | 08:16 |
| franred | perryl, http://wiki.baserock.org/using-latest-morph/ <-- and then you set the morph repo to the branch that you want to test? | 08:17 |
| straycat | pedroalvarez, yeah that wasn't clear, regardleess there's no compelling reason to add all this bloat to the base system. why do i need to be able to deploy a base system to openstack? | 08:23 |
| *** jonathanmaw has quit IRC | 08:29 | |
| straycat | so my vote is removing cloud-init from the base system to keep things minimal, maybe it's worth appealing to others for their thoughts | 08:31 |
| pedroalvarez | I don't have a strong opinion about that. I'm only worried about base systems being broken | 08:31 |
| richard_maw | since base is ill-defined and cloud init is broken in its current state, so nobody can be using it, I'd +1 a patch to remove it | 08:34 |
| * richard_maw looks at the gerrit link | 08:34 | |
| *** edcragg has joined #baserock | 08:34 | |
| franred | Same here, I am not opposed to remove cloud-init support from the base-systems either | 08:35 |
| *** ssam2 has joined #baserock | 08:37 | |
| *** ChanServ sets mode: +v ssam2 | 08:37 | |
| *** jonathanmaw has joined #baserock | 08:38 | |
| *** gary_perkins has joined #baserock | 08:38 | |
| franred | ssam2, good morning, we are discussing about remove cloud-init support from base-systems there are 2 +1 to remove, 2 +0, do you have anything against this? | 08:38 |
| jjardon | +1 from me to remove it as well | 08:40 |
| ssam2 | I think it's a bad idea, but I'm not going to block it | 08:40 |
| ssam2 | i based the Gerrit system off the base system, for example, and was handy to not then have to add cloud-init support | 08:41 |
| ssam2 | but it's not the end of the world | 08:41 |
| franred | straycat, pedroalvarez, richard_maw, jjardon, ssam2, ok, I will abandon https://gerrit.baserock.org/#/c/230/ and create a patch to remove the cloud-init support from base-systems | 08:46 |
| pedroalvarez | franred: also the configure exts | 08:47 |
| franred | pedroalvarez, sorry I don't undertand, you want me to configure exts or remove it? | 08:49 |
| pedroalvarez | let me think, one second | 08:50 |
| richard_maw | franred: remove the cloud-init configuration extensions listed in the system I guess | 08:50 |
| pedroalvarez | yes, although if we keep it there, and someone tries to configure a system with cloud-init, the deployment will fail | 08:51 |
| franred | pedroalvarez, I'd suggest to remove it too | 08:53 |
| pedroalvarez | franred: meh, just remove the "cloud-init" configuraton extensions from the systems as well | 08:53 |
| franred | pedroalvarez, snap | 08:54 |
| * richard_maw has just noticed that one of his irssi scripts is not currently functioning | 08:54 | |
| richard_maw | quick, someone say cloud | 08:55 |
| straycat | cloud | 08:56 |
| pedroalvarez | could | 08:56 |
| straycat | :s | 08:57 |
| straycat | franred, cool | 08:57 |
| franred | straycat, ssam2, richard_maw, pedroalvarez, jjardon, https://gerrit.baserock.org/#/c/241/ | 09:07 |
| straycat | ahh i hadn't noticed gerrit lets you edit the commit message from the web ui, that's nice | 09:10 |
| richard_maw | it doesn't re-flow it for you though, which annoys me | 09:11 |
| * richard_maw accidentally wrote a very long line in it, since the web ui line wrapped it without breaking the line in the output | 09:11 | |
| Albert | ybd/morph-related: I've been looking at a bug on YBD where strata that have the same name as chunks cause errors in recursion. I was wondering how morph handles this? | 09:12 |
| straycat | richard_maw, your +1 doesn't seem to apply to the version with the updated commit msg | 09:12 |
| richard_maw | Albert: badly in general, but specifically it knows that strata can only depend on other strata, and chunks can only depend on other chunks, so it disambiguates based on that, which means we don't get a loop there | 09:13 |
| richard_maw | Albert: we've previously had loops from accidentally being able to depend on a chunk from another strata, and it being unpredictable which version was actually referred to, but we don't accidentally depend on the wrong kind of definition | 09:14 |
| * jjardon thinks morph should enforce unique names to avoid problems | 09:15 | |
| * SotK too | 09:16 | |
| richard_maw | maybe, but I can't make my mind up about whether we should re-work the definitions so that you do this by file names *having* to be unique, or post-hoc validatoin to make sure you haven't defined something twice | 09:16 |
| *** wschaller has joined #baserock | 09:17 | |
| Albert | In this case we have the 'ruby' strata depending on the 'ruby' chunk. There are others besides. I assume morph handles this. | 09:17 |
| SotK | I wonder if it would be better to think of that as "Definitions version X requires names to be unique." | 09:17 |
| *** Krin has joined #baserock | 09:17 | |
| SotK | and then tools which support that (ie. both morph and ybd) should enforce uniqueness | 09:18 |
| Albert | I was thinking some sort of mangling in ybd for the time being | 09:19 |
| Albert | but that would be a pain | 09:19 |
| SotK | Albert: you could send a patch to definitions to rename the ruby stratum to ruby-common or similar | 09:20 |
| SotK | I doubt there would be objections | 09:20 |
| richard_maw | SotK: I believe paulsherwood is working on one | 09:20 |
| * richard_maw saw him push a branch | 09:20 | |
| Albert | I gather from paulsherwood that conversations ensue | 09:20 |
| Albert | But paul would prefer YBD to handle what morph can handle, so I was wanting to find out how you guys have done it. | 09:27 |
| richard_maw | effectively it's just a different namespace | 09:28 |
| richard_maw | morph is currently buggy in that there's a strata namespace and a chunks namespace, when what would make sense is a per-stratum chunks namespace | 09:28 |
| Albert | What if the effect of these bugs, and how tractable or otherwise are they? In other words is it an approach worth taking/avoiding in YBD? | 09:39 |
| Albert | is * | 09:39 |
| richard_maw | Albert: the effect of that bug is that if two strata hava a chunk called foo, then we end up with one with the union of the dependencies, and the build commands and build commit selected arbitrarily as the first encountered in the traversal | 09:41 |
| richard_maw | in the wrong circumstances this can result in a loop | 09:42 |
| Albert | So unique names would benefit all? | 09:43 |
| *** sambishop has quit IRC | 09:43 | |
| richard_maw | unique names, or per-stratum scoped names | 09:43 |
| straycat | per-stratum scoped makes more sense imo | 09:45 |
| *** sambishop has joined #baserock | 09:45 | |
| Albert | OK thanks for your input guys. Much appreciated. | 09:45 |
| * SotK thinks so too | 09:45 | |
| * paulsherwood would prefer unique names, as he has said many times | 09:45 | |
| paulsherwood | however, for ybd i want to be able to build all previous versions of definitions.git, and morphs.git if possible, so i need to find a way to deal with the recursion | 09:46 |
| richard_maw | paulsherwood: for _all_ versions of morphs.git, you'd need to use the timestamp of the commit to reason about the definitions format | 09:47 |
| Albert | So a similar namespaces approach? | 09:47 |
| paulsherwood | richard_maw: you may be right. i have a theory, though :) | 09:47 |
| * paulsherwood has been wrong before, of course | 09:48 | |
| richard_maw | paulsherwood: I recall some changes that were staged to change the behaviour of an existing field, I'm not sure you'd have sufficient context without checking the time | 09:48 |
| paulsherwood | richard_maw: ok, thanks for the warning :-) | 09:48 |
| paulsherwood | richard_maw: note i'm trying to ignore as many fields as possible :-) | 09:49 |
| *** jonathanmaw has quit IRC | 09:49 | |
| richard_maw | paulsherwood: I'm not sure how well that will serve you, as we only introduced fields when we thought we needed them | 09:50 |
| paulsherwood | richard_maw: fair enough. but i can ignore 'kind' for example. and 'products', currently | 09:52 |
| paulsherwood | richard_maw: i thought i could ignore 'name' because others suggested that, but it seems i can't | 09:52 |
| richard_maw | kind was pretty much always possible to ignore because of context, products can be ignored if you don't need to have a small initramfs, as can the artifacts fields | 09:52 |
| paulsherwood | ack | 09:53 |
| jjardon | paulsherwood: are you still working in a patch to have unique names in our definitions? | 09:55 |
| paulsherwood | i started one. my concern based on the discussion here is that only jjardon and paulsherwood are actually in favour of it | 10:03 |
| jjardon | And SotK . and I think richard_maw would be OK with that as well | 10:05 |
| rdale | i think we should have proper nested scopes, and having only global names doesn't scale | 10:06 |
| richard_maw | I'm not yet convinced that morph needs to enforce uniqueness, or _how_ to do so, but for our definitions, I think uniqueness helps the cognitive load | 10:06 |
| richard_maw | so I'm happy to +1 a patch to rename the strata to make it so | 10:07 |
| ssam2 | I think unique names in definitions is a good idea | 10:07 |
| ssam2 | I wasn't sure about names like 'lorry-common', that's kind of why I didn't reply yet | 10:08 |
| ssam2 | cus I haven't got a better idea :) | 10:08 |
| SotK | lorry-core maybe? | 10:09 |
| SotK | they both seem a bit strange though I feel | 10:09 |
| ssam2 | lorry-stratum | 10:09 |
| paulsherwood | :/ | 10:09 |
| jmacs | Anything ending in '-core' sounds like a music genre to me | 10:09 |
| ssam2 | lorry-and-some-of-its-dependencies | 10:09 |
| paulsherwood | lorry-things, lorry-group, lorry-set, lorry-stuff | 10:13 |
| * jjardon voted lorry-group | 10:14 | |
| paulsherwood | one more +1 and i'll do the patch | 10:15 |
| paulsherwood | (ruby-group, erlang-group, ansible-group, swift-group) | 10:15 |
| richard_maw | or we could take the gnu convention and stuff -utils or -tools | 10:15 |
| * paulsherwood has learned the hard way, over many years, that names are a source of disproportionate grief | 10:16 | |
| richard_maw | though that may end up in the silly situation of having coreutils-utils | 10:16 |
| richard_maw | there are 2 challenges in computing: 1. names, 2. memory management, 3. off by one errors | 10:16 |
| paulsherwood | 4. pbkac :) | 10:16 |
| radiofree | +1 lorry-group | 10:16 |
| paulsherwood | yay!!!!! | 10:17 |
| paulsherwood | we have a winner :-) | 10:17 |
| *** jonathanmaw has joined #baserock | 10:17 | |
| richard_maw | I didn't like lorry-group, but couldn't articulate why, so if I can't justify it to myself, it's not even worth mentioning, because I can't justify this opinion to anyone else | 10:18 |
| DavePage | And now you've mentioned it by talking about how you're not going to mention it. Cicero would be proud :) | 10:18 |
| paulsherwood | rofl | 10:19 |
| * SotK marginally prefers lorry-components to lorry-group, but decided to stop bikeshedding | 10:20 | |
| ssam2 | lorry-group is OK | 10:22 |
| *** wschaller has quit IRC | 10:31 | |
| straycat | lorry-stratum | 10:32 |
| straycat | oh wait | 10:32 |
| Albert | But this renaming still leaves the fact that YBD can't deal with older versions? | 10:34 |
| Albert | Can someone provide a quick pointer to the where morph deals with namespaces so I can take a look? | 10:37 |
| straycat | rdale, fwiw i agree *shrug* | 10:46 |
| *** wschaller has joined #baserock | 10:47 | |
| richard_maw | Albert: not easily, there's no explicit namespacing, sources of all kind are put in the sourcepool in sourceresolver.py/create_source_pool(), and the artifactresolver joins up the dependencies | 10:48 |
| paulsherwood | Albert: not yet, but i still have hope :) | 10:48 |
| richard_maw | straycat, rdale: As do I, but I think morph should be able to support both | 10:48 |
| straycat | well yeah unique would be a subset of per stratum scoped... | 10:49 |
| ssam2 | Albert: Morph calculates the cache identity of a source here:http://git.baserock.org/cgi-bin/cgit.cgi/baserock/baserock/morph.git/tree/morphlib/cachekeycomputer.py#n81 | 10:49 |
| persia | On lorry-foo: I don't care enough to suggest we change it after the above discussion, but generally believe that we ought describe things in terms of themselves, rather than what they might contain. So "archive-mirroring" would be a sensible sort of function name, using this case as an example, which function can be sensibly added as a feature for a system. | 10:49 |
| ssam2 | Albert: you can see it uses a different algorithm depending on the 'kind' field | 10:49 |
| ssam2 | so a chunk named foo and a stratum named foo will have different cache identities | 10:49 |
| ssam2 | does that help? | 10:50 |
| ssam2 | persia: that's a good idea, at least for 'lorry' | 10:50 |
| persia | For lorry, I'm +1 on "lorry-group" just to make the issue go away, but I'd prefer the same logic I used above to be applied next time. | 10:51 |
| ssam2 | me too | 10:51 |
| Albert | thanks ssam richard_maw | 10:56 |
| jjardon | I think thats orthogonal to the previous conversation: you can always use archive-mirroring-group to name the stratum | 11:20 |
| persia | I don't think "group" belongs there. I think the names for larger components should be semantically mapped to functions, so that the system defintion reads like a list of functions. | 11:32 |
| persia | And while I agree it is orthogonal to the issue of name duplication, I assert it is very critical to the process of eliminating name duplication. | 11:32 |
| persia | (whether this is always a good idea is another discussion, which I'm not prepared to enter today) | 11:32 |
| *** wschaller has quit IRC | 12:02 | |
| * SotK idly wonders why we have "build-system-x86_64.morph" but "devel-system-x86_64-generic.morph" | 13:40 | |
| *** wschaller has joined #baserock | 13:42 | |
| ssam2 | it kind of makes sense ... 'generic' says 'you might want to adapt this for your own needs' | 13:43 |
| ssam2 | where build-system is more of a fixed 'you need this stuff to build Baserock, nothing more.' | 13:43 |
| ssam2 | although none of that is really true, I'd happily remove -generic from everything | 13:43 |
| jonathanmaw | I have a baserock VM on my laptop, but it is apparently too slow to build systems in a reasonable timeframe. I can get another VM on a server somewhere (I assume), but will have a problem upgrading the one on my VM (for testing) - it only gives an IP address as part of my laptop's virtual network. How do I get it accessible on a wider network? | 13:43 |
| ssam2 | why not use a chroot on your laptop? | 13:44 |
| jonathanmaw | ssam2: for building? | 13:44 |
| ssam2 | they do work for building, but if your laptop is slow that might still be too slow | 13:44 |
| persia | Those should probably be reconciled at some point, yes. | 13:45 |
| persia | Do we expect multiple x86 BSP flavours? | 13:45 |
| ssam2 | but for testing, maybe a chroot would be appropriate. Then upgrading is just a case of: deploy test chroot as .tar -> manage-baserock add foo ./path/to/.tar -> enter-baserock foo | 13:45 |
| nowster | paulsherwood: talking about line noise earlier.... # LANG= perl -ne 'if (/\[([^]]+)\] Elapsed time (\d+:\d+:\d+)/) { $x{$1}=$2 | 13:46 |
| nowster | ; } END { for (sort keys %x) { printf "%-32s %s\n", $_, $x{$_}; } }' morph.log | 13:46 |
| ssam2 | persia: i don't think a one-size-fits-all kernel config will ever be possible. | 13:46 |
| ssam2 | although we try, at the moment :) | 13:46 |
| nowster | ... try again ... | 13:46 |
| nowster | # LANG= perl -ne 'if (/\[([^]]+)\] Elapsed time (\d+:\d+:\d+)/) { $x{$1}=$2; } END { for (sort keys %x) { printf "%-32s %s\n", $_, $x{$_}; } }' morph.log | 13:46 |
| ssam2 | bless you | 13:47 |
| nowster | :) | 13:47 |
| nowster | where's the build times link on the wiki? | 13:48 |
| jonathanmaw | ssam2: can't test in a chroot, I need graphics, and my experiences with the fbdev renderer in a chroot have been unfriendly. | 13:49 |
| ssam2 | oh, if you need graphics, a chroot probably isn't appropriate | 13:51 |
| ssam2 | i can't really help with virtualmachine networking though, it makes my head spin | 13:52 |
| ssam2 | nowster: no idea, can't find it using the search box | 13:52 |
| ssam2 | nowster: 'git grep' in my local clone of the wiki turned up http://wiki.baserock.org/build-times/ | 13:53 |
| nowster | ssam2: I found it by searching for an arbitrary time | 13:53 |
| ssam2 | heh | 13:54 |
| persia | ssam2: I used to agree with you, but the Canonical kernel team convinced me otherwise during a long series of summit sessions over many years when they explained to me why there was no need for separate kernels for servers, tablets, phones, realtime systems, audio mixing decks, virtual machines, etc., and that a kernel that worked well for desktop could also meet all those needs. | 13:55 |
| ssam2 | i shall bow to their knowledge, then :) | 13:56 |
| persia | They may be mistaken, and I encourage others who know better to continue to have multiple BSPs: I've just given up the argument as I lost it too many times in a row. | 13:57 |
| *** straycat has left #baserock | 13:57 | |
| nowster | page updated | 14:01 |
| nowster | # LANG= perl -ne 'if (/\[([^]]+)\] Elapsed time (\d+:\d+:\d+)/) { $x{$2}.="$1 "; } END { for my $t (reverse sort keys %x) { for (sort split(/ /,$x{$t})) { printf "%s [%s]\n", $t, $_; } } }' morph.log | 14:02 |
| pedroalvarez | nowster: maybe worth noting that "script" in the page? | 14:05 |
| nowster | Good idea! | 14:05 |
| pedroalvarez | nowster: I'd suggest a removal of the artifacts and morph.log | 14:06 |
| nowster | pedroalvarez: beg pardon? | 14:07 |
| nowster | Oh, I see! Delete the cache and the existing morph log. | 14:09 |
| pedroalvarez | nowster: I mean, my suggestion was to add some information about how to generate those build-times, and that would be something like 1) remove the artifacts to make sure that you re-build everything. 2)remove morph.log to clean it and remove previous build times 3) build whatever you like 4) run this perl script | 14:09 |
| pedroalvarez | I can do that actually | 14:09 |
| nowster | Am editing page | 14:10 |
| pedroalvarez | ta :) | 14:10 |
| nowster | OK... who misspelled artefacts? :) | 14:11 |
| pedroalvarez | nowster: hehe,`git blame` | 14:11 |
| nowster | done | 14:17 |
| pedroalvarez | nowster: cool | 14:19 |
| * pedroalvarez adds a [toc] | 14:20 | |
| perryl | i have a couple of quick questions about my distbuild-start/cancel branches...one, both are currently working via duplicating the Initiator class and renaming it (i.e. InitiatorStart, InitiatorCancel); would this be better pushed as-is and change to using super in a follow-up patch, or modified to use super(Initiator, self) now? | 14:48 |
| ssam2 | if you can do it in one without the patch being really confusing, do it in one. But doing it separately and having a note saying 'I'll clean this up a separate change' would be fine too | 14:49 |
| ssam2 | *in a separate change | 14:49 |
| perryl | no problem, that makes sense! the patches have been tested and work fine as is, it's more of a cluttering issue. i'll see how it looks, add a comment about cleanup and then push | 14:51 |
| ssam2 | if you do it in a separate patch you can test squashing them and see how it looks | 14:56 |
| perryl | i have done, it's a +439, -10 beast | 14:56 |
| perryl | there is an issue in that it's rebased off my list-jobs patch, not sure whether to rebase that out so there's no duplication with the list-jobs patch currently in review | 14:58 |
| ssam2 | makes sense to base it off that branch, since we need all of them for the 'build without persistant connection' feature to be much use | 15:00 |
| perryl | aye, there's very little way of testing if start and cancel work without it, unless you're willing to delve into morph-controller.log each time | 15:01 |
| perryl | right, if that's sorted i'll push the branch for review now | 15:01 |
| paulsherwood | nowster: http://wiki.baserock.org/build-times/ | 15:05 |
| radiofree | the jetson times are now widely off | 15:06 |
| radiofree | wildly.. | 15:06 |
| radiofree | i suppose widely off works | 15:06 |
| nowster | paulsherwood: you'll notice I've updated it | 15:06 |
| radiofree | basically they're not a true reflection anymore (gcc doesn't take an hour to build) | 15:06 |
| radiofree | how should i update them? remove the current ones? add to the top of the list? | 15:14 |
| *** zoli__ has quit IRC | 15:16 | |
| paulsherwood | radiofree: remove the current ones | 15:16 |
| paulsherwood | maybe separate into pages for each class of hardware? | 15:17 |
| * pedroalvarez removes his identical answer | 15:17 | |
| * persia has very strong opinions about the different meanings of "artifact" and "artefact", and wonders which page is potentially using "artefact" in the desire to have consistent semantics. | 15:23 | |
| jjardon | What's the difference? A quick google search shows they mean the same | 15:26 |
| rdale | i found this comment which i like: "Seems to be an artifact of two countries separated by one language!" | 15:27 |
| nowster | If I put "artifact" into the Oxford Dictionaries site it corrects it to artefact. | 15:33 |
| nowster | OK. We have it with "i" in the USA and "e" in the UK and some other places. | 15:34 |
| rdale | i prefer avoiding british english for anything to do with computer programming | 15:35 |
| nowster | rdale: you mean "programing", surely? :) | 15:36 |
| rdale | is it? oh no | 15:36 |
| nowster | consonant doubling like that is a British trait | 15:36 |
| jmacs | If you were truly British you'd write computer programmes | 15:37 |
| nowster | indeed | 15:37 |
| persia | jjardon: The difference used to be that "artifact" was something created by artifice, and "artefact" was something that was a side-effect of creation. The US decided to spell the words the same in the early 20th century because it was too confusing to differentiate, and certain parties in the UK decided that "artefact" must be a UK spelling of US "artifact" in the late 20th century. I don't agree with any of the modern interpretations, and want the | 15:37 |
| persia | traditional ones, because the distinction is useful. | 15:37 |
| nowster | Noah versus Samuel | 15:38 |
| SotK | persia: +1 | 15:38 |
| jmacs | persia: So "JPEG artefact" would be a correct use? | 15:38 |
| persia | jmacs: Yes. | 15:38 |
| persia | A baserock artifact may likely contain a jpeg artefact. | 15:39 |
| nowster | Ars Gratia Artis! | 15:39 |
| persia | :) | 15:39 |
| * nowster roars quietly. | 15:40 | |
| jjardon | persia: interesting, thanks for the explanation | 15:41 |
| nowster | There's a similar history to the -ise/-ize split. | 15:43 |
| persia | nowster: What was the semantic difference for that one? | 15:44 |
| * persia thought it was just a difference of opinion in orthography between Oxford and Cambridge | 15:44 | |
| nowster | It's all Greek to me. :) | 15:44 |
| *** a1exhughe5 has quit IRC | 15:45 | |
| *** CTtpollard has quit IRC | 15:46 | |
| *** zoli__ has joined #baserock | 15:59 | |
| *** petefoth has joined #baserock | 16:26 | |
| *** petefoth has quit IRC | 16:29 | |
| *** zoli__ has quit IRC | 16:30 | |
| *** simonh_ has quit IRC | 16:44 | |
| *** simonh_ has joined #baserock | 16:46 | |
| *** jonathanmaw has quit IRC | 16:48 | |
| *** Krin has quit IRC | 16:48 | |
| *** wschaller has quit IRC | 16:53 | |
| *** tiagogomes_ has quit IRC | 16:57 | |
| *** ssam2 has quit IRC | 17:08 | |
| *** Albert has quit IRC | 17:12 | |
| *** simonh_ has quit IRC | 17:24 | |
| *** sambishop has quit IRC | 17:35 | |
| *** sambishop has joined #baserock | 17:47 | |
| *** edcragg has quit IRC | 17:50 | |
| *** flatmush1 has joined #baserock | 17:53 | |
| *** flatmush has quit IRC | 17:53 | |
| *** gary_perkins has quit IRC | 17:54 | |
| *** sambishop has quit IRC | 18:33 | |
| *** zoli__ has joined #baserock | 18:42 | |
| *** zoli__ has quit IRC | 18:46 | |
| *** sambishop has joined #baserock | 18:55 | |
| *** zoli__ has joined #baserock | 22:33 | |
| *** zoli__ has quit IRC | 23:08 | |
Generated by irclog2html.py 2.15.3 by Marius Gedminas - find it at mg.pov.lt!