[Puppet - Bug #19153] service puppet ensure stopped kills off cron-run puppet with Caught TERM; calling stop
Issue #19153 has been updated by R.I. Pienaar.
you can just run the daemon and the mcollective agent will signal it to wake up.
But then you can never add any custom arguments like noop or disable schedules
etc - and thats what #7273 is about, though adding signals is hardly optimal
I'd rather see a control socket or something where you can do various
interactions but whatever that's not for this ticket.
Bug #19153: service puppet ensure stopped kills off cron-run puppet with
Caught TERM; calling stop
https://projects.puppetlabs.com/issues/19153#change-84592
Author: Jo Rhett
Status: Needs More Information
Priority: Urgent
Assignee: Jo Rhett
Category: agent
Target version: 3.1.1
Affected Puppet version: 3.1.0
Keywords:
Branch:
We have recently switched from puppet agent in daemon mode (for kick) to
cron-run puppet with mcollective agent. However, I started noticing that puppet
policies were being inconsistently applied across the hosts. It turns out that
this policy is the problem:
pre
service { 'puppet':
ensure = stopped,
enable = false,
require = File['/etc/cron.d/puppet','/etc/puppet/puppet.conf'],
}
/pre
I have checked and confirmed that the puppet init script returns the correct
response even when puppet is running. If I run puppet agent --test in one
window and while it is running I run this in the other window, it shows clear:
pre
root@sj2-noc01 ~$ service puppet status ; echo $?
puppet is stopped
3
/pre
However, if I run puppet in a silent mode with --onetime and --no-daemon then
the init script returns this value
pre
root@sj2-noc01 ~$ service puppet status ; echo $?
puppet (pid 30406) is running...
0
/pre
This causes it to kill itself off, and not finish the run. Due to the
semi-random nature of ordering, this happens near the end or near the beginning
of the puppet run on different hosts. (there are few dependancies on the puppet
module, so its order in the manifest is random from host to host)
This is clearly a major flaw. We need the above policy to ensure that no puppet
daemons are running, however it interferes with the cron-run instance. However
it is handled properly when run verbosely with test.
Environment is a mixture of CentOS 5 6.
--
You have received this notification because you have either subscribed to it,
or are involved in it.
To change your notification preferences, please click here:
http://projects.puppetlabs.com/my/account
--
You received this message because you are subscribed to the Google Groups
Puppet Bugs group.
To unsubscribe from this group and stop receiving emails from it, send an email
to puppet-bugs+unsubscr...@googlegroups.com.
To post to this group, send email to puppet-bugs@googlegroups.com.
Visit this group at http://groups.google.com/group/puppet-bugs?hl=en.
For more options, visit https://groups.google.com/groups/opt_out.
[Puppet - Bug #19153] service puppet ensure stopped kills off cron-run puppet with Caught TERM; calling stop
Issue #19153 has been updated by Jo Rhett.
Eh. The memory problems in puppet daemon have never been solved. I grow tired
of 800mb and larger puppet daemons. That's why we want to run from cron.
Bug #19153: service puppet ensure stopped kills off cron-run puppet with
Caught TERM; calling stop
https://projects.puppetlabs.com/issues/19153#change-84593
Author: Jo Rhett
Status: Needs More Information
Priority: Urgent
Assignee: Jo Rhett
Category: agent
Target version: 3.1.1
Affected Puppet version: 3.1.0
Keywords:
Branch:
We have recently switched from puppet agent in daemon mode (for kick) to
cron-run puppet with mcollective agent. However, I started noticing that puppet
policies were being inconsistently applied across the hosts. It turns out that
this policy is the problem:
pre
service { 'puppet':
ensure = stopped,
enable = false,
require = File['/etc/cron.d/puppet','/etc/puppet/puppet.conf'],
}
/pre
I have checked and confirmed that the puppet init script returns the correct
response even when puppet is running. If I run puppet agent --test in one
window and while it is running I run this in the other window, it shows clear:
pre
root@sj2-noc01 ~$ service puppet status ; echo $?
puppet is stopped
3
/pre
However, if I run puppet in a silent mode with --onetime and --no-daemon then
the init script returns this value
pre
root@sj2-noc01 ~$ service puppet status ; echo $?
puppet (pid 30406) is running...
0
/pre
This causes it to kill itself off, and not finish the run. Due to the
semi-random nature of ordering, this happens near the end or near the beginning
of the puppet run on different hosts. (there are few dependancies on the puppet
module, so its order in the manifest is random from host to host)
This is clearly a major flaw. We need the above policy to ensure that no puppet
daemons are running, however it interferes with the cron-run instance. However
it is handled properly when run verbosely with test.
Environment is a mixture of CentOS 5 6.
--
You have received this notification because you have either subscribed to it,
or are involved in it.
To change your notification preferences, please click here:
http://projects.puppetlabs.com/my/account
--
You received this message because you are subscribed to the Google Groups
Puppet Bugs group.
To unsubscribe from this group and stop receiving emails from it, send an email
to puppet-bugs+unsubscr...@googlegroups.com.
To post to this group, send email to puppet-bugs@googlegroups.com.
Visit this group at http://groups.google.com/group/puppet-bugs?hl=en.
For more options, visit https://groups.google.com/groups/opt_out.
[Puppet - Bug #19153] service puppet ensure stopped kills off cron-run puppet with Caught TERM; calling stop
Issue #19153 has been updated by R.I. Pienaar.
recent puppets have actually improved a lot - they fork a runner whch exits,
memory bloat is in this runner
pre
root 2118 0.8 11.2 128628 42000 ?Ss 09:53 0:00 /usr/bin/ruby
/usr/bin/puppet agent
root 2121 5.8 13.1 150836 48968 ?Sl 09:53 0:00 puppet agent:
applying configurat
/pre
That's fine and all - but we need to be able to influence the next runs settings
Bug #19153: service puppet ensure stopped kills off cron-run puppet with
Caught TERM; calling stop
https://projects.puppetlabs.com/issues/19153#change-84594
Author: Jo Rhett
Status: Needs More Information
Priority: Urgent
Assignee: Jo Rhett
Category: agent
Target version: 3.1.1
Affected Puppet version: 3.1.0
Keywords:
Branch:
We have recently switched from puppet agent in daemon mode (for kick) to
cron-run puppet with mcollective agent. However, I started noticing that puppet
policies were being inconsistently applied across the hosts. It turns out that
this policy is the problem:
pre
service { 'puppet':
ensure = stopped,
enable = false,
require = File['/etc/cron.d/puppet','/etc/puppet/puppet.conf'],
}
/pre
I have checked and confirmed that the puppet init script returns the correct
response even when puppet is running. If I run puppet agent --test in one
window and while it is running I run this in the other window, it shows clear:
pre
root@sj2-noc01 ~$ service puppet status ; echo $?
puppet is stopped
3
/pre
However, if I run puppet in a silent mode with --onetime and --no-daemon then
the init script returns this value
pre
root@sj2-noc01 ~$ service puppet status ; echo $?
puppet (pid 30406) is running...
0
/pre
This causes it to kill itself off, and not finish the run. Due to the
semi-random nature of ordering, this happens near the end or near the beginning
of the puppet run on different hosts. (there are few dependancies on the puppet
module, so its order in the manifest is random from host to host)
This is clearly a major flaw. We need the above policy to ensure that no puppet
daemons are running, however it interferes with the cron-run instance. However
it is handled properly when run verbosely with test.
Environment is a mixture of CentOS 5 6.
--
You have received this notification because you have either subscribed to it,
or are involved in it.
To change your notification preferences, please click here:
http://projects.puppetlabs.com/my/account
--
You received this message because you are subscribed to the Google Groups
Puppet Bugs group.
To unsubscribe from this group and stop receiving emails from it, send an email
to puppet-bugs+unsubscr...@googlegroups.com.
To post to this group, send email to puppet-bugs@googlegroups.com.
Visit this group at http://groups.google.com/group/puppet-bugs?hl=en.
For more options, visit https://groups.google.com/groups/opt_out.
[Puppet - Bug #3299] owner of files created by nagios resource types
Issue #3299 has been updated by Andrew McNaughton.
If this bug is not going to be resolved, then the 'target' parameter is
severely limited. At a minimum, this shortcoming should be documented in the
notes on the 'target' parameter on each of puppet's nagios types.
Either that or just fix the thing. If people don't need the extra parameters,
they won't use them. I can't see that having an extra file resource with those
parameters is in any way preferable.
Bug #3299: owner of files created by nagios resource types
https://projects.puppetlabs.com/issues/3299#change-84596
Author: Frederic Descamps
Status: Accepted
Priority: Normal
Assignee:
Category: nagios
Target version:
Affected Puppet version: 0.25.4
Keywords:
Branch:
Currently the files are created with the permission 600 and are owned by root
it will be nice to have the possibility to change the owner and/or the
permissions of those resources
example :
pre
nagios_host{ korin:
ensure = present,
use = linux-server,
alias = korin,
address = 192.168.109.84,
hostgroups = linux-servers,
target = /etc/nagios/host_korin.cfg,
**owner = nagios**;
}
/pre
--
You have received this notification because you have either subscribed to it,
or are involved in it.
To change your notification preferences, please click here:
http://projects.puppetlabs.com/my/account
--
You received this message because you are subscribed to the Google Groups
Puppet Bugs group.
To unsubscribe from this group and stop receiving emails from it, send an email
to puppet-bugs+unsubscr...@googlegroups.com.
To post to this group, send email to puppet-bugs@googlegroups.com.
Visit this group at http://groups.google.com/group/puppet-bugs?hl=en.
For more options, visit https://groups.google.com/groups/opt_out.
[Puppet - Bug #19558] (Merged - Pending Release) Type-level validation doesn't provide information about the resource
Issue #19558 has been updated by Jeff McCune.
Status changed from In Topic Branch Pending Review to Merged - Pending Release
Assignee deleted (Dominic Cleal)
Target version set to 3.2.0
@domcleal This looks great, thank you for turning it around so quickly!
Merged into master as 6143203.
This should be released in Puppet 3.2.0.
Thanks again for the contribution!
-Jeff
Bug #19558: Type-level validation doesn't provide information about the resource
https://projects.puppetlabs.com/issues/19558#change-84611
Author: Dominic Cleal
Status: Merged - Pending Release
Priority: Normal
Assignee:
Category: error reporting
Target version: 3.2.0
Affected Puppet version:
Keywords:
Branch: https://github.com/puppetlabs/puppet/pull/1515
When validation is defined at the type level rather than a parameter,
exceptions raised don't show the resource or manifest that it originated from:
$ bin/puppet apply -e 'file { /a: content = a, source = puppet:/// }'
--trace
Error: You cannot specify more than one of content, source, target
/home/dcleal/code/puppet/puppet/lib/puppet/util/errors.rb:60:in `fail'
/home/dcleal/code/puppet/puppet/lib/puppet/type/file.rb:289:in `block (2
levels) in top (required)'
/home/dcleal/code/puppet/puppet/lib/puppet/type.rb:2198:in `initialize'
/home/dcleal/code/puppet/puppet/lib/puppet/type/file.rb:400:in `initialize'
When it fails from a parameter, it shows the resource (thanks to #16208), but
not the manifest:
$ bin/puppet apply -e 'file { /a: content = a, source = puppe:/// }'
--trace
Error: Parameter source failed on File[/a]: Cannot use URLs of type 'puppe'
as source for fileserving
/home/dcleal/code/puppet/puppet/lib/puppet/util/errors.rb:61:in `fail'
/home/dcleal/code/puppet/puppet/lib/puppet/type/file/source.rb:67:in `block
(3 levels) in module:Puppet'
/home/dcleal/code/puppet/puppet/lib/puppet/type/file/source.rb:56:in `each'
/home/dcleal/code/puppet/puppet/lib/puppet/type/file/source.rb:56:in `block
(2 levels) in module:Puppet'
/home/dcleal/code/puppet/puppet/lib/puppet/parameter.rb:450:in `validate'
/home/dcleal/code/puppet/puppet/lib/puppet/parameter.rb:485:in `value='
/home/dcleal/code/puppet/puppet/lib/puppet/type.rb:654:in `[]='
--
You have received this notification because you have either subscribed to it,
or are involved in it.
To change your notification preferences, please click here:
http://projects.puppetlabs.com/my/account
--
You received this message because you are subscribed to the Google Groups
Puppet Bugs group.
To unsubscribe from this group and stop receiving emails from it, send an email
to puppet-bugs+unsubscr...@googlegroups.com.
To post to this group, send email to puppet-bugs@googlegroups.com.
Visit this group at http://groups.google.com/group/puppet-bugs?hl=en.
For more options, visit https://groups.google.com/groups/opt_out.
[Puppet] 'Downloading Puppet' wiki page has been updated
The 'Downloading Puppet' wiki page has been updated by Moses Mendoza. Downloading Puppet: https://projects.puppetlabs.com/projects/puppet/wiki/Downloading_Puppet View differences: https://projects.puppetlabs.com/projects/puppet/wiki/Downloading_Puppet/diff/241 -- You have received this notification because you have either subscribed to it, or are involved in it. To change your notification preferences, please click here: http://projects.puppetlabs.com/my/account -- You received this message because you are subscribed to the Google Groups Puppet Bugs group. To unsubscribe from this group and stop receiving emails from it, send an email to puppet-bugs+unsubscr...@googlegroups.com. To post to this group, send email to puppet-bugs@googlegroups.com. Visit this group at http://groups.google.com/group/puppet-bugs?hl=en. For more options, visit https://groups.google.com/groups/opt_out.
[Facter] 'Wiki' wiki page has been updated
The 'Wiki' wiki page has been updated by Moses Mendoza. Wiki: https://projects.puppetlabs.com/projects/facter/wiki/Wiki View differences: https://projects.puppetlabs.com/projects/facter/wiki/Wiki/diff/60 -- You have received this notification because you have either subscribed to it, or are involved in it. To change your notification preferences, please click here: http://projects.puppetlabs.com/my/account -- You received this message because you are subscribed to the Google Groups Puppet Bugs group. To unsubscribe from this group and stop receiving emails from it, send an email to puppet-bugs+unsubscr...@googlegroups.com. To post to this group, send email to puppet-bugs@googlegroups.com. Visit this group at http://groups.google.com/group/puppet-bugs?hl=en. For more options, visit https://groups.google.com/groups/opt_out.
[Puppet - Bug #19552] Cron handles special schedules poorly
Issue #19552 has been updated by Charlie Sharpsteen. Hi Felix, It looks like we may have another issue, #16809, that has a pull request which may solve this issue by unifying the handling of normal and special records. Bug #19552: Cron handles special schedules poorly https://projects.puppetlabs.com/issues/19552#change-84645 Author: Felix Frank Status: Accepted Priority: Normal Assignee: Felix Frank Category: cron Target version: Affected Puppet version: 2.6.17 Keywords: cronfixit crontab Branch: The crontab provider is rather schizophrenic. When parsing crontabs from disk, lines with special schedules such as @reboot are treated as a whole different breed than regular numerically scheduled tasks. That is necessary due to the structure of Puppet::Util::Fileparsing. However, upon creating new resources, such special schedules are just special cases of regular crontabs. A conditional in the implementation allows it to be generated correctly in the crontab file. Here's where the schizophrenia kicks in: When *not* dealing with brand new resources, but parsed records instead, certain code paths are never entered, and regenerating the record in file fails miserably. Neither the record name nor environment lines are written. A fix is already in the works. -- You have received this notification because you have either subscribed to it, or are involved in it. To change your notification preferences, please click here: http://projects.puppetlabs.com/my/account -- You received this message because you are subscribed to the Google Groups Puppet Bugs group. To unsubscribe from this group and stop receiving emails from it, send an email to puppet-bugs+unsubscr...@googlegroups.com. To post to this group, send email to puppet-bugs@googlegroups.com. Visit this group at http://groups.google.com/group/puppet-bugs?hl=en. For more options, visit https://groups.google.com/groups/opt_out.
[Puppet - Bug #4695] (Investigating) Puppet should not reset locale
Issue #4695 has been updated by eric sorenson. Status changed from Re-opened to Investigating Assignee set to Erik Dalén Target version changed from 3.1.0 to 3.2.0 Hi Erik - it appears the patch did not fix the bug for some people. Do you have any insight into why this could be? Re-targeting it for the next planned Puppet release, 3.2.0. Bug #4695: Puppet should not reset locale https://projects.puppetlabs.com/issues/4695#change-84649 Author: Mo Morsi Status: Investigating Priority: High Assignee: Erik Dalén Category: exec Target version: 3.2.0 Affected Puppet version: 3.1.0 Keywords: telly_deprecation locale Branch: https://github.com/puppetlabs/puppet/pull/1239 Puppet resets various locale related ENV variables to the posix default of 'C' immediately before invoked Kernel.exec to launch an executable (occurs when running a Single_exec in a recipe) http://github.com/reductivelabs/puppet/blob/master/lib/puppet/util.rb#L295 The problem is, the python interpreter will attempt to parse these variables to determine the default locale, and if it is set to 'C' (or not set at all as it will default to 'C'), 'None' will be returned, ignoring the true default locale. Thus any python script launched via Single_exec from a puppet recipe will not be able to get the default locale by invoking locale.getdefaultlocale(). This functionality is part of the standard python library and is relied upon by many various Python scripts. -- You have received this notification because you have either subscribed to it, or are involved in it. To change your notification preferences, please click here: http://projects.puppetlabs.com/my/account -- You received this message because you are subscribed to the Google Groups Puppet Bugs group. To unsubscribe from this group and stop receiving emails from it, send an email to puppet-bugs+unsubscr...@googlegroups.com. To post to this group, send email to puppet-bugs@googlegroups.com. Visit this group at http://groups.google.com/group/puppet-bugs?hl=en. For more options, visit https://groups.google.com/groups/opt_out.
[Puppet - Bug #7770] (Needs More Information) warning: Found multiple default providers
Issue #7770 has been updated by eric sorenson.
Status changed from Accepted to Needs More Information
Assignee set to Adam Gandelman
Target version changed from 3.1.0 to 3.x
Hi Adam -- a comment on this brought it to my attention -- were you able to try
the workaround Dan Bode suggested in
https://projects.puppetlabs.com/issues/7770#note-4 ?
I'm curious too if this problem is still applicable on Puppet 3, since we have
the ability to pick up new capabilities partway through a run.
I’ve put this ticket’s status into “Needs more Information” and assigned it to
you. Please either (a) update it with the information I’ve requested and
re-assign it to me if you need more help, or (b) change the status to “Closed”
if you were able to resolve the issue on your own.
Bug #7770: warning: Found multiple default providers
https://projects.puppetlabs.com/issues/7770#change-84650
Author: Adam Gandelman
Status: Needs More Information
Priority: Normal
Assignee: Adam Gandelman
Category: agent
Target version: 3.x
Affected Puppet version: 2.6.4
Keywords:
Branch:
Using a noop provider to work around suitability checks for commands from
yet-to-be installed packages, causes a warning about multiple providers during
runs when the package is actually installed. If the package is not installed
before the run, there are no warnings and the package is later installed.
pre
# lib/puppet/type/nova_admin.rb
Puppet::Type.newtype(:nova_admin) do
@doc = Manage createion/deletion of nova admin users.
ensurable
newparam(:name) do
desc The name of the admins.
end
end
/pre
pre
# lib/puppet/provider/nova_admin/default.pp
Puppet::Type.type(:nova_admin).provide(:default) do
desc This is a default provider that does nothing. This allows us to install
nova-manage on the same puppet run where we want to use it.
def create
return false
end
def destroy
return false
end
def exists?
fail('This is just the default provider for nova_admin, all it does is
fail')
end
end
/pre
pre
# lib/puppet/provider/nova_admin/nova_admin.pp
Puppet::Type.type(:nova_admin).provide(:admin) do
desc Manage nova admin user
commands :nova_manage = 'nova-manage'
def exists?
nova_manage(user, list).match(/^#{resource[:name]}$/)
end
def create
nova_manage(user, admin, resource[:name])
end
def destroy
nova_manage(user, delete, resource[:name])
end
end
/pre
pre
# admin.pp
class nova::manage::admin ( $username ) {
nova_admin{ $username:
ensure = present,
provider = 'admin',
notify = Exec[nova-db-sync],
require = Class[nova::db],
}
}
/pre
pre
warning: Found multiple default providers for nova_admin: admin, default; using
admin
/pre
--
You have received this notification because you have either subscribed to it,
or are involved in it.
To change your notification preferences, please click here:
http://projects.puppetlabs.com/my/account
--
You received this message because you are subscribed to the Google Groups
Puppet Bugs group.
To unsubscribe from this group and stop receiving emails from it, send an email
to puppet-bugs+unsubscr...@googlegroups.com.
To post to this group, send email to puppet-bugs@googlegroups.com.
Visit this group at http://groups.google.com/group/puppet-bugs?hl=en.
For more options, visit https://groups.google.com/groups/opt_out.
[Puppet - Bug #19153] service puppet ensure stopped kills off cron-run puppet with Caught TERM; calling stop
Issue #19153 has been updated by eric sorenson.
Target version changed from 3.1.1 to 3.2.0
Updating the target version to match reality.
Bug #19153: service puppet ensure stopped kills off cron-run puppet with
Caught TERM; calling stop
https://projects.puppetlabs.com/issues/19153#change-84653
Author: Jo Rhett
Status: Needs More Information
Priority: Urgent
Assignee: Jo Rhett
Category: agent
Target version: 3.2.0
Affected Puppet version: 3.1.0
Keywords:
Branch:
We have recently switched from puppet agent in daemon mode (for kick) to
cron-run puppet with mcollective agent. However, I started noticing that puppet
policies were being inconsistently applied across the hosts. It turns out that
this policy is the problem:
pre
service { 'puppet':
ensure = stopped,
enable = false,
require = File['/etc/cron.d/puppet','/etc/puppet/puppet.conf'],
}
/pre
I have checked and confirmed that the puppet init script returns the correct
response even when puppet is running. If I run puppet agent --test in one
window and while it is running I run this in the other window, it shows clear:
pre
root@sj2-noc01 ~$ service puppet status ; echo $?
puppet is stopped
3
/pre
However, if I run puppet in a silent mode with --onetime and --no-daemon then
the init script returns this value
pre
root@sj2-noc01 ~$ service puppet status ; echo $?
puppet (pid 30406) is running...
0
/pre
This causes it to kill itself off, and not finish the run. Due to the
semi-random nature of ordering, this happens near the end or near the beginning
of the puppet run on different hosts. (there are few dependancies on the puppet
module, so its order in the manifest is random from host to host)
This is clearly a major flaw. We need the above policy to ensure that no puppet
daemons are running, however it interferes with the cron-run instance. However
it is handled properly when run verbosely with test.
Environment is a mixture of CentOS 5 6.
--
You have received this notification because you have either subscribed to it,
or are involved in it.
To change your notification preferences, please click here:
http://projects.puppetlabs.com/my/account
--
You received this message because you are subscribed to the Google Groups
Puppet Bugs group.
To unsubscribe from this group and stop receiving emails from it, send an email
to puppet-bugs+unsubscr...@googlegroups.com.
To post to this group, send email to puppet-bugs@googlegroups.com.
Visit this group at http://groups.google.com/group/puppet-bugs?hl=en.
For more options, visit https://groups.google.com/groups/opt_out.
[Puppet - Bug #19140] (Code Insufficient) package provider Gem uses --include-dependency = does not work with gem 2.0.0-rc2
Issue #19140 has been updated by eric sorenson. Status changed from Accepted to Code Insufficient Assignee set to Matthew Jones Hi Matthew -- we got a report from a user who tried your patch that it causes an error, can you please check out this update? https://projects.puppetlabs.com/issues/19140#note-4 I’ve put this ticket’s status into “Code Insufficient” and assigned it to you. Please either (a) update the ticket or pull request with a version of code which addresses the issues, or (b) assign it back to me if you are blocked on the problem and I'll move things forward. Bug #19140: package provider Gem uses --include-dependency = does not work with gem 2.0.0-rc2 https://projects.puppetlabs.com/issues/19140#change-84655 Author: Xavier Nicollet Status: Code Insufficient Priority: Normal Assignee: Matthew Jones Category: package Target version: 3.1.x Affected Puppet version: Keywords: Branch: Puppet should not use --include-dependency for gem = gem 2.0.0-rc2, because the switch is not supported anymore. I have submitted a bug report to gem: https://github.com/rubygems/rubygems/issues/446 Should be handled before rubygems 2.0.0 is widely used. Cheers, -- You have received this notification because you have either subscribed to it, or are involved in it. To change your notification preferences, please click here: http://projects.puppetlabs.com/my/account -- You received this message because you are subscribed to the Google Groups Puppet Bugs group. To unsubscribe from this group and stop receiving emails from it, send an email to puppet-bugs+unsubscr...@googlegroups.com. To post to this group, send email to puppet-bugs@googlegroups.com. Visit this group at http://groups.google.com/group/puppet-bugs?hl=en. For more options, visit https://groups.google.com/groups/opt_out.
[Puppet - Bug #19140] package provider Gem uses --include-dependency = does not work with gem 2.0.0-rc2
Issue #19140 has been updated by Jeff McCune. Hi Matthew, If you get a chance to review the change set, I'd also greatly appreciate it if you file a pull request instead of attaching a patch. The details are in our [contributing](https://github.com/puppetlabs/puppet/blob/master/CONTRIBUTING.md) guide. The vast majority of our contributions come as pull requests and I overlooked the patch in this issue since much of our tooling and process is built around pull requests. We'll accept contributions in any form, of course, we just really appreciate pull requests. Thanks, -Jeff Bug #19140: package provider Gem uses --include-dependency = does not work with gem 2.0.0-rc2 https://projects.puppetlabs.com/issues/19140#change-84668 Author: Xavier Nicollet Status: Code Insufficient Priority: Normal Assignee: Matthew Jones Category: package Target version: 3.1.x Affected Puppet version: Keywords: Branch: Puppet should not use --include-dependency for gem = gem 2.0.0-rc2, because the switch is not supported anymore. I have submitted a bug report to gem: https://github.com/rubygems/rubygems/issues/446 Should be handled before rubygems 2.0.0 is widely used. Cheers, -- You have received this notification because you have either subscribed to it, or are involved in it. To change your notification preferences, please click here: http://projects.puppetlabs.com/my/account -- You received this message because you are subscribed to the Google Groups Puppet Bugs group. To unsubscribe from this group and stop receiving emails from it, send an email to puppet-bugs+unsubscr...@googlegroups.com. To post to this group, send email to puppet-bugs@googlegroups.com. Visit this group at http://groups.google.com/group/puppet-bugs?hl=en. For more options, visit https://groups.google.com/groups/opt_out.
