Re: rubygem-licensee and rubygem-faraday
Dne 16. 10. 23 v 16:53 Benson Muite napsal(a): On 10/16/23 14:08, Vít Ondruch wrote: Additionally, what is the reason for having Faraday 2? It seems octokit requires Faraday, but version 1 should be fine. I am not sure about Licensee itself, but on the first look, it seems they are having some troubles with Faraday 2, but I don't see there any direct dependency ... Vít Dne 16. 10. 23 v 12:58 Vít Ondruch napsal(a): Dear Benson, Yeah, the situation about Faraday is a bit unfortunate. I think that also rubygem-typhoeus depends on Faraday 1: https://github.com/typhoeus/typhoeus/blob/f5c5751df49089da89fc2683a23df04850a45604/Gemfile#L18 Nevertheless, would you be open to rather rename the current package to `rubygem-faraday1` and afterwards bump the `rubygem-faraday` to version 2? I understand it is more work initially, but it is better long term. That is ok, though there are dependencies for the latest version of faraday that are not in Fedora. Based on the guidelines: https://docs.fedoraproject.org/en-US/package-maintainers/Package_Renaming_Process/ Should I request a review of faraday1? No need for a review. Would still need to have dependencies of the latest version of faraday reviewed. Yes indeed. Without the dependencies, we would not be able to bump the rubygem-faraday into version 2. Maybe it is conveniient to do this in a sidetag https://docs.fedoraproject.org/en-US/package-maintainers/Package_Update_Guide/#multiple_packages Maybe Vít OpenPGP_signature.asc Description: OpenPGP digital signature ___ 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: rubygem-licensee and rubygem-faraday
On 10/16/23 14:08, Vít Ondruch wrote: > Additionally, what is the reason for having Faraday 2? It seems octokit > requires Faraday, but version 1 should be fine. I am not sure about > Licensee itself, but on the first look, it seems they are having some > troubles with Faraday 2, but I don't see there any direct dependency ... > > > Vít > > > > Dne 16. 10. 23 v 12:58 Vít Ondruch napsal(a): >> Dear Benson, >> >> Yeah, the situation about Faraday is a bit unfortunate. I think that >> also rubygem-typhoeus depends on Faraday 1: >> >> https://github.com/typhoeus/typhoeus/blob/f5c5751df49089da89fc2683a23df04850a45604/Gemfile#L18 >> >> Nevertheless, would you be open to rather rename the current package >> to `rubygem-faraday1` and afterwards bump the `rubygem-faraday` to >> version 2? I understand it is more work initially, but it is better >> long term. That is ok, though there are dependencies for the latest version of faraday that are not in Fedora. Based on the guidelines: https://docs.fedoraproject.org/en-US/package-maintainers/Package_Renaming_Process/ Should I request a review of faraday1? Would still need to have dependencies of the latest version of faraday reviewed. Maybe it is conveniient to do this in a sidetag https://docs.fedoraproject.org/en-US/package-maintainers/Package_Update_Guide/#multiple_packages >> ___ ruby-sig mailing list -- ruby-sig@lists.fedoraproject.org To unsubscribe send an email to ruby-sig-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/ruby-sig@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
Re: Ruby 3.3
Dne 12. 10. 23 v 17:20 Vít Ondruch napsal(a):
Next on my table is allow usage of generators on default/bundled gems.
More details on this approach is here:
https://lists.fedoraproject.org/archives/list/de...@lists.fedoraproject.org/thread/3MHROKOM53HM6NF7RGGLFBIQFG5IEIQG/
and in practice, this will look like:
~~~
$ git diff
diff --git a/ruby.spec b/ruby.spec
index 1aea20b..51f3065 100644
--- a/ruby.spec
+++ b/ruby.spec
@@ -196,6 +196,11 @@ Source15: test_openssl_fips.rb
%{load:%{SOURCE4}}
%{load:%{SOURCE5}}
+%global __local_generator_requires make -C
%{_builddir}/%{buildsubdir}/%{_vpath_builddir} -s runruby
TESTRUN_SCRIPT="--enable-gems %{SOURCE9}"
+%global __local_generator_provides make -C
%{_builddir}/%{buildsubdir}/%{_vpath_builddir} -s runruby
TESTRUN_SCRIPT="--enable-gems %{SOURCE10}"
+%global __local_generator_conflicts make -C
%{_builddir}/%{buildsubdir}/%{_vpath_builddir} -s runruby
TESTRUN_SCRIPT="--enable-gems %{SOURCE11}"
+%global __local_generator_path ^%{gem_dir}/specifications/.*\.gemspec$
+
# Fix ruby_version abuse.
# https://bugs.ruby-lang.org/issues/11002
Patch0: ruby-2.3.0-ruby_version.patch
@@ -229,6 +234,7 @@ Requires: %{name}-libs%{?_isa} =
%{version}-%{release}
Recommends: ruby(rubygems) >= %{rubygems_version}
Recommends: rubygem(bigdecimal) >= %{bigdecimal_version}
+BuildRequires: rpm-local-generator-support
# Build dependencies
BuildRequires: autoconf
BuildRequires: gcc
~~~
But to enable this, I'll soon need help with a review of:
https://copr.fedorainfracloud.org/coprs/vondruch/rpm-local-generator/package/rpm-local-generator-support/
I have submitted this package for a review. Can somebody help me please?
The package can't be simpler.
https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=2244428
Thx in advance
BTW it shaves off ~60 lines of the ruby.spec
Vít
OpenPGP_signature.asc
Description: OpenPGP digital signature
___
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: rubygem-licensee and rubygem-faraday
On 10/16/23 13:08, Vít Ondruch wrote: Additionally, what is the reason for having Faraday 2? It seems octokit requires Faraday, but version 1 should be fine. I am not sure about Licensee itself, but on the first look, it seems they are having some troubles with Faraday 2, but I don't see there any direct dependency ... There might be something "fun" going on in there: https://github.com/licensee/licensee/blob/56dc12bbbe1e4e5b967827c46dfee99c7d59a035/Gemfile#L5 https://github.com/licensee/licensee/commit/e0a4987137d9d429bc897a5568c8c6069410d0a1 It seems it doesn't matter for us https://github.com/octokit/octokit.rb/discussions/1486 They're just trying to remove a warning which we won't get with older faraday as I understand it. Jarek Vít Dne 16. 10. 23 v 12:58 Vít Ondruch napsal(a): Dear Benson, Yeah, the situation about Faraday is a bit unfortunate. I think that also rubygem-typhoeus depends on Faraday 1: https://github.com/typhoeus/typhoeus/blob/f5c5751df49089da89fc2683a23df04850a45604/Gemfile#L18 Nevertheless, would you be open to rather rename the current package to `rubygem-faraday1` and afterwards bump the `rubygem-faraday` to version 2? I understand it is more work initially, but it is better long term. Thx Vít Dne 14. 10. 23 v 18:59 Benson Muite napsal(a): Am working on packaging rubygem-licensee as it would probably be a useful complement to scancode-toolkit and other similar tools. It requires rubygem-faraday >= 2.0 but rubygem-elasticsearch-transport for elasticsearch 7 requires rubygem-faraday >~ 1.0 so am packaging it as rubygem-faraday2. Hope this will be ok. https://bugzilla.redhat.com/show_bug.cgi?id=2244212 Issue upstream: https://github.com/elastic/elasticsearch-ruby/issues/2228 ___ ruby-sig mailing list -- ruby-sig@lists.fedoraproject.org To unsubscribe send an email to ruby-sig-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/ruby-sig@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue ___ ruby-sig mailing list -- ruby-sig@lists.fedoraproject.org To unsubscribe send an email to ruby-sig-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/ruby-sig@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue ___ ruby-sig mailing list -- ruby-sig@lists.fedoraproject.org To unsubscribe send an email to ruby-sig-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/ruby-sig@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
Re: rubygem-licensee and rubygem-faraday
Additionally, what is the reason for having Faraday 2? It seems octokit requires Faraday, but version 1 should be fine. I am not sure about Licensee itself, but on the first look, it seems they are having some troubles with Faraday 2, but I don't see there any direct dependency ... Vít Dne 16. 10. 23 v 12:58 Vít Ondruch napsal(a): Dear Benson, Yeah, the situation about Faraday is a bit unfortunate. I think that also rubygem-typhoeus depends on Faraday 1: https://github.com/typhoeus/typhoeus/blob/f5c5751df49089da89fc2683a23df04850a45604/Gemfile#L18 Nevertheless, would you be open to rather rename the current package to `rubygem-faraday1` and afterwards bump the `rubygem-faraday` to version 2? I understand it is more work initially, but it is better long term. Thx Vít Dne 14. 10. 23 v 18:59 Benson Muite napsal(a): Am working on packaging rubygem-licensee as it would probably be a useful complement to scancode-toolkit and other similar tools. It requires rubygem-faraday >= 2.0 but rubygem-elasticsearch-transport for elasticsearch 7 requires rubygem-faraday >~ 1.0 so am packaging it as rubygem-faraday2. Hope this will be ok. https://bugzilla.redhat.com/show_bug.cgi?id=2244212 Issue upstream: https://github.com/elastic/elasticsearch-ruby/issues/2228 ___ 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 OpenPGP_signature.asc Description: OpenPGP digital signature ___ 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: rubygem-licensee and rubygem-faraday
Hello, feel free to look at packaged licensee gem in my COPR: https://copr.fedorainfracloud.org/coprs/pvalena/rubygems/package/rubygem-licensee/ I haven't looked at the `.spec` for a long time. It has just some dependencies removed, and is probably quite an old version. But maybe just for reference. Regards, Pavel On Sat, Oct 14, 2023 at 6:59 PM Benson Muite wrote: > Am working on packaging rubygem-licensee as it would probably be a > useful complement to scancode-toolkit and other similar tools. It > requires rubygem-faraday >= 2.0 but rubygem-elasticsearch-transport for > elasticsearch 7 requires rubygem-faraday >~ 1.0 so am packaging it as > rubygem-faraday2. Hope this will be ok. > > https://bugzilla.redhat.com/show_bug.cgi?id=2244212 > > Issue upstream: > https://github.com/elastic/elasticsearch-ruby/issues/2228 > ___ > ruby-sig mailing list -- ruby-sig@lists.fedoraproject.org > To unsubscribe send an email to ruby-sig-le...@lists.fedoraproject.org > Fedora Code of Conduct: > https://docs.fedoraproject.org/en-US/project/code-of-conduct/ > List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines > List Archives: > https://lists.fedoraproject.org/archives/list/ruby-sig@lists.fedoraproject.org > Do not reply to spam, report it: > https://pagure.io/fedora-infrastructure/new_issue > ___ ruby-sig mailing list -- ruby-sig@lists.fedoraproject.org To unsubscribe send an email to ruby-sig-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/ruby-sig@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
Re: rubygem-licensee and rubygem-faraday
On 10/14/23 18:59, Benson Muite wrote: Am working on packaging rubygem-licensee as it would probably be a useful complement to scancode-toolkit and other similar tools. It requires rubygem-faraday >= 2.0 but rubygem-elasticsearch-transport for elasticsearch 7 requires rubygem-faraday >~ 1.0 so am packaging it as rubygem-faraday2. Hope this will be ok. Quite unusual approach in the Ruby ecosystem. I am not sure we necessarily need rubygem-elasticsearch-transport in Fedora, but that migth be a different discussion. Personally, I'd rather see rubygem-faraday1 (or whatever for faraday >= 1.0 < 2.0) for the reverse dependencies that fall apart with the newer faraday and have the rest use rubygem-faraday >= 2.0. https://bugzilla.redhat.com/show_bug.cgi?id=2244212 Left an unnoficial review after a short glance at the specfile, I can understand test suite not running yet, but it should ideally run. https://bugzilla.redhat.com/show_bug.cgi?id=2244212#c1 Issue upstream: https://github.com/elastic/elasticsearch-ruby/issues/2228 Regards, Jarek Prokop ___ 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: rubygem-licensee and rubygem-faraday
Dear Benson, Yeah, the situation about Faraday is a bit unfortunate. I think that also rubygem-typhoeus depends on Faraday 1: https://github.com/typhoeus/typhoeus/blob/f5c5751df49089da89fc2683a23df04850a45604/Gemfile#L18 Nevertheless, would you be open to rather rename the current package to `rubygem-faraday1` and afterwards bump the `rubygem-faraday` to version 2? I understand it is more work initially, but it is better long term. Thx Vít Dne 14. 10. 23 v 18:59 Benson Muite napsal(a): Am working on packaging rubygem-licensee as it would probably be a useful complement to scancode-toolkit and other similar tools. It requires rubygem-faraday >= 2.0 but rubygem-elasticsearch-transport for elasticsearch 7 requires rubygem-faraday >~ 1.0 so am packaging it as rubygem-faraday2. Hope this will be ok. https://bugzilla.redhat.com/show_bug.cgi?id=2244212 Issue upstream: https://github.com/elastic/elasticsearch-ruby/issues/2228 ___ 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 OpenPGP_signature.asc Description: OpenPGP digital signature ___ ruby-sig mailing list -- ruby-sig@lists.fedoraproject.org To unsubscribe send an email to ruby-sig-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/ruby-sig@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
Re: Ruby 3.3
Dne 15. 10. 23 v 1:48 Mamoru TASAKA napsal(a):
Vít Ondruch wrote on 2023/10/13 0:20:
Hi,
I am back again with yet another update, this time to e029375a7d. The
changes are in the PR:
Vít, would you take a look at this change?
https://github.com/rubygems/rubygems/pull/5327
It is on my TODO list, but I am still postponing feedback, because I did
not have high hopes this will go right. Oh well.
Thx for spotting this.
Vít
In ruby.git , these are imported from
7aebe2a52bac2a925c475c511640ad13a7d20490 to
9dcaa832592af0125ba6407a506b2b3953b2f81c , I guess.
Perhaps due to the above changes:
[A] now "gem build ../foo-version.spec" as we usually do in
rubygem-foo.spec fails like:
-
+ gem build ../Ascii85-1.1.0.gemspec
Defaulting to user installation because default GEM_HOME
(/usr/share/gems) is not writable.
Invalid gemspec in [../Ascii85-1.1.0.gemspec]:
../Ascii85-1.1.0.gemspec:1: unknown regexp options - har
...se default GEM_HOME (/usr/share/gems) is not writable.
... ^~
../Ascii85-1.1.0.gemspec:1: syntax error, unexpected local variable or
method, expecting end-of-input
...t GEM_HOME (/usr/share/gems) is not writable.
... ^~
ERROR: Error loading gemspec. Aborting.
error: Bad exit status from /var/tmp/rpm-tmp.Cvl7rH (%build)
-
So this affects (breaks) almost all of Fedora rubygem- packages.
[B]
Also, even if I workaround this, %gem_install , i.e.
$ gem install -V --local --build-root . --force --document=ri,rdoc
%{gem_name}-%{version}.gem
now installs files under $HOME/.local:
-
+ gem install -V --local --build-root . --force --document=ri,rdoc
Ascii85-1.1.0.gem
Defaulting to user installation because default GEM_HOME
(/usr/share/gems) is not writable.
WARNING: You build with buildroot.
Build root: /builddir/build/BUILD/Ascii85-1.1.0
Bin dir:
/builddir/build/BUILD/Ascii85-1.1.0/builddir/.local/share/gem/ruby/bin
Gem home:
/builddir/build/BUILD/Ascii85-1.1.0/builddir/.local/share/gem/ruby
Plugins dir:
/builddir/build/BUILD/Ascii85-1.1.0/builddir/.local/share/gem/ruby/plugins
/builddir/build/BUILD/Ascii85-1.1.0/builddir/.local/share/gem/ruby/gems/Ascii85-1.1.0/.travis.yml
/builddir/build/BUILD/Ascii85-1.1.0/builddir/.local/share/gem/ruby/gems/Ascii85-1.1.0/Ascii85.gemspec
/builddir/build/BUILD/Ascii85-1.1.0/builddir/.local/share/gem/ruby/gems/Ascii85-1.1.0/Gemfile
/builddir/build/BUILD/Ascii85-1.1.0/builddir/.local/share/gem/ruby/gems/Ascii85-1.1.0/History.txt
/builddir/build/BUILD/Ascii85-1.1.0/builddir/.local/share/gem/ruby/gems/Ascii85-1.1.0/LICENSE
/builddir/build/BUILD/Ascii85-1.1.0/builddir/.local/share/gem/ruby/gems/Ascii85-1.1.0/README.md
/builddir/build/BUILD/Ascii85-1.1.0/builddir/.local/share/gem/ruby/gems/Ascii85-1.1.0/Rakefile
/builddir/build/BUILD/Ascii85-1.1.0/builddir/.local/share/gem/ruby/gems/Ascii85-1.1.0/bin/ascii85
/builddir/build/BUILD/Ascii85-1.1.0/builddir/.local/share/gem/ruby/gems/Ascii85-1.1.0/lib/Ascii85/version.rb
/builddir/build/BUILD/Ascii85-1.1.0/builddir/.local/share/gem/ruby/gems/Ascii85-1.1.0/lib/ascii85.rb
/builddir/build/BUILD/Ascii85-1.1.0/builddir/.local/share/gem/ruby/gems/Ascii85-1.1.0/spec/lib/ascii85_spec.rb
/builddir/build/BUILD/Ascii85-1.1.0/builddir/.local/share/gem/ruby/bin/ascii85
-
So for now, I essentially reverted the above PR5327 changes on my
local ruby.src (based on
your ruby.src) and it looks working as before, so again I am going to
do trial rebuild for
all rubygem- packages.
(Well, when I saw these lots of git changelog related to rubygems part
on ruby.git,
I had a bad feeling about this.)
Regards,
Mamoru
https://src.fedoraproject.org/rpms/ruby/pull-request/159
And the scratch build is running here:
https://koji.fedoraproject.org/koji/taskinfo?taskID=107409961
From upstream POV, there is nothing particularly interesting, except
of the rename of the new Ruby source code parser from YART to prism
and on strange JIT test failure.
From changes in the .spec file, I have migrated every custom
reference of gem path to the %gem_ macros. This was enabled by this
commit:
https://src.fedoraproject.org/fork/vondruch/rpms/ruby/c/c514f5f13c709dc289754663ba31491617d83811
Please note that this commit also introduces `%gem_name_version`
macro, which we could use in place of `%{gem_name}-%{version}`.
Next on my table is allow usage of generators on default/bundled
gems. More details on this approach is here:
https://lists.fedoraproject.org/archives/list/de...@lists.fedoraproject.org/thread/3MHROKOM53HM6NF7RGGLFBIQFG5IEIQG/
and in practice, this will look like:
~~~
$ git diff
diff --git a/ruby.spec b/ruby.spec
index 1aea20b..51f3065 100644
--- a/ruby.spec
+++ b/ruby.spec
@@
