IRC logs for #baserock for Friday, 2015-05-29

*** SotK has quit IRC00:30
*** SotK has joined #baserock00:30
*** zoli__ has joined #baserock07:08
*** jonathanmaw has joined #baserock07:44
*** bashrc_ has joined #baserock08:08
*** gary_perkins has joined #baserock08:39
*** edcragg has joined #baserock08:50
*** ssam2 has joined #baserock09:15
*** ChanServ sets mode: +v ssam209:15
straycatmwilliams_ct, i was recently given feedback that my reviews are too indirect, that's probably the first 'direct' review i've made, i hope it didn't seem harsh09:22
mwilliams_ctstraycat: not at all, very helpful feedback and *very* much appreciated. thanks for taking the time to review09:22
straycatcool09:22
*** lachlanmackenzie has joined #baserock09:23
richard_mawssam2: I'd rather morph didn't hard-code logic about binary stripping, but there's other things we could do to make the "strip the contents of DESTDIR" command readable. I'm not seriously suggesting we merge its current incarnation.09:25
richard_mawit's currently at the optimal point for speed and size without considerations for readability beyond indentation of the clauses09:26
richard_maws/speed and size/speed, size and reduction of external dependencies/09:27
ssam2richard_maw: ok09:28
ssam2I wonder if having a few well-defined functions that definitions could call would be a good idea09:28
ssam2so e.g. a 'find-all-elf-binaries()' function that definitions could choose to call, or not09:29
ssam2and then we could implement find-all-elf-binaries() in a language that isn't shell09:29
ssam2not something that will be done this week, I imagine, but maybe it makes sense in the long term. If we used jinja2 templating in definitions it could maybe be a jinja2 function09:30
richard_mawa jinja2 function that expanded into a shell command‽09:31
* richard_maw doesn't understand09:31
ssam2no, a jinja2 function that called some functionality in the build tool09:31
ssam2and was substituted when evaluated for a list of all ELF binaries that were found09:31
ssam2so you could have: 'strip-commands: strip --foo --bar {{ all_elf_binaries }}'09:32
ssam2something like that09:32
KinnisonI can imagine that various people would be upset if processing definitions now involved jinja2 templates09:32
ssam2people are always upset :)09:32
* Kinnison is not terribly pleased with the idea of the definitions not being able to be expanded until after the build09:33
ssam2that's a fair point09:33
ssam2Kinnison: but is it more useful to know that you have 'strip-commands: find -exec foo' ?09:34
ssam2you don't actually know what that will do until build-time, anyway09:34
KinnisonTrue, but at least you know it can *ONLY* depend on the content of the staging area09:34
KinnisonRather than relying on some functional implementation within the build tool09:35
ssam2I was imagining the hook functions would be strictly defined09:35
ssam2so you would know what they did09:35
ssam2(given the contents of the staging area)09:35
straycatdefinitions already involve jinja templates?09:35
ssam2i also don't particularly want to have them, it just seems like in this one case, it might be nicer than the shell script richard_maw posted yesterday :)09:35
Kinnisonssam2: If the hook functions can be defined in *definitions* then I'd be up for it09:35
ssam2hm... that makes sense, indeed09:36
* Kinnison wants less magic in the build tool09:36
KinnisonI don't mind cleverer definitions so long as the build tool is not more magical as a result09:36
ssam2it wouldn't be magic, it'd be well-defined stuff. but it would be a total pain in the ass to define how the function should behave. much better to just define it in code, in definitions09:36
straycatwe only added jinja template support to install-files cause it turned out it's really quite useful09:36
* richard_maw would prefer the build helpers be present in definitions in the form of chunk definitions09:37
richard_mawKinnison: can you provide a link to the slpkg equivalent command? I couldn't find it with a quick google09:37
* richard_maw is interested in being able to compare approaches09:38
KinnisonNot easily09:38
Kinnisonthe code is on my NAS at home09:38
richard_mawoh, sl in this case stands for simtec linux, rather than slackware09:39
Kinnisonyes09:39
KinnisonHence Lua09:39
Kinnison:)09:39
richard_mawgoogle results only came up with the latter09:39
richard_mawslackware's tooling appears to also be python09:39
* 20WABCVSQ wonders where 20WABCVSQ came from09:40
*** 20WABCVSQ is now known as tiagogomes09:40
radiofreeit's probably because you're logging in with the nick "tiago"09:47
rdalei can't seem to see how you reply to a review on gerrit and quote the message - i've done it before i'm sure10:17
radiofreerdale: click the comment to expand it10:18
radiofreeclick the arrow next to the date/time on the right hand side of the comment10:19
rdaleah ha! thanks10:19
ssam2here's a weird bug: my Jetson-Mason instance is failing to get the shared artifact cache to fetch completed artifacts... because worker_connection._conn.getpeername()[0] is returning 127.0.0.210:28
ssam2worker_connection is a socket connection from localhost, to localhost, in this case10:28
ssam2and networking is fine otherwise, 'ip addr' shows the real IP10:29
ssam2i imagine restarting the distbuild services will fix it, but I wonder if anyone knows how we can stop this in future...10:29
Kinnisonfind out where has 127.0.0.2 ?10:29
ssam2how do I do that?10:29
Kinnisongrep?10:30
ssam2# lsof -i|grep -c 127.0.0.210:30
ssam2010:30
ssam2I think that the last thing I did to this box is reboot it, so I'm suspicious that the problem is distbuild services starting up before systemd-networkd has fully sorted out the network10:31
Kinnisonhmm10:31
ssam2not sure what to do about that though, if it is that. https://wiki.freedesktop.org/www/Software/systemd/NetworkTarget/ suggests that programs should just cope with internet coming and going underneath them10:31
ssam2which is sensible, but not trivial to do with the current distbuild code10:32
straycati guess we could handle socket errors by re-establishing the connections and resending the data10:40
ssam2the weird thing is that the connection that things its peername is 127.0.0.2 works fine10:52
ssam2the only problem comes when it says to the artifact cache, "hey, fetch an artifact from 127.0.0.2/...'10:52
Kinnisonthat ought to work unless the cache tight-bound to 127.0.0.110:53
ssam2the cache is remote10:53
ssam2so it can't work10:53
Kinnisonaah10:53
Kinnisonerm10:53
Kinnisonbuh?10:53
ssam2perhaps the problem is an assumption in the distbuild code that the worker *isn't* localhost10:54
ssam2such that it thinks whatever address its has connected to the worker on is publically accessible10:54
Kinnisoncontroller->worker permits localhostness for single-system deployments10:54
KinnisonWhat do your controller and worker configs look like?10:54
ssam2the culprit is: http://git.baserock.org/cgi-bin/cgit.cgi/baserock/baserock/morph.git/tree/distbuild/worker_build_scheduler.py#n65410:55
ssam2one sec10:55
Kinnisonaaaah10:55
KinnisonYes the assumption is that your cache must be able to reach your worker's IP addresses10:55
ssam2yeah, I guess it is10:56
KinnisonSo if you have a worker on the controller node, you must have it in the config by its externally visible address10:56
ssam2right.10:56
ssam2I have: 'worker = sam-jetson-mason'10:56
ssam2which is the config set up by distbuild-setup.service10:56
ssam2but I can't hardcode the public IP because it DHCP's10:57
KinnisonI'm guessing that sam-jetson-mason resolves to the local IP address10:57
Kinnisonbecause of systemd's nss-myhostname stuff10:57
ssam2yeah, I guess it does that the time the distbuild services start10:57
straycatssam2, use the fqdn for that network10:57
ssam2straycat: that's an idea, I'll try that10:57
ssam2I created a story to track the current state of the OSTree work: <https://storyboard.baserock.org/#!/story/48>, please add more detail if you can think of any11:02
*** pacon has joined #baserock11:22
*** pacon has quit IRC12:09
*** pacon has joined #baserock12:11
*** pacon has quit IRC12:13
*** pacon has joined #baserock12:14
ssam2hello, I've updated http://wiki.baserock.org/links/ with some descriptions for some of the links and a couple of the new links12:42
ssam2one of the links is to Yocto / OpenEmbedded so it might be a little controversial ;) I did my best to understand and explain what they are and how they differ from Baserock, though12:42
ssam2feedback welcome but I'll not respond til after I've eaten some lunch12:43
*** pacon has quit IRC13:01
*** pacon has joined #baserock13:03
jonathanmawhrm, I'm trying to build bits of Tizen in baserock, and I've found something that requires icu (which is already in the webtools and qt5-tools strata). Since conceivably the tizen work might be on a GENIVI Demo Platform system, qt5-tools might be on the system, but it might not13:11
jonathanmawand either way, I wouldn't want to depend on all of qt when I just want icu13:12
jonathanmawWould it be wise to move icu into core?13:12
ssam2better to create a separate 'icu' stratum, I think13:12
*** pacon has quit IRC13:12
radiofreesomething else uses icu as well13:15
jonathanmawradiofree: I see it in qt5-tools, qt4-tools and webtools13:16
radiofreeprobably webtools13:21
radiofree(what i was thinking of)13:21
pedroalvarezcan we take out the configure extensions from the system morphologies?13:35
pedroalvarezor at least from the cache key calculation?13:35
richard_mawpedroalvarez: I wasn't aware that they did! I'd +2 a patch to remove configuration-extensions from the cache keys of system morphologies13:37
pedroalvarez\o/13:38
pedroalvarezthat was easy13:48
pedroalvarezopenstack-system-x86_6414:16
pedroalvarezwrong paste14:16
pedroalvarezhttps://gerrit.baserock.org/73414:16
pedroalvarezurgh, pyeclib artifact contains a pyeclib.inst folder14:36
pedroalvarezI think everyone has that folder in / in their devel systems now14:37
* paulsher1ood doesn't :)14:39
pedroalvarezhmm :/14:40
pedroalvarezoh, I see, this is a new addition of openstack kilo14:42
richard_mawpedroalvarez: that's annoying, but it won't be the first time that something's messed up and included DESTDIR in their paths14:49
pedroalvarezI'll have to check the build log, but not a big deal14:51
*** gallit has joined #baserock15:00
*** zoli__ has quit IRC15:11
mwilliams_ctstraycat: sorry for misunderstanding, will fix15:23
straycatmwilliams_ct, actually i think it's my fault, earlier in the week someone pointed out that a value received there might be an empty string, but any empty dictionary values in the cluster morph get set to None by the yaml parser15:33
mwilliams_ctYeah just seen your second comment. I'm replying now15:34
mwilliams_ct(for those playing along at home this conversation is in ref to change 729)15:34
*** CTtpollard has quit IRC15:58
straycatdef sanitize_environment(env):16:11
straycat    for k in env:16:11
straycat        env[k] = str(env[k])16:11
straycati see16:11
*** zoli__ has joined #baserock16:12
*** jonathanmaw has quit IRC16:12
*** sambishop has quit IRC16:12
Kinnisonstraycat: pardon?16:17
mwilliams_ctKinnison: see change 729, straycat has managed to find where I was tripping up and that is the place16:20
mwilliams_ctstraycat: thanks!16:20
Kinnisonah16:21
straycatKinnison, so when you specify a key "x: " in the cluster morph, the yaml parse assigns value None to key x, but then morph goes over the whole dictionary and calls str() on each value, so our value for x now contains the string 'None', I think we ought to make morph replace values with None types with empty strings, because this isn't the first time this has caused confusion16:23
straycatbut, I expect that doing that could break things16:23
Kinnisonstraycat: aah, I'd have expected morph to barf on a "None"16:23
KinnisonCertainly when we've wanted explicitly empty strings before we've done 'x: ""'16:23
Kinnison(and by 'barf' I mean explode is a pleasant controlled manner and inform the user clearly what went on)16:24
straycatactually, from a quick grep only swift-storage.configure does a check for a None string, so I don't think that change would break much, if anything16:26
straycatmwilliams_ct, i suggest leaving v4 as it is and i'll send a fix for sanitize_environment16:28
mwilliams_ctstraycat: ok! thanks again for taking the time to review :)16:29
*** sambishop has joined #baserock16:35
*** tiagogomes has quit IRC16:39
pedroalvarezmeh, this pyeclib thing installs installs also more things, but these things ignore $PREFIX and $DESTDIR16:41
edcragghas gcc broken on armv7? http://paste.baserock.org/udowosupis16:42
pedroalvarezedcragg: "sed: can't create temp file 'gcc/configureA5wp9A': Read-only file system"16:44
pedroalvarezedcragg: that doesn't look like gcc being broken :P16:44
edcraggthis system's been building, i just rebased and that happened16:44
edcraggi meant the gcc build16:45
pedroalvarezhm.. you are using /tmp16:46
edcraggsymlinked to /src16:46
pedroalvarezhm.. you can configure morph instead: http://wiki.baserock.org/quick-start/#index4h216:48
straycatKinnison, https://gerrit.baserock.org/736 is a possible fix for that16:48
edcraggpedroalvarez: ah, ok, that's handy!16:48
pedroalvarezedcragg: not sure what's going on in your build, tbh, but it looks like a problem in your development environment, and nothing to do with gcc16:49
edcraggprobably, yes i agree... i've just been building quite a few things recently so assumed the environment was fine. thanks pedroalvarez, you calmed my nerves anyway16:52
pedroalvarez:)16:53
*** bashrc_ has quit IRC17:01
*** ssam2 has quit IRC17:03
*** gary_perkins has quit IRC17:14
*** zoli__ has quit IRC17:32
*** gallit has quit IRC17:52
*** edcragg has quit IRC18:16
*** lachlanmackenzie has quit IRC18:30
*** sambishop has quit IRC19:55
*** zoli__ has joined #baserock20:46
*** zoli__ has quit IRC21:39
*** zoli__ has joined #baserock21:41
*** zoli__ has quit IRC22:46

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