Bug#932957: Please migrate Release Notes to reStructuredText
Hi, Paul Gevers wrote (Wed, 14 Jun 2023 21:19:00 +0200): > Also, on the topic of arch-specific builds, I not convinced it's worth a > lot of effort. The amount of arch specific pieces is rather limited, so > I wouldn't mind if we drop that altogether. Currently, we don't do a > great service to people that need to support multiple architectures, > because they need to *search* for the delta's, so I wouldn't be > surprised if it is even better if we drop it. >From the technical side, I managed to get the arch-specific builds done in the meantime basically; so no problem anymore there - theoretically. On the other side, I also thought about the arch-specific differences, and given they are only rather small, my assumption was, that it's maybe not worth it to differentiate between archs, when it comes to filtering out content of r-n depending on the architecture. But even if we leave that point out, there are some arch-dependent links like http://mirrors.kernel.org/debian/dists/bookworm/main/binary-amd64/... in chapter 4.3.1 https://www.debian.org/releases/stable/amd64/release-notes/ch-upgrading.en.html#network So, we still need to build the release-notes differentiated by archs (based on the current content). However, that does not mean, we could not change our base rules, so that filtering out chapters based on architecture is no longer used. I would vote for this solution, yes. Holger -- Holger Wansing PGP-Fingerprint: 496A C6E8 1442 4B34 8508 3529 59F1 87CA 156E B076
Bug#932957: Please migrate Release Notes to reStructuredText
Hi, On 20-05-2023 23:26, Holger Wansing wrote: And the last point is the integration into the debhelper tools: I don't know if it is required, to have the release-notes fit for building as a whole package with sbuild or debuild or similar. Salsa tries to build it via CI at every push, but currently fails. It's possible I've misunderstood, but would be the goals here to be to get the release-notes documentation built by CI, and also for it to be distributed as a Debian package itself? (someone who knows more may correct me, but I think it would be great to have the package available for install using apt in addition to the website) That was my first thought as well, yes. At the price this may have been answered already, I think the current release notes are not packages because typically a lot of the relevant changes get updated in the weeks *around* the release. So one would have an outdated release notes. On top of that, most "issues to be aware of while upgrading" won't be so useful if you already upgraded. Having said that, I don't mind we make it a package, we just need to be clear of what the purpose is inside a release. Also, on the topic of arch-specific builds, I not convinced it's worth a lot of effort. The amount of arch specific pieces is rather limited, so I wouldn't mind if we drop that altogether. Currently, we don't do a great service to people that need to support multiple architectures, because they need to *search* for the delta's, so I wouldn't be surprised if it is even better if we drop it. Paul OpenPGP_signature Description: OpenPGP digital signature
Bug#932957: Please migrate Release Notes to reStructuredText
Hi Stuart, Stuart Prescott wrote (Sat, 3 Jun 2023 14:45:46 +1000): > > - The list of archs is hardcoded in the Makefile for now. > > The following might provide you with some useful way of not hard-coding > such information: > > curl -s 'https://api.ftp-master.debian.org/suite/bookworm' > > (pipe that into « jq -r '.architectures[]' » to get just the archs as > plain text) I managed to get a list of all relevant architectures via curl -s 'https://api.ftp-master.debian.org/suite/testing' | jq -r '.architectures[]' | grep -v all | grep -v source > You might want to make that a 'maintainer-run' step rather than is run > occasionally as part of preparing a release, rather than as a build time > step. That is, the maintainer runs that from a machine with internet > access to find the list of archs that should be used; this is then > cached in the repo until it is next refreshed. There is precedent for > this 'maintainer-run' step in various "make dist' mechanisms (from the > autotools world) and how the dh-python packages prepares a cache of > known python modules in the archive for later module→package translation. I created a prepare-release.sh script, which can be used to prepare the release-notes for the next stable. That script creates an archlist file, which holds the relevant archs for the current testing. Thanks for helping me with that! > There has been talk for a while about how we might avoid baking in > internal metadata in packages and there might be more inspiration on how > to do this in other parts of the project: > > https://wiki.debian.org/SuitesAndReposExtension > > (there are already a couple of entries there for the release notes) Shouldn't the above solution be added to that wiki page? (I don't see it there, right?) Holger -- Holger Wansing PGP-Fingerprint: 496A C6E8 1442 4B34 8508 3529 59F1 87CA 156E B076
Bug#932957: Please migrate Release Notes to reStructuredText
Hi Holger Thanks for working on this :) - The list of archs is hardcoded in the Makefile for now. The following might provide you with some useful way of not hard-coding such information: curl -s 'https://api.ftp-master.debian.org/suite/bookworm' (pipe that into « jq -r '.architectures[]' » to get just the archs as plain text) You might want to make that a 'maintainer-run' step rather than is run occasionally as part of preparing a release, rather than as a build time step. That is, the maintainer runs that from a machine with internet access to find the list of archs that should be used; this is then cached in the repo until it is next refreshed. There is precedent for this 'maintainer-run' step in various "make dist' mechanisms (from the autotools world) and how the dh-python packages prepares a cache of known python modules in the archive for later module→package translation. There has been talk for a while about how we might avoid baking in internal metadata in packages and there might be more inspiration on how to do this in other parts of the project: https://wiki.debian.org/SuitesAndReposExtension (there are already a couple of entries there for the release notes) cheers Stuart -- Stuart Prescott http://www.nanonanonano.net/ stu...@nanonanonano.net Debian Developer http://www.debian.org/ stu...@debian.org GPG fingerprint 90E2 D2C1 AD14 6A1B 7EBB 891D BBC1 7EBB 1396 F2F7
Bug#932957: Please migrate Release Notes to reStructuredText
Some status update: I managed to expand the Makefile, to build r-n for different archs for all languages and for formats text+pdf+nopdf+html: https://salsa.debian.org/holgerw/release-notes/-/commits/master?ref_type=heads Open points: - In this version, it builds for amd64+armel+i386+ppc64el only. No problem, to expand this for more archs though. - For now, I have separate conf.py files for the different archs, which I copy in place before starting the builds; needs to be replaced by some sed mechanism. - The list of archs is hardcoded in the Makefile for now. - The target 'make install' is not ready; you can only build with 'make text|make pdf|make nopdf|make html|make all' and get the results in the build dir. Holger -- Holger Wansing PGP-Fingerprint: 496A C6E8 1442 4B34 8508 3529 59F1 87CA 156E B076
Bug#932957: Please migrate Release Notes to reStructuredText
Hi,
James Addison wrote (Mon, 29 May 2023 00:18:36 +0100):
> [[Holger Wansing wrote:]]
> > Yes, filtering the content for the different architectures does not work
> > yet.
>
> Ah, and I said I would help with that :)
>
> Although I don't yet know exactly how it's going to interact with the build
> process, I _think_ that a feature we could use for this is the 'only'
> directive:
>
>
> https://www.sphinx-doc.org/en/master/usage/restructuredtext/directives.html#directive-only
>
> Although this could benefit from more thought, initially I suggest we adopt a
> tag format something like 'arch-{debarch}' to handle this (so the conditional
> clause here would be placed within a '.. only:: arch-i386' block.
>
> >From there, we could pass the corresponding tag on the commandline using the
> '-t' option, I guess in the Makefile:
>
>
> https://salsa.debian.org/holgerw/release-notes/-/blob/a2ba839790573915a80db75405abf8ef9212ac8e/Makefile#L103
I have implemented such things now in
https://salsa.debian.org/holgerw/release-notes/-/commit/0304c87400432e1905d1bb04d39468a632876978
as a first step for arch-depending filtering.
Works so far, if the wanted arch is set in the Makefile (line 175) via the -t
option.
Thanks for your help on this!
Now we just need an infrastructure, to loop over all architectures for build
targets...
Holger
--
Holger Wansing
PGP-Fingerprint: 496A C6E8 1442 4B34 8508 3529 59F1 87CA 156E B076
Bug#932957: Please migrate Release Notes to reStructuredText
Package: release-notes Followup-For: Bug #932957 X-Debbugs-Cc: hwans...@mailbox.org Oops - there were a couple of problems with my most recent message here: * Forgot to cc you on the details, Holger (in short summary: the ReST 'only' directive[1] may be helpful here, and could be used with a '-t ' command-line option to sphinx-build from the Makefile) * I didn't read the documentation! The tags for the 'only' directive must be valid Python identifiers, so 'arch_i386' would work as a tag name, but 'arch-i386' (that I had suggested previously) would not. [1] - https://www.sphinx-doc.org/en/master/usage/restructuredtext/directives.html#including-content-based-on-tags
Bug#932957: Please migrate Release Notes to reStructuredText
Package: release-notes
Followup-For: Bug #932957
> Yes, filtering the content for the different architectures does not work yet.
Ah, and I said I would help with that :)
Although I don't yet know exactly how it's going to interact with the build
process, I _think_ that a feature we could use for this is the 'only'
directive:
https://www.sphinx-doc.org/en/master/usage/restructuredtext/directives.html#directive-only
Although this could benefit from more thought, initially I suggest we adopt a
tag format something like 'arch-{debarch}' to handle this (so the conditional
clause here would be placed within a '.. only:: arch-i386' block.
>From there, we could pass the corresponding tag on the commandline using the
'-t' option, I guess in the Makefile:
https://salsa.debian.org/holgerw/release-notes/-/blob/a2ba839790573915a80db75405abf8ef9212ac8e/Makefile#L103
Bug#932957: Please migrate Release Notes to reStructuredText
Hi, James Addison wrote (Fri, 26 May 2023 13:02:53 +0100): > I noticed one more problem with the output of the ReST release-notes: > > Filtering of architecture-specific sections does not seem to be taking place, > so the 'Supported Architectures'[1] section for AMD64 currently contains the > text: > > The ARCH-TITLE support (known as the Debian architecture amd64) now > requires the “long NOP” instruction. Please refer to Baseline for 64-bit PC > is now i686 for more information. > > (the ARCH-TITLE placeholder is probably a small fixup - the problem I'd like > to draw attention to is the reference to 64-bit PC / amd64 as i686) > > In the Docbook source, there is an 'arch="i386"' annotation[2] on the > section's > XML element, so perhaps that is used to filter the content. Yes, filtering the content for the different architectures does not work yet. That's one open point, where I have requested help for. I have fixed the forgotten ARCH-TITLE placeholder now. Holger -- Holger Wansing PGP-Fingerprint: 496A C6E8 1442 4B34 8508 3529 59F1 87CA 156E B076
Bug#932957: Please migrate Release Notes to reStructuredText
Hi, Stéphane Blondon wrote (Sun, 28 May 2023 13:16:24 +0200): > > > Richard Lewis wrote (Fri, 19 May > > 2023 00:58:26 +0100): > > > > > - are the red hyphens in eg the 'deb...' line near the top of > > > > > > https://people.debian.org/~holgerw/release-notes_sphinx/en/html/issues.html > > > > meant to be red? (maybe it is a syntax error?) > > > > > > > Sphinx uses Pygments to highlight source code. I guess no language is > defined so Sphinx uses a wrong lexer. We should force Sphinx to use > 'SourceListLexer' with: > .. code-block :: sources.list The highlighting feature is great, thanks for pointing this out! However, we cannot use it here in most cases for sources.list entries, since resolving substitutions does not work within such lines :-( like in deb https://deb.debian.org/debian |RELEASENAME| main contrib But in many cases the highlighting gives us a great benefit, so I will merge your MR and adapt the rare cases, where it does not work. Thanks again! Holger -- Holger Wansing PGP-Fingerprint: 496A C6E8 1442 4B34 8508 3529 59F1 87CA 156E B076
Bug#932957: Please migrate Release Notes to reStructuredText
Le dim. 28 mai 2023 à 13:16, Stéphane Blondon a écrit : > Sphinx uses Pygments to highlight source code. I guess no language is defined > so Sphinx uses a wrong lexer. We should force Sphinx to use 'SourceListLexer' > with: > .. code-block :: sources.list I sent a Merge Request on Holger's repository to implement it: https://salsa.debian.org/holgerw/release-notes/-/merge_requests/2
Bug#932957: Please migrate Release Notes to reStructuredText
> > Richard Lewis wrote (Fri, 19 May > 2023 00:58:26 +0100): > > > - are the red hyphens in eg the 'deb...' line near the top of > > > > https://people.debian.org/~holgerw/release-notes_sphinx/en/html/issues.html > > > meant to be red? (maybe it is a syntax error?) > > Sphinx uses Pygments to highlight source code. I guess no language is defined so Sphinx uses a wrong lexer. We should force Sphinx to use 'SourceListLexer' with: .. code-block :: sources.list
Bug#932957: Please migrate Release Notes to reStructuredText
Package: release-notes Followup-For: Bug #932957 X-Debbugs-Cc: hwans...@mailbox.org Hi Holger, I noticed one more problem with the output of the ReST release-notes: Filtering of architecture-specific sections does not seem to be taking place, so the 'Supported Architectures'[1] section for AMD64 currently contains the text: The ARCH-TITLE support (known as the Debian architecture amd64) now requires the “long NOP” instruction. Please refer to Baseline for 64-bit PC is now i686 for more information. (the ARCH-TITLE placeholder is probably a small fixup - the problem I'd like to draw attention to is the reference to 64-bit PC / amd64 as i686) In the Docbook source, there is an 'arch="i386"' annotation[2] on the section's XML element, so perhaps that is used to filter the content. Cheers, James [1] - https://people.debian.org/~holgerw/release-notes_sphinx/en/html/whats-new.html#supported-architectures [2] - https://salsa.debian.org/ddp-team/release-notes/-/blob/698b757e098b7d7ccd7b34b5bb9bda333155fd11/en/whats-new.dbk#L71
Bug#932957: Please migrate Release Notes to reStructuredText
Hi,
James Addison wrote (Tue, 23 May 2023 00:22:16 +0100):
> Followup-For: Bug #932957
> X-Debbugs-Cc: hwans...@mailbox.org
>
> On Mon, 22 May 2023 23:40:46 +0100, James wrote:
> > On Sun, 21 May 2023 10:16:36 +0200, Holger wrote:
> > > There is also a problem using entities (or now called substitutions) in
> > > quoted lines like
> >
> > > deb https://deb.debian.org/debian RELEASENAME main contrib
> >
> > Ok, yep - I understand the problem there now, and have experimented with it
> > a
> > bit locally. Roughly speaking: substitutions aren't possible within literal
> > quote blocks (there is a '::' a couple of lines before the mentioned line,
> > and
> > adding the pipe '|' symbols around the substitution label doesn't make a
> > difference within literal blocks)
>
> It looks like the fix for that is to convert those literal ('::') blocks into
> parsed-literal[1] ('.. parsed-literal::') blocks.
>
> [1] -
> https://docutils.sourceforge.io/docs/ref/rst/directives.html#parsed-literal
Yes, that works! Thanks for this!
I have therefore changed all literal ('::') blocks into parsed-literal
('.. parsed-literal::') blocks.
In output, there seems to be no difference (at least in this document), and
this way it's easier for future editors (no need to distinguish between
two different versions of quoted blocks).
Holger
--
Holger Wansing
PGP-Fingerprint: 496A C6E8 1442 4B34 8508 3529 59F1 87CA 156E B076
Bug#932957: Please migrate Release Notes to reStructuredText
Followup-For: Bug #932957
X-Debbugs-Cc: hwans...@mailbox.org
On Mon, 22 May 2023 23:40:46 +0100, James wrote:
> On Sun, 21 May 2023 10:16:36 +0200, Holger wrote:
> > There is also a problem using entities (or now called substitutions) in
> > quoted lines like
>
> > deb https://deb.debian.org/debian RELEASENAME main contrib
>
> Ok, yep - I understand the problem there now, and have experimented with it a
> bit locally. Roughly speaking: substitutions aren't possible within literal
> quote blocks (there is a '::' a couple of lines before the mentioned line, and
> adding the pipe '|' symbols around the substitution label doesn't make a
> difference within literal blocks)
It looks like the fix for that is to convert those literal ('::') blocks into
parsed-literal[1] ('.. parsed-literal::') blocks.
[1] -
https://docutils.sourceforge.io/docs/ref/rst/directives.html#parsed-literal
Bug#932957: Please migrate Release Notes to reStructuredText
Followup-For: Bug #932957 X-Debbugs-Cc: hwans...@mailbox.org On Sun, 21 May 2023 10:16:36 +0200, Holger wrote: > There is also a problem using entities (or now called substitutions) in > quoted lines like > deb https://deb.debian.org/debian RELEASENAME main contrib Ok, yep - I understand the problem there now, and have experimented with it a bit locally. Roughly speaking: substitutions aren't possible within literal quote blocks (there is a '::' a couple of lines before the mentioned line, and adding the pipe '|' symbols around the substitution label doesn't make a difference within literal blocks) Not sure what to suggest yet as an alternative, though...
Bug#932957: Please migrate Release Notes to reStructuredText
[[ Replying to two mails in one ]] Hi, Holger Wansing wrote (Sat, 20 May 2023 23:26:47 +0200): > James Addison wrote (Fri, 19 May 2023 23:28:55 +0100): > > > Please note the in the URL! > > > I could not get this working with sphinx (if someone knows better, please > > > contact me!) > > > > Could the 'extlinks' feature[1] of Sphinx be helpful to migrate those? > > Yes, thanks for the pointer! I used that now to get the manpage links fixed! > > > (it allows defining URL pattern aliases, so for example :oldreleasenotes: > > could > > map to https://www.debian.org/releases/bullseye/releasenotes and > > :releasenotes: > > could map to https://www.debian.org/releases/bookworm/releasenotes for D12) > > > > Parameters are supported too, and that could be useful for > > package-or-filepath > > refs (re: grep -r '`.*<' source |grep -o '' | sort | uniq -c |sort > > -n) > > The drawback is, it is not as flexible as the entities in docbook. > For example, there is the following URL in this manual in docbook: > > /debian/dists//main/binary-/... > > You see, there are three entites in this URL! > This seems to be not supported by extlinks :-(( I focused a bit too much on the URL front here. There is also a problem using entities (or now called substitutions) in quoted lines like deb https://deb.debian.org/debian RELEASENAME main contrib or # script -t 2>~/upgrade-RELEASENAMEstep.time -a ~/upgrade-RELEASENAMEstep.script These also do not work. That's the biggest blocker in the upgrading chapter IMHO. > > > Beside this, I need help to adapt the buildchain, to get the possibility > > > of > > > building the release-notes for the different architectures. > > > I have no python knowledge, so I will most likely not get this running > > > myself. > > > > I'll try to take a look into that soon to see what I can find out. Do you > > know how the current docbook-based build varies by architecture? > > There are some chapters, which are only visible for specific architectures, > like > in installing.dbk: > > > Cloud installations > > The cloud team publishes > Debian for several popular cloud computing services > including: > > > > Perhaps we can borrow some build scripting from developers-reference and/or > > debian-policy.. but I suppose those don't have per-architecture output. > > I think so, yes. That will be of no help, I fear... > > > > And the last point is the integration into the debhelper tools: I don't > > > know > > > if it is required, to have the release-notes fit for building as a whole > > > package with sbuild or debuild or similar. Salsa tries to build it via CI > > > at every push, but currently fails. > > > > It's possible I've misunderstood, but would be the goals here to be to get > > the release-notes documentation built by CI, and also for it to be > > distributed > > as a Debian package itself? > > > > (someone who knows more may correct me, but I think it would be great to > > have > > the package available for install using apt in addition to the website) > > That was my first thought as well, yes. Hi, Holger Wansing wrote (Sat, 20 May 2023 23:10:59 +0200): > Hi, > > Richard Lewis wrote (Fri, 19 May 2023 > 00:58:26 +0100): > > On Thu, 18 May 2023 22:39:11 +0200 Holger Wansing > > wrote: > > Unfortunately, my first impression is that it the output has quite a > > few issues which make it a lot harder to read than > > the docbook version - which im sure is because it's still only a > > prototype, but thought it might helpful to list the things that jumped > > out at me: > > - It is a lot more cluttered than the docbook version - it feels > > off-putting and dense to read > > - it's all a bit 'blue' - i'd suggest red is more on-brand for debian > > - the "next"/"prev" links at the bottom-right are white on green --- > > I totally missed at first, and found hard to read > > I copied style and font settings from developers-reference, another > document, which has been migrated recently from docbook to sphinx. > So I consider this as a quasi-standard at the moment. > I copied it by intent, to get a consistent look for all manuals generated > with sphinx. > We can work on that later on, as Laura already pointed out there is even > a bugreport for this. > So will ignore this for now here. > > > - i was a bit confused by the "12.1" version number at the bottom of > > every page, and having 'sphinx' reminded me of websites with "hosted > > by geocities" > > The first version I built with sphinx had version displayed > "release-notes 5.0.1" which confused me even more. > Therefore I changed that in the sense of "release-notes version 12 for > Debian release 12". Can still be changed in any way... > > > - are the red hyphens in eg the 'deb...' line near the top of > > https://people.debian.org/~holgerw/release-notes_sphinx/en/html/issues.html > > meant to be red? (maybe it is a syntax
Bug#932957: Please migrate Release Notes to reStructuredText
Hi, James Addison wrote (Fri, 19 May 2023 23:28:55 +0100): > > Please note the in the URL! > > I could not get this working with sphinx (if someone knows better, please > > contact me!) > > Could the 'extlinks' feature[1] of Sphinx be helpful to migrate those? Yes, thanks for the pointer! I used that now to get the manpage links fixed! > (it allows defining URL pattern aliases, so for example :oldreleasenotes: > could > map to https://www.debian.org/releases/bullseye/releasenotes and > :releasenotes: > could map to https://www.debian.org/releases/bookworm/releasenotes for D12) > > Parameters are supported too, and that could be useful for package-or-filepath > refs (re: grep -r '`.*<' source |grep -o '' | sort | uniq -c |sort > -n) The drawback is, it is not as flexible as the entities in docbook. For example, there is the following URL in this manual in docbook: /debian/dists//main/binary-/... You see, there are three entites in this URL! This seems to be not supported by extlinks :-(( > > Beside this, I need help to adapt the buildchain, to get the possibility of > > building the release-notes for the different architectures. > > I have no python knowledge, so I will most likely not get this running > > myself. > > I'll try to take a look into that soon to see what I can find out. Do you > know how the current docbook-based build varies by architecture? There are some chapters, which are only visible for specific architectures, like in installing.dbk: Cloud installations The cloud team publishes Debian for several popular cloud computing services including: > Perhaps we can borrow some build scripting from developers-reference and/or > debian-policy.. but I suppose those don't have per-architecture output. I think so, yes. That will be of no help, I fear... > > And the last point is the integration into the debhelper tools: I don't know > > if it is required, to have the release-notes fit for building as a whole > > package with sbuild or debuild or similar. Salsa tries to build it via CI > > at every push, but currently fails. > > It's possible I've misunderstood, but would be the goals here to be to get > the release-notes documentation built by CI, and also for it to be distributed > as a Debian package itself? > > (someone who knows more may correct me, but I think it would be great to have > the package available for install using apt in addition to the website) That was my first thought as well, yes. Holger -- Holger Wansing PGP-Fingerprint: 496A C6E8 1442 4B34 8508 3529 59F1 87CA 156E B076
Bug#932957: Please migrate Release Notes to reStructuredText
The following message is a courtesy copy of an article that has been posted to gmane.linux.debian.devel.documentation as well. James Addison writes: > (someone who knows more may correct me, but I think it would be great to have > the package available for install using apt in addition to the website) Interesting idea, but who would use it - won't a release-notes package always be a whole release out of date? (and the build-dependencies take a huge amount of disk space for something you only read once a cycle, alhtough maybe sphinx fixes that)
Bug#932957: Please migrate Release Notes to reStructuredText
Followup-For: Bug #932957 X-Debbugs-Cc: hwans...@mailbox.org Hi Holger, > Please note the in the URL! > I could not get this working with sphinx (if someone knows better, please > contact me!) Could the 'extlinks' feature[1] of Sphinx be helpful to migrate those? (it allows defining URL pattern aliases, so for example :oldreleasenotes: could map to https://www.debian.org/releases/bullseye/releasenotes and :releasenotes: could map to https://www.debian.org/releases/bookworm/releasenotes for D12) Parameters are supported too, and that could be useful for package-or-filepath refs (re: grep -r '`.*<' source |grep -o '' | sort | uniq -c |sort -n) > Beside this, I need help to adapt the buildchain, to get the possibility of > building the release-notes for the different architectures. > I have no python knowledge, so I will most likely not get this running myself. I'll try to take a look into that soon to see what I can find out. Do you know how the current docbook-based build varies by architecture? Perhaps we can borrow some build scripting from developers-reference and/or debian-policy.. but I suppose those don't have per-architecture output. > And the last point is the integration into the debhelper tools: I don't know > if it is required, to have the release-notes fit for building as a whole > package with sbuild or debuild or similar. Salsa tries to build it via CI > at every push, but currently fails. It's possible I've misunderstood, but would be the goals here to be to get the release-notes documentation built by CI, and also for it to be distributed as a Debian package itself? (someone who knows more may correct me, but I think it would be great to have the package available for install using apt in addition to the website) Cheers, James [1] - https://www.sphinx-doc.org/en/master/usage/extensions/extlinks.html
Bug#932957: Re Bug 932957 Please migrate Release Notes to reStructuredText
Hi Andrei, On 02-12-2019 00:29, Andrei POPESCU wrote: > As mentioned before, this is something I would be interested to work on, > assuming I find the time for it. Ack. > In any case, if someone else is interested please go for it. > > Regarding branches, wouldn't it make more sense to create a buster > branch and continue work on master? Just asking, I'm fine either way. Of course, that's what I meant. I did that in the mean time and master is now free to start working on this transition to reStructeredText. Paul signature.asc Description: OpenPGP digital signature
Bug#932957: Re Bug 932957 Please migrate Release Notes to reStructuredText
On Du, 01 dec 19, 20:35:35, Paul Gevers wrote: > Hi Andrei, > > On Thu, 25 Jul 2019 22:44:29 +0900 Osamu Aoki wrote: > > Yes. It can be done. I just converted developers-reference and someone > > merged it ti main ;-) > > > > If you follow my commit history, all tools and tricks are there. > > > > https://salsa.debian.org/debian/developers-reference > > > > I will work on build script more to make web page looks better. But > > source conversion was possible though it is non-trivial. > > > > > Ok, I'll have a look at it, though I wouldn't mind if someone is faster > > > ;) > > > > https://salsa.debian.org/debian/developers-reference/blob/1b0940a5c2879a5be3100b0e0f2bee6c5de58bdf/README.rst > > > > This describes general tasks involved. > > > > If someone makes broken PO file by copying some msgstr from random > > msgstr, then conversion doesn't work well and it may be cryptic to > > debug. > > Are you still upto doing this change? I'm not expecting you worked on > this recently, but now is a good time to get this on the rails. Should > we first branch bullseye (bug #932853), make the relatively small fixes > there and then work on that branch or do you have a different proposal? As mentioned before, this is something I would be interested to work on, assuming I find the time for it. In any case, if someone else is interested please go for it. Regarding branches, wouldn't it make more sense to create a buster branch and continue work on master? Just asking, I'm fine either way. Kind regards, Andrei -- http://wiki.debian.org/FAQsFromDebianUser signature.asc Description: PGP signature
Bug#932957: Re Bug 932957 Please migrate Release Notes to reStructuredText
Hi Andrei, On Thu, 25 Jul 2019 22:44:29 +0900 Osamu Aoki wrote: > Yes. It can be done. I just converted developers-reference and someone > merged it ti main ;-) > > If you follow my commit history, all tools and tricks are there. > > https://salsa.debian.org/debian/developers-reference > > I will work on build script more to make web page looks better. But > source conversion was possible though it is non-trivial. > > > Ok, I'll have a look at it, though I wouldn't mind if someone is faster > > ;) > > https://salsa.debian.org/debian/developers-reference/blob/1b0940a5c2879a5be3100b0e0f2bee6c5de58bdf/README.rst > > This describes general tasks involved. > > If someone makes broken PO file by copying some msgstr from random > msgstr, then conversion doesn't work well and it may be cryptic to > debug. Are you still upto doing this change? I'm not expecting you worked on this recently, but now is a good time to get this on the rails. Should we first branch bullseye (bug #932853), make the relatively small fixes there and then work on that branch or do you have a different proposal? Paul signature.asc Description: OpenPGP digital signature
