From nobody Mon Jan 29 09:03:36 2024 X-Original-To: freebsd-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 4TNj643QPRz58X2S for ; Mon, 29 Jan 2024 09:04:12 +0000 (UTC) (envelope-from Alexander@Leidinger.net) Received: from mailgate.Leidinger.net (mailgate.leidinger.net [IPv6:2a00:1828:2000:313::1:5]) (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-signature ECDSA (P-256) client-digest SHA256) (Client CN "mailgate.leidinger.net", Issuer "R3" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4TNj632JlBz4hm3; Mon, 29 Jan 2024 09:04:11 +0000 (UTC) (envelope-from Alexander@Leidinger.net) Authentication-Results: mx1.freebsd.org; dkim=pass header.d=leidinger.net header.s=outgoing-alex header.b=i0rdvIPh; dmarc=pass (policy=quarantine) header.from=leidinger.net; spf=pass (mx1.freebsd.org: domain of Alexander@Leidinger.net designates 2a00:1828:2000:313::1:5 as permitted sender) smtp.mailfrom=Alexander@Leidinger.net List-Id: Porting software to FreeBSD List-Archive: https://lists.freebsd.org/archives/freebsd-ports List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-ports@freebsd.org X-BeenThere: freebsd-ports@freebsd.org MIME-Version: 1.0 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=leidinger.net; s=outgoing-alex; t=1706519037; 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:references:references; bh=KrN+3AcKgrpZzT9QOMkILHDDpmMmgYG3JpXw+z/zLYY=; b=i0rdvIPhX3jwmXvBOSoKqW1XAEaF2HuIebRgUtIZP1SRKBALSezveIEk5W/vO6KI/+jRhQ rF0cKgkhiTVzIUxPwD3n/Vgx4iu0yQxde0PcNFfIop+Z6Qu7wQfQs/y3ylUrzYebNNeHRt eM/sRCY8/2VPvbes5dt71R4PtY0PsxADAGCVMxkhvy93hqYmgN1Oq7h5BhNkclKi8hdQfC q4zgaoMmPmUW/vdUYk9EiWkxr0iVTQMUs6kIfxaGkt+l1NaYNjjtpcOQ4HK8vfgW16iBkj 4WGSMd9NfGW2pWnEgLc6st2pnr1kTUUDNdlFokV9VVWOT338R0757CIk+xkLAQ== Date: Mon, 29 Jan 2024 10:03:36 +0100 From: Alexander Leidinger To: Luca Pizzamiglio Cc: Stefan Esser , FreeBSD ports , portmgr , FreeBSD Core Team Subject: Re: This is going to break port building without poudriere! In-Reply-To: References: <609374cf-7f1f-4643-8379-f368b23ccb09@freebsd.org> Message-ID: <1e27bce44f2ba85f0097fbc6aba1dac1@Leidinger.net> Organization: No organization, this is a private message. Content-Type: multipart/signed; protocol="application/pgp-signature"; boundary="=_95f53f3a767db87175f0df71c3b4cb37"; micalg=pgp-sha256 X-Spamd-Bar: ------ X-Spamd-Result: default: False [-6.10 / 15.00]; SIGNED_PGP(-2.00)[]; NEURAL_HAM_LONG(-1.00)[-1.000]; NEURAL_HAM_MEDIUM(-1.00)[-1.000]; NEURAL_HAM_SHORT(-1.00)[-0.997]; DMARC_POLICY_ALLOW(-0.50)[leidinger.net,quarantine]; MIME_GOOD(-0.20)[multipart/signed,text/plain]; R_SPF_ALLOW(-0.20)[+mx]; R_DKIM_ALLOW(-0.20)[leidinger.net:s=outgoing-alex]; MISSING_XM_UA(0.00)[]; ARC_NA(0.00)[]; MIME_TRACE(0.00)[0:+,1:+,2:~]; ASN(0.00)[asn:34240, ipnet:2a00:1828::/32, country:DE]; HAS_ORG_HEADER(0.00)[]; SUBJECT_ENDS_EXCLAIM(0.00)[]; DKIM_TRACE(0.00)[leidinger.net:+]; RCPT_COUNT_FIVE(0.00)[5]; FROM_EQ_ENVFROM(0.00)[]; FROM_HAS_DN(0.00)[]; RCVD_COUNT_ZERO(0.00)[0]; TO_MATCH_ENVRCPT_ALL(0.00)[]; MLMMJ_DEST(0.00)[freebsd-ports@freebsd.org]; TO_DN_ALL(0.00)[]; MID_RHS_MATCH_FROM(0.00)[]; HAS_ATTACHMENT(0.00)[] X-Rspamd-Queue-Id: 4TNj632JlBz4hm3 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --=_95f53f3a767db87175f0df71c3b4cb37 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=US-ASCII; format=flowed Am 2024-01-27 16:59, schrieb Luca Pizzamiglio: > Hi Stefan. > > Let's start from the beginning, as it seems that things are not clear. > > Subpackages is a feature to create multiple packages from one build > Those subpackages can depend on the main package. > The main package cannot depend on any subpackages. > This limits the cases where subpackages can be applied. The main > package MUST be independent from its subpackages. Subpackages can only > add features (like a plugin). > To recall your NLS example (ref > https://reviews.freebsd.org/D16457#715443): this is not a use-case for > subpackages. If the main program/library needs to be compiled > differently with or without NLS, this is not viable for subpackages. > If a port needs to be built multiple times to create different > subpackages, this is not a viable case for subpackages. > A good candidate is qt6-tools: this port contains multiple tools > (designer, linguist, help, and so on). Those tools could be put in > different subpackages. > > I hope this explanation helps to clarify and address some of your > concerns. As I read this, lang/php is the best example of a port where subpackages has a benefit (in the sense it matches your description above to the letter, the main port independent from the subpacakges, and what can be build as subpackages is a plugin/extension). > OPTIONS and SUBPACKAGES > Do we have to convert OPTIONS to SUBPACKAGES? No. > Can a SUBPACKAGE be built only if an OPTION is enabled? Yes. > The only viable use cases for SUBPACKAGES being enabled/disabled by > OPTIONS is limited to those portions of the port that do not affect the > main package. > Examples are: additional libraries, additional data files, and so on. > > Consolidate master/slave ports in one bigger ports > About this topic, I guess your concerns are mainly related to potential > explosion of build time of the consolidated ports. > This is a justified concern. > In those cases, we are suggesting to convert slave ports in SUBPACKAGES > enabled via OPTIONS. > This will allow port builders to configure the bigger ports to not > build all SUBPACKAGES, but only the needed ones. This should restore > the previous build time. > > However, as for the php case, the maintainer is going to evaluate if > the consolidation makes sense or not. > If a consolidation is going to result more problematic than beneficial, > it can be reverted and subpackages not adopted for the use case. If I understand the sum of all the above correct, you suggest to remove slave ports and to use subpackages instead (where this makes sense in terms of the current implementation of subpackages). Or worded differently to the same effect (as I only care about the effect and not the intention), when someone converts a port to subpackages, the corresponding slave packages shall be removed (or for new ports: slave ports shall not be introduced in this case). Removing slave ports means we can not depend upon specific parts anymore when installing from ports, as the subpackages can not be targeted for install directly and my example of a subpackages aware php results in security implications of to much being installed and active if installed via make install in /usr/ports/something/with_webinterface. -> best example of lang/php to use subpacakges is the best example of why not to use subpackages / shows what is a regression in the features we provide in our ports collection. While qt6-tools may be a good example where subpackages makes sense, we can not depend on subpacakges for "make install", and as if the port would be converted to have subpackages but no slave ports are introduced, pkg install and make install would differ in the amount of installed files. > For port builders > > Port builders can experience longer build times in the future, as > master/slave ports could be consolidated in one single larger ports. > If this is the case, the larger ports should provide OPTIONS to not > build unneeded subpackages. > If no OPTION is available, please work with the maintainer to introduce > one. I fail to see the benefit: We either lose the possibility to target parts of a package (when slave ports are removed / not introduced) on make install (with a similar amount of build time for the ports tree as it is right now), or get higher build times for the package builders. In both cases we do not gain something significant. If we want to keep the (useful in some cases) feature to install from ports (there is the case of py39-rpds-py failing to build in my poudriere which I tried to debug with the author of py-maturin due to a runtime issue in maturin, which shows up in my the cross build on amd64-intel for amd64-athlon64... which in the end leads me to build py-rpds-py on the target machine from ports), the current implementation of subpackages has to come with the requirement to create slave ports for each subpackage. That's my concern, and that's the reason why I have the opinion, that portmgr has to keep the lock on subpackages and reject any subpackage which don't come with a slave port. I would be OK to lift this restriction, when the current implementation is changed to be able to only install the files of a subpacakge on make install (an implementation could be to require "make install TARGET_SUBPACAKGES=sub1,sub2,sub3" or "make install-subpackage1 install-subpacakge2"... as long as recursive dependencies are handled according to this requirement, those people designing, implementing and reviewing this can argue about such details). Keeping the current implementation (with the restriction of always introducing slave packages for subpackages) would need a way to denote that a slave port covers a specific subpackage which would allow package builders to skip those slave ports (and the subpacakges would need to have the same package name as the slave port, no idea if this has a technical disadvantage in terms of having 2 different origins for the same package name, but it surely would be confusing for people at first look). TLDR: for the use cases you specified in the beginning, I do not see a benefit, only drawbacks. Can you please provide an example of a benefit I fail to see (yes, more modularity for qt6-tools may be beneficial for some people, but the cost/benefit between qt6-tools (something which we don't provide right now) and "make install" (what we provide right now) or "build time reduction for package builders" (which would have a benefit for a lot of use cases) is in my books much more in the direction of "make install" and "build time reduction" than towards the modularization of qt6-tools)? Bye, Alexander. -- http://www.Leidinger.net Alexander@Leidinger.net: PGP 0x8F31830F9F2772BF http://www.FreeBSD.org netchild@FreeBSD.org : PGP 0x8F31830F9F2772BF --=_95f53f3a767db87175f0df71c3b4cb37 Content-Type: application/pgp-signature; name=signature.asc Content-Disposition: attachment; filename=signature.asc; size=833 Content-Description: OpenPGP digital signature -----BEGIN PGP SIGNATURE----- iQIzBAEBCAAdFiEER9UlYXp1PSd08nWXEg2wmwP42IYFAmW3afgACgkQEg2wmwP4 2IbpORAAnteg1C5NU7Fhcj7ndTq7oZWx7DAiPVr6qokyT+btJGpKhThaLB+n4Xm1 NYCf0gMfNcKCht8uWuejG+eIZkVN7Sou+wyZbQ7Ey07vWVCAV1bu/MENzwAzHaBU gZYs11626G1ZdyBCGX2XgyqzyxOSEJjk3c/A8ulB7C9TyLdxWf7q5dxlggwodfAV PAbfW5J/HuvIBLL6q9fVNuGpqafsH/vyQVtsMdtBF5r/A6B5J8ZsijBYaNjx8h85 95yDC1EUp68AdH0OXZbyU0PdP0p4HAb6tClC8TzQmSWX5RpptmMNQoK2MxarTL9u WRfLRBHxajOe2yDjPn6gCs0N8vztQJ616Xfec0XInrXqWcW0Vkwus9YJiHmtkmrV u823YsKiHcF3ceTyhoZy6wP32W5Exi9h2kE7YGJo7CrfCn1GB8vVGnZ4tnm8CCdh QkeESgW4aLmiXihreCIDKz9RYcnOajCFN+wPoe+fK06BWZvRb8AK0QQ0Q7iQm+xd XF9tdBeFKM8TWFP+LLQTN7tl3ppqIq7YLBmf5dkMiSLwHut6gStQo4PN3Q3OLA2d Z0vejL6eE7WBixOlFw3RXtaFznb2tL20xJIGm/WOprGQ3c46pFa6duCzKTQPH/iz ozvFf/t347gAxEXq2JDTowmzoY+lm9tW5kVYHly/O6ABgNAJmdY= =wRzG -----END PGP SIGNATURE----- --=_95f53f3a767db87175f0df71c3b4cb37-- From nobody Mon Jan 29 09:27:02 2024 X-Original-To: freebsd-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 4TNjcf085qz58KS5 for ; Mon, 29 Jan 2024 09:27:14 +0000 (UTC) (envelope-from eduardo@freebsd.org) Received: from smtp.freebsd.org (smtp.freebsd.org [IPv6:2610:1c1:1:606c::24b:4]) (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-signature RSA-PSS (4096 bits) client-digest SHA256) (Client CN "smtp.freebsd.org", Issuer "R3" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4TNjcd6nyCz4ltM for ; Mon, 29 Jan 2024 09:27:13 +0000 (UTC) (envelope-from eduardo@freebsd.org) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=freebsd.org; s=dkim; t=1706520434; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:mime-version:mime-version:content-type:content-type; bh=LZG0fAU3mG10AUrotaIYYL2rZ0H1VNn+DrQyleQWt1Y=; b=ZDRiDWopPrX6yADENH45xYFVquDXT9JbaTqfeJJFIjAqLvxkapizi/VvpGnbo0Q3cp1jop f1U1mEVqpvQ7B2Nkkt8ZYgPkBNLWLa5xc4q0dYa60p/shnJA1zHzh5FRWr/gLz7PFwYCaN 1HBMd9fqbOiYu67S5ikfkcyoLcKsNy06CAx17IKTslVm2X3TA+A1/Dn0r4ETAwrF4jdtOS DfaCuR8yyAtnt8ylZezIAKL0gspIqwIhbs5QwPJQUaaB6mT/jlo1nMt48icUfFvNGiqOh1 o0qMj32bz2gjyegkSclN6eAX4VZmErVb0CZK+2wn0F2f4RoY/iFFLFGA+Kr7Rw== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=freebsd.org; s=dkim; t=1706520434; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:mime-version:mime-version:content-type:content-type; bh=LZG0fAU3mG10AUrotaIYYL2rZ0H1VNn+DrQyleQWt1Y=; b=S5LnuZiJ2HT3Xt9Z5bwn/Op0wB+pWfqNWGL84Q7KNWpzonVi10c1lS5IbUR29qGeU2BTod wpU+HE0S37ev5FB+ZFSlGwsG9JykVo7UB5bOe5T6Il7O7zA0ek4D/cfpmTxAvSDe0vq826 RIArouY68J/v5VQLb2yDfOqNpyREThGNToQx5S/z5jK0TVnyTbfpJdqqN50DC2Apja1Y0q 6/rWjv5FxqclO/EpKoX6hBVMi6e1fXiMXpdDgbQVg3qS1fbdd3F/aKFmnQ39mOZjf8EpGO YBFfSvTtV/4ZRYSPNkWi7sADQcZ2NA4k4S3fcjplSpHMikbbG8nyI+sAqckGkw== ARC-Authentication-Results: i=1; mx1.freebsd.org; none ARC-Seal: i=1; s=dkim; d=freebsd.org; t=1706520434; a=rsa-sha256; cv=none; b=jHYkcT2pKk1l2L0khxJrfZbM5j4P3qbtFonR36/Ef3dajIi5aseDd54GmDb7zsoXOgJgz9 v4BnnnHQrC2D1JFVqZIvbinGpKT6r1F/zOJlvulzhSz3AIaskog1kRnL8D2e6k2Ei+gARy 4q4ktreKEp7hiBN0/U6fXU/gI+R6hRTL5czu27nbXhjYN/kXcQDG89kh9noKqrNtXAfb35 aVZf8zy/gqoSuHT9jyLeDmB7/fmj+VeyFp5EEYMZQOvbLX4vYfJ84vO22KtetuhHtHuIV5 09CDKFZk+iGU/3/qDGb0wEsmzqZjcOXj5wRgmyt4/+TB5YJSxrjIywW4ek5Tkg== Received: from mail-qt1-f178.google.com (mail-qt1-f178.google.com [209.85.160.178]) (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)) (Authenticated sender: eduardo) by smtp.freebsd.org (Postfix) with ESMTPSA id 4TNjcd5lY3z16yC for ; Mon, 29 Jan 2024 09:27:13 +0000 (UTC) (envelope-from eduardo@freebsd.org) Received: by mail-qt1-f178.google.com with SMTP id d75a77b69052e-42a8a398cb2so25233671cf.1 for ; Mon, 29 Jan 2024 01:27:13 -0800 (PST) X-Gm-Message-State: AOJu0YwWSHoi2XW5LjkFdRh3oON4bE8TPXxnXbqQtHX8hlt8DG16uFUc hRI0hnCgIp5DLSR6FthM7xfKcvxIQdYlZ2KHObEK00mfbcAsby5f5OOip9nipx+RoskVbczv5IO C7yBjFK8WHRCm/WblYOCUlJSdSl8= X-Google-Smtp-Source: AGHT+IHH9GftVdOOuCufJ7Kjf4e0n2wwiZtKb1i9SOlkHIMiBug88puPisraMO9HFysraXF1pKE+ellDkO4BGtAjFyk= X-Received: by 2002:ac8:5cc9:0:b0:42a:476c:b67a with SMTP id s9-20020ac85cc9000000b0042a476cb67amr7159449qta.69.1706520433439; Mon, 29 Jan 2024 01:27:13 -0800 (PST) List-Id: Porting software to FreeBSD List-Archive: https://lists.freebsd.org/archives/freebsd-ports List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-ports@freebsd.org X-BeenThere: freebsd-ports@freebsd.org MIME-Version: 1.0 From: Nuno Teixeira Date: Mon, 29 Jan 2024 09:27:02 +0000 X-Gmail-Original-Message-ID: Message-ID: Subject: LDFLAGS= -pthread situation To: FreeBSD Mailing List Content-Type: multipart/alternative; boundary="0000000000003cbaf20610124086" --0000000000003cbaf20610124086 Content-Type: text/plain; charset="UTF-8" Hello all! I was updating games/exult-devel and I found that build failed with: ld: error: undefined symbol: pthread_create >>> referenced by LowLevelMidiDriver.cpp >>> LowLevelMidiDriver.o:(std::__1::thread::thread Related to a upstream change about threading support from C++11... Using LDFLAGS= -pthread fixed build and it is present in lot of ports. My question is if upstream could do anything to avoid this LDFLAGS addition. This is being discussed at https://github.com/exult/exult/issues/436 Any sugestions are welcome! Thanks, -- Nuno Teixeira FreeBSD Committer (ports) --0000000000003cbaf20610124086 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Hello all!

I was updating ga= mes/exult-devel and I found that build failed with:
ld: error: undefined =
symbol: pthread_create
>>> referenced by LowLevelMidiDriver.cpp
>>>               LowLevelMidiDriver.o:(std::__1::thread::thread&l=
t;int (&)(LowLevelMidiDriver*) <snip>

=
Related to a upstream change about threading support from C++11.= ..

Using LDFLAGS=3D -pthread fixed build and it is presen= t in lot of ports.

My question is if upstream coul= d do anything to avoid this LDFLAGS addition.
This is being discu= ssed at https://githu= b.com/exult/exult/issues/436

Any sugestions ar= e welcome!

Thanks,

--
Nuno Teixeira
FreeBSD Committer (ports)
--0000000000003cbaf20610124086-- From nobody Mon Jan 29 11:10:52 2024 X-Original-To: freebsd-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 4TNlwT5hN9z58V79 for ; Mon, 29 Jan 2024 11:11:05 +0000 (UTC) (envelope-from junchoon@dec.sakura.ne.jp) Received: from www121.sakura.ne.jp (www121.sakura.ne.jp [153.125.133.21]) (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 4TNlwS5s69z3yfV; Mon, 29 Jan 2024 11:11:04 +0000 (UTC) (envelope-from junchoon@dec.sakura.ne.jp) Authentication-Results: mx1.freebsd.org; none Received: from kalamity.joker.local (123-1-91-49.area1b.commufa.jp [123.1.91.49]) (authenticated bits=0) by www121.sakura.ne.jp (8.17.1/8.17.1/[SAKURA-WEB]/20201212) with ESMTPA id 40TBArpd021732; Mon, 29 Jan 2024 20:10:53 +0900 (JST) (envelope-from junchoon@dec.sakura.ne.jp) Date: Mon, 29 Jan 2024 20:10:52 +0900 From: Tomoaki AOKI To: Nuno Teixeira Cc: FreeBSD Mailing List Subject: Re: LDFLAGS= -pthread situation Message-Id: <20240129201052.3520bea9850f96c9180b3bbc@dec.sakura.ne.jp> In-Reply-To: References: Organization: Junchoon corps X-Mailer: Sylpheed 3.7.0 (GTK+ 2.24.33; amd64-portbld-freebsd14.0) List-Id: Porting software to FreeBSD List-Archive: https://lists.freebsd.org/archives/freebsd-ports List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-ports@freebsd.org X-BeenThere: freebsd-ports@freebsd.org Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-Rspamd-Queue-Id: 4TNlwS5s69z3yfV 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:7684, ipnet:153.125.128.0/18, country:JP] On Mon, 29 Jan 2024 09:27:02 +0000 Nuno Teixeira wrote: > Hello all! > > I was updating games/exult-devel and I found that build failed with: > > ld: error: undefined symbol: pthread_create > >>> referenced by LowLevelMidiDriver.cpp > >>> LowLevelMidiDriver.o:(std::__1::thread::thread > > > Related to a upstream change about threading support from C++11... > > Using LDFLAGS= -pthread fixed build and it is present in lot of ports. > > My question is if upstream could do anything to avoid this LDFLAGS addition. > This is being discussed at https://github.com/exult/exult/issues/436 > > Any sugestions are welcome! > > Thanks, > > -- > Nuno Teixeira > FreeBSD Committer (ports) Different port, but looks very similar situation with Bug 275950 [1], which I've filed but still not yet triaged (Status: New). [1] https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=275950 -- Tomoaki AOKI From nobody Mon Jan 29 12:28:01 2024 X-Original-To: freebsd-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 4TNndT3py2z58d5V for ; Mon, 29 Jan 2024 12:28:13 +0000 (UTC) (envelope-from eduardo@freebsd.org) Received: from smtp.freebsd.org (smtp.freebsd.org [IPv6:2610:1c1:1:606c::24b:4]) (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-signature RSA-PSS (4096 bits) client-digest SHA256) (Client CN "smtp.freebsd.org", Issuer "R3" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4TNndT34Tnz46xt for ; Mon, 29 Jan 2024 12:28:13 +0000 (UTC) (envelope-from eduardo@freebsd.org) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=freebsd.org; s=dkim; t=1706531293; 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:references:references; bh=QPrwkEYxn0Yr6WLnoXlBGQdKY2QG7/km6k5T7ljlwf4=; b=DlsuryGL0wEOlYoq40+xV2b1xagk/YrBXABtUh0I7GBjuAdtcUpNO5bQSimXCf0qOIcc4h 0NS4jpQpebO8ieD9DBNdwmgpxHfw206zvViPkZ7dSv+8mLUocF4j1vzKPfPb5zthQ7h95z M7BEQdEz54FtOovv09HkPVimbujpjLkRlFPHDdyB+jmoRVYhRDYOpW9IVMjA/zxjaIlO9K dUK6xb+ecaS/K0eS9VGZwNQeVhhWFWV/HZSjBiAGfVIQNyA4dsDpMBx9OTTWrg0eldykFx MIJUaR8MQQAFWO/bEQh9UERuAdMMc43vcq9dtk6AdmjJ5vFV0TpgQ3EpaE7vow== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=freebsd.org; s=dkim; t=1706531293; 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:references:references; bh=QPrwkEYxn0Yr6WLnoXlBGQdKY2QG7/km6k5T7ljlwf4=; b=mw6R2hqek1ArcjIoYQCFYE+riw170qgnOCtOcI78NlCGvMEqf2PQahM2BhVzcDJI0Lxlko dc99QjKn+q9/jIoUwcsaWHVZ9EaN0QPq25Z6Sk50y2Ft3f13ah0ObfqWDx8hRu6SsgwDaZ J0dzDt4SKAKroiKG7KDjwp762Mv8NyAWZXRYREDXexB88a1mESFBG7vtyGeTnxefG/x5qh NnKnJjgSHPEZJulTVI2GStnZwFhRNJ4NVMVwFzWYU72H5bkJgWDrvaFrq8YkeRjq8ahPiX E3GnjWATv1Ykw6nwOW94GUMssQ/9x8qbdM3KUGoeNR/TTcQTqyLyEmWPqVkgVA== ARC-Authentication-Results: i=1; mx1.freebsd.org; none ARC-Seal: i=1; s=dkim; d=freebsd.org; t=1706531293; a=rsa-sha256; cv=none; b=Yp7Z43WvP3kh5PSrUQY3E8yB1xCWFGdfPJFfLjR7FOjCjAw7Iyh82LNXB4d9PA9eoTUxTg OLMajLRdhD85b2498uz8agMu8BTEE+ZetMy3mEzJH1UyWgBCRsjD5je0Ol1TNq42VgL+6z PGkkXgaY1jACteHB0jfubIy8aeuNdryYFTXLhDkdp1idU2l1LHvHlOgZXh7FES0Qxf7fg7 30WC1yX/SijBwq+b0qvwHNWd0kaaDj2y29jR6Yqiux4ThDJlJOXhcwpg8IkuCZi86udPSU 6ZiyJMvAEptJAALiabMmdYDplYtHPfSvirDFnV9S7Yyt1NHH+Kk0uJmXPtNnhg== Received: from mail-qt1-f178.google.com (mail-qt1-f178.google.com [209.85.160.178]) (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)) (Authenticated sender: eduardo) by smtp.freebsd.org (Postfix) with ESMTPSA id 4TNndT20B4z1B4d for ; Mon, 29 Jan 2024 12:28:13 +0000 (UTC) (envelope-from eduardo@freebsd.org) Received: by mail-qt1-f178.google.com with SMTP id d75a77b69052e-427a3887483so24379451cf.3 for ; Mon, 29 Jan 2024 04:28:13 -0800 (PST) X-Gm-Message-State: AOJu0Yxz9ZzWOqoYYUs+t5dIj8rpQYDZJmA5CMR9GgZtc2fya5rgJ6sm OQ0oWi9RhbtnheTkGmtyAJRweukXNbmPyhsYI3LTET++Ly8byNRePmP6Zi3k0A1PIUmbJONV41H WbTH/WNQhMO/+qjKQXHhDU3kPIZk= X-Google-Smtp-Source: AGHT+IHOCwgvLjY2bvPOQHuces98NA5KOKHHJte+Gt4QcC68q+Q0tBHkrlARkdIJZxK9cqPn+lcDZouptjHOucKiSQU= X-Received: by 2002:ac8:5713:0:b0:42a:ad64:bd3e with SMTP id 19-20020ac85713000000b0042aad64bd3emr496678qtw.92.1706531292942; Mon, 29 Jan 2024 04:28:12 -0800 (PST) List-Id: Porting software to FreeBSD List-Archive: https://lists.freebsd.org/archives/freebsd-ports List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-ports@freebsd.org X-BeenThere: freebsd-ports@freebsd.org MIME-Version: 1.0 References: <20240129201052.3520bea9850f96c9180b3bbc@dec.sakura.ne.jp> In-Reply-To: <20240129201052.3520bea9850f96c9180b3bbc@dec.sakura.ne.jp> From: Nuno Teixeira Date: Mon, 29 Jan 2024 12:28:01 +0000 X-Gmail-Original-Message-ID: Message-ID: Subject: Re: LDFLAGS= -pthread situation To: Tomoaki AOKI Cc: FreeBSD Mailing List Content-Type: multipart/alternative; boundary="00000000000083964a061014c706" --00000000000083964a061014c706 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Interesting that it using same fix of around 300 ports for a quick grep of LDFLAGS. Maybe I will take a look of what someone said upstream: "There is a case statement on $host_os near the beginning of configure.ac, with freebsd as a possible choice. Could you test whether it would be enough to add there a SYSLIBS=3D"-lpthre= ad" like we do for Solaris or Darwin ?" It seems interesting dealing this upstream like they do for other OSes. Also, I've saw similar fixes by upstream with cmake. What you think? Tomoaki AOKI escreveu (segunda, 29/01/2024 =C3= =A0(s) 11:11): > On Mon, 29 Jan 2024 09:27:02 +0000 > Nuno Teixeira wrote: > > > Hello all! > > > > I was updating games/exult-devel and I found that build failed with: > > > > ld: error: undefined symbol: pthread_create > > >>> referenced by LowLevelMidiDriver.cpp > > >>> LowLevelMidiDriver.o:(std::__1::thread::thread (&)(LowLevelMidiDriver*) > > > > > > Related to a upstream change about threading support from C++11... > > > > Using LDFLAGS=3D -pthread fixed build and it is present in lot of ports= . > > > > My question is if upstream could do anything to avoid this LDFLAGS > addition. > > This is being discussed at https://github.com/exult/exult/issues/436 > > > > Any sugestions are welcome! > > > > Thanks, > > > > -- > > Nuno Teixeira > > FreeBSD Committer (ports) > > Different port, but looks very similar situation with Bug 275950 [1], > which I've filed but still not yet triaged (Status: New). > > > [1] https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=3D275950 > > -- > Tomoaki AOKI > --=20 Nuno Teixeira FreeBSD Committer (ports) --00000000000083964a061014c706 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Interesting that it using same fix of around 300 port= s for a quick grep of LDFLAGS.

Maybe I will take a= look of what someone said upstream:
"There is a case statem= ent on $host_os near the beginning= of confi= gure.ac, with freebsd a= s a possible choice.
Could you test whether it would be enough to= add there a SYSLIBS=3D"-lpthread&qu= ot; like we do for Solaris or Darwin ?"

It seems interesting dealing this upstream like they do for other OSes.

Also, I've saw similar fixes by upstream with c= make.

What you think?

Tomoaki AOKI &l= t;junchoon@dec.sakura.ne.jp> escreveu (segunda, 29/01/2024 =C3=A0(s) 11:11):
On Mon, 29 Jan 2024 09:27:02 +0000 Nuno Teixeira <= eduardo@freebsd.org> wrote:

> Hello all!
>
> I was updating games/exult-devel and I found that build failed with: >
> ld: error: undefined symbol: pthread_create
> >>> referenced by LowLevelMidiDriver.cpp
> >>>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0Low= LevelMidiDriver.o:(std::__1::thread::thread<int (&)(LowLevelMidiDriv= er*) <snip>
>
>
> Related to a upstream change about threading support from C++11...
>
> Using LDFLAGS=3D -pthread fixed build and it is present in lot of port= s.
>
> My question is if upstream could do anything to avoid this LDFLAGS add= ition.
> This is being discussed at https://github.com/exult/ex= ult/issues/436
>
> Any sugestions are welcome!
>
> Thanks,
>
> --
> Nuno Teixeira
> FreeBSD Committer (ports)

Different port, but looks very similar situation with Bug 275950 [1],
which I've filed but still not yet triaged (Status: New).


[1] https://bugs.freebsd.org/bugzilla/show= _bug.cgi?id=3D275950

--
Tomoaki AOKI=C2=A0 =C2=A0 <junchoon@dec.sakura.ne.jp>


--
Nuno Teixeira
FreeBSD Committ= er (ports)
--00000000000083964a061014c706-- From nobody Mon Jan 29 12:48:50 2024 X-Original-To: freebsd-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 4TNp5N59X7z58fb6 for ; Mon, 29 Jan 2024 12:48:56 +0000 (UTC) (envelope-from junchoon@dec.sakura.ne.jp) Received: from www121.sakura.ne.jp (www121.sakura.ne.jp [153.125.133.21]) (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 4TNp5M6DSSz4B1X; Mon, 29 Jan 2024 12:48:55 +0000 (UTC) (envelope-from junchoon@dec.sakura.ne.jp) Authentication-Results: mx1.freebsd.org; none Received: from kalamity.joker.local (123-1-91-49.area1b.commufa.jp [123.1.91.49]) (authenticated bits=0) by www121.sakura.ne.jp (8.17.1/8.17.1/[SAKURA-WEB]/20201212) with ESMTPA id 40TCmo8O038873; Mon, 29 Jan 2024 21:48:51 +0900 (JST) (envelope-from junchoon@dec.sakura.ne.jp) Date: Mon, 29 Jan 2024 21:48:50 +0900 From: Tomoaki AOKI To: Nuno Teixeira Cc: FreeBSD Mailing List Subject: Re: LDFLAGS= -pthread situation Message-Id: <20240129214850.2e0a615875eacc6fae995b3d@dec.sakura.ne.jp> In-Reply-To: References: <20240129201052.3520bea9850f96c9180b3bbc@dec.sakura.ne.jp> Organization: Junchoon corps X-Mailer: Sylpheed 3.7.0 (GTK+ 2.24.33; amd64-portbld-freebsd14.0) List-Id: Porting software to FreeBSD List-Archive: https://lists.freebsd.org/archives/freebsd-ports List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-ports@freebsd.org X-BeenThere: freebsd-ports@freebsd.org Mime-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit X-Rspamd-Queue-Id: 4TNp5M6DSSz4B1X 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:7684, ipnet:153.125.128.0/18, country:JP] On Mon, 29 Jan 2024 12:28:01 +0000 Nuno Teixeira wrote: > Interesting that it using same fix of around 300 ports for a quick grep of > LDFLAGS. > > Maybe I will take a look of what someone said upstream: > "There is a case statement on $host_os near the beginning of configure.ac, > with freebsd as a possible choice. > Could you test whether it would be enough to add there a SYSLIBS="-lpthread" > like we do for Solaris or Darwin ?" > > It seems interesting dealing this upstream like they do for other OSes. > > Also, I've saw similar fixes by upstream with cmake. > > What you think? Frankly, I'm open about what kind of fixes are applied. If SYSLIBS= way works for the specific port (in the case I've bitte, devel/libayatana-indicator). I'm not yet sure enough to determine what way exists and in those ways which actually works. But it would need more deeper investivations. The choices for now would be *Temporarily fix with ad-hoc way and fix again when really correct fix is found. or *Investigate from now on for logically and actually correct fix and wait until it finishes. If I myself is the maintainer and a committer, I would prefer the former way. As leaving port(s) unbuildable for a long time even though a working wourkaround is known isn't a good thing. Keeping PR as New/Open/In Progress until logically correct is found would be not too bad idea, though, pkg should be better "buildable". Regards. > > Tomoaki AOKI escreveu (segunda, 29/01/2024 à(s) > 11:11): > > > On Mon, 29 Jan 2024 09:27:02 +0000 > > Nuno Teixeira wrote: > > > > > Hello all! > > > > > > I was updating games/exult-devel and I found that build failed with: > > > > > > ld: error: undefined symbol: pthread_create > > > >>> referenced by LowLevelMidiDriver.cpp > > > >>> LowLevelMidiDriver.o:(std::__1::thread::thread > (&)(LowLevelMidiDriver*) > > > > > > > > > Related to a upstream change about threading support from C++11... > > > > > > Using LDFLAGS= -pthread fixed build and it is present in lot of ports. > > > > > > My question is if upstream could do anything to avoid this LDFLAGS > > addition. > > > This is being discussed at https://github.com/exult/exult/issues/436 > > > > > > Any sugestions are welcome! > > > > > > Thanks, > > > > > > -- > > > Nuno Teixeira > > > FreeBSD Committer (ports) > > > > Different port, but looks very similar situation with Bug 275950 [1], > > which I've filed but still not yet triaged (Status: New). > > > > > > [1] https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=275950 > > > > -- > > Tomoaki AOKI > > > > > -- > Nuno Teixeira > FreeBSD Committer (ports) -- Tomoaki AOKI From nobody Tue Jan 30 04:05:13 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 4TPBQf72nCz58B5v for ; Tue, 30 Jan 2024 04:05:14 +0000 (UTC) (envelope-from portscout@FreeBSD.org) Received: from mxrelay.nyi.freebsd.org (mxrelay.nyi.freebsd.org [IPv6:2610:1c1:1:606c::19:3]) (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-signature RSA-PSS (4096 bits) client-digest SHA256) (Client CN "mxrelay.nyi.freebsd.org", Issuer "R3" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4TPBQd65K8z4KxV for ; Tue, 30 Jan 2024 04:05:13 +0000 (UTC) (envelope-from portscout@FreeBSD.org) ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=freebsd.org; s=dkim; t=1706587513; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:mime-version:mime-version:content-type:content-type: content-transfer-encoding:content-transfer-encoding; bh=rTJSDzaDcUWpuqV41qboY7m7BwS95ygS60kih8cnP/o=; b=cumr9f1Wagfg3l/QFLd4aQHcWDMr4ckrA/6ANu62Mj1MfPtoTbVvOS9GSzbvGX02eAM1G/ o3fyzCfeYNjFNScQwwrwLhephlXfYofkYKjL7vP7x3EiH0Zmp0/yH/FA6RvsTjTalhmFET gTi49Y3uqxH579ebbpyuLQjkCSu2UBq3sut0zzmgyIPQYY0UIA4NXKLORUgp22ANsInY/P zrG1HrnODNqUvgc7n4yBGk8t7NxoLLHt0TpK7N7iWbf7/WmkgE8Muj9145SSvCDvunIIOl C7BvcqaqsGBUwyDwF0ttu7u97ovqlOSGm3g6bRZGpJQNipsfYe9RInZf+Z6HTg== ARC-Authentication-Results: i=1; mx1.freebsd.org; none ARC-Seal: i=1; s=dkim; d=freebsd.org; t=1706587513; a=rsa-sha256; cv=none; b=L4ddD0/Zyx/HS5LaBMwmvNO0SRNNnR1VSL+++O6X7vWrbr39UX/q0bHhn8l19MaEqr/XNv AoBiF2DV682R9HzlCSX/K+U5RvP8m8bRhN5dGEd3FB+ZNfcd6G0abg9S9cuONJZup7etd6 JQHCxPUzBxDhvWZPYwcDc1cxl8d3M8UxnRdPd2sk87HGf7EDegqGPBdlfpvMqJ9KEZHOXi FeS8S4D4kP1Ha+v4hRb3uqGsfZVf3lvgGI1RNmSOVQmIp5bD4iY0dUaABepSXeH80K9sYl EB696UQgE7OUgNkTXZh5NBUHHjMI8uwpydnmJTAf5piPlI43ZERARtx3hyCPVA== Received: from portscout.nyi.freebsd.org (portscout.nyi.freebsd.org [IPv6:2610:1c1:1:606c::50:21]) (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 mxrelay.nyi.freebsd.org (Postfix) with ESMTPS id 4TPBQd49QYzKVM for ; Tue, 30 Jan 2024 04:05:13 +0000 (UTC) (envelope-from portscout@FreeBSD.org) Received: from portscout.nyi.freebsd.org ([127.0.1.10]) by portscout.nyi.freebsd.org (8.17.1/8.17.1) with ESMTP id 40U45D5t082967 for ; Tue, 30 Jan 2024 04:05:13 GMT (envelope-from portscout@FreeBSD.org) Received: (from portscout@localhost) by portscout.nyi.freebsd.org (8.17.1/8.17.1/Submit) id 40U45DOc082966; Tue, 30 Jan 2024 04:05:13 GMT (envelope-from portscout@FreeBSD.org) Message-Id: <202401300405.40U45DOc082966@portscout.nyi.freebsd.org> X-Authentication-Warning: portscout.nyi.freebsd.org: portscout set sender to portscout@FreeBSD.org using -f Content-Disposition: inline Content-Transfer-Encoding: 8bit Content-Type: text/plain List-Id: Porting software to FreeBSD List-Archive: https://lists.freebsd.org/archives/freebsd-ports List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-ports@freebsd.org X-BeenThere: freebsd-ports@freebsd.org MIME-Version: 1.0 Date: Tue, 30 Jan 2024 04:05:13 +0000 From: portscout@FreeBSD.org To: ports@freebsd.org Subject: Unmaintained FreeBSD ports which are out of date X-Mailer: portscout/0.8.1 Dear port maintainers, The portscout new distfile checker has detected that one or more unmaintained ports appears to be out of date. Please take the opportunity to check each of the ports listed below, and if possible and appropriate, submit/commit an update. Please consider also adopting this port. If any ports have already been updated, you can safely ignore the entry. An e-mail will not be sent again for any of the port/version combinations below. Full details can be found at the following URL: http://portscout.freebsd.org/ports@freebsd.org.html Port | Current version | New version ------------------------------------------------+-----------------+------------ cad/ifcopenshell | 0.6.0 | blenderbim-240129 ------------------------------------------------+-----------------+------------ lang/gnatcross-binutils-aarch64 | 2.27 | 2.42 ------------------------------------------------+-----------------+------------ sysutils/nix | 2.3.11 | 2.20.0 ------------------------------------------------+-----------------+------------ If any of the above results are invalid, please check the following page for details on how to improve portscout's detection and selection of distfiles on a per-port basis: http://portscout.freebsd.org/info/portscout-portconfig.txt Reported by: portscout! From nobody Tue Jan 30 09:42:20 2024 X-Original-To: freebsd-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 4TPKw11Tjjz58Vn4 for ; Tue, 30 Jan 2024 09:42:41 +0000 (UTC) (envelope-from luca.pizzamiglio@gmail.com) Received: from mail-io1-f45.google.com (mail-io1-f45.google.com [209.85.166.45]) (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 4TPKvz46qgz472R; Tue, 30 Jan 2024 09:42:39 +0000 (UTC) (envelope-from luca.pizzamiglio@gmail.com) Authentication-Results: mx1.freebsd.org; dkim=none; dmarc=fail reason="SPF not aligned (relaxed), No valid DKIM" header.from=freebsd.org (policy=none); spf=pass (mx1.freebsd.org: domain of luca.pizzamiglio@gmail.com designates 209.85.166.45 as permitted sender) smtp.mailfrom=luca.pizzamiglio@gmail.com Received: by mail-io1-f45.google.com with SMTP id ca18e2360f4ac-7bed8faf6ebso132198039f.2; Tue, 30 Jan 2024 01:42:39 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1706607757; x=1707212557; 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=5mc46pwGMcJbldxZK4HnPjvx/B6cLH9ugtmTrEum4jk=; b=Oko9DggRqdxaccx6rebLKrE2k9jdAeB+cv+mOLL82k7PnqN4MX+Clf3qSPb+wugSHE OJyvP039E1N8ljiUIBvDtIXYKwrzv6kFrD9l8MGzH03jZcs3nXL+trXNoPS+GbJVgjzF RbVIOsqPcznpW7Yd0eMXxSds1AABbmIJQ/i1+6b3WuY4SR6vJQUHFhcyifaaaGufTfOh io/FMcSrlXxTUdJQD53HteAC2MKpp0e+wHIjNrGoReaaFK9DbiBgwWoOClrldr2Y9P0U z6YxaqFLPFu6UDPk+UhZjbB4Hq0JcNJiOq9cvcVYDHcGJ690goOAW0xCdtIPNEiG0k7B ewhA== X-Gm-Message-State: AOJu0YyWiEz1043fbH4jFIekxcVhNpLkP1KnRdg4juVpfGqJSxu3jnP4 FD1JRM4jL339klXAnlCgv/qXR+pr3kMcWzUREnEXbZvfUqgjHIaqWiVY7QR5LKY= X-Google-Smtp-Source: AGHT+IHOdGEZHserP9MLyvmg0gy7Stu6XJ6rdwYNTGA2lMaOj9wPTlUYEixCq6rpf82IjZvh/XGusw== X-Received: by 2002:a05:6e02:1d15:b0:362:8bdf:45cc with SMTP id i21-20020a056e021d1500b003628bdf45ccmr9279190ila.17.1706607757065; Tue, 30 Jan 2024 01:42:37 -0800 (PST) Received: from mail-il1-f175.google.com (mail-il1-f175.google.com. [209.85.166.175]) by smtp.gmail.com with ESMTPSA id k2-20020a92c9c2000000b00363789a0b23sm1845923ilq.6.2024.01.30.01.42.36 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Tue, 30 Jan 2024 01:42:36 -0800 (PST) Received: by mail-il1-f175.google.com with SMTP id e9e14a558f8ab-363890fe589so3585585ab.0; Tue, 30 Jan 2024 01:42:36 -0800 (PST) X-Received: by 2002:a05:6e02:f46:b0:363:812d:d6a3 with SMTP id y6-20020a056e020f4600b00363812dd6a3mr3963416ilj.20.1706607756562; Tue, 30 Jan 2024 01:42:36 -0800 (PST) List-Id: Porting software to FreeBSD List-Archive: https://lists.freebsd.org/archives/freebsd-ports List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-ports@freebsd.org X-BeenThere: freebsd-ports@freebsd.org MIME-Version: 1.0 References: <609374cf-7f1f-4643-8379-f368b23ccb09@freebsd.org> <1e27bce44f2ba85f0097fbc6aba1dac1@Leidinger.net> In-Reply-To: <1e27bce44f2ba85f0097fbc6aba1dac1@Leidinger.net> From: Luca Pizzamiglio Date: Tue, 30 Jan 2024 10:42:20 +0100 X-Gmail-Original-Message-ID: Message-ID: Subject: Re: This is going to break port building without poudriere! To: Alexander Leidinger Cc: FreeBSD ports , portmgr , FreeBSD Core Team Content-Type: multipart/alternative; boundary="00000000000019db290610269536" X-Spamd-Bar: / X-Spamd-Result: default: False [-0.92 / 15.00]; NEURAL_HAM_LONG(-1.00)[-1.000]; NEURAL_HAM_MEDIUM(-1.00)[-1.000]; NEURAL_SPAM_SHORT(0.98)[0.983]; FORGED_SENDER(0.30)[pizzamig@freebsd.org,lucapizzamiglio@gmail.com]; R_SPF_ALLOW(-0.20)[+ip4:209.85.128.0/17]; DMARC_POLICY_SOFTFAIL(0.10)[freebsd.org : SPF not aligned (relaxed), No valid DKIM,none]; MIME_GOOD(-0.10)[multipart/alternative,text/plain]; RCVD_TLS_LAST(0.00)[]; TO_DN_ALL(0.00)[]; SUBJECT_ENDS_EXCLAIM(0.00)[]; RCVD_COUNT_THREE(0.00)[3]; TAGGED_FROM(0.00)[]; MIME_TRACE(0.00)[0:+,1:+,2:~]; ARC_NA(0.00)[]; FROM_HAS_DN(0.00)[]; MISSING_XM_UA(0.00)[]; FREEMAIL_ENVFROM(0.00)[gmail.com]; MLMMJ_DEST(0.00)[freebsd-ports@freebsd.org]; TO_MATCH_ENVRCPT_SOME(0.00)[]; FROM_NEQ_ENVFROM(0.00)[pizzamig@freebsd.org,lucapizzamiglio@gmail.com]; RCPT_COUNT_THREE(0.00)[4]; R_DKIM_NA(0.00)[]; RCVD_VIA_SMTP_AUTH(0.00)[]; RWL_MAILSPIKE_POSSIBLE(0.00)[209.85.166.45:from]; ASN(0.00)[asn:15169, ipnet:209.85.128.0/17, country:US]; RCVD_IN_DNSWL_NONE(0.00)[209.85.166.45:from,209.85.166.175:received] X-Rspamd-Queue-Id: 4TPKvz46qgz472R --00000000000019db290610269536 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Hi Alexander. Subpackage modularization of existing ports (i.e. qt6-tools) provides benefits to package users/builders: smaller dependency footprint, smaller usage on disk (useful for embedded systems), smaller jails. There are no benefits nor regressions for port builders for this specific use case. On the other hand, moving master/slave ports to subpackages comes with the cost of losing the ability to build the slave ports independently. For package users there is no change and some benefit for package builders. The issue can be mitigated by introducing options to select which subpackage to build (available for make install as well), but, still, a single subpackage cannot be built independently. This limitation *can* be unacceptable in some cases. For example, bofh@, the php maintainer, considers subpackages not the way to go, so the master/slave approach will stay. We introduced subpackages in the framework to explore all use cases, by trying and testing its adoption. By doing so we have already identified some issues (i.e. USES is not subpackage-aware yet) and interesting new use cases (subpackage with debug symbols). As per master/slave merge use case, we will let the maintainers decide if they want to move forward with subpackage adoptions, knowing the regression for port builders, but we won't push them in this direction. Best regards, Luca On Mon, Jan 29, 2024 at 10:04=E2=80=AFAM Alexander Leidinger < Alexander@leidinger.net> wrote: > Am 2024-01-27 16:59, schrieb Luca Pizzamiglio: > > > Hi Stefan. > > > > Let's start from the beginning, as it seems that things are not clear. > > > > Subpackages is a feature to create multiple packages from one build > > Those subpackages can depend on the main package. > > The main package cannot depend on any subpackages. > > This limits the cases where subpackages can be applied. The main > > package MUST be independent from its subpackages. Subpackages can only > > add features (like a plugin). > > To recall your NLS example (ref > > https://reviews.freebsd.org/D16457#715443): this is not a use-case for > > subpackages. If the main program/library needs to be compiled > > differently with or without NLS, this is not viable for subpackages. > > If a port needs to be built multiple times to create different > > subpackages, this is not a viable case for subpackages. > > A good candidate is qt6-tools: this port contains multiple tools > > (designer, linguist, help, and so on). Those tools could be put in > > different subpackages. > > > > I hope this explanation helps to clarify and address some of your > > concerns. > > As I read this, lang/php is the best example of a port where subpackages > has a benefit (in the sense it matches your description above to the > letter, the main port independent from the subpacakges, and what can be > build as subpackages is a plugin/extension). > > > OPTIONS and SUBPACKAGES > > Do we have to convert OPTIONS to SUBPACKAGES? No. > > Can a SUBPACKAGE be built only if an OPTION is enabled? Yes. > > The only viable use cases for SUBPACKAGES being enabled/disabled by > > OPTIONS is limited to those portions of the port that do not affect the > > main package. > > Examples are: additional libraries, additional data files, and so on. > > > > Consolidate master/slave ports in one bigger ports > > About this topic, I guess your concerns are mainly related to potential > > explosion of build time of the consolidated ports. > > This is a justified concern. > > In those cases, we are suggesting to convert slave ports in SUBPACKAGES > > enabled via OPTIONS. > > This will allow port builders to configure the bigger ports to not > > build all SUBPACKAGES, but only the needed ones. This should restore > > the previous build time. > > > > However, as for the php case, the maintainer is going to evaluate if > > the consolidation makes sense or not. > > If a consolidation is going to result more problematic than beneficial, > > it can be reverted and subpackages not adopted for the use case. > > If I understand the sum of all the above correct, you suggest to remove > slave ports and to use subpackages instead (where this makes sense in > terms of the current implementation of subpackages). Or worded > differently to the same effect (as I only care about the effect and not > the intention), when someone converts a port to subpackages, the > corresponding slave packages shall be removed (or for new ports: slave > ports shall not be introduced in this case). > > Removing slave ports means we can not depend upon specific parts anymore > when installing from ports, as the subpackages can not be targeted for > install directly and my example of a subpackages aware php results in > security implications of to much being installed and active if installed > via make install in /usr/ports/something/with_webinterface. -> best > example of lang/php to use subpacakges is the best example of why not to > use subpackages / shows what is a regression in the features we provide > in our ports collection. > > While qt6-tools may be a good example where subpackages makes sense, we > can not depend on subpacakges for "make install", and as if the port > would be converted to have subpackages but no slave ports are > introduced, pkg install and make install would differ in the amount of > installed files. > > > For port builders > > > > Port builders can experience longer build times in the future, as > > master/slave ports could be consolidated in one single larger ports. > > If this is the case, the larger ports should provide OPTIONS to not > > build unneeded subpackages. > > If no OPTION is available, please work with the maintainer to introduce > > one. > > I fail to see the benefit: > We either lose the possibility to target parts of a package (when slave > ports are removed / not introduced) on make install (with a similar > amount of build time for the ports tree as it is right now), or get > higher build times for the package builders. In both cases we do not > gain something significant. > > If we want to keep the (useful in some cases) feature to install from > ports (there is the case of py39-rpds-py failing to build in my > poudriere which I tried to debug with the author of py-maturin due to a > runtime issue in maturin, which shows up in my the cross build on > amd64-intel for amd64-athlon64... which in the end leads me to build > py-rpds-py on the target machine from ports), the current implementation > of subpackages has to come with the requirement to create slave ports > for each subpackage. > > That's my concern, and that's the reason why I have the opinion, that > portmgr has to keep the lock on subpackages and reject any subpackage > which don't come with a slave port. > > I would be OK to lift this restriction, when the current implementation > is changed to be able to only install the files of a subpacakge on make > install (an implementation could be to require "make install > TARGET_SUBPACAKGES=3Dsub1,sub2,sub3" or "make install-subpackage1 > install-subpacakge2"... as long as recursive dependencies are handled > according to this requirement, those people designing, implementing and > reviewing this can argue about such details). > > Keeping the current implementation (with the restriction of always > introducing slave packages for subpackages) would need a way to denote > that a slave port covers a specific subpackage which would allow package > builders to skip those slave ports (and the subpacakges would need to > have the same package name as the slave port, no idea if this has a > technical disadvantage in terms of having 2 different origins for the > same package name, but it surely would be confusing for people at first > look). > > TLDR: for the use cases you specified in the beginning, I do not see a > benefit, only drawbacks. Can you please provide an example of a benefit > I fail to see (yes, more modularity for qt6-tools may be beneficial for > some people, but the cost/benefit between qt6-tools (something which we > don't provide right now) and "make install" (what we provide right now) > or "build time reduction for package builders" (which would have a > benefit for a lot of use cases) is in my books much more in the > direction of "make install" and "build time reduction" than towards the > modularization of qt6-tools)? > > Bye, > Alexander. > > -- > http://www.Leidinger.net Alexander@Leidinger.net: PGP 0x8F31830F9F2772BF > http://www.FreeBSD.org netchild@FreeBSD.org : PGP 0x8F31830F9F2772BF > --00000000000019db290610269536 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Hi Alexander.

Subpackage mod= ularization of existing ports (i.e. qt6-tools) provides benefits to package= users/builders: smaller dependency footprint, smaller usage on disk (usefu= l for embedded systems), smaller jails. There are no benefits nor regressio= ns for port builders for this specific use case.

O= n the other hand, moving master/slave ports to subpackages comes with the c= ost of losing the ability to build the slave ports independently. For packa= ge users there is no change and some benefit for package builders.
The issue can be mitigated by introducing options to select which sub= package to build (available for make install as well), but, still, a single= subpackage cannot be built independently.
This limitation can be unacceptable in some cases. For example, bofh@, the php maintai= ner, considers subpackages not the way to go, so the master/slave approach = will stay.

We introduced subpackages in the fr= amework to explore all use cases, by trying and testing its adoption.
By doing so we have already identified some issues (i.e. USES is n= ot subpackage-aware yet) and interesting new use cases (subpackage with deb= ug symbols).
As per master/slave merge use case, we will let the = maintainers decide if they want to move forward with subpackage adoptions, = knowing the regression for port builders, but we won't push them in thi= s direction.

Best regards,
Luca
<= /div>


On Mon, Jan 29, 2024 at 10:04=E2=80=AFAM Alexander Leid= inger <Alexander@leidinger.ne= t> wrote:
Am 2024-01-27 16:59, schrieb Luca Pizzamiglio:

> Hi Stefan.
>
> Let's start from the beginning, as it seems that things are not cl= ear.
>
> Subpackages is a feature to create multiple packages from one build > Those subpackages can depend on the main package.
> The main package cannot depend on any subpackages.
> This limits the cases where subpackages can be applied. The main
> package MUST be independent from its subpackages. Subpackages can only=
> add features (like a plugin).
> To recall your NLS example (ref
> https://reviews.freebsd.org/D16457#715443): this i= s not a use-case for
> subpackages. If the main program/library needs to be compiled
> differently with or without NLS, this is not viable for subpackages. > If a port needs to be built multiple times to create different
> subpackages, this is not a viable case for subpackages.
> A good candidate is qt6-tools: this port contains multiple tools
> (designer, linguist, help, and so on). Those tools could be put in > different subpackages.
>
> I hope this explanation helps to clarify and address some of your
> concerns.

As I read this, lang/php is the best example of a port where subpackages has a benefit (in the sense it matches your description above to the
letter, the main port independent from the subpacakges, and what can be build as subpackages is a plugin/extension).

> OPTIONS and SUBPACKAGES
> Do we have to convert OPTIONS to SUBPACKAGES? No.
> Can a SUBPACKAGE be built only if an OPTION is enabled? Yes.
> The only viable use cases for SUBPACKAGES being enabled/disabled by > OPTIONS is limited to those portions of the port that do not affect th= e
> main package.
> Examples are: additional libraries, additional data files, and so on.<= br> >
> Consolidate master/slave ports in one bigger ports
> About this topic, I guess your concerns are mainly related to potentia= l
> explosion of build time of the consolidated ports.
> This is a justified concern.
> In those cases, we are suggesting to convert slave ports in SUBPACKAGE= S
> enabled via OPTIONS.
> This will allow port builders to configure the bigger ports to not > build all SUBPACKAGES, but only the needed ones. This should restore <= br> > the previous build time.
>
> However, as for the php case, the maintainer is going to evaluate if <= br> > the consolidation makes sense or not.
> If a consolidation is going to result more problematic than beneficial= ,
> it can be reverted and subpackages not adopted for the use case.

If I understand the sum of all the above correct, you suggest to remove slave ports and to use subpackages instead (where this makes sense in
terms of the current implementation of subpackages). Or worded
differently to the same effect (as I only care about the effect and not the intention), when someone converts a port to subpackages, the
corresponding slave packages shall be removed (or for new ports: slave
ports shall not be introduced in this case).

Removing slave ports means we can not depend upon specific parts anymore when installing from ports, as the subpackages can not be targeted for
install directly and my example of a subpackages aware php results in
security implications of to much being installed and active if installed via make install in /usr/ports/something/with_webinterface. -> best
example of lang/php to use subpacakges is the best example of why not to use subpackages / shows what is a regression in the features we provide in our ports collection.

While qt6-tools may be a good example where subpackages makes sense, we can not depend on subpacakges for "make install", and as if the p= ort
would be converted to have subpackages but no slave ports are
introduced, pkg install and make install would differ in the amount of
installed files.

> For port builders
>
> Port builders can experience longer build times in the future, as
> master/slave ports could be consolidated in one single larger ports. > If this is the case, the larger ports should provide OPTIONS to not > build unneeded subpackages.
> If no OPTION is available, please work with the maintainer to introduc= e
> one.

I fail to see the benefit:
We either lose the possibility to target parts of a package (when slave ports are removed / not introduced) on make install (with a similar
amount of build time for the ports tree as it is right now), or get
higher build times for the package builders. In both cases we do not
gain something significant.

If we want to keep the (useful in some cases) feature to install from
ports (there is the case of py39-rpds-py failing to build in my
poudriere which I tried to debug with the author of py-maturin due to a runtime issue in maturin, which shows up in my the cross build on
amd64-intel for amd64-athlon64... which in the end leads me to build
py-rpds-py on the target machine from ports), the current implementation of subpackages has to come with the requirement to create slave ports
for each subpackage.

That's my concern, and that's the reason why I have the opinion, th= at
portmgr has to keep the lock on subpackages and reject any subpackage
which don't come with a slave port.

I would be OK to lift this restriction, when the current implementation is changed to be able to only install the files of a subpacakge on make install (an implementation could be to require "make install
TARGET_SUBPACAKGES=3Dsub1,sub2,sub3" or "make install-subpackage1=
install-subpacakge2"... as long as recursive dependencies are handled =
according to this requirement, those people designing, implementing and reviewing this can argue about such details).

Keeping the current implementation (with the restriction of always
introducing slave packages for subpackages) would need a way to denote
that a slave port covers a specific subpackage which would allow package builders to skip those slave ports (and the subpacakges would need to
have the same package name as the slave port, no idea if this has a
technical disadvantage in terms of having 2 different origins for the
same package name, but it surely would be confusing for people at first look).

TLDR: for the use cases you specified in the beginning, I do not see a
benefit, only drawbacks. Can you please provide an example of a benefit I fail to see (yes, more modularity for qt6-tools may be beneficial for some people, but the cost/benefit between qt6-tools (something which we don't provide right now) and "make install" (what we provide = right now)
or "build time reduction for package builders" (which would have = a
benefit for a lot of use cases) is in my books much more in the
direction of "make install" and "build time reduction" = than towards the
modularization of qt6-tools)?

Bye,
Alexander.

--
h= ttp://www.Leidinger.net Alexander@Leidinger.net: PGP 0x8F31830F9F2772BF=
htt= p://www.FreeBSD.org=C2=A0 =C2=A0 netchild@FreeBSD.org=C2=A0 : PGP 0x8F3= 1830F9F2772BF
--00000000000019db290610269536-- From nobody Tue Jan 30 10:30:59 2024 X-Original-To: freebsd-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 4TPM0R5dgpz58ZMm for ; Tue, 30 Jan 2024 10:31:35 +0000 (UTC) (envelope-from Alexander@Leidinger.net) Received: from mailgate.Leidinger.net (mailgate.leidinger.net [IPv6:2a00:1828:2000:313::1:5]) (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-signature ECDSA (P-256) client-digest SHA256) (Client CN "mailgate.leidinger.net", Issuer "R3" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4TPM0Q5trsz4DTK; Tue, 30 Jan 2024 10:31:34 +0000 (UTC) (envelope-from Alexander@Leidinger.net) Authentication-Results: mx1.freebsd.org; none List-Id: Porting software to FreeBSD List-Archive: https://lists.freebsd.org/archives/freebsd-ports List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-ports@freebsd.org X-BeenThere: freebsd-ports@freebsd.org MIME-Version: 1.0 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=leidinger.net; s=outgoing-alex; t=1706610679; 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:references:references; bh=04ZVQRDJ2e6+Ltf9zY61oRcswKab1/Do7ONhVUCniQo=; b=O7RKNtR3S8oMdEd0HAYcVNsMOBh1tcObHJO31p8s62ZIumUawga+uXZvvmeWkBgdQr8qUv rXHp4PG8i4x7dUagiTpako9fvMOPKO9KN+zl8p8W5/xmm8n946bThWy7826rISwXLJXxvq mfvlAOZ+ltv0eZOHI5tVgcZyLMVH9Gp4goJuLjEdgaY6rqgTkzi30bmTa/gogLwzkn+3md VeWC8jwYPNqC7mjtrJXaYhhgrkNjthXPvo5FQevjGbW1TleKutx0drl640u0G3KbfUY5kx rZnII80WX8TANMrWlmIRaqJD+7g1zC00dWAMzAIi2osmix+X3PK2JdumME4WCA== Date: Tue, 30 Jan 2024 11:30:59 +0100 From: Alexander Leidinger To: Luca Pizzamiglio Cc: FreeBSD ports , portmgr , FreeBSD Core Team Subject: Re: This is going to break port building without poudriere! In-Reply-To: References: <609374cf-7f1f-4643-8379-f368b23ccb09@freebsd.org> <1e27bce44f2ba85f0097fbc6aba1dac1@Leidinger.net> Message-ID: <282c88d38f7d9125a3cfad911370aa40@Leidinger.net> Organization: No organization, this is a private message. Content-Type: multipart/signed; protocol="application/pgp-signature"; boundary="=_e41e4721d889efa1a87dcea6662c4eae"; micalg=pgp-sha256 X-Rspamd-Queue-Id: 4TPM0Q5trsz4DTK 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:34240, ipnet:2a00:1828::/32, country:DE] This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --=_e41e4721d889efa1a87dcea6662c4eae Content-Transfer-Encoding: 8bit Content-Type: text/plain; charset=UTF-8; format=flowed Am 2024-01-30 10:42, schrieb Luca Pizzamiglio: > Hi Alexander. > > Subpackage modularization of existing ports (i.e. qt6-tools) provides > benefits to package users/builders: smaller dependency footprint, > smaller usage on disk (useful for embedded systems), smaller jails. > There are no benefits nor regressions for port builders for this > specific use case. Nicely worded. I agree to that. At the same time it is a regression for port builders. Installing from ports is not on par with installing from pkg anymore in this case. What you describe means we can use subpackages only for leaf ports. Ports which are a dependency can not converted to subpackages (in the sense of "no slave port available for the subpackages"). > On the other hand, moving master/slave ports to subpackages comes with > the cost of losing the ability to build the slave ports independently. > For package users there is no change and some benefit for package > builders. > The issue can be mitigated by introducing options to select which > subpackage to build (available for make install as well), but, still, a > single subpackage cannot be built independently. This is not a proper mitigation. I used mail/roundcube and lang/php as a specific example for this particular case where it is not a proper mitigation. > This limitation _can_ be unacceptable in some cases. For example, > bofh@, the php maintainer, considers subpackages not the way to go, so > the master/slave approach will stay. Do you see that you just told that one of the best role models for subpackages according to you previous mail will not use subpackages because of the limitations I highlighted? > We introduced subpackages in the framework to explore all use cases, by > trying and testing its adoption. > By doing so we have already identified some issues (i.e. USES is not > subpackage-aware yet) and interesting new use cases (subpackage with > debug symbols). You are surely aware that you haven't mentioned one of the points I talked about as an issue, don't you? I have not seen any technical answer which shows that my technical description of issues is wrong. I want to make you aware that I understand the responses from you and the others in this thread as: "we do not care about those regressions and do not want to fix them" (I understand it like that because I see no acknowledgement of those issues, just answers which look like a smokescreen and pointing into directions of good faith). If you would acknowledge the technical issues highlighted in this thread (or show evidence that those regressions can not happen) and tell that the adoption of subpackages is monitored to not introduce those regressions I talk about, my understanding of the situation would change. > As per master/slave merge use case, we will let the maintainers decide > if they want to move forward with subpackage adoptions, knowing the > regression for port builders, but we won't push them in this direction. I consider it unfortunate that you describe it like that. I was hoping you would tell that portmgr will prevent the removal of slave packages and enforce the rule of having slave ports for subpackages aware ports to prevent regressions for users which install from ports (until the technical valid issues I have pointed out are resolved -- and they can be fixed, a first step would be to make the names of subpackages match normal packages names = replacing the '~' in the name with a '-' ASAP to prevent churn later). Note, in src some big discussion like this of having several committers identify regressions and no immediate fix would lead to a backout until it is fixed. I do not ask for a backout of this, but I ask for a strong lock/policy by portmgr on the subpackages feature like I already described in my previous mails (until the regressions the use of subpackages would create are fixed). This would allow for more experimentation by a lot of people without the need to patch the ports tree and without introducing regressions for a simple "make install" of ports with a lot of dependencies. Bye, Alexander. > Best regards, > Luca > > On Mon, Jan 29, 2024 at 10:04 AM Alexander Leidinger > wrote: > >> Am 2024-01-27 16:59, schrieb Luca Pizzamiglio: >> >>> Hi Stefan. >>> >>> Let's start from the beginning, as it seems that things are not >>> clear. >>> >>> Subpackages is a feature to create multiple packages from one build >>> Those subpackages can depend on the main package. >>> The main package cannot depend on any subpackages. >>> This limits the cases where subpackages can be applied. The main >>> package MUST be independent from its subpackages. Subpackages can >>> only >>> add features (like a plugin). >>> To recall your NLS example (ref >>> https://reviews.freebsd.org/D16457#715443): this is not a use-case >>> for >>> subpackages. If the main program/library needs to be compiled >>> differently with or without NLS, this is not viable for subpackages. >>> If a port needs to be built multiple times to create different >>> subpackages, this is not a viable case for subpackages. >>> A good candidate is qt6-tools: this port contains multiple tools >>> (designer, linguist, help, and so on). Those tools could be put in >>> different subpackages. >>> >>> I hope this explanation helps to clarify and address some of your >>> concerns. >> >> As I read this, lang/php is the best example of a port where >> subpackages >> has a benefit (in the sense it matches your description above to the >> letter, the main port independent from the subpacakges, and what can >> be >> build as subpackages is a plugin/extension). >> >>> OPTIONS and SUBPACKAGES >>> Do we have to convert OPTIONS to SUBPACKAGES? No. >>> Can a SUBPACKAGE be built only if an OPTION is enabled? Yes. >>> The only viable use cases for SUBPACKAGES being enabled/disabled by >>> OPTIONS is limited to those portions of the port that do not affect >>> the >>> main package. >>> Examples are: additional libraries, additional data files, and so on. >>> >>> Consolidate master/slave ports in one bigger ports >>> About this topic, I guess your concerns are mainly related to >>> potential >>> explosion of build time of the consolidated ports. >>> This is a justified concern. >>> In those cases, we are suggesting to convert slave ports in >>> SUBPACKAGES >>> enabled via OPTIONS. >>> This will allow port builders to configure the bigger ports to not >>> build all SUBPACKAGES, but only the needed ones. This should restore >>> the previous build time. >>> >>> However, as for the php case, the maintainer is going to evaluate if >>> the consolidation makes sense or not. >>> If a consolidation is going to result more problematic than >>> beneficial, >>> it can be reverted and subpackages not adopted for the use case. >> >> If I understand the sum of all the above correct, you suggest to >> remove >> slave ports and to use subpackages instead (where this makes sense in >> terms of the current implementation of subpackages). Or worded >> differently to the same effect (as I only care about the effect and >> not >> the intention), when someone converts a port to subpackages, the >> corresponding slave packages shall be removed (or for new ports: slave >> ports shall not be introduced in this case). >> >> Removing slave ports means we can not depend upon specific parts >> anymore >> when installing from ports, as the subpackages can not be targeted for >> install directly and my example of a subpackages aware php results in >> security implications of to much being installed and active if >> installed >> via make install in /usr/ports/something/with_webinterface. -> best >> example of lang/php to use subpacakges is the best example of why not >> to >> use subpackages / shows what is a regression in the features we >> provide >> in our ports collection. >> >> While qt6-tools may be a good example where subpackages makes sense, >> we >> can not depend on subpacakges for "make install", and as if the port >> would be converted to have subpackages but no slave ports are >> introduced, pkg install and make install would differ in the amount of >> installed files. >> >>> For port builders >>> >>> Port builders can experience longer build times in the future, as >>> master/slave ports could be consolidated in one single larger ports. >>> If this is the case, the larger ports should provide OPTIONS to not >>> build unneeded subpackages. >>> If no OPTION is available, please work with the maintainer to >>> introduce >>> one. >> >> I fail to see the benefit: >> We either lose the possibility to target parts of a package (when >> slave >> ports are removed / not introduced) on make install (with a similar >> amount of build time for the ports tree as it is right now), or get >> higher build times for the package builders. In both cases we do not >> gain something significant. >> >> If we want to keep the (useful in some cases) feature to install from >> ports (there is the case of py39-rpds-py failing to build in my >> poudriere which I tried to debug with the author of py-maturin due to >> a >> runtime issue in maturin, which shows up in my the cross build on >> amd64-intel for amd64-athlon64... which in the end leads me to build >> py-rpds-py on the target machine from ports), the current >> implementation >> of subpackages has to come with the requirement to create slave ports >> for each subpackage. >> >> That's my concern, and that's the reason why I have the opinion, that >> portmgr has to keep the lock on subpackages and reject any subpackage >> which don't come with a slave port. >> >> I would be OK to lift this restriction, when the current >> implementation >> is changed to be able to only install the files of a subpacakge on >> make >> install (an implementation could be to require "make install >> TARGET_SUBPACAKGES=sub1,sub2,sub3" or "make install-subpackage1 >> install-subpacakge2"... as long as recursive dependencies are handled >> according to this requirement, those people designing, implementing >> and >> reviewing this can argue about such details). >> >> Keeping the current implementation (with the restriction of always >> introducing slave packages for subpackages) would need a way to denote >> that a slave port covers a specific subpackage which would allow >> package >> builders to skip those slave ports (and the subpacakges would need to >> have the same package name as the slave port, no idea if this has a >> technical disadvantage in terms of having 2 different origins for the >> same package name, but it surely would be confusing for people at >> first >> look). >> >> TLDR: for the use cases you specified in the beginning, I do not see a >> benefit, only drawbacks. Can you please provide an example of a >> benefit >> I fail to see (yes, more modularity for qt6-tools may be beneficial >> for >> some people, but the cost/benefit between qt6-tools (something which >> we >> don't provide right now) and "make install" (what we provide right >> now) >> or "build time reduction for package builders" (which would have a >> benefit for a lot of use cases) is in my books much more in the >> direction of "make install" and "build time reduction" than towards >> the >> modularization of qt6-tools)? >> >> Bye, >> Alexander. >> >> -- >> http://www.Leidinger.net Alexander@Leidinger.net: PGP >> 0x8F31830F9F2772BF >> http://www.FreeBSD.org netchild@FreeBSD.org : PGP >> 0x8F31830F9F2772BF -- http://www.Leidinger.net Alexander@Leidinger.net: PGP 0x8F31830F9F2772BF http://www.FreeBSD.org netchild@FreeBSD.org : PGP 0x8F31830F9F2772BF --=_e41e4721d889efa1a87dcea6662c4eae Content-Type: application/pgp-signature; name=signature.asc Content-Disposition: attachment; filename=signature.asc; size=833 Content-Description: OpenPGP digital signature -----BEGIN PGP SIGNATURE----- iQIzBAEBCAAdFiEER9UlYXp1PSd08nWXEg2wmwP42IYFAmW4z/QACgkQEg2wmwP4 2IYXPBAAm25vFFWs/pjN19XvUmsat74xI2DgDN+77M8uTydTSC0fajCPXfht1xhC 8nAZkbjxdQtp4vU6/T4I8b4nvZeL3zQIlS9TfQ70ZXCVzo332hCAJ6kf9j3nXRc7 L5JEMXYmKIvgfRwO89nw12DIs/xL+pnEEx7zKzrlMFNLsbMABddyKOlg5itHhPyi md11jriClX0Esv00rQaw681m/vYTHEG+yT4WFyvqP199z3OBbWmLCXe3krevVKAH iv0VEm6Q9KEjxcFbso80LzmJo1ymIVPt+GGlYYn9TQsWPGzstWXbl/9bet3EuUgv ogP6Ph09tUtmkxHiYibqi1YO7iQreF+2zHtbkgq0oViKX1ns4bZqxfGWfVKZNzR/ PSLHXKmKPJjG6GtXCGEljPEd8thkXRxYQr07GMm/mWNqOZkT9ackqx5EaMpXO4LY qDaaxqjVmrFw8uW83xTagbweqWKdL2AKnp71aEddg+BVp8ZiOaLp5qbAVF9o2ywx IcOc2X2I7qIquzMTsjmFhZXELP99nFxdD3Ljg8d90m5oZ+SAmgz7csLu7fDtJZor JBvxIj+IY+lAWKH3QALBMKAKYF9csPVDDZvhIXkBWdePVn9/jcFfuLuEvTokPDrr shBzfyTQ1sx2AePudPNq5tLSRqgLaeuYvi/a6rFuhldfuJNQ2ik= =n7+X -----END PGP SIGNATURE----- --=_e41e4721d889efa1a87dcea6662c4eae-- From nobody Tue Jan 30 12:24:31 2024 X-Original-To: freebsd-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 4TPPW61YpQz58lhP for ; Tue, 30 Jan 2024 12:24:50 +0000 (UTC) (envelope-from luca.pizzamiglio@gmail.com) Received: from mail-il1-f177.google.com (mail-il1-f177.google.com [209.85.166.177]) (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 4TPPW56X3vz4Tng; Tue, 30 Jan 2024 12:24:49 +0000 (UTC) (envelope-from luca.pizzamiglio@gmail.com) Authentication-Results: mx1.freebsd.org; none Received: by mail-il1-f177.google.com with SMTP id e9e14a558f8ab-363890b20dfso4436655ab.2; Tue, 30 Jan 2024 04:24:49 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1706617488; x=1707222288; 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=fQLe/RFnLqv1/4CY5Brz5bgW4kYvxRxqa9kMSRu/AXA=; b=otOqXg86VzZMaEeoYXOQvgw+nWeavtGtCaXd3GR+HvPhCUBFSZUijdEGslo6FJGpUd hI055PDedU8KODt/gDBV3tP3Y3pnVbpAXzqV+mnU+7RusSsl4kxNFWTUWK9QQZR0QkLJ c8wI9H9FBidcBfdcDmjZcEUyPC8tgiMoI3GvHf6zfV+61svKW+ywmGTU70Wr9Ct2jYap UrFuaKfUDTihODiRd5rXKk2LlIQgp0lCpOcxlcERz7JLypoVgfU0/+AIVxw9vgw1l3lx f+9Q0cnde9kDqfbNLEfZnysU3bP7rQiQ9KUarv25gckxxSgITlBO1zIrxlSswllJTRPU Wb5Q== X-Gm-Message-State: AOJu0YwQw6rvilvpU5ttyZ/2A4hBY+1WXBUwcaItNotwJSHP7yEyMwuS CBP0eSoyMzHVJAUAURAw4S5f0ew4GmdXE6KnTUpzYenhhI18m0FcKM04oFDC4tw= X-Google-Smtp-Source: AGHT+IFhdAsL4oLI7aXfi54YhjOwdp6eZF89kh7wH/I3nIPV2UPN51NkK6z+fuGJpKM3Jd5rQkvhCg== X-Received: by 2002:a92:c54d:0:b0:362:b454:2ad7 with SMTP id a13-20020a92c54d000000b00362b4542ad7mr10625040ilj.3.1706617487963; Tue, 30 Jan 2024 04:24:47 -0800 (PST) Received: from mail-io1-f53.google.com (mail-io1-f53.google.com. [209.85.166.53]) by smtp.gmail.com with ESMTPSA id by17-20020a056e02261100b003619a43268asm1387029ilb.34.2024.01.30.04.24.47 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Tue, 30 Jan 2024 04:24:47 -0800 (PST) Received: by mail-io1-f53.google.com with SMTP id ca18e2360f4ac-7bade847536so168856239f.0; Tue, 30 Jan 2024 04:24:47 -0800 (PST) X-Received: by 2002:a92:cb4d:0:b0:363:7bc5:727b with SMTP id f13-20020a92cb4d000000b003637bc5727bmr6026114ilq.26.1706617487584; Tue, 30 Jan 2024 04:24:47 -0800 (PST) List-Id: Porting software to FreeBSD List-Archive: https://lists.freebsd.org/archives/freebsd-ports List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-ports@freebsd.org X-BeenThere: freebsd-ports@freebsd.org MIME-Version: 1.0 References: <609374cf-7f1f-4643-8379-f368b23ccb09@freebsd.org> <1e27bce44f2ba85f0097fbc6aba1dac1@Leidinger.net> <282c88d38f7d9125a3cfad911370aa40@Leidinger.net> In-Reply-To: <282c88d38f7d9125a3cfad911370aa40@Leidinger.net> From: Luca Pizzamiglio Date: Tue, 30 Jan 2024 13:24:31 +0100 X-Gmail-Original-Message-ID: Message-ID: Subject: Re: This is going to break port building without poudriere! To: Alexander Leidinger Cc: FreeBSD ports , portmgr , FreeBSD Core Team Content-Type: multipart/alternative; boundary="0000000000001d7836061028d9b7" X-Rspamd-Queue-Id: 4TPPW56X3vz4Tng 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)[]; TAGGED_FROM(0.00)[]; ASN(0.00)[asn:15169, ipnet:209.85.128.0/17, country:US] --0000000000001d7836061028d9b7 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Hi Alexander, On Tue, Jan 30, 2024 at 11:31=E2=80=AFAM Alexander Leidinger < Alexander@leidinger.net> wrote: > Am 2024-01-30 10:42, schrieb Luca Pizzamiglio: > > > Hi Alexander. > > > > Subpackage modularization of existing ports (i.e. qt6-tools) provides > > benefits to package users/builders: smaller dependency footprint, > > smaller usage on disk (useful for embedded systems), smaller jails. > > There are no benefits nor regressions for port builders for this > > specific use case. > > Nicely worded. I agree to that. At the same time it is a regression for > port builders. Installing from ports is not on par with installing from > pkg anymore in this case. What you describe means we can use subpackages > only for leaf ports. Ports which are a dependency can not converted to > subpackages (in the sense of "no slave port available for the > subpackages"). > > I disagree that this is regression, but I agree that it's an unexpected change. Installing from ports can install more than installing from pkg. I don't call it a regression, as it doesn't introduce bugs, ports can be successfully built as before. However, it introduces a divergence that requires more attention. > On the other hand, moving master/slave ports to subpackages comes with > > the cost of losing the ability to build the slave ports independently. > > For package users there is no change and some benefit for package > > builders. > > The issue can be mitigated by introducing options to select which > > subpackage to build (available for make install as well), but, still, a > > single subpackage cannot be built independently. > > This is not a proper mitigation. I used mail/roundcube and lang/php as a > specific example for this particular case where it is not a proper > mitigation. > It's a mitigation, as you can reduce what you need to build, but it's not a solution and it doesn't fix the breaking change. It only offers a way to install less, but no way to install a subpackage only. > > This limitation _can_ be unacceptable in some cases. For example, > > bofh@, the php maintainer, considers subpackages not the way to go, so > > the master/slave approach will stay. > > Do you see that you just told that one of the best role models for > subpackages according to you previous mail will not use subpackages > because of the limitations I highlighted? > Yes, your arguments contributed to change my opinion on this point. Is this a problem? > > We introduced subpackages in the framework to explore all use cases, by > > trying and testing its adoption. > > By doing so we have already identified some issues (i.e. USES is not > > subpackage-aware yet) and interesting new use cases (subpackage with > > debug symbols). > > You are surely aware that you haven't mentioned one of the points I > talked about as an issue, don't you? I have not seen any technical > answer which shows that my technical description of issues is wrong. I > want to make you aware that I understand the responses from you and the > others in this thread as: "we do not care about those regressions and do > not want to fix them" (I understand it like that because I see no > acknowledgement of those issues, just answers which look like a > smokescreen and pointing into directions of good faith). If you would > acknowledge the technical issues highlighted in this thread (or show > evidence that those regressions can not happen) and tell that the > adoption of subpackages is monitored to not introduce those regressions > I talk about, my understanding of the situation would change. > So you are saying that my answers are "smokescreen and pointing into directions of good faith". Am I trying to deceive you? Are you assuming that I have an ill intent that needs to be masked? Those seem serious accusations and they trouble me. As per: "we don't care about those regressions and do not want to fix them"= . I've already acknowledged that subpackages are going to introduce a breaking change. It's possible to have different outcomes if you use packages and ports. We are going to have a portmgr meeting soon and we will see how to proceed. The solutions you propose (subpackge+slave port) don't make any sense to me, I would prefer to focus on a long term solution. Technically, it should be possible to install a portion of a port. It's more difficult to build only a part of a port, but this aspect is less relevant. > As per master/slave merge use case, we will let the maintainers decide > > if they want to move forward with subpackage adoptions, knowing the > > regression for port builders, but we won't push them in this direction. > > I consider it unfortunate that you describe it like that. I was hoping > you would tell that portmgr will prevent the removal of slave packages > and enforce the rule of having slave ports for subpackages aware ports > to prevent regressions for users which install from ports (until the > technical valid issues I have pointed out are resolved -- and they can > be fixed, a first step would be to make the names of subpackages match > normal packages names =3D replacing the '~' in the name with a '-' ASAP t= o > prevent churn later). > > Note, in src some big discussion like this of having several committers > identify regressions and no immediate fix would lead to a backout until > it is fixed. I do not ask for a backout of this, but I ask for a strong > lock/policy by portmgr on the subpackages feature like I already > described in my previous mails (until the regressions the use of > subpackages would create are fixed). This would allow for more > experimentation by a lot of people without the need to patch the ports > tree and without introducing regressions for a simple "make install" of > ports with a lot of dependencies. > Are you asking to completely block the introduction of subpackages? A complete block seems excessive to me, but some additional restriction can be considered. In any case, an update on the subpackage topic needs to be shared in the next few days. Best regards, Luca > > Bye, > Alexander. > > > Best regards, > > Luca > > > > On Mon, Jan 29, 2024 at 10:04=E2=80=AFAM Alexander Leidinger > > wrote: > > > >> Am 2024-01-27 16:59, schrieb Luca Pizzamiglio: > >> > >>> Hi Stefan. > >>> > >>> Let's start from the beginning, as it seems that things are not > >>> clear. > >>> > >>> Subpackages is a feature to create multiple packages from one build > >>> Those subpackages can depend on the main package. > >>> The main package cannot depend on any subpackages. > >>> This limits the cases where subpackages can be applied. The main > >>> package MUST be independent from its subpackages. Subpackages can > >>> only > >>> add features (like a plugin). > >>> To recall your NLS example (ref > >>> https://reviews.freebsd.org/D16457#715443): this is not a use-case > >>> for > >>> subpackages. If the main program/library needs to be compiled > >>> differently with or without NLS, this is not viable for subpackages. > >>> If a port needs to be built multiple times to create different > >>> subpackages, this is not a viable case for subpackages. > >>> A good candidate is qt6-tools: this port contains multiple tools > >>> (designer, linguist, help, and so on). Those tools could be put in > >>> different subpackages. > >>> > >>> I hope this explanation helps to clarify and address some of your > >>> concerns. > >> > >> As I read this, lang/php is the best example of a port where > >> subpackages > >> has a benefit (in the sense it matches your description above to the > >> letter, the main port independent from the subpacakges, and what can > >> be > >> build as subpackages is a plugin/extension). > >> > >>> OPTIONS and SUBPACKAGES > >>> Do we have to convert OPTIONS to SUBPACKAGES? No. > >>> Can a SUBPACKAGE be built only if an OPTION is enabled? Yes. > >>> The only viable use cases for SUBPACKAGES being enabled/disabled by > >>> OPTIONS is limited to those portions of the port that do not affect > >>> the > >>> main package. > >>> Examples are: additional libraries, additional data files, and so on. > >>> > >>> Consolidate master/slave ports in one bigger ports > >>> About this topic, I guess your concerns are mainly related to > >>> potential > >>> explosion of build time of the consolidated ports. > >>> This is a justified concern. > >>> In those cases, we are suggesting to convert slave ports in > >>> SUBPACKAGES > >>> enabled via OPTIONS. > >>> This will allow port builders to configure the bigger ports to not > >>> build all SUBPACKAGES, but only the needed ones. This should restore > >>> the previous build time. > >>> > >>> However, as for the php case, the maintainer is going to evaluate if > >>> the consolidation makes sense or not. > >>> If a consolidation is going to result more problematic than > >>> beneficial, > >>> it can be reverted and subpackages not adopted for the use case. > >> > >> If I understand the sum of all the above correct, you suggest to > >> remove > >> slave ports and to use subpackages instead (where this makes sense in > >> terms of the current implementation of subpackages). Or worded > >> differently to the same effect (as I only care about the effect and > >> not > >> the intention), when someone converts a port to subpackages, the > >> corresponding slave packages shall be removed (or for new ports: slave > >> ports shall not be introduced in this case). > >> > >> Removing slave ports means we can not depend upon specific parts > >> anymore > >> when installing from ports, as the subpackages can not be targeted for > >> install directly and my example of a subpackages aware php results in > >> security implications of to much being installed and active if > >> installed > >> via make install in /usr/ports/something/with_webinterface. -> best > >> example of lang/php to use subpacakges is the best example of why not > >> to > >> use subpackages / shows what is a regression in the features we > >> provide > >> in our ports collection. > >> > >> While qt6-tools may be a good example where subpackages makes sense, > >> we > >> can not depend on subpacakges for "make install", and as if the port > >> would be converted to have subpackages but no slave ports are > >> introduced, pkg install and make install would differ in the amount of > >> installed files. > >> > >>> For port builders > >>> > >>> Port builders can experience longer build times in the future, as > >>> master/slave ports could be consolidated in one single larger ports. > >>> If this is the case, the larger ports should provide OPTIONS to not > >>> build unneeded subpackages. > >>> If no OPTION is available, please work with the maintainer to > >>> introduce > >>> one. > >> > >> I fail to see the benefit: > >> We either lose the possibility to target parts of a package (when > >> slave > >> ports are removed / not introduced) on make install (with a similar > >> amount of build time for the ports tree as it is right now), or get > >> higher build times for the package builders. In both cases we do not > >> gain something significant. > >> > >> If we want to keep the (useful in some cases) feature to install from > >> ports (there is the case of py39-rpds-py failing to build in my > >> poudriere which I tried to debug with the author of py-maturin due to > >> a > >> runtime issue in maturin, which shows up in my the cross build on > >> amd64-intel for amd64-athlon64... which in the end leads me to build > >> py-rpds-py on the target machine from ports), the current > >> implementation > >> of subpackages has to come with the requirement to create slave ports > >> for each subpackage. > >> > >> That's my concern, and that's the reason why I have the opinion, that > >> portmgr has to keep the lock on subpackages and reject any subpackage > >> which don't come with a slave port. > >> > >> I would be OK to lift this restriction, when the current > >> implementation > >> is changed to be able to only install the files of a subpacakge on > >> make > >> install (an implementation could be to require "make install > >> TARGET_SUBPACAKGES=3Dsub1,sub2,sub3" or "make install-subpackage1 > >> install-subpacakge2"... as long as recursive dependencies are handled > >> according to this requirement, those people designing, implementing > >> and > >> reviewing this can argue about such details). > >> > >> Keeping the current implementation (with the restriction of always > >> introducing slave packages for subpackages) would need a way to denote > >> that a slave port covers a specific subpackage which would allow > >> package > >> builders to skip those slave ports (and the subpacakges would need to > >> have the same package name as the slave port, no idea if this has a > >> technical disadvantage in terms of having 2 different origins for the > >> same package name, but it surely would be confusing for people at > >> first > >> look). > >> > >> TLDR: for the use cases you specified in the beginning, I do not see a > >> benefit, only drawbacks. Can you please provide an example of a > >> benefit > >> I fail to see (yes, more modularity for qt6-tools may be beneficial > >> for > >> some people, but the cost/benefit between qt6-tools (something which > >> we > >> don't provide right now) and "make install" (what we provide right > >> now) > >> or "build time reduction for package builders" (which would have a > >> benefit for a lot of use cases) is in my books much more in the > >> direction of "make install" and "build time reduction" than towards > >> the > >> modularization of qt6-tools)? > >> > >> Bye, > >> Alexander. > >> > >> -- > >> http://www.Leidinger.net Alexander@Leidinger.net: PGP > >> 0x8F31830F9F2772BF > >> http://www.FreeBSD.org netchild@FreeBSD.org : PGP > >> 0x8F31830F9F2772BF > > > -- > http://www.Leidinger.net Alexander@Leidinger.net: PGP 0x8F31830F9F2772BF > http://www.FreeBSD.org netchild@FreeBSD.org : PGP 0x8F31830F9F2772BF > --0000000000001d7836061028d9b7 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Hi Alexander,

On Tue, Jan 30, 2024 at 11:31=E2=80= =AFAM Alexander Leidinger <Al= exander@leidinger.net> wrote:
Am 2024-01-30 10:42, schrieb Luca Pizzamiglio:

> Hi Alexander.
>
> Subpackage modularization of existing ports (i.e. qt6-tools) provides =
> benefits to package users/builders: smaller dependency footprint,
> smaller usage on disk (useful for embedded systems), smaller jails. > There are no benefits nor regressions for port builders for this
> specific use case.

Nicely worded. I agree to that. At the same time it is a regression for port builders. Installing from ports is not on par with installing from pkg anymore in this case. What you describe means we can use subpackages only for leaf ports. Ports which are a dependency can not converted to
subpackages (in the sense of "no slave port available for the
subpackages").

I disagree that this is regression, but I agree that = it's an unexpected change.
Installing from ports can inst= all more than installing from pkg.
I don't call it a regressi= on, as it doesn't introduce bugs, ports can be successfully built as be= fore.
However, it introduces a divergence that requires more attention.<= br>

> On the other hand, moving master/slave ports to subpackages comes with=
> the cost of losing the ability to build the slave ports independently.=
> For package users there is no change and some benefit for package
> builders.
> The issue can be mitigated by introducing options to select which
> subpackage to build (available for make install as well), but, still, = a
> single subpackage cannot be built independently.

This is not a proper mitigation. I used mail/roundcube and lang/php as a specific example for this particular case where it is not a proper
mitigation.
It's a mitigation, as you can reduce w= hat you need to build, but it's not a solution and it doesn't fix t= he breaking change.
It only offers a way to install less, but no = way to install a subpackage only.
=C2=A0
> This limitation _can_ be unacceptable in some cases. For example,
> bofh@, the php maintainer, considers subpackages not the way to go, so=
> the master/slave approach will stay.

Do you see that you just told that one of the best role models for
subpackages according to you previous mail will not use subpackages
because of the limitations I highlighted?
Yes, your ar= guments contributed to change my opinion on this point.
Is this a = problem?
=C2=A0
> We introduced subpackages in the framework to explore all use cases, b= y
> trying and testing its adoption.
> By doing so we have already identified some issues (i.e. USES is not <= br> > subpackage-aware yet) and interesting new use cases (subpackage with <= br> > debug symbols).

You are surely aware that you haven't mentioned one of the points I talked about as an issue, don't you? I have not seen any technical
answer which shows that my technical description of issues is wrong. I
want to make you aware that I understand the responses from you and the others in this thread as: "we do not care about those regressions and = do
not want to fix them" (I understand it like that because I see no
acknowledgement of those issues, just answers which look like a
smokescreen and pointing into directions of good faith). If you would
acknowledge the technical issues highlighted in this thread (or show
evidence that those regressions can not happen) and tell that the
adoption of subpackages is monitored to not introduce those regressions I talk about, my understanding of the situation would change.

So you are saying that my answers are "smokescr= een and pointing into directions of good faith".
Am I trying= to deceive you? Are you assuming that I have an ill intent that needs to b= e masked?
Those seem serious accusations and they trouble me.

As per: "we don't care about those regressions an= d do not want to fix them".
I've a= lready acknowledged that subpackages are going to introduce a breaking chan= ge.
It's possible to have different out= comes if you use packages and ports.

We are going to have a portmgr meeting soon = and we will see how to proceed.
The solutions you propose (subpackge+slave port) don't= make any sense to me, I would prefer to focus on a long term solution.
=
Technically, it should be possible t= o install a portion of a port.
It's mor= e difficult to build only a part of a port, but this aspect is less relevan= t.

> As per master/slave merge use case, we will let the maintainers decide=
> if they want to move forward with subpackage adoptions, knowing the > regression for port builders, but we won't push them in this direc= tion.

I consider it unfortunate that you describe it like that. I was hoping
you would tell that portmgr will prevent the removal of slave packages
and enforce the rule of having slave ports for subpackages aware ports
to prevent regressions for users which install from ports (until the
technical valid issues I have pointed out are resolved -- and they can
be fixed, a first step would be to make the names of subpackages match
normal packages names =3D replacing the '~' in the name with a '= ;-' ASAP to
prevent churn later).

Note, in src some big discussion like this of having several committers identify regressions and no immediate fix would lead to a backout until it is fixed. I do not ask for a backout of this, but I ask for a strong lock/policy by portmgr on the subpackages feature like I already
described in my previous mails (until the regressions the use of
subpackages would create are fixed). This would allow for more
experimentation by a lot of people without the need to patch the ports
tree and without introducing regressions for a simple "make install&qu= ot; of
ports with a lot of dependencies.

Are y= ou asking to completely block the introduction of subpackages?
A compl= ete block seems excessive to me, but some additional restriction can be con= sidered.

In any case, an updat= e on the subpackage topic needs to be shared in the next few days.

Best= regards,
Luca

Bye,
Alexander.

> Best regards,
> Luca
>
> On Mon, Jan 29, 2024 at 10:04=E2=80=AFAM Alexander Leidinger
> <Alexa= nder@leidinger.net> wrote:
>
>> Am 2024-01-27 16:59, schrieb Luca Pizzamiglio:
>>
>>> Hi Stefan.
>>>
>>> Let's start from the beginning, as it seems that things ar= e not
>>> clear.
>>>
>>> Subpackages is a feature to create multiple packages from one = build
>>> Those subpackages can depend on the main package.
>>> The main package cannot depend on any subpackages.
>>> This limits the cases where subpackages can be applied. The ma= in
>>> package MUST be independent from its subpackages. Subpackages = can
>>> only
>>> add features (like a plugin).
>>> To recall your NLS example (ref
>>> https://reviews.freebsd.org/D16457#715443)= : this is not a use-case
>>> for
>>> subpackages. If the main program/library needs to be compiled<= br> >>> differently with or without NLS, this is not viable for subpac= kages.
>>> If a port needs to be built multiple times to create different=
>>> subpackages, this is not a viable case for subpackages.
>>> A good candidate is qt6-tools: this port contains multiple too= ls
>>> (designer, linguist, help, and so on). Those tools could be pu= t in
>>> different subpackages.
>>>
>>> I hope this explanation helps to clarify and address some of y= our
>>> concerns.
>>
>> As I read this, lang/php is the best example of a port where
>> subpackages
>> has a benefit (in the sense it matches your description above to t= he
>> letter, the main port independent from the subpacakges, and what c= an
>> be
>> build as subpackages is a plugin/extension).
>>
>>> OPTIONS and SUBPACKAGES
>>> Do we have to convert OPTIONS to SUBPACKAGES? No.
>>> Can a SUBPACKAGE be built only if an OPTION is enabled? Yes. >>> The only viable use cases for SUBPACKAGES being enabled/disabl= ed by
>>> OPTIONS is limited to those portions of the port that do not a= ffect
>>> the
>>> main package.
>>> Examples are: additional libraries, additional data files, and= so on.
>>>
>>> Consolidate master/slave ports in one bigger ports
>>> About this topic, I guess your concerns are mainly related to =
>>> potential
>>> explosion of build time of the consolidated ports.
>>> This is a justified concern.
>>> In those cases, we are suggesting to convert slave ports in >>> SUBPACKAGES
>>> enabled via OPTIONS.
>>> This will allow port builders to configure the bigger ports to= not
>>> build all SUBPACKAGES, but only the needed ones. This should r= estore
>>> the previous build time.
>>>
>>> However, as for the php case, the maintainer is going to evalu= ate if
>>> the consolidation makes sense or not.
>>> If a consolidation is going to result more problematic than >>> beneficial,
>>> it can be reverted and subpackages not adopted for the use cas= e.
>>
>> If I understand the sum of all the above correct, you suggest to <= br> >> remove
>> slave ports and to use subpackages instead (where this makes sense= in
>> terms of the current implementation of subpackages). Or worded
>> differently to the same effect (as I only care about the effect an= d
>> not
>> the intention), when someone converts a port to subpackages, the >> corresponding slave packages shall be removed (or for new ports: s= lave
>> ports shall not be introduced in this case).
>>
>> Removing slave ports means we can not depend upon specific parts <= br> >> anymore
>> when installing from ports, as the subpackages can not be targeted= for
>> install directly and my example of a subpackages aware php results= in
>> security implications of to much being installed and active if >> installed
>> via make install in /usr/ports/something/with_webinterface. -> = best
>> example of lang/php to use subpacakges is the best example of why = not
>> to
>> use subpackages / shows what is a regression in the features we >> provide
>> in our ports collection.
>>
>> While qt6-tools may be a good example where subpackages makes sens= e,
>> we
>> can not depend on subpacakges for "make install", and as= if the port
>> would be converted to have subpackages but no slave ports are
>> introduced, pkg install and make install would differ in the amoun= t of
>> installed files.
>>
>>> For port builders
>>>
>>> Port builders can experience longer build times in the future,= as
>>> master/slave ports could be consolidated in one single larger = ports.
>>> If this is the case, the larger ports should provide OPTIONS t= o not
>>> build unneeded subpackages.
>>> If no OPTION is available, please work with the maintainer to =
>>> introduce
>>> one.
>>
>> I fail to see the benefit:
>> We either lose the possibility to target parts of a package (when =
>> slave
>> ports are removed / not introduced) on make install (with a simila= r
>> amount of build time for the ports tree as it is right now), or ge= t
>> higher build times for the package builders. In both cases we do n= ot
>> gain something significant.
>>
>> If we want to keep the (useful in some cases) feature to install f= rom
>> ports (there is the case of py39-rpds-py failing to build in my >> poudriere which I tried to debug with the author of py-maturin due= to
>> a
>> runtime issue in maturin, which shows up in my the cross build on<= br> >> amd64-intel for amd64-athlon64... which in the end leads me to bui= ld
>> py-rpds-py on the target machine from ports), the current
>> implementation
>> of subpackages has to come with the requirement to create slave po= rts
>> for each subpackage.
>>
>> That's my concern, and that's the reason why I have the op= inion, that
>> portmgr has to keep the lock on subpackages and reject any subpack= age
>> which don't come with a slave port.
>>
>> I would be OK to lift this restriction, when the current
>> implementation
>> is changed to be able to only install the files of a subpacakge on=
>> make
>> install (an implementation could be to require "make install<= br> >> TARGET_SUBPACAKGES=3Dsub1,sub2,sub3" or "make install-su= bpackage1
>> install-subpacakge2"... as long as recursive dependencies are= handled
>> according to this requirement, those people designing, implementin= g
>> and
>> reviewing this can argue about such details).
>>
>> Keeping the current implementation (with the restriction of always=
>> introducing slave packages for subpackages) would need a way to de= note
>> that a slave port covers a specific subpackage which would allow <= br> >> package
>> builders to skip those slave ports (and the subpacakges would need= to
>> have the same package name as the slave port, no idea if this has = a
>> technical disadvantage in terms of having 2 different origins for = the
>> same package name, but it surely would be confusing for people at =
>> first
>> look).
>>
>> TLDR: for the use cases you specified in the beginning, I do not s= ee a
>> benefit, only drawbacks. Can you please provide an example of a >> benefit
>> I fail to see (yes, more modularity for qt6-tools may be beneficia= l
>> for
>> some people, but the cost/benefit between qt6-tools (something whi= ch
>> we
>> don't provide right now) and "make install" (what we= provide right
>> now)
>> or "build time reduction for package builders" (which wo= uld have a
>> benefit for a lot of use cases) is in my books much more in the >> direction of "make install" and "build time reducti= on" than towards
>> the
>> modularization of qt6-tools)?
>>
>> Bye,
>> Alexander.
>>
>> --
>> http://www.Leidinger.net Alexander@Leidinger.net: PGP
>> 0x8F31830F9F2772BF
>> http://www.FreeBSD.org=C2=A0 =C2=A0 netchild@FreeBSD.org=C2=A0 : = PGP
>> 0x8F31830F9F2772BF


--
h= ttp://www.Leidinger.net Alexander@Leidinger.net: PGP 0x8F31830F9F2772BF=
htt= p://www.FreeBSD.org=C2=A0 =C2=A0 netchild@FreeBSD.org=C2=A0 : PGP 0x8F3= 1830F9F2772BF
--0000000000001d7836061028d9b7-- From nobody Tue Jan 30 13:21:03 2024 X-Original-To: freebsd-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 4TPQn52q0pz58qmb for ; Tue, 30 Jan 2024 13:22:01 +0000 (UTC) (envelope-from Alexander@Leidinger.net) Received: from mailgate.Leidinger.net (bastille.leidinger.net [89.238.82.207]) (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-signature ECDSA (P-256) client-digest SHA256) (Client CN "mailgate.leidinger.net", Issuer "R3" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4TPQn44lx3z4ZQs; Tue, 30 Jan 2024 13:22:00 +0000 (UTC) (envelope-from Alexander@Leidinger.net) Authentication-Results: mx1.freebsd.org; none List-Id: Porting software to FreeBSD List-Archive: https://lists.freebsd.org/archives/freebsd-ports List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-ports@freebsd.org X-BeenThere: freebsd-ports@freebsd.org MIME-Version: 1.0 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=leidinger.net; s=outgoing-alex; t=1706620912; 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:references:references; bh=leIF7ldyCfcVMzttJ/A9Tpod+P6KyZEh7Ttw7057lII=; b=ykftDIbiHyL4Num5VnSnq/wpNVMYc3dawD85hYi0kkdovPvSriOnOSRI3zsfVzwrr3BqUU 0yxxfwsHvdoFz/+wUheBvTT0KL5CZTMruPODvtoMXi48cLDUUIRSBtRfvs7sKF+iQdvhHs Be3NIQ2pmU9elFdcwadRvik41QzHxoBpoR+Xo2op6ubkMBgOcDmv7DxaBEWGmbsF6VgXAu dTJhiNKQPH12Z2BbfiDR+2r/HSKcBiqc4kofAAG1ovkyby0O0UZKWVVCE0LJP6L70az73M sBW49oLNh4BJGNth20/f9dWvaXi5Qx25+zzhzjbaAXp3MDK8y7TgLJrEh/TJHA== Date: Tue, 30 Jan 2024 14:21:03 +0100 From: Alexander Leidinger To: Luca Pizzamiglio Cc: FreeBSD ports , portmgr , FreeBSD Core Team Subject: Re: This is going to break port building without poudriere! In-Reply-To: References: <609374cf-7f1f-4643-8379-f368b23ccb09@freebsd.org> <1e27bce44f2ba85f0097fbc6aba1dac1@Leidinger.net> <282c88d38f7d9125a3cfad911370aa40@Leidinger.net> Message-ID: Organization: No organization, this is a private message. Content-Type: multipart/signed; protocol="application/pgp-signature"; boundary="=_deba9ff91a50bd5416fe042e22d25a98"; micalg=pgp-sha256 X-Rspamd-Queue-Id: 4TPQn44lx3z4ZQs 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:34240, ipnet:89.238.64.0/18, country:DE] This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --=_deba9ff91a50bd5416fe042e22d25a98 Content-Transfer-Encoding: 8bit Content-Type: text/plain; charset=UTF-8; format=flowed Am 2024-01-30 13:24, schrieb Luca Pizzamiglio: > Hi Alexander, > > On Tue, Jan 30, 2024 at 11:31 AM Alexander Leidinger > wrote: > >> Am 2024-01-30 10:42, schrieb Luca Pizzamiglio: >> >>> Hi Alexander. >>> >>> Subpackage modularization of existing ports (i.e. qt6-tools) provides >>> benefits to package users/builders: smaller dependency footprint, >>> smaller usage on disk (useful for embedded systems), smaller jails. >>> There are no benefits nor regressions for port builders for this >>> specific use case. >> >> Nicely worded. I agree to that. At the same time it is a regression >> for >> port builders. Installing from ports is not on par with installing >> from >> pkg anymore in this case. What you describe means we can use >> subpackages >> only for leaf ports. Ports which are a dependency can not converted to >> subpackages (in the sense of "no slave port available for the >> subpackages"). > > I disagree that this is regression, but I agree that it's an unexpected > change. And at the same time you talk about a breaking change in the next part. > Installing from ports can install more than installing from pkg. > I don't call it a regression, as it doesn't introduce bugs, ports can > be successfully built as before. > However, it introduces a divergence that requires more attention. A divergence which requires more attention is a nice way of telling it is a regression. >>> On the other hand, moving master/slave ports to subpackages comes >>> with >>> the cost of losing the ability to build the slave ports >>> independently. >>> For package users there is no change and some benefit for package >>> builders. >>> The issue can be mitigated by introducing options to select which >>> subpackage to build (available for make install as well), but, still, >>> a >>> single subpackage cannot be built independently. >> >> This is not a proper mitigation. I used mail/roundcube and lang/php as >> a >> specific example for this particular case where it is not a proper >> mitigation. > > It's a mitigation, as you can reduce what you need to build, but it's > not a solution and it doesn't fix the breaking change. > It only offers a way to install less, but no way to install a > subpackage only. > >>> This limitation _can_ be unacceptable in some cases. For example, >>> bofh@, the php maintainer, considers subpackages not the way to go, >>> so >>> the master/slave approach will stay. >> >> Do you see that you just told that one of the best role models for >> subpackages according to you previous mail will not use subpackages >> because of the limitations I highlighted? > > Yes, your arguments contributed to change my opinion on this point. Is > this a problem? No. >>> We introduced subpackages in the framework to explore all use cases, >>> by >>> trying and testing its adoption. >>> By doing so we have already identified some issues (i.e. USES is not >>> subpackage-aware yet) and interesting new use cases (subpackage with >>> debug symbols). >> >> You are surely aware that you haven't mentioned one of the points I >> talked about as an issue, don't you? I have not seen any technical >> answer which shows that my technical description of issues is wrong. I >> want to make you aware that I understand the responses from you and >> the >> others in this thread as: "we do not care about those regressions and >> do >> not want to fix them" (I understand it like that because I see no >> acknowledgement of those issues, just answers which look like a >> smokescreen and pointing into directions of good faith). If you would >> acknowledge the technical issues highlighted in this thread (or show >> evidence that those regressions can not happen) and tell that the >> adoption of subpackages is monitored to not introduce those >> regressions >> I talk about, my understanding of the situation would change. > > So you are saying that my answers are "smokescreen and pointing into > directions of good faith". > Am I trying to deceive you? Are you assuming that I have an ill intent > that needs to be masked? > Those seem serious accusations and they trouble me. I do not think you try to deceive me or anyone else. I do not think you have ill intents. When we met some years ago in Essen I got a favorable impression about you (I remember you as smart and nice) and this has not changed (and you can be assured that I'm not angry or similar, and that you can imagine my "voice" in this thread as calm as in my interaction with everyone back then in Essen). What I "accuse" (to pick up one of your words, I rather call it "giving the impression in your answers") you is that you postulate that subpackages as implemented does not create issues or play down the issues when converting master/slave ports to subpackages, or implicitly tell that "make install" is not worth it / something you support / ... and people shall use packages instead (I use packages myself in most cases, but sometimes "make install" is the most pragmatic solution, and then users shall not fall into a trap... "make install" is an asset, not a burden). > As per: "we don't care about those regressions and do not want to fix > them". > I've already acknowledged that subpackages are going to introduce a > breaking change. > It's possible to have different outcomes if you use packages and ports. We always had different outcomes regarding build dependencies. Having those differences is not the point. The point is that this change will cripple the ports collection. Converting a port to make use of subpackages removes the possibility to have fine grained control over what is installed which is exposed to a sensible security context (aka the internet). Yes, sorry, I'm riding on the lang/php example to death... it's a good example. > We are going to have a portmgr meeting soon and we will see how to > proceed. I'm looking forward to the outcome. > The solutions you propose (subpackge+slave port) don't make any sense > to me, I would prefer to focus on a long term solution. It doesn't make sense to me either, but is the only way the current implementation of subpackages will not cripple the functionality of "make install" in the mid-term. I also would prefer a long term solution. Namely making subpackages first class items for pkg (= no different naming -> s/~/-/, and having the origin recorded inside the metadata), and having the possibility to target subpackages for a make install (as a quick idea: introduce "make install TARGET_SUBPACKAGES=a,b,c", have the port build as needed (full or only the subpackage), build the subpackage out of the plist, and only install the subpackage with pkg). > Technically, it should be possible to install a portion of a port. > It's more difficult to build only a part of a port, but this aspect is > less relevant. Only building the subpackage is an optimization problem (for lang/php this is possible, for other ports maybe not), not a problem of a crippled feature. Yes, it would be nice if it is possible (if upstream allows it) to build subpackages, but this is not something I would ask portmgr to policy. But I ask portmgr to policy the security relevant features, as an example "make install" of mail/roundcube (or take any other port which doesn't require lang/php but falls into the same category of security implications). >>> As per master/slave merge use case, we will let the maintainers >>> decide >>> if they want to move forward with subpackage adoptions, knowing the >>> regression for port builders, but we won't push them in this >>> direction. >> >> I consider it unfortunate that you describe it like that. I was hoping >> you would tell that portmgr will prevent the removal of slave packages >> and enforce the rule of having slave ports for subpackages aware ports >> to prevent regressions for users which install from ports (until the >> technical valid issues I have pointed out are resolved -- and they can >> be fixed, a first step would be to make the names of subpackages match >> normal packages names = replacing the '~' in the name with a '-' ASAP >> to >> prevent churn later). >> >> Note, in src some big discussion like this of having several >> committers >> identify regressions and no immediate fix would lead to a backout >> until >> it is fixed. I do not ask for a backout of this, but I ask for a >> strong >> lock/policy by portmgr on the subpackages feature like I already >> described in my previous mails (until the regressions the use of >> subpackages would create are fixed). This would allow for more >> experimentation by a lot of people without the need to patch the ports >> tree and without introducing regressions for a simple "make install" >> of >> ports with a lot of dependencies. > > Are you asking to completely block the introduction of subpackages? A > complete block seems excessive to me, but some additional restriction > can be considered. I ask portmgr to - not accept conversions of existing ports to subpackages which remove slave ports (and as such touches the dependencies of other ports). - not accept the removal of slave ports for existing subpackages. - not accept new ports with subpackages without slave ports to be able to target the subpackages for "make install". All this until the implementation of subpackages is fixed in a way that we can make lang/php a subpackages aware port and do not install more dependencies in "make install" in mail/roundcube. Again, lang/php serves here as an example of a perfect-fit port for subpackages, and at the same time a perfect example of the issues we get on "make install". So no, I do not ask to block it completely. I simply ask to not remove features. I'm aware that this introduces a burden on package building. If those which operate a package building infrastructure want to have some more restrictions because of this, then this is off course at the discretion of them to speak up. Personally I'm willing to take the hit for my poudriere runs, if this allows to improve the subpackages feature in the tree. I additionally suggest to rethink the naming scheme of subpackages (replacing the '~' with a '-' to have the same filename on disk for the slave ports and the corresponding subpackage) before new subpackages aware ports are introduced. In my opinion this facilitates future updates / improvements to the current implementation of subpackages. I'm open to discuss specifics, but I suggest to open a new thread for this... in case there is interest to discuss it. > In any case, an update on the subpackage topic needs to be shared in > the next few days. I'm looking forward to it. I consider subpackages a very nice feature in the general case. I have simply seen some bugs/issues/regressions in the current implementation which make me believe it is not yet ready to let us use it without the above mentioned governance until those issues are fixed. Bye, Alexander. > Best regards, > Luca > >> Bye, >> Alexander. >> >>> Best regards, >>> Luca >>> >>> On Mon, Jan 29, 2024 at 10:04 AM Alexander Leidinger >>> wrote: >>> >>>> Am 2024-01-27 16:59, schrieb Luca Pizzamiglio: >>>> >>>>> Hi Stefan. >>>>> >>>>> Let's start from the beginning, as it seems that things are not >>>>> clear. >>>>> >>>>> Subpackages is a feature to create multiple packages from one build >>>>> Those subpackages can depend on the main package. >>>>> The main package cannot depend on any subpackages. >>>>> This limits the cases where subpackages can be applied. The main >>>>> package MUST be independent from its subpackages. Subpackages can >>>>> only >>>>> add features (like a plugin). >>>>> To recall your NLS example (ref >>>>> https://reviews.freebsd.org/D16457#715443): this is not a use-case >>>>> for >>>>> subpackages. If the main program/library needs to be compiled >>>>> differently with or without NLS, this is not viable for >>>>> subpackages. >>>>> If a port needs to be built multiple times to create different >>>>> subpackages, this is not a viable case for subpackages. >>>>> A good candidate is qt6-tools: this port contains multiple tools >>>>> (designer, linguist, help, and so on). Those tools could be put in >>>>> different subpackages. >>>>> >>>>> I hope this explanation helps to clarify and address some of your >>>>> concerns. >>>> >>>> As I read this, lang/php is the best example of a port where >>>> subpackages >>>> has a benefit (in the sense it matches your description above to the >>>> letter, the main port independent from the subpacakges, and what can >>>> be >>>> build as subpackages is a plugin/extension). >>>> >>>>> OPTIONS and SUBPACKAGES >>>>> Do we have to convert OPTIONS to SUBPACKAGES? No. >>>>> Can a SUBPACKAGE be built only if an OPTION is enabled? Yes. >>>>> The only viable use cases for SUBPACKAGES being enabled/disabled by >>>>> OPTIONS is limited to those portions of the port that do not affect >>>>> the >>>>> main package. >>>>> Examples are: additional libraries, additional data files, and so >>>>> on. >>>>> >>>>> Consolidate master/slave ports in one bigger ports >>>>> About this topic, I guess your concerns are mainly related to >>>>> potential >>>>> explosion of build time of the consolidated ports. >>>>> This is a justified concern. >>>>> In those cases, we are suggesting to convert slave ports in >>>>> SUBPACKAGES >>>>> enabled via OPTIONS. >>>>> This will allow port builders to configure the bigger ports to not >>>>> build all SUBPACKAGES, but only the needed ones. This should >>>>> restore >>>>> the previous build time. >>>>> >>>>> However, as for the php case, the maintainer is going to evaluate >>>>> if >>>>> the consolidation makes sense or not. >>>>> If a consolidation is going to result more problematic than >>>>> beneficial, >>>>> it can be reverted and subpackages not adopted for the use case. >>>> >>>> If I understand the sum of all the above correct, you suggest to >>>> remove >>>> slave ports and to use subpackages instead (where this makes sense >>>> in >>>> terms of the current implementation of subpackages). Or worded >>>> differently to the same effect (as I only care about the effect and >>>> not >>>> the intention), when someone converts a port to subpackages, the >>>> corresponding slave packages shall be removed (or for new ports: >>>> slave >>>> ports shall not be introduced in this case). >>>> >>>> Removing slave ports means we can not depend upon specific parts >>>> anymore >>>> when installing from ports, as the subpackages can not be targeted >>>> for >>>> install directly and my example of a subpackages aware php results >>>> in >>>> security implications of to much being installed and active if >>>> installed >>>> via make install in /usr/ports/something/with_webinterface. -> best >>>> example of lang/php to use subpacakges is the best example of why >>>> not >>>> to >>>> use subpackages / shows what is a regression in the features we >>>> provide >>>> in our ports collection. >>>> >>>> While qt6-tools may be a good example where subpackages makes sense, >>>> we >>>> can not depend on subpacakges for "make install", and as if the port >>>> would be converted to have subpackages but no slave ports are >>>> introduced, pkg install and make install would differ in the amount >>>> of >>>> installed files. >>>> >>>>> For port builders >>>>> >>>>> Port builders can experience longer build times in the future, as >>>>> master/slave ports could be consolidated in one single larger >>>>> ports. >>>>> If this is the case, the larger ports should provide OPTIONS to not >>>>> build unneeded subpackages. >>>>> If no OPTION is available, please work with the maintainer to >>>>> introduce >>>>> one. >>>> >>>> I fail to see the benefit: >>>> We either lose the possibility to target parts of a package (when >>>> slave >>>> ports are removed / not introduced) on make install (with a similar >>>> amount of build time for the ports tree as it is right now), or get >>>> higher build times for the package builders. In both cases we do not >>>> gain something significant. >>>> >>>> If we want to keep the (useful in some cases) feature to install >>>> from >>>> ports (there is the case of py39-rpds-py failing to build in my >>>> poudriere which I tried to debug with the author of py-maturin due >>>> to >>>> a >>>> runtime issue in maturin, which shows up in my the cross build on >>>> amd64-intel for amd64-athlon64... which in the end leads me to build >>>> py-rpds-py on the target machine from ports), the current >>>> implementation >>>> of subpackages has to come with the requirement to create slave >>>> ports >>>> for each subpackage. >>>> >>>> That's my concern, and that's the reason why I have the opinion, >>>> that >>>> portmgr has to keep the lock on subpackages and reject any >>>> subpackage >>>> which don't come with a slave port. >>>> >>>> I would be OK to lift this restriction, when the current >>>> implementation >>>> is changed to be able to only install the files of a subpacakge on >>>> make >>>> install (an implementation could be to require "make install >>>> TARGET_SUBPACAKGES=sub1,sub2,sub3" or "make install-subpackage1 >>>> install-subpacakge2"... as long as recursive dependencies are >>>> handled >>>> according to this requirement, those people designing, implementing >>>> and >>>> reviewing this can argue about such details). >>>> >>>> Keeping the current implementation (with the restriction of always >>>> introducing slave packages for subpackages) would need a way to >>>> denote >>>> that a slave port covers a specific subpackage which would allow >>>> package >>>> builders to skip those slave ports (and the subpacakges would need >>>> to >>>> have the same package name as the slave port, no idea if this has a >>>> technical disadvantage in terms of having 2 different origins for >>>> the >>>> same package name, but it surely would be confusing for people at >>>> first >>>> look). >>>> >>>> TLDR: for the use cases you specified in the beginning, I do not see >>>> a >>>> benefit, only drawbacks. Can you please provide an example of a >>>> benefit >>>> I fail to see (yes, more modularity for qt6-tools may be beneficial >>>> for >>>> some people, but the cost/benefit between qt6-tools (something which >>>> we >>>> don't provide right now) and "make install" (what we provide right >>>> now) >>>> or "build time reduction for package builders" (which would have a >>>> benefit for a lot of use cases) is in my books much more in the >>>> direction of "make install" and "build time reduction" than towards >>>> the >>>> modularization of qt6-tools)? >>>> >>>> Bye, >>>> Alexander. >>>> >>>> -- >>>> http://www.Leidinger.net Alexander@Leidinger.net: PGP >>>> 0x8F31830F9F2772BF >>>> http://www.FreeBSD.org netchild@FreeBSD.org : PGP >>>> 0x8F31830F9F2772BF >> >> -- >> http://www.Leidinger.net Alexander@Leidinger.net: PGP >> 0x8F31830F9F2772BF >> http://www.FreeBSD.org netchild@FreeBSD.org : PGP >> 0x8F31830F9F2772BF -- http://www.Leidinger.net Alexander@Leidinger.net: PGP 0x8F31830F9F2772BF http://www.FreeBSD.org netchild@FreeBSD.org : PGP 0x8F31830F9F2772BF --=_deba9ff91a50bd5416fe042e22d25a98 Content-Type: application/pgp-signature; name=signature.asc Content-Disposition: attachment; filename=signature.asc; size=833 Content-Description: OpenPGP digital signature -----BEGIN PGP SIGNATURE----- iQIzBAEBCAAdFiEER9UlYXp1PSd08nWXEg2wmwP42IYFAmW4988ACgkQEg2wmwP4 2IY4ZRAAmFeMb/O0SK1Nr7ngjhqOiKvzeLLJ/oAPzActoRDQ7PlsAupFmUkNYpKl a5Nyuggt5384/6jmWDBsli1aaNkOYmiNzIHhgb6Q7jWFKNI5Wsbt+4fS9+mwvu99 4AZsC7ohIw1Kw+x12TMfgzxIBZ9t+mfXNnyYEy0zj4UfgHrgxyHSyyPEwAzvwe0w DVevcEgUWyFcX6rmNb+FH3GxOtI/QpsLxbLHJmVnyNnLs1dOdOk/85c1B5I3dQJ0 SxTOoqYqjzQqeKyqwhLvgKKu3So2HXgUh++xOjCzCxq9FMvg30f+zDNwFPv6ChPA js+Ax5h4K6lpr1i2DeTEyI2PxJ8r+gbMe5qn/js7nzGxdL0cd0Nn+h5Cf5RIb998 3EtdZSpwWgdQbVxvvjPIDakbSARAcUY+wyxdcEnSkWKos3Ey1a3GFnpLMJn8dVKW XjvB14nNlVnUOfRFVIOBqIqN/FTVEj+pTdgad5FXacnHZhB2VYdaxo7blX19/hnp Vb/IWCW5BRu3mLkxD8+nRQLkRX/Xq9bZosqi90iK5mUwzrazUuuPOoYCPC0tXSKK oqx+p+beQvomDMgFUeqWIOAzhJJDGjs0i5XIT9ma0M+Xid9/ee94ulsRAJ6tiJKe 7jHsKthj6yVenS9Q9cS9lFW1eBgh/e+Tl0RvFRPgW7k51zuDHfk= =luvr -----END PGP SIGNATURE----- --=_deba9ff91a50bd5416fe042e22d25a98-- From nobody Tue Jan 30 17:24:35 2024 X-Original-To: freebsd-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 4TPX9821drz59D8R for ; Tue, 30 Jan 2024 17:24:44 +0000 (UTC) (envelope-from jamie@catflap.org) Received: from donotpassgo.dyslexicfish.net (donotpassgo.dyslexicfish.net [IPv6:2001:19f0:7400:8808:123::1]) by mx1.freebsd.org (Postfix) with ESMTP id 4TPX975qTyz4KBh; Tue, 30 Jan 2024 17:24:43 +0000 (UTC) (envelope-from jamie@catflap.org) Authentication-Results: mx1.freebsd.org; none X-Catflap-Envelope-From: X-Catflap-Envelope-To: core@FreeBSD.org Received: from donotpassgo.dyslexicfish.net (donotpassgo.dyslexicfish.net [209.250.224.51]) by donotpassgo.dyslexicfish.net (8.14.5/8.14.5) with ESMTP id 40UHOZiG057848; Tue, 30 Jan 2024 17:24:35 GMT (envelope-from jamie@donotpassgo.dyslexicfish.net) Received: (from jamie@localhost) by donotpassgo.dyslexicfish.net (8.14.5/8.14.5/Submit) id 40UHOZWx057847; Tue, 30 Jan 2024 17:24:35 GMT (envelope-from jamie) From: Jamie Landeg-Jones Message-Id: <202401301724.40UHOZWx057847@donotpassgo.dyslexicfish.net> Date: Tue, 30 Jan 2024 17:24:35 +0000 Organization: Dyslexic Fish To: pizzamig@FreeBSD.org, Alexander@leidinger.net Cc: portmgr@FreeBSD.org, freebsd-ports@FreeBSD.org, core@FreeBSD.org Subject: Re: This is going to break port building without poudriere! References: <609374cf-7f1f-4643-8379-f368b23ccb09@freebsd.org> <1e27bce44f2ba85f0097fbc6aba1dac1@Leidinger.net> <282c88d38f7d9125a3cfad911370aa40@Leidinger.net> In-Reply-To: User-Agent: Heirloom mailx 12.4 7/29/08 List-Id: Porting software to FreeBSD List-Archive: https://lists.freebsd.org/archives/freebsd-ports List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-ports@freebsd.org X-BeenThere: freebsd-ports@freebsd.org MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Greylist: Sender passed SPF test, not delayed by milter-greylist-4.2.7 (donotpassgo.dyslexicfish.net [209.250.224.51]); Tue, 30 Jan 2024 17:24:35 +0000 (GMT) X-Rspamd-Queue-Id: 4TPX975qTyz4KBh 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:20473, ipnet:2001:19f0:7400::/38, country:US] Luca Pizzamiglio wrote: > Installing from ports can install more than installing from pkg. > I don't call it a regression, as it doesn't introduce bugs, ports can be > successfully built as before. > However, it introduces a divergence that requires more attention. That last sentence sounds ominous! Due to having many ports using non-default options, as well as many ports with locally produced patches, I install from src using ports rather than pkg on all machines. I do hope that those of us who do this aren't going to be forgotten with these changes! Cheers, Jamie From nobody Wed Jan 31 04:13:22 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 4TPpYb1DVdz58LPK for ; Wed, 31 Jan 2024 04:13:23 +0000 (UTC) (envelope-from portscout@FreeBSD.org) Received: from mxrelay.nyi.freebsd.org (mxrelay.nyi.freebsd.org [IPv6:2610:1c1:1:606c::19:3]) (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-signature RSA-PSS (4096 bits) client-digest SHA256) (Client CN "mxrelay.nyi.freebsd.org", Issuer "R3" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4TPpYZ6fZDz4Vbn for ; Wed, 31 Jan 2024 04:13:22 +0000 (UTC) (envelope-from portscout@FreeBSD.org) ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=freebsd.org; s=dkim; t=1706674403; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:mime-version:mime-version:content-type:content-type: content-transfer-encoding:content-transfer-encoding; bh=P7CHrea1ojoojJwVmDRWe/iPLu23NquqazEYVH0UGU0=; b=RQAvgfslY6ZKkvHzpRnpQ9cX0xhm9U0YrIQKziOmXnXeL+XoQOhByP4DwRXToQJEsFPNII bNyfmaUcVxE5K/XXWuQNooEnnL1n2VnUznX1WdDhcKaAFwTaOrlYsswInC8OVf+tTARqKq ZPplfJe9VzI0akmh201mEjs2WApTKL3tMScov1+3TSkL2WHKDqL3JKOflpPfIHGODOaNxi XUllE7Q4QCvJRIgsHmGLo8lT7RV1mMfRdvN4fLizMP2oNAC6xTvEuQjh23f3lHCfy/mbN1 ZBSCAK+Vc+ZOC0qtd82EzOoMGn4QwmVdMTWSXdS6y6LcixXafHKkzoBKCWnC/w== ARC-Authentication-Results: i=1; mx1.freebsd.org; none ARC-Seal: i=1; s=dkim; d=freebsd.org; t=1706674403; a=rsa-sha256; cv=none; b=NHKQSHzQSccfb+wMCs5djP1LbGoWDbNV+dPE/ajlwLPSaJPCja8bszyN+OmFrTRU5NXYjM i70LOYWD6TIVIZFnvHYPEH7qHSN2RR6YIrVZ/phWgrsn3AihtVjTvTkFTeWOfuVdTGCCFY kSsuNzhWscZJsg1jlgJY9cvgIil8t3/n+OTEUMAE5QNGMJQ2/1zkIVNX0PSPbXxF618zOp Cm9riRqG+Oe2f/TksJxD0kBk3LyjWQs52TCu1O3VADTX8xOAHa3YG9gMC+XMgsO/DbtVXV levEaeqKn8BMFkjr8CJGqTvGHkMeJOTllq4Oi8nFjTn1uy05jHveM6E3gOIiYw== Received: from portscout.nyi.freebsd.org (portscout.nyi.freebsd.org [IPv6:2610:1c1:1:606c::50:21]) (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 mxrelay.nyi.freebsd.org (Postfix) with ESMTPS id 4TPpYZ5XdKz146D for ; Wed, 31 Jan 2024 04:13:22 +0000 (UTC) (envelope-from portscout@FreeBSD.org) Received: from portscout.nyi.freebsd.org ([127.0.1.10]) by portscout.nyi.freebsd.org (8.17.1/8.17.1) with ESMTP id 40V4DMST007703 for ; Wed, 31 Jan 2024 04:13:22 GMT (envelope-from portscout@FreeBSD.org) Received: (from portscout@localhost) by portscout.nyi.freebsd.org (8.17.1/8.17.1/Submit) id 40V4DMcD007702; Wed, 31 Jan 2024 04:13:22 GMT (envelope-from portscout@FreeBSD.org) Message-Id: <202401310413.40V4DMcD007702@portscout.nyi.freebsd.org> X-Authentication-Warning: portscout.nyi.freebsd.org: portscout set sender to portscout@FreeBSD.org using -f Content-Disposition: inline Content-Transfer-Encoding: 8bit Content-Type: text/plain List-Id: Porting software to FreeBSD List-Archive: https://lists.freebsd.org/archives/freebsd-ports List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-ports@freebsd.org X-BeenThere: freebsd-ports@freebsd.org MIME-Version: 1.0 Date: Wed, 31 Jan 2024 04:13:22 +0000 From: portscout@FreeBSD.org To: ports@freebsd.org Subject: Unmaintained FreeBSD ports which are out of date X-Mailer: portscout/0.8.1 Dear port maintainers, The portscout new distfile checker has detected that one or more unmaintained ports appears to be out of date. Please take the opportunity to check each of the ports listed below, and if possible and appropriate, submit/commit an update. Please consider also adopting this port. If any ports have already been updated, you can safely ignore the entry. An e-mail will not be sent again for any of the port/version combinations below. Full details can be found at the following URL: http://portscout.freebsd.org/ports@freebsd.org.html Port | Current version | New version ------------------------------------------------+-----------------+------------ cad/ifcopenshell | 0.6.0 | blenderbim-240130 ------------------------------------------------+-----------------+------------ databases/clickhouse | 22.1.3.7 | v24.1.1.2048-stable ------------------------------------------------+-----------------+------------ devel/py-archinfo | 9.0.5405 | v9.2.87 ------------------------------------------------+-----------------+------------ devel/py-cle | 9.0.5405 | v9.2.87 ------------------------------------------------+-----------------+------------ math/py-claripy | 9.0.5405 | v9.2.87 ------------------------------------------------+-----------------+------------ net-mgmt/netxms | 3.9.420 | 4.5.1 ------------------------------------------------+-----------------+------------ security/py-ailment | 9.0.5405 | v9.2.87 ------------------------------------------------+-----------------+------------ security/py-pyvex | 9.0.5405 | v9.2.87 ------------------------------------------------+-----------------+------------ sysutils/nix | 2.3.11 | 2.20.1 ------------------------------------------------+-----------------+------------ textproc/R-cran-commonmark | 1.9.0 | 1.9.1 ------------------------------------------------+-----------------+------------ If any of the above results are invalid, please check the following page for details on how to improve portscout's detection and selection of distfiles on a per-port basis: http://portscout.freebsd.org/info/portscout-portconfig.txt Reported by: portscout! From nobody Wed Jan 31 06:12:10 2024 X-Original-To: freebsd-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 4TPsCh1nFsz58X94 for ; Wed, 31 Jan 2024 06:13:04 +0000 (UTC) (envelope-from pat@patmaddox.com) Received: from out3-smtp.messagingengine.com (out3-smtp.messagingengine.com [66.111.4.27]) (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 4TPsCg228yz4kTD; Wed, 31 Jan 2024 06:13:03 +0000 (UTC) (envelope-from pat@patmaddox.com) Authentication-Results: mx1.freebsd.org; dkim=pass header.d=patmaddox.com header.s=fm2 header.b=DDIX1zVJ; dkim=pass header.d=messagingengine.com header.s=fm3 header.b=FBuZ5uZB; dmarc=none; spf=pass (mx1.freebsd.org: domain of pat@patmaddox.com designates 66.111.4.27 as permitted sender) smtp.mailfrom=pat@patmaddox.com Received: from compute2.internal (compute2.nyi.internal [10.202.2.46]) by mailout.nyi.internal (Postfix) with ESMTP id 4C5D25C008C; Wed, 31 Jan 2024 01:13:02 -0500 (EST) Received: from imap41 ([10.202.2.91]) by compute2.internal (MEProxy); Wed, 31 Jan 2024 01:13:02 -0500 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=patmaddox.com; h=cc:content-type:content-type:date:date:from:from:in-reply-to :message-id:mime-version:reply-to:subject:subject:to:to; s=fm2; t=1706681582; x=1706767982; bh=uJ4gToem3LhaGT7Q6XJUN2GN1njTPERb N7bzT0jKnEU=; b=DDIX1zVJTGCEVyJlhyKJUqHtqbviXu1CRMogAHglqvv2e02o wHlW8Gv+lbDddQLFZZ7mF9BaloabUa6RFM1q5D50bDcOI4xb4+MT73PAH94JrQDe Lyim3FjTEQFAZOKxXohE7ReNFc7g3anXWnQKmRmzMKxO5v/kd2FsdEM4cqynvZKs DwJ6x4pqlCN4Cs7UkEvLUO1FjNuCxRHKXg+OdlwNSrck2Y7XRMm3c6dBVe/Iq8Qn pxtW9W2doUsP3IPT0T/QnCmFAuBJbxaJIkQHd3pBKbycAKM6qdBswFx+SCIDLWYd pms763eCRhIqfIaVmJBE8+7H8m3wm8SyVleEyA== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=cc:content-type:content-type:date:date :feedback-id:feedback-id:from:from:in-reply-to:message-id :mime-version:reply-to:subject:subject:to:to:x-me-proxy :x-me-proxy:x-me-sender:x-me-sender:x-sasl-enc; s=fm3; t= 1706681582; x=1706767982; bh=uJ4gToem3LhaGT7Q6XJUN2GN1njTPERbN7b zT0jKnEU=; b=FBuZ5uZBiejTsybWbQAP800EqJyFcSsIPBK/4078AVteHL4aXEi v8wHofGR/9+r7px5ldvYDknA2wHSuPOd60cB6iyhQvQhKp8Rc2evoJVFYmNwNKlR ailB8a75mtREUHi4P3qzapb7aFdC2shunpZPLJzdlHYuoTytUURAleb5MY1kHbfI yUpKl+MJFV2AfIXcb0eYhuZkLe7bINQY2TzGdXMaF1g7QkeEIPXaVJMdHogNWoq8 XzxaYbv2jCNsKecuYyQHnWvRzTFVzMSOsUcxmtDeTmooMnLK4WKTcrlvvA+uUQp+ eGBAIQj5VdrelibAbPL/pRkcByxWC53YcIQ== X-ME-Sender: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgedvkedrfedtkedgleduucetufdoteggodetrfdotf fvucfrrhhofhhilhgvmecuhfgrshhtofgrihhlpdfqfgfvpdfurfetoffkrfgpnffqhgen uceurghilhhouhhtmecufedttdenucenucfjughrpefofgggkfffhffvufgtsehttdertd erredtnecuhfhrohhmpedfrfgrthcuofgrugguohigfdcuoehprghtsehprghtmhgruggu ohigrdgtohhmqeenucggtffrrghtthgvrhhnpeduueefgfekgeehudeuheettddtgfelud dtveetvefhhfduuedtjedvgeeuieefteenucffohhmrghinhepfhhrvggvsghsugdrohhr ghenucevlhhushhtvghrufhiiigvpedtnecurfgrrhgrmhepmhgrihhlfhhrohhmpehprg htsehprghtmhgrugguohigrdgtohhm X-ME-Proxy: Feedback-ID: i8b6c40f9:Fastmail Received: by mailuser.nyi.internal (Postfix, from userid 501) id EED602340080; Wed, 31 Jan 2024 01:13:01 -0500 (EST) X-Mailer: MessagingEngine.com Webmail Interface User-Agent: Cyrus-JMAP/3.11.0-alpha0-144-ge5821d614e-fm-20240125.002-ge5821d61 List-Id: Porting software to FreeBSD List-Archive: https://lists.freebsd.org/archives/freebsd-ports List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-ports@freebsd.org X-BeenThere: freebsd-ports@freebsd.org MIME-Version: 1.0 Message-Id: Date: Tue, 30 Jan 2024 22:12:10 -0800 From: "Pat Maddox" To: freebsd-ports@freebsd.org Subject: Request to review and merge several updated ports I maintain (and a few new ones) Content-Type: text/plain X-Spamd-Bar: ---- X-Spamd-Result: default: False [-4.54 / 15.00]; DWL_DNSWL_LOW(-1.00)[messagingengine.com:dkim]; NEURAL_HAM_MEDIUM(-1.00)[-1.000]; NEURAL_HAM_LONG(-1.00)[-1.000]; NEURAL_HAM_SHORT(-0.95)[-0.953]; R_SPF_ALLOW(-0.20)[+ip4:66.111.4.27]; R_DKIM_ALLOW(-0.20)[patmaddox.com:s=fm2,messagingengine.com:s=fm3]; MIME_GOOD(-0.10)[text/plain]; RCVD_IN_DNSWL_LOW(-0.10)[66.111.4.27:from]; XM_UA_NO_VERSION(0.01)[]; ARC_NA(0.00)[]; FREEFALL_USER(0.00)[pat]; RCPT_COUNT_ONE(0.00)[1]; MIME_TRACE(0.00)[0:+]; ASN(0.00)[asn:19151, ipnet:66.111.4.0/24, country:US]; FROM_HAS_DN(0.00)[]; DMARC_NA(0.00)[patmaddox.com]; RCVD_COUNT_THREE(0.00)[3]; FROM_EQ_ENVFROM(0.00)[]; MLMMJ_DEST(0.00)[freebsd-ports@freebsd.org]; TO_DN_NONE(0.00)[]; RCVD_TLS_LAST(0.00)[]; TO_MATCH_ENVRCPT_ALL(0.00)[]; DKIM_TRACE(0.00)[patmaddox.com:+,messagingengine.com:+] X-Rspamd-Queue-Id: 4TPsCg228yz4kTD Hi there, (If I've BCCed you, it's because you merged some of my maintained ports in the past. Please let me know if you would prefer I not do so in the future) Here are updates to several of my maintained ports that I submitted a while back. I believe I've configured them all so they would get picked up by committers - if not, could someone please let me know what I would need to change? Thanks, Pat Updates: - textproc/ox-gfm.el - https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=276460 - databases/py-snowddl - https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=276458 - databases/py-schemachange - https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=276457 - databases/py-dbt-snowflake - https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=276456 - databases/py-snowflake-connector-python - https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=276455 - databases/py-dbt-duckdb - https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=276454 - databases/py-dbt-core - https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=276453 - databases/py-dbt-semantic-interfaces - https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=276452 New ports: - devel/ob-go - https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=276322 - devel/go-mode.el - https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=276329 - textproc/denote.el - https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=276317 From nobody Wed Jan 31 09:36:16 2024 X-Original-To: freebsd-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 4TPxkZ3sL9z57Nlm for ; Wed, 31 Jan 2024 09:36:38 +0000 (UTC) (envelope-from einar@isnic.is) Received: from mx01.isnic.is (mx01.isnic.is [IPv6:2001:67c:6c:58::133]) (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-signature RSA-PSS (2048 bits) client-digest SHA256) (Client CN "mx01.isnic.is", Issuer "R3" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4TPxkY1ncPz49YH for ; Wed, 31 Jan 2024 09:36:37 +0000 (UTC) (envelope-from einar@isnic.is) Authentication-Results: mx1.freebsd.org; dkim=pass header.d=isnic.is header.s=20200921 header.b=Hf0e4tmr; dmarc=pass (policy=quarantine) header.from=isnic.is; spf=pass (mx1.freebsd.org: domain of einar@isnic.is designates 2001:67c:6c:58::133 as permitted sender) smtp.mailfrom=einar@isnic.is Received: from ht-mailstore01.isnic.is (ht-mailstore01.isnic.is [IPv6:2001:67c:6c:56::2]) by mx01.isnic.is (Postfix) with ESMTPS id 18AA516159 for ; Wed, 31 Jan 2024 09:36:27 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=isnic.is; s=20200921; t=1706693787; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:mime-version:mime-version:content-type:content-type: content-transfer-encoding:content-transfer-encoding; bh=PWNI1FON8z8Ne4bzIDMVCimiGnDRIII6z942fX3FJqU=; b=Hf0e4tmr9+bmubpsT4f/LBgIMwaYkMfVmaXaplN0e4+/96Cl67SVqYpRyf0Sow5puIw3fA olJB/mu6UOS85z5eieDi3ftJMc+VXEqZ415ZKY74GvOBAAj7RdacQrOOHoSzTFfRvE18X2 IQ3xr2S6OerrCKz56xn922JpcEmrwDpv3Clb5v5zVUYzT3V6CkZmalgb7kxbiHkfuPLb8E EvanTaKF8YWlCCiSqbEYVSkEzUJyJ0Vm4RqPPe8GOVL8ozAHciYvWdz6SGzNyO12w+Ssce bmfDBm/ofy+EuYyOLH1zn1VasEjZMLqLvBVcJvYYwv/yrAgNZtswadyIxiLvQQ== Received: from smtpclient.apple (unknown [IPv6:2001:67c:6c:f100::194]) by ht-mailstore01.isnic.is (Postfix) with ESMTPS id 11A201E98A for ; Wed, 31 Jan 2024 09:36:27 +0000 (UTC) From: =?utf-8?Q?Einar_Bjarni_Halld=C3=B3rsson?= Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable List-Id: Porting software to FreeBSD List-Archive: https://lists.freebsd.org/archives/freebsd-ports List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-ports@freebsd.org X-BeenThere: freebsd-ports@freebsd.org Mime-Version: 1.0 (Mac OS X Mail 16.0 \(3774.400.31\)) Subject: mail/py-authheaders 0.16.2 Message-Id: <82A11CEE-CA78-4211-981F-EF70639E7868@isnic.is> Date: Wed, 31 Jan 2024 09:36:16 +0000 To: FreeBSD Mailing List X-Mailer: Apple Mail (2.3774.400.31) X-Spamd-Bar: --- X-Spamd-Result: default: False [-4.00 / 15.00]; NEURAL_HAM_LONG(-1.00)[-1.000]; NEURAL_HAM_MEDIUM(-1.00)[-1.000]; NEURAL_HAM_SHORT(-1.00)[-1.000]; DMARC_POLICY_ALLOW(-0.50)[isnic.is,quarantine]; R_DKIM_ALLOW(-0.20)[isnic.is:s=20200921]; R_SPF_ALLOW(-0.20)[+ip6:2001:67c:6c::/48]; MIME_GOOD(-0.10)[text/plain]; RCPT_COUNT_ONE(0.00)[1]; ASN(0.00)[asn:1850, ipnet:2001:67c:6c::/48, country:IS]; APPLE_MAILER_COMMON(0.00)[]; MIME_TRACE(0.00)[0:+]; RCVD_TLS_ALL(0.00)[]; MID_RHS_MATCH_FROM(0.00)[]; MLMMJ_DEST(0.00)[freebsd-ports@freebsd.org]; FROM_EQ_ENVFROM(0.00)[]; FROM_HAS_DN(0.00)[]; ARC_NA(0.00)[]; RCVD_COUNT_TWO(0.00)[2]; PREVIOUSLY_DELIVERED(0.00)[freebsd-ports@freebsd.org]; TO_MATCH_ENVRCPT_ALL(0.00)[]; TO_DN_ALL(0.00)[]; DKIM_TRACE(0.00)[isnic.is:+] X-Rspamd-Queue-Id: 4TPxkY1ncPz49YH Hi, I have a PR [1] open for upgrading mail/py-authheaders to the latest = version, 0.16.2. It=E2=80=99s a fairly basic update, although upstream has added a = dependency on python 3.8+. Could a committer take a look and commit? .einar [1] https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=3D276550= From nobody Wed Jan 31 13:27:04 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 4TQ2rW1RtBz58X3t for ; Wed, 31 Jan 2024 13:27:07 +0000 (UTC) (envelope-from rizzo@rizzo.eng.br) Received: from mailhost.i805.com.br (mailhost.i805.com.br [199.241.136.61]) (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-signature RSA-PSS (2048 bits) client-digest SHA256) (Client CN "ibicui", Issuer "ibicui" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id 4TQ2rV4xzJz4gtL for ; Wed, 31 Jan 2024 13:27:06 +0000 (UTC) (envelope-from rizzo@rizzo.eng.br) Authentication-Results: mx1.freebsd.org; dkim=none; dmarc=none; spf=softfail (mx1.freebsd.org: 199.241.136.61 is neither permitted nor denied by domain of rizzo@rizzo.eng.br) smtp.mailfrom=rizzo@rizzo.eng.br Received: from mailhost.i805.com.br (localhost [127.0.0.1]) by mailhost.i805.com.br (8.17.1/8.17.1) with ESMTPS id 40VDR5FE062553 (version=TLSv1.3 cipher=TLS_AES_256_GCM_SHA384 bits=256 verify=NO) for ; Wed, 31 Jan 2024 10:27:05 -0300 (-03) (envelope-from rizzo@mailhost.i805.com.br) Received: (from rizzo@localhost) by mailhost.i805.com.br (8.17.1/8.17.1/Submit) id 40VDR5Sq062109 for ports@freebsd.org; Wed, 31 Jan 2024 10:27:05 -0300 (-03) (envelope-from rizzo) From: Nilton Jose Rizzo Message-Id: <202401311327.40VDR5Sq062109@mailhost.i805.com.br> Subject: problem with qcad port To: ports@freebsd.org Date: Wed, 31 Jan 2024 10:27:04 -0300 (-03) X-Mailer: ELM [version 2.5 PL8] List-Id: Porting software to FreeBSD List-Archive: https://lists.freebsd.org/archives/freebsd-ports List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-ports@freebsd.org X-BeenThere: freebsd-ports@freebsd.org MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Spam-Status: No, score=-0.9 required=5.0 tests=ALL_TRUSTED,TW_CG,TW_QC, T_SCC_BODY_TEXT_LINE autolearn=no autolearn_force=no version=4.0.0 X-Spam-Checker-Version: SpamAssassin 4.0.0 (2022-12-14) on mailhost.i805.com.br X-Spamd-Bar: -- X-Spamd-Result: default: False [-2.73 / 15.00]; NEURAL_HAM_LONG(-1.00)[-0.999]; NEURAL_HAM_MEDIUM(-0.94)[-0.942]; NEURAL_HAM_SHORT(-0.69)[-0.691]; MIME_GOOD(-0.10)[text/plain]; MLMMJ_DEST(0.00)[ports@freebsd.org]; R_DKIM_NA(0.00)[]; ARC_NA(0.00)[]; ASN(0.00)[asn:29802, ipnet:199.241.136.0/24, country:US]; RCVD_COUNT_TWO(0.00)[2]; MIME_TRACE(0.00)[0:+]; FROM_HAS_DN(0.00)[]; RCVD_TLS_LAST(0.00)[]; R_SPF_SOFTFAIL(0.00)[~all:c]; FROM_EQ_ENVFROM(0.00)[]; DMARC_NA(0.00)[rizzo.eng.br]; TO_DN_NONE(0.00)[]; PREVIOUSLY_DELIVERED(0.00)[ports@freebsd.org]; TO_MATCH_ENVRCPT_ALL(0.00)[]; RCPT_COUNT_ONE(0.00)[1] X-Rspamd-Queue-Id: 4TQ2rV4xzJz4gtL Hi all I install the QCad on FreeBSD 15-current and I get this error: % qcad QCAD version 3.28.1 10:20:31: Debug: loading plugins... 10:20:31: Debug: loading static plugins... Segmentation fault under cgdb debbbuger tools, I get this infomations: (gdb) run Starting program: /usr/local/bin/qcad QCAD version 3.28.1 [New LWP 282536 of process 34997] 10:21:05: Debug: loading plugins... 10:21:05: Debug: loading static plugins... [New LWP 282537 of process 34997] Thread 1 received signal SIGSEGV, Segmentation fault. Address not mapped to object. 0x0000000803d9da80 in ?? () from /usr/local/lib/qt5/libQt5Script.so.5 last instruction: ** 0x803d9da80: mov -0x38(%r15),%r14 (803d9da80 - 803d9dc06) ** (gdb) bt #0 0x0000000803d9da80 in ?? () from /usr/local/lib/qt5/libQt5Script.so.5 #1 0x0000000803d2b436 in ?? () from /usr/local/lib/qt5/libQt5Script.so.5 #2 0x0000000803d2a419 in ?? () from /usr/local/lib/qt5/libQt5Script.so.5 #3 0x0000000803da57b1 in ?? () from /usr/local/lib/qt5/libQt5Script.so.5 #4 0x0000000803da6d44 in QScriptEngine::newVariant(QVariant const&) () from /usr/local/lib/qt5/libQt5Script.so.5 #5 0x000000080ba1b7d8 in qtscript_create_Qt_class(QScriptEngine*) () from /usr/local/share/qcad/plugins/script/libqtscript_core.so.1.0.0 #6 0x000000080baae570 in qtscript_initialize_com_trolltech_qt_core_bindings(QSc riptValue&) () from /usr/local/share/qcad/plugins/script/libqtscript_core.so.1.0.0 #7 0x000000080b92b938 in non-virtual thunk to com_trolltech_qt_core_ScriptPlugi n::initialize(QString const&, QScriptEngine*) () from /usr/local/share/qcad/plugins/script/libqtscript_core.so.1.0.0 #8 0x0000000803dacad7 in QScriptEngine::importExtension(QString const&) () from /usr/local/lib/qt5/libQt5Script.so.5 #9 0x0000000800ae2d15 in RScriptHandlerEcma::RScriptHandlerEcma() () from /usr/local/lib/libqcadecmaapi.so #10 0x0000000800aef6fc in RScriptHandlerEcma::factory() () from /usr/local/lib/libqcadecmaapi.so #11 0x0000000801db77de in RScriptHandlerRegistry::getGlobalScriptHandler(QString const&) () from /usr/local/lib/libqcadcore.so #12 0x0000000000206b8f in ?? () #13 0x00000008048d987a in __libc_start1 (argc=1, argv=0x7fffffffd910, --Type for more, q to quit, c to continue without paging-- env=0x7fffffffd920, cleanup=, mainX=0x205c70) at /usr/src/lib/libc/csu/libc_start1.c:157 #14 0x0000000000205c00 in ?? () (gdb) I trying recompile all qt5 and qcad and reinstall the both ports, but the erro persist. Information about my box: % uname -nmbK valfenda amd64 1500012 c5ee0db87cb2833d50db2da0342580b6a2342920 % uname -a FreeBSD valfenda 15.0-CURRENT FreeBSD 15.0-CURRENT #3: Mon Jan 29 21:06:53 -03 2024 rizzo@valfenda:/usr/obj/usr/src/amd64.amd64/sys/GENERIC-NODEBUG amd64 % cd /usr/src # git log -1 commit c46860dbcb2037933575a260028325418b3e9789 (HEAD -> main, freebsd/main, freebsd/HEAD) Author: John Baldwin Date: Mon Jan 29 11:02:07 2024 -0800 bhyve: Use NVMEF macro to construct fields Reviewed by: corvink, chuck (older version) Sponsored by: Chelsio Communications Differential Revision: https://reviews.freebsd.org/D43607 # cd /usr/ports # git log -1 commit 9cf62446de471195b1bc744d53b4a8463e692657 (HEAD -> main, origin/main, origin/HEAD) Author: Muhammad Moinur Rahman Date: Mon Jan 29 20:53:58 2024 +0100 x11-wm/fvwm2: Moved man to share/man Approved by: portmgr (blanket) Whats did I do wrong? TIA Nilton Jose Rizzo From nobody Wed Jan 31 13:36:26 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 4TQ33J2HXCz58Xxw for ; Wed, 31 Jan 2024 13:36:28 +0000 (UTC) (envelope-from rizzo@rizzo.eng.br) Received: from mailhost.i805.com.br (mailhost.i805.com.br [199.241.136.61]) (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-signature RSA-PSS (2048 bits) client-digest SHA256) (Client CN "ibicui", Issuer "ibicui" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id 4TQ33H5v1yz4hg8 for ; Wed, 31 Jan 2024 13:36:27 +0000 (UTC) (envelope-from rizzo@rizzo.eng.br) Authentication-Results: mx1.freebsd.org; dkim=none; dmarc=none; spf=softfail (mx1.freebsd.org: 199.241.136.61 is neither permitted nor denied by domain of rizzo@rizzo.eng.br) smtp.mailfrom=rizzo@rizzo.eng.br Received: from mailhost.i805.com.br (localhost [127.0.0.1]) by mailhost.i805.com.br (8.17.1/8.17.1) with ESMTPS id 40VDaQ77080121 (version=TLSv1.3 cipher=TLS_AES_256_GCM_SHA384 bits=256 verify=NO) for ; Wed, 31 Jan 2024 10:36:26 -0300 (-03) (envelope-from rizzo@mailhost.i805.com.br) Received: (from rizzo@localhost) by mailhost.i805.com.br (8.17.1/8.17.1/Submit) id 40VDaQrJ080028 for ports@freebsd.org; Wed, 31 Jan 2024 10:36:26 -0300 (-03) (envelope-from rizzo) From: Nilton Jose Rizzo Message-Id: <202401311336.40VDaQrJ080028@mailhost.i805.com.br> Subject: problem with Obs-Studio To: ports@freebsd.org Date: Wed, 31 Jan 2024 10:36:26 -0300 (-03) X-Mailer: ELM [version 2.5 PL8] List-Id: Porting software to FreeBSD List-Archive: https://lists.freebsd.org/archives/freebsd-ports List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-ports@freebsd.org X-BeenThere: freebsd-ports@freebsd.org MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Spam-Status: No, score=-0.9 required=5.0 tests=ALL_TRUSTED,TW_CG, T_SCC_BODY_TEXT_LINE,URIBL_BLOCKED autolearn=unavailable autolearn_force=no version=4.0.0 X-Spam-Checker-Version: SpamAssassin 4.0.0 (2022-12-14) on mailhost.i805.com.br X-Spamd-Bar: --- X-Spamd-Result: default: False [-3.04 / 15.00]; NEURAL_HAM_LONG(-1.00)[-1.000]; NEURAL_HAM_SHORT(-0.99)[-0.991]; NEURAL_HAM_MEDIUM(-0.95)[-0.949]; MIME_GOOD(-0.10)[text/plain]; R_DKIM_NA(0.00)[]; MLMMJ_DEST(0.00)[ports@freebsd.org]; ARC_NA(0.00)[]; ASN(0.00)[asn:29802, ipnet:199.241.136.0/24, country:US]; RCVD_COUNT_TWO(0.00)[2]; MIME_TRACE(0.00)[0:+]; FROM_HAS_DN(0.00)[]; RCVD_TLS_LAST(0.00)[]; R_SPF_SOFTFAIL(0.00)[~all:c]; FROM_EQ_ENVFROM(0.00)[]; DMARC_NA(0.00)[rizzo.eng.br]; TO_DN_NONE(0.00)[]; PREVIOUSLY_DELIVERED(0.00)[ports@freebsd.org]; TO_MATCH_ENVRCPT_ALL(0.00)[]; RCPT_COUNT_ONE(0.00)[1] X-Rspamd-Queue-Id: 4TQ33H5v1yz4hg8 Hi all I trying to use OBS-Studio installed via pkg, but I get this erro: % obs debug: Attempted path: share/obs/obs-studio/locale/en-US.ini debug: Attempted path: /usr/local/share/obs/obs-studio/locale/en-US.ini debug: Attempted path: share/obs/obs-studio/locale.ini debug: Attempted path: /usr/local/share/obs/obs-studio/locale.ini debug: Attempted path: share/obs/obs-studio/themes/Yami.qss debug: Attempted path: /usr/local/share/obs/obs-studio/themes/Yami.qss warning: [Safe Mode] Unclean shutdown detected! warning: [Safe Mode] User elected to launch normally. info: Using EGL/X11 info: CPU Name: AMD Ryzen 5 2600 Six-Core Processor info: CPU Speed: 3393.81MHz info: Physical Cores: 2, Logical Cores: 12 info: Physical Memory: 15843MB Total, 5950MB Free info: Kernel Version: FreeBSD 15.0-CURRENT info: Distribution: FreeBSD "15.0" info: Window System: X11.0, Vendor: The X.Org Foundation, Version: 1.21.1 info: Qt Version: 6.6.1 (runtime), 6.6.1 (compiled) info: Portable mode: false info: OBS 30.0.2 (freebsd) info: --------------------------------- info: --------------------------------- info: audio settings reset: samples per sec: 48000 speakers: 2 max buffering: 960 milliseconds buffering type: dynamically increasing info: --------------------------------- info: Initializing OpenGL... Segmentation fault When I execute OBS-Studio, it show a windows asking to I choose Normal or Safe Mode, in both cases it's crash. Note this port is using QT6. I trying to reinstall OBS-Studio via ports and the error was keeping. using cgdb I get this infomations: info: audio settings reset: samples per sec: 48000 speakers: 2 max buffering: 960 milliseconds buffering type: dynamically increasing [New LWP 283537 of process 52911] info: --------------------------------- info: Initializing OpenGL... Thread 1 received signal SIGSEGV, Segmentation fault. Address not mapped to object. 0x000000080c99d84b in gladLoadGL () from /usr/local/lib/libobs-opengl.so.1 (gdb) bt #0 0x000000080c99d84b in gladLoadGL () at /usr/local/lib/libobs-opengl.so.1 #1 0x000000080c99c57b in ??? () at /usr/local/lib/libobs-opengl.so.1 #2 0x000000080c995338 in device_create () at /usr/local/lib/libobs-opengl.so.1 #3 0x0000000803f9e9b0 in gs_create () at /usr/local/lib/libobs.so.0 #4 0x0000000803f41673 in obs_reset_video () at /usr/local/lib/libobs.so.0 #5 0x00000000004bbc48 in ??? () #6 0x00000000004b9b16 in ??? () #7 0x00000000004147de in ??? () #8 0x000000000041a8e1 in ??? () #9 0x000000080505887a in __libc_start1 (argc=1, argv=0x7fffffffd910, env=0x7fffffffd920, cleanup=, m ainX=0x4191a0) at /usr/src/lib/libc/csu/libc_start1.c:157 #10 0x00000000003f75a0 in ??? () My box: % uname -anbK FreeBSD valfenda 15.0-CURRENT FreeBSD 15.0-CURRENT #3: Mon Jan 29 21:06:53 -03 2024 rizzo@valfenda:/usr/obj/usr/src/amd64.amd64/sys/GENERIC-NODEBUG amd64 1500012 c5ee0db87cb2833d50db2da0342580b6a2342920 % TIA, Nilton Jose Rizzo From nobody Wed Jan 31 13:46:11 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 4TQ3HG4jfkz58Yt7 for ; Wed, 31 Jan 2024 13:46:50 +0000 (UTC) (envelope-from marietto2008@gmail.com) Received: from mail-ed1-x531.google.com (mail-ed1-x531.google.com [IPv6:2a00:1450:4864:20::531]) (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 4TQ3HG17v4z4jyV for ; Wed, 31 Jan 2024 13:46:50 +0000 (UTC) (envelope-from marietto2008@gmail.com) Authentication-Results: mx1.freebsd.org; none Received: by mail-ed1-x531.google.com with SMTP id 4fb4d7f45d1cf-558f523c072so6470104a12.2 for ; Wed, 31 Jan 2024 05:46:50 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1706708809; x=1707313609; darn=freebsd.org; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:from:to:cc:subject:date:message-id:reply-to; bh=qbc3SNH3KoAPlO0X5olipQNLbtFePMNkjYEuAkCViz4=; b=YFwd+WU3F85Pl1dFYT4vlLy5pcFlQX7+w84s6F1aRS7RBk2dnsNEGJRvJhv+xUypti CkrToZZJ+rQH6OOo83P6ohwKJ8SBariHrzrU8K9ZMm2k+D77KgZFR7Z8CDLLvQ010EIl JEeK6+7bKTnoH9HrWadLu5UBAhQaT37vxzU/0sfWqBbgtHpoZOHvPiuUCYYfMy983fl7 wz34d8VSe2dmXpEhpdrdbrDmLOrUiRywnTnEFNGcjLQZ3hwQrInFmh9GYRPWnT1txHde 3iIkw0LfnGyt9JRo+DSxm4VCW284ABRWseb9U17fbxM5aJdOojb3opv3xWZBazFM7JOn X7VA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1706708809; x=1707313609; 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=qbc3SNH3KoAPlO0X5olipQNLbtFePMNkjYEuAkCViz4=; b=mP2wl9t1lQ9Jcl+iaarP9N9/QrDZWmLAlEOGrwsaJ1iBDb1vSXfG76Uov1fpD/8eM9 /XViOTtZnWHYELwn3ckJjks5MsOpoNHZwg9F2XOBVw8qB9U1BeSqmLPNv2/0RX2InTR6 TCeRFRNltvAyfSizcyhJC1zqclusPO1W1/GiqD7nHG6ZYdipQtesNCu2RIMaemUsHc5s C4JI7BMz2KB3XNzLMriWwkPNzcRZqXsD3zVt6slqPhYZLLxf5LehqRzE8BZxmjB0yr97 t8ySgDZ6pUQMbJ1TZJVl7W6EDUe9I3IkpVPG6wt6bx5ZVWpmIhx8QqR8XMofRYBmp3/c rAYw== X-Gm-Message-State: AOJu0YyRCu2U6KnrbITkv5/OORZspre21ehynJNKIZXUyIUn43LUlUaM +CH/olxYAog1Ij0l8Bvb61I1OgiyR+x7e29oAOwY1ZhL37gYuh5Zfqyq42OcNcEZmOY5r5QECLF uG02iVdLtUdbFDSN17QcFrMCSigpOofpT X-Google-Smtp-Source: AGHT+IFJRxnSSnJC+cMrQCzihWlKRKQaXrFCRRu2dzLLdaz7mhJvW1je0DyBRkSOWA3aAqghj4tYuYLqVUWDA1WMsoA= X-Received: by 2002:a17:906:387:b0:a30:1000:3c5a with SMTP id b7-20020a170906038700b00a3010003c5amr1270835eja.49.1706708808563; Wed, 31 Jan 2024 05:46:48 -0800 (PST) List-Id: Porting software to FreeBSD List-Archive: https://lists.freebsd.org/archives/freebsd-ports List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-ports@freebsd.org X-BeenThere: freebsd-ports@freebsd.org MIME-Version: 1.0 References: <202401311336.40VDaQrJ080028@mailhost.i805.com.br> In-Reply-To: <202401311336.40VDaQrJ080028@mailhost.i805.com.br> From: Mario Marietto Date: Wed, 31 Jan 2024 14:46:11 +0100 Message-ID: Subject: Re: problem with Obs-Studio To: Nilton Jose Rizzo Cc: ports@freebsd.org Content-Type: multipart/alternative; boundary="00000000000044fea906103e1c51" X-Rspamd-Queue-Id: 4TQ3HG17v4z4jyV 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:2a00:1450::/32, country:US] --00000000000044fea906103e1c51 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable FreeBSD 15.0 is for development usage. You can't expect everything to work well. Try 14.0. On Wed, Jan 31, 2024 at 2:36=E2=80=AFPM Nilton Jose Rizzo wrote: > Hi all > > I trying to use OBS-Studio installed via pkg, but I get this erro: > > % obs > debug: Attempted path: share/obs/obs-studio/locale/en-US.ini > debug: Attempted path: /usr/local/share/obs/obs-studio/locale/en-US.ini > debug: Attempted path: share/obs/obs-studio/locale.ini > debug: Attempted path: /usr/local/share/obs/obs-studio/locale.ini > debug: Attempted path: share/obs/obs-studio/themes/Yami.qss > debug: Attempted path: /usr/local/share/obs/obs-studio/themes/Yami.qss > warning: [Safe Mode] Unclean shutdown detected! > warning: [Safe Mode] User elected to launch normally. > info: Using EGL/X11 > info: CPU Name: AMD Ryzen 5 2600 Six-Core Processor > info: CPU Speed: 3393.81MHz > info: Physical Cores: 2, Logical Cores: 12 > info: Physical Memory: 15843MB Total, 5950MB Free > info: Kernel Version: FreeBSD 15.0-CURRENT > info: Distribution: FreeBSD "15.0" > info: Window System: X11.0, Vendor: The X.Org Foundation, Version: 1.21.1 > info: Qt Version: 6.6.1 (runtime), 6.6.1 (compiled) > info: Portable mode: false > info: OBS 30.0.2 (freebsd) > info: --------------------------------- > info: --------------------------------- > info: audio settings reset: > samples per sec: 48000 > speakers: 2 > max buffering: 960 milliseconds > buffering type: dynamically increasing > info: --------------------------------- > info: Initializing OpenGL... > Segmentation fault > > When I execute OBS-Studio, it show a windows asking to I choose Normal or > Safe Mode, in both cases it's crash. > > Note this port is using QT6. > > I trying to reinstall OBS-Studio via ports and the error was keeping. > > using cgdb I get this infomations: > > info: audio settings reset: > samples per sec: 48000 > speakers: 2 > max buffering: 960 milliseconds > buffering type: dynamically increasing > [New LWP 283537 of process 52911] > info: --------------------------------- > info: Initializing OpenGL... > > Thread 1 received signal SIGSEGV, Segmentation fault. > Address not mapped to object. > 0x000000080c99d84b in gladLoadGL () from /usr/local/lib/libobs-opengl.so.= 1 > (gdb) bt > #0 0x000000080c99d84b in gladLoadGL () at > /usr/local/lib/libobs-opengl.so.1 > #1 0x000000080c99c57b in ??? () at /usr/local/lib/libobs-opengl.so.1 > #2 0x000000080c995338 in device_create () at > /usr/local/lib/libobs-opengl.so.1 > #3 0x0000000803f9e9b0 in gs_create () at /usr/local/lib/libobs.so.0 > #4 0x0000000803f41673 in obs_reset_video () at /usr/local/lib/libobs.so.= 0 > #5 0x00000000004bbc48 in ??? () > #6 0x00000000004b9b16 in ??? () > #7 0x00000000004147de in ??? () > #8 0x000000000041a8e1 in ??? () > #9 0x000000080505887a in __libc_start1 > (argc=3D1, argv=3D0x7fffffffd910, env=3D0x7fffffffd920, cleanup=3D out>, m > ainX=3D0x4191a0) at /usr/src/lib/libc/csu/libc_start1.c:157 > #10 0x00000000003f75a0 in ??? () > > My box: > > % uname -anbK > FreeBSD valfenda 15.0-CURRENT FreeBSD 15.0-CURRENT #3: Mon Jan 29 21:06:5= 3 > -03 2024 rizzo@valfenda:/usr/obj/usr/src/amd64.amd64/sys/GENERIC-NODE= BUG > amd64 1500012 c5ee0db87cb2833d50db2da0342580b6a2342920 > % > > TIA, > > Nilton Jose Rizzo > > > > --=20 Mario. --00000000000044fea906103e1c51 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
FreeBSD 15.0 is for development usage. You can't expec= t everything to work well. Try 14.0.

On Wed, Jan 31, 2024 at 2:36=E2=80= =AFPM Nilton Jose Rizzo <rizzo@riz= zo.eng.br> wrote:
Hi all

I trying to use OBS-Studio installed via pkg, but I get this erro:

% obs
debug: Attempted path: share/obs/obs-studio/locale/en-US.ini
debug: Attempted path: /usr/local/share/obs/obs-studio/locale/en-US.ini
debug: Attempted path: share/obs/obs-studio/locale.ini
debug: Attempted path: /usr/local/share/obs/obs-studio/locale.ini
debug: Attempted path: share/obs/obs-studio/themes/Yami.qss
debug: Attempted path: /usr/local/share/obs/obs-studio/themes/Yami.qss
warning: [Safe Mode] Unclean shutdown detected!
warning: [Safe Mode] User elected to launch normally.
info: Using EGL/X11
info: CPU Name: AMD Ryzen 5 2600 Six-Core Processor=C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0
info: CPU Speed: 3393.81MHz
info: Physical Cores: 2, Logical Cores: 12
info: Physical Memory: 15843MB Total, 5950MB Free
info: Kernel Version: FreeBSD 15.0-CURRENT
info: Distribution: FreeBSD "15.0"
info: Window System: X11.0, Vendor: The X.Org Foundation, Version: 1.21.1 info: Qt Version: 6.6.1 (runtime), 6.6.1 (compiled)
info: Portable mode: false
info: OBS 30.0.2 (freebsd)
info: ---------------------------------
info: ---------------------------------
info: audio settings reset:
=C2=A0 =C2=A0 =C2=A0 =C2=A0 samples per sec: 48000
=C2=A0 =C2=A0 =C2=A0 =C2=A0 speakers:=C2=A0 =C2=A0 =C2=A0 =C2=A0 2
=C2=A0 =C2=A0 =C2=A0 =C2=A0 max buffering:=C2=A0 =C2=A0960 milliseconds
=C2=A0 =C2=A0 =C2=A0 =C2=A0 buffering type:=C2=A0 dynamically increasing info: ---------------------------------
info: Initializing OpenGL...
Segmentation fault

When I execute OBS-Studio, it show a windows asking to I choose Normal or S= afe Mode, in both cases it's crash.

Note this port is using QT6.

I trying to reinstall OBS-Studio via ports and the error was keeping.

using cgdb I get this infomations:

info: audio settings reset:
=C2=A0 =C2=A0 =C2=A0 =C2=A0 samples per sec: 48000
=C2=A0 =C2=A0 =C2=A0 =C2=A0 speakers:=C2=A0 =C2=A0 =C2=A0 =C2=A0 2
=C2=A0 =C2=A0 =C2=A0 =C2=A0 max buffering:=C2=A0 =C2=A0960 milliseconds
=C2=A0 =C2=A0 =C2=A0 =C2=A0 buffering type:=C2=A0 dynamically increasing [New LWP 283537 of process 52911]
info: ---------------------------------
info: Initializing OpenGL...

Thread 1 received signal SIGSEGV, Segmentation fault.
Address not mapped to object.
0x000000080c99d84b in gladLoadGL () from /usr/local/lib/libobs-opengl.so.1<= br> (gdb) bt
#0=C2=A0 0x000000080c99d84b in gladLoadGL () at /usr/local/lib/libobs-openg= l.so.1
#1=C2=A0 0x000000080c99c57b in ??? () at /usr/local/lib/libobs-opengl.so.1<= br> #2=C2=A0 0x000000080c995338 in device_create () at /usr/local/lib/libobs-op= engl.so.1
#3=C2=A0 0x0000000803f9e9b0 in gs_create () at /usr/local/lib/libobs.so.0 #4=C2=A0 0x0000000803f41673 in obs_reset_video () at /usr/local/lib/libobs.= so.0
#5=C2=A0 0x00000000004bbc48 in ??? ()
#6=C2=A0 0x00000000004b9b16 in ??? ()
#7=C2=A0 0x00000000004147de in ??? ()
#8=C2=A0 0x000000000041a8e1 in ??? ()
#9=C2=A0 0x000000080505887a in __libc_start1
=C2=A0 =C2=A0 (argc=3D1, argv=3D0x7fffffffd910, env=3D0x7fffffffd920, clean= up=3D<optimized out>, m
ainX=3D0x4191a0) at /usr/src/lib/libc/csu/libc_start1.c:157
#10 0x00000000003f75a0 in ??? ()

My box:

% uname -anbK
FreeBSD valfenda 15.0-CURRENT FreeBSD 15.0-CURRENT #3: Mon Jan 29 21:06:53 = -03 2024=C2=A0 =C2=A0 =C2=A0rizzo@valfenda:/usr/obj/usr/src/amd64.amd64/sys= /GENERIC-NODEBUG amd64 1500012 c5ee0db87cb2833d50db2da0342580b6a2342920
%

TIA,

Nilton Jose Rizzo





--
Mario.
--00000000000044fea906103e1c51-- From nobody Wed Jan 31 17:35:32 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 4TQ8MD4lc8z58wSm for ; Wed, 31 Jan 2024 17:35:36 +0000 (UTC) (envelope-from garga@FreeBSD.org) Received: from smtp.freebsd.org (smtp.freebsd.org [96.47.72.83]) (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-signature RSA-PSS (4096 bits) client-digest SHA256) (Client CN "smtp.freebsd.org", Issuer "R3" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4TQ8MD4D7Dz4K5h; Wed, 31 Jan 2024 17:35:36 +0000 (UTC) (envelope-from garga@FreeBSD.org) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=freebsd.org; s=dkim; t=1706722536; 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: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=raOPQ8/5FF7LHfUZcAz2pO4RlBxhF5HY+1ENYxJAkQo=; b=IFx4QuXlyPtI6ROHUJFTf0BX6S+lMsL7SNmP/qWC9bQT6v12Qx/DxODIyiSUUQQmuzp1RR I+B0DSZikTMt42/Ae+HzDd9JIU6hy0EjKrl0N25RuyGqLpTjCmfypdd+IahkQ+PGwfI8EH YSYi7Ab1qwUr7seTIxB2hqeDiJF+4vdTJbOVQ29o2NQkQ5xiol66pkIrkPNdwXTqy6U9Tx cvrPLlNgNvCC6r6NbBnoUkuv8h+8g63xKbg+1pL/eaEJLlPakdhLkxYsbu18qvdZqhQBaP 7NOssirylhI59wUuAoyD3G91MQ0WBpFkb//zr6HrVZybhO236udzNfJ4NkY6TA== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=freebsd.org; s=dkim; t=1706722536; 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: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=raOPQ8/5FF7LHfUZcAz2pO4RlBxhF5HY+1ENYxJAkQo=; b=xr53SZtnqXmx8TBf18to0Ce8pNYjDQCI+3/tDJUZkfOkyggsjUdTdWZsZpQ8tBs0eJvQoR G40zXP4miqHHuUK6Svk4en9k0sZI/4xj1jc8v6hG+jgdf3wHSdhnrMN6dy4tc9UaewWOVG +KjLUARUAaKeEHDU7sob7cNIOoEKa+CO3ACOBPy0MmOu1R8L3gvZGgKwwU3cG4uyxbJSnW dj/pX2EWjb60qnRrOfwyt61LmoUxXXA3cRKJf8JxB3amEG0E85fwlOb8cjlwQVcY9kwIxG K3j7mwX8bAQDwP4d4PyMpzAd6xMS9wTk2HdaO8CwS875xXs5zCm0ARM6CHqPSA== ARC-Authentication-Results: i=1; mx1.freebsd.org; none ARC-Seal: i=1; s=dkim; d=freebsd.org; t=1706722536; a=rsa-sha256; cv=none; b=NXRm1nbHVNki+b2vr20LqPExVjNnQE2sp3QHK2pfhe1Z27mNCa3x82V+W+IPNyw/SPO7Ww cLRT/ggX2bpwd6s/Bpe68wev4Z2MwiydiUALYFzi8LQx0HIwdOeu4UxeXMVS1oMNfpEjnr t2VWjnq4i+Doi5lm9SOG+HLCu4z1BHP58s8PVUCWwrkmG51z1J2bGMWM7/Q4nyjdZV0cdw bG/c6FYY6wdodrJ1eui2ioaR74mY0Fh7NxzyE0I6zI44lEQroyCuPU49kT1P2NA41nGmJF Hd5vgNtC5l0/LoopszaK3f1gn57PS/0Sa16d/fGsBx4DpOPWQsuwhDJmvKzd4Q== Received: from [172.21.4.172] (dynamic-177-53-82-16.telecominternet.net.br [177.53.82.16]) (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 did not present a certificate) (Authenticated sender: garga) by smtp.freebsd.org (Postfix) with ESMTPSA id 4TQ8MC6nj2z103Y; Wed, 31 Jan 2024 17:35:35 +0000 (UTC) (envelope-from garga@FreeBSD.org) Message-ID: Date: Wed, 31 Jan 2024 14:35:32 -0300 List-Id: Porting software to FreeBSD List-Archive: https://lists.freebsd.org/archives/freebsd-ports List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-ports@freebsd.org X-BeenThere: freebsd-ports@freebsd.org MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: problem with Obs-Studio To: Mario Marietto , Nilton Jose Rizzo Cc: ports@freebsd.org References: <202401311336.40VDaQrJ080028@mailhost.i805.com.br> Content-Language: en-US From: Renato Botelho In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit On 31/01/24 10:46, Mario Marietto wrote: > FreeBSD 15.0 is for development usage. You can't expect everything to > work well. Try 14.0. I don't think this is the proper answer here. Of course CURRENT is not the stable distribution, but, if a user finds a bug on it and reports it to the project, the problem should be investigated and fixed. More people using CURRENT means it's going to be better tested and it's good to everyone. -- Renato Botelho From nobody Wed Jan 31 18:18:11 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 4TQ9K645Qhz590pV for ; Wed, 31 Jan 2024 18:18:50 +0000 (UTC) (envelope-from marietto2008@gmail.com) Received: from mail-ej1-x635.google.com (mail-ej1-x635.google.com [IPv6:2a00:1450:4864:20::635]) (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 4TQ9K60BS0z4NyH; Wed, 31 Jan 2024 18:18:50 +0000 (UTC) (envelope-from marietto2008@gmail.com) Authentication-Results: mx1.freebsd.org; none Received: by mail-ej1-x635.google.com with SMTP id a640c23a62f3a-a354408e6bfso201600266b.1; Wed, 31 Jan 2024 10:18:49 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1706725128; x=1707329928; darn=freebsd.org; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:from:to:cc:subject:date:message-id:reply-to; bh=ebfCMGwJhP7ptc9VyZWpsb/4gK6pf9IPD5ZQ+rfNnHw=; b=XD+iwfMYRkKw+JjkIH1vESGw7DnKvutOJG3vDqqfUnp2j1y6VxqFprA2OrTS/CmMF0 tedob3eFtV6uDIgjCEzK5mL8IFsDf6ScaKLS/i18Rf5fafhhzTINSUrmKvUqBzfuHKPQ iye9uBzixqWsZtaHXEGsrjZLMrsWQ+jiiSvkHfw3WwIjN63C7WkFDHp/4TahGWZQxS+n BganZjYBB745YG+GQLbb2ASdhX1CdMt+lHBMxDxr2pWBwt2x/TUNH7c/w4NVs8SQ3Dby DNXTt99ZcyJZykyycpwPA7D/E3FJ2saZNfMujuhdhAc7yuInwKTuryoF4SGAI4l6+Zw6 QQ/w== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1706725128; x=1707329928; 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=ebfCMGwJhP7ptc9VyZWpsb/4gK6pf9IPD5ZQ+rfNnHw=; b=s6pPAkI30Vv6uwoWyr+bur0zwXTlKpyBXLKIA7E/CwqgrpQNCP+7K2ZtL8U9hqFV0b ytUmJoMsSm4epAV5Ez4LjORiz/AcDkDlpipnbcNANZkUFm9PcOEd+hglT/vmGhahuC9C LAspmPRbNzCkFDAdyRHcHgczFyx/7nb/XsWFIFBaJiwDYKMovLxDAkmW/KFcsT0aRtJb J4Tj0xfHnZ8uyiXB01aGNlMLWRKqtW1IFTcojuAEhH/Re4mSNuOQDUEg84+4/XQs4HzA MBRpcJ9Tu6ogwXJ1XhmNMTUuMupQpgnuEjJiK9DNDEdVTV7ESDeNEuoFp/cS82QTgrdw 8xLw== X-Gm-Message-State: AOJu0YwLAjd3iEjAsyRuQJYPccU0nlN3odFXAI+GaqQN/iVt+FsjQJTN qIRjYwHSlwTIxq3MMn+ZpALQBjNu82azJsMBnymzHDjgAEoiUxTFyz6c/ds/ihJhTUjbPZsQig0 kEci4bskaRNCc66kg1Z2Mx175Al9Uu+hB X-Google-Smtp-Source: AGHT+IFQao4oLQ1J45g5gvcj/THpEup9ayNPI8k6jsgoqXi084FuAoVhxPtH4rsiMf6spSGIwMSa8SIBNB9y6Vhct04= X-Received: by 2002:a17:907:a4c1:b0:a35:bd6a:60bf with SMTP id vq1-20020a170907a4c100b00a35bd6a60bfmr5988484ejc.17.1706725128028; Wed, 31 Jan 2024 10:18:48 -0800 (PST) List-Id: Porting software to FreeBSD List-Archive: https://lists.freebsd.org/archives/freebsd-ports List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-ports@freebsd.org X-BeenThere: freebsd-ports@freebsd.org MIME-Version: 1.0 References: <202401311336.40VDaQrJ080028@mailhost.i805.com.br> In-Reply-To: From: Mario Marietto Date: Wed, 31 Jan 2024 19:18:11 +0100 Message-ID: Subject: Re: problem with Obs-Studio To: Renato Botelho Cc: Nilton Jose Rizzo , ports@freebsd.org Content-Type: multipart/alternative; boundary="000000000000fc4767061041e8d6" X-Rspamd-Queue-Id: 4TQ9K60BS0z4NyH 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:2a00:1450::/32, country:US] --000000000000fc4767061041e8d6 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable For sure. I meant only that if he wants to have a "stable" version of FreeBSD he should use 14.0,not 15. I said this because I'm not sure that he understood what version of FreeBSD he choses. So,if he chooses 15 I hope that he is ready to feel some frustration and that he knows that he's helping developers to fix bugs and it will take some time,time taken to him and to developers themself. On Wed, Jan 31, 2024 at 6:35=E2=80=AFPM Renato Botelho = wrote: > On 31/01/24 10:46, Mario Marietto wrote: > > FreeBSD 15.0 is for development usage. You can't expect everything to > > work well. Try 14.0. > > I don't think this is the proper answer here. Of course CURRENT is not > the stable distribution, but, if a user finds a bug on it and reports it > to the project, the problem should be investigated and fixed. > > More people using CURRENT means it's going to be better tested and it's > good to everyone. > -- > Renato Botelho > > --=20 Mario. --000000000000fc4767061041e8d6 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
For sure. I meant only that if he wants to have a &qu= ot;stable" version of FreeBSD he should use 14.0,not 15. I said this b= ecause I'm not sure that he understood what version of FreeBSD he chose= s. So,if he chooses 15 I hope that he is ready to feel some frustration and= that he knows that he's helping developers to fix bugs and it will tak= e some time,time taken to him and to developers themself.

On Wed, Jan 31, 2024 at 6:35=E2=80=AFPM Renato Botelho <garga@freebsd.org> wrote:
On 31/01/24 10:46, Mario Mar= ietto wrote:
> FreeBSD 15.0 is for development usage. You can't expect everything= to
> work well. Try 14.0.

I don't think this is the proper answer here.=C2=A0 Of course CURRENT i= s not
the stable distribution, but, if a user finds a bug on it and reports it to the project, the problem should be investigated and fixed.

More people using CURRENT means it's going to be better tested and it&#= 39;s
good to everyone.
--
Renato Botelho



--
Mario.
--000000000000fc4767061041e8d6-- From nobody Wed Jan 31 19:21:17 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 4TQBjF6Vjnz586hD for ; Wed, 31 Jan 2024 19:21:21 +0000 (UTC) (envelope-from jbeich@freebsd.org) Received: from freefall.freebsd.org (freefall.freebsd.org [IPv6:2610:1c1:1:6074::16:84]) (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-signature RSA-PSS (4096 bits) client-digest SHA256) (Client CN "freefall.freebsd.org", Issuer "R3" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4TQBjF62tjz4YlK; Wed, 31 Jan 2024 19:21:21 +0000 (UTC) (envelope-from jbeich@freebsd.org) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=freebsd.org; s=dkim; t=1706728881; 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:references:references; bh=R79hG03o7gyoGpdftu10fQJ7Zv1U4JvQBNCiYrsfo9k=; b=pJ4gs5dbjkBhlpvxHUNW7z3Br5WT0SI5r/y63iL/0UIKXCnY3FAtneUlXPgFluHFB/bZDy nWzGqFZYmEfAwuEmRIaLLUow6CCAy2XUJ+ggDVZYiDAS9ees8dKfxsOl4vIYvVDDc8egjS dhyb3hk0nQ3uj/Hya+ZRVS1RR1a4QPvGX3c8GLv3aLxXUm9YvbPcy0OeNpIml8/iI3TKoO Dcfyx+juTZZwr7v/xXip4Gk2UQUG/x7n6Ns7hwsqfiaKEWQAHsojocOhodc4eJrmFCmMgJ YwSEjw6sUCSv4YZSWuBXvwZbQ6zaRAVoBNg6wi8O93J1qL5Kep+3ss8r24mCSw== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=freebsd.org; s=dkim; t=1706728881; 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:references:references; bh=R79hG03o7gyoGpdftu10fQJ7Zv1U4JvQBNCiYrsfo9k=; b=Pp5/UMhOlvGANKoeIsU7KBpsUU3QrGX5XPl7Z9EtQ+ZigKm0Az4MGI94cyi7qOUa6jORv/ k028tRTbJg6UgI8TRevm+HN/rdq2+VbH6D2u4Wl2+S8GpWG3zb/wtOLGSAIII5iagUpsFx YQ0tqQTjcgxGImdzE1rlVfm3WUrmxn4uiTGKUx704s/GNJg07m4ZUhg8eIDt6oP7NftqzE Boo/cHT/rD6SEbU9UOqnGCoJs8duVmF6tzJ1p6J7CpBCZ+KoiTIE8pr3x4pxPOCxV1NrZc 4hoeGdVQQSOtvhzE1HP2gRh//5jcMIsJTiTAFJwBh6e8ptNhzQSuTbhMfQgapQ== ARC-Authentication-Results: i=1; mx1.freebsd.org; none ARC-Seal: i=1; s=dkim; d=freebsd.org; t=1706728881; a=rsa-sha256; cv=none; b=wQWApZ8rsLHiKh3eys5YnBXaSoRqpL9o4V2EvPwj9BTdQEeJdehvX8eAEZ1q8JFSuJUmwe u8sudxhnaM5jBa/nl2cRCDpopkRgIOS2v27UQn1ZVbemX5A7gmQJpuO8YHICDuUTpQjZVX v3dhUCemwJPis005u17+srZxjMx4xWI/+S8aWNtnXf76pB9PWRGoEKOWh0ixhhcyR4pPPN +ZO3xYnLkwSAWAxuO/ovHxCQu8srQQFUanqCeOuBb85CljVSEsgqrbKyQ+f7y3sUJSTtGe BeCr0qvceP/I/6KaTGgvtPnnVMyqtKflz+DC7SCd4cHMHA5Z1Li/KZ2U8XypGQ== Received: by freefall.freebsd.org (Postfix, from userid 1354) id AC2F51DBE5; Wed, 31 Jan 2024 19:21:21 +0000 (UTC) From: Jan Beich To: Nilton Jose Rizzo Cc: ports@freebsd.org Subject: Re: problem with Obs-Studio In-Reply-To: <202401311336.40VDaQrJ080028@mailhost.i805.com.br> (Nilton Jose Rizzo's message of "Wed, 31 Jan 2024 10:36:26 -0300 (-03)") References: <202401311336.40VDaQrJ080028@mailhost.i805.com.br> Date: Wed, 31 Jan 2024 20:21:17 +0100 Message-ID: List-Id: Porting software to FreeBSD List-Archive: https://lists.freebsd.org/archives/freebsd-ports List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-ports@freebsd.org X-BeenThere: freebsd-ports@freebsd.org MIME-Version: 1.0 Content-Type: text/plain Nilton Jose Rizzo writes: > [New LWP 283537 of process 52911] > info: --------------------------------- > info: Initializing OpenGL... > > Thread 1 received signal SIGSEGV, Segmentation fault. > Address not mapped to object. > 0x000000080c99d84b in gladLoadGL () from /usr/local/lib/libobs-opengl.so.1 > (gdb) bt > #0 0x000000080c99d84b in gladLoadGL () at /usr/local/lib/libobs-opengl.so.1 > #1 0x000000080c99c57b in ??? () at /usr/local/lib/libobs-opengl.so.1 > #2 0x000000080c995338 in device_create () at /usr/local/lib/libobs-opengl.so.1 > #3 0x0000000803f9e9b0 in gs_create () at /usr/local/lib/libobs.so.0 > #4 0x0000000803f41673 in obs_reset_video () at /usr/local/lib/libobs.so.0 > #5 0x00000000004bbc48 in ??? () > #6 0x00000000004b9b16 in ??? () > #7 0x00000000004147de in ??? () > #8 0x000000000041a8e1 in ??? () > #9 0x000000080505887a in __libc_start1 > (argc=1, argv=0x7fffffffd910, env=0x7fffffffd920, cleanup=, m > ainX=0x4191a0) at /usr/src/lib/libc/csu/libc_start1.c:157 > #10 0x00000000003f75a0 in ??? () [...] > % uname -anbK > FreeBSD valfenda 15.0-CURRENT FreeBSD 15.0-CURRENT #3: Mon Jan 29 21:06:53 -03 2024 rizzo@valfenda:/usr/obj/usr/src/amd64.amd64/sys/GENERIC-NODEBUG amd64 1500012 c5ee0db87cb2833d50db2da0342580b6a2342920 Likely a buggy GPU driver. Can you try graphics/kmscube under VT console? Also provide more details: - "pciconf -lv | fgrep -A4 vga" output - "pkg info -x drm mesa" output - "glxinfo -B" output From nobody Wed Jan 31 20:16:22 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 4TQCwn2NkGz58CfK for ; Wed, 31 Jan 2024 20:16:25 +0000 (UTC) (envelope-from bdrewery@FreeBSD.org) Received: from freefall.freebsd.org (freefall.freebsd.org [96.47.72.132]) (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-signature RSA-PSS (4096 bits) client-digest SHA256) (Client CN "freefall.freebsd.org", Issuer "R3" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4TQCwn1KBmz4gkh; Wed, 31 Jan 2024 20:16:25 +0000 (UTC) (envelope-from bdrewery@FreeBSD.org) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=freebsd.org; s=dkim; t=1706732185; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:mime-version:mime-version:content-type:content-type: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=J+O6Ye6n9nYp5OUOa54CfBxByDG1zC1Lo249JUjDyOI=; b=S2By3DqGp4k+mLfzd0qt7tPtdfmUeZHYFiPA99osQfzncrvxAjiSME0Ep2o+f8HInBapsa ZRXbmVGiI5LgU8+VOd/YVhXzK2JPJqYGLOZTFpWdJ8QhzQNUcqr/+GSmxNdrvyNLhfL0/X AhWOLm/mheJuRpb73kzfpuAm9i7AIsanXLeWcDx+ADYVkA8b+RhoHPNcQJoZNXbFm38Jmu osaOefNmjcMFRY2OKhdlUJHPYMJw6TznttVRdlGJUQZuLWMlx9waK675KuOLRfTKOccslY IpzMOYQn/K2dUT4EnV5GpTK3vzYoDX8NIfC2sg5sqDr+/ZPgU+zTXObaH0ZsdA== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=freebsd.org; s=dkim; t=1706732185; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:mime-version:mime-version:content-type:content-type: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=J+O6Ye6n9nYp5OUOa54CfBxByDG1zC1Lo249JUjDyOI=; b=oGoImmzfDjgtWWnF9UN84ogbcNG1pbF9eITX1iWHy8JXCRx8wZROMplmhUlpwL5FibXhUd 9m1rm9XO1S7VLSQ0Wkv6xwoPwJtgwyeAbGnjXRXHyVp83wBNJ57rMoikvqtyZfZlS2IRMh xX/2lsCSeHWa9/YjvRzxhjpRWVQUhOA/mKvXLigUGUzzskvk97DGCQBZzdW2/PpVkkQOxI RUhJ2O5YzySXqHigtJvn3p+Y0SX9DLi1C1MjpgaBGHuyGgMr+YWNMM+PxPiwhp+F8hnaOa kjZauZbVbl53PZOUx/tY5UScFnN7VaEg891Tm2FNrzgT7ilyfsOqFYjYEkux+Q== ARC-Authentication-Results: i=1; mx1.freebsd.org; none ARC-Seal: i=1; s=dkim; d=freebsd.org; t=1706732185; a=rsa-sha256; cv=none; b=UT/nz6kUdokSYzO7XN8LtA4QP+fmraZtJNkQWlF30q9xluQrdLdjbsE8gPRBipApfIwAHD fpfhIXIs/APILzsYDeA4cehjl040NtWtLTeAw2K/hJF6U5GDubmecAzBUV+k9OmvmBCfwN p7KrxuIDscVW/vPu6RZ+fziXHjgyDTbXcHgtX5qdbqCimXfqwwdQOPe3KogW2+n2oaU0nQ /ZRoTDPZAPmVK4/7C7ZdJd0HUAG/Ms6UIfzEBGaZmeahcypeT1skCgcP37SsojeF5gdysO nNXIxwTlCgCDJGzNLzZwZd+dey3vSEvO7Bkkpqdnq8DAhd7TaB+/gS0iQhexbg== Received: from mail.xzibition.com (unknown [127.0.1.132]) (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 freefall.freebsd.org (Postfix) with ESMTPS id F219F1E14A; Wed, 31 Jan 2024 20:16:24 +0000 (UTC) (envelope-from bdrewery@FreeBSD.org) Received: from mail.xzibition.com (localhost [172.31.3.2]) by mail.xzibition.com (Postfix) with ESMTP id 4781E66D6; Wed, 31 Jan 2024 12:16:24 -0800 (PST) X-Virus-Scanned: amavisd-new at mail.xzibition.com Received: from mail.xzibition.com ([172.31.3.2]) by mail.xzibition.com (mail.xzibition.com [172.31.3.2]) (amavisd-new, port 10026) with LMTP id oAPnlh87nxfi; Wed, 31 Jan 2024 12:16:22 -0800 (PST) Message-ID: DKIM-Filter: OpenDKIM Filter v2.10.3 mail.xzibition.com B14CF66CD Date: Wed, 31 Jan 2024 12:16:22 -0800 List-Id: Porting software to FreeBSD List-Archive: https://lists.freebsd.org/archives/freebsd-ports List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-ports@freebsd.org X-BeenThere: freebsd-ports@freebsd.org MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: We need to do something about build times Content-Language: en-US To: Robert Clausecker , ports@freebsd.org References: From: Bryan Drewery Organization: FreeBSD In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit On 10/24/2023 12:12 PM, Robert Clausecker wrote: > - rework Poudriere's rebuild detection to not rebuild every port for > every random bullshit thing. For example, I don't see why ports need > to be rebuilt for transitive changes in build dependencies. E.g. if > port A has build depends on port B which build depends on port C, and > C is updated, then A has to be rebuilt despite its direct dependencies > being unchanged. This does not appear to be reasonable. I have this working in a private branch for a few years. Along with allowing Rust to build OFF of tmpfs, and avoiding gcc*/llvm*/rust building concurrently. It's been hard to find time to work on it and get proper testing; there have been a lot of issues identified. I think it's stable now, but the subpackages work that went into Poudriere recently requires me to rebase my work. It's a few hundred commits in conflict. It's so massive I have not figured out how to move forward yet. I need to find time for it. If it were up to me I would strip out subpackages support because it has no tests, isn't properly supported in Poudriere (things needlessly rebuild), had its examples reverted, and has community pushback about it. As is once I find time to get my changes rebased in I need to add tests and proper support for subpackages. -- Bryan Drewery From nobody Wed Jan 31 22:12:52 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 4TQGWH5GbGz58PWw for ; Wed, 31 Jan 2024 22:12:59 +0000 (UTC) (envelope-from junchoon@dec.sakura.ne.jp) Received: from www121.sakura.ne.jp (www121.sakura.ne.jp [153.125.133.21]) (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 4TQGWH16Xbz3y1k; Wed, 31 Jan 2024 22:12:58 +0000 (UTC) (envelope-from junchoon@dec.sakura.ne.jp) Authentication-Results: mx1.freebsd.org; none Received: from kalamity.joker.local (123-1-91-49.area1b.commufa.jp [123.1.91.49]) (authenticated bits=0) by www121.sakura.ne.jp (8.17.1/8.17.1/[SAKURA-WEB]/20201212) with ESMTPA id 40VMCrHx025687; Thu, 1 Feb 2024 07:12:53 +0900 (JST) (envelope-from junchoon@dec.sakura.ne.jp) Date: Thu, 1 Feb 2024 07:12:52 +0900 From: Tomoaki AOKI To: Mario Marietto Cc: Renato Botelho , Nilton Jose Rizzo , ports@freebsd.org Subject: Re: problem with Obs-Studio Message-Id: <20240201071252.ccdd8ca050d84f05aee67023@dec.sakura.ne.jp> In-Reply-To: References: <202401311336.40VDaQrJ080028@mailhost.i805.com.br> Organization: Junchoon corps X-Mailer: Sylpheed 3.7.0 (GTK+ 2.24.33; amd64-portbld-freebsd14.0) List-Id: Porting software to FreeBSD List-Archive: https://lists.freebsd.org/archives/freebsd-ports List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-ports@freebsd.org X-BeenThere: freebsd-ports@freebsd.org Mime-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit X-Rspamd-Queue-Id: 4TQGWH16Xbz3y1k 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:7684, ipnet:153.125.128.0/18, country:JP] Most possible use-case why end-user runs main (aka -current) branch would be "I want this device to be availabe. But it's supported only on main branch!". Maybe especially on notebooks. For example, GPUs requiring graphics/drm-61-kmod forces main for now. Maybe it would be nice if snapshot images on main branch are provided at relatively stable commits, not in regular basis like dayly, weekly and/or monthly. Main branch is not always unstable or broken. ;-) And git allows checking out src tree at specific commit for builder. On Wed, 31 Jan 2024 19:18:11 +0100 Mario Marietto wrote: > For sure. I meant only that if he wants to have a "stable" version of > FreeBSD he should use 14.0,not 15. I said this because I'm not sure that he > understood what version of FreeBSD he choses. So,if he chooses 15 I hope > that he is ready to feel some frustration and that he knows that he's > helping developers to fix bugs and it will take some time,time taken to him > and to developers themself. > > > On Wed, Jan 31, 2024 at 6:35 PM Renato Botelho wrote: > > > On 31/01/24 10:46, Mario Marietto wrote: > > > FreeBSD 15.0 is for development usage. You can't expect everything to > > > work well. Try 14.0. > > > > I don't think this is the proper answer here. Of course CURRENT is not > > the stable distribution, but, if a user finds a bug on it and reports it > > to the project, the problem should be investigated and fixed. > > > > More people using CURRENT means it's going to be better tested and it's > > good to everyone. > > -- > > Renato Botelho > > > > > > -- > Mario. -- Tomoaki AOKI From nobody Thu Feb 1 04:03:37 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 4TQQHt3GL6z58xSv for ; Thu, 1 Feb 2024 04:03:38 +0000 (UTC) (envelope-from portscout@FreeBSD.org) Received: from mxrelay.nyi.freebsd.org (mxrelay.nyi.freebsd.org [IPv6:2610:1c1:1:606c::19:3]) (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-signature RSA-PSS (4096 bits) client-digest SHA256) (Client CN "mxrelay.nyi.freebsd.org", Issuer "R3" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4TQQHt1V1Sz4jB4 for ; Thu, 1 Feb 2024 04:03:38 +0000 (UTC) (envelope-from portscout@FreeBSD.org) ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=freebsd.org; s=dkim; t=1706760218; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:mime-version:mime-version:content-type:content-type: content-transfer-encoding:content-transfer-encoding; bh=11C/yIn5h23I0gv96X3JSZZTHI4rH6rzViMHxdKRhPY=; b=P3kv8mb43vrldtVJ14i9NG0rTdImn3EjK0LAZOU+NFov8PX/y8oX6PCadoSe1yYZtBTr2B GEPkVQ9NKp/7/w3PbROMuLvgQE3UILLOdSO8oytDDmsFYlAHRi2r3Doa542a73Cq+w3vmh QYj99FROThnTbttE4oo+Jo8dg61mpxZgzPTWAHsElh5fWAGD8FVSQ7vPnEsvMRFsjXMren FYRARoCb0WE6osZVc8qiNwKdwoevMVuGg/VHwoUUwBK1pMYETyOraI4vn0ulnjGDH2hZG+ j4o5Foolo9X9VmdGxXhO2WmFbIAIVKfwyRrIog6U66PG4y3mwDJu7rDCWdk2GA== ARC-Authentication-Results: i=1; mx1.freebsd.org; none ARC-Seal: i=1; s=dkim; d=freebsd.org; t=1706760218; a=rsa-sha256; cv=none; b=erU0+QRy0iULkuTceWRs/QzywboI/SyMAVvNdrBy6eWrhUB8ZWHSnAKsp4aUmfZU+m5qt3 z1EVWnMSHHLQxpFFanAqB4LuNr8KlPBBiKgu5p8yhtWUBSIc+Mqi+5Z6shegOV/jdRivo8 aYs2sAY1PAIM58ALvUgVbxPgunS1aJJpW5EFhua5NifBUyokpwv+8aoWfz5Pvlx9Xu3lpt wTQFqUrlLgIHQav4wX6121PknpBubbyt+K5pFdeRUCJc+lY/nBHqWA+9GLAry9YK5zNJUl Cy0S4JqROTcThLlRbQoL49XZvj0DrN70ddYcDRusSj498sV4sa8d7SN6uoLy3g== Received: from portscout.nyi.freebsd.org (portscout.nyi.freebsd.org [IPv6:2610:1c1:1:606c::50:21]) (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 mxrelay.nyi.freebsd.org (Postfix) with ESMTPS id 4TQQHt0SmMznBY for ; Thu, 1 Feb 2024 04:03:38 +0000 (UTC) (envelope-from portscout@FreeBSD.org) Received: from portscout.nyi.freebsd.org ([127.0.1.10]) by portscout.nyi.freebsd.org (8.17.1/8.17.1) with ESMTP id 41143bMb023338 for ; Thu, 1 Feb 2024 04:03:37 GMT (envelope-from portscout@FreeBSD.org) Received: (from portscout@localhost) by portscout.nyi.freebsd.org (8.17.1/8.17.1/Submit) id 41143b6s023337; Thu, 1 Feb 2024 04:03:37 GMT (envelope-from portscout@FreeBSD.org) Message-Id: <202402010403.41143b6s023337@portscout.nyi.freebsd.org> X-Authentication-Warning: portscout.nyi.freebsd.org: portscout set sender to portscout@FreeBSD.org using -f Content-Disposition: inline Content-Transfer-Encoding: 8bit Content-Type: text/plain List-Id: Porting software to FreeBSD List-Archive: https://lists.freebsd.org/archives/freebsd-ports List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-ports@freebsd.org X-BeenThere: freebsd-ports@freebsd.org MIME-Version: 1.0 Date: Thu, 1 Feb 2024 04:03:37 +0000 From: portscout@FreeBSD.org To: ports@freebsd.org Subject: Unmaintained FreeBSD ports which are out of date X-Mailer: portscout/0.8.1 Dear port maintainers, The portscout new distfile checker has detected that one or more unmaintained ports appears to be out of date. Please take the opportunity to check each of the ports listed below, and if possible and appropriate, submit/commit an update. Please consider also adopting this port. If any ports have already been updated, you can safely ignore the entry. An e-mail will not be sent again for any of the port/version combinations below. Full details can be found at the following URL: http://portscout.freebsd.org/ports@freebsd.org.html Port | Current version | New version ------------------------------------------------+-----------------+------------ audio/baresip | 3.6.0 | v3.9.0 ------------------------------------------------+-----------------+------------ audio/re | 3.6.2 | v3.9.0 ------------------------------------------------+-----------------+------------ devel/efivar | 0.15 | 39 ------------------------------------------------+-----------------+------------ devel/intel-graphics-compiler | 1.0.12504.5 | igc-1.0.15770.11 ------------------------------------------------+-----------------+------------ lang/intel-compute-runtime | 22.24.23453 | 23.52.28202.14 ------------------------------------------------+-----------------+------------ security/py-angr | 9.0.5405 | v9.2.87 ------------------------------------------------+-----------------+------------ sysutils/nerdctl | 1.7.2 | 1.7.3 ------------------------------------------------+-----------------+------------ If any of the above results are invalid, please check the following page for details on how to improve portscout's detection and selection of distfiles on a per-port basis: http://portscout.freebsd.org/info/portscout-portconfig.txt Reported by: portscout! From nobody Thu Feb 1 13:06:15 2024 X-Original-To: freebsd-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 4TQfLB6NRJz58c7r for ; Thu, 1 Feb 2024 13:06:26 +0000 (UTC) (envelope-from eduardo@freebsd.org) Received: from smtp.freebsd.org (smtp.freebsd.org [IPv6:2610:1c1:1:606c::24b:4]) (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-signature RSA-PSS (4096 bits) client-digest SHA256) (Client CN "smtp.freebsd.org", Issuer "R3" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4TQfLB5sCHz4VL1 for ; Thu, 1 Feb 2024 13:06:26 +0000 (UTC) (envelope-from eduardo@freebsd.org) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=freebsd.org; s=dkim; t=1706792786; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:mime-version:mime-version:content-type:content-type; bh=EZun+dOXB4Ux7qR8R3DTdJxtjhUGaJefmwtXJBFB/CQ=; b=kiP8FV1uP3Wvz5dMJqrWDZAQvK30mgMaw/OCYAspSWstNb9ckzWutfWEs8F5sHE+LqFLZ3 rq7Yx4Q1PJbPsLAQUMdJOe8ESTd2u0UKqIx8MwFBVTwdOMALF2k6OrdKB0lhnhRPiUJ9SW YIXimZFMGGfM4b/FS+A9CnnB1K9zZZxgqjOwyh8B4EFQIP3mKn8kMLkKAR2+vZJqTnBnBw N5Y3MzVFbfOdBdyLWhkJV4Fz9bvMXRI3iocd1b7qmpDM6cA7tg8IEcQ1e8lHbkvoto2ZLA bulIyShuFoC2Yvu/H4E0+KPft6mTzEVs3Nxvj8NmK4a07l7fN1FCqAKnWJC/1A== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=freebsd.org; s=dkim; t=1706792786; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:mime-version:mime-version:content-type:content-type; bh=EZun+dOXB4Ux7qR8R3DTdJxtjhUGaJefmwtXJBFB/CQ=; b=sgM8qe7wCoIFvQu2vWoa2zsPtKUjuXBehGipSs0LNhUf3O3q0I+PKLM1C+FSpCllmqyPVN 6Gb345fqVCX/UblbmrNi65Y4S9K09kxTFZaAekYkM42rSFZM0ohZHnYKMWr5FyKpk/MJ4r aEgBVyt9U/umLA/FNX+EdILP/qvBT48v4sOwpYwLX1AZDC7dHXWYVeeK9O1XrfvvxAmME1 wQxNKfT8/wybFzDVyNQpNVgh3Km+X/RyAfkYutCwoxdIHXkAFiYI5/hLvYuADn8b+J4MEP NWaTfbk9A3Q0cSlkVw5s6fM66uGJ0VRTi4lgmbI8L2L8paX0qewD66nrm42Y/Q== ARC-Authentication-Results: i=1; mx1.freebsd.org; none ARC-Seal: i=1; s=dkim; d=freebsd.org; t=1706792786; a=rsa-sha256; cv=none; b=QZ9NehjhFuD2HtXAAfrOuq3NwdPtVeRh4izWwWIP5PJnAudub6L0IhwV72dSOE6TlU1LTI JXwx7tgwy1q5OuK+yF/4/0+3+x2O7tbv6zRWInQkycJbZ45M1JJyQy2YiJm5sJC9gPR5Ph 1XlcldRQU0a+9zNnkrR+OivsKn4T/WJW7pzm7c5HMHkRIUOebYJy4Eu9Bxkyw3CKJ6B4e+ Bin7/zbM1r44ziiMNKRTsnZGnJLBdCkjvRc6qXDWFORZ4y0wXXgQO/VaToJyEpuxkA2g6o 5TNzoxYFmYpMVyNfG0IIPU58/V/hovGHlgSu5yeOYXaB0y5nbREDYugjvsDDYg== Received: from mail-qt1-f172.google.com (mail-qt1-f172.google.com [209.85.160.172]) (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)) (Authenticated sender: eduardo) by smtp.freebsd.org (Postfix) with ESMTPSA id 4TQfLB4p4Jz1LfM for ; Thu, 1 Feb 2024 13:06:26 +0000 (UTC) (envelope-from eduardo@freebsd.org) Received: by mail-qt1-f172.google.com with SMTP id d75a77b69052e-42ab4f6daf2so2976581cf.3 for ; Thu, 01 Feb 2024 05:06:26 -0800 (PST) X-Gm-Message-State: AOJu0YxUlCkZKC4vbiAF1v7eDtq4v/FyeV279VsFtV/51Q19o2kYF28B 5+rjPgUtK2XjKpUntbxIxWPF6wvjutfguSsvD9HS8cXSh2bIpk3le3Hiff0cfIE/GRHbvwrmwtq OJUDDvKHIZ0EXNWhN1/jfKgHws5c= X-Google-Smtp-Source: AGHT+IFA21Wfb+GQ6M1IOhMKfu2ekPJUHXuq8APn4CO3ROgBT5f09l0Oj05v9c82f6wl9Ez5NG8j0LTLmb6PkiDhM8M= X-Received: by 2002:ac8:5909:0:b0:42a:b73d:447e with SMTP id 9-20020ac85909000000b0042ab73d447emr6211627qty.15.1706792786229; Thu, 01 Feb 2024 05:06:26 -0800 (PST) List-Id: Porting software to FreeBSD List-Archive: https://lists.freebsd.org/archives/freebsd-ports List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-ports@freebsd.org X-BeenThere: freebsd-ports@freebsd.org MIME-Version: 1.0 From: Nuno Teixeira Date: Thu, 1 Feb 2024 13:06:15 +0000 X-Gmail-Original-Message-ID: Message-ID: Subject: port shares same binary and manual names with base ztest (ZFS) To: FreeBSD Mailing List Content-Type: multipart/alternative; boundary="000000000000ba8341061051a9ae" --000000000000ba8341061051a9ae Content-Type: text/plain; charset="UTF-8" Hello all, archivers/ztools shares binary ztest and manual ztest.1 with base ZFS. Is there a policy to deal with it? If someone knows a port that shares same issue, please let me know. /usr/bin/ztest /usr/share/man/man1/ztest.1.gz PREFIX/bin/ztest PREFIX/man/man1/ztest.1.gz Thanks, -- Nuno Teixeira FreeBSD Committer (ports) --000000000000ba8341061051a9ae Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Hello all,

archivers/ztools = shares binary ztest and manual ztest.1 with base ZFS.
Is there a = policy to deal with it?

If someone knows a port th= at shares same issue, please let me know.

/usr/bin= /ztest
/usr/share/man/man1/ztest.1.gz

PR= EFIX/bin/ztest
PREFIX/man/man1/ztest.1.gz

Thank= s,

--
<= div dir=3D"ltr" class=3D"gmail_signature" data-smartmail=3D"gmail_signature= ">
Nuno Teixeira
= FreeBSD Committer (ports)
--000000000000ba8341061051a9ae-- From nobody Thu Feb 1 14:05:26 2024 X-Original-To: freebsd-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 4TQgfQ0cd5z58j9D for ; Thu, 1 Feb 2024 14:05:34 +0000 (UTC) (envelope-from junchoon@dec.sakura.ne.jp) Received: from www121.sakura.ne.jp (www121.sakura.ne.jp [153.125.133.21]) (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 4TQgfP3HXLz4fGp; Thu, 1 Feb 2024 14:05:32 +0000 (UTC) (envelope-from junchoon@dec.sakura.ne.jp) Authentication-Results: mx1.freebsd.org; none Received: from kalamity.joker.local (123-1-91-49.area1b.commufa.jp [123.1.91.49]) (authenticated bits=0) by www121.sakura.ne.jp (8.17.1/8.17.1/[SAKURA-WEB]/20201212) with ESMTPA id 411E5QVR087353; Thu, 1 Feb 2024 23:05:27 +0900 (JST) (envelope-from junchoon@dec.sakura.ne.jp) Date: Thu, 1 Feb 2024 23:05:26 +0900 From: Tomoaki AOKI To: Nuno Teixeira Cc: FreeBSD Mailing List Subject: Re: port shares same binary and manual names with base ztest (ZFS) Message-Id: <20240201230526.07da35af24e2723b14ebe240@dec.sakura.ne.jp> In-Reply-To: References: Organization: Junchoon corps X-Mailer: Sylpheed 3.7.0 (GTK+ 2.24.33; amd64-portbld-freebsd14.0) List-Id: Porting software to FreeBSD List-Archive: https://lists.freebsd.org/archives/freebsd-ports List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-ports@freebsd.org X-BeenThere: freebsd-ports@freebsd.org Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-Rspamd-Queue-Id: 4TQgfP3HXLz4fGp 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:7684, ipnet:153.125.128.0/18, country:JP] On Thu, 1 Feb 2024 13:06:15 +0000 Nuno Teixeira wrote: > Hello all, > > archivers/ztools shares binary ztest and manual ztest.1 with base ZFS. > Is there a policy to deal with it? > > If someone knows a port that shares same issue, please let me know. > > /usr/bin/ztest > /usr/share/man/man1/ztest.1.gz > > PREFIX/bin/ztest > PREFIX/man/man1/ztest.1.gz > > Thanks, > > -- > Nuno Teixeira > FreeBSD Committer (ports) AFAIK, at least archivers/unzip [1] has the same issue. But base unzip and its manpage is now a symlink to bsdunzip. FYI: command other than `man /usr/local/share/man/man1/unzip.1.gz` for unzip shows `man 1 bsdunzip`. even `man -M /usr/local/share/man/man1 unzip` shown bsdunzip's one. [1] https://www.freshports.org/archivers/unzip/ -- Tomoaki AOKI From nobody Fri Feb 2 04:06:40 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 4TR2Jw4gS8z59LK3 for ; Fri, 2 Feb 2024 04:06:40 +0000 (UTC) (envelope-from portscout@FreeBSD.org) Received: from mxrelay.nyi.freebsd.org (mxrelay.nyi.freebsd.org [IPv6:2610:1c1:1:606c::19:3]) (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-signature RSA-PSS (4096 bits) client-digest SHA256) (Client CN "mxrelay.nyi.freebsd.org", Issuer "R3" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4TR2Jw32HHz4Kkc for ; Fri, 2 Feb 2024 04:06:40 +0000 (UTC) (envelope-from portscout@FreeBSD.org) ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=freebsd.org; s=dkim; t=1706846800; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:mime-version:mime-version:content-type:content-type: content-transfer-encoding:content-transfer-encoding; bh=90lp7RYcFYEAgQPOa7TFRIJl9i3L89fnuh0tkeuUIMo=; b=Y7htbanquuN7g1yrKvcSL4zcUtIZjsE+q98krpWmW6NARS2fukqTzsQ0EFjnZZB36TofwX EkGFIG2BYeD2IsIiUS3ahPRXblbxt+lyQRFpLMOh1mNFGnW0WUZuj5Pu/lRhzoci2CFpEQ 66luYOEHWzP31UXv+CKiR/P/6J7IN/XHWq78bz7OItQrGy9caAUk9Iry54WgedHG4dX2R7 DcOFzLzcS4N+CNHOWAkMxh/pWAi/OTGPWYVmlwQAtJGuFeQHhLzJDsFFVJSANbj4inLPoQ hpoMhbIILoh5OMw69xZXGj1EUX1slWXVOyIp4o/ZcQejuDFKcFaui0fDKm5gXw== ARC-Authentication-Results: i=1; mx1.freebsd.org; none ARC-Seal: i=1; s=dkim; d=freebsd.org; t=1706846800; a=rsa-sha256; cv=none; b=H1XW1H6fc+jkyF4GHU6Wr7/QOziNtUL38HwhrmD3jcC+QmF+Tb8OXiLco8WxNtwJpRUvgQ pidiEsl9tfbV6eTaDiNaofcs7jwyqoIqVcNV4Zbt+RIuIHCp8ebhvEb5O87rhqqcOjvnzP 6p9n2Mrjl4ebcE6s9yvJ10e8hx258iUddmXXaUFJVLleMoF3v9FI+Mw8UTYvkKKONwTrKQ g4BhBwPWRo+ElBK9/U4wKdm/6YRqP1FKxPKDtTgR6VHo4Adrt6lyEVFw9JDabg9aRf9q07 FBkmWGALTaNiW9KAZR/5qop7tuydkagkdJRg9mTGp5hkNBJt5r2Y5x6FdgFx2Q== Received: from portscout.nyi.freebsd.org (portscout.nyi.freebsd.org [IPv6:2610:1c1:1:606c::50:21]) (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 mxrelay.nyi.freebsd.org (Postfix) with ESMTPS id 4TR2Jw27S6zFdK for ; Fri, 2 Feb 2024 04:06:40 +0000 (UTC) (envelope-from portscout@FreeBSD.org) Received: from portscout.nyi.freebsd.org ([127.0.1.10]) by portscout.nyi.freebsd.org (8.17.1/8.17.1) with ESMTP id 41246eAX061595 for ; Fri, 2 Feb 2024 04:06:40 GMT (envelope-from portscout@FreeBSD.org) Received: (from portscout@localhost) by portscout.nyi.freebsd.org (8.17.1/8.17.1/Submit) id 41246enQ061594; Fri, 2 Feb 2024 04:06:40 GMT (envelope-from portscout@FreeBSD.org) Message-Id: <202402020406.41246enQ061594@portscout.nyi.freebsd.org> X-Authentication-Warning: portscout.nyi.freebsd.org: portscout set sender to portscout@FreeBSD.org using -f Content-Disposition: inline Content-Transfer-Encoding: 8bit Content-Type: text/plain List-Id: Porting software to FreeBSD List-Archive: https://lists.freebsd.org/archives/freebsd-ports List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-ports@freebsd.org X-BeenThere: freebsd-ports@freebsd.org MIME-Version: 1.0 Date: Fri, 2 Feb 2024 04:06:40 +0000 From: portscout@FreeBSD.org To: ports@freebsd.org Subject: Unmaintained FreeBSD ports which are out of date X-Mailer: portscout/0.8.1 Dear port maintainers, The portscout new distfile checker has detected that one or more unmaintained ports appears to be out of date. Please take the opportunity to check each of the ports listed below, and if possible and appropriate, submit/commit an update. Please consider also adopting this port. If any ports have already been updated, you can safely ignore the entry. An e-mail will not be sent again for any of the port/version combinations below. Full details can be found at the following URL: http://portscout.freebsd.org/ports@freebsd.org.html Port | Current version | New version ------------------------------------------------+-----------------+------------ audio/asterisk-espeak | 5.0-rc1 | v5.0 ------------------------------------------------+-----------------+------------ cad/ifcopenshell | 0.6.0 | blenderbim-240201 ------------------------------------------------+-----------------+------------ devel/py-archinfo | 9.0.5405 | v9.2.88 ------------------------------------------------+-----------------+------------ devel/py-cle | 9.0.5405 | v9.2.88 ------------------------------------------------+-----------------+------------ math/py-claripy | 9.0.5405 | v9.2.88 ------------------------------------------------+-----------------+------------ net-p2p/py-nicotine-plus | 3.2.9 | 3.3.0 ------------------------------------------------+-----------------+------------ security/py-ailment | 9.0.5405 | v9.2.88 ------------------------------------------------+-----------------+------------ security/py-angr | 9.0.5405 | v9.2.88 ------------------------------------------------+-----------------+------------ security/py-pyvex | 9.0.5405 | v9.2.88 ------------------------------------------------+-----------------+------------ If any of the above results are invalid, please check the following page for details on how to improve portscout's detection and selection of distfiles on a per-port basis: http://portscout.freebsd.org/info/portscout-portconfig.txt Reported by: portscout! From nobody Fri Feb 2 17:23:45 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 4TRN0X5N3nz597pc for ; Fri, 2 Feb 2024 17:23:40 +0000 (UTC) (envelope-from niltonrizzo@gmail.com) Received: from mail-pg1-x532.google.com (mail-pg1-x532.google.com [IPv6:2607:f8b0:4864:20::532]) (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 4TRN0X0S0yz4YnK for ; Fri, 2 Feb 2024 17:23:40 +0000 (UTC) (envelope-from niltonrizzo@gmail.com) Authentication-Results: mx1.freebsd.org; dkim=pass header.d=gmail.com header.s=20230601 header.b="P4/Eecy0"; dmarc=pass (policy=none) header.from=gmail.com; spf=pass (mx1.freebsd.org: domain of niltonrizzo@gmail.com designates 2607:f8b0:4864:20::532 as permitted sender) smtp.mailfrom=niltonrizzo@gmail.com Received: by mail-pg1-x532.google.com with SMTP id 41be03b00d2f7-5ce9555d42eso2048934a12.2 for ; Fri, 02 Feb 2024 09:23:40 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1706894619; x=1707499419; darn=freebsd.org; h=content-transfer-encoding:subject:cc:to:from:content-language :user-agent:mime-version:date:message-id:from:to:cc:subject:date :message-id:reply-to; bh=HnbWXzfwiqNqFFF+Yljw6k2xhxLYxIXg9k7DxbExudc=; b=P4/Eecy0dx2bDn0qDFE2Tc+fvLCl5/qTdp8pzAb+l3MYko2O1GoAQUF0aBhIkybi+2 7TJsMFGoom2Keh0UdKunNena+SvpRO9FdPjisFm/UMKUa3ix3sO0oJlXvabbpQyNafnW h/g2aN6vzpsZ0UwDgLg3rpaEMWz/JpLY5JCWh5dpDorY9QiLDR7ElamecZGUV29Doo30 6Q3LUT0T4MSBA+xgUmHkZ4Fb/VBpqEog8qitTql/lG2BzNhRZCOw74YTRHGplJCnyZ1a bSF7TE+MePq5PNw7/ZzAq15msTAZZIbjJSCkcyi7Nu492CfGKcKCJ1IuZ/M49gqC8jGK +A7g== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1706894619; x=1707499419; h=content-transfer-encoding:subject:cc:to:from:content-language :user-agent:mime-version:date:message-id:x-gm-message-state:from:to :cc:subject:date:message-id:reply-to; bh=HnbWXzfwiqNqFFF+Yljw6k2xhxLYxIXg9k7DxbExudc=; b=iiSFCCvqtIgrhg8dnOEPcg5vBbyA1tn4KqVED85oEEyQj7WMFTcTywjlXTjXvThbYW tndap1h8rM3L3ztdg7FJSttw9xqTbcPpl41UmeaoGlpAfc2s9y5LLwzqHCY8Jf8K+K7E lberQgP0IK2JhGWVYJucfN90EdcIRX4d8cttaxYAHgnDL/n712JIAEczjzyOQMIF2+51 B2oZgQQG/KVIJIVgTk9Ks1pOMXlmw0aHWV/Gz5/djLe1kS3Kh34gqSdJ2fBFQPFN/Ca4 ivqMmQ0PrYGjwhc17465BXN0Kh6b2GUqwS/rs0qZQFIuPQXiXYm9r8U3rEUe+GtZ8w/A 4EcQ== X-Gm-Message-State: AOJu0YzVItJGWvtx6zmlYB5HpmELeZMmQd+gv242GbP82MBBg3hibNus 3dMKpxnQGq/EoU2Y/ZzN5ytTYtvMs0yB2T7iJ0ijGgxGqO7KWKyATacpFFGzsuc= X-Google-Smtp-Source: AGHT+IHsu8YyvVsavoQ+OseIo/R58kqdCefZrPx4zf0tvGmQVnzz/73WTuoru+MpfKMYs3FB/kvDSw== X-Received: by 2002:a05:6a21:2d08:b0:19e:3654:7d18 with SMTP id tw8-20020a056a212d0800b0019e36547d18mr3171341pzb.10.1706894618548; Fri, 02 Feb 2024 09:23:38 -0800 (PST) Received: from [192.168.0.200] ([186.221.166.131]) by smtp.gmail.com with ESMTPSA id m1-20020a62f201000000b006db13a02921sm1858170pfh.183.2024.02.02.09.23.37 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Fri, 02 Feb 2024 09:23:38 -0800 (PST) Message-ID: Date: Fri, 2 Feb 2024 14:23:45 -0300 List-Id: Porting software to FreeBSD List-Archive: https://lists.freebsd.org/archives/freebsd-ports List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-ports@freebsd.org X-BeenThere: freebsd-ports@freebsd.org MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Content-Language: pt-BR From: Nilton Jose Rizzo To: ports@freebsd.org Cc: jbeich@freebsd.orgq Subject: problem with Obs-Studio Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit X-Spamd-Bar: --- X-Spamd-Result: default: False [-3.57 / 15.00]; NEURAL_HAM_LONG(-1.00)[-1.000]; NEURAL_HAM_MEDIUM(-1.00)[-1.000]; NEURAL_HAM_SHORT(-0.58)[-0.577]; DMARC_POLICY_ALLOW(-0.50)[gmail.com,none]; R_DKIM_ALLOW(-0.20)[gmail.com:s=20230601]; R_SPF_ALLOW(-0.20)[+ip6:2607:f8b0:4000::/36]; MIME_GOOD(-0.10)[text/plain]; XM_UA_NO_VERSION(0.01)[]; RCVD_TLS_LAST(0.00)[]; FROM_HAS_DN(0.00)[]; ARC_NA(0.00)[]; FREEMAIL_ENVFROM(0.00)[gmail.com]; RCPT_COUNT_TWO(0.00)[2]; FREEMAIL_FROM(0.00)[gmail.com]; MIME_TRACE(0.00)[0:+]; DKIM_TRACE(0.00)[gmail.com:+]; ASN(0.00)[asn:15169, ipnet:2607:f8b0::/32, country:US]; RCVD_VIA_SMTP_AUTH(0.00)[]; TO_DN_NONE(0.00)[]; RCVD_COUNT_TWO(0.00)[2]; FROM_EQ_ENVFROM(0.00)[]; DWL_DNSWL_NONE(0.00)[gmail.com:dkim]; TO_MATCH_ENVRCPT_SOME(0.00)[]; MLMMJ_DEST(0.00)[ports@freebsd.org]; PREVIOUSLY_DELIVERED(0.00)[ports@freebsd.org]; MID_RHS_MATCH_FROM(0.00)[]; RCVD_IN_DNSWL_NONE(0.00)[2607:f8b0:4864:20::532:from] X-Rspamd-Queue-Id: 4TRN0X0S0yz4YnK Hi Jan Thankx for your replay please forgive me for the delay in responding. Follow all the infomation you request: # pciconf -lv | fgrep -A4 vga vgapci0@pci0:8:0:0:     class=0x030000 rev=0xa1 hdr=0x00 vendor=0x10de device=0x1c82 subvendor=0x1043 subdevice=0x8626     vendor     = 'NVIDIA Corporation'     device     = 'GP107 [GeForce GTX 1050 Ti]'     class      = display     subclass   = VGA # pkg info -x drm mesa libdrm-2.4.120,1 mesa-dri-23.3.3 mesa-libs-23.3.3 # glxinfo -B name of display: unix:0.0 display: unix:0  screen: 0 direct rendering: Yes Memory info (GL_NVX_gpu_memory_info):     Dedicated video memory: 4096 MB     Total available memory: 4096 MB     Currently available dedicated video memory: 3789 MB OpenGL vendor string: NVIDIA Corporation OpenGL renderer string: GeForce GTX 1050 Ti/PCIe/SSE2 OpenGL core profile version string: 4.5.0 NVIDIA 390.154 OpenGL core profile shading language version string: 4.50 NVIDIA OpenGL core profile context flags: (none) OpenGL core profile profile mask: core profile OpenGL version string: 4.5.0 NVIDIA 390.154 OpenGL shading language version string: 4.50 NVIDIA OpenGL context flags: (none) OpenGL profile mask: (none) OpenGL ES profile version string: OpenGL ES 3.2 NVIDIA 390.154 OpenGL ES profile shading language version string: OpenGL ES GLSL ES 3.20 TIA, Nilton Jose Rizzo From nobody Fri Feb 2 18:06:01 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 4TRNxV1YXvz59ByJ for ; Fri, 2 Feb 2024 18:06:06 +0000 (UTC) (envelope-from jbeich@freebsd.org) Received: from freefall.freebsd.org (freefall.freebsd.org [96.47.72.132]) (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-signature RSA-PSS (4096 bits) client-digest SHA256) (Client CN "freefall.freebsd.org", Issuer "R3" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4TRNxV0xTVz4dQ3; Fri, 2 Feb 2024 18:06:06 +0000 (UTC) (envelope-from jbeich@freebsd.org) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=freebsd.org; s=dkim; t=1706897166; 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:references:references; bh=yQ5R4pSp1JFMlpc9nx/9mKBqHmgcm5dPHr3pvhsXXyA=; b=x6lFXjUA6lBN3surVE8ZCP8VNcpFFCRjUrCojwLlc8JjpHJkNqf+6ZRy72wkHBlw5pKlRW pRGt0vqXkLUqmOLMmLeTGLWzVCt/CsOrOmaIaqSMeiQObq4mKRzW9/Ob9A7CB8JuDM3qap abAbfbt0lPXnfSyyRlxvDxPkMwak7tDTxbuF2SBkKXFZJNs80kThTIh/35prVQCPl0O9nb zV14BUjJaEIdp2WkHK9iAb7nUizq+UhsZ/U510/ntK8pqp9nRi57yEwbDTlE74PNBHCfVF NwPW8k2mmi3jZBWLcAdFJff5BYfo613NF7jiAYzG+emioTFwigHrcFBfYLeykQ== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=freebsd.org; s=dkim; t=1706897166; 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:references:references; bh=yQ5R4pSp1JFMlpc9nx/9mKBqHmgcm5dPHr3pvhsXXyA=; b=SkHR6+r/FtrJsUrPNGp73stHuuN4jCRPQR3R/0W27tE9ovx63sOLpQ35Mh45VHYioaGiHp gETvcyE6i9qStSwJthNE1qeBk5M4TRYtYgVQZJcfb5plOSm0zae5NGIul0WCPOvr4VPudt oAhSToxS1AwYq6pTsyqCuLYgwfXAln7SMzEURp79c+/gF6FaaeqQ4nwsM5D5KOaaRdkbum OKIImb+mxcTDE1/BVtbsbtdKFyCd5NKD2gwa0BwZEszRO7KbaURit3baaiXPNX5wAA+hQG M97FZVlIy5Kz3zwko4lf+kkv+Ce5DY/xXKtjYM381EMxCoexGmQOXz3n6XU0eA== ARC-Authentication-Results: i=1; mx1.freebsd.org; none ARC-Seal: i=1; s=dkim; d=freebsd.org; t=1706897166; a=rsa-sha256; cv=none; b=NfQ2eUY5gpdw4qGIgHKFFqb3zLRGiDXcXNcHlf61r8Uh6LDGKh4m/LK2+hDqqVuCR6LmS/ gdtwaqEfpKZBZ6+SMgWXrv/L3zj2lLA4MpHfgkeFEDKD2+XrYWOWT9kyzgpiuQKQ/9igPJ qfUE95agWqn6bRhPXBxzQUuaFiJ7ckrQiC0j/9sDLYZYwgy7hSfN0v0CkGquqpW47Y8GVA 1dsNNav6xLrgLZGq9JxAlANOr/tznm1zheWkWKDvCJeaLepf+94r94OGj3ZSXuwpPZFkvj ug+ZIoBMO2eKsBoKo+vVGqfBfbdr3o6Z8fgk5GeOKqtCRpgjnJYVyG2OzYFLQA== Received: by freefall.freebsd.org (Postfix, from userid 1354) id 0774739EC; Fri, 2 Feb 2024 18:06:06 +0000 (UTC) From: Jan Beich To: Nilton Jose Rizzo Cc: ports@freebsd.org Subject: Re: problem with Obs-Studio In-Reply-To: (Nilton Jose Rizzo's message of "Fri, 2 Feb 2024 14:23:45 -0300") References: Date: Fri, 02 Feb 2024 19:06:01 +0100 Message-ID: List-Id: Porting software to FreeBSD List-Archive: https://lists.freebsd.org/archives/freebsd-ports List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-ports@freebsd.org X-BeenThere: freebsd-ports@freebsd.org MIME-Version: 1.0 Content-Type: text/plain Nilton Jose Rizzo writes: > vgapci0@pci0:8:0:0: class=0x030000 rev=0xa1 hdr=0x00 vendor=0x10de device=0x1c82 subvendor=0x1043 subdevice=0x8626 [...] > OpenGL renderer string: GeForce GTX 1050 Ti/PCIe/SSE2 > OpenGL core profile version string: 4.5.0 NVIDIA 390.154 Legacy series like nvidia-driver-390 may be buggy e.g., https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=267446 1c82 (Device PCI ID) is still supported by regular nvidia-driver, see https://download.nvidia.com/XFree86/FreeBSD-x86_64/535.146.02/README/supportedchips.html From nobody Fri Feb 2 20:34:13 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 4TRSDS1fZWz58Cwj for ; Fri, 2 Feb 2024 20:34:16 +0000 (UTC) (envelope-from bdrewery@FreeBSD.org) Received: from freefall.freebsd.org (freefall.freebsd.org [96.47.72.132]) (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-signature RSA-PSS (4096 bits) client-digest SHA256) (Client CN "freefall.freebsd.org", Issuer "R3" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4TRSDS15N7z4ypD for ; Fri, 2 Feb 2024 20:34:16 +0000 (UTC) (envelope-from bdrewery@FreeBSD.org) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=freebsd.org; s=dkim; t=1706906056; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:mime-version:mime-version:content-type:content-type: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=AhxmZg4ygs3Jf/vBSSNliBGOXUsgyWLy/VKf9fu53pM=; b=CgaH9j+Da2Do1fGckYazUUBLopGV7pSgAeypVRvuGCZULZOMOvEJo1f8/hSP93sBuHUTuv 4lLAh0PEvzVLp3/C0LidRb3oNinjiZPIQTjIkP/ex70Y/zhvjpndTIlh/wWI2wzDyrZeXu ZTI5/KS5vci+JWx/HzgJeozz96fLXQPlBHl21PmyDD1JH19FgjZLqW3dqRDJyAYd1EPW5G xNsIbwhIXTEzjNvwBjrOGk8tBdmekWMeboa5arukkvrFO6vq1Bw7AqqEj3YjQx6vzQbl4c VD7zfJP782YReI3VJKABs1qKFiX5V/faMZjyEi/eDp+tmP/Mzo+gajm3voQAlQ== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=freebsd.org; s=dkim; t=1706906056; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:mime-version:mime-version:content-type:content-type: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=AhxmZg4ygs3Jf/vBSSNliBGOXUsgyWLy/VKf9fu53pM=; b=VgGoXQ0RlcX4iZM4Mz1/UgBbw4fPGLHs3n1py1MYZETsp0sXHr7tzYY8kl5viwSEvhIjIl +thNxvW7HiV93uhhfrADAcrQ4ZiqsRGRTp8mIz7ERdAHvp1SqKaVrTDRpQ8djH4rLkwsxO jK+7HyJgJMo/YXjtC73b3K/UdHhvc/upqSUNUwZKn0t8vMiLvojfVxBYk2wYBfG+/g4tzG uaVXnNf1NrD3Ka508hTiK7S5VNRIJMtffXinzQDWO8ccg0kFNBGpyimaMPzatkBbeICDlx cdEv4f3PE9rDfyO9IXHhllLSMN2uORYWQ/3nHTl/ZZiNMTjVGjtFBWpusZYT+w== ARC-Authentication-Results: i=1; mx1.freebsd.org; none ARC-Seal: i=1; s=dkim; d=freebsd.org; t=1706906056; a=rsa-sha256; cv=none; b=IcLq2nCcww2swiof0RhwJdstN/oRleWNJR+uM9dkguOBMrfe6ttGFtlxbOHScaTPAmJBnx MQV2Kua2r48zh5AvcBlwpD+F+Vll4yJXD3R7whtucTmboSc0kOVHC3Ff/qmSGKPu7RxNHa zSQkQEsM0P/5Ru+gjaS72Th1HxfAXjx/13tpevbZSIo1bG1hP4nHm3Be6R6sQJx7ozX9hA TnukiOnzOCmkZZEuvbHbRasNAJHNymhP1aguocaw486CidVYLqAtyKX5/kYpH+q3ZHWx/y 4KZTNqwoMcV1JmiJC9Qu98TCM5QmfxgWEjzud5FnqM0xqS2k3ysm8wFv97u3Bg== Received: from mail.xzibition.com (unknown [127.0.1.132]) (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 freefall.freebsd.org (Postfix) with ESMTPS id C9C0A41FC for ; Fri, 2 Feb 2024 20:34:15 +0000 (UTC) (envelope-from bdrewery@FreeBSD.org) Received: from mail.xzibition.com (localhost [172.31.3.2]) by mail.xzibition.com (Postfix) with ESMTP id BD741CC99 for ; Fri, 2 Feb 2024 12:34:14 -0800 (PST) X-Virus-Scanned: amavisd-new at mail.xzibition.com Received: from mail.xzibition.com ([172.31.3.2]) by mail.xzibition.com (mail.xzibition.com [172.31.3.2]) (amavisd-new, port 10026) with LMTP id x6OPRDEbk9ZY for ; Fri, 2 Feb 2024 12:34:13 -0800 (PST) Message-ID: DKIM-Filter: OpenDKIM Filter v2.10.3 mail.xzibition.com 0C45ECC92 Date: Fri, 2 Feb 2024 12:34:13 -0800 List-Id: Porting software to FreeBSD List-Archive: https://lists.freebsd.org/archives/freebsd-ports List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-ports@freebsd.org X-BeenThere: freebsd-ports@freebsd.org MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: We need to do something about build times Content-Language: en-US To: ports@freebsd.org References: From: Bryan Drewery Organization: FreeBSD In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit On 1/31/2024 12:16 PM, Bryan Drewery wrote: > On 10/24/2023 12:12 PM, Robert Clausecker wrote: >>   - rework Poudriere's rebuild detection to not rebuild every port for >>     every random bullshit thing.  For example, I don't see why ports need >>     to be rebuilt for transitive changes in build dependencies.  E.g. if >>     port A has build depends on port B which build depends on port C, and >>     C is updated, then A has to be rebuilt despite its direct >> dependencies >>     being unchanged.  This does not appear to be reasonable. > > I have this working in a private branch for a few years. Along with > allowing Rust to build OFF of tmpfs, and avoiding gcc*/llvm*/rust > building concurrently. It's been hard to find time to work on it and get > proper testing; there have been a lot of issues identified. I think it's > stable now, but the subpackages work that went into Poudriere recently > requires me to rebase my work. It's a few hundred commits in conflict. > It's so massive I have not figured out how to move forward yet. I need > to find time for it. If it were up to me I would strip out subpackages > support because it has no tests, isn't properly supported in Poudriere > (things needlessly rebuild), had its examples reverted, and has > community pushback about it. As is once I find time to get my changes > rebased in I need to add tests and proper support for subpackages. > This sounds harsher to subpackages that I intended. It's actually a very simple change to Poudriere, it just touches a lot of places that cause me conflicts and slow me down. It's my fault for sleeping on reviewing/merging the feature for the past few years leading to the issues I have with it now. -- Bryan Drewery From nobody Sat Feb 3 03:15:21 2024 X-Original-To: freebsd-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 4TRd7b6MwJz58t4f for ; Sat, 3 Feb 2024 03:15:39 +0000 (UTC) (envelope-from tatsuki_makino@hotmail.com) Received: from APC01-SG2-obe.outbound.protection.outlook.com (mail-sgaapc01olkn2059.outbound.protection.outlook.com [40.92.53.59]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "mail.protection.outlook.com", Issuer "DigiCert Cloud Services CA-1" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4TRd7Z5sy2z4hth for ; Sat, 3 Feb 2024 03:15:38 +0000 (UTC) (envelope-from tatsuki_makino@hotmail.com) Authentication-Results: mx1.freebsd.org; dkim=pass header.d=hotmail.com header.s=selector1 header.b=QGsmeqqb; arc=pass ("microsoft.com:s=arcselector9901:i=1"); dmarc=pass (policy=none) header.from=hotmail.com; spf=pass (mx1.freebsd.org: domain of tatsuki_makino@hotmail.com designates 40.92.53.59 as permitted sender) smtp.mailfrom=tatsuki_makino@hotmail.com ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=EGEMeJlWxa2qnaWxrFDW0h3DhGY7IfgLiK66ebGYcq3InAp11OAJOxrYAuwQhamF8mF8hgFG9W3NU50z+cqP7DzewlGz7UOt5TzX8oqkuGDcdtTNozASYxE6Uds4379hUNBfwjFYvZuXS06b42pvYrHijQtsvBx+Lv5ranPw38/ckusQqqN0LFQTKNW6ecXI6bPTI3n/WpKaKrh6+bOT5aaIHxfSfSyq9e0obtYjbw2FZ0UI+4mfwISm/QtKL5v3XDUQ79ZDdvIcFDbqMPCpt7lA44H38EeT/xuRjYmijfoX2lelgmbeTL5/zLtrsQozbngkb3MUbem8QFXYme7l5g== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1; bh=tnnVi0wWCdM/UNUVAHUcExLmKdOHsnKEzV5KTWH9U+g=; b=BXNLLcD1pQ+qIRc04Jn/kpTK4QG6BpKVj3ZvqdWHDOs6+rPKqEHoCJiG7lz36Yq/jAIwf9WkfhiEpKue5tgawPx3C8sRl05GHXAVxkg7wPrpprA+twJWBLq83YbGPAVRQKDf2DfUYVsyR6zrI7fwBrjo/70cshpeYQIoGGOQb5wXWgzKVJLmMEjrbcKm7/50T5JepE+IOv5V4F3sIjomFKpBsRgCFH3mpnB1xriF3W9zL32Tu9pLHzJuduU0oD3J6D09QTmRYb2c/1DScsQOSyoSO1+UliRKTUhTQIGlaQZGmchOT+aYF/7YgcGrm107a3p6p+FSIhwYmadAtTgaAg== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=none; dmarc=none; dkim=none; arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=hotmail.com; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=tnnVi0wWCdM/UNUVAHUcExLmKdOHsnKEzV5KTWH9U+g=; b=QGsmeqqb74IPHnRla7aKav0ObqYBKvZIsJWUhiNtvzLoyNm5L0RKEjkmPix6RL5gvfD43y5Gy7cI+4mrdVRSSxaHgMX6Gcubh8qe235C+HzPGsSpc0GruRwbA/4KhCteNK2sxb+GF13MtECv5MQQAKtfOuwXn7OMlbO7m70yjbm/u2nkITl69Bgntzj7redFI+wmZg+1fVwrM3cjtW570LXt6pYgKJanPWwYVgo4mmP5dEV+co5b/0DKtMHLbJ6WD0utrPziRb6RWWqkHUlMda+JAQiKh1Snxus/KHSytDpRj1IH7mr7WBPsnKQEn0wt8kzBq5mGm6nTPN4Vr0+4fA== Received: from SI2PR01MB5036.apcprd01.prod.exchangelabs.com (2603:1096:4:1f8::9) by TYSPR01MB6030.apcprd01.prod.exchangelabs.com (2603:1096:405:5f::7) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.7249.31; Sat, 3 Feb 2024 03:15:32 +0000 Received: from SI2PR01MB5036.apcprd01.prod.exchangelabs.com ([fe80::e96d:da6a:42e6:5db3]) by SI2PR01MB5036.apcprd01.prod.exchangelabs.com ([fe80::e96d:da6a:42e6:5db3%6]) with mapi id 15.20.7249.027; Sat, 3 Feb 2024 03:15:32 +0000 To: "freebsd-ports@FreeBSD.org" From: Tatsuki Makino Subject: poudriere-3.4.1 repeatedly builds subpackaged port Message-ID: Date: Sat, 3 Feb 2024 12:15:21 +0900 User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:52.0) Gecko/20100101 Firefox/52.0 SeaMonkey/2.49.4 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit X-TMN: [8o9eLtq6QqW0GQV0KC12deGffccJWQUo] X-ClientProxiedBy: TYCP286CA0242.JPNP286.PROD.OUTLOOK.COM (2603:1096:400:456::9) To SI2PR01MB5036.apcprd01.prod.exchangelabs.com (2603:1096:4:1f8::9) X-Microsoft-Original-Message-ID: List-Id: Porting software to FreeBSD List-Archive: https://lists.freebsd.org/archives/freebsd-ports List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-ports@freebsd.org X-BeenThere: freebsd-ports@freebsd.org MIME-Version: 1.0 X-MS-Exchange-MessageSentRepresentingType: 1 X-MS-PublicTrafficType: Email X-MS-TrafficTypeDiagnostic: SI2PR01MB5036:EE_|TYSPR01MB6030:EE_ X-MS-Office365-Filtering-Correlation-Id: 2c7d4198-1018-4829-68dd-08dc246661be X-Microsoft-Antispam: BCL:0; X-Microsoft-Antispam-Message-Info: cj3IvWJYQEYgoP1ZCcHzx44GuzxJfAdPdTanfN7IOFFqGZHEQw3LFtVIK1pg8xwexByB2nXomTFczXt/IKh1xVLVo8kPCnDcVpRGaFZhhJHEpojUAe4AW8EVRTThh/9PkGi6ctB0CGsqa2KW5E7HAisSpOgzGQw4o6jnAnnFWtzeYxPomFpjTGRRzcauB0ux+ZzNOFaOxiYY11vT3f2jz0ATHeCSb0649nZtc/KQE6s9YvuVEKtQc5xC5XvQ3qBVSZpAuEWeFH0/zZCcTdkxk+7xA0pNPeGa9MhiLBaCIDHGpJkd0geWZdx7ZbLBF70avGmZGlcC4qj2Qg2DQ3gJW1FF5US52OIP3xNrfCXE5jPcQtZPkVWcLm67MhFgbxH3f0OeG2ibW+CXrDzzBmaGF7/e+//LRXzeHPuiOBuqE3gxspJc1uN9RBBZ7dK+1mirP+vzsvyfDuvccMQ3AHRIm+6LWecpl0KvV3Vcfg/chCqbEfnP2sOMZNXF6rXURnfiz+cRwyj5GWfGpVl41IPWFuTyWzsRqZVGoJ8ocA+KKIfM2ImZvlkNrKx09IHil2q1VN3iptnwu9H58H8CFSqOIar/tXTlvrD8YvHDCEH1KV2ZWwu8g6c57gD4uOV5ICbr X-MS-Exchange-AntiSpam-MessageData-ChunkCount: 1 X-MS-Exchange-AntiSpam-MessageData-0: =?utf-8?B?eCtqWld2bkMyRUpmd0JFdENFT2ora3B4VDNCL0dlNEhZaXNqdEt4enJSUVU2?= =?utf-8?B?bmlCMnNYTThSdTM5TWVJaHhUUlBYZkRzMFVia1RGcWJpWWdIZWZIeUJRZkRF?= =?utf-8?B?R0s5TU1YaEVZRUUxbHpUTGs4c3RLa0N1V3FjYnhONTNOKzQ2TEFjMy9lVHVW?= =?utf-8?B?RVMwM2U1S1p2RDBRYVRhNUZSdFgrUTBjZ1M4akU1Q3hYRFY4V2ExUXRnbjBM?= =?utf-8?B?eWgyZ0crb3Evblk0K3NsbU5abnA2bU5wZzgyQ3hBU0pQVS9Hc1IwV09KN0Vp?= =?utf-8?B?clRhUWQrYlNWZXAvZVpnOXVkUlZ2U0lSYkswKzBDWGlLZC9XbkhCS25qTSt3?= =?utf-8?B?eDJxSXJtWmFNNGFvTGJQaCs3K3JSQThTaG9pVHRMMlVtTlZBdnRNelhqTlJi?= =?utf-8?B?bFBVYWhObURZMDIzQUxoUEw4bkFyZmdScGE3UzBOU3V0dHlNYXROV0VPWEl1?= =?utf-8?B?Nmh3K05RV3NpS0krU2JsblJRZlYzcHdKckprQTJOME9GQ041MVNkOFp1RHRZ?= =?utf-8?B?WjY0anUvK3NGa3llR3JEeERrd2RPSU5KQ2NRSWVUUkNiaTYvTnhnb1VoRzVV?= =?utf-8?B?c1dQbmt2ZTQvdzcvSGRqQnRvb1ZwZktiWG1zVnNWRzEvUzc3bDhCSFBoRXVt?= =?utf-8?B?MDNjbXhDTFdsVXNudzVzdGU5Qi91RXhuVEg0ZVh4YWxIVVhndVdFdE8wNUZi?= =?utf-8?B?RVlCdnp5b0V1SkE3eDJISU5TOEtNQXB0T2NHU0l4ZXBSYjJwalZDUHJ6ZU9E?= =?utf-8?B?c0lVZzJENmRJeHJKdEdzZFF3M2V0SzhQcGhoUXpWQTRvQjhMeFJZU3QzSndz?= =?utf-8?B?cDcvekM1dmhQV1czUXJ1NXVnenpzSE9FMkw5V0xuV3pCZDVXZG52ekluVDV5?= =?utf-8?B?QlRFUEJiakFaRFMrSE9ySWI2TzRLNUhXOHpxKzJFYnp2aWh4YkZxbWhLTGwv?= =?utf-8?B?WURQT3UvR3RYL0p4R0M0Wlk5MEExK1hndXppOXZpdmRTN2RBRVI0YWtaWE4r?= =?utf-8?B?QXNMZnduOGxHMmpmcFU1UkFrRkJrWFBpbVFaZWt2a3V2dmgzWEluenlOaVRI?= =?utf-8?B?ZDQ3ekdqWVNFYnlnRkxZYTFpRTQwYW9NK3lsOWpGNmtMRFZmM1FJT0tROTla?= =?utf-8?B?NWwwUHN4NVUzb0gzVHYyaGcxU3FCUG9veHRaUUZJSnFxT0tnQlczVDJBM09Z?= =?utf-8?B?QmNVZTFSb2p6L1ZGdnVSUVBBS20zUzBidjVmOVpuKzlHamtMVisydTdtV0dB?= =?utf-8?B?aEUyMzdwU1drZEwya1Y0WWZ2UVpXTzBvZEpGb0wyWFA0OFlHZ0lDQ1RnTE9l?= =?utf-8?B?SXJJZk9nNjdodGpVT0dpSlQ2U25yalFVQVhTaXZ3RzM1ZXkxTE1FVlUwb1dO?= =?utf-8?B?WEl6SUpia09VU0FRM0JkSGFtSmhZUHMrYzlSUXo4Sy9DT01lcmNXOURoZVFp?= =?utf-8?B?L0NMUlVsU0kxcG04NStWWTM5K0xtZjRTVTlDMFhqRWY5SmVENEtKWm5OK2s4?= =?utf-8?B?eFp4Vmp3V2pkbFhvclhYVFVtVnVaRVloSDM1UnFyV3d4VHdNeGNEL29KVGla?= =?utf-8?B?NnJnRnN1NWZxcmNoSUs0Wi9iaSs1Rlg1S3JXaW5TWGpna28rU2J5cGY5N1dT?= =?utf-8?Q?a93l/h3g9OMmjk1MDerkPDKhap3LNKyJaYTwwPKLHl8I=3D?= X-OriginatorOrg: sct-15-20-4755-11-msonline-outlook-d8e84.templateTenant X-MS-Exchange-CrossTenant-Network-Message-Id: 2c7d4198-1018-4829-68dd-08dc246661be X-MS-Exchange-CrossTenant-AuthSource: SI2PR01MB5036.apcprd01.prod.exchangelabs.com X-MS-Exchange-CrossTenant-AuthAs: Internal X-MS-Exchange-CrossTenant-OriginalArrivalTime: 03 Feb 2024 03:15:32.8292 (UTC) X-MS-Exchange-CrossTenant-FromEntityHeader: Hosted X-MS-Exchange-CrossTenant-Id: 84df9e7f-e9f6-40af-b435-aaaaaaaaaaaa X-MS-Exchange-CrossTenant-RMS-PersistedConsumerOrg: 00000000-0000-0000-0000-000000000000 X-MS-Exchange-Transport-CrossTenantHeadersStamped: TYSPR01MB6030 X-Spamd-Bar: -- X-Spamd-Result: default: False [-2.31 / 15.00]; FORGED_MUA_SEAMONKEY_MSGID_UNKNOWN(2.50)[]; ARC_ALLOW(-1.00)[microsoft.com:s=arcselector9901:i=1]; NEURAL_HAM_MEDIUM(-1.00)[-0.999]; NEURAL_HAM_LONG(-1.00)[-0.999]; NEURAL_HAM_SHORT(-0.81)[-0.807]; DMARC_POLICY_ALLOW(-0.50)[hotmail.com,none]; R_SPF_ALLOW(-0.20)[+ip4:40.92.0.0/16]; R_DKIM_ALLOW(-0.20)[hotmail.com:s=selector1]; MIME_GOOD(-0.10)[text/plain]; FREEMAIL_FROM(0.00)[hotmail.com]; RWL_MAILSPIKE_POSSIBLE(0.00)[40.92.53.59:from]; MIME_TRACE(0.00)[0:+]; RCPT_COUNT_ONE(0.00)[1]; ASN(0.00)[asn:8075, ipnet:40.80.0.0/12, country:US]; MLMMJ_DEST(0.00)[freebsd-ports@freebsd.org]; DWL_DNSWL_NONE(0.00)[hotmail.com:dkim]; FROM_EQ_ENVFROM(0.00)[]; FROM_HAS_DN(0.00)[]; FREEMAIL_ENVFROM(0.00)[hotmail.com]; RCVD_COUNT_TWO(0.00)[2]; TO_MATCH_ENVRCPT_ALL(0.00)[]; TO_DN_EQ_ADDR_ALL(0.00)[]; RCVD_TLS_LAST(0.00)[]; DKIM_TRACE(0.00)[hotmail.com:+] X-Rspamd-Queue-Id: 4TRd7Z5sy2z4hth Hello. I don't know what a subpackage is, but poudriere repeats the build that seems to be one of the causes. Since subpackage are going to be used, what else could be the cause? 1. I'm still using 12.4-STABLE :) 2. My poudriere has been fixed a bit :) 3. Dependencies are written in the style of packagename>versionnumber:category/portname. If 1. or 2. is the cause, stop poudriere and think of a countermeasure on my side :) If it is 3 or any other reason, the impact seems to be significant, maybe. The build repetition occurs in the following combination. graphics/blender -> x11-toolkits/libdecor www/qt5-webengine -> audio/alsa-plugins As for Blender, I'm not sure because the build is failing :) Regards. From nobody Sat Feb 3 04:03:34 2024 X-Original-To: freebsd-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 4TRfC22Tv8z58xwK for ; Sat, 3 Feb 2024 04:03:42 +0000 (UTC) (envelope-from jbeich@freebsd.org) Received: from freefall.freebsd.org (freefall.freebsd.org [96.47.72.132]) (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-signature RSA-PSS (4096 bits) client-digest SHA256) (Client CN "freefall.freebsd.org", Issuer "R3" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4TRfC21zWLz4mxh; Sat, 3 Feb 2024 04:03:42 +0000 (UTC) (envelope-from jbeich@freebsd.org) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=freebsd.org; s=dkim; t=1706933022; 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:references:references; bh=kfBieHDh58OoTTGMBF2GzGDpJGu+dXQdWN0B9JL4WQ0=; b=SW9Mq4oGKCh3B5tPyExiOFhXoR039wAnEQ0T2Q2XbA4jwPgLv7jCmqOb7kJiPIsvka3ixz J+O18t2k4VW36ICC2JV3GZciCfYmKvabMd2MyWUpFCFhDKSLp85YuZTVpOk4u5gnUi4Za2 /JGSgpl9EFLvL3qdvdfYnQCQgYZS4iappgQkn97D/8ZAW+kra187nafjJau/Mgz1xCovuT VtNucN1V3jP9xHwm/49paes42lZkRnzLgjLz688ZbTu3WCNkw+Hqf78sJBVZIrZYDkpX9U 2I/pozsee7faNMM70EvLNhF68KPxtzFyzMgrV4t5QjeRwou/1mxbysgLoG7bYA== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=freebsd.org; s=dkim; t=1706933022; 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:references:references; bh=kfBieHDh58OoTTGMBF2GzGDpJGu+dXQdWN0B9JL4WQ0=; b=aYBFLyg/gAQyjbdYKXtlaTkbwWJAq/Kp4mlU/eT4p3czAhYDmEa10c0lPul6VcmmwlXtZz qiGjasusdhIp6D9KIFpO74JzyCCZrAoR34t+oU3HcazspbfV+BZOi919m4Earoguq5Klld dOHLEYnCqE6X6B021PuacdHNmnnaCa1J+U/DKVoG7cbGEm712s9Z9SOrbh5fyrwsT2mA0K Ij4rR+HLUg9EkQIbamLWfQe79BGhF+dL82WZZ0ifYV/gEsLx19zxurBxP7YlaEiSnjGT0E K7rrlQzHq/8v0BNuZKQfjkZEhShxARGERtzoWitbx8i+s2rEsOIi1ErZizqFBA== ARC-Authentication-Results: i=1; mx1.freebsd.org; none ARC-Seal: i=1; s=dkim; d=freebsd.org; t=1706933022; a=rsa-sha256; cv=none; b=WEvWBMwGtaMzahTk+Kq8YEvhtLwRZgRRyH+gq6eNTxHG4lXXx6rzy4CNiIkFI2eGmCzY1Y qUSBKRfXJebBx1dAkvNX5v0IIh/jQF6U6lYBuRF6echDmnLIqygAvPD0BW2tyNrL+1lC53 Moz1+GPAeGWPbUOJB4oYzhLmtPv2SL5skueFBkoIUvTuqCfx9HIsJKi82IlfkADnpwFSFC /IexhlZZ04in5tZZvR/0j0PI060y8AaJZeWA5A+gWaeSVICvVzHbjDMxpgGr4PiAcjZMGE QPFKaTCzxMXPYPamhU06yPSUJB65QPu/yeXqu1+gqu9ACL/bp6JGO/Yjq6SH4g== Received: by freefall.freebsd.org (Postfix, from userid 1354) id 198E855E3; Sat, 3 Feb 2024 04:03:41 +0000 (UTC) From: Jan Beich To: Tatsuki Makino Cc: "freebsd-ports@FreeBSD.org" Subject: Re: poudriere-3.4.1 repeatedly builds subpackaged port In-Reply-To: (Tatsuki Makino's message of "Sat, 3 Feb 2024 12:15:21 +0900") References: Date: Sat, 03 Feb 2024 05:03:34 +0100 Message-ID: <7cjm-dwix-wny@FreeBSD.org> List-Id: Porting software to FreeBSD List-Archive: https://lists.freebsd.org/archives/freebsd-ports List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-ports@freebsd.org X-BeenThere: freebsd-ports@freebsd.org MIME-Version: 1.0 Content-Type: text/plain Tatsuki Makino writes: > The build repetition occurs in the following combination. > > graphics/blender -> x11-toolkits/libdecor > www/qt5-webengine -> audio/alsa-plugins See https://github.com/freebsd/poudriere/issues/1113 From nobody Sat Feb 3 04:11:35 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 4TRfN76NY3z58yjK for ; Sat, 3 Feb 2024 04:11:35 +0000 (UTC) (envelope-from portscout@FreeBSD.org) Received: from mxrelay.nyi.freebsd.org (mxrelay.nyi.freebsd.org [IPv6:2610:1c1:1:606c::19:3]) (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-signature RSA-PSS (4096 bits) client-digest SHA256) (Client CN "mxrelay.nyi.freebsd.org", Issuer "R3" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4TRfN73g2Cz4skX for ; Sat, 3 Feb 2024 04:11:35 +0000 (UTC) (envelope-from portscout@FreeBSD.org) ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=freebsd.org; s=dkim; t=1706933495; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:mime-version:mime-version:content-type:content-type: content-transfer-encoding:content-transfer-encoding; bh=JYyzRMDD0IzL1XAGqU7UHrv+pPd8N4AbgUN/cPmA9Y4=; b=FCBLnGdbpWNcrdd58p50yx9egk6KKIdIkHyIrNiXFL0WPpbC0TZg5u9PbpnbrJYrAnVP4+ 4er5cCdXI2pzA3Pgeao0f5piH2TSEdzL9D7hapf8Y+7c6ys9X/i8w+9PazTaOHCkVexNbR AaZLP9Wz2wNCJeI3wRFQ2W5Cp/xLtxD22F1MkoD5xgT9+O2bnqCLxbMW7D+ts4HowJL8NJ MMU4oPJeNVH4L/c5pIbAE748g3rsCOAM+BgVXNpaL0NYHs+eBtF7SIZiR498OGoi43fuNR T/yeQULh0L9GnCzFmqV6kJEiDmh6t/AAbm+5Drnczo+EAiVAWcFSPDvJ7naPHA== ARC-Authentication-Results: i=1; mx1.freebsd.org; none ARC-Seal: i=1; s=dkim; d=freebsd.org; t=1706933495; a=rsa-sha256; cv=none; b=ZlbAGe6SCySDQm/Hdj+Z80cCS/Z0X6WAo9mE7Vyze9JEdO6Wk8KTlzC0F1luyjjqv2lXU4 BOiAi44k73qNg4QpEB9yVw9mJAhrlGXfiM8CNrHYuyd13xnfzM906lRok7JyyV1szHjODz vvQTRMITb/mV5hqtDqwvGf8E3760VFCaKuTBd+vWcp0tipgzVeCwNis7mxKoYmXHB3ChQJ LE5IYE8mUw+l8Bcp9Yo8A/v/CZqNc61GGogosJvgoUIPq9HXEPuEM3Kb6DFIpzxkwq5xJ7 IL39zYJLcEQElLEOAS6plpuRSqP6UaTXXr/HiLoa85s/nxWh5i5nGsWqvNcz1A== Received: from portscout.nyi.freebsd.org (portscout.nyi.freebsd.org [IPv6:2610:1c1:1:606c::50:21]) (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 mxrelay.nyi.freebsd.org (Postfix) with ESMTPS id 4TRfN72XvrzysZ for ; Sat, 3 Feb 2024 04:11:35 +0000 (UTC) (envelope-from portscout@FreeBSD.org) Received: from portscout.nyi.freebsd.org ([127.0.1.10]) by portscout.nyi.freebsd.org (8.17.1/8.17.1) with ESMTP id 4134BZQP091378 for ; Sat, 3 Feb 2024 04:11:35 GMT (envelope-from portscout@FreeBSD.org) Received: (from portscout@localhost) by portscout.nyi.freebsd.org (8.17.1/8.17.1/Submit) id 4134BZK6091377; Sat, 3 Feb 2024 04:11:35 GMT (envelope-from portscout@FreeBSD.org) Message-Id: <202402030411.4134BZK6091377@portscout.nyi.freebsd.org> X-Authentication-Warning: portscout.nyi.freebsd.org: portscout set sender to portscout@FreeBSD.org using -f Content-Disposition: inline Content-Transfer-Encoding: 8bit Content-Type: text/plain List-Id: Porting software to FreeBSD List-Archive: https://lists.freebsd.org/archives/freebsd-ports List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-ports@freebsd.org X-BeenThere: freebsd-ports@freebsd.org MIME-Version: 1.0 Date: Sat, 3 Feb 2024 04:11:35 +0000 From: portscout@FreeBSD.org To: ports@freebsd.org Subject: Unmaintained FreeBSD ports which are out of date X-Mailer: portscout/0.8.1 Dear port maintainers, The portscout new distfile checker has detected that one or more unmaintained ports appears to be out of date. Please take the opportunity to check each of the ports listed below, and if possible and appropriate, submit/commit an update. Please consider also adopting this port. If any ports have already been updated, you can safely ignore the entry. An e-mail will not be sent again for any of the port/version combinations below. Full details can be found at the following URL: http://portscout.freebsd.org/ports@freebsd.org.html Port | Current version | New version ------------------------------------------------+-----------------+------------ databases/clickhouse | 22.1.3.7 | v24.1.2.5-stable ------------------------------------------------+-----------------+------------ devel/R-cran-hardhat | 1.3.0 | 1.3.1 ------------------------------------------------+-----------------+------------ sysutils/testdisk | 7.1 | 7.2 ------------------------------------------------+-----------------+------------ If any of the above results are invalid, please check the following page for details on how to improve portscout's detection and selection of distfiles on a per-port basis: http://portscout.freebsd.org/info/portscout-portconfig.txt Reported by: portscout! From nobody Sat Feb 3 04:45:25 2024 X-Original-To: freebsd-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 4TRg7P1WYZz592Bm for ; Sat, 3 Feb 2024 04:45:37 +0000 (UTC) (envelope-from tatsuki_makino@hotmail.com) Received: from APC01-PSA-obe.outbound.protection.outlook.com (mail-psaapc01olkn2082d.outbound.protection.outlook.com [IPv6:2a01:111:f400:feae::82d]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "mail.protection.outlook.com", Issuer "DigiCert Cloud Services CA-1" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4TRg7N5YVJz40Q7; Sat, 3 Feb 2024 04:45:36 +0000 (UTC) (envelope-from tatsuki_makino@hotmail.com) Authentication-Results: mx1.freebsd.org; none ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=SFUOXsPMGVDY/3OsTuyKXbW8aUW4WtmFL+MdgcGIsEeccpPnTVji2jPI4v4DtfJKl4DqEH20pctMrpy256zmlQ4oWa1kRrkeN8W2SrIj7SW+nSZS7cYlr8ioOMIdaKmwHiu7WZAMBdoPDQ9dMgRhtz3HyoBKL0h77l0laBv52aCaJeVOCN9EsXH35g3unJSEIewfKwjSOjsBA18bwVA7T2Ib5U3SNsgFJbhixrQnhmINn+GDvqu8UiyU6ytQQvSogvaLTaQ8cz7ZO3O1IqXtpBLBDQv80dX7PCZYEy52LeT/pF5OiluerjOjHkZWgwn0gVF64ho5zPktMJ8u8x47ng== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1; bh=FiYZ310fHjO5QKpxVGm0BtP05FKgVsdZIuVMRztN088=; b=mCQM9PfhmBGf5EYNWqWGaAkHMKTNAMMq+Z39whbI4DbXcxnhxMXCb3+Ei041pphtZIU3HzO8Udh1Mt2f/As07/AKSerGpnXsKIOC6/sO4xoA+I44eA15agzrG5WcQ6Vp0HcnhKXRlQ6u5vPzzKuHeRosresHdPPhqntrQ7W2Utz31ljal+RXrYvxs4a736/p5+drCnMLG6CNMMIlCmQrS6FHxYkJp8SUxL/BrRVSU1MiTeLjAxUQcp4TjonZkhuw5rdEjvHOkqbaJq4nzT6b3ZC87hLNgJsOhqOu2+sFziRPfRWJ7yODbXSJvgMRJLLjR4TI8BqoV2bh1gfq0K0mgQ== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=none; dmarc=none; dkim=none; arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=hotmail.com; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=FiYZ310fHjO5QKpxVGm0BtP05FKgVsdZIuVMRztN088=; b=a6rxoPCJzEORV4c3enZ8KUYAkNiLrIaiK/mM8FLkTCqwBrEB3+139W+jyzd42VkgFTqHnzFASO8OHMZyLF3KgvoOAxbw/fz4Kh45LtUCc1i/jJbuyN0PaUNEctQqFeaeKEmXIV6QrOXmfem2ijt8kxQ9zixgxlsV/hyR2TJyN3fFpaXIroi3xLC/SHkBDsMov7rOB8CUgugbLJlYJdgSmy9MUT9FaEcU/EDpTl3oRVEwMYGgH91nG+SXu6DhOek5OJBnUds3PEkpG2/pIhRU6MCGIfdseAHZISwSn/mJ7FuoIeZvjxrnH5qPZT+dBB+yiQc3KjoDwxz+RnLKpLu1jQ== Received: from SI2PR01MB5036.apcprd01.prod.exchangelabs.com (2603:1096:4:1f8::9) by PUZPR01MB4775.apcprd01.prod.exchangelabs.com (2603:1096:301:fd::6) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.7249.31; Sat, 3 Feb 2024 04:45:29 +0000 Received: from SI2PR01MB5036.apcprd01.prod.exchangelabs.com ([fe80::e96d:da6a:42e6:5db3]) by SI2PR01MB5036.apcprd01.prod.exchangelabs.com ([fe80::e96d:da6a:42e6:5db3%6]) with mapi id 15.20.7249.027; Sat, 3 Feb 2024 04:45:28 +0000 Subject: Re: poudriere-3.4.1 repeatedly builds subpackaged port To: Jan Beich Cc: "freebsd-ports@FreeBSD.org" References: <7cjm-dwix-wny@FreeBSD.org> From: Tatsuki Makino Message-ID: Date: Sat, 3 Feb 2024 13:45:25 +0900 User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:52.0) Gecko/20100101 Firefox/52.0 SeaMonkey/2.49.4 In-Reply-To: <7cjm-dwix-wny@FreeBSD.org> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit X-TMN: [92b0C38fzz3SNGn5Uci2Bn2SFrtsNnpM] X-ClientProxiedBy: TYCP286CA0247.JPNP286.PROD.OUTLOOK.COM (2603:1096:400:456::18) To SI2PR01MB5036.apcprd01.prod.exchangelabs.com (2603:1096:4:1f8::9) X-Microsoft-Original-Message-ID: <0db73f42-cf59-46aa-176c-633a622f859e@hotmail.com> List-Id: Porting software to FreeBSD List-Archive: https://lists.freebsd.org/archives/freebsd-ports List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-ports@freebsd.org X-BeenThere: freebsd-ports@freebsd.org MIME-Version: 1.0 X-MS-Exchange-MessageSentRepresentingType: 1 X-MS-PublicTrafficType: Email X-MS-TrafficTypeDiagnostic: SI2PR01MB5036:EE_|PUZPR01MB4775:EE_ X-MS-Office365-Filtering-Correlation-Id: 5105b41d-6f57-418f-8b39-08dc2472f224 X-Microsoft-Antispam: BCL:0; X-Microsoft-Antispam-Message-Info: gG9ZjN1+uATN53m4r2v9/vozSQ/OQY6qtVxHbkm8nwn6ks08+1MdriBbKlyJXfApUzfDiKAq2c0cEBjwQDkdVdYO4ujsN6dBZHUqcgxFqbu4iEsIS4a7Q/VfTID9AQoUJi6YFJjnW2Cq0myrWz9rRDANQ/oMwAXkncdjmDKEXRh54Xvs562uzG1nndYDC3SkDj0k49dMgzxJaaPQN0DBqUAyhmDGUhifDBL1EA67SHuhZ2HSAvmvTRgUJPXDyWPWdzQALcCpv29T1g8jsOVlXgC2hL/wyk6oW1uyXpdG8+9aKlqZaCXuevpRLri1D+wKYNcmMkUkrACLkAJZIXOXGSgoiAzVWhn3M7ryeMDRHEhIsWItwX03yAu7FWnseBE++YRAbOzOV8yOGkcXdGZ/RmNmAKsb+2wgFWQnr2ef4ynD3/auklu+MYj6AgKlqAcrK/W1LczcKDq4KbN3zX4Iz5ULhOI4AYDotv/5BSF9Tt/LDAI/wvSRjEBN+m/CopTwpim78RbyGrAhtWhTgDHGfrUo9gEU9ushCqijj5n1+V/dsC3zrxVaq3X1P0ZWnGMLkmIoMu/RtRcsZhbOESGqCeoaahB1Y7EBAYzr73pKtHsQYwIXX7VNzr2cjWvU+rlg X-MS-Exchange-AntiSpam-MessageData-ChunkCount: 1 X-MS-Exchange-AntiSpam-MessageData-0: =?utf-8?B?cThOeXZNUkJhZ254UjE1ZGVleE9mWUZjVFljc3FPTlRQWkl4dTJ6NzlVM09k?= =?utf-8?B?a3duN2RqbGZveFg2T1lSNXFZSytNa3hONlRCdnRrZzk4akRERTFpUG9oOUJT?= =?utf-8?B?a0dVZEtnTW5Wak0zMDlIaks1TGNpNUh1MTN4cVZwNWJadGliNkp6eXdSM0tQ?= =?utf-8?B?Q1dUNGt0OW5iVSs3UG00YUZlNW9DcjgvWVhtNVdpblZtcGlrbGJ0YkxRNERs?= =?utf-8?B?dW1SOGNyWG1QRDJQamF3Vy9OZ3lyZXhlSm1pUGlPTk5VYzVoT1B2RWZBbE1S?= =?utf-8?B?MmJBRldUbVhERlpJVWE3NUFQeTV3VyszVTkyUU9BTExYWllCQ25ncm1naXlq?= =?utf-8?B?dzc0endKTGI3WkNyRURDOERUNENCaGExZFRESDhlbVRGbHBTeHgvZVU4Y2E4?= =?utf-8?B?MGVJdjR1M3BVYjlqQlg1VUNjSGkxMFZiWVV4Y3BDNXkveWZnVjA1M21ERS9E?= =?utf-8?B?Tm53UnVteXNGOUdqazRHVis1U2dFL3poVmNKV0VHVjVMWXN5Y3NiRnJaTjRQ?= =?utf-8?B?OWlZa05MWUVTc3c4U0x1dDdob2F1cnFZMWk3V0NVZmREL3ZDL1k0U2h5Q3Rs?= =?utf-8?B?ei9hN1R0Q0lIOFlCUHB0cmh4RWo4Q1ZnMG04bFZoRFhITnZObE9SRkphV3BV?= =?utf-8?B?N3p0SEZjZDNJdFgzSXJseWUyU3lrMGNxcmhkeWkrUnJJMHk3dlhhZzVubldT?= =?utf-8?B?eURuMW1sV1p1SGUzb1I5Q1RSQVV6b0czMS9ZeCtlQnpvZGxOcXZVQkhTd3px?= =?utf-8?B?ME8xemhPRDZ5emlhdkdMZWJFOExJU1BWUU01TnNhMm5kaWc1NjllVWJvR0Vz?= =?utf-8?B?REx1N3o4WjE2NmZrRXN3bWg2VTFiSms4SFlnWjZVS1lrS3VaZDVQbGJyMHBV?= =?utf-8?B?R1pPa2xGdjNRNDBITVRKaXlUV1djU3hiVzBaVUVuaHE1anVORWJsellWanhG?= =?utf-8?B?SHh0YVkrK1AyK2psNHYrbkloT1dlYjFqSURkcEppUGdieTh6NnZHN3RFdmJn?= =?utf-8?B?VlQ0UWhJd24za1lsWUhMVVhxOHdRaENhYjZvS0k3N1dSaytqT25vWVBSeTBy?= =?utf-8?B?NzZKeEhMSkJiKzA0Y1E5UGFkM2dJQlhBZ0xpZEljTFRnRFZ5QlZvZisrbHhQ?= =?utf-8?B?TzR3czF0dURIRC9OOE40QlQ0WmxLSTlWVmZUbGdaNENLV3l0YnduZnl5SHVK?= =?utf-8?B?OStNRWJRU29lWSs5cDhBdjRJZTVHR3gxckNpaHNlbWRLRktxYnJ0ZmV2WE4x?= =?utf-8?B?TEVwMEdHSGlFemdtZ2ZoKzhMbUdjMU5UNnJOSWQyWGd5VUxNNFZvMWNaYUc2?= =?utf-8?B?SVRyMjVSMWtrSDVUUzNZSDVIc1RHWE9TNEtBNXNBV2MyQ2xEYk04L3VjNFRF?= =?utf-8?B?bzZaWnVHdWxBTk9JclpQSnJMOVI3SlhuWjdON0JJcEw4c3lLRzE2UE0xVVlI?= =?utf-8?B?VUdmTGVZSjdwYjZKamxwaDNaUFoyaDVtTVZoMDZtaXZRNG1nVEo5ZTZJWUdY?= =?utf-8?B?Q1hDeURBNFQrRXl6R3p4a0JLV3AvMktSaUZQeFhaK29IT1h1MHRyMTBwSG5D?= =?utf-8?B?VlVaTTY4d1c1OEkwS1lZUTJYS0NEY1AxWExIYldqY2VBVElrOXl3dU1JOEQ0?= =?utf-8?Q?dSZMf5SFkVCpeMcwJz2eHIqzV5l8mtt85FV1EE2fT6gw=3D?= X-OriginatorOrg: sct-15-20-4755-11-msonline-outlook-d8e84.templateTenant X-MS-Exchange-CrossTenant-Network-Message-Id: 5105b41d-6f57-418f-8b39-08dc2472f224 X-MS-Exchange-CrossTenant-AuthSource: SI2PR01MB5036.apcprd01.prod.exchangelabs.com X-MS-Exchange-CrossTenant-AuthAs: Internal X-MS-Exchange-CrossTenant-OriginalArrivalTime: 03 Feb 2024 04:45:28.9078 (UTC) X-MS-Exchange-CrossTenant-FromEntityHeader: Hosted X-MS-Exchange-CrossTenant-Id: 84df9e7f-e9f6-40af-b435-aaaaaaaaaaaa X-MS-Exchange-CrossTenant-RMS-PersistedConsumerOrg: 00000000-0000-0000-0000-000000000000 X-MS-Exchange-Transport-CrossTenantHeadersStamped: PUZPR01MB4775 X-Rspamd-Queue-Id: 4TRg7N5YVJz40Q7 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:8075, ipnet:2a01:111:f000::/36, country:US] Jan Beich wrote on 2024/02/03 13:03: > See https://github.com/freebsd/poudriere/issues/1113 Thank you. In the case of FLAVOR, the package name was also dynamically changed by a variable (e.g. ${PYTHON_PKGNAMEPREFIX}sphinx>=0:textproc/py-sphinx@${PY_FLAVOR}), but how does subpackage work...? Regards. From nobody Sat Feb 3 05:44:23 2024 X-Original-To: freebsd-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 4TRhRp3RVSz58Nqt for ; Sat, 3 Feb 2024 05:44:54 +0000 (UTC) (envelope-from 6yearold@gmail.com) Received: from mail-qk1-f169.google.com (mail-qk1-f169.google.com [209.85.222.169]) (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 4TRhRp15NGz44ZM for ; Sat, 3 Feb 2024 05:44:54 +0000 (UTC) (envelope-from 6yearold@gmail.com) Authentication-Results: mx1.freebsd.org; none Received: by mail-qk1-f169.google.com with SMTP id af79cd13be357-7810827e54eso178807985a.2 for ; Fri, 02 Feb 2024 21:44:54 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1706939093; x=1707543893; h=content-transfer-encoding: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=8wAqbjwKQirwaERrlZpW544Qq1wCFxZnD1d5IuE2doQ=; b=rEGsir2jQNUFqQllXhBFojwEKcnhsIN+vZcU5RpL1xuY9rHm/to+cpdzXj3DKIk5RA AOFHF1f9eaI+6zXejmcejIpC0W94f0hwCd6s6fCdxU3pkCP/TUGq3yFFS4XtRjljPhUH gevP/waFOuqvXNQiX/1dTkO5+uJFIEgyQB2Gd19EZUyZDqNoZW1LEs6vWowL/DpqTahU d8RYOuj3dbGgVgX+2Ghu3tQ5RDZUhcBExAzitQPG0CNAvpLpASOdnGkZMQ9PHKsxWtp3 M92ZJYQZhd7lCNkJwBbLEcN9grJ7GfWIX7CAJix2y4z5UCgyahBwnB2wWkp9J3Fvt074 vNgQ== X-Gm-Message-State: AOJu0YzUoZvDvY9itquJ2O0UEs+POXjgGzLrQGMaeIBVHWwtmwKzLNQX 8A7m97l1GKxDYopxhzQARrPWS5fbzDgc4igHm4xaNJhPc/jEIcrUnLQKdA/N X-Google-Smtp-Source: AGHT+IGxgi8Y4kn4L64PIgYUbfQXEocMkT/0I4J+fh6FvimbBElq+/gaPpHIBsZUUxkIAe4hhXfItw== X-Received: by 2002:a05:620a:199a:b0:785:3dc5:284b with SMTP id bm26-20020a05620a199a00b007853dc5284bmr5105985qkb.52.1706939092745; Fri, 02 Feb 2024 21:44:52 -0800 (PST) Received: from mail-qk1-f176.google.com (mail-qk1-f176.google.com. [209.85.222.176]) by smtp.gmail.com with ESMTPSA id bi2-20020a05620a318200b00783f9bb4c85sm1229945qkb.131.2024.02.02.21.44.52 for (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Fri, 02 Feb 2024 21:44:52 -0800 (PST) Received: by mail-qk1-f176.google.com with SMTP id af79cd13be357-783cd62f1b5so112578285a.3 for ; Fri, 02 Feb 2024 21:44:52 -0800 (PST) X-Received: by 2002:a05:620a:51cc:b0:783:9011:67f0 with SMTP id cx12-20020a05620a51cc00b00783901167f0mr4337705qkb.61.1706939092239; Fri, 02 Feb 2024 21:44:52 -0800 (PST) List-Id: Porting software to FreeBSD List-Archive: https://lists.freebsd.org/archives/freebsd-ports List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-ports@freebsd.org X-BeenThere: freebsd-ports@freebsd.org MIME-Version: 1.0 References: <7cjm-dwix-wny@FreeBSD.org> In-Reply-To: From: Gleb Popov Date: Sat, 3 Feb 2024 08:44:23 +0300 X-Gmail-Original-Message-ID: Message-ID: Subject: Re: poudriere-3.4.1 repeatedly builds subpackaged port To: Tatsuki Makino Cc: "freebsd-ports@FreeBSD.org" Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Rspamd-Queue-Id: 4TRhRp15NGz44ZM 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:209.85.128.0/17, country:US] On Sat, Feb 3, 2024 at 7:46=E2=80=AFAM Tatsuki Makino wrote: > Thank you. > > In the case of FLAVOR, the package name was also dynamically changed by a= variable (e.g. ${PYTHON_PKGNAMEPREFIX}sphinx>=3D0:textproc/py-sphinx@${PY_= FLAVOR}), but how does subpackage work...? https://lists.freebsd.org/archives/freebsd-ports/2024-January/005227.html http://arrowd.name/ports_writeup From nobody Sat Feb 3 07:55:24 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 4TRlLR5FZrz58rH5 for ; Sat, 3 Feb 2024 07:55:27 +0000 (UTC) (envelope-from lbartoletti@tuxfamily.org) Received: from smtp2-g21.free.fr (smtp2-g21.free.fr [IPv6:2a01:e0c:1:1599::11]) (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 4TRlLQ64G8z4Ld2 for ; Sat, 3 Feb 2024 07:55:26 +0000 (UTC) (envelope-from lbartoletti@tuxfamily.org) Authentication-Results: mx1.freebsd.org; dkim=none; dmarc=none; spf=neutral (mx1.freebsd.org: 2a01:e0c:1:1599::11 is neither permitted nor denied by domain of lbartoletti@tuxfamily.org) smtp.mailfrom=lbartoletti@tuxfamily.org Received: from [IPV6:2a01:e0a:d62:8fc0:e96b:7111:9524:85f] (unknown [IPv6:2a01:e0a:d62:8fc0:e96b:7111:9524:85f]) by smtp2-g21.free.fr (Postfix) with ESMTP id BD862200402 for ; Sat, 3 Feb 2024 08:55:24 +0100 (CET) Content-Type: multipart/alternative; boundary="------------uogGJs0T706q6QCV5TfI0fgg" Message-ID: Date: Sat, 3 Feb 2024 08:55:24 +0100 List-Id: Porting software to FreeBSD List-Archive: https://lists.freebsd.org/archives/freebsd-ports List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-ports@freebsd.org X-BeenThere: freebsd-ports@freebsd.org MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: poudriere-3.4.1 repeatedly builds subpackaged port To: ports@freebsd.org References: <7cjm-dwix-wny@FreeBSD.org> Content-Language: fr From: =?UTF-8?Q?Lo=C3=AFc_Bartoletti?= In-Reply-To: X-Spamd-Bar: -- X-Spamd-Result: default: False [-2.99 / 15.00]; NEURAL_HAM_LONG(-1.00)[-1.000]; NEURAL_HAM_MEDIUM(-1.00)[-1.000]; NEURAL_HAM_SHORT(-1.00)[-0.999]; MIME_GOOD(-0.10)[multipart/alternative,text/plain]; ONCE_RECEIVED(0.10)[]; XM_UA_NO_VERSION(0.01)[]; R_SPF_NEUTRAL(0.00)[?all]; RCVD_COUNT_ONE(0.00)[1]; RCPT_COUNT_ONE(0.00)[1]; ASN(0.00)[asn:12322, ipnet:2a01:e00::/26, country:FR]; RCVD_TLS_LAST(0.00)[]; FREEFALL_USER(0.00)[lbartoletti]; MIME_TRACE(0.00)[0:+,1:+,2:~]; MID_RHS_MATCH_FROM(0.00)[]; R_DKIM_NA(0.00)[]; TO_DN_NONE(0.00)[]; FROM_EQ_ENVFROM(0.00)[]; ARC_NA(0.00)[]; TO_MATCH_ENVRCPT_ALL(0.00)[]; DMARC_NA(0.00)[tuxfamily.org: no valid DMARC record]; PREVIOUSLY_DELIVERED(0.00)[ports@freebsd.org]; MLMMJ_DEST(0.00)[ports@freebsd.org]; FROM_HAS_DN(0.00)[] X-Rspamd-Queue-Id: 4TRlLQ64G8z4Ld2 This is a multi-part message in MIME format. --------------uogGJs0T706q6QCV5TfI0fgg Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit Hi Gleb, Le 03/02/2024 à 06:44, Gleb Popov a écrit : > http://arrowd.name/ports_writeup Do you think that it could be an entry in the porters-handbook? All the best, Loïc --------------uogGJs0T706q6QCV5TfI0fgg Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: 8bit

Hi Gleb,

Le 03/02/2024 à 06:44, Gleb Popov a écrit :
http://arrowd.name/ports_writeup

Do you think that it could be an entry in the porters-handbook?

All the best,

Loïc

--------------uogGJs0T706q6QCV5TfI0fgg-- From nobody Sat Feb 3 08:20:39 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 4TRlw64qRZz58tsc for ; Sat, 3 Feb 2024 08:21:10 +0000 (UTC) (envelope-from 6yearold@gmail.com) Received: from mail-vs1-f45.google.com (mail-vs1-f45.google.com [209.85.217.45]) (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 4TRlw55FH9z4NLh for ; Sat, 3 Feb 2024 08:21:09 +0000 (UTC) (envelope-from 6yearold@gmail.com) Authentication-Results: mx1.freebsd.org; none Received: by mail-vs1-f45.google.com with SMTP id ada2fe7eead31-46d15b18a78so191394137.0 for ; Sat, 03 Feb 2024 00:21:09 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1706948469; x=1707553269; h=content-transfer-encoding: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=CgxtbVXMHxA8XkL9jK9KnOu8lhyfF+KMPzRiBD/a390=; b=cE9zphEQ17MTVAczrSCg5j9jhdIfF1J1rpsSmoLUcMBKzRtYJa6aw6KwvYj8AcTMQI 99NDXd0uUxzGrwGkGHqSZlPGZpa59W/ttztlvhJpZxahHZ+EUo4Qe1Qg3o4M2pZl26/f YcTFV6p/yAq613mTyFOn2AiEv5CPSlABULf33Gm/CuPDnYSUZQKp6VzAuciKhVxVWKPa fMpE4a5r+M3so6CZvhmyWGaYNQHNhBJRKdJvHiVpzLy9dSMyutccJsUvsJutHSa9pzgi PmpAT6VkSk61rzVQcy2ZKYxGz1EBBObg7zKyfUXBWVcNsbfqZpeuRXVQUuoWcyLdGaNA A1jw== X-Gm-Message-State: AOJu0YyJnpj6wWADmnYrMTcT9w/MrE9TW6ewAb2+7LBYImoc1Kbgs7M8 SYCekpGiXqbRYuIhznxPcmaWArX5I9ZF1E47EkGECEgb0YFKclx9bMld/WPH618= X-Google-Smtp-Source: AGHT+IHXhJiTtIQmegC8++el8fMG+T0dQ4x6codi7yt0ilpWOaKWdw2RlODL4ugKxsGk1yK6UcTPFw== X-Received: by 2002:a67:ec50:0:b0:46d:1cba:fc46 with SMTP id z16-20020a67ec50000000b0046d1cbafc46mr103835vso.2.1706948468707; Sat, 03 Feb 2024 00:21:08 -0800 (PST) Received: from mail-vk1-f181.google.com (mail-vk1-f181.google.com. [209.85.221.181]) by smtp.gmail.com with ESMTPSA id b17-20020a056102233100b0046af097562bsm392354vsa.9.2024.02.03.00.21.08 for (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Sat, 03 Feb 2024 00:21:08 -0800 (PST) Received: by mail-vk1-f181.google.com with SMTP id 71dfb90a1353d-4c00da9db0dso600014e0c.1 for ; Sat, 03 Feb 2024 00:21:08 -0800 (PST) X-Received: by 2002:a1f:7307:0:b0:4b7:49f9:c6f4 with SMTP id o7-20020a1f7307000000b004b749f9c6f4mr321792vkc.4.1706948468281; Sat, 03 Feb 2024 00:21:08 -0800 (PST) List-Id: Porting software to FreeBSD List-Archive: https://lists.freebsd.org/archives/freebsd-ports List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-ports@freebsd.org X-BeenThere: freebsd-ports@freebsd.org MIME-Version: 1.0 References: <7cjm-dwix-wny@FreeBSD.org> In-Reply-To: From: Gleb Popov Date: Sat, 3 Feb 2024 11:20:39 +0300 X-Gmail-Original-Message-ID: Message-ID: Subject: Re: poudriere-3.4.1 repeatedly builds subpackaged port To: =?UTF-8?Q?Lo=C3=AFc_Bartoletti?= Cc: ports@freebsd.org Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Rspamd-Queue-Id: 4TRlw55FH9z4NLh 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:209.85.128.0/17, country:US] On Sat, Feb 3, 2024 at 10:55=E2=80=AFAM Lo=C3=AFc Bartoletti wrote: > > Hi Gleb, > > Le 03/02/2024 =C3=A0 06:44, Gleb Popov a =C3=A9crit : > > http://arrowd.name/ports_writeup > > Do you think that it could be an entry in the porters-handbook? Eventually, yes, I'd love to see it in Handbook. But for now subpackages are a bleeding edge feature and there are several problems with its wide adoption. I also don't have enough free time to refine my brain dump into a proper Handbook section. So, maybe later. From nobody Sat Feb 3 15:24:48 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 4TRxK64lKcz59Z8c; Sat, 3 Feb 2024 15:24:58 +0000 (UTC) (envelope-from ml@netfence.it) Received: from soth.netfence.it (mailserver.netfence.it [78.134.96.152]) (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-signature RSA-PSS (2048 bits) client-digest SHA256) (Client CN "mailserver.netfence.it", Issuer "R3" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4TRxK53wB9z4HhN; Sat, 3 Feb 2024 15:24:57 +0000 (UTC) (envelope-from ml@netfence.it) Authentication-Results: mx1.freebsd.org; dkim=pass header.d=netfence.it header.s=202401 header.b=O0CJ6XN4; dmarc=pass (policy=none) header.from=netfence.it; spf=pass (mx1.freebsd.org: domain of ml@netfence.it designates 78.134.96.152 as permitted sender) smtp.mailfrom=ml@netfence.it Received: from [10.1.2.18] (alamar.local.netfence.it [10.1.2.18]) (authenticated bits=0) by soth.netfence.it (8.17.2/8.17.1) with ESMTPSA id 413FOmRa031594 (version=TLSv1.3 cipher=TLS_AES_128_GCM_SHA256 bits=128 verify=NO); Sat, 3 Feb 2024 16:24:49 +0100 (CET) (envelope-from ml@netfence.it) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=netfence.it; s=202401; t=1706973889; bh=9cve/VWFwUCoWmeS77QuEvdzD3Kle1AFjopXhm4mYAQ=; h=Date:To:Cc:From:Subject; b=O0CJ6XN4Z4z3I7CU7NodtMCytZF8KgtB5upHK3GDn9Db3W7cDpTQ/TLpu1ZhBXgUz woTj1D8h/ez9ochBnLjn9yVq0DWKuPA6Uf9n6KDJZfGchvLCk8dl7At4U4sFzSBptb GbXZfLWxWIJR7AC4+aa2XrHB3MNXCPAGEY/6Y/Ng= X-Authentication-Warning: soth.netfence.it: Host alamar.local.netfence.it [10.1.2.18] claimed to be [10.1.2.18] Message-ID: <954b15e9-7522-439a-a9e0-188f7b0056c9@netfence.it> Date: Sat, 3 Feb 2024 16:24:48 +0100 List-Id: Porting software to FreeBSD List-Archive: https://lists.freebsd.org/archives/freebsd-ports List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-ports@freebsd.org X-BeenThere: freebsd-ports@freebsd.org MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Content-Language: en-US To: elastic@FreeBSD.org Cc: ports@freebsd.org From: Andrea Venturoli Subject: Troubles with Kibana Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-Spamd-Bar: --- X-Spamd-Result: default: False [-3.99 / 15.00]; NEURAL_HAM_MEDIUM(-1.00)[-1.000]; NEURAL_HAM_LONG(-1.00)[-1.000]; NEURAL_HAM_SHORT(-1.00)[-1.000]; DMARC_POLICY_ALLOW(-0.50)[netfence.it,none]; R_SPF_ALLOW(-0.20)[+ip4:78.134.96.152]; R_DKIM_ALLOW(-0.20)[netfence.it:s=202401]; MIME_GOOD(-0.10)[text/plain]; XM_UA_NO_VERSION(0.01)[]; RCVD_VIA_SMTP_AUTH(0.00)[]; ASN(0.00)[asn:35612, ipnet:78.134.0.0/17, country:IT]; ARC_NA(0.00)[]; MIME_TRACE(0.00)[0:+]; RCVD_COUNT_ONE(0.00)[1]; RCVD_TLS_ALL(0.00)[]; RCPT_COUNT_TWO(0.00)[2]; MLMMJ_DEST(0.00)[ports@freebsd.org,elastic@FreeBSD.org]; FROM_HAS_DN(0.00)[]; HAS_XAW(0.00)[]; MID_RHS_MATCH_FROM(0.00)[]; FROM_EQ_ENVFROM(0.00)[]; TO_MATCH_ENVRCPT_ALL(0.00)[]; TO_DN_NONE(0.00)[]; DKIM_TRACE(0.00)[netfence.it:+] X-Rspamd-Queue-Id: 4TRxK53wB9z4HhN Hello. I've got a 13.2p9/amd64 server where I have a jail dedicated to ElasticSearch+Kibana and I'm having troubles starting and stopping the latter. > # pkg info | grep -E "(elastic|kibana)" > elasticsearch8-8.11.3 Distributed, RESTful search and analytics engine > kibana8-8.11.3 Browser based analytics and search interface to ElasticSearch > py39-elasticsearch-7.17.9 Official Python low-level client for Elasticsearch > py39-elasticsearch-dsl-7.3.0 High level Python client for Elasticsearch > # cat /etc/rc.conf > #cron_enable="NO" > kibana_enable="YES" > kibana_syslog_output_enable="YES" > elasticsearch_enable="YES" First problem When I start the jail (with "ezjail-admin start") Elastic starts, but Kibana does not. syslog shows: > [2024-02-03T16:14:21.861+01:00][INFO ][root] Kibana is starting > [2024-02-03T16:14:21.939+01:00][INFO ][root] Kibana is shutting down > [2024-02-03T16:14:21.939+01:00][FATAL][root] Reason: EACCES: permission denied, open '/var/run/kibana.pid' > Error: EACCES: permission denied, open '/var/run/kibana.pid' > > FATAL Error: EACCES: permission denied, open '/var/run/kibana.pid' Same happens if I try "service kibana start" afterwards from inside the jail. I can get around this with: > # touch /var/run/kibana.pid > # chown www /var/run/kibana.pid > # service kibana start However this must be done manually everytime I need to restart the server or jail. Second problem When I try to stop Kibana, it just hangs indefinitely: > # service kibana stop > Stopping kibana. > Waiting for PIDS: 28179 syslog reports: > [2024-02-03T16:20:22.309+01:00][INFO ][root] SIGTERM received - initiating shutdown > [2024-02-03T16:20:22.309+01:00][INFO ][root] Kibana is shutting down > [2024-02-03T16:20:22.311+01:00][INFO ][plugins-system.standard] Stopping all plugins. > [2024-02-03T16:20:22.314+01:00][INFO ][plugins.monitoring.monitoring.kibana-monitoring] Monitoring stats collection is stopped > [2024-02-03T16:20:22.323+01:00][INFO ][plugins-system.standard] All plugins stopped. > [2024-02-03T16:20:22.324+01:00][WARN ][environment] Detected an unhandled Promise rejection: Error: EACCES: permission denied, unlink '/var/run/kibana.pid' > at unlinkSync (node:fs:1883:3) > at process. (/usr/local/www/kibana8/node_modules/@kbn/core-environment-server-internal/src/write_pid_file.js:49:24) > at process. (/usr/local/www/kibana8/node_modules/lodash/before.js:31:21) > at Object.onceWrapper (node:events:632:26) > at process.emit (node:events:529:35) > at process.emit (/usr/local/www/kibana8/node_modules/source-map-support/source-map-support.js:516:21) > at process.exit (node:internal/process/per_thread:192:15) > at Root.onRootShutdown [as onShutdown] (/usr/local/www/kibana8/node_modules/@kbn/core-root-server-internal/src/bootstrap.js:136:11) > at Root.shutdown (/usr/local/www/kibana8/node_modules/@kbn/core-root-server-internal/src/root/index.js:96:12) > at processTicksAndRejections (node:internal/process/task_queues:95:5) > [2024-02-03T16:20:23.026+01:00][ERROR][plugins.taskManager] Failed to poll for work: NoLivingConnectionsError: There are no living connections > [2024-02-03T16:20:26.024+01:00][ERROR][plugins.taskManager] Failed to poll for work: NoLivingConnectionsError: There are no living connections > [2024-02-03T16:20:29.024+01:00][ERROR][plugins.taskManager] Failed to poll for work: NoLivingConnectionsError: There are no living connections > [2024-02-03T16:20:32.023+01:00][ERROR][plugins.taskManager] Failed to poll for work: NoLivingConnectionsError: There are no living connections > [2024-02-03T16:20:35.022+01:00][ERROR][plugins.taskManager] Failed to poll for work: NoLivingConnectionsError: There are no living connections > [2024-02-03T16:20:38.021+01:00][ERROR][plugins.taskManager] Failed to poll for work: NoLivingConnectionsError: There are no living connections > [2024-02-03T16:20:41.021+01:00][ERROR][plugins.taskManager] Failed to poll for work: NoLivingConnectionsError: There are no living connections > [2024-02-03T16:20:44.021+01:00][ERROR][plugins.taskManager] Failed to poll for work: NoLivingConnectionsError: There are no living connections > [2024-02-03T16:20:47.022+01:00][ERROR][plugins.taskManager] Failed to poll for work: NoLivingConnectionsError: There are no living connections > [2024-02-03T16:20:50.022+01:00][ERROR][plugins.taskManager] Failed to poll for work: NoLivingConnectionsError: There are no living connections > [2024-02-03T16:20:53.023+01:00][ERROR][plugins.taskManager] Failed to poll for work: NoLivingConnectionsError: There are no living connections > [2024-02-03T16:20:56.022+01:00][ERROR][plugins.taskManager] Failed to poll for work: NoLivingConnectionsError: There are no living connections > [2024-02-03T16:20:59.021+01:00][ERROR][plugins.taskManager] Failed to poll for work: NoLivingConnectionsError: There are no living connections > [2024-02-03T16:21:02.021+01:00][ERROR][plugins.taskManager] Failed to poll for work: NoLivingConnectionsError: There are no living connections > [2024-02-03T16:21:05.021+01:00][ERROR][plugins.taskManager] Failed to poll for work: NoLivingConnectionsError: There are no living connections > NoLivingConnectionsError: There are no living connections > [2024-02-03T16:21:08.022+01:00][ERROR][plugins.taskManager] Failed to poll for work: NoLivingConnectionsError: There are no living connections > [2024-02-03T16:21:11.023+01:00][ERROR][plugins.taskManager] Failed to poll for work: NoLivingConnectionsError: There are no living connections > [2024-02-03T16:21:14.022+01:00][ERROR][plugins.taskManager] Failed to poll for work: NoLivingConnectionsError: There are no living connections > [2024-02-03T16:21:17.021+01:00][ERROR][plugins.taskManager] Failed to poll for work: NoLivingConnectionsError: There are no living connections > [2024-02-03T16:21:20.020+01:00][ERROR][plugins.taskManager] Failed to poll for work: NoLivingConnectionsError: There are no living connections This goes on until I kill -9 the process. This is particularly problematic in case power goes missing and the UPS tries to shutdown the server, which will hang, instead. Any hint? bye & Thanks av. From nobody Sat Feb 3 15:30:37 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 4TRxS33mKGz59b1p for ; Sat, 3 Feb 2024 15:30:59 +0000 (UTC) (envelope-from einar@isnic.is) Received: from mx01.isnic.is (mx01.isnic.is [IPv6:2001:67c:6c:58::133]) (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-signature RSA-PSS (2048 bits) client-digest SHA256) (Client CN "mx01.isnic.is", Issuer "R3" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4TRxS22llCz4JBp for ; Sat, 3 Feb 2024 15:30:58 +0000 (UTC) (envelope-from einar@isnic.is) Authentication-Results: mx1.freebsd.org; dkim=pass header.d=isnic.is header.s=20200921 header.b=t5ReNHei; dmarc=pass (policy=quarantine) header.from=isnic.is; spf=pass (mx1.freebsd.org: domain of einar@isnic.is designates 2001:67c:6c:58::133 as permitted sender) smtp.mailfrom=einar@isnic.is Received: from ht-mailstore01.isnic.is (ht-mailstore01.isnic.is [IPv6:2001:67c:6c:56::2]) by mx01.isnic.is (Postfix) with ESMTPS id 17601208CA for ; Sat, 3 Feb 2024 15:30:48 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=isnic.is; s=20200921; t=1706974248; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:mime-version:mime-version:content-type:content-type: content-transfer-encoding:content-transfer-encoding; bh=Sft3Op4RKgPfux8RpHXtaEm40u/Nr3kdteu/8xwlVtQ=; b=t5ReNHeirbl/CiPJgbqjumtFbdGr/bk/ylyTWwSM166VRg2ijiOm03bskCe4e8PId6md5B guGXL962tCLolGp77tqPSxgsZmh5hU+M5AuVSF9PRmdHhV79MNRT3g52Bk39GzeTiVCQpt ZnYhI0C/qqOMAuZahMP9CsHWQFsho9zJqpvvTDbfq2doIp/n0ckGkQ3/67BE9Gfk4Y6nk2 t2L1MTGbQzN5K2eP6uGFnDVE+a69a1xB5jiD7Ivvc3fOL0Dwd0dq40D0ek8L1Ly/xx46Fh gyBOu+1DAEkfFyS4hqNcd9gsiuUI6k5W+zHM7p82WfqeJLifaq1vqDmx4CC27A== Received: from smtpclient.apple (unknown [185.93.159.194]) by ht-mailstore01.isnic.is (Postfix) with ESMTPS id 0E64620DC3 for ; Sat, 3 Feb 2024 15:30:48 +0000 (UTC) From: =?utf-8?Q?Einar_Bjarni_Halld=C3=B3rsson?= Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable List-Id: Porting software to FreeBSD List-Archive: https://lists.freebsd.org/archives/freebsd-ports List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-ports@freebsd.org X-BeenThere: freebsd-ports@freebsd.org Mime-Version: 1.0 (Mac OS X Mail 16.0 \(3774.400.31\)) Subject: Multiple new R ports Message-Id: <44F61FC1-532F-447F-80E9-83ED37599CD7@isnic.is> Date: Sat, 3 Feb 2024 15:30:37 +0000 To: ports@freebsd.org X-Mailer: Apple Mail (2.3774.400.31) X-Spamd-Bar: --- X-Spamd-Result: default: False [-4.00 / 15.00]; NEURAL_HAM_LONG(-1.00)[-1.000]; NEURAL_HAM_MEDIUM(-1.00)[-1.000]; NEURAL_HAM_SHORT(-1.00)[-1.000]; DMARC_POLICY_ALLOW(-0.50)[isnic.is,quarantine]; R_DKIM_ALLOW(-0.20)[isnic.is:s=20200921]; R_SPF_ALLOW(-0.20)[+ip6:2001:67c:6c::/48]; MIME_GOOD(-0.10)[text/plain]; RCPT_COUNT_ONE(0.00)[1]; ASN(0.00)[asn:1850, ipnet:2001:67c:6c::/48, country:IS]; APPLE_MAILER_COMMON(0.00)[]; MIME_TRACE(0.00)[0:+]; RCVD_TLS_ALL(0.00)[]; MID_RHS_MATCH_FROM(0.00)[]; MLMMJ_DEST(0.00)[ports@freebsd.org]; FROM_EQ_ENVFROM(0.00)[]; FROM_HAS_DN(0.00)[]; ARC_NA(0.00)[]; RCVD_COUNT_TWO(0.00)[2]; TO_MATCH_ENVRCPT_ALL(0.00)[]; TO_DN_NONE(0.00)[]; PREVIOUSLY_DELIVERED(0.00)[ports@freebsd.org]; DKIM_TRACE(0.00)[isnic.is:+] X-Rspamd-Queue-Id: 4TRxS22llCz4JBp Hi, I needed to create three new R ports, but with new ports for missing = dependencies, it=E2=80=99s 13 new ports in total, all R packages. Should I create one PR for them all, or one for each package with = blockers for dependencies? .einar= From nobody Sat Feb 3 16:05:20 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 4TRyCw5Sdyz59dpR for ; Sat, 3 Feb 2024 16:05:32 +0000 (UTC) (envelope-from SRS0=Ta0Z=JM=quip.cz=000.fbsd@elsa.codelab.cz) Received: from elsa.codelab.cz (elsa.codelab.cz [94.124.105.4]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 4TRyCv0nmNz4NhF for ; Sat, 3 Feb 2024 16:05:30 +0000 (UTC) (envelope-from SRS0=Ta0Z=JM=quip.cz=000.fbsd@elsa.codelab.cz) Authentication-Results: mx1.freebsd.org; dkim=pass header.d=quip.cz header.s=private header.b=qCCXPP7a; dkim=pass header.d=quip.cz header.s=private header.b=55PtOSYZ; dmarc=none; spf=none (mx1.freebsd.org: domain of "SRS0=Ta0Z=JM=quip.cz=000.fbsd@elsa.codelab.cz" has no SPF policy when checking 94.124.105.4) smtp.mailfrom="SRS0=Ta0Z=JM=quip.cz=000.fbsd@elsa.codelab.cz" Received: from elsa.codelab.cz (localhost [127.0.0.1]) by elsa.codelab.cz (Postfix) with ESMTP id F3F3AD78AA for ; Sat, 3 Feb 2024 17:05:21 +0100 (CET) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=quip.cz; s=private; t=1706976322; bh=FakxseVOBCleWGJ3QDlLrVEe4YegYjZFXL2wQScQXwI=; h=Date:Subject:To:References:From:In-Reply-To; b=qCCXPP7a3fXmmB7YuG+srRtgaDoiwO/InQS9rHo+AcWUZ7pzwuzF9B9c2Ajj/FpzM t2K0QS923BJ26n3ld+T0I5dYny3092OnpcyghCXoAfTwnhkPCRadEDB7c6Pd/z4MzU 2apx9SFuObSVzkXqmNUy+Byd2Vrk0gmeyoXJce78= Received: from [192.168.145.49] (ip-89-177-27-225.bb.vodafone.cz [89.177.27.225]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by elsa.codelab.cz (Postfix) with ESMTPSA id 9B398D7894 for ; Sat, 3 Feb 2024 17:05:20 +0100 (CET) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=quip.cz; s=private; t=1706976320; bh=FakxseVOBCleWGJ3QDlLrVEe4YegYjZFXL2wQScQXwI=; h=Date:Subject:To:References:From:In-Reply-To; b=55PtOSYZ6lbAF2EGKUeklM7G+7cUZqMNQH67Z8+VoRmJHMeBphdYWUbnJKfEePsVw vBmcFaQ09oGDX7FQQ+CVbfzie+qODaD9l2twQj3cILsfmGA7O+YiFsFiz2uR/vIBCt N52RQkenr1XrHezhxhz8GZBeMyU03HaJ7OqirlY4= Message-ID: <5336ee37-7966-4745-97c4-9ce41570d6be@quip.cz> Date: Sat, 3 Feb 2024 17:05:20 +0100 List-Id: Porting software to FreeBSD List-Archive: https://lists.freebsd.org/archives/freebsd-ports List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-ports@freebsd.org X-BeenThere: freebsd-ports@freebsd.org MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: Troubles with Kibana Content-Language: en-US To: ports@freebsd.org References: <954b15e9-7522-439a-a9e0-188f7b0056c9@netfence.it> From: Miroslav Lachman <000.fbsd@quip.cz> In-Reply-To: <954b15e9-7522-439a-a9e0-188f7b0056c9@netfence.it> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit X-Spamd-Bar: -- X-Spamd-Result: default: False [-2.99 / 15.00]; NEURAL_HAM_MEDIUM(-1.00)[-1.000]; NEURAL_HAM_LONG(-1.00)[-1.000]; NEURAL_HAM_SHORT(-1.00)[-1.000]; FORGED_SENDER(0.30)[000.fbsd@quip.cz,SRS0=Ta0Z=JM=quip.cz=000.fbsd@elsa.codelab.cz]; R_DKIM_ALLOW(-0.20)[quip.cz:s=private]; MIME_GOOD(-0.10)[text/plain]; XM_UA_NO_VERSION(0.01)[]; R_SPF_NA(0.00)[no SPF record]; RCVD_VIA_SMTP_AUTH(0.00)[]; RCPT_COUNT_ONE(0.00)[1]; DMARC_NA(0.00)[quip.cz]; MIME_TRACE(0.00)[0:+]; ASN(0.00)[asn:42000, ipnet:94.124.104.0/21, country:CZ]; MID_RHS_MATCH_FROM(0.00)[]; ARC_NA(0.00)[]; MLMMJ_DEST(0.00)[ports@freebsd.org]; FROM_NEQ_ENVFROM(0.00)[000.fbsd@quip.cz,SRS0=Ta0Z=JM=quip.cz=000.fbsd@elsa.codelab.cz]; FROM_HAS_DN(0.00)[]; RCVD_TLS_LAST(0.00)[]; RCVD_COUNT_TWO(0.00)[2]; TO_MATCH_ENVRCPT_ALL(0.00)[]; TO_DN_NONE(0.00)[]; PREVIOUSLY_DELIVERED(0.00)[ports@freebsd.org]; DKIM_TRACE(0.00)[quip.cz:+] X-Rspamd-Queue-Id: 4TRyCv0nmNz4NhF On 03/02/2024 16:24, Andrea Venturoli wrote: > Hello. > > I've got a 13.2p9/amd64 server where I have a jail dedicated to > ElasticSearch+Kibana and I'm having troubles starting and stopping the > latter. > >> # pkg info | grep -E "(elastic|kibana)" >> elasticsearch8-8.11.3          Distributed, RESTful search and >> analytics engine >> kibana8-8.11.3                 Browser based analytics and search >> interface to ElasticSearch >> py39-elasticsearch-7.17.9      Official Python low-level client for >> Elasticsearch >> py39-elasticsearch-dsl-7.3.0   High level Python client for Elasticsearch > >> # cat /etc/rc.conf >> #cron_enable="NO" >> kibana_enable="YES" >> kibana_syslog_output_enable="YES" >> elasticsearch_enable="YES" > > First problem > > When I start the jail (with "ezjail-admin start") Elastic starts, but > Kibana does not. > syslog shows: >> [2024-02-03T16:14:21.861+01:00][INFO ][root] Kibana is starting >> [2024-02-03T16:14:21.939+01:00][INFO ][root] Kibana is shutting down >> [2024-02-03T16:14:21.939+01:00][FATAL][root] Reason: EACCES: >> permission denied, open '/var/run/kibana.pid' >> Error: EACCES: permission denied, open '/var/run/kibana.pid' >> >>  FATAL  Error: EACCES: permission denied, open '/var/run/kibana.pid' > > Same happens if I try "service kibana start" afterwards from inside the > jail. > I can get around this with: >> # touch /var/run/kibana.pid >> # chown www /var/run/kibana.pid >> # service kibana start > > However this must be done manually everytime I need to restart the > server or jail. Both, the first and the second problem are caused by permissions problem on PID file. I no longer use Kibana, but if Kibana is running as user www and tries to write to /var/run/ as that user, it must fail. But a quick look at the rc.d/kibana [1] show that the PID file should be written to subdirectory /var/run/kibana/kibana.pid Do you have any local modification to the path of the PID file? (for example, in the kibana.yml file) /var/run/kibana/ is created by rc.d/kibana with the correct owner and permissions, so "it should work". Try to figure out why your Kibana is trying to write /var/run/kibana.pid instead of /var/run/kibana/kibana.pid. > Second problem > > When I try to stop Kibana, it just hangs indefinitely: >>  # service kibana stop >> Stopping kibana. >> Waiting for PIDS: 28179 > > syslog reports: >> [2024-02-03T16:20:22.309+01:00][INFO ][root] SIGTERM received - >> initiating shutdown >> [2024-02-03T16:20:22.309+01:00][INFO ][root] Kibana is shutting down >> [2024-02-03T16:20:22.311+01:00][INFO ][plugins-system.standard] >> Stopping all plugins. >> [2024-02-03T16:20:22.314+01:00][INFO >> ][plugins.monitoring.monitoring.kibana-monitoring] Monitoring stats >> collection is stopped >> [2024-02-03T16:20:22.323+01:00][INFO ][plugins-system.standard] All >> plugins stopped. >> [2024-02-03T16:20:22.324+01:00][WARN ][environment] Detected an >> unhandled Promise rejection: Error: EACCES: permission denied, unlink >> '/var/run/kibana.pid' ^^^ PID file cannot be deleted as user www because parent dir is owned by root and no one else can write to it. [1] https://cgit.freebsd.org/ports/tree/textproc/kibana8/files/kibana.in Kind regards Miroslav Lachman From nobody Sat Feb 3 18:56:29 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 4TS22M0g7bz58C3T for ; Sat, 3 Feb 2024 18:57:31 +0000 (UTC) (envelope-from 6yearold@gmail.com) Received: from mail-io1-f43.google.com (mail-io1-f43.google.com [209.85.166.43]) (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 4TS22L5lNTz4tq9 for ; Sat, 3 Feb 2024 18:57:30 +0000 (UTC) (envelope-from 6yearold@gmail.com) Authentication-Results: mx1.freebsd.org; none Received: by mail-io1-f43.google.com with SMTP id ca18e2360f4ac-7bed9c7d33fso129556839f.1 for ; Sat, 03 Feb 2024 10:57:30 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1706986649; x=1707591449; h=content-transfer-encoding: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=ef79Sy+Fditff0xC8K23Usc0rwZugRiVPrWO5KgEMvs=; b=uWR9gX6jAoLVwE9YfhozdmzkmkkZ9HZAnmmhPgC2cnpAVlQ51rlGtKb9wz9fMiAXGR b4W0H8Voc/2kxdHFDvR/fCAfrfWnpBDZnWHLMaAlg6i6ZV/y+6aL8TFAqUdtAUqVQ1fy GGH6zi+ko3fMwclL+LJ++i2l1LptixILjpHa7itil0/mqDRi0jgnYUazy4cXSqBOYt9d woUCu9mZ/JImf15SPtkT2ieeAZqehjVHZC3amchEfYo6tUOhYFfXeW5hICiQYU7vUDZP w5UyxS2ipZryNKPi3XLkYON1MEznuybkEPMA8hMo7QogA7pJfKNqWFYFXMOsb2Xci4Dd lvUw== X-Gm-Message-State: AOJu0YzUokvdIwejb5kP4tEFFR8LDilDKz5Ur9wCNMvUruUrW00rstE8 9tJ0ROu0yN/mZEciFqcRAdIwwqwBXO5N7jMEIP0abiW97rJfz9bEaRwN8LjY9KI= X-Google-Smtp-Source: AGHT+IEB2WgYXngIDFH5x2Hy3vaPt34ZkWNjw2PTAq08Fofo52o7JcmgKu7Dn5gTI9gmeR1KE7m3Ow== X-Received: by 2002:a5d:850d:0:b0:7bf:ea24:9f5b with SMTP id q13-20020a5d850d000000b007bfea249f5bmr5865549ion.0.1706986648949; Sat, 03 Feb 2024 10:57:28 -0800 (PST) Received: from mail-il1-f182.google.com (mail-il1-f182.google.com. [209.85.166.182]) by smtp.gmail.com with ESMTPSA id z24-20020a056602123800b007c31a9124d7sm214428iot.11.2024.02.03.10.57.28 for (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Sat, 03 Feb 2024 10:57:28 -0800 (PST) Received: by mail-il1-f182.google.com with SMTP id e9e14a558f8ab-363ac28b375so6833515ab.3 for ; Sat, 03 Feb 2024 10:57:28 -0800 (PST) X-Received: by 2002:a05:6e02:c86:b0:363:abc0:4faf with SMTP id b6-20020a056e020c8600b00363abc04fafmr5810021ile.7.1706986648477; Sat, 03 Feb 2024 10:57:28 -0800 (PST) List-Id: Porting software to FreeBSD List-Archive: https://lists.freebsd.org/archives/freebsd-ports List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-ports@freebsd.org X-BeenThere: freebsd-ports@freebsd.org MIME-Version: 1.0 References: <44F61FC1-532F-447F-80E9-83ED37599CD7@isnic.is> In-Reply-To: <44F61FC1-532F-447F-80E9-83ED37599CD7@isnic.is> From: Gleb Popov Date: Sat, 3 Feb 2024 21:56:29 +0300 X-Gmail-Original-Message-ID: Message-ID: Subject: Re: Multiple new R ports To: =?UTF-8?Q?Einar_Bjarni_Halld=C3=B3rsson?= Cc: ports@freebsd.org Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Rspamd-Queue-Id: 4TS22L5lNTz4tq9 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:209.85.128.0/17, country:US] On Sat, Feb 3, 2024 at 6:31=E2=80=AFPM Einar Bjarni Halld=C3=B3rsson wrote: > > Hi, > > I needed to create three new R ports, but with new ports for missing depe= ndencies, it=E2=80=99s 13 new ports in total, all R packages. > > Should I create one PR for them all, or one for each package with blocker= s for dependencies? > > einar Single PR should be fine. You may also consider creating a Differential revision on our Phabricator. From nobody Sun Feb 4 04:02:39 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 4TSG7N0bwpz58sQy for ; Sun, 4 Feb 2024 04:02:40 +0000 (UTC) (envelope-from portscout@FreeBSD.org) Received: from mxrelay.nyi.freebsd.org (mxrelay.nyi.freebsd.org [IPv6:2610:1c1:1:606c::19:3]) (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-signature RSA-PSS (4096 bits) client-digest SHA256) (Client CN "mxrelay.nyi.freebsd.org", Issuer "R3" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4TSG7M5PKtz4qrm for ; Sun, 4 Feb 2024 04:02:39 +0000 (UTC) (envelope-from portscout@FreeBSD.org) ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=freebsd.org; s=dkim; t=1707019359; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:mime-version:mime-version:content-type:content-type: content-transfer-encoding:content-transfer-encoding; bh=jBmqjRef0nni6spz6y3409qQna3wHrNxdrZl9M/SDs0=; b=TiFNkddtEygVtr4pPTioAi3Bk7n8wgNmaOxblLQjOFrYlPTa377f0ann0w+V39CqxaGn7w xI1AkejiQ7pBVp+B9Oq+niQNrhWwMl0PTJjehhDi9F+ycB3oRzZ20SoxDGykZiAHxtdaBV ythpRJU3yC9KMx62gXP0sCT+Zc1sxm0/lRMl8GEbydZCIdH1OEECirenySbYXS+cggQO79 2g9X2U78qu45YmI2Zfhbfps9d1BKRzbi4Ly0vZ2UgjF5Jy/jdN/WKKYivdzgu1tshhsM8o rXu/AXudRqf4ToN0dKldqwm1WPYTHIh/Imvi87366MJ1W5/QsI5x+mPd8WMB6Q== ARC-Authentication-Results: i=1; mx1.freebsd.org; none ARC-Seal: i=1; s=dkim; d=freebsd.org; t=1707019359; a=rsa-sha256; cv=none; b=E/xktMJ5EyT2GKFu/04g86Hz/+jJHLhZM8GZxFUKR4yelOud53b7PJkRKOdcHj4VX5DRlR q4Wd9Pf/OreycE+VCbuKOZ5gTLt5RxezBSydouHhFGTiPK2fe2hG9WfYRCfbDFNG1u0GRC KW2s677biMJb+UvtFU603RxnOCAM/8e5PPFOtLRqQjLhJzCXxTkov4Z2OIeKg2b1ohs/Wz xmDF3sx9QintG+HPn40Rg1mH3zHWwK2aB3n3yjdnip7IVQHYeJSXVrFW4Wipz63EDdLa/X 73DoIX3vRCmpXT9gg0ezjVqli0Ot5iPJLTo3AEKlxCimBPaK/TYOY8JT1cQ0sg== Received: from portscout.nyi.freebsd.org (portscout.nyi.freebsd.org [IPv6:2610:1c1:1:606c::50:21]) (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 mxrelay.nyi.freebsd.org (Postfix) with ESMTPS id 4TSG7M454Tzj9J for ; Sun, 4 Feb 2024 04:02:39 +0000 (UTC) (envelope-from portscout@FreeBSD.org) Received: from portscout.nyi.freebsd.org ([127.0.1.10]) by portscout.nyi.freebsd.org (8.17.1/8.17.1) with ESMTP id 41442d7C071946 for ; Sun, 4 Feb 2024 04:02:39 GMT (envelope-from portscout@FreeBSD.org) Received: (from portscout@localhost) by portscout.nyi.freebsd.org (8.17.1/8.17.1/Submit) id 41442d2i071945; Sun, 4 Feb 2024 04:02:39 GMT (envelope-from portscout@FreeBSD.org) Message-Id: <202402040402.41442d2i071945@portscout.nyi.freebsd.org> X-Authentication-Warning: portscout.nyi.freebsd.org: portscout set sender to portscout@FreeBSD.org using -f Content-Disposition: inline Content-Transfer-Encoding: 8bit Content-Type: text/plain List-Id: Porting software to FreeBSD List-Archive: https://lists.freebsd.org/archives/freebsd-ports List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-ports@freebsd.org X-BeenThere: freebsd-ports@freebsd.org MIME-Version: 1.0 Date: Sun, 4 Feb 2024 04:02:39 +0000 From: portscout@FreeBSD.org To: ports@freebsd.org Subject: Unmaintained FreeBSD ports which are out of date X-Mailer: portscout/0.8.1 Dear port maintainers, The portscout new distfile checker has detected that one or more unmaintained ports appears to be out of date. Please take the opportunity to check each of the ports listed below, and if possible and appropriate, submit/commit an update. Please consider also adopting this port. If any ports have already been updated, you can safely ignore the entry. An e-mail will not be sent again for any of the port/version combinations below. Full details can be found at the following URL: http://portscout.freebsd.org/ports@freebsd.org.html Port | Current version | New version ------------------------------------------------+-----------------+------------ cad/ifcopenshell | 0.6.0 | blenderbim-240202 ------------------------------------------------+-----------------+------------ games/retroarch | 1.16.0.3 | v1.17.0 ------------------------------------------------+-----------------+------------ math/wxmaxima | 23.12.0 | version-24.02.0 ------------------------------------------------+-----------------+------------ www/kanboard | 1.2.34 | v1.2.35 ------------------------------------------------+-----------------+------------ If any of the above results are invalid, please check the following page for details on how to improve portscout's detection and selection of distfiles on a per-port basis: http://portscout.freebsd.org/info/portscout-portconfig.txt Reported by: portscout! From nobody Sun Feb 4 13:34:06 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 4TSVq40pKMz59n8Y for ; Sun, 4 Feb 2024 13:34:24 +0000 (UTC) (envelope-from einar@isnic.is) Received: from mx01.isnic.is (mx01.isnic.is [IPv6:2001:67c:6c:58::133]) (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-signature RSA-PSS (2048 bits) client-digest SHA256) (Client CN "mx01.isnic.is", Issuer "R3" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4TSVq34KhHz4TwX; Sun, 4 Feb 2024 13:34:23 +0000 (UTC) (envelope-from einar@isnic.is) Authentication-Results: mx1.freebsd.org; none Received: from ht-mailstore01.isnic.is (ht-mailstore01.isnic.is [185.93.156.2]) by mx01.isnic.is (Postfix) with ESMTPS id 7BF062328D; Sun, 4 Feb 2024 13:34:17 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=isnic.is; s=20200921; t=1707053657; 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: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=w8R6ModJjaTKuS4Q8KRKrAXeGLfMe0O8BxnibzAYFjc=; b=WRvlgdzR51lDyyWVJyUL3jDlpCAdc34V1xvto1NwnMcIQgtvUQDIILe2icuxmknM1JUhBU rKJP/FEE+7s7PktQtMVfl1qDhE4Ic6JYVZ6hBX99STIrBeYVNZHIE3an/XPbqffPQJ++OP +h+b3e1pwGZNBHoCIiQwgcfkK0RB1S9vfGpE3HW1q4jl5aVlHeW5etaVpHR1kBR2bb0Nyn MLMEda7mtHAKzn9XIoNSqi5SzgbhOZPEbiHMHOBcichFESYoL/ZyMT3AoqOf1oHIHpjAtQ tbdO//RfeLh34ixhhgRzTFrYbMH6wDMLaKrCdgDeg7rHgg/6ECp71bNT5XBMtg== Received: from smtpclient.apple (unknown [185.93.159.194]) by ht-mailstore01.isnic.is (Postfix) with ESMTPS id 65098216C1; Sun, 4 Feb 2024 13:34:17 +0000 (UTC) Content-Type: text/plain; charset=utf-8 List-Id: Porting software to FreeBSD List-Archive: https://lists.freebsd.org/archives/freebsd-ports List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-ports@freebsd.org X-BeenThere: freebsd-ports@freebsd.org Mime-Version: 1.0 (Mac OS X Mail 16.0 \(3774.400.31\)) Subject: Re: Multiple new R ports From: =?utf-8?Q?Einar_Bjarni_Halld=C3=B3rsson?= In-Reply-To: Date: Sun, 4 Feb 2024 13:34:06 +0000 Cc: ports@freebsd.org Content-Transfer-Encoding: quoted-printable Message-Id: References: <44F61FC1-532F-447F-80E9-83ED37599CD7@isnic.is> To: Gleb Popov X-Mailer: Apple Mail (2.3774.400.31) X-Rspamd-Queue-Id: 4TSVq34KhHz4TwX 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:1850, ipnet:2001:67c:6c::/48, country:IS] > On 3 Feb 2024, at 18:56, Gleb Popov wrote: >=20 > On Sat, Feb 3, 2024 at 6:31=E2=80=AFPM Einar Bjarni Halld=C3=B3rsson = wrote: >>=20 >> Hi, >>=20 >> I needed to create three new R ports, but with new ports for missing = dependencies, it=E2=80=99s 13 new ports in total, all R packages. >>=20 >> Should I create one PR for them all, or one for each package with = blockers for dependencies? >>=20 >> einar >=20 > Single PR should be fine. You may also consider creating a > Differential revision on our Phabricator. >=20 Thanks. I created a revision in Phabricator for all the ports. We=E2=80=99= ll see how it goes. If needed, I can chop it up into multiple revisions. .einar