packages for 12.4
Will package building be switched from 12.3 to 12.4?
www/chromium:
.if ${OSREL} == "12.3"
IGNORE= does not compile, libc++ too old
.endif
Last package for amd64 106.0.5249.119_1 (27 October),
the port has 108.0.5359.98 today.
https://pkg-status.freebsd.org/builds?server=beefy6&all=1
says last build was started on 10 December for 12.3.
Re: packages for 12.4
On 12/13/22 01:06, l...@lena.kiev.ua wrote:
Will package building be switched from 12.3 to 12.4?
I presume no; 12.3 is still supported. Maybe a job still needs to be
created to support 12.4 and start making those packages?
www/chromium:
.if ${OSREL} == "12.3"
IGNORE= does not compile, libc++ too old
.endif
Last package for amd64 106.0.5249.119_1 (27 October),
the port has 108.0.5359.98 today.
https://pkg-status.freebsd.org/builds?server=beefy6&all=1
says last build was started on 10 December for 12.3.
Re: packages for 12.4
Van: l...@lena.kiev.ua
Datum: dinsdag, 13 december 2022 09:06
Aan: freebsd-po...@freebsd.org
Onderwerp: packages for 12.4
Will package building be switched from 12.3 to 12.4?
www/chromium:
.if ${OSREL} == "12.3"
IGNORE= does not compile, libc++ too old
.endif
Last package for amd64 106.0.5249.119_1 (27 October),
the port has 108.0.5359.98 today.
https://pkg-status.freebsd.org/builds?server=beefy6&all=1
says last build was started on 10 December for 12.3.
Â
Hi,
The policy (as I last read it) is to build packages on the oldest supported
version of a branch. A newer FreeBSD version (12.4) is assumed to be backwards
compatible with an older FreeBSD version (12.3) so pkgs build on 12.3 should
run on 12.4. FreeBSD 12.3 is not expected to be forwards compatible with 12.4
as you can't predict the future changes. So packages build on 12.4 are not
promised to work on 12.3.
12.3 goes end-of-life around March 5th, 2023, see:
https://www.freebsd.org/security/#sup
So around that date the package building will be run on 12.4.
There have been discussions about starting to build packages on a new FreeBSD
version earlier but that did not happen yet. I don't know what the reasons are.
The tools are available to setup your own FreeBSD 12.4 and build packages for
it.
https://docs.freebsd.org/en/books/handbook/ports/#ports-poudriere
Regards,
Ronald.
Â
Re: Procmail Version
That's great, thanks for the pointer. I read in the commit message the following: As this upstream is in active development and the original procmail on sourceforge is defunct, we may wish to consider merging or replacing mail/procmail with this port at some point. I have a few thoughts. This does not appear to be a fork. It looks like a new version hosted on Github. The author updated the copyright and I looked at older READMEs from pre-2001 and the author's email is the same as today, srb [@] cuci[.]nl. I have not sent an email to this email address, but the MX SMTP greeting is quite similar to the username of the entity who is checking in the new updates: "ESMTP Postfix (Cubic Circle/BuGless)". Is the reasoning behind calling this a fork and not a new version because the identity of the entity checking in updates on the Github repo cannot be confirmed? On Tue, Dec 13, 2022 at 2:16 AM Alexander Leidinger wrote: > Quoting Robert Simmons (from Mon, 12 Dec 2022 > 18:22:27 -0500): > > There is a new version of procmail. Is updating the FreeBSD port to the > new 3.24 a good idea? > > https://github.com/BuGlessRB/procmail/releases > > > Have a look at $PORTSDIR/mail/procmail-bgrb/ > > Bye, > Alexander. > > http://www.Leidinger.net alexan...@leidinger.net: PGP 0x8F31830F9F2772BF > http://www.FreeBSD.orgnetch...@freebsd.org : PGP 0x8F31830F9F2772BF >
Re: lang/rust is super slow to build
On 2022-12-12 11:27, Pat Maddox wrote: Using poudriere, lang/rust is at 2 hours and counting on my 10-core i9 w/ 128 gigs of RAM. Does that sound right? It seems extremely slow to me, but this is my first time building it. That sounds typical. You can use ccache and tmpfs to speed it up a little bit, but both rust and llvm are computationally massive. Even worse, poudriere doesn't need to build it. If you aren't changing its options there's no functional difference between building it locally and installing from the public pkg repo. Poudriere does have the ability to install from pkgs, but there is a 2-year-old bug that prevents that feature from working correctly. I recommend everyone comment on issue #822 on the freebsd/poudriere github[1] and explain how much of a pain it is that poudriere doesn't have sane behaviour wrt dependencies. Maybe if enough people comment it will spur a fix. 1: https://github.com/freebsd/poudriere/issues/822
Re: lang/rust is super slow to build
On 2022-12-13 8:38, Christoph Brinkhaus wrote: Am Tue, Dec 13, 2022 at 07:55:11AM -0800 schrieb Mel Pilgrim: Even worse, poudriere doesn't need to build it. If you aren't changing its options there's no functional difference between building it locally and installing from the public pkg repo. Poudriere does have the ability to install from pkgs, but there is a 2-year-old bug that prevents that feature from working correctly. The developmenmt version poudriere-devel has got the feature to download the packages specified in some configuration file. Disclaimer: I have not used it because I can like with the packaged software. I have used it. Both -b branch and PACKAGE_FETCH_*. The feature you mention does indeed download pkgs. But, as is documented in issues on the project, the bug makes poudriere delete the pkgs it just fetched and queue up builds instead.
Unmaintained FreeBSD ports which are out of date
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/po...@freebsd.org.html Port| Current version | New version +-+ games/retroarch | 1.10.3 | v1.14.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!
Re: lang/rust is super slow to build
On Tue, Dec 13, 2022 at 7:55 AM Mel Pilgrim wrote: > On 2022-12-12 11:27, Pat Maddox wrote: > > Using poudriere, lang/rust is at 2 hours and counting on my 10-core i9 > > w/ 128 gigs of RAM. > > > > Does that sound right? It seems extremely slow to me, but this is my > > first time building it. > > That sounds typical. You can use ccache and tmpfs to speed it up a > little bit, but both rust and llvm are computationally massive. > > Even worse, poudriere doesn't need to build it. If you aren't changing > its options there's no functional difference between building it locally > and installing from the public pkg repo. Poudriere does have the > ability to install from pkgs, but there is a 2-year-old bug that > prevents that feature from working correctly. > > I recommend everyone comment on issue #822 on the freebsd/poudriere > github[1] and explain how much of a pain it is that poudriere doesn't > have sane behaviour wrt dependencies. Maybe if enough people comment it > will spur a fix. > > 1: https://github.com/freebsd/poudriere/issues/822 IMHO the ports collection should provide and use prebuilt packages of compilers (LLVM, GCC, Rust, etc.) built from the FreeBSD packages builder, and ports framework (possibly also the base system) should be changed to use prebuilt packages by default, unless a) user requested to build everything from source, or b) no binary package is available for the platform combination, like a Tier-2 platform. The source ports for compilers should have all optimizations (like PGO, LTO, etc.) enabled by default, and require reasonably modern (perhaps newer than Sandy Bridge) processor features by default. It does not make sense for most users to build compilers from source all the time, because most of them don't make any changes that would affect the toolchain, which takes hours for them to build, even with beefy machines and with parallelism and caching enabled. For these users, it's just a waste of time and also increases their carbon footprint for nothing good. Cheers,
Re: lang/rust is super slow to build
Using poudriere, lang/rust is at 2 hours and counting on my 10-core i9 w/ 128 gigs of RAM. Several interpreters and compilers take a long time to build today. This may change, of course, after another generation of hardware is released. Even worse, poudriere doesn't need to build it. If you aren't changing its options there's no functional difference between building it locally No difference for you perhaps but that is an important difference to many of us. IMHO the ports collection should provide and use prebuilt packages of compilers (LLVM, GCC, Rust, etc.) built from the FreeBSD packages builder, and ports framework (possibly also the base system) should be changed to use prebuilt packages by default. That would violate the principle of least surprise. If the same command used with one port compiles from source but when used from another port downloads a pre-built binary that's to be avoided (whether or not some java ports already do this). If we're talking about Poudriere then please first consider better build-time optimizations than downloading binaries that may have security implications and will change over time. Tangent: If we're talking about additional make (not pkg) functionality then please add a constant to only create packages, for the target app and all dependencies, and install them only using pkg (the OpenBSD model). Roger
Re: lang/rust is super slow to build
On Tue, Dec 13, 2022 at 3:32 PM Roger Marquis wrote: > > IMHO the ports collection should provide and use prebuilt packages of > > compilers (LLVM, GCC, Rust, etc.) built from the FreeBSD packages > builder, > > and ports framework (possibly also the base system) should be changed to > > use prebuilt packages by default. > > That would violate the principle of least surprise. If the same command > used with one port compiles from source but when used from another port > downloads a pre-built binary that's to be avoided (whether or not some > java ports already do this). > POLA doesn't mean we can not make reasonable changes to the existing practices. In fact, poudriere is already using prebuilt packages: when a set of packages depends on GCC, for example, it would build a binary package, then use that binary package for building these packages instead of building GCC over and over again. > If we're talking about Poudriere then please first consider better > build-time optimizations than downloading binaries that may have > security implications and will change over time. > Well optimization is an orthogonal goal. We should explore build time optimizations, but that doesn't change the fact that repeatedly building the same source artifact shall generate the same binary artifacts. Optimization means one can build these binaries faster when they want, and using prebuilt artifacts means one doesn't have to rebuild them over and over again, which is usually not needed. Using prebuilt binaries is not necessarily compromising security when done right. I think to ensure safety of these prebuilt binaries, we need to invest in e.g. making package builds reproducible (so an independent third party can audit and validate that the binaries are actually built from the source that they claimed to be when they want), ensure that the builders are safe, and sign the packages on the builders. > > Tangent: If we're talking about additional make (not pkg) functionality > then please add a constant to only create packages, for the target app > and all dependencies, and install them only using pkg (the OpenBSD > model). > > Roger > >
Re: lang/rust is super slow to build
On Tue, Dec 13, 2022, at 2:18 PM, Xin LI wrote: > On Tue, Dec 13, 2022 at 7:55 AM Mel Pilgrim > wrote: > >> On 2022-12-12 11:27, Pat Maddox wrote: >> > Using poudriere, lang/rust is at 2 hours and counting on my 10-core i9 >> > w/ 128 gigs of RAM. >> > >> > Does that sound right? It seems extremely slow to me, but this is my >> > first time building it. >> >> That sounds typical. You can use ccache and tmpfs to speed it up a >> little bit, but both rust and llvm are computationally massive. >> >> Even worse, poudriere doesn't need to build it. If you aren't changing >> its options there's no functional difference between building it locally >> and installing from the public pkg repo. Poudriere does have the >> ability to install from pkgs, but there is a 2-year-old bug that >> prevents that feature from working correctly. >> >> I recommend everyone comment on issue #822 on the freebsd/poudriere >> github[1] and explain how much of a pain it is that poudriere doesn't >> have sane behaviour wrt dependencies. Maybe if enough people comment it >> will spur a fix. >> >> 1: https://github.com/freebsd/poudriere/issues/822 > > > IMHO the ports collection should provide and use prebuilt packages of > compilers (LLVM, GCC, Rust, etc.) built from the FreeBSD packages builder, > and ports framework (possibly also the base system) should be changed to > use prebuilt packages by default, unless a) user requested to build > everything from source, or b) no binary package is available for the > platform combination, like a Tier-2 platform. The source ports for > compilers should have all optimizations (like PGO, LTO, etc.) enabled by > default, and require reasonably modern (perhaps newer than Sandy Bridge) > processor features by default. > > It does not make sense for most users to build compilers from source all > the time, because most of them don't make any changes that would affect the > toolchain, which takes hours for them to build, even with beefy machines > and with parallelism and caching enabled. For these users, it's just a > waste of time and also increases their carbon footprint for nothing good. > > Cheers, Perhaps poudriere needs (or even already has?) a more fine-grained way to declare whether to fetch package dependencies. -b works - but will do that for every dependency, whereas I may only want it to fetch llvm and other expensive ports. The value to me in building from ports is that I know the state of my packages matches my ports tree. I’m not installing a package that was built a week ago. For expensive ports though, I’ll take the trade off of saving time in exchange for a bit of staleness. btw vanilla ports does have a mechanism for installing package dependencies, it’s `make install-missing-packages`. Pat
Re: lang/rust is super slow to buildZ
On Tue, 13 Dec 2022, Xin LI wrote: Using prebuilt binaries is not necessarily compromising security when done right. I think to ensure safety of these prebuilt binaries, we need to invest in e.g. making package builds reproducible (so an independent third party can audit and validate that the binaries are actually built from the source that they claimed to be when they want), ensure that the builders are safe, and sign the packages on the builders. Reproducable builds, a packaged base and paid staff to maintain the vuxml db (and perhaps support for containerd and wakeonlan) would go a _long_ way towards getting FreeBSD back onto the short list of popular server operating systems. Alas, none of these seems to be a priority for the Board. Roger Marquis
Re: How do I depend on a port regardless of its flavor?
Hello.
Mel Pilgrim wrote on 2022/12/12 02:52:
> But I need to also specify a version spec. However, if I do this:
> RUN_DEPENDS= foo>=1.2:devel/foo
> That only works if the default flavor is installed. If one of the
> non-default flavors is installed, the Ports System doesn't find it and tries
> to build the port. Similarly, pkg thinks I need to install the default
> flavor.
> The flavors aren't part of a framework like Python, so I don't have a set of
> variables I can use to construct a universal pkg name.
> How do I add a version-limited dependency on a flavored port?
Is this simply about the following?
RUN_DEPENDS= foo>=1.2:devel/foo@nondefaultflavor
The majority of the Python module is like this.
RUN_DEPENDS= ${PYTHON_PKGNAMEPREFIX}foo>0:category/py-foo@${PY_FLAVOR}
PYTHON_PKGNAMEPREFIX is linked to PY_FLAVOR.
It seems that python basically guarantees that only the default FLAVOR is used,
so it does not cause problems, but there are some FLAVORs that cause problems.
For example, if your port has:
RUN_DEPENDS= foo>=1.2:devel/foo \
llvm-devel-lite>0:devel/llvm-devel@lite
And, devel/foo has:
RUN_DEPENDS= llvm-devel>0:devel/llvm-devel@default
Since llvm-devel and llvm-devel-lite are CONFLICTS_INSTALL, they are not
considered to work well.
So I dislike non-python FLAVOR :) and I believe that if FLAVORS is to be used,
a dynamic method like python should be implemented.
Regards.
excessive port build time
Hi, It has just taken me several hours to build x11/nvidia-driver-470 To be fair, my zpool is over 90% and I was copying several GB of files as well during most of the build time. I only state what I saw so someone may think of a way to improve this. My installworld log shows >>> Installing everything completed on Wed Dec 14 12:48:49 ACDT 2022 The nvidia build finished at Wed 14 Dec 2022 15:42:43 ACDT from ps aux I saw these processes starting at 14:08 - sh -c (find -P /usr/lib\011 /usr/local/lib -type l -name libglx.\\* | xargs echo) 14:47 - sh -c (find /usr/lib\011 /usr/local/lib -name libGLX_nvidia.a\\* -or ... 15:34 - sh -c (find -P /usr/lib\011 /usr/local/lib -type l -name libglx.\\* | xargs echo) One thing of note, I have an excessive number of python ports installed, which appears to account for a large number of files to scan through find /usr/local/lib/python3.8 -type f | wc -l 149591 Maybe the lib search can be limited by depth or bypass folders such as pythonXX/site-packages -- FreeBSD - the place to B...Software Developing Shane Ambler
