[PATCH/puppet 1/1] [#4313] removed 1.8.1 workaround preventing fact compression

[Marc Fournier]

2 workarounds for yaml issues with ruby 1.8.1 where added to
this file:
* 1c69af2 - Dec 3 2009
* e8bce7a - Oct 24 2009

e44430b (Mar 22 2010) completely circumvents the yaml library
bundled with ruby, which solves the yaml issues with 1.8.1.

This patch removes the code preventing fact compression with
ruby 1.8.1.

Signed-off-by: Marc Fournier <marc.f...@camptocamp.com>
---
lib/puppet/network/formats.rb | 6 ++----
1 files changed, 2 insertions(+), 4 deletions(-)

diff --git a/lib/puppet/network/formats.rb b/lib/puppet/network/formats.rb
index a98dcbc..24c7b53 100644
--- a/lib/puppet/network/formats.rb
+++ b/lib/puppet/network/formats.rb
@@ -26,9 +26,8 @@ Puppet::Network::FormatHandler.create(:yaml, :mime => "text/yaml") do
yaml
end

- # Everything's supported unless you're on 1.8.1
def supported?(klass)
- RUBY_VERSION != '1.8.1'
+ true
end

# fixup invalid yaml as per:
@@ -79,9 +78,8 @@ Puppet::Network::FormatHandler.create(:b64_zlib_yaml, :mime => "text/b64_zlib_ya
yaml
end

- # Because of yaml issue in ruby 1.8.1...
def supported?(klass)
- RUBY_VERSION != '1.8.1' and use_zlib?
+ use_zlib?
end

# fixup invalid yaml as per:
--
1.7.1

[Jesse A Wolfe]

+1. I could have sworn we had already caught these, but I guess not.

> --
> You received this message because you are subscribed to the Google Groups "Puppet Developers" group.
> To post to this group, send email to puppe...@googlegroups.com.
> To unsubscribe from this group, send email to puppet-dev+...@googlegroups.com.
> For more options, visit this group at http://groups.google.com/group/puppet-dev?hl=en.
>
>

[Markus]

> +1. I could have sworn we had already caught these, but I guess not.

If you're crazy, we both are. I'd also swear we fixed them.

-- Markus

[Marc Fournier]

> > +1. I could have sworn we had already caught these, but I guess not.
>
> If you're crazy, we both are. I'd also swear we fixed them.

Well it seems nobody is crazy in fact. It indeed got removed by Jesse
in dc1a977, which is only in the branch called "next".

This makes me wonder how the 0.25.x and older branches relate with the
"next" branch ?

It would be nice if bugs fixed in one branch get applied to the other
relevant ones. Easier said than done, I can imagine :-) Shouldn't there
be a way in redmine to indicate that an issue affects several branches ?

By the way, is it planned to rename the "next" branch to something like
"2.6.x" now that 2.6.0 is released ?

Cheers,
Marc

[Jesse A Wolfe]

That's ... even stranger. I'm sure that I've only merged changes into "next" from the "0.25.x" and "master" branches.

And it looks to me that my patch successfully made it into the 2.6.0 release. What version are you patching against, Marc?

As of today, "2.6.x" exists as a fork of "master"
"next" will become a staging zone for commits that will eventually their way into "master" which will eventually become the next major release ("statler" or "2.7.0" or "27.0")

~Jesse

[Marc Fournier]

On Thu, 22 Jul 2010 17:36:32 -0700
Jesse A Wolfe <jes...@gmail.com> wrote:

> That's ... even stranger. I'm sure that I've only merged changes into
> "next" from the "0.25.x" and "master" branches.
>
> And it looks to me that my patch successfully made it into the 2.6.0
> release. What version are you patching against, Marc?

I hit bug #2668 on a node with 0.25.5 from the EPEL repository. I
considered the issue only partly related so I created #4313 instead of
reopening #2668.

My patch was done on top of
http://github.com/reductivelabs/puppet/tree/0.25.x

From what I understand scrolling through gitk, dc1a977 got applied to
the "next" branch, which of course didn't get merged into "0.25.x".

Maybe would it be better to apply dc1a977 to the "0.25.x" branch using
git-cherry-pick and drop my patch ?

> As of today, "2.6.x" exists as a fork of "master"
> "next" will become a staging zone for commits that will eventually
> their way into "master" which will eventually become the next major
> release ("statler" or "2.7.0" or "27.0")

Nice, that makes things more consistent with pre-2.6 times :-)

Cheers,
Marc

[Marc Fournier]

> Maybe would it be better to apply dc1a977 to the "0.25.x" branch using
> git-cherry-pick and drop my patch ?

Well it appears this patch applies cleanly to the "0.25.x" branch, and
solves the problem too (facts get compressed when sent to the server
even with ruby 1.8.1)

Marc