| *** cosm_ has joined #baserock | 00:30 | |
| *** cosm has quit IRC | 00:33 | |
| *** toscalix has joined #baserock | 07:44 | |
| *** fay_ has joined #baserock | 08:33 | |
| *** ctbruce has joined #baserock | 08:57 | |
| *** paulw has joined #baserock | 09:00 | |
| *** bashrc has joined #baserock | 09:04 | |
| *** rdale has joined #baserock | 09:16 | |
| *** CTtpollard has joined #baserock | 09:29 | |
| *** jonathanmaw has joined #baserock | 09:34 | |
| *** paulw has joined #baserock | 09:41 | |
| *** ssam2 has joined #baserock | 09:46 | |
| *** ChanServ sets mode: +v ssam2 | 09:46 | |
| *** ctbruce has quit IRC | 09:52 | |
| paulsherwood | YBD 16.06 is released | 09:54 |
|---|---|---|
| * pedroalvarez_ claps | 09:58 | |
| *** pedroalvarez_ is now known as pedroalvarez | 09:58 | |
| *** edcragg has joined #baserock | 10:09 | |
| *** paulw has quit IRC | 10:10 | |
| paulsherwood | lol | 10:37 |
| *** Lachlan1975 has joined #baserock | 10:39 | |
| *** Lachlan1975 has quit IRC | 10:50 | |
| *** ctbruce has joined #baserock | 10:56 | |
| *** paulw has joined #baserock | 11:00 | |
| *** gtristan has joined #baserock | 11:16 | |
| *** Lachlan1975 has joined #baserock | 11:17 | |
| pedroalvarez | richard_maw: am i right thinking that all of these tasks have been completed? https://storyboard.baserock.org/#!/story/47 | 11:24 |
| richard_maw | pedroalvarez: sadly, no. | 11:26 |
| richard_maw | pedroalvarez: IIRC the moving debug artifacts to not be included by default isn't done | 11:27 |
| pedroalvarez | and everything else is | 11:27 |
| richard_maw | and default split rules haven't been moved to the build system definitions | 11:27 |
| richard_maw | AIUI they are both moved to definitions, but not in the way specified as part of the story | 11:28 |
| pedroalvarez | I see | 11:28 |
| richard_maw | IIRC there was some more tooling work required to be able to have a "not included by default" flag for split rules | 11:29 |
| * richard_maw has marked the bits he believes to be done as merged | 11:29 | |
| pedroalvarez | good, thanks! | 11:30 |
| * richard_maw tries to remember what he was doing before taking a trip down memory lane | 11:31 | |
| pedroalvarez | apologies | 11:32 |
| richard_maw | no worries | 11:32 |
| richard_maw | in the absence of a proper hand-off a couple of minutes here and there is fine | 11:32 |
| richard_maw | it's pretty much why I'm still in #baserock after running out of bandwidth to contribute more usefully | 11:33 |
| perryl | paulsherwood: is there anything that specifies that ybd must be ran from definitions or a directory containing it? i've noticed that the stage1-gcc `C compiler cannot create executable` error persists when running ybd on a morphology when the CWD is neither definitions or a directory the next level up | 11:42 |
| rdale | it has some file operations that assume ybd is being run from the top level of definitions | 11:43 |
| *** paulw has quit IRC | 11:45 | |
| perryl | i'm assuming that patch 92727a5 requires that, yes, though i'm not sure which other file operations assume that. i would suggest a pull request that finds definitions from the path argument given on the commandline, but that wouldn't work for running `./ybd.py gcc x86_64`, amongst other things | 11:46 |
| paulsherwood | i don't know how to solve this... if the definitions directory is called foo, and we're runnning an arbitrary number of levels above it, ybd can't divine where foo is by magic :) | 11:49 |
| perryl | indeed, i was just curious if it was specified anywhere :) | 11:50 |
| *** ctbruce has quit IRC | 11:51 | |
| *** ctbruce has joined #baserock | 11:57 | |
| ssam2 | morph solves this by requiring the top level dir to be a .git repo | 12:01 |
| ssam2 | which also isn't ideal, of course | 12:01 |
| ssam2 | but in practice i've never wished that it didn't require the definitions to be a .git repo, so far | 12:02 |
| *** locallycompact has joined #baserock | 12:03 | |
| rdale | i would like ybd and morph to allow a system to be built from definitions in more than one git repo, otherwise the entire world is expected to be in a single definitions repo which imho doesn't scale | 12:13 |
| pedroalvarez | I believe that was possible a while ago... | 12:16 |
| pedroalvarez | to point to strata in different repos | 12:17 |
| locallycompact | Has anyone tried go in baserock? It's on g.b.o but not in definitions. | 12:24 |
| ssam2 | paulsherwood tried it ages ago, which I think was back when it could be bootstrapped from C | 12:33 |
| ssam2 | which worked fine, but I think now it needs to be bootstrapped from Go | 12:34 |
| ssam2 | rdale: we used to have that and it was horrible! I think it does scale.. | 12:34 |
| ssam2 | e.g. Gentoo more or less works that way | 12:34 |
| paulsherwood | rdale: all in one repo does scale. no doubt in my mind on this point | 12:36 |
| locallycompact | something in ansible on g.b.o is wrong | 12:37 |
| paulsherwood | i'd go so far as to say all in one *branch* in one repo, covering many variants of many systems, | 12:37 |
| locallycompact | git clone http://git.baserock.org/git/delta/ansible.git | 12:37 |
| locallycompact | warning: remote HEAD refers to nonexistent ref, unable to checkout. | 12:38 |
| rdale | fair enough - when doing a codethink internal system though, i didn't like have to clone the entire definitions repo to maintain just a couple of baserock systems | 12:38 |
| ssam2 | locallycompact: ansible don't have a master branch | 12:39 |
| locallycompact | oh | 12:39 |
| paulsherwood | rdale: definitions is not such a large repo. but in any case, if you want to base a system off the default definitions, and track updates to the default definitions, i think cloning the repo is an acceptable price | 12:40 |
| rdale | maybe - i would be happier if ybd and morph didn't read in every definition before starting to build what i actually want to build - i don't want to see warnings about zookeeper or whatever every time i am building something totally unrelated | 12:42 |
| richard_maw | to weigh in on the topic of finding the "root" directory of a definitions repo, you could look for the DEFAULTS file | 12:43 |
| paulsherwood | richard_maw: ybd does that, but it's not always present in old definitions :) | 12:43 |
| richard_maw | paulsherwood: fair enough | 12:44 |
| paulsherwood | to be clear, iiuc perryl's case is where ybd is run *accidentally on purpose* somewhere *above* definitions | 12:44 |
| paulsherwood | s/on/ or on/ | 12:44 |
| perryl | indeed; in this case i was running from the ybd directory, with definitions and ybd both having the same parent | 12:45 |
| paulsherwood | ack | 12:45 |
| richard_maw | paulsherwood: but the file path of the definition to build is pointing to the file in the repository yes? | 12:45 |
| richard_maw | in which case if it had a DEFAULTS file, you could locate the root starting from the definition file, rather than going up from cwd | 12:46 |
| *** ctbruce has quit IRC | 12:47 | |
| *** ctbruce has joined #baserock | 13:02 | |
| *** Lachlan1975 has quit IRC | 13:05 | |
| paulsherwood | richard_maw: ybd supports 'ybd gcc x86_64' for example... | 13:12 |
| richard_maw | ah, so this is more data to suggest we should require file paths then | 13:13 |
| paulsherwood | yup, i think so | 13:14 |
| * paulsherwood will think more on this - i'm guessing just fixing for perryl's specific use-case would be good enough to make the problem undetectable for a long time :) | 13:16 | |
| richard_maw | an alternative to probing for the "top" of the definitions would be to specify all the definitions as relative file paths | 13:17 |
| paulsherwood | richard_maw: how? perryl's use-case is either user-error or environmental (eg Concourse is running a shell in an unexpected place) | 13:19 |
| paulsherwood | (iiuc) | 13:19 |
| richard_maw | oh, you'd still need to be able to specify a file path to the definition to build, but if paths in that definition were relative to that definition, you wouldn't need to work out where the "top" of the definitions is to resolve the paths for the other definitions | 13:20 |
| paulsherwood | i thought paths are already that way? | 13:23 |
| paulsherwood | eg morph: strata/armv7lhf-cross-toolchain/armv7lhf-cross-binutils.morph | 13:23 |
| paulsherwood | sorry, i may be being dumb, here | 13:24 |
| richard_maw | the paths are all relative to the top of the repo, rather than each other | 13:24 |
| paulsherwood | oh, i see what you mean | 13:24 |
| richard_maw | i.e. you could instead have in systems/foo.morph `morph: ../strata/armv7lhf-cross-toolchain/armv7lhf-cross-binutils.morph` | 13:24 |
| * paulsherwood wonders how to debug a cherrypy server... artifacts1.baserock.org keeps disappearing | 13:35 | |
| *** cosm_ has quit IRC | 13:53 | |
| *** cosm_ has joined #baserock | 14:07 | |
| *** Lachlan1975 has joined #baserock | 14:21 | |
| *** cosm_ has quit IRC | 14:24 | |
| locallycompact | what is ydb telling me here https://paste.fedoraproject.org/319887/94202814/ | 14:34 |
| radiofree | locallycompact: does /lib/modules exist? | 14:36 |
| radiofree | and/or depmod | 14:36 |
| locallycompact | /lib/modules exists | 14:37 |
| locallycompact | depmod too | 14:37 |
| radiofree | could you pastebin /src/artifacts/minimal-system-x86_64-generic.57782890a60b72bea336ecb1a1105efea8da233e492437f5ef91b9d43d20141c.build-log | 14:37 |
| locallycompact | https://paste.fedoraproject.org/319889/14549422/ | 14:38 |
| paulsherwood | i'm guessing 'which' may not exist? | 14:38 |
| locallycompact | which is there | 14:39 |
| paulsherwood | and sh? | 14:39 |
| locallycompact | yup | 14:40 |
| locallycompact | it's baserock build | 14:40 |
| radiofree | is there anything in /lib/modules? | 14:41 |
| *** Lachlan1975 has quit IRC | 14:41 | |
| radiofree | e.g /lib/modules/4.4.0-dirty.... | 14:41 |
| locallycompact | 4.2.0+/... | 14:41 |
| paulsherwood | locallycompact: which version of ybd, please? | 14:41 |
| locallycompact | master | 14:42 |
| richard_maw | you can also get that execv: No such file or directory error from a library sh depends on being missing | 14:43 |
| rjek | Or something that the shell then calls on? | 14:44 |
| richard_maw | and assuming the it's not doing something silly like passing that whole string as argv0, it will be that `sh` is missing something | 14:44 |
| richard_maw | rjekI think : you normally see a different error message in that case | 14:45 |
| paulsherwood | locallycompact: i'm suspecting that the problem is earlier... it's failing to open meta files. the new splitting functionality may be clashing with culling of aritfacts/unpacked dirs | 14:48 |
| paulsherwood | rdale: is splitting robust against 'WARNING: problem loading foo'? | 14:50 |
| paulsherwood | (eg if .unpacked doesn't exist) | 14:51 |
| *** Lachlan1975 has joined #baserock | 14:53 | |
| rdale | no, it wouldn't be expecting that to happen | 14:56 |
| paulsherwood | locallycompact: try putting get_cache(defs, chunk) | 14:57 |
| paulsherwood | in l99 of splitting.py | 14:57 |
| paulsherwood | rdale: well, it can happen now - .unpacked is doubling storage on artifacts, so cull clears .unpacked first if it can | 14:58 |
| locallycompact | same | 14:58 |
| rdale | so where are the files if the .unpacked dir is missing? | 14:59 |
| paulsherwood | in the artifact tarball itself | 15:00 |
| rdale | so if we get that error because there is no .unpacked dir, we need to untar the tarball again? | 15:00 |
| paulsherwood | rdale: i'd have expected 'ERROR: problem loading foo' and exit, rather than warning :) | 15:00 |
| paulsherwood | i'm assuming so. i didn't test this... will do so later | 15:01 |
| paulsherwood | locallycompact: to avoid holding you up, would reverting to 16.01 be tolerable for you? | 15:01 |
| * locallycompact can | 15:02 | |
| paulsherwood | ok i recommend that for now | 15:03 |
| mwilliams_ct | paulsherwood: I've made a pull request for a first pass attempt at Riemann support. I think there is plenty of scope to do more with Riemann, which I intend to figure out this afternoon, but it's a first pass and gives some support at least | 15:12 |
| rdale | paulsherwood: i think in compose(), if it finds a cache key for a stratum, it assumes the stratum is already built and doesn't try and rebuild the chunks | 15:13 |
| rdale | before calling the artifact splitting function on a stratum, the code calls compose() expecting the stratum to be built if it hasn't been already | 15:15 |
| paulsherwood | mwilliams_ct: have you tested what happens if riemann is installed, but server is not up/present? | 15:21 |
| mwilliams_ct | paulsherwood: no, but I realised seconds before you typed that it would be a bad thing! | 15:22 |
| * mwilliams_ct goes back to throw a conditional in | 15:22 | |
| paulsherwood | :) | 15:22 |
| paulsherwood | mwilliams_ct: i repeat my previous question... what happens if riemann_available, but there's no actual server, or the server is down? | 15:55 |
| mwilliams_ct | it would hang forever | 15:55 |
| mwilliams_ct | which is a limitation of riemann-client afaict. I'm looking into catching that though | 15:56 |
| paulsherwood | -1, then :) | 15:56 |
| mwilliams_ct | +1 to your -1 | 15:56 |
| *** jonathanmaw has quit IRC | 16:07 | |
| *** jonathanmaw has joined #baserock | 16:07 | |
| *** jonathanmaw_ has joined #baserock | 16:14 | |
| *** jonathanmaw has quit IRC | 16:18 | |
| mwilliams_ct | paulsherwood: v2 request submitted | 16:33 |
| *** locallycompact has quit IRC | 16:40 | |
| *** jonathanmaw_ is now known as jonathanmaw | 17:03 | |
| *** cosm has joined #baserock | 17:09 | |
| paulsherwood | mwilliams_ct: thanks! sorry to be picky, but why do we need two timer types? won't Artifact_timer be a subset of Timer? | 17:26 |
| mwilliams_ct | paulsherwood: yes, it will but that requires a bit more reimagining of ybd. I wanted to get something in for now and improve on it | 17:27 |
| mwilliams_ct | so the honest answer is because it was easier to program as a separate service, though actually it might be ok to just name them both the same | 17:28 |
| paulsherwood | i thought there's already an elapsed time for artifact? | 17:28 |
| paulsherwood | eg [gnome-contacts] Elapsed time for artifact creation 00:00:03 | 17:29 |
| paulsherwood | so if Timer fires on every Elapsed... is Artifact_timer something different? | 17:30 |
| *** jonathanmaw has quit IRC | 17:31 | |
| *** ctbruce has quit IRC | 17:31 | |
| *** CTtpollard has quit IRC | 17:31 | |
| *** ssam2 has quit IRC | 17:31 | |
| *** edcragg has quit IRC | 17:31 | |
| *** fay_ has quit IRC | 17:31 | |
| *** bashrc has quit IRC | 17:31 | |
| *** Lachlan1975 has quit IRC | 17:31 | |
| *** bashrc has joined #baserock | 17:31 | |
| *** ctbruce has joined #baserock | 17:31 | |
| *** jonathanmaw has joined #baserock | 17:31 | |
| *** fay_ has joined #baserock | 17:31 | |
| *** Lachlan1975 has joined #baserock | 17:31 | |
| *** CTtpollard has joined #baserock | 17:31 | |
| *** edcragg has joined #baserock | 17:32 | |
| mwilliams_ct | the major difference is that Artifact_Timer will always be called at the end of a chunk build, which means we can gain the name of the repo fairly easily. in principle that sounds like it could be handy for graphing and so should be separate from other timers... but in practice it isn't as artifact creation is nearly always very quick IME | 17:32 |
| mwilliams_ct | I'm sort of feeling my way through Riemann as I go along, locallycompact knows a lot more about it than me still | 17:33 |
| paulsherwood | ack | 17:34 |
| *** cosm_ has joined #baserock | 17:39 | |
| *** cosm has quit IRC | 17:40 | |
| *** ctbruce has quit IRC | 17:52 | |
| *** cosm_ is now known as cosm | 17:52 | |
| *** jonathanmaw has quit IRC | 17:56 | |
| *** bashrc has quit IRC | 17:59 | |
| pedroalvarez | jjardon: turns out https://gerrit.baserock.org/#/c/1369/3 was very broken | 18:06 |
| pedroalvarez | right, I guess it's just because too many things changed since nov 4th | 18:10 |
| jjardon | pedroalvarez: fixed | 18:13 |
| pedroalvarez | no review...? | 18:13 |
| pedroalvarez | it will be still broken | 18:13 |
| paulsherwood | :) | 18:17 |
| pedroalvarez | anyway.. | 18:18 |
| jjardon | pedroalvarez: its a trivial fix, better a quick fix than waiting for a review another 3 months | 18:19 |
| pedroalvarez | your call | 18:19 |
| radiofree | still broken | 18:24 |
| pedroalvarez | radiofree: what is it? | 18:24 |
| radiofree | 2016-02-08 18:22:02 Build of m4-common.morph failed. | 18:24 |
| radiofree | ERROR: Failed to build git://192.168.222.58/baserock/baserock/definitions 49ea7523e2c6c74100aa23906a9bedf914843df9 systems/gnome-system-x86_64.morph: Building failed for m4-common.morph-misc | 18:24 |
| pedroalvarez | turns out it wasn't that trivial | 18:25 |
| *** edcragg has quit IRC | 18:27 | |
| pedroalvarez | right, this was cache being full. Fixed that | 18:31 |
| *** Lachlan1975 has quit IRC | 18:32 | |
| *** edcragg has joined #baserock | 19:51 | |
| *** edcragg has quit IRC | 20:09 | |
| *** rdale has quit IRC | 20:23 | |
| *** edcragg has joined #baserock | 21:01 | |
| *** toscalix has quit IRC | 21:13 | |
| *** edcragg has quit IRC | 22:26 | |
Generated by irclog2html.py 2.15.3 by Marius Gedminas - find it at mg.pov.lt!