emerge that has RESTRICT=binchecks still performs binchecks and then warns me binchecks are disabled |
|||||||||
Issue descriptionThe emerge command I use: $ emerge-tatl fake-package-name The ">>> Install" step will take an enormous amount of time (minutes!) and spit out some warnings. This is one of them: readelf: Warning: Section '.GCC.command.line' was not dumped because it does not exist! File not built with -frecord-gcc-switches: /build/tatl/tmp/portage/<snip>/lib/libpty/linux/x86_64/libpty.so File not built with -Wl,-z,now: /build/tatl/tmp/portage/<snip>/lib/libpty/linux/x86_64/libpty.so File not built with gold: /build/tatl/tmp/portage/<snip>/lib/libpty/linux/x86_64/libpty.so And then at the end it will spit several messages like this: * QA Notice: RESTRICT=binchecks prevented checks on these ELF files: * /<snip>/lib/libpty/linux/x86_64/libpty.so To be fair to the binchecks, they aren't wrong, as these binaries are all downloaded prebuilds that are unlikely to be up to the standards of an local ebuild compile. It's annoying that I explicitly disabled these checks AND they happened anyways at great length AND emerge has the audacity to tell me that the checks were prevented. Relevant ebuild with the names changed to protect the privacy of the innocent: EAPI=5 RESTRICT="strip binchecks" DESCRIPTION="Silly Package Description" HOMEPAGE="http://example.com/fake-url" SRC_URI="fake-src-uri.zip" LICENSE="WTF" SLOT="0" KEYWORDS="*" S="${WORKDIR}/fake-package-name" RDEPEND="x11-base/xwayland app-arch/unzip media-fonts/roboto x11-libs/libXrender x11-libs/libXtst x11-libs/libXi x11-libs/libxcb sys-libs/zlib[abi_x86_32] app-arch/bzip2[abi_x86_32] sys-libs/ncurses[abi_x86_32] sys-libs/gcc-libs" src_install() { insinto /opt/fake-package-name doins -r * }
,
Mar 6 2017
the "file not built" checks are our own hooks in src/scripts/hooks/install/. they def don't currently look at RESTRICT settings. the QA notice though i think is from portage itself.
,
Mar 6 2017
That makes sense. Do you think it would be worth it to have the install hooks check for it or is that WAI?
,
Mar 10 2017
,
Mar 10 2017
the install hooks fix is in flight, and i've moved the pngfix question upstream: https://bugs.gentoo.org/612254
,
Mar 11 2017
The following revision refers to this bug: https://chromium.googlesource.com/chromiumos/platform/crosutils/+/fb0d84bed025b4e88d8056d10a8ea84e7b1dbfdf commit fb0d84bed025b4e88d8056d10a8ea84e7b1dbfdf Author: Mike Frysinger <vapier@chromium.org> Date: Sat Mar 11 03:52:33 2017 hooks: respect RESTRICT=binchecks We use this restrict knob for a few reasons, one of which is to speed up large binary installs. Update our hooks to respect it. BUG= chromium:698344 TEST=installing a pkg w/RESTRICT=binchecks no longer warns about these issues Change-Id: Ie9270bc926d3cdecf41b3812b1a440eff2235ea2 Reviewed-on: https://chromium-review.googlesource.com/450717 Commit-Ready: Mike Frysinger <vapier@chromium.org> Tested-by: Mike Frysinger <vapier@chromium.org> Reviewed-by: Zach Reizner <zachr@chromium.org> [modify] https://crrev.com/fb0d84bed025b4e88d8056d10a8ea84e7b1dbfdf/hooks/install/qa-elf.sh [modify] https://crrev.com/fb0d84bed025b4e88d8056d10a8ea84e7b1dbfdf/hooks/install/large-file-support.sh
,
Mar 11 2017
pngfix is less of an issue, so i'll close this out. we're talking about making changes in upstream portage, and we'll see about cherry picking back if it makes sense.
,
May 30 2017
,
Aug 1 2017
,
Jan 22 2018
,
Jun 21 2018
|
|||||||||
►
Sign in to add a comment |
|||||||||
Comment 1 by za...@chromium.org
, Mar 3 2017