1. 18 Jul, 2020 1 commit
  2. 17 Jul, 2020 2 commits
  3. 16 Jul, 2020 1 commit
  4. 12 Jul, 2020 1 commit
    • Michael Pyne's avatar
      rc-file: Add "num-cores-low-mem" and move num-cores* defs to initial-setup. · 654e1392
      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.
      654e1392
  5. 08 Jul, 2020 2 commits
  6. 07 Jul, 2020 2 commits
    • Michael Pyne's avatar
      rc-file: Add "num-cpus" option by default and use it in default setup. · 57e6c0c3
      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.
      57e6c0c3
    • Michael Pyne's avatar
      qt5: Remove from default build (kdesrc-build-setup and --initial-setup). · 646039b7
      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.
      646039b7
  7. 06 Jul, 2020 5 commits
    • Bernie Innocenti's avatar
      Don't build gpgme from git master · 36975cfe
      Bernie Innocenti authored
      gpgme 1.13.1 (released in 2019) works fine.
      36975cfe
    • Johan Ouwerkerk's avatar
      Take advantage of new stash logic to optimise the update step. · 5373794e
      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.
      5373794e
    • Johan Ouwerkerk's avatar
      Another attempt to 'fix' kdesrc-build's stash logic. · ccd8d4cf
      Johan Ouwerkerk authored
      This attempt takes the "simpler is better" approach:
      
       - Always attempt to stash (including untracked files as well)
       - Warn if it turns out that something was actually stashed
       - Never pop stashes
       - Leave it up to the user to recover the stashed changes and fold them into the updated clone.
      
      Essentially kdesrc-build becomes a lot more opinionated/strict about using --no-src.
      Previously, there were various situations where --no-src was not strictly necessary to build with local changes, now these have all been eliminated.
      There should really be no way anymore to build with a dirty checkout/clone now, except via --no-src.
      
      Issues: #42
      ccd8d4cf
    • Bernie Innocenti's avatar
      kf5-base-applications: Drop khelpcenter · a3087796
      Bernie Innocenti authored
      KHelpCenter isn't needed for a minimal desktop build. When khelpcenter
      is not installed, the various "Help" buttons in apps will simply open
      the online version of the documentation in the default browser.
      a3087796
    • Johan Ouwerkerk's avatar
      Explicitly build Qt in -release mode · 930114d6
      Johan Ouwerkerk authored
      Previously -release mode was the implied default, with this change it is explicitly selected for.
      Additionally -optimized-tools is removed because the Qt configure log notes that this is redundant.
      930114d6
  8. 05 Jul, 2020 2 commits
  9. 04 Jul, 2020 1 commit
  10. 01 Jul, 2020 1 commit
  11. 30 Jun, 2020 2 commits
  12. 20 Jun, 2020 3 commits
  13. 18 Jun, 2020 2 commits
  14. 17 Jun, 2020 2 commits
  15. 06 Jun, 2020 1 commit
  16. 31 May, 2020 1 commit
  17. 30 May, 2020 1 commit
  18. 28 May, 2020 3 commits
    • Adriaan de Groot's avatar
      Output generic vendor name rather than 'linux'. · 30bc380e
      Adriaan de Groot authored
      The output "linux distribution" doesn't make sense when it's actually
      FreeBSD; shuffle the message a little and put the identifier that
      comes back from os-release in parenthesis. This makes the output
      on FreeBSD consistent and won't scare weird-distro people (they
      know it's a linux, right?)
      30bc380e
    • Adriaan de Groot's avatar
      Call a spade a spade · 996916fd
      Adriaan de Groot authored
      When run on FreeBSD, with os-release saying that this is a FreeBSD
      system, since there's no distro-match it ends up being called a Linux.
      This changes the fallback / generic return from bestDistroMatch()
      to handle non-Linuxes (leaves space for haiku or openBSD).
      
      ```
       - Installing system packages for freebsd...
          Installing packages for freebsd/12.0
      ```
      996916fd
    • Adriaan de Groot's avatar
      Not an error if there's no os-release · 4f5fb910
      Adriaan de Groot authored
      As FreeBSD demonstrated (with the bug in truthiness-of-$fh)
      it's not an error to have no os-release, it's just inconvenient:
      the system type is recognized as a generic linux and you
      don't have a useful initial-setup setup of packages.
      4f5fb910
  19. 27 May, 2020 2 commits
    • Adriaan de Groot's avatar
      Add more os-release candidates. · 5d3e2edf
      Adriaan de Groot authored
      On FreeBSD (prior to 13), os-release is installed by a port (so it
      may be missing -- but it's an installation requirement for all KDE
      and possibly Qt ports, so it is going to be there if whoever is using
      kdesrc-build has any other KDE software at all). The file ends up
      in */usr/local/etc* because */etc* is for base-system things.
      
      Add that candidate location to the checks.
      5d3e2edf
    • Adriaan de Groot's avatar
      Fix (break) os-release detection. · 028b0e99
      Adriaan de Groot authored
      `open($fh, ...)` associates a filehandle with `$fh`, even when
      `open()` fails. The `$fh` is truthy, even when the filehandle is closed.
      
      On FreeBSD, */etc/os-release* does not exist (in versions prior
      to 13, at least), but the code tries to open that; `open()`
      returns undefined so the `last` doesn't trigger, but `$fh`
      is now associated with something, and is truthy: the while-loop
      ends, `croak_runtime()` is skipped, and a closed filehandle
      is read. There's no lines in there, and os-release detection
      ends up thinking generic-Linux.
      
      The warning that perl prints is
      
          readline() on closed filehandle $fh at
          kdesrc-build/modules/ksb/OSSupport.pm line 147.
      
      (line number modulo some debug-hacking of mine). By setting
      `$fh` back to undefined the while-loop will actually try all
      of the possibilities.
      
      - Effectively, this prevents FreeBSD from using kdesrc-build,
        since there is no os-release (and that's apparently fatal).
      - This **might** be a perl 5.30.2 issue? I don't know how truthy
        older filehandles are, nor whether `open()` sets them on failure.
      028b0e99
  20. 25 May, 2020 1 commit
  21. 20 May, 2020 3 commits
    • Michael Pyne's avatar
      git: Show warning at end of build if git-stash fails. · 87bcfe1f
      Michael Pyne authored
      If this all works this would allow us to migrate this functionality to
      improve how we handle git-stash as in issue #42.
      
      In my testing, it works at least. I'll show example output in the
      corresponding merge request for tracking.
      87bcfe1f
    • Michael Pyne's avatar
      module: Add ability to track messages to show user after build ends. · 7851924a
      Michael Pyne authored
      This is intended to support some of the git-stash improvement we want in
      issue #42 but it will obviously have wider application.
      
      The hard part is that in the normal mode of operations (asynchronous)
      the update process is off in a separate subprocess and will not have
      access to the ksb::Module that we would want to print the messages from
      at the end of the main process.
      
      As with the similar problems I've run into here, my solution is to pass
      the info over the IPC class. This will be easier in the make_it_mojo
      branch but on the other hand it will need implemented differently in
      that branch.
      7851924a
    • Michael Pyne's avatar
      2a2c08d5
  22. 18 May, 2020 1 commit
    • Johan Ouwerkerk's avatar
      Ignore `hasrepo` metadata field. · 631dbf74
      Johan Ouwerkerk authored
      This field is effectively obsolete, and sysadmin is looking to remove it.
      Previously there used to be metadata files on the 'group' level that had
      this flag disabled, but such files are now all gone. The sanity check
      never triggers for the metadata files anymore since the move to Gitlab.
      631dbf74