Hi all,
Ruby 2.4 was released during Christmas and the upcoming Ruby 2.5 development is advancing, so I continue in the tradition and I got r58319 packaged for testing. The updated .spec file is available in dist-git private-ruby-2.5 branch and here is the scratch build:
https://koji.fedoraproject.org/koji/taskinfo?taskID=18952639
One thing I'd like to point out that upstream is working on gemification of StdLib. The question ATM is what the result will be. Hence, there is one big TODO in the .spec file [1]. The question if each of the gems should be unbundled or not. The future will tell hopefully.
Vít
[1] http://pkgs.fedoraproject.org/cgit/rpms/ruby.git/tree/ruby.spec?h=private-ru...
Hi everybody,
After some while, here is another snapshot of Ruby 2.5, this time r59424. You can find the changes in private-ruby-2.5 dist-git branch and here is scratch build:
https://koji.fedoraproject.org/koji/taskinfo?taskID=20758987
As you can see, there are various build failures on various platforms. I've reported them upstream, but so far without response. It seems I'll need some support from secondary arches team ...
Anyway, if you have any feedback, please let me know.
Vít
Hi everybody,
After some bisecting, I was able to find the offending commit and build latest snapshot (r59657) of Ruby on all architectures. Here is the scratch build:
https://koji.fedoraproject.org/koji/taskinfo?taskID=21464336
Please give it some test and let me know in case you'll have issues with it.
Vít
Hi everybody,
Yet another update of Ruby 2.5 is here, this time r60107. You can grab the sources from private-ruby-2.5 branch from dist git and try the scratch build here:
https://koji.fedoraproject.org/koji/taskinfo?taskID=22236512
The main difference of this release is Bundler merged into the official Ruby repository. However, I decided to drop the Bundler from the Ruby ATM, mainly due to extensive bundling and other awful stuff. I made a call to remove the Bundler again [1], since there is no design behind it IMO. However, I am not 100% sure it won't break something, so please let me know ...
Vít
Hi everybody,
Here is another test build of Ruby 2.5, this time it is r61214.
https://koji.fedoraproject.org/koji/taskinfo?taskID=23681673
As always, you can find the .spec file in private-ruby-2.5 branch of ruby dist-gits.
Vít
Dne 13.4.2017 v 10:54 Vít Ondruch napsal(a):
Hi all,
Ruby 2.4 was released during Christmas and the upcoming Ruby 2.5 development is advancing, so I continue in the tradition and I got r58319 packaged for testing. The updated .spec file is available in dist-git private-ruby-2.5 branch and here is the scratch build:
https://koji.fedoraproject.org/koji/taskinfo?taskID=18952639
One thing I'd like to point out that upstream is working on gemification of StdLib. The question ATM is what the result will be. Hence, there is one big TODO in the .spec file [1]. The question if each of the gems should be unbundled or not. The future will tell hopefully.
Vít
[1] http://pkgs.fedoraproject.org/cgit/rpms/ruby.git/tree/ruby.spec?h=private-ru...
ruby-sig mailing list -- ruby-sig@lists.fedoraproject.org To unsubscribe send an email to ruby-sig-leave@lists.fedoraproject.org
Thanks for that.
I want you to add below kind of comment somethere in "private-ruby-2.5" branch or master ruby.spec file a way to create Source0 file.
# git clone https://github.com/ruby/ruby.git && cd ruby # git archive --prefix=ruby-2.5.0-r61214/ 06d36a1 | xz > ruby-2.5.0-r61214.tar.xz
Possible?
Jun
On Thu, Dec 14, 2017 at 2:42 PM, Vít Ondruch vondruch@redhat.com wrote:
Hi everybody,
Here is another test build of Ruby 2.5, this time it is r61214.
https://koji.fedoraproject.org/koji/taskinfo?taskID=23681673
As always, you can find the .spec file in private-ruby-2.5 branch of ruby dist-gits.
Vít
Dne 13.4.2017 v 10:54 Vít Ondruch napsal(a):
Hi all,
Ruby 2.4 was released during Christmas and the upcoming Ruby 2.5 development is advancing, so I continue in the tradition and I got r58319 packaged for testing. The updated .spec file is available in dist-git private-ruby-2.5 branch and here is the scratch build:
https://koji.fedoraproject.org/koji/taskinfo?taskID=18952639
One thing I'd like to point out that upstream is working on gemification of StdLib. The question ATM is what the result will be. Hence, there is one big TODO in the .spec file [1]. The question if each of the gems should be unbundled or not. The future will tell hopefully.
Vít
[1] http://pkgs.fedoraproject.org/cgit/rpms/ruby.git/tree/ruby.spec?h=private-ru...
ruby-sig mailing list -- ruby-sig@lists.fedoraproject.org To unsubscribe send an email to ruby-sig-leave@lists.fedoraproject.org
ruby-sig mailing list -- ruby-sig@lists.fedoraproject.org To unsubscribe send an email to ruby-sig-leave@lists.fedoraproject.org
Well, this is not the way you can get the right archive. You have to use something like:
~~~
tool/make-snapshot -packages=xz tmp
~~~
I previously published script which can generate the tarball using mock and update the spec file:
https://lists.fedoraproject.org/archives/list/ruby-sig@lists.fedoraproject.o...
V.
Dne 14.12.2017 v 15:16 Jun Aruga napsal(a):
Thanks for that.
I want you to add below kind of comment somethere in "private-ruby-2.5" branch or master ruby.spec file a way to create Source0 file.
# git clone https://github.com/ruby/ruby.git && cd ruby # git archive --prefix=ruby-2.5.0-r61214/ 06d36a1 | xz > ruby-2.5.0-r61214.tar.xz
Possible?
Jun
On Thu, Dec 14, 2017 at 2:42 PM, Vít Ondruch vondruch@redhat.com wrote:
Hi everybody,
Here is another test build of Ruby 2.5, this time it is r61214.
https://koji.fedoraproject.org/koji/taskinfo?taskID=23681673
As always, you can find the .spec file in private-ruby-2.5 branch of ruby dist-gits.
Vít
Dne 13.4.2017 v 10:54 Vít Ondruch napsal(a):
Hi all,
Ruby 2.4 was released during Christmas and the upcoming Ruby 2.5 development is advancing, so I continue in the tradition and I got r58319 packaged for testing. The updated .spec file is available in dist-git private-ruby-2.5 branch and here is the scratch build:
https://koji.fedoraproject.org/koji/taskinfo?taskID=18952639
One thing I'd like to point out that upstream is working on gemification of StdLib. The question ATM is what the result will be. Hence, there is one big TODO in the .spec file [1]. The question if each of the gems should be unbundled or not. The future will tell hopefully.
Vít
[1] http://pkgs.fedoraproject.org/cgit/rpms/ruby.git/tree/ruby.spec?h=private-ru...
ruby-sig mailing list -- ruby-sig@lists.fedoraproject.org To unsubscribe send an email to ruby-sig-leave@lists.fedoraproject.org
ruby-sig mailing list -- ruby-sig@lists.fedoraproject.org To unsubscribe send an email to ruby-sig-leave@lists.fedoraproject.org
OK thanks for the info.
Comparing the result of "gem list" command between upstream and our Fedora package, I found the difference. That can be confusing people.
Some of the gem are not shown in the result such as cmath for Fedora package ruby.
When running below command on mock, we can load cmath that is not in "gem list" on mock, maybe those are only shown as a result of "gem list".
``` irb(main):003:0> require 'cmath' => true ```
Is it possible to add those gems in the result as a compatibility for upstream Ruby? Hidden gems such as cmath are confusing users. We might also have to add additional gems as a recommendations like bigdecimal in ruby.spec as the result.
``` Recommends: rubygem(bigdecimal) >= %{bigdecimal_version} ```
No "default: " in the gem list for Fedora package is from past version. That's fine for me.
## Upstream
On current latest trunk.
$ dest/bin/gem list
*** LOCAL GEMS ***
bigdecimal (default: 1.3.3) bundler (default: 1.16.1.pre1) cmath (default: 1.0.0) csv (default: 1.0.0) date (default: 1.0.0) dbm (default: 1.0.0) digest (default: 0.1.0) etc (default: 1.0.0) fcntl (default: 1.0.0) fileutils (default: 1.0.1) gdbm (default: 2.0.0) io-console (default: 0.4.6) ipaddr (default: 1.2.0) json (default: 2.1.0) openssl (default: 2.1.0) psych (default: 3.0.0) rdoc (default: 6.0.0) scanf (default: 1.0.0) sdbm (default: 1.0.0) stringio (default: 0.0.1) strscan (default: 0.0.1) webrick (default: 1.4.0.beta1) zlib (default: 1.0.0)
## Building with your SRPM, and checked on mock environment
After installing all the binary RPMs from your SRPM
<mock-chroot> sh-4.4# gem list
*** LOCAL GEMS ***
bigdecimal (1.3.3) did_you_mean (1.1.2) io-console (0.4.6) json (2.1.0) minitest (5.10.3) net-telnet (0.1.1) openssl (2.1.0.beta2) power_assert (1.1.1) psych (3.0.0) rake (12.3.0) rdoc (6.0.0) test-unit (3.2.7) xmlrpc (0.3.0)
Jun
On Thu, Dec 14, 2017 at 5:06 PM, Vít Ondruch vondruch@redhat.com wrote:
Well, this is not the way you can get the right archive. You have to use something like:
tool/make-snapshot -packages=xz tmpI previously published script which can generate the tarball using mock and update the spec file:
https://lists.fedoraproject.org/archives/list/ruby-sig@lists.fedoraproject.o...
V.
Dne 14.12.2017 v 15:16 Jun Aruga napsal(a):
Thanks for that.
I want you to add below kind of comment somethere in "private-ruby-2.5" branch or master ruby.spec file a way to create Source0 file.
# git clone https://github.com/ruby/ruby.git && cd ruby # git archive --prefix=ruby-2.5.0-r61214/ 06d36a1 | xz > ruby-2.5.0-r61214.tar.xz
Possible?
Jun
On Thu, Dec 14, 2017 at 2:42 PM, Vít Ondruch vondruch@redhat.com wrote:
Hi everybody,
Here is another test build of Ruby 2.5, this time it is r61214.
https://koji.fedoraproject.org/koji/taskinfo?taskID=23681673
As always, you can find the .spec file in private-ruby-2.5 branch of ruby dist-gits.
Vít
Dne 13.4.2017 v 10:54 Vít Ondruch napsal(a):
Hi all,
Ruby 2.4 was released during Christmas and the upcoming Ruby 2.5 development is advancing, so I continue in the tradition and I got r58319 packaged for testing. The updated .spec file is available in dist-git private-ruby-2.5 branch and here is the scratch build:
https://koji.fedoraproject.org/koji/taskinfo?taskID=18952639
One thing I'd like to point out that upstream is working on gemification of StdLib. The question ATM is what the result will be. Hence, there is one big TODO in the .spec file [1]. The question if each of the gems should be unbundled or not. The future will tell hopefully.
Vít
[1] http://pkgs.fedoraproject.org/cgit/rpms/ruby.git/tree/ruby.spec?h=private-ru...
ruby-sig mailing list -- ruby-sig@lists.fedoraproject.org To unsubscribe send an email to ruby-sig-leave@lists.fedoraproject.org
ruby-sig mailing list -- ruby-sig@lists.fedoraproject.org To unsubscribe send an email to ruby-sig-leave@lists.fedoraproject.org
ruby-sig mailing list -- ruby-sig@lists.fedoraproject.org To unsubscribe send an email to ruby-sig-leave@lists.fedoraproject.org
Do we have a requirements document about ruby packaging? I'm all for avoiding upstream incompatibilities which we are currently not doing for some reasons. And having an official requirements document will make more clear what is a bug and what is a feature.
Jun Aruga wrote on 12/14/17 19:23:
OK thanks for the info.
Comparing the result of "gem list" command between upstream and our Fedora package, I found the difference. That can be confusing people.
Some of the gem are not shown in the result such as cmath for Fedora package ruby.
When running below command on mock, we can load cmath that is not in "gem list" on mock, maybe those are only shown as a result of "gem list".
irb(main):003:0> require 'cmath' => trueIs it possible to add those gems in the result as a compatibility for upstream Ruby? Hidden gems such as cmath are confusing users. We might also have to add additional gems as a recommendations like bigdecimal in ruby.spec as the result.
Recommends: rubygem(bigdecimal) >= %{bigdecimal_version}No "default: " in the gem list for Fedora package is from past version. That's fine for me.
## Upstream
On current latest trunk.
$ dest/bin/gem list
*** LOCAL GEMS ***
bigdecimal (default: 1.3.3) bundler (default: 1.16.1.pre1) cmath (default: 1.0.0) csv (default: 1.0.0) date (default: 1.0.0) dbm (default: 1.0.0) digest (default: 0.1.0) etc (default: 1.0.0) fcntl (default: 1.0.0) fileutils (default: 1.0.1) gdbm (default: 2.0.0) io-console (default: 0.4.6) ipaddr (default: 1.2.0) json (default: 2.1.0) openssl (default: 2.1.0) psych (default: 3.0.0) rdoc (default: 6.0.0) scanf (default: 1.0.0) sdbm (default: 1.0.0) stringio (default: 0.0.1) strscan (default: 0.0.1) webrick (default: 1.4.0.beta1) zlib (default: 1.0.0)
## Building with your SRPM, and checked on mock environment
After installing all the binary RPMs from your SRPM
<mock-chroot> sh-4.4# gem list
*** LOCAL GEMS ***
bigdecimal (1.3.3) did_you_mean (1.1.2) io-console (0.4.6) json (2.1.0) minitest (5.10.3) net-telnet (0.1.1) openssl (2.1.0.beta2) power_assert (1.1.1) psych (3.0.0) rake (12.3.0) rdoc (6.0.0) test-unit (3.2.7) xmlrpc (0.3.0)
Jun
On Thu, Dec 14, 2017 at 5:06 PM, Vít Ondruch vondruch@redhat.com wrote:
Well, this is not the way you can get the right archive. You have to use something like:
tool/make-snapshot -packages=xz tmpI previously published script which can generate the tarball using mock and update the spec file:
https://lists.fedoraproject.org/archives/list/ruby-sig@lists.fedoraproject.o...
V.
Dne 14.12.2017 v 15:16 Jun Aruga napsal(a):
Thanks for that.
I want you to add below kind of comment somethere in "private-ruby-2.5" branch or master ruby.spec file a way to create Source0 file.
# git clone https://github.com/ruby/ruby.git && cd ruby # git archive --prefix=ruby-2.5.0-r61214/ 06d36a1 | xz > ruby-2.5.0-r61214.tar.xz
Possible?
Jun
On Thu, Dec 14, 2017 at 2:42 PM, Vít Ondruch vondruch@redhat.com wrote:
Hi everybody,
Here is another test build of Ruby 2.5, this time it is r61214.
https://koji.fedoraproject.org/koji/taskinfo?taskID=23681673
As always, you can find the .spec file in private-ruby-2.5 branch of ruby dist-gits.
Vít
Dne 13.4.2017 v 10:54 Vít Ondruch napsal(a):
Hi all,
Ruby 2.4 was released during Christmas and the upcoming Ruby 2.5 development is advancing, so I continue in the tradition and I got r58319 packaged for testing. The updated .spec file is available in dist-git private-ruby-2.5 branch and here is the scratch build:
https://koji.fedoraproject.org/koji/taskinfo?taskID=18952639
One thing I'd like to point out that upstream is working on gemification of StdLib. The question ATM is what the result will be. Hence, there is one big TODO in the .spec file [1]. The question if each of the gems should be unbundled or not. The future will tell hopefully.
Vít
[1] http://pkgs.fedoraproject.org/cgit/rpms/ruby.git/tree/ruby.spec?h=private-ru...
ruby-sig mailing list -- ruby-sig@lists.fedoraproject.org To unsubscribe send an email to ruby-sig-leave@lists.fedoraproject.org
ruby-sig mailing list -- ruby-sig@lists.fedoraproject.org To unsubscribe send an email to ruby-sig-leave@lists.fedoraproject.org
ruby-sig mailing list -- ruby-sig@lists.fedoraproject.org To unsubscribe send an email to ruby-sig-leave@lists.fedoraproject.org
Dne 14.12.2017 v 18:23 Jun Aruga napsal(a):
OK thanks for the info.
Comparing the result of "gem list" command between upstream and our Fedora package, I found the difference. That can be confusing people.
Some of the gem are not shown in the result such as cmath for Fedora package ruby.
When running below command on mock, we can load cmath that is not in "gem list" on mock, maybe those are only shown as a result of "gem list".
irb(main):003:0> require 'cmath' => trueIs it possible to add those gems in the result as a compatibility for upstream Ruby? Hidden gems such as cmath are confusing users.
Interesting. That is definitely unintentional. Will take a look into it.
V.
We might also have to add additional gems as a recommendations like bigdecimal in ruby.spec as the result.
Recommends: rubygem(bigdecimal) >= %{bigdecimal_version}No "default: " in the gem list for Fedora package is from past version. That's fine for me.
## Upstream
On current latest trunk.
$ dest/bin/gem list
*** LOCAL GEMS ***
bigdecimal (default: 1.3.3) bundler (default: 1.16.1.pre1) cmath (default: 1.0.0) csv (default: 1.0.0) date (default: 1.0.0) dbm (default: 1.0.0) digest (default: 0.1.0) etc (default: 1.0.0) fcntl (default: 1.0.0) fileutils (default: 1.0.1) gdbm (default: 2.0.0) io-console (default: 0.4.6) ipaddr (default: 1.2.0) json (default: 2.1.0) openssl (default: 2.1.0) psych (default: 3.0.0) rdoc (default: 6.0.0) scanf (default: 1.0.0) sdbm (default: 1.0.0) stringio (default: 0.0.1) strscan (default: 0.0.1) webrick (default: 1.4.0.beta1) zlib (default: 1.0.0)
## Building with your SRPM, and checked on mock environment
After installing all the binary RPMs from your SRPM
<mock-chroot> sh-4.4# gem list
*** LOCAL GEMS ***
bigdecimal (1.3.3) did_you_mean (1.1.2) io-console (0.4.6) json (2.1.0) minitest (5.10.3) net-telnet (0.1.1) openssl (2.1.0.beta2) power_assert (1.1.1) psych (3.0.0) rake (12.3.0) rdoc (6.0.0) test-unit (3.2.7) xmlrpc (0.3.0)
Jun
On Thu, Dec 14, 2017 at 5:06 PM, Vít Ondruch vondruch@redhat.com wrote:
Well, this is not the way you can get the right archive. You have to use something like:
tool/make-snapshot -packages=xz tmpI previously published script which can generate the tarball using mock and update the spec file:
https://lists.fedoraproject.org/archives/list/ruby-sig@lists.fedoraproject.o...
V.
Dne 14.12.2017 v 15:16 Jun Aruga napsal(a):
Thanks for that.
I want you to add below kind of comment somethere in "private-ruby-2.5" branch or master ruby.spec file a way to create Source0 file.
# git clone https://github.com/ruby/ruby.git && cd ruby # git archive --prefix=ruby-2.5.0-r61214/ 06d36a1 | xz > ruby-2.5.0-r61214.tar.xz
Possible?
Jun
On Thu, Dec 14, 2017 at 2:42 PM, Vít Ondruch vondruch@redhat.com wrote:
Hi everybody,
Here is another test build of Ruby 2.5, this time it is r61214.
https://koji.fedoraproject.org/koji/taskinfo?taskID=23681673
As always, you can find the .spec file in private-ruby-2.5 branch of ruby dist-gits.
Vít
Dne 13.4.2017 v 10:54 Vít Ondruch napsal(a):
Hi all,
Ruby 2.4 was released during Christmas and the upcoming Ruby 2.5 development is advancing, so I continue in the tradition and I got r58319 packaged for testing. The updated .spec file is available in dist-git private-ruby-2.5 branch and here is the scratch build:
https://koji.fedoraproject.org/koji/taskinfo?taskID=18952639
One thing I'd like to point out that upstream is working on gemification of StdLib. The question ATM is what the result will be. Hence, there is one big TODO in the .spec file [1]. The question if each of the gems should be unbundled or not. The future will tell hopefully.
Vít
[1] http://pkgs.fedoraproject.org/cgit/rpms/ruby.git/tree/ruby.spec?h=private-ru...
ruby-sig mailing list -- ruby-sig@lists.fedoraproject.org To unsubscribe send an email to ruby-sig-leave@lists.fedoraproject.org
ruby-sig mailing list -- ruby-sig@lists.fedoraproject.org To unsubscribe send an email to ruby-sig-leave@lists.fedoraproject.org
ruby-sig mailing list -- ruby-sig@lists.fedoraproject.org To unsubscribe send an email to ruby-sig-leave@lists.fedoraproject.org
Dne 14.12.2017 v 18:41 Vít Ondruch napsal(a):
Dne 14.12.2017 v 18:23 Jun Aruga napsal(a):
OK thanks for the info.
Comparing the result of "gem list" command between upstream and our Fedora package, I found the difference. That can be confusing people.
Some of the gem are not shown in the result such as cmath for Fedora package ruby.
When running below command on mock, we can load cmath that is not in "gem list" on mock, maybe those are only shown as a result of "gem list".
irb(main):003:0> require 'cmath' => trueIs it possible to add those gems in the result as a compatibility for upstream Ruby? Hidden gems such as cmath are confusing users.
Interesting. That is definitely unintentional. Will take a look into it.
This appears to be related to the default location of where the gems are installed. Upstream Ruby installs the gems into their directory, we install the gems into home directory. And therefore RubyGems on Fedora are trying to load the specifications for the default gems from the home directory "/builddir/.gem/ruby/specifications/default" (testing in mock). So far, we never had the default gem specifications, so this was not issue.
V.
Alexander,
Do we have a requirements document about ruby packaging? I'm all for avoiding upstream incompatibilities which we are currently not doing for some reasons. And having an official requirements document will make more clear what is a bug and what is a feature.
We have a document for Ruby packaging here. https://fedoraproject.org/wiki/Packaging:Ruby
Below is a proposed document for Ruby 2.5. The section Detailed Description might be close for the requirement. But I think that there is NOT requirement document for Ruby 2.5 as far as I know. https://fedoraproject.org/wiki/Changes/Ruby_2.5
Vit,
This appears to be related to the default location of where the gems are installed. Upstream Ruby installs the gems into their directory, we install the gems into home directory.
Thanks for checking about the default gem specification,
Why did we decide the gems to not default local but home directly? I think that we might have to add the default gem behavior as one of the incompatibility list on the document somewhere.
And we need to take note that our other rubygem packages can be affected by the compatibility. Last time, we skipped a test case of rubygem-bundler by the compatibility. https://src.fedoraproject.org/rpms/rubygem-bundler/blob/master/f/rubygem-bun...
Everyone,
I want to add below thing as the requirement of Ruby 2.5.0.
- User can see stdlibs from "gem list", and they can update the gem's version by "gem update".
This is a new available operation from Ruby 2.5.0. Let me show you example with Ruby 2.5.0 preview1 version on upstream for the operation.
``` $ dest/bin/ruby -v ruby 2.5.0dev (2017-10-10 trunk 60153) [x86_64-linux]
$ dest/bin/gem list
*** LOCAL GEMS ***
bigdecimal (default: 1.3.2) bundler (default: 1.15.4) cmath (default: 0.0.1) csv (default: 0.1.0) date (default: 0.0.1) dbm (default: 1.0.0.beta1) digest (default: 0.1.0) etc (default: 0.2.1) fcntl (default: 0.0.1) fileutils (default: 0.7.2) gdbm (default: 2.0.0.beta1) io-console (default: 0.4.6) ipaddr (default: 1.0.0) json (default: 2.1.0) openssl (default: 2.1.0.beta1) psych (default: 3.0.0.beta3) rdoc (default: 6.0.0.beta3) scanf (default: 0.0.1) sdbm (default: 0.0.1) stringio (default: 0.0.1) strscan (default: 0.0.1) webrick (default: 1.4.0.beta1)
$ dest/bin/gem update fileutils Updating installed gems Updating fileutils Fetching: fileutils-1.0.1.gem (100%) Successfully installed fileutils-1.0.1 Parsing documentation for fileutils-1.0.1 Installing ri documentation for fileutils-1.0.1 Installing darkfish documentation for fileutils-1.0.1 Done installing documentation for fileutils after 0 seconds Parsing documentation for fileutils-1.0.1 Done installing documentation for fileutils after 0 seconds Gems updated: fileutils
$ dest/bin/gem list
*** LOCAL GEMS ***
bigdecimal (default: 1.3.2) bundler (default: 1.15.4) cmath (default: 0.0.1) csv (default: 0.1.0) date (default: 0.0.1) dbm (default: 1.0.0.beta1) digest (default: 0.1.0) etc (default: 0.2.1) fcntl (default: 0.0.1) fileutils (1.0.1, default: 0.7.2) gdbm (default: 2.0.0.beta1) io-console (default: 0.4.6) ipaddr (default: 1.0.0) json (default: 2.1.0) openssl (default: 2.1.0.beta1) psych (default: 3.0.0.beta3) rdoc (default: 6.0.0.beta3) scanf (default: 0.0.1) sdbm (default: 0.0.1) stringio (default: 0.0.1) strscan (default: 0.0.1) webrick (default: 1.4.0.beta1) zlib (default: 0.1.0)
$ dest/bin/gem list | grep fileutils fileutils (1.0.1, default: 0.7.2) ```
To filling this requirement, 1. We might have to create new subpackges for the cmath, csv, fileutils, and etc in ruby.spec This is about https://src.fedoraproject.org/rpms/ruby/blob/private-ruby-2.5/f/ruby.spec#_9... # TODO: Gemify these libraries
2. We might have to add those as Requires rather than Recommends like blow current code. This is for the compatibility of upstream Ruby 2.5.0. If upstream Ruby is keeping the gems as a default, we would add it as a Requires of binary RPM ruby package.
ruby.spec ``` Recommends: ruby(rubygems) >= %{rubygems_version} Recommends: rubygem(bigdecimal) >= %{bigdecimal_version} Recommends: rubygem(did_you_mean) >= %{did_you_mean_version} Recommends: rubygem(openssl) >= %{openssl_version} ```
3 we might have to independent RPM packages such as rubygem-cmath, rubygem-csv, rubygem-fileutils If we keep the stdlibs (such as fileutils) as latest version as much as possible, monitoring the upstream ( https://rubygems.org/gems/cmath , and etc) rather than keeping same version with ruby internal default gems, we do not have to do this. That depends on the policy.
Jun
On Thu, Dec 14, 2017 at 7:03 PM, Vít Ondruch vondruch@redhat.com wrote:
Dne 14.12.2017 v 18:41 Vít Ondruch napsal(a):
Dne 14.12.2017 v 18:23 Jun Aruga napsal(a):
OK thanks for the info.
Comparing the result of "gem list" command between upstream and our Fedora package, I found the difference. That can be confusing people.
Some of the gem are not shown in the result such as cmath for Fedora package ruby.
When running below command on mock, we can load cmath that is not in "gem list" on mock, maybe those are only shown as a result of "gem list".
irb(main):003:0> require 'cmath' => trueIs it possible to add those gems in the result as a compatibility for upstream Ruby? Hidden gems such as cmath are confusing users.
Interesting. That is definitely unintentional. Will take a look into it.
This appears to be related to the default location of where the gems are installed. Upstream Ruby installs the gems into their directory, we install the gems into home directory. And therefore RubyGems on Fedora are trying to load the specifications for the default gems from the home directory "/builddir/.gem/ruby/specifications/default" (testing in mock). So far, we never had the default gem specifications, so this was not issue.
V.
ruby-sig mailing list -- ruby-sig@lists.fedoraproject.org To unsubscribe send an email to ruby-sig-leave@lists.fedoraproject.org
Jun Aruga wrote on 12/15/17 13:47:
Alexander,
Do we have a requirements document about ruby packaging? I'm all for avoiding upstream incompatibilities which we are currently not doing for some reasons. And having an official requirements document will make more clear what is a bug and what is a feature.
We have a document for Ruby packaging here. https://fedoraproject.org/wiki/Packaging:Ruby
Thank you. What I can't spot in there is requirements around mini-portile and having gem dependencies match these of upstream. I see that version can be changed, no guideline about removing items.
Below is a proposed document for Ruby 2.5. The section Detailed Description might be close for the requirement. But I think that there is NOT requirement document for Ruby 2.5 as far as I know. https://fedoraproject.org/wiki/Changes/Ruby_2.5
...
Aleksandar,
Thank you. What I can't spot in there is requirements around mini-portile and having gem dependencies match these of upstream. I see that version can be changed, no guideline about removing items.
I am not familiar with mini_portile. I have only used it a few times in my past time. Maybe. https://github.com/flavorjones/mini_portile
I think it is possible to update the document by yourself if you like.
The document is not updated since January 2015. https://fedoraproject.org/wiki/Packaging:Ruby
Below document might be useful for you to update document. https://fedoraproject.org/wiki/Reporting_problems_with_Docs
Jun
On Fri, Dec 15, 2017 at 12:56 PM, Aleksandar Kostadinov akostadi@redhat.com wrote:
Jun Aruga wrote on 12/15/17 13:47:
Alexander,
Do we have a requirements document about ruby packaging? I'm all for avoiding upstream incompatibilities which we are currently not doing for some reasons. And having an official requirements document will make more clear what is a bug and what is a feature.
We have a document for Ruby packaging here. https://fedoraproject.org/wiki/Packaging:Ruby
Thank you. What I can't spot in there is requirements around mini-portile and having gem dependencies match these of upstream. I see that version can be changed, no guideline about removing items.
Below is a proposed document for Ruby 2.5. The section Detailed Description might be close for the requirement. But I think that there is NOT requirement document for Ruby 2.5 as far as I know. https://fedoraproject.org/wiki/Changes/Ruby_2.5
...
Jun Aruga wrote on 12/15/17 15:12:
Aleksandar,
Thank you. What I can't spot in there is requirements around mini-portile and having gem dependencies match these of upstream. I see that version can be changed, no guideline about removing items.
I am not familiar with mini_portile. I have only used it a few times in my past time. Maybe. https://github.com/flavorjones/mini_portile
I think it is possible to update the document by yourself if you like.
The document is not updated since January 2015. https://fedoraproject.org/wiki/Packaging:Ruby
I just know about that mini_portile discrepancy and I don't agree with it. The thing is whoever takes the decisions to ban some dependencies an make incompatible changes to document it for future reference.
Below document might be useful for you to update document. https://fedoraproject.org/wiki/Reporting_problems_with_Docs
Jun
On Fri, Dec 15, 2017 at 12:56 PM, Aleksandar Kostadinov akostadi@redhat.com wrote:
Jun Aruga wrote on 12/15/17 13:47:
Alexander,
Do we have a requirements document about ruby packaging? I'm all for avoiding upstream incompatibilities which we are currently not doing for some reasons. And having an official requirements document will make more clear what is a bug and what is a feature.
We have a document for Ruby packaging here. https://fedoraproject.org/wiki/Packaging:Ruby
Thank you. What I can't spot in there is requirements around mini-portile and having gem dependencies match these of upstream. I see that version can be changed, no guideline about removing items.
Below is a proposed document for Ruby 2.5. The section Detailed Description might be close for the requirement. But I think that there is NOT requirement document for Ruby 2.5 as far as I know. https://fedoraproject.org/wiki/Changes/Ruby_2.5
...
Dne 15.12.2017 v 12:47 Jun Aruga napsal(a):
Vit,
This appears to be related to the default location of where the gems are installed. Upstream Ruby installs the gems into their directory, we install the gems into home directory.
Thanks for checking about the default gem specification,
Why did we decide the gems to not default local but home directly?
I you build Ruby by yourself, they are installed by default into /urs/local. The distribution installs the packages into /usr. If you want to install additional gems using "gem install", they are installed into those directories. To do that, you need enough privileges (and you can see that historically, things like "sudo gem install" were always suggested) and you are mixing RPM managed and gem managed packages (and generally asking for problems). Alternatively you need to specify additional parameters on command line to install the additional gems into user directory.
This might be fine if you build Ruby by yourself or using RVM or rbenv, but non of these defaults respects the purpose of distribution and neither they are user friendly.
There is upstream ticket asking installation of gem to user directory to become default and we are not the only distribution which changed the defaults.
https://bugs.ruby-lang.org/issues/11731
Vít
Dne 14.12.2017 v 19:03 Vít Ondruch napsal(a):
Dne 14.12.2017 v 18:41 Vít Ondruch napsal(a):
Dne 14.12.2017 v 18:23 Jun Aruga napsal(a):
OK thanks for the info.
Comparing the result of "gem list" command between upstream and our Fedora package, I found the difference. That can be confusing people.
Some of the gem are not shown in the result such as cmath for Fedora package ruby.
When running below command on mock, we can load cmath that is not in "gem list" on mock, maybe those are only shown as a result of "gem list".
irb(main):003:0> require 'cmath' => trueIs it possible to add those gems in the result as a compatibility for upstream Ruby? Hidden gems such as cmath are confusing users.
Interesting. That is definitely unintentional. Will take a look into it.
This appears to be related to the default location of where the gems are installed. Upstream Ruby installs the gems into their directory, we install the gems into home directory. And therefore RubyGems on Fedora are trying to load the specifications for the default gems from the home directory "/builddir/.gem/ruby/specifications/default" (testing in mock). So far, we never had the default gem specifications, so this was not issue.
Here is updated build, which should fix the issues:
https://koji.fedoraproject.org/koji/taskinfo?taskID=23793602
The patch used to fix this in attachment. I'd love some feedback prior I push this into git. Mainly, I'd like you to test:
1) If "gem install" as a regular user still works the same. 2) If "gem install" as root still works the same. 3) If the RPM packages in Fedora (probably just noarch) still installs and runs just fine. 4) If rubygem- RPM packages build using this ruby are still build and installed correctly. 5) Any additional scenario you can think of ...
Thx for testing.
Vít
Vit thanks for the working.
I tested it.
- If "gem install" as a regular user still works the same.
Right now there is a 2 type of packages. Some gem package are "default", others are not. The gem package that is managed the ruby sub package is not "default" like "bigdecimal"
What is the future plan for these kind of pacakge such as "bigdecimal"? 1. These are "default" removing the sub package? Or 2. Current default package like "cmath" becomes not "default" creating the sub package?
Fedora Ruby by regular user.
``` [mockbuild@026f2c75e4664cfe887005e710a5497e ~]$ gem list | grep default cmath (default: 1.0.0) csv (default: 1.0.0) date (default: 1.0.0) dbm (default: 1.0.0) digest (default: 0.1.0) etc (default: 1.0.0) fcntl (default: 1.0.0) fiddle (default: 1.0.0) fileutils (default: 1.0.1) gdbm (default: 2.0.0) ipaddr (default: 1.2.0) scanf (default: 1.0.0) sdbm (default: 1.0.0) stringio (default: 0.0.1) strscan (default: 0.0.1) webrick (default: 1.4.0.beta1) zlib (default: 1.0.0)
[mockbuild@026f2c75e4664cfe887005e710a5497e ~]$ gem list | grep -v default bigdecimal (1.3.3) did_you_mean (1.1.2) io-console (0.4.6) json (2.1.0) minitest (5.10.3) net-telnet (0.1.1) openssl (2.1.0.beta2) power_assert (1.1.1) psych (3.0.0) rake (12.3.0) rdoc (6.0.0) test-unit (3.2.7) xmlrpc (0.3.0) ```
On upstream Ruby
``` $ dest/bin/gem list
*** LOCAL GEMS ***
bigdecimal (default: 1.3.3) bundler (default: 1.16.1.pre1) cmath (default: 1.0.0) csv (default: 1.0.0) date (default: 1.0.0) dbm (default: 1.0.0) digest (default: 0.1.0) etc (default: 1.0.0) fcntl (default: 1.0.0) fileutils (default: 1.0.1) gdbm (default: 2.0.0) io-console (default: 0.4.6) ipaddr (default: 1.2.0) json (default: 2.1.0) openssl (default: 2.1.0) psych (default: 3.0.0) rdoc (default: 6.0.0) scanf (default: 1.0.0) sdbm (default: 1.0.0) stringio (default: 0.0.1) strscan (default: 0.0.1) webrick (default: 1.4.0.beta1) zlib (default: 1.0.0) ```
- If "gem install" as root still works the same.
"gem list" result is same for regular user's situation.
I found the difference of the behavior between Upstream Ruby and Fedora Ruby. Case 2-1. does not install ri document by "gem install".
1-1. Upstream Ruby by root user
[root@unused-4-164 ~]# /usr/local/ruby-2.5.0.pre1/bin/gem install digest Fetching: digest-0.0.1.gem (100%) Successfully installed digest-0.0.1 Parsing documentation for digest-0.0.1 Installing ri documentation for digest-0.0.1 Done installing documentation for digest after 0 seconds 1 gem installed
2-1. Fedora Ruby by root user
<mock-chroot> sh-4.4# gem install webrick Fetching: webrick-1.4.1.gem (100%) Successfully installed webrick-1.4.1 1 gem installed
2-2. Fedora Ruby by regular user
[mockbuild@c187f3581b4e45ecb2837fe5ab6a0af5 ~]$ gem install webrick Fetching: webrick-1.4.1.gem (100%) WARNING: You don't have /builddir/bin in your PATH, gem executables will not run. Successfully installed webrick-1.4.1 Parsing documentation for webrick-1.4.1 Installing ri documentation for webrick-1.4.1 Done installing documentation for webrick after 0 seconds 1 gem installed
I do not know this difference is this Fedora Ruby specific. This might be related to this issue? https://src.fedoraproject.org/rpms/ruby/pull-request/9
- If the RPM packages in Fedora (probably just noarch) still installs
and runs just fine.
- If rubygem- RPM packages build using this ruby are still build and
I could not test below cases. I tried to build rubygem-bundler for your Ruby RPMs. But I could not build because of conflict with ruby-2.4.2.
rubygem-bundler
``` $ mock -r fedora-rawhide-x86_64 --with tests -n *.rpm ... Error: Problem: cannot install both ruby-libs-2.4.2-85.fc28.x86_64 and ruby-libs-2.5.0-0.1.r61214.fc28.x86_64 ```
Jun
On Tue, Dec 19, 2017 at 4:12 PM, Vít Ondruch vondruch@redhat.com wrote:
Dne 14.12.2017 v 19:03 Vít Ondruch napsal(a):
Dne 14.12.2017 v 18:41 Vít Ondruch napsal(a):
Dne 14.12.2017 v 18:23 Jun Aruga napsal(a):
OK thanks for the info.
Comparing the result of "gem list" command between upstream and our Fedora package, I found the difference. That can be confusing people.
Some of the gem are not shown in the result such as cmath for Fedora package ruby.
When running below command on mock, we can load cmath that is not in "gem list" on mock, maybe those are only shown as a result of "gem list".
irb(main):003:0> require 'cmath' => trueIs it possible to add those gems in the result as a compatibility for upstream Ruby? Hidden gems such as cmath are confusing users.
Interesting. That is definitely unintentional. Will take a look into it.
This appears to be related to the default location of where the gems are installed. Upstream Ruby installs the gems into their directory, we install the gems into home directory. And therefore RubyGems on Fedora are trying to load the specifications for the default gems from the home directory "/builddir/.gem/ruby/specifications/default" (testing in mock). So far, we never had the default gem specifications, so this was not issue.
Here is updated build, which should fix the issues:
https://koji.fedoraproject.org/koji/taskinfo?taskID=23793602
The patch used to fix this in attachment. I'd love some feedback prior I push this into git. Mainly, I'd like you to test:
- If "gem install" as a regular user still works the same.
- If "gem install" as root still works the same.
- If the RPM packages in Fedora (probably just noarch) still installs
and runs just fine. 4) If rubygem- RPM packages build using this ruby are still build and installed correctly. 5) Any additional scenario you can think of ...
Thx for testing.
Vít
ruby-sig mailing list -- ruby-sig@lists.fedoraproject.org To unsubscribe send an email to ruby-sig-leave@lists.fedoraproject.org
One more thing.
You would find format errors for your modification part if you run `rubocop`.
``` $ rubocop operating_system.rb ```
Jun
On Tue, Dec 19, 2017 at 7:19 PM, Jun Aruga jaruga@redhat.com wrote:
Vit thanks for the working.
I tested it.
- If "gem install" as a regular user still works the same.
Right now there is a 2 type of packages. Some gem package are "default", others are not. The gem package that is managed the ruby sub package is not "default" like "bigdecimal"
What is the future plan for these kind of pacakge such as "bigdecimal"?
- These are "default" removing the sub package?
Or 2. Current default package like "cmath" becomes not "default" creating the sub package?
Fedora Ruby by regular user.
[mockbuild@026f2c75e4664cfe887005e710a5497e ~]$ gem list | grep default cmath (default: 1.0.0) csv (default: 1.0.0) date (default: 1.0.0) dbm (default: 1.0.0) digest (default: 0.1.0) etc (default: 1.0.0) fcntl (default: 1.0.0) fiddle (default: 1.0.0) fileutils (default: 1.0.1) gdbm (default: 2.0.0) ipaddr (default: 1.2.0) scanf (default: 1.0.0) sdbm (default: 1.0.0) stringio (default: 0.0.1) strscan (default: 0.0.1) webrick (default: 1.4.0.beta1) zlib (default: 1.0.0) [mockbuild@026f2c75e4664cfe887005e710a5497e ~]$ gem list | grep -v default bigdecimal (1.3.3) did_you_mean (1.1.2) io-console (0.4.6) json (2.1.0) minitest (5.10.3) net-telnet (0.1.1) openssl (2.1.0.beta2) power_assert (1.1.1) psych (3.0.0) rake (12.3.0) rdoc (6.0.0) test-unit (3.2.7) xmlrpc (0.3.0)On upstream Ruby
$ dest/bin/gem list *** LOCAL GEMS *** bigdecimal (default: 1.3.3) bundler (default: 1.16.1.pre1) cmath (default: 1.0.0) csv (default: 1.0.0) date (default: 1.0.0) dbm (default: 1.0.0) digest (default: 0.1.0) etc (default: 1.0.0) fcntl (default: 1.0.0) fileutils (default: 1.0.1) gdbm (default: 2.0.0) io-console (default: 0.4.6) ipaddr (default: 1.2.0) json (default: 2.1.0) openssl (default: 2.1.0) psych (default: 3.0.0) rdoc (default: 6.0.0) scanf (default: 1.0.0) sdbm (default: 1.0.0) stringio (default: 0.0.1) strscan (default: 0.0.1) webrick (default: 1.4.0.beta1) zlib (default: 1.0.0)
- If "gem install" as root still works the same.
"gem list" result is same for regular user's situation.
I found the difference of the behavior between Upstream Ruby and Fedora Ruby. Case 2-1. does not install ri document by "gem install".
1-1. Upstream Ruby by root user
[root@unused-4-164 ~]# /usr/local/ruby-2.5.0.pre1/bin/gem install digest Fetching: digest-0.0.1.gem (100%) Successfully installed digest-0.0.1 Parsing documentation for digest-0.0.1 Installing ri documentation for digest-0.0.1 Done installing documentation for digest after 0 seconds 1 gem installed
2-1. Fedora Ruby by root user
<mock-chroot> sh-4.4# gem install webrick Fetching: webrick-1.4.1.gem (100%) Successfully installed webrick-1.4.1 1 gem installed
2-2. Fedora Ruby by regular user
[mockbuild@c187f3581b4e45ecb2837fe5ab6a0af5 ~]$ gem install webrick Fetching: webrick-1.4.1.gem (100%) WARNING: You don't have /builddir/bin in your PATH, gem executables will not run. Successfully installed webrick-1.4.1 Parsing documentation for webrick-1.4.1 Installing ri documentation for webrick-1.4.1 Done installing documentation for webrick after 0 seconds 1 gem installed
I do not know this difference is this Fedora Ruby specific. This might be related to this issue? https://src.fedoraproject.org/rpms/ruby/pull-request/9
- If the RPM packages in Fedora (probably just noarch) still installs
and runs just fine.
- If rubygem- RPM packages build using this ruby are still build and
I could not test below cases. I tried to build rubygem-bundler for your Ruby RPMs. But I could not build because of conflict with ruby-2.4.2.
rubygem-bundler
$ mock -r fedora-rawhide-x86_64 --with tests -n *.rpm ... Error: Problem: cannot install both ruby-libs-2.4.2-85.fc28.x86_64 and ruby-libs-2.5.0-0.1.r61214.fc28.x86_64Jun
On Tue, Dec 19, 2017 at 4:12 PM, Vít Ondruch vondruch@redhat.com wrote:
Dne 14.12.2017 v 19:03 Vít Ondruch napsal(a):
Dne 14.12.2017 v 18:41 Vít Ondruch napsal(a):
Dne 14.12.2017 v 18:23 Jun Aruga napsal(a):
OK thanks for the info.
Comparing the result of "gem list" command between upstream and our Fedora package, I found the difference. That can be confusing people.
Some of the gem are not shown in the result such as cmath for Fedora package ruby.
When running below command on mock, we can load cmath that is not in "gem list" on mock, maybe those are only shown as a result of "gem list".
irb(main):003:0> require 'cmath' => trueIs it possible to add those gems in the result as a compatibility for upstream Ruby? Hidden gems such as cmath are confusing users.
Interesting. That is definitely unintentional. Will take a look into it.
This appears to be related to the default location of where the gems are installed. Upstream Ruby installs the gems into their directory, we install the gems into home directory. And therefore RubyGems on Fedora are trying to load the specifications for the default gems from the home directory "/builddir/.gem/ruby/specifications/default" (testing in mock). So far, we never had the default gem specifications, so this was not issue.
Here is updated build, which should fix the issues:
https://koji.fedoraproject.org/koji/taskinfo?taskID=23793602
The patch used to fix this in attachment. I'd love some feedback prior I push this into git. Mainly, I'd like you to test:
- If "gem install" as a regular user still works the same.
- If "gem install" as root still works the same.
- If the RPM packages in Fedora (probably just noarch) still installs
and runs just fine. 4) If rubygem- RPM packages build using this ruby are still build and installed correctly. 5) Any additional scenario you can think of ...
Thx for testing.
Vít
ruby-sig mailing list -- ruby-sig@lists.fedoraproject.org To unsubscribe send an email to ruby-sig-leave@lists.fedoraproject.org
-- Jun Aruga jaruga@redhat.com IRC: jaruga, Office: TPB(Technology Park Brno) Building C 1F, Brno, Czech Republic
I found the difference of the behavior between Upstream Ruby and Fedora Ruby. Case 2-1. does not install ri document by "gem install".
When I tested some things for current private-ruby-2.5 branch, the result is okay like this.
2-1. Fedora Ruby by root user
``` <mock-chroot> sh-4.4# gem install webrick Fetching: webrick-1.4.1.gem (100%) Successfully installed webrick-1.4.1 Parsing documentation for webrick-1.4.1 Installing ri documentation for webrick-1.4.1 Done installing documentation for webrick after 0 seconds 1 gem installed ```
2-2. Fedora Ruby by regular user
``` [mockbuild@23d5fd90050e4ad382984b434162aa67 ~]$ gem install webrick Fetching: webrick-1.4.1.gem (100%) Successfully installed webrick-1.4.1 Parsing documentation for webrick-1.4.1 Installing ri documentation for webrick-1.4.1 Done installing documentation for webrick after 0 seconds 1 gem installed ```
On Tue, Dec 19, 2017 at 7:24 PM, Jun Aruga jaruga@redhat.com wrote:
One more thing.
You would find format errors for your modification part if you run `rubocop`.
$ rubocop operating_system.rbJun
On Tue, Dec 19, 2017 at 7:19 PM, Jun Aruga jaruga@redhat.com wrote:
Vit thanks for the working.
I tested it.
- If "gem install" as a regular user still works the same.
Right now there is a 2 type of packages. Some gem package are "default", others are not. The gem package that is managed the ruby sub package is not "default" like "bigdecimal"
What is the future plan for these kind of pacakge such as "bigdecimal"?
- These are "default" removing the sub package?
Or 2. Current default package like "cmath" becomes not "default" creating the sub package?
Fedora Ruby by regular user.
[mockbuild@026f2c75e4664cfe887005e710a5497e ~]$ gem list | grep default cmath (default: 1.0.0) csv (default: 1.0.0) date (default: 1.0.0) dbm (default: 1.0.0) digest (default: 0.1.0) etc (default: 1.0.0) fcntl (default: 1.0.0) fiddle (default: 1.0.0) fileutils (default: 1.0.1) gdbm (default: 2.0.0) ipaddr (default: 1.2.0) scanf (default: 1.0.0) sdbm (default: 1.0.0) stringio (default: 0.0.1) strscan (default: 0.0.1) webrick (default: 1.4.0.beta1) zlib (default: 1.0.0) [mockbuild@026f2c75e4664cfe887005e710a5497e ~]$ gem list | grep -v default bigdecimal (1.3.3) did_you_mean (1.1.2) io-console (0.4.6) json (2.1.0) minitest (5.10.3) net-telnet (0.1.1) openssl (2.1.0.beta2) power_assert (1.1.1) psych (3.0.0) rake (12.3.0) rdoc (6.0.0) test-unit (3.2.7) xmlrpc (0.3.0)On upstream Ruby
$ dest/bin/gem list *** LOCAL GEMS *** bigdecimal (default: 1.3.3) bundler (default: 1.16.1.pre1) cmath (default: 1.0.0) csv (default: 1.0.0) date (default: 1.0.0) dbm (default: 1.0.0) digest (default: 0.1.0) etc (default: 1.0.0) fcntl (default: 1.0.0) fileutils (default: 1.0.1) gdbm (default: 2.0.0) io-console (default: 0.4.6) ipaddr (default: 1.2.0) json (default: 2.1.0) openssl (default: 2.1.0) psych (default: 3.0.0) rdoc (default: 6.0.0) scanf (default: 1.0.0) sdbm (default: 1.0.0) stringio (default: 0.0.1) strscan (default: 0.0.1) webrick (default: 1.4.0.beta1) zlib (default: 1.0.0)
- If "gem install" as root still works the same.
"gem list" result is same for regular user's situation.
I found the difference of the behavior between Upstream Ruby and Fedora Ruby. Case 2-1. does not install ri document by "gem install".
1-1. Upstream Ruby by root user
[root@unused-4-164 ~]# /usr/local/ruby-2.5.0.pre1/bin/gem install digest Fetching: digest-0.0.1.gem (100%) Successfully installed digest-0.0.1 Parsing documentation for digest-0.0.1 Installing ri documentation for digest-0.0.1 Done installing documentation for digest after 0 seconds 1 gem installed
2-1. Fedora Ruby by root user
<mock-chroot> sh-4.4# gem install webrick Fetching: webrick-1.4.1.gem (100%) Successfully installed webrick-1.4.1 1 gem installed
2-2. Fedora Ruby by regular user
[mockbuild@c187f3581b4e45ecb2837fe5ab6a0af5 ~]$ gem install webrick Fetching: webrick-1.4.1.gem (100%) WARNING: You don't have /builddir/bin in your PATH, gem executables will not run. Successfully installed webrick-1.4.1 Parsing documentation for webrick-1.4.1 Installing ri documentation for webrick-1.4.1 Done installing documentation for webrick after 0 seconds 1 gem installed
I do not know this difference is this Fedora Ruby specific. This might be related to this issue? https://src.fedoraproject.org/rpms/ruby/pull-request/9
- If the RPM packages in Fedora (probably just noarch) still installs
and runs just fine.
- If rubygem- RPM packages build using this ruby are still build and
I could not test below cases. I tried to build rubygem-bundler for your Ruby RPMs. But I could not build because of conflict with ruby-2.4.2.
rubygem-bundler
$ mock -r fedora-rawhide-x86_64 --with tests -n *.rpm ... Error: Problem: cannot install both ruby-libs-2.4.2-85.fc28.x86_64 and ruby-libs-2.5.0-0.1.r61214.fc28.x86_64Jun
On Tue, Dec 19, 2017 at 4:12 PM, Vít Ondruch vondruch@redhat.com wrote:
Dne 14.12.2017 v 19:03 Vít Ondruch napsal(a):
Dne 14.12.2017 v 18:41 Vít Ondruch napsal(a):
Dne 14.12.2017 v 18:23 Jun Aruga napsal(a):
OK thanks for the info.
Comparing the result of "gem list" command between upstream and our Fedora package, I found the difference. That can be confusing people.
Some of the gem are not shown in the result such as cmath for Fedora package ruby.
When running below command on mock, we can load cmath that is not in "gem list" on mock, maybe those are only shown as a result of "gem list".
irb(main):003:0> require 'cmath' => trueIs it possible to add those gems in the result as a compatibility for upstream Ruby? Hidden gems such as cmath are confusing users.
Interesting. That is definitely unintentional. Will take a look into it.
This appears to be related to the default location of where the gems are installed. Upstream Ruby installs the gems into their directory, we install the gems into home directory. And therefore RubyGems on Fedora are trying to load the specifications for the default gems from the home directory "/builddir/.gem/ruby/specifications/default" (testing in mock). So far, we never had the default gem specifications, so this was not issue.
Here is updated build, which should fix the issues:
https://koji.fedoraproject.org/koji/taskinfo?taskID=23793602
The patch used to fix this in attachment. I'd love some feedback prior I push this into git. Mainly, I'd like you to test:
- If "gem install" as a regular user still works the same.
- If "gem install" as root still works the same.
- If the RPM packages in Fedora (probably just noarch) still installs
and runs just fine. 4) If rubygem- RPM packages build using this ruby are still build and installed correctly. 5) Any additional scenario you can think of ...
Thx for testing.
Vít
ruby-sig mailing list -- ruby-sig@lists.fedoraproject.org To unsubscribe send an email to ruby-sig-leave@lists.fedoraproject.org
-- Jun Aruga jaruga@redhat.com IRC: jaruga, Office: TPB(Technology Park Brno) Building C 1F, Brno, Czech Republic
-- Jun Aruga jaruga@redhat.com IRC: jaruga, Office: TPB(Technology Park Brno) Building C 1F, Brno, Czech Republic
Dne 19.12.2017 v 19:19 Jun Aruga napsal(a):
Vit thanks for the working.
I tested it.
- If "gem install" as a regular user still works the same.
Right now there is a 2 type of packages. Some gem package are "default", others are not. The gem package that is managed the ruby sub package is not "default" like "bigdecimal"
What is the future plan for these kind of pacakge such as "bigdecimal"?
- These are "default" removing the sub package?
Or 2. Current default package like "cmath" becomes not "default" creating the sub package?
There are several differences between how upstream works and how Fedora works.
1) In upstream, "gem install" mixes the packages with the gems bundled in Ruby. One of the reasons for "default" gems is to prevent "gem uninstall" from removing these packages. On Fedora, "gem install" does not manage RPM managed dependencies, so we don't face this issues and we can ignore this feature.
2) On Fedora, we typically keep only single version of package available. If for example upstream releases new version of JSON, we wont to remove the old version and install the new version. This is different from what "gem update" does, since "gem update" keeps the old version on the system. As long as we have "overlapped" packages which allows these updates, then it should be better to make regular gems from the default gems.
Therefore the plan is to keep the stuff as it is now, i.e. keep the subpackages as they are now. As far as I know, there should not be any concerning difference in behavior of default and non-default gems. If there is need for updated "cmat" etc, we should probably move them to nondefault. We can do it optionally anyway, but there is more then a few of them ...
Fedora Ruby by regular user.
[mockbuild@026f2c75e4664cfe887005e710a5497e ~]$ gem list | grep default cmath (default: 1.0.0) csv (default: 1.0.0) date (default: 1.0.0) dbm (default: 1.0.0) digest (default: 0.1.0) etc (default: 1.0.0) fcntl (default: 1.0.0) fiddle (default: 1.0.0) fileutils (default: 1.0.1) gdbm (default: 2.0.0) ipaddr (default: 1.2.0) scanf (default: 1.0.0) sdbm (default: 1.0.0) stringio (default: 0.0.1) strscan (default: 0.0.1) webrick (default: 1.4.0.beta1) zlib (default: 1.0.0) [mockbuild@026f2c75e4664cfe887005e710a5497e ~]$ gem list | grep -v default bigdecimal (1.3.3) did_you_mean (1.1.2) io-console (0.4.6) json (2.1.0) minitest (5.10.3) net-telnet (0.1.1) openssl (2.1.0.beta2) power_assert (1.1.1) psych (3.0.0) rake (12.3.0) rdoc (6.0.0) test-unit (3.2.7) xmlrpc (0.3.0)On upstream Ruby
$ dest/bin/gem list *** LOCAL GEMS *** bigdecimal (default: 1.3.3) bundler (default: 1.16.1.pre1) cmath (default: 1.0.0) csv (default: 1.0.0) date (default: 1.0.0) dbm (default: 1.0.0) digest (default: 0.1.0) etc (default: 1.0.0) fcntl (default: 1.0.0) fileutils (default: 1.0.1) gdbm (default: 2.0.0) io-console (default: 0.4.6) ipaddr (default: 1.2.0) json (default: 2.1.0) openssl (default: 2.1.0) psych (default: 3.0.0) rdoc (default: 6.0.0) scanf (default: 1.0.0) sdbm (default: 1.0.0) stringio (default: 0.0.1) strscan (default: 0.0.1) webrick (default: 1.4.0.beta1) zlib (default: 1.0.0)
- If "gem install" as root still works the same.
"gem list" result is same for regular user's situation.
I found the difference of the behavior between Upstream Ruby and Fedora Ruby. Case 2-1. does not install ri document by "gem install".
This is interesting. I remember to notice the shorter output, but I didn't pay enough attention to it. Will take a look at it.
1-1. Upstream Ruby by root user
[root@unused-4-164 ~]# /usr/local/ruby-2.5.0.pre1/bin/gem install digest Fetching: digest-0.0.1.gem (100%) Successfully installed digest-0.0.1 Parsing documentation for digest-0.0.1 Installing ri documentation for digest-0.0.1 Done installing documentation for digest after 0 seconds 1 gem installed
2-1. Fedora Ruby by root user
<mock-chroot> sh-4.4# gem install webrick Fetching: webrick-1.4.1.gem (100%) Successfully installed webrick-1.4.1 1 gem installed
2-2. Fedora Ruby by regular user
[mockbuild@c187f3581b4e45ecb2837fe5ab6a0af5 ~]$ gem install webrick Fetching: webrick-1.4.1.gem (100%) WARNING: You don't have /builddir/bin in your PATH, gem executables will not run. Successfully installed webrick-1.4.1 Parsing documentation for webrick-1.4.1 Installing ri documentation for webrick-1.4.1 Done installing documentation for webrick after 0 seconds 1 gem installed
I do not know this difference is this Fedora Ruby specific. This might be related to this issue? https://src.fedoraproject.org/rpms/ruby/pull-request/9
- If the RPM packages in Fedora (probably just noarch) still installs
and runs just fine.
- If rubygem- RPM packages build using this ruby are still build and
I could not test below cases. I tried to build rubygem-bundler for your Ruby RPMs. But I could not build because of conflict with ruby-2.4.2.
rubygem-bundler
$ mock -r fedora-rawhide-x86_64 --with tests -n *.rpm ... Error: Problem: cannot install both ruby-libs-2.4.2-85.fc28.x86_64 and ruby-libs-2.5.0-0.1.r61214.fc28.x86_64
You are probably missing some dependency in buildroot. Hard to tell more from this short snippet ...
Vít
Dne 20.12.2017 v 17:11 Vít Ondruch napsal(a):
Dne 19.12.2017 v 19:19 Jun Aruga napsal(a):
- If "gem install" as root still works the same.
"gem list" result is same for regular user's situation.
I found the difference of the behavior between Upstream Ruby and Fedora Ruby. Case 2-1. does not install ri document by "gem install".
This is interesting. I remember to notice the shorter output, but I didn't pay enough attention to it. Will take a look at it.
Apparently I have met this issue already:
https://github.com/rubygems/rubygems/issues/1470
So as long as upstream ignores this issue, there are just two options:
1) The documentation wont be installed by default. 2) The handling of default gems will be broken.
Neither is ideal, but I prefer the first option a bit. If somebody needs the documentation, it can be generated explicitly (gem rdoc).
Vít
Neither is ideal, but I prefer the first option a bit. If somebody needs
the documentation, it can be generated explicitly (gem rdoc).
3) Fixing the issue by yourself and sending the pull-request to rubygems project
You asked the upstream today, then if they are stumbling to fix it, "3)" is a good way isn't it to promote fixing the issue isn't it?
Jun
On Thu, Dec 21, 2017 at 12:29 PM, Vít Ondruch vondruch@redhat.com wrote:
Dne 20.12.2017 v 17:11 Vít Ondruch napsal(a):
Dne 19.12.2017 v 19:19 Jun Aruga napsal(a):
- If "gem install" as root still works the same.
"gem list" result is same for regular user's situation.
I found the difference of the behavior between Upstream Ruby and Fedora Ruby. Case 2-1. does not install ri document by "gem install".
This is interesting. I remember to notice the shorter output, but I didn't pay enough attention to it. Will take a look at it.
Apparently I have met this issue already:
https://github.com/rubygems/rubygems/issues/1470
So as long as upstream ignores this issue, there are just two options:
- The documentation wont be installed by default.
- The handling of default gems will be broken.
Neither is ideal, but I prefer the first option a bit. If somebody needs the documentation, it can be generated explicitly (gem rdoc).
Vít _______________________________________________ ruby-sig mailing list -- ruby-sig@lists.fedoraproject.org To unsubscribe send an email to ruby-sig-leave@lists.fedoraproject.org
As it turns out, this has other issues:
https://bugzilla.redhat.com/show_bug.cgi?id=1574594
I am really desperate now :/
V.
Dne 19.12.2017 v 16:12 Vít Ondruch napsal(a):
Dne 14.12.2017 v 19:03 Vít Ondruch napsal(a):
Dne 14.12.2017 v 18:41 Vít Ondruch napsal(a):
Dne 14.12.2017 v 18:23 Jun Aruga napsal(a):
OK thanks for the info.
Comparing the result of "gem list" command between upstream and our Fedora package, I found the difference. That can be confusing people.
Some of the gem are not shown in the result such as cmath for Fedora package ruby.
When running below command on mock, we can load cmath that is not in "gem list" on mock, maybe those are only shown as a result of "gem list".
irb(main):003:0> require 'cmath' => trueIs it possible to add those gems in the result as a compatibility for upstream Ruby? Hidden gems such as cmath are confusing users.
Interesting. That is definitely unintentional. Will take a look into it.
This appears to be related to the default location of where the gems are installed. Upstream Ruby installs the gems into their directory, we install the gems into home directory. And therefore RubyGems on Fedora are trying to load the specifications for the default gems from the home directory "/builddir/.gem/ruby/specifications/default" (testing in mock). So far, we never had the default gem specifications, so this was not issue.
Here is updated build, which should fix the issues:
https://koji.fedoraproject.org/koji/taskinfo?taskID=23793602
The patch used to fix this in attachment. I'd love some feedback prior I push this into git. Mainly, I'd like you to test:
- If "gem install" as a regular user still works the same.
- If "gem install" as root still works the same.
- If the RPM packages in Fedora (probably just noarch) still installs
and runs just fine. 4) If rubygem- RPM packages build using this ruby are still build and installed correctly. 5) Any additional scenario you can think of ...
Thx for testing.
Vít
ruby-sig mailing list -- ruby-sig@lists.fedoraproject.org To unsubscribe send an email to ruby-sig-leave@lists.fedoraproject.org
I wish that the ticket you opened will fix this issue. (Just note for everyone in ML.) https://bugs.ruby-lang.org/issues/14737
Jun
On Fri, May 4, 2018 at 12:41 PM, Vít Ondruch vondruch@redhat.com wrote:
As it turns out, this has other issues:
https://bugzilla.redhat.com/show_bug.cgi?id=1574594
I am really desperate now :/
V.
Dne 19.12.2017 v 16:12 Vít Ondruch napsal(a):
Dne 14.12.2017 v 19:03 Vít Ondruch napsal(a):
Dne 14.12.2017 v 18:41 Vít Ondruch napsal(a):
Dne 14.12.2017 v 18:23 Jun Aruga napsal(a):
OK thanks for the info.
Comparing the result of "gem list" command between upstream and our Fedora package, I found the difference. That can be confusing people.
Some of the gem are not shown in the result such as cmath for Fedora package ruby.
When running below command on mock, we can load cmath that is not in "gem list" on mock, maybe those are only shown as a result of "gem list".
irb(main):003:0> require 'cmath' => trueIs it possible to add those gems in the result as a compatibility for upstream Ruby? Hidden gems such as cmath are confusing users.
Interesting. That is definitely unintentional. Will take a look into it.
This appears to be related to the default location of where the gems are installed. Upstream Ruby installs the gems into their directory, we install the gems into home directory. And therefore RubyGems on Fedora are trying to load the specifications for the default gems from the home directory "/builddir/.gem/ruby/specifications/default" (testing in mock). So far, we never had the default gem specifications, so this was not issue.
Here is updated build, which should fix the issues:
https://koji.fedoraproject.org/koji/taskinfo?taskID=23793602
The patch used to fix this in attachment. I'd love some feedback prior I push this into git. Mainly, I'd like you to test:
- If "gem install" as a regular user still works the same.
- If "gem install" as root still works the same.
- If the RPM packages in Fedora (probably just noarch) still installs
and runs just fine. 4) If rubygem- RPM packages build using this ruby are still build and installed correctly. 5) Any additional scenario you can think of ...
Thx for testing.
Vít
ruby-sig mailing list -- ruby-sig@lists.fedoraproject.org To unsubscribe send an email to ruby-sig-leave@lists.fedoraproject.org
ruby-sig mailing list -- ruby-sig@lists.fedoraproject.org To unsubscribe send an email to ruby-sig-leave@lists.fedoraproject.org
Hi everybody.
Ruby 2.5 was released during Christmas [1]. One notable change is that Bundler is not included in the package at the end [2] and I am glad for that decision, as long as the merge of Bundler and RubyGems is not done (or at least better, there is currently to much bundling going on).
So here is the build of stable Ruby 2.5.0:
https://koji.fedoraproject.org/koji/taskinfo?taskID=23973894
The sources are, as always, in the private-ruby-2.5 dist-git branch.
This is perhaps going to F28 unless some issues are discovered. I'll be asking for the side-tag, so the rebuild can begin (there is not much time prior mass rebuild).
The release was not reset to 1, since rubygem-net-telnet is still of the same version and rubygem-io-console version was not bumped (although there were some changes, but I am tired of reminding this every time :/ ).
Also, prior the official build, I'll have to temporary bump the rubygem-json release, since the independent rubygem-json has the same version but higher release already, that would be issue for the rebuild of any other rubygem- package.
Vít
[1] https://www.ruby-lang.org/en/news/2017/12/25/ruby-2-5-0-released/ [2] https://bugs.ruby-lang.org/issues/12733#change-68601
Hm, aarch64 build failed, but AFAIK, that is the same issue as:
https://bugs.ruby-lang.org/issues/13758
So chances are the build would pass second time ...
Vít
Dne 2.1.2018 v 17:33 Vít Ondruch napsal(a):
Hi everybody.
Ruby 2.5 was released during Christmas [1]. One notable change is that Bundler is not included in the package at the end [2] and I am glad for that decision, as long as the merge of Bundler and RubyGems is not done (or at least better, there is currently to much bundling going on).
So here is the build of stable Ruby 2.5.0:
https://koji.fedoraproject.org/koji/taskinfo?taskID=23973894
The sources are, as always, in the private-ruby-2.5 dist-git branch.
This is perhaps going to F28 unless some issues are discovered. I'll be asking for the side-tag, so the rebuild can begin (there is not much time prior mass rebuild).
The release was not reset to 1, since rubygem-net-telnet is still of the same version and rubygem-io-console version was not bumped (although there were some changes, but I am tired of reminding this every time :/ ).
Also, prior the official build, I'll have to temporary bump the rubygem-json release, since the independent rubygem-json has the same version but higher release already, that would be issue for the rebuild of any other rubygem- package.
Vít
[1] https://www.ruby-lang.org/en/news/2017/12/25/ruby-2-5-0-released/ [2] https://bugs.ruby-lang.org/issues/12733#change-68601 _______________________________________________ ruby-sig mailing list -- ruby-sig@lists.fedoraproject.org To unsubscribe send an email to ruby-sig-leave@lists.fedoraproject.org
I found the difference of the behavior between Upstream Ruby and Fedora Ruby. Case 2-1. does not install ri document by "gem install".
Apparently I have met this issue already:
For your information. The issue that ri document is not installed was fixed on the upstream. https://github.com/rubygems/rubygems/issues/1470 https://github.com/rubygems/rubygems/commit/7c14198
Do we patch this or wait next release of rubygems?
Jun
On Tue, Jan 2, 2018 at 5:54 PM, Vít Ondruch vondruch@redhat.com wrote:
Hm, aarch64 build failed, but AFAIK, that is the same issue as:
https://bugs.ruby-lang.org/issues/13758
So chances are the build would pass second time ...
Vít
Dne 2.1.2018 v 17:33 Vít Ondruch napsal(a):
Hi everybody.
Ruby 2.5 was released during Christmas [1]. One notable change is that Bundler is not included in the package at the end [2] and I am glad for that decision, as long as the merge of Bundler and RubyGems is not done (or at least better, there is currently to much bundling going on).
So here is the build of stable Ruby 2.5.0:
https://koji.fedoraproject.org/koji/taskinfo?taskID=23973894
The sources are, as always, in the private-ruby-2.5 dist-git branch.
This is perhaps going to F28 unless some issues are discovered. I'll be asking for the side-tag, so the rebuild can begin (there is not much time prior mass rebuild).
The release was not reset to 1, since rubygem-net-telnet is still of the same version and rubygem-io-console version was not bumped (although there were some changes, but I am tired of reminding this every time :/ ).
Also, prior the official build, I'll have to temporary bump the rubygem-json release, since the independent rubygem-json has the same version but higher release already, that would be issue for the rebuild of any other rubygem- package.
Vít
[1] https://www.ruby-lang.org/en/news/2017/12/25/ruby-2-5-0-released/ [2] https://bugs.ruby-lang.org/issues/12733#change-68601 _______________________________________________ ruby-sig mailing list -- ruby-sig@lists.fedoraproject.org To unsubscribe send an email to ruby-sig-leave@lists.fedoraproject.org
ruby-sig mailing list -- ruby-sig@lists.fedoraproject.org To unsubscribe send an email to ruby-sig-leave@lists.fedoraproject.org
ruby-sig@lists.fedoraproject.org
-
Aleksandar Kostadinov -
Jun Aruga -
Vít Ondruch