Currently, the build run output (stdout, stderr) is just written through as-is (just passing through stdout/stderr to sub processes). But for longer build pipelines it would be very helpful to see which package is currently built.

Therefore: catch the subprocess output line per line and add a proper prefix before writing them out again.

What is the problem you're trying to solve

Cloning can take quite a while for pulling the complete history, which is unpleasant for build-only checkouts (eg. on CI). OTOH, when actively developing on a package, often full history is required.

Thus we need a (global ?) switch for doing just minimal shallow clones.

Describe the solution you'd like

1. add a per-package flag for limiting history cloning (shallow clone)
2. make it default to per-pool flag
3. make the per-pool flag default to global flag
4. make the global flag default to environment variable

Additional context

No response

What is the problem you're trying to solve

• create the rootfs images separately, so they can be created and cached in a separate step

Describe the solution you'd like

./create-rootfs-images

Additional context

No response

What is the problem you're trying to solve

github CI runs currently need to recreate the builder base images afresh, which takes some time

Describe the solution you'd like

• upload prebuilt images to dockerhub
• let deb-pkg (or the ci script) pull them before calling up the actual builds

Additional context

No response

The readme mentions an example packages.yml that show how to configure/run the system, but this appears to be missing.
Are there more details on how to use this?

What is the problem you're trying to solve

For now, there's no generic command line tool yet. For each individual project (or branch) we have a separate tiny script that calls the actual builder tool w/ appropriate config file name and the pool to build.

We should have a generic command line tool for that, so we don't need these individual scriptlets anymore.

Describe the solution you'd like

./build-pool

Additional context

History:

• originally this tool was meant to be customized for each project
• each project should have a number of scriptlets that can be executed w/o any extra parameters (eg. just hit on it in tools like MC ;-)).
• historically, these scriptlets used to do some more project specific things, that now can be just configured in the target config file
• that approach always had been a temporary step, and I've just been too lazy for writing a generic command :p

What is the problem you're trying to solve

Currently, apt repos are separated by target identifier (used by dck-buildpackage). That one is just a plain string w/o inherent structure. Since separate arch's of the same distro have separate target identifier, they're creating separate repos.

This is in contrast to classic apt repos that contain all supported archs in one repo.

Describe the solution you'd like

1. Introduce target configs in deb-pkg (located in cf/target/...)
2. These define several things like archs, repo identifier, arch to build and corresponding deb-buildpackage target identifiers
3. the current target list entries refer to these, if found, otherwise compute the entries that mimic the current behaviour

Additional context

No response

What is the problem you're trying to solve

Most configs only have one pool, usually "default". Some might use a different name for specific reasons.
In order to support building some config yaml, w/o extra boilerplate (eg. by CI), we need a method for finding out which pool to build.

Describe the solution you'd like

add global config "default-pool", which might be single value or a list.
cmd.build_pool checks for that value if no/empty pool name is given. this setting defaults to 'default'.

Additional context

No response

What is the problem you're trying to solve

When CI build runs through, the resulting apt/yum repos should be directly available for installations (eg. just add sources.list entry/key to your machine and fire away).

Describe the solution you'd like

The requirements are not entirely trivial:

1. Need a stable signing key: for now the keyring is generated on-demand and cached on gh (when the cache expires, a new one is generated). It's in no way meant to provide security, just to let the repo builder run through. (an actual repo maintainer would run the tool on his own machine, with his own keyring). Obviously that's painful, when repos should be built and hosted on gh.
2. Need to separate branches: actual repo configs are usually done in separate branches, so these somehow need to be reflected in the repo hosting schema.
3. Need to separate configs: there can be multiple target configs, usually using the same pool names, so these somehow need to be separated by the repo hosting schema.

Additional context

No response

What is the problem you're trying to solve

Variables need to be documented.

Describe the solution you'd like

.

Additional context

No response