Two stage Ruby compilation / Bootstrapping
by Vít Ondruch
Hi all,
Ruby upstream is implementing more and more stuff directly in Ruby. We
already had issues, that build of Ruby required Ruby when we did some
modifications [1]. In subsequent ticket, one of Ruby committers said [2]:
> ... snip ...
> BASERUBY is already a build requirement
> ... snip ...
> I would like to implement more of Ruby using Ruby, so miniruby may
depend on prelude one day.
With recent changes, such as [3], I am afraid that the day has come.
Previously, if you wanted to patch lets say "gem_prelude.rb", it was
enough to patch it. But now you *need* Ruby to process it into
miniprelude.c. There are possibly 4 ways out of this.
1) Build Ruby in two stages. a) build (mini)ruby, apply patches b) build
Ruby using the previously built (mini)ruby.
2) Use previous version of Ruby available in Fedora to bootstrap Ruby.
But this does not work ATM, at least when RubyGems are installed. And
upstream is doing what they can to make RubyGems inseparable [4].
3) Prepare patches locally and apply the required changes also to the
pregenerated files. But the problem here is, that the patches might
unpredictably fail between updates. I don't think that they keep any
API/ABI promises for the tools used to generate those files.
4) Don't use the upstream tarball, but generate it from sources with
patches integrated.
I think we should probably start to take look at 1), specifically into
the *miniruby* variant if that is enough. If that is done, the 2) could
optionally blend in. And in the mean time use 3) because otherwise I
really don't know how to integrate the ABRT hook support. I don't like
4) at all, unless we have some Fedora standardized way of doing so.
On the positive side, 1(2) would allow us to stay better in line with
"Pregenerated code" guidelines [5], because there is already quite a lot
of pre-generated code shipped in Ruby release tarball.
Thoughts?
Vít
[1]
https://src.fedoraproject.org/rpms/ruby/c/c0513dfb8c81a228619c6142195c511...
[2] https://bugs.ruby-lang.org/issues/15306#note-1
[3] https://github.com/ruby/ruby/pull/2655
[4] https://bugs.ruby-lang.org/issues/16431
[5]
https://docs.fedoraproject.org/en-US/packaging-guidelines/what-can-be-pac...
2 months
FTBFS's: cannot load such file - racc/*
by Pavel Valena
Hello,
as you probably know with Ruby 2.7, there came some incompatible changes. One of them is that `racc` was gemified and is not installed by default into a buildroot.
From my brief investigations of build failures (the list may not be complete or a bit outdated), I've encountered these:
rubygem-shoulda.log: LoadError: cannot load such file -- racc/parser.rb
^ require from actionpack
rubygem-shoulda-matchers.log: cannot load such file -- racc/parser.rb
^ require from activesupport
rubygem-i18n.log:/usr/share/rubygems/rubygems/core_ext/kernel_require.rb:92:in `require': cannot load such file -- racc/parser (LoadError)
^ require from i18n/lib
rubygem-nokogiri.log:/usr/share/rubygems/rubygems/core_ext/kernel_require.rb:92:in `require': cannot load such file -- racc/parser.rb (LoadError)
rubygem-sass-rails.log:/usr/share/gems/gems/nokogiri-1.10.7/lib/nokogiri/css/parser.rb:7:in `require': cannot load such file -- racc/parser.rb (LoadError)
rubygem-shoulda-context.log:<["/usr/share/gems/gems/nokogiri-1.10.7/lib/nokogiri/css/parser.rb:7:in `require': cannot load such file -- racc/parser.rb (LoadError)"]>
^ nokogiri
What would be the best solution? Add the require to Ruby, or add it to respective gems+spec files (nokogiri issue: [0])?
Regards,
Pavel
[0] https://github.com/sparklemotion/nokogiri/issues/1988
9 months, 4 weeks
Unexpected files included in rubygem doc packages
by Breno Brand Fernandes
Hi all,
I had an issue today with a package I submitted to code review [1].
The reviewer pointed out that I was shipping font files instead of
requiring them.
And, I was also not shipping their license.
After that, Trevor and I started to investigate and we realized that some
other packages had the same issue. We wrote a few scripts and came to the
conclusion that almost every rubygem doc package pushed to Fedora Rawhide
right now has those files.
We also investigated the gems, and it seems that by default they do not
include those files [2].
A list of the mentioned files is attached to this email.
There are fonts, CSS, Javascripts, and others.
In one of the rubygem packages (rubygem-nifti) we found that those files
could be excluded [3].
Is this expected? Should we just use the exclude [3] even though the files
were downloaded?
I mean, removing the files at a build stage is enough if they have
licensing issues?
What is the right direction the reviewer or the maintainer should be
pointed to?
Thanks.
- B
1 - https://bugzilla.redhat.com/show_bug.cgi?id=1803276
2 - e.g. https://rubygems.org/gems/cane-3.0.0.gem
3 - %files doc section, they have "%exclude %{gem_docdir}/rdoc"
11 months
ruby-sig Introduction email
by David Kirwan
Hi all,
My name is David Kirwan, I'm a software engineer in Red Hat based out of
Waterford in the South East of Ireland. So far in Red Hat I've worked in
releng/ops/devops and more recently now engineering teams.
Ruby is my go to language for fun/personal projects, I think it might be
fun to get involved in improving the experience for Ruby developers on
Fedora! I don't know exactly how I could be useful until I learn more about
what kind of work is actually performed in this group, but I'd like to join
and learn!
cheers,
David
--
David Kirwan
SOFTWARE ENGINEER
Red Hat Cloud Services
Communications House
Cork Road, Waterford
dkirwan(a)redhat.com T: +(353) 86-8624108 IM: @dkirwan
11 months, 1 week
Empty %files debugsourcefiles.list rpmbuild rubygem packages
by Breno Brand Fernandes
Hi all,
I had issues building some rubygem packages with rpmbuild.
E.g. rubygem-redcarpet[1].
During my tests, I am using the spec file from the master branch.
Using mock instead (of rpmbuild), the issue doesn't happen.
Do you know why it happens? Am I missing something obvious?
Thank you,
1 -
RPM build errors:
Downloading https://rubygems.org/gems/redcarpet-3.3.2.gem to
/home/mockbuild/rpmbuild/SOURCES/redcarpet-3.3.2.gem
Empty %files file
/home/mockbuild/rpmbuild/BUILD/rubygem-redcarpet-3.3.2/debugsourcefiles.list
- Breno
11 months, 2 weeks
Question about rubyforge related packages
by Troy Dawson
Hi,
rubygem-rubyforge was dropped back in November with "rubyforge is dead
long ago, retiring (mtasaka, 20191105)"
I'm ok with that.
I have a package that was part of rubyforge, rubygem-ci_reporter.
Looking at it's codebase, it hasn't been touched for 5 years. I was
debating on just dropping/retiring it, or orphaning it.
I don't use it anymore, so I'm at least orphaning it. But do people
think I should just completely drop it, like rubyforge, since we don't
really want it in fedora anymore?
Troy
11 months, 2 weeks