| *** locallycompact has quit IRC | 00:10 | |
| *** gtristan has quit IRC | 06:08 | |
| *** gtristan has joined #baserock | 06:38 | |
| paulsherwood | tiagogomes: ssam should be but i don't know where he is | 07:06 |
|---|---|---|
| *** paulwaters_ has joined #baserock | 07:14 | |
| *** toscalix has joined #baserock | 07:32 | |
| *** ctbruce has joined #baserock | 07:37 | |
| *** franred has joined #baserock | 08:28 | |
| *** rdale has joined #baserock | 08:34 | |
| gtristan | In the artifact metadata... I find the metadata lists all files and their parent directories which are found in the artifact, but there is an inconsistency regarding the ${package}.meta file itself | 08:41 |
| gtristan | it seems that every -misc artifact lists the baserock directory and omits the meta file itself | 08:42 |
| gtristan | How should this be fixed; do we ignore/remove the baserock/ meta directory from the artifact splitting rules entirely ? Or should we specify the metadata file ? | 08:42 |
| paulsherwood | gtristan: i've started thinking about this already, because radiofree has a use-case where the current splitting doesn't keep up | 08:53 |
| paulsherwood | i.e. he wants to create a new default rule, and apply that for a system. but existing chunks were built without any knowledge of the new rule | 08:54 |
| paulsherwood | so i think this means that chunk metadata should be just a list of files, and rules only apply at system-creation-time | 08:55 |
| gtristan | Not sure exactly what that means, you mean split the whole system up in different ways than which the chunks were already split ? | 08:55 |
| gtristan | hmmm | 08:55 |
| paulsherwood | chunks are not actually 'split' at the moment. each chunk artifact contains all the files... the chunk.meta describes what possible split-chunks should contain | 08:56 |
| gtristan | right | 08:56 |
| paulsherwood | but it would be better to figure out the split-chunks only when they're needed | 08:56 |
| gtristan | I'm not sure what is the reason to change this, but I'm sure radiofree has one :) | 08:57 |
| gtristan | I.e. seems to me pretty similar, to define the data either at chunk creation time or system creation time | 08:57 |
| gtristan | but perhaps there is more context in play at that point ? | 08:57 |
| paulsherwood | he has a new rule... let's call it 'ultra-splitting'... wants to build systems with it... but it shouldn't require a full rebuild of all the chunks | 08:58 |
| gtristan | I'm a bit skeptical of that though (at first sight at least), because if the splitting would be done differently at system creation time; then the result is... | 08:58 |
| gtristan | the same stratum of chunks might end up being split differently; /depending/ on which system they were included in ?? | 08:58 |
| gtristan | which sounds unstable | 08:59 |
| paulsherwood | put it another way... any splitting rules should only affect the cache-key of systems which apply that rule. chunks should be the same | 08:59 |
| gtristan | Sure | 09:00 |
| paulsherwood | the split applies for stratum and system, not chunk | 09:00 |
| gtristan | Ok so in any case, we're still going to end up with a phase where a system is an artifact, and contains a baserock/ subdirectory containing meta files for each chunk, with their splitting rules in there | 09:01 |
| gtristan | Only that the generation of that metadata will occur later on... correct ? | 09:01 |
| paulsherwood | yup | 09:01 |
| paulsherwood | so the chunk metadata will not contain any split information | 09:02 |
| gtristan | Sure, that worksforme... | 09:02 |
| paulsherwood | ack. now i just need to code it :-) | 09:03 |
| gtristan | so in any case, the question I am asking is unrelated I think | 09:03 |
| gtristan | Should the metadata itself be encoded into the artifacts in splitting rules ? Or not ? | 09:04 |
| gtristan | I tend to lean towards not | 09:04 |
| paulsherwood | yup, i just wanted to highlight that i'm about to change the metadata anyway | 09:04 |
| gtristan | Yup | 09:04 |
| * paulsherwood tries to wrangle what gtristan is thinking/wanting | 09:04 | |
| gtristan | Because this metadata seems to currently at least be generated at various levels, and for instance strata metadata files remain unmentioned | 09:04 |
| paulsherwood | unmentioned? | 09:05 |
| gtristan | There is no way I can see that the strata metadata file is included in any assembled system | 09:05 |
| * paulsherwood is pretty sure it is | 09:06 | |
| paulsherwood | but i may be wrong of course | 09:06 |
| gtristan | paulsherwood, Ok what I'm looking at is basically: Chunk meta files list the baserock/ directory in their -misc artifact (but FAIL to mention the filename itself) | 09:07 |
| *** locallycompact has joined #baserock | 09:07 | |
| gtristan | paulsherwood, while there is no rule that says, that a specific artifact should be generated containing a stratum metafile at all | 09:07 |
| gtristan | paulsherwood, so I can sort of infer that for say, the acl build, it's acl.meta says that acl-misc claims what is in the 'baserock/' directory | 09:08 |
| gtristan | However, nothing says that core.meta should be included in any artifact | 09:09 |
| gtristan | at all | 09:09 |
| * paulsherwood is downloading an acl artifact from kbas | 09:09 | |
| * gtristan chooses acl because it's just alphabetically first | 09:09 | |
| gtristan | paulsherwood, notice though; that our conversation is entirely distorted, because we now have 2 definitions of the word 'artifact' | 09:10 |
| * paulsherwood only has one... a tarball generated by ybd (since this conv is not about morph's approach( but it has different characteristics depending on whether it's of a chunk, stratum, system | 09:11 | |
| gtristan | paulsherwood, http://paste.baserock.org/sogayayeri | 09:12 |
| gtristan | paulsherwood, right, in for instance our conversation yesterday I used the term artifact with franred in a different way | 09:13 |
| paulsherwood | ok, to mean what? | 09:13 |
| gtristan | I.e. that a chunk is split into multiple artifacts | 09:13 |
| gtristan | Do we even have a word for that ? | 09:13 |
| * paulsherwood doesn't | 09:13 | |
| gtristan | or that's what I meant, maybe I didnt use that word exactly | 09:13 |
| gtristan | <gtristan> franred, ah I see what you mean, in which case the licence needs to be something at the artifact splitting level | 09:14 |
| paulsherwood | morph artifacts are pre-split | 09:14 |
| paulsherwood | sorry.. by that i mean morph generates foo-bin foo-lib foo-misc | 09:14 |
| gtristan | Right | 09:14 |
| locallycompact | Those are just artifacts | 09:14 |
| locallycompact | split :: Artifact -> List<Artifact> | 09:15 |
| gtristan | Ok so... My question is, does the baserock metadata go into an artifact (as in, a split up artifact, a piece of a chunk), or does it not ? | 09:15 |
| gtristan | A chunk tarball with cache key currently stores a baserock/ directory with it's metafile, and does that go into any 'artifact' ? does it belong inside foo-misc ? | 09:16 |
| gtristan | Or should it be omitted entirely :) | 09:16 |
| SotK | (there are stratum artifacts and system artifacts too, they aren't just for chunks) | 09:16 |
| paulsherwood | gtristan: i accept that there's an inconsistency, ie /baserock is not only for foo-misc. but i'm not sure what you want to *do* with the metadata so i don't know how to answer yet | 09:17 |
| rdale | when a system is assembled by ybd, any artifacts which are split will have only the meta data in /baserock for the split parts that they use | 09:17 |
| gtristan | paulsherwood, generate rpms of course :) | 09:17 |
| gtristan | paulsherwood, practical reason for the question: I have this obnoxious baserock/ directory listed, and an orphaned foo.meta file | 09:18 |
| *** ctbruce has quit IRC | 09:18 | |
| gtristan | If the splitting medatata lists the baserock directory at all, it should list the file so it can be claimed and packaged | 09:18 |
| gtristan | or not list the baserock directory at all, leaving it as a special case | 09:18 |
| paulsherwood | aha. so in my proposed scheme, foo-chunk/baserock/foo.meta would contain a list of all files including /baserock/foo.meta, no split information | 09:19 |
| paulsherwood | ie it will list the file | 09:19 |
| gtristan | Ok. | 09:19 |
| gtristan | paulsherwood, however that raises the interesting question: How do stratum and system metadata files get 'claimed' ? | 09:20 |
| paulsherwood | gtristan: are you proposing to create rpms of strata and systems too? | 09:20 |
| *** ctbruce has joined #baserock | 09:21 | |
| gtristan | paulsherwood, no, I'm questioning why the metadata files should be considered in the splitting rules at all, if only some of that metadata is to be claimed and other metadata not | 09:21 |
| paulsherwood | i'm aiming towards: chunk.meta lists all files. stratum/baserock contains chunk-misc.meta, chunk-bin.meta etc, but not a copy of chunk.meta | 09:25 |
| *** persia_ has quit IRC | 09:28 | |
| gtristan | foo-chunk.meta lists all files, I tend to disagree that it should list itself as one of those files; this means that... bar-stratum/baserock/foo-chunk-misc.meta should list the file baserock/foo-chunk.meta ? Which then makes me wonder... at the end of the day, where is baserock/foo-chunk-misc.meta listed ? | 09:30 |
| gtristan | paulsherwood, ^^^ you see how this is sort of circular ? | 09:30 |
| paulsherwood | i do, yes. i'm ok dropping chunk.meta from itself | 09:30 |
| gtristan | Heh | 09:31 |
| *** persia_ has joined #baserock | 09:31 | |
| paulsherwood | radiofree: if you're around, could you point to a ref of definitions with your example new splitting rule(s), please? | 09:32 |
| *** ctbruce has quit IRC | 09:53 | |
| * gtristan pulls out trivial patch https://gitlab.com/baserock/ybd/merge_requests/246 | 09:54 | |
| *** gtristan has quit IRC | 10:00 | |
| *** ctbruce has joined #baserock | 10:09 | |
| *** cphang has quit IRC | 11:01 | |
| tiagogomes | If no one objects, I would like to merge https://github.com/CodethinkLabs/sandboxlib/pull/23 | 11:08 |
| pedroalvarez | that repo could do with a little .travis script | 11:09 |
| SotK | tiagogomes: lgtm | 11:09 |
| tiagogomes | pedroalvarez one step at a time :) | 11:10 |
| pedroalvarez | :) | 11:11 |
| pedroalvarez | tiagogomes: please, merge that | 11:11 |
| *** cphang has joined #baserock | 11:13 | |
| *** cphang has quit IRC | 11:44 | |
| tiagogomes | So... I am trying to run linux-user-chroot without being root. I am getting a "execv: No such file or directory" error | 11:46 |
| tiagogomes | Strace shows this clone: Operation not permitted | 11:46 |
| pedroalvarez | namespaces support in kernel? or something like that? | 11:46 |
| tiagogomes | same command works with root | 11:46 |
| richard_maw | hm, you get ENOENT if a namespace flag is not supported I think | 11:47 |
| pedroalvarez | that error msg rings a bell | 11:48 |
| pedroalvarez | but can't recall atm | 11:48 |
| tiagogomes | `sudo /usr/bin/linux-user-chroot /tmp/pytest-of-tiagogomes/pytest-8/test_mount_point_writable_linu0/sandbox test-file-is-writable` | 11:50 |
| tiagogomes | `/usr/bin/linux-user-chroot /tmp/pytest-of-tiagogomes/pytest-8/test_mount_point_writable_linu0/sandbox /bin/test-file-is-writable` | 11:50 |
| tiagogomes | both are working | 11:50 |
| tiagogomes | But I don't understand why test-file-is-writable works as it is inside a bin directory in the chroot dir, unless linux-user-chroot sets $PATH? | 11:52 |
| tiagogomes | If so, why it doesn't for the non-root version | 11:53 |
| *** cphang has joined #baserock | 11:59 | |
| tiagogomes | moar things for sandboxlib: https://github.com/CodethinkLabs/sandboxlib/pull/24 | 12:17 |
| tiagogomes | leeming ^^ | 12:17 |
| *** cphang has quit IRC | 12:50 | |
| *** cphang has joined #baserock | 13:03 | |
| *** cphang has quit IRC | 13:08 | |
| tiagogomes | anyone fancies having a quick look at https://github.com/CodethinkLabs/sandboxlib/pull/24 | 13:16 |
| *** cphang has joined #baserock | 13:20 | |
| leeming | sorry back, will have a look in a sec tiagogomes | 13:33 |
| leeming | I also noticed/wondered where the path magic happened | 13:37 |
| leeming | but assumed there was some implicit /bin search for path | 13:37 |
| leeming | ahh good. i was not completely sure with this test : https://github.com/CodethinkLabs/sandboxlib/pull/24/files#diff-3f53d25293d2bb0d4fd436c090136ff0L173 | 13:41 |
| leeming | glad you thought it was strange too | 13:41 |
| leeming | tiagogomes, I am not getting 100% passes | 14:00 |
| leeming | i suggested a fix, but needs verifying | 14:00 |
| tiagogomes | ok, all pass to me tough. But I am not testing with different versions of python interpreters | 14:01 |
| paulsherwood | CTtpollard: is the source for the new GENIVI hmi launcher thing avilable somewhere now? | 14:06 |
| * paulsherwood wonders how hard it would be to integrated it in the applicable baserock systems | 14:07 | |
| CTtpollard | paulsherwood: yep | 14:10 |
| CTtpollard | paulsherwood: https://github.com/GENIVI/hmi-layout-gdp/tree/ics-launcher-gdp | 14:11 |
| paulsherwood | tvm | 14:11 |
| paulsherwood | why two branches? | 14:12 |
| CTtpollard | The powers that be decided a branch was more suitable than a new repo | 14:12 |
| paulsherwood | so which would we use? | 14:13 |
| paulsherwood | oh, one repo with two completely different codebases in it? | 14:13 |
| pedroalvarez | i'd hope they push all of it to master | 14:15 |
| pedroalvarez | at some point | 14:15 |
| cphang | Hi, small thing,added a lorry file for review: https://gerrit.baserock.org/#/c/2307/ | 14:23 |
| paulsherwood | +1 | 14:31 |
| paulsherwood | anyone else? | 14:31 |
| * paulsherwood would be quite excited to see freertos built the baserock way | 14:32 | |
| pedroalvarez | svn lorry | 14:32 |
| pedroalvarez | is it big? | 14:32 |
| paulsherwood | cphang: ^^ ? | 14:32 |
| pedroalvarez | years and years of history? | 14:33 |
| * paulsherwood guesses not... it's an rtos for microcontrollers | 14:33 | |
| pedroalvarez | I'm happy to merge and see if that works or not just by waiting | 14:33 |
| * paulsherwood *hopes* there's history :) | 14:33 | |
| pedroalvarez | is there a git mirror available somewhere? | 14:33 |
| leeming | tiagogomes, this was running the test as root/sudo for some of the chroot tests. i think it is a py3 issue | 14:33 |
| tiagogomes | Indeed | 14:33 |
| paulsherwood | pedroalvarez: eg https://github.com/blalor/FreeRTOS, 1632 commits | 14:35 |
| pedroalvarez | well, they are not too many | 14:36 |
| paulsherwood | pedroalvarez: if that's a +1 i'll merge :) | 14:37 |
| tiagogomes | leeming the problem is that I don't know how to install python3.3 and python3.4 | 14:38 |
| leeming | oh, apparently that is difficult.. ive just been making sure it works in 2 + 3 | 14:39 |
| cphang | pedroalvarez, paulsherwood, I think that git repo hasn't been updated since 2012. | 14:39 |
| cphang | There is a history here: https://sourceforge.net/p/freertos/code/commit_browser | 14:40 |
| cphang | To date: 2471 revisions for freeRTOS. | 14:44 |
| *** janderJLR has joined #baserock | 14:46 | |
| *** janderJLR is now known as JasonA | 14:46 | |
| JasonA | Hopefully ybd questions are welcome here. I am curious if ybd can handle repos with submodules that have submodules. I have spent a little bit of time looking at the code, and it seems to not recurse lower than the top-level .gitmodules | 14:49 |
| leeming | JasonA, I was just asked this out of channel. Not sure if i know what submodules refer to in this context | 14:50 |
| JasonA | Sorry, git submodules | 14:50 |
| leeming | oh right | 14:51 |
| JasonA | Specifically, I want to build Qt5 using the supermodule, which contains all of the Qt projects as submodules. Some of those submodules also have submodlues | 14:51 |
| leeming | i know as much as doing a --recursive flag when cloning the init repo... if you can do this after cloneing the 'master' repo, im wondering if you can stick in a chain of commands in the build-instructions part of the morph (im guessing) | 14:52 |
| leeming | unfortunately, the best person to answer this is off sick :( | 14:53 |
| leeming | (unless he is lurking) | 14:53 |
| leeming | locallycompact, ^ | 14:53 |
| leeming | but, if it is a generic hack with the definitions files.. others might be able to help too | 14:54 |
| * SotK thought ybd recursively cloned submodules and their submodules, but may be mistaken | 14:56 | |
| *** CTtpollard has quit IRC | 14:56 | |
| franred | JasonA, I think you can define the submodules in the yaml http://git.baserock.org/cgit/baserock/baserock/definitions.git/tree/strata/gnome.morph | 14:56 |
| franred | and for every chuck you define their submodules | 14:56 |
| franred | not sure if it is what you are looking for | 14:57 |
| SotK | a glance at the code suggests I am mistaken, unless I'm missing something | 14:57 |
| JasonA | Yeah, the issue is that some of the submodules also have submodules. So I have defined the top-level submodule in the morph, but once one of those tries to get built its submodules were not checked out | 15:00 |
| JasonA | The Qt5 supermodule has a perl script to do the recursive checkout and a gew other things. Another option would be to tell ybd not to checkout submodules at all if that is possible | 15:02 |
| SotK | JasonA: I suspect https://gitlab.com/baserock/ybd/blob/02b79c475aa9614412ead68c2953f0e9bf6ef80d/ybd/repos.py#L181 needs to be done around https://gitlab.com/baserock/ybd/blob/02b79c475aa9614412ead68c2953f0e9bf6ef80d/ybd/repos.py#L204 also, if you're in the mood to try fixing it | 15:02 |
| *** CTtpollard has joined #baserock | 15:02 | |
| JasonA | Ah, I see. I have a fork of ybd I will try that in | 15:03 |
| SotK | though, you'll probably want to remove lines 180 to 183 too if you do that | 15:05 |
| JasonA | Yes, basically just move that functionality into _checkout | 15:05 |
| * SotK realises he linked an old commit so the line numbers are off | 15:07 | |
| JasonA | No problem, I get the idea. Thanks for your help | 15:07 |
| SotK | yw :) | 15:07 |
| rdale | i wouldn't use submodules to build qt5 as it is likely you will need to customise the build of a particular module in a different way to the other modules | 15:24 |
| *** ctbruce has quit IRC | 15:27 | |
| JasonA | Yeas, but I can handle that in the configure steps. I am trying to avoid having to update the 20+ submodules SHAs every time I want to upgrade Qt versions | 15:28 |
| rdale | i see - upgrading the sha1s is tedious i agree | 15:28 |
| JasonA | Yeah | 15:29 |
| pedroalvarez | last time I looked at that code in ybd, it was recursive | 15:30 |
| pedroalvarez | but it looks like SotK has found the problem | 15:31 |
| SotK | https://gitlab.com/baserock/ybd/commit/4072533d598e332e0e88a859e0b38a92568aceac looks to be the change that broke it | 15:32 |
| JasonA | Ah yes, well I am about to kick off a build to test SotK's suggestion | 15:33 |
| JasonA | If it works I will submit the patch, if anyone is interested | 15:34 |
| * SotK expects there will be interested people | 15:34 | |
| pedroalvarez | paulsherwood will be interested, yes | 15:34 |
| *** franred has quit IRC | 16:00 | |
| *** CTtpollard has quit IRC | 16:02 | |
| leeming | why don't some chunks have install-commands defined? | 16:15 |
| leeming | is "make install" implicit? | 16:15 |
| SotK | can you link an example? | 16:16 |
| leeming | 2secs | 16:18 |
| SotK | leeming: you mean like http://git.baserock.org/cgit/baserock/baserock/definitions.git/tree/strata/core/bash.morph for example? | 16:25 |
| leeming | hmm no.. i am just trying to figure out locallycompact's new lib... can't seem to find which files it actually pulls | 16:28 |
| leeming | one i just tried to track down was 'xz' | 16:28 |
| leeming | but that seems to pull from upstream but can't find the build morph for it | 16:29 |
| *** toscalix has quit IRC | 16:29 | |
| leeming | wondering if the binary is packaged in these repos instead of compiling source? | 16:30 |
| SotK | http://git.baserock.org/cgit/baserock/baserock/definitions.git/tree/strata/core.morph#n219 is xz | 16:30 |
| jmacs | leeming: In morph, some commands have defaults depending on the build-system | 16:30 |
| leeming | ah is that so jmacs ? | 16:30 |
| SotK | it has build-system: autotools, so should get the default install-commands from DEFAULTS for that | 16:31 |
| SotK | slow snap | 16:31 |
| jmacs | With autotools selected, the default is make DESTDIR="$DESTDIR" instll | 16:31 |
| leeming | ah that kinda makes sense then | 16:31 |
| SotK | leeming: see http://git.baserock.org/cgit/baserock/baserock/definitions.git/tree/DEFAULTS#n25 | 16:31 |
| SotK | that bash morph also has build-system: autotools, but overrides the default configure and post-install commands | 16:32 |
| leeming | so for the xz example, im assuming a "xz.morph" isn't needed as it just runs the autotools build | 16:33 |
| SotK | correct | 16:33 |
| * leeming proceeds to x-ref ybd and defslib | 16:33 | |
| *** tiagogomes has quit IRC | 16:43 | |
| *** rdale has quit IRC | 17:30 | |
| *** lachlanmackenzie has quit IRC | 18:43 | |
| *** locallycompact has quit IRC | 19:59 | |
| *** gtristan has joined #baserock | 20:56 | |
Generated by irclog2html.py 2.15.3 by Marius Gedminas - find it at mg.pov.lt!