On 2019-05-10, Paul Wise wrote: > Please add support to the u-boot source package for building u-boot > binary packages for the Turris Omnia and other hardware where u-boot > requires OpenSSL. As I understand it, these binary packages are not > redistributable by Debian but folks could build or cross-build them > themselves for deployment on their own hardware.
That's my understanding, yes. > By using dpkg's build profiles support, those packages could be added > to the u-boot source package, not be built by default but still be > able to be manually buildable using the dpkg-buildpackage > --build-profiles option. I've thought about this as well... I've been hesitant to implement it wondering how it would interact with the NEW queue... if needed I guess a workaround would be to add them to the "u-boot" package, though it's not available on all architectures, and might violate "A binary package must contain the exact same content for all profiles with which it builds" And now that we've opened the discussion... Ideally, of course, would be to fix upstream to not require OpenSSL due to the incompatibility with GPL and port to another library that was GPL-compatible... in theory it's not a lot of code. I briefly tried looking into the GNU TLS OpenSSL compatibility layer, but it did not support the needed functionality. I also brought this issue up in Guix recently, but eventually just submitted a patch to remove OpenSSL from the u-boot packaging much like Debian already does: https://issues.guix.info/issue/34717 Some past discussion upstream: https://lists.denx.de/pipermail/u-boot/2017-November/312483.html https://lists.denx.de/pipermail/u-boot/2017-December/313616.html https://lists.denx.de/pipermail/u-boot/2017-December/313742.html It didn't seem like a licensing exception was plausible upstream, as u-boot is codebase with a lot of individual contributors over the years... live well, vagrant
signature.asc
Description: PGP signature
