[Reproducible-builds] Bug#819620: php-symfony-security-acl: FTBFS: Trying to configure method "getId" which cannot be configured because it does not exist, has not been specified, is final, or is stat
Source: php-symfony-security-acl Version: 2.8.0-2 Severity: serious Justification: fails to build from source User: reproducible-builds@lists.alioth.debian.org Usertags: ftbfs X-Debbugs-Cc: reproducible-builds@lists.alioth.debian.org Dear Maintainer, php-symfony-security-acl fails to build from source in unstable/amd64: [..] phpab \ --output autoload.php \ --template debian/autoload.php \ --blacklist '*\\tests\\*' \ . phpab %development% - Copyright (C) 2009 - 2016 by Arne Blankerts Scanning directory . Autoload file autoload.php generated. make[1]: Leaving directory '/home/lamby/temp/cdt.20160331085920.rjsZiobCPa/php-symfony-security-acl-2.8.0' debian/rules override_dh_auto_test make[1]: Entering directory '/home/lamby/temp/cdt.20160331085920.rjsZiobCPa/php-symfony-security-acl-2.8.0' phpunit --bootstrap autoload.php PHPUnit 5.2.12 by Sebastian Bergmann and contributors. S.. 63 / 167 ( 37%) E.. 126 / 167 ( 75%) . 167 / 167 (100%) Time: 190 ms, Memory: 10.00Mb There was 1 error: 1) Symfony\Component\Security\Acl\Tests\Domain\ObjectIdentityTest::testFromDomainObjectPrefersInterfaceOverGetId PHPUnit_Framework_MockObject_RuntimeException: Trying to configure method "getId" which cannot be configured because it does not exist, has not been specified, is final, or is static /home/lamby/temp/cdt.20160331085920.rjsZiobCPa/php-symfony-security-acl-2.8.0/Tests/Domain/ObjectIdentityTest.php:45 FAILURES! Tests: 167, Assertions: 464, Errors: 1, Skipped: 1. debian/rules:14: recipe for target 'override_dh_auto_test' failed make[1]: *** [override_dh_auto_test] Error 2 make[1]: Leaving directory '/home/lamby/temp/cdt.20160331085920.rjsZiobCPa/php-symfony-security-acl-2.8.0' debian/rules:3: recipe for target 'build' failed make: *** [build] Error 2 [..] The full build log is attached. Regards, -- ,''`. : :' : Chris Lamb `. `'` la...@debian.org / chris-lamb.co.uk `- php-symfony-security-acl.2.8.0-2.unstable.amd64.log.txt.gz Description: Binary data ___ Reproducible-builds mailing list Reproducible-builds@lists.alioth.debian.org http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/reproducible-builds
[Reproducible-builds] Bug#819619: dopewars: FTBFS: acinclude.m4:880: error: m4_copy: won't overwrite defined macro: glib_DEFUN
Source: dopewars Version: 1.5.12-16 Severity: serious Justification: fails to build from source User: reproducible-builds@lists.alioth.debian.org Usertags: ftbfs X-Debbugs-Cc: reproducible-builds@lists.alioth.debian.org Dear Maintainer, dopewars fails to build from source in unstable/amd64: [..] dh_autoreconf aclocal: warning: autoconf input should be named 'configure.ac', not 'configure.in' acinclude.m4:1: warning: ill-formed serial number 'AM1', expecting a version string with only digits and dots acinclude.m4:29: warning: underquoted definition of DP_EXPAND_DIR acinclude.m4:29: run info Automake 'Extending aclocal' acinclude.m4:29: or see http://www.gnu.org/software/automake/manual/automake.html#Extending-aclocal acinclude.m4:248: warning: the serial number must appear before any macro definition acinclude.m4:818: warning: the serial number must appear before any macro definition acinclude.m4:1810: warning: ill-formed serial number 'AM2', expecting a version string with only digits and dots acinclude.m4:1891: warning: the serial number must appear before any macro definition acinclude.m4:880: error: m4_copy: won't overwrite defined macro: glib_DEFUN acinclude.m4:880: the top level autom4te: /usr/bin/m4 failed with exit status: 1 aclocal: error: echo failed with exit status: 1 autoreconf: aclocal failed with exit status: 1 dh_autoreconf: autoreconf -f -i returned exit code 1 debian/rules:8: recipe for target 'override_dh_autoreconf' failed make[1]: *** [override_dh_autoreconf] Error 2 make[1]: Leaving directory '/home/lamby/temp/cdt.20160331085807.U0tnequjSk/dopewars-1.5.12' debian/rules:29: recipe for target 'build' failed make: *** [build] Error 2 [..] The full build log is attached. Regards, -- ,''`. : :' : Chris Lamb `. `'` la...@debian.org / chris-lamb.co.uk `- dopewars.1.5.12-16.unstable.amd64.log.txt.gz Description: Binary data ___ 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 build examples
Moin! On Thu, Mar 31, 2016 at 12:57:27AM +0200, Reiner Herrmann wrote: > > > > I have seen one which simply removed the timestamp from the executable. I do > > not consider that as a solution, it is just a quick and dirty workaround. > > I think it depends on the timestamp. In most cases they have no real > meaning/use to the user and there is no harm in removing them. So I > would say removing them where possible is actually a solution. > SOURCE_DATE_EPOCH can then be used as a "workaround" when upstream > insists on keeping timestamps or there are other reasons to keep it. It was not too difficult to replace \today in the tex file with a timestamp generated from SOURCE_DATE_EPOCH, so I did that. The date is used on the title page, so I think it makes sense to use this date like a version info. However, it took me two tries, since month names are not reproducible, so I had to use a format with numbers only. Why would I want to use a french month name in an english document? > > https://tests.reproducible-builds.org/rb-pkg/unstable/amd64/gle-graphics.html > > Thanks for fixing the issue mentioned there! > We are reviewing the issues mostly manually. The note in your example > was a bit outdated. We might also not always see _all_ issues in the diff. > Sometimes it is just too large and hides other issues. Perhaps this > was the reason why the PDF issue was not mentioned in the note. > But I just updated it. :) Thanks, I am not sure if this is correct (maybe because of the FTBFS you are comparing the previous try?). > Yes, we don't recommend the usage of faketime. Ok, but should its use cause an FTBFS instead? > I would instead remove the first timestamp in the PDF documentation and > replace the second one with some dummy value. I did replace \today in the tex file with a generated date using SOURCE_DATE_EPOCH https://anonscm.debian.org/git/debian-science/packages/gle-graphics.git/diff/?id=dfd125d35679a90931cd1c31314d8745eb806354&id2=e9449eb0a3197b6617d2d1ed29ebf0caab4095fe In the previous try I did replace the second one (if we are talking about the same one) with a static string (this was the time$() function in a gle example). However, the manual contains a lot of images as PDF files, which are generated by gle (after all the manual is the documentation for gle). The generated PDF files seem to contain timestamps as metadata also (I checked this for the font tables in the appendix, but there are more figures). When these PDF images are included in the latex document, it seems the timestamps in the metadata make it into the final PDF file. To get these consistent, I used faketime to generate the documentation (or just the images, but that seems to be more complicated, since I would have to pass the EPOCH to secondary Makefiles). Is there a better way to remove the timestamp metadata from the PDF images or all PDF files? The metadata also seems to include the location where the file is created... > We have a script called prebuilder, which can be used locally to build > packages twice with different variations [1] [2]. > This detects already a lot of issues. Thanks, I will check it out. I have another package which is marked unreproducible: https://tests.reproducible-builds.org/rb-pkg/unstable/amd64/moon-buggy.html https://tests.reproducible-builds.org/dbd/unstable/amd64/moon-buggy_1.0.51-10.diffoscope.html The diff looks huge, but looking at the text output, it seems the date is different between the two builds: 2 27 December 20042 28 December 2004 As far as I can see, this date is defined as a static value in version.texi: @set UPDATED 27 December 2004 Why and how is this modified in the second build? Is this related to the different timezone? But even if the timezone is changed, why is the date changed, there is no time defined in version.texi, so why would the date be changed? I don't know if that explains the whole difference, though. thanks, Christian ___ Reproducible-builds mailing list Reproducible-builds@lists.alioth.debian.org http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/reproducible-builds
[Reproducible-builds] Bug#819638: golang-github-armon-gomdb: FTBFS: panic: runtime error: cgo argument has Go pointer to Go pointer
Source: golang-github-armon-gomdb Version: 0.0~git20150106.0.151f2e0-1 Severity: serious Justification: fails to build from source User: reproducible-builds@lists.alioth.debian.org Usertags: ftbfs X-Debbugs-Cc: reproducible-builds@lists.alioth.debian.org Dear Maintainer, golang-github-armon-gomdb fails to build from source in unstable/amd64: [..] dpkg-buildpackage -rfakeroot -D -us -uc -b dpkg-buildpackage: source package golang-github-armon-gomdb dpkg-buildpackage: source version 0.0~git20150106.0.151f2e0-1 dpkg-buildpackage: source distribution unstable dpkg-buildpackage: source changed by Tianon Gravi dpkg-source --before-build golang-github-armon-gomdb-0.0~git20150106.0.151f2e0 dpkg-buildpackage: host architecture amd64 fakeroot debian/rules clean dh clean --buildsystem=golang --with=golang dh_testdir -O--buildsystem=golang dh_auto_clean -O--buildsystem=golang dh_clean -O--buildsystem=golang debian/rules build dh build --buildsystem=golang --with=golang dh_testdir -O--buildsystem=golang dh_update_autotools_config -O--buildsystem=golang dh_auto_configure -O--buildsystem=golang debian/rules override_dh_auto_build make[1]: Entering directory '/home/lamby/temp/cdt.20160331130518.JqkdCRDBbl/golang-github-armon-gomdb-0.0~git20150106.0.151f2e0' # lmdb is embedded -- purge that source find "/home/lamby/temp/cdt.20160331130518.JqkdCRDBbl/golang-github-armon-gomdb-0.0~git20150106.0.151f2e0/obj-x86_64-linux-gnu" \( -name '*.h' -o -name '*.c' \) -delete dh_auto_build go install -v github.com/armon/gomdb github.com/armon/gomdb make[1]: Leaving directory '/home/lamby/temp/cdt.20160331130518.JqkdCRDBbl/golang-github-armon-gomdb-0.0~git20150106.0.151f2e0' dh_auto_test -O--buildsystem=golang go test -v github.com/armon/gomdb === RUN TestEnvOpen --- PASS: TestEnvOpen (0.00s) === RUN TestEnvCopy --- PASS: TestEnvCopy (0.00s) env_test.go:67: Env path: /tmp/mdb_test840057194 === RUN TestTest1 --- FAIL: TestTest1 (0.00s) panic: runtime error: cgo argument has Go pointer to Go pointer [recovered] panic: runtime error: cgo argument has Go pointer to Go pointer goroutine 7 [running, locked to thread]: panic(0x5a0020, 0xc820012b40) /usr/lib/go/src/runtime/panic.go:464 +0x3e6 testing.tRunner.func1(0xc82007c3f0) /usr/lib/go/src/testing/testing.go:467 +0x192 panic(0x5a0020, 0xc820012b40) /usr/lib/go/src/runtime/panic.go:426 +0x4e9 github.com/armon/gomdb.(*Txn).Put(0xc8200280c8, 0x1, 0xc820012b10, 0x5, 0x8, 0xc820012b18, 0x5, 0x8, 0x10, 0x0, ...) /home/lamby/temp/cdt.20160331130518.JqkdCRDBbl/golang-github-armon-gomdb-0.0~git20150106.0.151f2e0/obj-x86_64-linux-gnu/src/github.com/armon/gomdb/txn.go:153 +0x179 github.com/armon/gomdb.TestTest1(0xc82007c3f0) /home/lamby/temp/cdt.20160331130518.JqkdCRDBbl/golang-github-armon-gomdb-0.0~git20150106.0.151f2e0/obj-x86_64-linux-gnu/src/github.com/armon/gomdb/mdb_test.go:54 +0xcde testing.tRunner(0xc82007c3f0, 0x8b9c50) /usr/lib/go/src/testing/testing.go:473 +0x98 created by testing.RunTests /usr/lib/go/src/testing/testing.go:582 +0x892 exit status 2 FAIL github.com/armon/gomdb 0.005s dh_auto_test: go test -v github.com/armon/gomdb returned exit code 1 debian/rules:11: recipe for target 'build' failed make: *** [build] Error 1 [..] The full build log is attached. Regards, -- ,''`. : :' : Chris Lamb `. `'` la...@debian.org / chris-lamb.co.uk `- golang-github-armon-gomdb.0.0~git20150106.0.151f2e0-1.unstable.amd64.log.txt.gz Description: Binary data ___ Reproducible-builds mailing list Reproducible-builds@lists.alioth.debian.org http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/reproducible-builds
[Reproducible-builds] Bug#819640: golang-github-hashicorp-raft-mdb: FTBFS: runtime error: cgo argument has Go pointer to Go pointer [recovered]
Source: golang-github-hashicorp-raft-mdb Version: 0.0~git20150806.0.55f2947-1 Severity: serious Justification: fails to build from source User: reproducible-builds@lists.alioth.debian.org Usertags: ftbfs X-Debbugs-Cc: reproducible-builds@lists.alioth.debian.org Dear Maintainer, golang-github-hashicorp-raft-mdb fails to build from source in unstable/amd64: [..] dh_auto_build -O--buildsystem=golang go install -v github.com/hashicorp/raft-mdb github.com/armon/gomdb github.com/hashicorp/go-msgpack/codec github.com/armon/go-metrics github.com/hashicorp/raft github.com/hashicorp/raft-mdb dh_auto_test -O--buildsystem=golang go test -v github.com/hashicorp/raft-mdb === RUN TestMDB_StableStore --- PASS: TestMDB_StableStore (0.00s) === RUN TestMDB_SetGet --- FAIL: TestMDB_SetGet (0.02s) panic: runtime error: cgo argument has Go pointer to Go pointer [recovered] panic: runtime error: cgo argument has Go pointer to Go pointer goroutine 22 [running]: panic(0x879a20, 0xc8200717e0) /usr/lib/go/src/runtime/panic.go:464 +0x3e6 testing.tRunner.func1(0xc82009c510) /usr/lib/go/src/testing/testing.go:467 +0x192 panic(0x879a20, 0xc8200717e0) /usr/lib/go/src/runtime/panic.go:426 +0x4e9 github.com/armon/gomdb.(*Txn).Get(0xc82007e0e0, 0x3, 0xc820071788, 0x6, 0x8, 0x0, 0x0, 0x0, 0x0, 0x0) /home/lamby/temp/cdt.20160331130627.Z2p7SJOThq/golang-github-hashicorp-raft-mdb-0.0~git20150806.0.55f2947/obj-x86_64-linux-gnu/src/github.com/armon/gomdb/txn.go:140 +0x151 github.com/hashicorp/raft-mdb.(*MDBStore).Get(0xc8200e1460, 0xc820071788, 0x6, 0x8, 0x0, 0x0, 0x0, 0x0, 0x0) /home/lamby/temp/cdt.20160331130627.Z2p7SJOThq/golang-github-hashicorp-raft-mdb-0.0~git20150806.0.55f2947/obj-x86_64-linux-gnu/src/github.com/hashicorp/raft-mdb/mdb_store.go:327 +0x1ad github.com/hashicorp/raft-mdb.TestMDB_SetGet(0xc82009c510) /home/lamby/temp/cdt.20160331130627.Z2p7SJOThq/golang-github-hashicorp-raft-mdb-0.0~git20150806.0.55f2947/obj-x86_64-linux-gnu/src/github.com/hashicorp/raft-mdb/mdb_store_test.go:52 +0x35c testing.tRunner(0xc82009c510, 0xd5dab8) /usr/lib/go/src/testing/testing.go:473 +0x98 created by testing.RunTests /usr/lib/go/src/testing/testing.go:582 +0x892 exit status 2 FAIL github.com/hashicorp/raft-mdb 0.029s dh_auto_test: go test -v github.com/hashicorp/raft-mdb returned exit code 1 debian/rules:4: recipe for target 'build' failed make: *** [build] Error 1 [..] The full build log is attached. Regards, -- ,''`. : :' : Chris Lamb `. `'` la...@debian.org / chris-lamb.co.uk `- golang-github-hashicorp-raft-mdb.0.0~git20150806.0.55f2947-1.unstable.amd64.log.txt.gz Description: Binary data ___ Reproducible-builds mailing list Reproducible-builds@lists.alioth.debian.org http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/reproducible-builds
[Reproducible-builds] Bug#819642: golang-goyaml: FTBFS: FAIL: encode_test.go:217: S.TestMarshal
Source: golang-goyaml
Version: 0.0~bzr50-1
Severity: serious
Justification: fails to build from source
User: reproducible-builds@lists.alioth.debian.org
Usertags: ftbfs
X-Debbugs-Cc: reproducible-builds@lists.alioth.debian.org
Dear Maintainer,
golang-goyaml fails to build from source in unstable/amd64:
[..]
dh_auto_build -O--buildsystem=golang
go install -v launchpad.net/goyaml
launchpad.net/goyaml
dh_auto_test -O--buildsystem=golang
go test -v launchpad.net/goyaml
=== RUN Test
--
FAIL: encode_test.go:217: S.TestMarshal
encode_test.go:221:
c.Assert(string(data), Equals, item.data)
... obtained string = "" +
... "a: 1\n" +
... "b: 2\n"
... expected string = "" +
... "a: 1\n" +
... "b: 2\n" +
... "c: 3\n"
--
FAIL: encode_test.go:238: S.TestMarshalErrors
encode_test.go:241:
c.Assert(err, ErrorMatches, item.error)
... value = nil
... regex string = "Duplicated key 'b' in struct struct \\{ B int; .*"
... Error value is nil
--
FAIL: decode_test.go:364: S.TestUnmarshal
decode_test.go:385:
c.Assert(value, DeepEquals, item.value, Commentf("Item #%d", i))
... obtained *struct { A int; C goyaml_test.inlineB "yaml:\",inline\"" } =
&struct { A int; C goyaml_test.inlineB "yaml:\",inline\"" }{A:1,
C:goyaml_test.inlineB{B:2, inlineC:goyaml_test.inlineC{C:0}}}
... expected *struct { A int; C goyaml_test.inlineB "yaml:\",inline\"" } =
&struct { A int; C goyaml_test.inlineB "yaml:\",inline\"" }{A:1,
C:goyaml_test.inlineB{B:2, inlineC:goyaml_test.inlineC{C:3}}}
... Item #84
OOPS: 9 passed, 3 FAILED
--- FAIL: Test (0.01s)
FAIL
exit status 1
FAIL launchpad.net/goyaml0.008s
dh_auto_test: go test -v launchpad.net/goyaml returned exit code 1
debian/rules:7: recipe for target 'build' failed
make: *** [build] Error 1
[..]
The full build log is attached.
Regards,
--
,''`.
: :' : Chris Lamb
`. `'` la...@debian.org / chris-lamb.co.uk
`-
golang-goyaml.0.0~bzr50-1.unstable.amd64.log.txt.gz
Description: Binary data
___
Reproducible-builds mailing list
Reproducible-builds@lists.alioth.debian.org
http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/reproducible-builds
[Reproducible-builds] Bug#819641: golang-github-jinzhu-gorm: FTBFS: FAIL: TestScannableSlices (0.00s)
Source: golang-github-jinzhu-gorm Version: 0.0~git20151012.0.20e37a0-1 Severity: serious Justification: fails to build from source User: reproducible-builds@lists.alioth.debian.org Usertags: ftbfs X-Debbugs-Cc: reproducible-builds@lists.alioth.debian.org Dear Maintainer, golang-github-jinzhu-gorm fails to build from source in unstable/amd64: [..] dh build --buildsystem=golang --with=golang dh_testdir -O--buildsystem=golang dh_update_autotools_config -O--buildsystem=golang dh_auto_configure -O--buildsystem=golang dh_auto_build -O--buildsystem=golang go install -v github.com/jinzhu/gorm github.com/lib/pq/hstore github.com/qor/inflection github.com/jinzhu/gorm dh_auto_test -O--buildsystem=golang go test -v github.com/jinzhu/gorm testing sqlite3... === RUN TestRegisterCallback --- PASS: TestRegisterCallback (0.00s) === RUN TestRegisterCallbackWithOrder --- PASS: TestRegisterCallbackWithOrder (0.00s) === RUN TestRegisterCallbackWithComplexOrder --- PASS: TestRegisterCallbackWithComplexOrder (0.00s) === RUN TestReplaceCallback [info] replacing callback `create` from /home/lamby/temp/cdt.20160331130655.2UxfTVyVK1/golang-github-jinzhu-gorm-0.0~git20151012.0.20e37a0/obj-x86_64-linux-gnu/src/github.com/jinzhu/gorm/callback_test.go:94 --- PASS: TestReplaceCallback (0.00s) === RUN TestRemoveCallback [info] removing callback `create` from /home/lamby/temp/cdt.20160331130655.2UxfTVyVK1/golang-github-jinzhu-gorm-0.0~git20151012.0.20e37a0/obj-x86_64-linux-gnu/src/github.com/jinzhu/gorm/callback_test.go:107 --- PASS: TestRemoveCallback (0.00s) === RUN TestCloneSearch --- PASS: TestCloneSearch (0.00s) === RUN TestHasOneAndHasManyAssociation --- PASS: TestHasOneAndHasManyAssociation (0.12s) === RUN TestRelated --- PASS: TestRelated (0.02s) === RUN TestManyToMany --- PASS: TestManyToMany (0.47s) === RUN TestForeignKey --- PASS: TestForeignKey (0.00s) === RUN TestRunCallbacks --- PASS: TestRunCallbacks (0.06s) === RUN TestCallbacksWithErrors --- PASS: TestCallbacksWithErrors (0.06s) === RUN TestCreate --- PASS: TestCreate (0.04s) === RUN TestCreateWithNoGORMPrimayKey --- PASS: TestCreateWithNoGORMPrimayKey (0.02s) === RUN TestCreateWithNoStdPrimaryKeyAndDefaultValues --- PASS: TestCreateWithNoStdPrimaryKeyAndDefaultValues (0.04s) === RUN TestAnonymousScanner --- PASS: TestAnonymousScanner (0.02s) === RUN TestAnonymousField --- PASS: TestAnonymousField (0.02s) === RUN TestSelectWithCreate --- PASS: TestSelectWithCreate (0.05s) === RUN TestOmitWithCreate --- PASS: TestOmitWithCreate (0.04s) === RUN TestCustomizeColumn --- PASS: TestCustomizeColumn (0.07s) === RUN TestCustomColumnAndIgnoredFieldClash --- PASS: TestCustomColumnAndIgnoredFieldClash (0.02s) === RUN TestDdlErrors testing sqlite3... --- PASS: TestDdlErrors (0.00s) === RUN TestDelete --- PASS: TestDelete (0.06s) === RUN TestInlineDelete --- PASS: TestInlineDelete (0.07s) === RUN TestSoftDelete --- PASS: TestSoftDelete (0.07s) === RUN TestSaveAndQueryEmbeddedStruct --- PASS: TestSaveAndQueryEmbeddedStruct (0.06s) === RUN TestCalculateField --- PASS: TestCalculateField (0.00s) === RUN TestJoinTable [35m(no such table: person_addresses)[0m [33m[2016-03-31 13:07:14][0m [31;1m [0m --- PASS: TestJoinTable (0.14s) === RUN TestStringPrimaryKey --- PASS: TestStringPrimaryKey (0.03s) === RUN TestExceptionsWithInvalidSql [35m(no such table: )[0m [33m[2016-03-31 13:07:14][0m [31;1m [0m [35m(no such column: aaa)[0m [33m[2016-03-31 13:07:14][0m [31;1m [0m --- PASS: TestExceptionsWithInvalidSql (0.00s) [35m(no such column: sdsd.zaaa)[0m [33m[2016-03-31 13:07:14][0m [31;1m [0m === RUN TestSetTable [35m(no such table: invalid_table)[0m [33m[2016-03-31 13:07:14][0m [31;1m [0m [35m(no such table: deleted_users)[0m [33m[2016-03-31 13:07:14][0m [31;1m [0m --- PASS: TestSetTable (0.20s) === RUN TestHasTable [35m(no such table: foos)[0m [33m[2016-03-31 13:07:14][0m [31;1m [0m --- PASS: TestHasTable (0.04s) === RUN TestTableName --- PASS: TestTableName (0.00s) === RUN TestSqlNullValue [35m(no such table: null_values)[0m [33m[2016-03-31 13:07:14][0m [31;1m [0m --- PASS: TestSqlNullValue (0.07s) === RUN TestTransaction [35m(NOT NULL constraint failed: null_values.name)[0m [33m[2016-03-31 13:07:14][0m [31;1m [0m [35m(sql: Transaction has already been committed or rolled back)[0m [33m[2016-03-31 13:07:14][0m [31;1m [0m --- PASS: TestTransaction (0.02s) === RUN TestRow --- PASS: TestRow (0.07s) === RUN TestRows --- PASS: TestRows (0.06s) === RUN TestScan --- PASS: TestScan (0.06s) === RUN TestRaw --- PASS: TestRaw (0.08s) === RUN TestGroup --- PASS: TestGroup (
[Reproducible-builds] Best approach to strip timestamp in postscript files
Hi. Looking at reproducibility issues in the kannel package, I saw that some PNG files are converted to PS and then included in another PS file. The PNG->PS conversion uses 'convert', which adds 'CreationDate' tags to the result. I don't know what is the best approach to solve this issue, but considered the following ones: 0) patch the kannel package to remove these tags from the PS files after PNG->PS conversion with a perl line (I made this in [1]). 1) patch the 'convert' code to remove CreationDate tags from PS output. But maybe some code somewhere relies on this tag to work? 2) add an option to the convert command to remove CreationDate tags from PS output, and add this option to the 'convert' calls in kannel build. 3) adds some code to strip-nondeterminism to remove all lines starting from "%%CreationDate:" from PS files Note that 1) and 2) may require to do the same for graphicsmagick, as imagemagick can be replaced by graphicsmagick-imagemagick-compat? Could you tell me if you think it could be helpful if I work on one of these approaches? Or maybe some current work is already going to solve this issue? Thanks, Alexis Bienvenüe. [1] http://docs.passoire.fr/alexis/debian/kannel_1.4.4-2_reproducible.diff ___ 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 build examples
On Thu, Mar 31, 2016 at 11:07:27AM +0200, Christian T. Steigies wrote: > It was not too difficult to replace \today in the tex file with a timestamp > generated from SOURCE_DATE_EPOCH, so I did that. The date is used on the > title page, so I think it makes sense to use this date like a version info. > However, it took me two tries, since month names are not reproducible, so I > had to use a format with numbers only. Why would I want to use a french > month name in an english document? You probably don't want them. But there are people that have different locales configured, so `date` will have different output on their systems. If you really want an English month name, you could set LC_ALL to C before calling date. > > Yes, we don't recommend the usage of faketime. > > Ok, but should its use cause an FTBFS instead? Hm, meanwhile on armhf version 4.2.5-4 built successfully. But the amd64 build failure is probably related to faketime. > > I would instead remove the first timestamp in the PDF documentation and > > replace the second one with some dummy value. > > I did replace \today in the tex file with a generated date using > SOURCE_DATE_EPOCH > > https://anonscm.debian.org/git/debian-science/packages/gle-graphics.git/diff/?id=dfd125d35679a90931cd1c31314d8745eb806354&id2=e9449eb0a3197b6617d2d1ed29ebf0caab4095fe > > > In the previous try I did replace the second one (if we are talking about > the same one) with a static string (this was the time$() function in a gle > example). However, the manual contains a lot of images as PDF files, which > are generated by gle (after all the manual is the documentation for gle). > The generated PDF files seem to contain timestamps as metadata also (I > checked this for the font tables in the appendix, but there are more figures). > When these PDF images are included in the latex document, it seems the > timestamps in the metadata make it into the final PDF file. To get these > consistent, I used faketime to generate the documentation (or just the > images, but that seems to be more complicated, since I would have to pass > the EPOCH to secondary Makefiles). Is there a better way to remove the > timestamp metadata from the PDF images or all PDF files? The metadata also > seems to include the location where the file is created... Hmm, are you sure it is caused by metadata from images? There will also be a lot of noise in PDF files, if somewhere the text changes (like the embedded date), which can be easily misinterpreted as unrelated differences. I would guess that the PDF becomes reproducible when the timestamp issues are fixed (even without using faketime). > I have another package which is marked unreproducible: > > https://tests.reproducible-builds.org/rb-pkg/unstable/amd64/moon-buggy.html > https://tests.reproducible-builds.org/dbd/unstable/amd64/moon-buggy_1.0.51-10.diffoscope.html > > The diff looks huge, but looking at the text output, it seems the date is > different between the two builds: > > 2 27 December 20042 28 December 2004 > > As far as I can see, this date is defined as a static value in version.texi: > > @set UPDATED 27 December 2004 > > Why and how is this modified in the second build? Is this related to the > different timezone? But even if the timezone is changed, why is the date > changed, there is no time defined in version.texi, so why would the date be > changed? I don't know if that explains the whole difference, though. I think this is updated during the build from Makefile.in:396, there version.texi is regenerated. And yes, the reason for this is the timezone difference: https://tests.reproducible-builds.org/issues/unstable/timezone_variance_because_of_automake_mdate_issue.html mdate-sh prints the last modification date of moon-buggy.texi. The modification time actually has a higher resolution than just day+month+year. But mdate-sh isn't normalizing the timezone, so the date can actually vary. (In Debian's automake this is already fixed, but packages shipping/using an old mdate-sh are still affected.) Kind regards, Reiner 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] Best approach to strip timestamp in postscript files
Hi. Le 31/03/2016 18:35, Dhole a écrit : > I believe the best option would be to make 'convert' honour the > environment variable SOURCE_DATE_EPOCH when defined, when embedding > the CreationDate tag. Thanks for your very clear advice. I prepared a patch for this [1]. I tested that the convert command now honour SOURCE_DATE_EPOCH for some output image formats. Does anyone want to have a look at it and give me some advice? Regards, Alexis. [1] http://docs.passoire.fr/alexis/debian/imagemagick_6.8.9.9-7_SOURCE_DATE_EPOCH.diff ___ Reproducible-builds mailing list Reproducible-builds@lists.alioth.debian.org http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/reproducible-builds
Re: [Reproducible-builds] Applying to Outreachy to work on Reproducible Builds
Hi Val,
On Wed, Mar 30, 2016 at 08:29:44PM -0400, spectran...@riseup.net wrote:
> Hurray! I started coding (when trapped without Internet earlier), now for
> confirmation:
>
> All possible status (Holger you mentioned "not for us" over irc, but that
> results with that status are already excluded, along with "blacklisted" and
> "404"):
right. i had forgotten about that :)
> ['FTBFS', 'depwait', 'reproducible', 'unreproducible']
>
> Tables of the result status, across (all two) architectures:
> arch1 | reproducible | reproducible | ftbfs | depwait | depwait
> |
> arch2 | reproducible | unreproducible | * | repro/unrepro | depwait
> |
> status | reproducible | unreproducible | ftbfs | repro/unrepro | depwait ??
that looks good to me. (+correct on depwait.)
>
> Questions:
> - see ?? above -- I assume I copy over "depwait" here?
yup
> About the JSON format!
> Old format:
> {
> "architecture": "armhf",
> "build_date": "2016-02-06 22:26",
> "package": "zzzeeksphinx",
> "status": "reproducible",
> "suite": "unstable",
> "version": "1.0.17-1"
> },
> {
> "architecture": "amd64",
> "build_date": "2016-03-19 23:35",
> "package": "zzzeeksphinx",
> "status": "reproducible",
> "suite": "unstable",
> "version": "1.0.17-1"
> },
>
> New proposed format:
> {
> "architecture": "armhf",
> "build_date": "2016-02-06 22:26",
> "package": "zzzeeksphinx",
> "status": "reproducible",
> "suite": "unstable",
> "version": "1.0.17-1"
> "architecture_status": [
> {
> "architecture": "armhf",
> "build_date": "2016-02-06 22:26",
> "status": "reproducible"
> },
> {
> "architecture": "amd64",
> "build_date": "2016-03-19 23:35",
> "status": "reproducible"
> },
> ]
> }
>
> Or, should I drop the architecture_status in the "new proposed format"
> altogether? Will no one need it?
i'd like to have architecture_status there. but i think you should drop
architecture & build-date above.
--
cheers,
Holger
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
