[Pkg-puppet-devel] Packaging Puppet Server 6 for Bullseye: status report

[Thomas Goirand]

On 12/28/20 4:20 PM, Louis-Philippe Véronneau wrote:
> On 2020-12-28 05 h 32, Thomas Goirand wrote:
>> On 12/27/20 1:49 AM, Louis-Philippe Véronneau wrote:
>>> On 2020-12-19 19 h 29, Louis-Philippe Véronneau wrote:
>>>> Hello folks!
>>>>
>>>> I think generally, things are moving in the right direction. Looking at
>>>> our TODO tracker for puppetserver [1], these are the only top level
>>>> dependencies left that keep us from packaging puppetserver
>>>>
>>>> * jruby-utils-clojure
>>>>
>>>> Not in the archive. I'm 75% done packaging it and in theory will only
>>>> have to update 2 or 3 of its dependencies to finish it.
>>>>
>>>> * libtrapperkeeper-metrics-clojure
>>>>
>>>> In the archive, not up to date. The dependency on jolokia-core worries
>>>> me; if it proves to be too much, I will probably vendor it in.
>>>
>>> *Good news:* I was able to update libtrapperkeeper-metrics-clojure by
>>> patching out Jolokia. It means reduced features (see #978402), but it's
>>> better than nothing.
>>>
>>> *Bad news:* jruby is in a bad state in Debian and currently cannot be
>>> used (see [1]). This pretty much means puppetserver won't be in the
>>> archive until someone decides to maintain jruby again.
>>>
>>> So short of a miracle, puppetserver will most likely not be in Bullseye.
>>
>> Hi,
>>
>> I don't think you need to go back and forth predicting what will happen.
>> Just do it (tm).
> Ack.
> 
>> So far, you've done a great job. Maybe just take over
>> JRuby? If it FTBFS and needs a new version, then no choice, and go ahead
>> (maybe going through staging in Experimental first...).
> 
> I don't plan on taking over Jruby no, as it has a bunch of very
> important bugs and I fear that's outside of field of competence. I guess
> I could eventually end up with something working, but it would certainly
> take me a _lot_ of time and I think my time is better used fixing
> Clojure deps for now.
> 
> Do you want to have a go at it? It would certainly unblock me a lot. The
> other alternative (that's what Moritz Mühlenhoff proposed me today) is
> to vendor jruby in jruby-utils-clojure.
> 
> Certainly less clean...

Hi,

I don't think I know Java packaging more than you do. However, what I
know, is that nobody will be angry at you if you attempt to repair a
package which is already broken (and IMO, that's the case with jruby,
considering the CVE and the FTBFS). Also, if the person that was taking
care of jruby isn't doing anything, I don't think we have a choice.

I don't think we need to take over the package completely though, if you
don't feel like it (I don't either: I package too many things already).

If you don't try before it, I'll see what I can do about it next week,
but again, I'm really not sure if I can do a better job than you would,
and also, RC bugs are accumulating on the OpenStack side, and I need to
take care of those first.

Cheers,

Thomas Goirand (zigo)