| *** gtristan has quit IRC | 04:23 | |
| *** gtristan has joined #baserock | 04:37 | |
| *** gtristan has quit IRC | 05:09 | |
| *** gtristan has joined #baserock | 05:26 | |
| *** ctbruce has joined #baserock | 06:50 | |
| *** rdale has quit IRC | 07:23 | |
| *** juergbi has quit IRC | 07:34 | |
| *** juergbi has joined #baserock | 07:40 | |
| *** locallycompact has joined #baserock | 07:59 | |
| *** rdale has joined #baserock | 08:38 | |
| *** ctbruce has quit IRC | 08:46 | |
| *** ctbruce has joined #baserock | 08:46 | |
| *** gtristan has quit IRC | 09:02 | |
| tiagogomes | paulsherwood do you remember which system fails if the integration commands are run after the splitting? | 09:12 |
|---|---|---|
| locallycompact | what is subsystems? | 09:14 |
| pedroalvarez | locallycompact: I think this explains some things about subsystems: https://docs.baserock.org/deployment/ | 09:15 |
| pedroalvarez | also mentioned here: https://docs.baserock.org/spec/#deployment-definitions-clusters | 09:16 |
| locallycompact | mmm | 09:17 |
| tiagogomes | I didn't know about docs.baserock.org. Looks nice | 09:17 |
| locallycompact | I might submit this with clusters broken as a first pass | 09:18 |
| *** tiagogomes has quit IRC | 09:30 | |
| *** tiagogomes has joined #baserock | 09:32 | |
| * paulsherwood notices tiagogomes has asked, and then disappeared | 09:32 | |
| tiagogomes | paulsherwood I did, but not because I was afraid of the answer :) | 09:34 |
| paulsherwood | the idea was to be able to apply default splits to any system. so we should be able to create devel-runtime devel-minimal | 09:34 |
| paulsherwood | i can't remember, but i'm pretty sure those systems don't have everything required for si-commands | 09:35 |
| paulsherwood | s/remember/remember the dtails/ | 09:35 |
| persia | Then they should have different si-commands. | 09:36 |
| paulsherwood | right. but i've been aiming at tooling to work with definitions as they are | 09:37 |
| persia | The problem is that if the system-integration commands run before split, there's no way for the commands themselves to know what will be in the final system, meaning it is unsafe to populate caches, set configuration to use preferred implementations for pluggable ABIs, etc. If these cannot be done at si-time, when are they to be done? | 09:37 |
| *** gtristan has joined #baserock | 09:37 | |
| paulsherwood | persia: caches only contain chunk artifacts | 09:38 |
| persia | I agree that running system-integration after splitting is a handy shortcut to avoid adjusting definitions, it just happens to create wrong results. | 09:38 |
| persia | paulsherwood: In-system caches, most importantly the ld.so cache. | 09:38 |
| persia | (but also things like the ca-certificates cache, correctly composing the initrd contents, etc.) | 09:42 |
| tiagogomes | paulsherwood I am not sure if I follow you. Are you referring to creating two system artifacts (devel-runtime and devel-minimal) every time a system is built? | 09:51 |
| paulsherwood | tiagogomes: no. i'm suggesting that if someone specifies default-splits: minimal, they'd get minimal systems | 10:18 |
| * SotK wonders where that gets specified | 10:21 | |
| tiagogomes | I guess is some ybd flag | 10:21 |
| paulsherwood | https://gitlab.com/baserock/ybd/blob/master/ybd/config/ybd.conf#L84 | 10:22 |
| * paulsherwood believes this works better than what was there before, but it still needs improvements | 10:23 | |
| SotK | I feel like it should at least be set in definitions rather than ybd, else I have to tell someone which default-splits value to use when they try to reproduce a thing, rather than everything they need to know being defined in the system definition | 10:23 |
| * paulsherwood knows that radiofree concluded that our splits are not splitting enough | 10:23 | |
| tiagogomes | I am not convinced by that flag . What dictates what goes into a system artifact should be mandated by definitions and definitions only no? | 10:24 |
| SotK | tiagogomes: +1 | 10:24 |
| paulsherwood | the splits themselves are in the defaults in definitions | 10:27 |
| paulsherwood | s/splits/splitting rules/ | 10:27 |
| paulsherwood | the cache-key notes which actual splits are applied | 10:28 |
| gtristan | the system integration commands is an interesting problem | 10:28 |
| * gtristan missed part of the conversation yesterday, but admits there are things to work out there | 10:28 | |
| paulsherwood | i'm happy for folks to improve the approach of course | 10:28 |
| gtristan | for instance; if one wanted to deploy to rpm; one would probably want the rpms to pickup the artifacts before system integration and implement the si commands as %post scripts | 10:29 |
| tiagogomes | Even in that case, the system integration commands would run after the splitting | 10:32 |
| gtristan | tiagogomes, right, they would | 10:35 |
| persia | gtristan: Precisely. The s-i commands are intended to represent the results of maintainer scripts (both pre- and post-) to make system-specific adjustments to the content. We do them at build time in an attempt to ensure we can repeat systems, rather than relying on the right balance of cosmic rays in the target system at package installation time. | 10:37 |
| gtristan | the problem we had with s-i commands was worse than just adjusting definitions (I think, unless the systems we were defining actually did not make sense), we ended up with building a minimal system and then running s-i commands in a sandbox with no shell | 10:38 |
| gtristan | I believe that's when it changed | 10:38 |
| persia | The minimal system had no shell? | 10:39 |
| persia | If so, the minimal system integration commands should not require a shell :) | 10:40 |
| gtristan | which is quite impossible heh | 10:40 |
| persia | (but I'd assert that the minimal system should have a shell) | 10:40 |
| persia | gtristan: Not really: just have them written in a compiled language, and fork into them. | 10:40 |
| gtristan | Ok, well then we need our sandboxing code to improve to handle that, I think s-i commands, and all others, are given to the shell | 10:41 |
| pedroalvarez | i was going to say that | 10:41 |
| pedroalvarez | I believe they do need shell, allways | 10:41 |
| persia | Historically, Debian's debian/rules file is defined as causing certain behaviours in response to certain arguments. While >99.99% of them are makefiles, the definition was chosen to allow one to use other sorts of files in the case where one needed to build something without having `make` available. | 10:42 |
| gtristan | Yes, and arguably they should continue to do so, because we would want to use shell variable expansion more, not less | 10:42 |
| tiagogomes | What's a minimal system here. For me a minimal system what e.g. systems/minimal-system-x86_64-generic.morph is about. Is a minimal system, in ybd context, a system that only includes the $strata-minimal artifacts? | 10:42 |
| gtristan | However, that does not rule out asserting that the sandbox is responsible for having an executable shell, regardless of what content is actually staged | 10:42 |
| gtristan | tiagogomes, we're talking about using the split-artifact rules indeed | 10:43 |
| tiagogomes | In that case, if ybd default-splits went away, probably there would be no problem of running the system integration commands after with current definitions. | 10:45 |
| paulsherwood | not just that. it should be possible to build *-system as a runtime or minimal version | 10:45 |
| paulsherwood | if we drop the default-splits idea, we're requiring that users explicitly define their splits for all systems | 10:46 |
| * paulsherwood would appreciate radiofree comments on this, but believes he's travelling | 10:46 | |
| gtristan | I think this needs some semantics, and running system integration commands is an optional transformation one might perform on a system artifact; turning it into something else. On the one hand, one wants to be able to split the system artifact and encode system-integration commands into packages, if that is what their deployment requires; on the other hand; one wants to be able to run the system integration commands on a system before pruning out | 10:49 |
| gtristan | unneeded cruft, like when building a runtime | 10:49 |
| gtristan | Say where the runtime is defined as something like a flatpak runtime (a chrootable or such area where one can run a program with a predetermined set of libraries present, but no tools/shells/dev files or such) | 10:50 |
| persia | My concern with asserting that the sandbox has a shell is that the results of system integration may create artifacts that would expect a shell on the target system. | 10:50 |
| gtristan | persia, whether it is a shell, or a shared library (say pango-querymodules or fontconfig programs), there is a dependency there | 10:52 |
| *** anahuelamo has quit IRC | 10:52 | |
| gtristan | so either there is syntax to account for that dependency, or the burden is on the definitions author to know that ? | 10:53 |
| gtristan | of course, if the sandbox makes a guarantee of the shell being present; s-i commands would only work within the sandbox on on targets that have a shell (so of course your point still stands) | 10:56 |
| gtristan | s/on on/or on | 10:56 |
| *** vgrade12 has quit IRC | 10:56 | |
| gtristan | persia, I'm curious what project atomic is doing with such commands | 10:59 |
| gtristan | probably similar, installing everything with %post scripts run from package builds before making an ostree commit | 11:00 |
| gtristan | but really not sure | 11:00 |
| rdale | it just seems to be like a build dependency to me - you may need bash to run the system integration commands on a minimal system, and not need bash in the final system. so you should just create a 'system integration artifact' against the system made of split artifacts, and just add the system integration one when built | 11:00 |
| *** vgrade12 has joined #baserock | 11:01 | |
| persia | gtristan: I believe they are running %post before commit, yes, but I don't know for sure. | 11:08 |
| persia | rdale: There may be a need for code run before splitting, but it's not the right time to run things that are usually in the post-install scripts. | 11:08 |
| gtristan | looks like it happens in this monstrosity: https://github.com/projectatomic/rpm-ostree/blob/master/src/libpriv/rpmostree-core.c#L1847 | 11:11 |
| * gtristan squirms looking at rpmTs again | 11:11 | |
| gtristan | rdale, indeed with rpm we even have explicit Requires(post)/Requires(postun) in order to specify what is required to run a given script | 11:14 |
| gtristan | rdale, but I think that comes down to what you're going to do with the output - anyway if you assume the output is always going to be a system image, then a single strategy will do | 11:15 |
| jjardon | Hi! Any idea why ybd is failing in this runner? Its using the same docker image as the public runners... https://gitlab.com/baserock/definitions/builds/5384231 | 11:16 |
| gtristan | rdale, which brings me back to the above, I have a feeling ultimately the definitions user may or may not want to perform a system integration transformation before doing other things, like splitting up and deploying chunks in whatever fashion | 11:16 |
| jjardon | locallycompact: be aware of that ^ | 11:17 |
| locallycompact | the public runners use ruby2:1 no? | 11:19 |
| locallycompact | ruby:2.1 | 11:19 |
| leeming | still pending https://github.com/CodethinkLabs/sandboxlib/pull/25 any mayor concerns? | 11:20 |
| jjardon | locallycompact: you can change that in your .gitlab-ci,yml | 11:20 |
| locallycompact | You said | 11:21 |
| locallycompact | Its using the same docker image as the public runners.. | 11:21 |
| jjardon | locallycompact: when I use the public runners (with the python:2.7 image), It's not a problem | 11:23 |
| locallycompact | oh right | 11:23 |
| jjardon | locallycompact: we have our own elastic runners now (still experimenting with it) | 11:24 |
| locallycompact | building some assemblargs https://gitlab.com/baserock/ybd/commits/staging/010 | 11:31 |
| jjardon | locallycompact: I will come back to public runners until we know why this is happening | 11:32 |
| jjardon | btw, didnt test it yet but I think it would be possible to replace KBAS with the distributed cache gitlab provides, I will get some numbers at some point to see what is faster | 11:34 |
| paulsherwood | tiagogomes: are you ok with leeming's sandboxlib changes now? | 11:37 |
| locallycompact | jjardon, nice | 11:38 |
| tiagogomes | paulsherwood, I'll have a look. leeming have you successfully built a system by with brwap by now? | 11:39 |
| leeming | it built before with root yes, not without root, but that is a ybd issue not sandboxlib | 11:40 |
| tiagogomes | If you comment out the code on ybd to create the device nodes, wouldn't it build as non-root? | 11:41 |
| locallycompact | what do we want to do about moving splitting | 11:41 |
| paulsherwood | jjardon: not running as root? | 11:45 |
| locallycompact | ybd not lets you | 11:46 |
| paulsherwood | ? | 11:46 |
| paulsherwood | jjardon: `$ ybd/ybd.py systems/build-system-x86_64-chroot.morph x86_64 | 11:47 |
| paulsherwood | suggests it's not running as root | 11:47 |
| locallycompact | ybd stops before anything if you're not root | 11:47 |
| leeming | tiagogomes, no, but gtristan started to look into it. but that is a ybd issue | 11:47 |
| locallycompact | 16-10-21 00:00:00 [SETUP] ERROR: ../ybd/ybd.py needs root permissions | 11:48 |
| leeming | yes, standard ybd catches that | 11:48 |
| locallycompact | those python docker images are only root | 11:48 |
| locallycompact | they don't have sudo | 11:48 |
| gtristan | leeming, tiagogomes, besides device nodes, there are other reasons ybd needs to be root, some chunks for instance need to install things as specific users; possibly things need to be installed as setuid root binaries as well | 11:49 |
| tiagogomes | paulsherwood, What's the user case for -mininal, -runtime and -devel artifacts of the same system? Let's consider embedded. You want to have a system definition for the production system with the target bsp, the vendor software, no debug symbols and no headers. In addition, you want a system definition for debugging the system, with the vendor software built without optimizations, with debug symbols, headers and a couple of de | 11:49 |
| tiagogomes | bbuging tools (e.g gdb-server, strace…). That looks to me two different system morphologies. | 11:49 |
| gtristan | the bubblewrap approach solves regular file ownership but not device nodes | 11:49 |
| paulsherwood | the actual error in jjardon's run is RuntimeError: ['mount', '-t', 'tmpfs', '-o', '', 'tmpfs', '/root/ybd/tmp/tmptDaWrZ/dev/shm'] failed: mount: permission denied | 11:50 |
| gtristan | yocto does not do device nodes afaik (rburton says that those are entirely left to udev / systemd or such at boot time) | 11:50 |
| * leeming just wants the PR to be reviewed so he can move on :) | 11:50 | |
| * paulsherwood is tempted to merge it | 11:50 | |
| locallycompact | certainly looks like it's root then | 11:50 |
| locallycompact | if it was able to mkdir /root/ybd/tmp | 11:50 |
| leeming | I am writing a bit of a writeup atm, so remaining features can be patched | 11:51 |
| paulsherwood | tiagogomes: having two different systems means keeping them in sync. the use-case is developer wants all the debug etc, but also wants to deploy a minimal/production version for testing | 11:53 |
| paulsherwood | but maybe you're right | 11:59 |
| gtristan | I dont think so tbh, the problem of debugging info is typically solved nowadays by stripping debugging info into separate files (and we are doing this already) | 12:03 |
| gtristan | And the argument for compiling with/without optimization shouldnt really necessitate a whole different set of definitions (or "morphology"), rather, would should be able to adjust the "optflags" or such variable in DEFAULTS (or override a variable in DEFAULTS from the ybd command line) | 12:04 |
| tiagogomes | True about debug symbols, but besides them, you would want some debug tools installed, including possibly vendor-specific debugging tools. | 12:05 |
| SotK | what does keeping two systems in sync entail beyond adding strata to both instead of just one of them, which doesn't seem hugely onerous to me? | 12:05 |
| locallycompact | This behaviour is what coeffects are for | 12:06 |
| SotK | it'd be even easier with v10, as you could make the larger system contain the smaller system and eliminate that issue | 12:06 |
| locallycompact | we could be able to set optflags arbitrarily if build instructions expect it and they get it delivered by runtime or minimal | 12:06 |
| gtristan | tiagogomes, yes indeed; still, you cannot begin to choose what vector of split-artifacts (including debugging symbols and debuggers as a complete set), had you not split the artifacts in the first place | 12:07 |
| gtristan | tiagogomes, however I may have misread your question: argument of -minimal -devel etc of a given *system* is questionable | 12:08 |
| gtristan | tiagogomes, i.e. there are various ways that deployment of built software is usable; those useful outputs are not always bootable things, and probably dont fall directly into 3 simple categories "minimal/runtime/devel" | 12:09 |
| tiagogomes | leeming, the sandboxlib tests are failing http://paste.baserock.org/nasoyatalo | 12:15 |
| *** anahuelamo has joined #baserock | 12:15 | |
| *** anahuelamo_ has joined #baserock | 12:17 | |
| *** anahuelamo has quit IRC | 12:17 | |
| leeming | arg thought you raised this the other day and i fixed it :( | 12:17 |
| locallycompact | what is this aboiut s-i commands # 3. asciibetically sort them | 12:30 |
| locallycompact | seems mighty precarious? | 12:30 |
| *** gtristan has quit IRC | 12:31 | |
| *** paulwaters_ has joined #baserock | 12:51 | |
| *** inara has quit IRC | 13:00 | |
| persia | locallycompact: Ordering of s-i commands needs to be deterministic. How this is determined is an arbitrary choice. asciibetically is as good as anything else. | 13:14 |
| persia | But it is not safe to have the ordering of s-i commands differ depending on system construction, if one is intending to expect that a given chunk integration is going to be similar between systems. | 13:14 |
| persia | (for example, to have s-i commands ordered based on the ordering of artifact application used to compose the system) | 13:15 |
| locallycompact | I don't like it but too much to solve now | 13:19 |
| *** inara has joined #baserock | 13:27 | |
| *** paulwaters_ has quit IRC | 13:33 | |
| * tiagogomes is sad that paulsherwood merged a pull request that doesn't even pass the tests. | 14:03 | |
| pedroalvarez | tiagogomes: which one? | 14:05 |
| SotK | does gitlab not do gating of merges? | 14:07 |
| tiagogomes | pedroalvarez, https://github.com/CodethinkLabs/sandboxlib/pull/25 | 14:07 |
| SotK | oh, its still github | 14:08 |
| tiagogomes | That PR was not even properly reviewed. I didn't review it, I doubt anyone else did it. | 14:08 |
| pedroalvarez | ¯\_(ツ)_/¯ | 14:09 |
| leeming | tiagogomes, I was just investigating your latest issue... oyu sure you pulled the latest version btw? I tried it on a remote machine | 14:09 |
| leeming | actually scrap that | 14:13 |
| *** CTtpollard has joined #baserock | 14:19 | |
| leeming | tiagogomes, I've patched that now.... | 14:21 |
| leeming | new PR or can reopen? | 14:21 |
| * tiagogomes doesn't care anymore | 14:22 | |
| leeming | hmm well this is the patched PR https://github.com/CodethinkLabs/sandboxlib/pull/27 | 14:30 |
| leeming | I included a recorded reminder of the bubblewrap bug i mentioned the other day here | 14:31 |
| *** CTtpollard has quit IRC | 14:35 | |
| paulsherwood | tiagogomes: i was under the impression that leeming had addressed your comments | 14:51 |
| leeming | i was in the middle of addressing one of them (the patch PR) | 14:51 |
| paulsherwood | i'm happy to revert it if that's the best thing | 14:54 |
| paulsherwood | tiagogomes: your call | 14:55 |
| * paulsherwood guesses that tiagogomes must have meant it when he said he didn't care any more | 15:08 | |
| paulsherwood | leeming: you got me into this mess.. can you help me get out of it, please? :) | 15:08 |
| paulsherwood | does your latest pr fix the tests, and leave users in a working state? or do we revert? | 15:09 |
| leeming | it does fix the 'mess' yes | 15:10 |
| tiagogomes | paulsherwood well it is not breaking anything I suppose... unless someone does a new release of sandboxlib to pip | 15:10 |
| leeming | ^ i was going to | 15:10 |
| leeming | not with broken version btw | 15:10 |
| paulsherwood | tiagogomes: afaik the only user of sandboxlib is ybd, and i was under the impression that leeming's stuff would only have any impact if bubblewrap is present | 15:11 |
| paulsherwood | these ar just excuses, though :) | 15:11 |
| leeming | do we know that 'we' are the only users? | 15:11 |
| paulsherwood | as i said above, ybd uses it. no other projects afaik | 15:12 |
| persia | Lots of folk don't disclose when they use things, although a lack of bug reports from non-ybd uses is a very strong indicator | 15:13 |
| leeming | anyway, #27 fixes the issue that was raised. The only thing to note is a (non blocking) bug with bubblewrap leaking PWD into the sandbox/reporting back afterwards | 15:14 |
| leeming | currently, I think it would be a blocker/ refuse to work, due to a missing config file | 15:15 |
| leeming | which I mistakenly missed out | 15:15 |
| pedroalvarez | tests to travis! | 15:15 |
| paulsherwood | +1 | 15:15 |
| leeming | yes, I should have pushed to gitlab's ci.. but i wasn;t sure what we were doing with the github vs gitlab thing. I had asked a few times | 15:15 |
| leeming | if there was an 'official' word on it | 15:15 |
| paulsherwood | there's multiple steps in that. let's do one at a time | 15:16 |
| paulsherwood | so either establish ci at travis (which is for github), or in the fork at gitlab. | 15:17 |
| pedroalvarez | if pull requests are happening in github, please use travis | 15:18 |
| paulsherwood | ack. i expect after this there won't be any pullrequests until the ci is in place :) | 15:19 |
| pedroalvarez | I would expect a PR to configure the CI :) | 15:19 |
| * leeming knows nothing of travis | 15:20 | |
| pedroalvarez | but yes, that PR will be already tested | 15:20 |
| paulsherwood | gah ;) | 15:20 |
| paulsherwood | leeming: it's trivial, similar to gitlab ci | 15:20 |
| leeming | yeah, i woulda thought so too.. was just thinknig of work commitments *looks at remaining time for today* :) | 15:21 |
| *** anahuelamo_ has quit IRC | 15:24 | |
| *** anahuelamo has joined #baserock | 15:25 | |
| paulsherwood | leeming: is the process for releasing to pypi properly documented? | 15:28 |
| tiagogomes | There are a few issues in the bubblewrap in sandboxlib. e.g the filesystem is not read only | 15:29 |
| leeming | there is a "hacking" file that explains it | 15:29 |
| leeming | it should be RO | 15:30 |
| leeming | but i was told originally it didn't matter anyway, but i did it cos that is the way it should be :P | 15:30 |
| leeming | https://github.com/CodethinkLabs/sandboxlib/blob/master/sandboxlib/bubblewrap.py#L278 | 15:31 |
| tiagogomes | that is not working | 15:32 |
| leeming | how so? | 15:33 |
| leeming | paulsherwood, I know a few people know have done it too, but i was waiting for a thumbs up before going ahead | 15:33 |
| *** edcragg has quit IRC | 16:38 | |
| *** anahuelamo_ has joined #baserock | 16:57 | |
| *** anahuelamo has quit IRC | 16:57 | |
| *** edcragg has joined #baserock | 17:04 | |
| *** franred has quit IRC | 17:10 | |
| *** tiagogomes has quit IRC | 17:11 | |
| *** locallycompact has quit IRC | 18:06 | |
| *** rdale has quit IRC | 18:22 | |
| *** ctbruce has quit IRC | 19:43 | |
| *** lachlanmackenzie has joined #baserock | 20:00 | |
| *** lachlanmackenzie is now known as lchlan | 20:11 | |
| *** lchlan has quit IRC | 22:23 | |
| *** vgrade12 has quit IRC | 23:01 | |
| *** ChanServ has quit IRC | 23:01 | |
| *** edcragg has quit IRC | 23:01 | |
| *** mwilliams_ct has quit IRC | 23:01 | |
| *** ChrisPolin has quit IRC | 23:01 | |
| *** jmacs has quit IRC | 23:01 | |
| *** cosm has quit IRC | 23:01 | |
| *** jjardon_matrix has quit IRC | 23:01 | |
| *** tardyp has quit IRC | 23:01 | |
| *** gary_perkins has quit IRC | 23:02 | |
| *** bjdooks has quit IRC | 23:02 | |
| *** persia_ has quit IRC | 23:02 | |
| *** fay_ has quit IRC | 23:02 | |
| *** inara has quit IRC | 23:02 | |
| *** juergbi has quit IRC | 23:02 | |
| *** persia has quit IRC | 23:02 | |
| *** jude_ has quit IRC | 23:02 | |
| *** leeming has quit IRC | 23:02 | |
| *** dabukalam has quit IRC | 23:02 | |
| *** benbrown_ has quit IRC | 23:02 | |
| *** vgrade has quit IRC | 23:02 | |
| *** malinus has quit IRC | 23:02 | |
| *** perryl has quit IRC | 23:02 | |
| *** bfletcher has quit IRC | 23:02 | |
| *** anahuelamo_ has quit IRC | 23:02 | |
| *** cyndis has quit IRC | 23:03 | |
| *** _longines has quit IRC | 23:03 | |
| *** JPohlman1 has quit IRC | 23:03 | |
| *** inara has joined #baserock | 23:08 | |
| *** jude_ has joined #baserock | 23:08 | |
| *** persia has joined #baserock | 23:08 | |
| *** juergbi has joined #baserock | 23:08 | |
| *** mwilliams_ct has joined #baserock | 23:08 | |
| *** edcragg has joined #baserock | 23:08 | |
| *** jmacs has joined #baserock | 23:08 | |
| *** ChrisPolin has joined #baserock | 23:08 | |
| *** vgrade12 has joined #baserock | 23:08 | |
| *** fay_ has joined #baserock | 23:08 | |
| *** cyndis has joined #baserock | 23:08 | |
| *** _longines has joined #baserock | 23:08 | |
| *** JPohlman1 has joined #baserock | 23:08 | |
| *** perryl has joined #baserock | 23:08 | |
| *** bfletcher has joined #baserock | 23:08 | |
| *** dabukalam has joined #baserock | 23:08 | |
| *** benbrown_ has joined #baserock | 23:08 | |
| *** vgrade has joined #baserock | 23:08 | |
| *** malinus has joined #baserock | 23:08 | |
| *** leeming has joined #baserock | 23:08 | |
| *** anahuelamo_ has joined #baserock | 23:08 | |
| *** cosm has joined #baserock | 23:08 | |
| *** jjardon_matrix has joined #baserock | 23:08 | |
| *** tardyp has joined #baserock | 23:08 | |
| *** gary_perkins has joined #baserock | 23:08 | |
| *** bjdooks has joined #baserock | 23:08 | |
| *** persia_ has joined #baserock | 23:08 | |
| *** ChanServ has joined #baserock | 23:11 | |
| *** niven.freenode.net sets mode: +o ChanServ | 23:11 | |
Generated by irclog2html.py 2.15.3 by Marius Gedminas - find it at mg.pov.lt!