Bug#1064454: debian-policy: Restrict deb822 field names more

[Niels Thykier]

Simon Josefsson:

Would it make sense to change this to use an inclusive list of permitted
characters instead?  How about checking the field names that is in use
today, and construct a regexp of permitted symbols out of that?
Starting point: [A-Za-z][A-Za-z0-9-_]*

/Simon


That is an option and would work for me.

Though, the starting point should include "_" as allowed for first 
character for the reasons listed in my opening email.


Best regards,
Niels

Bug#1064454: debian-policy: Restrict deb822 field names more

[Niels Thykier]

Package: debian-policy
Severity: wishlist
X-Debbugs-Cc: ni...@thykier.net
X-Debbugs-Cc: lintian-ma...@debian.org
X-Debbugs-Cc: de...@lists.debian.org
X-Debbugs-Cc: debian-d...@lists.debian.org

Hi

I am hoping we can agree to some tighter bounds on the field names 
followed by relevant tools implementing the same restrictions in our 
next versions. Ideally all deb822 parsers should follow suit; I have 
CC'ed the major ones I could think of.
 I will submit a MR for the  python-debian's parser if a change is 
agreed, which would eventually cover dak.


My rationale for this request is as follows.


The policy says the following about a field name:



The field name is composed of US-ASCII characters excluding control characters, 
space, and colon (i.e., characters in the ranges U+0021 (!) through U+0039 (9), 
and U+003B (;) through U+007E (~), inclusive). Field names must not begin with 
the comment character (U+0023 #), nor with the hyphen character (U+002D -).



Which leads to the interesting case that:

```
Package: foo
Depends: bar,
${shlib:Depends}
```

is a *valid* deb822 paragraph with 3 fields. The last being named 
`${shlib` with the value `Depends}`. I spotted this while debugging the 
python-debian parser that did not react to what I thought was a clear 
syntax error.


While the parser is technically correct given the Policy description 
above, I cannot see any case where this is a desirable outcome. Instead, 
I think we should classify this as a syntax error such that users are 
instructed to indent `${shlib:Depends}` token.


A simple fix would be to forbid `$` at the start of the field. Though, I 
think at this point it would make sense to prune more special characters 
from the list like `%&{}[]()/\\<>|$` from anywhere in the field. Note 
that we definitely need to keep `_` as it is used in debconf template 
files for translations. Both single and double underscore is used here, 
though they always come first in the field name.


The reason why I want a tighter bound is that currently, the following 
things are also considered valid field names:



|foo(>=1:2.0),
foo(>=2:2.0),
,foo(>=3:2.0)
,foo(>=4:2.0)[amd64]
)': We can make inverted crying smileys as field names!
`Foo`: Now with markdown formatting of the field name!
$(foo): Can we trick something into running shell commands?
/etc/passwd: Maybe path traversal


In all cases, I see no value to allowing these absurd field names and 
only potential downsides.



Best regards,
Niels

PS: I doubt anything actually uses field names in an unsafe manner any 
more. But we do have some history with deb822 files.


But someone will eventually try to do this. We already received a bug 
report against debhelper long ago about being able to do path traversal 
via questionable package names. Largely, this was considered a non-issue 
because dpkg in its default configuration would abort and debhelper has 
a "run arbitrary code via the upstream build system" feature anyway.


Additionally, 10+ years ago. lintian would create a file per field of 
the file it scanned. Here, if it had used perl's "2-arg" open, you might 
have been able to do something "fun". I do not remember if it did and 
the exploit is a decade overdue even if.

Bug#1055760: debian-policy,dpkg: Please document maintscript flow with `prerm deconfigure`

[Niels Thykier]

Package: debian-policy,dpkg
Severity: wishlist
X-Debbugs-Cc: ni...@thykier.net,debian-d...@lists.debian.org

Hi

The flow charts at 
https://www.debian.org/doc/debian-policy/ap-flowcharts.html 
unfortunately does not cover the `prerm deconfigure [...]`


This makes it hard to figure whether a package needs to consider 
`deconfigure` when it needs to have `prerm` code.


Like if a `prerm deconfigure` will be followed by a `prerm remove` then 
doing anything in `prerm deconfigure` is basically redundant (?) as you 
can just do it in `prerm remove` instead. Or does `deconfigure` imply a 
`remove` (despite the name suggesting it would only move the package to 
"configured -> unpacked")


This would also be relevant to understand whether postinst need to react 
to `abort-deconfigure` or can one assume that a `configure` will always 
(timely) follow an `abort-deconfigure`?


I had a look at `deb-prerm` and `deb-postinst`. Sadly, these does not 
answer my questions (they say when the action occurs). However, I am 
missing an overview and the terse descriptions do not give me that (nor 
tell me what state the package is in after success/failure, which could 
have helped in some cases).


Best regards,
Niels

PS: In debhelper, I have liberally sprinkled in `abort-*` cases in to 
the postinst and avoided any conditions in the prerm scripts. But it is 
not out of understanding but out of assumptions.

Bug#1051582: Policy 9.3 (Starting system services) is largely obsolete

[Niels Thykier]

Russ Allbery:

Niels Thykier  writes:

Russ Allbery:



Ooo, this is a great framing of the problem.  I have a lot of thoughts
about this.  Unfortunately, I'm not sure if they're actionable thoughts
since my grand vision requires someone to sit down and do some serious
Policy restructuring and produce a radically different document.  But
maybe if I write them all down and enough people feel similarly, it
would be worth doing.  I would love to work on this, I am just afraid
that it is the sort of project that I would start and never finish and
thus never accomplish anything of use.



Indeed, it is definitely the thing I would personally prefer to
pre-align on before adventuring on something of this scale myself (were
I in your shoes), so I totally feel your concern about actionability.


I do to some extent want people to encourage me to work on this if they
think it would be awesome, since people being happy with it would be what
would make all the work worthwhile (although I will probably also need
help).  :)



Personally, I feel such a change would be for the better. +1 from here.


Interesting choice with the mixing. I was of the understanding that the
idea was one should try to avoid mixing documentation styles according
to Divio. Admittedly, I find it hard to fully stick to exactly one type
of style, so I would be happy if I had just overlooked the "advice on
mixing".


So, I have to admit that I have not read Divio in detail although I have
been pointed at it many times and have had the high-level concepts
explained to me.  I've read bits and pieces, but I'm not sure what it says
about mixing.



I think it was my reading of their Introduction section. It says:

"""
Each of them requires a distinct mode of writing. People working with 
software need these four different kinds of documentation at different 
times, in different circumstances - so software usually needs them all, 
and they should all be integrated into your documentation.


And documentation needs to be explicitly structured around them, and 
they all must be kept separate and distinct from each other.

"""

Which I interpreted as "don't mix" (particular the "must be kept 
separate and distinct").  But re-reading here it might just be that the 
policy should use "How to" as a baseline and clearly mark explainer 
paragraphs as "Here is the background" as something you can choose to 
dive into or easily skip if you are not interested (or have distinct 
subsections for how to vs. explainers, which I think you are proposing 
in the part that I snipped)


Anyway, as long as you are going into it with open eyes and it seems 
like you are!



[...]


As for the content: The "How-to" style would make sense for the target
audience.  I am less clear if all of these headlines makes up a "Policy"
as they sounds like something you could find in a "Debian Packaging 101"
guide.


I think that about a quarter of Policy currently is already how-to text.
For example, look at Policy 3.4:

https://www.debian.org/doc/debian-policy/ch-binary.html#s-descriptions

This is a disguised how-to document on how to write a good package
description.  There's a ton of stuff in Policy like this.  What
distinguishes it from a Debian Packaging 101 guide is that the how-to goes
into *way* more depth than a 101 guide: edge cases, exceptions, advanced
bits of packaging, etc.



Sounds good to me.  For me it was mostly a question to ensure that 
Policy would not end up like "yet another new maintainers guide". You 
seem to have a clear vision here for how the Policy would set itself 
apart and I think you make a compelling argument.



The main problem from the perspective of helping the typical packager, is
that this is mixed in with oodles of advice that is irrelevant to anyone
except debhelper maintainers.  To take another short example, look at the
section on symbolic links:

https://www.debian.org/doc/debian-policy/ch-files.html#symbolic-links

Half of that section is a specification for the packaging helper, which
will fix symbolic links to follow those rules.  The rest is sort of a
how-to (mixed in with some basic shell command advice).



Indeed, I am not a fan of the those sections in our Policy!


Side question: Does Policy add anything on the specification for
`symbols` and `shlibs` files as a reference document that is not covered
by dpkg's documentation for these formats? I assume the "symbols guide"
(on /when/ to use symbols and when not too) would go in the previous
section.


Well, one can read the two side-by-side and see, and I'm biased as the
person who wrote it, but I think it does.

Policy duplicates dpkg documentation quite a lot, so this is a question
worth asking, but I do think Policy has a good answer.  The value that
Policy adds over the dpkg documentation generally falls into three
categories:

[...]


Again, compel

Bug#1051582: Policy 9.3 (Starting system services) is largely obsolete

[Niels Thykier]

Russ Allbery:

Niels Thykier  writes:


I had a look at the introduction section of Policy to check who the
target audience is.  I cannot find an explicit mention of the target
audience. I suspect there is a conflict here on the content because we
have different audiences in mind for the Policy and the Policy does not
seem to be explicit here.



[...]


Ooo, this is a great framing of the problem.  I have a lot of thoughts
about this.  Unfortunately, I'm not sure if they're actionable thoughts
since my grand vision requires someone to sit down and do some serious
Policy restructuring and produce a radically different document.  But
maybe if I write them all down and enough people feel similarly, it would
be worth doing.  I would love to work on this, I am just afraid that it is
the sort of project that I would start and never finish and thus never
accomplish anything of use.



Indeed, it is definitely the thing I would personally prefer to 
pre-align on before adventuring on something of this scale myself (were 
I in your shoes), so I totally feel your concern about actionability.



I think that ideally Policy targets all three of your audiences, but not
at the same time, and not with the same priority.

I have a lot of problems with the current structure of Policy, to the
extent that it sometimes interferes with my motivation for working on it,
and one of the big ones is that it doesn't follow any structured design
pattern for documentation, such as Divio [1].


I had Divio in an earlier draft of my email - should have kept it! :D


[...]

I think my ideal structure of Policy would have three major parts.

First, there would be Policy for Debian packagers.  This would focus on
the things someone packaging for Debian needs to know, and would be
organized roughly around task.  Example sections here would be:

* Choosing an archive area
* Files on the file system (FHS, ownership, permissions, etc.)
* Writing a debian/control file
* Writing a changelog
* Writing a copyright file
* Packaging a shared library
* Packaging a system service
* Using maintainer scripts

In other words, this section would consist primarily of Divio how-to
guides, with some intermixed Divio explanations.  (Tutorials I think are
outside the scope of Policy and are better handled elsewhere, such as in
debhelper documentation.)

[...]


Interesting choice with the mixing. I was of the understanding that the 
idea was one should try to avoid mixing documentation styles according 
to Divio. Admittedly, I find it hard to fully stick to exactly one type 
of style, so I would be happy if I had just overlooked the "advice on 
mixing".


As for the content: The "How-to" style would make sense for the target 
audience.  I am less clear if all of these headlines makes up a "Policy" 
as they sounds like something you could find in a "Debian Packaging 101" 
guide.  That is a "risk" (or maybe exactly what you are going for), 
which would be fine with me and I would support the idea.


Nevertheless, I feel it has quite some potential to make Policy more 
accessible to new contributors and that alone is worth supporting in my 
book. Though I am hardly the target audience nor "paying the upkeep 
cost", so supporting it is basically gratis for me.





[...]

Second section would be Policy the reference manual for interfaces in the
distribution.  Sections here would be:

* Complete list of control fields and their meanings.
* Specifications for the .dsc and .changes files (which packagers mostly
   never need to care about, but tool maintainers do).
* The detailed reference documentation on all the ways maintainer scripts
   can be called.
* Specification for the symbols and shlibs files.

This is all Divio reference stuff.  Whenever we have a comprehensive
explanation of the details of something, it goes here, and then we
liberally link to the reference section from the packaging-focused how-to
section for more details.



Makes sense to me as well. I would indeed also need documentation somewhere.

Side question: Does Policy add anything on the specification for 
`symbols` and `shlibs` files as a reference document that is not covered 
by dpkg's documentation for these formats? I assume the "symbols guide" 
(on /when/ to use symbols and when not too) would go in the previous 
section.



Finally, there is the reference manual for toolchain maintainers.  My
position on this is that it's best-effort documentation and should
probably be a non-normative appendix where toolchain maintainers are
relatively free to just make changes without going through a very formal
process as long as those changes reflect reality.  This is, by nature,
going to be incomplete and possibly out of date, but I do think the
project should have *somewhere* outside of any specific package where
people can write down the details of, oh, the other options to
Rules-Requires-Root that we aren't currently u

Bug#1051582: Policy 9.3 (Starting system services) is largely obsolete

[Niels Thykier]

Russ Allbery:

Bill Allombert  writes:

[...]  Quite a lot of Policy is of the general format "here's a bunch of
complex things you need to do, wait, never mind, just use debhelper, go
see its documentation for the configuration files you should use instead"
and some of the rest of Policy is "here's a bunch of complex things you
need to do but if you follow these instructions instead of using debhelper
your package will be buggy."  This is not ideal!

I think there's a lot of appeal of having a thorough specification for
what debhelper is supposed to be doing.  It would enable future
competition around better packaging helpers (and I do think debhelper will
not be the last word).  But I also want to be realistic about whether
we're really capable of maintaining that specification.

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



Indeed. I have had the same challenge with the Policy.

I had a look at the introduction section of Policy to check who the 
target audience is.  I cannot find an explicit mention of the target 
audience. I suspect there is a conflict here on the content because we 
have different audiences in mind for the Policy and the Policy does not 
seem to be explicit here.


If the target audience is package maintainers, then 100% of all debian 
contributors should read it. Then we need "simple and easy to 
understand" language and examples, because we want *everybody* to 
understand this.  I agree with Russ that long winded sections of "here 
is how you do this manually but really just use debhelper" is directly 
counter productive to this audience.


If it is cross-package integration, are we targeting the ones 
integrating or the ones providing the integration points?  If it is 
both, then for more complex topics, it would make sense to split the 
topic into two. One for consumer and one for the provider of the 
integration, because for the consumer it will probably boil down to 
"install path at $X in your deb and run tool $Y" and then the consumer 
can skip the provider section as "not relevant".


  There is a separate here in whether the Policy editors have the 
capacity to maintain the documentation for the provider side of the 
integration points for all the integrations.  I think this is where Russ 
is arguing that we do not that capacity.  If so, it would also make 
sense to explicitly cut *out* that side of from policy in the Scope 
section. Maybe along the lines of "The Policy does not document the 
provider side of integration points directly. Instead, we provide links 
to the external documentation where available.".



If the target audience is tool-chain maintainers, then only 5-10 people 
need to read the policy and the entire document + related process seems 
completely over-engineered.  But then, for the same reason, I suspect 
this is an unlikely target audience for the Policy.



Either way, I think the root problem is that we are not all agreeing on 
scope and audience for the Policy. Until resolved, we can argue forever 
about whether X belongs in Policy.


Best regards,
Niels


PS: I also have other things to say about the concrete topic, but I will 
leave that for a later mail. I think the point above is so important 
that it should not be diluted with other topics.

Bug#1049406: debian-policy: Does Debian have native vs. non-native *binary* packages?

[Niels Thykier]

Package: debian-policy
Severity: minor
X-Debbugs-Cc: ni...@thykier.net

Hi,

I re-read a bit on the policy definition of native vs. non-native 
packages and it occurred to me that the written word of the policy seems 
to be confusing to read at best.



The concept of a native package is introduced in chapter 4 "Source 
packages" and the following definition is given:


"""
Debian **source** packages are classified as native or non-native.

A native source package is one that does not distinguish between Debian 
packaging releases and upstream releases. A native source package 
contains a single tar file of source material, and the versioning does 
not have a Debian-specific component. Native packages are normally (but 
not exclusively) used for software that has no independent existence 
outside of Debian, such as software written specifically to be a Debian 
package.


[... more stuff about non-native packages ...]
"""

I put emphasis here on "Debian **source** packages", which implies that 
this definition do not apply to binary packages. I had a look in Chapter 
3 "Binary packages" and it does mention "Native Debian packages" but 
does not define the term.
  I assume the term in chapter 3 is a forward reference to chapter 4 
but it never explicitly states this. I feel it would aid the reader if 
it did have a explicit forward reference if that is what it is.
  Based on this assumption, I feel the full term should probably be 
along the lines of "binary packages built from a (non-)native source 
package". However, I admit that phrase is a bit obscene to use compared 
to "N(on-n)ative Debian packages" as it is a full sentence on its own. 
However, the shorter phrase used now may confuse readers into believing 
that "native binary packages" are a thing, which they do not seem to be 
according to chapter 4.



Assuming we agree so far, this has the consequences that:

 * The basename of the installed changelog name ("changelog" vs.
   "changelog.Debian") is decided based on the source package version
   and not the binary package version.
   - This is de facto what debhelper does because it does not know the
 version of the binary at the time debhelper installs the changelog
 (dh_installchangelog is run long before dh_gencontrol).
   - Not sure whether this affects lintian (I do not remember the code).

 * The remark in chapter 3 about date versioning for native packages is
   misplaced and should be in chapter 4 (the one about dashes being
   unsuitable for date separators in a native package). Because, a
   binary package built from a native source *can* have hyphens in its
   version.  Both according to the letter of the policy (the "native"
   trait only applies to the source package) but also in practice[1].

Assuming we do not agree on the above reading and "native binary 
packages" are a thing, then:


 * We have at least one instance of a non-native binary built from a
   native source that contains hyphens[1] with no open bugs of policy
   violations on this matter.

Maybe we should also review this from the angle of "Can a non-native 
source package produce binaries without a hyphen?" (e.g., replace "-" 
with "+") and still be policy complaint.  I would say "no", but tooling 
wise, I am certain it is possible.  Having a rule that all binaries 
built from a source must use the same "native-ness" of the source would 
solve this problem but would define java-common to be non-complaint.


However for the reasons stated above, we probably do not *want* to 
resolve this by mandating a binary is native based on its own version 
regardless of the source version/native-ness. This would lead debhelper 
to be non-compliant and in practice unable to become compliant out of 
the box.


Additionally, I hope we can improve the policy language around native 
vs. non-native and how it relates to binary packages.


Best regards,
Niels

[1]:
$ apt-cache show default-jre | grep -e ^Source: -e ^Version
Source: java-common (0.74)
Version: 2:1.17-74

The java-common source is a native package (version 0.74) but its binary 
default-jre is 2:1.17**-**74 and contains a hyphen.


This practice existed for over a decade now as I remember and no one 
complained. So the use of hyphens in binary versions are definitely not 
causing tooling issues and in my eyes makes this a "common practice" 
question rather than a "breaks stuff" question for whether it is allowed.


Feel free to open the on whether decade of use vs. it is only one 
package. Either way, the Policy is in my eyes not clear enough / aligned 
on this topic on what is allowed and what is not allowed.

Bug#975637: debian-policy: deprecate Rules-Requires-Root other than "no", "binary-targets" in Debian

[Niels Thykier]

On Mon, 14 Dec 2020 15:01:52 -0700 Sean Whitton 
 wrote:

Hello Ansgar,

On Tue 24 Nov 2020 at 01:37PM +01, Ansgar wrote:

> Package: debian-policy
> Version: 4.5.1.0
> Severity: normal
>
> After a discussion in #-devel today I reviewed packages using other
> choices of "Rules-Requires-Root" than "no" and "binary-targets".  The
> query [1] found two uses:
>
> [...]
>
> The complexity to support arbitrary additional keywords as choices of
> R³ seems overkill given there is just one real user (libcap2) and the
> current R³ specification doesn't handle that usecase fully either.
>
> Therefore I suggest to deprecate using R³ values other than "no" and
> "binary-targets" within Debian.
>
> (Unrelated: R³: no should probably be recommended.)

We would definitely need input from the designers of the R³ system
before removing anything (to my knowledge, the design was led by Niels
and Guillem).  They were designing for the very long term, so I don't
think we can safely infer much from the present contents of the archive.

I'm also not really convinced by your arguments that having these other
possible values adds much of a burden.  This is not about code which has
to be updated, just text.  We do not expect newcomers to imbibe
everything in Policy.

--
Sean Whitton


Hi,

Here is my view in short: As I see it, only the values `no` and 
`binary-targets` for `Rules-Requires-Root` makes sense for the *policy 
defined targets*[1] at the moment.  Accordingly, Debian policy can 
probably reduce the field to only cover `binary-targets` and `no` (and 
describe the remaining values as "[they] will mostly behave like `no`, 
but read more in the dpkg documentation for concrete the non-policy 
relevant use-case")


In theory, you could use `Rules-Requires-Root` to cover the static 
ownership cases (where you need to chown files and store that ownership 
in the deb).  However, that would require people to consistently use 
fakeroot with -l + -s (which, to my knowledge, no one does) - failure to 
do so would just silently loose the ownership and the files would end up 
with the wrong owner.


On a related note, both Guillem and I agreed a while back that ownership 
(among other) should ideally be specifiably without using chown.  While 
a concrete method has not yet materialized, I am not working on 
supporting static ownership via chown in debhelper (nor do I plan to do 
so), so in practice `binary-targets` is the only reliable way to setup 
static ownership for any package built via debhelper[2].


So in summary, with the current tooling, only `no` and `binary-targets` 
make sense for *policy defined targets* and I am not aware of anything 
that would change that.


Thanks,
~Niels

PS: As for the adding a recommendation to use `Rules-Requires-Root: no` 
where possible. I would second such as change. Over half of all Debian 
source packages in testing have the value, and adoption has been quite 
fast despite very little push from Guillem and I on it.  For me, the 
recommendation would be documenting public sentiment on this topic.


Source: https://trends.debian.net/rulesreqroot_testing-percent.png

[1]: There is a set of values for asking dpkg-buildpackage to provide 
(fake)root for custom targets, which might make sense for users/packages 
- but since those would be custom targets, Debian Policy should not care 
about these targets.  But it probably has to mention the field can have 
other values than specified and that is okay for very rare cases.


[2]: When `Rules-Requires-Root` is not (effectively) `binary-targets`, 
debhelper will pass `--root-owner-group` to `dpkg-deb`, which neuters 
any filesystem specified ownership.

Bug#990362: debian-policy: Obsolete advice on multiple builds

[Niels Thykier]

Package: debian-policy
Version: 4.5.1.0

Hi,

In 4.9 "Main building script: debian/rules", we find the following
paragraph under the description "build (required)":

"""
> For some packages, notably ones where the same source tree is compiled in 
> different ways to produce two binary packages, the build target does not make 
> much sense. For these packages it is good enough to provide two (or more) 
> targets (build-a and build-b or whatever) for each of the ways of building 
> the package, and a build target that does nothing. The binary target will 
> have to build the package in each of the possible ways and make the binary 
> package out of each.

"""


I think the "binary target will have to build the package in each of the
possible ways" part is a remanent from the time Debian did *not* support
build-arch and build-indep.


A much better recommendation would be to have build-arch and build-indep
targets depend on the relevant build-a, build-b (etc.) targets to keep
the build out of the binary target.  Notably they are builds plus the
binary target *can* be run under (fake)root.

Thanks,
~Niels

Bug#981406: define "makefile" as a GNU Make-compatible makefile; support 'gmake' shebang

[Niels Thykier]

On Sat, 30 Jan 2021 12:52:13 -0500 John Scott  wrote:
> Package: debian-policy
> Version: 4.5.1.0
> Severity: minor
> 
> At the moment, debian/rules is required to be a Makefile, but it's not
> exactly defined. In the absence of an explicit statement it seems most
> reasonable that it would be inherited from POSIX, but use of GNU extensions
> are liberal even in the Makefile excerpts provided by dpkg, for example.
> As make is notorious for its vendor-specific variants, this stands to be
> clarified.
> 
> Specify, perhaps in the Definitions section, that a Makefile is a file to
> be usable with GNU Make. This makes explicit that GNU Make is the
> standard, and implies that provided Makefiles may use such extensions.
> 
> On the topic, the GNU Make package now provides the 'gmake' binary, and
> the requirement that debian/rules starts with '#!/usr/bin/make' seems overly
> strict. Analogously to the requirements for shell scripts, I would like to
> make my GNU makefiles start with '#!/usr/bin/gmake' for explicitness:
> > If a shell script requires non-POSIX.1-2017 features from the shell
> > interpreter other than those listed above, the appropriate shell must be
> > specified in the first line of the script (e.g., #!/bin/bash) and the
> > package must depend on the package providing the shell (unless the shell
> > package is marked “Essential”, as in the case of bash).
> GNU Make extensions are the status quo, so I'd merely like it to be
> permissible to use the 'gmake' shebang line, or perhaps one that's
> functionally equivalent.
> 
> [...]
Hi,

Personally, I am the stage that if we are touching this piece of the
policy, I would like to remove the strict requirement for debian/rules
being make.

My proposal is therefore that the actual requirement would be that
"./debian/rules " must satisfy the policy requirements (as
before) and then have a non-normative paragraph saying that this in
practise has to be a GNU makefile using the shebang of make (or gmake)
due to the current tooling assuming (GNU) make in various places.

A bit of context: Before 2012 it was possible to use a "non-make"
debian/rules.  This "feature" was removed with our transition to mandate
build-{arch,indep} targets as dpkg was expected to use "make -qn" to
detect the presence of these optional targets (see #629385 - there
should also be a ctte bug overruling a maintainer with an sh d/rules
somewhere, but I cannot find it atm.).  However, we are now back to dpkg
supporting a non-make debian/rules again (via a side-effect in the R³
implementation)[1].

My personal reason for this solution is that I am working on removing
the "make layer" between dpkg-buildpackage and dh in the hope that it
will enable us to make some concrete improvements.  In practise the make
layer will probably still be around for a decade or more (but it would
cross off one thing on my todo list now rather than later).


Thanks,
~Niels

[1] But as said, in practise you still need make here except for the
ultimate base cases. Like dh assumes make.

Bug#980825: debian-policy: Historical sign off dates in d/changelog and "single digit" day of the month

[Niels Thykier]

Control: forcemerge -1 971977

Guillem Jover:
> Hi!
> 
> [...]
> 
> Isn't this report a duplicate of #971977?
> 
> (I clarified the other report in deb-changelog(5) with
> .)
> 
> Thanks,
> Guillem
> 

Seems like it.  Thanks for the heads up.

~Niels

Bug#980825: debian-policy: Historical sign off dates in d/changelog and "single digit" day of the month

[Niels Thykier]

Package: debian-policy
Version: 4.5.0.0
Severity: minor

Hi,

This is a bit of a nit pick, but I think it is a special case worth
mentioning in Policy.

I am basing this on
https://www.debian.org/doc/debian-policy/ch-source.html#debian-changelog-debian-changelog
where the date format of the changelog signoff line is described as:


> The date has the following format 7 (compatible and with the same semantics 
> of RFC 2822 and RFC 5322):
> 
> day-of-week, dd month  hh:mm:ss +
> 
> where:
> 
> day-of-week is one of: Mon, Tue, Wed, Thu, Fri, Sat, Sun
> 
> dd is a one- or two-digit day of the month (01-31)
> [...]

I find that "single-digit day" is a bit underspecified here in.
Basically there are two options, either the leading zero is replaced
with a leading space or the leading zero is simply omitted.

Sadly, neither RFC 2822 nor RFC 5322 are helpful in clearing this up as
they both assume "two-digit" days.

My understanding is that the reason for "single-digit" days is to
support historical changelogs, where Debian omitted the leading zero.
The samples I have found[1], the leading zero is replaced with a single
space as in:

>  -- Joey Hess   Thu,  3 Dec 1998 23:31:56 -0800



This is relatively prevalent.  As an (un)scientific example, this
alternative variant accounts for:

 * ~21% of all signoff dates in debhelper (202/927)
 * ~10% of all signoff dates in apt (49/480)


I applaud policy for highlighting the correct and preferred example, so
I propose that we restrain this amendment to a footnote (or another note
of equal low importance) that informs the reader that this alternative
format may be found in older changelog entries and that this variant is
still accepted but that the two-digit format with leading zero should be
preferred in every new entry.


~Niels

[1] Warning, this is based on the very unscientific sample size of about
3 source packages.

Bug#949006: debian-policy: Stop recommending stamp files in debian/rules

[Niels Thykier]

Jonathan Nieder:
> Niels Thykier wrote:
> 
>> debhelper cannot see "inside" the upstream build system.  If you modify
>> a .c file, debhelper won't notice and will currently just skip the
>> entire build.  Alternatively, debhelper will have to invoke the build
>> system and rely on it to not be flawed.
> 
> Yes, I think that would be a good behavior (invoking the build system
> and if it's flawed, let the packager work with upstream on it).
> Especially because the effect is directly on the packagers --- buildds
> wouldn't be hurt by this, as you note.
> 
> Is that the proposed debhelper change?  Where can I sign up? :)
> 

You can get this behaviour today with:

dh $@ --without build-stamp

(You probably want to implement "Rules-Requires-Root: no" first)

My idea would be to use Rules-Requires-Root as conditional to whether
the build-stamp should be enabled by default in a future compat level.
The rationale for that conditional being that we do not want to invoke
the build system as root by default.

>> AFAICT, the current practise recommended by policy have the same issue
>> (assuming you implement the stamp file or touch the "build" file).
> 
> Right, using "touch build" or build-stamp is a last resort, for
> dealing with irreperable upstream build systems.  Having a proper
> upstream build system is much better (and isn't all that rare).
> 
> Thanks,
> Jonathan
> 


Thanks,
~Niels

Bug#949006: debian-policy: Stop recommending stamp files in debian/rules

[Niels Thykier]

Jonathan Nieder:
> Hi!
> 
> Niels Thykier wrote:
> 
>> [...]
>>
>> Notely, this trickery prevents you from hacking on the upstream parts
>> and use "dpkg-buildpackage -b -nc -uc -us" to reduce the build times
>> for subsequent builds.  You would have to add some rm -f calls to
>> delete "internal debhelper state files" as well between each
>> dpkg-buildpackage call.
> 
> The ideal is to have dependencies correctly set so that if something
> changes, the build system knows exactly what needs to be rebuilt.  Is
> that achieveable in the debhelper context?
> 
> Summary: I don't have a strong opinion about what policy should say to
> do with poorly-designed makefiles, but let's make sure debhelper
> doesn't enter that category.
> 
> Thanks,
> Jonathan
> 

As I see it, there is no way for debhelper to sanely determine whether
something should be rebuild or not without just rerunning that part.

debhelper cannot see "inside" the upstream build system.  If you modify
a .c file, debhelper won't notice and will currently just skip the
entire build.  Alternatively, debhelper will have to invoke the build
system and rely on it to not be flawed.

AFAICT, the current practise recommended by policy have the same issue
(assuming you implement the stamp file or touch the "build" file).

Thanks,
~Niels

Bug#949006: debian-policy: Stop recommending stamp files in debian/rules

[Niels Thykier]

Source: debian-policy
Severity: wishlist

Hi,

I would like to propose that we drop or replace the following
recommendation in Policy:

"""
When a package has a configuration and build routine which takes a
long time, or when the makefiles are poorly designed, or when build
needs to run clean first, it is a good idea to touch build when the
build process is complete. This will ensure that if debian/rules build
is run again it will not rebuild the whole program. [11]
"""

(And related footnote about using "build-stamp" instead of "build").


I think a better solution would be to either drop the recommendation
entirely or keep it only for packages with this issue and
Rules-Requires-Root set to binary-targets.  Either way would enable me
to move some debhelper hacks out of the "default" in future compat
level (at least for people with Rules-Requires-Root).


# Rationale:


As I understand it, the primary purpose behind this recommendation
comes from the need for running "debian/rules build && fakeroot
debian/rules binary" and thereby repeating the build step in some
cases (as listed in the text).

However, with the advent of Rules-Requires-Root many packages can now
be built with a direct "debian/rules binary" call and here the stamp
file is no longer useful for the above purpose.

Furthermore, debhelper need some complexity in implementing/emulating
this behaviour.  This may sound "easy" until you try to implement this
"correctly" for the following sequence of debian/rules calls:


 debian/rules build-arch
 debian/rules binary-indep


This has resulted in debhelper using arcane trickery such as log files
(up to compat 9) and its own "stamp-log" (compat 10+).  Both
techniques have their limitations and causes frustrations for people
that has a "well-behaving" upstream build system as they have to work
around debhelper's trickery.

Notely, this trickery prevents you from hacking on the upstream parts
and use "dpkg-buildpackage -b -nc -uc -us" to reduce the build times
for subsequent builds.  You would have to add some rm -f calls to
delete "internal debhelper state files" as well between each
dpkg-buildpackage call.

Thanks,
~Niels

Bug#949007: debian-policy: Typo in example

[Niels Thykier]

Source: debian-policy
Severity: minor


In
https://www.debian.org/doc/debian-policy/ch-source.html#s-debianrules-gainrootapi
we find the following example:


"""
Examples of valid use of the gain root command:

# sh-syntax (assumes set -e semantics for error handling)
$DEB_GAIN_ROOT_CMD some-cmd --which-requires-root

# perl
my @cmd = ('some-cmd', '--which-requires-root');
unshift(@cmd, split(' ', $ENV{DEB_GAIN_ROOT_CMD})) if $ENV{DEB_GAIN_ROOT_CMD};
system(@cmd) == or die("@cmd failed");

"""

The Perl code is invalid.  There is missing a 0 after "==" and before "or 
die(...)".

Thanks,
~Niels

Re: debhelper: Please default Rules-Require-Root to no

[Niels Thykier]

Hideki Yamane:
> Hi,
> 
> On Fri, 24 May 2019 10:47:22 -0700
> Sean Whitton  wrote:
>> (surely we are a very long way from r-r-r: no for every package?)
> 
>  I don't think so since lintian info about 
> "should-specify-rules-requires-root"
>  containts only 98 packages.
>  https://lintian.debian.org/tags/should-specify-rules-requires-root.html
> 
>  mandatory "r-r-r: no" in dpkg-dev and full rebuild shows exact numbers
>  to be dealt with, IMO.
> 
> 

The use of "r-r-r: no" will also disable dpkg-buildpackage detection of
missing build-{arch,indep} targets.  IOW, you need to add

https://lintian.debian.org/tags/debian-rules-missing-recommended-target.html

To your list of packages needing a fix before "r-r-r: no" can be the
default.

Additionally, lintian cannot/does not detect cases where a package use
(fake)root during the install step (e.g. upstream) but then later
"undoes" the ownership to root:root (e.g. dh_fixperms).  Just as an FYI,
so you know the lintian check is incomplete (I have no idea how many
instances we have of that - so it might be a non-issue).

Thanks,
~Niels

Re: debhelper: Please default Rules-Require-Root to no

[Niels Thykier]

Sean Whitton:
> Hello,
> 
> On Fri 24 May 2019 at 01:42PM +09, Hideki Yamane wrote:
> 
>> Hi,
>>
 In summary: The debhelper fundamentally cannot affect whether
 Rules-Requires-Root: no is default or not.  The debhelper compat level
 system is the wrong interface to do this as well.

 That said, in a distant future, I hope we can flip the default of
 Rules-Requires-Root.  But when that comes, it will not be via a
 debhelper compat level AFAICT.
>>
>>  If we want to implement "Rules-Requires-Root: no" mandatory,
>>  is it dpkg-dev and policy issue?
> 
> Requiring maintainers to put `Rules-Requires-Root: no` in every single
> d/control file would be a debian-policy bug, yes.
> 
> Changing debhelper's default, if that remainder overrideable by the
> maintainer, would not be.
> 
> (surely we are a very long way from r-r-r: no for every package?)
> 

FYI, debhelper is *not* in control of the default for r-r-r (as stated
in the quoted text).  Therefore, "Changing debhelper'r default" cannot
be the solution here.

Thanks,
~Niels

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

[Niels Thykier]

Sean Whitton:
> Hello,
> 
> On Sun 11 Nov 2018 at 09:10PM +0100, Bill Allombert wrote:
> 
>> Package support for TMPDIR can be introduced as a general requirement,
>> outside of the build process.
> 
> Okay.
> 
>> Maybe the proposal could be rewritten in a way that does not need to
>> cover the detail of temporaries files.
>>
>> How about:
>>
>> +Required targets must not attempt to write outside of the unpacked
>> +source package tree.  There are two exceptions.  Firstly, the binary
>> +targets may write the binary packages to the parent directory of the
>> +unpacked source package tree.  Secondly, required targets may write to
>> +/tmp, /var/tmp and to the directory specified by the ``TMPDIR`` environment
>> + variable, but must not depend on the content of either.
>> +
>> +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``.
> 
> Thank you for this text.  I'd be happy to second it, since it solves the
> problem I was trying to solve with my patch, but ideally I'd like to
> hear from those others who seconded the older patch to see if they are
> happy to drop the TMPDIR parts.
> 

Seconded, thanks.

~Niels




signature.asc
Description: OpenPGP digital signature

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

[Niels Thykier]

Sean Whitton:
> Hello,
> 
> On Fri 09 Nov 2018 at 09:46PM GMT, Niels Thykier wrote:
> 
>> I suspect we are missing an exception allowing the binary targets to
>> write the produced binaries in the parent directory of the unpacked
>> source tree.
>>   Otherwise pretty much all packages violate the policy when they
>> generate the actual .debs/.udebs. :)
> 
> Heh.  You're right.
> 
> Here is a new version of the patch, fixing this problem.  I am not sure
> that it is meaningful to require that this change be seconded, but out
> of (possibly too much) respect for process, seeking seconds (and CCing
> those who have already seconded in the hope they'll renew their
> seconds):
> 
> diff --git a/policy/ch-source.rst b/policy/ch-source.rst
> index dc80243..3c6c9d5 100644
> --- a/policy/ch-source.rst
> +++ b/policy/ch-source.rst
> @@ -291,6 +291,20 @@ 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.  There are two exceptions.  Firstly, the binary
> +targets may write the binary packages to the parent directory of the
> +unpacked source package tree.  Secondly, 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 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)
> 

Seconded, thanks.

~Niels




signature.asc
Description: OpenPGP digital signature

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

[Niels Thykier]

On Sat, 03 Nov 2018 12:38:55 -0700 Sean Whitton
 wrote:
> 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.
> 
> [...]
> 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``.
> +
> [...]

I suspect we are missing an exception allowing the binary targets to
write the produced binaries in the parent directory of the unpacked
source tree.
  Otherwise pretty much all packages violate the policy when they
generate the actual .debs/.udebs. :)

Thanks,
~Niels

Bug#188731: debian-policy: "strip --strip-unneeded" is insufficient

[Niels Thykier]

Sean Whitton:
> Hello Niels,
> 
> On Sun 28 Oct 2018 at 02:22PM GMT, Niels Thykier wrote:
> 
>> I think I agree with your suggestion of shading policy requirements that
>> are already covered by common tools.
> 
> Well, more specifically debhelper.
> 

FTR, I would be happy if the solution was not specific to "debhelper" in
the long term.  In particular, there is a world of difference between
"debhelper", "cdbs with debhelper", "dh-style debhelper", and
"dhmk-style debhelper".

>> At the moment, I am hesitant as to whether I should second Sean's text
>> as it is or point out that text fails to handle cross-building[1] (note
>> the cross building issue is not a regression).
>>   On one front, it would be technically correct - on the other front, I
>> fear most maintainers will be overloaded by irrelevant details that is
>> already handled for them.
> 
> At present Policy does not require crossbuilding support.  So while it
> would be nice to include details of how to properly support
> crossbuilding, it's not as though we're contradicting another
> requirement in Policy.  So it seems like including the crossbuilding
> details would be a separate bug.
> 

Indeed - and accordingly, it is not a regression. :)

Thanks,
~Niels

Bug#188731: debian-policy: "strip --strip-unneeded" is insufficient

[Niels Thykier]

Sean Whitton:
> control: tag -1 +patch
> 
> Hello,
> 
> On Fri 28 Sep 2018 at 05:38AM GMT, Niels Thykier wrote:
> 
>>  * We now have auto-generated dbgsym packages by dh_strip (which were
>>just an idea when Bill wrote that answer).
>>
>>  * Policy mentions "--remove-section=.comment --remove-section=.note" in
>>a footnote as a "You might also want to use ...".
>>
>>  * Policy section 10.1 implies that "INSTALL = install -s" is a useful
>>way of stripping binaries (both in text and examples).  Besides not
>>covering the .comment + .note sections it also neuters dh_strip's
>>ability to create dbgsym packages.
>>
>>
>> I think we should update the policy to say that you should use
>> "--strip-unneeded --remove-section=.comment --remove-section=.note" and
>> maybe recommend delegating that task (where possible) to dh_strip as it
>> provide dbgsym packages.
> 
> Thank you for following up.
> 
> Here is a minimal patch, for which I am seeking seconds.  [...]
> 

Hi,

Seconded with one remark.

> diff --git a/policy/ch-files.rst b/policy/ch-files.rst
> index 21c4c37..7106afe 100644
> --- a/policy/ch-files.rst
> +++ b/policy/ch-files.rst
> @@ -48,12 +48,20 @@ used:
>  CC = gcc
>  CFLAGS = -O2 -g -Wall # sane warning options vary between programs
>  LDFLAGS = # none
> -INSTALL = install -s # (or use strip on the files in debian/tmp)
> 
> -Note that by default all installed binaries should be stripped, either
> -by using the ``-s`` flag to ``install``, or by calling ``strip`` on the
> -binaries after they have been copied into ``debian/tmp`` but before the
> -tree is made into a package.
> +By default all installed binaries should be stripped by calling
> +
> +::
> +
> +strip --strip-unneeded --remove-section=.comment --remove-section=.note 
> binaries
> +
> +on the binaries after they have been copied into ``debian/tmp`` but
> +before the tree is made into a package.
> +
> +It is not recommended to strip binaries by passing the ``-s`` flag to
> +``install``, because this fails to remove .comment and .note sections,
> +and also prevents the automatic creation of dbgsym binary packages by
> +tools like ``dh_strip``.
> 
>  Although binaries in the build tree should be compiled with debugging
>  information by default, it can often be difficult to debug programs if
> @@ -114,7 +122,7 @@ All installed shared libraries should be stripped with
> 
>  ::
> 
> -strip --strip-unneeded your-lib
> +strip --strip-unneeded --remove-section=.comment --remove-section=.note 
> your-lib
> 
>  (The option ``--strip-unneeded`` makes ``strip`` remove only the symbols
>  which aren't needed for relocation processing.) Shared libraries can
> @@ -123,7 +131,8 @@ linking are in a separate part of the ELF object file.  
> [#]_
> 
>  Note that under some circumstances it may be useful to install a shared
>  library unstripped, for example when building a separate package to
> -support debugging.
> +support debugging.  The debhelper `dh_strip`` tool can create such
> +packages automatically.
> 
>  Shared object files (often ``.so`` files) that are not public
>  libraries, that is, they are not meant to be linked to by third party
> @@ -741,9 +750,8 @@ restricted to ASCII when it is possible to do so.
> shared library, like ``mklibs`` does in the Debian installer project.
> 
>  .. [#]
> -   You might also want to use the options ``--remove-section=.comment``
> -   and ``--remove-section=.note`` on both shared libraries and
> -   executables, and ``--strip-debug`` on static libraries.
> +   You might also want to use the option ``--strip-debug`` on static
> +   libraries.
> 

For static libraries, you want to use --strip-debug *instead* of
--strip-unneeded (as opposed to "also" as the text implies) AFAICT.  At
least, debhelper always used --strip-debug without --strip-unneeded on
static libraries.

Note that for static libraries, it might be prudent to remind people to
use "-D" / "--enable-deterministic-archives" to ensure a deterministic
result (and thereby comply with the policy's recommendation to support
reproducible builds).

>  .. [#]
> A common example are the so-called "plug-ins", internal shared
> 
> =
> 
> To obtain a side-by-side diff:
> 
> % git clone salsa.debian.org:dbnpolicy/policy.git debian-policy
> % cd debian-policy
> % git difftool -y -x icdiff master..origin/bug188731-spwhitton
> 
> Alternatively, visit
> 
> https://salsa.debian.org/dbnpolicy/policy/commit/3cc86484767ac0aead9b7466c074ade5021ef225?view=parallel
> 

Thanks,
~Niels

Bug#188731: debian-policy: "strip --strip-unneeded" is insufficient

[Niels Thykier]

Russ Allbery:
> Sean Whitton  writes:
> 
>> Thank you for following up.
> 
>> Here is a minimal patch, for which I am seeking seconds.  I didn't
>> include a recommendation to use dh_strip because we generally keep such
>> recommendations in footnotes rather than the text of Policy, and we are
>> trying to reduce the number of footnotes -- but I don't mind adding it
>> if others think it would be a good idea (and it wouldn't need
>> seconding).
> 
> Looks good to me.  Seconded.
> 
> On an entirely unrelated note (and probably a larger project than anyone
> will be able to tackle any time soon), I think it would be very helpful if
> we had some way of annotating what parts of Policy are just handled for
> you if you use debhelper in the normal way (perhaps with references to the
> tools involved).  Maybe with background shading or an icon or something?
> I think Policy needs to state all of the rules, including the ones
> implemented by other tools, but at the same time nearly everyone doing
> Debian packaging is using debhelper (either directly or indirectly), so
> it's a bit of a disservice to people to ask them to wade through a bunch
> of specifications for stuff that normally they don't and shouldn't think
> about.
> 

I think I agree with your suggestion of shading policy requirements that
are already covered by common tools.

At the moment, I am hesitant as to whether I should second Sean's text
as it is or point out that text fails to handle cross-building[1] (note
the cross building issue is not a regression).
  On one front, it would be technically correct - on the other front, I
fear most maintainers will be overloaded by irrelevant details that is
already handled for them.

Well, given it is not a regression, the choice is strictly speaking
"obvious" in this case but the general issue stands.

Thanks,
~Niels

[1] For cross build support, you would have to use
"$(DEB_HOST_GNU_TYPE)-strip" rather than "strip"... Except if you are
doing a "Canadian Cross" build in which case you *might* need
"$(DEB_TARGET_GNU_TYPE)-strip" instead in very rare cases.

Plus you have to ensure DEB_HOST_GNU_TYPE is defined - either by
including a dpkg makefile (recommended) or defining it yourself via
dpkg-buildflags which will imply $(shell ...).  We would like to avoid
the latter due to the high overhead involved in doing that.

Bug#188731: debian-policy: "strip --strip-unneeded" is insufficient

[Niels Thykier]

On Mon, 11 May 2015 11:18:29 +0200 Bill Allombert 
wrote:
> On Mon, May 11, 2015 at 01:39:43PM +0500, Andrey Rahmatullin wrote:
> > On Sat, Apr 12, 2003 at 07:24:12PM +0200, Matthias Urlichs wrote:
> > > Section 11.2 says 
> > > 
> > >   strip --strip-unneeded your-lib
> > This is still true (the section is 10.2 though).
> > 
> > > Lintian, however, complains if the sections .comment or .note are
> > > present, which strip doesn't think are unneeded.
> > This is still true, the tag is binary-has-unneeded-section.
> > Emitted (non-overridden): 537, overridden: 71, total: 608
> > 
> > > I don't know whether this is a bug in policy, strip, or lintian, but
> > > since Debian's "install -s" and dh_strip both use the additional options
> > > 
> > >   --remove-section=.comment --remove-section=.note
> > > 
> > > I think that it's a policy bug.
> > This is still true for dh_strip but not for install -s (since 2005,
> > coreutils 5.93-1).
> 
> So to summary:
> Policy 11.2 recommends:
>   strip --strip-unneeded
> dh_strip does:
>   strip --strip-unneeded --remove-section=.comment --remove-section=.note
> install -s does currently:
>   strip --strip-unneeded
> lintian checks for:
>   strip --strip-unneeded --remove-section=.comment --remove-section=.note
> 
> is that correct ?
> 
> Did 'install -s' used to do 
> 'strip --strip-unneeded --remove-section=.comment --remove-section=.note' ?
> Do we know why it was changed ?
> 
> Cheers,
> -- 
> Bill. 
> 
> Imagine a large red swirl here. 
> 
> 

Hi,

AFAICT, Bill's follow up is nearly a accurate with the following remarks:

 * The Policy section is (now?) 10.2 (plus some bits in 10.1)

 * We now have auto-generated dbgsym packages by dh_strip (which were
   just an idea when Bill wrote that answer).

 * Policy mentions "--remove-section=.comment --remove-section=.note" in
   a footnote as a "You might also want to use ...".

 * Policy section 10.1 implies that "INSTALL = install -s" is a useful
   way of stripping binaries (both in text and examples).  Besides not
   covering the .comment + .note sections it also neuters dh_strip's
   ability to create dbgsym packages.


I think we should update the policy to say that you should use
"--strip-unneeded --remove-section=.comment --remove-section=.note" and
maybe recommend delegating that task (where possible) to dh_strip as it
provide dbgsym packages.

Thanks,
~Niels

Bug#813471: Seeking seconds for patch to permit some network access to localhost

[Niels Thykier]

Sean Whitton:
> Here is a revised patch; David, hopefully you will renew your second.
> 
>> diff --git a/policy/ch-source.rst b/policy/ch-source.rst
>> index 9e7d79c..890c479 100644
>> --- a/policy/ch-source.rst
>> +++ b/policy/ch-source.rst
>> @@ -278,7 +278,8 @@ non-interactive. It also follows that any target that 
>> these targets
>>  depend on must also be non-interactive.
>>
>>  For packages in the main archive, no required targets may attempt
>> -network access.
>> +network access, except, via the loopback interface, to services on the
>> +build host that have been started by the build.
>>
>>  The targets are as follows:
>>

Seconded.

Thanks for the proposal,
~Niels

Bug#813471: Seeking seconds for patch to permit some network access to localhost

[Niels Thykier]

Sean Whitton:
> Hello Niels,
> 
> On Sun 22 Jul 2018 at 09:33AM GMT, Niels Thykier wrote:
> 
>> The proposed text is awkward for me because I basically read it as:
>>
>> ""
>> For packages in the main archive, no required targets may attempt
>> network access, [... exception ...], via the loopback interface.
>> """
>>
>> Which is not at all what I expected to read given the subject.
> 
> I don't follow what's awkward about this; please say more.
> 

Basically I read "No required target may attempt network access via the
loopback interface (except if/when ...).".  To me that implies /only/
the loopback interface is restricted by that sentence (i.e. any other
network interface is not restricted by this sentence).

If there is another saying that no other network interfaces may be used
during the build, then the loopback restriction may be fine.  But the
original sentence sounded like it was the only sentence restricting
network access.

I hope that clarifies the situation for you.

Thanks,
~Niels

Bug#813471: Seeking seconds for patch to permit some network access to localhost

[Niels Thykier]

Sean Whitton:
> control: tag -1 +patch
> 
> Hello,
> 
> Here is a patch, for which I am seeking seconds, that tries to capture
> the points raised by Osamu, Guillem and Paul without getting into
> legalese -- Bill has a point.  In particular, I think we can trust
> package maintainers to interpret "started by the build" sensibly.
> 
> Discussion by Ian and Simon cloned into a separate bug and continued
> there.  Gunnar's discussion should be a separate bug, so setting it
> aside for now.
> 
>> diff --git a/policy/ch-source.rst b/policy/ch-source.rst
>> index 9e7d79c..34c90b3 100644
>> --- a/policy/ch-source.rst
>> +++ b/policy/ch-source.rst
>> @@ -278,7 +278,8 @@ non-interactive. It also follows that any target that 
>> these targets
>>  depend on must also be non-interactive.
>>  
>>  For packages in the main archive, no required targets may attempt
>> -network access.
>> +network access, except to services on the build host that have been
>> +started by the build, via the loopback interface.
>>  
>>  The targets are as follows:
>>  
> 

The proposed text is awkward for me because I basically read it as:

""
For packages in the main archive, no required targets may attempt
network access, [... exception ...], via the loopback interface.
"""

Which is not at all what I expected to read given the subject.


Secondly, my reading of the text enables you to start tor and then talk
with that (and it is not quite clear whether the exception also applies
to the started service).

Maybe something like:

"""
For packages in the main archive, no required targets may attempt
network access (either directly or via services started by the build) on
any interface except for the loopback interface.
"""

(not sure if that hits into the legalese territory you trying to avoid;
I have not read the full discussion)

Thanks,
~Niels

Bug#880920: Document Rules-Requires-Root field

[Niels Thykier]

Sean Whitton:
> [...]

Hi,

Thanks for the updated version.  :)

My second also applies to the re-worded variant quoted below

> Here is the complete new diff for seconding.  Below that, I've included
> the interdiff between the patch Niels seconded and the new one.
> 
>> diff --git a/debian/changelog b/debian/changelog
>> index 2dea331..b89816e 100644
>> --- a/debian/changelog
>> +++ b/debian/changelog
>> @@ -1,5 +1,11 @@
>> -debian-policy (4.1.4.2) UNRELEASED; urgency=medium
>> +debian-policy (4.1.5.0) UNRELEASED; urgency=medium
>>
>> +  * Policy: Document Rules-Requires-Root
>> +Wording: Niels Thykier 
>> +Wording: Guillem Jover 
>> +Wording: Sean Whitton 
>> +Seconded: ...
>> +Closes: #880920
>>* Fix URL to the alioth lists service in footnote (Closes: #896749).
>>  Thanks Martin Zobel-Helas for the report.
>>
>> diff --git a/policy/ch-controlfields.rst b/policy/ch-controlfields.rst
>> index 0771346..3afba4c 100644
>> --- a/policy/ch-controlfields.rst
>> +++ b/policy/ch-controlfields.rst
>> @@ -129,6 +129,8 @@ package) are:
>>
>>  -  :ref:`Testsuite `
>>
>> +-  :ref:`Rules-Requires-Root `
>> +
>>  The fields in the binary package paragraphs are:
>>
>>  -  :ref:`Package ` (mandatory)
>> @@ -1020,6 +1022,118 @@ This field is automatically added to Debian source 
>> control files
>>  field may also be used in source package control files
>>  (``debian/control``) if needed in other situations.
>>
>> +.. _s-f-Rules-Requires-Root:
>> +
>> +``Rules-Requires-Root``
>> +~~~
>> +
>> +Simple field that defines if the source package requires access to
>> +root (or fakeroot) during selected targets in the :ref:`Main building
>> +script: debian/rules `.
>> +
>> +The field can consist of exactly one of the following three items:
>> +
>> + - ``no``: Declares that neither root nor fakeroot is required.
>> +   Package builders (e.g. dpkg-buildpackage) may choose to invoke any
>> +   target in ``debian/rules`` with an unprivileged user.
>> +
>> + - ``binary-targets`` (default): Declares that the package will need
>> +   the root (or fakeroot) when either of the ``binary``,
>> +   ``binary-arch`` or ``binary-indep`` targets are called.  This is
>> +   how every tool behaved before this field was defined.
>> +
>> + - A space separated list of keywords described below.  These keywords
>> +   must always contain a forward slash, which sets them apart from the
>> +   other possible values of ``Rules-Requires-Root``.  When this list
>> +   is provided, the builder must provide a `gain root command` (as
>> +   defined in :ref:`debian/rules and Rules-Requires-Root
>> +   `) *or* pretend that the value was set
>> +   to ``binary-targets``, and both the builder and the package's
>> +   ``debian/rules`` script must downgrade accordingly (see below).
>> +
>> +If the package builder supports the ``Rules-Requires-Root`` field and
>> +wants to enable the feature, then it must set the environment variable
>> +``DEB_RULES_REQUIRES_ROOT`` when invoking the package building script
>> +``debian/rules``.  The value of ``DEB_RULES_REQUIRES_ROOT`` should be
>> +one of:
>> +
>> + * The value of ``Rules-Requires-Root`` if the builder can support
>> +   that value.  The builder may trim unnecessary whitespace used to
>> +   format the field for readability.
>> +
>> + * The value ``binary-targets`` if it cannot support the value of
>> +   ``Rules-Requires-Root``.
>> +
>> +A compliant builder may also leave ``DEB_RULES_REQUIRES_ROOT`` unset
>> +or set it to ``binary-targets`` if it has been requested to test
>> +whether the package it builds correctly implements the fall-back for
>> +legacy builders.
>> +
>> +Remarks
>> +^^^
>> +
>> +All packages and builders must support ``binary-targets`` as this was
>> +the historical behaviour prior to the introduction of this field.
>> +
>> +Any tool (particularly older versions of them) may be unaware of this
>> +field and behave like the field was set to ``binary-targets``.  The
>> +package build must gracefully cope with this and produce a
>> +semantically equivalent result.
>> +
>> +This field intentionally does not enable a package to request a true
>> +root over fakeroot.
>> +
>> +Definition of the keywords
>> +^^
>> +
>> +The keywords have the format ``/``, where:
>> +
>> + *  must consist entirely of printabl

Re: missing recommends are not RC severity

[Niels Thykier]

Russ Allbery:
> Holger Levsen  writes:
> 
> [...]
> 
> Release folks, why this exception in the release policy?  Are you
> comfortable with Debian releasing with packages that Recommend packages
> that aren't part of the release?  (Have we historically done this?)
> 

Hi,

Thanks for the questions.  I brought it up on the last Release Team IRC
meeting[1].

To my knowledge, we have never enforced Recommends being
installable/present in testing.  As such it is safe to assume that we
have made releases where packages had recommends that could not be
satisfied (to answer your second and third question first).

The exception to the RC bug policy appears to be older than most of the
RT members in the team today.  I got two versions of the rationale,
which I will include below (as I understood them at least).
  One version appeared to be that missing recommends do not cause issues
during an "apt install" (and therefore needed not be RC)[2]. The other
was that if it is going to be RC, then the tooling should enforce it
(and it should not affect development speed considerably)[3].


As I understood it, we are open to discussing changing the policy.
However, if we are planning to make "unavailable Recommends"[4] an RC
bug then we will need to determine the scope of the problem (how many
packages get RC buggy with the given definition) and enforce the change
in britney to avoid automatic regressions in testing[5].

Thanks,
~Niels

[1]
http://meetbot.debian.net/debian-release/2018/debian-release.2018-05-23-19.01.html

[2]
http://meetbot.debian.net/debian-release/2018/debian-release.2018-05-23-19.01.log.html#l-23

[3] Given by vorlon on IRC after the meeting and therefore not present
in the log.

[4] Regardless of whether we define that as "Recommends:
" or " Recommends:
" or "all of the above".

[5] Note that britney currently do not validate "(Build-)Depends"
between components directly.  Historically it has been less of a problem
as these problems tend to get RC bugs/blocked via other means.

Bug#880920: Document Rules-Requires-Root field

[Niels Thykier]

Sean Whitton:
> control: tag -1 +patch
> 
> Hello,
> 
> Seeking one further second (on top of those from Niels and I) to the
> following diff:
> 

As mentioned, I already seconded it.  However, my mail was not signed
and for avoidance of doubt, I am hereby seconding it with a signed message.

@Sean: Also, I spotted a typo of "particularly" highlighted below that I
missed in the previous review.

>> diff --git a/debian/changelog b/debian/changelog
>> index 2dea331..b89816e 100644
>> --- a/debian/changelog
>> +++ b/debian/changelog
>> @@ -1,5 +1,11 @@
>> -debian-policy (4.1.4.2) UNRELEASED; urgency=medium
>> +debian-policy (4.1.5.0) UNRELEASED; urgency=medium
>>
>> +  * Policy: Document Rules-Requires-Root
>> +Wording: Niels Thykier <ni...@thykier.net>
>> +Wording: Guillem Jover <guil...@debian.org>
>> +Wording: Sean Whitton <spwhit...@spwhitton.name>
>> +Seconded: ...
>> +Closes: #880920
>>* Fix URL to the alioth lists service in footnote (Closes: #896749).
>>  Thanks Martin Zobel-Helas for the report.
>>
>> diff --git a/policy/ch-controlfields.rst b/policy/ch-controlfields.rst
>> index 0771346..3519d99 100644
>> --- a/policy/ch-controlfields.rst
>> +++ b/policy/ch-controlfields.rst
>> @@ -129,6 +129,8 @@ package) are:
>>
>>  -  :ref:`Testsuite `
>>
>> +-  :ref:`Rules-Requires-Root `
>> +
>>  The fields in the binary package paragraphs are:
>>
>>  -  :ref:`Package ` (mandatory)
>> @@ -1020,6 +1022,118 @@ This field is automatically added to Debian source 
>> control files
>>  field may also be used in source package control files
>>  (``debian/control``) if needed in other situations.
>>
>> +.. _s-f-Rules-Requires-Root:
>> +
>> +``Rules-Requires-Root``
>> +~~~
>> +
>> +Simple field that defines if the source package requires access to
>> +root (or fakeroot) during selected targets in the :ref:`Main building
>> +script: debian/rules `.
>> +
>> +The field can consist of exactly one of the following three items:
>> +
>> + - ``no``: Declares that neither root nor fakeroot is required.
>> +   Package builders (e.g. dpkg-buildpackage) may choose to invoke any
>> +   target in ``debian/rules`` with an unprivileged user.
>> +
>> + - ``binary-targets`` (default): Declares that the package will need
>> +   the root (or fakeroot) when either of the ``binary``,
>> +   ``binary-arch`` or ``binary-indep`` targets are called.  This is
>> +   how every tool behaved before this field was defined.
>> +
>> + - A space separated list of keywords described below.  These must
>> +   always contain a forward slash, which sets them apart from the
>> +   other values.  When this list is provided, the builder must provide
>> +   a `gain root command` (as defined in :ref:`debian/rules and
>> +   Rules-Requires-Root `) *or* pretend that
>> +   the value was set to ``binary-targets``, and both the builder and
>> +   the package's ``debian/rules`` script must downgrade accordingly
>> +   (see below).
>> +
>> +If the package builder supports the ``Rules-Requires-Root`` field and
>> +want to enable the feature, then it must set the environment variable
>> +``DEB_RULES_REQUIRES_ROOT`` when invoking the package building script
>> +``debian/rules``.  The value of ``DEB_RULES_REQUIRES_ROOT`` should be
>> +one of:
>> +
>> + * The value of ``Rules-Requires-Root`` if the builder can support
>> +   that value.  The builder may trim unnecessary whitespace used to
>> +   format the field for readability.
>> +
>> + * The value ``binary-targets`` if it cannot support the value of
>> +   ``Rules-Requires-Root``.
>> +
>> +A compliant builder may also leave ``DEB_RULES_REQUIRES_ROOT`` unset
>> +or set it to ``binary-targets`` if it has been requested to test
>> +whether the package it builds correctly implements the fall-back for
>> +legacy builders.
>> +
>> +Remarks
>> +^^^
>> +
>> +All packages and builders must support ``binary-targets`` as this was
>> +the historical behaviour prior to the introduction of this field.
>> +
>> +Any tool (partiularly older versions of them) may be unaware of this
  ^^^

Typo of particularly

>> +field and behave like the field was set to ``binary-targets``.  The
>> +package build must gracefully cope with this and produce a
>> +semantically equivalent result.
>> +
>> +This field intentionally does not enable a package to request a true
>> 

Bug#880920: Document Rules-Requires-Root field

[Niels Thykier]

Sean Whitton:
> Hello Niels,
> 
> On Sun, Feb 25 2018, Niels Thykier wrote:
> 
>> Attached is my updated draft along with a changes since the previous
>> draft.
> 
> Thank you for this!  Let's get this into a release of the Policy Manual.
> 

Hi,

Thanks for cleaning up the text. :)

> I've pushed a bug880920-spwhitton branch to the Policy repo for you to
> review.  Aside from a single substantive change explained below, all my
> commits are rewordings for clarity and readability.  My commit messages
> should explain them.
> 
> It would be most efficient if you could base new patches on my
> bug880920-spwhitton branch.  Once we are happy with that branch, we can
> prepare a diff of the whole branch and post that to this bug to seek
> seconds, and then just merge the branch.
> 
Hi,

I have reviewed the commits on the branch (with HEAD at
efa61ef2c2580ac9a3c4ba2f0756249b4c862989) and I am happy with the
individual changes you have done on top of my initial proposal.

>From my PoV, I think it is ready for seconding/wider review and I am
happy to support/second it.

>> +The builder should set ``DEB_RULES_REQUIRES_ROOT`` environment
>> +variable when calling any of the mandatory targets as defined in
>> +:ref:`Rules-Requires-Root `.  If the
>> variable +is not set, the package must behave as if it was set to
>> +``binary-targets``.
>> +
> 
> I think s/should/may/ in the first line -- can you explain why you think
> it is worth enforcing this upon every build tool that might ever be
> uploaded to Debian, given that there exists a solid fallback?
> 

I am fine with it being relaxed to a "may", as I think documenting R³ is
more important than whether supporting is subject to a "should" or a "may".

Thanks,
~Niels

Bug#895136: debian-policy: §9.1.2 - Contains example that is misleadingly different than what the policy mandates

[Niels Thykier]

Niels Thykier:
> """
> if [ ! -e /usr/local/share/emacs ]; then
> if mkdir /usr/local/share/emacs 2>/dev/null; then
> if test -e /etc/staff-group-for-usr-local ; then
> if chown root:staff /usr/local/share/emacs; then
> chmod 2775 /usr/local/share/emacs || true
> fi
> elif chown root:staff /usr/local/share/emacs; then
> chmod 2775 /usr/local/share/emacs || true
> fi
> fi
> fi
> """

Bleh, I wanted:

"""
if [ ! -e /usr/local/share/emacs ]; then
if mkdir /usr/local/share/emacs 2>/dev/null; then
if test -e /etc/staff-group-for-usr-local ; then
if chown root:staff /usr/local/share/emacs; then
chmod 2775 /usr/local/share/emacs || true
fi
elif chown root:root /usr/local/share/emacs; then
chmod 0755 /usr/local/share/emacs || true
fi
fi
fi
"""

Apologies for the confusion.

Thanks,
~Niels

Bug#895136: debian-policy: §9.1.2 - Contains example that is misleadingly different than what the policy mandates

[Niels Thykier]

Package: debian-policy
Version: 4.1.4
Severity: normal

Last paragraph of 9.1.2 reads:

"""
If /etc/staff-group-for-usr-local does not exist, /usr/local and all
subdirectories created by packages should have permissions 0755 and be
owned by root:root. If /etc/staff-group-for-usr-local exists,
/usr/local and subdirectories should have permissions 2775
(group-writable and set-group-id) and be owned by root:staff.
"""

In the middle of 9.1.2, there is the following example of how to do
directory creation in /usr/local:

"""
if [ ! -e /usr/local/share/emacs ]; then
if mkdir /usr/local/share/emacs 2>/dev/null; then
if chown root:staff /usr/local/share/emacs; then
chmod 2775 /usr/local/share/emacs || true
fi
fi
fi
"""

The example is way too simple to comply with policy.  A more compliant
example would be:

"""
if [ ! -e /usr/local/share/emacs ]; then
if mkdir /usr/local/share/emacs 2>/dev/null; then
if test -e /etc/staff-group-for-usr-local ; then
if chown root:staff /usr/local/share/emacs; then
chmod 2775 /usr/local/share/emacs || true
fi
elif chown root:staff /usr/local/share/emacs; then
chmod 2775 /usr/local/share/emacs || true
fi
fi
fi
"""

Thanks,
~Niels

Bug#880920: RFC: Support for selective usage of (fake)root during package build (R³)

[Niels Thykier]

Niels Thykier:
> 
> Sean Whitton:
>> Hello,
>>
>> On Sun, Jan 21 2018, Guillem Jover wrote:
>>
>>> Ok, there were some comments provided, and some important omissions
>>> were spotted. I'm attaching the diff for those changes, which mark now
>>> the spec as a stable recommendation with 1.19.0.5.
>>
>> Sounds like this invalidates Niels' patch against Policy?
>>
> 
> Indeed, my patch will require some editorial changes.
> 
> Thanks,
> ~Niels
> 
> 

Hi,

Attached is my updated draft along with a changes since the previous draft.

Please CC me on remarks/request for changes: I nearly missed the
comments about making it explicit that "gain root command" should
preserve the environment variables.

Thanks,
~Niels
>From 1ef3ac1141c08361f4e2da81b9a0994ade411ff9 Mon Sep 17 00:00:00 2001
From: Niels Thykier <ni...@thykier.net>
Date: Fri, 29 Dec 2017 11:28:08 +
Subject: [PATCH] Initial draft for Rules-Requires-Root

Signed-off-by: Niels Thykier <ni...@thykier.net>
---
 policy/ch-controlfields.rst | 110 
 policy/ch-source.rst|  53 -
 2 files changed, 162 insertions(+), 1 deletion(-)

diff --git a/policy/ch-controlfields.rst b/policy/ch-controlfields.rst
index 0771346..7fc9216 100644
--- a/policy/ch-controlfields.rst
+++ b/policy/ch-controlfields.rst
@@ -129,6 +129,8 @@ package) are:
 
 -  :ref:`Testsuite `
 
+-  :ref:`Rules-Requires-Root `
+
 The fields in the binary package paragraphs are:
 
 -  :ref:`Package ` (mandatory)
@@ -1020,6 +1022,114 @@ This field is automatically added to Debian source control files
 field may also be used in source package control files
 (``debian/control``) if needed in other situations.
 
+.. _s-f-Rules-Requires-Root:
+
+``Rules-Requires-Root``
+~~~
+
+Simple field that defines if the source package requires access to
+root (or fakeroot) during selected targets in the :ref:`Main building
+script: debian/rules `.
+
+The field can consist of exactly one of either of the following:
+
+ - ``no``: Declares that neither root nor fakeroot is required.
+   Package builders (e.g. dpkg-buildpackage) may choose to invoke any
+   target in ``debian/rules`` with an unprivileged user.
+
+ - ``binary-targets`` (default): Declares that the package will need
+   the root (or fakeroot) when either of the ``binary``,
+   ``binary-arch`` or ``binary-indep`` targets are called.  This is
+   how every tool behaved before this field was defined.
+
+ - A space separated list of keywords described below.  These must
+   always contain a forward slash, which sets them apart from the
+   other values.  When this list is provided, the builder must provide
+   a `gain root command` (as defined in :ref:`debian/rules - Gain root
+   api for Rules-Requires-Root `) *or*
+   pretend that the value was set to ``binary-targets`` and both
+   parties must degrade accordingly (see below).
+
+If the package builder supports the field and want to enable the
+feature, then it must set the environment variable
+``DEB_RULES_REQUIRES_ROOT`` when invoking the package building script
+``debian/rules``.  The value of ``DEB_RULES_REQUIRES_ROOT`` should be
+one of:
+
+ * The same value as the ``Rules-Requires-Root`` if the builder can
+   provide the necessary support.  The builder may trim unnecessary
+   whitespace used to format the field for readability.
+
+ * The value ``binary-targets`` if it cannot provide the necessary
+   support.
+
+All packages and builders must support ``binary-targets`` as this was
+the historical behaviour prior to the introduction of this field.
+
+Please note that any tool (partiularly older versions of them) may be
+unaware of this field and behave like the field was set to
+``binary-targets``.  The package build must gracefully cope with this
+and produce the same semantical result regardless.
+
+A compliant builder may also leave ``DEB_RULES_REQUIRES_ROOT`` unset
+or set it to ``binary-targets`` if it has been requested to test
+whether the package it builds correctly implements the fall-back for
+legacy builders.
+
+This field intentionally does not enable a package to request a true
+root over fakeroot.
+
+**Definition of the keywords**:
+
+The keywords have the format ``/``, where:
+
+ *  must consist entirely of printable ASCII characters
+   except for any whitespace and the forward slash (``/``).  It must
+   consist of at least 2 characters.
+
+ * ``/`` (between  and ) is a single ASCII
+   forward slash.
+
+ *  must consist entirely of printable ASCII characters
+   except for any whitespace.  It must consist of at least 2
+   characters.
+
+These keywords define where the package build script (or the tools
+called from it) will need access to root or fakeroot.  If ``debian/rules``
+directly needs to invoke a tool as root or under fakeroot, then it must
+

Bug#880920: RFC: Support for selective usage of (fake)root during package build (R³)

[Niels Thykier]

Sean Whitton:
> Hello,
> 
> On Sun, Jan 21 2018, Guillem Jover wrote:
> 
>> Ok, there were some comments provided, and some important omissions
>> were spotted. I'm attaching the diff for those changes, which mark now
>> the spec as a stable recommendation with 1.19.0.5.
> 
> Sounds like this invalidates Niels' patch against Policy?
> 

Indeed, my patch will require some editorial changes.

Thanks,
~Niels

Bug#880920: Document Rules-Requires-Root field

[Niels Thykier]

On Wed, 08 Nov 2017 18:20:59 -0700 Sean Whitton
<spwhit...@spwhitton.name> wrote:
> Hello Ian,
> 
> On Wed, Nov 08 2017, Ian Jackson wrote:
> 
> > Sean Whitton writes ("Bug#880920: Document Rules-Requires-Root
> >field"):
> >> I wonder if we should just make Policy the new home of the spec that
> >> Niels and Guillem have already written?
> >
> > I certainly would rather not block incorporation of this new spec into
> > Debian's official document set, on the task of reformatting it into
> > docbook.
> >
> > So yes it should probably go into the policy package (since there is
> > no better home for it).
> 
> Given that we are now rST I think we should not just dump the spec into
> the policy package, but hold out on a patch to the manual itself, since
> writing such a thing is not very hard at all.
> 
> -- 
> Sean Whitton

Hi,

Here is an initial draft for how I think it could look.

Review welcome.

Thanks,
~Niels
>From 337d56b25eadd4dd0d80f30019e9b837dbf01210 Mon Sep 17 00:00:00 2001
From: Niels Thykier <ni...@thykier.net>
Date: Fri, 29 Dec 2017 11:28:08 +
Subject: [PATCH] Initial draft for Rules-Requires-Root

Signed-off-by: Niels Thykier <ni...@thykier.net>
---
 policy/ch-controlfields.rst | 90 +
 policy/ch-source.rst| 46 ++-
 2 files changed, 135 insertions(+), 1 deletion(-)

diff --git a/policy/ch-controlfields.rst b/policy/ch-controlfields.rst
index 0771346..5310813 100644
--- a/policy/ch-controlfields.rst
+++ b/policy/ch-controlfields.rst
@@ -129,6 +129,8 @@ package) are:
 
 -  :ref:`Testsuite `
 
+-  :ref:`Rules-Requires-Root `
+
 The fields in the binary package paragraphs are:
 
 -  :ref:`Package ` (mandatory)
@@ -1020,6 +1022,94 @@ This field is automatically added to Debian source control files
 field may also be used in source package control files
 (``debian/control``) if needed in other situations.
 
+.. _s-f-Rules-Requires-Root:
+
+``Rules-Requires-Root``
+~~~
+
+Simple field that defines if the source package requires access to
+root (or fakeroot) during selected targets in the :ref:`Main building
+script: debian/rules `.
+
+The field can consist of exactly one of either of the following:
+
+ - ``no``: Declares that neither root nor fakeroot is required.
+   Package builders (e.g. dpkg-buildpackage) may choose to invoke any
+   target in ``debian/rules`` with an unprivileged user.
+
+ - ``binary-targets`` (default): Declares that the package will need
+   the root (or fakeroot) when either of the ``binary``,
+   ``binary-arch`` or ``binary-indep`` targets are called.  This is
+   how every tool behaved before this field was defined.
+
+ - A space separated list of keywords described below.  These must
+   always contain a forward slash, which sets them apart from the
+   other values.  When this list is provided, the builder must provide
+   a `gain root command` (as defined in :ref:`debian/rules - Gain root
+   api for Rules-Requires-Root `) *or*
+   pretend that the value was set to ``binary-targets`` and both
+   parties must degrade accordingly (see below).
+
+Please note that any tool (partiularly older versions of them) may be
+unaware of this field and behave like the field was set to
+``binary-targets``.  The package build must gracefully cope with this
+and produce the same semantical result regardless.  The value of this
+field must not degrade if a builder tool invokes the package build
+
+This field intentionally does not enable a package to request a true
+root over fakeroot.
+
+**Definition of the keywords**:
+
+The keywords have the format ``/``, where:
+
+ *  must consist entirely of printable ASCII characters
+   except for any whitespace and the forward slash (``/``).  It must
+   consist of at least 2 characters.
+
+ * ``/`` (between  and ) is a single ASCII
+   forward slash.
+
+ *  must consist entirely of printable ASCII characters
+   except for any whitespace.  It must consist of at least 2
+   characters.
+
+These keywords define where the package build script (or the tools
+called from it) will need access to root or fakeroot.  If ``debian/rules``
+directly needs to invoke a tool as root or under fakeroot, then it must
+use the keyword ``dpkg/target-subcommand``.
+
+Furthermore, each tool or package may claim its own namespace named
+after it and create keywords based on that namespace.  The tool may
+use the `gain root command` to perform a given action as root or under
+fakeroot if (but only if) a package lists of said keyword in the
+``Rules-Requires-Root`` field.
+
+All tools must ignore keywords with namespaces they do not know or
+own.  A tool may choose warn or abort with an error if it finds
+unknown keywords in namespaces it provides or owns (but it is not
+required to this for all keywords in the namespace).

Bug#515856: [debhelper-devel] Bug#515856: debhelper: please implement dh get-orig-source

[Niels Thykier]

On Mon, 18 Sep 2017 11:04:04 +0200 Holger Levsen 
wrote:
> On Fri, Sep 01, 2017 at 06:52:27AM +0200, Helmut Grohne wrote:
> [...]
> > diff --git a/policy/ch-source.rst b/policy/ch-source.rst
> > index f706a13..27c49b5 100644
> > --- a/policy/ch-source.rst
> > +++ b/policy/ch-source.rst
> > @@ -368,19 +368,6 @@ The targets are as follows:
> >  Instead, the upstream source should be repacked to remove those
> >  files.
> >  
> > -``get-orig-source`` (optional)
> > -This target fetches the most recent version of the original source
> > -package from a canonical archive site (via FTP or WWW, for example),
> > -does any necessary rearrangement to turn it into the original source
> > -tar file format described below, and leaves it in the current
> > -directory.
> > -
> > -This target may be invoked in any directory, and should take care to
> > -clean up any temporary files it may have left.
> > -
> > -This target is optional, but providing it if possible is a good
> > -idea.
> > -
> 
> seconded.
> 
> 
> -- 
> cheers,
>   Holger

I second this change as well.

Thanks,
~Niels



signature.asc
Description: OpenPGP digital signature

Bug#630174: debian-policy: forbid installation into /lib64

[Niels Thykier]

On Tue, 9 Jun 2015 23:00:51 +0200 Bill Allombert 
wrote:
>[...]
> 
> OK, here a new patch.
> 
> Seconds welcome!
> 
> Cheers,
> -- 
> Bill. 
> 
> Imagine a large red swirl here. 

Hi,

I second the following change proposed by Bill:

> diff --git a/policy.sgml b/policy.sgml
> index 404dc73..f9fdbf7 100644
> --- a/policy.sgml
> +++ b/policy.sgml
> @@ -6955,12 +6955,13 @@ Built-Using: grub2 (= 1.99-9), loadlin (= 1.6e-1)
>character.
>  
>
>
>  
> -  The requirement for amd64 to use /lib64
> -  for 64 bit binaries is removed.
> +  The requirement for amd64 to use /lib64 for
> +  64 bit binaries is removed. Only the dynamic linker is
> +  allowed to use this directory.
>  
>
>
>  
>The requirement for object files, internal binaries, and
> @@ -6983,10 +6984,14 @@ Built-Using: grub2 (= 1.99-9), loadlin (= 1.6e-1)
>  use in cross-installation of library packages from other
>  architectures, as part of multiarch.
>
>  
>  
> +  No package for a 64 bit architecture may install files
> +  in /usr/lib64/ or in a subdirectory of it.
> +
> +
>The requirement for C and C++ headers files to be
>accessible through the search path
>/usr/include/ is amended, permitting files to
>be accessible through the search path
>/usr/include/triplet where

Thanks,
~Niels




signature.asc
Description: OpenPGP digital signature

Bug#798476: Bug#870788: Extract recent uploaders from d/changelog

[Niels Thykier]

Adrian Bunk:
> On Fri, Aug 04, 2017 at 06:13:09PM -0700, Sean Whitton wrote:
>> Package: tracker.debian.org
>> Severity: wishlist
>>
>> On Thu, Aug 03 2017, Holger Levsen wrote:
>>
>>> Then, Tobias has a point, knowing which team members uploaded a package is
>>> useful. So I have a simple proposal to achieve that: make tracker.d.o
>>> show the last 10 uploaders for a given package (based on UDD), just like it
>>> parses the Uploaders: field from the packages now.
>>
>> Such a feature would move this discussion forward, so I'm submitting it
>> as a feature request.
>>
>> I think that the logic in who-uploads(1) is probably insufficient;
>> parsing d/changelog would catch people actually /contributing/ to the
>> package, not just those who signed the uploads.
> 
> I assume you are thinking of parsing the [ name ] syntax used by many teams.
> 
> Note that a prerequisite for such debian/changelog parsing would
> be that policy sets strict syntax and semantics requirements.
> 
> Examples:
> 
> Some teams use different syntax.
> I did already state in the policy bug that extracting this information 
> from the lintian changelog is my challenge to everyone who thinks that 
> that this could be extracted from current debian/changelog.
> 
> This can only work if policy states that that the established practice 
> of many people using this syntax also for patch submitters is no longer 
> permitted.
> 
> cu
> Adrian
> 

The syntax used in lintian's changelog is relatively unique to my
knowledge; if by changing it we can actually have this proposal work,
then let me know and I will raise that internally in the lintian team.

Thanks,
~Niels

Bug#758234: debian-policy: allow packages to depend on packages of lower priority

[Niels Thykier]

On Sun, 25 Jun 2017 15:54:00 -0700 Russ Allbery  wrote:
> Ansgar Burchardt  writes:
> 
> > I discussed this a bit on IRC with the other ftp-masters and we came to
> > this summary:
> 
> > 0) We would like to drop the requirement for packages to not depend on
> >packages of lower priority: it is better to declare only what we
> >actually want included in the installation (that is at priority >=
> >standard) rather than also the dependency closure.
> 
> > 1) We agree that the 'extra' priority can be dropped.
> 
> > 2) We wonder if the 'standard' priority can also be dropped: as far as
> >we know, it is used only by the "standard" task and it might make
> >sense to treat it the same as other tasks.
> >(Depending on what works better for the installer team.)
> 

Hi,

Thanks for this draft.

> Given KiBi's reply, I'll leave 2 out for now.
> 

Seems reasonable to me. :)

> [...]
> 
> Note that this also says that no two packages that both have a priority of
> standard or higher may conflict.  I think that's a logical consequence of
> the use of priorities, and didn't want to lose that completely when that
> requirement was dropped from optional.
> 

Agreed.

I second the change below.  Please notify me/the lintian maintainers
if/when it is merged, so we can update the relevant checks in lintian.

> diff --git a/policy.xml b/policy.xml
> index ace6a3b..be458cd 100644
> --- a/policy.xml
> +++ b/policy.xml
> @@ -837,11 +837,33 @@
>Priorities
>  
>
> -Each package should have a priority value,
> -which is included in the package's control
> -record (see ).  This
> -information is used by the Debian package management tools to
> -separate high-priority packages from less-important packages.
> +Each package must have a priority value,
> +which is set in the metadata for the Debian archive and is also
> +included in the package's control files (see  +linkend="s-f-Priority"/>).  This information is used to control
> +which packages are included in standard or minimal Debian
> +installations.
> +  
> +  
> +Most Debian packages will have a priority of
> +optional.  Priority levels other than
> +optional are only used for packages that should
> +be included by default in a standard installation of Debian.
> +  
> +  
> +The priority of a package is determined solely by the
> +functionality it provides directly to the user.  The priority of a
> +package should not be increased merely because another
> +higher-priority package depends on it; instead, the tools used to
> +construct Debian installations will correctly handle package
> +dependencies.  In particular, this means that C-like libraries
> +will almost never have a priority above
> +optional, since they do not provide
> +functionality directly to users.  However, as an exception, the
> +maintainers of Debian installers may request an increase of the
> +priority of a package to resolve installation issues and ensure
> +that the correct set of packages is included in a standard or
> +minimal install.
>
>
>  The following priority levels are recognized
> @@ -896,19 +922,22 @@
>installed by default if the user doesn't select anything
>else.  It doesn't include many large applications.
>  
> +
> +  No two packages that both have a priority of
> +  standard or higher may conflict with each
> +  other.
> +
>
>  
>  
>optional
>
>  
> -  (In a sense everything that isn't required is optional, but
> -  that's not what is meant here.) This is all the software
> -  that you might reasonably want to install if you didn't know
> -  what it was and don't have specialized requirements.  This
> -  is a much larger system and includes the X Window System, a
> -  full TeX distribution, and many applications.  Note that
> -  optional packages should not conflict with each other.
> +  This is the default priority for the majority of the
> +  archive.  Unless a package should be installed by default on
> +  standard Debian systems, it should have a priority of
> +  optional.  Packages with a priority of
> +  optional may conflict with each other.
>  
>
>  
> @@ -916,22 +945,21 @@
>extra
>
>  
> -  This contains all packages that conflict with others with
> -  required, important, standard or optional priorities, or are
> -  only likely to be 

Bug#640263: debian-policy: Clarify policy section 9.9 - Environment variables

[Niels Thykier]

On Sun, 25 Jun 2017 14:58:06 -0700 Russ Allbery  wrote:
> Russ Allbery  writes:
> 
> > Looking at this section, there are several issues.  One is the issue
> > addressed above, and I like Jonathan's wording for that.  Another is the
> > one Colin mentioned earlier: this only applies to programs installed in
> > the system path.  (I considered saying programs intended to be directly
> > invoked by users, but I can imagine pointless arguments about /usr/sbin
> > programs, so let's just go with that.)  A third issue is that parts of
> > that section are now out of date, since /etc/profile.d exists (but still
> > shouldn't be used for this purpose).
> 
> > I propose the attached patch to address all of those issues.  Seconds or
> > further discussion?
> 
> Hi folks,
> 
> Everyone seemed generally happy with this text, but it never clearly got
> enough seconds to apply.  Here's an updated patch so that we can take
> another run at getting enough seconds and getting it merged.
> 

Seconded,  thanks for writing it. :)

> diff --git a/policy.xml b/policy.xml
> index 7ba5fc0..ace6a3b 100644
> --- a/policy.xml
> +++ b/policy.xml
> @@ -9352,11 +9352,14 @@ Reloading description 
> configuration...done.
>Environment variables
>  
>
> -A program must not depend on environment variables to get
> -reasonable defaults.  (That's because these environment variables
> -would have to be set in a system-wide configuration file like
> -/etc/profile, which is not supported by all
> -shells.)
> +Programs installed on the system PATH (/bin,
> +/usr/bin, /sbin,
> +/usr/sbin, or similar directories) must not
> +depend on custom environment variable settings to get reasonable
> +defaults.  This is because such environment variables would have
> +to be set in a system-wide configuration file such as a file in
> +/etc/profile.d, which is not supported by all
> +shells.
>
>
>  If a program usually depends on environment variables for its
> @@ -9364,7 +9367,7 @@ Reloading description 
> configuration...done.
>  reasonable default configuration if these environment variables
>  are not present.  If this cannot be done easily (e.g., if the
>  source code of a non-free program is not available), the program
> -must be replaced by a small "wrapper" shell script which sets the
> +must be replaced by a small "wrapper" shell script that sets the
>  environment variables if they are not already defined, and calls
>  the original program.
>
> @@ -9377,12 +9380,6 @@ BAR=${BAR:-/var/lib/fubar}
>  export BAR
>  exec /usr/lib/foo/foo "$@"
>
> -  
> -Furthermore, as /etc/profile is a
> -configuration file of the base-files package,



signature.asc
Description: OpenPGP digital signature

Bug#787816: Replace FHS 2.3 by FHS 3.0 in the Policy.

[Niels Thykier]

On Fri, 5 Jun 2015 20:43:10 +0900 Charles Plessy  wrote:
> Package: debian-policy
> Severity: normal
> 
> Le Thu, Jun 04, 2015 at 07:09:00PM -0700, Russ Allbery a écrit :
> > I have not looked at this at all, but this list should be aware that it
> > exists.
> 
> > Date: Wed, 03 Jun 2015 09:19:04 -0400
> > Subject: [fhs-discuss] FHS 3.0
> > 
> > The LSB workgroup is happy to announce the release of FHS 3.0.
> ... 
> > Release notes can be found here:
> > 
> > https://wiki.linuxfoundation.org/en/FHSReleaseNotes30
> 
> Thanks Russ for the heads-up.
> 
> Judging from the release notes, it would not be too hard to update the 
> Policy's
> description of how Debian follows and deviates from the FHS.
> 
> By the way, I wonder if the debian-policy package is the best place for
> shipping a copy of the FHS.  I just checked out the bzr repository that
> contains its sources, and it builds out of the box (build-depends on xmlto and
> fop).  Perhaps it would deserve its own package ?
> 
> Have a nice day,
> 
> Charles
> 
> -- 
> Charles Plessy
> Tsurumi, Kanagawa, Japan
> 
> 

Hi,

I would like to see FHS 3.0 adopted as well.  Or an 2.3 exception to
allow the use of /usr/libexec.

Thanks,
~Niels

Bug#758234: another nasty fallout of this requirement

[Niels Thykier]

On Tue, 06 Dec 2016 15:54:46 +0100 Ansgar Burchardt 
wrote:
> On Sat, 2016-12-03 at 06:33 +0100, Adam Borowski wrote:
> > And to actually fix the issues, instead of merely dropping the
> > mention and
> > thus making the dependencies last forever because of inertia, I urge
> > you to
> > go all the way from "priority of rdepends MUST be raised" all the way
> > to
> > "priority of rdepends MUST NOT be raised, every package is to be
> > evaluated
> > only based on what it directly brings to the user (elevation possibly
> > _moved_ to a metapackage/etc but never copied the other way)" (maybe
> > just a
> > SHOULD NOT for a transitional period).
> 
> I think this should be a "SHOULD NOT":
> 
> The main consumer of the priority information is the installer
> (debootstrap) which has only a very limited dependency resolver.  It
> might be necessary to raise the priority of dependencies to make sure
> it does the right thing (I don't think we need this currently, but we
> should keep the option open in case it turns out we need it).
> 
> Ansgar
> 
> 

Hi,

I support this (with "SHOULD NOT").

Thanks,
~Niels




signature.asc
Description: OpenPGP digital signature

Bug#767839: debian-policy: Linking documentation of arch:any package to arch:all

[Niels Thykier]

b...@debian.org:
> Hi,
> 

Hi,

Relying as the debhelper maintainer.

Let me start by answering, where we are now (in compat 10).  In compat
10, we got a simple narrow permitted set, where we can say:

 * The selections are /known/ to work in all cases.
 * They are simple to implement (correctly).
 * It is simple to understand when you can apply it
   ("all -> all" OR "any -> any")
 * debhelper rejects known cases that it does not support correctly

The last part is missing in earlier compat levels.

> There are a few new bugs related to this, perhaps because it's common
> practice in game packages, that split  and -data,
> and move all the doc to -data.
> 
> I ended here reading:
> https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=857974#15
> "That is broken by design: #766711"
> though apparently this is more a problem of implementation rather than
> a design issue.
> 

It is a common perception among people who are quite happy with
--link-doc that is "just an implementation issue".  Unfortunately, from
the implementation PoV there are some fundamental design issues that a
lot of people are not aware of.

Especially, if you want to keep both design and implementation simple.
I will get to that below.

> I see that DH now generates an error with compat=10, but the
> documentation doesn't hint at this issue.
> 

Correct on debhelper erroring out in compat 10.

 * It is the first time that (I remember where) someone has mentioned
   that the documentation is inadequate.

 * Please file a bug against debhelper on what you are missing from the
   documentation.  You are almost certainly right on this; just let me
   know what I have overlooked.

Originally we wanted to error out in compat 9, but only during a binNMU.
 Unfortunately we could make the detection work correctly so it had too
many false-positives (although in hindsight I think I could do a follow
up with less issues now).

> Also AFAICS the current binNMU changelogs created with such a
> configuration are lost (the binary package just contain the 
> -> -data symlink and no changelog.).
> This looks like the main/only issue to me.
> 

Unfortunately, this is a common misconception.  But lets dig deeper to
understand the issue.

It is correct that if we did an:
arch:any () -> arch:all (-data)
link-doc, we would have to ensure that the changelog.arch file was
included / preserved so it appeared in the arch:all's doc dir despite
being provided by the arch:any file.

But then what happens when /two/ (or more) arch:any packages want to use
the same arch:all with --link-doc.  Now they both install the same file
to the same location which causes a file-conflict.   Still RC, still
broken and still "debhelper's fault".
  Also, this reveals that the previous part of pushing the
changelog.$arch file through the symlink must /only/ occur if the target
is arch:all.  Otherwise you bust arch:any -> arch:any link-docs on
binNMUs as well (another RC bug just around the corner).

And you might think that debhelper would be able to detect these cases
reliably.  However, that gets extra complicated as debhelper cannot rely
on this being in the same dh_installdocs call, because you can do stuff
like:

  dh_installdocs -ppkg1 --link-doc=pkg-data
  dh_installdocs -ppkg2 --link-doc=pkg-data
  ...
  dh_installdocs -ppkgN --link-doc=pkg-data


Plus then --link-doc becomes even more magical to understand.  You can
do all -> all, any -> any and any -> all, but the latter only works for
one pkg (while the rest works for "unlimited" numbers).  Without
mentioning the people lobbying for support for arch:all -> arch:any.


Compare this to what is supported in compat 10:

 * The selections are /known/ to work in all cases.
 * They are simple to implement (correctly).
 * It is simple to understand when you can apply it
   ("all -> all" OR "any -> any")
 * Unsupported cases are rejected at built time (and thus never reach
   the archive).

This is so much easier to deal with as a consumer and for me as the one
having to support it.  I am sorry it excludes your desired state, but
that unfortunately fails at least 2 out of bullets of the above.

> Would you provide a status update?
> (are changes/clarifications planned?)
> 
> Cheers!
> Sylvain
> 

The current status is that I intend to deprecate compat 9 in buster and
migrate people to compat 10, which prevents binNMU unsafe cases before
they reach the archive and that will be the end of that.
However, I doubt I would be motivated to write support for arch:any ->
arch:all in debhelper even if they are blessed by policy.


In summary:

 * The compat 10 rules are simple to implement, understand, explain and
   we know they work in all cases.

 * Please file bugs for debhelper's documentation of --link-doc where it
   is not up to date/adequate.

Thanks,
~Niels





signature.asc
Description: OpenPGP digital signature

Bug#835452: debian-policy: Deprecating dependency of "binary" on "build"

[Niels Thykier]

On Thu, 25 Aug 2016 22:06:51 +0200 (CEST) Santiago Vila
 wrote:
> Package: debian-policy
> Version: 3.9.8
> Severity: wishlist
> 
> Greetings.
> 
Hi,

CCing debian-dpkg@l.d.o because I think Guillem would be interested in this.

> Debian Policy 4.9 says:
> 
>  Both binary-* targets should depend on the build target, or on the
>  appropriate build-arch or build-indep target, if provided, so that the
>  package is built if it has not been already.
> 
> 
> I don't see the point at all:
> 
> 
> * Autobuilders *always* invoke the build-* targets first.
> 
> * dpkg-buildpackage *always* invoke the build/build-* target first.
> 
> [...]
>
> * Building as root should be discouraged.
> 

It is my understanding that Guillem is working on making the requirement
for using (fake)root obsolete.  This would have different benefits that
relevant to this discussion:

 * We can reduce the number of calls to make and by extension all
   the $(shell ...) invocation in d/rules (see #793404 for a discussion
   of that)

 * In theory, /if/ we could do a 100% transition, we could ditch the
   build target as a mandatory target. (Though this is hardly in the
   "near future" by any measure).

> 
> [...]
> 
> I don't know if this proposal will seem controversial, because we have
> been doing that for ages, so please let us consider all the pros and
> all the cons.
> 
> [...]
> 
> Thanks.
> 
> 

I have no strong feeling for whether build should remain a mandated
target (re: my second bullet above).  But I have a conflict of interest
with mandating that build must always be done in a separate invocation
as it would complicate a major progress on #793404.
  My understanding is that removing the dependency would do exactly the
latter (as "debian/rules build binary" is no longer well defined).

Thanks,
~Niels




signature.asc
Description: OpenPGP digital signature

Bug#821859: debian-policy: New virtual package ‘adventure’

[Niels Thykier]

On Sat, 31 Dec 2016 23:40:53 -0800 Russ Allbery  wrote:
> Ben Finney  writes:
> > On 20-Apr-2016, Ben Finney wrote:
> 
> >> We intend to use the ‘adventure’ virtual package name, to declare
> >> providing an implementation of the classic game Adventure.
> 
> > An announcement of this at ‘debian-devel’ on 2016-04-20 with Message-Id
> > <85zispp4gn@benfinney.id.au> attracted no feedback, so this name
> > evidently is uncontroversial.
> 
> > Please add this virtual package to the Games section:
> 
> > adventurethe classic Colossal Cave Adventure game
> 
> Seconded (needs one more second).
> 
> -- 
> Russ Allbery (r...@debian.org)   
> 
> 

Seconded. :)

Thanks,
~Niels




signature.asc
Description: OpenPGP digital signature

Bug#823348: Limit the strongest dependencies on supplemental -doc packages

[Niels Thykier]

On Sun, 01 Jan 2017 23:06:17 -0800 Russ Allbery  wrote:
> [...]
> 
> > diff --git a/policy.sgml b/policy.sgml
> > index 404dc73..421e0d1 100644
> > --- a/policy.sgml
> > +++ b/policy.sgml
> > @@ -10699,6 +10699,18 @@ END-INFO-DIR-ENTRY
> > 
> >  
> > 
> > + If package is a build tool, development tool,
> > + command-line tool, or library development package,
> > + package (or package-dev in the case of a
> > + library development package) already provides documentation in
> > + man, info, or plain text format, and package-doc
> > + provides HTML or other formats, package should declare
> > + at most a Suggests on package-doc. Otherwise,
> > + package should declare at most a Recommends on
> > + package-doc.
> > +   
> > +
> > +   
> >   Additional documentation included in the package should be
> >   installed under /usr/share/doc/package.
> >   If the documentation is packaged separately,
> 
> -- 
> Russ Allbery (r...@debian.org)   
> 
> 

Seconded. :)

Thanks,
~Niels





signature.asc
Description: OpenPGP digital signature

Bug#816249: debian-policy: C.2.4 does not reflect current practises

[Niels Thykier]

Russ Allbery:
> Niels Thykier <ni...@thykier.net> writes:
> 
>> The section C.2.4 seems to be a bit outdated.  Quote:
> 
>> """
>> [...]
>> """
> 
>> However, the default used by debhelper is "debian/", which covers
>> up to 99% of all packages.
> 
> Thanks for pointing this out.  The (non-normative) appendices have not
> gotten a lot of love.  I've applied the following patch to update this at
> least somewhat:
> 
> [...]
>  

Thanks for picking this up (and a happy year)! :)

Also, great job on the other policy changes in git today/yesterday! :)

Thanks,
~Niels





signature.asc
Description: OpenPGP digital signature

Re: PIE + bindnow for Stretch?(Re: Time to reevaluate the cost of -fPIC?)

[Niels Thykier]

Bálint Réczey:
> Hi,
> 
> [...]
> 

Hi,

> I think making PIE and bindnow default in dpkg (at least for amd64) would be
> perfect release goals for Stretch.
> 

I support the end goal, but I suspect we should enable PIE by default
via GCC-6's new configure switch[1].  Assuming it does what I hope, then
it will work better than enabling PIE via dpkg-buildflags.

 * The major issue with PIE by default is that it is not compatible
   with -fPIC (and presumably also -static), which causes FTBFS or
   broken ELF binaries.

 * Assuming the GCC option does what I hope, then it would automatically
   disable PIE for irrelevant outputs.

My assumption seems to be aligned with the approach taking by Ubuntu.

> This would make Debian on par with Fedora and Ubuntu in that regard.
> 

FTR, Fedora seems to have some special logic for adding PIE only to
executables.

> We briefly discussed that with Guillem in a related bug report:
> https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=812783#42
> 
> I think the next step could be an archive rebuild with the changed defaults
> if we would like to pursue this:
> https://wiki.debian.org/Teams/Dpkg/FAQ#Q:_Can_we_add_support_for_new_default_build_flags_to_dpkg-buildflags.3F
> 
> I planned starting a discussion on debian-devel about PIE + bindnow,
> too, after checking
> all the packages which contain statically compiled binaries because
> they may need patching
> to disable PIE flags based on Lunar's post:
> https://people.debian.org/~lunar/blog/posts/aslr_now/
> 
> Cheers,
> Balint
> 
>>[...]

In summary:

 * I would welcome bindnow by default via dpkg-buildflags.

 * I would also love to have PIE as default for Stretch although I fear
   dpkg-buildflags is the wrong approach for that particular flag.

Thanks,
~Niels

[1] https://gcc.gnu.org/gcc-6/changes.html

"""The --enable-default-pie configure option enables generation of PIE
by default."""




signature.asc
Description: OpenPGP digital signature

Re: Time to reevaluate the cost of -fPIC?

[Niels Thykier]

Marco d'Itri:
> On May 03, Josh Triplett  wrote:
> 
>> While this doesn't make PIC absolutely free, it does eliminate almost
>> all of the cost, to the point that it no longer seems worthwhile to
>> build without -fPIC.  Apart from that, building *all* code with -fPIC
>> (including both programs and libraries) helps with hardening.
> I think that this is worth exploring.
> Did you check what other (relevant) distributions are doing?
> 

Fedora seems to be doing -fPIE by default for executables[1] - targeting
Fedora 23.  Known issues they ran into can be found at [2].
  I also found the following PPA [3]. Cannot say if it is official or
just a personal interest from the PPA owner.

FTR, I personally think we should consider this as well for Stretch.

Thanks,
~Niels

[1]
https://fedoraproject.org/wiki/Changes/Harden_All_Packages?rd=Changes/Harden_all_packages_with_position-independent_code

[2] https://bugzilla.redhat.com/show_bug.cgi?id=1199775

Tracking bug for FTBFS/seg. faults etc. caused by the "hardening by
default" project.

[3] https://launchpad.net/~sbeattie/+archive/ubuntu/gcc-pie-amd64





signature.asc
Description: OpenPGP digital signature

Bug#822430: debian-policy: Please update 8.1.1 to use the "ldconfig" trigger instead

[Niels Thykier]

Package: debian-policy
Severity: normal

Hi,

Please update 8.1.1 to use the "ldconfig" trigger[1].

Possible wording could be:

"""
Any package installing shared libraries in one of the default library
directories of the dynamic linker (which are currently /usr/lib and
/lib) or a directory that is listed in /etc/ld.so.conf[60] must use
ldconfig to update the shared library system.

Any such package must have an "activate-noawait ldconfig" line in
their "triggers" control file.
"""
(replacing the entire section).

Alternative wordings welcome; I am not entirely certain the one above
is all that well.

Thanks,
~Niels

[1] https://lists.debian.org/debian-glibc/2015/08/msg00056.html

Bug#813471: network access to the loopback device should be allowed

[Niels Thykier]

On Wed, 3 Feb 2016 19:48:17 +0900 Osamu Aoki  wrote:
> 
> On Wed, Feb 03, 2016 at 12:22:14AM +0100, Guillem Jover wrote:
> > Hi!
> > This is probably too restrictive too. It would not allow local access
> > through TAP device or other similar things. It might be better to just
> > say something like:
> > 
> > | For packages in the main archive, no required targets may attempt
> > | network access outside the current machine.
> > 
> > or something along those lines.
> 
> I agree with you.
> 
> Osamu
> 
> 

Hi,

I would like to second Guillem's wording.

Thanks,
~Niels




signature.asc
Description: OpenPGP digital signature

Bug#746514: Autoreconf during build

[Niels Thykier]

On Fri, 8 May 2015 14:43:45 +0200 Bill Allombert 
wrote:
> On Sun, Jul 13, 2014 at 09:36:26AM +0900, Charles Plessy wrote:
> > Altogether, the wording was not restrictive as I thought.
> > 
> > Nevertheless, what would people think of adding a bit more explanation on 
> > the
> > purpose of replacing these files ?  Not all readers will have
> > /usr/share/doc/autotools-dev/README.Debian.gz available on their computer.  
> > How
> > about the following addition or an equivalent?
> > 
> > "This ensures that these files can be updated distribution-wide when 
> > introducing
> > new architectures."
> 
> OK, please find a new patch incorporating this.
> 
> > Also, adding "at build time" somewhere may clarify that patching these 
> > files is not
> > a good solution.
> 
> The wording "be used instead" seems to convey that already.
> 
> Looking for second, as always.
> 
> Cheers,
> -- 
> Bill. 
> 
> Imagine a large red swirl here. 

Hi,

An update to this:

 * dh (since 9.20160115) automatically updates all instances of
   config.sub and config.guess to the version in autotools-dev
   - This is done via a new helper called dh_update_autotools_config.
 * Therefore updating config.sub and config.guess based on the contents
   of autotools-dev can presumably now be considered "common practise".

As for the wording:

 * I second the wording proposed by Bill in message #55 with or without
   Charles's suggestion to add/use "at build time" (preferring "with")

Thanks,
~Niels




signature.asc
Description: OpenPGP digital signature

Bug#816249: debian-policy: C.2.4 does not reflect current practises

[Niels Thykier]

Package: debian-policy
Severity: minor

Hi,

The section C.2.4 seems to be a bit outdated.  Quote:

"""
C.2.4 debian/tmp

This is the canonical temporary location for the construction of
binary packages by the binary target. The directory tmp serves as the
root of the file system tree as it is being constructed (for example,
by using the package's upstream makefiles install targets and
redirecting the output there), and it also contains the DEBIAN
subdirectory. [...]

If several binary packages are generated from the same source tree it
is usual to use several debian/tmpsomething directories, for example
tmp-a or tmp-doc.

[...]
"""

However, the default used by debhelper is "debian/", which covers
up to 99% of all packages.

Note that "debian/tmp" is used still used as the default target for
"make install" (etc.) *if* there are several binaries and you use
"dh_auto_install".  When there is a single binary, dh_auto_install
defaults to installing all of it in "debian/".
  Note that I cannot speak for packages *not* using dh_auto_install,
but I suspect this has become the default for many packages.

Thanks,
~Niels

Re: dh: Install binaries to /usr/games if Section=games

[Niels Thykier]

Control: reassign -1 debian-policy
Control: retitle -1 debian-policy: Clarify status of /usr/games

Hi Policy maintainers,

I am reassigning this bug to you about whether /usr/games is still the
best place to install games binaries.

On 2015-08-31 21:57, Markus Koschany wrote:
> Am 31.08.2015 um 21:34 schrieb Niels Thykier:
> [...]
>> Hi,
>>
>> Are we still using /usr/games for games?  AFAICT, the use of /usr/games
>> is optional, so it is not clear to me that this desired?  The last I can
>> find on this in Debian is [1], which is 1½ years after this bug was filed.
> 
> Yes, we still install all binaries for games to /usr/games and static
> content to /usr/share/games. The use is optional according to the FHS
> but the Policy recommends the use of /usr/games and really questioned or
> changed that in the past years.
> 
> https://www.debian.org/doc/debian-policy/ch-customized-programs.html#s11.11
> 
> AFAIK, the next revision of the FHS will deprecate game specific paths
> but no idea how much progress has been done on this front.
> 
> Regards,
> 
> Markus
> 

If the current plans in FHS are to deprecate /usr/games, it seems
counter-productive to me to have debhelper start using it by default.
It will only serve to make the transition away from /usr/games even longer.

I think Debian Policy should consider relaxing the "should" in §11.11
(btw, is that normative even when written in lowercase?).

Thanks,
~Niels





signature.asc
Description: OpenPGP digital signature

Bug#727610: debian-policy: clearer discussion of why build-indep implies building the whole package

[Niels Thykier]

On Sat, 26 Oct 2013 14:14:23 +0200 Guillem Jover guil...@debian.org wrote:
 Hi!
 
 On Thu, 2013-10-24 at 15:47:56 +0100, Ximin Luo wrote:
  Package: debian-policy
  Severity: normal
 
  I was recently told to split part of my Build-Depends field into a
  separate Build-Depends-Indep field. Not one to follow orders without
  question, I went and did some research, and found this snippet in
  the policy[1]:
  
  There is no Build-Depends-Arch; this role is essentially met with
  Build-Depends. Anyone building the build-indep and binary-indep
  targets is assumed to be building the whole package, and therefore
  installation of all build dependencies is required.
 
 dpkg has supported Build-Depends-Arch and Build-Conflicts-Arch since
 1.16.4 (complete support with 1.17.0). Although they should not be
 used yet, as long as other resolvers are not aware of these.
 
 Thanks,
 Guillem
 
 

Hi Policy maintainers,

With dpkg and buildds supporting build-arch and build-indep plus source
uploads being tested in unstable, perhaps it is time to move forward
with this again?  :)


The build options are currently:

1. Maintainer uses binary and build targets (i.e. *-arch AND *-indep)
   - buildds uses binary-arch and build-arch missing architectures
2. Maintainer uses binary-indep and build-indep targets
   - buildds uses binary-arch and build-arch on *every* architecture
 (Ben Hutching has been doing this for a while already)
3. Maintainer uploads a source only (*)
   - One buildd uses binary-indep and build-indep to build the arch:all
 packages (if present)
   - buildds uses binary-arch and build-arch on *every* architecture

(*): Being tested in experimental atm.,

As noted, only option 1 uses the binary and build target.

Thanks,
~Niels

Please CC me on replies.





signature.asc
Description: OpenPGP digital signature

Bug#662998: debian-policy: stripping static libraries

[Niels Thykier]

On Fri, 28 Feb 2014 19:13:15 +0100 Niels Thykier ni...@thykier.net wrote:
 On 2014-02-28 19:05, Bastien ROUCARIES wrote:
  I could do some work if you point me thé branch
  
  Bastien
  [...]
 
 It is the branch from [1]; needs to be rebased on top of a recent
 version of Lintian.
 
 ~Niels
 
 [1]
 http://anonscm.debian.org/gitweb/?p=users/nthykier/lintian.git;a=shortlog;h=refs/heads/strip-static-lib
 

This has been deployed as two experimental tags in lintian[1].

 * unstripped-static-library (198 packages, 117207 tags)
 * static-library-has-unneeded-section (2797 packages, 629705 tags)

Packages using dh_strip will until yesterday have emitted
static-library-has-unneeded-section.  But the new version of debhelper
will now properly strip these sections as well.

As for the extreme number of tags (per package): This is caused by
Lintian emitted a tag for each object file inside the static lib (x2 as
it checks two architectures).


Assuming we currently have 40 000 binary packages in the archive, we are
dealing with:

 * At most 7.0% packages with 1 or more partially stripped static
   library
 * At most 0.5% packages with 1 or more completely unstripped

Since the 7% almost certainly comes from packages using dh_strip, I
think it is fairly safe to add stripping of static libraries as a
SHOULD at this point.

Thanks,
~Niels

[1] https://lintian.debian.org/tags.html

I *cannot* recommend that you click the links for the particular tags.
They are rather large given the number of tags.


-- 
To UNSUBSCRIBE, email to debian-policy-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/55caf854.3040...@thykier.net

Re: Bug#769818: lintian: false positive for dep5-file-paragraph-reference-header-paragraph

[Niels Thykier]

Control: tags -1 pending

On 2015-07-08 06:57, Charles Plessy wrote:
 Control: reassign -1 lintian
 Control: retitle -1 lintian: false positive for 
 dep5-file-paragraph-reference-header-paragraph
 
 Hello everybody,
 
 following Martin's clear report of false positive for the tag
 dep5-file-paragraph-reference-header-paragraph (see below), I am reassigning
 this bug to lintian.
 
 Have a nice day,
 
 -- Charles
 

Hi,

I believe this to be fixed in the master branch of our repository.

Thanks,
~Niels



-- 
To UNSUBSCRIBE, email to debian-policy-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/559cb95d.9090...@thykier.net

Bug#767839: [debhelper-devel] Bug#766711: debhelper: support --link-doc arch:all = arch:any

[Niels Thykier]

On 2015-01-09 17:39, Niels Thykier wrote:
 [...]
 

For reference, I have reviewed the situation a bit more and I have some
updates to my previous statements.

 If you bump the version of the binary, then it is no longer the same
 version as the source package.  Which is why I believe it is a violation
 of the footnote example.
 

I still believe this to be mostly true.  But to be honest, that is the
least of my concerns with this problem.

Please note that permitting arch:any packages to use an arch:all package
as --link-doc package implies that the arch:any package is allowed to
install its binNMU changelog into the target package as:

  /usr/share/doc/target-package/changelog.arch

There are already cases where debhelper might do something similar with
--link-doc packages, so I doubt this is an issue.

 Regardless, debhelper *cannot express* a dependency relation that
 guarantees that binaries built from exactly that version of the source
 (including binNMUs thereof) *AND* supporting arch:all - arch:any
 --link-doc support *WITHOUT* breaking binNMU.
 
 [...]
 
 Thanks,
 ~Niels
 
 [...]


While my argument here might be true, it is only so for cases where the
--link-doc target is an arch:any package.  In the case where an arch:any
uses an arch:all package as --link-doc target, a dependency on
(pkg = ${source:Version}) does seem to retain binNMU safety at first glance.


I am open to patches that allow an arch:any package to use an arch:all
as --link-doc target *provided* that:

 * It detects invalid link-doc targets[1] under a regular source
   *AND* an arch:all only (-A) builds[2]. Invalid link-doc targets
must cause an errors and abort the build.
 * The detection must *not* break a binNMU build[3].
 * The patch must ensure that the binNMU changelog is installed into the
   target package as noted above.
   - If this cannot be done without changing the debhelper sequence,
 the --link-doc change can only be supported in a new compat level.
   - NB: If it requires a major change to the sequence, I might veto it
 solely on that basis.
 * The patch cannot make assumptions on maximum number of packages
   sharing the same --link-doc target[4].
 * The patch cannot make assumptions on all packages sharing the same
   --link-doc target will be included in the same dh_installdocs call.
 * The patch must not introduce file conflicts.  A likely example could
   when multiple arch:any packages share the same arch:all package as
   link-doc target.
 * The patch must ensure that as long as at least one of the arch:any
   packages are installed, their binNMU changelog is available in
   /usr/share/doc/target-package[5].
 * It does not cause regressions in debhelper's current functionality
   or/and behaviour.
   - Where the existing behaviour is wrong or can be extended in an
 incompatible manner, the support can be added in a new compat level
 as noted above.
 * The patch must implement policy compliance under the current
   interface[6].
   - If not possible, it may extend the interface in a new compat level.
 However, the interface should generally strive to retain it
 simplicity.  In particular, it *must not* require the user to
 pre-declare the packages using a given --link-doc target (or
 similar) as such can trivially become outdated.
 * The patch must use the proper version for the --link-doc target.
   - For an arch:all target, I suspect the best approximation will be
 the ${source:Version} variable.  Though I suspect it to be wrong
 for cases where packages choose a different own version for the
 target package (see #747141).  This *may* be documented as a known
 limitation of the --link-doc setup if a better solution cannot be
 provided[7].

I am not entirely sure that this is possible, but to be honest, I would
be quite interested to see a solution to this problem.
  In fact, I might be willing to apply such a patch to debhelper even
without the policy footnote clarified[8] (in this bug or in the policy)
assuming it satisfies the above requirements.  Note that there are also
some *implicit* requirements (basics like it does not break the test
suite etc.) that I have not spelled out.
  Mind you, should a later clarification render this case non-compliant,
I will be forced to deprecate/revert the provided patch.

Should you provide a patch, please remove the wontfix tag from #766711
and add the patch tag as well.

Thanks,
~Niels

[1] An invalid link-doc target being an arch:all using an arch:any as
link-doc target.

[2] The reason here is that it is currently permitted to upload source
plus arch:all packages to the archive.  I believe that debhelper should
stop these from reaching the archive.

[3] I believe the test case should be something like:

  dch --bin-nmu 'Fake binNMU'
  dpkg-buildpackage -B -us -uc

[4] However, the patch may assume that a --link-doc target *never* have
another package as --link-doc target (e.g. P links to Q which links to
R

Bug#767839: debhelper: support --link-doc arch:all = arch:any (was: Re: debhelper: Dependency added by dh_installdocs --link-doc breaks binary-only NMUs)

[Niels Thykier]

Control: severity 766711 wishlist
Control: retitle 766711 support --link-doc arch:all = arch:any

On 2015-01-08 23:19, Robert Luberda wrote:
 reopen 766711
 block 766711 by 767839
 thanks
 

 I have taken the liberty of marking the bug as wontfix (read: cantfix)
 and closing it.
 
 I'm re-opening it, as neither the bug has not been fixed, nor the Policy
 has been changed to explicitly disallow linking arch:any to arch:all
 (see #767839).
 

Be that as it may, but does not change the fact that debhelper *does
not* support --link-doc between arch:all and arch:any packages.  Even if
it is deemed allowed, debhelper will not necessarily be able to support it.


 ~Niels

 [1] This is not limited to debhelper.  The reading of the policy
 actually (implicitly) forbids link-doc between arch:all and arch:any
 packages as the binNMU version is not the same as the source version.
 
 The version of source package is actually the same for both binNMU-ed
 arch:any and originally built arch:all. I think this fulfils the `(same
 source package and version)' given in footnote 116 in the policy.
 
 Additionally in my opinion those dummy `rebuild with ' changelog
 entries are added only to bump the version of binary package in order to
 upload into archive, otherwise they are probably of little interest to
 users, especially that they are being later overridden by maintainers'
 uploads.
 
 Regards,
 robert
 
 [...]

If you bump the version of the binary, then it is no longer the same
version as the source package.  Which is why I believe it is a violation
of the footnote example.

Regardless, debhelper *cannot express* a dependency relation that
guarantees that binaries built from exactly that version of the source
(including binNMUs thereof) *AND* supporting arch:all - arch:any
--link-doc support *WITHOUT* breaking binNMU.

Consider:
  (= ${binary:Version}) = breaks binNMU
  (= ${source:Version}) = breaks binNMU
  (= ${source:Version}), ( ${source:Version}+c~) =
Allows binaries not built from ${source:Version} to match[1]
  (= ${source:Version}), (= ${binary:Version}) =
breaks binNMU as well (arch:all are not rebuilt, so binary:Version
is the same as source:Version).


None of the above works and AFAICT, there exists no valid solution that
does not basically reduce the same conclusion as the above cases.

Thanks,
~Niels


[1] Assume source version 1.0, binNMU version 1.0+b1.  New source upload
1.0+a.  Binaries built from this satisfies the relation and thereby
violates the policy.


-- 
To UNSUBSCRIBE, email to debian-policy-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/54b00435.7020...@thykier.net

Bug#662998: debian-policy: stripping static libraries

[Niels Thykier]

On 2014-02-28 19:05, Bastien ROUCARIES wrote:
 I could do some work if you point me thé branch
 
 Bastien
 [...]

It is the branch from [1]; needs to be rebased on top of a recent
version of Lintian.

~Niels

[1]
http://anonscm.debian.org/gitweb/?p=users/nthykier/lintian.git;a=shortlog;h=refs/heads/strip-static-lib


-- 
To UNSUBSCRIBE, email to debian-policy-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/5310d1bb.80...@thykier.net

Bug#706778: debian-policy: Please explicitly forbid - at the start of Deb822 field names

[Niels Thykier]

Package: debian-policy
Severity: minor

Policy §5.1 states that:


[...] The field name is composed of US-ASCII characters excluding
control characters, space, and colon (i.e., characters in the ranges
33-57 and 59-126, inclusive). Field names must not begin with the
comment character, #.


This suggests that (e.g.)

  -Field: value

is a valid field.  Or (a bit more screwed):

  -BEGIN: PGP SIGNATURE-

would be the field -BEGIN with a value of PGP SIGNATURE-.

I would like recommend that the Policy explicitly forbids the use of
- at the start of a field name.

~Niels


--
To UNSUBSCRIBE, email to debian-policy-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: 
http://lists.debian.org/20130504182750.30206.83472.report...@mikazuki.thykier.net

Re: Bug#701660: lintian: Possible wrong syntax-error-in-dep5-copyright test in Lintian (Duplicate field copyright)

[Niels Thykier]

Control: reassign -1 debian-policy
Control: retitle -1 debian-policy: Clarifiy DEP5 copyright field example


Dear policy maintainers,

I am reassigning this Lintian bug to you, because I believe it was
caused by an example in the policy.  (Full context below)

In a nut shell, I suspect the problem is the following part of
copyright-format/1.0/ specificiation:



Copyright

[...] The Copyright field for that paragraph would contain:

Copyright 2008 John Smith
Copyright 2009, 2010 Angela Watts

[...]



The casual reader may misread this as:


Copyright: 2008 John Smith
Copyright: 2009, 2010 Angela Watts


I.e. as two single-line fields that are both named Copyright.  I think
it would be prudent to rewrite this to something like:


The Copyright field for that paragraph could look like:

Copyright:
  Copyright 2008 John Smith
  Copyright 2009, 2010 Angela Watts


~Niels

As promised, the context is

On 2013-02-25 21:50, Niels Thykier wrote:
 On 2013-02-25 21:37, Nelson A. de Oliveira wrote:
 Package: lintian
 Version: 2.5.11
 Severity: minor

 Correct me if I am wrong or if I lack some coffee, please, but with this
 copyright file:

 =
 Format: http://www.debian.org/doc/packaging-manuals/copyright-format/1.0/
 Upstream-Name: name
 Upstream-Contact: Somebody

 Files: file1.c file2.c
 Copyright: 2000, 2001 Foo
 Copyright: 2001, 2002 Bar
 License: BSD-Like
 =

 I am seeing this:

 W: test source: syntax-error-in-dep5-copyright line 7: Duplicate field 
 copyright.

 
 The specification says the syntax of these files are that of Policy §5.1
 and said specification do not allow duplicate fields in a given paragraph.
 
 In
 http://www.debian.org/doc/packaging-manuals/copyright-format/1.0/#copyright-field
 we can see an example with two Copyright lines.

 
 The example may be confusing, but what you see is not a two fields, but
 the contents of the field[1].
 
 It seems that lintian should not warn for duplicates copyright fields?

 
 My reading is that duplicate fields are a violation of the syntax.
 
 Thank you!

 Best regards,
 Nelson

 [...]
 
 ~Niels
 
 [1] Note the (by me emphased) singular field.
 
 
 _The Copyright field_ for that paragraph would contain:
 
 
 


-- 
To UNSUBSCRIBE, email to debian-policy-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/51335087.2020...@thykier.net

Bug#662998: debian-policy: stripping static libraries

[Niels Thykier]

Hi,

I have created a Lintian branch for detecting insufficient stripping of
static libs[1].  On a related note, dh_strip seems to do the right
thing(tm) so any package using debhelper (correctly) should already
strip static libs.  Though I did not check if it can do detacted symbols...

~Niels

[1]
http://anonscm.debian.org/gitweb/?p=users/nthykier/lintian.git;a=shortlog;h=refs/heads/strip-static-lib




-- 
To UNSUBSCRIBE, email to debian-policy-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/4ffd43ba.5080...@thykier.net

Bug#662998: debian-policy: stripping static libraries

[Niels Thykier]

Russ Allbery r...@debian.org writes:
 One drawback here, then, is that we don't know how many packages
 would be affected.  Is there a way that Lintian could introduce a
 check so that we know how many packages we would make buggy by adding
 a should?

Hi,

Both objdump and readelf handles .a files by giving a dump per .o
file in the ar archive (only tested on /usr/lib/libgettextpo.a).

We could look for the .note and .comment sections for those and give a
not properly stripped tag.  However, I doubt that L::Collect and
checks/binaries DTRT if handed the objdump/readelf output for a .a
file.  So some work is probably needed.

~Niels

PS: Not subscribed to the bug or d-policy bugs, so please CC as
needed.




-- 
To UNSUBSCRIBE, email to debian-policy-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/20120318112943.0ccbc40...@thykier.net

Bug#613046: debian-policy: please update example in 4.9.1 (debian/rules and DEB_BUILD_OPTIONS)

[Niels Thykier]

On 2012-02-01 01:43, Jonathan Nieder wrote:
 Hi,
 
 Charles Plessy wrote:
 
 [...]
 
 By now I imagine that dpkg-buildflags is becoming enough of a de facto
 standard that it would be reasonable to just recommend it with a policy
 should.  Niels, would you mind if I merge this with bug#578597?
 
 [...]

 Thanks,
 Jonathan


Feel free to merge them. :)

~Niels




-- 
To UNSUBSCRIBE, email to debian-policy-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/4f290719.1020...@thykier.net

Bug#656637: debian-policy: §5.1 is slightly ambiguous on space

[Niels Thykier]

Package: debian-policy
Severity: minor


Hi,

I would like to request a clarification on whether spaces are allowed
in fields.  My first thought was that it is not allowed.  However
units-filter/3.5-2 has a a space in the fields of its d/control file,
so presumably dpkg accepts it (at least to some extend).


Looking at the Policy §5.1, I found:


[...] each field consists of the field name, followed by a colon
and then the data/value associated with that field. The field name is
composed of printable ASCII characters (i.e., characters that have
values between 33 and 126, inclusive) except colon and must not with a
begin with #.


Here is usage of printable ASCII characters seems to imply
isprint(3), which considers space a printable.  However the range
(33-126) does not include space (32).  This leaves me two possible
interpretations:

 1. Typo in the range 33-126 (and 32-126 was intended).
- In this case, it is missing that fields must not start with
  space (as in that case the space is a continuation character).
- Considering that the comment character and other symbols
  (!$@` etc.) is allowed in a field, a space is not unthinkable.
- The results of googling printable ASCII seems to support this
  interpretation.
 2. printable is not defined by isprint(3) and the range is correct.
- In this case, the use of printable ASCII without an explicit
  exception for space character might be slightly confusing.

If space is allowed, I would suggest somthing like:


The field name is composed of printable ASCII characters (i.e.,
characters that have values between 32 and 126, inclusive) except
colon.  The field name must not with a begin with # or a space
character.



Otherwise, I would suggest:


The field name is composed of printable ASCII characters (i.e.,
characters that have values between 32 and 126, inclusive) except
colon and space.  The field name must not with a begin with #.



Thanks in advance for the clarification,
~Niels



--
To UNSUBSCRIBE, email to debian-policy-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: 
http://lists.debian.org/20120120164532.5418.49377.report...@mangetsu.thykier.net

Bug#578421: virtual-packages: Retire java-compiler, java2-compiler and java-virtual-machine

[Niels Thykier]

On 2011-11-29 00:32, Bill Allombert wrote:
 On Wed, Apr 21, 2010 at 11:07:53AM +0200, Niels Thykier wrote:
 Rene Engelhard wrote:
 On Mon, Apr 19, 2010 at 08:33:12PM +0200, Niels Thykier wrote:
 [java{,2}-compiler]
   - default-jdk. If used in an alternative in Build-Depends{,-Indep} then 
 pick
 one of the options (The Java Team recommends default-jdk).

 And what are you going to do as replacement for whatever Java compiler, I 
 don't care
 as long as it understands Java 2?

 Grüße/Regards,

 René

 Hi

 Good point.

 A java compiler is usually useless without the a backing Java core
 library, so you probably want to replace it with a JDK.

 Also please note that we have removed a lot of JVMs from Squeeze;
 currently Debian has 3 or so left.
   * openjdk-6
   * gcj/gij
   * sun-java6 (non-free)
   * default (which is either openjdk-6 or gcj/gij)

 As I recall there is also a JVM implemented in .NET or so, but it does
 not identify itself via one of the javaX-runtime (nor the java-compiler
 ones) and I cannot remember its name offhand.

 Aside from the mono JVM (which I do not really know), all of them can
 run Java5 code[1], so basically it is useless to have both java-compiler
 and java2-compiler.
   On a related note: it appears that only sun-java6 provides
 java2-compiler (even though all others could provide it as well).

 If I was to replace a java{,2}-compiler to mean Any java compiler I
 would use:
   default-jdk | gcj-jdk | sun-java6-jdk [3]

 But I would definitely consider only using default-jdk (especially for
 Suggests). While that may seem a bit strange as replacement for Any
 compiler consider the following:
  default-jdk is either openjdk-6-jdk or gcj-jdk
  openjdk-6 is based on the same source as sun-java6
  openjdk-6 is available any architecture where sun-java6 is.
  gcj-jdk is inferior to openjdk-6 (not only due to [1])

 While sun-java6 is still superior to openjdk-6 in some cases, I believe
 this is only a runtime thing and not a compile issue. So by using
 default-jdk you get the best compiler we got and it is shorter.
   Of course there are users using sun-java6-jdk which will not like if
 apt pulls in a second JDK, so for Recommends+Depends it may be worth to
 use the alternatives.

 With a little grep-dctrl magic I noticed we 1 absolute dependency on
 javaX-compiler (laby), four Recommends (robocode, jde, jython, mmake)
 and 5 Suggests (ant, ant1.7, cup, openoffice.org-dev-doc, lab).
   There are also 6 Build-Depends(-Indep) cases, but I already covered
 those. All in all we got a total of 15 (9 + 6) uses of java-compiler and
 java2-compiler, so they do not appear to be widely used.

 ~Niels

 [1] gcj/gij does not implement the full Java5 API.

 [2] Should be updated, since gcj is a transitional package.

 [3] You could add openjdk-6-jdk to this list, but on architectures where
 openjdk-6 is available, it will be pulled by default-jdk.
 
 Hello Renee,
 Are you fine with that change ?
 
 Niels, can you get other Java people to second this ?
 
 Cheers,

Hi,

Considering the retirement of these virtual packages was up for public
debate on d-java in 2010[1], it shouldn't be a problem to get someone to
(re-)second this.  :)

So, hallo d-java people - if you (still) agree with this change, please
reply to #578421.  :)

~Niels

[1] http://lists.debian.org/debian-java/2010/04/msg00088.html





--
To UNSUBSCRIBE, email to debian-policy-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/4ed529e6.6050...@thykier.net

Bug#613046: debian-policy: please update example in 4.9.1 (debian/rules and DEB_BUILD_OPTIONS)

[Niels Thykier]

Package: debian-policy
Version: 3.9.1.0
Severity: minor

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

Hey

The example in 4.9.1 suggests to set CFLAGS in a way that completely
overrides values from dpkg-buildpackage/dpkg-buildflags[1]:

CFLAGS = -Wall -g

This will set CFLAGS to -Wall -g regardless of what dpkg-buildflags
provides.  Possible alternatives that appears to work are:

CFLAGS := $(CFLAGS) -Wall -g

CFLAGS  = $(shell dpkg-buildflags --get CFLAGS) -Wall -g

While related to #578597, I believe it to be a distinct issue. This was 
triggered
by this email[2] on debian-mentors.

Thank you in advance,
~Niels

[1] http://www.debian.org/doc/debian-policy/ch-source.html#s-debianrules-options

[2] 4d565fcd.8030...@climbing.nl

- -- System Information:
Debian Release: 6.0
  APT prefers testing
  APT policy: (990, 'testing'), (500, 'unstable'), (1, 'experimental')
Architecture: i386 (i686)

Kernel: Linux 2.6.32-5-686 (SMP w/2 CPU cores)
Locale: LANG=en_DK.UTF-8, LC_CTYPE=en_DK.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash

debian-policy depends on no packages.

debian-policy recommends no packages.

Versions of packages debian-policy suggests:
pn  doc-base  none (no description available)

- -- no debconf information

-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.10 (GNU/Linux)

iQIcBAEBCAAGBQJNVopQAAoJEAVLu599gGRC5owP/126vj5jQDjG+poceq2sMEwY
Pn5Btc+iXey8TLQQoA/0D2pT0VU+dfnflTzQSsiec24R7sSicviEyOujSJDRHsef
zXKriaWLywscP0z8aqGb9z12Fc7zYjYgqeeNc+NLzxoSD+dZRNgo0ILrQ/GQlC7p
Okq1DJnc8BqwFMezxoTk39n+LLTuv6M3OuV7sZYSdHwYNhSVyUjLwppdqTjMMH2j
8qq46PkfvAudj5uskCyY4r7Mh/SSwDYFKMp0Lo/T/ic9WhAZQE+7qu4kjexmtyl/
aTC3c0Tqfc2CSfNoxbRZKY1FUT77ZmBbg17DWRLF8LfajOIkFjK4ps61t9hWNTmX
uGJVzr8m9CNc+HRQAMO4wSTjCDGl3NLnP2d12OiOvhCaFO4nTuUdk+0t8YByUU2P
BPDX0TVmODQT3DPyiIg7lliuyBRk4an4G6SqhrDuMOWQ5iZ4LhxsFZrVE/qlHAeg
IL+5A+AchPKvrDByRKurH09J0wboZt7a2suJfwk+NjyglpYF1X8wwZFxvZN3QlEm
hvPpa2RQRwjfzXE0PIPjjdsdlGCdwNLdooV/O8hBKczw9jaSu6iZyYcFGlgeFXxj
2RhAAWcFqymglZ85uSgmALz7Yq/zawLNU/yOGdajz+Rw+fcfOyINzVQaMIfTjunE
b3kp2V2nF5Sxeg0gKPzZ
=zJ3g
-END PGP SIGNATURE-



-- 
To UNSUBSCRIBE, email to debian-policy-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: 
http://lists.debian.org/20110212132540.9089.87350.report...@getsu.thykier.net

Bug#613046: debian-policy: please update example in 4.9.1 (debian/rules and DEB_BUILD_OPTIONS)

[Niels Thykier]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

On 2011-02-12 22:32, Julien Cristau wrote:
 On Sat, Feb 12, 2011 at 14:25:40 +0100, Niels Thykier wrote:
 
 Package: debian-policy
 Version: 3.9.1.0
 Severity: minor

 Hey

 The example in 4.9.1 suggests to set CFLAGS in a way that completely
 overrides values from dpkg-buildpackage/dpkg-buildflags[1]:

 CFLAGS = -Wall -g

 This will set CFLAGS to -Wall -g regardless of what dpkg-buildflags
 provides.  Possible alternatives that appears to work are:

 CFLAGS := $(CFLAGS) -Wall -g

 That would be wrong.  A package build shouldn't depend on random env
 variables.
 

I believe a lot of packages in the archive actually suffers from this
issue then, if dpkg-build{package,flags} did not sanitize these variables.
  How many packages explicitly sets e.g. LDFLAGS in debian/rules? Almost
none of mine does it (granted most of my packages are Java packages, but
still).

 CFLAGS  = $(shell dpkg-buildflags --get CFLAGS) -Wall -g

 While related to #578597, I believe it to be a distinct issue. This was 
 triggered
 by this email[2] on debian-mentors.

 Seems to be the exact same request to me?
 
 Cheers,
 Julien
 

Well, yes, if you insist the CFLAGS  := $(CFLAGS) somearg is wrong, it
would appear that my original request can be trivially be reduced to
#578597.
  Though in that case, I think we should change this one to a request to
make the policy be explicit in how a package should handle variables
from the environment (and which variables it should neutralize).

~Niels

-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.10 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/

iQIcBAEBCAAGBQJNVwv1AAoJEAVLu599gGRC3twQAIfvAyQRXBN51/aMMDxb3Zyk
dSKdi9OnebvufSULxvgWZJ0pm8+QUp/pjg1FAELGo4tbmFv6jqbW8KIhws3UACtP
TZ9ohwnt/9Hdp3Whvu2gPze0CvKSkplYLtrAMpevvi4S6RN5qX/Un0QtyeD1oNfn
47nJcPINryWZPKKWI6boq1EGed3m2+CIzzjvKtPeQHX/40rgwN39kAZpiuBNGah/
3TiM1/ETZl7oXXxCpJ8EzN62CA3vj6ugSBVCfLFVjlv82sMTV8mZTYaBK2Re8BSu
MHWzb7PHButf3J2xwL1RoaoeuwnJEs+mgP8oFeprf5T4ugjwMbN/FmcxTm2DQlt8
ZbnRFiuBIO/D30TtiW3DAsUcOhZasIcvtRuNZ1U1LFkXj79n4fHsBYIrTdEnbbtR
27lGITVVAHfscZsReIn8Eb3V1uJgklVnQeyMZSpb8wSaKoEVv9uLZPc/NCV9KC41
PahhxuEkTMQfFwCY6cxaeHq/nZwY1XWUYGmHioa0/cPDARyIbwNU2nC6qZNxGCuQ
C5NONW+cTDIqu1S7Hh07B+oRA6MIW8iLZUUdt0kxv0L0ZTawJRk3Kgu7AYPl66CN
cI/n4fNPsAEcPHnMYfk+L+xduO89krrlu38eGAX2a5Z15ZKlaV2NDHlermErcfgg
jsSQKFlYiDiAkjS8hfix
=zUym
-END PGP SIGNATURE-



-- 
To UNSUBSCRIBE, email to debian-policy-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/4d570bf6.90...@thykier.net

Bug#610298: phasing out tar-in-tar in source packages

[Niels Thykier]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

Hi

I second the idea of phasing out source packages the old tar-in-tar,
starting with a should (not) or a Recommend (against). :)

~Niels

-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.10 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/

iQIcBAEBCAAGBQJNNFyXAAoJEAVLu599gGRCJz4P/3Uw70HMvfcypnmzVJVEXuBJ
izKKugd/8rUY7DjC9oAbAHX5awGg7sOdWgaQpVHWnKXrLjYFny0p2Ua2D69HTL89
IJyf6NMsjtctP4ft2jJotfpYxJZhI7TgxpS2BkF952Wum85Z3MEVwor9yh+edziS
YKtGDt2A46+2l7Py05hSEVArqkYaNTN1urNtJkNZec/6o2V3mWgDfEfRVM8Jww4J
qo4/2EHPqyZvGa++FQ7bwFZMVk1E8PPlbQNjmEi/8NWHl+mWCyLZYXATHc3rtCpP
64YSSM7Y+WAsOgeSlb2FvZteCxnk8hOQE26lTqEt9i9arZelwS5dWM+IcvWe0feE
vzPuIrgA3ONHYSEOUkhckyGLprjfddvqVRERjvalJrEzhrCGQuSDtda1KRl4pOU8
8N2e9BM4RJoQWpN1puc4y00ZJ0No7RT0gVxjFwZmVD7rOnqrZn5lMYdjjb82ne+k
OTNSDnORmiwgmhBw+HC/aseJp/GwIvsSP1uHpufIxHZo+6PJqwrXXRKn+cMfnnxI
1GHwQpgQ9JgrV8XZxMefKNj5PtuuW3gtvhZuWsPEdOnxgXrAZOyKE0rGCl7XJD15
Lx7z5tofPRoMRCrwXvKyRwhifuX7bxlPVyP3pLoKIKsG027oKLTQPregEoi0Gh6J
2gQkVgF0FnE/YLbGK86M
=S1iM
-END PGP SIGNATURE-



-- 
To UNSUBSCRIBE, email to debian-policy-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/4d345c98.7060...@thykier.net

Bug#578421: virtual-packages: Retire java-compiler, java2-compiler and java-virtual-machine

[Niels Thykier]

Rene Engelhard wrote:
 On Mon, Apr 19, 2010 at 08:33:12PM +0200, Niels Thykier wrote:
 [java{,2}-compiler]
   - default-jdk. If used in an alternative in Build-Depends{,-Indep} then 
 pick
 one of the options (The Java Team recommends default-jdk).
 
 And what are you going to do as replacement for whatever Java compiler, I 
 don't care
 as long as it understands Java 2?
 
 Grüße/Regards,
 
 René

Hi

Good point.

A java compiler is usually useless without the a backing Java core
library, so you probably want to replace it with a JDK.

Also please note that we have removed a lot of JVMs from Squeeze;
currently Debian has 3 or so left.
  * openjdk-6
  * gcj/gij
  * sun-java6 (non-free)
  * default (which is either openjdk-6 or gcj/gij)

As I recall there is also a JVM implemented in .NET or so, but it does
not identify itself via one of the javaX-runtime (nor the java-compiler
ones) and I cannot remember its name offhand.

Aside from the mono JVM (which I do not really know), all of them can
run Java5 code[1], so basically it is useless to have both java-compiler
and java2-compiler.
  On a related note: it appears that only sun-java6 provides
java2-compiler (even though all others could provide it as well).

If I was to replace a java{,2}-compiler to mean Any java compiler I
would use:
  default-jdk | gcj-jdk | sun-java6-jdk [3]

But I would definitely consider only using default-jdk (especially for
Suggests). While that may seem a bit strange as replacement for Any
compiler consider the following:
 default-jdk is either openjdk-6-jdk or gcj-jdk
 openjdk-6 is based on the same source as sun-java6
 openjdk-6 is available any architecture where sun-java6 is.
 gcj-jdk is inferior to openjdk-6 (not only due to [1])

While sun-java6 is still superior to openjdk-6 in some cases, I believe
this is only a runtime thing and not a compile issue. So by using
default-jdk you get the best compiler we got and it is shorter.
  Of course there are users using sun-java6-jdk which will not like if
apt pulls in a second JDK, so for Recommends+Depends it may be worth to
use the alternatives.

With a little grep-dctrl magic I noticed we 1 absolute dependency on
javaX-compiler (laby), four Recommends (robocode, jde, jython, mmake)
and 5 Suggests (ant, ant1.7, cup, openoffice.org-dev-doc, lab).
  There are also 6 Build-Depends(-Indep) cases, but I already covered
those. All in all we got a total of 15 (9 + 6) uses of java-compiler and
java2-compiler, so they do not appear to be widely used.

~Niels

[1] gcj/gij does not implement the full Java5 API.

[2] Should be updated, since gcj is a transitional package.

[3] You could add openjdk-6-jdk to this list, but on architectures where
openjdk-6 is available, it will be pulled by default-jdk.




signature.asc
Description: OpenPGP digital signature

Bug#578421: virtual-packages: Retire java-compiler, java2-compiler and java-virtual-machine

[Niels Thykier]

Package: debian-policy
Version: 3.8.4.0
Severity: wishlist
Justification: Policy §3.6
X-Debbugs-CC: debian-de...@lists.debian.org

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Hi

As of today[1], the Java Policy retired the use of the virtual packages 
mentioned
in the subject line, which brings the Java Policy closer to the actual practices
used by the Java Team.


The replacement guide for the packages are as described below. Please note that
these are guide lines for the average case. If a package does not fit in,
feel free to contact the Java Team (debian-j...@l.d.o) about it.

[java-virtual-machine]
 - none if already depending(or recommending/...) on a java runtime[2].
 - An alternative list of java runtimes (see [2]) otherwise.

[java{,2}-compiler]
 - default-jdk. If used in an alternative in Build-Depends{,-Indep} then pick
   one of the options (The Java Team recommends default-jdk).

In case you change your Build-Depends{,-Indep} to include default-jdk, you
should update JAVA_HOME to /usr/lib/jvm/default-java if your build system
(e.g. ant) uses it.

Please do *not* switch to default-jdk-builddep without consulting the Java Team
first. On most architectures default-jdk-builddep will pull *two* full Java
Development Environments.
  There is a reason for insanity; if you are interested then get in contact 
with
the Java Team.

Thank you in advance,
~Niels

NB: I am subscribed to debian-de...@l.d.o, but not debian-pol...@l.d.o; please 
CC
me accordingly.

[1] http://packages.qa.debian.org/j/java-common/news/20100419T071712Z.html

[2] e.g. one of these default-jre, default-jre-headless, java1-runtime, 
java2-runtime
  If you use indiviual JVMs (e.g. gij or gcj) it may be worth replacing them 
with
default-jre{,-headless} plus alternatives.
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.10 (GNU/Linux)

iEYEARECAAYFAkvMoaIACgkQVCqoiq1YlqyQkwCfSvVWBsnto4SlIeGuitjsOIBd
gZ0AnilwrFjEfUNB2LVf1uoaai5YJlYr
=hAv9
-END PGP SIGNATURE-