Third party packages on the openSUSE build service

[Masgalor]

Hey folks.
I created a project at the openSUSE-BuildService, to provide repositories with prebuilt packages for several linux distributions.

The motivation was my slightly disappointing experience with the available third party packages.
Some packaging projects are lacking behind, some distros have only buildscripts available that need some knowledge to be used and so on. I also noticed that a lot of people would rather download some random package from the web than learn to use a build script, what is an awful idea, especially for a password-manager.

My available packages are far from being perfect, but alone the fact that they are downloaded via a package-manager from a trustworthy source are worth a lot.

Unfortunately, this buildsystem has a some restrictions that prevent the building with rust-nightly and npm.
So all I can do for now is packaging prebuilt binaries (extracted from the docker image) and the prebuilt webvault available here under dani-garcia/bw_web_builds. I will try to improve this in the future, but for now it is as it is.

Anyway, let me know what you think about it.

Project-Page https://build.opensuse.org/project/show/home:Masgalor:Vaultwarden
Vaultwarden API-Server https://software.opensuse.org//download.html?project=home%3AMasgalor%3AVaultwarden&package=vaultwarden
Vaultwarden web-vault https://software.opensuse.org//download.html?project=home%3AMasgalor%3AVaultwarden&package=vaultwarden-webvault

[BlackDex]

Would you be so kind and update: https://github.com/dani-garcia/vaultwarden/wiki/Third-party-packages

[Masgalor]

Sure, my idea was to get some basic feedback before I do so.

[mqus]

What you did is great imho (building packages for 7 distros is no small feat!) , but the argument about trustworthiness seems odd to me:

My available packages are far from being perfect, but alone the fact that they are downloaded via a package-manager from a trustworthy source are worth a lot.

Your packages are mostly bundling pre-built binaries (Out of necessity, I get that.). How is that more trustworthy than downloading a random package from the internet?

But I still think this is great, mostly because a repository (even an untrustworthy one) means regular updates and minimal effort to get them.

I packaged vaultwarden for Archlinux for a while (before it became an official package) and the package(s) seems good to me. Sadly I don't really have a clue about spec-files and debians build system so I can't comment on the specifics and guidelines of the distros you target. One thing that may be an idea (depending on how the distro usually handles this) are tmpfiles.d and sysusers.d files for creating the /var/lib/vaultwarden directory and adding the vaultwarden user, respectively. (See the files in https://github.com/archlinux/svntogit-community/tree/packages/vaultwarden/trunk and how they get applied). They are more declarative instead of imperative which to me seems a bit cleaner.

[Masgalor]

Thank you for your feedback.
Regarding the trustworthiness of this project, I was primarily referring to the service and infrastructure of openSUSE.
The packages themselves are not more or less trustworthy than any other package out there.

The problems I see with "random" downloads:
Your download-request may be redirected several times before reaching the requested file.
File-checksums may not be available.
The packages may not be signed.
And even if there are checksums and signatures available, you have to download and check them by your self for every update.
You can never be sure the package was built for your specific distro, rpms are not always compatible with any rpm base distro.

The user and directory creation is based on arguably old Debian practices that suggest not to relay on systemd during package installation, as it may not be available on the system. But I will keep this in mind for the future.

[alexpdp7]

Hi @Masgalor ,

I maintain an RPM for EL8 which I implemented as a fork of this repo, adding some scripts to build an RPM and push them to COPR ( https://github.com/alexpdp7/bitwarden_rs/commit/6645f190fa61db24be4c5705b6772f76d1d34a66 ).

Even if you cannot build nightly Rust, do OBS builds allow you to pull stuff from the Internet? You could run rustup or even... fetch the official Docker image and extract the binary instead of bundling it in the OBS sources?

If you can do that, I'd rather deprecate my build- the Vaultwarden maintainers have refused (rightfully) to merge my fork and upstream the RPM building, so I'd need to rebuild it anyway for more sanity. And your package has the webvault...

If you were willing to accept contributions to try to rustup/get the binary automatically during the build, I might try to help?

Cheers,

Álex

[BlackDex]

Just a small note, the current version of Vaultwarden builds fine using the stable release of Rust. No need for nightly anymore.

[Masgalor]

Hey @alexpdp7 , sorry for the late reply.

OBS does not allow an internet connection during builds.
So it is neither possible to use rustup nor to download crates at buildtime.
The stance they take here is similar to Debian, so kind of "If you need something during your build, package it first.".
There is only one exception, you are allowed to download archives before the build process and extract them to your SOURCE directory.

To finally build the binary inside OBS I configured it to download the official "rust offline installer".
There is also an official tool from OBS available to bundle all needed crates into an archive.
But for now this "crate collection tool" can not be used inside OBS you need to build the archive yourself and push it your OBS sources or upload it somewhere to download it. I do not know why they do not want it to run on their buildserver, might be changed in the future.
So I am now able use the sideloaded rust binaries and crates to build the binary.

I did not have the time to test the new packages yet, but the build process finishes without problems.
They are in a separate repo as of now, feel free to have a look.
https://build.opensuse.org/project/show/home:Masgalor:Vaultwarden_staging

[alexpdp7]

Heh, I posted my message very recently, no worries!

With BlackDex's message, it should be possible to install each distributions Rust and remove one binary dependency. However, Vaultwarden declares it needs Rust 1.60. So this would only be possible on EL9 (it has 1.61.0, EL8 is too old). And then all the dependencies should be packaged too, which is very tedious work. So packaging this for OBS does require pushing blobs or a lot of effort.

I think I will stick to my container-based build process. Would you mind if I "copy" your packaging? That is, can I copy your spec file and everything? I would attribute them to you and provide links to your OBS build...

(Sorry I'm a bit paranoid about the OBS packaging...)

[Masgalor]

Sure thing, feel free to use what ever resources are useful to you.
If you want to add a link my OBS please use https://build.opensuse.org/project/show/home:Masgalor:Vaultwarden the staging repo might be removed as soon as I have tested all packages thruly.

As @BlackDex wrote below, strip is considered experimental until 1.60, so you can remove it or activate experimental features to use a lower version.

Just a sidenote, you can run the obs-build-service yourself, it is available for a lot of distros.
If you do so, you are free to enable online access during builds, but I never tried that.

[alexpdp7]

Thanks! Will link to the main repo.

Yeah, we used to run OBS at a place I worked. It's great, and definitely a great choice if you're packaging for a ton of different distros. Given that I'm interested in just EL, I will just "refactor" my container build to separate it from the main repo. I have a Nextcloud package that uses this technique. The good thing about container builds is that I can just run rustup. It's a bit slow, but it's also easy to "validate and reproduce".

[BlackDex]

@alexpdp7 which version does EL8 support?
In theory Vaultwarden needs 1.59 but it has incremental building disabled because of some bugs which are fixed in 1.60.

And if really needed, you could patch the Cargo.toml to even support v1.58 by removing the strip settings. Maybe there is an other option to have that also working, but not sure from the top of my head. Though, using the latest stable would still be preferred of course.

[alexpdp7]

Hmmm, EL8 does ship 1.58, so patching might be interesting. I'll take a look. It's interesting to use the compiler in the distro, but if upstream does not support it... well, I can always switch back to rustup. Thanks for the heads up!