Bug 237075
| Summary: | devel/qt5-core: QSysInfo::productVersion() returns "unknown" | ||
|---|---|---|---|
| Product: | Ports & Packages | Reporter: | Alexey Dokuchaev <danfe> |
| Component: | Individual Port(s) | Assignee: | freebsd-kde (group) <kde> |
| Status: | Closed FIXED | ||
| Severity: | Affects Many People | CC: | kwm, tcberner |
| Priority: | Normal | Flags: | tcberner:
maintainer-feedback+
|
| Version: | Latest | ||
| Hardware: | Any | ||
| OS: | Any | ||
| URL: | https://reviews.freebsd.org/D19866 | ||
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 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 Why not use uname(3) instead? Wait for my commit to `net-im/psi' for example. 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 (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. 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 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. 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). 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). (In reply to Alexey Dokuchaev from comment #9) I'll prepare something for review on the weekend. sysutils/etc_os-release is there now and used by qt5-core. |
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".