Used by sys-cluster/ceph, ebuild for rocksdb-6.14.6-r3 moves to EAPI=8 and adds more features.
This package has stable keywords only on 2 arches. Please don't cc arches manually, nattka will do it on its own when sanity check is green
Ok, sorry, I thought maybe it could be stable on more arches, but I guess if only ceph uses it, it might be pointless. I will use CC-ARCHES in the future once sanity check passes. Thanks!
Unable to check for sanity: > no match for package: dev-libs/rocksdb-8.10.0
All sanity-check issues have been resolved
amd64 done
Why is dev-libs/rocksdb-6.14.6-r3 receiving a new stable keyword here? It would be obsolete if ceph maintainers confirm <7.9.3 may be cleaned up, as bug 941299 is already stabilising 7.9.3-r1.
Indeed, I added -r3 to make it possible to drop EAPI=7 ebuilds in case ceph (which is picky) couldn't move to a newer version. If ceph is fine with 7.9.2, then we can stabilize that and drop other versions.
(In reply to Guilherme Amadio from comment #3) > Ok, sorry, I thought maybe it could be stable on more arches, but I guess if > only ceph uses it, it might be pointless. So, is first-time arm64 stable still desired? Because there is no stable revdep for it.
Was bug 84137 dependency added by mistake? (likely missing a digit?)
Yes, I thought it might be a good idea to stabilize on arm64 to allow ceph (which is only ~arm64) to become stable as well. However, if this creates too much unnecessary work, just keeping the current stable arches should be fine.
(In reply to Guilherme Amadio from comment #11) > Yes, I thought it might be a good idea to stabilize on arm64 to allow ceph > (which is only ~arm64) to become stable as well. However, if this creates > too much unnecessary work, just keeping the current stable arches should be > fine. The first step would be to create such a ceph ~arm64 keywording bug, let NATTkA go over the package list (unless you know already it is only rocksdb), and make it depend on the latest possible, compatible rocksdb stable bug (that would have been bug 941299). If I see a depending bug, I can sort of guess what you are intending to do with the added stable keywords even if I am not a maintainer involved in these packages, but even better to communicate the reasoning in #description.
(In reply to Andreas Sturmlechner from comment #12) > The first step would be to create such a ceph ~arm64 keywording bug *stabilisation bug ofc
amd64 is stabilized, let's wait for some time and stabilize the newly added rocksdb-9.10.0 later. Closing this bug.
Then what about ppc64?
I guess it is pointless given that the only ppc64 revdep here has a ceiling on <dev-libs/rocksdb-7.9.3 anyway. Un-CCing the arches for you.
Yes, since only ceph depends on rocksdb in the tree, there's no need to stabilize on ppc64. However, I realize that rocksdb-9.10.0 doesn't compile with GCC 15, so stabilization should probably wait on that getting fixed. Cheers,
(In reply to Guilherme Amadio from comment #17) > Yes, since only ceph depends on rocksdb in the tree, there's no need to > stabilize on ppc64. However, I realize that rocksdb-9.10.0 doesn't compile > with GCC 15, so stabilization should probably wait on that getting fixed. > Cheers, No, once again: GCC 15 does not even have keywords yet. Build failures with non-stable packages are no stabilisation blockers.
