How to stop EBUILD performing premerge checks [SOLVED]

[mounty1]

It's well known that you can use I_KNOW_WHAT_I_AM_DOING=1 to stop emerge from performing checks.

emerge is a front-end for ebuild.

How do you prevent ebuild whateverthepackage.ebuild compile from performing the checks? I_KNOW_WHAT_I_AM_DOING=1 doesn't do it. I.e., how does emerge invoke ebuild when the env. var be set?

I need this because on one machine, emerge chromium just dies for some reason and the workaround is repeatedly to run ebuild chromium-version.ebuild compile. Yes I know it would be nice to find out why but I just don't have time or interest in fixing crappy little build problems.

The check is failing because /var/tmp/portage is a 32 GiB file system, chromium is taking 16 GiB so the check for 19 GiB free space is failing. I tried mounting an empty file system at /var/tmp/portage/www-client/chromium-blah/temp/2 (so that in fact there is 19 GiB free under .../temp) but the test was written by Microsoft and fails anyway, no doubt by trying to be too clever and failing.

So to repeat the question: how do you prevent ebuild whateverthepackage.ebuild compile from performing the checks?

[CaptainBlood]

The check is failing because /var/tmp/portage is a 32 GiB file system, chromium is taking 16 GiB so the check for 19 GiB free space is failing. I tried mounting an empty file system at /var/tmp/portage/www-client/chromium-blah/temp/2 (so that in fact there is 19 GiB free under .../temp) but the test was written by Microsoft and fails anyway, no doubt by trying to be too clever and failing.

This sounds confusing here... I may be mistaken

Thks 4 ur attention, interest & support.

[Genone]

Space checks are performed by the check-reqs eclass. Skimming over that, looks like you can set CHECKREQS_DONOTHING to any value which will then bypass the die() call (the check is still performed and you'll get the message, but execution will continue).

Also I_KNOW_WHAT_I_AM_DOING is not a real thing, there are zero references to it in portage itself (some ebuilds or scripts might reference it, but that's just random then).

[wjb]

You can use package.env to tweak builds for individual packages, Gentoo Wiki: /etc/portage/package.env

So you could change MAKEOPTS to use less cores for chromium, which should reduce the RAM requirements - hopefully to something that will pass the check.

Or modify an ebuild function.

[logrusx]

You can use package.env to tweak builds for individual packages, Gentoo Wiki: /etc/portage/package.env

So you could change MAKEOPTS to use less cores for chromium, which should reduce the RAM requirements - hopefully to something that will pass the check.

Or modify an ebuild function.

That's not what OP asked for. There's a difference between disk space and memory requirements. When you want to resume an ebuild, although the sources are unpacked, the pre-merge check is still executed and it fails, although no more additional disk space is required. /Actually the ebuild has no way of knowing that in advance/

@CaptainBlood, does that clear the quoted statement you find confusing?

Space checks are performed by the check-reqs eclass. Skimming over that, looks like you can set CHECKREQS_DONOTHING to any value which will then bypass the die() call (the check is still performed and you'll get the message, but execution will continue).

Also I_KNOW_WHAT_I_AM_DOING is not a real thing, there are zero references to it in portage itself (some ebuilds or scripts might reference it, but that's just random then).

I wish I knew that a few years back. It might have saved a lot of unnecessary compile hours for my old and tired setup back then.

Best Regards,
Georgi

[CaptainBlood]

Code: Select all

/var/tmp/portage is a 32 GiB file system, chromium is taking 16 GiB

What does chromium has to do with /var/tmp/portage?
noob here, never used chromium in gentoo...

Code: Select all

test was written by Microsoft

even more confusing to me

Thks 4 ur attention, interest & support.

[Hu]

www-client/chromium is a Gentoo Portage package which, like all Portage packages, will be built in a directory under PORTAGE_TMPDIR, which defaults to /var/tmp/portage. OP's problem then is that the artifacts from the first failed build consume disk space and make the build area look "too small" because the check assumes that the ebuild is not yet using any space, and that unpacking and building will consume space. In OP's case, unpacking has been done and will not be repeated, so the space consumed by source files does not need to be consumed again. Some amount of compilation has been done before the failure, so some build artifacts exist and consume space, and will not be duplicated by resuming the build.

That comment about the test by Microsoft seems wrong to me. OP seems to be asking about a Gentoo Portage safety check, not something from the upstream project.

For some purposes, which may or may not include the one about which the OP is asking, Portage restores the environment from the initial build when processing the resumption. This may (note: I have not checked this!) mean that the override environment variable needs to be set in the first call to emerge, so that it is present in the restored environment that the later manual ebuild sets up. If I am right, which I may not be, setting the override variable only on the attempted ebuild resumption will not propagate into the eclass, and therefore will have no effect.

[mounty1]

... Portage restores the environment from the initial build when processing the resumption.

Thank you. This is the key.

In /var/tmp/portage/www-client/chromium-blahversion/temp/environment, add

Code: Select all

declare CHECKREQS_DONOTHING="1"

and the ebuild proceeds.

[mounty1]

That comment about the test by Microsoft seems wrong to me. OP seems to be asking about a Gentoo Portage safety check, not something from the upstream project..

It was a flippant remark referencing Microsoft's predilection for building 'smarts' into their 'products' which cause more problems than they solve.

[logrusx]

Judging by the following:

... Portage restores the environment from the initial build when processing the resumption.

Thank you. This is the key.

In /var/tmp/portage/www-client/chromium-blahversion/temp/environment, add

Code: Select all

declare CHECKREQS_DONOTHING="1"

and the ebuild proceeds.

I think a clarification about the following is needed:

Space checks are performed by the check-reqs eclass. Skimming over that, looks like you can set CHECKREQS_DONOTHING to any value which will then bypass the die() call (the check is still performed and you'll get the message, but execution will continue).

You don't need to modify anything in PORTAGE_TEMPDIR.

You can define variables at the command line and they'll take precedence over the ones defined in files. What you needed to do was:

Code: Select all

CHECKREQS_DONOTHING="1" FEATURES="keepwork" emerge chromium

CHECKREQS_DONOTHING will cause portage to skip chicks and FEATURES="keepwork" will prevent portage from cleaning up PORTAGE_TEMDIR. The second part is necessary to avoid modifying make.conf or per-package configuration in /etc/portage.

Best Regards,
Georgi

[CaptainBlood]

How do you prevent ebuild whateverthepackage.ebuild compile from performing the checks?

I overlooked that,
which is a workaround to not restart the emerge from scratch; that make sense with lasting ebuilds.

I gave up trying to do this, because of mitigated results, e.g. lasting failed re-builds.
I currently favor to restart from scratch.

This post may help to reconsider my position.

Thks 4 ur attention, interest & support.