Hi,
I have worked on the packages quite a bit. They are now all added
to the CI on salsa and are green. See the list
https://salsa.debian.org/search?utf8=%E2%9C%93&search=opm-&group_id=&project_id=&snippets=false&repository_ref=&nav_source=navbar
There have some struggles and I had to work a bit to get it work or deactivate
some stuff
On Wed, May 26, 2021 at 03:32:54PM +0200, Markus Blatt wrote:
- "build i386" as the upstream tests fail on this platform.
One of the reasons is probably the Y2k38 problem on this
architecture.
Can I restrict Architecture in debian/control to 64bit only?
It turned out that even with fixes for i386 the packages would be rather
useless. Hence the work was stopped. Instead we now only lit 64bit architectures
in debian/control and intsruct salsa-ci to skip i386 builds via
variables:
SALSA_CI_DISABLE_BUILD_PACKAGE_I386: 1
in debian/salsa-ci.yml
-reprotest times out.
I increased the timeout of the CI to 2 hours. At least for opm-common
some of the reprocibility bugs have been fixed. Unfortunately for the
other modules reprotest had to be deactivated (SALSA_CI_DISABLE_REPROTEST: 1)
as the test runs as root and some of our tests are run using MPI (which refuses
to run as root). See
https://salsa.debian.org/salsa-ci-team/pipeline/-/issues/160
autopkgtests:
I have added autopkgtests to all modules. Unfortunately, I had to deactivate
running them on all modules
but opm-common. The problem is that they need the packages from other OPM
modules. That works for the build
(see below) but autopkgtest has a problem with ca-certificates when using external repositories, see
https://salsa.debian.org/salsa-ci-team/pipeline/-/issues/201#note_244674
For opm-simulators the shared CI on gitlab.com ran out of RAM and I had to
deactivate parallel builds
in the CI (SALSA_CI_DPKG_BUILDPACKAGE_ARGS: --jobs=1)
- Please consider reducing the number of source packages.
Uploading/sponsoring
7 source packages, especially if some of them should go through NEW
queue. It is
pain.
Each of the source packages has its own repository upstream. [...]
I always assumed that Debian source package correspond to official
upstream tarballs/repositories.
Indeed and I feel with you. When I added the CI to all packages I already
had to deal with that. As we need the OPM packages we depend on, I used the
following approach
- Activated aptly for salsa-ci: (SALSA_CI_DISABLE_APTLY: 0)
- Created a gpg keypair for the aptly repostories
- In the Setting->CI/CD->Variables
- Set variable (type variable) SALSA_CI_APTLY_GPG_KEY to the private key (same
key for all repos)
- Set variable (type variable) SALSA_CI_APTLY_GPG_PASSPHRASE to the passphrase
for the key
- Set variable (type File) SALSA_CI_EXTRA_REPOSITORY to a recent one of aptly,
e.g.
deb
https://salsa.debian.org/science-team/opm-common/-/jobs/1734127/artifacts/raw/aptly
unstable main
- Set variable (type File) SALSA_CI_EXTRA_REPOSITORY_KEY to the public (same
key for all repos)
I wonder how other multi-repository projects deal with these build
dependencies. Any hint/insight would
be highly appreciated
Would be cool if somebody would take another look?
Is there anything I need to do because of the freeze? CI is using unstable.
Cheers,
Markus
