| *** jlrmagnus has quit IRC | 00:29 | |
| *** bbranch has quit IRC | 05:03 | |
| *** bbranch has joined #automotive | 05:05 | |
| *** bbranch has joined #automotive | 05:10 | |
| *** poxar has quit IRC | 06:43 | |
| *** gunnarx has joined #automotive | 07:41 | |
| *** jonathanmaw has joined #automotive | 07:51 | |
| *** mdunford has joined #automotive | 08:06 | |
| *** jacobo has joined #automotive | 08:07 | |
| *** jeremiah has joined #automotive | 08:12 | |
| *** jeremiah1 has joined #automotive | 08:14 | |
| *** jeremiah_ has joined #automotive | 08:14 | |
| *** KlausUhl has joined #automotive | 08:20 | |
| *** poxar has joined #automotive | 08:29 | |
| *** CTtpollard has quit IRC | 08:38 | |
| *** CTtpollard has joined #automotive | 08:41 | |
| CTtpollard | woop! second build of GDP for porter has booted! | 09:11 |
|---|---|---|
| *** gunnarx has quit IRC | 09:11 | |
| paulsherwood | lovely :-) | 09:12 |
| dzen | porter ? as in beer ? | 09:12 |
| fredcadete | as in lager and koelsch | 09:12 |
| mdunford | so beer then? :) | 09:12 |
| fredcadete | yes, that's Renesas's naming scheme for their development boards | 09:13 |
| * rjek tries to remember the name of the company who named all their dev boards after scotches. | 09:14 | |
| *** wschaller has joined #automotive | 09:14 | |
| rjek | Perhaps the fact that alcohol is a common theme is telling. | 09:15 |
| jeremiah1 | lol | 09:15 |
| jeremiah1 | Interesting hackfest today with the builder folks from GNOME | 09:16 |
| jeremiah1 | They're looking into building out GNOME conitinuous and thinking about pulling in Yocto / Baserock | 09:16 |
| *** jeremiah1 has left #automotive | 09:18 | |
| *** jeremiah_ has left #automotive | 09:18 | |
| rjek | jeremiah: Interesting. | 09:19 |
| paulsherwood | jeremiah: maybe you can help me with this... | 09:30 |
| paulsherwood | does the idea of working from a managed/known mirror of upstreams seem clearly a win to you? | 09:31 |
| jeremiah | paulsherwood: Yes, absolutely. | 09:38 |
| jeremiah | We've seen in GENIVI that using the build system when it pulls from dead upstreams it causes problems. | 09:39 |
| jeremiah | I can imagine that we're going to see that issue again | 09:39 |
| jeremiah | I also can see the usefulness of a *single* location to pull from for our builds | 09:39 |
| paulsherwood | jeremiah: ok. but then i see gunnarx's point that to implement this for the GDP for example, we'd end up forking a load of recipes | 09:40 |
| jeremiah | Well, yes. | 09:40 |
| jeremiah | It is going to be huge. | 09:40 |
| jeremiah | This is why using maintained packages from a distro is so advantageous. | 09:41 |
| paulsherwood | when i explained this concept to wolfgang denx earlier this year he said 'this is clearly a good idea... you should take it to yocto upstream' | 09:41 |
| jeremiah | Doesn't Yocto do something like this already? | 09:41 |
| paulsherwood | well if it does, why are the default recipes pulling from the wild internet? | 09:42 |
| jeremiah | Likely because they don't want to do the work of hosting an archive. | 09:43 |
| paulsherwood | maybe there's some magic url-mapper shim i'm not aware of | 09:43 |
| jeremiah | I think, now that I look a bit, its really just a way for one to use Yocto with local sources. | 09:43 |
| jeremiah | So I don't think it really maps to a proper hosted semi-official mirror. | 09:43 |
| jeremiah | I don't know much about Lorry or the other tools you have but I don't know too many other tools that even attempt to do the kind of mirroring that baserock does | 09:44 |
| paulsherwood | well, i believe debian mirrors sources, but as tarballs | 09:45 |
| paulsherwood | presumablty the yocto local sources approach deals bzr, hg, svn etc? | 09:46 |
| jeremiah | To be honest I don't know about the internals | 09:46 |
| jeremiah | Debian does create source packages | 09:47 |
| jeremiah | And it hosts some upstreams in git as well | 09:47 |
| rjek | paulsherwood: Debian normally mirror the project's release tarballs, along with a seperate tarball containing Debian-specific patches | 09:47 |
| jeremiah | This allows you to do apt-get source <foo> and get the source of a given package | 09:47 |
| paulsherwood | rjek: ah, ok | 09:47 |
| rjek | paulsherwood: If a project doesn't make release tarballs (or Debian decide to ship a pre-release from a project's version control) then they make their own tarball. | 09:48 |
| rjek | But that's pretty rare | 09:48 |
| jeremiah | But what is great is that they have a source package FOR EVERY PACKAGE THEY SHIP! | 09:48 |
| rjek | (This also allows people to check the upstream release signature on what Debian mirrors and then patches, if such is provided) | 09:48 |
| jeremiah | Which means that the 25,000 package strong archive is highly available and maintained for you. | 09:49 |
| rjek | jeremiah: It's amazing how many distributions don't do that | 09:49 |
| jeremiah | rjek: It is. | 09:49 |
| jeremiah | And it is part of what makes Debian so valuable | 09:49 |
| rjek | Debian is love. | 09:49 |
| jeremiah | rjek++ | 09:49 |
| jeremiah | It means we can use Debian to create builds of an image and you automatically have the "complete and corresponding" source code | 09:50 |
| jeremiah | So you comply with the GPL trivially | 09:50 |
| rjek | Indeed. That's also one of the great things about Baserock's approach | 09:51 |
| jeremiah | So just stuff Debian sources in your CI and you can ship binaries. | 09:51 |
| paulsherwood | exactly | 09:51 |
| jeremiah | Yes, this is a huge benefit to Baserock's approach | 09:51 |
| jeremiah | Huge. | 09:51 |
| paulsherwood | jeremiah: so my dilemma is how to help agl, genivi and automotive in general achieve this benefit... | 09:52 |
| jeremiah | paulsherwood: Politically it may be hard because automotive folks are wedded to their tooling. | 09:52 |
| paulsherwood | i don't think offering to fork yocto will be very popular | 09:52 |
| paulsherwood | s/yocto/yocto and oe recipes/ | 09:52 |
| jeremiah | Practically just setting up a source mirror and enabling builds from Yocto should be fairly easy? | 09:53 |
| jeremiah | paulsherwood: Perhaps just implementing it and offering it for use would be enough for adoption? | 09:53 |
| jeremiah | Or perhaps you (rightly) want this to be funded? | 09:53 |
| paulsherwood | jeremiah: i believe that when others have done this, they forked the recipes | 09:53 |
| jeremiah | paulsherwood: Ah, I see. | 09:53 |
| jeremiah | hmm. | 09:53 |
| paulsherwood | it's not the funding, it's the question of maintenance | 09:54 |
| paulsherwood | i don't want to lead automotive into forking anything if i can avoid it | 09:54 |
| jeremiah | Shouldn't the maintenance be funded? | 09:54 |
| jeremiah | Agreed | 09:54 |
| paulsherwood | i think i need a constructive discussion with yocto and/or oe upstream | 09:54 |
| jeremiah | paulsherwood++ | 09:55 |
| paulsherwood | (as amazing as that sounds, given some of the arguments in genivi in recent years) | 09:55 |
| jeremiah | OE might be a good place to approach | 09:55 |
| jeremiah | But Richard Purdie in Yocto might be interested | 09:55 |
| paulsherwood | isn't richard active in both places? | 09:55 |
| jeremiah | I imagine, you likely know better than I, I don't really work with him. | 09:56 |
| jeremiah | But he's a Linux Foundation fellow so he would likely be open minded. | 09:56 |
| paulsherwood | ack | 09:56 |
| jeremiah | As I mentioned, GNOME builder is going try to incorporate Yocto and/or Baserock, a source code mirror might fit well in such a project and potentially might yield shared maintenance. | 09:58 |
| jeremiah | BUt I think its early days still there. | 09:59 |
| paulsherwood | jeremiah: ack, thanks for the headsup | 09:59 |
| * CTtpollard would like the various guides on the gdp wiki to have links to prebuilt images | 10:06 | |
| paulsherwood | here's a thought... could we do that and then just get folks to 'drop in' the binaries themselves? | 10:07 |
| CTtpollard | but there's the obvious licensing complexity, especially with the renesas boards | 10:07 |
| paulsherwood | (eg for renesas) | 10:07 |
| paulsherwood | there would be no licensing complexity if the binaries were not present in the images? | 10:07 |
| CTtpollard | I would not think so no | 10:08 |
| CTtpollard | but that's still adding to the complexity for a user who just wants to spin it up and may not have the knowledge / urge to start doing that | 10:08 |
| CTtpollard | you would however not need to wait on build time, which is a start | 10:09 |
| paulsherwood | CTtpollard: instructions for that would be simpler than the currnet process | 10:09 |
| CTtpollard | s/simpler/shorter | 10:11 |
| paulsherwood | both :) | 10:11 |
| *** jeremiah has quit IRC | 10:14 | |
| *** jeremiah_ has joined #automotive | 10:17 | |
| *** gunnarx has joined #automotive | 10:22 | |
| CTtpollard | what about non-renesas images? | 10:25 |
| *** jeremiah_ has quit IRC | 10:28 | |
| *** gunnarx has quit IRC | 10:42 | |
| *** gunnarx has joined #automotive | 11:03 | |
| CTtpollard | would it be acceptable to provide a renesas build without gfx acceleration, if it's still functional | 11:04 |
| fredcadete | maybe I am late to the conversation about the mirroring | 11:08 |
| fredcadete | but yocto has some stuff to avoid pulling from the internet every time you rebuild | 11:09 |
| fredcadete | I have tested it, mostly to make sure that what you deliver to a customer can have its source tracked and the build reproduced | 11:10 |
| fredcadete | even years later | 11:10 |
| *** wschaller has quit IRC | 11:10 | |
| paulsherwood | fredcadete: iiuc that's a 'local mirror'? ie sits on the developer/integrator's own machine? | 11:11 |
| fredcadete | paulsherwood: not necessarily, it can be put in a server in the basement for example | 11:12 |
| fredcadete | basically it's a bbclass and a set of variables that you can use to make your download directory a repository for all the sources | 11:13 |
| fredcadete | let me see if I can find the docs | 11:13 |
| paulsherwood | fredcadete: ok, i must do more reading on this. | 11:13 |
| fredcadete | paulsherwood: https://wiki.yoctoproject.org/wiki/How_do_I#Q:_How_do_I_create_my_own_source_download_mirror_.3F | 11:13 |
| paulsherwood | fredcadete: thanks! | 11:13 |
| fredcadete | paulsherwood: it's enough for saving bandwidth and reproduceability; but it's not what you want if you also want to heavily customize the packages in a repo | 11:15 |
| fredcadete | paulsherwood: no problem | 11:15 |
| paulsherwood | fredcadete: the use-case i'm mainly interested in is ciat on an ongoing basis for genivi and agl | 11:16 |
| paulsherwood | (and other projects too) | 11:17 |
| paulsherwood | the mirror will likely be used for licence compliance, traceability, reproducibility as well as driving the builds | 11:19 |
| fredcadete | paulsherwood: I'm afraid I don't have any good suggestion for that... in our internal usage of yocto we haven't yet found a very efficient way of doing ciat | 11:19 |
| fredcadete | paulsherwood: the trouble has mostly been how resource usage scales with several branches | 11:20 |
| paulsherwood | fredcadete: ack. i wonder if others have similar experiences | 11:20 |
| fredcadete | paulsherwood: we don't have a clean way of building a topic branch without rebuilding practically the whole system | 11:21 |
| fredcadete | so we do it with care | 11:21 |
| paulsherwood | ouch | 11:23 |
| fredcadete | it may or may not be a problem depending on your available computing resources | 11:25 |
| fredcadete | and the response time you want from the ciat | 11:25 |
| paulsherwood | understood | 11:29 |
| *** KlausUhl has quit IRC | 12:03 | |
| *** wschaller has joined #automotive | 12:22 | |
| gunnarx | CTtpollard: Recently built minnowboard successfully as well as koelsch (not deployed and tested either of those builds though). | 12:43 |
| gunnarx | According to branches koelsch and minnowboard at: https://github.com/gunnarx/gdp-submodules/ | 12:43 |
| gunnarx | For koelsch we had the necessary graphics drivers. For porter, they are downloadable with click-through license. Have no porter branch there yet but maybe soon. | 12:45 |
| CTtpollard | gunnarx: I'm currently having a poke are you submodule repo :P | 12:46 |
| CTtpollard | s/:p/:) | 12:46 |
| gunnarx | still not a parseable sentence, but that's ok :) | 12:47 |
| CTtpollard | yep sorry my head was in two conversations there | 12:47 |
| paulsherwood | gunnarx: this is irc, we have to make do :-) | 12:47 |
| *** emaj has joined #automotive | 12:54 | |
| CTtpollard | I think the use of the submodules suits what we need | 13:00 |
| gunnarx | Oh, Pollard, now I made the connection... | 13:05 |
| gunnarx | You have commit permission to meta-genivi-demo then, right? | 13:06 |
| CTtpollard | gunnarx yes | 13:06 |
| gunnarx | So currently our project has forked I think 2 layers, let me know if you think I can point m-g-d towards GENIVI git again. | 13:07 |
| CTtpollard | doing a recursive clone of a specific board branch through the use of submodules is imo a really clean way to do it | 13:08 |
| gunnarx | thanks, I think so too :) | 13:08 |
| paulsherwood | git subtrees (cough) | 13:08 |
| gunnarx | what? | 13:09 |
| paulsherwood | sorry, there's an alternative to submodules, subtrees.... better in some respects iiuc | 13:09 |
| * paulsherwood is on a call, half on irc | 13:09 | |
| paulsherwood | but your submodules soln works, so i'm not pushing | 13:10 |
| paulsherwood | just mentioning it in passing ;) | 13:12 |
| gunnarx | OK, I'll check. Submodules are indeed a little quirky. | 13:12 |
| paulsherwood | http://blogs.atlassian.com/2013/05/alternatives-to-git-submodule-git-subtree/ | 13:15 |
| gunnarx | Yes, found all that. | 13:15 |
| paulsherwood | :-) | 13:16 |
| gunnarx | I'm no fan of repo though for sure. | 13:16 |
| gunnarx | I should upload my unrepo program to github. Converts a project to submodules (if I remember, it's been a while) :) | 13:16 |
| CTtpollard | gunnarx: the head of m-g-d builds and deploys fine to porter and qemu for me, so I'd be happy for you to point to genivi git instead of the github fork | 13:16 |
| gunnarx | OK good, we'll put that on a short term list... Next is meta-ivi... | 13:20 |
| *** KlausUhl has joined #automotive | 13:21 | |
| gunnarx | "Since there’s no way to have two versions of a submodule checked out at once, it simply doesn’t try, effectively treating the entire submodule like a single binary file" | 13:22 |
| gunnarx | "(If you’ve ever tried to have two people working on a binary file that’s tracked in Git, you’ll have an idea of how much of a pain it is to resolve such conflicts.)" | 13:22 |
| *** jeremiah has joined #automotive | 13:23 | |
| gunnarx | Nonsense, IMHO. You need to do some supposedly unnecessary steps but you still have git supporting you when merging inside of the submodule, which is not the case for binaries. | 13:23 |
| gunnarx | Other than that, yes I agree all the things mentioned are indeed the problems you realize after using submodules for a while. | 13:24 |
| emaj | j #amb | 14:08 |
| *** gunnarx has quit IRC | 14:28 | |
| CTtpollard | I've posted my thoughts about it to the projects mailing list | 14:36 |
| *** felipealmeida has quit IRC | 15:00 | |
| *** felipealmeida has joined #automotive | 15:08 | |
| *** KlausUhl has left #automotive | 15:09 | |
| *** wschaller_ has joined #automotive | 15:13 | |
| CTtpollard | I've tested using kvm-qemu as described here, linked from the bottom of http://wiki.projects.genivi.org/index.php/Hardware_Setup_and_Software_Installation/qemux86-64 | 15:14 |
| CTtpollard | I think it definitely should be added to the main part of the guide, I've found that the instructions for it are already there, but hidden 'until prebuild binaries are available' | 15:15 |
| CTtpollard | there is a section hidden like this for actually providing the download urls which is understandable, but I'm not sure if the kvm method also needs to be hidden for that reason? | 15:16 |
| *** wschaller has quit IRC | 15:17 | |
| *** gunnarx has joined #automotive | 15:23 | |
| *** bbranch has left #automotive | 15:24 | |
| *** gunnarx has quit IRC | 15:34 | |
| *** jlrmagnus has joined #automotive | 15:55 | |
| *** jonathanmaw has quit IRC | 16:29 | |
| *** jeremiah has quit IRC | 16:31 | |
| *** jeremiah has joined #automotive | 16:33 | |
| *** jeremiah has quit IRC | 16:35 | |
| *** bbranch has joined #automotive | 16:36 | |
| *** jeremiah has joined #automotive | 16:37 | |
| *** mdunford has quit IRC | 16:48 | |
| *** wschaller_ has quit IRC | 16:54 | |
| *** tester1234 has joined #automotive | 17:29 | |
| *** jacobo has quit IRC | 18:29 | |
| *** myself has joined #automotive | 18:46 | |
| *** joone has quit IRC | 19:04 | |
| *** joone has joined #automotive | 19:07 | |
| *** jeremiah has quit IRC | 19:22 | |
| *** emaj has quit IRC | 20:38 | |
| jlrmagnus | CAN Firewall presentation complete | 21:13 |
| jlrmagnus | https://github.com/PDXostc/canfw/blob/master/doc/DRD_CANFW.xlsx?raw=true | 21:13 |
| jlrmagnus | Wrong file. | 21:13 |
| jlrmagnus | One sec | 21:13 |
| jlrmagnus | https://github.com/PDXostc/canfw/blob/master/doc/CAN%20Firewall.pdf | 21:15 |
| jlrmagnus | Hardware has been sent off for production. | 21:16 |
| jlrmagnus | I'll add the specs. | 21:16 |
| JEEB | 'grats | 21:41 |
| myself | not sure about the crypto math but the canb.us hardware should be able to do the rest today. | 21:42 |
| rjek | jlrmagnus: I noticed that RVI's build system checks stuff out at build time, and some deps are at HEAD rather than a specific hash. My Baserock and Debian love means this makes me sad. Can this be easily fixed? | 21:44 |
| rjek | Or do I have the wrong end of the stick? | 21:46 |
| jlrmagnus | Please note that all directories under deps are actually a part of the rvi_core repo. | 21:52 |
| jlrmagnus | The reason for this is the stupidity of GBS/OBS where the sandboxed machine does not have network access to pull deps. | 21:54 |
| rjek | ISTR that when issuing make, things got git cloned | 21:54 |
| jlrmagnus | Can you dump output to pastebin? | 21:55 |
| rjek | Would git submodules make more sense? | 21:55 |
| rjek | I'm in a pub atm, not at my laptop :-) | 21:55 |
| jlrmagnus | Possibly. This, however, is a part of rebar, erlangs build system. | 21:56 |
| rjek | Yeah, it was rebar | 21:56 |
| jlrmagnus | Separate repos do make sense, as is, but we need to clean up the GBS build | 21:56 |
| rjek | the rebar config file fills me with fear atm | 21:56 |
| rjek | Esp. because HEAD imports are not only very variable, they are man in rhe middleable | 21:57 |
| rjek | OBS makes me sad too :-) | 21:58 |
| jlrmagnus | Which branch are you working on? | 22:19 |
| jlrmagnus | I can lock it down to specific commits fairly easily. | 22:19 |
| *** jlrmagnus has left #automotive | 23:54 | |
Generated by irclog2html.py 2.14.0 by Marius Gedminas - find it at mg.pov.lt!