Reproducible builds

[danimesq]

No description provided.

[pali]

Could you please describe the issue?

[danimesq]

udftools releases having the same hash when being manually built.

[pali]

Could you please describe what is the issue with udftools?

[danimesq]

Im just suggesting reproducible builds for udftools

[pali]

So, can you please describe what is the issue?

[Siltaar]

Without having tested anything, I imagine that @DaniellMesquita is requesting some small fix in the compilation process in order to always get the same result when compiling the same version of the binaries. This is important to allow security checks over the binaries you meet afterwards (such as comparing your fresh build with the official distributed one, on the one that is available in your share-hosting…).

More info can be found here : https://en.wikipedia.org/wiki/Reproducible_builds

Debian: by July 2017 more than 90% of the packages in the repository have been proven to build reproducibly.

This looks like a small effort to make that achieves a fundamental difference. Its usually a matter of :

normalizing variables that may change, such as order of input files, timestamps, locales, and paths.

[pali]

I imagine that @DaniellMesquita is requesting some small fix in the compilation process in order to always get the same result when compiling the same version of the binaries.

So could you please describe that issue which you think that needs to be fixed?

[pali]

no description = no issue = nothing which could be fixed, so closing

[Siltaar]

Well, you gave no clue about that fact you understood what is at stake.

I hope you're implying that the builds are already reproducibles, else you would not loose your time learning what it means, at least. I gave a good concise pointer, but you acted like a machine discarding the information.

You're not acting inclusively and it's sad because working udftools would allow GNU+Linux users to get rid of FAT32/exFAT for USB-Key for instance.

[pali]

5x I kindly asked for a description of the issue. Nothing. I'm not going to play a role of detective Poirot, to figure out could be a theoretical problem and what probably reported wanted to report as he would not been able to provide even a description of the problem. If in issue description is missing information how to reproduce the issue, how other can developer check if the issue is still relevant or if is really fixed? Developers really do not have a crystal ball for reading someones mind and also do not have time for decipher it.

PS: I know what are reproducible builds. And after 10 posts I have not got any information where is the problem, which part/binary of udftools cause that build is not reproducible.

[Siltaar]

It might not cost too much time to check if the builds are reproducible.
Then maybe you would be the best person to find out the eventual glitches preventing them from being so.
The rest of the Debian team worked a lot about it.

Then, sure the reporter did not consent to provide usable info, or at least an example, but time spent on reproducibility of the builds is not lost :-) (I myself would not be efficient trying to do more, I barely managed to ./configure the project… I am more a web guy Python/JavaScript… but JavaScript can achieve some useful things, such as : https://www.meta-press.es)

[pali]

It might not cost too much time to check if the builds are reproducible.

Ok, so in this case, please provide description of the issue.

I spend too much time with issue which is described as "No description provided.".
As I said, I'm not detective Poirot and I'm not interested in reading detective literature in issue trackers. Bug report must be brief, clear and describe how to reproduce it. "No description provided." = "No issue at all".