As can be seen in current libpng16 submission (sr#436546), comment is moved somewhere else, which is not acceptable (in my opinion, comments should not be moved at all). Unfortunately I cannot submit correct version, as format_spec_file prevents it.
`
-Group: System/Libraries

bug437293

+Group: System/Libraries
%ifarch ppc64
Obsoletes: libpng-64bit
%endif
`

obs-service-format_spec_file-20191114-1.3.noarch illegally eats part of the package description.

» cat test.spec
%description
Foo does bar. Many features!
Provides:
        * zlib support

» /usr/lib/obs/service/format_spec_file
Use of uninitialized value $oldspec[-1] in pattern match (m//) at /usr/lib/obs/service/format_spec_file.files/prepare_spec line 109.

» cat test.spec
#
# spec file for package 
#
# Copyright (c) 2020 SUSE LLC
#
# All modifications and additions to the file contributed by third parties
# remain the property of their copyright owners, unless otherwise agreed
# upon. The license for this file, and modifications and additions to the
# file, is the same license as for the pristine package itself (unless the
# license for the pristine package is not an Open Source License, in which
# case the license is the MIT License). An "Open Source License" is a
# license that conforms to the Open Source Definition (Version 1.9)
# published by the Open Source Initiative.

# Please submit bugfixes or comments via https://bugs.opensuse.org/
#


%description
Foo does bar. Many features!
        * zlib support

%changelog

I have tried running fetch-licenses.sh but it keeps erroring out with:

DUPS Bitstream-Vera
mplus

I think that is because SPDX recently added new identifiers: Bitstream-Vera and mplus which conflict with SUSE's own: SUSE-Bitstream-Vera and SUSE-mplus. I don't know what is the proper procedure to get this conflict resolved.

I personally want the list of licenses to be updated so that I can use the newly added SPDX Arphic-1999 rather than the provisional SUSE-Arphic which has been used for font packages such as: babelstone-han-fonts.

After the recent change, running osc service localrun format_spec_file breaks gcc11.spec file in the following manner:

Before:

...
Conflicts: %selfconflict libgnarl-11
Provides: libgnat-11 = %{version}-%{release}
Conflicts: %selfconflict libgnat-11
...

after:

...
Conflicts:      %selfconflict
Conflicts:      libgnarl-11
Provides:       libgnat-11 = %{version}-%{release}
Conflicts:      %selfconflict
Conflicts:      libgnat-11
...

Just for context, the macro is defined as:

%if %{suse_version} >= 1220
%define selfconflict() %1
%else
%define selfconflict() otherproviders(%1)
%endif

According to SPDX specification, I can aggegrate valid licenses using 'AND' and 'OR'

format_spec_file though does complain when one uses 'AND' (which is according to the spec) - but it does not complain with 'and' (which would be outside the spec)

osc service lr format_spec_file
Unknown license 'LGPL-2.1 AND LGPL-2.1+'

I recently hitted issue where my change with BSD-4-clause was accepted into factory. While, the cavil threw an error that this is not recognized license by SPDX.

Seems like we should be more strict at checking as far as case sensitivity for licenses go. I would appreciate if the AND/OR/WITH would still be case insensitive.

When I tried to build 42.3's intltool package locally for a 42.3 maintenance update using osc build
it always failed with
intltool.src: E: invalid-license (Badness: 100000) GPL-2.0-or-later

It only worked with osc revert *.spec ; osc build --no-service

While packaging I noticed the following license was used:

Apache-2.0 WITH LLVM-exception OR Apache-2.0 OR MIT

Rpmlint does not have knowledge of the LLVM-exception. Could it please be added to exceptions?

Here is the original spec file (snippet) in a formatting as intended by its author:

...
%if %{with man}
BuildRequires:  doxygen
BuildRequires:  graphviz
%endif
# /SECTION

%description
LAPACK provides routines for solving systems of simultaneous linear
equations,...(snip)

# LAPACK
%package     -n liblapack%{so_ver}
Summary:        Linear Algebra PACKage: Shared Library
Requires(post): update-alternatives
Requires(postun): update-alternatives

%description -n liblapack%{so_ver}
LAPACK provides routines for solving systems of simultaneous linear
equations, ... (snip)

This package provides the shared library for LAPACK.

%package -n %{pname}-devel
Summary:       ...

... (some more package definitions)

# BLAS
%package     -n libblas%{so_ver}
Summary:        Basic Linear Algebra Subprograms: Shared Library
Requires(post): update-alternatives
Requires(postun): update-alternatives

%description -n libblas%{so_ver}
BLAS (Basic Linear Algebra Subprograms) is a standard library for
numerical algebra... (snip)

This package provides the shared library for BLAS.

%package     -n blas-devel
Summary:        Basic Linear Algebra Subprograms: headers and sources for development
Requires:       libblas%{so_ver} = %{version}
...

Here is what happens after format_spec_file has a first go at it:

~> /usr/lib/obs/service/format_spec_file.files/prepare_spec lapack.spec | diff -u lapack.spec -

--- lapack.spec	2024-05-06 20:14:16.230600369 +0530
+++ -	2024-05-06 20:15:58.956174187 +0530
@@ -68,6 +68,7 @@
 both single and double precision.
 
 # LAPACK
+
 %package     -n liblapack%{so_ver}
 Summary:        Linear Algebra PACKage: Shared Library
 Requires(post): update-alternatives
@@ -122,6 +123,7 @@
 This package provides the static library for LAPACK.
 
 # BLAS
+
 %package     -n libblas%{so_ver}
 Summary:        Basic Linear Algebra Subprograms: Shared Library
 Requires(post): update-alternatives
...

OK, fine let us accept it, not too bad. On next commit, format_spec_file has a go at it again:

--- lapack.spec	2024-05-06 20:16:21.448316936 +0530
+++ -	2024-05-06 20:16:51.197976356 +0530
@@ -67,8 +67,8 @@
 similar functionality is provided for real and complex matrices, in
 both single and double precision.
 
-# LAPACK
 
+# LAPACK
 %package     -n liblapack%{so_ver}
 Summary:        Linear Algebra PACKage: Shared Library
 Requires(post): update-alternatives
@@ -122,8 +122,8 @@
 
 This package provides the static library for LAPACK.
 
-# BLAS
 
+# BLAS
 %package     -n libblas%{so_ver}
 Summary:        Basic Linear Algebra Subprograms: Shared Library
 Requires(post): update-alternatives
...

Weird, but let us accept it. Upon next commit it has a go again:

--- lapack.spec	2024-05-06 20:16:55.881938971 +0530
+++ -	2024-05-06 20:16:59.195134832 +0530
@@ -69,6 +69,7 @@
 
 
 # LAPACK
+
 %package     -n liblapack%{so_ver}
 Summary:        Linear Algebra PACKage: Shared Library
 Requires(post): update-alternatives
@@ -124,6 +125,7 @@
 
 
 # BLAS
+
 %package     -n libblas%{so_ver}
 Summary:        Basic Linear Algebra Subprograms: Shared Library
 Requires(post): update-alternatives
...

And so on ad infinitum.

Eventually, after a few osc ci runs which apparently enforces format_spec_file automatically, I have Texas sized blank spaces above all of these comments, which is undesirable and will need manual intervention to fix and commit using --noservice. I don't understand why the formatter keeps "fixing" its own blank lines before/after comments.

Observed:

» cat qt6-coap.spec
Name:           qt6-coap%{?pkg_suffix}
» /usr/lib/obs/service/format_spec_file.files/prepare_spec qt6-coap.spec | head -n2
#
# spec file for package qt6

Expected:

# spec file for package qt6-coap

Version: obs-service-format_spec_file-20191114-1.3.noarch (openSUSE Tumbleweed du jour)

rpm 4.13 (which found its way to Tumbleweed recently) has introduced a new feature: boolean dependencies.
But format_spec_file (and rpm-software-management/spec-cleaner#174) messes them up, turning

Requires: (foo and bar)

into

BuildRequires:  (foo
BuildRequires:  and
BuildRequires:  bar)

Hi,

Here is an output as generated by format_spec_file

mchandras@helix->~/src/obs/home:markoschandras:network/openvswitch $ /usr/lib/obs/service/format_spec_file --outdir foobar/  --specfile openvswitch.spec 
mchandras@helix->~/src/obs/home:markoschandras:network/openvswitch $ diff -Naur openvswitch.spec  foobar/openvswitch.spec 
--- openvswitch.spec    2016-09-12 14:43:25.189247552 +0100
+++ foobar/openvswitch.spec     2016-09-12 14:44:14.313817594 +0100
@@ -29,11 +29,11 @@
 Version:        2.5.0
 Release:        0
 Summary:        An open source, production quality, multilayer virtual switch
+License:        Apache-2.0 and LGPL-2.1 and SISSL
+Group:          Productivity/Networking/System
 # All code is Apache-2.0 except
 # - lib/sflow* which is SISSL
 # - utilities/bugtool which is LGPL-2.1
-License:        Apache-2.0 and LGPL-2.1 and SISSL
-Group:          Productivity/Networking/System
 Url:            http://openvswitch.org/
 Source0:        http://openvswitch.org/releases/openvswitch-%{version}.tar.gz
 Source1:        preamble

For me it makes no sense to mess around with the comment. That comment itself refers to the License tag so it should stay where I put it.

We currently use a SUSE- prefix (like SUSE-BSD-3-Clause-with-non-nuclear-addition) for our own additions, but according to the SPDX spec it should be LicenseRef- (like LicenseRef-BSD-3-Clause-with-non-nuclear-addition).

osc claims to need this package (using a trusty client):

$ osc commit
*** Error: Package obs-service-format_spec_file is required for this operation

But this package does not exists in official repos (also not for other versions).

So, let's use another source: OBS itself!

https://build.opensuse.org/package/show/openSUSE:Tools/obs-service-format_spec_file

The publish flag is true, but on the download page, it's not available, same for soo: https://software.opensuse.org/package/obs-service-format_spec_file?search_term=obs-service-format_spec_file

So where to get this package? (Except building myself?)

format_spec strips # needspubkeyforbuild from spec files... openSUSE/open-build-service#11836

Correct copyright string for SUSE is SUSE LLC which can be confirmed by visiting https://www.suse.com/c/news/suse-secures-openchain-certification-meeting-the-new-industry-benchmark-for-a-simplified-open-source-experience/

Likely also a recent change. Due to it one can see in: devel:gcc/gcc11 unmerged Copyright in:

$ grep 'Copyright.*' cross-sparc-gcc11.spec
# Copyright (c) 2021 SUSE LLC
# Copyright (c) 2005 SUSE Linux AG, Nuernberg, Germany.

I'm pretty sure these used to be merge correctly.

For https://build.opensuse.org/package/view_file/systemsmanagement:cockpit/cockpit/cockpit.spec?expand=1 we want to keep the diff to the upstream shipped spec file clean. To do that currently we always need to remember running osc commit --noservice to not run this service. But often we forget or someone is unfamiliar with that.

Is there a way to make this service do the sensible thing for us? Would having the formater disable changing anything on seeing a magic comment be the way to implement that?

Original issue here openSUSE/osc#647

I sometimes copied some build commands from GitHub or websites. The copied text may contains \r and some editors don't convert it (vim). When I run osc build, it will throw an error at \r (show as ^M in vim) position.

Maybe format_spec_file can call spec-cleaner when preparing the spec file.

Details in openSUSE/openSUSE-release-tools#1322. For example:

Unknown license 'GPL-3.0+ and LGPL-3.0+'

I'd like to import Larceny Scheme (https://github.com/larcenists/larceny) into an OBS package, but the license
at https://github.com/larcenists/larceny/blob/master/COPYRIGHT appears to be idiosyncratic and does not directly correspond to an existing license.
Can someone review it and let me know if either it would be considered an instance of an existing entry or add a new entry for it?

As per poll on opensuse-packaging project https://doodle.com/poll/9y6gfunm8bm8cz3b

Counterpart change of spec-cleaner rpm-software-management/spec-cleaner@a82a733

Request-To-Return-Clause seems to be missing from exception list

This report is from cavil

https://legaldb.suse.de/reviews/details/364623#file-13936063112
Found new license BSD-3-Clause WITH Request-To-Return-Clause (risk 4) not present in old report

Since #42, almost all foo.spec packages with a _multibuild flavor like test now have something like

# spec file for package foo-test

Did you accept this intentionally?

hpc packages like tensorflow2 are even worse:

/usr/lib/obs/service/format_spec_file.files/prepare_spec tensorflow2.spec | head -2
#
# spec file for package %{package_name}

I committed a spec file update that didn't touch the initial comment section, but according to https://build.opensuse.org/package/rdiff/devel:languages:haskell:lts:7/ghc-yaml?linkrev=base&rev=2 the commit ended up modifying that comment after all, and the generated comment has the package name wrong. I assume that obs-service-format_spec is responsible for that change? Would it be possible to fix the script not to mis-detected that package name?