git sha of ports tree used to build packages from
hi, is there any way to know what commit was used from the ports tree, as the base for the package builders? If not, can this be exposed somehow, maybe in something like meta.conf ? $ curl http://pkg.freebsd.org/FreeBSD:14:amd64/latest/meta.conf version = 2; packing_format = "txz"; manifests = "packagesite.yaml"; filesite = "filesite.yaml"; manifests_archive = "packagesite"; filesite_archive = "filesite"; I could use this commit to ensure my local poudriere ports branch isn't ahead of what is pre-built on the official mirrors, and only rebase up to what's there. This would be a huge help in avoiding needless local poudriere rebuilds when my ports tree is ahead of whatever the builders have done. Nothing like watching cmake* openjdk* llvm* rust* etc starting up when all you really needed was some trivial leaf package. A+ Dave
OpenSSL 3.0 in the base system update
As previously mentioned[1] FreeBSD 14.0 will include OpenSSL 3.0. We expect to merge the update to main in the near future (within the next week or two) and are ready for wider testing. Supported by the FreeBSD Foundation, Pierre Pronchery has been working on the update in the src tree, with assistance from Enji Cooper (ngie@), and me (emaste@). Thanks to Antoine Brodin (antoine@) and Muhammad Moinur Rahman (bofh@) for ports exp-runs and fixes/workarounds and to Dag-Erling (des@) for updating ldns in the base system. ## Base system compatibility status Most of the base system is ready for a seamless switch to OpenSSL 3.0. For several components we've added `-DOPENSSL_API_COMPAT=0x1010L` to CFLAGS to specify the API version, which avoids deprecation warnings from OpenSSL 3.0. Changes have also been made to avoid OpenSSL APIs already deprecated in OpenSSL 1.1. We can continue the process of updating to contemporary APIs after OpenSSL 3.0 is in the tree. Additional changes are still required for libarchive and seven Kerberos-related libraries or tools. Workarounds are ready to go along with the OpenSSL 3 import, and proper fixes are in progress in the upstream projects. A segfault from `openssl x509` in the i386 ports exp-run is under investigation and needs to be addressed prior to the merge. ## Ports compatibility With bofh@'s recent www/node18 and www/node20 patches the ports tree is in reasonable shape for OpenSSL 3.0 in the base system. The exp-run (link below) has a list of the failing ports, and I've emailed all of the maintainers as a heads-up. None of the remaining failures are responsible for a large number of skipped ports (i.e., the failures are either leaf ports or are responsible for only a small number of skipped ports). I expect that some or many of these will need to be addressed after the change lands in the src tree. ## Call for testing We welcome feedback from anyone willing to test the work in progress. Pierre's update can be obtained from the pull request[2] or by fetching the branch[3]. If desired I will provide a large diff against main. ## Links - Base system OpenSSL 3.0 update tracking PR: https://bugs.freebsd.org/271615 - Ports exp-run with OpenSSL 3.0 in the base system: https://bugs.freebsd.org/271656 [1] https://lists.freebsd.org/archives/freebsd-current/2023-May/003609.html [2] https://github.com/freebsd/freebsd-src/pull/760 [3] https://github.com/khorben/freebsd-src/tree/khorben/openssl-3.0.9
Re: git sha of ports tree used to build packages from
Hello. Someone said something similar to that. :) -> https://lists.freebsd.org/archives/freebsd-ports/2023-January/003292.html It seems that the package download feature of poudriere-devel has to keep pace with the official builder. Perhaps when updates are made to chromium, etc., the official will be delayed somewhat? One of the reasons poudriere picks and chooses which packages to rebuild is that it cannot find the resulting package displayed by the following command. pkg query -F /usr/local/poudriere/data/packages/jail-porttree/All/rust-1.69.0_2.pkg %dn-%dv If rust is to use curl only for runtime linking, dynamic loading, or piping by executing commands, there would be little need to rebuild the entire rust. Therefore, if only the discrepancy in the rust package is rewritten, packages can be built without any problems :) Regards. Dave Cottlehuber wrote on 2023/06/09 00:58: > > This would be a huge help in avoiding needless local poudriere rebuilds > when my ports tree is ahead of whatever the builders have done. Nothing > like watching cmake* openjdk* llvm* rust* etc starting up when all you > really needed was some trivial leaf package.
Re: OpenSSL 3.0 in the base system update
09.06.2023 0:13, Ed Maste wrote: [skip] > We welcome feedback from anyone willing to test the work in progress. Is it possible to grab some binary snapshot of 14-CURRENT to install into a VM and test my port that fails build? If not, how do I build 14-CURRENT with OpenSSL 3.0 myself? Eugene
Re: OpenSSL 3.0 in the base system update
Dear Ed, Am 08.06.2023 um 20:13 schrieb Ed Maste: Most of the base system is ready for a seamless switch to OpenSSL 3.0. For several components we've added `-DOPENSSL_API_COMPAT=0x1010L` to CFLAGS to specify the API version, which avoids deprecation warnings from OpenSSL 3.0. Changes have also been made to avoid OpenSSL APIs already deprecated in OpenSSL 1.1. We can continue the process of updating to contemporary APIs after OpenSSL 3.0 is in the tree. at first thanks a lot to take care of it. I only want to ask a question: Regarding my information openssl 3.0 has a major performance problem compared to 1.1. I have this information only from the haproxy mailing list, where many users downgraded from 3.0 to 1.1 as they were not able to handle the traffic anymore with the same hardware. Maybe talk to the developers of haproxy, they have a very deep knowledge of openssl. OpenSSL 3.1 should be better, but what I read on the haproxy mailing list does not reaching the performance of 1.1. (I do not have the technical background, but I only wanted to ask that you are aware of this issue) Gruß Matthias -- "Programming today is a race between software engineers striving to build bigger and better idiot-proof programs, and the universe trying to produce bigger and better idiots. So far, the universe is winning." -- Rich Cook
