GitLab

This makes it simpler to debug problems.

It's time to move on here too.

They're unmaintained.

`pureos/amber` and `pureos/byzantium` images now have a manifest
that allows the right image to be selected based on host architecture
automatically.

Packages like apt-setup produce only udebs so copying the debs
fails. Split the copying and just make sure either udebs or debs
got copied.

We want to make sure, that tags are being fetched
so that `gbp export-orig` can create the tarballs

This way we immediatelly know if something breaks there.

amber-jobs: Add "changed-by-invalid-for-derivative" and "invalid-version-number-for-derivative" to lintian suppressions

Lintian in PureOS imposes additional restrictions on version numbers
and changed-by addresses that aren't always followed by packages built
by GitLab CI.

Otherwise initial apt-get update fails because of missing ca-certificates.

It doesn't really make sense to utilize `before_script` here,
since its primary function is to overwrite global `before_script`
set in the pipeline. This made it impossible for a job to define
its own steps to execute before `script` without copying the whole
`before_script` section from this file, which makes it easily out of
date (and is something that already happened for `package:deb-pureos-amber`
job in phosh as it doesn't use eatmydata like other jobs do now).

This gives people a better chance to understand what's going on.

Thus enabling more checks

There's no standard job name template defined anywhere, users
are expected to specify the dependencies by themselves.

Removing the default value makes it more flexible, as DAG
("needs" keyword) can be used instead of regular dependencies.

This job doesn't need to collect any artifacts nor wait for
previous stages to complete.

This avoids a warning that confuses users. Also show the content
of the topmost commit so errors are simpler to find.

It's not necessarily in the repo

This makes it simple to verify the tarball on release builds.

That should make it harder to miss such build when
setting up CI

Make it easier to find out if one is running a CI build and if so which
one.

The UNRELEASED in the changelog might us get into trouble later on.

The default is to include all artifacts, but these jobs usually don't
need any.

We need the executable also when not using CI repos.

Build a dummy deb so we know the pipeline works

Just here to test the pipeline on itself

The debian package builds dumps stuff there and so it might
end up in cached containers.

We only need to update the packaging information if we added the
ci repo.

Builds not using our ci repos need those as well.

So we don't fail if they're missing.

Copy udebs as well

See merge request !2

Otherwise lintian chokes on missing files

Update submodule

See merge request !1