Hi everybody,
Recently, there was opened this ticket:
https://bugzilla.redhat.com/show_bug.cgi?id=1719647
In short, there are some issues with -doc noarch subpackages, which are not precisely identical coming from different builders, due to embedded timestamps. As it turns out, there is SOURCE_DATE_EPOCH environment variable available in RDoc, which allows to specify the timestamp and therefore workaround the issue. And I think this could be useful for our packages, therefore I created this PR:
https://src.fedoraproject.org/rpms/ruby/pull-request/47
It modifies %gem_install macro and sets the timestamp for each gem. Is there any reason, why not merge this PR?
Vít
On Wed, Jun 19, 2019 at 10:44 AM Vít Ondruch vondruch@redhat.com wrote:
Hi everybody,
Recently, there was opened this ticket:
https://bugzilla.redhat.com/show_bug.cgi?id=1719647
In short, there are some issues with -doc noarch subpackages, which are not precisely identical coming from different builders, due to embedded timestamps. As it turns out, there is SOURCE_DATE_EPOCH environment variable available in RDoc, which allows to specify the timestamp and therefore workaround the issue. And I think this could be useful for our packages, therefore I created this PR:
https://src.fedoraproject.org/rpms/ruby/pull-request/47
It modifies %gem_install macro and sets the timestamp for each gem. Is there any reason, why not merge this PR?
It's probably better to use that variable along with having rpm's feature to populate that variable on.
%source_date_epoch_from_changelog Y
We should probably turn this on in redhat-rpm-config...
Dne 19. 06. 19 v 16:49 Neal Gompa napsal(a):
On Wed, Jun 19, 2019 at 10:44 AM Vít Ondruch vondruch@redhat.com wrote:
Hi everybody,
Recently, there was opened this ticket:
https://bugzilla.redhat.com/show_bug.cgi?id=1719647
In short, there are some issues with -doc noarch subpackages, which are not precisely identical coming from different builders, due to embedded timestamps. As it turns out, there is SOURCE_DATE_EPOCH environment variable available in RDoc, which allows to specify the timestamp and therefore workaround the issue. And I think this could be useful for our packages, therefore I created this PR:
https://src.fedoraproject.org/rpms/ruby/pull-request/47
It modifies %gem_install macro and sets the timestamp for each gem. Is there any reason, why not merge this PR?
It's probably better to use that variable along with having rpm's feature to populate that variable on.
%source_date_epoch_from_changelog Y
We should probably turn this on in redhat-rpm-config...
Ah, I was not aware there is something like this possible in RPM. That would be much better to have this enabled by default. So are you going to propose change in defaults?
Vít
Dne 19. 06. 19 v 16:55 Vít Ondruch napsal(a):
Dne 19. 06. 19 v 16:49 Neal Gompa napsal(a):
On Wed, Jun 19, 2019 at 10:44 AM Vít Ondruch vondruch@redhat.com wrote:
Hi everybody,
Recently, there was opened this ticket:
https://bugzilla.redhat.com/show_bug.cgi?id=1719647
In short, there are some issues with -doc noarch subpackages, which are not precisely identical coming from different builders, due to embedded timestamps. As it turns out, there is SOURCE_DATE_EPOCH environment variable available in RDoc, which allows to specify the timestamp and therefore workaround the issue. And I think this could be useful for our packages, therefore I created this PR:
https://src.fedoraproject.org/rpms/ruby/pull-request/47
It modifies %gem_install macro and sets the timestamp for each gem. Is there any reason, why not merge this PR?
It's probably better to use that variable along with having rpm's feature to populate that variable on.
%source_date_epoch_from_changelog Y
We should probably turn this on in redhat-rpm-config...
Ah, I was not aware there is something like this possible in RPM. That would be much better to have this enabled by default. So are you going to propose change in defaults?
Actually I went ahead and opened this PR:
https://src.fedoraproject.org/rpms/redhat-rpm-config/pull-request/57
Vít
ruby-sig@lists.fedoraproject.org