This is half a warning and half a note to Matthew Kent who so graciously packages up Chef for Redhat/CentOS systems.
Today an update went out to EPEL to add rubygem-json 1.4.3. For those of us using the combination of EPEL and ELFF (mkent’s repo) repositories, this updates rubygem-json from 1.1.9 (from ELFF). Unfortunately, Chef and Ohai need versions less than or equal to 1.4.2, so Rubygems will refuse to load the chef and ohai gems.
I’ve temporarily fixed this on the boxes that picked it up using
yum downgrade rubygem-json
but I think I’ll just be moving the EPEL dependencies to my local repo so as not to be bitten again if another update like this occurs.
On Thu, 2010-09-16 at 01:42 -0500, Leinartas, Michael wrote:
This is half a warning and half a note to Matthew Kent who so
graciously packages up Chef for Redhat/CentOS systems.
Today an update went out to EPEL to add rubygem-json 1.4.3. For those
of us using the combination of EPEL and ELFF (mkent's repo)
repositories, this updates rubygem-json from 1.1.9 (from ELFF).
Unfortunately, Chef and Ohai need versions less than or equal to
1.4.2, so Rubygems will refuse to load the chef and ohai gems.
Thanks! I'll certainly look at updating the packages shortly and likely
just carry the working version of rubygem-json in ELFF.
--
Matthew Kent \ SA \ bravenet.com
On 16 September 2010 21:34, Matthew Kent matt@bravenet.com wrote:
On Thu, 2010-09-16 at 01:42 -0500, Leinartas, Michael wrote:
This is half a warning and half a note to Matthew Kent who so
graciously packages up Chef for Redhat/CentOS systems.
Today an update went out to EPEL to add rubygem-json 1.4.3. For those
of us using the combination of EPEL and ELFF (mkent's repo)
repositories, this updates rubygem-json from 1.1.9 (from ELFF).
Unfortunately, Chef and Ohai need versions less than or equal to
1.4.2, so Rubygems will refuse to load the chef and ohai gems.
Thanks! I'll certainly look at updating the packages shortly and likely
just carry the working version of rubygem-json in ELFF.
Given a basic installation of EPEL+ELFF, will the presence of <1.4.3
in ELFF alongside the current 1.4.3 in EPEL not result in 1.4.3 being
used?
[I'm aware of the repo prioritisation and yum cli parameters that
could be used to help with this; I'm just interested in the
non-customised situation which might be reasonable/expected given a
pre-chef-install environment]
Jonathan
Jonathan Matthews
London, UK
http://www.jpluscplusm.com/contact.html
I'm gonna go ahead and point out that it's considered best practice to
maintain a private package repository for exactly these reasons.
-s
On Fri, Sep 17, 2010 at 7:33 AM, Jonathan Matthews
contact@jpluscplusm.com wrote:
On 16 September 2010 21:34, Matthew Kent matt@bravenet.com wrote:
On Thu, 2010-09-16 at 01:42 -0500, Leinartas, Michael wrote:
This is half a warning and half a note to Matthew Kent who so
graciously packages up Chef for Redhat/CentOS systems.
Today an update went out to EPEL to add rubygem-json 1.4.3. For those
of us using the combination of EPEL and ELFF (mkent's repo)
repositories, this updates rubygem-json from 1.1.9 (from ELFF).
Unfortunately, Chef and Ohai need versions less than or equal to
1.4.2, so Rubygems will refuse to load the chef and ohai gems.
Thanks! I'll certainly look at updating the packages shortly and likely
just carry the working version of rubygem-json in ELFF.
Given a basic installation of EPEL+ELFF, will the presence of <1.4.3
in ELFF alongside the current 1.4.3 in EPEL not result in 1.4.3 being
used?
[I'm aware of the repo prioritisation and yum cli parameters that
could be used to help with this; I'm just interested in the
non-customised situation which might be reasonable/expected given a
pre-chef-install environment]
Jonathan
Jonathan Matthews
London, UK
http://www.jpluscplusm.com/contact.html
++ always stage your infra
On Sep 17, 2010, at 8:14 AM, Sean OMeara wrote:
I'm gonna go ahead and point out that it's considered best practice to
maintain a private package repository for exactly these reasons.
-s
On Fri, Sep 17, 2010 at 7:33 AM, Jonathan Matthews
contact@jpluscplusm.com wrote:
On 16 September 2010 21:34, Matthew Kent matt@bravenet.com wrote:
On Thu, 2010-09-16 at 01:42 -0500, Leinartas, Michael wrote:
This is half a warning and half a note to Matthew Kent who so
graciously packages up Chef for Redhat/CentOS systems.
Today an update went out to EPEL to add rubygem-json 1.4.3. For those
of us using the combination of EPEL and ELFF (mkent's repo)
repositories, this updates rubygem-json from 1.1.9 (from ELFF).
Unfortunately, Chef and Ohai need versions less than or equal to
1.4.2, so Rubygems will refuse to load the chef and ohai gems.
Thanks! I'll certainly look at updating the packages shortly and likely
just carry the working version of rubygem-json in ELFF.
Given a basic installation of EPEL+ELFF, will the presence of <1.4.3
in ELFF alongside the current 1.4.3 in EPEL not result in 1.4.3 being
used?
[I'm aware of the repo prioritisation and yum cli parameters that
could be used to help with this; I'm just interested in the
non-customised situation which might be reasonable/expected given a
pre-chef-install environment]
Jonathan
Jonathan Matthews
London, UK
http://www.jpluscplusm.com/contact.html
On Fri, 2010-09-17 at 11:14 -0400, Sean OMeara wrote:
I'm gonna go ahead and point out that it's considered best practice to
maintain a private package repository for exactly these reasons.
Given the sheer number of packages involved in the chef server setup and
the potential for breakage like this json issue I'd highly recommend
anyone using it to rsync a stable copy of the whole repo and use plugins
like yum priorities to make use of it's contents.
http://elff.viviti.com/packages has links for rsync.
The original issue should be fixed by updated packages I just pushed. I
patched out the mandatory old json version and built a copy of the
latest json for ELFF.
I've also filed a ticket for an update in Fedora which should trickle
down to EPEL later @
https://bugzilla.redhat.com/show_bug.cgi?id=635034
--
Matthew Kent \ SA \ bravenet.com
That's a great idea. I second that.
Another method is to use "yum --downloadonly install chef" to download
the RPM and its dependencies. Then you can put them in your own
repository if you are already maintaining your own set of RPMs. I've
been doing that for 0.8.16 and then 0.9.6. As Sean wrote earlier, it's
good practice to lock down the libraries you use.
-Paul
On 9/17/10 3:10 PM, Matthew Kent wrote:
On Fri, 2010-09-17 at 11:14 -0400, Sean OMeara wrote:
I'm gonna go ahead and point out that it's considered best practice to
maintain a private package repository for exactly these reasons.
Given the sheer number of packages involved in the chef server setup and
the potential for breakage like this json issue I'd highly recommend
anyone using it to rsync a stable copy of the whole repo and use plugins
like yum priorities to make use of it's contents.
http://elff.viviti.com/packages has links for rsync.
The original issue should be fixed by updated packages I just pushed. I
patched out the mandatory old json version and built a copy of the
latest json for ELFF.
I've also filed a ticket for an update in Fedora which should trickle
down to EPEL later @
635034 – SystemStackError: stack level too deep
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
Is that issue the same / similar to the one I reported?
On Sep 17, 2010, at 4:10 PM, Matthew Kent wrote:
On Fri, 2010-09-17 at 11:14 -0400, Sean OMeara wrote:
I'm gonna go ahead and point out that it's considered best practice to
maintain a private package repository for exactly these reasons.
Given the sheer number of packages involved in the chef server setup and
the potential for breakage like this json issue I'd highly recommend
anyone using it to rsync a stable copy of the whole repo and use plugins
like yum priorities to make use of it's contents.
http://elff.viviti.com/packages has links for rsync.
The original issue should be fixed by updated packages I just pushed. I
patched out the mandatory old json version and built a copy of the
latest json for ELFF.
I've also filed a ticket for an update in Fedora which should trickle
down to EPEL later @
635034 – SystemStackError: stack level too deep
--
Matthew Kent \ SA \ bravenet.com
Opscode, Inc
Joshua Timberman, Technical Evangelist
IRC, Skype, Twitter, Github: jtimberman
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.10 (Darwin)
iEYEARECAAYFAkyT+HUACgkQO97WSdVpzT2rpACfdUlzMAubahoFRoNar5Mu2fSk
Wa0AoIWyBblyVwPmWz9obdtHvJESW/Cg
=hmIq
-----END PGP SIGNATURE-----