tonarino/innernet

Binary packages no longer built (was: 1.5.4 package doesn't work on Debian buster)

bensteinberg opened this issue · 13 comments

bensteinberg commented

This isn't really a problem, just a report -- when I upgraded a mixed set of buster and bullseye machines to 1.5.4, I found that the service wouldn't start on the buster machines. The error in the syslog was

innernet[28207]: /usr/bin/innernet: /lib/x86_64-linux-gnu/libc.so.6: version `GLIBC_2.29' not found (required by /usr/bin/innernet)

so I downgraded the buster machines to innernet 1.5.3. I'm not sure whether this has to do with the OS of the underlying system that GitHub workflow uses to build the Debian packages. My buster machines have libc6 version 2.28-10, and the bullseye machines have 2.31-13+deb11u2.

alerque commented

This project should not be releasing deb files ... there are lots of different variants of Ubuntu systems (Debian, Ubuntu, others, different releases, etc). Packaging info should be tracked in a separate packaging repository and binary packages released to wherever each distro needs them (the main upstream distro if possible, PPAs or other user repositories otherwise).

mcginty commented

I'm in agreement, I think innernet should stop releasing "official" deb or rpm files since they're bound to continue to cause headaches (or overload people with the variations necessary for it to work for all users).

That said, @bensteinberg, just run:

cargo install cargo-deb # if it isn't installed already
cargo deb -p client
cargo deb -p server

and you'll have a working deb linked and built correctly for your OS and architecture :).

If somebody has guidance on a simple way to maintain an apt repository (or better yet, wants to maintain it themselves), I'm happy to collaborate.

bensteinberg commented

Thanks! A few points, in no particular order:

I agree that package maintenance doesn't belong in this repo, or in your hands, necessarily, but the close coupling of releases and the production of packages with GitHub Actions is pretty nice.

I'm happy to build my own packages, but in some cases it will require people to find or create a build server with the right OS and architecture, as many possible targets are going to be constrained in disk space (~/.rustup/, ~/.cargo/, and innernet/ take up almost 2G after the build) or memory -- an experiment just now in building on a t3.micro EC2 instance (1G RAM) resulted in the instance freezing.

I've contemplated making another run at becoming a Debian Maintainer, but I'm not sure it's the right solution here; I think the pace of innernet development may not match the cadence of Debian releases. Not sure how important that is.

I don't know much about setting up or maintaining an apt repository or PPA, but will look into it.

I see you've already removed the .deb files for 1.5.4 ;)

The complete procedure for building and installing a Debian client package in a fresh bullseye machine at the moment is

apt install git build-essential libsqlite3-dev
curl https://sh.rustup.rs -sSf | sh
source $HOME/.cargo/env
git clone https://github.com/tonarino/innernet.git
cd innernet/
cargo install cargo-deb
cargo deb -p client
apt install ./target/debian/innernet_1.5.4_amd64.deb

I also noticed that the Mac I'm working on is running 1.5.2 -- is the pipeline to homebrew no longer in place?

Thanks, @mcginty! I hope this doesn't sound like I'm hassling you, and I apologize if it does. My intent is pure enthusiasm. :)

  • 👍3
mcginty commented

@bensteinberg Don't worry, I don't feel hassled in the slightest! This is quite helpful to talk through.

Yeah, I agree that innernet currently fits best as a PPA or external apt repository vs. being packaged, given its rate of change still. As for build machines, I can supply that either via my own machines or configuring GitHub actions to generate the right artifacts, the main concern is just hosting them in a convenient place and keeping them maintained :).

Thanks for reminding me about homebrew! It's not currently automated, and I forgot to update it. I think now that innernet is in more wide-spread usage, I'm going to make a PR to submit innernet to the official Homebrew repository.

alerque commented

I'm going to make a PR to submit innernet to the official Homebrew repository.

Definitely recommended. Besides making it easy to get started with for end users, they have pretty good CI checks on their main repository and it allows anybody submitting a PR to bump on updates so you don't have to feel on the line for it.

tommie commented

If somebody has guidance on a simple way to maintain an apt repository (or better yet, wants to maintain it themselves), I'm happy to collaborate.

I already have an APT repo (using reprepro) running automatic updates from the official repo releases: https://github.com/tommie/innernet-debian

I'm guessing that moving the cargo deb invocation to there would be simple, and forking it per Debian version would be too. I'm using these packages on Ubuntu, BTW. Haven't had any issues with Debian version mismatches yet. Just today noticed that v1.5.4 .debs didn't make it to the release artifacts: https://github.com/tonarino/innernet/releases/tag/v1.5.4

So my GitHub action to update the repo hasn't updated to 1.5.4.

hg commented

You can build packages for lots of different distributions and architectures with openSUSE's Open Build Service.

What they handle for you:

  • building on and for all of the most popular distributions (typically including the latest preview version, and at least two oldstable versions)
  • doing that on native hardware (x86, amd64, ppc64, s390x, armv6, armv7, aarch64, probably something else I'm forgetting); everything is built on native hardware and not emulated on top of x86
  • automatically sign packages to make package managers happy (only their signing servers know the keys)
  • create and update repositories (users don't have to re-download packages on every update manually like it's 1980, just add the repo once and forget about it)

You can reuse the same RPM spec for everything.

I can help with writing a spec if there's interest in using OBS. Here's an example for tinc (not official, it's just an experiment for now):

  • ❤️5
tommie commented

I got https://github.com/tommie/innernet-debian back up, built debs of 1.5.5. Also building for both Ubuntu focal and jammy, where focal still works on Debian bullseye too (jammy's glibc is too new).

strohel commented

Thanks a lot, @tommie! Do you want we link your builds from the README?

tommie commented

Do you want we link your builds from the README?

Sure. I think it's stable enough for others to use now.

wwalker commented

I will endeavor to set up a separate repo to build rpm builds. It will however take a little while to sort out how to build for multiple architectures and distributions.

  • 🎉1
  • ❤️2
  • 🚀1
refi64 commented

I've created a COPR with packages for Fedora & RHEL9 family, currently on v1.6.0 w/ #273 added on top.

  • 🎉2
  • ❤️1
anarcat commented

I have opened bug https://bugs.debian.org/1052189 to track packaging efforts in the official Debian.org archive.

  • 👍3
  • ❤️1