pkg-fallout: License not correctly defined: defining both LICENSE_FILE and LICENSE_TEXT is not allowed
I'm getting the following report from pkg-fallout@:
License not correctly defined: defining both LICENSE_FILE and LICENSE_TEXT is
not allowed
for
x11-themes/kde-icons-nuovext2
HOWEVER the error returned by pkg-fallout@ makes absolutely no
sense at all, given the Makefile for the report contains only:
LICENSE=LGPL3
LICENSE_FILE= ${WRKSRC}/COPYING
for the license section.
Please advise, or tell me how to fix the pkg builder.
Thanks!
--Chris
___
freebsd-ports@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-ports
To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org"
Re: pkg-fallout: License not correctly defined: defining both LICENSE_FILE and LICENSE_TEXT is not allowed
## Chris (portmas...@bsdforge.com): > HOWEVER the error returned by pkg-fallout@ makes absolutely no > sense at all, given the Makefile for the report contains only: Foremost, that Makefile has an .include, and that's where the mess (for this use case) happens. >From a quick glance, I'm not totally sure how that kde-icons-noia/Makefile.icons makes sense in the grand scheme of things (if it's that common functionality, should it live somewhere in Mk? if it's relevant only for a very limited number of ports, should it have some comments about that?), but the way it currently interacts with your port is not that fine: in the very least, it overwrites your LICENSE variables, which cannot be your intention. (Try "make -V LICENSE" in kde-icons-nuovoext2). Regards, Christoph -- Spare Space ___ freebsd-ports@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org"
Re: Trubles compiling lxqt on RPi4
On Thu, May 13, 2021 at 08:13:07AM +0200, Jan Beich wrote: > > > > Moving to /usr/ports/json-glib and using > > make -DBATCH MAKE_JOBS_UNSAFE=yes MAKE_JOBS_NUMBER=4 > > DISABLE_VULNERABILITIES=yes > make.log > > reports several instances of > > error: unknown argument: '-fno-color-diagnostics' > > Likely caused by desync between USES=meson and devel/meson, see > https://cgit.freebsd.org/ports/commit/?id=ff2796d5bc83 > > Try again after re-installing devel/meson. That might be a hint which circles back to Mark's comments related to python37 vs -38. Trying to re-make devel/meson finds. root@nemesis:/usr/ports/devel/meson # make -DBATCH FORCE_PKG_REGISTER=yes install ===> meson-0.57.1_1 depends on package: py38-setuptools>0 - not found ===> Installing for py38-setuptools-44.0.0_1 ===> Registering installation for py38-setuptools-44.0.0_1 as automatic Installing py38-setuptools-44.0.0_1... pkg-static: py38-setuptools-44.0.0_1 conflicts with py37-setuptools-44.0.0 (installs files into the same place). Problematic file: /usr/local/bin/easy_install *** Error code 1 Stop. make[1]: stopped in /usr/ports/devel/py-setuptools *** Error code 1 Stop. make: stopped in /usr/ports/devel/meson The fix for the -37 vs-38 conflict invokes portmaster, might it suffice to simply deinstall -37 and explicitly replace it with -38 ? I'll give it a try. Hmm, no dice. After deinstalling python37 and reinstalling python38 an attempt to make devel/meson still stops with root@nemesis:/usr/ports/devel/meson # make -DBATCH DISABLE_VULNERABILITIES=yes install ===> meson-0.57.1_1 depends on package: py38-setuptools>0 - not found ===> Installing for py38-setuptools-44.0.0_1 ===> Checking if py38-setuptools is already installed ===> Registering installation for py38-setuptools-44.0.0_1 as automatic Installing py38-setuptools-44.0.0_1... pkg-static: py38-setuptools-44.0.0_1 conflicts with py37-setuptools-44.0.0 (installs files into the same place). Problematic file: /usr/local/bin/easy_install *** Error code 1 How did python38 get installed without py38-setuptools? bob prohaska ___ freebsd-ports@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org"
Re: Trubles compiling lxqt on RPi4
bob prohaska fbsd at www.zefox.net wrote on
Thu May 13 15:39:41 UTC 2021 :
> On Thu, May 13, 2021 at 08:13:07AM +0200, Jan Beich wrote:
> > >
> > > Moving to /usr/ports/json-glib and using
> > > make -DBATCH MAKE_JOBS_UNSAFE=yes MAKE_JOBS_NUMBER=4
> > > DISABLE_VULNERABILITIES=yes > make.log
> > > reports several instances of
> > > error: unknown argument: '-fno-color-diagnostics'
> >
> > Likely caused by desync between USES=meson and devel/meson, see
> > https://cgit.freebsd.org/ports/commit/?id=ff2796d5bc83
> >
> > Try again after re-installing devel/meson.
>
> That might be a hint which circles back to Mark's comments related to
> python37 vs -38. Trying to re-make devel/meson finds.
>
> root at nemesis:/usr/ports/devel/meson # make -DBATCH FORCE_PKG_REGISTER=yes
> install
> ===> meson-0.57.1_1 depends on package: py38-setuptools>0 - not found
> ===> Installing for py38-setuptools-44.0.0_1
> ===> Registering installation for py38-setuptools-44.0.0_1 as automatic
> Installing py38-setuptools-44.0.0_1...
> pkg-static: py38-setuptools-44.0.0_1 conflicts with py37-setuptools-44.0.0
> (installs files into the same place). Problematic file:
> /usr/local/bin/easy_install
> *** Error code 1
>
> Stop.
> make[1]: stopped in /usr/ports/devel/py-setuptools
> *** Error code 1
>
> Stop.
> make: stopped in /usr/ports/devel/meson
>
> The fix for the -37 vs-38 conflict invokes portmaster, might it
> suffice to simply deinstall -37 and explicitly replace it with
> -38 ? I'll give it a try.
>
> Hmm, no dice. After deinstalling python37 and reinstalling python38 an
> attempt to make devel/meson still stops with
>
> root at nemesis:/usr/ports/devel/meson # make -DBATCH
> DISABLE_VULNERABILITIES=yes install
> ===> meson-0.57.1_1 depends on package: py38-setuptools>0 - not found
> ===> Installing for py38-setuptools-44.0.0_1
> ===> Checking if py38-setuptools is already installed
> ===> Registering installation for py38-setuptools-44.0.0_1 as automatic
> Installing py38-setuptools-44.0.0_1...
> pkg-static: py38-setuptools-44.0.0_1 conflicts with py37-setuptools-44.0.0
> (installs files into the same place). Problematic file:
> /usr/local/bin/easy_install
> *** Error code 1
>
> How did python38 get installed without py38-setuptools?
You have apparently chosen to build/update ports via a
technique that requires you to manage the dependencies, at
least some of the time. (Not that when is necessarily
obvious up front.)
Your environment is now based on a mix of python37 and
python 38 related materials. You are likely going to
need to rework/rebuild/reinstall things to avoid that.
Hints may come from that UPDATING that I quoted but
things are more broken overall than what UPDATING is
intended to cover. You might end up needing to
uninstall a bunch of stuff until python is unused
(or only one python is used) and then follow the
notes if you have only python37 use and want to
get to python38. Finally rebuild/reinstall what
was uninstalled, based on python38 as a context.
(I'm not even sure uninstalls are going to always work
correctly/completely in the mixed context.)
QUOTE
20210425:
AFFECTS: users of python
AUTHOR: kai at FreeBSD.org
The default version of python3 and python was switched to 3.8.
For ports users wanting to keep version 3.7 as default,
add DEFAULT_VERSIONS+= python=3.7 python3=3.7 to make.conf
Following procedures may ease the upgrade:
For users of pre-build packages:
# sh
# for i in $(pkg query -g %n 'py37-*'); do pkg set -yn ${i}:py38-${i#py37-};
done
# pkg upgrade
For portmaster users:
# sh
# portmaster -o lang/python38 python37
# REINSTALL="$(pkg info -o "*py37*" | awk '{printf "%s ", $2}')"
# pkg delete -f "*py37*"
# portmaster $REINSTALL
# REBUILD=$(pkg query -g "%n:%dn" '*' | grep py3 | grep -v py38 | cut -d : -f
1 | sort -u)
# portmaster $REBUILD
# REBUILD2=$(pkg list | grep python-37 | xargs pkg which | awk '{print $6}' |
sort -u)
# portmaster $REBUILD2
END QUOTE
Due to how I build/install ports, I've not had to deal
with ending up with the mix so I'm not familiar with
the details for recovering from a messy mix.
===
Mark Millard
marklmi at yahoo.com
( dsl-only.net went
away in early 2018-Mar)
___
freebsd-ports@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-ports
To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org"
Re: pkg-fallout: License not correctly defined: defining both LICENSE_FILE and LICENSE_TEXT is not allowed
On 2021-05-13 09:08, Christoph Moench-Tegeder wrote: ## Chris (portmas...@bsdforge.com): HOWEVER the error returned by pkg-fallout@ makes absolutely no sense at all, given the Makefile for the report contains only: Foremost, that Makefile has an .include, and that's where the mess (for this use case) happens. From a quick glance, I'm not totally sure how that kde-icons-noia/Makefile.icons makes sense in the grand scheme of things (if it's that common functionality, should it live somewhere in Mk? if it's relevant only for a very limited number of ports, should it have some comments about that?), but the way it currently interacts with your port is not that fine: in the very least, it overwrites your LICENSE variables, which cannot be your intention. (Try "make -V LICENSE" in kde-icons-nuovoext2). Sorry. My bad. LGPL3 is now included in the current LICENSE Templates. So LICENSE_FILE is redundant && pkg-fallout (the ports framework) was trying to use a "clue bat" to tell me so. ;-) Sorry for the noise, and thanks for taking the time to reply. --Chris Regards, Christoph ___ freebsd-ports@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org"
Re: Trubles compiling lxqt on RPi4
On 2021-May-13, at 14:27, Tatsuki Makino wrote: > 20210425 of UPDATING doesn't take into care the environment where python37 > and python38 are installed at the same time. > This is a problem for people who installed 3.8 when 3.7 was the default. > (e.g. user of graphics/blender) > > Can you experiment with the commands I've been thinking about in anticipation > of 3.9 becoming the default :) > > # check dependencies. > pkg check -d -n -a > # gather the names of packages that will need to be reinstalled. > pkg query -e '( %n !~ py37-* && %n !~ *-py37-* )' %n-:%dn | grep -e > ':python37\|:py37-\|:.*-py37-' | cut -d : -f 1 | sort -u > /tmp/py37.txt > # gather the origins of manually installed packages where the FLAVOR will > change. > pkg query -e '( %n ~ py37-* || %n ~ *-py37-* ) && %a = 0 && %#''r = 0' %o:%dn > | grep -e ':python37\|:py37-\|:.*-py37-' | cut -d : -f 1 | sort -u > > /tmp/py37-o.txt > # delete the py37 packages > pkg delete -f -g py37-\* \*-py37-\* > # install the package of py37-o.txt > xargs -o -- portmaster (portmaster options of your choice) < /tmp/py37-o.txt > # reinstall the package of py37.txt > xargs -o -- portmaster (portmaster options of your choice) < /tmp/py37.txt > My context is not based on using portmaster at all. I do not create environments with multiple versions of python in use (or other such potential conflicts). So: It will not be me that tests such commands for handling such contexts. May be Bob P. will test your sequence. === Mark Millard marklmi at yahoo.com ( dsl-only.net went away in early 2018-Mar) ___ freebsd-ports@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org"
Re: Making a port to use OpenSSL of ports collection on FreeBSD 11.x
___ freebsd-ports@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org"
Python 37/38 conflict, was Re: Trubles compiling lxqt on RPi4
On Thu, May 13, 2021 at 01:35:50PM -0700, Mark Millard wrote: > You have apparently chosen to build/update ports via a > technique that requires you to manage the dependencies, at > least some of the time. (Not that when is necessarily > obvious up front.) > You give me too much credit 8-) > Your environment is now based on a mix of python37 and > python 38 related materials. You are likely going to > need to rework/rebuild/reinstall things to avoid that. > > Hints may come from that UPDATING that I quoted but > things are more broken overall than what UPDATING is > intended to cover. You might end up needing to > uninstall a bunch of stuff until python is unused > (or only one python is used) and then follow the > notes if you have only python37 use and want to > get to python38. Finally rebuild/reinstall what > was uninstalled, based on python38 as a context. > Trying to deinstall both python37 and python38 didn't suffice. Python38's reinstall fails with the same conflict. Deleting the offending file doesn't help If other things need to be deinstalled it's not clear what they might be. > Due to how I build/install ports, I've not had to deal > with ending up with the mix so I'm not familiar with > the details for recovering from a messy mix. > Would use of poudriere help with this sort of problem? It isn't trivial to configure, but this sort of difficulty has been growing ever worse. I didn't want to deal with the complexity and overhead, but maybe it's time. Many thanks for patient counsel! bob prohaska ___ freebsd-ports@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org"
Re: Python 37/38 conflict, was Re: Trubles compiling lxqt on RPi4
On 14/05/2021 11:35 am, bob prohaska wrote: On Thu, May 13, 2021 at 01:35:50PM -0700, Mark Millard wrote: You have apparently chosen to build/update ports via a technique that requires you to manage the dependencies, at least some of the time. (Not that when is necessarily obvious up front.) You give me too much credit 8-) Your environment is now based on a mix of python37 and python 38 related materials. You are likely going to need to rework/rebuild/reinstall things to avoid that. Hints may come from that UPDATING that I quoted but things are more broken overall than what UPDATING is intended to cover. You might end up needing to uninstall a bunch of stuff until python is unused (or only one python is used) and then follow the notes if you have only python37 use and want to get to python38. Finally rebuild/reinstall what was uninstalled, based on python38 as a context. Trying to deinstall both python37 and python38 didn't suffice. Python38's reinstall fails with the same conflict. Deleting the offending file doesn't help If other things need to be deinstalled it's not clear what they might be. Due to how I build/install ports, I've not had to deal with ending up with the mix so I'm not familiar with the details for recovering from a messy mix. Would use of poudriere help with this sort of problem? It isn't trivial to configure, but this sort of difficulty has been growing ever worse. I didn't want to deal with the complexity and overhead, but maybe it's time. Many thanks for patient counsel! bob prohaska ___ freebsd-ports@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org" happy to help identify the root cause if you can jump on IRC (#freebsd-python @ freenode) ___ freebsd-ports@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org"
Re: Trubles compiling lxqt on RPi4
In the meantime, if anyone has failed to update default version to 3.8, please try it :) It will also restore automatic flag correctly. Best regards. Mark Millard wrote on 2021/05/14 06:43: > My context is not based on using portmaster at all. I do > not create environments with multiple versions of python > in use (or other such potential conflicts). > > So: It will not be me that tests such commands for handling > such contexts. > > May be Bob P. will test your sequence. > ___ freebsd-ports@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org"
Re: Trubles compiling lxqt on RPi4
20210425 of UPDATING doesn't take into care the environment where python37 and python38 are installed at the same time. This is a problem for people who installed 3.8 when 3.7 was the default. (e.g. user of graphics/blender) Can you experiment with the commands I've been thinking about in anticipation of 3.9 becoming the default :) # check dependencies. pkg check -d -n -a # gather the names of packages that will need to be reinstalled. pkg query -e '( %n !~ py37-* && %n !~ *-py37-* )' %n-:%dn | grep -e ':python37\|:py37-\|:.*-py37-' | cut -d : -f 1 | sort -u > /tmp/py37.txt # gather the origins of manually installed packages where the FLAVOR will change. pkg query -e '( %n ~ py37-* || %n ~ *-py37-* ) && %a = 0 && %#''r = 0' %o:%dn | grep -e ':python37\|:py37-\|:.*-py37-' | cut -d : -f 1 | sort -u > /tmp/py37-o.txt # delete the py37 packages pkg delete -f -g py37-\* \*-py37-\* # install the package of py37-o.txt xargs -o -- portmaster (portmaster options of your choice) < /tmp/py37-o.txt # reinstall the package of py37.txt xargs -o -- portmaster (portmaster options of your choice) < /tmp/py37.txt Best regards. ___ freebsd-ports@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org"
Re: Troubles compiling lxqt on RPi4
On 2021-May-12, at 22:28, bob prohaska wrote:
> On Wed, May 12, 2021 at 09:16:29PM -0700, Mark Millard via freebsd-ports
> wrote:
>> On 2021-May-12, at 20:48, bob prohaska wrote:
>>
>>>
>>> Moving to /usr/ports/json-glib and using
>>> make -DBATCH MAKE_JOBS_UNSAFE=yes MAKE_JOBS_NUMBER=4
>>> DISABLE_VULNERABILITIES=yes > make.log
>>> reports several instances of
>>> error: unknown argument: '-fno-color-diagnostics'
>>>
>>> Running make clean and restarting makes no difference. There don't seem to
>>> be
>>> any user options for making json-glib,
>>
>> The build log at:
>>
>> http://ampere2.nyi.freebsd.org/data/main-arm64-default/pcd62f0886c18_sd1cb8d11b0/logs/json-glib-1.6.2_1.log
>>
>> is the one that just python38 and it reports:
>>
>> ---Begin OPTIONS List---
>> ===> The following configuration options are available for json-glib-1.6.2_1:
>> DOCS=on: Build and/or install documentation
>> GIR=on: Build introspection data
>> ===> Use 'make config' to modify these settings
>> ---End OPTIONS List---
>>
>> as the options that were used for the build. So
>> there are 2 options, one of which is appearently
>> tied to the code's operation (introspection data).
>>
>
> Turning off both options and trying a manual make seems to end with the same
> error.
>
>
>
>>> but I wonder if it might be inherting
>>> an incompatible option from something else.
>>
>> That build log also has lines showing the likes of:
>>
>> [ 21% 16/69] cc -Ijson-glib/libjson-glib-1.0.so.0.600.2.p . . .
>> -fno-color-diagnostics . . .
>>
>> The compiler is reported in the log to be:
>>
>> C compiler for the host machine: cc (clang 11.0.1 "FreeBSD clang version
>> 11.0.1 (g...@github.com:llvm/llvm-project.git
>> llvmorg-11.0.1-0-g43ff75f2c3fe)")
>> C linker for the host machine: cc ld.lld 11.0.1
>>
>> That "llvmorg-11.0.1-0-g43ff75f2c3fe" matches what is in my
>> historical main [so: 14] environments.
>>
>> So system-clang apparently allows the option.
>>
>> You did not show any example command that got the complaint
>> about -fno-color-diagnostics so I can ont even be sure it
>> was a cc command that had the option.
>>
>>
>
> A copy of the make log is at
> http://www.zefox.net/~fbsd/rpi4/lxqt/make.log
Note: Your environment is not up to date enough to be using
python38 . The log shows:
[ 1% 4/69] /usr/local/bin/python3.7 . . .
. . .
I'll note that /usr/ports/UPDATING reports:
20210425:
AFFECTS: users of python
AUTHOR: k...@freebsd.org
The default version of python3 and python was switched to 3.8.
For ports users wanting to keep version 3.7 as default,
add DEFAULT_VERSIONS+= python=3.7 python3=3.7 to make.conf
Following procedures may ease the upgrade:
For users of pre-build packages:
# sh
# for i in $(pkg query -g %n 'py37-*'); do pkg set -yn ${i}:py38-${i#py37-};
done
# pkg upgrade
For portmaster users:
# sh
# portmaster -o lang/python38 python37
# REINSTALL="$(pkg info -o "*py37*" | awk '{printf "%s ", $2}')"
# pkg delete -f "*py37*"
# portmaster $REINSTALL
# REBUILD=$(pkg query -g "%n:%dn" '*' | grep py3 | grep -v py38 | cut -d : -f
1 | sort -u)
# portmaster $REBUILD
# REBUILD2=$(pkg list | grep python-37 | xargs pkg which | awk '{print $6}' |
sort -u)
# portmaster $REBUILD2
The log also shows the use of -Xclang in the cc commands:
cc -Ijson-glib/libjson-glib-1.0.so.0.600.2.p . . . -Xclang
-fno-color-diagnostics . . .
but:
http://ampere2.nyi.freebsd.org/data/main-arm64-default/pcd62f0886c18_sd1cb8d11b0/logs/json-glib-1.6.2_1.log
does not show any use of -Xclang .
-Xclang makes the following argument be passed directly to the
cc1 compiler stage. So the:
error: unknown argument: '-fno-color-diagnostics'
would be from cc1. "clang -cc1 --help" only reports one
form of color-diagnostics option allowed by the -cc1
stage:
-fcolor-diagnostics Enable colors in diagnostics
Viewed various ways that confirm:
# more main.c
static volatile char big_area[67001] = "This is a test";
int main ()
{
big_area[67000] = '9';
}
# clang -Xclang -fno-color-diagnostics main.c
error: unknown argument: '-fno-color-diagnostics'
But the detail of what is involved, showing the
-cc1 command that is internally generated, is:
# clang -### -Xclang -fno-color-diagnostics main.c
FreeBSD clang version 11.0.1 (g...@github.com:llvm/llvm-project.git
llvmorg-11.0.1-0-g43ff75f2c3fe)
Target: x86_64-unknown-freebsd14.0
Thread model: posix
InstalledDir: /usr/bin
"/usr/bin/clang" "-cc1" "-triple" "x86_64-unknown-freebsd14.0" "-emit-obj"
"-mrelax-all" "-disable-free" "-disable-llvm-verifier" "-discard-value-names"
"-main-file-name" "main.c" "-mrelocation-model" "static" "-mframe-pointer=all"
"-fno-rounding-math" "-mconstructor-aliases" "-munwind-tables" "-target-cpu"
"x86-64" "-fno-split-dwarf-inlining" "-debugger-tuning=gdb" "-resource-dir"
"/usr/lib/clang/11.0.1" "-fdebug-compilation-dir" "/root/c_tests"
"-ferror-limit" "19" "-fgnuc-version=4.2.1"
Re: Trubles compiling lxqt on RPi4
bob prohaska writes: > On Wed, May 12, 2021 at 05:17:37PM -0700, Mark Millard via freebsd-ports > wrote: > >> bob prohaska fbsd at www.zefox.net wrote on >> Wed May 12 21:10:02 UTC 2021 : >> >> > Attempts to compile x11/x11-wm/lxqt on a Pi4 running -current >> > get stuck with: >> > ===> Building for json-glib-1.6.2_1 > [] >> > FAILED: >> > json-glib/libjson-glib-1.0.so.0.600.2.p/meson-generated_.._json-enum-types.c.o >> > >> > Is there a workaround? Ports were up-to-date as of today, May 12, 2021. >> >> You are not very explicit about the FreeBSD context and >> such, beyond RPi4 (so aarm64/aarch64). >> >> > > Moving to /usr/ports/json-glib and using > make -DBATCH MAKE_JOBS_UNSAFE=yes MAKE_JOBS_NUMBER=4 > DISABLE_VULNERABILITIES=yes > make.log > reports several instances of > error: unknown argument: '-fno-color-diagnostics' Likely caused by desync between USES=meson and devel/meson, see https://cgit.freebsd.org/ports/commit/?id=ff2796d5bc83 Try again after re-installing devel/meson. ___ freebsd-ports@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org"
Re: Troubles compiling lxqt on RPi4 [out of date Mk/Uses/meson.mk in use]
On 2021-May-12, at 23:13, Mark Millard wrote:
>
> On 2021-May-12, at 22:28, bob prohaska wrote:
>
>> On Wed, May 12, 2021 at 09:16:29PM -0700, Mark Millard via freebsd-ports
>> wrote:
>>> On 2021-May-12, at 20:48, bob prohaska wrote:
>>>
Moving to /usr/ports/json-glib and using
make -DBATCH MAKE_JOBS_UNSAFE=yes MAKE_JOBS_NUMBER=4
DISABLE_VULNERABILITIES=yes > make.log
reports several instances of
error: unknown argument: '-fno-color-diagnostics'
Running make clean and restarting makes no difference. There don't seem to
be
any user options for making json-glib,
>>>
>>> The build log at:
>>>
>>> http://ampere2.nyi.freebsd.org/data/main-arm64-default/pcd62f0886c18_sd1cb8d11b0/logs/json-glib-1.6.2_1.log
>>>
>>> is the one that just python38 and it reports:
>>>
>>> ---Begin OPTIONS List---
>>> ===> The following configuration options are available for
>>> json-glib-1.6.2_1:
>>>DOCS=on: Build and/or install documentation
>>>GIR=on: Build introspection data
>>> ===> Use 'make config' to modify these settings
>>> ---End OPTIONS List---
>>>
>>> as the options that were used for the build. So
>>> there are 2 options, one of which is appearently
>>> tied to the code's operation (introspection data).
>>>
>>
>> Turning off both options and trying a manual make seems to end with the same
>> error.
>>
>>
>>
but I wonder if it might be inherting
an incompatible option from something else.
>>>
>>> That build log also has lines showing the likes of:
>>>
>>> [ 21% 16/69] cc -Ijson-glib/libjson-glib-1.0.so.0.600.2.p . . .
>>> -fno-color-diagnostics . . .
>>>
>>> The compiler is reported in the log to be:
>>>
>>> C compiler for the host machine: cc (clang 11.0.1 "FreeBSD clang version
>>> 11.0.1 (g...@github.com:llvm/llvm-project.git
>>> llvmorg-11.0.1-0-g43ff75f2c3fe)")
>>> C linker for the host machine: cc ld.lld 11.0.1
>>>
>>> That "llvmorg-11.0.1-0-g43ff75f2c3fe" matches what is in my
>>> historical main [so: 14] environments.
>>>
>>> So system-clang apparently allows the option.
>>>
>>> You did not show any example command that got the complaint
>>> about -fno-color-diagnostics so I can ont even be sure it
>>> was a cc command that had the option.
>>>
>>>
>>
>> A copy of the make log is at
>> http://www.zefox.net/~fbsd/rpi4/lxqt/make.log
>
> Note: Your environment is not up to date enough to be using
> python38 . The log shows:
>
> [ 1% 4/69] /usr/local/bin/python3.7 . . .
> . . .
>
> I'll note that /usr/ports/UPDATING reports:
>
> 20210425:
> AFFECTS: users of python
> AUTHOR: k...@freebsd.org
>
> The default version of python3 and python was switched to 3.8.
>
> For ports users wanting to keep version 3.7 as default,
> add DEFAULT_VERSIONS+= python=3.7 python3=3.7 to make.conf
>
> Following procedures may ease the upgrade:
>
> For users of pre-build packages:
> # sh
> # for i in $(pkg query -g %n 'py37-*'); do pkg set -yn ${i}:py38-${i#py37-};
> done
> # pkg upgrade
>
> For portmaster users:
> # sh
> # portmaster -o lang/python38 python37
> # REINSTALL="$(pkg info -o "*py37*" | awk '{printf "%s ", $2}')"
> # pkg delete -f "*py37*"
> # portmaster $REINSTALL
> # REBUILD=$(pkg query -g "%n:%dn" '*' | grep py3 | grep -v py38 | cut -d :
> -f 1 | sort -u)
> # portmaster $REBUILD
> # REBUILD2=$(pkg list | grep python-37 | xargs pkg which | awk '{print $6}'
> | sort -u)
> # portmaster $REBUILD2
>
>
>
> The log also shows the use of -Xclang in the cc commands:
>
> cc -Ijson-glib/libjson-glib-1.0.so.0.600.2.p . . . -Xclang
> -fno-color-diagnostics . . .
>
> but:
>
> http://ampere2.nyi.freebsd.org/data/main-arm64-default/pcd62f0886c18_sd1cb8d11b0/logs/json-glib-1.6.2_1.log
>
> does not show any use of -Xclang .
>
> -Xclang makes the following argument be passed directly to the
> cc1 compiler stage. So the:
>
> error: unknown argument: '-fno-color-diagnostics'
>
> would be from cc1. "clang -cc1 --help" only reports one
> form of color-diagnostics option allowed by the -cc1
> stage:
>
> -fcolor-diagnostics Enable colors in diagnostics
>
> Viewed various ways that confirm:
>
> # more main.c
> static volatile char big_area[67001] = "This is a test";
> int main ()
> {
>big_area[67000] = '9';
> }
>
> # clang -Xclang -fno-color-diagnostics main.c
> error: unknown argument: '-fno-color-diagnostics'
>
> But the detail of what is involved, showing the
> -cc1 command that is internally generated, is:
>
> # clang -### -Xclang -fno-color-diagnostics main.c
> FreeBSD clang version 11.0.1 (g...@github.com:llvm/llvm-project.git
> llvmorg-11.0.1-0-g43ff75f2c3fe)
> Target: x86_64-unknown-freebsd14.0
> Thread model: posix
> InstalledDir: /usr/bin
> "/usr/bin/clang" "-cc1" "-triple" "x86_64-unknown-freebsd14.0" "-emit-obj"
> "-mrelax-all" "-disable-free" "-disable-llvm-verifier" "-discard-value-names"
> "-main-file-name" "main.c" "-mrelocation-model" "static"
>
FreeBSD ports you maintain which are out of date
Dear port maintainer, The portscout new distfile checker has detected that one or more of your ports appears to be out of date. Please take the opportunity to check each of the ports listed below, and if possible and appropriate, submit/commit an update. If any ports have already been updated, you can safely ignore the entry. You will not be e-mailed again for any of the port/version combinations below. Full details can be found at the following URL: http://portscout.freebsd.org/po...@freebsd.org.html Port| Current version | New version +-+ devel/tinygo| 0.17.0 | v0.18.0 +-+ If any of the above results are invalid, please check the following page for details on how to improve portscout's detection and selection of distfiles on a per-port basis: http://portscout.freebsd.org/info/portscout-portconfig.txt Reported by:portscout! ___ freebsd-ports@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org"
