| *** lachlanmackenzie has quit IRC | 01:23 | |
| *** gtristan has joined #baserock | 05:07 | |
| *** fay_ has joined #baserock | 07:12 | |
| *** ctbruce has joined #baserock | 07:32 | |
| *** rdale has joined #baserock | 08:37 | |
| *** tiagogomes has joined #baserock | 09:09 | |
| *** locallycompact has joined #baserock | 09:10 | |
| *** jude_ has quit IRC | 09:30 | |
| *** jude_ has joined #baserock | 09:35 | |
| locallycompact | well that certainly makes cache key calculation a lot faster | 09:47 |
|---|---|---|
| gtristan | awesome, to the chopping block ! | 09:48 |
| locallycompact | I made this the behaviour in defslib https://gitlab.com/baserock/defslib/commits/master | 09:58 |
| pedroalvarez | then, the ref is always a git sha? | 09:59 |
| locallycompact | ah we don't validate that | 10:00 |
| locallycompact | how many characters is a sha | 10:02 |
| locallycompact | is ^[a-f0-9]{64} ? | 10:03 |
| pedroalvarez | aren't they 40? | 10:03 |
| pedroalvarez | also, what if it's a tag sha? and not a commit sha? | 10:03 |
| locallycompact | ? | 10:03 |
| *** franred has joined #baserock | 10:04 | |
| pedroalvarez | it will validate with the same regex, but that won't be a valid value for the cache key | 10:04 |
| locallycompact | what why? | 10:04 |
| pedroalvarez | well, is one of the policies in http://wiki.baserock.org/policies/ | 10:08 |
| pedroalvarez | maybe we don't care about that anymore? | 10:09 |
| locallycompact | What am I looking at sorry | 10:09 |
| locallycompact | I see it | 10:10 |
| pedroalvarez | " ref to the commit hash (not the tag hash) of that version." | 10:10 |
| locallycompact | Why is it important | 10:10 |
| pedroalvarez | I 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 |
| pedroalvarez | if you feel like that policy should die too, feel free to send an email to baserock-dev | 10:12 |
| locallycompact | ok | 10:16 |
| locallycompact | gtristan, I will come down very heavily on any object oriented creep into defslib. there will be no definition->enrichCacheKey as it changes the type | 10:18 |
| locallycompact | Actuators transform Assemblages into cacheEnrichedAssemblages via cache enrichment | 10:18 |
| locallycompact | without 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 fucked | 10:20 |
| locallycompact | and that approach is keeping the logic short so far | 10:20 |
| gtristan | "object oriented creep" | 10:28 |
| gtristan | as 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 level | 10:29 |
| locallycompact | I'm interested in data types if we can generate them from the schema somehow and they are strictly pep 484 | 10:32 |
| locallycompact | Without currying and immutability it doesn't provide a whole lot but it's at least something | 10:33 |
| *** edcragg has quit IRC | 11:43 | |
| locallycompact | gtristan, eyes on https://gitlab.com/baserock/ybd/builds/5188628 | 11:45 |
| locallycompact | it's gonna fail somewhere around foundation for whatever reason | 11:45 |
| locallycompact | or core | 11:46 |
| locallycompact | gtristan, 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-a59cda4c0e53 | 11:55 |
| locallycompact | they're archetypal for unwanted side effects | 11: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 |
| gtristan | locallycompact, 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 track | 12:01 |
| gtristan | and it's almost impossible to really know all modes of failure that are possible at a given time | 12:02 |
| gtristan | but asking for a banana and receiving a gorilla is an example of misuse of the paradigm | 12:02 |
| gtristan | the 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 |
| gtristan | Keeping 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 codebase | 12:05 |
| locallycompact | parents classes are not type generalization | 12:05 |
| locallycompact | an assemblage is not a definition, a definition gives rise to an assemblage | 12:06 |
| locallycompact | I don't know where I mentioned switch statements | 12:06 |
| gtristan | No, you did not. And I'm waiting for you to propose your alternate vision of how the code should be organized. | 12:07 |
| gtristan | So sorry I did not mean to put words in your mouth | 12:07 |
| gtristan | in 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 artifact | 12:08 |
| locallycompact | no, an assemblage is an abstract concept, how it's constructed does not constitute a class relation | 12:12 |
| locallycompact | They're serializable of course, but that's not a inheritance relation, that's aspectual. | 12:15 |
| gtristan | I'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 machine | 12:17 |
| gtristan | And to be honest I dont even know if you agree with that or not, I'm drawing a blank | 12:17 |
| locallycompact | No I agree with that | 12:17 |
| gtristan | Ok, 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 |
| locallycompact | except, I don't want mutating methods adding things to the representation without changing the type to match | 12:18 |
| locallycompact | pep 484 / mypi will help here | 12:19 |
| gtristan | In absence of that, just please try to describe how you would compartmentalize the various parts of this machine in mail and what these things do | 12:19 |
| gtristan | I'm going to eat though, now :) | 12:19 |
| gtristan | heh | 12:19 |
| gtristan | I do have a huge wiki page on pep 484 open since before btw | 12:20 |
| *** gtristan has quit IRC | 12:25 | |
| tiagogomes | gitlab is being so slow | 12:41 |
| jjardon | The ansible repo seems to still be problematic, does anyone have any time to check if something strange happen with It? | 13:04 |
| tiagogomes | 1 sec | 13:05 |
| tiagogomes | grr slowlab... | 13:06 |
| pedroalvarez | I have already checked | 13:06 |
| pedroalvarez | nothing looks wrong in there | 13:06 |
| pedroalvarez | If anyone can reproduce the error and prove that there is something wrong in the trove, I'll investigate | 13:07 |
| tiagogomes | This PR can potentially fix the problem with ansible repo: https://gitlab.com/baserock/ybd/merge_requests/252 . | 13:08 |
| pedroalvarez | sounds scary | 13:09 |
| pedroalvarez | also, nice patch and reasoning | 13:10 |
| tiagogomes | 👍 | 13:11 |
| *** SotK_ is now known as SotK | 13:11 | |
| *** edcragg has joined #baserock | 13:27 | |
| locallycompact | https://gitlab.com/baserock/ybd/builds/5188628 | 13:32 |
| *** jjardon_matrix has quit IRC | 13:37 | |
| *** jjardon_matrix has joined #baserock | 13:37 | |
| *** jude_ has quit IRC | 14:01 | |
| *** toscalix has joined #baserock | 14:09 | |
| *** jude_ has joined #baserock | 14:15 | |
| leeming | http://paste.baserock.org/ohacekujej | 14:17 |
| leeming | anyone know/could suggest/provide insight into this root build command | 14:17 |
| leeming | stage2-glibc seems to state : sh -c -e 'install -m 644 -o root -g root ld.so.conf "$DESTDIR/etc/ld.so.conf"' | 14:18 |
| paulsherwood | leeming: i'm guessing this is an implication of overlaps | 14:18 |
| * paulsherwood may be wrong though | 14:18 | |
| leeming | my simple brain tells me this might be a blocker for non-root builds | 14:18 |
| * leeming wonders if the namespacing of root would fix this | 14:20 | |
| *** CTtpollard has joined #baserock | 14:33 | |
| *** thinkl33t has joined #baserock | 14:50 | |
| *** toscalix has quit IRC | 15:16 | |
| *** gtristan has joined #baserock | 15:26 | |
| rdale | i don't know if it helps, but in the above command DESTDIR would be set to /tools | 15:50 |
| leeming | ive not changed any of the definitions. Just changing the sandbox tool | 15:59 |
| leeming | but im not educated enough to know if that is an issue or not? | 16:00 |
| locallycompact | $PREFIX would be set to /tools. | 16:01 |
| locallycompact | not DESTDIR | 16:01 |
| rdale | yes, please ignore my comment | 16:01 |
| locallycompact | why would overlaps be putting things in destdir | 16:02 |
| *** ctbruce has quit IRC | 16:19 | |
| locallycompact | can someone help me debug a thing by leaving a build on overnight | 16:30 |
| pedroalvarez | use gitlab ci? | 16:32 |
| locallycompact | I can't shell into gitlab ci runners | 16:33 |
| locallycompact | and it doesn't preserve artifacts between runs | 16:38 |
| leeming | do you just need a second (non arch) machine to test on? | 16:39 |
| locallycompact | yeah | 16:39 |
| leeming | I guess i could | 16:39 |
| locallycompact | pip3 install defslib | 16:40 |
| locallycompact | this branch of ybd https://gitlab.com/baserock/ybd/commits/staging/010 | 16:40 |
| leeming | tiagogomes, sorry if you are seeing PR for sandboxlib, update on https://github.com/CodethinkLabs/sandboxlib/pull/25 | 16:40 |
| locallycompact | this branch of definitions https://gitlab.com/baserock/definitions/commits/lc/010 | 16:40 |
| leeming | has defslib been updated? | 16:42 |
| locallycompact | yeah | 16:42 |
| locallycompact | shoulod be 0.1.14 | 16:42 |
| leeming | erk. how to check python lib versions | 16:42 |
| locallycompact | does it not say when you pip it | 16:43 |
| pedroalvarez | pip freeze | 16:43 |
| locallycompact | oh nice | 16:43 |
| pedroalvarez | (the only way I know) | 16:43 |
| leeming | Requirement already satisfied (use --upgrade to upgrade): defslib in /usr/local/lib/python3.4/dist-packages | 16:43 |
| leeming | Cleaning up... | 16:43 |
| leeming | tells me nuthin | 16:44 |
| pedroalvarez | that says a lot actually | 16:44 |
| leeming | pip freeze? | 16:44 |
| locallycompact | --upgrade | 16:44 |
| pedroalvarez | says that you already have defslib installed, and if you want to upgrade, you need to use --upgrade | 16:44 |
| leeming | thought it would tell me that i have xx installed and yy is latest | 16:45 |
| leeming | like it tells me after i run upgrade | 16:45 |
| leeming | "Found existing installation: defslib 0.1.9" | 16:45 |
| locallycompact | pip freeze is a silly name for that command | 16:46 |
| locallycompact | should say | 16:46 |
| locallycompact | Successfully installed defslib-0.1.14 | 16:46 |
| leeming | yes it installed | 16:46 |
| leeming | just moaning about pip :P | 16:46 |
| leeming | I thought python had a module.__version__ attribute :( | 16:47 |
| leeming | oh common gitlab! | 16:50 |
| leeming | oops! ignore that.. remote is pointing to the wrong gitlab :P | 16:52 |
| *** toscalix has joined #baserock | 16:54 | |
| tiagogomes | leeming, to solve the problem that you have pasted above, have you tried to run bbrwap with `--gid 0 -- uid 0` ? | 16:57 |
| tiagogomes | This works fine for me `bwrap --bind / / --uid 0 --gid 0 sh -c 'touch FOO && chown root:root FOO` | 16:57 |
| leeming | ah, good catch | 16:58 |
| leeming | re man page "Custon gid in the sandbox (requires --unshare-user)" | 16:58 |
| tiagogomes | --uid implies --unshare-user | 16:58 |
| leeming | docs should say implies then :) | 16:59 |
| leeming | i 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 root | 17:00 | |
| leeming | nor me, but a lot of things happen without me know what is going on :) and i was tasked to do this | 17:01 |
| locallycompact | dw about me | 17:02 |
| leeming | running the sandbox always with --uid=1 a good idea? | 17:02 |
| leeming | sorry s/1/0/ | 17:03 |
| leeming | hmm patched and just started off a ybd build | 17:06 |
| tiagogomes | I don't see any problem with that. Note that although the user appears to be root, it doesn't have the root privileges | 17:06 |
| *** toscalix has quit IRC | 17:07 | |
| leeming | my bwrap doesn't run your command btw, seem to still require --unsure-user to be set | 17:08 |
| tiagogomes | That looks solvable. | 17:09 |
| *** toscalix has joined #baserock | 17:11 | |
| leeming | blurh, seems to be a specific order of where to put --uid | 17:12 |
| * leeming scratches head at "Unknown option --uid 0" | 17:15 | |
| tiagogomes | which bbwrap version have u got | 17:16 |
| leeming | 0.1.2 | 17:16 |
| leeming | odd though... running it outside of ybd/sandboxlib, it seems to not throw that error | 17:16 |
| tiagogomes | That means that you are doing it wrong in sandboxlib :P | 17:18 |
| tiagogomes | What is the argument line that you giving in sandboxlib? | 17:18 |
| leeming | s/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 --uid | 17:19 |
| leeming | 0 --gid 0 <COMMAND> | 17:19 |
| leeming | where testing with just a simple ls worked :P | 17:19 |
| *** toscalix has quit IRC | 17:21 | |
| tiagogomes | You can probably replace `--bind // --remount-ro /` with `--ro-bind //`. But that won't do much difference | 17:23 |
| *** toscalix has joined #baserock | 17:23 | |
| tiagogomes | Also, you appear to do the same --bind twice for stage1-binutils.inst | 17:24 |
| leeming | --ro-bind / /, does not work if you are mounting anything else | 17:25 |
| * leeming looks at the double mount | 17:25 | |
| *** toscalix has quit IRC | 17:25 | |
| tiagogomes | Hmm, even if --ro-bind / / is the last argument of the command? | 17:25 |
| leeming | hmm last ey? | 17:26 |
| leeming | I'm sure i must have tried that | 17:26 |
| leeming | bwrap requires directories to exist, no? so thought it would have ot be first? | 17:26 |
| * leeming shrugs | 17: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 /BANANAS | 17:27 |
| tiagogomes | touch: cannot touch '/BANANAS': Read-only file system | 17:27 |
| leeming | like i siad, i dont know what im doing :P | 17:27 |
| tiagogomes | wfm ^ | 17:27 |
| leeming | i tried all sorts of arcane configurations before i could get it working | 17:28 |
| leeming | no body seemed to know how to help at the time | 17:28 |
| leeming | hindsight is great :) | 17:28 |
| * leeming wonders if the "Unknown option --uid 0" error is from bwrap or from ybd / somewhere else | 17:29 | |
| leeming | sandboxlib (bubblewrap impl) should log issues, and i do no see that in the logs | 17:30 |
| leeming | oops..... | 17:30 |
| tiagogomes | paste the code where you invoke bwrap | 17:32 |
| leeming | code was in the wrong place, but still did correct thing.. | 17:32 |
| *** locallycompact has quit IRC | 17:32 | |
| leeming | arg wrap | 17:32 |
| leeming | http://paste.baserock.org/obasigasom | 17:32 |
| tiagogomes | that won't work, because the command to run inside the sandbox is not escaped | 17:34 |
| * leeming notes that *.inst is only stated once in the log, so i clearly do mount twice | 17:34 | |
| tiagogomes | you probably need to change the implementation of bubblewrap run_command to accept a list of arguments | 17:35 |
| tiagogomes | And not a string with the full command | 17:36 |
| leeming | it is doing the same as the other implementations | 17:36 |
| leeming | i.e. a string with the full command | 17:36 |
| leeming | it worked when run as root + without the --uid 0 stuff | 17:37 |
| leeming | but yes, cleaner to encapsulate in quotes | 17:37 |
| tiagogomes | Tomorrow I can look at your code if you push it somewhere | 17:38 |
| * tiagogomes disappears in a cloud of dark smoke | 17:38 | |
| leeming | mysterious | 17:38 |
| leeming | thanks | 17:38 |
| leeming | oh, is that the time? | 17:38 |
| *** jjardon_matrix has quit IRC | 17:42 | |
| leeming | if 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 #baserock | 17:56 | |
| *** gtristan has quit IRC | 19:30 | |
| *** lachlanmackenzie has joined #baserock | 20:07 | |
| *** lachlanmackenzie has quit IRC | 22:33 | |
Generated by irclog2html.py 2.15.3 by Marius Gedminas - find it at mg.pov.lt!