| *** gmacario has joined #automotive | 06:42 | |
| *** fredcadete has joined #automotive | 06:51 | |
| *** KlausUhl has joined #automotive | 07:31 | |
| CTtpollard | good morning | 07:35 |
|---|---|---|
| fredcadete | good morning | 07:40 |
| KlausUhl | good morning everybody! | 07:43 |
| *** jacobo has joined #automotive | 08:09 | |
| paulsherwood | howdie | 08:17 |
| *** mdunford has joined #automotive | 08:23 | |
| *** jonathanmaw has joined #automotive | 09:09 | |
| *** wschaller_ has joined #automotive | 09:18 | |
| paulsherwood | CTtpollard: have you had a chance to check whether GDP for porter is buildable without the blobs? | 09:31 |
| CTtpollard | It will complain about not having multimedia blobs but carrying on building, I've not had any luck as of yet getting it to build without gfx blobs though | 09:36 |
| CTtpollard | I'm sure it will be able to build with further tinkering to local conf though, not specifying gles-user-module for example | 09:39 |
| fredcadete | interestingly, the Renesas BSP I have here has instructions to build without the gfx blobs | 10:18 |
| fredcadete | but only for X11 | 10:18 |
| radiofree | "use mesa"? | 10:20 |
| fredcadete | that's what it ends up doing | 10:20 |
| fredcadete | but you have to BBMASK libegl, libgbm | 10:21 |
| radiofree | CTtpollard: unless there's something horrific in the build you should just be able to build mesa with --enable-gles2 --disable-glx --with-egl-platforms=wayland | 10:21 |
| radiofree | ideally the renesas blobs should just be drop in replacements for mesa | 10:21 |
| radiofree | personally i think we should be building the GDP *only* with mesa (with all the gallium drivers), and then you go and see your vendor if you need the blobs for your gpu | 10:23 |
| radiofree | all least then the same build (minus the kernel etc...) should work on multiple platforms | 10:24 |
| CTtpollard | I agree with you radiofree | 10:24 |
| radiofree | arm you could use freedreno, nouveau, or the swrast dri driver (SLOW) | 10:24 |
| radiofree | intel, obviously the mesa drivers there are already excellent | 10:24 |
| paulsherwood | radiofree: good thinking :) | 10:34 |
| paulsherwood | jeremiah: what's genivi policy for maintaining mirrors of repos at the moment (ie in advance of me trying to persuade folks to adopt a mirror of upstreams in general) | 10:52 |
| paulsherwood | jeremiah: particular use-case, if folks working expressly on genivi integration need to make mods to an established yocto-oe repo, eg meta-foo... should they create a downstream mirror of meta-foo at git.projects.genivi.org? | 10:54 |
| paulsherwood | (presuming that the engineers have no ability to push branches directly to upstream, so need to stage their work somewhere) | 10:54 |
| paulsherwood | (if others know, besides jeremiah, please jump in) | 10:55 |
| paulsherwood | and actually, i should ask the same question of AGL folks | 10:55 |
| CTtpollard | I don't know, but it would be of use for me to know for the meta-ivi problem | 10:56 |
| paulsherwood | note that, in the absence of a standard way of doing this, it would seem that engineers will have to create their own fork somewhere (eg github) and then point their wip at that... which will likely lead to confusion if others start point at their wip, turning them into a new 'upstream' | 10:58 |
| paulsherwood | CTtpollard: i'll ask this officially on the lists... hopefully we can iron this out before you get too tangled up | 10:59 |
| CTtpollard | paulsherwood: it is appreciated, I'm very much against pointing official documentation to personal github forks, so I'd like to see the issue resolved | 11:01 |
| paulsherwood | ack | 11:01 |
| *** gunnarx has joined #automotive | 11:04 | |
| gunnarx | paulsherwood: This is only my opinion, but I think it follows a natural progression: First try to work upstream. If changes are not accepted, or not fast enough, use a mirror at GENIVI git. | 11:05 |
| gunnarx | But also don't forget that Yocto allows .bbappends, so you have the ability to do some local minor modifications on top of the unmodified upstream layer. | 11:06 |
| paulsherwood | gunnarx: 'try to work upstream'... unless folks have push rights upstream, that's not possible iiuc? | 11:07 |
| gunnarx | I haven't seen that we have ever had the need to fork any of the generic layers (meta-openembedded) so far. I think there is no generally applicable answer - there is so much diversity in the code. | 11:07 |
| gunnarx | Propose to upstream, send patches | 11:07 |
| gunnarx | whatever each project's contribution process is | 11:08 |
| paulsherwood | gunnarx: sorry to labour this... | 11:08 |
| gunnarx | no it's fine | 11:08 |
| paulsherwood | imagine i am working on a GENIVI project... in public. | 11:08 |
| paulsherwood | i find/think i have to make some changes to meta-foo | 11:09 |
| gunnarx | like meta-openembedded for example? | 11:09 |
| paulsherwood | while i am working, i want to push my work-in-progress changes somewhere | 11:09 |
| paulsherwood | and clearly they should not go to upstream, because i haven't even got them wroking for sure yet | 11:10 |
| gunnarx | I get it | 11:10 |
| paulsherwood | so, if genivi had its own mirror of meta-foo, i can push my stuff *in branches* there.... | 11:10 |
| paulsherwood | if/when i'm confident, i submit patches to upstream | 11:10 |
| paulsherwood | in the meantime, i can have other things wip off my branch | 11:11 |
| gunnarx | So you could.... | 11:11 |
| gunnarx | 1. work locally, not push until it works. 2... | 11:11 |
| gunnarx | 2. for backup purposes push to a "private" git repo on a server | 11:11 |
| paulsherwood | 1. is no use. i'm working in the open. i need to share my stuff to get feedback | 11:11 |
| gunnarx | hang on I'm not done. :) | 11:11 |
| paulsherwood | 2. neither | 11:11 |
| gunnarx | 3. work on a development branch and push that. Instructions should make clear that it is not guaranteed to work. That's pretty typical. | 11:12 |
| paulsherwood | 3. push it *where*? | 11:12 |
| gunnarx | OK so let me start over... | 11:13 |
| gunnarx | Consider gdp-submodules - it has a little code within it, and also brings in a number of layers that are separate projects | 11:13 |
| gunnarx | If I want to make a change that requires a change in meta-ivi I have the option to - make gdp-submodules use a forked version of hte layer | 11:13 |
| gunnarx | (in this case on github) | 11:14 |
| gunnarx | or - make it depend on some layer (private / local / whatever) so my local build works, push my changes (in order to back them up) to a public clearly makred "experimental brannch" | 11:14 |
| gunnarx | This branch will not work until upstream meta-ivi have accepted the patches I simultaneously send them. | 11:15 |
| gunnarx | So there is a time gap, but the branch being marked experimental shows that it is not guaranteed to work. | 11:15 |
| gunnarx | I'm not sure if it came across all the details here - we'd need a whiteboard. :) | 11:16 |
| paulsherwood | gunnarx: so basically you are saying that if i want to publish my work-in-progress i should create my own fork | 11:16 |
| gunnarx | Well, sending patches to upstream mailing list is also a kind of publishing | 11:16 |
| paulsherwood | gunnarx: i think you are missing my point | 11:16 |
| gunnarx | So you don't strictly need a git repo to publish | 11:16 |
| paulsherwood | i am working on a collaborative project. i want to get others feedbakc on my WIP before i offer it upstream... | 11:17 |
| gunnarx | No, I think I am getting it, but there are multiple tangents to this. Our projects are built out of multiple different repos for instance. | 11:17 |
| gunnarx | OK. So sending patches is that an acceptable way to get feedback? | 11:17 |
| paulsherwood | if i don't do that, i may waste upstream's time submitting patches that my colleagues would fix or tell me are not required | 11:17 |
| paulsherwood | gunnarx: not really | 11:17 |
| gunnarx | OK, that's a more specific problem. Why are patches not good enough? | 11:18 |
| paulsherwood | it's more friction on a day-to-day basis than just saying - her'es my branch, if anyone wants to try irt | 11:18 |
| paulsherwood | it is quite normal for git users to publish their branches. sending patches is a more formal thing | 11:19 |
| gunnarx | I understand. Yes having a git repo is some convenience. People might do a git pull <yourrepo> faster than applying patches (depending on their tools) | 11:19 |
| paulsherwood | exactly | 11:19 |
| gunnarx | So, your answer is you need a publicly accessible git repo containing a copy of the project you want to propose changes to. | 11:19 |
| paulsherwood | so... genivi has no mirrors of meta-foo for genivi folks to collaborate in. hence each person will likely fork some repos at github | 11:20 |
| gunnarx | what's the remaining question? :) | 11:20 |
| gunnarx | Yes, sure, we could have mirrors | 11:20 |
| paulsherwood | we *should* have mirrors, is my view, to avoid confusion | 11:20 |
| gunnarx | Depends on what you consider official. You suggested that these are changes that are so untested that you want colleagues feedback first. Github might be more indicative of something being not official? | 11:21 |
| gunnarx | Let's say there is a GENIVI copy, who has push access? All developers? | 11:21 |
| paulsherwood | whoever is granted that access | 11:21 |
| gunnarx | if it's going to be useful, that is whoever has any contribution, IOW anyone who asks for it. | 11:22 |
| paulsherwood | i think we're gradually thrashing throubgh that discussion for AGL | 11:22 |
| gunnarx | Or, maybe we are talking about maintainers here | 11:22 |
| gunnarx | Are you speaking as a "maintainer"? | 11:22 |
| paulsherwood | what a 'maintainer' is depends on the project | 11:23 |
| paulsherwood | i'm speaking as someone who wants to unravel the confusion so that engineers can work effectively | 11:23 |
| gunnarx | sure. but I'm trying to get to the core | 11:23 |
| gunnarx | absolutely, a worthy goal | 11:23 |
| gunnarx | It's not a bad idea to have an official GENIVI copy of whatever sub-projects we are working on | 11:24 |
| paulsherwood | to be clear, if each engineer creates their own fork, it *does* lead to confusion, because they *do* end up becoming new upstreams wherher the engineers intend that or not | 11:24 |
| paulsherwood | i discovered yesterday that one meta-foo has three currently active upstreams, for example | 11:25 |
| gunnarx | Maybe. I'm not sure how well such a process can be managed by rules or convention | 11:25 |
| gunnarx | However, I would consider that GENIVI (and you'll find the same for AGL) builds lots of different software. Prematurely cloning them all is not required/appropriate | 11:25 |
| paulsherwood | (ie three separate repos published, all with upstream content) | 11:25 |
| paulsherwood | (distinct from each other) | 11:25 |
| * paulsherwood needds to eat | 11:25 | |
| gunnarx | In most of the cases working only upstream works. | 11:26 |
| gunnarx | So this process is really just appropriate for the most actively changed adopted code I would say. | 11:26 |
| paulsherwood | gunnarx: i strongly disagree. i can't work directly upstream on 99.99999999% of the projects in the world, because i don't have the superpowers | 11:28 |
| gunnarx | ??? | 11:28 |
| gunnarx | working upstream still means "email them your patches" | 11:29 |
| gunnarx | substitute whatever contribution process they prefer | 11:29 |
| gunnarx | I think my statement stands. Having a mirror that people can commit to of every software in our platform encourages local changes which are not shared upstream. | 11:30 |
| dl9pf | working upstream means indeed to use their process ... in reality that means prep'ing 2 patches, one gets sent into gerrit and one possibly to the upstream ML | 11:31 |
| dl9pf | or whatever upstream uses. | 11:31 |
| dl9pf | but that is how it is ... usually we're on a stable version and upstream is using master. | 11:32 |
| dl9pf | I think the best policy still is "upstream first" aka the patch must be submitted or have landed in upstream before it can be included | 11:33 |
| dl9pf | for stuff that is upstreamable | 11:33 |
| gunnarx | To summarize (and it's affected by our useful exchange paulsherwood) I would say that GENIVI might make local "forks" of projects that you are working heavily in to promote your use case of sharing stuff and getting "local community" feedback. However, for most other things you have to first fix upstream what you need to do (which takes a while), and only then do you introduce the dependent changes in the GENIVI project. For more slowly | 11:35 |
| gunnarx | moving software, this is acceptable, IMHO. | 11:35 |
| gunnarx | Falling into the first category would likely be only some of the yocto meta-foo, as you suggested. But a copy should be set up when the need arises, IMHO | 11:37 |
| gunnarx | I've been mixing the terms mirror/copy and fork a bit. But to add to the above the "source mirror" we have discussed for CIAT, that 100% accurately tracks upstream is of course something different. It's for availability guarantees, performance, reduced bandwidth usage etc. But those would not allow any changes and commits for code review purposes. | 11:42 |
| gunnarx | /those mirrors/ | 11:43 |
| gunnarx | dl9pf: Ack to your input. thanks. | 11:45 |
| *** emaj has joined #automotive | 11:55 | |
| CTtpollard | if I'm to email to meta-ivi re adding the common api to branch/7.0, I will include genivi-project and genivi-meta-ivi@lists.genivi.org? or a specific yocto list? | 11:56 |
| CTtpollard | *common api fix | 11:56 |
| gunnarx | As far as I am aware genivi-meta-ivi is the "yocto list" for this layer. But I don't know the Yocto preferred policy - I'd be surprised if they want all patches/questions copied to some general list also.... | 11:57 |
| gunnarx | Since it's GDP related, genivi-projects would be appropriate to include. | 11:57 |
| CTtpollard | that was my though process | 11:57 |
| CTtpollard | *thought | 11:57 |
| gunnarx | seems sound | 11:58 |
| CTtpollard | genivi-projects as a direct or cc? | 11:58 |
| gunnarx | Most people don't care (pet peeve of mine als). Probably your guess is as good as mine. Let's say cc, this is a mail "to" meta-ivi. | 11:59 |
| gunnarx | paulsherwood: To answer your original question while we wait for Jeremiah's input: I believe we only have the generic "upstream first" policy regarding this. I would like to propose according to the above summary. A (GENIVI) copy of a git repo can be done only when a need has been identified (and removed if the need disappears). A maintainer must be assigned to each GENIVI repository, including such copies. | 12:02 |
| gunnarx | And the maintainer(s) would typically delegate commit access by the way... | 12:02 |
| jonathanmaw | I've been trying to get the GDP running on the minnowboard using the instructions at http://wiki.projects.genivi.org/index.php/Hardware_Setup_and_Software_Installation/MinnowMax, and while I can get weston to start and show some things on screen (gdp-hmi-background and gdp-hmi-panel), I don't see gdp-hmi-launcher appear | 12:09 |
| jonathanmaw | and with variations on the recommended changes to weston_1.5.0.bbappend, I've seen it laid out as: | 12:10 |
| jonathanmaw | * A background image, the gdp-hmi-background and gdp-hmi-panel appearing on weston-ivi-shell's default hmi-shell | 12:10 |
| jonathanmaw | * A grey background with cursor. Moving the cursor causes the gdp-hmi-background to flicker into visibility, but vanish when the cursor stops moving | 12:11 |
| jonathanmaw | * A grery background, and gdp-hmi-panel at the bottom | 12:11 |
| jonathanmaw | the minnowboard is also a bit more unstable at booting the GDP, generally failing to boot all the way to weston the first time I boot it after imaging the rootfs. | 12:13 |
| jonathanmaw | the wiki page has a warning that the page is a work-in-progress, so I suppose this is something that GDP maintainers have to figure out the cause for and fix. | 12:16 |
| paulsherwood | gunnarx: ok, so do you think that policy is correct, given what i've tried to explain? | 12:17 |
| paulsherwood | 12:30 < gunnarx> I think my statement stands. Having a mirror that people can commit to of every software in our platform encourages local changes which are not shared upstream. | 12:17 |
| paulsherwood | that is going to happen *anyway*. | 12:18 |
| paulsherwood | the difference is that the forks can either be in one place, where we have some chance of cleaning up, or scattered over the internet | 12:19 |
| *** emj has joined #automotive | 12:23 | |
| *** emj is now known as Guest45043 | 12:23 | |
| *** emaj has quit IRC | 12:26 | |
| CTtpollard | I've sent my email to the lists, meta-ivi is waiting approval | 12:26 |
| *** Guest45043 has quit IRC | 12:28 | |
| *** brlogger has joined #automotive | 12:34 | |
| fredcadete | as a stopgap of course | 12:34 |
| paulsherwood | fredcadete: one thing i'm still a little unclear on... if folks use bbappend as you suggest, isn't that in effect forking? | 12:36 |
| paulsherwood | i appreciate it seems to be part of the design of bitbake etc... but using it means we have a delta vs upstream? | 12:37 |
| fredcadete | paulsherwood: up to a point it scales better than forking | 12:37 |
| fredcadete | paulsherwood: if each layer's overrides or patches don't conflict | 12:38 |
| fredcadete | paulsherwood: so you can have one layer correcting the SRC_URI and another layer patching code for example | 12:38 |
| fredcadete | paulsherwood: you do have a delta from upstream but it is made explicit in your layer what the extent of that delta is | 12:40 |
| paulsherwood | fredcadete: but it's still a fork? | 12:40 |
| fredcadete | paulsherwood: in my usage of yocto I find it much easier to understand the delta in a bbappend than if I have to compare git repos | 12:41 |
| CTtpollard | if people think it's an acceptable stop gap, I think it would be suitable | 12:41 |
| paulsherwood | fredcadete: understood. but this practice seems to explicitly lead people away from submitting their stuff upstream? | 12:41 |
| fredcadete | paulsherwood: I don't see it as a fork, as much as a distro's patches are not a fork | 12:42 |
| paulsherwood | fredcadete: you may be right but i remain confused. if i create a bbappend, upstream won't accept it i expect? | 12:44 |
| *** gunnarx has left #automotive | 12:44 | |
| *** gunnarx has joined #automotive | 12:44 | |
| *** emaj has joined #automotive | 12:44 | |
| fredcadete | paulsherwood: of course ideally you submit upstream. To me a patch in a bbappend is more explicit than a forked git repo, and as such it is easier to measure your delta (and related maintenance burden) and to know what you still have to upstream | 12:44 |
| paulsherwood | so now, i have my work, with my bbappend... and i publish it on behalf of (say) genivi or agl. | 12:44 |
| paulsherwood | then someone turns up, takes my stuff with the bbappend... builds on it. | 12:45 |
| paulsherwood | now i'm a new upstream :/ | 12:45 |
| fredcadete | paulsherwood: for example my team's general policy when a bug is found is to: 1.test | 12:45 |
| *** wschaller_ has quit IRC | 12:45 | |
| fredcadete | 2. make a bbappend with a patch and validate with CI | 12:45 |
| fredcadete | 3. submit upstream | 12:45 |
| fredcadete | 4. when upstream integrates it and we upgrade to patched version, remove the delta from the bbappend | 12:45 |
| fredcadete | paulsherwood: yes, you do have the risk of building shaky castles with yocto layers | 12:46 |
| paulsherwood | ack. | 12:46 |
| fredcadete | as much as with any delta | 12:46 |
| gunnarx | paulsherwood: A key detail is that the .bbappend is in this case placed in a different layer than the original. That's one part of the layering concept. If your unique changes (in your layer) do not fit in the original project, you bbappend it. | 12:46 |
| gunnarx | If someone builds on top of your layer then yes, they depend on you... :) | 12:47 |
| paulsherwood | so, if i uncerstand AGL's remit correctly, which is 'automotiv grade' and 'production quality', we must absolutely avoid shaky castles | 12:47 |
| gunnarx | +1 on the other concerns, it's something that needs careful management. | 12:47 |
| paulsherwood | maybe i have misundertstood... is AGL ok maintaining deltas vs upstream for the very long term, do we know? | 12:48 |
| paulsherwood | (and same question for GENIVI...) | 12:48 |
| paulsherwood | s/maintaining deltas vs upstream/maintaining its own upstream/ | 12:49 |
| gunnarx | No it must be avoided as much as possible. I distinctly saw the word stopgap earlier. | 12:49 |
| paulsherwood | gunnarx: i agree. unfortunately i think that until more of the contributors underdtand the issues deeply, it will be unavoidable | 12:50 |
| gunnarx | With that substitution the question becomes unanswerable because it is generic. We do maintain some software right? | 12:50 |
| fredcadete | taking the current example, a possible approach could be to add a bbappend overriding the SRC_URI; this unblocks work in the open and the rest of the GDP build can be validated | 12:50 |
| fredcadete | in parallel submit to meta-ivi the correction of SRC_URI | 12:50 |
| gunnarx | fredcadete is a wise man | 12:51 |
| paulsherwood | fredcadete: adding the bbappend is not the only way. fixing the SRC_URI alone in a branch would achieve the same result? | 12:51 |
| CTtpollard | on the face of it I think that solution is potentially better than unlocking my pointing at a mirror/fork | 12:51 |
| CTtpollard | *unblocking by pointing | 12:51 |
| gunnarx | That was easier to parse :) | 12:52 |
| * paulsherwood thinks the bbappend approach masks the problem, and is extra work, but may be wrong as he often is | 12:52 | |
| gunnarx | +1 from me. Be prepared to remove it quickly again if meta-ivi responds to your request. | 12:52 |
| CTtpollard | fredcadete: do you mind replying with your suggestion to my post, so non #automotive lurkers can see? | 12:53 |
| gunnarx | paulsherwood: stopgap, unblocking, making things work, reversable... :) You need to see the positive side more. | 12:53 |
| fredcadete | paulsherwood: the question here is a bbappend versus a fork. Making a fork opens the door to even more delta , that in my opinion is less visible and the provenance is less clear than with a bbappend in the layer that is requesting the delta | 12:54 |
| paulsherwood | gunnarx: lots of people tell me that :) it may or may not be applicable here | 12:54 |
| fredcadete | CTtpollard: sure, in a minute | 12:54 |
| gunnarx | For example, now that CTtpollard has caught up I am pointing my project back on the official meta-genivi-demo | 12:54 |
| CTtpollard | fredcadete: awesome! thanks | 12:54 |
| gunnarx | we're talking about various temporary fixes to keep things flowing here | 12:54 |
| gunnarx | *back to | 12:55 |
| gunnarx | fork obliterated. for the moment. | 12:55 |
| gunnarx | Unrelated to this I just rebased my master and force pushed it. EVIL... :) | 12:56 |
| gunnarx | But I never promised that master was a good branch to rely on... or any other to be honest | 12:56 |
| CTtpollard | gunnarx: evilness is allowed on friday afternoons | 12:58 |
| gunnarx | I won't do it for the koelsch/minnowboard/porter branches to be nice | 12:58 |
| *** wschaller_ has joined #automotive | 13:00 | |
| CTtpollard | gunnarx: you can update you renesas modules to bsp 1.8 commit b42c0c82d628cc3e7af728df668cf4459a50621f | 13:03 |
| CTtpollard | which is the current recommendation from meta-gdp | 13:04 |
| CTtpollard | koelsch and porter are on the same commit now, after some fixes from slawr | 13:05 |
| gunnarx | yes, thanks, it's on my list | 13:05 |
| gunnarx | I wanted to confirm the build once first but if that's already the consensus. I didn't see anything risky in the diff either so, yes I will do it | 13:06 |
| CTtpollard | :) | 13:06 |
| CTtpollard | I can confirm porter builds off it, my Koelsch build is in the works as we speak | 13:06 |
| gunnarx | I just realized something - we have a different minnowboard branch on meta-genivi-demo. I was about to send an email to ask about the minnowboard instructions, why they are different | 13:07 |
| CTtpollard | ok I can take a look, what exactly is the difference? | 13:07 |
| gunnarx | I have a prepared a nice URL for you :) https://github.com/johnnytk/meta-genivi-demo/compare/koelsch...minnowboard | 13:08 |
| gunnarx | It's looks a bit of a mess. Minnowboard adds a patch which uses some new icons, which are not used on Koelsch if I see correctly. | 13:09 |
| CTtpollard | this is inline with the instructions on the wiki I believe | 13:09 |
| gunnarx | Yes, correct | 13:09 |
| gunnarx | Koelsch OTOH instead of patching includes a full weston.ini in the layer, and simply installs it. | 13:10 |
| gunnarx | which seems like a better way. But it's odd that they aim for different results also, not only different methods. | 13:11 |
| CTtpollard | ty fredcadete | 13:13 |
| fredcadete | np | 13:14 |
| CTtpollard | gunnarx: in the renesas layer? | 13:15 |
| gunnarx | The meta-ivi commit that adds the installation of a complete weston.ini 6 months ago 3736b07c "use complete file instead of patch" did not remove the patch from the directory... | 13:15 |
| gunnarx | CTtpollard: can you rephrase, not sure what you refer to | 13:16 |
| CTtpollard | gunnarx: no worries, I can see the commit you're referencing | 13:16 |
| gunnarx | "Koelsch" above means the koelsch branch on johnnytk/meta-genivi-demo, which also should correspond to the wiki instructions. | 13:16 |
| CTtpollard | yep | 13:17 |
| gunnarx | I'm pretty sure the patch could be applied to the ini once and for all, the ini stored and just installed as is, and that there is no difference needed between Koelsch and Minnowboard in this respect | 13:18 |
| CTtpollard | that would be better than having branches of gdp for the two, so they can both work from master | 13:19 |
| paulsherwood | +eleven | 13:19 |
| gunnarx | Not sure what the Koelsch build does here - it would seem it is not referencing the .png files at all | 13:19 |
| gunnarx | Exactly, I think the branches can be merged/removed | 13:19 |
| CTtpollard | however! using branches for sub-modules of the other repo's is still a good approach imo | 13:19 |
| gunnarx | Yes. I looked at subtrees, very cool use of the git data module and as far as I see it better when you are mostly in "control of" all the different parts yourself. Since yocto layers are separate projects where we must relate to different upstreams, submodules seem the better fit as they enforce the separation. An advanced user could of course switch back and forth as they see fit. | 13:21 |
| gunnarx | that's *git data model* of course | 13:23 |
| *** fredcadete_ has joined #automotive | 14:18 | |
| *** fredcadete has quit IRC | 14:20 | |
| *** fredcadete has joined #automotive | 14:22 | |
| *** fredcadete_ has quit IRC | 14:22 | |
| rjek | Slow clap, Chrysler: https://twitter.com/mikko/status/632199201720545280/photo/1 | 14:38 |
| *** fredcadete has quit IRC | 14:39 | |
| *** fredcadete has joined #automotive | 14:46 | |
| FelixH | x) | 14:46 |
| fredcadete | rjek: that's not so surprising after reading the exploit's whitepaper | 14:47 |
| rjek | Yeah | 14:48 |
| gunnarx | FYI, gdp-submodules now back to a non-forked meta-genivi-demo from GENIVI git , except for the minnowboard branch but I suspect we can avoid it soon too | 14:50 |
| CTtpollard | ace gunnarx :) | 14:51 |
| gunnarx | CTtpollard: It's might cause a little trouble | 14:53 |
| gunnarx | So let's assume someone starts on Koelsch. When you switch to minnowboard, the URL changes inside .gitmodules | 14:53 |
| gunnarx | but the hash won't be found inside meta-genivi-demo I suspect. I'm pretty sure you have to manually go into that module, add a new remote, fetch the commits you need from there. | 14:54 |
| gunnarx | Don't think submodules handle that automatically as they should even with a git submodule update? | 14:54 |
| gunnarx | Also, when a layer is removed (renesas / intel is removed as you switch between them), git will download the new BSP when you do update but it will not remove the directory contents of the old. I guess it's a security thing | 14:56 |
| gunnarx | Oh I just remembered, there's a sync command... | 14:57 |
| *** emj has joined #automotive | 15:03 | |
| *** emj is now known as Guest56416 | 15:03 | |
| gunnarx | Never mind me... I added submodule sync to init.sh also. That should reduce some of the first problem. | 15:04 |
| CTtpollard | tbh, when I was switching branches, I was doing clean checkouts of the branches | 15:04 |
| *** emaj has quit IRC | 15:06 | |
| gunnarx | Not a bad idea, but I'm just trying to anticipate a few user problems. It won't be perfect though. | 15:07 |
| *** gmacario has quit IRC | 15:07 | |
| *** gunnarx has quit IRC | 15:12 | |
| *** emaj has joined #automotive | 15:17 | |
| *** Guest56416 has quit IRC | 15:20 | |
| *** KlausUhl has quit IRC | 15:22 | |
| *** fredcadete has quit IRC | 15:47 | |
| *** CTtpollard has quit IRC | 15:54 | |
| *** jlrmagnus has joined #automotive | 16:11 | |
| jlrmagnus | Morning | 16:11 |
| rjek | hi jlrmagnus | 16:12 |
| jlrmagnus | Hello rjek | 16:13 |
| *** jlrmagnus has quit IRC | 16:21 | |
| *** jlrmagnus has joined #automotive | 16:21 | |
| weston | hi all | 16:38 |
| jlrmagnus | Hello weston | 16:39 |
| weston | jlrmagnus: hows going man | 16:39 |
| *** jacobo has quit IRC | 16:50 | |
| *** bbranch has joined #automotive | 16:51 | |
| *** jonathanmaw has quit IRC | 16:51 | |
| jlrmagnus | Pretty well. Lively firewall discussion here and on the lists. | 16:53 |
| paulsherwood | yup :) | 16:56 |
| jlrmagnus | I pinged Ford's SOTA guy to see if they have any interest in this. | 16:58 |
| rjek | What in general is the main driving force for wating SOTA for software running on EMUs, btw? I'm assuming a combination of cost cutting (in terms of avoiding recalls, or updating during service) and urgency when a complex system has a serious problem. | 17:00 |
| *** mdunford has quit IRC | 17:07 | |
| *** wschaller_ has quit IRC | 17:15 | |
| jlrmagnus | rjek: Recall mitigation. | 17:20 |
| jlrmagnus | Today, for a mainstream brand, a recall starts at $40 when the car rolls into the shop, and ticks up from there. | 17:20 |
| jlrmagnus | To be able to solve software issues OTA, and do it without the publicity of a recall would be a big benefit. | 17:20 |
| myself | But the complexity of testing -- what happens if there's a SOTA in progress while the car's in the shop and modules are being pulled? -- shouldn't be ignored or it'll come back to haunt you | 17:50 |
| myself | any other reflash, you know better to do while Jimbob Greasemonkey is rooting around in the wiring, but a SOTA update you have no such common sense about | 17:50 |
| jlrmagnus | True. Which is why you have a local SOTA manager running on the IVI, making sure that the vehicle is in the right state. | 17:51 |
| jlrmagnus | At the end of the day you will have dual flash banks in the control unit. Bank A is running. Flash Bank B. Reboot in to Bank B. | 17:51 |
| jlrmagnus | Have a watchdog monitor the reboot and reset to Bank A if it fails. | 17:52 |
| jlrmagnus | Report up to the backend server so that the vehicle can be flagged. | 17:52 |
| jlrmagnus | That's the last line of defense against a bricked unit. | 17:52 |
| myself | Yeah, now honestly how many modules out there have a robust A/B and watchdog setup like that? We all know it's ideal, but very very few actually do it that way | 17:53 |
| myself | that'll be a generational change before you're "safe" using SOTA on the installed base | 17:54 |
| myself | or, find some other way to do it, or, accept the risk and bricked modules once in a while | 17:54 |
| jlrmagnus | It's risk statistics assessment. How many vehicles with shitty ECUs will be bricked by this push, and is it worth the cost? | 17:54 |
| jlrmagnus | There will have to be a generational change for this to become robust. | 17:54 |
| jlrmagnus | I believe that purchasing / financial is the biggest obstacle since they love to strip out capacity of hardware modules before they are ordered for production. | 17:55 |
| jlrmagnus | "Double the necessary flash memory? I think not." | 17:55 |
| myself | And even as time marches forward, there will always be modules where someone shoots that down for cost reasons, or where some supplier didn't get the memo but we want to use their module anyway | 17:56 |
| jlrmagnus | See above. | 17:56 |
| myself | yup, it's all calculated risk | 17:56 |
| jlrmagnus | I've seen it happen myself (not in JLR, mind you). | 17:56 |
| jlrmagnus | A couple of thousand of bricked vehicles are usually a good motivator for a T1 to shape up. | 17:57 |
| jlrmagnus | Ask Harman's IVI people... | 17:57 |
| myself | There are plenty more examples, too :) | 17:57 |
| jlrmagnus | Indeed. | 17:59 |
| *** gvancuts has joined #automotive | 17:59 | |
| *** bbranch1 has joined #automotive | 18:01 | |
| *** bbranch has quit IRC | 18:03 | |
| *** RzR has quit IRC | 18:03 | |
| jlrmagnus | First spin of the circuit board. http://i.imgur.com/iKaqMp6.jpg | 18:31 |
| jlrmagnus | We have to redo it since we missed a few things, but the form factor will remain. | 18:31 |
| jlrmagnus | One DB9 connector at each end. | 18:32 |
| FelixH | =) | 18:35 |
| FelixH | In production you plan to let it as a connected device that can be removed or to integrate in the IVI box ? | 18:36 |
| jlrmagnus | It will be a removable device. | 18:36 |
| jlrmagnus | Pretty much a sandwich connector. | 18:36 |
| jlrmagnus | This is, however, reference hardware. I am sure production projects would do some redesign. | 18:36 |
| jlrmagnus | lunchtime. | 18:36 |
| FelixH | ok thx | 18:37 |
| myself | yeah, if you make the connectors male and female, you can just plug past it for bypass testing | 18:38 |
| *** bbranch1 has quit IRC | 19:10 | |
| jlrmagnus | That's the idea. We may end up doing male male just to ease CANalyzer testing the the PCAN adapters. | 19:21 |
| jlrmagnus | A breakout connector will be needed anyway for power and some GPIO pins. | 19:22 |
| *** bbranch has joined #automotive | 20:11 | |
| *** emaj has quit IRC | 20:25 | |
| *** RzR has joined #automotive | 20:41 | |
| *** bbranch has quit IRC | 21:35 | |
| *** bbranch has joined #automotive | 21:38 | |
| *** gvancuts has quit IRC | 21:52 | |
| *** bbranch has quit IRC | 22:03 | |
| *** jlrmagnus has quit IRC | 23:29 | |
| *** gvancuts has joined #automotive | 23:46 | |
Generated by irclog2html.py 2.14.0 by Marius Gedminas - find it at mg.pov.lt!
