Re: [GOLDSTAR] Re: [ITA] ruby 3.2.2
Thank you. I am deeply grateful and happy to receive this award. On Wed, Jun 14, 2023 at 12:05 AM Andrew Schulman via Cygwin-apps wrote: > > > On 19/04/2023 23:42, Daisuke Fujimura via Cygwin-apps wrote: > > > Hello, > > > > > > > > > > > > Cygportfile: > > > - > > > https://cygwin.com/git-cygwin-packages/?p=git/cygwin-packages/playground.git;a=shortlog;h=refs/heads/ruby > > > > > > Packages, logs: > > > - https://github.com/cygwin/scallywag/actions/runs/4743191979 > > > > According to our rules, Fujimura-san deserves one of our literally > > priceless gold stars for adopting Ruby. > > > > ... and several more, arranged into a tasteful tiara or something, for > > adopting and updating various ruby language packages. > > Awarded! https://cygwin.com/goldstars/#DF >
Re: [GOLDSTAR] Re: [ITA] ruby 3.2.2
> On 19/04/2023 23:42, Daisuke Fujimura via Cygwin-apps wrote: > > Hello, > > > > > > > > Cygportfile: > > - > > https://cygwin.com/git-cygwin-packages/?p=git/cygwin-packages/playground.git;a=shortlog;h=refs/heads/ruby > > > > Packages, logs: > > - https://github.com/cygwin/scallywag/actions/runs/4743191979 > > According to our rules, Fujimura-san deserves one of our literally > priceless gold stars for adopting Ruby. > > ... and several more, arranged into a tasteful tiara or something, for > adopting and updating various ruby language packages. Awarded! https://cygwin.com/goldstars/#DF
[GOLDSTAR] Re: [ITA] ruby 3.2.2
On 19/04/2023 23:42, Daisuke Fujimura via Cygwin-apps wrote: Hello, Cygportfile: - https://cygwin.com/git-cygwin-packages/?p=git/cygwin-packages/playground.git;a=shortlog;h=refs/heads/ruby Packages, logs: - https://github.com/cygwin/scallywag/actions/runs/4743191979 According to our rules, Fujimura-san deserves one of our literally priceless gold stars for adopting Ruby. ... and several more, arranged into a tasteful tiara or something, for adopting and updating various ruby language packages.
Re: [ITA] ruby 3.2.2
> Yeah, I'm not quite sure what that statement means. It's not literally > "every single binary in cygwin" > > I don't really know enough about ruby be sure how to interpret it. > There's some subset of packages which need rebuilding (as discussed > below), and maybe any locally installed gems which have binaries? As you pointed out, the sub-packages and gems installed locally using the gem command that depend on cygruby*0.dll will be subject to recompilation. I apologize for the insufficient explanation. On Wed, Apr 26, 2023 at 7:13 AM Jon Turney wrote: > > On 25/04/2023 22:10, Daisuke Fujimura via Cygwin-apps wrote: > > Thank you for your response. > > > > Following the announcement of the previous update, I would like to > > note that the binaries need to be recompiled. > > - > > https://www.mail-archive.com/cygwin-announce-rDBXBDvO6BXQT0dZR+AlfA@public.gmane.org/msg08753.html > > Yeah, I'm not quite sure what that statement means. It's not literally > "every single binary in cygwin" > > I don't really know enough about ruby be sure how to interpret it. > There's some subset of packages which need rebuilding (as discussed > below), and maybe any locally installed gems which have binaries? > > >> I applied my usual workaround (which is adding 'ruby_23' to an internal > >> list of things which are allowed to not be provided), and set the job to > >> rerun, which seems to have succeeded. > > > > Does this mean adding `ruby_23` to `depend2` in some packages in setup.ini? > > Not really. > > The failure was a consequence of that. As previously mentioned, using > some special tools, I've retroactively added appropriate ruby_xy > requires: in the .hint files for existing packages which: > > * install into /usr/lib/ruby/vendor_ruby/x.y/ > * install into /usr/lib/gems/ruby/x.y/ > * contain executable files linked to cygrubyxy0.dll because they embed a > ruby interpreter (which seems to be just kross-ruby, kf5-kross-ruby and > weechat-ruby) > > > I would like to know more about the specifications of setup.ini. Is > > there any documentation available somewhere? > > Sure, the documentation is at: > > https://sourceware.org/cygwin-apps/setup.ini.html > > Feel free to ask if you have further questions not covered by that. >
Re: [ITA] ruby 3.2.2
On 25/04/2023 22:10, Daisuke Fujimura via Cygwin-apps wrote: Thank you for your response. Following the announcement of the previous update, I would like to note that the binaries need to be recompiled. - https://www.mail-archive.com/cygwin-announce-rDBXBDvO6BXQT0dZR+AlfA@public.gmane.org/msg08753.html Yeah, I'm not quite sure what that statement means. It's not literally "every single binary in cygwin" I don't really know enough about ruby be sure how to interpret it. There's some subset of packages which need rebuilding (as discussed below), and maybe any locally installed gems which have binaries? I applied my usual workaround (which is adding 'ruby_23' to an internal list of things which are allowed to not be provided), and set the job to rerun, which seems to have succeeded. Does this mean adding `ruby_23` to `depend2` in some packages in setup.ini? Not really. The failure was a consequence of that. As previously mentioned, using some special tools, I've retroactively added appropriate ruby_xy requires: in the .hint files for existing packages which: * install into /usr/lib/ruby/vendor_ruby/x.y/ * install into /usr/lib/gems/ruby/x.y/ * contain executable files linked to cygrubyxy0.dll because they embed a ruby interpreter (which seems to be just kross-ruby, kf5-kross-ruby and weechat-ruby) I would like to know more about the specifications of setup.ini. Is there any documentation available somewhere? Sure, the documentation is at: https://sourceware.org/cygwin-apps/setup.ini.html Feel free to ask if you have further questions not covered by that.
Re: [ITA] ruby 3.2.2
Thank you for your response. Following the announcement of the previous update, I would like to note that the binaries need to be recompiled. - https://www.mail-archive.com/cygwin-announce@cygwin.com/msg08753.html > I applied my usual workaround (which is adding 'ruby_23' to an internal > list of things which are allowed to not be provided), and set the job to > rerun, which seems to have succeeded. Does this mean adding `ruby_23` to `depend2` in some packages in setup.ini? I would like to know more about the specifications of setup.ini. Is there any documentation available somewhere? On Tue, Apr 25, 2023 at 10:52 PM Jon Turney wrote: > > On 25/04/2023 10:56, Daisuke Fujimura via Cygwin-apps wrote: > >> I don't think so. Please, go ahead and deploy. > > > > I tried to deploy twice, but it failed. > > > > First attempt: > > - https://github.com/cygwin/scallywag/actions/runs/4791077183 > > > > ``` > > ERROR: package 'ruby-tcltk' version '3.2.2-1' has empty install tar > > file, but it's not in ['virtual', '_obsolete'] category > > ERROR: error while validating merged x86_64 packages for Daisuke Fujimura > > SUMMARY: 2 ERROR(s) > > ``` > > > > I fixed it according to the error message. > > - > > https://cygwin.com/cgit/cygwin-packages/ruby/commit/?id=e1bc357d4ca0423b5ec92aaeb3846adf7351efa3 > > > > Thanks. > > If you subsequently adopt the ruby-tk package, please remember to add > ruby_tk_OBSOLETES="ruby-tcltk" there (as that's the preferred way to > record obsoletions nowadays) > > > Second attempt: > > - https://github.com/cygwin/scallywag/actions/runs/4791758304 > > > > ``` > > ERROR: package 'ruby-caca' version '0.99.beta19-4' depends: 'ruby_23', > > but nothing satisfies that > > ERROR: package 'ruby-marisa' version '0.2.4-2' depends: 'ruby_23', but > > nothing satisfies that > > ERROR: package 'ruby-marisa' version '0.2.4-3' depends: 'ruby_23', but > > nothing satisfies that > > ERROR: package 'ruby-openbabel' version '2.3.2-6' depends: 'ruby_23', > > but nothing satisfies that > > ERROR: package 'ruby-openbabel' version '2.3.2-5' depends: 'ruby_23', > > but nothing satisfies that > > ERROR: package 'ruby-openwsman' version '2.6.3-3' depends: 'ruby_23', > > but nothing satisfies that > > ERROR: package 'ruby-openwsman' version '2.6.3-2' depends: 'ruby_23', > > but nothing satisfies that > > ERROR: package 'ruby-xapian' version '1.2.24-1' depends: 'ruby_23', > > but nothing satisfies that > > ERROR: package 'ruby-xapian' version '1.4.5-1' depends: 'ruby_23', but > > nothing satisfies that > > ERROR: package 'ruby-zinnia' version '0.06-8' depends: 'ruby_23', but > > nothing satisfies that > > ERROR: package 'ruby-zinnia' version '0.06-9' depends: 'ruby_23', but > > nothing satisfies that > > ERROR: package 'subversion-ruby' version '1.11.1-1' depends: > > 'ruby_23', but nothing satisfies that > > ERROR: x86_64 package set has errors after removing stale packages > > ERROR: error while evaluating stale packages for Daisuke Fujimura > > SUMMARY: 14 ERROR(s) > > ``` > > > > When I deployed ruby-3.2.2, ruby-2.3.6 (which provides ruby_23) was > > moved to the vault, resulting in some ruby-* subpackages being unable > > to satisfy the dependency of ruby_23. > > > > To resolve this, the following methods are being considered: > > > > - Do not move ruby-2.3.6 to the vault (I cannot do this myself). > > - Rebuild the subpackages. > > - Any other methods? > > Yeah, calm needs to learn how to deal with this scenario better. > > Probably what should actually happen here is that these packages get > expired at the same time that the last thing providing ruby_23 gets > expired (as they can no longer be installed and thus keeping them is a > bit pointless) > > > Is there anything I can do to deploy ruby-3.2.2? > > I applied my usual workaround (which is adding 'ruby_23' to an internal > list of things which are allowed to not be provided), and set the job to > rerun, which seems to have succeeded. > > > Apologies for the inconvenience, and thanks again for updating ruby! >
Re: [ITA] ruby 3.2.2
On 25/04/2023 10:56, Daisuke Fujimura via Cygwin-apps wrote: I don't think so. Please, go ahead and deploy. I tried to deploy twice, but it failed. First attempt: - https://github.com/cygwin/scallywag/actions/runs/4791077183 ``` ERROR: package 'ruby-tcltk' version '3.2.2-1' has empty install tar file, but it's not in ['virtual', '_obsolete'] category ERROR: error while validating merged x86_64 packages for Daisuke Fujimura SUMMARY: 2 ERROR(s) ``` I fixed it according to the error message. - https://cygwin.com/cgit/cygwin-packages/ruby/commit/?id=e1bc357d4ca0423b5ec92aaeb3846adf7351efa3 Thanks. If you subsequently adopt the ruby-tk package, please remember to add ruby_tk_OBSOLETES="ruby-tcltk" there (as that's the preferred way to record obsoletions nowadays) Second attempt: - https://github.com/cygwin/scallywag/actions/runs/4791758304 ``` ERROR: package 'ruby-caca' version '0.99.beta19-4' depends: 'ruby_23', but nothing satisfies that ERROR: package 'ruby-marisa' version '0.2.4-2' depends: 'ruby_23', but nothing satisfies that ERROR: package 'ruby-marisa' version '0.2.4-3' depends: 'ruby_23', but nothing satisfies that ERROR: package 'ruby-openbabel' version '2.3.2-6' depends: 'ruby_23', but nothing satisfies that ERROR: package 'ruby-openbabel' version '2.3.2-5' depends: 'ruby_23', but nothing satisfies that ERROR: package 'ruby-openwsman' version '2.6.3-3' depends: 'ruby_23', but nothing satisfies that ERROR: package 'ruby-openwsman' version '2.6.3-2' depends: 'ruby_23', but nothing satisfies that ERROR: package 'ruby-xapian' version '1.2.24-1' depends: 'ruby_23', but nothing satisfies that ERROR: package 'ruby-xapian' version '1.4.5-1' depends: 'ruby_23', but nothing satisfies that ERROR: package 'ruby-zinnia' version '0.06-8' depends: 'ruby_23', but nothing satisfies that ERROR: package 'ruby-zinnia' version '0.06-9' depends: 'ruby_23', but nothing satisfies that ERROR: package 'subversion-ruby' version '1.11.1-1' depends: 'ruby_23', but nothing satisfies that ERROR: x86_64 package set has errors after removing stale packages ERROR: error while evaluating stale packages for Daisuke Fujimura SUMMARY: 14 ERROR(s) ``` When I deployed ruby-3.2.2, ruby-2.3.6 (which provides ruby_23) was moved to the vault, resulting in some ruby-* subpackages being unable to satisfy the dependency of ruby_23. To resolve this, the following methods are being considered: - Do not move ruby-2.3.6 to the vault (I cannot do this myself). - Rebuild the subpackages. - Any other methods? Yeah, calm needs to learn how to deal with this scenario better. Probably what should actually happen here is that these packages get expired at the same time that the last thing providing ruby_23 gets expired (as they can no longer be installed and thus keeping them is a bit pointless) Is there anything I can do to deploy ruby-3.2.2? I applied my usual workaround (which is adding 'ruby_23' to an internal list of things which are allowed to not be provided), and set the job to rerun, which seems to have succeeded. Apologies for the inconvenience, and thanks again for updating ruby!
Re: [ITA] ruby 3.2.2
> I don't think so. Please, go ahead and deploy.
I tried to deploy twice, but it failed.
First attempt:
- https://github.com/cygwin/scallywag/actions/runs/4791077183
```
ERROR: package 'ruby-tcltk' version '3.2.2-1' has empty install tar
file, but it's not in ['virtual', '_obsolete'] category
ERROR: error while validating merged x86_64 packages for Daisuke Fujimura
SUMMARY: 2 ERROR(s)
```
I fixed it according to the error message.
-
https://cygwin.com/cgit/cygwin-packages/ruby/commit/?id=e1bc357d4ca0423b5ec92aaeb3846adf7351efa3
Second attempt:
- https://github.com/cygwin/scallywag/actions/runs/4791758304
```
ERROR: package 'ruby-caca' version '0.99.beta19-4' depends: 'ruby_23',
but nothing satisfies that
ERROR: package 'ruby-marisa' version '0.2.4-2' depends: 'ruby_23', but
nothing satisfies that
ERROR: package 'ruby-marisa' version '0.2.4-3' depends: 'ruby_23', but
nothing satisfies that
ERROR: package 'ruby-openbabel' version '2.3.2-6' depends: 'ruby_23',
but nothing satisfies that
ERROR: package 'ruby-openbabel' version '2.3.2-5' depends: 'ruby_23',
but nothing satisfies that
ERROR: package 'ruby-openwsman' version '2.6.3-3' depends: 'ruby_23',
but nothing satisfies that
ERROR: package 'ruby-openwsman' version '2.6.3-2' depends: 'ruby_23',
but nothing satisfies that
ERROR: package 'ruby-xapian' version '1.2.24-1' depends: 'ruby_23',
but nothing satisfies that
ERROR: package 'ruby-xapian' version '1.4.5-1' depends: 'ruby_23', but
nothing satisfies that
ERROR: package 'ruby-zinnia' version '0.06-8' depends: 'ruby_23', but
nothing satisfies that
ERROR: package 'ruby-zinnia' version '0.06-9' depends: 'ruby_23', but
nothing satisfies that
ERROR: package 'subversion-ruby' version '1.11.1-1' depends:
'ruby_23', but nothing satisfies that
ERROR: x86_64 package set has errors after removing stale packages
ERROR: error while evaluating stale packages for Daisuke Fujimura
SUMMARY: 14 ERROR(s)
```
When I deployed ruby-3.2.2, ruby-2.3.6 (which provides ruby_23) was
moved to the vault, resulting in some ruby-* subpackages being unable
to satisfy the dependency of ruby_23.
To resolve this, the following methods are being considered:
- Do not move ruby-2.3.6 to the vault (I cannot do this myself).
- Rebuild the subpackages.
- Any other methods?
Is there anything I can do to deploy ruby-3.2.2?
On Tue, Apr 25, 2023 at 5:10 AM Jon Turney wrote:
>
> On 24/04/2023 00:44, Daisuke Fujimura via Cygwin-apps wrote:
> >> This is what I get for not trying these things. I think nesting the
> >> substitution like that isn't valid in bash, so maybe:
> >>
> >> SOVERSION=${VERSION%.*}
> >> ruby_PROVIDES="ruby_${SOVERSION//./}"
> >>
> >> actually works?
> >
> > It worked. Thank you very much.
> >
> > ```
> > $ cygport ruby.cygport vars ruby_PROVIDES
> > declare -- ruby_PROVIDES="ruby_32"
> > ```
> >
> > -
> > https://cygwin.com/cgit/cygwin-packages/playground/commit/?id=9b448625c2166d5c7310c295bfa4328d24ac5444
> > -
> > https://github.com/cygwin/scallywag/actions/runs/4780609520/jobs/8498537391
> >
> >
> > I think I can release ruby-3.2.2-1 without applying the cygport patch,
> > but is there any problem if I deploy it?
>
> I don't think so. Please, go ahead and deploy.
>
> > (The cygport patch should not be needed until someone rebuilds the
> > ruby-* subpackages.)
>
> Right. Hopefully I'll get around around to doing a cygport release with
> that change this week.
>
Re: [ITA] ruby 3.2.2
On 24/04/2023 00:44, Daisuke Fujimura via Cygwin-apps wrote:
This is what I get for not trying these things. I think nesting the
substitution like that isn't valid in bash, so maybe:
SOVERSION=${VERSION%.*}
ruby_PROVIDES="ruby_${SOVERSION//./}"
actually works?
It worked. Thank you very much.
```
$ cygport ruby.cygport vars ruby_PROVIDES
declare -- ruby_PROVIDES="ruby_32"
```
-
https://cygwin.com/cgit/cygwin-packages/playground/commit/?id=9b448625c2166d5c7310c295bfa4328d24ac5444
- https://github.com/cygwin/scallywag/actions/runs/4780609520/jobs/8498537391
I think I can release ruby-3.2.2-1 without applying the cygport patch,
but is there any problem if I deploy it?
I don't think so. Please, go ahead and deploy.
(The cygport patch should not be needed until someone rebuilds the
ruby-* subpackages.)
Right. Hopefully I'll get around around to doing a cygport release with
that change this week.
Re: [ITA] ruby 3.2.2
> This is what I get for not trying these things. I think nesting the
> substitution like that isn't valid in bash, so maybe:
>
> SOVERSION=${VERSION%.*}
> ruby_PROVIDES="ruby_${SOVERSION//./}"
>
> actually works?
It worked. Thank you very much.
```
$ cygport ruby.cygport vars ruby_PROVIDES
declare -- ruby_PROVIDES="ruby_32"
```
-
https://cygwin.com/cgit/cygwin-packages/playground/commit/?id=9b448625c2166d5c7310c295bfa4328d24ac5444
- https://github.com/cygwin/scallywag/actions/runs/4780609520/jobs/8498537391
I think I can release ruby-3.2.2-1 without applying the cygport patch,
but is there any problem if I deploy it?
(The cygport patch should not be needed until someone rebuilds the
ruby-* subpackages.)
On Sun, Apr 23, 2023 at 10:35 PM Jon Turney wrote:
>
> On 22/04/2023 13:04, Daisuke Fujimura via Cygwin-apps wrote:
> >> Are you planning to adopt also the ruby-* sub-packages ?
> >
> > I intend to do that.
> >
> >
> >>> 2. Modify cygport and release it.
> >>> - Add code to detect dependencies on `ruby_xy`.
> >>> - It is similar to the process for `perl5_xy0`.
> >>> -
> >>> https://github.com/cygwin/cygport/blob/0.36.2/lib/pkg_info.cygpart#L442
> >>> -
> >>> https://github.com/cygwin/cygport/blob/0.36.2/lib/pkg_info.cygpart#L639
> >>
> >> Yes.
> >>
> >> I'm not asking you to do this work though, unless you really feel like it
> >> :)
> >
> > Please review the attached diff.
>
> That looks like almost exactly what's needed.
>
> Thank you very much for that!
>
> >>> - Add `ruby_PROVIDES="ruby_${${VERSION%.*}//./}"` to ruby.cygport.
> >
> > ```
> > /tmp/cygport-ruby/ruby.cygport: line 49: ${${VERSION%.*}//./}: bad
> > substitution
> > ```
> >
> > Is the warning being displayed because $VERSION (=3.2.2) starts with a
> > number?
>
> This is what I get for not trying these things. I think nesting the
> substitution like that isn't valid in bash, so maybe:
>
> SOVERSION=${VERSION%.*}
> ruby_PROVIDES="ruby_${SOVERSION//./}"
>
> actually works?
>
Re: [ITA] ruby 3.2.2
On 22/04/2023 13:04, Daisuke Fujimura via Cygwin-apps wrote:
Are you planning to adopt also the ruby-* sub-packages ?
I intend to do that.
2. Modify cygport and release it.
- Add code to detect dependencies on `ruby_xy`.
- It is similar to the process for `perl5_xy0`.
-
https://github.com/cygwin/cygport/blob/0.36.2/lib/pkg_info.cygpart#L442
-
https://github.com/cygwin/cygport/blob/0.36.2/lib/pkg_info.cygpart#L639
Yes.
I'm not asking you to do this work though, unless you really feel like it :)
Please review the attached diff.
That looks like almost exactly what's needed.
Thank you very much for that!
- Add `ruby_PROVIDES="ruby_${${VERSION%.*}//./}"` to ruby.cygport.
```
/tmp/cygport-ruby/ruby.cygport: line 49: ${${VERSION%.*}//./}: bad substitution
```
Is the warning being displayed because $VERSION (=3.2.2) starts with a number?
This is what I get for not trying these things. I think nesting the
substitution like that isn't valid in bash, so maybe:
SOVERSION=${VERSION%.*}
ruby_PROVIDES="ruby_${SOVERSION//./}"
actually works?
Re: [ITA] ruby 3.2.2
> Are you planning to adopt also the ruby-* sub-packages ?
I intend to do that.
> > 2. Modify cygport and release it.
> > - Add code to detect dependencies on `ruby_xy`.
> > - It is similar to the process for `perl5_xy0`.
> > -
> > https://github.com/cygwin/cygport/blob/0.36.2/lib/pkg_info.cygpart#L442
> > -
> > https://github.com/cygwin/cygport/blob/0.36.2/lib/pkg_info.cygpart#L639
>
> Yes.
>
> I'm not asking you to do this work though, unless you really feel like it :)
Please review the attached diff.
> > - Add `ruby_PROVIDES="ruby_${${VERSION%.*}//./}"` to ruby.cygport.
```
/tmp/cygport-ruby/ruby.cygport: line 49: ${${VERSION%.*}//./}: bad substitution
```
Is the warning being displayed because $VERSION (=3.2.2) starts with a number?
On Sat, Apr 22, 2023 at 5:06 AM Jon Turney wrote:
>
> On 21/04/2023 20:36, Daisuke Fujimura via Cygwin-apps wrote:
> > Thank you for your review.
> >
> > Based on your review, I understand that the following steps are necessary.
> >
> > Could you please let me know if it is correct?
> >
> > 1. Release `ruby-2.6.4-2`.
> > - Add `ruby_PROVIDES="ruby_${${VERSION%.*}//./}"` to ruby.cygport.
> > - The value of this variable will be `ruby_26`.
> > - `provides: ruby_26` is added to `ruby-2.6.4-2.hint`.
>
> This isn't needed. I've retroactively modified the existing 2.6.4-1 and
> 2.6.3-1 packages to have this provide.
>
> > 2. Modify cygport and release it.
> > - Add code to detect dependencies on `ruby_xy`.
> > - It is similar to the process for `perl5_xy0`.
> > -
> > https://github.com/cygwin/cygport/blob/0.36.2/lib/pkg_info.cygpart#L442
> > -
> > https://github.com/cygwin/cygport/blob/0.36.2/lib/pkg_info.cygpart#L639
>
> Yes.
>
> I'm not asking you to do this work though, unless you really feel like it :)
>
> > 3. Rebuild `ruby-*` subpackages.
>
> Again, this isn't needed as I can retroactively modify existing packages.
>
> > - The new cygport adds `depends: ruby_26` to the hint.
>
> I've retroactively added this to the packages listed below, which
> install into /usr/lib/ruby/vendor_ruby/2.6/ a .so linked to cygruby260.dll:
>
> > - (Question) Does a gem that has no dependencies on `cygruby*.dll`
> > need to rebuild?
>
> I don't really know enough about ruby to answer that question, but
> I don't think so.
>
> > 4. Release `ruby-3.2.2-1`.
> > - The value of `provides` becomes `ruby_32`.
> > - Packages that depend on `ruby_26` will no longer be installable.
> > 5. Rebuild `ruby-*` subpackages.
> > - The rebuild adds `depends: ruby_32` to the hint.
>
> Yes.
>
> The idea is that this will ensures that packages which are installed
> together will work together, going forwards.
>
> > On Fri, Apr 21, 2023 at 1:13 AM Jon Turney wrote:
> >> On 20/04/2023 11:50, Jon Turney via Cygwin-apps wrote:
> >>> On 20/04/2023 04:28, Marco Atzeri via Cygwin-apps wrote:
> On 20.04.2023 00:42, Daisuke Fujimura via Cygwin-apps wrote:
> > Hello,
> >
> >
> >
> > Cygportfile:
> > -
> > https://cygwin.com/git-cygwin-packages/?p=git/cygwin-packages/playground.git;a=shortlog;h=refs/heads/ruby
> >
> >>
> >> Looks fine. Thanks very much for updating this!
> >>
> > Packages, logs:
> > - https://github.com/cygwin/scallywag/actions/runs/4743191979
>
>
> all yours
>
> Are you planning to adopt also the ruby-* sub-packages ?
>
> Regards
> Marco
> >>>
> >>> I have a concern about how this changes a soversioned dll inside the
> >>> package (from cygruby260.dll to cygruby320.dll)
> >>>
> >>> I don't know if there's anything linked against this DLL (perhaps ruby
> >>> bindings provided by other packages) which will get broken?
> >>>
> >>> Please hold off on uploading this until I have a chance to look into
> >>> that issue a bit more.
> >> It seems we have a handful of ruby binding packages, which install a .so
> >> file into /usr/lib/ruby/vendor_ruby/2.6/ which is linked against
> >> cygruby260.dll:
> >>
> >> ruby-gv
> >> ruby-marisa
> >> ruby-openbabel
> >> ruby-openwsman
> >> ruby-solv
> >> ruby-xapian
> >> ruby-zinnia
> >> subversion-ruby
>
> ruby-caca also belongs on this list, but the ruby binding hasn't been
> rebuilt since ruby 2.3.0
>
> Additionally, there are some packages which install a .so into
> /usr/lib/gems/ruby/2.6/, which probably need similar treatment?
>
> >> (There might also be some other packages which link with that dll to
> >> embed the ruby interpreter or something, but those are harder for me to
> >> identify quickly...)
> >>
> >> I think this can be handled in the same way as perl, i.e. add something
> >> like "ruby_PROVIDES=ruby_${${VERSION%.*}//./}" to ruby.cygport, and add
> >> a mechanism to cygport to make the binding packages have an additional
> >> dependency on that provide.
> >>
> >> I'll look into retroactively adding this to the existing ruby 2.6.x
> >> packages, to
Re: [ITA] ruby 3.2.2
On 21/04/2023 20:36, Daisuke Fujimura via Cygwin-apps wrote:
Thank you for your review.
Based on your review, I understand that the following steps are necessary.
Could you please let me know if it is correct?
1. Release `ruby-2.6.4-2`.
- Add `ruby_PROVIDES="ruby_${${VERSION%.*}//./}"` to ruby.cygport.
- The value of this variable will be `ruby_26`.
- `provides: ruby_26` is added to `ruby-2.6.4-2.hint`.
This isn't needed. I've retroactively modified the existing 2.6.4-1 and
2.6.3-1 packages to have this provide.
2. Modify cygport and release it.
- Add code to detect dependencies on `ruby_xy`.
- It is similar to the process for `perl5_xy0`.
-
https://github.com/cygwin/cygport/blob/0.36.2/lib/pkg_info.cygpart#L442
-
https://github.com/cygwin/cygport/blob/0.36.2/lib/pkg_info.cygpart#L639
Yes.
I'm not asking you to do this work though, unless you really feel like it :)
3. Rebuild `ruby-*` subpackages.
Again, this isn't needed as I can retroactively modify existing packages.
- The new cygport adds `depends: ruby_26` to the hint.
I've retroactively added this to the packages listed below, which
install into /usr/lib/ruby/vendor_ruby/2.6/ a .so linked to cygruby260.dll:
- (Question) Does a gem that has no dependencies on `cygruby*.dll`
need to rebuild?
I don't really know enough about ruby to answer that question, but
I don't think so.
4. Release `ruby-3.2.2-1`.
- The value of `provides` becomes `ruby_32`.
- Packages that depend on `ruby_26` will no longer be installable.
5. Rebuild `ruby-*` subpackages.
- The rebuild adds `depends: ruby_32` to the hint.
Yes.
The idea is that this will ensures that packages which are installed
together will work together, going forwards.
On Fri, Apr 21, 2023 at 1:13 AM Jon Turney wrote:
On 20/04/2023 11:50, Jon Turney via Cygwin-apps wrote:
On 20/04/2023 04:28, Marco Atzeri via Cygwin-apps wrote:
On 20.04.2023 00:42, Daisuke Fujimura via Cygwin-apps wrote:
Hello,
Cygportfile:
-
https://cygwin.com/git-cygwin-packages/?p=git/cygwin-packages/playground.git;a=shortlog;h=refs/heads/ruby
Looks fine. Thanks very much for updating this!
Packages, logs:
- https://github.com/cygwin/scallywag/actions/runs/4743191979
all yours
Are you planning to adopt also the ruby-* sub-packages ?
Regards
Marco
I have a concern about how this changes a soversioned dll inside the
package (from cygruby260.dll to cygruby320.dll)
I don't know if there's anything linked against this DLL (perhaps ruby
bindings provided by other packages) which will get broken?
Please hold off on uploading this until I have a chance to look into
that issue a bit more.
It seems we have a handful of ruby binding packages, which install a .so
file into /usr/lib/ruby/vendor_ruby/2.6/ which is linked against
cygruby260.dll:
ruby-gv
ruby-marisa
ruby-openbabel
ruby-openwsman
ruby-solv
ruby-xapian
ruby-zinnia
subversion-ruby
ruby-caca also belongs on this list, but the ruby binding hasn't been
rebuilt since ruby 2.3.0
Additionally, there are some packages which install a .so into
/usr/lib/gems/ruby/2.6/, which probably need similar treatment?
(There might also be some other packages which link with that dll to
embed the ruby interpreter or something, but those are harder for me to
identify quickly...)
I think this can be handled in the same way as perl, i.e. add something
like "ruby_PROVIDES=ruby_${${VERSION%.*}//./}" to ruby.cygport, and add
a mechanism to cygport to make the binding packages have an additional
dependency on that provide.
I'll look into retroactively adding this to the existing ruby 2.6.x
packages, to prevent non-working combinations of packages getting installed.
Re: [ITA] ruby 3.2.2
Thank you for your review.
Based on your review, I understand that the following steps are necessary.
Could you please let me know if it is correct?
1. Release `ruby-2.6.4-2`.
- Add `ruby_PROVIDES="ruby_${${VERSION%.*}//./}"` to ruby.cygport.
- The value of this variable will be `ruby_26`.
- `provides: ruby_26` is added to `ruby-2.6.4-2.hint`.
2. Modify cygport and release it.
- Add code to detect dependencies on `ruby_xy`.
- It is similar to the process for `perl5_xy0`.
-
https://github.com/cygwin/cygport/blob/0.36.2/lib/pkg_info.cygpart#L442
-
https://github.com/cygwin/cygport/blob/0.36.2/lib/pkg_info.cygpart#L639
3. Rebuild `ruby-*` subpackages.
- The new cygport adds `depends: ruby_26` to the hint.
- (Question) Does a gem that has no dependencies on `cygruby*.dll`
need to rebuild?
4. Release `ruby-3.2.2-1`.
- The value of `provides` becomes `ruby_32`.
- Packages that depend on `ruby_26` will no longer be installable.
5. Rebuild `ruby-*` subpackages.
- The rebuild adds `depends: ruby_32` to the hint.
On Fri, Apr 21, 2023 at 1:13 AM Jon Turney wrote:
>
> On 20/04/2023 11:50, Jon Turney via Cygwin-apps wrote:
> > On 20/04/2023 04:28, Marco Atzeri via Cygwin-apps wrote:
> >> On 20.04.2023 00:42, Daisuke Fujimura via Cygwin-apps wrote:
> >>> Hello,
> >>>
> >>>
> >>>
> >>> Cygportfile:
> >>> -
> >>> https://cygwin.com/git-cygwin-packages/?p=git/cygwin-packages/playground.git;a=shortlog;h=refs/heads/ruby
> >>>
>
> Looks fine. Thanks very much for updating this!
>
> >>> Packages, logs:
> >>> - https://github.com/cygwin/scallywag/actions/runs/4743191979
> >>
> >>
> >> all yours
> >>
> >> Are you planning to adopt also the ruby-* sub-packages ?
> >>
> >> Regards
> >> Marco
> >
> > I have a concern about how this changes a soversioned dll inside the
> > package (from cygruby260.dll to cygruby320.dll)
> >
> > I don't know if there's anything linked against this DLL (perhaps ruby
> > bindings provided by other packages) which will get broken?
> >
> > Please hold off on uploading this until I have a chance to look into
> > that issue a bit more.
> It seems we have a handful of ruby binding packages, which install a .so
> file into /usr/lib/ruby/vendor_ruby/2.6/ which is linked against
> cygruby260.dll:
>
> ruby-gv
> ruby-marisa
> ruby-openbabel
> ruby-openwsman
> ruby-solv
> ruby-xapian
> ruby-zinnia
> subversion-ruby
>
> (There might also be some other packages which link with that dll to
> embed the ruby interpreter or something, but those are harder for me to
> identify quickly...)
>
> I think this can be handled in the same way as perl, i.e. add something
> like "ruby_PROVIDES=ruby_${${VERSION%.*}//./}" to ruby.cygport, and add
> a mechanism to cygport to make the binding packages have an additional
> dependency on that provide.
>
> I'll look into retroactively adding this to the existing ruby 2.6.x
> packages, to prevent non-working combinations of packages getting installed.
>
Re: [ITA] ruby 3.2.2
On 20/04/2023 11:50, Jon Turney via Cygwin-apps wrote:
On 20/04/2023 04:28, Marco Atzeri via Cygwin-apps wrote:
On 20.04.2023 00:42, Daisuke Fujimura via Cygwin-apps wrote:
Hello,
Cygportfile:
-
https://cygwin.com/git-cygwin-packages/?p=git/cygwin-packages/playground.git;a=shortlog;h=refs/heads/ruby
Looks fine. Thanks very much for updating this!
Packages, logs:
- https://github.com/cygwin/scallywag/actions/runs/4743191979
all yours
Are you planning to adopt also the ruby-* sub-packages ?
Regards
Marco
I have a concern about how this changes a soversioned dll inside the
package (from cygruby260.dll to cygruby320.dll)
I don't know if there's anything linked against this DLL (perhaps ruby
bindings provided by other packages) which will get broken?
Please hold off on uploading this until I have a chance to look into
that issue a bit more.
It seems we have a handful of ruby binding packages, which install a .so
file into /usr/lib/ruby/vendor_ruby/2.6/ which is linked against
cygruby260.dll:
ruby-gv
ruby-marisa
ruby-openbabel
ruby-openwsman
ruby-solv
ruby-xapian
ruby-zinnia
subversion-ruby
(There might also be some other packages which link with that dll to
embed the ruby interpreter or something, but those are harder for me to
identify quickly...)
I think this can be handled in the same way as perl, i.e. add something
like "ruby_PROVIDES=ruby_${${VERSION%.*}//./}" to ruby.cygport, and add
a mechanism to cygport to make the binding packages have an additional
dependency on that provide.
I'll look into retroactively adding this to the existing ruby 2.6.x
packages, to prevent non-working combinations of packages getting installed.
Re: [ITA] ruby 3.2.2
On 20/04/2023 04:28, Marco Atzeri via Cygwin-apps wrote: On 20.04.2023 00:42, Daisuke Fujimura via Cygwin-apps wrote: Hello, Cygportfile: - https://cygwin.com/git-cygwin-packages/?p=git/cygwin-packages/playground.git;a=shortlog;h=refs/heads/ruby Packages, logs: - https://github.com/cygwin/scallywag/actions/runs/4743191979 all yours Are you planning to adopt also the ruby-* sub-packages ? Regards Marco I have a concern about how this changes a soversioned dll inside the package (from cygruby260.dll to cygruby320.dll) I don't know if there's anything linked against this DLL (perhaps ruby bindings provided by other packages) which will get broken? Please hold off on uploading this until I have a chance to look into that issue a bit more.
Re: [ITA] ruby 3.2.2
On 20.04.2023 00:42, Daisuke Fujimura via Cygwin-apps wrote: Hello, Cygportfile: - https://cygwin.com/git-cygwin-packages/?p=git/cygwin-packages/playground.git;a=shortlog;h=refs/heads/ruby Packages, logs: - https://github.com/cygwin/scallywag/actions/runs/4743191979 all yours Are you planning to adopt also the ruby-* sub-packages ? Regards Marco
