[DOCS] sphinx: use new Sphinx links

Pushed.

---
 htdocs/about.html                  |  2 +-
 htdocs/bugs/index.html             |  4 ++--
 htdocs/faq.html                    |  6 +++---
 htdocs/news.html                   |  4 ++--
 htdocs/projects/beginner.html      |  8 ++++----
 htdocs/projects/documentation.html |  2 +-
 htdocs/projects/gomp/index.html    | 12 ++++++------
 htdocs/releases.html               |  2 +-
 htdocs/simtest-howto.html          |  2 +-
 htdocs/style.mhtml                 |  8 ++++----
 htdocs/testing/index.html          |  6 +++---
 11 files changed, 28 insertions(+), 28 deletions(-)

Gerald, can you please propagate changes I made to:
htdocs/style.mhtml file?

Thanks,
Martin

On 11/9/22 12:13, Martin Liška wrote:
> Pushed.
> 
> ---
>  htdocs/about.html                  |  2 +-
>  htdocs/bugs/index.html             |  4 ++--
>  htdocs/faq.html                    |  6 +++---
>  htdocs/news.html                   |  4 ++--
>  htdocs/projects/beginner.html      |  8 ++++----
>  htdocs/projects/documentation.html |  2 +-
>  htdocs/projects/gomp/index.html    | 12 ++++++------
>  htdocs/releases.html               |  2 +-
>  htdocs/simtest-howto.html          |  2 +-
>  htdocs/style.mhtml                 |  8 ++++----
>  htdocs/testing/index.html          |  6 +++---
>  11 files changed, 28 insertions(+), 28 deletions(-)
> 
> diff --git a/htdocs/about.html b/htdocs/about.html
> index 7278cae6..92e88ad0 100644
> --- a/htdocs/about.html
> +++ b/htdocs/about.html
> @@ -17,7 +17,7 @@
>  <p>The web effort was originally led by Jeff Law.  For the last two
>  decades or so Gerald Pfeifer has been leading the effort, but there are
>  many
> -<a href="https://gcc.gnu.org/onlinedocs/gcc/Contributors.html">contributors
> +<a href="https://gcc.gnu.org/onlinedocs/gcc/contributors-to-gcc.html">contributors
>  </a>.</p>
>  
>  <p>The web pages are under <a href="#git">git control</a>.
> diff --git a/htdocs/bugs/index.html b/htdocs/bugs/index.html
> index aaef8915..9b53512b 100644
> --- a/htdocs/bugs/index.html
> +++ b/htdocs/bugs/index.html
> @@ -673,7 +673,7 @@ errors or malfunctioning programs.
>  It should not be necessary to recompile if you have changed
>  to a bug-fix release of the same version of the compiler; bug-fix
>  releases are careful to avoid ABI changes. See also the
> -<a href="https://gcc.gnu.org/onlinedocs/gcc/Compatibility.html">compatibility
> +<a href="https://gcc.gnu.org/onlinedocs/gcc/binary-compatibility.html">compatibility
>  section</a> of the GCC manual.</p>
>  
>  <h4>Standard conformance</h4>
> @@ -689,7 +689,7 @@ However, some non-conforming constructs are allowed when the command-line
>  option <code>-fpermissive</code> is used.</p>
>  
>  <p>The manual contains a section on
> -<a href="https://gcc.gnu.org/onlinedocs/gcc/C_002b_002b-Misunderstandings.html">
> +<a href="https://gcc.gnu.org/onlinedocs/gcc/known-causes-of-trouble-with-gcc/common-misunderstandings-with-gnu-c.html">
>  Common Misunderstandings with GNU C++</a>.</p>
>  
>  </body>
> diff --git a/htdocs/faq.html b/htdocs/faq.html
> index b09e3920..0556b737 100644
> --- a/htdocs/faq.html
> +++ b/htdocs/faq.html
> @@ -97,7 +97,7 @@ disadvantages.</p>
>  <p>The host/target specific installation notes for GCC include information
>  about known problems with installing or using GCC on particular platforms.
>  These are included in the sources for a release in INSTALL/specific.html,
> -and the <a href="https://gcc.gnu.org/install/specific.html">latest version</a>
> +and the <a href="https://gcc.gnu.org/onlinedocs/install//host-target-specific-installation-notes-for-gcc.html">latest version</a>
>  is always available at the GCC web site.
>  Reports of <a href="buildstat.html">successful builds</a>
>  for several versions of GCC are also available at the web site.</p>
> @@ -210,7 +210,7 @@ may have to take one of the following actions to arrange that GCC uses
>  the GNU versions of those programs.</p>
>  
>  <p>To ensure that GCC finds the GNU assembler (the GNU linker), which
> -are required by <a href="https://gcc.gnu.org/install/specific.html">some
> +are required by <a href="https://gcc.gnu.org/onlinedocs/install/host-target-specific-installation-notes-for-gcc.html">some
>  configurations</a>,
>  you should configure these with the same --prefix option as you used
>  for GCC.  Then build &amp; install GNU as (GNU ld) and proceed with
> @@ -427,7 +427,7 @@ those generated files are out of date and try to regenerate them.</p>
>  transparently without requiring installation of any additional tools.</p>
>  
>  <p>If you modified some sources or when building from SVN you may also
> -need <a href="https://gcc.gnu.org/install/prerequisites.html#TOC1">some
> +need <a href="https://gcc.gnu.org/onlinedocs/install/install/prerequisites.html#tools-packages-necessary-for-modifying-gcc">some
>  additional tools</a>.</p>
>  
>  
> diff --git a/htdocs/news.html b/htdocs/news.html
> index e1384852..2b35dabc 100644
> --- a/htdocs/news.html
> +++ b/htdocs/news.html
> @@ -1020,7 +1020,7 @@ code now, and other ports will follow.
>  <dd>
>  Ben Elliston of Wasabi Systems, Inc. has converted the existing ARM
>  processor pipeline description to the new <a
> -href="https://gcc.gnu.org/onlinedocs/gccint/Processor-pipeline-description.html">DFA
> +href="https://gcc.gnu.org/onlinedocs/3.4.0/gccint/Processor-pipeline-description.html">DFA
>  pipeline description model</a>.
>  It will be part of the GCC 3.4.0 release.
>  </dd>
> @@ -1075,7 +1075,7 @@ fix release only.
>  <dd>
>  Geoffrey Keating of Apple Computer, Inc., with support from Red Hat,
>  Inc., has contributed a
> -<a href="https://gcc.gnu.org/onlinedocs/gcc/Precompiled-Headers.html#Precompiled%20Headers">
> +<a href="https://gcc.gnu.org/onlinedocs/3.4.0/gcc/Precompiled-Headers.html#Precompiled%20Headers">
>  precompiled header</a> implementation that can dramatically speed up
>  compilation of some projects.
>  </dd>
> diff --git a/htdocs/projects/beginner.html b/htdocs/projects/beginner.html
> index 0cefb562..0825b2c0 100644
> --- a/htdocs/projects/beginner.html
> +++ b/htdocs/projects/beginner.html
> @@ -31,10 +31,10 @@ suite.  You should also familiarize yourself with the
>  
>  <p>Many of these projects will require at least a reading knowledge of
>  GCC's intermediate language,
> -<a href="https://gcc.gnu.org/onlinedocs/gccint/RTL.html">RTL</a>.
> +<a href="https://gcc.gnu.org/onlinedocs/gccint/rtl-representation.html">RTL</a>.
>  It may help to understand the higher-level <code>tree</code> structure as
>  well.  Unfortunately, for this we only have an <a
> -href="https://gcc.gnu.org/onlinedocs/gccint/GENERIC.html">incomplete, C/C++ specific manual</a>.</p>
> +href="https://gcc.gnu.org/onlinedocs/gccint/generic.html">incomplete, C/C++ specific manual</a>.</p>
>  
>  <p>Remember to <a href="../contributewhy.html">keep other developers
>  informed</a> of any substantial projects you intend to work on.</p>
> @@ -428,8 +428,8 @@ There is also work to be done in cleaning up the places where the MI
>  code uses machine-specific macros.</p>
>  
>  <p>In addition to understanding RTL, you need to read the <a
> -href="https://gcc.gnu.org/onlinedocs/gccint/Machine-Desc.html">machine description</a> and <a
> -href="https://gcc.gnu.org/onlinedocs/gccint/Target-Macros.html">target macros</a> sections of the GCC
> +href="https://gcc.gnu.org/onlinedocs/gccint/machine-descriptions.html">machine description</a> and <a
> +href="https://gcc.gnu.org/onlinedocs/gccint/target-macros.html">target macros</a> sections of the GCC
>  manual.</p>
>  
>  <ul>
> diff --git a/htdocs/projects/documentation.html b/htdocs/projects/documentation.html
> index 00d9217b..daed9036 100644
> --- a/htdocs/projects/documentation.html
> +++ b/htdocs/projects/documentation.html
> @@ -58,7 +58,7 @@ a front end must or may provide.</p>
>  
>  <p>We've got quite a bit of this but it is scattered all over the
>  place.  It belongs in the official manual.  There is a <a
> -href="https://gcc.gnu.org/onlinedocs/gccint/GENERIC.html">C/C++ specific manual</a>,
> +href="https://gcc.gnu.org/onlinedocs/gccint/generic.html">C/C++ specific manual</a>,
>  which is incomplete, though.  The file
>  <code>gcc/LANGUAGES</code> contains incomplete and outdated information
>  about changes made in not so recent years to the <code>tree</code>
> diff --git a/htdocs/projects/gomp/index.html b/htdocs/projects/gomp/index.html
> index 053e0b7d..713a4e16 100644
> --- a/htdocs/projects/gomp/index.html
> +++ b/htdocs/projects/gomp/index.html
> @@ -36,21 +36,21 @@ OpenMP and OpenACC are supported with GCC's C, C++ and Fortran compilers.</p>
>  <ul>
>    <li>To enable <strong><a href="https://www.openmp.org">OpenMP</a></strong>,
>    use <a
> -  href="https://gcc.gnu.org/onlinedocs/gcc/C-Dialect-Options.html#index-fopenmp"
> +  href="https://gcc.gnu.org/onlinedocs/gcc/gcc-command-options/options-controlling-c-dialect.html#cmdoption-fopenmp"
>    ><code>-fopenmp</code></a>; <code>-fopenmp-simd</code> can be used
>    to enable only the SIMD vectorization and loop-transformation constructs
>    without creating multiple threads, offloading code or adding library
>    dependency.</li>
>    <li>To enable <strong><a href="https://www.openacc.org">OpenACC</a></strong>,
>    use <a
> -  href="https://gcc.gnu.org/onlinedocs/gcc/C-Dialect-Options.html#index-fopenacc"
> +  href="https://gcc.gnu.org/onlinedocs/gcc/gcc-command-options/options-controlling-c-dialect.html#cmdoption-fopenacc"
>    ><code>-fopenacc</code></a>.</li>
>    <li>If either is enabled, offloading is automatically generated for all
>    offload-device types for which the compiler has been configured. Use <a
> -  href="https://gcc.gnu.org/onlinedocs/gcc/C-Dialect-Options.html#index-foffload"
> +  href="https://gcc.gnu.org/onlinedocs/gcc/gcc-command-options/options-controlling-c-dialect.html#cmdoption-foffload"
>    ><code>-foffload=</code></a> to disable or specify the offload-devices to be
>    used. Use <a
> -  href="https://gcc.gnu.org/onlinedocs/gcc/C-Dialect-Options.html#index-foffload-options"
> +  href="https://gcc.gnu.org/onlinedocs/gcc/gcc-command-options/options-controlling-c-dialect.html#cmdoption-foffload-options"
>    ><code>-foffload-options=</code></a> to pass device-specific compiler and
>    linker flags.</li>
>  </ul>
> @@ -58,7 +58,7 @@ OpenMP and OpenACC are supported with GCC's C, C++ and Fortran compilers.</p>
>  <p>Diagnostics</p>
>  <ul>
>    <li>The <a
> -  href="https://gcc.gnu.org/onlinedocs/gcc/Developer-Options.html#index-fopt-info"
> +  href="https://gcc.gnu.org/onlinedocs/gcc/gcc-command-options/gcc-developer-options.html#cmdoption-fopt-info"
>    ><code>-fopt-info</code></a> flag provides details about compile-time performed
>    optimizations.</li>
>    <li>Environment variables can be used to influence run-time behavior and output
> @@ -141,7 +141,7 @@ filing a <a href="../../bugs/">bug report</a>.</p>
>  <h2 id="implementation-status">OpenMP Implementation Status</h2>
>  
>  <p>Implementation status in libgomp manual:
> -<a href="https://gcc.gnu.org/onlinedocs/libgomp/OpenMP-Implementation-Status.html"
> +<a href="https://gcc.gnu.org/onlinedocs/libgomp/openmp-implementation-status.html"
>  >Mainline (GCC 13)</a>,
>  <a href="https://gcc.gnu.org/onlinedocs/gcc-12.1.0/libgomp/OpenMP-Implementation-Status.html"
>  >GCC 12</a>.</p>
> diff --git a/htdocs/releases.html b/htdocs/releases.html
> index 02c675f5..22aa7928 100644
> --- a/htdocs/releases.html
> +++ b/htdocs/releases.html
> @@ -19,7 +19,7 @@
>  <p><em>Important: these are source releases, so will be of little
>  use if you do not already have a C++ compiler installed.</em>
>  As one option, there are
> -<a href="https://gcc.gnu.org/install/binaries.html">pre-compiled
> +<a href="https://gcc.gnu.org/onlinedocs/install/binaries.html">pre-compiled
>  binaries.</a> for various platforms.</p>
>  
>  <p>You can also retrieve our sources <a href="git.html">using Git</a>.</p>
> diff --git a/htdocs/simtest-howto.html b/htdocs/simtest-howto.html
> index 2e54476b..cb9d109a 100644
> --- a/htdocs/simtest-howto.html
> +++ b/htdocs/simtest-howto.html
> @@ -117,7 +117,7 @@ cd gcc &amp;&amp; find . -print | cpio -pdlmu ../combined &amp;&amp; cd ..
>      <h2>Build it</h2>
>  
>      <p>Make sure the
> -    <a href="http://gcc.gnu.org/install/prerequisites.html">building
> +    <a href="http://gcc.gnu.org/onlinedocs/install/prerequisites.html">building
>      prerequisites</a> for GCC are met, for example a host GCC no earlier
>      than 3.4 or later, with C++ support enabled.</p>
>  
> diff --git a/htdocs/style.mhtml b/htdocs/style.mhtml
> index 8afaa1e1..093f69a8 100644
> --- a/htdocs/style.mhtml
> +++ b/htdocs/style.mhtml
> @@ -66,7 +66,7 @@
>    <a href="<get-var BACKPATH>releases.html">Releases</a><br>
>    <a href="<get-var BACKPATH>snapshots.html">Snapshots</a><br>
>    <a href="<get-var BACKPATH>lists.html">Mailing lists</a><br>
> -  <a href="https://gcc.gnu.org/onlinedocs/gcc/Contributors.html">Contributors</a><br>
> +  <a href="https://gcc.gnu.org/onlinedocs/gcc/contributors-to-gcc.html">Contributors</a><br>
>    <div class="center">
>    <a href="https://twitter.com/gnutools">
>      <img src="<get-var BACKPATH>twitter-bird-light-bgs.png"
> @@ -84,8 +84,8 @@
>    <tr><td><table class="navitem">
>    <tr><td>Documentation</td></tr>
>    <tr><td>
> -  <a href="https://gcc.gnu.org/install/">Installation</a><br>
> -  &middot;&nbsp;<a href="https://gcc.gnu.org/install/specific.html">Platforms</a><br>
> +  <a href="https://gcc.gnu.org/onlinedocs/install/">Installation</a><br>
> +  &middot;&nbsp;<a href="https://gcc.gnu.org/onlinedocs/install/host-target-specific-installation-notes-for-gcc.html">Platforms</a><br>
>    <a href="<get-var BACKPATH>onlinedocs/">Manual</a><br>
>    <a href="<get-var BACKPATH>faq.html">FAQ</a><br>
>    <a href="https://gcc.gnu.org/wiki">Wiki</a><br>
> @@ -97,7 +97,7 @@
>    <tr><td>Download</td></tr>
>    <tr><td>
>    <a href="<get-var BACKPATH>mirrors.html">Mirrors</a><br>
> -  <a href="https://gcc.gnu.org/install/binaries.html">Binaries</a>
> +  <a href="https://gcc.gnu.org/onlinedocs/install/binaries.html">Binaries</a>
>    </td></tr>
>    </table></td></tr>
>  
> diff --git a/htdocs/testing/index.html b/htdocs/testing/index.html
> index bd6219ab..e62254af 100644
> --- a/htdocs/testing/index.html
> +++ b/htdocs/testing/index.html
> @@ -15,9 +15,9 @@
>  for additional testing.</p>
>  
>  <p>For information about running the GCC testsuites, see
> -<a href="https://gcc.gnu.org/install/test.html">Installing GCC: Testing</a>.
> +<a href="https://gcc.gnu.org/onlinedocs/install/testing.html">Installing GCC: Testing</a>.
>  For information about testsuite organization and adding new tests, see
> -<a href="https://gcc.gnu.org/onlinedocs/gccint/Testsuites.html">
> +<a href="https://gcc.gnu.org/onlinedocs/gccint/testsuites.html">
>  Test Suites</a> in the GCC Internals manual and the README files in
>  the testsuite directories.</p>
>  
> @@ -48,7 +48,7 @@ the testsuite directories.</p>
>  <ul>
>    <li>Perform regular builds and testing of current GCC sources that
>        are not already being reported regularly; see
> -      <a href="https://gcc.gnu.org/install/test.html">Installing GCC:
> +      <a href="https://gcc.gnu.org/onlinedoc/install/testing.html">Installing GCC:
>        Testing</a> for instructions on submitting test results.</li>
>    <li>Build cross compilers and test with simulators as described in
>        <a href="../simtest-howto.html">How to test GCC

On 11/9/22 12:22, Martin Liška wrote:
> Gerald, can you please propagate changes I made to:
> htdocs/style.mhtml file?

Gerald I would like to ask you for further server actions related
to the Sphinx documentation:

1) https://gcc.gnu.org/install/ - for the future we will use
https://gcc.gnu.org/onlinedocs/install/

That's a way we can cross reference an older GCC release (e.g. https://gcc.gnu.org/onlinedocs/gcc-12.2.0/nstall/)

So please remove content of /www/gcc/htdocs-preformatted/install

2) permanently redirect all '/install/', '/install/...*.html' to:
https://gcc.gnu.org/onlinedocs/install/

Thank you,
Martin

On Wed, 9 Nov 2022, Martin Liška wrote:
> Gerald, can you please propagate changes I made to:
> htdocs/style.mhtml file?

Done. All pages live on gcc.gnu.org should be udpated now.

(I'm at a conference and have been offline during daytime this week so 
far. If you want to run further changes, Friday and Monday should work 
fine.)

Gerald

Hi Martin,

On Wed, 9 Nov 2022, Martin Liška wrote:
> Gerald I would like to ask you for further server actions related
> to the Sphinx documentation:

sure, happy to help!

> 1) https://gcc.gnu.org/install/ - for the future we will use
> https://gcc.gnu.org/onlinedocs/install/

That's a (fair) bit longer and more complex URL. I understand the point 
about cross referencing older GCC releases and see benefits with that.

What do you think of keeping the latest under this shorter and simpler 
URL (too), though?

I believe a symlink (in the file system) on gcc.gnu.org could pull that
off.


> So please remove content of /www/gcc/htdocs-preformatted/install

That'll make some things simpler. 

Note how in style.mthml we have some special provisions for install/.

Over the last years I have reduced those to a large extent. There is still
a little bit post-processing going on right now including setting our CSS
and our favicon.

Should we see how to move those over to the new setup, or would you drop 
that?

Gerald

On 11/10/22 09:28, Gerald Pfeifer wrote:
> Hi Martin,
> 
> On Wed, 9 Nov 2022, Martin Liška wrote:
>> Gerald I would like to ask you for further server actions related
>> to the Sphinx documentation:
> 
> sure, happy to help!
> 
>> 1) https://gcc.gnu.org/install/ - for the future we will use
>> https://gcc.gnu.org/onlinedocs/install/
> 
> That's a (fair) bit longer and more complex URL. I understand the point
> about cross referencing older GCC releases and see benefits with that.
> 
> What do you think of keeping the latest under this shorter and simpler
> URL (too), though?

Hello.

Works for me.

> 
> I believe a symlink (in the file system) on gcc.gnu.org could pull that
> off.

Yep, please do so.

> 
> 
>> So please remove content of /www/gcc/htdocs-preformatted/install
> 
> That'll make some things simpler.
> 
> Note how in style.mthml we have some special provisions for install/.
> 
> Over the last years I have reduced those to a large extent. There is still
> a little bit post-processing going on right now including setting our CSS
> and our favicon.
> 
> Should we see how to move those over to the new setup, or would you drop
> that?

Well, the entire content of gcc.gnu.org/onlinedocs/install/ is *one* of our
documentations and there should not be anything special about it.
Does it make sense?

Cheers,
Martin

> 
> Gerald

On Thu, 10 Nov 2022, Martin Liška wrote:
>> What do you think of keeping the latest under this shorter and simpler
>> URL (too), though?
> Works for me.
:
>> I believe a symlink (in the file system) on gcc.gnu.org could pull that
>> off.
> Yep, please do so.

Done.

https://gcc.gnu.org/install/ is back with a new face.

Will you be reverting the link adjustments back from /onlinedocs/install/
to plain /install/ ?


>> Note how in style.mthml we have some special provisions for install/.
>> 
>> Over the last years I have reduced those to a large extent. There is still
>> a little bit post-processing going on right now including setting our CSS
>> and our favicon.
> Well, the entire content of gcc.gnu.org/onlinedocs/install/ is *one* of 
> our documentations and there should not be anything special about it. 
> Does it make sense?

Yes, things have evolved historically and there was a time we 
needed/wanted to treat /install especially, for example to retain 
the same (white) background color across.

By now, if we are to make changes, we probably should rather make them 
across all of /onlinedocs - favicon and our CSS being two such changes.
Not a critical priority, though, I guess.

Gerald

On 11/10/22 10:35, Gerald Pfeifer wrote:
> On Thu, 10 Nov 2022, Martin Liška wrote:
>>> What do you think of keeping the latest under this shorter and simpler
>>> URL (too), though?
>> Works for me.
> :
>>> I believe a symlink (in the file system) on gcc.gnu.org could pull that
>>> off.
>> Yep, please do so.
> 
> Done.
> 
> https://gcc.gnu.org/install/ is back with a new face.

But it's not working properly due to some Content Security Policy:

Refused to apply inline style because it violates the following Content Security Policy directive: "default-src 'self' http: https:". Either the 'unsafe-inline' keyword, a hash ('sha256-wAI2VKPX8IUBbq55XacEljWEKQc4Xc1nmwVsAjAplNU='), or a nonce ('nonce-...') is required to enable inline execution. Note also that 'style-src' was not explicitly set, so 'default-src' is used as a fallback.

gcc.gnu.org/:42 Refused to execute inline script because it violates the following Content Security Policy directive: "default-src 'self' http: https:". Either the 'unsafe-inline' keyword, a hash ('sha256-ySvT2PEZeueHGC1y2crNuNTfphBynFPP7i+U21fEgX0='), or a nonce ('nonce-...') is required to enable inline execution. Note also that 'script-src' was not explicitly set, so 'default-src' is used as a fallback.

gcc.gnu.org/:47 Refused to apply inline style because it violates the following Content Security Policy directive: "default-src 'self' http: https:". Either the 'unsafe-inline' keyword, a hash ('sha256-biLFinpqYMtWHmXfkA1BPeCY0/fNt46SAZ+BBk5YUog='), or a nonce ('nonce-...') is required to enable inline execution. Note that hashes do not apply to event handlers, style attributes and javascript: navigations unless the 'unsafe-hashes' keyword is present. Note also that 'style-src' was not explicitly set, so 'default-src' is used as a fallback.

gcc.gnu.org/:202 Refused to load the image 'data:image/svg+xml;charset=utf-8,<svg xmlns="http://www.w3.org/2000/svg" viewBox="0 0 24 24" stroke-width="1.5" stroke="currentColor" fill="none" stroke-linecap="round" stroke-linejoin="round"><path d="M0 0h24v24H0z" stroke="none"/><circle cx="10" cy="10" r="7"/><path d="m21 21-6-6"/></svg>' because it violates the following Content Security Policy directive: "default-src 'self' http: https:". Note that 'img-src' was not explicitly set, so 'default-src' is used as a fallback.


Can you please take a look at it?

> 
> Will you be reverting the link adjustments back from /onlinedocs/install/
> to plain /install/ ?

Yes, I can do that.

> 
> 
>>> Note how in style.mthml we have some special provisions for install/.
>>>
>>> Over the last years I have reduced those to a large extent. There is still
>>> a little bit post-processing going on right now including setting our CSS
>>> and our favicon.
>> Well, the entire content of gcc.gnu.org/onlinedocs/install/ is *one* of
>> our documentations and there should not be anything special about it.
>> Does it make sense?
> 
> Yes, things have evolved historically and there was a time we
> needed/wanted to treat /install especially, for example to retain
> the same (white) background color across.
> 
> By now, if we are to make changes, we probably should rather make them
> across all of /onlinedocs - favicon and our CSS being two such changes.
> Not a critical priority, though, I guess.
> 
> Gerald

On Thu, 10 Nov 2022, Martin Liška wrote:
>> https://gcc.gnu.org/install/ is back with a new face.
> But it's not working properly due to some Content Security Policy:

Hmm, it worked in my testing before and I just tried again: 

Firefox 106.0.1 (64-bit) and now also Chrome 106.0.5249.119 
and w3m.

Which browser are you using? Any particular add-ons or special security 
settings?

> Refused to apply inline style because it violates the following Content
> Security Policy directive: "default-src 'self' http: https:". Either the
> 'unsafe-inline' keyword, a hash
> ('sha256-wAI2VKPX8IUBbq55XacEljWEKQc4Xc1nmwVsAjAplNU='), or a nonce
> ('nonce-...') is required to enable inline execution. Note also that
> 'style-src' was not explicitly set, so 'default-src' is used as a fallback.

That looks like it's related to some Javascript fun? Does sphinx pull in 
something? Ohhhh, it does. A lot. 

I'm not using any Javascript blocker, though, so not sure why I am not
seeing any such warnings?

Searching for "+sphinx" and this message did not result in anything.

(It feels a bit curious how the position in the web server's file system 
or a symlink could trigger something like that?)


Looking at the source code of index.html I am wondering about

  <html class="no-js" lang="en">

versus all the .js inclusions later on.

And https://validator.w3.org/nu/?doc=https%3A%2F%2Fgcc.gnu.org%2Finstall%2F
and https://validator.w3.org/nu/?doc=https%3A%2F%2Fgcc.gnu.org%2Fonlinedocs%2Finstall%2F
appear equally (un)happy.

Gerald

On 11/10/22 11:03, Gerald Pfeifer wrote:
> On Thu, 10 Nov 2022, Martin Liška wrote:
>>> https://gcc.gnu.org/install/ is back with a new face.
>> But it's not working properly due to some Content Security Policy:
> 
> Hmm, it worked in my testing before and I just tried again:
> 
> Firefox 106.0.1 (64-bit) and now also Chrome 106.0.5249.119
> and w3m.
> 
> Which browser are you using? Any particular add-ons or special security
> settings?
> 
>> Refused to apply inline style because it violates the following Content
>> Security Policy directive: "default-src 'self' http: https:". Either the
>> 'unsafe-inline' keyword, a hash
>> ('sha256-wAI2VKPX8IUBbq55XacEljWEKQc4Xc1nmwVsAjAplNU='), or a nonce
>> ('nonce-...') is required to enable inline execution. Note also that
>> 'style-src' was not explicitly set, so 'default-src' is used as a fallback.
> 
> That looks like it's related to some Javascript fun? Does sphinx pull in
> something? Ohhhh, it does. A lot.
> 
> I'm not using any Javascript blocker, though, so not sure why I am not
> seeing any such warnings?
> 
> Searching for "+sphinx" and this message did not result in anything.
> 
> (It feels a bit curious how the position in the web server's file system
> or a symlink could trigger something like that?)
> 
> 
> Looking at the source code of index.html I am wondering about
> 
>    <html class="no-js" lang="en">
> 
> versus all the .js inclusions later on.
> 
> And https://validator.w3.org/nu/?doc=https%3A%2F%2Fgcc.gnu.org%2Finstall%2F
> and https://validator.w3.org/nu/?doc=https%3A%2F%2Fgcc.gnu.org%2Fonlinedocs%2Finstall%2F
> appear equally (un)happy.
> 
> Gerald

Well, I can also reproduce it on my mobile phone.

Anyway, the difference is:

$ curl https://gcc.gnu.org/install/index.html -v &> bad.txt
$ curl https://gcc.gnu.org/onlinedocs/install/index.html -v &> good.txt

$ diff -u good.txt bad.txt
--- good.txt	2022-11-10 11:33:45.293631904 +0100
+++ bad.txt	2022-11-10 11:33:37.813669264 +0100
@@ -32,31 +32,32 @@
  *  subjectAltName: host "gcc.gnu.org" matched cert's "gcc.gnu.org"
  *  issuer: C=US; O=Let's Encrypt; CN=R3
  *  SSL certificate verify ok.
   0     0    0     0    0     0      0      0 --:--:-- --:--:-- --:--:--     0* Using HTTP2, server supports multiplexing
+* Using HTTP2, server supports multiplexing
  * Copying HTTP/2 data in stream buffer to connection buffer after upgrade: len=0
  } [5 bytes data]
  * h2h3 [:method: GET]
-* h2h3 [:path: /onlinedocs/install/index.html]
+* h2h3 [:path: /install/index.html]
  * h2h3 [:scheme: https]
  * h2h3 [:authority: gcc.gnu.org]
  * h2h3 [user-agent: curl/7.86.0]
  * h2h3 [accept: */*]
  * Using Stream ID: 1 (easy handle 0x5555555bf890)
  } [5 bytes data]
-> GET /onlinedocs/install/index.html HTTP/2
+> GET /install/index.html HTTP/2
  > Host: gcc.gnu.org
  > user-agent: curl/7.86.0
  > accept: */*
  >
  { [5 bytes data]
  < HTTP/2 200
-< date: Thu, 10 Nov 2022 10:33:45 GMT
+< date: Thu, 10 Nov 2022 10:33:37 GMT
  < server: Apache/2.4.37 (Red Hat Enterprise Linux) OpenSSL/1.1.1k mod_qos/11.70 mod_wsgi/4.6.4 Python/3.6 mod_perl/2.0.12 Perl/v5.26.3
  < last-modified: Wed, 09 Nov 2022 18:51:10 GMT
  < etag: "8232-5ed0e23e07250"
  < accept-ranges: bytes
  < content-length: 33330
  < vary: Accept-Encoding
+< content-security-policy: default-src 'self' http: https:
  < strict-transport-security: max-age=16070400
  < content-type: text/html; charset=utf-8
  <
@@ -485,7 +486,7 @@
        
        
      </aside>
100 33330  100 33330    0     0  61514      0 --:--:-- --:--:-- --:--:-- 61494
100 33330  100 33330    0     0  62652      0 --:--:-- --:--:-- --:--:-- 62768
  * Connection #0 to host gcc.gnu.org left intact
  v>
  </div><script data-url_root="./" id="documentation_options" src="_static/documentation_options.js"></script>

=======

See that the problematic for some reason uses "content-security-policy: default-src 'self' http: https:".
And it uses 'Using HTTP2, server supports multiplexing'

Martin

Hi,

On 10.11.22 11:03, Gerald Pfeifer wrote:
> On Thu, 10 Nov 2022, Martin Liška wrote:
>>> https://gcc.gnu.org/install/ is back with a new face.
>> But it's not working properly due to some Content Security Policy:
> Hmm, it worked in my testing before and I just tried again:
> Firefox 106.0.1 (64-bit)

Did you open the console (F12)? If I do, I see the errors:

Content Security Policy: The page’s settings blocked the loading of a
resource at inline (“default-src”). That's for line 18, which is
'<style>'. The next one is for line 42 (same error) which is for:
<script>document.body.dataset.theme = localStorage.getItem("theme") ||
"auto"; </script>And then there is twice: Content Security Policy: The
page’s settings blocked the loading of a resource at
data:image/svg+xml;charset=utf-8,<svg xm… (“default-src”).

> (It feels a bit curious how the position in the web server's file system
> or a symlink could trigger something like that?)

If you look at the output of 'curl -I', which shows only the HTTP header, you will
see that only the /install/ URL has:

content-security-policy: default-src 'self' http: https:

There must be some server configuration that add this - but it does not seem
to be in the .ht* files in the wwwdocs git repo.

I could imaging that /install often contains some files in the default config
such that the central Apache configuration contains has this line to disallow code.
As most production servers don't use /install - it won't affect them and protects
them from some issues. → Something for overseers to check.


For a description, see:
https://developer.mozilla.org/en-US/docs/Web/HTTP/CSP
and https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers/Content-Security-Policy

* * *

> Looking at the source code of index.html I am wondering about
>    <html class="no-js" lang="en">
> versus all the .js inclusions later on.

But that only confuses humans - for the computer, it is just the name of
a CSS style sheet class.

Tobias

-----------------
Siemens Electronic Design Automation GmbH; Anschrift: Arnulfstraße 201, 80634 München; Gesellschaft mit beschränkter Haftung; Geschäftsführer: Thomas Heurung, Frank Thürauf; Sitz der Gesellschaft: München; Registergericht München, HRB 106955

Hi.

We noticed we'll need the old /install to be available for redirect.
Gerald, can you please put it somewhere under /install-prev, or something similar?

Thanks,
Martin

On Thu, 10 Nov 2022, Martin Liška wrote:
> We noticed we'll need the old /install to be available for redirect. 
>
> Gerald, can you please put it somewhere under /install-prev, or 
> something similar?

I'm afraid I am confused now. Based on your original request I had removed 
the original /install directoy.

Can you help me understand what exactly we need and what for (in the big
picture)? And I'll then see how I can help.

Gerald

Hi Gerald,

On 10.11.22 20:24, Gerald Pfeifer wrote:
> On Thu, 10 Nov 2022, Martin Liška wrote:
>> We noticed we'll need the old /install to be available for redirect.
>>
>> Gerald, can you please put it somewhere under /install-prev, or
>> something similar?
> I'm afraid I am confused now. Based on your original request I had removed
> the original /install directoy.

I think we just need to handle more. Namely:

* Links directly to https://gcc.gnu.org/install/
   this works and shows the new page.

* Sublinks - those currently fail as the name has changed:
   https://gcc.gnu.org/install/configure.html (which is now https://gcc.gnu.org/install/configuration.html )
   https://gcc.gnu.org/install/build.html (now: https://gcc.gnu.org/install/building.html )
   https://gcc.gnu.org/install/specific.html#avr → https://gcc.gnu.org/install/host-target-specific-installation-notes-for-gcc.html#avr

My impression is that it is sufficient to handle those renamings and we do not need the old pages.

However, others might have different ideas. Note that this was discussed in the thread "Links to web pages are broken."

Tobias

-----------------
Siemens Electronic Design Automation GmbH; Anschrift: Arnulfstraße 201, 80634 München; Gesellschaft mit beschränkter Haftung; Geschäftsführer: Thomas Heurung, Frank Thürauf; Sitz der Gesellschaft: München; Registergericht München, HRB 106955

On 11/11/22 09:40, Tobias Burnus wrote:
> However, others might have different ideas. Note that this was discussed in the thread "Links to web pages are broken."

Yes, please discuss this further in the aforementioned thread.

I do support the Richi's idea about using a new URL for the new Sphinx documentation
while keeping the older Texinfo documentation under /onlinedocs and /install

Martin

On 11.11.22 09:50, Martin Liška wrote:
> I do support the Richi's idea about using a new URL for the new Sphinx documentation
> while keeping the older Texinfo documentation under /onlinedocs and /install

If we do so and those become then static files: Can we put some
disclaimer at the top of all HTML files under /install/ and under
/onlinedocs/<previous mainline>/ that those are legacy files and the new
documentation can be found under <URL> (not a deep link but directly to
the install pages or the new overview page about the Sphinx docs).

I think we really need such a hint – otherwise it is more confusing than
helpful! Additionally, we should add a "news" entry to the mainpage
pointing out that it changed and linking to the new Sphinx doc.

Tobias

-----------------
Siemens Electronic Design Automation GmbH; Anschrift: Arnulfstraße 201, 80634 München; Gesellschaft mit beschränkter Haftung; Geschäftsführer: Thomas Heurung, Frank Thürauf; Sitz der Gesellschaft: München; Registergericht München, HRB 106955

On Fri, Nov 11, 2022 at 10:12 AM Tobias Burnus <tobias@codesourcery.com> wrote:
>
> On 11.11.22 09:50, Martin Liška wrote:
> > I do support the Richi's idea about using a new URL for the new Sphinx documentation
> > while keeping the older Texinfo documentation under /onlinedocs and /install
>
> If we do so and those become then static files: Can we put some
> disclaimer at the top of all HTML files under /install/ and under
> /onlinedocs/<previous mainline>/ that those are legacy files and the new
> documentation can be found under <URL> (not a deep link but directly to
> the install pages or the new overview page about the Sphinx docs).
>
> I think we really need such a hint – otherwise it is more confusing than
> helpful! Additionally, we should add a "news" entry to the mainpage
> pointing out that it changed and linking to the new Sphinx doc.

Note I think we can "remove" the install/ and onlinedocs/ _landing_ pages
(index.html) but we should keep the actual content pages so old links keep
working.  We can also replace the landing pages with a pointer to the new
documentation (or plain re-direct to that!).

Richard.

> Tobias
>
> -----------------
> Siemens Electronic Design Automation GmbH; Anschrift: Arnulfstraße 201, 80634 München; Gesellschaft mit beschränkter Haftung; Geschäftsführer: Thomas Heurung, Frank Thürauf; Sitz der Gesellschaft: München; Registergericht München, HRB 106955

On 11/11/22 11:18, Richard Biener wrote:
> On Fri, Nov 11, 2022 at 10:12 AM Tobias Burnus <tobias@codesourcery.com> wrote:
>>
>> On 11.11.22 09:50, Martin Liška wrote:
>>> I do support the Richi's idea about using a new URL for the new Sphinx documentation
>>> while keeping the older Texinfo documentation under /onlinedocs and /install
>>
>> If we do so and those become then static files: Can we put some
>> disclaimer at the top of all HTML files under /install/ and under
>> /onlinedocs/<previous mainline>/ that those are legacy files and the new
>> documentation can be found under <URL> (not a deep link but directly to
>> the install pages or the new overview page about the Sphinx docs).
>>
>> I think we really need such a hint – otherwise it is more confusing than
>> helpful! Additionally, we should add a "news" entry to the mainpage
>> pointing out that it changed and linking to the new Sphinx doc.
> 
> Note I think we can "remove" the install/ and onlinedocs/ _landing_ pages
> (index.html) but we should keep the actual content pages so old links keep
> working.  We can also replace the landing pages with a pointer to the new
> documentation (or plain re-direct to that!).

Even better. So let me summarize it:

gcc.gnu.org/docs - will contain newly generated Sphinx documentation
gcc.gnu.org/docs/gcc - sub-folder example
gcc.gnu.org/docs/install - sub-folder example
gcc.gnu.org/docs/gcc-13.1.0/install - sub-folder example once we'll have GCC 13.1 release

gcc.gnu.org/install/index.html - 301 to gcc.gnu.org/docs/install
gcc.gnu.org/install/$something - point to old install manual
gcc.gnu.org/onlinedocs/index.html - 301 to gcc.gnu.org/docs/
gcc.gnu.org/onlinedocs/$something - point to old GCC manual

@Gerald: Is it something you can set-up? What do you think about it?

Martin

> 
> Richard.
> 
>> Tobias
>>
>> -----------------
>> Siemens Electronic Design Automation GmbH; Anschrift: Arnulfstraße 201, 80634 München; Gesellschaft mit beschränkter Haftung; Geschäftsführer: Thomas Heurung, Frank Thürauf; Sitz der Gesellschaft: München; Registergericht München, HRB 106955

Hi Richard,

On 11.11.22 11:18, Richard Bienr wrote:

> Note I think we can "remove" the install/ and onlinedocs/ _landing_ pages
> (index.html) but we should keep the actual content pages so old links keep
> working.  We can also replace the landing pages with a pointer to the new
> documentation (or plain re-direct to that!).

For install, I think we should consider to redirect. Before the move to Sphinx, we had only:

binaries.html
build.html
configure.html
download.html
finalinstall.html
gfdl.html
index.html
prerequisites.html
specific.html
test.html

Re-directing them to the new pages will work. There is a one-to-one correspondence for all but
build/test which are now in 7* and 5 files, respectively. Still linking to the outermost
should be ok as I do not think that there will be many links using '#...'.

(*The subdivision is also a bit pointless for Ada and D as it consists only of the texts
"GNAT prerequisites." and "GDC prerequisites.", respectively (in the old doc).
In the Sphinx docs, it is even shortened to: "GNAT." and "GDC.".)

The only except where links to page anchors are likely used is for
"Host/target specific installation notes for GCC".
For them, some like '#avr' still works while others don't (like 'nvptx-*-none'
as '#nvptx-x-none' changed to '#nvptx-none'). But the page is short enough and
it is clear from the context what the user wants - there is also a table of
content on the right to click on. (IMHO that's sufficient.)

* * *

For /onlinedocs/, I concur that we want to have the old doc there as there are many
deep links. Still, we should consider adding a disclaimer box to all former mainline
documentation stating that this data is no longer updated + point to the new overview
page + we could redirect access which goes directly to '..../<module>/' and not a (sub)html
page to the new site, as you proposed.

Tobias

-----------------
Siemens Electronic Design Automation GmbH; Anschrift: Arnulfstraße 201, 80634 München; Gesellschaft mit beschränkter Haftung; Geschäftsführer: Thomas Heurung, Frank Thürauf; Sitz der Gesellschaft: München; Registergericht München, HRB 106955

On Fri, 11 Nov 2022, Tobias Burnus wrote:

> For /onlinedocs/, I concur that we want to have the old doc there as there are
> many
> deep links. Still, we should consider adding a disclaimer box to all former
> mainline
> documentation stating that this data is no longer updated + point to the new
> overview
> page + we could redirect access which goes directly to '..../<module>/' and
> not a (sub)html
> page to the new site, as you proposed.

Note that if we do this, I think my previous comments (to keep the 
unmodified files somewhere long-term outside the directory served by the 
webserver, with an automated process for modifying headers, so that 
modified versions of that process can be re-run in future if we have 
further changes to apply to the added headers) apply to such old mainline 
documentation just as to release documentation.

On Thu, 10 Nov 2022, Martin Liška wrote:
> See that the problematic for some reason uses "content-security-policy:
> default-src 'self' http: https:".

Yep.

On Thu, 10 Nov 2022, Tobias Burnus wrote:
> content-security-policy: default-src 'self' http: https:
> 
> There must be some server configuration that add this - but it does not 
> seem to be in the .ht* files in the wwwdocs git repo.

And yep. I dug into this yesterday and found the following:

In /etc/httpd/conf.d/sourceware-vhost-gcc.conf we have

  <Location /onlinedocs>
        Header unset Content-Security-Policy
  </Location>

I am not aware of who added this, and why, nor actually even why, yet it 
seems if we can get the same in place for /install we'll be good again, so
I'll ask overseers@.


Next step: redirects from the old /install docs to the new ones.

Gerald

On Sat, 12 Nov 2022, Gerald Pfeifer wrote:
> I am not aware of who added this, and why, nor actually even why, yet it 
> seems if we can get the same in place for /install we'll be good again, so
> I'll ask overseers@.

https://gcc.gnu.org/install/ is up and running fine now/again.

> Next step: redirects from the old /install docs to the new ones.

Gerald

On 11/12/22 01:06, Joseph Myers wrote:
> On Fri, 11 Nov 2022, Tobias Burnus wrote:
> 
>> For /onlinedocs/, I concur that we want to have the old doc there as there are
>> many
>> deep links. Still, we should consider adding a disclaimer box to all former
>> mainline
>> documentation stating that this data is no longer updated + point to the new
>> overview
>> page + we could redirect access which goes directly to '..../<module>/' and
>> not a (sub)html
>> page to the new site, as you proposed.
> 
> Note that if we do this, I think my previous comments (to keep the 
> unmodified files somewhere long-term outside the directory served by the 
> webserver, with an automated process for modifying headers, so that 
> modified versions of that process can be re-run in future if we have 
> further changes to apply to the added headers) apply to such old mainline 
> documentation just as to release documentation.
> 

Hello.

So I in context of [1] and [2] we will have to move content in between files
and thus newly taken URLs (from gcc.gnu.org/onlinedocs/$man and gcc.gnu.org/install)
can get invalid.

So Gerald, I'm suggesting a new url base gcc.gnu.org/docs that will be filled with the new manuals
and gcc.gnu.org/onlinedocs/$man and gcc.gnu.org/install locations should point to older (trunk)
manuals (prev folder at server I guess).
Having that, the new manuals will not available through navigation and will get some time
for further changes.

Thanks.
Martin

[1] https://gcc.gnu.org/pipermail/gcc/2022-November/239922.html
[2] https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107634

On Sun, 13 Nov 2022, Martin Liška wrote:
> So Gerald, I'm suggesting a new url base gcc.gnu.org/docs that will be 
> filled with the new manuals and gcc.gnu.org/onlinedocs/$man and 
> gcc.gnu.org/install locations should point to older (trunk) manuals 
> (prev folder at server I guess). Having that, the new manuals will not 
> available through navigation and will get some time for further changes.

I feel I may be missing something.

Why don't we

 (1a) keep /onlinedocs for all docs < GCC 13,
 (1b) possibly introduce /docs as an alternative URL (though we need
      to keep /onlinedocs for all the existing ones),

  (2) add sphinx docs for trunk, GCC 13 and later to /docs (and at the
      same time /onlinedocs which is just an alias)

  (3) put current installation documentation under /install and simply
      add a few redirects for those pages that have changed names?

That way we can retain existing structures, possibly replace /onlinedocs 
for the shorter /docs, and have one consistent index for all manuals.

Gerald

On 11/14/22 02:21, Gerald Pfeifer wrote:
> On Sun, 13 Nov 2022, Martin Liška wrote:
>> So Gerald, I'm suggesting a new url base gcc.gnu.org/docs that will be 
>> filled with the new manuals and gcc.gnu.org/onlinedocs/$man and 
>> gcc.gnu.org/install locations should point to older (trunk) manuals 
>> (prev folder at server I guess). Having that, the new manuals will not 
>> available through navigation and will get some time for further changes.
> 
> I feel I may be missing something.
> 
> Why don't we
> 
>  (1a) keep /onlinedocs for all docs < GCC 13,
>  (1b) possibly introduce /docs as an alternative URL (though we need
>       to keep /onlinedocs for all the existing ones),
> 
>   (2) add sphinx docs for trunk, GCC 13 and later to /docs (and at the
>       same time /onlinedocs which is just an alias)
> 
>   (3) put current installation documentation under /install and simply
>       add a few redirects for those pages that have changed names?
> 
> That way we can retain existing structures, possibly replace /onlinedocs 
> for the shorter /docs, and have one consistent index for all manuals.
> 
> Gerald

Hello.

Note the Sphinx changes will be reverted today:
https://gcc.gnu.org/pipermail/gcc/2022-November/239983.html

That said, we won't need to come up with a new sub-url.

Martin