nether dose slack ware jump on the latest bad idea band wagon ie s*d

1 members found this post helpful.

While compiling slackware-current there's still a special case: gst-plugins-base0
I compiles fine on x86_64 but not on x86: need a patch from LFS only for that case.

Another special case: kate
If you try to compile it solely on a pure slackware-current x86 or x86_64, it fails with the following message:
-----------------------
sip: ::KFontChooser ctor argument 5 has an unsupported type for a Python signature - provide a valid type, %MethodCode and a C++ signature
make[2]: *** [addons/kate/pate/sip/CMakeFiles/python_module_PyKate4_kate.dir/build.make:64: addons/kate/pate/sip/kate/sipkatepart0.cpp] Error 1
make[2]: *** Suppression du fichier ��addons/kate/pate/sip/kate/sipkatepart0.cpp��
make[1]: *** [CMakeFiles/Makefile2:3513: addons/kate/pate/sip/CMakeFiles/python_module_PyKate4_kate.dir/all] Error 2
make: *** [Makefile:141: all] Error 2
kdebindings:kate failed to build.
-------------------------
But when you compile it in a complete Slackware From Scratch system, it builds fine by adding the following patch to kate's patch:
-----------------------
cat > cmake-policy.diff << "EOF"
Author: Pino Toscano <pino@debian.org>
Description: Update cmake version & policy.
Set cmake_mininum_required to match kdelibs policy and enable newer cmake
policies.
Forwarded: not-needed
Last-Update: 2016-06-19

--- a/CMakeLists.txt
+++ b/CMakeLists.txt
@@ -1,6 +1,8 @@
# Kate project
project (kate)

+cmake_minimum_required(VERSION 2.8.9)
+
# shared libs
set (LIBRARY_TYPE SHARED)
}
EOF

1 members found this post helpful.

wow, thanks for your work , nobodino!

I wonder if I should mark this thread as resolved, and start a new one, something Slackware CI (continuous integration)
but I do not know how huge the interest on such a topic is

As you wish, it's the last special case I've in my pocket!

Glad to see you got things working and happy. I totally get not wanting to deal with learning then new math all the time. I avoided uefi too until I went NMVE up to that point I used the legacy mode; booting systems off sata. When I switched to nmve I was kinda forced at that point not wanting to deal with altering LILO itself.

I can tell you this. Its a few steps to get elilo working but once it is its super to deal with a working system. So if you take the effort at some point or on some future system to getting EFI to see elilo once you get beyond that point you'd probably find the 'new' to actually be a minor improvement.

Wrong thread, I think.

If you build all of KDE (not just kate), then kate will compile fine on -current. It needs the changes to pykde4 before it will compile.

6 members found this post helpful.

Thanks for the answer. Local source changes in kde are not advisable, too much interactions and dependancies.