• [gentoo-dev] [PATCH 1/4] autotools.eclass: don't inject -I${SYSROOT} to

    From Sam James@21:1/5 to All on Mon Jan 17 12:40:03 2022
    When -I${SYSROOT} is injected, it'll override the default of -Im4, which results in trying to install macros to ${SYSROOT} (a sandbox violation)
    when they can't be found.

    From aclocal(1):
    ```
    -I DIR add directory to search list for .m4 files

    --install
    copy third-party files to the first -I directory
    ```

    The first directry is normally -Im4 if anything, whereas when injected
    (when ${SYSROOT} is defined), it ends up being ${SYSROOT}, not m4 (so
    we try to copy macros to somewhere outside of the build directory).

    In EAPI 7+, this is almost always the case! We don't generally expect
    to find macros (particularly things like autoconf-archive) in ${SYSROOT} because that's for DEPEND-class dependencies, then they end up being
    copied in unnecessarily and wrongly.

    We could drop this just for < EAPI 7, but I'm not sure there's much
    point there either. As Chewi observed in bug 677002, you can't
    assume they'll be present in ${SYSROOT} anyway, and frankly,
    the cross-compilation (and --root, --sysroot, and so on) situation
    is rather bleak for earlier EAPIs, which is why we did all that
    work for 7.

    Bug: https://bugs.gentoo.org/710792
    Closes: https://bugs.gentoo.org/677002
    Closes: https://bugs.gentoo.org/738918
    Thanks-to: James Le Cuirot <chewi@gentoo.org>
    Signed-off-by: Sam James <sam@gentoo.org>
    ---
    eclass/autotools.eclass | 8 +-------
    1 file changed, 1 insertion(+), 7 deletions(-)

    diff --git a/eclass/autotools.eclass b/eclass/autotools.eclass
    index 95c92cc6df8ca..e2572290f0cbe 100644
    --- a/eclass/autotools.eclass
    +++ b/eclass/autotools.eclass
    @@ -1,4 +1,4 @@
    -# Copyright 1999-2021 Gentoo Authors
    +# Copyright 1999-2022 Gentoo Authors
    # Distributed under the terms of the GNU General Public License v2

    # @ECLASS: autotools.eclass
    @@ -666,12 +666,6 @@ autotools_m4sysdir_include() {
    # First try to use the paths the system integrator has set up.
    local paths=( $(eval echo ${AT_SYS_M4DIR}) )

    - if [[ ${#paths[@]} -eq 0 && -n ${SYSROOT} ]] ; then
    - # If they didn't give us anything, then default to the SYSROOT. - # This helps when cross-compiling.
    - local path="${SYSROOT}/usr/share/aclocal"
    - [[ -d ${path} ]] && paths+=( "${path}" )
    - fi
    _autotools_m4dir_include "${paths[@]}"
    }

    --
    2.34.1

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Sam James@21:1/5 to All on Mon Jan 17 12:40:03 2022
    Signed-off-by: Sam James <sam@gentoo.org>
    ---
    eclass/autotools.eclass | 2 +-
    1 file changed, 1 insertion(+), 1 deletion(-)

    diff --git a/eclass/autotools.eclass b/eclass/autotools.eclass
    index 2cf7c076d01ed..5250b28042ee2 100644
    --- a/eclass/autotools.eclass
    +++ b/eclass/autotools.eclass
    @@ -74,7 +74,7 @@ inherit gnuconfig libtool
    # Do NOT change this variable in your ebuilds!
    # If you want to force a newer minor version, you can specify the correct
    # WANT value by using a colon: <PV>:<WANT_AUTOMAKE>
    -_LATEST_AUTOMAKE=( 1.16.2-r1:1.16 )
    +_LATEST_AUTOMAKE=( 1.16.4:1.16 )

    _automake_atom="sys-devel/automake"
    _autoconf_atom="sys-devel/autoconf"
    --
    2.34.1

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Mike Frysinger@21:1/5 to Sam James on Wed Jan 19 07:40:01 2022
    On 17 Jan 2022 11:09, Sam James wrote:
    When -I${SYSROOT} is injected, it'll override the default of -Im4, which results in trying to install macros to ${SYSROOT} (a sandbox violation)
    when they can't be found.

    From aclocal(1):
    ```
    -I DIR add directory to search list for .m4 files

    --install
    copy third-party files to the first -I directory
    ```

    The first directry is normally -Im4 if anything, whereas when injected
    (when ${SYSROOT} is defined), it ends up being ${SYSROOT}, not m4 (so
    we try to copy macros to somewhere outside of the build directory).

    we should define the semantics we want and bring it upstream to get into automake. although it seems like ACLOCAL_PATH might work well enough
    for us now to switch to that.

    as a stop gap, it seems like the use of --install is pretty low ? we're cross-compiling about ~2.5k packages in CrOS every day and never seen a
    failure here. so the few packages which are running into troubles can workaround it by setting AT_SYS_M4DIR right ?

    In EAPI 7+, this is almost always the case! We don't generally expect
    to find macros (particularly things like autoconf-archive) in ${SYSROOT} because that's for DEPEND-class dependencies, then they end up being
    copied in unnecessarily and wrongly.

    i think this optimism is misplaced. libraries often install m4 files
    which is precisely why this logic is in here. https://bugs.gentoo.org/677002#c10

    deleting this check will break things. prob more than we're fixing.
    -mike

    -----BEGIN PGP SIGNATURE-----

    iQIzBAABCAAdFiEEuQK1JxMl+JKsJRrUQWM7n+g39YEFAmHnsS8ACgkQQWM7n+g3 9YEbTxAA0QIj1tp9l+pjjyF8CVv6vJqZJKMoeP0kxQOSvmBF1rmNnv3c/F4ema/L tqwY+vFLHzH8W18rlweG+cDWPHb5NQR8JcsayfTbeWf67YiVOBXuA7GuqTwpgOl9 rFeV8ONyCsHEyYGYSQLzcdkKWIreEjAYRkmUNFX0jpcj2lpcGSClv57zdM0N4g6Q kTi4pD3pihOKBucsnxEnF3tIpo/Oq3jzFInjhXq7AyLTJW5i7eN7opACq/Dh69Zu RBcSOy+UsnsAmwa2VA2VqnVqdT/GtzimheWhvHkhrTTA1HGHgvStitN3Ti4+sewe rEglDeWwhNMvN2PDThComSB8cBFfVIwXH5GmJjoeDslqGsI0zOk8Mm0y1dyIAnSk mOza5kQ7R2MsgMw76X3yD9kTTm6w/ouwV2jhYP5Ni5IPaYZGyhMkHrp9ZRIupgaB MPJ9vqbsomVA4MEpGnnqsvQZP8u+9lDuO5E1CCHpPl2gxJcxnvkKZKxNJqTkTk39 FH0doVWx4jTlezY23J06kwaUork77kpvWvbtXWNF6nBbC7h9ckC3n3wSLrGxfA0Z HtqAknREFYKRG2+ebcujgmJm3tgl4uj30Z+CRV4mqOU8/kCRNQxxzjvo3t4oPZZz xHutyWw1xmDQGzTcDc+0LLkBiHJ+rZEsaG3dwgjUEYB0Jys9CNQ=
    =WQpJ
    -----END PGP SIGNATURE-----

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Sam James@21:1/5 to All on Thu Jan 20 07:00:01 2022
    --Apple-Mail=_2DE5B281-25AF-482E-8986-ADF0F8E07ABD
    Content-Transfer-Encoding: quoted-printable
    Content-Type: text/plain;
    charset=us-ascii



    On 19 Jan 2022, at 06:35, Mike Frysinger <vapier@gentoo.org> wrote:

    On 17 Jan 2022 11:09, Sam James wrote:
    When -I${SYSROOT} is injected, it'll override the default of -Im4, which
    results in trying to install macros to ${SYSROOT} (a sandbox violation)
    when they can't be found.

    From aclocal(1):
    ```
    -I DIR add directory to search list for .m4 files

    --install
    copy third-party files to the first -I directory
    ```

    The first directry is normally -Im4 if anything, whereas when injected
    (when ${SYSROOT} is defined), it ends up being ${SYSROOT}, not m4 (so
    we try to copy macros to somewhere outside of the build directory).

    we should define the semantics we want and bring it upstream to get into automake. although it seems like ACLOCAL_PATH might work well enough
    for us now to switch to that.

    as a stop gap, it seems like the use of --install is pretty low ? we're cross-compiling about ~2.5k packages in CrOS every day and never seen a failure here. so the few packages which are running into troubles can workaround it by setting AT_SYS_M4DIR right ?

    I've only seen it in the wild with:
    - app-crypt/tpm2-tss (https://bugs.gentoo.org/756211 <https://bugs.gentoo.org/756211>)
    - another package which I hit during "normal" use but I'm afraid I can't
    recall what. I suspect I hit it before Python grew a BDEPEND on autoconf-archive
    so we're less likely to hit it now.

    But I accept it's niche. See below though, I think we agree that AT_SYS_M4DIR / system acdir should be satisfactory here.

    I don't mind keeping the old logic for < EAPI 7 if that'll help you in CrOS though.


    In EAPI 7+, this is almost always the case! We don't generally expect
    to find macros (particularly things like autoconf-archive) in ${SYSROOT}
    because that's for DEPEND-class dependencies, then they end up being
    copied in unnecessarily and wrongly.

    i think this optimism is misplaced. libraries often install m4 files
    which is precisely why this logic is in here. https://bugs.gentoo.org/677002#c10 <https://bugs.gentoo.org/677002#c10>

    deleting this check will break things. prob more than we're fixing.

    Sorry, you're absolutely right here!

    But I think it's addressed by the system-acdir commit that follows it up.

    i.e. the commit message is totally wrong (and I'll fix this), but the change is correct
    given we follow it up with seemingly a better way of handling
    the original case.

    Does that sound right?

    Best,
    sam


    --Apple-Mail=_2DE5B281-25AF-482E-8986-ADF0F8E07ABD
    Content-Transfer-Encoding: quoted-printable
    Content-Type: text/html;
    charset=us-ascii

    <html><head><meta http-equiv="Content-Type" content="text/html; charset=us-ascii"></head><body style="word-wrap: break-word; -webkit-nbsp-mode: space; line-break: after-white-space;" class=""><br class=""><div><br class=""><blockquote type="cite" class=""
    <div class="">On 19 Jan 2022, at 06:35, Mike Frysinger &lt;<a href="mailto:vapier@gentoo.org" class="">vapier@gentoo.org</a>&gt; wrote:</div><br class="Apple-interchange-newline"><div class=""><meta charset="UTF-8" class=""><div class="content-isolator__
    container" style="caret-color: rgb(0, 0, 0); font-family: Helvetica; font-size: 12px; font-style: normal; font-variant-caps: normal; font-weight: normal; letter-spacing: normal; text-align: start; text-indent: 0px; text-transform: none; white-space:
    normal; word-spacing: 0px; -webkit-text-stroke-width: 0px; text-decoration: none;">On 17 Jan 2022 11:09, Sam James wrote:<br class=""><blockquote type="cite" class="">When -I${SYSROOT} is injected, it'll override the default of -Im4, which<br class="">
    results in trying to install macros to ${SYSROOT} (a sandbox violation)<br class="">when they can't be found.<br class=""><br class="">From aclocal(1):<br class="">```<br class="">&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;-I DIR add directory to search list
    for .m4 files<br class=""><br class="">&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;--install<br class="">&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;copy third-party files to the first -I directory<br class="">```<br class=""><
    br class="">The first directry is normally -Im4 if anything, whereas when injected<br class="">(when ${SYSROOT} is defined), it ends up being ${SYSROOT}, not m4 (so<br class="">we try to copy macros to somewhere outside of the build directory).<br class="
    "></blockquote><br class="">we should define the semantics we want and bring it upstream to get into<br class="">automake. &nbsp;although it seems like ACLOCAL_PATH might work well enough<br class="">for us now to switch to that.<br class=""><br class="">
    as a stop gap, it seems like the use of --install is pretty low ? &nbsp;we're<br class="">cross-compiling about ~2.5k packages in CrOS every day and never seen a<br class="">failure here. &nbsp;so the few packages which are running into troubles can<br
    class="">workaround it by setting AT_SYS_M4DIR right ?<br class=""></div></div></blockquote><div><br class=""></div><div>I've only seen it in the wild with:</div><div>- app-crypt/tpm2-tss (<a href="https://bugs.gentoo.org/756211" class="">https://bugs.
    gentoo.org/756211</a>)</div><div>- another package which I hit during "normal" use but I'm afraid I can't</div><div>recall what. I suspect I hit it before Python grew a BDEPEND on autoconf-archive</div><div>so we're less likely to hit it now.</div><div><
    br class=""></div><div>But I accept it's niche. See below though, I think we agree that AT_SYS_M4DIR /</div><div>system acdir should be satisfactory here.</div><div><br class=""></div><div>I don't mind keeping the old logic for &lt; EAPI 7 if that'll
    help you in CrOS though.</div><br class=""><blockquote type="cite" class=""><div class=""><div class="content-isolator__container" style="caret-color: rgb(0, 0, 0); font-family: Helvetica; font-size: 12px; font-style: normal; font-variant-caps: normal;
    font-weight: normal; letter-spacing: normal; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; word-spacing: 0px; -webkit-text-stroke-width: 0px; text-decoration: none;"><br class=""><blockquote type="cite" class="">In EAPI
    7+, this is almost always the case! We don't generally expect<br class="">to find macros (particularly things like autoconf-archive) in ${SYSROOT}<br class="">because that's for DEPEND-class dependencies, then they end up being<br class="">copied in
    unnecessarily and wrongly.<br class=""></blockquote><br class="">i think this optimism is misplaced. &nbsp;libraries often install m4 files<br class="">which is precisely why this logic is in here.<br class=""><a href="https://bugs.gentoo.org/677002#c10"
    class="">https://bugs.gentoo.org/677002#c10</a><br class=""><br class="">deleting this check will break things. &nbsp;prob more than we're fixing.<br class=""></div></div></blockquote><div><br class=""></div><div>Sorry, you're absolutely right here!</div>
    <div><br class=""></div><div>But I think it's addressed by the system-acdir commit that follows it up.</div><div><br class=""></div><div>i.e. the commit message is totally wrong (and I'll fix this), but the change is correct</div><div>given we follow it
    up with seemingly a better way of handling</div><div>the original case.</div><div><br class=""></div><div>Does that sound right?</div><br class=""></div><div>Best,</div><div>sam</div><br class=""></body></html>
    --Apple-Mail=_2DE5B281-25AF-482E-8986-ADF0F8E07ABD--

    -----BEGIN PGP SIGNATURE-----

    iQGTBAEBCgB9FiEEYOpPv/uDUzOcqtTy9JIoEO6gSDsFAmHo+g5fFIAAAAAALgAo aXNzdWVyLWZwckBub3RhdGlvbnMub3BlbnBncC5maWZ0aGhvcnNlbWFuLm5ldDYw RUE0RkJGRkI4MzUzMzM5Q0FBRDRGMkY0OTIyODEwRUVBMDQ4M0IACgkQ9JIoEO6g SDuHGggAgwspxY09IzcOTNOiOkaQX60HLwW5/4iSXSAUb2cVYjKqDMQeTGu2yugS wLqeRn9wMSIKWwvKP1+C3FMyDe/OPxa4pucftAMZgjgM6av7otLbsNRoAU6O6i36 irJkUkOsyUqqx+dsPWKoVqAey5surALuc62JWdf3TBY6/Y1YK7qWowDVdbJtdOS4 T0nTbIRNwD4CHpVMAXapOvd/EP80+xjuFJUEIqQvmTv52oe2gKRsC54MFXHCP+aX g12VmE4UulFZiBgDrZpUyQ6Qg/76LqajPrU+0z228/X+VfDw3GDZMhg/LvKtHevw Hp0yVYGhKTz4kbesjbPDj5k0SLzkXQ==
    =Plum
    -----END PGP SIGNATURE-----

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)