| *** fay_ has joined #baserock | 01:32 | |
| *** fay__ has quit IRC | 01:32 | |
| *** tpollard_ has quit IRC | 01:32 | |
| *** nowster has quit IRC | 01:32 | |
| *** flatmush has quit IRC | 01:32 | |
| *** paulw has quit IRC | 01:32 | |
| *** nowster has joined #baserock | 01:32 | |
| *** paulw has joined #baserock | 01:32 | |
| *** franred has quit IRC | 01:32 | |
| *** tpollard_ has joined #baserock | 01:33 | |
| *** franred has joined #baserock | 01:33 | |
| *** flatmush has joined #baserock | 01:33 | |
| *** sambishop has quit IRC | 03:57 | |
| *** petefoth has joined #baserock | 05:50 | |
| *** Albert has joined #baserock | 07:22 | |
| *** a1exhughe5 has joined #baserock | 07:26 | |
| *** rdale has joined #baserock | 07:26 | |
| *** Albert has quit IRC | 07:33 | |
| *** Albert has joined #baserock | 07:34 | |
| *** jonathanmaw has joined #baserock | 07:50 | |
| *** sambishop has joined #baserock | 07:54 | |
| *** bashrc has joined #baserock | 08:02 | |
| *** gary_perkins has joined #baserock | 08:12 | |
| *** Kinnison_ is now known as Kinnison | 08:16 | |
| *** De|ta_ is now known as De|ta | 08:40 | |
| *** mariaderidder has joined #baserock | 08:49 | |
| radiofree | is it ok for me to put a load of genivi specific systemd units in http://git.baserock.org/cgi-bin/cgit.cgi/baserock/baserock/bsp-support.git/ rather than adding them to various chunk files | 08:58 |
|---|---|---|
| Kinnison | Is there a reason you don't want to make a genivi-support chunk? | 09:00 |
| Kinnison | And wouldn't it be better to upstream the units? | 09:00 |
| radiofree | Kinnison: genivi-support chunk was what i was getting at with adding the repo in bsp-support | 09:01 |
| *** tiagogomes has joined #baserock | 09:01 | |
| radiofree | yes, ideally upstream the units, however that's in the future, need something for now | 09:01 |
| richard_maw | I belive install-files is our usual hack for that then | 09:02 |
| * Kinnison nods | 09:02 | |
| radiofree | yeah, but i didn't really want to dirty definitions anymore | 09:02 |
| radiofree | i thought bsp-support was our way around needing to do install-files | 09:02 |
| Kinnison | What systems is bsp-support used in? | 09:05 |
| radiofree | only the jetson, and it's not really needed there anymore :\ | 09:05 |
| Kinnison | hmm | 09:05 |
| radiofree | e.g http://git.baserock.org/cgi-bin/cgit.cgi/baserock/baserock/bsp-support.git/log/?h=baserock/arm/tegra-3.10 | 09:05 |
| radiofree | added a systemd unit | 09:05 |
| *** ssam2 has joined #baserock | 09:05 | |
| *** ChanServ sets mode: +v ssam2 | 09:05 | |
| Kinnison | What a bizarre tiny chunk | 09:06 |
| richard_maw | it's even smaller than the initramfs, since that requires a moderately complicated shell script | 09:08 |
| radiofree | it's a perfectly formed chunk | 09:08 |
| richard_maw | it is | 09:08 |
| Kinnison | Well, it has a redundant .morph in it | 09:09 |
| richard_maw | it's a bit old | 09:10 |
| radiofree | i think bsp-support has a purpose though, a chunk you can throw into a system without adding loads more system specific stuff to the definitions repo | 09:18 |
| radiofree | in the case systemd units for the genivi-demo-platform | 09:19 |
| richard_maw | it would be weird for it to be stuff unrelated to the particular hardware though | 09:21 |
| radiofree | it's not going to be jetson only, it's x86+arm | 09:23 |
| radiofree | so just a branch in there called "genivi-demo-platform" or something | 09:23 |
| radiofree | then both the x86 and arm g-d-p systems will add it | 09:24 |
| richard_maw | it's not really the BSP then is it? it's there to provide app functionality, rather than stuff essential for the hardware that it's running on | 09:28 |
| radiofree | it's essentially board support functionality for genivi-demo-platform systems | 09:29 |
| radiofree | s/essentially/essential | 09:29 |
| richard_maw | what exactly needs to be added? | 09:30 |
| radiofree | systemd user service files for the apps in the GDP, dbus user session (though i'm going to add that to essential-files since it's pretty useful for everything), system units for weston | 09:31 |
| richard_maw | none of that seems hadware specific, so I'm skeptical that it belongs in anything named BSP | 09:32 |
| richard_maw | s/hadware/hardware/ | 09:32 |
| * radiofree will just keep the generation in the chunk files then | 09:36 | |
| *** edcragg has joined #baserock | 09:38 | |
| Kinnison | :) | 09:42 |
| jjardon | ssam2: maybe you have some free time to take a second look to https://gerrit.baserock.org/#/c/531/ and https://gerrit.baserock.org/#/c/580/ ? | 09:50 |
| ssam2 | oh yeah | 09:53 |
| ssam2 | oh, I still don't get it | 09:57 |
| ssam2 | we should bump definitions VERSION before merging #580 so old versions of Morph don't try to build something that will cause them to crash | 09:58 |
| ssam2 | #531 either | 09:58 |
| ssam2 | *even | 09:58 |
| ssam2 | s/build/deploy/ as well | 10:03 |
| ssam2 | I think due to the way `morph deploy` is implemented, versioning is a lot more complicated there than with `morph build` | 10:04 |
| ssam2 | the interface between Morph and definitions.git that we need to version is totally ad-hoc and undefined for `morph deploy`, but all our workflows that we suggest people use depend on being able to use `morph deploy` as well as `morph build` | 10:05 |
| ssam2 | I think moving .configure extensions into definitions.git is a good first step. But it'd be nice if they could live in a subdirectory rather than all being in the toplevel | 10:05 |
| paulsherwood | ssam2: the whole deployment situation is in need of some cleanup. it's a bit of a rat's nest | 10:06 |
| Kinnison | Until and unless extensions can live in a subtree, I wouldn't want to move everything in | 10:06 |
| ssam2 | Kinnison: but you haven't tried to make changes to a .configure extension recently | 10:06 |
| paulsherwood | extensionsh should be in definitions | 10:06 |
| Kinnison | However, we're *still* in the position of making changes to a surface we haven't properly mapped | 10:06 |
| ssam2 | it's a nightmare | 10:06 |
| paulsherwood | Kinnison: i'm willing to help map it myself, but only if folks agree to minimising the surface | 10:07 |
| Kinnison | paulsherwood: mapping it would be the first step to minimising it | 10:07 |
| paulsherwood | disagree | 10:07 |
| Kinnison | paulsherwood: But it's not a one-shot operation | 10:07 |
| ssam2 | there are 10 .configure extensions in morph.git/morphlib/exts, fyi | 10:07 |
| ssam2 | so not too many to have temporarily living in the top level of definitions.git | 10:08 |
| paulsherwood | i think i disagree on that too, Kinnison :) | 10:08 |
| paulsherwood | but i may be wrong | 10:08 |
| Kinnison | paulsherwood: You are wrong | 10:08 |
| Kinnison | paulsherwood: but that's your perogative | 10:08 |
| Kinnison | :) | 10:08 |
| paulsherwood | i've been wrong before :) | 10:08 |
| paulsherwood | but often, when folks told me i'm wrong, i proved to be right | 10:09 |
| ssam2 | Kinnison: I'm pretty confused on the form such a map might take | 10:09 |
| paulsherwood | and i think i'm getting to the point where i grok this as well as many of the folks here | 10:09 |
| ssam2 | if you have something in mind, it'd be useful if you could show an example of what you want | 10:09 |
| paulsherwood | ssam2: you mean me? | 10:09 |
| ssam2 | no, Kinnison | 10:09 |
| * paulsherwood shuts up, then :) | 10:10 | |
| ssam2 | but same to you if you can demonstrate it easily | 10:10 |
| Kinnison | ssam2: I'd like to see a proper specification document with testable assertions detailing the interaction between the physical model in definitions, the logical model it represents, and the results produced (along with all the appropriately abstracted behaviours en-route) so that reimplementation of any or all of the tooling would be safe | 10:10 |
| ssam2 | ok. I have no idea how I'd ever do that, so I doubt I will, i'm afraid | 10:10 |
| Kinnison | I have an approach in mind, but no time to do it, sadly :( | 10:10 |
| ssam2 | sounds like something on the order of complexity of the ANSI C specification | 10:10 |
| ssam2 | which wasn't the product of 1 day a week's hacking | 10:11 |
| Kinnison | I imagine it might end up slightly more complex than that to begin with | 10:11 |
| Kinnison | and then it offers a basis for simplification | 10:11 |
| *** pacon has joined #baserock | 10:11 | |
| * Kinnison has been advocating this approach for around six months now though | 10:13 | |
| Kinnison | and it hasn't received much traction | 10:13 |
| Kinnison | so perhaps I should give up | 10:14 |
| * SotK thinks that is partly because no-one has enough time to do it | 10:14 | |
| Kinnison | nor any ability to guarantee ongoing bandwidth (which IMO is essential) | 10:14 |
| ssam2 | honestly, if you are advocating an approach that involves producing something more complex than the ANSI C specification, I don't see how it will ever happen | 10:15 |
| Kinnison | We already produce something more complex than that -- full Linux systems | 10:16 |
| paulsherwood | :) | 10:16 |
| Kinnison | But I'm giving up | 10:16 |
| Kinnison | Clearly there's no desire to approach this the way I feel would be best | 10:16 |
| Kinnison | so I'll stop | 10:16 |
| richard_maw | Kinnison: you have agreement from me that it would be the best way to go | 10:16 |
| ssam2 | it may well be the best approach, I just don't see how it's possible | 10:17 |
| *** rdale_ has joined #baserock | 10:17 | |
| ssam2 | I can produce a full Linux system from scratch in a few days, by hand (following linux-from-scratch) | 10:17 |
| ssam2 | it's totally different from trying to produce a complete, machine-comprehensible, watertight specification of something | 10:18 |
| paulsherwood | actually, I think we *can* produce a machine-comprehensible watertight specification of these linux systems - we already do | 10:18 |
| Kinnison | I think you're missing a level of meta | 10:19 |
| paulsherwood | no, i get it. | 10:19 |
| * Kinnison was talking about producing a specification of how we specify systems | 10:19 | |
| paulsherwood | as i said, i get it. | 10:19 |
| Kinnison | However I said I'd stop, and I shall | 10:19 |
| * Kinnison apologises | 10:19 | |
| *** rdale has quit IRC | 10:20 | |
| paulsherwood | Kinnison: no need to stop, or apologise. i agree that what you want to get to is required. i'm just interested in finding the shortest/leastwork route to that goal | 10:20 |
| radiofree | looking at what is needed for the gdp, would people be happy suggesting "use this branch of definitions" rather than us submitting this to master? | 10:21 |
| paulsherwood | radiofree: it's not ideal, but ok | 10:21 |
| paulsherwood | (by me) | 10:21 |
| radiofree | there's so many hacks and obsolete versions of these (e.g we have to use an entirely different version of weston from the weston system *and* the genivi-baseline system) | 10:21 |
| radiofree | s/these/things | 10:22 |
| Kinnison | radiofree: If you're waiting on features or upstreaming before you can cleanly merge to master then I think it's reasonable providing you can commit to regular updates to that branch | 10:22 |
| paulsherwood | really? what is *wrong* with these people?!!! | 10:22 |
| radiofree | we're not using mainline qtmultimedia, *or* anything close to mainline qtwayland... | 10:22 |
| radiofree | Kinnison: ok, i'll commit to keeping track and maintaining if for a merge to master | 10:22 |
| paulsherwood | radiofree: nothing to stop you creating such a branch, irrespective of whether you choose to maintain it? :) | 10:23 |
| radiofree | well we need to document it somewhere, i.e "morph checkout baserock:baserock/definitions genivi-demo-platform | 10:23 |
| paulsherwood | how hard can that be? :) | 10:24 |
| radiofree | mandatory video anyway, jetson, kernel 4.0, nouveau http://seriousinternetbusiness.com/james/vids/gdp-jetson.mp4 | 10:24 |
| Kinnison | paulsherwood: one-shot -- trivial -- something useful for people in an ongoing way -- harder | 10:24 |
| ssam2 | the media player is terrifying | 10:24 |
| paulsherwood | Kinnison: false dichotomy | 10:25 |
| ssam2 | radiofree: if you want to be able to merge changes to 'genivi-demo-platform' in gerrit and have them replicated to git.baserock.org, it will need a config tweak | 10:25 |
| * SotK wonders how the media player is actually a media player | 10:25 | |
| SotK | it looks like two googly eyes | 10:25 |
| ssam2 | radiofree: i'm happy to do that if you want, request it via the mailing list if so in order that there's a record | 10:26 |
| paulsherwood | radiofree: can you get someone to put that on the baserock vimeo channel please? | 10:26 |
| SotK | ssam2: do you have time to fix https://gerrit.baserock.org/#/c/637/ btw? | 10:26 |
| radiofree | ssam2: can i version the branches then, e.g genivi-demo-platform-0.1, 0.2, until it's ready for master? | 10:27 |
| radiofree | i'd rather not have to go through any review process to get this up to scratch before submitting to master | 10:27 |
| ssam2 | radiofree: it's totally up to you, i'm not trying to force any process on you | 10:28 |
| paulsherwood | radiofree: just go ahead with that. i'll take up this conversation with other genivi folks. i mean, *wtf*!!!? | 10:28 |
| ssam2 | radiofree: it's just that if you want people to be able to submit patches for the 'genivi-demo-platform' branch, it won't work as you expect because 'master' is treated specially | 10:29 |
| ssam2 | radiofree: so we'd need to tell it to 'genivi-demo-platform' the same as 'master', rather than treating it as a personal branch | 10:29 |
| paulsherwood | ssam2: or folks could use ybd :) | 10:29 |
| ssam2 | paulsherwood: ybd can fix gerrit config now? I think i'm missing something | 10:30 |
| radiofree | ssam2: i see what you mean, but i'm not expecting anyone to submit patches for this, maybe document use the mailing list and cc me? | 10:30 |
| ssam2 | radiofree: yes, that makes sense | 10:31 |
| radiofree | i want to get it to a state that's reasonable for merging to master (when the review will happen) first, and that will need some serious changes in how upstream is implementing these components | 10:31 |
| paulsherwood | ssam2: no, it's me misunderstanding. i'm an idiot someteimes as you know :) sorry | 10:32 |
| ssam2 | SotK: I'll get to it today, but feel free to do so first | 10:32 |
| ssam2 | I need to repair my chroot setup, `manage-baserock rm` destroyed a bunch of stuff because I ran it on a chroot that still had stuff mounted | 10:33 |
| SotK | heh, I'll fix it up then :) | 10:33 |
| ssam2 | thanks | 10:33 |
| jmacs | Was doffm's flang patch merged into definitions? It seemed to get a +2 in January, but I can't see it in master. | 11:01 |
| nowster | ~ # ls /etc/localtime -l | 11:05 |
| nowster | lrwxrwxrwx 1 root root 25 Jan 1 1970 /etc/localtime -> ../usr/share/zoneinfo/UTC | 11:05 |
| nowster | But there's no /usr/share/zoneinfo... | 11:05 |
| ssam2 | nowster: is this inside a system build with Baserock? perhaps you're missing whatever stratum contains time-zone-database | 11:07 |
| nowster | yes | 11:07 |
| ssam2 | nowster: which I believe is 'foundation' | 11:07 |
| nowster | ah, right... that's build-system | 11:07 |
| ssam2 | built from what commit? | 11:08 |
| nowster | some time in February | 11:08 |
| ssam2 | oh, I think that's before time-zone-database was added, then | 11:08 |
| nowster | right | 11:08 |
| *** pacon has quit IRC | 11:48 | |
| *** pacon has joined #baserock | 11:49 | |
| *** sambishop has quit IRC | 12:10 | |
| *** sambishop has joined #baserock | 12:13 | |
| *** pacon has quit IRC | 12:55 | |
| ssam2 | does anyone have a minute to review https://gerrit.baserock.org/#/c/637/2 ? | 13:04 |
| ssam2 | it fixes a bug that is present in the version of Morph included in the Baserock 15.19.1 release of definitions.git | 13:04 |
| richard_maw | ssam2: reviewing | 13:15 |
| richard_maw | ssam2: +2, I'll leave submitting it for merge to you, as I made some small suggestions that are pretty much just cosmetic | 13:18 |
| ssam2 | thanks | 13:25 |
| ssam2 | ok, I'll tag and announce a 15.19.2 release of the Baserock reference definitions... | 13:29 |
| ssam2 | with just the last 2 commits to Morph as changes | 13:29 |
| *** a1exhughe5 has quit IRC | 13:38 | |
| tiagogomes | can we stop using busybox | 13:41 |
| bashrc | busybox < gnu | 13:43 |
| ssam2 | tiagogomes: what exactly do you want? | 13:43 |
| ssam2 | most of the GNU tools are present in Baserock, you can use them | 13:43 |
| ssam2 | I don't want to get involved in preventing people from using Busybox, however | 13:43 |
| tiagogomes | ssam2 today, it would be a proper brctl tool | 13:45 |
| ssam2 | ok, so find what package provides GNU brctl, and add it to Baserock | 13:45 |
| Kinnison | Under Debian it comes from bridge-utils | 13:47 |
| Kinnison | Amusingly enough apparently written by Lennart | 13:48 |
| Kinnison | However, Lennart Buytenhek :) | 13:48 |
| Kinnison | Apparently git://git.kernel.org/pub/scm/linux/kernel/git/shemminger/bridge-utils might be the current upstream | 13:56 |
| * Kinnison looks | 13:56 | |
| Kinnison | Certainly it's there, though there haven't been commits for 14 months | 13:57 |
| Kinnison | perhaps it's simply stable | 13:57 |
| Kinnison | tiagogomes: did that help? | 14:27 |
| tiagogomes | Kinnison didn't have a look, I copied the brctl binary from a debian system to baserock as a short fix | 14:28 |
| Kinnison | eww | 14:28 |
| pedroalvarez | :) | 14:31 |
| *** sambishop has quit IRC | 14:33 | |
| pedroalvarez | franred: just found this: http://git.baserock.org/cgi-bin/cgit.cgi/delta/python-packages/websockify.git/commit/?h=baserock/v0.6.0&id=e0863aa0c2103069961bc24e618615a0f2bb1487 | 14:36 |
| pedroalvarez | can you please change them to use upstream: the next time please? | 14:36 |
| pedroalvarez | franred: see policies for more info: http://wiki.baserock.org/policies/ | 14:38 |
| franred | pedroalvarez, yep, apologies for forgetting to use the full URL (when I was testing git didn't know what upstream was so it fails) | 14:38 |
| pedroalvarez | also, ssam2, shouldn't mason be failing because of this? | 14:39 |
| franred | pedroalvarez, why? it does point to git.baserock.org | 14:39 |
| pedroalvarez | franred: he was trying to isolate mason from internet | 14:40 |
| pedroalvarez | git.baserock.org is the public address | 14:40 |
| pedroalvarez | I think mason is using git.baserock.org as a local trove, setting trove-host to the internal IP | 14:41 |
| pedroalvarez | if something uses git.baserock.org, it should fail | 14:41 |
| pedroalvarez | if it uses upstream: that will be converted to the internal IP | 14:41 |
| pedroalvarez | and it should work | 14:41 |
| pedroalvarez | that was the idea | 14:41 |
| franred | pedroalvarez, ohh, I see | 14:41 |
| pedroalvarez | i think I know why mason hasn't detected this yet | 14:43 |
| pedroalvarez | It was already built when Sam restricted the internet on them | 14:44 |
| ssam2 | that would make sense | 14:44 |
| pedroalvarez | looking forward to see a full rebuild :) | 14:44 |
| *** sambishop has joined #baserock | 14:45 | |
| franred | pedroalvarez, clean the cache so we can fix anything is pointing to something external and we can fix it | 14:46 |
| pedroalvarez | franred: I don't think people want me to clean cache.baserock.org cache :) | 14:47 |
| franred | hehehehe | 14:47 |
| pedroalvarez | alhough I could remove it's artifact, which is less disruptive | 14:48 |
| pedroalvarez | s/'// | 14:48 |
| *** jonathanmaw has quit IRC | 15:18 | |
| radiofree | hi everyone | 15:58 |
| SotK | hi radiofree | 15:58 |
| radiofree | am i correct in thinking http://fpaste.org/221970/14316190/ will export an environment variable called WESTON_DEFAULT_BACKEND | 15:58 |
| radiofree | WESTON_NATIVE_BACKEND even | 15:58 |
| radiofree | that'll be available to configure | 15:59 |
| radiofree | or would i have to do something like WESTON_NATIVE_BACKEND=$WHATEVER_I_SET_UP_THERE and call it something else? | 15:59 |
| richard_maw | radiofree: no, it won't export that variable | 16:00 |
| richard_maw | it *needs* the explicit export command | 16:00 |
| radiofree | ok, so either do export WESTON_NATIVE_BACKEND or do something like http://fpaste.org/221971/31619244/ ? | 16:00 |
| richard_maw | yes | 16:01 |
| radiofree | ok, thanks | 16:01 |
| *** Albert has quit IRC | 16:09 | |
| ssam2 | I think that my 'optional workspaces' branch will be really awkward unless we first change sourcepools to allow containing multiple systems | 16:17 |
| ssam2 | as I understand it, the main thing that'd need to be fixed for that is that Source objects have a 'cache_key' and 'cache_id' attribute | 16:17 |
| ssam2 | but in fact it's the Artifact object that should track its cache identity | 16:18 |
| richard_maw | no | 16:18 |
| richard_maw | discussed it out of band | 16:24 |
| richard_maw | that would be a reversion to a previous conflation | 16:24 |
| richard_maw | when what I'd like is a reduction of the conflation of concepts in the Source object | 16:24 |
| ssam2 | I think i'd better avoid basing the 'optional workspaces' branch on such a change, and just work around the problem for now | 16:33 |
| ssam2 | I'd like to fix this, but I don't want that branch to turn into a huge monster | 16:33 |
| * jjardon learns today that you can fit systemd in a 7MB image system: https://plus.google.com/104232583922197692623/posts/DwGTQpaSEKh | 16:35 | |
| robtaylor | jjardon: nice | 16:37 |
| robtaylor | jjardon: ah, i gave jdub some pointers :) | 16:38 |
| robtaylor | jjardon: he'll probably be interested in rdale_ 's work to make systemd work with musl | 16:38 |
| rdale_ | i haven't actually started that, as i got a bit frightened of the size of the patch series on the mailing list for musl/systemd | 16:39 |
| jjardon | unfortunately the smallest system I manage to produce in baserock is ~35MB :/ This is the system: http://git.baserock.org/cgi-bin/cgit.cgi/baserock/baserock/definitions.git/tree/systems/minimal-system-armv5l-openbmc-aspeed.morph | 16:40 |
| jjardon | Any idea how can I make it smaller? | 16:40 |
| rdale_ | you can build a system like that with musl that uses busybox init | 16:42 |
| jjardon | robtaylor: I was really impressed that you can put systemd in such small system: http://vocore.io/ | 16:42 |
| *** ssam2 has quit IRC | 16:43 | |
| *** mariaderidder has quit IRC | 16:44 | |
| jjardon | rdale_: Thanks for the suggestion. Although Yocto is able to generate a smaller image without using musl, so it should be posible in some way | 16:46 |
| rdale_ | we need to use strip | 16:47 |
| jjardon | rdale_: Are the musl chunk in current definitions? | 16:47 |
| jjardon | or in a branch somewhere? | 16:47 |
| rdale_ | no, in baserock/rdale/musl | 16:47 |
| rdale_ | nowster has just found it doesn't work with ipv4 though, so that really needs fixing | 16:48 |
| jjardon | mmm, Anyone know what would be needed to strip in baserock? is it anyone working on it? | 16:49 |
| radiofree | jjardon: i think sam was | 16:50 |
| nowster | The devices are there in the kernel, but musl doesn't seem to be able to do "inet" sockets. | 16:51 |
| rdale_ | i haven't looked at it yet, but is it possibly a busybox build problem, rather than musl itself? | 16:55 |
| *** bashrc has quit IRC | 16:58 | |
| nowster | maybe... can't easily tell | 16:59 |
| ratmice__ | jjardon: was this a fairly standard yocto build or something e.g. compiled with -Os and other tricks to create a minimal footprint? | 17:00 |
| jjardon | ratmice__: I do not think so, at least I do not see anything like that in the machine layer: https://github.com/facebook/openbmc/tree/master/meta-aspeed | 17:04 |
| jjardon | mmm, seems they are using "'image-mklibs' to reduce shared library files size for an image" . Not sure what that does though | 17:06 |
| nowster | is configure "set-hostname" built into morph? | 17:07 |
| ratmice__ | so is there currently a 1:1 source->artifact for a given build/cache id thing? | 17:07 |
| Zara | jjardon: I did find this, which is in the 'common' files: https://github.com/facebook/openbmc/blob/master/common/recipes-core/packagegroups/packagegroup-core-tools-debug.bbappend I don't know that it's relevant right this second but might be worth bearing in mind if we have perl in the system currently | 17:08 |
| Zara | since it suggests they don't have perl in there. but you may be aware of that, sorry if so! :P | 17:09 |
| jjardon | Zara: thanks for the hint; we use perl (wich is in core) to build the bsp stratum (as linux build depends on perl), but we do not inclide the core stratum in the final system definition | 17:11 |
| ratmice__ | jjardon: ahh, seems it strips out functions/symbols in libraries which go unused by a set of executables | 17:12 |
| *** gary_perkins has quit IRC | 17:12 | |
| * ratmice__ isn't sure baserock is a closed enough system to do that | 17:13 | |
| robtaylor | jjardon: istr that there was a plan post chunk-splitting to have a way to strip the debug into a seperate artifact | 17:24 |
| ratmice__ | robtaylor: does that not mean the cache server will have multiple copies of debug info? | 17:31 |
| ratmice__ | e.g. one in the combined/one split out artifact? | 17:32 |
| robtaylor | ratmice__: well, i'd always split | 17:34 |
| robtaylor | ratmice__: and if you want an image with debug info, assemble with the debuginfo artefacts | 17:34 |
| robtaylor | one nice sideeffect of this appraoch is you could have debug images for production images, asswing in-field debugging | 17:35 |
| ratmice__ | robtaylor: oh right, chunk splitting happens before artifact, so it is avoiding this 2x size increase | 17:37 |
| robtaylor | ratmice__: yup | 17:40 |
| ratmice__ | for some reason 'separate artifact' had me confused as though there were an initial combined artifact | 17:40 |
| *** mwilliams_ct has quit IRC | 18:12 | |
| *** pdar has quit IRC | 18:12 | |
| *** Zara has quit IRC | 18:12 | |
| *** perryl has quit IRC | 18:12 | |
| *** DavePage has quit IRC | 18:12 | |
| *** paulsherwood has quit IRC | 18:12 | |
| *** kejiahu has quit IRC | 18:12 | |
| *** benbrown_ has quit IRC | 18:12 | |
| *** petefotheringham has quit IRC | 18:12 | |
| *** bwh has quit IRC | 18:12 | |
| *** jmacs has quit IRC | 18:12 | |
| *** SotK has quit IRC | 18:12 | |
| *** rjek has quit IRC | 18:13 | |
| *** rjek has joined #baserock | 18:13 | |
| *** bwh has joined #baserock | 18:19 | |
| *** petefotheringham has joined #baserock | 18:19 | |
| *** SotK has joined #baserock | 22:05 | |
Generated by irclog2html.py 2.15.3 by Marius Gedminas - find it at mg.pov.lt!