From nobody Wed Sep 11 17:38:21 2024 X-Original-To: ports@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 4X3nq33QwTz5V1Tn for ; Wed, 11 Sep 2024 17:38:23 +0000 (UTC) (envelope-from SRS0=600G=QJ=klop.ws=ronald-lists@realworks.nl) Received: from smtp-relay-int.realworks.nl (smtp-relay-int.realworks.nl [194.109.157.24]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 4X3nq26kzDz4LNv; Wed, 11 Sep 2024 17:38:22 +0000 (UTC) (envelope-from SRS0=600G=QJ=klop.ws=ronald-lists@realworks.nl) Authentication-Results: mx1.freebsd.org; dkim=pass header.d=klop.ws header.s=rw2 header.b=WzDMqOSv; dmarc=pass (policy=quarantine) header.from=klop.ws; spf=pass (mx1.freebsd.org: domain of "SRS0=600G=QJ=klop.ws=ronald-lists@realworks.nl" designates 194.109.157.24 as permitted sender) smtp.mailfrom="SRS0=600G=QJ=klop.ws=ronald-lists@realworks.nl" Date: Wed, 11 Sep 2024 19:38:21 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=klop.ws; s=rw2; t=1726076301; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: in-reply-to:in-reply-to; bh=rEBAGJ8poGrmtcZeGIJsR2cxoVBfHiXt+3BbeRGVduk=; b=WzDMqOSv+DL42E4XmwBPrHsvDNZLmqBNCluWeNp3lxXtjXfUw1+8QyRshbh0rT+FYtD0LQ HN4RmhydrjJGAVQhrszKbTYVtA3qPPs2oT0m4aJlKmSEnb5Wjf/NGkXacdZGNjDRz8Gi2i OwIPhKd8ejBfad637Tea+oMY85YROlANCAod6irTRSwSDMfDS3x1bum4JMCGO9lV8reRu2 K3pfHO7jMuzbyNUcZMDccCOCyxTLB86DzmuEB71A0GZh/iX9VJ6A9UYxnc1GTdDtkTsFMN NLMzaUIbMS25Z14JS1HPqwm79NPmyDdNPvPStqLYJNs/kfaEXyptdhI1B0OKoA== From: Ronald Klop To: Miroslav Lachman <000.fbsd@quip.cz>, sbz@FreeBSD.org Cc: ports@freebsd.org, cross+freebsd@distal.com Message-ID: <1583439132.2388.1726076301178@localhost> In-Reply-To: Subject: Re: Quarterly 13.3 amd64 package inconsistency? List-Id: Porting software to FreeBSD List-Archive: https://lists.freebsd.org/archives/freebsd-ports List-Help: List-Post: List-Subscribe: List-Unsubscribe: X-BeenThere: freebsd-ports@freebsd.org Sender: owner-freebsd-ports@FreeBSD.org MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_Part_2387_1003036883.1726076301169" X-Mailer: Realworks (719.52) Importance: Normal X-Priority: 3 (Normal) X-Spamd-Bar: / X-Spamd-Result: default: False [-0.67 / 15.00]; SUSPICIOUS_RECIPS(1.50)[]; SUBJECT_ENDS_QUESTION(1.00)[]; NEURAL_HAM_LONG(-1.00)[-1.000]; NEURAL_HAM_MEDIUM(-1.00)[-1.000]; NEURAL_HAM_SHORT(-0.97)[-0.967]; MID_RHS_NOT_FQDN(0.50)[]; DMARC_POLICY_ALLOW(-0.50)[klop.ws,quarantine]; FORGED_SENDER(0.30)[ronald-lists@klop.ws,SRS0=600G=QJ=klop.ws=ronald-lists@realworks.nl]; R_DKIM_ALLOW(-0.20)[klop.ws:s=rw2]; R_SPF_ALLOW(-0.20)[+ip4:194.109.157.0/24]; MIME_GOOD(-0.10)[multipart/alternative,text/plain]; ASN(0.00)[asn:3265, ipnet:194.109.0.0/16, country:NL]; MIME_TRACE(0.00)[0:+,1:+,2:~]; ARC_NA(0.00)[]; TO_DN_SOME(0.00)[]; MLMMJ_DEST(0.00)[ports@freebsd.org]; RCVD_COUNT_ZERO(0.00)[0]; FROM_NEQ_ENVFROM(0.00)[ronald-lists@klop.ws,SRS0=600G=QJ=klop.ws=ronald-lists@realworks.nl]; FROM_HAS_DN(0.00)[]; TAGGED_RCPT(0.00)[freebsd]; HAS_X_PRIO_THREE(0.00)[3]; RCPT_COUNT_THREE(0.00)[4]; TO_MATCH_ENVRCPT_SOME(0.00)[]; DKIM_TRACE(0.00)[klop.ws:+] X-Rspamd-Queue-Id: 4X3nq26kzDz4LNv ------=_Part_2387_1003036883.1726076301169 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: quoted-printable Has this py-OpenSSL issue been resolved already? If not, I can take a look in the near future.=20 Regards, Ronald. Van: Miroslav Lachman <000.fbsd@quip.cz> Datum: 24 augustus 2024 23:45 Aan: ports@freebsd.org CC: cross+freebsd@distal.com Onderwerp: Re: Quarterly 13.3 amd64 package inconsistency? >=20 >=20 > On 24/08/2024 19:48, Chris Ross wrote: >=20 > [..] >=20 > >>> I haven't tested that software nor confirmed version dependencies. Th= e ports tree shows the versions in the trees as mentioned but does not have= a version requirement checked for dependencies. > >> > >> Dependency info referenced above. Is there perhaps an issue with the > >> py-openssl port then? > >=20 > > Coming back to this. I temporarily switched my pkg config to use lates= t > > instead of quarterly, which allowed me to pull in pyopenssl 24.1.0.1 > > and I am now running. However, I think the problem still exists in > > quarterly, and should be corrected. > >=20 > > I=E2=80=99ll drop it if no-one else cares, but it seems a "broken windo= w=E2=80=9D that > > should be fixed. >=20 > We use quarterly packages on all our machines and more and more often I s= ee that something is broken in quarterly and the fix never makes it from HE= AD to quarterly, or that a package in quarterly has a security vulnerabilit= y, the fix is in HEAD but no one merges the security fix into quarterly (e.= g. Postgres). So increasingly I feel like quarterly serves no purpose excep= t to freeze for three months, even if it's broken. > I think if anything is broken in quarterly and the fix is known (in HEAD)= it should be MFH. I know it is sometimes complicated because of cross depe= ndencies, but other cases are simple. >=20 > Are some rules for MFH to quarterly defined in handbook or somewhere else= ? >=20 > Kind regards > Miroslav Lachman >=20 >=20 >=20 >=20 >=20 ------=_Part_2387_1003036883.1726076301169 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: quoted-printable Has this py-OpenSSL issue been resolved already?If not, I can take a look in the near future. 

=
Regards,
Ronald.

Van: Miroslav Lachman <000.fbsd@quip.cz>
Datum: 24 = augustus 2024 23:45
Aan: ports@freebsd.org
C= C: cross+freebsd@distal.com
Onderwerp: Re: Qua= rterly 13.3 amd64 package inconsistency?

On 24/08/2024 19:48, Chris Ross wrote:

[..]

>>> I haven't tested that software nor confirmed version dependenc= ies. The ports tree shows the versions in the trees as mentioned but does n= ot have a version requirement checked for dependencies.
>>
>> Dependency info referenced above.  Is there perhaps an issue = with the
>> py-openssl port then?
>
> Coming back to this.  I temporarily switched my pkg config to use= latest
> instead of quarterly, which allowed me to pull in pyopenssl 24.1.0.1 > and I am now running.  However, I think the problem still exists = in
> quarterly, and should be corrected.
>
> I=E2=80=99ll drop it if no-one else cares, but it seems a "broken wind= ow=E2=80=9D that
> should be fixed.

We use quarterly packages on all our machines and more and more often I see= that something is broken in quarterly and the fix never makes it from HEAD= to quarterly, or that a package in quarterly has a security vulnerability,= the fix is in HEAD but no one merges the security fix into quarterly (e.g.= Postgres). So increasingly I feel like quarterly serves no purpose except = to freeze for three months, even if it's broken.
I think if anything is broken in quarterly and the fix is known (in HEAD) i= t should be MFH. I know it is sometimes complicated because of cross depend= encies, but other cases are simple.

Are some rules for MFH to quarterly defined in handbook or somewhere else?<= br>
Kind regards
Miroslav Lachman




------=_Part_2387_1003036883.1726076301169--