Re: dns/bind916 builds rust unexpectedly
On 25/09/23 23:58, Dan Mahoney wrote: On Sep 25, 2023, at 14:41, Robert Clausecker wrote: Am Mon, Sep 25, 2023 at 02:15:19PM -0700 schrieb Edward Sanford Sutton, III: Poudriere still causes crashes in my experience depending on hardware, poudriere configuration, and what you tell it to build; I have to change defaults to use it and then it is fine. With only 32GB of RAM, if I have it operate the whole build process in RAM (USE_TMPFS=all>/usr/local/etc/poudriere) then I have to limit myself to 2 build jobs (PARALLEL_JOBS=2, though I specify it on the poudriere command line) or I 'may' have issues. Within that I can have multiple jobs per build (ALLOW_MAKE_JOBS=yes>/usr/local/etc/poudriere, MAKE_JOBS_NUMBER=4>/usr/local/etc/poudriere.d/make.conf) which gets through each compile job much faster so no one job is as likely to be running 'alone' holding up other jobs while cores sit idle. Ports tend to eat more and more storage for their source and dependencies these days. I encountered the same issue you had. A simple fix is to switch to USE_TMPFS="data localbase" which keeps the source code and objects of the package to be built on disk while placing dependencies into RAM. This does not actually reduce performance by much as the biggest spike in disk usage is when dependencies are installed and the distfile is extracted. This setting helps with the former while not doing much to the latter. During the build, compilers infrequently write small objects to disk, which gets handled very well by the write cache, so having the WRKDIR on disk doesn't hurt. The cache also quickly picks up on frequently needed source files, so there's little penalty in having to read them from disk every once in a while. I really, really wish the ports tree supported the option of: "I am building package X, but it requires dependency A, B, and C, which I will build as completely standard, so pretty friggin please, just pkg install them." So often have I done the dance of "Make...crap, ^c^c^c, pkg install autoconf...Make, ...dammit... pkg install dialog4portsmakedammit, crap install bison" pkg, as far as I know, has no concept of tracking the build-dependencies of a thing, but I would love the option of pkg --install-all-build-deps-for foo. "Just run poudriere" is a really crappy option when you just have a single box on an AWS t2-tiny install. There is work in poudriere development to support using binary packages for dependencies. [1] Poudriere already has a -S flag to avoid rebuilding things when a run dependency changes. I see there is ongoing work related with this flag, but it should be usable most of the time, although it exposes to some of the same risks that building manually causes. [2] DISLAIMER: Everyone is free to manage his own machines as he sees fit, there is really no sanctioned way to do that, and building ports on live machines is supported, and I have fixed bugs in the ports I maintain that failed to build properly in such an environment, and will keep doing that to the best of my abilities. But I also must state that doing things like that is a way to look for unnecessary trouble. Poudriere is resource hungry, because building software is resource hungry and will get even hungrier. I started computing on a Spectrum 48K and am still baffled by how we got to a condition where 48K is not even enough for a simple configuration file, but here we are. [1] https://github.com/freebsd/poudriere/commit/a587ae7a3741d56a3991d030a8d08b6e9e619f07 [2] https://github.com/freebsd/poudriere/issues/806 -- Guido Falsi
Re: dns/bind916 builds rust unexpectedly
On 26/09/23 00:06, Dave Horsfall wrote: On Mon, 25 Sep 2023, Guido Falsi wrote: Anyway building from ports on live machines has always been bad practice for a lot of reasons. That's fine if you can afford a spare system just for building... Again, anyone can do things the way he prefer, but to do things properly there are minimum requirements, if you can't get those, you will have to accept compromises and the issues that come with those compromises. What you can't do is expect others to fix your own self imposed issues. -- Guido Falsi
Re: dns/bind916 builds rust unexpectedly
On 26/09/23 08:53, Helge Oldach wrote: Gareth de Vaux wrote on Mon, 25 Sep 2023 17:06:54 +0200 (CEST): Hi all, I've just upgraded bind916 which brought half my system down since it suddenly required a mountain of python packages and rust which needed around 13GB (and hours) to build - space which I didn't have nor have ever remotely expected to need for a ports build. My bind configuration options are basically the defaults: # grep OPTIONS_FILE_SET /var/db/ports/dns_bind916/options OPTIONS_FILE_SET+=IDN OPTIONS_FILE_SET+=JSON OPTIONS_FILE_SET+=LMDB OPTIONS_FILE_SET+=MANPAGES OPTIONS_FILE_SET+=TCP_FASTOPEN OPTIONS_FILE_SET+=GSSAPI_NONE OPTIONS_FILE_SET+=DLZ_FILESYSTEM These are the top level dependencies: # make -C /usr/ports/dns/bind916 build-depends-list /usr/ports/ports-mgmt/pkg /usr/ports/textproc/py-sphinx /usr/ports/devel/pkgconf /usr/ports/security/openssl /usr/ports/converters/libiconv /usr/ports/devel/libuv /usr/ports/textproc/libxml2 /usr/ports/dns/libidn2 /usr/ports/devel/json-c /usr/ports/databases/lmdb /usr/ports/devel/libedit Does anyone know which option/dependency is causing this? I suspect MANPAGES -> py-sphinx since it has 'py' but who knows. Which itself would be crazy that just a manpage would trigger this kind of intense build. Indeed, it's py-sphinx, requiring py-openssl at some stage, which is in turn requiring py-cryptography which needs rust. DEFAULT_VERSIONS+=pycryptography=legacy in make.conf fixed this BS for me. Beware of the dogs, you might get bitten by software that requires the new py-cryptography - I did stumble over py-certbot and py-awscli for example. py-cryptography was kept at an old version for a long time, for various reasons, the new mandatory dependency on rust being the main one. But that old version does not work with OpenSSL 3, so the update of OpenSSL in FreeBSD 14 imposed the update of py-cryptography. This is the perfect example of why I say: - there are external pressures we have little power on (keeping an old OpenSSL indefinitely is not an option) - keeping old version of software (to avoid heavy dependencies or whatever) is a landmine waiting to go off The problem showed up now because the landmine of keeping an old version of py-cryptography in the tree finally went off. I'm sure there are more similar landmines waiting to explode under our feet in the ports tree. -- Guido Falsi
Re: dns/bind916 builds rust unexpectedly
Hello.
It means that rust is so pervasive that rust builds are unavoidable :)
During the build of rust, we can take off and do some light exercise. That is
to avoid strained back :)
If you are using a combination of poudriere and portmaster and do not want to
build rust twice, the following spells it out.
sh -c 'pkg version -q -l \< | cut -f 1 -w | xargs -- pkg query %n:%n-%v | while
IFS=":'\$'{IFS}" read n nv ; do find /usr/local/poudriere/data/packages/ -regex
"\(^.*/\)*All/'\$'{n}-[^-/]*.pkg" -not -name "'\$'{nv}" ; done'
This allows us to collect the paths of packages that need updating and have
already been built by poudriere.
Then replace them with pkg delete and pkg add.
If autoremove needs to work effectively, a little more arrangement is required.
I will omit that :)
Regards.
Re: dns/bind916 builds rust unexpectedly
On 26/09/23 09:30, Tatsuki Makino wrote: Hello. It means that rust is so pervasive that rust builds are unavoidable :) Actually it's much worse than that. It's not only rust per se. My poudriere machine rarely can do a build run without rebuilding one or more of rust, some version of clang, some version of gcc, qt[56]-webengine, py-qt6 (this one does most of the work single threaded unluckily). Also it often ends up having to rebuild firefox and thinderbird (these two heavily use rust, and get little speed up from ccache), libreoffice (this one at least get a very strong speed up thanks to ccache) etc. I do not approve of this, but the world is going in that direction, especially for desktop oriented software but not only. My conclusion is, I have no power to stop this, so I can only adapt, with effort, but still less effort than resisting alone for no benefit. -- Guido Falsi
Re: dns/bind916 builds rust unexpectedly
Am 2023-09-26 09:44, schrieb Guido Falsi: My poudriere machine rarely can do a build run without rebuilding one or more of rust, some version of clang, some version of gcc, qt[56]-webengine, py-qt6 (this one does most of the work single threaded unluckily). Also it often ends up having to rebuild firefox and thinderbird (these two heavily use rust, and get little speed up from ccache), libreoffice (this one at least get a very strong speed up thanks to ccache) etc. ports-mgmt/sccache-overlay is supposed to handle rust with poudriere-devel. I haven't tried it yet, but it's on my list to try to get the rust build time down. Bye, Alexander. -- http://www.Leidinger.net alexan...@leidinger.net: PGP 0x8F31830F9F2772BF http://www.FreeBSD.orgnetch...@freebsd.org : PGP 0x8F31830F9F2772BF signature.asc Description: OpenPGP digital signature
Re: dns/bind916 builds rust unexpectedly
On 26/09/23 13:46, Alexander Leidinger wrote: Am 2023-09-26 09:44, schrieb Guido Falsi: My poudriere machine rarely can do a build run without rebuilding one or more of rust, some version of clang, some version of gcc, qt[56]-webengine, py-qt6 (this one does most of the work single threaded unluckily). Also it often ends up having to rebuild firefox and thinderbird (these two heavily use rust, and get little speed up from ccache), libreoffice (this one at least get a very strong speed up thanks to ccache) etc. ports-mgmt/sccache-overlay is supposed to handle rust with poudriere-devel. I haven't tried it yet, but it's on my list to try to get the rust build time down. Ah, thank you for the information. I did not notice this existed. I'll check on it! -- Guido Falsi
Re: dns/bind916 builds rust unexpectedly
Hi! > Am 2023-09-26 09:44, schrieb Guido Falsi: > > > My poudriere machine rarely can do a build run without rebuilding one > > or more of rust, some version of clang, some version of gcc, > > qt[56]-webengine, py-qt6 (this one does most of the work single > > threaded unluckily). Also it often ends up having to rebuild firefox > > and thinderbird (these two heavily use rust, and get little speed up > > from ccache), libreoffice (this one at least get a very strong speed > > up thanks to ccache) etc. > > ports-mgmt/sccache-overlay is supposed to handle rust with > poudriere-devel. I haven't tried it yet, but it's on my list to try to get > the rust build time down. sccache-overlay upstream is at 0.5.4, the port is at 0.2.15 -- do you know why it diverges that much ? -- p...@freebsd.org +49 171 3101372 Now what ?
Re: dns/bind916 builds rust unexpectedly
On Tue, 26 Sep 2023 14:03:28 +0200 Guido Falsi wrote: > On 26/09/23 13:46, Alexander Leidinger wrote: > > Am 2023-09-26 09:44, schrieb Guido Falsi: > > > >> My poudriere machine rarely can do a build run without rebuilding one > >> or more of rust, some version of clang, some version of gcc, > >> qt[56]-webengine, py-qt6 (this one does most of the work single > >> threaded unluckily). Also it often ends up having to rebuild firefox > >> and thinderbird (these two heavily use rust, and get little speed up > >> from ccache), libreoffice (this one at least get a very strong speed > >> up thanks to ccache) etc. > > > > ports-mgmt/sccache-overlay is supposed to handle rust with > > poudriere-devel. I haven't tried it yet, but it's on my list to try to > > get the rust build time down. > > > > Ah, thank you for the information. I did not notice this existed. I'll > check on it! > > -- > Guido Falsi IIRC, poudriere pulls it in on its first build for rust, before I've switched to -devel. Not sure it's actually used or not. But running rustc itself is very, very, very heavy job. It eats up all 6C12T even if only one rustc "process" is running, watching ps. Maybe it is multithreaded and attemps to use all core, including HTT ones, available. hurts severly with UI experience. This is why I try as much proposals as possible for scheduler. -- Tomoaki AOKI
sccache(-overlay) to speed up rust builds in poudriere (was: Re: dns/bind916 builds rust unexpectedly)
Am 2023-09-26 14:06, schrieb Kurt Jaeger: Hi! Am 2023-09-26 09:44, schrieb Guido Falsi: > My poudriere machine rarely can do a build run without rebuilding one > or more of rust, some version of clang, some version of gcc, > qt[56]-webengine, py-qt6 (this one does most of the work single > threaded unluckily). Also it often ends up having to rebuild firefox > and thinderbird (these two heavily use rust, and get little speed up > from ccache), libreoffice (this one at least get a very strong speed > up thanks to ccache) etc. ports-mgmt/sccache-overlay is supposed to handle rust with poudriere-devel. I haven't tried it yet, but it's on my list to try to get the rust build time down. sccache-overlay upstream is at 0.5.4, the port is at 0.2.15 -- do you know why it diverges that much ? devel/sccache is maintained by pizzamig@ (CCed) and at v0.5.4, whereas the ports-mgmt/sccache-overlay port is maintained by rust@ (CCed). Maybe they can shed some light on this... Bye, Alexander. -- http://www.Leidinger.net alexan...@leidinger.net: PGP 0x8F31830F9F2772BF http://www.FreeBSD.orgnetch...@freebsd.org : PGP 0x8F31830F9F2772BF signature.asc Description: OpenPGP digital signature
Re: dns/bind916 builds rust unexpectedly
On 9/25/23 13:21, George Mitchell wrote: > On 9/25/23 11:38, Guido Falsi wrote: >> [...] >> There is a more general aspect to this. In the rest of the unix world >> software is now almost universally build using CI systems and >> buildboxes, people use binary packages almost all the time in linux. >> Developers don't care to keep low overhead in their builds and with >> dependency. The ports tree cannot mitigate this external pressure. >> >> Anyway building from ports on live machines has always been bad >> practice for a lot of reasons. >> [...] > And yet it mostly works for some of us. I'd be overjoyed to sign up > with the program (using packages only) if packages not using CUPS > (that would run with unassisted lpr) were available, let's say as a > flavor. But until then ... -- George > The sudden appearance of a Rust requirement broke at least some CI systems: https://github.com/pyca/cryptography/issues/5771#issuecomment-774997087
Re: dns/bind916 builds rust unexpectedly
On 9/26/23 00:17, Guido Falsi wrote: > On 26/09/23 08:53, Helge Oldach wrote: >> Gareth de Vaux wrote on Mon, 25 Sep 2023 17:06:54 +0200 (CEST): >>> Hi all, I've just upgraded bind916 which brought half my system down >>> since >>> it suddenly required a mountain of python packages and rust which needed >>> around 13GB (and hours) to build - space which I didn't have nor have >>> ever >>> remotely expected to need for a ports build. >>> >>> My bind configuration options are basically the defaults: >>> >>> # grep OPTIONS_FILE_SET /var/db/ports/dns_bind916/options >>> OPTIONS_FILE_SET+=IDN >>> OPTIONS_FILE_SET+=JSON >>> OPTIONS_FILE_SET+=LMDB >>> OPTIONS_FILE_SET+=MANPAGES >>> OPTIONS_FILE_SET+=TCP_FASTOPEN >>> OPTIONS_FILE_SET+=GSSAPI_NONE >>> OPTIONS_FILE_SET+=DLZ_FILESYSTEM >>> >>> These are the top level dependencies: >>> >>> # make -C /usr/ports/dns/bind916 build-depends-list >>> /usr/ports/ports-mgmt/pkg >>> /usr/ports/textproc/py-sphinx >>> /usr/ports/devel/pkgconf >>> /usr/ports/security/openssl >>> /usr/ports/converters/libiconv >>> /usr/ports/devel/libuv >>> /usr/ports/textproc/libxml2 >>> /usr/ports/dns/libidn2 >>> /usr/ports/devel/json-c >>> /usr/ports/databases/lmdb >>> /usr/ports/devel/libedit >>> >>> Does anyone know which option/dependency is causing this? I suspect >>> MANPAGES -> py-sphinx since it has 'py' but who knows. Which itself >>> would >>> be crazy that just a manpage would trigger this kind of intense build. >>> >> >> Indeed, it's py-sphinx, requiring py-openssl at some stage, which is in >> turn requiring py-cryptography which needs rust. >> >> DEFAULT_VERSIONS+=pycryptography=legacy >> >> in make.conf fixed this BS for me. Beware of the dogs, you might get >> bitten by software that requires the new py-cryptography - I did stumble >> over py-certbot and py-awscli for example. > > py-cryptography was kept at an old version for a long time, for various > reasons, the new mandatory dependency on rust being the main one. > > But that old version does not work with OpenSSL 3, so the update of > OpenSSL in FreeBSD 14 imposed the update of py-cryptography. > And yet I remember a proposal that would have prevented this requirement on one of these lists. Separate base SSL from ports SSL. Force ports to use ports SSL and prune back base SSL to the bare minimum required for base. This would have given FreeBSD the freedom to try alternative things like LibreSSL. It was proposed when the "upgrade" to Openssl 3 delayed the release of 14. > This is the perfect example of why I say: > > - there are external pressures we have little power on (keeping an old > OpenSSL indefinitely is not an option) > - keeping old version of software (to avoid heavy dependencies or > whatever) is a landmine waiting to go off > > The problem showed up now because the landmine of keeping an old version > of py-cryptography in the tree finally went off. > > I'm sure there are more similar landmines waiting to explode under our > feet in the ports tree. > The problem with bending over backwards to accommodate a project that treats its users with contempt is that they'll overwhelm you eventually. I'm willing to bet the Python community is at least an order of magnitude larger than the FreeBSD community. The creeping Rustification of open source projects is marginalizing projects that are already marginal. The brunt of the damage caused by these capricious changes is borne by communities that are already small. Those communities have no chance to win if they fight back, but if they work to adapt to the changes the larger projects are imposing on them they only accelerate their demise and make hegemony more likely. The effort would be better spent in either exorcising the dependencies that are causing breakage, or fork the projects involved. Yes, these are work too, but there's a slim hope that if enough marginal communities do this, the large projects will feel back pressure and become more accommodating. Yes, it's a small chance. I know myself well enough in my advanced age to know I have a sometimes unhealthy instinct to swim against the current. Take the above with a grain of salt, but I suspect that if you're using FreeBSD we may share some of the same instinct. Thanks, Jose
Re: dns/bind916 builds rust unexpectedly
On 26/09/23 17:26, Jose Quinteiro wrote: On 9/25/23 13:21, George Mitchell wrote: On 9/25/23 11:38, Guido Falsi wrote: [...] There is a more general aspect to this. In the rest of the unix world software is now almost universally build using CI systems and buildboxes, people use binary packages almost all the time in linux. Developers don't care to keep low overhead in their builds and with dependency. The ports tree cannot mitigate this external pressure. Anyway building from ports on live machines has always been bad practice for a lot of reasons. [...] And yet it mostly works for some of us. I'd be overjoyed to sign up with the program (using packages only) if packages not using CUPS (that would run with unassisted lpr) were available, let's say as a flavor. But until then ... -- George The sudden appearance of a Rust requirement broke at least some CI systems: https://github.com/pyca/cryptography/issues/5771#issuecomment-774997087 For the record, the comment you're referencing (and so the breakage) was happening two years ago. We are being quite late at the party... -- Guido Falsi
Re: dns/bind916 builds rust unexpectedly
On 26/09/23 17:44, Jose Quinteiro wrote: On 9/26/23 00:17, Guido Falsi wrote: On 26/09/23 08:53, Helge Oldach wrote: Gareth de Vaux wrote on Mon, 25 Sep 2023 17:06:54 +0200 (CEST): Hi all, I've just upgraded bind916 which brought half my system down since it suddenly required a mountain of python packages and rust which needed around 13GB (and hours) to build - space which I didn't have nor have ever remotely expected to need for a ports build. My bind configuration options are basically the defaults: # grep OPTIONS_FILE_SET /var/db/ports/dns_bind916/options OPTIONS_FILE_SET+=IDN OPTIONS_FILE_SET+=JSON OPTIONS_FILE_SET+=LMDB OPTIONS_FILE_SET+=MANPAGES OPTIONS_FILE_SET+=TCP_FASTOPEN OPTIONS_FILE_SET+=GSSAPI_NONE OPTIONS_FILE_SET+=DLZ_FILESYSTEM These are the top level dependencies: # make -C /usr/ports/dns/bind916 build-depends-list /usr/ports/ports-mgmt/pkg /usr/ports/textproc/py-sphinx /usr/ports/devel/pkgconf /usr/ports/security/openssl /usr/ports/converters/libiconv /usr/ports/devel/libuv /usr/ports/textproc/libxml2 /usr/ports/dns/libidn2 /usr/ports/devel/json-c /usr/ports/databases/lmdb /usr/ports/devel/libedit Does anyone know which option/dependency is causing this? I suspect MANPAGES -> py-sphinx since it has 'py' but who knows. Which itself would be crazy that just a manpage would trigger this kind of intense build. Indeed, it's py-sphinx, requiring py-openssl at some stage, which is in turn requiring py-cryptography which needs rust. DEFAULT_VERSIONS+=pycryptography=legacy in make.conf fixed this BS for me. Beware of the dogs, you might get bitten by software that requires the new py-cryptography - I did stumble over py-certbot and py-awscli for example. py-cryptography was kept at an old version for a long time, for various reasons, the new mandatory dependency on rust being the main one. But that old version does not work with OpenSSL 3, so the update of OpenSSL in FreeBSD 14 imposed the update of py-cryptography. And yet I remember a proposal that would have prevented this requirement on one of these lists. Separate base SSL from ports SSL. Force ports to use ports SSL and prune back base SSL to the bare minimum required for base. This would have given FreeBSD the freedom to try alternative things like LibreSSL. It was proposed when the "upgrade" to Openssl 3 delayed the release of 14. Great idea, we now only need to see the patches to base and ports allowing this to happen. Test them, commit them... 14.0 has already been delayed long enough. This is the perfect example of why I say: - there are external pressures we have little power on (keeping an old OpenSSL indefinitely is not an option) - keeping old version of software (to avoid heavy dependencies or whatever) is a landmine waiting to go off The problem showed up now because the landmine of keeping an old version of py-cryptography in the tree finally went off. I'm sure there are more similar landmines waiting to explode under our feet in the ports tree. The problem with bending over backwards to accommodate a project that treats its users with contempt is that they'll overwhelm you eventually. I'm willing to bet the Python community is at least an order of magnitude larger than the FreeBSD community. Not sure what project you are talking about. Rust is just s programming language. I am neutral towards rust itself, although slightly annoyed by the time it takes to build it (on the other hand rust is not slow at building things, but most projects compiled in rust are big ones and would take long with any language compiler). That said what is the alternative? (shipping old software or custom versions stripped of rust when we do not have the manpower to actually maintain forks is not really an option) The creeping Rustification of open source projects is marginalizing projects that are already marginal. The brunt of the damage caused by these capricious changes is borne by communities that are already small. Those communities have no chance to win if they fight back, but if they work to adapt to the changes the larger projects are imposing on them they only accelerate their demise and make hegemony more likely. The effort would be better spent in either exorcising the dependencies that are causing breakage, or fork the projects involved. Yes, these are work too, but there's a slim hope that if enough marginal communities do this, the large projects will feel back pressure and become more accommodating. Yes, it's a small chance. I know myself well enough in my advanced age to know I have a sometimes unhealthy instinct to swim against the current. Take the above with a grain of salt, but I suspect that if you're using FreeBSD we may share some of the same instinct. I used to have that kind of instinct when I was much younger. The instinct is partly there still, but I have learned to evaluate if I am fighting a current I can manage, or a stronger one that will swipe me away anyway. Y
Re: dns/bind916 builds rust unexpectedly
Le mar. 26 sept. 23 à 9:44:51 +0200, Guido Falsi écrivait : > Actually it's much worse than that. It's not only rust per se. > > My poudriere machine rarely can do a build run without rebuilding one or > more of rust, some version of clang, some version of gcc, qt[56]-webengine, > py-qt6 (this one does most of the work single threaded unluckily). Also it > often ends up having to rebuild firefox and thinderbird (these two heavily > use rust, and get little speed up from ccache), libreoffice (this one at > least get a very strong speed up thanks to ccache) etc. This is true, but rust is very heavy, and it seems to be updated quiet frequently. Just an idea: maybe it could be possible to repocopy lang/rust to e.g. lang/rust-devel (we already have rust-nightly), lang/rust being a stable release, used to compile the depending ports, and rust-devel being used by rust developers and updated more frequently. I do not know if these ports would be installed at the same place, with CONFLICTS_INSTALL, or if would be better to install the -devel port with some suffix… [r...@freebsd.org added to Cc:] -- Th. Thomas. signature.asc Description: PGP signature
Re: dns/bind916 builds rust unexpectedly
On Tue, 26 Sep 2023 22:03:18 +0200 Thierry Thomas wrote: > Le mar. 26 sept. 23 à 9:44:51 +0200, Guido Falsi > écrivait : > > > Actually it's much worse than that. It's not only rust per se. > > > > My poudriere machine rarely can do a build run without rebuilding one or > > more of rust, some version of clang, some version of gcc, qt[56]-webengine, > > py-qt6 (this one does most of the work single threaded unluckily). Also it > > often ends up having to rebuild firefox and thinderbird (these two heavily > > use rust, and get little speed up from ccache), libreoffice (this one at > > least get a very strong speed up thanks to ccache) etc. > > This is true, but rust is very heavy, and it seems to be updated quiet > frequently. > > Just an idea: maybe it could be possible to repocopy lang/rust to e.g. > lang/rust-devel (we already have rust-nightly), lang/rust being a stable > release, used to compile the depending ports, and rust-devel being used > by rust developers and updated more frequently. > > I do not know if these ports would be installed at the same place, with > CONFLICTS_INSTALL, or if would be better to install the -devel port > with some suffix? [r...@freebsd.org added to Cc:] > -- > Th. Thomas. There is lang/rust-nightly [1] [2], which may be the -devel version. IIRC, this is not so frequently updated. currently, the latest update was to 1.72.0.20230612 at Jun.20, 2023, while lang/rust 1.72.0 landed at Sep.08, 2023. The problem, I think, is that all BUILD_DEPEND'ed ports are basically bumped when lang/rust is updated. I'm not at all a rust developer nor porter, but if possible, files causing the rebuild (would be statically linked files like crt0.o in C) would be better splitted into individual port(s) and updated only when its source code is updated (and, if applicable, the behaviour of resulting binary is ACTUALLY changed WITH BACKWARD-INCOMPATIBLE WAY by rust code generator or optimizer) and all rust[-nightly] consumers LIB_DEPEND to them. [1] https://cgit.freebsd.org/ports/tree/lang/rust-nightly [2] https://www.freshports.org/lang/rust-nightly/ -- Tomoaki AOKI
Re: dns/bind916 builds rust unexpectedly
On Mon, 25 Sep 2023, Roger Marquis wrote: > Or $5/mo for a Digitalocean VM. They host spammers, so I cannot use them (the Boulder Pledge etc); there are probably other VMs around, should I feel the need. On Tue, 26 Sep 2023, Guido Falsi wrote: > > That's fine if you can afford a spare system just for building... > > Again, anyone can do things the way he prefer, but to do things properly > there are minimum requirements, if you can't get those, you will have to > accept compromises and the issues that come with those compromises. > > What you can't do is expect others to fix your own self imposed issues. That was an observation, not a complaint; are you always this narky? No wonder I'm starting to favour the Mac... -- Dave
Re: dns/bind916 builds rust unexpectedly
On 9/25/23 9:24 PM, Roger Marquis wrote: Or $5/mo for a Digitalocean VM. They dropped FreeBSD support last year. (And simultaneously raised their prices.)
Re: dns/bind916 builds rust unexpectedly
Hi all, > Am 27.09.2023 um 00:41 schrieb Mike Andrews : > > On 9/25/23 9:24 PM, Roger Marquis wrote: > >> Or $5/mo for a Digitalocean VM. > > > They dropped FreeBSD support last year. (And simultaneously raised their > prices.) That's why I am on Vultr, now. Kind regards, Patrick
Re: dns/bind916 builds rust unexpectedly
On 9/26/23 09:14, Guido Falsi wrote: (snip) >> >> And yet I remember a proposal that would have prevented this requirement >> on one of these lists. Separate base SSL from ports SSL. Force ports to >> use ports SSL and prune back base SSL to the bare minimum required for >> base. This would have given FreeBSD the freedom to try alternative >> things like LibreSSL. It was proposed when the "upgrade" to Openssl 3 >> delayed the release of 14. > > Great idea, we now only need to see the patches to base and ports > allowing this to happen. Test them, commit them... > This was not my idea, it was presented by a member of the Core Team.(1) > 14.0 has already been delayed long enough. > I do not question the decision to "upgrade" OpenSSL instead. I have put in neither the time nor the effort to have an educated opinion on this. >> >>> This is the perfect example of why I say: >>> >>> - there are external pressures we have little power on (keeping an old >>> OpenSSL indefinitely is not an option) >>> - keeping old version of software (to avoid heavy dependencies or >>> whatever) is a landmine waiting to go off >>> >>> The problem showed up now because the landmine of keeping an old version >>> of py-cryptography in the tree finally went off. >>> >>> I'm sure there are more similar landmines waiting to explode under our >>> feet in the ports tree. >>> >> >> The problem with bending over backwards to accommodate a project that >> treats its users with contempt is that they'll overwhelm you eventually. >> I'm willing to bet the Python community is at least an order of >> magnitude larger than the FreeBSD community. >> > > Not sure what project you are talking about. Rust is just s programming > language. > I beg to differ. It's a large runtime that changes quickly, a package manager and build tool that create enormous binaries from even tiny pieces of code, and the answer to all your problems, according to some. In any case, I was talking about py-cryptography in particular, and Python in general. > I am neutral towards rust itself, although slightly annoyed by the time > it takes to build it (on the other hand rust is not slow at building > things, but most projects compiled in rust are big ones and would take > long with any language compiler). > I was neutral until it started consuming more and more time and resources on my Poudriere builds, and until I tried to write a simple program to query a Mysql database. I'm also wary of the fact that it appears to have tied us to the FreeBSD 11 ABI forever(2). > That said what is the alternative? > Why do I need an alternative? >> The creeping Rustification of open source projects is marginalizing >> projects that are already marginal. The brunt of the damage caused by >> these capricious changes is borne by communities that are already small. >> Those communities have no chance to win if they fight back, but if they >> work to adapt to the changes the larger projects are imposing on them >> they only accelerate their demise and make hegemony more likely. >> >> The effort would be better spent in either exorcising the dependencies >> that are causing breakage, or fork the projects involved. Yes, these are >> work too, but there's a slim hope that if enough marginal communities do >> this, the large projects will feel back pressure and become more >> accommodating. Yes, it's a small chance. >> >> I know myself well enough in my advanced age to know I have a sometimes >> unhealthy instinct to swim against the current. Take the above with a >> grain of salt, but I suspect that if you're using FreeBSD we may share >> some of the same instinct. > > I used to have that kind of instinct when I was much younger. The > instinct is partly there still, but I have learned to evaluate if I am > fighting a current I can manage, or a stronger one that will swipe me > away anyway. > > You say we "bend" to rustification, but the way you suggest means ports > should bend to anti rustification, by removing features causing rust > dependencies, pinning software to old versions, and so on. This would > make the ports tree less useful for a lot of users. We would end up with > old packages. Not something we can force on all the user base. > > On the other hand you suggest forking projects, but we barely have > manpower to keep the ports updated as is. Let alone actually develop the > ported software. > > Anyway forking can be done outside of the ports tree. Nothing stops you > from forking, say, librsvg and keep your fork updated and at feature > parity with the rust version. > > If this is your battle you can fight it outside of the ports tree. > I never suggested doing this in the ports tree? The only change I mentioned was to base, and that was not my idea as I pointed out above. > > I'd add that the "ports" tree is just that "ports" not the place for > forking or original development; we port what outside projects deliver > with as little judgment as possible, for the
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 +-+ cad/ifcopenshell| 0.6.0 | blenderbim-230927 +-+ devel/py-archinfo | 9.0.5405| v9.2.70 +-+ devel/py-cle| 9.0.5405| v9.2.70 +-+ games/retroarch | 1.10.3 | v1.16.0.1 +-+ math/py-claripy | 9.0.5405| v9.2.70 +-+ security/py-angr| 9.0.5405| v9.2.70 +-+ security/py-pyvex | 9.0.5405| v9.2.70 +-+ sysutils/rshim-user-space | 2.0.9 | rshim-2.0.11 +-+ www/p5-RT-Extension-RepeatTicket| 1.11| 2.02 +-+ www/py-aiostream| 0.4.5 | 0.5.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!
