The PyOpenGL package has been renamed to python-pyopengl on the f24
and master branches, and the Provides have been updated to reflect
current python packaging guidelines. If your package depends on
PyOpenGL, or any of its sub-packages everything will continue to work,
but you should change your Requires lines as follows:
1) PyOpenGL -> python2-pyopengl
2) python3-PyOpenGL -> python3-pyopengl
3) PyOpenGL-Tk -> python2-pyopengl-tk
4) python3-PyOpenGL-Tk -> python3-pyopengl-tk
As I say, no upgrade paths should be broken, as the new package adds
compatibility Provides, but they will be removed in the Fedora 27
Packages affected (maybe incomplete):
qt-creator builds have started to fail, I've reduced the failure down to
having "-isystem /usr/include" in the command line:
$ cat test.cpp
$ g++ -isystem /usr/include -c -o test.o test.cpp
In file included from /usr/include/c++/6.0.0/bits/stl_algo.h:59:0,
/usr/include/c++/6.0.0/cstdlib:75:25: fatal error: stdlib.h: No such
file or directory
Without the -isystem /usr/include, it compiles.
Bug in GCC?
Today (2016-02-29) I received a mail, seemingly having been sent last
night (2016-02-29 01:18 CET), entitled "Your Koji certificate expires
within a week"
--- snip ---
This is an automated email sent to inform you that your Fedora Project Koji
certificate is about to expire. Koji certificates are valid for 6
our records indicate that you last recreated yours about 5 months ago
--- snip ---
OK, no mentioning of a accurate date and probably not taking short
months into account in calculation ;) ... but then, I noticed this:
--- snip ---
# /usr/bin/fedora-cert -v
cert expires: 2016-03-01
WARNING: Your cert expires soon.
--- snip ---
I.e. from the time I read this mail (2016-02-29 ca. 8:30 CET), you gave
me 15 hrs to renew the certificate!
I'd received a notification about new version released:
A new version of "rasmol" has been detected: "2.7.5", packaged as "rasmol"
But current version is:
# rpm -q rasmol
What had gone wrong here?
In the process of adopting the PyOpenGL package, I've updated it to
comply with modern python packaging practices and renamed the package
to python-PyOpenGL. That of course triggers a package review, so if
anyone would like to help me out with that, it's here:
I'll happily review a reasonably simple (preferably python) package in return.
upstream of enki (text editor written in python for Qt) moved to python3-qt5, so there's no need any more for python2-qutepart. Qutepart is the main library of Enki and provides the embedded editor component. We could drop python2/qt4 here and fully go forward with python3-qutepart only.
My question: Does anyone need, use, depend on python2-qutepart? It's built with Qt4 support. Qt4 is dead at upstream development, since several months.
I guess I'm going to drop python2-qutepart when there'll no complains in the next week or so. Please free to give any vote to keep the subpackage in rawhide.
I'm having this weird issue in rawhide / f24 where I get the following
ldd -r /usr/lib64/libsfml-graphics.so
undefined symbol: __cpu_model (/usr/lib64/libsfml-graphics.so)
I've found this out by build failures like this one:
/usr/bin/ld: conftest: hidden symbol `__cpu_model' in /usr/lib/gcc/x86_64-redhat-linux/6.0.0/libgcc.a(cpuinfo.o) is referenced by DSO
/usr/bin/ld: final link failed: Bad value
I've gone closely over the CFLAGS and LDFLAGS for SFML
and the full rpm config flags are used, including
passing -fPIC when building the object files and
passing both -fPIC and -shared when linking the .so file.
I've tracked the root cause of this down to a call
to __builtin_cpu_supports("sse2") in the SFML code,
if I remove that call, all is well.
Any hints on what is going on here appreciated.
Note I already have a fix, SFML only calls
__builtin_cpu_supports("sse2") when building with
-msse2, so the whole call can simply be replaced
by "1", but I still would like to know what
is going on here.