11.2 -> some ports don't build anymore :(

PMc

PMc

After upgrading system to release 11.2, I found a couple of ports fail to build now:
Code: 
Failed: povray37^graphics/povray37
        No rule to make target '../vfe/libvfe.a'
Failed: qpxtool^sysutils/qpxtool
        invalid suffix on literal; C++11 requires a space
Failed: icewm^x11-wm/icewm
        invalid suffix on literal; C++11 requires a space

Then, when the new branches/2018Q3 appeared, the issue on icewm had been fixed, but not the other two.

So I copied the fix from icewm to the other two, and it did help for graphics/povray37, but not for sysutils/qpxtool - that seems to need a closer look.

Now, I am wondering: wouldn't it be a good idea, before announcing a new production release, to run a test-build on the current ports tree and check if at least everything builds?

Furthermore, I seem to remember that once there was something like a automated periodic test build over the ports tree, which would issue an alert in such a case. Not sure what has become of that, but it seems not to work well...
 
What's in /etc/make.conf?

PMc said:
Now, I am wondering: wouldn't it be a good idea, before announcing a new production release, to run a test-build on the current ports tree and check if at least everything builds?
Click to expand...
All versions of FreeBSD for all architectures use the exact same ports tree. Which simply means that the ports tree has nothing to do with specific releases of the OS.

PMc said:
Furthermore, I seem to remember that once there was something like a automated periodic test build over the ports tree, which would issue an alert in such a case. Not sure what has become of that, but it seems not to work well...
Click to expand...
The ports tree is continuously built because it's continuously updated. You probably mean http://portsmon.freebsd.org/. That is indeed broken.
 
SirDice said:
What's in /etc/make.conf?
Click to expand...

Nothing:

Code: 
CPUTYPE?=core2
KERNCONF=       D6R11V1
INSTALL_NODEBUG=TRUE
SENDMAIL_MC=/etc/mail/Disp.mc
SENDMAIL_SUBMIT_MC=/etc/mail/Disp.submit.mc
INDEXDIR=       /var/db/pkg
INDEXFILE=      INDEX
FORCE_MAKE_JOBS=yes
INDEX_JOBS=4
MASTER_SITE_OVERRIDE?= \
        ftp://ftp2.de.freebsd.org/pub/FreeBSD/ports/distfiles/${DIST_SUBDIR}/
DEFAULT_VERSIONS= bdb=6 perl5=5.26 python=2.7 python2=2.7 python3=3.6 ruby=2.4 ghostscript=agpl linux=c6_64 pgsql=10
QT4_OPTIONS=QGTKSTYLE
DISABLE_LICENSES=yes
WITH_BDB6_PERMITTED=yes

(FORCE_MAKE_JOBS has been ruled out.)

All versions of FreeBSD for all architectures use the exact same ports tree. Which simply means that the ports tree has nothing to do with specific releases of the OS.
Click to expand...

Very well. But the release notes say, Rel. 11.2 updated the clang from Rel. 4 to Rel. 6. And some prereqs of some prereqs of the mentioned ports tend to pull in clang Rel. 5 as well. It is currently unclear to me which one will actually be used.
But for certain the raised compile errors have their cause in a wrong language standard being applied.
And the established fix for icewm (rev. 472514) was to put this into the Makefile:
USE_CXXSTD= c++98

And that does work for povray as well. It does not work for qpxtool, because here for some reason that option does not make it into the actual compiler call. (Currently I am searching where and how that option is normally handled.)
 
The issue with x11-wm/icewm was already fixed for 2018Q1: PR 226213 (that was before 11.2 was released)

Note that the fix for icewm also includes a change in a patch file, so the USE_CXXSTD wasn't the only thing that changed.


I cannot seem to find a PR for graphics/povray37 regarding this issue. Same for sysutils/qpxtool. Nothing will happen if there's no PR for it.
 
SirDice said:
The issue with x11-wm/icewm was already fixed for 2018Q1: PR 226213 (that was before 11.2 was released)
Click to expand...

Yes, some of it was fixed, so that it did build on 11.1. For 11.2 You should rather consider PR 228317.

I cannot seem to find a PR for graphics/povray37 regarding this issue. Same for sysutils/qpxtool. Nothing will happen if there's no PR for it.
Click to expand...

That's probably because there is none.
I am not sure if I get this right. Somehow the language standard has changed, and now the expectation is to create a PR for each and every port that may fail to compile with the new standard?
 
PMc said:
Somehow the language standard has changed, and now the expectation is to create a PR for each and every port that may fail to compile with the new standard?
Click to expand...
No, I'm surprised it hasn't been picked up yet. As far as I've been able to find out the Clang update/upgrade already happened in 12-CURRENT some time ago. So any issues with the language standards would likely have been detected long before this change even hit 11-STABLE, let alone 11.2-RELEASE.

But you did run into issues and I would definitely suggest creating a PR for it. Sometimes a polite prod is all it takes.
 
SirDice said:
No, I'm surprised it hasn't been picked up yet. As far as I've been able to find out the Clang update/upgrade already happened in 12-CURRENT some time ago. So any issues with the language standards would likely have been detected long before this change even hit 11-STABLE, let alone 11.2-RELEASE.
Click to expand...

Ah, we agree! Exactly that surprizes me, too.

But you did run into issues and I would definitely suggest creating a PR for it.
Click to expand...

I did already send mail to the maintainer for povray.

Problem is qpxtool - I got it fixed, but as it doesn't have a maintainer - even with a PR, who would drop the fix in?
 
PMc said:
Problem is qpxtool - I got it fixed, but as it doesn't have a maintainer - even with a PR, who would drop the fix in?
Click to expand...
Anybody and everybody. With a PR everybody will be aware there's a problem. Somebody that doesn't know this port but does know the solution could fix it. Heck, even you can fix it if you create the PR and attach your patches.
 
O.T
I know nobody can change it. But they make much work changing to "space after and before". It is a senseless change. For years it worked with quotes....
 
SirDice said:
Anybody and everybody. With a PR everybody will be aware there's a problem. Somebody that doesn't know this port but does know the solution could fix it. Heck, even you can fix it if you create the PR and attach your patches.
Click to expand...

Well, indeed, may take some decades to work out, and the patch may interim get lost in translation (like PR 122519), but well, never mind... (been there, done it...)

Update: just found, the patch is even still present on that one, and nevertheless nobody seems to care, for more than ten years now.
 
You must log in or register to reply here.
Back
Top