*** gtristan has quit IRC | 03:58 | |
*** gtristan has joined #baserock | 04:46 | |
*** franred has joined #baserock | 08:19 | |
*** bruce_ has joined #baserock | 08:25 | |
*** bashrc has joined #baserock | 09:01 | |
*** gtristan has quit IRC | 09:01 | |
*** jonathanmaw has joined #baserock | 09:23 | |
*** rdale has joined #baserock | 09:30 | |
*** tiagogomes_ has joined #baserock | 09:42 | |
*** ssam2 has joined #baserock | 10:05 | |
*** ChanServ sets mode: +v ssam2 | 10:05 | |
*** mwilliams_ct has joined #baserock | 10:05 | |
*** gtristan has joined #baserock | 10:06 | |
perryl | pedroalvarez: regarding the baserock docker image, how easy would it be to add dependencies to it, or for me to create one myself? | 10:06 |
---|---|---|
*** gtristan has joined #baserock | 10:06 | |
pedroalvarez | I tried yesterday to add sandboxlib but failed.. | 10:08 |
pedroalvarez | perryl: create one should be easy. You only need a baserock chroot ( that you can build using morph/ybd) and then use `docker import` | 10:09 |
pedroalvarez | some info about that in here: http://wiki.baserock.org/guides/docker/ | 10:09 |
perryl | argh, that doesn't sound promising! but i'll give it a go, see how i go on :) thanks! | 10:11 |
*** Lachlan1975 has joined #baserock | 10:11 | |
*** edcragg has joined #baserock | 10:12 | |
pedroalvarez | it should sound promising :/ | 10:13 |
pedroalvarez | let me know if you are stuck :) | 10:13 |
perryl | will do :) | 10:13 |
radiofree | yikes 16-01-08 14:14:09 [474/474/477] [TOTAL] Elapsed time 14:14:09 | 10:15 |
radiofree | for a gnome image | 10:15 |
rjek | Building on a RPi? :) | 10:15 |
pedroalvarez | rjek: ermm... on a Pi more than 8h just for gcc.. | 10:16 |
rjek | :) | 10:16 |
* rjek remembers when building a kernel on his main machine was an overnight job. | 10:17 | |
rjek | Protip: Don't run Linux on a 200MHz ARM as your main machine. | 10:17 |
radiofree | this was on a mustang | 10:17 |
rjek | Related, then | 10:18 |
*** richard_1aw is now known as richard_maw | 10:25 | |
*** ChanServ sets mode: +v richard_maw | 10:26 | |
nowster | pedroalvarez: pi or pi2? | 10:42 |
nowster | Edgerouter was about 3-4 hours for gcc | 10:43 |
rdale | x3 stages | 10:45 |
paulsherwood | 2 16-01-07 02:46:50 [956/956/962] [TOTAL] Elapsed time 02:46:43 (for ci.morph, mostly from scratch on AWS 36 core machine) | 10:52 |
paulsherwood | gnome sysem has more than doubled the wallclock time | 10:52 |
paulsherwood | (previously i was seeing 80 mins or so) | 10:52 |
pedroalvarez | nowster: Pi | 11:07 |
gtristan | hmmm, any pointers on how to install pyyaml, sandboxlib and jsonschema python libraries without pip ? preferably without requiring a python built with ssl support ? | 11:14 |
* gtristan was always annoyed about python modules acting so special, and not providing any 'make install' rules at the very least | 11:15 | |
radiofree | is pip the thing that allows "python setup.py install" to happen? | 11:16 |
ssam2 | gtristan: in a git checkout, just run 'python ./setup.py; sudo python ./setup.py install' | 11:17 |
gtristan | Not sure, no it provides 'pip install' | 11:17 |
ssam2 | that should work for any sane Python module | 11:17 |
gtristan | ssam2, thanks | 11:17 |
gtristan | hmmm, does PyYAML require libyaml ? | 11:20 |
* gtristan see: libyaml is not found or a compiler error: forcing --without-libyaml | 11:20 | |
gtristan | at 'python setup.py install' time... I guess if it installed, it just fell back to PyYAML without libyaml | 11:21 |
franred | gtristan, that is what we do in definitions with pyyaml :) | 11:22 |
franred | http://git.baserock.org/cgi-bin/cgit.cgi/baserock/baserock/definitions.git/tree/strata/python2-core/pyyaml.morph | 11:23 |
ssam2 | wow, that must be slow | 11:24 |
ssam2 | we should probably add libyaml and parse YAML with a C library rather than Python code! | 11:24 |
gtristan | ssam2, eh | 11:25 |
gtristan | ssam2, would shave off ~0.0001% of the build time, considering you parse definitions once and then run a build which potentially lasts hours :) | 11:25 |
* tiagogomes_ doesn't think it slow, after checking the time required to parse definitions | 11:26 | |
gtristan | but yeah, to be by the book :) | 11:26 |
ssam2 | yeah, i guess so | 11:28 |
ssam2 | don't ignore the impact of 'time to compute build graph' in a build tool though, for a long time in the history of Morph it took several minutes just to start building | 11:29 |
ssam2 | you can imagine how great it was waiting 3 minutes to find you had a syntax error or something | 11:29 |
gtristan | ssam2, after working with baserock for a while, 3 minutes to find out there was a mistake somewhere sounds like the least of my worries | 11:30 |
gtristan | even a great turn-around time :) | 11:30 |
gtristan | oh shit, I screwed up that configure time in build-essential... sigh, guess I'll get to test this tomorrow ;-P | 11:31 |
gtristan | s/time/line | 11:31 |
tiagogomes_ | ssam2 that's because morph was loading all morphs, and writing them back to disk. It should be pretty fast now | 11:40 |
ssam2 | there were various reasons! i'm talking about years ago | 11:48 |
ssam2 | like when Morph updated *every* git repo involved in the build each time you ran it | 11:49 |
gtristan | eek, after manually installing setuptools, I find that sandboxlib and jsonschema want to download stuff :-/ | 11:52 |
* gtristan wonders if it's worth going to the trouble of building openssl | 11:52 | |
ssam2 | what do they want to download? | 11:53 |
ssam2 | you mean setuptools is trying to fetch their dependencies? | 11:53 |
gtristan | yeah | 11:54 |
gtristan | jsonschema wants vcversioner | 11:54 |
gtristan | sandboxlib wants pbr | 11:54 |
ssam2 | ah, yes it will need pbr | 11:54 |
* gtristan adds those and hopes to not discover too many others | 11:54 | |
* gtristan thinks if he takes the jsonschema version from definition it will not require that other thing | 11:57 | |
gtristan | weird, pbr wants 'pip' | 11:59 |
gtristan | ssam2, is that what python-distutils does ? 'python setup.py install' ? | 11:59 |
pedroalvarez | gtristan: mainly | 12:00 |
pedroalvarez | gtristan: see DEFAULTS | 12:00 |
pedroalvarez | also, pbr is in strata/python2-core.morph | 12:01 |
gtristan | pedroalvarez, I see | 12:02 |
gtristan | yeah, I took the pbr referred to from that file | 12:02 |
gtristan | exact SHA1 | 12:02 |
* gtristan gets this: | 12:02 | |
gtristan | running install | 12:02 |
gtristan | /home/INSTALL/bin/python: No module named pip | 12:02 |
gtristan | error: ['/home/INSTALL/bin/python', u'-m', u'pip.__init__', u'install', u'pip'] returned 1 | 12:02 |
gtristan | oh yeah | 12:03 |
gtristan | http://git.baserock.org/cgi-bin/cgit.cgi/delta/pbr.git/tree/requirements.txt?id=0.10.7 | 12:04 |
gtristan | how is that possible ? do we have pip in definitions ? | 12:06 |
ssam2 | i think it's now bundled with Python | 12:06 |
ssam2 | it used to be separate | 12:06 |
ssam2 | unfortunate that pbr has tied things in knots. It exists to simplify the whole setuptools/distutils/distribute/setup.py mess :/ | 12:06 |
gtristan | ssam2, the really annoying thing is... I'm sure all this stuff is for, is to end up doing a cp ${script} -> ${prefix}/lib/${pythonversion}/modules... or similar | 12:09 |
gtristan | could be a few lines of makefile :-/ | 12:09 |
ssam2 | in this case, yeah | 12:10 |
gtristan | ok... install pip, so it can sit there without https support and do nothing but satisfy a dependency... | 12:10 |
ssam2 | if you prefer, add a makefile to sandboxlib | 12:11 |
gtristan | sandboxlib installed fine | 12:13 |
gtristan | it's pbr | 12:13 |
* gtristan downloading pip from github | 12:13 | |
gtristan | which *wants* to do some magick 'get-pip.py' as the regular install path, which wont work from my current vm | 12:14 |
gtristan | but should have a setup.py as well I presume | 12:14 |
ssam2 | yeah | 12:15 |
ssam2 | sandboxlib only depends on pbr for its setup.py file | 12:15 |
ssam2 | pbr is a tool to make writing setup.py a bit less crazy (you write a setup.cfg instead, so the package info is data rather than code) | 12:15 |
gtristan | nice | 12:18 |
gtristan | that worked | 12:18 |
gtristan | is 'requests' supposed to be builtin to python ? | 12:24 |
franred | gtristan, no, AFAIK | 12:25 |
* gtristan finds https://pypi.python.org/pypi/requests | 12:25 | |
* gtristan files minor bug | 12:25 | |
gtristan | umm, I'm not sure, does it's existence here: https://pypi.python.org/pypi/requests... mean that it is indeed builtin to python ? | 12:29 |
gtristan | clicking the download link oddly brings me to a page for downloading python | 12:29 |
gtristan | oh would you look at that | 12:30 |
gtristan | the page says if you want to install, use pip install | 12:30 |
gtristan | hahaha | 12:30 |
* gtristan finds it is actually maintained here: https://github.com/kennethreitz/requests.git | 12:30 | |
gtristan | Have a clue what could be causing this: http://paste.baserock.org/vomacasese | 12:53 |
gtristan | thats from running: ../ybd/ybd.py strata/build-essential.morph armv5l | 12:54 |
gtristan | fwiw, on this box; python -c "import sandboxlib" | 12:54 |
gtristan | says nothing, and echo $? reports 0 exist status | 12:55 |
gtristan | as opposed to python -c "import ridethepony"; which reports an error and complains about it's inability to ride ponies | 12:55 |
pedroalvarez | that's odd | 12:56 |
gtristan | yeah :-/ | 12:56 |
* gtristan thinks he installed everything alright | 12:56 | |
gtristan | I admit I did not pass the --prefix argument | 12:56 |
gtristan | but since python is installed under /home/INSTALL... python setup.py install seems to have been correctly shoving everything under there too | 12:57 |
ssam2 | it does that, yeah | 13:05 |
ssam2 | one thing it can do better than a Makefile :-) | 13:06 |
gtristan | ssam2, pkg-config macros (and other m4 bits) help with that, but yes it's much the same thing :) | 13:07 |
gtristan | ok I see, sort of | 13:21 |
gtristan | I dont have sandboxlib in /home/INSTALL/lib/python2.7/site-packages | 13:21 |
gtristan | and there is some warning when building/installing it | 13:21 |
gtristan | for some reason though; python -c "import sandboxlib" incorrectly seems to succeed | 13:22 |
paulsherwood | lc - please raise the ybd problem on #baserock | 13:22 |
paulsherwood | oops, wrong window | 13:22 |
SotK | gtristan: which directory are you running `python -c "import sandboxlib"` in? | 13:23 |
gtristan | SotK, that makes perfect sense ! | 13:24 |
gtristan | I hadnt thought of that :) | 13:24 |
gtristan | indeed, it only works from the sandboxlib directory, hadn't noticed that | 13:24 |
SotK | do you have to actually install sandboxlib for what you're trying to do or can you just add the git checkout to your PYTHONPATH when running ybd? | 13:25 |
gtristan | I only care about running ybd right now | 13:26 |
gtristan | everything is done completely wrong, the point is just to try it out | 13:26 |
* gtristan tries PYTHONPATH trick | 13:26 | |
gtristan | works ! | 13:27 |
gtristan | SotK, thanks :) | 13:27 |
SotK | good :) | 13:28 |
gtristan | question; I'm in an armv5l VM, but is that a valid arch name for definitions ? | 13:30 |
*** rdale_ct has joined #baserock | 13:30 | |
gtristan | or should it rather be armv5lhf ? | 13:30 |
jjardon | gtristan: for the future, probably it would help if you create a ybd stratum with all the dependencies ybd needs | 13:31 |
jjardon | gtristan: nope, I dont think any armv5 supports hard float | 13:32 |
*** rdale_ct_ has joined #baserock | 13:32 | |
SotK | gtristan: armv5l is correct I think | 13:32 |
gtristan | ok thanks | 13:33 |
*** rdale has quit IRC | 13:34 | |
gtristan | jjardon, we'll see where we're going, honestly I think one of 2 things; A.) this experiment works out, and the aboriginal bootstrap image contains exactly enough tooling to get the build started and nothing more... B.) YBD anyway documents it's dependencies, and we try not to presume anything about the system which is building (like if its baserock or debian or what) | 13:35 |
*** rdale_ct has quit IRC | 13:35 | |
*** rdale has joined #baserock | 13:36 | |
gtristan | jjardon, one thing we've learned, is that the idea that one can assume that what is installed on the machine is correctly what is needed to build, just because it is another baserock build image, is a false presumption | 13:36 |
gtristan | so if you can build one set of definitions on one baserock system which was built with a drastically different set of definitions, you can also do it from a debian system or other | 13:38 |
ssam2 | I don't think we ever expected that | 13:38 |
ssam2 | we assumed that if it was a specific release of systems/build-system-xxx.morph then you could assume that it contains the right stuff | 13:38 |
*** rdale_ct has joined #baserock | 13:38 | |
*** rdale_ct_ has quit IRC | 13:39 | |
gtristan | ssam2, sure, this doesnt exactly work in the current state either | 13:40 |
gtristan | i.e. host tooling such as syslinux/btrfs, in any case, clearly that loop needs to be closed | 13:40 |
*** rdale has quit IRC | 13:42 | |
gtristan | well, ybd clearly runs... and binutils is building, but... with the chroot sandboxing and all, it is not using distcc | 13:42 |
gtristan | either I will "build the whole thing" at turtle speed, or rip apart definitions and ybd, trying a hack | 13:43 |
gtristan | or more likely, I will do both :) | 13:43 |
jjardon | ok to lorry qtdeclarative-testsuites? https://gerrit.baserock.org/#/c/1728/ | 13:43 |
*** rdale has joined #baserock | 13:43 | |
*** rdale_ct has quit IRC | 13:46 | |
ssam2 | gtristan: once upon a time Morph supported building with distcc, inside a chroot | 13:52 |
ssam2 | I forgot how that worked or if the code still exists | 13:52 |
gtristan | oh I'm sure I can rig it up :) | 13:53 |
gtristan | thing is, I will also gut build-essential for this | 13:53 |
gtristan | at least some of it, at least gcc | 13:54 |
gtristan | and will have to expose the outer gcc to the inner build env | 13:54 |
*** mwilliams_ct has left #baserock | 13:56 | |
SotK | does that not have reproducibility implications? (or am I misunderstanding?) | 13:56 |
gtristan | SotK, not really, you can still choose what compiler you want to use, except you use a cross compiler on the host instead of the compiler built on the target | 13:59 |
gtristan | SotK, so essentially, it could end up that "building the bootstrap image & compiler" for a given arch, becomes a separate activity from "building everything else on that arch" | 14:00 |
gtristan | of course, there is always some chance that you have dusty ports, and they effect the bits traveling over distcc ;-) | 14:02 |
*** tiagogomes_ has quit IRC | 14:02 | |
radiofree | pedroalvarez: do you think it's safe to make the assumption that if someone has defined a /boot than that's where the bootloader config should go | 14:02 |
*** nowster has quit IRC | 14:02 | |
gtristan | SotK, actually there are dozens of ways to leverage that cross setup, one of which I've been thinking, is to start a VM instance for the build of each chunk (or have some VMs on standby), which could allow parallelism of orthogonal builds - while running YBD on the host side to launch the builds | 14:05 |
*** edcragg has quit IRC | 14:05 | |
gtristan | but first, I'll try to just get through a build hehe | 14:06 |
*** edcragg has joined #baserock | 14:07 | |
SotK | I see, I guess I misunderstood you a bit then, I haven't thought about the cross-bootstrap stuff for about a year :) | 14:08 |
gtristan | ah, first stumbling block, ybd doesnt like that I have everything in a non-standard location (I built all the additional tooling into /home/INSTALL prefix) | 14:08 |
gtristan | ok, 11pm, but made progress :) | 14:08 |
pedroalvarez | radiofree: hm.. not sure :/ | 14:12 |
pedroalvarez | but is not a really ugly workaround, if not a real solution | 14:13 |
pedroalvarez | can't decide about what;s the best solution for all of this.. | 14:14 |
paulsherwood | gtristan: set base: to that dir? | 14:14 |
pedroalvarez | radiofree: then, upgrades will use whatever has been definied in /boot ? that would be good too | 14:14 |
pedroalvarez | (just a thought) | 14:15 |
*** tiagogomes_ has joined #baserock | 14:16 | |
radiofree | pedroalvarez: as long as your set BOOT_PARTITION system-version-manager will use the correct partition | 14:17 |
radiofree | (i.e /boot) | 14:17 |
radiofree | i have to install the btrfs layout on the /boot parition though + write extlinux.conf there | 14:17 |
radiofree | assuming "if /boot, do it there" seems to be the simplest way | 14:18 |
pedroalvarez | I'd like to avoid the BOOT_PARTITION magic... "if /boot, write the magic BOOT_PARTITION variable somewhere" | 14:19 |
pedroalvarez | but I agree this is another issue | 14:19 |
radiofree | hmm | 14:19 |
pedroalvarez | it looks weird that you are specifing a partitioning layout, and **also** seting ROOT_DEVICE and BOOT_PARTITION (if those are the names) in the cluster | 14:20 |
radiofree | still need BOOT_PARTITION | 14:20 |
radiofree | you might have no partition layout and flash the image to /dev/sda (or similar) and BOOT_PARTITION might be on the internal emmc | 14:21 |
radiofree | e.g BOOT_PARTITION /dev/mmcblk0p1 ROOT_PARTITION /dev/sda | 14:21 |
radiofree | that's exactly what i do with my jetson ( boot on emmc, / on ssd) | 14:22 |
* radiofree got sick of running out of space for upgrades | 14:23 | |
gtristan | paulsherwood, not sure I have enough in /home/INSTALL, right now my PATH is /home/INSTALL/bin:$PATH, similar for LD_LIBRARY_PATH, PKG_CONFIG_PATH and ACLOCAL_FLAGS... but it's far from insurmountable | 14:23 |
pedroalvarez | and in that case, I don't think makes sense to deploy the image using partitioning.. | 14:23 |
gtristan | paulsherwood, thanks for pointing me to 'base', it will surely lead me in the right direction :) | 14:23 |
radiofree | pedroalvarez: no it doesn't, and you wouldn't | 14:23 |
radiofree | i see what you mean | 14:24 |
pedroalvarez | good :) | 14:24 |
radiofree | this is beyond the scope of this work though, since you'd have to modify x86 systems as well (i.e ones that don't use partitioning) | 14:25 |
pedroalvarez | in those cases that you need a flashing script, the flashing script will take care of generating the runes needed for upgrades (in this case the BOOT_PARTITION var) | 14:25 |
radiofree | maybe.. | 14:25 |
radiofree | well i suppose you could just hack system-version-manager to check /boot *or* / of the btfs partition | 14:25 |
pedroalvarez | radiofree: sure! I just never found anyone who wanted to talk about this :) | 14:25 |
radiofree | ok, so if you have /boot partitioned, you don't need BOOT_PARTITION, and relegate BOOT_PARTITION being set (since system-version-manager will need to know about it eventually) to the weird cases like mine | 14:27 |
radiofree | can you define fstab entires in the cluster file? | 14:27 |
pedroalvarez | yup, although I wonder if in your case isn't possible to guess where is /boot | 14:28 |
pedroalvarez | yes | 14:28 |
radiofree | you could also achieve BOOT_PARTITION that way... (i.e mount it to /boot) | 14:28 |
pedroalvarez | oh, so in your case you dont have /boot mounted at all, I see | 14:28 |
radiofree | no, /boot is just some folder on / | 14:28 |
radiofree | system-version-manager mounts BOOT_PARTITION to /tmp/foo/ and works there | 14:29 |
radiofree | ok, i'll get this done, and then take a look at deprecating BOOT_PARTITION | 14:31 |
radiofree | (though i'm not sure doing FSTAB_....: /dev/mmcblk0p1 loads of foo is better...) | 14:32 |
pedroalvarez | forget about that for now, until we think about the right solution | 14:37 |
*** gtristan has quit IRC | 14:48 | |
*** gtristan has joined #baserock | 14:58 | |
*** nowster has joined #baserock | 15:00 | |
radiofree | is there something i have to do to stop ybd trying to redownload the cache every time? | 16:08 |
radiofree | every time i use it on a cluster/system if goes through "try downloading foo.cache" | 16:08 |
radiofree | even though i've already build it | 16:08 |
radiofree | s/build/built | 16:09 |
radiofree | i'll restart the system... | 16:09 |
pedroalvarez | just use morph | 16:09 |
radiofree | well ybd was already on here and working, i cba to use morph | 16:10 |
*** paulw has joined #baserock | 16:11 | |
paulsherwood | radiofree: could you paste some of that output? | 16:11 |
paulsherwood | (ideally from the top) | 16:12 |
*** paulw has quit IRC | 16:12 | |
radiofree | paulsherwood: http://fpaste.org/308668/14522696/ | 16:13 |
radiofree | i'm running this in a chroot btw | 16:13 |
radiofree | `python /src/ybd/ybd systems/build-system-armv7lhf-jetson.morph armv7lhf` | 16:14 |
paulsherwood | 16-01-08 00:00:12 [0/1/1] [stage1-binutils] Cache_key is stage1-binutils.efd9f69dc47162aabb5fc19eaafe97f2a83dc1e8910e7fafe6904ebfc66ef54a | 16:14 |
paulsherwood | that means it hasn't even found the first artifact locally | 16:15 |
radiofree | i see | 16:15 |
paulsherwood | you say you've built this before? | 16:15 |
radiofree | yep | 16:15 |
paulsherwood | where is your artifact directory? | 16:16 |
radiofree | /root/ybd/artifacts | 16:16 |
radiofree | it seems to be populating it now | 16:16 |
radiofree | (it looks relatively empty) | 16:16 |
radiofree | not sure what went wrong.... | 16:17 |
paulsherwood | yes, but it's *repopulating*, which seems odd if you already built. | 16:17 |
paulsherwood | i wonder if you've changed/added a conf file? | 16:17 |
radiofree | i don't think so | 16:17 |
paulsherwood | git status on the ybd directory? | 16:18 |
paulsherwood | (and on the definitions)? | 16:18 |
radiofree | modified: ybd/config/ybd.conf | 16:19 |
radiofree | however that was 2 days ago | 16:19 |
radiofree | definitions is modified, i added somethings to the jetson-bsp | 16:20 |
radiofree | hmm interestingly now something failed to build >.< | 16:21 |
radiofree | (the thing i added to the bsp) | 16:21 |
paulsherwood | well that's progress, i guess :? | 16:22 |
radiofree | yes, at least it isn't attempting to download everything again | 16:22 |
radiofree | "autom4te: need GNU m4 1.4 or later: /usr/bin/m4" hmm | 16:23 |
radiofree | well i don't care about that for now anyway, i can continue | 16:24 |
paulsherwood | it should never download what is already there | 16:24 |
paulsherwood | ack | 16:24 |
pedroalvarez | maybe is ybd auto-removing things? | 16:24 |
pedroalvarez | (just a thought) | 16:24 |
paulsherwood | only if it's short of space... and it would say so | 16:25 |
paulsherwood | https://github.com/devcurmudgeon/ybd/blob/master/ybd/app.py#L200 | 16:26 |
radiofree | could be short of space? | 16:26 |
radiofree | i only have 9G | 16:26 |
paulsherwood | yes, it will start culling oldest artifacts | 16:26 |
paulsherwood | you could set min-gigabytes to less than 10 if your target is small | 16:26 |
*** bruce_ has quit IRC | 16:31 | |
*** tiagogomes_ has quit IRC | 16:32 | |
*** franred has quit IRC | 16:32 | |
*** jonathanmaw has quit IRC | 16:32 | |
*** bashrc has quit IRC | 16:32 | |
*** CTtpollard has quit IRC | 16:32 | |
*** faybrocklebank has quit IRC | 16:32 | |
*** nowster has quit IRC | 16:32 | |
*** Lachlan1975 has quit IRC | 16:32 | |
*** ssam2 has quit IRC | 16:32 | |
*** edcragg has quit IRC | 16:32 | |
*** faybrocklebank has joined #baserock | 16:32 | |
*** Lachlan1975 has joined #baserock | 16:32 | |
*** ssam2 has joined #baserock | 16:32 | |
*** ChanServ sets mode: +v ssam2 | 16:32 | |
*** tiagogomes__ has joined #baserock | 16:32 | |
*** CTtpollard has joined #baserock | 16:32 | |
*** edcragg has joined #baserock | 16:32 | |
*** nowster has joined #baserock | 16:32 | |
*** jonathanmaw has joined #baserock | 16:32 | |
*** bashrc has joined #baserock | 16:33 | |
*** CTtpollard has quit IRC | 16:37 | |
*** franred has joined #baserock | 17:21 | |
*** jonathanmaw has quit IRC | 17:23 | |
*** franred has quit IRC | 17:23 | |
*** benbrown1 has joined #baserock | 17:29 | |
*** benbrown_ has quit IRC | 17:30 | |
*** nowster has quit IRC | 17:56 | |
*** Lachlan1975 has quit IRC | 17:57 | |
*** bashrc has quit IRC | 17:58 | |
*** benbrown1 is now known as benbrown_ | 18:01 | |
*** tiagogomes__ has quit IRC | 18:18 | |
*** edcragg has quit IRC | 18:24 | |
*** ssam2 has quit IRC | 18:57 | |
*** rdale has quit IRC | 20:48 |
Generated by irclog2html.py 2.15.3 by Marius Gedminas - find it at mg.pov.lt!