Lots of broken packages due to year changed in boilerplate: How to avoid this?
Good morning, for building ansible for SLES15 I had to branch lots of packages from dlp. Today I noticed that there are many packages in a "broken" state. And most of them show the following conflict:
# # spec file for package python-constantly # <<<<<<< .mine # Copyright (c) 2022 SUSE LLC ======= # Copyright (c) 2023 SUSE LLC
>> .new #
I guess that when modifying the spec file (to adapt something else, not this line) something[tm] changed the year automatically in the background, and hence this change is seen as "my change". Can I somehow prevent this kind of automatic changes somehow? Or can OBS be told to simply ignore changes in the boilerplate code? Having to fix dozens of packages is something I would like to avoid. :-) Kind Regards, Johannes -- Johannes Kastl Linux Consultant & Trainer Tel.: +49 (0) 151 2372 5802 Mail: kastl@b1-systems.de B1 Systems GmbH Osterfeldstraße 7 / 85088 Vohburg http://www.b1-systems.de GF: Ralph Dehner Unternehmenssitz: Vohburg / AG: Ingolstadt,HRB 3537
Hi Johannes, Johannes Kastl <kastl@b1-systems.de> writes:
Good morning,
for building ansible for SLES15 I had to branch lots of packages from dlp. Today I noticed that there are many packages in a "broken" state.
And most of them show the following conflict:
# # spec file for package python-constantly # <<<<<<< .mine # Copyright (c) 2022 SUSE LLC ======= # Copyright (c) 2023 SUSE LLC
>>> .new #
I guess that when modifying the spec file (to adapt something else, not this line) something[tm] changed the year automatically in the background, and hence this change is seen as "my change".
Can I somehow prevent this kind of automatic changes somehow? Or can OBS be told to simply ignore changes in the boilerplate code?
You could branch the packages from a specific revision (you set the revision in the magic `_link` file in the unexpanded sources), which would prevent any kind of conflicts during development. But you'll get the conflicts anyway once you try to send your changes upstream. The far simpler solution would be that we omit copyright dates from spec files, but last time I talked to legal, that was a nogo… Cheers, Dan -- Dan Čermák <dcermak@suse.com> Software Engineer Development tools SUSE Software Solutions Germany GmbH Frankenstrasse 146 90461 Nürnberg Germany (HRB 36809, AG Nürnberg) Managing Director/Geschäftsführer: Ivo Totev, Andrew Myers, Andrew McDonald, Boudien Moerman
Hi Dan, thanks for the reply. On 04.05.23 at 09:19 Dan Čermák wrote:
You could branch the packages from a specific revision (you set the revision in the magic `_link` file in the unexpanded sources), which would prevent any kind of conflicts during development. But you'll get the conflicts anyway once you try to send your changes upstream.
In this case I would like to get updates to all packages automatically and not have to update each package manually. And I would get the conflicts then while updating the revision, so I still have to fix the conflicts.... I guess I have to revisit the packages and see if I find a way to get them to build without having to touch the spec files. Have a nice day! Kind Regards, Johannes -- Johannes Kastl Linux Consultant & Trainer Tel.: +49 (0) 151 2372 5802 Mail: kastl@b1-systems.de B1 Systems GmbH Osterfeldstraße 7 / 85088 Vohburg http://www.b1-systems.de GF: Ralph Dehner Unternehmenssitz: Vohburg / AG: Ingolstadt,HRB 3537
On Thursday 2023-05-04 09:19, Dan Čermák wrote:
Johannes Kastl <kastl@b1-systems.de> writes:
# # spec file for package python-constantly # <<<<<<< .mine # Copyright (c) 2022 SUSE LLC ======= # Copyright (c) 2023 SUSE LLC
>>>> .new #
I guess that when modifying the spec file (to adapt something else, not this line) something[tm] changed the year automatically in the background, and hence this change is seen as "my change".
Can I somehow prevent this kind of automatic changes somehow? Or can OBS be told to simply ignore changes in the boilerplate code?
You could branch the packages from a specific revision (you set the revision in the magic `_link` file in the unexpanded sources), which would prevent any kind of conflicts during development. But you'll get the conflicts anyway once you try to send your changes upstream.
The far simpler solution would be that we omit copyright dates from spec files, but last time I talked to legal, that was a nogo…
Was it branched in 2021, then updated in home: in 2022, and meanwhile dlp has 2023? That could explain the failure to do a three-way merge.
Hi Jan, On 04.05.23 at 09:48 Jan Engelhardt wrote:
Was it branched in 2021, then updated in home: in 2022, and meanwhile dlp has 2023? That could explain the failure to do a three-way merge.
That would be my guess, yes. But it was not **me** that changed the year. Some automatism changed it while/after I modified the spec file. And I would like to disable this automatism (unless OBS can be told to ignore changes in the boilerplate code, which I guess is not trivial to implement). Kind Regards, Johannes -- Johannes Kastl Linux Consultant & Trainer Tel.: +49 (0) 151 2372 5802 Mail: kastl@b1-systems.de B1 Systems GmbH Osterfeldstraße 7 / 85088 Vohburg http://www.b1-systems.de GF: Ralph Dehner Unternehmenssitz: Vohburg / AG: Ingolstadt,HRB 3537
On Thursday 2023-05-04 09:50, Johannes Kastl wrote:
On 04.05.23 at 09:48 Jan Engelhardt wrote:
Was it branched in 2021, then updated in home: in 2022, and meanwhile dlp has 2023? That could explain the failure to do a three-way merge.
That would be my guess, yes.
But it was not **me** that changed the year. Some automatism changed it while/after I modified the spec file.
And I would like to disable this automatism
osc ci --noservice or so.
Good morning Jan, On 04.05.23 at 10:19 Jan Engelhardt wrote:
On Thursday 2023-05-04 09:50, Johannes Kastl wrote:
But it was not **me** that changed the year. Some automatism changed it while/after I modified the spec file.
And I would like to disable this automatism
osc ci --noservice
or so.
Hmmm. I guess this disables lots of services that might run? And not just the "change the year in the license line" service? I'll give it a try. Kind Regards, Johannes -- Johannes Kastl Linux Consultant & Trainer Tel.: +49 (0) 151 2372 5802 Mail: kastl@b1-systems.de B1 Systems GmbH Osterfeldstraße 7 / 85088 Vohburg http://www.b1-systems.de GF: Ralph Dehner Unternehmenssitz: Vohburg / AG: Ingolstadt,HRB 3537
participants (3)
-
Dan Čermák -
Jan Engelhardt -
Johannes Kastl