This email is just to know if anyone from this SIG will be attending
Tempe Fudcon2011, i will, so it would be nice to use FUDCon to promote
ruby in general so i would like to start gathering info to get together
Toshio proposed to me the idea of coding dojos for fudcons but this idea
My bet is we could use fudcon to make fedora-ruby a better platform in
all senses, maybe solve issues at the hackfests.
As written on Fedora "general" packaging guideline , and as
kanarip explained on this mailing list, generally we do not allow
to use gems including vendorized external gems.
Now as I saw a review request based on a rubygem containing vendorlized
external gems , I searched for rubygem based rpms on Fedora rawhide
containing vendorlized gems and actually we already ships such ones:
Owner srpm bin_rpm
kanarip rubygem-picnic-0.8.1-2.fc12 rubygem-picnic
kanarip rubygem-shoulda-2.11.3-1.fc15 rubygem-shoulda-doc
mmorsi rubygem-actionmailer-2.3.8-1.fc15 rubygem-actionmailer
mmorsi rubygem-actionpack-2.3.8-2.fc15 rubygem-actionpack
mmorsi rubygem-activesupport-2.3.8-2.fc15 rubygem-activesupport
mmorsi rubygem-compass-0.8.17-3.fc14 rubygem-compass
mtasaka rubygem-activeldap-1.2.1-1.fc13 rubygem-activeldap
mtasaka rubygem-gettext_activerecord-2.1.0-1.fc13 rubygem-gettext_activerecord-doc
mtasaka rubygem-gettext_rails-2.1.0-3.fc14 rubygem-gettext_rails-doc
( I have 3....)
For example, activesupport 2.3.8 contains builder-2.1.2, i18n-0.3.7, memcache-client-1.7.4,
tzinfo-0.3.12. All of them should be packaged separately and activesupport should depend
on such separately packaged rubygem related packages.
Unless there are some opinions that this kind of bundling external projects should
be allowed, I will file bugs for these packages on RH bugzilla (and also I have to
fix such bugs) Note that I guess this kind of bundling external projects should also
require FESCO's approval anyway.
I'd like to bump rubygem-rack to the latest (1.2.1) in Rawhide and
EPEL. I was worried about EPEL and even started making a seperate
branch for a rack1 package, but according to my queries, the only
packages requiring rack in EPEL are:
stahnma@tyr /home/stahnma> repoquery -q --whatrequires "rubygem(rack)"
stahnma@olive /home/stahnma> repoquery --whatrequires "rubygem(rack)"
There are some API changes between rack-0.9 and rack-1.2, but mostly
semantics. For rawhide/fedora, I am pretty sure it will be ok. What
are the thoughts for this update in EPEL? It would allow sinatra,
shotgun, and possibly a new (parallel) version of rails.
After some vetting (thanks Mamoru) the Rails 2.3.8 rpms are Fedora
ready and pushed into rawhide. Feel free to pull from there to get the
latest stable 2.3.x rails build.
It's too late for the F14 release and I was contemplating whether or not
these should go into F14 updates. Would anyone object to this? If there
is any major incompatibilities or API changes between versions, we
should probably hold off to F15, but it would be nice to be able to
access these sooner than that.
FYI we are working on Fedora SELinux policy for mod_passenger.
This policy will be part of Apache SELinux policies, so mod_passenger
will just work out of the box.
Because packaging of mod_passenger is a bit complicated (boots issues)
we will support 'gem' installation method (gem install passenger) for now.
This policy should be ready for testing until next week.