Re: rpms/ruby rawhide starting to fail on OpenSSL related failure

2023-11-10 Thread Jun Aruga (he / him)
The PR was merged. Now Koschei passes.
https://src.fedoraproject.org/rpms/ruby/pull-request/163

> But my question was if the patch was backported for Ruby 3.2 and
possibly older.

I opened the backport request ticket below in the Ruby project.
https://bugs.ruby-lang.org/issues/2

-- 
Jun | He - Him | Timezone: UTC+1 or 2, Czech Republic
See  for
the timezone.
___
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: rpms/ruby rawhide starting to fail on OpenSSL related failure

2023-11-09 Thread Jun Aruga (he / him)
On Thu, Nov 9, 2023 at 5:01 PM Vít Ondruch  wrote:
>
>
> Dne 09. 11. 23 v 16:41 Jun Aruga (he / him) napsal(a):
> > On Thu, Nov 9, 2023 at 10:03 AM Vít Ondruch  wrote:
> >>
> >> Dne 08. 11. 23 v 18:31 Jun Aruga (he / him) napsal(a):
> >>> Hello folks in Ruby SIG.
> >>>
> >>> I just want to share that right now rpms/ruby started to fail in
> >>> Fedora rawhide after the dependent openssl version was upgraded from
> >>> openssl 1:3.1.1-4.fc40 to 1:3.1.4-1.fc40.
> >>> https://koschei.fedoraproject.org/package/ruby?collection=f40
> >>>
> >>> ```
> >>> 1) Failure:
> >>> OpenSSL::TestFIPS#test_fips_mode_get_is_true_on_fips_mode_enabled
> >>> [/builddir/build/BUILD/ruby-3.2.2/test/openssl/test_fips.rb:12]:
> >>> assert_separately failed with error message
> >>> pid 93922 exit 1
> >>> | 
> >>> /builddir/build/BUILD/ruby-3.2.2/redhat-linux-build/.ext/common/openssl/pkey.rb:132:in
> >>> `initialize': could not parse pkey (OpenSSL::PKey::DHError)
> >>> | from 
> >>> /builddir/build/BUILD/ruby-3.2.2/redhat-linux-build/.ext/common/openssl/pkey.rb:132:in
> >>> `new'
> >>> | from 
> >>> /builddir/build/BUILD/ruby-3.2.2/redhat-linux-build/.ext/common/openssl/pkey.rb:132:in
> >>> `new'
> >>> | from 
> >>> /builddir/build/BUILD/ruby-3.2.2/redhat-linux-build/.ext/common/openssl/ssl.rb:37:in
> >>> `'
> >>> | from 
> >>> /builddir/build/BUILD/ruby-3.2.2/redhat-linux-build/.ext/common/openssl/ssl.rb:23:in
> >>> `'
> >>> | from 
> >>> /builddir/build/BUILD/ruby-3.2.2/redhat-linux-build/.ext/common/openssl/ssl.rb:22:in
> >>> `'
> >>> | from 
> >>> /builddir/build/BUILD/ruby-3.2.2/redhat-linux-build/.ext/common/openssl/ssl.rb:21:in
> >>> `'
> >>> | from 
> >>> /builddir/build/BUILD/ruby-3.2.2/redhat-linux-build/.ext/common/openssl.rb:21:in
> >>> `require_relative'
> >>> | from 
> >>> /builddir/build/BUILD/ruby-3.2.2/redhat-linux-build/.ext/common/openssl.rb:21:in
> >>> `'
> >>> | from -:in `require'
> >>> 2) Failure:
> >>> OpenSSL::TestFIPS#test_fips_mode_get_with_fips_mode_set
> >>> [/builddir/build/BUILD/ruby-3.2.2/test/openssl/test_fips.rb:38]:
> >>> assert_separately failed with error message
> >>> pid 93924 exit 1
> >>> | 
> >>> /builddir/build/BUILD/ruby-3.2.2/redhat-linux-build/.ext/common/openssl/pkey.rb:132:in
> >>> `initialize': could not parse pkey (OpenSSL::PKey::DHError)
> >>> | from 
> >>> /builddir/build/BUILD/ruby-3.2.2/redhat-linux-build/.ext/common/openssl/pkey.rb:132:in
> >>> `new'
> >>> | from 
> >>> /builddir/build/BUILD/ruby-3.2.2/redhat-linux-build/.ext/common/openssl/pkey.rb:132:in
> >>> `new'
> >>> | from 
> >>> /builddir/build/BUILD/ruby-3.2.2/redhat-linux-build/.ext/common/openssl/ssl.rb:37:in
> >>> `'
> >>> | from 
> >>> /builddir/build/BUILD/ruby-3.2.2/redhat-linux-build/.ext/common/openssl/ssl.rb:23:in
> >>> `'
> >>> | from 
> >>> /builddir/build/BUILD/ruby-3.2.2/redhat-linux-build/.ext/common/openssl/ssl.rb:22:in
> >>> `'
> >>> | from 
> >>> /builddir/build/BUILD/ruby-3.2.2/redhat-linux-build/.ext/common/openssl/ssl.rb:21:in
> >>> `'
> >>> | from 
> >>> /builddir/build/BUILD/ruby-3.2.2/redhat-linux-build/.ext/common/openssl.rb:21:in
> >>> `require_relative'
> >>> | from 
> >>> /builddir/build/BUILD/ruby-3.2.2/redhat-linux-build/.ext/common/openssl.rb:21:in
> >>> `'
> >>> | from -:in `require'
> >>> ```
> >>>
> >>> It seems that we need to apply the following patch that I applied to
> >>> CentOS 9 stream and RHEL 9 into Fedora too. I will work on it to pass
> >>> the tests on the current rawhide.
> >>> https://gitlab.com/redhat/centos-stream/rpms/ruby/-/commit/59242d8ce8261a9759dfb2bd8db673e55061a28b
> >>
> >> Thx!
> >>
> >>
> >>> As a note, we can remove this patch after upgrading Ruby to 3.3.0.
> >>
> >> BTW could you also please check the patch was backported into upstream
> >> Ruby 3.2 or older? That way we could eventually drop it from ever

Re: rpms/ruby rawhide starting to fail on OpenSSL related failure

2023-11-09 Thread Jun Aruga (he / him)
On Thu, Nov 9, 2023 at 10:03 AM Vít Ondruch  wrote:
>
>
> Dne 08. 11. 23 v 18:31 Jun Aruga (he / him) napsal(a):
> > Hello folks in Ruby SIG.
> >
> > I just want to share that right now rpms/ruby started to fail in
> > Fedora rawhide after the dependent openssl version was upgraded from
> > openssl 1:3.1.1-4.fc40 to 1:3.1.4-1.fc40.
> > https://koschei.fedoraproject.org/package/ruby?collection=f40
> >
> > ```
> >1) Failure:
> > OpenSSL::TestFIPS#test_fips_mode_get_is_true_on_fips_mode_enabled
> > [/builddir/build/BUILD/ruby-3.2.2/test/openssl/test_fips.rb:12]:
> > assert_separately failed with error message
> > pid 93922 exit 1
> > | 
> > /builddir/build/BUILD/ruby-3.2.2/redhat-linux-build/.ext/common/openssl/pkey.rb:132:in
> > `initialize': could not parse pkey (OpenSSL::PKey::DHError)
> > | from 
> > /builddir/build/BUILD/ruby-3.2.2/redhat-linux-build/.ext/common/openssl/pkey.rb:132:in
> > `new'
> > | from 
> > /builddir/build/BUILD/ruby-3.2.2/redhat-linux-build/.ext/common/openssl/pkey.rb:132:in
> > `new'
> > | from 
> > /builddir/build/BUILD/ruby-3.2.2/redhat-linux-build/.ext/common/openssl/ssl.rb:37:in
> > `'
> > | from 
> > /builddir/build/BUILD/ruby-3.2.2/redhat-linux-build/.ext/common/openssl/ssl.rb:23:in
> > `'
> > | from 
> > /builddir/build/BUILD/ruby-3.2.2/redhat-linux-build/.ext/common/openssl/ssl.rb:22:in
> > `'
> > | from 
> > /builddir/build/BUILD/ruby-3.2.2/redhat-linux-build/.ext/common/openssl/ssl.rb:21:in
> > `'
> > | from 
> > /builddir/build/BUILD/ruby-3.2.2/redhat-linux-build/.ext/common/openssl.rb:21:in
> > `require_relative'
> > | from 
> > /builddir/build/BUILD/ruby-3.2.2/redhat-linux-build/.ext/common/openssl.rb:21:in
> > `'
> > | from -:in `require'
> >2) Failure:
> > OpenSSL::TestFIPS#test_fips_mode_get_with_fips_mode_set
> > [/builddir/build/BUILD/ruby-3.2.2/test/openssl/test_fips.rb:38]:
> > assert_separately failed with error message
> > pid 93924 exit 1
> > | 
> > /builddir/build/BUILD/ruby-3.2.2/redhat-linux-build/.ext/common/openssl/pkey.rb:132:in
> > `initialize': could not parse pkey (OpenSSL::PKey::DHError)
> > | from 
> > /builddir/build/BUILD/ruby-3.2.2/redhat-linux-build/.ext/common/openssl/pkey.rb:132:in
> > `new'
> > | from 
> > /builddir/build/BUILD/ruby-3.2.2/redhat-linux-build/.ext/common/openssl/pkey.rb:132:in
> > `new'
> > | from 
> > /builddir/build/BUILD/ruby-3.2.2/redhat-linux-build/.ext/common/openssl/ssl.rb:37:in
> > `'
> > | from 
> > /builddir/build/BUILD/ruby-3.2.2/redhat-linux-build/.ext/common/openssl/ssl.rb:23:in
> > `'
> > | from 
> > /builddir/build/BUILD/ruby-3.2.2/redhat-linux-build/.ext/common/openssl/ssl.rb:22:in
> > `'
> > | from 
> > /builddir/build/BUILD/ruby-3.2.2/redhat-linux-build/.ext/common/openssl/ssl.rb:21:in
> > `'
> > | from 
> > /builddir/build/BUILD/ruby-3.2.2/redhat-linux-build/.ext/common/openssl.rb:21:in
> > `require_relative'
> > | from 
> > /builddir/build/BUILD/ruby-3.2.2/redhat-linux-build/.ext/common/openssl.rb:21:in
> > `'
> > | from -:in `require'
> > ```
> >
> > It seems that we need to apply the following patch that I applied to
> > CentOS 9 stream and RHEL 9 into Fedora too. I will work on it to pass
> > the tests on the current rawhide.
> > https://gitlab.com/redhat/centos-stream/rpms/ruby/-/commit/59242d8ce8261a9759dfb2bd8db673e55061a28b
>
>
> Thx!
>
>
> >
> > As a note, we can remove this patch after upgrading Ruby to 3.3.0.
>
>
> BTW could you also please check the patch was backported into upstream
> Ruby 3.2 or older? That way we could eventually drop it from everywhere.
> Thx.

I sent the PR. I need to test it by myself. But please review.
https://src.fedoraproject.org/rpms/ruby/pull-request/163

Yes, the patch is already upstream below.  I expect that the patch is
included in Ruby 3.3.0.
https://github.com/ruby/ruby/commit/b6d7cdc2bad0eadbca73f3486917f0ec7a475814

-- 
Jun | He - Him | Timezone: UTC+1 or 2, Czech Republic
See <https://www.worldtimebuddy.com/czech-republic-prague-to-utc> for
the timezone.
___
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


rpms/ruby rawhide starting to fail on OpenSSL related failure

2023-11-08 Thread Jun Aruga (he / him)
Hello folks in Ruby SIG.

I just want to share that right now rpms/ruby started to fail in
Fedora rawhide after the dependent openssl version was upgraded from
openssl 1:3.1.1-4.fc40 to 1:3.1.4-1.fc40.
https://koschei.fedoraproject.org/package/ruby?collection=f40

```
  1) Failure:
OpenSSL::TestFIPS#test_fips_mode_get_is_true_on_fips_mode_enabled
[/builddir/build/BUILD/ruby-3.2.2/test/openssl/test_fips.rb:12]:
assert_separately failed with error message
pid 93922 exit 1
| 
/builddir/build/BUILD/ruby-3.2.2/redhat-linux-build/.ext/common/openssl/pkey.rb:132:in
`initialize': could not parse pkey (OpenSSL::PKey::DHError)
| from 
/builddir/build/BUILD/ruby-3.2.2/redhat-linux-build/.ext/common/openssl/pkey.rb:132:in
`new'
| from 
/builddir/build/BUILD/ruby-3.2.2/redhat-linux-build/.ext/common/openssl/pkey.rb:132:in
`new'
| from 
/builddir/build/BUILD/ruby-3.2.2/redhat-linux-build/.ext/common/openssl/ssl.rb:37:in
`'
| from 
/builddir/build/BUILD/ruby-3.2.2/redhat-linux-build/.ext/common/openssl/ssl.rb:23:in
`'
| from 
/builddir/build/BUILD/ruby-3.2.2/redhat-linux-build/.ext/common/openssl/ssl.rb:22:in
`'
| from 
/builddir/build/BUILD/ruby-3.2.2/redhat-linux-build/.ext/common/openssl/ssl.rb:21:in
`'
| from 
/builddir/build/BUILD/ruby-3.2.2/redhat-linux-build/.ext/common/openssl.rb:21:in
`require_relative'
| from 
/builddir/build/BUILD/ruby-3.2.2/redhat-linux-build/.ext/common/openssl.rb:21:in
`'
| from -:in `require'
  2) Failure:
OpenSSL::TestFIPS#test_fips_mode_get_with_fips_mode_set
[/builddir/build/BUILD/ruby-3.2.2/test/openssl/test_fips.rb:38]:
assert_separately failed with error message
pid 93924 exit 1
| 
/builddir/build/BUILD/ruby-3.2.2/redhat-linux-build/.ext/common/openssl/pkey.rb:132:in
`initialize': could not parse pkey (OpenSSL::PKey::DHError)
| from 
/builddir/build/BUILD/ruby-3.2.2/redhat-linux-build/.ext/common/openssl/pkey.rb:132:in
`new'
| from 
/builddir/build/BUILD/ruby-3.2.2/redhat-linux-build/.ext/common/openssl/pkey.rb:132:in
`new'
| from 
/builddir/build/BUILD/ruby-3.2.2/redhat-linux-build/.ext/common/openssl/ssl.rb:37:in
`'
| from 
/builddir/build/BUILD/ruby-3.2.2/redhat-linux-build/.ext/common/openssl/ssl.rb:23:in
`'
| from 
/builddir/build/BUILD/ruby-3.2.2/redhat-linux-build/.ext/common/openssl/ssl.rb:22:in
`'
| from 
/builddir/build/BUILD/ruby-3.2.2/redhat-linux-build/.ext/common/openssl/ssl.rb:21:in
`'
| from 
/builddir/build/BUILD/ruby-3.2.2/redhat-linux-build/.ext/common/openssl.rb:21:in
`require_relative'
| from 
/builddir/build/BUILD/ruby-3.2.2/redhat-linux-build/.ext/common/openssl.rb:21:in
`'
| from -:in `require'
```

It seems that we need to apply the following patch that I applied to
CentOS 9 stream and RHEL 9 into Fedora too. I will work on it to pass
the tests on the current rawhide.
https://gitlab.com/redhat/centos-stream/rpms/ruby/-/commit/59242d8ce8261a9759dfb2bd8db673e55061a28b

As a note, we can remove this patch after upgrading Ruby to 3.3.0.

Jun

-- 
Jun | He - Him | Timezone: UTC+1 or 2, Czech Republic
See  for
the timezone.
___
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: rpms/ruby rawhide FTBFS by checksec

2023-09-08 Thread Jun Aruga (he / him)
Thanks for the info about the Bugzilla ticket.

I think that the situation is a bit different from the things reported
on the ticket.
For example, the checksec command is failing in x86_64 build below.

https://koji.fedoraproject.org/koji/taskinfo?taskID=105910750
https://kojipkgs.fedoraproject.org//work/tasks/750/105910750/build.log
+ checksec --file=redhat-linux-build/libruby.so.3.2.2
/var/tmp/rpm-tmp.GFaqBt: line 48: 85686 Aborted (core
dumped) checksec --file=redhat-linux-build/libruby.so.3.2.2
RPM build errors:
error: Bad exit status from /var/tmp/rpm-tmp.GFaqBt (%check)

I tried to check which RPM package version of the checksec is used.
However it doesn't show the version of the installed checksec. It's
not convenient. Maybe because it is already installed in the build
environment? I think we can add the `rpm -q checksec` somewhere for
debugging purposes in ruby.spec
https://kojipkgs.fedoraproject.org//work/tasks/750/105910750/root.log

Anyway, I will consider commenting on the ticket.

Jun

On Fri, Sep 8, 2023 at 6:09 PM Vít Ondruch  wrote:
>
> But reading the ticket, it seems to be related after all :) It seems
> there was done some change, but properly not tested on Rawhide properly.
> Feel free to update the ticket.
>
>
> V.
>
>
> Dne 08. 09. 23 v 18:07 Vít Ondruch napsal(a):
> > Although, the dependency issue is new to me. Chm. Sorry for being to
> > fast replying without reading carefully.
> >
> >
> > V.
> >
> >
> > Dne 08. 09. 23 v 18:05 Vít Ondruch napsal(a):
> >> https://bugzilla.redhat.com/show_bug.cgi?id=2235760
> >>
> >>
> >> V.
> >>
> >>
> >> Dne 08. 09. 23 v 17:59 Jun Aruga (he / him) napsal(a):
> >>> Note that I am trying to fix the FTBFS on the current rpms/ruby
> >>> rawhide.
> >>>
> >>> Below is the scratch build with the modification to print the output
> >>> of the checksec command below.
> >>> https://koji.fedoraproject.org/koji/taskinfo?taskID=105910607
> >>>
> >>> ```
> >>> diff --git a/ruby.spec b/ruby.spec
> >>> index 51ada32..f61c3fe 100644
> >>> --- a/ruby.spec
> >>> +++ b/ruby.spec
> >>> @@ -855,6 +855,7 @@ rm -rf
> >>> %{buildroot}%{gem_dir}/gems/rake-%{rake_version}/.github
> >>>   %check
> >>>   %if 0%{?with_hardening_test}
> >>>   # Check Ruby hardening.
> >>> +checksec --file=%{_vpath_builddir}/libruby.so.%{ruby_version}
> >>>   checksec --file=%{_vpath_builddir}/libruby.so.%{ruby_version} | \
> >>> grep "Full RELRO.*Canary found.*NX enabled.*DSO.*No RPATH.*No
> >>> RUNPATH.*Yes.*\d*.*\d*.*libruby.so.%{ruby_version}"
> >>>   %endif
> >>> ```
> >>>
> >>> On only s390x build, there is another error in root.log. I am asking
> >>> how to fix it on devel@ mailing list now.
> >>>
> >>> https://kojipkgs.fedoraproject.org//work/tasks/753/105910753/root.log
> >>>
> >>> ```
> >>> DEBUG util.py:442:  No matches found for the following disable plugin
> >>> patterns: local, spacewalk, versionlock
> >>> DEBUG util.py:442:  Error:-
> >>> DEBUG util.py:442:   Problem: conflicting requests
> >>> DEBUG util.py:442:- nothing provides nm needed by
> >>> checksec-2.6.0-5.fc40.noarch from build
> >>> DEBUG util.py:442:- nothing provides python3.12dist(unicorn) >=
> >>> 1.0.2~rc1 needed by python3-pwntools-4.9.0-4.fc39.noarch from build
> >>> ```
> >>>
> ___
> 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



-- 
Jun | He - Him | Timezone: UTC+1 or 2, Czech Republic
See <https://www.worldtimebuddy.com/czech-republic-prague-to-utc> for
the timezone.
___
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


rpms/ruby rawhide FTBFS by checksec

2023-09-08 Thread Jun Aruga (he / him)
Note that I am trying to fix the FTBFS on the current rpms/ruby rawhide.

Below is the scratch build with the modification to print the output
of the checksec command below.
https://koji.fedoraproject.org/koji/taskinfo?taskID=105910607

```
diff --git a/ruby.spec b/ruby.spec
index 51ada32..f61c3fe 100644
--- a/ruby.spec
+++ b/ruby.spec
@@ -855,6 +855,7 @@ rm -rf
%{buildroot}%{gem_dir}/gems/rake-%{rake_version}/.github
 %check
 %if 0%{?with_hardening_test}
 # Check Ruby hardening.
+checksec --file=%{_vpath_builddir}/libruby.so.%{ruby_version}
 checksec --file=%{_vpath_builddir}/libruby.so.%{ruby_version} | \
   grep "Full RELRO.*Canary found.*NX enabled.*DSO.*No RPATH.*No
RUNPATH.*Yes.*\d*.*\d*.*libruby.so.%{ruby_version}"
 %endif
```

On only s390x build, there is another error in root.log. I am asking
how to fix it on devel@ mailing list now.

https://kojipkgs.fedoraproject.org//work/tasks/753/105910753/root.log

```
DEBUG util.py:442:  No matches found for the following disable plugin
patterns: local, spacewalk, versionlock
DEBUG util.py:442:  Error:-
DEBUG util.py:442:   Problem: conflicting requests
DEBUG util.py:442:- nothing provides nm needed by
checksec-2.6.0-5.fc40.noarch from build
DEBUG util.py:442:- nothing provides python3.12dist(unicorn) >=
1.0.2~rc1 needed by python3-pwntools-4.9.0-4.fc39.noarch from build
```

-- 
Jun | He - Him | Timezone: UTC+1 or 2, Czech Republic
See  for
the timezone.
___
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: Fedora 37 Ruby 3.1.4 and URI.parse FTBFS gems

2023-05-30 Thread Jun Aruga (he / him)
On Mon, May 29, 2023 at 4:54 PM Jarek Prokop  wrote:
>
> Hi all,
>
> JFYI, latest Fedora 37 Ruby rebase broke a few Ruby package builds due to 
> change in the URI gem.
>
> recently I did a rebase for Ruby 3.1.4 to address 2 CVEs among other things.
> For one of those CVEs (ReDoS vulnerability in URI [0]), upstream merged URI 
> gem v0.12.0[1] and later to v0.12.1 [2] (full 3.1.3 -> 3.1.4 diff: [3]).
>
> The 0.12.0 brought a change, where URI.parse now returns empty string instead 
> of `nil` for empty host, this resulted in a few newly FTBFS packages.
> I have hit this recently with vagrant-libvirt and found out it is more than 
> that package, though not by much.
>
> Looking at koschei [4] FTBFS for rubygems on Fedora 37, there aren't that 
> many and some have been failing on F37 for longer time than Ruby 3.1.4 is in 
> Fedora 37.
> The current package set that is FTBFS in koschei on Fedora 37 for one reason 
> or another:
> rubygem-clockwork  rubygem-eventmachine rubygem-excon
> rubygem-hiredisrubygem-loofah   rubygem-memfs
> rubygem-multi_json rubygem-mysql2   rubygem-net-ssh
> rubygem-nifti  rubygem-rails-html-sanitizer rubygem-rake-contrib
> rubygem-rdoc   rubygem-redisrubygem-rest-client
> rubygem-ronn-ngrubygem-rubyzip  rubygem-selenium-webdriver
> rubygem-slim   rubygem-sprocketsrubygem-websocket-extensions
>
> Regards,
> Jarek
>
>
> [0] https://www.ruby-lang.org/en/news/2023/03/28/redos-in-uri-cve-2023-28755/
> [1] 
> https://github.com/ruby/ruby/commit/da27583cf364c0d69c085db4abf358c334a8eca1
> [2] 
> https://github.com/ruby/ruby/commit/8ce4ab146498879b65e22f1be951b25eebb79300
> [3] https://github.com/ruby/ruby/compare/v3_1_3...v3_1_4
> [4] 
> https://koschei.fedoraproject.org/search?q=rubygem-%2A&order_by=state-f37%2Crunning%2Cfailing%2Cname

Hi Jarek,
Thank you for the useful and detailed report! When we fix it, we may
find the upstream patch to pass the test with Ruby 3.1.4 on the
package upstream projects.

-- 
Jun | He - Him | Timezone: UTC+1 or 2, Czech Republic
See  for
the timezone.
___
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: SPDX Status for Rubygems in Fedora as of 2023-04-20

2023-04-25 Thread Jun Aruga (he / him)
> Would it make sense to also add other committers/admins to the list as they 
> also have rights to push the SPDX "fix"?

It makes sense to me!

-- 
Jun | He - Him | Timezone: UTC+1 or 2, Czech Republic
See  for
the timezone.
___
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: WASM from Ruby - Lightning Chess Web App

2023-01-11 Thread Jun Aruga (he / him)
Jarek, thanks for your feedback!

> Or you can go completely from source. Then you want to follow Ruby's upstream 
> README on wasm crosscompilation [4].
...
> [4] 
> https://github.com/ruby/ruby/tree/master/wasm#webassembly--wasi-port-of-ruby
...

Phillip,
I built Ruby WASM binarys following the link [4] above, building
WASM-SDK and wasmtime recently. So, I may help you if you have some
issues on the way.

It seems that there is also another way to build and run Ruby WASM
binaries with wasi-vfs.
https://www.ruby-lang.org/en/news/2022/12/25/ruby-3-2-0-released/ -
WASI based WebAssembly support
> In addition, we built a VFS on top of WASI so that we can easily pack Ruby 
> apps into a single .wasm file. This makes distribution of Ruby apps a bit 
> easier.

As Jarek said, the necessary RPM packages such as "wasi-libc" and
"wasmtime" to build and run WASM binaries are not ready. Perhaps, you
can try to build Ruby WASM binaries from source first, then you might
be able to give feedback to people who are trying to create
WebAssembly SIG.

-- 
Jun | He - Him | Timezone: UTC+1 or 2, Czech Republic
See  for
the timezone.
___
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: WASM from Ruby - Lightning Chess Web App

2023-01-09 Thread Jun Aruga (he / him)
Hi Philip,
I added a Ruby SiG mailing list to TO.

Folks at Ruby SiG,
Could you take a look at the message below? Philip is trying to create
a RPM package including WASM built Ruby binaries. Your feedback is
helpful.

On Mon, Jan 9, 2023 at 11:00 AM Philip Rhoades  wrote:
>
> Jun,
>
>
> On 2023-01-09 00:36, Jun Aruga (he / him) wrote:
> > On Sun, Jan 8, 2023 at 11:51 AM Philip Rhoades via devel
> >  wrote:
> >>
> >> People,
> >>
> >> Over the holidays we had our irregular Family Lightning Chess
> >> competition (10 seconds per move) - I have not found an online web
> >> site
> >> that will work exactly with our rules and it occurs to me that this
> >> would be a nice project for me to get working via a Ruby2WASM project.
> >> If I could get that project working, it would allow the family to have
> >> at least annual electronic competitions for the times when not all the
> >> relatives can physically make it to the one place at the one time . .
> >>
> >> What do you think?
> >
> > Good idea!
>
>
> Good! - I wasn't sure if it was or note . .
>
>
> > Ruby 3.2 released a few weeks ago, started to support the WASM built
> > feature, and I guess that people want to use it easily.
>
>
> I certainly do!
>
>
> > The first choice for the packaging is to create WASM built binaries as
> > a sub package of "ruby" https://src.fedoraproject.org/rpms/ruby or to
> > create a new package with the new RPM spec file.
>
>
> I don't know about that but it would be good for me to get started with
> a "Hello World!" Ruby2WASM app and go from there . .

OK. I think trying to create a minimal RPM package such as "Hello
World" is a good idea if you have never experienced RPM packaging.
Then as your next step, you may be able to try to build by creating
your package by copying the current rpms/ruby's ruby.spec to e.g.
ruby-wasm.spec, and modifying it to build WASM binaries.

Tutorial: 
https://docs.fedoraproject.org/en-US/package-maintainers/Packaging_Tutorial_GNU_Hello/
Packaging Guide: https://docs.fedoraproject.org/en-US/packaging-guidelines/

> > We discussed if we shipped WASM binaries a bit in the ruby-sig@
> > mailing list. I can recommend you to join the list to discuss people
> > in the ruby related packages  if you like.
> >
> > * Ruby 3.2 - ruby-sig@
> >
> > https://lists.fedoraproject.org/archives/list/ruby-sig@lists.fedoraproject.org/thread/FK3XRKUICBS7HFZVEENSEGJ4ZMKCVNWF/
>
>
> Yes, I read that stuff and am subscribed to that list now.

OK. Nice!

> > Fedora WASM SIP might be launched. You can check the situation.
> >
> > * Web Assembly on Fedora: interested in a Fedora SIG to work on this?
> >
> > https://lists.fedoraproject.org/archives/list/de...@lists.fedoraproject.org/thread/JO2YYDQPC65EMQVO6UCHDV4SAKQNSGKV/
>
>
> Happy to join that list too but that is a much wider deal than the
> Ruby2WASM project?

Yes. right. I think it's about WASM things more than Ruby.
For example, it's about what you need to do to build WASM binaries of
Ruby, and which dependency RPM packages you need.

> Thanks!
>
> Phil.
> --
> Philip Rhoades
>
> PO Box 896
> Cowra  NSW  2794
> Australia
> E-mail:  p...@pricom.com.au

Thanks too!

-- 
Jun | He - Him | Timezone: UTC+1 or 2, Czech Republic
See <https://www.worldtimebuddy.com/czech-republic-prague-to-utc> for
the timezone.
___
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


Starting to use Zuul CI for other rubygem-* packages

2022-12-01 Thread Jun Aruga (he / him)
Hi,
I just sent PR[1][2] to start to use Zuul CI for RubyGems, Bundler and
rubygem-* packages used in the Ruby module, as I can see it's useful
for rpms/ruby. I hope you are happy with it.

Perhaps we might be able to add the following packages to Zuul in the
future too.

* All the rubygem-* packages included in Koschei ruby-rails group.
  https://koschei.fedoraproject.org/groups/ruby-rails
* All the rubygem-* packages @ruby-packagers-sig

[1] https://pagure.io/fedora-project-config/pull-request/243
[2] How to add:
https://fedoraproject.org/wiki/Zuul-based-ci#Add_the_repository_into_the_Zuul_configuration

-- 
Jun | He - Him | Timezone: UTC+1 or 2, Czech Republic
See  for
the timezone.
___
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: gem install fails on rawhide

2022-11-12 Thread Jun Aruga (he / him)
> But essentially we need to do something in the `ruby.spec` not to
> expose the redhat-rpm-config RPM or Red Hat specific RPMs such as
> package-notes RPM. Possible ways are below.
>
> A. Modify rbconfig.rb by such as `sed` command.
> B. Add another logic to create the `reconfig.rb` by `make rbconfig.rb`
> with extension flags, and ship it in the Ruby RPM.
> C. Update the configure script with proper arguments or command options.
>   https://src.fedoraproject.org/rpms/ruby/pull-request/117
>
> Feel free to take this task.

I think it's better to add the `gem install byebug` to Fedora CI for
the rpms/ruby.

-- 
Jun | He - Him | Timezone: UTC+1 or 2, Czech Republic
See  for
the timezone.
___
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


gem install fails on rawhide

2022-11-12 Thread Jun Aruga (he / him)
Hello,

I found the gem install  fails on the Ruby on the rawhide.

I reported it to the package-notes RPM.
https://bugzilla.redhat.com/show_bug.cgi?id=2142119

https://bugzilla.redhat.com/show_bug.cgi?id=2142119#c1

Maybe a temporary workaround we can do soon is to set the macro below
in the ruby.spec.

```
%undefine _package_note_file
```

But essentially we need to do something in the `ruby.spec` not to
expose the redhat-rpm-config RPM or Red Hat specific RPMs such as
package-notes RPM. Possible ways are below.

A. Modify rbconfig.rb by such as `sed` command.
B. Add another logic to create the `reconfig.rb` by `make rbconfig.rb`
with extension flags, and ship it in the Ruby RPM.
C. Update the configure script with proper arguments or command options.
  https://src.fedoraproject.org/rpms/ruby/pull-request/117

Feel free to take this task.

-- 
Jun | He - Him | Timezone: UTC+1 or 2, Czech Republic
See  for
the timezone.
___
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

2022-11-10 Thread Jun Aruga (he / him)
> >> I don't think that the former would be really valuable. Unless the RPM
> >> package Ruby would make it easier in some way.
> > I am suggesting that "we should rather not mention WASI, because the
> > RPM does not actually support it". That is what we did for our
> > document about the MJIT in the past in the RHEL side, as the MJIT
> > didn't work due to RHEL's hardening setting. Or just add note that
> > "the Ruby RPM doesn't support the WebAssemly. If you want to use the
> > feature, compile from the source."
> >
>
> I have dropped the section entirely. Because based on your explanation,
> I'd say that WebAssembly is currently out of scope, as long as we are
> not able to provide the WebAssembly Ruby blob.
>
>
> Thx a lot. Appreciate your help.

OK. That makes sense. Thanks.

I think the Ruby wasm's document could be improved. I just sent a PR
to improve that.

wasm/README.md: Add a note about the Ruby built for wasm.
https://github.com/ruby/ruby/pull/6707

-- 
Jun | He - Him | Timezone: UTC+1 or 2, Czech Republic
See  for
the timezone.
___
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 rawhide FTBFS

2022-11-09 Thread Jun Aruga (he / him)
> I am afraid that Koschei will not pick up the builds without submitting
> updates unfortunately.

Here is a document and an upstream ticket that I am asking. But there
are priorities to be picked up or to be started.
https://fedoraproject.org/wiki/Koschei#Priorities
https://github.com/fedora-infra/koschei/issues/349

-- 
Jun | He - Him | Timezone: UTC+1 or 2, Czech Republic
See  for
the timezone.
___
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

2022-11-09 Thread Jun Aruga (he / him)
On Mon, Nov 7, 2022 at 10:44 AM Vít Ondruch  wrote:
>
>
> Dne 04. 11. 22 v 19:13 Jun Aruga (he / him) napsal(a):
> >> I have put together the change proposal:
> >>
> >> https://fedoraproject.org/wiki/Changes/Ruby_3.2
> >>
> >> Please review, although with exception of "Detailed Description"
> >> chapter, where the changes are described, it is basically just
> >> copy/paste of the Ruby 3.1 change proposal.
> >>
> >> I have marked the change as "ChangeReadyForWrangler" already. BTW
> >> everybody feel free to add yourselves as a change (co-)owner.
> > For the "WASI based WebAssembly support" feature, there is no way to
> > use this feature from Ruby RPM. Users need to build Ruby from the
> > source with a specific build target configure option. Does it make
> > sense to show the feature on the proposal page?
> >
>
> Could you please elaborate? Do you suggest we should describe how to
> prepare that build or that we should rather not mention WASI, because
> the RPM does not actually support it?

Sure. First, are you ok for the part 'For the "WASI based WebAssembly
support" feature, there is no way to use this feature from Ruby RPM.'?

That means
https://bugs.ruby-lang.org/issues/19053#note-3

When building ruby to run on the WebAssembly runtime with `configure
--host wasm32-unknown-wasi`, it works on the WebAssembly runtime
(wasmtime).

```
$ pwd
/home/jaruga/src/ruby-3.2.0-preview2_wasi_fedora

$ ./autogen.sh

$ ./configure LDFLAGS="-Xlinker -zstack-size=16777216" \
  -prefix=/usr/local/ruby-3.2.0-preview2-wasm32-wasi \
  --host wasm32-unknown-wasi \
  --with-destdir=./ruby-wasm32-wasi \
  --with-static-linked-ext \
  --with-ext=ripper,monitor

$ make
$ make install

$ wasmtime ruby-wasm32-wasi/usr/local/ruby-3.2.0-preview2-wasm32-wasi/bin/ruby
--mapdir /::./ruby-wasm32-wasi/ -- -e 'puts RUBY_PLATFORM'
wasm32-wasi
```

But the binary doesn't work on normal use.

```
$ ruby-wasm32-wasi/usr/local/ruby-3.2.0-preview2-wasm32-wasi/bin/ruby -v
bash: ruby-wasm32-wasi/usr/local/ruby-3.2.0-preview2-wasm32-wasi/bin/ruby:
cannot execute binary file: Exec format error

$ ruby-wasm32-wasi/usr/local/ruby-3.2.0-preview2-wasm32-wasi/bin/ruby
-e 'puts "a"'
bash: ruby-wasm32-wasi/usr/local/ruby-3.2.0-preview2-wasm32-wasi/bin/ruby:
cannot execute binary file: Exec format error
```

Because the binary format is different.

```
$ file /usr/bin/ruby-mri
/usr/bin/ruby-mri: ELF 64-bit LSB pie executable, x86-64, version 1
(SYSV), dynamically linked, interpreter /lib64/ld-linux-x86-64.so.2,
BuildID[sha1]=37b172d9897934e511f5e8496b7409471488a99e, for GNU/Linux
3.2.0, stripped

$ file ruby-wasm32-wasi/usr/local/ruby-3.2.0-preview2-wasm32-wasi/bin/ruby
ruby-wasm32-wasi/usr/local/ruby-3.2.0-preview2-wasm32-wasi/bin/ruby:
WebAssembly (wasm) binary module version 0x1 (MVP)
```

> I don't think that the former would be really valuable. Unless the RPM
> package Ruby would make it easier in some way.

I am suggesting that "we should rather not mention WASI, because the
RPM does not actually support it". That is what we did for our
document about the MJIT in the past in the RHEL side, as the MJIT
didn't work due to RHEL's hardening setting. Or just add note that
"the Ruby RPM doesn't support the WebAssemly. If you want to use the
feature, compile from the source."

-- 
Jun | He - Him | Timezone: UTC+1 or 2, Czech Republic
See <https://www.worldtimebuddy.com/czech-republic-prague-to-utc> for
the timezone.
___
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

2022-11-04 Thread Jun Aruga (he / him)
> I have put together the change proposal:
>
> https://fedoraproject.org/wiki/Changes/Ruby_3.2
>
> Please review, although with exception of "Detailed Description"
> chapter, where the changes are described, it is basically just
> copy/paste of the Ruby 3.1 change proposal.
>
> I have marked the change as "ChangeReadyForWrangler" already. BTW
> everybody feel free to add yourselves as a change (co-)owner.

For the "WASI based WebAssembly support" feature, there is no way to
use this feature from Ruby RPM. Users need to build Ruby from the
source with a specific build target configure option. Does it make
sense to show the feature on the proposal page?

-- 
Jun | He - Him | Timezone: UTC+1 or 2, Czech Republic
See  for
the timezone.
___
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

2022-11-04 Thread Jun Aruga (he / him)
> Thanks for your input. I will create a pull-request to the private-ruby-3.2 
> branch to add the YJIT feature.

Here is the PR.

WIP: Enable YJIT feature.
https://src.fedoraproject.org/rpms/ruby/pull-request/139

I plan to test the YJIT and check the performance on the mock environment.
https://github.com/Shopify/yjit-bench

-- 
Jun | He - Him | Timezone: UTC+1 or 2, Czech Republic
See  for
the timezone.
___
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 rawhide FTBFS

2022-11-04 Thread Jun Aruga (he / him)
On Thu, Nov 3, 2022 at 8:06 PM Jun Aruga (he / him)  wrote:
>
> > Here is the PR. Someone, please review.
> > https://src.fedoraproject.org/rpms/rubygems/pull-request/4
>
> Here is the status. Review please. Thanks.

I was able to build the all the rpms/ruby and rubygems and
rubygem-bundler. Thanks for your help.
Just note I didn't submit the rpms/ruby build on f37, f36, f35 to the
Bodhi, as it is just to fix the FTBFS.

> rpms/ruby
> * rawhide: done (built)
> * f37: https://src.fedoraproject.org/rpms/ruby/pull-request/136
> * f36: https://src.fedoraproject.org/rpms/ruby/pull-request/137
> * f35: https://src.fedoraproject.org/rpms/ruby/pull-request/138

https://koji.fedoraproject.org/koji/packageinfo?packageID=125

> rpms/rubygems
> * rawhide: https://src.fedoraproject.org/rpms/rubygems/pull-request/4
> (in review)
>
> rpms/rubygem-bundler
> * rawhide: https://src.fedoraproject.org/rpms/rubygem-bundler/pull-request/6
>   The rubygem-bundler PR should be merged and built before the
> rpms/rubygems because rubygems depends on the latest version of the
> rubygem-bundler.

The Koschei has not worked for ruby rawhide since around 1 month ago,
but after reporting to the Koschei project, it started to work again.
https://github.com/fedora-infra/koschei/issues/349
https://koschei.fedoraproject.org/package/ruby

-- 
Jun | He - Him | Timezone: UTC+1 or 2, Czech Republic
See <https://www.worldtimebuddy.com/czech-republic-prague-to-utc> for
the timezone.
___
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 rawhide FTBFS

2022-11-03 Thread Jun Aruga (he / him)
> Here is the PR. Someone, please review.
> https://src.fedoraproject.org/rpms/rubygems/pull-request/4

Here is the status. Review please. Thanks.

rpms/ruby
* rawhide: done (built)
* f37: https://src.fedoraproject.org/rpms/ruby/pull-request/136
* f36: https://src.fedoraproject.org/rpms/ruby/pull-request/137
* f35: https://src.fedoraproject.org/rpms/ruby/pull-request/138

rpms/rubygems
* rawhide: https://src.fedoraproject.org/rpms/rubygems/pull-request/4
(in review)

rpms/rubygem-bundler
* rawhide: https://src.fedoraproject.org/rpms/rubygem-bundler/pull-request/6
  The rubygem-bundler PR should be merged and built before the
rpms/rubygems because rubygems depends on the latest version of the
rubygem-bundler.

-- 
Jun | He - Him | Timezone: UTC+1 or 2, Czech Republic
See  for
the timezone.
___
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 rawhide FTBFS

2022-11-03 Thread Jun Aruga (he / him)
> > Not surprisingly, RubyGems fail as well 🫤
> >
> >
> > https://koschei.fedoraproject.org/package/rubygems?collection=f38
>
> Okay, the rpms/rubygems is next after the rpms/ruby.

Here is the PR. Someone, please review.
https://src.fedoraproject.org/rpms/rubygems/pull-request/4

-- 
Jun | He - Him | Timezone: UTC+1 or 2, Czech Republic
See  for
the timezone.
___
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 rawhide FTBFS

2022-11-03 Thread Jun Aruga (he / him)
> >> https://bodhi.fedoraproject.org/updates/?packages=git
> > The git 2.38.1 is on f37, f36 and f35 too.
> > Maybe it's better to push this PR commit to these fedoras too after
> > merging the rawhide PR.
> >
>
> Right, I have mentioned this in the PR but you are apparently on top of
> it. Great!

OK. I will fix this issue and build on the old Fedoras too.

> BTW if you have a spare cycles, please review the Rawhide changes which
> were committed after the F37 was branched. I guess they could be
> included into F37, but I have not checked (particularly the enabled
> package notes, not sure if the changes landed in F37, but my guess is
> that they have landed there). Thx

It seems that the rawhide specific change below should work on Fedora
37 (and 36) too. I will backport the commit to the f37 too.
https://src.fedoraproject.org/rpms/ruby/c/588a4ae9f02928d7bedbcf46a739d36b0a76e632?branch=rawhide

The issue comes from the redhat-rpm-config and it was fixed in
redhat-rpm-config-210-1 fc36, fc37, fc38 (rawhide).
https://bugzilla.redhat.com/show_bug.cgi?id=2043092#c66

So, I will test by building the rubygem-nio4r package on the built
Ruby just in case. This is a step to verify the issue that you
reported on the Bugzilla ticket.

-- 
Jun | He - Him | Timezone: UTC+1 or 2, Czech Republic
See  for
the timezone.
___
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 rawhide FTBFS

2022-11-02 Thread Jun Aruga (he / him)
On Mon, Oct 31, 2022 at 6:54 PM Vít Ondruch  wrote:
>
> Good catch.

Here is the PR to the rpms/ruby rawhide.
https://src.fedoraproject.org/rpms/ruby/pull-request/135#

> Not surprisingly, RubyGems fail as well 🫤
>
>
> https://koschei.fedoraproject.org/package/rubygems?collection=f38

Okay, the rpms/rubygems is next after the rpms/ruby.

> And looking at git updates, I'd be not surprised if also older Fedoras
> get broken soon:
>
>
> https://bodhi.fedoraproject.org/updates/?packages=git

The git 2.38.1 is on f37, f36 and f35 too.
Maybe it's better to push this PR commit to these fedoras too after
merging the rawhide PR.

-- 
Jun | He - Him | Timezone: UTC+1 or 2, Czech Republic
See  for
the timezone.
___
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 rawhide FTBFS

2022-10-27 Thread Jun Aruga (he / him)
Just a quick note.
Right now the rpms/ruby rawhide is FTBFS.[1]

```
  1) Failure:
TestGemSourceGit#test_checkout_submodules
[/builddir/build/BUILD/ruby-3.1.2/test/rubygems/test_gem_source_git.rb:72]:
fatal: transport 'file' not allowed
fatal: clone of
'/builddir/build/BUILD/ruby-3.1.2/tmp/test_rubygems_20221027-81957-35u31l/git/b'
into submodule path
'/builddir/build/BUILD/ruby-3.1.2/tmp/test_rubygems_20221027-81957-35u31l/git/a/b'
failed
Finished tests in 975.746481s, 21.9330 tests/s, 2819.2661 assertions/s.
21401 tests, 2750889 assertions, 1 failures, 0 errors, 55 skips
```

The reason is the [2]. The git-core 2.38.1-1.fc38 is used as a
dependency on the rawhide now.
This failure happens on Git >= 2.38.1. This failure doesn't happen on
Git 2.28.0.[3]

The patch is [4][5]. I confirmed it passed the tests on the
private-ruby-3.2 branch.

As I will work for Fedora again next Wednesday, feel free to take and
apply the patch to the rawhide branch and backport.

[1] https://koji.fedoraproject.org/koji/taskinfo?taskID=93491139
[2] 
https://github.blog/2022-10-18-git-security-vulnerabilities-announced/#cve-2022-39253
[3] https://twitter.com/hsbt/status/1582565364700893184 (Japanese)
[4] 
https://github.com/rubygems/rubygems/commit/e29c79d1891a656ec50c8bd4ff6d8b11ca393f28
[5] https://github.com/ruby/ruby/commit/dae843f6b7502f921a7e66f39e3714a39d860181

-- 
Jun | He - Him | Timezone: UTC+1 or 2, Czech Republic
See  for
the timezone.
___
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

2022-10-27 Thread Jun Aruga (he / him)
On Thu, Oct 27, 2022 at 4:14 PM Jarek Prokop  wrote:

> Hi,
> On 10/27/22 15:14, Jun Aruga (he / him) wrote:
>
> On Fri, Oct 21, 2022 at 3:39 PM Vít Ondruch  
>  wrote:
>
> Dne 21. 10. 22 v 13:56 Mamoru TASAKA napsal(a):
>
> 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)?
>
> Thanks for the work.
> I am trying to build on the private-ruby-3.2 branch.
> Where is the SRPM file including the ruby-3.2.0-70bc8cc6c2.tar.xz ?
> Could you share?
>
> I have been testing Ruby 3.2.0 preview2. The outcome is 
> below.https://www.ruby-lang.org/en/news/2022/09/09/ruby-3-2-0-preview2-released/
>
> ## WebAssembly support
>
> This is one of the new features in Ruby 3.2.0, and that is to build a
> Ruby source for the WebAssembly target, and then run a Ruby code on
> the Ruby on the Web Assembly runtime.
> But this feature is exclusive from the current Ruby in the Ruby RPM.
> When building Ruby for that, we can not run the Ruby without the
> WebAssembly runtime.
> So, I think it's not realistic to include the feature in the Ruby RPM.
>
> I do not think any distribution will be able to reasonably support this.
>
> From my understanding of WASM, it is required to crosscompile everything
> needed to run the application,
> so that it is usable in browser or other WASM runtimes.
>
> It is a feature that upstream supports, which is nice from language
> usability perspective, but not something we are able to or want to
> reasonably support.
> Those who want to use it, need to crosscompile whole Ruby from source, as
> is the case with any other C application.
>
> Or, such people can download the .src.rpm unpack it and adjust the
> specfile to match their needs.
>
> I think it is comparable to mruby (the lightweight embeddable ruby):
> https://github.com/mruby/mruby
> These kinds of applications are better fine tuned by app developers
> themselves than the Linux distribution packagers.
>

Hi Jarek,
Thanks for sharing the info. For the mruby, in the past I developed an iOS
application on iPad and iPhone. In the application build process, I built
an Objective-C app with C or C++ library sources. The libraries are managed
as static libraries. So, I guess the mruby's case is something like this.
For the WASM, the application developers can build the Ruby with the WASM
target when building their applications.


> See devel@ mailing list - Subject: "Packaging a cross-compilation
> environment (wasi-libc)" for details.
>
> ## Regexp timeout
>
> I found a small issue on a new feature. Then it was 
> fixed.https://bugs.ruby-lang.org/issues/19055
>
> ## YJIT support
>
> YJIT is to improve the performance of Ruby code by using Rust. It's
> like MJIT (previously called JIT) by using gcc or clang.
>
> I think adding this feature in the Ruby RPM is realistic. So, I tested
> this feature with the upstream Ruby source code in some cases.
>
> Because in my understanding the YJIT is only available with the `ruby
> --yijt` option. It seems that it doesn't affect the current Ruby
> features. Possibly we need to add "BuildRequires rust cargo", and also
> needs a dependency rust (and cargo?) to run the `ruby --yjit`.
>
> ```
> $ ./configure --enable-yjit ...
> $ make
> $ make install
>
> $ ruby --help
> ...
> Features:
>   gemsrubygems (only for debugging, default: enabled)
> ...
>   mjitC compiler-based JIT compiler (default: disabled)
>   yjitin-process JIT compiler (default: disabled) # <=
> This line appears. And this feature is only enabled with the `ruby
> --yjit`.
> ...
>
> $ ruby --yjit my_script.rb
> ```
>
> See the following links for 
> details.https://bugs.ruby-lang.org/issues/18481https://github.com/ruby/ruby/blob/master/doc/yjit/yjit.md#installation
>
> I read that document, we should only need the `%{_bindir}/rustc`. Ruby
> upstream was successful in keeping the
> production version without any ext

Re: Ruby 3.2

2022-10-27 Thread Jun Aruga (he / him)
> Thanks for the work.
> I am trying to build on the private-ruby-3.2 branch.
> Where is the SRPM file including the ruby-3.2.0-70bc8cc6c2.tar.xz ?
> Could you share?

I found the ruby-3.2.0-70bc8cc6c2.tar.xz at
https://koji.fedoraproject.org/koji/taskinfo?taskID=92950720 . You
already shared it.

-- 
Jun | He - Him | Timezone: UTC+1 or 2, Czech Republic
See  for
the timezone.
___
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

2022-10-27 Thread Jun Aruga (he / him)
On Fri, Oct 21, 2022 at 3:39 PM Vít Ondruch  wrote:
>
>
> Dne 21. 10. 22 v 13:56 Mamoru TASAKA napsal(a):
> > 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)?

Thanks for the work.
I am trying to build on the private-ruby-3.2 branch.
Where is the SRPM file including the ruby-3.2.0-70bc8cc6c2.tar.xz ?
Could you share?

I have been testing Ruby 3.2.0 preview2. The outcome is below.
https://www.ruby-lang.org/en/news/2022/09/09/ruby-3-2-0-preview2-released/

## WebAssembly support

This is one of the new features in Ruby 3.2.0, and that is to build a
Ruby source for the WebAssembly target, and then run a Ruby code on
the Ruby on the Web Assembly runtime.
But this feature is exclusive from the current Ruby in the Ruby RPM.
When building Ruby for that, we can not run the Ruby without the
WebAssembly runtime.
So, I think it's not realistic to include the feature in the Ruby RPM.

See devel@ mailing list - Subject: "Packaging a cross-compilation
environment (wasi-libc)" for details.

## Regexp timeout

I found a small issue on a new feature. Then it was fixed.
https://bugs.ruby-lang.org/issues/19055

## YJIT support

YJIT is to improve the performance of Ruby code by using Rust. It's
like MJIT (previously called JIT) by using gcc or clang.

I think adding this feature in the Ruby RPM is realistic. So, I tested
this feature with the upstream Ruby source code in some cases.

Because in my understanding the YJIT is only available with the `ruby
--yijt` option. It seems that it doesn't affect the current Ruby
features. Possibly we need to add "BuildRequires rust cargo", and also
needs a dependency rust (and cargo?) to run the `ruby --yjit`.

```
$ ./configure --enable-yjit ...
$ make
$ make install

$ ruby --help
...
Features:
  gemsrubygems (only for debugging, default: enabled)
...
  mjitC compiler-based JIT compiler (default: disabled)
  yjitin-process JIT compiler (default: disabled) # <=
This line appears. And this feature is only enabled with the `ruby
--yjit`.
...

$ ruby --yjit my_script.rb
```

See the following links for details.
https://bugs.ruby-lang.org/issues/18481
https://github.com/ruby/ruby/blob/master/doc/yjit/yjit.md#installation
https://github.com/Shopify/yjit-bench

Jun

--
Jun | He - Him | Timezone: UTC+1 or 2, Czech Republic
See  for
the timezone.
___
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

2022-10-13 Thread Jun Aruga (he / him)
Thanks for the work, Mamoru.

> * Removal of File.exists? / Object#=~ / "tainted"ness affects several pacakges

It seems the method was removed in Ruby 3.2.0.
https://github.com/ruby/ruby/blob/v3_2_0_preview2/NEWS.md#removed-methods

> The following deprecated methods are removed.
> ...
> * `File.exists?` [[Feature #17391]]
> ...

> * rubygem-jekyll seems to be affected by keywords / positional argument 
> treatment
>change??

Not sure.

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

It sounds like a good idea.

-- 
Jun | He - Him | Timezone: UTC+1 or 2, Czech Republic
See  for
the timezone.
___
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: Embedded fonts in HTML documentation

2022-10-07 Thread Jun Aruga (he / him)
> Can one assume that updates to the Ruby packaging process will remove
> embedded fonts from all Ruby gems with generated html documentation?
> This would help with current reviews.
>
> [1]
> https://docs.fedoraproject.org/en-US/packaging-guidelines/#_avoid_bundling_of_fonts_in_other_packages

Possibly the steps to remove fonts from Ruby gems is

1 Update rpms/ruby RPM package (including rubygem-rdoc is a
sub-package of the rpms/ruby) with the rdoc logic to avoid generating
duplicated font logic.
2. When someone will build rpms/rubygem-foo with `fedpkg build`, the
rubygem-foo's RPM is built without duplicated font files.

It's not like building all the rpms/rubygem-* packages at the same time.

-- 
Jun | He - Him | Timezone: UTC+1 or 2, Czech Republic
See  for
the timezone.
___
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

2022-09-19 Thread Jun Aruga (he / him)
On Fri, Sep 16, 2022 at 7:03 PM Vít Ondruch  wrote:
>
> Hi everybody,
>
> I think it is the highest time to kick of the Ruby 3.2 thread. So here
> we go. I have just pushed the first update to private-ruby-3.2 branch
> [1] and here is the scratch build:
>
> https://koji.fedoraproject.org/koji/taskinfo?taskID=92083633
>
> There is nothing what would stand out.
>
> Nevertheless, I was testing the `--enable-mkmf-verbose` configure option
> submitted upstream by @jaruga (thx a bunch) with the ByeBug example just
> to find out that ByeBug is broken due to some upstream changes [3]. So
> just early heads up that there will be needed some changes for Ruby 3.2.
>
> As always, feedback is appreciate via regular channels.
>
>
> Vít

Thanks for starting to prepare the new Ruby. It seems that this year,
the preparation is earlier than before.
I am not sure that the ByeBug issue is directly related to the
`--enable-mkmf-verbose` option. I think the issue doesn't block adding
the configuration option, right?

Seeing your commit:
https://src.fedoraproject.org/rpms/ruby/c/6a98c151e6205b6d5774d0436f6492d97c321eb4?branch=private-ruby-3.2
, I thought backporting the upstream commit to rawhide before
releasing Ruby 3.2 would be good idea. And here is the pull-request I
sent now.
https://src.fedoraproject.org/rpms/ruby/pull-request/133

-- 
Jun | He - Him | Timezone: UTC+1 or 2, Czech Republic
See  for
the timezone.
___
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: RubyGems 3.3.22 + Bundler 2.3.22 in Rawhide

2022-09-15 Thread Jun Aruga (he / him)
On Thu, Sep 15, 2022 at 4:34 PM Vít Ondruch  wrote:
>
> Hi,
>
> Since the independent RubyGems package was FTBFS for some time and there
> was no Ruby update for a while, I have decided that it is probably about
> the time to try to fix and update RubyGems. Since RubyGems are nowadays
> shipped with Bundler and we enforce that Bundler has to be the same or
> newer version then sipped with them, this also forced update or Bundler.
> And here it is:
>
> https://bodhi.fedoraproject.org/updates/FEDORA-2022-8d0a0920e1
>
> Since the independent packages were not updated and used for a while,
> please give it some careful testing and report back if there is
> something wrong. Hopefully there won't be any issues, but one never know.

Wow, this is great. I guess previously the rpms/rubygem-bundler was
1.x. The independent package might be helpful to test with the new
RubyGems and Bundler.
Thanks.

-- 
Jun | He - Him | Timezone: UTC+1 or 2, Czech Republic
See  for
the timezone.
___
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: rpms/ruby module stream branches build failures

2022-08-16 Thread Jun Aruga (he / him)
On Wed, Jul 27, 2022 at 4:08 PM Vít Ondruch  wrote:
>
>
> Dne 26. 07. 22 v 21:36 Jun Aruga (he / him) napsal(a):
> >>>> I'd suggest against building Ruby 3.0 on F36+
> >>> Oh thanks. I missed the part.
> >>> How about using openssl1.1-devel
> >>
> >> Is it really available? I know there were some discussions in the
> >> context of old Python support, but I was under impression that while
> >> openssl1.1 is available, the -devel packages is not.
> >>
> >> So for modules, it could be actually an option.
> > Not sure about it. We need to ask the maintainer maybe at devel@.
> >
>
> Or test it? :)

I am testing it now on the stream-ruby-2.7 branch.
https://src.fedoraproject.org/rpms/ruby/pull-request/128

The openssl1.1-devel is used from several RPMs including python3.7 and
python3.6 RPMs.
A core dump in the tests. Let me know if you know the issue and how to fix.
https://kojipkgs.fedoraproject.org//work/tasks/8548/90868548/build.log

-- 
Jun | He - Him | Timezone: UTC+1 or 2, Czech Republic
See <https://www.worldtimebuddy.com/czech-republic-prague-to-utc> for
the timezone.
___
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: rpms/ruby module stream branches build failures

2022-07-26 Thread Jun Aruga (he / him)
> >> I'd suggest against building Ruby 3.0 on F36+
> > Oh thanks. I missed the part.
> > How about using openssl1.1-devel
>
>
> Is it really available? I know there were some discussions in the
> context of old Python support, but I was under impression that while
> openssl1.1 is available, the -devel packages is not.
>
> So for modules, it could be actually an option.

Not sure about it. We need to ask the maintainer maybe at devel@.

-- 
Jun | He - Him | Timezone: UTC+1 or 2, Czech Republic
See  for
the timezone.
___
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 module stream branches build failures

2022-07-21 Thread Jun Aruga (he / him)
On Wed, Jul 20, 2022 at 4:04 PM Vít Ondruch  wrote:

>
> IOW this is OpenSSL 3.x issue. There is no simple way around unless you want
>
> 1) Backport the OpenSSL 3.x patches from Ruby 3.0
>
> 2) Use some other workaround such as including upstream version of
> OpenSSL gem.
>
> I'd suggest against building Ruby 3.0 on F36+

Oh thanks. I missed the part.
How about using openssl1.1-devel instead of openssl-devel in only Ruby
2.7 (stream-ruby-2.7), 2.6 (stream-ruby-2.6) and 2.5 (ruby-2.5)? I
don't see any problems in this way.

The openssl1.1 RPM is available on F34~F37(rawhide).
https://src.fedoraproject.org/rpms/openssl1.1
https://koji.fedoraproject.org/koji/packageinfo?packageID=32363

> > ## stream-ruby-2.6
> >
> > ./configure: line 4122: syntax error near unexpected token `fi'
> > ./configure: line 4122: `fi'
> >
> > ## ruby-2.5
> >
> > ./configure: line 4101: syntax error near unexpected token `fi'
> > ./configure: line 4101: `fi'
> >
>
> My guess would be some autotools compatibility or some wrongly applied
> patch? I know that at times, we need to change the autotools version.
> But this was typically done just in RHEL AFAIR.

Hmm, I didn't find any patch on RHEL. I may check more about this
issue when I have time.

-- 
Jun | He - Him | Timezone: UTC+1 or 2, Czech Republic
See  for
the timezone.
___
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


rpms/ruby module stream branches build failures

2022-07-01 Thread Jun Aruga
Hi,
I tried to build rpms/ruby branches below on the mock build rawhide.
Then I got the build errors below. It's great if someone will take a
look at it or give me advice.

I wanted to rebase Ruby 2.5 from 2.5.8 to 2.5.9 if possible on the
ruby-2.5 branch.
https://www.ruby-lang.org/en/news/2021/04/05/ruby-2-5-9-released/

* stream-ruby-2.7
* stream-ruby-2.6
* ruby-2.5

## stream-ruby-2.7

gcc -shared -o ../../.ext/x86_64-linux/ripper.so ripper.o -L. -L../..
-L. -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  -Wl,--build-id=sha1
-Wl,-dT,/builddir/build/BUILD/ruby-2.7.4/.package_note-ruby-0.3.0-139.fc37.x86_64.ld
-fstack-protector-strong -rdynamic -Wl,-export-dynamic -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  -Wl,--build-id=sha1
-Wl,-dT,/builddir/build/BUILD/ruby-2.7.4/.package_note-ruby-0.3.0-139.fc37.x86_64.ld
 -m64  -lruby  -lm   -lc
make[2]: Leaving directory '/builddir/build/BUILD/ruby-2.7.4/ext/ripper'
make[1]: Leaving directory '/builddir/build/BUILD/ruby-2.7.4'
make: *** [uncommon.mk:296: build-ext] Error 2


## stream-ruby-2.6

./configure: line 4122: syntax error near unexpected token `fi'
./configure: line 4122: `fi'

## ruby-2.5

./configure: line 4101: syntax error near unexpected token `fi'
./configure: line 4101: `fi'

-- 
Jun | He - Him | Timezone: UTC+1 or 2, Czech Republic
See  for
the timezone.
___
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


mysql2 gem new version 0.5.4 was released

2022-05-03 Thread Jun Aruga
The mysql2 gem version 0.5.4 was released just now after 2+ years :)
https://rubygems.org/gems/mysql2/versions/0.5.4

-- 
Jun | He - Him | Timezone: UTC+2, Czech Republic
___
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 SIG at Fedora Council Video Meeting

2022-01-07 Thread Jun Aruga
> Yeah, I can do that unless somebody else wants to beat me. So any other 
> volunteer?

I am also happy to volunteer.

-- 
Jun | He - Him
___
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

2021-09-30 Thread Jun Aruga
On Wed, Sep 29, 2021 at 5:50 PM Vít Ondruch  wrote:
>
>
> Dne 29. 09. 21 v 14:26 Jun Aruga napsal(a):
> > On Wed, Sep 29, 2021 at 12:42 PM Vít Ondruch  wrote:
> >>
> >> Dne 28. 09. 21 v 1:51 Mamoru TASAKA napsal(a):
> >>> 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
> >>
> >> Right, I hoped for some upstream response, but my plan is to reintroduce
> >> the `AC_PROG_CC` if there is no response. Hopefully I get back to this
> >> soon, because we should look into the OpenSSL 3.x compatibility.
> > It seems the following patch for the ruby.spec works to build
> > rpms/ruby on rawhide. Now building is in progress in my environment.
> > But maybe we don't want to add the gcc-c++ dependency?
> >
> > ```
> > $ git diff
> > diff --git a/ruby.spec b/ruby.spec
> > index 414eb19..c5c6edc 100644
> > --- a/ruby.spec
> > +++ b/ruby.spec
> > @@ -188,6 +188,7 @@ BuildRequires: procps
> >   %{?with_hostname:BuildRequires: %{_bindir}/hostname}
> >   BuildRequires: multilib-rpm-config
> >   BuildRequires: gcc
> > +BuildRequires: gcc-c++
>
>
> I already had discussion on this topic previously:
>
> https://bugs.ruby-lang.org/issues/17337
>
> IOW there were attempts to enforce availability of C++ but the patches
> were reverted. And I think there was more, but I can't find the references.

OK. Thanks for pointing out the ticket. I did read it now.
I admit the `+BuildRequires: gcc-c++` is a wrong way to fix. In this
case, requiring C++ compiler happens with autoconf 2.71, but doesn't
happen with the 2.69. So, it is kind of a bug.

Fortunately the Ruby developer syouhei agreed on your way to fix this
issue adding `AC_PROG_CC`. Also talking with nobu today, he told me
that he didn't want to add the C++ compiler requirement.
So, we can expect the upstream is going to fix it.
https://bugs.ruby-lang.org/issues/18156#note-8

> >   BuildRequires: make
> >   BuildRequires: zlib-devel
> >
> > @@ -619,7 +620,7 @@ rm -rf ext/fiddle/libffi*
> >   cp -a %{SOURCE3} .
> >
> >   %build
> > -autoconf
> > +./autogen.sh
> >
> >   %configure \
> >   --with-rubylibprefix='%{ruby_libdir}' \
> > ```
> >
>
> I am not autotols expert, but `autogen.sh` does not do more then
> `autoreconf` and as far as I remember, I have tried autoreconf but I
> have opted to not use it for some (forgotten) reason. Moreover:
>
> 1) The upstream tarball contains the config.{guess,sub} files

I see I missed this point. We don't need to run the `./autogen.sh` or
`autoreconf`.
I think using `autogen.sh` makes the ruby.spec unnecessarily complicated.
In older Rubies, there is no `autogen.sh` in the tarball. Using the
`autogen.sh` also makes it harder to check the difference from older
Ruby's ruby.spec.

> 2) The `%{configure}` macro replaces the config.{guess,sub} files during
> build

OK. I didn't know that.

> Therefore you would need some convincing arguments.

OK.

-- 
Jun | He - Him
___
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

2021-09-29 Thread Jun Aruga
On Wed, Sep 29, 2021 at 12:42 PM Vít Ondruch  wrote:
>
>
> Dne 28. 09. 21 v 1:51 Mamoru TASAKA napsal(a):
> > 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
>
>
> Right, I hoped for some upstream response, but my plan is to reintroduce
> the `AC_PROG_CC` if there is no response. Hopefully I get back to this
> soon, because we should look into the OpenSSL 3.x compatibility.

It seems the following patch for the ruby.spec works to build
rpms/ruby on rawhide. Now building is in progress in my environment.
But maybe we don't want to add the gcc-c++ dependency?

```
$ git diff
diff --git a/ruby.spec b/ruby.spec
index 414eb19..c5c6edc 100644
--- a/ruby.spec
+++ b/ruby.spec
@@ -188,6 +188,7 @@ BuildRequires: procps
 %{?with_hostname:BuildRequires: %{_bindir}/hostname}
 BuildRequires: multilib-rpm-config
 BuildRequires: gcc
+BuildRequires: gcc-c++
 BuildRequires: make
 BuildRequires: zlib-devel

@@ -619,7 +620,7 @@ rm -rf ext/fiddle/libffi*
 cp -a %{SOURCE3} .

 %build
-autoconf
+./autogen.sh

 %configure \
 --with-rubylibprefix='%{ruby_libdir}' \
```

-- 
Jun | He - Him
___
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

2021-09-29 Thread Jun Aruga
On Tue, Sep 28, 2021 at 1:52 AM Mamoru TASAKA  wrote:
>
> 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

OK. Thanks for the info!

-- 
Jun | He - Him
___
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


rpms/ruby FTBFS with autoconf 2.71

2021-09-27 Thread Jun Aruga
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.

-- 
Jun | He - Him
___
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


Vagrant to port from Ruby to Go lang

2021-06-13 Thread Jun Aruga
just FYI, as we are maintaining Vagrant.

https://twitter.com/mitchellh/status/1403400750311505924
> We’re porting Vagrant to Go. Actually, we already did and we have an alpha 
> almost ready to go.

-- 
Jun | He - Him
___
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: Give or orphan my rubygem-* packages

2021-06-04 Thread Jun Aruga
> > > * rubygem-thin
> > >   * A dependency of rubygem-vegas.
>
> You are registered as admin or comitter on the rubygem-thin package.
> Are you interested in being the main admin of the package? otherwise I
> will orphan the package.
>
> @valtri val...@civ.zcu.cz
> @mmagr mm...@redhat.com
> @vondruch

I orphaned it now.
https://src.fedoraproject.org/rpms/rubygem-thin

> > > * rubygem-term-ansicolor
> > >   * A dependency of rubygem-coveralls, rubygem-terminal-table.
> > >   * I can not remember why I am the main admin of this package.
>
> You are registered as admin or comitter on the rubygem-term-ansicolor
> package. Are you interested in being the main admin of the package?
> otherwise I will orphan the package.
>
> @lkundrak lkund...@v3.sk
> @stahnma mastah...@gmail.com
> @tdawson tdaw...@redhat.com
> @vondruch

I orphaned it now.
https://src.fedoraproject.org/rpms/rubygem-term-ansicolor


-- 
Jun | He - His - Him
___
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: Give or orphan my rubygem-* packages

2021-05-26 Thread Jun Aruga
On Wed, May 26, 2021 at 11:10 PM Jun Aruga  wrote:
>
> > Greetings guys,
> >
> >   is this rubygem-thin in CentOS opstools SIG? Otherwise I am not sure 
> > where could I be tracked as the maintainer of that package.

Sorry again. I am not sure about CentOS and opstools SIG.
The EPEL{7,8} target built RPMs could be used in CentOS.

-- 
Jun | He - His - Him
___
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: Give or orphan my rubygem-* packages

2021-05-26 Thread Jun Aruga
> Greetings guys,
>
>   is this rubygem-thin in CentOS opstools SIG? Otherwise I am not sure where 
> could I be tracked as the maintainer of that package.
>
> Regards,
> Martin

Hi Martin,

No. Maybe. This rubygem-thin is managed at
https://src.fedoraproject.org/rpms/rubygem-thin on Fedora project.
  The FedoraNN, EPEL{7,8}, ELN are the build targets.
If someone has an admin role on a package, they can see the "Setting"
link on the page.
e.g. https://src.fedoraproject.org/rpms/rubygem-thin/settings - Users
& Groups page is where the info is tracked.

Or you can also check your own packages and the role from the following page.
https://src.fedoraproject.org/dashboard/projects

-- 
Jun | He - His - Him
___
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: Give or orphan my rubygem-* packages

2021-05-26 Thread Jun Aruga
> > ## 1. Dependencies of RSpec
> > ## 2. Dependencies of Rails
> > ### 2-1. Required on rawhide rubygem-rails.
> > ### 2-2. Was required by the old Rails 5.2.0 (as far as I know), now
> > not required by the rawhide Rails 6.1.3.2.
> > ## 3. Dependencies of Sinatra

Thanks. Pavel, I gave the above packages to you (pvalena) now.

> > * rubygem-thin
> >   * A dependency of rubygem-vegas.

You are registered as admin or comitter on the rubygem-thin package.
Are you interested in being the main admin of the package? otherwise I
will orphan the package.

@valtri val...@civ.zcu.cz
@mmagr mm...@redhat.com
@vondruch

> > * rubygem-term-ansicolor
> >   * A dependency of rubygem-coveralls, rubygem-terminal-table.
> >   * I can not remember why I am the main admin of this package.

You are registered as admin or comitter on the rubygem-term-ansicolor
package. Are you interested in being the main admin of the package?
otherwise I will orphan the package.

@lkundrak lkund...@v3.sk
@stahnma mastah...@gmail.com
@tdawson tdaw...@redhat.com
@vondruch


I orphaned otter rubyge-* packages of mine as the packages do not have
co-maintainers.


-- 
Jun | He - His - Him
___
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


Give or orphan my rubygem-* packages

2021-05-25 Thread Jun Aruga
Hi Ruby-SIG,

Recently I started to work on the upstream Ruby project as a committer
to workin on CI and non-x86 things to keep the pipelines stable. While
it is beneficial for Fedora Ruby SIG, it gave me an opportunity to
rethink how to use time. I need to stop something to start something.

So, while I continue to contribute to the rubygem-* dist-git
repositories as ruby-packagers-sig role, I would like to communicate
with you first to give you my main-admin role or to orphan by
following the process to orphan packages.
https://fedoraproject.org/wiki/Orphaned_package_that_need_new_maintainers

Here is a list of the packages I am the main admin for, and I want to
give the main admin role or orphan. If you are interested in being the
main admin, please let me know as a reply to this email thread.
Considering the importance of the packages, maybe the plan would be
like this. I will communicate with the co-maintainer later if it is
needed.

1. Dependencies of RSpec => Need to maintain.
2. Dependencies of Rails
2-1. Required on rawhide rubygem-rails => Need to maintain.
2-2. Was required by the old Rails 5.2.0 (as far as I know), now not
required by the rawhide Rails 6.1.3.2. => ?
3. Dependencies of Sinatra => Need to maintain. Maybe.
4. Dependencies of Resque => Orphan
5. Others => Orphan

## 1. Dependencies of RSpec

* rubygem-coderay
  * a dependency of RSpec (rubygem-rspec-core) and rubygem-asciidoctor.

## 2. Dependencies of Rails

### 2-1. Required on rawhide rubygem-rails.

* rubygem-marcel
* rubygem-nio4r
* rubygem-puma
* rubygem-rack
* rubygem-websocket-extensions

### 2-2. Was required by the old Rails 5.2.0 (as far as I know), now
not required by the rawhide Rails 6.1.3.2.

* rubygem-mimemagic
  This gem was migrated into rubygem-marcel.
* rubygem-spring-watcher-listen

## 3. Dependencies of Sinatra

* rubygem-mustermann
  * a dependency of rubygem-sinatra.

## 4. Dependencies of Resque

* rubygem-resque
  * There is no package depending on this package.
  * I started to manage this package in the past, because I saw that
the 3scale team used the own forked version.
I thought it might be good to maintain it as RPM.
But actually no reason to continue to maintain this package.
* rubygem-mono_logger
  * a dependency of rubygem-resque.
* rubygem-vegas
  * A dependency of rubygem-resque.

## 5. Others

* rubygem-thin
  * A dependency of rubygem-vegas.
* rubygem-redis-namespace
  * There is no package depending on this package.
* rubygem-ditz
  * There is no package depending on this package.
* rubygem-trollop
  * A dependency of rubygem-ditz and rubygem-rbvmomi.
  * I can not remember why I am the main admin of this package.
* rubygem-term-ansicolor
  * A dependency of rubygem-coveralls, rubygem-terminal-table.
  * I can not remember why I am the main admin of this package.

Regards,
Jun

-- 
Jun | He - His - Him
___
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 errors/warnings by rpmlint

2021-03-23 Thread Jun Aruga
> I will send a PR to add ruby.rpmlintrc as a small start.

Here is the PR. Could you review it? Thanks.
https://src.fedoraproject.org/rpms/ruby/pull-request/79

-- 
Jun | He - His - Him
___
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 errors/warnings by rpmlint

2021-03-23 Thread Jun Aruga
> We can see the informative result even when there is a `ruby.rpmlintrc` file.
> The `ruby.rpmlintrc` file does not harm our current manual operation
> when someone wants to see the original informative result.
>
> ```
> $ cat ruby.rpmlintrc
> addFilter(r'^ruby.spec:\d+: E: use-of-RPM_SOURCE_DIR$')
> ```
>
> The rpmlint without `--file` option shows the original information.
>
> ```
> $ rpmlint ruby.spec
> ruby.spec:20: E: use-of-RPM_SOURCE_DIR
> ruby.spec:231: W: unversioned-explicit-provides bundled(ccan-build_assert)
> ruby.spec:232: W: unversioned-explicit-provides bundled(ccan-check_type)
> ruby.spec:233: W: unversioned-explicit-provides bundled(ccan-container_of)
> ruby.spec:234: W: unversioned-explicit-provides bundled(ccan-list)
> 0 packages and 1 specfiles checked; 1 errors, 4 warnings.
> ```
>
> When using the `--file` option, we can suppress the false positive
> intentionally by specifying the message.
>
> ```
> $ rpmlint --file ruby.rpmlintrc ruby.spec
> ruby.spec:231: W: unversioned-explicit-provides bundled(ccan-build_assert)
> ruby.spec:232: W: unversioned-explicit-provides bundled(ccan-check_type)
> ruby.spec:233: W: unversioned-explicit-provides bundled(ccan-container_of)
> ruby.spec:234: W: unversioned-explicit-provides bundled(ccan-list)
> 0 packages and 1 specfiles checked; 0 errors, 4 warnings.
> ```

After discussing with Vit now, we agreed with starting to use ruby.rpmlintrc.
His concern, the pain with ruby.rpmlintrc was that the ignoring
specific errors/warnings might trigger to hide unknown or unintended
errors/warnings too.
But seeing above my example using the regular expression almost
perfectly matching "^...$", he changed his mind, and we agreed it's
unlikely that the matching pattern hides the unknown errors/warnings.
I will send a PR to add ruby.rpmlintrc as a small start.

So, let's keep in mind to always use the perfectly matching patterns
or prefix matching patterns that do not hide unknown errors/warnings.


-- 
Jun | He - His - Him
___
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 errors/warnings by rpmlint

2021-03-23 Thread Jun Aruga
> How about just removing the `%{ruby_libdir}/io` in rubygem-io-console
> like this with a comment?
> The directory actually always exists because ruby-libs are required to
> run rubygem-io-console.
>
> ```
> $ git diff
> diff --git a/ruby.spec b/ruby.spec
> index c43fb0a..6949ea7 100644
> --- a/ruby.spec
> +++ b/ruby.spec
> @@ -1261,7 +1261,7 @@ MSPECOPTS=""
>  %{gem_dir}/specifications/bigdecimal-%{bigdecimal_version}.gemspec
>
>  %files -n rubygem-io-console
> -%{ruby_libdir}/io
> +# The %%{ruby_libdir}/io exists in ruby-libs.
>  %{ruby_libarchdir}/io/console.so
>  %{_libdir}/gems/%{name}/io-console-%{io_console_version}
>  %{gem_dir}/gems/io-console-%{io_console_version}
> ```

I discussed this topic with Vit now, and I would cancel my suggestion.

In the discussion,

1. The comment is not so useful in this case. The comment might be
outdated in the future.
2. The concerns about removing `%{ruby_libdir}/io` from rubygem-io-console are

* Maintainability.
  In the future, the `%{ruby_libdir}/io` entry will be removed or
changed in the ruby-libs if the upstream will change this directory
structure,
  Then we might forget to consider adding or changing for the
`%{ruby_libdir}/io` in rubygem-io-console.
* He wants to keep rubygem-io-console as independently or separately
from ruby-libs.
  He would like to move rubygem-io-console to StdLib such as
rubygem-did_you_mean did, if he wants to fix something.

I agreed with it.

-- 
Jun | He - His - Him
___
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 errors/warnings by rpmlint

2021-03-22 Thread Jun Aruga
On Mon, Mar 22, 2021 at 12:59 PM Jun Aruga  wrote:
>
> > >> This directory is certainly needed for other `io` libraries. There is
> > >> more then just io-console.
> > > Did you mean the "other `io` libraries" are the other libraries
> > > requiring `io-soncole` gem?
> >
> >
> > https://src.fedoraproject.org/rpms/ruby/blob/rawhide/f/ruby.spec#_1097
> >
> >
> > > Are you thinking about the case where ruby-libs is installed but
> > > rubygem-io-console is not installed?
> > > But the directories of the rubygem-bigdecimal (`%exclude
> > > %{ruby_libdir}/bigdecimal*`), rubygem-irb (`%exclude
> > > %{ruby_libdir}/irb*
> > > `), and etc are already excluded in the ruby-libs. Why don't we do it
> > > for rubygem-io-console too?
> > >
> > >> This directory could be in theory dropped from rubygem-io-console, but
> > >> there is not any benefit IMO. I prefer the rubygem-io-console to be self
> > >> contained.
> > > I do not understand the "the rubygem-io-console to be self contained.".
> > > Could you explain more about it?
> > >
> >
> > If the libraries I have referred above were e.g. removed or extracted
> > into independent gems, then the `io` directory could become unowned.
> > That is not good. It is much better if it is owned twice.
>
> Ah OK. The other "io" libraries `io/nonblock.so` and `io/wait.so`
> should not belong in the io-console.
>
> ```
> %{ruby_libarchdir}/io/nonblock.so
> %{ruby_libarchdir}/io/wait.so
> ```
>
> ```
> %{ruby_libarchdir}/io/console.so
> ```
>
> I see the source files are in the io directory.
>
> ```
> $ find . -name nonblock.c
> ./ext/io/nonblock/nonblock.c
>
> $ find . -name wait.c
> ./ext/io/wait/wait.c
>
> $ find . -name console.c
> ./ext/io/console/console.c
> ```

How about just removing the `%{ruby_libdir}/io` in rubygem-io-console
like this with a comment?
The directory actually always exists because ruby-libs are required to
run rubygem-io-console.

```
$ git diff
diff --git a/ruby.spec b/ruby.spec
index c43fb0a..6949ea7 100644
--- a/ruby.spec
+++ b/ruby.spec
@@ -1261,7 +1261,7 @@ MSPECOPTS=""
 %{gem_dir}/specifications/bigdecimal-%{bigdecimal_version}.gemspec

 %files -n rubygem-io-console
-%{ruby_libdir}/io
+# The %%{ruby_libdir}/io exists in ruby-libs.
 %{ruby_libarchdir}/io/console.so
 %{_libdir}/gems/%{name}/io-console-%{io_console_version}
 %{gem_dir}/gems/io-console-%{io_console_version}
```

-- 
Jun | He - His - Him
___
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 errors/warnings by rpmlint

2021-03-22 Thread Jun Aruga
On Mon, Mar 22, 2021 at 12:31 PM Vít Ondruch  wrote:
>
>
> Dne 22. 03. 21 v 11:44 Jun Aruga napsal(a):
> >
> >>>> ### 5.
> >>>>
> >>>> ```
> >>>> ruby-default-gems.noarch: W: obsolete-not-provided rubygem-did_you_mean
> >>>> If a package is obsoleted by a compatible replacement, the obsoleted 
> >>>> package
> >>>> should also be provided in order to not cause unnecessary dependency
> >>>> breakage.
> >>>> If the obsoleting package is not a compatible replacement for the old 
> >>>> one,
> >>>> leave out the Provides.
> >>>>
> >>>> ruby-default-gems.noarch: W: obsolete-not-provided rubygem-openssl
> >>>> If a package is obsoleted by a compatible replacement, the obsoleted 
> >>>> package
> >>>> should also be provided in order to not cause unnecessary dependency
> >>>> breakage.
> >>>> If the obsoleting package is not a compatible replacement for the old 
> >>>> one,
> >>>> leave out the Provides.
> >>>>
> >>>> ruby-default-gems.noarch: W: obsolete-not-provided rubygem-racc
> >>>> If a package is obsoleted by a compatible replacement, the obsoleted 
> >>>> package
> >>>> should also be provided in order to not cause unnecessary dependency
> >>>> breakage.
> >>>> If the obsoleting package is not a compatible replacement for the old 
> >>>> one,
> >>>> leave out the Provides.
> >>>> ```
> >>> It think this should not be a warning, but a mere INFO. Note the 'IF'.
> >>>
> >>>> =>
> >>>> The Provides line needs for the Obsolete line.
> >>> I don't think we want to create Provides for those, as those are 
> >>> "Default" gems.
> >>
> >> The Obsoletes/Provides are always tricky. I think these are fine as they
> >> are.
> > Could you explain more about the Obsoletes/Provides are always tricky?
> > Maybe I do not understand "Provides" syntax well.
> > Do you know a helpful web page explaining it?
>
>
> 1) It is always up to debate, what `compatible replacement` actually
> means. `ruby-default-gems` certainly provides did_you_mean, but how
> compatible it is? The original independent gem had definitely some
> idiosyncrasies, while the bundle gem has different set.
>
> 2) If you start with `Provides`, then the question is when to stop
> providing them. If something depends on them, the dependencies won't be
> fixed any time before the `Provides` is removed (or the chances are just
> slim).
>
> 3) After all, the message is in this case is clear, get back closer to
> the upstream. People should not bother with rubygem-did_you_mean
> anymore. This should be forgotten.

OK. That makes sense. Maybe the rpmlint warnings should be suppressed by us.

> >>>> ## rpms/ruby CI to add rpmlint test.
> >>>>
> >>>> Can we check the rpmlint issues on an early timing: pull-request and 
> >>>> push?
> >>>> I think adding the rpmlint check ro rpm/ruby CI is a possible way
> >>>> related to this ticket.
> >>> Yes, I agree we could add this for the CI (functional). I'm not sure some 
> >>> generic checks aren't considered already for all PRs- I'll inquire abou 
> >>> it and follow up with you on IRC.
> >>>
> >>>> https://src.fedoraproject.org/rpms/ruby/pull-request/67
> >>>> Shall we add it after the PR #67 will be merged?
> >>
> >> The Zuul is running rpmlint on PR. You can check the PR you've
> >> referenced above.
> > That's good news. I can see the running rpmlint there.
> >
> > https://src.fedoraproject.org/rpms/ruby/pull-request/78#comment-70514
> >> rpm-linter : FAILURE in 7m 26s
> >> container: Run rpmlint
> >>
> >> rpmlint /root/src/src.fedoraproject.org/rpms/ruby/*.rpm
> > But this rpmlint command is not enough. The rpmlint for the
> > `ruby.spec` should be added like this.
> > Where can we report this issue?
>
>
> @fbo was always helpful, e.g. here:
>
> https://src.fedoraproject.org/rpms/ruby/pull-request/70#comment-60863

OK. I am asking @fbo to fix this issue on the following comment.
https://src.fedoraproject.org/rpms/ruby/pull-request/78#comment-70600

> > ```
> > $ rpmlint /root/src/src.fedoraproject.org/rpms/ruby/*.rpm /path/to/*.spec
> &g

Re: Ruby errors/warnings by rpmlint

2021-03-22 Thread Jun Aruga
> >> This directory is certainly needed for other `io` libraries. There is
> >> more then just io-console.
> > Did you mean the "other `io` libraries" are the other libraries
> > requiring `io-soncole` gem?
>
>
> https://src.fedoraproject.org/rpms/ruby/blob/rawhide/f/ruby.spec#_1097
>
>
> > Are you thinking about the case where ruby-libs is installed but
> > rubygem-io-console is not installed?
> > But the directories of the rubygem-bigdecimal (`%exclude
> > %{ruby_libdir}/bigdecimal*`), rubygem-irb (`%exclude
> > %{ruby_libdir}/irb*
> > `), and etc are already excluded in the ruby-libs. Why don't we do it
> > for rubygem-io-console too?
> >
> >> This directory could be in theory dropped from rubygem-io-console, but
> >> there is not any benefit IMO. I prefer the rubygem-io-console to be self
> >> contained.
> > I do not understand the "the rubygem-io-console to be self contained.".
> > Could you explain more about it?
> >
>
> If the libraries I have referred above were e.g. removed or extracted
> into independent gems, then the `io` directory could become unowned.
> That is not good. It is much better if it is owned twice.

Ah OK. The other "io" libraries `io/nonblock.so` and `io/wait.so`
should not belong in the io-console.

```
%{ruby_libarchdir}/io/nonblock.so
%{ruby_libarchdir}/io/wait.so
```

```
%{ruby_libarchdir}/io/console.so
```

I see the source files are in the io directory.

```
$ find . -name nonblock.c
./ext/io/nonblock/nonblock.c

$ find . -name wait.c
./ext/io/wait/wait.c

$ find . -name console.c
./ext/io/console/console.c
```

-- 
Jun | He - His - Him
___
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 errors/warnings by rpmlint

2021-03-22 Thread Jun Aruga
> And I love to see all the SUCCESS results as a default. Because the
> default green status makes us notice new issues easily.
> I think it's time to create ruby.rpmlintrc.
>
> Seeing the example of python3.9 package, it seems that we can
> intentionally ignore the false positive errors/warnings for a specific
> file
> https://src.fedoraproject.org/rpms/python3.9/blob/rawhide/f/python3.9.rpmlintrc
> https://fedoraproject.org/wiki/Taskotron/Tasks/dist.rpmlint

Other examples.
https://src.fedoraproject.org/rpms/perl/blob/rawhide/f/perl.rpmlintrc
https://src.fedoraproject.org/rpms/clang/blob/rawhide/f/clang.rpmlintrc

-- 
Jun | He - His - Him
___
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 errors/warnings by rpmlint

2021-03-22 Thread Jun Aruga
> >> ## Result
> >>
> >> ### 1.
> >>
> >> ruby.spec:20: E: use-of-RPM_SOURCE_DIR
> >> You use $RPM_SOURCE_DIR or %{_sourcedir} in your spec file. If you have to
> >> use
> >> a directory for building, use $RPM_BUILD_ROOT instead.
> >>
> >> =>
> >> The `%{_sourcedir}/%{ruby_archive}.tar.xz` can be replaced to
> >> `%{SOURCE0}`? I am not sure.
> > Yes, I think so.
>
>
> ~~~
>
> $ fedpkg srpm
> stat: cannot statx
> '/home/vondruch/fedora-scm/own/ruby/%{name}-3.0.0-684649ea05.tar.xz': No
> such file or directory
> warning: Macro expanded in comment on line 20: %(stat --printf='@%Y'
> %{_sourcedir}/%{ruby_archive}.tar.xz | date -f - +"%Y%m%d")
>
> stat: cannot statx '%{SOURCE0}': No such file or directory
>
>
>
> stat: cannot statx
> '/home/vondruch/fedora-scm/own/ruby/%{name}-3.0.0-684649ea05.tar.xz': No
> such file or directory
> warning: Macro expanded in comment on line 20: %(stat --printf='@%Y'
> %{_sourcedir}/%{ruby_archive}.tar.xz | date -f - +"%Y%m%d")
>
> stat: cannot statx '%{SOURCE0}': No such file or directory
> setting SOURCE_DATE_EPOCH=1614643200
> Wrote:
> /home/vondruch/fedora-scm/own/ruby/ruby-3.0.0-0.146.git684649ea05.fc35.src.rpm
>
> ~~~
>
>
> The order in .spec file could be possibly different, but there would be
> probably different issues. But I am open to suggestions.

Humm, thanks for checking.

> >> ### 2.
> >>
> >> ruby-default-gems.noarch: W: summary-ended-with-dot C Default gems
> >> which are part of Ruby StdLib.
> >> Summary ends with a dot.
> >>
> >> =>
> >> The summary ending dot needs to be removed.
> > Yes.
> >
>
> Good catch:
>
> https://src.fedoraproject.org/rpms/ruby/c/dae90ef93d0f3eb43b09780368a236cb4f2b850f?branch=rawhide

Thanks!

> >> ### 3.
> >>
> >> ruby-libs.x86_64: E: missing-call-to-chdir-with-chroot
> >> /usr/lib64/libruby.so.3.0.0
> >> This executable appears to call chroot without using chdir to change the
> >> current directory. This is likely an error and permits an attacker to break
> >> out of the chroot by using fchdir. While that's not always a security 
> >> issue,
> >> this has to be checked.
> >>
> >> =>
> >> Not sure when this error came.
> > This is probably inside some generic Ruby code. IMHO this is a false 
> > positive.
> >
> > E.g. https://www.rubydoc.info/stdlib/core/Dir.chroot
>
>
> Very likely false positive. But feel free to investigate deeper.

OK.

> >> ### 5.
> >>
> >> ```
> >> ruby-default-gems.noarch: W: obsolete-not-provided rubygem-did_you_mean
> >> If a package is obsoleted by a compatible replacement, the obsoleted 
> >> package
> >> should also be provided in order to not cause unnecessary dependency
> >> breakage.
> >> If the obsoleting package is not a compatible replacement for the old one,
> >> leave out the Provides.
> >>
> >> ruby-default-gems.noarch: W: obsolete-not-provided rubygem-openssl
> >> If a package is obsoleted by a compatible replacement, the obsoleted 
> >> package
> >> should also be provided in order to not cause unnecessary dependency
> >> breakage.
> >> If the obsoleting package is not a compatible replacement for the old one,
> >> leave out the Provides.
> >>
> >> ruby-default-gems.noarch: W: obsolete-not-provided rubygem-racc
> >> If a package is obsoleted by a compatible replacement, the obsoleted 
> >> package
> >> should also be provided in order to not cause unnecessary dependency
> >> breakage.
> >> If the obsoleting package is not a compatible replacement for the old one,
> >> leave out the Provides.
> >> ```
> > It think this should not be a warning, but a mere INFO. Note the 'IF'.
> >
> >> =>
> >> The Provides line needs for the Obsolete line.
> > I don't think we want to create Provides for those, as those are "Default" 
> > gems.
>
>
> The Obsoletes/Provides are always tricky. I think these are fine as they
> are.

Could you explain more about the Obsoletes/Provides are always tricky?
Maybe I do not understand "Provides" syntax well.
Do you know a helpful web page explaining it?

> >> ### 6.
> >>
> >> ```
> >> rubygem-rbs.noarch: E: non-executable-script
> >> /usr/share/gems/gems/rbs-1.0.0/bin/annotate-with-rdoc 644 /usr/bin/env
> >> ruby
> >> This text file contains a shebang or is located in a path dedicated for
> >> executables, but lacks the executable bits and cannot thus be executed.  If
> >> the file is meant to be an executable script, add the executable bits,
> >> otherwise remove the shebang or move the file elsewhere.
> >> ```
> >>
> >> This is the same for other files (total 8 files) under
> >> /usr/share/gems/gems/rbs-1.0.0/bin/.
>
>
> This is low priority. I think it would be actually better, if upstream
> have not shipped these files at all, because these are in fact
> development dependencies. But feel free submit PR fixing these (by
> adding the executable bits probably).

OK.

> >> ### 7.
> >>
> >> ```
> >> ruby-libs.x86_64: W: library-not-linked-against-libc
> >> /usr/lib64/ruby/continuation.so
> >> ruby-libs.x86_64: W: library-not-linked-against-libc
> >> /usr/lib64/ruby/enc/big5

Re: Ruby errors/warnings by rpmlint

2021-03-22 Thread Jun Aruga
> The issue here is that rpmlint can't deffer that rubygem-io-console
> transitively depends on ruby-libs, therefore the symlink is never dangling.

Yes, I understand the warning itself is false positive.

> >> =>
> >> This warning was a hint to find "another issue" to fix.
> >> The issue is the directory entry `%{ruby_libdir}/io` is duplicated
> >> between ruby-libs and rubygem-io-console RPM in ruby.spec.
>
>
> There is nothing wrong with duplicated directory ownership.

OK. I had never seen the duplicated directory ownership.

> >> Maybe the directory entry in ruby-libs should be removed like this.
> >>
> >> ```
> >> @@ -942,6 +942,7 @@ MSPECOPTS=""
> >>   # Platform independent libraries.
> >>   %dir %{ruby_libdir}
> >>   %exclude %{ruby_libdir}/bigdecimal*
> >> +%exclude %{ruby_libdir}/io
> >>   %exclude %{ruby_libdir}/irb*
> >>   %exclude %{ruby_libdir}/json*
> >>   %exclude %{ruby_libdir}/psych*
> >> @@ -964,7 +965,6 @@ MSPECOPTS=""
> >>   %{ruby_libdir}/find.rb
> >>   %{ruby_libdir}/forwardable*
> >>   %{ruby_libdir}/getoptlong*
> >> -%{ruby_libdir}/io
>
>
> This directory is certainly needed for other `io` libraries. There is
> more then just io-console.

Did you mean the "other `io` libraries" are the other libraries
requiring `io-soncole` gem?
Are you thinking about the case where ruby-libs is installed but
rubygem-io-console is not installed?
But the directories of the rubygem-bigdecimal (`%exclude
%{ruby_libdir}/bigdecimal*`), rubygem-irb (`%exclude
%{ruby_libdir}/irb*
`), and etc are already excluded in the ruby-libs. Why don't we do it
for rubygem-io-console too?

> This directory could be in theory dropped from rubygem-io-console, but
> there is not any benefit IMO. I prefer the rubygem-io-console to be self
> contained.

I do not understand the "the rubygem-io-console to be self contained.".
Could you explain more about it?

-- 
Jun | He - His - Him
___
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 errors/warnings by rpmlint

2021-03-19 Thread Jun Aruga
Pavel, thanks for your comment.
I will comment later.

Now I just inform you that I sent PR related to the 2 warnings in the
errors/warnings I mentioned.
https://src.fedoraproject.org/rpms/ruby/pull-request/78

-- 
Jun | He - His - Him
___
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 errors/warnings by rpmlint

2021-03-19 Thread Jun Aruga
> ### 4.
>
> ruby-libs.x86_64: W: dangling-symlink /usr/share/ruby/io
> /usr/share/gems/gems/io-console-0.5.6/lib/io
> The target of the symbolic link does not exist within this package or its file
> based dependencies.  Verify spelling of the link target and that the target is
> included in a package in this package's dependency chain.
>
> =>
> This warning was a hint to find "another issue" to fix.
> The issue is the directory entry `%{ruby_libdir}/io` is duplicated
> between ruby-libs and rubygem-io-console RPM in ruby.spec.
>
> Maybe the directory entry in ruby-libs should be removed like this.
>
> ```
> @@ -942,6 +942,7 @@ MSPECOPTS=""
>  # Platform independent libraries.
>  %dir %{ruby_libdir}
>  %exclude %{ruby_libdir}/bigdecimal*
> +%exclude %{ruby_libdir}/io
>  %exclude %{ruby_libdir}/irb*
>  %exclude %{ruby_libdir}/json*
>  %exclude %{ruby_libdir}/psych*
> @@ -964,7 +965,6 @@ MSPECOPTS=""
>  %{ruby_libdir}/find.rb
>  %{ruby_libdir}/forwardable*
>  %{ruby_libdir}/getoptlong*
> -%{ruby_libdir}/io
>  %{ruby_libdir}/ipaddr.rb
>  %{ruby_libdir}/kconv.rb
>  %{ruby_libdir}/logger*
> ```

For this issue, I actually found it by the following way.

```
$ rpm2cpio ruby-libs-3.0.0-146.fc35.x86_64.rpm | cpio -idmv

$ rpm2cpio rubygem-io-console-0.5.6-146.fc35.x86_64.rpm | cpio -idmv
...
cpio: ./usr/share/ruby/io not created: newer or same age version exists
...
```

The duplicated entry is only this entry. I checked it by the following script.

```
$ cat unpack.sh
#!/bin/bash

set -ex

for RPM_FILE in *.rpm; do
  rpm2cpio "${RPM_FILE}" | cpio -idmv
done
```

I opened the ticket for rpmlint to ask them to implement to detect the
duplicated entries here.
https://github.com/rpm-software-management/rpmlint/issues/613


What do you think about these errors/warnings I reported on the email?
I am happy to send PR to fix it.

-- 
Jun | He - His - Him
___
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


Ruby errors/warnings by rpmlint

2021-03-18 Thread Jun Aruga
Hi,
I checked the latest rawhide ruby ruby-3.0.0-146.fc35 by rpmlint, and
I found some errors and warnings to fix.

## Summary

I think the following 4 errors or warnings especially can be fixed.

```
ruby.spec:20: E: use-of-RPM_SOURCE_DIR
ruby-default-gems.noarch: W: summary-ended-with-dot C Default gems
which are part of Ruby StdLib.
ruby-libs.x86_64: E: missing-call-to-chdir-with-chroot
/usr/lib64/libruby.so.3.0.0
ruby-libs.x86_64: W: dangling-symlink /usr/share/ruby/io
/usr/share/gems/gems/io-console-0.5.6/lib/io
```

There are also other ones too.

## Steps to check by rpmlint

```
$ rpm -q rpmlint
rpmlint-1.11-15.fc33.noarch

$ rpmlint ruby.spec /path/to/result/*.rpm >& lint.log
$ rpmlint -i ruby.spec /path/to/result/*.rpm >& lint_detail.log
```

## Result

### 1.

ruby.spec:20: E: use-of-RPM_SOURCE_DIR
You use $RPM_SOURCE_DIR or %{_sourcedir} in your spec file. If you have to use
a directory for building, use $RPM_BUILD_ROOT instead.

=>
The `%{_sourcedir}/%{ruby_archive}.tar.xz` can be replaced to
`%{SOURCE0}`? I am not sure.

### 2.

ruby-default-gems.noarch: W: summary-ended-with-dot C Default gems
which are part of Ruby StdLib.
Summary ends with a dot.

=>
The summary ending dot needs to be removed.

### 3.

ruby-libs.x86_64: E: missing-call-to-chdir-with-chroot
/usr/lib64/libruby.so.3.0.0
This executable appears to call chroot without using chdir to change the
current directory. This is likely an error and permits an attacker to break
out of the chroot by using fchdir. While that's not always a security issue,
this has to be checked.

=>
Not sure when this error came.

### 4.

ruby-libs.x86_64: W: dangling-symlink /usr/share/ruby/io
/usr/share/gems/gems/io-console-0.5.6/lib/io
The target of the symbolic link does not exist within this package or its file
based dependencies.  Verify spelling of the link target and that the target is
included in a package in this package's dependency chain.

=>
This warning was a hint to find "another issue" to fix.
The issue is the directory entry `%{ruby_libdir}/io` is duplicated
between ruby-libs and rubygem-io-console RPM in ruby.spec.

Maybe the directory entry in ruby-libs should be removed like this.

```
@@ -942,6 +942,7 @@ MSPECOPTS=""
 # Platform independent libraries.
 %dir %{ruby_libdir}
 %exclude %{ruby_libdir}/bigdecimal*
+%exclude %{ruby_libdir}/io
 %exclude %{ruby_libdir}/irb*
 %exclude %{ruby_libdir}/json*
 %exclude %{ruby_libdir}/psych*
@@ -964,7 +965,6 @@ MSPECOPTS=""
 %{ruby_libdir}/find.rb
 %{ruby_libdir}/forwardable*
 %{ruby_libdir}/getoptlong*
-%{ruby_libdir}/io
 %{ruby_libdir}/ipaddr.rb
 %{ruby_libdir}/kconv.rb
 %{ruby_libdir}/logger*
```

### 5.

```
ruby-default-gems.noarch: W: obsolete-not-provided rubygem-did_you_mean
If a package is obsoleted by a compatible replacement, the obsoleted package
should also be provided in order to not cause unnecessary dependency breakage.
If the obsoleting package is not a compatible replacement for the old one,
leave out the Provides.

ruby-default-gems.noarch: W: obsolete-not-provided rubygem-openssl
If a package is obsoleted by a compatible replacement, the obsoleted package
should also be provided in order to not cause unnecessary dependency breakage.
If the obsoleting package is not a compatible replacement for the old one,
leave out the Provides.

ruby-default-gems.noarch: W: obsolete-not-provided rubygem-racc
If a package is obsoleted by a compatible replacement, the obsoleted package
should also be provided in order to not cause unnecessary dependency breakage.
If the obsoleting package is not a compatible replacement for the old one,
leave out the Provides.
```

=>
The Provides line needs for the Obsolete line.


### 6.

```
rubygem-rbs.noarch: E: non-executable-script
/usr/share/gems/gems/rbs-1.0.0/bin/annotate-with-rdoc 644 /usr/bin/env
ruby
This text file contains a shebang or is located in a path dedicated for
executables, but lacks the executable bits and cannot thus be executed.  If
the file is meant to be an executable script, add the executable bits,
otherwise remove the shebang or move the file elsewhere.
```

This is the same for other files (total 8 files) under
/usr/share/gems/gems/rbs-1.0.0/bin/.

### 7.

```
ruby-libs.x86_64: W: library-not-linked-against-libc
/usr/lib64/ruby/continuation.so
ruby-libs.x86_64: W: library-not-linked-against-libc /usr/lib64/ruby/enc/big5.so
...
```

=> I may remember this warning happened for 1 so file in Ruby 2.7 last
year. Now I see it for the many so files.

### 8.

non-executable-script errors.

=> Some parts are nice to fix.


## rpms/ruby CI to add rpmlint test.

Can we check the rpmlint issues on an early timing: pull-request and push?
I think adding the rpmlint check ro rpm/ruby CI is a possible way
related to this ticket.
https://src.fedoraproject.org/rpms/ruby/pull-request/67
Shall we add it after the PR #67 will be merged?

-- 
Jun | He - His - Him
___
ruby-sig mailing list -- ruby-sig@lists.fedo

Re: Self Introduction: Otto Urpelainen

2021-02-24 Thread Jun Aruga
> I see that Jun gave a bit different answer in his reply. In any case, my
> 

My answer was just my opinion. And I can see that my answer was wrong.
Sorry for confusing you. As Vit said, there is no strict rule for
using the @rubygem-packagers-sig. And I agree with Vit's concern for
using it on all the rubygem-* packages.

-- 
Jun | He - His - Him
___
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: Self Introduction: Otto Urpelainen

2021-02-24 Thread Jun Aruga
> Regarding maintaining Ruby packages, I notice that some of the packages
> I maintain have the group @ruby-packagers-sig as co-maintainers, but not
> all. What is the set of packages this group wants to have access to? I
> could all them to all my packages, if the answer is "all Ruby packages".

Welcome, Otto!
I think the answer is "all Ruby packages" (ruby + rubygem-* packages)
as much as possible.

-- 
Jun | He - His - Him
___
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

2021-01-20 Thread Jun Aruga
> $ dnf repoquery --repo=koji-ruby30 --qf '%{sourcerpm}' --whatrequires 
> "libruby.so.2.7()(64bit)" | cat -n
> ...
>  3 rubygem-mysql2-0.5.3-5.fc33.src.rpm

I am working on the rubygem-mysql2 package to build on rawhide.
See https://bugzilla.redhat.com/show_bug.cgi?id=1914515 for detail.

-- 
Jun | He - His - Him
___
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 change proposal

2021-01-07 Thread Jun Aruga
I think we can add not only the upstream github's NEWS.md but also the
ruby-lang's release note too, as obviously the Fedora wiki page's
content is copied from the upstream page.
https://www.ruby-lang.org/en/news/2020/12/25/ruby-3-0-0-released/
Though the ruby-lang page is not mentioned on Ruby 2.7, I think we can
start to mention it from Ruby 3.0.
https://fedoraproject.org/wiki/Changes/Ruby_2.7

-- 
Jun | He - His - Him
___
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 change proposal

2021-01-07 Thread Jun Aruga
> Upgrade/compatibility impact

Is it better to mention about the `%{gem_plugin}` macro for the file
to %files section to the Upgrade/compatibility impact section if it is
encouraged to add it to rubygem- packages?
https://src.fedoraproject.org/rpms/ruby/pull-request/76


We might also add the following things to the wiki page.
If net-telnet, xmlrpc, webrick gem are used on your ruby packages, you
need to add to the Requies and/or BuildRequires on the spec file.

According to
https://github.com/ruby/ruby/blob/v3_0_0/NEWS.md#stdlib-compatibility-issues

> * Bundled gems
>   net-telnet and xmlrpc have been removed from the bundled gems. If you are 
> interested in maintaining them, please comment on your plan to 
> https://github.com/ruby/xmlrpc or https://github.com/ruby/net-telnet.
> * SDBM has been removed from the Ruby standard library. [Bug #8446]
>  WEBrick has been removed from the Ruby standard library. [Feature #17303]

--
Jun | He - His - Him
___
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 change proposal

2021-01-07 Thread Jun Aruga
> Ruby 3.0.0.preview1 NEWS

Above link text and the actual link
(https://github.com/ruby/ruby/blob/v3_0_0_preview1/NEWS.md) for the
preview 1 are outdated.

-- 
Jun | He - His - Him
___
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 change proposal

2021-01-07 Thread Jun Aruga
On Wed, Dec 2, 2020 at 5:11 PM Vít Ondruch  wrote:
>
> Hi Rubyists,
>
> The release of Ruby 3.0 is coming close and to be ready for rebuild
> after Christmas, I have submitted the Ruby 3.0 change proposal [1]. It
> is already in `ChangeReadyForWrangler` state, since I don't expect any
> controversy. But anyway, please review and let me know if you have any
> concerns.
>
>
> Vít
>
>
> [1] https://fedoraproject.org/wiki/Changes/Ruby_3.0

> https://github.com/ruby/ruby/blob/master/NEWS

The link to the upstream NEWS on the wiki page is unreachable.

Maybe this is the correct one.
https://github.com/ruby/ruby/blob/v3_0_0/NEWS.md

As the following file already is about Ruby 3.1.0.
https://github.com/ruby/ruby/blob/master/NEWS.md

-- 
Jun | He - His - Him
___
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

2020-12-18 Thread Jun Aruga
On Fri, Dec 18, 2020 at 4:06 PM Jun Aruga  wrote:
>
> > Another snapshot is available in private-ruby-3.0 branch and the build
> > is running here:
> >
> > https://koji.fedoraproject.org/koji/taskinfo?taskID=57585626
> >
> > Most notable change is removal of WEBRick from Ruby. I am not completely
> > sure how much disruption this could cause in Fedora. I wonder if it is
> > worth of packaging it as a separate package. Thoughts?

I find the .gitignore is outdated, as we have ruby-3.*.tar.xz. Maybe
we can update be like this.

```
$ git diff
diff --git a/.gitignore b/.gitignore
index 3523d77..a59f941 100644
--- a/.gitignore
+++ b/.gitignore
@@ -1,4 +1,3 @@
 /*/
-/ruby-2.*.tar.bz2
-/ruby-2.*.tar.xz
+/ruby-*.tar.xz
 /*.rpm
```

-- 
Jun | He - His - Him
___
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

2020-12-18 Thread Jun Aruga
> Another snapshot is available in private-ruby-3.0 branch and the build
> is running here:
>
> https://koji.fedoraproject.org/koji/taskinfo?taskID=57585626
>
> Most notable change is removal of WEBRick from Ruby. I am not completely
> sure how much disruption this could cause in Fedora. I wonder if it is
> worth of packaging it as a separate package. Thoughts?
>
> Vít
>
>
> P.S. @jaruga + @pvalena thx for handling the GCC11 issues.

Thanks for another snapshot, Vit.
I confirmed the new snapshot's SRPM works on my mock build rawhide.
I also confirmed the following failure I reported above disappeared now.

```
  1) Failure:
TestBundledCA#test_accessing_rubygems
[/builddir/build/BUILD/ruby-3.0.0-1cfc6e7b7a/test/rubygems/test_bundled_ca.rb:46]:
rubygems.org is not verifiable using the included certificates. Error
was: SSL_connect returned=1 errno=0 state=error: certificate verify
failed (unable to get local issuer certificate)

Finished tests in 670.500927s, 31.2244 tests/s, 3975.4993 assertions/s.
20936 tests, 2665576 assertions, 1 failures, 0 errors, 48 skips

ruby -v: ruby 3.0.0dev (2020-12-04 master 1cfc6e7b7a) [x86_64-linux]
make: *** [uncommon.mk:801: yes-test-all] Error 1
```

-- 
Jun | He - His - Him
___
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

2020-12-14 Thread Jun Aruga
> All build results can be found here:
>   https://copr.fedorainfracloud.org/coprs/pvalena/rubygems-testing/builds/

Hi Pavel,
You might need to build the packages on your copr f34 (rawhide) now
again if it is easy to do.
Because there is new gcc-11 on rawhide now. And for example the
rubygem-mysql2 fails actually, but it was shown as a success on your
copr.
https://koschei.fedoraproject.org/package/rubygem-mysql2

-- 
Jun | He - His - Him
___
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: rspec suite 3.10 hits rawhide

2020-12-14 Thread Jun Aruga
On Fri, Dec 11, 2020 at 12:34 PM Mamoru TASAKA
 wrote:
>
> 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.

Hello,
I tried to build the following 2 packages on rubygem-rspec 3.10.0 on
f34 right now. It seems no problem.

rubygem-mysql2
https://koji.fedoraproject.org/koji/taskinfo?taskID=57440011
There are test failures. But possibly it comes from new gcc-11 or new mariadb.
https://koschei.fedoraproject.org/package/rubygem-mysql2

rubygem-pg
https://koji.fedoraproject.org/koji/taskinfo?taskID=57440025

-- 
Jun | He - His - Him
___
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

2020-12-14 Thread Jun Aruga
On Thu, Dec 10, 2020 at 12:32 PM Jun Aruga  wrote:
>
> > I will report it to the upstream, and let you know the result here.
>
> Here is the upstream ticket I opened now.
> https://bugs.ruby-lang.org/issues/17385

The patch was merged to the upstream ruby's master branch.
https://src.fedoraproject.org/fork/jaruga/rpms/ruby/c/ae692f4f294ac4f3e474581b0298060dc66ed759?branch=wip%2Fprivate-ruby-3.0-gcc-11

Here is my patch for the private-ruby-3.0 branch
https://src.fedoraproject.org/fork/jaruga/rpms/ruby/c/ae692f4f294ac4f3e474581b0298060dc66ed759?branch=wip%2Fprivate-ruby-3.0-gcc-11

It seems that the scratch build works.
https://koji.fedoraproject.org/koji/taskinfo?taskID=57437861

But the mock build fails with the following one.

```
  1) Failure:
TestBundledCA#test_accessing_rubygems
[/builddir/build/BUILD/ruby-3.0.0-1cfc6e7b7a/test/rubygems/test_bundled_ca.rb:46]:
rubygems.org is not verifiable using the included certificates. Error
was: SSL_connect returned=1 errno=0 state=error: certificate verify
failed (unable to get local issuer certificate)

Finished tests in 670.500927s, 31.2244 tests/s, 3975.4993 assertions/s.
20936 tests, 2665576 assertions, 1 failures, 0 errors, 48 skips

ruby -v: ruby 3.0.0dev (2020-12-04 master 1cfc6e7b7a) [x86_64-linux]
make: *** [uncommon.mk:801: yes-test-all] Error 1
```

Any idea to fix?
Thanks.

-- 
Jun | He - His - Him
___
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

2020-12-10 Thread Jun Aruga
> I will report it to the upstream, and let you know the result here.

Here is the upstream ticket I opened now.
https://bugs.ruby-lang.org/issues/17385

> I am running the SRPM on the private-ruby-3.0 branch for f33 too just in case.
>
> ```
> $ koji build --scratch --nowait --arch-override=x86_64 f33
> ruby-3.0.0-0.1.20201204git1cfc6e7b7a.fc34.src.rpm
> https://koji.fedoraproject.org/koji/taskinfo?taskID=57179644
> ```

The build succeeded with gcc 10.2.1-9.fc33 on f33.

-- 
Jun | He - His - Him
___
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

2020-12-10 Thread Jun Aruga
On Wed, Dec 9, 2020 at 8:45 PM Jun Aruga  wrote:
>
> > Hello,
> >
> > I was unable to rebuild in my testing repo:
> >
> > https://copr.fedorainfracloud.org/coprs/build/1818226
> >
> > Tests fail due warnings, when using RBIMPL_CAST:
> >
> > ```
> > /builddir/build/BUILD/ruby-3.0.0-1cfc6e7b7a/include/ruby/internal/core/rbasic.h:40:59:
> >  warning: expression does not compute the number of elements in this array; 
> > element type is 'VALUE' {aka 'long unsigned int'}, not 'char' 
> > [-Wsizeof-array-div]
> >40 | RBIMPL_CAST((int)(sizeof(VALUE[RVALUE_EMBED_LEN_MAX]) / 
> > sizeof(T)))
> > ```
> >
> > I suspect this is new gcc warning. Or should we report this upstream?
>
> Here is the failure of the scratch build on the private-ruby-3.0 branch.
> https://koji.fedoraproject.org/koji/taskinfo?taskID=57140928
> https://kojipkgs.fedoraproject.org//work/tasks/928/57140928/build.log
>
> Yes, I think we should report it. identifying the version of the gcc
> by comparing the build on f33 or f32 or finding and pointing out the
> official document of the new warning.

I investigated more to report it to upstream.
On the rawhide, the gcc version is 11.0.0-0.7.fc34

According to the gcc 11 release note, the new warning
-Wsizeof-array-div causing the error was added.
https://gcc.gnu.org/gcc-11/changes.html

> C family
> New warnings:
> -Wsizeof-array-div, enabled by -Wall, warns about divisions of two sizeof 
> operators when the first one is applied to an array and the divisor does not 
> equal the size of the array element.

Here is the ticket with the examples.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91741

I will report it to the upstream, and let you know the result here.

I am running the SRPM on the private-ruby-3.0 branch for f33 too just in case.

```
$ koji build --scratch --nowait --arch-override=x86_64 f33
ruby-3.0.0-0.1.20201204git1cfc6e7b7a.fc34.src.rpm
https://koji.fedoraproject.org/koji/taskinfo?taskID=57179644
```

-- 
Jun | He - His - Him
___
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

2020-12-09 Thread Jun Aruga
> Hello,
>
> I was unable to rebuild in my testing repo:
>
> https://copr.fedorainfracloud.org/coprs/build/1818226
>
> Tests fail due warnings, when using RBIMPL_CAST:
>
> ```
> /builddir/build/BUILD/ruby-3.0.0-1cfc6e7b7a/include/ruby/internal/core/rbasic.h:40:59:
>  warning: expression does not compute the number of elements in this array; 
> element type is 'VALUE' {aka 'long unsigned int'}, not 'char' 
> [-Wsizeof-array-div]
>40 | RBIMPL_CAST((int)(sizeof(VALUE[RVALUE_EMBED_LEN_MAX]) / 
> sizeof(T)))
> ```
>
> I suspect this is new gcc warning. Or should we report this upstream?

Here is the failure of the scratch build on the private-ruby-3.0 branch.
https://koji.fedoraproject.org/koji/taskinfo?taskID=57140928
https://kojipkgs.fedoraproject.org//work/tasks/928/57140928/build.log

Yes, I think we should report it. identifying the version of the gcc
by comparing the build on f33 or f32 or finding and pointing out the
official document of the new warning.

-- 
Jun | He - His - Him
___
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

2020-12-09 Thread Jun Aruga
Note that Ruby 3.0.0 preview2 was released yesterday on December 8th.
https://www.ruby-lang.org/en/news/2020/12/08/ruby-3-0-0-preview2-released/


-- 
Jun | He - His - Him
___
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

2020-11-19 Thread Jun Aruga
> This kind of commits does not make me happy :( While the intention is
> good, they don't take into consideration any distribution. It is
> tailored to the old fashion way of "download tarball & configure & make
> & make install", everything runs on single machine :/
>
> Does anybody have a tip how to convince upstream, that this does not
> scale? Does anybody want to ask upstream to revert this commit on my behalf?

The solution is like this?

This commit's comment explains "AC_PROG_CXX sets $CXX to "g++" when it
purposefully finds that there is _no_ g++".
But for the implementation, the condition " there is no g++" is not considered.
I think reporting there is a mismatch between the explanation and
implementation, convinces the upstream.

So, we just need to add the condition "there is no g++".
In the case of Mamoru, there is g++ possibly on the environment. So,
he can avoid unset CXX.
https://github.com/ruby/ruby/commit/50b18e81295ad2d45975e4d8ea1e0c7e85140b97

```
$ git diff
diff --git a/configure.ac b/configure.ac
index 4e4a52f066..ecc70846d8 100644
--- a/configure.ac
+++ b/configure.ac
@@ -190,7 +190,7 @@ AC_CHECK_TOOLS([STRIP],   [gstrip strip], [:])
 AS_IF([test ! $rb_test_CFLAGS], [AS_UNSET(CFLAGS)]); AS_UNSET(rb_test_CFLAGS)
 AS_IF([test ! $rb_test_CXXFLAGS], [AS_UNSET(CXXFLAGS)]);
AS_UNSET(rb_save_CXXFLAGS)

-AS_IF([test "${CXX}" = "g++" -a -z "${GXX}"], [
+AS_IF([test "${CXX}" = "g++" -a -z "${GXX}" && ! command -v g++ > /dev/null], [
 # AC_PROG_CXX sets $CXX to "g++" when it purposefully finds that there is
 # _no_ g++.  This brain-damaged design must be worked around.  Thankfully,
 # similar thing doesn't happen for AC_PROG_CC.
```

-- 
Jun | He - His - Him
___
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: Gem diffs

2020-11-19 Thread Jun Aruga
On Thu, Nov 19, 2020 at 10:42 AM Vít Ondruch  wrote:
>
> Not sure if anybody noticed the "Review changes" link of the
> Rubygem.org, but this is the example:
>
> https://my.diffend.io/gems/gem2rpm/1.0.0/1.0.1
>
> It seems quite handy to what we do.

I did not know the "Review changes" link in the right side area. It
looks useful.

https://rubygems.org/gems/gem2rpm
  => https://my.diffend.io/gems/gem2rpm/prev/1.0.1
=> https://my.diffend.io/gems/gem2rpm/1.0.0/1.0.1

-- 
Jun | He - His - Him
___
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


Ruby 2.7.2/3.0.0 rebasing

2020-10-05 Thread Jun Aruga
Is anyone working to rebase Ruby 2.7.2 and 3.0.0?

Ruby 2.7.2
https://www.ruby-lang.org/en/news/2020/10/02/ruby-2-7-2-released/

Ruby 3.0.0
https://www.ruby-lang.org/en/news/2020/09/25/ruby-3-0-0-preview1-released/

-- 
Jun | He - His - Him
___
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-rails group in Koschei & RoR 6.0.3.3

2020-10-01 Thread Jun Aruga
The list of packages `ruby-rails` group in Koschei is useful to manage
the packages related to Ruby on Rails.
https://koschei.fedoraproject.org/groups/ruby-rails
Thanks for the work.

> There are some suspicious entries, like `+rubygem-rspec2`, which will need 
> further investigation. I'll welcome any additional feedback on packages that 
> are missing, or should not be in this group.

It seems rubygem-rspec2 was removed from the list.

> From a swift look on the list any `simplecov` might not be needed IMO.

it seems rubygem-simplecov does not exist on the list.

> It would be nice to know what cucumber version will be required for this to 
> build

it seems cucumber also does not exist on the list.

-- 
Jun | He - His - Him
___
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: rpms/ruby: Fedora rawhide FTBFS

2020-06-09 Thread Jun Aruga
I opened the ticket for that.
https://bugzilla.redhat.com/show_bug.cgi?id=1845530

And possibly here is the patch to fix the issues.
https://github.com/ruby/psych/commit/3f5e520fd38c39975c25a1bbd8d6c8ec9a132f2d

Jun

On Sat, Jun 6, 2020 at 1:10 AM Jun Aruga  wrote:
>
> I observed the FTBFS on rpm/ruby rawhide.
>
> You can see Koschei.
> https://koschei.fedoraproject.org/package/ruby
>
> Do you know what causes the error? Is it a temporary issue?
>
> If you like, I open the bugzilla ticket for that.
>
> https://kojipkgs.fedoraproject.org/work/tasks/3309/45363309/build.log
>
> ```
>   1) Failure:
> Psych::TestNil#test_array_nil
> [/builddir/build/BUILD/ruby-2.7.1/test/psych/test_nil.rb:14]:
> --- expected
> +++ actual
> @@ -1,3 +1,3 @@
>  "---
> --
> +-
>  "
>   2) Failure:
> Psych::TestNil#test_nil
> [/builddir/build/BUILD/ruby-2.7.1/test/psych/test_nil.rb:8]:
> Expected /--- \n(?:\.\.\.\n)?/ to match "---\n".
>   3) Error:
> Psych_Unit_Tests#test_spec_domain_prefix:
> Psych::SyntaxError: (): did not find expected whitespace or
> line break while scanning a tag at line 2 column 10
> /builddir/build/BUILD/ruby-2.7.1/.ext/common/psych.rb:456:in `parse'
> /builddir/build/BUILD/ruby-2.7.1/.ext/common/psych.rb:456:in 
> `parse_stream'
> /builddir/build/BUILD/ruby-2.7.1/.ext/common/psych.rb:390:in `parse'
> /builddir/build/BUILD/ruby-2.7.1/.ext/common/psych.rb:277:in `load'
> /builddir/build/BUILD/ruby-2.7.1/test/psych/helper.rb:66:in
> `assert_parse_only'
> /builddir/build/BUILD/ruby-2.7.1/test/psych/test_yaml.rb:622:in
> `test_spec_domain_prefix'
>   4) Error:
> Psych_Unit_Tests#test_spec_application_family:
> Psych::SyntaxError: (): did not find expected whitespace or
> line break while scanning a tag at line 1 column 3
> /builddir/build/BUILD/ruby-2.7.1/.ext/common/psych.rb:456:in `parse'
> /builddir/build/BUILD/ruby-2.7.1/.ext/common/psych.rb:456:in 
> `parse_stream'
> /builddir/build/BUILD/ruby-2.7.1/.ext/common/psych.rb:390:in `parse'
> /builddir/build/BUILD/ruby-2.7.1/.ext/common/psych.rb:277:in `load'
> /builddir/build/BUILD/ruby-2.7.1/test/psych/helper.rb:66:in
> `assert_parse_only'
> /builddir/build/BUILD/ruby-2.7.1/test/psych/test_yaml.rb:750:in
> `test_spec_application_family'
>   5) Error:
> Psych_Unit_Tests#test_spec_float_explicit:
> Psych::SyntaxError: (): did not find expected whitespace or
> line break while scanning a tag at line 5 column 3
> /builddir/build/BUILD/ruby-2.7.1/.ext/common/psych.rb:456:in `parse'
> /builddir/build/BUILD/ruby-2.7.1/.ext/common/psych.rb:456:in 
> `parse_stream'
> /builddir/build/BUILD/ruby-2.7.1/.ext/common/psych.rb:390:in `parse'
> /builddir/build/BUILD/ruby-2.7.1/.ext/common/psych.rb:277:in `load'
> /builddir/build/BUILD/ruby-2.7.1/test/psych/helper.rb:66:in
> `assert_parse_only'
> /builddir/build/BUILD/ruby-2.7.1/test/psych/test_yaml.rb:768:in
> `test_spec_float_explicit'
>   6) Error:
> Psych_Unit_Tests#test_spec_explicit_families:
> Psych::SyntaxError: (): did not find expected whitespace or
> line break while scanning a tag at line 8 column 6
> /builddir/build/BUILD/ruby-2.7.1/.ext/common/psych.rb:456:in `parse'
> /builddir/build/BUILD/ruby-2.7.1/.ext/common/psych.rb:456:in 
> `parse_stream'
> /builddir/build/BUILD/ruby-2.7.1/.ext/common/psych.rb:390:in `parse'
> /builddir/build/BUILD/ruby-2.7.1/.ext/common/psych.rb:277:in `load'
> /builddir/build/BUILD/ruby-2.7.1/test/psych/helper.rb:66:in
> `assert_parse_only'
> /builddir/build/BUILD/ruby-2.7.1/test/psych/test_yaml.rb:711:in
> `test_spec_explicit_families'
>   7) Error:
> TestPsych#test_domain_types:
> Psych::SyntaxError: (): did not find expected whitespace or
> line break while scanning a tag at line 1 column 5
> /builddir/build/BUILD/ruby-2.7.1/.ext/common/psych.rb:456:in `parse'
> /builddir/build/BUILD/ruby-2.7.1/.ext/common/psych.rb:456:in 
> `parse_stream'
> /builddir/build/BUILD/ruby-2.7.1/.ext/common/psych.rb:390:in `parse'
> /builddir/build/BUILD/ruby-2.7.1/.ext/common/psych.rb:277:in `load'
> /builddir/build/BUILD/ruby-2.7.1/test/psych/test_psych.rb:185:in
> `test_domain_types'
>   8) Error:
> TestPsych#test_callbacks:
> Psych::SyntaxError: (): did not find expected whitespace or
> line break while scanning a tag at line 1 column 3
> /builddir/build/BUILD/ruby-2.7.1/.ext/common/psych.rb:456:in `parse'
> /builddir/build/BUILD/ruby-2.7.1/.ext/common/psych.rb:456:in 
> `parse_stream&

rpms/ruby: Fedora rawhide FTBFS

2020-06-05 Thread Jun Aruga
I observed the FTBFS on rpm/ruby rawhide.

You can see Koschei.
https://koschei.fedoraproject.org/package/ruby

Do you know what causes the error? Is it a temporary issue?

If you like, I open the bugzilla ticket for that.

https://kojipkgs.fedoraproject.org/work/tasks/3309/45363309/build.log

```
  1) Failure:
Psych::TestNil#test_array_nil
[/builddir/build/BUILD/ruby-2.7.1/test/psych/test_nil.rb:14]:
--- expected
+++ actual
@@ -1,3 +1,3 @@
 "---
-- 
+-
 "
  2) Failure:
Psych::TestNil#test_nil
[/builddir/build/BUILD/ruby-2.7.1/test/psych/test_nil.rb:8]:
Expected /--- \n(?:\.\.\.\n)?/ to match "---\n".
  3) Error:
Psych_Unit_Tests#test_spec_domain_prefix:
Psych::SyntaxError: (): did not find expected whitespace or
line break while scanning a tag at line 2 column 10
/builddir/build/BUILD/ruby-2.7.1/.ext/common/psych.rb:456:in `parse'
/builddir/build/BUILD/ruby-2.7.1/.ext/common/psych.rb:456:in `parse_stream'
/builddir/build/BUILD/ruby-2.7.1/.ext/common/psych.rb:390:in `parse'
/builddir/build/BUILD/ruby-2.7.1/.ext/common/psych.rb:277:in `load'
/builddir/build/BUILD/ruby-2.7.1/test/psych/helper.rb:66:in
`assert_parse_only'
/builddir/build/BUILD/ruby-2.7.1/test/psych/test_yaml.rb:622:in
`test_spec_domain_prefix'
  4) Error:
Psych_Unit_Tests#test_spec_application_family:
Psych::SyntaxError: (): did not find expected whitespace or
line break while scanning a tag at line 1 column 3
/builddir/build/BUILD/ruby-2.7.1/.ext/common/psych.rb:456:in `parse'
/builddir/build/BUILD/ruby-2.7.1/.ext/common/psych.rb:456:in `parse_stream'
/builddir/build/BUILD/ruby-2.7.1/.ext/common/psych.rb:390:in `parse'
/builddir/build/BUILD/ruby-2.7.1/.ext/common/psych.rb:277:in `load'
/builddir/build/BUILD/ruby-2.7.1/test/psych/helper.rb:66:in
`assert_parse_only'
/builddir/build/BUILD/ruby-2.7.1/test/psych/test_yaml.rb:750:in
`test_spec_application_family'
  5) Error:
Psych_Unit_Tests#test_spec_float_explicit:
Psych::SyntaxError: (): did not find expected whitespace or
line break while scanning a tag at line 5 column 3
/builddir/build/BUILD/ruby-2.7.1/.ext/common/psych.rb:456:in `parse'
/builddir/build/BUILD/ruby-2.7.1/.ext/common/psych.rb:456:in `parse_stream'
/builddir/build/BUILD/ruby-2.7.1/.ext/common/psych.rb:390:in `parse'
/builddir/build/BUILD/ruby-2.7.1/.ext/common/psych.rb:277:in `load'
/builddir/build/BUILD/ruby-2.7.1/test/psych/helper.rb:66:in
`assert_parse_only'
/builddir/build/BUILD/ruby-2.7.1/test/psych/test_yaml.rb:768:in
`test_spec_float_explicit'
  6) Error:
Psych_Unit_Tests#test_spec_explicit_families:
Psych::SyntaxError: (): did not find expected whitespace or
line break while scanning a tag at line 8 column 6
/builddir/build/BUILD/ruby-2.7.1/.ext/common/psych.rb:456:in `parse'
/builddir/build/BUILD/ruby-2.7.1/.ext/common/psych.rb:456:in `parse_stream'
/builddir/build/BUILD/ruby-2.7.1/.ext/common/psych.rb:390:in `parse'
/builddir/build/BUILD/ruby-2.7.1/.ext/common/psych.rb:277:in `load'
/builddir/build/BUILD/ruby-2.7.1/test/psych/helper.rb:66:in
`assert_parse_only'
/builddir/build/BUILD/ruby-2.7.1/test/psych/test_yaml.rb:711:in
`test_spec_explicit_families'
  7) Error:
TestPsych#test_domain_types:
Psych::SyntaxError: (): did not find expected whitespace or
line break while scanning a tag at line 1 column 5
/builddir/build/BUILD/ruby-2.7.1/.ext/common/psych.rb:456:in `parse'
/builddir/build/BUILD/ruby-2.7.1/.ext/common/psych.rb:456:in `parse_stream'
/builddir/build/BUILD/ruby-2.7.1/.ext/common/psych.rb:390:in `parse'
/builddir/build/BUILD/ruby-2.7.1/.ext/common/psych.rb:277:in `load'
/builddir/build/BUILD/ruby-2.7.1/test/psych/test_psych.rb:185:in
`test_domain_types'
  8) Error:
TestPsych#test_callbacks:
Psych::SyntaxError: (): did not find expected whitespace or
line break while scanning a tag at line 1 column 3
/builddir/build/BUILD/ruby-2.7.1/.ext/common/psych.rb:456:in `parse'
/builddir/build/BUILD/ruby-2.7.1/.ext/common/psych.rb:456:in `parse_stream'
/builddir/build/BUILD/ruby-2.7.1/.ext/common/psych.rb:390:in `parse'
/builddir/build/BUILD/ruby-2.7.1/.ext/common/psych.rb:277:in `load'
/builddir/build/BUILD/ruby-2.7.1/test/psych/test_psych.rb:300:in
`test_callbacks'
Finished tests in 978.698829s, 21.4785 tests/s, 2781.3173 assertions/s.
21021 tests, 2722072 assertions, 2 failures, 6 errors, 62 skips
```

Cheers,
Jun

-- 
Jun | He - His - Him
___
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


Ruby 2.7 module build failures

2020-05-25 Thread Jun Aruga
I tried to run the Ruby 2.7 module builds with
https://src.fedoraproject.org/modules/ruby/tree/master ruby.yaml,
using the rpms/ruby master HEAD on 22th May.

Now when running `fedpkg module-build` command, it is built on 5
builtroots f33, f32, f31, f30, el8.
Maybe the el8 target was added recently.

```
$ fepkg co modules/ruby
$ cd ruby
$ fedpkg module-build
Submitting the module build...
The builds 8964, 8965, 8966, 8967 and 8968 were submitted to the MBS
Build URLs:
https://mbs.fedoraproject.org/module-build-service/2/module-builds/8964
https://mbs.fedoraproject.org/module-build-service/2/module-builds/8965
https://mbs.fedoraproject.org/module-build-service/2/module-builds/8966
https://mbs.fedoraproject.org/module-build-service/2/module-builds/8967
https://mbs.fedoraproject.org/module-build-service/2/module-builds/8968
```

## Result

Seeing the current result of the builds, there are 3 kinds of failures.

1. s390x specific failures. Segmentation Fault in tests. (f33, f32, f31)
  But when running the scratch build for rpms/ruby today 25th May, it succeeded.
  https://koji.fedoraproject.org/koji/taskinfo?taskID=44954981
  Do you know what is the reason for the error?

2. The failure of `checksec --file=libruby.so.2.7.1` (f30)
  Possibly checksec 1.11.1-1.fc30, the old version does not support
--file option.
  To avoid running checksec on f30, I am planning to set the following
macro in modules/ruby ruby.yaml.

```
 buildopts:
 rpms:
 macros: |
 %_without_hardening_test 1
```

3. error: one or more PCH files were found, but they were invalid (el8).
  This is a known issue on the RHEL8 gcc setting.
  https://bugzilla.redhat.com/show_bug.cgi?id=1721553
  I think Fedora rawhide rpms/ruby ruby.spec needs to add a %if logic
to skip the tests on el8 target.
  Or it needs to add this kind of logic:

%bcond_without jit_pch


Any opinions to fix this?


## Detail log

### f33 (rawhide)

$ fedpkg module-build-info 8965
  f33: FAILED: ruby:
https://koji.fedoraproject.org/koji/taskinfo?taskID=44825779

s390x: https://kojipkgs.fedoraproject.org//work/tasks/5879/44825879/build.log
  1) Error:
TestBugReporter#test_bug_reporter_add:
Timeout::Error: execution of assert_in_out_err expired timeout (30 sec)
pid 2477783 killed by SIGKILL (signal 9)

### f32

$ fedpkg module-build-info 8966
  f32: FAILED: ruby:
https://koji.fedoraproject.org/koji/taskinfo?taskID=44824056

s390x: https://kojipkgs.fedoraproject.org//work/tasks/4292/44824292/build.log
  1) Failure:
Fiddle::TestFunction#test_nogvl_poll
[/builddir/build/BUILD/ruby-2.7.1/test/fiddle/test_function.rb:95]:
slept amount of time.
Expected |200 - 714| (514) to be <= 180.
  2) Error:
TestBugReporter#test_bug_reporter_add:
Timeout::Error: execution of assert_in_out_err expired timeout (30 sec)
pid 229068 killed by SIGKILL (signal 9)

### f31

$ fedpkg module-build-info 8967
  f31: FAILED: ruby:
https://koji.fedoraproject.org/koji/taskinfo?taskID=44824127

s390x: https://kojipkgs.fedoraproject.org//work/tasks/4208/44824208/build.log
  1) Error:
TestIO#test_dup_many:
Timeout::Error: execution of assert_separately expired timeout (10 sec)
pid 2679628 exit 1
  2) Error:
TestProcess#test_status_quit:
Timeout::Error: execution of assert_in_out_err expired timeout (10 sec)
pid 2682640 killed by SIGKILL (signal 9)
|-
/builddir/build/BUILD/ruby-2.7.1/test/ruby/test_process.rb:1446:in
`block in test_status_quit'
/builddir/build/BUILD/ruby-2.7.1/test/ruby/test_process.rb:37:in
`block (2 levels) in with_tmpchdir'
/builddir/build/BUILD/ruby-2.7.1/test/ruby/test_process.rb:36:in `chdir'
/builddir/build/BUILD/ruby-2.7.1/test/ruby/test_process.rb:36:in
`block in with_tmpchdir'
/builddir/build/BUILD/ruby-2.7.1/lib/tmpdir.rb:89:in `mktmpdir'
/builddir/build/BUILD/ruby-2.7.1/test/ruby/test_process.rb:34:in
`with_tmpchdir'
/builddir/build/BUILD/ruby-2.7.1/test/ruby/test_process.rb:1445:in
`test_status_quit'
  3) Error:
TestRubyOptions#test_segv_test:
Timeout::Error: execution of assert_in_out_err expired timeout (10 sec)
pid 2683275 killed by SIGABRT (signal 6) (core dumped)

### f30

$ fedpkg module-build-info 8964
  f30: FAILED: ruby:
https://koji.fedoraproject.org/koji/taskinfo?taskID=44825807

Error on all the architectures.
x86_64, and etc:
checksec: 1.11.1-1.fc30

https://kojipkgs.fedoraproject.org//work/tasks/5913/44825913/build.log
+ cd ruby-2.7.1
+ checksec --file=libruby.so.2.7.1
+ grep 'Full RELRO.*Canary found.*NX enabled.*DSO.*No RPATH.*No
RUNPATH.*Yes.*\d*.*\d*.*libruby.so.2.7.1'

### el8

$ fedpkg module-build-info 8968
  el8: FAILED: ruby:
https://koji.fedoraproject.org/koji/taskinfo?taskID=44823939
https://kojipkgs.fedoraproject.org//work/tasks/4041/44824041/build.log
Error on all the architectures.

  1) Failure:
TestJIT#test_attr_reader
[/builddir/build/BUILD/ruby-2.7.1/test/ruby/test_jit.rb:812]:
Expected 2 times of JIT success, but succeeded 0 times.
...
/tmp/_ruby_mjit_p2552165u0.c:1:41: error: one o

Re: Ruby 2.7

2020-01-10 Thread Jun Aruga
> > Perhaps, this time, may we be able to wait for the new release Ruby
> > 2.7.1 to release Ruby 2.7 on Fedora?
> > How do you think?
> Hello,
>
> Please correct me if I'm wrong but the enhancements are adding functionality 
> (feature?) to be used when you need to handle the flag for `ruby2_keywords` 
> explicitly (https://bugs.ruby-lang.org/issues/16486).

In my understanding. the referred note says there is a problem about
the way for Ruby to make users to implement ruby2_keywords to suppress
the mixed positional and keyword argument's warnings on Ruby 2.7.0.

It's not a new enhancement, but a deprecation for a case that is a
method with the mixed positional and keyword argument and the
delegation.
Because in Ruby 3.0, they want to be a syntax error for this pattern.

For example, try to run following code on both Ruby 2.7.0 and Ruby 2.6

## Case A

```
def target(*args, **kwargs)
  [args, kwargs]
end

def delegate(*args, &block)
  target(*args, &block)
end

delegate(1, b: 2)
```

On Ruby 2.6, the delegate method works.

```
delegate(1, b: 2) => [[1], {:b=>2}]
```

On Ruby 2.7.0, it shows deprecation message.

```
delegate(1, b: 2)
(irb):5: warning: Using the last argument as keyword parameters is
deprecated; maybe ** should be added to the call
(irb):1: warning: The called method `target' is defined here
=> [[1], {:b=>2}]
```

The problem is how to fix the deprecation message considering both
Ruby 2.7.0 and old Rubies.
They are recommending to use "ruby2_keywords" that is internally
implemented in Ruby 2.7.0.

## Case B

```
def target(*args, **kwargs)
  [args, kwargs]
end

ruby2_keywords def delegate(*args, &block)
  target(*args, &block)
end

delegate(1, b: 2)
```

So, this code works on Ruby 2.7.0.

```
delegate(1, b: 2) => [[1], {:b=>2}]
```

But "ruby2_keywords" is not implemented in Ruby 2.6.
Users need to install "ruby2_keywords" to run a Ruby program on older Rubies,
and need to add "require 'ruby2_keywords' to the code for the older Rubies.

Gemfile

```
gem 'ruby2_keywords'
```

The above suggestion (= note-12) says that Ruby 2.7.1 should work on
the above case A without deprecation message.
https://bugs.ruby-lang.org/issues/16454#note-12

So, I have 2 concerns for this situation.

* 1. For example we will release Ruby 2.7.0 and doing mass build.
  Then we will contribute upstream to add "ruby2_keywords" to the
candidates methods.
  But the modification might not be needed anymore again in Ruby 2.7.0.
* 2. Fedora users using Fedora Ruby might have to fix their Ruby code
for only Ruby 2.7.0.


## Case C

```
def target(*args)
  [args]
end

def delegate(*args, &block)
  target(*args, &block)
end

delegate(1, {b: 2})
```

```
delegate(1, {b: 2}) => [[1], {:b=>2}]
```

But writing this email, I got an idea. When we contribute the upstream
(such as sending pull-request) to modify Case A to Case C without
using ruby2_keywords,
it solves the above concern 1.

> So either way the current code (packaged gems) needs to be fixed to work with 
> 2.7 (and yes, we'll probably get better debugging, but gems' upstream is the 
> place to fix those issues; not Fedora).

We might need to patch it for only Ruby 2.7.0 on Fedora.

> I expect 2.7.1 to hit Rawhide before branching (it'll be soon, right?), so 
> there should be no difference having a 2.7.0 build (esp. in a side-tag) now.

The Ruby 2.7.1 release date is not clear.
At least the next Ruby dev meeting is 16th January.
https://bugs.ruby-lang.org/issues/16454#note-12

--
Jun | He - His - Him
___
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

2020-01-08 Thread Jun Aruga
Hi Ruby SIG people,

For the releasing of Ruby 2.7 to Fedora, seeing following note in Ruby
developers community.
Ruby 2.7.1 can have a better user experience especially for the
migration from older Rubies to Ruby 2.7.
https://bugs.ruby-lang.org/issues/16454#note-12

Perhaps, this time, may we be able to wait for the new release Ruby
2.7.1 to release Ruby 2.7 on Fedora?
How do you think?

The question original comes from
https://src.fedoraproject.org/rpms/ruby/pull-request/48#comment-35755 .

-- 
Jun | He - His - Him
___
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: Two stage Ruby compilation / Bootstrapping

2020-01-02 Thread Jun Aruga
> Not this way. We would just incrementally build Ruby using previous Ruby
> (IOW there would be `BR: ruby` in .spec file). That would be likely good
> as long as Fedora does not introduce new architecture. Then we would
> need manually build some Ruby, probably without patches and then use
> this Ruby for build of Ruby with patches.
>
> I think if we are able to do this right, then we can choose from option
> 1 and 2 by setting the right flags. Both options has their pros and cons.

I see.
The pattern `BR: ruby` in ruby.spec file is actually like what gcc is
doing as `BuildRequires: gcc, gcc-c++` in gcc.spec file.
Maybe we are able to do this right.

-- 
Jun | He - His - Him
___
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


4 steps to be get sponsored for ruby-sig

2020-01-02 Thread Jun Aruga
Dear following folks who requested the approval to join ruby-sig.

* joice
* panosl1
* marcel64
* mkrzywda
* dcorking
* roca

Thank you for being interested in the ruby-sig!
Sorry for the late response.
Please allow me to send an email to your email address directly.

https://fedoraproject.org/wiki/SIGs/Ruby#Members
> The minimal requirement to get sponsored to the group is to go through all 
> the steps above.

Please check the 4 steps to get sponsored in above page, then after
you completed, let us know.

Cheers,
Jun

-- 
Jun | He - His - Him
jar...@redhat.com / IRC: jaruga
___
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

2020-01-02 Thread Jun Aruga
This is for your information about a note for Ruby 2.7.

The keyword argument's behavior is changed on Ruby 2.7.

Here is the detail.

Ruby 2.7 and keyword arguments
https://www.ruby-lang.org/en/news/2019/12/12/separation-of-positional-and-keyword-arguments-in-ruby-3-0/

And how to detail with it.

Support Ruby 3 keyword arguments
https://github.com/sinatra/mustermann/pull/97

And as you may know, Ruby 2.7.0 was released.
https://www.ruby-lang.org/en/news/2019/12/25/ruby-2-7-0-released/

Cheers,
Jun

-- 
Jun | He - His - Him
jar...@redhat.com / IRC: jaruga
___
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: Two stage Ruby compilation / Bootstrapping

2020-01-02 Thread Jun Aruga
> With recent changes, such as [3], I am afraid that the day has come.

It seems that the day came on Ruby 2.7.0, right? Ruby 2.7.0 includes
the commit [3].

> Thoughts?

> On the positive side, 1(2) would allow us to stay better in line with
> "Pregenerated code" guidelines [5], because there is already quite a lot
> of pre-generated code shipped in Ruby release tarball.

For my first impression,, I agree with the way 1) and 2).

> 2) Use previous version of Ruby available in Fedora to bootstrap Ruby.
> But this does not work ATM, at least when RubyGems are installed. And
> upstream is doing what they can to make RubyGems inseparable [4].

If we create the SRPM for "Use previous version of Ruby available in
Fedora to bootstrap Ruby", which name do you like?

The candidates:
* rpms/ruby-bootstrap
* rpms/bootstrap-ruby
* rpms/previous-ruby

-- 
Jun | He - His - Him
___
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

2019-12-13 Thread Jun Aruga
The mock build and some arch's scratch builds with your
ruby-2.7.0-af11efd377.tar.xz succeeded.

x86_64, aarch64 scratch builds failed.
I think it randomly happens, and just in case I share it here.

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

x86_64

```
1)
Net::HTTP#request when passed request_object and request_body sends
the passed request_body when making the HTTP Request ERROR
EOFError: end of file reached
/builddir/build/BUILD/ruby-2.7.0-af11efd377/lib/net/protocol.rb:225:in
`rbuf_fill'
/builddir/build/BUILD/ruby-2.7.0-af11efd377/lib/net/protocol.rb:191:in
`readuntil'
/builddir/build/BUILD/ruby-2.7.0-af11efd377/lib/net/protocol.rb:201:in
`readline'
/builddir/build/BUILD/ruby-2.7.0-af11efd377/lib/net/http/response.rb:42:in
`read_status_line'
/builddir/build/BUILD/ruby-2.7.0-af11efd377/lib/net/http/response.rb:31:in
`read_new'
/builddir/build/BUILD/ruby-2.7.0-af11efd377/lib/net/http.rb:1528:in
`block in transport_request'
/builddir/build/BUILD/ruby-2.7.0-af11efd377/lib/net/http.rb:1519:in `catch'
/builddir/build/BUILD/ruby-2.7.0-af11efd377/lib/net/http.rb:1519:in
`transport_request'
/builddir/build/BUILD/ruby-2.7.0-af11efd377/lib/net/http.rb:1492:in `request'
/builddir/build/BUILD/ruby-2.7.0-af11efd377/spec/ruby/library/net/http/http/request_spec.rb:65:in
`block (3 levels) in '
/builddir/build/BUILD/ruby-2.7.0-af11efd377/spec/ruby/library/net/http/http/request_spec.rb:5:in
`'
Finished in 58.675157 seconds
3745 files, 30406 examples, 15 expectations, 0 failures, 1 error, 1 tagged
```

aarch64

```
  1) Failure:
TestThreadQueue#test_thr_kill
[/builddir/build/BUILD/ruby-2.7.0-af11efd377/test/ruby/test_thread_queue.rb:153]:
only 107/250 done in 60 seconds.
  2) Error:
TestThread#test_signal_at_join:
Timeout::Error: execution of assert_separately expired timeout (120 sec)
pid 972556 killed by SIGABRT (signal 6) (core dumped)
|
/builddir/build/BUILD/ruby-2.7.0-af11efd377/test/ruby/test_thread.rb:1341:in
`test_signal_at_join'
Finished tests in 1373.821450s, 15.2371 tests/s, 1979.2587 assertions/s.
```

-- 
Jun | He - His - Him
___
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

2019-12-13 Thread Jun Aruga
> Did you upload your updated *.patch files to the remote repository?

Sorry maybe my mistake. My `ruby-2.7.0-af11efd377.tar.xz` file created
by `tool/make-snapshot -packages=xz -srcdir="$(pwd)"
~/tmp/ruby-snapshot` was actually newer than the upstream af11efd377 .

Here is the `version.h` in my `ruby-2.7.0-af11efd377.tar.xz` file.
"#define RUBY_RELEASE_DAY 11" is newer than your archive and the
upstream af11efd377.

```
$ head version.h
# define RUBY_VERSION_MAJOR RUBY_API_VERSION_MAJOR
# define RUBY_VERSION_MINOR RUBY_API_VERSION_MINOR
#define RUBY_VERSION_TEENY 0
#define RUBY_RELEASE_DATE
RUBY_RELEASE_YEAR_STR"-"RUBY_RELEASE_MONTH_STR"-"RUBY_RELEASE_DAY_STR
#define RUBY_PATCHLEVEL -1

#define RUBY_RELEASE_YEAR 2019
#define RUBY_RELEASE_MONTH 12
#define RUBY_RELEASE_DAY 11
```

-- 
Jun | He - His - Him
___
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

2019-12-13 Thread Jun Aruga
> Yet another update of Ruby 2.7 is available in dist-git and the scratch
> build is running in Koji:
>
> https://koji.fedoraproject.org/koji/taskinfo?taskID=39474761
>
> I don't thing there was anything major from packagin POV. Anyway, please
> let me know if you encounter any issues.

Hi Vit, thanks for preparing Ruby 2.7.
Now I tried a scratch build on rpms/ruby, the latest private-ruby-2.7 branch

commit: fe89ec49cc6e09f8f308b1e8dfaf38c492c06836
Upgrade to Ruby 2.7.0 (af11efd377).

but the scratch build failed because of failed patching processes.

```
$ git checkout private-ruby-2.7
$ fedpkg srpm
$ fedpkg --release master scratch-build --srpm --nowait
```

The scratch build result:
https://koji.fedoraproject.org/koji/taskinfo?taskID=39522612

```
Patch #0 (ruby-2.3.0-ruby_version.patch):
+ echo 'Patch #0 (ruby-2.3.0-ruby_version.patch):'
+ /usr/bin/patch --no-backup-if-mismatch -p1 --fuzz=0
patching file configure.ac
Hunk #1 succeeded at 3691 (offset 1 line).
Hunk #2 succeeded at 3713 (offset 1 line).
Hunk #3 succeeded at 3785 (offset 1 line).
...

Patch #6 
(ruby-2.1.0-Allow-to-specify-additional-preludes-by-configuratio.patch):
+ echo 'Patch #6
(ruby-2.1.0-Allow-to-specify-additional-preludes-by-configuratio.patch):'
+ /usr/bin/patch --no-backup-if-mismatch -p1 --fuzz=0
patching file common.mk
Hunk #1 FAILED at 163.
1 out of 1 hunk FAILED -- saving rejects to file common.mk.rej
patching file configure.ac
Hunk #1 succeeded at 3885 (offset 1 line).
patching file template/Makefile.in
error: Bad exit status from /var/tmp/rpm-tmp.nTmxK5 (%prep)
```

I created Source0: `ruby-2.7.0-af11efd377.tar.xz` file like this.

```
$ cd ~/git/ruby/ruby

$ git checkout af11efd377

$ git clean -fdx

$ git status
HEAD detached at af11efd377
nothing to commit, working tree clean

$ tool/make-snapshot -packages=xz -srcdir="$(pwd)" ~/tmp/ruby-snapshot

$ ls -l ~/tmp/ruby-snapshot/ruby-2.7.0-af11efd377.tar.xz
-rw-r--r-- 1 jaruga jaruga 11941052 Dec 13 15:35
/home/jaruga/tmp/ruby-snapshot/ruby-2.7.0-af11efd377.tar.xz

$ sha256sum ~/tmp/ruby-snapshot/ruby-2.7.0-af11efd377.tar.xz
bc5b0435e19c8b3f0f2d0300a7ed9b128ee553525b70e2bbe42ae16b42ed3b61
/home/jaruga/tmp/ruby-snapshot/ruby-2.7.0-af11efd377.tar.xz
```

Did you upload your updated *.patch files to the remote repository?

-- 
Jun | He - His - Him
___
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

2019-09-19 Thread Jun Aruga
Thanks for preparing Ruby 2.7 package.

I just share below Ruby ticket related to Ruby 2.7.
Some standard libraries will be changed to default gems or bundled
gems on Ruby 2.7.
We can watch this ticket.

Remove the unmaintained libraries from Ruby 2.7
https://bugs.ruby-lang.org/issues/16170

-- 
Jun | He - His - Him
___
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: Retired "rubygems" package

2019-08-13 Thread Jun Aruga
> Obviously if I was convinced we really need it, I'd did that without asking.

I do not think that someone is using the independent "rubygems" package.
It's a legacy of old Ruby that does not bundle rubygem in it.
But I like that if you want to retire this kind of key package, just
share us what you will do on this mailing-list, before your work to
retire.
Then I am fine.

Jun

On Mon, Aug 12, 2019 at 12:09 PM Vít Ondruch  wrote:
>
> Hi all,
>
> The independent "rubygems" package was retired, because it FTBFS already
> for some while:
>
> https://src.fedoraproject.org/rpms/rubygems/c/366607586d95b505277165fce54d9494650e8b91?branch=master
>
> Now I wonder, do we care? Should I unretire it while there is a chance
> to do it without review or we don't care and we are fine with the
> bundled version shipped in Ruby? Obviously if I was convinced we really
> need it, I'd did that without asking. So what are your opinions?
>
>
> 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



-- 
Jun Aruga | He - His - Him
jar...@redhat.com / IRC: jaruga
___
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: Fake libraries for gem builds?

2019-05-09 Thread Jun Aruga
> What if we shipped in rubygems-devel some
fake libraries, which would try to load the original library, but
silently provided the miminum mock to make the test suite pass without
the library?

You mentioned about including the logic in "rubygems-devel" RPM.
I misunderstood you mentioned about "ruby-devel".

rubygems-devel package includes below files, that have macros for
rubygems RPM packaging.

When a user install current rubygems-devel, that is not still harmful,
that's not confusing a user.
But after including the fake libraries in it, if user install the
rubygems-devel by mistake, it is harmful.

ruby.spec

```
%files -n rubygems-devel
%{_rpmconfigdir}/macros.d/macros.rubygems
%{_rpmconfigdir}/fileattrs/rubygems.attr
%{_rpmconfigdir}/rubygems.req
%{_rpmconfigdir}/rubygems.prov
%{_rpmconfigdir}/rubygems.con
```

-- 
Jun Aruga / He - His - Him
___
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


Re: Fake libraries for gem builds?

2019-05-09 Thread Jun Aruga
I agree the intent to create fake libraries for SimpleCov, Coveralls
and Bundler.
It  makes each rubygem package easy and clean. That's good.

But ruby-devel is used for the use case to build the rubygem that has
a C extension, with ruby.h
I think that ruby-devel's "devel" means user's development, not
packager's development
If we add the fake libraries, users are confused to refer the fake libraries.

I assume that the fake libraries are used for the use case of our rpm
packaging development only.

I would prefer to create new ruby's sub RPM package or separated RPM
package such as
* "ruby-packagers-utils": inspired from scl-utils
or
* "ruby-packagers-devel"
or
* "ruby-packagers-fake-libs"
or etc

Then each rubygem-foo.spec use like this if it is necessary.

rubygem-foo.spec

```
BuildRequires: ruby-packagers-utils
```


-- 
Jun Aruga / He - His - Him
___
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


Re: Draft for new Ruby SIG wiki page

2019-05-07 Thread Jun Aruga
Thanks for the work.

Let's remove "RubyForge" (outdated website) link too.

Jun

On Tue, May 7, 2019 at 1:16 PM Jaroslav Prokop  wrote:
>
> Hello,
>
> I've created a draft for the SIG page [0]. I've added section about how
> to join the ruby-sig and deleted the members section as I don't see
> purpose to leave that there anymore.
>
> What are your thoughts?
>
> [0] https://fedoraproject.org/wiki/User:Jackorp1/Draft_RubySIG
>
> Jarek
> ___
> 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



-- 
Jun Aruga / He - His - Him
jar...@redhat.com / IRC: jaruga
___
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


Re: Some issues for Fedora ruby module

2019-05-03 Thread Jun Aruga
Just sharing also asking dnf to improve the help.

dnf module  level help
https://bugzilla.redhat.com/show_bug.cgi?id=1706131

Jun
___
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


Some issues for Fedora ruby module

2019-05-03 Thread Jun Aruga
I would just share I am asking issues for ruby module, as I am testing it.

* Module installation failed without setting default profile.
  https://pagure.io/modularity/issue/133

* How to uninstall module?
  https://pagure.io/modularity/issue/134

* Behavior of /data/profiles/foo/rpms
  https://pagure.io/modularity/issue/135

-- 
Jun Aruga jar...@redhat.com
IRC: jaruga, Office: TPB(Technology Park Brno) Building C 1F, Brno,
Czech Republic
___
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


Re: Ruby 2.6

2019-01-07 Thread Jun Aruga
Hi Vit,
Thanks for that.
I will look at your PR.
https://src.fedoraproject.org/rpms/ruby/pull-request/32

Jun

On Fri, Jan 4, 2019 at 4:18 PM Vít Ondruch  wrote:
>
> Hi,
>
> As planned, Ruby 2.6 was released during Christmas. So I updated my PR
> with the changes required for the official build. There are things which
> could be improved, but there is no blocker IMO (but I have not tested
> the package extensively). So please take look at the PR, here is the
> Koji build (not sure why the koji-simple-ci fails, it seems it somehow
> mangles some dates or ):
>
> https://koji.fedoraproject.org/koji/taskinfo?taskID=31810749
>
> and here is Copr repo for easier testing:
>
> https://copr.fedorainfracloud.org/coprs/vondruch/ruby26/
>
> If there is no issue, I'll ask for side tag and star with rebuild soon.
> Probably next week already unless I am on PTO. Anyway, mass rebuild is
> scheduled on 30th of January (unless I am mistaken), so everything
> should land in Fedora prior that date.
>
>
> Best,
>
>
> Vít
>
>
> Dne 16. 11. 18 v 17:43 Vít Ondruch napsal(a):
> > Hi everybody,
> >
> > I just created PR with .spec file updated to build Ruby 2.6.0.preview3:
> >
> > https://src.fedoraproject.org/rpms/ruby/pull-request/32
> >
> > It is very much WIP, but it builds at least. I have even not tried to
> > install or run the package. Pagure is so nice, that it should provide
> > the recent scratch builds via simple-koji-ci, so I am not going to link
> > it here.
> >
> > So far, there are 3 things missing/ignored:
> >
> > 1. Bundler is completely removed. I am afraid the situation has not
> > improved much since last year. E.g. Molinillo, the dependency solver is
> > included in Ruby twice, once via RubyGems, second time via Bundler, etc.
> > not nice.
> >
> > 2. IRB was gemified, therefore it should be moved into rubygem-
> > subpackage and the original ruby-irb should be obsoleted.
> >
> > 3. I am still undecided how to go forward with JIT. It requires compiler
> > and it has to be explicitly required, therefore we should do nothing
> > IMO. Later, we should probably Suggest or even Require the compiler? Not
> > sure.
> >
> > And as always, please let me know any feedback, either here or in PR.
> >
> >
> > Best,
> >
> >
> > 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://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
> ___
> 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



-- 
Jun Aruga jar...@redhat.com
IRC: jaruga, Office: TPB(Technology Park Brno) Building C 1F, Brno,
Czech Republic
___
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


Re: Ruby 2.6

2018-12-07 Thread Jun Aruga
Ruby 2.6.0.rc1 released yesterday!
https://www.ruby-lang.org/en/news/2018/12/06/ruby-2-6-0-rc1-released/

-- 
Jun Aruga jar...@redhat.com
___
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


  1   2   >