| *** gtristan has quit IRC | 02:27 | |
| *** thrace has joined #baserock | 02:39 | |
| *** gtristan has joined #baserock | 02:51 | |
| *** flatmush has quit IRC | 03:23 | |
| *** flatmush1 has joined #baserock | 03:23 | |
| *** gtristan has quit IRC | 04:37 | |
| *** thrace has quit IRC | 05:54 | |
| *** thrace has joined #baserock | 05:54 | |
| *** tlsa_ is now known as tlsa | 08:59 | |
| *** gtristan has joined #baserock | 11:47 | |
| pedroalvarez | So, for Raspberry Pi, I need to copy some blobs from this repo to /boot: https://github.com/raspberrypi/firmware/tree/master/boot | 17:10 |
|---|---|---|
| pedroalvarez | but looks like they provide a *lot* of thins in there, making it really big (4G) | 17:11 |
| pedroalvarez | I'm against lorrying it, any sane alternatives? | 17:11 |
| pedroalvarez | - Copying files to definitions.git to be installed with install-files | 17:12 |
| pedroalvarez | - Copy the files to a branch of another component of the bsp (kernel?) and install them at that point? | 17:13 |
| lostduck | bsp-support repo, add the binaries with morph add-binary ? | 17:14 |
| persia | I'm against copying the files to a branch of definitions: git doesn't maintain enough branch sanitization. | 17:17 |
| pedroalvarez | persia: I meant master of definitions.git | 17:17 |
| persia | Essentially, this brings up back to the unsolved binary injection problem. | 17:18 |
| persia | pedroalvarez: That would be even worse. | 17:18 |
| pedroalvarez | :) | 17:18 |
| pedroalvarez | lostduck: that might be the best option | 17:18 |
| persia | When we receive a blob, we need a mechanism to inject that blob into a build, essentially treating it as a built object (with an opaque build process). | 17:18 |
| persia | We have a mechanism to treat it as a source (lostduck's suggestion), but this implies either lorrying from somewhere or that one has unmirrored sources. | 17:20 |
| persia | git-fat helps make it less absolutely terrible, but ... | 17:20 |
| lostduck | fwiw, nix solves this by fetching blobs from a given url, the sha sum of the blob must match a sha provided by the expression | 17:20 |
| persia | To me, that makes more sense, perhaps with a parameter that explains the path the blob ought have in a final system. | 17:21 |
| persia | And perhaps some mechanism to mirror blobs somewhere (lorry type: "blob"), to protect against loss of blob availability on the internet somewhere. | 17:21 |
| pedroalvarez | hm.. I think I'm going to go with the bsp-support.git option | 17:39 |
| pedroalvarez | I can also mirror the official repo, but it has way more things than I need | 17:39 |
| persia | The advantage of lorrying the official mirror is that you'll catch things if they change. | 17:45 |
| persia | Given the variety of things called "raspberry pi", this is probably a good thing. | 17:46 |
| pedroalvarez | jjardon: thanks for reviewing the GDP patch-set, and sorry I forgot about your comments, I had a busy week, and when cleaning up things today I found more things to fix than expected | 22:20 |
| pedroalvarez | I need to think about what to do with weston-gdp, I probably can use weston-genivi, but the weston-gdp version has this thing that you don't like (It sets WESTON_NATIVE_BACKEND depending on the architecture) | 22:22 |
| pedroalvarez | I believe this is essential to make weston work in our 2 GDP deployments (drm-backend for jetson, and fbdev backend for x86_64) | 22:23 |
| pedroalvarez | This way the systemd unit that starts weston doesn't have to decide which one to use | 22:23 |
| pedroalvarez | Would it be possible to set that variable after installing weston? or does it have to be in the ./configure step when building it? | 22:24 |
| jjardon | pedroalvarez: question is; why do you need the fbdev backend for x86_64? | 22:30 |
| jjardon | also, the drm backend is the default, so only the condition for x86_64 should be required | 22:36 |
| pedroalvarez | jjardon: hm.. is the drm backend available for x86? | 22:39 |
| pedroalvarez | always? | 22:39 |
| pedroalvarez | I remember getting weston working with fbdev because it was the only thing available in a VM | 22:40 |
| jjardon | ah | 22:40 |
| jjardon | VM is not the same as x86_64 | 22:40 |
| jjardon | in that case you have to use the fbdev backend, yes | 22:41 |
| pedroalvarez | heh, there is no way to know where the system will run | 22:42 |
| jjardon | yeah, you will have the same problem is you put your jetson image in a VM | 22:43 |
| jjardon | this will be not a problem anymore when virgil get merged in qemu: https://virgil3d.github.io/ | 22:50 |
| pedroalvarez | :) | 22:52 |
Generated by irclog2html.py 2.15.3 by Marius Gedminas - find it at mg.pov.lt!