❦ 21 février 2017 09:48 -0800, Nikolaus Rath <nikol...@rath.org> :
>> Your chosen build environment is not common [...]
>
> This has come up a few times now. Could someone explain what is so odd
> about his envirnoment? It does not look unusual to me.
Official buildd have several CPU. Most "important" downstream
distribution builders have several CPU. Your own personal
laptop/workstation have several CPU. Free CI environments usually have
several CPU (eg. Travis CI). Private CI usually have several CPU
(eg. jenkins.debian.net, debomatic).
Just checked with Ubuntu, ri-li builds successfully and reliably on
their platform. Moreover, I don't think we ever had downstream
distributions complained about the inability to compile packages. From
my point of view, we are told to fix bugs that don't affect our users.
Accomodating for all build environments is a slippery slope. What if I
use a 128MB host with 64GB of swap? Timing-related tests will start to
fail. Is it Debian job to fix all the test suites? Should I be able to
build packages on a system not supporting ACL? On a kernel not
supporting users? On a grsec kernel? With a low ulimit value for the
number of opened files or on the stack size? On a chroot on an Android
phone? On the Windows Subsystem for Linux?
--
Use variable names that mean something.
- The Elements of Programming Style (Kernighan & Plauger)
signature.asc
Description: PGP signature
