Hi everybody,
Since Ruby 2.2 is going to be released during Christmas and -preview1
release is imminent (this Wednesday?), it is probably time to start
looking into its packaging. So here is the updated .spec file [1] and
scratch build [2], which can be finally build on all platforms. Sorry,
no Copr for you, since Ruby's build fails there due to old RHEL kernel :/.
What has changed from packaging point of view? Luckily, not much, but
here are a few bullets which comes to my mind:
* RPM 4.12 introduces new %load function, which is used to load RPM
macros during RPM build. This allowed to drop my custom RPM macro [3].
On the other hand, you'll be able to build the Ruby only on F21+
(luckily, you should be able to build SRPM everywhere).
* The RubyGems filesystem was not explicit enough, so there might be
something accidentally packages. This is now more explicit, so we should
be safer.
* Ruby now ships with MiniTest and Test::Unit. The very good news is
that they are installed so far as a regular gems. This means that you
have to always specify them in your Gemfile, if you are using Bundler,
but this is generally step in good direction. I hope that upstream will
not change their mind :) Due to this change, we have new subpackages
rubygem-test-unit (and rubygem-power_assert, which is now Test::Unit's
dependency). No more %{_bindir}/testrb (but nobody is using it these
days anyway, right? ;)
* Some prevailing test failures were resolved, some others introduced,
but hopefully they'll get resolved prior stable release.
Generally, I'd say that not much has changed since 2.1, which is good news.
Please test the packaging if you can and let me know about any issues
you encountered.
Also, if you have any other suggestions about Ruby packaging in general,
what we could improve etc, this is probably good time to share. It seems
that OpenSUSE guys are improving their packaging, so you might want to
get some inspiration there [4, 5, 6] ;)
Vít
[1] http://pkgs.fedoraproject.org/cgit/ruby.git/log/?h=private-ruby-2.2
[2] http://koji.fedoraproject.org/koji/taskinfo?taskID=7578843
[3]
http://pkgs.fedoraproject.org/cgit/ruby.git/commit/?h=private-ruby-2.2&id=8…
[4] https://build.opensuse.org/package/show/home:darix:ruby/ruby-common
[5] https://build.opensuse.org/package/show/home:darix:ruby/ruby2.2
[6] https://github.com/openSUSE/gem2rpm/commits/master
Hi guys,
Anybody have any experience with some scripts for bash completion? Have
you tried any? Should we integrate any? Just a quick googling gave me
two results:
https://github.com/mernen/completion-rubyhttps://github.com/pdkl95/rubygems-completion
And there are probably others. I did not tried them yet. Have you? Do
you have other/better tips?
Thank you
Vit
>
> Also, some of the packages you list above are what I'd class as
> development or test packages, which should be much lower priority for
> you. Focus on packaging runtime dependencies and you'll get there quicker.
Yeah, non-test, non-development ones seem to be more available than others.
Thanks for links btw, Dominic.
we update Ruby on Rails
> and many other gems. That means all packaged applications have to be
> updated as well. And that's why we
> have only one Rails app in Fedora.
Now there are two ;) I promise I will help with packaging. And don't worry
Sarup, I will do it on my own time.
A production ready application with unpackaged dependencies > one with all
> dependencies packaged but won't see use because of unfinished crucial
> features. The reverse would be true if we had several people working on the
> project simultaneously,
We will also need to bring Kushal on board with this.
Thanks a lot guys. You have been really helpful. I will read everything and
get back to you if I need help.
Aditya
On Fri, May 29, 2015 at 11:45 PM, Sarup Banskota <sbanskota08(a)gmail.com>
wrote:
> Very resourceful discussion.
>
> I have zero experience with packaging stuff myself, so what I may write in
> this email might be naive thinking.
>
> My short-term suggestion: IMO, you should continue with your work as usual
> on the git server and SparkleShare side of things for now. A production
> ready application with unpackaged dependencies > one with all dependencies
> packaged but won't see use because of unfinished crucial features. The
> reverse would be true if we had several people working on the project
> simultaneously, because someone's time spent packaging would mean another
> could work on features. Right now it's mostly you doing any programmatic
> activity, so how you spend your time affects when we can let people use it.
>
> Once we're into production ready phase, we can do two things in parallel:
> one, try to work with any feedback we may receive and two, start with
> packaging production gems (following the process Ken laid out). In fact,
> when it's visible people are using the application, we're more likely to
> see folks from the Ruby SIG want to guide us package gems, and we could
> definitely use that guidance.
>
> >
> > Phase 1) Create an RPM that more-or-less follows all the packaging
> > guidelines, but bundles all its dependencies. You can build/ship this
> > RPM via Copr.
> >
> > Phase 2) Switch your application from using Bundler to using
> > https://rubygems.org/gems/bundler_ext
> >
> > Phase 3) Start dropping your bundled gems one by one and use the
> > system gems instead.
> >
> > In hindsight I wish that I had taken this approach with Gitorious or
> > Gitlab, instead of only starting at the base of the dependency tree
> > and working my way upwards. It's probably good to work from both
> > directions at once. But starting at the top, with the app itself, will
> > give you the satisfaction and internal motivation of having something
> > that works today, even if it's not up to Fedora's standards.
> >
>
> +1.
>
> What do you think, @Emily?
>
>
>
hi,
I will start with sort introduction before I come to the topic. My name is
Aditya Prakash. I am second year CSE student at NIT Durgapur
<http://www.nitdgp.ac.in/>, India. I am working on GlitterGallery
<https://github.com/glittergallery/GlitterGallery> webapp (in rails) under
GSoC.
Today in fedora-infra meetting, Kushal mentioned that it is important that
whatever gem I use, I should make sure that it comes as rpm package. Good
people of ruby-sig have already build packages of many popular gems (link
here <http://www.isitfedoraruby.com/>). Unfortunately, there are still many
gems which aren't available on rawhide and there are others which aren't
upto date with upstream. ex: guard <https://github.com/guard/guard>,
cancancan <https://github.com/CanCanCommunity/cancancan>, capybara-webkit
<https://github.com/thoughtbot/capybara-webkit>, omniauth-facebook
<https://github.com/mkdynamic/omniauth-facebook>, haml-lint
<https://github.com/brigade/haml-lint>, rubocop
<https://github.com/bbatsov/rubocop> etc.
My guess is that atleast 50 gems from my gemlist.lock file would need
packaging or update. However, GlitterGalley is not an app app but it is a
web app. What I am trying to say is that main purpose of of GG is that it
is hosted on cloud somewhere and people will use to from web-browsers. How
important it is that gems I am using have rpm available? A good amount of
development time will be wasted in packaging if this is a requirement.
Also, how important it is that rpm package are available for ruby gems in
general? In name of being a ruby developer and part of fedora community I
would like to package a few important ones.
Thank you.
Hi all.
I want to participate to Ruby SIG.
I want to know you better and also what task are in progress and we
are waiting for realization.
Best regards
Dear ruby wizards,
As of now, there are some open bugs in fedora-review's ruby plugin [1]
Basically, we need some input on these to sort out how this should work.
However, here is also a more basic issue: who should maintain the ruby
plugin? Frankly, keeping track of all upcoming changes isn't that easy
when lacking specific ruby skills (which is what the open bugs are all
about).
Since some releases we have "outsourced" the java plugin to the java
SIG; the fedora-review-plugin-java is now part of javapackages-tools. I
think we have now stabilized the plugin interface. Basically, this has
made life easier both for me (no java wizard) and for the java SIG which
can enforce their packaging rules by modifying or adding tests.
From my perspective it would be nice to apply this organization also to
the ruby plugin i. e., create a fedora-review-plugin-ruby package
somehow maintained by the ruby SIG.
Thoughts?
--alec
[1]:
https://bugzilla.redhat.com/show_bug.cgi?id=1128094https://fedorahosted.org/FedoraReview/ticket/225https://fedorahosted.org/FedoraReview/ticket/238
Vít Ondruch wrote on 04/28/2015 11:52 PM:
> Dne 28.4.2015 v 11:35 Kalev Lember napsal(a):
>> On 04/28/2015 10:16 AM, Vít Ondruch wrote:
>>> Dne 28.4.2015 v 00:45 Kalev Lember napsal(a):
>>>> rubygem-rugged tdawson
>>>>
>>> I am not maintainer of this, but please do not remove this. Rugged was
>>> broken by unannounced libgit2 update and there is still not official
>>> release fixing the compatibility. Removing this rubygem will mean just
>>> more work for everybody involved.
>> libgit2 is at 0.22.2 and looks like there's a matching new Rugged
>> release at https://rubygems.org/gems/rugged/versions/0.22.1b1 and the
>> package just needs updating. I am not sure what's up with the
>> maintainer, but maybe you could help them out by comaintaining
>> rubygem-rugged?
>
> If you take a look on version history [1], you'll notice that the "b"
> in version stands for beta. I have not checked with upstream what is the
> plan, though.
>
> [1] https://rubygems.org/gems/rugged/versions
But this is branched as "maint/v0.22", and I think using this beta
is much preferable than to keep broken deps, thought?
By the way, I am not a maintainer of rubygem-rugged, either, and
I don't use rubygem-rugged (currently). Anyway I want to know
how the current maintainer think of the current status.
If the current maintainer has no interest on this package,
maybe it is better to get this retired.
>>
>> When it comes to shipping F22, I don't think it makes sense to include a
>> package that is so horribly broken that it cannot even be installed. But
>> if you guys are actively working on fixing it, I am sure we can try and
>> convince releng to give it a few more days before blocking so that it
>> can be pulled in through the freeze through the FE process:
>> https://fedoraproject.org/wiki/QA:SOP_freeze_exception_bug_process
>>
>> Also, please note that Fedora policies allow adding new packages in the
>> updates repo, so even if something gets dropped now, it can always be
>> fixed and shipped in the updates repo at a later date.
>>
>
> Which means re-review ...
>
> Vít
>
Regards,
Mamoru
Today while looking into the status of a Fedora / EPEL related issue, I
made good use of the isitfedoraruby website lookup the package
dependency tree [1]. From what I know this visualization / data
aggregation is not available anywhere else and it still looks and works
great.
Again kudos goes to all the students involved with the project over the
years for building a solid app!
-Mo
[1] http://www.isitfedoraruby.com/fedorarpms/rubygem-crack/full_deps