You are viewing a plain text version of this content. The canonical link for it is here.
Posted to issues@sis.apache.org by "hboutemy (via GitHub)" <gi...@apache.org> on 2023/07/15 21:06:15 UTC
[GitHub] [sis] hboutemy opened a new pull request, #36: enable Reproducible Builds
hboutemy opened a new pull request, #36:
URL: https://github.com/apache/sis/pull/36
(no comment)
--
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
To unsubscribe, e-mail: issues-unsubscribe@sis.apache.org
For queries about this service, please contact Infrastructure at:
users@infra.apache.org
[GitHub] [sis] desruisseaux commented on pull request #36: enable Reproducible Builds
Posted by "desruisseaux (via GitHub)" <gi...@apache.org>.
desruisseaux commented on PR #36:
URL: https://github.com/apache/sis/pull/36#issuecomment-1684922855
Since #37 the build system is no longer Maven (it is now Gradle), so this pull request can not be merged anymore. However the `Built-On` attribute fixed by this pull request is no longer added to the `META-INF/MANIFEST.MF` file. The content of that file is now like below (no more builder-dependent information):
```
Manifest-Version: 1.0
Specification-Title: GeoAPI
Specification-Vendor: Open Geospatial Consortium
Specification-Version: 3.0.2
Implementation-Title: Apache Spatial Information System (SIS)
Implementation-Vendor: The Apache Software Foundation
Implementation-Version: 1.4-SNAPSHOT
Main-Class: org.apache.sis.gui.DataViewer
```
--
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
To unsubscribe, e-mail: issues-unsubscribe@sis.apache.org
For queries about this service, please contact Infrastructure at:
users@infra.apache.org
[GitHub] [sis] hboutemy commented on a diff in pull request #36: enable Reproducible Builds
Posted by "hboutemy (via GitHub)" <gi...@apache.org>.
hboutemy commented on code in PR #36:
URL: https://github.com/apache/sis/pull/36#discussion_r1267575816
##########
pom.xml:
##########
@@ -545,6 +545,7 @@
=================================================================== -->
<properties>
<project.build.sourceEncoding>UTF-8</project.build.sourceEncoding>
+ <project.build.outputTimestamp>2023-07-15T16:42:39Z</project.build.outputTimestamp>
Review Comment:
on the maintenance mechanism: it can be maven-release-plugin, or versions-maven-plugin. Or if you prefer, you can use the git commit date. (sorry, I overlooked the fact that you don't use the maven-release-plugin)
Honestly, merging is not really something that happens, given the timestamp is only updated usually at most during version changes (between SNAPSHOT and release)
on why binary check vs smart tools:
- smart tools will have bugs
- efficiency (it's not only about timestamp, but also order)
- particularly in the case of cache mechanisms
--
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
To unsubscribe, e-mail: issues-unsubscribe@sis.apache.org
For queries about this service, please contact Infrastructure at:
users@infra.apache.org
[GitHub] [sis] desruisseaux closed pull request #36: enable Reproducible Builds
Posted by "desruisseaux (via GitHub)" <gi...@apache.org>.
desruisseaux closed pull request #36: enable Reproducible Builds
URL: https://github.com/apache/sis/pull/36
--
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
To unsubscribe, e-mail: issues-unsubscribe@sis.apache.org
For queries about this service, please contact Infrastructure at:
users@infra.apache.org
[GitHub] [sis] hboutemy commented on a diff in pull request #36: enable Reproducible Builds
Posted by "hboutemy (via GitHub)" <gi...@apache.org>.
hboutemy commented on code in PR #36:
URL: https://github.com/apache/sis/pull/36#discussion_r1281204329
##########
pom.xml:
##########
@@ -545,6 +545,7 @@
=================================================================== -->
<properties>
<project.build.sourceEncoding>UTF-8</project.build.sourceEncoding>
+ <project.build.outputTimestamp>2023-07-15T16:42:39Z</project.build.outputTimestamp>
Review Comment:
> If this migration is accepted, the fix proposed in this issue would take a different form.
ok, let's drop this PR, then, no problem
> it throws away valuable metadata such as build time and who made the build
I perfectly understand your idea, I was a strong promoter of trackers of provenance: the fact is that with RB, they are not useful any more
> I think that no timestamp would be better than a timestamp with fixed value
Yes: if you know if zip and/or tar have that notion, I'm interested
> In French I would said that bit-by-bit reproducibility is "jeter le bébé avec l'eau du bain".
Hehe :) From experience gained from thousands of rebuilds in https://github.com/jvm-repo-rebuild/reproducible-central , I detected many unexpected difference in releases with this approach: I'll talk about at next Community Over Code conference, if you happen to join us
But it has to happen step by step, learning while deploying, without forcing
--
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
To unsubscribe, e-mail: issues-unsubscribe@sis.apache.org
For queries about this service, please contact Infrastructure at:
users@infra.apache.org
[GitHub] [sis] hboutemy commented on a diff in pull request #36: enable Reproducible Builds
Posted by "hboutemy (via GitHub)" <gi...@apache.org>.
hboutemy commented on code in PR #36:
URL: https://github.com/apache/sis/pull/36#discussion_r1267575816
##########
pom.xml:
##########
@@ -545,6 +545,7 @@
=================================================================== -->
<properties>
<project.build.sourceEncoding>UTF-8</project.build.sourceEncoding>
+ <project.build.outputTimestamp>2023-07-15T16:42:39Z</project.build.outputTimestamp>
Review Comment:
on the maintenance mechanism: it can be maven-release-plugin, or versions-maven-plugin. Or if you prefer, you can use the git commit date.
Honestly, merging is not really something that happens, given the timestamp is only updated usually at most during version changes (between SNAPSHOT and release)
on why binary check vs smart tools:
- smart tools will have bugs
- efficiency (it's not only about timestamp, but also order)
- particularly in the case of cache mechanisms
--
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
To unsubscribe, e-mail: issues-unsubscribe@sis.apache.org
For queries about this service, please contact Infrastructure at:
users@infra.apache.org
[GitHub] [sis] hboutemy commented on a diff in pull request #36: enable Reproducible Builds
Posted by "hboutemy (via GitHub)" <gi...@apache.org>.
hboutemy commented on code in PR #36:
URL: https://github.com/apache/sis/pull/36#discussion_r1267575816
##########
pom.xml:
##########
@@ -545,6 +545,7 @@
=================================================================== -->
<properties>
<project.build.sourceEncoding>UTF-8</project.build.sourceEncoding>
+ <project.build.outputTimestamp>2023-07-15T16:42:39Z</project.build.outputTimestamp>
Review Comment:
on the maintenance mechanism: it can be maven-release-plugin, or versions-maven-plugin. Or if you prefer, you can use the git commit date: see https://maven.apache.org/guides/mini/guide-reproducible-builds.html#faq (sorry, I overlooked the fact that you don't use the maven-release-plugin)
Honestly, merging is not really something that happens, given the timestamp is only updated usually at most during version changes (between SNAPSHOT and release)
on why binary check vs smart tools:
- smart tools will have bugs
- efficiency (it's not only about timestamp, but also order)
- particularly in the case of cache mechanisms
--
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
To unsubscribe, e-mail: issues-unsubscribe@sis.apache.org
For queries about this service, please contact Infrastructure at:
users@infra.apache.org
[GitHub] [sis] hboutemy commented on a diff in pull request #36: enable Reproducible Builds
Posted by "hboutemy (via GitHub)" <gi...@apache.org>.
hboutemy commented on code in PR #36:
URL: https://github.com/apache/sis/pull/36#discussion_r1267575816
##########
pom.xml:
##########
@@ -545,6 +545,7 @@
=================================================================== -->
<properties>
<project.build.sourceEncoding>UTF-8</project.build.sourceEncoding>
+ <project.build.outputTimestamp>2023-07-15T16:42:39Z</project.build.outputTimestamp>
Review Comment:
on the maintenance mechanism: it can be maven-release-plugin, or versions-maven-plugin. Or if you prefer, you can use the git commit date, or even choose to not update the value and keep it at a conventional value: see https://maven.apache.org/guides/mini/guide-reproducible-builds.html#faq (sorry, I overlooked the fact that you don't use the maven-release-plugin)
Honestly, merging is not really something that happens, given the timestamp is only updated usually at most during version changes (between SNAPSHOT and release)
on why binary check vs smart tools:
- smart tools will have bugs
- efficiency (it's not only about timestamp, but also order)
- particularly in the case of cache mechanisms
--
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
To unsubscribe, e-mail: issues-unsubscribe@sis.apache.org
For queries about this service, please contact Infrastructure at:
users@infra.apache.org
[GitHub] [sis] hboutemy commented on a diff in pull request #36: enable Reproducible Builds
Posted by "hboutemy (via GitHub)" <gi...@apache.org>.
hboutemy commented on code in PR #36:
URL: https://github.com/apache/sis/pull/36#discussion_r1281204329
##########
pom.xml:
##########
@@ -545,6 +545,7 @@
=================================================================== -->
<properties>
<project.build.sourceEncoding>UTF-8</project.build.sourceEncoding>
+ <project.build.outputTimestamp>2023-07-15T16:42:39Z</project.build.outputTimestamp>
Review Comment:
> If this migration is accepted, the fix proposed in this issue would take a different form.
ok, let's drop this PR, then, no problem
> it throws away valuable metadata such as build time and who made the build
I perfectly understand your idea, I was a strong promoter of trackers of provenance: the fact is that with RB, they are not useful any more
> I think that no timestamp would be better than a timestamp with fixed value
Yes: if you know if zip and/or tar have that notion, I'm interested
> In French I would said that bit-by-bit reproducibility is "jeter le bébé avec l'eau du bain".
Hehe :) From experience gained from thousands of rebuilds in https://github.com/jvm-repo-rebuild/reproducible-central , I detected many unexpected difference in releases with this approach
But it has to happen step by step, learning while deploying, without forcing
##########
pom.xml:
##########
@@ -545,6 +545,7 @@
=================================================================== -->
<properties>
<project.build.sourceEncoding>UTF-8</project.build.sourceEncoding>
+ <project.build.outputTimestamp>2023-07-15T16:42:39Z</project.build.outputTimestamp>
Review Comment:
> If this migration is accepted, the fix proposed in this issue would take a different form.
ok, let's drop this PR, then, no problem
> it throws away valuable metadata such as build time and who made the build
I perfectly understand your idea, I was a strong promoter of trackers of provenance: the fact is that with RB, they are not useful any more
> I think that no timestamp would be better than a timestamp with fixed value
Yes: if you know if zip and/or tar have that notion, I'm interested
> In French I would said that bit-by-bit reproducibility is "jeter le bébé avec l'eau du bain".
Hehe :) From experience gained from thousands of rebuilds in https://github.com/jvm-repo-rebuild/reproducible-central , I detected many unexpected difference in releases with this approach
But it has to happen step by step, learning while deploying, without forcing
--
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
To unsubscribe, e-mail: issues-unsubscribe@sis.apache.org
For queries about this service, please contact Infrastructure at:
users@infra.apache.org
[GitHub] [sis] desruisseaux commented on a diff in pull request #36: enable Reproducible Builds
Posted by "desruisseaux (via GitHub)" <gi...@apache.org>.
desruisseaux commented on code in PR #36:
URL: https://github.com/apache/sis/pull/36#discussion_r1266439346
##########
pom.xml:
##########
@@ -545,6 +545,7 @@
=================================================================== -->
<properties>
<project.build.sourceEncoding>UTF-8</project.build.sourceEncoding>
+ <project.build.outputTimestamp>2023-07-15T16:42:39Z</project.build.outputTimestamp>
Review Comment:
Thanks. But what would be the maintenance mechanism? Would it be necessary to update this line manually during merges?
Alternatively (I know it is a much larger debate), I wonder why reproductive build proponents insist on bit-by-bit reproducibility instead of creating a `jar-diff` tools which ignores the order of entries in the JAR files, and ignores a small selected set of `META-INF/MANIFEST.MF` entries such as the build timestamp?
--
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
To unsubscribe, e-mail: issues-unsubscribe@sis.apache.org
For queries about this service, please contact Infrastructure at:
users@infra.apache.org
[GitHub] [sis] hboutemy commented on a diff in pull request #36: enable Reproducible Builds
Posted by "hboutemy (via GitHub)" <gi...@apache.org>.
hboutemy commented on code in PR #36:
URL: https://github.com/apache/sis/pull/36#discussion_r1281204329
##########
pom.xml:
##########
@@ -545,6 +545,7 @@
=================================================================== -->
<properties>
<project.build.sourceEncoding>UTF-8</project.build.sourceEncoding>
+ <project.build.outputTimestamp>2023-07-15T16:42:39Z</project.build.outputTimestamp>
Review Comment:
> If this migration is accepted, the fix proposed in this issue would take a different form.
ok, let's drop this PR, then, no problem
> it throws away valuable metadata such as build time and who made the build
I perfectly understand your idea, I was a strong promoter of trackers of provenance: the fact is that with RB, they are not useful any more
> I think that no timestamp would be better than a timestamp with fixed value
Yes: if you know if zip and/or tar have that notion, I'm interested
> In French I would said that bit-by-bit reproducibility is "jeter le bébé avec l'eau du bain".
Hehe :) From experience gained from thousands of rebuilds in https://github.com/jvm-repo-rebuild/reproducible-central , I detected many unexpected difference in releases with this approach: I'll talk about at next Community Over Code conference in Halifax, if you happen to join us
But it has to happen step by step, learning while deploying, without forcing
--
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
To unsubscribe, e-mail: issues-unsubscribe@sis.apache.org
For queries about this service, please contact Infrastructure at:
users@infra.apache.org
[GitHub] [sis] desruisseaux commented on a diff in pull request #36: enable Reproducible Builds
Posted by "desruisseaux (via GitHub)" <gi...@apache.org>.
desruisseaux commented on code in PR #36:
URL: https://github.com/apache/sis/pull/36#discussion_r1279045448
##########
pom.xml:
##########
@@ -545,6 +545,7 @@
=================================================================== -->
<properties>
<project.build.sourceEncoding>UTF-8</project.build.sourceEncoding>
+ <project.build.outputTimestamp>2023-07-15T16:42:39Z</project.build.outputTimestamp>
Review Comment:
A proposal to migrate from Maven to Gradle is [on the table](https://lists.apache.org/thread/xqnydv188cxom22forz3j8bbkbtv8g14) in order to modularize the project with `module-info.java` files. While Maven has some JPMS support, taking full advantage of JPMS requires restructuring the code from _Package Hierarchy_ to _Module Source Hierarchy_, and the latter would be very difficult to do with Maven. If this migration is accepted, the fix proposed in this issue would take a different form.
On binary check versus smart tools, the problem of binary check is that it throws away valuable metadata such as build time and who made the build. While the metadata seems to be there, they became meaningless in their values are not anymore what they seem to be. Metadata with false values are worst than no metadata, because they create a situation where we don't know anymore which metadata we can trust. In the particular case of this issue, I think that no timestamp would be better than a timestamp with fixed value. I highly value the goal of reproductible builds (it would make me feel safer when I deploy binaries on Maven Central), but I think that an extremist position on "bit-by-bit" reproducibility is creating other dangers in a world where false information became a thread as serious as hackers. In French I would said that bit-by-bit reproducibility is "jeter le bébé avec l'eau du bain".
##########
pom.xml:
##########
@@ -545,6 +545,7 @@
=================================================================== -->
<properties>
<project.build.sourceEncoding>UTF-8</project.build.sourceEncoding>
+ <project.build.outputTimestamp>2023-07-15T16:42:39Z</project.build.outputTimestamp>
Review Comment:
A proposal to migrate from Maven to Gradle is [on the table](https://lists.apache.org/thread/xqnydv188cxom22forz3j8bbkbtv8g14) in order to modularize the project with `module-info.java` files. While Maven has some JPMS support, taking full advantage of JPMS requires restructuring the code from _Package Hierarchy_ to _Module Source Hierarchy_, and the latter would be very difficult to do with Maven. If this migration is accepted, the fix proposed in this issue would take a different form.
On binary check versus smart tools, the problem of binary check is that it throws away valuable metadata such as build time and who made the build. While the metadata seems to be there, they became meaningless in their values are not anymore what they seem to be. Metadata with false values are worst than no metadata, because they create a situation where we don't know anymore which metadata we can trust. In the particular case of this issue, I think that no timestamp would be better than a timestamp with fixed value. I highly value the goal of reproductible builds (it would make me feel safer when I deploy binaries on Maven Central), but I think that an extremist position on "bit-by-bit" reproducibility is creating other dangers in a world where false information became a thread as serious as hackers. In French I would said that bit-by-bit reproducibility is "jeter le bébé avec l'eau du bain".
--
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
To unsubscribe, e-mail: issues-unsubscribe@sis.apache.org
For queries about this service, please contact Infrastructure at:
users@infra.apache.org
[GitHub] [sis] desruisseaux commented on a diff in pull request #36: enable Reproducible Builds
Posted by "desruisseaux (via GitHub)" <gi...@apache.org>.
desruisseaux commented on code in PR #36:
URL: https://github.com/apache/sis/pull/36#discussion_r1279045448
##########
pom.xml:
##########
@@ -545,6 +545,7 @@
=================================================================== -->
<properties>
<project.build.sourceEncoding>UTF-8</project.build.sourceEncoding>
+ <project.build.outputTimestamp>2023-07-15T16:42:39Z</project.build.outputTimestamp>
Review Comment:
A proposal to migrate from Maven to Gradle is [on the table](https://lists.apache.org/thread/xqnydv188cxom22forz3j8bbkbtv8g14) in order to modularize the project with `module-info.java` files. While Maven has some JPMS support, taking full advantage of JPMS requires restructuring the code from _Package Hierarchy_ to _Module Source Hierarchy_, and the latter would be very difficult to do with Maven. If this migration is accepted, the fix proposed in this issue would take a different form.
On binary check versus smart tools, the problem of binary check is that it throws away valuable metadata such as build time and who made the build. While the metadata seems to be there, they became meaningless if their values are not anymore what they seem to be. Metadata with false values are worst than no metadata, because they create a situation where we don't know anymore which metadata we can trust. In the particular case of this issue, I think that no timestamp would be better than a timestamp with fixed value. I highly value the goal of reproductible builds (it would make me feel safer when I deploy binaries on Maven Central), but I think that an extremist position on "bit-by-bit" reproducibility is creating other dangers in a world where false information became a thread as serious as hackers. In French I would said that bit-by-bit reproducibility is "jeter le bébé avec l'eau du bain".
--
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
To unsubscribe, e-mail: issues-unsubscribe@sis.apache.org
For queries about this service, please contact Infrastructure at:
users@infra.apache.org