Bug#844431: policy: packages should be reproducible

[Holger Levsen]

hi,

unsurprisingly I'm also in favor of making this policy change, now.

I also believe there is quite a consensus (definitly a rough one…) in Debian
for making this change, judging by the feedback we got at 3 DebConfs since 2013,
several mini Debconfs and other events, plus the general feedback in the form
of code merges and uploads.

At the Reproducible Builds Hackathon in Hamburg we were reminded of the former
DPL asking DDs to be "more bold" doing sensible changes forward, and as such
we plan that starting with the development phase of "buster" we'll consider
bugs about reproducible builds issues to be of severity "normal", not 
"wishlist".

This shall be announced on d-d-a soon & given there is no disagrement on this
procedure on this bug.

Last and least for now: the wording of
https://bugs.debian.org/cgi-bin/bugreport.cgi?att=1;bug=844431;filename=debian-policy.diff.txt;msg=17
IMO is almost good as it is, though I'll try to amend it to include the
definition of reproducible builds from reproducible-builds.org. 


-- 
cheers,
Holger


signature.asc
Description: Digital signature

Bug#844431: policy: packages should be reproducible

[Holger Levsen]

On Thu, May 11, 2017 at 02:42:43PM +0200, Bill Allombert wrote:
> I really think there should be an official tool to do build packages
> reproducibly with an interface like cowbuilder. 
 
the official tool to build packages reproducible in sid is called
"dpkg-buildpackage" (since dpkg 1.18.16 in sid since 2016-12-17).


-- 
cheers,
Holger


signature.asc
Description: Digital signature

Bug#844431: policy: packages should be reproducible

[Holger Levsen]

On Sun, May 14, 2017 at 04:51:47PM +0200, Bill Allombert wrote:
> > the official tool to build packages reproducible in sid is called
> > "dpkg-buildpackage" (since dpkg 1.18.16 in sid since 2016-12-17).
> So if your package builds with "dpkg-buildpackage" then the build is
> reproducible and any bug report to the contrary is in error ? 

almost. 93% of the packages in stretch today can be re-build bit by bit
identically. 

that's why we're now aiming at "packages should be reproducible" and not
for "must be reproducible"… (but plan to later aim for "must be").


-- 
cheers,
Holger


signature.asc
Description: Digital signature

Bug#844431: policy: packages should be reproducible

[Holger Levsen]

On Sun, May 07, 2017 at 06:15:38PM +0100, Chris Lamb wrote:
> > unsurprisingly I'm also in favor of making this policy change, now.
> Actually, yes, why were we waiting for stretch to be released? :)

good question. I guess because of a mental barrier against doing changes
targeted post-stretch now :)
 
> > Last and least for now: the wording of
> > https://bugs.debian.org/cgi-bin/bugreport.cgi?att=1;bug=844431;filename=debian-policy.diff.txt;msg=17
> > IMO is almost good as it is, though I'll try to amend it to include the
> > definition of reproducible builds from reproducible-builds.org. 
> That seems the next concrete step.

indeed! Will see to work on this the next days…


-- 
cheers,
Holger


signature.asc
Description: Digital signature

Bug#844431: policy: packages should be reproducible

[Holger Levsen]

On Sun, May 14, 2017 at 05:05:36PM +0200, Bill Allombert wrote:
> OK, but how can I check that my package build is reproducible before uploading
> it ?

in general you cannot find out with 100% certainity whether a given source 
package
will be reproducible. You can only find out with certainity if a package is 
*not*
reproducible…

that said

a.) go to http://reproducible.debian.net/$srcpkg and see if its reproducible 
today.

Bill, did you do this for your packages?
And then there is also 
https://tests.reproducible-builds.org/debian/unstable/index_dd-list.html#ballo...@debian.org
which shows that half of your 26 packages in sid (main) are 
unreproducible
with build path variation, though most of those unreproducible 
ones
are reproducible without build path variation…
-> 
https://tests.reproducible-builds.org/debian/testing/index_dd-list.html#ballo...@debian.org
only shows 4 unreproducible packages…

b.) build it twice and compare using diffoscope
c.) use reprotest


-- 
cheers,
Holger


signature.asc
Description: Digital signature

Bug#844431: policy: packages should be reproducible

[Holger Levsen]

On Sun, May 14, 2017 at 09:58:12PM +0200, Guillem Jover wrote:
> On Sun, 2017-05-14 at 15:20:54 +0000, Holger Levsen wrote:
> > Bill, did you do this for your packages?

on re-reading what I wrote here, it occurred to me that this could be
read *hostile* despite me having *zero* intentions to be hostile… I
just wanted to be friendly and give helpful URLs to you, Bill… I'm
sorry if this came across differently!

> b.0.) use debrepro (from devscripts)
 
Thanks for this additional hint, Guillem!


-- 
cheers,
Holger


signature.asc
Description: Digital signature

Bug#844431: policy: packages should be reproducible

[Holger Levsen]

On Mon, May 15, 2017 at 12:05:17AM +0200, Bill Allombert wrote:
> On Sun, May 14, 2017 at 03:20:54PM +0000, Holger Levsen wrote:
> > On Sun, May 14, 2017 at 05:05:36PM +0200, Bill Allombert wrote:
> > a.) go to http://reproducible.debian.net/$srcpkg and see if its 
> > reproducible today.
> As I said, I would like to check that my package build is reproducible before
> I upload it, not after, so I can be sure that any bug is fixed in the
> upload.
 
b.), b.0), c.) and d.) were given as possible "tools" *to build twice with 
(some) variation(s) and compare the results*.

"Reproducible Builds" (in the sense of bit by bit identicall builds) is
really a rather new field in the era of software (well, not really, but 
thats history and bit rotted until it was rediscovered in the early 2010s…)

What is trivial, if given, is to show that a package is *un*reproducible.

It's much harder to show that a package is reproducible.

And given that this is a new field I think it's ok, while somewhat unsatisfying,
that maybe some unreproducibility will only be detected by a more advanced
tool, like reproducible.debian.net (which aint a,b,c nor d, but e.)
after an upload has taken place.

This is one of the reasons we are aiming for "packages *should* be reproducible"
now, and not "*must* be".

> Some of my package were listed as reproducible for several months and
> then became unreproducible without any new upload. I do not mind that.

I guess this is because we introduced many more variations during 2014 and 2015.
During 2016 I don't recall us introducing many varitions, or rather many
causing many new unreproducibilty issues…

For 2017 there weren't any.

> However from a policy point of view, reproducible need to be defined
> precisely.

Yes!

> Generally speaking, reproducible means that the build will
> not change if some (but not all) parameters are changed.

Yes.

> What parameters
> are allowed to change need to be defined.

I sadly think this is impossible.

> One way is specify that would be to provide an authoritative tool to
> validate packages.

the tool to validate builds should be diff/sha256sum. a tool to simulate all 
possible
variations in the wild would probably need endless time to operate… 

> PS: I thanks you for your advices, I will reply to you privately if I
> need to.

While you surely can do so (and I will happily reply) I would even more happily
prefer if you could ask me on public list (and ping in private if you havent 
gotten a reply in whatever you think is appropriate)… a.) then more people can 
learn b.) you'll probably get faster *and better replies* (esp. on language
specific details) and c.) this helps me getting my inbox under control :-)


-- 
cheers,
Holger


signature.asc
Description: Digital signature

Bug#835520: Andreas Henriksson's 11 patches are awesome

[Holger Levsen]

hi,

$ git log master..for-holger --oneline -11
a8e08d5 Bug#835520: [PATCH v2 11/11] Drop entire section 9.4 Console messages 
from init.d scripts
dfa8fae Bug#835520: [PATCH v2 10/11] Add reference to systemd integration 
examples
658c3c2 Bug#835520: [PATCH v2 09/11] Drop obsolete paragraph about rc.boot
5364c04 Bug#835520: [PATCH v2 08/11] Add note about invoke-rc.d normally used 
via dh
24d45b9 Bug#835520: [PATCH v2 07/11] Drop legacy code from invoke-rc.d example
6964322 Bug#835520: [PATCH v2 06/11] Add "or equivalent" to must use 
invoke-rc.d paragraph
8ab2800 Bug#835520: [PATCH v2 05/11] Add note about update-rc.d normally used 
via dh
5103414 Bug#835520: [PATCH v2 04/11] Drop outdated paragraph about sequence 
numbers
5314e48 Bug#835520: [PATCH v2 03/11] Drop obsolete paragraph about static 
runlevels and update-rc.d
e553ef7 Bug#835520: [PATCH v2 02/11] Update init-system title to be more 
agnostic
5965214 Bug#835520: [PATCH v2 01/11] Drop outdated "/run needs initscripts 
dependency"

Those patches are all good, thanks a lot Andreas!

Hereby I'm formally seconding them and thus I'm attaching those commits signed
by myself.

minor nitpick: the 10th patch is fine but should be improve to mention systemd 
examples first, and sysv second.


-- 
cheers,
Holger




signature.asc
Description: Digital signature

Bug#835520: Andreas Henriksson's 11 patches are awesome

[Holger Levsen]

On Wed, Aug 02, 2017 at 06:57:03PM +, Holger Levsen wrote:
> Hereby I'm formally seconding them and thus I'm attaching those commits signed
> by myself.

this time with an actuall attachment.


-- 
cheers,
Holger
commit 596521413f7577ee959a4eee1449f146e43cd9c0
Author: Andreas Henriksson 
Date:   Sat Dec 17 13:57:04 2016 +0100

Bug#835520: [PATCH v2 01/11] Drop outdated "/run needs initscripts dependency"

The paragraph ends with
"...until the stable release of Debian supports /run."
which current releases does, so this paragraph is obsolete.

diff --git a/policy.sgml b/policy.sgml
index 9cd182b..81df4a3 100644
--- a/policy.sgml
+++ b/policy.sgml
@@ -7053,12 +7053,6 @@ Built-Using: grub2 (= 1.99-9), loadlin (= 1.6e-1)
 		  in /run should be stored on a temporary
 		  file system.
 		
-		
-		  Packages must not assume the /run
-		  directory exists or is usable without a dependency
-		  on initscripts (>= 2.88dsf-13.3) until the
-		  stable release of Debian supports /run.
-		
 	  
 	  
 		

commit e553ef727fe28006a2f240d8de70a5f761c77c86
Author: Andreas Henriksson 
Date:   Sat Dec 17 13:57:05 2016 +0100

Bug#835520: [PATCH v2 02/11] Update init-system title to be more agnostic

Get rid of "script" as that doesn't properly describe the equivalent for
systems using declarative replacements.

Also drop "the" as via update-rc.d you're potentially/likely interfacing
with multiple ones at a time. Possibly the word system should be
replaced with systems or system(s)?

diff --git a/policy.sgml b/policy.sgml
index 81df4a3..07b7e4f 100644
--- a/policy.sgml
+++ b/policy.sgml
@@ -7648,7 +7648,7 @@ test -f program-executed-later-in-script || exit 0
 	
 
 	
-	  Interfacing with the initscript system
+	  Interfacing with init systems
 
 	  
 	Maintainers should use the abstraction layer provided by

commit 5314e486798c5f112d0463a88b050448b2e2c92b
Author: Andreas Henriksson 
Date:   Sat Dec 17 13:57:06 2016 +0100

Bug#835520: [PATCH v2 03/11] Drop obsolete paragraph about static runlevels and update-rc.d

These days the information in the LSB header is used.

Manually specifying/overriding runlevels as a parameter to
update-rc.d on command line is even deprecated and a noop stub
these days.

diff --git a/policy.sgml b/policy.sgml
index 07b7e4f..32e1efc 100644
--- a/policy.sgml
+++ b/policy.sgml
@@ -7691,19 +7691,6 @@ test -f program-executed-later-in-script || exit 0
 	
 
 	
-	  By default update-rc.d will start services in
-	  each of the multi-user state runlevels (2, 3, 4, and 5)
-	  and stop them in the halt runlevel (0), the single-user
-	  runlevel (1) and the reboot runlevel (6).  The system
-	  administrator will have the opportunity to customize
-	  runlevels by simply adding, moving, or removing the
-	  symbolic links in /etc/rcn.d if
-	  symbolic links are being used, or by modifying
-	  /etc/runlevel.conf if the file-rc method
-	  is being used.
-	
-
-	
 	  To get the default behavior for your package, put in your
 	  postinst script
 	  

commit 51034145478cbaf2e3d027f7e82cce48ef1673b6
Author: Andreas Henriksson 
Date:   Sat Dec 17 13:57:07 2016 +0100

Bug#835520: [PATCH v2 04/11] Drop outdated paragraph about sequence numbers

Todays init systems calculates a dependency graph (eg. from the
dependencies specified in LSB headers) and doesn't go by sequence
numbers. See eg. insserv.

diff --git a/policy.sgml b/policy.sgml
index 32e1efc..d1108be 100644
--- a/policy.sgml
+++ b/policy.sgml
@@ -7708,15 +7708,6 @@ test -f program-executed-later-in-script || exit 0
 	
 
 	
-	  This will use a default sequence number of 20.  If it does
-	  not matter when or in which order the init.d
-	  script is run, use this default.  If it does, then you
-	  should talk to the maintainer of the sysvinit
-	  package or post to debian-devel, and they will
-	  help you choose a number.
-	
-
-	
 	  For more information about using update-rc.d,
 	  please consult its man page .

commit 8ab2800dc5c641442391530c0e78a4e072b0b74f
Author: Andreas Henriksson 
Date:   Sat Dec 17 13:57:08 2016 +0100

Bug#835520: [PATCH v2 05/11] Add note about update-rc.d normally used via dh

It might not be the policy's place to define how the maintainer should
automate the packaging work, but at least mention debhelper to not
fool people into thinking manually writing maintainer scripts is
the preferred method of using update-rc.d.

diff --git a/policy.sgml b/policy.sgml
index d1108be..37cac8a 100644
--- a/policy.sgml
+++ b/policy.sgml
@@ -7712,6 +7712,14 @@ test -f program-executed-later-in-script || exit 0
 	  please consult its man page .
 	
+
+	
+	  Note that the packaging should normally not call up

Bug#835520: Seconding nine patches & seeking seconds for two more

[Holger Levsen]

On Thu, Aug 03, 2017 at 10:55:30AM -0400, Sean Whitton wrote:
> I second all of Andreas' patches except the 5th and 8th.  I've attached
> the diff to which my second applies.
> 
> The 5th and 8th patches introduce a normative requirement to use
> debhelper.  This is a first for policy, which up to now only comments
> that using debhelper is "easiest".

thanks again for spotting this, Sean!
 
> I've spoken to h01ger and gregoa IRL and they say that they missed the
> magic word "should" which is what makes debhelper required by these
> patches.  So I'm seeking seconds for the following replacement for
> Andreas' 5th and 8th patches:
> 
> diff --git a/policy.xml b/policy.xml
> index 3daa532..c6c7412 100644
> --- a/policy.xml
> +++ b/policy.xml
> @@ -8525,6 +8525,14 @@ fi
>  update-rc.d, please consult its man page
>  
> update-rc.d8.
>
> +  
> +It is easiest for packages not to call
> +update-rc.d directly, but instead use
> +debhelper programs that add the required
> +update-rc.d calls automatically.  See
> +dh_installinit,
> +dh_systemd_enable, etc.
> +  
>  
>  
>  
> @@ -8573,6 +8581,14 @@ invoke-rc.d package 
> action
>  invoke-rc.d, please consult its man page
>  
> invoke-rc.d8.
>
> +  
> +It is easiest for packages not to call
> +invoke-rc.d directly, but instead use
> +debhelper programs that add the required
> +invoke-rc.d calls automatically.  See
> +dh_installinit,
> +dh_systemd_start, etc.
> +  
>  
>  
>
> 
> -- 
> Sean Whitton

> diff --git a/policy.sgml b/policy.sgml
> index 9cd182b..2b37df8 100644
> --- a/policy.sgml
> +++ b/policy.sgml
> @@ -7053,12 +7053,6 @@ Built-Using: grub2 (= 1.99-9), loadlin (= 1.6e-1)
> in /run should be stored on a temporary
> file system.
>   
> - 
> -   Packages must not assume the /run
> -   directory exists or is usable without a dependency
> -   on initscripts (>= 2.88dsf-13.3) until the
> -   stable release of Debian supports /run.
> - 
> 
> 
>   
> @@ -7654,7 +7648,7 @@ test -f program-executed-later-in-script || 
> exit 0
>   
>  
>   
> -   Interfacing with the initscript system
> +   Interfacing with init systems
>  
> 
>   Maintainers should use the abstraction layer provided by
> @@ -7697,19 +7691,6 @@ test -f program-executed-later-in-script || 
> exit 0
>   
>  
>   
> -   By default update-rc.d will start services in
> -   each of the multi-user state runlevels (2, 3, 4, and 5)
> -   and stop them in the halt runlevel (0), the single-user
> -   runlevel (1) and the reboot runlevel (6).  The system
> -   administrator will have the opportunity to customize
> -   runlevels by simply adding, moving, or removing the
> -   symbolic links in /etc/rcn.d if
> -   symbolic links are being used, or by modifying
> -   /etc/runlevel.conf if the file-rc method
> -   is being used.
> - 
> -
> - 
> To get the default behavior for your package, put in your
> postinst script
> 
> @@ -7727,15 +7708,6 @@ test -f program-executed-later-in-script || 
> exit 0
>   
>  
>   
> -   This will use a default sequence number of 20.  If it does
> -   not matter when or in which order the init.d
> -   script is run, use this default.  If it does, then you
> -   should talk to the maintainer of the sysvinit
> -   package or post to debian-devel, and they will
> -   help you choose a number.
> - 
> -
> - 
> For more information about using update-rc.d,
> please consult its man pagesection="8">.
> @@ -7756,8 +7728,8 @@ test -f program-executed-later-in-script || 
> exit 0
>   
> The package maintainer scripts must use
> invoke-rc.d to invoke the
> -   /etc/init.d/* initscripts, instead of
> -   calling them directly.
> +   /etc/init.d/* initscripts or equivalent,
> +   instead of calling them directly.
>   
>  
>   
> @@ -7769,17 +7741,11 @@ test -f program-executed-later-in-script 
> || exit 0
>   
>  
>   
> -   Most packages will simply need to change:
> -   /etc/init.d/
> -    in their postinst
> -   and prerm scripts to:
> +   Most packages will simply use:
> 
> - if which invoke-rc.d >/dev/null 2>&1; then
>   invoke-rc.d package 
> - else
> - /etc/init.d/pack

Bug#798476: Returning to the requirement that Uploaders: contain humans

[Holger Levsen]

On Thu, Aug 03, 2017 at 06:04:17PM -0400, gregor herrmann wrote:
> On Thu, 03 Aug 2017 12:11:07 -0700, Russ Allbery wrote:
> […]
> Thanks for putting my thoughts (again!) into better words than I ever
> could!

+1
  
> > (I am entirely in favor of giving the MIA team more actual power.)
> (Me too. And, tangential to this discussion but still: maybe also to
> packaging teams, like for salvaging un(der)-maintained packages.)

agreed as well.

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.

And probably some pages where all uploading team members of given teams are
shown.


-- 
cheers,
Holger


signature.asc
Description: Digital signature

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

[Holger Levsen]

On Sat, Aug 05, 2017 at 04:35:35PM +0200, Bill Allombert wrote:
> > > Note that a prerequisite for such debian/changelog parsing would be
> > > that policy sets strict syntax and semantics requirements.
> > 
> > No, we do not need to block such a feature that would work for 90% of
> > packages until we have a policy about the [ name ] syntax.  It can begin
> > as a useful heuristic.
> 
> How do you get that it would work 90% of package ?
> Using [] for non-team members is very common.

for getting the _uploaders_ it's not even required to parse those fields, as
each upload has one uploader which is semantically strict defined already.


-- 
cheers,
Holger


signature.asc
Description: Digital signature

Bug#798476: Returning to the requirement that Uploaders: contain humans

[Holger Levsen]

On Sat, Aug 05, 2017 at 10:39:02AM +0300, Adrian Bunk wrote:
> > I don't understand this suggestion.  If it can be automatically
> > generated, just generate it when you need it -- why store it in the
> > source package?
> 
> What cannot be automatically generated is the other side of the 
> intersection:
> https://sources.debian.net/src/gnome-pkg-tools/0.19.9/pkg-gnome.team/
> 
> And you cannot automatically generate whom the team considers as members.
> 
> This is policy specific to a team, where some team members might only 
> work in git (see the lintian example) and others might have left the
> team recently.
 
I think using the uploaders: field to guess who's a team member is just a
work-around / an estimate, as we have nothing better. Yet it's very often
inaccurate as eg src:debian-edu shows, which at least I don't keep accurate
as I dont want to remove people unneccessarily (can be seen as stepping on 
their toes), have added people who will not upload (because currently this
field is indeed abused to generate team member metadata) and sometimes 
people were even added even though they don't want to belong to the team.

;tl;dr: I think we need a better system to manage team membership in Debian.
(Ab)using the uploaders: field gives an estimate or datapoint today, but we
have other means to gather this data.


-- 
cheers,
Holger


signature.asc
Description: Digital signature

Bug#798476: Returning to the requirement that Uploaders: contain humans

[Holger Levsen]

On Sat, Aug 05, 2017 at 09:05:46PM +0300, Adrian Bunk wrote:
> > I think using the uploaders: field to guess who's a team member is just a
> > work-around / an estimate, as we have nothing better.
> It is the official place to list co-maintainers.

you keep repeating this but its still broken by design.

> > ;tl;dr: I think we need a better system to manage team membership in Debian.
> > (Ab)using the uploaders: field gives an estimate or datapoint today, but we
> > have other means to gather this data.
> 
> No, we do not have currently any other means to gather who is considered 
> a team member by a team.
> 
> And that's the problem.
 
then it's time to fix this and not hold on to a band-aid solution which causes
grief.


-- 
cheers,
Holger


signature.asc
Description: Digital signature

Bug#732445: debian-policy should encourage verification of upstream cryptographic signaturse

[Holger Levsen]

On Mon, Aug 07, 2017 at 09:40:22AM -0700, Russ Allbery wrote:
> In an ideal world, we would have a documented set of metadata for finding
> upstream releases, of which uscan is just one implementation, and document
> that in Policy.  This patch doesn't attempt to do that; it tries to find a
> compromise between the current Policy language ("include a watch file for
> uscan") and specifying the location of the upstream signing keys, while
> deferring all of the details to the uscan documentation.
> 
> I decided to keep this all in the uscan section rather than adding a new
> section for the upstream signing key location, since right now this is all
> closely linked to uscan functionality (and to avoid renumbering sections
> or having a section weirdly separated from the uscan description).
> 
> How does this look to everyone?
 
looks good to me and the reasoning as well. happy to second if you think it's
ready.

thanks!


-- 
cheers,
Holger


signature.asc
Description: Digital signature

Bug#844431: Revised patch: seeking seconds

[Holger Levsen]

On Sat, Aug 12, 2017 at 11:23:14AM -0700, Sean Whitton wrote:
> I am seeking formal seconds for this patch, from any DD.
> 
> In particular:
> 
> - for now, we only require reproducibility when the set of environment
>   variable values set is exactly the same
> 
>   This is because
> 
>   - the reproducible builds team aren't yet totally clear on the
> variables that they think may be allowed to vary
> 
>   - we should wait until .buildinfo is properly documented in policy,
> and then we can refer to that file
> 
> - we don't require reproducibility when build paths vary
> 
>   This is because
> 
>   - since there is not a consensus on whether we should require this,
> and there is strong consensus on the requirement of reproducibility
> if the path does /not/ vary, this issue should not block this change.
> We should open a separate bug against debian-policy
> 
> diff --git a/policy/ch-source.rst b/policy/ch-source.rst
> index 127b125..cc4b020 100644
> --- a/policy/ch-source.rst
> +++ b/policy/ch-source.rst
> @@ -661,6 +661,22 @@ particularly complex or unintuitive source layout or 
> build system (for
>  example, a package that builds the same source multiple times to
>  generate different binary packages).
>  
> +Reproducibility
> +---
> +
> +Packages should build reproducibly, which for the purposes of this
> +document [#]_ means that given
> +
> +- a version of a source package unpacked at a given path;
> +- a set of versions of installed build dependencies;
> +- a set of environment variable values; and
> +- a build architecture,
> +
> +repeatedly building the source package on any machine of the same
> +architecture with those versions of the build dependencies installed
> +and exactly those environment variable values set will produce
> +bit-for-bit identical binary packages.
> +
>  .. [#]
> See the file ``upgrading-checklist`` for information about policy
> which has changed between different versions of this document.
> @@ -790,3 +806,7 @@ generate different binary packages).
> often creates either static linking or shared library conflicts, and,
> most importantly, increases the difficulty of handling security
> vulnerabilities in the duplicated code.
> +
> +.. [#]
> +   This is Debian's precisification of the `reproducible-builds.org
> +   definition `_.

very happily seconded, many thanks to everyone who has contributed to this bug
directly or "indirectly" (I'm thinking specifically about Lunar here).


-- 
cheers,
Holger (who watched 
http://meetings-archive.debian.net/pub/debian-meetings/2017/debconf17/reproducible-builds-status-update.vp8.webm
 today and was equally happy when seeing the whole audience agreeing this 
should be in policy - and the applause after Russ's closing statement was also 
very very nice…!)


signature.asc
Description: Digital signature

Bug#844431: Revised patch: seeking seconds

[Holger Levsen]

On Sat, Aug 12, 2017 at 01:18:23PM -0700, Russ Allbery wrote:
> > +Packages are encouraged to produce bit-for-bit identical binary packages 
> > even
> > +if most environment variables and build paths are varied. This is 
> > technically
> > +more difficult at the time of writing, but it is intended that this 
> > stricter
> > +definition would replace the above one, when appropriate in the future.
> 
> > If this type of "intent" wording is not appropriate for Policy then
> > disregard what I'm saying, I don't wish to block this patch for this
> > reason.
> 
> Oh, that's a good way to capture that.  This seems fine to me, and I have
> no objections to adding this advice.  Seconded the original with or
> without this addition.
 
I'm also seconding the original with or without this addition.


-- 
cheers,
Holger


signature.asc
Description: Digital signature

Bug#844431: Reproducibility in Policy

[Holger Levsen]

On Fri, Aug 11, 2017 at 08:35:47PM -0700, Russ Allbery wrote:
> Daniel Kahn Gillmor  writes:
> > I don't like the idea of hard-coding a fixed build path requirement into
> > debian policy. 

I don't *like* it neither but I think it's the sensible thing to do now.

> > We're over 80% with variable build paths in unstable
> > already, and i want to keep the pressure up on this.  The build location
> > should not influence the binary output.

I'd like to keep the pressure on this but and I think we can still that
while OTOH also trying to get closer to 100% first+too.

With build path variation reaching the worthwhile goal of having >98% 
reproducible
builds will be delayed by 1-2 years at least, so this is a classic "perfect is 
the
enemy of good". I don't do reproducible builds for purely academic reasons,
I foremost want them to increase the security of user systems.

> It shouldn't, but my understanding is that it currently does.  If you can
> fix that, that's great, but until that's been fixed, I don't see the harm
> in documenting this as a prerequisite for a reproducible build.  If we can
> relax that prerequisite later, great, but nothing about listing it here
> should reduce the pressure on making variable build paths work.  It just
> documents the current state of the world.

exactly.


-- 
cheers,
Holger


signature.asc
Description: Digital signature

Bug#844431: Revised patch: seeking seconds

[Holger Levsen]

On Sat, Aug 12, 2017 at 03:34:35PM -0700, Sean Whitton wrote:
> Here is an updated patch addressing these.  I reworded it to use
> 'recommended' and changed the tone to better suit policy.
> 
> Thank you Ximin, Russ and Johannes!
> 
> > "precisification" -> "more precise version"
> 
> Our definition is not actually a /version/ of the
> reproducible-builds.org definition -- that would imply that our
> definition could replace the reproducible-builds.org definition, like
> upgrading a package.
> 
> 'precisification' means roughly "filling out the missing specification
> when it is appropriate to fill it out", which is what the r-p.org
> definition instructs distributors to do.
> 
> diff --git a/policy/ch-source.rst b/policy/ch-source.rst
> index 127b125..6e32870 100644
> --- a/policy/ch-source.rst
> +++ b/policy/ch-source.rst
> @@ -661,6 +661,28 @@ particularly complex or unintuitive source layout or 
> build system (for
>  example, a package that builds the same source multiple times to
>  generate different binary packages).
>  
> +Reproducibility
> +---
> +
> +Packages should build reproducibly, which for the purposes of this
> +document [#]_ means that given
> +
> +- a version of a source package unpacked at a given path;
> +- a set of versions of installed build dependencies;
> +- a set of environment variable values;
> +- a build architecture; and
> +- a host architecture,
> +
> +repeatedly building the source package for the build architecture on
> +any machine of the host architecture with those versions of the build
> +dependencies installed and exactly those environment variable values
> +set will produce bit-for-bit identical binary packages.
> +
> +It is recommended that packages produce bit-for-bit identical binaries
> +even if most environment variables and build paths are varied.  It is
> +intended for this stricter standard to replace the above when it is
> +easier for packages to meet it.
> +
>  .. [#]
> See the file ``upgrading-checklist`` for information about policy
> which has changed between different versions of this document.
> @@ -790,3 +812,7 @@ generate different binary packages).
> often creates either static linking or shared library conflicts, and,
> most importantly, increases the difficulty of handling security
> vulnerabilities in the duplicated code.
> +
> +.. [#]
> +   This is Debian's precisification of the `reproducible-builds.org
> +   definition `_.

seconded & thanks for these improvements!


-- 
cheers,
Holger


signature.asc
Description: Digital signature

Bug#872288: debian-policy: document .buildinfo files

[Holger Levsen]

package: debian-policy
severity: wishlist
x-debbugs-cc: reproduciblle-bui...@lists.alioth.debian.org

Hi,

On Tue, Aug 15, 2017 at 11:49:22AM -0700, Russ Allbery wrote:
> I believe the planned next step here is to publish the *.buildinfo files,
> which contain a specification of the environment variables the build cares
> about, and then Policy can be modified to include a description of
> *.buildinfo files and how to use them.  As part of those changes, we'd
> certainly update the definition of reproducible to reference matching the
> environment specified in the corresponding *.buildinfo file.

thanks, (as discussed with Sean during dc17) I'm filing a bug for this now so
that we don't forget this.


-- 
cheers,
Holger


signature.asc
Description: Digital signature

Bug#844431: Revised patch: seeking seconds

[Holger Levsen]

On Tue, Aug 15, 2017 at 10:09:30PM +0300, Adrian Bunk wrote:
> > > I would expect the reproducible builds team to not submit any bugs
> > > regarding varied environment variables as long as as the official
> > > definition of reproducibility in policy states that this is not required
> > > for a package to be reproducible.

I believe we'll continue to file sensible bug reports like we have done in
the last four years.

> Another example is that a package that is reproducible according to the 
> policy definition must not show up as non-reproducible in tracker/DDPO 
> based on results from the reproducible infrastructure.
 
I disagree that we should modfiy the results of actual tests based on wishful
thinking or some definition somewhere, even if it's our beloved debian-policy.

It's certainly possible that a package becomes unreproducible, for known or
unknown reasons (hopefully by now we understand most of them (or have the means
to find out)), at any point in time. And then tracker/DDPO should certainly
show that…

Also what you are saying ("a package that is reproducible according to the
policy definition must not show up as non-reproducible in tracker/DDPO based
on results from the reproducible infrastructure") doesnt really makes sense:
if a package shows up as unreproducible somewhere, it's not reproducible
according to our definition!


-- 
cheers,
Holger


signature.asc
Description: Digital signature

Bug#844431: Revised patch: seeking seconds

[Holger Levsen]

On Tue, Aug 15, 2017 at 09:05:29PM +0300, Adrian Bunk wrote:
> Is identical building on any kernel required (and tested)?

no and no.

it's only required that the results is reproducible, that is bit by bit 
identical…
 
> Will every reproducible package in buster build identical on the
> bullseye+1 kernel 2022.11.321 ? [1]

my crystal ball is broken, sorry…
 
> [1] the wheezy LTS updates are now built on buildds running stretch
> kernels, and in buster we will have the similar situation that
> nearly everyting in the initial release will be built on stretch
> kernels while post-release updates will be built on buster,
> bullseye and bullseye+1 kernels
 
there surely are situations where different kernels (much like different
libraries) will cause variations in the build artifacts. many times it
will not matter and sometimes it will and we don't really have much experience
with that *yet*.

I'm inclined to file a bug report against dpkg to document the kernel 
used in the .buildinfo files and (hereby) am asking the reproducible builds team
for comments / advice on this.

And probably we should amend debian-policy for this too, but I also 
think we'd rather do this via a new bug report at some later point in time.

Thanks, Adrian, for making sure we don't forget (this pretty old aspect).


-- 
cheers,
Holger


signature.asc
Description: Digital signature

Bug#844431: debian-policy: Packages should be reproducible

[Holger Levsen]

On Thu, Aug 17, 2017 at 09:12:12PM -0700, Chris Lamb wrote:
> > Nix builds packages in isolation from each other. This ensures that
> > they are reproducible
> (As Georg writes, we are using different usages of reproducible.)

…though NixOS is also working on creating bit by bit reproducibly packages…


-- 
cheers,
Holger


signature.asc
Description: Digital signature

Bug#810381: debian-policy: Update wording of 5.6.26 VCS-* fields to reflect the need for security

[Holger Levsen]

On Wed, Aug 23, 2017 at 09:20:39PM -0700, Russ Allbery wrote:
> --- a/policy/ch-controlfields.rst
> +++ b/policy/ch-controlfields.rst
> @@ -962,6 +962,10 @@ repository where the Debian source package is developed.
>  
>  More than one different VCS may be specified for the same package.
>  
> +For both fields, any URLs given should use a scheme that provides
> +confidentiality (``https``, for example, rather than ``http`` or ``git``)
> +if the VCS repository supports it.
> +
 
seconded, though I wouldnt mind a rewording to "…a scheme with better
confidentiallity…" ot some such. but then, the important bit is that we 
recommend
https here…


-- 
cheers,
Holger


signature.asc
Description: Digital signature

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

[Holger Levsen]

On Fri, Sep 01, 2017 at 06:52:27AM +0200, Helmut Grohne wrote:
> According to codesearch.d.n, get-orig-source is implemented by less than
> 3000 source packages. This is not very low, but neither a high adoption
> rate. It certainly makes using get-orig-source somewhat useless on a
> distribution-scale. In contrast, we have some 22500 watch files, an
> order of magnitude more. I think it is obvious which mechanism has won.
 
agreed.

[...]
> I believe that if debhelper is not going to support us in increasing
> get-orig-source adoption, then we should just stop doing it and move on
> to watch files.

agreed.

> I am attaching the removal patch and call for seconds.
> 
> Helmut

> 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


signature.asc
Description: Digital signature

Bug#877674: [debian-policy] update links to the pdf and other formats of the documentation

[Holger Levsen]

On Wed, Oct 04, 2017 at 09:08:01AM +0200, Laura Arjona Reina wrote:
> From 044e61f437e74fad6ce7e7d19b52419402c53881 Mon Sep 17 00:00:00 2001
> From: Laura Arjona Reina 
> Date: Wed, 4 Oct 2017 08:32:38 +0200
> Subject: [PATCH] update the links to the other formats of the documentation
> 
> ---
>  policy/ch-scope.rst | 10 ++
>  1 file changed, 6 insertions(+), 4 deletions(-)
> 
> diff --git a/policy/ch-scope.rst b/policy/ch-scope.rst
> index 5637316..a4b38e2 100644
> --- a/policy/ch-scope.rst
> +++ b/policy/ch-scope.rst
> @@ -62,10 +62,12 @@ This manual is distributed via the Debian package
>  The current version of this document is also available from the Debian
>  web mirrors at https://www.debian.org/doc/debian-policy/. Also
>  available from the same directory are several other formats:
> -`policy.html.tar.gz
> -`_ and
> -`policy.pdf.gz
> -`_.  Included
> +`policy.epub
> +`_,
> +`policy.txt
> +`_ and
> +`policy.pdf
> +`_. Included
>  in both the same directory and in the debian-policy package is a
>  standalone copy of :doc:`upgrading-checklist`, which indicates policy
>  changes between versions of this document.
> -- 

seconded, thanks for your work on this!


-- 
cheers,
Holger


signature.asc
Description: PGP signature

Bug#859649: debian-policy: Please add CC0-1.0 to common-licenses

[Holger Levsen]

Hi,

On Fri, Dec 08, 2017 at 08:48:25PM +0100, Mattia Rizzolo wrote:
> > > diff --git a/policy/ch-docs.rst b/policy/ch-docs.rst index
> > > dc02bc6..1de221f 100644 --- a/policy/ch-docs.rst +++
> > > b/policy/ch-docs.rst @@ -208,11 +208,12 @@ important because
> > > ``copyright`` files must be extractable by mechanical
> > >  means.
> > >
> > >  Packages distributed under the Apache license (version 2.0), the
> > > -Artistic license, the GNU GPL (versions 1, 2, or 3), the GNU LGPL
> > > -(versions 2, 2.1, or 3), the GNU FDL (versions 1.2 or 1.3), and the
> > > -Mozilla Public License (version 1.1 or 2.0) should refer to the
> > > -corresponding files under ``/usr/share/common-licenses``, [#]_ rather
> > > -than quoting them in the copyright file.  +Artistic license, the
> > > Creative Commons CC0-1.0 license, the GNU GPL +(versions 1, 2, or 3),
> > > the GNU LGPL (versions 2, 2.1, or 3), the GNU FDL +(versions 1.2 or
> > > 1.3), and the Mozilla Public License (version 1.1 or +2.0) should
> > > refer to the corresponding files under
> > > +``/usr/share/common-licenses``, [#]_ rather than quoting them in the
> > > +copyright file.
> > >
> > >  You should not use the copyright file as a general ``README``
> > >  file. If your package has such a file it should be installed in
> > > @@ -341,6 +342,7 @@ please see :ref:`s-dpkgchangelog`.
> > >  .. [#]
> > > In particular, ``/usr/share/common-licenses/Apache-2.0``,
> > > ``/usr/share/common-licenses/Artistic``,
> > > + ``/usr/share/common-licenses/CC0-1.0``,
> > > ``/usr/share/common-licenses/GPL-1``,
> > > ``/usr/share/common-licenses/GPL-2``,
> > > ``/usr/share/common-licenses/GPL-3``,
> 
> Seconded.

also seconded.


-- 
cheers,
Holger


signature.asc
Description: PGP signature

Bug#742364: Patch to document debian/missing-sources

[Holger Levsen]

On Sat, Dec 09, 2017 at 12:16:35PM -0700, Sean Whitton wrote:
> I am seeking seconds for the following patch:
> 
> > diff --git a/policy/ch-source.rst b/policy/ch-source.rst
> > index 37c4442..f8f768f 100644
> > --- a/policy/ch-source.rst
> > +++ b/policy/ch-source.rst
> > @@ -686,6 +686,26 @@ even if most environment variables and build paths are 
> > varied.  It is
> >  intended for this stricter standard to replace the above when it is
> >  easier for packages to meet it.
> >  
> > +Missing sources: ``debian/missing-sources``
> > +---
> > +
> > +Sometimes upstream does not include the source code for some files in
> > +the upstream tarball.  In order to satisfy the DFSG for packages in
> > +``main`` or ``contrib``, you should either:
> > +
> > +1. repack the upstream tarball to include those sources; or
> > +2. include a copy of the sources in the ``debian/missing-sources``
> > +   directory.
> > +
> > +There is an optional convention to organise the contents of
> > +``debian/missing-sources`` in the following way.  For a sourceless
> > +file ``foo`` in the subdirectory ``bar`` of the upstream tarball,
> > +where the source of ``foo`` has extension ``baz``, the source is to be
> > +located at ``debian/missing-sources/bar/foo.baz``.  For example,
> > +according to this convention, the C source code of an executable
> > +``checksum/util`` is to be located at
> > +``debian/missing-sources/checksum/util.c``.
> > +
> >  .. [#]
> > See the file ``upgrading-checklist`` for information about policy
> > which has changed between different versions of this document.

seconded & thanks for your work on this!


-- 
cheers,
Holger


signature.asc
Description: PGP signature

Bug#682347: mark 'editor' virtual package name as obsolete

[Holger Levsen]

On Mon, Dec 25, 2017 at 05:02:01PM -0800, Russ Allbery wrote:
> I think there are three options, and I'd love to get feedback on which of
> those three options we should take.
> 
> 1. Status quo: there is an undocumented editor virtual package, Policy
>says that nothing has to provide or depend on it, and some random
>collection of editors provide it.  I think this is a bad place to be,
>so I would hope we can rule out sticking with that status quo.
> 
> 2. Document editor and recommend everyone implement it properly.  Since
>we're going to allow packages to depend on editor, I think providing it
>would need to be a should, so that's going to be a lot of buggy (but
>not RC-buggy) editor packages.  But it would get us to a clean
>dependency system. 
> 
> 3. Mark editor obsolete.

looking at these three options for "for doing the best solution" I
think we should go for 2 or maybe 3, but then I think it's a sensible
thing to depend on, so I would say we should go with option 2.

I"m also very fine with this resulting in some trivial bugs being filed.


-- 
cheers,
Holger


signature.asc
Description: PGP signature

Re: Bug#886219: lintian should be less pedantic about latest policy version

[Holger Levsen]

On Wed, Jan 03, 2018 at 11:05:09PM +, Chris Lamb wrote:
> > > - ancient-standards-version should be triggered when S-V contains a
> > >   release of Policy from the previous stable release cycle
> > This sounds good to me.

reading this once again I'm reminded that this feeds the notion that our
current stable release is ancient :-/

But I guess that ship has sailed…

> Same here Is this the consensus view? If so, I can go ahead and make
> the change.

thanks.


-- 
cheers,
Holger


signature.asc
Description: PGP signature

Bug#890142: debian-policy: Please provide a backport of the package

[Holger Levsen]

Hi Gustavo,

frankly, and really just curious, but… what's the point of this
backport? you can always read the latest version at
https://www.debian.org/doc/debian-policy/ (ok, I see this needs network,
but…)


-- 
cheers,
Holger


signature.asc
Description: PGP signature

Bug#890142: debian-policy: Please provide a backport of the package

[Holger Levsen]

On Mon, Feb 12, 2018 at 10:17:29AM +0800, gustavo panizzo wrote:
> When I package something I usually have
> less /usr/share/doc/debian-policy/upgrading-checklist.txt.gz
> running in another shell

ok, I see your use case now. :)

Maybe it helps to show you my usage: I usually just run 

schroot less /usr/share/doc/debian-policy/upgrading-checklist.txt.gz

:)


-- 
cheers,
Holger


signature.asc
Description: PGP signature

Bug#881431: proposed wording

[Holger Levsen]

On Thu, Mar 29, 2018 at 08:12:15AM -0700, Sean Whitton wrote:
> Seeking seconds:
> 
> > §3.2.2 Uniqueness of version numbers
> >
> > The part of the version number after the epoch must not be reused for
> > a version of the package with different contents once the package has
> > been accepted into the archive, even if the version of the package
> > previously using that part of the version number is no longer present
> > in any archive suites.
> >
> > Epochs are not included in the names of the files that compose source
> > packages, or in the filenames of binary packages, so reusing a version
> > number, even if the epoch differs, results in identically named files
> > with different contents.  This can cause various problems.
> >
> > If you find yourself wanting to reuse the part of a version number
> > after the epoch, you can just bump the Debian revision, which doesn't
> > need to start at 1 or be consecutive.
 
seconded, thanks.


-- 
cheers,
Holger


signature.asc
Description: PGP signature

Bug#892142: debian-policy: update example to use default-mta instead of exim

[Holger Levsen]

On Mon, Mar 05, 2018 at 05:12:16PM -0800, Jonathan Nieder wrote:
> Thanks!  This is non-normative, so a policy editor can just make the
> change.

I'll second it nonetheless :)

> How about this patch?  It should be possible to apply by downloading
> this message as an mbox and using "git am --scissors mbox-file".
> 
> -- >8 --
> Subject: Use default-mta in MTA dependency example
> 
> Reported-by: Paul Wise 
> Closes: #892142
> ---
>  debian/changelog| 5 +
>  policy/ch-relationships.rst | 2 +-
>  2 files changed, 6 insertions(+), 1 deletion(-)
> 
> diff --git a/debian/changelog b/debian/changelog
> index 0ec082f..99f6068 100644
> --- a/debian/changelog
> +++ b/debian/changelog
> @@ -1,5 +1,6 @@
>  debian-policy (4.1.4.0) UNRELEASED; urgency=medium
>  
> +  [ Sean Whitton ]
>* Policy: Drop get-orig-source rules target
>  Wording: Helmut Grohne 
>  Seconded: Holger Levsen 
> @@ -29,6 +30,10 @@ debian-policy (4.1.4.0) UNRELEASED; urgency=medium
>* Fix indentation of description of the clean target (Closes: #889960).
>  Thanks Ferenc Wágner for the report.
>  
> +  [ Jonathan Nieder ]
> +  * Use default-mta instead of exim in dependency example (Closes: #892142).
> +Thanks to Paul Wise for the report.
> +
>   -- Sean Whitton   Fri, 29 Dec 2017 18:46:59 +
>  
>  debian-policy (4.1.3.0) unstable; urgency=medium
> diff --git a/policy/ch-relationships.rst b/policy/ch-relationships.rst
> index 77cf0e1..1eaa422 100644
> --- a/policy/ch-relationships.rst
> +++ b/policy/ch-relationships.rst
> @@ -45,7 +45,7 @@ For example, a list of dependencies might appear as:
>  
>  Package: mutt
>  Version: 1.3.17-1
> -Depends: libc6 (>= 2.2.1), exim | mail-transport-agent
> +Depends: libc6 (>= 2.2.1), default-mta | mail-transport-agent
>  
>  Relationships may be restricted to a certain set of architectures. This
>  is indicated in brackets after each individual package name and the
> -- 
 
seconded.


-- 
cheers,
Holger


signature.asc
Description: PGP signature

Bug#881431: proposed wording

[Holger Levsen]

On Wed, Apr 04, 2018 at 11:47:09AM -0700, Sean Whitton wrote:
> > §3.2.2 Uniqueness of version numbers
> >
> > The part of the version number after the epoch must not be reused for
> > a version of the package with different contents once the package has
> > been accepted into the archive, even if the version of the package
> > previously using that part of the version number is no longer present
> > in any archive suites.
> >
> > This uniqueness requirement applies to the version numbers of source
> > packages and of binary packages, even if the source package producing
> > a given binary package changes.  Thus the version numbers which a
> > binary package must not reuse includes the version numbers of any
> > versions of the binary package ever accepted into the archive, under
> > any source package.
> >
> > Additionally, for non-native packages, the upstream version must not
> > be reused for different upstream source code, so that for each source
> > package name and upstream version number there exists exactly one
> > original source archive contents [reference to defintiion of that].
> >
> > The reason for these restrictions is as follows.  Epochs are not
> > included in the names of the files that compose source packages, or in
> > the filenames of binary packages, so reusing a version number, even if
> > the epoch differs, results in identically named files with different
> > contents.  This can cause various problems.
> >
> > If you find yourself wanting to reuse the part of a version number
> > after the epoch, you can just increment the Debian revision, which
> > doesn't need to start at 1 or be consecutive.

seconded, thanks.


-- 
cheers,
Holger


signature.asc
Description: PGP signature

Re: missing recommends are not RC severity

[Holger Levsen]

hi,

dropping -devel@, adding -release@ and -policy@, I'm wondering if this
should be resolved somehow...:

A few days ago I wrote:
> > >if your package recommends a package which is not available, this is a
> > >normal bug, not one with RC severity (and neither an important one).

To which on Tue, Apr 17, 2018 at 01:04:47PM +, Scott Kitterman wrote:
> > Policy 2.2.1 pretty clearly says otherwise.

Then on Tue, Apr 17, 2018 at 06:14:56PM +0500, Andrey Rahmatullin wrote:
> While the release policy says "Packages in main cannot require any
> software outside of main for execution or compilation. "Recommends:" lines
> do not count as requirements."


-- 
cheers,
Holger


signature.asc
Description: PGP signature

Bug#901160: Updating the description of the Standards-Version field

[Holger Levsen]

On Sun, Jun 10, 2018 at 01:16:07AM -0700, Sean Whitton wrote:
> Here is the patch for seconding:
> 
> > From 3bad0c91264c707ee163af93e45d3b53e5e4f880 Mon Sep 17 00:00:00 2001
> > From: Sean Whitton 
> > Date: Sun, 10 Jun 2018 08:11:52 +
> > Subject: [PATCH] update description of usage of Standards-Version field
> >
> > ---
> >  policy/ch-controlfields.rst |  3 ++-
> >  policy/ch-source.rst| 30 +-
> >  2 files changed, 19 insertions(+), 14 deletions(-)
> >
> > diff --git a/policy/ch-controlfields.rst b/policy/ch-controlfields.rst
> > index 0771346..ecac5de 100644
> > --- a/policy/ch-controlfields.rst
> > +++ b/policy/ch-controlfields.rst
> > @@ -521,7 +521,8 @@ Their syntax and semantics are described in
> >  ~
> >
> >  The most recent version of the standards (the policy manual and
> > -associated texts) with which the package complies.
> > +associated texts) with which the package complies.  See
> > +:ref:`s-standardsversion`.
> >
> >  The version number has four components: major and minor version number
> >  and major and minor patch level. When the standards change in a way that
> > diff --git a/policy/ch-source.rst b/policy/ch-source.rst
> > index e3b1981..7484772 100644
> > --- a/policy/ch-source.rst
> > +++ b/policy/ch-source.rst
> > @@ -10,18 +10,27 @@ Source packages should specify the most recent version 
> > number of this
> >  policy document with which your package complied when it was last
> >  updated.
> >
> > -This information may be used to file bug reports automatically if your
> > -package becomes too much out of date.
> > -
> >  The version is specified in the ``Standards-Version`` control field. The
> >  format of the ``Standards-Version`` field is described in
> >  :ref:`s-f-Standards-Version`.
> >
> > -You should regularly, and especially if your package has become out of
> > -date, check for the newest Policy Manual available and update your
> > -package, if necessary. When your package complies with the new standards
> > -you should update the ``Standards-Version`` source package field and
> > -release it.  [#]_
> > +This information may be used to file bug reports automatically if your
> > +package becomes too much out of date.
> > +
> > +For a package to have an old Standards-Version value is not *itself* a
> > +bug, however.  It just means that no-one has yet reviewed the package
> > +with changes to the standards in mind.
> > +
> > +When updating existing packaging, the Standards-Version must not be
> > +updated except after reviewing the changes between the old and the new
> > +versions of the standards and updating your package if necessary (the
> > +:doc:`upgrading-checklist` can help with this task).
> > +
> > +A very old Standards-Version can mean that infelicities in the package
> > +are likely.  It is recommended that each package be reviewed at least
> > +once per Debian release, so a Standards-Version older than the
> > +previous Debian release is indicative of work (if only review work)
> > +that needs doing.
> >
> >  .. _s-pkg-relations:
> >
> > @@ -695,11 +704,6 @@ according to this convention, the C source code of an 
> > executable
> >  ``checksum/util`` is to be located at
> >  ``debian/missing-sources/checksum/util.c``.
> >
> > -
> > -.. [#]
> > -   See the file ``upgrading-checklist`` for information about policy
> > -   which has changed between different versions of this document.
> > -
> >  .. [#]
> > Rationale:
> >
> > --
> > 2.14.2

seconded. (with or without the sentence about filing bugs.)


-- 
cheers,
Holger, who wants to automate everything as much as possible,
including filing bugs.


signature.asc
Description: PGP signature

Bug#886258: Clarify whether or not the Standards-Version field must be present, or lower Lintian tag severity

[Holger Levsen]

On Wed, Jul 18, 2018 at 08:08:55PM +0800, Sean Whitton wrote:
> Given that it seems we have a strong project consensus on always
> including the field, seeking seconds to make Policy reflect that:
> 
> > diff --git a/policy/ch-controlfields.rst b/policy/ch-controlfields.rst
> > index 77ff81f..44080c9 100644
> > --- a/policy/ch-controlfields.rst
> > +++ b/policy/ch-controlfields.rst
> > @@ -121,7 +121,7 @@ package) are:
> >
> >  -  :ref:`Build-Depends et al `
> >
> > --  :ref:`Standards-Version ` (recommended)
> > +-  :ref:`Standards-Version ` (mandatory)
> >
> >  -  :ref:`Homepage `
> >
> > @@ -238,7 +238,7 @@ is described above, in :ref:`s-controlsyntax`.
> >
> >  -  :ref:`Dgit `
> >
> > --  :ref:`Standards-Version ` (recommended)
> > +-  :ref:`Standards-Version ` (mandatory)
> >
> >  -  :ref:`Build-Depends et al `

seconded.


-- 
cheers,
Holger


signature.asc
Description: PGP signature

Bug#459427: Patch seeking seconds on changelog vs. NEWS handling

[Holger Levsen]

On Thu, Jul 26, 2018 at 01:05:16PM +0800, Sean Whitton wrote:
> diff --git a/policy/ch-docs.rst b/policy/ch-docs.rst
> index 1de221f..e990f34 100644
> --- a/policy/ch-docs.rst
> +++ b/policy/ch-docs.rst
> @@ -255,32 +255,45 @@ files may be installed into ``/usr/share/doc/package``.
>  
>  .. _s-changelogs:
>  
> -Changelog files
> 
> +Changelog files and release notes
> +-
>  
>  Packages that are not Debian-native must contain a compressed copy of
>  the ``debian/changelog`` file from the Debian source tree in
>  ``/usr/share/doc/package`` with the name ``changelog.Debian.gz``.
>  
> -If an upstream changelog is available, it should be accessible as
> -``/usr/share/doc/package/changelog.gz`` in plain text. If the upstream
> -changelog is distributed in HTML, it should be made available in that
> -form as ``/usr/share/doc/package/changelog.html.gz`` and a plain text
> -``changelog.gz`` should be generated from it using, for example,
> -``lynx -dump -nolist``. If the upstream changelog files do not already
> -conform to this naming convention, then this may be achieved either by
> -renaming the files, or by adding a symbolic link, at the maintainer's
> +If an upstream release notes file is available, containing a summary
> +of changes between upstream releases intended for end users of the
> +package and often called ``NEWS``, it should be accessible as
> +``/usr/share/doc/package/NEWS.gz``.  An older practice of installing
> +the upstream release notes as ``/usr/share/doc/package/changelog.gz``
> +is permitted but deprecated.
> +
> +If there is an upstream changelog available, it may be made available
> +as ``/usr/share/doc/package/changelog.gz``.
> +
> +If either of these files are distributed in HTML, they should be made
> +available at ``/usr/share/doc/package/NEWS.html.gz`` and
> +``/usr/share/doc/package/changelog.html.gz`` respectively, and plain
> +text versions ``NEWS.gz`` and ``changelog.gz`` should be generated
> +from them, using, for example, ``lynx -dump -nolist``.
> +
> +If the upstream release notes or changelog do not already conform to
> +this naming convention, then this may be achieved either by renaming
> +the files, or by adding a symbolic link, at the maintainer's
>  discretion.  [#]_
>  
>  All of these files should be installed compressed using ``gzip -9``, as
>  they will become large with time even if they start out small.
>  
> -If the package has only one changelog which is used both as the Debian
> -changelog and the upstream one because there is no separate upstream
> -maintainer then that changelog should usually be installed as
> -``/usr/share/doc/package/changelog.gz``; if there is a separate upstream
> -maintainer, but no upstream changelog, then the Debian changelog should
> -still be called ``changelog.Debian.gz``.
> +If the package has only one file which is used both as the Debian
> +changelog and the upstream release notes or changelog, because there
> +is no separate upstream maintainer, then that file should usually be
> +installed as ``/usr/share/doc/package/NEWS.gz`` or
> +``/usr/share/doc/package/changelog.gz`` (depending on whether the file
> +is release notes or a changelog); if there is a separate upstream
> +maintainer, but no upstream release notes or changelog, then the
> +Debian changelog should still be called ``changelog.Debian.gz``.

seconded.

(though personally I would prefer not to save a few bytes and not gzip
those files, but meh, thats another topic :)


-- 
cheers,
Holger


signature.asc
Description: PGP signature

Bug#883950: Next steps on "[GPL-3+]" proposal

[Holger Levsen]

On Thu, Jul 26, 2018 at 08:47:08PM -0700, Russ Allbery wrote:
> A set of files under the license GPL-3+ and [GPL-3+] are under exactly the
> same license, so it is confusing and strange to use different identifiers
> based on a technical point about what information is included elsewhere in
> the copyright file.  Furthermore, the brackets are entirely opaque.  They
> convey no meaning to a person who hasn't read the specification, which
> seems inappropriate for a specification that's supposed to still be
> human-readable.

with my "I haven't read #883950"-hat, I can confirm what Russ said here.


-- 
cheers,
Holger, to give another data point


signature.asc
Description: PGP signature

Bug#883950: Next steps on "[GPL-3+]" proposal

[Holger Levsen]

On Thu, Aug 02, 2018 at 12:31:52PM +0200, Guillem Jover wrote:
> As has been mentioned before, you should not need to bump the version
> if you don't use the new format; if you do, you have aleady changed
> the file anyway and might as well change the version digit.
 
exactly.

I'm kinda surprised about this discussion, I didn't expect anyone here
wanting to change a versioned machine readable format, without bumping
that version number...

and of course lintian shouldnt complain if the old format is used.


-- 
cheers,
Holger


signature.asc
Description: PGP signature

Re: Bug#904934: [debian-policy] Add footnote to find easily the corresponding days for the urgency field

[Holger Levsen]

On Thu, Aug 02, 2018 at 01:43:46PM +0800, Sean Whitton wrote:
> I think we have stronger guarantees that discussions in the BTS will
> remain available for as long as Debian exists than we do with salsa, and
> so am against moving any discussions to salsa because such records are
> important for our process.  

fully agreed.

there is no project guarantee salsa will stay forever, while this exists
for the BTS.


-- 
cheers,
Holger


signature.asc
Description: PGP signature

Bug#905251: debian-policy: 4.9 paragraph is unclear (incompatibles statements)

[Holger Levsen]

Hi Sean,

On Mon, Aug 06, 2018 at 06:04:02PM +0800, Sean Whitton wrote:
> So how about making three changes:
> 
> 1) Add something like "In particular, build command lines should not be
>abbreviated."  Then we are not leaving that particular case up to
>maintainer judgement, without removing the general recommendation.
> 
> 2) Add some examples of what should usually not be included, or perhaps
>just say that if some output makes a build log tens of megabytes in
>size, it should not be included.
> 
> 3) Deal with the 'maximally' problem with one of the rewordings I
>suggested in a previous message -- we want to include mention that
>it's debian/rules that does the work of enabling the reasonable
>verbosity.

those seem all very reasonable to me, thanks!


-- 
cheers,
Holger

---
holger@(debian|reproducible-builds).org


signature.asc
Description: PGP signature

Bug#904248: Beginnings of a patch to add netbase to build-essential

[Holger Levsen]

On Mon, Aug 06, 2018 at 07:06:45PM +0800, Sean Whitton wrote:
> Here is the complete patch, for which I am seeking seconds:
> 
> diff --git a/policy/ch-source.rst b/policy/ch-source.rst
> index 9e7d79c..011893c 100644
> --- a/policy/ch-source.rst
> +++ b/policy/ch-source.rst
> @@ -40,9 +40,25 @@ example, if building a package requires a certain 
> compiler, then the
>  compiler should be specified as a build-time dependency.
> 
>  It is not necessary to explicitly specify build-time relationships on a
> -minimal set of packages that are always needed to compile, link and put
> -in a Debian package a standard "Hello World!" program written in C or
> -C++. The required packages are called *build-essential*, and an
> +minimal set of packages that are always needed
> +
> +- to compile, link and put in a Debian package a standard "Hello
> +  World!"  program written in C or C++;
> +
> +- for the package build to resolve the system hostname to a
> +  fully-qualified domain name using the C standard library; and
> +
> +- for the package build to look up longstanding and conventionally
> +  available service and protocol names and numbers, either by directly
> +  reading /etc/services and /etc/protocols, or by using the
> +  corresponding functions from the C standard library. [#]_
> +
> +  (If the package needs to look up a more recent service or protocol,
> +  and certainly if the service or protocol was not listed in these
> +  files in the package's targeted Debian releases, an appropriate
> +  versioned build-dependency is needed.)
> +
> +The required packages are called *build-essential*, and an
>  informational list can be found in
>  ``/usr/share/doc/build-essential/list`` (which is contained in the
>  ``build-essential`` package).  [#]_
> @@ -757,6 +773,10 @@ according to this convention, the C source code of an 
> executable
>  ``debian/missing-sources/checksum/util.c``.
> 
>  .. [#]
> +   The functionality described in these last two list items is
> +   provided by the "netbase" package at the time of writing.
> +
> +.. [#]

seconded, thanks.


-- 
cheers,
Holger

---
holger@(debian|reproducible-builds).org


signature.asc
Description: PGP signature

Bug#907313: Lack of guidelines on purging conffiles in stateless packages

[Holger Levsen]

On Sun, Aug 26, 2018 at 12:41:48PM +0200, Gioele Barabucci wrote:
> the policy lacks guidelines on how to treat user-provided configuration
> files during configuration purging in packages for programs that follow the
> "stateless" paradigm (default in `/usr`, override in `/etc`).

btw, I think the term 'stateless' is a misnomer here, clearly there's
state being kept in /etc.

then, policy says what to do with configuration files when a package is
purged: they should be removed. :-D

> That means that purging the package will remove also all the configuration
> files provided by the sysadmin. Should this be the normality or should this
> be avoided?

yes, that should be the normality and this is how purge worked since
basically forever, and I don't see a new compelling reason to change
this. 

If you want to keep your configuration files/modifications, don't purge
a package. And do backups.

> Could the policy be more explicit on what maintscripts are supposed to do in
> packages for stateless programs?

I don't think this (nice) new paradigm changes anything and do think
that all types of configuration files should be treated the same.

I'd suggest to close this bug as 'wontfix'.


-- 
cheers,
Holger

---
holger@(debian|reproducible-builds).org


signature.asc
Description: PGP signature

Bug#907313: Lack of guidelines on purging conffiles in stateless packages

[Holger Levsen]

On Sun, Aug 26, 2018 at 12:11:55PM -0700, Russ Allbery wrote:
> > I don't think this (nice) new paradigm changes anything and do think
> > that all types of configuration files should be treated the same.
> 
> > I'd suggest to close this bug as 'wontfix'.
> 
> If we do want to recommend removing those files, we shouldn't close this
> bug as wontfix, since that's not particularly obvious from Policy at
> present.  Those files are not conffiles of the package, and we're not
> entirely explicit that either they are configuration files of the package
> (I think they are, but it feels useful to clearly say this) or that all
> configuration files should be removed by the postrm script on purge (we
> sort of say this, but not as clearly as we could, at least in a quick
> check).

agreed. thanks for pointing this out.


-- 
cheers,
Holger

---
holger@(debian|reproducible-builds).org


signature.asc
Description: PGP signature

Bug#910783: Remove doc-base recommendation

[Holger Levsen]

On Thu, Oct 11, 2018 at 06:10:43PM -0700, Russ Allbery wrote:
> I wish I had some feel for how many people were actually using doc-base as
> a client, though.  How many users actually run the tools and use them to
> find documentation, and is it successful for them?

to give a data-point: I have no idea how to use doc-base.

If I search documentation I use a shell to cd into /usr/share/doc/$pkg
and run ls there. Or use apropos term. Or I search the web.

How do I use doc-base?


-- 
cheers,
Holger

---
   holger@(debian|reproducible-builds|layer-acht).org
   PGP fingerprint: B8BF 5413 7B09 D35C F026 FE9D 091A B856 069A AA1C


signature.asc
Description: PGP signature

Bug#912581: Slightly relax the requirement to include verbatim copyright information

[Holger Levsen]

On Thu, Nov 01, 2018 at 07:24:39AM -0700, Sean Whitton wrote:
> diff --git a/policy/ch-archive.rst b/policy/ch-archive.rst
> index c429f71..72764a9 100644
> --- a/policy/ch-archive.rst
> +++ b/policy/ch-archive.rst
> @@ -183,10 +183,18 @@ In addition, the packages in *non-free*
>  Copyright considerations
>  
>  
> +Every package must be accompanied by a verbatim copy of its
> +distribution license in the file ``/usr/share/doc/package/copyright``.
> +
>  Every package must be accompanied by a verbatim copy of its copyright
> -information and distribution license in the file
> -``/usr/share/doc/package/copyright`` (see
> -:ref:`s-copyrightfile` for further details).
> +information, unless its distribution license explicitly permits this
> +information to be excluded from distributions of binaries built from
> +the source.  In such cases, a verbatim copy of its copyright
> +information should normally still be included, but need not be if
> +creating and maintaining a copy of that information involves
> +significant time and effort.
> +
> +See :ref:`s-copyrightfile` for further details.
>  
>  We reserve the right to restrict files from being included anywhere in
>  our archives if
> diff --git a/policy/ch-source.rst b/policy/ch-source.rst
> index 7c6c4e8..dc80243 100644
> --- a/policy/ch-source.rst
> +++ b/policy/ch-source.rst
> @@ -210,12 +210,13 @@ packages, please see :ref:`s-changelogs`.
>  Copyright: ``debian/copyright``
>  ---
>  
> -Every package must be accompanied by a verbatim copy of its copyright
> -information and distribution license in the file
> -``/usr/share/doc/package/copyright`` (see
> -:ref:`s-copyrightfile` for further details). Also see
> -:ref:`s-pkgcopyright` for further considerations related
> -to copyrights for packages.
> +Every package must be accompanied by a verbatim copy of its
> +distribution license in the file ``/usr/share/doc/package/copyright``.
> +
> +This file is usually required to contain a verbatim copy of the
> +package's copyright information, too; see :ref:`s-copyrightfile` and
> +:ref:`s-pkgcopyright` for details, and for further considerations
> +related to copyrights for packages.

seconded & thanks, Sean.


-- 
cheers,
Holger

---
   holger@(debian|reproducible-builds|layer-acht).org
   PGP fingerprint: B8BF 5413 7B09 D35C F026 FE9D 091A B856 069A AA1C


signature.asc
Description: PGP signature

Bug#850171: Recommend that manpages contain an EXAMPLES section

[Holger Levsen]

On Sun, Nov 04, 2018 at 10:28:31AM +0100, Mattia Rizzolo wrote:
> I'm wary of one thing: I don't really want to be bothered by this.

same here.

> Going around patching upstream's manpages to add an EXAMPLE section is
> totally busywork, not mention possibly even hard to do for all the
> autogenerated manpages.
> What I mean is: if there is really enough people wanting this change by
> all means do it, but 1. make the wording clear that is really optional
> (in this view, I see "recommended" as too strong a word) and 2. I really
> hope lintian won't start bothering for this.

totally agreed.

manpages are great for cli software but for lots of desktop software
most of its users (and developers?) dont even know what manpages are, or
how to use them. thus I consider current policy (which treats the
absence of a manpage for *every* program, utility, and function in
Debian as a bug) already to be too strong today.


-- 
cheers,
Holger

---
   holger@(debian|reproducible-builds|layer-acht).org
   PGP fingerprint: B8BF 5413 7B09 D35C F026 FE9D 091A B856 069A AA1C


signature.asc
Description: PGP signature

Bug#913295: debian-policy: Update location of example init.d script

[Holger Levsen]

On Fri, Nov 09, 2018 at 08:17:42AM +, Dmitry Bogatov wrote:
> From e3457ee94e7293dbd59c9651d82d0c07fda50b33 Mon Sep 17 00:00:00 2001
> From: Dmitry Bogatov 
> Date: Fri, 9 Nov 2018 08:02:01 +
> Subject: [PATCH] Update information about example init.d script
> 
> According to #913154, there is consensus, that `/etc/init.d/skeleton'
> is not suitable location for example init.d script, and actually
> duplicates information, provided by init-d-script(5) manpage.
> ---
>  policy/ch-opersys.rst | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
> 
> diff --git a/policy/ch-opersys.rst b/policy/ch-opersys.rst
> index ffd19d3..59c92ec 100644
> --- a/policy/ch-opersys.rst
> +++ b/policy/ch-opersys.rst
> @@ -628,7 +628,7 @@ Example
>  
>  Examples on which you can base your systemd integration on is available in
>  the man page systemd.unit(8). An example on which you can base your
> -``/etc/init.d`` scripts is found in ``/etc/init.d/skeleton``.
> +``/etc/init.d`` scripts is available in the man page init-d-script(5).

seconded. (while I'm actually not convinced this needs seconding, esp.
if reality changed.)


-- 
cheers,
Holger

---
   holger@(debian|reproducible-builds|layer-acht).org
   PGP fingerprint: B8BF 5413 7B09 D35C F026 FE9D 091A B856 069A AA1C


signature.asc
Description: PGP signature

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

[Holger Levsen]

On Sat, Nov 10, 2018 at 08:38:07PM -0700, Sean Whitton wrote:
> 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``.
> +

seconded, thanks.


-- 
cheers,
Holger

---
   holger@(debian|reproducible-builds|layer-acht).org
   PGP fingerprint: B8BF 5413 7B09 D35C F026 FE9D 091A B856 069A AA1C


signature.asc
Description: PGP signature

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

[Holger Levsen]

On Sun, Nov 11, 2018 at 09:10:02PM +0100, Bill Allombert wrote:
> More accurately: I am not sure the Debian archive is ready for these
> bugs to be RC, especially since they are usually upstream bugs.
 
agreed & thanks for catching this.

> I can be convinced otherwise with data, though.

:)

> 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``.

better indeed, thanks and secoded.


-- 
cheers,
Holger

---
   holger@(debian|reproducible-builds|layer-acht).org
   PGP fingerprint: B8BF 5413 7B09 D35C F026 FE9D 091A B856 069A AA1C


signature.asc
Description: PGP signature

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

[Holger Levsen]

On Mon, Nov 12, 2018 at 09:32:51PM +0100, Bill Allombert wrote:
> > > I can be convinced otherwise with data, though.
> > :)
> If you still run 
> https://tests.reproducible-builds.org

we do, however, this setup is for testing for reproducible builds and
not trying 'random stuff' which might cause wide FTBFS problems, which
would be reported (quite prominently) to tracker.d.o and UDD.

> you could "chmod 1770 /tmp" and set TMPDIR to something valid and see
> how many packages FTBFS.

the above said, we are discussing "Vary setting TMPDIR during reproducibility
testing" in #913557 but that's also not trivial to do, see that bug for
details.


-- 
cheers,
Holger

---
   holger@(debian|reproducible-builds|layer-acht).org
   PGP fingerprint: B8BF 5413 7B09 D35C F026 FE9D 091A B856 069A AA1C


signature.asc
Description: PGP signature

Bug#913659: Document that not all bugs are policy violations

[Holger Levsen]

On Tue, Nov 13, 2018 at 05:51:15PM +, Ian Jackson wrote:
> I suggest adding something like this to s1.1, "Scope", as a new 3rd
> paragraph:
> 
>   This manual cannot and does not prohibit every possible bug or
>   undesirable behaviour.  The fact that something is not forbidden by
>   Debian policy does not mean that it is not a bug, let alone that it
>   is desirable.  Questions not covered by policy should be evaluated
>   on their merits.

looks good to me, seconded, thanks.


-- 
cheers,
Holger

---
   holger@(debian|reproducible-builds|layer-acht).org
   PGP fingerprint: B8BF 5413 7B09 D35C F026 FE9D 091A B856 069A AA1C


signature.asc
Description: PGP signature

severity of "fails to purge" issues

[Holger Levsen]

Hi,

in 
https://github.com/anbe42/piuparts/commit/283dac3ae7e31fee51efb836468cd8ca5b61584f
(not yet merged into the main piuparts repo) Andreas proposes to file bugs
regarding failing to purge with severity 'serious" because "old bugs are
filed/fixed and any failure due to a regression in sid will block migration
anyway", while we used to treat 'failing to purge' bugs as severity
'important' as in practice those bugs are merely annoying (while being a
clear policy violation).

There's also at least #918312 filed by Adrian Bunk.

The reasoning that these bugs will block migrations anyway sounds sound
- except for new packages though!

So I would like to have the opinion of the release team if you also
think that those bugs should be filed with severity 'serious' nowadays.
(As it was their opinion that this shouldn't be done previously.)

What do you think?


-- 
cheers,
Holger

---
   holger@(debian|reproducible-builds|layer-acht).org
   PGP fingerprint: B8BF 5413 7B09 D35C F026 FE9D 091A B856 069A AA1C


signature.asc
Description: PGP signature

Bug#918379: please decide: severity of "fails to purge" issues

[Holger Levsen]

package: release.debian.org
x-debbugs-cc: debian-policy@lists.debian.org, 
piuparts-de...@lists.alioth.debian.org, Adrian Bunk 

Hi,

filing this as a bug now. Please reassign to src:piuparts once you have
decided...

On Sat, Jan 05, 2019 at 03:34:23PM +, Holger Levsen wrote:
> in 
> https://github.com/anbe42/piuparts/commit/283dac3ae7e31fee51efb836468cd8ca5b61584f
> (not yet merged into the main piuparts repo) Andreas proposes to file bugs
> regarding failing to purge with severity 'serious" because "old bugs are
> filed/fixed and any failure due to a regression in sid will block migration
> anyway", while we used to treat 'failing to purge' bugs as severity
> 'important' as in practice those bugs are merely annoying (while being a
> clear policy violation).
> 
> There's also at least #918312 filed by Adrian Bunk.
> 
> The reasoning that these bugs will block migrations anyway sounds sound
> - except for new packages though!
> 
> So I would like to have the opinion of the release team if you also
> think that those bugs should be filed with severity 'serious' nowadays.
> (As it was their opinion that this shouldn't be done previously.)
> 
> What do you think?

this led to this discussion on #-release:

  h01ger: what does 'fails to purge' mean? the purge fails (gives
 errors) or the purge 'succeeds', but files are left?
 both
  and with 'both' you mean: 'either of these will produce that error'?
 yes. https://piuparts.debian.org/templates/mail/ lists 5 cases with 
purge failures
  personally, if the purge command fails, I wouldn't even hesitate to\
 call the serious (I'm surprised it wasn't filed as serious before)
  if the command succeeds and files are left over, I might hesitate a
 bit, but on the other hand, if you can't remove all the files, you
 have no right to call that a 'successful' purge
  so I wouldn't mind if that was filed as serious as well
 usually purges are done manually so failing to purge with exit 1 doesnt
 really have an effect. thats why it was important only
  well, it means something is wrong, and the user gets to clean it up 
manually
  but I don't think we disagree here :)
 :)
  I don't really like adding new cases for RC bugs just before the 
freeze,
 but if this type of error has been tested for quite some time, then it
 isn't really a 'new' case
 ivodd: i think i will reply to the bug via submit@bugs.d.o (assigned 
to release.d.o) and include our replies there
 yeah
  ok
 it has been tested since lenny :)
  piuparts++
 :) thanks!


-- 
cheers,
Holger

---
   holger@(debian|reproducible-builds|layer-acht).org
   PGP fingerprint: B8BF 5413 7B09 D35C F026 FE9D 091A B856 069A AA1C


signature.asc
Description: PGP signature

piuparts regressions for new packages? (Re: severity of "fails to purge" issues)

[Holger Levsen]

On Sat, Jan 05, 2019 at 05:52:17PM +0200, Adrian Bunk wrote:
> On Sat, Jan 05, 2019 at 03:34:23PM +0000, Holger Levsen wrote:
> >...
> > There's also at least #918312 filed by Adrian Bunk.
> > 
> > The reasoning that these bugs will block migrations anyway sounds sound
> > - except for new packages though!
> >...
> 
> Are you sure about the latter?
> 
> For testing migration purposes salt (#918312) is new since it
> was removed from testing in May.

right, thanks for pointing this out.

I think this is a bug in britney... should I file it? :)


-- 
cheers,
Holger

---
   holger@(debian|reproducible-builds|layer-acht).org
   PGP fingerprint: B8BF 5413 7B09 D35C F026 FE9D 091A B856 069A AA1C


signature.asc
Description: PGP signature

Re: Bug#918379 closed by Emilio Pozuelo Monfort (Re: Bug#918379: please decide: severity of "fails to purge" issues)

[Holger Levsen]

control: reopen -1
control: retitle -1 drop sid-strict?

On Mon, Jan 07, 2019 at 09:18:06AM +, Debian Bug Tracking System wrote:
> > Leaving files around after purge is a separate that will continue to be
> > filed as important.
> Agreed with Ivo. Serious for the cases you mention sound reasonable. Please
> continue doing that.

ok, thank you!

> > in 
> > https://github.com/anbe42/piuparts/commit/283dac3ae7e31fee51efb836468cd8ca5b61584f

merged and deployed to piuparts.d.o now.

Also this popped up:

 h01ger, bunk: Re #856324, does that (still) make sense? Where would I 
get the sid-strict data?
-zwiebelbot- | (#debian-qa) Debian#856324: DDPO should display sid-strict 
piuparts results - https://bugs.debian.org/856324
 atm we are using https://piuparts.debian.org/summary.json
 what is sid-strict?
 https://piuparts.debian.org/sid-strict/
 " Fails if there are leftover files after purge. "
 now that #918379 has been decided, i guess we can drop sid-strict
-zwiebelbot- | (#debian-qa) Debian#918379: please decide: severity of "fails to 
purge" issues - https://bugs.debian.org/918379
 so we can also close #856324
 ok so I don't need to do anything, except for closing that bug?
* h01ger nods

So I guess I will drop sid-strict now as well...


-- 
cheers,
Holger

---
   holger@(debian|reproducible-builds|layer-acht).org
   PGP fingerprint: B8BF 5413 7B09 D35C F026 FE9D 091A B856 069A AA1C


signature.asc
Description: PGP signature

Bug#920366: developers-reference: ftbfs in sid, builds fine in stable

[Holger Levsen]

Package: developers-reference
Version: 3.4.21
Severity: serious

Hi,

so I was going to do a developers-reference upload today, thinking it's
good to update it 'long' before the freeze...

so I did some polishing and tried to build it, and failed, fixed some
broken tags (see git) and noticed it still fails to build in sid, but
builds fine in stable.

So I triggered a build of 3.4.21 on tests.reproducible-builds.org and
voila, it fails exactly as the git master branch for 3.4.22:

from 
https://tests.reproducible-builds.org/debian/rbuild/unstable/amd64/developers-reference_3.4.21.rbuild.log.gz
(also attached)

xsltproc --nonet --novalid --xinclude 
/build/1st/developers-reference-3.4.21/xslt/txt.xsl 
/build/1st/developers-reference-3.4.21/index.dbk \
| LC_ALL=C.UTF-8 w3m -o display_charset=UTF-8 -cols 70 -dump -no-graph -T 
text/html > /build/1st/developers-reference-3.4.21/developers-reference.txt
dblatex --style=db2latex /build/1st/developers-reference-3.4.21/index.dbk \
--backend=xetex \
--xsl-user=xslt/user_param.xsl \
--xsl-user=xslt/xetex_param.xsl \
--param=lingua=/build/1st/developers-reference-3.4.21 \
&& mv /build/1st/developers-reference-3.4.21/index.dbk.pdf 
/build/1st/developers-reference-3.4.21/developers-reference.pdf
Build the book set list...
Build the listings...
XSLT stylesheets DocBook - LaTeX 2e (0.3.10)
===
Build index.dbk.pdf
xelatex failed
index.dbk.tex:279: Argument of \__fontspec_strip_leading_sign:Nw has an extra }.
index.dbk.tex:279: leading text: would be much less secure.\footnote{
index.dbk.tex:279: Paragraph ended before \__fontspec_strip_leading_sign:Nw was 
complete.
index.dbk.tex:279: leading text: would be much less secure.\footnote{
index.dbk.tex:308: Argument of \__fontspec_strip_leading_sign:Nw has an extra }.
index.dbk.tex:308: leading text: }
index.dbk.tex:308: Paragraph ended before \__fontspec_strip_leading_sign:Nw was 
complete.
index.dbk.tex:308: leading text: }
index.dbk.tex:558: Argument of \__fontspec_strip_leading_sign:Nw has an extra }.
index.dbk.tex:558: leading text: ... to the subject of your message\footnote{
index.dbk.tex:558: Paragraph ended before \__fontspec_strip_leading_sign:Nw was 
complete.
index.dbk.tex:558: leading text: ... to the subject of your message\footnote{
index.dbk.tex:562: Argument of \__fontspec_strip_leading_sign:Nw has an extra }.
index.dbk.tex:562: leading text: }
index.dbk.tex:562: Paragraph ended before \__fontspec_strip_leading_sign:Nw was 
complete.
index.dbk.tex:562: leading text: }
index.dbk.tex:2815: Argument of \__fontspec_strip_leading_sign:Nw has an extra 
}.
index.dbk.tex:2815: leading text: ... to \`{}main' or \`{}contrib'.\footnote{
index.dbk.tex:2815: Paragraph ended before \__fontspec_strip_leading_sign:Nw 
was complete.
index.dbk.tex:2815: leading text: ... to \`{}main' or \`{}contrib'.\footnote{
index.dbk.tex:2818: Argument of \__fontspec_strip_leading_sign:Nw has an extra 
}.
index.dbk.tex:2818: leading text: }
index.dbk.tex:2818: Paragraph ended before \__fontspec_strip_leading_sign:Nw 
was complete.
index.dbk.tex:2818: leading text: }
index.dbk.tex:3263: Argument of \__fontspec_strip_leading_sign:Nw has an extra 
}.
index.dbk.tex:3263: leading text: ...ion number of \texttt{3.4+b2}.\footnote{
index.dbk.tex:3263: Paragraph ended before \__fontspec_strip_leading_sign:Nw 
was complete.
index.dbk.tex:3263: leading text: ...ion number of \texttt{3.4+b2}.\footnote{
index.dbk.tex:3270: Argument of \__fontspec_strip_leading_sign:Nw has an extra 
}.
index.dbk.tex:3270: leading text: }
index.dbk.tex:3270: Paragraph ended before \__fontspec_strip_leading_sign:Nw 
was complete.
index.dbk.tex:3270: leading text: }
index.dbk.tex:3857: Argument of \__fontspec_strip_leading_sign:Nw has an extra 
}.
index.dbk.tex:3857: leading text:   package-{}name}\footnote{
index.dbk.tex:3857: Paragraph ended before \__fontspec_strip_leading_sign:Nw 
was complete.
index.dbk.tex:3857: leading text:   package-{}name}\footnote{
index.dbk.tex:3860: Argument of \__fontspec_strip_leading_sign:Nw has an extra 
}.
index.dbk.tex:3860: leading text: }
index.dbk.tex:3860: Paragraph ended before \__fontspec_strip_leading_sign:Nw 
was complete.
index.dbk.tex:3860: leading text: }
index.dbk.tex:5932: Argument of \__fontspec_strip_leading_sign:Nw has an extra 
}.
index.dbk.tex:5932: leading text: ...ibuted by the upstream author.\footnote{
index.dbk.tex:5932: Paragraph ended before \__fontspec_strip_leading_sign:Nw 
was complete.
index.dbk.tex:5932: leading text: ...ibuted by the upstream author.\footnote{
index.dbk.tex:5943: Argument of \__fontspec_strip_leading_sign:Nw has an extra 
}.
index.dbk.tex:5943: leading text: }
index.dbk.tex:5943: Paragraph ended before \__fontspec_strip_leading_sign:Nw 
was complete.
index.dbk.tex:5943: leading text: }
index.dbk.tex:6025: Argument of \__fontspec_strip_leading_sign:Nw has an extra 
}.
index.dbk.tex:6025: leading text: you.\footnote{
index.

Bug#920366: developers-reference: ftbfs in sid, builds fine in stable

[Holger Levsen]

control: reassign -1 texlive-latex-recommended
control: retitle -1 ftbfs causing regression in texlive-latex-recommended
control: affects -1 developers-reference
control: affects -1 logidee-tools
control: found -1 2018.20190122-1
thanks

On Fri, Jan 25, 2019 at 10:54:45AM +0100, Wolfgang Schweer wrote:
> On Thu, Jan 24, 2019 at 08:09:39PM +0100, Holger Levsen wrote:
> > Interestingly 3.4.21 build fine in unstable on arm64 only two days ago (see
> > https://tests.reproducible-builds.org/debian/history/developers-reference.html
> > )
> > 
> > Matching this, builds of 3.4.21 still build fine today. (also see that
> > last URL.)
> The failure is most probably due to src:texlive-base.
> texlive-base/2018.20190122-1 entered unstable a few days ago, replacing
> 2018.20181214-1 

thanks, that brought me on the right track:

- I booted a buster VM, installed all of developers-reference
  build-depends from buster
- then I successfully build developers-reference 3.4.21
- then I upgraded only texlive-base to the version from sid (2018.20190122-1)
  and dev-ref still build fine...
- same with texlive...
- same with texlive-latex-base
- same with texlive-xetex
- same with texlive-latex-extra
- same with texlive-extra-utils
- finally, after installing texlive-latex-recommended (2018.20190122-1)
  the build failed.
- then I booted another fresh buster VM, installed all of
  developers-reference build-depends from buster again and upgraded only
  texlive-latex-recommended to the sid version, and voila, *boom*,
  developers-reference FTBFS. (with the very same output as submitted to
  this bug report.)

Then I went to tracker.debian.org, saw two debci regressions and indeed
https://ci.debian.net/data/autopkgtest/testing/amd64/l/logidee-tools/1779974/log.gz
(attached) shows the very same symptoms as we are seeing with def-ref:

 Paragraph ended before \ProvidesPackageRCS@i was complete.

Thus, reassigning etc accordingly.


-- 
tschüß,
Holger

---
   holger@(debian|reproducible-builds|layer-acht).org
   PGP fingerprint: B8BF 5413 7B09 D35C F026 FE9D 091A B856 069A AA1C


autopkgtest_testing_amd64_logidee-tools_1779974_log.g
Description: Binary data


signature.asc
Description: PGP signature

Bug#817914: developers-reference: globally change "new maintainer" into "new member"

[Holger Levsen]

Hi Holger,

yes, a patch to fix this would be awesome! Many thanks in advance! :)


-- 
tschüß,
Holger

---
   holger@(debian|reproducible-builds|layer-acht).org
   PGP fingerprint: B8BF 5413 7B09 D35C F026 FE9D 091A B856 069A AA1C


signature.asc
Description: PGP signature

Bug#817914: developers-reference: globally change "new maintainer" into "new member"

[Holger Levsen]

Moin Holger :)

On Fri, Jan 25, 2019 at 11:59:53PM +0100, Holger Wansing wrote:
> > yes, a patch to fix this would be awesome! Many thanks in advance! :)
> Patch is attached!

wow, that was quick! Many thanks for that!

> In fact, this member/maintainer/developer naming thing is somewhat tricky,

indeed.

> and sometimes it's also irritating IMO (at least for people being new to 
> Debian).

for everyone, I guess, to varying degrees...

> However, this is because the documents have developed over time, so the
> document has probably been written in times where only the developer role
> was existing, and later the maintainer role and then the member role has
> been introduced.

yup

> Therefore, it's of course not possible and also not useful, to substitute
> all "maintainer" into "member" and the like (think about phrases like
> "maintainer script" and "maintainer field in control" and ...), which are
> still correct and will not be renamed into "member script" or "member field".
> 
> This only as a explanation, why not all occurrences of "maintainer" have
> been switched to "member".

I totally agree and I also think you've done a few substituion too many,
see below...

> (Yes, this relativizes the bug title a bit :-) )
> I hope I got it mostly right.

in any case: many thanks for your quick response! let's get this settled
now!

some (quick) comments, stuff I havent commented is fine IMO.

> -Given how easy it is to become a Debian Maintainer, you might want
> +Given how easy it is to become a Debian Member, you might want
>  to only sponsor people who plan to join. 

to become a Maintainer?

> -The process of registering as a developer is a process of verifying your
> +The process of registering as a member is a process of verifying your

... a maintainer?

(maybe then we also need one paragraph explaining that developers are
maintainers too? and developers are members, but members not necessarily
developers nor maintainers? ;)

> -Therefore, we need to verify new maintainers before we can give them accounts
> +Therefore, we need to verify new members before we can give them accounts
>  on our servers and let them upload packages.

not sure if members can get server access. maintainers surely can. maybe
"new developers/maintainers"? (also to answer my own question in the
previous paragraph, maybe be explicit and say
'member/developer/maintainer' if we mean that?

> -Resources for Debian Developers and Debian Maintainers
> +Resources for Debian Members\

see above :)

Even if this seems a bit confusing now I'd hope it was that bad. Have
you seen anything where you would like to rework your patch or do you
think it should rather go in as such?

(once it goes in it will trigger translation updates so we better are
careful...)



-- 
tschüß,
Holger

---
   holger@(debian|reproducible-builds|layer-acht).org
   PGP fingerprint: B8BF 5413 7B09 D35C F026 FE9D 091A B856 069A AA1C


signature.asc
Description: PGP signature

Bug#484805: marked as done (developers-reference: please make clone to tech-ctte the default)

[Holger Levsen]

On Fri, Jan 25, 2019 at 04:56:09PM -0700, Sean Whitton wrote:
> > which IMO is as good as it is. It also explicitly points to
> > http://www.debian.org/devel/tech-ctte for detailed information.
> At least for Policy bugs referred to the TC, they prefer a fresh bug
> where the first message is a summary of the situation, rather than a clone.

so you suggest a reopening of this bug?

(yes or no as an answer would be great, even greater in the case of
'yes' would obviously be a patch, but many thanks already for this
feedback, we can write the patch later, if needed?!)


-- 
tschüß,
Holger

---
   holger@(debian|reproducible-builds|layer-acht).org
   PGP fingerprint: B8BF 5413 7B09 D35C F026 FE9D 091A B856 069A AA1C


signature.asc
Description: PGP signature

Bug#484805: marked as done (developers-reference: please make clone to tech-ctte the default)

[Holger Levsen]

control: reopen -1
control: retitle -1 dev-ref: tech-ctte prefers fresh bug reports with a summary
thanks

On Sat, Jan 26, 2019 at 12:34:46PM -0700, Sean Whitton wrote:
> ISTM that it would be useful to have this in dev-ref, yes.  I'm not sure
> whether it should be a reopening or a new bug though :) I will leave
> this in the package maintainer's hands ;)

heh, thanks!


-- 
tschüß,
Holger

---
   holger@(debian|reproducible-builds|layer-acht).org
   PGP fingerprint: B8BF 5413 7B09 D35C F026 FE9D 091A B856 069A AA1C


signature.asc
Description: PGP signature

Bug#897217: Bug#920355: debian-policy: Permit branch specifications ("-b") in Mercurial Vcs-Hg headers

[Holger Levsen]

On Thu, Jan 24, 2019 at 05:05:07PM +0100, Chris Lamb wrote:
> Policy §5.6.26 permits "-b" only in the case of Vcs-Git:
[...] 
> However, Mercurial (ie. "Vcs-Hg") supports this too in its
> equivalent "hg clone" command. This change was triggered via
> #920314 in Lintian.
> 
> A simple patch (also attached) might be:
> 
> commit 3e66c9e470053fcc77169efa82833252971d211c
> Author: Chris Lamb 
> Date:   Thu Jan 24 16:55:21 2019 +0100
> 
>   Permit branch specifications ("-b") in Mercurial Vcs-Hg headers too, 
> not just Vcs-Git. (Closes: #-1)
> 
> diff --git a/policy/ch-controlfields.rst b/policy/ch-controlfields.rst
> index 44080c9..013aae4 100644
> --- a/policy/ch-controlfields.rst
> +++ b/policy/ch-controlfields.rst
> @@ -973,10 +973,11 @@ repository where the Debian source package is 
> developed.
>- Mtn (Monotone)
>- Svn (Subversion)
>  
> -In the case of Git, the value consists of a URL, optionally followed
> -by the word ``-b`` and the name of a branch in the indicated
> -repository, following the syntax of the ``git clone`` command. If no
> -branch is specified, the packaging should be on the default branch.
> +In the case of Git and Mercurial, the value consists of a URL,
> +optionally followed by the word ``-b`` and the name of a branch in
> +the indicated repository, following the syntax of the ``git clone``
> +or ``hg clone`` command. If no branch is specified, the packaging
> +should be on the default branch.

seconded.

> Thank you for maintaining Policy.

seconded too! :)


-- 
tschüß,
Holger

---
   holger@(debian|reproducible-builds|layer-acht).org
   PGP fingerprint: B8BF 5413 7B09 D35C F026 FE9D 091A B856 069A AA1C


signature.asc
Description: PGP signature

Bug#917431: debian-policy: virtual packages: logind, default-logind

[Holger Levsen]

On Fri, Dec 28, 2018 at 12:36:31PM +0100, Adam Borowski wrote:
> On Thu, Dec 27, 2018 at 06:28:04PM +, Sean Whitton wrote:
> > Could you provide an actual diff to be applied to policy.git, please?
> 
> Sure, what about:?
> 
> diff --git a/policy/upgrading-checklist.rst b/policy/upgrading-checklist.rst
> index 679a187..633c14e 100644
> --- a/policy/upgrading-checklist.rst
> +++ b/policy/upgrading-checklist.rst
> @@ -39,6 +39,14 @@ The sections in this checklist match the values for the
>  except in the two anomalous historical cases where normative
>  requirements were changed in a minor patch release.
>  
> +Unreleased
> +--
> +
> +virtual
> +New ``logind`` and ``default-logind`` virtual packages for a package
> +providing logind API (over D-Bus and /run/), and for Debian's preferred
> +implementation, respectively.
> +
>  Version 4.3.0
>  -
>  
> diff --git a/virtual-package-names-list.yaml b/virtual-package-names-list.yaml
> index afb76a3..de54e32 100644
> --- a/virtual-package-names-list.yaml
> +++ b/virtual-package-names-list.yaml
> @@ -110,6 +110,10 @@ virtualPackages:
> description: provides the D-Bus well-known session bus for most or all 
> user login sessions
>   - name: default-dbus-session-bus
> description: Debian's preferred implementation of dbus-session-bus, 
> possibly architecture-specific
> + - name: logind
> +   description: an org.freedesktop.login1 D-Bus API implementation 
> (versioned)
> + - name: default-logind
> +   description: Debian's preferred implementation of logind, possibly 
> architecture-specific (versioned)

seconded, thanks.


-- 
tschüß,
Holger

---
   holger@(debian|reproducible-builds|layer-acht).org
   PGP fingerprint: B8BF 5413 7B09 D35C F026 FE9D 091A B856 069A AA1C


signature.asc
Description: PGP signature

Bug#817914: developers-reference: globally change "new maintainer" into "new member"

[Holger Levsen]

Hi Holger,

On Sat, Jan 26, 2019 at 01:49:09AM +0100, Holger Wansing wrote:
> > > -Given how easy it is to become a Debian Maintainer, you might want
> > > +Given how easy it is to become a Debian Member, you might want
> > >  to only sponsor people who plan to join. 
> > to become a Maintainer?
> 
> Maybe ...
> But as a first step, it would be enough to only be a member.

it's much easier to become a Debian Maintainer, than a Debian Member. 

> For team maintained packages you can also do package work | package uploading
> work as a member (at least these are my experiences; see below).

you can do that work as 'nobody' too ;)

> > > -The process of registering as a developer is a process of verifying your
> > > +The process of registering as a member is a process of verifying your
> > ... a maintainer?
> Here we refer to the NM process itself, which is officially named "New Member
> process" these days.
> So I think "member" is fine here.

ok

> > (maybe then we also need one paragraph explaining that developers are
> > maintainers too? and developers are members, but members not necessarily
> > developers nor maintainers? ;)
> Yes, but question is, if we want to make it that complicated :-)

well, Debian *is* complex.

> Remember it should be understandable for new people ...

sure, but making it sound simpler / less complex than it is in reality
might also be a diservice for new people...

> > > -Therefore, we need to verify new maintainers before we can give them 
> > > accounts
> > > +Therefore, we need to verify new members before we can give them accounts
> > >  on our servers and let them upload packages.
> > 
> > not sure if members can get server access. maintainers surely can. maybe
> > "new developers/maintainers"? (also to answer my own question in the
> > previous paragraph, maybe be explicit and say
> > 'member/developer/maintainer' if we mean that?
> 
> Members have chance to get permission to access dillon :-)))
> At least in my case.

maintainers too.

> I am not a developer, and I am not mentioned as a maintainer in some packages'
> control file, so I assume I am a member? ;-))

you are a 'Debian Developer, non-uploading' :)

which in other words means you're a Debian (project) Member.

> And I got upload permissions for d-i packages, and I got access to dillon.
> As it seems the rules are always somewhat flexible ...

they are. Your upload permissions are probably technically done by also
making you a Debian Maintainer...

> > > -Resources for Debian Developers and Debian Maintainers
> > > +Resources for Debian Members\
> > see above :)
> I assume that all developers and maintainers are also members (in german we
> say "kleinster gemeinsamer Nenner").
 
No, Debian Maintainers are not Debian project members. Project members
can vote. Debian Maintainers cannot vote. You can vote.

> As written above: maybe we should not make this more complicated as needed
> and use 'member' as a cover term?

we definitly shouldnt add more meanings to words already loaded with too
many meanings :/

> > Even if this seems a bit confusing now I'd hope it was that bad. Have
> > you seen anything where you would like to rework your patch or do you
> > think it should rather go in as such?
> > 
> > (once it goes in it will trigger translation updates so we better are
> > careful...)
> 
> This is why I first thought "Huh it's maybe to late for this change now?", 
> since translators maybe have only little chance to catch up...

I've released dev-ref 3.4.22 yesterday so we can merge this now and then
translators have still time to catch up.

> But to not postpone this too much I prepared a patch anyway.

yup

> As a summary:
> I see no strict need to do reworking on my patch IMHO.
> (You can always find corner cases, where the terms are debatable, because
> of historical growth of the document and the rules in Debian, as already
> said. But I think it should fit this way.)

I think I'll merge your patch later (today?) and then go through it
again and reword areas where I think it needs reworking. It's definitly
a good base for future work!


-- 
tschüß,
Holger

---
   holger@(debian|reproducible-builds|layer-acht).org
   PGP fingerprint: B8BF 5413 7B09 D35C F026 FE9D 091A B856 069A AA1C


signature.asc
Description: PGP signature

Bug#920692: Packages must not install files or directories into /var/cache

[Holger Levsen]

On Wed, Jan 30, 2019 at 02:09:19AM +0100, Josh Triplett wrote:
> It's worth documenting things that some packages have gotten wrong
> when the reason why they're wrong isn't obvious and isn't currently
> documented anywhere.

this in mind...

On Mon, Jan 28, 2019 at 12:06:31PM +0100, Josh Triplett wrote:
> From 463182f3a365fff6610d4e94eca4860fe51994f6 Mon Sep 17 00:00:00 2001
> From: Josh Triplett 
> Date: Mon, 28 Jan 2019 11:39:10 +0100
> Subject: [PATCH] Packages must not install files or directories into
>  /var/cache
> 
> ---
>  policy/ch-files.rst | 9 +
>  1 file changed, 9 insertions(+)
> 
> diff --git a/policy/ch-files.rst b/policy/ch-files.rst
> index 48410be..1cdcb18 100644
> --- a/policy/ch-files.rst
> +++ b/policy/ch-files.rst
> @@ -722,6 +722,15 @@ The name of the files and directories installed by 
> binary packages
>  outside the system PATH must be encoded in UTF-8 and should be
>  restricted to ASCII when it is possible to do so.
>  
> +.. _s-cache:
> +
> +Cache
> +-
> +
> +Packages must not install files or directories into ``/var/cache``. The
> +system administrator may delete any or all files from this directory at
> +any time, or may choose to put it on an ephemeral filesystem.
> +
>  .. [#]
> If you are using GCC, ``-fPIC`` produces code with relocatable
> position independent code, which is required for most architectures
> -- 
> 2.20.1

seconded.


-- 
tschüß,
Holger

---
   holger@(debian|reproducible-builds|layer-acht).org
   PGP fingerprint: B8BF 5413 7B09 D35C F026 FE9D 091A B856 069A AA1C


signature.asc
Description: PGP signature

Bug#830562: developers-reference: Document expectations & best practices for including AppArmor policy in packages

[Holger Levsen]

Hi intri,

a patch for this for developers reference would be very welcome indeed.


-- 
tschüß,
Holger

---
   holger@(debian|reproducible-builds|layer-acht).org
   PGP fingerprint: B8BF 5413 7B09 D35C F026 FE9D 091A B856 069A AA1C


signature.asc
Description: PGP signature

Bug#921963: debian-policy: add link to https://jenkins.debian.net/userContent/debian-policy in README.md

[Holger Levsen]

Package: debian-policy
Version: 4.3.0.2
Severity: wishlist

Dear Maintainer,

attached is a patch to add this to README.md:

 Continuous integration

On each push to the master branch, a jenkins job is triggered which builds
src:debian-policy's binary packages and installs them to
https://jenkins.debian.net/userContent/debian-policy/

Thanks for maintaining debian-policy!


-- 
tschau,
Holger

---
   holger@(debian|reproducible-builds|layer-acht).org
   PGP fingerprint: B8BF 5413 7B09 D35C F026 FE9D 091A B856 069A AA1C
From 69421aaa3286682fe75bcfea5f7a5388ff058899 Mon Sep 17 00:00:00 2001
From: Holger Levsen 
Date: Sun, 10 Feb 2019 18:10:59 +0100
Subject: [PATCH] add a parapraph linking to
 https://jenkins.debian.net/userContent/debian-policy/

Signed-off-by: Holger Levsen 
---
 README.md | 6 ++
 1 file changed, 6 insertions(+)

diff --git a/README.md b/README.md
index 3ee1407..792cc01 100644
--- a/README.md
+++ b/README.md
@@ -253,6 +253,12 @@ The Git repository used for Debian Policy has the following branches:
 + rra:: old history of Russ's arch repository, now frozen
 + srivasta:: old history of Manoj's arch repository
 
+ Continuous integration
+
+On each push to the master branch, a jenkins job is triggered which builds
+src:debian-policy's binary packages and installs them to
+https://jenkins.debian.net/userContent/debian-policy/
+
 ### Managing a bug
 
 Some tips for managing bugs:
-- 
2.11.0



signature.asc
Description: PGP signature

Bug#919507: Reboot required patch for Debian policy

[Holger Levsen]

On Sun, Jan 20, 2019 at 05:09:39PM -0600, Karl O. Pinc wrote:
> diff --git a/policy/ch-opersys.rst b/policy/ch-opersys.rst
> index 59c92ec..8276bfe 100644
> --- a/policy/ch-opersys.rst
> +++ b/policy/ch-opersys.rst
> @@ -1040,3 +1040,33 @@ Debian, so this section has been removed.
> activate the trigger. In that case, it can be done by calling
> ``dpkg-trigger --no-await /usr/lib/mime/packages`` from the
> maintainer script after creating, modifying, or removing the file.
> +
> +.. index::
> +   pair: signaling; reboot
> +
> +.. _s-signalingreboot
> +
> +Signaling that a reboot is required
> +---
> +
> +.. index::
> +   single: reboot-required
> +   single: reboot-required.pkgs
> +
> +Programs can signal that a reboot is required by ``touch``\ing
> +``/run/reboot-required``.  It is conventional to add the name of the
> +package(s) requiring the reboot to
> +``/run/reboot-required.pkgs``. Programs should not add a package name
> +to ``/run/reboot-required.pkgs`` if it is already present there.
> +
> +.. index:
> +   single: postinst
> +
> +The ``/run/reboot-required`` mechanism is used when a reboot is
> +needed to fully apply the changes introduced by package
> +installation or upgrade.  Typically it is the ``postinst``
> +maintainer script that touches ``/run/reboot-required``, at the end
> +of a successful configuration of the package.
> +
> +There are no guarantees provided by the ``/var/reboot-required``
> +convention as to when or whether the requested reboot will occur.

seconded, thanks.


-- 
tschau,
Holger

---
   holger@(debian|reproducible-builds|layer-acht).org
   PGP fingerprint: B8BF 5413 7B09 D35C F026 FE9D 091A B856 069A AA1C


signature.asc
Description: PGP signature

Re: Converting dev-ref to use rST

[Holger Levsen]

Hi Sean,

On Mon, Apr 08, 2019 at 02:45:29PM -0700, Sean Whitton wrote:
> I am considering to working to convert dev-ref to rST+Sphinx this
> summer. 

awesome!

> - who else is interested in working on this;

/me

> - whether there is some reason that this should not be worked on at
>   the present time, and whether any of the dev-ref uploaders object to
>   the prospect of my unilaterally committing and uploading this
>   change.
 
please go ahead & now or any time. (I don't consider the Buster release
relevant here at all.)


-- 
tschau,
Holger

---
   holger@(debian|reproducible-builds|layer-acht).org
   PGP fingerprint: B8BF 5413 7B09 D35C F026 FE9D 091A B856 069A AA1C


signature.asc
Description: PGP signature

Re: Heads-up: new lintian error: no-human-maintainers

[Holger Levsen]

Hi,

I've added debian-policy@l.d.o to recipients as I believe this either
warrants an exception for debian installer packages or maybe this should
be redfined for all.

On Sat, Apr 20, 2019 at 11:02:49PM +0200, Cyril Brulebois wrote:
> With the removal of Christian Perrier from Uploaders in almost all d-i
> packages, some of them now have an empty Uploaders field. With the
> debian-boot@ list being in the Maintainer field, that can trigger this
> lintian error on the source package:
> 
> E: tzsetup source: no-human-maintainers
> 
> My personal policy regarding this (carried over from my X.Org days) is
> to ignore it entirely; I see no gain in having specific people being
> listed in Uploaders. Feel free to do the same when you're about to
> upload a package with pending l10n changes, or with various bug fixes
> that were awaiting an upload in git…

I've not really made up my mind of what I think about the general case,
I do think there are some merrits knowing/documenting human maintainers.

I also do think that this doesnt make that much sense for d-i packages.

(And I also think that policy should be changed (and not merely ignored) 
if we find that we disagree with whats written in it.)

Shall I file a bug against debian-policy?


-- 
tschau,
Holger

---
   holger@(debian|reproducible-builds|layer-acht).org
   PGP fingerprint: B8BF 5413 7B09 D35C F026 FE9D 091A B856 069A AA1C


signature.asc
Description: PGP signature

Re: Heads-up: new lintian error: no-human-maintainers

[Holger Levsen]

On Fri, Apr 26, 2019 at 01:50:24AM +0200, Cyril Brulebois wrote:
> I don't really see what's so specific about d-i here.

I agree, this is not about d-i.


-- 
tschau,
Holger

---
   holger@(debian|reproducible-builds|layer-acht).org
   PGP fingerprint: B8BF 5413 7B09 D35C F026 FE9D 091A B856 069A AA1C


signature.asc
Description: PGP signature

Bug#910783: Remove doc-base recommendation

[Holger Levsen]

On Wed, May 15, 2019 at 09:07:53AM +0200, Ansgar Burchardt wrote:
> > We need a cross-distro cross-desktop standard for an index of
> > docs before we can move on from doc-base like we did with menu.
> I don't think so: we can just remove doc-base without providing a
> replacement at the same time too.
> 
> Personally I don't know anyone using doc-base (probably most don't even
> know it exists).  If doc-base has indeed no users (or very few users),
> it just creates work for maintainers for no real benefit.
> 
> As [1] says, doc-base had 20+ years to get adopted.  I think it is fair
> to say that it failed to do so.
 
fully agreed. (and as said previously in this bug, I still have no idea
how to make use of doc-base...)


-- 
tschau,
Holger

---
   holger@(debian|reproducible-builds|layer-acht).org
   PGP fingerprint: B8BF 5413 7B09 D35C F026 FE9D 091A B856 069A AA1C


signature.asc
Description: PGP signature

Re: Converting dev-ref to use rST

[Holger Levsen]

On Tue, Jun 11, 2019 at 10:15:56AM -0700, Sean Whitton wrote:
> I don't know of any automated solution.  We might just have to keep the
> old source and continue building translations from that until each
> language is manually converted?  :\

once we have a script which does the conversion, cant we use po4a to
generate a $language version as docbook, then run the converting script
on it and then recreate the po file from the new format?


-- 
tschau,
Holger

---
   holger@(debian|reproducible-builds|layer-acht).org
   PGP fingerprint: B8BF 5413 7B09 D35C F026 FE9D 091A B856 069A AA1C


signature.asc
Description: PGP signature

Bug#930553: version-nexttesting should be "11" (not "10")

[Holger Levsen]

On Sat, Jun 15, 2019 at 09:04:24PM +0900, Osamu Aoki wrote:
> While doing sphinx conversion, I realized that it may be better to
> update as follows:

Thanks for the bug report, fixed in git.

Now I wonder, dies it make sense to do an upload now, for buster, and
then another upload with these numbers changed, for bullseye, once
buster is out:

>  
>  
>  
>  
 
?

-- 
tschau,
Holger

---
   holger@(debian|reproducible-builds|layer-acht).org
   PGP fingerprint: B8BF 5413 7B09 D35C F026 FE9D 091A B856 069A AA1C


signature.asc
Description: PGP signature

Bug#930565: dev-ref: should use distro-info instead of hardcoding version numbers

[Holger Levsen]

package: developers-reference
severity: wishlist
x-debbugs-cc: Osamu Aoki , 930...@bugs.debian.org

On Sat, Jun 15, 2019 at 03:53:07PM +, Holger Levsen wrote:
> Now I wonder, dies it make sense to do an upload now, for buster, and
> then another upload with these numbers changed, for bullseye, once
> buster is out:
> 
> >  
> >  
> >  
> >  

actually, I just realized that these numbers should be incremented
*now*, for an upload aimed at bullseye.

and then for bullseye we should use distro-info(-data). (wondering how
to do this sensibly at run time and not at build time...)


-- 
tschau,
Holger

---
   holger@(debian|reproducible-builds|layer-acht).org
   PGP fingerprint: B8BF 5413 7B09 D35C F026 FE9D 091A B856 069A AA1C


signature.asc
Description: PGP signature

Re: Converting dev-ref to use rST

[Holger Levsen]

On Sun, Jun 16, 2019 at 02:04:30AM +0900, Osamu Aoki wrote:
> My work to convert PO is done.
[...]
> What do you think?

coolio, nice work, though I wont have time to look at this until
DebConf19, me thinks. Still very yay & thank you very much!

(obviously I'd also welcome other people looking at this now.)


-- 
cheers,
Holger

---
   holger@(debian|reproducible-builds|layer-acht).org
   PGP fingerprint: B8BF 5413 7B09 D35C F026 FE9D 091A B856 069A AA1C


signature.asc
Description: PGP signature

Bug#930600: dev-ref: common.ent should be switched to utf-8

[Holger Levsen]

package: developers-reference
severity: minor
x-debbugs-cc: Osamu Aoki , 930...@bugs.debian.org


On Sun, Jun 16, 2019 at 09:23:42AM +0900, Osamu Aoki wrote:
> If you see my initial diff on the first line of common.ent
> 
>  -
>  +
> 
> Although for ASCII code range (7-bits), iso-8859-1, utf-8, ascii are the
> same, shouldn't we use UTF-8 in line with XML code?  Was there any
> specific issues to do this?
> 
> THis is no rush but I think this is the right way (Am I wrong?)

agreed & thanks for pointing this out as well. 

post buster material though :)


-- 
tschau,
Holger

---
   holger@(debian|reproducible-builds|layer-acht).org
   PGP fingerprint: B8BF 5413 7B09 D35C F026 FE9D 091A B856 069A AA1C


signature.asc
Description: PGP signature

Bug#931548: Migration to Sphinx

[Holger Levsen]

Hi Osamu,

On Sun, Jul 07, 2019 at 10:52:23PM +0900, Osamu Aoki wrote:
> You can build HTML and PDF with "make".

\o/

> debian/* still needs to be polished as of this posting.

ok :)

> The conversion process is completely recorded in the history.  If main branch
> is update, we can rebase most of rest8 and do the operation as in the commit
> message to get conversion for the updated master if needed.

cool cool cool!

> Maybe, now I think Sphinx expert can take over to get proper packaging.

yeah, indeed! ;)

I think it's ok if the master branch is broken for some time, this
conversation has been much desired to get developers-reference in an
editable state again, so here we go.

And thank you very much for the work until here, Osamu!


-- 
tschau,
Holger

---
   holger@(debian|reproducible-builds|layer-acht).org
   PGP fingerprint: B8BF 5413 7B09 D35C F026 FE9D 091A B856 069A AA1C


signature.asc
Description: PGP signature

Bug#931548: Migration to Sphinx

[Holger Levsen]

Hi,

adding Sean to cc: for the question mentioned below.


On Mon, Jul 22, 2019 at 11:24:41PM +0900, Osamu Aoki wrote:
> Do you know anyone good in this.   Is there any volunteer?  (I am
> seeking help on the mailinglist at sphinx-us...@googlegroups.com now)

I'm currently constantly asking on the #debconf channel for any takers :)

> > I think it's ok if the master branch is broken for some time, this
> > conversation has been much desired to get developers-reference in an
> > editable state again, so here we go.
> 
> One thing stopping me to move forward is the difference of i18n HTML
> page arrangement:
> 
>  * Debian web site https://www.debian.org/doc/manuals/developers-reference/
>It offers the automatic locale adjusted content by using
>index.en.html, index.fr.html, ...
>  * Sphinx based web sites such as https://docs.python.org/3/
>It offers the manual pull-down menu and web pages are placed at
>.../en/index.html .../fr/index.html
> 
> How should we arrange web page? I want to migrate to Sphinx-style.
> But that will break current URL links.  Any opinion?

I wonder how this was done for debian-policy which is also hosted on
www.debian.org. Sean, do you have any insight on this?

> Please note Debian web pages will be generated from the latest unstable
> version binary package. 
 
nods. Given how few development there was in recent years on dev-ref I
do think its ok if it will take 1-3 months until the next release ;)


-- 
tschau,
Holger

---
   holger@(debian|reproducible-builds|layer-acht).org
   PGP fingerprint: B8BF 5413 7B09 D35C F026 FE9D 091A B856 069A AA1C


signature.asc
Description: PGP signature

Bug#931548: Migration to Sphinx

[Holger Levsen]

hi,

dear debian-www people: src:developers-reference was just switched to
use sphinx, just like src:debian-policy. However, no upload to unstable
has been made yet...

On Tue, Jul 23, 2019 at 08:13:50AM -0700, Sean Whitton wrote:
> On Mon 22 Jul 2019 at 09:22pm +00, Holger Levsen wrote:
> > I wonder how this was done for debian-policy which is also hosted on
> > www.debian.org. Sean, do you have any insight on this?
> Paul, Laura and Osamu hacked on the www-team's scripts until it worked
> -- I'm afraid I wasn't involved other than reporting problems with the
> published version of Policy, and I don't think we made changes to our
> package in response to any requests from the www-team.

Am I correct to assume we could go a similar way with src:developers-reference ?

If you wanted, you could test by cloning the git repo, install the
build-depends and run 'make'. The package build is still broken...


-- 
tschau,
Holger

---
   holger@(debian|reproducible-builds|layer-acht).org
   PGP fingerprint: B8BF 5413 7B09 D35C F026 FE9D 091A B856 069A AA1C


signature.asc
Description: PGP signature

Bug#931548: Migration to Sphinx

[Holger Levsen]

hi,

On Thu, Jul 25, 2019 at 10:22:24PM +0900, Osamu Aoki wrote:
> > > -- I'm afraid I wasn't involved other than reporting problems with the
> > > published version of Policy, and I don't think we made changes to our
> > > package in response to any requests from the www-team.
> > Am I correct to assume we could go a similar way with 
> > src:developers-reference ?
> Yes.

coolio

> Only remaining problem is it builds multi-language outputs as packages
> but not for web.

well, the packaging also expects to have .txt files to work on to
replace the placeholders with common-entities?


> I mean that the English files are available on
> www.debian.org but translations don't show up as described in
> https://www.debian.org/intro/cn This is because  all html files are
> names as index.html etc. without language code, so automatic language
> selection can not be implemented.
> 
> We can do 2 ways.  
[...] 
> If I figure how to set up option2 type i18n web page, I may even do it
> for debian-handbook.

yeah, I also strongly prefer option 2.


-- 
tschau,
Holger

---
   holger@(debian|reproducible-builds|layer-acht).org
   PGP fingerprint: B8BF 5413 7B09 D35C F026 FE9D 091A B856 069A AA1C


signature.asc
Description: PGP signature

Bug#931548: Migration to Sphinx -- developers-reference

[Holger Levsen]

Hi,

On Tue, Aug 06, 2019 at 11:36:25PM +0900, Osamu Aoki wrote:
> With today's commit, pull-down language selection seems to work for
> package installed files.  Also now we have Gnome desktop icon ;-)

great!

> It is usable, I think.

I think so too! :)

> > yeah, I also strongly prefer option 2.
> I think I figured out OK.  This is my first web page using javascript.
> It should be easy to add menu to select pdf/text/epub download now just by
> updating the existing template file and javascript.

coolio.

> If any of you have good sense of color, adjusting color via CSS may be
> an option for this pull-down menu.

I'm sure eventually someday someone will come around and improve this.

> Your feed back is most appreciated.

thank you for your work!


-- 
cheers,
Holger

---
   holger@(debian|reproducible-builds|layer-acht).org
   PGP fingerprint: B8BF 5413 7B09 D35C F026 FE9D 091A B856 069A AA1C


signature.asc
Description: PGP signature

Bug#931548: Migration to Sphinx -- developers-reference

[Holger Levsen]

On Sun, Aug 11, 2019 at 11:51:32PM +0900, Osamu Aoki wrote:
> I saw you uploaded a new version.  Thanks.

most changes were from you, so thank you very much too!

> As I see this package, remaining tasks are:

this list looks good to me. highest prio for me is getting
https://www.debian.org/doc/devel-manuals#devref fixed though.

> I am playing with the pudb python debugger to learn how docutils/sphinx works 
> :-)

nice!

-- 
cheers,
Holger

---
   holger@(debian|reproducible-builds|layer-acht).org
   PGP fingerprint: B8BF 5413 7B09 D35C F026 FE9D 091A B856 069A AA1C


signature.asc
Description: PGP signature

Bug#940234: debian-policy: add a section about source reproducibility

[Holger Levsen]

On Sat, Sep 14, 2019 at 01:34:49PM +0200, Aurelien Jarno wrote:
> There is already a section about reproducibility in the debian-policy,
> but it only mentions the binary packages. It might be a good idea to
> add a new requirement that repeatedly building the source package in
> the same environment produces identical .dsc file modulo the GPG
> signature.
> 
> I haven't checked how many packages do not fulfill this condition

please do check. last (and only) time we (=r-b) looked, it wasn't
practical at all. this was around 5 years ago, but I don't remember any
work done on improving this.


-- 
cheers,
Holger

---
   holger@(debian|reproducible-builds|layer-acht).org
   PGP fingerprint: B8BF 5413 7B09 D35C F026 FE9D 091A B856 069A AA1C


signature.asc
Description: PGP signature

Bug#940234: debian-policy: add a section about source reproducibility

[Holger Levsen]

On Sat, Sep 14, 2019 at 11:57:43PM +0200, Guillem Jover wrote:
> > >> I haven't checked how many packages do not fulfill this condition
> > > please do check. last (and only) time we (=r-b) looked, it wasn't
> > > practical at all. this was around 5 years ago, but I don't remember any
> > > work done on improving this.
> Back when we were fixing the binary package reproducible problems
> within dpkg, I also checked the source side, and fixed a few
> problematic cases. Assuming the same tools installed as defined in
> the .buildinfo file, and the same content in the unpacked source
> tree, dpkg-source should be producing the same output source packages.

oh, cool, thanks for this spreading this information!

> If this does not hold, I'd consider it a bug to be fixed.

great!

so now someone just needs to do something^wa rebuild of say 1000 source
packages and share the stats...


-- 
cheers,
Holger

---
   holger@(debian|reproducible-builds|layer-acht).org
   PGP fingerprint: B8BF 5413 7B09 D35C F026 FE9D 091A B856 069A AA1C


signature.asc
Description: PGP signature

Bug#884857: developers-reference: clarify process on retirement/improve wording

[Holger Levsen]

On Sat, Sep 21, 2019 at 05:24:34PM +0700, Judit Foglszinger wrote:
> Added patch for updating retirement/return description to new process.

thank you & happily merged!


-- 
cheers,
Holger

---
   holger@(debian|reproducible-builds|layer-acht).org
   PGP fingerprint: B8BF 5413 7B09 D35C F026 FE9D 091A B856 069A AA1C



signature.asc
Description: PGP signature

Bug#884857: developers-reference: clarify process on retirement/improve wording

[Holger Levsen]

On Mon, Sep 23, 2019 at 12:46:19AM +0700, Judit Foglszinger wrote:
> Updated both descriptions.

merged, thank you both.


-- 
cheers,
Holger

---
   holger@(debian|reproducible-builds|layer-acht).org
   PGP fingerprint: B8BF 5413 7B09 D35C F026 FE9D 091A B856 069A AA1C



signature.asc
Description: PGP signature

Bug#941274: developers-reference: please mention packaging-tutorial

[Holger Levsen]

package: developers-reference
severity: wislist

hi,

subject says it all, please mention packaging-tutorial somewhere.


-- 
cheers,
Holger

---
   holger@(debian|reproducible-builds|layer-acht).org
   PGP fingerprint: B8BF 5413 7B09 D35C F026 FE9D 091A B856 069A AA1C



signature.asc
Description: PGP signature

Bug#941274: Acknowledgement (developers-reference: please mention packaging-tutorial)

[Holger Levsen]

control: retitle -1 developers-reference: please mention the packaging-tutorial 
and lintian-brush packages
thanks

-- 
cheers,
Holger

---
   holger@(debian|reproducible-builds|layer-acht).org
   PGP fingerprint: B8BF 5413 7B09 D35C F026 FE9D 091A B856 069A AA1C



signature.asc
Description: PGP signature

Bug#941475: debian-policy: please document the /run/reboot-required thingy in the upgrade changelog

[Holger Levsen]

On Thu, Oct 03, 2019 at 10:40:09AM +0200, Mattia Rizzolo wrote:
> I only read the title of the d-d-a mail, but I read the upgrade
> checklist many times over the course of the years.  

almost the same here, just that I usually read the mail too.


-- 
cheers,
Holger

---
   holger@(debian|reproducible-builds|layer-acht).org
   PGP fingerprint: B8BF 5413 7B09 D35C F026 FE9D 091A B856 069A AA1C



signature.asc
Description: PGP signature

Bug#658825: Provide *single* page HTML manuals in http://www.debian.org/doc/*

[Holger Levsen]

block 658825 by 873456
block 658825 by 876075
block 658825 by 879048
thanks

hi,

fwiw, src:developers-reference/Makefile now contains these lines:

# singlehtml files
# don't install Sphinx singlehtml output until various bugs
# are fixed upstream (e.g. #873456, #876075, #879048)
#cp $(BUILD_DIR)/en/singlehtml/$(PACKAGE).html $(DESTDIR)$(datadir)
#@set -ex; for l in $(filter-out en,$(LANGS)); do   \
#cp $(BUILD_DIR)/$$l/singlehtml/$(PACKAGE).html 
$(DESTDIR)$(datadir)/$$l ;  \
#done


-- 
cheers,
Holger

---
   holger@(debian|reproducible-builds|layer-acht).org
   PGP fingerprint: B8BF 5413 7B09 D35C F026 FE9D 091A B856 069A AA1C



signature.asc
Description: PGP signature

Bug#658825: Provide *single* page HTML manuals in http://www.debian.org/doc/*

[Holger Levsen]

On Fri, Oct 04, 2019 at 09:07:41PM +, Holger Levsen wrote:
> fwiw, src:developers-reference/Makefile now contains these lines:
> 
> # singlehtml files
> # don't install Sphinx singlehtml output until various bugs
> # are fixed upstream (e.g. #873456, #876075, #879048)
> #cp $(BUILD_DIR)/en/singlehtml/$(PACKAGE).html $(DESTDIR)$(datadir)
> #@set -ex; for l in $(filter-out en,$(LANGS)); do   \
> #cp $(BUILD_DIR)/$$l/singlehtml/$(PACKAGE).html 
> $(DESTDIR)$(datadir)/$$l ;  \
> #done
 
the comments are outdated, all these three bugs have been fixed in the
meantime...


-- 
cheers,
Holger

---
   holger@(debian|reproducible-builds|layer-acht).org
   PGP fingerprint: B8BF 5413 7B09 D35C F026 FE9D 091A B856 069A AA1C



signature.asc
Description: PGP signature

Bug#658825: Provide *single* page HTML manuals in http://www.debian.org/doc/*

[Holger Levsen]

On Sat, Oct 05, 2019 at 12:12:55PM +0200, Bill Allombert wrote:
> > the comments are outdated, all these three bugs have been fixed in the
> > meantime...
> Does that mean the singlehtml version can be restored ?
> Does this apply to debian-policy too ?

I've no idea, I just noticed these bugs are closed (and thus the
comments are outdated).


-- 
cheers,
Holger

---
   holger@(debian|reproducible-builds|layer-acht).org
   PGP fingerprint: B8BF 5413 7B09 D35C F026 FE9D 091A B856 069A AA1C



signature.asc
Description: PGP signature

Bug#318637: why #318637? "Recommend that -dev documents be symlinks"

[Holger Levsen]

control: tags -1 wontfix
thanks

hi,

in 2005 manoj wrote to this bug "BTW, _why_ are these -dev packages
duplicating files already in a package they depend on?" and I have to
say, I'm wondering the same and don't think this is true anymore, so I'm
tagging this wontfix. Please correct me if I'm wrong ;)


-- 
cheers,
Holger

---
   holger@(debian|reproducible-builds|layer-acht).org
   PGP fingerprint: B8BF 5413 7B09 D35C F026 FE9D 091A B856 069A AA1C



signature.asc
Description: PGP signature

Bug#399028: developers-reference: best practices to create and delete system accounts

[Holger Levsen]

Hi Marc,

On Fri, Nov 17, 2006 at 09:41:48AM +0100, Marc Haber wrote:
> The information collected in
> http://wiki.debian.org/AccountHandlingInMaintainerScripts should
> eventually be put into the developer's reference, chapter 6.5.
 
would you suggest to remove all of that from this wiki page and then add
a pointer to developers-reference or what would you suggest today?

A suggestion where exactly to add this in the developers-reference would
also be welcome, btw.


-- 
cheers,
Holger

---
   holger@(debian|reproducible-builds|layer-acht).org
   PGP fingerprint: B8BF 5413 7B09 D35C F026 FE9D 091A B856 069A AA1C



signature.asc
Description: PGP signature

Bug#941835: debian-policy: drop mentioning of legacy manual in package description

[Holger Levsen]

Package: debian-policy
Version: 4.4.1.1
Severity: normal

Dear Maintainer,

the current package description contains this paragraph:

 It also replaces the old Packaging Manual; most of the still-relevant
 content is now included as appendices to the Policy Manual.

I'm around a long time and I dont remember the old Packaging Manual, so
I think this paragraph can safely be dropped.


Thanks for your work on debian-policy!

-- 
cheers,
Holger

---
   holger@(debian|reproducible-builds|layer-acht).org
   PGP fingerprint: B8BF 5413 7B09 D35C F026 FE9D 091A B856 069A AA1C



signature.asc
Description: PGP signature

Bug#288822: marked as done (developers-reference: "Bugs" control field not documented)

[Holger Levsen]

Hi Guillem,

On Tue, Oct 08, 2019 at 12:30:50PM +0200, Guillem Jover wrote:
> > I don't really understand "#288822: developers-reference: "Bugs" control 
> > field
> > not documented" and I'm not sure it's really an issue still.
> This would be the Bugs field documented now in both deb-control(5) and
> deb-src-control(5), since dpkg 1.14.7 (2007-10-08), ref #173463.

thanks for that information! do you agree there's nothing to be added to
dev-ref?


-- 
cheers,
Holger

---
   holger@(debian|reproducible-builds|layer-acht).org
   PGP fingerprint: B8BF 5413 7B09 D35C F026 FE9D 091A B856 069A AA1C



signature.asc
Description: PGP signature