Bug#893183: diffoscope FTBFS with openjdk-9
Source: diffoscope
Version: 91
Severity: serious
https://tests.reproducible-builds.org/debian/rb-pkg/unstable/amd64/diffoscope.html
...
___ test_diff_javap
differences_javap = []
@skip_unless_tool_is_at_least('javap', javap_version, '1.8')
def test_diff_javap(differences_javap):
> diff(differences_javap, 'javap_class_expected_diff')
differences_javap = []
tests/comparators/test_java.py:84:
_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _
differences = []
expected_diff_file = 'javap_class_expected_diff'
def diff(differences, expected_diff_file):
expected_diff = get_data(expected_diff_file)
> assert differences[0].unified_diff == expected_diff
E assert '@@ -34,13 +3..."Test.java"\n' == '@@ -31,13 +31..."Test.java"\n'
E - @@ -34,13 +34,13 @@
E ? ^ ^
E + @@ -31,13 +31,13 @@
E ? ^ ^
Eline 1: 0
E
E public static int main(java.lang.String[]);
Edescriptor: ([Ljava/lang/String;)I
E - flags: (0x0009) ACC_PUBLIC, ACC_STATIC
E ?-
E + flags: ACC_PUBLIC, ACC_STATIC
ECode:
E stack=1, locals=1, args_size=1
E - 0: bipush42
E - 2: ireturn
E + 0: iconst_m1
E + 1: ireturn
E LineNumberTable:
Eline 3: 0
E}
ESourceFile: "Test.java"
differences = []
expected_diff = '@@ -31,13 +31,13 @@\n line 1: 0\n \n public static
int main(java.lang.String[]);\n descriptor: ([Ljava/... 0:
iconst_m1\n+ 1: ireturn\n LineNumberTable:\n line 3: 0\n
}\n SourceFile: "Test.java"\n'
expected_diff_file = 'javap_class_expected_diff'
tests/comparators/test_java.py:66: AssertionError
-- Captured log setup --
__init__.py127 DEBUGLoaded 65 comparator classes
specialize.py 40 DEBUGUsing ClassFile for
/build/1st/diffoscope-91/.pybuild/cpython3_3.6/build/tests/data/Test1.class
specialize.py 40 DEBUGUsing ClassFile for
/build/1st/diffoscope-91/.pybuild/cpython3_3.6/build/tests/data/Test2.class
command.py 38 DEBUGExecuting javap -verbose -constants -s
-l -private
/build/1st/diffoscope-91/.pybuild/cpython3_3.6/build/tests/data/Test1.class
command.py 38 DEBUGExecuting javap -verbose -constants -s
-l -private
/build/1st/diffoscope-91/.pybuild/cpython3_3.6/build/tests/data/Test2.class
diff.py177 DEBUGRunning diff -aU7
/tmp/tmpff97aoah_diffoscope/fifo1 /tmp/tmpff97aoah_diffoscope/fifo2
diff.py193 DEBUGdiff -aU7
/tmp/tmpff97aoah_diffoscope/fifo1 /tmp/tmpff97aoah_diffoscope/fifo2: returncode
1, parsed True
== 2 failed, 364 passed, 18 skipped in 992.92 seconds ==
E: pybuild pybuild:323: test: plugin distutils failed with: exit code=1: cd
/build/1st/diffoscope-91/.pybuild/cpython3_3.6/build; python3.6 -m pytest -vv
-r sxX -l --cov=diffoscope --cov-report=term-missing --cov-report=html
dh_auto_test: pybuild --test --test-pytest -i python{version} -p 3.6 returned
exit code 13
make: *** [debian/rules:35: binary] Error 25
___
Reproducible-builds mailing list
Reproducible-builds@lists.alioth.debian.org
http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/reproducible-builds
Bug#884386: reprotest FTBFS: test failure
Source: reprotest
Version: 0.7.5
Severity: serious
https://buildd.debian.org/status/fetch.php?pkg=reprotest=all=0.7.5=1513272013=0
...
===
Reproduction successful
===
No differences in ./../*.deb
5bd731e16d34c2dc16241cdcccf584ccd6f828b7d676f9608ea55df3e84d9190
./../reprotest_0.7.5_all.deb
However, other factors may still make the build unreproducible; try re-running
with --vary=+all.
..
tests/test_shell.py ..
=== FAILURES ===
test_variations[null-num_cpus]
virtual_server = ['null'], captures = 'num_cpus'
@pytest.mark.parametrize('captures', list(VARIATIONS.keys()))
def test_variations(virtual_server, captures):
expected = captures not in TEST_VARIATIONS
with setup_logging(False):
> check_reproducibility('python3 mock_build.py ' + captures,
> virtual_server, expected)
tests/test_reprotest.py:90:
_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _
command = 'python3 mock_build.py num_cpus', virtual_server = ['null']
reproducible = False
def check_reproducibility(command, virtual_server, reproducible):
result = reprotest.check(
reprotest.TestArgs.of(command, 'tests', 'artifact'),
reprotest.TestbedArgs.of(virtual_server),
Variations.of(VariationSpec.default(TEST_VARIATIONS)))
> assert result == reproducible
E assert True == False
tests/test_reprotest.py:28: AssertionError
= 1 failed, 20 passed in 61.23 seconds =
usage: reprotest --help []
reprotest [options] [-c ]
[]
[-- [ ...]]
reprotest [options] [-s ]
[]
[-- [ ...]]
reprotest: error: unrecognized arguments: -d
usage: reprotest --help []
reprotest [options] [-c ]
[]
[-- [ ...]]
reprotest [options] [-s ]
[]
[-- [ ...]]
reprotest: error: unrecognized arguments: null -d
usage: reprotest --help []
reprotest [options] [-c ]
[]
[-- [ ...]]
reprotest [options] [-s ]
[]
[-- [ ...]]
reprotest: error: unrecognized arguments: null -d
usage: reprotest --help []
reprotest [options] [-c ]
[]
[-- [ ...]]
reprotest [options] [-s ]
[]
[-- [ ...]]
reprotest: error: unrecognized arguments: -d
usage: reprotest --help []
reprotest [options] [-c ]
[]
[-- [ ...]]
reprotest [options] [-s ]
[]
[-- [ ...]]
reprotest: error: unrecognized arguments: -d
usage: reprotest --help []
reprotest [options] [-c ]
[]
[-- [ ...]]
reprotest [options] [-s ]
[]
[-- [ ...]]
reprotest: error: unrecognized arguments: null -d
usage: reprotest --help []
reprotest [options] [-c ]
[]
[-- [ ...]]
reprotest [options] [-s ]
[]
[-- [ ...]]
reprotest: error: unrecognized arguments: null -d
usage: reprotest --help []
reprotest [options] [-c ]
[]
[-- [ ...]]
reprotest [options] [-s ]
[]
[-- [ ...]]
reprotest: error: unrecognized arguments: -d
ERROR: InvocationError: '/<>/.tox/py36/bin/python -m coverage run
--omit .tox/* --parallel -m py.test -s tests/'
___ summary
ERROR: py36: commands failed
debian/rules:27: recipe for target 'override_dh_auto_test' failed
make[1]: *** [override_dh_auto_test] Error 1
___
Reproducible-builds mailing list
Reproducible-builds@lists.alioth.debian.org
http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/reproducible-builds
QFINDTESTDATA uses __FILE__
Control: reassign -1 qtbase5-dev Control: reassign 876917 qtbase5-dev Control: reassign 876933 qtbase5-dev Control: forcemerge -1 876917 876933 Control: retitle -1 QFINDTESTDATA uses __FILE__ Control: severity -1 normal Control: affects -1 src:karchive src:ki18n src:kcodecs src:kparts thanks The problem is the following implementation in /usr/include/x86_64-linux-gnu/qt5/QtTest/qtestcase.h: # define QFINDTESTDATA(basepath)\ QTest::qFindTestData(basepath, __FILE__, __LINE__) With the patched gcc in the unstable reproducible builds setting __FILE__ to something other value, this does no longer find the test data. I do not really see any reason for blaming the users here for using a documented public Qt API for accesssing test data in the source directory: http://doc.qt.io/qt-5/qtest.html#QFINDTESTDATA I've added reproducible-builds@lists.alioth.debian.org to Cc for giving input what a reproducible and portable implementation might be for Qt. cu Adrian -- "Is there not promise of rain?" Ling Tan asked suddenly out of the darkness. There had been need of rain for many days. "Only a promise," Lao Er said. Pearl S. Buck - Dragon Seed ___ Reproducible-builds mailing list Reproducible-builds@lists.alioth.debian.org http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/reproducible-builds
Re: Bug#844431: Revised patch: seeking seconds
On Wed, Aug 16, 2017 at 03:43:00PM +, Ximin Luo wrote: > Adrian Bunk: > > On Wed, Aug 16, 2017 at 11:37:00AM +, Ximin Luo wrote: > >> [..] > >> > >> Fair enough. I actually spotted that but thought it was better to get > >> "something" into Policy rather than nitpick. I guess other people were > >> thinking similar things. Well, lesson learnt, I will be more forceful next > >> time. > >> ... > > > > What is the point of getting "something" into policy, when it is known > > to not match existing practice and that what is being added to policy > > will be ignored by everyone? > > > >> The sentence I amended said "most environment variables" so our intent is > >> clear. > >> ... > > > > This is not about "intent", this is about giving an exact definition > > of reproducibility for Debian. > > > > The definition should then match what is recorded in .buildinfo > > and what the reproducible builds infrastructure is testing. > > > > The exact wording that was added, was a too-loose requirement. I'm now > proposing to make the requirement more strict, in accordance with the tests > that we're running. Do you have any comments on my proposal? >... Will both dpkg-genbuildinfo and the reproducible builds infrastructure implement this definition? Any definition is fine for me as long as it will match what is actually being done.[1] > X cu Adrian [1] not excluding future changes, but at the time the policy will be published it should match reality -- "Is there not promise of rain?" Ling Tan asked suddenly out of the darkness. There had been need of rain for many days. "Only a promise," Lao Er said. Pearl S. Buck - Dragon Seed ___ Reproducible-builds mailing list Reproducible-builds@lists.alioth.debian.org http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/reproducible-builds
Re: Bug#844431: Revised patch: seeking seconds
On Wed, Aug 16, 2017 at 10:24:07AM +, Mattia Rizzolo wrote: > On Tue, 15 Aug 2017, 11:02 p.m. Adrian Bunk <b...@debian.org> wrote: > > > Tracker: > > https://tracker.debian.org/pkg/hsqldb1.8.0 > > "Does not build reproducibly during testing" > > And indeed it's not reproducible according to policy: it's storing the > build user at the very least. >... What makes you so confident that this package is not reproducible according to policy? According to policy, storing the value of $USER in the binary is clearly permitted for a reproducible package. [1] As long as the reproducible builds infrastructure varies $USER instead of following the policy definition, it is not suitable for determining whether or not a package is reproducible according to policy. And what the reproducible builds infrastructure pushes as Does not build reproducibly during testing to tracker and DDPO is therefore not usable for determining reproducibility according to policy. cu Adrian [1] I haven't checked what exactly this package does -- "Is there not promise of rain?" Ling Tan asked suddenly out of the darkness. There had been need of rain for many days. "Only a promise," Lao Er said. Pearl S. Buck - Dragon Seed ___ Reproducible-builds mailing list Reproducible-builds@lists.alioth.debian.org http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/reproducible-builds
Re: Bug#844431: Revised patch: seeking seconds
On Tue, Aug 15, 2017 at 01:00:00PM -0700, Russ Allbery wrote: >... > This in absolutely no way constrains the reproducible build team from > working on raising the bar in the future, just as the absence of this > language from Policy did not prevent them from starting to work on this > problem four years ago. They should continue to work on making package > builds more reproducible and raising the bar for reproducibility as makes > sense for their goals and judging the impact of that. Once any new > requirements reach maturity and look feasible and have some project > committment, we'll change Policy to set a new baseline for the whole > project. But the reproducible builds work should not *wait* for that, and > should definitely push forward and experiment just as they have up until > now. >... This is not about experimenting for raising the bar in the future. This is about the reproducible builds team not using policy as a stick for claiming a bar higher than what policy actually defines. Is it really allowed to claim that a package is not reproducible, when it actually is reproducible according to policy? Let me explain with examples how this information is presented to maintainers: Tracker: https://tracker.debian.org/pkg/hsqldb1.8.0 "Does not build reproducibly during testing" DDPO: https://qa.debian.org/developer.php?email=debian-openoff...@lists.debian.org red "unrep" entries Maintainer dashboard: https://udd.debian.org/dmd/?email1=debian-openoffice%40lists.debian.org red "(un)reproducible" entries [1] Let's look at the mdds package, that has red unreproducible entries in the maintainer dashboard: https://tests.reproducible-builds.org/debian/rb-pkg/unstable/amd64/mdds.html mdds is unreproducible only in sid since more things (including the build path) are varied there. The information behind "differences" confirms that the build path is the only issue. According to policy, mdds is reproducible. Unless policy is supposed to be completely detached from reality, the criteria for claiming in various places that a package is unreproducible have to match the policy definition of reproducibility. cu Adrian [1] the FTBFS entries are actually problems in the reproducible infrastructure -- "Is there not promise of rain?" Ling Tan asked suddenly out of the darkness. There had been need of rain for many days. "Only a promise," Lao Er said. Pearl S. Buck - Dragon Seed ___ Reproducible-builds mailing list Reproducible-builds@lists.alioth.debian.org http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/reproducible-builds
Re: Bug#844431: Revised patch: seeking seconds
On Tue, Aug 15, 2017 at 11:49:22AM -0700, Russ Allbery wrote: > Adrian Bunk <b...@debian.org> writes: > > > I would expect the reproducible builds team to not submit any bugs > > regarding varied environment variables as long as as the official > > definition of reproducibility in policy states that this is not required > > for a package to be reproducible. > > I believe the planned next step here is to publish the *.buildinfo files, > which contain a specification of the environment variables the build cares > about, and then Policy can be modified to include a description of > *.buildinfo files and how to use them. As part of those changes, we'd > certainly update the definition of reproducible to reference matching the > environment specified in the corresponding *.buildinfo file. I do understand that. My point is that we now have an official definition what is required for a package to be reproducible, and what is not required. Future policy versions might change this definition, but whatever latest policy states has to be the definition used by both packages and the reproducible builds team. Another example is that a package that is reproducible according to the policy definition must not show up as non-reproducible in tracker/DDPO based on results from the reproducible infrastructure. cu Adrian -- "Is there not promise of rain?" Ling Tan asked suddenly out of the darkness. There had been need of rain for many days. "Only a promise," Lao Er said. Pearl S. Buck - Dragon Seed ___ Reproducible-builds mailing list Reproducible-builds@lists.alioth.debian.org http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/reproducible-builds
Re: Use of .buildinfo in buster
On Mon, Jul 24, 2017 at 09:46:27PM +0100, Chris Lamb wrote: >... > Related to this is how we show/expose reproducibility to end users, if it > all. Some discussion of sorts is happening on #863622 (src:apt). >... How is this supposed to work for DSAs? Do you want to claim a security update is reproducible without checking, or do you want to delay DSAs until the packages have been reproduced for all architectures? Why should this be a per-package user-visible issue instead of aiming at giving guarantess for all packages in main? There is also a certain amount of WTF: This would make a relatively hard to exploit issue appear more worrisome to a user than installing a browser engine with zero security support and more than 100 unfixed CVEs. > Regards, cu Adrian -- "Is there not promise of rain?" Ling Tan asked suddenly out of the darkness. There had been need of rain for many days. "Only a promise," Lao Er said. Pearl S. Buck - Dragon Seed ___ Reproducible-builds mailing list Reproducible-builds@lists.alioth.debian.org http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/reproducible-builds
Re: Status update from the Reproducible Builds project
>... > Debian Policy > = > > We are in the process of making reproducibility of packages something > properly documented in policy. Writing patches for policy is not easy, > so we welcome input from everyone to be able to better consider all the > needed facets. See bug #844431 [16] for it. > Also, we wish to remind everyone that Debian Policy aims at documenting > current practices, it's not a "stick" to impose new rules. That said, > we believe reproducible builds to be among the best practices today. >... If it could be interpreted in the future to include things that are not current practice today, it would be a stick to impose new rules. The main problem is the lack of an exact definition what "packages build in a reproducible manner" includes, and what not. Bill already explained that "it is possible to reproduce" is a much easier problem to solve than "it will always be reproduced". I would suggest a top-down approach to that: What are the high-level guarantees reproducible builds plans to make for all packages in buster? What exactly is required from every single package for that, and also realistic to achieve for buster? Once you have these plus a list of all remaining bugs, you can go to the release team asking whether these can be considered as release critical for buster. At that point documenting this status quo for policy should be straightforward. cu Adrian -- "Is there not promise of rain?" Ling Tan asked suddenly out of the darkness. There had been need of rain for many days. "Only a promise," Lao Er said. Pearl S. Buck - Dragon Seed ___ Reproducible-builds mailing list Reproducible-builds@lists.alioth.debian.org http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/reproducible-builds
Use of .buildinfo in buster
On Sun, Jul 23, 2017 at 01:54:32PM +0200, Mattia Rizzolo wrote: >... > Buildinfo files > === > > We have been playing with .buildinfo files [9] for more than two years, > and dpkg finally started producing them with version 1.18.11 (Nov 2016). > > Some weeks later dak started to store those files, and they are > accessible to all DDs in > mirror.ftp-master.debian.org:/srv/ftp-master.debian.org/buildinfo. > There are 214791 unique .buildifo files at the time of writing. > > Our dreams for those files do not end there, however; we want those > files be published and much more. You can see in [10] more details > on these files as we thought of them, and the current format as > implemented by dpkg is available in deb-buildinfo(5) [11]. > > We are currently blocked awaiting feedback from ftp-masters on this (see > #763822 [12]). Please consider helping out if you can! > > We also have a proof of concept website reachable at > https://buildinfo.debian.net that is aiming to collect .buildinfo files > coming from everywhere; currently only our CI is systematically pushing > .buildinfo files there, but there is another open bug for ftp-master to > push the .buildinfo of officially built packages there as well (see > #862073 [13]). Also note that the service is open to anyone without > authentication (by design), so everybody could push their own .buildinfo > file with a simple HTTP POST. >... What and how is expected to work based on .buildinfo files in buster? Usecases based on .buildinfo files uploaded by random people are more on the fringe side, a more relevant topic is how users can get the .buildinfo files from the binaries they are using (or plan to use). What tool(s) in buster will allow users to download the .buildinfo files matching the packages they are using and what is the canonical location where such tools will download them from (Debian mirrors or buildinfo.debian.net)? If wide adoption of .buildinfo is desired, will providing and downloading .buildinfo also seamlessly work for local repositories in cases where the .buildinfo must not leak to a public place? Is the sig-repos infrastructure expected to be available for buster, and how would that interact for example with security updates installed through unattended-upgrades? Likely none of the above has an answer right now, and that is OK. My point is that these are topics that have to be started soon if it shouldn't be too late for buster. cu Adrian -- "Is there not promise of rain?" Ling Tan asked suddenly out of the darkness. There had been need of rain for many days. "Only a promise," Lao Er said. Pearl S. Buck - Dragon Seed ___ Reproducible-builds mailing list Reproducible-builds@lists.alioth.debian.org http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/reproducible-builds
Re: source-only builds and .buildinfo
On Thu, Jun 22, 2017 at 08:26:00AM +, Ximin Luo wrote: >... > One way to give security that is independent of third parties, is to provide > some sort of mathematically-verifiable proof. However the world isn't at that > stage yet for compiler technology. What changes in compiler technology are you hoping for? The main reason for fixing optimizer bugs in the compiler is to get different (no longer buggy) output. >... > For users that can't directly verify everything that they themselves run, one > "next best thing" they can do is to check that different parties that they > trust - or many parties that they don't trust, that they nevertheless believe > are probably not all colluding to attack them - claimed to have performed the > build or verified each others' proofs. > > So, the more buildinfo files we have, from different parties (DDs, the Debian > archive, etc) the better this is for users, because they have more sources of > claims. How much they "trust" each individual source, is indeed not something > that is concretely measurable and no existing security system tries to model > this more precisely unfortunately; however I think we can all agree that > "more is better" here. >... I don't see how more random information is helpful for users. One or more trusted instances verifying that all packages in a release were built from their sources is the information that would be useful for users. For some users it would also be important to be able to verify this for the whole archive themselves. > X cu Adrian -- "Is there not promise of rain?" Ling Tan asked suddenly out of the darkness. There had been need of rain for many days. "Only a promise," Lao Er said. Pearl S. Buck - Dragon Seed ___ Reproducible-builds mailing list Reproducible-builds@lists.alioth.debian.org http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/reproducible-builds
Re: source-only builds and .buildinfo
On Wed, Jun 21, 2017 at 09:30:14AM +, Holger Levsen wrote: > Hi, > > trigger warning: nitpicking. > > On Wed, Jun 21, 2017 at 11:34:17AM +0300, Adrian Bunk wrote: > > > I do source-only uploads because i don't want the binaries built on my > > > own personal infrastructure to reach the public. But i want to upload > > > the .buildinfo because i want to provide a corroboration of what i > > > *expect* the buildds to produce. > > If you expect that, then your expectation is incorrect. > > I actually think that dkg's expectation is right, "just" that reality is > wrong. > > The design of the Debian buildd network is from times when machines were much > less powerful than what we have today and it shows. > > I'd rather have deterministic builds than the current unpredictable mess. I understand what you want, but using buildinfo is not a good idea here. Based on how many broken binaries get uploaded from developers, the environment of the person uploading the sources is not a good basis for determining what package versions to install when building on the buildds. > cheers, > Holger cu Adrian -- "Is there not promise of rain?" Ling Tan asked suddenly out of the darkness. There had been need of rain for many days. "Only a promise," Lao Er said. Pearl S. Buck - Dragon Seed ___ Reproducible-builds mailing list Reproducible-builds@lists.alioth.debian.org http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/reproducible-builds
Re: source-only builds and .buildinfo
On Wed, Jun 21, 2017 at 10:09:00AM +, Ximin Luo wrote: > Adrian Bunk: > > On Wed, Jun 21, 2017 at 09:28:00AM +, Ximin Luo wrote: > >> Adrian Bunk: > >>> On Tue, Jun 20, 2017 at 02:47:20PM -0400, Daniel Kahn Gillmor wrote: > >>>> Hi Ian-- > >>>> > >>>> On Tue 2017-06-20 18:10:49 +0100, Ian Jackson wrote: > >>>>> A .buildinfo file is not useful for a source-only upload which is > >>>>> veried to be identical to the intended source as present in the > >>>>> uploader's version control (eg, by the use of dgit). > >>>>> > >>>>> Therefore, dgit should not include .buildinfos in source-only uploads > >>>>> it performs. If dgit sees that a lower-layer tool like > >>>>> dpkg-buildpackage provided a .buildinfo for a source-only upload, dgit > >>>>> should strip it out of .changes. > >>>> > >>>> I often do source-only uploads which include the .buildinfo. > >>>> > >>>> I do source-only uploads because i don't want the binaries built on my > >>>> own personal infrastructure to reach the public. But i want to upload > >>>> the .buildinfo because i want to provide a corroboration of what i > >>>> *expect* the buildds to produce. > >>>> ... > >>> > >>> If you expect that, then your expectation is incorrect. > >>> > >>> If you upload a package right now, chances are the buildds will use both > >>> older versions of some packages [1] and more recent versions of some > >>> other packages [2] than what you used. > >>> > >> > >> I think what dkg means here (and what we the R-B team has wanted for ages > >> and is working towards), is not that the buildds use the *versioned > >> dependencies* listed in the buildinfo, but produce the same *output > >> hashes* as what's in the buildinfo. > >> > >> The point being specifically that the dependencies used could change, but > >> if the output remains constant, we're more assured that the build was done > >> properly and reproducibly. > > > > How is that supposed to work when the compiler is not exactly identical? > > > > As an example, gcc-6 6.3.0-18 and gcc-6 6.3.0-19 will likely produce > > different output for every non-trivial piece of software. > > > > The reason is that every new gcc upload usually contains whatever > > bugfixes are on the upstream branch. > > > > It would depend on the situation which dependencies should be "irrelevant" > towards the final output, right. If the dependencies are different and the > buildinfo is different, it does not necessarily mean there is a problem, the > upload does not need to be rejected. But it's a signal that other people > (including the uploader) might want to re-try the build with the newer > dependencies. > > OTOH if the outputs match, we get more certainty, which is a good thing. >... "more certainty" on what exactly? "signal that other people might want to" is quite vague, what do you want to prove and how exactly should people spend time proving it? In the best case [1] we would know that the buildd on the one architecture that happens to be used by the person doing the source upload produced the same binaries. Once you start verifying that all binaries in the archive were built from the sources in the archive, this will automatically be covered. > X cu Adrian [1] excluding the binary-all special case -- "Is there not promise of rain?" Ling Tan asked suddenly out of the darkness. There had been need of rain for many days. "Only a promise," Lao Er said. Pearl S. Buck - Dragon Seed ___ Reproducible-builds mailing list Reproducible-builds@lists.alioth.debian.org http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/reproducible-builds
Re: source-only builds and .buildinfo
On Wed, Jun 21, 2017 at 09:28:00AM +, Ximin Luo wrote: > Adrian Bunk: > > On Tue, Jun 20, 2017 at 02:47:20PM -0400, Daniel Kahn Gillmor wrote: > >> Hi Ian-- > >> > >> On Tue 2017-06-20 18:10:49 +0100, Ian Jackson wrote: > >>> A .buildinfo file is not useful for a source-only upload which is > >>> veried to be identical to the intended source as present in the > >>> uploader's version control (eg, by the use of dgit). > >>> > >>> Therefore, dgit should not include .buildinfos in source-only uploads > >>> it performs. If dgit sees that a lower-layer tool like > >>> dpkg-buildpackage provided a .buildinfo for a source-only upload, dgit > >>> should strip it out of .changes. > >> > >> I often do source-only uploads which include the .buildinfo. > >> > >> I do source-only uploads because i don't want the binaries built on my > >> own personal infrastructure to reach the public. But i want to upload > >> the .buildinfo because i want to provide a corroboration of what i > >> *expect* the buildds to produce. > >> ... > > > > If you expect that, then your expectation is incorrect. > > > > If you upload a package right now, chances are the buildds will use both > > older versions of some packages [1] and more recent versions of some > > other packages [2] than what you used. > > > > I think what dkg means here (and what we the R-B team has wanted for ages and > is working towards), is not that the buildds use the *versioned dependencies* > listed in the buildinfo, but produce the same *output hashes* as what's in > the buildinfo. > > The point being specifically that the dependencies used could change, but if > the output remains constant, we're more assured that the build was done > properly and reproducibly. How is that supposed to work when the compiler is not exactly identical? As an example, gcc-6 6.3.0-18 and gcc-6 6.3.0-19 will likely produce different output for every non-trivial piece of software. The reason is that every new gcc upload usually contains whatever bugfixes are on the upstream branch. > X cu Adrian -- "Is there not promise of rain?" Ling Tan asked suddenly out of the darkness. There had been need of rain for many days. "Only a promise," Lao Er said. Pearl S. Buck - Dragon Seed ___ Reproducible-builds mailing list Reproducible-builds@lists.alioth.debian.org http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/reproducible-builds
Finding merged /usr bugs through reproducible builds?
Hi, could you change the reproducible builds to find bugs like #843433, ideally with a rebuild of everything that is currently building reproducibly? If one of the builds would use merged /usr and the other would not, then bugs like #843433 should show up as difference in the build. Thanks Adrian BTW: #843433 might not be found this way due to systemd not building reproducible, but similar bugs in many other packages could be found this way. -- "Is there not promise of rain?" Ling Tan asked suddenly out of the darkness. There had been need of rain for many days. "Only a promise," Lao Er said. Pearl S. Buck - Dragon Seed ___ Reproducible-builds mailing list Reproducible-builds@lists.alioth.debian.org http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/reproducible-builds
