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

2024-03-16 Thread 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

2024-03-16 Thread 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

2024-03-12 Thread 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

2024-03-09 Thread 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

2024-03-07 Thread 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

2024-03-06 Thread 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

2024-03-05 Thread 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

2024-03-05 Thread 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

2024-03-04 Thread 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

2024-03-04 Thread 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

2024-03-04 Thread 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

2024-03-03 Thread 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

2024-03-02 Thread 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

2024-03-01 Thread 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

2024-02-29 Thread 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

2024-02-25 Thread 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

2024-02-24 Thread 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

2024-02-23 Thread 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

2024-02-15 Thread 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

2024-02-11 Thread 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

2024-02-08 Thread 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

2024-02-07 Thread 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

2024-01-11 Thread 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

2024-01-03 Thread 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

2024-01-01 Thread 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

2023-12-31 Thread 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

2023-12-30 Thread 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"

2023-12-02 Thread 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

2023-12-01 Thread 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

2023-11-29 Thread 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

2023-11-25 Thread 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

2023-11-25 Thread Holger Wansing
see 


-- 
Sent from /e/ OS on Fairphone3



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

2023-11-25 Thread 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

2023-11-24 Thread 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)

2023-11-24 Thread 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)

2023-11-24 Thread 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

2023-11-24 Thread 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)

2023-11-24 Thread 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

2023-11-22 Thread 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

2023-11-18 Thread 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)

2023-11-18 Thread 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

2023-11-13 Thread 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

2023-11-11 Thread 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

2023-11-10 Thread 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

2023-10-29 Thread 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

2023-10-23 Thread 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)

2023-10-22 Thread 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'

2023-10-04 Thread 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'

2023-10-04 Thread 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

2023-10-04 Thread 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'

2023-10-04 Thread 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'

2023-10-04 Thread 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

2023-10-04 Thread 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

2023-10-01 Thread 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

2023-10-01 Thread 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 ]

2023-09-22 Thread 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

2023-09-03 Thread 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

2023-09-03 Thread 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

2023-08-25 Thread 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

2023-08-23 Thread 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?

2023-08-20 Thread 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

2023-08-20 Thread 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

2023-08-16 Thread 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

2023-08-13 Thread 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

2023-08-12 Thread 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

2023-07-31 Thread 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

2023-07-31 Thread 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



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

2023-07-30 Thread Holger Wansing
Hi,

Richard Lewis  wrote (Sun, 30 Jul 2023 
11:10:10 +0100):
> in [0] the '#' is meant to indicate 'run this as root', but the rst has
> '.. code-block:: shell' so the commands are being formatted as a
> comment.

Yes, there are different methods for including quoted material, and they are
somewhat tricky sometimes.

I may lack detailed experience on this, so need more details:
- What's the exact URL where you found this? (there was no such link as [0])
- What makes you think, that the commands are formatted as comment?
  Is it the font color or what?

> in [1] the second para is dummy text that is commented out in the XML
> version.  

This reST version of r-n is kind of a draft, so it's not as ready as it would
be when in publication mode. Such details slipped through, sorry.

> In the rst 'source' (but not visible in the html) there are
> also some odd chars around 'formal' (the quotes seems to be fine in the
> sections above).

Reason for this was: there were different quote signs used in those sections.
I changed “this” quotes into "this" ones. That solves the problem.

> [1] 
> https://people.debian.org/~holgerw/release-notes_sphinx/www.debian.org/releases/trixie/release-notes/issues.en.html#things-to-do-post-upgrade-before-rebooting
> 
> in [2] there seems to be an extra space in the RH column in
> 'c a-certificates-java' (in the source there is a linebreak after the c)

Also fixed.
However, this section is also kind of a placeholder, it will get replaced
with a updated list. But fixing the format is a good idea nevertheless.

> [2] 
> https://people.debian.org/~holgerw/release-notes_sphinx/www.debian.org/releases/trixie/release-notes/issues.en.html#known-severe-bugs
> 
> (And
> https://people.debian.org/~holgerw/release-notes_sphinx/www.debian.org/releases/trixie/release-notes/about.en.html#sources-for-this-document
> will need an update! - as will the README in salsa)

For sure. I am aware of this.

Holger



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



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

2023-07-29 Thread Holger Wansing
Hi,

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 forked that repo and committed my changings there:
https://salsa.debian.org/holgerw/cron/-/commits/master?ref_type=heads


Tests were successful, the results can be found on
https://people.debian.org/~holgerw/release-notes_sphinx/www.debian.org/,
in the exact same structure as they would appear on the Debian website.
The release-notes dir 
https://people.debian.org/~holgerw/release-notes_sphinx/www.debian.org/releases/trixie/release-notes/
holds the html files for all languages, but content negotiation does not 
work there apparently; and the apache server does not show a file browser 
view for that directory.
You can find German for example via
https://people.debian.org/~holgerw/release-notes_sphinx/www.debian.org/releases/trixie/release-notes/index.de.html
or Dutch via
https://people.debian.org/~holgerw/release-notes_sphinx/www.debian.org/releases/trixie/release-notes/index.nl.html
And remember, there is only one generic variant for all archs now!



The build process in 7releases-notes is now different between stable
and testing: stable is still on docbook, and testing is on sphinx/
reStructuredText.

So, when the time comes, we could create a bookworm branch for r-n, 
migrate master to sphinx, and activate the build on wolkenstein for
master/trixie.
That way, we have a comfortable test time, to get everything ready
on the website (Note: there are changings to do on the website then),
while the r-n for trixie are not in public attention.


So long

Holger


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



Bug#1042437: partman-auto-lvm: using binary units for size of volume group does not work correctly

2023-07-28 Thread Holger Wansing
Package: partman-auto-lvm
Severity: normal


With a bookworm 12.0 netinst image:
when choosing guided partitioning -> set up LVM, it is now allowed to use
binary units for volume group size (MiB, GiB, ...), but the size is wrongly
calculated.
For example, if I choose a volume group of 12 GiB, I get one with 11,9 GB, but 
it should be roughly 12,9 GB.

Using the manual way of configuring (so not guided partitioning, but manual),
it works correctly.


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

2023-07-28 Thread Holger Wansing
Hi,


Am 26. Juli 2023 23:19:31 MESZ schrieb Thorsten Glaser :
>
>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.



That would require synchron changings in partman-partitioning and
partman-auto-lvm.


Patches attached as a proposal.
CC'ing debian-l10n-english for template review (three identical additions
in two packages).


Holger







diff --git a/debian/partman-partitioning.templates b/debian/partman-partitioning.templates
index 8464201..298a3ae 100644
--- a/debian/partman-partitioning.templates
+++ b/debian/partman-partitioning.templates
@@ -25,30 +25,32 @@ _Description: Write previous changes to disk and continue?
  .
  You cannot undo this operation.
  .
  Please note that the resize operation may take a long time.
 
 Template: partman-partitioning/new_size
 Type: string
 Default: some number
 # :sl2:
 _Description: New partition size:
  The minimum size for this partition is ${MINSIZE} (or ${PERCENT}) and its
  maximum size is ${MAXSIZE}.
  .
  Hint: "max" can be used as a shortcut to specify the maximum size, or
  enter a percentage (e.g. "20%") to use that percentage of the maximum size.
+ You can specify partition sizes in decimal units (like MB or GB) as well as
+ in binary units (like GiB or TiB).
 
 Template: partman-partitioning/bad_new_size
 Type: error
 # :sl2:
 _Description: The size entered is invalid
  The size you entered was not understood.
  Please enter a positive integer size followed by an optional unit of measure
  (e.g. "200 GB"). The default unit of measure is the megabyte.
 
 Template: partman-partitioning/big_new_size
 Type: error
 # :sl2:
 _Description: The size entered is too large
  The size you entered is larger than the maximum size of the partition.
  Please enter a smaller size to continue.
@@ -65,30 +67,32 @@ Type: error
 # :sl2:
 _Description: Resize operation failure
  An error occurred while writing the changes to the storage devices.
  .
  The resize operation has been aborted.
 
 Template: partman-partitioning/new_partition_size
 Type: string
 Default: some number
 # :sl2:
 _Description: New partition size:
  The maximum size for this partition is ${MAXSIZE}.
  .
  Hint: "max" can be used as a shortcut to specify the maximum size, or
  enter a percentage (e.g. "20%") to use that percentage of the maximum size.
+ You can specify partition sizes in decimal units (like MB or GB) as well as
+ in binary units (like GiB or TiB).
 
 Template: partman-partitioning/bad_new_partition_size
 Type: error
 # :sl2:
 _Description: Invalid size
 
 Template: partman-partitioning/new_partition_place
 Type: select
 # :sl1:
 __Choices: Beginning, End
 # :sl1:
 _Description: Location for the new partition:
  Please choose whether you want the new partition to be created at the
  beginning or at the end of the available space.
 
diff --git a/debian/partman-auto-lvm.templates b/debian/partman-auto-lvm.templates
index 271294e..f5f4bbd 100644
--- a/debian/partman-auto-lvm.templates
+++ b/debian/partman-auto-lvm.templates
@@ -79,30 +79,32 @@ Type: string
 Default: some number
 # :sl3:
 _Description: Amount of volume group to use for guided partitioning:
  You may use the whole volume group for guided partitioning, or part of it.
  If you use only part of it, or if you add more disks later, then you will
  be able to grow logical volumes later using the LVM tools, so using a
  smaller part of the volume group at installation time may offer more
  flexibility.
  .
  The minimum size of the selected partitioning recipe is ${MINSIZE} (or
  ${PERCENT}); please note that the packages you choose to install may
  require more space than this. The maximum available size is ${MAXSIZE}.
  .
  Hint: "max" can be used as a shortcut to specify the maximum size, or
  enter a percentage (e.g. "20%") to use that percentage of the maximum size.
+ You can specify partition sizes in decimal units (like MB or GB) as well as
+ in binary units (like GiB or TiB).
 
 Template: partman-auto-lvm/bad_guided_size
 Type: error
 # :sl3:
 _Description: Invalid input
  You entered "${INPUT}", which was not recognized as a valid size.
 
 Template: partman-auto-lvm/big_guided_size
 Type: error
 # :sl3:
 _Description: ${SIZE} is too big
  You asked for ${SIZE} to be used for guided partitioning, but the available
  space is only ${MAXSIZE}.
 
 Template: partman-auto-lvm/small_guided_size


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

2023-07-26 Thread Holger Wansing


Thorsten Glaser  wrote (Tue, 25 Jul 2023 20:15:04 + (UTC)):
> why is this bug still unfixed?
> 
> In bookworm d-i, entering 512 MiB seems to be using something
> entirely different, and 512 Mi gives an error “invalid size”.
> 
> This still makes d-i unsuitable for most partitioning.

With a 12.0 netinst image, creating a new partition with a size of 512 MiB
results in a parition of 536 MB, creating a partiton of 10 GiB results in
a partition of 10,7 GB.
So I guess it works as it should.

The (visual) output is still in MB / GB, apart from this a see no issue.


Holger

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



Bug#1040713: bookworm-pu: package installation-guide/20230508+deb12u1

2023-07-09 Thread Holger Wansing
Package: release.debian.org
Severity: normal
Tags: bookworm
User: release.debian@packages.debian.org
Usertags: pu

Hi,

some months ago, we received a new, complete translation of the 
installation-guide
into Indonesian.
However, I failed to turn all needed wheels, to get this translation into the
package completely. 
Therefore, Indonesian translation is currently not visible on debian.org :-(

So I ask for this minor update to get that into stable (bookworm).

debdiff attached.

Thanks for considering.


Holger

-- 
Holger Wansing 
PGP-Fingerprint: 496A C6E8 1442 4B34 8508  3529 59F1 87CA 156E B076
diff -Nru installation-guide-20230508/debian/changelog 
installation-guide-20230508+deb12u1/debian/changelog
--- installation-guide-20230508/debian/changelog2023-05-08 
22:47:33.0 +0200
+++ installation-guide-20230508+deb12u1/debian/changelog2023-07-09 
15:25:17.0 +0200
@@ -1,3 +1,11 @@
+installation-guide (20230508+deb12u1) bookworm; urgency=medium
+
+  [ Holger Wansing ]
+  * Add Indonesian (as a recently added new translation) to langlist, to get
+this translation into the package.
+
+ -- Samuel Thibault   Sun, 09 Jul 2023 15:25:17 +0200
+
 installation-guide (20230508) unstable; urgency=medium
 
   [ Samuel Thibault ]
diff -Nru installation-guide-20230508/debian/langlist 
installation-guide-20230508+deb12u1/debian/langlist
--- installation-guide-20230508/debian/langlist 2023-05-08 22:47:33.0 
+0200
+++ installation-guide-20230508+deb12u1/debian/langlist 2023-06-23 
01:16:32.0 +0200
@@ -12,6 +12,7 @@
 #fiFinnish
 fr French
 #huHungarian
+id Indonesian
 it Italian
 ja Japanese
 #kab   Kabyle


Bug#932957: no longer build arch-dependent variants of r-n?

2023-06-25 Thread Holger Wansing
Hi,

Holger Wansing  wrote (Sun, 18 Jun 2023 14:32:25 +0200):
> That gives us the possibility, to simplify the whole r-n thing to only build 
> one generic release-notes variant for all archs, in the different languages, 
> and we are done.
> 
> How does that sound?

Status update:

1.
I have reduced the build chain to only build one generic arch-independent
variant of r-n, for all languages. It has all the content, and it's just named
"Release Notes for Debian 12 (bookworm)"
no longer mentioning any arch name in the title, and without any arch-name
reference in the whole document.

Note: If we decide to go with such approach, the website would need an 
overhaul because of this!!!


2. 
I added some sort of a basic-level draft mode:
Sphinx does not have support for a watermark, as dblatex had (at least not 
in the sphinx version/packages we have in Debian; there is a contrib
extension 'sphinxmark' which does that, but that's not available in
Sphinx mainstream).

So I have just added a bold 
"DRAFT MODE - in development for the next release"
on the html index page.

Maybe someone has better ideas?
AFAICS we could go forward with this via using a different html layout
template, or using a different theme, but I could not get that running.


The current version can still be found at
https://people.debian.org/~holgerw/release-notes_sphinx
for all languages and in html|text|pdf
(or grab the results from Salsa's CI at
https://salsa.debian.org/holgerw/release-notes/-/pipelines
which builds fine now.)


Holger



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



Bug#932957: no longer build arch-dependent variants of r-n?

2023-06-18 Thread Holger Wansing
Hi,

Holger Wansing  wrote (Wed, 14 Jun 2023 21:50:18 +0200):
> Paul Gevers  wrote (Wed, 14 Jun 2023 21:19:00 +0200):
> > Also, on the topic of arch-specific builds, I not convinced it's worth a 
> > lot of effort. The amount of arch specific pieces is rather limited, so 
> > I wouldn't mind if we drop that altogether. Currently, we don't do a 
> > great service to people that need to support multiple architectures, 
> > because they need to *search* for the delta's, so I wouldn't be 
> > surprised if it is even better if we drop it.
> 
> From the technical side, I managed to get the arch-specific builds done in
> the meantime basically; so no problem anymore there - theoretically.
> 
> On the other side, I also thought about the arch-specific differences, and
> given they are only rather small, my assumption was, that it's maybe not worth
> it to differentiate between archs, when it comes to filtering out content
> of r-n depending on the architecture.
> But even if we leave that point out, there are some arch-dependent links like
> http://mirrors.kernel.org/debian/dists/bookworm/main/binary-amd64/...
> in chapter 4.3.1
> https://www.debian.org/releases/stable/amd64/release-notes/ch-upgrading.en.html#network
> 
> So, we still need to build the release-notes differentiated by archs
> (based on the current content).
> 
> 
> 
> However, that does not mean, we could not change our base rules, so that
> filtering out chapters based on architecture is no longer used.
> I would vote for this solution, yes.

Thinking a bit more about this, I wonder if we could indeed get rid of 
architecture-dependent r-n at all.

If all paragraphs/chapters are visible for all archs anyway, there are
only two situations where the arch shortname (amd64, i386 etc.) is used
in URLs. That is in
https://www.debian.org/releases/stable/amd64/release-notes/ch-upgrading.en.html#network
and
https://www.debian.org/releases/stable/amd64/release-notes/ch-upgrading.en.html#localmirror


   For example, suppose your closest Debian mirror is 
http://mirrors.kernel.org. 
   If you inspect that mirror with a web browser, you will notice that the main 
   directories are organized like this:

   http://mirrors.kernel.org/debian/dists/bookworm/main/binary-amd64/...
   http://mirrors.kernel.org/debian/dists/bookworm/contrib/binary-amd64/...

   To configure APT to use a given mirror, add a line like this (again, 
   assuming you are using main and contrib):

   deb http://mirrors.kernel.org/debian bookworm main contrib


So, the arch-dependent directories on the mirrors are mentioned here, but the
arch part is not really relevant here. We could just skip the last part of 
the URL and point to
http://mirrors.kernel.org/debian/dists/bookworm/main/..
and that's it. The same counts for the second occurrence of arch shortname.

That gives us the possibility, to simplify the whole r-n thing to only build 
one generic release-notes variant for all archs, in the different languages, 
and we are done.

How does that sound?


Holger



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



Bug#1038413: DDP Documentation policy: should no longer recommend docbook xml

2023-06-17 Thread Holger Wansing
Package: www.debian.org
Severity: minor


https://www.debian.org/doc/ddp.en.html says under "Documentation Policy":

"We use Docbook XML for our documents."

Since some documents (Debian Policy, Developers Reference) have been migrated
to Sphinx/restructuredText alredy, can this be considered as the new recommend?

If so, the text should be updated to something like

"We use restructuredText or Docbook XML (deprecated) for our documents."



Holger


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



Bug#932957: Please migrate Release Notes to reStructuredText

2023-06-14 Thread Holger Wansing
Hi,

Paul Gevers  wrote (Wed, 14 Jun 2023 21:19:00 +0200):
> Also, on the topic of arch-specific builds, I not convinced it's worth a 
> lot of effort. The amount of arch specific pieces is rather limited, so 
> I wouldn't mind if we drop that altogether. Currently, we don't do a 
> great service to people that need to support multiple architectures, 
> because they need to *search* for the delta's, so I wouldn't be 
> surprised if it is even better if we drop it.

>From the technical side, I managed to get the arch-specific builds done in
the meantime basically; so no problem anymore there - theoretically.

On the other side, I also thought about the arch-specific differences, and
given they are only rather small, my assumption was, that it's maybe not worth
it to differentiate between archs, when it comes to filtering out content
of r-n depending on the architecture.
But even if we leave that point out, there are some arch-dependent links like
http://mirrors.kernel.org/debian/dists/bookworm/main/binary-amd64/...
in chapter 4.3.1
https://www.debian.org/releases/stable/amd64/release-notes/ch-upgrading.en.html#network

So, we still need to build the release-notes differentiated by archs
(based on the current content).



However, that does not mean, we could not change our base rules, so that
filtering out chapters based on architecture is no longer used.
I would vote for this solution, yes.



Holger



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



Bug#1037350: Package: installation-reports

2023-06-12 Thread Holger Wansing
Control: retitle -1 installation-reports: grub not installed (correctly)



-- 
Sent from /e/ OS on Fairphone3



Bug#1037350: Package: installation-reports

2023-06-12 Thread Holger Wansing
Control: rename -1 installation-reports: grub not installed (correctly)



Am 11. Juni 2023 22:45:34 MESZ schrieb Peter Ehlert :
>Package: installation-reports
>
>Boot method: USB
>Image version: debian-12.0.0-amd64-netinst.iso
>Date: 2023-06-11 9-16-23
>
>Machine: Type: Desktop System: Hewlett-Packard product: HP Z820 Workstation
>Processor: CPU: 2x 8-core Intel Xeon E5-2687W 0 (-MT MCP SMP-)
>Memory: Mem: 1310.8/48189.1 MiB (2.7%) Storage: 9.32 TiB (3.2% used)
>Partitions: 
>
>$ df -Tl
>Filesystem Type 1K-blocks    Used Available Use% Mounted on
>udev   devtmpfs  24639364   0  24639364   0% /dev
>tmpfs  tmpfs  4934568    2036   4932532   1% /run
>/dev/sdb24 ext4  28660644 4437152  22742276  17% /
>tmpfs  tmpfs 24672828   0  24672828   0% /dev/shm
>tmpfs  tmpfs 5120  12  5108   1% /run/lock
>/dev/sdb26 ext4  19046484    1228  18052388   1% /home
>tmpfs  tmpfs  4934564  80   4934484   1% /run/user/1000
>
>
>
>Output of lspci -knn (or lspci -nn):
>
>$ lspci -knn
>00:00.0 Host bridge [0600]: Intel Corporation Xeon E5/Core i7 DMI2 [8086:3c00] 
>(rev 07)
>    Subsystem: Hewlett-Packard Company Xeon E5/Core i7 DMI2 [103c:158b]
>00:01.0 PCI bridge [0604]: Intel Corporation Xeon E5/Core i7 IIO PCI Express 
>Root Port 1a [8086:3c02] (rev 07)
>    Subsystem: Hewlett-Packard Company Xeon E5/Core i7 IIO PCI Express Root 
>Port 1a [103c:158b]
>    Kernel driver in use: pcieport
>00:01.1 PCI bridge [0604]: Intel Corporation Xeon E5/Core i7 IIO PCI Express 
>Root Port 1b [8086:3c03] (rev 07)
>    Subsystem: Hewlett-Packard Company Xeon E5/Core i7 IIO PCI Express Root 
>Port 1b [103c:158b]
>    Kernel driver in use: pcieport
>00:02.0 PCI bridge [0604]: Intel Corporation Xeon E5/Core i7 IIO PCI Express 
>Root Port 2a [8086:3c04] (rev 07)
>    Subsystem: Hewlett-Packard Company Xeon E5/Core i7 IIO PCI Express Root 
>Port 2a [103c:158b]
>    Kernel driver in use: pcieport
>00:03.0 PCI bridge [0604]: Intel Corporation Xeon E5/Core i7 IIO PCI Express 
>Root Port 3a in PCI Express Mode [8086:3c08] (rev 07)
>    Subsystem: Hewlett-Packard Company Xeon E5/Core i7 IIO PCI Express Root 
>Port 3a in PCI Express Mode [103c:158b]
>    Kernel driver in use: pcieport
>00:05.0 System peripheral [0880]: Intel Corporation Xeon E5/Core i7 Address 
>Map, VTd_Misc, System Management [8086:3c28] (rev 07)
>    Subsystem: Hewlett-Packard Company Xeon E5/Core i7 Address Map, VTd_Misc, 
>System Management [103c:158b]
>00:05.2 System peripheral [0880]: Intel Corporation Xeon E5/Core i7 Control 
>Status and Global Errors [8086:3c2a] (rev 07)
>    Subsystem: Hewlett-Packard Company Xeon E5/Core i7 Control Status and 
>Global Errors [103c:158b]
>00:05.4 PIC [0800]: Intel Corporation Xeon E5/Core i7 I/O APIC [8086:3c2c] 
>(rev 07)
>    Subsystem: Intel Corporation Xeon E5/Core i7 I/O APIC [8086:3c2c]
>00:11.0 PCI bridge [0604]: Intel Corporation C600/X79 series chipset PCI 
>Express Virtual Root Port [8086:1d3e] (rev 05)
>    Subsystem: Hewlett-Packard Company C600/X79 series chipset PCI Express 
>Virtual Root Port [103c:158b]
>    Kernel driver in use: pcieport
>00:16.0 Communication controller [0780]: Intel Corporation C600/X79 series 
>chipset MEI Controller #1 [8086:1d3a] (rev 05)
>    Subsystem: Hewlett-Packard Company C600/X79 series chipset MEI Controller 
>[103c:158b]
>    Kernel driver in use: mei_me
>    Kernel modules: mei_me
>00:16.2 IDE interface [0101]: Intel Corporation C600/X79 series chipset IDE-r 
>Controller [8086:1d3c] (rev 05)
>    Subsystem: Hewlett-Packard Company C600/X79 series chipset IDE-r 
>Controller [103c:158b]
>    Kernel driver in use: ata_generic
>    Kernel modules: ata_generic
>00:16.3 Serial controller [0700]: Intel Corporation C600/X79 series chipset KT 
>Controller [8086:1d3d] (rev 05)
>    Subsystem: Hewlett-Packard Company C600/X79 series chipset KT Controller 
>[103c:158b]
>    Kernel driver in use: serial
>00:19.0 Ethernet controller [0200]: Intel Corporation 82579LM Gigabit Network 
>Connection (Lewisville) [8086:1502] (rev 05)
>    DeviceName: Onboard LAN
>    Subsystem: Hewlett-Packard Company 82579LM Gigabit Network Connection 
>(Lewisville) [103c:158b]
>    Kernel driver in use: e1000e
>    Kernel modules: e1000e
>00:1a.0 USB controller [0c03]: Intel Corporation C600/X79 series chipset USB2 
>Enhanced Host Controller #2 [8086:1d2d] (rev 05)
>    Subsystem: Hewlett-Packard Company C600/X79 series chipset USB2 Enhanced 
>Host Controller [103c:158b]
>    Kernel driver in use: ehci-pci
>    Kernel modules: ehci_pci
>00:1b.0 Audio device [0403]: Intel Corporation C600/X79 series chipset High 
>Definition Audio Controller [8086:1d20] (rev 05)
>    Subsystem: Hewlett-Packard Company C600/X79 series chipset High Definition 
>Audio Controller [103c:158b]
>    Kernel driver in use: snd_hda_intel
>    Kernel modules: snd_hda_intel
>00:1c.0 PCI bridge [0604]: Intel Corporation C600/X79 series chipset PCI 
>Express 

Bug#1037355: packages.debian.org: wrong mapping codename <-> stable

2023-06-11 Thread Holger Wansing
Package: www.debian.org

In the search form, at packages.debian.org, bullseye is still stable.

Please update the suites (similar to 
https://salsa.debian.org/webmaster-team/packages/-/commit/4648ee328d98a903bb9212b7ffb1f42fa9db773d)

The old issue of hardcoded suitenames ... (?)


Holger



-- 
Sent from /e/ OS on Fairphone3



Bug#1037316: www.debian.org: Download links on www.debian.org after release = no iso images, only BT

2023-06-11 Thread Holger Wansing
Hi,

Holger Wansing  wrote (Sun, 11 Jun 2023 13:54:43 +0200):
> That's correct, there are some things to update:
> - netinst images are now much larger due to included firmware, 
>   150-300 MB is no longer correct.
> - multi-arch netinst images are no longer being built

Now done with
https://salsa.debian.org/webmaster-team/webwml/-/commit/c64bdf15d82617c46942470ac0846ed7ec8b0f74

Affects
CD/http-ftp/index.wml
CD/netinst/index.wml 



Holger

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



Bug#1037316: www.debian.org: Download links on www.debian.org after release = no iso images, only BT

2023-06-11 Thread Holger Wansing
Hi,

"Andrew M.A. Cater"  wrote (Sun, 11 Jun 2023 11:26:16 
+):
> https://www.debian.org/download links to https://www.debian.org/distrib/
> 
> This page is missing links to larger images like DVD and the only links
> are the links to torrents.
> 
> Debian Live links are also only torrents

https://www.debian.org/distrib/ is like this for ages, nothing has changed.
I guess this is to save bandwidth on cdimage mirrors? (it's only DVD and BT
images, which are BT-only; there are direct download links for netinst images)

> https://www.debian.org/CD/ still has suggestions for 11.7

This is fixed in the meantime; I guess you watched a cached version of the
page or the page rebuild wasn't ready at that time (I encountered similar this
morning).

> https://www.debian.org/CD/http-ftp/ then needs rewrite

That's correct, there are some things to update:
- netinst images are now much larger due to included firmware, 
  150-300 MB is no longer correct.
- multi-arch netinst images are no longer being built



Holger


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



Bug#1037316: www.debian.org: Download links on www.debian.org after release = no iso images, only BT

2023-06-11 Thread Holger Wansing
Hi,

Am 11. Juni 2023 11:29:54 MESZ schrieb "Andrew M.A. Cater" 
:
>Package: www.debian.org
>Severity: important
>
>Dear Maintainer,
>
>*** Reporter, please consider answering these questions, where appropriate ***
>
>   * What led up to the situation?
>
>Following Bookworm release and new layout: download links missing on 
>www.debian.org for live CDs and some other images. Only BT links are there.
>
>   * What exactly did you do (or not do) that was effective (or
> ineffective)?
>
>Followed download link on front page
>
>   * What was the outcome of this action?
>
>Redirect to appropriate page but links missing.
>
>   * What outcome did you expect instead?
>
>Download links to full CD/DVD/debian-live DVD images
>

Please report the exact link of the page where you encounter this!

Holger



-- 
Sent from /e/ OS on Fairphone3



Bug#932957: Please migrate Release Notes to reStructuredText

2023-06-04 Thread Holger Wansing
Hi Stuart,

Stuart Prescott  wrote (Sat, 3 Jun 2023 14:45:46 +1000):
> > - The list of archs is hardcoded in the Makefile for now.
> 
> The following might provide you with some useful way of not hard-coding 
> such information:
> 
>   curl -s 'https://api.ftp-master.debian.org/suite/bookworm'
> 
> (pipe that into « jq -r '.architectures[]' » to get just the archs as 
> plain text)

I managed to get a list of all relevant architectures via
curl -s 'https://api.ftp-master.debian.org/suite/testing' | jq -r 
'.architectures[]' | grep -v all | grep -v source

> You might want to make that a 'maintainer-run' step rather than is run 
> occasionally as part of preparing a release, rather than as a build time 
> step. That is, the maintainer runs that from a machine with internet 
> access to find the list of archs that should be used; this is then 
> cached in the repo until it is next refreshed. There is precedent for 
> this 'maintainer-run' step in various "make dist' mechanisms (from the 
> autotools world) and how the dh-python packages prepares a cache of 
> known python modules in the archive for later module→package translation.

I created a prepare-release.sh script, which can be used to prepare the
release-notes for the next stable.
That script creates an archlist file, which holds the relevant archs for
the current testing.

Thanks for helping me with that!


> There has been talk for a while about how we might avoid baking in 
> internal metadata in packages and there might be more inspiration on how 
> to do this in other parts of the project:
> 
>   https://wiki.debian.org/SuitesAndReposExtension
> 
> (there are already a couple of entries there for the release notes)

Shouldn't the above solution be added to that wiki page?
(I don't see it there, right?)


Holger




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



Bug#932957: Please migrate Release Notes to reStructuredText

2023-06-02 Thread Holger Wansing
Some status update:

I managed to expand the Makefile, to build r-n for different archs for all 
languages and for formats text+pdf+nopdf+html:

https://salsa.debian.org/holgerw/release-notes/-/commits/master?ref_type=heads


Open points: 

- In this version, it builds for amd64+armel+i386+ppc64el only. No problem,
  to expand this for more archs though.
- For now, I have separate conf.py files for the different archs, which I copy 
  in place before starting the builds; needs to be replaced by some sed 
mechanism.
- The list of archs is hardcoded in the Makefile for now.
- The target 'make install' is not ready; you can only build with 
  'make text|make pdf|make nopdf|make html|make all' and get the results in 
  the build dir.


Holger

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



Bug#932957: Please migrate Release Notes to reStructuredText

2023-05-29 Thread Holger Wansing
Hi,

James Addison  wrote (Mon, 29 May 2023 00:18:36 +0100):
> [[Holger Wansing wrote:]]
> > Yes, filtering the content for the different architectures does not work 
> > yet.
> 
> Ah, and I said I would help with that :)
> 
> Although I don't yet know exactly how it's going to interact with the build
> process, I _think_ that a feature we could use for this is the 'only'
> directive:
> 
>   
> https://www.sphinx-doc.org/en/master/usage/restructuredtext/directives.html#directive-only
> 
> Although this could benefit from more thought, initially I suggest we adopt a
> tag format something like 'arch-{debarch}' to handle this (so the conditional
> clause here would be placed within a '.. only:: arch-i386' block.
> 
> >From there, we could pass the corresponding tag on the commandline using the
> '-t' option, I guess in the Makefile:
> 
>   
> https://salsa.debian.org/holgerw/release-notes/-/blob/a2ba839790573915a80db75405abf8ef9212ac8e/Makefile#L103

I have implemented such things now in
https://salsa.debian.org/holgerw/release-notes/-/commit/0304c87400432e1905d1bb04d39468a632876978
as a first step for arch-depending filtering.

Works so far, if the wanted arch is set in the Makefile (line 175) via the -t 
option.

Thanks for your help on this!

Now we just need an infrastructure, to loop over all architectures for build 
targets...


Holger



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



Bug#932957: Please migrate Release Notes to reStructuredText

2023-05-28 Thread Holger Wansing
Hi,

James Addison  wrote (Fri, 26 May 2023 13:02:53 +0100):
> I noticed one more problem with the output of the ReST release-notes:
> 
> Filtering of architecture-specific sections does not seem to be taking place,
> so the 'Supported Architectures'[1] section for AMD64 currently contains the
> text:
> 
>   The ARCH-TITLE support (known as the Debian architecture amd64) now 
> requires the “long NOP” instruction. Please refer to Baseline for 64-bit PC 
> is now i686 for more information.
> 
> (the ARCH-TITLE placeholder is probably a small fixup - the problem I'd like
> to draw attention to is the reference to 64-bit PC / amd64 as i686)
> 
> In the Docbook source, there is an 'arch="i386"' annotation[2] on the 
> section's
> XML element, so perhaps that is used to filter the content.

Yes, filtering the content for the different architectures does not work yet.
That's one open point, where I have requested help for.

I have fixed the forgotten ARCH-TITLE placeholder now.


Holger


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



Bug#932957: Please migrate Release Notes to reStructuredText

2023-05-28 Thread Holger Wansing
Hi,

Stéphane Blondon  wrote (Sun, 28 May 2023 13:16:24 
+0200):
> > > Richard Lewis  wrote (Fri, 19 May
> > 2023 00:58:26 +0100):
> >
> > > - are the red hyphens in eg the 'deb...' line near the top of
> > > >
> > https://people.debian.org/~holgerw/release-notes_sphinx/en/html/issues.html
> > > > meant to be red? (maybe it is a syntax error?)
> > >
> 
> 
> 
> Sphinx uses Pygments to highlight source code. I guess no language is
> defined so Sphinx uses a wrong lexer. We should force Sphinx to use
> 'SourceListLexer' with:
> .. code-block :: sources.list

The highlighting feature is great, thanks for pointing this out!
However, we cannot use it here in most cases for sources.list entries,
since resolving substitutions does not work within such lines :-(
like in
   deb https://deb.debian.org/debian |RELEASENAME| main contrib


But in many cases the highlighting gives us a great benefit, so I will
merge your MR and adapt the rare cases, where it does not work.

Thanks again!

Holger



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



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

2023-05-24 Thread Holger Wansing
[ Sending this to #932957 as well, as it contains valueable info on that topic ]


Jeremy Stanley  wrote (Wed, 24 May 2023 18:22:09 +):
> On 2023-05-24 19:40:56 +0200 (+0200), Agathe Porte wrote:
> [...]
> > Maybe the idea was to introduce %OLD_RELEASE_NAME% and to call sed to
> > replace this kind of strings in a build step, and not rely on sphinx
> > substitution at all.
> > 
> > I know that I have done this a few times and it works fine as a very
> > simple preprocessor.
> 
> Similar things can be done at sphinx-build time with a custom Sphinx
> extension (can be a trivial Python module). We do that for the
> published security advisories list upstream in OpenStack:
> 
> https://opendev.org/openstack/ossa/src/commit/136b24c/doc/source/conf.py#L31
> 
> https://opendev.org/openstack/ossa/src/commit/136b24c/doc/source/_exts/vmt.py
> 
> That's a more complex example because we generate a ton of content
> out of structured data (YAML) files by splatting the relevant fields
> into substitutions in a Jinja2 template, but for basic string
> substitution you could get away with something far simpler, or even
> use a canned one like (this was simply my first web search result):
> 
> https://pypi.org/project/Sphinx-Substitution-Extensions/
> 
> The examples in its readme look to be along the lines of the Debian
> Release Notes use case anyway. There's also basic substitutions
> support in the reStructuredText specification, which might be useful
> to reduce the amount of actual content you need to swap at build
> time:
> 
> https://docutils.sourceforge.io/docs/ref/rst/restructuredtext.html#substitution-definitions

The above seem related to the issue in question, but the solution pointed
out by James Addison in
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=932957#90
(use parsed-literal ('.. parsed-literal::') blocks)
seems to be the easier one (at least for this document) and it works fine
here. So I would go for it.

Thanks anyway

Holger



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



Bug#932957: Please migrate Release Notes to reStructuredText

2023-05-24 Thread Holger Wansing
Hi,

James Addison  wrote (Tue, 23 May 2023 00:22:16 +0100):
> Followup-For: Bug #932957
> X-Debbugs-Cc: hwans...@mailbox.org
> 
> On Mon, 22 May 2023 23:40:46 +0100, James wrote:
> > On Sun, 21 May 2023 10:16:36 +0200, Holger wrote:
> > > There is also a problem using entities (or now called substitutions) in 
> > > quoted lines like
> >
> > >   deb https://deb.debian.org/debian RELEASENAME main contrib
> >
> > Ok, yep - I understand the problem there now, and have experimented with it 
> > a
> > bit locally.  Roughly speaking: substitutions aren't possible within literal
> > quote blocks (there is a '::' a couple of lines before the mentioned line, 
> > and
> > adding the pipe '|' symbols around the substitution label doesn't make a
> > difference within literal blocks)
> 
> It looks like the fix for that is to convert those literal ('::') blocks into
> parsed-literal[1] ('.. parsed-literal::') blocks.
> 
> [1] - 
> https://docutils.sourceforge.io/docs/ref/rst/directives.html#parsed-literal

Yes, that works! Thanks for this!

I have therefore changed all literal ('::') blocks into parsed-literal
('.. parsed-literal::') blocks.
In output, there seems to be no difference (at least in this document), and
this way it's easier for future editors (no need to distinguish between
two different versions of quoted blocks).


Holger



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



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

2023-05-23 Thread Holger Wansing
Hi Paul,

Am 23. Mai 2023 08:20:18 MESZ schrieb Paul Gevers :
>Hi Holger,
>
>On 18-05-2023 22:39, Holger Wansing wrote:
>> I worked on this recently, and I have something like a prototype ready.
>
>Thanks a lot for working on this. I'm a bit swamped with last minute things 
>that need to happen before the release of bookworm, so I don't expect to have 
>time to look at this until after the release.

As I wrote, I see this as a prototype, and thus I don't expected it to be a 
thing to 
happen before releasing bookworm.


Holger



-- 
Sent from /e/ OS on Fairphone3



Bug#932957: Please migrate Release Notes to reStructuredText

2023-05-21 Thread Holger Wansing
[[ Replying to two mails in one ]]


Hi,

Holger Wansing  wrote (Sat, 20 May 2023 23:26:47 +0200):
> James Addison  wrote (Fri, 19 May 2023 23:28:55 +0100):
> > > Please note the  in the URL!
> > > I could not get this working with sphinx (if someone knows better, please
> > > contact me!)
> > 
> > Could the 'extlinks' feature[1] of Sphinx be helpful to migrate those?
> 
> Yes, thanks for the pointer! I used that now to get the manpage links fixed!
> 
> > (it allows defining URL pattern aliases, so for example :oldreleasenotes: 
> > could
> > map to https://www.debian.org/releases/bullseye/releasenotes and 
> > :releasenotes:
> > could map to https://www.debian.org/releases/bookworm/releasenotes for D12)
> > 
> > Parameters are supported too, and that could be useful for 
> > package-or-filepath
> > refs (re: grep -r '`.*<' source |grep -o '' | sort | uniq -c |sort 
> > -n)
> 
> The drawback is, it is not as flexible as the entities in docbook.
> For example, there is the following URL in this manual in docbook:
> 
> /debian/dists//main/binary-/...
> 
> You see, there are three entites in this URL!
> This seems to be not supported by extlinks :-((

I focused a bit too much on the URL front here.
There is also a problem using entities (or now called substitutions) in 
quoted lines like

deb https://deb.debian.org/debian RELEASENAME main contrib

or

# script -t 2>~/upgrade-RELEASENAMEstep.time -a 
~/upgrade-RELEASENAMEstep.script

These also do not work.
That's the biggest blocker in the upgrading chapter IMHO.


> > > Beside this, I need help to adapt the buildchain, to get the possibility 
> > > of
> > > building the release-notes for the different architectures.
> > > I have no python knowledge, so I will most likely not get this running 
> > > myself.
> > 
> > I'll try to take a look into that soon to see what I can find out.  Do you
> > know how the current docbook-based build varies by architecture?
> 
> There are some chapters, which are only visible for specific architectures, 
> like
> in installing.dbk:
> 
>   
> Cloud installations
> 
>   The cloud team publishes
>   Debian  for several popular cloud computing services
>   including:
> 
> 
> > Perhaps we can borrow some build scripting from developers-reference and/or
> > debian-policy.. but I suppose those don't have per-architecture output.
> 
> I think so, yes. That will be of no help, I fear...
> 
> > > And the last point is the integration into the debhelper tools: I don't 
> > > know
> > > if it is required, to have the release-notes fit for building as a whole
> > > package with sbuild or debuild or similar. Salsa tries to build it via CI
> > > at every push, but currently fails.
> > 
> > It's possible I've misunderstood, but would be the goals here to be to get
> > the release-notes documentation built by CI, and also for it to be 
> > distributed
> > as a Debian package itself?
> > 
> > (someone who knows more may correct me, but I think it would be great to 
> > have
> > the package available for install using apt in addition to the website)
> 
> That was my first thought as well, yes.





Hi,

Holger Wansing  wrote (Sat, 20 May 2023 23:10:59 +0200):
> Hi,
> 
> Richard Lewis  wrote (Fri, 19 May 2023 
> 00:58:26 +0100):
> > On Thu, 18 May 2023 22:39:11 +0200 Holger Wansing  
> > wrote:
> > Unfortunately, my first impression is that it the output has quite a
> > few issues which make it a lot harder to read than
> > the docbook version - which im sure is because it's still only a
> > prototype, but thought it might helpful to list the things that jumped
> > out at me:
> > - It is a lot more cluttered than the docbook version - it feels
> > off-putting and dense to read
> > - it's all a bit 'blue' - i'd suggest red is more on-brand for debian
> > - the "next"/"prev" links at the bottom-right are white on green  ---
> > I totally missed at first, and found hard to read
> 
> I copied style and font settings from developers-reference, another
> document, which has been migrated recently from docbook to sphinx.
> So I consider this as a quasi-standard at the moment.
> I copied it by intent, to get a consistent look for all manuals generated
> with sphinx.
> We can work on that later on, as Laura already pointed out there is even
> a bugreport for this.
> So will ignore this for now here.
> 
> > - i was a bit confused by the "12.1" version number at the bottom of
> > e

Bug#932957: Please migrate Release Notes to reStructuredText

2023-05-20 Thread Holger Wansing
Hi,

James Addison  wrote (Fri, 19 May 2023 23:28:55 +0100):
> > Please note the  in the URL!
> > I could not get this working with sphinx (if someone knows better, please
> > contact me!)
> 
> Could the 'extlinks' feature[1] of Sphinx be helpful to migrate those?

Yes, thanks for the pointer! I used that now to get the manpage links fixed!

> (it allows defining URL pattern aliases, so for example :oldreleasenotes: 
> could
> map to https://www.debian.org/releases/bullseye/releasenotes and 
> :releasenotes:
> could map to https://www.debian.org/releases/bookworm/releasenotes for D12)
> 
> Parameters are supported too, and that could be useful for package-or-filepath
> refs (re: grep -r '`.*<' source |grep -o '' | sort | uniq -c |sort 
> -n)

The drawback is, it is not as flexible as the entities in docbook.
For example, there is the following URL in this manual in docbook:

/debian/dists//main/binary-/...

You see, there are three entites in this URL!
This seems to be not supported by extlinks :-((


> > Beside this, I need help to adapt the buildchain, to get the possibility of
> > building the release-notes for the different architectures.
> > I have no python knowledge, so I will most likely not get this running 
> > myself.
> 
> I'll try to take a look into that soon to see what I can find out.  Do you
> know how the current docbook-based build varies by architecture?

There are some chapters, which are only visible for specific architectures, like
in installing.dbk:


  Cloud installations
  
The cloud team publishes
Debian  for several popular cloud computing services
including:


> Perhaps we can borrow some build scripting from developers-reference and/or
> debian-policy.. but I suppose those don't have per-architecture output.

I think so, yes. That will be of no help, I fear...

> > And the last point is the integration into the debhelper tools: I don't know
> > if it is required, to have the release-notes fit for building as a whole
> > package with sbuild or debuild or similar. Salsa tries to build it via CI
> > at every push, but currently fails.
> 
> It's possible I've misunderstood, but would be the goals here to be to get
> the release-notes documentation built by CI, and also for it to be distributed
> as a Debian package itself?
> 
> (someone who knows more may correct me, but I think it would be great to have
> the package available for install using apt in addition to the website)

That was my first thought as well, yes.


Holger



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



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

2023-05-20 Thread Holger Wansing
Hi,

Richard Lewis  wrote (Fri, 19 May 2023 
00:58:26 +0100):
> On Thu, 18 May 2023 22:39:11 +0200 Holger Wansing  
> wrote:
> Unfortunately, my first impression is that it the output has quite a
> few issues which make it a lot harder to read than
> the docbook version - which im sure is because it's still only a
> prototype, but thought it might helpful to list the things that jumped
> out at me:
> - It is a lot more cluttered than the docbook version - it feels
> off-putting and dense to read
> - it's all a bit 'blue' - i'd suggest red is more on-brand for debian
> - the "next"/"prev" links at the bottom-right are white on green  ---
> I totally missed at first, and found hard to read

I copied style and font settings from developers-reference, another
document, which has been migrated recently from docbook to sphinx.
So I consider this as a quasi-standard at the moment.
I copied it by intent, to get a consistent look for all manuals generated
with sphinx.
We can work on that later on, as Laura already pointed out there is even
a bugreport for this.
So will ignore this for now here.

> - i was a bit confused by the "12.1" version number at the bottom of
> every page, and having 'sphinx' reminded me of websites with "hosted
> by geocities"

The first version I built with sphinx had version displayed
"release-notes 5.0.1" which confused me even more.
Therefore I changed that in the sense of "release-notes version 12 for
Debian release 12". Can still be changed in any way...

> - are the red hyphens in eg the 'deb...' line near the top of
> https://people.debian.org/~holgerw/release-notes_sphinx/en/html/issues.html
> meant to be red? (maybe it is a syntax error?)

I see this in other sphinx-generated manuals as well. So maybe a bug in sphinx?
Or a feature?

> - package names are no longer distinguished from other text (eg 'ntp'
> in 
> https://people.debian.org/~holgerw/release-notes_sphinx/en/html/issues.html#changes-to-packages-that-set-the-system-clock)

good catch, that should be changed - that's an easy one :-)

> - the order in the contents pane on the left is a bit...unusual: it
> starts with the current section, then does previous, then next, so eg
> on chapter 2,
>  
> https://people.debian.org/~holgerw/release-notes_sphinx/en/html/whats-new.html
> it lists chapters 2, then 1, then 3.

Seems to be the default in Sphinx? Currently I cannot see how I could change 
that.

> - 
> https://people.debian.org/~holgerw/release-notes_sphinx/en/html/genindex.html
> is completely blank

Yes, I already noticed that too.
And it's the same for the debian-policy and the developers-reference...
Needs to be investigated.

> - not sure "show source" on the left is all that useful for readers

That's a feature of sphinx, I guess.
And if a reader finds an error, or wants to make a proposal for a change, he
can easily access the source code and provide a patch against this.
So that's a good feature!

> I'm sure these are easy to fix!
> 
> > while the git repo containing the migration is at
> > https://salsa.debian.org/holgerw/release-notes
> 
> Im sure i am being dumb, but i couldnt spot where the actual rst files
> are? - i still see eg
> https://salsa.debian.org/holgerw/release-notes/-/blob/master/en/issues.dbk
> in XML

I have removed several old files from the repo now, amongst others the dbk
files in en.
The new rst files for English are in ./source/ (default for sphinx AFAICT).

> > as far as I know, sphinx/reStructuredText is still lacking some 
> > functionality,
> > which is heavily used in the release-notes.
> > That is the use of substitutions within URLs.
> 
> You could always keep the entities and do a 'sed
> s//bookworm/g' etc before "building" with sphinx.

That will not work. 
You cannot replace all 'bullseye' by 'bookworm'. There are places, where the
'bullseye' needs to stay. So that needs to be done selective one-by-one.

> Actually if i click 'show source'  l get to
> https://people.debian.org/~holgerw/release-notes_sphinx/en/html/_sources/about.rst.txt
> which seems to have |RELEASE| and |RELEASENAME| rather than 12 and
> bookworm: perhaps sphinx supports entities after all?

Sure, in sphinx that's called "substitution" and I use it already very much in
this manual.
The point is, that they do not work in all situations, where they did in docbook
(at least this is my current state of knowledge).


Holger



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



Bug#1023472: Workaround implemented for live images

2023-05-20 Thread Holger Wansing
Hi kibi,

Cyril Brulebois  wrote (Fri, 19 May 2023 10:50:57 +0200):
> Hi,
> 
> Roland Clobus  (2023-05-19):
> > I consider it a workaround, because the netinst D-I is still affected.
> > If the LXQt desktop is selected in the installer, the Wayland desktop
> > manager is used instead of xfwm4.
> > The MR for a proposed fix (in tasksel) is at [1].
> 
> OK, I'll leave that one to people more used to tasksel than me.

Do you think, that just changing the order in the Recommends packages list
like in


  Depends: ${misc:Depends},
   task-desktop,
+ # Mention the preferred theme before sddm, otherwise another theme will be 
used
+  sddm-theme-debian-elarun | sddm-theme,
   sddm,
-  sddm-theme-debian-elarun | sddm-theme-debian-elarun,
   lxqt,
  Recommends: xsane,


changes the result?
My guess would be that the order is of no relevance.


Holger



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



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

2023-05-18 Thread Holger Wansing
[[ debian-devel in CC, to get a wider audience regarding reStructuredText ]]


Hi,

I worked on this recently, and I have something like a prototype ready.
It can be found (as html) at
https://people.debian.org/~holgerw/release-notes_sphinx/
while the git repo containing the migration is at
https://salsa.debian.org/holgerw/release-notes


However, I may have some objections against the migration at all:
as far as I know, sphinx/reStructuredText is still lacking some functionality,
which is heavily used in the release-notes.
That is the use of substitutions within URLs.
In docbook speach these were entities, and you could use them in URLs like this:

Please follow the instructions in the https://www.debian.org/releases//releasenotes;>Release
Notes for   to upgrade to 
 first if needed.

Please note the  in the URL!
I could not get this working with sphinx (if someone knows better, please
contact me!)
In sphinx, I used hardcoded codenames like
https://www.debian.org/releases/bullseye/releasenotes instead, which means,
that there is much work to do to make the release-notes fit for the next 
release,
while with docbook you only need to change the entity in one place !!!
In sphinx you need to change every single occurence, and don't forget the 
translations !!!



Beside this, I need help to adapt the buildchain, to get the possibility of
building the release-notes for the different architectures.
I have no python knowledge, so I will most likely not get this running myself.

And the last point is the integration into the debhelper tools: I don't know
if it is required, to have the release-notes fit for building as a whole
package with sbuild or debuild or similar. Salsa tries to build it via CI
at every push, but currently fails.
However, there is no package "release-notes" in the archive, so currently
it is only a matter of building it on wolkenstein for www.debian.org, right?


Regards
Holger



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



Bug#1034750: tasksel default value for preseeding

2023-05-07 Thread Holger Wansing
Hi,

"Adam Baxter"  wrote:
> A full desktop environment was installed without prompting but I think this 
> is a side effect 
> of using priority=critical as a boot parameter. 

Yes, that's correct.
Using priority=critical leads to questions not being asked, if they have a 
reasonable default value; and the default value for the "tasksel tasksel/first"
question is "Installing gnome desktop environment".
So you get Gnome, if you bypass that question :-)


"Adam Baxter"  wrote:
> 
> #The original didn't have this, but this stops the desktop environment being 
> installed.
> d-i pkgsel/run_tasksel boolean false

Setting 
tasksel tasksel/first multiselect standard
in your preseed file would also work (installing all "standard" packages,
and that's it; would lead to what's often called a "minimal Debian system").


Holger


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



Bug#1033730: [release-notes] adduser changes in bookworm

2023-04-28 Thread Holger Wansing
Hi,

Am 28. April 2023 17:42:31 MESZ schrieb Paul Gevers :
>Hi Holger,
>
>Again, thanks for working on the notes.
>
>On 27-04-2023 23:00, Holger Wansing wrote:
>> Developers also can find out there, which changes are planned for Debian's 
>> next
>> release after bookworm (trixie), enabling them to do necessary changes to 
>> their
>> packages and code during the bookworm cycle to get ready for trixie.
>
>I think you are addressing Debian Developers here? I don't consider the 
>Release Notes as the right platform for that.

In that case we can just skip this last part and go with 
the rest...

Holger


-- 
Sent from /e/ OS on Fairphone3



Bug#1033730: [release-notes] adduser changes in bookworm

2023-04-27 Thread Holger Wansing
I think, we don't want to have all of the text from the bugreport in the
release-notes, it's much to specific stuff for the majority of people IMO.

Maybe we just want some more generic text like:



Extensive changes in adduser for bookworm

There have been several changings in adduser during the development cycle of
bookworm. Users might be affected by this, and also developers of other 
packages, if they use adduser in their maintainer scripts.

Remember to check /usr/share/doc/adduser/NEWS.Debian
and /usr/shade/doc/adduser/README.Debian as well as the manual pages that come
with the package for detailed information.

Developers also can find out there, which changes are planned for Debian's next
release after bookworm (trixie), enabling them to do necessary changes to their
packages and code during the bookworm cycle to get ready for trixie.


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



Bug#1034412: release-notes: Information about manpages-l10n for bookworm release notes

2023-04-27 Thread Holger Wansing
Hi,

Paul Gevers  wrote (Thu, 27 Apr 2023 22:17:40 +0200):
> Hi,
> 
> On 27-04-2023 22:07, Holger Wansing wrote:
> > Control: tags -1 + patch
> > 
> > I would like to propose the attached patch for this report (mostly grabbed
> > from Helge's text).
> 
> +  Greatly expanded translations of man pages
> +  
> +Thank to many efforts of our translators, the translation of many
> 
> That feels like one many too many for one sentence.
> 
> +manpages has been greatly expanded (e.g. we have complete 
> translation
> +of systemd user pages into German now) and various new 
> languages have
> +been added (Czech, Danish, Greek, Finnish, Indonesian, Macedonian,
> +Norwegian, Russian, Serbian, Swedish, Ukranian and Vietnamesian).
> 
> I happen to know that "Norwegian" is ambiguous? There's Bokmål and 
> Nynorsk. I assume the former is meant, maybe "Norwegian (Bokmål)"?

Looking at the repo
https://salsa.debian.orgNorwegian 
(Bokmål/manpages-l10n-team/manpages-l10n/-/tree/master/po
there is a folder for Norwegian Bokmål (nb), but none for Norwegian Nynorsk 
(nn),
so it looks you are right.

> 
> My spelling checker also suggests Ukrainian and Vietnamese.

Good catch. Correct.

> Paul


Holger

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



  1   2   3   4   5   6   7   8   9   10   >