>
>
> Is there a specific reason why uniqueness_key should be a SORTED list of
> keyattributes? If we do not sort them they appear in the array in the
> same order as the params were defined in the type definition (so the
> order is still determined) [By type definition I mean the ruby source,
> no
We're squashing the following changes into this commit to
1) fix a failing spec
2) add some more behavior-driven tests into the specs
Otherwise, +1
diff --git a/spec/unit/provider/user/user_role_add_spec.rb
b/spec/unit/provider/user/user_role_add_spec.rb
index 9cf6492..f739423 100644
--- a/spec/u
> What I don't understand is where my logic has gone wrong and why Daniel's
> proposal is preferred.
>
The logic is fine, but:
1) We've got some learned skittishness on relying on mocha for this
sort of thing
2) If your problem is that you're over-catching exceptions, raising an
exception when you
> Sure, but Puppet doesn't actually have numbers - it's just that some of its
> strings happen to consist entirely of digits.
>
Suddenly this whole conversation makes much more sense.
... but some of the Type code suddenly makes much less sense.
>
> On Feb 17, 2011, a
Coincidentally, I found this in the JSON spec:
"Numbers are not quoted. It would be insane to require quotes around
numbers." - http://www.json.org/fatfree.html
On Thu, Feb 17, 2011 at 3:23 PM, Luke Kanies wrote:
> On Feb 17, 2011, at 3:22 PM, Paul Berry wrote:
>
> On Thu, Feb 17, 2011 at 3:17 P
>
>> Proposal here is that Package <| |> would realize, but Package <| |> { }
>> wouldn't.
>>
>
>
And - while I'm going to try not to derail this conversation - I'd like
whatever syntax we come up with to be reasonable to extend to searching
other authorities (storeconfigs, the "catalog service", m
>
>
> Proposal here is that Package <| |> would realize, but Package <| |> { }
> wouldn't.
>
What about passing a collection to a function?
foo( <| search=whatever |> {} )
seems like penalizing a common case.
> Could we add the ability to query whether a given resource has
>> been realized or n
Everything in "lib/puppet/util/command_line" should be gone in Statler (I've
already committed a patch to `next` that moves it.) The rest of the dev team
convinced me that it was too big of a change to shoehorn into the 2.6.x
series.
I'm happy to see the rdoc/usage dependency go away in Statler, th
> What's the behavior with this patch when checksum=none and specifying a
> source or content? How does the system compare the current file to the
> desired file?
>
It overwrites the file every time. That might not be the most desirable
behavior, but it's more correct than *truncating* the file e
>
> Um, gack. You could do it with replication instead of shifts with
>> something like:
>>
>> rights = ((old_mode & 0777 & who_masks[what_letter]) * 011) >> 9
>> value = rights & 0777 & who_masks[who_letter]
>>
>>
>
(oops, hit send by mistake)
Gack! That seems overly clever.
Maybe som
> Um, gack. You could do it with replication instead of shifts with
> something like:
>
> rights = ((old_mode & 0777 & who_masks[what_letter]) * 011) >> 9
> value = rights & 0777 & who_masks[who_letter]
>
>
>
> rights = ((old_mode & who_masks[what_letter]) * 011) >> 9
>
As I recall, the old code was doing backflips to make sure that Integer( x )
always got a string with a leading zero, and I bet I just got too absorbed
into that codepath to remember that there was a better way.
On Oct 26, 2010 6:05 PM, "Markus Roberts" wrote:
--
You received this message becaus
+1
On Wed, Oct 20, 2010 at 11:38 AM, Markus Roberts wrote:
> The currious part is that this wasn't noticed before since it appears to
> block
> server-first migration to 2.6.x and doesn’t appear to be the consequence of
> a
> recent (2.6.3) change (unless, as is quite possible, I’m missing
> som
+1
On Wed, Oct 20, 2010 at 10:28 AM, Markus Roberts wrote:
>
>
> Did this code change? It looks exactly the same to me.
>
>
> Yes, it did. I have no idea why the changes didn't come through in the
> email (I probably goofed something up when I did "rake mail_patches" but
> offhand I can't say wh
>"foo/
>bar"
>
>
It took me a minute to figure out what you were talking about, since the
slash in your commit message should really be a backslash
> +%Q{"string with an escaped '\\\n'"} =>
> [[:STRING,"string with an escaped ''"]],
>
Can we get something
+1
On Mon, Oct 18, 2010 at 1:29 PM, Paul Berry wrote:
> On Tue, Oct 12, 2010 at 3:21 PM, Paul Berry wrote:
>
>> On Tue, Oct 12, 2010 at 12:46 PM, Jesse A Wolfe wrote:
>>
>>> # Make an instance of our resource type. This is only possible
>>>> # for
+1
On Fri, Oct 15, 2010 at 12:44 PM, Markus Roberts wrote:
> This is based on the discussion on ticket, simplified slightly and with
> test
> adjustment.
>
> Signed-off-by: Markus Roberts
> ---
> lib/puppet/provider/mount.rb |2 +-
> spec/unit/provider/mount_spec.rb |9 -
>
+1
On Oct 7, 2010 5:12 PM, "Markus Roberts" wrote:
> Volumes that don't suport SELinux should be considered in_sync so they
don't
> generate spurious change notice.
>
> Patch from Darrell Fuhriman
>
> Signed-off-by: Markus Roberts
> ---
> lib/puppet/type/file/selcontext.rb | 8 ++--
> 1 files
+1. I don't love the looking-for-id section, but I can't think of another
way to do it.
On Mon, Oct 11, 2010 at 3:58 PM, Nigel Kersten wrote:
>
> Signed-off-by: Nigel Kersten
> ---
> .../provider/nameservice/directoryservice.rb | 34
> +++-
> 1 files changed, 33 inserti
+1. I had some style quibbles but I've talked myself out of them.
On Mon, Oct 11, 2010 at 9:28 PM, Markus Roberts wrote:
> This is intended to be a minimal fix, with tests, to prevent chage from
> running
> unless needed.
>
> Signed-off-by: Markus Roberts
> ---
> lib/puppet/provider/nameservic
>
> Hmm, the number of people chiming in on this topic is making me wonder
> whether we are barking up the wrong tree with lexical scoping. If people
> don't need for variables and resource defaults defined in a class to take
> effect in contained classes, then there's no sense in our going to ext
> Well, inheriting doesn't work with parameterized classes at all right now,
> because of bug 4534 :)
>
>
After #4534, I believe we'll be in the state that you'll be able to do this:
class parametrized($param) inherits nonparametrized {
}
but the reverse is still not well defined:
class nonpara
> +if resource.resource_type.is_a? Puppet::Resource::Type
> + resource.resource_type.instantiate_resource(scope, resource)
> +else
> + scope.compiler.add_resource(scope, resource)
> +end
>
I don't like this one. Can we use duck typing here instead of testi
Nigel:
> construct as I've never been clear on the implications and just keep
>
all classes in their own files.
>
>
RI:
>
> you'd kind of want to think that variables in A should be available in B by
> looking at the code but that's just not the case and writing out these
> classes
> long hand ma
+1
On Mon, Oct 11, 2010 at 9:42 PM, Markus Roberts wrote:
> This fixes the command / option issues of #4963 as suggested on the ticket;
> the
> setting-expiry when not needed aspects are deferred to #4975.
>
> Signed-off-by: Markus Roberts
> ---
> lib/puppet/provider/user/user_role_add.rb
>
> Single inheritance is already confusing enough and it's used primarily for
> resource overrides and not scoping.
>
>
What I heard above is: people need resource defaults from multiple classes.
We could call the first one "inheritance" and the subsequent ones "mixins",
the way ruby does, but I t
+1
On Fri, Oct 1, 2010 at 7:24 PM, James Turnbull wrote:
> /usr/lib/ruby/site_ruby/1.8/puppet/util/metric.rb:62: warning: parenthesize
> argument(s) for future version
>
> Signed-off-by: James Turnbull
> ---
> lib/puppet/util/metric.rb |2 +-
> 1 files changed, 1 insertions(+), 1 deletions(
> I have no idea what your concern is here. I wasn't proposing eliminating
> any such tests or folding them in anywhere.
>
Not stating a concern, just trying to reason out the unspoken part of your
suggestion, which wasn't immediately obvious to me.
> Ah, but you weren't burned by it, you just
+1 !
On Thu, Sep 30, 2010 at 7:52 AM, Paul Berry wrote:
> The evaluate_definitions method was first figuring out which resources
> needed to be evaluated (using unevaluated_resources), and then
> evaluating them one by one. As a result, if evaluating one resource
> triggered another resource to
Yeah, I should probably extract that conditional into a method.
I wanted to write it in such a way that someone looking at the diffs would
have no doubt that this was just a mechanical merge between the two versions
of the code.
anyway, I expect that we'll probably drop support for the old bindings
+1
I'm looking forward to a cleaner solution for 2.7.x
On Mon, Sep 27, 2010 at 3:25 PM, Nick Lewis wrote:
> Whits are inserted into the dependency graph in the place where an empty
> class is being required. Unfortunately, when such a class is involved in
> a loop, the error message shows the cy
+1
On Thu, Sep 23, 2010 at 5:15 PM, Matt Robinson wrote:
> The code made assumptions about report structure that weren't valid for
> 2.6.x. The change has been verified to work with 0.25.x and 2.6.x
> report formats.
>
> Paired with: Rein Henrichs
>
> Signed-off-by: Matt Robinson
> ---
> lib/
+1 as a pair-er.
On Wed, Sep 22, 2010 at 2:35 PM, Paul Berry wrote:
> The global "-o" option ("--onetime") was overriding the
> application-specific option "-o" because global options were being
> sent to the OptionParser after application-specific options.
>
> Modified the order in which option
> Wow, I could have sworn Jesse told me it was our convention.
I did - I really thought that the [#] convention had been unanimously
approved. My mistake.
--
You received this message because you are subscribed to the Google Groups
"Puppet Developers" group.
To post to this group, send ema
+1
On Fri, Sep 17, 2010 at 4:51 PM, Paul Berry wrote:
> The :undef symbol, which we use internally to distinguish between
> undefined variables and variables whose value is the empty string, is
> being leaked in calls to functions (e.g. "split"). This is a
> departure from 0.25.x behavior, wher
>
> Isn't this already opened as a ticket?
> I know I've taken at least one stab at it, although I don't appear to have
> ever committed anything.
>
I thought it was likely to be a ticket, but searching redmine didn't turn up
anything.
--
You received this message because you are subscribed to
> On 9/16/2010 11:32 AM, Peter Meier wrote:
>
>> Personally I think that the grouping issue is much more important and
>> would provide the basis on which we could build a faster automatic
>> dependency resolution. I simply don't see the importance of the proposed
>> feature over the grouping one.
> Can we have more information or pointer on said algorithm?
> (It's possible it was discussed here and I missed the thread).
>
> I'll have to direct this question over to Markus. I've seen him sketch it
on a whiteboard, but I'm not sure it's been capture sufficiently outside his
head.
--
You rec
>
> So basically, you can see that the params aren't including the facts, and
> this is a problem with the run_mode, which I don't quite understand. Jesse
> Wolfe should be able to help with that, I think, and once you've got that
> sorted you should be all set.
>
>
Basically the run_mode is an ab
+1, this makes sense to me.
On Fri, Sep 10, 2010 at 6:22 PM, Markus Roberts wrote:
> This restricts the change introduced in #4691 to hostclasses, and leaves
> defined
> resources and nodes alone, thus more closely mimicing the 0.25.x behaviour.
> It
> also includes title, as this was similarly
I'm going to +1 this under the rationale that since it's *deterministic*
such that someone changes the test data such that the test fails, it will
fail immediately and the comment will explain what went wrong.
On Wed, Sep 1, 2010 at 10:45 AM, Markus Roberts wrote:
> +0.85 This does the job, but i
+1
On Mon, Aug 23, 2010 at 8:55 AM, Paul Berry wrote:
> The ZAML class was using class variables to keep track of labels and
> backreferences while serializing object to YAML. This made it
> possible to get ill-formed or incorrect YAML output if two threads
> tried to serialize objects at the s
oof. well, at least "apply" is easier to search&replace on than "puppet"
+1
On Sat, Aug 21, 2010 at 8:12 PM, Markus Roberts wrote:
> Basing pervasive low-level behaviour changes on the application name isn't
> a
> good idea, but if we're going to do it we need to remember to update the
> test
>
+1
On Fri, Aug 13, 2010 at 4:13 PM, Paul Berry wrote:
> This change is part of an ongoing effort to remove functionality from
> TypeCollection that is not related to keeping track of a collection of
> types. This reduces TypeCollection's linkage to the environment,
> which is a step toward deco
Wait, oops. Version is failing a "rake unit" test ... it looks like we were
relying on the TypeCollection object getting replaced when the .pp files
were altered.
This patch prevents the version number from being incremented.
On Thu, Aug 12, 2010 at 3:05 PM, Jesse A Wolfe wrote:
+1 (as a partial pairing partner)
On Thu, Aug 12, 2010 at 2:10 PM, Paul Berry wrote:
> This change is part of an ongoing effort to remove functionality from
> TypeCollection that is not related to keeping track of a collection of
> types. This reduces TypeCollection's linkage to the environment
>
> In looking at that patch, it still looks like resources will be created as
> Type[type], rather than Class[type]. Have you tested that relationships to
> class resources still works with this code?
>
>
I don't see how that could be true, when:
case type.downcase
> when "class"
>
>> + resource_type = scope.find_resource_type(type)
>> resource_titles.flatten.collect { |resource_title|
>> exceptwrap :type => Puppet::ParseError do
>> -
>> - resource = Puppet::Parser::Resource.new(
>> - type, resource_title,
>> + resource = Puppet::Parser::
Xavier,
#4224 is a proposed change. It has not been shipped with 2.6.0 - in fact, no
code has been written for that ticket.
Looking at the code, it seems that puppet master should always be using
/etc/puppet and /var/lib/puppet , without regard to what user it is running
as.
If you are seeing a be
>
> extlookup_precedence = lookupvar('extlookup_precedence').collect { |s|
> s.gsub(/%\{(.+?)\}/) { lookupvar($1) } }
>
we switched from curlies to do-end after actually getting getting lost in
the {({({(/#{{ forest.
I'm strongly preferring the more verbose syntax in this case.
--
You received
+2
On Jul 26, 2010 7:37 PM, "Matt Robinson" wrote:
We found the gsub! in extlookup was actually modifying the value for
extlookup_precedence, so the next node to call it just got the
interpolated value from the first run.
We did two things in the code to prevent this:
1. We returned a dup of th
+ an infinite number of iotas, or 1, whichever is greater.
On Sat, Jul 24, 2010 at 4:42 PM, Markus Roberts wrote:
> As Brice discovered, the problem was that we simply ignored empty classes
> in
> the graph when determining application order. This patch instead replaces
> them
> with a resource
This makes more sense than anything I've seen in days.
+0..
On Sat, Jul 24, 2010 at 11:09 AM, Markus Roberts wrote:
> The first version had a typo, fixed in the second.
>
> -- Markus
> ---
> The power of a
> Don't we have to move the extlookup code into
> lib/puppet/parser/functions or something too? (I don't know the
> answer, but it seems likely).
I did!
> rename from ext/extlookup.rb
> rename to lib/puppet/parser/functions/
extlookup.rb
On Fri, Jul 23, 2010 at 2:35 PM, Markus Roberts wrote:
+1, as this is analogous to the solution that Matt Robinson found yesterday.
I'll be spending some time today trying to get this file tested enough that
we're comfortable promoting it from /ext/ to /lib/puppet/parser/functions/
~Jesse
On Fri, Jul 23, 2010 at 9:31 AM, James Turnbull wrote:
>
> S
Hrmm. There's an implicit assumption that a thread won't span environments.
In what circumstances is that assumption violated?
On Thu, Jul 22, 2010 at 8:47 PM, Markus Roberts wrote:
> -1 unfortunately.
>
> This makes known resources per-thread instead of per-environment,
> which means that we'll
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"
+1. It might be nicer if full_path didn't return a leading slash, but this
definitely seems like the safest way to fix it.
On Wed, Jul 21, 2010 at 1:58 PM, Brice Figureau <
brice-pup...@daysofwonder.com> wrote:
> We were sending an incorrect (containing a //) url for sourced file
> content since
I like this code. +1, unless someone can find a place where we're using the
same thread to compile more than one catalog.
On Thu, Jul 22, 2010 at 11:37 AM, Brice Figureau <
brice-pup...@daysofwonder.com> wrote:
> In 2.6 we moved access to loaded type to the environment.
> Each time the compiler w
+1. I could have sworn we had already caught these, but I guess not.
On Wed, Jul 21, 2010 at 5:08 AM, Marc Fournier
wrote:
> 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 circumv
Oh! I see my mistake: I keep conflating the attributes hash and the
parameters hash.
I've changed that line in my branch.
~Jesse
On Thu, Jul 15, 2010 at 9:00 PM, Markus Roberts wrote:
> > -obj = Puppet::Parser::Resource.new(hash)
> > +obj = Puppet::Parser::Resource.new(hash["type"], hash
I, unfortunately, failed to understand your code until I had rediscovered
and reimplemented the fix almost verbatim.
So it was just a difference in style between your code and mine that I used
[] when you used delete(), but
I don't think it makes any difference whether we delete "type" and "title"
The source code for that method is in the patch I posted, I think you just
missed it.
On Tue, Jul 13, 2010 at 7:06 PM, Todd Zullinger wrote:
> Jesse Wolfe wrote:
> > My previous fix for #3656 missed the case where a "require" attribute
> > (or other graph-ish attribute) had multiple values. This
+1, nice fix to my error.
On Tue, Jul 13, 2010 at 11:54 AM, Matt Robinson wrote:
> This came up because if you ran puppetd with a specific vardir, then
> when rundir got set to a hardcoded value its parent directory might not
> exist and the whole thing would fail.
>
> This change came about wit
It looks like Matt and I just missed this one case in the earlier patch.
There are actually surprisingly few calls to methods named "resources" in
the codebase; I was expecting it to be a grep nightmare.
On Sun, Jul 11, 2010 at 10:43 PM, Luke Kanies wrote:
> Is the complete fix actually this sim
Not really - if I'm remembering correctly, the non-idempotentcy of this line
was exacerbating other call-order problems. That's about as deep as I got.
On Sun, Jul 11, 2010 at 5:32 PM, Markus Roberts wrote:
> Jesse --
>
> > +1. It seems like I've smashed into this line of code three times in the
+1. It seems like I've smashed into this line of code three times in the
last week.
On Sun, Jul 11, 2010 at 12:24 PM, Markus Roberts wrote:
> This patch fixes the narrow problem of #4205, wherein type_loader would
> reparse
> a file each time it was imported (causing the parser to incorrectly th
On Sat, Jul 10, 2010 at 10:08 AM, Markus Roberts wrote:
> After mulling this a while, I think the real issue is that we're
> treating ensure as an attribute-set rather than as an attribute. It's
> a magic feature that semantically sets a whole slew of features. When
> we say "ensure => present"
> Basically, 'ensure' trumps everything - if it's out of sync, nothing else
> really matters.
In cases where ensure is absent/present, this holds. But if you've got
other options (changing a service from "stopped" to "running", for
example), then you may still care about other changes on the resou
Not a bug for 2.6, I believe. Perhaps needs-design-decision for later.
On Jul 7, 2010 11:11 AM, "Markus Roberts" wrote:
So does that make #4111 not-a-bug or?
-- Markus
--
You received this message because you are subscribed to the Google Groups
"Puppet Developers" group
--
You recei
The answer is: we get a lot more events. It looks like this was
intentional, to not behave this way.
On Wed, Jul 7, 2010 at 10:36 AM, Jesse Wolfe wrote:
> If "ensure" changes, then no other changes are logged for that resource.
> I'm not sure why this special case is here. If I remove it, like so
If we fix the Hash#count to something that exists on old rubies, I'll
happily +1 this.
On Tue, Jul 6, 2010 at 2:06 PM, Nick Lewis wrote:
> Apologies, this is actually for ticket #4114. I've amended the commit message.
>
> On Jul 6, 2010, at 1:36 PM, Nick Lewis wrote:
>
>> The log will now queue a
I meant to say: the other patch supersedes this one, on Markus's suggestion.
So I give it a -1.
On Tue, Jul 6, 2010 at 6:21 PM, Luke Kanies wrote:
> The reason I didn't do this is because it makes it tough to test the
> class in isolation - every instance effectively becomes global.
>
> I can see
> Isn't this the same as calling Env.new with no arguments?
Probably.
--
You received this message because you are subscribed to the Google Groups
"Puppet Developers" group.
To post to this group, send email to puppet-...@googlegroups.com.
To unsubscribe from this group, send email to
puppet-d
+1, I've certainly been bitten by this.
an executable that fails because you're in the wrong directory feels
brittle, and I'm in favor of any change that makes the tests less likely to
fail for surprising reasons.
(an alternate suggestion would be to have spec_helper make sure the working
directory
+1. I see where I made a mistake trying to reproduce it. But, yep, that's
how it works.
On Fri, Jun 11, 2010 at 7:17 PM, Markus Roberts wrote:
>
>
> On Tue, Jun 8, 2010 at 1:11 PM, Jesse A Wolfe wrote:
> > This is begging for a test case. I either don't understand what
+1, I like the way it finally came together
On Jun 11, 2010 4:10 PM, "Markus Roberts" wrote:
Jesse and I are shooting for the minimal viable fix here, with the idea that
a great deal of refactoring is needed but isn't appropriate at this time.
The
changes in this commit are:
* Index the functi
This is begging for a test case. I either don't understand what you're
saying Syck will do, or I can't reproduce it.
~Jesse
On Mon, Jun 7, 2010 at 1:56 PM, Markus Roberts wrote:
> Syck/Yaml quietly passes on undefined classes as strings, so that if
> objects
> of those classes are loaded and re-
r generate
broken YAML, we don't need fixup().
~Jesse
On Tue, May 25, 2010 at 9:16 PM, Ohad Levy wrote:
> What about cases where the client does not use zaml yet (e.g. old 0.24.x
> clients)? will that introduce any new compatibility problems?
>
> Ohad
>
> On Wed, May 26
Yes.
On Tue, May 25, 2010 at 6:47 PM, Ohad Levy wrote:
>
>
> On Wed, May 26, 2010 at 6:17 AM, Jesse Wolfe wrote:
>
>> Remove workarounds that were only needed because ruby's builtin YAML
>> lib is broken.
>>
> Hi,
>
> Why is this being removed? is it because of the introduction of zaml?
>
> Oha
+1 as the pair-er
but I'd be happy to hear suggestions of if there's something we could have
written a unit test for in here.
On Tue, May 25, 2010 at 6:02 PM, Matt Robinson wrote:
> The user method on the provider always returned what the resource should
> be, not what it actually was, so it alw
On Fri, May 21, 2010 at 9:44 PM, Markus Roberts wrote:
> +1, with two comments:
>
> >end
>
>> eachsection do |section|
>> persection(section) do |obj|
>> +next if ReadOnly.include? obj.name
>> str += obj.to_config + "\n"
>> en
I started to change "load", too, but then I waffled - it was unclear if it
there were any cases where I wouldn't just be wrapping it in a rescue
I'll give another stab at it.
On Fri, May 21, 2010 at 5:02 PM, Luke Kanies wrote:
> This is only half of the battle - you need to change the 'load' met
+1, then.
On Fri, May 21, 2010 at 2:22 PM, Luke Kanies wrote:
> Fixed in code - not worth pushing again, I assume.
>
> On May 21, 2010, at 2:19 PM, Jesse A Wolfe wrote:
>
> +0.9, with the last 0.1 if you fix the rspec docstring to have the right
> setting name
>
> (I gu
+0.9, with the last 0.1 if you fix the rspec docstring to have the right
setting name
(I guess "main" is a reserved word? I'm slightly surprised by that)
On Wed, May 19, 2010 at 11:45 PM, Luke Kanies wrote:
> This disables adding any code to 'main' except
> in site.pp, so if you have code outsi
+1, pretty straightforward
On Wed, May 19, 2010 at 11:46 PM, Luke Kanies wrote:
> This allows you to create builtin nested resource types
> that generate other resources that generate other resources
> ad naseum.
>
> The primary point of this feature is that you can make
> builtin resource types
+1, this patch is giving me deja vu
On Tue, May 18, 2010 at 5:14 PM, Matt Robinson wrote:
> OpenSuSE replaced rug with zypper so our code should too
>
> Signed-off-by: Matt Robinson
> ---
> lib/puppet/provider/package/zypper.rb |8
> 1 files changed, 4 insertions(+), 4 deletions(-
I'm going to echo Luke on this one. +1, but needs some serious
cross-platform verification before release.
On Tue, May 4, 2010 at 9:02 PM, Luke Kanies wrote:
> +1 for the testing branch, anyway.
>
> Obviously a potentially large change so needs plenty of testing.
>
>
> On May 4, 2010, at 4:10 PM
When I wrote this, I was imagining that there might be places that using a
CommandLine object would be less desirable than the singleton (module)
version. That looks like an increasingly spurious concern.
~Jesse
On Sat, May 1, 2010 at 11:29 PM, Markus Roberts wrote:
> def self.subcom
I actually did squash+unsquash my original series quite a bit (went from 29
patches to 15). I had convinced myself that leaving this one intact made
10/15 (f5aecbe) make more sense as a set of method extracts that don't
change functionality. I'm sure there's a different possible pair of patches
tha
+1
On Fri, Apr 30, 2010 at 5:38 PM, Markus Roberts wrote:
> The plussignment operator was constructing the new parameter value by
> modifying the param object's value in place (so as to preserve the file
> and line information for debugging). However, when multiple resources
> are overridden by
I started to code up an alternate implementation, but it occurred to me this
morning to check the old behavior so I could maintain back compatibility
with 0.25.x series clients.
Here's what I found:
Puppet::Resource::Reference.new("File", "/dev/null").to_pson
=> "\"File[/dev/null]\""
So, I'm going
+1 ! Until somebody implements IOScanner
On Apr 29, 2010 2:41 PM, "Markus Roberts" wrote:
It's about 10x faster to read the whole file than to read each line and
concatenate them (actually, it's O(n) vs. O(n^2), so the exact speedup
depends on the file size).
Signed-off-by: Markus Roberts
---
Yeah, that sounds reasonable. I chose a $global because it seemed analogous
to the $0 , but I was never thrilled with the idea.
Might as well move legacy_name into that class, while I'm at it.
~Jesse
On Wed, Apr 21, 2010 at 1:36 PM, Luke Kanies wrote:
> I'd be far happier with Puppet::Util::Com
Alright. I've put the change in.
On Wed, Apr 21, 2010 at 12:49 PM, Markus Roberts wrote:
> J --
>
> that doesn't feel typesafe to me, notice that my predicates are all calling
>> different methods - my impression is that it's a lucky coincidence that
>> NilClass, Regexp, and String's various ===
that doesn't feel typesafe to me, notice that my predicates are all calling
different methods - my impression is that it's a lucky coincidence that
NilClass, Regexp, and String's various === operations happen to DWIM in each
of these situations.
of course, I imagine that you'll reply that it's not
+1, clears up the problem on my ubuntu box.
On Tue, Mar 30, 2010 at 2:38 PM, Markus Roberts wrote:
> Due to a bug in Ruby 1.8.7 net/http will attempt to close a connection
> that wasn't successfully opened (it's nil), first checking to see if the
> connection is already close, and thus raising a
3 days have passed and many of these requested changes have made it into the
0.25.x branch. By my count, 0.25.5rc1 should include all of the current
0.25.x branch (fd76142), plus:
* #3396; Brice, event propagation speedup
* #3229; Brice, case/selector regex matching
* #2929; Brice, Allow checksum t
I'd like to recommend this patch to go into the upcoming 0.25.5 release.
It looks like a typo has crept into your github branch, though:
+commands :rug => "/usr/bin/zypper"
And the code below is calling "zypper" as a method - I suspect that doesn't
work (and it doesn't match your old mailing-
What I mean is, what information are you passing via the URI that you can't
> pass as options et al? The 'https' is clearly redundant, since we're always
> talking https when using REST, and the api stuff should handle converting
> the rest of the info to a URI.
>
>
The things that there's not a w
1 - 100 of 159 matches
Mail list logo
