Re: Ruby 3.2
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)? Short answer is no. Honestly, I don't trust Ruby upstream they will keep their ABI stable enough and I have never tried to ask what is their stance here. From my POV, with exception of the final release date, the development always appeared quite random. I remember several years the huge changes in their configuration scripts done just during the December, few days/week prior the release (which of course says nothing about ABI stability ...) The reason I am asking here is that: * As I wrote above, ruby3.2 is to be released on 2022/12/25 (perhaps), usually we wait for this, and actually ruby mass rebuild usually begins around 2nd week of January? Then mass rebuild for whole Fedora packages (for F38) begins at 2023-01-18, so (as usual) the timing is very tight. Oh, I have not checked the dates. This comes earlier and earlier :/ If it was even earlier, we could do our rebuild afterwards ;) I could ask Ben, what are his thoughts and why there are 3 weeks for mass rebuild followed with branching right away. * Now rpm supports tilde, tilde is regarded as older than non-tilde version. So we can use, say, ruby-3.2.0~preview2-170.20221021gitabcdefg.fc38, for example, without "resetting" release number to 0.1.. Then we can set the release number of subpackages (such as rubygem-io-console) to (0.5.12-)170.gitabcdefg.fc38, so now we don't have to fight with release number, just we have to keep increasing this. The release number was never priority for my local experiments. But the tilde is probably something to consider. Not sure what impact it will have on the work with the archive name etc. But it could help with the Copr rebuilds and what not. Thx for pointing this out. I'll try to take 2nd look. Vít * And perhaps on 2022/11/E, I guess ruby3.2 would almost stable. Regards, Mamoru ___ ruby-sig mailing list -- ruby-sig@lists.fedoraproject.org To unsubscribe send an email to ruby-sig-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/ruby-sig@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue OpenPGP_signature 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.2
Vít Ondruch wrote on 2022/10/17 23:24: Hi again, Here is yet another version from Friday: https://koji.fedoraproject.org/koji/taskinfo?taskID=92978738 Nothing really special from Ruby POV, but I have enabled out-of-source build, as was previously discussed here: https://src.fedoraproject.org/rpms/ruby/pull-request/120 https://src.fedoraproject.org/rpms/ruby/pull-request/122 So while this should not have any influence on resulting package, it might come handy when somebody wants to clean the source tree and play with e.g. different configuration options or what not. Vít Thank you. By the way, do you have some plan to bring ruby 3.2 development rpm to f38 buildroot earlier than 2022 Christmas (say, around 2022/11/E)? The reason I am asking here is that: * As I wrote above, ruby3.2 is to be released on 2022/12/25 (perhaps), usually we wait for this, and actually ruby mass rebuild usually begins around 2nd week of January? Then mass rebuild for whole Fedora packages (for F38) begins at 2023-01-18, so (as usual) the timing is very tight. * Now rpm supports tilde, tilde is regarded as older than non-tilde version. So we can use, say, ruby-3.2.0~preview2-170.20221021gitabcdefg.fc38, for example, without "resetting" release number to 0.1.. Then we can set the release number of subpackages (such as rubygem-io-console) to (0.5.12-)170.gitabcdefg.fc38, so now we don't have to fight with release number, just we have to keep increasing this. * And perhaps on 2022/11/E, I guess ruby3.2 would almost stable. Regards, Mamoru ___ ruby-sig mailing list -- ruby-sig@lists.fedoraproject.org To unsubscribe send an email to ruby-sig-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/ruby-sig@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
Re: Packaging Ruby gem documentation
And just another anecdote, the hardlinks are there per my request:
https://github.com/ruby/rdoc/issues/186
The only issue is that they probably have almost 0 effect, since to be
effective, the owner of the original file have to be the same as the
owner of the target file. In our case, the origin is typically owned by
"root", while the build system is using the "mockbuild" user. The
hardlinks can't work even for user installed gem. The only case when
they works is when RDoc is installed via `gem install` as well as the
other gems (OTOH, this is always the case for people compiling their own
Rubies).
Not sure if I should propose to use just plain old copy instead 樂
Vít
Dne 21. 10. 22 v 12:08 Vít Ondruch napsal(a):
Just playing with this, the funny thing is that RDoc does not copy the
template, but they use hardlinks:
https://github.com/ruby/rdoc/blob/master/lib/rdoc/generator/darkfish.rb#L591
I guess that RPM can't preserve them.
Vít
Dne 20. 07. 22 v 12:28 Vít Ondruch napsal(a):
Just a few notes from the limited time I spend trying to understand
the approach.
1) The template can't be subpackage of the rubygem-rdoc. It needs to
live in completely separate project to enable us to decouple RDoc
updates from the template updates.
2) You are using the `--format darkfish`, but wouldn't it be better
to use `--template=NAME` instead?
3) I don't think we necessarily need to use the `%{_webassetdir}` or
`%{_jsdir}` dirs. OTOH, the template is using jQuery, which resides
in the `%{_jsdir}`, isn't it? But I can't see any reference to jQuery.
4) I would not mind to keep the original template including the
bundled fonts around. The original functionality including usage of
the original template for generating the documentation should be
completely preserved.
5) There is too much changes into the RDoc. If possible, I think it
would be better to keep the RDoc in its pristine form. I'd rather
seems some RPM macro to do some replacements if needed. But I still
think that if the template was done smart and it would e.g. already
contained symlinks, so copying of files would be in reality copying
of symlinks, that could save us from the modifications. IOW my naive
idea is:
/some/path/to/our/template/ - This patch contains our version of
Darkfish
/some/path/to/template/which/contains/just/symlinks/to/template/ - As
the path says, this on the first look appears to be the template, but
in reality these are just symlinks.
$ rdoc
--template=/some/path/to/template/which/contains/just/symlinks/to/template/
And the end result should be:
~~~
/usr/share/gems/doc/rdoc-6.3.2/rdoc/js/darkfish.js ->
/some/path/to/our/template/js/darkfish.js
~~~
But this might not be realistic at all
Vít
Dne 04. 07. 22 v 21:23 Jarek Prokop napsal(a):
Hi all,
I did some initial work in unbundling the static files and adjusting
the darkfish template that we can then copy out and use for
generating Fedora's HTML documentation.
For this I used rubygem-rdoc and rdoc v6.4.0 for protyping.
You can check the spec at:
https://src.fedoraproject.org/fork/jackorp/rpms/rubygem-rdoc/tree/dedup_static_files
And the RDoc sources at:
https://github.com/jackorp/rdoc/tree/fedora_doc_template
To build the RDoc ruby package, you need to build the gem from my
RDoc fork's branch (which is based on RDoc tag v6.4.0).
To test it, pick any project that makes use of Darkfish for
documentation and run `RPMBUILD=TRUE rdoc --format darkfish` in the
project's directory.
Note that the `RPMBUILD` env variable has to be non empty to force
symlinking, this is a WIP feature to allow for comparing results.
I used the symlink approach, but it has a few shortcomings, that
need to be worked around (That is WIP see specfile comment [0]).
I was able to get the docs to load properly, though, the search
index generation is broken due to the symlink.
If you are interested in more details of the implementation, scroll
down for a more detailed explanation.
Also, If you have any notes regarding my approach, feel free to
reach out and we can discuss.
JFTR, for now I have disabled the test suite as moving the files
breaks it.
Copying the static files to proper directories and then removing
them would be better in general,
but I use this approach for now to ensure I don't have some files in
improper locations, during the development of the custom template,
which could hide some bugs.
Regards,
Jarek
[0]
https://src.fedoraproject.org/fork/jackorp/rpms/rubygem-rdoc/blob/dedup_static_files/f/rubygem-rdoc.spec#_109
PS:
Implementation:
Package:
All static files were moved to rubygem-rdoc-darkfish-static, which
has more dependencies, such as the replaced fonts and the web assets
filesystem.
The %{_jsdir} and %{_webassetdir} are used to comply with Fedora
Packaging guidelines [1] [2] which seem relevant to this case.
Fonts.
To unbundle fonts, I removed them completely. Browsers can load
Re: Packaging Ruby gem documentation
Just playing with this, the funny thing is that RDoc does not copy the
template, but they use hardlinks:
https://github.com/ruby/rdoc/blob/master/lib/rdoc/generator/darkfish.rb#L591
I guess that RPM can't preserve them.
Vít
Dne 20. 07. 22 v 12:28 Vít Ondruch napsal(a):
Just a few notes from the limited time I spend trying to understand
the approach.
1) The template can't be subpackage of the rubygem-rdoc. It needs to
live in completely separate project to enable us to decouple RDoc
updates from the template updates.
2) You are using the `--format darkfish`, but wouldn't it be better to
use `--template=NAME` instead?
3) I don't think we necessarily need to use the `%{_webassetdir}` or
`%{_jsdir}` dirs. OTOH, the template is using jQuery, which resides in
the `%{_jsdir}`, isn't it? But I can't see any reference to jQuery.
4) I would not mind to keep the original template including the
bundled fonts around. The original functionality including usage of
the original template for generating the documentation should be
completely preserved.
5) There is too much changes into the RDoc. If possible, I think it
would be better to keep the RDoc in its pristine form. I'd rather
seems some RPM macro to do some replacements if needed. But I still
think that if the template was done smart and it would e.g. already
contained symlinks, so copying of files would be in reality copying of
symlinks, that could save us from the modifications. IOW my naive idea
is:
/some/path/to/our/template/ - This patch contains our version of Darkfish
/some/path/to/template/which/contains/just/symlinks/to/template/ - As
the path says, this on the first look appears to be the template, but
in reality these are just symlinks.
$ rdoc
--template=/some/path/to/template/which/contains/just/symlinks/to/template/
And the end result should be:
~~~
/usr/share/gems/doc/rdoc-6.3.2/rdoc/js/darkfish.js ->
/some/path/to/our/template/js/darkfish.js
~~~
But this might not be realistic at all
Vít
Dne 04. 07. 22 v 21:23 Jarek Prokop napsal(a):
Hi all,
I did some initial work in unbundling the static files and adjusting
the darkfish template that we can then copy out and use for
generating Fedora's HTML documentation.
For this I used rubygem-rdoc and rdoc v6.4.0 for protyping.
You can check the spec at:
https://src.fedoraproject.org/fork/jackorp/rpms/rubygem-rdoc/tree/dedup_static_files
And the RDoc sources at:
https://github.com/jackorp/rdoc/tree/fedora_doc_template
To build the RDoc ruby package, you need to build the gem from my
RDoc fork's branch (which is based on RDoc tag v6.4.0).
To test it, pick any project that makes use of Darkfish for
documentation and run `RPMBUILD=TRUE rdoc --format darkfish` in the
project's directory.
Note that the `RPMBUILD` env variable has to be non empty to force
symlinking, this is a WIP feature to allow for comparing results.
I used the symlink approach, but it has a few shortcomings, that need
to be worked around (That is WIP see specfile comment [0]).
I was able to get the docs to load properly, though, the search index
generation is broken due to the symlink.
If you are interested in more details of the implementation, scroll
down for a more detailed explanation.
Also, If you have any notes regarding my approach, feel free to reach
out and we can discuss.
JFTR, for now I have disabled the test suite as moving the files
breaks it.
Copying the static files to proper directories and then removing them
would be better in general,
but I use this approach for now to ensure I don't have some files in
improper locations, during the development of the custom template,
which could hide some bugs.
Regards,
Jarek
[0]
https://src.fedoraproject.org/fork/jackorp/rpms/rubygem-rdoc/blob/dedup_static_files/f/rubygem-rdoc.spec#_109
PS:
Implementation:
Package:
All static files were moved to rubygem-rdoc-darkfish-static, which
has more dependencies, such as the replaced fonts and the web assets
filesystem.
The %{_jsdir} and %{_webassetdir} are used to comply with Fedora
Packaging guidelines [1] [2] which seem relevant to this case.
Fonts.
To unbundle fonts, I removed them completely. Browsers can load
them if they are present on other system paths (which is taken care
of by the `Requires:`).
However, this approach has a shortcoming. If a user generates
documentation using system RDoc, then fonts will be missing from the
result directory.
I'll need to take a closer look to see how to solve this.
Images and CSS stylesheets:
These are moved to %{_webassetdir} and symlinked to the result
folder with generated documentation.
Javascript:
This is more complicated, since RDoc uses gzip compression. We know
it is going to do that, so it is done ahead of time and the gzip
files are added to gemspec.
Everything is then moved to proper directories to be symlinked later.
RDoc template:
Nothing too complicated. The
