make package on Solaris (omnios) should match strings in version.h
This is mostly a cosmetic issue, I think. Did a checkout of 18.6.2 and setup to build
make package generated: OpenSSH-OpenSSH_8.7p1-hpn15v4-Solaris-i386.pkg
when version.h shows:
#define SSH_VERSION "OpenSSH_9.9"
#define SSH_PORTABLE "p2"
#define SSH_HPN "_hpn18.6.1"
#define SSH_RELEASE SSH_VERSION SSH_PORTABLE SSH_HPN
Shouldn't the package name match the version string(s)?
That's odd. Can you tell me your exact steps starting from cloning the repo?
I cloned the repo long ago, and normally do a pull/checkout tag/autoreconf and then configure. Its been some time since I last built a Solaris package, so maybe I need to be doing something else.....
I noticed that you didn't list make clean and/or git clean -ix. Perhaps your build reused an old version of an intermediate file? If so, there might be dependency missing from the Makefile.
I asked about the process because I don't know how you are building a Solaris package from the repo. There are spec files for redhat and suse and there is the buildpkg.sh file. Unfortunately I don't know much about those as we inherit those from OpenSSH and I haven't explored those much.
My previous theory (missing dependency in the Makefile) looks to be incorrect.
New theory:
The make package command runs buildpkg.sh (from buildpkg.sh.in). The package filename includes a variable, $VERSION, which is set by VERSION=`./ssh -V 2>&1 | sed -e 's/,.*//'` , which is a problem because our binary is named hpnssh, not ssh. If you previously compiled hpn15v4 (which is from before we renamed the binaries), then it would grab the wrong version info by running that old binary. The hpn15v4 release was only one or two releases before the one where we renamed the binaries, so it makes sense that a leftover ssh binary could be that version.
If correct, then running make clean would not have helped. I think the bug is in buildpkg.sh.in: we need to use the new binary names there. My other previous suggestion, git clean -ix, also wouldn't have resulted in a correct package, but it probably would have complained about not finding ./ssh.
@panachoi , I don't know whether your resulting file OpenSSH-OpenSSH_8.7p1-hpn15v4-Solaris-i386.pkg would contain the new binaries (e.g., hpnssh) or the old binaries (e.g., ssh). I recommend rebuilding it from a clean git clone of the sources, just to be safe.
Ah, that's a good catch. I think that will resolve the problem and will add it to the list for the next release.
My previous theory (missing dependency in the Makefile) looks to be incorrect.
New theory:
The
make packagecommand runsbuildpkg.sh(frombuildpkg.sh.in). The package filename includes a variable,$VERSION, which is set byVERSION=`./ssh -V 2>&1 | sed -e 's/,.*//'`, which is a problem because our binary is namedhpnssh, notssh. If you previously compiled hpn15v4 (which is from before we renamed the binaries), then it would grab the wrong version info by running that old binary. The hpn15v4 release was only one or two releases before the one where we renamed the binaries, so it makes sense that a leftoversshbinary could be that version.
Indeed, this is the case. There was an old ssh version: -rwxr-xr-x 1 root root 3415512 Sep 14 2021 ssh
Oddly enough it reports this: OpenSSH_8.7p1-hpn15v4, OpenSSL 1.1.1w 11 Sep 2023
Which of course matches my package name, so that fits. Of course, since the binary name has now changed, a make clean wont help (it might have if I was judiciously rebuilding all the time, which then would have removed the offending file before the binaries were renamed).
But, now there seems to be something else amiss. After a completely fresh checkout/autoreconf//configure, the package fails to build with this:
## Validating control scripts.
## Packaging complete.
pkgtrans: ERROR: no package associated with <line>
pkgtrans: ERROR: unable to complete package transfer
- no packages were selected from </tmp/openssh-portable/pkg>
So I'm only slightly better off.
I'm so sorry that I've been out of touch on this. These past few months have been hectic. Where do things stand on your end with this issue?
I'm goign to close this as I haven't heard back. Feel free to reopen if you need to.