ruby-sig FAS group and rubygems build in Copr
by Vít Ondruch
Hi everybody,
You probably noticed, that there is ongoing build of all Python packages
in Copr [1] and today, I was approached by Miroslav Suchý, that he'd
like to do the same for rubygems. And this in turn triggered these
questions:
1) Would you be interested to create ruby-sig group in FAS? We could
make the group owner of some packages and in turn, the members of the
group could maintain the packages, without explicitly asking for some ACLs.
2) For the Copr rebuild of rubygems, there needs to be some FAS group
again. Python guys are asking for "pypi-builds-sig" group [2], hence
following their lead, I'd like to ask for "rubygems-builds-sig" group
(note that although I don't like the '-sig' suffix in this case, it is
mandated by the infrastructure ticket template).
So what are your thoughts?
Vít
[1]
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.o...
[2] https://fedorahosted.org/fedora-infrastructure/ticket/5311
3 years, 10 months
Ruby 2.4
by Vít Ondruch
Hi everybody,
Time is running past and it is almost 6 months of development of Ruby
2.4. So I started to prepare some test build again. I am pushing all the
changes into private-ruby-2.4 branch of dist-git if you are interested
and here is the build of r55184:
http://koji.fedoraproject.org/koji/taskinfo?taskID=14278233
One notable change is that XMLRPC library was extracted into separate
gem, so rubygem-xmlrpc is now available as Ruby subpackage.
Please give it a try and let me know if anything goes wrong.
Vít
4 years, 2 months
Packaging pre-release version
by Vít Ondruch
Hi all,
I am working on rubygem-asciidoctor-mallard review [1] and since there
was not released stable version yet, the pre-release version (actually
git snapshot) needs to be packaged. And now I realized it is more PITA
then it should be.
The main issue is with the way, how pre-release packages are versioned.
E.g. in rubygem-asciidoctor-mallard case, the upstream version is
"0.1.0.dev" which transforms in Fedora into "0.1.0-0.1.dev" and
subsequently, no standard macro works.
But the remedy could be quite simple. With this change:
```
$ git diff
diff --git a/macros.rubygems b/macros.rubygems
index 45c59c4..0652ec6 100644
--- a/macros.rubygems
+++ b/macros.rubygems
@@ -3,12 +3,12 @@
%gem_archdir %{_libdir}/gems
# Common gem locations and files.
-%gem_instdir %{gem_dir}/gems/%{gem_name}-%{version}
-%gem_extdir_mri %{gem_archdir}/%{name}/%{gem_name}-%{version}
+%gem_instdir %{gem_dir}/gems/%{gem_name}-%{version}%{?prerelease}
+%gem_extdir_mri %{gem_archdir}/%{name}/%{gem_name}-%{version}%{?prerelease}
%gem_libdir %{gem_instdir}/lib
-%gem_cache %{gem_dir}/cache/%{gem_name}-%{version}.gem
-%gem_spec %{gem_dir}/specifications/%{gem_name}-%{version}.gemspec
-%gem_docdir %{gem_dir}/doc/%{gem_name}-%{version}
+%gem_cache %{gem_dir}/cache/%{gem_name}-%{version}%{?prerelease}.gem
+%gem_spec
%{gem_dir}/specifications/%{gem_name}-%{version}%{?prerelease}.gemspec
+%gem_docdir %{gem_dir}/doc/%{gem_name}-%{version}%{?prerelease}
# %gem_install - Install gem into appropriate directory.
@@ -28,7 +28,7 @@ gem install \\\
--build-root %{-d*}%{!?-d:.} \\\
--force \\\
--document=ri,rdoc \\\
- %{-n*}%{!?-n:%{gem_name}-%{version}.gem} \
+ %{-n*}%{!?-n:%{gem_name}-%{version}%{?prerelease}.gem} \
%{nil}
```
It would be enough to specify:
```
%global prerelease .dev
```
in your .spec file and half of the lines I needed to add into the
pre-release package could be removed.
Please note that this is inspired by macros Mamoru is using for ages in
some of his packages (Nokogiri for example [2]).
(Actually, now I realized that the proposal in the review is more
complex then it should be, but that is a different story ...)
Any thoughts?
Vít
[1] https://bugzilla.redhat.com/show_bug.cgi?id=1343977#add_comment
[2]
http://pkgs.fedoraproject.org/cgit/rpms/rubygem-nokogiri.git/tree/rubygem...
4 years, 3 months
Ruby 2.3.2
by Vít Ondruch
Hi,
I am slowly pushing Ruby 2.3.2 into Fedora.
Unfortunately, part of Ruby 2.3.2 is update of RubyGems and this update
has one annoying consequence. RubyGems developers decided, that it is
good idea to freeze all strings in generated .gemspec file. But because
of this, there might be several rubygem- packages FTBFS. For example,
rubygem-execjs fails to build with following errror:
```
+ gem build execjs.gemspec
WARNING: See http://guides.rubygems.org/specification-reference/ for help
ERROR: While executing gem ... (Gem::InvalidSpecificationException)
["lib/execjs/support/jscript_runner.js",
"lib/execjs/support/json2.js"] are not files
```
This is because there are some files removed from the package and the
previous sed:
```
+ sed -i -e '/files/ s|"lib/execjs/support/jscript_runner.js", ||' -e
'/files/ s|"lib/execjs/support/json2.js", ||' execjs.gemspec
```
Does not match/substitute anything, due to .freeze call :/ This is the
fix for rubygem-execjs:
```
$ git diff
diff --git a/rubygem-execjs.spec b/rubygem-execjs.spec
index b2df67c..fddb541 100644
--- a/rubygem-execjs.spec
+++ b/rubygem-execjs.spec
@@ -41,8 +41,8 @@ gem unpack %{SOURCE0}
gem spec %{SOURCE0} -l --ruby > %{gem_name}.gemspec
%patch0 -p1
-sed -i -e '/files/ s|"lib/execjs/support/jscript_runner.js", ||' \
- -e '/files/ s|"lib/execjs/support/json2.js", ||' %{gem_name}.gemspec
+sed -i -e '/files/ s|"lib/execjs/support/jscript_runner.js".freeze, ||' \
+ -e '/files/ s|"lib/execjs/support/json2.js".freeze, ||'
%{gem_name}.gemspec
%build
# Create the gem as gem install only works on a gem file
```
I'm sorry for any inconvenience, but suggest to complain to
Ruby/RubyGems upstream, since minor/teeny version changes should not
break anything ...
Vít
4 years, 3 months