<div dir="ltr"><br><div class="gmail_extra"><br><div class="gmail_quote">On Tue, Feb 21, 2017 at 1:54 PM, gustavo panizzo <span dir="ltr"><<a href="mailto:gfa@zumbi.com.ar" target="_blank">gfa@zumbi.com.ar</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">Hello<br>
<br>
Can you please publish this pkg in armhf? I have a bunch of RPI3 and RPI2 deployed as small servers, running jessie/stretch, I don't think I'll ever upgrade them to arm64.<br>
The amount of RAM on the RPI3 does not justify to run arm64, I don't do math on them so I dont see the point of running a newer arch on them (all of them are remote, so reliability is important)<br></blockquote><div><br></div><div>The key advantage for me is that the upstream Linux kernel can be used, i.e. a kernel that is supported by Debian can be used. That alone justifies using arm64 for me.</div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
<br>
I know Debian's kernel doesn't support RPI3 in armhf, but maybe it will at some point. And if Debian's kernel never </blockquote><div><br></div><div>IIUC, this is unlikely because people aren’t actively working on upstreaming the armhf patches.</div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">supports armhf on the RPI3 doesn't matter, I'll build the kernel but I won't have to build the firmware :)<br></blockquote><div><br></div><div>The firmware isn’t built in Debian either: the Debian package uses the pre-built files from <a href="https://github.com/raspberrypi/firmware">https://github.com/raspberrypi/firmware</a> and adds a hook script to copy these files (plus the kernel image/dtbs/initrd and a generated config) upon kernel/firmware changes.</div><div><br></div><div>The use-case you’re describing is something which I do not want to support. The firmware (configuration at least) depends on the kernel build configuration: obviously the CPU shouldn’t be put into arm64 mode when a non-arm64 kernel is about to be booted, for example.</div><div><br></div><div>What you’re suggesting, hence, is to blow up the test/support matrix significantly: in addition to being responsible for the kernel which is included in Debian, we would also need to respond to potential problem reports of users who use a kernel outside of Debian.</div><div><br></div><div>Such a change places an undue burden on the pkg-raspi team, which is stretched very thin already.</div><div><br></div><div>All that said, as a practical workaround you can use dpkg --add-architecture arm64 && apt update && apt install raspi3-firmware. Do note that the package maintainers don’t endorse this and won’t support your use-case.</div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
<br>
<br>
Regarding the config handling, I personally don't care. I want them to be pure Debian so I can manage them as my other servers.<span class="gmail-HOEnZb"><font color="#888888"><br>
<br>
<br>
-- <br>
1AE0 322E B8F7 4717 BDEA BF1D 44BB 1BA7 9F6C 6333<br>
<br>
keybase: <a href="https://keybase.io/gfa" rel="noreferrer" target="_blank">https://keybase.io/gfa</a><br>
<br>
______________________________<wbr>_________________<br>
Pkg-raspi-maintainers mailing list<br>
<a href="mailto:Pkg-raspi-maintainers@lists.alioth.debian.org" target="_blank">Pkg-raspi-maintainers@lists.al<wbr>ioth.debian.org</a><br>
<a href="https://lists.alioth.debian.org/mailman/listinfo/pkg-raspi-maintainers" rel="noreferrer" target="_blank">https://lists.alioth.debian.or<wbr>g/mailman/listinfo/pkg-raspi-<wbr>maintainers</a><br>
</font></span></blockquote></div><br><br clear="all"><div><br></div>-- <br><div class="gmail_signature">Best regards,<br>Michael</div>
</div></div>