Reprepro cookbook

Douglas_Garstang · June 19, 2015, 2:31pm

I was trying to use the Debian Reprepro cookbook located here:

It runs fine on the first run, and then fails on subsequent runs (ie a
simple 'vagrant provision') due to the logic that imports the gpg key not
being handled idempotently.

==> default:

==> default: Error executing action `run` on resource 'execute[import
packaging key]'
==> default:

==> default:
==> default:
==> default: Mixlib::ShellOut::ShellCommandFailed
==> default: ------------------------------------
==> default: Expected process to exit with [0], but received '2'
==> default: ---- Begin output of /bin/echo -e '-----BEGIN PGP PRIVATE KEY
BLOCK-----
==> default: Version: GnuPG v1
==> default:
==> default:
==> default: -----END PGP PRIVATE KEY BLOCK-----
==> default: ' | gpg --import - ----
==> default: STDOUT:
==> default: STDERR: gpg: key 18DB12D8: already in secret keyring
==> default: gpg: Total number processed: 1
==> default: gpg: secret keys read: 1
==> default: gpg: secret keys unchanged: 1

Disappointing quality from something with Opscode's name on it. Can someone
recommend a cookbook for setting up a Debian package repository of better
quality? Alternatively I concede I might be doing something wrong in the
way I'm implementing it, but I don't think so.

Doug

Tensibai · June 19, 2015, 3:34pm

According to this line

github.com

sous-chefs/reprepro/blob/main/recipes/default.rb#L92


      
          if apt_repo
            pgp_key = "#{apt_repo['repo_dir']}/#{node['reprepro']['pgp_email']}.gpg.key"
          
            execute 'import packaging key' do
              command "/bin/echo -e '#{apt_repo['pgp']['private']}' | gpg --import -"
              user 'root'
              cwd '/root'
              environment 'GNUPGHOME' => node['reprepro']['gnupg_home']
              not_if "GNUPGHOME=/root/.gnupg gpg --list-secret-keys --fingerprint #{node['reprepro']['pgp_email']} | egrep -qx '.*Key fingerprint = #{node['reprepro']['pgp_fingerprint']}'"
            end
          
            template pgp_key do
              source 'pgp_key.erb'
              mode '0644'
              owner 'nobody'
              group 'nogroup'
              variables(
                pgp_public: apt_repo['pgp']['public']
              )
            end
          else

[2]

not_if "GNUPGHOME=/root/.gnupg gpg --list-secret-keys --fingerprint
#{node['reprepro']['pgp_email']} | egrep -qx '.*Key fingerprint =
#{node['reprepro']['pgp_fingerprint']}'"

It should not happen if your databag is set up properly, the quality
sounds out of cause in your problem.

Blaming the code quality with so few debugging information is unlikely
to get you a return from the authors.

Run with -l debug to see why the guard does not apply and give some
insight on what give the guard if you try it in a vagrant ssh session,
tell us which distribution you're using, well give insight on your
platform so we don't have to guess.

Le 2015-06-19 16:31, Douglas Garstang a écrit :

I was trying to use the Debian Reprepro cookbook located here:
GitHub - sous-chefs/reprepro: Development repository for the reprepro cookbook [1]

It runs fine on the first run, and then fails on subsequent runs (ie a simple 'vagrant provision') due to the logic that imports the gpg key not being handled idempotently.

==> default: ================================================================================
==> default: Error executing action run on resource 'execute[import packaging key]'
==> default: ================================================================================
==> default:
==> default:
==> default: Mixlib::ShellOut::ShellCommandFailed
==> default: ------------------------------------
==> default: Expected process to exit with [0], but received '2'
==> default: ---- Begin output of /bin/echo -e '-----BEGIN PGP PRIVATE KEY BLOCK-----
==> default: Version: GnuPG v1
==> default:
==> default:
==> default: -----END PGP PRIVATE KEY BLOCK-----
==> default: ' | gpg --import - ----
==> default: STDOUT:
==> default: STDERR: gpg: key 18DB12D8: already in secret keyring
==> default: gpg: Total number processed: 1
==> default: gpg: secret keys read: 1
==> default: gpg: secret keys unchanged: 1

Disappointing quality from something with Opscode's name on it. Can someone recommend a cookbook for setting up a Debian package repository of better quality? Alternatively I concede I might be doing something wrong in the way I'm implementing it, but I don't think so.

Doug

Links:

[1] GitHub - sous-chefs/reprepro: Development repository for the reprepro cookbook
[2]
https://github.com/jesseadams/reprepro/blob/master/recipes/default.rb#L92

Douglas_Garstang · June 19, 2015, 4:02pm

Here's the data bag, with the keys redacted.

{
"id": "main",
"fqdn": "pypiserv-004.dev.slicetest.com",
"repo_dir": "/srv/apt",
"incoming": "/srv/apt_incoming",
"description": "APT Repository for our packages.",
"codenames": [
"trusty"
],
"allow": [
"unstable>sid", "stable>squeeze"
],
"pgp": {
"email": "packages@example.com",
"fingerprint": "PGP Fingerprint for the key",
"public": "",
"private": ""
},
"pulls": {
"name": "sid",
"from": "sid",
"component": "main"
},
"architectures": [
"amd64","i386","all","source"
]
}

I'm not sure how to get the chef client to run with -l debug via vagrant.

Doug.

On Fri, Jun 19, 2015 at 8:34 AM, Tensibai tensibai@iabis.net wrote:

According to this line
https://github.com/jesseadams/reprepro/blob/master/recipes/default.rb#L92

not_if "GNUPGHOME=/root/.gnupg gpg --list-secret-keys --fingerprint #{
node['reprepro']['pgp_email']} | egrep -qx '.*Key fingerprint = #{node['
reprepro']['pgp_fingerprint']}'"

It should not happen if your databag is set up properly, the quality
sounds out of cause in your problem.

Blaming the code quality with so few debugging information is unlikely to
get you a return from the authors.

Run with -l debug to see why the guard does not apply and give some
insight on what give the guard if you try it in a vagrant ssh session, tell
us which distribution you're using, well give insight on your platform so
we don't have to guess.

Le 2015-06-19 16:31, Douglas Garstang a écrit :

I was trying to use the Debian Reprepro cookbook located here:
GitHub - sous-chefs/reprepro: Development repository for the reprepro cookbook

It runs fine on the first run, and then fails on subsequent runs (ie a
simple 'vagrant provision') due to the logic that imports the gpg key not
being handled idempotently.

==> default:

==> default: Error executing action run on resource 'execute[import
packaging key]'
==> default:

==> default:
==> default:
==> default: Mixlib::ShellOut::ShellCommandFailed
==> default: ------------------------------------
==> default: Expected process to exit with [0], but received '2'
==> default: ---- Begin output of /bin/echo -e '-----BEGIN PGP PRIVATE KEY
BLOCK-----
==> default: Version: GnuPG v1
==> default:
==> default:
==> default: -----END PGP PRIVATE KEY BLOCK-----
==> default: ' | gpg --import - ----
==> default: STDOUT:
==> default: STDERR: gpg: key 18DB12D8: already in secret keyring
==> default: gpg: Total number processed: 1
==> default: gpg: secret keys read: 1
==> default: gpg: secret keys unchanged: 1

Disappointing quality from something with Opscode's name on it. Can
someone recommend a cookbook for setting up a Debian package repository of
better quality? Alternatively I concede I might be doing something wrong in
the way I'm implementing it, but I don't think so.

Doug

--
Regards,

Douglas Garstang
http://www.linkedin.com/in/garstang
Email: doug.garstang@gmail.com
Cell: +1-805-340-5627

Tensibai · June 19, 2015, 4:14pm

From vagrant documentation:

In your provisonning block add :

chef.log_level :debug (as you would do with add_recipe=

And doing a vagrant ssh to your box and being root could you try the
following command:

GNUPGHOME=/root/.gnupg gpg --list-secret-keys --fingerprint
"packages@example.com" | egrep -qx '.*Key fingerprint = '

Le 2015-06-19 18:02, Douglas Garstang a écrit :

Here's the data bag, with the keys redacted.

{
"id": "main",
"fqdn": "pypiserv-004.dev.slicetest.com [1]",
"repo_dir": "/srv/apt",
"incoming": "/srv/apt_incoming",
"description": "APT Repository for our packages.",
"codenames": [
"trusty"
],
"allow": [
"unstable>sid", "stable>squeeze"
],
"pgp": {
"email": "packages@example.com",
"fingerprint": "PGP Fingerprint for the key",
"public": "",
"private": ""
},
"pulls": {
"name": "sid",
"from": "sid",
"component": "main"
},
"architectures": [
"amd64","i386","all","source"
]
}

I'm not sure how to get the chef client to run with -l debug via vagrant.

Doug.

On Fri, Jun 19, 2015 at 8:34 AM, Tensibai tensibai@iabis.net wrote:

According to this line https://github.com/jesseadams/reprepro/blob/master/recipes/default.rb#L92 [2]

not_if "GNUPGHOME=/root/.gnupg gpg --list-secret-keys --fingerprint #{node['reprepro']['pgp_email']} | egrep -qx '.*Key fingerprint = #{node['reprepro']['pgp_fingerprint']}'"

It should not happen if your databag is set up properly, the quality sounds out of cause in your problem.

Blaming the code quality with so few debugging information is unlikely to get you a return from the authors.

Run with -l debug to see why the guard does not apply and give some insight on what give the guard if you try it in a vagrant ssh session, tell us which distribution you're using, well give insight on your platform so we don't have to guess.

Le 2015-06-19 16:31, Douglas Garstang a écrit :

I was trying to use the Debian Reprepro cookbook located here:
GitHub - sous-chefs/reprepro: Development repository for the reprepro cookbook [3]

It runs fine on the first run, and then fails on subsequent runs (ie a simple 'vagrant provision') due to the logic that imports the gpg key not being handled idempotently.

==> default: ================================================================================
==> default: Error executing action run on resource 'execute[import packaging key]'
==> default: ================================================================================
==> default:
==> default:
==> default: Mixlib::ShellOut::ShellCommandFailed
==> default: ------------------------------------
==> default: Expected process to exit with [0], but received '2'
==> default: ---- Begin output of /bin/echo -e '-----BEGIN PGP PRIVATE KEY BLOCK-----
==> default: Version: GnuPG v1
==> default:
==> default:
==> default: -----END PGP PRIVATE KEY BLOCK-----
==> default: ' | gpg --import - ----
==> default: STDOUT:
==> default: STDERR: gpg: key 18DB12D8: already in secret keyring
==> default: gpg: Total number processed: 1
==> default: gpg: secret keys read: 1
==> default: gpg: secret keys unchanged: 1

Disappointing quality from something with Opscode's name on it. Can someone recommend a cookbook for setting up a Debian package repository of better quality? Alternatively I concede I might be doing something wrong in the way I'm implementing it, but I don't think so.

Doug

--

Regards,

Douglas Garstang
http://www.linkedin.com/in/garstang [4]
Email: doug.garstang@gmail.com
Cell: +1-805-340-5627

Links:

[1] http://pypiserv-004.dev.slicetest.com
[2]
https://github.com/jesseadams/reprepro/blob/master/recipes/default.rb#L92
[3] GitHub - sous-chefs/reprepro: Development repository for the reprepro cookbook
[4] http://www.linkedin.com/in/garstang

Lamont_Granquist · June 19, 2015, 7:19pm

On 06/19/2015 07:31 AM, Douglas Garstang wrote:

Disappointing quality from something with Opscode's name on it.

Doug you've been warned repeatedly that you need to stop making
statements like this.

That cookbook has also been transferred to community support by Jesse
Adams, which should be obvious from the URL to the repo that you pasted,
so you're actually insulting a community member. The banner at the top
is incorrect and has not been updated. AFAIK nobody at Chef Software
has commit rights to that repo (I certainly do not).

Jesse_Adams · June 19, 2015, 7:25pm

It's all good I honestly have very few commits on this cookbook so far
and I am a bit behind on maintenance. If someone is interested in taking it
over please let me know. I plan on putting some work on it soon as time is
going to free up soon. Pull requests are always welcome.

Thanks!

Jesse

On Fri, Jun 19, 2015 at 12:19 PM, Lamont Granquist lamont@chef.io wrote:

On 06/19/2015 07:31 AM, Douglas Garstang wrote:

Disappointing quality from something with Opscode's name on it.

Doug you've been warned repeatedly that you need to stop making statements
like this.

That cookbook has also been transferred to community support by Jesse
Adams, which should be obvious from the URL to the repo that you pasted, so
you're actually insulting a community member. The banner at the top is
incorrect and has not been updated. AFAIK nobody at Chef Software has
commit rights to that repo (I certainly do not).

Douglas_Garstang · June 19, 2015, 7:34pm

Lamont,

I'm biting my tongue as I write this doing my best to restrain my anger. It
is quite apparent that no matter what I say, it will be deemed
inappropriate. The README.md at the bottom states Opscode. It's not my
place to know if that is accurate or not. I also took pains to specifically
mention in my original post that it might actually be my fault. For reasons
I don't understand, you've latched onto my personal opinion of a piece of
software generated by a commercial enterprise being below the quality I'd
expect. Again, like before, there's nothing in the community guidelines
about this being not being allowed.

Douglas.

On Fri, Jun 19, 2015 at 12:19 PM, Lamont Granquist lamont@chef.io wrote:

On 06/19/2015 07:31 AM, Douglas Garstang wrote:

Disappointing quality from something with Opscode's name on it.

Doug you've been warned repeatedly that you need to stop making statements
like this.

That cookbook has also been transferred to community support by Jesse
Adams, which should be obvious from the URL to the repo that you pasted, so
you're actually insulting a community member. The banner at the top is
incorrect and has not been updated. AFAIK nobody at Chef Software has
commit rights to that repo (I certainly do not).

--
Regards,

Douglas Garstang
http://www.linkedin.com/in/garstang
Email: doug.garstang@gmail.com
Cell: +1-805-340-5627

Chip · June 19, 2015, 8:54pm

Doug,

It’s okay to point out what’s wrong. It’s not okay to tear people down when you feel that the work they have given you for free isn’t good enough for you to re-use.

If you are unable to understand the difference between saying “I’m really frustrated and stuck, this is broken and I can’t get it to work, and I don’t know how to fix it,” and saying “disappointing quality from Opscode,” then I don’t know what to tell you. Regardless of who disappointed you, this isn’t a constructive thing to share with a software community.

Criticism is welcomed form of expression when it isn’t just bashing on people with snide remarks. “Disappointing quality from Opscode” doesn’t make anyone who reads it want to help you be better at your job, or help you improve the free cookbooks you’re re-using. If you don’t know how to express your feelings in a way that invites others to help, then again I really don’t know what to say.

I understand that you feel stuck in a problem you don’t know how to solve. I understand that you’re angry about being censured again. But instead of responding with an attempt to rules-lawyer the community guidelines by pointing out that your particular brand of negativity isn’t specifically disallowed, perhaps you should focus on how your future contributions can motivate us all make the code and the community better for both yourself and everyone else.

None of us want to see you unhappy. All of us want to see you succeed beyond your wildest dreams. But we can’t enable that goal at the expense of others in this community.

Thanks,
–Charles

On June 19, 2015 at 12:35:31 PM, Douglas Garstang (doug.garstang@gmail.com) wrote:

Lamont,

I’m biting my tongue as I write this doing my best to restrain my anger. It is quite apparent that no matter what I say, it will be deemed inappropriate. The README.md at the bottom states Opscode. It’s not my place to know if that is accurate or not. I also took pains to specifically mention in my original post that it might actually be my fault. For reasons I don’t understand, you’ve latched onto my personal opinion of a piece of software generated by a commercial enterprise being below the quality I’d expect. Again, like before, there’s nothing in the community guidelines about this being not being allowed.

Douglas.

On Fri, Jun 19, 2015 at 12:19 PM, Lamont Granquist lamont@chef.io wrote:

On 06/19/2015 07:31 AM, Douglas Garstang wrote:

Disappointing quality from something with Opscode’s name on it.

Doug you’ve been warned repeatedly that you need to stop making statements like this.

That cookbook has also been transferred to community support by Jesse Adams, which should be obvious from the URL to the repo that you pasted, so you’re actually insulting a community member. The banner at the top is incorrect and has not been updated. AFAIK nobody at Chef Software has commit rights to that repo (I certainly do not).

–
Regards,

Douglas Garstang
http://www.linkedin.com/in/garstang
Email: doug.garstang@gmail.com
Cell: +1-805-340-5627

PeterBurkholder · June 19, 2015, 10:30pm

Here's a thought: when we are most frustrated, that's also when we have the
chance to make real contributions back to open-source. Even if your skills
aren't yet up to the level of submitting new features or fixing bugs,
almost every project needs better READMEs, HOW-TOs and examples.

Frustration is a sign you've hit the envelope of what's currently
well-documented, and your experience, if submitted as a PR back to a
project, is a gift that keeps on giving. And that contribution is
tremendously empowering as you've gone from hapless consumer to kick-ass
contributor (and, yes, documentation does count).

--Peter

On Fri, Jun 19, 2015 at 4:55 PM Charles Johnson charles@chef.io wrote:

Doug,

It's okay to point out what's wrong. It's not okay to tear people down
when you feel that the work they have given you for free isn't good enough
for you to re-use.

If you are unable to understand the difference between saying "I'm really
frustrated and stuck, this is broken and I can't get it to work, and I
don't know how to fix it," and saying "disappointing quality from Opscode,"
then I don't know what to tell you. Regardless of who disappointed you,
this isn't a constructive thing to share with a software community.

Criticism is welcomed form of expression when it isn't just bashing on
people with snide remarks. "Disappointing quality from Opscode" doesn't
make anyone who reads it want to help you be better at your job, or help
you improve the free cookbooks you're re-using. If you don't know how to
express your feelings in a way that invites others to help, then again I
really don't know what to say.

I understand that you feel stuck in a problem you don't know how to solve.
I understand that you're angry about being censured again. But instead of
responding with an attempt to rules-lawyer the community guidelines by
pointing out that your particular brand of negativity isn't specifically
disallowed, perhaps you should focus on how your future contributions can
motivate us all make the code and the community better for both yourself
and everyone else.

None of us want to see you unhappy. All of us want to see you succeed
beyond your wildest dreams. But we can't enable that goal at the expense of
others in this community.

Thanks,
--Charles

On June 19, 2015 at 12:35:31 PM, Douglas Garstang (doug.garstang@gmail.com)
wrote:

Lamont,

I'm biting my tongue as I write this doing my best to restrain my anger.
It is quite apparent that no matter what I say, it will be deemed
inappropriate. The README.md at the bottom states Opscode. It's not my
place to know if that is accurate or not. I also took pains to specifically
mention in my original post that it might actually be my fault. For reasons
I don't understand, you've latched onto my personal opinion of a piece of
software generated by a commercial enterprise being below the quality I'd
expect. Again, like before, there's nothing in the community guidelines
about this being not being allowed.

Douglas.

On Fri, Jun 19, 2015 at 12:19 PM, Lamont Granquist lamont@chef.io wrote:

On 06/19/2015 07:31 AM, Douglas Garstang wrote:

Disappointing quality from something with Opscode's name on it.

Doug you've been warned repeatedly that you need to stop making
statements like this.

That cookbook has also been transferred to community support by Jesse
Adams, which should be obvious from the URL to the repo that you pasted, so
you're actually insulting a community member. The banner at the top is
incorrect and has not been updated. AFAIK nobody at Chef Software has
commit rights to that repo (I certainly do not).

--
Regards,

Douglas Garstang
http://www.linkedin.com/in/garstang
Email: doug.garstang@gmail.com
Cell: +1-805-340-5627

someara · June 21, 2015, 8:04am

Documentation PRs are super easy to merge, too. They don't require
tests, just human parsing.
Totally my fave.
-s

On Fri, Jun 19, 2015 at 3:30 PM, Peter Burkholder pburkholder@pobox.com wrote:

Here's a thought: when we are most frustrated, that's also when we have the
chance to make real contributions back to open-source. Even if your skills
aren't yet up to the level of submitting new features or fixing bugs, almost
every project needs better READMEs, HOW-TOs and examples.

Frustration is a sign you've hit the envelope of what's currently
well-documented, and your experience, if submitted as a PR back to a
project, is a gift that keeps on giving. And that contribution is
tremendously empowering as you've gone from hapless consumer to kick-ass
contributor (and, yes, documentation does count).

--Peter

On Fri, Jun 19, 2015 at 4:55 PM Charles Johnson charles@chef.io wrote:

Doug,

It's okay to point out what's wrong. It's not okay to tear people down
when you feel that the work they have given you for free isn't good enough
for you to re-use.

If you are unable to understand the difference between saying "I'm really
frustrated and stuck, this is broken and I can't get it to work, and I don't
know how to fix it," and saying "disappointing quality from Opscode," then I
don't know what to tell you. Regardless of who disappointed you, this isn't
a constructive thing to share with a software community.

Criticism is welcomed form of expression when it isn't just bashing on
people with snide remarks. "Disappointing quality from Opscode" doesn't make
anyone who reads it want to help you be better at your job, or help you
improve the free cookbooks you're re-using. If you don't know how to express
your feelings in a way that invites others to help, then again I really
don't know what to say.

I understand that you feel stuck in a problem you don't know how to solve.
I understand that you're angry about being censured again. But instead of
responding with an attempt to rules-lawyer the community guidelines by
pointing out that your particular brand of negativity isn't specifically
disallowed, perhaps you should focus on how your future contributions can
motivate us all make the code and the community better for both yourself and
everyone else.

None of us want to see you unhappy. All of us want to see you succeed
beyond your wildest dreams. But we can't enable that goal at the expense of
others in this community.

Thanks,
--Charles

On June 19, 2015 at 12:35:31 PM, Douglas Garstang
(doug.garstang@gmail.com) wrote:

Lamont,

I'm biting my tongue as I write this doing my best to restrain my anger.
It is quite apparent that no matter what I say, it will be deemed
inappropriate. The README.md at the bottom states Opscode. It's not my place
to know if that is accurate or not. I also took pains to specifically
mention in my original post that it might actually be my fault. For reasons
I don't understand, you've latched onto my personal opinion of a piece of
software generated by a commercial enterprise being below the quality I'd
expect. Again, like before, there's nothing in the community guidelines
about this being not being allowed.

Douglas.

On Fri, Jun 19, 2015 at 12:19 PM, Lamont Granquist lamont@chef.io wrote:

On 06/19/2015 07:31 AM, Douglas Garstang wrote:

Disappointing quality from something with Opscode's name on it.

Doug you've been warned repeatedly that you need to stop making
statements like this.

That cookbook has also been transferred to community support by Jesse
Adams, which should be obvious from the URL to the repo that you pasted, so
you're actually insulting a community member. The banner at the top is
incorrect and has not been updated. AFAIK nobody at Chef Software has
commit rights to that repo (I certainly do not).

--
Regards,

Douglas Garstang
http://www.linkedin.com/in/garstang
Email: doug.garstang@gmail.com
Cell: +1-805-340-5627

Roland_Moriz1 · June 21, 2015, 12:40pm

Am 21.06.2015 um 10:04 schrieb Sean OMeara someara@chef.io:

Documentation PRs are super easy to merge, too. They don't require
tests, just human parsing.
Totally my fave.
-s

There are many cases of (former) opscode-cookbooks that have such „easy“ PRs waiting but wont get merged - for months.

IMHO most cookbooks don’t lack PRs and issue reports but maintainer activity or willingness to adopt new maintainers if the current ones don’t have enough time or motivation anymore (which is fine, it’s OSS and shouldn’t be a burden).

For example you may want to check your github notifications on the nginx cookbook (afaik you’re co-mainainer). I’ve worked through many open, unanswered issues last week to help users. Because I’m not a maintainer
I cannot close issues or merge PRs so my efforts can’t bring any sustainable improvement.

That’s why I can fully understand that many chef users become angry and or leaving chef behind.

See also:
Access rights validated https://feedback.chef.io/forums/301644-chef-product-feedback/suggestions/8386914-broken-cookbook-community

I clearly don’t understand Chef, inc. here… and I’m getting humiliated by Ansible users regularly when I try to present Chef

regards
Roland

Tensibai · June 21, 2015, 1:27pm

I have something to add: when you're too lazy to do a Google search on how to set chef log level at debug in a vagrant file and just saying it like this, without showing any effort on reading replies and answering questions in them, you'd better engage a consultant or buy a commercial support.

I'm happy to help people willing to learn, you don't show any interest on this part.

I'm not part of Chef Inc. Nor a cookbook maintenir but your mails sounds insulting anyway as you persist in this negative tone.

Le 19 juin 2015 21:34, Douglas Garstang <doug.garstang@gmail.com> a écrit :

Lamont,
I'm biting my tongue as I write this doing my best to restrain my anger. It is quite apparent that no matter what I say, it will be deemed inappropriate. The README.md at the bottom states Opscode. It's not my place to know if that is accurate or not. I also took pains to specifically mention in my original post that it might actually be my fault. For reasons I don't understand, you've latched onto my personal opinion of a piece of software generated by a commercial enterprise being below the quality I'd expect. Again, like before, there's nothing in the community guidelines about this being not being allowed.

Douglas.

On Fri, Jun 19, 2015 at 12:19 PM, Lamont Granquist <lamont@chef.io> wrote:

On 06/19/2015 07:31 AM, Douglas Garstang wrote:

Disappointing quality from something with Opscode's name on it.

Doug you've been warned repeatedly that you need to stop making statements like this.

That cookbook has also been transferred to community support by Jesse Adams, which should be obvious from the URL to the repo that you pasted, so you're actually insulting a community member. The banner at the top is incorrect and has not been updated. AFAIK nobody at Chef Software has commit rights to that repo (I certainly do not).

--

Regards,

Douglas Garstang

http://www.linkedin.com/in/garstang

Email: doug.garstang@gmail.com

Cell: +1-805-340-5627

holoway · June 22, 2015, 4:33pm

Hi Roland. I think the willingness to adopt new maintainers isn't true in
the main, while maintainer activity most certainly is. We (Chef Software)
have been pretty aggressively trying to find new maintainers for much of
the community cookbooks we started - not because we don't see value in
them, but because we (often) are no longer direct users of the technology
in question, and so we wind up not being the best possible maintainers.
That process started well over a year ago, and continues.

I think it's clear that, over the seven years Chef has existed, the role of
community cookbooks has changed and morphed several times. We initially all
believed that we would wind up with a single, glorious abstraction for each
piece of software we needed to manage - I think in the intervening time
we've learned that's not realistic, and where it is, the shape is different
(more resources, less recipes). You can see reflections of that in the way
we teach Chef - we used to start with using community cookbooks, and then
try and teach how it worked - we now teach how it works first, and build up
to re-use as an advanced topic. What used to happen was people would get a
great initial experience with a cookbook, then need to make a small change
or variation, and wind up lost in a sea of complexity. That happens today,
too, but less often than it used to.

To speak for Chef Software directly, we have always had people on staff
whose role was assisting the creation and maintenance of cookbooks. That
number has fluctuated up and down over time, with the skill sets of people
we hire, and the normal day-to-day ebb and flow of trying to figure out how
to build a business that is successful. We have people on staff today who
do the same. What is clear is that the energy around cookbooks in the
community is far greater than the energy we can muster as an organization
(regardless of how much capital we do or do not have - y'all outnumber us)

and so our focus today is on trying to build and support the best
community we can, through development of the supermarket, better tooling,
and providing a few key examples of how best to build a community cookbook
(see Sean's work on the httpd cookbook.)

Perhaps we need to organize a PR/merge festival brigade?

Best,
Adam

On Sun, Jun 21, 2015 at 5:40 AM, Roland Moriz rmoriz@gmail.com wrote:

Am 21.06.2015 um 10:04 schrieb Sean OMeara someara@chef.io:

Documentation PRs are super easy to merge, too. They don't require
tests, just human parsing.
Totally my fave.
-s

There are many cases of (former) opscode-cookbooks that have such „easy“
PRs waiting but wont get merged - for months.

IMHO most cookbooks don’t lack PRs and issue reports but maintainer
activity or willingness to adopt new maintainers if the current ones don’t
have enough time or motivation anymore (which is fine, it’s OSS and
shouldn’t be a burden).

For example you may want to check your github notifications on the nginx
cookbook (afaik you’re co-mainainer). I’ve worked through many open,
unanswered issues last week to help users. Because I’m not a maintainer
I cannot close issues or merge PRs so my efforts can’t bring any
sustainable improvement.

That’s why I can fully understand that many chef users become angry and or
leaving chef behind.

See also:

Access rights validated

I clearly don’t understand Chef, inc. here… and I’m getting humiliated by
Ansible users regularly when I try to present Chef

regards
Roland

Topic		Replies	Views
Chef bootstrap installation -->gpg key not found on keyserver Chef Infra (archive)	6	1156	January 12, 2012
How should I handle the problem of the pubkey auth for git repos in Chef recipes? Chef Infra (archive)	2	371	November 14, 2012
Package Source Repo GPG Key Broken? Chef Infra (archive)	12	1117	July 22, 2021
Application cookbook/bitbucket problem Chef Infra (archive)	7	712	September 17, 2014
Apt repository cookbook Chef Infra (archive)	7	425	February 19, 2015

Reprepro cookbook

==> default:

==> default: Error executing action run on resource 'execute[import packaging key]' ==> default:

Links:

==> default:

==> default: Error executing action run on resource 'execute[import packaging key]' ==> default:

Links:

Related topics

==> default: Error executing action `run` on resource 'execute[import
packaging key]'
==> default:

==> default: Error executing action `run` on resource 'execute[import
packaging key]'
==> default: