For the use case of building pure Debian packages, we only need the
package-source-builder. So, lets just disable the rest of the images.

And also add the Debian specific bits to get the debootstrap work.

This is the same approach done in c7faa400 (Bookworm) and d285422a (Bullseye.)

Signed-off-by: Dylan Aïssi <dylan.aissi@collabora.com>

In order to proceed with the rebase we need stable docker images with all
the needed dependencies available. To do that switch to Debian Bookworm
as mirror.

This same approach was used in fb4c138c (Bookworm) and 788aa27a (Bullseye).

Signed-off-by: Dylan Aïssi <dylan.aissi@collabora.com>

Walter Lozano authored 1 year ago and Ritesh Raj Sarraf committed 1 year ago

HMI component is not longer supported, so remove references to it.

Signed-off-by: Walter Lozano <walter.lozano@collabora.com>

Walter Lozano authored 1 year ago and Ritesh Raj Sarraf committed 1 year ago

Signed-off-by: Walter Lozano <walter.lozano@collabora.com>

For the use case of building pure Debian packages, we only need the
package-source-builder. So, lets just disable the rest of the images.

And also add the Debian specific bits to get the debootstrap work

This is the same approach done in d285422a.

Signed-off-by: Walter Lozano <walter.lozano@collabora.com>

In order to proceed with the rebase we need stable docker images with all
the needed dependencies available. To do that switch to Debian Bookworm
as mirror.

This same approach was used in 788aa27a.

Signed-off-by: Walter Lozano <walter.lozano@collabora.com>

Now that the bulk of the packages have been made available in the
Bullseye based v2022dev2 we can revert
commit 788aa27a.

For the use case of building pure Debian packages, we only need the
package-source-builder. So, lets just disable the rest of the images.

And also add the Debian specific bits to get the debootstrap work

Signed-off-by: Ritesh Raj Sarraf <ritesh.sarraf@collabora.com>

Signed-off-by: Emanuele Aina <emanuele.aina@collabora.com>

Downstreams need to figure out what is specific to Apertis and needs to
be customized, so let's not mislead them and drop "apertis" from the
rootfs intermediate artifact as it does not need any customization since
it's purely internal to the pipeline.

Signed-off-by: Emanuele Aina <emanuele.aina@collabora.com>

Calling the recipe `apertis.yaml` is annoying for downstreams which have
to either keep the misleading name or rename it and deal with issues
when pulling updates.

Let's use a slightly more descritive name that does not encode the
name of the OS.

Signed-off-by: Emanuele Aina <emanuele.aina@collabora.com>

Repeating "apertis" everywhere is not particularly useful but is
annoying for downstreams which have to either keep the misleading
names or rename everything and deal with the resulting mess when
pulling updates.

This also makes our life less painful since not having a common prefix
makes shell completion much more useful. :)

Signed-off-by: Emanuele Aina <emanuele.aina@collabora.com>

Instead of building all images individually, try and build Apertis-based
ones from the same common ground. First create a fairly basic Apertis
ospack with a few development tools in, then create a Docker image out of
it and layer things on top of it.

This unifies the previously separate overlays for the package builder and
the package source builder, only keeping the real differences in their
respective overlays.

We opt to not use Docker proper since it requires non-trivial
Docker-in-Docker setup. Makisu, which could be used as an alternative,
unfortunately, has buggy implementation of the ADD command, leaving us
the only option to use Kaniko.

The docker building step is templated in .gitlab-ci.yml to avoid
repetition. The Debian-based images don’t normally have to depend on the
rootfs building step, but to be able to run them asynchronously in the
same pipeline stage we need to declare the dependency anyway, as GitLab CI
does not currently support empty "needs" lists.

The branches named apertis/* build their respective Apertis releases,
everything else builds the default defined in the CI YAML file.

The jobs for apertis/* branches tag their build images as "latest", every
other job uses the branch name.

For robustness, the debos rootfs step uses a stable v2020 image builder
step instead of the currently built one.

Signed-off-by: Andrej Shadura <andrew.shadura@collabora.co.uk>

These repositories can be required when new updates to the stable
release occur which bring in new package dependencies. For new packages
(build dependencies) that occur, we push them through the :updates or
:security repository for that stable release

Signed-off-by: Ritesh Raj Sarraf <ritesh.sarraf@collabora.com>

Tested locally with debos -t suite:$release -t stable:true ...

2019/11/01 13:00:18 ==== overlay ====
Overlaying /home/rrs/rrs-home/devel/CCU/Apertis/apertis-docker-images/apertis-package-source-builder/overlay on /scratch/root
2019/11/01 13:00:18 ==== Add extra apt sources ====
2019/11/01 13:00:19 ==== run ====
Hit:1 https://repositories.apertis.org/apertis v2019 InRelease
Get:2 https://repositories.apertis.org/apertis v2019-updates InRelease [24.3 kB]
Get:3 https://repositories.apertis.org/apertis v2019-security InRelease [24.5 kB]
Get:4 https://repositories.apertis.org/apertis v2019/sdk Sources [158 kB]
Get:5 https://repositories.apertis.org/apertis v2019/development Sources [1382 kB]
Get:6 https://repositories.apertis.org/apertis v2019/target Sources [244 kB]
Get:7 https://repositories.apertis.org/apertis v2019/hmi Sources [2852 B]
Get:8 https://repositories.apertis.org/apertis v2019/hmi amd64 Packages [6332 B]
Get:9 https://repositories.apertis.org/apertis v2019/sdk amd64 Packages [299 kB]
Get:10 https://repositories.apertis.org/apertis v2019/development amd64 Packages [2436 kB]
Get:11 https://repositories.apertis.org/apertis v2019-updates/development Sources [7018 B]
Get:12 https://repositories.apertis.org/apertis v2019-updates/development amd64 Packages [6359 B]
Get:13 https://repositories.apertis.org/apertis v2019-security/development Sources [9284 B]
Get:14 https://repositories.apertis.org/apertis v2019-security/target Sources [3418 B]
Get:15 https://repositories.apertis.org/apertis v2019-security/sdk Sources [1429 B]
Get:16 https://repositories.apertis.org/apertis v2019-security/target amd64 Packages [11.5 kB]
Get:17 https://repositories.apertis.org/apertis v2019-security/sdk amd64 Packages [10.6 kB]
Get:18 https://repositories.apertis.org/apertis v2019-security/development amd64 Packages [64.3 kB]
Fetched 4691 kB in 8s (555 kB/s)
Reading package lists... Doneplv2-packages-for-dev-env.sh |
Reading package lists... Doneplv2-packages-for-dev-env.sh |
Building dependency tree... Done2-packages-for-dev-env.sh |
2019/11/01 13:00:28 replace-gplv2-packages-for-dev-env.sh | The following packages will be REMOVED:
2019/11/01 13:00:28 replace-gplv2-packages-for-dev-env.sh |   coreutils-gplv2* mktemp*

Use v2020 branch from OBS and set default suite to v2020dev0

Signed-off-by: Denis Pynkin <denis.pynkin@collabora.com>

Extend the script replacing the GPLv2 forks of `tar` and `coreutils` to
also replace the newly introduced `grep-gplv2`, `diffutils-gplv2` and
`findutils-gplv2`.

Signed-off-by: Emanuele Aina <emanuele.aina@collabora.com>

Signed-off-by: Andrej Shadura <andrew.shadura@collabora.co.uk>

Signed-off-by: Denis Pynkin <denis.pynkin@collabora.com>

Signed-off-by: Sjoerd Simons <sjoerd.simons@collabora.co.uk>

Ritesh Raj Sarraf authored 6 years ago and Ritesh Raj Sarraf committed 6 years ago

This is needed by the ade tool, which relies on '/etc/image_version' to determine
in what environment it is running

Signed-off-by: Ritesh Raj Sarraf <ritesh.sarraf@collabora.com>

Add some new build dependency packages for apertis-eclipse-plugins package

Also enable the sdk component because some of the build dependency packages
are part of the apertis archive in the 'sdk' component

Signed-off-by: Ritesh Raj Sarraf <ritesh.sarraf@collabora.com>

debos, by default, lets debootstrap check gpg keys. As the
apertis gpg key isn't typically in the hosts default set add it to the
recipe directly.

Also add the gpg keyring file

Signed-off-by: Ritesh Raj Sarraf <ritesh.sarraf@collabora.com>

Introduce a docker image for usage as a package builder in Jenkins. This first
generates a minimal debos ospack which gets uses by Docker as a scratch
file system. Everything else can then be brought in usins the docker tools.

Apertis: T4510

Signed-off-by: Sjoerd Simons <sjoerd.simons@collabora.co.uk>