IRC logs for #baserock for Monday, 2016-10-17

*** lachlanmackenzie has quit IRC01:23
*** gtristan has joined #baserock05:07
*** fay_ has joined #baserock07:12
*** ctbruce has joined #baserock07:32
*** rdale has joined #baserock08:37
*** tiagogomes has joined #baserock09:09
*** locallycompact has joined #baserock09:10
*** jude_ has quit IRC09:30
*** jude_ has joined #baserock09:35
locallycompactwell that certainly makes cache key calculation a lot faster09:47
gtristanawesome, to the chopping block !09:48
locallycompactI made this the behaviour in defslib https://gitlab.com/baserock/defslib/commits/master09:58
pedroalvarezthen, the ref is always a git sha?09:59
locallycompactah we don't validate that10:00
locallycompacthow many characters is a sha10:02
locallycompactis ^[a-f0-9]{64} ?10:03
pedroalvarezaren't they 40?10:03
pedroalvarezalso, what if it's a tag sha? and not a commit sha?10:03
locallycompact?10:03
*** franred has joined #baserock10:04
pedroalvarezit will validate with the same regex, but that won't be a valid value for the cache key10:04
locallycompactwhat why?10:04
pedroalvarezwell, is one of the policies in http://wiki.baserock.org/policies/10:08
pedroalvarezmaybe we don't care about that anymore?10:09
locallycompactWhat am I looking at sorry10:09
locallycompactI see it10:10
pedroalvarez" ref to the commit hash (not the tag hash) of that version."10:10
locallycompactWhy is it important10:10
pedroalvarezI actually can't recall, but it's an special case you have to bear in mind. If you checkout a tag-sha your repo will checkout the commit-sha that the tag is pointing to.10:11
pedroalvarezif you feel like that policy should die too, feel free to send an email to baserock-dev10:12
locallycompactok10:16
locallycompactgtristan, I will come down very heavily on any object oriented creep into defslib. there will be no definition->enrichCacheKey as it changes the type10:18
locallycompactActuators transform Assemblages into cacheEnrichedAssemblages via cache enrichment10:18
locallycompactwithout any mutability language features the only strategy I have to keep python in line is to assume that any data structure I pass to any method at any point is as good as fucked10:20
locallycompactand that approach is keeping the logic short so far10:20
gtristan"object oriented creep"10:28
gtristanas far as the abstract enrichCacheKey part, which is really the missing piece to allow extensibility, I dont hold to that too strongly because I'm doubtful of how useful extensibility will be useful at that level10:29
locallycompactI'm interested in data types if we can generate them from the schema somehow and they are strictly pep 48410:32
locallycompactWithout currying and immutability it doesn't provide a whole lot but it's at least something10:33
*** edcragg has quit IRC11:43
locallycompactgtristan, eyes on https://gitlab.com/baserock/ybd/builds/518862811:45
locallycompactit's gonna fail somewhere around foundation for whatever reason11:45
locallycompactor core11:46
locallycompactgtristan, also this is pejorative but it's on point and is essentially the basis for the reason I won't entertain inheritance or encapsulative mutation: https://medium.com/@cscalfani/goodbye-object-oriented-programming-a59cda4c0e5311:55
locallycompactthey're archetypal for unwanted side effects11:55
locallycompact"The problem with object-oriented languages is they’ve got all this implicit environment that they carry around with them. You wanted a banana but what you got was a gorilla holding the banana and the entire jungle."11:56
gtristanlocallycompact, of course sound design is important, personally my gripe with OO models is that it's inherently not very deterministic; one inherits functionality that may change and bases assumptions about parent class guarantees that may change. With huger code bases like widget toolkits (which I still argue OO is the right fit for), things become hard to track12:01
gtristanand it's almost impossible to really know all modes of failure that are possible at a given time12:02
gtristanbut asking for a banana and receiving a gorilla is an example of misuse of the paradigm12:02
gtristanthe benefits of type generalization are good, extensibility is a good thing, hardening an object's API to mean something concrete and forcing subclasses to comply is good.12:04
gtristanKeeping the logic of different types contained in separate files which can be accessed with the same API because they appear to do the same thing (i.e. Chunk,Stratum,System are all definitions and all produce an artifact), is better than having switch cases scattered around a codebase12:05
locallycompactparents classes are not type generalization12:05
locallycompactan assemblage is not a definition, a definition gives rise to an assemblage12:06
locallycompactI don't know where I mentioned switch statements12:06
gtristanNo, you did not. And I'm waiting for you to propose your alternate vision of how the code should be organized.12:07
gtristanSo sorry I did not mean to put words in your mouth12:07
gtristanin the general sense though, I think I disagree that an assemblage is not a definition; it replaces the strata but behaves differently, it has an associated definition to compose it just like a stratum, and it will undoubtedly produce an artifact with metadata similar to an artifact12:08
locallycompactno, an assemblage is an abstract concept, how it's constructed does not constitute a class relation12:12
locallycompactThey're serializable of course, but that's not a inheritance relation, that's aspectual.12:15
gtristanI'm pretty sold on the idea that with or without inheritance, every entity in the definitions tree should be associated to a type, whos API I expect to gain character and harden with time so to speak, and not managed a chaotic collection dicts interpreted by some abstract machine12:17
gtristanAnd to be honest I dont even know if you agree with that or not, I'm drawing a blank12:17
locallycompactNo I agree with that12:17
gtristanOk, well I have a feeling that we just need to communicate better, and regret that we can't sit down for a beer f2f with a pen and napkin :)12:18
locallycompactexcept, I don't want mutating methods adding things to the representation without changing the type to match12:18
locallycompactpep 484 / mypi will help here12:19
gtristanIn absence of that, just please try to describe how you would compartmentalize the various parts of this machine in mail and what these things do12:19
gtristanI'm going to eat though, now :)12:19
gtristanheh12:19
gtristanI do have a huge wiki page on pep 484 open since before btw12:20
*** gtristan has quit IRC12:25
tiagogomesgitlab is being so slow12:41
jjardonThe ansible repo seems to still be problematic, does anyone have any time to check if something strange happen with It?13:04
tiagogomes1 sec13:05
tiagogomesgrr slowlab...13:06
pedroalvarezI have already checked13:06
pedroalvareznothing looks wrong in there13:06
pedroalvarezIf anyone can reproduce the error and prove that there is something wrong in the trove, I'll investigate13:07
tiagogomesThis PR can potentially fix the problem with ansible repo: https://gitlab.com/baserock/ybd/merge_requests/252 .13:08
pedroalvarezsounds scary13:09
pedroalvarezalso, nice patch and reasoning13:10
tiagogomes👍13:11
*** SotK_ is now known as SotK13:11
*** edcragg has joined #baserock13:27
locallycompacthttps://gitlab.com/baserock/ybd/builds/518862813:32
*** jjardon_matrix has quit IRC13:37
*** jjardon_matrix has joined #baserock13:37
*** jude_ has quit IRC14:01
*** toscalix has joined #baserock14:09
*** jude_ has joined #baserock14:15
leeminghttp://paste.baserock.org/ohacekujej14:17
leeminganyone know/could suggest/provide insight into this root build command14:17
leemingstage2-glibc seems to state : sh -c -e 'install -m 644 -o root -g root ld.so.conf "$DESTDIR/etc/ld.so.conf"'14:18
paulsherwoodleeming: i'm guessing this is an implication of overlaps14:18
* paulsherwood may be wrong though14:18
leemingmy simple brain tells me this might be a blocker for non-root builds14:18
* leeming wonders if the namespacing of root would fix this14:20
*** CTtpollard has joined #baserock14:33
*** thinkl33t has joined #baserock14:50
*** toscalix has quit IRC15:16
*** gtristan has joined #baserock15:26
rdalei don't know if it helps, but in the above command DESTDIR would be set to /tools15:50
leemingive not changed any of the definitions. Just changing the sandbox tool15:59
leemingbut im not educated enough to know if that is an issue or not?16:00
locallycompact$PREFIX would be set to /tools.16:01
locallycompactnot DESTDIR16:01
rdaleyes, please ignore my comment16:01
locallycompactwhy would overlaps be putting things in destdir16:02
*** ctbruce has quit IRC16:19
locallycompactcan someone help me debug a thing by leaving a build on overnight16:30
pedroalvarezuse gitlab ci?16:32
locallycompactI can't shell into gitlab ci runners16:33
locallycompactand it doesn't preserve artifacts between runs16:38
leemingdo you just need a second (non arch) machine to test on?16:39
locallycompactyeah16:39
leemingI guess i could16:39
locallycompactpip3 install defslib16:40
locallycompactthis branch of ybd https://gitlab.com/baserock/ybd/commits/staging/01016:40
leemingtiagogomes, sorry if you are seeing PR for sandboxlib, update on https://github.com/CodethinkLabs/sandboxlib/pull/2516:40
locallycompactthis branch of definitions https://gitlab.com/baserock/definitions/commits/lc/01016:40
leeminghas defslib been updated?16:42
locallycompactyeah16:42
locallycompactshoulod be 0.1.1416:42
leemingerk. how to check python lib versions16:42
locallycompactdoes it not say when you pip it16:43
pedroalvarezpip freeze16:43
locallycompactoh nice16:43
pedroalvarez(the only way I know)16:43
leemingRequirement already satisfied (use --upgrade to upgrade): defslib in /usr/local/lib/python3.4/dist-packages16:43
leemingCleaning up...16:43
leemingtells me nuthin16:44
pedroalvarezthat says a lot actually16:44
leemingpip freeze?16:44
locallycompact--upgrade16:44
pedroalvarezsays that you already have defslib installed, and if you want to upgrade, you need to use --upgrade16:44
leemingthought it would tell me that i have xx installed and yy is latest16:45
leeminglike it tells me after i run upgrade16:45
leeming"Found existing installation: defslib 0.1.9"16:45
locallycompactpip freeze is a silly name for that command16:46
locallycompactshould say16:46
locallycompactSuccessfully installed defslib-0.1.1416:46
leemingyes it installed16:46
leemingjust moaning about pip :P16:46
leemingI thought python had a module.__version__ attribute :(16:47
leemingoh common gitlab!16:50
leemingoops! ignore that.. remote is pointing to the wrong gitlab :P16:52
*** toscalix has joined #baserock16:54
tiagogomesleeming, to solve the problem that you have pasted above, have you tried to run bbrwap with `--gid 0 -- uid 0` ?16:57
tiagogomesThis works fine for me `bwrap --bind / / --uid 0 --gid 0 sh -c 'touch FOO && chown root:root FOO`16:57
leemingah, good catch16:58
leemingre man page "Custon gid in the sandbox (requires --unshare-user)"16:58
tiagogomes--uid implies --unshare-user16:58
leemingdocs should say implies then :)16:59
leemingi will try that though.... but... locallycompact this might affect running your tests?16:59
* tiagogomes is still yet to see how the deployed image will have the files own by root17:00
leemingnor me, but a lot of things happen without me know what is going on :) and i was tasked to do this17:01
locallycompactdw about me17:02
leemingrunning the sandbox always with --uid=1 a good idea?17:02
leemingsorry s/1/0/17:03
leeminghmm patched and just started off a ybd build17:06
tiagogomesI don't see any problem with that. Note that although the user appears to be root, it doesn't have the root privileges17:06
*** toscalix has quit IRC17:07
leemingmy bwrap doesn't run your command btw, seem to still require --unsure-user to be set17:08
tiagogomesThat looks solvable.17:09
*** toscalix has joined #baserock17:11
leemingblurh, seems to be a specific order of where to put --uid17:12
* leeming scratches head at "Unknown option --uid 0"17:15
tiagogomeswhich bbwrap version have u got17:16
leeming0.1.217:16
leemingodd though... running it outside of ybd/sandboxlib, it seems to not throw that error17:16
tiagogomesThat means that you are doing it wrong in sandboxlib :P17:18
tiagogomesWhat is the argument line that you giving in sandboxlib?17:18
leemings/sandboxlib/life/17:18
leeming/usr/bin/bwrap --bind / / --unshare-net --chdir /home/andrewleeming/ybd/tmp/tmpqtdO7a/stage1-binutils.build --dev-bind /dev /dev --bind /tmp /tmp --bind /home/andrewleeming/ybd/tmp/tmpqtdO7a/stage1-binutils.inst /home/andrewleeming/ybd/tmp/tmpqtdO7a/stage1-binutils.inst --bind /home/andrewleeming/ybd/tmp/tmpqtdO7a/stage1-binutils.build /home/andrewleeming/ybd/tmp/tmpqtdO7a/stage1-binutils.build --remount-ro / --unshare-user --uid17:19
leeming 0 --gid 0 <COMMAND>17:19
leemingwhere testing with just a simple ls worked :P17:19
*** toscalix has quit IRC17:21
tiagogomesYou can probably replace `--bind // --remount-ro /` with `--ro-bind //`. But that won't do much difference17:23
*** toscalix has joined #baserock17:23
tiagogomesAlso, you appear to do the same --bind twice for stage1-binutils.inst17:24
leeming--ro-bind / /, does not work if you are mounting anything else17:25
* leeming looks at the double mount17:25
*** toscalix has quit IRC17:25
tiagogomesHmm, even if --ro-bind / / is the last argument of the command?17:25
leeminghmm last ey?17:26
leemingI'm sure i must have tried that17:26
leemingbwrap requires directories to exist, no? so thought it would have ot be first?17:26
* leeming shrugs17:26
tiagogomes[tiagogomes@tiagogomes-thinkpad ybd]$ /usr/bin/bwrap --ro-bind / / --unshare-net --chdir / --dev-bind /dev /dev --bind /tmp /tmp --unshare-user --uid 0 --gid 0 touch /BANANAS17:27
tiagogomestouch: cannot touch '/BANANAS': Read-only file system17:27
leeminglike i siad, i dont know what im doing :P17:27
tiagogomeswfm ^17:27
leemingi tried all sorts of arcane configurations before i could get it working17:28
leemingno body seemed to know how to help at the time17:28
leeminghindsight is great :)17:28
* leeming wonders if the "Unknown option --uid 0" error is from bwrap or from ybd / somewhere else17:29
leemingsandboxlib (bubblewrap impl) should log issues, and i do no see that in the logs17:30
leemingoops.....17:30
tiagogomespaste the code where you invoke bwrap17:32
leemingcode was in the wrong place, but still did correct thing..17:32
*** locallycompact has quit IRC17:32
leemingarg wrap17:32
leeminghttp://paste.baserock.org/obasigasom17:32
tiagogomesthat won't work, because the command to run inside the sandbox is not escaped17:34
* leeming notes that *.inst is only stated once in the log, so i clearly do mount twice17:34
tiagogomesyou probably need to change the implementation of bubblewrap run_command to accept a list of arguments17:35
tiagogomesAnd not a string with the full command17:36
leemingit is doing the same as the other implementations17:36
leemingi.e. a string with the full command17:36
leemingit worked when run as root + without the --uid 0 stuff17:37
leemingbut yes, cleaner to encapsulate in quotes17:37
tiagogomesTomorrow I can look at your code if you push it somewhere17:38
* tiagogomes disappears in a cloud of dark smoke17:38
leemingmysterious17:38
leemingthanks17:38
leemingoh, is that the time?17:38
*** jjardon_matrix has quit IRC17:42
leemingif the quotes are needed, then it looks like ybd would need to add them in, as it wraps the command with "sh -c -e"17:43
*** jjardon_matrix has joined #baserock17:56
*** gtristan has quit IRC19:30
*** lachlanmackenzie has joined #baserock20:07
*** lachlanmackenzie has quit IRC22:33

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