IRC logs for #baserock for Tuesday, 2016-09-27

*** wdutch has quit IRC02:19
*** gtristan has joined #baserock04:39
*** rdale has joined #baserock05:29
*** toscalix has joined #baserock07:40
*** fay has joined #baserock07:53
*** fay is now known as faybrocklebank07:53
*** gtristan has quit IRC08:10
*** CTtpollard has quit IRC08:26
*** CTtpollard has joined #baserock08:30
*** gtristan has joined #baserock08:38
*** franred has quit IRC08:56
*** franred has joined #baserock08:56
*** benbrown2 is now known as benbrown_08:57
*** CTtpollard has quit IRC09:00
*** CTtpollard has joined #baserock09:02
gtristanSo I think I need to understand a bit more how 'extensions' work09:04
* paulsher1ood would like to answer locallycompact's question, but he's not here09:05
gtristanWhat I'd like to do, is run some code in a chroot of a built system, with a given artifact staged at a given location; say it's already built and I want it to appear again as /${chunkname}.inst09:06
* pedroalvarez reads gtristan09:07
gtristanthis is so that I could run tools (specifically rpmbuild) that are built in the system, without relying on host tools, to operate on a given chunk09:07
*** tiagogomes has joined #baserock09:07
gtristanthat extension basically just has to parse the metadata for the chunk, generate an rpm spec file according to the splitting rules and build a package09:08
* gtristan is thinking 'extensions' is the way to go, because it clearly should not be a first class citizen feature for ybd09:08
*** lc_ has joined #baserock09:09
pedroalvarezpaulsher1ood: ^09:09
pedroalvarezgtristan: so, you described something like install the same chunk in 2 different locations?09:10
*** lc_ is now known as locallycompact09:10
gtristanpedroalvarez, any idea how I would go about this ? specifically... can I have an extension that runs code in a chroot sandbox ? and how would such a thing be invoked from the cluster ?09:10
gtristanpedroalvarez, kind of sort of... I mean to stage an artifact as well as having the entire built system staged09:11
gtristanpedroalvarez, I guess it doesnt really have to be natively understood by ybd... so long as the extension itself has the ability to call back into functionality that ybd provides09:13
pedroalvarezwith a configure extension you can run any code you want. They are basically a program that take the location of the decompressed system rootfs  as an argument, and you can do whatever with it09:14
gtristanpedroalvarez, so say there is some already existing semantic to run an 'extension' from a cluster... and that extension would just need to run some code asking ybd to "please stage the entire system, and also put this artifact here, and run this code in the sandbox"09:14
pedroalvarezthat ^ sounds a bit tricky09:15
gtristanthe configure extension is a good start09:15
pedroalvarezi wonder if we have the functionality you need already implemented09:16
pedroalvarezhow many artifacts will you need? 1? 10? 100?09:16
gtristanwell, all of them; but I was thinking it should be something I should be able to do one at a time09:17
pedroalvarezI'm wondering if the implementation of subsystems deployment (deployment of a system inside of a system) combined with the partial deployments (deploy only some parts of a system)  will give you this functionality09:17
gtristansounds like a pretty intense operation, but considering that staging is usually done with hardlinks, shouldnt be too bad09:17
gtristanI guess the subsystems deployment thing is something we're looking into especially to avoid the usage of host tooling in deployment phase ?09:19
pedroalvarezcannot be as bad as building webkit twice09:19
gtristanpedroalvarez, is subsystems deployment something that already exists ?09:20
pedroalvarezyes, it does09:20
gtristannice, are we using it now to kill that syslinux/btrfs/requiring a baserock vm problem ?09:20
pedroalvarezthe classic and original example for subsystems clusters/initramfs-test.morph09:21
pedroalvareznot related to killing syslinux/btrfs/vms09:21
pedroalvarezit only gives you the ability of putting a system inside of a system at deploytime09:22
gtristanhmmm, ok so we *could* be using that to kill off the host tool dependencies09:22
pedroalvarezi see your point now09:22
pedroalvarezis that related to your goal? so that you could run things against some artifacts using tools that are in another system?09:23
gtristanpedroalvarez, yes that is09:24
pedroalvarezwell, I think you had a brilliant idea :)09:24
gtristanpedroalvarez, I want to run the rpmbuild tool that is built in that particular system, to package rpms for each artifact in that system09:24
* gtristan is not sure how that initramfs cluster is really working09:25
pedroalvarezthat problem may be a bit more complicated09:25
* gtristan is looking at extensions/initramfs.write09:25
pedroalvareznaw, don't look at that09:25
pedroalvarezthe cluster says that the subsystem "initramfs" will be deployed at location boot/initramfs.gz of the main system09:26
pedroalvarezwhich is the main point, deploying things inside other systems before deploying them09:27
gtristanI dont understand how that cluster says that :-/09:27
pedroalvarezI'll be busy the next 30 min or so, ill be back later09:28
gtristanit says basically: { deploy { initramfs { type = extensions/initramfs, location = boot/initramfs.gz } } }09:28
pedroalvarezyes09:28
pedroalvarezbut that is a subsystem09:28
pedroalvarez(see previous "subsystems" keyword)09:29
gtristanohhh09:29
gtristanoh09:29
gtristanok so the shell commands in extensions/initramfs.write are executed inside the deployed system ?09:29
pedroalvareznope09:30
gtristanpedroalvarez, ok I'll read what the subsystems keyword does in ybd and try to figure it out09:31
gtristanpedroalvarez, I think that might be most of what I need, and I may need to add some core semantics saying "Please run this code in the sandbox"09:32
gtristanthat should be very doable, seeing we already do it for system-integration commands09:33
*** ctbruce has joined #baserock09:53
*** ctbruce has quit IRC09:54
*** ctbruce has joined #baserock09:54
*** ctbruce has quit IRC09:56
*** ctbruce has joined #baserock09:59
*** jonathanmaw has joined #baserock10:01
*** jonathanmaw has quit IRC10:04
*** anahuelamo_ has quit IRC10:06
*** anahuelamo has joined #baserock10:06
*** CTtpollard has quit IRC10:12
*** toscalix has quit IRC10:12
*** CTtpollard has joined #baserock10:12
*** toscalix has joined #baserock10:13
*** anahuelamo has quit IRC10:13
*** anahuelamo has joined #baserock10:13
*** paulwaters_ has joined #baserock10:14
*** ctbruce has quit IRC10:23
*** ctbruce has joined #baserock10:23
*** franred has quit IRC10:26
*** franred has joined #baserock10:26
*** ctbruce has quit IRC10:27
*** ctbruce has joined #baserock10:27
* paulsher1ood would like to see extensions as some kind of 'deploylib', rather than in definitions10:30
paulsher1oodbut maybe i'm missing the point10:31
paulsher1oodand maybe the exensions are too coupled to definitions specifics to make that possible/sensible10:31
locallycompactSuggestion: Buildable type class that has 'build-depends' and a set of execution instructions that transform input -> output. Assemblage and Chunk are both Buildable.10:33
pedroalvarezgtristan: note that write/configure extensions are not using any sandboxing10:33
paulsher1oodlocallycompact: many output types are possible...10:34
SotKpaulsher1ood: we attempted that approach when first moving the extensions out of morph, but decided that most of them aren't useful when not in the definitions repository10:34
paulsher1oodSotK: ack10:35
locallycompactpaulsher1ood, ?10:35
locallycompactthey all output a filesystem no?10:35
paulsher1oodrpm, img, tar, etc...10:35
paulsher1oodyes, they're all of class 'thing' too10:36
locallycompactchunk goes source -> filesystem as artifact assemblage goes staged artifacts -> filesystem as artifact10:36
locallycompactthis is long before you get to a tarball10:36
locallycompactor any of that10:36
paulsher1oodlocallycompact: we're talking about extensions10:36
locallycompactright10:36
gtristanpaulsher1ood, I had the same thoughts earlier on, now I think there are 2 classes of extensions; extensions that should probably be built in to ybd as features, and extensions that are related to a specific system (i.e. this rpmbuild thing would really only be useful for a specific project / definitions tree)10:37
paulsher1oodextensions are *after* we've got to a tarball10:37
locallycompact? like what10:37
paulsher1oodrpm, img, rootfs etc...10:37
locallycompactok this is worlds away from what I'm thinking of10:37
gtristanAnother thought I had was, I wonder if some of the extensions we do have could instead be written out like we do build instructions in the yaml directly10:37
SotKgtristan: which extensions fit into the former catefory?10:37
paulsher1oodlocallycompact: i'm commenting on gtristan's discussion with pedroalvarez10:38
gtristanSotK, well, install-files for example is vastly used in all systems (although arguably should not exist at all :-/)10:38
paulsher1oodlocallycompact: i had assumed your Suggestion was a contribution to that discussion10:39
gtristanSotK, tarring up a sysroot seems like a common enough feature10:39
locallycompactI'm thinking of these things configuration-extensions:10:39
locallycompactThey're in the system definitions10:39
locallycompact- extensions/set-hostname10:39
locallycompact- extensions/add-config-files10:39
paulsher1oodlocallycompact: do you still need to understand what assembly.claim is doing?10:39
locallycompactyeah10:39
SotKgtristan: a number of the extensions used to be built in to morph, we extracted them out of morph and into definitions to avoid definitions being tied to a single build tool10:40
SotKI'd be disappointed to undo that work and retie definitions to a single build tool again (albeit a different one)10:40
paulsher1oodybd can run multi-instance, claim ensures only one thread is attempting to assemble foo at once.. it holds a foo.lock file10:40
paulsher1oodSotK: +110:40
gtristanSotK, yeah I had that discussion with Sam I recall; I'm still of the opinion that the build tool is the compiler and the definitions are the source, I dont like that those two dont have clean separation, and the compiler itself bleeds into the source10:41
gtristanit may contribute to definitions growing and growing10:42
SotKgtristan: A number of the extensions are closely related to the content of definitions rather than the build tool though. We originally planned to move them all into a separate library which the build tool would call out to, but we'd still have ended up with a bunch needing to be in definitions due to their implementation being so tied in with the definitions themselves.10:45
SotKWe then decided that it made more sense to have all the extensions in one place (definitions) rather than keeping them separated across repositories.10:45
gtristanSotK, agreed, thats sort of the difference I was referring to; some extensions really should not be first class citizens in the formalism10:46
gtristanif they are common/useful enough, they should probably be features10:46
SotKgtristan: but that approach leads to code duplication across different build tools, or making one tool depend on another for its write extension code10:47
gtristanI honestly tend to think that code duplication is better, at least in the morph/ybd case I think code sharing could be achieved with common python libs10:48
gtristanhaving a well/strictly defined formalism for the definitions format is more desirable than saving lines of code in build tools10:49
gtristanbut that is an entirely subjective point of view10:49
* paulsher1ood agrees10:50
paulsher1oodeven though i'm fiercely in favour of less loc :)10:51
* locallycompact mutters something about types10:51
paulsher1oodlocallycompact: this is about extensions. they're code, not data10:52
locallycompactall code is types10:52
paulsher1oodheh10:52
*** lachlanmackenzie has joined #baserock10:54
SotKassuming we did move the extensions out, what would we do with the "second class citizen" extensions (which iirc was most of them)11:00
SotK?11:00
paulsher1oodpls give an example?11:01
gtristanSotK, I would favor factoring them into build instructions, or "deploy instructions" or system integration commands, if at all possible11:02
gtristanSotK, I would also favor doing more things in chunks, i.e. install-files gets nuked, and some chunks get added to various systems11:03
gtristanchunks after all are what add payload to a system11:03
SotKpaulsher1ood: practically every non-trivial configure extension11:03
leemingsince this is most likely a general mounting issue. I'm trying to integrate bwrap into sandboxlib but am hitting a lot of problems. Unsure I'm just stupid, the tests not great or bwrap doesn't do this - http://paste.baserock.org/raw/rojujureko11:04
SotKgtristan: what about something like the functionality of sshkeys.configure?11:04
gtristanSotK, interestingly, I cannot find anything in systems/ or clusters/ which mentions 'sshkeys'11:07
gtristanwhich leads me to think; it's actually deadcode ?11:07
SotKperhaps people began using install-files for ssh keys11:08
gtristanWhat I dont understand is what $SSHKEYS is in that extension11:09
gtristanit's a file... where ?11:09
gtristanif it's a file that is in definitions somewhere, then clearly that extension can just be a chunk11:09
gtristanitself11:09
pedroalvarezerm..11:10
pedroalvarezyou want to inject the ssh public key at deplyment time?11:10
pedroalvarezso that you inject yours, I inject mine, and we share all the built artifacts?11:10
gtristanpedroalvarez, as I dont understand how that configure extension was ever intended to work; I dont know.11:11
pedroalvarezhrm..11:11
pedroalvarezyou add in your cluster:11:11
pedroalvarezSSHKEYS: /path/to/my/.ssh/id_rsa.pub11:11
gtristanOk well, if asked the question; honestly it looks like there needs to be some bridge between the definition of a chunk; and the context in which it is built11:13
gtristanSo basically; what is a cluster ?11:14
gtristana deployment, can be a deployment of anything11:14
gtristanSo should a deployment really expose a feature that is specific to ssh ?11:14
gtristanPossibly the chunk needs to declaratively expose some variable that a user can effect at deployment time11:15
gtristanwith the knowledge that they are deploying a system that has sshd ?11:15
pedroalvarezthat was one of the ideas to implement11:15
pedroalvarezsomething like "some chunks give you access to some deployment extensions"11:15
pedroalvarezs/deployment//11:16
gtristanIt could be simply that the user can export some variable (via some key file) that are read during system-integration11:16
gtristanthen the sshd chunk could check for sshd.keys11:16
gtristanwell, that's tricky because you dont have access to outside the system at that point11:17
SotKbut then I couldn't reuse the system artifact from someone else's cache11:17
gtristantrue11:17
gtristanmessy11:17
* SotK likes the "some chunks give you access to some deployment extensions" idea incidentally11:23
gtristanleeming, you probably understand bwrap better at this point by; why would you expect the /data tmpfs to not be writable ?11:24
leemingbecause the root filesystem contains a /data directory and is mounted ro11:24
leemingbut if i try to add in a writable version, it nukes the previous11:25
gtristanleeming, but the /data directory is a mount point for the rw tmpfs right ?11:25
leemingyes11:25
gtristansigh so I think I was derailed: If I want to write a configure extension to package chunks into rpms; where would I start then ?11:47
gtristanIn the context of an extension (write or configure or whatever extension)... can I get a dict of all the artifacts ?11:47
pedroalvarezthat depends on the metadata you have available in $1/baserock/11:49
gtristanpedroalvarez, ummm, so if I have a system ? what metadata would I have, the cache keys for each artifact ? would I have a path to the local artifact cache ?11:52
gtristanalso ?11:52
* gtristan reassembles a system and looks11:52
pedroalvarez:P11:52
gtristan:-/11:52
pedroalvarezI'm not sure what ybd puts in there, tbh :/11:53
paulsher1oodputs in where, sorry?11:58
gtristanSo in the baserock/ directory I have all the .meta files for each chunk in the system11:58
paulsher1oodyup11:58
gtristanThose .meta files have a git ref, but not a cache key11:58
gtristanalso the directory where to get the artifacts is not in context11:59
* gtristan wonders if he could get that too11:59
* gtristan wants a.) a staged system to chroot into b.) a list of all artifacts and their cache keys c.) the cache directory12:00
paulsher1oodthe .meta files *should* contain cache keys then. would be easy to fix12:00
gtristanso just missing the cache directory12:01
gtristanMaybe that could be passed as an argument to the extension somehow ?12:02
pedroalvarezsounds as a massive hack, but from the extensions you have access to any file in the host12:02
gtristanso ybd runs a deployment, and says extensions/package-rpms $1 $212:02
gtristanwhere $1 is a staged sysroot and $2 is the cache dir12:02
paulsher1oodif ybd runs a deployment, it already knows cachekeys for everything and cache dir12:03
paulsher1ood(but the extension doesnn't of course)12:03
gtristanpaulsher1ood, right, but I'm trying to avoid adding unwanted features to ybd proper12:03
paulsher1oodack12:03
gtristanpedroalvarez, so yeah I have *access* to any file on the host... but I dont have access to the exact path where ybd is configured to store artifacts12:06
gtristanhmmm, well; how to elegantly jam this square cube up that round hole :-S12:06
*** ctbruce has quit IRC12:06
*** ctbruce has joined #baserock12:07
* gtristan notes that it would be interesting if each rpm he had to produce was an individual build step that occurred post system assembly12:08
gtristanbut that's unlikely to happen without severely changing ybd anyway12:08
* gtristan goes to eat food :-S12:08
SotKgtristan: do you need to deploy a system and obtain rpms for it, or just obtain rpms for it?12:10
*** gtristan has quit IRC12:14
*** anahuelamo has quit IRC12:43
*** anahuelamo has joined #baserock12:45
paulsher1oodSotK: i think he wants to create rpms from chunks, that can be installed in systems12:58
* paulsher1ood may be wrong though12:58
SotKdoes it have to be a configure extension?13:02
SotKwhy not just write a script which runs ybd with the config option that makes it spit out just cache keys instead of doing a build, and then uses that list of cache keys to get the relevant chunk artifacts and turn them into rpms?13:02
paulsher1oodi think it's more a deployment extension... but can't remember whether those can apply for chunks or not13:02
pedroalvarezthe tool to turn them into rpms is inside the system being deployed13:03
SotKah, I see13:04
* paulsher1ood is unsure why that would be the case13:04
paulsher1oodbut maybe it is13:04
*** toscalix has quit IRC13:36
*** toscalix has joined #baserock13:40
*** gtristan has joined #baserock13:44
leeming(x-posting: sorry but this is really blocking me) I have been staring at this for so long now, I really don't know what to try next... if anyone has experience with linux mounts/ bubblewrap, I appreciate any pointers http://stackoverflow.com/questions/39726445/sandbox-mounting-confusion13:51
richard_mawleeming: doesn't `--tmpfs` mount a new tmpfs at /data when the command is run?13:56
leemingyes13:56
richard_mawI'm confused about the complaint that "however, is the /data directory is totally empty (other than the output of my 'touch /data/testwrite'). Note the original /data partition I wanted to mount, actually contains files.13:56
leemingi need /data to be writable, as per the test.. but i also need it to be the original /data13:57
richard_mawI'm not sure I follow, you need a mutable copy of /data for the test?13:57
richard_mawif --tmpfs does that then it's doing more magic than I thought it would13:58
leemingeven though it is defined in the root partition13:59
leeming(where did my previous comment go>)13:59
leeming /data needs to be writeable, but it is also defined in the test logic to mount as a tmpfs13:59
leemingah13:59
richard_maw--tmpfs mounts a new empty tmpfs on top of the /data directory, which hides the files that were in the partition underneath14:00
leemingso i do need to do some fancy shifting of the data?14:01
leemingI can't see/understand how the linux_user_choot code manages that14:02
richard_mawyeah, unless bwrap has a way to make an ephemeral copy of a directory natively14:02
leemingso.. is the test wrong? im lost14:03
richard_mawI'm missing all context for what this is for. the morph and ybd code I recall didn't need to do that, they did staging areas by creating a hard-link tree and marking subtrees as read-only and copying in a build tree and an install path14:04
richard_mawthe deploy code made a copy without hardlinks, so it was safe to leave bits writable14:05
leemingno idea,,, it is in the test cases for sandboxlib14:05
richard_mawcan you post a link to it?14:05
leeminghttps://github.com/CodethinkLabs/sandboxlib14:05
richard_mawI meant the test in question, but I can browse14:05
leeminghttps://github.com/CodethinkLabs/sandboxlib/blob/master/tests/test_all.py#L18214:06
richard_mawta14:06
leemingthe bit that creates the root-fs is : https://github.com/CodethinkLabs/sandboxlib/blob/master/tests/test_all.py#L10714:07
leemingjust doesn't make sense why it would be part of the root-fs, yet be stated as an extra mount14:07
richard_mawyeah, I don't get the reason for the extra mount either14:09
richard_mawor how it apparently used to work14:09
* leeming wonders if he should just totally fudge the test or not then14:16
richard_mawlooks like the linux-user-chroot code would create parameters for making paths read-only, then a writable bind-mount for a temporary directory into the target path, perhaps linux-user-chroot would process those arguments in a different order14:16
richard_mawI'd remove the extra tmpfs mount, I can't see the need for it14:17
leemingok14:18
locallycompactpaulsher1ood, ok, I have something reasonably coherent, could you help me wedge it into ybd?14:19
*** gtristan has quit IRC14:40
*** persia__ has quit IRC15:01
*** persia has joined #baserock15:04
locallycompactleeming, https://gitlab.com/baserock/defslib15:19
locallycompactso this gets as far as resolving the assemblage, calculating cache keys and flattening the assemblage so it's just a one level deep list of chunks with large build-depends lists15:21
leemingso re how ybd sandboxes. it uses the sandboxlib api, which is essentially "degrade_config_for_capabilities" and "run_sandbox"15:22
leemingI assume dn['sandbox'] is the path to the sandbox root-filesystem15:23
locallycompactif we can pull sandboxing into the library, then the assembly code should be much clearer and shorter than what's currently in ybd15:23
locallycompactthat seems like a strange field ot mutate the definition with15:23
locallycompactwhy does that persist15:23
*** anahuelamo has quit IRC15:23
leemingsorry.. are we mixing each other up?15:24
*** anahuelamo has joined #baserock15:24
locallycompactwhat does that mean15:25
leemingsandboxlib currently has 3 (well 2 in the live version) 'executors'. "degrade_config_for_capabilities" basically picks the best executor, given some config requirements (see sandbox.py::run_sandboxed() for an example) ..15:26
leeminglooks like ybd just passes 'sh -c -e [command]' to the sandbox15:29
richard_maw`sh -e -c` command surely?15:34
*** faybrocklebank has quit IRC15:35
leemingnope15:35
leemingargv = ['sh', '-c', '-e', command]15:35
richard_maweww, sh's command parsing is non-standard then, usually you'd interpret -c as an option that takes a parameter, so it should take its parameter from the next argument15:39
paulsher1oodlocallycompact: would love to help, but the next few days are going to be difficult15:50
paulsher1oodleeming: do you know enough of ybd to assist?15:50
*** ctbruce has quit IRC15:52
* paulsher1ood believes, but can't prove, that either ybd re-uses morhp code, or someone else frabbed the commandline when introducing sandboxlib15:52
paulsher1oodin other words, it's not me :)15:52
* leeming isn't sure if he has satisfied locallycompact 's question15:53
locallycompactI do see what it's doing, ish15:55
leemingit basically gets a pointer/ref to the sandbox wrapper in sandboxlib, so {chroot, linux-user-chroot, bwrap}15:59
leemingthey all have the run_sandbox method15:59
* paulsher1ood looks at defslib, sees 'MorphologyResolver' and 'Actuator' and wonders if there aren't simpler words than those16:19
leemingMorphResolver is simpler, but I think it would raise an eyebrow16:20
rdaleanything with 'Morph' in it is confusing16:20
leemingbetter than naming it 'def' imo16:20
leemingalthough naming.. yes..16:21
leemingbut maintaining consistency with prior tooling is another thing to consider, no?16:21
locallycompactthe point of actuator is that it's effective, it accepts a dictionary of "places things should go", and some aliases, and a tree server. Ideally I'd like that to be all it should need to build an assemblage with filesystem effects.16:22
leemingwhat is meant by "assemblage" and "filesystem effects" in this context?16:23
locallycompactassemblage is the new data type, it replaces system and stratum16:24
leemingsome collection then?16:24
locallycompactnominally yes16:24
locallycompactit's defined here https://gitlab.com/baserock/spec/blob/lc/010/schemas/assemblage.json-schema16:25
locallycompactby filesystem effects I mean actual affects that affect the filesystem via IO16:26
locallycompactHaskell would make that distinction by type at compile time so I make the distinction as best as possible in python with documentation16:26
leeming"actual affects that affect the filesystem"16:27
locallycompact*effects16:27
leemingok, but that doesn't make it clearly for me. but nvm16:28
locallycompactThe class will actually try and do things outside of program memory16:29
leemingoh sorry, so just simply IO16:30
leemingi thought you were defining a new keyword16:31
leemingalso, note the time... and my brain has not worked properly for weeks16:31
paulsher1oodleeming: shame. does your employer know? :)16:32
rdalewhat is the difference between an 'assembly' and an 'assemblage'?16:32
leemingpaulsher1ood, well my failures are recorded :)16:33
*** jjardon has quit IRC16:36
*** lachlanmackenzie has quit IRC16:37
*** radiofree has quit IRC16:37
*** rjek has quit IRC16:37
*** zoli_ has quit IRC16:37
*** toscalix_ has joined #baserock16:37
*** CTtpollard has quit IRC16:37
*** locallycompact has quit IRC16:37
*** rdale has quit IRC16:37
*** anahuelamo has quit IRC16:37
*** vgrade_ has quit IRC16:37
*** rjek has joined #baserock16:37
*** perryl has quit IRC16:37
*** lachlanmackenzie has joined #baserock16:37
*** perryl has joined #baserock16:37
*** anahuelamo_ has joined #baserock16:38
*** bfletcher has quit IRC16:38
*** toscalix has quit IRC16:38
*** vgrade has joined #baserock16:38
*** radiofree has joined #baserock16:39
*** rdale has joined #baserock16:40
*** franred has quit IRC16:43
*** cyndis has quit IRC16:46
*** toscalix has joined #baserock16:46
*** lachlanmackenzie has quit IRC16:47
*** jjardon_matrix has quit IRC16:47
*** paulsher1ood has quit IRC16:47
*** toscalix_ has quit IRC16:47
*** paulsherwood has joined #baserock16:47
*** anahuelamo__ has joined #baserock16:47
*** vgrade has quit IRC16:47
*** JPohlmann has quit IRC16:47
*** vgrade has joined #baserock16:47
*** Lachlan1975 has joined #baserock16:48
*** anahuelamo_ has quit IRC16:48
*** franred has joined #baserock16:48
*** CTtpollard has joined #baserock16:49
*** locallycompact has joined #baserock16:53
*** JPohlmann has joined #baserock16:55
*** JPohlmann has joined #baserock16:55
*** bfletcher has joined #baserock16:55
*** cyndis has joined #baserock17:00
*** jjardon has joined #baserock17:00
*** toscalix has quit IRC17:11
*** jjardon has quit IRC17:11
*** bfletcher has quit IRC17:11
*** locallycompact has quit IRC17:11
*** toscalix has joined #baserock17:11
*** franred has quit IRC17:11
*** anahuelamo__ has quit IRC17:12
*** anahuelamo__ has joined #baserock17:12
*** CTtpollard has quit IRC17:12
*** lc_ has joined #baserock17:12
*** franred_ has joined #baserock17:12
*** CTtpollard has joined #baserock17:13
*** tiagogomes has quit IRC17:21
*** lachlanmackenzie has joined #baserock17:22
*** lc__ has joined #baserock17:22
*** Lachlan1975 has quit IRC17:22
*** CTtpollard has quit IRC17:22
*** lc_ has quit IRC17:22
*** tiagogomes has joined #baserock17:24
*** CTtpollard has joined #baserock17:24
*** lc__ has quit IRC17:32
*** jjardon has joined #baserock17:37
*** bfletcher has joined #baserock17:54
*** rdale has quit IRC18:03
*** lachlanmackenzie has quit IRC18:10
*** lachlanmackenzie has joined #baserock18:10
*** bfletcher has quit IRC18:11
*** zoli_ has joined #baserock18:38
*** bfletcher has joined #baserock18:40
*** toscalix has quit IRC18:45
*** gtristan has joined #baserock19:23
*** jjardon has quit IRC19:26
*** lachlanmackenzie has quit IRC19:27
*** bfletcher has quit IRC19:27
*** gtristan has quit IRC19:27
*** lachlanmackenzie has joined #baserock19:29
*** _longines has quit IRC19:34
*** juergbi has quit IRC19:34
*** SotK has quit IRC19:34
*** richard_maw has quit IRC19:34
*** leeming has quit IRC19:35
*** bjdooks has quit IRC19:35
*** _longines has joined #baserock19:35
*** leeming has joined #baserock19:36
*** lachlanmackenzie has quit IRC19:36
*** SotK has joined #baserock19:37
*** SotK has quit IRC19:37
*** SotK has joined #baserock19:38
*** lachlanmackenzie has joined #baserock19:38
*** juergbi has joined #baserock19:38
*** gtristan has joined #baserock19:39
*** bjdooks has joined #baserock19:45
*** bfletcher has joined #baserock19:49
*** richard_maw has joined #baserock19:53
*** ChanServ sets mode: +v richard_maw19:53
*** jjardon has joined #baserock19:57
*** jjardon has quit IRC20:22
*** bfletcher has quit IRC20:23
*** juergbi has quit IRC20:24
*** juergbi has joined #baserock20:24
*** bfletcher has joined #baserock20:35
*** jjardon has joined #baserock20:43
*** juergbi` has joined #baserock20:44
*** juergbi has quit IRC20:45
*** bfletcher has quit IRC20:45
*** gtristan has quit IRC20:58
*** cosm has quit IRC21:04
*** trn has left #baserock21:51
*** bfletcher has joined #baserock21:58
*** vgrade has quit IRC22:50
*** vgrade has joined #baserock22:50
*** JPohlmann has quit IRC22:51
*** JPohlmann has joined #baserock22:53
*** jjardon_matrix has joined #baserock23:02

Generated by irclog2html.py 2.15.3 by Marius Gedminas - find it at mg.pov.lt!