June 2021 - openSUSE Packaging - openSUSE Mailing Lists

Leap 15.3 glibc binary and source rpms are different versions
by Onnie Winebarger 28 Jun '21

28 Jun '21

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

2 2

Portable way for using zstd tarballs?
by Ferdinand Thiessen 08 Jun '21

08 Jun '21

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

2 3

Dynamic linking of rust libraries
by sp1rit 08 Jun '21

08 Jun '21

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

3 3

libboost_filesystem-devel-32bit
by Konstantin Voinov 01 Jun '21

01 Jun '21

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?

2 2

Link broken: python-flask-jwt-extended
by Sean Marlow 01 Jun '21

01 Jun '21

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

6 14