-
Notifications
You must be signed in to change notification settings - Fork 182
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Binary packages no longer built (was: 1.5.4 package doesn't work on Debian buster) #203
Comments
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). |
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. |
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 ( 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
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. :) |
@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. |
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. |
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 So my GitHub action to update the repo hasn't updated to 1.5.4. |
You can build packages for lots of different distributions and architectures with openSUSE's Open Build Service. What they handle for you:
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):
|
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). |
Thanks a lot, @tommie! Do you want we link your builds from the README? |
Sure. I think it's stable enough for others to use now. |
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. |
I have opened bug https://bugs.debian.org/1052189 to track packaging efforts in the official Debian.org archive. |
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
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.
The text was updated successfully, but these errors were encountered: