ruby-sig June 2018

ruby-sig@lists.fedoraproject.org

3 participants
8 discussions

Ruby 2.2
by Vít Ondruch 22 Sep '23

22 Sep '23

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 19

Re: Starting CI for Rails
by Jun Aruga 27 Jun '18

27 Jun '18

>> - What is the trigger to run CI? > > > The running is currently run for each koji build and dist-git pull request > ... > > >> >> Both cron (regular running) and trigger by pull-request to target >> RPM packages repositoris? > > > There is no cron, it reacts on a finished koji build (scratch or > non-scratch) Okay, which package's koji build is the target for the trigger? Is it only rpms/ruby? Because we are actually testing Rails in the CI test. I prefer every Ruby on Rails groups are the target. https://apps.fedoraproject.org/koschei/groups/ruby-rails And here are 6 use cases for testing Rails. I want to add these 6 uses cases to CI at first. https://github.com/junaruga/fedora-blog/blob/master/2018-06-20-test-for-rai… I have not checked at the target Fedora CI documents yet. Jun On Wed, Jun 20, 2018 at 6:33 PM, Miroslav Vadkerti <mvadkert(a)redhat.com> wrote: > Hi, > > On Wed, Jun 20, 2018 at 5:02 PM, Jun Aruga <jaruga(a)redhat.com> wrote: >> >> Hi Miroslav, >> >> Thanks for the cooperation. > > > Sure thing :) > > >> >> >> > And you would like to automate as much as possible from that, cool. >> >> Yes, as much as possible :) >> >> > I created that shared test space [1] some time ago. The idea behind >> > it was to host ruby related integration and other tests, that work on >> > all >> > supported >> > Fedora releases and do not fit into a specific component's dist-git. >> > Idea >> > for them was to include link them from multiple ruby packages. >> > >> > In your case, I guess theste tests could be added here, as they seem >> > to be generic enough. If you would need to include that test also >> > from other compoents, just link them according to [1] >> >> Your idea is exactly what I want. >> >> > This is also a possibility, but I would be against it (creating another >> > repository in tests namespace). Feel free to use the tests/ruby repo, >> > if you decide to go with the shared test repository. >> >> > If you feel that these tests are not integration, and are really >> > for ruby-on-rails, please add the directly to dist-git [2], similarly >> > to what I did lately for rubygem-bundler [3] >> >> Right now I will try to understand the way for option 1: tests/ruby at >> first, reading the document. >> In the future if it is problem to manage the rails test by test/ruby, >> we can split and move it. >> >> Maintaining the rails tests on 1 part is better and easier. > > > Sure, you should choose as you like. > > >> >> >> >> At first what I want to know is >> - How to run Fedora CI manually. > > > The pipeline itself cannot be run manually, but that should not be needed > very much. You should be able to execute tests on a VM or inside a docker > image via ansible. Quick start guide is here: > > https://fedoraproject.org/wiki/CI/Quick_Start_Guide > > >> >> - What is the trigger to run CI? > > > The running is currently run for each koji build and dist-git pull request > ... > > >> >> Both cron (regular running) and trigger by pull-request to target >> RPM packages repositoris? > > > There is no cron, it reacts on a finished koji build (scratch or > non-scratch) > > >> >> > [2] >> https://src.fedoraproject.org/rpms/rubygem-rails >> >> >> What is the actual link? > > > I think it was this :) > > HTH > /M > > >> >> >> Jun >> >> >> On Tue, Jun 19, 2018 at 5:23 PM, Miroslav Vadkerti <mvadkert(a)redhat.com> >> wrote: >> > Hi Jun! >> > >> > On Tue, Jun 19, 2018 at 3:12 PM, Jun Aruga <jaruga(a)redhat.com> wrote: >> >> >> >> Hi @mvadkert, and people in Ruby SIG >> >> >> >> @mvadkert, I found you in below pull-request. >> >> https://src.fedoraproject.org/rpms/rubygem-bundler/pull-request/4 >> >> And I was introduced by Vit that you are good person to discuss about >> >> CI (Fedora CI?). >> > >> > >> > That is correct, I am adding our mailing list, where there are more of >> > us :) >> > >> > >> >> >> >> >> >> The thing that I want to discuss with you, and what I want to improve >> >> is to add CI environment for Ruby on Rails. >> > >> > >> > I see, cool! >> > >> > >> >> >> >> >> >> For every version up of Ruby on Rails, in my impression, we are doing >> >> similar things manually such as running use cases on page [1], editing >> >> packages in rubyonrails group file in fedora-comps project, fixing >> >> build failure seeing [3]. >> > >> > >> > And you would like to automate as much as possible from that, cool. >> > >> >> >> >> >> >> There are options >> >> Option 1. Update tests/ruby. The Rails test has already been in >> >> >> >> >> >> https://src.fedoraproject.org/tests/ruby/blob/master/f/run-basic-rails-appl… >> > >> > >> > I created that shared test space [1] some time ago. The idea behind >> > it was to host ruby related integration and other tests, that work on >> > all >> > supported >> > Fedora releases and do not fit into a specific component's dist-git. >> > Idea >> > for them was to include link them from multiple ruby packages. >> > >> > In your case, I guess theste tests could be added here, as they seem >> > to be generic enough. If you would need to include that test also >> > from other compoents, just link them according to [1] >> > >> >> . >> >> Option 2. Create new tests name space >> >> - 2.1. tests/rubygem-rails (rubygem-rails is a top package of Ruby on >> >> Rails.) >> >> - 2.2. tests/rails (Simple name) >> >> - 2.3. tests/ruby-rails (Same name with the group name [3]) >> >> - 2.4. tests/rubyonrails (Same name with the group name [2]) >> > >> > >> > This is also a possibility, but I would be against it (creating another >> > repository in tests namespace). Feel free to use the tests/ruby repo, >> > if you decide to go with the shared test repository. >> > >> > If you feel that these tests are not integration, and are really >> > for ruby-on-rails, please add the directly to dist-git [2], similarly >> > to what I did lately for rubygem-bundler [3] >> > >> >> >> >> How do you think about it? >> > >> > >> > Note that there is not clear winner here. It all depends on you how >> > you want to structure and maintain your test code. >> > >> > >> >> >> >> Which name space is better to run the CI for rails? >> >> Personally I prefer 2. because I want to run only rails related tests >> >> without necessary dependencies. >> > >> > >> > I would go for 1. or directly to dist-git of ruby-on-rails as tried >> > to explain aboce. >> > >> > >> >> >> >> The feed back from other people is welcome. >> > >> > >> > Feel free to reach out if this still would be unclear or I can >> > provide any more info. >> > >> > HTH, >> > >> > /M >> > >> > >> >> >> >> >> >> [1] https://fedoraproject.org/wiki/Changes/R >> >> >> >> For integration tests, this is a very nice fit. We could simply also >> >> >> >> include this integration test to >> >> >> >> uby_on_Rails_5.2 >> >> [2] https://pagure.io/fedora-comps/blob/master/f/comps-f29.xml.in#_5204 >> >> [3] https://apps.fedoraproject.org/koschei/groups/ruby-rails >> >> >> > >> > [1] what is shared test namespace: >> > https://fedoraproject.org/wiki/CI/Share_Test_Code >> > [2] >> > [3] https://src.fedoraproject.org/rpms/rubygem-bundler/pull-request/4 >> > >> > >> >> >> >> >> >> -- >> >> Jun Aruga jaruga(a)redhat.com >> > >> > >> > >> > >> > -- >> > Miroslav Vadkerti :: Principal QE :: BaseOS QE Security >> > IRC mvadkert #qe #urt #brno #rpmdiff :: GPG 0x25881087 >> > Desk Phone +420 532 294 129 :: Mobile +420 773 944 252 >> > Red Hat Czech s.r.o, Purkyňova 99/71, 612 00, Brno, CR >> > >> >> >> >> -- >> Jun Aruga jaruga(a)redhat.com >> IRC: jaruga, Office: TPB(Technology Park Brno) Building C 1F, Brno, >> Czech Republic > > > > > -- > Miroslav Vadkerti :: Principal QE :: BaseOS QE Security > IRC mvadkert #qe #urt #brno #rpmdiff :: GPG 0x25881087 > Desk Phone +420 532 294 129 :: Mobile +420 773 944 252 > Red Hat Czech s.r.o, Purkyňova 99/71, 612 00, Brno, CR > -- Jun Aruga jaruga(a)redhat.com IRC: jaruga, Office: TPB(Technology Park Brno) Building C 1F, Brno, Czech Republic

1 0

Testing Rails 5.2.0
by Jun Aruga 22 Jun '18

22 Jun '18

Hi Pavel, I am testing Rails 5.2.0 now seeing below document. https://fedoraproject.org/wiki/Changes/Ruby_on_Rails_5.2 I have 2 questions for you. I installed Rails 5.2 with group install. $ mock -r fedora-rawhide-x86_64 --dnf-cmd group install 'Ruby on Rails' ... ========================================================================================================= Group Packages ========================================================================================================= Marking packages as installed by the group: @Ruby on Rails rubygem-uglifier rubygem-selenium-webdriver rubygem-spring-watcher-listen ruby-devel rubygem-abrt rubygem-json rubygem-sqlite3 rubygem-byebug rubygem-listen rubygem-sass-rails rubygem-puma rubygem-turbolinks rubygem-web-console nodejs rubygem-jbuilder rubygem-rails rubygem-spring rubygem-bcrypt rubygem-capybara .... Then my question is it seems that rubygem-coffee-rails is not marked as the group. even though it is included in https://pagure.io/fedora-comps/blob/master/f/comps-f29.xml.in#_5204 Do you know why? My 2nd question is it seems chromedriver-helper gem is in the app's Gemfile from Rails 5.2.0. Do you have a plan to do RPM packaging for this gem? https://github.com/rails/rails/blob/v5.2.0/railties/lib/rails/generators/ra… Thanks. -- Jun Aruga jaruga(a)redhat.com

2 10

Re: Starting CI for Rails
by Jun Aruga 20 Jun '18

20 Jun '18

Hi Miroslav, Thanks for the cooperation. > And you would like to automate as much as possible from that, cool. Yes, as much as possible :) > I created that shared test space [1] some time ago. The idea behind > it was to host ruby related integration and other tests, that work on all > supported > Fedora releases and do not fit into a specific component's dist-git. Idea > for them was to include link them from multiple ruby packages. > > In your case, I guess theste tests could be added here, as they seem > to be generic enough. If you would need to include that test also > from other compoents, just link them according to [1] Your idea is exactly what I want. > This is also a possibility, but I would be against it (creating another > repository in tests namespace). Feel free to use the tests/ruby repo, > if you decide to go with the shared test repository. > If you feel that these tests are not integration, and are really > for ruby-on-rails, please add the directly to dist-git [2], similarly > to what I did lately for rubygem-bundler [3] Right now I will try to understand the way for option 1: tests/ruby at first, reading the document. In the future if it is problem to manage the rails test by test/ruby, we can split and move it. Maintaining the rails tests on 1 part is better and easier. At first what I want to know is - How to run Fedora CI manually. - What is the trigger to run CI? Both cron (regular running) and trigger by pull-request to target RPM packages repositoris? > [2] What is the actual link? Jun On Tue, Jun 19, 2018 at 5:23 PM, Miroslav Vadkerti <mvadkert(a)redhat.com> wrote: > Hi Jun! > > On Tue, Jun 19, 2018 at 3:12 PM, Jun Aruga <jaruga(a)redhat.com> wrote: >> >> Hi @mvadkert, and people in Ruby SIG >> >> @mvadkert, I found you in below pull-request. >> https://src.fedoraproject.org/rpms/rubygem-bundler/pull-request/4 >> And I was introduced by Vit that you are good person to discuss about >> CI (Fedora CI?). > > > That is correct, I am adding our mailing list, where there are more of us :) > > >> >> >> The thing that I want to discuss with you, and what I want to improve >> is to add CI environment for Ruby on Rails. > > > I see, cool! > > >> >> >> For every version up of Ruby on Rails, in my impression, we are doing >> similar things manually such as running use cases on page [1], editing >> packages in rubyonrails group file in fedora-comps project, fixing >> build failure seeing [3]. > > > And you would like to automate as much as possible from that, cool. > >> >> >> There are options >> Option 1. Update tests/ruby. The Rails test has already been in >> >> https://src.fedoraproject.org/tests/ruby/blob/master/f/run-basic-rails-appl… > > > I created that shared test space [1] some time ago. The idea behind > it was to host ruby related integration and other tests, that work on all > supported > Fedora releases and do not fit into a specific component's dist-git. Idea > for them was to include link them from multiple ruby packages. > > In your case, I guess theste tests could be added here, as they seem > to be generic enough. If you would need to include that test also > from other compoents, just link them according to [1] > >> . >> Option 2. Create new tests name space >> - 2.1. tests/rubygem-rails (rubygem-rails is a top package of Ruby on >> Rails.) >> - 2.2. tests/rails (Simple name) >> - 2.3. tests/ruby-rails (Same name with the group name [3]) >> - 2.4. tests/rubyonrails (Same name with the group name [2]) > > > This is also a possibility, but I would be against it (creating another > repository in tests namespace). Feel free to use the tests/ruby repo, > if you decide to go with the shared test repository. > > If you feel that these tests are not integration, and are really > for ruby-on-rails, please add the directly to dist-git [2], similarly > to what I did lately for rubygem-bundler [3] > >> >> How do you think about it? > > > Note that there is not clear winner here. It all depends on you how > you want to structure and maintain your test code. > > >> >> Which name space is better to run the CI for rails? >> Personally I prefer 2. because I want to run only rails related tests >> without necessary dependencies. > > > I would go for 1. or directly to dist-git of ruby-on-rails as tried > to explain aboce. > > >> >> The feed back from other people is welcome. > > > Feel free to reach out if this still would be unclear or I can > provide any more info. > > HTH, > > /M > > >> >> >> [1] https://fedoraproject.org/wiki/Changes/R >> >> For integration tests, this is a very nice fit. We could simply also >> >> include this integration test to >> >> uby_on_Rails_5.2 >> [2] https://pagure.io/fedora-comps/blob/master/f/comps-f29.xml.in#_5204 >> [3] https://apps.fedoraproject.org/koschei/groups/ruby-rails >> > > [1] what is shared test namespace: > https://fedoraproject.org/wiki/CI/Share_Test_Code > [2] > [3] https://src.fedoraproject.org/rpms/rubygem-bundler/pull-request/4 > > >> >> >> -- >> Jun Aruga jaruga(a)redhat.com > > > > > -- > Miroslav Vadkerti :: Principal QE :: BaseOS QE Security > IRC mvadkert #qe #urt #brno #rpmdiff :: GPG 0x25881087 > Desk Phone +420 532 294 129 :: Mobile +420 773 944 252 > Red Hat Czech s.r.o, Purkyňova 99/71, 612 00, Brno, CR > -- Jun Aruga jaruga(a)redhat.com IRC: jaruga, Office: TPB(Technology Park Brno) Building C 1F, Brno, Czech Republic

1 0

Starting CI for Rails
by Jun Aruga 19 Jun '18

19 Jun '18

Hi @mvadkert, and people in Ruby SIG @mvadkert, I found you in below pull-request. https://src.fedoraproject.org/rpms/rubygem-bundler/pull-request/4 And I was introduced by Vit that you are good person to discuss about CI (Fedora CI?). The thing that I want to discuss with you, and what I want to improve is to add CI environment for Ruby on Rails. For every version up of Ruby on Rails, in my impression, we are doing similar things manually such as running use cases on page [1], editing packages in rubyonrails group file in fedora-comps project, fixing build failure seeing [3]. There are options Option 1. Update tests/ruby. The Rails test has already been in https://src.fedoraproject.org/tests/ruby/blob/master/f/run-basic-rails-appl… . Option 2. Create new tests name space - 2.1. tests/rubygem-rails (rubygem-rails is a top package of Ruby on Rails.) - 2.2. tests/rails (Simple name) - 2.3. tests/ruby-rails (Same name with the group name [3]) - 2.4. tests/rubyonrails (Same name with the group name [2]) How do you think about it? Which name space is better to run the CI for rails? Personally I prefer 2. because I want to run only rails related tests without necessary dependencies. The feed back from other people is welcome. [1] https://fedoraproject.org/wiki/Changes/Ruby_on_Rails_5.2 [2] https://pagure.io/fedora-comps/blob/master/f/comps-f29.xml.in#_5204 [3] https://apps.fedoraproject.org/koschei/groups/ruby-rails -- Jun Aruga jaruga(a)redhat.com

1 0

RubyGems package contribution workshop on Flock 2018
by Jun Aruga 08 Jun '18

08 Jun '18

The annual Fedora community event Flock 2018 [1] is going to be held from August 8th to 11th. And there is a page to propose talk or workshop. [2]. I posted my proposal for talks & workshop about contributing for RubyGem upstream, and Fedora RubyGems packaging there. If you have some requests and needs for workshop, please feel free to comment in the page or for this mail. If you would attend the Flock 2018 event, I might ask you to assist the workshop. I believe that this workshop makes an opportunity for people to know Fedora Ruby SIG. [1] https://flocktofedora.org/ [2] https://pagure.io/flock/issue/16 -- Jun Aruga

1 0

Rails on Rails 5.2.0
by Pavel Valena 07 Jun '18

07 Jun '18

Hello, Rails 5.2 should be fully built in my Copr[1](feel free to test it) and I started to rebuild the packages in Rawhide. Some of the new dependencies are still missing, and await the Review: https://bugzilla.redhat.com/show_bug.cgi?id=1586199 - rubygem-mini_magick https://bugzilla.redhat.com/show_bug.cgi?id=1586295 - rubygem-bootsnap Please do review if you can. Thanks! Pavel [1] https://copr.fedorainfracloud.org/coprs/pvalena/ruby-on-rails/

2 1

[ANN] gem2rpm 1.0.1
by Vít Ondruch 01 Jun '18

01 Jun '18

Hi everybody, Today I released gem2rpm 1.0.1. There are no significant changes in what gem2rpm is doing. However, there is one significant change in templates, which is due to updated RPM and Ruby packaging guidelines. So starting by this release, gem2rpm supports expanding of the package using %setup macro. This should simplify your packages a bit. Feel free to grab the updated package from rubygem.org or updates are available in updates-testing for F27+ and EPEL6+. Vít

1 0

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

ruby-sig June 2018