control: close -1Thanks Thanks for pinging about this old and not anymore an issue bug. Closing is indeed the right thing to do. BR Gianfranco
Yahoo Mail: Search, Organize, Conquer On Wed, Jan 8, 2025 at 1:12, Santiago Vila<sanv...@debian.org> wrote: tags 965214 + moreinfo tags 965215 + moreinfo thanks Hello Gianfranco. This proposal you made four years ago seems a little bit vague/imprecise to me. How much memory is too small? How many CPUs are too many for a given amount of memory? Let me tell you what I do to avoid this in my completely amateur autobuilder setup: During build, I monitor Committed_AS in /proc/meminfo and store the maximum value for each package. Since I use machines with different memory sizes, I know which ones will be able to build a given package and which ones might not, and I never ask a machine to build a package if I'm not sure that it will be able to build that particular package. I have been doing that for a long time, and it would be hard to believe that Canonical does not have the resources to do that, and instead has to ask Debian maintainers to adjust a lot of packages to accommodate for that. For the particular case of dune-grid and dune-common, I can tell that among the 37000 packages currently in trixie, there are at least 500 packages that need more memory than those two. If we had to change those two packages using some threshold, we would probably have to change another 500 packages as well, to be consistent. So: Would you mind if we close these two bugs and instead try to see what could be done from the dpkg/debhelper side? There is a very interesting thread started by Helmut Grohne here which tries to do exactly that: https://lists.debian.org/debian-dpkg/2024/11/msg00015.html The target for that is between 10 and 50 packages. Supposedly, the top 10 to 50 packages as far as memory consumption is concerned. Thanks.
