IRC logs for #baserock for Thursday, 2014-12-18

*** De|ta [~arc@195.242.156.171] has quit [Ping timeout: 264 seconds]00:15
*** SotK [~adamcoldr@access.ducie-dc1.codethink.co.uk] has quit [Ping timeout: 245 seconds]00:16
*** De|ta [~arc@195.242.156.171] has joined #baserock00:16
*** br_logger [~ubuntu@85.199.252.189] has quit [Ping timeout: 245 seconds]00:16
*** benbrown_ [~benbrown@access.ducie-dc1.codethink.co.uk] has quit [Ping timeout: 245 seconds]00:16
*** br_logger [~ubuntu@85.199.252.189] has joined #baserock00:16
*** benbrown_ [~benbrown@access.ducie-dc1.codethink.co.uk] has joined #baserock00:16
*** SotK [~adamcoldr@access.ducie-dc1.codethink.co.uk] has joined #baserock00:16
*** rdale [~quassel@196.Red-79-153-62.dynamicIP.rima-tde.net] has joined #baserock01:10
*** rdale_ [~quassel@200.Red-83-59-206.dynamicIP.rima-tde.net] has quit [Ping timeout: 264 seconds]01:13
*** zoli_ [~zoli_@linaro/zoli] has joined #baserock05:28
*** petefoth [~petefoth@host-92-25-64-58.as13285.net] has joined #baserock06:34
*** petefoth [~petefoth@host-92-25-64-58.as13285.net] has quit [Quit: petefoth]07:03
*** petefoth [~petefoth@host-92-25-64-58.as13285.net] has joined #baserock07:05
*** mariaderidder [~maria@82-70-136-246.dsl.in-addr.zen.co.uk] has joined #baserock08:06
*** CTtpollard [~tom@82-70-136-246.dsl.in-addr.zen.co.uk] has quit [Quit: Ex-Chat]08:31
*** franred [~franred@82-70-136-246.dsl.in-addr.zen.co.uk] has joined #baserock08:34
*** bashrc [~motters@82-70-136-246.dsl.in-addr.zen.co.uk] has joined #baserock09:02
paulsher1oodfranred: one email would have been enough :)09:06
franredpaulsher1ood, true, Im from the old school and use to remark all the errors, I will send only one next time09:08
paulsher1ood:-)09:12
*** ssam2 [~ssam2@82-70-136-246.dsl.in-addr.zen.co.uk] has joined #baserock09:46
Mode #baserock +v ssam2 by ChanServ09:46
ssam2could anyone cast a 'yes or no' vote on my 'morph: Error message improvements' patch series please?10:09
ssam2it seems to be getting various eyes but nobody dares give a final +1 or -110:09
ssam2Thanks Krin for reviewing it by the way. Maybe you could be a bit more confident and give it a +1 :)10:11
* Kinnison has cast an eye over it, agrees with straycat and richard_maw and gives you a conditional +1 on those cleanups10:11
ssam2ok, thanks10:11
*** Krin [~mikesmith@82-70-136-246.dsl.in-addr.zen.co.uk] has joined #baserock10:12
KinnisonIn general, I approve of improving messages10:12
*** CTtpollard [~tom@82-70-136-246.dsl.in-addr.zen.co.uk] has joined #baserock10:27
*** rdale_ [~quassel@117.Red-83-49-223.dynamicIP.rima-tde.net] has joined #baserock10:35
*** rdale [~quassel@196.Red-79-153-62.dynamicIP.rima-tde.net] has quit [Read error: Connection reset by peer]10:36
Krinhey all, if anyone has the time, could i have a second reviewer on the zookeeper work? 10:51
Krinas added incentive for anyone in the CT building, I will attempt to do the shuffle when I leave today for everyone's amusement if it gets a second reviewer (has a feeling he's going to regret saying that as it's a long way from his desk to the door and the shuffle is not a very efficient movement)10:53
Kinnisonis it as bad as concertina motion for snakes?10:54
Krinroughly. only on foot is involved in moving across the surface10:55
Kinnisonoh my10:56
radiofreedoes anyone know how i would fix this http://i.imgur.com/s0wJIgD.png10:57
radiofreegenivi baseline image, looks fine on a devel image10:57
Kinnisonlooks like a terminal issue10:58
Kinnisonwhat is TERM set to?10:58
radiofreexterm10:58
radiofreei don't have the tools stratum on a genivi image, if that makes a difference?10:59
radiofreethis is what it looks like when i reboot into factory http://i.imgur.com/C2M7Hj0.png11:00
Kinnisonmight be a different pager?11:00
radiofreei suppose it's a minor issue, since you're not really supposed to be using a genivi image as a development system anyway11:01
radiofreei'll try adding the tools to see if that fixes it11:02
pedroalvarezradiofree: genivi images doesn't have 'less' I believe11:19
*** rdale [~quassel@97.Red-81-35-54.dynamicIP.rima-tde.net] has joined #baserock11:38
*** rdale_ [~quassel@117.Red-83-49-223.dynamicIP.rima-tde.net] has quit [Ping timeout: 245 seconds]11:40
*** franred [~franred@82-70-136-246.dsl.in-addr.zen.co.uk] has quit [Quit: Leaving]11:42
ssam2Krin: looking at the 'baserock/mikesmith/zookeeper' branch of definitions, it looks like you didn't squash the fix you did into the previous commit11:53
ssam2not everyone agrees that this is needed, but it does make things neater, and Pedro did say "+1 Assuming that the git history is not "commits-of-first-patch-series and11:53
ssam2commits-of-fixes", and that the fixes are squashed in the first commits."11:53
Krinno, i have not ssam2 i was intending to squish it ata merge11:53
ssam2right11:53
Krini thought that during review it may be better to leave a trail of what has been done to fix and address concerns raised so far11:54
ssam2yes, not a bad plan11:55
ssam2i'll continue reviewing then :)11:55
* Krin realises he is likely going to have to shuffle out of the office today, starts actually looking at his rout out and if it is safe to do so11:56
pedroalvarezI'll record it a publish it :)11:58
* Krin whimpers11:59
Kinnisonpedroalvarez: I think you have to buy a boy lunch before you're allowed to do that kind of thing12:01
Krinin addition, i'm not a very good shuffler. so it would only be worth publishing for humor :P12:02
Krinand if you are looking through the branch ssam2, the most recent is baserock/mikesmith/zookeeper-for-review-v312:03
ssam2ah OK12:04
ssam2I have some comments by the way, you may yet be saved the shuffle ;)12:05
Krin:)12:05
ssam2oh, actually seems they are addressed in  baserock/mikesmith/zookeeper-for-review-v3 already12:05
Krin:(12:05
ssam2shuffle it is.12:06
pedroalvarezKrin: you should be happy!12:06
Krindamn my efficiancey12:06
petefothKrin: not to mention your efficiency ;)12:06
Krinwe dont speak of that petefoth :P12:07
Krinright, now comes the bit where i have to remember how to merge/squish12:09
petefoth`git rebase -i master` ?12:12
Krinyup :)12:12
jmacsIs there a list of environment variables available in chunks anywhere? $DESTDIR, etc12:16
jmacs?12:17
radiofreei think the morph log might print into about them?12:17
radiofreee.g http://fpaste.org/160909/18905125/12:18
ssam2I think morph.log is the best place to look12:18
ssam2'man morph' also has a list12:19
ssam2with documentation!12:19
ssam2but it may be out of date :)12:19
ssam2looks ok to me though12:19
jmacs"man morph" doesn't mention DESTDIR, so it can't be a complete list12:20
ssam2hmm, true. I *think* that's the only one missing12:20
radiofreePREFIX12:20
ssam2oh yeah, that too12:21
ssam2the two main ones !12:21
jmacsI was hoping for something like $VERSION, although I know we don't like Baserock version numbers12:25
ssam2what do you need it for ?12:25
ssam2I often miss version numbers.12:25
jmacsIt's one of the fields in /etc/lsb-release, which Chef checks to determine the distro type.12:26
jmacsI *may* be able to get away without it though.12:26
*** zoli_ [~zoli_@linaro/zoli] has quit [Remote host closed the connection]12:26
ssam2oh, so you want a way of getting the Baserock version into /etc/lsb-release ?12:26
jmacsYes12:26
ssam2getting the SHA1 of definitions in there would be cool, but it might need to be Morph itself that did that ...12:26
ssam2`morph deploy` already knows the SHA1 of definitions (and writes the output of `git describe` to /baserock/deployment.meta`) , but it doesn't pass that to configure extensions12:27
ssam2wouldn't be too hard to make `morph deploy` set something like DEFINITIONS_SHA1 in the environment for configure and write extension though ...12:28
jmacsI'm sure I can figure something out if it is necessary12:28
ssam2one of the many little tweaks I'd like to do would be make /etc/os-release contain more info than just "Baserock = Baserock (baserock)"12:29
Zara_haha12:30
Krindamnit history! let me re-write you!12:31
Krinshould this be being squished so that i shows all of it as one big commit before pushing the branch into master?12:32
ssam2I don't know12:32
ssam2in your case, I think so yes12:33
Krinwell that will make life easyer :)12:33
ssam2in general, you want each commit in a branch to be one change12:33
ssam2so if there are 4 commits that all say "make output blue", squash them all together12:33
ssam2if there are 4 that do different things, leave them separate12:33
ssam2maybe you want two, one that adds the strata and one that adds the example systems. But it's not super important here.12:34
jmacsCan I have a chunk which has no repo/ref? I want to run my lsb chunk which only has install-commands to write a file to /etc/lsb-release. Am I going about this the right way?12:35
ssam2you can't have a chunk with no repo/ref (although it might be a nice feature)12:36
ssam2you can use 'repo: baserock:baserock/definitions' or something as a hack12:36
ssam2I think configure-extension might be better for adding /etc/lsb-release12:36
jmacsCertainly possible to do it with a configure extension, but then it's specified in the system definition, rather than in chef.morph where I think it belongs12:37
ssam2I think in future we should add system-integration commands for strata12:38
ssam2maybe you could add it to 'integration-commands' for the chef chunk or something for now?12:38
ssam2(grep definitions.git for some examples of 'integration-commands')12:39
jmacsssam2: Will do, thanks12:39
ssam2sorry, the field is system-integration12:39
*** zoli_ [~zoli_@linaro/zoli] has joined #baserock12:46
*** Krin [~mikesmith@82-70-136-246.dsl.in-addr.zen.co.uk] has quit [Remote host closed the connection]13:54
*** franred [~franred@37.205.56.35] has joined #baserock14:18
franredhi folks, do we have Django lorried? I though that paulsher1ood sent a patch to create a chunck for it time ago, unless was just an attempt in a pastebin (I can't find the mail with the patch)14:19
pedroalvarezit is not lorried afaik14:20
pedroalvarezfranred: http://git.baserock.org/cgi-bin/cgit.cgi/baserock/baserock/definitions.git/log/?h=baserock/pedroalvarez/django14:21
pedroalvarezfranred: That was my attempt to create a chunk for it14:21
franredummm, ok, I need to create a stratum for it for horizon, because there are more django plugins/ packages needed for horizon14:23
franredso I will send the patch to create the stratum and the lorry soon14:23
franredpedroalvarez, ^^14:23
franredpedroalvarez, also thanks for the chunk morphology :)14:23
pedroalvarezit was really straightforward14:24
pedroalvarezI expected it to be more complex14:24
pedroalvarezif horizon needs django + django plugins, makes sense to me to create a django stratum to put everything14:25
ssam2yeah, a django stratum would be ace14:29
Kinnisondjango has a *lot* of optional dependencies.  Getting the balance right will be hard but useful14:34
* Kinnison likes django and would like to see it available for Baserock though14:34
CTtpollarddjango stratum +1 14:35
*** mdunford [~marcdunfo@82-70-136-246.dsl.in-addr.zen.co.uk] has quit [Ping timeout: 255 seconds]14:37
ssam2yeah, the strata model will be a pain for Django14:38
ssam2I guess most of the dependencies are probably small and quick to build though14:39
KinnisonAt least until we have conditional behaviour14:39
Kinnisonssam2: it's things like the pgsql dependencies are only useful if you have postgres (and only buildable with it too)14:39
ssam2ah, yes14:39
Kinnisonsqlite we can obviously build always given cpython build-deps on it14:40
Kinnisonbut there's also mariadb14:40
Kinnisonand a horde of others14:40
ssam2might be better for django-pgsql to go in the stratum with each app that needs it, in that case14:41
Kinnisonperhaps14:41
ssam2until we can think of a better way14:41
franredaham, I will have a look **carefully**14:44
*** franred [~franred@37.205.56.35] has quit [Quit: Leaving]14:47
pdarI was looking at updating the wiki to inform people unpetrify-ref is for. Would http://wiki.baserock.org/Morph/morphology-files/ be the right place to add a sentance about it?14:54
rdale'unpetrify-ref' has got to be the most obscure name for whatever it is it means15:00
*** mdunford [~marcdunfo@82-70-136-246.dsl.in-addr.zen.co.uk] has joined #baserock15:01
bashrcrdale: +115:02
pdarunpetrify isn't overly informative but ref seems relevant15:03
radiofreerdale: :)15:04
mwilliams_ctpdar: perhaps something should be added to http://wiki.baserock.org/contributing/ about standards for refs and "unpetrify-refs"15:04
rdaleeveryone else uses 'freeze' instead of 'petrify' afaik15:05
Kinnisonthe name 'unpetrify-ref' is hysterical raisins15:06
tlsamaybe 'frozen-ref' and 'thawed-ref' would be better15:21
paulsher1oodi think freeze is mainly a ruby term, not 'everyone' - and in that community freeze iirc means something else, not to do with refs?15:25
paulsher1oodhttp://wiki.dreamhost.com/Freezing_Gems15:25
*** zoli_ [~zoli_@linaro/zoli] has quit [Remote host closed the connection]15:28
rdaleinteresting - i don't think i found 'freeze' more familiar than 'petrifiy' because of my ruby background. i need to go and find some other uses of 'freeze' as a metaphor15:28
KinnisonReally it should be SHA1 and landing-ref15:29
Kinnisonand SHA1 should always be a SHA115:29
Kinnisonand then perhaps we can move it out of the primary definitions into a side file15:29
paulsher1oodKinnison: i've been experimenting with that side file idea. would you be averse to the SHA1 being the tree in all cases? is there some reason for it not to be?15:31
paulsher1ood(tree as opposed to commit... iirc there was some debate...)15:32
KinnisonYou can't check if a tree SHA is anchored15:33
Kinnisonso it's much less useful15:33
KinnisonI'd rather have the commit SHA, and a separate cache for the tree SHA15:33
rdalewhat is a 'side file'?15:34
Kinnisona file "on the side" i.e. not in the definitions you typically interact with, but still in the definitions repo15:34
* paulsher1ood googles 'git anchor' but can't discover what Kinnison means15:35
Kinnisonthe term 'anchor' relates to garbage collection15:36
Kinnisondoes that help?15:36
paulsher1oodi'm confused - maybe i'm misunderstanding the idea. assuming (in a world with side files) ref: is a branch/tag, and tree: is what that resolves to, how could a tree not be anchored?15:47
KinnisonMy point is, it's easy to ask git "is this SHA1 anchored in this ref"15:48
Kinnisonit's much harder to ask "is this tree anchored in this red"15:48
rdalewhat is 'red'?15:49
Kinnisonref15:49
* Kinnison mistyped15:49
rdaleah :)15:49
*** zoli_ [~zoli_@0x5e91887a.adsl.cybercity.dk] has joined #baserock15:56
*** zoli_ [~zoli_@0x5e91887a.adsl.cybercity.dk] has quit [Changing host]15:56
*** zoli_ [~zoli_@linaro/zoli] has joined #baserock15:56
pdarAnother question regarding the same wiki page. Is the 'morphology' field for strata ever used? I've never encountered it and I couldnt find an instance of it in strata/*15:57
pdarof my definition15:58
pdars15:58
radiofreeis that the same as the morph field?16:00
radiofreedocumentation should probably be added for "morph" filed, i think the morphology field is obsolete now (i seem to remember it being used when the name of the morph file didn't match the name of the chunck)16:02
radiofreewhen morph files were in the git repos and not definitions16:02
radiofreee.g chunk linux might use morphology: linux-foo-bar-arch.morph16:02
radiofreethough i may be completely wrong about that16:03
Kinnisonnaah, it was always morph:16:03
pdarhmm if its obselete I might remove that line then16:06
radiofreepdar: it's not obsolete, it should be "morph", but perhaps the documentation should be updated to reflect chunks-in-definitions16:07
pdarradiofree: ahh, "morph:" is used a whole bunch16:11
*** zoli_ [~zoli_@linaro/zoli] has quit [Remote host closed the connection]16:51
*** mariaderidder [~maria@82-70-136-246.dsl.in-addr.zen.co.uk] has quit [Quit: Ex-Chat]17:00
*** ssam2 [~ssam2@82-70-136-246.dsl.in-addr.zen.co.uk] has quit [Quit: Leaving]17:40
pedroalvarezgreat, took to me 15 minutes to perform an on-hardware deployment using morph :)17:48
pedroalvarezI'm going to publish a document with instructions about how to do it17:49
pedroalvarezBut before that I'll read it again, I'm sure I can improve it a bit17:49
persiaOn use of /etc/lsb-release in Baserock: I believe this file may have a version, but needs to be populated by the Baserock user, and that we probably don't want to have a default version upstream (because people won't remember to change it, whilst changing any number of sha1s).17:52
pedroalvarezthat makes sense to me17:53
persiaOn the use of "landing-ref" to replace "unpetrify-ref": This assumes that every ref used is anchored, which to my knowledge is the only place this restriction is imposed in Baserock.  Can we just drop it, and let users do whatever they want, anchoring or not anchoring as they find convenient (perhaps with a note that if they fail to anchor, and run `git gc`, they may lose the ref)17:54
persiaI expect people will typically want to use branch refs during development, switching to sha1s when they publish: having two fields makes this confusing.17:55
radiofreeit's a lot easier to see the branch/ref name when you're looking through morph files though17:56
persiaIn the case where someone wants to edit, they should create a new feature branch from the provided sha1, and land that in a place that depends on what they are doing (and may be entirely unrelated to the thoughts of the person who created the commit from which they are branching)17:56
persiaradiofree: Yes, but why do you care?17:56
radiofreerather than some sha that you then have to translate into "oh it's using version 217 of systemd"17:57
radiofreepersia: so you can quickly tell what version of something is being built?17:57
persiaThat trick happens to work for systemd, but not for many other things.17:57
persiaAs discussed many times previously, we need to put more effort into the documentation and usability of the tooling that currently does the translation from refs to versions.17:57
radiofreewell only because we have a load of baserock/morph things still there17:57
persiaAlso because lots of upstreams don't organise their repos that way.17:58
radiofreegenerally for new things that have been added the unpetrify-ref with be something like "v3.3.9" (procps-ng)17:58
persiaThere is *an entirely different* tool that is supposed to provide the version numbers.17:58
radiofreeqt5 for example17:58
persiaAnd we really ought use that, rather than trying to assert that there is a meaningful relation between refs and versions in repositories controlled by people not us.17:58
radiofreei can take a look at that startum and see instantly that it's version 5.3.217:58
radiofreewhat a pain in the arse it would be to have to look up 05670f586ffe05425b7542a27fcca31bddf231aa17:59
persiaSure, but if you are interested in versions, why don't you use the tool already written to provide version number information?17:59
radiofreei'd prefer keeping stratum files human-readable rather than have to use yet another tool/command to get that info17:59
radiofreewhy on earth would i want to do that?18:00
persiaI don't want the sha1s in the stratum files anyway :)18:00
radiofree"Oh i'm looking at this stratum file in vim, let me exit and run some other tool to find out what version of qt we're using"18:00
jmacsNote to self: adding a chunk to core causes a full rebuild18:00
persiajmacs: If you find that unpleasing, avoid adjusting build-essential :)18:00
pedroalvarezjmacs: at least you don't have to rebuild gcc18:01
jmacsTrue18:01
*** bashrc [~motters@82-70-136-246.dsl.in-addr.zen.co.uk] has quit [Quit: Lost terminal]18:01
*** petefoth [~petefoth@host-92-25-64-58.as13285.net] has quit [Quit: petefoth]18:03
jmacsHmm, but if I put my sgdisk chunk into the more appropriate place, ceph-service.morph, it says its build dependency (util-linux) isn't defined. Surely everything depends on core?18:04
pedroalvarezno, not everything18:04
persiaradiofree: Thinking about it, my desire to remove the refs from the stratum files entirely affects your described use case as much as my desire not to use two refs.18:04
persiaWhat is the use case that means you care which version of of something is described at the time you are editing the stratum file?18:05
radiofreepersonally i'd rather you remove the sha than the branch name :)18:05
persiaI want to remove all refs entirely.18:05
pedroalvarezjmacs: you can add an explicit build-depend entry in the stratum that you want to include sgdisk18:05
jmacsTried that - I added a build-depends for the stratum (either strata/core.morph or strata/core/util-linux.morph, neither works)18:07
pedroalvarezthen I don't expect it to work when adding it to core.morph.18:08
pedroalvarez:/18:08
jmacsIt is just because util-linux happens to be defined in core as well?18:08
pedroalvarezIf you add sgdisk to core, and put util-linux as a build dependency should be (almost) the same as adding sgdisk in a different stratum depending on core18:10
pedroalvarezjmacs: you can try to add it to core, though. It will rebuld everything but starting from sgdisk, so you can see if that works18:10
jmacsYep, I'm going to put it back in core and leave it to build overnight18:11
persiaAdding things like this to non-core ought be less complicated.18:11
persia(to avoid the overnight-build effect)18:11
pedroalvarezjmacs: if that works I think you are doing something wrong when trying to add core.morph as a build-dependency18:15
jmacsQuite possibly.18:16
pedroalvarezas an example: this is how I'd add core as a dependency in the installer-utils stratum http://paste.baserock.org/otosuwesim18:19
jmacsLooks like what I was doing18:20
pedroalvarezPublished: http://wiki.baserock.org/guides/deploy-to-hardware/18:47
pedroalvarezI'll try to improve it tomorrow a bit more18:47
*** zoli_ [~zoli_@0x5e91887a.adsl.cybercity.dk] has joined #baserock18:51
*** zoli_ [~zoli_@0x5e91887a.adsl.cybercity.dk] has quit [Changing host]18:51
*** zoli_ [~zoli_@linaro/zoli] has joined #baserock18:51
persiapedroalvarez: Your guide assumes Debian: is it possible to do this with only Baserock?19:10
*** rdale [~quassel@97.Red-81-35-54.dynamicIP.rima-tde.net] has quit [Ping timeout: 256 seconds]19:57
*** rdale [~quassel@77.Red-2-138-206.dynamicIP.rima-tde.net] has joined #baserock19:58
*** zoli_ [~zoli_@linaro/zoli] has quit [Remote host closed the connection]20:10
*** rdale_ [~quassel@147.Red-79-146-1.dynamicIP.rima-tde.net] has joined #baserock20:21
*** rdale [~quassel@77.Red-2-138-206.dynamicIP.rima-tde.net] has quit [Read error: Connection reset by peer]20:21
*** rdale [~quassel@206.red-80-26-163.adsl.dynamic.ccgg.telefonica.net] has joined #baserock20:23
*** rdale_ [~quassel@147.Red-79-146-1.dynamicIP.rima-tde.net] has quit [Read error: Connection reset by peer]20:23
*** zoli_ [~zoli_@0x5e91887a.adsl.cybercity.dk] has joined #baserock20:25
*** zoli_ [~zoli_@0x5e91887a.adsl.cybercity.dk] has quit [Changing host]20:25
*** zoli_ [~zoli_@linaro/zoli] has joined #baserock20:25
*** zoli_ [~zoli_@linaro/zoli] has quit [Remote host closed the connection]20:25
*** rdale_ [~quassel@11.Red-80-39-246.dynamicIP.rima-tde.net] has joined #baserock20:28
*** rdale__ [~quassel@80.30.109.144] has joined #baserock20:30
*** rdale [~quassel@206.red-80-26-163.adsl.dynamic.ccgg.telefonica.net] has quit [Ping timeout: 264 seconds]20:32
*** rdale_ [~quassel@11.Red-80-39-246.dynamicIP.rima-tde.net] has quit [Ping timeout: 245 seconds]20:33
*** rdale__ [~quassel@80.30.109.144] has quit [Ping timeout: 255 seconds]20:35
*** rdale [~quassel@30.Red-80-39-246.dynamicIP.rima-tde.net] has joined #baserock20:36
*** rdale [~quassel@30.Red-80-39-246.dynamicIP.rima-tde.net] has quit [Ping timeout: 265 seconds]20:41
*** rdale [~quassel@16.Red-88-21-208.staticIP.rima-tde.net] has joined #baserock20:46
*** rdale_ [~quassel@10.Red-80-39-246.dynamicIP.rima-tde.net] has joined #baserock20:48
*** rdale [~quassel@16.Red-88-21-208.staticIP.rima-tde.net] has quit [Ping timeout: 250 seconds]20:51
*** rdale [~quassel@102.red-80-26-167.adsl.dynamic.ccgg.telefonica.net] has joined #baserock20:51
*** rdale_ [~quassel@10.Red-80-39-246.dynamicIP.rima-tde.net] has quit [Ping timeout: 250 seconds]20:54

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