1. 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
  2. 08 Jul, 2020 1 commit
  3. 07 Jul, 2020 1 commit
    • 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
  4. 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
  5. 05 Jul, 2020 2 commits
  6. 04 Jul, 2020 1 commit
  7. 01 Jul, 2020 1 commit
  8. 30 Jun, 2020 2 commits
  9. 20 Jun, 2020 3 commits
  10. 18 Jun, 2020 2 commits
  11. 17 Jun, 2020 2 commits
  12. 06 Jun, 2020 1 commit
  13. 31 May, 2020 1 commit
  14. 30 May, 2020 1 commit
  15. 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
  16. 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
  17. 25 May, 2020 1 commit
  18. 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
  19. 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
  20. 17 May, 2020 6 commits
    • Michael Pyne's avatar
      Add project logo. · b183195b
      Michael Pyne authored
      b183195b
    • Michael Pyne's avatar
      doc: Remove anongit references. · 48368983
      Michael Pyne authored
      48368983
    • Milian Wolff's avatar
      Use `git pull --rebase` instead of `git rebase` · 1b329567
      Milian Wolff authored
      My git version 2.26.2 returns an error code 1 and doesn't rebase
      in a fast-forward scenario. I have to admit that I'm surprised by
      this myself. But `git pull --rebase` does what we want, so apparently
      that should be used instead? Or is this some local configuration
      issue?
      
      When I run kdesrc-build without this patch I get:
      
      ```
              Updating sysadmin-repo-metadata using existing branch master
      log_command(): Module sysadmin-repo-metadata, Command: git checkout master
      # kdesrc-build running: 'git' 'checkout' 'master'
      # from directory: /home/milian/projects/kf5/src/sysadmin/repo-metadata
      Already on 'master'
      Your branch is behind 'origin/master' by 105 commits, and can be fast-forwarded.
        (use "git pull" to update your local branch)
      log_command(): Module sysadmin-repo-metadata, Command: git rebase origin/master
      # kdesrc-build running: 'git' 'rebase' 'origin/master'
      # from directory: /home/milian/projects/kf5/src/sysadmin/repo-metadata
      error: nothing to do
      Logfile for sysadmin-repo-metadata is git-rebase.log
              Unable to update the source code for sysadmin-repo-metadata
      ```
      
      Indeed, I can also easily reproduce this issue outside of kdesrc-build
      directly in my shell:
      
      ```
      $ git --version
      git version 2.26.2
      $ cd /home/milian/projects/kf5/src/sysadmin/repo-metadata
      $ git status
      On branch master
      Your branch is behind 'origin/master' by 105 commits, and can be fast-forwarded.
        (use "git pull" to update your local branch)
      
      nothing to commit, working tree clean
      $ git rebase origin/master
      error: nothing to do
      $ echo $?
      1
      ```
      
      A `git pull --rebase origin master` fast-forwards my local checkout
      as intended. This is what this patch does now too, thereby fixing all
      the errors/warnings in kdesrc-build (and properly updating my local
      checkouts again).
      1b329567
    • Michael Pyne's avatar
    • Michael Pyne's avatar
      git: Revert change to git-desired-protocol. · 52026a14
      Michael Pyne authored
      We *always* use HTTPS to fetch new objects from git.
      
      We *can support* setting the git "push URL" to HTTPS also, and some
      users will need this. But this complicates the existing practice of
      using git + SSH to push changes to the KDE git infrastructure, so revert
      this part of the change.
      52026a14
    • Johan Ouwerkerk's avatar
      Make sure to remove old pushInsteadOf mapping if git-desired-protocol changes. · 940f3355
      Johan Ouwerkerk authored
      Also: x-invent-push-urls is now the only way to go, the feature toggle is no longer useful.
      940f3355