Ruby 2.2
by Vít Ondruch
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...
[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
2 months, 2 weeks
BR: gcc vs gcc-c++
by Vít Ondruch
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
5 years, 3 months
Koschei build failures
by Vít Ondruch
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.
5 years, 4 months
Re: Updating rubygem-coderay to the latest version
by Jun Aruga
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
5 years, 4 months
Re: Starting CI for Rails
by Jun Aruga
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-r...
>>
>> 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-ap...
>> >> >
>> >> >
>> >> > 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
5 years, 4 months
bundler changes in Fedora 28
by Aleksandar Kostadinov
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"
5 years, 4 months
