On 30 October 2017 at 11:50, Gaël Chamoulaud gchamoul@redhat.com wrote:
On 25/Oct/2017 15:22, James Hogarth wrote:
On 13 October 2017 at 20:49, James Hogarth james.hogarth@gmail.com wrote:
On 4 October 2017 at 15:16, James Hogarth james.hogarth@gmail.com wrote:
On 5 September 2017 at 08:15, James Hogarth james.hogarth@gmail.com wrote:
On 5 Sep 2017 8:05 am, "Vít Ondruch" vondruch@redhat.com 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
Hi guys,
Further update for this update ;)
General stuff
The work of Denis Arnaud has got boost157 packaged as an option in EPEL (as of a few minutes or so when I approve the package review).
The boost-nowide dependency has it's own review and has been tested in both F27 and F26 as well as with the boost157 package to build leatherman, and packages further down the tree.
https://bugzilla.redhat.com/show_bug.cgi?id=1502584
The leatherman spec in my fedorapeople space was used to build the version in the COPR with cpp-hocon using that leatherman package to build and facter3 using that to build/run.
https://jhogarth.fedorapeople.org/facter3/
https://copr.fedorainfracloud.org/coprs/jhogarth/facter3/
I've not submitted the cpp-hocon review yet as it's dependent on the boost-nowide one anyway.
Obviously as you can see in the COPR the new facter 3 builds fine in EPEL7 and Fedora with the boost157 package and these two dependencies in place.
This is all fine for Fedora and puts us in a great place to get this all into place in plenty of time before F28 even branches.
Note that although I've built facter3 in the COPR for EPEL7 (using that boost157 package) and facter itself works fine ... the older puppet in EPEL (3.6.2 in EPEL7) is not compatible with the more recent facter.
I'm not sure exactly yet where the specific breakage happens and haven't had time to dig through all the old puppet release notes to see where the facter compatibility changes.
Does the Ruby-SIG have any plans to get puppet updated in EPEL7? If so we can get the new facter there too ... if not we'll need to hold back and I'm not even sure if the 2.5.X releases of facter would be compatible.
Specific questions to people
Haikel, have you had time to review the changes to the leatherman spec and patches proposed to bring your review up to date? Do you have time to finish through on that review once the boost-nowide module is approved?
Gaël, are you happy remaining POC or would you prefer I get any bug reports after we push facter3 out?
Hi James,
A big sorry about the slow reactivity from my part!
I think I've been promoted to POC since the new fedora sources web application, and I appreciate you request to take over it.
Vit, are you okay to adjust the puppet dependency in fedora to ruby-facter once we get the dependencies built or would you prefer I coordinate that change with the facter update as a Proven Packager?
Thanks for all you help and time guys,
James
With Gratitude,
Gaël
Hey no worries and thanks :)
FYI everything is aligned now so as soon as Haikel has done his leatherman build in rawhide I'll be building Facter 3 there.
Hi guys,
This is now complete.
I've done the puppet build in rawhide to use the ruby-facter dependency instead.
I'm not doing an update in EPEL7, as it will build and work on that platform with the updated boost available, as it appears at least puppet4 is needed to be compatible with current facter.
If the ruby-sig updates puppet in EPEL7 then I'll revisit that.
Kevin I've cc'd you as ansible can optionally use facter for fact gathering ... my testing is that it should be fine ... but just as a heads up ;)
I'll update the F28 change ticket shortly.
Facter no longer depends on net-tools ... yay! Next painful one is cloud-init ;)
Thanks for all your help.
James
On 30 October 2017 at 14:06, James Hogarth james.hogarth@gmail.com wrote:
On 30 October 2017 at 11:50, Gaël Chamoulaud gchamoul@redhat.com wrote:
On 25/Oct/2017 15:22, James Hogarth wrote:
On 13 October 2017 at 20:49, James Hogarth james.hogarth@gmail.com wrote:
On 4 October 2017 at 15:16, James Hogarth james.hogarth@gmail.com wrote:
On 5 September 2017 at 08:15, James Hogarth james.hogarth@gmail.com wrote:
On 5 Sep 2017 8:05 am, "Vít Ondruch" vondruch@redhat.com 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
Hi guys,
Further update for this update ;)
General stuff
The work of Denis Arnaud has got boost157 packaged as an option in EPEL (as of a few minutes or so when I approve the package review).
The boost-nowide dependency has it's own review and has been tested in both F27 and F26 as well as with the boost157 package to build leatherman, and packages further down the tree.
https://bugzilla.redhat.com/show_bug.cgi?id=1502584
The leatherman spec in my fedorapeople space was used to build the version in the COPR with cpp-hocon using that leatherman package to build and facter3 using that to build/run.
https://jhogarth.fedorapeople.org/facter3/
https://copr.fedorainfracloud.org/coprs/jhogarth/facter3/
I've not submitted the cpp-hocon review yet as it's dependent on the boost-nowide one anyway.
Obviously as you can see in the COPR the new facter 3 builds fine in EPEL7 and Fedora with the boost157 package and these two dependencies in place.
This is all fine for Fedora and puts us in a great place to get this all into place in plenty of time before F28 even branches.
Note that although I've built facter3 in the COPR for EPEL7 (using that boost157 package) and facter itself works fine ... the older puppet in EPEL (3.6.2 in EPEL7) is not compatible with the more recent facter.
I'm not sure exactly yet where the specific breakage happens and haven't had time to dig through all the old puppet release notes to see where the facter compatibility changes.
Does the Ruby-SIG have any plans to get puppet updated in EPEL7? If so we can get the new facter there too ... if not we'll need to hold back and I'm not even sure if the 2.5.X releases of facter would be compatible.
Specific questions to people
Haikel, have you had time to review the changes to the leatherman spec and patches proposed to bring your review up to date? Do you have time to finish through on that review once the boost-nowide module is approved?
Gaël, are you happy remaining POC or would you prefer I get any bug reports after we push facter3 out?
Hi James,
A big sorry about the slow reactivity from my part!
I think I've been promoted to POC since the new fedora sources web application, and I appreciate you request to take over it.
Vit, are you okay to adjust the puppet dependency in fedora to ruby-facter once we get the dependencies built or would you prefer I coordinate that change with the facter update as a Proven Packager?
Thanks for all you help and time guys,
James
With Gratitude,
Gaël
Hey no worries and thanks :)
FYI everything is aligned now so as soon as Haikel has done his leatherman build in rawhide I'll be building Facter 3 there.
ruby-sig@lists.fedoraproject.org
-
James Hogarth