Michael Pyne authored May 10, 2020 and Méven Car committed Jun 17, 2020

This addresses kdesrc-build bugs in local change detection.

@dfaure has noted continuing issues with kdesrc-build in trying to stash
what it believes are local changes, the stash being empty, and then
kdesrc-build throwing an error trying to restore the non-existent stash.

Rather than trying to predict what git will decide is stash-able, and
what is not, we can just use git to do the autostashing directly. It's
been supported since at least git 2.6 (Sep 2015), which we can assume
has been deployed to enough users to rely on being available.

I do this by adapting the existing 'update existing checkout' code to
include `--autostash` when it calls git-rebase and removing a bunch of
now-redundant code.

It passes test suite and some test updates I've done locally, including
modules with stash-able changes.

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"

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"

Nicolas Fella authored May 28, 2020 and Michael Pyne committed May 30, 2020

boost is needed for kactivities
intltool is needed for kaccounts

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?)

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
```

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.

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.

`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.

For starter, it is in wrong place, and for second bit, it is
unmaintained

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.

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.

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.

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).

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.

Also: x-invent-push-urls is now the only way to go, the feature toggle is no longer useful.

This addresses the bug causing kdesrc-build to warn repeatedly about a
git remote having moved (because it was comparing against a persistent
option set the normal way).

Unfortunately the persistent option update feature in the IPC code has
probably never worked properly as far as I can tell, so this may also
fix other minor bugs.

What I'd like to do before merging this all is to find a way to
integrate into the test suite somehow.

* kde-build-metadata has moved, update our pre-baked module to request
  the right name.
* Enable the invent.kde.org logic by default.
* Use invent.kde.org instead of anongit.kde.org for kde: fetch URL

kdesrc-build still makes a lot of complaints about having to move git
remotes for some reason but at least I can make it through part of a
build.

Into the migration to Gitlab, kdesrc-build was oddly failing to
understand the KDE project database.

Long story short, the sysadmins tried to help the various scripts by
placing a symlink from the old module location to the new
'invent-modules' in repo-metadata. However kdesrc-build's search logic
didn't follow symlinks since Perl's File::Find doesn't do this by
default.

It's an easy option to add now though, so I've done that and tried to
add some better logic checks / error messages for similar problems that
might recur in the future.

kdesrc-build still fails to build many modules though because the
metadata key we're checking doesn't give the right path? I'll look into
that more...

It would be even easier for most users of our graphical desktop
environment to look at log files if they could click on the log dir.

By prefixing the log dir path with file://, now they can (in Konsole and
I'm sure most others).

I thought about implementing OSC8 support (TTY escape codes for
hyperlinks) but we don't support that in Konsole and I'm not sure how
many other TTYs are commonly used in Plasma.

Prepare for new project metadata format in kde-build-metadata.

See merge request kde/kdesrc-build!31

Prepare for invent migration

See merge request kde/kdesrc-build!27

With this change kdesrc-build will automatically fixup repository fetch/push URLs if the repopath metadata changes.

This change is gated behind a feature flag: x-invent-kde-push-urls (disabled by default for now).
It should be possible to opt-in to test the change via rc file configuration.

This change enables it to access configuration options.

There have long been bug reports around git-stash handling. I just had
to enter another one, but it's hard to troubleshoot what git was seeing
after the fetch and rebase has already happened, even if you try to
rewind with reflog.

For now this will just run a simple 'git-status' as a smoke check before
the update, and optionally if a stash or error occur. My hope is this
will permit more detail to be provided with subsequent bug reports.

CCBUG:420933

Add Alpine support to initial setup

See merge request kde/kdesrc-build!30