From nobody Sat Aug 12 00:11:54 2023 X-Original-To: freebsd-current@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id 4RN1Lh3mLwz4pxtV for ; Sat, 12 Aug 2023 00:12:12 +0000 (UTC) (envelope-from kob6558@gmail.com) Received: from mail-yb1-xb29.google.com (mail-yb1-xb29.google.com [IPv6:2607:f8b0:4864:20::b29]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256 client-signature RSA-PSS (2048 bits) client-digest SHA256) (Client CN "smtp.gmail.com", Issuer "GTS CA 1D4" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4RN1Lh1jSJz4MvK; Sat, 12 Aug 2023 00:12:12 +0000 (UTC) (envelope-from kob6558@gmail.com) Authentication-Results: mx1.freebsd.org; none Received: by mail-yb1-xb29.google.com with SMTP id 3f1490d57ef6-d656d5e8265so1774615276.1; Fri, 11 Aug 2023 17:12:12 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20221208; t=1691799131; x=1692403931; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:from:to:cc:subject:date:message-id:reply-to; bh=jyzNjgonHLRQeBEaPcFvdCYeJjaj+3okbdtgzZG+zfM=; b=GIF7LDJn+c1NdYfix2LILQUNNyzVQJgjUS6M4JUmjILoYki6kUOq6iUnaT6tgq5K/5 9wTCxNQFOWYgcpzW1pGO3U60C1bTNwQP19m7Cw7rhqDdcZmQ/59Sxo7sbVwesc40CQ8I WrQ7Xz1wTK3Sce55SXUZ8naWyXVxlx8GxqPLhG2nfwEUGpSinJSgejKK1unGaxv/xPuu WYChOz0DnlA8x8ih1/NKQbt4/azesW0C68JjQ0UkiSR3kB4gkoxET8AdisHvf7Jyg/7H 73AdObkj5bi7aANYWbiaIrSRwwYbwvKuyUtSe1xdsscb+a6aWvCJ5vxI1n4PvBKC2c4e GydQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20221208; t=1691799131; x=1692403931; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:x-gm-message-state:from:to:cc:subject:date:message-id :reply-to; bh=jyzNjgonHLRQeBEaPcFvdCYeJjaj+3okbdtgzZG+zfM=; b=jGxum/kjlKlGiqDshtEzUDGl1zuDIoJZFcGmK+baLtfEk1PO661AFZm2cOXLN5GWgi R3WaCDNTcQRZvBjZgIfg8lyzrolhWQaxidymh+IWor0kqOLQSwWZqnYZ7ll7bX3S5Xz/ ZR19aYUP+hcuvtc90o6fnWuuouJYQEGNpteltHq50O8iC7jM40tpZFN3X6HE7YONENHk IvGhaac0hGD5hy9WYPu1xPlXo6hM3+grmd+e1+n9Br0NJ0b2kErOTRRPhl0fS6YcNPeG +gQ/EQVrZtnbfXnXY+qJJdURJzOF91P0ZOpyO1Vxnd858iEdKCwFuxpoNzMLAdSQ2Ziq qcuw== X-Gm-Message-State: AOJu0Yx6zyU45H2EqlHZI0vecSayWX1PCCWfGbIOhLWUOsWPZBcZgH9F WC1nQB4vVoLqLrX5vv+1s2G2wW0AdHxwbvyXC3AUqWpP X-Google-Smtp-Source: AGHT+IG6zY6e2wu86lsByhbj9s3IlVWgYybSlu3+ImfVZZU+z0t9y9ZC2DEKeSuhX8d21Cx8AT0JXSgsL3dVTCFvqC0= X-Received: by 2002:a25:4251:0:b0:cfe:9981:2af3 with SMTP id p78-20020a254251000000b00cfe99812af3mr3222810yba.20.1691799130972; Fri, 11 Aug 2023 17:12:10 -0700 (PDT) List-Id: Discussions about the use of FreeBSD-current List-Archive: https://lists.freebsd.org/archives/freebsd-current List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-current@freebsd.org MIME-Version: 1.0 References: In-Reply-To: From: Kevin Oberman Date: Fri, 11 Aug 2023 17:11:54 -0700 Message-ID: Subject: Re: problem with poudriere && port ftp/curl To: Jan Beich Cc: freebsd-current@freebsd.org Content-Type: multipart/alternative; boundary="0000000000003ba9050602aeaeec" X-Rspamd-Queue-Id: 4RN1Lh1jSJz4MvK X-Spamd-Bar: ---- X-Rspamd-Pre-Result: action=no action; module=replies; Message is reply to one we originated X-Spamd-Result: default: False [-4.00 / 15.00]; REPLY(-4.00)[]; ASN(0.00)[asn:15169, ipnet:2607:f8b0::/32, country:US] --0000000000003ba9050602aeaeec Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable On Fri, Aug 11, 2023 at 3:00=E2=80=AFPM Jan Beich wrot= e: > Matthias Apitz writes: > > > I have the following problem with poudriere on 14-CURRENT and ports fro= m > > git head: every time when I start poudriere-bulk it removes a port > > already compile fine (and all its dependent ports) with the message: > > > > ... > > > The difference seems to be +/-GSSAPI_BASE and +/-GSSAPI_NONE. > > I have not set anything about > > this in the port's options or jail's make.conf. > > > > What can I do to fix this? > > Maybe poudriere is confused by GSSAPI_${${SSL_DEFAULT} =3D=3D base :?BASE > :NONE} > in OPTIONS_DEFAULT due ssl!=3Dbase in DEFAULT_VERSIONS via make.conf(5). > Try filing a bug against ftp/curl. > > $ env -i __MAKE_CONF=3D PORT_DBDIR=3D/var/empty make -V > '${OPTIONS_DEFAULT:M*GSS*}' > GSSAPI_BASE > $ env -i __MAKE_CONF=3D PORT_DBDIR=3D/var/empty DEFAULT_VERSIONS=3Dssl=3D= openssl > make -V '${OPTIONS_DEFAULT:M*GSS*}' > GSSAPI_NONE > > See also > https://cgit.freebsd.org/ports/diff/ftp/curl/Makefile?id=3D6d324c1f70c9 > > I can't reproduce on -CURRENT when only using base OpenSSL 3.0. > There are several ports with this problem. Since VirtualBox (and libvncserver) need openssl31, I now delete openssl31, upgrade ports as required, and then "package add /usr/ports/packages/All/openssl31-3.1.2.pkg" when finished. Just today I hit openldap-client trying to use openssl31 even though make.conf does not define it as default. Several other ports also don't honor the fairly new USES=3Dopenssl and, if they find an openssl installed, will use it. Since Aug. 1, I have had several other ports hit this issue. You really, really don't want ports using openssl31 unless you are sure that they or any port which they depend on are also using openssl31. If you get shareable libraries with conflicts, it is a pain to clean them up. Maybe a message to all committers that they need to be sure that OPENSSLBASE is not used without USES=3Dopenssl. (At least I believe that is the case.) --=20 Kevin Oberman, Part time kid herder and retired Network Engineer E-mail: rkoberman@gmail.com PGP Fingerprint: D03FB98AFA78E3B78C1694B318AB39EF1B055683 --0000000000003ba9050602aeaeec Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
On Fri, Aug 11, 2023 at 3:00=E2= =80=AFPM Jan Beich <jbeich@freebsd= .org> wrote:
Matthias Apitz <guru@unixarea.de> writes:

> I have the following problem with poudriere on 14-CURRENT and ports fr= om
> git head: every time when I start poudriere-bulk it removes a port
> already compile fine (and all its dependent ports) with the message: >
> ...

> The difference seems to be +/-GSSAPI_BASE and +/-GSSAPI_NONE.
> I have not set anything about
> this in the port's options or jail's make.conf.
>
> What can I do to fix this?

Maybe poudriere is confused by GSSAPI_${${SSL_DEFAULT} =3D=3D base :?BASE := NONE}
in OPTIONS_DEFAULT due ssl!=3Dbase in DEFAULT_VERSIONS via make.conf(5). Try filing a bug against ftp/curl.

$ env -i __MAKE_CONF=3D PORT_DBDIR=3D/var/empty make -V '${OPTIONS_DEFA= ULT:M*GSS*}'
GSSAPI_BASE
$ env -i __MAKE_CONF=3D PORT_DBDIR=3D/var/empty DEFAULT_VERSIONS=3Dssl=3Dop= enssl make -V '${OPTIONS_DEFAULT:M*GSS*}'
GSSAPI_NONE

See also https://cgit.freebsd= .org/ports/diff/ftp/curl/Makefile?id=3D6d324c1f70c9

I can't reproduce on -CURRENT when only using base OpenSSL 3.0.
=C2=A0
There are several ports with this= problem. Since VirtualBox (and libvncserver) need openssl31, I now delete = openssl31, upgrade ports as required, and then "package add /usr/ports= /packages/All/openssl31-3.1.2.pkg" when finished.

<= /div>
Just today I hit openldap-client trying to use openssl31 eve= n though make.conf does not define it as default. Several other ports also = don't honor the fairly new USES=3Dopenssl and, if they find an openssl = installed, will use it. Since Aug. 1, I have had several other ports hit th= is issue. You really, really don't want ports using openssl31 unless yo= u are sure that they or any port which they depend on are also using openss= l31. If you get shareable libraries with conflicts, it is a pain to clean t= hem up. Maybe a message to all committers that they need to be sure that OP= ENSSLBASE is not used without USES=3Dopenssl. (At least I believe that is t= he case.)


--
Kevin= Oberman, Part time kid herder and retired Network Engineer
E-mail: rkoberman@gmail.com
--0000000000003ba9050602aeaeec--