[regression]Blender gets broken python detection with cmake
by Luya Tshimbalanga
Hello team,
It looks like something broke inside cmake when attempting to detect python:
CMake Error at /usr/share/cmake/Modules/FindPackageHandleStandardArgs.cmake:164 (message):
Could NOT find PythonLibsUnix (missing: PYTHON_LIBRARY PYTHON_LIBPATH
PYTHON_INCLUDE_DIR PYTHON_INCLUDE_CONFIG_DIR)
Call Stack (most recent call first):
/usr/share/cmake/Modules/FindPackageHandleStandardArgs.cmake:445 (_FPHSA_FAILURE_MESSAGE)
build_files/cmake/Modules/FindPythonLibsUnix.cmake:180 (FIND_PACKAGE_HANDLE_STANDARD_ARGS)
build_files/cmake/platform/platform_unix.cmake:99 (find_package)
CMakeLists.txt:812 (include)
-- Configuring incomplete, errors occurred!
See also "/builddir/build/BUILD/blender-2.83.3/build/CMakeFiles/CMakeOutput.log".
Can someone investigate the issue?
Reference: https://koji.fedoraproject.org/koji/taskinfo?taskID=47730766
Thanks
--
Luya Tshimbalanga
Fedora Design Team
Fedora Design Suite maintainer
3 years, 8 months
Can we use emulation of other architectures to run integration tests?
by Aleksandra Fedorova
Hi, all,
I'd like to get some understanding on the current state of emulation
of other architectures.
In the current CI infra we have infinite(*) access to x86_64 compute
resources, but we haven't yet got our hands on any non x86_64
hardware.
As COPR has recently got support for s390 builds, the question is: if
emulation is good enough for building packages, can we use it for
testing? What are the limitations there? Is it worth it?
If yes, can you suggest some links, tips on the topic?
(*) Not really, and some of our infra services are not yet good at
scaling up, but we are getting better at it.
--
Aleksandra Fedorova
bookwar
3 years, 8 months
Lua 5.4.0
by Tom Callaway
I just built lua 5.4.0 in Rawhide. As with previous major updates of lua,
the package also includes a copy of the lua 5.3 libraries so that rawhide
does not just become broken reps. If you depend on lua, please rebuild your
packages in rawhide and let me know if you run into any issues.
Thanks,
Tom
3 years, 8 months
Fedora 32 System-Wide Change proposal (late): Enable EarlyOOM
by Ben Cotton
https://fedoraproject.org/wiki/Changes/EnableEarlyoom
== Summary ==
Install earlyoom package, and enable it by default. This will cause
the kernel oomkiller to trigger sooner, but will not affect which
process it chooses to kill off. The idea is to recover from out of
memory situations sooner, rather than the typical complete system hang
in which the user has no other choice but to force power off.
== Owner ==
* Name: [[User:chrismurphy| Chris Murphy]]
* Email: bugzilla(a)colorremedies.com
== Detailed Description ==
Workstation working group has discussed "better interactivity in
low-memory situations" for some months. In certain use cases,
typically compiling, if all RAM and swap are completely consumed,
system responsiveness becomes so abysmal that a reasonable user can
consider the system "lost", and resorts to forcing a power off. This
is objective a very bad UX. The broad discussion of this problem, and
some ideas for near term and long term solutions, is located here:
Recent long discussions on "Better interactivity in low-memory situations"<br>
https://pagure.io/fedora-workstation/issue/98<br>
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.o...<br>
Fedora editions and spins, have the in-kernel OOM (out-of-memory)
manager enabled. The manager's concern is keeping the kernel itself
functioning. It has no concern about user space function or
interactivity. This proposed change attempts to improve the user
experience, in the short term, by triggering the in-kernel process
killing mechanism, sooner. Instead of the system becoming completely
unresponsive for tens of minutes, hours or days, the expectation is an
offending process (determined by oom_score, same as now) will be
killed off within seconds or a few minutes. This is an incremental
improvement in user experience, but admittedly still suboptimal. There
is additional work on-going to improve the user experience further.
Workstation working group discussion specific to enabling earlyoom by default
https://pagure.io/fedora-workstation/issue/119
Other in-progress solutions:<br>
https://gitlab.freedesktop.org/hadess/low-memory-monitor<br>
Background information on this complicated problem:<br>
https://www.kernel.org/doc/gorman/html/understand/understand016.html<br>
https://lwn.net/Articles/317814/<br>
== Benefit to Fedora ==
There are two major benefits to Fedora:
* improved user experience by more quickly regaining control over
one's system, rather than having to force power off in low-memory
situations where there's aggressive swapping. Once a system becomes
unresponsive, it's completely reasonable for the user to assume the
system is lost, but that includes high potential for data loss.
* reducing forced poweroff as the main work around will increase data
collection, improving understanding of low memory situations and how
to handle them better
== Scope ==
* Proposal owners:
a. Modify {{code|https://pagure.io/fedora-comps/blob/master/f/comps-f32.xml.in}}
to include earlyoom package for Workstation.<br>
b. Modify {{code|https://src.fedoraproject.org/rpms/fedora-release/blob/master/f/80-workstation.preset}}
to include:
<pre>
# enable earlyoom by default on workstation
enable earlyoom.service
</pre>
* Other developers:
Restricted to Workstation edition, unless other editions/spins want to opt-in.
* Release engineering: [https://pagure.io/releng/issues #9141] (a
check of an impact with Release Engineering is needed) <!-- REQUIRED
FOR SYSTEM WIDE CHANGES -->
* Policies and guidelines: N/A
* Trademark approval: N/A
== Upgrade/compatibility impact ==
earlyoom.service will be enabled on upgrade. An upgraded system should
exhibit the same behaviors as a clean installed system.
== How To Test ==
* Fedora 30/31 users can test today, any edition or spin:<br>
{{code|sudo dnf install earlyoom}}<br>
{{code|sudo systemctl enable --now earlyoom}}
And then attempt to cause an out of memory situation. Examples:<br>
{{code|tail /dev/zero}}<br>
{{code|https://lkml.org/lkml/2019/8/4/15}}
* Fedora Workstation 32 (and Rawhide) users will see this service is
already enabled. It can be toggled with {{code|sudo systemctl
start/stop earlyoom}} where start means earlyoom is running, and stop
means earlyoom is not running.
== User Experience ==
The most egregious instances this change is trying to mitigate:
a. RAM is completely used
b. Swap is completely used
c. System becomes unresponsive to the user as swap thrashing has ensued
--> earlyoom disabled, the user often gives up and forces power off
(in my own testing this condition lasts >30 minutes with no kernel
triggered oom killer and no recovery)
--> earlyoom enabled, the system likely still becomes unresponsive but
oom killer is triggered in much less time (seconds or a few minutes,
in my testing, after less than 10% RAM and 10% swap is remaining)
earlyoom starts sending SIGTERM once both memory and swap are below
their respective PERCENT setting, default 10%. It sends SIGKILL once
both are below their respective KILL_PERCENT setting, default 5%.
The package includes configuration file /etc/default/earlyoom which
sets option {{code|-r 60}} causing a memory report to be entered into
the journal every minute.
== Dependencies ==
earlyoom package has no dependencies
== Contingency Plan ==
* Contingency mechanism: Owner will revert all changes
* Contingency deadline: Final freeze
* Blocks release? No
* Blocks product? No
== Documentation ==
{{code|man earlyoom}}<br><br>
https://www.kernel.org/doc/gorman/html/understand/understand016.html
== Release Notes ==
Earlyoom service is enabled by default, which will cause kernel
oom-killer to trigger sooner. To revert to previous behavior:<br>
{{code|sudo systemctl disable earlyoom.service}}
And to customize see {{code|man earlyoom}}.
--
Ben Cotton
He / Him / His
Fedora Program Manager
Red Hat
TZ=America/Indiana/Indianapolis
3 years, 8 months
z3 soname bump
by Jerry James
I will soon push a change to the z3 package, in Rawhide only, which
will result in an soname bump. The actual contents of libz3 will not
change, however. The only Fedora consumer outside of the z3 package
itself is cppcheck, which currently fails to build due to the recent
cmake change. If the cppcheck maintainers want me to try to fix that,
I will do so; otherwise, I am happy to let them fix it themselves.
The gory details for those interested:
The z3 project has two build systems: an old one, based on generating
Makefiles with python scripts, and a new one based on cmake. We have
been using the old one, because the cmake build system does not
support building z3's OCaml interface. However, the old build system
has a number of ... features ... that we had to work around, leading
to a fair amount of uncleanness in the spec file.
I have decided to take the plunge and switch to using the cmake build
system, with manual steps afterward to build the OCaml interface. The
old build system gave the z3 library an soname of "libz3.so", which
the spec file modified to be "libz3.so.0", with a versioned library
libz3.so.0.0.0. The cmake build system gives the library an soname of
"libz3.so.4.8" (where 4 and 8 are the major and minor version numbers,
respectively), with a versioned library libz3.so.4.8.8.0. This lets
me throw out a bunch of cruft, while introducing a much smaller amount
of cruft due to the OCaml interface. I think it's a win.
--
Jerry James
http://www.jamezone.org/
3 years, 8 months
ar (binutils) segfaulting in Rawhide - known bug?
by Richard W.M. Jones
Just upgraded a development machine to:
binutils-2.34.0-10.fc33.x86_64
gcc-10.1.1-2.fc33.x86_64
glibc-2.31.9000-21.fc33.x86_64
and a very simple C compile (non-LTO) is now segfaulting:
make[3]: Entering directory '/home/rjones/d/nbdkit/common/protocol'
/bin/sh ../../libtool --tag=CC --mode=compile gcc -DHAVE_CONFIG_H -I. -I../.. -Wall -Wshadow -Wvla -Werror -O0 -g -Wp,-U_FORTIFY_SOURCE -MT libprotocol_la-protostrings.lo -MD -MP -MF .deps/libprotocol_la-protostrings.Tpo -c -o libprotocol_la-protostrings.lo `test -f 'protostrings.c' || echo './'`protostrings.c
libtool: compile: gcc -DHAVE_CONFIG_H -I. -I../.. -Wall -Wshadow -Wvla -Werror -O0 -g -Wp,-U_FORTIFY_SOURCE -MT libprotocol_la-protostrings.lo -MD -MP -MF .deps/libprotocol_la-protostrings.Tpo -c protostrings.c -fPIC -DPIC -o .libs/libprotocol_la-protostrings.o
libtool: compile: gcc -DHAVE_CONFIG_H -I. -I../.. -Wall -Wshadow -Wvla -Werror -O0 -g -Wp,-U_FORTIFY_SOURCE -MT libprotocol_la-protostrings.lo -MD -MP -MF .deps/libprotocol_la-protostrings.Tpo -c protostrings.c -o libprotocol_la-protostrings.o >/dev/null 2>&1
mv -f .deps/libprotocol_la-protostrings.Tpo .deps/libprotocol_la-protostrings.Plo
/bin/sh ../../libtool --tag=CC --mode=link gcc -Wall -Wshadow -Wvla -Werror -O0 -g -Wp,-U_FORTIFY_SOURCE -O0 -g -Wp,-U_FORTIFY_SOURCE -o libprotocol.la libprotocol_la-protostrings.lo
libtool: link: ar cru .libs/libprotocol.a .libs/libprotocol_la-protostrings.o
../../libtool: line 1734: 2572327 Segmentation fault (core dumped) ar cru .libs/libprotocol.a .libs/libprotocol_la-protostrings.o
Core was generated by `ar cru .libs/libprotocol.a .libs/libprotocol_la-protostrings.o'.
Program terminated with signal SIGSEGV, Segmentation fault.
#0 0x0000000000000000 in ?? ()
binutils-2.34.0-10.fc33.x86_64
(gdb) bt
Missing separate debuginfos, use: dnf debuginfo-install#0 0x0000000000000000 in ?? ()
#1 0x00007f15bd3e03d0 in make_relative_prefix_1.part ()
from /lib64/libbfd-2.34.0.20200522.so
#2 0x00007f15bd3d22db in bfd_plugin_object_p.lto_priv ()
from /lib64/libbfd-2.34.0.20200522.so
#3 0x00007f15bd3401ce in bfd_check_format_matches ()
from /lib64/libbfd-2.34.0.20200522.so
#4 0x00007f15bd340e7a in _bfd_write_archive_contents ()
from /lib64/libbfd-2.34.0.20200522.so
#5 0x00007f15bd348b2a in bfd_close () from /lib64/libbfd-2.34.0.20200522.so
#6 0x0000559ee83994b6 in write_archive ()
#7 0x0000559ee8396ac3 in main ()
I can't find any BZ for this. Any ideas what it could be?
Rich.
--
Richard Jones, Virtualization Group, Red Hat http://people.redhat.com/~rjones
Read my programming and virtualization blog: http://rwmj.wordpress.com
libguestfs lets you edit virtual machines. Supports shell scripting,
bindings from many languages. http://libguestfs.org
3 years, 8 months
Headsup: dbus 1.12.10-1.fc29 is missing systemd dbus.service file,
breaking almost everything
by Hans de Goede
Hi All,
Just a quick headsup for users following Fedora 29, the
dbus 1.12.10-1.fc29 build is missing the systemd dbus.service
file, breaking almost everything.
Instead it contains a dbus-daemon.service file, but the
dbus.socket file expects a matching dbus.service, not
dbus-daemon.service.
So either hold of on applying updates until this is fixed
or exclude dbus.
Regards,
Hans
3 years, 8 months
No debugsource generated, weird DWARF errors
by Richard W.M. Jones
https://koji.fedoraproject.org/koji/taskinfo?taskID=48101965 fails
with:
error: Empty %files file /builddir/build/BUILD/hevea-2.34/debugsourcefiles.list
However it works when I build locally:
$ rpm -qlp /home/rjones/d/fedora/hevea/master/x86_64/hevea-debugsource-2.34-7.fc33.x86_64.rpm
/usr/src/debug/hevea-2.34-7.fc33.x86_64
/usr/src/debug/hevea-2.34-7.fc33.x86_64/_build
/usr/src/debug/hevea-2.34-7.fc33.x86_64/_build/auxx.ml
/usr/src/debug/hevea-2.34-7.fc33.x86_64/_build/bibhva.ml
/usr/src/debug/hevea-2.34-7.fc33.x86_64/_build/color.ml
[etc]
There's an earlier error which occurs in the Koji build which doesn't
occur for me locally but looks related:
Dwarf Error: wrong version in compilation unit header (is 0, should be 2, 3, 4 or 5) [in module /builddir/build/BUILDROOT/hevea-2.34-7.fc33.x86_64/usr/bin/hacha]
gdb-add-index: No index was created for /builddir/build/BUILDROOT/hevea-2.34-7.fc33.x86_64/usr/bin/hacha
gdb-add-index: [Was there no debuginfo? Was there already an index?]
Did something change with DWARF or gdb in Rawhide that we should be
aware of? Obviously these are not C code and OCaml has its own DWARF
generator.
Rich.
--
Richard Jones, Virtualization Group, Red Hat http://people.redhat.com/~rjones
Read my programming and virtualization blog: http://rwmj.wordpress.com
virt-top is 'top' for virtual machines. Tiny program with many
powerful monitoring features, net stats, disk stats, logging, etc.
http://people.redhat.com/~rjones/virt-top
3 years, 8 months