Closed rdmark closed 1 year ago
Just for the sake of being more precise: This is not a backend issue but a Python client issue: scsictl and the PiSCSI Control app report the correct version, e.g.
>scsictl -s
piscsi server version: 22.12 (development version)
......
Doesn’t the C++ clients import the piscsi_version.h header directly and get the version data they display this way, rather than over the protobuf interface? I could be wrong since I haven’t looked closely at the code yet.
On Wed, Dec 7, 2022 at 1:31 AM Uwe Seimet @.***> wrote:
Just for the sake of being more precise: This is not a backend issue but a Python client issue: scsictl and the PiSCSI Control app report the correct version, e.g.
scsictl -s piscsi server version: 22.12 (development version) ......
— Reply to this email directly, view it on GitHub https://github.com/PiSCSI/piscsi/issues/1023#issuecomment-1340648576, or unsubscribe https://github.com/notifications/unsubscribe-auth/AAQCYMZFIO6FWBDXRXJEOADWMBKOHANCNFSM6AAAAAASWIXW34 . You are receiving this because you authored the thread.Message ID: @.***>
@rdmark piscsi is the server process, which includes piscsi_version.h. scsictl gets the piscsi server version (-s option) remotely via the remote interface. This version can differ from the scsictl version if piscsi/scsictl are from different releases. And the app has to use the remote interface anyway.
So when I started from scratch with a fresh clone of piscsi on the same system, the issue does not reproduce. So it seems to have to do with some residual data in that "converted" rascsi code.
I tested cloning a fresh 2022 Oct release, and then update to the latest develop. However the issue did not reproduce this way.
I would lean towards a Won't Fix for this, since it's happening only in my dirty dev clone.
The Python clients get 0 / 0 / 0 (major, minor and patch versions) back from the protobuf interface,
message PbVersionInfo
after the piscsi rebranding.