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.
cool.
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?
[cross-config]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] gfmasdrf IOhannes
Attachment:
OpenPGP_0xB65019C47F7A36F8.asc
Description: OpenPGP public key
Attachment:
OpenPGP_signature
Description: OpenPGP digital signature