I'm having trouble updating this package to 0.18.0 without rapidyaml.

@code , are you working on getting rapidyaml into Fedora?

I am working on it. I had put it on the back burner because it was a huge pain to patch the build system to refrain from downloading sources at build time, and I was tired of looking at it ;-) . Once I have a working package I’ll ask upstream if there is something that could be done in c4core to make this a little easier with CMake options or environment variables or something.

Anyway, I worked on it a little more this morning, and it’s really close. I now have a rapidyaml library package that could pass review, and I should be able to build the Python bindings properly too once I package https://pypi.org/project/cmake-build-extension/.

Thanks!

I'd be happy to do package reviews. jsonnet 0.18.0 is a dependency for some parts of Ceph's dashboards.

Currently, there are two things blocking further progress on packaging rapidyaml.

1. I am trying to understand what to do about upstream removing .so versioning from c4core/c4log/c4fs[1][2].
2. I am waiting on a package review for python-cmake-build-extension[3].

[1] https://github.com/biojppm/cmake/commit/436b163de715eb01e0912ea329431ca4c942a6ba#commitcomment-73776839
[2] https://github.com/biojppm/cmake/issues/8
[3] https://bugzilla.redhat.com/show_bug.cgi?id=2085825

The initial rapidyaml package is ready for review: https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=2115417

Does anyone have time to review the rapidyaml package? Thanks!

Oh my, I'd swear I did this earlier.  I'll get to it today.

Releases retrieved: 0.19.0
Upstream release that is considered latest: 0.19.0
Current version/release in rawhide: 0.17.0-6.fc37
URL: https://jsonnet.org/

Please consult the package updates policy before you issue an update to a stable branch: https://docs.fedoraproject.org/en-US/fesco/Updates_Policy/


More information about the service that created this bug can be found at: https://docs.fedoraproject.org/en-US/package-maintainers/Upstream_Release_Monitoring


Please keep in mind that with any upstream change, there may also be packaging changes that need to be made. Specifically, please remember that it is your responsibility to review the new version to ensure that the licensing is still correct and that no non-free or legally problematic items have been added upstream.


Based on the information from Anitya: https://release-monitoring.org/project/71812/


To change the monitoring settings for the project, please visit:
https://src.fedoraproject.org/rpms/jsonnet

Based on https://github.com/google/jsonnet/releases/tag/v0.19.0

> In order to support importbin, it was necessary to change the C API for import callbacks so that
> they can return arbitrary binary blobs (that can contain \0) as opposed to just strings. This
> change is not binary compatible with previous versions of libjsonnet. If you build against
> libjsonnet.h and you use import callbacks then you will have to make a small adjustment to your
> code.

looks like it will need a so name bump.

Releases retrieved: 0.19.1
Upstream release that is considered latest: 0.19.1
Current version/release in rawhide: 0.17.0-6.fc37
URL: https://jsonnet.org/

Please consult the package updates policy before you issue an update to a stable branch: https://docs.fedoraproject.org/en-US/fesco/Updates_Policy/


More information about the service that created this bug can be found at: https://docs.fedoraproject.org/en-US/package-maintainers/Upstream_Release_Monitoring


Please keep in mind that with any upstream change, there may also be packaging changes that need to be made. Specifically, please remember that it is your responsibility to review the new version to ensure that the licensing is still correct and that no non-free or legally problematic items have been added upstream.


Based on the information from Anitya: https://release-monitoring.org/project/71812/


To change the monitoring settings for the project, please visit:
https://src.fedoraproject.org/rpms/jsonnet

Hmmm... good news?  Upstream is finally versioning their `so` objects.  Bad news, they started at `0` which is a different binary abi than our `0` object.

I'll confess I'm unsure what the policy is here...

(In reply to Pat Riehecky from comment #11)
> Hmmm... good news?  Upstream is finally versioning their `so` objects.  Bad
> news, they started at `0` which is a different binary abi than our `0`
> object.
> 
> I'll confess I'm unsure what the policy is here...

Ideally we would have started the downstream .so versioning at something like “0.1” to avoid this (https://docs.fedoraproject.org/en-US/packaging-guidelines/#_downstream_so_name_versioning), but that ship has sailed.

We *could* patch upstream’s SOVERSION setting[1] to something that isn’t 0, like 0.1, then stop patching it the next time upstream bumps the SOVERSION. It’s not great, but I don’t know if there are any other reasonable options. Maybe the devel mailing list would have ideas?

[1] https://github.com/google/jsonnet/blob/813c7412d1c7a42737724d011618d0fd7865bc69/cpp/CMakeLists.txt#L19

FEDORA-2022-06200445ff has been submitted as an update to Fedora 38. https://bodhi.fedoraproject.org/updates/FEDORA-2022-06200445ff

FEDORA-2022-06200445ff has been pushed to the Fedora 38 stable repository.
If problem still persists, please make note of it in this bug report.

The needinfo request[s] on this closed bug have been removed as they have been unresolved for 120 days