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, 5 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
Ruby SIG introduction
by Christopher Brown
Hi folks,
I joined this mailing list a while back and maintain the asciidoctor-pdf
package along with a number of rubygem dependencies.
Thanks Vit for sponsoring me. I'd specifically like to call out Dan Allen
for his assistance in working to improve the testing for asciidoctor-pdf
earlier and others for answering my basic questions. :)
--
Christopher Brown
Senior Consultant
Red Hat UK Ltd
chris.brown(a)redhat.com
2 years, 11 months
prawn-svg test suite
by Christopher Brown
Hi folks,
I'm looking to try and enable some more tests on some of the packages I
maintain but am struggling with removal of bundler.
I have attempted to enable it in prawn-svg using the usual:
%check
pushd .%{gem_instdir}
sed -i "/require 'bundler'/ s/^/#/" spec/spec_helper.rb
sed -i "/Bundler/ s/^/#/" spec/spec_helper.rb
rspec spec
popd
however I'm getting:
NameError:
uninitialized constant Prawn
on any mock builds I run. I'm sure this is an incredibly newbie question
but would appreciate it if someone can point me in the right direction.
I'll look to enhance
https://fedoraproject.org/wiki/Packaging:Ruby#Running_test_suites with my
subsequent knowledge, if it helps.
Thanks
--
Christopher Brown
2 years, 11 months
Self-introduction
by Michael Kohl
Hi everyone,
I'm Michael Kohl and generally go by citizen428 online (https://citizen428.net/).
I've been a Ruby developer since ~2004 and was part of Gentoo's Ruby team (amongst others) from around that time until mid 2006 or so. I have contributed some bugfixes to JRuby (https://github.com/jruby/jruby/commits?author=citizen428) and quite recently my first one to MRI (https://github.com/ruby/ruby/commits?author=citizen428). I'm quite involved in the Ruby community and co-organize Bangkok.rb and RubyConf Thailand. I also like speaking at events myself.
I currently work for DEV (https://dev.to/) and our systems stack leverages FCOS. So I'm interested in helping with getting new Ruby releases packaged fast.
If you have any further questions, please feel free to ask.
Have a nice day,
Michael
2 years, 11 months
orphaning rubygem-kramdown on EPEL
by Mamoru TASAKA
Hello, ruby-sig folks:
rubygem-kramdown before 2.3.0 has security issue assigned as CVE-2020-14001 :
https://bugzilla.redhat.com/show_bug.cgi?id=1858395 ,
so I've pushed updates rubygem-kramdown-2.2.1-4.fc32 for Fedora 32, and
rubygem-kramdown-1.17.0-6.fc31 for Fedora 31.
For EPEL(7), as I've repeatedly said I didn't maintain any packages on EPEL,
however as somehow EPEL updates request was assigned to me :
https://bugzilla.redhat.com/show_bug.cgi?id=1858415
I've created rubygem-kramdown-1.9.0-2.el7 updates which was pushed to stable
yesterday - however it seems there was some mistakes on the patch I've applied:
https://bugzilla.redhat.com/show_bug.cgi?id=1889144
So as I've thought before I am afraid that I should not maintain packages on EPEL,
so once I've orphaned rubygem-kramdown on EPEL. I hope that someone who really uses
EPEL can take care of this. Note that I'll keep maintaining rubygem-kramdown on
Fedora branches.
Regards,
Mamoru
2 years, 11 months
ruby-rails group in Koschei & RoR 6.0.3.3
by Pavel Valena
Hello,
following on my previous email (bellow), I'm working on regenerating the list of packages `ruby-rails` group in Koschei.
I've done some fixes to package resolving in my script (I'm left with 3 unresolved /ambiguous/ packages as well), and got current list:
https://gist.github.com/pvalena/ccdd482ace158bc55c891528e2be22ce
I'm also thinking of a way to get list of packages that are requiring the dependency (let me know if you want to see that).
Proposed (generated) changes:
https://gist.github.com/pvalena/dd00dafa1bf37b8f74312b57e650d8b0
+ means addition
- means removal
There are some suspicious entries, like `+rubygem-rspec2`, which will need further investigation. I'll welcome any additional feedback on packages that are missing, or should not be in this group.
Currently failing (dependent) packages:
https://gist.github.com/pvalena/f9b40fdebed1b9864ea1e1c7fedcb14a
_ _ _ _
Additionaly, Ruby on Rails was updated to 6.0.3.3 in Rawhide and F33 has update pending:
https://bodhi.fedoraproject.org/updates/FEDORA-2020-83a4999b7c
https://bodhi.fedoraproject.org/updates/FEDORA-2020-4dd34860a3
Please let me know if this breaks something for you. You can see my test passing here:
https://gist.github.com/pvalena/350309be47258e9bdb0e01f7e04fde12
Regards,
--
Pavel Valena
Software Engineer, Red Hat
Brno, Czech Republic
----- Forwarded Message -----
> From: "Pavel Valena" <pvalena(a)redhat.com>
> To: "Ruby SIG mailing list" <ruby-sig(a)lists.fedoraproject.org>
> Sent: Friday, August 21, 2020 4:59:58 PM
> Subject: Current build failures from RoR group
>
> Hello,
>
> I'm refreshing ruby-rails group[1] in koschei, and I've decided to use COPR
> for it. I'm rebuilding every 'rubygem-*' dependency that gets pulled in
> (recursively) for the build.
>
> Current failing packages can be found here:
> https://gist.github.com/pvalena/f9b40fdebed1b9864ea1e1c7fedcb14a
> (Some of them may have already PRs pending.)
>
> The builds can be found here:
> https://copr.fedorainfracloud.org/coprs/pvalena/ruby-on-rails/packages/
>
> All pulled-in packages (resulting list):
> https://gist.github.com/pvalena/ccdd482ace158bc55c891528e2be22ce
>
>
> [1] https://koschei.fedoraproject.org/groups/ruby-rails
>
> Regards,
> --
> Pavel Valena
> Software Engineer, Red Hat
> Brno, Czech Republic
>
3 years
