Re: F35 Change: Memory Constraints macros for RPM (System-Wide Change proposal)

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



On 8/16/21 12:25 AM, Michel Alexandre Salim wrote:
On Thu, Aug 12, 2021 at 06:14:57PM -0700, Michel Alexandre Salim via devel wrote:
On Thu, Aug 12, 2021 at 05:23:18PM -0700, Michel Alexandre Salim via devel wrote:
On Wed, Aug 11, 2021 at 10:56:39AM +0300, Panu Matilainen wrote:
On 8/10/21 8:53 PM, Ankur Sinha wrote:
On Thu, Aug 05, 2021 09:01:14 +0200, Miroslav Suchý wrote:
Dne 05. 08. 21 v 2:42 Michel Alexandre Salim via devel napsal(a):
This is now implemented on Rawhide; Fedora updates are in testing:

Where is it documented?

I suggest one of these

https://rpm-packaging-guide.github.io/
https://docs.fedoraproject.org/en-US/packaging-guidelines/

That would be great. I was trying to put %limit_build at the top of my
spec and kept getting errors. Then I looked at the mcrouter spec and
realised this needs to go into the %build section XD

Yes, the macro is a strange as it mixes rpm macro language and shell
language, relying on some rather subtle aspects of how spec parsing and
macros work and has to be placed in a shell section. If you ask me, it's
asking for trouble.

Setting RPM_BUILD_NCPUS environment should achieve the same without
requiring the twisty %global override which looks like it may break
_smp_build_ncpus use in later sections (but I may be missing something
there)

So - I did try exporting RPM_BUILD_NCPUS earlier, and having tried it
again, could not figure out how to set that definition from within a
macro. Any idea?

openSUSE's macro overrides %_smp_mflags instead, which ... seems to work
for them, but I agree that we should rather use an environment variable instead.

Some findings:
- overriding %_smp_mflags works. But I have to use %global - %define
   does not work - and that triggers some ugly warnings at every build
- setting RPM_BUILD_NCPUS (or, similarly, %_smp_ncpus_max) does not work
   since %_smp_build_ncpus is already defined by then

%_smp_build_ncpus being defined or not is not an issue, it's evaluated on each use. The problem is the time of use: a macro is used during spec parse, whereas your macro expects to be part of the *shell* execution of %build.


Seems like the proper fix here is to either:
- try and get this macro into RPM proper, so we can have %limit_build
   declared at the top of the spec. This will likely push the change back
   to F36 at the earliest, and would make it hard to retrofit on existing
   releases, unless we want to carry out-of-tree patches.

Yes, such a thing should go upstream instead of distro-specific hacks, each different and in the end complicating doing it upstream in the end.

That said, it doesn't have to be in RPM to be usable at top of the spec, I don't know where that idea comes from. Just do the math in Lua and set %_smp_ncpus_max from there, and then expected usage is to put it at top of the spec. It shouldn't be any harder, more likely it should be far easier than what it's now doing. Doing it that way will also affect all
the parallelisation done by rpmbuild, not just %build.

   - _smp_build_ncpus also seems to be defined per platform, even though
     the definition is mostly identical, so this will be a bit messy
- change the usage, and require users who want to limit the build to do
   something like this:

   %make_build %{limit_build -m 4096} -- with %limit_build used as a
   %function that spits out the relevant -j override


Updated pull request, using the latter option:
https://src.fedoraproject.org/rpms/redhat-rpm-config/pull-request/141

The macro is now rewritten in Lua, since I can't coerce the shell
definition to just output a value. Tested locally with mock (I had to
copy fedora-34-x86_64 to fedora-35-x86_64 as the Rawhide target is
currently failing on GPG verification).

- if limit_build computes a number that is higher than %_smp_build_ncpus
   it outputs nothing
- if it computes a value that is smaller, it outputs '-j<thatvalue>'
- if it computes a value less than 1 it outputs '-j1'

Tested with mcrouter locally and setting the memory requirement to some
ridiculous value (-m 409600) I do end up with a single-core build.

Inline documentation is provided, once the PR is reviewed and this is
built for Rawhide I'll update the packaging guideline.

EEK! NAK!

That totally breaks the idea of how %make_build and friends are supposed to work. Revert this hack, NOW!

This thing needs to go back to drawing board to be discussed at leisure rather than trying to hack something up in a hurry that we will regret later.

	- Panu -


Best regards,

_______________________________________________
devel mailing list -- devel@xxxxxxxxxxxxxxxxxxxxxxx
To unsubscribe send an email to devel-leave@xxxxxxxxxxxxxxxxxxxxxxx
Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: https://lists.fedoraproject.org/archives/list/devel@xxxxxxxxxxxxxxxxxxxxxxx
Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure




[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
[Index of Archives]     [Fedora Announce]     [Fedora Users]     [Fedora Kernel]     [Fedora Testing]     [Fedora Formulas]     [Fedora PHP Devel]     [Kernel Development]     [Fedora Legacy]     [Fedora Maintainers]     [Fedora Desktop]     [PAM]     [Red Hat Development]     [Gimp]     [Yosemite News]

  Powered by Linux