control: close -1<div>Thanks<br><div><br></div><div>Thanks for pinging about this old and not anymore an issue bug.</div><div><br></div><div>Closing is indeed the right thing to do.</div><div><br></div><div>BR</div><div><br></div><div>Gianfranco<br><br><div id="ymail_android_signature"><a id="ymail_android_signature_link" href="https://mail.onelink.me/107872968?pid=nativeplacement&c=US_Acquisition_YMktg_315_SearchOrgConquer_EmailSignature&af_sub1=Acquisition&af_sub2=US_YMktg&af_sub3=&af_sub4=100002039&af_sub5=C01_Email_Static_&af_ios_store_cpp=0c38e4b0-a27e-40f9-a211-f4e2de32ab91&af_android_url=https://play.google.com/store/apps/details?id=com.yahoo.mobile.client.android.mail&listing=search_organize_conquer">Yahoo Mail: Search, Organize, Conquer</a></div> <br> <blockquote style="margin: 0 0 20px 0;"> <div style="font-family:Roboto, sans-serif; color:#6D00F6;"> <div>On Wed, Jan 8, 2025 at 1:12, Santiago Vila</div><div><sanvila@debian.org> wrote:</div> </div> <div style="padding: 10px 0 0 20px; margin: 10px 0 0 0; border-left: 1px solid #6D00F6;"> <div dir="ltr">tags 965214 + moreinfo<br></div><div dir="ltr">tags 965215 + moreinfo<br></div><div dir="ltr">thanks<br></div><div dir="ltr"><br></div><div dir="ltr">Hello Gianfranco.<br></div><div dir="ltr"><br></div><div dir="ltr">This proposal you made four years ago seems a little bit<br></div><div dir="ltr">vague/imprecise to me. How much memory is too small?<br></div><div dir="ltr">How many CPUs are too many for a given amount of memory?<br></div><div dir="ltr"><br></div><div dir="ltr">Let me tell you what I do to avoid this in my completely<br></div><div dir="ltr">amateur autobuilder setup:<br></div><div dir="ltr"><br></div><div dir="ltr">During build, I monitor Committed_AS in /proc/meminfo and store<br></div><div dir="ltr">the maximum value for each package.<br></div><div dir="ltr"><br></div><div dir="ltr">Since I use machines with different memory sizes, I know<br></div><div dir="ltr">which ones will be able to build a given package and which ones<br></div><div dir="ltr">might not, and I never ask a machine to build a package if<br></div><div dir="ltr">I'm not sure that it will be able to build that particular package.<br></div><div dir="ltr"><br></div><div dir="ltr">I have been doing that for a long time, and it would be hard to<br></div><div dir="ltr">believe that Canonical does not have the resources to do that,<br></div><div dir="ltr">and instead has to ask Debian maintainers to adjust a lot of packages<br></div><div dir="ltr">to accommodate for that.<br></div><div dir="ltr"><br></div><div dir="ltr">For the particular case of dune-grid and dune-common, I can tell<br></div><div dir="ltr">that among the 37000 packages currently in trixie, there are<br></div><div dir="ltr">at least 500 packages that need more memory than those two.<br></div><div dir="ltr"><br></div><div dir="ltr">If we had to change those two packages using some threshold,<br></div><div dir="ltr">we would probably have to change another 500 packages as well,<br></div><div dir="ltr">to be consistent.<br></div><div dir="ltr"><br></div><div dir="ltr"><br></div><div dir="ltr">So: Would you mind if we close these two bugs and instead try<br></div><div dir="ltr">to see what could be done from the dpkg/debhelper side?<br></div><div dir="ltr"><br></div><div dir="ltr">There is a very interesting thread started by Helmut Grohne<br></div><div dir="ltr">here which tries to do exactly that:<br></div><div dir="ltr"><br></div><div dir="ltr"><a href="https://lists.debian.org/debian-dpkg/2024/11/msg00015.html" target="_blank">https://lists.debian.org/debian-dpkg/2024/11/msg00015.html</a><br></div><div dir="ltr"><br></div><div dir="ltr">The target for that is between 10 and 50 packages. Supposedly,<br></div><div dir="ltr">the top 10 to 50 packages as far as memory consumption is concerned.<br></div><div dir="ltr"><br></div><div dir="ltr">Thanks.<br></div> </div> </blockquote></div></div>