| *** gtristan has joined #baserock | 03:37 | |
| *** gtristan has quit IRC | 06:06 | |
| *** gtristan has joined #baserock | 06:34 | |
| *** fay has joined #baserock | 07:20 | |
| *** fay is now known as Guest5915 | 07:20 | |
| *** Guest5915 is now known as faybrocklebank | 07:20 | |
| *** ctbruce has joined #baserock | 07:31 | |
| *** rdale has joined #baserock | 07:38 | |
| *** locallycompact has joined #baserock | 09:26 | |
| locallycompact | now with drag drop and zoom http://baserock.gitlab.io/defslib/ | 09:42 |
|---|---|---|
| paulsherwood | locallycompact: cool. while you're on, can you think back to how we handled git submodules before you improved definitions? | 09:43 |
| paulsherwood | did we ever handle them recursively? | 09:43 |
| paulsherwood | there was some conversation here that claimed so, but i can't understand how it would have worked | 09:43 |
| locallycompact | *before* V8? | 09:44 |
| paulsherwood | or after | 09:44 |
| paulsherwood | it doesn't work now, that's for sure | 09:44 |
| pedroalvarez | I think I checked ybd code when we moved to v8, and it was recursive | 09:44 |
| pedroalvarez | or at least it looked recursive, and to do the right thing | 09:44 |
| SotK | yes, I'm pretty sure it used to be correctly recursive | 09:45 |
| tiagogomes | Morph used to do them recursively, by parsing .gitmodules | 09:46 |
| paulsherwood | is there any example of this in our actual definitions? if ybd doesn't do the right thing, i wonder how come it builds ci.morph sueccessfully | 09:47 |
| pedroalvarez | paulsherwood: it may build it, but fetching the code from a different place (not g.b.o) | 09:47 |
| locallycompact | Is there anything in definitions with two layers of submodules? | 09:47 |
| SotK | pedroalvarez: I think the issue was that the nested submodules weren't even being checked out | 09:47 |
| pedroalvarez | right, someone should try to reproduce it then] | 09:48 |
| pedroalvarez | locallycompact: there was something.. introduced when integrating openstack | 09:49 |
| pedroalvarez | will try to find out | 09:49 |
| paulsherwood | https://irclogs.baserock.org/%23baserock.2016-09-30.log.html#t2016-09-30T14:49:34 is the previous conversation on this | 09:50 |
| * paulsherwood is curious how SotK could be so clear that https://irclogs.baserock.org/%23baserock.2016-09-30.log.html#t2016-09-30T15:32:31 was the breaking commit? | 09:50 | |
| locallycompact | this bit surely https://gitlab.com/baserock/ybd/commit/4072533d598e332e0e88a859e0b38a92568aceac#6b62905b9aafce15e2b8dbbb906882cc418687c9_261_270 | 09:51 |
| SotK | locallycompact: yes | 09:52 |
| SotK | paulsherwood: by keeping the call to checkout_submodules() in checkout() but making checkout_submodules() call _checkout() instead, checkout_submodules() is only called for the first level | 09:53 |
| SotK | (ie, it isn't called when checking out a submodule, and it should be) | 09:54 |
| pedroalvarez | will the patch only remove the "_" :P | 09:55 |
| pedroalvarez | ? | 09:55 |
| * paulsherwood has been working on non-code things for so long, he is struggling to grok basic python | 09:56 | |
| SotK | I'd move the checkout_submodules stuff into _checkout to replicate the old behaviour | 09:57 |
| SotK | where stuff == call | 09:57 |
| paulsherwood | SotK: ack, thanks. i'm trying to find a 'volunteer' to do the actual work :) | 10:02 |
| paulsherwood | locallycompact: so looking at your visualisation, you've now got that base-system contains minimal-system + some other sets/strata? | 10:03 |
| paulsherwood | (shiny, btw) | 10:04 |
| locallycompact | right | 10:04 |
| paulsherwood | so is your schema generic for nesting of these sets? eg foo could contain base-system + other sets | 10:05 |
| locallycompact | right | 10:05 |
| paulsherwood | does 'right' mean 'yes'? | 10:05 |
| locallycompact | yes | 10:05 |
| paulsherwood | :) | 10:05 |
| paulsherwood | great, then. and your new proposed name for these generic sets is 'assemblage'? | 10:06 |
| locallycompact | yes | 10:06 |
| paulsherwood | and an assemblage could be (say) a system (bootable set) or a stratum... but not a cluster? | 10:06 |
| locallycompact | yes, strata and system no longer have syntactic specifications, a strata is an assemblage that lives in another assemblage, a system is an assemblage that has certain constraints on its lower strata so that it is bootstrappable and also can boot, etc | 10:08 |
| locallycompact | that's not in the ontology yet, but system and strata schemas are gone | 10:09 |
| * paulsherwood likes this | 10:10 | |
| paulsherwood | did i hear someone mumble that 'defslib nearly builds' already? | 10:10 |
| locallycompact | Does, nearly | 10:12 |
| *** franred has joined #baserock | 10:12 | |
| tiagogomes | If ybd and and defslib are on gitlab, shouldn't sandboxlib be there was well | 10:13 |
| locallycompact | sanboxlib is on gitlab | 10:13 |
| tiagogomes | ah ok, does it sync from github sandboxlib? | 10:14 |
| locallycompact | I think it is | 10:14 |
| leeming | it should do | 10:14 |
| tiagogomes | Anyway that is confusing | 10:14 |
| paulsherwood | it's probably time for some cleaning up. i agree this and other things are confusing | 10:15 |
| leeming | i was only using gitlab for the ci | 10:15 |
| tiagogomes | I am planning to merge https://github.com/CodethinkLabs/sandboxlib/pull/24 if no review happens by tomorrow. | 10:24 |
| paulsherwood | leeming: ^^ | 10:29 |
| *** franred has quit IRC | 10:30 | |
| tiagogomes | I would appreciate code review, and not only checking whether the tests pass or not. | 10:31 |
| *** franred has joined #baserock | 10:44 | |
| leeming | a few small issues, i am seeing if i can clean it up | 10:49 |
| *** jjardon_matrix has quit IRC | 10:50 | |
| leeming | tiagogomes, where do the params for test functions get sourced from? | 10:55 |
| tiagogomes | wut | 10:56 |
| leeming | ah nevermind. I was just debugging some of your code... you seem to have the wrong indentation set | 10:57 |
| *** gtristan has quit IRC | 10:58 | |
| jjardon | tiagogomes: are you one of the owners of the sandboxlib project? If yes, we can move it to gitlab instead mirroring it | 11:01 |
| pedroalvarez | is defslib going to be another builder? or will ybd sit on top of defslib to do the work? | 11:03 |
| locallycompact | defslib has a reference implementation for V10 | 11:03 |
| pedroalvarez | to parse definitions or to parse and build? | 11:04 |
| locallycompact | build | 11:04 |
| locallycompact | it wasn't going to but it needs to be able to clone in order to calculate cache keys | 11:04 |
| *** jjardon_matrix has joined #baserock | 11:04 | |
| locallycompact | and since it's all sorted and flattenable | 11:04 |
| locallycompact | then building is not that much extra | 11:04 |
| pedroalvarez | hah | 11:06 |
| pedroalvarez | not sure if that makes a lot of sense, but ok :) | 11:06 |
| locallycompact | defslib can sort topologically by build dependency using this https://pypi.python.org/pypi/toposort | 11:07 |
| locallycompact | so it can do that for the whole assemblage | 11:07 |
| locallycompact | then it can flatten the assemblage to a list of chunks, filling in the build-dependencies as it flattens | 11:08 |
| pedroalvarez | :) | 11:08 |
| locallycompact | then building is for x in chunks: | 11:08 |
| locallycompact | because they are sorted | 11:08 |
| *** jjardon_matrix has quit IRC | 11:09 | |
| pedroalvarez | I didn't expect another build tool, that's all | 11:10 |
| pedroalvarez | but I welcome it | 11:10 |
| locallycompact | You can just use the resolver validator and the cache key logic and use your own build logic | 11:11 |
| locallycompact | that works already | 11:11 |
| *** franred_ has joined #baserock | 11:13 | |
| *** jjardon_matrix has joined #baserock | 11:15 | |
| leeming | so far it is easier to read too, although it is basic atm | 11:16 |
| *** franred has quit IRC | 11:17 | |
| leeming | needs comments ;) | 11:17 |
| pedroalvarez | heh | 11:17 |
| pedroalvarez | other build tools were easy to read when they only had basic functionality | 11:18 |
| *** ctbruce has quit IRC | 11:19 | |
| *** ctbruce has joined #baserock | 11:20 | |
| tiagogomes | jjardon I believe I am one of the owners yes, but I leave that work to someone that is more knowledgeable of what Baserock will use for its infrastructure. | 11:26 |
| * tiagogomes is unsure if gerrit is still used or not | 11:26 | |
| jjardon | tiagogomes: sandboxlib is not in baserock infra at the moment ... | 11:26 |
| jjardon | but sure your choice | 11:27 |
| *** anahuelamo__ is now known as anahuelamo | 11:27 | |
| pedroalvarez | can any of the infrastructure creators join the infrastructure team? | 11:28 |
| pedroalvarez | and take some decissions and clean up this mess? | 11:29 |
| jjardon | what mess? | 11:29 |
| * SotK wouldn't mind helping out but probably only has useful time at the weekends | 11:30 | |
| *** anahuelamo_ has joined #baserock | 11:31 | |
| pedroalvarez | what is baserock infra and what not | 11:31 |
| *** anahuelamo_ has quit IRC | 11:31 | |
| pedroalvarez | what is baserock using and what not | 11:31 |
| pedroalvarez | in how many different places are we going to have the code, and accept patches | 11:32 |
| pedroalvarez | issue trackers | 11:32 |
| pedroalvarez | etc | 11:32 |
| pedroalvarez | also, what is baserock and what not | 11:32 |
| jjardon | AFAIK, nothing has changed (yet); I was about to send an email to change the canonical location of definition from git.baserock.org to gitlab.com/baseock/definitions but didnt have the time. Maybe now is a good moment | 11:33 |
| * SotK wouldn't like that | 11:34 | |
| pedroalvarez | I wouldn't like that either, but I'm not going to vote | 11:34 |
| jjardon | SotK: why not? we can use the gitlab ci and get what we always wanted: pre-commin ci and a flexible ci system. Some people is already using the mirror in gitlab.com/baserock/definitions for this reason | 11:35 |
| pedroalvarez | I say it again, I'd appreciate if people wanting to make decisions about the infra, joinded the infra team | 11:35 |
| SotK | jjardon: what happens if gitlab.com ceases to exist for some currently-unforeseen reason? | 11:37 |
| tiagogomes | Who are in the infra team these days? Pedro and Gary? | 11:37 |
| jjardon | SotK: we can setup our own gitlab instance if that concerns you | 11:37 |
| pedroalvarez | yeah, sssam also, but he is not around these days | 11:37 |
| SotK | I thought we care about maintaining git.b.o to ensure that git repositories we care about don't disappear | 11:37 |
| jjardon | git.b.o doesnt have to disappear | 11:38 |
| pedroalvarez | my question still stands | 11:38 |
| jjardon | pedroalvarez: what is your question? | 11:38 |
| pedroalvarez | well, not question | 11:39 |
| pedroalvarez | <pedroalvarez> I say it again, I'd appreciate if people wanting to make decisions about the infra, joinded the infra team | 11:39 |
| franred_ | jjardon, probably what pedroalvarez wants to say is given that someone has create the gitlab infra, and you want to make it canonical, one of you should be part or the operations team (it that replaces completely the whole infrastructure) | 11:40 |
| jjardon | I do not agree with that | 11:40 |
| pedroalvarez | I just want to get out of the way | 11:41 |
| jjardon | and setup that infra in a couple of minutes in my free time to test it; if people think is cool and useful (as I think it is), I propose to switch; I do not think is needed any bureaucracy joining other teams to do that | 11:42 |
| jjardon | pedroalvarez: nobody is on the way :) I was hopping the people to try it and have their own opinnion before propossing any change | 11:43 |
| pedroalvarez | so, you set it up, and then forget about it | 11:44 |
| pedroalvarez | :) | 11:44 |
| jjardon | no at all; I'm using it all the time! | 11:45 |
| * jjardon will write an email to the mailing list | 11:45 | |
| pedroalvarez | using != maintaining | 11:46 |
| jjardon | pedroalvarez: SotK any other concerns about moving the canonical location of definitions to gitlab.com/baserock/definitions ? | 11:46 |
| leeming | is this re: sandboxlib? | 11:46 |
| leeming | because it has existed on github for a few years now? | 11:47 |
| pedroalvarez | I don't have any concerns, just joing the infra team | 11:47 |
| jjardon | pedroalvarez: No need to mantain a project hosted in gitlab.com | 11:47 |
| jjardon | gitlab do that for us | 11:48 |
| pedroalvarez | right, just join to maintain the bits you set up | 11:48 |
| jjardon | or Am I misunderstanding something? | 11:48 |
| pedroalvarez | (other things may happen) | 11:48 |
| pedroalvarez | (lorrying definitions may fail, forexample) | 11:49 |
| jjardon | lorrying defininitions? | 11:49 |
| SotK | if definitions' upstream is gitlab.com/baserock/definitions it'll need to be lorried into git.b.o is the meaning I think | 11:50 |
| SotK | someone should probably update the ybd lorry too incidentally | 11:51 |
| jjardon | SotK: do we actually need to lorry definitions back to g.b.o? | 11:53 |
| * SotK thinks it is verging on hypocritical not to | 11:55 | |
| SotK | since we maintain a mirror of the various projects in g.b.o to make it more likely that we can reproduce things in the future | 11:56 |
| SotK | and by not mirroring the definitions themselves there (or having them live there) that is pretty pointless | 11:56 |
| jjardon | well, if needed it will be lorried under /delta, so it should not conflict with the current repo location | 11:57 |
| SotK | but if that lorry breaks for whatever reason, who investigates and fixes it? | 11:58 |
| * SotK thinks pedroalvarez's point is that he doesn't have time to do so really | 11:58 | |
| * SotK may be misrepresenting there, and apologises if so | 11:59 | |
| locallycompact | V10 https://gitlab.com/baserock/spec/merge_requests/2/diffs | 12:50 |
| locallycompact | Things I still would like: | 12:51 |
| locallycompact | morph: replaced by $include: | 12:52 |
| pedroalvarez | also updaging the docstrings :P | 12:52 |
| pedroalvarez | oh no | 12:52 |
| pedroalvarez | it's ok, is v9, not v10 | 12:52 |
| pedroalvarez | ignore me | 12:53 |
| locallycompact | actually 10 has a typo | 12:53 |
| pedroalvarez | ah, I see, 2 versions at the same time | 12:54 |
| pedroalvarez | any reason to not send that patch to upstream? | 12:54 |
| * pedroalvarez runs away | 12:54 | |
| *** franred_ is now known as franred | 12:55 | |
| *** faybrocklebank has quit IRC | 13:04 | |
| *** fay has joined #baserock | 13:17 | |
| *** fay is now known as faybrocklebank | 13:18 | |
| locallycompact | how do I get actual information back from sandbox lib running a command | 14:30 |
| locallycompact | all I see is | 14:30 |
| locallycompact | cmd: ['sh', '-c', '-e', 'ls'], cwd: /stage1-binutils.build, env: {'TERM': 'dumb', 'PROGRAM_REF': 'my-version', 'DESTDIR': 'stage1-binutils.install', 'DEFINITIONS_REF': 'def-version', 'LC_ALL': 'C', 'USER': 'tomjon', 'TARGET_STAGE1': 'cpu-bootstrap-linux-gnu', 'CCACHE_DIR': '/tmp/ccache', 'LOGNAME': 'tomjon', 'CCACHE_EXTRAFILES': '', 'USERNAME': 'tomjon', 'TZ': 'UTC', 'SHELL': '/bin/sh', 'MAKEFLAGS': '-j 1', 'MORPH_ARCH': 'x86_64' | 14:30 |
| locallycompact | , 'TARGET': 'cpu-baserock-linux-gnu', 'HOME': '/tmp'}, filesystem_root: tmp/tmpx3ohzmj5,filesystem_writable_paths: all, mounts: isolated, extra_mounts: [('tmp/tmpx3ohzmj5/stage1-binutils.build', 'stage1-binutils.build', None), ('tmp/tmpx3ohzmj5/stage1-binutils.install', 'stage1-binutils.install', None), ('tmp/tmpx3ohzmj5/baserock', 'baserock', None), ('tmpfs', '/tmp', 'tmpfs'), ('proc', '/proc', 'proc'), ('dev', '/dev', 'dev')], | 14:30 |
| locallycompact | network: isolated, stderr: -1, stdout: -1 | 14:30 |
| locallycompact | hm wat | 14:30 |
| locallycompact | leeming, what are those extra mounts? | 14:31 |
| leeming | extra as in thing.install, thing.build? | 14:38 |
| locallycompact | I'm simply perplexed | 14:39 |
| locallycompact | What is a mount | 14:39 |
| leeming | what are you asking? just how to get data out? | 14:39 |
| locallycompact | I checked out the thing to .build | 14:39 |
| leeming | the mapping of host directory to sandbox directory | 14:40 |
| locallycompact | so it's there in the filesystem | 14:40 |
| locallycompact | these are already in the sandbox directory | 14:40 |
| locallycompact | now I get | 14:41 |
| locallycompact | RuntimeError: ['mount', '-t', 'dev', 'dev', 'tmp/tmpudjfj8lh/dev'] failed: mount: unknown filesystem type 'dev' | 14:41 |
| leeming | ? | 14:41 |
| leeming | are we on the same page here? :\ | 14:41 |
| locallycompact | no, clearly | 14:42 |
| leeming | ohhh dev | 14:42 |
| * leeming looks in the code + bwrap docs | 14:42 | |
| locallycompact | that's with chroot | 14:42 |
| locallycompact | with bubblewrap it is ind of fine | 14:42 |
| locallycompact | but still stdout: -1 with no information | 14:43 |
| leeming | oh | 14:43 |
| leeming | you downstairs ? | 14:43 |
| locallycompact | ye | 14:43 |
| leeming | 2secs | 14:43 |
| *** gtristan has joined #baserock | 15:02 | |
| *** toscalix has joined #baserock | 15:29 | |
| locallycompact | When I run the configure for stage1-binutils inside a sandbox with the host rootfs='/', I get a Makefile out | 15:50 |
| locallycompact | When I run it inside the sandbox I get gcc: error trying to exec 'cc1': execvp: No such file or directory | 15:50 |
| locallycompact | What's going on | 15:50 |
| tiagogomes | If in the second time the root of the sandbox is not '/', they no compiler will be installed in the sandbox, hence that error | 16:13 |
| locallycompact | it is '/' | 16:13 |
| locallycompact | It finds gcc fine | 16:14 |
| locallycompact | configure:4246: gcc --version >&5 | 16:14 |
| locallycompact | gcc (GCC) 6.1.1 20160707 | 16:14 |
| tiagogomes | So what is the difference between the two runs? Is not clear to me what you changed | 16:14 |
| jmacs | locallycompact: Does it find cc1? | 16:14 |
| jmacs | cc1 | 16:14 |
| locallycompact | that's unclear | 16:15 |
| locallycompact | tiagogomes, sorry I misspoke | 16:15 |
| locallycompact | the first one was on the host | 16:15 |
| locallycompact | the second one was in rootfs='#/' | 16:15 |
| locallycompact | '/' | 16:15 |
| *** ctbruce has quit IRC | 16:16 | |
| tiagogomes | That makes more sense. Are /usr or /lib{,64} in your host are in the same partition as '/' | 16:17 |
| locallycompact | yeah | 16:17 |
| tiagogomes | And as jmac said, your host can run cc1? | 16:17 |
| locallycompact | cc1 not on my path | 16:18 |
| locallycompact | I think | 16:18 |
| locallycompact | the host completes the configure though | 16:18 |
| jmacs | There needs to be a cc1 executable somewhere and your gcc executable needs to know where it is | 16:19 |
| jmacs | It's possible you have a bad gcc executable | 16:19 |
| jmacs | But without know how sandbox works I couldn't guess how you got there | 16:20 |
| *** toscalix has quit IRC | 17:01 | |
| *** locallycompact has quit IRC | 17:23 | |
| *** ctbruce has joined #baserock | 17:28 | |
| JasonA | Sotk: I see you were wondering my progress. Sorry, its been busy around here. I have not quite gotten the submodule fix working, and I have had to move on for now. I will revisit once I get a chance in the next week or so | 17:53 |
| *** gtristan has quit IRC | 19:19 | |
| SotK | JasonA: no need to apologise, I was just wondering if my suggestion had worked :) | 21:36 |
| SotK | on an unrelated note: people who want yaml lorries may be interested in https://gerrit.baserock.org/#/c/2311/ | 21:37 |
| *** ctbruce has quit IRC | 21:37 | |
| *** rdale has quit IRC | 22:03 | |
| SotK | also: https://gerrit.baserock.org/#/c/2312/ | 22:17 |
Generated by irclog2html.py 2.15.3 by Marius Gedminas - find it at mg.pov.lt!