IRC logs for #baserock for Thursday, 2014-10-16

*** radiofree [radiofree@unaffiliated/radiofree] has quit [Read error: Connection reset by peer]00:38
*** radiofree [radiofree@unaffiliated/radiofree] has joined #baserock00:41
*** radiofree [radiofree@unaffiliated/radiofree] has quit [Ping timeout: 260 seconds]00:55
*** radiofree [radiofree@unaffiliated/radiofree] has joined #baserock00:57
*** radiofree [radiofree@unaffiliated/radiofree] has quit [Read error: Connection reset by peer]01:00
*** radiofree [radiofree@unaffiliated/radiofree] has joined #baserock01:02
*** radiofree [radiofree@unaffiliated/radiofree] has quit [Read error: Connection reset by peer]01:38
*** radiofree [radiofree@unaffiliated/radiofree] has joined #baserock01:40
*** radiofree [radiofree@unaffiliated/radiofree] has quit [Ping timeout: 260 seconds]05:27
*** radiofree [radiofree@unaffiliated/radiofree] has joined #baserock05:27
richard_mawwell, we can build a devel system without /dev/shm in the staging area07:17
*** tiagogomes [~tiagogome@] has joined #baserock07:34
paulsherwoodis there source of radiofree's jetson flasher script somewhere?07:54
*** dutch_ [] has joined #baserock08:10
richard_mawpaulsherwood: not that I know of, just inside the tarball08:11
richard_mawI know it didn't get sent for review anywhere, or I would have pointed out the bashism which caused the confusion when people were running it on systems that weren't fedora.08:17
paulsherwoodok. we should get james or someone to submit it, for inclusion in scripts08:18
Kinnisonrichard_maw: I'd be concerned that some build systems might run tests or tools which require /dev/shm during build08:26
Kinnisonrichard_maw: i.e. if we can have /dev/shm I'd be happier08:26
*** jonathanmaw [] has joined #baserock08:35
*** radiofree [radiofree@unaffiliated/radiofree] has quit [Ping timeout: 260 seconds]08:41
*** radiofree [radiofree@unaffiliated/radiofree] has joined #baserock08:41
paulsherwoodwhat is /dev/shm and what do we need it?08:47
paulsherwoods/it/it for/08:47
KinnisonIt's where shared memory segments come from for SYSV shm segments08:50
paulsherwoodKinnison: sorry, i don't understand that - too tech for me i'm afraid. what do we need it for please?08:51
KinnisonAccording to Richard Maw, nothing currently08:52
KinnisonBut I'd be concerned that build systems might behave differently in the absence of it08:52
Kinnisone.g. if a configure script *tested* for shmget working08:52
Kinnisonrather than just its presence08:52
Kinnisonor a build system was metaprogrammed and needed shm for running a build tool08:52
KinnisonIt just feels odd not to have it available08:52
paulsherwoodok thanks08:53
jjardonHi! Is there a page with the list of components a system should have to be genivi compliant ? 08:53
KinnisonI imagine in GENIVI's documentation there will be08:55
KinnisonI doubt we maintain a separate one08:56
paulsherwoodwe cannot maintain apublic one.. the spec is confidential09:04
rjek... really?09:05
wikicatrjek: Error: ".." is not a valid command.09:05
rjekwikicat: Be silent.09:05
wikicatrjek: Error: "Be" is not a valid command.09:05
* Kinnison assumes straycat will disable wikicat's interaction with the channe;09:06
* Kinnison rephrases...09:07
Kinnisonstraycat: Please disable wikicat's interaction with the channel.09:07
paulsherwooddon't we like wikicat, then?09:07
KinnisonI'm happy for wikicat to tell us when things happen09:08
petefothI think there are other ways of being kept informed of vhanges to w.b.o without adding to traffic in this channel09:08
KinnisonI don't want it responding to people who start lines with a dot09:09
rjekI like wikicat's edit announcements.09:09
rjekBut public commands are an abomination.09:09
KinnisonAt least ones which aren't obviously directed09:09
jjardonOh, didn't know the spec was confidential; that explain why I was struggling trying to find it in the genivi docs yesterday 09:10
KinnisonGENIVI is a commercial entity09:10
Kinnisontheir *output* is, to some extent, free software09:10
Kinnisonbut their intermediates are proprietary09:11
robtaylorrichard_maw: have you seen this wotrk by harald hoyer?
richard_mawrobtaylor: an earlier version of it09:12
richard_mawit was posted to google+ soon after Lennart's proposal for apps.09:13
paulsherwoodrobtaylor: what does it *do*? 09:18
*** ssam2 [] has joined #baserock09:19
jjardonI'd say commercial and free software are orthogonal things. But thanks for the info09:20
KinnisonAt least it's not free-core-proprietary-full09:21
*** Krin [] has joined #baserock09:22
*** radiofree [radiofree@unaffiliated/radiofree] has quit [Read error: Connection reset by peer]09:28
*** radiofree [radiofree@unaffiliated/radiofree] has joined #baserock09:31
ssam2ripsum: I pushed code to the baserock:baserock/import repo last night09:37
ssam2still needs quite a bit of tidying up09:38
ssam2but no longer needs the x-dependencies fields, it uses a separate .foreign-dependencies file instead09:38
ssam2which means it doesn't need a patch to morph in order to work09:38
ssam2and I split out the dependency calculation into a separate .find_deps extension instead of doing it in the .to_chunk extension09:38
ssam2you should move your pip work to a branch in that repo, when convenient09:39
Zaraif I'm editing a stratum, where would I find the ref I need for the 'ref' field?09:50
robtaylorpaulsherwood: read only rootfs 09:52
robtaylorrichard_maw: so, apparently for btrfs write stability we need to regularly defrag and balance09:52
robtaylorrichard_maw: i suspect a patch to systemd to add a unit to do this would be well received09:53
ssam2zara: you can actually put any valid Git ref there09:53
ssam2e.g. 'master'09:53
ssam2but as a policy we restrict the ones in the master branch of definitions.git to be exact commit SHA1s09:54
ssam2to resolve a git ref to a SHA1 you can use the `git show-ref` command09:54
richard_mawor `git rev-parse $REF`09:55
ssam2wow. "ERROR: Conflicting versions of stratum 'tools-devel' appear in the build. Check the contents of the system against the build-depends of the strata."11:04
ssam2that's an error I've not seen for a while11:04
paulsherwoodshouldn't be possible any longer? :)11:05
ssam2but jjardon seems to have worked magic :)11:06
jjardonssam2: sorry, I only tested the genivi-baseline to check that branch11:09
ssam2it's a pretty unexpected error to be honest11:18
ssam2the problem is that the 'tools' stratum appears in the build graph twice11:19
ssam2since all strata are in the same repo now, it's not the old problem we had where two versions of the same stratum could be pulled in11:20
ssam2in fact, i'm so confused11:20
* straycat sees that '.' was not a good choice for a command character11:21
ssam2hah, OK, I see the problem11:32
ssam2coreutils-common.morph has 'name: tools' at the top :)11:32
ssam2maybe it's time for Morph to enforce morph name == file basename11:33
straycatCould we get rid of the name key now?12:02
straycatI mean name field12:02
ssam2I like having it. I fear holy war.12:03
straycatWell, if we are to enforce morph name == file basename, that suggests we're storing redundant data.12:04
ssam2depends if the morphology has a filename. It could be in a pastebin, or a presentation slide, or a design document, or inlined in a test case12:04
ssam2only when its stored in a file in a git repo or on disk does it necessarily have a filename12:05
straycatAnd in all of those cases you can give it a meaningful name.12:05
* Kinnison would rather not enforce name == basename12:05
* Kinnison would rather report a better error:12:05
Kinnison"ERROR: name 'tools-devel' is present in some/file.morph and some/other/file.morph"12:06
Krini heard tell a while back about a strata for Java on baserock, is this true and if so could someone point me in the direction to start walking to add said strata?12:06
KinnisonAnd I'd like it if the graph was checked so that build-depends (which state both morph and name) get the name checked12:06
KinnisonKrin: franred did some work to add a stratum for Java12:06
KinnisonKrin: But it was not ideal12:06
ssam2Kinnison: i'm not sure what you mean about build-depends.12:07
KrinKinnison, not ideal meaning... not working? or...12:07
ssam2Kinnison: changing the 'conflicting versions of strata' error to what you described there seems reasonable12:08
straycatOr we could just remove the name field and make conficting strata impossible.12:08
Kinnisonssam2: I mean, in strata (and systems) when we refer to other strata, we mention both name and morph -- we should validate that the name in the morph matches the name in the includer morphology12:08
* Kinnison likes the idea that there might be multiple variants of the "foo" stratum12:09
KinnisonBut ultimately if the upstream project chooses to dump the name field, I won't whinge12:09
Kinnisonwell, I will, but I'll try and do it quietly and far away :-)12:09
straycatI can't see why that would be useful, things we have multiple variants of, such as bsps already have unique names.12:09
franredKrin, java 8 works in baserock in the gerrit stratum12:09
franredas Kinnison said it is not the baserock way but java is difficult to bootstrap12:10
Krinok so i need to add the gerrit stratum before i add the zookeeper one? (as zookeeper requires java it seems)12:11
Kinnisonshort-term I'd abstract the javaness out of the gerrit stratum, and then make a zookeeper stratum which depended on the java one12:11
franredKrin, no, you need to add java to an stratum or add the part of the chunk which install java12:11
franredKinnison beats me12:12
Krinstill kind of trying to work out how to construct chunks / strata, begining to realise i dont understand baserock uch, well i understand the concept, it's the actual doing that i'm clueless on *goes back to the wiki and feels he needs a reading hat*12:13
* Kinnison grins12:13
KinnisonHave you followed the adding-something-to-baserock tutorial?12:13
paulsherwoodKrin: it's because some of our nomenclature sucks, tbh. 12:14
Krinto be honest Kinnison most of that tutorial simply says to "do this bit" when "this bit" is what i'm struggling to work out how to do :)12:14
KinnisonKrin: Please do try to go through the tutorial first, and where you're confused, ask here for assistance -- when you are unconfused, *please* augment the wiki page :-)12:15
Krinadd a new stratum to it12:16
Krincreate your new stratum file12:16
Krinadd new chunk(s) in that for your component(s), specifying repo as ...12:16
Krinthose bits are kind of... brief :)12:16
Kinnisonmmm, very true12:16
Kinnisonpetefoth: Do you fancy (a) helping Krin understand and (b) helping augment the docs?12:16
Kinnisonpetefoth: You're better at wording than I am12:17
richard_mawpetefoth wordulates most cromulently12:17
straycatIf the name field is desireable from a ui point of view we could keep it but in the morphs, but drop it internally.12:18
richard_mawbut then it gets out of sync and confuses12:18
* petefoth reponds in a less public channel12:18
* straycat nods12:19
paulsherwoodcan someone just recommend a small chunk of FOSS goodness that isn't in baserock, and is likely to build without too much pain?12:24
* Kinnison ponders12:26
richard_mawnothing springs to mind12:26
rjekFOSS goodness to do anything specific?12:26
Kinnisonsomething whose b-ds are all already in there?12:26
* paulsherwood will make a tutorial12:26
richard_mawI think we've built bonnie before12:26
rjek :)12:26
* Kinnison thinks it'd be nice to have moreutils and/or extrautils12:26
* Kinnison would like emacs in the devel system too12:27
KinnisonAlso gdb12:27
richard_mawwe have gdb12:27
* richard_maw remembers watching it build12:27
paulsherwoodI'm not doing emacs. ever12:27
Kinnisonpfeh, emacs is easy12:27
Kinnisonbenbrown_ proved that12:27
* rjek wonders if binetd builds anymore12:27
petefothwe (i.e. Codethin internally) have scripts for many tutorials (including one that builds bonnie IIRC.12:28
petefothPerhapes we should make those public rather than startign from scratch?12:28
richard_mawrjek: google isn't revealing the meaning of binetd12:28
rjek :)12:29
rjekBob's inetd.  Trivial command-line inetd kinda thing12:29
paulsherwoodpetefoth: publish and be damned. but i bet it's not currnet12:29
rjekie, it listens on a socket and spawns things when there are connections so unprivileged users can easily run inetd-expecting things12:29
petefothpaulsherwood: OK. I'll publish with a health warning12:30
richard_mawrjek: ah, I've written a couple of those. One even doing udp nowait12:30
rjekAh, this is trivial and only does tcp12:30
rjekIt's so trivial it doesn't even have a makefile12:30
rjekls -l12:31
* rjek is petefoth.12:31
richard_mawrjek: got a python version of that, hard-coded to launch a git-daemon
richard_mawexcept it spawns an ephemeral port and tells you what is is, rather than letting you pass one in12:34
* rjek nods12:35
richard_mawbusybox also has udpsvd and tcpsvd when you don't want to use inetd12:36
* rjek wrote binetd over a decade ago while learning BSD sockets.12:37
*** fay_ [] has quit [Ping timeout: 250 seconds]13:05
*** fay_ [] has joined #baserock13:19
ssam2Zara: I saw this article recently which may give useful info about NPM:
ssam2it's written by the Nix guys, Nix being a package manager, distro, build environment, and CI system which manages to be even more complex than Baserock13:29
Zarahaha, ok, I'll have a read through13:29
Zarabtw, I tried to build a system with express by editing a stratum and the corresponding system (and also by creating a stratum and a corresponding system), but I kept getting the error 'couldn't find morphology'. Is there something else I need to do? the stratum and system are definitely in the right directories (and have the right names!)13:32
ssam2ah, right13:34
ssam2you sometimes need a chunk morphology too, if the project's build system doesn't follow a pattern that Morph knows about13:35
ssam2and I very much doubt that Morph knows how to build 'express' ?13:35
ssam2do they provide instructions on how to build it from git?13:35
Zaraah, ok, I thought it might be that (if that corresponds to "     13:35
ZaraUnless the software you're adding is has a 'normal' build system recognised by Baserock (currently autotools, cmake) you'll probably need to script the build instructions in a morph file for your repo (see other morph files for examples), stored as chunkname.repo in the root of the git repository you created in your branch. "13:36
ssam2wow, the end of that sentence is rather weird13:36
Zarathey might provide instructions somewhere or other, though I don't think they're in the readme13:38
ssam2yes, they want you to just use NPM13:39
Zaraok, I bookmarked a generic 'installing node packages sans npm' page a little while ago, but I wanted to check that was the problem before I spent too much time on it. :)13:39
ssam2it's probably easier to try the commands at the commandline, then once you have a process that works, put it into a morphology13:40
ssam2also, it's not forbidden to use NPM in Baserock: we just don't want it to download and install dependencies from the internet as part of the build process13:41
ssam2so maybe you can work out how to get 'npm install' to run without doing that13:41
Zarassam2: it does *seem* to work (it doesn't report any errors), but then express doesn't run so I assume there's another step.13:42
*** genii [~quassel@ubuntu/member/genii] has quit [Remote host closed the connection]13:47
Zaraanyway, going from the wiki instructions above: I'm not sure where to find a morph file with build instructions to use as a example/template for this; does anyone have any recommendations?13:50
pedroalvarezZara: there are loads of them in definitions.git13:51
pedroalvarezZara: so if you go to "strata/name-of-stratum/" inside you will find the chunk morphologies needed to build the stratum with name "strata/name-of-stratum.morph"13:52
Zaraahhh, right13:56
*** thecorconian [~thecorcon@] has joined #baserock13:56
*** thecorconian [~thecorcon@] has quit []13:56
Zaraso the chunk morphologies are like files in directories?13:56
Zarawhere the directory title is the name of the stratum13:57
pedroalvarezZara: yup! :)13:57
pedroalvarezdoes that makes sense to you?13:57
Zarayes, it does :)13:57
pedroalvarezZara: it  is flexible though, so you can point from one stratum to the chunk morphology of another stratum directory, but that would make it complex13:58
richard_mawyou could put the chunk morphology anywhere, we just put it in a directory per stratum because it's tidy13:59
Zarapedroalvarez: Ok, well I won't worry about that for now :) I think I was just confused by the terminology.13:59
*** genii [~quassel@ubuntu/member/genii] has joined #baserock14:25
*** fay_ [] has quit [Ping timeout: 258 seconds]14:26
paulsherwoodfwiw while globetrotting i've started hacking to explore some of the ideas from the baserock user meetup which happened in August....14:28
rjekpaulsherwood: OOI, "brock" ?14:29
paulsherwoodfor fun14:29
paulsherwoodanything not morph would be fine for me14:29
paulsherwoodnote it doesn't actually *build* anything, but on the other hand it eats the whole definitions dataset into build order in approx 1 second14:31
KinnisonIncl. everything being locked down to tree shas?14:32
paulsherwoodnot quite, but i think i know how to do that14:32
straycatthe morph codebase is actually not that bad.14:32
paulsherwoodi've started fiddling with the git stuff since i last pushed14:32
KinnisonCall me back when it constructs the same dataset twice in a row, even when someone moves a git ref along14:32
paulsherwoodoh, i'm sure i can do that.14:33
KinnisonThe reason morph is slow at constructing that dataset is because it has to go examine repos for data it *could* cache in the definitions instead14:33
straycatI've recently been looking at much simpler tools that are in much worse shape.14:33
*** fay_ [] has joined #baserock14:33
paulsherwoodKinnison: i think we'll have to agree to differ, until such time as a can prove my point :)14:34
* Kinnison shrugs14:34
KinnisonIt depends on where your priorities are14:34
Kinnisonyou don't need to lock down to tree SHAs if you don't care about rebuilds happening unnecessarily14:34
paulsherwoodi do care about that14:35
paulsherwoodi just think it can be much simpler than what we've come up with14:35
KinnisonWe have a non-trivial amount of complexity, which could possibly be simplified.  But in a lot of cases, it's complexity to support use-cases which would otherwise fail.14:36
straycatWhat we have at the moment is quite simple, at least conceptually.14:36
paulsherwoodanyway, i know others have other ideas, and in the meantime i have noticed that morph seems to have got a lot faster this week, unless it's my imagination14:36
KinnisonWe have done a lot to get rid of useless re-doing of work in morph I believe14:36
wikicatWiki change: Improve 'adding-stuff' a bit (hopefully it's an improvement);a=commitdiff;h=f87d95114:37
straycatIt might be nice to replace local build with distbuild, this has been suggested before I'm just repeating it.14:41
* Kinnison would like that too, and I think richard_maw's work is heading in that direction14:41
Kinnisonwe need to improve the error feedback and debugability for distbuilt though14:41
Kinnisonotherwise we lose functionality14:42
richard_mawwait, that's wrong14:42
straycatIt would definitely be great to optimise the processes involved in determining build order, cache keys etc. As far as I'm aware that's not really something we've focused on too much.14:42
straycatKinnison, *nod*14:42
richard_mawI was going to have a crack at that after parallel test suite, since my goal yesterday was to see if I could bring the testing time down14:42
straycatWe were planning to drop workspaces too I thought14:46
straycatI'm not sure I understand "users can understand and diagnose the cache naming scheme"14:47
richard_maw$ currently14:48$SHA would be better for tab-completion :)14:48
richard_mawor a directory tree14:48
Kinnisontbf, humans shouldn't be interacting with the cache14:48
Kinnisonthat they do, is an abstraction leak14:49
richard_mawpaulsherwood has proposed "$name|${hash}.cache"14:49
* Kinnison dislikes filenames with shell metacharacters in14:49
* richard_maw fails to see how this is better than "${hash}.chunk.${name}"14:49
straycatI think we tend to interact with the cache more than we would because we've ended up doing things that cause the cache keys to change on us in unexpected ways.14:51
KinnisonI think we interact with it more than we should because we lack some commands, and we leak artifact ids into standard logging14:52
straycatDo you think it would be nice to have a command that gave you the cache status of a chunk?14:53
KinnisonBut a command which streamed you the chunk artifact contents as a tarball would be good14:53
KinnisonDitto for systems etc14:54
* straycat nods14:54
ssam2since we rebuild more is needed, users will always be curious about the cache14:54
Kinnisonsince people sometimes just want to poke at it and say "Did it include the files I wanted?"14:54
ssam2*more than14:54
Kinnisonssam2: s/needed/commonly expected/14:54
Kinnisonssam2: if we rebuild more than is needed, we're doing it wrong14:54
ssam2ok, we're doing it wrong14:54
ssam2changing README.txt in gcc.git shouldn't require me to rebuild the whole operating system14:55
richard_mawyes, but I'm not convinced ABI manifests are feasible14:55
Kinnisonssam2: So you say -- but what if it *does* have an effect14:55
richard_maw*that* would be the game changer for rebuilds14:55
Kinnisonssam2: there's little we can algorithmically do for that14:55
ssam2our build process may be the best available compromise14:55
ssam2but it's always going to make users confused about why things were rebuilt and not cached. I don't think we can pretend that the caching is "magic"14:56
Kinnisonrichard_maw: aye, it is certainly hard to see how they might be tractable14:56
*** violeta_ [] has quit [Ping timeout: 240 seconds]14:59
richard_mawthe best I think we could get is to build-depend on an abi manifest, and if we've got anything of an older ABI manifest, we can build against that, rather than having to build the new version of its dependency first14:59
richard_mawbut we'd still need to build the new version, and fail the build if after we've built it, it turns out not to have the right ABI14:59
KinnisonConstructing the manifest, and comparing them, are the two big things to work out15:00
KinnisonHowever, perhaps we've overcomplicated things again15:00
KinnisonI don't know for sure15:00
richard_mawplus, you _need_ to be able to extend it to arbitrary chunks, rather than just C, so we'd need new tooling15:00
richard_mawand not everything _has_ an ABI15:01
richard_mawthe best fallback would probably be to hash everything in DESTDIR in a stable order15:01
Kinnisonit's hard15:02
*** rdale [] has joined #baserock15:06
*** violeta_ [] has joined #baserock15:14
*** franred [] has quit [Ping timeout: 272 seconds]15:32
*** franred [] has joined #baserock15:40
rdaleis it possible to build baserock for arm in a chroot?15:55
*** tiagogomes [~tiagogome@] has quit [Ping timeout: 240 seconds]15:55
richard_mawif you have an arm device to build it on15:55
doffmrdale: A chroot on an X86 machine? Not as far as i'm aware. There is no cross compile currently.15:55
rdaleno a chroot on an arm based laptop15:56
richard_mawit should be possible if your kernel is recent enough and has mount and network namespaces enabled15:56
pedroalvarezis there any easy test to check that?15:58
rdaleit has linux 3.8.11 on it15:58
Kinnisonrdale: I regularly use a baserock chroot on x86_64 to use an armv7lhf distbuild cluster15:58
rdaleit looks like chrome os uses network namespaces itself and so they must be in the kernel and the chros shell has a mount command in it16:08
richard_mawit stands a chance then. How much storage do you have available?16:11
rdalenot much in the laptop itself, and so i'm formatting a 16gb usb stick in ext416:15
pedroalvarezrdale: any chance you can get a bigger thingy to use as storage?16:16
rdaleyes, i could - is 16 gb enough to see if it works or not?16:17
pedroalvarezI think is enough to see if it works, yes.16:18
pedroalvarezwe didn't create a tarball release of armv7lhf on the latest release16:19
pedroalvarezbut is would be possible to extract the rootfs from the jetson image16:20
Krinif you need more storage rdale , the jets i was using previusly was packaged away again with a SSDD16:28
rdaleok, so i would copy the rootfs from that into the chroot then?16:29
pedroalvarezwe have tools to make easier the use of baserock in a chroot, and I think that these tools use tarballs16:32
pedroalvareznot sure though16:32
KinnisonThey do16:32
Kinnisonthey expect chroot systems built and deployed as tarballs16:32
pedroalvarezso, if he creates a tar file with the rootfs extracted, he can use the tools?16:33
pedroalvarezbtw, these tools are explained here:
Kinnisonprobably, yes16:34
KinnisonNote, those tools expect schroot to be available16:34
pedroalvarezKinnison: yup, that is noted in the wiki page I've linked16:34
* Kinnison crawls back under his rock ;-)16:35
*** jonathanmaw [] has quit [Quit: Leaving]16:36
*** vmeson [~quassel@] has quit [Ping timeout: 240 seconds]16:39
*** Krin [] has quit [Quit: Leaving]16:45
*** ssam2 [] has quit [Quit: Leaving]17:16
*** thecorconian [~thecorcon@] has joined #baserock17:19
*** dutch_ [] has quit [Ping timeout: 265 seconds]17:33
*** rdale [] has quit [Ping timeout: 272 seconds]17:37
*** dutch_ [] has joined #baserock17:47
*** vmeson [~quassel@] has joined #baserock18:04
*** thecorconian [~thecorcon@] has quit [Ping timeout: 260 seconds]18:49
*** dutch_ [] has quit [Quit: Quit]18:57
*** genii [~quassel@ubuntu/member/genii] has quit [Read error: Connection reset by peer]21:02
*** wikicat [] has quit [Remote host closed the connection]22:21
*** wikicat [] has joined #baserock22:21
*** rjek [~rjek@gateway/shell/pepperfish/x-ngxsjnmkijdsfmse] has quit [Ping timeout: 258 seconds]22:24
*** rjek [~rjek@gateway/shell/pepperfish/x-rjmkpdzfhqiuguqz] has joined #baserock22:32

Generated by 2.15.3 by Marius Gedminas - find it at!