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... > > _______________________________________________ > ruby-sig mailing list -- ruby-sig(a)lists.fedoraproject.org > To unsubscribe send an email to ruby-sig-leave(a)lists.fedoraproject.org _______________________________________________ ruby-sig mailing list -- ruby-sig(a)lists.fedoraproject.org To unsubscribe send an email to ruby-sig-leave(a)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.fedoraprojec... 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(a)redhat.com&gt; 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... >>> >>> _______________________________________________ >>> ruby-sig mailing list -- ruby-sig(a)lists.fedoraproject.org >>> To unsubscribe send an email to ruby-sig-leave(a)lists.fedoraproject.org >> _______________________________________________ >> ruby-sig mailing list -- ruby-sig(a)lists.fedoraproject.org >> To unsubscribe send an email to ruby-sig-leave(a)lists.fedoraproject.org > > _______________________________________________ ruby-sig mailing list -- ruby-sig(a)lists.fedoraproject.org To unsubscribe send an email to ruby-sig-leave(a)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(a)redhat.com&gt; 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/ruby-sig@lists.fedoraprojec... > > > 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(a)redhat.com&gt; 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... >>>> >>>> _______________________________________________ >>>> ruby-sig mailing list -- ruby-sig(a)lists.fedoraproject.org >>>> To unsubscribe send an email to ruby-sig-leave(a)lists.fedoraproject.org >>> _______________________________________________ >>> ruby-sig mailing list -- ruby-sig(a)lists.fedoraproject.org >>> To unsubscribe send an email to ruby-sig-leave(a)lists.fedoraproject.org >> > _______________________________________________ > ruby-sig mailing list -- ruby-sig(a)lists.fedoraproject.org > To unsubscribe send an email to ruby-sig-leave(a)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.

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.

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 -- ruby-sig(a)lists.fedoraproject.org To unsubscribe send an email to ruby-sig-leave(a)lists.fedoraproject.org

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.

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

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?

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

4) If rubygem- RPM packages build using this ruby are still build and

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

4) If rubygem- RPM packages build using this ruby are still build and

I found the difference of the behavior between Upstream Ruby and Fedora Ruby. Case 2-1. does not install ri document by "gem install".

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(a)redhat.com&gt; wrote: > Vit thanks for the working. > > I tested it. > >> 1) 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) > ``` > >> 2) 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 > >> 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 > > 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(a)redhat.com&gt; 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: >> >> 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 >> >> _______________________________________________ >> ruby-sig mailing list -- ruby-sig(a)lists.fedoraproject.org >> To unsubscribe send an email to ruby-sig-leave(a)lists.fedoraproject.org >> > > > > -- > Jun Aruga jaruga(a)redhat.com > IRC: jaruga, Office: TPB(Technology Park Brno) Building C 1F, Brno, > Czech Republic -- Jun Aruga jaruga(a)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): >> 2) 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.

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 _______________________________________________ ruby-sig mailing list -- ruby-sig(a)lists.fedoraproject.org To unsubscribe send an email to ruby-sig-leave(a)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: https://github.com/rubygems/rubygems/issues/1470

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(a)lists.fedoraproject.org > To unsubscribe send an email to ruby-sig-leave(a)lists.fedoraproject.org _______________________________________________ ruby-sig mailing list -- ruby-sig(a)lists.fedoraproject.org To unsubscribe send an email to ruby-sig-leave(a)lists.fedoraproject.org