[Reproducible-builds] [Reproducible-commits] [notes] 01/01: In addition to scsh-0.6, we should not be trying to build these packages on amd64:

Holger Levsen holger at layer-acht.org
Thu Nov 26 20:04:19 UTC 2015

Hi Santiago,

On Donnerstag, 26. November 2015, Santiago Vila wrote:
> Yesterday night, in another email, Holger told me that perhaps those
> packages that I added and then removed should be added again.
> I started to write this reply but I think it is better to discuss it
> here as I think it could be of general interest.

thanks for moving our discussion to this list again! My last private mail started private (just including the info that I just had scheduled those builds which was visible on IRC) but then I included the 
results and conclusions… and should have sent it to this list instead.

> Let me start by saying that IMHO none of the packages I added to
> notes.git should be tried on amd64 to begin with.

well, any package source should be downloaded and then the Architecture: header of the source package should be parsed.

this is the code responsible for doing this:

check_suitability() {
        # check whether the package is not for us...
        local SUITABLE=false
        local ARCHITECTURES=$(grep "^Architecture: " ${SRCPACKAGE}_*.dsc| cut -d " " -f2- | sed -s "s# #\n#g" | sort -u)
        for arch in ${ARCHITECTURES} ; do
                if [ "$arch" = "any" ] || [ "$arch" = "$ARCH" ] || [ "$arch" = "linux-any" ] || [ "$arch" = "linux-$ARCH" ] || [ "$arch" = "any-$ARCH" ] || [ "$arch" = "all" ] ; then
                # special case arm…
                if [ "$ARCH" = "armhf" ] && [ "$arch" = "any-arm" ] ; then

        if ! $SUITABLE ; then handle_not_for_us $ARCHITECTURES ; fi

> That's why I said that the best fix is for those packages not to be in
> the "list of packages to be tried on amd64".
> So, before adding stuff back and forth to notes.git, let me ask a simple
> question:
> How do you generate the list of packages that should be tried?

all of them are tried, and then, the above code is run.

> Let's take cmucl as an example:
> Package: cmucl
> Architecture: i386 all
> It has "all", yes, but implicitly I take the Architecture line
> as saying that I should only try to build the "Arch: all" package
> using a i386 autobuilder.

why do you think so? is that documented somethere?

I always read it as "this package should be buildable on
i386 and all architectures" which I see now seems a bit silly. 
> Does this make sense?

yup :)

another thing: I think I've seen some packages which should be tagged 
"ftbfs_due_to_virtual_dependencies" in notes.git, though OTOH I seem to
recall pbuilder learned to cope with that. Hm.

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 828 bytes
Desc: This is a digitally signed message part.
URL: <http://lists.alioth.debian.org/pipermail/reproducible-builds/attachments/20151126/0561b8e0/attachment.sig>

More information about the Reproducible-builds mailing list