Bug#773916: libical: Ship different constant values accross builds
On 31/12/14 10:00, Simon McVittie wrote: On Mon, 29 Dec 2014 at 21:27:16 +, Debian Bug Tracking System wrote: libical (1.0-1.2) unstable; urgency=medium . * Non-maintainer upload. * Sort keys to generate reproducible source code. (Closes: #773916) This is enough to make 1.0 internally consistent; but if the list is going to get larger (I don't know whether it can, I don't know anything about this library), then it is not enough to make 1.0 consistent with a subsequent 1.1. There is really no long-term solution to this other than upstream declaring that a particular enum ordering is canonical, sticking to it in future, always adding new entries at the end, and never re-ordering or deleting. The order in which they appear in the source file might be the best choice for a canonical order. That is true. It's enough for debian though, for now. And one should check abi on subsequent updates. I haven't checked later releases, but sorting the keys / keeping-things-not-future-proof is what is done elsewhere in the generated code upstream. It did appear that some other enums have stable values, but I didn't manage to figure it out if those simply are non-generated / static pieces of code. There are accessors and getters generated for each of the values, and the NONE and LAST are stable values throughout, thus the abi breakage is subtle. -- Regards, Dimitri. signature.asc Description: OpenPGP digital signature
Bug#773916: libical: Ship different constant values accross builds
On Mon, 29 Dec 2014 at 21:27:16 +, Debian Bug Tracking System wrote: libical (1.0-1.2) unstable; urgency=medium . * Non-maintainer upload. * Sort keys to generate reproducible source code. (Closes: #773916) This is enough to make 1.0 internally consistent; but if the list is going to get larger (I don't know whether it can, I don't know anything about this library), then it is not enough to make 1.0 consistent with a subsequent 1.1. There is really no long-term solution to this other than upstream declaring that a particular enum ordering is canonical, sticking to it in future, always adding new entries at the end, and never re-ordering or deleting. The order in which they appear in the source file might be the best choice for a canonical order. S -- To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#773916: libical: Ship different constant values accross builds
Dimitri John Ledkov: If I fail to upload this, please upload it instead of me. Looks like the upload went ok. I am now able to rebuild libical reproducibly. :) Please remember to coordinate with the release team for binNUMs and unblocks. -- Lunar.''`. lu...@debian.org: :Ⓐ : # apt-get install anarchism `. `'` `- signature.asc Description: Digital signature
Bug#773916: libical: Ship different constant values accross builds
On Thu, 25 Dec 2014 16:46:14 +0100 =?iso-8859-1?B?Suly6W15?= Bobbio lu...@debian.org wrote: Package: libical-dev Version: 1.0-1.1 Severity: critical User: reproducible-bui...@lists.alioth.debian.org Usertags: randomness Hi! While working on the âreproducible buildsâ effort [1], we have noticed that libical could not be built reproducibly: https://jenkins.debian.net/userContent/dbd/libical_1.0-1.1.debbindiff.html Looks like perl script is used to generate the headers which is using unsorted hash, hence random result. Sorting it seems to do the trick. If I fail to upload this, please upload it instead of me. Regards, Dimitri. libical.debdiff Description: Binary data
Bug#773916: libical: Ship different constant values accross builds
Package: libical-dev Version: 1.0-1.1 Severity: critical User: reproducible-bui...@lists.alioth.debian.org Usertags: randomness Hi! While working on the “reproducible builds” effort [1], we have noticed that libical could not be built reproducibly: https://jenkins.debian.net/userContent/dbd/libical_1.0-1.1.debbindiff.html The debbindiff output linked above show that two builds of libical will output different values for the constant defined in the icalvalue_kind enum in ical.h and icalderivedvalue.h. This is bad. It means that any software using these values will break when libical is updated. After a quick look at the report, this might be the cause for #766454. The problem highly likely lies in the following code: https://sources.debian.net/src/libical/1.0-1.1/scripts/mkderivedvalues.pl/?hl=66:74#L66 Sorting the keys before using them should make the output stable accross builds. Ideally this should be done in all similar constructs to enable the package to build reproducibly. Packages having a Build-Depends on libical-dev should probably be binNMU'ed once this is fixed. That should be: agenda.app, asterisk, bluez, cairo-dock-plug-ins, citadel, cyrus-imapd-2.4, evolution, evolution-data-server, evolution-ews, gnokii, goldencheetah, ical2html, kdepimlibs, kmymoney, libsynthesis, openchange, orage, osmo, syncevolution, webcit. [1]: https://wiki.debian.org/ReproducibleBuilds -- Lunar.''`. lu...@debian.org: :Ⓐ : # apt-get install anarchism `. `'` `- signature.asc Description: Digital signature
