Bug 237075 - devel/qt5-core: QSysInfo::productVersion() returns "unknown"
Summary: devel/qt5-core: QSysInfo::productVersion() returns "unknown"
Status: Closed FIXED
Alias: None
Product: Ports & Packages
Classification: Unclassified
Component: Individual Port(s) (show other bugs)
Version: Latest
Hardware: Any Any
: Normal Affects Many People
Assignee: kde
URL: https://reviews.freebsd.org/D19866
Keywords:
Depends on:
Blocks:
 
Reported: 2019-04-07 16:20 UTC by Alexey Dokuchaev
Modified: 2019-05-01 09:22 UTC (History)
2 users (show)

See Also:
tcberner: maintainer-feedback+


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Alexey Dokuchaev freebsd_committer 2019-04-07 16:20:58 UTC
In our Qt5 build, QSysInfo::productVersion() returns "unknown" string for FreeBSD version, instead of expected "13.0-CURRENT" (for example).  The following little program demonstrates this:

> $ cat pv.cc
> #include <QString>
> #include <QSysInfo>
> 
> int main()
> {
>     QString pv = QSysInfo::productVersion();
> 
>     fprintf(stderr, "%s\n", pv.toLocal8Bit().constData());
> }
> $ c++ pv.cc -I/usr/local/include/qt5/QtCore -I/usr/local/include/qt5 -fPIC \
> -L/usr/local/lib/qt5 -lQt5Core
> $ ./a.out
> unknown
The same program built on Fedora release 26 (Twenty Six) returns more or less correct "26".
Comment 1 Tobias C. Berner freebsd_committer 2019-04-07 16:42:31 UTC
Moin moin

We could either provide an [1] /etc/os-release file for Qt (and also other software) to read from, or patch the support in. The os-release file would be "nicer", in a way.


mfg Tobias

[1] https://www.freedesktop.org/software/systemd/man/os-release.html
Comment 2 Tobias C. Berner freebsd_committer 2019-04-07 16:49:34 UTC
FreeBSD could for example install a file like this

NAME=FreeBSD
VERSION="13.0-CURRENT"
ID=FreeBSD
VERSION_ID=13.0
PRETTY_NAME="FreeBSD 13.0-CURRENT"
ANSI_COLOR="0;34"
CPE_NAME="cpe:/o:freebsd:freebsd:13.0"
HOME_URL="https://freebsd.org/"
BUG_REPORT_URL="https://bugs.freebsd.org"

Then you get:
>./a.out                
13.0
Comment 3 Alexey Dokuchaev freebsd_committer 2019-04-07 17:09:33 UTC
Why not use uname(3) instead?  Wait for my commit to `net-im/psi' for example.
Comment 4 commit-hook freebsd_committer 2019-04-07 17:17:45 UTC
A commit references this bug:

Author: danfe
Date: Sun Apr  7 17:17:26 UTC 2019
New revision: 498300
URL: https://svnweb.freebsd.org/changeset/ports/498300

Log:
  Report correct FreeBSD version: currently, QSysInfo::productVersion() on
  FreeBSD bogusly returns "unknown".

  PR:	237075

Changes:
  head/net-im/psi/files/patch-src_systeminfo.cpp
Comment 5 Tobias C. Berner freebsd_committer 2019-04-07 17:32:59 UTC
(In reply to Alexey Dokuchaev from comment #3)
Because adding /etc/os-release would fix it for free, while manually patching it means carrying a (likely) un-upstreamable patch.
Comment 6 Alexey Dokuchaev freebsd_committer 2019-04-08 09:10:43 UTC
Sorry, but I don't like this approach.  Relying on some file to carry information about the operating system instead of asking it directly would be only appropriate in some crippled, very ascetic environments.  Usually, operating system should be asked, and most of them provide standard ways of doing so.  Both Linux and FreeBSD provide uname(3) function as defined by POSIX[*], I'd assume that Windows also has something like that.

> manually patching it means carrying a (likely) un-upstreamable patch.
Why do you think upstream would not be interested in nice and clean patch instead of this "read from /etc/os-release" crap?

[*] http://pubs.opengroup.org/onlinepubs/9699919799/functions/uname.html
Comment 7 Koop Mast freebsd_committer 2019-04-08 21:15:28 UTC
While I would like this file to exist so the current code would work out of the box. I know gnome-control-center uses it for example, I'm not not that hard line for get it.

You also have to remember that this /etc/os-release "crap" has "invested" all major linux distro's and most software assumes it there to be used. This doesn't mean we can't write our own code, but if upstream is a bit subborn we have a patch upstream doesn't want to accept.
Comment 8 Baptiste Daroussin freebsd_committer 2019-04-09 16:10:00 UTC
I don't like the idea of adding /etc/os-release.

At the sametime I think the uname usage is very fragile considering it will give your the version of the kernel not the version of the userland, while if you run the code in a FreeBSD 11 jail running on a 13-CURRENT host the output would be wrong (except if one forces some variable environment).

That said, having a package that installs /usr/local/etc/os-release in an accurate manner would be pretty easy and can probably do the trick with the cost of almost no patches or upstreamable patches (configurable path to os-release).
Comment 9 Alexey Dokuchaev freebsd_committer 2019-04-09 16:29:59 UTC
Fair enough.  Given the above rationale, I guess I can live with carefully crafted /usr/local/etc/os-release (but definitely not /etc/os-release).
Comment 10 Tobias C. Berner freebsd_committer 2019-04-09 17:00:40 UTC
(In reply to Alexey Dokuchaev from comment #9)
I'll prepare something for review on the weekend.
Comment 11 Tobias C. Berner freebsd_committer 2019-05-01 09:22:06 UTC
sysutils/etc_os-release is there now and used by qt5-core.