Re: [Reproducible-builds] [Reproducible-commits] [notes] 01/01: In addition to scsh-0.6, we should not be trying to build these packages on amd64:
On Thu, Nov 26, 2015 at 09:04:19PM +0100, Holger Levsen wrote: > 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. Currently there are 0 packages tagged with that. Anyway, pbuilder doesn't really care about this afaik, but I don't even recall it ever caring. For dependencies resolution it just passes the list of deps to something else, in our cases it creates a fake .deb with the needed build-dep (=> stripping build-profiles and arch restrictements after evaluating them), install it and then asking aptitude to fix the deps. I believe this can deal with virtual dep just fine (though it's not like I even explicetely tried this out, and for sure now nothing is failing due to that. ISTR that tag was done due to apt saying Depends: $pkg which is a virtual package when it cannot find it for whatever reason (look at the depwait packages to see). That string is actually misleading... -- regards, Mattia Rizzolo GPG Key: 66AE 2B4A FCCF 3F52 DA18 4D18 4B04 3FCD B944 4540 .''`. more about me: http://mapreri.org : :' : Launchpad user: https://launchpad.net/~mapreri `. `'` Debian QA page: https://qa.debian.org/developer.php?login=mattia `- signature.asc Description: PGP signature ___ Reproducible-builds mailing list Reproducible-builds@lists.alioth.debian.org http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/reproducible-builds
Re: [Reproducible-builds] [Reproducible-commits] [notes] 01/01: In addition to scsh-0.6, we should not be trying to build these packages on amd64:
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
SUITABLE=true
break
fi
# special case arm…
if [ "$ARCH" = "armhf" ] && [ "$arch" = "any-arm" ] ; then
SUITABLE=true
break
fi
done
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.
cheers,
Holger
signature.asc
Description: This is a digitally signed message part.
___
Reproducible-builds mailing list
Reproducible-builds@lists.alioth.debian.org
http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/reproducible-builds
Re: [Reproducible-builds] [Reproducible-commits] [notes] 01/01: In addition to scsh-0.6, we should not be trying to build these packages on amd64:
Hi. 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. Let me start by saying that IMHO none of the packages I added to notes.git should be tried on amd64 to begin with. 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? In case it helps, I can tell you how I generated the list I needed for my "dpkg-buildpackage -A" experiment using an amd64 autobuilder: I needed a list of source packages that generate at least one "Arch: all" package and at least one "Arch: amd64" package, so I looked for source packages having an Architecture field containing: 1. "all" and 2. At least one of "any", "linux-any", "amd64" or "any-amd64" That's exactly what nobody has been testing, the "binary-indep" target of packages that also generate some "Arch: any" package of any kind, but I had to restrict that to amd64 as I was using an amd64 autobuilder. For reproducible.debian.org, it seems that you consider buildable any package having "all" in the Architecture field in the source package. However, something tells me that this is more than it's expected. 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. Does this make sense? ___ Reproducible-builds mailing list Reproducible-builds@lists.alioth.debian.org http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/reproducible-builds
Re: [Reproducible-builds] [Reproducible-commits] [notes] 01/01: In addition to scsh-0.6, we should not be trying to build these packages on amd64:
Hi Santiago, On Mittwoch, 25. November 2015, Santiago Vila wrote: > I was making package lists to check for "dpkg-buildpackage -A", > for amd64 and for i386. saw those bugs, nice work! > Of those, cmucl FTBFS (just reported, without even using -A), so I > went to reproducible.debian.net to confirm, and the funny thing is > that it appeared as "depwait". we had some squid problems this weekend which caused "the machinery" to run havoc a bit. since then we have increased diskspace on jenkins.d.n (which quite probably was the cause for squid going down - and this was causing other issues anyway too) and I've added 30m sleep to build jobs which encounter a 404 (in addition to 15m already…) - as those should not happen at all (but they do happen if squid has problems.) so next time the effects of such service downtimes should be less. > > also please revert this commit/change, thanks! > Ok, I've made one more commit which not only reverts the change I did > but also drops a comment similar which according to what you have just > said it should not be in notes.git. thanks! > Thanks. likewise, really! :-) cheers, Holger signature.asc Description: This is a digitally signed message part. ___ Reproducible-builds mailing list Reproducible-builds@lists.alioth.debian.org http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/reproducible-builds
Re: [Reproducible-builds] [Reproducible-commits] [notes] 01/01: In addition to scsh-0.6, we should not be trying to build these packages on amd64:
On Wed, Nov 25, 2015 at 10:57:48PM +0100, Holger Levsen wrote: > > The "right" fix for this very little anomaly is that they should not > > be in the list of packages to be built to begin with. > > nope, we have something better, see above :) how did you notice? I was making package lists to check for "dpkg-buildpackage -A", for amd64 and for i386. There are only a few packages buildable on i386 but not on amd64. Of those, cmucl FTBFS (just reported, without even using -A), so I went to reproducible.debian.net to confirm, and the funny thing is that it appeared as "depwait". > also please revert this commit/change, thanks! Ok, I've made one more commit which not only reverts the change I did but also drops a comment similar which according to what you have just said it should not be in notes.git. Thanks. ___ Reproducible-builds mailing list Reproducible-builds@lists.alioth.debian.org http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/reproducible-builds
Re: [Reproducible-builds] [Reproducible-commits] [notes] 01/01: In addition to scsh-0.6, we should not be trying to build these packages on amd64:
Hi Santiago, On Mittwoch, 25. November 2015, Santiago Vila wrote: > > why? (eg bug number) > Because their Architecture field in the Sources.gz file does not include > amd64. ah, ok, then please don't mention those in notes.git as they automatically show up on https://reproducible.debian.net/unstable/amd64/index_not_for_us.html and/or https://reproducible.debian.net/unstable/armhf/index_not_for_us.html If they don't, it's a bug in reproducible.debian.net and should be treated as such. > > - and should we blacklist them? > This is up to you. Blacklist is a very strong word, these are nice > packages that have not done anything wrong :-) indeed :) > The "right" fix for this very little anomaly is that they should not > be in the list of packages to be built to begin with. nope, we have something better, see above :) how did you notice? also please revert this commit/change, thanks! cheers, Holger signature.asc Description: This is a digitally signed message part. ___ Reproducible-builds mailing list Reproducible-builds@lists.alioth.debian.org http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/reproducible-builds
Re: [Reproducible-builds] [Reproducible-commits] [notes] 01/01: In addition to scsh-0.6, we should not be trying to build these packages on amd64:
On Wed, Nov 25, 2015 at 09:52:55PM +0100, Holger Levsen wrote: > Hi Santiago, > > On Mittwoch, 25. November 2015, Santiago Vila wrote: > > In addition to scsh-0.6, we should not be trying to build these > > packages on amd64: > > > > cmucl > > fenix > > gnumach > > why? (eg bug number) Because their Architecture field in the Sources.gz file does not include amd64. Package: cmucl Architecture: i386 all Package: fenix Architecture: arm armel armhf hppa hurd-i386 i386 kfreebsd-i386 m68k mips mipsel mipsn32 mipsn32el powerpc s390 sh4 sparc all Package: gnumach Architecture: any-i386 all > - and should we blacklist them? This is up to you. Blacklist is a very strong word, these are nice packages that have not done anything wrong :-) The "right" fix for this very little anomaly is that they should not be in the list of packages to be built to begin with. Thanks. ___ Reproducible-builds mailing list Reproducible-builds@lists.alioth.debian.org http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/reproducible-builds
Re: [Reproducible-builds] [Reproducible-commits] [notes] 01/01: In addition to scsh-0.6, we should not be trying to build these packages on amd64:
Hi Santiago, On Mittwoch, 25. November 2015, Santiago Vila wrote: > In addition to scsh-0.6, we should not be trying to build these > packages on amd64: > > cmucl > fenix > gnumach why? (eg bug number) - and should we blacklist them? cheers, Holger signature.asc Description: This is a digitally signed message part. ___ Reproducible-builds mailing list Reproducible-builds@lists.alioth.debian.org http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/reproducible-builds
