Bug#1073510: Spanish translation of slm debconf template (Re: Translation status robot not working?)

[Holger Wansing]

Control: reopen -1


Hi,

Camaleón  wrote (Sun, 30 Jun 2024 19:52:48 +0200):
> 
> IIRC, I also noticed the typo and submitted the corrected PO file... 
> way days ago:
> 
> https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1073510#15

Please note, that you have added that message to the bug, when it has already
been closed.
So the maintainer might overlook this (important) message!

Thus, let's reopen that bug, to make maintainer aware of this.


@georgesk: 
The debian/po/es.po file sadly contains a syntax error, which leads to
processing errors with translation statistics on the Debian website.
Please use the file from
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1073510#15
to fix this issue.


Thanks for your time

Holger



-- 
Holger Wansing 
PGP-Fingerprint: 496A C6E8 1442 4B34 8508  3529 59F1 87CA 156E B076

Bug#1074292: [INTL:es] Spanish translation of systemd-boot-installer debconf template

[Holger Wansing]

Control: tags -1 + pending


Hi,

Camaleón  wrote (Wed, 26 Jun 2024 08:19:11 +0200):
> Package: systemd-boot-installer
> Severity: wishlist
> Tags: patch l10n
> 
> Hello,
> 
> You can find enclosed the Spanish translation template to be uploaded with 
> the latest package build.
> 
> Kindly place this file in debian/po/ as es.po for your next upload.

As I wrote you in another mail, this is not a usual package, but one
belonging to the debian-installer.
I have therefore added your work to d-i's l10n infrastructure here:
https://salsa.debian.org/installer-team/d-i/-/commit/3e2ac8dc08386129740e80877f8d04404082b496


Holger

-- 
Holger Wansing 
PGP-Fingerprint: 496A C6E8 1442 4B34 8508  3529 59F1 87CA 156E B076

Bug#1074304: xfce4-power-manager: please add manpage for xfce4-pm-helper

[Holger Wansing]

Package: xfce4-power-manager
Severity: wishlist
Tags: patch


Hi maintainer,

attached is a manpage for xfce4-pm-helper script, which is currently missing
from your package.

Please consider including it.


Thanks for your time

So long
Holger


-- 
Holger Wansing 
PGP-Finterprint: 496A C6E8 1442 4B34 8508  3529 59F1 87CA 156E B076


debian⁄xfce4-pm-helper.8.gz
Description: application/gzip

Bug#1073497: dh_sphinxdoc: please replace *-stemmer.js with symlinks to files from sphinx-common

[Holger Wansing]

Package: sphinx-common
Severity: wishlist


Hi guys,

I would like to ask, if it would be possible, to make dh_sphinxdoc to process
*-stemmer.js files (base-stemmer.js, german-stemmer.js and so on) for
replacing with symlinks to /usr/share/sphinx/search/non-minified-js/ ?

I see there are other variants of that files in the minified-js folder,
so I'm not sure, if this approach is do-able at all ...


Thanks for your time

So long
Holger


-- 
Holger Wansing 
PGP-Finterprint: 496A C6E8 1442 4B34 8508  3529 59F1 87CA 156E B076

Bug#932957: 'Official' Debian-style html theme for Sphinx-based docs

[Holger Wansing]

Holger Wansing  wrote:
> Hi, you may have noticed that we have an 'official' Debian-style html 
> theme for Sphinx-based manuals on the Debian website now. It can 
> be seen at debian-policy under https://www.debian.org/doc/debian-policy/
> It was created by Stéphane Blondon, based on a theme from readthedocs.org. 
> Any objections against porting this theme to the release-notes as well?

I have created a merge request for this:
<https://salsa.debian.org/ddp-team/release-notes/-/merge_requests/207>

I will merge it shortly, if noone objects.


Holger



-- 
Sent from /e/ OS on Fairphone3

Bug#1072860: dh_sphinxdoc: unable to exclude files from test with -X

[Holger Wansing]

Package: sphinx-common
Severity: minor
Version: 7.2.6-8


Hi maintainers,

While migrating the developers-reference to a Debian-style html theme - based
on a readthedocs theme - we encountered a build failure with:

-
debian/rules override_dh_sphinxdoc
make[1]: Entering directory '/build/developers-reference-13.7'
dh_sphinxdoc -pdevelopers-reference usr/share/developers-reference
dh_sphinxdoc: error: 
debian/developers-reference/usr/share/developers-reference/search.html 
top-level node does not have data-content_root attribute
make[1]: *** [debian/rules:19: override_dh_sphinxdoc] Error 255
make[1]: Leaving directory '/build/developers-reference-13.7'
make: *** [debian/rules:6: binary] Error 2
dpkg-buildpackage: error: debian/rules binary subprocess returned exit status 2
-

While this error is basically correct (the search.html in fact does not 
contain data-content_root attribute, and this because I incorrectly used the 
search.html template from the python3-sphinx-rtd-theme package from stable 
instead of unstable), I could not exclude the search.html from the tests with

-Xsearch.html
or
-Xdebian/developers-reference/usr/share/developers-reference/search.html
as stated in the manpage.

So, the exclude function seems somewhat buggy.


Thanks for your time

So long
Holger


-- 
Holger Wansing 
PGP-Finterprint: 496A C6E8 1442 4B34 8508  3529 59F1 87CA 156E B076

Bug#815202: #815202 packages: machines and sponsors information is outdated

[Holger Wansing]

No progress for the last 7 years :-(

I have just updated the sponsors list manually for now.


Holger

-- 
Holger Wansing 
PGP-Fingerprint: 496A C6E8 1442 4B34 8508  3529 59F1 87CA 156E B076

Bug#442083: #442083packages.debian.org: [i18n] several i18n related issues

[Holger Wansing]

Thomas Lange  wrote:
> I wonder if this bug is still valid?

The discrepancies spotted by Paul in



are still there, so this is valid.

Just apply the patch and see how it goes?


Holger



-- 
Sent from /e/ OS on Fairphone3

Bug#1071739: marked as done (packages.debian.org: Removal of spam domain from download mirror page)

[Holger Wansing]

Am 24. Mai 2024 20:16:35 MESZ schrieb Holger Wansing :
>
>
>Am 24. Mai 2024 20:10:35 MESZ schrieb Thomas Lange :
>>>>>>> On Fri, 24 May 2024 20:02:35 +0200, Holger Wansing 
>>>>>>>  said:
>>
>>> Hi Thomas,
>>> you fixed this in master branch.
>>> Are you sure about this?
>>> I somehow seem to remember, that debian-master branch is used for 
>> packages.d.o ...
>>you are right, debian-master seems to be the correct branch.
>>I will fix it also in debian-master.
>>
>>Do you know if the branch master is used for anything?
>
>Don't know.

Maybe we should just make debian-master the default branch (instead of the 
master one)?


Holger

-- 
Sent from /e/ OS on Fairphone3

Bug#1071739: marked as done (packages.debian.org: Removal of spam domain from download mirror page)

[Holger Wansing]

Am 24. Mai 2024 20:10:35 MESZ schrieb Thomas Lange :
>>>>>> On Fri, 24 May 2024 20:02:35 +0200, Holger Wansing 
>>>>>>  said:
>
>> Hi Thomas,
>> you fixed this in master branch.
>> Are you sure about this?
>> I somehow seem to remember, that debian-master branch is used for 
> packages.d.o ...
>you are right, debian-master seems to be the correct branch.
>I will fix it also in debian-master.
>
>Do you know if the branch master is used for anything?

Don't know.


Holger


-- 
Sent from /e/ OS on Fairphone3

Bug#1071739: marked as done (packages.debian.org: Removal of spam domain from download mirror page)

[Holger Wansing]

Hi Thomas,

you fixed this in master branch.
Are you sure about this?
I somehow seem to remember, that debian-master branch is used for packages.d.o 
...


Holger






Von:Thomas Lange 
An:1071739-done@bugs.debian.orgGesendet:Fri May 24 
19:31:01 GMT+02:00 2024Betreff:Bug#1071739 fixed in www.debian.org

Hello,

Bug #1071739 in www.debian.org reported by you has been fixed in the Git 
repository.
You can see the commit message below and you can check the diff of the fix at:

https://salsa.debian.org/webmaster-team/packages/-/commit/68dd648d0b460c33c396e743732268c0bcd10f8a







-- 
Sent from /e/ OS on Fairphone3

Bug#1071157: www.debian.org: securing debian manual: broken links

[Holger Wansing]

Control: reassign -1 harden-doc



Am 15. Mai 2024 11:33:44 MESZ schrieb Hendrik Jaeger 
:
>Package: www.debian.org
>Severity: minor
>X-Debbugs-Cc: debian-b...@henk.geekmail.org
>
>Dear Maintainer,
>
>   * What led up to the situation?
>
>Collecting information on SysRq.
>Followed by trying to find information how to report issues with the 
>documentation.
>
>   * What was the outcome of this action?
>
>For both tasks: stumble over broken links.
>
>   * What outcome did you expect instead?
>
>Working links.
>
>
>https://www.debian.org/doc/manuals/securing-debian-manual/restrict-sysrq.en.html
> has the following text:
>»For more information, read security chapter in the Remote Serial Console 
>HOWTO, Kernel SysRQ documentation. and the Magic_SysRq_key wikipedia entry.«
>The link to the »Kernel SysRQ documentation« is broken and leads to
>https://kernel.org/doc/Documentation/sysrq.txt
>correct link would probably be
>https://www.kernel.org/doc/html/latest/admin-guide/sysrq.html
>
>https://www.debian.org/doc/manuals/securing-debian-manual/changelog.en.html 
>has the following text:
>»You can download or view the latest version of the Securing Debian Manual 
>from the Debian Documentation Project.«
>The link to »Debian Documentation Project« leads to
>https://www.debian.org/doc/manuals/securing-debian-howto/ which shows »Page 
>not found« and should maybe instead lead to
>https://www.debian.org/doc/ddp.
>
>It looks like there are possibly more broken links, among other to 
>alioth.debian.org.
>So generally it might be a good idea to regularly run a broken link checker 
>over all docs.

The issue is in the documentation package, not on the website; reassign to 
harden-doc.


Holger

-- 
Sent from /e/ OS on Fairphone3

Bug#1016957: remove kbd-chooser from the archive?

[Holger Wansing]

Hi,

Paul Gevers  wrote (Sat, 4 May 2024 07:46:45 +0200):
> Hi Bastian,
> 
> On Sat, 9 Sep 2023 19:03:07 +0200 Bastian Germann  wrote:
> > Control: severity -1 serious
> 
> Can you please elaborate? I'm not seeing anything serious in this bug 
> report.

I think Bastian's approach is, to remove kbd-chooser from the archive, since
it was stated (see below) that it's no longer in use.
d-i has switched away from it to console-setup 12 years ago with
https://salsa.debian.org/installer-team/debian-installer/-/commit/2575a669e91252a6253430020137154c995c9b38

Are there any ports maybe, that still use it somehow?
Or what about derivatives?
It's an udeb-only package, so the use in the installer is the only imaginable 
scenario...

@installer-team: any comments?

> 
> > On Wed, 10 Aug 2022 21:42:34 +0200 Holger Wansing  
> > wrote:
> > > kbd-chooser is no longer in use, I think.
> > > Or am I missing something?
> > 
> > I am raising severity to serious then so that it can be autoremoved from 
> > testing.
> 
> This package is a key package (because of debian-installer), so it can't 
> be autoremoved.


Holger


-- 
Holger Wansing 
PGP-Fingerprint: 496A C6E8 1442 4B34 8508  3529 59F1 87CA 156E B076

Bug#1069417: upgrade procedure instructs users to run “apt update” but neglects upgrading

[Holger Wansing]

Control: tags -1 + patch


Manny  wrote:
> The Bookworm release notes instruct users to “upgrade” to the latest point 
> release of Bullseye prior to upgrading to Bookworm:
> 
>   
> https://www.debian.org/releases/stable/i386/release-notes/ch-upgrading.en.html#upgrade-to-latest-point-release
> 
> When following that link, the article says to do an “apt update” then 
> neglects to tell users to perform the upgrade.

Moreover, we have "This should only be necessary in specific situations." in 
this chapter appendix A [1], while we recommend to upgrade to the latest point
release of stable in 4.2.2 [2].

We should remove that phrase completely.

A patch for above two issues is attached (against the bookworm branch; any
such changing needs to be ported to master/trixie as well).


Holger


[1] 
https://www.debian.org/releases/stable/amd64/release-notes/ap-old-stuff.en.html#old-upgrade
[2] 
https://www.debian.org/releases/stable/amd64/release-notes/ch-upgrading.en.html#upgrade-to-latest-point-release

-- 
Holger Wansing 
PGP-Fingerprint: 496A C6E8 1442 4B34 8508  3529 59F1 87CA 156E B076
diff --git a/en/old-stuff.dbk b/en/old-stuff.dbk
index b1c734e7..287c80c1 100644
--- a/en/old-stuff.dbk
+++ b/en/old-stuff.dbk
@@ -2,22 +2,21 @@
 https://www.oasis-open.org/docbook/xml/4.5/docbookx.dtd; [
%languagedata;
%shareddata;
 ]>
 
 
 Managing your  system before the upgrade
 
 This appendix contains information on how to make sure you can install or
-upgrade  packages before you upgrade to .  This should only be
-necessary in specific situations.
+upgrade  packages before you upgrade to .
 
 
 Upgrading your  system
 
 Basically this is no different from any other upgrade of  you've been
 doing.  The only difference is that you first need to make sure your package
 list still contains references to  as explained in .
 
 
@@ -73,20 +72,31 @@ not.  It is possible to downgrade packages, but that is not covered here.
 If you've made any changes, save the file and execute
 
 
 # apt update
 
 
 to refresh the package list.
 
 
 
+
+Performing the upgrade to latest  release
+
+To upgrade all packages to the state of the latest point release for
+, do
+
+
+# apt full-upgrade
+
+
+
 
 Removing obsolete configuration files
 
 Before upgrading your system to , it is recommended to remove old
 configuration files (such as *.dpkg-{new,old} files under
 /etc) from the system.
 
 
 
 

Bug#932957: 'Official' Debian-style html theme for Sphinx-based docs

[Holger Wansing]

I tend to ignore the language-related issues with the search for now.

Currently we have no document-wide search functionality at all on the Sphinx-
based documents on our website.

So it's clearly an improvement, if it works for English at least.


Holger

Bug#932957: 'Official' Debian-style html theme for Sphinx-based docs

[Holger Wansing]

Hi,

James Addison  wrote (Sun, 14 Apr 2024 23:52:03 +0100):
> The _other_ hyperlinks in the static content are replaced as part of the
> cronjob[1] - but that doesn't work for items in the searchindex.js file.
> 
> Fortunately I think there might be a better way to do this.  Sphinx itself has
> an HTML builder option 'html_file_suffix' and I think we could use that 
> instead
> to define the filenames.  That option is respected by the search JavaScript
> using a template variable[3] in the documentation_options.js file.

I fear I have no idea what to do with these options:

add 'html_file_suffix' in the conf.py: the default value is html here, what
should I insert here?

in documentation_options.js I have  FILE_SUFFIX: '{{ file_suffix }}'; what
to do with this?



An idea came to mind:
if we could change the search results, so that they no longer have a file
extension (say: the link points to 'installing' instead of 'installing.html') 
everything would work fine I guess, since the browser delivers the correct
language page due to content negotiation according to browser lang settings.


I don't know if you thought about such thing, when writing about above html 
build / file suffix options???
(as already said: I have no clue how the above could change something)


Holger



> We should be careful of other side-effects if making that change, but it
> would remove a deployment transformation step on the static content, and I
> think that's beneficial.
> 
> [1] - 
> https://salsa.debian.org/webmaster-team/cron/-/blob/3462a061d0a67dce3761b0f4d9357c017ad0a50b/parts/7release-notes#L64-70
> 
> [2] - 
> https://www.sphinx-doc.org/en/master/usage/configuration.html#confval-html_file_suffix
> 
> [3] - 
> https://github.com/sphinx-doc/sphinx/blob/cf7d2759af0852d67288e58d823d51fe860749ca/sphinx/themes/basic/static/documentation_options.js_t#L6
> 


-- 
Holger Wansing 
PGP-Fingerprint: 496A C6E8 1442 4B34 8508  3529 59F1 87CA 156E B076

Bug#932957: 'Official' Debian-style html theme for Sphinx-based docs

[Holger Wansing]

Hi,

Am 16. April 2024 23:47:05 MESZ schrieb James Addison :
>> I have tried to deal with this by some adaptions in the cronjob - see the
>> first two additions in my patch: change all links to search.html into
>> search.§lang.html, and rename the language-specific searchindex files into
>> searchindex.$lang.js.
>> However, that does not seem to be enough.
>
>When you say it is not enough: could I check what you mean by that?

I could guess that changings on the Search box are needed, to use
the language-wise correct searchindex.

But that's too much corrections on the Sphinx-generated result
if you ask me...

And out of my skills, sorry.


Holger



-- 
Sent from /e/ OS on Fairphone3

Bug#932957: 'Official' Debian-style html theme for Sphinx-based docs

[Holger Wansing]

Hi,

James Addison  wrote (Sun, 14 Apr 2024 23:52:03 +0100):
> From some testing of these: the search results have a problem that they
> hyperlink to a language-less .html URL, meaning that clicking a result link in
> the DE-language search results takes the user to a EN-language page.

Yes, good catch.
However it's even worse: if you view a German page and use the Search function,
the search index for English is used.
I have tried to deal with this by some adaptions in the cronjob - see the 
first two additions in my patch: change all links to search.html into
search.§lang.html, and rename the language-specific searchindex files into
searchindex.$lang.js.
However, that does not seem to be enough.

> The _other_ hyperlinks in the static content are replaced as part of the
> cronjob[1] - but that doesn't work for items in the searchindex.js file.

Why is that a problem at all (maybe you know this already): 
since we use content negotiation at Debian website (so the pages are 
delivered in the correct language according to user's browser setting), we
change the directory structure away from the default how it's build by Sphinx:
after Sphinx' make there are separate directories for every language,
and they contain everything for that language, including the searchindex.js
file. And in that structure it works fine.
On Debian website we put everything in one directory, adding the language
code into the filename in front of the .html extension.
While this works fine for static content, it does not for the search 
function here.

> Fortunately I think there might be a better way to do this.  Sphinx itself has
> an HTML builder option 'html_file_suffix' and I think we could use that 
> instead
> to define the filenames.  That option is respected by the search JavaScript
> using a template variable[3] in the documentation_options.js file.
> 
> We should be careful of other side-effects if making that change, but it
> would remove a deployment transformation step on the static content, and I
> think that's beneficial.

I don't understand how that could affect our search function problem, 
but I could give it a try.


Holger

-- 
Holger Wansing 
PGP-Fingerprint: 496A C6E8 1442 4B34 8508  3529 59F1 87CA 156E B076

Bug#932957: 'Official' Debian-style html theme for Sphinx-based docs

[Holger Wansing]

Hi,

Holger Wansing  wrote (Sun, 14 Apr 2024 22:25:21 +0200):
> It can be seen at debian-policy under
> https://www.debian.org/doc/debian-policy/

I forgot to mention, that I have pushed a release-notes variant with this
theme to
https://people.debian.org/~holgerw/new-rtd-sphinx-theme-for-debian/release-notes/release-notes/index.en.html
(English)

https://people.debian.org/~holgerw/new-rtd-sphinx-theme-for-debian/release-notes/release-notes/index.de.html
(German)

https://people.debian.org/~holgerw/new-rtd-sphinx-theme-for-debian/release-notes/release-notes/index.ca.html
(Catalan)


And we need an additional package installed on wolkenstein, to build the
release-notes with this theme.


Holger

-- 
Holger Wansing 
PGP-Fingerprint: 496A C6E8 1442 4B34 8508  3529 59F1 87CA 156E B076

Bug#932957: 'Official' Debian-style html theme for Sphinx-based docs

[Holger Wansing]

Hi,

you may have noticed that we have an 'official' Debian-style html theme for
Sphinx-based manuals on the Debian website now.

It can be seen at debian-policy under
https://www.debian.org/doc/debian-policy/

It was created by Stéphane Blondon, based on a theme from readthedocs.org.

Any objections against porting this theme to the release-notes as well?

To make this theme work on the Debian website, there are some more changings
needed in webmaster's cron repo; I have prepared them and attached to this
mail, just for completeness.


Holger


-- 
Holger Wansing 
PGP-Fingerprint: 496A C6E8 1442 4B34 8508  3529 59F1 87CA 156E B076
>From 2704fab5800f36aeafa29275e7afd13b422ecb81 Mon Sep 17 00:00:00 2001
From: Holger Wansing 
Date: Sun, 14 Apr 2024 22:04:20 +0200
Subject: [PATCH] =?UTF-8?q?Switch=20to=20new=20Debian-style=20html=20theme?=
 =?UTF-8?q?=20by=20St=C3=A9phane=20Blondon,=20based=20on=20readthedocs.org?=
 =?UTF-8?q?=20theme?=
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit

---
 source/_static/debian.css | 103 ++
 source/conf.py|  14 +++---
 2 files changed, 109 insertions(+), 8 deletions(-)
 create mode 100644 source/_static/debian.css

diff --git a/source/_static/debian.css b/source/_static/debian.css
new file mode 100644
index ..7f0981b0
--- /dev/null
+++ b/source/_static/debian.css
@@ -0,0 +1,103 @@
+/* Debian Cascading stylesheet for Sphinx */
+
+div.related {
+background-color: #C70036;
+}
+
+.rst-content h1, .rst-content h2, .rst-content h3, .rst-content h4, .rst-content h5, .rst-content h6 {
+color: #C70036;
+}
+
+.wy-nav-top {
+background-color: #C70036;
+}
+
+.wy-side-nav-search {
+background-color: #C70036;
+}
+
+.rst-content a:link {
+color: #0035C7;
+text-decoration: none;
+}
+.rst-content a:visited {
+color: #00207A;
+text-decoration: none;
+}
+.rst-content a:link:hover {
+color: #00207A;
+text-decoration: underline;
+}
+
+
+/* Table in content */
+
+.wy-table-responsive table td, .wy-table-responsive table th {
+white-space: normal;
+}
+
+.rst-content table.docutils, .wy-table-bordered-all {
+width: 100%;
+}
+
+.wy-table-responsive table.docutils thead tr {
+background-color: #C70036;
+border: 1px solid black;
+color: black;
+}
+
+.wy-table-responsive table.docutils thead tr:hover {
+color: #fcfcfc;
+}
+
+.wy-table-responsive table.docutils tbody tr:hover {
+background-color:#66;
+color: #FF;
+}
+
+.rst-content table.docutils:not(.field-list) tbody tr:hover:nth-child(2n-1), .wy-table-backed, .wy-table-odd td, .wy-table-striped tr:nth-child(2n-1) td {
+background-color:#66;
+}
+
+/* Previous and next buttons */
+
+.rst-footer-buttons .btn:hover {
+text-decoration: none !important;
+}
+
+/* Version release more readable */
+
+.wy-side-nav-search > div.version {
+color: #FCFCFC;
+}
+
+/* Infos blocks */
+
+div.warning {
+border: 1px dashed #EFF500;
+background-color: #eff50030;
+}
+
+div.note {
+border: 1px dashed blue;
+background-color: #ff30;
+
+}
+
+.warning, .note {
+margin-left: 1em;
+margin-right: 1em;
+}
+
+@media (max-width: 5in), (max-device-width: 5in){
+.warning, .note {
+margin-left: 0.5em;
+margin-right: 0.5em;
+}
+}
+
+/* Notes */
+
+html.writer-html5 .rst-content aside.citation, html.writer-html5 .rst-content aside.footnote, html.writer-html5 .rst-content div.citation {
+display: block;
+}
diff --git a/source/conf.py b/source/conf.py
index 855fb942..ec055233 100644
--- a/source/conf.py
+++ b/source/conf.py
@@ -127,20 +127,15 @@ pygments_style = None
 # The theme to use for HTML and HTML Help pages.  See the documentation for
 # a list of builtin themes.
 #
-html_theme = 'alabaster'
+html_theme = 'sphinx_rtd_theme'
 
 # Theme options are theme-specific and customize the look and feel of a theme
 # further.  For a list of options available for each theme, see the
 # documentation.
 #
 html_theme_options = {
-	'logo': 'openlogo-release-notes.png',
-	'show_powered_by': False,
-	'link': '#0035c7',
-	'sidebar_header': '#c70036',
-	'sidebar_link': '#0035c7',
-	'show_related': True,
-	'show_relbars': True
+	# To get previous/next buttons at the top and the bottom:
+	'prev_next_buttons_location': 'both'
 }
 
 # Add any paths that contain custom static files (such as style sheets) here,
@@ -148,6 +143,9 @@ html_theme_options = {
 # so a file named "default.css" will overwrite the builtin "default.css".
 html_static_path = ['_static']
 
+# Overwrite theme to fit Debian colors
+html_css_files = ['debian.css']
+
 html_js_files = ['switchers.js']
 
 # Hide “Created using Sphinx” in the HTML footer
-- 
2.39.2

diff --git a/parts/7release-notes b/parts/7release-notes
index c1a74c9..a700b71 100755
--- a/parts/7release-notes
+++ b/parts/7release-notes
@@ -122,6 +122,8 @@ for page in $pagepattern; do
 			if [ &qu

Bug#877337: single-page html of debian-policy to be revived?

[Holger Wansing]

Hi,

Sean Whitton  wrote (Sun, 14 Apr 2024 12:27:34 +0800):
> On Thu 11 Apr 2024 at 08:32am GMT, Holger Levsen wrote:
> 
> > On Thu, Apr 11, 2024 at 09:18:06AM +0200, Thomas Lange wrote:
> >> A single page html may be an additional option but there's already the
> >> single page txt version and the PDF. That's sufficient and I see no
> >> need in providing more formats of this manual.
> >>
> >> Therefore we can close this and I will close 877337.
> >
> > fwiw, I disagree with this conclusion. single page txt and pdf versions
> > are no replacements for single page html.
> 
> I agree, and still think we should be publishing the single page version.

1.
Currently, the package does not ship this version. So this would have to
be re-added there.

2.
There are pro's and con's for both the single-page and multi-page variants.
Thus the only possible way IMO is to ship both via www.d.o.
The developers-refererence also ships both already, so it would be consistent 
there.
To make the existing mechanism work, which finds both variants on the
web mirrors via webwml, the single-page html file needs to be named
debian-policy.html:
https://salsa.debian.org/webmaster-team/webwml/-/blob/master/english/doc/devel-manuals.defs?ref_type=heads
That needs to be dealed with in the package, just renaming the file does not 
work, since it would break all the internal links.
(Don't know how it worked in the past on the website with the file being named 
policy-1.html though.)

3.
There were several bugs (e.g. #873456, #876075, #879048) with the single-page
html version. Are they known to be solved now?
Sphinx has received much development in the past 7 years, so there may be a
chance to have them fixed ... (?)
To get an idea of where we stand, I have built latest version of debian-policy
with re-activated singlehtml variant (build via sbuild, so with latest Sphinx
version), made the copy-and-rename dance which happens on wolkenstein for 
publication on www.d.o and pushed the result at
https://people.debian.org/~holgerw/debian-policy-with-singlehtml/

The multi-page html is found via
https://people.debian.org/~holgerw/debian-policy-with-singlehtml/debian-policy/index.html

while single-page html is at
https://people.debian.org/~holgerw/debian-policy-with-singlehtml/debian-policy/policy-1.html


Could the Policy Editors team check, if everything is fine now, and if 
this should be published again?
At least there is still an issue with the footnotes, there are 16 occurrences
of #id1 for example... (search for "[1]" in policy-1.html).


So long
Holger


-- 
Holger Wansing 
PGP-Fingerprint: 496A C6E8 1442 4B34 8508  3529 59F1 87CA 156E B076

Bug#1053549: Create a Debian theme for documentation based in Sphinx (reStructuredText)

[Holger Wansing]

Hi James,

Am 11. April 2024 23:52:52 MESZ schrieb James Addison :
>Hi Holger,
>
>On Sun, 7 Apr 2024 13:00:43 +0200, Holger wrote:
>> The only thing which is not working currently, is the search functionality,
>> but since that's not theme-specific I guess (please correct me, if I'm
>> wrong), I close this bug.
>
>The theme looks great, and I agree with closing this bug.  However, so that
>we don't overlook another potential python3-sphinx bug: could you report the
>problem that you encountered?  (I contribute to upstream and may be able to
>help with investigating that)

It's not a bug in sphinx or something like that.
The issue was in the build process for the website, what lead to some missing 
files in the manuals' tree (javascript script files and the searchindex.js).

Everything fine for now.

I'm currently working on switching the Debian release-notes to the new theme, 
and that might bring some issues, since the release-notes have translations as 
well (this was not the case for the debian-policy).

So maybe I come back to you in such case, if that's ok?


Thanks
Holger


-- 
Sent from /e/ OS on Fairphone3

Bug#872944: #872944 www.debian.org: Remove JavaScript from Policy Manual published on web mirrors

[Holger Wansing]

Hi,

Bill Allombert  wrote (Wed, 10 Apr 2024 
22:24:20 +0200):
> On Wed, Apr 10, 2024 at 09:33:50PM +0200, Holger Wansing wrote:
> > Hello www team and debian-policy editor team,
> > 
> > Note: apparently we have no alternative beside js, if we want full-text 
> > search for html output (single-page html could be a possible way, but 
> > that output format has been disabled due to various other issues).
> 
> Sorry, but why is this so hard to generate a single-page html ?
> debiandoc could do it. Using the browser intra-page search is always much
> easier/faster that using a search box.

I did not go deeper into this scenario, I just found 
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=877337
which includes a forward-backword-forward dance switching multiple
times between multi-page and single-page html variant requests.


Holger


-- 
Holger Wansing 
PGP-Fingerprint: 496A C6E8 1442 4B34 8508  3529 59F1 87CA 156E B076

Bug#872944: #872944 www.debian.org: Remove JavaScript from Policy Manual published on web mirrors

[Holger Wansing]

Hello www team and debian-policy editor team,


in-line with activating the new html theme on our website I also
worked on the javascript front:

to make the html theme work on small screens (smartphones) the readthedocs.org
theme relies on javascript functionality, to display a sidebar with the table
of content only, when the device is in landscape direction resp. when the 
burger button is pressed.

The second javascript functionality is the full-text search.

I made all needed changings, to get the above functions work and they are doing 
fine now. See 

Please note, that I made use of javascript by intend, despite of this bug 
requesting to remove all js functionality.
This is because I wanted to find out,  what we need (aka which javascript 
packages) to make all the above mentioned functions work. 
Since I lack the skills to value this simply by studying source code and 
reading documentation, I had to test this in live to be sure.

The outcome of this is:
we need content of the javascript packages "libjs-sphinxdoc" and "libjs-jquery" 
existing in the manuals' path, to accomplish the above goals.

We need to decide now, if we want these functionality, when they require 
those javascript packages. 
Or if we skip such functionality.

Note: apparently we have no alternative beside js, if we want full-text 
search for html output (single-page html could be a possible way, but 
that output format has been disabled due to various other issues).

And being able to show/hide the sidebar on smartphones is a great benefit
when screen size is limited.


There are requests to not use js, but it has also been mentioned, that it
may be worth it enabling js, because of the relatively reduced amount of js 
use in sphinxdoc / jquery.
Note: I'm lacking skills to inspect source code, which other functions are
integrated in the doctools.js / jquery.js / searchtools.js / sphinx-highlight.js
scripts resp. what the functions I find there are doing exactly! 
Maybe someone can make a statement here?

I would like to mention another point:
it's a Browser functionality for decades to have the possibility to disable
use of JavaScript. So people who want to avoid any risk due to js, can or
will most probably have JavaScript disabled in the Browser settings anyway.


Please note, that this decision is not only for debian-policy, but for
all sphinx-based manuals on Debian website.
(I hope we don't make different decisions on this question for the 
various manuals we have. That would make the implentation once again
more difficult.)



What should be done now?


Holger

Bug#987943: www.debian.org: Developers Reference: Sphinx search non-functional: searchindex.js missing

[Holger Wansing]

Hi,

Holger Wansing  wrote (Sat, 25 Nov 2023 12:43:24 +0100):
> In the meantime things have evolved, Sphinx has changed its way to
> deal with this; see 
> <https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=872944#74>
> 
> Thus, the current developers-reference built on a bookworm or later system
> leads to a output, where the search is working.
> Can be viewed at 
> <https://people.debian.org/~holgerw/sphinx-theme-for-debian/alabaster/developers-reference/>
> (also with a different html theme, BTW)
> 
> 
> So, when wolkenstein gets updates to bookworm (currently on bullseye)
> it will just, I guess.

Sorry, the above was complete nonsens, since for Developers Reference on the 
website we use the binary Debian package as a basis, which is built by
buildds, so on unstable. Thus the Sphinx version on wolkenstein is completely 
irrelevant.

I mixed that up with the release-notes, which I have worked on to migrate to
Sphinx: since there is no such package like 'release-notes' in the archive,
they in fact need to be built from scratch on wolkenstein.

So ...

$ time_machine start target=submitting-date

... we are back to the beginning:

Stefano Rivera  wrote:
> Sphinx search is broken on the developers reference:
> https://www.debian.org/doc/manuals/developers-reference/searchindex.js
> is 404.

Note: I'm working on debian-policy now, which has also switched to Sphinx;
as debian-policy shows the same problem, I think it's a systematic issue and
thus a solution for this will work for other sphinx-based manuals as well
(hopefully).

First, I focused on the symlinks to several .js scripts in _static, which point
to not existing targets. That has been mentioned at several places, and drawed
my attention.
After several attempts I have all those scripts existing now on the relevant 
place at https://www.debian.org/doc/debian-policy/_static/,
however the search is still not working :-((

But then --- guess what: the subject says it all:
"searchindex.js is missing" !

Indeed, that file is existing here after a local build of the package, but
is missing on our webserver.
That's because the 7doc script in webmaster's cron repo (to push /doc content on
the website) does only process html files in the root directoriy of the manual, 
no .js files.

I have prepared a build of debian-policy with all needed javascript scripts
and that searchindex.js file at
https://people.debian.org/~holgerw/new-rtd-sphinx-theme-for-debian/debian-policy/debian-policy/

Everything works fine there as far a I see (with a desktop firefox and brave
browser, as well as with the mobile versions of those browsers on my 
smartphone).
Feel free to test with more browsers/platforms/whatever.

I guess I will need to trim the 7doc script once again - h ...


So long
Holger


-- 
Holger Wansing 
PGP-Fingerprint: 496A C6E8 1442 4B34 8508  3529 59F1 87CA 156E B076

Bug#1064593: issue with Debian-style html theme for sphinx-based documents

[Holger Wansing]

Hi,

Holger Wansing  wrote (Tue, 2 Apr 2024 14:47:12 +0200):
> We need a separate copy of 3 packages in our www build tree on
> wolkenstein and all www static mirrors (simply let DSA install those
> packages on the machines will not work).
> And every sphinx-based manual needs relative symlinks in its tree, pointing
> to the above packages' content.
> The 1ftpfiles and 7doc scripts, which need to be adapted for that, and
> also the situation on the www mirrors is getting more complex, so I'm unsure 
> if we want this.
> See my patch.
> 
> On the other side, I don't see any other solution apart from developing
> a new theme.

Since there were no objections, I pushed that yesterday (+ one additional
change was needed), and that works now.


Holger


-- 
Holger Wansing 
PGP-Fingerprint: 496A C6E8 1442 4B34 8508  3529 59F1 87CA 156E B076

Bug#1064593: issue with Debian-style html theme for sphinx-based documents

[Holger Wansing]

Control: reassign 1064593 www.debian.org


Hi all,

Sean Whitton  wrote (Tue, 02 Apr 2024 10:11:39 +0800):
> Hello,
> 
> On Mon 01 Apr 2024 at 02:50pm +02, Holger Wansing wrote:
> 
> > I now tend to switch to another approach (also proposed similarly by Adam):
> >
> > instead of relying on the rtd-theme package in the default install path of 
> > the
> > package installed by DSA, I will use the infrastructure in 1ftpfiles and
> > 7doc of webmaster's cron repo, to (always) fetch the latest version of that
> > package (and two more packages, which the former depends on: 
> > fonts-font-awesome
> > and fonts-lato, to get the needed fonts) and unpack+copy them into
> > a dedicated path inside the www build tree.
> >
> > That path will be synced to the static www mirrors, and we can symlink
> > to it from the manuals.
> > (And the content of that path will automatically be kept up-to-date on
> > the unstable version of packages, so we don't get outdated/orphaned
> > copies of that packages in the isolated path.)
> > I want the unstable version of that packages here, since they need to
> > incorporate with the unstable version of the different manuals (like
> > debian-policy), and those packages are built by buildd, so unstable.
> >
> > How does that sound in the light of Debian guidelines and best practice?
> >
> > Is it ok, to have such "isolated copies" of packages as described above?
> >
> > I have not much experience in similar things, so I would like to get
> > some comments here, please.
> 
> I mean, it seems okay to me, but it's up to the web team really.

Yeah, that makes we aware of that this bug is now assigned to the wrong
package (this is no longer an issue on debian-policy side, but on
www.debian.org). 

Therefore, web team is most probably not aware at all of this specific issue.
So, I'm reassigning this bug to www.debian.org now.
And also debian-doc in CC, since in the past the doc/manuals part of
the website was somehow under responsibility of -doc people IIRC.



@web + doc teams:
We have (after more than 5 years) a new Debian-style html theme for 
sphinx-based 
documents, created by Stéphane Blondon based on a readthedocs.org theme.
It looks really good, and a preview of debian-policy with this theme can be 
seen here:
https://people.debian.org/~holgerw/new-rtd-sphinx-theme-for-debian/debian-policy/debian-policy/

However, getting this theme to work on the Debian website became more and more 
of a challenge these days/weeks.
An issue came up, which can be seen at Debian's website:
https://www.debian.org/doc/debian-policy/
The html layout is completely broken, because the theme relys on files
provided by the sphinx-rtd-theme-common package, which are not there on
the www mirrors.
Getting that files correctly on the mirrors occured to become difficult, sadly.

You can find a current summary of this issue at
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1064593#125

This comes down to one more adaption of the 1ftpfiles / 7doc scripts
in webmaster's cron repo.
Attached is the latest version of my patch, to get this going.

It works so far, but I wonder if this is the way we want to go.
There is a significant amount of things, which need to work correctly to
make this new theme appear correctly on Debian's website:

We need a separate copy of 3 packages in our www build tree on
wolkenstein and all www static mirrors (simply let DSA install those
packages on the machines will not work).
And every sphinx-based manual needs relative symlinks in its tree, pointing
to the above packages' content.
The 1ftpfiles and 7doc scripts, which need to be adapted for that, and
also the situation on the www mirrors is getting more complex, so I'm unsure 
if we want this.
See my patch.

On the other side, I don't see any other solution apart from developing
a new theme.


Comments?


Holger


-- 
Holger Wansing 
PGP-Fingerprint: 496A C6E8 1442 4B34 8508  3529 59F1 87CA 156E B076
diff --git a/parts/1ftpfiles b/parts/1ftpfiles
index 3a2d953..3079131 100755
--- a/parts/1ftpfiles
+++ b/parts/1ftpfiles
@@ -72,6 +72,11 @@ $WGET -O - $httpurlamd64 | xzcat >Packages-amd64
 
 httpurlrepo="http://${ftpsite}/debian;
 
+# readthedocs.org html theme files and related fonts
+getdeb all sphinx-rtd-theme-common
+getdeb all fonts-font-awesome
+getdeb all fonts-lato
+
 # many language specific binary packages (arch=all)
 getdebs aptitude
 getdebs debian-faq
diff --git a/parts/7doc b/parts/7doc
index b079aea..c2ff284 100755
--- a/parts/7doc
+++ b/parts/7doc
@@ -341,6 +341,39 @@ if [ "$lang" = "en" ]; then
 fi
 }
 
+#
+
+place_symlinks_to_theme_files()
+# To make the html theme (which is based on a readthedocs.org theme) for
+# sphinx-base

Bug#1064593: dh_sphinxdoc: replaces files provided by read-the-doc theme by empty symlinks

[Holger Wansing]

Hi,

Sean Whitton  wrote (Thu, 28 Mar 2024 09:48:51 +0800):
> Many thanks all for working on this, especially you Holger for this
> scripting work.  So, we're waiting in DSA and then on your script
> changes, and it'll work again.

DSA (adsb) did install the python3-sphinx-rtd-theme package on the www static 
mirrors (thanks Adam for the quick reaction !!!), and I pushed my changings 
to the 7doc script, but reality has proven me wrong, sadly:

The idea was, to have absolute symlinks from inside the manuals directories
to /usr/share/sphinx_rtd_theme/static/... and all looks fine on wolkenstein,
but those symlinks fail to get synced to the www static mirrors, because of
rsync's "--safe-links" option:

--safe-links ignore symlinks that point outside the tree

Thus, the debian-policy is still broken on our website, as before.


I now tend to switch to another approach (also proposed similarly by Adam):

instead of relying on the rtd-theme package in the default install path of the
package installed by DSA, I will use the infrastructure in 1ftpfiles and 
7doc of webmaster's cron repo, to (always) fetch the latest version of that 
package (and two more packages, which the former depends on: fonts-font-awesome
and fonts-lato, to get the needed fonts) and unpack+copy them into
a dedicated path inside the www build tree.

That path will be synced to the static www mirrors, and we can symlink
to it from the manuals.
(And the content of that path will automatically be kept up-to-date on
the unstable version of packages, so we don't get outdated/orphaned
copies of that packages in the isolated path.)
I want the unstable version of that packages here, since they need to
incorporate with the unstable version of the different manuals (like
debian-policy), and those packages are built by buildd, so unstable.

How does that sound in the light of Debian guidelines and best practice?

Is it ok, to have such "isolated copies" of packages as described above?

I have not much experience in similar things, so I would like to get
some comments here, please.

Or do people prefer a complete different way, like using another theme
or whatever? (since this thing is getting bigger and bigger currently)

(Please keep in mind that this is not only for debian-policy, but in the
long term all sphinx-based manuals are supposed to follow the path 
discussed here.)

I already proposed to switch away from dh_sphinxdoc, to completely get rid 
of this symlink issue, but someone mentioned various privacy issues as a
contra argument...



Patch attached for the first part (to get above mentioned packages
in the www build path) - just posted for reference here.
(Second part - to point the debian-policy manual to that path - will
follow in another round.)


Holger



-- 
Holger Wansing 
PGP-Fingerprint: 496A C6E8 1442 4B34 8508  3529 59F1 87CA 156E B076
diff --git a/parts/1ftpfiles b/parts/1ftpfiles
index 3a2d953..3079131 100755
--- a/parts/1ftpfiles
+++ b/parts/1ftpfiles
@@ -72,6 +72,11 @@ $WGET -O - $httpurlamd64 | xzcat >Packages-amd64
 
 httpurlrepo="http://${ftpsite}/debian;
 
+# readthedocs.org html theme files and related fonts
+getdeb all sphinx-rtd-theme-common
+getdeb all fonts-font-awesome
+getdeb all fonts-lato
+
 # many language specific binary packages (arch=all)
 getdebs aptitude
 getdebs debian-faq
diff --git a/parts/7doc b/parts/7doc
index 6998512..47e076e 100755
--- a/parts/7doc
+++ b/parts/7doc
@@ -428,6 +428,45 @@ echo -n "Installing documents:" >> $webdocdir/build.log
 # We only have sid now
 dist=sid
 
+# readthedocs.org html theme files and related fonts.
+# We need those files inside the www.d.o build tree on wolkenstein, because
+# the manuals will have symlinks pointing to those files, and syncing such
+# symlinks to the static www mirrors fails, when they point outside of the
+# tree (because of rsync's "--safe-links" option).
+# Therefore, we cannot simply have the packages installed by DSA on
+# wolkenstein, but we need an own copy inside the tree (in
+# www/doc/html-theme).
+# Since the manuals here are built on buildds and therefore are based on
+# unstable, I want to use the unstable version of the following packages
+# as well.
+unpack sphinx-rtd-theme-common
+   for themefilecss in usr/share/sphinx_rtd_theme/static/css/* ; do
+	mkdirp $webdocdir/html-theme/sphinx_rtd_theme/static/css
+	cp -rf $themefilecss $webdocdir/html-theme/sphinx_rtd_theme/static/css
+   done
+   for themefilefonts in usr/share/sphinx_rtd_theme/static/fonts/* ; do
+	mkdirp $webdocdir/html-theme/sphinx_rtd_theme/static/fonts
+	cp -rf $themefilefonts $webdocdir/html-theme/sphinx_rtd_theme/static/fonts
+   done
+unpack fonts-font-awesome
+   for fontfileawesome1 in usr/share/fonts-font-awesome/fonts/* ; do
+	mkdirp $webdocdir/html-theme/fonts-font-awesome/fonts
+	cp -rf $fontfileawesome1 $webdocdir/html-theme/fonts-font-awesome/fonts
+   done
+   for fontfileaw

Bug#1064593: Bug#1066967: Bug#1064593: Bug#1066967: dh_sphinxdoc: replaces files provided by read-the-doc theme by empty symlinks

[Holger Wansing]

Hi,

Dmitry Shachnev  wrote (Fri, 22 Mar 2024 18:46:25 +0300):
> On Fri, Mar 22, 2024 at 03:30:55PM +0100, Holger Wansing wrote:
> > Ok, I see.
> > So, we will need to get sphinx-rtd-theme-common installed on all debian.org
> > website mirrors, and it will just work (?) ...
> 
> From your earlier message it seemed to me like you are using the build
> tree in your deploy process, not the built package.
> 
> That is why I suggested not running dh_sphinxdoc, however my suggestion
> applied only to your deploy procedure. The package which is being uploaded
> to Debian archive should still use dh_sphinxdoc.
> 
> If you are using the built package and installing it on the remote server,
> then yes, install sphinx-rtd-theme-common and you should be good.

While working on adapting the parts/7doc script (from Debian Webmaster
Team's 'cron' repo), I realized that this is not going to work out of the
box: while the concept of the symlinks mentioned above is working fine,
when the debian-policy document is installed on a machine as usual
(means it recides in the same path as in the binary deb package, aka
/usr/share/doc/debian-policy/policy.html), we have the docs for the website
on the debian.org website machine in another path. That is in
/srv/www.debian.org/www/doc/debian-policy/.

That means the (relative) symlinks will not resolve!
Therefore I think the best solution here is, to change the relative
symlinks into absolute ones, on the debian.org website machine.

I have worked out the needed changes for cron/parts/7doc to deal with all
this (it works fine here locally). The debian-policy package could stay
unchanged.
I attach the patch here just for reference; will apply it, as soon as
sphinx-rtd-theme-common gets installed on wolkenstein
(working on a bugreport to DSA to get this done).

Closing #1066967 against sphinx-common/dh_sphinxdoc now.
Thanks python people for your help!

> Actually, I would move ${sphinxdoc:Depends} from Recommends to Depends,
> because the documentation is mostly unusable without the static files.

Ok. I will leave this mostly to Debian Policy maintainers.



Greetings
Holger

-- 
Holger Wansing 
PGP-Fingerprint: 496A C6E8 1442 4B34 8508  3529 59F1 87CA 156E B076
diff --git a/parts/7doc b/parts/7doc
index b079aea..5a358d7 100755
--- a/parts/7doc
+++ b/parts/7doc
@@ -260,22 +260,24 @@ if [ "$lang" = "en" ]; then
 			install -p -m 664 `readlink -f $page` $destdir/Common_Content/images/$(basename $page)
 		fi
 	done
 fi
 }
 
 #
 
 mvhtml_sphinx()
 {
-# Copy of mvhtml(), modified so it copies the _images and _static subfolders too
-# This is needed by debian-policy since they moved to reStructuredText and Sphinx
+# Copy of mvhtml(), modified so it copies the _images, _sources, _static, _static/css
+# and _static/fonts subfolders too.
+# This is needed by some manuals which moved to reStructuredText and Sphinx
+# (like debian-policy and developers-reference) and use an html theme from read-the-docs.
 # This is probably uncomplete, since the _static folder contains symlinks to
 # some javascript that probably will not work.
 
 namedest=$1# destdir directory:  maint-guide
 basedir=$2 # binary package data dir.: usr/share/doc/maint-guide-fr/html
 addlang=${3:-NO} # $lang in filename: NO | ADD | YES
  # NO:  without $lang and leave it so
  # ADD: without $lang and add it (make link for en) (internal URL conversion)
  # YES: with$lang and leave it so (make link for en)
 lang=${4:-en}  # language name: en (default), fr, ...
@@ -317,20 +319,36 @@ for page in $pagepattern; do
 done
 
 if [ "$lang" = "en" ]; then
 	pagepattern="$basedir/_static/*"
 	for page in $pagepattern; do
 		if [ -f "`readlink -f $page`" ]; then
 			mkdirp $destdir/_static
 			install -p -m 664 `readlink -f $page` $destdir/_static/$(basename $page)
 		fi
 	done
+	pagepattern="$basedir/_static/css/*"
+	for page in $pagepattern; do
+		if [ -d "$basedir/_static/css" ]; then
+	# Replace all existing relative symlinks in css by absolute symlinks to the correct place.
+			mkdirp $destdir/_static/css
+			ln -sf /usr/share/sphinx_rtd_theme/static/css/$(basename $page) $destdir/_static/css/$(basename $page)
+		fi
+	done
+	pagepattern="$basedir/_static/fonts/*"
+	for page in $pagepattern; do
+		if [ -d "$basedir/_static/fonts" ]; then
+	# Replace all existing relative symlinks in fonts by absolute symlinks to the correct place.
+			mkdirp $destdir/_static/fonts
+			ln -sf /usr/share/sphinx_rtd_theme/static/fonts/$(basename $page) $destdir/_static/fonts/$(basename $page)
+		fi
+	done
 	pagepattern="$basedir/_images/*"
 	for page in $pagepattern ; do
 		if [ -f "`readlink -f $page`" ]; then
 			mkdirp $destdir/_images
 			install -p -m 664 `readlink -f $page` $destdir/_images/$(basename $page)
 		fi
 	done
 pagepattern="$basedir/_sources/*"
 for page in $pagepattern ; do
 if [ -f "`readlink -f $page`" ]; then

Bug#1064593: Bug#1066967: Bug#1064593: Bug#1066967: dh_sphinxdoc: replaces files provided by read-the-doc theme by empty symlinks

[Holger Wansing]

Hi,

Dmitry Shachnev  wrote (Fri, 22 Mar 2024 16:04:14 +0300):
> On Fri, Mar 22, 2024 at 01:46:48PM +0100, Holger Wansing wrote:
> > [...]
> > Anyway, the symlink points to some path inside the package build path, here:
> > /srv/debian-policy/debian-policy-4.6.2.1/debian/debian-policy/usr/share/sphinx_rtd_theme_static/css/theme.css
> > 
> > and that path does not exist.
> > Same in the debian-policy binary package.
> 
> This is expected. The path in the build tree is relative in a way that when
> a package is built and installed, it becomes working.

Ok, I see.
So, we will need to get sphinx-rtd-theme-common installed on all debian.org
website mirrors, and it will just work (?) ...

> The symlink is generated relative per Policy 10.5. And I think that even if
> dh_sphinxdoc generated it as absolute, dh_link would later change it to
> relative.
> 
> If you are trying to rely on something that is in the build directory, you
> have to turn relative symlinks into absolute ones on your own. Or just don't
> call dh_sphinxdoc, then you will get normal files.

... or we switch away from dh_sphinxdoc.
But there was already a hint, why this is a bad idea.
Will need to be evaluated...



Thanks for your time, guys!

Holger


-- 
Holger Wansing 
PGP-Fingerprint: 496A C6E8 1442 4B34 8508  3529 59F1 87CA 156E B076

Bug#1064593: Bug#1066967: dh_sphinxdoc: replaces files provided by read-the-doc theme by empty symlinks

[Holger Wansing]

Hi,

Andrey Rakhmatullin  wrote (Fri, 22 Mar 2024 15:50:26 +0500):
> On Fri, Mar 22, 2024 at 11:29:11AM +0100, Holger Wansing wrote:
> > > I cannot reproduce this. I downloaded debian-policy source package and 
> > > built
> > > it in an up-to-date sid chroot. And the built package has this:
> > > 
> > >   $ dpkg-deb -c debian-policy_4.6.2.1_all.deb | grep theme.css
> > >   lrwxrwxrwx root/root 0 2024-02-24 15:39 
> > > ./usr/share/doc/debian-policy/policy.html/_static/css/theme.css -> 
> > > ../../../../../sphinx_rtd_theme/static/css/theme.css
> > 
> > But above output shows a filesize of 0B.
> > Shouldn't that be something different?
> Not for symlinks.

Ok.


> > Has ./usr/share/doc/debian-policy/policy.html/_static/css/theme.css any
> > useful content, when you open it?
> It's a symlink, it can't have content.
> It's target does have content, as shown in the quote below:
> 
> > > So, it is a symlink, not an empty file. When resolving the relative path,
> > > I get /usr/share/sphinx_rtd_theme/static/css/theme.css, and that file
> > > exists in sphinx-rtd-theme-common and is non-empty.
> 
> > if you open that theme.css file in the debian/debian-policy build path,
> > does it have any content?
> :-/
> 
> > Maybe it was bad wording, when I wrote 
> > "replaces files provided by read-the-doc theme by empty symlinks" in the 
> > subject of this bug.
> > Probably "symlinks pointing to a not-existing file" is more correct?
> To which non-existent files? Are they non-existent only when you don't
> have sphinx-rtd-theme-common installed?

Sure.

> > I don't know where's the problem in detail, I only see that in the
> > debian-policy binary package that file is empty, and therefore the html
> > layout is broken.
> It's not empty, it's a symlink that points to a non-existent (on your
> system) file.
> 
> > BTW: the same counts for all the symlinks under _static/fonts/:
> > 
> > holgerw@t520:~/debian-policy$ ls -la 
> > policy/debian/debian-policy/usr/share/doc/debian-policy/policy.html/_static/fonts/
> > total 64
> > drwxr-xr-x 2 holgerw holgerw 4096 Mar 22 11:17 .
> > drwxr-xr-x 5 holgerw holgerw 4096 Mar 22 11:17 ..
> > lrwxrwxrwx 1 holgerw holgerw   68 Mar 22 11:17 fontawesome-webfont.eot -> 
> > ../../../../../sphinx_rtd_theme/static/fonts/fontawesome-webfont.eot
> > lrwxrwxrwx 1 holgerw holgerw   68 Mar 22 11:17 fontawesome-webfont.svg -> 
> > ../../../../../sphinx_rtd_theme/static/fonts/fontawesome-webfont.svg
> > lrwxrwxrwx 1 holgerw holgerw   68 Mar 22 11:17 fontawesome-webfont.ttf -> 
> > ../../../../../sphinx_rtd_theme/static/fonts/fontawesome-webfont.ttf
> > lrwxrwxrwx 1 holgerw holgerw   69 Mar 22 11:17 fontawesome-webfont.woff -> 
> > ../../../../../sphinx_rtd_theme/static/fonts/fontawesome-webfont.woff
> > lrwxrwxrwx 1 holgerw holgerw   70 Mar 22 11:17 fontawesome-webfont.woff2 -> 
> > ../../../../../sphinx_rtd_theme/static/fonts/fontawesome-webfont.woff2
> > lrwxrwxrwx 1 holgerw holgerw   64 Mar 22 11:17 Lato-BoldItalic.ttf -> 
> > ../../../../../sphinx_rtd_theme/static/fonts/Lato-BoldItalic.ttf
> > lrwxrwxrwx 1 holgerw holgerw   66 Mar 22 11:17 Lato-BoldItalic.woff2 -> 
> > ../../../../../sphinx_rtd_theme/static/fonts/Lato-BoldItalic.woff2
> > lrwxrwxrwx 1 holgerw holgerw   58 Mar 22 11:17 Lato-Bold.ttf -> 
> > ../../../../../sphinx_rtd_theme/static/fonts/Lato-Bold.ttf
> > lrwxrwxrwx 1 holgerw holgerw   60 Mar 22 11:17 Lato-Bold.woff2 -> 
> > ../../../../../sphinx_rtd_theme/static/fonts/Lato-Bold.woff2
> > lrwxrwxrwx 1 holgerw holgerw   60 Mar 22 11:17 Lato-Italic.ttf -> 
> > ../../../../../sphinx_rtd_theme/static/fonts/Lato-Italic.ttf
> > lrwxrwxrwx 1 holgerw holgerw   62 Mar 22 11:17 Lato-Italic.woff2 -> 
> > ../../../../../sphinx_rtd_theme/static/fonts/Lato-Italic.woff2
> > lrwxrwxrwx 1 holgerw holgerw   61 Mar 22 11:17 Lato-Regular.ttf -> 
> > ../../../../../sphinx_rtd_theme/static/fonts/Lato-Regular.ttf
> > lrwxrwxrwx 1 holgerw holgerw   63 Mar 22 11:17 Lato-Regular.woff2 -> 
> > ../../../../../sphinx_rtd_theme/static/fonts/Lato-Regular.woff2
> > lrwxrwxrwx 1 holgerw holgerw   66 Mar 22 11:17 RobotoSlab-Bold.woff2 -> 
> > ../../../../../sphinx_rtd_theme/static/fonts/RobotoSlab-Bold.woff2
> > lrwxrwxrwx 1 holgerw holgerw   69 Mar 22 11:17 RobotoSlab-Regular.woff2 -> 
> > ../../../../../sphinx_rtd_theme/static/fonts/RobotoSlab-Regular.woff2
> > 
> > All those symlinks are pointing to a not-existing target here.
> Only because you don't have sphinx-rtd-theme-common ins

Bug#1064593: Bug#1066967: dh_sphinxdoc: replaces files provided by read-the-doc theme by empty symlinks

[Holger Wansing]

Hi Dmitry,

Dmitry Shachnev  wrote (Fri, 22 Mar 2024 00:35:57 +0300):
> I cannot reproduce this. I downloaded debian-policy source package and built
> it in an up-to-date sid chroot. And the built package has this:
> 
>   $ dpkg-deb -c debian-policy_4.6.2.1_all.deb | grep theme.css
>   lrwxrwxrwx root/root 0 2024-02-24 15:39 
> ./usr/share/doc/debian-policy/policy.html/_static/css/theme.css -> 
> ../../../../../sphinx_rtd_theme/static/css/theme.css

But above output shows a filesize of 0B.
Shouldn't that be something different?
Has ./usr/share/doc/debian-policy/policy.html/_static/css/theme.css any
useful content, when you open it?

> So, it is a symlink, not an empty file. When resolving the relative path,
> I get /usr/share/sphinx_rtd_theme/static/css/theme.css, and that file
> exists in sphinx-rtd-theme-common and is non-empty.

As above:
if you open that theme.css file in the debian/debian-policy build path,
does it have any content?

If I open it here, nano shows "New file" in the status bar at the bottom,
so the file does not exist.

Maybe it was bad wording, when I wrote 
"replaces files provided by read-the-doc theme by empty symlinks" in the 
subject of this bug.
Probably "symlinks pointing to a not-existing file" is more correct?

> The only issue I see is that sphinx-rtd-theme-common is in Recommends of
> debian-policy, not in Depends. But that is because ${sphinxdoc:Depends}
> was put there.
> 
> Am I doing something wrong?

I don't know where's the problem in detail, I only see that in the
debian-policy binary package that file is empty, and therefore the html
layout is broken.

BTW: the same counts for all the symlinks under _static/fonts/:

holgerw@t520:~/debian-policy$ ls -la 
policy/debian/debian-policy/usr/share/doc/debian-policy/policy.html/_static/fonts/
total 64
drwxr-xr-x 2 holgerw holgerw 4096 Mar 22 11:17 .
drwxr-xr-x 5 holgerw holgerw 4096 Mar 22 11:17 ..
lrwxrwxrwx 1 holgerw holgerw   68 Mar 22 11:17 fontawesome-webfont.eot -> 
../../../../../sphinx_rtd_theme/static/fonts/fontawesome-webfont.eot
lrwxrwxrwx 1 holgerw holgerw   68 Mar 22 11:17 fontawesome-webfont.svg -> 
../../../../../sphinx_rtd_theme/static/fonts/fontawesome-webfont.svg
lrwxrwxrwx 1 holgerw holgerw   68 Mar 22 11:17 fontawesome-webfont.ttf -> 
../../../../../sphinx_rtd_theme/static/fonts/fontawesome-webfont.ttf
lrwxrwxrwx 1 holgerw holgerw   69 Mar 22 11:17 fontawesome-webfont.woff -> 
../../../../../sphinx_rtd_theme/static/fonts/fontawesome-webfont.woff
lrwxrwxrwx 1 holgerw holgerw   70 Mar 22 11:17 fontawesome-webfont.woff2 -> 
../../../../../sphinx_rtd_theme/static/fonts/fontawesome-webfont.woff2
lrwxrwxrwx 1 holgerw holgerw   64 Mar 22 11:17 Lato-BoldItalic.ttf -> 
../../../../../sphinx_rtd_theme/static/fonts/Lato-BoldItalic.ttf
lrwxrwxrwx 1 holgerw holgerw   66 Mar 22 11:17 Lato-BoldItalic.woff2 -> 
../../../../../sphinx_rtd_theme/static/fonts/Lato-BoldItalic.woff2
lrwxrwxrwx 1 holgerw holgerw   58 Mar 22 11:17 Lato-Bold.ttf -> 
../../../../../sphinx_rtd_theme/static/fonts/Lato-Bold.ttf
lrwxrwxrwx 1 holgerw holgerw   60 Mar 22 11:17 Lato-Bold.woff2 -> 
../../../../../sphinx_rtd_theme/static/fonts/Lato-Bold.woff2
lrwxrwxrwx 1 holgerw holgerw   60 Mar 22 11:17 Lato-Italic.ttf -> 
../../../../../sphinx_rtd_theme/static/fonts/Lato-Italic.ttf
lrwxrwxrwx 1 holgerw holgerw   62 Mar 22 11:17 Lato-Italic.woff2 -> 
../../../../../sphinx_rtd_theme/static/fonts/Lato-Italic.woff2
lrwxrwxrwx 1 holgerw holgerw   61 Mar 22 11:17 Lato-Regular.ttf -> 
../../../../../sphinx_rtd_theme/static/fonts/Lato-Regular.ttf
lrwxrwxrwx 1 holgerw holgerw   63 Mar 22 11:17 Lato-Regular.woff2 -> 
../../../../../sphinx_rtd_theme/static/fonts/Lato-Regular.woff2
lrwxrwxrwx 1 holgerw holgerw   66 Mar 22 11:17 RobotoSlab-Bold.woff2 -> 
../../../../../sphinx_rtd_theme/static/fonts/RobotoSlab-Bold.woff2
lrwxrwxrwx 1 holgerw holgerw   69 Mar 22 11:17 RobotoSlab-Regular.woff2 -> 
../../../../../sphinx_rtd_theme/static/fonts/RobotoSlab-Regular.woff2

All those symlinks are pointing to a not-existing target here.



Holger



-- 
Holger Wansing 
PGP-Fingerprint: 496A C6E8 1442 4B34 8508  3529 59F1 87CA 156E B076

Bug#1064617: update password selection advice

[Holger Wansing]

Apparently we have reached something like a consensus on this topic, 
should we merge this then?



Any objections?


Holger


-- 
Sent from /e/ OS on Fairphone3

Bug#1064593: debian-policy: missing static resources for www.debian.org policy page

[Holger Wansing]

Hi,

James Addison  wrote (Fri, 15 Mar 2024 10:42:39 +):
> I'm not much of a perlmonger but this might be a problem somewhere in:
> 
>   
> https://sources.debian.org/src/sphinx/7.2.6-5/debian/dh-sphinxdoc/dh_sphinxdoc/?hl=409#L389-L413
> 
> When I modify that code to always follow the 'absolute link' path, I still
> get relative links to the theme.css file in the debian/ package build dirs.
> 
> (note: this function also exists in imagemagick-6-doc, so any problem/fix
> should not forget about that package too)

I filed 
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1066967
for this.


Holger


-- 
Holger Wansing 
PGP-Fingerprint: 496A C6E8 1442 4B34 8508  3529 59F1 87CA 156E B076

Bug#1066967: dh_sphinxdoc: replaces files provided by read-the-doc theme by empty symlinks

[Holger Wansing]

Package: sphinx-common
Severity: serious


Hi,

dh_sphinxdoc does not work well with read-the-doc theme, apparently.
Debian policy document has switched to sphinx_rtd_theme recently (see
https://salsa.debian.org/dbnpolicy/policy/-/commit/686622814018b5a121252b189d99c1968f332b78
 )

However, the built document has a completely broken html layout, because
many files under _static/ are empty (0B size), most noteably 
_static/css/theme.css.

If I replace 
dh $@ --with sphinxdoc
by
dh $@
(so do not use dh_sphinxdoc), I get a valid html file with the theme
in use.

More details on that topic can be found in 
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1064593

To get an idea of how it looks like, see
https://www.debian.org/doc/debian-policy/
(however, there is also an issue with rtd theme on debian.org, that's
why _static/css/ is completely missing there. That's an known issue,
but we need a valid document in the debian-policy binary package first,
to get the website problem fixed.)



So long
Holger


-- 
Holger Wansing 
PGP-Finterprint: 496A C6E8 1442 4B34 8508  3529 59F1 87CA 156E B076

Bug#1064593: debian-policy: missing static resources for www.debian.org policy page

[Holger Wansing]

Hi guys,

Stéphane Blondon  wrote (Mon, 4 Mar 2024 08:29:10 
+0100):
> Hello,
> 
> Le dim. 3 mars 2024 à 11:49, Holger Wansing  a écrit :
> > So, no problem with latest Sphinx version, it seems the integration in the
> > debian-policy package is the problem (aka debian/rules) ...
> 
> Thank you for the search.
> 
> I have two wild guesses based on broken symlink assumption:
> 
> 1. By dh_auto_install
> 
> buildd create symbolic links to the files (like theme.css) provided by
> python3-sphinx-rtd-theme:
> lrwxrwxrwx root/root 0 2024-02-24 12:39
> ./usr/share/doc/debian-policy/policy.html/_static/css/theme.css ->
> ../../../../../sphinx_rtd_theme/static/css/theme.css
> (found in the log file)
> 
> Then the target dh_auto_install in debian/rules from debian_policy
> moves files (line 15):
> mv debian/tmp/* debian/debian-policy/
> 
> The symlink is relative so it could be broken.

It appears to me that the target for that symlink 
(../../../../../sphinx_rtd_theme/static/css/theme.css) is not existing
and therefore we get an empty file.

I did some testing with debuild, and changed debian/rules (line 4) like

-   dh $@ --with sphinxdoc
+   dh $@

and that way I get a valid html document with the new theme working !!!

(That is something of a revert of
https://salsa.debian.org/dbnpolicy/policy/-/commit/528ad4d79a76690eeb0504fd6c094a88ddb9739d
 )

Please note that I did not check for any other differences in the package
created that way compared to the latest version in the archive (debdiff).
An sbuild run was successful that way as well.

Seems there is something wrong in the debhelper / dh_sphinxdoc world 
(or at least an incompatibility with read-the-doc themes) ...

But that's out of my skills

Applying above change could at least be a temporary way to get the policy
back in shape on the website ...


Holger



-- 
Holger Wansing 
PGP-Fingerprint: 496A C6E8 1442 4B34 8508  3529 59F1 87CA 156E B076

Bug#1064617: Passwords should not be changed frequently

[Holger Wansing]

Hi,

Am 8. März 2024 19:58:56 MEZ schrieb Philip Hands :
>
>IMO Having the 'password/passphrase' throughout makes it awkward to
>read, and actually we've got one place where it still just says
>password, and fixing that would make it slightly worse IMO.
>
>How about dropping the passphrase stuff?
>
>  
> https://salsa.debian.org/philh/user-setup/-/commit/7c8dd1bd9d5c8596e7b8f82a19a075e0a5572ed7

Well, the idea was, to mention that 'passphrase' thing one time in the dialog.

Now having it at all places is indeed not strictly an improvement.
Feel free to drop it.


Holger




-- 
Sent from /e/ OS on Fairphone3

Bug#1064617: Passwords should not be changed frequently

[Holger Wansing]

Hi,

Am 7. März 2024 08:50:25 MEZ schrieb Justin B Rye :
>Philip Hands wrote:
>>> Maybe instead of saying "use the system's initial user account to
>>> become root" it should say "allow the system's initial user account
>>> to gain administrative privileges"?  I'm not sure.  Oh, and we might
>>> even want to mention the word "superuser", or then again we might not.
>> 
>> I think Diederik's suggestion of using 'root' for the account and
>> 'super-user' for the privileges might be the way to go.
>
>Looking at what I end up with after another couple of rounds of
>fiddling with it I'm not sure if it's doing quite what you asked for,
>but you still might want it so here it is:
>
>-   Some account needs to have system administrative privileges. The
>-   password/passphrase for that account should be something that
>-   cannot be guessed.
>+   Some account needs to be available with administrative super-user
>+   privileges. The password/passphrase for that account should be
>+   something that cannot be guessed.
>.
>To allow direct password-based access via the 'root' account, you
>can set the password/passphrase for that account here.
>.
>-   Alternatively, you can lock root's password
>+   Alternatively, you can lock the root account's password
>by leaving this setting empty, and
>instead use the system's initial user account
>(which will be set up in the next step)
>-   to become root. This will be enabled for you
>-   by adding that user to the 'sudo' group.
>+   to gain administrative privileges. This will be enabled for you by
>+   adding that initial user to the 'sudo' group.
>.
>Note: what you type here will be hidden (unless you select to show it).

All the above looks like an improvement to me.


Holger


-- 
Sent from /e/ OS on Fairphone3

Bug#1064617: Passwords should not be changed frequently

[Holger Wansing]

Hi,

Am 5. März 2024 20:44:52 MEZ schrieb Philip Hands :
>BTW I don't know much about how the translation side of things works,
>but given that there are many ways of getting the fine detail of this to
>be incorrect in various ways, is there a standard method for adding
>hints for translators, and should that be done?

Such hints for translators can be added to the templates file, as in

They will then end up in translator's po files.


Do you have some specific sentence in mind, which deserves a
special hint?
I noticed that my English is not good enough to formulate such details.


Holger


-- 
Sent from /e/ OS on Fairphone3

Bug#1064617: Passwords should not be changed frequently

[Holger Wansing]

Hi all,

Am 5. März 2024 19:28:25 MEZ schrieb Cyril Brulebois :
>Philip Hands  (2024-03-05):
>> Cool, in that case I'll fix those two things and then use the result
>> for the MR[1], and if the openQA test runs look OK, will merge that.
>
>Only skimmed over it, but that looks sensible, thanks all.
>
>Is it worth getting d-l-english involved in a final review before
>getting that translated? Contrary to a lot of not-so-critical l10n
>material, that particular screen is crucial, and I'd hate it if we
>wasted translator efforts due to a missed typo or obvious improvement.

Good idea.

@d-l10n-english: hey guys, we would like to get a proposal reviewed, 
which aims to improve the root/user password screens in the installer.

Please find the related merge request at


There was some (more) discussion / various attempts on finding
the correct wording, most of which can be found in



Maybe we should have put d-l10n-english into the loop earlier, sorry for not
doing that.


Holger


-- 
Sent from /e/ OS on Fairphone3

Bug#1064617: Passwords should not be changed frequently

[Holger Wansing]

Hi,

Am 5. März 2024 15:01:21 MEZ schrieb Philip Hands :
>Here are my latest attempts:

"Be aware that that a ..."
doubled "that"

"... (unless you select to show it)"
missing fullstop.

Otherwise: looks good to me.


Holger



-- 
Sent from /e/ OS on Fairphone3

Bug#1064617: Passwords should not be changed frequently

[Holger Wansing]

Hi,

Diederik de Haas  wrote (Mon, 04 Mar 2024 15:57:10 
+0100):
> On Monday, 4 March 2024 10:43:59 CET Holger Wansing wrote:
> > >Regarding the password advice, I ended up concluding that it's pretty
> > >unlikely that anything we say at this point will have any effect on
> > >people's behaviour, but then I'm probably just an old cynic. Also, I
> > >failed when trying to come up with a wording which I was happy with,
> > >which is why I ended up discarding the advice entirely.
> > >
> > >If we want to keep the password advice in then I think what you wrote is
> > >(mostly) OK, although I think it implies that one should be choosing a
> > >single "password" (although, not a word in any normal sense), which
> > >could be argued to steer people away from the perfectly decent xkcd
> > >approach of using several dictionary words. Saying "Password or
> > >Passphrase" at least once would probably address that.
> > 
> > Ok, makes it a bit longer, but it could be worth it.
> 
> https://wiki.debian.org/Passwords doesn't exist (yet), but it's an easy to 
> remember URL and we'd have all the space we need to give proper advise?

Would need to check if that fits in the relevant screens (I want to avoid
having a scroll bar on that screens).


Holger

-- 
Holger Wansing 
PGP-Fingerprint: 496A C6E8 1442 4B34 8508  3529 59F1 87CA 156E B076

Bug#1064617: Passwords should not be changed frequently

[Holger Wansing]

Hi,

Holger Wansing  wrote (Mon, 04 Mar 2024 10:43:59 +0100):
> Hi,
> 
> Am 4. März 2024 06:17:31 MEZ schrieb Philip Hands :
> >I found that there were some phrases that I was avoiding for various
> >reasons, a couple of which I see you've used, so I'll say why I was avoiding
> >them and see if I have a persuasive argument for doing so.
> >
> >"allow/deny login/access as root":
> >
> >  The problem here is that not having a password for root only prevents
> >  one from getting direct access to root by using a password. Indirect
> >  access is still available via sudo, and direct access is still
> >  available via key bassed ssh.  I was also avoiding saying things like
> >  "disable the root account" for the same reason.
> >
> >  This is why I ended up with the phrasing:
> >
> > direct password-based logins to 'root'.
> 
> Ok, seems fair. I would change to that then.
> 
> >
> >"using the 'sudo' command":
> >
> >  This I was avoiding becuase it might give the impression that one MUST
> >  use sudo, whereas most people will actually get their root acces via a
> >  GUI prompting them for their own pasword (because it's checked that
> >  they're in the sudo group) when doing things like unlocking their
> >  network or printer settings. I thought it was worth mentining the
> >  'sudo' group explicitly because that gives something to search for if
> >  they want to find out more, but telling people they need to use the
> >  sudo command seemed like a step too far.
> 
> Correct so far. Maybe a bit more technical and therefore probably
> not the easiest choice for newbies, but I have no problem using that.
> 
> >Regarding the password advice, I ended up concluding that it's pretty
> >unlikely that anything we say at this point will have any effect on
> >people's behaviour, but then I'm probably just an old cynic. Also, I
> >failed when trying to come up with a wording which I was happy with,
> >which is why I ended up discarding the advice entirely.
> >
> >If we want to keep the password advice in then I think what you wrote is
> >(mostly) OK, although I think it implies that one should be choosing a
> >single "password" (although, not a word in any normal sense), which
> >could be argued to steer people away from the perfectly decent xkcd
> >approach of using several dictionary words. Saying "Password or
> >Passphrase" at least once would probably address that.
> 
> Ok, makes it a bit longer, but it could be worth it.
> 
> I will prepare a new patch with above.

Updated patch attached.

Holger


-- 
Holger Wansing 
PGP-Fingerprint: 496A C6E8 1442 4B34 8508  3529 59F1 87CA 156E B076
diff --git a/debian/user-setup-udeb.templates b/debian/user-setup-udeb.templates
index cdb6d78..437b9d7 100644
--- a/debian/user-setup-udeb.templates
+++ b/debian/user-setup-udeb.templates
@@ -33,22 +33,21 @@ _Description: Allow login as root?
 Template: passwd/root-password
 Type: password
 # :sl1:
-_Description: Root password:
- You need to set a password for 'root', the system administrative
- account. A malicious or unqualified user with root access can have
- disastrous results, so you should take care to choose a root password
- that is not easy to guess. It should not be a word found in dictionaries,
- or a word that could be easily associated with you.
+_Description: Root password/passphrase:
+ If you want to allow direct password-based login as root, you need to set a
+ password for 'root', the system administrative account now.
+ A malicious or unqualified user with root access can have
+ disastrous results, so you should take care to choose a root
+ password/passphrase that cannot be guessed. It should not be a word found in
+ dictionaries, or something that could be easily associated with you.
  .
- A good password will contain a mixture of letters, numbers and punctuation
- and should be changed at regular intervals.
+ You can also leave the password for root empty here, to disable the root
+ account; the system's initial user account (which will be set up in the next
+ step) will then be given the power to become root via 'sudo' (by adding it to
+ the 'sudo' group).
  .
- The root user should not have an empty password. If you leave this
- empty, the root account will be disabled and the system's initial user
- account will be given the power to become root using the "sudo"
- command.
- .
- Note that you will not be able to see the password as you type it.
+ Note that you will not be able to see the password as you type it (except if
+ you choose to show it in clear text).
 
 Template: passwd/root-password-again
 Type: password
@@ -109,9 +108,8 @@ _Description: Reserved username
 Template: pa

Bug#1064617: Passwords should not be changed frequently

[Holger Wansing]

Hi,

Am 4. März 2024 06:17:31 MEZ schrieb Philip Hands :
>I found that there were some phrases that I was avoiding for various
>reasons, a couple of which I see you've used, so I'll say why I was avoiding
>them and see if I have a persuasive argument for doing so.
>
>"allow/deny login/access as root":
>
>  The problem here is that not having a password for root only prevents
>  one from getting direct access to root by using a password. Indirect
>  access is still available via sudo, and direct access is still
>  available via key bassed ssh.  I was also avoiding saying things like
>  "disable the root account" for the same reason.
>
>  This is why I ended up with the phrasing:
>
> direct password-based logins to 'root'.

Ok, seems fair. I would change to that then.

>
>"using the 'sudo' command":
>
>  This I was avoiding becuase it might give the impression that one MUST
>  use sudo, whereas most people will actually get their root acces via a
>  GUI prompting them for their own pasword (because it's checked that
>  they're in the sudo group) when doing things like unlocking their
>  network or printer settings. I thought it was worth mentining the
>  'sudo' group explicitly because that gives something to search for if
>  they want to find out more, but telling people they need to use the
>  sudo command seemed like a step too far.

Correct so far. Maybe a bit more technical and therefore probably
not the easiest choice for newbies, but I have no problem using that.

>Regarding the password advice, I ended up concluding that it's pretty
>unlikely that anything we say at this point will have any effect on
>people's behaviour, but then I'm probably just an old cynic. Also, I
>failed when trying to come up with a wording which I was happy with,
>which is why I ended up discarding the advice entirely.
>
>If we want to keep the password advice in then I think what you wrote is
>(mostly) OK, although I think it implies that one should be choosing a
>single "password" (although, not a word in any normal sense), which
>could be argued to steer people away from the perfectly decent xkcd
>approach of using several dictionary words. Saying "Password or
>Passphrase" at least once would probably address that.

Ok, makes it a bit longer, but it could be worth it.

I will prepare a new patch with above.


Holger


-- 
Sent from /e/ OS on Fairphone3

Bug#1064593: debian-policy: missing static resources for www.debian.org policy page

[Holger Wansing]

Hi,

Stéphane Blondon  wrote (Tue, 27 Feb 2024 21:27:50 
+0100):
> Hello,
> 
> Le dim. 25 févr. 2024 à 14:24, Holger Wansing  a écrit :
> >
> > Hi,
> > Seems there is more than only one issue:
> >
> > 1.
> > In the binary package (debian-policy latest version) the above files and
> > directories are existing, but the files are all empty (0 B size).
> > However, in the previous version (4.6.2.0) the javascript .js files
> > are also empty (0 B), so that's most probably not the issue.
> > [...]
> > In a local build here, they are all fine, and the document is displayed
> > correctly. But that's build on bookworm, so sphinx version 5.3.0.
> > The binary packages built by buildd will get build on sphinx 7.2.x
> > I think, so maybe there is the difference?
> > Maybe we need some adaption for latest sphinx version?
> 
> 
> Sphinx Changelog (https://www.sphinx-doc.org/en/master/changes.html)
> shows several incompatibilities between 5.3 and 7 branches.
> Can we get the logs of the built of the package?
> 
> I will try to do some tests with Sphinx 7.2 in a virtualenv too.

I tested building it on a trixie system:
a build with just a 'make' in 'policy' dir is successful, the generated
html files are valid, with the new Debian theme.

So, no problem with latest Sphinx version, it seems the integration in the 
debian-policy package is the problem (aka debian/rules) ...


Holger



-- 
Holger Wansing 
PGP-Fingerprint: 496A C6E8 1442 4B34 8508  3529 59F1 87CA 156E B076

Bug#1064617: Passwords should not be changed frequently

[Holger Wansing]

Hi,

Am 2. März 2024 21:07:34 MEZ schrieb Philip Hands :
>
>This sentence is the thing that prompted me to change things in the
>first place, because it is not true. One does not _need_ to set a root
>password.

It should be understood as 
"If you want to enable login as root, you have to set a root password now."

And in expert mode it is in fact working this way:
At first, you are asked if you want to enable login as root. If you answer yes 
here, you are prompted to set a root password. 
And at that point it is indeed required to set a root password, since you 
chose to enable root login in the first question and the installer does not
allow an empty password for root.

To make it work in default install, we could change the question as
in above citation.

>I don't actually care very much whether we encourage sudo use. My
>wording ended up (after many variations) quite strongly encouraging it
>mostly as an antidote to the implication that comes from having a
>question dedicated to setting the root password, but I'd be happy with
>any wording that makes sure that people understand that both options are
>totally fine.

The sudo possibility is also mentioned:

'The root user should not have an empty password. If you leave this
empty, the root account will be disabled and the system's initial user
account will be given the power to become root using the "sudo"
command.'

I have rephrased that a bit, see below.

>The other thing that I was trying to ensure is that people are reassured
>that they'll get to specify a password that will get them root access even if
>they decide to leave the root password unset.  This is because I've seen
>people become quite uncertain about what to expect at this point in the
>install.
>
>I've found that it is not easy to come up with things that include much
>nuance about this, while still fitting in the space available, which is
>why I decided to try a more opinionated approach.
>
>One could soften what I wrote by replacing "generally recommended" with
>something like "often appropriate" -- how does that seem to people?

Your proposal too much focusses on the sudo way IMO.
We risk getting complains from people, who miss advise regarding the
enabled root login.

I have rephrased the dialog a bit, to make the sudo way more visible and
better understandable.

>One can of course tinker with this stuff indefinitely. I actually spent
>a fair amount of time wondering how best to describe not setting a root
>password for instance -- should one say "leave the password unset", "set
>an empty password", "enter no password", or something like "just hit
>"? (and does that last one actually apply to all the available
>UIs?).
>
>The same goes for how you say that the password is not going to get
>shown (unless you ask for it to be shown), which in the GTK UI gets
>characters replaced with dots, IIRC in the text UI its with asterisks,
>and I'd guess it just gets completely hidden in the speech install.

I think that's not much of a problem. People are used to the situation,
that passwords are not shown, but replaced by asterisks or similar.
And we have the checkbox for showing it in clear text, that should be
enough.


Updated patch attached.


Holger



diff --git a/debian/user-setup-udeb.templates b/debian/user-setup-udeb.templates
index cdb6d78..7393511 100644
--- a/debian/user-setup-udeb.templates
+++ b/debian/user-setup-udeb.templates
@@ -34,21 +34,19 @@ Template: passwd/root-password
 Type: password
 # :sl1:
 _Description: Root password:
- You need to set a password for 'root', the system administrative
- account. A malicious or unqualified user with root access can have
+ If you want to allow login as root, you need to set a password for 'root',
+ the system administrative account now.
+ A malicious or unqualified user with root access can have
  disastrous results, so you should take care to choose a root password
- that is not easy to guess. It should not be a word found in dictionaries,
- or a word that could be easily associated with you.
+ that cannot be guessed. It should not be a word found in dictionaries,
+ or something that could be easily associated with you.
  .
- A good password will contain a mixture of letters, numbers and punctuation
- and should be changed at regular intervals.
+ You can also leave the password for root empty here, to disable the root
+ account; the system's initial user account (which will be set up in the next
+ step) will then be given the power to become root using the "sudo" command.
  .
- The root user should not have an empty password. If you leave this
- empty, the root account will be disabled and the system's initial user
- account will be given the power to become root using the "sudo"
- command.
- .
- Note that you will not be able to see the password as you type it.
+ Note that you will not be able to see the password as you type it (except if
+ you choose to show it in clear text).
 
 Template: passwd/root-password-again
 Type: password

Bug#1064617: Passwords should not be changed frequently

[Holger Wansing]

Hi,

Philip Hands  wrote (Fri, 01 Mar 2024 06:46:27 +0100):
> If you want to make a constructive contribution, how about suggesting a
> wording that reflects the advice that you think would be most useful to
> the people that actually read the advice?

I would like to make a proposal, leaving the default setting as is 
(aka: default to an enabled root account, no sudo), with only some wording 
changings.

Patch attached.

What do you think?


Holger


-- 
Holger Wansing 
PGP-Fingerprint: 496A C6E8 1442 4B34 8508  3529 59F1 87CA 156E B076
diff --git a/debian/user-setup-udeb.templates b/debian/user-setup-udeb.templates
index cdb6d78..2715cfb 100644
--- a/debian/user-setup-udeb.templates
+++ b/debian/user-setup-udeb.templates
@@ -32,28 +32,26 @@ _Description: Allow login as root?
 
 Template: passwd/root-password
 Type: password
 # :sl1:
 _Description: Root password:
  You need to set a password for 'root', the system administrative
  account. A malicious or unqualified user with root access can have
  disastrous results, so you should take care to choose a root password
- that is not easy to guess. It should not be a word found in dictionaries,
+ that cannot be guessed. It should not be a word found in dictionaries,
  or a word that could be easily associated with you.
  .
- A good password will contain a mixture of letters, numbers and punctuation
- and should be changed at regular intervals.
- .
  The root user should not have an empty password. If you leave this
  empty, the root account will be disabled and the system's initial user
  account will be given the power to become root using the "sudo"
  command.
  .
- Note that you will not be able to see the password as you type it.
+ Note that you will not be able to see the password as you type it (except if
+ you choose to show it in clear text).
 
 Template: passwd/root-password-again
 Type: password
 # :sl1:
 _Description: Re-enter password to verify:
  Please enter the same root password again to verify that you have typed it
  correctly.
 
@@ -105,18 +103,17 @@ Type: error
 _Description: Reserved username
  The username you entered (${USERNAME}) is reserved for use by the system.
  Please select a different one.
 
 Template: passwd/user-password
 Type: password
 # :sl1:
 _Description: Choose a password for the new user:
- A good password will contain a mixture of letters, numbers and punctuation
- and should be changed at regular intervals.
+ Make sure to select a strong password, that cannot be guessed.
 
 Template: passwd/user-password-again
 Type: password
 # :sl1:
 _Description: Re-enter password to verify:
  Please enter the same user password again to verify you have typed it
  correctly.
 

Bug#1064617: Passwords should not be changed frequently

[Holger Wansing]

Hi,

Philip Hands  wrote (Thu, 29 Feb 2024 20:53:10 +0100):
> Depending upon whether we think it's worth using translators' time on
> this subject, we can then select one or both commits, and finally close
> these bugs.

I think it would be worth it to generate some work for translators here, yes.

> You can see my latest attempt here:
> 
>   https://openqa.debian.net/tests/238094#step/passwords/1
> 
> in which I'm recommending setting no password for root, which then gives
> the initial user 'sudo' membership[1].

What about the "Allow login as root?" question (only shown in expert mode),
which is asked directly before the above mentioned dialog?
(That's in user-setup-udeb.templates - line 25 ff.)

Maybe that needs some re-wording too?

Seems somewhat inconsistent now IMO:
if you say 'Yes' to 'Allow login as root' you get the next dialog allowing
the same choice again (or at least very similar): 
'It is possible [...] to lock the root acount ... If you leave the password
here unset, then this is what happens.'

Is that understandable for users?


Holger


-- 
Holger Wansing 
PGP-Fingerprint: 496A C6E8 1442 4B34 8508  3529 59F1 87CA 156E B076

Bug#1064593: debian-policy: missing static resources for www.debian.org policy page

[Holger Wansing]

Hi,

James Addison  wrote (Sun, 25 Feb 2024 11:05:06 +):
> On Sun, 25 Feb 2024 at 08:07, Sean Whitton  wrote:
> > ...
> > On Sun 25 Feb 2024 at 08:44am +01, Holger Wansing wrote:
> > > ...
> > > Am 24. Februar 2024 20:15:41 MEZ schrieb James Addison 
> > > :
> > >>
> > >>(this may relate closely to #915583)
> > >>
> > >>Some of the web resources referenced by the online[1] copy of the Debian 
> > >>policy
> > >>manual seem to return HTTP 404 responses at the moment, meaning that the
> > >>intended Sphinx CSS theming fails to apply.
> > >>
> > >>[1] - https://www.debian.org/doc/debian-policy/
> > >
> > > Hmm, locally built it's fine here ...
> > > ...
> > The new debian.css is there.  So, which file is it that's missing?
> 
> Thanks for checking - yep, the debian.css file does appear to be fine.
> The following paths (relative to the policy base) produce HTTP 404
> responses:
> 
>   * _static/css/theme.css
>   * _static/jquery.js
>   * _static/sphinx_highlight.js
>   * _static/js/theme.js

Seems there is more than only one issue:

1.
In the binary package (debian-policy latest version) the above files and 
directories are existing, but the files are all empty (0 B size).
However, in the previous version (4.6.2.0) the javascript .js files
are also empty (0 B), so that's most probably not the issue.
I remember we don't have full javascript functionality in our sphinx-based
manuals on debian.org for a longer time, search is not working for example. 
That's #1026446, #872944, #987943.

In a local build here, they are all fine, and the document is displayed
correctly. But that's build on bookworm, so sphinx version 5.3.0.
The binary packages built by buildd will get build on sphinx 7.2.x
I think, so maybe there is the difference?
Maybe we need some adaption for latest sphinx version?
   

2. 
The first file from above list _static/css/theme.css is likely to be
the point, since the html layout is completely broken.
That file is also empty in latest debian-policy binary package.
Since it is fine in local build here, also an issue with latest sphinx
version maybe ???
Or do we no longer need _static/css/theme.css, as we now have 
_static/debian.css ?


3.
Despite the fact, that the files from above are empty, there seems to be
another issue with debian.org website:
the subdirectories under _static are not existing on debian.org, as well as 
the files within of course (like _static/css/theme.css).
Apparently there is some more magic needed in webmaster-team's cron
https://salsa.debian.org/webmaster-team/cron/-/blob/master/parts/7doc?ref_type=heads#L319
to get such files copied over to debian.org during website build.

But first, we need to have a working version in the binary package,
since that's the basis for website build.


Holger



-- 
Holger Wansing 
PGP-Fingerprint: 496A C6E8 1442 4B34 8508  3529 59F1 87CA 156E B076

Bug#1064593: debian-policy: missing static resources for www.debian.org policy page

[Holger Wansing]

Hi,

Am 24. Februar 2024 20:15:41 MEZ schrieb James Addison :
>
>(this may relate closely to #915583)
>
>Some of the web resources referenced by the online[1] copy of the Debian policy
>manual seem to return HTTP 404 responses at the moment, meaning that the
>intended Sphinx CSS theming fails to apply.
>
>[1] - https://www.debian.org/doc/debian-policy/

Hmm, locally built it's fine here ...

@Stéphane: could you take a look?


Holger





-- 
Sent from /e/ OS on Fairphone3

Bug#915583: about html_static_path

[Holger Wansing]

Hi Sean,

Sean Whitton  wrote (Sat, 24 Feb 2024 11:58:59 +0800):
> Attached is the patch I prepared, which I couldn't get to work.  Maybe
> you can see what is wrong.  Thanks!

As I know it, the debian.css file has to reside in policy/_static.
And activate (un-comment) the path declaration for that in line 105 of 
conf.py.in.

Additionally, as I already wrote somewhere, for navigating it would be good
to have the Next/Previous buttons at the top of the page as well, not only
at the bottom.

And: do we want to have the 
"Built with Sphinx using a theme provided by Read the Docs."
in the footer? If not, that could be suppressed by
html_show_sphinx = False
in conf.py.in.


My diff for conf.py.in would be like this (with above suggestions):

diff --git a/policy/conf.py.in b/policy/conf.py.in
index d516d7b..4ea4df6 100755
--- a/policy/conf.py.in
+++ b/policy/conf.py.in
@@ -84,13 +84,19 @@ todo_include_todos = False
 # The theme to use for HTML and HTML Help pages.  See the documentation for
 # a list of builtin themes.
 #
-html_theme = 'nature'
+html_theme = 'sphinx_rtd_theme'
 
 # Theme options are theme-specific and customize the look and feel of a theme
 # further.  For a list of options available for each theme, see the
 # documentation.
 #
-# html_theme_options = {}
+html_theme_options = {
+   # To get previous/next buttons at the top and the bottom:
+   'prev_next_buttons_location': 'both'
+}
+
+# Overwrite theme to fit Debian colors
+html_css_files = ['debian.css']
 
 # Override the title to remove the unnecessary "documentation" suffix.
 html_title = "Debian Policy Manual v@VERSION@"
@@ -98,11 +104,14 @@ html_title = "Debian Policy Manual v@VERSION@"
 # Suppress the copyright notice.
 html_show_copyright = False
 
+# Hide “Created using Sphinx” in the HTML footer
+html_show_sphinx = False
+
 # Add any paths that contain custom static files (such as style sheets) here,
 # relative to this directory. They are copied after the builtin static files,
 # so a file named "default.css" will overwrite the builtin "default.css".
 #
-# html_static_path = ['_static']
+html_static_path = ['_static']
 
 
 # -- Options for HTMLHelp output ----------



Best regards
Holger



-- 
Holger Wansing 
PGP-Fingerprint: 496A C6E8 1442 4B34 8508  3529 59F1 87CA 156E B076

Bug#915583: about html_static_path

[Holger Wansing]

Sean Whitton  wrote:
> On Fri 29 Dec 2023 at 07:08am +01, Stéphane Blondon wrote:
> 
> > Yes, html_static_path must be set but it's already the case in conf.py.in:
> > https://sources.debian.org/src/debian-policy/4.6.2.0/policy/conf.py.in/#L105
> >
> > I guess conf.py is generated from conf.py.in so we only need to keep
> > the current setup.
> 
> That line is commented out, though.  Are you saying it takes on its
> default value in that case?

I think it would be good to un-comment such lines which are needed, so it's 
clear without doubt, what is used and active.
Works fine here BTW.


Holger

-- 
Holger Wansing 
PGP-Fingerprint: 496A C6E8 1442 4B34 8508  3529 59F1 87CA 156E B076

Bug#848972: Fixed in Ubuntu

[Holger Wansing]

Control: tags -1 + patch

Ferenc Wágner  wrote (Mon, 26 Jun 2023 12:27:49 +0200):
> Control: tag + patch
> 
> Hi,
> 
> This issue was fixed in 1.178ubuntu12, as detailed at
> https://bugs.launchpad.net/ubuntu/+source/console-setup/+bug/1824227
> Please consider taking over the fix.

I have grabbed the changings from
https://git.launchpad.net/ubuntu/+source/console-setup/commit/?h=applied/ubuntu/disco=dc3395232928c2a3f53c7e5e29ad25a2638ddcae


Patch attached.

Any objections?


Holger


-- 
Holger Wansing 
PGP-Fingerprint: 496A C6E8 1442 4B34 8508  3529 59F1 87CA 156E B076
diff --git a/debian/changelog b/debian/changelog
index fb41ffd..ce2f43b 100644
--- a/debian/changelog
+++ b/debian/changelog
@@ -1,3 +1,13 @@
+console-setup (1.227) UNRELEASED; urgency=medium
+
+  * setupcon: use /run for tempfiles (and dump the various unnecessary
+fallback paths), since /run is always mountable rw at least as early as
+/tmp is and is guaranteed to be safe from tmpcleaners at boot.  Only keep
+/tmp as a fallback in case we have access to write to /tmp and to a
+console, but not to /run.  Closes: #848972
+
+ -- Holger Wansing   Sun, 11 Feb 2024 13:03:18 +0100
+
 console-setup (1.226) unstable; urgency=medium
 
   * Team upload
diff --git a/setupcon b/setupcon
index 04641c6..5d83433 100755
--- a/setupcon
+++ b/setupcon
@@ -60,11 +60,8 @@ trap 'rm -f $tempfiles >/dev/null 2>&1' 0
 trap "exit 2" 1 2 3 13 15
 tempfile () {
 if \
-TMPFILE=`mktemp /tmp/tmpkbd.XX 2>/dev/null` \
-|| TMPFILE=`mktemp /run/tmpkbd.XX 2>/dev/null` \
-|| TMPFILE=`mktemp /dev/.tmpkbd.XX 2>/dev/null` \
-|| TMPFILE=`mktemp /lib/init/rw/tmpkbd.XX 2>/dev/null` \
-|| TMPFILE=`mktemp 2>/dev/null`
+TMPFILE=`mktemp /run/tmpkbd.XX 2>/dev/null` \
+|| TMPFILE=`mktemp /tmp/tmpkbd.XX 2>/dev/null`
 then
 tempfiles="$tempfiles $TMPFILE"
 return 0

Bug#1063413: FTBFS: cannot open /<>/Keyboard/pc105.ekbd: No such file

[Holger Wansing]

Hi,

Colin Watson  wrote (Thu, 8 Feb 2024 14:06:05 +):
> On Wed, Feb 07, 2024 at 11:13:01PM +0100, Holger Wansing wrote:
> > Am 7. Februar 2024 21:55:05 MEZ schrieb Emanuele Rocca :
> > >  Dumping the encoded keymaps for pc105...
> > >  WARNING: Can not find "caps_switch" in "group".
> > >  WARNING: Can not find "caps_toggle" in "group".
> > >  gzip -9n >/Keyboard/pc105.ekbd 
> > > >/<>/Keyboard/pc105.ekbd.gz
> > >  /bin/sh: 1: cannot open /<>/Keyboard/pc105.ekbd: No such 
> > > file
> > >  make[1]: *** [rules.mk:17: /<>/Keyboard/pc105.ekbd.gz] 
> > > Error 2
> > >  make[1]: Leaving directory '/<>'
> > >  make: *** [debian/rules:204: udeb-install] Error 2
> > >
> > >Version 1.223 builds fine in unstable instead. Perhaps this is related
> > >to the fact that 1.224 dropped the binary package console-setup-pc-ekbd?
> > 
> > What makes you think, that this has happened?
> > 
> > There is a merge request that includes the removal of said package,
> > but it has not yet been merged.
> 
> It's not in git, but you appear to have built 1.224 from an unclean
> source tree that had that patch applied.
> 
> My inclination is to upload 1.225 without that patch for now, as we need
> to rebuild for the new xkb-data to sort out uninstallability in
> unstable, and then get the kFreeBSD-removal patch sorted out after that.

Uhm, that was not my plan :-(
Sorry for that.

> Objections?

None, of course.
Will work that out.


Holger

-- 
Holger Wansing 
PGP-Fingerprint: 496A C6E8 1442 4B34 8508  3529 59F1 87CA 156E B076

Bug#1063413: FTBFS: cannot open /<>/Keyboard/pc105.ekbd: No such file

[Holger Wansing]

Am 7. Februar 2024 21:55:05 MEZ schrieb Emanuele Rocca :
>  Dumping the encoded keymaps for pc105...
>  WARNING: Can not find "caps_switch" in "group".
>  WARNING: Can not find "caps_toggle" in "group".
>  gzip -9n >/Keyboard/pc105.ekbd 
> >/<>/Keyboard/pc105.ekbd.gz
>  /bin/sh: 1: cannot open /<>/Keyboard/pc105.ekbd: No such file
>  make[1]: *** [rules.mk:17: /<>/Keyboard/pc105.ekbd.gz] Error 2
>  make[1]: Leaving directory '/<>'
>  make: *** [debian/rules:204: udeb-install] Error 2
>
>Version 1.223 builds fine in unstable instead. Perhaps this is related
>to the fact that 1.224 dropped the binary package console-setup-pc-ekbd?

What makes you think, that this has happened?

There is a merge request that includes the removal of said package,
but it has not yet been merged.


Holger



-- 
Sent from /e/ OS on Fairphone3

Bug#1051968: #1051968please make task-mate-desktop install libreoffice-gnome

[Holger Wansing]

Control: tags -1 pending


MR just merged.


-- 
Sent from /e/ OS on Fairphone3

Bug#915583: Bug#1059730: debian-policy: switch to new Debian-conform html theme for Sphinx/reST

[Holger Wansing]

[ Hrrr, I sent this to the wrong bug #1059730; so resending to the correct 
one #915583 for completeness ]


Holger Wansing  wrote (Sun, 31 Dec 2023 10:02:29 +0100):
> Hi Sean and Stéphane,
> 
> Am 30. Dezember 2023 23:43:17 MEZ schrieb Sean Whitton 
> :
> >Possibly some of your changes could be applied on top of that?
[...]
> @Stéphane: 
> The URL is 404 now, could you provide the draft again somewhere?
> (<http://stephane.yaal.fr/tmp/policy/>)

Thanks, your files are back online.
They look really good indeed. 
Especially how the menu/sidebar is shown/not shown on small screens 
(smartphones) is fine, that was an open point in my proposal :-)

BTW: I think it would be good to have the 'Next'/'Previous' buttons
at the top additionally to those at the bottom.
The theme supports this via a config option. Simply set

html_theme_options = {
# To get previous/next buttons at the top and the bottom:
'prev_next_buttons_location': 'both'
}

in conf.py.in.


Holger



-- 
Holger Wansing 
PGP-Fingerprint: 496A C6E8 1442 4B34 8508  3529 59F1 87CA 156E B076

Bug#1059730: debian-policy: switch to new Debian-conform html theme for Sphinx/reST

[Holger Wansing]

Hi,

Holger Wansing  wrote (Sun, 31 Dec 2023 10:02:29 +0100):
> Hi Sean and Stéphane,
> 
> Am 30. Dezember 2023 23:43:17 MEZ schrieb Sean Whitton 
> :
> >Possibly some of your changes could be applied on top of that?
[...]
> @Stéphane: 
> The URL is 404 now, could you provide the draft again somewhere?
> (<http://stephane.yaal.fr/tmp/policy/>)

Thanks, your files are back online.
They look really good indeed. 
Especially how the menu/sidebar is shown/not shown on small screens 
(smartphones) is fine, that was an open point in my proposal :-)

BTW: I think it would be good to have the 'Next'/'Previous' buttons
at the top additionally to those at the bottom.
The theme supports this via a config option. Simply set

html_theme_options = {
# To get previous/next buttons at the top and the bottom:
'prev_next_buttons_location': 'both'
}

in conf.py.in.


Holger



-- 
Holger Wansing 
PGP-Fingerprint: 496A C6E8 1442 4B34 8508  3529 59F1 87CA 156E B076

Bug#1059730: debian-policy: switch to new Debian-conform html theme for Sphinx/reST

[Holger Wansing]

Hi Sean and Stéphane,

Am 30. Dezember 2023 23:43:17 MEZ schrieb Sean Whitton 
:
>Hello,
>
>On Sat 30 Dec 2023 at 11:11pm +01, Holger Wansing wrote:
>
>> Source: debian-policy
>> Tags: patch
>>
>> Debian Policy has been migrated to restructedText / Sphinx.
>> However, the current html theme is not conform with the look of the Debian 
>> website.
>>
>> Bug #1053549 (https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1053549)
>> requests to create a new theme for Sphinx-based documents "to match our docs
>> appearance with the Debian website colours etc."
>>
>> I have worked on this and a patch is attached, to fulfill this goal.
>>
>> An preview how the Debian Policy would look like with this theme can be 
>> found at
>> https://people.debian.org/~holgerw/sphinx-theme-for-debian/alabaster/debian-policy-manual/
>>
>> Please consider to apply this proposal.
>
>We're actually in the middle of applying someone else's proposal, here: 
>#915583.
>
>Possibly some of your changes could be applied on top of that?

Yes, of course.
I wasn't aware of other work on this front.
And Stéphane is for sure the right guy for CSS/theme topics, he has much
experience there, other than me. 
I just wanted to push things forward somehow.

So, let's see how it goes and if things remain from this proposal


@Stéphane: 
The URL is 404 now, could you provide the draft again somewhere?
(<http://stephane.yaal.fr/tmp/policy/>)

BTW: I missed the MR you filed for my release-notes's draft regarding CSS, 
sorry. 
I will follow up there shortly.


Greetings
Holger

-- 
Sent from /e/ OS on Fairphone3

Bug#1059730: debian-policy: switch to new Debian-conform html theme for Sphinx/reST

[Holger Wansing]

Source: debian-policy
Tags: patch

Debian Policy has been migrated to restructedText / Sphinx.
However, the current html theme is not conform with the look of the Debian 
website.

Bug #1053549 (https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1053549)
requests to create a new theme for Sphinx-based documents "to match our docs 
appearance with the Debian website colours etc."

I have worked on this and a patch is attached, to fulfill this goal.

An preview how the Debian Policy would look like with this theme can be found at
https://people.debian.org/~holgerw/sphinx-theme-for-debian/alabaster/debian-policy-manual/

Please consider to apply this proposal.


BTW:
I have also requested to switch the developers-reference to the same
theme (https://salsa.debian.org/debian/developers-reference/-/merge_requests/47)
and the new release-notes for trixie are already using it
(https://www.debian.org/releases/testing/release-notes/index.en.html).


So long
Holger


-- 
Holger Wansing 
PGP-Finterprint: 496A C6E8 1442 4B34 8508  3529 59F1 87CA 156E B076
>From 1193ec1df212565fc5344a9a4bf31b65275cfc5b Mon Sep 17 00:00:00 2001
From: Holger Wansing 
Date: Sat, 30 Dec 2023 22:49:20 +0100
Subject: [PATCH] Switch to new theme for sphinx-based documentation

---
 policy/_static/openlogo-policy-manual.png | Bin 0 -> 15237 bytes
 policy/_static/openlogo-policy-manual.xcf | Bin 0 -> 7904 bytes
 policy/conf.py.in |  13 ++---
 3 files changed, 10 insertions(+), 3 deletions(-)
 create mode 100644 policy/_static/openlogo-policy-manual.png
 create mode 100644 policy/_static/openlogo-policy-manual.xcf

diff --git a/policy/_static/openlogo-policy-manual.png b/policy/_static/openlogo-policy-manual.png
new file mode 100644
index ..bd449f163feefe9e3c0b0f473acfe11591e275f5
GIT binary patch
literal 15237
zcmeHtWmKF?)^6kO8nhdCZ`|FT5L_E*oThOIPJrML0t9!L1PBCo3+@sm5G+U_K#+u7
zl5=L}%>Cwm-<`GY{WrZ}T(KYVWFk>59?TRKmfezytsQI4a8Wx(|PCAKs03ERJjMfGGEU1
zZPJbh-^YDh4fOBY$V=%of72y-s(9lM`l7$X`}F>8kc8XDTAPwrzQ7N#zpC`1N#h@eD5N`>;Y{FYZZMZPv}!Eo?l2
zH%vNpeGjgbce6hsk`taT-1E6^A1%69BtzpS?~;4pK5f0bA)@%SY^hUGR{EZp`R8o;
zTAk6s_N39xS)D}+;n<$v5K%CW-Obtc&>rVck?WJl>oT#S%k7C^zfPCcF3r8W(~h>*
zfJu9AdJ`_A#1RC%n)b~VaO
z?9^k~I+`_G+Yj3+@;cY4A?ivk0l)NRf`RM@be4BTpX!E>(kC3A6$*L2UmUV
zdARJ@P|7TR#^iN%Om(pN@oz|a6mpOoY7_8bLo~bm$S@l2%#?0WuJ861rAD0?!fzs5
zd3(0@_6Ye`4P7b{KB~cY;xmV|>Wn^EkOAe_#Q4cYftlRIT_j(@5sr#flsAt|%Of*-
z8Bo$am*V(}$+1SDGT(Oj=hp+|aP!J~I0%z%VqVN$2oD<|E|uqHQGf+t?^*XuVdI?N
z#8o*ec63!a5xaD3G{B3xPA*N0)7EO7Z)ZZ37yT(EF3^Q{
z%&;2Fw9ADoEZgPT=t#2Hw2xL+wazatSqMKsqOfhli1zyUY`AU=NnS<(u=`cdZ)m~g;TYRO$K&*TMh>LZG%Vo`QfnL
zS0%*Rx@FlnxbH(<;`rD_R?~R-G7=$l1ZjF(*e95uO~$ksc(86x{jgzs
z@~!;`$jM}?JrK?<=O~9Vue6dV6hC#1r+Isjyfx0}IzoRW_-$PXK^0%KBIt6HZQ5*g
zXz=*B|Tc
zxGnq%XwO$a^0mJIJS)PL`g!?LT46H!UBT_@_(7bP-XpQPM?X3}uP6qqbI94eBb?54
zp>MPo)2SCZ@n=BFZKYz?W@)P^F0ICyp_49BBith=PP+nfW^?`yti;6XxkNJ!=ylWn
zyo)VEEzeaJ5C`K0GOx2)O_a8HRSXlVlA*Y49)#Bu
z$fRWN%aREkzr7b9guSfhtSln(GWHH^LOH5_20H#$H{_a%KWG$>U#Gj-{%9d2Bz0A$
zBwd4$ZqDvz(0sLqebT)Gdvg<+y^VWu%e8m?FpsaJ3xB;K>QJ18oj$a98UUo`Py
z3;rKU%{e%a!(Sg#1b$itNSjt#Sb%5n(I|L8(M~Q
z0fbHSk-8O)!v2|S`Syb`#F_m*E$QWXIaxL8n2uwYOTr;GoE=40DqeEM*%+j#>}bAH
zaW}g?Inclp1JILG!Xz@|C>-e@@Pi{`xnm?90Y0$d4_0;Yy%>0Xw`yEk`v1#5{
zW3+IL%iwVmbr7^2ZSm(5@-k8UT^Ql7XfRC^ZLDc`nHu7BW-%b6kfvm-l4tan4%xd4aMe5|tvt
zd!#`MUsXz;HW@7Jd4W-PS}E3&8Ha2^R%Hij?-1t(HFY%C9OZp8R<~N@XKQmHV)qIz
z;kILqv?u`?+x`H|mgd%Y)e*}2X0LfPeT3Hp)u^Hk$aR7h?IGV3{K-)iC9T?HypyWM
zzffdJisA>>=n3s$@C=C>a_7_bWioNd^`-GgtJOT)0)17Ms5>8wor^)sZfBUJj;@7&
zj&#

Bug#1057288: www.debian.org: use of wml::debian::translation-check header breaks translation of "Galician"

[Holger Wansing]

Package: www.debian.org
X-Debbugs-CC: a...@debian.org

I just found (more or less by accident), that using the
wml::debian::translation-check header in wml files breaks the translation of
the word "Galician".
So this counts for all pages but English.
The result can be found on pages like

https://www.debian.org/releases/trixie/releasenotes.nl.html
https://www.debian.org/releases/trixie/releasenotes.zh-cn.html

or

https://www.debian.org/doc/user-manuals.fr.html#refcard
https://www.debian.org/doc/user-manuals.es.html#refcard

All those pages have a line with HTML | text | PDF links, where the
language entry at the beginning is blank.


Removing the translation-check header from the respective wml file will
make the "Galician" word appear.
(Interestingly, all other language names are correctly translated in either
way!)

My wild guess would be this being a wml issue (thus abe in CC), but I would be 
more comfortable, if I could get more debugging info, like the full wml 
commandline, or the like.
Don't know, how to get this though ...


Holger


-- 
Holger Wansing 
PGP-Fingerprint: 496A C6E8 1442 4B34 8508  3529 59F1 87CA 156E B076

Bug#619328: console-setup-freebsd: Uninstallable on Linux hosts

[Holger Wansing]

Hi,

Paul Gevers  wrote (Sat, 28 Oct 2023 20:14:13 +0200):
> Hi,
> 
> On Mon, 24 Jul 2023 17:17:54 +0200 Paul Gevers  wrote:
> > On Wed, 23 Mar 2011 10:49:42 +0100 Julien Cristau  
> > wrote:
> > > On Wed, Mar 23, 2011 at 11:36:00 +0200, Anton Zinoviev wrote:
> > > > Does this mean the 
> > > > architectures are not equal in rights - an 'all' package is allowed to 
> > > > be uninsallable on kFreeBSD but not on Linux?
> > > > 
> > > No, it's fine.
> > 
> > While I totally stand behind this, with the kfreebsd's removed now even 
> > from the ports [1], maybe it's time to stop building console-setup-freebsd?
> 
> And now, due to changes in our migration software, this issue has caused 
> console-setup to be blocked for 34 days already [1]:
> uninstallable on arch amd64, not running autopkgtest there
> 
> I'll hint it through now, but it would be nicer if console-setup-freebsd 
> would be dropped next time (as it would ensure src:console-setup gets 
> the normal autopkgtest treatment).
> 
> Paul
> 
> [1] https://qa.debian.org/excuses.php?package=console-setup

While cleaning up the whole code of console-setup from kfreebsd parts
is out of my skills, I managed to get it so far, that the kfreebsd packages
are no longer beeing built, and those packages removed from control file.
Could this be enough for now?

I filed this as MR [1].

The pipeline on that push went fine first [2], while there was a job within
the pipeline named "D-I" which I triggered manually and that failed, however 
I'm not exactly sure what this job does, and what failed there; a mini.iso 
image was however successfully created. I did not notice this pipeline
funtionality before. Is this expected to work?

Comparing all the remaining packages with debdiff shows no unexpected 
differences compared to the previous version, so for me it looks ok.

Maybe someone wants to take a look?


Holger

[1] https://salsa.debian.org/installer-team/console-setup/-/merge_requests/21
[2] https://salsa.debian.org/holgerw/console-setup/-/pipelines/608351


-- 
Holger Wansing 
PGP-Fingerprint: 496A C6E8 1442 4B34 8508  3529 59F1 87CA 156E B076

Bug#1057073: debian-cd: adapt script to match the new release-notes situation for trixie

[Holger Wansing]

Package: debian-cd
Tags: patch


For trixie we have some changings regarding the release-notes:

They have been migrated from Docbook to reStructedText / Sphinx [1].
During this migration, it has been decided to no longer build separate
versions per architecture, but only one generic variant.

This leads to a changed directory structure on the website for trixie:
While the release-notes had in the past (for example for bookworm):

/www.d.o/releases/bookworm/amd64/release-notes/index.en.html
  /index.de.html
  /index.da.html
[and many more html files for amd64]
/www.d.o/releases/bookworm/i386/release-notes/index.en.html
 /index.de.html
 /index.da.html
[and many more html files for i386]
/www.d.o/releases/bookworm/armel/release-notes/index.en.html
  /index.de.html
  /index.da.html
[and many more html files for armel]

... and so on


And for trixie we have now:

/www.d.o/releases/trixie/release-notes/index.en.html
  /index.de.html
  /index.da.html
  [and many more html files]

So, the architecture part is skipped from the path.




This requires changes in debian-cd/tools/trixie/installtools.sh, so that
this script can find the release-notes again:

The script uses a r-n tarball, which for bookworm is under
https://www.debian.org/releases/bookworm/release-notes-amd64.tar.gz
https://www.debian.org/releases/bookworm/release-notes-i386.tar.gz
https://www.debian.org/releases/bookworm/release-notes-armel.tar.gz
... and so on.

For trixie, the tarball is under
https://www.debian.org/releases/trixie/release-notes.tar.gz


BTW:
AFAICS the release-notes are not integrated in the installation images
currently, but we should keep the script working nevertheless.



I have attached a patch with the required changings.
This is however untested, since I'm unable to use debian-cd due to the
lack of a local mirror. So, could someone do a test build, to check the
script works again?


Regards
Holger




[1] https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=932957#245


-- 
Holger Wansing 
PGP-Fingerprint: 496A C6E8 1442 4B34 8508  3529 59F1 87CA 156E B076
diff --git a/tools/trixie/installtools.sh b/tools/trixie/installtools.sh
index 9ecdf688..40780946 100755
--- a/tools/trixie/installtools.sh
+++ b/tools/trixie/installtools.sh
@@ -42,33 +42,30 @@ if [ "$OMIT_MANUAL" != 1 ]; then
 echo "ERROR: Unable to copy installer documentation to CD."
 fi
 else
 echo "ERROR: installation-guide package not unpacked correctly."
fi
 else
 echo "ERROR: package installation-guide-$ARCH not found."
 fi
 		fi
 	done
 fi
 
 if [ "$OMIT_RELEASE_NOTES"x = "1"x ]; then
 	echo "  Omitting release notes, as requested"
 else
-	for ARCH in $ARCHES
-	do
 		if [ $ARCH != source ] ; then
 			RN=$DIR/doc/release-notes
 			mkdir -p $RN
 			cd $RN
-			echo "  Downloading most recent release notes for $ARCH"
-			$WGET $RELEASE_NOTES_LOCATION/release-notes-$ARCH.tar.gz
-			if [ -e release-notes-$ARCH.tar.gz ] ; then
-tar xzvf release-notes-$ARCH.tar.gz
-rm -f release-notes-$ARCH.tar.gz
+			echo "  Downloading most recent release notes"
+			$WGET $RELEASE_NOTES_LOCATION/release-notes.tar.gz
+			if [ -e release-notes.tar.gz ] ; then
+tar xzvf release-notes.tar.gz
+rm -f release-notes.tar.gz
 rm -f */*.ps
 			else
-echo "No release notes found at $RELEASE_NOTES_LOCATION/release-notes-$ARCH.tar.gz"
+echo "No release notes found at $RELEASE_NOTES_LOCATION/release-notes.tar.gz"
 			fi
 		fi
-	done
 fi

Bug#905344: #905344www.debian.org: please publish Japanese translation of the Debian Policy Manual

[Holger Wansing]

AFAICS there has been not much work on Japanese since this bug has been filed.

How to proceed?
Sorry for not acting more in time, but should we still  publish Japanese 
translation?


Holger

-- 
Sent from /e/ OS on Fairphone3

Bug#1026446: #1026446Static javascript resources for Policy and DevRef give 404 errors, breaking search

[Holger Wansing]

see 


-- 
Sent from /e/ OS on Fairphone3

Bug#987943: www.debian.org: Developers Reference: Sphinx search non-functional: searchindex.js missing

[Holger Wansing]

In the meantime things have evolved, Sphinx has changed its way to
deal with this; see 


Thus, the current developers-reference built on a bookworm or later system
leads to a output, where the search is working.
Can be viewed at 

(also with a different html theme, BTW)


So, when wolkenstein gets updates to bookworm (currently on bullseye)
it will just, I guess.


Holger


-- 
Sent from /e/ OS on Fairphone3

Bug#1056697: 12.2 Installation Report, Complete Failure of Network

[Holger Wansing]

Hi,

Am 24. November 2023 23:54:49 MEZ schrieb David Hillman 
:
>On 11/24/23 12:59, Holger Wansing wrote:
>Thanks Holger.  I could do that, but that would completely defeat the purpose. 
> I installed Debian 12 on this machine as a test, to confirm that everything 
>necessary works, before installing it on a dozen or so other similar machines.

Trying a debian 13 image was meant as some sort of debugging. 
It would involve a newer kernel for example, in case it's a kernel issue...


Holger



-- 
Sent from /e/ OS on Fairphone3

Bug#1053549: Bug#932957: New theme for docs in reStructuredText (was: Re: Bug#932957: #932957 Please migrate Release Notes to reStructuredText)

[Holger Wansing]

Holger Wansing  wrote (Fri, 24 Nov 2023 22:49:47 +0100):
> I used the alabaster theme, which is the default theme in Sphinx, and 
> set some configuration options in conf.py, to adapt some details. That's all.
> 
> So no need to create a new theme IMO.
> 
> Just set the appropriate options in the manual, and build it.

I have switched trixie's release-notes to this new theme, and the result 
is now visible on www.debian.org/releases/trixie/release-notes.

I noticed, that the links to the previous and next chapter at the top
and the bottom of the pages are missing.

Some research showed, that the reason for this is the sphinx version on
www-master, which is a bullseye system.
Starting with the sphinx version in bookworm, those links are supported.
So this will start working, when wolkenstein will get updated to bookworm.

Moreover, I changed the Debian logo to include the document name (here:
"Release-Notes"), to have that information available on every page of the
release-notes (at the top).


Holger



-- 
Holger Wansing 
PGP-Fingerprint: 496A C6E8 1442 4B34 8508  3529 59F1 87CA 156E B076

Bug#1053549: Bug#932957: New theme for docs in reStructuredText (was: Re: Bug#932957: #932957 Please migrate Release Notes to reStructuredText)

[Holger Wansing]

[ Re-sending message; first attempt from smartphone dropped some recipients, 
sorry ]


Am 24. November 2023 10:50:19 MEZ schrieb Laura Arjona Reina 
:
>I've had a quick look at the theme 
>inhttps://people.debian.org/~holgerw/sphinx-theme-for-debian/alabaster/release-notes/
>  and looks very nice both in my computer and my phone, and I think it's a 
>good improvement for the current theme. Thank you *very much*.
>
>I don't know which is the better way forward, maybe add a repo for the theme 
>in the ddp-team umbrella, and then file a bug for every documentation manual 
>using Sphinx, suggesting including it?

I used the alabaster theme, which is the default theme in Sphinx, and 
set some configuration options in conf.py, to adapt some details. That's all.

So no need to create a new theme IMO.

Just set the appropriate options in the manual, and build it.


Holger


-- 
Holger Wansing 
PGP-Fingerprint: 496A C6E8 1442 4B34 8508  3529 59F1 87CA 156E B076

Bug#1056697: 12.2 Installation Report, Complete Failure of Network

[Holger Wansing]

Hi,

David Hillman  wrote (Fri, 24 Nov 2023 12:34:50 -0600):
> Ubuntu 20 and 22 installers work just fine on the same hardware, so this 
> is a Debian-specific issue.  All four interfaces work just fine under 
> both Ubuntu 20 and 22, but are totally dysfunctional with Debian 12.

Maybe you could try a preview Debian 13 image?
https://cdimage.debian.org/cdimage/daily-builds/daily/arch-latest/amd64/iso-cd/


-- 
Holger Wansing 
PGP-Fingerprint: 496A C6E8 1442 4B34 8508  3529 59F1 87CA 156E B076

Bug#932957: New theme for docs in reStructuredText (was: Re: Bug#932957: #932957 Please migrate Release Notes to reStructuredText)

[Holger Wansing]

Hi,

Am 24. November 2023 10:50:19 MEZ schrieb Laura Arjona Reina 
:
>I've had a quick look at the theme 
>inhttps://people.debian.org/~holgerw/sphinx-theme-for-debian/alabaster/release-notes/
>  and looks very nice both in my computer and my phone, and I think it's a 
>good improvement for the current theme. Thank you *very much*.
>
>I don't know which is the better way forward, maybe add a repo for the theme 
>in the ddp-team umbrella, and then file a bug for every documentation manual 
>using Sphinx, suggesting including it?

I used the alabaster theme, which is the default theme in Sphinx, and 
set some configuration options in conf.py, to adapt some details. That's all.

So no need to create a new theme IMO.

Just set the appropriate options in the manual, and build it.


Holger


-- 
Sent from /e/ OS on Fairphone3

Bug#932957: #932957 Please migrate Release Notes to reStructuredText

[Holger Wansing]

Hi again,

Holger Wansing  wrote (Mon, 13 Nov 2023 11:19:07 +0100):
> Time for a status update:
> Since the new release-notes itself are now being built on www-master (based
> on Sphinx), some changings were needed for the webpage (currently 
> www.debian.org/releases/testing/releasenotes), because we no longer have
> separate release-notes for the different release-archs.
> 
> I did that yesterday, let's say as a proposal.
> 
> Previously, there was some sort of black magic (or maybe it's perl), 
> which automatically creates a table with all architectures, languages,
> and output formats of the r-n.
> Changing this mechanism to leave out the architecture part is out of my
> skills, but I managed to copy (and adapt) the logic which is being used in 
> the debian.org/doc part of the website, to generate the list of available 
> languages and formats for the different manuals there.
> 
> It looks fine IMO, and it also works. However new languages are not 
> displayed automatically, so compared to the old mechanism there might
> be some handwork needed at some point (but rare I guess).
> 
> 
> @webmaster, @release-team, @ddp-team: what do you think? Would this
> proposal be acceptable to you for the new release-notes (trixie and later)?

And since there has been a call for a Debian theme for Sphinx (see
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1053549), a proposal
for that can be found at
https://people.debian.org/~holgerw/sphinx-theme-for-debian/alabaster/release-notes/
(for those, who are uncomfortable with the greenish theme).


Holger


-- 
Holger Wansing 
PGP-Fingerprint: 496A C6E8 1442 4B34 8508  3529 59F1 87CA 156E B076

Bug#941962: #941962Publish the new (Sphinx based) Developers Reference

[Holger Wansing]

I guess this bug can be closed, right?
The developers-reference (Sphinx-based) is online on www.d.o
(There are some minor issues with search and the theme, but they have separate 
bugs.)


Holger


-- 
Sent from /e/ OS on Fairphone3

Bug#1053549: #1053549Create a Debian theme for documentation based in Sphinx (reStructuredText)

[Holger Wansing]

Hi,

I'm have no experiences regarding design or CSS or the like, but I have
created some sort of a proposal for this, using an adapted alabaster theme.

See 

The used conf.py can also be found there for reference.

While it looks good IMO on laptos, PC etc., it does not on a small 
screen like on smartphones, because the sidebar gets unvisible.

Maybe someone can help with that?




Holger


-- 
Sent from /e/ OS on Fairphone3

Bug#932957: #932957 Please migrate Release Notes to reStructuredText

[Holger Wansing]

Hi,

Paul Gevers  wrote (Thu, 24 Aug 2023 14:10:41 +0200):
> I have just requested webmaster to switch the bookworm build from the 
> master branch to the bookworm branch [1]. After that request gets merged 
> and deployed, I'd like you to publish your work in the master branch 
> such that we can work from there (and see the results too [2]). Because 
> in your worked we stopped making notes per architecture, we probably 
> need to make further changes to the webmaster archive, but let's first 
> build something.

Time for a status update:
Since the new release-notes itself are now being built on www-master (based
on Sphinx), some changings were needed for the webpage (currently 
www.debian.org/releases/testing/releasenotes), because we no longer have
separate release-notes for the different release-archs.

I did that yesterday, let's say as a proposal.

Previously, there was some sort of black magic (or maybe it's perl), 
which automatically creates a table with all architectures, languages,
and output formats of the r-n.
Changing this mechanism to leave out the architecture part is out of my
skills, but I managed to copy (and adapt) the logic which is being used in 
the debian.org/doc part of the website, to generate the list of available 
languages and formats for the different manuals there.

It looks fine IMO, and it also works. However new languages are not 
displayed automatically, so compared to the old mechanism there might
be some handwork needed at some point (but rare I guess).


@webmaster, @release-team, @ddp-team: what do you think? Would this
proposal be acceptable to you for the new release-notes (trixie and later)?


Holger


-- 
Holger Wansing 
PGP-Fingerprint: 496A C6E8 1442 4B34 8508  3529 59F1 87CA 156E B076

Bug#1055767: release-notes and sphinx: incompatible formatting of manpage links in bookworm and trixie

[Holger Wansing]

Hi Paul,

Paul Gevers  wrote (Sat, 11 Nov 2023 14:35:42 +0100):
> Hi,
> 
> On 10-11-2023 22:31, Holger Wansing wrote:
> > So the situation is: with the current source code we cannot have the 
> > release-notes
> > correct on the Debian website and at the same time have succeeding pipelines
> > on Salsa, when people are doing changes.
> 
> > Need to investigate, how to proceed here...
> 
> I didn't check, but can't we switch the relevant pipelines to run on 
> bookworm instead on trixie? Sooner or later we *need* the website to be 
> correct and I agree that the pipelines are really nice to have too.

yes, that was the idea I had this morning too :-))
So simple, but I didn't get that yesterday...

I have already committed that, the pipeline was fine then, and now I see the
website also fine again, so this is fixed.

Closing this bug
Thanks for your time anyway


Holger


-- 
Holger Wansing 
PGP-Fingerprint: 496A C6E8 1442 4B34 8508  3529 59F1 87CA 156E B076

Bug#1055767: release-notes and sphinx: incompatible formatting of manpage links in bookworm and trixie

[Holger Wansing]

Package: release-notes


Now that the release-notes for trixie are based on and built with Sphinx /
restructedText, we got an issue with manpage links.

The manpage links are created with the Sphinx extension "extlinks" with a line
like this

extlinks = {'url-man-stable': ('https://manpages.debian.org/trixie/%s', '%s')}

in source/conf.py. 

A sentence like 
"Further information about this are in :url-man-stable:`rsyslog.conf(5)`. "
leads to html output
"Further information about this are in rsyslog.conf(5). "
where "rsyslog.conf(5)" is a link to 
https://manpages.debian.org/trixie/rsyslog.conf(5).



extlinks has just introduced a change, that makes it impossible to build the 
release-notes on both bookworm and unstable systems, and getting the same 
result with both builds.

Above example is the state of the r-n we actually have in git on Salsa, and
the gitlab CI pipelines running via Salsa are happily building like shown above.

But now looking at the Debian website, for example
https://www.debian.org/releases/testing/release-notes/issues.en.html#rsyslog-changes-affecting-log-analyzers-such-as-logcheck
you find the link to manpages.debian.org crippled, showing "%srsyslog.conf(5)" 
as link text.
This is because *this* build of release-notes is happening on wolkenstein,
which is currently a Bullseye system.
wolkenstein will of course upgraded to Bookworm some time, but when Trixie
is released, wolkenstein will still be a Bookworm system, and the Sphinx
version in Bookworm suffers from the same issue as today under Bullseye.


So the situation is: with the current source code we cannot have the 
release-notes 
correct on the Debian website and at the same time have succeeding pipelines
on Salsa, when people are doing changes.
(If we change the source code in a way, that the links are showing up ok 
on the Debian website, every r-n pipeline on Salsa will fail. See
https://salsa.debian.org/ddp-team/release-notes/-/commit/281b371e731f8abd4a0ea755eea8165e1991bad0/pipelines?ref=master
for an example of such a failure.)


Need to investigate, how to proceed here...


Holger


-- 
Holger Wansing 
PGP-Fingerprint: 496A C6E8 1442 4B34 8508  3529 59F1 87CA 156E B076

Bug#1036906: debian-junior: Desktop environment for Debian Junior

[Holger Wansing]

Hi, 

Stefan Kropp  wrote:
> I would like to provide a Desktop environment for
> Debian Junior in Debian 13 (trixie). It would be very
> nice, if we will be able to provide this task into the
> Debian Installer and provide a Debian live system.

Since Debian Junior is one of the Debian Pure Blends, this bug
is another incarnation of a very longstanding issue:
Add the blends to the installer (or: have an easy way, to install 
blends from the installer).

See 


Holger

-- 
Sent from /e/ OS on Fairphone3

Bug#1036886: Text input fields very hard to identify in high contrast / dark mode

[Holger Wansing]

Hi,

Samuel Thibault  wrote (Mon, 23 Oct 2023 02:00:25 +0200):
> I had a hard time getting a border. The simplest might be to just have
> a black background, as attached. Would that be fine enough? (we don't
> actually lose any contrast since it's the same blue as before)

Any disadvantages in advocating the text installer to those people?

IMO the situation is much better there (only one input field per page
+ a hyphened baseline below it).

See attachment.


Holger


-- 
Holger Wansing 
PGP-Fingerprint: 496A C6E8 1442 4B34 8508  3529 59F1 87CA 156E B076

Bug#364913: closed by Thomas Lange (closing)

[Holger Wansing]

Am 22. Oktober 2023 06:42:45 MESZ schrieb Helge Kreutzmann 
:
>Hello Thomas,
>Am Sun, Oct 22, 2023 at 01:39:03AM + schrieb Debian Bug Tracking System:
>> Noone work on fixing this, so closing.
>> Feel free to reopen this bug, if soneone really works on this.
>
>Is Debian now hiding its problems? I.e., something nobody is working
>should not be shown in the BTS?
>
>(It's not like hard disk of the BTS is getting fuil, or something …)
>
>For this issue:
>Almost everything is is i18n, except this part. I'm since reporting
>this daily monitoring the devotee repository (and yes, last activity
>was 2009) so I'm disappointed that Debian is now hiding this fact.

I understand Thomas' approach to clean up the list of bugs for the team.
There is no point of keeping reports which are lying in the BTS for 10 
or more years IMO.
They are just filling up the bug list, making it difficult to see the real 
issues.

OTOH there are always people supporting the other view, pointing to 
the "Debian does not hide its problems" rule. (That was my 
experience in the d-i team, too.)

It's an unthankful job.

The main problem is the lack of manpower, in most teams. The 
rest are only nuances. 


Recently I disovered a project (it's part of Lineage OS, an open 
source smartphone OS, powering my Fairphone), where cases 
are closed automatically, when there is no activity for more than 3 
months...
Maybe a bit fast, but probably it shows the reality: 
either people are working on the issue immediatley, or never.

The solution could be, to set them wontfix, but where is the real difference 
then?


Holger




-- 
Sent from /e/ OS on Fairphone3

Bug#1053445: Merge request regarding 'Please migrate Release Notes to reStructuredText'

[Holger Wansing]

Hi,

Am 4. Oktober 2023 17:05:16 MESZ schrieb Laura Arjona Reina 
:
>Hello all
>Sorry for jumping into the thread withour having reading all of it, but the 
>changes to the website cron jobs to build the trixie release notes (MR 13) 
>have been integrated in the codebase (see 
>https://salsa.debian.org/webmaster-team/cron/-/blob/master/parts/7release-notes
> ) and we're getting an error in the build process (hence the recent "ddp 
>build failed" message in the debian-doc list).
>
>I think there are two issues:

Thanks for the quick merge.

That being done now, I need to push the 
'Migrate r-n to restructuredText' changings to master.

Please be patient.

Holger


>A)
>
>7release-notes script now calls for trixie 
>(https://salsa.debian.org/webmaster-team/cron/-/blob/master/parts/7release-notes#L208
> ):
>
>make install DESTDIR=$crondir/tmp >> $notesdir/build.log 2>&1
>
>while for the other releases the call is 
>(https://salsa.debian.org/webmaster-team/cron/-/blob/master/parts/7release-notes#L242
> )
>
>
>make -C $notesdir/release-notes publish \
>PUBLISHTARBALL=yes PUBLISHDIR=$webtopdir/www/releases/$release >> 
> $notesdir/build.log 2>&1
>
>I believe that the Makefile of release-notes understands "publish" instead of 
>"install" but I'm not sure about how should we update L208 of the 
>7release-notes script.
>
>B)
>On the other hand, if I look at the master branch of the release-notes repo, I 
>see that it's still written in docbook, not restructuredtext.
>I guess the files in the new format are still in 
>https://salsa.debian.org/holgerw/release-notes and should be merged into the 
>original release-notes repo first so we actually build them and not the old 
>docbook ones, but not 100% sure about this point because I couldn't follow all 
>the related threads with all the attention they needed (apologies!).
>
>
>Kind regards,
>
>El 4/10/23 a las 12:23, Holger Wansing escribió:
>> Hi,
>> 
>> Thomas Lange  wrote (Wed, 4 Oct 2023 10:29:35 +0200):
>>> Hi Holger,
>>> 
>>> I really like the idea no to produce release notes for each
>>> architecture but only one. Moving to sphinx is also nice.
>>> 
>>> Sorry, if I broke your MR, by adding code that checks if something
>>> changed in the git repo. I think I can easily add this to your code
>>> later. So maybe we copy your version of 7release-notes and after that
>>> I add my code.
>> 
>> That would be really great!
>> 
>>> Do you know how long the build process takes using sphinx? I've added
>>> the code, because the build took around 90 minutes using docbook.
>> 
>> I expect the build time to be reduced dramatically (rughly ~ 1/9, due to
>> building only one arch instead of nine), but I have no definite values,
>> expecially not for the run on www-master.
>> 
>>> Any other things I should keep an eye on?
>> 
>> None at the moment.
>> 
>> Thanks for considering this MR.
>> It would give us the possibility to move r-n to sphinx, which would be a
>> great deal!
>> 
>> 
>> Holger
>> 
>> 
>

-- 
Sent from /e/ OS on Fairphone3

Bug#1053445: Merge request regarding 'Please migrate Release Notes to reStructuredText'

[Holger Wansing]

Hi,

Thomas Lange  wrote (Wed, 4 Oct 2023 10:29:35 +0200):
> Hi Holger,
> 
> I really like the idea no to produce release notes for each
> architecture but only one. Moving to sphinx is also nice.
> 
> Sorry, if I broke your MR, by adding code that checks if something
> changed in the git repo. I think I can easily add this to your code
> later. So maybe we copy your version of 7release-notes and after that
> I add my code.

That would be really great!

> Do you know how long the build process takes using sphinx? I've added
> the code, because the build took around 90 minutes using docbook.

I expect the build time to be reduced dramatically (rughly ~ 1/9, due to 
building only one arch instead of nine), but I have no definite values, 
expecially not for the run on www-master.

> Any other things I should keep an eye on?

None at the moment.

Thanks for considering this MR.
It would give us the possibility to move r-n to sphinx, which would be a
great deal!


Holger


-- 
Holger Wansing 
PGP-Fingerprint: 496A C6E8 1442 4B34 8508  3529 59F1 87CA 156E B076

Bug#932957: #932957 Please migrate Release Notes to reStructuredText

[Holger Wansing]

Created a new bug to track the MR
https://salsa.debian.org/webmaster-team/cron/-/merge_requests/13

That is https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1053445


-- 
Holger Wansing 
PGP-Fingerprint: 496A C6E8 1442 4B34 8508  3529 59F1 87CA 156E B076

Bug#1053445: Merge request regarding 'Please migrate Release Notes to reStructuredText'

[Holger Wansing]

Hi,

Holger Wansing  wrote (Wed, 4 Oct 2023 09:27:34 +0200):
> > I have just requested webmaster to switch the bookworm build from the 
> > master branch to the bookworm branch [1]. After that request gets merged 
> > and deployed, I'd like you to publish your work in the master branch 
> > such that we can work from there (and see the results too [2]). Because 
> > in your worked we stopped making notes per architecture, we probably 
> > need to make further changes to the webmaster archive, but let's first 
> > build something.
> 
> Hey webmaster team,
> 
> please consider MR13 in webmaster's cron repo:
> 
> https://salsa.debian.org/webmaster-team/cron/-/merge_requests/13

I filed this MR ~ 6 weeks ago, but no reaction so far.
And yesterday other commits made this MR broken, unable to merge it now.
Needs to be overworked now.


Holger



-- 
Holger Wansing 
PGP-Fingerprint: 496A C6E8 1442 4B34 8508  3529 59F1 87CA 156E B076

Bug#1053445: Merge request regarding 'Please migrate Release Notes to reStructuredText'

[Holger Wansing]

Package: www.debian.org
Severity: normal


[Re-send attempt 3;
simply mentioning a bug number in the subject apparently leads to the mail 
being 
sent to that bug; and therefore you have a mail, which tries to create a new 
bug, while replying to an exiting one; and this seems to be rejected by the BTS]



Paul Gevers  wrote (Thu, 24 Aug 2023 14:10:41 +0200):
> Hi Holger,
> 
> On 29-07-2023 21:29, Holger Wansing wrote:
> > I have worked out the last big blocker for this migration now.
> > That is, to allow the build on wolkenstein, which is happening via the
> > parts/7release-notes script in webmaster-team/cron git repo.
> 
> I have just requested webmaster to switch the bookworm build from the 
> master branch to the bookworm branch [1]. After that request gets merged 
> and deployed, I'd like you to publish your work in the master branch 
> such that we can work from there (and see the results too [2]). Because 
> in your worked we stopped making notes per architecture, we probably 
> need to make further changes to the webmaster archive, but let's first 
> build something.

Hey webmaster team,

please consider MR13 in webmaster's cron repo:

https://salsa.debian.org/webmaster-team/cron/-/merge_requests/13


Thanks
Holger



-- 
Holger Wansing 
PGP-Fingerprint: 496A C6E8 1442 4B34 8508  3529 59F1 87CA 156E B076

Bug#932957: #932957 Please migrate Release Notes to reStructuredText

[Holger Wansing]

Package: www.debian.org
Severity: normal

[Re-send once more; first try one month ago did not make it into the BTS]


Paul Gevers  wrote (Thu, 24 Aug 2023 14:10:41 +0200):
> Hi Holger,
> 
> On 29-07-2023 21:29, Holger Wansing wrote:
> > I have worked out the last big blocker for this migration now.
> > That is, to allow the build on wolkenstein, which is happening via the
> > parts/7release-notes script in webmaster-team/cron git repo.
> 
> I have just requested webmaster to switch the bookworm build from the 
> master branch to the bookworm branch [1]. After that request gets merged 
> and deployed, I'd like you to publish your work in the master branch 
> such that we can work from there (and see the results too [2]). Because 
> in your worked we stopped making notes per architecture, we probably 
> need to make further changes to the webmaster archive, but let's first 
> build something.

Hey webmaster team,

please consider MR13 in webmaster's cron repo:

https://salsa.debian.org/webmaster-team/cron/-/merge_requests/13


Thanks
Holger



-- 
Holger Wansing 
PGP-Fingerprint: 496A C6E8 1442 4B34 8508  3529 59F1 87CA 156E B076

Bug#1053305: Fw: https://www.debian.org/doc/packaging-manuals/copyright-format/1.0/ examples suffer escape damage

[Holger Wansing]

Control: tags -1 + patch


наб  wrote:
>  You should have received a copy of the GNU General Public License
>  along with this package; if not, see https://www.gnu.org/licenses/;.
> -- >8 --
> and I almost just copied this into d/copyright verbatim.
> 
> Oddly, all other <> pairs, even in those same  hunks,
> are correctly (un)escaped? So unclear to me how this happened.

Using   entites does not work here.
Should be replaced by < >.

Patch (tested) attached.


-- 
Holger Wansing 
PGP-Fingerprint: 496A C6E8 1442 4B34 8508  3529 59F1 87CA 156E B076
diff --git a/copyright-format-1.0.xml b/copyright-format-1.0.xml
index 954a65b..0920a84 100644
--- a/copyright-format-1.0.xml
+++ b/copyright-format-1.0.xml
@@ -1283,7 +1283,7 @@ License: GPL-2+
  GNU General Public License for more details.
  .
  You should have received a copy of the GNU General Public License
- along with this package; if not, see https://www.gnu.org/licenses/;.
+ along with this package; if not, see <https://www.gnu.org/licenses/>.
 Comment:
  On Debian systems, the full text of the GNU General Public License
  version 2 can be found in the file '/usr/share/common-licenses/GPL-2'.
@@ -1363,7 +1363,7 @@ License: GPL-2+
  GNU General Public License for more details.
  .
  You should have received a copy of the GNU General Public License
- along with this package; if not, see https://www.gnu.org/licenses/;.
+ along with this package; if not, see <https://www.gnu.org/licenses/>.
 Comment:
  On Debian systems, the full text of the GNU General Public License
  version 2 can be found in the file '/usr/share/common-licenses/GPL-2'.]]>

Bug#1053305: Fw: https://www.debian.org/doc/packaging-manuals/copyright-format/1.0/ examples suffer escape damage

[Holger Wansing]

Package: debian-policy
Severity: minor
X-Debbugs-CC: наб 


This has to be fixed in the package.
Turning this into a bugreport against debian-policy.




Date: Sun, 1 Oct 2023 01:42:47 +0200
From: наб 
To: debian-...@lists.debian.org
Subject: https://www.debian.org/doc/packaging-manuals/copyright-format/1.0/ 
examples suffer escape damage


File appears untagged, as does everything up to /doc. So posting here.

https://www.debian.org/doc/packaging-manuals/copyright-format/1.0/,
Example 3. Simple and Example 4. Complex say
-- >8 --
 You should have received a copy of the GNU General Public License
 along with this package; if not, see https://www.gnu.org/licenses/;.
-- >8 --
and I almost just copied this into d/copyright verbatim.

Oddly, all other <> pairs, even in those same  hunks,
are correctly (un)escaped? So unclear to me how this happened.

Best,
наб


-- 
Holger Wansing 
PGP-Fingerprint: 496A C6E8 1442 4B34 8508  3529 59F1 87CA 156E B076


signature.asc
Description: PGP signature

Bug#1052488: Persian translation [ Re: mrtg 2.17.10-10: Please translate debconf PO for the package mrtg ]

[Holger Wansing]

Package: mrtg
Severity: wishlist
Tags: patch,l10n


Danial Behzadi  wrote (Fri, 08 Sep 2023 22:43:27 +0330):
> This is the Persian (fa) translation file attached:

I'm submitting this into a bug against mrtg, so that it doesn't get lost on 
this 
mailinglist.


Holger



-- 
Holger Wansing 
PGP-Fingerprint: 496A C6E8 1442 4B34 8508  3529 59F1 87CA 156E B076


mrtg.fa.po.gz
Description: application/gzip

Bug#932957: #932957 Please migrate Release Notes to reStructuredText

[Holger Wansing]

Package: www.debian.org
Severity: normal


Paul Gevers  wrote (Thu, 24 Aug 2023 14:10:41 +0200):
> Hi Holger,
> 
> On 29-07-2023 21:29, Holger Wansing wrote:
> > I have worked out the last big blocker for this migration now.
> > That is, to allow the build on wolkenstein, which is happening via the
> > parts/7release-notes script in webmaster-team/cron git repo.
> 
> I have just requested webmaster to switch the bookworm build from the 
> master branch to the bookworm branch [1]. After that request gets merged 
> and deployed, I'd like you to publish your work in the master branch 
> such that we can work from there (and see the results too [2]). Because 
> in your worked we stopped making notes per architecture, we probably 
> need to make further changes to the webmaster archive, but let's first 
> build something.

Hey webmaster team,

please consider MR13 in webmaster's cron repo:

https://salsa.debian.org/webmaster-team/cron/-/merge_requests/13


Thanks
Holger



-- 
Holger Wansing 
PGP-Fingerprint: 496A C6E8 1442 4B34 8508  3529 59F1 87CA 156E B076

Bug#1051178: broken security manual link on debian portal

[Holger Wansing]

Package: harden-doc
Severity: minor


Aeou ROUND  wrote (Thu, 24 Aug 2023 21:35:35 +0200):
> 
> the .pdf version shows a broken link page "please inform our team of this
> broken link".
> 
> https://www.debian.org/doc/manuals/securing-debian-manual/changelog.en.html

thanks for the hint.

However, there is nothing the webpage people can do about this in the first
instance, because the Debian package "harden-doc" (this is the package which
holds the Securing Debian manual) does not contain any txt or pdf file for
the manual.
As a consequence, they cannot be displayed on the webpage as well :-(


So, this has to be fixed in the package first.

Turning this into a bugreport against harden-doc.
Thanks

Holger



-- 
Holger Wansing 
PGP-Fingerprint: 496A C6E8 1442 4B34 8508  3529 59F1 87CA 156E B076

Bug#932957: #932957 Please migrate Release Notes to reStructuredText

[Holger Wansing]

Hi,

Paul Gevers  wrote (Thu, 24 Aug 2023 14:10:41 +0200):
> Hi Holger,
> 
> On 29-07-2023 21:29, Holger Wansing wrote:
> > I have worked out the last big blocker for this migration now.
> > That is, to allow the build on wolkenstein, which is happening via the
> > parts/7release-notes script in webmaster-team/cron git repo.
> 
> I have just requested webmaster to switch the bookworm build from the 
> master branch to the bookworm branch [1]. After that request gets merged 
> and deployed, I'd like you to publish your work in the master branch 
> such that we can work from there (and see the results too [2]). Because 
> in your worked we stopped making notes per architecture, we probably 
> need to make further changes to the webmaster archive, but let's first 
> build something.

Please note, that the webmaster-team/cron script has to be overworked,
to deal with the new reST format.
I have prepared that in 
https://salsa.debian.org/holgerw/cron/-/commits/master?ref_type=heads
(as written above).


Rationale:
It is common for all documentation packages we have on www.debian/doc,
that the package itself creates files during package build, which do not
fit into the webpage system (main point: content negotiation).
To deal with this, someone from the ddp team has developed a script
(long ago; don't know by head who was this), that renames the files 
to fit the webpage (basically this is about adding the language
extension). This is in webmaster-team/cron/parts/7doc.

With the old docbook release-notes, this has been dealed with directly
in the build script.
Now in the new reST world, I have basically copied the whole build 
mechanism from the developers-reference as is, with the intention to
rely on the mechanism from the 7doc script mentioned above
(the 7doc script has been adapted explicitly for reST/sphinx).

The release-notes have always been a corner case when it comes to how
they were built, compared to all other docs:
the r-n are built from source explicitly for the website, while for all 
the other documentation we just unpack their binary debian packages,
rename the files via 7doc and that's it.
This does not work for the r-n, because there is no Debian package existing
for them.
So the r-n are always a separate world.
Based on that, I have kept the 7doc mechanism separately too, copied into
the new 7release-notes.
Means the 7release-notes script from webmaster-team/cron git repo
gets extremely expanded, to copy (and adjust) the functionality from 7doc.

I have developed and tested this here locally, it should work fine.

So I have created a merge request to get this done for the website:
https://salsa.debian.org/webmaster-team/cron/-/merge_requests/13


Best regards
Holger

-- 
Holger Wansing 
PGP-Fingerprint: 496A C6E8 1442 4B34 8508  3529 59F1 87CA 156E B076

Bug#684128: src:debian-installer: allow use of binary units in disk partitioner

[Holger Wansing]

Hi,

Holger Wansing  wrote (Wed, 16 Aug 2023 19:40:38 +0200):
> Hi,
> 
> Thorsten Glaser  wrote (Fri, 28 Jul 2023 19:53:52 + 
> (UTC)):
> > Holger Wansing dixit:
> > 
> > >>Could this information (valid unit sufficēs) be added to the dialogue
> > >>where the size is entered? Screen space should suffice.
> > >
> > >Yes, I already thought about if changing the template would make sense 
> > >here.
> > 
> > Thanks!
> 
> Just pushed (to partman-partitioning, partman-auto-lvm and partman-lvm).

And uploaded:
- partman-partitioning 148
- partman-auto-lvm 92
- partman-lvm 147


-- 
Holger Wansing 
PGP-Fingerprint: 496A C6E8 1442 4B34 8508  3529 59F1 87CA 156E B076

Bug#1049919: #1049919 installation-guide: add information about how to append boot parameters to the installer?

[Holger Wansing]

Control: reassign -1 installation-guide
-- 
Sent from /e/ OS on Fairphone3

Bug#1049919: #1049919 d-i: pressing ESC in graphical installer does nothing, unable to preseed installation

[Holger Wansing]

Control: retitle -1 installation-guide: add information about how to append 
boot parameters to the installer?


Ernesto Alfonso  wrote:
> The docs for preseeding debian recommend pressing ESC after entering
> the graphical installer menu:
> 
> 
> > Loading the preseeding file from a webserver
> > Most install methods you can interrupt early on and add a URL to a preseed 
> > file, for an almost fully automated installations. Here exemplified with 
> > the graphical installer:
> > 
> > When the graphical installer boot menu appears, press ESC
> > 
> > (Type "help" if you want view generic help)
> > Type "auto url=http://webserver/path/preseed.cfg;, replacing the URL with 
> > the address to your preseed configuration file
> > 
> 
> But when pressing ESC after selecting the debian bookworm graphical 
> installer, nothing happens.
> 
> I am using the amd64 DVD-1 ISO image: debian-12.0.0-amd64-DVD-1.iso

I found that you refer to the Debian Wiki at
https://wiki.debian.org/DebianInstaller/Preseed
when you talk about "docs for preseeding debian" above.

Please note, that the Wiki is not the "official" documentation for our 
installer.
That would be the installation-guide, see 
https://www.debian.org/releases/stable/installmanual
A chapter about preseeding installation is at
https://www.debian.org/releases/stable/amd64/apb.en.html

That being said, I see that the information on the Wiki page you mentioned 
is outdated and thus no longer working.
I have updated it now in that regard.




Moreover, I notice that we probably have some deficit in the installation-guide,
when it comes to information about how to append boot parameters to the 
installer
(at least for some architectures).

For amd64 and ii386 that is mentioned in chapter "5.1.5. The Boot Screen"
see https://www.debian.org/releases/stable/amd64/ch05s01.en.html#boot-screen

and s390x has it in "5.1.2. S/390 Boot Parameters"
https://www.debian.org/releases/stable/s390x/ch05s01.en.html

But for all other archs I cannot find any such information.

Would it make sense to add that?
(OTOH, nobody has complained about that for years, so maybe it's not necessary?)


Holger




-- 
Holger Wansing 
PGP-Fingerprint: 496A C6E8 1442 4B34 8508  3529 59F1 87CA 156E B076

Bug#684128: src:debian-installer: allow use of binary units in disk partitioner

[Holger Wansing]

Hi,

Thorsten Glaser  wrote (Fri, 28 Jul 2023 19:53:52 + (UTC)):
> Holger Wansing dixit:
> 
> >>Could this information (valid unit sufficēs) be added to the dialogue
> >>where the size is entered? Screen space should suffice.
> >
> >Yes, I already thought about if changing the template would make sense here.
> 
> Thanks!

Just pushed (to partman-partitioning, partman-auto-lvm and partman-lvm).


> Could we also get the size output in both formats? I realise that
> will most likely not be a change as simple…


Holger

-- 
Holger Wansing 
PGP-Fingerprint: 496A C6E8 1442 4B34 8508  3529 59F1 87CA 156E B076

Bug#684128: src:debian-installer: allow use of binary units in disk partitioner

[Holger Wansing]

Hi,

Am 13. August 2023 10:46:50 MESZ schrieb Richard Lewis 
:
>Holger Wansing  writes:
>
> (Terabytes), 10TiB (Tebibytes). The default unit is Megabytes.
> ^^
>
>I wonder if this last word is a typo and should say Gigabytes? (if not
>please consider changing the installer default - no-one is going to be
>happy to have accidentally made a MB-sized partition!)

No, that's no typo. And the patch does not touch this.
So, it's just the current status quo.

But I will evaluate, if that should be changed.

>I reads OK as-is, but to avoid repetition of 'enter the size' you could
>start the second sentence with something like "You can use the following
>formats:"

LGTM, thanks


Holger

-- 
Sent from /e/ OS on Fairphone3

Bug#684128: src:debian-installer: allow use of binary units in disk partitioner

[Holger Wansing]

Hi,

Justin B Rye  wrote (Fri, 28 Jul 2023 10:04:09 
+0100):
> Holger Wansing wrote:
> > Thorsten Glaser :
> >> Could this information (valid unit sufficēs) be added to the dialogue
> >> where the size is entered? Screen space should suffice.
> [...]
> > CC'ing debian-l10n-english for template review (three identical additions
> > in two packages).

I found there is another template, which needs to be changed for this.

Patch attached (especially for review on l10n-english).


Holger



-- 
Holger Wansing 
PGP-Fingerprint: 496A C6E8 1442 4B34 8508  3529 59F1 87CA 156E B076
diff --git a/debian/partman-lvm.templates b/debian/partman-lvm.templates
index 509d9a7..63219c0 100644
--- a/debian/partman-lvm.templates
+++ b/debian/partman-lvm.templates
@@ -376,8 +376,9 @@ Type: string
 # :sl3:
 _Description: Logical volume size:
  Please enter the size of the new logical volume. The size may be
- entered in the following formats: 10K (Kilobytes), 10M (Megabytes),
- 10G (Gigabytes), 10T (Terabytes). The default unit is Megabytes.
+ entered in the following formats: 10KB (Kilobytes), 10KiB (Kibibytes), 10MB
+ (Megabytes), 10MiB (Mebibytes), 10GB (Gigabytes), 10GiB (Gibibytes), 10TB
+ (Terabytes), 10TiB (Tebibytes). The default unit is Megabytes.
 
 Template: partman-lvm/lvcreate_error
 Type: error

Bug#1042779: developers-reference: overhaul of chapter about i18n / l10n

[Holger Wansing]

Package: developers-reference
Severity: normal


Hi,

yesterday I was a bit shocked when reading chapter 8 of the developers-ref:
https://www.debian.org/doc/manuals/developers-reference/l10n.en.html

That chapter has several wrong/bad sentences (or is heavily outdated, if that
things have been correct like that at some time).

I comment here on the different parts; a complete patch which integrates all
this proposals is attached to this mail.



"For program messages, the gettext infrastructure is used most of the time. 
Most of the time, the translation is handled upstream within projects like the 
Free Translation Project, the GNOME Translation Project or the KDE Localization 
project.


... is used most of the time. Most of the time, the translation ...

Please avoid this doubled use of "most of the time" in direct repeating.
(only cosmetic, yes.)



The only centralized resources within Debian are the Central Debian 
translation statistics, where you can find some statistics about the 
translation 
files found in the actual packages, but no real infrastructure to ease the 
translation process."


... where you can find some statistics ... but no real infrastructure to ease 
the 
translation process.

This is not true. The statistics page provides the possibility to directly
download the po files by one click! This is for sure much easier than
loading the whole source package, uncompress it and pick the po file out from
there! So, it's much more than just a statistics page, and it makes translators
work much easier!
(What was meant here is probably, that Debian has no own pootle or Weblate
server, where the translation can be done directly online?)




For debconf templates, maintainers should use the po-debconf package to ease 
the work of translators, who could use the DDTP to do their work (but the 
French and Brazilian teams don't). Some statistics can be found both on the 
DDTP site (about what is actually translated), and on the Central Debian 
translation statistics site (about what is integrated in the packages).


Here we have some wrong facts. The DDTP infrastructure is only for translating
the package descriptions!
It does not handle debconf template translations!
And the DDTP site does not have statistics about debconf template translations.
(Don't know, if this was different in the past, but this is the status quo.)



For package-specific documentation (man pages, info documents, other formats),
almost everything remains to be done.


This is also not true!
We have many translated manpages now for example, so we cannot say 
"nothing has been done on this".




For all other material (gettext files, man pages, or other documentation), the 
best solution is to put your text somewhere on the Internet, and ask on 
debian-i18n for a translation in different languages. Some translation team 
members are subscribed to this list, and they will take care of the translation 
and of the reviewing process. Once they are done, you will get your translated 
document from them in your mailbox.


... the best solution is to put your text somewhere on the Internet ...

This seems rather weird for me. Debian is such a huge community with much
infrastructure, we should not recommend to "put the text somewhere on the 
Internet". That sounds poor.


... Once they are done, you will get your translated document from them in 
your mailbox. ...

There is a big consensus, that translations are sent via wishlist bugreports.



Please find a patch attached (can be seen as a proposal, of course).


So long
Holger


-- 
Holger Wansing 
PGP-Finterprint: 496A C6E8 1442 4B34 8508  3529 59F1 87CA 156E B076
diff --git a/source/l10n.rst b/source/l10n.rst
index c66173d..8935907 100644
--- a/source/l10n.rst
+++ b/source/l10n.rst
@@ -42,7 +42,7 @@ manual task, and the process depends on the kind of text you want to see
 translated.
 
 For program messages, the gettext infrastructure is used most of the
-time. Most of the time, the translation is handled upstream within
+time. Often the translation is handled upstream within
 projects like the `Free Translation
 Project <https://translationproject.org/html/welcome.html>`__, the
 `GNOME Translation
@@ -51,7 +51,7 @@ Localization <https://l10n.kde.org/>`__ project. The only centralized
 resources within Debian are the `Central Debian translation
 statistics <https://www.debian.org/intl/l10n/>`__, where you can find
 some statistics about the translation files found in the actual
-packages, but no real infrastructure to ease the translation process.
+packages and download those files.
 
 Package descriptions have translations since many years and Maintainers
 don't need to do anything special to support translated package
@@ -59,12 +59,9 @@ descriptions; translators should use the `Debian Description Translation
 Project (DDTP) <https://ddtp.debian.org/>`__.
 
 For ``debconf`` templates, maintainers should use the ``

Bug#932957: #932957 Please migrate Release Notes to reStructuredText

[Holger Wansing]

Hi,

Richard Lewis  wrote (Sun, 30 Jul 2023 
21:32:36 +0100):
> sorry - it's the use of italic in eg '# apt-mark auto rsyslog'
> https://people.debian.org/~holgerw/release-notes_sphinx/www.debian.org/releases/trixie/release-notes/issues.en.html#changes-to-system-logging
> 
> 
> i found
> https://stackoverflow.com/questions/16397794/how-to-show-terminal-shell-code-snippets-in-sphinx
> which i think says that 'code-block:: console' might be better than
> 'code-block:: shell', but i may be misunderstanding that page

Yes, 'code-block:: console' indeed works fine for most occurrences.
So I unified 
'code-block:: text'
'code-block:: shell'
'code-block:: shell-session'
to
'code-block:: console'


The only case where that doesn't work is, when substitutions are included.
They only work within  '.. parsed-literal::' sadly :-(



Holger


-- 
Holger Wansing 
PGP-Fingerprint: 496A C6E8 1442 4B34 8508  3529 59F1 87CA 156E B076