| *** flatmush [~flatmush@82-70-136-246.dsl.in-addr.zen.co.uk] has joined #baserock | 00:00 | |
| *** flatmush [~flatmush@82-70-136-246.dsl.in-addr.zen.co.uk] has quit [Ping timeout: 255 seconds] | 01:15 | |
| *** flatmush [~flatmush@82-70-136-246.dsl.in-addr.zen.co.uk] has joined #baserock | 01:17 | |
| *** JPohlmann [~jannis@xfce/core-developer/JPohlmann] has quit [Ping timeout: 240 seconds] | 02:12 | |
| *** JPohlmann [~jannis@xfce/core-developer/JPohlmann] has joined #baserock | 02:13 | |
| *** vmeson [~quassel@128.224.252.2] has quit [Ping timeout: 250 seconds] | 05:23 | |
| *** vmeson [~quassel@128.224.252.2] has joined #baserock | 05:25 | |
| paulsherwood | has anyone here managed to self-upgrade a jetson? | 07:00 |
|---|---|---|
| *** fay_ [~fay@82-70-136-246.dsl.in-addr.zen.co.uk] has joined #baserock | 07:39 | |
| *** franred [~franred@82-70-136-246.dsl.in-addr.zen.co.uk] has joined #baserock | 07:48 | |
| SotK | paulsherwood: I have | 07:50 |
| SotK | what problem are you having? | 07:50 |
| paulsherwood | http://fpaste.org/129201/12305140/ | 07:51 |
| paulsherwood | i feel like i'm in uncharted territory... looks like james' updates are pre-c.i.d | 07:52 |
| SotK | that is strange, and I don't know enough about the inner workings of the upgrade process to help you I feel... | 07:55 |
| SotK | I upgraded with a system in the baserock/tegra branch (but rebased to use chunks in definitions) and didn't see anything like that | 07:56 |
| paulsherwood | ok let me check - i may ask you again :) | 07:56 |
| pedroalvarez | good morning! | 08:10 |
| pedroalvarez | the upgrade deployment is expecting a "tegra124-jetson-tk1.dtb" in the rootfs of the system that you are deploying | 08:13 |
| tlsa_ is now known as tlsa | 08:14 | |
| pedroalvarez | This is specific of a jetson board upgrade, so I don't have any idea of why it should be there, and why is not there | 08:14 |
| *** jonathanmaw [~jonathanm@82-70-136-246.dsl.in-addr.zen.co.uk] has joined #baserock | 08:19 | |
| persia | To me, that looks like the device tree data file, although I don't know why it might be absent. | 08:19 |
| robtaylo1 is now known as robtaylor | 08:23 | |
| SotK | I want to build a Baserock system with Qt in it, but my devel system doesn't have enough RAM | 08:44 |
| persia | Add swap | 08:45 |
| persia | It will be slow and painful, but it should build. | 08:45 |
| SotK | slow and painful is better than not at all I guess | 08:46 |
| * persia has built boost with 512M RAM and koffice with 256M RAM, both of which required patience | 08:46 | |
| pedroalvarez | in some chunks I found that using "max-jobs: 1" helped with small RAM | 08:47 |
| persia | If you can cause the build to happen in an environment in which you don't need to do anything until tomorrow, that helps. | 08:47 |
| liw-orc | swap may save you, unless the linker needs more memory than your address space allows | 08:47 |
| persia | liw-orc: Do we have any chunks that can't build in 32-bit 2G/2G? | 08:47 |
| robtaylor | (only case i've ever heard of needing that is building chromium with full LTO) | 08:48 |
| liw-orc | I was told in 2011 by people who've tried it that 32-bit ARM didn't have the address space to link then-modern versions of OO.o and LibreOffice; I haven't investigated in detail | 08:48 |
| persia | Hmm. I'd believe that. | 08:49 |
| robtaylor | I suspect again, linking them with LTO | 08:49 |
| persia | Mind you, that's a kernel option: one can use a 3G/1G split in 32-bit to get a bit more space. | 08:49 |
| robtaylor | if you really had to do it, you could farm it out to a cross-linker on a 64bit system | 08:50 |
| persia | let's avoid that: we don't have such tooling already in place. | 08:50 |
| persia | (and any upstream that needs more than 3G to link should be admonished) | 08:51 |
| robtaylor | I don't think anyone needs to do this at this moment in time | 08:51 |
| robtaylor | if you do hit a problem, just disable LTO | 08:51 |
| *** jonathanmaw [~jonathanm@82-70-136-246.dsl.in-addr.zen.co.uk] has quit [Ping timeout: 240 seconds] | 08:58 | |
| paulsherwood | SotK: maxjobs? | 09:02 |
| *** jonathanmaw [~jonathanm@82-70-136-246.dsl.in-addr.zen.co.uk] has joined #baserock | 09:16 | |
| *** ssam2 [~ssam2@host86-159-251-35.range86-159.btcentralplus.com] has joined #baserock | 09:23 | |
| paulsherwood | SotK: did you succeed? | 11:09 |
| radiofree | paulsherwood: the patch to your device tree is wrong | 11:24 |
| radiofree | s/patch/path | 11:25 |
| radiofree | solution: use the correct path (don't have a leading /) | 11:26 |
| paulsherwood | ah! | 11:26 |
| radiofree | so boot/tegra-foo.dtb not /boot/tegra-foo.dtb | 11:26 |
| paulsherwood | thank you! i'll try that when i'm next near to the jetson | 11:27 |
| radiofree | max-jobs:1 when building qt will take ages btw | 11:29 |
| persia | Taking ages is better than not completing. | 11:39 |
| pedroalvarez | radiofree: define ages :) | 11:41 |
| radiofree | which version of qt? | 11:42 |
| SotK | paulsherwood: no, gstreamer is failing to build :( | 11:42 |
| SotK | radiofree: qt5 | 11:43 |
| radiofree | SotK: i sent patches for that ages ago | 11:43 |
| radiofree | "[PATCH 0/7] Fix gstreamer 0.10 build with newer glibs" | 11:43 |
| pedroalvarez | yeah, they were merged, and I built it last week to do a Genivi release | 11:43 |
| SotK | hm | 11:44 |
| * SotK investigates | 11:44 | |
| radiofree | pedroalvarez: i don't see it in http://git.baserock.org/cgi-bin/cgit.cgi/delta/gstreamer.git/log/?h=baserock/morph/0.10 | 11:44 |
| radiofree | a genivi release doesn't have gstreamer 0.10? | 11:45 |
| pedroalvarez | hmmm | 11:45 |
| SotK | there is only 1 +1 on the patch on the ML | 11:45 |
| pedroalvarez | radiofree: you are right, Genivi doesnt have that version of gstreamer | 11:47 |
| pedroalvarez | I assumed they were merged, because Genivi stop failing building | 11:47 |
| SotK | radiofree: using the SHA from your patch series it built fine, thanks | 11:53 |
| radiofree | i think you'll be looking at 3-5 hours to build qtbase with maxjobs 1 | 12:03 |
| radiofree | then of course there's qtwebkit... | 12:03 |
| persia | 3-5 hours isn't so bad. One gets to work on the patches twice a day. | 12:05 |
| liw-orc | persia, I don't know if we have anything that doesn't build in 32-bit 2G/2G; I assume we don't, or we would've noticed | 12:06 |
| radiofree | qt5 is one of the things that would really benefit from using distcc | 12:08 |
| persia | As long as the address space split is identical for all 32-architectures, it's usually safe. It's when folk change X86_32 to 3G/1G and not the other 32-bit architectures, and continue to depend on x86_32 as a canary that trouble occurs. | 12:08 |
| *** thecorconian [~thecorcon@eccvpn1.ford.com] has joined #baserock | 12:17 | |
| *** fay_ [~fay@82-70-136-246.dsl.in-addr.zen.co.uk] has quit [Ping timeout: 260 seconds] | 13:02 | |
| *** fay_ [~fay@82-70-136-246.dsl.in-addr.zen.co.uk] has joined #baserock | 13:51 | |
| *** genii [~quassel@ubuntu/member/genii] has joined #baserock | 13:59 | |
| pedroalvarez | hm... when configuring a distbuild worker we do this: | 14:20 |
| pedroalvarez | ssh-keyscan -t dsa,ecdsa,rsa "$TROVE_HOST" >> "$1/root/.ssh/known_hosts" | 14:20 |
| pedroalvarez | I'm trying to figure out how can I do that command idempotent | 14:21 |
| richard_maw | if your known_hosts is encrypted, I'm not sure, but otherwise you could grep known_hosts for $TROVE_HOST | 14:21 |
| liw-orc | that file shouldn't be going into root's home directory, btw; it should be going to /etc/ssh | 14:22 |
| pedroalvarez | liw-orc: I can change that | 14:23 |
| pedroalvarez | I found `ssh-keygen -H -FHOSNTAME` useful to check if a host is defined in known_hosts | 14:24 |
| persia | The relevant user on the trove should probably have an ssh configuration to not encrypt known_hosts, but you can use `ssh-keygen -r` to find out if it is already there if it is encrypted | 14:24 |
| liw-orc | I think it should be /etc/ssh/ssh_known_hosts (under $1 obviously) | 14:24 |
| persia | (or even if it isn't) | 14:24 |
| pedroalvarez | but, what about if the host has changed? | 14:24 |
| persia | -H doesn't do that according to my docs. | 14:24 |
| persia | If you want to replace unconditionally, use -R | 14:24 |
| pedroalvarez | persia: -H -F HOSTNAME, sorry | 14:25 |
| liw-orc | pedroalvarez, btw, what do you mean by idempotent? this is being run at configuration extension time, and not multiple times | 14:25 |
| pedroalvarez | liw-orc: is because I'm moving it out from the configuration extension | 14:26 |
| liw-orc | pedroalvarez, and it might get run multiple times? | 14:26 |
| pedroalvarez | every boot | 14:26 |
| persia | pedroalvarez: I'm unsure about -H-F: use -r to check if it is there, or use -R to replace it (and -R will add it if it isn't present) | 14:27 |
| persia | *every boot* Why? | 14:27 |
| liw-orc | pedroalvarez, do you need to notice if the server host key has changed? if so, maybe it'd be better to just have the client not care about host key checking | 14:27 |
| persia | That's not safe. | 14:28 |
| pedroalvarez | I think we care | 14:28 |
| persia | But resetting it every boot is just as unsafe as not checking | 14:28 |
| liw-orc | persia, yeah, that was my point | 14:28 |
| pedroalvarez | And I agree with you both | 14:28 |
| persia | So don't do this then :) | 14:28 |
| pedroalvarez | just check if the host has already an entry in the known_hosts file, and not update it | 14:29 |
| liw-orc | pedroalvarez, will there ever be other hosts in that known hosts file? | 14:29 |
| pedroalvarez | liw-orc: the one that is in the /root/.ssh/, yes | 14:31 |
| pedroalvarez | I don't know about the /etc/ssh one | 14:31 |
| persia | When is the user expected to provide TROVE_HOST? Is this deploy time or instantiation time? | 14:31 |
| liw-orc | go with the assumption that /etc/ssh/known_hosts only ever has the Trove's host key, and only generate if the file doesn't exist yet | 14:31 |
| pedroalvarez | right | 14:32 |
| * persia is still worried with that solution that spoofed DNS can provide the wrong value. | 14:33 | |
| pedroalvarez | Just to let you know what I'm trying to achieve: I'm trying to do a generic distbuild-node deployment. IMO this is needed to have Mason in OpenStack | 14:33 |
| richard_maw | is it feasible to generate host and user keys in advance, and pass them to cloud-init for the trove and the distbuild nodes? | 14:35 |
| paulsherwood | quick question - if i want to track down the GENIVI I-0.1 release, what do i look for? | 14:35 |
| persia | richard_maw: Yes, but that means passing private keys over the wire. | 14:35 |
| paulsherwood | i see no tag | 14:35 |
| pedroalvarez | paulsherwood: seems I missed that step from our release process | 14:36 |
| pedroalvarez | paulsherwood: there is a branch, I will do the tag now | 14:37 |
| paulsherwood | tvm | 14:37 |
| pedroalvarez | paulsherwood: tag GENIVI-I0.1 | 14:42 |
| paulsherwood | great, thank you | 14:43 |
| ssam2 | franred: regarding your cpython patch, merge and fix however pleases you. once we have an actual policy we can clean up the refs and tags and unpetrify-refs to be consistent :) | 14:51 |
| persia | Well, either that, or we remove the unpetrify-ref entirely, if it comes to that (which I've seen proposed before). | 14:52 |
| ssam2 | if fran wants to remove it, he may | 14:55 |
| persia | Is it safe to do so? I thought morph still complained if it was absent. | 14:56 |
| radiofree | i usually don't use unpetrify-refs (just ref: branchname) and i've never had problems | 14:58 |
| persia | Oh, cool. | 15:00 |
| richard_maw | ref: branchname means that if someone else moves those refs you have to build their changes though | 15:00 |
| franred | ssam2, persia, Im going to merge the patch as it was reviewed. I leave the unpetrify-refs discussion for the mailing list | 15:00 |
| persia | Seems reasonable | 15:00 |
| genii | Hm, 50 Commandments. Even God only had 10 | 15:10 |
| genii | Is there a recommended CAN adapter ? | 15:12 |
| persia | Bsaerock is mostly focused on the software side: anything with kernel support should work. | 15:14 |
| genii | persia: OK, thanks. | 15:15 |
| *** ssam2 [~ssam2@host86-159-251-35.range86-159.btcentralplus.com] has quit [Ping timeout: 240 seconds] | 15:28 | |
| paulsherwood | genii: commandments seemed like a good name at the time... but that was in the 90s :) | 15:32 |
| genii | paulsherwood: Hah, understandable. | 15:33 |
| * richard_maw realises he'll have to start referring to the 90s as the generation before him referred to the 80s | 15:35 | |
| richard_maw | though 00s (pronounced noughties) sounds silly | 15:35 |
| *** fay_ [~fay@82-70-136-246.dsl.in-addr.zen.co.uk] has quit [Remote host closed the connection] | 15:59 | |
| *** jonathanmaw [~jonathanm@82-70-136-246.dsl.in-addr.zen.co.uk] has quit [Quit: Leaving] | 16:00 | |
| *** franred [~franred@82-70-136-246.dsl.in-addr.zen.co.uk] has quit [Quit: Leaving] | 17:00 | |
| paulsherwood | is stripping debug symbols as simple as running 'strip'? | 17:05 |
| persia | Yes, but generally speaking one wants to save them, so when the system breaks, one has the means to recover them and debug the issue. | 17:06 |
| persia | Be aware that this may be dangerous: some sorts of object files rather like to keep at least some of their symbols (e.g. .so files). | 17:07 |
| paulsherwood | i was just wondering where i might insert this in my workflow, to have smaller images and thus reduce deploy/upload times | 17:08 |
| persia | It's something morph should probably do when it splits the artifacts. | 17:09 |
| paulsherwood | i'm willing to risk breakages while experimenting | 17:09 |
| persia | That seems a logical point to separate blobs into two pieces: the stripped executable and the debug symbols (which can later be used for debugging). | 17:09 |
| persia | But someone more familar with how morph manages builds may have a better opinion than I. | 17:10 |
| *** ssam2 [~ssam2@host86-159-251-35.range86-159.btcentralplus.com] has joined #baserock | 17:32 | |
| robtaylor | genii: looking at drivers/net/can/usb looks like kernel has buit in support for: | 17:49 |
| robtaylor | EMS CPC-USB/ARM7 CAN/USB interface | 17:49 |
| robtaylor | ESD USB/2 CAN/USB interface | 17:49 |
| robtaylor | Kvaser CAN/USB interface | 17:49 |
| robtaylor | PEAK PCAN-USB/USB Pro interfaces | 17:49 |
| robtaylor | 8 devices USB2CAN interface | 17:49 |
| robtaylor | EMS Dr. Thomas Wuensche (http://www.ems-wuensche.de). | 17:49 |
| robtaylor | esd electronic system design gmbh (http://www.esd.eu). | 17:49 |
| robtaylor | PEAK-System Technik (http://www.peak-system.com). | 17:49 |
| robtaylor | 8 devices (http://www.8devices.com). | 17:49 |
| robtaylor | genii: hth :) | 17:50 |
| genii | robtaylor: Thanks! Yes, I also found most of those listed at http://elinux.org/CAN_Bus#SocketCAN_Supported_Controllers ...I did manage to get some good assistance also in the #genivi channel | 17:51 |
| robtaylor | genii: cool :) | 17:51 |
| robtaylor | genii: course, if you're using an autmotive SoC, they usually have a can interface built in (imx6, jacinto, jetson, etc) | 17:52 |
| genii | robtaylor: This is what we need to sort out on our end right now | 17:52 |
| *** ssam2 [~ssam2@host86-159-251-35.range86-159.btcentralplus.com] has quit [Quit: Leaving] | 18:15 | |
| *** flatmush [~flatmush@82-70-136-246.dsl.in-addr.zen.co.uk] has quit [Ping timeout: 246 seconds] | 18:25 | |
| *** flatmush [~flatmush@82-70-136-246.dsl.in-addr.zen.co.uk] has joined #baserock | 18:28 | |
| *** flatmush [~flatmush@82-70-136-246.dsl.in-addr.zen.co.uk] has quit [Ping timeout: 246 seconds] | 18:32 | |
| *** flatmush [~flatmush@82-70-136-246.dsl.in-addr.zen.co.uk] has joined #baserock | 18:33 | |
| *** flatmush [~flatmush@82-70-136-246.dsl.in-addr.zen.co.uk] has quit [Ping timeout: 260 seconds] | 18:40 | |
| *** flatmush [~flatmush@82-70-136-246.dsl.in-addr.zen.co.uk] has joined #baserock | 18:44 | |
| *** flatmush [~flatmush@82-70-136-246.dsl.in-addr.zen.co.uk] has quit [Ping timeout: 264 seconds] | 18:49 | |
| *** flatmush [~flatmush@82-70-136-246.dsl.in-addr.zen.co.uk] has joined #baserock | 18:49 | |
| *** flatmush [~flatmush@82-70-136-246.dsl.in-addr.zen.co.uk] has quit [Ping timeout: 245 seconds] | 18:54 | |
| *** flatmush [~flatmush@82-70-136-246.dsl.in-addr.zen.co.uk] has joined #baserock | 18:55 | |
| *** flatmush [~flatmush@82-70-136-246.dsl.in-addr.zen.co.uk] has quit [Ping timeout: 246 seconds] | 19:00 | |
| *** flatmush [~flatmush@82-70-136-246.dsl.in-addr.zen.co.uk] has joined #baserock | 19:11 | |
| *** flatmush [~flatmush@82-70-136-246.dsl.in-addr.zen.co.uk] has quit [Ping timeout: 250 seconds] | 19:15 | |
| *** flatmush [~flatmush@82-70-136-246.dsl.in-addr.zen.co.uk] has joined #baserock | 19:26 | |
| *** De|ta [~arc@195.242.156.171] has quit [Quit: leaving] | 19:28 | |
| *** flatmush [~flatmush@82-70-136-246.dsl.in-addr.zen.co.uk] has quit [Ping timeout: 240 seconds] | 19:32 | |
| *** De|ta [~arc@195.242.156.171] has joined #baserock | 19:37 | |
| richard_maw | paulsherwood, persia: Kinnison, liw-orc and I discussed this previously. The rough idea we had was to add "strip-commands" to chunk morphologies which operate on "$DESTDIR" only, and change the build-system defaults to include something appropriate that splits the binaries' debug symbols out, replacing it with a debug-link entry, and putting the debug symbol object files somewhere that chunk splitting will notice | 19:39 |
| richard_maw | can't stay to chat about this tonight though, I only logged in to see what irssi looks like with cool-old-term | 19:40 |
| *** flatmush [~flatmush@82-70-136-246.dsl.in-addr.zen.co.uk] has joined #baserock | 19:40 | |
| *** flatmush [~flatmush@82-70-136-246.dsl.in-addr.zen.co.uk] has quit [Ping timeout: 260 seconds] | 19:45 | |
| *** flatmush [~flatmush@82-70-136-246.dsl.in-addr.zen.co.uk] has joined #baserock | 19:51 | |
| *** flatmush [~flatmush@82-70-136-246.dsl.in-addr.zen.co.uk] has quit [Ping timeout: 255 seconds] | 20:00 | |
| *** flatmush [~flatmush@82-70-136-246.dsl.in-addr.zen.co.uk] has joined #baserock | 20:05 | |
| *** flatmush [~flatmush@82-70-136-246.dsl.in-addr.zen.co.uk] has quit [Ping timeout: 245 seconds] | 20:09 | |
| *** flatmush [~flatmush@82-70-136-246.dsl.in-addr.zen.co.uk] has joined #baserock | 20:10 | |
| *** flatmush [~flatmush@82-70-136-246.dsl.in-addr.zen.co.uk] has quit [Ping timeout: 250 seconds] | 20:25 | |
| *** flatmush [~flatmush@82-70-136-246.dsl.in-addr.zen.co.uk] has joined #baserock | 20:28 | |
| *** flatmush [~flatmush@82-70-136-246.dsl.in-addr.zen.co.uk] has quit [Ping timeout: 244 seconds] | 20:32 | |
| *** flatmush [~flatmush@82-70-136-246.dsl.in-addr.zen.co.uk] has joined #baserock | 20:36 | |
| *** flatmush [~flatmush@82-70-136-246.dsl.in-addr.zen.co.uk] has quit [Ping timeout: 240 seconds] | 20:44 | |
| *** flatmush [~flatmush@82-70-136-246.dsl.in-addr.zen.co.uk] has joined #baserock | 20:46 | |
| *** flatmush [~flatmush@82-70-136-246.dsl.in-addr.zen.co.uk] has quit [Ping timeout: 244 seconds] | 20:51 | |
| *** flatmush [~flatmush@82-70-136-246.dsl.in-addr.zen.co.uk] has joined #baserock | 20:52 | |
| *** flatmush [~flatmush@82-70-136-246.dsl.in-addr.zen.co.uk] has quit [Ping timeout: 240 seconds] | 20:57 | |
| *** flatmush [~flatmush@82-70-136-246.dsl.in-addr.zen.co.uk] has joined #baserock | 21:04 | |
| *** flatmush [~flatmush@82-70-136-246.dsl.in-addr.zen.co.uk] has quit [Ping timeout: 260 seconds] | 21:12 | |
| *** flatmush [~flatmush@82-70-136-246.dsl.in-addr.zen.co.uk] has joined #baserock | 21:42 | |
| *** flatmush [~flatmush@82-70-136-246.dsl.in-addr.zen.co.uk] has quit [Ping timeout: 240 seconds] | 21:47 | |
| *** flatmush [~flatmush@82-70-136-246.dsl.in-addr.zen.co.uk] has joined #baserock | 21:50 | |
| *** flatmush [~flatmush@82-70-136-246.dsl.in-addr.zen.co.uk] has quit [Ping timeout: 240 seconds] | 21:55 | |
| *** flatmush [~flatmush@82-70-136-246.dsl.in-addr.zen.co.uk] has joined #baserock | 21:56 | |
| *** flatmush [~flatmush@82-70-136-246.dsl.in-addr.zen.co.uk] has quit [Ping timeout: 245 seconds] | 22:01 | |
| *** flatmush [~flatmush@82-70-136-246.dsl.in-addr.zen.co.uk] has joined #baserock | 22:07 | |
| *** genii [~quassel@ubuntu/member/genii] has quit [Remote host closed the connection] | 22:11 | |
| *** flatmush [~flatmush@82-70-136-246.dsl.in-addr.zen.co.uk] has quit [Ping timeout: 244 seconds] | 22:12 | |
| *** flatmush [~flatmush@82-70-136-246.dsl.in-addr.zen.co.uk] has joined #baserock | 22:15 | |
| *** flatmush [~flatmush@82-70-136-246.dsl.in-addr.zen.co.uk] has quit [Ping timeout: 240 seconds] | 22:27 | |
| *** flatmush [~flatmush@82-70-136-246.dsl.in-addr.zen.co.uk] has joined #baserock | 22:33 | |
| *** flatmush [~flatmush@82-70-136-246.dsl.in-addr.zen.co.uk] has quit [Ping timeout: 240 seconds] | 22:44 | |
| *** flatmush [~flatmush@82-70-136-246.dsl.in-addr.zen.co.uk] has joined #baserock | 22:44 | |
| *** flatmush [~flatmush@82-70-136-246.dsl.in-addr.zen.co.uk] has quit [Ping timeout: 260 seconds] | 22:59 | |
| *** flatmush [~flatmush@82-70-136-246.dsl.in-addr.zen.co.uk] has joined #baserock | 22:59 | |
| *** flatmush [~flatmush@82-70-136-246.dsl.in-addr.zen.co.uk] has quit [Ping timeout: 244 seconds] | 23:05 | |
| *** flatmush [~flatmush@82-70-136-246.dsl.in-addr.zen.co.uk] has joined #baserock | 23:05 | |
| *** flatmush [~flatmush@82-70-136-246.dsl.in-addr.zen.co.uk] has quit [Ping timeout: 260 seconds] | 23:11 | |
| *** flatmush [~flatmush@82-70-136-246.dsl.in-addr.zen.co.uk] has joined #baserock | 23:31 | |
| *** flatmush [~flatmush@82-70-136-246.dsl.in-addr.zen.co.uk] has quit [Ping timeout: 240 seconds] | 23:48 | |
| *** flatmush [~flatmush@82-70-136-246.dsl.in-addr.zen.co.uk] has joined #baserock | 23:53 | |
Generated by irclog2html.py 2.15.3 by Marius Gedminas - find it at mg.pov.lt!