[opensuse-factory] Package Removal announcement: eletra
Hi everybody, I'd like to inform you that the package 'elektra' will be removed from openSUSE:Factory if nobody cares to fix it. This package has not had a successful build since May 2020 - 6 months grace period sounds like enough to justify its removal. This will have a few side-effects to other packages, that must also be removed, as they depend on elektra (but are currently not installable, due to elektra requiring libraries that no longer exist for a while already) So, the packages in question to be removed will be: * elektra * oyranos (color management system, depends on elektra) * icc-examin (depends on oyranos) * synnefo (depends on oyranos) * kolor-manager * xcm There is potentially more showing up, based on what the bot finds which I did not yet see, but this should give some information as to what is going to happen. Cheers, Dominique PS: of course, if somebody volunteers and commits to fixing elektra,we can consider keeping it around. There are like 10 version updates available upstream - which shows tha maintenance is not high up on this package.
Am Dienstag, 24. November 2020, 09:29:30 CET schrieb Dominique Leuenberger / DimStar:
Hi everybody,
I'd like to inform you that the package 'elektra' will be removed from openSUSE:Factory if nobody cares to fix it.
This package has not had a successful build since May 2020 - 6 months grace period sounds like enough to justify its removal.
I've started to fix the package, choose 0.8.26 as base version since the 0.9 series changes/changed API, available here: home:frispete:Tumbleweed/elektra But now, I got stuck with: [ 9s] -- Configuring done [ 9s] CMake Error at src/bindings/io/uv/CMakeLists.txt:76 (add_executable): [ 9s] Error evaluating generator expression: [ 9s] [ 9s] $<TARGET_OBJECTS:cframework> [ 9s] [ 9s] Objects of target "cframework" referenced but no such target exists. [ 9s] [ 9s] [ 9s] CMake Error at src/bindings/io/glib/CMakeLists.txt:59 (add_executable): [ 9s] Error evaluating generator expression: [ 9s] [ 9s] $<TARGET_OBJECTS:cframework> [ 9s] [ 9s] Objects of target "cframework" referenced but no such target exists. [ 9s] [ 9s] [ 9s] CMake Error at benchmarks/CMakeLists.txt:8 (add_executable): [ 9s] Error evaluating generator expression: [ 9s] [ 9s] $<TARGET_OBJECTS:cframework> [ 9s] [ 9s] Objects of target "cframework" referenced but no such target exists. [ 9s] Call Stack (most recent call first): [ 9s] benchmarks/CMakeLists.txt:36 (do_benchmark) [ 9s] [ 9s] [ 9s] CMake Error at benchmarks/CMakeLists.txt:8 (add_executable): [ 9s] Error evaluating generator expression: [ 9s] [ 9s] $<TARGET_OBJECTS:cframework> [ 9s] [ 9s] Objects of target "cframework" referenced but no such target exists. [ 9s] Call Stack (most recent call first): [ 9s] benchmarks/CMakeLists.txt:53 (do_benchmark) [ 9s] [ 9s] [ 9s] CMake Error at src/bindings/io/uv/CMakeLists.txt:76 (add_executable): [ 9s] Error evaluating generator expression: [ 9s] [ 9s] $<TARGET_OBJECTS:cframework> [ 9s] [ 9s] Objects of target "cframework" referenced but no such target exists. [ 9s] [ 9s] [ 9s] CMake Error at src/bindings/io/glib/CMakeLists.txt:59 (add_executable): [ 9s] Error evaluating generator expression: [ 9s] [ 9s] $<TARGET_OBJECTS:cframework> [ 9s] [ 9s] Objects of target "cframework" referenced but no such target exists. [ 9s] [ 9s] [ 9s] CMake Error at benchmarks/CMakeLists.txt:8 (add_executable): [ 9s] Error evaluating generator expression: [ 9s] [ 9s] $<TARGET_OBJECTS:cframework> [ 9s] [ 9s] Objects of target "cframework" referenced but no such target exists. [ 9s] Call Stack (most recent call first): [ 9s] benchmarks/CMakeLists.txt:36 (do_benchmark) [ 9s] [ 9s] [ 9s] CMake Error at benchmarks/CMakeLists.txt:8 (add_executable): [ 9s] Error evaluating generator expression: [ 9s] [ 9s] $<TARGET_OBJECTS:cframework> [ 9s] [ 9s] Objects of target "cframework" referenced but no such target exists. [ 9s] Call Stack (most recent call first): [ 9s] benchmarks/CMakeLists.txt:53 (do_benchmark) [ 9s] [ 9s] [ 9s] CMake Error at src/bindings/io/uv/CMakeLists.txt:76 (add_executable): [ 9s] No SOURCES given to target: testio_uv [ 9s] [ 9s] [ 9s] CMake Error at src/bindings/io/glib/CMakeLists.txt:59 (add_executable): [ 9s] No SOURCES given to target: testio_glib [ 9s] [ 9s] [ 9s] CMake Error at benchmarks/CMakeLists.txt:8 (add_executable): [ 9s] No SOURCES given to target: benchmark_storage [ 9s] Call Stack (most recent call first): [ 9s] benchmarks/CMakeLists.txt:36 (do_benchmark) [ 9s] [ 9s] [ 9s] CMake Error at benchmarks/CMakeLists.txt:8 (add_executable): [ 9s] No SOURCES given to target: benchmark_opmphm [ 9s] Call Stack (most recent call first): [ 9s] benchmarks/CMakeLists.txt:53 (do_benchmark) [ 9s] [ 9s] [ 9s] CMake Generate step failed. Build files cannot be regenerated correctly. [ 9s] error: Bad exit status from /var/tmp/rpm-tmp.BfQx3Y (%build) This was mentioned for master branch in https://github.com/ElektraInitiative/libelektra/issues/3452 The proposed workaround doesn't work for us, though: -DBINDINGS="MAINTAINED;-intercept_env;-intercept_fs;-io_uv;-io_ev;-io_glib" I'm running out of time right now, and would be glad, if somebody could pick up from here. Cheers, Pete
Hi Pete, On Tue, 2020-11-24 at 15:26 +0100, Hans-Peter Jansen wrote:
Am Dienstag, 24. November 2020, 09:29:30 CET schrieb Dominique Leuenberger / DimStar:
Hi everybody,
I'd like to inform you that the package 'elektra' will be removed from openSUSE:Factory if nobody cares to fix it.
This package has not had a successful build since May 2020 - 6 months grace period sounds like enough to justify its removal.
I've started to fix the package, choose 0.8.26 as base version since the 0.9 series changes/changed API, available here:
home:frispete:Tumbleweed/elektra
Thanks for picking this up!
But now, I got stuck with:
This was mentioned for master branch in https://github.com/ElektraInitiative/libelektra/issues/3452 The proposed workaround doesn't work for us, though: -DBINDINGS="MAINTAINED;-intercept_env;-intercept_fs;-io_uv;-io_ev;-io_glib"
Acording to that tickte, the issues comes bundled with BUILD_TESTING=OFF; do we forcibly need that? Can we just drop this cmake parameter? What other problems do we run into? cheers, Dominique
El martes, 24 de noviembre de 2020 15:47:03 (CET) Dominique Leuenberger / DimStar escribió:
Hi Pete,
On Tue, 2020-11-24 at 15:26 +0100, Hans-Peter Jansen wrote:
Am Dienstag, 24. November 2020, 09:29:30 CET schrieb Dominique Leuenberger /> DimStar:
Hi everybody,
I'd like to inform you that the package 'elektra' will be removed from openSUSE:Factory if nobody cares to fix it.
This package has not had a successful build since May 2020 - 6 months grace period sounds like enough to justify its removal.
I've started to fix the package, choose 0.8.26 as base version since the 0.9 series changes/changed API, available here:
home:frispete:Tumbleweed/elektra
Thanks for picking this up!
But now, I got stuck with:
This was mentioned for master branch in https://github.com/ElektraInitiative/libelektra/issues/3452 The proposed workaround doesn't work for us, though: -DBINDINGS="MAINTAINED;-intercept_env;-intercept_fs;-io_uv;-io_ev;-io_g lib" Acording to that tickte, the issues comes bundled with BUILD_TESTING=OFF; do we forcibly need that? Can we just drop this cmake parameter? What other problems do we run into?
I have compiled 0.9.3 successfully with "-DBINDINGS=MAINTAINED; -io_glib" Some bindings aren't built due to dependencies not found (next step). Please check SR #850587. Cheers, -- Javier Llorente
Am Dienstag, 24. November 2020, 19:32:58 CET schrieb Javier Llorente:
El martes, 24 de noviembre de 2020 15:47:03 (CET) Dominique Leuenberger /
DimStar escribió:
Hi Pete,
On Tue, 2020-11-24 at 15:26 +0100, Hans-Peter Jansen wrote:
Am Dienstag, 24. November 2020, 09:29:30 CET schrieb Dominique Leuenberger />
DimStar:
Hi everybody,
I'd like to inform you that the package 'elektra' will be removed from openSUSE:Factory if nobody cares to fix it.
This package has not had a successful build since May 2020 - 6 months grace period sounds like enough to justify its removal.
I've started to fix the package, choose 0.8.26 as base version since the
0.9 series changes/changed API, available here: home:frispete:Tumbleweed/elektra
Thanks for picking this up!
But now, I got stuck with:
This was mentioned for master branch in
https://github.com/ElektraInitiative/libelektra/issues/3452
The proposed workaround doesn't work for us, though: -DBINDINGS="MAINTAINED;-intercept_env;-intercept_fs;-io_uv;-io_ev;-io _g
lib"
Acording to that tickte, the issues comes bundled with BUILD_TESTING=OFF; do we forcibly need that? Can we just drop this cmake parameter? What other problems do we run into?
I have compiled 0.9.3 successfully with "-DBINDINGS=MAINTAINED; -io_glib" Some bindings aren't built due to dependencies not found (next step). Please check SR #850587.
Since quite some packages depend on this, and you moved on into unstable API land, you should check them as well, shouldn't you? I have 0.8.26 build mostly fine now. SR #850590. Cheers, Pete
El martes, 24 de noviembre de 2020 19:45:27 (CET) Hans-Peter Jansen escribió:
Am Dienstag, 24. November 2020, 19:32:58 CET schrieb Javier Llorente:
El martes, 24 de noviembre de 2020 15:47:03 (CET) Dominique Leuenberger /
DimStar escribió:
Hi Pete,
On Tue, 2020-11-24 at 15:26 +0100, Hans-Peter Jansen wrote:
Am Dienstag, 24. November 2020, 09:29:30 CET schrieb Dominique Leuenberger />
DimStar:
Hi everybody,
I'd like to inform you that the package 'elektra' will be removed from openSUSE:Factory if nobody cares to fix it.
This package has not had a successful build since May 2020 - 6 months grace period sounds like enough to justify its removal.
I've started to fix the package, choose 0.8.26 as base version since the
0.9 series changes/changed API, available here:
home:frispete:Tumbleweed/elektra
Thanks for picking this up!
But now, I got stuck with:
This was mentioned for master branch in
https://github.com/ElektraInitiative/libelektra/issues/3452
The proposed workaround doesn't work for us, though:
-DBINDINGS="MAINTAINED;-intercept_env;-intercept_fs;-io_uv;-io_ev;- io _g
lib"
Acording to that tickte, the issues comes bundled with BUILD_TESTING=OFF; do we forcibly need that? Can we just drop this cmake parameter? What other problems do we run into?
I have compiled 0.9.3 successfully with "-DBINDINGS=MAINTAINED; -io_glib" Some bindings aren't built due to dependencies not found (next step). Please check SR #850587.
Since quite some packages depend on this, and you moved on into unstable API land, you should check them as well, shouldn't you?
Well, isn't Factory about having the latest & greatest? :-P I haven't tested it but yes, it comes with some changes that could break builds.
I have 0.8.26 build mostly fine now. SR #850590.
Excellent. If needed, we could have two packages, one with 0.8.x and another one with 0.9.x. Greetings, -- Javier Llorente
Am Dienstag, 24. November 2020, 20:25:59 CET schrieb Javier Llorente:
El martes, 24 de noviembre de 2020 19:45:27 (CET) Hans-Peter Jansen escribió:
Am Dienstag, 24. November 2020, 19:32:58 CET schrieb Javier Llorente:
I have compiled 0.9.3 successfully with "-DBINDINGS=MAINTAINED; -io_glib" Some bindings aren't built due to dependencies not found (next step). Please check SR #850587.
Since quite some packages depend on this, and you moved on into unstable API> land, you should check them as well, shouldn't you?
Well, isn't Factory about having the latest & greatest? :-P I haven't tested it but yes, it comes with some changes that could break builds.
I have 0.8.26 build mostly fine now. SR #850590.
Excellent. If needed, we could have two packages, one with 0.8.x and another one with 0.9.x.
SR #850668 is down to 5 warnings now. @Dominique, what about starting with this one. It's looking fine now. @Javier, would you build some of the dependent packages in your branch so see, how this goes? You might want to rebase to my spec (given, Dominique will accept it), since it uses build conditionals now, and has been cleaned from some crude artifacts. Cheers, Pete
El miércoles, 25 de noviembre de 2020 10:05:21 (CET) Hans-Peter Jansen escribió:
Am Dienstag, 24. November 2020, 20:25:59 CET schrieb Javier Llorente:
El martes, 24 de noviembre de 2020 19:45:27 (CET) Hans-Peter Jansen
escribió:
Am Dienstag, 24. November 2020, 19:32:58 CET schrieb Javier Llorente:
I have compiled 0.9.3 successfully with "-DBINDINGS=MAINTAINED; -io_glib" Some bindings aren't built due to dependencies not found (next step). Please check SR #850587.
Since quite some packages depend on this, and you moved on into unstable API>
land, you should check them as well, shouldn't you?
Well, isn't Factory about having the latest & greatest? :-P I haven't tested it but yes, it comes with some changes that could break builds.
I have 0.8.26 build mostly fine now. SR #850590.
Excellent. If needed, we could have two packages, one with 0.8.x and another one with 0.9.x.
SR #850668 is down to 5 warnings now.
@Dominique, what about starting with this one. It's looking fine now. @Javier, would you build some of the dependent packages in your branch so see, how this goes? You might want to rebase to my spec (given, Dominique will accept it), since it uses build conditionals now, and has been cleaned from some crude artifacts.
Nice. It's much cleaner now :) I have rebased my spec and was wondering why you aren't building some bindings, such as jna or python. Shouldn't we use %define instead of %bcond_* in this case? I also suggest you adding another section for ruby (it's missing). Cheers, -- Javier Llorente
Am Donnerstag, 26. November 2020, 13:56:51 CET schrieb Javier Llorente:
El miércoles, 25 de noviembre de 2020 10:05:21 (CET) Hans-Peter Jansen
SR #850668 is down to 5 warnings now.
@Dominique, what about starting with this one. It's looking fine now. @Javier, would you build some of the dependent packages in your branch so see, how this goes? You might want to rebase to my spec (given, Dominique will accept it), since it uses build conditionals now, and has been cleaned from some crude artifacts.
Nice. It's much cleaner now :)
Thanks for the flowers, Javier.
I have rebased my spec and was wondering why you aren't building some bindings, such as jna or python.
jna: lazyness (we're not friends, java and me ;-) python: due to linking issues of this build (just branch and osc build --with swig to see yourself): [ 137s] /usr/bin/c++ -fPIC -std=c++11 -Wno-deprecated-declarations -Wold- style-cast -Wstrict-null-sentinel -D_GLIBCXX_USE_NANOSLEEP -Wno-missing-field- initializers -Woverloaded-virtual -Wsign-promo -Wno-long-long -Wpedantic - Wno-variadic-macros -Wall -Wextra -Wno-overlength-strings -Wsign-compare - Wfloat-equal -Wformat -Wformat-security -Wshadow -Wcomments -Wtrigraphs - Wundef -Wuninitialized -Winit-self -Wmaybe-uninitialized -O2 -g -DNDEBUG - Wl,--allow-multiple-definition -rdynamic CMakeFiles/testmod_python.dir/python/ testmod_python.c.o ../../tests/cframework/CMakeFiles/cframework.dir/tests.c.o ../plugins/python/CMakeFiles/elektra-python-objects.dir/python.cpp.o -o ../../ bin/testmod_python -Wl,-rpath,/home/abuild/rpmbuild/BUILD/elektra-0.8.26/ build/lib: ../../lib/libelektra-kdb.so.0.8.26 ../../lib/libelektra- pluginprocess.so.0.8.26 -lgtest -lpython3 ../../lib/libelektra-plugin.so. 0.8.26 ../../lib/libelektra-invoke.so.0.8.26 ../../lib/libelektra-core.so. 0.8.26 ../../lib/libelektra.so.0.8.26 -ldl [ 137s] /usr/lib64/gcc/x86_64-suse-linux/10/../../../../x86_64-suse-linux/ bin/ld: ../plugins/python/CMakeFiles/elektra-python-objects.dir/python.cpp.o: undefined reference to symbol 'PyErr_Restore' [ 137s] /usr/lib64/gcc/x86_64-suse-linux/10/../../../../x86_64-suse-linux/ bin/ld: /usr/lib64/libpython3.8.so.1.0: error adding symbols: DSO missing from command line
Shouldn't we use %define instead of %bcond_* in this case?
I don't get you here. The major difference between those is, defines are value based, while bconds are existence-based, iow. it's enough to define one leg and get the other for free..
I also suggest you adding another section for ruby (it's missing).
Again: lazyness Cheers, Pete
El jueves, 26 de noviembre de 2020 17:38:55 (CET) Hans-Peter Jansen escribió:
Am Donnerstag, 26. November 2020, 13:56:51 CET schrieb Javier Llorente:
El miércoles, 25 de noviembre de 2020 10:05:21 (CET) Hans-Peter Jansen
SR #850668 is down to 5 warnings now.
@Dominique, what about starting with this one. It's looking fine now. @Javier, would you build some of the dependent packages in your branch so see, how this goes? You might want to rebase to my spec (given, Dominique will accept it), since it uses build conditionals now, and has been cleaned from some crude artifacts.
Nice. It's much cleaner now :)
Thanks for the flowers, Javier.
I have rebased my spec and was wondering why you aren't building some bindings, such as jna or python.
jna: lazyness (we're not friends, java and me ;-) python: due to linking issues of this build (just branch and osc build --with swig to see yourself):
[ 137s] /usr/bin/c++ -fPIC -std=c++11 -Wno-deprecated-declarations -Wold-style-cast -Wstrict-null-sentinel -D_GLIBCXX_USE_NANOSLEEP -Wno-missing-field- initializers -Woverloaded-virtual -Wsign-promo -Wno-long-long -Wpedantic - Wno-variadic-macros -Wall -Wextra -Wno-overlength-strings -Wsign-compare - Wfloat-equal -Wformat -Wformat-security -Wshadow -Wcomments -Wtrigraphs - Wundef -Wuninitialized -Winit-self -Wmaybe-uninitialized -O2 -g -DNDEBUG - Wl,--allow-multiple-definition -rdynamic CMakeFiles/testmod_python.dir/python/ testmod_python.c.o ../../tests/cframework/CMakeFiles/cframework.dir/tests.c.o ../plugins/python/CMakeFiles/elektra-python-objects.dir/python.cpp.o -o ../../ bin/testmod_python -Wl,-rpath,/home/abuild/rpmbuild/BUILD/elektra-0.8.26/ build/lib: ../../lib/libelektra-kdb.so.0.8.26 ../../lib/libelektra- pluginprocess.so.0.8.26 -lgtest -lpython3 ../../lib/libelektra-plugin.so. 0.8.26 ../../lib/libelektra-invoke.so.0.8.26 ../../lib/libelektra-core.so. 0.8.26 ../../lib/libelektra.so.0.8.26 -ldl [ 137s] /usr/lib64/gcc/x86_64-suse-linux/10/../../../../x86_64-suse-linux/ bin/ld: ../plugins/python/CMakeFiles/elektra-python-objects.dir/python.cpp.o: undefined reference to symbol 'PyErr_Restore' [ 137s] /usr/lib64/gcc/x86_64-suse-linux/10/../../../../x86_64-suse-linux/ bin/ld: /usr/lib64/libpython3.8.so.1.0: error adding symbols: DSO missing from command line
I see ;-(
Shouldn't we use %define instead of %bcond_* in this case?
I don't get you here. The major difference between those is, defines are value based, while bconds are existence-based, iow. it's enough to define one leg and get the other for free..
If our goal is to have lots of subpackages on OBS, I would use %define. If binding A doesn't compile, set the %define to 0. If fixed, no need to change the %bcond_* to %define. Just set it to 1. But it's just my personal opinion ;)
I also suggest you adding another section for ruby (it's missing).
Again: lazyness
Same here x) In other news, I got an error (and many warnings) when I tried to compile oyranos 0.9.6 against elektra 0.9.3. The latest version (0.9.6) was released back in 2016. AFAIK, oyranos is the only package in the multimedia:color_management repository that requires elektra. I am not sure if we need elektra 0.8.26 for oyranos. I would have to dig deeper; [ 62s] /home/abuild/rpmbuild/BUILD/oyranos-0.9.6/src/modules/color/modules/ oyranos_cmm_elDB.c:801:42: error: 'KDB_VERSION_MICRO' undeclared here (not in a function); did you mean 'KDB_VERSION_MINOR'? Cheers, -- Javier Llorente
participants (3)
-
Dominique Leuenberger / DimStar -
Hans-Peter Jansen -
Javier Llorente