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
1 week, 2 days
asciidoctor-diagram missing from Fedora
by Christopher Brown
Hello,
I've upgrade to F33 and discovered that we are missing asciidoctor-diagram
as a requirement for some internal tooling.
https://rubygems.org/gems/asciidoctor-diagram/
https://github.com/asciidoctor/asciidoctor-diagram
I am putting together a spec file for this now however tests are failing
with missing executables in the path. I am able to work around some by
installing the package but the majority we don't appear to ship packages
for - see example below.
Again, I'm sure this is something obvious (hopefully) and would appreciate
a steer in the right direction. I've attempted to pass various options to
rspec but to no avail.
Thanks for any advice in advance.
425) Asciidoctor::Diagram::WavedromBlockProcessor should support scaling
diagrams
Failure/Error: raise "Could not find the #{cmd_names.map { |c|
"'#{c}'" }.join(', ')} executable in PATH; add it to the PATH or specify
its location using the '#{attr_names[0]}' document attribute"
RuntimeError:
asciidoctor: FAILED: <stdin>: Failed to load AsciiDoc document -
Could not find the 'WaveDromEditor' executable in PATH; add it to the PATH
or specify its location using the 'WaveDromEditor' document attribute
Shared Example Group: "block" called from ./spec/wavedrom_spec.rb:16
# ./lib/asciidoctor-diagram/diagram_source.rb:130:in `find_command'
# ./lib/asciidoctor-diagram/wavedrom/converter.rb:39:in `convert'
# ./lib/asciidoctor-diagram/diagram_processor.rb:170:in
`create_image_block'
# ./lib/asciidoctor-diagram/diagram_processor.rb:86:in `process'
#
/usr/share/gems/gems/asciidoctor-2.0.10/lib/asciidoctor/parser.rb:1040:in
`[]'
#
/usr/share/gems/gems/asciidoctor-2.0.10/lib/asciidoctor/parser.rb:1040:in
`build_block'
#
/usr/share/gems/gems/asciidoctor-2.0.10/lib/asciidoctor/parser.rb:886:in
`next_block'
#
/usr/share/gems/gems/asciidoctor-2.0.10/lib/asciidoctor/parser.rb:379:in
`next_section'
#
/usr/share/gems/gems/asciidoctor-2.0.10/lib/asciidoctor/parser.rb:364:in
`next_section'
#
/usr/share/gems/gems/asciidoctor-2.0.10/lib/asciidoctor/parser.rb:97:in
`parse'
#
/usr/share/gems/gems/asciidoctor-2.0.10/lib/asciidoctor/document.rb:549:in
`parse'
#
/usr/share/gems/gems/asciidoctor-2.0.10/lib/asciidoctor/load.rb:83:in `load'
# ./spec/test_helper.rb:70:in `load_asciidoc'
# ./spec/shared_examples.rb:592:in `block (2 levels) in <top
(required)>'
# ./spec/test_helper.rb:112:in `block (3 levels) in <top (required)>'
# ./spec/test_helper.rb:111:in `chdir'
# ./spec/test_helper.rb:111:in `block (2 levels) in <top (required)>'
# ------------------
# --- Caused by: ---
# RuntimeError:
# Could not find the 'WaveDromEditor' executable in PATH; add it
to the PATH or specify its location using the 'WaveDromEditor' document
attribute
# ./lib/asciidoctor-diagram/diagram_source.rb:130:in `find_command'
--
Christopher Brown
2 years, 10 months
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 years, 10 months
Orphaned rubygem-json_pure
by Vít Ondruch
Hello,
I have removed dependencies on rubygem-json_pure from rubygem-morph-cli
and rubygem-multi_json, therefore nothing else depended on
rubygem-json_pure. There is no real need for rubzgem-json_pure in
Fedora, since jruby is long gone and ruby can use the binary
rubygem-json, which is more performant, therefore I orphaned
rubygem-json_pure.
Vít
2 years, 10 months
Fwd: Fedora 34 Change proposal: Remove make from BuildRoot
(System-Wide Change)
by Vít Ondruch
Reading this proposal, I wonder, if rubygems should grow some (weak)
dependency on Make? Historically, that was not good idea, because the
only option was hard dependency, which would be overkill. But since we
have weak dependencies already for some time, maybe we could consider this.
This question could be probably extended to gcc, cmake, ruby-devel so
maybe this is just opening Pandora box.
What are your thoughts?
Vít
-------- Přeposlaná zpráva --------
Předmět: Fedora 34 Change proposal: Remove make from BuildRoot
(System-Wide Change)
Datum: Wed, 4 Nov 2020 13:12:54 -0500
Od: Ben Cotton <bcotton(a)redhat.com>
Adresa pro odpověď: Development discussions related to Fedora
<devel(a)lists.fedoraproject.org>
Komu: devel-announce(a)lists.fedoraproject.org
Kopie: Development discussions related to Fedora
<devel(a)lists.fedoraproject.org>
https://fedoraproject.org/wiki/Changes/Remove_make_from_BuildRoot
== Summary ==
This change will remove make from the default buildroot in Koji and mock.
== Owner ==
* Name: [[User:tstellar| Tom Stellard]]
* Email: <tstellar(a)redhat.com>
== Detailed Description ==
===== Phase 1: Analysis =====
For this change, we will start by creating a list of all packages that
have a build-time dependency on make. This will be done by analyzing
spec files and also by rebuilding all packages in Fedora with make
removed from the buildroot to see which packages fail to build. Once
we have this list, we will remove packages that already have
BuildRequires:make in their spec file, and this final list[1] will be
all the packages that need to be updated in Phase 2.
[1]
https://github.com/tstellar/fedora-change-make-buildroot/blob/main/needs_...
===== Phase 2: Package Updates =====
Once we have the list of packages that need to be updated, we will
proceed with adding BuildRequires: make to all spec files that require
it. This new BuildRequires will be added to the line after the last
BuildRequires in the spec file. The release number for packages will
'''*not*''' be incremented for this change.
The spec file updates will be automated and changes will be pushed
directly to dist-git once they are ready.
===== Phase 3: Update Buildroot =====
Once package spec files have been updated, then we can proceed with
removing make from the BuildRoot. This will be done by removing make
from the build group in Koji and by removing make from the
buildsys-build group in comps (fedora-comps). In order to avoid
issues with Koschei, this change will need to be made as close as
possible to the start of the mass rebuild. If possible, we will try
to first remove make from the mass rebuild side-tag and then remove it
from rawhide after the rebuild completes.
===== Phase 4: Monitor Failures =====
Once all the changes are in place, we will continue to monitor koji
builds to see if there are any failures related to this change. We
expect that the analysis done in Phase 1 would give us the complete
list of packages that need to be updated, but it is always possible
that something will be missed.
== Feedback ==
* Removing make from the Buildroot without rebuilding the packages
first has the potential to cause mass failures in Koschei. This is
because Koschei builds from the latest SRPM and not from dist-git. We
can minimize this problem by removing make from the buildroot as close
as possible to the mass rebuild. The proposal has been updated now to
account for this issue.
== Benefit to Fedora ==
Based on my research[1], Fedora Rawhide has 22,309 packages, and there
are approximately 10,378 packages that either use make explicitly or
fail to build when make is removed form the buildroot. This means
that there are around 11,931 packages that don't need make. Removing
make from the BuildRoot will reduce the network traffic, download
times, and disk usage for these builds in Koji and also for users
doing builds with mock.
Removing make (and its dependencies) will:
* Reduce the BuildRoot download size by: 7.3 MB [2]:
** make: 539k
** gc: 104k
** guile22: 6.6M
** libtool-ltdl: 36k
* Reduce the BuildRoot install size by; 46 MB [2]:
** make: 1.6M
** gc: 229k
** guile22: 44M
** libtool-ltdl: 71k
[1] https://github.com/tstellar/fedora-change-make-buildroot
[2] Package sizes are from the x86_64 packages.
== Scope ==
* '''Proposal owners:''' Tom Stellard
* '''Package Maintainers:''' Fedora package maintainers should report
bugs if they think there is a problem caused by this change, but
otherwise there will be no action required by them.
* '''Proven Packager:''' The proposal owner will need to either apply
for provenpackager status or get the help of someone with
provenpackager status in order to make the spec file changes that are
required.
* '''Release engineering:''' [https://pagure.io/releng/issue/9829
#9829] (a check of an impact with Release Engineering is needed)
* '''Policies and guidelines:''' The packager guidelines will need to
be updated to mention that BuildRequires: make is now required for all
packages that need make.
* '''Trademark approval:''' N/A (not needed for this Change)
* '''Alignment with Objectives:''' This aligns with the Fedora
Minimization [https://pagure.io/minimization/issue/12 objective].
== Upgrade/compatibility impact ==
This should not impact upgrades.
== How To Test ==
This change can be tested by rebuilding affected packages. The goal
is to complete this before the mass rebuild to ensure maximum testing
coverage.
== User Experience ==
Fedora users will not notice any difference with this change. This
will only impact Fedora package maintainers.
== Dependencies ==
gcc < 11 will fail if the -flto=auto option is used when make is not
installed. Phase 3 cannot be completed until gcc 11 lands in rawhide,
but Phase 1 and Phase 2 are not blocked by this.
== Contingency Plan ==
* '''Contingency mechanism:''' If we discover critical issues during
phase 4, then Fedora Release Engineering will need to re-add make into
the buildroot.
* '''Contingency deadline:''' 2021-02-23 (F34 Beta Freeze)
* '''Blocks release?''' No
* '''Blocks product?''' No
== Documentation ==
The packager guidelines will need to be updated to mention that
BuildRequires: make is now required for all packages that need make.
--
Ben Cotton
He / Him / His
Senior Program Manager, Fedora & CentOS Stream
Red Hat
TZ=America/Indiana/Indianapolis
_______________________________________________
devel mailing list -- devel(a)lists.fedoraproject.org
To unsubscribe send an email to devel-leave(a)lists.fedoraproject.org
Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
2 years, 11 months
