Details
- Reviewers
pjfloyd_wanadoo.fr tcberner - Group Reviewers
portmgr - Commits
- R11:6eed0ced5ace: devel/valgrind: temporary build fix for FreeBSD 15.
Diff Detail
- Repository
- R11 FreeBSD ports repository
- Lint
Lint Not Applicable - Unit
Tests Not Applicable
Event Timeline
Whilst that should work my plans were to do the following
Leave devel/valgrind alone until Valgrind 3.22 is released in a couple of months
When I have VMs to test on FreeBSD 15 make the fixes upstream and bump the version of devel/valgrind-devel.
How many failures are there with "gmake regtest" ?
Why would you intentionally leave the port broken for months when a simple fix exists?
FreeBSD 15.0 isn't even available for download yet.
I don't consider a quick hack to the configure script to be a fix.
It's not a hack. Right now FreeBSD 15 is essentially identical to FreeBSD 14 except for the version number.
FreeBSD 15.0 isn't even available for download yet.
Snapshots will start being available soon, and a decent fraction of the FreeBSD developer community is already running 15 or will be shortly.
It's not a hack. Right now FreeBSD 15 is essentially identical to FreeBSD 14 except for the version number.
Really? Have you run the regression suite as I asked? There's a lot of platform specific code in Valgrind. It should work OK but I've seen cases that were wrong in the past and needed updating after a version upgrade.
Valgrind doesn't support FreeBSD 14 well just yet. I've made some improvements since the alpha cycle started.
I don't subscibe to the view "if it builds, ship it".
I'm planning on setting up FreeBSD 15 VMs for amd64 and i386 as soon as downloads are available.
As I said
When I have VMs to test on FreeBSD 15 make the fixes upstream and bump the version of devel/valgrind-devel.
The rhetorical question was referring to your assertation that just fixing the build is not a hack.
You can easily upgrade a FreeBSD 14 VM to FreeBSD 15. Or you can take my word, as a FreeBSD developer, that this patch is fine.
Right now if you really need to use Valgrind on FreeBSD 15 the best thing to do would be
- clone the Valgrind git source, see instructions here https://valgrind.org/downloads/repository.html
- apply the patch provided here to configure.ac
- follow the instructions to build and install
which will be essentially the same as what I'm planning for devel/valgrind-devel with the exception that it will be untested
My goal is not to use Valgrind, my goal is to fix a broken port. At the moment, this patch is all that is needed to make devel/valgrind build and run no better or worse on FreeBSD 15 than on FreeBSD 14.
I'm not in the habit of doing that and I expect that it would be rather long on my old workstation.
Or you can take my word, as a FreeBSD developer, that this patch is fine.
I wonder how that makes you feel qualified to judge a patch for Valgrind?
Now this is getting annoying.
You presume that it will be no worse WHEN NOBODY HAS EVEN RUN THE VALGRIND TEST SUITE.
FreeBSD 14 and 15 are essentially identical. We just bumped the version number last week. The test suite produces the exact same result on both:
== 813 tests, 477 stderr failures, 83 stdout failures, 11 stderrB failures, 17 stdoutB failures, 37 post failures ==
I suggest you reevaluate your attitude.
You're doing something badly wrong if you're getting 477 stderr failures.
Did you read README.freebsd and install gsed and gdb as it says in the "Running regression tests" section?
On 13.2 I usually get zero regtest failures, on 14.0 I would expect somewhere between 5 and 10 failures.
Moin moin
portmgr values the idea of upstream CI. But given the recent branching of 14 from CURRENT, this looks like a safe enough change, to go forward under the "just fix it " blanket.
mfg Tobias/portmgr
Being the port maintainer means the same everywhere, let me quote the Porter's Handbook for you:
A maintainer volunteers to keep a port in good working order. Maintainers have the primary responsibility for their ports, but not exclusive ownership. Ports exist for the benefit of the community and, in reality, belong to the community. What this means is that people other than the maintainer can make changes to a port. Large changes to the Ports Collection might require changes to many ports. The FreeBSD Ports Management Team or members of other teams might modify ports to fix dependency issues or other problems, like a version bump for a shared library update.