The binary package of lsof when installed on a binary updated FreeBSD 11.1-p6 system (userland 11.1-p4) erroniously compares 11.1-p4 to 11.1-p6 and gives the user a warning.
This is cause by a bad compiled in constant of 11.1-p6 is LSOF_VSTR,
the compiled in constant is obtained from uname -r in the file
Configure, I suggest changing this to uname -K -r.
This is by design. There might be kernel changes that would cause issues with lsof.
This is NOT by design, this is by not understanding that when users update there 11.1 system they end up with a user land of 11.1-p4 and a kernel of 11.1-p6 and when you build a binary package of lsof on the cluster it compiles in the wrong constant to compare!
lsof is sensitive to the KERNEL version.
And there is NO SUCK KERNEL as 11.1-p6 DO NOT CLOSE THIS AGAIN.
please show me a uname -r and the exact error messages.
And are you complaining about a package built on the cluster or hand built?
This is in regard to the packages built on the cluster and being installed on to an 11.1 system that has had binary updated.
No, I dont have any of the uname -r output anymore as I was helping someone with this issue in IRC.
I HAVE however looked at the port and src's enough to know that the way things are being built the code end up comparing the wrong two strings.
It is comparing the -U string to the -K string and failing, what appears to be due to the use of just "uname -r" in the Configure script. If you replace that with "uname -K -r" it should fix it, and as you say it depends on the kernel version so we should STOP comparing userland version.
Ok, I'm spinning up a 11.1-REL VM, and will look.
I think the issue is that the build cluster jail lies on the uname -r, since a binary updated system shows 11.1-RELEASE-p4 on uname -r.
Why does the build cluster give a different answer than a system doing binary upgrades?
I spun up a 11.1-RELEASE VM, freebsd-updated to -p6, and then built lsof on that machine and:
# freebsd-version -u
# freebsd-version -k
To my mind, if the build cluster is using the RELENG/11.1 source tree, it should set UNAME_R to 11.1-RELEASE-p4
I don't think this is an lsof port issue.
clusteradm, what say you?
(In reply to Larry Rosenman from comment #9)
I think installing the lsof pkg at this point rather than building it
from code would show you the error the end user is getting.
Perhaps your right in the cluster is building things with a
modified uname string, but why would its kernel report -p6
as there is no such kernel....
Thank you for sticking with me on this...
it does. I think the build cluster(s) do the builds in a jail with a UNAME_R variable set in the environment.
Hence, getting clusteradm@ involved (or should it be portmgr?)
Minor correction, the environment variable would be UNAME_r. per uname(3) man page.
AFAIK, in general the clusters build all packages on a 12 box. It has no way of knowing what the kernel version is, as poudriere jails don't fetch or extract the kernel. In standard poudriere jails, "freebsd-version -k" produces an error about a missing kernel.
The best guess it can make is that kernel = host.
After an email exchange with adamw@, I've added a pkg-message to the sysutils/lsof port about this possibility.
A commit references this bug:
Date: Sat Feb 17 18:51:17 UTC 2018
New revision: 462185
Add a pkg-message about pre-built binaries and kernels.
Reviewed by: adamw
This seems to miss the point.
Maybe it makes more sense to use uname -K, since that is the ABI version, and should change if the ABI changes. Or truncate the patch level off of the version string, since the ABI shouldn't change between 11.1-p4 and 11.1-p6.
It's the KBI, and source changes HAVE broken it before.
I don't want to change the upstream check.
(In reply to Allan Jude from comment #17)
In a poudriere jail, uname -K will report the version of the host kernel. AFAIK, packages are built on -CURRENT hosts, so this check will always be wrong.
(In reply to Allan Jude from comment #17)
Shouldn't, but occasionally it does. It's better to have a warning message that things may be wrong than to have it actually be wrong with no warning.
uname -K is wrong in poudriere jails (it reports on the host kernel), and freebsd-version -k doesn't work at all in poudriere jails (there's no kernel installed in the jail).
AFAIK, there's no way to actually get this right. A pkg-message explaining the message is probably as universal as the solution can get. From my perspective, this can be closed.
closing per adamw@
Really? Closed 3 times without a resolution?
I'll take this, and get to the bottom of it.
I do not find false warnings that lead users a stray a good idea.
I also finding it appauling that the port built from src is fine,
but a pkg installed at the correct version is not. This indicates
a reproducability issue at minimum.
Please do *NOT* change sysutils/lsof without my *EXPLICIT* approval.
(In reply to Adam Weinberger from comment #19)
I do not believe that packages are always built on current hosts, my understanding is that they are built on the oldest release of the supported branch, aka 11.x ports are built on an 11.1 system.
If that is not the case then the build environment needs enhanced so that both a UNAME_r and UNAME_K_r exist, the right things just happen.
(In reply to Larry Rosenman from comment #18)
I agree, there should not be a change to upstream, other than possibly in the FreeBSD specific portion of Configure where it deals with creating the LSOF_VSTR, but as you point out, this code does infact "DTRT" when compiled on an actual 11.1-p6 box, so this leads to the build environment is where the fix needs to be.
Larry, your marked as MAINTAINER in the Makefile, of cource I would seek your approval before any commit.
Glen, I am adding you to this so you can confirm, deny, clarify, or expand on where and in what environment the packages for FreeBSD 11.1-p6 are built?
Portmgr: Comments, please.
(In reply to Rodney W. Grimes from comment #24)
I believe packages are always built on a host running -current, but in a jail that has the oldest supported stable release of the branch in question installed. So the userland it is linking against is 11.x, the running kernel is 12-current. The environment is modified to trick the compilation process. It may be possible that one such environment variable is missing.
I think the source of the problem is likely that the 'version' reported via poudriere to the compilation process is that of the userland version, since there is no kernel, so in the slightly off freebsd-update case where you have a -p6 userland, but only a -p4 kernel because the kernel has not changed in -p5 or -p6, a freshly built package will produce the warning.
This is an artifact of how poudriere builds things. It gets the version from the jail, which is 11.1-p6, and decides that it is what the version is.
Reading all the comments quickly, this was explained in comments 14, 20, 26.
This was already closed three times, so let's close it again.