| *** petefoth has quit IRC | 05:14 | |
| *** petefoth has joined #baserock | 06:25 | |
| *** paulw has joined #baserock | 06:26 | |
| *** petefoth has quit IRC | 06:39 | |
| *** petefoth has joined #baserock | 06:40 | |
| paulsherwood | nowster: yup - each sandbox is a tmp directory created (with symlinks) specifically for each command | 07:01 |
|---|---|---|
| paulsherwood | nowster: there's a known problem with the linux-user-chroot, where BIND can fail because another instance's sandbox gets deleted between listing things to bind and doing it | 07:07 |
| paulsherwood | (so by default i'm ignoring linux-user-chroot on systems where i run ybd) | 07:07 |
| paulsherwood | (until i find a fix) | 07:14 |
| paulsherwood | nowster: here's another fail log - stage1-gcc this time http://sprunge.us/BbcN | 07:21 |
| paulsherwood | pedroalvarez: shouldn't those notes mention the genivi baseline? | 07:25 |
| *** jonathanmaw has joined #baserock | 08:00 | |
| *** bashrc has joined #baserock | 08:09 | |
| pedroalvarez | paulsherwood: probably | 08:14 |
| *** bashrc has quit IRC | 08:21 | |
| pedroalvarez | done | 08:24 |
| *** bashrc has joined #baserock | 08:30 | |
| paulsherwood | :) | 08:32 |
| *** bashrc has quit IRC | 08:33 | |
| pedroalvarez | If it weren't for the GENIVI manifests, the release process would be really easy. Less than 10 minutes of my time (not including the release notes) | 08:36 |
| paulsherwood | interesting. what is so hard about the GENIVI manifests? | 08:38 |
| *** bashrc has joined #baserock | 08:43 | |
| pedroalvarez | actually you are right, I guess I'm just disappointed I still need to create a workspace to be able to generate one of them | 08:43 |
| paulsherwood | pedroalvarez: presumably your time excludes the build time? | 08:43 |
| pedroalvarez | it does | 08:44 |
| *** ssam2 has joined #baserock | 08:44 | |
| *** ChanServ sets mode: +v ssam2 | 08:44 | |
| pedroalvarez | I hope `morph edit` still works, or that we have replace its use for something else when generating the manifests | 08:44 |
| paulsherwood | pedroalvarez: which script generates manifests? easiest would be to fix that, i assume? | 08:45 |
| pedroalvarez | scirpts/licensecheck.sh | 08:45 |
| pedroalvarez | it might be easy to replace with the get-repo command | 08:47 |
| paulsherwood | what is the get-repo command? | 08:47 |
| SotK | you could use `morph get-repo` if `morph edit` doesn't work | 08:47 |
| * paulsherwood would like to use ybd, and be done | 08:47 | |
| SotK | heh, you beat me to it | 08:47 |
| pedroalvarez | I assume it still works, but it might be about to dead | 08:48 |
| pedroalvarez | to die* | 08:48 |
| pedroalvarez | actually, this is one of the things that remains morph specific in definitions | 08:49 |
| pedroalvarez | well, I guess the entire release process | 08:50 |
| * paulsherwood wonders why git blame shows no lines of scirpts/licensecheck.sh written by paulsherwood, yet he has strange memories of writing it or something extremely similar | 08:50 | |
| pedroalvarez | I guess it will show you the commit when we moved it to the scripts/ folder | 08:51 |
| paulsherwood | so i'm pretty sure i can make it not require anything of morph | 08:52 |
| pedroalvarez | hahah I knew you would feel challenged after my comments | 08:53 |
| paulsherwood | lol | 08:53 |
| *** wschaller has joined #baserock | 09:16 | |
| *** paulw has quit IRC | 09:18 | |
| *** paulw has joined #baserock | 09:20 | |
| *** lmackenzie_2015 has joined #baserock | 09:22 | |
| *** paulw has quit IRC | 09:45 | |
| nowster | paulsherwood: that fail is a binutils one, I think | 09:45 |
| nowster | paulsherwood: try running without parallelism | 09:45 |
| *** paulw has joined #baserock | 09:47 | |
| paulsherwood | nowster: i know it works without parallelism. some also work *with* paralellism. the question is why it occasionally fails. stage1-gcc explicitly depends on stage1-binutils, so that should be present in its staging area, parallel or no? | 09:53 |
| nowster | maybe it's disappearing | 09:53 |
| paulsherwood | nowster: /win 53 | 09:54 |
| paulsherwood | bah! | 09:55 |
| nowster | I think it's not good that there are multiple parallel builds happening of binutils, all making the same asset. | 09:55 |
| nowster | You may be setting yourself up for a race condition. | 09:55 |
| paulsherwood | they are all making it in different places | 09:55 |
| paulsherwood | it's *supposed* to race | 09:55 |
| paulsherwood | but clearly there's something going wrong ;) | 09:55 |
| nowster | and are multiple gcc builds happening too? | 09:56 |
| paulsherwood | yup | 09:56 |
| paulsherwood | until there's enough scope for each to find something different from the others | 09:56 |
| nowster | so you don't know whether one was succeeding when one failed... | 09:57 |
| paulsherwood | i do... they all get logged | 09:57 |
| nowster | so did they all fail the same way? | 09:57 |
| paulsherwood | no, only one failed, afaict | 09:57 |
| nowster | so, why are you stopping? | 09:58 |
| nowster | Have you worked out what's different in the environment of the failed gcc compared with a single task build? | 09:59 |
| paulsherwood | you mean why does the instance hardstop? because it's a build fail that should not happen | 09:59 |
| paulsherwood | no - i was hoping for a clue from someone who actually understood make/gcc/autotools, hence this conversation :) | 09:59 |
| nowster | "configure: error: cannot compute suffix of object files: cannot compile" is a linker not found bug. | 10:00 |
| paulsherwood | and the linker we are expecting to use should be in stage1-binutils? | 10:01 |
| nowster | yes | 10:02 |
| paulsherwood | ok, i need to look harder on that basis | 10:03 |
| nowster | it would normally be in /tools/bin/ld at that point | 10:04 |
| nowster | named according to the pattern /tools/bin/$ARCH-bootstrap-linux-$ABI-ld | 10:05 |
| nowster | and even /tools/$ARCH-bootstrap-linux-$ABI/bin/ld | 10:06 |
| paulsherwood | ok | 10:06 |
| nowster | Is there *any* possibility that two copies of the gcc build might be making the "unpacked" artifact at the same time? | 10:08 |
| paulsherwood | hmmm... actually, yes. the artifact should be unpacked when it's created (before the os.rename(tmpdir, target) not when something realises it's not unpacked) | 10:11 |
| paulsherwood | good spot | 10:12 |
| *** wschaller has quit IRC | 10:17 | |
| paulsherwood | nowster: are ybd system meta files expected to be only repo: null, ref: null | 10:29 |
| *** wschaller has joined #baserock | 10:29 | |
| nowster | yes | 10:31 |
| nowster | ...as that's what they've always been | 10:31 |
| paulsherwood | ok great :) | 10:31 |
| * paulsherwood has done pep8 | 10:31 | |
| nowster | paulsherwood: have you got a tool for that? | 10:33 |
| * nowster is pleased how few tweaks were needed | 10:34 | |
| paulsherwood | nowster: i am the tool for that :) | 10:35 |
| paulsherwood | nowster: by which i mean, i just run pep8 *py, edit stuff and run pep8 again until it goes silent | 10:51 |
| nowster | ah | 10:51 |
| nowster | aha! | 10:51 |
| paulsherwood | ? | 10:51 |
| nowster | I hadn't realised there was a tool with that name. | 10:51 |
| paulsherwood | there isn't in baserock... i run it from my host on an sshfs | 10:52 |
| nowster | I've also found flake8 | 10:53 |
| *** petefoth has quit IRC | 10:53 | |
| ssam2 | you might like autopep8, which supposedly fixes things automatically | 10:54 |
| ssam2 | never tried it though | 10:54 |
| ssam2 | I use whatever one Vim python mode comes with | 10:54 |
| nowster | paulsherwood: http://paste.baserock.org/eliwovecib | 10:54 |
| paulsherwood | ooh.. .what's that from nowster ? | 10:59 |
| nowster | flake8 (and a newer pep8 program) | 11:00 |
| nowster | https://gitlab.com/pycqa/flake8 | 11:00 |
| nowster | paulsherwood: after the fixes I've just requested, it leaves http://paste.baserock.org/ezehefotag, which may need further investigation rather than a blind fix | 11:15 |
| *** wschaller has quit IRC | 11:30 | |
| paulsherwood | nowster: great, thanks | 11:53 |
| paulsherwood | nowster: looks like your unpacked spot idea is correct | 11:54 |
| nowster | aha! | 11:55 |
| ssam2 | it seems that it's possible to run BitBake builds outside of BitBake. | 11:57 |
| ssam2 | ah! I knew it would fail once i talked about it. | 11:57 |
| ssam2 | I think the build failure I just hit is one I saw when running *in* BitBake, too, though | 11:57 |
| ssam2 | and it got thru about 20 packages before breaking, anyway | 11:58 |
| paulsherwood | ssam2: that *must* be a w00t | 11:58 |
| * pedroalvarez is amazed | 11:58 | |
| ssam2 | there's about 2.5GB of generated shell + Python code. But most of that is just a dump of all the variables in the gigantic 'data' dict that BitBake keeps | 12:01 |
| ssam2 | one dump per task | 12:01 |
| ssam2 | i think it's certainly going to be possible to convert them to a format which is nice to browse thru and see what configure flags are used, etc. | 12:01 |
| ssam2 | converting them to actually usable Baserock definitions would be /much/ more of a stretch, but we can see, anyway :) | 12:02 |
| paulsherwood | so do they go for an over-arching dict, similarly to ybd? | 12:03 |
| ssam2 | I wouldn't really compare it to YBD | 12:03 |
| ssam2 | it's more like Automake | 12:03 |
| paulsherwood | oh? pls elaborate... | 12:04 |
| ssam2 | there's an 'environment' in which recipes run, basically | 12:04 |
| ssam2 | which has all these variables set | 12:04 |
| ssam2 | and the recipes can also change the environment | 12:04 |
| ssam2 | and the variables can expand to other variables, or expand to Python code, which is great | 12:05 |
| ssam2 | so it feels quite like 'make'. I think YBD is far less flexible than that | 12:06 |
| ssam2 | but with flexibility comes incredible complexity :) | 12:06 |
| paulsherwood | nowster: did you test your more pep8? | 12:08 |
| nowster | I'll do so now. | 12:08 |
| * paulsherwood merged it, but has seen odd behaviour since | 12:09 | |
| pedroalvarez | random thought: you can add this check in a Travis CI job | 12:11 |
| nowster | paulsherwood: such as? | 12:11 |
| paulsherwood | i've lost my paste, now sorry | 12:12 |
| paulsherwood | it failed fast on something to do with gitdirs i think | 12:12 |
| paulsherwood | nowster: http://paste.baserock.org/ihififupoy | 12:14 |
| * nowster tests | 12:15 | |
| paulsherwood | this is running on clusters/ci.morph | 12:16 |
| SotK | transl(x) doesn't appear to return anything | 12:17 |
| nowster | paulsherwood: usually the fault is a good few lines before where you started that paste | 12:18 |
| paulsherwood | nowster: there's nothing above that but normal log? | 12:19 |
| paulsherwood | http://paste.baserock.org/eqididusif | 12:19 |
| nowster | I can reproduce | 12:20 |
| nowster | try this: http://paste.baserock.org/unewupikic | 12:22 |
| * nowster blushes | 12:22 | |
| paulsherwood | lol | 12:22 |
| nowster | that fixed it | 12:24 |
| * paulsherwood looks forward to a pr :) | 12:24 | |
| *** wschaller has joined #baserock | 12:26 | |
| nowster | paulsherwood: sent | 12:28 |
| paulsherwood | tvm | 12:28 |
| paulsherwood | nowster: what is a brown paper bag bug? :() | 12:29 |
| nowster | one that makes you want to sit in a corner with a brown paper bag on your head | 12:30 |
| nowster | Linus uses the term a lot. | 12:30 |
| paulsherwood | aha :) | 12:31 |
| paulsherwood | thanks for the patches, anyway... you're rapidly becoming a key contributor | 12:31 |
| pedroalvarez | I've documented a bit my failure trying to convert nixos expressions to something usable by baserock: http://wiki.baserock.org/projects/importing-from-nixos/ | 12:37 |
| paulsherwood | pedroalvarez: thanks! | 12:39 |
| nowster | paulsherwood: http://www.catb.org/jargon/html/B/brown-paper-bag-bug.html | 12:43 |
| pedroalvarez | paulsherwood: we haven't looked at debian/germinate yet | 12:44 |
| pedroalvarez | that one would be interesting | 12:44 |
| paulsherwood | ack | 12:45 |
| pedroalvarez | I've always found similarities between baserock definitions and debian's equivalent | 12:45 |
| pedroalvarez | same with fedora | 12:46 |
| nowster | debian's are a little more spread out | 12:47 |
| paulsherwood | yup, but germinate seems to do magic | 12:47 |
| nowster | Interesting. I wasn't aware of germinate before. | 12:48 |
| nowster | Oh dear! Written by Scott and Colin. :) | 12:49 |
| *** paulw has quit IRC | 12:52 | |
| *** paulw has joined #baserock | 13:01 | |
| pedroalvarez | Genivi release notes draft: http://paste.baserock.org/upuzumefis | 13:40 |
| pedroalvarez | Brief, but I don't have more to say | 13:40 |
| paulsherwood | pedroalvarez: looks good to me | 13:41 |
| pedroalvarez | good | 13:41 |
| pedroalvarez | I'm going to send the emails soon | 13:42 |
| SotK | pedroalvarez: looks fine to me too | 13:42 |
| * pedroalvarez sends the emails | 13:51 | |
| pedroalvarez | Any with powers to moderate baserock-announce? | 13:51 |
| ssam2 | you don't have them? i'll see if I can give you them :) | 13:51 |
| pedroalvarez | please, I should :) | 13:52 |
| pedroalvarez | **Baserock 15.34 is released!** | 13:56 |
| SotK | \o/ | 13:56 |
| ssam2 | nice work! | 13:57 |
| pedroalvarez | I'm tempted to remove any mention of workspaces in the wiki | 13:57 |
| ssam2 | That's a really good idea | 13:58 |
| SotK | +1 | 13:58 |
| ssam2 | I think documentation is the main thing blocking us removing the commands from Morph | 13:59 |
| ssam2 | although I still like the idea of us having some sort of workflow helper tool' | 13:59 |
| radiofree | pedroalvarez: "Baserock 15.34 (Kronos K-0.2) is released" | 14:01 |
| radiofree | Baserock 15.34 is our Kronos K-0.1-compliant release of the Baserock GENIVI baseline. | 14:01 |
| radiofree | s/K-0.1/K-0.2/ | 14:01 |
| radiofree | ? | 14:01 |
| paulsherwood | probably | 14:01 |
| pedroalvarez | I know :/ | 14:02 |
| * pedroalvarez updates the version of morph in Mason(s) | 14:15 | |
| jjardon | \o/ | 14:19 |
| jjardon | ssam2: version 6 coming? | 14:19 |
| jjardon | mmm, morph is trying to build binutils instead using the mason cache, anyone more with the same problem? | 14:20 |
| ssam2 | jjardon: we can use version 6 now in master of definitions.git, yeah | 14:20 |
| ssam2 | jjardon: which means we can delete a bunch of code from Morph too | 14:21 |
| * jjardon likes deleting code | 14:21 | |
| * jjardon notices v7 is waiting in gerrit too | 14:22 | |
| pedroalvarez | jjardon: the cache-key of everything changed recently | 14:23 |
| pedroalvarez | there is no cache for latest morph, that's why I just updated the version of Morph in Mason(s) | 14:23 |
| paulsherwood | v7 has some bugs, if i remember rightly | 14:24 |
| jjardon | pedroalvarez: ah, ok, thanks | 14:28 |
| ssam2 | v7 is still a proposal on the mailing list. I think only Paul has responded so far | 14:30 |
| ssam2 | the implementation I proposed for YBD might well have some bugs, too | 14:30 |
| paulsherwood | ssam2: v7 being defaults? (sorry i'm in other conversations... can't google enough) | 14:31 |
| pedroalvarez | yes | 14:35 |
| pedroalvarez | maybe something else | 14:35 |
| paulsherwood | ybd has implemented defaults | 14:35 |
| ssam2 | oh, cool | 14:35 |
| ssam2 | if we want the Baserock definitions format to make sense independently of the tooling, we need to think about it independently of the tooling. right now we are talking about specific implementations, again | 14:36 |
| paulsherwood | ssam2: it was implemented based on your proposal... but there were bugs, is all. it will use defaults in definitions, if/when they are there | 14:38 |
| paulsherwood | (i was only replying to your comment) | 14:38 |
| ssam2 | nice! But of course there are no bugs in my proposal :-) | 14:38 |
| jjardon | paulsherwood: what was the URL to that online service with a massive amount of CPU avaialble? | 14:38 |
| paulsherwood | aws? | 14:39 |
| pedroalvarez | hahaha | 14:39 |
| jjardon | that one, thanks | 14:40 |
| paulsherwood | ssam2: https://github.com/devcurmudgeon/ybd/blob/master/config/defaults.conf | 14:45 |
| paulsherwood | i'll try to reply to your email with what additions/changes happened vs your original | 14:46 |
| paulsherwood | (i needed indicators, for example... for backwards compatibility) | 14:46 |
| paulsherwood | and i think python install-commands needed to be - python setup.py install --prefix "$PREFIX" --root "$DESTDIR" | 14:47 |
| pdar | are the artifacts for the release not cached yet? | 14:48 |
| * pdar wonders if that sentence means what he thinks... | 14:48 | |
| paulsherwood | ssam2: note the split-rules are there too | 14:49 |
| ssam2 | pdar: pedro would know, but he has just left! | 14:50 |
| ssam2 | the artifacts are very likely to be in cache.baserock.org already | 14:50 |
| ssam2 | they need to be manually uploaded to git.baserock.org for each release, I don't know if that's been done or not | 14:50 |
| ssam2 | paulsherwood: oh yeah, I guess if you don't want to remove build-system autodetection then you need the indicators still | 14:51 |
| pdar | ha, alas. I asked cos I just started bulding stuff quite early on. | 14:52 |
| pdar | thanks ssam2 | 14:53 |
| ssam2 | why do you think that about python install-commands? have you seen the previous defaults (`python setup.py install`) failing to work correctly? | 14:53 |
| paulsherwood | ssam2: i believe nowster hit that | 14:53 |
| paulsherwood | nowster: ^^? | 14:53 |
| ssam2 | right. It makes sense, it just would surprise me if they were broken for 4 years and nobody realised | 14:53 |
| nowster | ? | 14:54 |
| paulsherwood | can you recall anything about defauly python install commands? | 14:54 |
| nowster | Something didn't work. | 14:54 |
| paulsherwood | :) | 14:54 |
| nowster | I have a script: | 14:55 |
| nowster | #!/bin/sh | 14:55 |
| nowster | XDG_CACHE_HOME=/src/cache PYTHONPATH=/src/src/sandboxlib /src/ybd/ybd.py $@ | 14:55 |
| *** wschaller has quit IRC | 14:55 | |
| nowster | because I couldn't get sandboxlib to install | 14:55 |
| *** wschaller has joined #baserock | 15:10 | |
| *** CTtpollard has quit IRC | 15:35 | |
| *** wschaller has quit IRC | 16:16 | |
| *** jonathanmaw has quit IRC | 16:17 | |
| paulsherwood | hmmm.... ybd has started reporting 'sh: update-ca-certificates: not found' | 16:31 |
| paulsherwood | nowster: sorry to bug you with this, but did you do anything that could have affected system-integration commands? | 16:33 |
| nowster | No, I don't think so. | 16:34 |
| nowster | They weren't running. | 16:34 |
| paulsherwood | where is updat-ca-certificates now?? | 16:40 |
| jjardon | strata/core/ca-certificates.morph says /sbin/update-ca-certificates | 16:49 |
| jjardon | paulsherwood: ^ | 16:49 |
| paulsherwood | yup, thanks | 16:49 |
| paulsherwood | my error is 15-08-21 14:06:15 [156/568/662] [genivi-baseline-system-x86_64-generic] ERROR: command failed in directory /src/workspace/reference/baserock/baserock/definitions: | 16:50 |
| paulsherwood | i wonder why it's there, rather than in a sandbox | 16:51 |
| ssam2 | system-integration commands | 16:52 |
| ssam2 | I think they are sandboxed differently | 16:52 |
| ssam2 | (I can't remember what Morph does, I think it's different to how it runs chunk build commands, though) | 16:52 |
| paulsherwood | nowster: pretty sure git bisect will point me to... *you* :) | 16:56 |
| nowster | :P | 16:57 |
| *** bashrc has quit IRC | 16:57 | |
| paulsherwood | fa38c448388d45fd020b1f556983593a4da984f4 | 16:58 |
| nowster | neither morph nor ybd were running the integration commands for minimal-system-* | 16:59 |
| paulsherwood | ok, but for other systems | 16:59 |
| paulsherwood | i think somehow cwd is different | 17:00 |
| nowster | odd. I can't find where this['install-commands'] gets called | 17:01 |
| jjardon | mmm, seems the cache is still not available, morph is still trying to build binutils here | 17:04 |
| paulsherwood | nowster: it's a system-integration command... http://git.baserock.org/cgi-bin/cgit.cgi/baserock/baserock/definitions.git/tree/strata/core/ca-certificates.morph#n20 | 17:05 |
| ssam2 | jjardon: what is your artifact-cache-server variable set to? git.baserock.org:8080 or cache.baserock.org:8080 ? | 17:05 |
| nowster | paulsherwood: what calls the install-commands? | 17:05 |
| ssam2 | oh, https://mason-x86-64.baserock.org/current.log shows that it's only just starting building binutils | 17:06 |
| ssam2 | makes me wonder how pedroalvarez did the release though | 17:06 |
| paulsherwood | nowster: l205 of assembly.py stuffs them into 'install-commnands' for the system | 17:06 |
| nowster | yes, but what calls the install-commands? | 17:07 |
| ssam2 | actually the release commit is 6cb639983 which is showing as built on https://mason-x86-64.baserock.org/ | 17:07 |
| paulsherwood | nowster: not sure. never mind, i'll figure it out | 17:08 |
| nowster | paulsherwood: it's most likely to have been broken by the shuffling of the default build-system stuff around | 17:09 |
| jjardon | ssam2: http://cache.baserock.org:8080/ | 17:10 |
| paulsherwood | nowster: i doubt it. bisect shows it's definitely that patch | 17:10 |
| paulsherwood | (i think. it's technically past beer o'clock here, my brain may be underperforming :) | 17:12 |
| ssam2 | jjardon: ok. and are you definitely building the release tag, or 'master' ? | 17:15 |
| ssam2 | here is notes from my digging into BitBake: http://wiki.baserock.org/projects/importing-from-bitbake/ | 17:15 |
| ssam2 | *here are notes | 17:15 |
| nowster | paulsherwood: you're not using linux-user-chroot? | 17:16 |
| jjardon | ssam2: I tried with both with the same result: [Build 1/278] [stage1-binutils] | 17:19 |
| ssam2 | some artifacts in /home/cache/artifacts on cache.baserock.org were owned by 'root' instead of 'cache' | 17:24 |
| ssam2 | that often breaks things | 17:24 |
| ssam2 | i'm changing them now | 17:25 |
| ssam2 | ok, try now. I think it will be fixed | 17:25 |
| ssam2 | 01b04620275d829d187b6c7023903897100e7be248f45718355554919164fea3.chunk.binutils-bins definitely exists in the cache, anyway | 17:25 |
| paulsherwood | nowster: not for multi-instance, no | 17:26 |
| paulsherwood | well, actually s/not for multi-instance, // (since i moved it out of my path) | 17:26 |
| jjardon | ssam2: it worked, thanks! | 17:31 |
| nowster | paulsherwood: is ca-certificates actually used by the system you're building, or is it just part of the build-deps of something? | 17:35 |
| nowster | I can see that if it is excluded from the final tarball it shouldn't be running its system-integration commands. | 17:36 |
| nowster | ...and the chdir/chroot will fail, possibly silently | 17:36 |
| paulsherwood | nowster: i'm building genivi-baseline-x86_64 - it includes core, so the si command gets run at system artifact creation time | 17:37 |
| paulsherwood | http://paste.baserock.org/wukaxaquhu | 17:37 |
| nowster | what's in the artifact metadata for ca-certificates*.meta? | 17:40 |
| paulsherwood | http://paste.baserock.org/vumozizoxe | 17:41 |
| nowster | identical to mine | 17:42 |
| nowster | very odd | 17:45 |
| nowster | Anyway, I'm off for the next week. Have fun. :) | 17:45 |
| paulsherwood | key is in the error message... | 17:45 |
| paulsherwood | ERROR: command failed in directory /src/workspace/reference/baserock/baserock/definitions | 17:45 |
| paulsherwood | we shouldn't be in that directory when we run it | 17:45 |
| paulsherwood | enjoy your weekend | 17:45 |
| paulsherwood | :-) | 17:45 |
| *** ssam2 has quit IRC | 17:51 | |
| *** lmackenzie_2015 has quit IRC | 18:22 | |
| *** mdunford has quit IRC | 18:28 | |
| *** petefoth has joined #baserock | 18:49 | |
| *** petefoth has quit IRC | 18:55 | |
| *** kejiahu has quit IRC | 19:37 | |
Generated by irclog2html.py 2.15.3 by Marius Gedminas - find it at mg.pov.lt!