IRC logs for #baserock for Sunday, 2014-11-16

*** zoli_ [~zoli_@linaro/zoli] has joined #baserock06:40
*** zoli_ [~zoli_@linaro/zoli] has quit [Read error: Connection reset by peer]07:46
*** zoli_ [~zoli_@linaro/zoli] has joined #baserock08:22
*** zoli_ [~zoli_@linaro/zoli] has quit [Read error: Connection reset by peer]08:26
*** zoli_ [~zoli_@linaro/zoli] has joined #baserock08:26
*** zoli__ [] has joined #baserock08:44
*** zoli_ [~zoli_@linaro/zoli] has quit [Read error: Connection reset by peer]08:44
*** zoli_ [~zoli_@linaro/zoli] has joined #baserock08:57
*** zoli__ [] has quit [Read error: Connection reset by peer]08:57
*** zoli__ [] has joined #baserock08:59
*** zoli_ [~zoli_@linaro/zoli] has quit [Read error: Connection reset by peer]08:59
*** zoli_ [~zoli_@linaro/zoli] has joined #baserock09:16
*** zoli__ [] has quit [Ping timeout: 244 seconds]09:17
*** zoli_ [~zoli_@linaro/zoli] has quit [Read error: Connection reset by peer]09:28
*** zoli_ [~zoli_@linaro/zoli] has joined #baserock09:29
* paulsher1ood wonders if we really need to specify git repos based on trove_id etc. that means a separate repo in /src/cache/gits for each trove a user interacts with...09:29
paulsher1oodis there some git weirdness that makes it unsafe to have upstream:foo as /src/cache/gits/foo, always ?09:30
KinnisonIt's more to do with the potential for lost refs09:38
Kinnisone.g. trove1's upstream:foo may have refs not present in trove2's upstream:foo09:38
Kinnisonso fetching the latter might lose content needed from the former09:38
paulsher1oodonly if gc is run, or more generally?09:39
* paulsher1ood assumes that this can't happen in the normal case - i can have multiple remotes, pull from them all, and expect not to lose stuff09:40
KinnisonMore generally10:03
KinnisonWe use mirror pulls into the morph cache10:03
paulsher1oodcouldn't we do that first time, thereafter build on that?10:06
paulsher1oods/build on that/treat the mirror as our working base and do normal transactions on it/ ?10:07
KinnisonThe cache would quickly become overful of obsolete refs10:11
paulsher1oodare you sure?10:26
paulsher1oodis there no safe way to clean up?10:26
KinnisonThe point of the cache is to represent a copy of what is on the trove.  We could have a single git repo and use namespaces, that'd work but result in a much more complex single repo10:28
paulsher1ooddo you mean the code to do this would be more complex? i don't really believe that :-)10:29
KinnisonI'm glad you don't believe that10:30
KinnisonNow you can write a prototype10:30
paulsher1oodi already have :)10:30
paulsher1oodi just don't understand the deep foo here10:30
paulsher1oodso i'm checking my understanding10:30
paulsher1oodmy current dilemma is whether i really need to understand what is doing, or not10:31
KinnisonI see, I'm afraid I'm not off-the-top-of-my-head familiar with that and am currently engaged in writing a research program for an experimental javascript interpreter in NetSurf10:32
paulsher1oodno problem. your project sounds more fun :-)10:32
KinnisonCertainly less deep-voodoo10:32
paulsher1oodeasier question - is there any resistance to just specifying build-system: in each definition (alongside repo:, ref:), rather than having the magic of
paulsher1ood(apart from it being another flag day)10:38
KinnisonMostly that last time I suggested it, I got whinged at that it was yet another thing you had to do rather than letting morph work it out for you10:38
* Kinnison can't remember who it was who whinged though10:38
rjekhi straycat 13:30
straycathello rjek :)13:35
straycati've fixed our build commands so that the system arg can be relative to your cwd within the workspace, but i think we should add some yarns so that we avoid accidentally breaking this13:35
*** zoli_ [~zoli_@linaro/zoli] has quit [Remote host closed the connection]13:38
straycati also found a very minor bug along the way, we urlparse ssh urls and i don't think that works how the author expected it to, the result is that when you morph checkout say the dir in workspace is created as rather than To fix this we'd probably need to start using a giturlparser or write one, I'm not sure it's worth worrying about though13:39
*** zoli_ [~zoli_@linaro/zoli] has joined #baserock13:39
straycati'll go spin some yarns now and maybe eventually get onto what i actually had planned for this weekend >.>13:40
* straycat discovers the tests that exist already cover this and are failing14:10
straycati must be wrong14:12
paulsher1oodKinnison: might have been me :-)14:18
straycatokay good i was wrong >.>14:20
KinnisonI think morph should detect the use of shonky rsync-style URIs and explode, deleting everything in /dev14:29
* Kinnison is slightly opinionated in this though14:29
*** zoli_ [~zoli_@linaro/zoli] has quit [Ping timeout: 265 seconds]14:37
straycat00h10m42s 376/501: partially deploying a cluster morphology: THEN morph failed     is this normal?15:42
KinnisonOut of disk in your TMPDIR ?15:42
straycatnot likely I'm using /src/tmp as my tmpdir15:43
straycatwow, it took nearly 15 minutes to run those tests15:47
*** zoli_ [~zoli_@linaro/zoli] has joined #baserock17:52
*** zoli_ [~zoli_@linaro/zoli] has quit [Remote host closed the connection]18:23
*** zoli_ [~zoli_@linaro/zoli] has joined #baserock19:00
*** zoli_ [~zoli_@linaro/zoli] has quit [Read error: Connection reset by peer]19:07
*** zoli__ [] has joined #baserock19:07
*** cosm [] has quit [Ping timeout: 240 seconds]19:45
*** cosm [] has joined #baserock19:58
*** cosm [] has quit [Read error: Connection reset by peer]21:35
*** zoli__ [] has quit [Remote host closed the connection]21:41
*** cosm [] has joined #baserock21:53
*** JPohlmann [~jannis@xfce/core-developer/JPohlmann] has quit [Ping timeout: 255 seconds]23:48

Generated by 2.15.3 by Marius Gedminas - find it at!