Your message dated Tue, 06 Oct 2020 12:06:29 -0700 with message-id <877ds3dvii.fsf@ponder> and subject line Re: Bug#850284: reprotest: add a mode to automatically attempt to detect which variations cause unreproducibility has caused the Debian Bug report #850284, regarding reprotest: add a mode to automatically attempt to detect which variations cause unreproducibility to be marked as done.
This means that you claim that the problem has been dealt with. If this is not the case it is now your responsibility to reopen the Bug report if necessary, and/or fix the problem forthwith. (NB: If you are a system administrator and have no idea what this message is talking about, this may indicate a serious mail system misconfiguration somewhere. Please contact ow...@bugs.debian.org immediately.) -- 850284: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=850284 Debian Bug Tracking System Contact ow...@bugs.debian.org with problems
--- Begin Message ---Package: reprotest Version: 0.4 Severity: wishlist Dear Maintainer, One idea that was brought up at RWS2 in Berlin (I forgot who came up with it now, sorry) is to add a mode to automatically attempt to detect which variations cause a package to be unreproducible. For example, given variations {a, b, c}, if varying none of these results in a reproducible build, but varying all of them makes it unreproducible, then reprotest could automatically try to figure out which combinations of {a, b, c} "cause" the unreproducibility. Note that this is not as simple as a "bisect" algorithm which assumes that the items to be tested are in some linear order. In fact, it's unclear if we can make the algorithm (using the above example) more efficient than the brute force method of "test a, test b, test c". X -- System Information: Debian Release: stretch/sid APT prefers testing APT policy: (990, 'testing'), (500, 'unstable-debug'), (500, 'testing-debug'), (300, 'unstable'), (200, 'experimental'), (1, 'experimental-debug') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 4.8.0-2-amd64 (SMP w/4 CPU cores) Locale: LANG=en_GB.utf8, LC_CTYPE=en_GB.utf8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Init: systemd (via /run/systemd/system) Versions of packages reprotest depends on: ii apt-utils 1.4~beta2 ii diffoscope 63 ii libdpkg-perl 1.18.18 ii procps 2:3.3.12-3 ii python3-debian 0.1.29 ii python3-pkg-resources 32.0.0-1 pn python3:any <none> Versions of packages reprotest recommends: ii disorderfs 0.5.1-1 ii locales-all 2.24-8 Versions of packages reprotest suggests: ii autodep8 0.8 ii qemu-system 1:2.7+dfsg-3+b1 ii qemu-utils 1:2.7+dfsg-3+b1 ii schroot 1.6.10-2+b2 -- no debconf information
--- End Message ---
--- Begin Message ---Version: 0.7.1 On 2017-01-05, Ximin Luo wrote: > One idea that was brought up at RWS2 in Berlin (I forgot who came up with it > now, sorry) is to add a mode to automatically attempt to detect which > variations cause a package to be unreproducible. This was implemented with the --auto-build option: group1_0.add_argument('--auto-build', default=False, action='store_true', help='Automatically perform builds to try to determine which specific ' 'variations cause unreproducibility, potentially up to and including ' 'the ones specified by --variations and --vary. Conflicts with ' '--extra-build.') > For example, given variations {a, b, c}, if varying none of these results in a > reproducible build, but varying all of them makes it unreproducible, then > reprotest could automatically try to figure out which combinations of {a, b, > c} > "cause" the unreproducibility. It doesn't figure out combinations, e.g. if a+b cause a issue that only individually running a or only individually running b individually would not trigger, but I'm guessing such complicated issues combinations are pretty rare. If you think this is important enough or I missed something in understanding the issue, please re-open. > Note that this is not as simple as a "bisect" algorithm which assumes that the > items to be tested are in some linear order. In fact, it's unclear if we can > make the algorithm (using the above example) more efficient than the brute > force method of "test a, test b, test c". I think the --auto-build option essentially implements the brute-force option. live well, vagrant
signature.asc
Description: PGP signature
--- End Message ---
_______________________________________________ Reproducible-builds mailing list Reproducible-builds@alioth-lists.debian.net https://alioth-lists.debian.net/cgi-bin/mailman/listinfo/reproducible-builds
