Re: [Reproducible-builds] dh_shlibdeps dependency ordering not stable if alternate dependency templates are used
> shouldn't we upload dpkg with that fix to our repo then? If the impact was more widespread, then definitely.. but am tempted to wait until some response from dpkg maintainers, especially as I'm not 100% confident in the patch. -- ,''`. : :' : Chris Lamb `. `'` la...@debian.org / chris-lamb.co.uk `- ___ Reproducible-builds mailing list Reproducible-builds@lists.alioth.debian.org http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/reproducible-builds
Re: [Reproducible-builds] dh_shlibdeps dependency ordering not stable if alternate dependency templates are used
Hi, On Samstag, 18. Juli 2015, Chris Lamb wrote: > Fixed in http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=792491 shouldn't we upload dpkg with that fix to our repo then? 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] dh_shlibdeps dependency ordering not stable if alternate dependency templates are used
> > > btw: https://reproducible.debian.net/rb-pkg/unstable/amd64/pyopencl.html > > > > After fixing the other issues, I now have a reproducability rate of 50% ... > > IIRC you are repeating a failed test once to ignore some spurious > > failures? So you would end up at an error rate of 25% - or less if you > > were retrying even more. Fixed in http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=792491 Regards, -- ,''`. : :' : Chris Lamb `. `'` la...@debian.org / chris-lamb.co.uk `- ___ Reproducible-builds mailing list Reproducible-builds@lists.alioth.debian.org http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/reproducible-builds
Re: [Reproducible-builds] dh_shlibdeps dependency ordering not stable if alternate dependency templates are used
Hi Andreas, On Freitag, 10. Juli 2015, Andreas Beckmann wrote: > On 2015-07-09 20:23, Holger Levsen wrote: > >> The issue is nondeterministic - a first rebuild after partly fixing > >> another reproducibility issue has not shown this again. > > > > btw: https://reproducible.debian.net/rb-pkg/unstable/amd64/pyopencl.html > > After fixing the other issues, I now have a reproducability rate of 50% ... > IIRC you are repeating a failed test once to ignore some spurious > failures? So you would end up at an error rate of 25% - or less if you > were retrying even more. I'm not really sure what you mean, we don't ignore test failures at all. 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] dh_shlibdeps dependency ordering not stable if alternate dependency templates are used
On 2015-07-09 20:23, Holger Levsen wrote: >> The issue is nondeterministic - a first rebuild after partly fixing >> another reproducibility issue has not shown this again. > > btw: https://reproducible.debian.net/rb-pkg/unstable/amd64/pyopencl.html After fixing the other issues, I now have a reproducability rate of 50% ... IIRC you are repeating a failed test once to ignore some spurious failures? So you would end up at an error rate of 25% - or less if you were retrying even more. I've now collected the d/*.substvars before the call to dh_gencontrol, let's see if we get something there: $ grep libopencl-1.2-1 logs/fglrx-driver_*.build* logs/fglrx-driver_15.7-1.build1:shlibs:Depends=libc6 (>= 2.3.3), libgcc1 (>= 1:4.1.1), ocl-icd-libopencl1 | amd-libopencl1 | libopencl1, ocl-icd-libopencl1 (>= 1.0) | amd-libopencl1 | libopencl-1.1-1, ocl-icd-libopencl1 (>= 1.0) | amd-libopencl1 | libopencl-1.2-1 logs/fglrx-driver_15.7-1.build1:shlibs:Depends=libc6 (>= 2.3.3), libgcc1 (>= 1:4.1.1), ocl-icd-libopencl1 | amd-libopencl1 | libopencl1, ocl-icd-libopencl1 (>= 1.0) | amd-libopencl1 | libopencl-1.2-1, ocl-icd-libopencl1 (>= 1.0) | amd-libopencl1 | libopencl-1.1-1 # first build with --twice, so 2 output lines logs/fglrx-driver_15.7-1.build2:shlibs:Depends=libc6 (>= 2.3.3), libgcc1 (>= 1:4.1.1), ocl-icd-libopencl1 | amd-libopencl1 | libopencl1, ocl-icd-libopencl1 (>= 1.0) | amd-libopencl1 | libopencl-1.1-1, ocl-icd-libopencl1 (>= 1.0) | amd-libopencl1 | libopencl-1.2-1 # second build w/o --twice OK, let's repeat a few times until we get some successes: logs/fglrx-driver_15.7-1.build1:shlibs:Depends=libc6 (>= 2.3.3), libgcc1 (>= 1:4.1.1), ocl-icd-libopencl1 | amd-libopencl1 | libopencl1, ocl-icd-libopencl1 (>= 1.0) | amd-libopencl1 | libopencl-1.1-1, ocl-icd-libopencl1 (>= 1.0) | amd-libopencl1 | libopencl-1.2-1 logs/fglrx-driver_15.7-1.build1:shlibs:Depends=libc6 (>= 2.3.3), libgcc1 (>= 1:4.1.1), ocl-icd-libopencl1 | amd-libopencl1 | libopencl1, ocl-icd-libopencl1 (>= 1.0) | amd-libopencl1 | libopencl-1.1-1, ocl-icd-libopencl1 (>= 1.0) | amd-libopencl1 | libopencl-1.2-1 logs/fglrx-driver_15.7-1.build2:shlibs:Depends=libc6 (>= 2.3.3), libgcc1 (>= 1:4.1.1), ocl-icd-libopencl1 | amd-libopencl1 | libopencl1, ocl-icd-libopencl1 (>= 1.0) | amd-libopencl1 | libopencl-1.2-1, ocl-icd-libopencl1 (>= 1.0) | amd-libopencl1 | libopencl-1.1-1 # not reproducible logs/fglrx-driver_15.7-1.build1:shlibs:Depends=libc6 (>= 2.3.3), libgcc1 (>= 1:4.1.1), ocl-icd-libopencl1 | amd-libopencl1 | libopencl1, ocl-icd-libopencl1 (>= 1.0) | amd-libopencl1 | libopencl-1.2-1, ocl-icd-libopencl1 (>= 1.0) | amd-libopencl1 | libopencl-1.1-1 logs/fglrx-driver_15.7-1.build1:shlibs:Depends=libc6 (>= 2.3.3), libgcc1 (>= 1:4.1.1), ocl-icd-libopencl1 | amd-libopencl1 | libopencl1, ocl-icd-libopencl1 (>= 1.0) | amd-libopencl1 | libopencl-1.1-1, ocl-icd-libopencl1 (>= 1.0) | amd-libopencl1 | libopencl-1.2-1 logs/fglrx-driver_15.7-1.build2:shlibs:Depends=libc6 (>= 2.3.3), libgcc1 (>= 1:4.1.1), ocl-icd-libopencl1 | amd-libopencl1 | libopencl1, ocl-icd-libopencl1 (>= 1.0) | amd-libopencl1 | libopencl-1.1-1, ocl-icd-libopencl1 (>= 1.0) | amd-libopencl1 | libopencl-1.2-1 # reproducible logs/fglrx-driver_15.7-1.build1:shlibs:Depends=libc6 (>= 2.3.3), libgcc1 (>= 1:4.1.1), ocl-icd-libopencl1 | amd-libopencl1 | libopencl1, ocl-icd-libopencl1 (>= 1.0) | amd-libopencl1 | libopencl-1.1-1, ocl-icd-libopencl1 (>= 1.0) | amd-libopencl1 | libopencl-1.2-1 logs/fglrx-driver_15.7-1.build1:shlibs:Depends=libc6 (>= 2.3.3), libgcc1 (>= 1:4.1.1), ocl-icd-libopencl1 | amd-libopencl1 | libopencl1, ocl-icd-libopencl1 (>= 1.0) | amd-libopencl1 | libopencl-1.2-1, ocl-icd-libopencl1 (>= 1.0) | amd-libopencl1 | libopencl-1.1-1 logs/fglrx-driver_15.7-1.build2:shlibs:Depends=libc6 (>= 2.3.3), libgcc1 (>= 1:4.1.1), ocl-icd-libopencl1 | amd-libopencl1 | libopencl1, ocl-icd-libopencl1 (>= 1.0) | amd-libopencl1 | libopencl-1.1-1, ocl-icd-libopencl1 (>= 1.0) | amd-libopencl1 | libopencl-1.2-1 # not reproducible logs/fglrx-driver_15.7-1.build1:shlibs:Depends=libc6 (>= 2.3.3), libgcc1 (>= 1:4.1.1), ocl-icd-libopencl1 | amd-libopencl1 | libopencl1, ocl-icd-libopencl1 (>= 1.0) | amd-libopencl1 | libopencl-1.2-1, ocl-icd-libopencl1 (>= 1.0) | amd-libopencl1 | libopencl-1.1-1 logs/fglrx-driver_15.7-1.build1:shlibs:Depends=libc6 (>= 2.3.3), libgcc1 (>= 1:4.1.1), ocl-icd-libopencl1 | amd-libopencl1 | libopencl1, ocl-icd-libopencl1 (>= 1.0) | amd-libopencl1 | libopencl-1.2-1, ocl-icd-libopencl1 (>= 1.0) | amd-libopencl1 | libopencl-1.1-1 logs/fglrx-driver_15.7-1.build2:shlibs:Depends=libc6 (>= 2.3.3), libgcc1 (>= 1:4.1.1), ocl-icd-libopencl1 | amd-libopencl1 | libopencl1, ocl-icd-libopencl1 (>= 1.0) | amd-libopencl1 | libopencl-1.2-1, ocl-icd-libopencl1 (>= 1.0) | amd-libopencl1 | libopencl-1.1-1 # reproducible, but the other way around Andreas ___ Reproducible-builds mailing list Reproducible-buil
Re: [Reproducible-builds] dh_shlibdeps dependency ordering not stable if alternate dependency templates are used
On Thu, Jul 09, 2015 at 08:23:12PM +0200, Holger Levsen wrote: > > The issue is nondeterministic - a first rebuild after partly fixing > > another reproducibility issue has not shown this again. > > > btw: https://reproducible.debian.net/rb-pkg/unstable/amd64/pyopencl.html I recall some other cases, where it turned out that the problem is not dpkg's and neither dh's. from dpkg-gencontrol(1): The order of dependencies is preserved as best as possible: if any dependency must be discarded due to another dependency appearing further in the field, the superseding dependency will take the place of the discarded one. That means that whatever passes them to dpkg, has to sort them. I quickly looked to dh_shlibdeps, and (if i got that right) it just call dpkg-shlibdeps. Now I don't have a clue of the order used by this one, and the manpage is way too long to be read in 5 minutes, but I'm fairly sure we didn't patch that file (at least, the changelog does not state so). -- 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: Digital 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] dh_shlibdeps dependency ordering not stable if alternate dependency templates are used
Hi,
On Donnerstag, 9. Juli 2015, Andreas Beckmann wrote:
> no, you need to test something that uses both OpenCL 1.1 and OpenCL 1.2
> functions, e.g. amd-clinfo, erlang-cl, python{,3}-pyopencl{,-dbg}. That
> list is complete - all rdepends of the libopencl-1.2-1 virtual package.
any of these in main?
> The issue is nondeterministic - a first rebuild after partly fixing
> another reproducibility issue has not shown this again.
btw: https://reproducible.debian.net/rb-pkg/unstable/amd64/pyopencl.html
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] dh_shlibdeps dependency ordering not stable if alternate dependency templates are used
On 2015-07-09 18:38, Holger Levsen wrote:
PPS: Similarly "complex" symbols files are used by ocl-icd-libopencl1
and nvidia-libopencl1, too.
>>> are these both only in non-free too?
>> ocl-icd is in main
>
> and reproducible when tested in our setup:
> https://reproducible.debian.net/ocl-icd
no, you need to test something that uses both OpenCL 1.1 and OpenCL 1.2
functions, e.g. amd-clinfo, erlang-cl, python{,3}-pyopencl{,-dbg}. That
list is complete - all rdepends of the libopencl-1.2-1 virtual package.
The issue is nondeterministic - a first rebuild after partly fixing
another reproducibility issue has not shown this again.
Andreas
___
Reproducible-builds mailing list
Reproducible-builds@lists.alioth.debian.org
http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/reproducible-builds
Re: [Reproducible-builds] dh_shlibdeps dependency ordering not stable if alternate dependency templates are used
Hi, On Donnerstag, 9. Juli 2015, Andreas Beckmann wrote: > Yes, I use a modified variant of your pbuilder script + hook scripts > that works with my build setup. > > that was with debhelper 9.20150628.0~reproducible3 > > > but since there may be some "dependency sanitization" pass in dpkg (? or > some other debhelper?) later on, maybe not dh_shlibdeps is to be blamed ... I think we've fixed these issues, maybe someone else has an idea? > >> PPS: Similarly "complex" symbols files are used by ocl-icd-libopencl1 > >> and nvidia-libopencl1, too. > > are these both only in non-free too? > ocl-icd is in main and reproducible when tested in our setup: https://reproducible.debian.net/ocl-icd 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] dh_shlibdeps dependency ordering not stable if alternate dependency templates are used
On 2015-07-09 18:05, Holger Levsen wrote: > have you been using our patched debhelper? see Yes, I use a modified variant of your pbuilder script + hook scripts that works with my build setup. that was with debhelper 9.20150628.0~reproducible3 but since there may be some "dependency sanitization" pass in dpkg (? or some other debhelper?) later on, maybe not dh_shlibdeps is to be blamed ... >> PPS: Similarly "complex" symbols files are used by ocl-icd-libopencl1 >> and nvidia-libopencl1, too. > > are these both only in non-free too? ocl-icd is in main Andreas ___ Reproducible-builds mailing list Reproducible-builds@lists.alioth.debian.org http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/reproducible-builds
Re: [Reproducible-builds] dh_shlibdeps dependency ordering not stable if alternate dependency templates are used
Hi Andreas,
On Donnerstag, 9. Juli 2015, Andreas Beckmann wrote:
> [ please keep me Cc:ed ]
done
> Control files: lines which differ (wdiff format)
>
> Depends:
> libc6 (>= 2.3.3),
> libgcc1 (>= 1:4.1.1),
> ocl-icd-libopencl1 | amd-libopencl1 | libopencl1,
> ocl-icd-libopencl1 (>= 1.0) | amd-libopencl1 | [-libopencl-1.2-1,-]
> {+libopencl-1.1-1,+}
> ocl-icd-libopencl1 (>= 1.0) | amd-libopencl1 | [-libopencl-1.1-1-]
> {+libopencl-1.2-1+}
>
>
> The only difference is the ordering of the dependencies generated by
> dh_shlibdeps (?).
have you been using our patched debhelper? see
https://wiki.debian.org/ReproducibleBuilds/ExperimentalToolchain
> PPS: Similarly "complex" symbols files are used by ocl-icd-libopencl1
> and nvidia-libopencl1, too.
are these both only in non-free too?
> PPPS: I haven't tried to see whether this unreproducibility is
> reproducible.
:-)
Thanks for caring + investigating this!
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
[Reproducible-builds] dh_shlibdeps dependency ordering not stable if alternate dependency templates are used
[ please keep me Cc:ed ]
Hi,
I'm just looking into reproducibility of fglrx-driver/non-free and saw
some toolchain issue resulting in unreproducible packages:
debdiff b1/amd-clinfo_15.5-2_amd64.deb b2/amd-clinfo_15.5-2_amd64.deb
(manually wrapped for better readability)
File lists identical (after any substitutions)
Control files: lines which differ (wdiff format)
Depends:
libc6 (>= 2.3.3),
libgcc1 (>= 1:4.1.1),
ocl-icd-libopencl1 | amd-libopencl1 | libopencl1,
ocl-icd-libopencl1 (>= 1.0) | amd-libopencl1 | [-libopencl-1.2-1,-]
{+libopencl-1.1-1,+}
ocl-icd-libopencl1 (>= 1.0) | amd-libopencl1 | [-libopencl-1.1-1-]
{+libopencl-1.2-1+}
The only difference is the ordering of the dependencies generated by
dh_shlibdeps (?).
The symbols file from amd-libopencl1 that is used to generate these
dependencies makes use of alternate dependency templates and more than
one of the alternate templates are needed for the final dependencies:
===
#
libOpenCL.so.1 ocl-icd-libopencl1 | #PACKAGE# #MINVER# | libopencl1
# symbols specific to this implementation - would forbid using alternate
implementations
| #PACKAGE# #MINVER#
# symbols conforming to the OpenCL standards - can use alternate
implementations
| ocl-icd-libopencl1 (>= 1.0) | #PACKAGE# #MINVER# | libopencl-1.1-1
| ocl-icd-libopencl1 (>= 1.0) | #PACKAGE# #MINVER# | libopencl-1.2-1
| ocl-icd-libopencl1 (>= 2.2.0) | #PACKAGE# #MINVER# | libopencl-2.0-1
# As AMD uses versioned symbols, we use this information instead of
# listing all symbols.
(symver|optional)OPENCL_1.0 0 2
(symver|optional)OPENCL_1.1 0 2
(symver|optional)OPENCL_1.2 0 3
(symver|optional)OPENCL_2.0 1:14 4
===
Andreas
PS: As an additional reproducibility torturing measure I used the
pbuilder --twice option for the first build.
PPS: Similarly "complex" symbols files are used by ocl-icd-libopencl1
and nvidia-libopencl1, too.
PPPS: I haven't tried to see whether this unreproducibility is reproducible.
___
Reproducible-builds mailing list
Reproducible-builds@lists.alioth.debian.org
http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/reproducible-builds
