On 4 October 2017 at 15:16, James Hogarth <[email protected]> wrote:
> > > On 5 September 2017 at 08:15, James Hogarth <[email protected]> > wrote: > >> >> >> On 5 Sep 2017 8:05 am, "Vít Ondruch" <[email protected]> wrote: >> >> >> >> Dne 4.9.2017 v 14:58 James Hogarth napsal(a): >> > >> > I'm in two minds whether to suggest we leave facter as it is for >> > F25-27 or whether to at least update those to 2.5.1 which won't have >> > the drastic 3.0 changes. >> >> For me it is always clear. Keep the branched versions as they are unless >> you have really good arguments for upgrade. >> >> >> Usually I'd agree... but facter is way behind on bug fixes and hasn't >> seen an update in two years... a full three fedora releases ago. >> >> A move to the most recent 2.X on the branches whilst 3.X is arranged in >> rawhide has decent justification... but I'll wait on what to do with that >> after a discussion with upstream. >> >> >> > I've also not looked fully into the EPEL situation but from an initial >> > cursory look of gemfiles I think the ruby versions there are out of >> > their support matrix. >> >> Well, there is still just Ruby 1.8.7 in EPEL6 and these are rather old >> and incompatible (mainly due to encoding support and character >> handling). It should be better in EPEL7 with Ruby 2.0.0. Upstreams tends >> to drop official support for older Rubies (without any real reason >> except reducing the support matrix), but the code typically works >> (although you might need to relax some dependencies). >> >> One thing to always consider is the dependency chain, including the >> build dependencies ... >> >> >> Yeah this is another package that's just going to be left at an old >> version in EPEL6 I fear... I really wish we could link to Red Hat SCL >> packages for these situations... but oh well. Since my only direction/goal >> I this endeavour is the removal is the requirement of net-tools, and >> that's only Fedora, I'm not going to worry about it for now. >> >> >> > Hi guys, > > Here's a status update for this change. > > I have a Facter 3.9.0 package I'm happy with on initial testing. I'll be > writing up a F28 self contained change shortly. I've tested puppet in F26 > against this and it appears to behave correctly - would appreciate more > eyes on it though. > > I'm having issues with cmake3 in EPEL7 not picking up the cmake files from > the leatherman package preventing me from building there - so that will > stay on 2.5.X for now, similar to F26 and F27 will be updated shortly > staying within the 2.5.X series for compatibilty concerns. > > If you'd like to test the facter 3.9.0 packages this COPR can be used: > > https://copr.fedorainfracloud.org/coprs/jhogarth/facter3/ > > We'll need to coordinate on the F28 package so puppet can depend on > ruby-facter instead of facter ... I'll do a repoquery to see if I can > locate any similar packages using the ruby bindings as well. > > Cheers, > > James > > To keep the ruby sig and relevant package owners/reviewers in the loop ... the change for Facter3 in F28 has been approved. https://pagure.io/fesco/issue/1767#comment-472520 I'll get the boost-nowide review request in over the weekend, which will unblock leatherman and cpp-hocon can then be submitted as well. The initial spec files that need a final tuning for submission, and which were used for the COPR, can be found here: https://jhogarth.fedorapeople.org/facter3/ We've got plenty of time according to the schedule but it'd be nice to get this resolved in rawhide sooner rather than later :) https://fedoraproject.org/wiki/Releases/28/Schedule James
_______________________________________________ ruby-sig mailing list -- [email protected] To unsubscribe send an email to [email protected]
