ruby-sig July 2018

ruby-sig@lists.fedoraproject.org

5 participants
9 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

BR: gcc vs gcc-c++
by Vít Ondruch 30 Aug '18

30 Aug '18

Hi, Ruby currently fails to build due to removal of GCC from buildroot. The build failure is due to one test case [1] which fails now and which should be probably fixed to pass even without GCC. However, digging into this, I wonder if Ruby should have "BR: gcc" or "BR: gcc-c++". The thing is, that Ruby is checking presence of C++ compiler during its configuration phase. When I was asking upstream what is the reason for that [2], the answer was that some extension/gems might use C++. Generally, for distribution purpose, I think that it does not really make sense and every extension should be configured separately, therefore we should have just "BR: gcc", i.e. no C++ compiler available during build. However, I am not really sure if this is going to break something or not. I have tried to build rubygem-eventmachine at it seems to build just fine, but what else might be broken? Anyway, for now, I'll probably stick with "BR: gcc" and we can change to "BR: gcc-c++" later, if we discover it causes real troubles. Vít [1] https://bugzilla.redhat.com/show_bug.cgi?id=1606143#c4 [2] https://bugs.ruby-lang.org/issues/14590

2 7

Koschei build failures
by Vít Ondruch 27 Jul '18

27 Jul '18

Hi all, Unfortunately, it seems that almost every rubygem Koschi builds fail after yesterday rebuild of Ruby. I'm investigating what is going on. It seems that only x86_64 is not affected ... V.

1 2

Re: Updating rubygem-coderay to the latest version
by Jun Aruga 26 Jul '18

26 Jul '18

Hi Jan, > I have granted ruby sig group a commit rights to this repository. However, as I have no longer any time to maintain ruby packages (7), i think it would be best if ruby sig could take them. Is there anybody from ruby sig who wants to take them? Thanks for the quick response. I appreciate it. Okay. I want to take them. Assign me. Thanks. Jun On Wed, Jul 25, 2018 at 7:43 PM, Jan Klepek <jan.klepek(a)gmail.com> wrote: > Hi, > > I have granted ruby sig group a commit rights to this repository. However, > as I have no longer any time to maintain ruby packages (7), i think it would > be best if ruby sig could take them. Is there anybody from ruby sig who > wants to take them? > > Thanks, > Regards, > Jan Klepek > > > > On Wed, Jul 25, 2018 at 6:49 PM Jun Aruga <jaruga(a)redhat.com> wrote: >> >> Hello Jan, >> >> My name is Jun Aruga. >> I am in Fedora Ruby SIG. >> >> I want to update rubygem-coderay to the latest version. >> https://src.fedoraproject.org/rpms/rubygem-coderay/pull-request/1 >> >> Can you check the pull-request or can you add ruby sig group as a >> committer to the repository? >> >> You can refer this repository to add the group. >> https://src.fedoraproject.org/rpms/rubygem-rspec-core >> >> Thank you. >> >> -- >> Jun Aruga jaruga(a)redhat.com -- Jun Aruga jaruga(a)redhat.com IRC: jaruga, Office: TPB(Technology Park Brno) Building C 1F, Brno, Czech Republic

1 0

Re: Starting CI for Rails
by Jun Aruga 25 Jul '18

25 Jul '18

Hi Miroslav, Thanks for the answer! I got it. Right now I still can not start the Rails CI work again. Sorry. Jun On Tue, Jul 24, 2018 at 5:45 PM, Miroslav Vadkerti <mvadkert(a)redhat.com> wrote: > Hi, > > sorry this email got lost in my inbox > > On Wed, Jun 27, 2018 at 11:56 AM Jun Aruga <jaruga(a)redhat.com> wrote: >> >> >> - 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? > > > The testing runs for each brew build that has tests in it's dist-git. > > >> >> 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 > > > That can be done, but yhou need add tests into each dist-git of all those > targets. > This can reference the same shared test if you want. > >> >> 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. > > > Np, feel free to reach out if we can help more. > > Thanks, > /M > > >> >> >> 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 > > > > -- > Miroslav Vadkerti :: Principal QE :: BaseOS QE Security > IRC mvadkert #osci #baseosci #qe :: GPG 0x7B5B2E95 > 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

Updating rubygem-coderay to the latest version
by Jun Aruga 25 Jul '18

25 Jul '18

Hello Jan, My name is Jun Aruga. I am in Fedora Ruby SIG. I want to update rubygem-coderay to the latest version. https://src.fedoraproject.org/rpms/rubygem-coderay/pull-request/1 Can you check the pull-request or can you add ruby sig group as a committer to the repository? You can refer this repository to add the group. https://src.fedoraproject.org/rpms/rubygem-rspec-core Thank you. -- Jun Aruga jaruga(a)redhat.com

1 0

rubygems related packages needs attention after F-29 rebuild
by Mamoru TASAKA 25 Jul '18

25 Jul '18

Hello, ruby-sig folks: So currently lots of rubygems related packages failed to rebuild for F-29 mass rebuild: https://kojipkgs.fedoraproject.org/mass-rebuild/f29-need-rebuild.html I've not checked details, however it seems many of these are due to lack of proper compiler. Please check and help fixing these packages. Regards, Mamoru

2 1

Fedora: rubygem-mysql2
by Pavel Valena 19 Jul '18

19 Jul '18

Hello Alex, would you mind adding me (pvalena) as an admin to `rubygem-mysql2` Fedora package, so I we (Ruby-SIG) can do rebases? Alternatively you could grant commit access to @ruby-packagers-sig. It can be easily done in Pagure[0] now. It would help us a lot! [0] https://src.fedoraproject.org/rpms/rubygem-rails/adduser [0] https://src.fedoraproject.org/rpms/rubygem-rails/addgroup FYI on your web page, the Fedora url[1] no longer works. Current is [2]. [1] https://admin.fedoraproject.org/pkgdb/users/packages/achernya [2] https://src.fedoraproject.org/user/achernya Regards, Pavel Valena Software Engineer, Red Hat Brno, Czech Republic

2 1

bundler changes in Fedora 28
by Aleksandar Kostadinov 17 Jul '18

17 Jul '18

Hi, anybody know what changed so that bundler now tries to install either via `sudo` or in `vendor/bundle`? Any ideas how to restore old behavior where gems were installed user-wide in `~/.gem`? P.S. I presently do this hack > export BUNDLE_PATH=$(ls -t -U | ruby -e 'puts Gem.user_dir') > export PATH="$PATH:$BUNDLE_PATH/bin"

2 2

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

ruby-sig July 2018