*** zoli__ [~zoli_@0x5e91887a.adsl.cybercity.dk] has quit [Remote host closed the connection] | 00:11 | |
*** zoli__ [~zoli_@0x5e91887a.adsl.cybercity.dk] has joined #baserock | 03:12 | |
*** zoli__ [~zoli_@0x5e91887a.adsl.cybercity.dk] has quit [Ping timeout: 256 seconds] | 03:16 | |
*** petefoth_ [~petefoth@82-70-136-246.dsl.in-addr.zen.co.uk] has joined #baserock | 04:03 | |
*** petefoth [~petefoth@82-70-136-246.dsl.in-addr.zen.co.uk] has quit [Ping timeout: 265 seconds] | 04:04 | |
petefoth_ is now known as petefoth | 04:04 | |
*** zoli__ [~zoli_@0x5e91887a.adsl.cybercity.dk] has joined #baserock | 04:36 | |
*** zoli__ [~zoli_@0x5e91887a.adsl.cybercity.dk] has quit [Remote host closed the connection] | 04:49 | |
*** zoli__ [~zoli_@0x5e91887a.adsl.cybercity.dk] has joined #baserock | 07:50 | |
*** zoli__ [~zoli_@0x5e91887a.adsl.cybercity.dk] has quit [Ping timeout: 265 seconds] | 07:54 | |
*** sherm_ [~mike@82-70-136-246.dsl.in-addr.zen.co.uk] has joined #baserock | 07:58 | |
*** zoli__ [~zoli_@0x5e91887a.adsl.cybercity.dk] has joined #baserock | 08:08 | |
perryl | persia: is there no 'hide joins/parts' function for quassel? | 08:21 |
---|---|---|
*** grahamfinney [~grahamfin@cpc14-know11-2-0-cust234.know.cable.virginm.net] has joined #baserock | 08:25 | |
*** sambishop [~sambishop@82-70-136-246.dsl.in-addr.zen.co.uk] has joined #baserock | 08:26 | |
*** tiagogomes_ [~tiagogome@82-70-136-246.dsl.in-addr.zen.co.uk] has joined #baserock | 08:42 | |
*** mariaderidder [~maria@82-70-136-246.dsl.in-addr.zen.co.uk] has joined #baserock | 08:42 | |
*** rdale_ [~quassel@81.Red-79-146-151.dynamicIP.rima-tde.net] has joined #baserock | 08:44 | |
*** zoli__ [~zoli_@0x5e91887a.adsl.cybercity.dk] has quit [Remote host closed the connection] | 09:02 | |
*** zoli__ [~zoli_@0x5e91887a.adsl.cybercity.dk] has joined #baserock | 09:02 | |
*** bashrc_ [~motters@82-70-136-246.dsl.in-addr.zen.co.uk] has joined #baserock | 09:06 | |
*** zoli__ [~zoli_@0x5e91887a.adsl.cybercity.dk] has quit [Ping timeout: 246 seconds] | 09:06 | |
*** CTtpollard [~tom@82-70-136-246.dsl.in-addr.zen.co.uk] has joined #baserock | 09:11 | |
rjek | Can somebody confirm to me that we're using glibc 2.20? The morphs are a twisty maze of many glibc references and I can't work it out. | 09:20 |
Kinnison | Last time I checked, we were using 2.20 | 09:21 |
tiagogomes_ | ldd (GNU libc) 2.20 | 09:26 |
*** zoli__ [~zoli_@cpe.ge-0-2-0-366.abnqu1.dk.customer.tdc.net] has joined #baserock | 09:35 | |
*** ssam2 [~ssam2@82-70-136-246.dsl.in-addr.zen.co.uk] has joined #baserock | 09:40 | |
Mode #baserock +v ssam2 by ChanServ | 09:40 | |
tiagogomes_ | anyone has ideas about the best way of updating config.guess and config.sub if they are not updated upstream? (a) download the files from http://git.savannah.gnu.org/gitweb/?p=config; (b) run `autoreconf -ivf` on the repositoy and commit; (c) add `autoreconf -ivf` to the pre-configure-commands of the morphology | 09:52 |
*** jonathanmaw [~jonathanm@82-70-136-246.dsl.in-addr.zen.co.uk] has joined #baserock | 09:53 | |
* tiagogomes_ favors (b) | 09:56 | |
Kinnison | If (c) were possible, (c) is preferable. Given you're clearly running from preconfigured tarball imports, I'd do (b) | 09:57 |
*** zoli__ [~zoli_@cpe.ge-0-2-0-366.abnqu1.dk.customer.tdc.net] has quit [Remote host closed the connection] | 09:57 | |
ssam2 | agreed | 09:57 |
Kinnison | I'd also be tempted to email the upstream project and ask them if they might do a new release with updated autoconfery | 09:58 |
tiagogomes_ | Kinnison, why (c) is not possible? | 09:59 |
tiagogomes_ | (c) is dangerous, as if you update automake, things could break when running the pre-configured-commands | 10:00 |
Kinnison | Presumably this is too early in the bootstrapping phase | 10:00 |
Kinnison | for autoconf, automake, libtool etc to be available | 10:00 |
tiagogomes_ | righto | 10:01 |
bashrc_ | why isn't there any manpage for the morph command? | 10:02 |
Kinnison | Most of morph's help is built into it | 10:03 |
Kinnison | because it's dynamic | 10:04 |
*** Krin [~mikesmith@82-70-136-246.dsl.in-addr.zen.co.uk] has joined #baserock | 10:05 | |
persia | perryl: The problem is that when I'm on both sides of a netsplit, I have to keep track of which others are in which segments. In my ideal world, my client follows the splits so that I have a consistent datastream from all segments, and am posting to all segments. | 10:05 |
ssam2 | bashrc_: there is one | 10:06 |
straycat | what's the deal with cliapp in baserock? we seem to have an unofficial fork? | 10:07 |
persia | Is the fork required for morph? | 10:08 |
bashrc_ | maybe morph isn't installed | 10:08 |
perryl | a number of morph plugins use cliapp functions | 10:08 |
persia | I know that we've forked some of the key support components for morph, lorry, etc. In some cases, even when we've landed things upstream, we haven't gone to an upstream branch in order to preserve history. | 10:08 |
ssam2 | straycat: i believe richard_maw has talked to lars a bit about our fork of cliapp, and at the time, lars didn't have time to do any kind of maintenance work on cliapp | 10:09 |
ssam2 | there are quite a few differences, it seems, it would be good to resolve them | 10:09 |
straycat | okay, just asking because richard_maw fixed a bug I found yesterday and the fix has been sent upstream, so we'll want that | 10:10 |
*** jonathanmaw [~jonathanm@82-70-136-246.dsl.in-addr.zen.co.uk] has quit [Ping timeout: 252 seconds] | 10:11 | |
*** jonathanmaw [~jonathanm@82-70-136-246.dsl.in-addr.zen.co.uk] has joined #baserock | 10:12 | |
*** grahamfinney [~grahamfin@cpc14-know11-2-0-cust234.know.cable.virginm.net] has quit [Quit: Ex-Chat] | 10:14 | |
*** grahamfinney [~grahamfin@cpc14-know11-2-0-cust234.know.cable.virginm.net] has joined #baserock | 10:14 | |
*** lachlanmackenzie [~lachlan@82-70-136-246.dsl.in-addr.zen.co.uk] has joined #baserock | 10:15 | |
*** zoli__ [~zoli_@cpe.ge-0-2-0-366.abnqu1.dk.customer.tdc.net] has joined #baserock | 10:19 | |
straycat | ssam2, i it's just this commit by doffm really, since the rest is chunk morph stuff we can remove | 10:19 |
pedroalvarez | that commit was to improve the `help` in morph IIRC | 10:20 |
tiagogomes_ | `build-depends: []` means that the chunk doesn't depend on anything on the strata were it was defined right | 10:25 |
ssam2 | tiagogomes_: yes | 10:26 |
* tiagogomes_ considers moving sqlite3 down on core | 10:26 | |
ssam2 | since it's already in core, changing the order is fine if something else depends on it | 10:29 |
tiagogomes_ | ssam2 I was thinking in moving it to do autoreconf as part of pre-configure-commands, not minimize the delta agains upstream. But I see now that's a tarball, so I don't think it matters | 10:30 |
tiagogomes_ | s/not minimize/to minimize | 10:30 |
ssam2 | none of our systems at baserock.org are vulnerable to http://www.openwall.com/lists/oss-security/2015/01/27/9 | 10:34 |
Kinnison | phew | 10:34 |
pedroalvarez | up-to-date systems ftw! | 10:35 |
paulsherwood | w00t!!!!! | 10:36 |
paulsherwood | 'a working security system is indistinguishable from blind luck' :) | 10:36 |
* paulsherwood wonders by what magic gcc in autotools gets built with /usr/bin in its path | 10:38 | |
paulsherwood | s/autotools/build-essential/ | 10:38 |
*** locallycompact [~lc@82-70-136-246.dsl.in-addr.zen.co.uk] has joined #baserock | 10:39 | |
ssam2 | paulsherwood: there is a little cleverness going on, there's a special 'prefix' field for each chunk in a stratum | 10:40 |
ssam2 | 'prefix' is /usr/bin by default | 10:40 |
ssam2 | sorry, 'prefix' is /usr by default | 10:40 |
paulsherwood | ssam2: i can see the special prefix set to '/tools' but nothing else. | 10:40 |
paulsherwood | (in definitions) | 10:40 |
ssam2 | yeah, if 'prefix' is absent then it is assumed to be /usr | 10:40 |
ssam2 | to avoid having to write 'prefix=/usr' for every single chunk | 10:41 |
ssam2 | then, this: http://git.baserock.org/cgi-bin/cgit.cgi/baserock/baserock/morph.git/tree/morphlib/buildcommand.py#n340 | 10:41 |
paulsherwood | so that's one of many magic assumptions hidden in morph, i think. | 10:41 |
ssam2 | i'd call it a 'default value' rather than a 'magic assumption' | 10:42 |
ssam2 | but I agree it could be documented better | 10:42 |
ssam2 | or, at all. :( | 10:42 |
paulsherwood | default values could be in definitions too, easily enough. hiding this in code is unhelpful | 10:43 |
paulsherwood | (imo) | 10:43 |
ssam2 | yeah, it'd be better if that could be controlled from definitions, I think | 10:43 |
persia | I'd agree. Some systems may not think /usr/ is a sensible path. | 10:43 |
* Kinnison thinks defaults should be in definitions, but so should the build systems | 10:43 | |
paulsherwood | agreed. | 10:44 |
Kinnison | This would be another move toward as much as possible being declarative | 10:44 |
paulsherwood | yup. | 10:44 |
Kinnison | Perhaps a topic worth discussion next week? | 10:44 |
paulsherwood | yes, absolutely :) | 10:45 |
paulsherwood | incidentally, ybd now builds up to gcc, hence my question. i have not verified it builds the same things, exactly, but it's a start :) | 10:45 |
*** grahamfinney [~grahamfin@cpc14-know11-2-0-cust234.know.cable.virginm.net] has quit [Quit: Ex-Chat] | 10:45 | |
ssam2 | cool! | 10:46 |
*** grahamfinney [~grahamfin@cpc14-know11-2-0-cust234.know.cable.virginm.net] has joined #baserock | 10:46 | |
*** grahamfinney_ [~grahamfin@cpc14-know11-2-0-cust234.know.cable.virginm.net] has joined #baserock | 10:46 | |
paulsherwood | i hope so. on this journey i've discovered another reason to be on it - ie a possibility to provide an independent view on morph's assumptions | 10:47 |
*** petefoth [~petefoth@82-70-136-246.dsl.in-addr.zen.co.uk] has quit [Quit: petefoth] | 10:48 | |
ssam2 | good for ensuring the definitions format is solid and well-defined, certainly | 10:48 |
Kinnison | Indeed | 10:49 |
paulsherwood | ssam2: i'd already seen that in buildcommand.py - but at gcc, all prefix can come back as is '/tools', so /usr must be slipped in somewhere else | 10:49 |
ssam2 | it includes its own prefix, I think | 10:49 |
Kinnison | Ideally we'd be able to have a multiplicity of tools all able to work from definitions and all producing the same stuff | 10:49 |
paulsherwood | +1 | 10:49 |
* Kinnison has been tempted to write some haskell to represent morphologies in an attempt to see if he can come up with an algebra of chunks | 10:49 | |
* Kinnison is odd though | 10:50 | |
paulsherwood | ssam2: possibly, but i'm trying to understand what sets PATH in this way | 10:50 |
paulsherwood | -PATH=/tools/bin:/usr/bin:/usr/lib/ccache:/sbin:/usr/sbin:/bin:/usr/bin | 10:50 |
paulsherwood | +PATH=/tools/bin:/usr/lib/ccache:/sbin:/usr/sbin:/bin:/usr/bin | 10:50 |
paulsherwood | not to worry, i'll track it down :) | 10:51 |
straycat | richard_maw, Did we submit doffm's patch to liw? | 10:53 |
paulsherwood | Kinnison: that would be quite exciting. we are exploring an R&D project which would be interested in that thinking :-) | 10:53 |
Kinnison | paulsherwood: I'd love to chat with someone who understands FP more than I do about it | 10:54 |
* Kinnison is a dabbler in it | 10:54 | |
paulsherwood | :) | 10:54 |
* paulsherwood is a dabbler in general | 10:55 | |
richard_maw | straycat: yes, liw couldn't accept it because it changed things in a not backwards compatible way. IIRC he said he'd look at a better way to do it, but that was back when he had time to look at it. | 10:56 |
*** petefoth [~petefoth@82-70-136-246.dsl.in-addr.zen.co.uk] has joined #baserock | 10:56 | |
straycat | right | 10:57 |
straycat | i guess we can wait till he merges the fix then merge master into baserock/morph? | 11:00 |
richard_maw | that's what I'd do | 11:12 |
bashrc_ | is there a way to determine if an image is devel or not? | 11:14 |
*** zoli__ [~zoli_@cpe.ge-0-2-0-366.abnqu1.dk.customer.tdc.net] has quit [Ping timeout: 245 seconds] | 11:15 | |
ssam2 | bashrc_: ls /baserock/*-system-*.meta | 11:18 |
ssam2 | will give you the name (and much more info) of the system artifact | 11:18 |
bashrc_ | thanks | 11:18 |
nowster | is it a bug in me or morph that you get "file exists" when doing "morph branch baserock:foo my/branch ; morph branch upstream:bar my/branch" ? | 11:46 |
ssam2 | morph, really | 11:46 |
nowster | I get "ERROR: /src/workspace/my/branch: File exists" on the second command | 11:46 |
pedroalvarez | you are trying to create 2 branches with same name | 11:47 |
nowster | pedroalvarez: yes, that is true | 11:47 |
ssam2 | `morph branch`, `morph checkout` and `morph edit` are quite flawed | 11:47 |
nowster | and it's what I desire | 11:47 |
ssam2 | but we've not yet done much documentation or work on how to use Morph without needing those commands | 11:47 |
*** De|ta [~arc@195.242.156.171] has quit [Quit: reboot] | 11:51 | |
Zara_ | incidentally, the 'man morph' synopsis is a bit terrifying when you see it for the first time. I'm not sure if all that stuff should be in the synopsis, or if we could move some of it elsewhere. | 11:54 |
*** De|ta [~arc@195.242.156.171] has joined #baserock | 11:54 | |
persia | Unfortunately, morph really doesn't work without at least one execution of `morph checkout` or `morph branch`. Working without `morph edit` is as well documented as working with `morph edit`, but mostly because of the lack of clear documentation for either choice. | 11:54 |
petefoth | Zara_: sadly, for baserock generally there is no specification (that I am aware of) for what documentation is required, and what criteria can be used to to determine whwther what is implmeneted meets those requirements. So we could (we have) change it to meet something we believe is a requirment, then change it again later to meet a different requirment without checking that it still fulfils the earlier requirement. | 11:58 |
*** zoli__ [~zoli_@cpe.ge-0-2-0-366.abnqu1.dk.customer.tdc.net] has joined #baserock | 11:58 | |
persia | Some of that is exposed in the tests, but only with Mason v3 are we reaching a point where we have credible system-level testing, and are able to write verification criteria that match documentation, etc. | 12:00 |
persia | Specification is a bit of an illusion in a collaborative environment: unless there is absolute consensus, the implementation rarely matches, and when there is delay for absolute consensus, the feature is often dropped in favour of something similar but different or a workaround that someone developed while everyone was waiting for consensus. | 12:01 |
Zara_ | I see. Just for context, atm I'm trying to find/flag up any UI issues which might discourage people from using baserock, and work out how easy they would be to fix. | 12:04 |
petefoth | Zara_: good luck! ;) | 12:05 |
mauricemoss_ | is there an easy way to force a morph doing a clean build? I fiddle around with deleting chunks and the ccache, but morph won't do a clean build. | 12:10 |
tiagogomes_ | mauricemoss_ did you deleted the artifacts as well? /src/artifacts | 12:10 |
SotK | mauricemoss_: rm -rf /src/cache/artifacts | 12:11 |
SotK | assuming your cachedir is set to /src/cache | 12:11 |
mauricemoss_ | ok, I'll try | 12:11 |
mauricemoss_ | worked :) Can I document that as "Clean build" under build issues in the wiki? | 12:13 |
persia | Documentation for that should probably include information on how *not* to use a cache server. | 12:20 |
persia | While some builds don't use the cache server, higher-level stuff often does, and if one wants a true clean build, one wants not to use cached artifacts. | 12:21 |
mauricemoss_ | ok | 12:21 |
*** jonathanmaw_ [~jonathanm@82-70-136-246.dsl.in-addr.zen.co.uk] has joined #baserock | 12:40 | |
*** jonathanmaw [~jonathanm@82-70-136-246.dsl.in-addr.zen.co.uk] has quit [Read error: Connection reset by peer] | 12:40 | |
nowster | morph branch *appears* happy if you move the branch-named directory somewhere else | 12:48 |
nowster | eg. morph branch baserock:foo my/branch; mv my/branch my-branch | 12:49 |
nowster | or morph branch baserock:foo my/branch; mv my/branch my-branch-foo | 12:49 |
persia | Morph keeps some hidden files at the workspace level that may be confused as a result of that sort of thing. | 12:53 |
nowster | it does? My /src/workspace/.morph/ is empty | 12:54 |
nowster | I haven't got rid of the .../.morph-system-branch/config stuff. There's one in each checkout. | 12:55 |
persia | I believe morph makes some assumptions about directory layout, so you may want to adjust the config and the branch names to suit. | 12:57 |
persia | Or this may not be an issue for you. | 12:57 |
nowster | let's see what happens | 12:57 |
* SotK thinks morph can cope with the directory being renamed | 12:59 | |
persia | SotK: When running `morph`, it doesn't use the branchname from config to determine the directory in which to find definitions? | 13:00 |
SotK | persia: I don't think so | 13:04 |
jonathanmaw_ is now known as jonathanmaw | 13:05 | |
SotK | It determines that based on which directory you are in (it knows how to find the root directory of the "system branch", and from there can get the path to definitions) | 13:05 |
SotK | where the root directory of the "system branch" is the one containing the ".morph-system-branch" directory | 13:06 |
SotK | I thinK :) | 13:06 |
SotK | q | 13:11 |
*** CTtpollard [~tom@82-70-136-246.dsl.in-addr.zen.co.uk] has quit [Quit: Ex-Chat] | 13:20 | |
ssam2 | yes, moving the directories created by 'morph branch/checkout' and 'morph edit' around should work fine | 13:20 |
tiagogomes_ | I am trying to build m4 after doing a `autoreconf -ivf`. It fails with: aclocal-1.14: not found . It shouldn't need aclocal with the files updated by autoreconf committed. Any idea | 13:20 |
*** CTtpollard [~tom@82-70-136-246.dsl.in-addr.zen.co.uk] has joined #baserock | 13:22 | |
pedroalvarez | maybe you ran autoreconf in a machine with different autoconf version? | 13:22 |
pedroalvarez | jjardon: have you ever tried `gst-launch-1.0 audiotestsrc ! audioconvert ! pulsesink` in baserock? | 13:24 |
tiagogomes_ | the machine the I ran autoreconf is the same as I am trying to build the chunk and it is failing | 13:24 |
jjardon | pedroalvarez: yep, if you can only use a VM, simply check the pipeline change to state PLAYING without errors | 13:41 |
pedroalvarez | jjardon: I was asking because i tried to test Alsa but looks like we are missing some kernel drivers to get it running | 13:42 |
radiofree | did you add a soundcard in qemu? | 13:42 |
jjardon | pedroalvarez: alsasink maybe doesnt work because the device is being used by pulseaudio | 13:44 |
jjardon | generally is not a good idea to access alsa devices directly when pulseadio is running | 13:45 |
persia | If `aplay -l` returns "no devices", this isn't the problem. | 13:46 |
radiofree | try qemu with -soundhw all | 13:48 |
radiofree | you might have the driver for at least one of them... | 13:48 |
radiofree | pretty sure hda (intel hda) is on by default in the defconfig | 13:49 |
jjardon | mmm, seems pulseadio is intelligent enough to not make the pipeline to fail even if the alsa device is not there | 13:50 |
*** CTtpollard [~tom@82-70-136-246.dsl.in-addr.zen.co.uk] has quit [Read error: Connection reset by peer] | 13:57 | |
*** CTtpollard [~tom@82-70-136-246.dsl.in-addr.zen.co.uk] has joined #baserock | 13:57 | |
nowster | ERROR: Push to remote "trove", push url ssh://git@ct-mcr-1.ducie.codethink.co.uk/delta/cpython failed with exit code 1 | 14:09 |
nowster | That's helpful. | 14:09 |
nowster | "ssh git@ct-mcr-1.ducie.codethink. | 14:09 |
nowster | co.uk whoami" is fine. | 14:09 |
SotK | what did you run to get that error? | 14:10 |
Kinnison | For those following tiago's attempts to get armv8l64 up, I can now confirm I have a minimal patch series against 3.19-rc5 (which should therefore be good against 3.19 real) and a devicetree which can boot an HP Moonshot m400 cartridge | 14:10 |
nowster | morph push trove baserock/nowster | 14:10 |
nowster | morph push trove baserock/nowster/mips | 14:10 |
richard_maw | Kinnison: woo! | 14:11 |
SotK | Kinnison: nice! | 14:11 |
ssam2 | sweet! | 14:11 |
ssam2 | nowster: avoid `morph push` | 14:12 |
SotK | nowster: try naming your branch ct-mcr-1/nowster/mips, and using git push :) | 14:12 |
ssam2 | `git push` is fine and does the same thing, unless you happen to have committed binaries using `morph add-binary` | 14:12 |
ssam2 | anyone able to do an in-IRC review of this patch to fix a stupid mistake I made with the lvm2 chunk morph? http://sprunge.us/giKV | 14:12 |
nowster | Aha! | 14:13 |
nowster | ! [remote rejected] baserock/nowster/mips -> baserock/nowster/mips (hook declined) | 14:13 |
nowster | The server, she no like me. | 14:13 |
nowster | does the branch name need to start with ct-mcr-1? | 14:14 |
SotK | nowster: I think so | 14:14 |
perryl | nowster: try git push <branchname>:ct-mcr-1/<branchname> | 14:14 |
Kinnison | If you're pushing to a trove called XXX then the branch will typically need to start XXX/ | 14:14 |
pedroalvarez | ssam2: +1 if you move "I'm dubm" out of the commit message and you put it on a sticker in your t-shirt | 14:15 |
pedroalvarez | s/dubm/dumb/ | 14:16 |
nowster | ok... it's accepted it. | 14:16 |
nowster | not ideal, but it's there | 14:16 |
SotK | nowster: why not ideal? | 14:17 |
persia | ssam2: I don't like the commit message, but +1 for the rest of it. Please explain that it was because Fedora links them, rather than making inaccurate claims about your thinking processes. | 14:17 |
persia | The idea being that future developers looking through the commit messages can learn something useful or avoid the same trap. | 14:17 |
ssam2 | it's not to do with Fedora, it's to do with 'prefix' meaning the path *containing* ./lib, not ./lib itself | 14:18 |
persia | Ah. I thought this was related to the /lib/udev vs. /usr/lib/udev issue discussed recently | 14:18 |
ssam2 | ok if I change it to: 'The rules were being put in /lib/lib/udev/rules.d because I specified the wrong value for --with-udev-prefix=' ? | 14:18 |
persia | But anyway, it ought be explained :) | 14:19 |
persia | I'd prefer "The rules were being put in /lib/lib/udev/rules.d/ because --with-udev-prefix is the path *containing* ./lib, not ./lib itself." | 14:20 |
ssam2 | ok, i'll commit with that message. thanks | 14:20 |
persia | Thanks for finding this and fixing it :) | 14:20 |
tiagogomes_ | how to I attach a second volume to my VM in openstack | 14:21 |
tiagogomes_ | s/how to/how do | 14:21 |
ssam2 | persia: it found me. :) | 14:21 |
persia | tiagogomes_: http://docs.openstack.org/user-guide/content/dashboard_manage_volumes.html | 14:22 |
persia | tiagogomes_: Also, if you don't get enough help here, the folk in #openstack are also helpful (and may know more than us). | 14:22 |
tiagogomes_ | persia thanks | 14:22 |
persia | tiagogomes_: There are also some nova command-line calls that would do that, but I fear the nova command-line options. | 14:23 |
jmalk | I'm currently trying to run `morph cross-bootstrap` to x86_32 and getting the following error: http://paste.baserock.org/onubazukoh . For comparison I tried running cross-bootstrap to ppc64 and it completed with no problems. | 14:28 |
persia | jmalk: To confirm, your local system is not x86_32, right? | 14:30 |
jmalk | persia: it is not. trying this on a VM, which is using baserock-14.29-devel-system-x86_64-generic | 14:30 |
persia | 14.29? You might want to pull latest definitions, and run cycle.sh to get something fresher. | 14:31 |
jmalk | persia: I shall take a look at that | 14:31 |
richard_maw | jmalk: what's in your cross-bootstrap-sysem-x86_32-generic.morph? | 14:31 |
jmalk | richard_maw: a paste of "Add the following" from http://wiki.baserock.org/x86_64_to_x86_32/ | 14:32 |
jmalk | richard_maw: the writers of that tutorial had not encountered the error | 14:32 |
richard_maw | jmalk: If you can confirm that it still has the `- morph: strata/build-essential.morph` line in it, I'm out of ideas | 14:34 |
persia | The reference definitions have cross-bootstrap morphologies for armv7lhf, ppc64, and x86_64, which differ only by arch name. Should the documentation perhaps reference one of these, and indicate that one copies the file and changes the architecture string? | 14:34 |
richard_maw | that error's only supposed to happen if you ended up with strata that don't contain any bootstrap chunks, and build-essential is the stratum which should have bootstrap chunks | 14:35 |
persia | Does the x86_64 compiler have some special magic that makes it think x86_32 isn't cross-compilation? | 14:35 |
richard_maw | persia: it's failing well before a compiler gets involved | 14:36 |
jmalk | persia: that documentation links to http://wiki.baserock.org/guides/how-to-cross-bootstrap/ where the original "ARCH_NAME" example is | 14:36 |
persia | jmalk: Right. I'm not a fan of having multiple different copies of a file under different version control systems, which is why I thought it might be best to just reference the files in definitions master :) | 14:37 |
SotK | Does anyone remember why when serialising artifacts in distbuild we do "json.dumps(yaml.dump(contents))"? | 14:41 |
Kinnison | content which cannot be encoded in json | 14:42 |
SotK | which morphologies contain that? :( | 14:44 |
Kinnison | I think it's more logs | 14:48 |
Kinnison | e.g. filenames with byte sequences which are invalid utf8 i think make json barf | 14:48 |
SotK | we don't serialise the logs there though afaict | 14:48 |
Kinnison | metadata comes through perhaps? | 14:49 |
* Kinnison isn't clear on it and perhaps running 'git annotate' and examining the commits which put it in place might help? | 14:49 | |
persia | logs can contain anything, in any encoding (or even several) | 14:49 |
SotK | hm, the commit message suggests its to "allow distbuilding morphologies with binary data embedded" | 14:50 |
persia | Perhaps someone wanted to put some binary blobs in the foo-commands sections? I'd think it would be more sensible to base64- or uuencode them. | 14:50 |
* SotK imagines this was discussed at the time and looks on the ML | 14:51 | |
*** zoli__ [~zoli_@cpe.ge-0-2-0-366.abnqu1.dk.customer.tdc.net] has quit [Remote host closed the connection] | 14:54 | |
ssam2 | the reason distbuild needs to handle binary data is for when we transfer stdout and stderr from chunk builds | 14:59 |
ssam2 | because we can't expect those to be valid UTF-8 | 15:00 |
ssam2 | i'm pretty sure any other communcation can be easily validated before sending | 15:00 |
ssam2 | we should probably reject any chunk names that aren't valid UTF-8 straight away in morphloader.py | 15:00 |
ssam2 | the 'encode as YAML then JSON' thing was always a bit of a hack though, I think it was done in quite a rush | 15:01 |
*** grahamfinney [~grahamfin@cpc14-know11-2-0-cust234.know.cable.virginm.net] has quit [Quit: Ex-Chat] | 15:01 | |
richard_maw | ssam2: yeah, it should just be yaml, but there's code that expects the output to be a one-line string that encodes a json object | 15:05 |
richard_maw | it would be better to make the parser handle multi-line messages and send the whole thing in yaml, but we were in a rush | 15:05 |
SotK | richard_maw: it looks to me like we just use yaml.load(json.loads(encoded_stuff)) when deserialising artifacts though? | 15:06 |
richard_maw | possibly, there's two different communications streams using the same idea going on. There's controller ←→ worker and `morph serialize-artifact` → worker | 15:08 |
ssam2 | richard_maw: ah, I see, so the line-breaks in yaml break the code which expects messages to be newline-separated | 15:08 |
Kinnison | ssam2: chunk metadata might also contain non utf-8 (e.g. filenames) | 15:09 |
ssam2 | Kinnison: true, but I don't think distbuild ever talks about that right now | 15:09 |
tiagogomes_ | do we have morphs on the repos because nobody delete them, or because they are needed for backwards compatibility | 15:11 |
ssam2 | i wonder if there's something other than JSON or YAML we could use that would be (a) debuggable (b) fast (c) not limited to UTF-8 strings and (d) terminated in a way that code listening to the sockets can handle easily | 15:11 |
ssam2 | tiagogomes_: chunk morphs in chunk repos are there only because nobody has deleted them | 15:11 |
tiagogomes_ | ssam2, good to hear, thanks | 15:11 |
persia | deleting things in git is hard: better to just drop the relevant patch when moving to a new commit. | 15:12 |
* SotK hopes so, the current method is horribly slow | 15:12 | |
ssam2 | there's https://developers.google.com/protocol-buffers/, I've never used it | 15:12 |
* richard_maw dislikes protocol buffers, as it's a meta-language that generates C or Go code, rather than having its own compiler that produces object code that you can link in | 15:13 | |
ssam2 | does it not generate Python? | 15:16 |
ssam2 | it's hard to tell from https://developers.google.com/protocol-buffers/docs/pythontutorial | 15:16 |
*** franred [~franred@82-70-136-246.dsl.in-addr.zen.co.uk] has quit [Quit: Leaving] | 15:17 | |
rdale_ | yes, you can use python protobufs | 15:17 |
jmacs | Why do you dislike generating C? | 15:18 |
richard_maw | jmacs: it usually ends up generating hard to debug C when something does go wrong | 15:21 |
jmacs | Harder than debugging object code? | 15:21 |
rdale_ | protobuf is c++, not c and the python protobuf code is pure python afaik | 15:23 |
ssam2 | I have a feeling that to have a Gerrit running on Baserock at baserock.org that sends forgot-password emails and the like, I need to add sendmail to Baserock | 15:33 |
pedroalvarez | i managed to configure exim4 on it | 15:34 |
ssam2 | ok, is that better or worse than sendmail ? | 15:34 |
ssam2 | (i know nothing here) | 15:34 |
richard_maw | exim4 is a sendmail | 15:36 |
ssam2 | ok, so ftp://ftp.sendmail.org/pub/sendmail/ is not 'sendmail' but 'a sendmail' too? | 15:36 |
pedroalvarez | it wasn't complicated to configure, and I remember that Kinnison and rjek helped me with it. And the fact that they didn't say "don't use it" makes me think that is a good option :) | 15:36 |
ssam2 | exim4 seems to have git repos to | 15:36 |
ssam2 | o | 15:36 |
persia | ssam2: You want exim or postfix: not authentic sendmail | 15:37 |
ssam2 | ok, thanks | 15:37 |
ssam2 | I'll go with exim4 | 15:37 |
pedroalvarez | ssam2: if the old testgerrit is still alive, it will have the configuration | 15:37 |
ssam2 | great | 15:37 |
persia | Actually, you may not even need something that complex, if you are only dealing with limited outbound. | 15:40 |
persia | https://github.com/ajwans/sSMTP as an example | 15:40 |
* rjek oohs at exim4 | 15:44 | |
rjek | ISTR exim4 is exciting* to build with morph, but it's been 2 years since I tried. | 15:44 |
persia | I also worry about the security of exim vs. postfix (single binary vs. privilege separation), but I know of no exploits that use that vector today. | 15:45 |
persia | But ssmtp or nullmailer are more useful candidates for appliances, unless one is setting up a mail host. | 15:45 |
* persia doesn't like nullmailer because it doesn7t have TLS support, but that may not be important for a controlled network | 15:46 | |
nowster | one wee problem with cross-bootstrap... it leaves stuff in /bin -> /tools/bin | 15:47 |
persia | nowster: At which point? My thought is that the model is 1) run something to generate a cross-tarball, 2) boot the cross-tarball to get a very basic system, 3) use this to run morph to generate a real build system, 4) deploy the build system somewhere, and start from there (generating devel, possibly deployiing trove/distbuild, etc.) | 15:49 |
nowster | at what point should /tools be removed? | 15:50 |
ratmice__ | fwiw, the author of protobufs went on to write cap'n'proto, which i'm not sure if its capnp compile with various output plugins would cover any of richard's objections | 15:50 |
Kinnison | nowster: once the native-bootstrap completes, the system is "enough" to build something with morph | 15:50 |
Kinnison | nowster: we suggest you build a build system | 15:50 |
Kinnison | nowster: then use that build system to build a devel system | 15:50 |
Kinnison | nowster: at that point you're fairly well clean and away | 15:51 |
richard_maw | ratmice__: ooh, I like the look of that | 15:51 |
persia | With this model, /tools is never explicity removed: the entire rootfs that contained it is ignored instead. | 15:51 |
Kinnison | correct | 15:52 |
persia | That said, does the use of binaries from /tools ever cause a reduction in bootstrap steps? | 15:52 |
ssam2 | i don't understand the question | 16:01 |
Kinnison | The presence of /tools after the completion of the native part of the bootstrap phase is sad but not actually relevant. | 16:06 |
Kinnison | It should be ignored and a clean system built out of the tottering doom | 16:07 |
persia | nowster reports that there is some /bin->/tools/bin stuff left over. My question is whether this matters at all. | 16:07 |
pedroalvarez | ssam2: given that the patch already had a +2, I merged it :/ | 16:07 |
Kinnison | It shouldn't matter, no | 16:07 |
ssam2 | pedroalvarez: thanks. I'm sure it won't hurt :) | 16:10 |
ssam2 | persia: the symlink from /bin to /tools/bin is an expected part of the stage 3 bootstrap | 16:11 |
ssam2 | I forget the details of why | 16:11 |
ssam2 | it should be documented in the comments of the build-essential stratum | 16:11 |
*** sherm_ [~mike@82-70-136-246.dsl.in-addr.zen.co.uk] has quit [Quit: Leaving] | 16:39 | |
bashrc_ | getting an error: Couldn't find morphology: strata/build-essential/stage2-linux-api-headers.morph | 16:46 |
bashrc_ | the thing is that morph file exists | 16:46 |
pedroalvarez | bashrc_: can you please paste a detailed log of the error? With `morph version` output too please | 16:49 |
bashrc_ | morph version is e8adedb8f3f27d9212caf277b8e8f7c6792a20c2 | 16:51 |
bashrc_ | and I'm running the command morph cross-bootstrap $TARGET_ARCH file:///src/workspace/crossboot/baserock/baserock/definitions HEAD systems/cross-bootstrap-system-$TARGET_ARCH-generic.morph | 16:52 |
pedroalvarez | bashrc_: can you please paste a detailed log of the error? | 16:52 |
pedroalvarez | bashrc_: also, this version of morph is pretty old, can you update it please? | 16:54 |
pedroalvarez | bashrc_: this is the easiest way to do it: http://wiki.baserock.org/using-latest-morph/ | 16:56 |
bashrc_ | tried to get verbose output, but morph doesn't like that | 16:57 |
pedroalvarez | it liked it every time I used it | 16:58 |
bashrc_ | just using -v or --verbose | 16:58 |
pedroalvarez | anyway, please upgrade morph, the version that you are using is from before we moved all the chunks to definitions | 16:59 |
pedroalvarez | if it's still failing, then please send the logs | 16:59 |
pedroalvarez | is --verbose | 16:59 |
*** jonathanmaw [~jonathanm@82-70-136-246.dsl.in-addr.zen.co.uk] has quit [Quit: Leaving] | 17:01 | |
ssam2 | if --verbose doesn't work, '--log=/dev/stdout --log-level=debug' should give you even more info on stdout | 17:02 |
locallycompact | What does lp: mean in the url field of make.lorry? | 17:07 |
richard_maw | launchpad | 17:08 |
richard_maw | it's a bzr import | 17:08 |
* persia continues to believe the easiest way to move a devel system to latest morph is to have a definitions master checking, and to run `git pull; morph upgrade` therein. | 17:10 | |
locallycompact | Why isn't it being updated? | 17:10 |
persia | s/checking/checkout/ | 17:10 |
bashrc_ | ah the classic error: Nothing to cross-compile. Only chunks built in 'bootstrap' mode can be cross-compiled | 17:11 |
bashrc_ | verbose output http://0bin.net/paste/V4j7twvXVphvRZKz#NNHOhyBdOQzNE92VgTDj+mtkrvc0cgggeNmQ6p-1ESS | 17:12 |
ssam2 | locallycompact: is there a problem with the delta/make lorry not updating? I can look at why, but will probably have to wait til tomorrow | 17:13 |
locallycompact | ssam2: Latest master on g.b.o is 3 years old which is 3.8.something, I'm interested in bringing it up to latest. | 17:14 |
ssam2 | oh dear | 17:15 |
ssam2 | but the launchpad make repo is up to date? or are we lorrying from the wrong place? | 17:15 |
locallycompact | I'm trying to find where that lives | 17:16 |
locallycompact | Think it's up to date https://launchpad.net/make | 17:17 |
ssam2 | good spot, the lorry is failing | 17:19 |
ssam2 | log shows: bzr: ERROR: These branches have diverged. Use the missing command to see how. | 17:19 |
ssam2 | Use the merge command to reconcile them. | 17:19 |
ssam2 | I don't have a clue how to fix that | 17:19 |
Kinnison | sounds like they've force-pushed their bzr branch and lorry didn't know what to do | 17:19 |
Kinnison | ssam2: bzr pull --overwrite might be what you need | 17:20 |
ssam2 | cool, I'll try that | 17:20 |
pedroalvarez | bashrc_: from your log I don't see what command are you running, nor what morphology trying to build | 17:21 |
ssam2 | also, it seems silly to me that we keep these lorry logs secret. If they were public it'd be easier to notice errors like this.. | 17:21 |
bashrc_ | the full script is here: http://wiki.baserock.org/x86_64_to_armv8l64 | 17:21 |
pedroalvarez | ssam2: I'd like to make public also if they are working or not. | 17:22 |
pedroalvarez | ssam2: one day I thought that pubilishing the results of the latest run would be ok | 17:22 |
*** tiagogomes_ [~tiagogome@82-70-136-246.dsl.in-addr.zen.co.uk] has quit [Quit: Leaving] | 17:23 | |
ssam2 | Kinnison: `bzr pull --overwrite` did a lot of stuff, but it still shows the error | 17:23 |
Kinnison | what does 'bzr missing' tell you? | 17:23 |
ssam2 | 'Branches are up to date. ' | 17:24 |
ssam2 | and if I run 'bzr pull' in the /bzr directory, it succeeds | 17:24 |
Kinnison | odd | 17:24 |
ssam2 | ah, I might need to add 'lp:make' to the end of the 'bzr pull' command | 17:24 |
Kinnison | heh | 17:25 |
ssam2 | ah, and I need to run it in the bzr/trunk directory, not the bzr/ directory | 17:28 |
pedroalvarez | bashrc_: sorry, I don't have time to understand your script right now. | 17:28 |
ssam2 | 4th time lucky | 17:28 |
Kinnison | bzr is confusing when you're used to git | 17:31 |
Kinnison | (and git is confusing when you're used to bzr) | 17:31 |
ssam2 | this time, it failed because git-fast-import returned non-zero | 17:32 |
ssam2 | but its stderr only shows warnings | 17:32 |
Kinnison | I assume git-fast-import can do non-ff updates | 17:33 |
ssam2 | I see this: | 17:33 |
ssam2 | git fast-import --export-marks=/home/l | 17:33 |
ssam2 | orry/working-area/delta_make/git/marks.git --import-marks=/home/lorry/working-ar | 17:33 |
ssam2 | ea/delta_make/git/marks.git | 17:33 |
ssam2 | warning: Not updating refs/heads/trunk (new tip 0c1aa83e432e8ea521f70db6065daf5382eb1426 does not contain ec421e7dda7788ac19e912fcc4e07f9a5809f8d5) | 17:34 |
ssam2 | which suggests it's avoiding doing a non-ff update | 17:34 |
*** nowster [~pm@82-70-136-246.dsl.in-addr.zen.co.uk] has quit [Quit: Client exiting] | 17:34 | |
Kinnison | :( | 17:36 |
Kinnison | pop --force on the import cmdline maybe? | 17:36 |
ssam2 | i'll try running it manually with --force | 17:36 |
*** mariaderidder [~maria@82-70-136-246.dsl.in-addr.zen.co.uk] has quit [Quit: Ex-Chat] | 17:36 | |
* ssam2 does so as root, and thus breaks more things | 17:39 | |
Kinnison | oops | 17:39 |
ssam2 | locallycompact: fresh new commits of make! http://git.baserock.org/cgi-bin/cgit.cgi/delta/make.git | 17:40 |
ssam2 | please wipe the tears off them | 17:41 |
locallycompact | ssam2: Thanks very much | 17:41 |
* locallycompact notices no tags of 4.x, hmm | 17:41 | |
*** gary_perkins [~gary_perk@82-70-136-246.dsl.in-addr.zen.co.uk] has joined #baserock | 17:42 | |
radiofree | wouldn't it be easier to use make from git? | 17:43 |
ssam2 | definitely. is there one? | 17:44 |
radiofree | http://git.savannah.gnu.org/cgit/make.git ? | 17:45 |
ssam2 | cool, let's switch to that | 17:46 |
ssam2 | I wonder why we were using it from launchpad? | 17:46 |
ssam2 | for compatibility reasons we'll have to keep the existing delta/make repo and import the git one as delta/make-git or something... | 17:46 |
radiofree | there's a tag in there "moved-to-git" from 2 years ago | 17:47 |
radiofree | maybe when it was originally lorried there was no git repo | 17:47 |
ssam2 | ah, right | 17:49 |
ssam2 | one problem of this 'everything is reproducible for ever' idea we have is that we can't rename the existing delta/make repo without breaking lots of existing commits of definitions.git | 17:50 |
ssam2 | unless we implement some super clever 'redirect this repo to this one but only in commits older than this' system, but that sounds a bit risky | 17:50 |
*** nowster [~pm@82-70-136-246.dsl.in-addr.zen.co.uk] has joined #baserock | 17:51 | |
ssam2 | so I guess we're stuck with delta/make-2 or delta/make-git or something... | 17:51 |
pedroalvarez | +1 for make-git | 17:51 |
ssam2 | unless of course the sha1s for the savannah version of make.git happen to correspond to those in our bzr import... but i think that's unlikely | 17:52 |
*** Krin [~mikesmith@82-70-136-246.dsl.in-addr.zen.co.uk] has quit [Remote host closed the connection] | 17:54 | |
richard_maw | especially since they've apparently fast-forwarded their own master | 17:54 |
gary_perkins | Hi, can anyone help me? I'm trying to run morph deploy ct-trove.morph. It has /root/.ssh/authorized_keys in the manifest. But the deploy errors with the following: ERROR: install-files.configure failed with code 1: ERROR: [Errno 2] No such file or directory: '/src/tmp/deployments/tmpWZb3He/tmpf9X8Ng/./root/.ssh/authorized_keys' | 17:55 |
gary_perkins | I'm sure I had this same problem when deploying this trove the first time, but I can't remember how I fixed it | 17:55 |
pedroalvarez | gary_perkins: can I see the manifest? | 17:56 |
gary_perkins | pedroalvarez: sure... | 17:56 |
pedroalvarez | I assume that in the root folder of your definitions you have a root/.ssh/ folder | 17:56 |
pedroalvarez | with the file inside | 17:57 |
gary_perkins | 0100600 0 0 root/.ssh/authorized_keys | 17:57 |
gary_perkins | I have a ct-trove-files/root/.ssh/authorized_keys | 17:58 |
gary_perkins | should I have added the ct-trove-files ? | 17:58 |
*** bashrc_ [~motters@82-70-136-246.dsl.in-addr.zen.co.uk] has quit [Quit: Lost terminal] | 17:59 | |
pedroalvarez | gary_perkins: no as long that your manifest is also in the ct-trove-files folder | 18:00 |
pedroalvarez | sorry about the confusion | 18:00 |
gary_perkins | pedroalvarez: it is | 18:00 |
pedroalvarez | yo need to add:0040755 0 0 /root | 18:01 |
pedroalvarez | 0040755 0 0 /usr/lib | 18:01 |
gary_perkins | I had included root/.ssh directory too as an entry in the manifest, but that didn't work either | 18:01 |
gary_perkins | ahh /root! | 18:01 |
pedroalvarez | gary_perkins: oops, my paste is maybe wrong | 18:01 |
gary_perkins | ahh! so obvious! I'll try that. Thanks pedro | 18:01 |
pedroalvarez | gary_perkins: just to be clear: http://paste.baserock.org/axeqisigap | 18:02 |
gary_perkins | pedroalvarez: Ta :) | 18:02 |
pedroalvarez | np! :) | 18:02 |
*** mdunford [~marcdunfo@82-70-136-246.dsl.in-addr.zen.co.uk] has quit [Ping timeout: 255 seconds] | 18:05 | |
*** jonathanmaw [~jonathanm@host5-81-53-4.range5-81.btcentralplus.com] has joined #baserock | 18:06 | |
*** ssam2 [~ssam2@82-70-136-246.dsl.in-addr.zen.co.uk] has quit [Quit: Leaving] | 18:07 | |
*** kejiahu [~kejiahu@access.ducie-dc1.codethink.co.uk] has quit [Remote host closed the connection] | 18:15 | |
*** jmalk [~joshmalki@access.ducie-dc1.codethink.co.uk] has quit [Read error: Connection reset by peer] | 18:15 | |
*** mwilliams_ct [~mikewilli@access.ducie-dc1.codethink.co.uk] has quit [Read error: Connection reset by peer] | 18:15 | |
*** petefoth1 [~petefothe@access.ducie-dc1.codethink.co.uk] has quit [Read error: Connection reset by peer] | 18:15 | |
*** Zara_ [~zarazaime@access.ducie-dc1.codethink.co.uk] has quit [Read error: Connection reset by peer] | 18:15 | |
*** pdar [~patrickda@access.ducie-dc1.codethink.co.uk] has quit [Read error: Connection reset by peer] | 18:15 | |
*** wdutch [~yourname@access.ducie-dc1.codethink.co.uk] has quit [Read error: Connection reset by peer] | 18:15 | |
*** jmacs [~jimmacart@access.ducie-dc1.codethink.co.uk] has quit [Read error: Connection reset by peer] | 18:15 | |
*** paulsherwood [~paulsherw@access.ducie-dc1.codethink.co.uk] has quit [Read error: Connection reset by peer] | 18:15 | |
*** benbrown_ [~benbrown@access.ducie-dc1.codethink.co.uk] has quit [Read error: Connection reset by peer] | 18:15 | |
*** SotK [~adamcoldr@access.ducie-dc1.codethink.co.uk] has quit [Read error: Connection reset by peer] | 18:15 | |
*** bwh [~benhutchi@access.ducie-dc1.codethink.co.uk] has quit [Read error: Connection reset by peer] | 18:15 | |
*** DavePage [~dpage@access.ducie-dc1.codethink.co.uk] has quit [Read error: Connection reset by peer] | 18:15 | |
*** perryl [~laurenper@access.ducie-dc1.codethink.co.uk] has quit [Read error: Connection reset by peer] | 18:16 | |
*** grahamfinney_ [~grahamfin@cpc14-know11-2-0-cust234.know.cable.virginm.net] has quit [Quit: Ex-Chat] | 18:18 | |
straycat | o/ | 18:22 |
*** zarazaimeche [~zarazaime@access.ducie-dc1.codethink.co.uk] has joined #baserock | 18:23 | |
zarazaimeche is now known as Zara | 18:23 | |
*** perryl [~laurenper@access.ducie-dc1.codethink.co.uk] has joined #baserock | 18:24 | |
*** jmacs [~jimmacart@access.ducie-dc1.codethink.co.uk] has joined #baserock | 18:32 | |
*** kejiahu [~kejiahu@access.ducie-dc1.codethink.co.uk] has joined #baserock | 18:35 | |
*** locallycompact [~lc@82-70-136-246.dsl.in-addr.zen.co.uk] has quit [Ping timeout: 246 seconds] | 18:46 | |
*** petefoth [~petefoth@82-70-136-246.dsl.in-addr.zen.co.uk] has quit [Ping timeout: 256 seconds] | 18:58 | |
*** lachlanmackenzie [~lachlan@82-70-136-246.dsl.in-addr.zen.co.uk] has quit [Ping timeout: 240 seconds] | 19:26 | |
*** zoli__ [~zoli_@0x5e91887a.adsl.cybercity.dk] has joined #baserock | 20:03 | |
*** jonathanmaw [~jonathanm@host5-81-53-4.range5-81.btcentralplus.com] has quit [Quit: Leaving] | 20:15 | |
*** gary_perkins [~gary_perk@82-70-136-246.dsl.in-addr.zen.co.uk] has quit [Read error: Connection reset by peer] | 20:36 | |
*** petefotheringham [~petefothe@access.ducie-dc1.codethink.co.uk] has joined #baserock | 20:53 | |
*** rdale__ [~quassel@200.Red-83-47-16.dynamicIP.rima-tde.net] has joined #baserock | 20:57 | |
*** rdale_ [~quassel@81.Red-79-146-151.dynamicIP.rima-tde.net] has quit [Ping timeout: 256 seconds] | 20:59 | |
*** SotK [~adamcoldr@access.ducie-dc1.codethink.co.uk] has joined #baserock | 21:18 | |
*** SotK [~adamcoldr@access.ducie-dc1.codethink.co.uk] has quit [Client Quit] | 21:20 | |
*** SotK [~adamcoldr@access.ducie-dc1.codethink.co.uk] has joined #baserock | 21:26 | |
*** paulsherwood [~paulsherw@access.ducie-dc1.codethink.co.uk] has joined #baserock | 21:39 | |
*** paulsherwood [~paulsherw@access.ducie-dc1.codethink.co.uk] has quit [Client Quit] | 21:39 | |
*** zoli__ [~zoli_@0x5e91887a.adsl.cybercity.dk] has quit [Remote host closed the connection] | 22:55 | |
*** zoli__ [~zoli_@0x5e91887a.adsl.cybercity.dk] has joined #baserock | 23:16 |
Generated by irclog2html.py 2.15.3 by Marius Gedminas - find it at mg.pov.lt!