Ruby 2.5

[Vít Ondruch]

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...

[Vít Ondruch]

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

[Vít Ondruch]

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

[Vít Ondruch]

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

[1] https://bugs.ruby-lang.org/issues/13978

[Vít Ondruch]

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 -- [e-mail]
> To unsubscribe send an email to [e-mail]

[Jun Aruga]

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  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 -- [e-mail]
> > To unsubscribe send an email to [e-mail]
>
> ruby-sig mailing list -- [e-mail]
> To unsubscribe send an email to [e-mail]

[Vít Ondruch]

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/[e-mail].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  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 -- [e-mail]
> > > To unsubscribe send an email to [e-mail]
> >
> > ruby-sig mailing list -- [e-mail]
> > To unsubscribe send an email to [e-mail]

[Jun Aruga]

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  wrote:
> 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/[e-mail].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  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 -- [e-mail]
> > > > To unsubscribe send an email to [e-mail]
> > >
> > > ruby-sig mailing list -- [e-mail]
> > > To unsubscribe send an email to [e-mail]
>
> ruby-sig mailing list -- [e-mail]
> To unsubscribe send an email to [e-mail]

[Aleksandar Kostadinov]

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'
> => 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  wrote:
> > 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/[e-mail].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  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 -- [e-mail]
> > > > > To unsubscribe send an email to [e-mail]
> > > >
> > > > ruby-sig mailing list -- [e-mail]
> > > > To unsubscribe send an email to [e-mail]
> >
> > ruby-sig mailing list -- [e-mail]
> > To unsubscribe send an email to [e-mail]

[Vít Ondruch]

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'
> => 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.

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  wrote:
> > 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/[e-mail].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  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 -- [e-mail]
> > > > > To unsubscribe send an email to [e-mail]
> > > >
> > > > ruby-sig mailing list -- [e-mail]
> > > > To unsubscribe send an email to [e-mail]
> >
> > ruby-sig mailing list -- [e-mail]
> > To unsubscribe send an email to [e-mail]

[Vít Ondruch]

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'
> > => 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.
>
> 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.

[Jun Aruga]

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  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'
> > > => 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.
> >
> > 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 -- [e-mail]
> To unsubscribe send an email to [e-mail]

[Aleksandar Kostadinov]

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]

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
 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
>
> ...

[Vít Ondruch]

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

[Aleksandar Kostadinov]

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
>  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
> >
> > ...

[Vít Ondruch]

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'
> > > => 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.
> >
> > 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

[Jun Aruga]

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  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'
> > > > => 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.
> > >
> > > 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 -- [e-mail]
> To unsubscribe send an email to [e-mail]

[Jun Aruga]

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  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_64
>
> Jun
>
> On Tue, Dec 19, 2017 at 4:12 PM, Vít Ondruch  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'
> > > > > => 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.
> > > >
> > > > 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 -- [e-mail]
> > To unsubscribe send an email to [e-mail]
>
> --
> Jun Aruga [e-mail]
> IRC: jaruga, Office: TPB(Technology Park Brno) Building C 1F, Brno,
> Czech Republic

[Jun Aruga]

> 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  wrote:
> 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  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_64
> >
> > Jun
> >
> > On Tue, Dec 19, 2017 at 4:12 PM, Vít Ondruch  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'
> > > > > > => 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.
> > > > >
> > > > > 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 -- [e-mail]
> > > To unsubscribe send an email to [e-mail]
> >
> > --
> > Jun Aruga [e-mail]
> > IRC: jaruga, Office: TPB(Technology Park Brno) Building C 1F, Brno,
> > Czech Republic
>
> --
> Jun Aruga [e-mail]
> IRC: jaruga, Office: TPB(Technology Park Brno) Building C 1F, Brno,
> Czech Republic

[Vít Ondruch]

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

[Vít Ondruch]

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

[Jun Aruga]

> 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  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 -- [e-mail]
> To unsubscribe send an email to [e-mail]

[Vít Ondruch]

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

[Vít Ondruch]

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 -- [e-mail]
> To unsubscribe send an email to [e-mail]

[Jun Aruga]

> > > 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:
>
> https://github.com/rubygems/rubygems/issues/1470

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  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 -- [e-mail]
> > To unsubscribe send an email to [e-mail]
>
> ruby-sig mailing list -- [e-mail]
> To unsubscribe send an email to [e-mail]

[Vít Ondruch]

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'
> > > > => 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.
> > >
> > > 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 -- [e-mail]
> To unsubscribe send an email to [e-mail]

[Jun Aruga]

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  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'
> => 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.
>
> 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 -- [e-mail]
> To unsubscribe send an email to [e-mail]
>
> ruby-sig mailing list -- [e-mail]
> To unsubscribe send an email to [e-mail]