ruby-sig May 2015

ruby-sig@lists.fedoraproject.org

9 participants
10 discussions

Ruby 2.2
by Vít Ondruch 25 Jan '22

25 Jan '22

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

4 18

BASH completion for Ruby
by Vít Ondruch 25 May '16

25 May '16

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-ruby https://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

2 3

Ruby 2.3
by Vít Ondruch 23 Dec '15

23 Dec '15

Hi everybody, I needed to check something in development version of Ruby today, so it was good opportunity to prepare updated package with the latest bits. I'll keep updating the sources in dist git private branch [1]. This should be the scratch build (if it succeeds): http://koji.fedoraproject.org/koji/taskinfo?taskID=8810288 As always, let me know if you encounter any issues. Vít [1] http://pkgs.fedoraproject.org/cgit/ruby.git/log/?h=private-ruby-2.3

3 20

Re: rpm package for ruby gems
by Aditya Prakash 29 May '15

29 May '15

> > 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? > > >

1 0

rpm package for ruby gems
by Aditya Prakash 29 May '15

29 May '15

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.

4 5

Hi all
by Mr Coffeina 27 May '15

27 May '15

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

2 1

fedora-review ruby plugin
by Alec Leamas 25 May '15

25 May '15

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=1128094 https://fedorahosted.org/FedoraReview/ticket/225 https://fedorahosted.org/FedoraReview/ticket/238

3 8

[ANN] gem2rpm 0.11.1
by Vít Ondruch 11 May '15

11 May '15

Hi everybody, I just want to let you know that I have released gem2rpm 0.11.1. Here are some highlights: * New helpers for %files section preparation. * Add vagrant templates. * /etc/os-release support. * Add PLD Linux support. * Always add dot at the end of description. * Use non-versioned template if OS is detected but versioned template is not available. Since you probably missed some of the features, I suggest you to give it a try. BTW there are updates available* for all Fedoras and EPEL. Vít * https://admin.fedoraproject.org/updates/rubygem-gem2rpm-0.11.1-1.fc22 https://admin.fedoraproject.org/updates/rubygem-gem2rpm-0.11.1-1.fc21 https://admin.fedoraproject.org/updates/rubygem-gem2rpm-0.11.1-1.fc20 https://admin.fedoraproject.org/updates/rubygem-gem2rpm-0.11.1-1.el7 https://admin.fedoraproject.org/updates/rubygem-gem2rpm-0.11.1-1.el6

1 0

Re: Removing packages that have broken dependencies in F22 tree
by Mamoru TASAKA 05 May '15

05 May '15

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

2 2

is it fedora ruby shout out
by Mo Morsi 05 May '15

05 May '15

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

1 0

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

ruby-sig May 2015