Hi Stuart, Stuart Prescott <stu...@debian.org> wrote (Sat, 3 Jun 2023 14:45:46 +1000): > > - The list of archs is hardcoded in the Makefile for now. > > The following might provide you with some useful way of not hard-coding > such information: > > curl -s 'https://api.ftp-master.debian.org/suite/bookworm' > > (pipe that into « jq -r '.architectures[]' » to get just the archs as > plain text)
I managed to get a list of all relevant architectures via curl -s 'https://api.ftp-master.debian.org/suite/testing' | jq -r '.architectures[]' | grep -v all | grep -v source > You might want to make that a 'maintainer-run' step rather than is run > occasionally as part of preparing a release, rather than as a build time > step. That is, the maintainer runs that from a machine with internet > access to find the list of archs that should be used; this is then > cached in the repo until it is next refreshed. There is precedent for > this 'maintainer-run' step in various "make dist' mechanisms (from the > autotools world) and how the dh-python packages prepares a cache of > known python modules in the archive for later module→package translation. I created a prepare-release.sh script, which can be used to prepare the release-notes for the next stable. That script creates an archlist file, which holds the relevant archs for the current testing. Thanks for helping me with that! > There has been talk for a while about how we might avoid baking in > internal metadata in packages and there might be more inspiration on how > to do this in other parts of the project: > > https://wiki.debian.org/SuitesAndReposExtension > > (there are already a couple of entries there for the release notes) Shouldn't the above solution be added to that wiki page? (I don't see it there, right?) Holger -- Holger Wansing <hwans...@mailbox.org> PGP-Fingerprint: 496A C6E8 1442 4B34 8508 3529 59F1 87CA 156E B076
