[opensuse-packaging] format_spec_file service
Hi, I'm testing a new version of the format_spec_file service (you can find the sources on github's openSUSE project) and this results in submit requests of mine to: - remove #norootforbuild - remove duplicated group and license from sub packages - patch license field to apply to spdx.org (where I can, this needs to improve and is in discussion with legal how to handle the corner cases) - split buildrequires in single lines (I'll try to keep two adjacent buildrequire lines sorted). That should be what I changed, but just so you don't get afraid :) Greetings, Stephan -- To unsubscribe, e-mail: opensuse-packaging+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-packaging+owner@opensuse.org
On Thu, 1 Dec 2011, Stephan Kulow wrote:
Hi,
I'm testing a new version of the format_spec_file service (you can find the sources on github's openSUSE project) and this results in submit requests of mine to:
- remove #norootforbuild - remove duplicated group and license from sub packages - patch license field to apply to spdx.org (where I can, this needs to improve and is in discussion with legal how to handle the corner cases) - split buildrequires in single lines (I'll try to keep two adjacent buildrequire lines sorted).
That should be what I changed, but just so you don't get afraid :)
Umm....
How are "duplicated license" detected?
And why do we add more to this service rather than removing it?
Or, make running it optional (how do I turn this off for a devel
project or a specific package for example?)
It makes reviewing local changes impossible for packages which
generate their spec files automatically from input files.
Thanks,
Richard.
--
Richard Guenther
Am Donnerstag, 1. Dezember 2011, 12:37:12 schrieb Richard Guenther:
On Thu, 1 Dec 2011, Stephan Kulow wrote:
Hi,
I'm testing a new version of the format_spec_file service (you can find the sources on github's openSUSE project) and this results in submit requests of mine to:
- remove #norootforbuild - remove duplicated group and license from sub packages - patch license field to apply to spdx.org (where I can,
this needs to improve and is in discussion with legal how to handle the corner cases)
- split buildrequires in single lines (I'll try to keep
two adjacent buildrequire lines sorted).
That should be what I changed, but just so you don't get afraid :)
Umm....
How are "duplicated license" detected?
And why do we add more to this service rather than removing it? Or, make running it optional (how do I turn this off for a devel project or a specific package for example?)
That would mean that sources may turn into broken or conflicts after checkin into factory. Our goal is to see obvious violations as soon as possible, in best case even before the packager is commiting. That makes the checks transparent, is reducing the amount of needed reviews and the packager does not need to wait just to see the result of checks.
It makes reviewing local changes impossible for packages which generate their spec files automatically from input files.
Well, our policy is to have a unique layout and we even are required to do so legal wise to some degree. So if you generate spec files, best is also to run the formater directly so you can see the differences.
Thanks, Richard. -- Adrian Schroeter SUSE Linux Products GmbH email: adrian@suse.de
-- To unsubscribe, e-mail: opensuse-packaging+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-packaging+owner@opensuse.org
On Dec 01, 11 13:34:52 +0100, Adrian Schröter wrote:
I'm testing a new version of the format_spec_file service It makes reviewing local changes impossible for packages which generate their spec files automatically from input files.
Well, our policy is to have a unique layout and we even are required to do so legal wise to some degree.
A new legal requirement is: We adopt the SPDX standard for license names. (E.g. where we had "GPL 2 or later" we now say "GPL-2.0+".) Such name changes need to propagate into your spec file input files. But how does that make reviewing local changes impossible? cheers, Jw- -- o \ Juergen Weigert paint it green! __/ _=======.=======_ <V> | jw@suse.de back to ascii! __/ _---|____________\/ \ | 0911 74053-508 __/ (____/ /\ (/) | _____________________________/ _/ \_ vim:set sw=2 wm=8 SUSE LINUX Products GmbH, GF: Jeff Hawn, J.Guild, F.Imendoerffer, HRB 16746 (AG Nuernberg), Maxfeldstrasse 5, 90409 Nuernberg, Germany SuSE. Supporting Linux since 1992. -- To unsubscribe, e-mail: opensuse-packaging+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-packaging+owner@opensuse.org
On Thu, 1 Dec 2011, Juergen Weigert wrote:
On Dec 01, 11 13:34:52 +0100, Adrian Schröter wrote:
I'm testing a new version of the format_spec_file service It makes reviewing local changes impossible for packages which generate their spec files automatically from input files.
Well, our policy is to have a unique layout and we even are required to do so legal wise to some degree.
A new legal requirement is: We adopt the SPDX standard for license names. (E.g. where we had "GPL 2 or later" we now say "GPL-2.0+".) Such name changes need to propagate into your spec file input files. But how does that make reviewing local changes impossible?
I review .spec file changes that result from changing the .spec.in files and re-generating them. But doing so and using osc diff on the .spec file produces a huge unreadable diff now (mostly not due to the license change stuff). How can I run the formatter on a selected file (in my case, the .spec.in file)? Richard.
Am Donnerstag, 1. Dezember 2011, 15:01:08 schrieb Richard Guenther:
On Thu, 1 Dec 2011, Juergen Weigert wrote:
On Dec 01, 11 13:34:52 +0100, Adrian Schröter wrote:
I'm testing a new version of the format_spec_file service
It makes reviewing local changes impossible for packages which generate their spec files automatically from input files.
Well, our policy is to have a unique layout and we even are required to do so legal wise to some degree.
A new legal requirement is: We adopt the SPDX standard for license names. (E.g. where we had "GPL 2 or later" we now say "GPL-2.0+".) Such name changes need to propagate into your spec file input files. But how does that make reviewing local changes impossible?
I review .spec file changes that result from changing the .spec.in files and re-generating them. But doing so and using osc diff on the .spec file produces a huge unreadable diff now (mostly not due to the license change stuff).
How can I run the formatter on a selected file (in my case, the .spec.in file)?
/usr/lib/obs/service/format_spec_file.files/prepare_spec $in > $out
Richard. -- Adrian Schroeter SUSE Linux Products GmbH email: adrian@suse.de
-- To unsubscribe, e-mail: opensuse-packaging+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-packaging+owner@opensuse.org
On Thu, 1 Dec 2011, Adrian Schröter wrote:
Am Donnerstag, 1. Dezember 2011, 15:01:08 schrieb Richard Guenther:
On Thu, 1 Dec 2011, Juergen Weigert wrote:
On Dec 01, 11 13:34:52 +0100, Adrian Schröter wrote:
I'm testing a new version of the format_spec_file service
It makes reviewing local changes impossible for packages which generate their spec files automatically from input files.
Well, our policy is to have a unique layout and we even are required to do so legal wise to some degree.
A new legal requirement is: We adopt the SPDX standard for license names. (E.g. where we had "GPL 2 or later" we now say "GPL-2.0+".) Such name changes need to propagate into your spec file input files. But how does that make reviewing local changes impossible?
I review .spec file changes that result from changing the .spec.in files and re-generating them. But doing so and using osc diff on the .spec file produces a huge unreadable diff now (mostly not due to the license change stuff).
How can I run the formatter on a selected file (in my case, the .spec.in file)?
/usr/lib/obs/service/format_spec_file.files/prepare_spec $in > $out
How does that file magically appear or stay up-to-date? I guess
I have to play games to stay up-to-date with multiple versions in
the different repositories? (12.1 and Factory for now I guess)
Richard.
--
Richard Guenther
Am Donnerstag, 1. Dezember 2011, 15:11:40 schrieb Richard Guenther:
On Thu, 1 Dec 2011, Adrian Schröter wrote:
Am Donnerstag, 1. Dezember 2011, 15:01:08 schrieb Richard Guenther:
On Thu, 1 Dec 2011, Juergen Weigert wrote:
On Dec 01, 11 13:34:52 +0100, Adrian Schröter wrote:
> I'm testing a new version of the format_spec_file > service
It makes reviewing local changes impossible for packages which generate their spec files automatically from input files.
Well, our policy is to have a unique layout and we even are required to do so legal wise to some degree.
A new legal requirement is: We adopt the SPDX standard for license names. (E.g. where we had "GPL 2 or later" we now say "GPL-2.0+".) Such name changes need to propagate into your spec file input files. But how does that make reviewing local changes impossible?
I review .spec file changes that result from changing the .spec.in files and re-generating them. But doing so and using osc diff on the .spec file produces a huge unreadable diff now (mostly not due to the license change stuff).
How can I run the formatter on a selected file (in my case, the .spec.in file)?
/usr/lib/obs/service/format_spec_file.files/prepare_spec $in > $out
How does that file magically appear or stay up-to-date? I guess
Via maintenance update. We will do release the required set of services and also the new osc for maintenance work soon hopefully.
I have to play games to stay up-to-date with multiple versions in the different repositories? (12.1 and Factory for now I guess)
No, we should have only one standard regarding the sources. If there will be a difference in future, we will still have one service, but change modes via server side configurations (extra service parameter per project). Btw, just added an optional parameter to allow to specify the spec file name. You could use that in your source via adding a _service file with this content: <services> <service name="format_spec_file" mode="localonly"> <param name="specfile">YOUR_FILE.spec.in</param> <service> </services> So it will update your file automatically the next time you work on it. -- Adrian Schroeter SUSE Linux Products GmbH email: adrian@suse.de -- To unsubscribe, e-mail: opensuse-packaging+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-packaging+owner@opensuse.org
On Thu, 1 Dec 2011, Adrian Schröter wrote:
Am Donnerstag, 1. Dezember 2011, 15:11:40 schrieb Richard Guenther:
On Thu, 1 Dec 2011, Adrian Schröter wrote:
Am Donnerstag, 1. Dezember 2011, 15:01:08 schrieb Richard Guenther:
On Thu, 1 Dec 2011, Juergen Weigert wrote:
On Dec 01, 11 13:34:52 +0100, Adrian Schröter wrote:
> > I'm testing a new version of the format_spec_file > > service > > It makes reviewing local changes impossible for packages > which > generate their spec files automatically from input > files.
Well, our policy is to have a unique layout and we even are required to do so legal wise to some degree.
A new legal requirement is: We adopt the SPDX standard for license names. (E.g. where we had "GPL 2 or later" we now say "GPL-2.0+".) Such name changes need to propagate into your spec file input files. But how does that make reviewing local changes impossible?
I review .spec file changes that result from changing the .spec.in files and re-generating them. But doing so and using osc diff on the .spec file produces a huge unreadable diff now (mostly not due to the license change stuff).
How can I run the formatter on a selected file (in my case, the .spec.in file)?
/usr/lib/obs/service/format_spec_file.files/prepare_spec $in > $out
How does that file magically appear or stay up-to-date? I guess
Via maintenance update. We will do release the required set of services and also the new osc for maintenance work soon hopefully.
I have to play games to stay up-to-date with multiple versions in the different repositories? (12.1 and Factory for now I guess)
No, we should have only one standard regarding the sources.
If there will be a difference in future, we will still have one service, but change modes via server side configurations (extra service parameter per project).
Btw, just added an optional parameter to allow to specify the spec file name. You could use that in your source via adding a _service file with this content:
<services> <service name="format_spec_file" mode="localonly"> <param name="specfile">YOUR_FILE.spec.in</param> <service> </services>
So it will update your file automatically the next time you work on it.
Currently (obs-service-format_spec_file-0.2-39.1) it does
(on devel:gcc/gcc47/gcc.spec.in):
@@ -18,9 +18,6 @@
# norootforbuild
# icecream 0
-
-# Ada currently fails to build on a few platforms, enable it only
-# on those that work
# Note that AdaCore only supports %ix86, x86_64 and ia64
%ifarch %ix86 x86_64 ppc s390 ia64
%define build_ada !0%{?building_libjava:1}%{?building_libffi:1}
err? Why does it remove random comments?
-
-Name: gcc@base_ver@
-BuildRequires: bison flex gettext-devel glibc-devel-32bit mpfr-devel perl
texin
fo zlib-devel mpc-devel
+Name: gcc.spec.in
+BuildRequires: bison flex gettext-devel glibc-devel-32bit mpc-devel
mpfr-devel
perl texinfo zlib-devel
Sure changing Name like this is broken.
# PACKAGE-BEGIN
+
%package -n libgomp@base_ver@@variant@
License: GPLv3+ <
On 05.12.2011 14:21, Richard Guenther wrote:
Minus the vertical space issue, the Name: mangling and the toplevel comment removal then changes look good. But I obviously cannot apply a patch like the one produced.
Richard and me debugged this a bit more and we came up with a compromise :) Greetings, Stephan -- To unsubscribe, e-mail: opensuse-packaging+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-packaging+owner@opensuse.org
On 05.12.2011 15:33, Stephan Kulow wrote:
On 05.12.2011 14:21, Richard Guenther wrote:
Minus the vertical space issue, the Name: mangling and the toplevel comment removal then changes look good. But I obviously cannot apply a patch like the one produced.
Richard and me debugged this a bit more and we came up with a compromise :)
As I implemented all features wanted from replies, I would like to reformat all factory sources. What I would like to do: - release the current git version as update - reformat all factory packages that are unchanged branches in the devel package The main goal is to change the license to spdx format so we can enable the rpmlint error about non-spdx license format. What do you think? Greetings, Stephan -- To unsubscribe, e-mail: opensuse-packaging+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-packaging+owner@opensuse.org
On 12/05/2011 06:05 PM, Stephan Kulow wrote:
On 05.12.2011 15:33, Stephan Kulow wrote:
On 05.12.2011 14:21, Richard Guenther wrote:
Minus the vertical space issue, the Name: mangling and the toplevel comment removal then changes look good. But I obviously cannot apply a patch like the one produced.
Richard and me debugged this a bit more and we came up with a compromise :)
As I implemented all features wanted from replies, I would like to reformat all factory sources. What I would like to do:
- release the current git version as update - reformat all factory packages that are unchanged branches in the devel package
The main goal is to change the license to spdx format so we can enable the rpmlint error about non-spdx license format.
What do you think? Buy me the biggest coffee mug you can find and let go! -- Viele Grüße, Sascha
On 06.12.2011 09:36, Sascha Peilicke wrote:
On 12/05/2011 06:05 PM, Stephan Kulow wrote:
On 05.12.2011 15:33, Stephan Kulow wrote:
On 05.12.2011 14:21, Richard Guenther wrote:
Minus the vertical space issue, the Name: mangling and the toplevel comment removal then changes look good. But I obviously cannot apply a patch like the one produced.
Richard and me debugged this a bit more and we came up with a compromise :)
As I implemented all features wanted from replies, I would like to reformat all factory sources. What I would like to do:
- release the current git version as update - reformat all factory packages that are unchanged branches in the devel package
The main goal is to change the license to spdx format so we can enable the rpmlint error about non-spdx license format.
What do you think? Buy me the biggest coffee mug you can find and let go!
While you sure deserve a christmas present, I meant to change them directly in factory without SRs :) Greetings, Stephan -- To unsubscribe, e-mail: opensuse-packaging+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-packaging+owner@opensuse.org
On 12/06/2011 09:47 AM, Stephan Kulow wrote:
On 06.12.2011 09:36, Sascha Peilicke wrote:
On 12/05/2011 06:05 PM, Stephan Kulow wrote:
On 05.12.2011 15:33, Stephan Kulow wrote:
On 05.12.2011 14:21, Richard Guenther wrote:
Minus the vertical space issue, the Name: mangling and the toplevel comment removal then changes look good. But I obviously cannot apply a patch like the one produced.
Richard and me debugged this a bit more and we came up with a compromise :)
As I implemented all features wanted from replies, I would like to reformat all factory sources. What I would like to do:
- release the current git version as update - reformat all factory packages that are unchanged branches in the devel package
The main goal is to change the license to spdx format so we can enable the rpmlint error about non-spdx license format.
What do you think? Buy me the biggest coffee mug you can find and let go!
While you sure deserve a christmas present, I meant to change them directly in factory without SRs :) Even better! In the meantime, I'll re-use my standard-sized mug to get some... -- Viele Grüße, Sascha
Le lundi 05 décembre 2011, à 18:05 +0100, Stephan Kulow a écrit :
On 05.12.2011 15:33, Stephan Kulow wrote:
On 05.12.2011 14:21, Richard Guenther wrote:
Minus the vertical space issue, the Name: mangling and the toplevel comment removal then changes look good. But I obviously cannot apply a patch like the one produced.
Richard and me debugged this a bit more and we came up with a compromise :)
As I implemented all features wanted from replies, I would like to reformat all factory sources. What I would like to do:
- release the current git version as update - reformat all factory packages that are unchanged branches in the devel package
The main goal is to change the license to spdx format so we can enable the rpmlint error about non-spdx license format.
So would you restrict the change to the license, or run the whole thing? I'm fine with the former, less sure about the latter if we don't review the changes somewhere (although fixing 3000 packages and breaking by accident 2 obscure packages might be a fine compromise). Cheers, Vincent -- Les gens heureux ne sont pas pressés. -- To unsubscribe, e-mail: opensuse-packaging+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-packaging+owner@opensuse.org
On 06.12.2011 10:01, Vincent Untz wrote:
Le lundi 05 décembre 2011, à 18:05 +0100, Stephan Kulow a écrit :
On 05.12.2011 15:33, Stephan Kulow wrote:
On 05.12.2011 14:21, Richard Guenther wrote:
Minus the vertical space issue, the Name: mangling and the toplevel comment removal then changes look good. But I obviously cannot apply a patch like the one produced.
Richard and me debugged this a bit more and we came up with a compromise :)
As I implemented all features wanted from replies, I would like to reformat all factory sources. What I would like to do:
- release the current git version as update - reformat all factory packages that are unchanged branches in the devel package
The main goal is to change the license to spdx format so we can enable the rpmlint error about non-spdx license format.
So would you restrict the change to the license, or run the whole thing?
I'm fine with the former, less sure about the latter if we don't review the changes somewhere (although fixing 3000 packages and breaking by accident 2 obscure packages might be a fine compromise).
I can tell you from experience - if you review 1000 packages, 2 obscure packages will slip through anyway as your eyes create a filter for whitespace after ~50 packages :) Greetings, Stephan -- To unsubscribe, e-mail: opensuse-packaging+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-packaging+owner@opensuse.org
On Tue, 6 Dec 2011, Stephan Kulow wrote:
On 06.12.2011 10:01, Vincent Untz wrote:
Le lundi 05 décembre 2011, à 18:05 +0100, Stephan Kulow a écrit :
On 05.12.2011 15:33, Stephan Kulow wrote:
On 05.12.2011 14:21, Richard Guenther wrote:
Minus the vertical space issue, the Name: mangling and the toplevel comment removal then changes look good. But I obviously cannot apply a patch like the one produced.
Richard and me debugged this a bit more and we came up with a compromise :)
As I implemented all features wanted from replies, I would like to reformat all factory sources. What I would like to do:
- release the current git version as update - reformat all factory packages that are unchanged branches in the devel package
The main goal is to change the license to spdx format so we can enable the rpmlint error about non-spdx license format.
So would you restrict the change to the license, or run the whole thing?
I'm fine with the former, less sure about the latter if we don't review the changes somewhere (although fixing 3000 packages and breaking by accident 2 obscure packages might be a fine compromise).
I can tell you from experience - if you review 1000 packages, 2 obscure packages will slip through anyway as your eyes create a filter for whitespace after ~50 packages :)
Which is why devel project owners should do the review ;)
Richard.
--
Richard Guenther
On 06.12.2011 10:49, Richard Guenther wrote:
I can tell you from experience - if you review 1000 packages, 2 obscure packages will slip through anyway as your eyes create a filter for whitespace after ~50 packages :)
Which is why devel project owners should do the review ;)
Oh, there I have made worse experience ;( But I'm open for blocking specific devel projects. So the list of packages to autoformat would be then: - license can be autoconverted (otherwise legal needs to review anyway) - devel project has unmodified branch - devel project is not in black list Greetings, Stephan -- To unsubscribe, e-mail: opensuse-packaging+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-packaging+owner@opensuse.org
On 06.12.2011 10:59, Stephan Kulow wrote:
On 06.12.2011 10:49, Richard Guenther wrote:
I can tell you from experience - if you review 1000 packages, 2 obscure packages will slip through anyway as your eyes create a filter for whitespace after ~50 packages :)
Which is why devel project owners should do the review ;)
Oh, there I have made worse experience ;(
But I'm open for blocking specific devel projects. So the list of packages to autoformat would be then:
- license can be autoconverted (otherwise legal needs to review anyway) - devel project has unmodified branch - devel project is not in black list
I think I changed my mind - I'll only run a stripped version to change the License field. As there is nothing to "review" for a 1:1 change I would also leave out the blacklist part. Greetings, Stephan -- To unsubscribe, e-mail: opensuse-packaging+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-packaging+owner@opensuse.org
Le mardi 06 décembre 2011, à 14:23 +0100, Stephan Kulow a écrit :
On 06.12.2011 10:59, Stephan Kulow wrote:
On 06.12.2011 10:49, Richard Guenther wrote:
I can tell you from experience - if you review 1000 packages, 2 obscure packages will slip through anyway as your eyes create a filter for whitespace after ~50 packages :)
Which is why devel project owners should do the review ;)
Oh, there I have made worse experience ;(
But I'm open for blocking specific devel projects. So the list of packages to autoformat would be then:
- license can be autoconverted (otherwise legal needs to review anyway) - devel project has unmodified branch - devel project is not in black list
I think I changed my mind - I'll only run a stripped version to change the License field. As there is nothing to "review" for a 1:1 change I would also leave out the blacklist part.
Sounds good. Maybe keep the list of packages that won't be touched (devel project has unmodified branch) so we can make sure they'll get fixed eventually at a later point? Vincent -- Les gens heureux ne sont pas pressés. -- To unsubscribe, e-mail: opensuse-packaging+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-packaging+owner@opensuse.org
Am Dienstag, 6. Dezember 2011, 14:25:42 schrieb Vincent Untz:
Sounds good.
Maybe keep the list of packages that won't be touched (devel project has unmodified branch) so we can make sure they'll get fixed eventually at a later point?
I have 1608 packages left after commiting > 3200 packages. I'm not yet sure what left to do with them :) Greetings, Stephan -- Sent from openSUSE -- To unsubscribe, e-mail: opensuse-packaging+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-packaging+owner@opensuse.org
I have prepare a complete update for this stack. This includes also an osc 0.133 release candidate. Please test these packages: http://download.opensuse.org/repositories/home:/adrianSuSE:/branches:/OBS_Ma... This will also obsolete the old osc-source_validator, which means it won't force the openSUSE rules anymore on sources for non-openSUSE targets. All stuff which is needed for current Factory and upcomming openSUSE Maintenance work is part of these packages. thanks adrian Am Dienstag, 6. Dezember 2011, 10:01:47 schrieb Vincent Untz:
Le lundi 05 décembre 2011, à 18:05 +0100, Stephan Kulow a écrit :
On 05.12.2011 15:33, Stephan Kulow wrote:
On 05.12.2011 14:21, Richard Guenther wrote:
Minus the vertical space issue, the Name: mangling and the toplevel comment removal then changes look good. But I obviously cannot apply a patch like the one produced.
Richard and me debugged this a bit more and we came up with a compromise :)> As I implemented all features wanted from replies, I would like to
reformat all factory sources. What I would like to do: - release the current git version as update - reformat all factory packages that are unchanged branches in the
devel package
The main goal is to change the license to spdx format so we can enable the rpmlint error about non-spdx license format.
So would you restrict the change to the license, or run the whole thing?
I'm fine with the former, less sure about the latter if we don't review the changes somewhere (although fixing 3000 packages and breaking by accident 2 obscure packages might be a fine compromise).
Cheers,
Vincent -- Adrian Schroeter SUSE Linux Products GmbH email: adrian@suse.de
-- To unsubscribe, e-mail: opensuse-packaging+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-packaging+owner@opensuse.org
Am Donnerstag, 1. Dezember 2011, 12:37:12 schrieb Richard Guenther:
On Thu, 1 Dec 2011, Stephan Kulow wrote:
Hi,
I'm testing a new version of the format_spec_file service (you can find the sources on github's openSUSE project) and this results in submit requests of mine to:
- remove #norootforbuild - remove duplicated group and license from sub packages - patch license field to apply to spdx.org (where I can,
this needs to improve and is in discussion with legal how to handle the corner cases)
- split buildrequires in single lines (I'll try to keep
two adjacent buildrequire lines sorted).
That should be what I changed, but just so you don't get afraid :)
Umm....
How are "duplicated license" detected?
And why do we add more to this service rather than removing it? Because people submit all kind of spec files and I value a rather standard format of spec files.
Or, make running it optional (how do I turn this off for a devel project or a specific package for example?) It is optional. osc ci --skip-local-service-run
It makes reviewing local changes impossible for packages which generate their spec files automatically from input files. You're aware that you can run the service locally as part of the generation?
Greetings, Stephan -- Sent from openSUSE -- To unsubscribe, e-mail: opensuse-packaging+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-packaging+owner@opensuse.org
Am Donnerstag, 1. Dezember 2011, 12:37:12 schrieb Richard Guenther:
How are "duplicated license" detected?
If they are the same in source package and sub package. Greetings, Stephan -- Sent from openSUSE -- To unsubscribe, e-mail: opensuse-packaging+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-packaging+owner@opensuse.org
On Thu, 1 Dec 2011, Stephan Kulow wrote:
Am Donnerstag, 1. Dezember 2011, 12:37:12 schrieb Richard Guenther:
How are "duplicated license" detected?
If they are the same in source package and sub package.
Hmm. But I prefer to see the explicit license in every sub-package,
because I explicitely checked it. With all the different licenses
in the GCC sub-packages for example it becomes hard to track what
licenses to change otherwise.
Can we remove those duplicated licenses only if _all_ sub-packages
have the same license please?
Thanks,
Richard.
--
Richard Guenther
On Dec 02, 11 10:56:53 +0100, Richard Guenther wrote:
On Thu, 1 Dec 2011, Stephan Kulow wrote:
Am Donnerstag, 1. Dezember 2011, 12:37:12 schrieb Richard Guenther:
How are "duplicated license" detected?
If they are the same in source package and sub package.
Hmm. But I prefer to see the explicit license in every sub-package, because I explicitely checked it. With all the different licenses in the GCC sub-packages for example it becomes hard to track what licenses to change otherwise.
Can we remove those duplicated licenses only if _all_ sub-packages have the same license please?
A more helpful rule would be: - either all sub-packages implicitly inherit their license from the main package, or - all subpackages explicitly spell out their license. This avoids the doubt weather a license string of some sub package was forgotten or intentionally implicit. Coolos new logic appears to actually create more of this doubt, if I get it right. cheers, JW- -- o \ Juergen Weigert paint it green! __/ _=======.=======_ <V> | jw@suse.de back to ascii! __/ _---|____________\/ \ | 0911 74053-508 __/ (____/ /\ (/) | _____________________________/ _/ \_ vim:set sw=2 wm=8 SUSE LINUX Products GmbH, GF: Jeff Hawn, J.Guild, F.Imendoerffer, HRB 16746 (AG Nuernberg), Maxfeldstrasse 5, 90409 Nuernberg, Germany SuSE. Supporting Linux since 1992. -- To unsubscribe, e-mail: opensuse-packaging+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-packaging+owner@opensuse.org
On Fri, 2 Dec 2011, Juergen Weigert wrote:
On Dec 02, 11 10:56:53 +0100, Richard Guenther wrote:
On Thu, 1 Dec 2011, Stephan Kulow wrote:
Am Donnerstag, 1. Dezember 2011, 12:37:12 schrieb Richard Guenther:
How are "duplicated license" detected?
If they are the same in source package and sub package.
Hmm. But I prefer to see the explicit license in every sub-package, because I explicitely checked it. With all the different licenses in the GCC sub-packages for example it becomes hard to track what licenses to change otherwise.
Can we remove those duplicated licenses only if _all_ sub-packages have the same license please?
A more helpful rule would be: - either all sub-packages implicitly inherit their license from the main package, or - all subpackages explicitly spell out their license.
This avoids the doubt weather a license string of some sub package was forgotten or intentionally implicit. Coolos new logic appears to actually create more of this doubt, if I get it right.
Yes, that's a good suggestion as well.
Richard.
--
Richard Guenther
On Fri, 2 Dec 2011, Richard Guenther wrote:
On Fri, 2 Dec 2011, Juergen Weigert wrote:
On Dec 02, 11 10:56:53 +0100, Richard Guenther wrote:
On Thu, 1 Dec 2011, Stephan Kulow wrote:
Am Donnerstag, 1. Dezember 2011, 12:37:12 schrieb Richard Guenther:
How are "duplicated license" detected?
If they are the same in source package and sub package.
Hmm. But I prefer to see the explicit license in every sub-package, because I explicitely checked it. With all the different licenses in the GCC sub-packages for example it becomes hard to track what licenses to change otherwise.
Can we remove those duplicated licenses only if _all_ sub-packages have the same license please?
A more helpful rule would be: - either all sub-packages implicitly inherit their license from the main package, or - all subpackages explicitly spell out their license.
This avoids the doubt weather a license string of some sub package was forgotten or intentionally implicit. Coolos new logic appears to actually create more of this doubt, if I get it right.
Yes, that's a good suggestion as well.
Btw, a general rule to follow should be that the formatter should
only do transformations that a subsequent changed formatter can undo.
Thus, throwing away information isn't ok - like in this case.
Richard.
--
Richard Guenther
This avoids the doubt weather a license string of some sub package was forgotten or intentionally implicit. Coolos new logic appears to actually create more of this doubt, if I get it right.
Yes, that's a good suggestion as well.
Btw, a general rule to follow should be that the formatter should only do transformations that a subsequent changed formatter can undo. Thus, throwing away information isn't ok - like in this case. As I only remove duplicated information that can be readded without a
Am Freitag, 2. Dezember 2011, 11:47:31 schrieb Richard Guenther: problem I don't see a problem. Greetings, Sephan -- Sent from openSUSE -- To unsubscribe, e-mail: opensuse-packaging+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-packaging+owner@opensuse.org
On Fri, 2 Dec 2011, Stephan Kulow wrote:
Am Freitag, 2. Dezember 2011, 11:47:31 schrieb Richard Guenther:
This avoids the doubt weather a license string of some sub package was forgotten or intentionally implicit. Coolos new logic appears to actually create more of this doubt, if I get it right.
Yes, that's a good suggestion as well.
Btw, a general rule to follow should be that the formatter should only do transformations that a subsequent changed formatter can undo. Thus, throwing away information isn't ok - like in this case. As I only remove duplicated information that can be readded without a problem I don't see a problem.
You don't distinguish between a deliberate duplicate (same) license
and an errorneously omitted (different) one. If you re-add the
"duplicates" you loose the "errorneously omitted different" license state.
Richard.
--
Richard Guenther
Am Freitag, 2. Dezember 2011, 13:40:23 schrieb Richard Guenther:
On Fri, 2 Dec 2011, Stephan Kulow wrote:
Am Freitag, 2. Dezember 2011, 11:47:31 schrieb Richard Guenther:
This avoids the doubt weather a license string of some sub package was forgotten or intentionally implicit. Coolos new logic appears to actually create more of this doubt, if I get it right.
Yes, that's a good suggestion as well.
Btw, a general rule to follow should be that the formatter should only do transformations that a subsequent changed formatter can undo. Thus, throwing away information isn't ok - like in this case.
As I only remove duplicated information that can be readded without a problem I don't see a problem.
You don't distinguish between a deliberate duplicate (same) license and an errorneously omitted (different) one. If you re-add the "duplicates" you loose the "errorneously omitted different" license state.
The old autobuild checkin formater added the main license as duplicate all around, so this was already the case. So Jürgen's policy is better: only if one subpackage has a different license, we require the main license in all subpackages with that license too. Greetings, Stephan -- Sent from openSUSE -- To unsubscribe, e-mail: opensuse-packaging+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-packaging+owner@opensuse.org
On Fri, 2 Dec 2011, Stephan Kulow wrote:
Am Freitag, 2. Dezember 2011, 13:40:23 schrieb Richard Guenther:
On Fri, 2 Dec 2011, Stephan Kulow wrote:
Am Freitag, 2. Dezember 2011, 11:47:31 schrieb Richard Guenther:
This avoids the doubt weather a license string of some sub package was forgotten or intentionally implicit. Coolos new logic appears to actually create more of this doubt, if I get it right.
Yes, that's a good suggestion as well.
Btw, a general rule to follow should be that the formatter should only do transformations that a subsequent changed formatter can undo. Thus, throwing away information isn't ok - like in this case.
As I only remove duplicated information that can be readded without a problem I don't see a problem.
You don't distinguish between a deliberate duplicate (same) license and an errorneously omitted (different) one. If you re-add the "duplicates" you loose the "errorneously omitted different" license state.
The old autobuild checkin formater added the main license as duplicate all around, so this was already the case.
So Jürgen's policy is better: only if one subpackage has a different license, we require the main license in all subpackages with that license too.
Yes, I agree.
Richard.
--
Richard Guenther
Am Freitag, 2. Dezember 2011, 10:56:53 schrieb Richard Guenther:
On Thu, 1 Dec 2011, Stephan Kulow wrote:
Am Donnerstag, 1. Dezember 2011, 12:37:12 schrieb Richard Guenther:
How are "duplicated license" detected?
If they are the same in source package and sub package.
Hmm. But I prefer to see the explicit license in every sub-package, because I explicitely checked it. With all the different licenses in the GCC sub-packages for example it becomes hard to track what licenses to change otherwise.
Can we remove those duplicated licenses only if _all_ sub-packages have the same license please? Hmm, convinced. I'll come up with a patch
Gretings, Stephan -- Sent from openSUSE -- To unsubscribe, e-mail: opensuse-packaging+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-packaging+owner@opensuse.org
Stephan Kulow
- remove duplicated group and license from sub packages - patch license field to apply to spdx.org (where I can, this needs to improve and is in discussion with legal how to handle the corner cases)
If exists, please fix this info in the "attributes" file. -- Karl Eichwalder SUSE LINUX Products GmbH R&D / Documentation Maxfeldstraße 5 90409 Nürnberg, Germany GF: Jeff Hawn, Jennifer Guild, Felix Imendörffer, HRB 16746 (AG Nürnberg) -- To unsubscribe, e-mail: opensuse-packaging+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-packaging+owner@opensuse.org
Am Donnerstag, 1. Dezember 2011, 11:38:45 schrieb Stephan Kulow:
Hi,
I'm testing a new version of the format_spec_file service (you can find the sources on github's openSUSE project) and this results in submit requests of mine to:
- remove #norootforbuild - remove duplicated group and license from sub packages
The remove Group: tags do lead to spec files which are not buildable with rpms like existing on SLES 11 and before. Since I really like to keep my stuff (OBS packages) also working for this old (well, SLE 11 is actually still the most up2date enterprise distro of us) rpms, I like to request to drop the Group removeing for now. Or to add %if %suse_version around it so it is only active on old distro. Otherwise people will find workarounds to not use the formater at all anymore ... bye adrian -- Adrian Schroeter SUSE Linux Products GmbH email: adrian@suse.de -- To unsubscribe, e-mail: opensuse-packaging+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-packaging+owner@opensuse.org
On 16.12.2011 11:14, Adrian Schröter wrote:
Since I really like to keep my stuff (OBS packages) also working for this old (well, SLE 11 is actually still the most up2date enterprise distro of us) rpms, I like to request to drop the Group removeing for now.
Or to add %if %suse_version around it so it is only active on old distro. BAH, that's the worst option of all.
Otherwise people will find workarounds to not use the formater at all anymore ...
I wonder if it wouldn't make more sense to have the build script run a spec file patcher - either distribution specific or in general - after all the duplicated group does not really harm in the spec file. But with this logic we will keep support for old rpms in our factory spec files forever. So this spec file patcher could also add a buildroot or even a default %clean section - right before building without us having to carry those forever in the sources. Greetings, Stephan -- To unsubscribe, e-mail: opensuse-packaging+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-packaging+owner@opensuse.org
On Friday 16 December 2011, Stephan Kulow wrote:
On 16.12.2011 11:14, Adrian Schröter wrote:
Since I really like to keep my stuff (OBS packages) also working for this old (well, SLE 11 is actually still the most up2date enterprise distro of us) rpms, I like to request to drop the Group removeing for now.
Or to add %if %suse_version around it so it is only active on old distro.
BAH, that's the worst option of all.
Otherwise people will find workarounds to not use the formater at all anymore ...
BTW how does that service works exactly? For example this one in server:http/libev https://build.opensuse.org/package/rdiff?linkrev=base&package=libev&project=server%3Ahttp&rev=7 Was it committed manually or automatically? Will it happens again after now being fixed again in r11?
I wonder if it wouldn't make more sense to have the build script run a spec file patcher - either distribution specific or in general - after all the duplicated group does not really harm in the spec file.
But with this logic we will keep support for old rpms in our factory spec files forever. So this spec file patcher could also add a buildroot or even a default %clean section - right before building without us having to carry those forever in the sources.
The idea looks good but IMO it would be quite confusing for spare time packagers if such patcher applies hidden magic differently for different distros. I think generally any code formatters are nice but should be only used seldom as single shots and not automatically again and again. For me a clean commit history with mostly significant diffs is more important than having every white space corrected but endless confusing commits even without or with nonsense commit messages like the libev example above: https://build.opensuse.org/package/revisions?package=libev&project=server%3Ahttp BTW I'd like some mechanism to be noticed about such breakage at least. If a commit breaks the build for a target which worked before then the one who did that commit should get an email about requiring him to fix that again. If he does not fix that within one day (or if he does not confirm somehow that that breakage was wanted) then his patch should get reverted automatically. cu, Rudi -- To unsubscribe, e-mail: opensuse-packaging+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-packaging+owner@opensuse.org
On 16.12.2011 13:50, Ruediger Meier wrote:
On Friday 16 December 2011, Stephan Kulow wrote:
On 16.12.2011 11:14, Adrian Schröter wrote:
Since I really like to keep my stuff (OBS packages) also working for this old (well, SLE 11 is actually still the most up2date enterprise distro of us) rpms, I like to request to drop the Group removeing for now.
Or to add %if %suse_version around it so it is only active on old distro.
BAH, that's the worst option of all.
Otherwise people will find workarounds to not use the formater at all anymore ...
BTW how does that service works exactly? For example this one in server:http/libev https://build.opensuse.org/package/rdiff?linkrev=base&package=libev&project=server%3Ahttp&rev=7
Was it committed manually or automatically? Will it happens again after now being fixed again in r11?
There is nothing automatic. But I have a script to sync up factory packages in their devel project. And if I commit, my osc runs the service.
I wonder if it wouldn't make more sense to have the build script run a spec file patcher - either distribution specific or in general - after all the duplicated group does not really harm in the spec file.
But with this logic we will keep support for old rpms in our factory spec files forever. So this spec file patcher could also add a buildroot or even a default %clean section - right before building without us having to carry those forever in the sources.
The idea looks good but IMO it would be quite confusing for spare time packagers if such patcher applies hidden magic differently for different distros.
I think generally any code formatters are nice but should be only used seldom as single shots and not automatically again and again. For me a clean commit history with mostly significant diffs is more important than having every white space corrected but endless confusing
... which is the reason we only format on commit. Greetings, Stephan -- To unsubscribe, e-mail: opensuse-packaging+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-packaging+owner@opensuse.org
Am Freitag, 16. Dezember 2011, 14:16:47 schrieb Stephan Kulow:
On 16.12.2011 13:50, Ruediger Meier wrote:
On Friday 16 December 2011, Stephan Kulow wrote: ...
I wonder if it wouldn't make more sense to have the build script run a spec file patcher - either distribution specific or in general - after all the duplicated group does not really harm in the spec file.
But with this logic we will keep support for old rpms in our factory spec files forever. So this spec file patcher could also add a buildroot or even a default %clean section - right before building without us having to carry those forever in the sources.
The idea looks good but IMO it would be quite confusing for spare time packagers if such patcher applies hidden magic differently for different distros.
I think generally any code formatters are nice but should be only used seldom as single shots and not automatically again and again. For me a clean commit history with mostly significant diffs is more important than having every white space corrected but endless confusing
... which is the reason we only format on commit.
and on "osc build", because it may affect the build. You can run it manually also with "osc service run" when you want to. -- Adrian Schroeter SUSE Linux Products GmbH email: adrian@suse.de -- To unsubscribe, e-mail: opensuse-packaging+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-packaging+owner@opensuse.org
On Friday 16 December 2011, Stephan Kulow wrote:
On 16.12.2011 13:50, Ruediger Meier wrote:
On Friday 16 December 2011, Stephan Kulow wrote:
On 16.12.2011 11:14, Adrian Schröter wrote:
Since I really like to keep my stuff (OBS packages) also working for this old (well, SLE 11 is actually still the most up2date enterprise distro of us) rpms, I like to request to drop the Group removeing for now.
Or to add %if %suse_version around it so it is only active on old distro.
BAH, that's the worst option of all.
Otherwise people will find workarounds to not use the formater at all anymore ...
BTW how does that service works exactly? For example this one in server:http/libev https://build.opensuse.org/package/rdiff?linkrev=base&package=libev &project=server%3Ahttp&rev=7
Was it committed manually or automatically? Will it happens again after now being fixed again in r11?
There is nothing automatic. But I have a script to sync up factory packages in their devel project. And if I commit, my osc runs the service.
However would be nice to check whether it not breaks that devel projects before syncing. I still don't undertand why 5 of the 9 commits above have none or wrong commit messages while nothing important was changed except breaking SLE builds.
I think generally any code formatters are nice but should be only used seldom as single shots and not automatically again and again. For me a clean commit history with mostly significant diffs is more important than having every white space corrected but endless confusing
... which is the reason we only format on commit.
You mean formatting changes will be mixed with real changes when committing them to make the diff even harder to read? cu, Rudi -- To unsubscribe, e-mail: opensuse-packaging+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-packaging+owner@opensuse.org
On Fri, 16 Dec 2011, Stephan Kulow wrote:
On 16.12.2011 11:14, Adrian Schröter wrote:
Since I really like to keep my stuff (OBS packages) also working for this old (well, SLE 11 is actually still the most up2date enterprise distro of us) rpms, I like to request to drop the Group removeing for now.
Or to add %if %suse_version around it so it is only active on old distro. BAH, that's the worst option of all.
Otherwise people will find workarounds to not use the formater at all anymore ...
I wonder if it wouldn't make more sense to have the build script run a spec file patcher - either distribution specific or in general - after all the duplicated group does not really harm in the spec file.
But with this logic we will keep support for old rpms in our factory spec files forever. So this spec file patcher could also add a buildroot or even a default %clean section - right before building without us having to carry those forever in the sources.
That sounds backward - the master copy will still have those "old"
stuff then. Nobody looks at the packaged srpms.
Richard.
--
Richard Guenther
On Friday 16 December 2011, Richard Guenther wrote:
On Fri, 16 Dec 2011, Stephan Kulow wrote:
On 16.12.2011 11:14, Adrian Schröter wrote:
Since I really like to keep my stuff (OBS packages) also working for this old (well, SLE 11 is actually still the most up2date enterprise distro of us) rpms, I like to request to drop the Group removeing for now.
Or to add %if %suse_version around it so it is only active on old distro.
BAH, that's the worst option of all.
Otherwise people will find workarounds to not use the formater at all anymore ...
I wonder if it wouldn't make more sense to have the build script run a spec file patcher - either distribution specific or in general - after all the duplicated group does not really harm in the spec file.
But with this logic we will keep support for old rpms in our factory spec files forever. So this spec file patcher could also add a buildroot or even a default %clean section - right before building without us having to carry those forever in the sources.
That sounds backward - the master copy will still have those "old" stuff then.
I've understood the master copy is the cleaned factory one but buildroot and stuff will be added on the fly before building on distros where it's needed.
Nobody looks at the packaged srpms.
SRPMs may still be usefull for people who not use OBS but want to recompile packages against their local customized systems. cu, Rudi -- To unsubscribe, e-mail: opensuse-packaging+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-packaging+owner@opensuse.org
participants (8)
-
Adrian Schröter -
Juergen Weigert -
Karl Eichwalder -
Richard Guenther -
Ruediger Meier -
Sascha Peilicke -
Stephan Kulow -
Vincent Untz