| Message ID | 20241010075413.91344-1-libcamerabmw+ml@lsmod.de |
|---|---|
| State | Superseded |
| Headers | show |
| Series |
|
| Related | show |
Quoting libcamerabmw+ml@lsmod.de (2024-10-10 08:54:13) > From: "Bernhard M. Wiedemann" <bwiedemann@suse.de> > > without this patch, openSUSE's debugsource package would vary over time, > breaking reproducible builds. > Also a copyright of 2025 is factually wrong, > because nobody did anything copyright-worthy in that year. Agreed, I'm still working on my time machine, but it's not ready yet. But I think that must be an issue on your side, or am I mistaken. Is there a reference to 2025 within the libcamera code base? > If updating the year manually is too hard (it is optional anyway), > using the mtime of input file(s) could work as well. > > The diff was: > /usr/src/debug/libcamera-0.3.1/x86_64-suse-linux/include/libcamera/internal/tracepoints.h 2024-08-20 09:37:46.000000000 +0200 > @@ -1,6 +1,6 @@ > /* SPDX-License-Identifier: LGPL-2.1-or-later */ > /* > - * Copyright (C) 2024, Google Inc. > + * Copyright (C) 2025, Google Inc. This file is autogenerated right? So this 2025 isn't an issue in our commited code - but a build server with the wrong date at Suse? > > Signed-off-by: Bernhard M. Wiedemann <bwiedemann@suse.de> > --- > utils/codegen/gen-tp-header.py | 3 +-- > 1 file changed, 1 insertion(+), 2 deletions(-) > > diff --git a/utils/codegen/gen-tp-header.py b/utils/codegen/gen-tp-header.py > index 83606c32..0a3fa644 100755 > --- a/utils/codegen/gen-tp-header.py > +++ b/utils/codegen/gen-tp-header.py > @@ -6,7 +6,6 @@ > # > # Generate header file to contain lttng tracepoints > > -import datetime > import jinja2 > import pathlib > import os > @@ -20,7 +19,7 @@ def main(argv): > output = argv[2] > template = argv[3] > > - year = datetime.datetime.now().year > + year = 2024 I would rather not hardcode this, as that then becomes the same as we may as well just remove it if it's worthless (except, I don't know what the legal issues are for removing a copyright statement so ... I'm not going there). If we set it from an mtime which is a good idea, it would probably be best to do so from the top level meson.build, as that's one file that can be guaranteed to be the same 'year' as the release. (because I modify that file to make the release). Otherwise, you'd have to parse all of the input files and take the latest mtime. That could be a good option too. In fact that might be easier as you have a list of those files, while you don't have a reference to the meson.build... > path = pathlib.Path(output).absolute().relative_to(argv[1]) > > source = '' > -- > 2.46.1
On 10/10/2024 10.51, Kieran Bingham wrote: > Quoting libcamerabmw+ml@lsmod.de (2024-10-10 08:54:13) >> From: "Bernhard M. Wiedemann" <bwiedemann@suse.de> >> The diff was: >> /usr/src/debug/libcamera-0.3.1/x86_64-suse-linux/include/libcamera/internal/tracepoints.h 2024-08-20 09:37:46.000000000 +0200 >> @@ -1,6 +1,6 @@ >> /* SPDX-License-Identifier: LGPL-2.1-or-later */ >> /* >> - * Copyright (C) 2024, Google Inc. >> + * Copyright (C) 2025, Google Inc. > > This file is autogenerated right? So this 2025 isn't an issue in our > commited code - but a build server with the wrong date at Suse? It is my test script for reproducible-builds using qemu's -rtc base= option to simulate a clock that all computers will soon have anyway. > If we set it from an mtime which is a good idea, it would probably be > best to do so from the top level meson.build, as that's one file that > can be guaranteed to be the same 'year' as the release. (because I > modify that file to make the release). > > Otherwise, you'd have to parse all of the input files and take the > latest mtime. That could be a good option too. In fact that might be > easier as you have a list of those files, while you don't have a > reference to the meson.build... Checking mtimes has the disadvantage that applying any downstream patch in our distribution would update it and thereby re-introduce this variation. A constant year is really the simplest and most reliable solution. Ciao Bernhard M.
Hi Kieran, On 10/10/24 10:51 AM, Kieran Bingham wrote: > Quoting libcamerabmw+ml@lsmod.de (2024-10-10 08:54:13) >> From: "Bernhard M. Wiedemann" <bwiedemann@suse.de> >> >> without this patch, openSUSE's debugsource package would vary over time, >> breaking reproducible builds. >> Also a copyright of 2025 is factually wrong, >> because nobody did anything copyright-worthy in that year. > > Agreed, I'm still working on my time machine, but it's not ready yet. > > But I think that must be an issue on your side, or am I mistaken. Is > there a reference to 2025 within the libcamera code base? > >> If updating the year manually is too hard (it is optional anyway), >> using the mtime of input file(s) could work as well. >> >> The diff was: >> /usr/src/debug/libcamera-0.3.1/x86_64-suse-linux/include/libcamera/internal/tracepoints.h 2024-08-20 09:37:46.000000000 +0200 >> @@ -1,6 +1,6 @@ >> /* SPDX-License-Identifier: LGPL-2.1-or-later */ >> /* >> - * Copyright (C) 2024, Google Inc. >> + * Copyright (C) 2025, Google Inc. > > This file is autogenerated right? So this 2025 isn't an issue in our > commited code - but a build server with the wrong date at Suse? > >> >> Signed-off-by: Bernhard M. Wiedemann <bwiedemann@suse.de> >> --- >> utils/codegen/gen-tp-header.py | 3 +-- >> 1 file changed, 1 insertion(+), 2 deletions(-) >> >> diff --git a/utils/codegen/gen-tp-header.py b/utils/codegen/gen-tp-header.py >> index 83606c32..0a3fa644 100755 >> --- a/utils/codegen/gen-tp-header.py >> +++ b/utils/codegen/gen-tp-header.py >> @@ -6,7 +6,6 @@ >> # >> # Generate header file to contain lttng tracepoints >> >> -import datetime >> import jinja2 >> import pathlib >> import os >> @@ -20,7 +19,7 @@ def main(argv): >> output = argv[2] >> template = argv[3] >> >> - year = datetime.datetime.now().year >> + year = 2024 > > I would rather not hardcode this, as that then becomes the same as we > may as well just remove it if it's worthless (except, I don't know what > the legal issues are for removing a copyright statement so ... I'm not > going there). > > If we set it from an mtime which is a good idea, it would probably be > best to do so from the top level meson.build, as that's one file that > can be guaranteed to be the same 'year' as the release. (because I > modify that file to make the release). > > Otherwise, you'd have to parse all of the input files and take the > latest mtime. That could be a good option too. In fact that might be > easier as you have a list of those files, while you don't have a > reference to the meson.build... > I think it's best practice to default to the content of SOURCE_DATE_EPOCH environment variable if it exists, otherwise use of now() would be fine I guess. I believe U-Boot, Buildroot and Yocto do make use of that setting? c.f. https://reproducible-builds.org/docs/source-date-epoch/ Cheers, Quentin
On Mon, Oct 14, 2024 at 02:33:13PM +0200, Quentin Schulz wrote: > Hi Kieran, > > On 10/10/24 10:51 AM, Kieran Bingham wrote: > > Quoting libcamerabmw+ml@lsmod.de (2024-10-10 08:54:13) > >> From: "Bernhard M. Wiedemann" <bwiedemann@suse.de> > >> > >> without this patch, openSUSE's debugsource package would vary over time, > >> breaking reproducible builds. > >> Also a copyright of 2025 is factually wrong, > >> because nobody did anything copyright-worthy in that year. > > > > Agreed, I'm still working on my time machine, but it's not ready yet. > > > > But I think that must be an issue on your side, or am I mistaken. Is > > there a reference to 2025 within the libcamera code base? > > > >> If updating the year manually is too hard (it is optional anyway), > >> using the mtime of input file(s) could work as well. > >> > >> The diff was: > >> /usr/src/debug/libcamera-0.3.1/x86_64-suse-linux/include/libcamera/internal/tracepoints.h 2024-08-20 09:37:46.000000000 +0200 > >> @@ -1,6 +1,6 @@ > >> /* SPDX-License-Identifier: LGPL-2.1-or-later */ > >> /* > >> - * Copyright (C) 2024, Google Inc. > >> + * Copyright (C) 2025, Google Inc. > > > > This file is autogenerated right? So this 2025 isn't an issue in our > > commited code - but a build server with the wrong date at Suse? > > > >> > >> Signed-off-by: Bernhard M. Wiedemann <bwiedemann@suse.de> > >> --- > >> utils/codegen/gen-tp-header.py | 3 +-- > >> 1 file changed, 1 insertion(+), 2 deletions(-) > >> > >> diff --git a/utils/codegen/gen-tp-header.py b/utils/codegen/gen-tp-header.py > >> index 83606c32..0a3fa644 100755 > >> --- a/utils/codegen/gen-tp-header.py > >> +++ b/utils/codegen/gen-tp-header.py > >> @@ -6,7 +6,6 @@ > >> # > >> # Generate header file to contain lttng tracepoints > >> > >> -import datetime > >> import jinja2 > >> import pathlib > >> import os > >> @@ -20,7 +19,7 @@ def main(argv): > >> output = argv[2] > >> template = argv[3] > >> > >> - year = datetime.datetime.now().year > >> + year = 2024 > > > > I would rather not hardcode this, as that then becomes the same as we > > may as well just remove it if it's worthless (except, I don't know what > > the legal issues are for removing a copyright statement so ... I'm not > > going there). > > > > If we set it from an mtime which is a good idea, it would probably be > > best to do so from the top level meson.build, as that's one file that > > can be guaranteed to be the same 'year' as the release. (because I > > modify that file to make the release). > > > > Otherwise, you'd have to parse all of the input files and take the > > latest mtime. That could be a good option too. In fact that might be > > easier as you have a list of those files, while you don't have a > > reference to the meson.build... > > I think it's best practice to default to the content of > SOURCE_DATE_EPOCH environment variable if it exists, otherwise use of > now() would be fine I guess. I believe U-Boot, Buildroot and Yocto do > make use of that setting? > > c.f. https://reproducible-builds.org/docs/source-date-epoch/ Another (and simpler) option would be to set the copyright year in tracepoints.h.in. That file contains the only copyrightable contents, the rest is generated from .tp files that I don't believe meet the bar for copyright protection.
diff --git a/utils/codegen/gen-tp-header.py b/utils/codegen/gen-tp-header.py index 83606c32..0a3fa644 100755 --- a/utils/codegen/gen-tp-header.py +++ b/utils/codegen/gen-tp-header.py @@ -6,7 +6,6 @@ # # Generate header file to contain lttng tracepoints -import datetime import jinja2 import pathlib import os @@ -20,7 +19,7 @@ def main(argv): output = argv[2] template = argv[3] - year = datetime.datetime.now().year + year = 2024 path = pathlib.Path(output).absolute().relative_to(argv[1]) source = ''