Bug#1012556: nageru: no need to (wrongly) hardcode luajit architecture
Hi Steinar, Feel free to just close the bug if you think the current list expresses your intent best. Paul OpenPGP_signature Description: OpenPGP digital signature
Bug#1012556: nageru: no need to (wrongly) hardcode luajit architecture
On Thu, Jun 09, 2022 at 10:26:15AM +0200, Paul Gevers wrote: > We're in the process of add support for a second implemtentation of > luajit [1] that supposedly is properly supported on IBM architectures > (ppc64el and s390x). While I scheduled binNMU's for nageru, I noticed > it doesn't build on all architectures where luajit is available and > reading d/control suggests that the reason why your package has an > explicit architecture list is because of luajit. In general, it's > recommended to just use Architecture: any in such cases, as your > package will not build on architectecture where your build > dependencies aren't available. Yes and no. It also needs: - USB - A little-endian CPU - Working VA-API - Working OpenGL (not GLES) and especially the little-endian CPU demand is hard to express using Architecture: any. :-) You also tend to get FTBFS bugs filed pretty blindly by porters, for a software package that doesn't really make sense on such architectures. E.g. there's absolutely no way anyone would run Nageru on s390x, ever. /* Steinar */ -- Homepage: https://www.sesse.net/
Bug#1012556: nageru: no need to (wrongly) hardcode luajit architecture
Source: nageru Version: 2.1.0-2 Severity: normal Hi, We're in the process of add support for a second implemtentation of luajit [1] that supposedly is properly supported on IBM architectures (ppc64el and s390x). While I scheduled binNMU's for nageru, I noticed it doesn't build on all architectures where luajit is available and reading d/control suggests that the reason why your package has an explicit architecture list is because of luajit. In general, it's recommended to just use Architecture: any in such cases, as your package will not build on architectecture where your build dependencies aren't available. The advantage is that once somebody makes new architectures available, your package can be supportered there without further changes. Paul [1] https://bugs.debian.org/1012362
