Re: Plan to update rubygem-json to 2.7.3

[Mamoru TASAKA]

Vít Ondruch wrote on 2024/04/19 18:05:

Thanks for the heads up. I assume you are going to land this just for Rawhide, 
right?


Yes, only for F-41, not for F-40 and below.

Mamoru


And we should also watch Ruby. So far, there is 2.7.2 in master and 2.7.1 in 
Ruby 3.3.


Checking Rails, there seems to be some patches around such as:

https://github.com/rails/rails/pull/51510


For Rspec-rails, these might be the changes:

https://github.com/rspec/rspec-rails/pull/2754

https://github.com/rspec/rspec-rails/pull/2755


Checking Haml / Pundit, they seems to be using OpenStruct just in their test 
suites.


Vít


Dne 19. 04. 24 v 10:31 Mamoru TASAKA napsal(a):

Hello, ruby-sig folks:

I am going to update rubygem-json to 2.7.3 *some day* (when I have enough time).

What is preventing me from doing it now is that due to json change that now
json makes OpenStruct support (dependency) optional, it causes the following
packages FTBFS:

rubygem-actionmailer
rubygem-actionpack
rubygem-actionview
rubygem-haml
rubygem-pundit
rubygem-rspec-rails

c.f.
https://github.com/flori/json/pull/565
https://github.com/flori/json/issues/579

json upstream now requests the each packge to add `require "ostruct"`, so
I am going to apply this change to the above packages (when I have enough time).

Regards,
Mamoru
--
___
ruby-sig mailing list -- ruby-sig@lists.fedoraproject.org
To unsubscribe send an email to ruby-sig-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/ruby-sig@lists.fedoraproject.org
Do not reply to spam, report it: 
https://pagure.io/fedora-infrastructure/new_issue


--
___
ruby-sig mailing list -- ruby-sig@lists.fedoraproject.org
To unsubscribe send an email to ruby-sig-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/ruby-sig@lists.fedoraproject.org
Do not reply to spam, report it: 
https://pagure.io/fedora-infrastructure/new_issue

--
___
ruby-sig mailing list -- ruby-sig@lists.fedoraproject.org
To unsubscribe send an email to ruby-sig-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/ruby-sig@lists.fedoraproject.org
Do not reply to spam, report it: 
https://pagure.io/fedora-infrastructure/new_issue

Plan to update rubygem-json to 2.7.3

[Mamoru TASAKA]

Hello, ruby-sig folks:

I am going to update rubygem-json to 2.7.3 *some day* (when I have enough time).

What is preventing me from doing it now is that due to json change that now
json makes OpenStruct support (dependency) optional, it causes the following
packages FTBFS:

rubygem-actionmailer
rubygem-actionpack
rubygem-actionview
rubygem-haml
rubygem-pundit
rubygem-rspec-rails

c.f.
https://github.com/flori/json/pull/565
https://github.com/flori/json/issues/579

json upstream now requests the each packge to add `require "ostruct"`, so
I am going to apply this change to the above packages (when I have enough time).

Regards,
Mamoru
--
___
ruby-sig mailing list -- ruby-sig@lists.fedoraproject.org
To unsubscribe send an email to ruby-sig-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/ruby-sig@lists.fedoraproject.org
Do not reply to spam, report it: 
https://pagure.io/fedora-infrastructure/new_issue

rspec 3.13.0 will hit rawhide

[Mamoru TASAKA]

Hello, ruby-sig folks:

Today I am going to update rspec series to 3.13.0 on F40.
I tried mass rebuild beforehand, and currently it seems this update
causes no additional build failures.

("No additional build failures" means that there are already some
  build failures on some packages, I've excluded the investigation
  on those packages.)

Regards,
Mamoru
--
___
ruby-sig mailing list -- ruby-sig@lists.fedoraproject.org
To unsubscribe send an email to ruby-sig-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/ruby-sig@lists.fedoraproject.org
Do not reply to spam, report it: 
https://pagure.io/fedora-infrastructure/new_issue

Minitest 5.22.2 will hit rawhide, with behavior change on empty test

[Mamoru TASAKA]

Hello, ruby-sig folks:

I am going to update rubygem-minitest to 5.22.2 on F40.

This version sees some behavior change, perhaps due to:
https://github.com/minitest/minitest/commit/ef839657fe46ecda4f46a6c0fdc670a361374080

Perviously, if there was no tests actually, Minitest showed the message
like:

```
0 runs, 0 assertions, 0 failures, 0 errors, 0 skips
```

With Minitest 5.22.2, the above message won't be shown.
(Messages like "Run options: --seed 28982" are shown, but the above "0 errors" 
messages
 won't appear)

So testsuite which expects this message will going to fail.

At least the following packages are affected by this change:
* rubygem-aruba
* rubygem-railties

Regards,
Mamoru
--
___
ruby-sig mailing list -- ruby-sig@lists.fedoraproject.org
To unsubscribe send an email to ruby-sig-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/ruby-sig@lists.fedoraproject.org
Do not reply to spam, report it: 
https://pagure.io/fedora-infrastructure/new_issue

Re: Ruby 3.3 - Mass rebuild

[Mamoru TASAKA]

Vít Ondruch wrote on 2024/01/04 22:51:


Dne 04. 01. 24 v 9:39 Vít Ondruch napsal(a):


Dne 03. 01. 24 v 19:43 Vít Ondruch napsal(a):


Dne 03. 01. 24 v 18:59 Vít Ondruch napsal(a):


Dne 03. 01. 24 v 18:55 Vít Ondruch napsal(a):


Dne 03. 01. 24 v 18:00 Vít Ondruch napsal(a):


Dne 03. 01. 24 v 17:18 Mamoru TASAKA napsal(a):

Mamoru TASAKA wrote on 2024/01/04 1:06:

Vít Ondruch wrote on 2024/01/03 19:20:

Hi everybody,

Ruby 3.3 is out and it is time for Ruby mass rebuild. First of all, I'd like to 
thank to Mamoru for the preparation and lot of fixes all around. I really 
appreciate that.

I think we are well prepared for the rebuild, therefore I have requested 
side-tag:

~~~

$ fedpkg request-side-tag
Side tag 'f40-build-side-80411' (id 80411) created.
Use 'fedpkg build --target=f40-build-side-80411' to use it.
Use 'koji wait-repo f40-build-side-80411' to wait for the build repo to be 
generated.

~~~

Ruby 3.3 is already merged [1] and build there:


https://koji.fedoraproject.org/koji/builds?inherited=0=80411=-build_id=1

or using:

~~~

$ koji list-tagged f40-build-side-80411

~~~

Now this is a list of packages, which very likely needs rebuild:

~~~
$ dnf repoquery --disablerepo=* --enablerepo=rawhide 
--enablerepo=rawhide-source --arch=src --whatrequires 'ruby-devel' | sort | uniq
~~~


You can take the package and just fire rebuild, but please ensure that you are 
using f40-build-side-80411 build target, i.e. the build command should look 
like:


~~~
$ fedpkg build --target f40-build-side-80411
~~~


Please be careful, because if you, by a chance, omit the f40-build-side-80411 
target, you'll be building against Ruby 3.2 which is not what you want.

If you won't do it by yourself, I'll be rebuilding all packages after I am 
finished with my packages. I'll be using fermig [2] to help me with that. If 
you don't want me to touch your packages for whatever reason, please let me 
know.

As always, any help/testing/feedback is welcome.


Vít


[1] https://github.com/fedora-ruby/fermig
[2] https://src.fedoraproject.org/rpms/ruby/pull-request/159




Thank you for preparing ruby3.3 for F-40.

Now I think the leftover (not rebuilt against ruby3.3) are the following:

  1 kf5-kross-interpreters-22.04.3-5.fc39.src.rpm
  3    openbabel-3.1.1-21.fc39.src.rpm

Umm... looks like redhat-rpm-config-273-1.fc40 change 
(-Wl,-z,pack-relative-relocs) is causing this:
for now reported against redhat-rpm-config:
https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=2256645

  2    libsbml-5.20.2-4.fc40.src.rpm
Now building (perhaps will succeed):
https://koji.fedoraproject.org/koji/taskinfo?taskID=111244836


libsbml build successfully finished.



  4    subversion-1.14.2-22.fc40.src.rpm
Build failing, perhaps due to zlib-ng-compat switch, already reported:
https://bugzilla.redhat.com/show_bug.cgi?id=2255746

After libsbml build finishes, I think we can merge ruby33 side tag into
F40 build tree.





Thx for the help with rebuilds. I am pondering about a few packages, e.g.:


libsolv needs rebuild it seems:

https://github.com/openSUSE/libsolv/issues/548

https://koji.fedoraproject.org/koji/taskinfo?taskID=111249415


And I think that VIM might fall into the same bucket.



Yep, VIM cannot load vim-command-t and if somebody using the Ruby bindings. But 
I don't think this is major issue and VIM is updated quite often. So not a show 
stopper.

Despite there has been some activity related to the kf5-kross-interpreters / 
openbabel, I'll rather wont wait and merge it now. Anybody can rebuild those 
later.


Vít





Done:

https://bodhi.fedoraproject.org/updates/FEDORA-2024-d093bd520d


Vít



CRITPATH update, probably due to DNF. Will look at that tomorrow.



So there actually were some gating failures. I have waved them and the update 
has finally landed. Should there be needed any further fixes, please apply them 
directly in Rawhide, as usually.

Mamoru than you for adding the kf5-kross-interpreters / openbabel in the mean 
time.





Just casually checking Koschei for "ruby" packages, it seems that all of them 
were already rebuilt and I am flattered I can't see any new issue. Very nice. Thx all for 
your great work and your support.


Vít



Good to hear. Thanks to Vít and all the folks for the nice work for landing new 
ruby into
Fedora 40.

Mamoru
--
___
ruby-sig mailing list -- ruby-sig@lists.fedoraproject.org
To unsubscribe send an email to ruby-sig-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/ruby-sig@lists.fedoraproject.org
Do not reply to spam, report it: 
https://pagure.io/fedora-infrastructure/new_issue

Re: Ruby 3.3 - Mass rebuild

[Mamoru TASAKA]

Mamoru TASAKA wrote on 2024/01/04 1:06:

Vít Ondruch wrote on 2024/01/03 19:20:

Hi everybody,

Ruby 3.3 is out and it is time for Ruby mass rebuild. First of all, I'd like to 
thank to Mamoru for the preparation and lot of fixes all around. I really 
appreciate that.

I think we are well prepared for the rebuild, therefore I have requested 
side-tag:

~~~

$ fedpkg request-side-tag
Side tag 'f40-build-side-80411' (id 80411) created.
Use 'fedpkg build --target=f40-build-side-80411' to use it.
Use 'koji wait-repo f40-build-side-80411' to wait for the build repo to be 
generated.

~~~

Ruby 3.3 is already merged [1] and build there:


https://koji.fedoraproject.org/koji/builds?inherited=0=80411=-build_id=1

or using:

~~~

$ koji list-tagged f40-build-side-80411

~~~

Now this is a list of packages, which very likely needs rebuild:

~~~
$ dnf repoquery --disablerepo=* --enablerepo=rawhide 
--enablerepo=rawhide-source --arch=src --whatrequires 'ruby-devel' | sort | uniq
~~~


You can take the package and just fire rebuild, but please ensure that you are 
using f40-build-side-80411 build target, i.e. the build command should look 
like:


~~~
$ fedpkg build --target f40-build-side-80411
~~~


Please be careful, because if you, by a chance, omit the f40-build-side-80411 
target, you'll be building against Ruby 3.2 which is not what you want.

If you won't do it by yourself, I'll be rebuilding all packages after I am 
finished with my packages. I'll be using fermig [2] to help me with that. If 
you don't want me to touch your packages for whatever reason, please let me 
know.

As always, any help/testing/feedback is welcome.


Vít


[1] https://github.com/fedora-ruby/fermig
[2] https://src.fedoraproject.org/rpms/ruby/pull-request/159




Thank you for preparing ruby3.3 for F-40.

Now I think the leftover (not rebuilt against ruby3.3) are the following:

  1    kf5-kross-interpreters-22.04.3-5.fc39.src.rpm
  3    openbabel-3.1.1-21.fc39.src.rpm

Umm... looks like redhat-rpm-config-273-1.fc40 change 
(-Wl,-z,pack-relative-relocs) is causing this:
for now reported against redhat-rpm-config:
https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=2256645

  2    libsbml-5.20.2-4.fc40.src.rpm
Now building (perhaps will succeed):
https://koji.fedoraproject.org/koji/taskinfo?taskID=111244836


libsbml build successfully finished.



  4    subversion-1.14.2-22.fc40.src.rpm
Build failing, perhaps due to zlib-ng-compat switch, already reported:
https://bugzilla.redhat.com/show_bug.cgi?id=2255746

After libsbml build finishes, I think we can merge ruby33 side tag into
F40 build tree.



Regards,
Mamoru

--
___
ruby-sig mailing list -- ruby-sig@lists.fedoraproject.org
To unsubscribe send an email to ruby-sig-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/ruby-sig@lists.fedoraproject.org
Do not reply to spam, report it: 
https://pagure.io/fedora-infrastructure/new_issue

Re: Ruby 3.3 - Mass rebuild

[Mamoru TASAKA]

Vít Ondruch wrote on 2024/01/03 19:20:

Hi everybody,

Ruby 3.3 is out and it is time for Ruby mass rebuild. First of all, I'd like to 
thank to Mamoru for the preparation and lot of fixes all around. I really 
appreciate that.

I think we are well prepared for the rebuild, therefore I have requested 
side-tag:

~~~

$ fedpkg request-side-tag
Side tag 'f40-build-side-80411' (id 80411) created.
Use 'fedpkg build --target=f40-build-side-80411' to use it.
Use 'koji wait-repo f40-build-side-80411' to wait for the build repo to be 
generated.

~~~

Ruby 3.3 is already merged [1] and build there:


https://koji.fedoraproject.org/koji/builds?inherited=0=80411=-build_id=1

or using:

~~~

$ koji list-tagged f40-build-side-80411

~~~

Now this is a list of packages, which very likely needs rebuild:

~~~
$ dnf repoquery --disablerepo=* --enablerepo=rawhide 
--enablerepo=rawhide-source --arch=src --whatrequires 'ruby-devel' | sort | uniq
~~~


You can take the package and just fire rebuild, but please ensure that you are 
using f40-build-side-80411 build target, i.e. the build command should look 
like:


~~~
$ fedpkg build --target f40-build-side-80411
~~~


Please be careful, because if you, by a chance, omit the f40-build-side-80411 
target, you'll be building against Ruby 3.2 which is not what you want.

If you won't do it by yourself, I'll be rebuilding all packages after I am 
finished with my packages. I'll be using fermig [2] to help me with that. If 
you don't want me to touch your packages for whatever reason, please let me 
know.

As always, any help/testing/feedback is welcome.


Vít


[1] https://github.com/fedora-ruby/fermig
[2] https://src.fedoraproject.org/rpms/ruby/pull-request/159




Thank you for preparing ruby3.3 for F-40.

Now I think the leftover (not rebuilt against ruby3.3) are the following:

 1  kf5-kross-interpreters-22.04.3-5.fc39.src.rpm
 3  openbabel-3.1.1-21.fc39.src.rpm

Umm... looks like redhat-rpm-config-273-1.fc40 change 
(-Wl,-z,pack-relative-relocs) is causing this:
for now reported against redhat-rpm-config:
https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=2256645

 2  libsbml-5.20.2-4.fc40.src.rpm
Now building (perhaps will succeed):
https://koji.fedoraproject.org/koji/taskinfo?taskID=111244836

 4  subversion-1.14.2-22.fc40.src.rpm
Build failing, perhaps due to zlib-ng-compat switch, already reported:
https://bugzilla.redhat.com/show_bug.cgi?id=2255746

After libsbml build finishes, I think we can merge ruby33 side tag into
F40 build tree.

Regards,
Mamoru
--
___
ruby-sig mailing list -- ruby-sig@lists.fedoraproject.org
To unsubscribe send an email to ruby-sig-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/ruby-sig@lists.fedoraproject.org
Do not reply to spam, report it: 
https://pagure.io/fedora-infrastructure/new_issue

Re: Ruby 3.3

[Mamoru TASAKA]

Vít Ondruch wrote on 2023/12/21 21:08:

Hi everybody,

I am back with yet another update, this time rev 8e6f63df47. The changes are in 
my PR, while the build is running here:

https://koji.fedoraproject.org/koji/taskinfo?taskID=110562000

I have not noticed any noteworthy from upstream POV, but downstream, I have 
extracted the bundled Racc into separate sub package, to prevent possible 
collisions with standalone rubygem-racc (as discussed elsewhere). I have also 
provided multiple `bundled` provides. I know the line between what is part of 
Ruby and what is independent project is blurry and even blurrier then it used 
to be. However, it is probably better to have more `bundled` provides than less.

As always, please give it a try and any feedback is welcome.

Thx




Unfortunately, alexandria testsuite began to segfault (sometimes, not always)...

Once I've reported:
https://bugs.ruby-lang.org/issues/20079
Looks like 
https://github.com/ruby/ruby/commit/11fa76b1b521072c200c78ea023960221ff426d6 is 
the culprit.
Letting the upstream reproduce the issue may be difficult...

Regards,
Mamoru
--
___
ruby-sig mailing list -- ruby-sig@lists.fedoraproject.org
To unsubscribe send an email to ruby-sig-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/ruby-sig@lists.fedoraproject.org
Do not reply to spam, report it: 
https://pagure.io/fedora-infrastructure/new_issue

Re: Conflicting racc

[Mamoru TASAKA]

Mamoru TASAKA wrote on 2023/12/21 9:04:

Vít Ondruch wrote on 2023/12/21 0:45:

I have just hit this issue:

~~~

Error: Transaction test error:
   file /usr/lib64/gems/ruby/racc-1.7.3/racc/cparse.so from install of 
ruby-bundled-gems-3.3.0~20231219git8e6f63df47-184.fc40.x86_64 conflicts with 
file from package rubygem-racc-1.7.3-200.fc40.x86_64
   file /usr/share/gems/specifications/racc-1.7.3.gemspec from install of 
ruby-bundled-gems-3.3.0~20231219git8e6f63df47-184.fc40.x86_64 conflicts with 
file from package rubygem-racc-1.7.3-200.fc40.x86_64

~~~


The problem here is that racc is now bundled gem, where previously it was 
default gem, therefore there is now this conflict. How are we going to solve 
this? There are several options:

1) Make rubygem-racc subpackage of Ruby. We used to do this [1], but with 
default gem, the situation was different.

2) Install default gems / our system gems into dedicated directory, where they 
won't conflict. I was already proposing it elsewhere to explore the `gem 
install --vendor` or I have proposed upstream to have dedicated directories for 
default / bundled gems. Is it the right time to do this?

3) Drop the independent rubygem-racc

Actually I am not sure how sever this situation is, because I have explicitly 
installed rubygem-racc prior the ruby-default-gems get chance to be installed. 
So maybe we still have some time to thing about it.

Thoughts?


Vít


[1] 
https://src.fedoraproject.org/rpms/ruby/c/baf046a6a4d17fa309c9d20fa3db949f6c24aacf




Because new version of racc (independent) gem may be released during ruby 3.3 
stage
(actually racc version 1.7.0 was released 2023/Jun) and when that happens,
racc bundled in ruby 3.3 won't be updated, to make it possible to update 
rubygem-racc
version, I don't think 3) is what we want (at least I don't want 3)) .

I think 1) is the "simplest" way in that this is the least likely way where some
misbehavior can happen.

2) can be the option, but I think we can defer to this for ruby 3.4.

Or...
4) Make ruby-default-gems have "Obsoletes: rubygem-racc < 1.7.4" ?
So this way, unless I am wrong:

* when rubygem-racc-1.7.3-200.fc40 is firstly installed, rubygem-default-gems
   should Obsolete this independent rubygem-racc because of this.
* when independent rubygem-racc version is updated, this Obsoletes no longer in 
effect,
   but as version differs between independent rubygem-racc and bundled one,
   so there should be no file conflict, perhaps?
* Then when racc version in ruby-default-gems is updated, we can again have
   "Obsoletes: rubygem-racc < 1.7.5" in ruby-default-gems.

  At least, for current situation, 4) (i.e. use Obsoletes instead of dropping)
  should work.

Anyway, thank you for pointing this out.



After second thought, maybe some bugfix backport can happen even in 
rubygem-racc 1.7.3 era,
so after all, I think 1) is the best for now.

Regards,
Mamoru

--
___
ruby-sig mailing list -- ruby-sig@lists.fedoraproject.org
To unsubscribe send an email to ruby-sig-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/ruby-sig@lists.fedoraproject.org
Do not reply to spam, report it: 
https://pagure.io/fedora-infrastructure/new_issue

Re: Conflicting racc

[Mamoru TASAKA]

Vít Ondruch wrote on 2023/12/21 0:45:

I have just hit this issue:

~~~

Error: Transaction test error:
   file /usr/lib64/gems/ruby/racc-1.7.3/racc/cparse.so from install of 
ruby-bundled-gems-3.3.0~20231219git8e6f63df47-184.fc40.x86_64 conflicts with 
file from package rubygem-racc-1.7.3-200.fc40.x86_64
   file /usr/share/gems/specifications/racc-1.7.3.gemspec from install of 
ruby-bundled-gems-3.3.0~20231219git8e6f63df47-184.fc40.x86_64 conflicts with 
file from package rubygem-racc-1.7.3-200.fc40.x86_64

~~~


The problem here is that racc is now bundled gem, where previously it was 
default gem, therefore there is now this conflict. How are we going to solve 
this? There are several options:

1) Make rubygem-racc subpackage of Ruby. We used to do this [1], but with 
default gem, the situation was different.

2) Install default gems / our system gems into dedicated directory, where they 
won't conflict. I was already proposing it elsewhere to explore the `gem 
install --vendor` or I have proposed upstream to have dedicated directories for 
default / bundled gems. Is it the right time to do this?

3) Drop the independent rubygem-racc

Actually I am not sure how sever this situation is, because I have explicitly 
installed rubygem-racc prior the ruby-default-gems get chance to be installed. 
So maybe we still have some time to thing about it.

Thoughts?


Vít


[1] 
https://src.fedoraproject.org/rpms/ruby/c/baf046a6a4d17fa309c9d20fa3db949f6c24aacf




Because new version of racc (independent) gem may be released during ruby 3.3 
stage
(actually racc version 1.7.0 was released 2023/Jun) and when that happens,
racc bundled in ruby 3.3 won't be updated, to make it possible to update 
rubygem-racc
version, I don't think 3) is what we want (at least I don't want 3)) .

I think 1) is the "simplest" way in that this is the least likely way where some
misbehavior can happen.

2) can be the option, but I think we can defer to this for ruby 3.4.

Or...
4) Make ruby-default-gems have "Obsoletes: rubygem-racc < 1.7.4" ?
So this way, unless I am wrong:

* when rubygem-racc-1.7.3-200.fc40 is firstly installed, rubygem-default-gems
  should Obsolete this independent rubygem-racc because of this.
* when independent rubygem-racc version is updated, this Obsoletes no longer in 
effect,
  but as version differs between independent rubygem-racc and bundled one,
  so there should be no file conflict, perhaps?
* Then when racc version in ruby-default-gems is updated, we can again have
  "Obsoletes: rubygem-racc < 1.7.5" in ruby-default-gems.

 At least, for current situation, 4) (i.e. use Obsoletes instead of dropping)
 should work.

Anyway, thank you for pointing this out.

Regards,
Mamoru
--
___
ruby-sig mailing list -- ruby-sig@lists.fedoraproject.org
To unsubscribe send an email to ruby-sig-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/ruby-sig@lists.fedoraproject.org
Do not reply to spam, report it: 
https://pagure.io/fedora-infrastructure/new_issue

Re: Current rubygem- packages rebuild failure against ruby 3.3

[Mamoru TASAKA]

Vít Ondruch wrote on 2023/12/20 18:56:


Dne 15. 12. 23 v 17:03 Vít Ondruch napsal(a):


Dne 15. 12. 23 v 11:10 Vít Ondruch napsal(a):


Dne 26. 11. 23 v 15:13 Mamoru TASAKA napsal(a):


7. rubygem-railties
https://copr.fedorainfracloud.org/coprs/mtasaka/rubygem-newruby-test-3-2/build/6695576/
Testsuite is failing, but due to some different reason:

```
Failure:
FullStackConsoleTest#test_sandbox [test/application/console_test.rb:133]:
"> " expected, but got:

Loading development environment in sandbox (Rails 7.0.8)
Any modifications you make will be rolled back on exit
â–½.
Expected # encoding: ASCII-8BIT
#    valid: true
"Loading development environment in sandbox (Rails 7.0.8)\r\nAny modifications you make will be 
rolled back on exit\r\n\e[1G\xE2\x96\xBD\e[6n" to include "> ".

rails test test/application/console_test.rb:139

F

Failure:
FullStackConsoleTest#test_environment_option_and_irb_option 
[test/application/console_test.rb:133]:
"> " expected, but got:

Loading test environment (Rails 7.0.8)
Switch to inspect mode.
â–½.
Expected # encoding: ASCII-8BIT
#    valid: true
"Loading test environment (Rails 7.0.8)\r\nSwitch to inspect 
mode.\r\n\e[1G\xE2\x96\xBD\e[6n" to include "> ".
```




Isn't this related to the Aruba + Reline issue?

https://bugs.ruby-lang.org/issues/20052

https://github.com/ruby/reline/issues/616


Vít



I have tried to reproduce this with the latest version of Ruby, I have execute 
the console_test.rb more then 100x and I have not hit the issue. Was it fixed 
somehow? Not sure.


Vít



Well, actually with rubygem-railties-7.0.8-2 , 
FullStackConsoleTest#test_sandbox [test/application/console_test.rb:133] is 
passing,
but with rubygem-railties-7.0.8-1, I still see the same error (with ruby git 
7c2d819862)


Failure:
FullStackConsoleTest#test_sandbox [test/application/console_test.rb:133]:
"> " expected, but got:

/usr/share/gems/gems/activesupport-7.0.8/lib/active_support/message_verifier.rb:4:
 warning: base64 was loaded from the standard library, but will no longer be 
part of the default gems since Ruby 3.4.0. Add base64 to your Gemfile or 
gemspec. Also contact author of activesupport-7.0.8 to add base64 into its 
gemspec.
/usr/share/gems/gems/activesupport-7.0.8/lib/active_support/core_ext/object/json.rb:5:
 warning: bigdecimal was loaded from the standard library, but will no longer 
be part of the default gems since Ruby 3.4.0. Add bigdecimal to your Gemfile or 
gemspec. Also contact author of activesupport-7.0.8 to add bigdecimal into its 
gemspec.
/usr/share/gems/gems/activesupport-7.0.8/lib/active_support/notifications/fanout.rb:3:
 warning: mutex_m was loaded from the standard library, but will no longer be 
part of the default gems since Ruby 3.4.0. Add mutex_m to your Gemfile or 
gemspec. Also contact author of activesupport-7.0.8 to add mutex_m into its 
gemspec.
Loading development environment in sandbox (Rails 7.0.8)
Any modifications you make will be rolled back on exit
▽.
Expected # encoding: ASCII-8BIT
#valid: true
"/usr/share/gems/gems/activesupport-7.0.8/lib/active_support/message_verifier.rb:4: warning: 
base64 was loaded from the standard library, but will no longer be part of the default gems since Ruby 
3.4.0. Add base64 to your Gemfile or gemspec. Also contact author of activesupport-7.0.8 to add base64 
into its 
gemspec.\r\n/usr/share/gems/gems/activesupport-7.0.8/lib/active_support/core_ext/object/json.rb:5: 
warning: bigdecimal was loaded from the standard library, but will no longer be part of the default 
gems since Ruby 3.4.0. Add bigdecimal to your Gemfile or gemspec. Also contact author of 
activesupport-7.0.8 to add bigdecimal into its 
gemspec.\r\n/usr/share/gems/gems/activesupport-7.0.8/lib/active_support/notifications/fanout.rb:3: 
warning: mutex_m was loaded from the standard library, but will no longer be part of the default gems 
since Ruby 3.4.0. Add mutex_m to your Gemfile or gemspec. Also contact author of activesupport-7.0.8 
to add mutex_m into its gemspec.\r\nLoading development environment in sandbox (Rails 7.0.8)\r\nAny 
modifications you make will be rolled back on exit\r\n\e[1G\xE2\x96\xBD\e[6n" to include 
"> ".


So comparing with 1 and 2, there is Patch4:
rubygem-railties-7.1.0-Run-Rails-console-test-against-IRB-with-Reline-instead-of.patch
This patch actually seems to have fixed the above issue.

(You are trying to reproduce the above issue with -2?)

Regards,
Mamoru

--
___
ruby-sig mailing list -- ruby-sig@lists.fedoraproject.org
To unsubscribe send an email to ruby-sig-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Ar

Re: Ruby 3.3

[Mamoru TASAKA]

Vít Ondruch wrote on 2023/12/14 23:10:

Dear Rubyists,

As it turns out, yesterday version was not a big success, as we learned the 
hard way (thx Mamoru). So here I am back with updated version, this time rev 
e3631277c3. The changes are in my PR and the build is here:

https://koji.fedoraproject.org/koji/taskinfo?taskID=110328934

As always, please give it a try and let me know.


Cheers,


Vít




Looks like this is again in good shape, thank you.

Regards,
Mamoru
--
___
ruby-sig mailing list -- ruby-sig@lists.fedoraproject.org
To unsubscribe send an email to ruby-sig-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/ruby-sig@lists.fedoraproject.org
Do not reply to spam, report it: 
https://pagure.io/fedora-infrastructure/new_issue

Re: Ruby 3.3

[Mamoru TASAKA]

Hello, again:

Vít Ondruch wrote on 2023/12/14 0:30:

Hi again,

I'm back with yet another update, this time rev a7ad9f3836. The build is 
running here:

https://koji.fedoraproject.org/koji/taskinfo?taskID=110284699

This time, there are several changes I'd like to mention.

* There is included patch fixing several of the network related spec failures, 
therefore we don't need to workaround them anymore.

* There are now several more gems bundled in RubyGems. Mamoru already knows. 
Apart of the issues he hit, this means the licensing information of RubyGems is 
not up2date anymore. I have opened several tickets around various default gems 
and RubyGems requesting license clarification. I have also update the license 
information in ruby.spec a bit.


Looks like this is now causing issue on several packages.
Now I am trying to rebuild again, but some packages now newly began to fail.

For example, rubygem-actionmailbox now began to fail (previously build was 
successful), like:

```
+ ruby -rbundler -Ilib:test -e 'Dir.glob "./test/**/*_test.rb", 
(:require)'
/usr/share/gems/gems/bundler-2.5.0.dev/lib/bundler/resolver.rb:116:in `rescue 
in solve_versions': Could not find compatible versions (Bundler::SolveFailure)

Because every version of actionmailer depends on net-imap >= 0
  and every version of net-imap depends on net-protocol >= 0,
  every version of actionmailer requires net-protocol >= 0.
So, because net-protocol >= 0 could not be found in locally installed gems
  and Gemfile depends on actionmailer >= 0,
  version solving has failed.
from 
/usr/share/gems/gems/bundler-2.5.0.dev/lib/bundler/resolver.rb:79:in 
`solve_versions'
from 
/usr/share/gems/gems/bundler-2.5.0.dev/lib/bundler/resolver.rb:32:in `start'
from 
/usr/share/gems/gems/bundler-2.5.0.dev/lib/bundler/definition.rb:595:in 
`start_resolution'
from 
/usr/share/gems/gems/bundler-2.5.0.dev/lib/bundler/definition.rb:311:in 
`resolve'
from 
/usr/share/gems/gems/bundler-2.5.0.dev/lib/bundler/definition.rb:548:in 
`materialize'
from 
/usr/share/gems/gems/bundler-2.5.0.dev/lib/bundler/definition.rb:203:in `specs'
from 
/usr/share/gems/gems/bundler-2.5.0.dev/lib/bundler/definition.rb:270:in 
`specs_for'
from 
/usr/share/gems/gems/bundler-2.5.0.dev/lib/bundler/runtime.rb:18:in `setup'
from /usr/share/gems/gems/bundler-2.5.0.dev/lib/bundler.rb:164:in 
`setup'
from /usr/share/gems/gems/bundler-2.5.0.dev/lib/bundler/setup.rb:23:in `block 
in '
from 
/usr/share/gems/gems/bundler-2.5.0.dev/lib/bundler/ui/shell.rb:159:in 
`with_level'
from 
/usr/share/gems/gems/bundler-2.5.0.dev/lib/bundler/ui/shell.rb:111:in `silence'
from /usr/share/gems/gems/bundler-2.5.0.dev/lib/bundler/setup.rb:23:in 
`'
from 
:127:in 
`require'
from 
:127:in 
`require'
from 
/builddir/build/BUILD/actionmailbox-7.0.8/usr/share/gems/gems/actionmailbox-7.0.8/test/dummy/config/boot.rb:4:in
 `'
from 
/builddir/build/BUILD/actionmailbox-7.0.8/usr/share/gems/gems/actionmailbox-7.0.8/test/dummy/config/application.rb:1:in
 `require_relative'
from 
/builddir/build/BUILD/actionmailbox-7.0.8/usr/share/gems/gems/actionmailbox-7.0.8/test/dummy/config/application.rb:1:in
 `'
from 
/builddir/build/BUILD/actionmailbox-7.0.8/usr/share/gems/gems/actionmailbox-7.0.8/test/dummy/config/environment.rb:2:in
 `require_relative'
from 
/builddir/build/BUILD/actionmailbox-7.0.8/usr/share/gems/gems/actionmailbox-7.0.8/test/dummy/config/environment.rb:2:in
 `'
from 
/builddir/build/BUILD/actionmailbox-7.0.8/usr/share/gems/gems/actionmailbox-7.0.8/test/test_helper.rb:6:in
 `require_relative'
from 
/builddir/build/BUILD/actionmailbox-7.0.8/usr/share/gems/gems/actionmailbox-7.0.8/test/test_helper.rb:6:in
 `'
from 
:127:in 
`require'
from 
:127:in 
`require'
from 
/builddir/build/BUILD/actionmailbox-7.0.8/usr/share/gems/gems/actionmailbox-7.0.8/test/controllers/ingresses/mailgun/inbound_emails_controller_test.rb:3:in
 `'
from 
:127:in 
`require'
from 
:127:in 
`require'
from :411:in `glob'
from -e:1:in `'
/usr/share/gems/gems/bundler-2.5.0.dev/lib/bundler/vendor/pub_grub/lib/pub_grub/version_solver.rb:237:in
 `resolve_conflict': Could not find compatible versions 
(Bundler::PubGrub::SolveFailure)
```
Link: 
https://copr.fedorainfracloud.org/coprs/mtasaka/rubygem-newruby-test-3-2/build/6752051/

Most likely this is due to recent net-http and net-protocol vendorization.
Looks like rails related rubygem- packages, and "vagrant-libvirt" package fail 
to build due to this
issue.
(vagrant-libvirt: 
https://copr.fedorainfracloud.org/coprs/mtasaka/rubydep-heavypkg-test-3-2/build/6751386/
 )




* Some of you probably noticed the "auto user install" feature of RubyGems [1]. There 
were several issues, which should have been fixed now. I thought that it could help us a bit, but I 
am not sure 

Re: Ruby 3.3

[Mamoru TASAKA]

Vít Ondruch wrote on 2023/12/11 21:26:

Hi everybody,

Ruby 3.3 RC1 is here:

https://www.ruby-lang.org/en/news/2023/12/11/ruby-3-3-0-rc1-released/

And therefore I have updated the PR with recent changes and the build is 
running here:

https://koji.fedoraproject.org/koji/taskinfo?taskID=110183096

I have not seen anything what would caught my attention. And I hope that there 
won't be any big changes since now, because upstream promises stable ABI with 
RC1:

https://bugs.ruby-lang.org/issues/19980#note-3

We will see. As always, any feedback is welcome.


Vít



Another Umm

Now
* Build OK   
https://github.com/ruby/ruby/commit/2350c7946275cd570cc1d7cd892abc16ac68a92c
* Build FAIL 
https://github.com/ruby/ruby/commit/75f4a687ed54e3b1863ba1767c666a0bea809c8a

Failing like:

```
+ make -C redhat-linux-build -s runruby 'TESTRUN_SCRIPT=-e "   module Bundler; 
module Persistent; module Net; module HTTP;   end; end; end; end;   require 
'\''bundler/vendor/net-http-persistent/lib/net/http/persistent'\'';   puts 
'\''%{bundler_net_http_persistent_version}: 4.0.2'\'';   puts 
%Q[Bundler::Persistent::Net::HTTP::Persistent::VERSION: 
#{Bundler::Persistent::Net::HTTP::Persistent::VERSION}];   exit 1 if 
Bundler::Persistent::Net::HTTP::Persistent::VERSION != '\''4.0.2'\''; "'
/builddir/build/BUILD/ruby-3.3.0-745ab3e4c7/lib/rubygems/timeout/lib/timeout.rb:25:in 
`': uninitialized constant Gem (NameError)
from 
/builddir/build/BUILD/ruby-3.3.0-745ab3e4c7/lib/rubygems/net-protocol/lib/net/protocol.rb:23:in
 `require_relative'
from 
/builddir/build/BUILD/ruby-3.3.0-745ab3e4c7/lib/rubygems/net-protocol/lib/net/protocol.rb:23:in
 `'
from 
/builddir/build/BUILD/ruby-3.3.0-745ab3e4c7/lib/rubygems/net-http/lib/net/http.rb:23:in
 `require_relative'
from 
/builddir/build/BUILD/ruby-3.3.0-745ab3e4c7/lib/rubygems/net-http/lib/net/http.rb:23:in
 `'
from 
/builddir/build/BUILD/ruby-3.3.0-745ab3e4c7/lib/rubygems/net/http.rb:3:in 
`require_relative'
from 
/builddir/build/BUILD/ruby-3.3.0-745ab3e4c7/lib/rubygems/net/http.rb:3:in `'
from 
/builddir/build/BUILD/ruby-3.3.0-745ab3e4c7/lib/bundler/vendored_net_http.rb:4:in
 `require'
from 
/builddir/build/BUILD/ruby-3.3.0-745ab3e4c7/lib/bundler/vendored_net_http.rb:4:in 
`'
from 
/builddir/build/BUILD/ruby-3.3.0-745ab3e4c7/lib/bundler/vendor/net-http-persistent/lib/net/http/persistent.rb:1:in
 `require_relative'
from 
/builddir/build/BUILD/ruby-3.3.0-745ab3e4c7/lib/bundler/vendor/net-http-persistent/lib/net/http/persistent.rb:1:in
 `'
from -e:1:in `require'
from -e:1:in `'
make: *** [uncommon.mk:1375: runruby] Error 1
error: Bad exit status from /var/tmp/rpm-tmp.Dh4Yrz (%check)
Bad exit status from /var/tmp/rpm-tmp.Dh4Yrz (%check)
```

Looking at:
https://github.com/ruby/ruby/compare/2350c79462...75f4a687ed54e3b1863ba1767c666a0bea809c8a
I suspect the above failure is related to:
https://github.com/ruby/ruby/commit/ce924ce1fb029f19fd34a43f2012a485f4f62b53

Vít, would you have a look at this? Thank you.

Regards,
Mamoru

--
___
ruby-sig mailing list -- ruby-sig@lists.fedoraproject.org
To unsubscribe send an email to ruby-sig-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/ruby-sig@lists.fedoraproject.org
Do not reply to spam, report it: 
https://pagure.io/fedora-infrastructure/new_issue

Re: Ruby 3.3

[Mamoru TASAKA]

Vít Ondruch wrote on 2023/12/11 21:26:

Hi everybody,

Ruby 3.3 RC1 is here:

https://www.ruby-lang.org/en/news/2023/12/11/ruby-3-3-0-rc1-released/

And therefore I have updated the PR with recent changes and the build is 
running here:

https://koji.fedoraproject.org/koji/taskinfo?taskID=110183096

I have not seen anything what would caught my attention. And I hope that there 
won't be any big changes since now, because upstream promises stable ABI with 
RC1:

https://bugs.ruby-lang.org/issues/19980#note-3

We will see. As always, any feedback is welcome.


Vít



Okay, thank you.

Now I've again tried rebuilding all rubygem-XXX packages with
https://github.com/ruby/ruby/commit/505715ddf17e004d184c0b71afb40a31e2e8c98e
(later than ruby-3.3RC1 commit) (with additional notes).
The results are again shown as below.

Now 10 packages are failing to build:

A. The following 6 packages are failing due to the same reasons as before:

1. rubygem-actionview
   
https://copr.fedorainfracloud.org/coprs/mtasaka/rubygem-newruby-test-3-2/build/6743492/
2. rubygem-aruba
   
https://copr.fedorainfracloud.org/coprs/mtasaka/rubygem-newruby-test-3-2/build/6743493/
3. rubygem-async_sinatra
   
https://copr.fedorainfracloud.org/coprs/mtasaka/rubygem-newruby-test-3-2/build/6743494/
4. rubygem-byebug
   
https://copr.fedorainfracloud.org/coprs/mtasaka/rubygem-newruby-test-3-2/build/6743496/
5. rubygem-childprocess
   
https://copr.fedorainfracloud.org/coprs/mtasaka/rubygem-newruby-test-3-2/build/6743497/
6. rubygem-ronn-ng
   
https://copr.fedorainfracloud.org/coprs/mtasaka/rubygem-newruby-test-3-2/build/6743511/

B. The following packages failed to build, build failure was occuring from 
before, but
   this time failed with the different reasons than before

7. rubygem-railties
   
https://copr.fedorainfracloud.org/coprs/mtasaka/rubygem-newruby-test-3-2/build/6743510/
   Test suite expects some output, but actual output shows some diffs than 
expected like:
```
F

Failure:
ApplicationTests::BinSetupTest#test_bin_setup_output 
[test/application/bin_setup_test.rb:51]:
--- expected
+++ actual
@@ -2,10 +2,22 @@
 The Gemfile's dependencies are satisfied
 
 == Preparing database ==

+/usr/share/gems/gems/activesupport-7.0.8/lib/active_support/message_verifier.rb:4:
 warning: base64 was loaded from the standard library, but will no longer be 
part of the default gems since Ruby 3.4.0. Add base64 to your Gemfile or 
gemspec. Also contact author of activesupport-7.0.8 to add base64 into its 
gemspec.
+/usr/share/gems/gems/activesupport-7.0.8/lib/active_support/core_ext/object/json.rb:5:
 warning: bigdecimal was loaded from the standard library, but will no longer 
be part of the default gems since Ruby 3.4.0. Add bigdecimal to your Gemfile or 
gemspec. Also contact author of activesupport-7.0.8 to add bigdecimal into its 
gemspec.
+/usr/share/gems/gems/activesupport-7.0.8/lib/active_support/notifications/fanout.rb:3:
 warning: mutex_m was loaded from the standard library, but will no longer be 
part of the default gems since Ruby 3.4.0. Add mutex_m to your Gemfile or 
gemspec. Also contact author of activesupport-7.0.8 to add mutex_m into its 
gemspec.
+/usr/share/gems/gems/mail-2.7.1/lib/mail.rb:9: warning: net/smtp was loaded 
from the standard library, but is not part of the default gems since Ruby 
3.1.0. Add net-smtp to your Gemfile or gemspec. Also contact author of 
mail-2.7.1 to add net-smtp into its gemspec.
 Created database 'app_development'
 Created database 'app_test'
```


C. New failures
8. rubygem-rails-deprecated_sanitizer
   
https://copr.fedorainfracloud.org/coprs/mtasaka/rubygem-newruby-test-3-2/build/6743508/
```
  1) Failure:
DeprecatedSanitizerTest#test_Action_View_sanitizer_vendor_returns_constant_from_HTML_module
 
[/builddir/build/BUILD/rails-deprecated_sanitizer-1.0.4/usr/share/gems/gems/rails-deprecated_sanitizer-1.0.4/test/deprecated_sanitizer_test.rb:15]:
Expected: HTML::LinkSanitizer
  Actual: Rails::HTML4::LinkSanitizer
```
   Most likely due to rubygem-rails-html-sanitizer update from 1.4.3 to 1.6.0, 
especially
   perhaps due to this commit:
   
https://github.com/rails/rails-html-sanitizer/commit/206942674e5fb16e90d777de6e3debc842fe9b6c
   Maybe just fixing rails-deprecated_sanitizer testsuite is fine, but I am not 
sure.

   Note that rawhide koschei build is also failing:
   
https://koschei.fedoraproject.org/package/rubygem-rails-deprecated_sanitizer?collection=f40

9. rubygem-rubygems-mirror
   
https://copr.fedorainfracloud.org/coprs/mtasaka/rubygem-newruby-test-3-2/build/6743512/
```
+ ruby -Ilib -e 'Dir.glob "./test/test_*.rb", (:require)'
:127:in 
`require': cannot load such file -- rubygems/indexer (LoadError)
from 
:127:in 
`require'
from 
/builddir/build/BUILD/rubygems-mirror-1.3.0/usr/share/gems/gems/rubygems-mirror-1.3.0/lib/rubygems/mirror/test_setup.rb:7:in
 `'
from 
:127:in 
`require'
from 
:127:in 
`require'
from 

Re: Ruby 3.3

[Mamoru TASAKA]

Vít Ondruch wrote on 2023/11/24 22:17:

Hi,

I am back with yet another update of Ruby 3.3, this time rev 24e0b185ab. The 
changes are in my PR and the scratch build is available here:

https://koji.fedoraproject.org/koji/taskinfo?taskID=109487230

This starting to be boring, because there is nothing what would caught my 
attention. So the only thing worth of mentioning is that there are included 
several RubyGems, which fixes multiple test failures of RubyGems test suite 
running on Fedora Ruby. And this also my give some change to my proposal:

https://bugs.ruby-lang.org/issues/19972

As always. Any feedback is welcome.


Vít




U

Looks like
* Test passing: 
https://github.com/ruby/ruby/commit/c8b60c8ac2c8bbd077150792b5b207e983ab3634
* Test failing: 
https://github.com/ruby/ruby/commit/071df40495e31f6d3fd14ae8686b01edf9a689e3

```
1)
An exception occurred during: before :each
UDPSocket#local_address using IPv4 using an implicit hostname the returned 
Addrinfo uses the correct IP address ERROR
Socket::ResolutionError: getaddrinfo: Name or service not known
/builddir/build/BUILD/ruby-3.3.0-071df40495/spec/ruby/library/socket/udpsocket/local_address_spec.rb:66:in
 `connect'
/builddir/build/BUILD/ruby-3.3.0-071df40495/spec/ruby/library/socket/udpsocket/local_address_spec.rb:66:in
 `block (4 levels) in '
/builddir/build/BUILD/ruby-3.3.0-071df40495/spec/ruby/library/socket/udpsocket/local_address_spec.rb:4:in
 `'

2)
An exception occurred during: before :each
UDPSocket#local_address using IPv6 using an implicit hostname the returned 
Addrinfo uses the correct IP address ERROR
Socket::ResolutionError: getaddrinfo: Name or service not known
/builddir/build/BUILD/ruby-3.3.0-071df40495/spec/ruby/library/socket/udpsocket/local_address_spec.rb:66:in
 `connect'
/builddir/build/BUILD/ruby-3.3.0-071df40495/spec/ruby/library/socket/udpsocket/local_address_spec.rb:66:in
 `block (4 levels) in '
/builddir/build/BUILD/ruby-3.3.0-071df40495/spec/ruby/library/socket/udpsocket/local_address_spec.rb:4:in
 `'

3)
An exception occurred during: before :each
UDPSocket#remote_address using IPv4 using an implicit hostname the returned 
Addrinfo uses the correct IP address ERROR
Socket::ResolutionError: getaddrinfo: Name or service not known
/builddir/build/BUILD/ruby-3.3.0-071df40495/spec/ruby/library/socket/udpsocket/remote_address_spec.rb:65:in
 `connect'
/builddir/build/BUILD/ruby-3.3.0-071df40495/spec/ruby/library/socket/udpsocket/remote_address_spec.rb:65:in
 `block (4 levels) in '
/builddir/build/BUILD/ruby-3.3.0-071df40495/spec/ruby/library/socket/udpsocket/remote_address_spec.rb:4:in
 `'

4)
An exception occurred during: before :each
UDPSocket#remote_address using IPv6 using an implicit hostname the returned 
Addrinfo uses the correct IP address ERROR
Socket::ResolutionError: getaddrinfo: Name or service not known
/builddir/build/BUILD/ruby-3.3.0-071df40495/spec/ruby/library/socket/udpsocket/remote_address_spec.rb:65:in
 `connect'
/builddir/build/BUILD/ruby-3.3.0-071df40495/spec/ruby/library/socket/udpsocket/remote_address_spec.rb:65:in
 `block (4 levels) in '
/builddir/build/BUILD/ruby-3.3.0-071df40495/spec/ruby/library/socket/udpsocket/remote_address_spec.rb:4:in
 `'

Finished in 65.764894 seconds

3728 files, 32871 examples, 191872 expectations, 0 failures, 4 errors, 0 tagged
```

I may try to bisect (I am going to bed for now), but maybe due to this commit?

Mamoru
https://github.com/ruby/ruby/commit/d2ba8ea54a4089959afdeecdd963e3c4ff391748
--
___
ruby-sig mailing list -- ruby-sig@lists.fedoraproject.org
To unsubscribe send an email to ruby-sig-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/ruby-sig@lists.fedoraproject.org
Do not reply to spam, report it: 
https://pagure.io/fedora-infrastructure/new_issue

Re: Current rubygem- packages rebuild failure against ruby 3.3

[Mamoru TASAKA]

Hello again, all:

Now with again I tried to rebuild all rubygem-foo pacakages on Fedora with
ruby 3.3.0dev:

The packages failing to build with:
https://github.com/ruby/ruby/commit/9cd086ba4b559153864ab924723a665a4ddfb5d8
are listed below. (Commented inline between my previous post.)

8 packages are still failing to build.


Mamoru TASAKA wrote on 2023/10/29 17:09:

Hello, all:

With wonderful work by Vít and friends, again I tried to rebuild all rubygem-foo
packages on Fedora against ruby 3.3.0dev.

For the below failure reports,
https://github.com/ruby/ruby/commit/83ecdd1dce18246de631eb3b5d8308145bb269f5
is used.

Among ~455 packages, now 16 packages see build failure. Please check what is 
going,
thank you.

Regards,
Mamoru


1. rubygem-actionview
https://copr.fedorainfracloud.org/coprs/mtasaka/rubygem-newruby-test-3-2/build/6695570/
Same as before.



1.
rubygem-actionview
https://copr.fedorainfracloud.org/coprs/mtasaka/rubygem-newruby-test-3-2/build/6576506/

```
Failure:
RipperTrackerTest#test_finds_dependencies_with_extra_spaces 
[test/template/dependency_tracker_test.rb:191]:
--- expected
+++ actual
@@ -1 +1 @@
-["spaces/header", "spaces/form", "messages/message", "events/event", 
"comments/comment"]
+["spaces/header", "spaces/form", "messages/message", "comments/comment"]
```

Discussed on: 
https://src.fedoraproject.org/rpms/rubygem-actionview/pull-request/4


rubygem-addressable is FIXED: as reported before, this is fixed with
https://github.com/ruby/ruby/pull/8813
https://bugs.ruby-lang.org/issues/19992



2.
rubygem-addressable
https://copr.fedorainfracloud.org/coprs/mtasaka/rubygem-newruby-test-3-2/build/6576510/
Test suite segfaults constantly...



2. rubygem-aruba
https://copr.fedorainfracloud.org/coprs/mtasaka/rubygem-newruby-test-3-2/build/6695571/
Same as before.


3.
rubygem-aruba
https://copr.fedorainfracloud.org/coprs/mtasaka/rubygem-newruby-test-3-2/build/6576568/
Cucumber testsuite fails. Some test failures are due to removed 
irb/ext/save-history,
some are due to pry behaving badly? on ruby3.3 (not knowing in details), others 
I don't know.
Already reported https://github.com/cucumber/aruba/issues/910 , no response.


3. rubygem-async_sinatra
https://copr.fedorainfracloud.org/coprs/mtasaka/rubygem-newruby-test-3-2/build/6695572/
Same as before.
 

4.
rubygem-async_sinatra
https://copr.fedorainfracloud.org/coprs/mtasaka/rubygem-newruby-test-3-2/build/6576572/
`test/test_async.rb:28:in `': uninitialized constant MiniTest (NameError)`
Fixing this will perhaps be easy, leaving this to maintainer for now.


rubygem-bootsnap is FIXED: https://github.com/Shopify/bootsnap/pull/460


5.
rubygem-bootsnap
https://copr.fedorainfracloud.org/coprs/mtasaka/rubygem-newruby-test-3-2/build/6576574/
```
   1) Failure:
Bootsnap::KernelRequireTest#test_uses_the_same_duck_type_as_require 
[/builddir/build/BUILD/bootsnap-1.15.0/usr/share/gems/gems/bootsnap-1.15.0/test/load_path_cache/core_ext/kernel_require_test.rb:26]:
Expected # to be success?.
```
I don't know what this means. With ruby 7b8d472100 (around 2023-10-06) test was 
successful,
but with ruby 55c5ebe0a0 (around 2023-10-14) test test fails, not sure what 
ruby change caused
this.


4. rubygem-byebug
https://copr.fedorainfracloud.org/coprs/mtasaka/rubygem-newruby-test-3-2/build/6695573/
Same as before.

Note that as I posted before, I've already orphaned rubygem-byebug.
It seems rubygem-pry-byebug only depends on rubygem-byebug.
 

6.
rubygem-byebug
https://copr.fedorainfracloud.org/coprs/mtasaka/rubygem-newruby-test-3-2/build/6576577/
As discussed before, I don't expect that rubygem-byebug comes to work with 
ruby3.3.
Probably I am going to orphan this.


5. rubygem-childprocess
https://copr.fedorainfracloud.org/coprs/mtasaka/rubygem-newruby-test-3-2/build/6695574/
Same as before.


7.
rubygem-childprocess
https://copr.fedorainfracloud.org/coprs/mtasaka/rubygem-newruby-test-3-2/build/6576582/
`Failure/Error: require 'rubygems/mock_gem_ui'`
This file is removed: 
https://github.com/ruby/ruby/commit/74772840430fc3fca3f5fb0ad585d9cc48f512fb
Need to address in childprocess side.


6. NEW: rubygem-liquid
https://copr.fedorainfracloud.org/coprs/mtasaka/rubygem-newruby-test-3-2/build/6695575/
```
  1) Failure:
StandardFiltersTest#test_sort_when_property_is_sometimes_missing_puts_nils_last 
[/builddir/build/BUILD/liquid-4.0.3/usr/share/gems/gems/liquid-4.0.3/test/integration/standard_filter_test.rb:220]:
--- expected
+++ actual
@@ -1 +1 @@
-[{"price"=>1, "handle"=>"gamma"}, {"price"=>2, "handle"=>"epsilon"}, {"price"=>4, "handle"=>"alpha"}, 
{"handle"=>"delta"}, {"handle"=>"beta"}]
+[{"price"=>1, "handle"=>"gamma"}, {"price"=>2, "handle"=>

Re: Current rubygem- packages rebuild failure against ruby 3.3

[Mamoru TASAKA]

Vít Ondruch wrote on 2023/10/30 19:37:

Nice, thx for the summary and a few remarks inline.

Dne 29. 10. 23 v 9:09 Mamoru TASAKA napsal(a):

2.
rubygem-addressable
https://copr.fedorainfracloud.org/coprs/mtasaka/rubygem-newruby-test-3-2/build/6576510/
Test suite segfaults constantly...



Isn't this some RegExp / GC thing seeint this part of backtrace:

~~~

/lib64/libruby.so.3.3(rb_st_foreach+0x85) [0x7f2fc3b24285]
/lib64/libruby.so.3.3(onig_names_free+0x27) [0x7f2fc3b10807]
/lib64/libruby.so.3.3(onig_free+0x1a) [0x7f2fc3b035fa]
/lib64/libruby.so.3.3(0x7f2fc3a24022) [0x7f2fc3a24022]
/lib64/libruby.so.3.3(0x7f2fc3c1e048) [0x7f2fc3c1e048]
/lib64/libruby.so.3.3(0x7f2fc3a21f23) [0x7f2fc3a21f23]
/lib64/libruby.so.3.3(0x7f2fc3a2a39b) [0x7f2fc3a2a39b]
/lib64/libruby.so.3.3(0x7f2fc3a2a7be) [0x7f2fc3a2a7be]
/lib64/libruby.so.3.3(rb_wb_protected_newobj_of+0x74) [0x7f2fc3a2b0a4]



Actually as you said this turned out to be GC issue on ruby regexp
and is fixed with:

https://github.com/ruby/ruby/pull/8813
https://bugs.ruby-lang.org/issues/19992

Now with f694bd158c rubygem-addressable test suite passes and builds
successfully.

Mamoru
___
ruby-sig mailing list -- ruby-sig@lists.fedoraproject.org
To unsubscribe send an email to ruby-sig-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/ruby-sig@lists.fedoraproject.org
Do not reply to spam, report it: 
https://pagure.io/fedora-infrastructure/new_issue

Re: Current rubygem- packages rebuild failure against ruby 3.3

[Mamoru TASAKA]

Mamoru TASAKA wrote on 2023/10/29 17:09:

Hello, all:

With wonderful work by Vít and friends, again I tried to rebuild all rubygem-foo
packages on Fedora against ruby 3.3.0dev.

For the below failure reports,
https://github.com/ruby/ruby/commit/83ecdd1dce18246de631eb3b5d8308145bb269f5
is used.

Among ~455 packages, now 16 packages see build failure. Please check what is 
going,
thank you.

Regards,
Mamoru





6.
rubygem-byebug
https://copr.fedorainfracloud.org/coprs/mtasaka/rubygem-newruby-test-3-2/build/6576577/
As discussed before, I don't expect that rubygem-byebug comes to work with 
ruby3.3.
Probably I am going to orphan this.

7.
rubygem-childprocess
https://copr.fedorainfracloud.org/coprs/mtasaka/rubygem-newruby-test-3-2/build/6576582/
`Failure/Error: require 'rubygems/mock_gem_ui'`
This file is removed: 
https://github.com/ruby/ruby/commit/74772840430fc3fca3f5fb0ad585d9cc48f512fb
Need to address in childprocess side.





10.
rubygem-power_assert
https://copr.fedorainfracloud.org/coprs/mtasaka/rubygem-newruby-test-3-2/build/6576589/
%check needs BR: rubygem-byebug , which doesn't build.
Discussed on: https://github.com/ruby/power_assert/issues/47 , I may try to 
remove
byebug dependency myself.



Looking closely, it turned out that rubygem-power_assert does not strictly need 
rubygem-byebug:
In both runtime and %check, power_assert tries to load byebug and if LoadError 
happens,
it is just rescued and procedure continues.

So I've now orphaned rubygem-byebug. Unless no one takes, it will be retired 
after 6 weeks or so.
The packages which depends on rubygem-byebug (for Requires or BuildRequires) 
seems
rubygem-pry-byebug only (maintainer CCed), which will become FTI and will be 
retired for Fedora 40
unless someone takes rubygem-byebug.

Regards,
Mamoru
___
ruby-sig mailing list -- ruby-sig@lists.fedoraproject.org
To unsubscribe send an email to ruby-sig-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/ruby-sig@lists.fedoraproject.org
Do not reply to spam, report it: 
https://pagure.io/fedora-infrastructure/new_issue

Re: Current rubygem- packages rebuild failure against ruby 3.3

[Mamoru TASAKA]

Vít Ondruch wrote on 2023/10/30 20:43:


Dne 29. 10. 23 v 9:09 Mamoru TASAKA napsal(a):

14.
rubygem-shoulda-matchers
https://copr.fedorainfracloud.org/coprs/mtasaka/rubygem-newruby-test-3-2/build/6576601/
Lots of:
```
An error occurred while loading 
./spec/unit/shoulda/matchers/action_controller/callback_matcher_spec.rb.
Failure/Error: require 'unit_spec_helper'

NoMethodError:
  undefined method `tr' for an instance of Pathname
```
Not sure what this means.




This could be workaround:


~~~

$ git diff
diff --git a/spec/support/unit/rails_application.rb 
b/spec/support/unit/rails_application.rb
index b55b12ce..3d5609a1 100644
--- a/spec/support/unit/rails_application.rb
+++ b/spec/support/unit/rails_application.rb
@@ -184,7 +184,7 @@ end
  end

  def load_environment
-  require environment_file_path
+  require environment_file_path.to_s
  end

  def run_migrations
~~~


IOW it seems like there used to be conversion from Pathname to String 
somewhere, but it is not anymore.


Vít




Thank you. After looking at your comment above, it seems that it is indended that 
"require" (in bundler)
supports Pathname, once it is modified so:

https://github.com/rubygems/rubygems/pull/6837

This says "**Restore** support for Pathname objects in the replaced require" , 
so it used to support
Pathname, but it got broken at some time, then modified again at this time.

But looks like this got broken again by this commit:
https://github.com/rubygems/rubygems/pull/7056

So may this this is wanted, but I am not sure.

```
diff --git a/lib/bundler/rubygems_integration.rb 
b/lib/bundler/rubygems_integration.rb
index f420934ceb..59d32e68f3 100644
--- a/lib/bundler/rubygems_integration.rb
+++ b/lib/bundler/rubygems_integration.rb
@@ -244,6 +244,7 @@ def replace_require(specs)
   [::Kernel.singleton_class, ::Kernel].each do |kernel_class|
 kernel_class.send(:alias_method, :no_warning_require, :require)
 kernel_class.send(:define_method, :require) do |name|
+  name = File.path(name)
   if message = ::Gem::BUNDLED_GEMS.warning?(name, specs: specs) # 
rubocop:disable Style/HashSyntax
 warn message, :uplevel => 1
   end
```

___
ruby-sig mailing list -- ruby-sig@lists.fedoraproject.org
To unsubscribe send an email to ruby-sig-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/ruby-sig@lists.fedoraproject.org
Do not reply to spam, report it: 
https://pagure.io/fedora-infrastructure/new_issue

Re: Ruby 3.3 change proposal

[Mamoru TASAKA]

Vít Ondruch wrote on 2023/11/01 19:17:

Hi Rubyists,

The release of Ruby 3.3 is coming close and to be ready for rebuild after 
Christmas, I have submitted the Ruby 3.3 change proposal [1]. It is already in 
`ChangeReadyForWrangler` state, since I don't expect any controversy (it is 
mostly copy paste of Ruby 3.2 change [2]). But anyway, please review and let me 
know if you have any concerns (or feel free to address them in the proposal).




Also, I wonder if somebody wants to join me as an owner? Mamoru? You have been 
very helpful with this effort.



Thanks for inviting me! I am happy to become changeset co-owner with you.
As before, I will do my best effort for Ruby 3.3 on Fedora.

Regards,
Mamoru



Vít


[1] https://fedoraproject.org/wiki/Changes/Ruby_3.3

[2] https://fedoraproject.org/wiki/Changes/Ruby_3.2



___
ruby-sig mailing list -- ruby-sig@lists.fedoraproject.org
To unsubscribe send an email to ruby-sig-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/ruby-sig@lists.fedoraproject.org
Do not reply to spam, report it: 
https://pagure.io/fedora-infrastructure/new_issue

Re: Ruby 3.3

[Mamoru TASAKA]

Pavel Valena wrote on 2023/11/01 3:42:

On Fri, Oct 27, 2023 at 12:36 PM Vít Ondruch  wrote:



Dne 26. 10. 23 v 18:26 Pavel Valena napsal(a):



On Wed, Oct 25, 2023 at 4:31 PM Vít Ondruch  wrote:



Dne 25. 10. 23 v 16:11 Mamoru TASAKA napsal(a):

Hi, Vít:

Vít Ondruch wrote on 2023/10/24 23:07:

Hi,

I am back again with updated version of Ruby, this time c44d65427e.
Please see the changes in the upstream PR and test the build
(currently in progress) here:

https://koji.fedoraproject.org/koji/taskinfo?taskID=108034430

Apart of fixes for the "user install gems" discussed in other parts
of this thread, there is fix for the "TestYJIT#test_bug_19316" test
failure (which is not important on itself, just a few of you were
involved, thx!). I have not noticed anything else outstanding.

As always, please give it a try and I am looking forward to your
feedback.




Hello,

this time I'm getting strange build errors in my COPR like:

```
  /builddir/build/BUILD/ruby-3.3.0-c44d65427e/redhat-linux-build/ruby:
error while loading shared libraries: libruby.so.3.3: cannot open shared
object file: No such file or directory
```
https://gist.github.com/pvalena/63a91bca8ddf40c275f1f218b9a265a9
https://copr.fedorainfracloud.org/coprs/build/6565734

Not sure if that's something on my side... It's not a random error though.
Strangely enough, I can't reproduce it locally (local build is fine), even
in the same buildroot.


Sorry, not sure what is going on and the links you have shared don't
provide enough context. The rawhide builds are either complete or they
failed with different issue then the Gist.



I believe the error is really there, but I might be mistaken to consider it
most important part of the log.
It's in between the
  --;
here f.e. in fedora-rawhide-x86_64:

~~~
  Invoking
`/builddir/build/BUILD/ruby-3.3.0-c44d65427e/redhat-linux-build/ruby
-rrubygems /builddir/build/BUILD/ruby-3.3.0-c44d65427e/bin/gem --backtrace
build lib/bundler/bundler.gemspec` failed with output:
   --
   /builddir/build/BUILD/ruby-3.3.0-c44d65427e/redhat-linux-build/ruby:
error while loading shared libraries: libruby.so.3.3: cannot open shared
object file: No such file or directory
   --
# ./spec/bundler/support/helpers.rb:202:in `sys_exec'
# ./spec/bundler/support/helpers.rb:165:in `gem_command'
# ./spec/bundler/support/helpers.rb:343:in `with_built_bundler'
# ./spec/bundler/support/helpers.rb:304:in `block (2 levels) in system_gems'
# ./spec/bundler/support/helpers.rb:300:in `each'
# ./spec/bundler/support/helpers.rb:300:in `block in system_gems'
# ./spec/bundler/support/helpers.rb:357:in `block in with_gem_path_as'
# ./spec/bundler/support/helpers.rb:371:in `without_env_side_effects'
# ./spec/bundler/support/helpers.rb:352:in `with_gem_path_as'
# ./spec/bundler/support/helpers.rb:298:in `system_gems'
# ./spec/bundler/spec_helper.rb:92:in `block (2 levels) in '
~~~

Yes, it's very strange - and it happens every time I try. But I'm fine with
it as long as no one else experiences the issue :).

Builds so far:
https://copr.fedorainfracloud.org/coprs/pvalena/ruby-testing/build/6565230/
https://copr.fedorainfracloud.org/coprs/pvalena/ruby-testing/build/6567675/
https://copr.fedorainfracloud.org/coprs/pvalena/ruby-testing/build/6565734/
https://copr.fedorainfracloud.org/coprs/pvalena/ruby-testing/build/6565235/
https://copr.fedorainfracloud.org/coprs/pvalena/ruby-testing/build/6582818/

It didn't happen with previous builds though



Looking at your copr setting, you have enabled "--with bundler_tests" on
x86_64 arch only:

```
Modified fedora-rawhide-x86_64:
Mock options: --with bundler_tests
```
and correspondingly build is failing on

+ make -C redhat-linux-build test-bundler-parallel

Mamoru
___
ruby-sig mailing list -- ruby-sig@lists.fedoraproject.org
To unsubscribe send an email to ruby-sig-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/ruby-sig@lists.fedoraproject.org
Do not reply to spam, report it: 
https://pagure.io/fedora-infrastructure/new_issue

Current rubygem- packages rebuild failure against ruby 3.3

[Mamoru TASAKA]

Hello, all:

With wonderful work by Vít and friends, again I tried to rebuild all rubygem-foo
packages on Fedora against ruby 3.3.0dev.

For the below failure reports,
https://github.com/ruby/ruby/commit/83ecdd1dce18246de631eb3b5d8308145bb269f5
is used.

Among ~455 packages, now 16 packages see build failure. Please check what is 
going,
thank you.

Regards,
Mamoru

1.
rubygem-actionview
https://copr.fedorainfracloud.org/coprs/mtasaka/rubygem-newruby-test-3-2/build/6576506/

```
Failure:
RipperTrackerTest#test_finds_dependencies_with_extra_spaces 
[test/template/dependency_tracker_test.rb:191]:
--- expected
+++ actual
@@ -1 +1 @@
-["spaces/header", "spaces/form", "messages/message", "events/event", 
"comments/comment"]
+["spaces/header", "spaces/form", "messages/message", "comments/comment"]
```

Discussed on: 
https://src.fedoraproject.org/rpms/rubygem-actionview/pull-request/4

2.
rubygem-addressable
https://copr.fedorainfracloud.org/coprs/mtasaka/rubygem-newruby-test-3-2/build/6576510/
Test suite segfaults constantly...

3.
rubygem-aruba
https://copr.fedorainfracloud.org/coprs/mtasaka/rubygem-newruby-test-3-2/build/6576568/
Cucumber testsuite fails. Some test failures are due to removed 
irb/ext/save-history,
some are due to pry behaving badly? on ruby3.3 (not knowing in details), others 
I don't know.
Already reported https://github.com/cucumber/aruba/issues/910 , no response.

4.
rubygem-async_sinatra
https://copr.fedorainfracloud.org/coprs/mtasaka/rubygem-newruby-test-3-2/build/6576572/
`test/test_async.rb:28:in `': uninitialized constant MiniTest (NameError)`
Fixing this will perhaps be easy, leaving this to maintainer for now.

5.
rubygem-bootsnap
https://copr.fedorainfracloud.org/coprs/mtasaka/rubygem-newruby-test-3-2/build/6576574/
```
  1) Failure:
Bootsnap::KernelRequireTest#test_uses_the_same_duck_type_as_require 
[/builddir/build/BUILD/bootsnap-1.15.0/usr/share/gems/gems/bootsnap-1.15.0/test/load_path_cache/core_ext/kernel_require_test.rb:26]:
Expected # to be success?.
```
I don't know what this means. With ruby 7b8d472100 (around 2023-10-06) test was 
successful,
but with ruby 55c5ebe0a0 (around 2023-10-14) test test fails, not sure what 
ruby change caused
this.

6.
rubygem-byebug
https://copr.fedorainfracloud.org/coprs/mtasaka/rubygem-newruby-test-3-2/build/6576577/
As discussed before, I don't expect that rubygem-byebug comes to work with 
ruby3.3.
Probably I am going to orphan this.

7.
rubygem-childprocess
https://copr.fedorainfracloud.org/coprs/mtasaka/rubygem-newruby-test-3-2/build/6576582/
`Failure/Error: require 'rubygems/mock_gem_ui'`
This file is removed: 
https://github.com/ruby/ruby/commit/74772840430fc3fca3f5fb0ad585d9cc48f512fb
Need to address in childprocess side.

8.
rubygem-clockwork
https://copr.fedorainfracloud.org/coprs/mtasaka/rubygem-newruby-test-3-2/build/6576583/
`:128:in 
`require': cannot load such file -- mocha/setup (LoadError)`
This mocha issue is already fixed in 
https://github.com/Rykian/clockwork/pull/64/ .
Looks like in addition Minitest issue needs fixing.

9.
rubygem-curb
https://copr.fedorainfracloud.org/coprs/mtasaka/rubygem-newruby-test-3-2/build/6576585/
```
Error: test_curlopt_stderr_with_file(TestCurbCurlEasy): Errno::ENOENT: No such 
file or directory @ rb_sysopen - 
/tmp/curb_test_curlopt_stderr20231028-3388-1r4xk0
/builddir/build/BUILD/curb-1.0.1/usr/share/gems/gems/curb-1.0.1/tests/tc_curl_easy.rb:30:in
 `read'
/builddir/build/BUILD/curb-1.0.1/usr/share/gems/gems/curb-1.0.1/tests/tc_curl_easy.rb:30:in
 `test_curlopt_stderr_with_file'
```
Well, successful on x86_64, failing on s390x. But even on s390x this was 
successful with
ruby 7b8d472100 (around 2023-10-06), seeing failure with ruby 55c5ebe0a0 
(around 20231014).

10.
rubygem-power_assert
https://copr.fedorainfracloud.org/coprs/mtasaka/rubygem-newruby-test-3-2/build/6576589/
%check needs BR: rubygem-byebug , which doesn't build.
Discussed on: https://github.com/ruby/power_assert/issues/47 , I may try to 
remove
byebug dependency myself.

11.
rubygem-puppet-lint
https://copr.fedorainfracloud.org/coprs/mtasaka/rubygem-newruby-test-3-2/build/6576591/
```
No matching package to install: 'rubygem(rspec-collection_matchers) >= 1.0'
```
The above package is already retired.

12.
rubygem-railties
https://copr.fedorainfracloud.org/coprs/mtasaka/rubygem-newruby-test-3-2/build/6576593/
```
Failure:
ApplicationTests::AssetsTest#test_precompile_shouldn't_use_the_digests_present_in_manifest.json
 [test/application/assets_test.rb:299]:
Expected 
"application-c56ef81d122dffa8b257b0546ba1b09bd2d8b97e4aef881de8db9f760b903af6.css" to not 
be equal to 
"application-c56ef81d122dffa8b257b0546ba1b09bd2d8b97e4aef881de8db9f760b903af6.css".
```
Not sure what this means.


13.
rubygem-ronn-ng
https://copr.fedorainfracloud.org/coprs/mtasaka/rubygem-newruby-test-3-2/build/6576596/
```
Failure: test_angle_bracket_syntax_HTML(RonnTest):
  --- 

Re: Ruby 3.3

[Mamoru TASAKA]

Hi, Vít:

Vít Ondruch wrote on 2023/10/24 23:07:

Hi,

I am back again with updated version of Ruby, this time c44d65427e. Please see 
the changes in the upstream PR and test the build (currently in progress) here:

https://koji.fedoraproject.org/koji/taskinfo?taskID=108034430

Apart of fixes for the "user install gems" discussed in other parts of this thread, there 
is fix for the "TestYJIT#test_bug_19316" test failure (which is not important on itself, 
just a few of you were involved, thx!). I have not noticed anything else outstanding.

As always, please give it a try and I am looking forward to your feedback.


Vít



This seems to be working, thank you.

BTW (although I am sure I saw ppc64le test failure in some previous commit)
at least as of a2badf3066 I no longer see 
ppc64le/TestCoverage#test_coverage_suspendable
test failure, not sure what commit cured this test.

Regards,
Mamoru
___
ruby-sig mailing list -- ruby-sig@lists.fedoraproject.org
To unsubscribe send an email to ruby-sig-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/ruby-sig@lists.fedoraproject.org
Do not reply to spam, report it: 
https://pagure.io/fedora-infrastructure/new_issue

Re: Ruby 3.3

[Mamoru TASAKA]

Vít Ondruch wrote on 2023/10/20 21:21:


Dne 20. 10. 23 v 14:13 Vít Ondruch napsal(a):


Dne 15. 10. 23 v 1:48 Mamoru TASAKA napsal(a):

Vít Ondruch wrote on 2023/10/13 0:20:

Hi,

I am back again with yet another update, this time to e029375a7d. The changes 
are in the PR:



Vít, would you take a look at this change?

https://github.com/rubygems/rubygems/pull/5327

In ruby.git , these are imported from 7aebe2a52bac2a925c475c511640ad13a7d20490 
to
9dcaa832592af0125ba6407a506b2b3953b2f81c , I guess.

Perhaps due to the above changes:

[A] now "gem build ../foo-version.spec" as we usually do in rubygem-foo.spec 
fails like:

-
+ gem build ../Ascii85-1.1.0.gemspec
Defaulting to user installation because default GEM_HOME (/usr/share/gems) is 
not writable.
Invalid gemspec in [../Ascii85-1.1.0.gemspec]: ../Ascii85-1.1.0.gemspec:1: 
unknown regexp options - har
...se default GEM_HOME (/usr/share/gems) is not writable.
... ^~
../Ascii85-1.1.0.gemspec:1: syntax error, unexpected local variable or method, 
expecting end-of-input
...t GEM_HOME (/usr/share/gems) is not writable.
... ^~
ERROR:  Error loading gemspec. Aborting.
error: Bad exit status from /var/tmp/rpm-tmp.Cvl7rH (%build)
-

So this affects (breaks) almost all of Fedora rubygem- packages.



https://github.com/rubygems/rubygems/issues/7082

Testing with e.g. rubygem-json, this would be the workaround I guess:

~~~

$ sed -i '/^Defaulting to user installation/d' json-2.6.3.gemspec

~~~


Vít





[B]
Also, even if I workaround this, %gem_install , i.e.
$ gem install -V --local --build-root . --force --document=ri,rdoc 
%{gem_name}-%{version}.gem
now installs files under $HOME/.local:

-
+ gem install -V --local --build-root . --force --document=ri,rdoc 
Ascii85-1.1.0.gem
Defaulting to user installation because default GEM_HOME (/usr/share/gems) is 
not writable.
WARNING:  You build with buildroot.
  Build root: /builddir/build/BUILD/Ascii85-1.1.0
  Bin dir: 
/builddir/build/BUILD/Ascii85-1.1.0/builddir/.local/share/gem/ruby/bin
  Gem home: /builddir/build/BUILD/Ascii85-1.1.0/builddir/.local/share/gem/ruby
  Plugins dir: 
/builddir/build/BUILD/Ascii85-1.1.0/builddir/.local/share/gem/ruby/plugins
/builddir/build/BUILD/Ascii85-1.1.0/builddir/.local/share/gem/ruby/gems/Ascii85-1.1.0/.travis.yml
/builddir/build/BUILD/Ascii85-1.1.0/builddir/.local/share/gem/ruby/gems/Ascii85-1.1.0/Ascii85.gemspec
/builddir/build/BUILD/Ascii85-1.1.0/builddir/.local/share/gem/ruby/gems/Ascii85-1.1.0/Gemfile
/builddir/build/BUILD/Ascii85-1.1.0/builddir/.local/share/gem/ruby/gems/Ascii85-1.1.0/History.txt
/builddir/build/BUILD/Ascii85-1.1.0/builddir/.local/share/gem/ruby/gems/Ascii85-1.1.0/LICENSE
/builddir/build/BUILD/Ascii85-1.1.0/builddir/.local/share/gem/ruby/gems/Ascii85-1.1.0/README.md
/builddir/build/BUILD/Ascii85-1.1.0/builddir/.local/share/gem/ruby/gems/Ascii85-1.1.0/Rakefile
/builddir/build/BUILD/Ascii85-1.1.0/builddir/.local/share/gem/ruby/gems/Ascii85-1.1.0/bin/ascii85
/builddir/build/BUILD/Ascii85-1.1.0/builddir/.local/share/gem/ruby/gems/Ascii85-1.1.0/lib/Ascii85/version.rb
/builddir/build/BUILD/Ascii85-1.1.0/builddir/.local/share/gem/ruby/gems/Ascii85-1.1.0/lib/ascii85.rb
/builddir/build/BUILD/Ascii85-1.1.0/builddir/.local/share/gem/ruby/gems/Ascii85-1.1.0/spec/lib/ascii85_spec.rb
/builddir/build/BUILD/Ascii85-1.1.0/builddir/.local/share/gem/ruby/bin/ascii85
-



For the beginning, I have reported this here:

https://github.com/rubygems/rubygems/issues/7083


Vít




Thank you for reporting these to the upstream. I will keep track of
these bugs.

Mamoru
___
ruby-sig mailing list -- ruby-sig@lists.fedoraproject.org
To unsubscribe send an email to ruby-sig-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/ruby-sig@lists.fedoraproject.org
Do not reply to spam, report it: 
https://pagure.io/fedora-infrastructure/new_issue

Re: Ruby 3.3

[Mamoru TASAKA]

Vít Ondruch wrote on 2023/10/13 0:20:

Hi,

I am back again with yet another update, this time to e029375a7d. The changes 
are in the PR:



Vít, would you take a look at this change?

https://github.com/rubygems/rubygems/pull/5327

In ruby.git , these are imported from 7aebe2a52bac2a925c475c511640ad13a7d20490 
to
9dcaa832592af0125ba6407a506b2b3953b2f81c , I guess.

Perhaps due to the above changes:

[A] now "gem build ../foo-version.spec" as we usually do in rubygem-foo.spec 
fails like:

-
+ gem build ../Ascii85-1.1.0.gemspec
Defaulting to user installation because default GEM_HOME (/usr/share/gems) is 
not writable.
Invalid gemspec in [../Ascii85-1.1.0.gemspec]: ../Ascii85-1.1.0.gemspec:1: 
unknown regexp options - har
...se default GEM_HOME (/usr/share/gems) is not writable.
... ^~
../Ascii85-1.1.0.gemspec:1: syntax error, unexpected local variable or method, 
expecting end-of-input
...t GEM_HOME (/usr/share/gems) is not writable.
... ^~
ERROR:  Error loading gemspec. Aborting.
error: Bad exit status from /var/tmp/rpm-tmp.Cvl7rH (%build)
-

So this affects (breaks) almost all of Fedora rubygem- packages.

[B]
Also, even if I workaround this, %gem_install , i.e.
$ gem install -V --local --build-root . --force --document=ri,rdoc 
%{gem_name}-%{version}.gem
now installs files under $HOME/.local:

-
+ gem install -V --local --build-root . --force --document=ri,rdoc 
Ascii85-1.1.0.gem
Defaulting to user installation because default GEM_HOME (/usr/share/gems) is 
not writable.
WARNING:  You build with buildroot.
  Build root: /builddir/build/BUILD/Ascii85-1.1.0
  Bin dir: 
/builddir/build/BUILD/Ascii85-1.1.0/builddir/.local/share/gem/ruby/bin
  Gem home: /builddir/build/BUILD/Ascii85-1.1.0/builddir/.local/share/gem/ruby
  Plugins dir: 
/builddir/build/BUILD/Ascii85-1.1.0/builddir/.local/share/gem/ruby/plugins
/builddir/build/BUILD/Ascii85-1.1.0/builddir/.local/share/gem/ruby/gems/Ascii85-1.1.0/.travis.yml
/builddir/build/BUILD/Ascii85-1.1.0/builddir/.local/share/gem/ruby/gems/Ascii85-1.1.0/Ascii85.gemspec
/builddir/build/BUILD/Ascii85-1.1.0/builddir/.local/share/gem/ruby/gems/Ascii85-1.1.0/Gemfile
/builddir/build/BUILD/Ascii85-1.1.0/builddir/.local/share/gem/ruby/gems/Ascii85-1.1.0/History.txt
/builddir/build/BUILD/Ascii85-1.1.0/builddir/.local/share/gem/ruby/gems/Ascii85-1.1.0/LICENSE
/builddir/build/BUILD/Ascii85-1.1.0/builddir/.local/share/gem/ruby/gems/Ascii85-1.1.0/README.md
/builddir/build/BUILD/Ascii85-1.1.0/builddir/.local/share/gem/ruby/gems/Ascii85-1.1.0/Rakefile
/builddir/build/BUILD/Ascii85-1.1.0/builddir/.local/share/gem/ruby/gems/Ascii85-1.1.0/bin/ascii85
/builddir/build/BUILD/Ascii85-1.1.0/builddir/.local/share/gem/ruby/gems/Ascii85-1.1.0/lib/Ascii85/version.rb
/builddir/build/BUILD/Ascii85-1.1.0/builddir/.local/share/gem/ruby/gems/Ascii85-1.1.0/lib/ascii85.rb
/builddir/build/BUILD/Ascii85-1.1.0/builddir/.local/share/gem/ruby/gems/Ascii85-1.1.0/spec/lib/ascii85_spec.rb
/builddir/build/BUILD/Ascii85-1.1.0/builddir/.local/share/gem/ruby/bin/ascii85
-

So for now, I essentially reverted the above PR5327 changes on my local 
ruby.src (based on
your ruby.src) and it looks working as before, so again I am going to do trial 
rebuild for
all rubygem- packages.

(Well, when I saw these lots of git changelog related to rubygems part on 
ruby.git,
 I had a bad feeling about this.)

Regards,
Mamoru

 


https://src.fedoraproject.org/rpms/ruby/pull-request/159

And the scratch build is running here:

https://koji.fedoraproject.org/koji/taskinfo?taskID=107409961

 From upstream POV, there is nothing particularly interesting, except of the 
rename of the new Ruby source code parser from YART to prism and on strange JIT 
test failure.

 From changes in the .spec file, I have migrated every custom reference of gem 
path to the %gem_ macros. This was enabled by this commit:

https://src.fedoraproject.org/fork/vondruch/rpms/ruby/c/c514f5f13c709dc289754663ba31491617d83811

Please note that this commit also introduces `%gem_name_version` macro, which 
we could use in place of `%{gem_name}-%{version}`.

Next on my table is allow usage of generators on default/bundled gems. More 
details on this approach is here:

https://lists.fedoraproject.org/archives/list/de...@lists.fedoraproject.org/thread/3MHROKOM53HM6NF7RGGLFBIQFG5IEIQG/

and in practice, this will look like:


~~~

$ git diff
diff --git a/ruby.spec b/ruby.spec
index 1aea20b..51f3065 100644
--- a/ruby.spec
+++ b/ruby.spec
@@ -196,6 +196,11 @@ Source15: test_openssl_fips.rb
  %{load:%{SOURCE4}}
  %{load:%{SOURCE5}}

+%global __local_generator_requires make -C 
%{_builddir}/%{buildsubdir}/%{_vpath_builddir} -s runruby 
TESTRUN_SCRIPT="--enable-gems %{SOURCE9}"
+%global 

Re: F39 Change Proposal: Allow Removal of tzdata (System-Wide)

[Mamoru TASAKA]

Pavel Valena wrote on 2023/09/24 23:53:

I agree. I was just thinking of adding it to activesupport.

Regards,
Pavel


Okay, thank you! I see that this rubygem-activesupport change (to have
Requires: tzdata) cleared out the most of FTBFS I listed below.

Looking closely, it is found that

* rubygem-jekyll

itself tries to use tzinfo directly. I will going to add
"BuildRequires (not Requires): tzdata" to jekyll (as it seems it is
not always required).

Mamoru



On Sun, Sep 24, 2023 at 2:10 AM Neal Gompa  wrote:


On Sat, Sep 23, 2023 at 7:50 PM Mamoru TASAKA 
wrote:


Hello, ruby-sig folks:

  From devel list:

Zbigniew Jędrzejewski-Szmek wrote on 2023/09/22 23:01:

On Fri, Sep 22, 2023 at 10:43:05AM +0200, Vít Ondruch wrote:

https://bugzilla.redhat.com/show_bug.cgi?id=2233281#c3

This probably answers my question. So heads up to others.

Dne 22. 09. 23 v 10:39 Vít Ondruch napsal(a):

Was this implemented in past days? I am asking because this FTBFS
suggest so:



https://koschei.fedoraproject.org/package/rubygem-timecop?collection=f40


Yes. The change was done in rawhide a while ago, but it got pushed to

F39

only recently, see

https://bugzilla.redhat.com/show_bug.cgi?id=2233281#c3.


Zbyszek


Now again I tried rebuilding all rubygem- packages, and
now due to this tzdata removal changes, the following packages
are now additionally FTBFS:

rubygem-activemodel-serializers-xml
rubygem-globalid
rubygem-haml
rubygem-importmap-rails
rubygem-jekyll
rubygem-rails-controller-testing
rubygem-sassc-rails
rubygem-slim
rubygem-sprockets-rails
rubygem-timecop
rubygem-web-console

And all of these seems like:



/usr/share/gems/gems/tzinfo-2.0.6/lib/tzinfo/data_sources/zoneinfo_data_source.rb:252:in
`initialize': None of the paths included in
TZInfo::DataSources::ZoneinfoDataSource.search_path are valid zoneinfo
directories. (TZInfo::DataSources::ZoneinfoDirectoryNotFound)

 from

/usr/share/gems/gems/tzinfo-2.0.6/lib/tzinfo/data_source.rb:157:in `new'

 from

/usr/share/gems/gems/tzinfo-2.0.6/lib/tzinfo/data_source.rb:157:in
`create_default_data_source'

 from

/usr/share/gems/gems/tzinfo-2.0.6/lib/tzinfo/data_source.rb:55:in `block in
get'

 from

/usr/share/gems/gems/tzinfo-2.0.6/lib/tzinfo/data_source.rb:54:in
`synchronize'

 from

/usr/share/gems/gems/tzinfo-2.0.6/lib/tzinfo/data_source.rb:54:in `get'

 from

/usr/share/gems/gems/activesupport-7.0.8/lib/active_support/railtie.rb:88:in
`block in '

 from

/usr/share/gems/gems/railties-7.0.8/lib/rails/initializable.rb:32:in
`instance_exec'

 from

/usr/share/gems/gems/railties-7.0.8/lib/rails/initializable.rb:32:in `run'

 from

/usr/share/gems/gems/railties-7.0.8/lib/rails/initializable.rb:61:in `block
in run_initializers'

 from /usr/share/ruby/tsort.rb:231:in `block in tsort_each'
 from /usr/share/ruby/tsort.rb:353:in `block (2 levels) in

each_strongly_connected_component'

 from /usr/share/ruby/tsort.rb:434:in

`each_strongly_connected_component_from'

 from /usr/share/ruby/tsort.rb:352:in `block in

each_strongly_connected_component'

 from /usr/share/ruby/tsort.rb:350:in `each'
 from /usr/share/ruby/tsort.rb:350:in `call'
 from /usr/share/ruby/tsort.rb:350:in

`each_strongly_connected_component'

 from /usr/share/ruby/tsort.rb:229:in `tsort_each'
 from /usr/share/ruby/tsort.rb:208:in `tsort_each'
 from

/usr/share/gems/gems/railties-7.0.8/lib/rails/initializable.rb:60:in
`run_initializers'

 from

/usr/share/gems/gems/railties-7.0.8/lib/rails/application.rb:372:in
`initialize!'

.

So initializer of rails tries to initialize tzdata, and if it is not

found exception is raised:

The related code is:


https://github.com/rails/rails/blob/fc734f28e65ef8829a1a939ee6702c1f349a1d5a/activesupport/lib/active_support/railtie.rb#L87-L91


So what is the proper fix for this?

A. Make every package above have "BuildRequires: tzdata"
B. Make rubygem-tzinfo or rubygem-activesupport have "Requires (not

Recommends) tzdata"

C. Or ask rubygem-activesupport upstream to make the code work even if

tzdata is absent


My current thought is that as currently RoR code explicitly requests to

have tzdata installed,

B. is the best option.



I agree that Option B is the best option.



--
真実はいつも一つ！/ Always, there's only one truth!
___
ruby-sig mailing list -- ruby-sig@lists.fedoraproject.org
To unsubscribe send an email to ruby-sig-le...@lists.fedoraproject.org
Fedora Code of Conduct:
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives:
https://lists.fedoraproject.org/archives/list/ruby-sig@lists.fedoraproject.org
Do not reply to spam, report it:
https://pagure.io/fedora-infrastructure/new_issue




___

Re: F39 Change Proposal: Allow Removal of tzdata (System-Wide)

[Mamoru TASAKA]

Hello, ruby-sig folks:

From devel list:

Zbigniew Jędrzejewski-Szmek wrote on 2023/09/22 23:01:

On Fri, Sep 22, 2023 at 10:43:05AM +0200, Vít Ondruch wrote:

https://bugzilla.redhat.com/show_bug.cgi?id=2233281#c3

This probably answers my question. So heads up to others.

Dne 22. 09. 23 v 10:39 Vít Ondruch napsal(a):

Was this implemented in past days? I am asking because this FTBFS
suggest so:

https://koschei.fedoraproject.org/package/rubygem-timecop?collection=f40


Yes. The change was done in rawhide a while ago, but it got pushed to F39
only recently, see https://bugzilla.redhat.com/show_bug.cgi?id=2233281#c3.

Zbyszek


Now again I tried rebuilding all rubygem- packages, and
now due to this tzdata removal changes, the following packages
are now additionally FTBFS:

rubygem-activemodel-serializers-xml
rubygem-globalid
rubygem-haml
rubygem-importmap-rails
rubygem-jekyll
rubygem-rails-controller-testing
rubygem-sassc-rails
rubygem-slim
rubygem-sprockets-rails
rubygem-timecop
rubygem-web-console

And all of these seems like:

/usr/share/gems/gems/tzinfo-2.0.6/lib/tzinfo/data_sources/zoneinfo_data_source.rb:252:in
 `initialize': None of the paths included in 
TZInfo::DataSources::ZoneinfoDataSource.search_path are valid zoneinfo 
directories. (TZInfo::DataSources::ZoneinfoDirectoryNotFound)
from /usr/share/gems/gems/tzinfo-2.0.6/lib/tzinfo/data_source.rb:157:in 
`new'
from /usr/share/gems/gems/tzinfo-2.0.6/lib/tzinfo/data_source.rb:157:in 
`create_default_data_source'
from /usr/share/gems/gems/tzinfo-2.0.6/lib/tzinfo/data_source.rb:55:in 
`block in get'
from /usr/share/gems/gems/tzinfo-2.0.6/lib/tzinfo/data_source.rb:54:in 
`synchronize'
from /usr/share/gems/gems/tzinfo-2.0.6/lib/tzinfo/data_source.rb:54:in 
`get'
from 
/usr/share/gems/gems/activesupport-7.0.8/lib/active_support/railtie.rb:88:in `block 
in '
from 
/usr/share/gems/gems/railties-7.0.8/lib/rails/initializable.rb:32:in 
`instance_exec'
from 
/usr/share/gems/gems/railties-7.0.8/lib/rails/initializable.rb:32:in `run'
from 
/usr/share/gems/gems/railties-7.0.8/lib/rails/initializable.rb:61:in `block in 
run_initializers'
from /usr/share/ruby/tsort.rb:231:in `block in tsort_each'
from /usr/share/ruby/tsort.rb:353:in `block (2 levels) in 
each_strongly_connected_component'
from /usr/share/ruby/tsort.rb:434:in 
`each_strongly_connected_component_from'
from /usr/share/ruby/tsort.rb:352:in `block in 
each_strongly_connected_component'
from /usr/share/ruby/tsort.rb:350:in `each'
from /usr/share/ruby/tsort.rb:350:in `call'
from /usr/share/ruby/tsort.rb:350:in `each_strongly_connected_component'
from /usr/share/ruby/tsort.rb:229:in `tsort_each'
from /usr/share/ruby/tsort.rb:208:in `tsort_each'
from 
/usr/share/gems/gems/railties-7.0.8/lib/rails/initializable.rb:60:in 
`run_initializers'
from 
/usr/share/gems/gems/railties-7.0.8/lib/rails/application.rb:372:in 
`initialize!'
.

So initializer of rails tries to initialize tzdata, and if it is not found 
exception is raised:
The related code is:
https://github.com/rails/rails/blob/fc734f28e65ef8829a1a939ee6702c1f349a1d5a/activesupport/lib/active_support/railtie.rb#L87-L91

So what is the proper fix for this?

A. Make every package above have "BuildRequires: tzdata"
B. Make rubygem-tzinfo or rubygem-activesupport have "Requires (not Recommends) 
tzdata"
C. Or ask rubygem-activesupport upstream to make the code work even if tzdata 
is absent

My current thought is that as currently RoR code explicitly requests to have 
tzdata installed,
B. is the best option.

Regards,
Mamoru
___
ruby-sig mailing list -- ruby-sig@lists.fedoraproject.org
To unsubscribe send an email to ruby-sig-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/ruby-sig@lists.fedoraproject.org
Do not reply to spam, report it: 
https://pagure.io/fedora-infrastructure/new_issue

cookiejar status (was: Re: Ruby 3.3)

[Mamoru TASAKA]

Hello all, again:

Mamoru TASAKA wrote on 2023/09/17 22:42:


Okay, so with my initial builds for rubygem- packages, among 456 packages,
50 packages failed to build (1 just fixed one of them, so currently 49).

https://copr.fedorainfracloud.org/coprs/mtasaka/rubygem-newruby-test-3-2/packages/

Some types of errors (I noticed) which is affecting several packages are:


* Regexp.new now rejects 3rd argument:
   example:
   wrong number of arguments (given 3, expected 1..2)
   https://github.com/ruby/ruby/pull/7039



rubygem-cookiejar hits this issue:


Failure/Error: PARAM2 = Regexp.new 
"(#{PATTERN::TOKEN})(?:=(#{PATTERN::VALUE2}))?(?:\\Z|;)", '', 'n'

ArgumentError:
  wrong number of arguments (given 3, expected 1..2)


It looks like the following packages need rubygem-cookiejar when rebuilding,
and when rebuilding the same error when (in cookiejar internal):

* rubygem-em-http-request
* rubygem-em-websocket
* rubygem-faraday
* rubygem-webmock

Now rubygem-cookiejar upstream got archived:
https://github.com/dwaite/cookiejar

while there is the fork named "cookiejar2":
https://github.com/dorianmariefr/cookiejar2

It seems cookiejar upstream is very responsive, actually the PR I've submitted
about the above Regexp issue was merged very quickly:
https://github.com/dorianmariefr/cookiejar2/pull/2

Now I've applied the above PR to Fedora rubygem-cookiejar, but in the future
perhaps we should switch to use cookiejar2 instead of cookiejar.

( CCing pvalena )

Regards,
Mamoru
___
ruby-sig mailing list -- ruby-sig@lists.fedoraproject.org
To unsubscribe send an email to ruby-sig-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/ruby-sig@lists.fedoraproject.org
Do not reply to spam, report it: 
https://pagure.io/fedora-infrastructure/new_issue

Re: Ruby 3.3

[Mamoru TASAKA]

Follow up:

Mamoru TASAKA wrote on 2023/09/18 20:16:

Hello, again:

Vít Ondruch wrote on 2023/09/18 17:24:


Dne 17. 09. 23 v 15:42 Mamoru TASAKA napsal(a):

Some topics:
* rubygem-nifti sees test failure on s390x, this is perhaps big endian issue.



Interesting. nifti failed during mass rebuild, but later it was update by its 
maintainer. So it would probably deserve bug report and maybe some 
`ExcludeArch`?


Okay, I will check rubygem-nifti commit on Fedora dist-git (and perhaps I will
probably file bugzilla ticket for rubygem-nifti).


Reported: https://bugzilla.redhat.com/show_bug.cgi?id=2239481



(Well, rubygem-nifti is actually noarch, but I often wonder if we should always
  try to build packages for all arches even if the srpm itself is noarch:
  sometimes I see endian issue like this, for example.)





* rubygem-byebug fails to build (on test suite), however it seems this needs
  the undestanding of ruby internal change, and seems very difficult for me



Is there any future in byebug? Wasn't it obsoleted/replaced by the `debug` gem 
which is shipped with Ruby?


Thank you for info.
Well, it seems that actually my usage of byebug gem can be enough satisfied 
with debug gem.
So now I incline to orphan byebug rather than spending time to fix byebug test 
failure...

but what I've found is that power_assert testsuite depends on byebug:
https://github.com/ruby/power_assert/blob/297fa68908c45c4ca6c41e0940ebcc069744d580/power_assert.gemspec#L26

Before I orphan byebug, first I will try to contact with power_assert upstream.


(As Vít already noticed) reported: 
https://github.com/ruby/power_assert/issues/47

Mamoru

___
ruby-sig mailing list -- ruby-sig@lists.fedoraproject.org
To unsubscribe send an email to ruby-sig-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/ruby-sig@lists.fedoraproject.org
Do not reply to spam, report it: 
https://pagure.io/fedora-infrastructure/new_issue

Re: Ruby 3.3

[Mamoru TASAKA]

Hello, again:

Vít Ondruch wrote on 2023/09/18 17:24:


Dne 17. 09. 23 v 15:42 Mamoru TASAKA napsal(a):

Okay, so with my initial builds for rubygem- packages, among 456 packages,
50 packages failed to build (1 just fixed one of them, so currently 49).

https://copr.fedorainfracloud.org/coprs/mtasaka/rubygem-newruby-test-3-2/packages/

Some types of errors (I noticed) which is affecting several packages are:

* minitest 5.19 side change: MiniTest class support deprecated:
  example:
  test/test_async.rb:28:in `': uninitialized constant MiniTest (NameError)
https://github.com/minitest/minitest/commit/a2c6c18570f6f0a1bf6af70fe3b6d9599a13fdd6



While I am aware of this issue in rubygem-async_sinatra, I have let this 
package deliberately unfixed, because I don't think it is maintained. So either 
their maintainer will fix it or it will be later automatically removed from 
Fedora. I don't really intend to prolong life of such packages.




* ruby logger change.
  example:
  NoMethodError: undefined method `[]' for nil
  https://github.com/ruby/logger/pull/85
  -> affects like https://github.com/resque/resque/issues/1856

* Regexp.new now rejects 3rd argument:
  example:
  wrong number of arguments (given 3, expected 1..2)
  https://github.com/ruby/ruby/pull/7039

* mocha being updated from 1.15.0 to 2.1 - perhaps some adjustment is needed
  example:
  `require': cannot load such file -- mocha/setup (LoadError)



Assuming this is about rubygem-rack-cors, this is similar case to the 
rubygem-async_sinatra. I have submitted fix upstream:

https://github.com/cyu/rack-cors/pull/266

and put @valtri on CC. So he should be aware.




* Some packages expect that there are no warnings, but now with ruby3.3
  when trying to load default gems which are going to be gemified,
  warnings are generated like:

  $ ruby -e "require 'csv'"
-e:1: warning: csv which will be not part of the default gems since Ruby 3.4.0



I think that this was reported here:

https://bugs.ruby-lang.org/issues/19885


Thank you for info. This is actually what I want to track.






  https://github.com/ruby/ruby/pull/8126 , and the above warnings cause
  some tests fail.
  So this may mean that we have to package those default gems into separated
  rubygem-XXX srpm , at least before ruby 3.4 lands.

* And, currently some tests segfault.

* (Just note that there are some other reasons which cause test failure:
   I have not investigated them yet.)

Some topics:
* rubygem-nifti sees test failure on s390x, this is perhaps big endian issue.



Interesting. nifti failed during mass rebuild, but later it was update by its 
maintainer. So it would probably deserve bug report and maybe some 
`ExcludeArch`?


Okay, I will check rubygem-nifti commit on Fedora dist-git (and perhaps I will
probably file bugzilla ticket for rubygem-nifti).

(Well, rubygem-nifti is actually noarch, but I often wonder if we should always
 try to build packages for all arches even if the srpm itself is noarch:
 sometimes I see endian issue like this, for example.)





* rubygem-byebug fails to build (on test suite), however it seems this needs
  the undestanding of ruby internal change, and seems very difficult for me



Is there any future in byebug? Wasn't it obsoleted/replaced by the `debug` gem 
which is shipped with Ruby?


Thank you for info.
Well, it seems that actually my usage of byebug gem can be enough satisfied 
with debug gem.
So now I incline to orphan byebug rather than spending time to fix byebug test 
failure...

but what I've found is that power_assert testsuite depends on byebug:
https://github.com/ruby/power_assert/blob/297fa68908c45c4ca6c41e0940ebcc069744d580/power_assert.gemspec#L26

Before I orphan byebug, first I will try to contact with power_assert upstream.



I may post some detailed results (if I have time), however as I wrote above
the results can be shown on:
https://copr.fedorainfracloud.org/coprs/mtasaka/rubygem-newruby-test-3-2/packages/



Thank you for the initial tests. I'll look into your findings later in more 
detail. These were just quick notes mostly just from my memory :)



Vít



Mamoru

___
ruby-sig mailing list -- ruby-sig@lists.fedoraproject.org
To unsubscribe send an email to ruby-sig-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/ruby-sig@lists.fedoraproject.org
Do not reply to spam, report it: 
https://pagure.io/fedora-infrastructure/new_issue

Re: Ruby 3.3

[Mamoru TASAKA]

Mamoru TASAKA wrote on 2023/09/14 21:13:

Hello, Vít:

Thank you for initial work for ruby 3.3 .

Vít Ondruch wrote on 2023/09/12 17:08:

* `%gem_spec` macro with options:

https://src.fedoraproject.org/fork/vondruch/rpms/ruby/blob/77c580dfa85f921d969a8da68eaf6e88987aab8a/f/macros.rubygems#_10

This is my initial version, just to enable to use this macro in ruby.spec. I 
think I'll similarly modify all the related macros. While they'll be more 
complex, their use in ruby.spec will outweigh that. And I should add some 
documentation ...

BTW there are several possibilities in choosing how complex/flexible this macro 
will be and I think this is one of the changes which could be backported to 
Ruby 3.2. So feedback is appreciated. Looking at the macro, this bit 
`%{?1:%{expand:%{%{1}_version}}}%{!?1:%{version}}` is probably not very good 
idea for possible use in rubygem-*.gemspec.




I think this should be :

%gem_spec(d) 
%{gem_dir}/specifications%{?-d:/default}/%{?1}%{!?1:%{gem_name}}-%{?1:%{expand:%{%{1}_version}}}%{!?1:%{version}}%{?prerelease}.gemspec

(instead of %gem_spec(d) %{gem_dir}/specifications%{?-d:/default}/%{1}. )

Otherwise, for example trying to build rubygem-json fails like:
---
Processing files: rubygem-json-2.6.3-204.fc40.x86_64
error: File not found: 
/builddir/build/BUILDROOT/rubygem-json-2.6.3-204.fc40.101.x86_64/usr/share/gems/specifications/%{1}json-2.6.3.gemspec
     File not found: 
/builddir/build/BUILDROOT/rubygem-json-2.6.3-204.fc40.101.x86_64/usr/share/gems/specifications/%{1}json-2.6.3.gemspec
---

Now I am trying to rebuild gem related pkgs depending on libruby.3.2 (with 
using %{?1} for %gem_spec macro)



Okay, so with my initial builds for rubygem- packages, among 456 packages,
50 packages failed to build (1 just fixed one of them, so currently 49).

https://copr.fedorainfracloud.org/coprs/mtasaka/rubygem-newruby-test-3-2/packages/

Some types of errors (I noticed) which is affecting several packages are:

* minitest 5.19 side change: MiniTest class support deprecated:
  example:
  test/test_async.rb:28:in `': uninitialized constant MiniTest (NameError)
  
https://github.com/minitest/minitest/commit/a2c6c18570f6f0a1bf6af70fe3b6d9599a13fdd6

* ruby logger change.
  example:
  NoMethodError: undefined method `[]' for nil
  https://github.com/ruby/logger/pull/85
  -> affects like https://github.com/resque/resque/issues/1856

* Regexp.new now rejects 3rd argument:
  example:
  wrong number of arguments (given 3, expected 1..2)
  https://github.com/ruby/ruby/pull/7039

* mocha being updated from 1.15.0 to 2.1 - perhaps some adjustment is needed
  example:
  `require': cannot load such file -- mocha/setup (LoadError)

* Some packages expect that there are no warnings, but now with ruby3.3
  when trying to load default gems which are going to be gemified,
  warnings are generated like:

  $ ruby -e "require 'csv'"
-e:1: warning: csv which will be not part of the default gems since Ruby 3.4.0

  https://github.com/ruby/ruby/pull/8126 , and the above warnings cause
  some tests fail.
  So this may mean that we have to package those default gems into separated
  rubygem-XXX srpm , at least before ruby 3.4 lands.

* And, currently some tests segfault.

* (Just note that there are some other reasons which cause test failure:
   I have not investigated them yet.)

Some topics:
* rubygem-nifti sees test failure on s390x, this is perhaps big endian issue.
* rubygem-byebug fails to build (on test suite), however it seems this needs
  the undestanding of ruby internal change, and seems very difficult for me


I may post some detailed results (if I have time), however as I wrote above
the results can be shown on:
https://copr.fedorainfracloud.org/coprs/mtasaka/rubygem-newruby-test-3-2/packages/

Regards,
Mamoru

___
ruby-sig mailing list -- ruby-sig@lists.fedoraproject.org
To unsubscribe send an email to ruby-sig-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/ruby-sig@lists.fedoraproject.org
Do not reply to spam, report it: 
https://pagure.io/fedora-infrastructure/new_issue

Re: Ruby 3.3

[Mamoru TASAKA]

Hello, Vít:

Thank you for initial work for ruby 3.3 .

Vít Ondruch wrote on 2023/09/12 17:08:

* `%gem_spec` macro with options:

https://src.fedoraproject.org/fork/vondruch/rpms/ruby/blob/77c580dfa85f921d969a8da68eaf6e88987aab8a/f/macros.rubygems#_10

This is my initial version, just to enable to use this macro in ruby.spec. I 
think I'll similarly modify all the related macros. While they'll be more 
complex, their use in ruby.spec will outweigh that. And I should add some 
documentation ...

BTW there are several possibilities in choosing how complex/flexible this macro 
will be and I think this is one of the changes which could be backported to 
Ruby 3.2. So feedback is appreciated. Looking at the macro, this bit 
`%{?1:%{expand:%{%{1}_version}}}%{!?1:%{version}}` is probably not very good 
idea for possible use in rubygem-*.gemspec.




I think this should be :

%gem_spec(d) 
%{gem_dir}/specifications%{?-d:/default}/%{?1}%{!?1:%{gem_name}}-%{?1:%{expand:%{%{1}_version}}}%{!?1:%{version}}%{?prerelease}.gemspec

(instead of %gem_spec(d) %{gem_dir}/specifications%{?-d:/default}/%{1}. )

Otherwise, for example trying to build rubygem-json fails like:
---
Processing files: rubygem-json-2.6.3-204.fc40.x86_64
error: File not found: 
/builddir/build/BUILDROOT/rubygem-json-2.6.3-204.fc40.101.x86_64/usr/share/gems/specifications/%{1}json-2.6.3.gemspec
File not found: 
/builddir/build/BUILDROOT/rubygem-json-2.6.3-204.fc40.101.x86_64/usr/share/gems/specifications/%{1}json-2.6.3.gemspec
---

Now I am trying to rebuild gem related pkgs depending on libruby.3.2 (with 
using %{?1} for %gem_spec macro)

Regards,
Mamoru

___
ruby-sig mailing list -- ruby-sig@lists.fedoraproject.org
To unsubscribe send an email to ruby-sig-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/ruby-sig@lists.fedoraproject.org
Do not reply to spam, report it: 
https://pagure.io/fedora-infrastructure/new_issue

Re: Ruby 3.2 - Mass rebuild

[Mamoru TASAKA]

Vít Ondruch wrote on 2023/01/18 23:45:


Dne 17. 01. 23 v 15:48 Mamoru TASAKA napsal(a):

Vít Ondruch wrote on 2023/01/04 21:13:


Dne 04. 01. 23 v 8:55 Mamoru TASAKA napsal(a):

Vít Ondruch wrote on 2023/01/03 23:28:

Hi everybody,

Ruby 3.2 is out and it is time for Ruby mass rebuild. First of all, I'd like to 
thank to Mamoru for the preparation and lot of fixes all around. I really 
appreciate that. Due to this, I feel we are in better shape then we ever was 
and we can start with rebuld, therefore I have requested side-tag:



Note that as you are watching koschei so I guess you have already
noticed this, however currently ruby is reproducible FTBFS on ppc64le
due to the below:

  1) Failure:
TestSprintf#test_float_hex 
[/builddir/build/BUILD/ruby-3.2.0/test/ruby/test_sprintf.rb:299]:
<"-0x0p+0"> expected but was
<"-0x1p-1537">.



Yeah, I have noticed this. I hope it disappears the same way it appeared :D

On second thought, it might very well be that I have analyzed something similar 
earlier (probably quite some time ago) and it was related to specific CPU 
features. I'll try to remember what was the specific case.



Well, the above test failure on ppc64le is still reproducible with 
gcc-13.0.1-0.1.fc38.ppc64le.
The simple reproducer is

$ ruby --disable-gems -e 'puts sprintf("%a", -0.0)'
returns "-0x1p-1537", which must be "-0x0p+0".

As far as I am looking into this, what is sure that the following comparison:
https://github.com/ruby/ruby/blob/a528908271c678360d2d8ca232c178e7cdd340b4/missing/dtoa.c#L3411
is failing when d is actually -0.0: when d is -0.0, (d == 0.0) must pass.

What is difficult here is that:
* Extracting this hdtoa code only, compiling on ppc64le and executing unit test 
using
  hdtoa function does not reproduce this failure (i.e. (d == 0.0) passes).
* Looking at disassembled code of libruby.so.3.2 on ppc64le, due to LTO,
  - BSD_vfprintf 
https://github.com/ruby/ruby/blob/a528908271c678360d2d8ca232c178e7cdd340b4/vsnprintf.c#L529
  - cvt 
https://github.com/ruby/ruby/blob/a528908271c678360d2d8ca232c178e7cdd340b4/vsnprintf.c#L1229
  - and hdtoa
  are unified, hdtoa code is divided by input double value cases, and actually
  it looks like that the above  (d == 0.0) comparison is optimized away
* So disabling LTO actually makes the original test pass.

So I suspect gcc-13.0.1-0.1.fc38.ppc64le LTO on ppc64le is broken (althogh 
there may be some
possibility that ruby code contains some UB...), but as this is related to 3 
functions,
it may difficult to report to gcc developers

Mamoru

___
ruby-sig mailing list -- ruby-sig@lists.fedoraproject.org
To unsubscribe send an email to ruby-sig-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/ruby-sig@lists.fedoraproject.org
Do not reply to spam, report it: 
https://pagure.io/fedora-infrastructure/new_issue

Re: Ruby 3.2 - Mass rebuild

[Mamoru TASAKA]

Vít Ondruch wrote on 2023/01/04 21:13:


Dne 04. 01. 23 v 8:55 Mamoru TASAKA napsal(a):

Vít Ondruch wrote on 2023/01/03 23:28:

Hi everybody,

Ruby 3.2 is out and it is time for Ruby mass rebuild. First of all, I'd like to 
thank to Mamoru for the preparation and lot of fixes all around. I really 
appreciate that. Due to this, I feel we are in better shape then we ever was 
and we can start with rebuld, therefore I have requested side-tag:



Note that as you are watching koschei so I guess you have already
noticed this, however currently ruby is reproducible FTBFS on ppc64le
due to the below:

  1) Failure:
TestSprintf#test_float_hex 
[/builddir/build/BUILD/ruby-3.2.0/test/ruby/test_sprintf.rb:299]:
<"-0x0p+0"> expected but was
<"-0x1p-1537">.

Umm.

Another notice is that after rebuilding ruby with current f38 buildroot,
rspec-core test failure issue, i.e.
https://bugs.ruby-lang.org/issues/19254
is unreproducible with rebuilt ruby, so this is very like optimization 
specific...
(Anyway perhaps I am going to disable the rspec-core test under discussion)

Mamoru
___
ruby-sig mailing list -- ruby-sig@lists.fedoraproject.org
To unsubscribe send an email to ruby-sig-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/ruby-sig@lists.fedoraproject.org
Do not reply to spam, report it: 
https://pagure.io/fedora-infrastructure/new_issue

Re: Latest RSpec issues?

[Mamoru TASAKA]

Vít Ondruch wrote on 2023/01/17 23:31:

This seems to be never ending story 臘‍♂️

https://koschei.fedoraproject.org/package/rubygem-mail?collection=f38


Vít



Well, I've noticed this, so I tried to reproduce, but it seems unreproducible.

I suspected:

* This is due to rspec-expectations 3.12.1 -> 3.12.2
* Or aarch64 specific:

But neither of the above seems to be the reason: At least koji build is
successful and mockbuild on my local disc is also successful.

https://koji.fedoraproject.org/koji/taskinfo?taskID=96250590

Mamoru




Dne 07. 02. 22 v 12:24 Vít Ondruch napsal(a):

Dear Mamoru,

Could you please check the following two packages which recently started to 
fail?


https://koschei.fedoraproject.org/package/rubygem-webmock?collection=f36

https://koschei.fedoraproject.org/package/rubygem-websocket-extensions?collection=f36


I suspect that this is related to the RSpec update, but the errors are quite 
strange on the first look:


~~~

  1) WebMock::RequestSignature initialization assigns normalized headers
 Failure/Error: @headers = WebMock::Util::Headers.normalize_headers(headers)
   # received :normalize_headers with 
unexpected arguments
 expected: ({"A"=>"a"})
  got: ({"A"=>"a"})
 # ./lib/webmock/request_signature.rb:25:in `headers='
 # ./lib/webmock/request_signature.rb:49:in `assign_options'
 # ./lib/webmock/request_signature.rb:11:in `initialize'
 # ./spec/unit/request_signature_spec.rb:23:in `new'
 # ./spec/unit/request_signature_spec.rb:23:in `block (3 levels) in '
 # ./lib/webmock/rspec.rb:37:in `block (2 levels) in '

~~~


Thx a lot


Vít


P.S. Sorry for not being more helpful, I have to spent some time with CentOS 
Stream 9 to get Ruby into shape there, especially the problematic SystemTap 
support [1].


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




___
ruby-sig mailing list -- ruby-sig@lists.fedoraproject.org
To unsubscribe send an email to ruby-sig-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/ruby-sig@lists.fedoraproject.org
Do not reply to spam, report it: 
https://pagure.io/fedora-infrastructure/new_issue

___
ruby-sig mailing list -- ruby-sig@lists.fedoraproject.org
To unsubscribe send an email to ruby-sig-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/ruby-sig@lists.fedoraproject.org
Do not reply to spam, report it: 
https://pagure.io/fedora-infrastructure/new_issue

Re: Ruby 3.2 - Mass rebuild

[Mamoru TASAKA]

Vít Ondruch wrote on 2023/01/03 23:28:

Hi everybody,

Ruby 3.2 is out and it is time for Ruby mass rebuild. First of all, I'd like to 
thank to Mamoru for the preparation and lot of fixes all around. I really 
appreciate that. Due to this, I feel we are in better shape then we ever was 
and we can start with rebuld, therefore I have requested side-tag:


$ fedpkg request-side-tag
Side tag 'f38-build-side-61533' (id 61533) created.
Use 'fedpkg build --target=f38-build-side-61533' to use it.
Use 'koji wait-repo f38-build-side-61533' to wait for the build repo to be 
generated.


Ruby 3.2 is already merged [1] and build there:
https://koji.fedoraproject.org/koji/builds?inherited=0=61533=-build_id=1
or using:

$ koji list-tagged f38-build-side-61533


Now this is a list of packages, which very likely needs rebuild:
$ dnf repoquery --disablerepo=* --enablerepo=rawhide 
--enablerepo=rawhide-source --arch=src --whatrequires 'ruby-devel' | sort | uniq

You can take the package and just fire rebuild, but please ensure that you are 
using f38-build-side-61533 build target, i.e. the build command should look 
like:
$ fedpkg build --target f38-build-side-61533

Please be careful, because if you, by a chance, omit the f38-build-side-61533 
target, you'll be building against Ruby 3.1 which is not what you want.

If you won't do it by yourself, I'll be rebuilding all packages after I am 
finished with my packages. I'll be using fermig [1] to help me with that. If 
you don't want me to touch your packages for whatever reason, please let me 
know.

As always, any help/testing/feedback is welcome.

Vít 


[1] https://github.com/fedora-ruby/fermig
[1] https://src.fedoraproject.org/rpms/ruby/pull-request/145




All packages which had Requires dependency for "libruby.so.3.1()(64bit)" are 
now successfully rebuilt
(including pcs, adding workaround) - total 98 pkgs rebuilt.

Now I think we can merge f38-build-side-61533 into main f38 buildroot.

Yes, thanks to Vít, this time we had enough time for preparing for ruby3.2 
update, so we could proceed
this mass rebuild rather smoothly. Thank you to everyone, and good time for 
trying ruby3.2!

Regards,
Mamoru
___
ruby-sig mailing list -- ruby-sig@lists.fedoraproject.org
To unsubscribe send an email to ruby-sig-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/ruby-sig@lists.fedoraproject.org
Do not reply to spam, report it: 
https://pagure.io/fedora-infrastructure/new_issue

Re: Ruby 3.2

[Mamoru TASAKA]

Vít Ondruch wrote on 2022/12/23 22:30:


Dne 23. 12. 22 v 8:46 Mamoru TASAKA napsal(a):

Vít Ondruch wrote on 2022/12/22 17:48:

Hi,

I am back again with yet another update, this time to 6af6857ecf. The changes 
are in dist-git and the build is here:

https://koji.fedoraproject.org/koji/taskinfo?taskID=95591030

I am still surprised that this cycle, there are not big breakages. So there is 
nothing to report from my side, except that I am not convinced that the change 
to the tilde versions works as it is supposed to. I think that the 
`%{?development_release}` would need to be added not just to the Ruby version, 
but also to the subpackages and therefore to the Provides, etc. So if anybody 
tries update from the previous snapshot, please let me know your practical 
experience.


Vít



Well, looks like "my" copr build says that (some of) rubygem-foo pkgs building 
C extensions
began to FTBFS with 20221223git7d700a9f5d, while 20221220git8f081d4d0 they were 
okay.

For examples:

rubygem-glib2 
https://copr.fedorainfracloud.org/coprs/mtasaka/rubygem-newruby-test/package/rubygem-glib2/
rubygem-nokogiri 
https://copr.fedorainfracloud.org/coprs/mtasaka/rubygem-newruby-test/package/rubygem-nokogiri/
rubygem-rdiscount 
https://copr.fedorainfracloud.org/coprs/mtasaka/rubygem-newruby-test/package/rubygem-rdiscount/

Looking at the build logs, I strongly believe this is because of this change:

https://github.com/ruby/ruby/commit/0a9544ce4ab86963dde0f3ad0b489b6a354cc8b3
Subject: [PATCH] [rubygems/rubygems] Cleanup intermediate artifacts after
 installing built extensions

https://github.com/rubygems/rubygems/commit/98b6a959bd

So building C extensions, .so is removed from ext/ directory, so at %check, for 
example doing
$ ruby -Ilib:ext:. -e 'Dir.glob' cannot find required .so file and 
%check fails.

So what should Fedora side srpm do?
- Revert the above change on ruby (and also rubygems)
- Or make every rubygem-foo pkgs building C extension to use 
-I%{buildroot}%{gem_extdir_mri} instead of -Iext



The latter is the approach we use on various places (just random references):

https://src.fedoraproject.org/rpms/rubygem-bcrypt/blob/rawhide/f/rubygem-bcrypt.spec#_52

https://src.fedoraproject.org/rpms/rubygem-bindex/blob/rawhide/f/rubygem-bindex.spec#_57

https://src.fedoraproject.org/rpms/rubygem-json/blob/rawhide/f/rubygem-json.spec#_92

I don't think that `-Iext` was ever optimal, because that is never the place 
from where the extension is used. It would be even much better, if RubyGems 
used out of source build, somewhere in `/tmp` or so (there is still room for 
improvement :)).



Okay, I've fixed this side issue (i.e. use %{buildroot}%{gem_extdir_mri} 
instead of ext).

Regards,
Mamoru




Vít

P.S. it is getting closer to the release, time for subtle breaking changes :D



Regards,
Mamoru

___
ruby-sig mailing list -- ruby-sig@lists.fedoraproject.org
To unsubscribe send an email to ruby-sig-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/ruby-sig@lists.fedoraproject.org
Do not reply to spam, report it: 
https://pagure.io/fedora-infrastructure/new_issue

Re: Ruby 3.2

[Mamoru TASAKA]

Mamoru TASAKA wrote on 2022/12/23 16:46:

Vít Ondruch wrote on 2022/12/22 17:48:

Hi,

I am back again with yet another update, this time to 6af6857ecf. The changes 
are in dist-git and the build is here:

https://koji.fedoraproject.org/koji/taskinfo?taskID=95591030

I am still surprised that this cycle, there are not big breakages. So there is 
nothing to report from my side, except that I am not convinced that the change 
to the tilde versions works as it is supposed to. I think that the 
`%{?development_release}` would need to be added not just to the Ruby version, 
but also to the subpackages and therefore to the Provides, etc. So if anybody 
tries update from the previous snapshot, please let me know your practical 
experience.


Vít



Well, looks like "my" copr build says that (some of) rubygem-foo pkgs building 
C extensions
began to FTBFS with 20221223git7d700a9f5d, while 20221220git8f081d4d0 they were 
okay.

For examples:

rubygem-glib2 
https://copr.fedorainfracloud.org/coprs/mtasaka/rubygem-newruby-test/package/rubygem-glib2/
rubygem-nokogiri 
https://copr.fedorainfracloud.org/coprs/mtasaka/rubygem-newruby-test/package/rubygem-nokogiri/
rubygem-rdiscount 
https://copr.fedorainfracloud.org/coprs/mtasaka/rubygem-newruby-test/package/rubygem-rdiscount/

Looking at the build logs, I strongly believe this is because of this change:

https://github.com/ruby/ruby/commit/0a9544ce4ab86963dde0f3ad0b489b6a354cc8b3
Subject: [PATCH] [rubygems/rubygems] Cleanup intermediate artifacts after
  installing built extensions

https://github.com/rubygems/rubygems/commit/98b6a959bd

So building C extensions, .so is removed from ext/ directory, so at %check, for 
example doing
$ ruby -Ilib:ext:. -e 'Dir.glob' cannot find required .so file and 
%check fails.

So what should Fedora side srpm do?
- Revert the above change on ruby (and also rubygems)
- Or make every rubygem-foo pkgs building C extension to use 
-I%{buildroot}%{gem_extdir_mri} instead of -Iext



Also, (as Vít enabled yjit the above 20221223git7d700a9f5d also enabled yjit), 
then
rubygem-rspec-core got FTBFS with 20221223git7d700a9f5d, while with 
20221223git7d700a9f5d *without* yjit,
rubygem-rspec-core builds successfully.

With yjit, rubygem-rspec-core shows:

===
Failures:

  1) RSpec::Core::Example#run memory leaks, see GH-321, GH-1921 releases 
references to the examples / their ivars
 Failure/Error: expect(get_all.call).to eq opts.fetch(:post_gc)
 
   expected: []

got: ["after_all", "before_all"]
 
   (compared using ==)

 # ./spec/rspec/core/example_spec.rb:469:in `expect_gc'
 # ./spec/rspec/core/example_spec.rb:492:in `block (4 levels) in '
 # ./spec/support/sandboxing.rb:16:in `block (3 levels) in '
 # ./spec/support/sandboxing.rb:7:in `block (2 levels) in '

Finished in 12.79 seconds (files took 0.47826 seconds to load)
2209 examples, 1 failure, 4 pending

Failed examples:

rspec ./spec/rspec/core/example_spec.rb:472 # RSpec::Core::Example#run memory 
leaks, see GH-321, GH-1921 releases references to the examples / their ivars
===

So this may mean that yjit interacts badly with GC. Would someone investigate 
this?

Regards,
Mamoru

___
ruby-sig mailing list -- ruby-sig@lists.fedoraproject.org
To unsubscribe send an email to ruby-sig-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/ruby-sig@lists.fedoraproject.org
Do not reply to spam, report it: 
https://pagure.io/fedora-infrastructure/new_issue

Re: Ruby 3.2

[Mamoru TASAKA]

Vít Ondruch wrote on 2022/12/22 17:48:

Hi,

I am back again with yet another update, this time to 6af6857ecf. The changes 
are in dist-git and the build is here:

https://koji.fedoraproject.org/koji/taskinfo?taskID=95591030

I am still surprised that this cycle, there are not big breakages. So there is 
nothing to report from my side, except that I am not convinced that the change 
to the tilde versions works as it is supposed to. I think that the 
`%{?development_release}` would need to be added not just to the Ruby version, 
but also to the subpackages and therefore to the Provides, etc. So if anybody 
tries update from the previous snapshot, please let me know your practical 
experience.


Vít



Well, looks like "my" copr build says that (some of) rubygem-foo pkgs building 
C extensions
began to FTBFS with 20221223git7d700a9f5d, while 20221220git8f081d4d0 they were 
okay.

For examples:

rubygem-glib2 
https://copr.fedorainfracloud.org/coprs/mtasaka/rubygem-newruby-test/package/rubygem-glib2/
rubygem-nokogiri 
https://copr.fedorainfracloud.org/coprs/mtasaka/rubygem-newruby-test/package/rubygem-nokogiri/
rubygem-rdiscount 
https://copr.fedorainfracloud.org/coprs/mtasaka/rubygem-newruby-test/package/rubygem-rdiscount/

Looking at the build logs, I strongly believe this is because of this change:

https://github.com/ruby/ruby/commit/0a9544ce4ab86963dde0f3ad0b489b6a354cc8b3
Subject: [PATCH] [rubygems/rubygems] Cleanup intermediate artifacts after
 installing built extensions

https://github.com/rubygems/rubygems/commit/98b6a959bd

So building C extensions, .so is removed from ext/ directory, so at %check, for 
example doing
$ ruby -Ilib:ext:. -e 'Dir.glob' cannot find required .so file and 
%check fails.

So what should Fedora side srpm do?
- Revert the above change on ruby (and also rubygems)
- Or make every rubygem-foo pkgs building C extension to use 
-I%{buildroot}%{gem_extdir_mri} instead of -Iext

Regards,
Mamoru
___
ruby-sig mailing list -- ruby-sig@lists.fedoraproject.org
To unsubscribe send an email to ruby-sig-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/ruby-sig@lists.fedoraproject.org
Do not reply to spam, report it: 
https://pagure.io/fedora-infrastructure/new_issue

zeitwerk updated to 2.6.6

[Mamoru TASAKA]

Hello, ruby-sig folks:

I've updated rubygem-zeitwerk from 2.5.4 to 2.6.6.

2.5.4 FTBFS with ruby3.2: 
https://copr.fedorainfracloud.org/coprs/vondruch/ruby-3.2/package/rubygem-zeitwerk/

This commit is needed to fix this build error:
https://github.com/fxn/zeitwerk/commit/d36d646c157a3b1584035e2014b68f90829adb61
and backporting this commit to 2.5.4 cannot be done cleanly.
Also zeitwerk consumers are basically RoR related, and it seems upstream RoR CI 
already uses
zeitwerk 2.6.x, so I judged that backporting the above commit to Fedora 
zeitwerk is waste of time,
and simply updating to the newest is better.

Regards,
Mamoru
___
ruby-sig mailing list -- ruby-sig@lists.fedoraproject.org
To unsubscribe send an email to ruby-sig-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/ruby-sig@lists.fedoraproject.org
Do not reply to spam, report it: 
https://pagure.io/fedora-infrastructure/new_issue

Re: Ruby 3.2 - mass-prebuild

[Mamoru TASAKA]

Vít Ondruch wrote on 2022/12/13 17:29:


2) webkitgtk - 
https://copr.fedorainfracloud.org/coprs/vondruch/ruby-3.2/build/5132009/

Obviously, the issue is with independent rubygem-json, which was not build by 
mass-prebuild. This is probably tricky due to rubygem-json being subpackage of 
ruby while there is also independent RPM.



I've recently updated rubygem-json to 2.6.3:
https://koji.fedoraproject.org/koji/buildinfo?buildID=2096881

Just note that webkitgtk-2.39.2-6.fc38 is known to FTBFS with ruby3.2,
-7.fc38 is needed (currently still building), see:

https://src.fedoraproject.org/rpms/webkitgtk/c/9d80218444055c571711b4d86fb5b6114c31299c
https://bugs.webkit.org/show_bug.cgi?id=246743
https://github.com/WebKit/WebKit/pull/7531

Regards,
Mamoru

___
ruby-sig mailing list -- ruby-sig@lists.fedoraproject.org
To unsubscribe send an email to ruby-sig-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/ruby-sig@lists.fedoraproject.org
Do not reply to spam, report it: 
https://pagure.io/fedora-infrastructure/new_issue

Re: Ruby 3.2

[Mamoru TASAKA]

Vít Ondruch wrote on 2022/12/02 21:02:


Dne 21. 10. 22 v 15:33 Vít Ondruch napsal(a):


Dne 21. 10. 22 v 13:56 Mamoru TASAKA napsal(a):



* Now rpm supports tilde, tilde is regarded as older than non-tilde version.
  So we can use, say, ruby-3.2.0~preview2-170.20221021gitabcdefg.fc38, for 
example,
  without "resetting" release number to 0.1..




But it could be better, if the date is always first:


3.2.0~20220916git6ad6994457

3.2.0~20221012git70bc8cc6c

3.2.0~20221015preview1

3.2.0~20221101preview1^git4b1504ae0a


But I am not sure this is not overcomplicated.

So any other scheme which would work? 


Just use tilde + date + some other git / preview / or random string,
I think this is easy usage.

Mamoru
___
ruby-sig mailing list -- ruby-sig@lists.fedoraproject.org
To unsubscribe send an email to ruby-sig-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/ruby-sig@lists.fedoraproject.org
Do not reply to spam, report it: 
https://pagure.io/fedora-infrastructure/new_issue

Re: Latest RSpec issues?

[Mamoru TASAKA]

Vít Ondruch wrote on 2022/11/04 1:39:


Dne 03. 11. 22 v 17:13 Mamoru TASAKA napsal(a):

Vít Ondruch wrote on 2022/11/04 0:37:


Dne 03. 11. 22 v 15:37 Mamoru TASAKA napsal(a):

Vít Ondruch wrote on 2022/11/03 22:22:


Dne 03. 11. 22 v 14:07 Mamoru TASAKA napsal(a):

Vít Ondruch wrote on 2022/11/03 21:19:

I have provided negative karma for F37 for the moment:

https://bodhi.fedoraproject.org/updates/FEDORA-2022-f7975d0e6a


However, not sure if it is not too late already, since the update was submitted 
for stable. Mamoru, could you please check the status and our options here?


Vít


This is:
https://github.com/rspec/rspec-mocks/commit/e931e818b577172b89fb4583fc336fbcd25df36b
i.e. to ”emphasize" the difference between keyword v.s. hash



Thx for pointing out the exact commit.




I "think" the package seeing errors due to the above change need fixing anyway,



No doubt about it, the only question is when :)



however
To distinguish "keywords" v.s. "hash" with ruby 3.x seems generally weigh too 
difficult...

As Fedora 37 is not released yet, and is going to be maintained for 13 months,
I think fixing F37 packages seeing the above error is desirable



In this case, can we postpone landing the F37 update and include fixes for the 
affected packages into the update?

(I wish the notifications were not delayed by one week, but hopefully, the FMN 
is going to be fixed soon).



(and on the other hand,
I am not going to upgrade F36 rspec series to 3.12.x)



I support that, thx.

Vít



Well, the simplest solution for now is to revert the above change on F-37.



You mean the rspec-mocks commit? That is interesting idea.


Yes, I mean that (i.e. revert e931e818b577172b89fb4583fc336fbcd25df36b on 
Fedora 37
rubygem-rspec-mocks rpm). Koschei should report errors on rawhide (for rspec 
consumer
rpms) anyway.



Sounds good to me. We can re-enable this once we catch all the issues in 
Rawhide and patches are ready.

Thx


Vít



Okay, will revert on F-37 in rubygem-rspec-mocks-3.12.0-2.fc37 (on rawhide, the 
above
e931e818b577172b89fb4583fc336fbcd25df36b change is still effective)

Mamoru





Mamoru



In the man time, I have fixed rubygem-notiffany, but there seems to be several 
more:

https://koschei.fedoraproject.org/search?q=ruby_by=state-f38%2Crunning%2Cfailing%2Cname

rubygem-listen

rubygem-guard

rubygem-guard-livereload

rubygem-memfs


And that actually might be it. I'll try to take look at listen.


Vít



___
ruby-sig mailing list -- ruby-sig@lists.fedoraproject.org
To unsubscribe send an email to ruby-sig-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/ruby-sig@lists.fedoraproject.org
Do not reply to spam, report it: 
https://pagure.io/fedora-infrastructure/new_issue

___
ruby-sig mailing list -- ruby-sig@lists.fedoraproject.org
To unsubscribe send an email to ruby-sig-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/ruby-sig@lists.fedoraproject.org
Do not reply to spam, report it: 
https://pagure.io/fedora-infrastructure/new_issue


___
ruby-sig mailing list -- ruby-sig@lists.fedoraproject.org
To unsubscribe send an email to ruby-sig-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/ruby-sig@lists.fedoraproject.org
Do not reply to spam, report it: 
https://pagure.io/fedora-infrastructure/new_issue

___
ruby-sig mailing list -- ruby-sig@lists.fedoraproject.org
To unsubscribe send an email to ruby-sig-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/ruby-sig@lists.fedoraproject.org
Do not reply to spam, report it: 
https://pagure.io/fedora-infrastructure/new_issue

Re: Latest RSpec issues?

[Mamoru TASAKA]

Vít Ondruch wrote on 2022/11/04 0:37:


Dne 03. 11. 22 v 15:37 Mamoru TASAKA napsal(a):

Vít Ondruch wrote on 2022/11/03 22:22:


Dne 03. 11. 22 v 14:07 Mamoru TASAKA napsal(a):

Vít Ondruch wrote on 2022/11/03 21:19:

I have provided negative karma for F37 for the moment:

https://bodhi.fedoraproject.org/updates/FEDORA-2022-f7975d0e6a


However, not sure if it is not too late already, since the update was submitted 
for stable. Mamoru, could you please check the status and our options here?


Vít


This is:
https://github.com/rspec/rspec-mocks/commit/e931e818b577172b89fb4583fc336fbcd25df36b
i.e. to ”emphasize" the difference between keyword v.s. hash



Thx for pointing out the exact commit.




I "think" the package seeing errors due to the above change need fixing anyway,



No doubt about it, the only question is when :)



however
To distinguish "keywords" v.s. "hash" with ruby 3.x seems generally weigh too 
difficult...

As Fedora 37 is not released yet, and is going to be maintained for 13 months,
I think fixing F37 packages seeing the above error is desirable



In this case, can we postpone landing the F37 update and include fixes for the 
affected packages into the update?

(I wish the notifications were not delayed by one week, but hopefully, the FMN 
is going to be fixed soon).



(and on the other hand,
I am not going to upgrade F36 rspec series to 3.12.x)



I support that, thx.

Vít



Well, the simplest solution for now is to revert the above change on F-37.



You mean the rspec-mocks commit? That is interesting idea.


Yes, I mean that (i.e. revert e931e818b577172b89fb4583fc336fbcd25df36b on 
Fedora 37
rubygem-rspec-mocks rpm). Koschei should report errors on rawhide (for rspec 
consumer
rpms) anyway.

Mamoru



In the man time, I have fixed rubygem-notiffany, but there seems to be several 
more:

https://koschei.fedoraproject.org/search?q=ruby_by=state-f38%2Crunning%2Cfailing%2Cname

rubygem-listen

rubygem-guard

rubygem-guard-livereload

rubygem-memfs


And that actually might be it. I'll try to take look at listen.


Vít



___
ruby-sig mailing list -- ruby-sig@lists.fedoraproject.org
To unsubscribe send an email to ruby-sig-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/ruby-sig@lists.fedoraproject.org
Do not reply to spam, report it: 
https://pagure.io/fedora-infrastructure/new_issue

___
ruby-sig mailing list -- ruby-sig@lists.fedoraproject.org
To unsubscribe send an email to ruby-sig-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/ruby-sig@lists.fedoraproject.org
Do not reply to spam, report it: 
https://pagure.io/fedora-infrastructure/new_issue

Re: Latest RSpec issues?

[Mamoru TASAKA]

Vít Ondruch wrote on 2022/11/03 22:22:


Dne 03. 11. 22 v 14:07 Mamoru TASAKA napsal(a):

Vít Ondruch wrote on 2022/11/03 21:19:

I have provided negative karma for F37 for the moment:

https://bodhi.fedoraproject.org/updates/FEDORA-2022-f7975d0e6a


However, not sure if it is not too late already, since the update was submitted 
for stable. Mamoru, could you please check the status and our options here?


Vít


This is:
https://github.com/rspec/rspec-mocks/commit/e931e818b577172b89fb4583fc336fbcd25df36b
i.e. to ”emphasize" the difference between keyword v.s. hash



Thx for pointing out the exact commit.




I "think" the package seeing errors due to the above change need fixing anyway,



No doubt about it, the only question is when :)



however
To distinguish "keywords" v.s. "hash" with ruby 3.x seems generally weigh too 
difficult...

As Fedora 37 is not released yet, and is going to be maintained for 13 months,
I think fixing F37 packages seeing the above error is desirable



In this case, can we postpone landing the F37 update and include fixes for the 
affected packages into the update?

(I wish the notifications were not delayed by one week, but hopefully, the FMN 
is going to be fixed soon).



(and on the other hand,
I am not going to upgrade F36 rspec series to 3.12.x)



I support that, thx.

Vít



Well, the simplest solution for now is to revert the above change on F-37.

Mamoru





Regards,
Mamoru



Dne 03. 11. 22 v 13:14 Vít Ondruch napsal(a):

Seems the saga continues with RSpec 3.12:

https://koschei.fedoraproject.org/package/rubygem-notiffany?collection=f38

https://koschei.fedoraproject.org/package/rubygem-listen?collection=f38


Vít



Dne 07. 02. 22 v 12:24 Vít Ondruch napsal(a):

Dear Mamoru,

Could you please check the following two packages which recently started to 
fail?


https://koschei.fedoraproject.org/package/rubygem-webmock?collection=f36

https://koschei.fedoraproject.org/package/rubygem-websocket-extensions?collection=f36


I suspect that this is related to the RSpec update, but the errors are quite 
strange on the first look:


~~~

  1) WebMock::RequestSignature initialization assigns normalized headers
 Failure/Error: @headers = WebMock::Util::Headers.normalize_headers(headers)
   # received :normalize_headers with 
unexpected arguments
 expected: ({"A"=>"a"})
  got: ({"A"=>"a"})
 # ./lib/webmock/request_signature.rb:25:in `headers='
 # ./lib/webmock/request_signature.rb:49:in `assign_options'
 # ./lib/webmock/request_signature.rb:11:in `initialize'
 # ./spec/unit/request_signature_spec.rb:23:in `new'
 # ./spec/unit/request_signature_spec.rb:23:in `block (3 levels) in '
 # ./lib/webmock/rspec.rb:37:in `block (2 levels) in '

~~~


Thx a lot


Vít


P.S. Sorry for not being more helpful, I have to spent some time with CentOS 
Stream 9 to get Ruby into shape there, especially the problematic SystemTap 
support [1].


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




___
ruby-sig mailing list -- ruby-sig@lists.fedoraproject.org
To unsubscribe send an email to ruby-sig-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/ruby-sig@lists.fedoraproject.org
Do not reply to spam, report it: 
https://pagure.io/fedora-infrastructure/new_issue

___
ruby-sig mailing list -- ruby-sig@lists.fedoraproject.org
To unsubscribe send an email to ruby-sig-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/ruby-sig@lists.fedoraproject.org
Do not reply to spam, report it: 
https://pagure.io/fedora-infrastructure/new_issue


___
ruby-sig mailing list -- ruby-sig@lists.fedoraproject.org
To unsubscribe send an email to ruby-sig-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/ruby-sig@lists.fedoraproject.org
Do not reply to spam, report it: 
https://pagure.io/fedora-infrastructure/new_issue

___
ruby-sig mailing list -- ruby-sig@lists.fedoraproject.org
To unsubscribe send an email to ruby-sig-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 

Re: Latest RSpec issues?

[Mamoru TASAKA]

Vít Ondruch wrote on 2022/11/03 21:19:

I have provided negative karma for F37 for the moment:

https://bodhi.fedoraproject.org/updates/FEDORA-2022-f7975d0e6a


However, not sure if it is not too late already, since the update was submitted 
for stable. Mamoru, could you please check the status and our options here?


Vít


This is:
https://github.com/rspec/rspec-mocks/commit/e931e818b577172b89fb4583fc336fbcd25df36b
i.e. to ”emphasize" the difference between keyword v.s. hash

I "think" the package seeing errors due to the above change need fixing anyway, 
however
To distinguish "keywords" v.s. "hash" with ruby 3.x seems generally weigh too 
difficult...

As Fedora 37 is not released yet, and is going to be maintained for 13 months,
I think fixing F37 packages seeing the above error is desirable (and on the 
other hand,
I am not going to upgrade F36 rspec series to 3.12.x)

Regards,
Mamoru
 


Dne 03. 11. 22 v 13:14 Vít Ondruch napsal(a):

Seems the saga continues with RSpec 3.12:

https://koschei.fedoraproject.org/package/rubygem-notiffany?collection=f38

https://koschei.fedoraproject.org/package/rubygem-listen?collection=f38


Vít



Dne 07. 02. 22 v 12:24 Vít Ondruch napsal(a):

Dear Mamoru,

Could you please check the following two packages which recently started to 
fail?


https://koschei.fedoraproject.org/package/rubygem-webmock?collection=f36

https://koschei.fedoraproject.org/package/rubygem-websocket-extensions?collection=f36


I suspect that this is related to the RSpec update, but the errors are quite 
strange on the first look:


~~~

  1) WebMock::RequestSignature initialization assigns normalized headers
 Failure/Error: @headers = WebMock::Util::Headers.normalize_headers(headers)
   # received :normalize_headers with 
unexpected arguments
 expected: ({"A"=>"a"})
  got: ({"A"=>"a"})
 # ./lib/webmock/request_signature.rb:25:in `headers='
 # ./lib/webmock/request_signature.rb:49:in `assign_options'
 # ./lib/webmock/request_signature.rb:11:in `initialize'
 # ./spec/unit/request_signature_spec.rb:23:in `new'
 # ./spec/unit/request_signature_spec.rb:23:in `block (3 levels) in '
 # ./lib/webmock/rspec.rb:37:in `block (2 levels) in '

~~~


Thx a lot


Vít


P.S. Sorry for not being more helpful, I have to spent some time with CentOS 
Stream 9 to get Ruby into shape there, especially the problematic SystemTap 
support [1].


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




___
ruby-sig mailing list -- ruby-sig@lists.fedoraproject.org
To unsubscribe send an email to ruby-sig-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/ruby-sig@lists.fedoraproject.org
Do not reply to spam, report it: 
https://pagure.io/fedora-infrastructure/new_issue

___
ruby-sig mailing list -- ruby-sig@lists.fedoraproject.org
To unsubscribe send an email to ruby-sig-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/ruby-sig@lists.fedoraproject.org
Do not reply to spam, report it: 
https://pagure.io/fedora-infrastructure/new_issue

Re: Ruby 3.2

[Mamoru TASAKA]

Vít Ondruch wrote on 2022/10/17 23:24:

Hi again,

Here is yet another version from Friday:

https://koji.fedoraproject.org/koji/taskinfo?taskID=92978738

Nothing really special from Ruby POV, but I have enabled out-of-source build, 
as was previously discussed here:

https://src.fedoraproject.org/rpms/ruby/pull-request/120

https://src.fedoraproject.org/rpms/ruby/pull-request/122

So while this should not have any influence on resulting package, it might come 
handy when somebody wants to clean the source tree and play with e.g. different 
configuration options or what not.


Vít



Thank you.

By the way, do you have some plan to bring ruby 3.2 development rpm to
f38 buildroot earlier than 2022 Christmas (say, around 2022/11/E)?

The reason I am asking here is that:
* As I wrote above, ruby3.2 is to be released on 2022/12/25 (perhaps),
  usually we wait for this, and actually ruby mass rebuild usually begins
  around 2nd week of January?
  Then mass rebuild for whole Fedora packages (for F38) begins at
  2023-01-18, so (as usual) the timing is very tight.

* Now rpm supports tilde, tilde is regarded as older than non-tilde version.
  So we can use, say, ruby-3.2.0~preview2-170.20221021gitabcdefg.fc38, for 
example,
  without "resetting" release number to 0.1..
  Then we can set the release number of subpackages (such as rubygem-io-console)
  to (0.5.12-)170.gitabcdefg.fc38, so now we don't have to fight with release 
number,
  just we have to keep increasing this.

* And perhaps on 2022/11/E, I guess ruby3.2 would almost stable.

Regards,
Mamoru
___
ruby-sig mailing list -- ruby-sig@lists.fedoraproject.org
To unsubscribe send an email to ruby-sig-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/ruby-sig@lists.fedoraproject.org
Do not reply to spam, report it: 
https://pagure.io/fedora-infrastructure/new_issue

Re: Ruby 3.2

[Mamoru TASAKA]

Vít Ondruch wrote on 2022/10/13 0:26:

Hi again,

I have prepared update again. You can see the changes in the PR [1] I have 
opened (not intended to be merged, just to show the diff) and the scratch build 
is here:

https://koji.fedoraproject.org/koji/taskinfo?taskID=92950720

I have not spot anything which would caught my attention. Please give it a try 
and let me know in case of issues.

Thx

Vít


[1] https://src.fedoraproject.org/rpms/ruby/pull-request/134



Thank you for your work.

While Pavel is trying rebuilding rubygem- packages continuously, now I tried
myself rebuilding.

https://copr.fedorainfracloud.org/coprs/mtasaka/rubygem-newruby-test/
https://copr.fedorainfracloud.org/coprs/mtasaka/heavypkg-newruby-test/

So far
* Out of 495 rubygem- packages:
  - ~447 packages built successfully
  - ~48  failed to build

* And out of other 58 packages which has "BR: ruby-devel" or "BR: 
pkgconfig(ruby)"
  - ~53 packages built successfully
  - ~5 failed to build

Just a quick glance at these (I have not checked all of these, just selected
some of them)

* Removal of File.exists? / Object#=~ / "tainted"ness affects several pacakges
* rubygem-jekyll seems to be affected by keywords / positional argument 
treatment
  change??

By the way, is it better to create "central" bugzilla ticket to keep track of 
ruby32
related issues for each package?

Regards,
Mamoru
___
ruby-sig mailing list -- ruby-sig@lists.fedoraproject.org
To unsubscribe send an email to ruby-sig-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/ruby-sig@lists.fedoraproject.org
Do not reply to spam, report it: 
https://pagure.io/fedora-infrastructure/new_issue

Re: Ruby 3.2

[Mamoru TASAKA]

Hello, Vít:

Vít Ondruch wrote on 2022/10/01 17:10:


And I should really update Pry, because I saw Pry related issues on more places.


For now, may I just backport the below?
https://github.com/pry/pry/commit/b548784b4a31b49026b69849430a9ec9072ae94a

At least the above change fixes rubygem-rmagick build issue.

Regards,
Mamoru
___
ruby-sig mailing list -- ruby-sig@lists.fedoraproject.org
To unsubscribe send an email to ruby-sig-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/ruby-sig@lists.fedoraproject.org
Do not reply to spam, report it: 
https://pagure.io/fedora-infrastructure/new_issue

Re: Ruby 3.2

[Mamoru TASAKA]

Vít Ondruch wrote on 2022/09/29 20:15:





And another issue for Mamoru, this time from rspec-core:


~~~

expected "\nAn error occurred while loading ./spec/example_spec.rb.\nFailure/Error:\n  
RSpec.describe Fixnum d...files took 0.05699 seconds to load)\n0 examples, 0 failures, 1 error 
occurred outside of examples\n" not to string includes: "0 examples"
Diff:
@@ -1,2 +1,22 @@
-0 examples
+
+An error occurred while loading ./spec/example_spec.rb.
+Failure/Error:
+  RSpec.describe Fixnum do
+    describe 'inner' do
+  describe String do
+    it "is available as described_class" do
+  expect(described_class).to eq(String)
+    end
+  end
+    end
+  end
+
+NameError:
+  uninitialized constant Fixnum
+# ./spec/example_spec.rb:1:in `'
+No examples found.
+
+
+Finished in 0.3 seconds (files took 0.05699 seconds to load)
+0 examples, 0 failures, 1 error occurred outside of examples

~~~


And here is the fix:
https://github.com/rspec/rspec-core/commit/bf49c78d7a92e253d557924a3f85fd6991e32ca3


This is likely due to:
https://github.com/ruby/ruby/blob/28840d74c26189f4e730b906c2383e32ea6165fe/NEWS.md?plain=1#L232


In short, it seems to be due to removing deprecated `Fixnum` and `Bignum`. This 
might cause some troubles. Not in rspec-core.



Okay, backported (with minimum changes):
https://src.fedoraproject.org/rpms/rubygem-rspec-core/c/e7531e5398dc0d81fbcdcb9c7b26fb83e009a2e0

I guess removal of Fixnum / Bignum / tainted? and so on will affect many 
packages.

Mamoru.
___
ruby-sig mailing list -- ruby-sig@lists.fedoraproject.org
To unsubscribe send an email to ruby-sig-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/ruby-sig@lists.fedoraproject.org
Do not reply to spam, report it: 
https://pagure.io/fedora-infrastructure/new_issue

Re: Ruby 3.2

[Mamoru TASAKA]

Vít Ondruch wrote on 2022/09/26 19:57:


Which fails due to Racc:

https://copr.fedorainfracloud.org/coprs/pvalena/rubygems-testing/build/4871170/

The issue seems to be fixed upstream:

https://github.com/ruby/racc/pull/191


It is unfortunate that such a minor bug might influence quite lot of the 
ecosystem. Hopefully we will be in better shape in few months. And if on, just 
remember we have to fix this one ;)



I've backported this.
https://src.fedoraproject.org/rpms/rubygem-racc/c/3c4085f926366417a372f0ee6e9746f79ca46bb7

Mamoru

___
ruby-sig mailing list -- ruby-sig@lists.fedoraproject.org
To unsubscribe send an email to ruby-sig-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/ruby-sig@lists.fedoraproject.org
Do not reply to spam, report it: 
https://pagure.io/fedora-infrastructure/new_issue

Re: Minitest 5.16 broke Rails due to kwargs

[Mamoru TASAKA]

Vít Ondruch wrote on 2022/08/02 19:21:

Hi,

Just heads up that I have noticed that RoR (and probably more) are broken after 
Minitest 5.16 landed in Rawhide. This is the RoR commit fixing the issues:

https://github.com/rails/rails/commit/9766eb4a833c26c64012230b96dd1157ebb8e8a2

However, for us it means the fix is spread across multiple components and it 
might need more then this patch.

@Mamoru please don't push the Minitest 5.16 into stable releases.


As you can see on dist-git I've already pushed minitest 5.16 on rawhide on 
2022-06-19,
but I didn't push it to F-36 or below.
 

Vít



Mamoru
___
ruby-sig mailing list -- ruby-sig@lists.fedoraproject.org
To unsubscribe send an email to ruby-sig-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/ruby-sig@lists.fedoraproject.org
Do not reply to spam on the list, report it: 
https://pagure.io/fedora-infrastructure

Re: List of long term FTBFS packages to be retired in August

[Mamoru TASAKA]

Miro Hrončok wrote on 2022/07/26 21:28:

Dear maintainers.

Based on the current fail to build from source policy, the following packages
will be retired from Fedora 37 approximately one week before branching (August 
2022).

Policy: 
https://docs.fedoraproject.org/en-US/fesco/Fails_to_build_from_source_Fails_to_install/

The packages in rawhide were not successfully built at least since Fedora 35.

This report is based on dist tags.

Packages collected via:
https://github.com/hroncok/fedora-report-ftbfs-retirements/blob/master/ftbfs-retirements.ipynb

If you see a package that was built, please let me know.
If you see a package that should be exempted from the process, please let me 
know and we can work together to get a FESCo approval for that.

If you see a package that can be rebuilt, please do so.

  Package   (co)maintainers
=
rubygem-coffee-rails jaruga, ruby-packagers-sig, vondruch
rubygem-minitest-reporters   pvalena
rubygem-sprockets-rails  jaruga, pvalena, ruby-packagers-sig



So the above says "retirement will happen about one week before mass branch 
(2022-08-09)",
that is 2022-08-02 or so, so this will happen very soon!

rubygem-sprockets-rails is already fixed (as I posted about 1 weeks ago).

I can fix rubygem-minitest-reporters (scratch build successful), should I push
the fix?

I have not checked rubygem-coffee-rails, sorry.

Regards,
Mamoru
___
ruby-sig mailing list -- ruby-sig@lists.fedoraproject.org
To unsubscribe send an email to ruby-sig-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/ruby-sig@lists.fedoraproject.org
Do not reply to spam on the list, report it: 
https://pagure.io/fedora-infrastructure

rawhide hits rpm-4.18.0 alpha - affecting gem based packaging

[Mamoru TASAKA]

Hello, all:

Now I was going to update rubygem-kramdown, resulting in build failure.
Then I've noticed that on rawhide, "rpm" was updated to rpm 4.18.0 alpha .
This seems to affect current gem based packaing of ours.

Mainly: "%setup -q" for foo-%version.gem places foo-%version.gemspec on
%{_sourcedir} with rpm 4.18.0 alpha . Previously (with rpm 4.17.x), gemspec file
was placed on %{_builddir}.

Maybe we may have to update packaging guideline, or modify gem2rpm.

Regards,
Mamoru
___
ruby-sig mailing list -- ruby-sig@lists.fedoraproject.org
To unsubscribe send an email to ruby-sig-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/ruby-sig@lists.fedoraproject.org
Do not reply to spam on the list, report it: 
https://pagure.io/fedora-infrastructure

Re: rspec 3.11.0 hits rawhide/f36

[Mamoru TASAKA]

Vít Ondruch wrote on 2022/02/15 1:35:


Dne 10. 02. 22 v 13:36 Mamoru TASAKA napsal(a):

Hello, ruby-sig folks:

I've upgraded rubygem-rspec (and its friends: rspec-core, rspec-expectations,
rspec-mocks, rspec-support) to 3.11.0. Please try using this, thank you.

Note that the change Vít previously mentioned (i.e.
  https://github.com/rspec/rspec-mocks/issues/1460
  https://github.com/rspec/rspec-mocks/pull/1394
) is still in effect.
Some rspec usage, espcially using "with" syntax may need updating.



Is this included also in 3.10.3? Koschei reports issues such as this:

https://apps.fedoraproject.org/koschei/package/rubygem-thor?collection=f34


Yes, this is also included in (rspec-mocks-)3.10.3.

Mamoru

___
ruby-sig mailing list -- ruby-sig@lists.fedoraproject.org
To unsubscribe send an email to ruby-sig-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/ruby-sig@lists.fedoraproject.org
Do not reply to spam on the list, report it: 
https://pagure.io/fedora-infrastructure

rspec 3.11.0 hits rawhide/f36

[Mamoru TASAKA]

Hello, ruby-sig folks:

I've upgraded rubygem-rspec (and its friends: rspec-core, rspec-expectations,
rspec-mocks, rspec-support) to 3.11.0. Please try using this, thank you.

Note that the change Vít previously mentioned (i.e.
  https://github.com/rspec/rspec-mocks/issues/1460
  https://github.com/rspec/rspec-mocks/pull/1394
) is still in effect.
Some rspec usage, espcially using "with" syntax may need updating.

Regards,
Mamoru
___
ruby-sig mailing list -- ruby-sig@lists.fedoraproject.org
To unsubscribe send an email to ruby-sig-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/ruby-sig@lists.fedoraproject.org
Do not reply to spam on the list, report it: 
https://pagure.io/fedora-infrastructure

Re: Latest RSpec issues?

[Mamoru TASAKA]

Mamoru TASAKA wrote on 2022/02/07 22:45:

Vít Ondruch wrote on 2022/02/07 20:24:

Dear Mamoru,

Could you please check the following two packages which recently started to 
fail?

https://koschei.fedoraproject.org/package/rubygem-webmock?collection=f36
https://koschei.fedoraproject.org/package/rubygem-websocket-extensions?collection=f36

I suspect that this is related to the RSpec update, but the errors are quite 
strange on the first look:


~~~

   1) WebMock::RequestSignature initialization assigns normalized headers
  Failure/Error: @headers = 
WebMock::Util::Headers.normalize_headers(headers)
    # received :normalize_headers with 
unexpected arguments
  expected: ({"A"=>"a"})
   got: ({"A"=>"a"})
  # ./lib/webmock/request_signature.rb:25:in `headers='
  # ./lib/webmock/request_signature.rb:49:in `assign_options'
  # ./lib/webmock/request_signature.rb:11:in `initialize'
  # ./spec/unit/request_signature_spec.rb:23:in `new'
  # ./spec/unit/request_signature_spec.rb:23:in `block (3 levels) in '
  # ./lib/webmock/rspec.rb:37:in `block (2 levels) in '

~~~


I am trying to fix rubygem-yard build failure, but currently I see the same 
issue
(on my local machine).

Looks like this is:
https://github.com/rspec/rspec-mocks/issues/1460
- was brought by: https://github.com/rspec/rspec-mocks/pull/1394

expecially:
https://github.com/rspec/rspec-mocks/pull/1394/files#diff-ae171e2be1f799a6704fcbadb353721dda4d078185aa265671e07b14594c72e5R63


# if both arguments end with Hashes, and if one is a keyword hash and the other 
is not, they don't match


So rspec upstream is saying this is correct (again keywords / hash 
separation...), previous
rspec-mocks 3.10.2 behaved wrongly with ruby3 (rspec upstream says), and
rspec-mocks user side has to fix this.


Just took a look at webmock (rubygem-webmock-3.11.1-4.fc36), so with 
rspec-mocks 3.10.3
the following change seems needed:


diff -urp webmock-3.11.1/spec.orig/unit/request_signature_spec.rb 
webmock-3.11.1/spec/unit/request_signature_spec.rb
--- webmock-3.11.1/spec.orig/unit/request_signature_spec.rb 2022-02-07 
23:13:47.262714681 +0900
+++ webmock-3.11.1/spec/unit/request_signature_spec.rb  2022-02-07 
23:23:11.527273614 +0900
@@ -18,7 +18,7 @@ describe WebMock::RequestSignature do
 end
 
 it "assigns normalized headers" do

-  expect(WebMock::Util::Headers).to receive(:normalize_headers).with('A' => 
'a').and_return('B' => 'b')
+  expect(WebMock::Util::Headers).to receive(:normalize_headers).with({'A' => 
'a'}).and_return('B' => 'b')
   expect(
 WebMock::RequestSignature.new(:get, "www.example.com", headers: {'A' 
=> 'a'}).headers
   ).to eq({'B' => 'b'})
Only in webmock-3.11.1/spec/unit: request_signature_spec.rb~
diff -urp webmock-3.11.1/spec.orig/unit/response_spec.rb 
webmock-3.11.1/spec/unit/response_spec.rb
--- webmock-3.11.1/spec.orig/unit/response_spec.rb  2022-02-07 
23:13:47.262714681 +0900
+++ webmock-3.11.1/spec/unit/response_spec.rb   2022-02-07 23:23:52.502314196 
+0900
@@ -31,7 +31,7 @@ describe WebMock::Response do
   end
 
   it "should report normalized headers" do

-expect(WebMock::Util::Headers).to receive(:normalize_headers).with('A' => 
'a').and_return('B' => 'b')
+expect(WebMock::Util::Headers).to receive(:normalize_headers).with({'A' => 
'a'}).and_return('B' => 'b')
 @response = WebMock::Response.new(headers: {'A' => 'a'})
 expect(@response.headers).to eq({'B' => 'b'})
   end


Mamoru
___
ruby-sig mailing list -- ruby-sig@lists.fedoraproject.org
To unsubscribe send an email to ruby-sig-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/ruby-sig@lists.fedoraproject.org
Do not reply to spam on the list, report it: 
https://pagure.io/fedora-infrastructure

Re: Latest RSpec issues?

[Mamoru TASAKA]

Vít Ondruch wrote on 2022/02/07 20:24:

Dear Mamoru,

Could you please check the following two packages which recently started to 
fail?

https://koschei.fedoraproject.org/package/rubygem-webmock?collection=f36
https://koschei.fedoraproject.org/package/rubygem-websocket-extensions?collection=f36

I suspect that this is related to the RSpec update, but the errors are quite 
strange on the first look:


~~~

   1) WebMock::RequestSignature initialization assigns normalized headers
  Failure/Error: @headers = 
WebMock::Util::Headers.normalize_headers(headers)
    # received :normalize_headers with 
unexpected arguments
  expected: ({"A"=>"a"})
   got: ({"A"=>"a"})
  # ./lib/webmock/request_signature.rb:25:in `headers='
  # ./lib/webmock/request_signature.rb:49:in `assign_options'
  # ./lib/webmock/request_signature.rb:11:in `initialize'
  # ./spec/unit/request_signature_spec.rb:23:in `new'
  # ./spec/unit/request_signature_spec.rb:23:in `block (3 levels) in '
  # ./lib/webmock/rspec.rb:37:in `block (2 levels) in '

~~~


I am trying to fix rubygem-yard build failure, but currently I see the same 
issue
(on my local machine).

Looks like this is:
https://github.com/rspec/rspec-mocks/issues/1460
- was brought by: https://github.com/rspec/rspec-mocks/pull/1394

expecially:
https://github.com/rspec/rspec-mocks/pull/1394/files#diff-ae171e2be1f799a6704fcbadb353721dda4d078185aa265671e07b14594c72e5R63


# if both arguments end with Hashes, and if one is a keyword hash and the other 
is not, they don't match


So rspec upstream is saying this is correct (again keywords / hash 
separation...), previous
rspec-mocks 3.10.2 behaved wrongly with ruby3 (rspec upstream says), and
rspec-mocks user side has to fix this.


Thx a lot
Vít


P.S. Sorry for not being more helpful, I have to spent some time with CentOS 
Stream 9 to get Ruby into shape there, especially the problematic SystemTap 
support [1].
[1] https://bugs.ruby-lang.org/issues/18257



Regards,
Mamoru
___
ruby-sig mailing list -- ruby-sig@lists.fedoraproject.org
To unsubscribe send an email to ruby-sig-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/ruby-sig@lists.fedoraproject.org
Do not reply to spam on the list, report it: 
https://pagure.io/fedora-infrastructure

Re: Ruby 3.1 - Mass rebuild

[Mamoru TASAKA]

Vít Ondruch wrote on 2022/01/28 5:12:


Dne 27. 01. 22 v 14:23 Mamoru TASAKA napsal(a):

Vít Ondruch wrote on 2022/01/27 22:05:





Thank you! Now I vote for merging into f36 buildroot.



Should be done now:
https://bodhi.fedoraproject.org/updates/FEDORA-2022-5a660a2215
With exception of player, but relengs will hopefully take care about that.

Thx everybody once again!


Vít


A.
Note that Koschei shows that not a few package now fail to build due to
psych 4 change on YAML.load now default to YAML.safe_load, build.log
looks like

Psych::DisallowedClass: Tried to load unspecified class: MIME::Type

The easiest fix is to change YAML.load to YAML.unsafe_load .

B.
Another not a few errors are now some packages need BR: rubygem(matrix) .

I will submit PRs to fix these when I have my free time.

Regards,
Mamoru
___
ruby-sig mailing list -- ruby-sig@lists.fedoraproject.org
To unsubscribe send an email to ruby-sig-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/ruby-sig@lists.fedoraproject.org
Do not reply to spam on the list, report it: 
https://pagure.io/fedora-infrastructure

Re: List of long term FTBFS packages to be retired in March

[Mamoru TASAKA]

Miro Hrončok wrote on 2022/02/01 23:08:

Dear maintainers.

Based on the current fail to build from source policy, the following packages
should be retired from Fedora 36 approximately one week before branching.

However, 5 weekly reminders are required and I forgot to start this sooner,
hence the retirement will happen in 5 weeks, i.e. March 1st 2022.
Since this is after the Beta Freeze,
I will skip retiring components with depending packages.
Such components will be retired during the next release cycle,
and are included in this report for completeness.

Policy: 
https://docs.fedoraproject.org/en-US/fesco/Fails_to_build_from_source_Fails_to_install/

The packages in rawhide were not successfully built at least since Fedora 33.

This report is based on dist tags.

Packages collected via:
https://github.com/hroncok/fedora-report-ftbfs-retirements/blob/master/ftbfs-retirements.ipynb

If you see a package that was built, please let me know.
If you see a package that should be exempted from the process, please let me 
know and we can work together to get a FESCo approval for that.

If you see a package that can be rebuilt, please do so.

     Package  (co)maintainers







rubygem-cucumber-rails    mmorsi, vondruch
rubygem-selenium-webdriver    mmorsi, ruby-packagers-sig, vondruch
rubygem-sup    dcallagh, jaruga, ruby-packagers-sig, shreyankg






Depending on: rubygem-selenium-webdriver (21)
 Too many dependencies for rubygem-selenium-webdriver, not all listed here


Here, it seems rubygem-cucumber-rails rubygem-sup have no impact on other 
packages.

rubygem-selenium-webdriver has huge impact on other packages:

Although runtime dependency has no impact:
$ dnf repoquery --quiet --repo=koji-36 --qf '%{sourcerpm}' --whatrequires 
rubygem-selenium-webdriver
rubygem-selenium-webdriver-3.142.7-3.fc33.src.rpm


BuildRequires has huge impact:
$ dnf repoquery --arch=src --quiet --repo=koji-36-source --recursive --whatrequires 
"rubygem(selenium-webdriver)"
rubygem-actionpack-1:6.1.4.1-2.fc36.src
rubygem-actiontext-0:6.1.4.1-2.fc36.src
rubygem-capybara-0:3.34.0-5.fc36.src
rubygem-cucumber-rails-0:1.8.0-5.fc33.src
rubygem-rspec-rails-0:4.0.2-3.fc36.src

For capybara:
$ dnf repoquery --arch=src --quiet --repo=koji-36-source --recursive --whatrequires 
"rubygem(capybara)"
rubygem-actionpack-1:6.1.4.1-2.fc36.src
rubygem-actiontext-0:6.1.4.1-2.fc36.src
rubygem-cucumber-rails-0:1.8.0-5.fc33.src
rubygem-railties-0:6.1.4.1-2.fc36.src
rubygem-rspec-rails-0:4.0.2-3.fc36.src
rubygem-simplecov-0:0.13.0-12.fc36.src

Can someone investigate rubygem-selenium-webdriver build failure? Thank you in 
advance.

BTW, for rubygem-simplecov, I've found that rubygem-capybara (so 
rubygem-selenium-webdriver) BR
dependency can easily be removed.

Regards,
Mamoru
___
ruby-sig mailing list -- ruby-sig@lists.fedoraproject.org
To unsubscribe send an email to ruby-sig-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/ruby-sig@lists.fedoraproject.org
Do not reply to spam on the list, report it: 
https://pagure.io/fedora-infrastructure

orphan rubygem-ruby-ntlm

[Mamoru TASAKA]

Hello, ruby-sig folks:

I've orphaned rubygem-ruby-ntlm .

Currently repoquery shows no package uses this package uses this packages 
either on
BuildRequires or Requires. On rawhide, this package FTBFS because this package
uses OpenSSL::Digest::MD4 and OpenSSL::Cipher::DES , which does not seem to be
supported on Fedora openssl-3.

Regards,
Mamoru
___
ruby-sig mailing list -- ruby-sig@lists.fedoraproject.org
To unsubscribe send an email to ruby-sig-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/ruby-sig@lists.fedoraproject.org
Do not reply to spam on the list, report it: 
https://pagure.io/fedora-infrastructure

rubygem(rake) runtime dependency removed from rubygem-rspec-core

[Mamoru TASAKA]

Hello, ruby-sig folks:

With PR: https://src.fedoraproject.org/rpms/rubygem-rspec-core/pull-request/4
I removed rubygem(rake) Requires (when using on koji buildroot) on:
https://src.fedoraproject.org/rpms/rubygem-rspec-core/c/15e3de8d5ccf32c7199d9f39e45d536fa6159a48?branch=rawhide

Note that some of rubygems related packages becan to fail to rebuild
due to this change, especially on %check stage, e.g.

* rubygem-rspec-{core,expectations,mocks}
* rubygem-cucumber

I am going to add "BR: rubygem(rake)" for those packages when I notice such 
issues,
but if you find it, just add "BR: rubygem(rake)" to satisfy dependency.

Regards,
Mamoru
___
ruby-sig mailing list -- ruby-sig@lists.fedoraproject.org
To unsubscribe send an email to ruby-sig-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/ruby-sig@lists.fedoraproject.org
Do not reply to spam on the list, report it: 
https://pagure.io/fedora-infrastructure

Re: Ruby 3.1 - Mass rebuild

[Mamoru TASAKA]

Vít Ondruch wrote on 2022/01/27 22:05:


Dne 27. 01. 22 v 13:50 Mamoru TASAKA napsal(a):

Vít Ondruch wrote on 2022/01/27 21:37:


Dne 27. 01. 22 v 11:50 Vít Ondruch napsal(a):



Dne 27. 01. 22 v 11:14 Mamoru TASAKA napsal(a):


7    rubygem-ffi-1.15.5-1.fc36.src.rpm
https://koji.fedoraproject.org/koji/taskinfo?taskID=81980984
%check stage fails with SIGABRT. Even build for rawhide now fails.

I would apprecite it if someone looks at what is happening here. This affects 
lots of
packages - rubygem-cucumber indirectly depends on this, for example



Yes, this is a bummer. I suspect this is the same issue as the Fiddle failures:

https://src.fedoraproject.org/rpms/ruby/c/b6d9b2acd19c1f6f98468e667ec9f5b829228a21

If I am correct, I think we should disable the failing test case and hope that 
the apps using FFI are not using fork ATM.



I have pushed workaround here:
https://src.fedoraproject.org/rpms/rubygem-ffi/c/19f6fee2f1f21ffd437018849a9f868a7b83b923?branch=rawhide



And the build is running:


https://koji.fedoraproject.org/koji/taskinfo?taskID=82006114


Looks like this is built for rawhide (f36). 



Ouch  thx for spotting this. Luckily it won't hurt anything except my ego  
Here should be the right one:

https://koji.fedoraproject.org/koji/taskinfo?taskID=82007038


Vít



Thank you! Now I vote for merging into f36 buildroot.

Mamoru
___
ruby-sig mailing list -- ruby-sig@lists.fedoraproject.org
To unsubscribe send an email to ruby-sig-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/ruby-sig@lists.fedoraproject.org
Do not reply to spam on the list, report it: 
https://pagure.io/fedora-infrastructure

Re: Ruby 3.1 - Mass rebuild

[Mamoru TASAKA]

Vít Ondruch wrote on 2022/01/27 21:37:


Dne 27. 01. 22 v 11:50 Vít Ondruch napsal(a):



Dne 27. 01. 22 v 11:14 Mamoru TASAKA napsal(a):


7    rubygem-ffi-1.15.5-1.fc36.src.rpm
https://koji.fedoraproject.org/koji/taskinfo?taskID=81980984
%check stage fails with SIGABRT. Even build for rawhide now fails.

I would apprecite it if someone looks at what is happening here. This affects 
lots of
packages - rubygem-cucumber indirectly depends on this, for example



Yes, this is a bummer. I suspect this is the same issue as the Fiddle failures:

https://src.fedoraproject.org/rpms/ruby/c/b6d9b2acd19c1f6f98468e667ec9f5b829228a21

If I am correct, I think we should disable the failing test case and hope that 
the apps using FFI are not using fork ATM.



I have pushed workaround here:
https://src.fedoraproject.org/rpms/rubygem-ffi/c/19f6fee2f1f21ffd437018849a9f868a7b83b923?branch=rawhide



And the build is running:


https://koji.fedoraproject.org/koji/taskinfo?taskID=82006114


Looks like this is built for rawhide (f36).  

Vít


Mamoru
 
___

ruby-sig mailing list -- ruby-sig@lists.fedoraproject.org
To unsubscribe send an email to ruby-sig-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/ruby-sig@lists.fedoraproject.org
Do not reply to spam on the list, report it: 
https://pagure.io/fedora-infrastructure

Re: Ruby 3.1 - Mass rebuild

[Mamoru TASAKA]

Vít Ondruch wrote on 2022/01/26 21:59:

So Fedora mass rebuild has finished (although I am not sure how does it look 
with the signing of the packages), therefore we should be good to go. I have 
requested side tag:


$ fedpkg request-side-tag
Side tag 'f36-build-side-49941' (id 49941) created.
Use 'fedpkg build --target=f36-build-side-49941' to use it.
Use 'koji wait-repo f36-build-side-49941' to wait for the build repo to be 
generated.


and Ruby 3.1 is already built there as you can see at:
https://koji.fedoraproject.org/koji/builds?inherited=0=49941=-build_id=1
or using:
~~~
$ koji list-tagged f36-build-side-49941
~~~

Now this is a list of packages, which very likely needs rebuild:
~~~
$ dnf repoquery --disablerepo=* --enablerepo=rawhide 
--enablerepo=rawhide-source --arch=src --whatrequires 'ruby-devel' | sort | uniq
~~~
You can take the package and just fire rebuild, but please ensure that you are 
using f36-build-side-49941 build target, i.e. the build command should look 
like:
~~~
$ fedpkg build --target f36-build-side-49941
~~~ 
Please be careful, because if you, by a chance, omit the f36-build-side-49941 target, you'll be building against Ruby 3.0 which is not what you want.


If you won't do it by yourself, I'll be rebuilding all packages after I am 
finished with my packages. I'll be using fermig [1] to help me with that. If 
you don't want me to touch your packages for whatever reason, please let me 
know.

As always, any help/testing/feedback is welcome.



Current status
$ dnf repoquery --quiet --repo=koji-f36-build-side-49941 --qf '%{sourcerpm}' 
--whatrequires "libruby.so.3.0()(64bit)" | cat -n
 1  libguestfs-1.47.2-2.fc36.src.rpm
https://koji.fedoraproject.org/koji/taskinfo?taskID=81990276
On x86_64, %check fails with kernel oops. On ppc64le there is unsatisfied 
BuildRequires dependency.

 2  mlt-6.26.1-5.fc36.src.rpm
even $ fedpkg sources fails, for now I don't want to proceed further..

 3  nbdkit-1.29.14-1.fc36.src.rpm
https://koji.fedoraproject.org/koji/taskinfo?taskID=81983055
Looked at x86_64 failure, %configure is failing with some questionable reason,
reported against gcc for now:
https://bugzilla.redhat.com/show_bug.cgi?id=2046640


 4  openbabel-3.1.1-5.fc36.src.rpm
https://koji.fedoraproject.org/koji/taskinfo?taskID=81981066
Even build for rawhide fails, but mass rebuild was successful.
During mass rebuild and now, cmake is updated and build failure seems related
to cmake update.

 5  pcs-0.10.11-2.fc36.src.rpm
https://koji.fedoraproject.org/koji/taskinfo?taskID=81980259
BuildRequires rubygem-ffi

 6  qpid-proton-0.36.0-2.fc36.src.rpm
https://koji.fedoraproject.org/koji/taskinfo?taskID=81978394
Maybe same issue as nbdkit

 7  rubygem-ffi-1.15.5-1.fc36.src.rpm
https://koji.fedoraproject.org/koji/taskinfo?taskID=81980984
%check stage fails with SIGABRT. Even build for rawhide now fails.

I would apprecite it if someone looks at what is happening here. This affects 
lots of
packages - rubygem-cucumber indirectly depends on this, for example

 8  rubygem-hiredis-0.6.3-9.fc35.src.rpm
https://koji.fedoraproject.org/koji/taskinfo?taskID=81994532
hiredis is updated from 0.13.3 to 1.0.2, and there seems some API change.

 9  rubygem-pg-1.2.3-6.fc35.src.rpm
https://koji.fedoraproject.org/koji/taskinfo?taskID=81994559
Not looked at this in detail yet

10  rubygem-websocket-driver-0.7.5-3.fc36.src.rpm
https://koji.fedoraproject.org/koji/taskinfo?taskID=81945124
%check fails with something looking like some minor output change.

Regards,
Mamoru
___
ruby-sig mailing list -- ruby-sig@lists.fedoraproject.org
To unsubscribe send an email to ruby-sig-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/ruby-sig@lists.fedoraproject.org
Do not reply to spam on the list, report it: 
https://pagure.io/fedora-infrastructure

Re: Ruby 3.1 - Mass rebuild

[Mamoru TASAKA]

Pavel Valena wrote on 2022/01/27 1:12:


I've started my mass rebuild script[1] which will build all the
packages in the ruby-packagers-sig [2] and also which I own [3]. The
scratch build, along with other checks[*] is done prior to that, of
course.

Here [4] is the list of currently targeted packages, with dependency
on `libruby.so.3.0()`. Please let me know if you want me to skip some
packages.


Really? At least rubygem-ZenTest is noarch. And directly executing
$ dnf repoquery --whatrequires "libruby.so.3.0()(64bit)" does not show
such packages. Would you recheck your script?

Currently:

$ dnf repoquery --quiet --repo=koji-f36-build-side-49941 --qf '%{sourcerpm}' 
--whatrequires "libruby.so.3.0()(64bit)" | cat -n
 1  clearsilver-0.10.5-66.fc36.src.rpm
 2  dislocker-0.7.3-6.fc36.src.rpm
 3  graphviz-2.50.0-3.fc36.src.rpm
 4  hivex-1.3.21-4.fc36.src.rpm
 5  hyperestraier-1.4.13-45.fc35.src.rpm
 6  kf5-kross-interpreters-21.12.1-2.fc36.src.rpm
 7  libcaca-0.99-0.57.beta20.fc36.src.rpm
 8  libguestfs-1.47.2-2.fc36.src.rpm
 9  libprelude-5.2.0-10.fc36.src.rpm
10  libsbml-5.19.0-10.fc36.src.rpm
11  libselinux-3.3-3.fc36.src.rpm
12  libyui-bindings-2.0.2-7.fc36.src.rpm
13  mapserver-7.6.4-9.fc36.src.rpm
14  marisa-0.2.4-53.fc36.src.rpm
15  mlt-6.26.1-5.fc36.src.rpm
16  nbdkit-1.29.14-1.fc36.src.rpm
17  notmuch-0.34.3-2.fc36.src.rpm
18  openbabel-3.1.1-5.fc36.src.rpm
19  openwsman-2.7.1-2.fc36.src.rpm
20  pcs-0.10.11-2.fc36.src.rpm
21  player-3.1.0-37.fc36.src.rpm
22  qdbm-1.8.78-48.fc36.src.rpm
23  qpid-proton-0.36.0-2.fc36.src.rpm
24  remctl-3.17-5.fc36.src.rpm
25  rrdtool-1.7.2-22.fc36.src.rpm
26  ruby-augeas-0.5.0-29.fc36.src.rpm
27  ruby-gnome2-0.90.4-9.fc36.8.src.rpm
28  ruby-mecab-0.996-6.fc36.20.src.rpm
29  ruby-ncurses-1.3.1-38.fc36.src.rpm
30  rubygem-atomic-1.1.101-10.fc35.src.rpm
31  rubygem-bootsnap-1.4.7-5.fc36.src.rpm
32  rubygem-bson-4.10.0-5.fc36.src.rpm
33  rubygem-byebug-11.1.3-3.fc36.2.src.rpm
34  rubygem-ffi-1.15.5-1.fc36.src.rpm
35  rubygem-glu-8.3.0-19.fc36.src.rpm
36  rubygem-glut-8.3.0-18.fc36.src.rpm
37  rubygem-goocanvas1-1.2.6-29.fc36.src.rpm
38  rubygem-gtk2-3.4.3-5.fc36.src.rpm
39  rubygem-gtksourceview2-3.4.3-5.fc36.src.rpm
40  rubygem-hiredis-0.6.3-9.fc35.src.rpm
41  rubygem-http_parser.rb-0.6.0-22.fc35.src.rpm
42  rubygem-krb5-auth-0.8.3-16.gita86ddf2.fc36.src.rpm
43  rubygem-msgpack-1.1.0-17.fc36.src.rpm
44  rubygem-mysql2-0.5.3-9.fc36.src.rpm
45  rubygem-narray-0.6.1.1-22.fc35.src.rpm
46  rubygem-ncursesw-1.4.10-6.fc36.src.rpm
47  rubygem-nokogiri-1.13.1-1.fc36.1.src.rpm
48  rubygem-opengl-0.10.0-18.fc36.src.rpm
49  rubygem-ox-2.14.4-3.fc36.src.rpm
50  rubygem-pg-1.2.3-6.fc35.src.rpm
51  rubygem-posix-spawn-0.3.15-5.fc36.src.rpm
52  rubygem-puma-5.5.2-1.fc36.src.rpm
53  rubygem-rdiscount-2.2.0.2-5.fc36.src.rpm
54  rubygem-redcarpet-3.3.2-20.fc35.src.rpm
55  rubygem-regexp_property_values-1.0.0-5.fc36.src.rpm
56  rubygem-ruby-libvirt-0.7.1-13.fc35.src.rpm
57  rubygem-ruby-shadow-2.5.0-17.fc36.src.rpm
58  rubygem-vte-3.4.3-5.fc36.src.rpm
59  rubygem-websocket-driver-0.7.5-3.fc36.src.rpm
60  simspark-0.3.2-4.fc36.src.rpm
61  skf-2.10.14-4.fc36.2.src.rpm
62  subversion-1.14.1-9.fc36.src.rpm
63  vim-command-t-5.0.3-3.fc36.src.rpm
64  weechat-3.4-4.fc36.src.rpm
65  xmms2-0.8-79.fc36.src.rpm



[*] Previous git entries are checked for changelog entries I've
encountered in previous years (see script above). The builds will
retry on failure, as well as the scratch-builds will retry in another
pass (in case there are dependency loops).
Example builds[5][6].

[1] https://gist.github.com/154a9f1863cfdadae46c7d7ead359613
[2] 
https://github.com/pvalena/theprototype/blob/main/fedora/list_group_packages.sh
[3] 
https://github.com/pvalena/theprototype/blob/main/fedora/list_owned_packages.sh
[4] https://gist.github.com/pvalena/f48bce8c0e54b6222d51ecafdc421654
[5] https://koji.fedoraproject.org/koji/taskinfo?taskID=81946328
[6] https://koji.fedoraproject.org/koji/taskinfo?taskID=81946627

Regards,
Pavel



Mamoru
___
ruby-sig mailing list -- ruby-sig@lists.fedoraproject.org
To unsubscribe send an email to ruby-sig-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/ruby-sig@lists.fedoraproject.org
Do not reply to spam on the list, report it: 
https://pagure.io/fedora-infrastructure

Re: Ruby 3.1 - Mass rebuild

[Mamoru TASAKA]

Vít Ondruch wrote on 2022/01/26 21:59:

So Fedora mass rebuild has finished (although I am not sure how does it look 
with the signing of the packages), therefore we should be good to go. I have 
requested side tag:


$ fedpkg request-side-tag
Side tag 'f36-build-side-49941' (id 49941) created.
Use 'fedpkg build --target=f36-build-side-49941' to use it.
Use 'koji wait-repo f36-build-side-49941' to wait for the build repo to be 
generated.

and Ruby 3.1 is already built there as you can see at:
https://koji.fedoraproject.org/koji/builds?inherited=0=49941=-build_id=1
or using:
~~~
$ koji list-tagged f36-build-side-49941
~~~
Now this is a list of packages, which very likely needs rebuild:
~~~
$ dnf repoquery --disablerepo=* --enablerepo=rawhide 
--enablerepo=rawhide-source --arch=src --whatrequires 'ruby-devel' | sort | uniq
~~~
You can take the package and just fire rebuild, but please ensure that you are 
using f36-build-side-49941 build target, i.e. the build command should look 
like:
~~~
$ fedpkg build --target f36-build-side-49941
~~~
Please be careful, because if you, by a chance, omit the f36-build-side-49941 
target, you'll be building against Ruby 3.0 which is not what you want.

If you won't do it by yourself, I'll be rebuilding all packages after I am 
finished with my packages. I'll be using fermig [1] to help me with that. If 
you don't want me to touch your packages for whatever reason, please let me 
know.

As always, any help/testing/feedback is welcome.

Vít


[1] https://github.com/fedora-ruby/fermig


Now I am going to bed..
Just note that due to package-notes injecting some flags to %build_ldflags , now
executing %gem_install on %prep (instead of %build) section containing C 
extension
will fail because

- creating package_notes is done at the begininning of %build
- %buildsubdir is not defined at %prep (so package_notes file name is wrong at 
%prep)

so for most cases now we have to move %gem_install to %build (from %prep)

Regards,
Mamoru

___
ruby-sig mailing list -- ruby-sig@lists.fedoraproject.org
To unsubscribe send an email to ruby-sig-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/ruby-sig@lists.fedoraproject.org
Do not reply to spam on the list, report it: 
https://pagure.io/fedora-infrastructure

Re: Ruby 3.1 - Mass rebuild

[Mamoru TASAKA]

Mamoru TASAKA wrote on 2022/01/19 22:27:

Vít Ondruch wrote on 2022/01/19 19:54:


Dne 19. 01. 22 v 9:08 Pavel Valena napsal(a):

On Tue, Jan 18, 2022 at 6:39 PM Vít Ondruch  wrote:


Dne 18. 01. 22 v 12:00 Pavel Valena napsal(a):

On Mon, Jan 17, 2022 at 4:27 PM Vít Ondruch  wrote:

Dne 17. 01. 22 v 16:15 Vít Ondruch napsal(a):

Hi,


4)
```
+ ruby -rrubygems -Ilib:test:ext/gio2 test/run-test.rb
glib-compile-resources ruby-gio2.gresource.xml
cd resource
glib-compile-schemas .
cd -
cd schema/default
glib-compile-schemas .
cd -
cd schema/source
cd -
Loaded suite test
Started
../usr/share/gems/gems/gobject-introspection-3.4.9/lib/gobject-introspection/loader.rb:616:
[BUG] Segmentation fault at 0x0>
ruby 3.1.0dev (2021-12-07 master ec878dac90) [x86_64-linux]


```
https://copr.fedorainfracloud.org/coprs/build/3190970


I hope this is not related to FFI, because gobject-introspection was
mentioned in that context.

I was not able to rebuilt dependent packages due to this, so the



Could you please finish your thoughts? :)

@Mamoru PTAL, I think that Pavel wanted to say that this is precondition to 
build other GTK stuff.


ruby-gnome 3.5.1 "suite" is already released, which will (perhaps) fix this 
issue as
the upstream tests 3.5.1 with ruby31 on github ci, however as ruby-gnome (on 
Fedora) has
~20 gems, I just suspend updating ruby-gnome gems until ruby31 rebuild actually 
starts.



Just note that now I am preparing ruby-gnome 3.5.1 suite for ruby3.1:
https://copr.fedorainfracloud.org/coprs/mtasaka/ruby310-test/builds/

Regards,
Mamoru
___
ruby-sig mailing list -- ruby-sig@lists.fedoraproject.org
To unsubscribe send an email to ruby-sig-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/ruby-sig@lists.fedoraproject.org
Do not reply to spam on the list, report it: 
https://pagure.io/fedora-infrastructure

Re: Mass rebuild failure on rubygems related packages

[Mamoru TASAKA]

Mamoru TASAKA wrote on 2022/01/22 20:28:

Hello, ruby-sig folks:

So looks like there is really a lot of rebuild failure on rubygems related
packages - and many of them contains:

Executing(%build): /bin/sh -e /var/tmp/rpm-tmp.gjYYrb
+ umask 022
+ cd /builddir/build/BUILD
/var/tmp/rpm-tmp.gjYYrb: line 31: syntax error near unexpected token `;'
RPM build errors:

I just noticed this, I will perhaps investigate what has happened, but
if someone can take a look at this beforehand, I really appreciate it.

Maybe... (just a guess) this is related with
https://fedoraproject.org/wiki/Changes/SetBuildFlagsBuildCheck , but
I may be wrong.


So this is https://src.fedoraproject.org/rpms/package-notes/pull-request/1 ,
Vít seems already aware of this, thanks.

So we'll have to rebuild lots of rubygems packages again...

Regards,
Mamoru
___
ruby-sig mailing list -- ruby-sig@lists.fedoraproject.org
To unsubscribe send an email to ruby-sig-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/ruby-sig@lists.fedoraproject.org
Do not reply to spam on the list, report it: 
https://pagure.io/fedora-infrastructure

Mass rebuild failure on rubygems related packages

[Mamoru TASAKA]

Hello, ruby-sig folks:

So looks like there is really a lot of rebuild failure on rubygems related
packages - and many of them contains:

Executing(%build): /bin/sh -e /var/tmp/rpm-tmp.gjYYrb
+ umask 022
+ cd /builddir/build/BUILD
/var/tmp/rpm-tmp.gjYYrb: line 31: syntax error near unexpected token `;'
RPM build errors:

I just noticed this, I will perhaps investigate what has happened, but
if someone can take a look at this beforehand, I really appreciate it.

Maybe... (just a guess) this is related with
https://fedoraproject.org/wiki/Changes/SetBuildFlagsBuildCheck , but
I may be wrong.

Regards,
Mamoru
___
ruby-sig mailing list -- ruby-sig@lists.fedoraproject.org
To unsubscribe send an email to ruby-sig-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/ruby-sig@lists.fedoraproject.org
Do not reply to spam on the list, report it: 
https://pagure.io/fedora-infrastructure

Re: Ruby 3.1 - Mass rebuild

[Mamoru TASAKA]

Vít Ondruch wrote on 2022/01/19 19:54:


Dne 19. 01. 22 v 9:08 Pavel Valena napsal(a):

On Tue, Jan 18, 2022 at 6:39 PM Vít Ondruch  wrote:


Dne 18. 01. 22 v 12:00 Pavel Valena napsal(a):

On Mon, Jan 17, 2022 at 4:27 PM Vít Ondruch  wrote:

Dne 17. 01. 22 v 16:15 Vít Ondruch napsal(a):

Hi,


4)
```
+ ruby -rrubygems -Ilib:test:ext/gio2 test/run-test.rb
glib-compile-resources ruby-gio2.gresource.xml
cd resource
glib-compile-schemas .
cd -
cd schema/default
glib-compile-schemas .
cd -
cd schema/source
cd -
Loaded suite test
Started
../usr/share/gems/gems/gobject-introspection-3.4.9/lib/gobject-introspection/loader.rb:616:
[BUG] Segmentation fault at 0x0>
ruby 3.1.0dev (2021-12-07 master ec878dac90) [x86_64-linux]


```
https://copr.fedorainfracloud.org/coprs/build/3190970


I hope this is not related to FFI, because gobject-introspection was
mentioned in that context.

I was not able to rebuilt dependent packages due to this, so the



Could you please finish your thoughts? :)

@Mamoru PTAL, I think that Pavel wanted to say that this is precondition to 
build other GTK stuff.


ruby-gnome 3.5.1 "suite" is already released, which will (perhaps) fix this 
issue as
the upstream tests 3.5.1 with ruby31 on github ci, however as ruby-gnome (on 
Fedora) has
~20 gems, I just suspend updating ruby-gnome gems until ruby31 rebuild actually 
starts.

Regards,
Mamoru
___
ruby-sig mailing list -- ruby-sig@lists.fedoraproject.org
To unsubscribe send an email to ruby-sig-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/ruby-sig@lists.fedoraproject.org
Do not reply to spam on the list, report it: 
https://pagure.io/fedora-infrastructure

Re: Ruby 3.1 - Mass rebuild

[Mamoru TASAKA]

Vít Ondruch wrote on 2022/01/18 17:15:


Dne 18. 01. 22 v 8:44 Mamoru TASAKA napsal(a):

Vít Ondruch wrote on 2022/01/18 0:15:

Hi,

It is time of the year when new version of Ruby was released upstream and we should land 
it in Fedora. Unfortunately, the change proposal was approved just last Thursday and on 
top of that, rebase of libffi broke Ruby (I am going to disable the failing test cases 
for the moment and hope for the best). So this brings us into situation, where won't have 
enough time prior Fedora Mass rebuild. I have discussed this a bit with relengs and one 
of the options would be to build Ruby early during the mass rebuild and fix the outfall 
later. I shared the proposal in the Fedora Mass rebuild ticket [2]. One downside would be 
that in case of problems, we could not trigger our contingency plan, which is "drop 
our side tag". But I hope we won't need that.

Any thoughts?

My fist concern is that maybe we should build more then just Ruby. rubygem-json 
comes to my mind and possibly rubygem-nokogiri?

Vít


[1] https://bugzilla.redhat.com/show_bug.cgi?id=2040380
[2] https://pagure.io/releng/issue/10538#comment-775197



My light idea is that as "Change Checkpoint" and "Branch Fedora Linux 36 from 
Rawhide" happends
on 2022/Feb/08 (Tue),



Please note that this also marks end of mass rebuild phase.



I think we have enough time even if we start rebuilding with ruby31 beginning 
at,
say, 2022/Jan/24 (Mon) or Jan/25



Right, I agree.



(if mass rebuild "really" begins tomorrow).



Yeah, this worries me, because I think that there used to be delays for past 
several occasions.


Or, once we can determine we wait rebuild until 2022/Jan/24 (Mon) or so on, and
if mass rebuild doesn't go well by that day, we will force ruby rebuild anyway, 
for example.

One note:
At least side-tag build can be done (queued) from the branch other than 
rawhide/main,
(by specifying --release explicitly, like $ fedpkg --release f36 build --target 
f36-build-side-XX )

So you can
- push ruby 3.1 change to ruby.git other than rawhide branch (say ruby31-temp 
branch)
- create side-tag for ruby rebuild, build ruby3.1 on that side-tag from 
ruby.git ruby31-temp branch
- At this time, mass rebuild can happen, but mass rebuild will happen using 
rawhide/main branch,
  so mass rebuild will be done using ruby3.0
- If that happen, merge rawhide and ruby31-temp (anyway), rebuild again on 
ruby31 side-tag
- Then later, push bodhi to merge side-tag builds into rawhide


BTW Is your preference based on your availability or is that just considering 
the schedule and processes or what not?


Well, for my availability, although I cannot spare full time on ruby work (as I have my 
"daily" work),
currently I have no worry for this and I can do rebuild of ruby related srpms 
at my own pace
for the time being.
So I am just considering the schedule for now.


Thx
Vít


Regards,
Mamoru
___
ruby-sig mailing list -- ruby-sig@lists.fedoraproject.org
To unsubscribe send an email to ruby-sig-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/ruby-sig@lists.fedoraproject.org
Do not reply to spam on the list, report it: 
https://pagure.io/fedora-infrastructure

Re: Ruby 3.1 - Mass rebuild

[Mamoru TASAKA]

Vít Ondruch wrote on 2022/01/18 0:15:

Hi,

It is time of the year when new version of Ruby was released upstream and we should land 
it in Fedora. Unfortunately, the change proposal was approved just last Thursday and on 
top of that, rebase of libffi broke Ruby (I am going to disable the failing test cases 
for the moment and hope for the best). So this brings us into situation, where won't have 
enough time prior Fedora Mass rebuild. I have discussed this a bit with relengs and one 
of the options would be to build Ruby early during the mass rebuild and fix the outfall 
later. I shared the proposal in the Fedora Mass rebuild ticket [2]. One downside would be 
that in case of problems, we could not trigger our contingency plan, which is "drop 
our side tag". But I hope we won't need that.

Any thoughts?

My fist concern is that maybe we should build more then just Ruby. rubygem-json 
comes to my mind and possibly rubygem-nokogiri?

Vít


[1] https://bugzilla.redhat.com/show_bug.cgi?id=2040380
[2] https://pagure.io/releng/issue/10538#comment-775197



My light idea is that as "Change Checkpoint" and "Branch Fedora Linux 36 from 
Rawhide" happends
on 2022/Feb/08 (Tue), I think we have enough time even if we start rebuilding 
with ruby31 beginning at,
say, 2022/Jan/24 (Mon) or Jan/25 (if mass rebuild "really" begins tomorrow).

Regards,
Mamoru

___
ruby-sig mailing list -- ruby-sig@lists.fedoraproject.org
To unsubscribe send an email to ruby-sig-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/ruby-sig@lists.fedoraproject.org
Do not reply to spam on the list, report it: 
https://pagure.io/fedora-infrastructure

Re: Status update: updating rubygem-cucumber

[Mamoru TASAKA]

Jarek Prokop wrote on 2022/01/17 7:40:


On 1/14/22 12:40, Mamoru TASAKA wrote:

Hello, all:

Jarek Prokop wrote on 2022/01/13 2:17:

Hi,

On 1/12/22 12:34, Vít Ondruch wrote:

Hi Jarek,

https://src.fedoraproject.org/rpms/rubygem-aruba/pull-request/2


Considering the Aruba ticket ^^, I am not sure if every party understands that 
you are testing the changes in the side-tag (am I correct, right?), you are 
unspecifically referring bellow. So what side-tag are you using?


Right, changes are built & tested using the side-tag: f36-build-side-49108

Already built packages can be viewed here: 
https://koji.fedoraproject.org/koji/builds?order=-tag_name=49108=0=1 
<https://koji.fedoraproject.org/koji/builds?order=-tag_name=49108=0=1>


Now I've pushed rubygem-aruba-2.0.0-2.fc36 into f36-build-side-49108 .
Thanks (especially to Pavel and Jarek) for paying attention to this.
(And sorry for pushing new aruba late.)

I am now trying to rebuild several packages. Note that as Jarek has pointed out
(on rubygem-aruba PR), cucumber 7 now refuses "--tag ~@foo" usage:
several rpms fails to build with cucumber 7 due to this change and need fixing,
e.g.
https://src.fedoraproject.org/rpms/rubygem-rake-compiler/c/c645a03053d3722a575e52d1a6ff494e6a2c6a0f?branch=rawhide


Thanks!

I will start rebuilding the cucumber dependencies with the features tests 
enabled.


Currently, 2 packages are seeing trouble. But I think now f36-build-side-49108 
sidetag can be
merged into f36 main buildroot.

1. rubygem-nifti
Executing rspec and cucumber test suites causes test failure on s390x only 
(note that srpm
itself is noarch), very likely big endian related, so rebuilding rubygem-nifti 
causes build failure
if build happens on s390x arch:

https://koji.fedoraproject.org/koji/taskinfo?taskID=81341629

2. rubygem-cucumber-rails
This seems difficult for me... cucumber testsuite fails (even if I relax 
gemspec dependency) in the way
seemingly difficult.

cucumber testsuite seems to be failing basically by the following code:
```
$ ruby -e "require 'aruba/cucumber'"
/usr/share/gems/gems/aruba-2.0.0/lib/aruba/cucumber/hooks.rb:4:in `': undefined method `World' for main:Object (NoMethodError)
from 
:85:in 
`require'
from 
:85:in 
`require'
from /usr/share/gems/gems/aruba-2.0.0/lib/aruba/cucumber.rb:4:in `'
from 
:160:in 
`require'
from 
:160:in 
`rescue in require'
from 
:149:in 
`require'
from -e:1:in `'
:85:in 
`require': cannot load such file -- aruba/cucumber (LoadError)
from 
:85:in 
`require'
from -e:1:in `'
```
Looks like some initialization is needed before "require 'aruba/cucumber'", 
however currently
I have no idea. Maybe updating to the latest cucumber-rails fixes cucumber 
test, I hope
someone would investigate this further.

Again thanks for work on cucumber update.

Regards,
Mamoru
___
ruby-sig mailing list -- ruby-sig@lists.fedoraproject.org
To unsubscribe send an email to ruby-sig-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/ruby-sig@lists.fedoraproject.org
Do not reply to spam on the list, report it: 
https://pagure.io/fedora-infrastructure

Re: Status update: updating rubygem-cucumber

[Mamoru TASAKA]

Hello, all:

Jarek Prokop wrote on 2022/01/13 2:17:

Hi,

On 1/12/22 12:34, Vít Ondruch wrote:

Hi Jarek,

https://src.fedoraproject.org/rpms/rubygem-aruba/pull-request/2


Considering the Aruba ticket ^^, I am not sure if every party understands that 
you are testing the changes in the side-tag (am I correct, right?), you are 
unspecifically referring bellow. So what side-tag are you using?


Right, changes are built & tested using the side-tag: f36-build-side-49108

Already built packages can be viewed here: 
https://koji.fedoraproject.org/koji/builds?order=-tag_name=49108=0=1 



Now I've pushed rubygem-aruba-2.0.0-2.fc36 into f36-build-side-49108 .
Thanks (especially to Pavel and Jarek) for paying attention to this.
(And sorry for pushing new aruba late.)

I am now trying to rebuild several packages. Note that as Jarek has pointed out
(on rubygem-aruba PR), cucumber 7 now refuses "--tag ~@foo" usage:
several rpms fails to build with cucumber 7 due to this change and need fixing,
e.g.
https://src.fedoraproject.org/rpms/rubygem-rake-compiler/c/c645a03053d3722a575e52d1a6ff494e6a2c6a0f?branch=rawhide


Regards,
Jarek


Regards,
Mamoru
___
ruby-sig mailing list -- ruby-sig@lists.fedoraproject.org
To unsubscribe send an email to ruby-sig-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/ruby-sig@lists.fedoraproject.org
Do not reply to spam on the list, report it: 
https://pagure.io/fedora-infrastructure

Re: Ruby 3.1

[Mamoru TASAKA]

Mamoru TASAKA wrote on 2021/12/06 22:02:

Vít Ondruch wrote on 2021/12/06 20:07:


Dne 03. 12. 21 v 21:36 Pavel Valena napsal(a):

On Fri, Dec 3, 2021 at 2:23 PM Vít Ondruch  wrote:


Dne 03. 12. 21 v 13:40 Pavel Valena napsal(a):

On Fri, Dec 3, 2021 at 1:20 PM Vít Ondruch  wrote:

Dne 03. 12. 21 v 11:47 Pavel Valena napsal(a):

Hello,

I've rebuilt it in my ruby-testing COPR:
https://copr.fedorainfracloud.org/coprs/build/2999821

And I'm also rebuilding dependent packages (`ruby-devel` for now) in
the rubygems-testing COPR:
https://copr.fedorainfracloud.org/coprs/pvalena/rubygems-testing/builds/
(starting with build 3000168)

Nice, thx.



I'll let you know in case there're build failures.

There apparently are build failures.

1) It will probably need some bootstrap round, but

Sure, I'll run the builds several times & build the most needed
packages manually (I also have a script for that; maybe it works).
Reliable build results will come after that.


2) There seems to be something wrong with the binary extensions:

https://download.copr.fedorainfracloud.org/results/pvalena/rubygems-testing/fedora-rawhide-x86_64/03000252-rubygem-eventmachine/build.log.gz

That might be actually related to the issues I had with building rbs and
debug gems. I'll need to investigate.


Interesting, trying eventmachine locally, it works 

There may be newer versions of some gems in my COPR.



That won't be the case, since eventmachine depends just on test-unit.

Vít



https://download.copr.fedorainfracloud.org/results/mtasaka/ruby310-test/fedora-rawhide-x86_64/03006846-rubygem-eventmachine/builder-live.log.gz

```
+ find . -name mkmf.log
+ xargs cat
LD_LIBRARY_PATH=.:/usr/lib64 pkg-config --exists openssl
LD_LIBRARY_PATH=.:/usr/lib64 pkg-config --libs openssl |
=> "-lssl -lcrypto \n"
LD_LIBRARY_PATH=.:/usr/lib64 "gcc -o conftest -I/usr/include 
-I/usr/include/ruby/backward -I/usr/include -I.    -O2 -flto=auto -ffat-lto-objects 
-fexceptions -g -grecord-gcc-switches -pipe -Wall -Werror=format-security 
-Wp,-D_FORTIFY_SOURCE=2 -Wp,-D_GLIBCXX_ASSERTIONS 
-specs=/usr/lib/rpm/redhat/redhat-hardened-cc1 -fstack-protector-strong 
-specs=/usr/lib/rpm/redhat/redhat-annobin-cc1  -m64  -mtune=generic 
-fasynchronous-unwind-tables -fstack-clash-protection -fcf-protection conftest.c  -L. 
-L/usr/lib64 -Wl,-z,relro -Wl,--as-needed  -Wl,-z,now 
-specs=/usr/lib/rpm/redhat/redhat-hardened-ld 
-specs=/usr/lib/rpm/redhat/redhat-annobin-cc1   -m64   -lruby -lz -lpthread -lrt -lrt 
-lgmp -ldl -lcrypt -lm   -lm   -lc"
/usr/bin/ld: cannot find -lz
/usr/bin/ld: cannot find -lgmp
collect2: error: ld returned 1 exit status
checked program was:
/* begin */
1: #include "ruby.h"
2:
3: int main(int argc, char **argv)
4: {
5:   return !!argv[argc];
6: }
/* end */
```

-lz ? -lgmp?

/usr/lib64/ruby/rbconfig.rb (in 
ruby-libs-3.1.0-0.1.20211202gita84dc9d80d.fc36.x86_64) contains:
/usr/lib64/ruby/rbconfig.rb:82:  CONFIG["MAINLIBS"] = "-lz -lpthread -lrt -lrt -lgmp 
-ldl -lcrypt -lm "

So perhaps this is the culprit. Currently it seems all non-noarch builds fail.



Well, "-lz" and "-lgmp" also appears on ruby-libs-3.0.2-151.fc35.x86_64:
82:  CONFIG["MAINLIBS"] = "-lz -lpthread -lrt -lrt -lgmp -ldl -lcrypt -lm "

The "real" difference is perhaps that with ruby-libs-3.1.0-0.1, 
CONFIG["MAINLIBS"] is inherited by
CONFIG["LIBRUBYARG_SHARED"].

ruby-libs-3.1.0-0.1 CONFIG["LIBRUBYARG_SHARED"] says: CONFIG["LIBRUBYARG_SHARED"] = 
"-l$(RUBY_SO_NAME) $(MAINLIBS)"
ruby-libs-3.0.2 CONFIG["LIBRUBYARG_SHARED"] says: CONFIG["LIBRUBYARG_SHARED"] = 
"-l$(RUBY_SO_NAME)"

Regards,
Mamoru


___
ruby-sig mailing list -- ruby-sig@lists.fedoraproject.org
To unsubscribe send an email to ruby-sig-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/ruby-sig@lists.fedoraproject.org
Do not reply to spam on the list, report it: 
https://pagure.io/fedora-infrastructure

Re: Ruby 3.1

[Mamoru TASAKA]

Vít Ondruch wrote on 2021/12/06 20:07:


Dne 03. 12. 21 v 21:36 Pavel Valena napsal(a):

On Fri, Dec 3, 2021 at 2:23 PM Vít Ondruch  wrote:


Dne 03. 12. 21 v 13:40 Pavel Valena napsal(a):

On Fri, Dec 3, 2021 at 1:20 PM Vít Ondruch  wrote:

Dne 03. 12. 21 v 11:47 Pavel Valena napsal(a):

Hello,

I've rebuilt it in my ruby-testing COPR:
https://copr.fedorainfracloud.org/coprs/build/2999821

And I'm also rebuilding dependent packages (`ruby-devel` for now) in
the rubygems-testing COPR:
https://copr.fedorainfracloud.org/coprs/pvalena/rubygems-testing/builds/
(starting with build 3000168)

Nice, thx.



I'll let you know in case there're build failures.

There apparently are build failures.

1) It will probably need some bootstrap round, but

Sure, I'll run the builds several times & build the most needed
packages manually (I also have a script for that; maybe it works).
Reliable build results will come after that.


2) There seems to be something wrong with the binary extensions:

https://download.copr.fedorainfracloud.org/results/pvalena/rubygems-testing/fedora-rawhide-x86_64/03000252-rubygem-eventmachine/build.log.gz

That might be actually related to the issues I had with building rbs and
debug gems. I'll need to investigate.


Interesting, trying eventmachine locally, it works 

There may be newer versions of some gems in my COPR.



That won't be the case, since eventmachine depends just on test-unit.

Vít



https://download.copr.fedorainfracloud.org/results/mtasaka/ruby310-test/fedora-rawhide-x86_64/03006846-rubygem-eventmachine/builder-live.log.gz

```
+ find . -name mkmf.log
+ xargs cat
LD_LIBRARY_PATH=.:/usr/lib64 pkg-config --exists openssl
LD_LIBRARY_PATH=.:/usr/lib64 pkg-config --libs openssl |
=> "-lssl -lcrypto \n"
LD_LIBRARY_PATH=.:/usr/lib64 "gcc -o conftest -I/usr/include 
-I/usr/include/ruby/backward -I/usr/include -I.-O2 -flto=auto -ffat-lto-objects 
-fexceptions -g -grecord-gcc-switches -pipe -Wall -Werror=format-security 
-Wp,-D_FORTIFY_SOURCE=2 -Wp,-D_GLIBCXX_ASSERTIONS 
-specs=/usr/lib/rpm/redhat/redhat-hardened-cc1 -fstack-protector-strong 
-specs=/usr/lib/rpm/redhat/redhat-annobin-cc1  -m64  -mtune=generic 
-fasynchronous-unwind-tables -fstack-clash-protection -fcf-protection conftest.c  -L. 
-L/usr/lib64 -Wl,-z,relro -Wl,--as-needed  -Wl,-z,now 
-specs=/usr/lib/rpm/redhat/redhat-hardened-ld 
-specs=/usr/lib/rpm/redhat/redhat-annobin-cc1   -m64   -lruby -lz -lpthread -lrt -lrt 
-lgmp -ldl -lcrypt -lm   -lm   -lc"
/usr/bin/ld: cannot find -lz
/usr/bin/ld: cannot find -lgmp
collect2: error: ld returned 1 exit status
checked program was:
/* begin */
1: #include "ruby.h"
2:
3: int main(int argc, char **argv)
4: {
5:   return !!argv[argc];
6: }
/* end */
```

-lz ? -lgmp?

/usr/lib64/ruby/rbconfig.rb (in 
ruby-libs-3.1.0-0.1.20211202gita84dc9d80d.fc36.x86_64) contains:
/usr/lib64/ruby/rbconfig.rb:82:  CONFIG["MAINLIBS"] = "-lz -lpthread -lrt -lrt -lgmp 
-ldl -lcrypt -lm "

So perhaps this is the culprit. Currently it seems all non-noarch builds fail.

Regards,
Mamoru
___
ruby-sig mailing list -- ruby-sig@lists.fedoraproject.org
To unsubscribe send an email to ruby-sig-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/ruby-sig@lists.fedoraproject.org
Do not reply to spam on the list, report it: 
https://pagure.io/fedora-infrastructure

Re: rpms/ruby FTBFS with autoconf 2.71

[Mamoru TASAKA]

Jun Aruga wrote on 2021/09/28 1:54:

Just FYI
It seems the rpms/ruby rawhide started to fail to build from the
following build.

https://koschei.fedoraproject.org/build/11069282
autoconf: 2.69-37.fc35 => 2.71-1.fc36

I noticed this when I also saw the build started to fail on the
stream-ruby-2.6 branch too.



I think Vít has already noticed this and contacted the upstream:
https://bugzilla.redhat.com/show_bug.cgi?id=1999479
https://bugs.ruby-lang.org/issues/18156

Regards,
Mamoru
___
ruby-sig mailing list -- ruby-sig@lists.fedoraproject.org
To unsubscribe send an email to ruby-sig-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/ruby-sig@lists.fedoraproject.org
Do not reply to spam on the list, report it: 
https://pagure.io/fedora-infrastructure

Re: Intend to retire rubygem-rspec2 series on Fedora 35

[Mamoru TASAKA]

Hello, all:

Vít Ondruch wrote on 2021/04/07 22:56:


Dne 07. 04. 21 v 13:47 Mamoru TASAKA napsal(a):

Hello, ruby-sig folks:

Since rspec 3.0.0 is released on 2014/Jun (almost 7 years ago),
Fedora's rubygem-rspec is upgraded to 3.x on Fedora 22 era, and compat package
rubygem-rspec2 is introduced.



Finally! :) I was just migrating some packages to RSpec 3.x not long time ago.




Since I think enough time is already passed for packages to migrate to
rspec 3.x and actually:
--
$ dnf repoquery --arch=src --repo=koji-35-source --whatrequires 
"rubygem(rspec2)"
rubygem-database_cleaner-0:1.7.0-5.fc34.src
rubygem-nifti-0:0.0.2-14.fc34.src
rubygem-rspec2-core-0:2.14.8-11.fc34.3.src
rubygem-rspec2-expectations-0:2.14.5-10.fc34.7.src
rubygem-rspec2-mocks-0:2.14.6-6.fc34.6.src

$ dnf repoquery --repo=koji-35 --qf 
'%{name}-%{epoch}:%{version}-%{release}\t%{SOURCERPM}' --whatrequires 
"rubygem-rspec2"
rubygem-json_spec-0:1.1.5-9.fc34 rubygem-json_spec-1.1.5-9.fc34.src.rpm
rubygem-rspec2-doc-0:2.14.1-14.fc34 rubygem-rspec2-2.14.1-14.fc34.src.rpm
--

currently, very few packages depend on rubygem(rspec2).

* rubygem-json_spec actually has dependency: "(rubygem(rspec) >= 2.0 with 
rubygem(rspec) < 4.0)"
  so this is okay
* For rubygem-nifti, I successfully migrated this to use rspec-3.x locally, so 
(unless someone
  objects), I will push changes to use rspec-3.x
* For rubygem-database_cleaner, current upstream newest is 2.0.1, which is 
released on 2021/Feb,
  so the latest one is perhaps using rspec-3.x, I guess.


It seems that 1.8+ should be RSpec3 ready.
https://github.com/DatabaseCleaner/database_cleaner/commit/467ab08e3533ae28692d0d7a64ded41aa934f909



so I intend to retire rubygem-rspec2 series, perhaps in two weeks, or if 
someone objects,
at least I intend to orphan rubygem-rspec2 series on Fedora 35.


LGTM
Vít


Now I've orphaned:
rubygem-rspec2
rubygem-rspec2-core
rubygem-rspec2-expectations
rubygem-rspec2-mocks

Regards,
Mamoru
___
ruby-sig mailing list -- ruby-sig@lists.fedoraproject.org
To unsubscribe send an email to ruby-sig-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/ruby-sig@lists.fedoraproject.org
Do not reply to spam on the list, report it: 
https://pagure.io/fedora-infrastructure

Intend to retire rubygem-rspec2 series on Fedora 35

[Mamoru TASAKA]

Hello, ruby-sig folks:

Since rspec 3.0.0 is released on 2014/Jun (almost 7 years ago),
Fedora's rubygem-rspec is upgraded to 3.x on Fedora 22 era, and compat package
rubygem-rspec2 is introduced.

Since I think enough time is already passed for packages to migrate to
rspec 3.x and actually:
--
$ dnf repoquery --arch=src --repo=koji-35-source --whatrequires 
"rubygem(rspec2)"
rubygem-database_cleaner-0:1.7.0-5.fc34.src
rubygem-nifti-0:0.0.2-14.fc34.src
rubygem-rspec2-core-0:2.14.8-11.fc34.3.src
rubygem-rspec2-expectations-0:2.14.5-10.fc34.7.src
rubygem-rspec2-mocks-0:2.14.6-6.fc34.6.src

$ dnf repoquery --repo=koji-35 --qf 
'%{name}-%{epoch}:%{version}-%{release}\t%{SOURCERPM}' --whatrequires 
"rubygem-rspec2"
rubygem-json_spec-0:1.1.5-9.fc34rubygem-json_spec-1.1.5-9.fc34.src.rpm
rubygem-rspec2-doc-0:2.14.1-14.fc34 rubygem-rspec2-2.14.1-14.fc34.src.rpm
--

currently, very few packages depend on rubygem(rspec2).

* rubygem-json_spec actually has dependency: "(rubygem(rspec) >= 2.0 with 
rubygem(rspec) < 4.0)"
  so this is okay
* For rubygem-nifti, I successfully migrated this to use rspec-3.x locally, so 
(unless someone
  objects), I will push changes to use rspec-3.x
* For rubygem-database_cleaner, current upstream newest is 2.0.1, which is 
released on 2021/Feb,
  so the latest one is perhaps using rspec-3.x, I guess.

so I intend to retire rubygem-rspec2 series, perhaps in two weeks, or if 
someone objects,
at least I intend to orphan rubygem-rspec2 series on Fedora 35.

Regards,
Mamoru
___
ruby-sig mailing list -- ruby-sig@lists.fedoraproject.org
To unsubscribe send an email to ruby-sig-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/ruby-sig@lists.fedoraproject.org
Do not reply to spam on the list, report it: 
https://pagure.io/fedora-infrastructure

Re: F35 Change proposal: RPM 4.17 (System-Wide Change proposal)

[Mamoru TASAKA]

Hello:

Miro Hrončok wrote on 2021/04/01 6:45:

On 31. 03. 21 21:52, Ben Cotton wrote:

* Strict checking for unpackaged content in builds

 > ...

* Many existing packages will fail to build due to the stricter
buildroot content checking. Fixing this in the packaging is always
backwards compatible. We could temporarily set
`%_unpackaged_files_terminate_build 0` in rawhide to alleviate initial
impact if necessary.


This is my main concern with this update.

tl;dr If you %exclude something and there is no other subpackage to own the 
files, the build fails:


This fails:

   %install
   ...
   touch %{buildroot}/foo %{buildroot}/bar

   %files
   /
   %exclude /foo


As the files Miro has attached shows, this affects not a few rubygems related
packages. Many rubygems related packages has: %exclude %gem_cache .

Regards,
Mamoru
___
ruby-sig mailing list -- ruby-sig@lists.fedoraproject.org
To unsubscribe send an email to ruby-sig-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/ruby-sig@lists.fedoraproject.org
Do not reply to spam on the list, report it: 
https://pagure.io/fedora-infrastructure

net-http-persistent 4.0.1 hits rawhide/f34

[Mamoru TASAKA]

Hello, ruby-sig folks:

After a long delay, I've finally updated net-http-persistent to 4.0.1
on rawhide/f34, and also I've modified packages which directly depend on
net-http-persistent:

- rubygem-mechanize : actually not modified
- rubygem-rubygems-mirror:
code itself already supports net-http-persistent >= 3, modified gemspec
dependency
also fixed FTBFS, due to missing BR for webrick (for ruby 3.0 change)
- rubygem-faraday
applied upstream patch to support change on net-http-persistent >= 3
for error status when net connection fails

I think I've done my best, however please try and check the above changes,
thank you!

Regards,
Mamoru
  
___

ruby-sig mailing list -- ruby-sig@lists.fedoraproject.org
To unsubscribe send an email to ruby-sig-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/ruby-sig@lists.fedoraproject.org
Do not reply to spam on the list, report it: 
https://pagure.io/fedora-infrastructure

Re: Orphaned my Ruby packages (Jekyll + dependencies)

[Mamoru TASAKA]

Fabio Valentini wrote on 2021/02/14 4:29:

Hi everybody,

With a heavy heart, I have orphaned all my Ruby packages today.

- rubygem-kramdown-parser-gfm (kramdown support for GitHub-flavored markdown)
- rubygem-kramdown-syntax-coderay (coderay syntax highlighting support)
- rubygem-rouge (jekyll dep, default syntax highlighter, "compatible"
with pygments)
- rubygem-ruby-progressbar
- rubygem-stringex


Taken these (rubygem-kramdown depends on 4 of these, rubygem-nokogiri depends on
rubygem-ruby-progressbar). The packages I am maintaining is getting broader...
 

There are some known issues with the packages:

- Some of them are failing to build on Fedora 34 due to changes in
Ruby 3.0 (jekyll, jekyll-feed, liquid, stringex, tomlrb).


Actually rubygem-stringex test failure is not due to ruby 3.0, but change in
RoR 6.1.x suite and I've fixed this. (I've not checked jekyll or so).


Big thanks to everybody who helped me with maintaining my Ruby
packages over the years.
Fabio


Thank you for maintaining these packages till now.
Regards,
Mamoru
___
ruby-sig mailing list -- ruby-sig@lists.fedoraproject.org
To unsubscribe send an email to ruby-sig-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/ruby-sig@lists.fedoraproject.org
Do not reply to spam on the list, report it: 
https://pagure.io/fedora-infrastructure

Re: Ruby 3.0 - Mass rebuild

[Mamoru TASAKA]

Mamoru TASAKA wrote on 2021/01/07 16:54:

Some test failure
=
  6    rubygem-ox-2.12.1-3.fc33.src.rpm

build fails:
https://koji.fedoraproject.org/koji/taskinfo?taskID=59091142

Failures like:
Error: test_array_multi(Func): FrozenError: can't modify frozen Range: 0..0


Just note that I've reported this: https://github.com/ohler55/ox/issues/258
(latest ox 2.14.0 still fails.)

Regards,
Mamoru
___
ruby-sig mailing list -- ruby-sig@lists.fedoraproject.org
To unsubscribe send an email to ruby-sig-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/ruby-sig@lists.fedoraproject.org

Re: Ruby 3.0 - Mass rebuild

[Mamoru TASAKA]

Mamoru TASAKA wrote on 2021/01/07 22:41:

Mamoru TASAKA wrote on 2021/01/07 16:54:

Current leftovers (wrt library dependency issue):

$ dnf repoquery --repo=koji-ruby30 --qf '%{sourcerpm}' --whatrequires 
"libruby.so.2.7()(64bit)" | cat -n
=
  3    libyui-bindings-2.0.2-1.fc33.src.rpm

build fails:
https://koji.fedoraproject.org/koji/taskinfo?taskID=59088613
/builddir/build/BUILD/libyui-bindings-59dfa64f05adb40c7da88325255d758f4588ab42/x86_64-redhat-linux-gnu/swig/ruby/yui_ruby.cxx:
 In function 'VALUE YEvent_mywidget(YEvent*)':
/builddir/build/BUILD/libyui-bindings-59dfa64f05adb40c7da88325255d758f4588ab42/x86_64-redhat-linux-gnu/swig/ruby/yui_ruby.cxx:3287:77:
 error: invalid conversion from 'YWidget*' to 'long int' [-fpermissive]

Perhaps related to ruby 3.0 change, however for now I don't know in detail.
Note that build for rawhide succeeds:
https://koji.fedoraproject.org/koji/taskinfo?taskID=59089100


Applying the following makes build succeed... however I am not sure if
this is correct approach...
-
--- libyui-bindings-59dfa64f05adb40c7da88325255d758f4588ab42/swig/yui.i.ruby30  
  2021-01-07 16:27:19.835043901 +0900
+++ libyui-bindings-59dfa64f05adb40c7da88325255d758f4588ab42/swig/yui.i    
2021-01-07 17:13:28.648458721 +0900
@@ -275,7 +275,7 @@

  #if defined(SWIGRUBY)
  %extend YEvent {
-  VALUE mywidget() { return INT2FIX( $self->widget() ); }
+  VALUE mywidget() { return INT2FIX( (long)$self->widget() ); }
  }
  #endif



Anyway I've applied the above fix for now and build itself now succeeds:
https://koji.fedoraproject.org/koji/buildinfo?buildID=1666141

Asked upstream for verification:
https://github.com/libyui/libyui-bindings/pull/38

Now current leftovers (using old libruby.so.2.7 library):

$ dnf repoquery --repo=koji-ruby30 --qf '%{sourcerpm}' --whatrequires 
"libruby.so.2.7()(64bit)" | cat -n
 1  libsbml-5.18.0-19.fc34.src.rpm
 2  rubygem-debug_inspector-0.0.3-11.fc33.src.rpm
 3  rubygem-mysql2-0.5.3-5.fc33.src.rpm
 4  rubygem-ox-2.12.1-3.fc33.src.rpm
 5  rubygem-raindrops-0.13.0-18.fc33.src.rpm
 6  rubygem-unicode-0.4.4.2-17.fc33.src.rpm

Regards,
Mamoru
___
ruby-sig mailing list -- ruby-sig@lists.fedoraproject.org
To unsubscribe send an email to ruby-sig-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/ruby-sig@lists.fedoraproject.org

Re: Ruby 3.0 - Mass rebuild

[Mamoru TASAKA]

Mamoru TASAKA wrote on 2021/01/07 16:54:

Current leftovers (wrt library dependency issue):

$ dnf repoquery --repo=koji-ruby30 --qf '%{sourcerpm}' --whatrequires 
"libruby.so.2.7()(64bit)" | cat -n
=
  3    libyui-bindings-2.0.2-1.fc33.src.rpm

build fails:
https://koji.fedoraproject.org/koji/taskinfo?taskID=59088613
/builddir/build/BUILD/libyui-bindings-59dfa64f05adb40c7da88325255d758f4588ab42/x86_64-redhat-linux-gnu/swig/ruby/yui_ruby.cxx:
 In function 'VALUE YEvent_mywidget(YEvent*)':
/builddir/build/BUILD/libyui-bindings-59dfa64f05adb40c7da88325255d758f4588ab42/x86_64-redhat-linux-gnu/swig/ruby/yui_ruby.cxx:3287:77:
 error: invalid conversion from 'YWidget*' to 'long int' [-fpermissive]

Perhaps related to ruby 3.0 change, however for now I don't know in detail.
Note that build for rawhide succeeds:
https://koji.fedoraproject.org/koji/taskinfo?taskID=59089100


Applying the following makes build succeed... however I am not sure if
this is correct approach...
-
--- libyui-bindings-59dfa64f05adb40c7da88325255d758f4588ab42/swig/yui.i.ruby30  
2021-01-07 16:27:19.835043901 +0900
+++ libyui-bindings-59dfa64f05adb40c7da88325255d758f4588ab42/swig/yui.i 
2021-01-07 17:13:28.648458721 +0900
@@ -275,7 +275,7 @@
 
 #if defined(SWIGRUBY)

 %extend YEvent {
-  VALUE mywidget() { return INT2FIX( $self->widget() ); }
+  VALUE mywidget() { return INT2FIX( (long)$self->widget() ); }
 }
 #endif
 
-



=
  7    rubygem-posix-spawn-0.3.13-7.fc33.src.rpm

build fails:
https://koji.fedoraproject.org/koji/taskinfo?taskID=59091190

mv: cannot stat 
'/builddir/build/BUILDROOT/rubygem-posix-spawn-0.3.13-7.fc34.x86_64/usr/share/gems/gems/posix-spawn-0.3.13/lib/posix_spawn_ext.so':
 No such file or directory

Looks like posix_spawn_ext.so is successfully built, but installation 
destination is somehow
wrong.


This was easy. spec file had some script part to check if using ruby-mri is new 
or
not using the minor version of ruby... but minor version of 3.0 is 0...

Just removed old craft, now build succeeds:
https://koji.fedoraproject.org/koji/buildinfo?buildID=1666134

Regards,
Mamoru
___
ruby-sig mailing list -- ruby-sig@lists.fedoraproject.org
To unsubscribe send an email to ruby-sig-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/ruby-sig@lists.fedoraproject.org

Re: Ruby 3.0 - Mass rebuild

[Mamoru TASAKA]

Pavel Valena wrote on 2021/01/07 14:19:



- Original Message -

From: "Vít Ondruch" 
To: ruby-sig@lists.fedoraproject.org
Sent: Wednesday, January 6, 2021 7:23:36 PM
Subject: Re: Ruby 3.0 - Mass rebuild



The PR was merged and should be available in the side tag. Should anybody
package RubyGems plugins, please use the `%{gem_plugin}` macro to own the
RubyGems plugin stub.


I've been creating PRs, mostly, with rexml / webrick dependencies (I'm not 
finished yet).

Mamoru, Vit, thank you for all the builds!


You're welcome!!

Currently 91 packages are using new "libruby.so.3.0()(64bit)" library.
Current leftovers (wrt library dependency issue):

$ dnf repoquery --repo=koji-ruby30 --qf '%{sourcerpm}' --whatrequires 
"libruby.so.2.7()(64bit)" | cat -n
=
 1  kf5-kross-interpreters-20.08.3-1.fc34.src.rpm

build fails:
https://koji.fedoraproject.org/koji/taskinfo?taskID=59090361
/builddir/build/BUILD/kross-interpreters-20.08.3/ruby/rubyinterpreter.cpp:69:5: 
error: 'rb_set_safe_level' was not declared in this scope
   69 | rb_set_safe_level( info->optionValue("safelevel", 
defaultsafelevel).toInt() );

Perhaps simply calling rb_set_safe_level should be removed?
=
 2  libsbml-5.18.0-19.fc34.src.rpm

build fails:
https://koji.fedoraproject.org/koji/taskinfo?taskID=59090995
configure: error: Doxygen version cannot be greater than 1.8.11, but found 
version 1.8.20.

Perhaps not related to ruby
=
 3  libyui-bindings-2.0.2-1.fc33.src.rpm

build fails:
https://koji.fedoraproject.org/koji/taskinfo?taskID=59088613
/builddir/build/BUILD/libyui-bindings-59dfa64f05adb40c7da88325255d758f4588ab42/x86_64-redhat-linux-gnu/swig/ruby/yui_ruby.cxx:
 In function 'VALUE YEvent_mywidget(YEvent*)':
/builddir/build/BUILD/libyui-bindings-59dfa64f05adb40c7da88325255d758f4588ab42/x86_64-redhat-linux-gnu/swig/ruby/yui_ruby.cxx:3287:77:
 error: invalid conversion from 'YWidget*' to 'long int' [-fpermissive]

Perhaps related to ruby 3.0 change, however for now I don't know in detail.
Note that build for rawhide succeeds:
https://koji.fedoraproject.org/koji/taskinfo?taskID=59089100
=
 4  rubygem-debug_inspector-0.0.3-11.fc33.src.rpm

build fails:
https://koji.fedoraproject.org/koji/taskinfo?taskID=59090797
current directory: 
/builddir/build/BUILD/debug_inspector-0.0.3/usr/share/gems/gems/debug_inspector-0.0.3/ext/debug_inspector
"make \"DESTDIR=\" clean"
make: *** No rule to make target 'clean'.  Stop.
current directory: 
/builddir/build/BUILD/debug_inspector-0.0.3/usr/share/gems/gems/debug_inspector-0.0.3/ext/debug_inspector
"make \"DESTDIR=\""
echo "Nada."
Nada.

Perhaps building ruby extension is really failing
=
 5  rubygem-mysql2-0.5.3-5.fc33.src.rpm

build fails:
https://koji.fedoraproject.org/koji/taskinfo?taskID=59090805

Failures:
  1) Mysql2::Error encoding returns error messages as UTF-8 by default
  2) Mysql2::Statement should create a statement
  3) Mysql2::Statement close should free server resources

Some test failure
=
 6  rubygem-ox-2.12.1-3.fc33.src.rpm

build fails:
https://koji.fedoraproject.org/koji/taskinfo?taskID=59091142

Failures like:
Error: test_array_multi(Func): FrozenError: can't modify frozen Range: 0..0
=
 7  rubygem-posix-spawn-0.3.13-7.fc33.src.rpm

build fails:
https://koji.fedoraproject.org/koji/taskinfo?taskID=59091190

mv: cannot stat 
'/builddir/build/BUILDROOT/rubygem-posix-spawn-0.3.13-7.fc34.x86_64/usr/share/gems/gems/posix-spawn-0.3.13/lib/posix_spawn_ext.so':
 No such file or directory

Looks like posix_spawn_ext.so is successfully built, but installation 
destination is somehow
wrong.

=
 8  rubygem-raindrops-0.13.0-18.fc33.src.rpm

build fails:
https://koji.fedoraproject.org/koji/taskinfo?taskID=59091207

Many:
TypeError: no implicit conversion of Hash into Integer
=
 9  rubygem-unicode-0.4.4.2-17.fc33.src.rpm

build fails:
https://koji.fedoraproject.org/koji/taskinfo?taskID=59090709

armv7hl only: document generation segfaults:
Installing darkfish documentation for unicode-0.4.4.2
/usr/share/gems/gems/rdoc-6.3.0/lib/rdoc/markup/to_html.rb:226: [BUG] 
Segmentation fault at 0xb2654000
ruby 3.0.0p0 (2020-12-25 revision 95aff21468) [armv7hl-linux]


So currently, packages still using "libruby.so.2.7()(64bit)" (9 packages) all 
fails to build,
and (as I've said above) 91 packages are using new "libruby.so.3.0()(64bit)" 
library.

I think we can merge side build into rawhide main 

rspec suite 3.10 hits rawhide

[Mamoru TASAKA]

Hello, ruby-sig folks:

Before upcoming F-34 mass build, I've upgraded rubygem-rspec suite to
3.10.0.
I don't expect any significant difference from 3.9.x as far as I looked at
the code briefly, but please test your packages with new rspec.

Regards,
Mamoru
___
ruby-sig mailing list -- ruby-sig@lists.fedoraproject.org
To unsubscribe send an email to ruby-sig-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/ruby-sig@lists.fedoraproject.org

Re: Ruby 3.0

[Mamoru TASAKA]

Mamoru TASAKA wrote on 2020/11/13 19:18:

Vít Ondruch wrote on 2020/11/13 17:46:


Dne 13. 11. 20 v 3:56 Pavel Valena napsal(a):

- Original Message -

From: "Pavel Valena" 
To: "Dan Čermák" 
Cc: "Ruby SIG mailing list" 
Sent: Thursday, November 5, 2020 8:30:25 PM
Subject: Re: Ruby 3.0

- Original Message -

From: "Dan Čermák" 
To: "Vít Ondruch" 
Cc: ruby-sig@lists.fedoraproject.org
Sent: Thursday, November 5, 2020 4:41:46 PM
Subject: Re: Ruby 3.0

Hi Vít,

Vít Ondruch  writes:


Hi all,

Here is once again freshly updated Ruby. The changes are available here:

https://src.fedoraproject.org/rpms/ruby/pull-request/70

and you can find the scratch build in Koji:

https://koji.fedoraproject.org/koji/taskinfo?taskID=54978639

  From the notable changes, there is ongoing effort to gemify StdLib.

As always, please let me know if you encounter any issues with the
package.

It seems I'm still not able to build gems like eventmachine:



I wonder what precisely is "gems like eventmachine"




    
https://download.copr.fedorainfracloud.org/results/pvalena/rubygems-testing/fedora-rawhide-x86_64/01767294-rubygem-eventmachine/builder-live.log.gz
    
https://copr.fedorainfracloud.org/coprs/pvalena/rubygems-testing/build/1767294/

Error I'm getting is
``` make: I.: No such file or directory ```
  note the missing -



I think the issue is not in the `-` but in what is missing prior it. If you see 
this line, isn't there something strange?

~~~

I. -I/usr/include -I/usr/include/ruby/backward -I/usr/include -I. 
-DHAVE_OPENSSL_SSL_H -DHAVE_OPENSSL_ERR_H -DWITH_SSL -DBUILD_FOR_RUBY 
-DHAVE_RB_THREAD_CALL_WITHOUT_GVL -DHAVE_RB_THREAD_FD_SELECT 
-DHAVE_TYPE_RB_FDSET_T -DHAVE_RB_WAIT_FOR_SINGLE_FD -DHAVE_RB_TIME_NEW 
-DHAVE_INOTIFY_INIT -DHAVE_INOTIFY -DHAVE_WRITEV -DHAVE_PIPE2 -DHAVE_ACCEPT4 
-DHAVE_CONST_SOCK_CLOEXEC -DOS_UNIX -DHAVE_EPOLL_CREATE -DHAVE_EPOLL 
-DHAVE_CLOCK_GETTIME -DHAVE_CONST_CLOCK_MONOTONIC_RAW 
-DHAVE_CONST_CLOCK_MONOTONIC -fPIC -O2 -flto=auto -ffat-lto-objects 
-fexceptions -g -grecord-gcc-switches -pipe -Wall -Werror=format-security 
-Wp,-D_FORTIFY_SOURCE=2 -Wp,-D_GLIBCXX_ASSERTIONS 
-specs=/usr/lib/rpm/redhat/redhat-hardened-cc1 -fstack-protector-strong 
-specs=/usr/lib/rpm/redhat/redhat-annobin-cc1 -m64 -mtune=generic 
-fasynchronous-unwind-tables -fstack-clash-protection -fcf-protection  -m64 -o 
binder.o -c binder.cpp

~~~


For comparison, the same line from last official Fedora build:


~~~

g++ -I. -I/usr/include -I/usr/include/ruby/backward -I/usr/include -I. 
-DHAVE_OPENSSL_SSL_H -DHAVE_OPENSSL_ERR_H -DWITH_SSL -DBUILD_FOR_RUBY 
-DHAVE_RB_THREAD_CALL_WITHOUT_GVL -DHAVE_RB_THREAD_FD_SELECT 
-DHAVE_TYPE_RB_FDSET_T -DHAVE_RB_WAIT_FOR_SINGLE_FD -DHAVE_RB_TIME_NEW 
-DHAVE_INOTIFY_INIT -DHAVE_INOTIFY -DHAVE_WRITEV -DHAVE_PIPE2 -DHAVE_ACCEPT4 
-DHAVE_CONST_SOCK_CLOEXEC -DOS_UNIX -DHAVE_EPOLL_CREATE -DHAVE_EPOLL 
-DHAVE_CLOCK_GETTIME -DHAVE_CONST_CLOCK_MONOTONIC_RAW 
-DHAVE_CONST_CLOCK_MONOTONIC -DHAVE_MAKE_PAIR    -fPIC -O2 -flto=auto 
-ffat-lto-objects -fexceptions -g -grecord-gcc-switches -pipe -Wall 
-Werror=format-security -Wp,-D_FORTIFY_SOURCE=2 -Wp,-D_GLIBCXX_ASSERTIONS 
-specs=/usr/lib/rpm/redhat/redhat-hardened-cc1 -fstack-protector-strong 
-specs=/usr/lib/rpm/redhat/redhat-annobin-cc1 -m64 -mtune=generic 
-fasynchronous-unwind-tables -fstack-clash-protection -fcf-protection  -m64 -o 
binder.o -c binder.cpp

~~~


If you checked the Makefile, these are the corresponding lines:


~~~

.cpp.o:
 $(ECHO) compiling $(<)
 $(Q) $(CXX) $(INCFLAGS) $(CPPFLAGS) $(CXXFLAGS) $(COUTFLAG)$@ -c 
$(CSRCFLAG)$<

~~~


And


~~~

CXX =

~~~


So one of the reasons is that we don't have C++ compiler available during Ruby 
build and therefore there are not stored the appropriate values into RbConfig 
(I mildly remember, that there could have been also patch to remove the need 
for C++ or it was reported somewhere, but I don't remember more details).

The other reason is that somebody changed something somewhere and apparently 
something relies on it. The question is what. I would appreciate if somebody 
helped me to understand what have changed.

One could also expect, that the extconf.rb + mkmf would include check for 
compiler availability and let the compilation fail earlier, but this is not the 
case unfortunately. So if somebody could investigate, if eventmachine and 
possibly also other package could check on compiler availability, that could 
help to prevent non-obvious issues like this.

Checking the mkmf.log, it is also interesting to see, that most of the 
configuration check are done using `gcc`, while there also other checks:

~~~

" -o conftest -I/usr/include -I/usr/include/ruby/backward -I/usr/include -I. -O2 
-flto=auto -ffat-lto-objects -fexceptions -g -grecord-gcc-switches -pipe -Wall 
-Werror=format-security -Wp,-D_FORTIFY_SOURCE=2 -Wp,-D_GLIBCXX_ASSERTIONS 
-specs=/usr/lib/rpm/redhat/redhat-h

Re: Ruby 3.0

[Mamoru TASAKA]

Vít Ondruch wrote on 2020/11/13 17:46:


Dne 13. 11. 20 v 3:56 Pavel Valena napsal(a):

- Original Message -

From: "Pavel Valena" 
To: "Dan Čermák" 
Cc: "Ruby SIG mailing list" 
Sent: Thursday, November 5, 2020 8:30:25 PM
Subject: Re: Ruby 3.0

- Original Message -

From: "Dan Čermák" 
To: "Vít Ondruch" 
Cc: ruby-sig@lists.fedoraproject.org
Sent: Thursday, November 5, 2020 4:41:46 PM
Subject: Re: Ruby 3.0

Hi Vít,

Vít Ondruch  writes:


Hi all,

Here is once again freshly updated Ruby. The changes are available here:

https://src.fedoraproject.org/rpms/ruby/pull-request/70

and you can find the scratch build in Koji:

https://koji.fedoraproject.org/koji/taskinfo?taskID=54978639

  From the notable changes, there is ongoing effort to gemify StdLib.

As always, please let me know if you encounter any issues with the
package.

It seems I'm still not able to build gems like eventmachine:



I wonder what precisely is "gems like eventmachine"




    
https://download.copr.fedorainfracloud.org/results/pvalena/rubygems-testing/fedora-rawhide-x86_64/01767294-rubygem-eventmachine/builder-live.log.gz
    
https://copr.fedorainfracloud.org/coprs/pvalena/rubygems-testing/build/1767294/

Error I'm getting is
``` make: I.: No such file or directory ```
  note the missing -



I think the issue is not in the `-` but in what is missing prior it. If you see 
this line, isn't there something strange?

~~~

I. -I/usr/include -I/usr/include/ruby/backward -I/usr/include -I. 
-DHAVE_OPENSSL_SSL_H -DHAVE_OPENSSL_ERR_H -DWITH_SSL -DBUILD_FOR_RUBY 
-DHAVE_RB_THREAD_CALL_WITHOUT_GVL -DHAVE_RB_THREAD_FD_SELECT 
-DHAVE_TYPE_RB_FDSET_T -DHAVE_RB_WAIT_FOR_SINGLE_FD -DHAVE_RB_TIME_NEW 
-DHAVE_INOTIFY_INIT -DHAVE_INOTIFY -DHAVE_WRITEV -DHAVE_PIPE2 -DHAVE_ACCEPT4 
-DHAVE_CONST_SOCK_CLOEXEC -DOS_UNIX -DHAVE_EPOLL_CREATE -DHAVE_EPOLL 
-DHAVE_CLOCK_GETTIME -DHAVE_CONST_CLOCK_MONOTONIC_RAW 
-DHAVE_CONST_CLOCK_MONOTONIC -fPIC -O2 -flto=auto -ffat-lto-objects 
-fexceptions -g -grecord-gcc-switches -pipe -Wall -Werror=format-security 
-Wp,-D_FORTIFY_SOURCE=2 -Wp,-D_GLIBCXX_ASSERTIONS 
-specs=/usr/lib/rpm/redhat/redhat-hardened-cc1 -fstack-protector-strong 
-specs=/usr/lib/rpm/redhat/redhat-annobin-cc1 -m64 -mtune=generic 
-fasynchronous-unwind-tables -fstack-clash-protection -fcf-protection  -m64 -o 
binder.o -c binder.cpp

~~~


For comparison, the same line from last official Fedora build:


~~~

g++ -I. -I/usr/include -I/usr/include/ruby/backward -I/usr/include -I. 
-DHAVE_OPENSSL_SSL_H -DHAVE_OPENSSL_ERR_H -DWITH_SSL -DBUILD_FOR_RUBY 
-DHAVE_RB_THREAD_CALL_WITHOUT_GVL -DHAVE_RB_THREAD_FD_SELECT 
-DHAVE_TYPE_RB_FDSET_T -DHAVE_RB_WAIT_FOR_SINGLE_FD -DHAVE_RB_TIME_NEW 
-DHAVE_INOTIFY_INIT -DHAVE_INOTIFY -DHAVE_WRITEV -DHAVE_PIPE2 -DHAVE_ACCEPT4 
-DHAVE_CONST_SOCK_CLOEXEC -DOS_UNIX -DHAVE_EPOLL_CREATE -DHAVE_EPOLL 
-DHAVE_CLOCK_GETTIME -DHAVE_CONST_CLOCK_MONOTONIC_RAW 
-DHAVE_CONST_CLOCK_MONOTONIC -DHAVE_MAKE_PAIR    -fPIC -O2 -flto=auto 
-ffat-lto-objects -fexceptions -g -grecord-gcc-switches -pipe -Wall 
-Werror=format-security -Wp,-D_FORTIFY_SOURCE=2 -Wp,-D_GLIBCXX_ASSERTIONS 
-specs=/usr/lib/rpm/redhat/redhat-hardened-cc1 -fstack-protector-strong 
-specs=/usr/lib/rpm/redhat/redhat-annobin-cc1 -m64 -mtune=generic 
-fasynchronous-unwind-tables -fstack-clash-protection -fcf-protection  -m64 -o 
binder.o -c binder.cpp

~~~


If you checked the Makefile, these are the corresponding lines:


~~~

.cpp.o:
     $(ECHO) compiling $(<)
     $(Q) $(CXX) $(INCFLAGS) $(CPPFLAGS) $(CXXFLAGS) $(COUTFLAG)$@ -c 
$(CSRCFLAG)$<

~~~


And


~~~

CXX =

~~~


So one of the reasons is that we don't have C++ compiler available during Ruby 
build and therefore there are not stored the appropriate values into RbConfig 
(I mildly remember, that there could have been also patch to remove the need 
for C++ or it was reported somewhere, but I don't remember more details).

The other reason is that somebody changed something somewhere and apparently 
something relies on it. The question is what. I would appreciate if somebody 
helped me to understand what have changed.

One could also expect, that the extconf.rb + mkmf would include check for 
compiler availability and let the compilation fail earlier, but this is not the 
case unfortunately. So if somebody could investigate, if eventmachine and 
possibly also other package could check on compiler availability, that could 
help to prevent non-obvious issues like this.

Checking the mkmf.log, it is also interesting to see, that most of the 
configuration check are done using `gcc`, while there also other checks:

~~~

" -o conftest -I/usr/include -I/usr/include/ruby/backward -I/usr/include -I. -O2 
-flto=auto -ffat-lto-objects -fexceptions -g -grecord-gcc-switches -pipe -Wall 
-Werror=format-security -Wp,-D_FORTIFY_SOURCE=2 -Wp,-D_GLIBCXX_ASSERTIONS 
-specs=/usr/lib/rpm/redhat/redhat-hardened-cc1 -fstack-protector-strong 
-specs=/usr/lib/rpm/redhat/redhat-annobin-cc1  -m64 -mtune=generic 

orphaning rubygem-kramdown on EPEL

[Mamoru TASAKA]

Hello, ruby-sig folks:

rubygem-kramdown before 2.3.0 has security issue assigned as CVE-2020-14001 :
https://bugzilla.redhat.com/show_bug.cgi?id=1858395 ,
so I've pushed updates rubygem-kramdown-2.2.1-4.fc32 for Fedora 32, and
rubygem-kramdown-1.17.0-6.fc31 for Fedora 31.

For EPEL(7), as I've repeatedly said I didn't maintain any packages on EPEL,
however as somehow EPEL updates request was assigned to me :
https://bugzilla.redhat.com/show_bug.cgi?id=1858415
I've created  rubygem-kramdown-1.9.0-2.el7 updates which was pushed to stable
yesterday - however it seems there was some mistakes on the patch I've applied:

https://bugzilla.redhat.com/show_bug.cgi?id=1889144

So as I've thought before I am afraid that I should not maintain packages on 
EPEL,
so once I've orphaned rubygem-kramdown on EPEL. I hope that someone who really 
uses
EPEL can take care of this. Note that I'll keep maintaining rubygem-kramdown on
Fedora branches.

Regards,
Mamoru
___
ruby-sig mailing list -- ruby-sig@lists.fedoraproject.org
To unsubscribe send an email to ruby-sig-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/ruby-sig@lists.fedoraproject.org

Re: Ruby 3.0

[Mamoru TASAKA]

Pavel Valena wrote on 2020/10/13 21:00:

- Original Message -

From: "Vít Ondruch" 
To: ruby-sig@lists.fedoraproject.org
Sent: Friday, October 9, 2020 1:52:07 PM
Subject: Re: Ruby 3.0

Hi all,

Another update to the most recent version of Ruby 3.0 is here:

https://src.fedoraproject.org/rpms/ruby/pull-request/70

https://koji.fedoraproject.org/koji/taskinfo?taskID=53075655

The main difference is RubyGems patch fixing issues with build of
rubygem- packages pvalena encountered in Copr. Apart of that, there is
ongoing StdLib gemification.

As always, I'm looking for any feedback.


Hello,

I've rebuilt your ruby in my ruby-testing copr repo, and I'm building (almost) 
all rubygem-* packages on top of it in my rubygems-testing corp repo.

This time, it was more successful. I only had to remove `racc` requirement from 
Nokogiri so far (colliding with ruby-default-gems).
   
https://download.copr.fedorainfracloud.org/results/pvalena/rubygems-testing/fedora-rawhide-x86_64/01705314-rubygem-nokogiri/builder-live.log.gz

All build results can be found here:
   https://copr.fedorainfracloud.org/coprs/pvalena/rubygems-testing/builds/

I'm looking into the failed ones, and rebuilding those which can be, as their 
dependencies got fullfiled.

One 'interesting' failure is a gem with native extension:
   
https://download.copr.fedorainfracloud.org/results/pvalena/rubygems-testing/fedora-rawhide-x86_64/01705801-rubygem-eventmachine/builder-live.log.gz
   (It builds fine in rawhide.)

Pavel


Looks like with Vít's ruby 3.0 scratch build (taskID=53075655),
CONFIG["CXX"] is not set ( in /usr/lib64/ruby/rbconfig.rb on x86_64), while
with ruby-libs-2.7.1-134.fc33.x86_64, CONFIG["CXX"] is correctly set as g++.

rubygem-eventmachine uses CONFIG["CXX"] to find c++ compiler, so it seems
currently eventmachine cannot find c++ compiler.



Vít



Regards,
Mamoru
___
ruby-sig mailing list -- ruby-sig@lists.fedoraproject.org
To unsubscribe send an email to ruby-sig-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/ruby-sig@lists.fedoraproject.org

Re: Ruby 2.7 - Mass rebuild

[Mamoru TASAKA]

Mamoru TASAKA wrote on 2020/01/18 15:33:

Vít Ondruch wrote on 2020/01/17 0:00:

Hi everybody,

This years schedule does not give us too much freedom, because the
Fedora mass rebuild is scheduled for the 22nd of January, which is in a
few days. There are also some concerns with keyword arguments, but since
I have no idea how problematic this might be, I decided to give it a go.
It seems that nowadays, everybody is able to ask for side tag via
`fedpkg` so I acquired one:




Thank you (and thanks to other people) for excellent works to bring
ruby 2.7 into Fedora 32. As Vít says, the rebuilt packages can be seen on:
https://koji.fedoraproject.org/koji/builds?inherited=0=17977=-build_id=1

92 packages were already rebuilt.

Current rebuild leftovers (with regards to library dependency) are:


     16    subversion-1.12.2-3.fc32.src.rpm

https://koji.fedoraproject.org/koji/taskinfo?taskID=40681152
Well, some linkage or macro expanding error??
/usr/share/rubygems/rubygems/core_ext/kernel_require.rb:92:in `require': 
/builddir/build/BUILD/subversion-1.12.2/subversion/bindings/swig/ruby/libsvn_swig_ruby/.l
ibs/libsvn_swig_ruby-1.so.0: undefined symbol: assert - 
/builddir/build/BUILD/subversion-1.12.2/subversion/bindings/swig/ruby/.ext/svn/ext/core.so
 (LoadError)



For subversion, the reason of the above error which is related to ruby2.7
is found and I pushed the (maybe-tentative) solution to git.
Unfortunately now build of subversion for rawhide fails on some test,
only on i686 and armv7hl, which I believe is unrelated to ruby2.7 change
but is related to some other thing. (Note that builds on f31 is successful.)

So anyway I pushed build on rawhide so that subversion maintainer can
investigate the current status.

https://koji.fedoraproject.org/koji/buildinfo?buildID=1431029

Regards,
Mamoru
___
ruby-sig mailing list -- ruby-sig@lists.fedoraproject.org
To unsubscribe send an email to ruby-sig-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/ruby-sig@lists.fedoraproject.org

Re: Ruby 2.7 - Mass rebuild

[Mamoru TASAKA]

Vít Ondruch wrote on 2020/01/20 22:24:


Dne 20. 01. 20 v 14:02 Vít Ondruch napsal(a):

Hi Mamoru,


Dne 20. 01. 20 v 12:37 Mamoru TASAKA napsal(a):

Mamoru TASAKA wrote on 2020/01/18 15:33:

Thank you (and thanks to other people) for excellent works to bring
ruby 2.7 into Fedora 32. As Vít says, the rebuilt packages can be
seen on:
https://koji.fedoraproject.org/koji/builds?inherited=0=17977=-build_id=1


92 packages were already rebuilt.

Current rebuild leftovers (with regards to library dependency) are:


Status update: currently leftovers are:

$ dnf repoquery --disablerepo=\* --enablerepo=koji-ruby27 --qf
"%{sourcerpm}" --whatrequires "libruby.so.2.6()(64bit)" | sort | uniq
| cat -n
  1    nbdkit-1.17.5-1.fc32.src.rpm
  2    rubygem-curb-0.9.10-1.fc32.src.rpm
  3    rubygem-ffi-1.10.0-3.fc31.src.rpm
  4    rubygem-qpid_messaging-1.39.0-4.fc31.src.rpm
  5    rubygem-thin-1.7.2-11.fc31.src.rpm
  6    subversion-1.12.2-3.fc32.src.rpm
  7    weechat-2.4-4.fc32.src.rpm

As rubygem-qpid_messaging (dependency retired) and weechat (source
broken) cannot be fixed
due to the issues completely unrelated to ruby27 change, I think now
it is already
good time to get the rebuilt package merged into f32 buildroot.


Thank you for the heavy lifting and of course all others who helped with
the rebuild. I have asked relengs to merge the side tag back to master:

https://pagure.io/releng/issue/9179


I was told to merge the side tag via Bodhi, so here is the update:

https://bodhi.fedoraproject.org/updates/FEDORA-2020-223644200d

However I am not sure how it really gets merged, because it is in
Pending state now, whatever it means ...
 

Vít



Okay, now side-builds packages are merged into f32 buildroot (and newrepo
for f32 including ruby27 finished). (I updated the packages' entry of
the bodhi update Vít created to include new hivex and libguestfs, and
now bodhi pushed packages into f32)

Again thanks to all people for bringing ruby27 into Fedora 32.

Regards,
Mamoru
___
ruby-sig mailing list -- ruby-sig@lists.fedoraproject.org
To unsubscribe send an email to ruby-sig-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/ruby-sig@lists.fedoraproject.org

Re: Ruby 2.7 - Mass rebuild

[Mamoru TASAKA]

Mamoru TASAKA wrote on 2020/01/18 15:33:


Thank you (and thanks to other people) for excellent works to bring
ruby 2.7 into Fedora 32. As Vít says, the rebuilt packages can be seen on:
https://koji.fedoraproject.org/koji/builds?inherited=0=17977=-build_id=1

92 packages were already rebuilt.

Current rebuild leftovers (with regards to library dependency) are:


Status update: currently leftovers are:

$ dnf repoquery --disablerepo=\* --enablerepo=koji-ruby27 --qf "%{sourcerpm}" 
--whatrequires "libruby.so.2.6()(64bit)" | sort | uniq | cat -n
 1  nbdkit-1.17.5-1.fc32.src.rpm
 2  rubygem-curb-0.9.10-1.fc32.src.rpm
 3  rubygem-ffi-1.10.0-3.fc31.src.rpm
 4  rubygem-qpid_messaging-1.39.0-4.fc31.src.rpm
 5  rubygem-thin-1.7.2-11.fc31.src.rpm
 6  subversion-1.12.2-3.fc32.src.rpm
 7  weechat-2.4-4.fc32.src.rpm

As rubygem-qpid_messaging (dependency retired) and weechat (source broken) 
cannot be fixed
due to the issues completely unrelated to ruby27 change, I think now it is 
already
good time to get the rebuilt package merged into f32 buildroot.

Regards,
Mamoru
___
ruby-sig mailing list -- ruby-sig@lists.fedoraproject.org
To unsubscribe send an email to ruby-sig-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/ruby-sig@lists.fedoraproject.org

Re: Ruby 2.7 - Mass rebuild

[Mamoru TASAKA]

Mamoru TASAKA wrote on 2020/01/18 15:33:


     14    rubygem-qpid_messaging-1.39.0-4.fc31.src.rpm
DEBUG util.py:596:  No matching package to install: 'qpid-cpp-client-devel'
DEBUG util.py:596:  Not all dependencies satisfied
Looks line qpid-cpp is retired, someone needs taking care of depending package
maintainership.


Link:
https://koji.fedoraproject.org/koji/taskinfo?taskID=40681069

Regards,
Mamoru
___
ruby-sig mailing list -- ruby-sig@lists.fedoraproject.org
To unsubscribe send an email to ruby-sig-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/ruby-sig@lists.fedoraproject.org

Re: Ruby 2.7 - Mass rebuild

[Mamoru TASAKA]

Vít Ondruch wrote on 2020/01/17 0:00:

Hi everybody,

This years schedule does not give us too much freedom, because the
Fedora mass rebuild is scheduled for the 22nd of January, which is in a
few days. There are also some concerns with keyword arguments, but since
I have no idea how problematic this might be, I decided to give it a go.
It seems that nowadays, everybody is able to ask for side tag via
`fedpkg` so I acquired one:




Thank you (and thanks to other people) for excellent works to bring
ruby 2.7 into Fedora 32. As Vít says, the rebuilt packages can be seen on:
https://koji.fedoraproject.org/koji/builds?inherited=0=17977=-build_id=1

92 packages were already rebuilt.

Current rebuild leftovers (with regards to library dependency) are:

$ dnf repoquery --disablerepo=\* --enablerepo=koji-ruby27 --qf "%{sourcerpm}" 
--whatrequires "libruby.so.2.6()(64bit)" | sort | uniq | cat -n

 1  graphviz-2.42.2-4.fc32.src.rpm
https://koji.fedoraproject.org/koji/taskinfo?taskID=40688927
gv_ruby.cpp: In function 'void SWIG_RubyInitializeTrackings()':
gv_ruby.cpp:1267:85: error: call of overloaded 'rb_define_virtual_variable(const 
char [21], VALUE (&)(...), NULL)' is ambiguous
 1267 |   rb_define_virtual_variable("SWIG_TRACKINGS_COUNT", 
swig_ruby_trackings_count, NULL);
  | 
^
In file included from /usr/include/ruby/ruby.h:2863,
 from /usr/include/ruby.h:33,
 from gv_ruby.cpp:880:
/usr/include/ruby/backward/cxxanyargs.hpp:59:1: note: candidate: 'void 
ruby::backward::cxxanyargs::rb_define_virtual_variable(const char*, VALUE 
(*)(...), void (*)(...))'
   59 | rb_define_virtual_variable(const char *q, type *w, void_type *e)
  | ^~
/usr/include/ruby/backward/cxxanyargs.hpp:90:1: note: candidate: 'void 
ruby::backward::cxxanyargs::rb_define_virtual_variable(const char*, VALUE 
(*)(...), void (*)(VALUE, ID, VALUE*))'
   90 | rb_define_virtual_variable(const char *q, type *w, rb_gvar_setter_t *e)
  | ^~

Looks like this is below and it seems swig needs patching.
https://github.com/swig/swig/issues/1689
https://github.com/swig/swig/pull/1692/commits/00e291b319bd6b58bf061feee3721a58c9c6be32

 2  libprelude-5.1.1-2.fc32.src.rpm
https://koji.fedoraproject.org/koji/taskinfo?taskID=40688760
Looks like the same issue as graphviz.
Prelude.cxx:1263:85: error: call of overloaded 'rb_define_virtual_variable(const 
char [21], VALUE (&)(...), NULL)' is ambiguous

 3  libsbml-5.18.0-9.fc32.src.rpm
https://koji.fedoraproject.org/koji/taskinfo?taskID=40688622
Looks like the same issue as graphviz.
/builddir/build/BUILD/libSBML-5.18.0-Source/build/src/bindings/ruby/libsbml_wrap.cpp:1268:85:
 error: call of overloaded 'rb_define_virtual_variable(const char [21], VALUE 
(&)(...), NULL)' is ambiguous

 4  libsedml-0.4.4-7.fc32.src.rpm
https://koji.fedoraproject.org/koji/taskinfo?taskID=40688515
Looks like the same issue as graphviz.
/builddir/build/BUILD/libSEDML-0.4.4/build/bindings/ruby/libsedml_wrap.cpp:1268:85: 
error: call of overloaded 'rb_define_virtual_variable(const char [21], VALUE 
(&)(...), NULL)' is ambiguous

 5  libyui-bindings-1.1.2-19.fc32.src.rpm
https://koji.fedoraproject.org/koji/taskinfo?taskID=40685537
Looks like the same issue as graphviz.
/builddir/build/BUILD/libyui-bindings-1.1.2/build-x86_64-redhat-linux-gnu/swig/ruby/yui_ruby.cxx:1267:85:
 error: call of overloaded 'rb_define_virtual_variable(const char [21], VALUE 
(&)(...), NULL)' is ambiguous

 6  marisa-0.2.4-42.fc32.src.rpm
https://koji.fedoraproject.org/koji/taskinfo?taskID=40685286
Looks like the same issue as graphviz.
marisa-swig_wrap.cxx:1267:85: error: call of overloaded 
'rb_define_virtual_variable(const char [21], VALUE (&)(...), NULL)' is ambiguous

 7  mlt-6.18.0-2.fc32.src.rpm
https://koji.fedoraproject.org/koji/taskinfo?taskID=40685147
nothing provides libpoppler.so.84()(64bit) needed by 
gdal-libs-2.3.2-14.fc32.x86_64
Looks like gdal needs rebuilding for poppler first.

 8  nbdkit-1.17.5-1.fc32.src.rpm
https://koji.fedoraproject.org/koji/taskinfo?taskID=40688690
x86_64 test fails (ramdomly, perhaps), and armv7hl test seems to be hanging, 
out of my hands.

 9  openbabel-2.4.1-26.fc32.src.rpm
https://koji.fedoraproject.org/koji/taskinfo?taskID=40684400
Looks like the same issue as graphviz.
/builddir/build/BUILD/openbabel-openbabel-2-4-1/scripts/ruby/openbabel-ruby.cpp:1267:85:
 error: call of overloaded 'rb_define_virtual_variable(const char [21], VALUE 
(&)(...), NULL)' is ambiguous

10  rubygem-bootsnap-1.3.2-3.fc31.src.rpm
https://koji.fedoraproject.org/koji/taskinfo?taskID=40683765
Test suite fails.
/usr/share/rubygems/rubygems/core_ext/kernel_require.rb:72:in `require': no 
implicit conversion of String into Integer (TypeError)
from /usr/share/rubygems/rubygems/core_ext/kernel_require.rb:72:in 
`require'

Re: Rspec 3.9.0

[Mamoru TASAKA]

Hello, ruby-sig folks:

Pavel Valena wrote on 2019/12/05 1:50:

Currently, I've experimentally built Rspec 3.9, and I'm trying to enable tests, 
and I'm getting:


Anyway now I've updated rspec suites to 3.9.0 on rawhide (F32),

- rubygem-rspec
- rubygem-rspec-core
- rubygem-rspec-mocks
- rubygem-rspec-expectations
- rubygem-rspec-support
- rubygem-rspec-rails

which are now in f32 buildroot. (Just note that tests are enabled again in
spec file.)  Thanks to Pavel anyway.

Regards,
Mamoru
___
ruby-sig mailing list -- ruby-sig@lists.fedoraproject.org
To unsubscribe send an email to ruby-sig-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/ruby-sig@lists.fedoraproject.org

Re: Ruby 2.6 - Mass rebuild

[Mamoru TASAKA]

Vít Ondruch wrote on 2019/01/29 20:58:


Dne 29. 01. 19 v 12:29 Mamoru TASAKA napsal(a):

Zdenek Dohnal wrote on 2019/01/29 18:07:

Hi,

I'm just adding my 'cent' to ruby 2.6 mass rebuild - Vim started to
fail after ruby-2.6 was introduced to rawhide, but it fails only on
i686 and armv7hl:

i686:
task: https://koji.fedoraproject.org/koji/taskinfo?taskID=32309685
log:
https://kojipkgs.fedoraproject.org//work/tasks/9685/32309685/build.log

armv7hl:
task: https://koji.fedoraproject.org/koji/taskinfo?taskID=32309687
log:
https://kojipkgs.fedoraproject.org//work/tasks/9687/32309687/build.log

The error looks like mistake in C programming, but I already tried to
build current Vim with old ruby in copr and the build passes, but it
fails with new ruby. Did anyone encounter such errors with new ruby?


Actually this is due to API change on rb_int2big in ruby 2.6:

https://github.com/ruby/ruby/commit/d77e8a7da596fc23acd76c785548f6314114f97a

https://bugs.ruby-lang.org/issues/14036



Right. Please see the attached patch for naive fix of this issue (it
builds on i686 with the patch, that is all I tested). However, there
should be probably some Ruby version checks, because I suspect the patch
won't work on Ruby 2.5 and older.

I'll probably open Ruby upstream ticket pointing out the issue. But not
sure what anwer to expect ¯\_(ツ)_/¯


Vít



Or the attached patch may be preferable (ruby version check added).

Regards,
Mamoru


--- vim81/src/if_ruby.c.debug	2019-01-23 01:27:39.0 +0900
+++ vim81/src/if_ruby.c	2019-01-29 20:53:12.653072079 +0900
@@ -476,7 +476,11 @@
 #  endif
 # endif
 # ifdef RUBY19_OR_LATER
+#  if DYNAMIC_RUBY_VER >= 26
+static VALUE (*dll_rb_int2big)(intptr_t);
+#  else
 static VALUE (*dll_rb_int2big)(SIGNED_VALUE);
+#  endif
 # endif
 
 # ifdef RUBY19_OR_LATER
@@ -506,7 +510,11 @@
 {
 return dll_rb_num2long(x);
 }
+#  if DYNAMIC_RUBY_VER >= 26
+VALUE rb_int2big_stub(intptr_t x)
+#  else
 VALUE rb_int2big_stub(SIGNED_VALUE x)
+#  endif
 {
 return dll_rb_int2big(x);
 }
___
ruby-sig mailing list -- ruby-sig@lists.fedoraproject.org
To unsubscribe send an email to ruby-sig-le...@lists.fedoraproject.org
Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/ruby-sig@lists.fedoraproject.org