I am back with some updates. You can see the latest version here:
https://fedorapeople.org/cgit/vondruch/public_git/darkfish.git/
and I have also prepared Copr build:
https://copr.fedorainfracloud.org/coprs/vondruch/darkfish/
I have incorporated most of the feedback, except the %check section
On 11/24/22 14:20, Vít Ondruch wrote:
Dne 24. 11. 22 v 13:12 Jarek Prokop napsal(a):
nit regarding the spec license, "GPL-2.0" is not valid SPDX
(according to license-validate at least), however, there is
"GPL-2.0-only" or "GPL-2.0-or-later".
I think that it used to be valid identifier at
Dne 24. 11. 22 v 13:12 Jarek Prokop napsal(a):
Hi,
looks great :), I'll comment more inline.
nit regarding the spec license, "GPL-2.0" is not valid SPDX (according
to license-validate at least), however, there is "GPL-2.0-only" or
"GPL-2.0-or-later".
I think that it used to be valid ide
Hi,
looks great :), I'll comment more inline.
nit regarding the spec license, "GPL-2.0" is not valid SPDX (according
to license-validate at least), however, there is "GPL-2.0-only" or
"GPL-2.0-or-later".
I am maybe coming too soon with this comment, but since we are also on
the SPDX topic in
Building upon this, here is another attempt:
https://fedorapeople.org/cgit/vondruch/public_git/darkfish.git/commit/?h=rawhide&id=487234ef5f64f78291ce767a8a989649ee941c73
https://koji.fedoraproject.org/koji/taskinfo?taskID=94460961
While I have reverted back to non gem approach, the RubyGems pl
Dne 22. 11. 22 v 9:21 Benson Muite napsal(a):
On 11/1/22 20:53, Vít Ondruch wrote:
Dne 26. 10. 22 v 17:32 Vít Ondruch napsal(a):
We could also try to somehow modify the Gem.done_installing hooks
and remove the RDoc hook and replace it with ours.
Building upon this idea, I am attaching an p
On 11/1/22 20:53, Vít Ondruch wrote:
Dne 26. 10. 22 v 17:32 Vít Ondruch napsal(a):
We could also try to somehow modify the Gem.done_installing hooks and
remove the RDoc hook and replace it with ours.
Building upon this idea, I am attaching an proof of concept. This loads
the original RubyGe
Dne 26. 10. 22 v 17:32 Vít Ondruch napsal(a):
We could also try to somehow modify the Gem.done_installing hooks and
remove the RDoc hook and replace it with ours.
Building upon this idea, I am attaching an proof of concept. This loads
the original RubyGems RDoc hook, removes it an replaces b
a) Fonts can be symlinked, there are 652K for each install.
In theory, this should not be needed if the fonts are installed into
system location. In that case, browser should be able to pick them up.
This just needs minor .css modification IMHO. However, I am not CSS
expert. But I am quit
Dne 01. 11. 22 v 5:51 Benson Muite napsal(a):
On 10/26/22 18:32, Vít Ondruch wrote:
Dne 26. 10. 22 v 16:50 Vít Ondruch napsal(a):
Dne 26. 10. 22 v 11:59 Jarek Prokop napsal(a):
I am afraid we won't dodge monkey patching here due to the lack of
parametrization of the documentation generator
On 10/26/22 18:32, Vít Ondruch wrote:
Dne 26. 10. 22 v 16:50 Vít Ondruch napsal(a):
Dne 26. 10. 22 v 11:59 Jarek Prokop napsal(a):
I am afraid we won't dodge monkey patching here due to the lack of
parametrization of the documentation generator options.
I will need to experiment with this
Dne 26. 10. 22 v 16:50 Vít Ondruch napsal(a):
Dne 26. 10. 22 v 11:59 Jarek Prokop napsal(a):
I am afraid we won't dodge monkey patching here due to the lack of
parametrization of the documentation generator options.
I will need to experiment with this idea a bit.
One option to avoid th
Dne 26. 10. 22 v 11:59 Jarek Prokop napsal(a):
Hi,
Sub-clasing is interesting idea. But that would mean we needed to
provide our own generator.
I am working on a kind of a prototype on this.
Sources with specfile are available here:
https://fedorapeople.org/cgit/jackorp/public_git/fedor
Hi,
Sub-clasing is interesting idea. But that would mean we needed to
provide our own generator.
I am working on a kind of a prototype on this.
Sources with specfile are available here:
https://fedorapeople.org/cgit/jackorp/public_git/fedora_darkfish.git/
I also created copr repo that con
On 10/25/22 14:46, Vít Ondruch wrote:
Dne 25. 10. 22 v 13:12 Jarek Prokop napsal(a):
The other subthread with Jarek reminded me that one of the options
could be to extract/fork the whole Darkfish generator instead of
monkey patching. But Darkfish is pretty complex. We would probably
not
Dne 25. 10. 22 v 13:12 Jarek Prokop napsal(a):
The other subthread with Jarek reminded me that one of the options
could be to extract/fork the whole Darkfish generator instead of
monkey patching. But Darkfish is pretty complex. We would probably
not avoided any issues.
Maybe it would be
Hi,
I took a different approach using Vít's script as a base.
the -T could be specified in code, that is subject for more refinement
in the next iteration.
Also, it seems the fonts are symlinked, a `.reject` on the right place
might help with that.
~~~
[vagrant@fedora test]$ cat ./hello.r
The other subthread with Jarek reminded me that one of the options
could be to extract/fork the whole Darkfish generator instead of
monkey patching. But Darkfish is pretty complex. We would probably not
avoided any issues.
Maybe it would be possible to just provide the subclass of Darkfish
Dne 24. 10. 22 v 18:00 Jarek Prokop napsal(a):
Hi,
On 7/20/22 12:28, Vít Ondruch wrote:
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
On 10/24/22 17:42, Vít Ondruch wrote:
So here is my proof of concept:
https://fedorapeople.org/cgit/vondruch/public_git/darkfish.git/
https://koji.fedoraproject.org/koji/taskinfo?taskID=93399794
It can be executed as follows:
<...snip...>
And now a few remarks and questions:
1) I hoped
Dne 24. 10. 22 v 17:42 Vít Ondruch napsal(a):
So here is my proof of concept:
https://fedorapeople.org/cgit/vondruch/public_git/darkfish.git/
https://koji.fedoraproject.org/koji/taskinfo?taskID=93399794
It can be executed as follows:
~~~
$ RUBYOPT="-I/usr/share/darkfish-rdoc/ -rfedora_dar
Hi,
On 7/20/22 12:28, Vít Ondruch wrote:
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.
So here is my proof of concept:
https://fedorapeople.org/cgit/vondruch/public_git/darkfish.git/
https://koji.fedoraproject.org/koji/taskinfo?taskID=93399794
It can be executed as follows:
~~~
$ RUBYOPT="-I/usr/share/darkfish-rdoc/ -rfedora_darkfish" gem install
gem2rpm --doc=ri,rdoc
Fetch
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 orig
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 fro
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`
Copying the static files to proper directories and then removing them
would be better in general,
s/removing/symlinking/
___
ruby-sig mailing list -- ruby-sig@lists.fedoraproject.org
To unsubscribe send an email to ruby-sig-le...@lists.fedoraproject.o
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.o
On 6/28/22 09:54, Vít Ondruch wrote:
Dne 27. 06. 22 v 19:51 Jarek Prokop napsal(a):
Hi,
since it came up in the package review I took a closer look on the
state and possibilities.
On 6/27/22 17:47, Vít Ondruch wrote:
Dne 27. 06. 22 v 13:21 Benson Muite napsal(a):
Hi Pavel,
Thanks. Is i
Dne 27. 06. 22 v 19:51 Jarek Prokop napsal(a):
Hi,
since it came up in the package review I took a closer look on the
state and possibilities.
On 6/27/22 17:47, Vít Ondruch wrote:
Dne 27. 06. 22 v 13:21 Benson Muite napsal(a):
Hi Pavel,
Thanks. Is it also worth encouraging packaging of R
Hi,
since it came up in the package review I took a closer look on the state
and possibilities.
On 6/27/22 17:47, Vít Ondruch wrote:
Dne 27. 06. 22 v 13:21 Benson Muite napsal(a):
Hi Pavel,
Thanks. Is it also worth encouraging packaging of Ri documentation?
These are very comandline frien
Dne 27. 06. 22 v 13:21 Benson Muite napsal(a):
Hi Pavel,
Thanks. Is it also worth encouraging packaging of Ri documentation?
These are very comandline friendly, Javascript is not. In principle,
one might want to have HTML documentation as a separate package from
Ri documentation giving the
Hi Pavel,
Thanks. Is it also worth encouraging packaging of Ri documentation?
These are very comandline friendly, Javascript is not. In principle,
one might want to have HTML documentation as a separate package from Ri
documentation giving the end user a choice of what to install.
Will see
Hello Benson,
as of now, this hasn't been an issue and I think there's no obstacle with
using the javascript (the library has reported vulnerability AFAIR), but
it's not exploitable in the documentation so it's deemed safe (the library
should not be used for anything else).
The same goes for the
Hi,
Rdoc generated HTML often includes embedded fonts and javascript which
may be problematic to package. Might it be worth suggesting in the
packaging documentation[0] to only create Ri files which are accessible
on the command line? A related ticket that prompted this is [1].
Regards,
Bens
35 matches
Mail list logo