New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

dealii claims copyright for future years #7251

Closed
bmwiedemann opened this Issue Oct 1, 2018 · 7 comments

Comments

Projects
None yet
4 participants
@bmwiedemann

bmwiedemann commented Oct 1, 2018

When I built dealii in the year 2033, I got such a diff:

--- /usr/share/doc/packages/dealii/doxygen/deal.II/work__stream_8h_source.html      2033-10-28
+++ /usr/share/doc/packages/dealii/doxygen/deal.II/work__stream_8h_source.html      2018-09-28
@@ -18,7 +18,7 @@
 <link rel="SHORTCUT ICON" href="deal.ico"></link>
 <script type="text/javascript" src="custom.js"></script>
 <meta name="author" content="The deal.II Authors <authors@dealii.org>"></meta>
-<meta name="copyright" content="Copyright (C) 1998 - 2018 by the deal.II authors"></meta>
+<meta name="copyright" content="Copyright (C) 1998 - 2033 by the deal.II authors"></meta>
 <meta name="deal.II-version" content="8.5.1"></meta>
 </head>

See also https://reproducible-builds.org/ for why this matters.

This bug was found while working on reproducible builds for openSUSE.

@tjhei

This comment has been minimized.

Show comment
Hide comment
@tjhei

This comment has been minimized.

Show comment
Hide comment
@tjhei

tjhei Oct 1, 2018

Member

We could fix this on master to use the date from ./VERSION or something but your diff shows that you are building a 8.5.1 package. Is this something worth back-porting?

Member

tjhei commented Oct 1, 2018

We could fix this on master to use the date from ./VERSION or something but your diff shows that you are building a 8.5.1 package. Is this something worth back-porting?

@bangerth

This comment has been minimized.

Show comment
Hide comment
@bangerth

bangerth Oct 1, 2018

Member

Well, that's actually a bit funny :-) We could just strip the copyright date out of the pages, but I think it's not wrong to have a copyright date in each HTML page, and that's what the mod_header.pl script does.

What it does wrong is to take the current year, and not the year in which the source files for the doxygen HTML pages were last modified. It would not be terribly difficult to extract that date from all of the source files at cmake time, and consequently make the year in the HTML pages independent of the year in which the HTML pages are built. @bmwiedemann -- is this what you would suggest we do?

Member

bangerth commented Oct 1, 2018

Well, that's actually a bit funny :-) We could just strip the copyright date out of the pages, but I think it's not wrong to have a copyright date in each HTML page, and that's what the mod_header.pl script does.

What it does wrong is to take the current year, and not the year in which the source files for the doxygen HTML pages were last modified. It would not be terribly difficult to extract that date from all of the source files at cmake time, and consequently make the year in the HTML pages independent of the year in which the HTML pages are built. @bmwiedemann -- is this what you would suggest we do?

@bmwiedemann

This comment has been minimized.

Show comment
Hide comment
@bmwiedemann

bmwiedemann Oct 2, 2018

@bangerth that could work, but is sometimes troublesome if we apply distribution patches during package build, which updates mtime of input files. So taking the VERSION file's mtime would be more reliable.

Fixing it in master is good enough. Eventually all other versions will be obsolete ;-)

bmwiedemann commented Oct 2, 2018

@bangerth that could work, but is sometimes troublesome if we apply distribution patches during package build, which updates mtime of input files. So taking the VERSION file's mtime would be more reliable.

Fixing it in master is good enough. Eventually all other versions will be obsolete ;-)

@bangerth

This comment has been minimized.

Show comment
Hide comment
@bangerth

bangerth Oct 2, 2018

Member

OK, I think I can figure this out. Do you happen to recall a way to determine VERSION's mtime from cmake? (I suspect this isn't the first time you encounter this kind of problem :-)

Member

bangerth commented Oct 2, 2018

OK, I think I can figure this out. Do you happen to recall a way to determine VERSION's mtime from cmake? (I suspect this isn't the first time you encounter this kind of problem :-)

@bmwiedemann

This comment has been minimized.

Show comment
Hide comment
@bmwiedemann

bmwiedemann Oct 2, 2018

on UNIXy systems, stat -c %y could help, but many cases I know just solved it with a variable set to a constant 2018 (and a git commit to update it every year)

bmwiedemann commented Oct 2, 2018

on UNIXy systems, stat -c %y could help, but many cases I know just solved it with a variable set to a constant 2018 (and a git commit to update it every year)

@tamiko

This comment has been minimized.

Show comment
Hide comment
@tamiko

tamiko Oct 2, 2018

Member

Let's just query the year from a YEAR file (similarly to the VERSION file). That way this is also platform independent.

Member

tamiko commented Oct 2, 2018

Let's just query the year from a YEAR file (similarly to the VERSION file). That way this is also platform independent.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment