- 08 Nov, 2020 1 commit
-
-
It's used by neochat
-
- 07 Nov, 2020 1 commit
-
-
David Faure authored
This stuff about repo paths used to be less confusing...
-
- 31 Oct, 2020 1 commit
-
-
Carl Schwan authored
-
- 25 Oct, 2020 1 commit
-
-
Script Kiddy authored
-
- 24 Oct, 2020 1 commit
-
-
Script Kiddy authored
-
- 11 Oct, 2020 2 commits
-
-
Michael Pyne authored
In the event that the stash does not apply a "post-build" message is issued to warn the user. Otherwise there is an in-situ message. This addresses user feedback I have received on Invent and IRC. In particular re-fixes #42 and bug 420933, and fixes #49. All that I do here is to use the existing logic and add "git stash pop" after the update phase has completed. I've previously tried --autostash (see !32 and !45) and that had issues of its own. Using this approach allows us to use rely on git directly without risk of missing a merge conflict that git sometimes seems to generate with `git pull --autostash` (see sdk/kdesrc-build!32 (comment 46926)). The merge request !61 may still be applicable. I haven't looked long enough to tell if there's more on it than the --autostash feature which still causes us problems... it's possible that there's a more reliable method than what we're doing though we've already taken pains to simplify this routine because of the recurring stash failures that we've seen previously. BUG:420933
-
David Faure authored
-
- 06 Oct, 2020 1 commit
-
-
Nicolas Fella authored
It is only used for libdbusmenu-qt, which isn't built by default any more.
-
- 27 Sep, 2020 3 commits
-
-
Michael Pyne authored
This change should address the immediate breakage that a user had when using kdesrc-build-setup, choosing no major module groups, and then using kdesrc-build to eventually build bluez-qt. In that case, bluez-qt had an 'options' block in kf5-frameworks-build-include to address the error he'd experienced, however since kdesrc-build-setup didn't generate a include to that file, the options weren't picked up either. kdesrc-build later found the module via include-dependencies and built it anyways. To fix this, break out "always-set" options into a dedicated file (kf5-common-options-build-include) and include that from kdesrc-build-setup-generated files always. I moved these from kf5-frameworks-build-include so I added an include from that file back to kf5-common-options-build-include for backwards compatibility for existing users. This relies on duplicate options blocks continuing to work (similar to C++'s One Definition Rule) s...
-
Michael Pyne authored
My hope is to make it easier for new users to understand how to add module groups if they are desired later, since there has previously been no generated note or warning in the generated kdesrc-buildrc if the user chose no major groups. In this case we had a user who, even though they didn't select any module groups, still had kdesrc-build trying to build bluez-qt due to include-dependencies being set to 'true' (the default). However bluez-qt needs a CMake option to be passed to build with kdesrc-build; this option isn't set unless the kf5-frameworks-build-include file is read in. That fix will happen in a separate commit, this should hopefully make it easier to read through the generated kdesrc-buildrc in any case. CCBUG:426219
-
Michael Pyne authored
This seems needed for some KF5 modules (especially using QtWayland) and is where I expect most Qt5 bugfixes to land while everyone is working on Qt6/KF6.
-
- 20 Sep, 2020 1 commit
-
-
They are required for kaidan and qrca.
-
- 19 Sep, 2020 1 commit
-
-
Script Kiddy authored
-
- 10 Sep, 2020 1 commit
-
-
Script Kiddy authored
-
- 05 Sep, 2020 1 commit
-
-
David Faure authored
-
- 01 Sep, 2020 1 commit
-
-
Script Kiddy authored
-
- 23 Aug, 2020 1 commit
-
-
Michael Pyne authored
The sample xsession/environment setup shell script has to figure how where CMake is going to install the libraries that kdesrc-build builds, so that it may setup the proper override paths in the environment. These library names are a cornucopia of names across various Linux distros. Some systems have /usr/lib, others use /usr/lib64, some use both, some use /usr/lib and /usr/lib32, and still others use a combo of all three, with /usr/lib having the "right" libraries and one of the other specific paths being a symlink back to /usr/lib if appropriate. In this latter situation our script guesses the wrong library name, with predicable failures from there. This breaks Arch Linux if users don't know to fix the session driver that kdesrc-build installs. The fix here is simple, we only treat /usr/lib64 as the authoritative library path if it isn't a symlink elsewhere. Otherwise we use /usr/lib as normal and assume that CMake itself will...
-
- 16 Aug, 2020 3 commits
-
-
Michael Pyne authored
This was all replaced with Getopt::Long years ago but I missed this during that refactoring.
-
Michael Pyne authored
For now it's only commented out but the module hasn't changed in many years so there's really no need for kdesrc-build to have to build it. It should be installed from -devel packages instead as we do with other distro dependencies. I've commented it out for now as an indicator this was deliberate, but I've taken the liberty of updating the distros in ksb::FirstRun as appears to be appropriate. After a few weeks we can remove the commented section as dead code. See issue #53.
-
Michael Pyne authored
eg. if we're cloning libdbusmenu-qt into ~/kde/src/libdbusmenu-qt, the bzr command should be run from ~/kde/src, not ~/kde/src/RANDOM_OTHER_MODULE as apparently is already happening. I believe this fixes #53, if it doesn't please reopen. My distro doesn't package bzr anymore so I will remove our usage in a separate commit but will maintain Updater/Bzr.pm for at least a few more months with prior warning of deprecation. But I will need help testing :)
-
- 15 Aug, 2020 1 commit
-
-
- 13 Aug, 2020 1 commit
-
-
Script Kiddy authored
In case of conflict in i18n, keep the version of the branch "ours" To resolve a particular conflict, "git checkout --ours path/to/file.desktop"
-
- 05 Aug, 2020 1 commit
-
-
Nicolás Alvarez authored
Replace repository URLs for taglib, poppler, qtspeech and telepathy-qt to use HTTPS instead of unencrypted git:// URLs. Fixes #50
-
- 03 Aug, 2020 1 commit
-
-
Marco Martin authored
kirigami is a framework now, doesn't need its own definition
-
- 02 Aug, 2020 1 commit
-
-
Michael Pyne authored
Closes !55, which has diverged from master since I've been able to approve it.
-
- 27 Jul, 2020 2 commits
- 19 Jul, 2020 1 commit
-
-
Script Kiddy authored
-
- 18 Jul, 2020 2 commits
-
-
Luis Kao authored
- Respect ZDOTDIR env variable when updating shell rc. - Prompt user to ask for updating shell rc-file. - Make messages more detailed.
-
Script Kiddy authored
-
- 17 Jul, 2020 2 commits
-
-
Script Kiddy authored
In case of conflict in i18n, keep the version of the branch "ours" To resolve a particular conflict, "git checkout --ours path/to/file.desktop"
-
Script Kiddy authored
-
- 16 Jul, 2020 1 commit
-
-
Michael Pyne authored
-
- 12 Jul, 2020 1 commit
-
-
Michael Pyne authored
It is annoying to be maintaining kdesrc-build-setup and --initial-setup but combining those two can be a subsequent refactoring. This adds a separate num-cores-low-mem to address the qtwebengine case and makes both num-cores and num-cores-low-mem into an option generated during initial setup, and only used by the default config (rather than any part of the kdesrc-build internals directly). There is a fallback reference in the code in case there is a usage of the default configuration file sections (e.g. qt5-build-include) but this is set conservatively (4 cores, 2 cores during low-mem). At this point it's almost "just" a configuration convention with a bit of code in the setup wizard so perhaps it's best not to touch the rest of the code/docs at all, but I'm happy with where this is at. I've tested --initial-setup in a Docker container (Fedora 29 with perl manually installed first) and tested kdesrc-build-setup separately.
-
- 08 Jul, 2020 2 commits
-
-
Michael Pyne authored
I was off by a few days but 20.06 feels better than 20.07, so here we go anyways. It's cosmetic only at this point anyways.
-
Michael Pyne authored
-
- 07 Jul, 2020 2 commits
-
-
Michael Pyne authored
This change introduces a "num-cpus" option that is inherently present in the build context. This permits config file reading code to refer to this option (due to an existing kdesrc-build feature). So I also update the various available methods of generating a default configuration to use this option instead of hardcoding a -j value for make-options (or leaving it blank). This should provide maximum performance for most users (who aren't using or can't use the existing Ninja support, anyways), as long as they are able to start from a generated configuration. Users with existing configuration files would need to regenerate it or edit it to add "make-options -j ${num-cpus}" (including separately to their Qt5 options if applicable, as global options are ignored for non-KDE modules). See issue #39.
-
Michael Pyne authored
With the advent of Qt6 development, the pace of Qt5 has slowed enough that we can now rely on distribution packages being available and up to date for Plasma development. Since Qt5 remains a significant pain point for kdesrc-build users, we shouldn't inflict this requirement by default for new users.
-
- 06 Jul, 2020 2 commits
-
-
gpgme 1.13.1 (released in 2019) works fine.
-
Johan Ouwerkerk authored
Previously we incurred additional network I/O due to git pull (for reasons to do with a bug in certain git versions). However, with the new stash logic we can assume a clean checkout and so an update should always be a simple fast-forward to the remote HEAD.
-