Bug#850171: Recommend that manpages contain an EXAMPLES section

[gregor herrmann]

On Sat, 03 Nov 2018 14:00:51 -0700, Sean Whitton wrote:

> Hence I am seeking seconds for this patch I've written:
> 
> diff --git a/policy/ch-docs.rst b/policy/ch-docs.rst
> index e990f34..a9b297f 100644
> --- a/policy/ch-docs.rst
> +++ b/policy/ch-docs.rst
> @@ -61,6 +61,12 @@ by a note at the beginning of the manual page or by 
> showing the missing
>  or changed portions in the original language instead of the target
>  language.
> 
> +It is recommended that manual pages contain an EXAMPLES section,
> +containing working syntax that uses the functionality documented by
> +the manual page.  For example, command-line invocations of a utility
> +for some of its standard usages, or an example call to an API
> +function.
> +
>  .. _s12.2:
> 
>  Info documents

No objections from me, just 2 nits:

- The typical .3pm manpage (for perl modules) doesn't contain an
  EXAMPLES section but contains working and copypastable code in the
  SYNOPSIS section. [0]
- I'm not really convinced that a "duty" to patch upstream manpages
  in order to add EXAMPLE sections, which would follow from this
  recommendation, is sustainable or desirable …


Cheers,
gregor


[0] If you're interested in an amendment, maybe:
"It is recommended that manual pages contain examples of working
syntax that uses the functionality documented by the manual page.  For
example, …"

or

"It is recommended that manual pages contain examples of working
syntax, e.g. in an EXAMPLES section, that uses the functionality
documented by the manual page.  For example, …"

-- 
 .''`.  https://info.comodo.priv.at -- Debian Developer https://www.debian.org
 : :' : OpenPGP fingerprint D1E1 316E 93A7 60A8 104D  85FA BB3A 6801 8649 AA06
 `. `'  Member VIBE!AT & SPI Inc. -- Supporter Free Software Foundation Europe
   `-   NP: Billy Joel: Captan Jack


signature.asc
Description: Digital Signature

Bug#824495: debian-policy: Source packages "can" declare relationships

[Russ Allbery]

Santiago Vila  writes:
> On Sat, Nov 03, 2018 at 03:42:20PM -0700, Russ Allbery wrote:

>> In a way, I don't think this goes far enough.  Build-Conflicting with
>> something installed by debhelper would be incredibly painful and would
>> basically require the package be built in a chroot.

> I'm not sure what do you mean by "painful" here. In this case, a
> Build-Conflicts would have told sbuild to uninstall automake during
> the "install build-dependencies stage", which is not painful at all.

I certainly think it is!  I would be extremely upset if trying to build a
package uninstalled automake.

This also makes the package effectively unbuildable outside of a chroot,
which is also quite painful.

I feel pretty strongly here that Build-Conflicts is not a correct solution
to this problem, and therefore I'm not happy about the idea of adding a
Policy rule that would imply that it was.  The problem was that the
package didn't tolerate having automake installed, and fixing *that* was
the correct fix.  But this seems fairly subtle to try to turn into a
general Policy rule.

-- 
Russ Allbery (r...@debian.org)   

Bug#824495: debian-policy: Source packages "can" declare relationships

[Santiago Vila]

On Sat, Nov 03, 2018 at 03:42:20PM -0700, Russ Allbery wrote:

> In a way, I don't think this goes far enough.  Build-Conflicting with
> something installed by debhelper would be incredibly painful and would
> basically require the package be built in a chroot.

I'm not sure what do you mean by "painful" here. In this case, a
Build-Conflicts would have told sbuild to uninstall automake during
the "install build-dependencies stage", which is not painful at all.

The real pain comes from not having a build-conflicts at all (because
in such case there was a FTBFS).

> In this particular case, it also seems unnecessary. [...]

In this case, it was unnecessary, yes. The maintainer solved the
problem by calling automake-1.11 by its versioned name. But as far as
this was not done yet, the package had an undeclared build-conflicts.

Anyway, this was the case that made me think about the language used
in policy. The package (as it was) "required" in an absolute sense not
to have automake installed as much as it "required" to have their
build-dependencies installed. That's why "can" or "may" seemed a
little bit strange for the wording to me.

Maybe the relevant paragraph in policy is this one instead:

  If build-time dependencies are specified, it must be possible to build
  the package and produce working binaries on a system with only
  essential and build-essential packages installed and also those
  required to satisfy the build-time relationships (including any
  implied relationships).

To follow with the previous example, does this paragraph imply that if
you call automake by "automake" and you build-depend on automake-1.11
then you should use a build-conflict?

I don't think so, because the "with only [...]" part suggests the
completely minimal chroot approach to building packages.

Thanks.

Bug#824495: debian-policy: Source packages "can" declare relationships

[Russ Allbery]

Santiago Vila  writes:

> The source package failed to build from source if you had "automake"
> installed in the chroot. At the time, automake was installed by default
> when you installed debhelper.

Ow.

> So: What about "packages should declare Build-Conflicts when the
> build-conflict happens against a very common build-dependency"?
> (Or something like that).

In a way, I don't think this goes far enough.  Build-Conflicting with
something installed by debhelper would be incredibly painful and would
basically require the package be built in a chroot.

In this particular case, it also seems unnecessary.  automake1.11 is
(unless I'm missing something) co-installable with automake, so I think
the root problem here is that the package isn't using it in preference to
automake when both are installed.  This feels like something that should
be fixed in the package, not worked around by adding Build-Conflicts
against an incredibly commonly-installed package.

-- 
Russ Allbery (r...@debian.org)   

Bug#845715: Required targets must not write outside of the source package tree

[Bill Allombert]

On Sat, Nov 03, 2018 at 01:07:49PM -0700, Russ Allbery wrote:
> Sean Whitton  writes:
> 
> > I reformatted and wordsmithed josch's patch, second it myself, and am
> > seeking further seconds.
> 
> > Given that whole archive rebuilds with use sbuild and already catch
> > packages that violate this requirement, making this change would not
> > declare any packages buggy that would not already be considered buggy,
> > so we can make it right away.
> 
> Excellent!  This has been a long-standing issue, and it's great to finally
> get this into Policy.
> 
> One minor wording nit, seconded either way:
> 
> > +Required targets must not attempt to write outside of the unpacked
> > +source package tree. An exception to this rule is the use of
> > +``TMPDIR`` (or ``/tmp`` if that is not set) which is permitted as long
> > +as temporary files are deleted by the end of the target, and not
> > +reused by subsequent execution of the target.  This restriction is
> 
> How about:
> 
> As an exception, required targets may write to the directory specified
> by the ``TMPDIR`` environment variable (or ``/tmp`` if that is not
> set), provided that files created in that directory are deleted before
> the target completes and are not reused by subsequent executions of
> the target.
> 
> This explicitly states that this is an environment variable and makes it
> clear that it refers to a directory.

I may be wrong but I expect that a lot of packages targets leaves stray
files and directory in /tmp (that are created by mktemp but not removed)
but not reused, and also that some of them fail to honor TMPDIR.

Do we have some data about this ?

Cheers,
-- 
Bill. 

Imagine a large red swirl here. 

Bug#824495: debian-policy: Source packages "can" declare relationships

[Santiago Vila]

> > While we are at it, I understand, because it would involve a huge
> > amount of computation to determine, that we can't test every package
> > against every other binary package to discover undeclared
> > build-conflicts.
> 
> Well, indeed.  In fact, this is the reason why I don't see how we could
> introduce a requirement to use Build-Conflicts into Policy.  We would
> not be able to determine whether we were making packages buggy by doing
> that.

Sorry, I forgot some details about the case that prompted me to file
this report:

I was building all the packages in stretch, and to save time and
bandwidth for each build, I installed debhelper in my chroot
(as nearly every package uses it).

The source package failed to build from source if you had "automake"
installed in the chroot. At the time, automake was installed by
default when you installed debhelper.

So it built ok only if you take the ultraorthodox path of having a
completely minimal chroot, but it would fail for anybody who, like me,
also installed debhelper and its default dependencies in the chroot.

What I would like to avoid is maintainers recommending or even
*suggesting* the user to uninstall the conflicting package
as a way to "solve" the problem, as it happened here:

https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=824011

Maybe I was a little bit rude at the time by changing the severity
while discussing, but I would also consider rude that a maintainer
even suggests that this FTBFS problem is user's fault and not a
packaging bug.

So: What about "packages should declare Build-Conflicts when the
build-conflict happens against a very common build-dependency"?
(Or something like that).

If we don't do anything like that, not even a recommendation, an
example, or a typical use-case for build-conflicts, maybe we could
declare that the only acceptable way to build packages is to have a
completely minimal chroot and declare build-conflicts obsolete...

Thanks.

Bug#690750: Broken links in developers-reference as published on the Debian's website

[Laura Arjona Reina]

Hello
Could this be caused by the code of mvhtml() function in cron/parts/7doc
script?

https://salsa.debian.org/webmaster-team/cron/blob/master/parts/7doc

Maybe it works well for links *.html and *.XX.html being XX the language
processing in that time, but maybe it's not prepared for *.YY.html files
being YY a different language than the one being processed each time.

I've had a look at the code but I cannot understand it well, sorry.

Kind regards

El 03/11/18 a las 22:07, Lev Lamberov escribió:
> Hi Holger,
> 
> thanks for your attention to the bug report, but my report was about a
> different issue. Let me explain.
> 
> First, let's take a look at developers-reference as it pubished on the
> Debian's website. Say, in English [web-en]. It incorrectly links to
> translations as index.{fr,de,it,ru,jp}.en.html, such files do not exist.
> Any other translation, say, French [web-fr] links to translations as
> index.{de,it,ru,jp}.fr.html, such files do not exist.
> 
> [web-en] https://www.debian.org/doc/manuals/developers-reference/index.en.html
> 
> [web-fr] https://www.debian.org/doc/manuals/developers-reference/index.fr.html
> 
> Second, let's take a look at developers-reference package. All links
> there are correct, that is in _any_ language links point to
> index.{fr,de,it,ru,jp}.html.
> 
> Third, let's take a look at developers-reference source code. In English
> we currently have as follows:
> 
> 
> If you want to print this reference, you should use the  url="developers-reference.pdf">pdf version.  This page is also
> available in French,  url="index.de.html">German,  url="index.it.html">Italian,  url="index.ru.html">Russian, and  url="index.ja.html">Japanese.
> 
> 
> 
> Again, links are correct and point to index.{fr,de,it,ru,jp}.html. And
> the same holds for any translation.
> 
> Broken links are only in developers-reference published on the Debian's
> website. Since links in the source code and in the developers-reference
> package are correct, then it is the content negotiation problem. Looks
> like the webserver incorrectly rewrites links.
> 
> Let me stress that my report is _not_ about links to English, or links
> in English. It is about _broken_ links in _any_ developers-reference as
> published on the Debian's website. So, my bug report is about
> www.debian.org, not developers-reference. Please, reconsider it and
> reassign #912724 to www.debian.org.
> 
> Regards,
> Lev
> 

-- 
Laura Arjona Reina
https://wiki.debian.org/LauraArjona

Processed: Re: Bug#824495: debian-policy: Source packages "can" declare relationships

[Debian Bug Tracking System]

Processing control commands:

> tag -1 +pending
Bug #824495 [debian-policy] debian-policy: Source packages "can" declare 
relationships
Added tag(s) pending.

-- 
824495: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=824495
Debian Bug Tracking System
Contact ow...@bugs.debian.org with problems

Bug#824495: debian-policy: Source packages "can" declare relationships

[Sean Whitton]

control: tag -1 +pending

Hello Santiago,

On Mon 16 May 2016 at 08:16PM +0200, Santiago Vila wrote:

> Policy 7.7 says: (Bold in "can" is mine)
>
>   Source packages that require certain binary packages to be installed
>   or absent at the time of building the package *can* declare
>   relationships to those binary packages.
>
> I interpret this "can" in the sense that this is the vocabulary that
> the maintainer is allowed to use when writing control files.
>
> To my surprise, however, today a maintainer has quoted this "can" word
> as a rationale for a missing Build-Conflicts not to be a bug of serious
> severity:
>
>   "No _must_ directive here. It is not a Policy violation if you don't
>   use Build-Conflicts."

This maintainer's interpretation matches how I'd understand the quoted
wording from 7.7.

> If my idea that policy is just describing the vocabulary is close to
> reality, I would perhaps suggest something like this:
>
>   The following relationsips are available for source packages to
>   express the fact that they require certain binary packages to be
>   installed or absent at the time of building the package.

I tried implementing something like this wording, but I don't think it
reads any better, when considered as part of the section as a whole.

What I've done instead is replace 'can' with 'may', which is the
standard Policy language to express that things are optional.

> but then it would be nice to state somewhere later that Build-Depends
> and Build-Conflicts are not just "optional" but mandatory when the
> referenced packages are either required to be present or required to
> be absent.
>
>
> While we are at it, I understand, because it would involve a huge
> amount of computation to determine, that we can't test every package
> against every other binary package to discover undeclared
> build-conflicts.

Well, indeed.  In fact, this is the reason why I don't see how we could
introduce a requirement to use Build-Conflicts into Policy.  We would
not be able to determine whether we were making packages buggy by doing
that.

Thus, I'm marking this bug as done with the s/can/may/ change, since I
don't think the normative change is one we can feasibly make.

-- 
Sean Whitton


signature.asc
Description: PGP signature

Bug#833401: debian-policy: virtual packages: dbus-session-bus, default-dbus-session-bus

[Sean Whitton]

control: tag -1 +moreinfo

Dear Simon,

On Thu 04 Aug 2016 at 01:43PM +0100, Simon McVittie wrote:

>> Other options
>> =
> ...
>> * Add a real (non-virtual) empty package dbus-session-bus built by src:dbus,
>>   with Depends: dbus-user-session | dbus-x11 (initially). Other packages
>>   depend on dbus-session-bus.
>>   (Pro: simpler dependency graph. Con: requires NEW queue.)
>
> Another advantage of this option (which it shares with the others that do not
> use a default-d-s-b virtual package) is that it avoids ambiguity if apt
> is configured to see more than one suite (perhaps unstable and testing, or
> testing and stable-security) and the package providing default-d-s-b differs
> between those suites.
>
> If the scheme involving two virtual packages is preferred over this
> option, I would very much appreciate someone who knows about these things
> describing why, because it isn't currently clear to me.

I note that no such binary package exists right now.  Does this issue
remain unresolved?  I also note recent discussion on d-devel.  Kindly
update this bug with the present state of play.

-- 
Sean Whitton


signature.asc
Description: PGP signature

Processed: Re: Bug#833401: debian-policy: virtual packages: dbus-session-bus, default-dbus-session-bus

[Debian Bug Tracking System]

Processing control commands:

> tag -1 +moreinfo
Bug #833401 [debian-policy] debian-policy: virtual packages: dbus-session-bus, 
dbus-default-session-bus
Added tag(s) moreinfo.

-- 
833401: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=833401
Debian Bug Tracking System
Contact ow...@bugs.debian.org with problems

Bug#690750: Broken links in developers-reference as published on the Debian's website

[Lev Lamberov]

Hi Holger,

thanks for your attention to the bug report, but my report was about a
different issue. Let me explain.

First, let's take a look at developers-reference as it pubished on the
Debian's website. Say, in English [web-en]. It incorrectly links to
translations as index.{fr,de,it,ru,jp}.en.html, such files do not exist.
Any other translation, say, French [web-fr] links to translations as
index.{de,it,ru,jp}.fr.html, such files do not exist.

[web-en] https://www.debian.org/doc/manuals/developers-reference/index.en.html

[web-fr] https://www.debian.org/doc/manuals/developers-reference/index.fr.html

Second, let's take a look at developers-reference package. All links
there are correct, that is in _any_ language links point to
index.{fr,de,it,ru,jp}.html.

Third, let's take a look at developers-reference source code. In English
we currently have as follows:


If you want to print this reference, you should use the pdf version.  This page is also
available in French, German, Italian, Russian, and Japanese.



Again, links are correct and point to index.{fr,de,it,ru,jp}.html. And
the same holds for any translation.

Broken links are only in developers-reference published on the Debian's
website. Since links in the source code and in the developers-reference
package are correct, then it is the content negotiation problem. Looks
like the webserver incorrectly rewrites links.

Let me stress that my report is _not_ about links to English, or links
in English. It is about _broken_ links in _any_ developers-reference as
published on the Debian's website. So, my bug report is about
www.debian.org, not developers-reference. Please, reconsider it and
reassign #912724 to www.debian.org.

Regards,
Lev

Processed: Recommend that manpages contain an EXAMPLES section

[Debian Bug Tracking System]

Processing control commands:

> tag -1 +patch
Bug #850171 [debian-policy] debian-policy: Addition of having an 'EXAMPLES' 
section in manual pages debian policy 12.1
Bug #850289 [debian-policy] debian-policy: Patch so that there is an Example 
section in manual pages
Added tag(s) patch.
Added tag(s) patch.

-- 
850171: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=850171
850289: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=850289
Debian Bug Tracking System
Contact ow...@bugs.debian.org with problems

Bug#850171: Recommend that manpages contain an EXAMPLES section

[Sean Whitton]

control: tag -1 +patch

Hello,

Policy probably shouldn't contain too much detail about the contents of
manpages, but EXAMPLES sections really do make them significantly more
useful, so I would like to include the recommendation that Shirish
proposes.

Hence I am seeking seconds for this patch I've written:

diff --git a/policy/ch-docs.rst b/policy/ch-docs.rst
index e990f34..a9b297f 100644
--- a/policy/ch-docs.rst
+++ b/policy/ch-docs.rst
@@ -61,6 +61,12 @@ by a note at the beginning of the manual page or by showing 
the missing
 or changed portions in the original language instead of the target
 language.

+It is recommended that manual pages contain an EXAMPLES section,
+containing working syntax that uses the functionality documented by
+the manual page.  For example, command-line invocations of a utility
+for some of its standard usages, or an example call to an API
+function.
+
 .. _s12.2:

 Info documents

-- 
Sean Whitton


signature.asc
Description: PGP signature

Processed: Re: Bug#845715: Required targets must not write outside of the source package tree

[Debian Bug Tracking System]

Processing control commands:

> tag -1 -patch +pending
Bug #845715 [debian-policy] debian-policy: Please document that packages are 
not allowed to write outside their source directories
Removed tag(s) patch.
Bug #845715 [debian-policy] debian-policy: Please document that packages are 
not allowed to write outside their source directories
Added tag(s) pending.

-- 
845715: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=845715
Debian Bug Tracking System
Contact ow...@bugs.debian.org with problems

Bug#845715: Required targets must not write outside of the source package tree

[Sean Whitton]

control: tag -1 -patch +pending

Hello,

On Sat 03 Nov 2018 at 01:07PM -0700, Russ Allbery wrote:

> One minor wording nit, seconded either way:
>
>> +Required targets must not attempt to write outside of the unpacked
>> +source package tree. An exception to this rule is the use of
>> +``TMPDIR`` (or ``/tmp`` if that is not set) which is permitted as long
>> +as temporary files are deleted by the end of the target, and not
>> +reused by subsequent execution of the target.  This restriction is
>
> How about:
>
> As an exception, required targets may write to the directory specified
> by the ``TMPDIR`` environment variable (or ``/tmp`` if that is not
> set), provided that files created in that directory are deleted before
> the target completes and are not reused by subsequent executions of
> the target.

Good, thanks.

-- 
Sean Whitton


signature.asc
Description: PGP signature

Bug#845715: Required targets must not write outside of the source package tree

[Russ Allbery]

Sean Whitton  writes:

> I reformatted and wordsmithed josch's patch, second it myself, and am
> seeking further seconds.

> Given that whole archive rebuilds with use sbuild and already catch
> packages that violate this requirement, making this change would not
> declare any packages buggy that would not already be considered buggy,
> so we can make it right away.

Excellent!  This has been a long-standing issue, and it's great to finally
get this into Policy.

One minor wording nit, seconded either way:

> +Required targets must not attempt to write outside of the unpacked
> +source package tree. An exception to this rule is the use of
> +``TMPDIR`` (or ``/tmp`` if that is not set) which is permitted as long
> +as temporary files are deleted by the end of the target, and not
> +reused by subsequent execution of the target.  This restriction is

How about:

As an exception, required targets may write to the directory specified
by the ``TMPDIR`` environment variable (or ``/tmp`` if that is not
set), provided that files created in that directory are deleted before
the target completes and are not reused by subsequent executions of
the target.

This explicitly states that this is an environment variable and makes it
clear that it refers to a directory.

> +intended to prevent source package builds creating and depending on
> +state outside of themselves, thus affecting multiple independent
> +rebuilds.  In particular, the required targets must not attempt to
> +write into ``HOME``.

-- 
Russ Allbery (r...@debian.org)   

Processed: Required targets must not write outside of the source package tree

[Debian Bug Tracking System]

Processing control commands:

> tag -1 +patch
Bug #845715 [debian-policy] debian-policy: Please document that packages are 
not allowed to write outside their source directories
Added tag(s) patch.

-- 
845715: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=845715
Debian Bug Tracking System
Contact ow...@bugs.debian.org with problems

Bug#845715: Required targets must not write outside of the source package tree

[Sean Whitton]

control: tag -1 +patch

Hello,

I reformatted and wordsmithed josch's patch, second it myself, and am
seeking further seconds.

Given that whole archive rebuilds with use sbuild and already catch
packages that violate this requirement, making this change would not
declare any packages buggy that would not already be considered buggy,
so we can make it right away.

diff --git a/debian/changelog b/debian/changelog
index 956f367..b90ea92 100644
--- a/debian/changelog
+++ b/debian/changelog
@@ -10,6 +10,11 @@ debian-policy (4.2.2.0) UNRELEASED; urgency=medium
 Seconded: Holger Levsen 
 Seconded: Russ Allbery 
 Closes: #912581
+  * Policy: Required targets must not write outside of the source package tree
+Wording: Johannes Schauer 
+Seconded: Sean Whitton 
+Seconded: ...
+Closes: #845715
   * In a preexisting footnote, recommend passing -D to strip(1) when
 stripping static libraries.
 Thanks to Niels Thykier for the suggestion.
diff --git a/policy/ch-source.rst b/policy/ch-source.rst
index dc80243..c486e7c 100644
--- a/policy/ch-source.rst
+++ b/policy/ch-source.rst
@@ -291,6 +291,16 @@ For packages in the main archive, no required targets may 
attempt
 network access, except, via the loopback interface, to services on the
 build host that have been started by the build.

+Required targets must not attempt to write outside of the unpacked
+source package tree. An exception to this rule is the use of
+``TMPDIR`` (or ``/tmp`` if that is not set) which is permitted as long
+as temporary files are deleted by the end of the target, and not
+reused by subsequent execution of the target.  This restriction is
+intended to prevent source package builds creating and depending on
+state outside of themselves, thus affecting multiple independent
+rebuilds.  In particular, the required targets must not attempt to
+write into ``HOME``.
+
 The targets are as follows:

 ``build`` (required)
diff --git a/policy/upgrading-checklist.rst b/policy/upgrading-checklist.rst
index 899f7e8..70b31bd 100644
--- a/policy/upgrading-checklist.rst
+++ b/policy/upgrading-checklist.rst
@@ -52,6 +52,10 @@ Unreleased.
 copyright file, but it need not be if creating and maintaining a
 copy of that information involves significant time and effort

+4.9
+Required targets must not write outside of the unpacked source
+package tree, except for TMPDIR (or /tmp if that is not set).
+
 10.1
 Binaries should be stripped using
 ``strip --strip-unneeded --remove-section=.comment --remove-section=.note``

-- 
Sean Whitton


signature.asc
Description: PGP signature

Processed: Re: Bug#912724: www.debian.org: wrong links to translations of "Debian Developer's Reference"

[Debian Bug Tracking System]

Processing control commands:

> reassign 912724 developers-reference
Bug #912724 [developers-reference] www.debian.org: wrong links to translations 
of "Debian Developer's Reference"
Ignoring request to reassign bug #912724 to the same package

-- 
912724: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=912724
Debian Bug Tracking System
Contact ow...@bugs.debian.org with problems

Processed: Re: Bug#912724: www.debian.org: wrong links to translations of "Debian Developer's Reference"

[Debian Bug Tracking System]

Processing control commands:

> reassign 912724 developers-reference
Bug #912724 [www.debian.org] www.debian.org: wrong links to translations of 
"Debian Developer's Reference"
Bug reassigned from package 'www.debian.org' to 'developers-reference'.
Ignoring request to alter found versions of bug #912724 to the same values 
previously set
Ignoring request to alter fixed versions of bug #912724 to the same values 
previously set

-- 
690750: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=690750
912724: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=912724
Debian Bug Tracking System
Contact ow...@bugs.debian.org with problems

Bug#690750: Bug#912724: www.debian.org: wrong links to translations of "Debian Developer's Reference"

[Holger Wansing]

Control: reassign 912724 developers-reference

Lev Lamberov  wrote:
> Package: www.debian.org
> Severity: normal
> Tags: l10n
> 
> Dear Maintainer,
> 
> Debian Developer's Reference on the Debian's website [reference]
> contains wrong links to translations of the documantation. That is,
> French translation is linked as index.fr.en.html (where it should be
> index.fr.html) and so on. The same problem holds for translations,
> that is French translation [reference-fr] links to Italian as
> index.it.fr.html (where it should be index.it.html).
> 
> [reference-en] 
> https://www.debian.org/doc/manuals/developers-reference/index.en.html
> 
> [reference-fr] 
> https://www.debian.org/doc/manuals/developers-reference/index.fr.html
> 
> I guess the problem is with the content negotiation, since there's no
> such problems both in the source code of the documentation and in the

This has already been reported (years ago :-( ) in 
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=690750

(and: no, there's no content negotiation involved here, that's static links;
thus reassigning to package)


I have already proposed a fix there, too.

@hideki: any objections against me committing the patch from
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=690750#17 ?



Holger


-- 

Created with Sylpheed 3.5.1 under 
D E B I A N   L I N U X   9   " S T R E T C H " .

Registered Linux User #311290 - https://linuxcounter.net/