[opensuse-factory] openSUSE reproducible builds status 2021-02
Hi, last month's status: https://lists.opensuse.org/archives/list/factory@lists.opensuse.org/thread/V... Last months' reproducible builds project updates (including my work): https://reproducible-builds.org/reports/2021-01/ I uploaded https://rb.zq1.de/compare.factory-20210227/ today and rbstats are: total-packages: 13909 (-20) build-tried: 13900 (-22) build-failed: 81 (+51) build-n-a: 135 (+5) build-succeeded: 13684 (-78) build-official-failed+na: 393 (+99) build-compare-failed: 433 (-3) build-compare-succeeded: 13251 (-75) verify-failed: 497 (-11) verified-semi-reproducible: 12871 (-75) bit-by-bit-identical: 13119 (-79) not-bit-by-bit-identical: 565 (+1) not-bit-by-bit-identicalcheck: 565 (+1) https://rb.zq1.de/compare.factory-20210227/graph.png shows the change over time https://rb.zq1.de/compare.factory-20210227/unreproduciblerings.txt lists very unreproducible core packages (bootstrap+DVD) Of the badly unreproducible packages, 3 were in ring0 45 were in ring1 That makes it 48/3247 => 1.48 % which is below the overall average of 433/13684 => 3.16 % 565/13684 => 4.13 % of packages are not perfectly reproducible newly unreproducible core packages: containerd: becomes reproducible with BuildRequires: go1.15 https://github.com/golang/go/issues/42159 python-numpy: .pyc files are nondeterministic again/still newly reproducible core packages: kopete: might still be affected by https://bugreports.qt.io/browse/QTBUG-83186 but 1-bit nondeterminism can go unnoticed rubygem-nokogiri darix fixed https://bugzilla.opensuse.org/show_bug.cgi?id=1180528
On Saturday 2021-02-27 07:34, Bernhard M. Wiedemann wrote:
I uploaded https://rb.zq1.de/compare.factory-20210227/ today gfan: dvipdf manual.dvi manual.pdf
Generates <xmp:CreateDate>, <xmp:ModifyDate> and <xapMM:DocumentID>uu-id-..</xap> Cause is ghostscript:/devices/vector/gdevpdfe.c not honoring SOURCE_BUILD_TIME or any of the other mechanisms.
On Samstag, 27. Februar 2021 08:43:57 CET Jan Engelhardt wrote:
On Saturday 2021-02-27 07:34, Bernhard M. Wiedemann wrote:
I uploaded https://rb.zq1.de/compare.factory-20210227/ today
gfan: dvipdf manual.dvi manual.pdf
Generates <xmp:CreateDate>, <xmp:ModifyDate> and <xapMM:DocumentID>uu-id-..</xap>
Cause is ghostscript:/devices/vector/gdevpdfe.c not honoring SOURCE_BUILD_TIME or any of the other mechanisms.
The corresponding GS upstream report has been closed (and patch rejected) with "NOT-A-BUG". https://bugs.ghostscript.com/show_bug.cgi?id=696765 CreateDate and ModifyDate can be overridden, see https://bugs.ghostscript.com/show_bug.cgi?id=696765#c15 - should be possible to hack this into dvips/dvipdf by using SOURCE_DATE_EPOCH for these dates. That leaves you with the DocumentId/InstanceId. You can override these on the command line, but it is somewhat difficult to put "correct" values there. It should be a unique value, and I imagine there are quite some packages which use "manual.dvi" or "doc.dvi", so the filename is insufficient. According to the PDF specification (PDF 32000-1:2008, 7.5.5 File Trailer), the IDs are optional:
ID | array | (Required if an Encrypt entry is present; optional otherwise; PDF 1.1) An array of two byte-strings constituting a file identifier (see 14.4, "File Identifiers") for the file. If there is an Encrypt entry this array and the two byte-strings shall be direct objects and shall be unencrypted. NOTE 1 (...) NOTE 2 Although this entry is optional, its absence might prevent the file from functioning in some workflows that depend on files being uniquely identified.
Unfortunately, AFAIK you can't tell GS to omit the IDs. Kind regards, Stefan -- Stefan Brüns / Bergstraße 21 / 52062 Aachen home: +49 241 53809034 mobile: +49 151 50412019
Citeren Jan Engelhardt <jengelh@inai.de>:
On Saturday 2021-02-27 07:34, Bernhard M. Wiedemann wrote:
I uploaded https://rb.zq1.de/compare.factory-20210227/ today gfan: dvipdf manual.dvi manual.pdf
Generates <xmp:CreateDate>, <xmp:ModifyDate> and <xapMM:DocumentID>uu-id-..</xap>
Cause is ghostscript:/devices/vector/gdevpdfe.c not honoring SOURCE_BUILD_TIME or any of the other mechanisms.
That, and quite a few other places. I think I got most of them, so here we go: https://build.opensuse.org/request/show/875678
On Samstag, 27. Februar 2021 23:13:05 CET Arjen de Korte wrote:
Citeren Jan Engelhardt <jengelh@inai.de>:
On Saturday 2021-02-27 07:34, Bernhard M. Wiedemann wrote:
I uploaded https://rb.zq1.de/compare.factory-20210227/ today
gfan: dvipdf manual.dvi manual.pdf
Generates <xmp:CreateDate>, <xmp:ModifyDate> and <xapMM:DocumentID>uu-id-..</xap>
Cause is ghostscript:/devices/vector/gdevpdfe.c not honoring SOURCE_BUILD_TIME or any of the other mechanisms.
That, and quite a few other places. I think I got most of them, so here we go: https://build.opensuse.org/request/show/875678
Using SOURCE_DATE_EPOCH and only SDE for the UUID is violating the PDF specification. While the current upstream implementation is not really good (using only the current timestamp with microsecond resolution), it has significantly more entropy than the SOURCE_DATE_EPOCH as set by the OBS, which only has day granularity. All PDFs built today would have the same UUID. The recommendation in PDF 32000-1 is to also use the contents of the document metadata dictionary, the filesize and the filename. Kind regards, Stefan -- Stefan Brüns / Bergstraße 21 / 52062 Aachen home: +49 241 53809034 mobile: +49 151 50412019
participants (4)
-
Arjen de Korte -
Bernhard M. Wiedemann -
Jan Engelhardt -
Stefan Brüns