Hello,
While working on Katello, I've encountered a strange problem.
We run against Rails 3.0.5 and in development, we use gem packages from 'http://repos.fedorapeople.org/repos/katello/gems/'.
Currently, we were reported a bug while testing in fedora 14 (and it fails in 15 as well) [1]. This bug however didn't appear in the development.
After some investigation, I've found out, that the error was caused by the change in rails officially released in v 3.0.8 [2]. But we have this change included in RPM for rails version 3.0.5.
Do we have to count on this kind of version differences between Gems and RPMs, or there was some problem in packaging?
[1] - https://bugzilla.redhat.com/show_bug.cgi?id=727627#c2 [2] - https://github.com/rails/rails/commit/53a2c0baf2b128dd4808eca313256f6f4bb8c4...
Thanks -- Ivan
On 08/17/2011 12:07 PM, Ivan Nečas wrote:
Do we have to count on this kind of version differences between Gems and RPMs, or there was some problem in packaging?
I guess we call this "backporting" :-)
If you check the SRPM, you will find there is the patch you are referring to. The thing is - we (or ruby-sig in this case) backport important (security related etc) fixes in the released versions. In this case its 3.0.5.
It is not possible to upgrade to 3.0.8 because Fedora 15 is considered as "stable". We are not rolling Gentoo :-) The only way to fix a particular problem is to provide a patch file in the SRPM and bump the epoch number (number three in this case). The gold rule is not to modify the source tarball. For more info see Fedora Packaging Guidelines.
Do this (having yum-utils installed):
$ yumdownloader --source rubygem-activesupport
Unpack the SRPM (or install it) and find this file:
$ md5sum cve-2011-2197-fix.patch 883d8eac854ded578f4d3f3e371fedc4 cve-2011-2197-fix.patch
Here we go...
http://lists.fedoraproject.org/pipermail/package-announce/2011-June/062090.h...
It's more Katello problem - you (we) should all develop on the very same rubygems as users do have. In this case you use original gem files vs gems from RPMs. That is the reason why you see the error in the development.
On 08/18/2011 09:55 AM, Lukas Zapletal wrote:
On 08/17/2011 12:07 PM, Ivan Nečas wrote:
Do we have to count on this kind of version differences between Gems and RPMs, or there was some problem in packaging?
I guess we call this "backporting" :-)
If you check the SRPM, you will find there is the patch you are referring to. The thing is - we (or ruby-sig in this case) backport important (security related etc) fixes in the released versions. In this case its 3.0.5.
It is not possible to upgrade to 3.0.8 because Fedora 15 is considered as "stable". We are not rolling Gentoo :-) The only way to fix a particular problem is to provide a patch file in the SRPM and bump the epoch number (number three in this case). The gold rule is not to modify the source tarball. For more info see Fedora Packaging Guidelines.
Do this (having yum-utils installed):
$ yumdownloader --source rubygem-activesupport
Unpack the SRPM (or install it) and find this file:
$ md5sum cve-2011-2197-fix.patch 883d8eac854ded578f4d3f3e371fedc4 cve-2011-2197-fix.patch
Here we go...
http://lists.fedoraproject.org/pipermail/package-announce/2011-June/062090.h...
It's more Katello problem - you (we) should all develop on the very same rubygems as users do have. In this case you use original gem files vs gems from RPMs. That is the reason why you see the error in the development.
Thanks for explanation. At least I know where to look when such a problem occurs.
Using plain old gems over RPM has some advantages:
1. Some of packages used in development (especially in early stages of some functionality) are not packed to RPM yet. It's more effective to try it out from gem and if we agree it's worth in, it can be packaged
2. Bundler + RVM makes it much easier to keep the development going. For example: "I've make some experiments using SuperAwesomeGem - check out my branch - you will need bundle install before hacking"
3. Some of us use Mac for development - they can't use RPM
What I am trying to say is that pure gems, RVM and bundler are much more effective for the development.
Would be possible to take it from the other end, and reflect the changes we've made to RPM in ruby gem in our private gem source we use with bundler, e.g.: http://repos.fedorapeople.org/repos/katello/gems/. Ideally with some automated process (I think I shouldn't be hard:)
Question: do RPM for gems differ for different distribution: FC14, FC15, RHEL5, RHEL6?: If they do, we could similarly keep separated gem source for every distribution - this could help us in debugging, if we get report, that some distro fails with our app.
What do you think about this apporach?
-- Ivan
On 11-08-18 8:13 AM, Ivan Nečas wrote:
On 08/18/2011 09:55 AM, Lukas Zapletal wrote:
On 08/17/2011 12:07 PM, Ivan Nečas wrote:
Do we have to count on this kind of version differences between Gems and RPMs, or there was some problem in packaging?
I guess we call this "backporting" :-)
If you check the SRPM, you will find there is the patch you are referring to. The thing is - we (or ruby-sig in this case) backport important (security related etc) fixes in the released versions. In this case its 3.0.5.
It is not possible to upgrade to 3.0.8 because Fedora 15 is considered as "stable". We are not rolling Gentoo :-) The only way to fix a particular problem is to provide a patch file in the SRPM and bump the epoch number (number three in this case). The gold rule is not to modify the source tarball. For more info see Fedora Packaging Guidelines.
Do this (having yum-utils installed):
$ yumdownloader --source rubygem-activesupport
Unpack the SRPM (or install it) and find this file:
$ md5sum cve-2011-2197-fix.patch 883d8eac854ded578f4d3f3e371fedc4 cve-2011-2197-fix.patch
Here we go...
http://lists.fedoraproject.org/pipermail/package-announce/2011-June/062090.h...
It's more Katello problem - you (we) should all develop on the very same rubygems as users do have. In this case you use original gem files vs gems from RPMs. That is the reason why you see the error in the development.
Thanks for explanation. At least I know where to look when such a problem occurs.
Using plain old gems over RPM has some advantages:
- Some of packages used in development (especially in early stages of
some functionality) are not packed to RPM yet. It's more effective to try it out from gem and if we agree it's worth in, it can be packaged
- Bundler + RVM makes it much easier to keep the development going. For
example: "I've make some experiments using SuperAwesomeGem - check out my branch
- you will need bundle install before hacking"
- Some of us use Mac for development - they can't use RPM
What I am trying to say is that pure gems, RVM and bundler are much more effective for the development.
Would be possible to take it from the other end, and reflect the changes we've made to RPM in ruby gem in our private gem source we use with bundler, e.g.: http://repos.fedorapeople.org/repos/katello/gems/. Ideally with some automated process (I think I shouldn't be hard:)
That would work, and we'll be able to use bundler again! Definitely +1 from me. -d
Question: do RPM for gems differ for different distribution: FC14, FC15, RHEL5, RHEL6?: If they do, we could similarly keep separated gem source for every distribution - this could help us in debugging, if we get report, that some distro fails with our app.
What do you think about this apporach?
-- Ivan
ruby-sig mailing list ruby-sig@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/ruby-sig
On 08/18/2011 01:13 PM, Ivan Nečas wrote:
Question: do RPM for gems differ for different distribution: FC14, FC15, RHEL5, RHEL6?: If they do, we could similarly keep separated gem source for every distribution - this could help us in debugging, if we get report, that some distro fails with our app.
They can be different, yes.
What do you think about this apporach?
I would note that I would prefer patching the upstream. In this case asking rubygem author to release 3.0.5.1 patched gem (not sure if rubygems support such a convention). And then to use it.
Is it necessary to put that effort in maintaining our own rubygems just because few developers (incl. me) do use RVM instead recommended RPM gems? I would go for patching upstream if it blocks us (e.g. maybe this case - the gettext issue), but for other cases I would recommend to live with it.
On 08/18/2011 07:58 AM, Lukas Zapletal wrote:
On 08/18/2011 01:13 PM, Ivan Nečas wrote:
Question: do RPM for gems differ for different distribution: FC14, FC15, RHEL5, RHEL6?: If they do, we could similarly keep separated gem source for every distribution - this could help us in debugging, if we get report, that some distro fails with our app.
They can be different, yes.
What do you think about this apporach?
I would note that I would prefer patching the upstream. In this case asking rubygem author to release 3.0.5.1 patched gem (not sure if rubygems support such a convention). And then to use it.
Well the newer upstream release is the patched version, eg 3.0.8 contains this fix.
The issue is that we lock the version in any given Fedora release, perhaps its time to revisit this policy for certain packages, especially as they stabilize more (so long as backwards compatibility is preserved).
-Mo
ruby-sig@lists.fedoraproject.org
-
Dmitri Dolguikh -
Ivan Necas -
Lukas Zapletal -
Mo Morsi