On Tue, Feb 11, 2020 at 5:39 AM Christopher Huhn <
C.Huhn@gsi.de> wrote:
> Given we discussed about the condition of chef during the sprints (the
> "crazy" renaming of licensing + can be replaced with "tinc"), is it a
> good idea (and time) to file an RM bug for it?
I'd have strong wish to keep the chef-client as an official Debian
package and not be required to `gem install chef`, build my own package
or roll out some crazy omnibus stuff (and pay the ridiculous license fee).
Ah, of course. I respect that wish of yours. Would you be willing to help us maintain that?
I wrote the things that need help with chef below (where you asked).
Do you mean cinc(https://cinc-project.gitlab.io/) when you write tinc?
Oh, yes. My bad. I meant cinc.
Would it make sense to replace chef with cinc? Does that work for you?
> (it also fails to build against Ruby 2.7)
The chef developers are actively working on this:
https://github.com/chef/chef/issues/9227
That is good to know, thanks!
What would be the best way for me to help keep chef or cinc in Debian?
For chef,
You could help us by updating the package and its reverse dependencies so they don't fail against Ruby2.7.
You might also want to keep the package updated (there's 16.0.58 out, while we're at 13.8.7).
Another help would be to fix chef on arm64 as it fails with the latest version of bundler. See the logs at [1].
Antonio mentioned some problem with the licensing part so you'd probably need to check that, too.
Also, I guess we can replace chef with cinc, maybe? Or d'you need both?
For cinc,
You'd need to package its dependencies and then package cinc itself.
(I am assuming it hasn't been packaged yet. I cannot see it on tracker, at least.)
Best,