Bug 1508950

> Obsoletes:  grib_api-devel < 1.18.0-3
> Provides:   grib_api-devel = 1.18.0-3
> Provides:   grib_api-devel%{?_isa} = 1.18.0-3

Questionable. And deserving a comment in the spec file at least.

First of all, grib_api is way above 1.18.0 already, so one would like to know whether this package really _replaces_ all of that. 

Secondly, if replacing a package, while the Obsoletes tag is correct and needed, one must be careful about whether/when to add the Provides tag. Only if the new package is compatible enough as a replacement, adding the Provides tag makes sense. Only then something that BuildRequires grib_api-devel would work if eccodes-devel is pulled in as the replacement package. That's mentioned here:
  https://fedoraproject.org/wiki/Packaging:Guidelines#Renaming.2FReplacing_Existing_Packages
Since basic files, such as the pkg-config files, have been renamed, the replacement package is _not_ compatible enough.


> %{_libdir}/*.so*

https://fedoraproject.org/wiki/Packaging:Guidelines#Shared_Libraries

Thanks for looking at the spec file.
I did not yet pay much attention to the Obsoletes/Provides. It was added in the first version by Orion, so maybe he wishes to comment?

As I understand it, according to upstream this package will replace grib_api, and it has some compatibility to it.
https://software.ecmwf.int/wiki/display/ECC/ecCodes+Home states:
"""
For GRIB encoding and decoding, the GRIB-API functionality is provided fully in ecCodes with only minor interface and behaviour changes. Interfaces for C, Fortran 90 and Python are all maintained as in GRIB-API.  However, the GRIB-API Fortran 77 interface is no longer available.
"""
I have no overview of what these minor changes are, but at least the library name itself is totally different, so depending packages will never build "as is" against this new library.
I have no problem to remove the provides tag.

Also thanks for pointing out the missing %post / %postun sections. I'll add them in the next version.

Spec URL: http://www.jdekloe.nl/Fedora/eccodes-2.5.0-1-rev2/eccodes.spec
SRPM URL: http://www.jdekloe.nl/Fedora/eccodes-2.5.0-1-rev2/eccodes-2.5.0-1.fc26.src.rpm

Here is my next try.
I am not happy yet, but there is some improvement.
* Obsoletes / Provides have been disabled
* post / postun sections have been added
* LD_LIBRARY_PATH env setting has been added to the ctest command. This is needed to let the tests run

Still rpmlint issues a number of errors and warnings:
   7 packages and 0 specfiles checked; 8 errors, 57 warnings.

eccodes.x86_64: E: invalid-soname /usr/lib64/libeccodes.so libeccodes.so

has been reported upstream. Not clear yet what they will do.
See: https://software.ecmwf.int/issues/browse/SUP-1809
[this issue has been made public now]

eccodes.x86_64: E: wrong-script-interpreter
and
eccodes.x86_64: E: non-executable-script
for files:
  /usr/share/eccodes/definitions/grib1/local.82.0.def
  /usr/share/eccodes/definitions/grib1/local.82.83.def

these are a false errors. These def files are data files, not scripts.
They start by accident with a shebang like line due to a funny choice of data format by upstream.

eccodes-devel.x86_64: E: rpath-in-buildconfig 
  /usr/lib64/pkgconfig/eccodes.pc
  /usr/lib64/pkgconfig/eccodes_f90.pc

Sure, these files contain rpath settings.
However, removing these settings totally cripples the test system.
I don't know what to do here. Any idea how to solve this?

eccodes-debuginfo.x86_64: E: useless-provides debuginfo(build-id)

I don't know what this means. How to solve it?

The warnings are mostly on missing man pages (44 times).
and false warnings on spelling errors (7 times)

An issue requesting addition of the missing man pages was opened here:
https://software.ecmwf.int/issues/browse/SUP-2271
[this issue is still internal, but I requested them to make it public]

The other warnings are:

eccodes-devel.x86_64: W: only-non-binary-in-usr-lib

this is a bug in rpmlint I think.
/usr/lib64 contains 2 fortran *.mod files which are needed
to be able to compile fortran code with this library.
These files are possibly ascii, but they are generated by the compiler
and surely should be in the devel package.

eccodes-devel.x86_64: W: no-documentation
python2-eccodes.x86_64: W: no-documentation
eccodes-debugsource.x86_64: W: no-documentation

all relevant documentation is included in the main package, so no problem here.

eccodes.x86_64: W: shared-lib-calls-exit /usr/lib64/libeccodes.so exit.5
eccodes.x86_64: W: shared-lib-calls-exit /usr/lib64/libeccodes_f90.so exit.5

this is a proper problem.
It is reported upstream here: https://software.ecmwf.int/issues/browse/SUP-2272
[this issue is still internal, but I requested them to make it public]

Also the 4 failing tests are still excluded in the check section.
I tried hard but could not yet find a way to make them pass.

just for information. Upstream issues:
https://software.ecmwf.int/issues/browse/SUP-2271
https://software.ecmwf.int/issues/browse/SUP-2272
have now been made publicly accessible.

> eccodes-devel.x86_64: E: rpath-in-buildconfig 
>   /usr/lib64/pkgconfig/eccodes.pc
>   /usr/lib64/pkgconfig/eccodes_f90.pc
>
> Sure, these files contain rpath settings.
> However, removing these settings totally cripples the test system.

How?  -Wl,-rpath,${libdir}  with standard lib is pretty much nonsensical. And do you mean the $LD_LIBRARY_PATH fix deals with this already? Pointing the %check section at libs in the buildroot may be strictly necessary for some packages. It isn't unusual to do that.


> eccodes-debuginfo.x86_64: E: useless-provides debuginfo(build-id)
> 
> I don't know what this means. How to solve it?

Give "rpmlint -i ..." a try. It's rpmlint being confused by -debuginfo packages:

$ rpmlint -i eccodes-debuginfo-2.5.0-1.fc27.x86_64.rpm
eccodes-debuginfo.x86_64: E: useless-provides debuginfo(build-id)
This package provides 2 times the same capacity. It should only provide it
once.

Spec URL: http://www.jdekloe.nl/Fedora/eccodes-2.6.0-1-rev1/eccodes.spec
SRPM URL: http://www.jdekloe.nl/Fedora/eccodes-2.6.0-1-rev1/eccodes-2.6.0-1.fc26.src.rpm

Thanks a lot for your comments.
The above links point to my next iteration.
Changes this time are:
* update to new upstream version 2.6.0
* defined a downstream so version since upstream refuses to do so
* found that next to LD_LIBRARY_PATH the tests also need the LIBRARY_PATH environment setting, since many tests generate c or fortran code and compile it on the fly. Without it the compiler does not find the libraries in the build tree. With this change the rpath setting could be removed from the eccodes.pc and eccodes_f90.pc without the earlier mentioned problems
* added a small patch to fix 2 remaining failures for tests that compile pieces of fortran code

With these changes the number of errors reported by rpmlint is reduced to 5.
Four of the remaining errors are false positives since they are triggered by data files that start with something resembling a shebang as mentioned above.

The only other error is:
   eccodes-debuginfo.x86_64: E: useless-provides debuginfo(build-id)
I suspect this is caused by the fact that the package installs two tools in the bin directory that are binary identical to each other. I don't think I can fix that, since it is an upstream choice to do it like that.

I noticed two new warnings on the so files that I don't understand yet:
eccodes.x86_64: W: devel-file-in-non-devel-package /usr/lib64/libeccodes.so
eccodes.x86_64: W: devel-file-in-non-devel-package /usr/lib64/libeccodes_f90.so
this seems not correct to me.

Spec URL: http://www.jdekloe.nl/Fedora/eccodes-2.6.0-1-rev1/eccodes.spec
SRPM URL: http://www.jdekloe.nl/Fedora/eccodes-2.6.0-1-rev1/eccodes-2.6.0-1.fc28.src.rpm

sorry, there was a typo in the srpm package. This one should work.

>The only other error is:
>   eccodes-debuginfo.x86_64: E: useless-provides debuginfo(build-id)

Don't worry about this, it's a rpmlint bug fixed in the next version.

- %post -p /sbin/ldconfig

  %postun -p /sbin/ldconfig

   Use the brand new macro for this:

%ldconfig_scriptlets

   See https://fedoraproject.org/wiki/Changes/Removing_ldconfig_scriptlets#Upgrade.2Fcompatibility_impact


 - I noticed two new warnings on the so files that I don't understand yet:
eccodes.x86_64: W: devel-file-in-non-devel-package /usr/lib64/libeccodes.so
eccodes.x86_64: W: devel-file-in-non-devel-package /usr/lib64/libeccodes_f90.so
this seems not correct to me.

This correct: the .so files without the versioning should be in the -devel subpackage. See https://fedoraproject.org/wiki/Packaging:Guidelines#Devel_Packages for more details.

I've got a failed test when trying to build:

99% tests passed, 1 tests failed out of 217
Label Time Summary:
download_data    =  47.88 sec*proc (5 tests)
eccodes          = 1028.06 sec*proc (217 tests)
executable       =   0.40 sec*proc (1 test)
script           = 979.78 sec*proc (211 tests)
Total Test time (real) = 178.90 sec
The following tests FAILED:
	184 - eccodes_p_grib_keys_iterator_test (Failed)

See logs https://koji.fedoraproject.org/koji/taskinfo?taskID=25299376

SO I tested with Fedora 27 and it works:

184/217 Test #184: eccodes_p_grib_keys_iterator_test ...........   Passed    0.40 sec

So I don't know what change in F29 that might cause an issue? GCC 8?

thanks a lotfor your time and your explanation on the "W: devel-file-in-non-devel-package " warning.
I'll take a look at the failing test now to see what happens.

Haha I got the fricking bug! Starting F28, Fedora warns against the use of /usr/bin/python:

DEPRECATION WARNING: python2 invoked with /usr/bin/python.
    Use /usr/bin/python3 or /usr/bin/python2
    /usr/bin/python will be removed or switched to Python 3 in the future.
    If you cannot make the switch now, please follow instructions at https://fedoraproject.org/wiki/Changes/Avoid_usr_bin_python_in_RPM_Build#Quick_Opt-Out

One of this warning messages got into test 184 output, making it fail.

To solve this, simply pass the following cmake variable to force the use of /usr/bin/python2

%cmake3 -DINSTALL_LIB_DIR=%{_lib} \
        -DENABLE_ECCODES_OMP_THREADS=ON \
        -DENABLE_EXTRA_TESTS=ON \
        -DENABLE_PNG=ON \
        -DCMAKE_SKIP_RPATH=TRUE \
        -DECCODES_SOVERSION=%{so_version} \
        -DECCODES_SOVERSION_F90=%{so_version_f90} \
        -DPYTHON_EXECUTABLE=%{_bindir}/python2 \
        ..

Then it builds.

Spec URL: http://www.jdekloe.nl/Fedora/eccodes-2.6.0-1-rev2/eccodes.spec
SRPM URL: http://www.jdekloe.nl/Fedora/eccodes-2.6.0-1-rev2/eccodes-2.6.0-1.fc27.src.rpm

brilliant, that might have taken me much longer to figure out...
I fixed the test and included your %ldconfig_scriptlets remark in a new version.
Files are available at above urls.

Thanks again for your help.

You didn't move the .so files to -devel:


>This is correct: the .so files without the versioning should be in the -devel
>subpackage. See https://fedoraproject.org/wiki/Packaging:Guidelines#Devel_Packages for more details.

thanks for pointing this out.
I've run out of time for today. It will be a few more days before I can continue on this one.

Spec URL: http://www.jdekloe.nl/Fedora/eccodes-2.6.0-1-rev3/eccodes.spec
SRPM URL: http://www.jdekloe.nl/Fedora/eccodes-2.6.0-1-rev3/eccodes-2.6.0-1.fc27.src.rpm

I moved the *.so file to the devel package, but I still get these rpmlint errors.

eccodes.x86_64: E: library-without-ldconfig-postin /usr/lib64/libeccodes.so.0.1
eccodes.x86_64: E: library-without-ldconfig-postun /usr/lib64/libeccodes.so.0.1
eccodes.x86_64: E: library-without-ldconfig-postin /usr/lib64/libeccodes_f90.so.0.1
eccodes.x86_64: E: library-without-ldconfig-postun /usr/lib64/libeccodes_f90.so.0.1

even though the %ldconfig_scriptlets macro is present.

Is this caused by running mock on a Fedora 27 system?
Do I need to change something to prevent this?

Another question: the source package provides html documentation and a fair number of usage examples for c, fortran and python. These are not installed by the cmake call in the %install section. Should/Could I add these as documentation? Maybe as a dedicated documentation sub-package?

This is perfectly normal:
 - on F27 and below, the %ldconfig_scriptlets macro it replaced with ldconfig
 - on F28 and above, it is replaced by nothing, because we moved ldconfig to a transfiletrigger than run once per transaction instead of per package, which improve speed.

See https://fedoraproject.org/wiki/Changes/Removing_ldconfig_scriptlets#Detailed_Description

Rpmlint is not up to speed with this new guidelines, so it causes an error when it doesn't detect ldconfig.

>Should/Could I add these as documentation? Maybe as a dedicated documentation sub-package?

Yes definitively. If the doc is superior to 1 MiB, split it in a noarch subpackage.

Spec URL: http://www.jdekloe.nl/Fedora/eccodes-2.6.0-1-rev4/eccodes.spec
SRPM URL: http://www.jdekloe.nl/Fedora/eccodes-2.6.0-1-rev4/eccodes-2.6.0-1.fc27.src.rpm

next attempt, I added a sub-package. Installed the documentation is about 6 MB, but compressed the rpm doc package is only 429 KB. If that is too small it is easy to revert the change.

Next issue: during a test install on my system I noticed there is a conflict for a number of scripts below /usr/bin that are also provided by the existing grib_api package. These files are also provided by the new eccodes package:

/usr/bin/grib2ppm
/usr/bin/grib_compare
/usr/bin/grib_copy
/usr/bin/grib_count
/usr/bin/grib_dump
/usr/bin/grib_filter
/usr/bin/grib_get
/usr/bin/grib_get_data
/usr/bin/grib_histogram
/usr/bin/grib_index_build
/usr/bin/grib_ls
/usr/bin/grib_set
/usr/bin/grib_to_netcdf
/usr/bin/tigge_accumulations
/usr/bin/tigge_check
/usr/bin/tigge_name
/usr/bin/tigge_split

Looking at the discussion in the first 3 comments above, it is not clear to me how to handle this. Eccodes could obsolete the grib_api package, but the ABI of the library itself may not be compatible enough to allow this.
Any idea what to do here?

I'm not sure either, ask on the -devel mailing list for advice.
I think I would do like Orion did initially.

Spec URL: http://www.jdekloe.nl/Fedora/eccodes-2.7.0-1-rev1/eccodes.spec
SRPM URL: http://www.jdekloe.nl/Fedora/eccodes-2.7.0-1-rev1/eccodes-2.7.0-1.fc27.src.rpm

Thanks.
After asking on the devel list and reading the answers I added the Obsoletes but no Provides.
I also updated to version 2.7.0.

[!]: Large data in /usr/share should live in a noarch subpackage if package
     is arched.
     Note: Arch-ed rpms have a total of 47646720 bytes in /usr/share
     eccodes-2.7.0-1.fc29.x86_64.rpm:47605760
     See:
     http://fedoraproject.org/wiki/Packaging:ReviewGuidelines#Package_Review_Guidelines

You should split of the data in a noarch subpackages.

 - Some of the source is under GPL:

GPL (v3 or later)
-----------------
eccodes-2.7.0-Source/src/grib_yacc.c
eccodes-2.7.0-Source/src/grib_yacc.h

LGPL
----
eccodes-2.7.0-Source/src/grib_accessor_class_bufr_data_element.c
eccodes-2.7.0-Source/src/grib_accessor_class_pack_bufr_values.c
eccodes-2.7.0-Source/src/grib_accessor_class_unpack_bufr_values.c

Thanks for pointing this out.

These 2:
eccodes-2.7.0-Source/src/grib_yacc.c
eccodes-2.7.0-Source/src/grib_yacc.h

have a special clause in their header:

It says:

   ...
   This program is free software: you can redistribute it and/or modify
   it under the terms of the GNU General Public License as published by
   the Free Software Foundation, either version 3 of the License, or
   (at your option) any later version.
   
   This program is distributed in the hope that it will be useful,
   but WITHOUT ANY WARRANTY; without even the implied warranty of
   MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
   GNU General Public License for more details.
   
   You should have received a copy of the GNU General Public License
   along with this program.  If not, see <http://www.gnu.org/licenses/>.  */

/* As a special exception, you may create a larger work that contains
   part or all of the Bison parser skeleton and distribute that work
   under terms of your choice, so long as that work isn't itself a
   parser generator using the skeleton or a modified version thereof
   as a parser skeleton.  Alternatively, if you modify or redistribute
   the parser skeleton itself, you may (at your option) remove this
   special exception, which will cause the skeleton and the resulting
   Bison output files to be licensed under the GNU General Public
   License without this special exception.
   
   This special exception was added by the Free Software Foundation in
   version 2.2 of Bison.  */

as I interpret this, these are not GPL strictly versioned, and maybe redistributed with the ASL license that applies to most of the rest of this package.

These 3 fils surely have the LGPL license:

eccodes-2.7.0-Source/src/grib_accessor_class_bufr_data_element.c
eccodes-2.7.0-Source/src/grib_accessor_class_pack_bufr_values.c
eccodes-2.7.0-Source/src/grib_accessor_class_unpack_bufr_values.c

I suspect this is a mistake upstream, since early versions of the predecessor package grib_api where LGPL licensed. They may just have forgotten to update these files.
I have raised an issue upstream to inquire if this really is what they intended, see:https://software.ecmwf.int/issues/browse/SUP-2387
(unfortunately this issue is not yet public)
and they confirmed this probably is a  mistake.

Anyway, for now the situation is as it is, so looking at the licensing faq:
https://fedoraproject.org/wiki/Licensing:FAQ?rd=Licensing/FAQ#How_should_I_handle_multiple_licensing_situations.3F
question 2.2, issue nr. 1, the most strict license should be applied, so this would be the LGPL license I think.

I'll update the spec file accordingly for now, and revert the change when upstream fixes this in a new release.

Spec URL: http://www.jdekloe.nl/Fedora/eccodes-2.7.0-1-rev2/eccodes.spec
SRPM URL: http://www.jdekloe.nl/Fedora/eccodes-2.7.0-1-rev2/eccodes-2.7.0-1.fc27.src.rpm

> [!]: Large data in /usr/share should live in a noarch subpackage

added a data sub-package and changed the license as mentioned in the above comments.
New version in the URLs above.

Seems upstream believe that the LGPL files are errors, and thus the whole project should be ASL 2.0.

 - This:

/usr/share/eccodes/cmake/eccodes-config-version.cmake
/usr/share/eccodes/cmake/eccodes-config.cmake
/usr/share/eccodes/cmake/eccodes-import.cmake
/usr/share/eccodes/cmake/eccodes-targets-relwithdebinfo.cmake
/usr/share/eccodes/cmake/eccodes-targets.cmake

   I think these files should be in %{_libdir}/cmake/%{name}/. And in the -devel subpackage.

 - Your check part is escaped:

%%check

   Remove the extraneous %.

Spec URL: http://www.jdekloe.nl/Fedora/eccodes-2.7.0-1-rev3/eccodes.spec
SRPM URL: http://www.jdekloe.nl/Fedora/eccodes-2.7.0-1-rev3/eccodes-2.7.0-1.fc27.src.rpm

Thanks again for looking at my changes.

(In reply to Robert-André Mauchin from comment #26)
> Seems upstream believe that the LGPL files are errors, and thus the whole
> project should be ASL 2.0.

changed it back again.

>  - This:
> 
> /usr/share/eccodes/cmake/eccodes-config-version.cmake
> /usr/share/eccodes/cmake/eccodes-config.cmake
> /usr/share/eccodes/cmake/eccodes-import.cmake
> /usr/share/eccodes/cmake/eccodes-targets-relwithdebinfo.cmake
> /usr/share/eccodes/cmake/eccodes-targets.cmake
> 
>    I think these files should be in %{_libdir}/cmake/%{name}/. And in the
> -devel subpackage.

done

>  - Your check part is escaped:
> 
> %%check
> 
>    Remove the extraneous %.

Sorry about that, stupid mistake from my side
fixed it.

New version in the URLs mentioned above.

%dir %{_libdir}/cmake/%{name}
%dir %{_libdir}/cmake/%{name}/cmake
%{_libdir}/cmake/%{name}/cmake/*


The cmake files should be directly under %{_libdir}/cmake/%{name}, not within a cmake subdirectory. Probably by moving like this:

mv %{buildroot}%{_datadir}/%{name}/cmake/* %{buildroot}%{_libdir}/cmake/%{name}/


This is trivial to fix, package is therefore accepted.

Hi  Robert-André Mauchin,

thanks a lot!
And sorry that this took so much iterations. I guess it shows my inexperience, since I have not done a lot of packaging yet.

Anyway, I owe you one, so if you have an open review request just let me know.

(fedrepo-req-admin):  The Pagure repository was created at https://src.fedoraproject.org/rpms/eccodes

eccodes-2.7.0-2.fc28 has been submitted as an update to Fedora 28. https://bodhi.fedoraproject.org/updates/FEDORA-2018-2942160ff6

eccodes-2.7.0-2.fc28 has been pushed to the Fedora 28 testing repository. If problems still persist, please make note of it in this bug report.
See https://fedoraproject.org/wiki/QA:Updates_Testing for
instructions on how to install test updates.
You can provide feedback for this update here: https://bodhi.fedoraproject.org/updates/FEDORA-2018-2942160ff6

eccodes-2.7.0-2.fc28 has been pushed to the Fedora 28 stable repository. If problems still persist, please make note of it in this bug report.