IRC logs for #baserock for Monday, 2016-02-08

*** cosm_ has joined #baserock00:30
*** cosm has quit IRC00:33
*** toscalix has joined #baserock07:44
*** fay_ has joined #baserock08:33
*** ctbruce has joined #baserock08:57
*** paulw has joined #baserock09:00
*** bashrc has joined #baserock09:04
*** rdale has joined #baserock09:16
*** CTtpollard has joined #baserock09:29
*** jonathanmaw has joined #baserock09:34
*** paulw has joined #baserock09:41
*** ssam2 has joined #baserock09:46
*** ChanServ sets mode: +v ssam209:46
*** ctbruce has quit IRC09:52
paulsherwoodYBD 16.06 is released09:54
* pedroalvarez_ claps09:58
*** pedroalvarez_ is now known as pedroalvarez09:58
*** edcragg has joined #baserock10:09
*** paulw has quit IRC10:10
paulsherwoodlol10:37
*** Lachlan1975 has joined #baserock10:39
*** Lachlan1975 has quit IRC10:50
*** ctbruce has joined #baserock10:56
*** paulw has joined #baserock11:00
*** gtristan has joined #baserock11:16
*** Lachlan1975 has joined #baserock11:17
pedroalvarezrichard_maw: am i right thinking that all of these tasks have been completed? https://storyboard.baserock.org/#!/story/4711:24
richard_mawpedroalvarez: sadly, no.11:26
richard_mawpedroalvarez: IIRC the moving debug artifacts to not be included by default isn't done11:27
pedroalvarezand everything else is11:27
richard_mawand default split rules haven't been moved to the build system definitions11:27
richard_mawAIUI they are both moved to definitions, but not in the way specified as part of the story11:28
pedroalvarezI see11:28
richard_mawIIRC there was some more tooling work required to be able to have a "not included by default" flag for split rules11:29
* richard_maw has marked the bits he believes to be done as merged11:29
pedroalvarezgood, thanks!11:30
* richard_maw tries to remember what he was doing before taking a trip down memory lane11:31
pedroalvarezapologies11:32
richard_mawno worries11:32
richard_mawin the absence of a proper hand-off a couple of minutes here and there is fine11:32
richard_mawit's pretty much why I'm still in #baserock after running out of bandwidth to contribute more usefully11:33
perrylpaulsherwood: 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 up11:42
rdaleit has some file operations that assume ybd is being run from the top level of definitions11:43
*** paulw has quit IRC11:45
perryli'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 things11:46
paulsherwoodi 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
perrylindeed, i was just curious if it was specified anywhere :)11:50
*** ctbruce has quit IRC11:51
*** ctbruce has joined #baserock11:57
ssam2morph solves this by requiring the top level dir to be a .git repo12:01
ssam2which also isn't ideal, of course12:01
ssam2but in practice i've never wished that it didn't require the definitions to be a .git repo, so far12:02
*** locallycompact has joined #baserock12:03
rdalei 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 scale12:13
pedroalvarezI believe that was possible a while ago...12:16
pedroalvarezto point to strata in different repos12:17
locallycompactHas anyone tried go in baserock? It's on g.b.o but not in definitions.12:24
ssam2paulsherwood tried it ages ago, which I think was back when it could be bootstrapped from C12:33
ssam2which worked fine, but I think now it needs to be bootstrapped from Go12:34
ssam2rdale: we used to have that and it was horrible! I think it does scale..12:34
ssam2e.g. Gentoo more or less works that way12:34
paulsherwoodrdale: all in one repo does scale. no doubt in my mind on this point12:36
locallycompactsomething in ansible on g.b.o is wrong12:37
paulsherwoodi'd go so far as to say all in one *branch* in one repo, covering many variants of many systems,12:37
locallycompactgit clone http://git.baserock.org/git/delta/ansible.git12:37
locallycompactwarning: remote HEAD refers to nonexistent ref, unable to checkout.12:38
rdalefair 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 systems12:38
ssam2locallycompact: ansible don't have a master branch12:39
locallycompactoh12:39
paulsherwoodrdale: 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 price12:40
rdalemaybe - 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 unrelated12:42
richard_mawto weigh in on the topic of finding the "root" directory of a definitions repo, you could look for the DEFAULTS file12:43
paulsherwoodrichard_maw: ybd does that, but it's not always present in old definitions :)12:43
richard_mawpaulsherwood: fair enough12:44
paulsherwoodto be clear, iiuc perryl's case is where ybd is run *accidentally on purpose* somewhere *above* definitions12:44
paulsherwoods/on/ or on/12:44
perrylindeed; in this case i was running from the ybd directory, with definitions and ybd both having the same parent12:45
paulsherwoodack12:45
richard_mawpaulsherwood: but the file path of the definition to build is pointing to the file in the repository yes?12:45
richard_mawin which case if it had a DEFAULTS file, you could locate the root starting from the definition file, rather than going up from cwd12:46
*** ctbruce has quit IRC12:47
*** ctbruce has joined #baserock13:02
*** Lachlan1975 has quit IRC13:05
paulsherwoodrichard_maw: ybd supports 'ybd gcc x86_64' for example...13:12
richard_mawah, so this is more data to suggest we should require file paths then13:13
paulsherwoodyup, i think so13: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_mawan alternative to probing for the "top" of the definitions would be to specify all the definitions as relative file paths13:17
paulsherwoodrichard_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_mawoh, 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 definitions13:20
paulsherwoodi thought paths are already that way?13:23
paulsherwoodeg morph: strata/armv7lhf-cross-toolchain/armv7lhf-cross-binutils.morph13:23
paulsherwoodsorry, i may be being dumb, here13:24
richard_mawthe paths are all relative to the top of the repo, rather than each other13:24
paulsherwoodoh, i see what you mean13:24
richard_mawi.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 disappearing13:35
*** cosm_ has quit IRC13:53
*** cosm_ has joined #baserock14:07
*** Lachlan1975 has joined #baserock14:21
*** cosm_ has quit IRC14:24
locallycompactwhat is ydb telling me here https://paste.fedoraproject.org/319887/94202814/14:34
radiofreelocallycompact: does /lib/modules exist?14:36
radiofreeand/or depmod14:36
locallycompact /lib/modules exists14:37
locallycompactdepmod too14:37
radiofreecould you pastebin  /src/artifacts/minimal-system-x86_64-generic.57782890a60b72bea336ecb1a1105efea8da233e492437f5ef91b9d43d20141c.build-log14:37
locallycompacthttps://paste.fedoraproject.org/319889/14549422/14:38
paulsherwoodi'm guessing 'which' may not exist?14:38
locallycompactwhich is there14:39
paulsherwoodand sh?14:39
locallycompactyup14:40
locallycompactit's baserock build14:40
radiofreeis there anything in /lib/modules?14:41
*** Lachlan1975 has quit IRC14:41
radiofreee.g /lib/modules/4.4.0-dirty....14:41
locallycompact4.2.0+/...14:41
paulsherwoodlocallycompact: which version of ybd, please?14:41
locallycompactmaster14:42
richard_mawyou can also get that execv: No such file or directory error from a library sh depends on being missing14:43
rjekOr something that the shell then calls on?14:44
richard_mawand assuming the it's not doing something silly like passing that whole string as argv0, it will be that `sh` is missing something14:44
richard_mawrjekI think : you normally see a different error message in that case14:45
paulsherwoodlocallycompact: 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 dirs14:48
paulsherwoodrdale: is splitting robust against 'WARNING: problem loading foo'?14:50
paulsherwood(eg if .unpacked doesn't exist)14:51
*** Lachlan1975 has joined #baserock14:53
rdaleno, it wouldn't be expecting that to happen14:56
paulsherwoodlocallycompact: try putting         get_cache(defs, chunk)14:57
paulsherwoodin l99 of splitting.py14:57
paulsherwoodrdale: well, it can happen now - .unpacked is doubling storage on artifacts, so cull clears .unpacked first if it can14:58
locallycompactsame14:58
rdaleso where are the files if the .unpacked dir is missing?14:59
paulsherwoodin the artifact tarball itself15:00
rdaleso if we get that error because there is no .unpacked dir, we need to untar the tarball again?15:00
paulsherwoodrdale: i'd have expected 'ERROR: problem loading foo' and exit, rather than warning :)15:00
paulsherwoodi'm assuming so. i didn't test this... will do so later15:01
paulsherwoodlocallycompact: to avoid holding you up, would reverting to 16.01 be tolerable for you?15:01
* locallycompact can15:02
paulsherwoodok i recommend that for now15:03
mwilliams_ctpaulsherwood: 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 least15:12
rdalepaulsherwood: 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 chunks15:13
rdalebefore calling the artifact splitting function on a stratum, the code calls compose() expecting the stratum to be built if it hasn't been already15:15
paulsherwoodmwilliams_ct: have you tested what happens if riemann is installed, but server is not up/present?15:21
mwilliams_ctpaulsherwood: 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 in15:22
paulsherwood:)15:22
paulsherwoodmwilliams_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_ctit would hang forever15:55
mwilliams_ctwhich is a limitation of riemann-client afaict. I'm looking into catching that though15:56
paulsherwood-1, then :)15:56
mwilliams_ct+1 to your -115:56
*** jonathanmaw has quit IRC16:07
*** jonathanmaw has joined #baserock16:07
*** jonathanmaw_ has joined #baserock16:14
*** jonathanmaw has quit IRC16:18
mwilliams_ctpaulsherwood: v2 request submitted16:33
*** locallycompact has quit IRC16:40
*** jonathanmaw_ is now known as jonathanmaw17:03
*** cosm has joined #baserock17:09
paulsherwoodmwilliams_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_ctpaulsherwood: yes, it will but that requires a bit more reimagining of ybd. I wanted to get something in for now and improve on it17:27
mwilliams_ctso 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 same17:28
paulsherwoodi thought there's already an elapsed time for artifact?17:28
paulsherwoodeg [gnome-contacts] Elapsed time for artifact creation 00:00:0317:29
paulsherwoodso if Timer fires on every Elapsed... is Artifact_timer something different?17:30
*** jonathanmaw has quit IRC17:31
*** ctbruce has quit IRC17:31
*** CTtpollard has quit IRC17:31
*** ssam2 has quit IRC17:31
*** edcragg has quit IRC17:31
*** fay_ has quit IRC17:31
*** bashrc has quit IRC17:31
*** Lachlan1975 has quit IRC17:31
*** bashrc has joined #baserock17:31
*** ctbruce has joined #baserock17:31
*** jonathanmaw has joined #baserock17:31
*** fay_ has joined #baserock17:31
*** Lachlan1975 has joined #baserock17:31
*** CTtpollard has joined #baserock17:31
*** edcragg has joined #baserock17:32
mwilliams_ctthe 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 IME17:32
mwilliams_ctI'm sort of feeling my way through Riemann as I go along, locallycompact knows a lot more about it than me still17:33
paulsherwoodack17:34
*** cosm_ has joined #baserock17:39
*** cosm has quit IRC17:40
*** ctbruce has quit IRC17:52
*** cosm_ is now known as cosm17:52
*** jonathanmaw has quit IRC17:56
*** bashrc has quit IRC17:59
pedroalvarezjjardon: turns out https://gerrit.baserock.org/#/c/1369/3 was very broken18:06
pedroalvarezright, I guess it's just because  too many things changed since nov 4th18:10
jjardonpedroalvarez: fixed18:13
pedroalvarezno review...?18:13
pedroalvarezit will be still broken18:13
paulsherwood:)18:17
pedroalvarezanyway..18:18
jjardonpedroalvarez: its a trivial fix, better a quick fix than waiting for a review another 3 months18:19
pedroalvarezyour call18:19
radiofreestill broken18:24
pedroalvarezradiofree: what is it?18:24
radiofree2016-02-08 18:22:02 Build of m4-common.morph failed.18:24
radiofreeERROR: Failed to build git://192.168.222.58/baserock/baserock/definitions 49ea7523e2c6c74100aa23906a9bedf914843df9 systems/gnome-system-x86_64.morph: Building failed for m4-common.morph-misc18:24
pedroalvarezturns out it wasn't that trivial18:25
*** edcragg has quit IRC18:27
pedroalvarezright, this was cache being full. Fixed that18:31
*** Lachlan1975 has quit IRC18:32
*** edcragg has joined #baserock19:51
*** edcragg has quit IRC20:09
*** rdale has quit IRC20:23
*** edcragg has joined #baserock21:01
*** toscalix has quit IRC21:13
*** edcragg has quit IRC22:26

Generated by irclog2html.py 2.14.0 by Marius Gedminas - find it at mg.pov.lt!