On 29/12/15 17:18, Ricardo Wurmus wrote:
> Ben Woodcroft <b.woodcroft@uq.edu.au> writes:
>
>> Unfortunately none of these builds are reproducible because rubygems in
>> Guix generally aren't. For one, this is because .gem files are archives
>> whose contents are timestamped.
> I found the same problem with Java stuff.  “.jar” files are archives of
> the generated “.class” files and they contain an automatically generated
> manifest.  To fix this in a build system I’m planning to unpack all
> files from the “.jar”, then “touch -d @0” each file, and then repack
> with “jar” without creating a new manifest.
>
> So far “touch”-ing every class file after compilation and leaving off
> the manifest at jar creation time has shown that “jar” archives can be
> made reproducible.
>
> “gem” archives are really just slightly modified “tar” archives, aren’t
> they?  Maybe we could add a phase to the ruby-build-system — or modify
> the “build” phase, which unpacks and rebuilds the “.gem” archive.
Yep, they are just tar files. But since it is just a cache, can we just 
delete the gem file as per attached? Too ham-fisted?

Of the 104 gems in my checkout of gnu/packages/ruby.scm, only 14 are now 
not reproducible (as opposed to 104 beforehand I think). None seem to 
fail to build the traditional way. I believe the remaining offendors are 
not reproducible because they compile native extensions leading to 
further timestamp issues. I think after this we are OK to test pure Ruby 
packages for reproducibility.

The offendors:
ruby-byebug
ruby-eventmachine
ruby-ffi
ruby-json
ruby-libxml
ruby-nokogiri
ruby-nokogumbo
ruby-ox
ruby-pg
ruby-rack
ruby-redcarpet
ruby-redcloth
ruby-rjb
ruby-unf-ext

Another case where Ruby was easier than Java? :P

Thanks,
ben