Hello guys, Free Ekanayaka <fr...@debian.org> writes:
> László Böszörményi (GCS) <g...@debian.org> writes: [...] >> OK, currently I can't build 'raft' on Debian, a bug is reported [1] >> and upstream working on it. Fedora has a patch, which I haven't tried >> yet. > > I've notice that, I'll take a look as well. I've now fixed this problem in cowsql/raft and released v0.17.7. [...] >>> I'd also like to help with maintainership of both src:dqlite and the >>> re-upstreamed src:raft in Debian, making sure that things work as >>> expected. >> This is also accepted, you can open a project on Salsa and either >> start a project group or just make yourself the maintainer and me as >> an uploader. But the former might be better as I think Mathias might >> like to join. > > Great, thanks! I'll start a new project group then, that you and Mathias > can join as well. > > I'll follow-up this bug with the relevant updates. As you probably noticed I've created a new cowsql-team, of which both Mathias and you are owners. There are 3 packaging repositories there: raft, dqlite and cowsql. I've imported the current dqlite-1.11.1-1 source package in sid into the Salsa dqlite repository, imported the new v1.16.0 release, and set myself as Maintainer and László as Uploader. Similarly, I've also imported the current raft-0.15.0-1 source package in sid into the Salsa raft repository, updated the packaging to point to cowsql/raft instead of canonical/raft, imported the new v0.17.7 release, and set myself as Maintainer and László as Uploader. As Mathias noticed, the .so version of cowsql/raft v0.17.7 is 0. As I mention in: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1042989#55 there was a bit of a mess in the past with .so versions. The .so version should have been kept to 0 in all releases in the first place, and ABI compatibilty should have not been broken. I'd like to take the chance to clear the situation a bit: the .so version is now 0, and all future 0.x releases of cowsql/raft will be ABI and API backward compatible, so there will no need to bump the .so version. As a consequence, I've renamed the libraft2 binary package to libraft0. Note that libraft0 already exists in bullseye, but there's nothing depending on it, so even in the weird case where somebody downloads libraft0 from sid and installs it in bullseye, nothing should break. For bookworm/sid, there should be no breakage as well. I'd first upload raft-0.17.7-1 to sid, which will be a no-op for people with libraft2 installed. Then I'd upload dqlite-1.16.0-1 to sid, which would build against raft-0.17.7-1. At that point people with libdqlite0 installed will be upgraded to 1.16.0-1 and would pull libraft0, and running apt-get autoremove will get rid of libraft2. I've tested the lxd package in sid and it keeps working fine when performing the upgrade described above. Am I missing something? If there's consenus about this, I'd finalize the changelog and start uploading raft-0.17.7-1. Cheers, Free
