python-sphinx_rtd_theme update: comments requested

[Jerry James]

sphinx_rtd_theme 0.5.0 is out.  I have taken the unprecedented step
(for me!) of creating a pull request instead of just updating the
package, because I'm taking a few steps that I would like to have
other eyes on.  Pull request:

https://src.fedoraproject.org/rpms/python-sphinx_rtd_theme/pull-request/2

The first issue is that, with this release, upstream defaults to
building the Javascript and CSS files from source.  This is a laudable
move.  I'm glad upstream did that.  Unfortunately, the build process
requires quite a few things we don't have in Fedora right now, so I've
had to figure out how to subvert upstream's build system and use the
prebuilt bits instead.  I have neither the time nor the expertise to
add the missing bits to Fedora.  There are quite a lot of them.

The second issue is that the package has not been in compliance with
the recently revised font guidelines.  With this pull request, I am
attempting to bring this package into compliance.  This means no
longer using fonts in eot, svg, woff, or woff2 formats, but going with
straight ttf.  I'm worried about the impact this might have on
dependent packages.

Third, any package that includes documentation generated from this
package will need this:

Requires:       font(fontawesome)
Requires:       font(lato)
Requires:       font(robotoslab)

In addition, if that documentation is put anywhere that an old
Internet Explorer might see it, then this will also be needed:

Requires:  js-html5shiv

How should that information be conveyed to consumers?

Thank you for any help you can give me.  If you see something that
makes you wonder what I was thinking, that's probably an indication
that I don't know what I'm doing and you should tell me how to do it
the right way.  Regards,
-- 
Jerry James
http://www.jamezone.org/

[Miro Hrončok]

On 01. 07. 20 0:47, Jerry James wrote:
>  Third, any package that includes documentation generated from this
>  package will need this:
>  
>  Requires:       font(fontawesome)
>  Requires:       font(lato)
>  Requires:       font(robotoslab) 
Quick idea:

Package an RPM dependency generator into python3-sphinx_rtd_theme that matches 
*.css files and when it find the "sphinx_rtd_theme" comment in them, it adds the

requires. I can help with that.

If we want to get fancy, we can add a more general CSS-font requirements 
generator used for all packaged *.css files in Fedora, but frankly, I don't have 
the energy to spare for this.

-- 
Miro Hrončok
--
Phone: [phone]
IRC: mhroncok

[Miro Hrončok]

On 01. 07. 20 2:07, Miro Hrončok wrote:
>  On 01. 07. 20 0:47, Jerry James wrote:
> > Third, any package that includes documentation generated from this
> > package will need this:
> >
> > Requires:       font(fontawesome)
> > Requires:       font(lato)
> > Requires:       font(robotoslab)
>  
>  Quick idea:
>  
>  Package an RPM dependency generator into python3-sphinx_rtd_theme that matches 
>  *.css files and when it find the "sphinx_rtd_theme" comment in them, it adds
> the 
>  requires. I can help with that. 
I've worked on this in

https://src.fedoraproject.org/fork/churchyard/rpms/python-sphinx_rtd_them...

However, there is "tiny little problem" that makes it not work:

https://github.com/rpm-software-management/rpm/issues/1297

-- 
Miro Hrončok
--
Phone: [phone]
IRC: mhroncok

[Jerry James]

On Wed, Jul 1, 2020 at 5:21 AM Miro Hrončok <mhroncok(a)redhat.com&gt; wrote:
>  I've worked on this in
>
>
> https://src.fedoraproject.org/fork/churchyard/rpms/python-sphinx_rtd_them...
>
>  However, there is "tiny little problem" that makes it not work:
>
>  https://github.com/rpm-software-management/rpm/issues/1297 
Nice!  Thank you, Miro, I like what you've done.  I'll wait to see the
resolution of your "tiny little problem" before doing anything more.

Should the %{?python_provide...} line be removed?  It seems to be
redundant with the new python dependency generator.

I'm also thinking of purging all traces of html5shiv from the spec
file, and rewriting the reference to it in layout.html to something
like this:

  {# JAVASCRIPTS #}
  {%- block scripts %}
  <!--[if lt IE 9]>
    <script
src="https://cdnjs.cloudflare.com/ajax/libs/html5shiv/3.7.3/html5shi...
  <![endif]-->

What do you think?  Regards,
-- 
Jerry James
http://www.jamezone.org/

[Miro Hrončok]

On 01. 07. 20 17:37, Jerry James wrote:
>  On Wed, Jul 1, 2020 at 5:21 AM Miro Hrončok
> <mhroncok(a)redhat.com&gt; wrote:
> > I've worked on this in
> >
> >
> https://src.fedoraproject.org/fork/churchyard/rpms/python-sphinx_rtd_them...
> >
> > However, there is "tiny little problem" that makes it not work:
> >
> > https://github.com/rpm-software-management/rpm/issues/1297
>  
>  Nice!  Thank you, Miro, I like what you've done.  I'll wait to see the
>  resolution of your "tiny little problem" before doing anything more. 
Well I think that before this is resolved, we can only add the requirement 
manually to all the affected Fedora packages and check newly added packages 
regularly.

>  Should the %{?python_provide...} line be removed?  It seems to be
>  redundant with the new python dependency generator. 
Yes, if this will not be backported (I assume it won't, my generator for example 
only targets rawhide+).

>  I'm also thinking of purging all traces of html5shiv from the
> spec
>  file, and rewriting the reference to it in layout.html to something
>  like this:
>  
>     {# JAVASCRIPTS #}
>     {%- block scripts %}
>     <!--[if lt IE 9]>
>       <script
> src="https://cdnjs.cloudflare.com/ajax/libs/html5shiv/3.7.3/html5shi...
>     <![endif]-->
>  
>  What do you think? 
Given the /usr/share font links in CSS won't work when the documentation is 
exposed via a webserver, I assume the docs are mostly intended to be browsed 
(possibly offline) from within Fedora anyway. As such, I would be inclined to 
simply drop the html5shiv part entirely, rather than pointing to a code that's 
outside of Fedora's area of influence. Whoever wants to browse the docs online 
will do it on readthedocs anyway.

-- 
Miro Hrončok
--
Phone: [phone]
IRC: mhroncok

[Nicolas Mailhot]

Le mercredi 01 juillet 2020 à 18:35 +0200, Miro Hrončok a écrit :
>  
>  Given the /usr/share font links in CSS won't work when the
>  documentation is 
>  exposed via a webserver, I assume the docs are mostly intended to be
>  browsed 
>  (possibly offline) from within Fedora anyway.  
It’s not that hard to expose /usr/share/fonts in a webserver (and
pretty risk-free).

However old IE browsers are a plague security-wise, it’s much better to
remove IE workarounds than help users keep an insecure browser that
does not work all that well on free software webapps.

Also, making the browser walk a remote location is not good for
performance and will have all kind of interesting effects in restricted
networks

Regards,

-- 
Nicolas Mailhot

[Miro Hrončok]

On 01. 07. 20 19:34, Nicolas Mailhot via devel wrote:
>  Le mercredi 01 juillet 2020 à 18:35 +0200, Miro Hrončok a écrit :
> > Given the /usr/share font links in CSS won't work when the
> > documentation is
> > exposed via a webserver, I assume the docs are mostly intended to be
> > browsed
> > (possibly offline) from within Fedora anyway.
>  It’s not that hard to expose /usr/share/fonts in a webserver (and
>  pretty risk-free). 
Let's consider this scenario.

The documentation is exposed on 1.2.3.4:8000 from machine A.

On machine B, I open http://1.2.3.4:8000/ in my webbrowser.
The HTML is loaded, it contains a CSS file reference.
The CSS is loaded, it contains an /usr/share/... font link.

Now I don't know if having the font /usr/share/... font installed on machine B 
makes it work, but certainly, th font from machine A won't be served this way.



That makes me thing. Wouldn't it be better to reference the fonts by name 
instead of full path? That way, if the font is installed on machine B (not 
Fedora machine necessarily) in any way, it works.

-- 
Miro Hrončok
--
Phone: [phone]
IRC: mhroncok

[Nicolas Mailhot]

Le 2020-07-02 10:51, Miro Hrončok a écrit :
>  On 01. 07. 20 19:34, Nicolas Mailhot via devel wrote:
> > Le mercredi 01 juillet 2020 à 18:35 +0200, Miro Hrončok a écrit :
> >> Given the /usr/share font links in CSS won't work when the
> >> documentation is
> >> exposed via a webserver, I assume the docs are mostly intended to be
> >> browsed
> >> (possibly offline) from within Fedora anyway.
> > It’s not that hard to expose /usr/share/fonts in a webserver (and
> > pretty risk-free).
>  
>  Let's consider this scenario.
>  
>  The documentation is exposed on 1.2.3.4:8000 from machine A.
>  
>  On machine B, I open http://1.2.3.4:8000/ in my webbrowser.
>  The HTML is loaded, it contains a CSS file reference.
>  The CSS is loaded, it contains an /usr/share/... font link.
>  
>  Now I don't know if having the font /usr/share/... font installed on
>  machine B makes it work, but certainly, th font from machine A won't
>  be served this way. 
You’d need to declare the font files you want to serve as a relative 
path, in your CSS files, and that relative path matches the path your 
webserver serves /usr/share/fonts at.

Not sure it is worth the effort but is is certainly doable

Regards,

-- 
Nicolas Mailhot