Search Criteria
Package Details: vodozemac-bindings-cpp-kazv 0.1.0-3
Package Actions
Git Clone URL: | https://aur.archlinux.org/vodozemac-bindings-cpp-kazv.git (read-only, click to copy) |
---|---|
Package Base: | vodozemac-bindings-cpp-kazv |
Description: | kazv's C++ bindings for the vodozemac cryptographic library. |
Upstream URL: | https://lily-is.land/kazv/vodozemac-bindings |
Licenses: | Apache-2.0 |
Submitter: | shrik3 |
Maintainer: | shrik3 |
Last Packager: | shrik3 |
Votes: | 0 |
Popularity: | 0.000000 |
First Submitted: | 2024-10-19 20:02 (UTC) |
Last Updated: | 2024-11-13 14:56 (UTC) |
Dependencies (3)
- gcc-libs (gcc-libs-gitAUR, gccrs-libs-gitAUR, gcc11-libsAUR, gcc-libs-snapshotAUR)
- cargo (rustup-gitAUR, rust-nightly-binAUR, rust-gitAUR, rust, rustup) (make)
- perl (perl-gitAUR) (make)
Latest Comments
shrik3 commented on 2024-11-14 16:00 (UTC) (edited on 2024-11-14 16:04 (UTC) by shrik3)
dreieck:
sorry, I gave the wrong reference. The upstream is https://github.com/matrix-org/vodozemac-bindings which is officially "unmaintained". It's a binding for other languages, not the library itself.
I had a brainfart, sorry for the misinformation.
RT: https://aur.archlinux.org/packages/vodozemac-bindings-cpp-kazv#comment-998355
dreieck commented on 2024-11-13 16:08 (UTC)
Addendum:
But maybe it still should
conflicts=('libvodozemac')
, because it installs/usr/include/vodozemac.h
and/usr/lib/libvodozemac.so*
.dreieck commented on 2024-11-13 13:56 (UTC) (edited on 2024-11-13 13:58 (UTC) by dreieck)
In this case I think it should not provide
libvodozemac
at all.It is a rust library anyway, and I have no idea how to make a "C" shared library from this.
Does kazv's fork forkes and changes https://github.com/matrix-org/vodozemac as well, or does it only provide a wrapper to build a shared "C" library? Ok, seems the first. :-(.
Thank you for the maintanance!
shrik3 commented on 2024-11-12 20:16 (UTC) (edited on 2024-11-14 16:06 (UTC) by shrik3)
@dreieck :
done;
I'm new to packaging and this is my mistake; I'll commit the changes in a few days. Thanks for pointing out.
other than that, I was wondering whether this package should provide
libvodozemac
at all: kazv's fork (this) differs from the original [1] a lot and has different versioning.[1] https://github.com/matrix-org/vodozemac-bindings ; which AFAIK is not packaged for arch.
P.S. I've pointed the devs to your notes on
libkazv-git
andkazv-git
. Thank you![EDIT] I wrongly pointed to the vodozemac library as upstream. It should have been the bindings, which is unmaintained.
dreieck commented on 2024-11-12 18:37 (UTC)
I see strange versioned
provides
entry in the finished build:libvodozemac.so=0.1.0
andlibvodozemac.so=libvodozemac.so-64
.The first version is manually specified in the
provides
array (I think it should have a-<bitdepth>
suffix, calculated from$CARCH
?), the second one is strange, though.Anyway, I suggest to add
libvodozemac
to theprovides
andconflicts
arrays (andlibvodozemac.so
maybe too to theconflicts
array).Regards!
dreieck commented on 2024-11-12 18:04 (UTC) (edited on 2024-11-12 18:08 (UTC) by dreieck)
It is, but
rust
was neither a makedependency.I thing (observing other packages) specifiyng
cargo
is the correct way, and usually this results in installingrust
, but if people need specific other versions likerustup
they also can install that.You can (and should) remove
rust
frommakedepends
once you havecargo
, otherwise you could create conflicts withrustup
,cargo-nightly
or so, I think.But I am really unsure on this aspect!
shrik3 commented on 2024-11-11 20:30 (UTC)
@dreieck :
both done, thanks for the comments.
I thought
cargo
was already provided byrust
; my bad.dreieck commented on 2024-11-11 19:41 (UTC)
I am now trying to build this in order to bring
libkazv-git
up to date.cargo
needs to be added to themakedepends
array:When done, please rework your
PKGBUILD
so that the rust specific downloads already happens inprepare()
:Regards and thanks for the package!