[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: cross-building with salsa-ci

On 6/22/21 1:23 PM, Helmut Grohne wrote:
On Tue, Jun 22, 2021 at 11:54:30AM +0200, IOhannes m zmölnig (Debian GNU|Linux) wrote:
a quick glance of the pipeline definition shows that ARCH is not really used
for anything apart from defining the cache-key.

Unless I am mistaken, it also selects the docker image.

i checked but couldn't find anything like this.
the "build i386" uses the ${SALSA_CI_IMAGES_BASE_I386} image which hardcodes the "/i386/" part.

Why not apply the same "trick" that you use with HOST_ARCH to BUILD_ARCH > and default it to empty? As such you can say ${BUILD_ARCH:-$ARCH} and be

ah well.
because i wanted to use ${BUILD_ARCH} rather than ${ARCH} in the expansion outside of the 'scripts' section (as mentioned previously this is used only in "cache:key", but there it *is* used; if we want to nag towards migrating away from ARCH, i don't see much value in keeping ${ARCH} around for such things.

anyhow: i think the point is, whether you think that I should check all the
pipeline-definitions of all the projects to see whether we might have
problems, or just assume that the current solution is good enough.

I think this is up to the salsa-ci team, not me.


I see that you unset HOST_ARCH when it equals BUILD_ARCH. If you keep
this, then the check on empty values makes sense to me.

i plan to keep it.

Otherwise you
risk performing a native build with cross flag.

would that actually be an interesting test-case?

should this info be added to [1] then? the wiki is what i followed to setup
the cross-compiling pipelines.

Unsure. I really don't like cross-config and its CONFIG_SITE approach.

should the CONFIG_SITE export be left out completely?
in any case, of course i do want to support projects that use autotools out
of the box.

The principle of least surprise likely says that you should do what
sbuild does (and keep CONFIG_SITE).

aren't the two statements contradictory?

does sbuild provide 'cross-config'?
if not, why would a dpkg-buildpackage based workflow need to install it?

i don't know much about the internals of sbuild nor of CONFIG_SITE, but so far my understanding is (and i'm really just repeating what you told me in the previous email) that if i want to use CONFIG_SITE then i should *also* install 'cross-config'.

so why would you tell me to install it here on the mailinglist, but not on the wiki? (on re-reading this sounds a bit aggressive; this is not my intention, i just don't know how to ask the question more nicely)

you can find my attempts in the (default) 'crossbuild' branch of my
salsa/pipelines fork at [2].

This looks mostly good. Your test for whether a source package builds
$HOST_ARCH binary packages is not fully correct though. A package with
"Architecture: any-arm" would build for armhf, but reported as "No
binary" from your check.

i just copied the check verbatim from the 'test-build-any' job.
i guess it should be reported to eh salsa-ci-pipeline as a separate issue.

Hard coding the gcc version into the libstdc++-dev dependency is going
to cause maintenance effort.

yep. i just pushed the hardcoded value to get a test-run of the pipeline and see whether the rest works correctly. in the meantime i have force-pushed a solution that uses "apt-get satisfy" and should not have this problem.

at least, my test-pipeline (that builds an arch:any package) succeeded.

I think you can turn this into a WIP MR right now and see whether it
passes salsa-ci maintainers.

done: [https://salsa.debian.org/salsa-ci-team/pipeline/-/merge_requests/293]


Attachment: OpenPGP_0xB65019C47F7A36F8.asc
Description: OpenPGP public key

Attachment: OpenPGP_signature
Description: OpenPGP digital signature

Reply to: