The x86_64 binary rpm is glibc-2.31-7.30.x86_64.rpm.
The source rpm is glibc-2.31-7.20.src.rpm.
Is there a source rpm corresponding to the binary that can be put in the source repo?
Lynn Winebarger
Hi,
I see an increasing number of projects providing their sources as zstd compressed tarballs.
But currently it is only possible to use them directly on Tumbleweed by adding zstd as BuildRequires.
Leap is broken, as the %setup macro will not detect the zstd compression even if you add it as a build requirement.
(I remember when xz works off the shelf on Factory but you had to add it as BuildRequires for the stable distribution, but for zstd %setup seems to be broken on Leap)
So currently I guess you have to use something like this?
> %if 0%{?suse_version} >= 1550
> %setup -q
> %else
> # Leap does not support zstd as source compression
> %setup -cT
> tar -I zstd -xf %{SOURCE0} --strip-components=1
> %endif
Cheers
Ferdinand
Hi,
I have some questions regarding dynamic rust packaging.
As most of you probably know, Rust supports building a library crate
crate as a shared object (--crate-type dylib). Those objects contain
everything needed to build & link against them but can be shared by
multiple dependents unlike rust's rlibs that are statically linked into
the resulting binary.
Additionally invoking rustc with -C prefer-dynamic links the rust std
dynamically (/usr/lib/rustlib/x86_64-unknown-linux-gnu/lib/libstd-
<fingerprint>.so) rather than staticly in the resulting binary and thus
its filesize a lot smaller.
I was wondering if this could be used to build rust packages, because
currently all rust crate packages just provide the sourcecode, and
cargo/rustc builds a static binary (only links against glibc).
Additionally devel:languages:rust:crates seems kinda dead (last updated
package seven months ago), but dynamic linking could offer an advantage
over vendoring the dependencies into your package.
The downside to dynamic linking in rust is, that if a library or the
std gets updated but a dependency didn't it'll break the dependency.
However, given that the buildservice will recompile any dependents if a
package gets updated, the only case where this could become an issue is
in case of a partial update.
If anyone wants to experiment with rust's dynamic librarys, heres how I
got it to work:
1. Build any library you depend on with --crate-type dylib
2. Drop the library you've just built from the dependencies section
3. Rebuild the project with RUSTFLAGS="-C prefer-dynamic --extern
depname=../path/to/built/library/libdepname.so" cargo -v build
4. To run the built binary make sure that the libdepname.so is in your
LD search path.
Regards,
Florian "sp1rit"
--
Matrix: @sp1rit:tchncs.de
<sp1rit(a)disroot.org>
D248BF2F4C6A82A1E0569D897D8C1CD573166D09
<sp1rit(a)national.shitposting.agency>
BBDE032EAAFBFC627FB7E635B1F4055D8460CE34
Hi,
It's a rarely case, but I need the link /usr/lib/libboost_filesystem.so
-> /usr/lib/libboost_filesystem.so.1.76.0
for building 32bit-64bit version of yabridge
https://github.com/robbert-vdh/yabridge
keep an own branch of boost scares me a bit
maybe there is a some trick where I can make a stump package with that
link?
Hi,
I noticed that the devel package is broken for python-flask-jwt-
extended [1]. It seems like the link is invalid. Any ideas on how to
get this fixed so the package starts building again in devel and also
in factory?
[1]
https://build.opensuse.org/package/show/devel:languages:python:flask/python…
Thanks,
Sean
