Build of french PDF broken (Re: Update of the package debian-history?)
Hi, Joost van Baal-Ilić wrote (Wed, 24 Jul 2024 16:29:54 +0200): > Hi Holger e.a., > > On Wed, Jul 24, 2024 at 03:07:34PM +0200, Holger Wansing wrote: > > Am 22. Juli 2024 17:20:46 MESZ schrieb "Joost van Baal-Ilić" > > : > > > > > >For some reason, under current sid, with current package as in git, > > >project-history.fr.pdf fails to build (all other translated .pdf's build > > >fine). > > >I'll keep working on fixing this; however, any help here would be very much > > >appreciated. > > > > Just in case you did not notice: > > > > That's not specific to debian-history, it's the toolchain (dblatex, ...), > > which is > > broken. > > > > Several manuals have just received FTBFS bugs, often with French PDFs > > failing > > to build. > > Yes I know, thanks anyway. A bug has been filed for this yesterday: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1076675 -- Holger Wansing PGP-Fingerprint: 496A C6E8 1442 4B34 8508 3529 59F1 87CA 156E B076
Re: Update of the package debian-history?
Hi all, Am 22. Juli 2024 17:20:46 MESZ schrieb "Joost van Baal-Ilić" : > >For some reason, under current sid, with current package as in git, >project-history.fr.pdf fails to build (all other translated .pdf's build fine). >I'll keep working on fixing this; however, any help here would be very much >appreciated. Just in case you did not notice: That's not specific to debian-history, it's the toolchain (dblatex, ...), which is broken. Several manuals have just received FTBFS bugs, often with French PDFs failing to build. Holger -- Sent from /e/ OS on Fairphone3
Re: Update of the package debian-history?
Hi, On Mon, Jul 15, 2024 at 02:33:50PM +0200, Laura Arjona Reina wrote: > El 14/7/24 a las 18:22, Carsten Schoenert escribió: > > > > https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1074052 > > The package debian-history is handled by the publicity team. > But it needs to be uploaded to unstable so the website scripts get it from > there, unpack it and build the corresponding website pages. I am working on https://salsa.debian.org/publicity-team/debian-history , in order to get the upcoming Debian 13 "trixie" release shipping a decently up to date version of that package. The work should be finished before the end of this year, I guess. (No dates have been picked yet for https://release.debian.org/testing/freeze_policy.html#transition .) Current uploaders Bdale Garbee, Osamu Aoki and/or Javier Fernández-Sanguino Peña: I took the liberty to add myself to Uploaders. Is that OK with you? Also, our translations are out of date: Since 2019, there has not been any update of es fr ja lt ru . Since 2022, there has not been any update of it ko . Luckily, pretty much up to date are: de pt . See also https://i18n.debian.org/l10n-pkg-status/d/debian-history.html for some details. I plan to contact the last translators and/or some relevant list & ask for updates there. Or could I better not do that and do we have some automated infrastructure in place for such notifications? Third, and last: For some reason, under current sid, with current package as in git, project-history.fr.pdf fails to build (all other translated .pdf's build fine). I'll keep working on fixing this; however, any help here would be very much appreciated. Thanks for your time! Bye, Joost signature.asc Description: PGP signature
Bug#932957: 'Official' Debian-style html theme for Sphinx-based docs
Holger Wansing wrote: > Hi, you may have noticed that we have an 'official' Debian-style html > theme for Sphinx-based manuals on the Debian website now. It can > be seen at debian-policy under https://www.debian.org/doc/debian-policy/ > It was created by Stéphane Blondon, based on a theme from readthedocs.org. > Any objections against porting this theme to the release-notes as well? I have created a merge request for this: <https://salsa.debian.org/ddp-team/release-notes/-/merge_requests/207> I will merge it shortly, if noone objects. Holger -- Sent from /e/ OS on Fairphone3
Bug#932957: 'Official' Debian-style html theme for Sphinx-based docs
Ok, that's reasonable. Re: content-negotation: the www FAQ[1] makes me think that, at least currently, it's not worth attempting anything more advanced than language negotiation. Re: file suffixes: after re-reading the Sphinx code and experimenting with a few builds: I'm convinced that the html_file_suffix setting does _not_ help. I couldn't think of a better near-term alternative than using the cron script to adjust the searchindex.js src attribute, similar to the HTML hrefs. I don't really like that, though. And finally, re: other Sphinx-built documentation, I noticed some JavaScript errors for the language chooser in the online HTML developers-reference[2], so I've opened a merge request[3] related to that. It's not directly related here, but I'm mentioning it because the documentation projects share some similarities. [1] - https://www.debian.org/devel/website/desc.en.html#faq [2] - https://www.debian.org/doc/manuals/developers-reference/ [3] - https://salsa.debian.org/debian/developers-reference/-/merge_requests/48
Bug#932957: 'Official' Debian-style html theme for Sphinx-based docs
I tend to ignore the language-related issues with the search for now. Currently we have no document-wide search functionality at all on the Sphinx- based documents on our website. So it's clearly an improvement, if it works for English at least. Holger
Bug#932957: 'Official' Debian-style html theme for Sphinx-based docs
On Wed, 17 Apr 2024 at 21:46, Holger Wansing wrote:
> James Addison wrote (Sun, 14 Apr 2024 23:52:03 +0100):
> > The _other_ hyperlinks in the static content are replaced as part of the
> > cronjob[1] - but that doesn't work for items in the searchindex.js file.
> >
> > Fortunately I think there might be a better way to do this. Sphinx itself
> > has
> > an HTML builder option 'html_file_suffix' and I think we could use that
> > instead
> > to define the filenames. That option is respected by the search JavaScript
> > using a template variable[3] in the documentation_options.js file.
>
> I fear I have no idea what to do with these options:
>
> add 'html_file_suffix' in the conf.py: the default value is html here, what
> should I insert here?
A possibility would be to configure it during make, by using something like:
-D html_file_suffix=$*
> in documentation_options.js I have FILE_SUFFIX: '{{ file_suffix }}'; what
> to do with this?
With an html_file_suffix config option, that becomes: FILE_SUFFIX: 'es-ES' (for
example).
> An idea came to mind:
> if we could change the search results, so that they no longer have a file
> extension (say: the link points to 'installing' instead of 'installing.html')
> everything would work fine I guess, since the browser delivers the correct
> language page due to content negotiation according to browser lang settings.
>
>
> I don't know if you thought about such thing, when writing about above html
> build / file suffix options???
> (as already said: I have no clue how the above could change something)
I hadn't considered that approach, but it could make sense since there are
other file formats that we build (text, PDF) and those could also be negotiated
by an HTTP user-agent.
> > We should be careful of other side-effects if making that change, but it
> > would remove a deployment transformation step on the static content, and I
> > think that's beneficial.
> >
> > [1] -
> > https://salsa.debian.org/webmaster-team/cron/-/blob/3462a061d0a67dce3761b0f4d9357c017ad0a50b/parts/7release-notes#L64-70
> >
> > [2] -
> > https://www.sphinx-doc.org/en/master/usage/configuration.html#confval-html_file_suffix
> >
> > [3] -
> > https://github.com/sphinx-doc/sphinx/blob/cf7d2759af0852d67288e58d823d51fe860749ca/sphinx/themes/basic/static/documentation_options.js_t#L6
> >
>
>
> --
> Holger Wansing
> PGP-Fingerprint: 496A C6E8 1442 4B34 8508 3529 59F1 87CA 156E B076
Bug#932957: 'Official' Debian-style html theme for Sphinx-based docs
On Wed, 17 Apr 2024 at 19:36, Holger Wansing wrote: > Am 16. April 2024 23:47:05 MESZ schrieb James Addison : > >> I have tried to deal with this by some adaptions in the cronjob - see the > >> first two additions in my patch: change all links to search.html into > >> search.§lang.html, and rename the language-specific searchindex files into > >> searchindex.$lang.js. > >> However, that does not seem to be enough. > > > >When you say it is not enough: could I check what you mean by that? > > I could guess that changings on the Search box are needed, to use > the language-wise correct searchindex. > > But that's too much corrections on the Sphinx-generated result > if you ask me... Some .js files remain static when the source is rebuilt in different languages; however searchindex.js is not one of those files. So it seems that the content to retrieve for it should be negotiated between the client and server too, like the html-suffix files. > And out of my skills, sorry. Identifying and describing the problem is part of the fix; I'll think about it some more but I reckon there's already some relevant information from this discussion to take upstream to Sphinx issue thread(s).
Bug#932957: 'Official' Debian-style html theme for Sphinx-based docs
Hi,
James Addison wrote (Sun, 14 Apr 2024 23:52:03 +0100):
> The _other_ hyperlinks in the static content are replaced as part of the
> cronjob[1] - but that doesn't work for items in the searchindex.js file.
>
> Fortunately I think there might be a better way to do this. Sphinx itself has
> an HTML builder option 'html_file_suffix' and I think we could use that
> instead
> to define the filenames. That option is respected by the search JavaScript
> using a template variable[3] in the documentation_options.js file.
I fear I have no idea what to do with these options:
add 'html_file_suffix' in the conf.py: the default value is html here, what
should I insert here?
in documentation_options.js I have FILE_SUFFIX: '{{ file_suffix }}'; what
to do with this?
An idea came to mind:
if we could change the search results, so that they no longer have a file
extension (say: the link points to 'installing' instead of 'installing.html')
everything would work fine I guess, since the browser delivers the correct
language page due to content negotiation according to browser lang settings.
I don't know if you thought about such thing, when writing about above html
build / file suffix options???
(as already said: I have no clue how the above could change something)
Holger
> We should be careful of other side-effects if making that change, but it
> would remove a deployment transformation step on the static content, and I
> think that's beneficial.
>
> [1] -
> https://salsa.debian.org/webmaster-team/cron/-/blob/3462a061d0a67dce3761b0f4d9357c017ad0a50b/parts/7release-notes#L64-70
>
> [2] -
> https://www.sphinx-doc.org/en/master/usage/configuration.html#confval-html_file_suffix
>
> [3] -
> https://github.com/sphinx-doc/sphinx/blob/cf7d2759af0852d67288e58d823d51fe860749ca/sphinx/themes/basic/static/documentation_options.js_t#L6
>
--
Holger Wansing
PGP-Fingerprint: 496A C6E8 1442 4B34 8508 3529 59F1 87CA 156E B076
Bug#932957: 'Official' Debian-style html theme for Sphinx-based docs
Hi, Am 16. April 2024 23:47:05 MESZ schrieb James Addison : >> I have tried to deal with this by some adaptions in the cronjob - see the >> first two additions in my patch: change all links to search.html into >> search.§lang.html, and rename the language-specific searchindex files into >> searchindex.$lang.js. >> However, that does not seem to be enough. > >When you say it is not enough: could I check what you mean by that? I could guess that changings on the Search box are needed, to use the language-wise correct searchindex. But that's too much corrections on the Sphinx-generated result if you ask me... And out of my skills, sorry. Holger -- Sent from /e/ OS on Fairphone3
Bug#932957: 'Official' Debian-style html theme for Sphinx-based docs
On Tue, 16 Apr 2024 at 22:47, James Addison wrote:> > Thanks Holger, > > On Mon, 15 Apr 2024 at 20:43, Holger Wansing wrote: > > > > Hi, > > > > James Addison wrote (Sun, 14 Apr 2024 23:52:03 +0100): > > > From some testing of these: the search results have a problem that they > > > hyperlink to a language-less .html URL, meaning that clicking a result > > > link in > > > the DE-language search results takes the user to a EN-language page. > > > > Yes, good catch. > > However it's even worse: if you view a German page and use the Search > > function, > > the search index for English is used. > > Wait, I'm confused. Not on your site, though. There you have the > per-language > search indices. > > And in fact, when deployed to the debian.org website, requested-language > search > (mapping of the browser language to an appropriate searchindex.*.js > file) could be > (and is already) a better user experience. If you hypothetically send > me a hyperlink > to a policy section auf Deutsch, that's fine, but when I search for > 'configuration' > after reading that, I might want my browser settings to have been respected, > in > terms of what is searched. > > > I have tried to deal with this by some adaptions in the cronjob - see the > > first two additions in my patch: change all links to search.html into > > search.§lang.html, and rename the language-specific searchindex files into > > searchindex.$lang.js. > > However, that does not seem to be enough. > > When you say it is not enough: could I check what you mean by that? > > > > The _other_ hyperlinks in the static content are replaced as part of the > > > cronjob[1] - but that doesn't work for items in the searchindex.js file. > > > > Why is that a problem at all (maybe you know this already): > > since we use content negotiation at Debian website (so the pages are > > delivered in the correct language according to user's browser setting), we > > change the directory structure away from the default how it's build by > > Sphinx: > > after Sphinx' make there are separate directories for every language, > > and they contain everything for that language, including the searchindex.js > > file. And in that structure it works fine. > > On Debian website we put everything in one directory, adding the language > > code into the filename in front of the .html extension. > > While this works fine for static content, it does not for the search > > function here. > > I think this is a reasonable solution; serving the content from a > single directory > is simple and logical because the permissions and content should be the same; > the latter only differs as a result of locale and therefore translation. > > > > Fortunately I think there might be a better way to do this. Sphinx > > > itself has > > > an HTML builder option 'html_file_suffix' and I think we could use that > > > instead > > > to define the filenames. That option is respected by the search > > > JavaScript > > > using a template variable[3] in the documentation_options.js file. > > > > > > We should be careful of other side-effects if making that change, but it > > > would remove a deployment transformation step on the static content, and I > > > think that's beneficial. > > > > I don't understand how that could affect our search function problem, > > but I could give it a try. > > The main change that it would introduce is that the dynamic search results > that > appear in the search results (as gathered by the JavaScript) have > hyperlinks that > include the build-time suffix in the filename. So in the example > above, you have > linked me to a German-language dokumentation page, and when I search from > that page, I find (based on a DE search index) and am linked to (based on DE > file suffixes) Deutsch results; foo.de.html instead of foo.html for example. > > I'm in two minds about this: if my browser settings say that my locale is > en-150 > and I land on a de-DE page, what language should search be performed in, and > what language should the results link to? > > An answer that I find straightforward is that if the page is de-DE -- which > your > hypothetical link to me was -- then because everything on that page _should_ > (with sufficient translation availability) be in German, then I would expect > to > search and be linked to pages accordingly. If you'd linked to a language-less > URL, then that would (a) have been thoug
Bug#932957: 'Official' Debian-style html theme for Sphinx-based docs
Thanks Holger, On Mon, 15 Apr 2024 at 20:43, Holger Wansing wrote: > > Hi, > > James Addison wrote (Sun, 14 Apr 2024 23:52:03 +0100): > > From some testing of these: the search results have a problem that they > > hyperlink to a language-less .html URL, meaning that clicking a result link > > in > > the DE-language search results takes the user to a EN-language page. > > Yes, good catch. > However it's even worse: if you view a German page and use the Search > function, > the search index for English is used. Wait, I'm confused. Not on your site, though. There you have the per-language search indices. And in fact, when deployed to the debian.org website, requested-language search (mapping of the browser language to an appropriate searchindex.*.js file) could be (and is already) a better user experience. If you hypothetically send me a hyperlink to a policy section auf Deutsch, that's fine, but when I search for 'configuration' after reading that, I might want my browser settings to have been respected, in terms of what is searched. > I have tried to deal with this by some adaptions in the cronjob - see the > first two additions in my patch: change all links to search.html into > search.§lang.html, and rename the language-specific searchindex files into > searchindex.$lang.js. > However, that does not seem to be enough. When you say it is not enough: could I check what you mean by that? > > The _other_ hyperlinks in the static content are replaced as part of the > > cronjob[1] - but that doesn't work for items in the searchindex.js file. > > Why is that a problem at all (maybe you know this already): > since we use content negotiation at Debian website (so the pages are > delivered in the correct language according to user's browser setting), we > change the directory structure away from the default how it's build by Sphinx: > after Sphinx' make there are separate directories for every language, > and they contain everything for that language, including the searchindex.js > file. And in that structure it works fine. > On Debian website we put everything in one directory, adding the language > code into the filename in front of the .html extension. > While this works fine for static content, it does not for the search > function here. I think this is a reasonable solution; serving the content from a single directory is simple and logical because the permissions and content should be the same; the latter only differs as a result of locale and therefore translation. > > Fortunately I think there might be a better way to do this. Sphinx itself > > has > > an HTML builder option 'html_file_suffix' and I think we could use that > > instead > > to define the filenames. That option is respected by the search JavaScript > > using a template variable[3] in the documentation_options.js file. > > > > We should be careful of other side-effects if making that change, but it > > would remove a deployment transformation step on the static content, and I > > think that's beneficial. > > I don't understand how that could affect our search function problem, > but I could give it a try. The main change that it would introduce is that the dynamic search results that appear in the search results (as gathered by the JavaScript) have hyperlinks that include the build-time suffix in the filename. So in the example above, you have linked me to a German-language dokumentation page, and when I search from that page, I find (based on a DE search index) and am linked to (based on DE file suffixes) Deutsch results; foo.de.html instead of foo.html for example. I'm in two minds about this: if my browser settings say that my locale is en-150 and I land on a de-DE page, what language should search be performed in, and what language should the results link to? An answer that I find straightforward is that if the page is de-DE -- which your hypothetical link to me was -- then because everything on that page _should_ (with sufficient translation availability) be in German, then I would expect to search and be linked to pages accordingly. If you'd linked to a language-less URL, then that would (a) have been thoughtful if you suspected that I did not comprehend Deutsch, and (b) also be provided in my default locale, with search and results taking place accordingly, and without any specific locale in the result hyperlinks (because the server will select a resource to serve). Note also: there does _not_ appear to be an equivalent to the 'html_file_suffix' config setting to adjust the search index filename. Regards, James
Bug#932957: 'Official' Debian-style html theme for Sphinx-based docs
Hi, James Addison wrote (Sun, 14 Apr 2024 23:52:03 +0100): > From some testing of these: the search results have a problem that they > hyperlink to a language-less .html URL, meaning that clicking a result link in > the DE-language search results takes the user to a EN-language page. Yes, good catch. However it's even worse: if you view a German page and use the Search function, the search index for English is used. I have tried to deal with this by some adaptions in the cronjob - see the first two additions in my patch: change all links to search.html into search.§lang.html, and rename the language-specific searchindex files into searchindex.$lang.js. However, that does not seem to be enough. > The _other_ hyperlinks in the static content are replaced as part of the > cronjob[1] - but that doesn't work for items in the searchindex.js file. Why is that a problem at all (maybe you know this already): since we use content negotiation at Debian website (so the pages are delivered in the correct language according to user's browser setting), we change the directory structure away from the default how it's build by Sphinx: after Sphinx' make there are separate directories for every language, and they contain everything for that language, including the searchindex.js file. And in that structure it works fine. On Debian website we put everything in one directory, adding the language code into the filename in front of the .html extension. While this works fine for static content, it does not for the search function here. > Fortunately I think there might be a better way to do this. Sphinx itself has > an HTML builder option 'html_file_suffix' and I think we could use that > instead > to define the filenames. That option is respected by the search JavaScript > using a template variable[3] in the documentation_options.js file. > > We should be careful of other side-effects if making that change, but it > would remove a deployment transformation step on the static content, and I > think that's beneficial. I don't understand how that could affect our search function problem, but I could give it a try. Holger -- Holger Wansing PGP-Fingerprint: 496A C6E8 1442 4B34 8508 3529 59F1 87CA 156E B076
Bug#932957: 'Official' Debian-style html theme for Sphinx-based docs
Hi Holger, On Sun, 14 Apr 2024 22:40:36 +0200, Holger wrote: > I forgot to mention, that I have pushed a release-notes variant with this theme to > https://people.debian.org/~holgerw/new-rtd-sphinx-theme-for-debian/release-notes/release-notes/index.en.html > (English) > > https://people.debian.org/~holgerw/new-rtd-sphinx-theme-for-debian/release-notes/release-notes/index.de.html > (German) > > https://people.debian.org/~holgerw/new-rtd-sphinx-theme-for-debian/release-notes/release-notes/index.ca.html > (Catalan) >From some testing of these: the search results have a problem that they hyperlink to a language-less .html URL, meaning that clicking a result link in the DE-language search results takes the user to a EN-language page. The _other_ hyperlinks in the static content are replaced as part of the cronjob[1] - but that doesn't work for items in the searchindex.js file. Fortunately I think there might be a better way to do this. Sphinx itself has an HTML builder option 'html_file_suffix' and I think we could use that instead to define the filenames. That option is respected by the search JavaScript using a template variable[3] in the documentation_options.js file. We should be careful of other side-effects if making that change, but it would remove a deployment transformation step on the static content, and I think that's beneficial. [1] - https://salsa.debian.org/webmaster-team/cron/-/blob/3462a061d0a67dce3761b0f4d9357c017ad0a50b/parts/7release-notes#L64-70 [2] - https://www.sphinx-doc.org/en/master/usage/configuration.html#confval-html_file_suffix [3] - https://github.com/sphinx-doc/sphinx/blob/cf7d2759af0852d67288e58d823d51fe860749ca/sphinx/themes/basic/static/documentation_options.js_t#L6
Bug#932957: 'Official' Debian-style html theme for Sphinx-based docs
Hi, Holger Wansing wrote (Sun, 14 Apr 2024 22:25:21 +0200): > It can be seen at debian-policy under > https://www.debian.org/doc/debian-policy/ I forgot to mention, that I have pushed a release-notes variant with this theme to https://people.debian.org/~holgerw/new-rtd-sphinx-theme-for-debian/release-notes/release-notes/index.en.html (English) https://people.debian.org/~holgerw/new-rtd-sphinx-theme-for-debian/release-notes/release-notes/index.de.html (German) https://people.debian.org/~holgerw/new-rtd-sphinx-theme-for-debian/release-notes/release-notes/index.ca.html (Catalan) And we need an additional package installed on wolkenstein, to build the release-notes with this theme. Holger -- Holger Wansing PGP-Fingerprint: 496A C6E8 1442 4B34 8508 3529 59F1 87CA 156E B076
Bug#932957: 'Official' Debian-style html theme for Sphinx-based docs
Hi,
you may have noticed that we have an 'official' Debian-style html theme for
Sphinx-based manuals on the Debian website now.
It can be seen at debian-policy under
https://www.debian.org/doc/debian-policy/
It was created by Stéphane Blondon, based on a theme from readthedocs.org.
Any objections against porting this theme to the release-notes as well?
To make this theme work on the Debian website, there are some more changings
needed in webmaster's cron repo; I have prepared them and attached to this
mail, just for completeness.
Holger
--
Holger Wansing
PGP-Fingerprint: 496A C6E8 1442 4B34 8508 3529 59F1 87CA 156E B076
>From 2704fab5800f36aeafa29275e7afd13b422ecb81 Mon Sep 17 00:00:00 2001
From: Holger Wansing
Date: Sun, 14 Apr 2024 22:04:20 +0200
Subject: [PATCH] =?UTF-8?q?Switch=20to=20new=20Debian-style=20html=20theme?=
=?UTF-8?q?=20by=20St=C3=A9phane=20Blondon,=20based=20on=20readthedocs.org?=
=?UTF-8?q?=20theme?=
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit
---
source/_static/debian.css | 103 ++
source/conf.py| 14 +++---
2 files changed, 109 insertions(+), 8 deletions(-)
create mode 100644 source/_static/debian.css
diff --git a/source/_static/debian.css b/source/_static/debian.css
new file mode 100644
index ..7f0981b0
--- /dev/null
+++ b/source/_static/debian.css
@@ -0,0 +1,103 @@
+/* Debian Cascading stylesheet for Sphinx */
+
+div.related {
+background-color: #C70036;
+}
+
+.rst-content h1, .rst-content h2, .rst-content h3, .rst-content h4, .rst-content h5, .rst-content h6 {
+color: #C70036;
+}
+
+.wy-nav-top {
+background-color: #C70036;
+}
+
+.wy-side-nav-search {
+background-color: #C70036;
+}
+
+.rst-content a:link {
+color: #0035C7;
+text-decoration: none;
+}
+.rst-content a:visited {
+color: #00207A;
+text-decoration: none;
+}
+.rst-content a:link:hover {
+color: #00207A;
+text-decoration: underline;
+}
+
+
+/* Table in content */
+
+.wy-table-responsive table td, .wy-table-responsive table th {
+white-space: normal;
+}
+
+.rst-content table.docutils, .wy-table-bordered-all {
+width: 100%;
+}
+
+.wy-table-responsive table.docutils thead tr {
+background-color: #C70036;
+border: 1px solid black;
+color: black;
+}
+
+.wy-table-responsive table.docutils thead tr:hover {
+color: #fcfcfc;
+}
+
+.wy-table-responsive table.docutils tbody tr:hover {
+background-color:#66;
+color: #FF;
+}
+
+.rst-content table.docutils:not(.field-list) tbody tr:hover:nth-child(2n-1), .wy-table-backed, .wy-table-odd td, .wy-table-striped tr:nth-child(2n-1) td {
+background-color:#66;
+}
+
+/* Previous and next buttons */
+
+.rst-footer-buttons .btn:hover {
+text-decoration: none !important;
+}
+
+/* Version release more readable */
+
+.wy-side-nav-search > div.version {
+color: #FCFCFC;
+}
+
+/* Infos blocks */
+
+div.warning {
+border: 1px dashed #EFF500;
+background-color: #eff50030;
+}
+
+div.note {
+border: 1px dashed blue;
+background-color: #ff30;
+
+}
+
+.warning, .note {
+margin-left: 1em;
+margin-right: 1em;
+}
+
+@media (max-width: 5in), (max-device-width: 5in){
+.warning, .note {
+margin-left: 0.5em;
+margin-right: 0.5em;
+}
+}
+
+/* Notes */
+
+html.writer-html5 .rst-content aside.citation, html.writer-html5 .rst-content aside.footnote, html.writer-html5 .rst-content div.citation {
+display: block;
+}
diff --git a/source/conf.py b/source/conf.py
index 855fb942..ec055233 100644
--- a/source/conf.py
+++ b/source/conf.py
@@ -127,20 +127,15 @@ pygments_style = None
# The theme to use for HTML and HTML Help pages. See the documentation for
# a list of builtin themes.
#
-html_theme = 'alabaster'
+html_theme = 'sphinx_rtd_theme'
# Theme options are theme-specific and customize the look and feel of a theme
# further. For a list of options available for each theme, see the
# documentation.
#
html_theme_options = {
- 'logo': 'openlogo-release-notes.png',
- 'show_powered_by': False,
- 'link': '#0035c7',
- 'sidebar_header': '#c70036',
- 'sidebar_link': '#0035c7',
- 'show_related': True,
- 'show_relbars': True
+ # To get previous/next buttons at the top and the bottom:
+ 'prev_next_buttons_location': 'both'
}
# Add any paths that contain custom static files (such as style sheets) here,
@@ -148,6 +143,9 @@ html_theme_options = {
# so a file named "default.css" will overwrite the builtin "default.css".
html_static_path = ['_static']
+# Overwrite theme to fit Debian colors
+html_css_files = ['debian.css']
+
html_js_files = ['switchers.js']
# Hide âCreated using Sphinxâ in the HTML footer
--
2.39.2
diff --
Re: Bug#1053549: Create a Debian theme for documentation based in Sphinx (reStructuredText)
Hi, Laura Arjona Reina wrote (Fri, 6 Oct 2023 09:35:09 +0200): > Several documentation manuals are being generated now using > ReStructuredText and Sphinx, and it would be nice that a Debian theme in > Sphinx is created and used to match our docs appearance with the Debian > website colours etc. Thanks to Stéphane Blondon, we have a nice Debian theme for Sphinx now, and I managed to get it to the website in the end so far, currently visible at debian-policy: https://www.debian.org/doc/debian-policy/index.html I had to deal with some missing javascript files as well, to make the sidebar appear/disappear on small screens like smartphones, but that works now. The only thing which is not working currently, is the search functionality, but since that's not theme-specific I guess (please correct me, if I'm wrong), I close this bug. Javascript leaves some open issues, but for those I will follow-up on some existing javascript bugs, we already have for the website/manuals. Holger -- Holger Wansing PGP-Fingerprint: 496A C6E8 1442 4B34 8508 3529 59F1 87CA 156E B076
Re: issue with Debian-style html theme for sphinx-based documents
Hello, On Fri 05 Apr 2024 at 02:07pm +02, Holger Wansing wrote: > Hi, > > Holger Wansing wrote (Tue, 2 Apr 2024 14:47:12 +0200): >> We need a separate copy of 3 packages in our www build tree on >> wolkenstein and all www static mirrors (simply let DSA install those >> packages on the machines will not work). >> And every sphinx-based manual needs relative symlinks in its tree, pointing >> to the above packages' content. >> The 1ftpfiles and 7doc scripts, which need to be adapted for that, and >> also the situation on the www mirrors is getting more complex, so I'm unsure >> if we want this. >> See my patch. >> >> On the other side, I don't see any other solution apart from developing >> a new theme. > > Since there were no objections, I pushed that yesterday (+ one additional > change was needed), and that works now. Thank you very much again. -- Sean Whitton signature.asc Description: PGP signature
Re: issue with Debian-style html theme for sphinx-based documents
Hi, Holger Wansing wrote (Tue, 2 Apr 2024 14:47:12 +0200): > We need a separate copy of 3 packages in our www build tree on > wolkenstein and all www static mirrors (simply let DSA install those > packages on the machines will not work). > And every sphinx-based manual needs relative symlinks in its tree, pointing > to the above packages' content. > The 1ftpfiles and 7doc scripts, which need to be adapted for that, and > also the situation on the www mirrors is getting more complex, so I'm unsure > if we want this. > See my patch. > > On the other side, I don't see any other solution apart from developing > a new theme. Since there were no objections, I pushed that yesterday (+ one additional change was needed), and that works now. Holger -- Holger Wansing PGP-Fingerprint: 496A C6E8 1442 4B34 8508 3529 59F1 87CA 156E B076
Re: issue with Debian-style html theme for sphinx-based documents
Hi Holger, even if things get more complex, this is a working solution. I'm very happy for that and there's no need for spending more time into looking for a perfect solution. >From my side you get a thank you very much and a GO for applying this patch. > On Tue, 2 Apr 2024 14:47:12 +0200, Holger Wansing > said: > The 1ftpfiles and 7doc scripts, which need to be adapted for that, and > also the situation on the www mirrors is getting more complex, so I'm unsure > if we want this. > See my patch. > On the other side, I don't see any other solution apart from developing > a new theme. -- regards Thomas
issue with Debian-style html theme for sphinx-based documents
Control: reassign 1064593 www.debian.org
Hi all,
Sean Whitton wrote (Tue, 02 Apr 2024 10:11:39 +0800):
> Hello,
>
> On Mon 01 Apr 2024 at 02:50pm +02, Holger Wansing wrote:
>
> > I now tend to switch to another approach (also proposed similarly by Adam):
> >
> > instead of relying on the rtd-theme package in the default install path of
> > the
> > package installed by DSA, I will use the infrastructure in 1ftpfiles and
> > 7doc of webmaster's cron repo, to (always) fetch the latest version of that
> > package (and two more packages, which the former depends on:
> > fonts-font-awesome
> > and fonts-lato, to get the needed fonts) and unpack+copy them into
> > a dedicated path inside the www build tree.
> >
> > That path will be synced to the static www mirrors, and we can symlink
> > to it from the manuals.
> > (And the content of that path will automatically be kept up-to-date on
> > the unstable version of packages, so we don't get outdated/orphaned
> > copies of that packages in the isolated path.)
> > I want the unstable version of that packages here, since they need to
> > incorporate with the unstable version of the different manuals (like
> > debian-policy), and those packages are built by buildd, so unstable.
> >
> > How does that sound in the light of Debian guidelines and best practice?
> >
> > Is it ok, to have such "isolated copies" of packages as described above?
> >
> > I have not much experience in similar things, so I would like to get
> > some comments here, please.
>
> I mean, it seems okay to me, but it's up to the web team really.
Yeah, that makes we aware of that this bug is now assigned to the wrong
package (this is no longer an issue on debian-policy side, but on
www.debian.org).
Therefore, web team is most probably not aware at all of this specific issue.
So, I'm reassigning this bug to www.debian.org now.
And also debian-doc in CC, since in the past the doc/manuals part of
the website was somehow under responsibility of -doc people IIRC.
@web + doc teams:
We have (after more than 5 years) a new Debian-style html theme for
sphinx-based
documents, created by Stéphane Blondon based on a readthedocs.org theme.
It looks really good, and a preview of debian-policy with this theme can be
seen here:
https://people.debian.org/~holgerw/new-rtd-sphinx-theme-for-debian/debian-policy/debian-policy/
However, getting this theme to work on the Debian website became more and more
of a challenge these days/weeks.
An issue came up, which can be seen at Debian's website:
https://www.debian.org/doc/debian-policy/
The html layout is completely broken, because the theme relys on files
provided by the sphinx-rtd-theme-common package, which are not there on
the www mirrors.
Getting that files correctly on the mirrors occured to become difficult, sadly.
You can find a current summary of this issue at
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1064593#125
This comes down to one more adaption of the 1ftpfiles / 7doc scripts
in webmaster's cron repo.
Attached is the latest version of my patch, to get this going.
It works so far, but I wonder if this is the way we want to go.
There is a significant amount of things, which need to work correctly to
make this new theme appear correctly on Debian's website:
We need a separate copy of 3 packages in our www build tree on
wolkenstein and all www static mirrors (simply let DSA install those
packages on the machines will not work).
And every sphinx-based manual needs relative symlinks in its tree, pointing
to the above packages' content.
The 1ftpfiles and 7doc scripts, which need to be adapted for that, and
also the situation on the www mirrors is getting more complex, so I'm unsure
if we want this.
See my patch.
On the other side, I don't see any other solution apart from developing
a new theme.
Comments?
Holger
--
Holger Wansing
PGP-Fingerprint: 496A C6E8 1442 4B34 8508 3529 59F1 87CA 156E B076
diff --git a/parts/1ftpfiles b/parts/1ftpfiles
index 3a2d953..3079131 100755
--- a/parts/1ftpfiles
+++ b/parts/1ftpfiles
@@ -72,6 +72,11 @@ $WGET -O - $httpurlamd64 | xzcat >Packages-amd64
httpurlrepo="http://${ftpsite}/debian";
+# readthedocs.org html theme files and related fonts
+getdeb all sphinx-rtd-theme-common
+getdeb all fonts-font-awesome
+getdeb all fonts-lato
+
# many language specific binary packages (arch=all)
getdebs aptitude
getdebs debian-faq
diff --git a/parts/7doc b/parts/7doc
index b079aea..c2ff284 100755
--- a/parts/7doc
+++ b/parts/7doc
@@ -341,6 +341,39 @@ if [ "$lang" = "en" ]; then
fi
}
+#
+
+place_symlinks_to_theme_files()
+# To make the html theme (which is b
Re: Request to join the Debian Documentation Project group
Hi Jefferson, On Mon, Feb 26, 2024 at 10:24:02PM +, Debian GitLab wrote: > > Jefferson Carneiro (https://salsa.debian.org/oslackjeff) requested Developer > access to the Debian Documentation Project group. > > https://salsa.debian.org/groups/ddp-team/-/group_members I've seen your nice introduction at https://lists.debian.org/msgid-search/077aad3e-00b4-4b6e-ae36-bf83b7a0f...@riseup.net . But do you have some specific plans to work on debian-documentation stuff? Or maybe even have a patch ready yet? Thanks for you interest! Bye, Joost
Not able to Shutdown or Reboot Debian 12 KDE Plasma
Respected Sir/ Ma'am This is to bring to your notice that Debian 12 KDE Plasma is getting stuck at kvm: exiting hardware virtualization during the Shutdown and Reboot process. I tried searching for a solution on various Linux Forums but none of them worked. Here is the list of things I have tried till now: 1) Downloading 'dracut' 2) Updating Grub and Setting DEFAULT TIMEOUTSTOP=30s 3) Setting Debian KDE Plasma to X11 4) Tried Shutting Down using terminal and from System Launcher 5) Finally, I shutdown using the power button of my Laptop. (This works but is annoying as hell!!) Some Linux Forums also said that it is a bug and cannot be fixed just like that. Therefore, I request you to kindly look into this bug and fix it in the next patch update. Also, please let me know if there is some other simple fix to this problem. Regards Losers' Arena
Bug#992113: marked as done (release-notes: Initial availability of Bazel build system in Debian)
Your message dated Sat, 10 Jun 2023 17:43:45 +0200 with message-id and subject line Re: Bug#992113: release-notes: Initial availability of Bazel build system in Debian has caused the Debian Bug report #992113, regarding release-notes: Initial availability of Bazel build system in Debian to be marked as done. This means that you claim that the problem has been dealt with. If this is not the case it is now your responsibility to reopen the Bug report if necessary, and/or fix the problem forthwith. (NB: If you are a system administrator and have no idea what this message is talking about, this may indicate a serious mail system misconfiguration somewhere. Please contact ow...@bugs.debian.org immediately.) -- 992113: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=992113 Debian Bug Tracking System Contact ow...@bugs.debian.org with problems --- Begin Message --- Package: release-notes Severity: normal Dear Release Team, If possible, please include the following in section 2.2 (What's new in the distribution?) of the release notes for the following architectures: amd64, arm64, ppc64el, s390x, ppc64, riscv64 2.2.x Initial availability of the Bazel build system The [Bazel](https://bazel.build/) build system is available in Debian starting with this release. This is a bootstrap variant that will not include local versions of the extended Bazel ecosystem. However, the current package **does** provide identical functionality to core upstream Bazel, with the advantage of convenient Debian package management for the installation. While building Debian packages is not currently recommended, any software that supports Bazel builds should build normally using this Debian-native Bazel package. This includes build-time downloads of required dependencies. The [Debian Bazel Team](https://salsa.debian.org/bazel-team/meta) is working to package an extensible version of Bazel for future Debian releases. This extensible version will allow additional components of the Bazel ecosystem to be included as native Debian packages. More importantly, this version will allow Debian packages to be built using Bazel. Contributions to the team are welcome! Please let me know if you have any questions. Feel free to make minor edits if you think it will improve readability for users. I did NOT wrap the text above at 80 columns since I hope that will make it easier to copy/paste it into the release notes. Thank you! -Olek (On behalf of the Bazel packaging team) --- End Message --- --- Begin Message --- Hi, On 08-06-2023 23:25, Olek Wojnar wrote: I just reviewed it and it looks good. In the future, and now that I see how your process works, I'll do the MR myself to save you the trouble. Thanks for doing it this time! Particularly, I think the package to installed is bazel-bootstrap, can you confirm? That is correct. That was merged in the mean time. Paul OpenPGP_signature Description: OpenPGP digital signature --- End Message ---
Processed: Re: Bug#992113: release-notes: Initial availability of Bazel build system in Debian
Processing control commands: > tag -1 - moreinfo Bug #992113 [release-notes] release-notes: Initial availability of Bazel build system in Debian Removed tag(s) moreinfo. -- 992113: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=992113 Debian Bug Tracking System Contact ow...@bugs.debian.org with problems
Bug#992113: release-notes: Initial availability of Bazel build system in Debian
Control: tag -1 - moreinfo Hi Paul, On Thu, Jun 8, 2023 at 6:56 AM Paul Gevers wrote: I reworded a tiny bit and added markup. Please review the merge request I just reviewed it and it looks good. In the future, and now that I see how your process works, I'll do the MR myself to save you the trouble. Thanks for doing it this time! Particularly, I think the package to installed is bazel-bootstrap, can you confirm? That is correct. Thanks again! -Olek OpenPGP_signature Description: OpenPGP digital signature
Bug#992113: release-notes: Initial availability of Bazel build system in Debian
Control: tag -1 patch moreinfo Hi, On 29-05-2023 06:22, Paul Gevers wrote: 2.2.x Initial availability of the Bazel build system The [Bazel](https://bazel.build/) build system is available in Debian starting with this release. This is a bootstrap variant that will not include local versions of the extended Bazel ecosystem. However, the current package **does** provide identical functionality to core upstream Bazel, with the advantage of convenient Debian package management for the installation. While building Debian packages is not currently recommended, any software that supports Bazel builds should build normally using this Debian-native Bazel package. This includes build-time downloads of required dependencies. The [Debian Bazel Team](https://salsa.debian.org/bazel-team/meta) is working to package an extensible version of Bazel for future Debian releases. This extensible version will allow additional components of the Bazel ecosystem to be included as native Debian packages. More importantly, this version will allow Debian packages to be built using Bazel. Contributions to the team are welcome! I reworded a tiny bit and added markup. Please review the merge request here: https://salsa.debian.org/ddp-team/release-notes/-/merge_requests/192 Particularly, I think the package to installed is bazel-bootstrap, can you confirm? Paul OpenPGP_signature Description: OpenPGP digital signature
Processed: Re: Bug#992113: release-notes: Initial availability of Bazel build system in Debian
Processing control commands: > tag -1 patch moreinfo Bug #992113 [release-notes] release-notes: Initial availability of Bazel build system in Debian Ignoring request to alter tags of bug #992113 to the same tags previously set -- 992113: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=992113 Debian Bug Tracking System Contact ow...@bugs.debian.org with problems
Bug#1037112: marked as done (release-notes: Release notes paragraph from Debian Astro team)
Your message dated Thu, 8 Jun 2023 12:07:28 +0200 with message-id <7775e096-c9fa-4cf9-7bcf-2d0496949...@debian.org> and subject line Re: Bug#1037112: release-notes: Release notes paragraph from Debian Astro team has caused the Debian Bug report #1037112, regarding release-notes: Release notes paragraph from Debian Astro team to be marked as done. This means that you claim that the problem has been dealt with. If this is not the case it is now your responsibility to reopen the Bug report if necessary, and/or fix the problem forthwith. (NB: If you are a system administrator and have no idea what this message is talking about, this may indicate a serious mail system misconfiguration somewhere. Please contact ow...@bugs.debian.org immediately.) -- 1037112: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1037112 Debian Bug Tracking System Contact ow...@bugs.debian.org with problems --- Begin Message --- Package: release-notes Severity: normal X-Debbugs-Cc: debian-as...@lists.debian.org Please add an Debian Astro section to the Bookworm release notes. The merge request is available in https://salsa.debian.org/ddp-team/release-notes/-/merge_requests/188 Thank you! Best regards Ole --- End Message --- --- Begin Message --- Hi On 05-06-2023 08:09, Ole Streicher wrote: Please add an Debian Astro section to the Bookworm release notes. The merge request is available in https://salsa.debian.org/ddp-team/release-notes/-/merge_requests/188 That got merged. Paul OpenPGP_signature Description: OpenPGP digital signature --- End Message ---
Bug#1037116: Debian Edu bookworm not ready
Hi Holger, hi all, On Mo 05 Jun 2023 10:04:44 CEST, Holger Levsen wrote: package: release-notes x-debbugs-cc: debian-...@lists.debian.org hi, maybe we should have a release notes entry stating that debian-edu bookworm is not yet ready?!? :(( https://wiki.debian.org/DebianEdu/Status/Bookworm has the details what needs doing. sorry, I could not help with this in a sufficient timely manner. I'll see what I can do for Debian 12.1 and/or Debian 12.2. I definitely have an interest in seeing Debian Edu 12 becoming available and usable. Mike -- DAS-NETZWERKTEAM c\o Technik- und Ökologiezentrum Eckernförde Mike Gabriel, Marienthaler Str. 17, 24340 Eckernförde mobile: +49 (1520) 1976 148 landline: +49 (4351) 850 8940 GnuPG Fingerprint: 9BFB AEE8 6C0A A5FF BF22 0782 9AF4 6B30 2577 1B31 mail: mike.gabr...@das-netzwerkteam.de, http://das-netzwerkteam.de pgpQYPjKp4d3e.pgp Description: Digitale PGP-Signatur
Bug#1037116: Debian Edu bookworm not ready
package: release-notes x-debbugs-cc: debian-...@lists.debian.org hi, maybe we should have a release notes entry stating that debian-edu bookworm is not yet ready?!? :(( https://wiki.debian.org/DebianEdu/Status/Bookworm has the details what needs doing. -- cheers, Holger ⢀⣴⠾⠻⢶⣦⠀ ⣾⠁⢠⠒⠀⣿⡁ holger@(debian|reproducible-builds|layer-acht).org ⢿⡄⠘⠷⠚⠋⠀ OpenPGP: B8BF54137B09D35CF026FE9D 091AB856069AAA1C ⠈⠳⣄ Stop saying that we are all in the same boat. We’re all in the same storm. But we’re not all in the same boat. signature.asc Description: PGP signature
Bug#1037112: release-notes: Release notes paragraph from Debian Astro team
Package: release-notes Severity: normal X-Debbugs-Cc: debian-as...@lists.debian.org Please add an Debian Astro section to the Bookworm release notes. The merge request is available in https://salsa.debian.org/ddp-team/release-notes/-/merge_requests/188 Thank you! Best regards Ole
Bug#992113: release-notes: Initial availability of Bazel build system in Debian
Hi Paul, On 5/29/23 00:22, Paul Gevers wrote: Hi Olek, First and foremost, I'm sorry this bug report dropped completely from the radar during the major part of bullseye being stable. Thank you for the apology. I definitely understand how crazy things get prior to release! On 11-08-2021 21:28, Olek Wojnar wrote: If possible, please include the following in section 2.2 (What's new in the distribution?) of the release notes for the following architectures: amd64, arm64, ppc64el, s390x, ppc64, riscv64 2.2.x Initial availability of the Bazel build system The [Bazel](https://bazel.build/) build system is available in Debian starting with this release. This is a bootstrap variant that will not include local versions of the extended Bazel ecosystem. However, the current package **does** provide identical functionality to core upstream Bazel, with the advantage of convenient Debian package management for the installation. While building Debian packages is not currently recommended, any software that supports Bazel builds should build normally using this Debian-native Bazel package. This includes build-time downloads of required dependencies. The [Debian Bazel Team](https://salsa.debian.org/bazel-team/meta) is working to package an extensible version of Bazel for future Debian releases. This extensible version will allow additional components of the Bazel ecosystem to be included as native Debian packages. More importantly, this version will allow Debian packages to be built using Bazel. Contributions to the team are welcome! We can still add it to the bullseye release notes. Should we do that still? Yes, please do! I'm hoping to get to the point of being able to build Debian packages with Bazel for the next release so I'll plan to file a release-notes bug early for Trixie. Thanks for following up on this. -Olek
Bug#992113: release-notes: Initial availability of Bazel build system in Debian
Hi Olek, First and foremost, I'm sorry this bug report dropped completely from the radar during the major part of bullseye being stable. On 11-08-2021 21:28, Olek Wojnar wrote: If possible, please include the following in section 2.2 (What's new in the distribution?) of the release notes for the following architectures: amd64, arm64, ppc64el, s390x, ppc64, riscv64 2.2.x Initial availability of the Bazel build system The [Bazel](https://bazel.build/) build system is available in Debian starting with this release. This is a bootstrap variant that will not include local versions of the extended Bazel ecosystem. However, the current package **does** provide identical functionality to core upstream Bazel, with the advantage of convenient Debian package management for the installation. While building Debian packages is not currently recommended, any software that supports Bazel builds should build normally using this Debian-native Bazel package. This includes build-time downloads of required dependencies. The [Debian Bazel Team](https://salsa.debian.org/bazel-team/meta) is working to package an extensible version of Bazel for future Debian releases. This extensible version will allow additional components of the Bazel ecosystem to be included as native Debian packages. More importantly, this version will allow Debian packages to be built using Bazel. Contributions to the team are welcome! We can still add it to the bullseye release notes. Should we do that still? Paul OpenPGP_signature Description: OpenPGP digital signature
Bug#1036776: marked as done (release-notes: Release notes paragraph from Debian Med team)
Your message dated Sun, 28 May 2023 06:44:41 +0200 with message-id and subject line Re: Bug#1036776: release-notes: Release notes paragraph from Debian Med team has caused the Debian Bug report #1036776, regarding release-notes: Release notes paragraph from Debian Med team to be marked as done. This means that you claim that the problem has been dealt with. If this is not the case it is now your responsibility to reopen the Bug report if necessary, and/or fix the problem forthwith. (NB: If you are a system administrator and have no idea what this message is talking about, this may indicate a serious mail system misconfiguration somewhere. Please contact ow...@bugs.debian.org immediately.) -- 1036776: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1036776 Debian Bug Tracking System Contact ow...@bugs.debian.org with problems --- Begin Message --- Package: release-notes Severity: normal X-Debbugs-Cc: debian-...@lists.debian.org Please add the following patch from the Debian Med team to the release notes: News from Debian Med Blend As in every release new packages in the field of life sciences and medicine were added. The new package shiny-server might be worth extra mentioning since it simplifies scientific web applications using R. We kept on to get Continuous Integration support for the packages maintained by the Debian Med team. The Debian Med team is continuously interested in feedback from users specifically in the form of requesting the packaging of not yet packaged free software or backports from new packages or higher versions in unstable. To install packages maintained by the Debian Med team, install the metapackages named med-*, which are at version 3.8.x for Debian bookworm. Feel free to visit the https://blends.debian.org/med/tasks";>Debian Med tasks pages to see the full range of biological and medical software available in Debian. Kind regards Andreas. --- End Message --- --- Begin Message --- Hi On 27-05-2023 07:14, Andreas Tille wrote: Thanks a lot for your comments and for your work on the release notes And accepted the proposal in the release notes. Paul OpenPGP_signature Description: OpenPGP digital signature --- End Message ---
Bug#1036776: release-notes: Release notes paragraph from Debian Med team
Hi Justin, Am Sat, May 27, 2023 at 04:42:32AM +0100 schrieb Justin B Rye: > Andreas Tille wroteL > > Please add the following patch from the Debian Med team to the release > > notes: > > Some English-usage suggestions: Thanks a lot for looking onto the text in "pedantic mode". ;-) I'm not a native speaker and its perfectly welcome if someone with better language is polishing my scribbling. So I simply ACK all those enhancements. > > News from Debian Med Blend > > > > > > As in every release new packages in the field of life sciences and > > medicine > > were added. > > "Have been" added, and I think it works better as ACK. > As in every release new packages have been added in the fields of > medicine > and life sciences. > > > The new package shiny-server might be worth extra > > mentioning > > The new package role="package">shiny-server >might be worth a particular mention, > > (Or "might be particularly worth mentioning", among other options.) ACK > > since it simplifies scientific web applications using R. > > (Is it worth reorganising that into something like "since it makes it > simpler for scientific web applications to use R" or am I only > noticing it because I'm reading in pedant mode?) > > > We kept on to > > get > > Continuous Integration support for the packages maintained by the > > Debian Med > > team. > > It's not clear whether this means that you maintained the effort and > as a result got CI support or whether CI support is something you > already had that you kept going. Maybe: >We also kept > up the > effort to provide Continuous Integration support for the packages > maintained > by the Debian Med team. This is definitely the better wording which describes what I intended to write. > > > > The Debian Med team is continuously interested in feedback from users > > specifically in the form of requesting the packaging of not yet packaged > > free software or backports from new packages or higher versions in > > unstable. > > > > This needs at least one extra comma; maybe even: ACK. > The Debian Med team is always interested in feedback from users, > especially in the form of requests for packaging of not-yet-packaged > free software, or for backports from new packages or higher versions > in unstable. > > (Are you *allowed* to put things in stable-backports if there's no > version in stable?) Yes, stable-backports is required to have this package in testing. This might be higher versions than in stable or packages which are not available in stable. > > To install packages maintained by the Debian Med team, install the > > metapackages named med-*, which are at version 3.8.x for Debian > > bookworm. > > Feel free to visit the > > https://blends.debian.org/med/tasks";>Debian Med tasks > > pages > > to see the full range of biological and medical software available in > > Debian. > > > > This all looks good; I suppose med-* gets a > * but no tags. I admit I'm not very deep in these tags - thus feel free to pick the proper one. Thanks a lot for your comments and for your work on the release notes Andreas. -- http://fam-tille.de
Bug#1036776: release-notes: Release notes paragraph from Debian Med team
Andreas Tille wroteL > Please add the following patch from the Debian Med team to the release notes: Some English-usage suggestions: > > News from Debian Med Blend > > > As in every release new packages in the field of life sciences and > medicine > were added. "Have been" added, and I think it works better as As in every release new packages have been added in the fields of medicine and life sciences. > The new package shiny-server might be worth extra mentioning The new package shiny-server might be worth a particular mention, (Or "might be particularly worth mentioning", among other options.) > since it simplifies scientific web applications using R. (Is it worth reorganising that into something like "since it makes it simpler for scientific web applications to use R" or am I only noticing it because I'm reading in pedant mode?) > We kept on to > get > Continuous Integration support for the packages maintained by the Debian > Med > team. It's not clear whether this means that you maintained the effort and as a result got CI support or whether CI support is something you already had that you kept going. Maybe: We also kept up the effort to provide Continuous Integration support for the packages maintained by the Debian Med team. > > The Debian Med team is continuously interested in feedback from users > specifically in the form of requesting the packaging of not yet packaged > free software or backports from new packages or higher versions in > unstable. > This needs at least one extra comma; maybe even: The Debian Med team is always interested in feedback from users, especially in the form of requests for packaging of not-yet-packaged free software, or for backports from new packages or higher versions in unstable. (Are you *allowed* to put things in stable-backports if there's no version in stable?) > To install packages maintained by the Debian Med team, install the > metapackages named med-*, which are at version 3.8.x for Debian bookworm. > Feel free to visit the > https://blends.debian.org/med/tasks";>Debian Med tasks > pages > to see the full range of biological and medical software available in > Debian. > This all looks good; I suppose med-* gets a * but no tags. -- JBR with qualifications in linguistics, experience as a Debian sysadmin, and probably no clue about this particular package
Bug#1036776: release-notes: Release notes paragraph from Debian Med team
Package: release-notes Severity: normal X-Debbugs-Cc: debian-...@lists.debian.org Please add the following patch from the Debian Med team to the release notes: News from Debian Med Blend As in every release new packages in the field of life sciences and medicine were added. The new package shiny-server might be worth extra mentioning since it simplifies scientific web applications using R. We kept on to get Continuous Integration support for the packages maintained by the Debian Med team. The Debian Med team is continuously interested in feedback from users specifically in the form of requesting the packaging of not yet packaged free software or backports from new packages or higher versions in unstable. To install packages maintained by the Debian Med team, install the metapackages named med-*, which are at version 3.8.x for Debian bookworm. Feel free to visit the https://blends.debian.org/med/tasks";>Debian Med tasks pages to see the full range of biological and medical software available in Debian. Kind regards Andreas.
Bug#1036358: release-notes: Debian 12 expected to be last release w/ installer for i386
Paul Gevers wrote: > On 20-05-2023 16:21, Justin B Rye wrote: > > When do we stop producing official Release Notes? > > You mean when do we stop accepting changes to the Release Notes and stop > building them? Once the release is EOL. However, I don't expect a lot of > people to look for new versions after a while. You can still find the old > release notes on-line. I was just wondering if it was standard procedure for the last set of Release Notes for a given arch to announce that that's what they are. Given how arch qualification works, this could be tricky; but of course we might still consider i386 a special case. -- JBR with qualifications in linguistics, experience as a Debian sysadmin, and probably no clue about this particular package
Bug#1036358: release-notes: Debian 12 expected to be last release w/ installer for i386
Hi, On 20-05-2023 16:21, Justin B Rye wrote: When do we stop producing official Release Notes? You mean when do we stop accepting changes to the Release Notes and stop building them? Once the release is EOL. However, I don't expect a lot of people to look for new versions after a while. You can still find the old release notes on-line. Paul OpenPGP_signature Description: OpenPGP digital signature
Re: Bug#1035710: unblock: doc-debian/11.3
On Sat, May 20, 2023 at 04:21:47PM +0200, Sebastian Ramacher wrote: > On 2023-05-14 06:47:18 +0200, Joost van Baal-Ilić wrote: > > reopen 1035710 > > retitle 1035710 unblock: doc-debian/11.3 > > thanks > > > > Please unblock package doc-debian > > > > [ Reason ] > > The doc-debian package claims to ship the Constitution for the Debian > > Project, > > the Debian Social Contract and other Debian documents. The versions of > > those > > documents are obsolete [obsolete], which makes the package as now in testing > > very buggy. > > > > unblock doc-debian/11.3 > > Please go ahead with the upload to unstable. Remove the moreinfo tag > once the package is available. Thank you. Unfortunately I don't think I'll make it before the deadline / in the next couple of hours, real life currently doesn't allow me that. If anybody else has time to take a shot at it: here's the current issue's: I made a mistake in the upload to experimental: it says 'experimental' in the top of debian/changelog; should probably be 'unstable'. And the last commit on salsa is misguided. If nobody steps up I can probably prepare an upload for the first bookworm point release. Bye, Joost -- irc: joostvb @ OFTC / libera.chat / ...
Bug#1036358: release-notes: Debian 12 expected to be last release w/ installer for i386
On Sat, 20 May 2023 15:21:49 +0100 Justin B Rye wrote: > Perhaps the angle the Release Notes should be taking on this is to > announce what's going to happen for dist-upgrades to trixie/forkie. > When do we stop producing official Release Notes? That was my aim too. Think people would welcome as much notice of support going away - i dont think the thread has concluded you cant dist-upgrade i386 after bookworm, but it might get quite close to that for many user I've added a MR to better track comments on this here: https://salsa.debian.org/ddp-team/release-notes/-/merge_requests/171
Bug#1036358: release-notes: Debian 12 expected to be last release w/ installer for i386
RL wrote:
> Ansgar writes:
>> On Fri, 2023-05-19 at 15:03 +0100, Steve McIntyre wrote:
>>> My plan is therefore to ship i386 installer images
>>> for bookworm as normal (including bookworm point releases going
>>> forwards), but to disable those builds for testing/trixie
>>> ~immediately after the release.
>>
>> I suggest to already document this in the release notes for bookworm,
>> possibly in Section 2.1 (Supported architectures) or a subsection in
>> Section 5 (Issues to be aware of for bookworm).
>
> I suspect few would re-read 2.1 on upgrade... but is release-notes is
> the best place to document what new installs can use? (maybe doesnt
> matter as there wont be any new installs!)
I would expect a debian-announce message when it happens.
>> Maybe something along these lines:
>>
>> +---
>> | Debian 12 is expected to be the last Debian release providing
>> | full support for i386. Debian 13 will only partially support
>> | i386 and no longer provide installation media for i386.
>> |
>> | We recommend hosts still running the i386 port to be upgraded
>> | to amd64. Legacy i386 software can be run using multi-arch,
>> | chroot environments or containers.
>> +---
>
> We already have a bit about i386 now meaning i686, but i think OK to
> keep separate as that one is bookworm, and this is for the future
>
> Adding links to explain jargon and adding markup: im hope ive got the right
> arch-related entities right here...
>
>
>
> Bookworm is the last Debian release with full support for &arch-title;
>
>
Title lines don't need to be full sentences; this could be just
"&arch-title; support to be reduced from trixie".
>
> The next release, trixie, will not have full support for the
> &architecture; architecture, for example there will be no official
> installer.
>
Do we need a mention of the reason (i.e. that an increasing number of
upstreams are no longer supporting it)?
Perhaps the angle the Release Notes should be taking on this is to
announce what's going to happen for dist-upgrades to trixie/forkie.
When do we stop producing official Release Notes?
>
> Debian recommends converting systems using the &architecture;
> architecture to the 64-bit
> PC architecture (known as amd64) before bookworm
> becomes unsupported:
How about "https://wiki.debian.org/CrossGrading";? I was worried that it
might be a pre-systemd relic, but apparently not.
> most computers manufactured since 2000 can use
> amd64.
I'd have guessed later, given that the i386 arch held the lead in
popcon until 2012 ("https://www.debian.org/News/weekly/2012/17/";), but
this may just be because I use junk hardware.
>
>
> You can still run legacy 32-bit software on 64-bit systems using url="&url-wiki;SystemVirtualization">containers
>
> or in url="&url-wiki;Multiarch/HOWTO">multi-arch
> chroots.
>
>
>
> (but shld use the &url-wiki; entity for wiki links)
>
> Perhaps https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=995397 (Xen no
> longer supports 32-bit Xen PV guests) also relevent to the last para.
It would make a relevant link for the "increasing number of upstreams"
I was mentioning.
--
JBR with qualifications in linguistics, experience as a Debian
sysadmin, and probably no clue about this particular package
Bug#1036358: release-notes: Debian 12 expected to be last release w/ installer for i386
Ansgar writes: > On Fri, 2023-05-19 at 15:03 +0100, Steve McIntyre wrote: >> My plan is therefore to ship i386 installer images >> for bookworm as normal (including bookworm point releases going >> forwards), but to disable those builds for testing/trixie >> ~immediately after the release. > > I suggest to already document this in the release notes for bookworm, > possibly in Section 2.1 (Supported architectures) or a subsection in > Section 5 (Issues to be aware of for bookworm). I suspect few would re-read 2.1 on upgrade... but is release-notes is the best place to document what new installs can use? (maybe doesnt matter as there wont be any new installs!) > Maybe something along these lines: > > +--- > | Debian 12 is expected to be the last Debian release providing > | full support for i386. Debian 13 will only partially support > | i386 and no longer provide installation media for i386. > | > | We recommend hosts still running the i386 port to be upgraded > | to amd64. Legacy i386 software can be run using multi-arch, > | chroot environments or containers. > +--- We already have a bit about i386 now meaning i686, but i think OK to keep separate as that one is bookworm, and this is for the future Adding links to explain jargon and adding markup: im hope ive got the right arch-related entities right here... Bookworm is the last Debian release with full support for &arch-title; The next release, trixie, will not have full support for the &architecture; architecture, for example there will be no official installer. Debian recommends converting systems using the &architecture; architecture to the 64-bit PC architecture (known as amd64) before bookworm becomes unsupported: most computers manufactured since 2000 can use amd64. You can still run legacy 32-bit software on 64-bit systems using containers or in multi-arch chroots. (but shld use the &url-wiki; entity for wiki links) Perhaps https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=995397 (Xen no longer supports 32-bit Xen PV guests) also relevent to the last para.
Bug#1036358: release-notes: Debian 12 expected to be last release w/ installer for i386
Package: release-notes X-Debbugs-Cc: Steve McIntyre , debian-de...@lists.debian.org On Fri, 2023-05-19 at 15:03 +0100, Steve McIntyre wrote: > I had been thinking about doing similar for installer images too, but > with other work going on too I think it got too late in the cycle to > make that change. My plan is therefore to ship i386 installer images > for bookworm as normal (including bookworm point releases going > forwards), but to disable those builds for testing/trixie > ~immediately after the release. I suggest to already document this in the release notes for bookworm, possibly in Section 2.1 (Supported architectures) or a subsection in Section 5 (Issues to be aware of for bookworm). Maybe something along these lines: +--- | Debian 12 is expected to be the last Debian release providing | full support for i386. Debian 13 will only partially support | i386 and no longer provide installation media for i386. | | We recommend hosts still running the i386 port to be upgraded | to amd64. Legacy i386 software can be run using multi-arch, | chroot environments or containers. +--- Ansgar
Bug#992113: release-notes: Initial availability of Bazel build system in Debian
On Wed, 11 Aug 2021 15:28:12 -0400 Olek Wojnar wrote: > If possible, please include the following in section 2.2 (What's new in the > distribution?) of the release notes for the following architectures: > amd64, arm64, ppc64el, s390x, ppc64, riscv64 Is this perhaps an old bug that should be closed - bullseye seems to have a bazel-bootstrap package, so not sure there is anything needed for bookworm? > 2.2.x Initial availability of the Bazel build system > The [Bazel](https://bazel.build/) build system is available in Debian > starting with this release. This is a bootstrap variant that will not include > local versions of the extended Bazel ecosystem. However, the current package > **does** provide identical functionality to core upstream Bazel, with the > advantage of convenient Debian package management for the installation. While > building Debian packages is not currently recommended, any software that > supports Bazel builds should build normally using this Debian-native Bazel > package. This includes build-time downloads of required dependencies. > > The [Debian Bazel Team](https://salsa.debian.org/bazel-team/meta) is working > to package an extensible version of Bazel for future Debian releases. This > extensible version will allow additional components of the Bazel ecosystem to > be included as native Debian packages. More importantly, this version will > allow Debian packages to be built using Bazel. Contributions to the team are > welcome!
Re: How do I push a translation to the official Debian documentation?
On Sun, 2023-04-30 at 12:19 +0800, gugudu wrote: > I tried to register an account with WiKi and it tells me that I cannot > register automatically. > > Account creation failed: Automatic account creation disabled to stop spammers > signing up. > Please contact w...@debian.org and describe what you want to do in the wiki. I think you have sent this mail to the wrong address, as the error says, you should have sent it to w...@debian.org instead. Luckily as a wiki admin I also read the debian-doc list so you reached a wiki admin anyway. Your email is now approved, please reregister the account. Please also read our guides for translators: https://wiki.debian.org/DebianWiki/EditorGuide#Translations https://www.debian.org/international/chinese/ https://www.debian.org/devel/website/translating -- bye, pabs https://wiki.debian.org/PaulWise signature.asc Description: This is a digitally signed message part
How do I push a translation to the official Debian documentation?
Hello, community members.I've been learning about Debian's WiKi, and I've translated the chapter “Booting a UEFI machine normally“ in the “UEFI“ entry.How can I push the translation to the official WiKi? Original article, https://wiki.debian.org/UEFI#Booting_a_UEFI_machine_normallyTranslation, https://my.oschina.net/chipo/blog/8559560 I tried to register an account with WiKi and it tells me that I cannot register automatically. Account creation failed: Automatic account creation disabled to stop spammers signing up. Please contact w...@debian.org and describe what you want to do in the wiki.Please contact us in English, otherwise we will have to pass your message to online translation services. Or, how do I apply to join the Debian community's documentation SIG? Translated with www.DeepL.com/Translator (free version)
Re: help with doc-debian package
Hi, On Fri, Feb 17, 2023 at 01:48:42PM -0600, jathan wrote: > On 17/02/2023 00:57, Joost van Baal-Ilić wrote: > > On Thu, Feb 16, 2023 at 11:58:48AM -0600, jathan wrote: > > > On 14/02/2023 23:11, Joost van Baal-Ilić wrote: > > > > On Tue, Feb 14, 2023 at 07:38:39PM -0700, Sean Whitton wrote: > > > > > On Tue 14 Feb 2023 at 02:32PM +01, Joost van Baal-Ilić wrote: > > > > > > > > > > > I believe Sean didn't get to it yet. Maybe the two of you can > > > > > > coordinate? > > > > > > > > > > I have a bit of a backlog. I'll have to withdraw my offer of help > > > > > for now. My apologies. > > > > > > > > Fair enough, thanks anyway. > > > > > > > > Jathan: I've heard there's still a little bit of time to get new > > > > package releases shipped with bookworm... > > > > > > > Thanks a lot for your last answers Joost! Do I need to update the package > > > https://salsa.debian.org/ddp-team/doc-debian or to interface with the > > > infrastructure of doc-debian in someway? > > > > First thing would be to prepare a new release, possibly from what's now in > > git, and upload it. > > I thought the team were needing some infrastructure administration help. So > it is needed to prepare a new release doing Debian Packaging of doc-deian? Yes, a new release, and ideally long term maintainership of the package. Sorry for being unclear in my initial request for help. Bye, Joost
Re: help with doc-debian package
On 17/02/2023 00:57, Joost van Baal-Ilić wrote: Hi, On Thu, Feb 16, 2023 at 11:58:48AM -0600, jathan wrote: On 14/02/2023 23:11, Joost van Baal-Ilić wrote: On Tue, Feb 14, 2023 at 07:38:39PM -0700, Sean Whitton wrote: On Tue 14 Feb 2023 at 02:32PM +01, Joost van Baal-Ilić wrote: I believe Sean didn't get to it yet. Maybe the two of you can coordinate? I have a bit of a backlog. I'll have to withdraw my offer of help for now. My apologies. Fair enough, thanks anyway. Jathan: I've heard there's still a little bit of time to get new package releases shipped with bookworm... Bye, Joost Thanks a lot for your last answers Joost! Do I need to update the package https://salsa.debian.org/ddp-team/doc-debian or to interface with the infrastructure of doc-debian in someway? First thing would be to prepare a new release, possibly from what's now in git, and upload it. HTH, Bye, Joost I thought the team were needing some infrastructure administration help. So it is needed to prepare a new release doing Debian Packaging of doc-deian? Regards Jathan -- ⢀⣴⠾⠻⢶⣦⠀ ⣾⠁⢠⠒⠀⣿⡁ Jonathan Bustillos ⢿⡄⠘⠷⠚⠋⠀ Debian Developer ⠈⠳⣄⠀ https://wiki.debian.org/jathan OpenPGP_signature Description: OpenPGP digital signature
Re: help with doc-debian package
Hi, On Thu, Feb 16, 2023 at 11:58:48AM -0600, jathan wrote: > On 14/02/2023 23:11, Joost van Baal-Ilić wrote: > > On Tue, Feb 14, 2023 at 07:38:39PM -0700, Sean Whitton wrote: > > > On Tue 14 Feb 2023 at 02:32PM +01, Joost van Baal-Ilić wrote: > > > > > > > I believe Sean didn't get to it yet. Maybe the two of you can > > > > coordinate? > > > > > > I have a bit of a backlog. I'll have to withdraw my offer of help for > > > now. My apologies. > > > > Fair enough, thanks anyway. > > > > Jathan: I've heard there's still a little bit of time to get new package > > releases shipped with bookworm... > > > > Bye, > > > > Joost > > > Thanks a lot for your last answers Joost! Do I need to update the package > https://salsa.debian.org/ddp-team/doc-debian or to interface with the > infrastructure of doc-debian in someway? First thing would be to prepare a new release, possibly from what's now in git, and upload it. HTH, Bye, Joost
Re: help with doc-debian package
On 14/02/2023 23:11, Joost van Baal-Ilić wrote: Hi, On Tue, Feb 14, 2023 at 07:38:39PM -0700, Sean Whitton wrote: On Tue 14 Feb 2023 at 02:32PM +01, Joost van Baal-Ilić wrote: I believe Sean didn't get to it yet. Maybe the two of you can coordinate? I have a bit of a backlog. I'll have to withdraw my offer of help for now. My apologies. Fair enough, thanks anyway. Jathan: I've heard there's still a little bit of time to get new package releases shipped with bookworm... Bye, Joost Thanks a lot for your last answers Joost! Do I need to update the package https://salsa.debian.org/ddp-team/doc-debian or to interface with the infrastructure of doc-debian in someway? Regards Jathan -- ⢀⣴⠾⠻⢶⣦⠀ ⣾⠁⢠⠒⠀⣿⡁ Jonathan Bustillos ⢿⡄⠘⠷⠚⠋⠀ Debian Developer ⠈⠳⣄⠀ https://wiki.debian.org/jathan OpenPGP_signature Description: OpenPGP digital signature
Re: help with doc-debian package
Hi, On Tue, Feb 14, 2023 at 07:38:39PM -0700, Sean Whitton wrote: > On Tue 14 Feb 2023 at 02:32PM +01, Joost van Baal-Ilić wrote: > > > I believe Sean didn't get to it yet. Maybe the two of you can coordinate? > > I have a bit of a backlog. I'll have to withdraw my offer of help for > now. My apologies. Fair enough, thanks anyway. Jathan: I've heard there's still a little bit of time to get new package releases shipped with bookworm... Bye, Joost
Re: help with doc-debian package
Hello, On Tue 14 Feb 2023 at 02:32PM +01, Joost van Baal-Ilić wrote: > I believe Sean didn't get to it yet. Maybe the two of you can coordinate? I have a bit of a backlog. I'll have to withdraw my offer of help for now. My apologies. -- Sean Whitton signature.asc Description: PGP signature
Re: help with doc-debian package
Hi Jathan, Sorry, I only now see your reply... Thanks a lot for your offer to help! On Thu, Feb 02, 2023 at 06:42:18PM +0100, Joost van Baal-Ilić wrote: > Hi Sean, > > On Thu, Feb 02, 2023 at 09:45:15AM -0700, Sean Whitton wrote: > > On Wed 01 Feb 2023 at 08:38PM +01, Joost van Baal-Ilić wrote: > > > > > > FWIW: our beloved doc-debian [1] package, which ships stuff like > > > /usr/share/doc/debian/constitution.txt.gz and > > > /usr/share/doc/debian/social-contract.txt.gz is another one of those old > > > and > > > strange (by-hand stuff @ ftp-master, e.g.) packages in need of some extra > > > care. > > > I don't think I have time to do the necessary updates in time for the > > > freeze... > > > > > > The work needed consists of interfacing with our infrastructure, no > > > coding or > > > text drafting necessary. > > > > I can adopt it if you would like. Let me know. > > Sure! On Wed, 1 Feb 2023 14:45:38 -0600, Jathan wrote at debian-proj...@lists.debian.org: > If I have the necessary skills to interface with the infrastructure of > doc-debian, maybe I can help in some manual tasks. Tell me what is needed > please What would be needed is another upload of the doc-debian package, with fresh content. If it's too late for bookworm now, we might be able to get into the first point-release. We currently ship e.g. an out of date copy of the DFSG. Package git repo is currently at https://salsa.debian.org/groups/ddp-team . I believe Sean didn't get to it yet. Maybe the two of you can coordinate? Bye, Joost
Re: help with doc-debian package
Hi Osamu e.a., On Sun, Feb 05, 2023 at 11:37:50AM +0900, Osamu Aoki wrote: > On Thu, 2023-02-02 at 09:45 -0700, Sean Whitton wrote: > > On Wed 01 Feb 2023 at 08:38PM +01, Joost van Baal-Ilić wrote: > > > > > > FWIW: our beloved doc-debian [1] package, which ships stuff like > > > /usr/share/doc/debian/constitution.txt.gz and > > > /usr/share/doc/debian/social-contract.txt.gz is another one of those old > > > and > > > strange (by-hand stuff @ ftp-master, e.g.) packages in need of some extra > > > care. > > > I don't think I have time to do the necessary updates in time for the > > > freeze... > > > > > > The work needed consists of interfacing with our infrastructure, no coding > > > or text drafting necessary. > > > > I can adopt it if you would like. Let me know. > > If I understand correctly, we copy webwml source and create source for this > deb > package manually in advance. In a oversimplified sense: > > source of www.debian.org --> transform to create deb source. --> deb > > What is better is create a source deb package as the pristine source and > generate corresponding www.debian.org pages from binary deb package content > files with cron script on www-master.d.o like debian-policy etc. Then > updating > is simpler. > > deb source package --> deb binary packages --> www.debian.org > > Of course, this needs to be agreed by the party updating the constitution in > advance. FWIW; I completely agree :) Thanks! Bye, Joost
Re: help with doc-debian package
Hi, Thanks Sean. Let me make some comment. On Thu, 2023-02-02 at 09:45 -0700, Sean Whitton wrote: > Hello, > > On Wed 01 Feb 2023 at 08:38PM +01, Joost van Baal-Ilić wrote: > > > Hiya, > > > > FWIW: our beloved doc-debian [1] package, which ships stuff like > > /usr/share/doc/debian/constitution.txt.gz and > > /usr/share/doc/debian/social-contract.txt.gz is another one of those old and > > strange (by-hand stuff @ ftp-master, e.g.) packages in need of some extra > > care. > > I don't think I have time to do the necessary updates in time for the > > freeze... > > > > The work needed consists of interfacing with our infrastructure, no coding > > or text drafting necessary. > > I can adopt it if you would like. Let me know. If I understand correctly, we copy webwml source and create source for this deb package manually in advance. In a oversimplified sense: source of www.debian.org --> transform to create deb source. --> deb What is better is create a source deb package as the pristine source and generate corresponding www.debian.org pages from binary deb package content files with cron script on www-master.d.o like debian-policy etc. Then updating is simpler. deb source package --> deb binary packages --> www.debian.org Of course, this needs to be agreed by the party updating the constitution in advance. Just my thought. Osamu
Re: help with doc-debian package
Hi Sean, On Thu, Feb 02, 2023 at 09:45:15AM -0700, Sean Whitton wrote: > On Wed 01 Feb 2023 at 08:38PM +01, Joost van Baal-Ilić wrote: > > > > FWIW: our beloved doc-debian [1] package, which ships stuff like > > /usr/share/doc/debian/constitution.txt.gz and > > /usr/share/doc/debian/social-contract.txt.gz is another one of those old and > > strange (by-hand stuff @ ftp-master, e.g.) packages in need of some extra > > care. > > I don't think I have time to do the necessary updates in time for the > > freeze... > > > > The work needed consists of interfacing with our infrastructure, no coding > > or > > text drafting necessary. > > I can adopt it if you would like. Let me know. Sure! Thanks, Bye, Joost
Re: help with doc-debian package
Hello, On Wed 01 Feb 2023 at 08:38PM +01, Joost van Baal-Ilić wrote: > Hiya, > > FWIW: our beloved doc-debian [1] package, which ships stuff like > /usr/share/doc/debian/constitution.txt.gz and > /usr/share/doc/debian/social-contract.txt.gz is another one of those old and > strange (by-hand stuff @ ftp-master, e.g.) packages in need of some extra > care. > I don't think I have time to do the necessary updates in time for the > freeze... > > The work needed consists of interfacing with our infrastructure, no coding or > text drafting necessary. I can adopt it if you would like. Let me know. -- Sean Whitton signature.asc Description: PGP signature
help with doc-debian package
Hiya, FWIW: our beloved doc-debian [1] package, which ships stuff like /usr/share/doc/debian/constitution.txt.gz and /usr/share/doc/debian/social-contract.txt.gz is another one of those old and strange (by-hand stuff @ ftp-master, e.g.) packages in need of some extra care. I don't think I have time to do the necessary updates in time for the freeze... The work needed consists of interfacing with our infrastructure, no coding or text drafting necessary. Bye, Joost [1] https://salsa.debian.org/ddp-team/doc-debian .
Bug#935744: marked as done (RFC Debian Buster Release notes documentation : Power-saving regulations)
Your message dated Sun, 29 Jan 2023 21:15:21 +0100 with message-id and subject line buster is EOL for a while; closing release-notes bugs has caused the Debian Bug report #935744, regarding RFC Debian Buster Release notes documentation : Power-saving regulations to be marked as done. This means that you claim that the problem has been dealt with. If this is not the case it is now your responsibility to reopen the Bug report if necessary, and/or fix the problem forthwith. (NB: If you are a system administrator and have no idea what this message is talking about, this may indicate a serious mail system misconfiguration somewhere. Please contact ow...@bugs.debian.org immediately.) -- 935744: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=935744 Debian Bug Tracking System Contact ow...@bugs.debian.org with problems --- Begin Message --- Package: release-notes Hi Rémi, Thanks for your report. On 30-07-2019 15:10, Rémi Rouaud wrote: > Hi, > > Sorry for my bad english, and sorry I'm not sysadmin. > > I migrated from Debian 9 to 10 applying excellent documentation : > https://www.debian.org/releases/stable/amd64/release-notes/ch-upgrading.fr.html > > All worked well. > > The machine is a sftp server. And to be user-friendly Gnome graphic > environement runs on this server. > > And my server entered in deep suspend power save mode few minutes later... > > According to this bug report : > https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=893964#22 > "It's 20 minutes, and is a result of the defaults in > gnome-settings-daemon 3.28 changing to comply with European and American > power-saving > regulations." > > So If we migrate a debian server with gnome to Buster. The login screen > will suspend the server 20 minutes later the migration. > What a joke ! > > The solution consists in editing /etc/gdm3/greeter.dconf-defaults to > come back to 'blank' screen. > > After the sysadmin can enforce refering to : > https://manpages.debian.org/jessie/systemd/systemd-sleep.conf.5.en.html > https://wiki.debian.org/Suspend > > I suggest the release notes documentation should point this small but > very critical change. > > Best regards, > Rémi Rouaud > Next time, it's better to file a bug report (as I have done now), as unfortunately, e-mail have a tendency to sometimes get lost. Does anybody have a proposal for some text? Paul signature.asc Description: OpenPGP digital signature --- End Message --- --- Begin Message --- Dear bug submitter, Thanks for taking the time to file bugs. However, the bug you reported was aimed at buster (or hasn't seen activity after the last queries). buster is EOL for a while now and we're preparing for the release of bookworm. Hence, I'm closing these bugs as no longer valid or actionable. Paul OpenPGP_signature Description: OpenPGP digital signature --- End Message ---
Documentation about Debian Packaging - Translation
Hello, I took a time frame to work put some more parts in the documentation. I also looked for a better translation process then described before. I found a description how to use OmegaT to translate documentation also in LaTeX. I did some promising tests. OmegaT is also available as a Debian Package. It can handle the file to translate and the translated file in a better way, I think. For that there is no need to prepare soeziell (PO-) files for translation. We need only shared TM (Translation Memory) Files. Those will then be part of the repo. Are there any reasons not to switch to Omegat? -- Mechtilde Stehmann ## Debian Developer ## PGP encryption welcome ## F0E3 7F3D C87A 4998 2899 39E7 F287 7BBA 141A AD7F
Re: About korean translation of debian history
On Sat, 2022-12-03 at 20:56 +0100, Borden wrote: > 3 Dec 2022, 01:27 by Holger Wansing: > > > Where can I find the latest Korean translator? > > > > In your kitchen, I guess :-p > > > Is there a joke somewhere in there? The latest Korean translator for project-history was sebul. -- bye, pabs https://wiki.debian.org/PaulWise signature.asc Description: This is a digitally signed message part
Re: About korean translation of debian history
3 Dec 2022, 01:27 by hwans...@mailbox.org: > >Where can I find the latest Korean translator? > > In your kitchen, I guess :-p > Is there a joke somewhere in there?
Re: About korean translation of debian history
Am 3. Dezember 2022 00:07:55 MEZ schrieb sebul : >Hello. I read >https://www.debian.org/doc/manuals/project-history/index.ko.html > >Where can I find the latest Korean translator? In your kitchen, I guess :-p Holger -- Sent from /e/ OS on Fairphone3
Re: About korean translation of debian history
On Sat, 2022-12-03 at 08:07 +0900, sebul wrote: > Hello. I read > https://www.debian.org/doc/manuals/project-history/index.ko.html > > Where can I find the latest Korean translator? This is the git repository for that project: https://salsa.debian.org/ddp-team/project-history These files are related to the Korean translation: debian/debian-history.doc-base.ko po4a/add_ko/project-history.add po4a/po/ko.po po4a/po/ko.tex -- bye, pabs https://wiki.debian.org/PaulWise signature.asc Description: This is a digitally signed message part
About korean translation of debian history
Hello. I read https://www.debian.org/doc/manuals/project-history/index.ko.html Where can I find the latest Korean translator? -- https://sebuls.blogspot.kr
I've red Debian i\history
Hi. I like it: https://www.debian.org/doc/manuals/project-history/index.en.html More about me: www.greitas.com/en/debian_history
Re: Is Debian OS FIPS Certified?
Dear Javier, Many thanks for your reply and proper answer. Regards, Milica On Mon, Sep 19, 2022 at 12:28 PM Javier Fernandez-Sanguino wrote: > Dear Milica, > > I believe your question should be best addressed to the debian-security > mailing list, as you might find security experts there, rather than to > this mailing list (debian-doc). Nevertheless, I will try to answer you to > the best of my ability. > > On Mon, 19 Sept 2022 at 11:28, Milica Mijatovic < > milica.mijato...@sbgenomics.com> wrote: > >> Hi, >> >> Is Debian OS FIPS certified? Does it support FIPS Validated Cryptographic >> Modules? >> > > It would be best if you clarified to which specific FIPS certification you > refer to. There are multiple FIPS standards (see > https://csrc.nist.gov/publications/fips). Are you referring to FIPS 140-2 > or 140-3? (Security Requirements for Cryptographic Modules). If this is the > case, the elements to be certified in these standards are specific > cryptographic modules, not the operating system itself. > > For security operating system certifications, the market uses the Common > Criteria standard. This standard has developed a specific "Protection > Profile" for general purpose operating systems. It is worthwhile noting > that Debian GNU/Linux, as an operating system, is not Common Criteria > certified. This is not because the Debian OS does not fulfill the > requirements for certification but, rather, because certification is a > heavy process that requires the engagement of a certification lab and an > entity paying for the whole process. Debian, as a project, has not seen the > need in the past to go through these types of security certifications. > Commercial companies (such as Red Hat, Ubuntu or IBM/SUSE) have undergone > the costly certification process, that is why their operating systems are > listed in the Common Criteria product pages (see > https://www.commoncriteriaportal.org/products/) > > > >> What I noticed is that FIPS mode can be enabled with the tool >> fips-mode-setup >> <https://manpages.debian.org/unstable/crypto-policies/fips-mode-setup.8.en.html>. >> This tool is developed and can be used for other Linux distributions (SUSE, >> Oracle Linux, RedHat, Ubuntu), in case the user wants to enable FIPS mode >> afterwards (not part of OS). Does that mean that Debian can be configured >> to use FIPS Validated Cryptographic Modules? >> > > Debian can be indeed be configured, as other distributions, with FIPS to > enable the cryptographic module self-checks mandated by the Federal > Information Processing Standard (FIPS) 140-2. However, you need to be aware > that the distribution itself has not been tested / certified to be in > compliance with the FIPS 1402- standard. This does not mean that it does > not comply, it just means that no attempts have been done to test/certify > the Debian OS in specific configuration. > > Hope the above information is helpful. > > Javier > > -- This email may contain confidential information. Please take care in the storage and transmission of this information. If you are not this message’s intended recipient, please destroy it and notify the sender. This email is not intended to and does not create any legally binding or enforceable obligation on the part of Seven Bridges in the absence of a fully-executed contract or an express written override of this disclaimer.
Re: Is Debian OS FIPS Certified?
Dear Milica, I believe your question should be best addressed to the debian-security mailing list, as you might find security experts there, rather than to this mailing list (debian-doc). Nevertheless, I will try to answer you to the best of my ability. On Mon, 19 Sept 2022 at 11:28, Milica Mijatovic < milica.mijato...@sbgenomics.com> wrote: > Hi, > > Is Debian OS FIPS certified? Does it support FIPS Validated Cryptographic > Modules? > It would be best if you clarified to which specific FIPS certification you refer to. There are multiple FIPS standards (see https://csrc.nist.gov/publications/fips). Are you referring to FIPS 140-2 or 140-3? (Security Requirements for Cryptographic Modules). If this is the case, the elements to be certified in these standards are specific cryptographic modules, not the operating system itself. For security operating system certifications, the market uses the Common Criteria standard. This standard has developed a specific "Protection Profile" for general purpose operating systems. It is worthwhile noting that Debian GNU/Linux, as an operating system, is not Common Criteria certified. This is not because the Debian OS does not fulfill the requirements for certification but, rather, because certification is a heavy process that requires the engagement of a certification lab and an entity paying for the whole process. Debian, as a project, has not seen the need in the past to go through these types of security certifications. Commercial companies (such as Red Hat, Ubuntu or IBM/SUSE) have undergone the costly certification process, that is why their operating systems are listed in the Common Criteria product pages (see https://www.commoncriteriaportal.org/products/) > What I noticed is that FIPS mode can be enabled with the tool > fips-mode-setup > <https://manpages.debian.org/unstable/crypto-policies/fips-mode-setup.8.en.html>. > This tool is developed and can be used for other Linux distributions (SUSE, > Oracle Linux, RedHat, Ubuntu), in case the user wants to enable FIPS mode > afterwards (not part of OS). Does that mean that Debian can be configured > to use FIPS Validated Cryptographic Modules? > Debian can be indeed be configured, as other distributions, with FIPS to enable the cryptographic module self-checks mandated by the Federal Information Processing Standard (FIPS) 140-2. However, you need to be aware that the distribution itself has not been tested / certified to be in compliance with the FIPS 1402- standard. This does not mean that it does not comply, it just means that no attempts have been done to test/certify the Debian OS in specific configuration. Hope the above information is helpful. Javier
Is Debian OS FIPS Certified?
Hi, Is Debian OS FIPS certified? Does it support FIPS Validated Cryptographic Modules? What I noticed is that FIPS mode can be enabled with the tool fips-mode-setup <https://manpages.debian.org/unstable/crypto-policies/fips-mode-setup.8.en.html>. This tool is developed and can be used for other Linux distributions (SUSE, Oracle Linux, RedHat, Ubuntu), in case the user wants to enable FIPS mode afterwards (not part of OS). Does that mean that Debian can be configured to use FIPS Validated Cryptographic Modules? Thanks in advance. Regards, -- Milica Mijatović Team Lead, Security Engineering Seven Bridges Genomics https://www.sbgenomics.com/ -- This email may contain confidential information. Please take care in the storage and transmission of this information. If you are not this message’s intended recipient, please destroy it and notify the sender. This email is not intended to and does not create any legally binding or enforceable obligation on the part of Seven Bridges in the absence of a fully-executed contract or an express written override of this disclaimer.
Re: Where is debian-installer document repository ?
Hi, d-i docs are maintained by d-i folks. Read this page first: https://www.debian.org/devel/debian-installer/index.en.html Then follow links to read: * development version (testing) https://www.debian.org/releases/testing/installmanual * Debian Installation Guide — Development version https://d-i.debian.org/manual/ * Git repo on salsa https://salsa.debian.org/installer-team/installation-guide/ Regards, Osamu > -Original Message- > From: sebul > To: Debian Documentation List , debian-www > > Subject: Re: Where is debian-installer document repository ? > Date: Sun, 24 Jul 2022 13:48:36 +0900 > > Hello. > > > 2022년 7월 24일 (일) 오후 12:47, sebul 님이 작성: > > > > Hello. I found a typo at > > https://www.debian.org/releases/stable/amd64/ch06s04.ko.html > > but I can't find this string in the directory > > https://salsa.debian.org/webmaster-team/webwml/-/tree/master/korean > > > > Where can I find it? and how to find it ? > > https://salsa.debian.org/installer-team/installation-guide/-/raw/master/po/ko/using-d-i.po >
Re: Where is debian-installer document repository ?
Hello. 2022년 7월 24일 (일) 오후 12:47, sebul 님이 작성: > > Hello. I found a typo at > https://www.debian.org/releases/stable/amd64/ch06s04.ko.html > but I can't find this string in the directory > https://salsa.debian.org/webmaster-team/webwml/-/tree/master/korean > > Where can I find it? and how to find it ? https://salsa.debian.org/installer-team/installation-guide/-/raw/master/po/ko/using-d-i.po
Where is debian-installer document repository ?
Hello. I found a typo at https://www.debian.org/releases/stable/amd64/ch06s04.ko.html but I can't find this string in the directory https://salsa.debian.org/webmaster-team/webwml/-/tree/master/korean Where can I find it? and how to find it ?
Re: Bullseye release date in Debian history
Hi, Joost van Baal-Ilić wrote (Fri, 27 May 2022 10:05:11 +0200): > Hi sebul, > > On Fri, May 27, 2022 at 04:19:52PM +0900, sebul wrote: > > > > https://salsa.debian.org/ddp-team/project-history/-/edit/master/project-history.en.dbk > > says at Line 490 > > > > Debian 11 Bullseye (no release date yet): named for > > Woody's wooden toyhorse that appeared in Toy Story 2. > > > > > > > > At Line 1746 > > The 11.x Releases > > > > Debian 11.0 (Bullseye) was released August 14th, 2021. > > > > > > Please update master/project-history.en.dbk file. > > Done in efc9d92..3a1adfa. Thanks! Probably we should also add some highlights for the Bullseye release, as we have for the other releases too, and also include a pointer to the next stable release name. Proposal attached. Holger -- Holger Wansing PGP-Fingerprint: 496A C6E8 1442 4B34 8508 3529 59F1 87CA 156E B076 diff --git a/project-history.en.dbk b/project-history.en.dbk index a963101..8218c95 100644 --- a/project-history.en.dbk +++ b/project-history.en.dbk @@ -484,20 +484,32 @@ pet dog, received as Christmas present in the end of Toy Story. With this release Debian for the first time included a mandatory access control framework enabled per default (AppArmor). It was also the first Debian release to ship with Rust based programs such as Firefox, ripgrep, fd, exa, etc. and a significant number of Rust based libraries (more than 450). Debian 11 Bullseye (August 14th, 2021): named for Woody's wooden toyhorse that appeared in Toy Story 2. + + +Some major improvements in this release include: +Driver-less printing and scanning, kernel support for exFAT, improved support +for alternative init systems. + + + +Debian 12 Bookworm (no release date yet): named for +the green toy worm with a built-in flashlight who wears glasses (from Toy +Story 3). + A Detailed History The 0.x Releases Debian was begun in August 1993 by Ian Murdock, then an undergraduate at Purdue University. Debian was sponsored by the GNU Project of http://www.fsf.org/";>The Free Software Foundation, the organization started by Richard Stallman and associated with the General Public License (GPL), for one year -- from November 1994 to November 1995.
Re: Bullseye release date in Debian history
Hi sebul, On Fri, May 27, 2022 at 04:19:52PM +0900, sebul wrote: > > https://salsa.debian.org/ddp-team/project-history/-/edit/master/project-history.en.dbk > says at Line 490 > > Debian 11 Bullseye (no release date yet): named for > Woody's wooden toyhorse that appeared in Toy Story 2. > > > > At Line 1746 > The 11.x Releases > > Debian 11.0 (Bullseye) was released August 14th, 2021. > > > Please update master/project-history.en.dbk file. Done in efc9d92..3a1adfa. Thanks! Bye, Joost
Bullseye release date in Debian history
Hello. https://salsa.debian.org/ddp-team/project-history/-/edit/master/project-history.en.dbk says at Line 490 Debian 11 Bullseye (no release date yet): named for Woody's wooden toyhorse that appeared in Toy Story 2. At Line 1746 The 11.x Releases Debian 11.0 (Bullseye) was released August 14th, 2021. Please update master/project-history.en.dbk file.
Re: Untranslated part of debian history korean.
2022년 5월 22일 (일) 오후 8:29, Holger Wansing 님이 작성: > > Your translation is not fully up-to-date. > There has been a change in English on that paragraph (only cosmetical): > https://salsa.debian.org/ddp-team/project-history/-/commit/e7746c5d02e5de5a586e36ec999cf5407efc8533 > > Because of that, these two strings are currently fuzzy in Korean (as well as > others). > > I have refreshed all po files and pushed them to GIT. > > Please update your file, if you have time. > > Thank you. I updated the korean translation from the refreshed ko.po file.
Re: Untranslated part of debian history korean.
Hi, sebul wrote (Thu, 19 May 2022 18:19:08 +0900): > But > > https://salsa.debian.org/ddp-team/project-history/-/blob/master/po4a/po/ko.po > > shows korean translation > > "크리스토퍼 H. 로즈는 2016년 9월 17일 골수섬유증 myelofibrosis과 오랜 전투 끝" > "에 세상을 떠났다. 크리스토퍼는 프로젝트 초기부터 데비안 기고자로, 그리고 " > "LaTeX 패키지 Xy-pic, FlexML과 같은 몇 가지 패키지의 업스트림 저자였다.몇 년간" > "의 공백 끝에 프로젝트에 복귀하면서 우리들 중 다수는 하이델베르크의 데브컨프" > "15 때 크리스토퍼를 만나는 기쁨을 누렸다." > > How can I solve it ? Your translation is not fully up-to-date. There has been a change in English on that paragraph (only cosmetical): https://salsa.debian.org/ddp-team/project-history/-/commit/e7746c5d02e5de5a586e36ec999cf5407efc8533 Because of that, these two strings are currently fuzzy in Korean (as well as others). I have refreshed all po files and pushed them to GIT. Please update your file, if you have time. Regards Holger -- Holger Wansing PGP-Fingerprint: 496A C6E8 1442 4B34 8508 3529 59F1 87CA 156E B076
Re: Untranslated part of debian history korean.
Hi Sebul, You might want to report this as a wishlist bug for the debian-history package. Thanks, Bye, Joost On Thu, May 19, 2022 at 06:19:08PM +0900, sebul wrote: > -- Forwarded message - > 보낸사람: sebul > Date: 2022년 5월 18일 (수) 18:54 > Subject: Untranslated part of debian history korean. > To: > > > Hello. > https://www.debian.org/doc/manuals/project-history/detailed.ko.html#2016-09 > shows English > > Kristoffer H. Rose died on September 17th 2016 after a long battle with > myelofibrosis. Kristoffer was a Debian contributor from the very early days > of the project, and the upstream author of several packages, such as the > LaTeX package Xy-pic and FlexML. On his return to the project after several > years' absence, many of us had the pleasure of meeting Kristoffer during > DebConf15 in Heidelberg. > > Kristoffer H. Rose will be missed. > > But > > https://salsa.debian.org/ddp-team/project-history/-/blob/master/po4a/po/ko.po > > shows korean translation > > "크리스토퍼 H. 로즈는 2016년 9월 17일 골수섬유증 myelofibrosis과 오랜 전투 끝" > "에 세상을 떠났다. 크리스토퍼는 프로젝트 초기부터 데비안 기고자로, 그리고 " > "LaTeX 패키지 Xy-pic, FlexML과 같은 몇 가지 패키지의 업스트림 저자였다.몇 년간" > "의 공백 끝에 프로젝트에 복귀하면서 우리들 중 다수는 하이델베르크의 데브컨프" > "15 때 크리스토퍼를 만나는 기쁨을 누렸다." > > How can I solve it ?
Untranslated part of debian history korean.
-- Forwarded message - 보낸사람: sebul Date: 2022년 5월 18일 (수) 18:54 Subject: Untranslated part of debian history korean. To: Hello. https://www.debian.org/doc/manuals/project-history/detailed.ko.html#2016-09 shows English Kristoffer H. Rose died on September 17th 2016 after a long battle with myelofibrosis. Kristoffer was a Debian contributor from the very early days of the project, and the upstream author of several packages, such as the LaTeX package Xy-pic and FlexML. On his return to the project after several years' absence, many of us had the pleasure of meeting Kristoffer during DebConf15 in Heidelberg. Kristoffer H. Rose will be missed. But https://salsa.debian.org/ddp-team/project-history/-/blob/master/po4a/po/ko.po shows korean translation "크리스토퍼 H. 로즈는 2016년 9월 17일 골수섬유증 myelofibrosis과 오랜 전투 끝" "에 세상을 떠났다. 크리스토퍼는 프로젝트 초기부터 데비안 기고자로, 그리고 " "LaTeX 패키지 Xy-pic, FlexML과 같은 몇 가지 패키지의 업스트림 저자였다.몇 년간" "의 공백 끝에 프로젝트에 복귀하면서 우리들 중 다수는 하이델베르크의 데브컨프" "15 때 크리스토퍼를 만나는 기쁨을 누렸다." How can I solve it ?
Re: debian-faq in NEW - or: remove documentation from the archive at all
Hi, FYI: FAQ is published automatically upon uploading the package using cron script which unpack deb package to www.debian.org pages. So I think we can simply drop by hand if we put short static file in package archive mirror containing something like: --- For help, please see: * https://www.debian.org/support * FAQ https://www.debian.org/doc/user-manuals#faq * Debian Installation Guide https://www.debian.org/doc/user-manuals#install * Debian Release Notes https://www.debian.org/doc/user-manuals#relnotes --- > -Original Message- > From: Paul Wise > To: debian-de...@lists.debian.org > Cc: debian-doc@lists.debian.org > Subject: Re: debian-faq in NEW - or: remove documentation from the archive at > all > Date: Tue, 05 Apr 2022 07:54:47 +0800 > > On Mon, 2022-04-04 at 20:52 +0200, Joost van Baal-Ilić wrote: > > > Maybe in a next upload of debian-faq, we could get rid of this by-hand > > stuff. > > Afaik it's only used to get the FAQ content published at > > https://ftp.debian.org/debian/doc/ or http://deb.debian.org/debian/doc/ more specifically http://deb.debian.org/debian/doc/FAQ/ > I think it would be better to send a dak patch turning the manual > processing for debian-faq by-hand into automatic by-hand processing. > There are multiple examples of automatic by-hand processing in dak, > so it should not be very hard to do that. > > > Now that we no longer offer our mirrors via ftp FTP protocol access was used in automatic script but that has been updated to use HTTP protocol now. So missing FTP access is not issue. (This update was done long after announced FTP-shutdown. Somehow, it was working in the mean time. So FTP may had been available long after announcement for some mirror.) > The ftp protocol is irrelevant here, since the documentation is > available on the mirrors irrespective of what protocol is used to > contact them or if the mirror is an offline one available on disk. This is only true for web mirrors: www.debiun.org > > I guess most of the rationale for doing this is gone. > > I think the rationale remains the same; that the mirrors should have a > readable copy of some Debian documentation. If anything I would argue > that that documentation available there should be increased to also > include the Debian install guide and perhaps other documentation. > How about my simpler solution above?
Re: debian-faq in NEW - or: remove documentation from the archive at all
Hi, Am 6. April 2022 06:40:54 MESZ schrieb "Joost van Baal-Ilić" : > >Luckily ftp-masters in the mean time did accept the faq upload. Thanks! Yes, That's great. Many thanks Now I can look into activating the new Portuguese translation on the website (which is one major point in this upload, and indeed the reason, why this had to go through NEW). Regards Holger -- Sent from /e/ OS on Fairphone3
Re: debian-faq in NEW - or: remove documentation from the archive at all
Hi, On Tue, Apr 05, 2022 at 07:54:47AM +0800, Paul Wise wrote: > On Mon, 2022-04-04 at 20:52 +0200, Joost van Baal-Ilić wrote: > > > Maybe in a next upload of debian-faq, we could get rid of this by-hand > > stuff. > > Afaik it's only used to get the FAQ content published at > > https://ftp.debian.org/debian/doc/ > > I think it would be better to send a dak patch turning the manual > processing for debian-faq by-hand into automatic by-hand processing. > There are multiple examples of automatic by-hand processing in dak, > so it should not be very hard to do that. > > > Now that we no longer offer our mirrors via ftp > > The ftp protocol is irrelevant here, since the documentation is > available on the mirrors irrespective of what protocol is used to > contact them or if the mirror is an offline one available on disk. > > > I guess most of the rationale for doing this is gone. > > I think the rationale remains the same; that the mirrors should have a > readable copy of some Debian documentation. If anything I would argue > that that documentation available there should be increased to also > include the Debian install guide and perhaps other documentation. A, indeed, good point. And I agree with all other points (but unfortunately don't have time to write a dak patch). Luckily ftp-masters in the mean time did accept the faq upload. Thanks! Bye, Joost
Re: debian-faq in NEW - or: remove documentation from the archive at all
On Mon, 2022-04-04 at 20:52 +0200, Joost van Baal-Ilić wrote: > Maybe in a next upload of debian-faq, we could get rid of this by-hand stuff. > Afaik it's only used to get the FAQ content published at > https://ftp.debian.org/debian/doc/ I think it would be better to send a dak patch turning the manual processing for debian-faq by-hand into automatic by-hand processing. There are multiple examples of automatic by-hand processing in dak, so it should not be very hard to do that. > Now that we no longer offer our mirrors via ftp The ftp protocol is irrelevant here, since the documentation is available on the mirrors irrespective of what protocol is used to contact them or if the mirror is an offline one available on disk. > I guess most of the rationale for doing this is gone. I think the rationale remains the same; that the mirrors should have a readable copy of some Debian documentation. If anything I would argue that that documentation available there should be increased to also include the Debian install guide and perhaps other documentation. -- bye, pabs https://wiki.debian.org/PaulWise signature.asc Description: This is a digitally signed message part
Re: debian-faq in NEW - or: remove documentation from the archive at all
Hi, Samuel Thibault schreef op maandag 4 april 2022: > the byhand queue is quite different from the new > queue, possibly there are very few ftpmaster who actually know how to > process it. Maybe in a next upload of debian-faq, we could get rid of this by-hand stuff. Afaik it's only used to get the FAQ content published at https://ftp.debian.org/debian/doc/ . Now that we no longer offer our mirrors via ftp, I guess most of the rationale for doing this is gone. Or am I overlooking something here? Bye, Joost
Re: Survey proposal about the usage of money in Debian
Hello,
I have received some private feedback that a few questions were heavily
biased towards technical roles. That bias is certainly real as this is where
I come from and the kind of work that I'd like to fund with Freexian is
mostly technical.
That said the survey would certainly be more useful to Debian if we could
expand it to cover a few non-technical areas.
I left below the 2-3 questions that would benefit from being expanded. I
put in copy a few teams that are currently not listed and that might be
able to suggest new possible use of money in the context of their team.
For the full context, please read
https://lists.debian.org/debian-project/2022/01/msg00024.html. We welcome
your suggestions, either by reply to the mailing list or by MR against
https://salsa.debian.org/freexian-team/misc-drafts/
> Select the teams to which you regularly contribute:
>
> * Release team
> * FTPmasters (archive team)
> * System Admistrators ("DSA")
> * Security team
> * Long Term Support team
> * Quality Assurance ("QA")
> * Debian Installer
> * Debian CD images
> * One (or more) packaging teams
>
>
> For each possible use of Debian's money quoted below, please indicate if
> such a use is a "good idea", "good idea in some specific cases", "bad
> idea" or if it's "totally unacceptable". Select "uncertain" if you can't
> make up your mind.
>
> * Paying for package maintenance (handling bugs, new upstream release,
> improving packaging, etc.)
> * Paying for the initial packaging of software new to Debian.
> * Paying for development of new features/improvements for
> Debian-specific infrastructure (e.g. bugs.debian.org,
> tracker.debian.org, dak, etc.)
> * Paying development of new features/improvements to Debian specific
> software (e.g. dpkg, apt, debhelper, lintian, etc.)
> * Paying development of new tools to experiment new workflows or new
> services
> * Paying technical writers to improve the documentation for new
> contributors
> * Use Debian funds to help the Debian Project Leader (DPL) role in some
> way
> * Pay Debian contributors to complete large scale changes in a
> reasonable time frame
> * Pay specialist porters to support release architectures at risk of
> being dropped from Debian releases due to lack of porters.
>
>
> For each role listed below, please answer the following question: Should
> this Debian role include a stipend or otherwise be funded to allow more
> time to fulfill the obligations of the role? (yes/no/unsure/no opinion)
>
> * Debian Project Leader (DPL)
> * Debian Release Manager
> * In general
> * During the freeze
> * Member of the archive team ("ftpmasters")
> * In general
> * Those who process NEW and RM
> * Member of the Security team
> * Member of the LTS team
> * Member of the Technical Committee
--
Raphaël Hertzog
Re: Failed pipeline for latest | debian-reference | 51c0df57
Hi, On Sat, 2021-12-04 at 21:03 +0100, Beatrice Torracca wrote: > Hi again! > > On 04/12/21 19:01, Beatrice Torracca wrote: > > Hi everyone! Thanks for updating Italian. > > I received the following message from Salsa (I obfuscate my email > > address and name in the text). > > > > On 04/12/21 12:43, Debian GitLab wrote: > > > ✖ Pipeline #323842 has failed! > > > > > > I think it was because I used a URL with "%" signs. If it is for that, I > see Xiao already fixed the problem; so my thanks to Xiao. Yes. Thanks Xiao. In theory, we can have some pre-processor but then I may need to deal with more convoluted case. So let's use readable UTF-8 characters. I think with this round of updates, we are moving toward new reality under systemd instead of sysv-init, UEFI instead of MBR, , git instead of cvs, imap4 instead of pop3, wayland instead of X, bind-mount, ... Osamu
Re: Failed pipeline for latest | debian-reference | 51c0df57
Hi, debian-reference had add CI/CD [1] in salsa, It will do some test and build after every git commit in pipeline. If has any failed, the member of debian-reference in salsa perhaps receive the "Failed pipeline" notifications email. The notifications email[2] can set in salsa by yourself. Notes: If has any % character or & character in the URL, it will break the build. https://www.urldecoder.io/ can help to transfer the URL to UTF-8 online. Please see README.md [3] for detail. The weblate also has this remind[4]. [1] https://salsa.debian.org/debian/debian-reference/-/blob/latest/.gitlab-ci.yml [2] https://salsa.debian.org/-/profile/notifications [3] https://salsa.debian.org/debian/debian-reference/-/blob/latest/README.md#not-use-in-url [4] https://hosted.weblate.org/projects/debian-reference/ 在 2021/12/5 上午4:03, Beatrice Torracca 写道: Hi again! On 04/12/21 19:01, Beatrice Torracca wrote: Hi everyone! I received the following message from Salsa (I obfuscate my email address and name in the text). On 04/12/21 12:43, Debian GitLab wrote: ✖ Pipeline #323842 has failed! I think it was because I used a URL with "%" signs. If it is for that, I see Xiao already fixed the problem; so my thanks to Xiao. You are welcome. Good weekend, beatrice -- 肖盛文 xiao sheng wen Faris Xiao 微信(wechat)：atzlinux 《铜豌豆 Linux》https://www.atzlinux.com 基于 Debian 的 Linux 中文 桌面 操作系统 Debian QA page: https://qa.debian.org/developer.php?login=atzlinux%40sina.com GnuPG Public Key: 0x00186602339240CB OpenPGP_0x00186602339240CB.asc Description: OpenPGP public key OpenPGP_signature Description: OpenPGP digital signature
Re: Failed pipeline for latest | debian-reference | 51c0df57
Hi again! On 04/12/21 19:01, Beatrice Torracca wrote: Hi everyone! I received the following message from Salsa (I obfuscate my email address and name in the text). On 04/12/21 12:43, Debian GitLab wrote: ✖ Pipeline #323842 has failed! I think it was because I used a URL with "%" signs. If it is for that, I see Xiao already fixed the problem; so my thanks to Xiao. Good weekend, beatrice
Re: Failed pipeline for latest | debian-reference | 51c0df57
Hi everyone! I received the following message from Salsa (I obfuscate my email address and name in the text). On 04/12/21 12:43, Debian GitLab wrote: ✖ Pipeline #323842 has failed! Project Debian <https://salsa.debian.org/debian> / debian-reference <https://salsa.debian.org/debian/debian-reference> Branch latest <https://salsa.debian.org/debian/debian-reference/-/commits/latest> Commit 51c0df57 <https://salsa.debian.org/debian/debian-reference/-/commit/51c0df570ee4cfd1a211afd70fae519777de> Partial update of the Italian translation Commit Author [snip my name] Pipeline #323842 <https://salsa.debian.org/debian/debian-reference/-/pipelines/323842> triggered by < my name and salsa ID> had 1 failed build. Failed builds ✖ test html-tests <https://salsa.debian.org/debian/debian-reference/-/jobs/2244716> I have no idea if it is because I tried the command "make test" as suggested in the readme or if my translation has errors. It is the first time that I receive something like this. I can of course revert the commit if there is a problem with my partial Update of the Italian translation. Sadly trying to build locally it is very difficult for me with all the entities declarations missing, and I never managed to make it work properly to see the document build. Thanks, beatrice
Re: Bug#998160: Stop using /usr/share/doc/debian
Joost van Baal-Ilić writes: >> Source: debian-faq > But how about the doc-debian package? That one now installs : > > /usr/share/doc/debian/bug-log-access.txt > /usr/share/doc/debian/bug-*.txt.gz > /usr/share/doc/debian/bug-reporting.txt.gz > /usr/share/doc/debian/constitution.*txt.gz > /usr/share/doc/debian/debian-manifesto.gz > /usr/share/doc/debian/mailing-lists.txt.gz > /usr/share/doc/debian/social-contract.*txt.gz > /usr/share/doc/debian/source-unpack.txt > > If those documents get moved, we can get rid of /usr/share/doc/debian/ > . > > However, I myself am not quite sure if moving these documents is the > right > thing to do. Opinions? No-one replied, so here is my opinion as a user - packages should put their docs in /usr/share/doc/ very few people will expect to look in /usr/share/doc/debian unlesss they installed a 'debian' package - some of those documents look old/out of date - who is the intended user of versions of files older than the current one? these should be on the website or mail-archive.com only - not sure the ones starting 'bug-' are useful - why so many and isnt the same info in 'man bts'? - source-unpack.txt doesnt seem to belong with the others, and shouldnt it be merged with the man-page of dpkg-source?
Re: Bug#998160: Stop using /usr/share/doc/debian
Hi, On Sun, 2021-10-31 at 11:03 +0100, Joost van Baal-Ilić wrote: > On Sun, Oct 31, 2021 at 03:08:42PM +0900, Osamu Aoki wrote: > > Source: debian-faq > > Version: 10.1 > > Severity: minor > > > > When DDP was started, those people had big plan. But in reality, scope > > has been scaled back. > > > > Since there is no big pile of Debian document and most (Policy, > > DevRef,...) now uses their own doc directory, I think it's about time > > for FAQ to be in line with others. > > > > This should help people to find this document easily since doc-base > > support is scant and rarely used by newbies. > > I agree. > > But how about the doc-debian package? That one now installs : > > /usr/share/doc/debian/bug-log-access.txt > /usr/share/doc/debian/bug-*.txt.gz > /usr/share/doc/debian/bug-reporting.txt.gz > /usr/share/doc/debian/constitution.*txt.gz > /usr/share/doc/debian/debian-manifesto.gz > /usr/share/doc/debian/mailing-lists.txt.gz > /usr/share/doc/debian/social-contract.*txt.gz > /usr/share/doc/debian/source-unpack.txt > > If those documents get moved, we can get rid of /usr/share/doc/debian/ . > > However, I myself am not quite sure if moving these documents is the right > thing to do. Opinions? Good catch. True. I think it is good idea but its worth thinking. If we do this, we need to update debwww cron script. Before then, we should stop using FTP servive in cron script. > url = g...@salsa.debian.org:webmaster-team/cron.git Osamu
Re: Bug#998160: Stop using /usr/share/doc/debian
On Sun, Oct 31, 2021 at 03:08:42PM +0900, Osamu Aoki wrote: > Source: debian-faq > Version: 10.1 > Severity: minor > > When DDP was started, those people had big plan. But in reality, scope > has been scaled back. > > Since there is no big pile of Debian document and most (Policy, > DevRef,...) now uses their own doc directory, I think it's about time > for FAQ to be in line with others. > > This should help people to find this document easily since doc-base > support is scant and rarely used by newbies. I agree. But how about the doc-debian package? That one now installs : /usr/share/doc/debian/bug-log-access.txt /usr/share/doc/debian/bug-*.txt.gz /usr/share/doc/debian/bug-reporting.txt.gz /usr/share/doc/debian/constitution.*txt.gz /usr/share/doc/debian/debian-manifesto.gz /usr/share/doc/debian/mailing-lists.txt.gz /usr/share/doc/debian/social-contract.*txt.gz /usr/share/doc/debian/source-unpack.txt If those documents get moved, we can get rid of /usr/share/doc/debian/ . However, I myself am not quite sure if moving these documents is the right thing to do. Opinions? Bye, Joost
debian-faq: remove obsolete usenet links / Re: Debian FAQ Usenet newsgroup
Package: debian-faq Severity: normal Hi Sebul, On Sun, Oct 10, 2021 at 05:07:34AM +0900, sebul / https://sebuls.blogspot.kr wrote: > Hello. > https://www.debian.org/doc/manuals/debian-faq/support.en.html#s12.2.5 > 12.2.5. Usenet newsgroups > say Linux Online and LinuxJournal > But these links say page not found. > > Where is usenet for debian? These links are obsolete and should be removed. I don't think there's a specific usenet group dedicated to Debian; and I'm not quite sure we should refer to one if such a group would exist. Thanks for bringing this up. (Now reporting this in our Bugtracking System; Patches welcome! :-) Bye, Joost
Debian FAQ Usenet newsgroup
Hello. https://www.debian.org/doc/manuals/debian-faq/support.en.html#s12.2.5 12.2.5. Usenet newsgroups say Linux Online and LinuxJournal But these links say page not found. Where is usenet for debian? -- https://sebuls.blogspot.kr
Re: debian-faq korean translation
Hi sebul, sebul wrote (Thu, 7 Oct 2021 18:53:47 +0900): > I added ko at Makefile to add a korean translation. > I run make updatepo. > I edited *.po files in the ko/ directory. > I don't know why other files changed. > Help me please. Hmm, the changes to the en and debian directory are from commits, which happened in December of last year already, like: - commit 70398b06f25701a61cfe886aca0429bcb663db96 Author: Dr. Tobias Quathamer Date: Mon Dec 28 21:47:17 2020 +0100 More preparations for the next upload commit bcfde0383f044aecc000ae5dda29ddc1bf267927 Author: Dr. Tobias Quathamer Date: Mon Dec 28 21:37:40 2020 +0100 Update Standards-Version to 4.5.1, no changes needed commit 816be4d185aa1028b17f510e9a53bb7163ab758e Author: Dr. Tobias Quathamer Date: Mon Dec 28 21:36:48 2020 +0100 Use debhelper v13 - Don't know, what happened, so that you got them into your merge request... Probably some bad workflow with branch/creation of merge request. To get that solved, I would propose the following: Commit your lastest changings (if you have any) to the merge request, as you already did the last days. Then we could cherry-pick the Korean po files from the MR and get them committed into the master branch, and close the MR. >From that point, you could use your po files from master branch, for l10n >review and more translation work. Holger -- Holger Wansing PGP-Fingerprint: 496A C6E8 1442 4B34 8508 3529 59F1 87CA 156E B076
Re: debian-faq korean translation
Hello. joostvb 2021년 10월 7일 (목) 오후 2:15, Joost van Baal-Ilić 님이 작성: > > Hi Sebul, > > Wow! That's an impressive amount of work, thanks for that! > > The translation is not complete yet, did I see that correctly? (Hrm... maybe > it is complete enough to ship it anyway, improvements can also come after the > first public release of this translation.) > Now, my translation is not complete. But, I will improve. > And I saw you also changed Makefile and some of the debian/* files. Could > you tell me why you did that, or describe it in the commit messages? > I added ko at Makefile to add a korean translation. I run make updatepo. I edited *.po files in the ko/ directory. I don't know why other files changed. Help me please. > And yes, it would be very nice if another member of debian-l10n-korean > could review your nice work, so that I can merge it.Hello. joostvb > Sure. I mailed debian-l10n-korean. Thank you.
Re: debian-faq korean translation
Hi Sebul, Wow! That's an impressive amount of work, thanks for that! The translation is not complete yet, did I see that correctly? (Hrm... maybe it is complete enough to ship it anyway, improvements can also come after the first public release of this translation.) And I saw you also changed Makefile and some of the debian/* files. Could you tell me why you did that, or describe it in the commit messages? And yes, it would be very nice if another member of debian-l10n-korean could review your nice work, so that I can merge it. Thanks again for your work! Bye, Joost On Thu, Oct 07, 2021 at 08:30:24AM +0900, sebul wrote: > Hello. I translate debian-faq into korean. Review please. > > 안녕하세요. debian-faq 한국어 번역 검토 요청합니다. > 여러분의 도움말 참고하여 보완하려 합니다. > > https://salsa.debian.org/ddp-team/debian-faq/-/merge_requests/3
debian-faq korean translation
Hello. I translate debian-faq into korean. Review please. 안녕하세요. debian-faq 한국어 번역 검토 요청합니다. 여러분의 도움말 참고하여 보완하려 합니다. https://salsa.debian.org/ddp-team/debian-faq/-/merge_requests/3
