BUG:377686
Diff Detail
Diff Detail
- Repository
- R241 KIO
- Branch
- master
- Lint
No Linters Available - Unit
No Unit Test Coverage
Comment Actions
This will have effects on the non-kio users : https://lxr.kde.org/search?_string=kio_http_cache_cleaner
Comment Actions
Well, the kstars hack shouldn't exist and makes me cringe.
But indeed the kate mac-packaging script is a valid case, please get in touch with Christoph Cullmann about it.
The rekonq use case looks valid too but that code doesn't seem really maintained anymore.
Comment Actions
I still question how these installs conflict - as all the scenarios where they could conflict should already be taken into account:
- Linux distros, FreeBSD, etc have no co-installability issues here
- Windows installs should be one prefix per application, which means KF5 and KDE 4 installs should never collide
- macOS is basically the same as Windows, only difference being it's a .app bundle instead
Can you provide some background please Ralf?
Note that the CI already has native Umbrello builds for Windows so cross compilation shouldn't be required.
Comment Actions
see below
Note that the CI already has native Umbrello builds for Windows so cross compilation shouldn't be required.
Relating to the jenkins based system: How can I check build internals in case of hidden build issues ? From my 16 year porting KDE experience (https://en.wikipedia.org/wiki/KDE_on_Cygwin) - because of the number of related packages, build systems and possible configuration - this is required often and could not be provided by a build log. You need to inspect for example cmake generated files like include_cxx.rsp which contains the used include directories (a real world example is https://phabricator.kde.org/D9404)
Therefore I'm using obs build service. After installing osc (https://en.opensuse.org/openSUSE:OSC) on a linux machine, I run
osc co home:rhabacker:branches:windows:mingw:win32:KF541/mingw32-kio cd home:rhabacker:branches:windows:mingw:win32:KF541/mingw32-kio osc build
In case of errors I run
osc chroot
to enter the chrooted build environment
to enter package source dir I enter
cd /home/abuild/rpmbuild/BUILD/kio-5.41.0
to enter package source dir I use
cd /home/abuild/rpmbuild/BUILD/kio-5.41.0/build
to continue broken build I run
cd /home/abuild/rpmbuild/BUILD/kio-5.41.0/build make
I can edit files, clean builds, restart build, make patches to fix issues in build system and so one
Doe KDE CI provide shell access to the complete build infrastructure like installed 3rdparty packages, source and build files ?
Comment Actions
In regards to needing to inspect the build directory (which is something we rarely get asked for) the system automatically tarballs a copy of the entire workspace (which includes the source code and build directory) whenever a build fails or has failing tests. These tarballs can be found at https://build-artifacts.kde.org/production/Workspaces/ (filenames match the job name on Jenkins itself). "Hidden build issues" aren't something we've really come across when standing up the native Windows CI system.
Most dependencies are provided by Craft (with Git and Python being the notable exceptions there). The "list file" which controls what Craft packages we install can be found at https://cgit.kde.org/sysadmin/ci-tooling.git/tree/craftmaster/packages.list. We rely on the publicly accessible Craft cache packages, so anyone can replicate the CI setup on their system relatively easily. The Binary Factory also uses the same Craft Cache for it's binaries (and the Binary Factory generates usable binaries for many KDE applications already) and the Binary Factory is also responsible for populating that Craft Cache.
For various reasons it's totally inpractical for us to provide remote shell access to the CI infrastructure. In the case of Linux builds you can download the Docker images and run them locally. For FreeBSD and Windows you'll have to rely on the tarballs.
Also note that we won't be signing any binaries which are not generated by the Binary Factory.