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"
> "-mframe-pointer=a
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" "-fcolo
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
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 > Do you have /etc/make.conf or /etc/src.conf or the like that > might be interfering? Something else? > Neither file is present. > What does "cc -v" show in your context? > bob@nemesis:/usr/ports/devel/json-glib % cc -v FreeBSD clang version 11.0.1 (g...@github.com:llvm/llvm-project.git llvmorg-11.0.1-0-g43ff75f2c3fe) Target: aarch64-unknown-freebsd14.0 Thread model: posix InstalledDir: /usr/bin > FYI: > As I remember, "-DBATCH MAKE_JOBS_UNSAFE=yes MAKE_JOBS_NUMBER=4" > is incoherent: the first says not to do the last. > Not sure I follow; -DBATCH refers to config options, would that affect job number? The last major port compiled was www/chromium, might there be some cleanup required before starting another compilation? I've always thought that ports communicated only through installed files, but if they use one another's source or object files it would be easier to encounter incompatibilities. If a global "make clean" will simplify things it'll be worth the wait. Thanks for your help! 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
On 2021-May-12, at 20:48, bob prohaska wrote: > 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' > > 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). > 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. Still, your report suggests that the "cc" in your environment for this build does not reach the normal system-clang. Do you have /etc/make.conf or /etc/src.conf or the like that might be interfering? Something else? What does "cc -v" show in your context? FYI: As I remember, "-DBATCH MAKE_JOBS_UNSAFE=yes MAKE_JOBS_NUMBER=4" is incoherent: the first says not to do the last. === 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: Trubles compiling lxqt on RPi4
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' Running make clean and restarting makes no difference. There don't seem to be any user options for making json-glib, but I wonder if it might be inherting an incompatible option from something else. Thanks for writing! 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 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 > [ 1% 1/53] cc -Ijson-glib/libjson-glib-1.0.so.0.600.2.p -Ijson-glib > -I../json-glib -I. -I.. -I/usr/ > local/include -I/usr/local/include/glib-2.0 -I/usr/local/lib/glib-2.0/include > -Xclang -fno-color-dia > gnostics -pipe -D_FILE_OFFSET_BITS=64 -Wall -Winvalid-pch -std=c99 -O3 -O2 > -fstack-protector-strong > -isystem /usr/local/include -fno-strict-aliasing -isystem /usr/local/include > -fPIC -pthread '-DG_LOG > _DOMAIN="Json"' -DG_LOG_USE_STRUCTURED=1 -DJSON_COMPILATION > '-DJSON_LOCALEDIR="/usr/local/share/loca > le"' -Wcast-align -Wmissing-declarations -Wmissing-format-attribute > -Wmissing-prototypes -Wmissing-n > oreturn -Wold-style-definition -Wpointer-arith -Wshadow -Wstrict-prototypes > -Wunused -Wno-int-conver > sion -fno-strict-aliasing -Wno-uninitialized -Werror=address > -Werror=array-bounds -Werror=empty-body > -Werror=format=2 -Werror=implicit -Werror=init-self > -Werror=int-to-pointer-cast -Werror=main -Werro > r=missing-braces -Werror=nested-externs -Werror=nonnull > -Werror=pointer-to-int-cast -Werror=return-t > ype -Werror=sequence-point -Werror=trigraphs -Werror=undef > -Werror=write-strings -fvisibility=hidden > -MD -MQ > json-glib/libjson-glib-1.0.so.0.600.2.p/meson-generated_.._json-enum-types.c.o > -MF json-gli > b/libjson-glib-1.0.so.0.600.2.p/meson-generated_.._json-enum-types.c.o.d -o > json-glib/libjson-glib-1 > .0.so.0.600.2.p/meson-generated_.._json-enum-types.c.o -c > json-glib/json-enum-types.c > 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). It is also likely that there was more error-type reporting text than just: FAILED: json-glib/libjson-glib-1.0.so.0.600.2.p/meson-generated_.._json-enum-types.c.o The error is from the build attempt for: devel/json-glib instead of directly from lxqt. http://ampere2.nyi.freebsd.org/build.html?mastername=main-arm64-default&build=p46fc7df8540c_s1f64f32a4c and: http://ampere2.nyi.freebsd.org/build.html?mastername=main-arm64-default&build=pcd62f0886c18_sd1cb8d11b0 show successful builds of json-glib-1.6.2_1 on/for main [so: 14]. The first used python37 and the 2nd python38 . Most of the other modern build runs that show json-glib-1.6.2_1 queued indicate that it was skipped because of: docbook-xml-5.0_3 sdocbook-xml-1.1_2,2 None listed failed builds, so no logs would match your report. https://www.freshports.org/devel/json-glib indicates that the last devel/json-glib update was on 2021-Apr-06. (I've not checked other dependencies, beyond the basicis of the python3 change.) This may get into things like poudriere based builds vs. some other ways of building that are more sensitive to context oddities. But you were not explicit about that aspect of things. === 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: ports-mgmt/poudriere-devel, lang/rust (for example), and USE_TMPFS that includes wrkdir (or yes)
There is no solution at the moment and is a common complaint (about concurrent large builds). I had TMPFS_LIMIT=15 and had rust fail on me from that. Quite large... Bryan On 5/10/2021 10:19 PM, Mark Millard wrote: > I've been using USE_TMPFS=yes (so "wrkdir data") on > various systems, both ZFS (recently) and UFS > (generally, even now). Only one system builds rust > (in order for something else to be built), at least > so far. > > An example of the wrkdirs tmpfs use for rust is > (UFS context): > > # df -m | grep tmpfs > Filesystem 1M-blocks Used Avail Capacity Mounted on > . . . > tmpfs 301422 17859 283563 6% > /usr/local/poudriere/data/.m/FBSDFSSDjail-default/01/wrkdirs > . . . > > This was near the end but the maximum figure was probably > somewhat higher than the 17 GiByte+ figure above. The > context the example is from is for the only large capacity > build machine that I have access to, an amd64 context. I > have other build contexts as well, but, so far, none have > had to deal with building rust. > > Rust likely would fit the 8 GiByte RAM + 24 GiByte swap > aarch64 build context with USE_TMPFS including wrkdir if > it was the only builder running at the time. But the > existing builds for the context allow 4 builders in > parallel, one per core. [This deals just fine with > llvm10, llvm11, llvm12, and, gcc10 (no bootstrap) being > what happens to build in parallel, even with USE_TMPFS > that includes wrkdir. Rust is just uses more space all > by itself.] > > If I end up with something that requires rust for the > aarch64 builder context, is there a different technique > to deal with the tradeoff other than giving up on > USE_TMPFS spanning wrkdir for all other other > ports/builder-instances as well, presuming the same > media and partitioning (such as total swap space)? > > Imaginary examples could be: > > A) Tell poudriere that lang/rust is to be built by itself >despite the general 4-builder context. > > B) Tell poudriere that USE_TMPFS excludes wrkdir for >lang/rust's specific builder. > > C) . . . (good question) . . . > > So far all I've come up with is explicitly building > lang/rust by itself first, a form of (A): > > # poudriere bulk -jNAME -w lang/rust > # poudriere bulk -jNAME -w -f ~/origins/CA72-origins.txt > > (Hopefully, reliably remembering to do so.) > > Is there any better technique that I've not noticed? > > To some extent here, lang/rust is being used an example > of a more general issue: Other ports could have similar > issues with attempted wrkdir-included USE_TMPFS use. > > Note: If I build using WITH_DEBUG, the one system that > I have access to that can build such a lang/rust with > workdir included in USE_TMPFS shows over 130 GiBytes > in the tmpfs earn the end of the builder's activity. > (This is a amd64 context with 128 GiBytes of RAM and > 192 GiBytes of swapping/paging space.) > > === > Mark Millard > marklmi at yahoo.com > ( dsl-only.net went > away in early 2018-Mar) > -- Regards, Bryan Drewery OpenPGP_signature Description: OpenPGP digital signature
Trubles compiling lxqt on RPi4
Attempts to compile x11/x11-wm/lxqt on a Pi4 running -current get stuck with: ===> Building for json-glib-1.6.2_1 [ 1% 1/53] cc -Ijson-glib/libjson-glib-1.0.so.0.600.2.p -Ijson-glib -I../json-glib -I. -I.. -I/usr/ local/include -I/usr/local/include/glib-2.0 -I/usr/local/lib/glib-2.0/include -Xclang -fno-color-dia gnostics -pipe -D_FILE_OFFSET_BITS=64 -Wall -Winvalid-pch -std=c99 -O3 -O2 -fstack-protector-strong -isystem /usr/local/include -fno-strict-aliasing -isystem /usr/local/include -fPIC -pthread '-DG_LOG _DOMAIN="Json"' -DG_LOG_USE_STRUCTURED=1 -DJSON_COMPILATION '-DJSON_LOCALEDIR="/usr/local/share/loca le"' -Wcast-align -Wmissing-declarations -Wmissing-format-attribute -Wmissing-prototypes -Wmissing-n oreturn -Wold-style-definition -Wpointer-arith -Wshadow -Wstrict-prototypes -Wunused -Wno-int-conver sion -fno-strict-aliasing -Wno-uninitialized -Werror=address -Werror=array-bounds -Werror=empty-body -Werror=format=2 -Werror=implicit -Werror=init-self -Werror=int-to-pointer-cast -Werror=main -Werro r=missing-braces -Werror=nested-externs -Werror=nonnull -Werror=pointer-to-int-cast -Werror=return-t ype -Werror=sequence-point -Werror=trigraphs -Werror=undef -Werror=write-strings -fvisibility=hidden -MD -MQ json-glib/libjson-glib-1.0.so.0.600.2.p/meson-generated_.._json-enum-types.c.o -MF json-gli b/libjson-glib-1.0.so.0.600.2.p/meson-generated_.._json-enum-types.c.o.d -o json-glib/libjson-glib-1 .0.so.0.600.2.p/meson-generated_.._json-enum-types.c.o -c json-glib/json-enum-types.c 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. Thanks for reading, 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"
security/passivedns maintainer timeout?
I've got two patches sitting in bugzilla for security/passivedns. One has been sitting there since March 22, the other since May 4. So far there has been no movement from the maintainer on those bugs, to the point I'm wondering if the maintainer is watching for issues. https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=255599 (Allow build on FreeBSD 13 and maybe 14) https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=254435 (enable option for JSON output) Would it be possible for someone else to look at those bug reports? Shawn ___ 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: audio/alsa-plugins compiles OK, install fails
Gleb Popov responds: > > On Wed, May 12, 2021 at 3:01 PM Robert Huff wrote: > > > > > Stop. > > > make[1]: stopped in /usr/ports/audio/alsa-plugins > > *** Error code 1 > > Hello. This is being worked on in https://reviews.freebsd.org/D30223 Awesome. I thank those involved. Respectfully, Robert "Thank god it wasn't me." Huff -- Hello ... my name is SARS-CoV-2. You are not wearing a mask? Prepare to die! ___ 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: audio/alsa-plugins compiles OK, install fails
On Wed, May 12, 2021 at 3:01 PM Robert Huff wrote: > Stop. > make[1]: stopped in /usr/ports/audio/alsa-plugins > *** Error code 1 > Hello. This is being worked on in https://reviews.freebsd.org/D30223 ___ 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"
audio/alsa-plugins compiles OK, install fails
Hello: On a system running: 14.0-CURRENT FreeBSD 14.0-CURRENT #0 main-d6327ae8c1: Sun Jan 24 14:16:54 EST 2021 amd64 with any required ports updated. audio/alsa-plugins builds sucessfully. Installation, however, fails with: ===> Installing for alsa-plugins-1.2.2 ===> Checking if alsa-plugins is already installed ===> Registering installation for alsa-plugins-1.2.2 pkg-static: Unable to access file /data/port-work/usr/ports/audio/alsa-plugins/work/stage/usr/local/lib/alsa-lib/libasound_module_rate_lavcrate.la:No such file or directory pkg-static: Unable to access file /data/port-work/usr/ports/audio/alsa-plugins/work/stage/usr/local/lib/alsa-lib/libasound_module_rate_lavcrate.so:No such file or directory pkg-static: Unable to access file /data/port-work/usr/ports/audio/alsa-plugins/work/stage/usr/local/lib/alsa-lib/libasound_module_rate_lavcrate_fast.so:No such file or directory pkg-static: Unable to access file /data/port-work/usr/ports/audio/alsa-plugins/work/stage/usr/local/lib/alsa-lib/libasound_module_rate_lavcrate_faster.so:No such file or directory pkg-static: Unable to access file /data/port-work/usr/ports/audio/alsa-plugins/work/stage/usr/local/lib/alsa-lib/libasound_module_rate_lavcrate_high.so:No such file or directory pkg-static: Unable to access file /data/port-work/usr/ports/audio/alsa-plugins/work/stage/usr/local/lib/alsa-lib/libasound_module_rate_lavcrate_higher.so:No such file or directory *** Error code 1 Stop. make[1]: stopped in /usr/ports/audio/alsa-plugins *** Error code 1 I have no clue what's happening. Help, please? Respectfully, Robert Huff -- Hello ... my name is SARS-CoV-2. You are not wearing a mask? Prepare to die! ___ 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: State of mail/postfix-sasl for older FreeBSD
From: Jeremy Chadwick via freebsd-ports Subject: State of mail/postfix-sasl for older FreeBSD Date: Tue, 11 May 2021 13:51:26 + > That said: I see mail/postfix-sasl as orphaned, but no mail/postfix35-sasl > stub port. I submmitted following bug report. Bug 255809 mail/postfix35: Flavorize https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=255809 Attatched patch flavorizes mail/postfix35 and add ldap_sasl and sasl flovors which correspond to mail/postfix-ldap-sasl and mail/postfix-sasl. > Understand that there's a large percentage of FreeBSD users who do not > want to deal with poudrier and its nonsense just to get something as > basic as SASL support in their MTA. Stub ports are important for this > very reason. In this case poudriere has nothing to do with the problem. Whatever tool you use you can't build slave port of mail/postfix35 because there isn't such one. --- Yasuhiro Kimura ___ 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"
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 +-+ audio/alsa-lib | 1.2.2 | 1.2.4 +-+ audio/alsa-utils| 1.2.2 | 1.2.4 +-+ databases/jasperreports | 5.5.2 | 6.17.0 +-+ devel/distcc| 3.3.5 | v3.4 +-+ 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"
Re: net-mgmt/pnp and nagios4
On 12/05/2021 08:54, Andrea Venturoli wrote: Hello. I'm using net-mgmt/nagios4 and I'd like to try adding PNP to it. Alas the port depends on net-mgmt/nagios (i.e. version 3.5.1). From general docs, I see PNP should work with Nagios 4.x. Is this expected NOT to work specifically on FreeBSD? Or can I go ahead and try modifying the DEPENDS line? From my experience with nagios, you can proceed Cheers Xavier bye & Thanks av. � -- Xavier HUMBERT - Unix/Win/MacOSX Sysadmin/Network Senior Engineer https://www.amdh.fr ___ 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"
