You are viewing a plain text version of this content. The canonical link for it is here.
Posted to commits@buildstream.apache.org by GitBox <gi...@apache.org> on 2022/02/01 22:49:58 UTC
[GitHub] [buildstream] doraskayo opened a new issue #1580: %{source-date-epoch} is not set to the last modification time of an element's sources
doraskayo opened a new issue #1580:
URL: https://github.com/apache/buildstream/issues/1580
# Description
`%{source-date-epoch}` is currently a constant value set to 2011-11-11 11:11:11 UTC. Projects such as freedesktop-sdk commonly use this variable to define the `$SOURCE_DATE_EPOCH` environment variable inside the sandbox, thus allowing reproducible builds.
However, according to the established spec, `$SOURCE_DATE_EPOCH` should be set to the modification date of the source, as its name suggets: (from https://reproducible-builds.org/specs/source-date-epoch/)
> The value MUST be reproducible (deterministic) across different executions of the build, depending only on the source code. **It SHOULD be set to the last modification time of the source, incorporating any packaging-specific modifications.**
# Potential solution
One idea to accomplish this by allowing source plugins to implement a function that gets the last modification time of their fetched source. `git`-based plugins could use the commit timestamp, `tar` could use the modification date of the fetched file, etc.
BuildStream would then consult with each source plugin in a given element, and dynamically push the latest source date from each of the source plugins into the `%{source-date-epoch}` variable. So when source plugins are present in an element, the `%{source-date-epoch}` variable would essentially be dynamically updated (similarly to `%{max-jobs}`) to the actual source date. Otherwise, if no source plugins are present, the source date would remain with the sane default of 2011-11-11 11:11:11 UTC.
Projects defining their `$SOURCE_DATE_EPOCH` environment variable according to the `%{source-date-epoch}` variable would then become compliant with the spec, assuming the source plugins they rely upon actually provide a souce date.
This function can be made optional to plugins, and only "nice" plugins would implement it and provide a source date. This also be done in bst-1, but using a new variable (not `%{source-date-epoch}`), to avoid affecting the cache key.
It can also be made mandatory (but only in bst master), and plugins that don't have a way to provide the source date could return NULL to indicate this.
--
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: commits-unsubscribe@buildstream.apache.org
For queries about this service, please contact Infrastructure at:
users@infra.apache.org
[GitHub] [buildstream] gtristan edited a comment on issue #1580: %{source-date-epoch} is not set to the last modification time of an element's sources
Posted by GitBox <gi...@apache.org>.
gtristan edited a comment on issue #1580:
URL: https://github.com/apache/buildstream/issues/1580#issuecomment-1027503540
I think we quite intentionally disregard that `SHOULD` statement and already manage to provide a constant value that is deterministic across all build executions.
Is there any practical reason why the current constant value will lead to incorrect results ?
I’m scratching my head wondering what is the problem exactly you are trying to solve with this, I don’t think following the `SHOULD` recommendation in itself solves anything, or justifies any of the proposed changes.
--
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: commits-unsubscribe@buildstream.apache.org
For queries about this service, please contact Infrastructure at:
users@infra.apache.org
[GitHub] [buildstream] gtristan edited a comment on issue #1580: %{source-date-epoch} is not set to the last modification time of an element's sources
Posted by GitBox <gi...@apache.org>.
gtristan edited a comment on issue #1580:
URL: https://github.com/apache/buildstream/issues/1580#issuecomment-1028540884
> @gtristan eg OpenSSL is using this value to generate copyright year for generated code. Current BuildStream behaviour is quite possibly resulting in copyright violation.
Thanks for providing some background.
I'm personally not happy with engineering anything of this scale to work around one or *theoretically more than one* module who took it upon themselves to trust `SOURCE_DATE_EPOCH` to provide something it is not guaranteed to provide (i.e. there is no guarantee that `SOURCE_DATE_EPOCH` is the last modification time of the source, it is only recommended to be such - a better source of truth would be to observe the latest commit in the owning git repository, as many modules observe git tags to derive a version number). At this point, we could easily be betting on the wrong pony in this race, and it may very well turn out that using `SOURCE_DATE_EPOCH` in this way was a one time occurrence by OpenSSL, or that a more reliable/different technique (e.g. git) become the norm over time - it would be unwise I think to jump on implementing something to automate this in advance of this becoming a normal thing.
I'm also curious, as this variable is derived from debian reproducible builds, *how* exactly debian is going about providing this value - if I had to guess, `SOURCE_DATE_EPOCH` is probably derived from a value that the package maintainer sets in the packaging metadata in advance of rolling a release of that package, and there is no complex automation on that side to obtain the value either.
In the case that one *wanted* to provide a `SOURCE_DATE_EPOCH` when updating a module in a BuildStream project, one could just as well manually override the default `2011-11-11 11:11:11 UTC` value in the element's environment section; I would consider this to be a very rare thing one would do in the case they had a module which unexpectedly decided to interpret `SOURCE_DATE_EPOCH` explicitly during the build in order to produce some meaningful output (like a copyright declaration in some documentation as openssl seems to be doing).
--
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: commits-unsubscribe@buildstream.apache.org
For queries about this service, please contact Infrastructure at:
users@infra.apache.org
[GitHub] [buildstream] gtristan commented on issue #1580: %{source-date-epoch} is not set to the last modification time of an element's sources
Posted by GitBox <gi...@apache.org>.
gtristan commented on issue #1580:
URL: https://github.com/apache/buildstream/issues/1580#issuecomment-1043597631
> No, OpenSSL is the only part where this BuildStream behaviour has clear legal consequences. Not every project has been analyzed. This was because it was failing reproducibility test before they took SOURCE_DATE_EPOCH into wider use
Right, and I’m clearly saying it’s the opposite: it’s the OpenSSL behavior which is asking for trouble IMO, this outlier behaving in this strange way should not be our problem.
If it’s important to a project that builds OpenSSL to get their copyright generated properly, they should probably set the env var manually in the bst file and/or file an issue with OpenSSL suggesting they use another way to obtain the copyright year, rather than relying on the variable which we’ve already established has never been guaranteed to provide the correct value.
--
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: commits-unsubscribe@buildstream.apache.org
For queries about this service, please contact Infrastructure at:
users@infra.apache.org
[GitHub] [buildstream] nanonyme commented on issue #1580: %{source-date-epoch} is not set to the last modification time of an element's sources
Posted by GitBox <gi...@apache.org>.
nanonyme commented on issue #1580:
URL: https://github.com/apache/buildstream/issues/1580#issuecomment-1042613067
I meant, if it is simpler for BuildStream to use as timestamp that is at least as new as source-driven timestamp, then that is also fine here. Currently a much older value is always used.
--
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: commits-unsubscribe@buildstream.apache.org
For queries about this service, please contact Infrastructure at:
users@infra.apache.org
[GitHub] [buildstream] gtristan commented on issue #1580: %{source-date-epoch} is not set to the last modification time of an element's sources
Posted by GitBox <gi...@apache.org>.
gtristan commented on issue #1580:
URL: https://github.com/apache/buildstream/issues/1580#issuecomment-1042741561
> I meant, if it is simpler for BuildStream to use as timestamp that is at least as new as source-driven timestamp, then that is also fine here. Currently a much older value is always used.
Right, and there is nothing wrong with using an older time stamp either afaics, except for corner case libraries like OpenSSL doing unexpected things with this value, which can be worked around by manually setting the variable… that’s my understanding right now.
I think it might make sense to do something dynamic here to resolve the value as proposed, if it turns out to be very trendy to interpret source date epoch variable and lots of modules start doing this, but I don’t expect this to be the case (and rather have my fingers crossed that this won’t happen, git would be a better source of truth for this sort of thing).
--
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: commits-unsubscribe@buildstream.apache.org
For queries about this service, please contact Infrastructure at:
users@infra.apache.org
[GitHub] [buildstream] nanonyme commented on issue #1580: %{source-date-epoch} is not set to the last modification time of an element's sources
Posted by GitBox <gi...@apache.org>.
nanonyme commented on issue #1580:
URL: https://github.com/apache/buildstream/issues/1580#issuecomment-1027813206
@gtristan eg OpenSSL is using this value to generate copyright year for generated code. Current BuildStream behaviour is quite possibly resulting in copyright violation.
--
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: commits-unsubscribe@buildstream.apache.org
For queries about this service, please contact Infrastructure at:
users@infra.apache.org
[GitHub] [buildstream] nanonyme commented on issue #1580: %{source-date-epoch} is not set to the last modification time of an element's sources
Posted by GitBox <gi...@apache.org>.
nanonyme commented on issue #1580:
URL: https://github.com/apache/buildstream/issues/1580#issuecomment-1028401732
This is most likely not the only project that is assuming SOURCE_DATE_EPOCH is derived from real source modification time.
--
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: commits-unsubscribe@buildstream.apache.org
For queries about this service, please contact Infrastructure at:
users@infra.apache.org
[GitHub] [buildstream] nanonyme commented on issue #1580: %{source-date-epoch} is not set to the last modification time of an element's sources
Posted by GitBox <gi...@apache.org>.
nanonyme commented on issue #1580:
URL: https://github.com/apache/buildstream/issues/1580#issuecomment-1030634762
Note it is entirely fine to have newer value than source-based timestamp, however, for cache key stability source-based timestamp is best.
--
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: commits-unsubscribe@buildstream.apache.org
For queries about this service, please contact Infrastructure at:
users@infra.apache.org
[GitHub] [buildstream] nanonyme commented on issue #1580: %{source-date-epoch} is not set to the last modification time of an element's sources
Posted by GitBox <gi...@apache.org>.
nanonyme commented on issue #1580:
URL: https://github.com/apache/buildstream/issues/1580#issuecomment-1030634576
I was told Debian build system automatically constructs the value based on Debian change log.
--
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: commits-unsubscribe@buildstream.apache.org
For queries about this service, please contact Infrastructure at:
users@infra.apache.org
[GitHub] [buildstream] gtristan commented on issue #1580: %{source-date-epoch} is not set to the last modification time of an element's sources
Posted by GitBox <gi...@apache.org>.
gtristan commented on issue #1580:
URL: https://github.com/apache/buildstream/issues/1580#issuecomment-1028540884
> @gtristan eg OpenSSL is using this value to generate copyright year for generated code. Current BuildStream behaviour is quite possibly resulting in copyright violation.
Thanks for providing some background.
I'm personally not happy with engineering anything of this scale to work around one or *theoretically more than one* module who took it upon themselves to trust `SOURCE_DATE_EPOCH` to provide something it is not guaranteed to provide (i.e. there is no guarantee that `SOURCE_DATE_EPOCH` is the last modification time of the source, it is only recommended to be such - a better source of truth would be to observe the latest commit in the owning git repository, as many modules observe git tags to derive a version number). At this point, we could easily be betting on the wrong pony in this race, and it may very well turn out that using `SOURCE_DATE_EPOCH` in this way was a one time occurrence by OpenSSL, or that a more reliable/different technique (e.g. git) become the norm over time - it would be unwise I think to jump on implementing something to automate this in advance of this becoming a normal thing.
I'm also curious, as this is variable is derived from debian reproducible builds, *how* exactly debian is going about providing this value - if I had to guess, `SOURCE_DATE_EPOCH` is probably derived from a value that the package maintainer sets in the packaging metadata in advance of rolling a release of that package, and there is no complex automation on that side to obtain the value either.
In the case that one *wanted* to provide a `SOURCE_DATE_EPOCH` when updating a module in a BuildStream project, one could just as well manually override the default `2011-11-11 11:11:11 UTC` value in the element's environment section; I would consider this to be a very rare thing one would do in the case they had a module which unexpectedly decided to interpret `SOURCE_DATE_EPOCH` explicitly during the build in order to produce some meaningful output (like a copyright declaration in some documentation as openssl seems to be doing).
--
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: commits-unsubscribe@buildstream.apache.org
For queries about this service, please contact Infrastructure at:
users@infra.apache.org
[GitHub] [buildstream] gtristan edited a comment on issue #1580: %{source-date-epoch} is not set to the last modification time of an element's sources
Posted by GitBox <gi...@apache.org>.
gtristan edited a comment on issue #1580:
URL: https://github.com/apache/buildstream/issues/1580#issuecomment-1044080977
> The problem is this is generated source code so the copyright is supposed to reflect when code is generated, not when last human change is committed to git.
I doubt that is the case, and if so, it would seem dishonest to me. An author does not get to extend their copyright just because new copies of their book are published. If they wanted to be pedantic, then probably the generated code's copyright year should only be updated when parts of the code involved in that code generation have changed. I still think that the latest git commit is the most reasonable value for openssl as an automated solution.
We are however straying off topic.
What I'm looking at is a proposal for BuildStream to carry a new API for Sources, which we basically would have to carry *forever* in the code base, all for the sake of a single module - all while this can just as well be worked around by manually setting `SOURCE_DATE_EPOCH` environment variable periodically in an `openssl.bst` element. Yes this would have to be done whenever updating openssl versions (similarly, debian package maintainers manually enter changelogs from which they derive this environment variable).
To add to that, we could very well make the wasteful mistake of incorporating this new API, while OpenSSL can very well choose to use a more sensible approach (e.g. git commit date) in the future, rendering this new API *completely* useless (instead of useful for exactly 1 module).
Looking at the cost/benefit, I think it's definitely a bad idea to reach as far as engineering an automated solution for this in buildstream, considering this is a trend of one single module, the benefits are not really compelling here.
--
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: commits-unsubscribe@buildstream.apache.org
For queries about this service, please contact Infrastructure at:
users@infra.apache.org
[GitHub] [buildstream] gtristan commented on issue #1580: %{source-date-epoch} is not set to the last modification time of an element's sources
Posted by GitBox <gi...@apache.org>.
gtristan commented on issue #1580:
URL: https://github.com/apache/buildstream/issues/1580#issuecomment-1042578381
> Note it is entirely fine to have newer value than source-based timestamp, however, for cache key stability source-based timestamp is best.
Can you elaborate here ?
As far as I can tell, `SOURCE_DATE_EPOCH` will affect the cache key - and if your source code changes it will also affect the cache key.
I'm still not seeing any compelling reason to implement something complex like this.
--
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: commits-unsubscribe@buildstream.apache.org
For queries about this service, please contact Infrastructure at:
users@infra.apache.org
[GitHub] [buildstream] gtristan commented on issue #1580: %{source-date-epoch} is not set to the last modification time of an element's sources
Posted by GitBox <gi...@apache.org>.
gtristan commented on issue #1580:
URL: https://github.com/apache/buildstream/issues/1580#issuecomment-1044080977
> The problem is this is generated source code so the copyright is supposed to reflect when code is generated, not when last human change is committed to git.
I doubt that is the case, and if so, it would seem dishonest to me. An author does not get to extend their copyright just because new copies of their book are published. If they wanted to be pedantic, then probably the generated code's copyright year should only be updated when parts of the code involved in that code generation have changed. I still think that the latest git commit is the most reasonable value for openssl as an automated solution.
We are however straying off topic.
What I'm looking at is a proposal for BuildStream to carry a new API for Sources, which we basically would have to carry *forever* in the code base, all for the sake of a single module - all while this can just as well be worked around by manually setting `SOURCE_DATE_EPOCH` environment variable periodically in an `openssl.bst` element. Yes this would have to be done whenever updating openssl versions (similarly, debian package maintainers manually enter changelogs from which they derive this environment variable).
Looking at the cost/benefit, I think it's definitely a bad idea to reach as far as engineering an automated solution for this in buildstream, considering this is a trend of one single module, the benefits are not really compelling here.
--
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: commits-unsubscribe@buildstream.apache.org
For queries about this service, please contact Infrastructure at:
users@infra.apache.org
[GitHub] [buildstream] nanonyme commented on issue #1580: %{source-date-epoch} is not set to the last modification time of an element's sources
Posted by GitBox <gi...@apache.org>.
nanonyme commented on issue #1580:
URL: https://github.com/apache/buildstream/issues/1580#issuecomment-1043049240
No, OpenSSL is the only part where this BuildStream behaviour has clear legal consequences. Not every project has been analyzed. This was because it was failing reproducibility test before they took SOURCE_DATE_EPOCH into wider use
--
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: commits-unsubscribe@buildstream.apache.org
For queries about this service, please contact Infrastructure at:
users@infra.apache.org
[GitHub] [buildstream] nanonyme commented on issue #1580: %{source-date-epoch} is not set to the last modification time of an element's sources
Posted by GitBox <gi...@apache.org>.
nanonyme commented on issue #1580:
URL: https://github.com/apache/buildstream/issues/1580#issuecomment-1043958201
The problem is this is generated source code so the copyright is supposed to reflect when code is generated, not when last human change is committed to git.
--
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: commits-unsubscribe@buildstream.apache.org
For queries about this service, please contact Infrastructure at:
users@infra.apache.org
[GitHub] [buildstream] gtristan edited a comment on issue #1580: %{source-date-epoch} is not set to the last modification time of an element's sources
Posted by GitBox <gi...@apache.org>.
gtristan edited a comment on issue #1580:
URL: https://github.com/apache/buildstream/issues/1580#issuecomment-1028540884
> @gtristan eg OpenSSL is using this value to generate copyright year for generated code. Current BuildStream behaviour is quite possibly resulting in copyright violation.
Thanks for providing some background.
I'm personally not happy with engineering anything of this scale to work around one or *theoretically more than one* module who took it upon themselves to trust `SOURCE_DATE_EPOCH` to provide something it is not guaranteed to provide (i.e. there is no guarantee that `SOURCE_DATE_EPOCH` is the last modification time of the source, it is only recommended to be such - a better source of truth would be to observe the latest commit in the owning git repository, as many modules observe git tags to derive a version number). At this point, we could easily be betting on the wrong pony in this race, and it may very well turn out that using `SOURCE_DATE_EPOCH` in this way was a one time occurrence by OpenSSL, or that a more reliable/different technique (e.g. git) become the norm over time - it would be unwise I think to jump on implementing something to automate this in advance of this becoming a normal thing.
I'm also curious, as this variable is derived from debian reproducible builds, *how* exactly debian is going about providing this value - if I had to guess, `SOURCE_DATE_EPOCH` is probably derived from a value that the package maintainer sets in the packaging metadata in advance of rolling a release of that package, and there is no complex automation on that side to obtain the value either.
In the case that one *wanted* to provide a `SOURCE_DATE_EPOCH` when updating a module in a BuildStream project, one could just as well manually override the default `2011-11-11 11:11:11 UTC` value in the element's environment section; I would consider this to be a very rare thing one would do in the case they had a module which decided to interpret `SOURCE_DATE_EPOCH` explicitly during the build in order to produce some meaningful output (as OpenSSL appears to be doing).
--
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: commits-unsubscribe@buildstream.apache.org
For queries about this service, please contact Infrastructure at:
users@infra.apache.org
[GitHub] [buildstream] nanonyme commented on issue #1580: %{source-date-epoch} is not set to the last modification time of an element's sources
Posted by GitBox <gi...@apache.org>.
nanonyme commented on issue #1580:
URL: https://github.com/apache/buildstream/issues/1580#issuecomment-1028403035
I'm not sure it's enough to rely on modification time of the tarball. It's what is inside it whose timestamps matter.
--
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: commits-unsubscribe@buildstream.apache.org
For queries about this service, please contact Infrastructure at:
users@infra.apache.org
[GitHub] [buildstream] nanonyme edited a comment on issue #1580: %{source-date-epoch} is not set to the last modification time of an element's sources
Posted by GitBox <gi...@apache.org>.
nanonyme edited a comment on issue #1580:
URL: https://github.com/apache/buildstream/issues/1580#issuecomment-1028403035
I'm not sure it's enough to rely on modification time of the tarball. It's what is inside it whose timestamps matter. That also guarantees the value does not change unless ref changes. The value clearly must be deterministic. We can probably disregard modification time of other things than archives and scm.
--
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: commits-unsubscribe@buildstream.apache.org
For queries about this service, please contact Infrastructure at:
users@infra.apache.org
[GitHub] [buildstream] nanonyme edited a comment on issue #1580: %{source-date-epoch} is not set to the last modification time of an element's sources
Posted by GitBox <gi...@apache.org>.
nanonyme edited a comment on issue #1580:
URL: https://github.com/apache/buildstream/issues/1580#issuecomment-1028403035
I'm not sure it's enough to rely on modification time of the tarball. It's what is inside it whose timestamps matter. That also guarantees the value does not change unless ref changes
--
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: commits-unsubscribe@buildstream.apache.org
For queries about this service, please contact Infrastructure at:
users@infra.apache.org
[GitHub] [buildstream] gtristan commented on issue #1580: %{source-date-epoch} is not set to the last modification time of an element's sources
Posted by GitBox <gi...@apache.org>.
gtristan commented on issue #1580:
URL: https://github.com/apache/buildstream/issues/1580#issuecomment-1027503540
I think we quite intentionally disregard that `SHOULD` statement and already manage to provide a constant value that is deterministic across all build executions.
Is there any practical reason why the current constant value will lead to incorrect results ?
I’m scratching my head wondering the problem exactly you are trying to solve with this, I don’t think following the `SHOULD` recommendation in itself solves anything, or justifies any of the proposed changes.
--
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: commits-unsubscribe@buildstream.apache.org
For queries about this service, please contact Infrastructure at:
users@infra.apache.org
[GitHub] [buildstream] nanonyme commented on issue #1580: %{source-date-epoch} is not set to the last modification time of an element's sources
Posted by GitBox <gi...@apache.org>.
nanonyme commented on issue #1580:
URL: https://github.com/apache/buildstream/issues/1580#issuecomment-1042781895
Right, it's not entirely straightforward to set environment variables from git that last for entire build though.
--
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: commits-unsubscribe@buildstream.apache.org
For queries about this service, please contact Infrastructure at:
users@infra.apache.org
[GitHub] [buildstream] gtristan edited a comment on issue #1580: %{source-date-epoch} is not set to the last modification time of an element's sources
Posted by GitBox <gi...@apache.org>.
gtristan edited a comment on issue #1580:
URL: https://github.com/apache/buildstream/issues/1580#issuecomment-1042946878
> Right, it's not entirely straightforward to set environment variables from git that last for entire build though.
But there is no need for that.
I’m saying that it’s a better strategy for OpenSSL to read the date of the latest git commit and use *that date* for the copyright year in generated code (similarly to how many modules use git tags to generate a version number during the build).
Right now OpenSSL is an outlier for doing this with the source date epoch environment variable, and I’m arguing that it’s not really the most suitable way to derive this date anyway.
--
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: commits-unsubscribe@buildstream.apache.org
For queries about this service, please contact Infrastructure at:
users@infra.apache.org
[GitHub] [buildstream] gtristan commented on issue #1580: %{source-date-epoch} is not set to the last modification time of an element's sources
Posted by GitBox <gi...@apache.org>.
gtristan commented on issue #1580:
URL: https://github.com/apache/buildstream/issues/1580#issuecomment-1042946878
> Right, it's not entirely straightforward to set environment variables from git that last for entire build though.
But there is no need for that.
I’m saying that it’s a better strategy for OpenSSL to read the date of the latest for commit and use *that date* for the copyright year in generated code (similarly to how many modules use git tags to generate a version number during the build).
Right now OpenSSL is an outlier for doing this with the source date epoch environment variable, and I’m arguing that it’s not really the most suitable way to derive this date anyway.
--
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: commits-unsubscribe@buildstream.apache.org
For queries about this service, please contact Infrastructure at:
users@infra.apache.org