Re: Bug#991533: lintian: please forget about required-field Standards-Version for udeb packages

[Henrique de Moraes Holschuh]

On Fri, Aug 13, 2021, at 17:37, Sean Whitton wrote:
> On Fri 13 Aug 2021 at 12:36PM -07, Felix Lechner wrote:
> 
> > How do you know that people actually bring their packages up to the
> > latest policy revision before they update the Standards-Version field?
> 
> There is a "must" requirement not to do that in Policy, and I trust DDs
> to follow those.

Indeed...

> > I believe people bump the Standards-Version in order to unleash the
> > most recent Lintian tags, which is a fallacy that makes the field
> > unreliable, and probably superfluous.
> 
> I have never heard of this.  Surely that's a solveable documentation
> issue, even if it takes a posting to d-d-a?

I haven't heard of it either, I personally go over the upgrading checklist by 
policy version before I update the field in any packages I am working on.

It would be enough to add to lintian a CLI option to force a standards-version 
to use as baseline, hopefully?  Assuming it doesn't have one yet, which it  
might very well have...

-- 
  Henrique de Moraes Holschuh 

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

[Henrique de Moraes Holschuh]

On Fri, 16 Nov 2018, Sean Whitton wrote:
> On Fri 16 Nov 2018 at 12:22PM -0200, Henrique de Moraes Holschuh wrote:
> > How about also adding one that makes it clear that in *Debian*, policy
> > follows practice, and not the other way around (which should also
> > require seconds just to make sure people agree with this, even if it is
> > a decades-long practice in debian-policy)...
> 
> This is already there, in § 1.3.3

Not in such a clearly stated form, but yeah.  Anyway, that was a passing
comment, it is off-topic on this bug report, and for that I apologise...

-- 
  Henrique Holschuh

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

[Henrique de Moraes Holschuh]

On Tue, 13 Nov 2018, Ian Jackson wrote:
> Package: debian-policy
> Version: 4.2.1.4
> 
> The discussion in #913572 is just another instance of the following
> antipattern:
> 
>Submitter:   program X does strange thing Y which is undesirable
>Maintainer:  Y is not against policy
> 
> 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.

Seconded.

How about also adding one that makes it clear that in *Debian*, policy
follows practice, and not the other way around (which should also
require seconds just to make sure people agree with this, even if it is
a decades-long practice in debian-policy)...

-- 
  Henrique Holschuh


signature.asc
Description: PGP signature

Re: debian/upstream/signing-key.asc in policy 4.1.0

[Henrique de Moraes Holschuh]

On Wed, 23 Aug 2017, Russ Allbery wrote:
> Note that this Policy language is carefully written to make it perfectly
> fine for uscan to support all the things it currently supports, since it
> only talks about what Policy recommends the maintainer does.  So don't
> feel any obligation to change what uscan is doing on Policy's account
> here.

Actually, the text in 4.1.0.0 might be doing too much.  It reads:

"If the upstream maintainer of the software provides OpenPGP signatures
for new releases, including the information required for "uscan" to
verify signatures for new upstream releases is also recommended. To do
this, use the "pgpsigurlmangle" option in "debian/watch" to specify
the location of the upstream signature, and include the key or keys
used to sign upstream releases in the Debian source package as
"debian/upstream/signing-key.asc".

IMO, it should either not be mandating uscan internals, or it should be
very clear about the exact subset of stuff we can use in debian/watch
(version, etc).  For example, I'd rather use opt="..., pgpmode=auto,..."
instead of explicitly hardcoding a "pgpsigurlmangle".

IMHO, just drop everything from "To do this..." to the end of that
paragraph entirely.  HOW one gets "uscan" to fetch and check upstream
signatures is a job for the uscan(1) manpage.  Alternatively, just
mention "debian/watch", and to refer to the uscan documentation in
package "devscripts".

OTOH, if we really need to mandate a specific level of debian/watch
support, the current text in policy needs work: it doesn't even tell me
whether I can use version=3 (supported in oldstable), or version=4
(supported in oldstable-backports and stable), for example...

-- 
  Henrique Holschuh

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

[Henrique de Moraes Holschuh]

On Thu, 24 Aug 2017, Sean Whitton wrote:
> Seconded, but I think the integrity protection is a more important
> reason to avoid the git protocol or http, so if we can come up with a
> further change to reflect that it would be better.

Attacking the integrity of the messages in transit requires active MITM
attacks for all three protocols (http, https, git).

https *without* strong certificate validation has no defense against
active MITM, i.e. it does *not* protect message integrity against
attacks.

And since all of the required PKI for https to do strong certificate
validation is out-of-band, we have to assume naive https use.

So, no, this is not about integrity.  It is, at most, about privacy
against passive eavesdropers.  If you want integrity, a lot more is
needed.

-- 
  Henrique Holschuh

Re: Upstream Tarball Signature Files

[Henrique de Moraes Holschuh]

On Mon, 14 Aug 2017, Russ Allbery wrote:
> Henrique de Moraes Holschuh <h...@debian.org> writes:
> > On Sun, 13 Aug 2017, Russ Allbery wrote:
> >> it can't just move the file -- it has to ASCII-armor it.  But still, I
> >> think that's the right thing for the tools to do, not add another file.
> >> (The ASCII format is completely equivalent to the binary format; the
> >> conversion shouldn't lose or change any data.)
> 
> > The armor just wastes space, and will do so for every signature in the
> > archive.
> 
> I very much doubt we will ever notice such a tiny amount of overhead.

We do when the binary sig is small enough to be stored along with the
inode, instead of requiring an entire filesystem block (4KiB), and the
armored signature is not small enough for that :-(   Of course, this
really depends a lot on the filesystem, etc.

It is not an extreme difference anyway even in the worst case, but it
might be a Good Idea to avoid technical debt on a feature we have not
even deployed to production (as in "started to use") yet, without at
least considering the alternatives.

> > Why are we not using binary signatures in the first place, if we're
> > going to mandate conversions?
> 
> We could go that route too, but I don't think the benefits are worth
> changing the existing code that supports *.asc files.  But I certainly
> wouldn't object if the folks doing the work wanted to change.  I just want
> to support only one or the other.

Then we should have gone with .sig :-(  At least it means "signature",
and not "ascii text".

May I humbly suggest that, *if* a change is going to be made, we switch
to ".sig" (binary) and ".sig.asc" (armored), or .sig.gpg / sig.gpg.asc?
As in "let's not overload .asc to mean armored signature, when it only
means ASCII text"...

-- 
  Henrique Holschuh

Re: Upstream Tarball Signature Files

[Henrique de Moraes Holschuh]

On Sun, 13 Aug 2017, Russ Allbery wrote:
> it can't just move the file -- it has to ASCII-armor it.  But still, I
> think that's the right thing for the tools to do, not add another file.
> (The ASCII format is completely equivalent to the binary format; the
> conversion shouldn't lose or change any data.)

The armor just wastes space, and will do so for every signature in the
archive.

Why are we not using binary signatures in the first place, if we're
going to mandate conversions?

-- 
  Henrique Holschuh

Bug#865713: Please Start UTF-8 debian-policy Text Files with UTF-8 Signature

[Henrique de Moraes Holschuh]

On Sat, 24 Jun 2017, Russ Allbery wrote:
> Russ Allbery  writes:
> > I did a bit more research, and apparently this approach has become more
> > blessed again.  I'm glad I looked it up!  As of Unicode 5.0, the

...

> Okay, I experimented with this, but unfortunately less displays the BOM at
> the start of the file as a very ugly reverse-video  at the top of
> the screen.

An alternative would be to just use .8txt, .u8txt or some other
extension for UTF-8 text files that is not ".txt".

This also addresses the mix of UTF-8 and unknown charset .txt files in
our web trees, the difficulty of configuring charsets out-of-band across
a mirror network, etc.

An imperfect world asks for imperfect solutions :-(  All of them will
have drawbacks.

-- 
  Henrique Holschuh

Bug#865367: developers-reference: section 5.5.1: explicitly mention that stable and oldstable uploads must use release codename

[Henrique de Moraes Holschuh]

Package: developers-reference
Version: 3.4.18
Severity: normal

Section 5.5.1 seems to imply uploads to stable and oldstable should
target "stable" or "oldstable" in the distribution field of the
changelog entry, which is incorrect.

Please add explicit text to section 5.5.1, directing uploaders to use
the release codename, instead (e.g. "jessie", "wheezy"...).

Suggested text:

When uploading to stable, debian/changelog should use the release
codename as the target. I.e. upload to "jessie", "stretch", etc. instead
of uploading to "stable" or "oldstable".

Thank you!

-- 
  Henrique Holschuh

Bug#835520: [PATCH v2 11/11] Drop entire section 9.4 Console messages from init.d scripts

[Henrique de Moraes Holschuh]

On Sat, Dec 17, 2016, at 10:57, Andreas Henriksson wrote:
> The entire section is specific to sysvinit and already solved
> by LSB in that case. There's no point in reinventing LSB.

Then, instead of deleting it entirely, wouldn't it be better to replace
it with text directing maintainers to follow the relevant sections of
the LSB?

-- 
  Henrique de Moraes Holschuh <h...@debian.org>

Bug#844431: Packages should be reproducible

[Henrique de Moraes Holschuh]

On Tue, 15 Nov 2016, Chris Lamb wrote:
> [As a mild suggestion to streamline this; we should probably come to some
> consensus on principle of this addition to Policy first and only then
> move to the more difficult topic of defining exactly what reproducibility
> means in a technical sense.]

I don't think there will be much of a contention about this.

Please propose wording (i.e. the diff to the policy text), but I
recommend that you do *not* use "should" or "must" to make such
reproducibility mandatory right now, only to define stuff like "*if* it
is built for reproducibility, it must do so in such a way that...", etc.

Enforcing package reproducibility (should/must in policy) has to wait
until a majority of the package is effectively being reproducibly built
for a small while (to shaken up any issues), and the tooling echosystem
is complete so that it is actually usable to verify things.  IMHO, this
would be best done only after stretch is released, even if we reach >85%
reproducibility levels *and* a full, working toolset before that.

As a suggestion, since a "may build reproducibly" policy is not going to
give the readers the desired idea, the policy text proposal could use
words to the effect that "it is recommended that", and "in the future,
this will become a requirement".

Any packages that absolutely cannot be built in a reproducible way[1],
can become oficially allowed exceptions -- and we could likely teach the
verification tools that specific regions of a package/file are to be
random, and ignore those when comparing for reproducibility, too.  But
this would be tackled on in the future, between an already implemented
policy of SHOULD is out, and >95% of the packages are being built
reproducibly and policy is about to be changed to MUST.  Therefore, the
initial proposal just needs to acknowledge that this fact could happen
and will be dealt with in time.

[1] Such as random noise added to kernel and firmware data structures
during local builds, to be used as a last defense to avoid the *herd
using same keys* effects, etc.

-- 
  Henrique Holschuh

Bug#823584: [PATCH] Correct top-level directory name in repackaged tarballs

[Henrique de Moraes Holschuh]

On Fri, 06 May 2016, Tormod Volden wrote:
> PS. I didn't think about it initially, but I guess "NACK" means
> "thanks for your patch and your interest in the developer reference,
> but I don't think this is the best solution."

That's pretty much correct, yes.

NACK in this context implies that whatever you proposed was carefully
considered by the person "NACK'ing" it, and then rejected.  An explanation
for the rejection should be provided along with the "NACK".

It is very common lingo on Linux-releated FLOSS development mailing lists,
when rejecting a changes proposal (patch), etc.

-- 
  "One disk to rule them all, One disk to find them. One disk to bring
  them all and in the darkness grind them. In the Land of Redmond
  where the shadows lie." -- The Silicon Valley Tarot
  Henrique Holschuh

Re: Bug#802501: init script failures during postinst and related scripts

[Henrique de Moraes Holschuh]

On Tue, Oct 20, 2015, at 14:08, Daniel Pocock wrote:
> If postinst or one of the other scripts does a service restart and the
> restart operation fails, should the postinst abort or should it mask the
> error, continue and return success?

Whatever makes more sense for that particular service, as in "safer". 
And by safer I do mean: smaller chance of aggravating already present
damage, causing security issues, or data loss".

> If it continues, is there any other convention for reporting the
> problem, e.g. stderr?

You report errors and warnings to stderr, yes.  For sysvinit there is a
shell API that can be used for that.  Systemd might have its own
convention for unit files.

A better way to get error/warning information to the user would be
welcome, but it needs to be properly planned (headless nodes, unattended
upgrades, desktops with crippled local mail delivery/routing, etc).

-- 
  "One disk to rule them all, One disk to find them. One disk to bring
  them all and in the darkness grind them. In the Land of Redmond
  where the shadows lie." -- The Silicon Valley Tarot
  Henrique de Moraes Holschuh <h...@debian.org>

Re: Bug#801065: Section 6.4 - discourage failing install or upgrade when service fails to start

[Henrique de Moraes Holschuh]

On Mon, Oct 5, 2015, at 22:13, Marvin Renich wrote:
> The discussion started on d-devel; should it be moved back there?  The
> overwhelming majority of opinion seems to be in favor of the change.

We have supported per-package behavior on this for a very long time,
maybe since forever (this is no joke).  We have had packages that
restart after the upgrade instead of stopping before, or that ignore
service start failures during upgrades for *years*.

All it takes is that the package maintainer actually stop to think about
it, consider which behavior is more appropriate to that specific
package, and adjust things appropriately.  There is a damn good reason
why policy does not use "must" to mandate service start/stop/restart
behavior across package updates.

The reason for this thread, an "undesired" behavior of stopping a
package upgrade if the service fails to start, which is the current
default, is both employed by the (likely few) packages that absolutely
depend on it to avoid worse damage down the service/package dependency
chain, as well as by packages that the maintainer did not even think
about the issue (and therefore might or might not need this behavior).

IMO, we should not just "change this default" in the *implementation*
(debhelper, etc), at least not without actually acessing the real risk
of the change.  It does not look like this kind of risk accessment was
done by anyone yet in the d-devel thread.  Just because we expect it to
be low, doesn't mean it doesn't exist or that it won't have a high
impact on the user if it happens.

If the need for this kind of provision in a possible policy text update
(possibly as a foot-note) is contentious, IMHO the matter needs to go
back to d-devel for further discussion.

-- 
  "One disk to rule them all, One disk to find them. One disk to bring
  them all and in the darkness grind them. In the Land of Redmond
  where the shadows lie." -- The Silicon Valley Tarot
  Henrique de Moraes Holschuh <h...@debian.org>

Bug#798714: debian-policy: Please explicitly recommend punctuation between the year, month and day components of date based version numbers

[Henrique de Moraes Holschuh]

On Fri, 11 Sep 2015, Axel Beckert wrote:
> To demonstrate my point, please sort the following version numbers in
> your head:
> 
> * 20110111.0
> * 2010.1
> * 2011.2

These are rather bad, as you might need to use epochs.  In fact, they go
against documented current best practice due to a lack of an initial field
that is not the date.

But they're utterly easy to sort on sight.

> * 9.20111211
> * 9.2021

These, and similar variants (major.MMDD.minor) are good:  Your eyes
easily lock on the several semanthic components of the version field, and
when you have any trouble, you just bump major without the need to resort to
epochs.

> And now compare the same dates, but written with punctuation:
> 
> * 2011.01.11.0
> * 2010.11.11.1
> * 2011.11.11.2
> * 9.2011.12.11
> * 9.2011.11.21

Ugh.  All of them look like something the cat dragged in as far as _I_ am
concerned.  Others might disagree, of course: you clearly would.  The point
is that this is controversial.

But what is really nasty IMHO is the fact that the same delimiter is used
for the date and for other semanthic components.  I would not be nearly as
opposed to something like  9+2011.11.21+3, but I would still never use that
unless forced.

I'd rather leave '+' out of base version numbers, so as to have it stand out
for its other higher-level uses (we regularly use "+" for bin-NMUs, security
updates, stable updates, etc).

> So please change the above cited policy section in a way that it is
> clear that the ".MM.DD" format is preferred and the format without

Do you have statistics on the current patterns used in the archive?  If most
are of the something..MM.DD.something_else sort, I'd agree that it is
preferred.

> Here's a suggestion for an updated text:
> 
> | […] the date-based portion of any upstream version number should be
> | given in a way that sorts correctly: four-digit year first, followed
> | by a two-digit numeric month, followed by a two-digit numeric date,
> | with punctuation between the components.
> |
> | […] Since punctuation is desired between the date components, remember
> | that hyphen (-) cannot be used in native package versions. Period (.)
> | is the recommended choice.
> 
> P.S.: Yes, I'm aware that this doesn't help much for existing badly
> formatted date-based version numbers, as it would need an epoch to
> change it. But since many packages (like e.g. debhelper) use a prefix
> number anyway (e.g. 9.20150811), this could be changed when the date
> prefix is bumped the next time, e.g. to 10.2015.09.23 or so. And if
> someone thinks that makes it less obvious where the date starts, a
> different delimiter before the date could be chosen, e.g. 10+2015.09.23.

I oppose this change on several grounds.

1. I personally feel it is horrible beyond belief, i.e. this is highly
   subjective matter with little technical reasons to mandate in one
   way or the other.

2. -policy documents best current *ADOPTED* practice.

   First, you get a sizeable fraction of the packages to implement it
   (like >70%), which *might* warrant a _should_ in policy.

   Then you get nearly everything to implement it, OR agreement in
   -devel, or get it to become a release goal.  That likely warrants
   a _must_ in policy.

Even on non-normative sections, the spirit of (2) above should prevail.

Now, if you do the statistic work to show that the absolute majority of our
packages use "." as a delimiter inside dates, then it would make sense to
continue this thread on the grounds that is indeed already adopted common
practice -- but even in this case, a softer wording is likely required.

-- 
  "One disk to rule them all, One disk to find them. One disk to bring
  them all and in the darkness grind them. In the Land of Redmond
  where the shadows lie." -- The Silicon Valley Tarot
  Henrique Holschuh

Re: Bug#761219: debian-policy: document versioned Provides

[Henrique de Moraes Holschuh]

On Fri, Mar 27, 2015, at 08:41, Niko Tyni wrote:
 On Fri, Mar 13, 2015 at 05:38:39PM -0300, Henrique de Moraes Holschuh
 wrote:
  On Fri, 13 Mar 2015, David Prévot wrote:
   On Thu, Sep 11, 2014 at 09:57:57PM +0300, Niko Tyni wrote:
dpkg 1.17.11 and apt 1.0.7 recently implemented support for versioned
provides.
   […]
This clearly needs an update. No proposed wording yet, sorry.
   
   Here is a simple one, stripping away the incorrect restriction. The
   consideration about versioned virtual package may evolve with the dpkg
   implementation, so I don’t believe it is worth it to document it in the
   policy, at least not right now anyway.
  
  Support for versioned provides is still too new: it is present only in
  Jessie and unstable.  This is a concern when dealing with backports.
 
 So how long do you propose we should wait before adopting new dpkg/apt
 features, if one release cycle isn't enough anymore?

IMO, at least three stable releases before policy can remove entirely
information that is relevant to past stable releases (because of the LTS
branches).  I guess two stable releases might even be enough, but one
stable release is certainly too early.

Note that I don't care if we move information related to older stable
releases to footnotes to unclutter the main text, as long as we don't
remove it entirely.

Evidently, we can and should add or update information as soon as it is
stable enough: it is just a matter of doing it in a way that we still
document past behavior as well.

 FWIW I don't think the policy needs to change before jessie is
 released, but I don't think anybody was aiming for that anyway?

I have nothing against documenting that versioned provides is supported
by dpkg version  in jessie and later, _and_ getting that updated
policy into jessie. In fact, I'd like it.

However, I have everything against NOT mentioning that versioned
provides are not supported before dpkg  (i.e. cannot be used in
wheezy and earlier).

  I'd recommend we change the current text, but not by removing the
  restriction on versioned provides.  Instead, mention that it does not exist
  anymore since Debian jessie (dpkg 1.17.11 and newer).
 
 How about removing the restriction, but adding a footnote mentioning
 that support for versioned provides is still new, and care should be
 taken not to create needless complications on possible backports?

A footnote mentioning the dpkg version that implemented versioned
provides, and the stable release when it was first shipped would be
enough, as far as I'm concerned.

-- 
  One disk to rule them all, One disk to find them. One disk to bring
  them all and in the darkness grind them. In the Land of Redmond
  where the shadows lie. -- The Silicon Valley Tarot
  Henrique de Moraes Holschuh h...@debian.org


--
To UNSUBSCRIBE, email to debian-policy-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: 
https://lists.debian.org/1427459182.2725229.245994581.642ec...@webmail.messagingengine.com

Bug#761219: debian-policy: document versioned Provides

[Henrique de Moraes Holschuh]

On Fri, 13 Mar 2015, David Prévot wrote:
 On Thu, Sep 11, 2014 at 09:57:57PM +0300, Niko Tyni wrote:
  dpkg 1.17.11 and apt 1.0.7 recently implemented support for versioned
  provides.
 […]
  This clearly needs an update. No proposed wording yet, sorry.
 
 Here is a simple one, stripping away the incorrect restriction. The
 consideration about versioned virtual package may evolve with the dpkg
 implementation, so I don’t believe it is worth it to document it in the
 policy, at least not right now anyway.

Support for versioned provides is still too new: it is present only in
Jessie and unstable.  This is a concern when dealing with backports.

I'd recommend we change the current text, but not by removing the
restriction on versioned provides.  Instead, mention that it does not exist
anymore since Debian jessie (dpkg 1.17.11 and newer).

-- 
  One disk to rule them all, One disk to find them. One disk to bring
  them all and in the darkness grind them. In the Land of Redmond
  where the shadows lie. -- The Silicon Valley Tarot
  Henrique Holschuh


-- 
To UNSUBSCRIBE, email to debian-policy-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/20150313203839.ga8...@khazad-dum.debian.net

Re: Bug#770016: Clarify network access for building packages in main

[Henrique de Moraes Holschuh]

On Tue, Feb 3, 2015, at 20:21, Bill Allombert wrote:
 On Tue, Feb 03, 2015 at 04:27:56PM +0100, Lucas Nussbaum wrote:
  
  yeah, I second this version:
   +  For packages in the main archive, no required targets
   +  may attempt network access.
  
  even if I would prefer something that did not restrict to main, and said
  something like:
  
No packages may rely on network access to be available during the 
  execution
of required targets.
 
 I have no problem removing the restriction to the main archive.
 (non free is always an exception to policy anyway).
 
 However as I understand, your wording still allow to use network access
 if it
 is available (which I find dangerous).
 
 Maybe 
The execution of a required target must not attempt network
access.
 
 Henrique, did Lucas answers about the archive rebuild address your
 objections ?

Yes.  We can treat exceptions as... exceptions :-)

-- 
  One disk to rule them all, One disk to find them. One disk to bring
  them all and in the darkness grind them. In the Land of Redmond
  where the shadows lie. -- The Silicon Valley Tarot
  Henrique de Moraes Holschuh h...@debian.org


-- 
To UNSUBSCRIBE, email to debian-policy-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: 
https://lists.debian.org/1423051730.4064579.222956817.68a45...@webmail.messagingengine.com

Bug#774384: developers-reference: soften advice to justify retirement to debian-private

[Henrique de Moraes Holschuh]

On Fri, 02 Jan 2015, Cyril Brulebois wrote:
 Jakub Wilk jw...@debian.org (2015-01-02):
  * Jonathan Wiltshire j...@debian.org, 2015-01-01, 21:49:
   -Send an gpg-signed email about why you are leaving the project to
   -emaildebian-private@lists-host;/email.
   +Send an gpg-signed email announcing your retirement to
   +emaildebian-private@lists-host;/email. It's courteous, but not 
   essential,
   +to include a brief explanation of your decision.
  
  Seconded.
 
 Seconded as well.
 
  (I'd even go as far as to remove the second sentence. People will figure
  out themselves that they can explain their reasons if they wish so.)
 
 That would make sense.

Indeed. Seconded, either version is fine IMHO.

-- 
  One disk to rule them all, One disk to find them. One disk to bring
  them all and in the darkness grind them. In the Land of Redmond
  where the shadows lie. -- The Silicon Valley Tarot
  Henrique Holschuh


signature.asc
Description: Digital signature

Bug#773557: debian-policy: Avoid unsafe RPATH/RUNPATH

[Henrique de Moraes Holschuh]

On Sun, 21 Dec 2014, Martin Carpenter wrote:
  Packages are not allowed to create *and* execute libraries or executables
  with unsafe RPATH or RUNPATH at any time, not even during their build
  process.
 
 But actually Package maintainers should not make or run dangerous
 stuff? Agreed -- and also seems uncontroversial. Although I think you
 mean or not and? Perhaps neither/nor to kill any ambiguity:

I did mean build a tool for its build using unsafe RPATH/RUNPATH, run that
build tool, which is a common pitfall on crap that sets RPATH in the first
place...

If it builds the broken build-time tool, but never runs it, there is no harm
since the unsafe binary is not going to be used or shipped.  And if the
unsafe binary is meant for manual running every so often by an attentive
maintainer, we don't really care.

  8.7 RUNPATH and RPATH
 
  Libraries and executables should not define RPATH or RUNPATH unless
  absolutely necessary.
 
  Those that do should ensure that relative paths or paths that traverse
  insecure directories (eg /tmp or /var/tmp) are not included. This
  is to prevent an executable from loading a library from an untrusted
  location. (This should include the corner cases whereby the path list
  starts or ends with a colon, or includes two consecutive colons).
 
  Packages should neither create nor execute libraries or executables
  with unsafe RPATH or RUNPATH at any time, not even during their
  build process.

This is a bit stronger than what I meant, but I don't have anything against
this wording.

-- 
  One disk to rule them all, One disk to find them. One disk to bring
  them all and in the darkness grind them. In the Land of Redmond
  where the shadows lie. -- The Silicon Valley Tarot
  Henrique Holschuh


-- 
To UNSUBSCRIBE, email to debian-policy-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/20141221192648.gd30...@khazad-dum.debian.net

Bug#773557: debian-policy: Avoid unsafe RPATH/RUNPATH

[Henrique de Moraes Holschuh]

On Fri, 19 Dec 2014, Jonathan Nieder wrote:
  8.7 RUNPATH and RPATH
 
  Libraries and executables should not define RPATH or RUNPATH unless
  absolutely necessary.
 
 This part seems vague to me --- if a project relies on RUNPATH but could
 be modified to avoid relying on it, is today's use of RUNPATH absolutely
 necessary?  It's hard enough to act on this recommendation that I don't
 think it belongs in policy yet.

IMO, it does belong in policy, and if anything, its inclusion is late for at
least a decade.

IMHO, the suggested wording does get the point across that whomever wants to
use RPATH/RUNPATH must be prepared to defend its use with strong technical
reasons.

  Those that do should ensure that relative paths or paths that traverse
  insecure directories (eg /tmp or /var/tmp) are not included. This
  is to prevent an executable from loading a library from an untrusted
  location.
 
 This part looks good.

IMO, it is too weak.  This is about introducing security hazards, so...

For security reasons, packages that set RPATH or RUNPATH MUST ensure that
relative paths or paths that traverse insecure directories (e.g. /tmp or
/var/tmp, their original build locations, user home directorites, etc) are
not included.  This is to prevent an executable from loading a library from
an untrusted location.

And in fact, I'd add:

Packages are not allowed to create *and* execute libraries or executables
with unsafe RPATH or RUNPATH at any time, not even during their build
process.

-- 
  One disk to rule them all, One disk to find them. One disk to bring
  them all and in the darkness grind them. In the Land of Redmond
  where the shadows lie. -- The Silicon Valley Tarot
  Henrique Holschuh


-- 
To UNSUBSCRIBE, email to debian-policy-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/20141220041047.ga23...@khazad-dum.debian.net

Re: Bug#666726: debian-policy: Clarify if empty control fields are ollowed or not

[Henrique de Moraes Holschuh]

On Sun, 23 Nov 2014, Bill Allombert wrote:
 diff --git a/policy.sgml b/policy.sgml
 index 6eac491..66de529 100644
 --- a/policy.sgml
 +++ b/policy.sgml
 @@ -2556,13 +2556,15 @@ endif
 example compact=compact
  Package: libc6
 /example
 the field name is ttPackage/tt and the field value
 ttlibc6/tt.
   /p
 -
 +p Empty fields value are only permitted in source package control 
 files
 +   (filedebian/control/file). Such fields are ignored.
 +/p
   p
 A paragraph must not contain more than one instance of a
 particular field name.
   /p
  
   p

I'm okay with this, but wouldn't it be better if it were more assertive
about the fact that empty fields must be supported in source packages, and
must be removed when generating binary packages?

-- 
  One disk to rule them all, One disk to find them. One disk to bring
  them all and in the darkness grind them. In the Land of Redmond
  where the shadows lie. -- The Silicon Valley Tarot
  Henrique Holschuh


-- 
To UNSUBSCRIBE, email to debian-policy-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/20141123154610.gb14...@khazad-dum.debian.net

Bug#555979: debian-policy: Symlinks pointing beyond the root of the file system

[Henrique de Moraes Holschuh]

On Sun, 23 Nov 2014, Jakub Wilk wrote:
 * Andrey Rahmatullin w...@debian.org, 2014-11-22, 12:39:
 --- a/policy.sgml
 +++ b/policy.sgml
 @@ -8892,6 +8892,7 @@ fname () {
would point to file/srv/run/file rather than the intended
target.
  /footnote
 + Symbolic links must not traverse above the root directory.
/p
 
 Seconded.

Seconded. as well.

-- 
  One disk to rule them all, One disk to find them. One disk to bring
  them all and in the darkness grind them. In the Land of Redmond
  where the shadows lie. -- The Silicon Valley Tarot
  Henrique Holschuh


signature.asc
Description: Digital signature

Bug#666726: debian-policy: Clarify if empty control fields are ollowed or not

[Henrique de Moraes Holschuh]

On Mon, 24 Nov 2014, Charles Plessy wrote:
 Le Sat, Nov 22, 2014 at 08:15:03AM -0200, Henrique de Moraes Holschuh a écrit 
 :
  Empty fields in debian/control must be valid in *source* packages.  It is a
  widely used feature of the dpkg-dev suite, and it has been around for a very
  very long time AFAIK.
 
 do you have examples of packages having empty fields in source package control
 files ?  I have not found any.  (In the sense that a field that only contains
 a substitution variable is not considered empty).

They come from empty substitutions, yes.

-- 
  One disk to rule them all, One disk to find them. One disk to bring
  them all and in the darkness grind them. In the Land of Redmond
  where the shadows lie. -- The Silicon Valley Tarot
  Henrique Holschuh


-- 
To UNSUBSCRIBE, email to debian-policy-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/20141123170846.gb18...@khazad-dum.debian.net

Bug#666726: debian-policy: Clarify if empty control fields are ollowed or not

[Henrique de Moraes Holschuh]

On Sun, 23 Nov 2014, Bill Allombert wrote:
 Anyway, this is a second try.
 
 Cheers,

 commit d450ce8f978bad0f3927ea055698b789055dfa3a
 Author: Bill Allombert bill.allomb...@math.u-bordeaux1.fr
 Date:   Sun Nov 23 16:16:21 2014 +0100
 
 Document that empty field values are only allowed in debian/control.
 
 diff --git a/policy.sgml b/policy.sgml
 index 6eac491..55b558f 100644
 --- a/policy.sgml
 +++ b/policy.sgml
 @@ -2556,13 +2556,15 @@ endif
 example compact=compact
  Package: libc6
 /example
 the field name is ttPackage/tt and the field value
 ttlibc6/tt.
   /p
 -
 +p Empty field values are only permitted in source package control 
 files
 +   (filedebian/control/file). Such fields are ignored.
 +/p
   p
 A paragraph must not contain more than one instance of a
 particular field name.
   /p
  
   p
 @@ -2699,12 +2701,13 @@ Package: libc6
 file.dsc/file source control file as part of a source
 archive.  Some fields are folded in filedebian/control/file,
 but not in any other control
 file. These tools are responsible for removing the line
 breaks from such fields when using fields from
 filedebian/control/file to generate other control files.
 +   They are also responsible for discarding empty fields.
   /p
  
   p
 The fields here may contain variable references - their
 values will be substituted by prgndpkg-gencontrol/prgn,
 prgndpkg-genchanges/prgn or prgndpkg-source/prgn

Seconded.

-- 
  One disk to rule them all, One disk to find them. One disk to bring
  them all and in the darkness grind them. In the Land of Redmond
  where the shadows lie. -- The Silicon Valley Tarot
  Henrique Holschuh


signature.asc
Description: Digital signature

Bug#666726: debian-policy: Clarify if empty control fields are ollowed or not

[Henrique de Moraes Holschuh]

On Mon, 24 Nov 2014, Charles Plessy wrote:
 Le Sun, Nov 23, 2014 at 03:08:47PM -0200, Henrique de Moraes Holschuh a écrit 
 :
  On Mon, 24 Nov 2014, Charles Plessy wrote:
   
   do you have examples of packages having empty fields in source package 
   control
   files ?  I have not found any.  (In the sense that a field that only 
   contains
   a substitution variable is not considered empty).
  
  They come from empty substitutions, yes.
 
 Then they are not empty: there is a big difference between Depends: and
 Depends: ${foo}.  I think that it would be very confusing if we would refer
 them as empty.

Well, both are valid.  Can you suggest alternative wording?

For the record, some packages even autogenerate debian/control from a
template during package build.  I can't recall the name of any right now,
though.

 Also, the bug started with a problem where empty means nothing after the
 colon.

In a binary package.

-- 
  One disk to rule them all, One disk to find them. One disk to bring
  them all and in the darkness grind them. In the Land of Redmond
  where the shadows lie. -- The Silicon Valley Tarot
  Henrique Holschuh


-- 
To UNSUBSCRIBE, email to debian-policy-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/20141123181414.gc18...@khazad-dum.debian.net

Bug#770016: Clarify network access for building packages in main

[Henrique de Moraes Holschuh]

On Sun, 23 Nov 2014, Bill Allombert wrote:
 --- a/policy.sgml
 +++ b/policy.sgml
 @@ -1928,12 +1928,16 @@ zope.
 impossible to auto-compile that package and also makes it hard
 for other people to reproduce the same binary package, all
 required targets must be non-interactive.  It also follows that
 any target that these targets depend on must also be
 non-interactive.
   /p
 + p
 +  For packages in the main archive, no required targets
 +  may attempt network access.
 + /p
  
   p
 The targets are as follows:
 taglist
   tagttbuild/tt (required)/tag
   item

This is something we want for multiple reasons, but have we already fixed
all instances of, e.g., validating sgml/xml parsers trying to fetch DTDs or
schemas during documentation build ?  Or other network access attempts that
don't fail a build (and helpfully don't modify it either)?

I worry that we'd might need an intermediate step.

And it is is not just for main, I don't think contrib is supposed to hit the
network during *build*, either.

-- 
  One disk to rule them all, One disk to find them. One disk to bring
  them all and in the darkness grind them. In the Land of Redmond
  where the shadows lie. -- The Silicon Valley Tarot
  Henrique Holschuh


-- 
To UNSUBSCRIBE, email to debian-policy-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/20141123184700.gd18...@khazad-dum.debian.net

Bug#666726: debian-policy: Clarify if empty control fields are ollowed or not

[Henrique de Moraes Holschuh]

On Sun, 23 Nov 2014, Bill Allombert wrote:
 On Mon, Nov 24, 2014 at 02:15:45AM +0900, Charles Plessy wrote:
  Le Sun, Nov 23, 2014 at 03:08:47PM -0200, Henrique de Moraes Holschuh a 
  écrit :
   On Mon, 24 Nov 2014, Charles Plessy wrote:
do you have examples of packages having empty fields in source package 
control
files ?  I have not found any.  (In the sense that a field that only 
contains
a substitution variable is not considered empty).
   
   They come from empty substitutions, yes.
  
  Then they are not empty: there is a big difference between Depends: and
  Depends: ${foo}.  I think that it would be very confusing if we would 
  refer
  them as empty.
  
  Also, the bug started with a problem where empty means nothing after the
  colon.
 
 This bug is mostly to document a check in dak. Are you suggesting the check is
 looking at the debian/control file and reject source packages with empty 
 fields
 ?

That would be broken beyond belief!  debian/control might not even *exist*
after source package unpack when it is autogenerated during the build.

-- 
  One disk to rule them all, One disk to find them. One disk to bring
  them all and in the darkness grind them. In the Land of Redmond
  where the shadows lie. -- The Silicon Valley Tarot
  Henrique Holschuh


-- 
To UNSUBSCRIBE, email to debian-policy-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/20141123204917.ga24...@khazad-dum.debian.net

Bug#666726: debian-policy: Clarify if empty control fields are ollowed or not

[Henrique de Moraes Holschuh]

On Sun, 23 Nov 2014, Jakub Wilk wrote:
 * Henrique de Moraes Holschuh h...@debian.org, 2014-11-23, 18:49:
 This bug is mostly to document a check in dak. Are you
 suggesting the check is looking at the debian/control file and
 reject source packages with empty fields?
 
 That would be broken beyond belief!  debian/control might not even
 *exist* after source package unpack when it is autogenerated
 during the build.
 
 Not quite. dpkg-buildpackage checks for existence of debian/control
 before running debian/rules. So if the source package doesn't ship
 the file, it will FTBFS.

Hmm, I stand corrected.  And I should say I rather prefer a world where
debian/control is there when the source is unpacked, so I am happy to have
been wrong about this :-)

 Moreover, ftp-masters require that certain things in debian/control
 (Build-Depends, package list) do not change during package build:
 https://ftp-master.debian.org/REJECT-FAQ.html

Thanks.

-- 
  One disk to rule them all, One disk to find them. One disk to bring
  them all and in the darkness grind them. In the Land of Redmond
  where the shadows lie. -- The Silicon Valley Tarot
  Henrique Holschuh


-- 
To UNSUBSCRIBE, email to debian-policy-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/20141123225903.gc24...@khazad-dum.debian.net

Bug#666726: debian-policy: Clarify if empty control fields are ollowed or not

[Henrique de Moraes Holschuh]

On Sat, 22 Nov 2014, Charles Plessy wrote:
 Le Fri, Nov 21, 2014 at 10:56:15AM +0100, Bill Allombert a écrit :
  What about automatically generated control files and substvar ?
  e.g.
  Depends: ${misc:Depends}
  where ${misc:Depends} resolve to the empty string ?
  
  Does dpkg-gencontrol take care of that ? In that case we should not lead 
  people
  to believe that the above is incorrect.
 
 a quick check where I added Recommends: ${misc:Recommends} and Suggests: 
 to
 the source control file of the hello package suggests that empty fields
 are removed by default.

Empty fields in debian/control must be valid in *source* packages.  It is a
widely used feature of the dpkg-dev suite, and it has been around for a very
very long time AFAIK.

I don't think they are allowed in binary packages (deb/udeb), though.

I suggest we add explicit documentation in policy to reflect reality: the
package build process must accept empty fields in the debian/control file of
the source package being built, and must remove all empty fields from the
control file of the binary packages the package build process generates.

-- 
  One disk to rule them all, One disk to find them. One disk to bring
  them all and in the darkness grind them. In the Land of Redmond
  where the shadows lie. -- The Silicon Valley Tarot
  Henrique Holschuh


-- 
To UNSUBSCRIBE, email to debian-policy-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/20141122101503.ga19...@khazad-dum.debian.net

Bug#770016: Clarify network access for building packages in main

[Henrique de Moraes Holschuh]

On Tue, 18 Nov 2014, Andrey Rahmatullin wrote:
 On Tue, Nov 18, 2014 at 09:24:15PM +0900, Charles Plessy wrote:
  I guess that it is implicit from the defintion of contrib that follows in 
  2.2.2:
  
The contrib archive area contains supplemental packages intended to work 
  with
the Debian distribution, but which require software outside of the 
  distribution
to either build or function. 
 I have a feeling that software here is too narrow.

Well, contrib is also used when there is a requirement of *data* (be it game
assets or scientific datasets) external to Debian main, not just software.

-- 
  One disk to rule them all, One disk to find them. One disk to bring
  them all and in the darkness grind them. In the Land of Redmond
  where the shadows lie. -- The Silicon Valley Tarot
  Henrique Holschuh


-- 
To UNSUBSCRIBE, email to debian-policy-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/20141118124911.gb21...@khazad-dum.debian.net

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

[Henrique de Moraes Holschuh]

On Sat, 16 Aug 2014, Charles Plessy wrote:
 Le Fri, Aug 15, 2014 at 02:22:33PM -0300, Henrique de Moraes Holschuh a écrit 
 :
   Am 15.08.2014 17:47, schrieb Gerrit Pape:
   That this rule is violated in hundreds of cases [1] clearly shows that
   there is something wrong which needs to be addressed in a more idiomatic
   way.
  
  Maybe update the policy text to match reality?
  
  Any packages depended upon by a higher priority package are, effectively,
  raised to that package's priority.

I did write that we also need text to discourage raising priorities
without asking other interested parties, first.  And that should also
include the maintainer of the package which will get its priority raised.

IMHO, it would be fine if they're treated the same way we do pre-depends,
i.e. ask in d-devel first, only we'd want to add at least debian-boot and
debian-cd and the relevant package maintainers as well.

-- 
  One disk to rule them all, One disk to find them. One disk to bring
  them all and in the darkness grind them. In the Land of Redmond
  where the shadows lie. -- The Silicon Valley Tarot
  Henrique Holschuh


-- 
To UNSUBSCRIBE, email to debian-policy-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/20140816130526.gb22...@khazad-dum.debian.net

Re: Bug#758231: rsyslog: is priority important, depends on packages with priority extra

[Henrique de Moraes Holschuh]

On Fri, 15 Aug 2014, Michael Biebl wrote:
 Am 15.08.2014 17:47, schrieb Gerrit Pape:
  Package: rsyslog
  Version: 8.2.2-3
  Severity: serious
  Justification: Policy 2.5
  
  Hi, the current rsyslog package version in testing is priority important
  and depends on packages with priority extra.  Policy 2.5 states:
  
  Packages must not depend on packages with lower priority values
  (excluding build-time dependencies).

This rule was once really useful when we had tools that could not do
dependency resolution very well by themselves to sort out what needs to go
into d-i images, etc.

I am not sure it is still relevant, though, as the tools are a lot better
now.  This question should be asked in debian-boot@l.d.o, debian-cd@l.d.o,
and maybe even debian-release@l.d.o.

 That this rule is violated in hundreds of cases [1] clearly shows that
 there is something wrong which needs to be addressed in a more idiomatic
 way.

Maybe update the policy text to match reality?

Any packages depended upon by a higher priority package are, effectively,
raised to that package's priority.

That said, AFAIK the current text was also supposed to get people to think
twice before adding new dependencies to high-priority packages, and to get
some external input before they do it.

-- 
  One disk to rule them all, One disk to find them. One disk to bring
  them all and in the darkness grind them. In the Land of Redmond
  where the shadows lie. -- The Silicon Valley Tarot
  Henrique Holschuh


-- 
To UNSUBSCRIBE, email to debian-policy-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/20140815172233.gc2...@khazad-dum.debian.net

Bug#707851: Proposed changes on menu systems

[Henrique de Moraes Holschuh]

On Sat, 25 Jan 2014, Markus Koschany wrote:
 I wanted to clarify that there are also efforts to support both menu
 systems and that the majority of games already integrate both.
 
 https://wiki.debian.org/Games/JessieReleaseGoal
 
 In my opinion the policy should at least mention the Debian menu as an
 alternative menu system, so that all the effort until now was not
 completely wasted. Menu files are easy to write and once written do not
 impose more work for the maintainer. If the Debian menu is not mentioned
 at all in Debian's policy, people will use this as a justification to
 ignore even wishlist bugs for menu files.

Seconded.

-- 
  One disk to rule them all, One disk to find them. One disk to bring
  them all and in the darkness grind them. In the Land of Redmond
  where the shadows lie. -- The Silicon Valley Tarot
  Henrique Holschuh


signature.asc
Description: Digital signature

Is this license acceptable for non-free?

[Henrique de Moraes Holschuh]

** PLEASE CC: ME ON REPLIES **

The new license for AMD microcode updates seems to be quite obnoxious.

Is it acceptable for non-free?

The full license text is reproduced below:


Copyright (C) 2010-2013 Advanced Micro Devices, Inc., All rights reserved.

Permission is hereby granted by Advanced Micro Devices, Inc. (AMD),
free of any license fees, to any person obtaining a copy of this
microcode in binary form (the Software) (You), to install,
reproduce, copy and distribute copies of the Software and to permit
persons to whom the Software is provided to do the same, subject to
the following terms and conditions.  Your use of any portion of the
Software shall constitute Your acceptance of the following terms and
conditions. If You do not agree to the following terms and conditions,
do not use, retain or redistribute any portion of the Software.

If You redistribute this Software, You must reproduce the above
copyright notice and this license with the Software.
Without specific, prior, written permission from AMD, You may not
reference AMD or AMD products in the promotion of any product derived
from or incorporating this Software in any manner that implies that
AMD endorses or has certified such product derived from or
incorporating this Software.

You may not reverse engineer, decompile, or disassemble this Software
or any portion thereof.

THE SOFTWARE IS PROVIDED AS IS WITHOUT ANY EXPRESS OR IMPLIED
WARRANTY OF ANY KIND, INCLUDING BUT NOT LIMITED TO WARRANTIES OF
MERCHANTABILITY, NONINFRINGEMENT, TITLE, FITNESS FOR ANY PARTICULAR
PURPOSE, OR WARRANTIES ARISING FROM CONDUCT, COURSE OF DEALING, OR
USAGE OF TRADE. IN NO EVENT SHALL AMD OR ITS LICENSORS BE LIABLE FOR
ANY DAMAGES WHATSOEVER (INCLUDING, WITHOUT LIMITATION, DAMAGES FOR
LOSS OF PROFITS, BUSINESS INTERRUPTION, OR LOSS OF DATA OR
INFORMATION) ARISING OUT OF AMD'S NEGLIGENCE, GROSS NEGLIGENCE, THE
USE OF OR INABILITY TO USE THE SOFTWARE, EVEN IF AMD HAS BEEN ADVISED
OF THE POSSIBILITY OF SUCH DAMAGES. BECAUSE SOME JURISDICTIONS
PROHIBIT THE EXCLUSION OR LIMITATION OF LIABILITY FOR CONSEQUENTIAL OR
INCIDENTAL DAMAGES OR THE EXCLUSION OF IMPLIED WARRANTIES, THE ABOVE
LIMITATION MAY NOT APPLY TO YOU.

Without limiting the foregoing, the Software may implement third party
technologies for which You must obtain licenses from parties other
than AMD. You agree that AMD has not obtained or conveyed to You, and
that You shall be responsible for obtaining the rights to use and/or
distribute the applicable underlying intellectual property rights
related to the third party technologies. These third party
technologies are not licensed hereunder.

If You use the Software (in whole or in part), You shall adhere to all
applicable U.S., European, and other export laws, including but not
limited to the U.S. Export Administration Regulations (EAR), (15
C.F.R. Sections 730 through 774), and E.U. Council Regulation (EC) No
1334/2000 of 22 June 2000. Further, pursuant to Section 740.6  of the
EAR, You hereby certify that, except pursuant to a license granted by
the United States Department of Commerce Bureau of Industry and
Security or as otherwise permitted pursuant to a License Exception
under the U.S. Export Administration Regulations (EAR), You will not
(1) export, re-export or release to a national of a country in Country
Groups D:1, E:1 or E:2 any restricted technology, software, or source
code You receive hereunder, or (2) export to Country Groups D:1, E:1
or E:2 the direct product of such technology or software, if such
foreign produced direct product is subject to national security
controls as identified on the Commerce Control List (currently found
in Supplement 1 to Part 774 of EAR). For the most current Country
Group listings, or for additional information about the EAR or Your
obligations under those regulations, please refer to the U.S. Bureau
of Industry and Security?s website at ttp://www.bis.doc.gov/.

-- 
  One disk to rule them all, One disk to find them. One disk to bring
  them all and in the darkness grind them. In the Land of Redmond
  where the shadows lie. -- The Silicon Valley Tarot
  Henrique Holschuh


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

Re: Is this license acceptable for non-free?

[Henrique de Moraes Holschuh]

Sorry about this, I sent it to the wrong ML.  Will post to debian-legal.

-- 
  One disk to rule them all, One disk to find them. One disk to bring
  them all and in the darkness grind them. In the Land of Redmond
  where the shadows lie. -- The Silicon Valley Tarot
  Henrique Holschuh


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

Re: What is the use case for Policy §7.6.2 ?

[Henrique de Moraes Holschuh]

On Fri, 09 Nov 2012, Josselin Mouette wrote:
 It looks to me that we should strictly favor the transitional package
 approach instead. Shouldn’t we entirely forbid the
 Provides/Conflicts/Replaces combination way of handling upgrades, except
 for virtual packages?

And instantly break even further the upgrade path of lots of
already-published packages?  This is the sort of thing that might need a
deployment plan over two stable releases, it is probably better to find a
way to fix apt.

-- 
  One disk to rule them all, One disk to find them. One disk to bring
  them all and in the darkness grind them. In the Land of Redmond
  where the shadows lie. -- The Silicon Valley Tarot
  Henrique Holschuh


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

Re: debian/copyright in case of multiple alternative licences

[Henrique de Moraes Holschuh]

On Sat, 03 Nov 2012, Bart Martens wrote:
 I understand its copyright information and distribution license(s) as
 including all licenses, so that the user can still choose between the
 alternative licenses.  The packager should not choose for the user.

Sometimes we have to.  The source may be distributed with license choices we
cannot use for the binary packages, because of restrictions caused by
linking to libraries, or by the DFSG.

IMO, debian/copyright should reflect the licenses being used to distribute
the binary and source packages *by Debian*.

This is a somewhat uncommon case, though.  And I don't think many of us are
updating GPLv2 or later licenses to GPLv3 in debian/copyright when linking
to something ends up resulting in a GPLv3 application, for example.

-- 
  One disk to rule them all, One disk to find them. One disk to bring
  them all and in the darkness grind them. In the Land of Redmond
  where the shadows lie. -- The Silicon Valley Tarot
  Henrique Holschuh


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

Bug#397939: clean rule behavior underspecified and inconsistent with common practice

[Henrique de Moraes Holschuh]

On Tue, 11 Sep 2012, Jonathan Nieder wrote:
 Bernhard R. Link wrote:
  * Jonathan Nieder jrnie...@gmail.com [120911 05:45]:
  The requirements in policy for
  debian/rules clean are very stringent --- to avoid the
  unrepresentable changes it would be enough to _remove_ the modified
  (regenerated) files, but policy requires undoing everything the build
  target did, or in other words restoring the original files.
 [...]
  It does not do it must undo everything. Undoing everything would be
  impossible (like, how do you revert the timestamps of directories that
  got a newer timestamp because there was a file created and then removed
  in there?).
 
  Policy only speaks about the effects those targets had.
 
  And I think common understanding of this was (at least was in the past)
  that removing files not needed for the build is a simple and effective
  way to undo those effects, as it results in a working dir aquivalent
  for all practical purposes to one where build and binary never ran.
 
 I'm happy to hear that, though I don't see how the wording in policy
 can support it.  Perhaps a simple footnote that mentions that adding
 or modifying files is not allowed but removing them is allowed would
 take care of that distraction, then?

Yes, but as soon as you try that, you will get a bunch of people who
considers that Debian source package trees must at all times work as if it
were an upstream package tree (i.e. not depend on debian/rules targets to
work) to voice in the thread against any non-reversible changes during
build, and the thread will rapidly either die, or degenerate into
dead-horse-beating noise.

Nowadays we could actually do it, in a faint hope that the thread will
actually come to a rough consensus of some sort, and if it doesn't, punt it
to the ctte.  But this is *really* not worth the hassle IMO.

Still, if any of you would like to do it, please wait a bit.  Let's release
Wheezy first.

-- 
  One disk to rule them all, One disk to find them. One disk to bring
  them all and in the darkness grind them. In the Land of Redmond
  where the shadows lie. -- The Silicon Valley Tarot
  Henrique Holschuh


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

Bug#678607: debian-policy: original authors in 12.5 is unclear

[Henrique de Moraes Holschuh]

On Sat, 23 Jun 2012, Jonathan Nieder wrote:
 Russ Allbery wrote:
  Would one list bug-gnu-ut...@gnu.org?  That's the most useful contact
  point (and we have a copyright-format field for that), but it's not in any
  real sense the author.
 
 Sure it is --- it's the contact point for the people who create the
 code that goes into the upstream tarball.

I supposed it is best to call it upstream, instead of original
authors...

IMHO we might want to mandate installing the AUTHORS file when it contains
relevant information.  It is sort of a tribute to those who started the ball
rolling, and part of the giving back expected from downstream and users.

 I suspect the original intent of this piece of policy was to uniquely
 identify where the packaged source came from: I used such-and-such
 tarball, by such-and-such author.  I agree that the wording is a
 little crazy (because ambiguous).

We should clarify it, then...

-- 
  One disk to rule them all, One disk to find them. One disk to bring
  them all and in the darkness grind them. In the Land of Redmond
  where the shadows lie. -- The Silicon Valley Tarot
  Henrique Holschuh



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

Bug#568313: Bug#673301: useless use of dpkg-statoverride

[Henrique de Moraes Holschuh]

On Fri, 01 Jun 2012, Holger Levsen wrote:
  They seem to conclude 2
  things applying on our cases :
  - dpkg-statoverride --list must be used to check if the administrator
  allows dpkg to change permissions on the file. For instance an
  administrator could set an override before the installation and you
  don't want to mess with it.
 
 indeed. So the only way to use dpkg-statoverride in maintainer scripts should 
 be using --list, and then using simple chown/chmod, leaving other uses of 
 dpkg-override to local admins only.

You can insert an override when none is present without trampling the local
admin, but in that case, you might not be able to autofix it quietly later
if you get it wrong or the situation changes.  It is not too bad: if it is
important enough to warrant a statoveride change, asking the user about it
in postinst no matter who set the statoverride is actually safer for
everyone involved.

 Also this can be prevented by shipping with safe permissions (=non 
 setuid/gid) 
 and changing them in postinst

This is quite good enough, actually.  In postinst, don't touch anything if
an statoverride exists (dpkg will have already applied the override), or
chown/chmod it manually when none exists.

When it is about an ephemeral directory (e.g. stuff in /run), you must use
the same logic in the postinst and the initscript (easy)... but I have no
idea how easy it would be, e.g., for native systemd.

-- 
  One disk to rule them all, One disk to find them. One disk to bring
  them all and in the darkness grind them. In the Land of Redmond
  where the shadows lie. -- The Silicon Valley Tarot
  Henrique Holschuh



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

Bug#663762: debian-policy: default for DEB_BUILD_OPTIONS=parallel=N

[Henrique de Moraes Holschuh]

On Sun, 25 Mar 2012, Bill Allombert wrote:
 On Sun, Mar 25, 2012 at 09:18:18AM +1030, Ron wrote:
  On Sat, Mar 17, 2012 at 04:55:19PM -0700, Russ Allbery wrote:
   Jakub Wilk jw...@debian.org writes:
   
How should packages behave if there is no explicit parallel=N in
DEB_BUILD_OPTIONS? I saw two different approaches:
   
1) Behave (roughly) like if parallel=1 was set.
   
2) Be clever and try to guess the right level of parallelism, e.g. by
using getconf _NPROCESSORS_ONLN or parsing /proc/cpuinfo (ugh!).
 
 On an hyperthreaded system, getconf _NPROCESSORS_ONLN return the number of 
 threads
 and not the number of cores, so it is not always what the user want.

IMO, this is best left for the local admin.  Guessing this kind of stuff
right in every arch is a very hard problem, and the safe choice [which
doesn't break any package builds] is to not do a parallel build at all.

For the record: if you ever thought about using crap like getconf
_NPROCESSORS_ONLN for anything, you will probably benefit from looking at
the hwloc and libhwloc* packages.

-- 
  One disk to rule them all, One disk to find them. One disk to bring
  them all and in the darkness grind them. In the Land of Redmond
  where the shadows lie. -- The Silicon Valley Tarot
  Henrique Holschuh



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

Bug#660193: developers-reference: please suggest debian/rules target name for preparing source

[Henrique de Moraes Holschuh]

On Sat, 17 Mar 2012, Carsten Hey wrote:
  prebuild:
test ! -d wafadmin
./waf --help /dev/null
mv .waf-*/wafadmin .
rm -f .waf-*/t.bz2
rmdir .waf-*
sed -n -i -e '1,/^#==$$/ p' -e '/^#==$$/,$$ p' waf

Maybe this would work?

prebuild: prebuild-stamp
(do interesting stuff here)
echo stamp  prebuild-stamp

clean:  prebuild
...

get-source:
rm -f prebuild-stamp
...

dpkg-source will carry prebuild-stamp in the diff, and since it updates
the timestamp of anything it patches, and clean is a phony target, it
should not decide that prebuild is outdated and needs a rebuild.

If it does run, guarding the relevant shell stuff with 
if ! [ -e prebuild-stamp ]
should be obvious enough and easier to understand than the other
techniques to avoid timestamp skews.

 have been 'extract-waf'.  All this bug report is about is that in such
 cases maintainers should consider using prebuild as the target's name
 instead of inventing new ones.

To me it looks like clean should be able to do this job without any
changes to dpkg-source and friends.

-- 
  One disk to rule them all, One disk to find them. One disk to bring
  them all and in the darkness grind them. In the Land of Redmond
  where the shadows lie. -- The Silicon Valley Tarot
  Henrique Holschuh



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

Re: [proposal] remove the requirement to compress documentation

[Henrique de Moraes Holschuh]

On Mon, 20 Feb 2012, Russ Allbery wrote:
 Wouter Verhelst wou...@debian.org writes:
  To be a bit more specific on this: such a tool could be implemented
  fairly trivially with a dpkg trigger. Just register a trigger that
  triggers on any file under /usr/share/doc, and have it call gzip --best
  on the files it is called with.
 
 It would be a good idea for removing a package to remove its
 documentation.

If we're going that way, can we please do it the right way for once, and
instead of any hideous hacks from the underworld pits, implement a way to
assign [unknown to dpkg] files to an already installed package?

-- 
  One disk to rule them all, One disk to find them. One disk to bring
  them all and in the darkness grind them. In the Land of Redmond
  where the shadows lie. -- The Silicon Valley Tarot
  Henrique Holschuh


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

Bug#660193: developers-reference: please suggest debian/rules target name for preparing source

[Henrique de Moraes Holschuh]

On Fri, 17 Feb 2012, Carsten Hey wrote:
   The package debianutils already uses such a target and uses 'prebuild'
   as name.  The developers reference could adopt this name.
 
  How would this relate to Policy 4.14 - debian/README.source?
 
 In general, debian/README.source does not contain information how to
 run, for example, autoconf and friends to convert a clean VCS checkout
 into a source tree that can be built using dpkg-buildpackage (there are
 packages that require this).

The truth is that the tree is prepared by the clean target.  It's function
is, *in practice*, to reset the tree for a build, including the first build.
I suspect a lot of packages will malfunction (fail to build or produce
subtly defective builds) if you do not do this.

The clean target can easily arrange for destructive changes to
non-autogenerated source (i.e. those that cannot be redone on every build)
to happen only once.

 The section's first sentence reads:
 | If running dpkg-source -x on a source package doesn't produce ...,
 | creating a debian/README.source documentation file is recommended.
 
 Mentioning such a target in debian/README.source seems to be a good
 thing, but it does not match the current definition in the policy.  If
 this gets added to the developer's reference, suggesting to add an
 according note to debian/README.source seems to be reasonable, despite
 not perfectly fitting a definition in the policy.  But if it ends up in
 the policy (either in section 4.14 - debian/README.source or section
 4.9 - debian/rules and using the words may or optional), I assume
 it would be hard to find a wording that justifies mentioning this target
 in debian/README.source, but not explaining how to run autoconf manually
 to be able to build the package.
 
 The intention of this bug report is to unify the name of a target that
 might be used more often soon, and it is not sufficient to reach this
 goal if we rely on package maintainers to document the target they use
 in debian/README.source.

I have nothing against separating the clean target into a prebuild target
(that will have to run when the clean target is invoked for the first time
at the very least).  But I do wonder how useful this separate prebuild
target would really be?   You still need to run the clean target anyway to
do anything useful...

-- 
  One disk to rule them all, One disk to find them. One disk to bring
  them all and in the darkness grind them. In the Land of Redmond
  where the shadows lie. -- The Silicon Valley Tarot
  Henrique Holschuh



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

Bug#620870: debian-policy: Please add /run as FHS exception

[Henrique de Moraes Holschuh]

On Wed, 15 Jun 2011, Michael Biebl wrote:
 At the current state, I'm not for adding /run/shm to debian-policy.
 If we can get wider acceptance of this feature (cross-distro), then my 
 position
 on this might change. Atm this looks like a Debian-only feature with no real
 use-case why we need that.

Hmm?  The only acceptable access to /dev/shm (and therefore /run/shm) by
normal applications is through the SYSV shmem API.  Wider distro acceptance
is a non-issue.

That doesn't mean I think it is a good idea to move it to /run, I think it
is a bad idea.

IMHO the only interesting use-case for /run/shm seems to be breaking for
good any crap that still abuses /dev/shm, which is not nearly enough a good
reason to mess with it.  I consider storing shm data inside the /run
filesystem to be a misfeature (as opposed to having it as a separete tmpfs),
so merging it with /run is exactly what I'd not like to see happening.

-- 
  One disk to rule them all, One disk to find them. One disk to bring
  them all and in the darkness grind them. In the Land of Redmond
  where the shadows lie. -- The Silicon Valley Tarot
  Henrique Holschuh



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

Bug#646235: developers-reference: Please keep this package up-to-date in stable

[Henrique de Moraes Holschuh]

Package: developers-reference
Version: 3.4.4
Severity: wishlist

Updates to developers-reference have no regression risk, and unlike
debian-policy, whatever it contained at the time of a stable release is
of little relevance: one really should base his work and interaction
with the Debian project on the latest version of developers-reference,
not whatever was current when stable was released.

Please consider updating the package on stable through
stable-proposed-updates and point releases.

-- System Information:
Debian Release: 6.0.3
  APT prefers proposed-updates
  APT policy: (990, 'proposed-updates'), (990, 'stable'), (500, 
'stable-updates')
Architecture: amd64 (x86_64)

Kernel: Linux 3.0.7+ (SMP w/8 CPU cores)
Locale: LANG=pt_BR.UTF-8, LC_CTYPE=pt_BR.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash

developers-reference depends on no packages.

Versions of packages developers-reference recommends:
ii  debian-policy 3.9.1.0Debian Policy Manual and related d

Versions of packages developers-reference suggests:
ii  doc-base  0.9.5  utilities to manage online documen

-- no debconf information



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

Bug#621833: What about userdel?

[Henrique de Moraes Holschuh]

On Sun, 29 May 2011, Nicholas Bamber wrote:
 I am managing a package that does 'userdel' in a purge. It removes the
 home directory as that contains config files. I am a bit concerned about

I've seen that cause data loss.  You must make sure the homedir is
exactly as you set it when you created the system user.  If it isn't,
abort.

If you want to know how bad it can be, we've had once packages that had
/ set as the home dir of system users they created.

-- 
  One disk to rule them all, One disk to find them. One disk to bring
  them all and in the darkness grind them. In the Land of Redmond
  where the shadows lie. -- The Silicon Valley Tarot
  Henrique Holschuh



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

Re: [PATCH] Specify policy for use of revision IDs in version numbers

[Henrique de Moraes Holschuh]

On Sun, 01 May 2011, Bill Allombert wrote:
 On Sat, Apr 30, 2011 at 09:00:14PM -0700, Russ Allbery wrote:
  So the reason for imposing a length restriction on version numbers in
  particular is due to the UI display of aptitude?  I'm a bit dubious that
  this is a good justification for a Policy rule.  dpkg -l has truncated
  version numbers for forever at 14 characters, and I don't recall this
  being a major issue in the past.  The thing that started off this thread,
  I thought, was the constraint on file name length in ISO images, which is
  the total length and doesn't impose a constraint specifically on the
  version.
 
 Also there are no technical requirement for packages filenames in ISO images 
 to be
 canonical packages names. Packages filename can be mangled to fit the medium, 
 there
 is a program 'dpkg-name' to recover the canonical packages name. This requires
 the same mangling to be applied to the filenames in the Packages files, but 
 this 
 not an issue since the Packages file is in the same medium.

That could work, but I can certainly imagine non-uniqueness causing
problems.  .debs from inside a CD/DVD have this nasty tendency to show up in
the most strange places.  They don't stay put in that DVD/CD and get
destroyed at the next point release.

And it would cause problems for some tools, too.  Assuming such package name
reduction can be made to work safely, the question is: what would be the
better solution in the long term?

-- 
  One disk to rule them all, One disk to find them. One disk to bring
  them all and in the darkness grind them. In the Land of Redmond
  where the shadows lie. -- The Silicon Valley Tarot
  Henrique Holschuh


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

Re: [PATCH] Specify policy for use of revision IDs in version numbers

[Henrique de Moraes Holschuh]

On Sat, 30 Apr 2011, Russ Allbery wrote:
 Osamu Aoki os...@debian.org writes:
  This is another topic.  I do not think everyone agreed yet to a
  particular set of numbers.  The more I looked into this issue, I think
  followings are the possible numbers:

No, but I'd like to have a MUST rule that says that you MUST specify the
full repository and commit identification data in the 'new upstream'
changelog entry when you package out of a VCS repository instead of a
public release tarball.  Maybe with examples for git, svn, mercurial and
bzr on the grounds that they're the most used ones right now and it
should get the idea across nicely).

   * package file name for normal uploads: 90 characters (must)
 - rationale: UCS-2 requirement etc.
 - current longest is 76 chars.
 - this number is ready for policy.
 
   * package name length =40 (must:   99.8% qualifies)
   * package name length =30 (should: 98.3% qualifies)
 - aptitude field length default
 
  normal version length withour special extension such as +nmu? +b? ...
  should be:
 
   * version length =30 (must:   99.9% qualifies)
=20 (must:   99.0% qualifies) possible alternative.
   * version length =15 (should: 95.3% qualifies)
 - aptitude field length default can be 15 as BTS #624542 for 80 char/line
 - 10 is too short since only 83.8% qualifies.
 
 So the reason for imposing a length restriction on version numbers in
 particular is due to the UI display of aptitude?  I'm a bit dubious that

No, it is because package file name + version string + other stuff
(arch, .deb/.udeb/?, _ field separators...) must not exceed 90
characters...  who cares if the tool won't show 10 chars by default?
Request a new default for the tool, or fix it in your local config if it
bothers you (I had to configure aptitute to show 20 chars plus suite to
suit my local needs, for example).

AND since you need to vary the arch and version strings outside of
maintainer control (new ports, NMUs, binNMUs, security updates,
backports...) you must have some space reserved for that.

When we arrive at the final numbers, we really should ALSO mandate the
maximum length of arch names and also change the p-u and security
updates versioning to be bounded and shorter (i.e. use a short pattern
with the debian release number that is other-distros-friendly, not its
codename), etc.

Otherwise it is a moot effort.

  If we do this, we also need to move 3.2.1 to developers-reference.
 
 I don't agree.  That section is there because of a technical failure
 caused by poorly-chosen date-based version numbers.  As discussed in the
 long thread in debian-devel, the use of hashes is as a supplement to a
 sequential version, to identify a precise commit reliably.

When we mandate anything re. version numbers, it better be in policy as
SHOULD or MUST, yes.

 I would support adding a statement to Policy akin to the advice in 3.2.1
 pointing out that hashes don't sort reasonably and hence can't be relied
 upon to order the version number, and that the part of the version prior
 to the hash has to establish a unique sort.  (That's a bad way of phrasing
 it, of course.)  But just banning them doesn't feel justified to me.

I advise that the supporters of VCS-commit-hashes in version strings to
help write a footnote in policy (and maybe a full text in d-reference)
about how to properly deal with variable-length commit ids used as
version, when they exceed the maximum size.  It requires some thought to
do it right in a way that it won't cause issues for any future commits.

Since we had to do it for the much easier to understand date-style
safe patterns for version strings because people were screwing it up in
practice and epochs were needed to repair the damage, we better do it
for VCS commit ids as well.  There is no reason to believe history won't
repeat itself.

-- 
  One disk to rule them all, One disk to find them. One disk to bring
  them all and in the darkness grind them. In the Land of Redmond
  where the shadows lie. -- The Silicon Valley Tarot
  Henrique Holschuh


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

Bug#624586: Bug#618885: sasl2-bin: unowned files after purge (policy 6.8, 10.8)

[Henrique de Moraes Holschuh]

On Sat, 30 Apr 2011, Russ Allbery wrote:
 Steve Langasek vor...@debian.org writes:
  I don't think that /etc/shadow qualifies as a configuration file,
  either; I would call it variable state information (→ /var/lib), but
  it lives in /etc because a) it has to be on the root filesystem, b)
  that's where it's always been so moving it somewhere else would be more
  trouble than it's worth.
 
  For other packages like sasl (or, say, samba, which stores all its
  authentication databases in /var/lib/samba in Debian), neither of these
  arguments holds AFAICS.
 
 Actually, now that I look at the sasldb2 file, I think you're right.  I
 was under the mistaken impression that it was a file that administrators
 were expected to edit with a text editor, but it's actually a binary file
 format that's manipulated only via utilities.  You're right; this probably
 doesn't belong in /etc at all and should instead be somewhere in /var.

It has the same semanthics as /etc/shadow.

-- 
  One disk to rule them all, One disk to find them. One disk to bring
  them all and in the darkness grind them. In the Land of Redmond
  where the shadows lie. -- The Silicon Valley Tarot
  Henrique Holschuh



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

Bug#624586: Bug#618885: sasl2-bin: unowned files after purge (policy 6.8, 10.8)

[Henrique de Moraes Holschuh]

On Sun, 01 May 2011, Henrique de Moraes Holschuh wrote:
 On Sat, 30 Apr 2011, Russ Allbery wrote:
  Steve Langasek vor...@debian.org writes:
   I don't think that /etc/shadow qualifies as a configuration file,
   either; I would call it variable state information (→ /var/lib), but
   it lives in /etc because a) it has to be on the root filesystem, b)
   that's where it's always been so moving it somewhere else would be more
   trouble than it's worth.
  
   For other packages like sasl (or, say, samba, which stores all its
   authentication databases in /var/lib/samba in Debian), neither of these
   arguments holds AFAICS.
  
  Actually, now that I look at the sasldb2 file, I think you're right.  I
  was under the mistaken impression that it was a file that administrators
  were expected to edit with a text editor, but it's actually a binary file
  format that's manipulated only via utilities.  You're right; this probably
  doesn't belong in /etc at all and should instead be somewhere in /var.
 
 It has the same semanthics as /etc/shadow.

Bah, just noticed the semanthics are broken because we have the libs
outside of / anyway, so if anyone tried to use it for important stuff,
it is already broken.

We could purge it, yes, provided it is optional and we ask about it.  It
needs also to default to NO.  It has to be fool-proof on every possible
fucked up scenario, and in some of them an admin saying no! is the
only thing that will save him from losing the authentication information
(passwords) for his users.

That said, relocating it to outside of /etc is a Major Bad Idea, and I
very strongly recommend against it.  Local configuration to move it
somewhere else is already provided, but you just have extreme amount of
application documentation and even certification tests that want it in
/etc/sasldb2.

-- 
  One disk to rule them all, One disk to find them. One disk to bring
  them all and in the darkness grind them. In the Land of Redmond
  where the shadows lie. -- The Silicon Valley Tarot
  Henrique Holschuh



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

Bug#587377: debian-policy: Decide on arbitrary file/path names limit

[Henrique de Moraes Holschuh]

On Wed, 02 Mar 2011, Sean Finney wrote:
 Having a warning in lintian for arbitrarily long (perhaps = 256)
 filenames is totally reasonable i'd say, but there's no reason to

Most (all?) filesystems commonly used in Debian systems will limit you to
somewhere close to 254 characters per filename (paths can be longer).

Do not get paths and filenames confused.  Filenames go in the inode and
their lenght is limited by the filesystem.  Path length is limited by the
applications, libc, and (maybe) the kernel.

PATH_MAX is 4096, go anywhere close to that, and a LOT of applications will
give you real grief.

Policy should at least mention this.

-- 
  One disk to rule them all, One disk to find them. One disk to bring
  them all and in the darkness grind them. In the Land of Redmond
  where the shadows lie. -- The Silicon Valley Tarot
  Henrique Holschuh



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

Bug#604990: clarify man page dates policy

[Henrique de Moraes Holschuh]

On Fri, 26 Nov 2010, jida...@jidanni.org wrote:
 The Debian Policy Manual should state what the preferred date on manual
 pages should be, or wishes upstream would make it.

There is no need.  This is documented in man-pages(7).  It is the date the
manpage was last revised.

 Also mention if Debian maintainers should tamper with upstreams' date, or only
 maybe when they add things to the man page.

Maintainer's discretion should be good enough.  IMO, one should update it
when one changes anything non-minor (i.e. don't bother if it is a typo fix),
but as long as the changes are sent upstream, it doesn't matter much.

 By 'dates' I am talking about the
 $ man -w cat|xargs zcat|sed 2!d
 .TH CAT 1 April 2010 GNU coreutils 8.5 User Commands
 line. Which brings up another item to mention: just month and year OK,
 or must add date?

As long as it is not xx/yy/zz or xx/yy/.

Prose text format in the same language as the manpage is good.  ISO format
(-MM-DD) is good.  Japanese format is acceptable (/MM/DD).  Anything
else will be confusing.  And personal discretion is good enough for the
decision whether one should bother with days or not.

-- 
  One disk to rule them all, One disk to find them. One disk to bring
  them all and in the darkness grind them. In the Land of Redmond
  where the shadows lie. -- The Silicon Valley Tarot
  Henrique Holschuh



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

Bug#491318: init scripts should support start/stop/restart/force-reload - why not must?

[Henrique de Moraes Holschuh]

On Fri, 11 Sep 2009, Manoj Srivastava wrote:
 Looking at the bug report, it seems like we agree that the
  current policy is correct, and the should should not be changed to a
  must?  In that case, can we just close this report?

Alternatively, the proposal should be clarified to mention that it is
optional for system startup scripts (runlevel S), but mandatory for everyone
else.

Daemon and regular service initscripts really ought to implement all
actions, and do so *sensibly*.

-- 
  One disk to rule them all, One disk to find them. One disk to bring
  them all and in the darkness grind them. In the Land of Redmond
  where the shadows lie. -- The Silicon Valley Tarot
  Henrique Holschuh



-- 
To UNSUBSCRIBE, email to debian-policy-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

Bug#513955: [Pkg-sysvinit-devel] Bug#339955: Bug#513955: debian-policy: do not require /etc/init.d/*.sh scripts to be sourced

[Henrique de Moraes Holschuh]

On Fri, 13 Feb 2009, Russ Allbery wrote:
 I went to write the patch for this, but I paused when I saw that the other
 part of this sentence (explicitly running such scripts with sh at other
 run levels) is implemented.  The current /etc/init.d/rc runs the script
 directly if it doesn't end in .sh but runs it with sh if it does.
 
 At least on my system, all of the scripts ending in .sh have a proper #!
 line and are executable, so this wouldn't make any difference there, but I
 wanted to double-check first before also removing that since it appears to
 be implemented.

Non-executable shell initscripts are NOT supported.  While rc might handle
them, invoke-rc.d will refuse to run them, and it also breaks the
well-understood and standard call /etc/init.d/initscript action
directly which everything under the sun expects to work.

It is something left over from the ancient past that we can and should get
rid of.  At most, it deserves a note on the NEWS.Debian file, if that much.

-- 
  One disk to rule them all, One disk to find them. One disk to bring
  them all and in the darkness grind them. In the Land of Redmond
  where the shadows lie. -- The Silicon Valley Tarot
  Henrique Holschuh



-- 
To UNSUBSCRIBE, email to debian-policy-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

Re: Clarify what sensible behaviour is for init scripts

[Henrique de Moraes Holschuh]

On Fri, 04 Jul 2008, Raphael Hertzog wrote:
 Here's a try (against current master branch):
 diff --git a/policy.sgml b/policy.sgml
 index c9bd84f..772afce 100644
 --- a/policy.sgml
 +++ b/policy.sgml
 @@ -5946,9 +5946,11 @@ rmdir /usr/local/share/emacs 2/dev/null || true
   The fileinit.d/file scripts must ensure that they will
   behave sensibly if invoked with ttstart/tt when the
   service is already running, or with ttstop/tt when it
 - isn't, and that they don't kill unfortunately-named user
 + isn't (in particular, they should not exit with a non-zero
 +error code), and that they don't kill unfortunately-named user
   processes.  The best way to achieve this is usually to use
 - prgnstart-stop-daemon/prgn.
 + prgnstart-stop-daemon/prgn and its tt--oknodo/tt
 +option.
 /p
  
 p

Seconded.  It is unfortunate that we need such explanations for the obvious,
but we certainly *do* need them.

-- 
  One disk to rule them all, One disk to find them. One disk to bring
  them all and in the darkness grind them. In the Land of Redmond
  where the shadows lie. -- The Silicon Valley Tarot
  Henrique Holschuh


signature.asc
Description: Digital signature

Bug#397939: Lintian: outdated-autotools-helper-file

[Henrique de Moraes Holschuh]

On Mon, 11 Feb 2008, Kapil Hari Paranjape wrote:
 Note that if the upstream's auto-generated files are deleted during
 the clean target, then the source *must* be re-packaged to avoid
 needless clutter in the .diff.gz which is of a negative nature.

Not so.  Deletions are ignored.  Ever tried it?

-- 
  One disk to rule them all, One disk to find them. One disk to bring
  them all and in the darkness grind them. In the Land of Redmond
  where the shadows lie. -- The Silicon Valley Tarot
  Henrique Holschuh



-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]

Re: deluser on purge (was: Piuparts testing status update)

[Henrique de Moraes Holschuh]

On Tue, 12 Dec 2006, Michelle Konzack wrote:
 Am 2006-11-27 13:02:18, schrieb Michael Stone:
  On Mon, Nov 27, 2006 at 05:33:25PM +0100, Michelle Konzack wrote:
  And HOW can I get UID's  =65536 to work?
  
  I have already tried it in my /etc/passwd and
  /etc/group but it gives tonns of errors.
  
  Any hints?
  
  Hint: you need to be more specific about the problems you're having.
 
 I have used addgroup to create a group foo with GID 10 and
 adduser to create a user bar with UID 10 in group foo.
 
 I can start the xserver but now several programs complain about
 illegal GID/UID.  Same for courier-mta and courier-imap using
 authpam

getent passwd foo and getent group foo works, right?  If it does, then file
bugs on the broken crap^H^H^H^Happlications.

Debian is supposed to support 31-bit user ids.  Anything that does not is
very broken.  I don't think it is a release goal or anything, but still...

-- 
  One disk to rule them all, One disk to find them. One disk to bring
  them all and in the darkness grind them. In the Land of Redmond
  where the shadows lie. -- The Silicon Valley Tarot
  Henrique Holschuh


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]

Re: How thorough must the clean target be?

[Henrique de Moraes Holschuh]

On Thu, 05 Oct 2006, Bill Allombert wrote:
 \usepackage[shameless]{plug}
 \begin{plug}
 I have proposed a (IMVHO) better solution to the
 config.sub/config.guess problem see
 http://lists.debian.org/debian-science/2006/03/msg00038.html
 \end{plug}

You know, I'd have appreciated getting that email filed as a bug against
autotools-dev instead of finding about it in this thread.

It is a good idea, I will add it to autotools-dev.

 The only unclear issues is files that exist in the tarball but get
 removed in the clean target. However since dpkg-buildpackage default
 to run debian/rules clean prior to build the package, one might consider 
 to limit the policy requirement to that case:
 
 1 dpkg-source -x foo.dsc  cd foo-*
 2 debian/rules clean
 3 debian/rules binary
 4 debian/rules clean
 
 We would then require that the tree after 4 must be indentical to the
 tree after 2.

Seems *very* good.  Asking for the tree after 4 being the same as the tree
before 2 is not useful to Debian packages at all, and it *is* a hassle that
requires often more expensive build strategies.

I'd second a proposal for the tree after 4 must be indentical to the tree
after 2.

-- 
  One disk to rule them all, One disk to find them. One disk to bring
  them all and in the darkness grind them. In the Land of Redmond
  where the shadows lie. -- The Silicon Valley Tarot
  Henrique Holschuh


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]

Re: binNMU safe and ${binary:Version} or ${source:Version}

[Henrique de Moraes Holschuh]

On Thu, 14 Sep 2006, Steve Langasek wrote:
  The BIG problem is how to get the next-version. Say you have version
  1.2-3. A binNMU would be 1.2-3+b1, a security release would be
  1.2-3etch1 (unless there was a binNMU).
 
 In the Great Scheme, these were supposed to become 1.2-3+etch1 instead of
 1.2-3etch1 so that security NMUs would sort higher than binNMUs...

And they didn't because?

-- 
  One disk to rule them all, One disk to find them. One disk to bring
  them all and in the darkness grind them. In the Land of Redmond
  where the shadows lie. -- The Silicon Valley Tarot
  Henrique Holschuh


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]

Re: dak now supports ~ in version numbers

[Henrique de Moraes Holschuh]

On Wed, 09 Aug 2006, sean finney wrote:
   Thanks to the work of our DPL Anthony aj Towns (and all the other
   people who have worked on this without my knowledge), I am happy to
   announce that dak, our archive management software, finally supports
   the use of the tilde ('~') in version numbers.
  
  Should we really start using this feature even though it violates
  section 5.6.12 of the Policy?
 
 i'd say we should update the policy document.

Policy documents reality, so if now the reality is that ~ is supported and
its use is encouraged, then yes, policy should be changed ASAP.

-- 
  One disk to rule them all, One disk to find them. One disk to bring
  them all and in the darkness grind them. In the Land of Redmond
  where the shadows lie. -- The Silicon Valley Tarot
  Henrique Holschuh


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]

Re: dak now supports ~ in version numbers

[Henrique de Moraes Holschuh]

On Wed, 09 Aug 2006, Manoj Srivastava wrote:
  Policy documents reality, so if now the reality is that ~ is
  supported and its use is encouraged, then yes, policy should be
  changed ASAP.
 
 No. Policy documents what is correct, not just any old broken
  thing that is currently being done (not that that is the case here).

Sort of.  Refer to update-rc.d, which as currently implemented in Debian AND
described in policy is at the very least an old broken thing that is
currently being done.

 In this case, ~ provides a mechanism to easily package
  pre-release versions, so it is a good thing, it has been in place for
  a long time, the semantics are fairly well set, it has been tested
  across the whole suite of packaging tools, so yes, now  policy should
  document it.

That was the intended spirit of my reply, which I obviously failed to convey
properly.

-- 
  One disk to rule them all, One disk to find them. One disk to bring
  them all and in the darkness grind them. In the Land of Redmond
  where the shadows lie. -- The Silicon Valley Tarot
  Henrique Holschuh


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]

Bug#152955: debian-policy: Clarify force-reload, be LSB-compliant in doing so.

[Henrique de Moraes Holschuh]

On Mon, 10 Jul 2006, Sven Mueller wrote:
 I think we need something like a policy to be, i.e. some document
 which shows which changes _should_ go into the policy document as soon
 as packages are fixed accordingly. Something that results in an

We can have a ongoing tasks page in the wiki, and document where that page
is properly (i.e. at least an email to d-d-a).

That said, you are encouraged to propose a policy change that uses may,
with a footnote that specifies that it will become a should and must when
the goals of x% of packages have been met (I suggest 80% and 98% for the
should and must thresholds).  This has been done before, and it works.

 and still not in policy. The reason is simple: Many maintainers don't
 care to implement upcoming policy changes until they really are in policy.

True, and AFAIK the usual way to fix this is do a patch run, followed by a
not-so-friendly prodding for the patch acceptance, and then a NMU to delayed
run.  It takes a few months for non-invasive changes, but it is not too
painful.  You end up with enough packages fixed to bump policy to a should
without much resistence, and after a few months, another patch run which can
be a lot more forceful will allow it to be brought to a must.

 1) Implement force-reload as a restart alias if reload is not
available and violate LSB (which, according to the RMs means an RC
bug).

Did you specifically ask the RM if this *particular* violation of the LSB
is RC?  If you didn't, please clarify it with them.

 2) Implement force-reload as a conditional restart alias only
executed when the service is already running. This violates current
policy wording and is therefor also an RC bug.

It is also non-trivial to implement.  already running is not always easy
to detect, and most initscripts are really just crap and don't even do the
start-stop-daemon dance properly.

Usually, if you are going to implement any such thing, it would be good to
implement status while at it.

One of the reasons I would get behind a massive workforce to switch to runit
(provided we *still* keep init.d scripts -- they will often be little more
than generic calls into runit helpers and a base initscript shell library
anyway) is that we'd fix all initscripts and maintainers would not have an
excuse to write bad ones anymore because it would be simpler to just do it
right (and runit makes it MUCH easier to track running state properly).

 At the very least, I would suggest the following wording of the
 force-reload description:
 
 
 tagttforce-reload/tt/tag
 itemcause the configuration to be reloaded if the service supports
 this. If it doesn't support reloading, restart the service. Note that
 the service should not get started if it wasn't already running./item
 

I can second such a change.

 After all, even if policy can't _mandate_ (must, required) the wanted
 behaviour, it should not encourage behaviour that is supposed to get RC
 buggy at some point in time.

That I agree with completely.

-- 
  One disk to rule them all, One disk to find them. One disk to bring
  them all and in the darkness grind them. In the Land of Redmond
  where the shadows lie. -- The Silicon Valley Tarot
  Henrique Holschuh


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]

Re: Bug#370471: use of invoke-rc.d $PACKAGE stop || exit $? in prerm scripts

[Henrique de Moraes Holschuh]

On Mon, 26 Jun 2006, Gerrit Pape wrote:
 Instead of writing their pid to a file, daemons could maintain a fifo
 and read (one-byte) commands from there; if there's no reader on the
 fifo, the daemon isn't running and nothing bad happens.

Agreed.

 Or better yet, instead of duplicating such code in each and every
 daemon, as already done for fork/exec, detach from terminal, cleanup
 filedescriptors, setsid(), write pid file, remove all that duplicated
 code, and have the service daemon run under a parent supervisor process
 which maintains such a fifo.  The parent process always already knows
 the pid to send signals to, and knows about a service daemon terminating
 through SIGCHLD.

Nothing against it, but it is sort of a war uphill (one Debian can actually
take, I suppose.  It is technically superior and it does offer a truckload
of advantages) to get all services to run in foreground mode *while* making
sure this means they behave exactly as they would be in background mode.

At least this approach makes everything from babysiting services and getting
their status, to parallel-execution and logging MUCH easier to implement.

Gerrit, I don't recall it completely, do your system provide a generalized
*per service* supervisor for initscripts, or a single master hipervisor that
is parent to all services?

Any chances of providing an sysv-init-like interface for this (I don't see
why it would be technically impossible to do it -- it is a bit more complex,
though), or do we have to insist on changing to a new initscript system type
completely?

-- 
  One disk to rule them all, One disk to find them. One disk to bring
  them all and in the darkness grind them. In the Land of Redmond
  where the shadows lie. -- The Silicon Valley Tarot
  Henrique Holschuh


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]

Re: Bug#370471: use of invoke-rc.d $PACKAGE stop || exit $? in prerm scripts

[Henrique de Moraes Holschuh]

On Wed, 21 Jun 2006, Gerrit Pape wrote:
 On Mon, Jun 05, 2006 at 03:36:30PM +0300, Lars Wirzenius wrote:
  The policy manual says (9.3.2 Writing the scripts):
  
  The init.d scripts should ensure that they will behave sensibly
  if invoked with start when the service is already running, or
  with stop when it isn't, and that they don't kill
  unfortunately-named user processes.
  
  Would it be acceptable to change this to say must ensure?
 
 You might call this nitpicking, but with the current Debian init scripts
 using start-stop-daemon, this isn't really achievable.  See the
 start-stop-daemon(8) man page:

You should use start-stop-daemon with both --name AND --pidfile together
(never use --exec unless you REALLY know you will always stop the daemon
before it changes on disk) in an initscript.  That changes start-stop-daemon
into a homing killall.

 And relying on a pidfile also doesn't guarantee that ``they don't kill
 unfortunately-named user processes'', but actually can cause exactly
 that, AFAICT.

Nothing is 100% foolproof, of course.  --exec is damn good at homing exactly
on what you want, but you'd need to know the inode of the already unlinked
executable if it is restarted after being upgraded.  Hints are welcome, so
far we got far more breakage from --exec than any benefits.

A pidfile + process name check is actually quite good enough in practice,
IME.  I have never seen it misfire in my life other than in fabricated
scenarios.

Of course, bird-brain interpretors like python in which it is hell to change
the process name and on top of it insist on running all scripts/programs
with the interpretor name sort of widen the error window a lot more than
necessary.  Hints on how to fix that are very welcome, I have at least one
package which would benefit from this.

-- 
  One disk to rule them all, One disk to find them. One disk to bring
  them all and in the darkness grind them. In the Land of Redmond
  where the shadows lie. -- The Silicon Valley Tarot
  Henrique Holschuh


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]

Bug#370471: use of invoke-rc.d $PACKAGE stop || exit $? in prerm scripts

[Henrique de Moraes Holschuh]

On Mon, 05 Jun 2006, Lars Wirzenius wrote:
 The policy manual says (9.3.2 Writing the scripts):
 
 The init.d scripts should ensure that they will behave sensibly
 if invoked with start when the service is already running, or
 with stop when it isn't, and that they don't kill
 unfortunately-named user processes.
 
 Would it be acceptable to change this to say must ensure?

Yes.  Not only that, behaves sensibly is to be defined as starting an
already started service is not an error and must return status 0, and stopping
an already stopped service is not an error and must return status 0 as a
minimal implementation :)

-- 
  One disk to rule them all, One disk to find them. One disk to bring
  them all and in the darkness grind them. In the Land of Redmond
  where the shadows lie. -- The Silicon Valley Tarot
  Henrique Holschuh


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]

Re: Make use of invoke-rc.d, if available, mandatory?

[Henrique de Moraes Holschuh]

On Mon, 03 Apr 2006, Lars Wirzenius wrote:
 Current policy states in section 9.3.3.2 (Running initscripts) the
 following: The use of invoke-rc.d to invoke the /etc/init.d/*
 initscripts is strongly recommended[51], instead of calling them
 directly. 
 
 Footnote 51 further says: In the future, the use of invoke-rc.d to
 invoke initscripts shall be made mandatory. Maintainers are advised to
 switch to invoke-rc.d as soon as possible.
 
 I propose that the future has arrived.

I second this one as a proud father :-)

-- 
  One disk to rule them all, One disk to find them. One disk to bring
  them all and in the darkness grind them. In the Land of Redmond
  where the shadows lie. -- The Silicon Valley Tarot
  Henrique Holschuh


signature.asc
Description: Digital signature

Re: [EMAIL PROTECTED]: init scripts and the reload target]

[Henrique de Moraes Holschuh]

On Mon, 23 Jan 2006, sean finney wrote:
 is my interpretation of this correct, or am i over-analyzing things?

As I have already told you, yes, you ARE correct, and yes, anyone restarting
stuff in the reload target has a bug in their packages.

-- 
  One disk to rule them all, One disk to find them. One disk to bring
  them all and in the darkness grind them. In the Land of Redmond
  where the shadows lie. -- The Silicon Valley Tarot
  Henrique Holschuh


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]

Bug#346598: init script stop example should use --oknodo

[Henrique de Moraes Holschuh]

On Sun, 08 Jan 2006, Matt Kraai wrote:
 According to the LSB Core Specification 3.1, init scripts should
 consider running stop on a service already stopped or not running
 successful, but the example in policy does not behave this way because
 it does not pass --oknodo to start-stop-daemon in the stop case.  The
 attached patch makes it do so.

It must also use retry or some other way to make sure the daemon indeed
stopped, and we should add a comment that you cannot use --exec if:
 1. the daemon isn't an ELF executable (i.e. no #! stuff can use --exec)
 2. the daemon could be running when its executable was replaced by a
package upgrade.

Or remove that error-inducing example completely and tell people to read
/etc/init.d/skeleton (which is easier to fix than policy :-) ).

-- 
  One disk to rule them all, One disk to find them. One disk to bring
  them all and in the darkness grind them. In the Land of Redmond
  where the shadows lie. -- The Silicon Valley Tarot
  Henrique Holschuh


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]

Re: dependencies on makedev

[Henrique de Moraes Holschuh]

On Thu, 29 Dec 2005, Marco d'Itri wrote:
 These packages have already been fixed:
 rng-tools

Huh? rng-tools certainly takes benefit of MAKEDEV.  It doesn't bork if
MAKEDEV has disappeared, though.  Is that what you mean?

rng-tools postinst does this:
(cd /dev  ./MAKEDEV hwrandom || ./MAKEDEV intel_rng || true)

-- 
  One disk to rule them all, One disk to find them. One disk to bring
  them all and in the darkness grind them. In the Land of Redmond
  where the shadows lie. -- The Silicon Valley Tarot
  Henrique Holschuh


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]

Re: [Proposal] binaries must not have rpath outside /usr/lib/dir/

[Henrique de Moraes Holschuh]

On Fri, 02 Dec 2005, Ian Jackson wrote:
  Indeed, rpath is only acceptable for:
1. dynamically loaded modules/plugins
2. libraries that must live outside of ld.so directories
 
 And these things might reasonably be searched for in
 /usr/local/lib/foo as well as /usr/lib/foo.

rpath is for the canon location of a library.  If someone wants something
searched, he puts it (in fact, I guess we already do for him) in ld.so.conf.

There is no legal, acceptable or even remotely sane reason for a rpath
pointing to /usr/local/* *IN SOMETHING PACKAGED BY DEBIAN*.

-- 
  One disk to rule them all, One disk to find them. One disk to bring
  them all and in the darkness grind them. In the Land of Redmond
  where the shadows lie. -- The Silicon Valley Tarot
  Henrique Holschuh


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]

Re: [Proposal] binaries must not have rpath outside /usr/lib/dir/

[Henrique de Moraes Holschuh]

On Fri, 02 Dec 2005, Ian Jackson wrote:
 A sensible way to arrange for this to work might be for
 /usr/bin/frobnicate's rpath to specify /usr/lib/frobnicate/modules.
 That way frobnicate can load `frictive' without having to specify the
 path.

Hmm... (reads ELF 1.2). Oh drat, DT_RPATH is a collon-delimited lists of
search path*s*.   Yeah, in that case it certainly makes sense to allow
/usr/local in there.

I apologise. I had forgotten you can have something like
/usr/lib/foo/bar:/usr/local/lib/foo/bar in DT_RPATH.

 Please don't shout.  I heard you the first time.

Yeah, my bad. Sorry about that.

-- 
  One disk to rule them all, One disk to find them. One disk to bring
  them all and in the darkness grind them. In the Land of Redmond
  where the shadows lie. -- The Silicon Valley Tarot
  Henrique Holschuh


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]

Re: [Proposal] binaries must not have rpath outside /usr/lib/dir/

[Henrique de Moraes Holschuh]

On Wed, 30 Nov 2005, Ian Jackson wrote:
 Just as one example, a program might reasonably have an rpath in
 /usr/local/lib/package/.  And there might be other reasons why

Not in Debian, it doesn't.  Since policy is about Debian *packages*, and
Debian cannot ship much more than empty dirs under /usr/local, any rpath
inside a Debian package pointing to /usr/local is a major error.

Indeed, rpath is only acceptable for:
  1. dynamically loaded modules/plugins
  2. libraries that must live outside of ld.so directories

and IMHO any case of (2) probably needs some debian-devel discursion first.

-- 
  One disk to rule them all, One disk to find them. One disk to bring
  them all and in the darkness grind them. In the Land of Redmond
  where the shadows lie. -- The Silicon Valley Tarot
  Henrique Holschuh


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]

Re: [Proposal] binaries must not have rpath outside /usr/lib/dir/

[Henrique de Moraes Holschuh]

On Mon, 28 Nov 2005, Bill Allombert wrote:
 So I would propose for policy explicitly forbid 2) and 3).

Agreed. In particular, 3) is a MUST NOT if I ever seen one.

-- 
  One disk to rule them all, One disk to find them. One disk to bring
  them all and in the darkness grind them. In the Land of Redmond
  where the shadows lie. -- The Silicon Valley Tarot
  Henrique Holschuh


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]

Re: [Pkg-sysvinit-devel] Bug#339955: sysv-rc: /etc/init.d/*.sh should be sourced in runlevel S

[Henrique de Moraes Holschuh]

On Sat, 19 Nov 2005, Petter Reinholdtsen wrote:
 What a strange thing for policy to specify.  :)

On the contrary.

 This will make it impossible to speed up the rcS.d boot by running
 scripts in parallel.  It does not sound sensible to me.

rc.S scripts have always had the capability of setting environment
variables.  We have to be *very* careful here before such a change is
made.  This means auditing *ALL* rcS scripts in Debian to know which ones
need this capability, and what it is used for.

We will get enough of a speedup by runining runlevel 2 in parallel, even if
parts of rcS have to be serialized.

 Well, I would be surprised if any of the scripts used in rcS.d uses
 exit, as this would break the boot.

They don't, AFAIK.  And it is a critical bug to do so, anyway.

  Note: I believe that return should work to exit from a script both
  when sourced and when executed but perhaps someone with a copy of
  POSIX could confirm.
 
 As far as I know, return will exit the script if used in the 'outer'
 scope.

AFAIK, that's correct.

-- 
  One disk to rule them all, One disk to find them. One disk to bring
  them all and in the darkness grind them. In the Land of Redmond
  where the shadows lie. -- The Silicon Valley Tarot
  Henrique Holschuh


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]

Re: Add Debian revision number standards to policy?

[Henrique de Moraes Holschuh]

On Thu, 03 Nov 2005, Steve Langasek wrote:
 On Thu, Nov 03, 2005 at 06:45:32PM +0100, Kurt Roeckx wrote:
  If I number it 1.2-0.1, it would mean it's no longer a native
  package.  Does that mean I should split it in an .orig.tar.gz and
  a diff?
 
 On the contrary; Policy does not say that a native package can't have a - in
 its version, it only says that *if* the package is non-native, the Debian
 revision is the part after the last -.
 
 This format for NMU version numbers of native packages (1.2 - 1.2-0.1) is
 the only one that provides unambiguous identification of NMUs and binNMUs by
 version number alone, and it's the only one that's guaranteed not to collide
 with the maintainer's versioning scheme.

Ah, so I was completely wrong on this issue.  Good to know...

-- 
  One disk to rule them all, One disk to find them. One disk to bring
  them all and in the darkness grind them. In the Land of Redmond
  where the shadows lie. -- The Silicon Valley Tarot
  Henrique Holschuh


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]

Re: Add Debian revision number standards to policy?

[Henrique de Moraes Holschuh]

On Thu, 03 Nov 2005, Kurt Roeckx wrote:
 How about numbering for native packages?  People seem to be
 disagreeing alot on how to do that:

I won't touch that one.  IMHO people can number diff-less packages whichever
way they want to.

 Should I add a debian reversion or not?  Say the version is 
 1.2, and I do an NMU, would I call it:

IMHO, we should never change a diff-less package to a diff-based one in an
NMU (unless the NMU is for the explict objective of doing just that...), the
maintainer won't like it.  So tack the usual NMU/binary NMU .NMU and
.NMU.BINNMU suffixes to the end, no dashes.

 - 1.2.0.1
 - 1.2.1

Yes, these ones are fine, AFAIK.

 If I number it 1.2-0.1, it would mean it's no longer a native
 package.  Does that mean I should split it in an .orig.tar.gz and
 a diff?

You'd have to. So don't do it.

 What about binNMU's for those packages?

I have no experience trying to bin-NMU a diff-less package, I don't know how
well it works.  I will wait for someone with more knowledge to step in.

-- 
  One disk to rule them all, One disk to find them. One disk to bring
  them all and in the darkness grind them. In the Land of Redmond
  where the shadows lie. -- The Silicon Valley Tarot
  Henrique Holschuh


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]

Re: Add Debian revision number standards to policy?

[Henrique de Moraes Holschuh]

On Tue, 01 Nov 2005, Nathanael Nerode wrote:
 I was surprised to discover that the standard rules for Debian
 revision numbers
 (maintainer revisions contain no dots;
  source NMUs contain one dots;
  binary NMUs contain two)
 are not in Policy, but only in the Developer's Reference.

They are not even where they need to be toolwise, binary NMUs break strict
versioned dependencies hideously...

 Should a policy patch be created?

IMHO, Yes. IMHO you should also add that you are only to use numbers without
zero padding (not that the tools will break if you pad, AFAIK, but...), that
they must increase monotonically, that NMUs start with 1 and binary NMUs
start with 0.1 if there isn't a NMU version yet, or NMU.1 if there is one.

-- 
  One disk to rule them all, One disk to find them. One disk to bring
  them all and in the darkness grind them. In the Land of Redmond
  where the shadows lie. -- The Silicon Valley Tarot
  Henrique Holschuh


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]

Re: Section 6.3 should reference 3.10.1 (was: It is 23:53, do you know whether your package (un)installs cleanly?)

[Henrique de Moraes Holschuh]

On Sun, 04 Sep 2005, Marc 'HE' Brockschmidt wrote:
 Lars Wirzenius [EMAIL PROTECTED] writes:
  * Some packages still don't use debconf for prompting, and
instead do silly stuff that assumed it is OK to read and
write /dev/tty.
 
 Actually, the policy explicitly allows this:
 
 | The maintainer scripts are guaranteed to run with a controlling terminal
 | and can interact with the user. If they need to prompt for passwords, do
 | full-screen interaction or something similar you should do these things
 | to and from /dev/tty, [...]
 [Debian Policy 3.6.2.1, section 6.3]
 
 
 This should probably changed a bit to reference 3.10.1, which says that
 all means to prompt the user besides debconf are deprecated.
 
 I'm not yet sure that this my view is right, so I only CCed -policy (and
 have not filed a bug yet).

Your view is right. 

Any sort of user input interaction outside of debconf [for maintainer
scripts] is deprecated.  

Any sort of importat output user interaction [i.e. alerts to the user]
outside of debconf warnings is deprectated, AND an extremely dumb idea to do
otherwise anyway, since it is likely that anything short of a debconf
warning will never be noticed anyway.

-- 
  One disk to rule them all, One disk to find them. One disk to bring
  them all and in the darkness grind them. In the Land of Redmond
  where the shadows lie. -- The Silicon Valley Tarot
  Henrique Holschuh


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]

Re: libxine1 creates /u/s/d/xine/

[Henrique de Moraes Holschuh]

On Fri, 06 May 2005, Joerg Sommer wrote:
 Henrique de Moraes Holschuh [EMAIL PROTECTED] wrote:
  On Sun, 03 Apr 2005, Bill Allombert wrote:
  For the record:
  $ dpkg -L libxine1|grep /usr/share/doc
  /usr/share/doc/xine
  [...]
  Given the binary package 'xine' does not exist currently, I think this
  is a policy violation due to namespace breakage.
 
  Agreed.  The directory would have to be named at least XINE or Xine to avoid
  such problems (in which case I don't think it violates policy, or at least
  not its spirit).
 
  That said, it is much better to have it all under libxine1.
 
 What is with /usr/share/doc/texmf? Is this legal?

Sort of.  It has the same problem as the /usr/share/doc/xine dir, but the
debian-tex maintainers keep control of it, so it is coordinated and no
namespace clashes should happen.

 
 $ pkgof /usr/share/doc/texmf/
 tetex-base  tetex-bin  foiltex  tetex-doc

Try dlocate /usr/share/doc/texmf/, it gives you a better picture.

-- 
  One disk to rule them all, One disk to find them. One disk to bring
  them all and in the darkness grind them. In the Land of Redmond
  where the shadows lie. -- The Silicon Valley Tarot
  Henrique Holschuh


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]

Re: Policy for devfs support

[Henrique de Moraes Holschuh]

On Fri, 22 Apr 2005, Russell Coker wrote:
 On Sunday 27 March 2005 00:26, Roger Leigh [EMAIL PROTECTED] 
 wrote:
  Is there a project-wide policy for support for devfs (and devfs-style,
  e.g. udev devfs.rules) device naming?
 
 The SE Linux kernel code doesn't and won't support devfs.  Devfs is on the 
 way 
 out and there is no interest in adding any support.
 
 SE Linux also has a list of device names for initially labelling a file 
 system.  Neither devfs nor devfs device names will work with SE Linux.

That's fine.  But regular packages should not limit themselves like that
IMHO.  That way, they will work under udev and static, with or without
devfs, in either standard or devfs naming modes.  SE Linux has special
needs, and that's quite easy to understand.

-- 
  One disk to rule them all, One disk to find them. One disk to bring
  them all and in the darkness grind them. In the Land of Redmond
  where the shadows lie. -- The Silicon Valley Tarot
  Henrique Holschuh


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]

Re: libxine1 creates /u/s/d/xine/

[Henrique de Moraes Holschuh]

On Sun, 03 Apr 2005, Bill Allombert wrote:
 For the record:
 $ dpkg -L libxine1|grep /usr/share/doc
 /usr/share/doc/xine
[...]
 Given the binary package 'xine' does not exist currently, I think this
 is a policy violation due to namespace breakage.

Agreed.  The directory would have to be named at least XINE or Xine to avoid
such problems (in which case I don't think it violates policy, or at least
not its spirit).

That said, it is much better to have it all under libxine1.

-- 
  One disk to rule them all, One disk to find them. One disk to bring
  them all and in the darkness grind them. In the Land of Redmond
  where the shadows lie. -- The Silicon Valley Tarot
  Henrique Holschuh


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]

Re: Policy for devfs support

[Henrique de Moraes Holschuh]

On Sat, 26 Mar 2005, Roger Leigh wrote:
 Is there a project-wide policy for support for devfs (and devfs-style,
 e.g. udev devfs.rules) device naming?

Do it if you can. It is not mandated anywhere, but it is clearly a very good
idea.  We should even make it a *may* in policy to stress this, I suppose.
Most maintainers (AFAIK) have been slowly changing their packages to support
devfs-like naming schemes or user-configurable naming of devices (which is
even better).

 I'm asking because of obstruction (from upstream) regarding the
 application of a simple patch to allow yaboot to support it:
 
 http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=300950
 
 If there was a definite policy of supporting it (or not), this would
 be easier.  As it stands, the tool is not properly functional on devfs
 systems.  Since we should aim to support a well-integrated system, I'm
 not happy that folks can deliberately obstruct furthering the
 integration of the system.

They cannot.  You can override upstream on this with a clear conscience, it
*is* on the role-call of the downstream maintainer to tweak things like
this, and we do it all the time.

But let me suggest you a better, much more friendly solution:

Enhance the program so that it can be configured to use the first sucessfull
open of a *list* of user-supplied devices (or, if that is too intrusive, to
support a single user-configured device, and add a shell wrapper that tries
to detect which device to use, like I did with rng-tools in sid (see its
initscript)). 

Make the hardcoded default be /dev/nvram, of course.

-- 
  One disk to rule them all, One disk to find them. One disk to bring
  them all and in the darkness grind them. In the Land of Redmond
  where the shadows lie. -- The Silicon Valley Tarot
  Henrique Holschuh


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]

Re: watch file in policy

[Henrique de Moraes Holschuh]

On Mon, 14 Feb 2005, Adam Heath wrote:
 On Sat, 12 Feb 2005, Bluefuture wrote:
  3. submit with a wishlist (tag patch) bug to BTS.
 
 These things shouldn't be filed as bugs, when there are so many.  Make a

It is not an one-go mass-bug filling, since he has to review every watch
file anyway.  It won't hit the BTS all at once (unless he's crazy).

 status page, discuss on -devel, and when the number of packages gets smaller,
 then maybe you can file a mass-bug.

He has already done that, you know.  DEHS *is* the status page, one *can*
request it to send the watch file the DEHS wwizard used, etc.  And DEHS has
been the subject of threads in d-devel a few times, already.

And DEHS has been out there for some time, too.  So it is not a it is too
new issue, either.

-- 
  One disk to rule them all, One disk to find them. One disk to bring
  them all and in the darkness grind them. In the Land of Redmond
  where the shadows lie. -- The Silicon Valley Tarot
  Henrique Holschuh


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]

Bug#225465: Suggested course of action to close this bug

[Henrique de Moraes Holschuh]

On Tue, 30 Dec 2003, Dan Jacobson wrote:
 Debian should no longer be like some mere arcade kiddie game machine,
 where if you don't like the games staring when you deposit your coin,
 then sorry.

It is not anymore.  This has been fixed by invoke-rc.d.  All that remains
now is to give users an easy interface to this machinery.

 surely mess up my system, so I'm not the daring experimenter anymore.

You just have to either:

1. Remove all S* links to stuff you don't want stared, OR
2. apt-get install file-rc, and edit the file-rc config file which is
   MUCH easier to use.

You can even use one of the pretty GUI configurator thingies for changing
the links. I don't think there is one for file-rc, but then, file-rc does
NOT need one to be simple to use...

This will *not* stop packages from starting services on their first
install, though.  Any packages that have been fixed to use invoke-rc.d will
not restart the services on package upgrades.  Broken ones still calling
/etc/init.d/whatever directly will, but that's a bug: report it whenever you
find one of these packages.

 Each package that puts a file in /etc/init.d must in its debconf area,
 call [a new debconf element[?]] that will ask the user's wishes as to if
 this package is to be started at boot or not.

There is a much better way.

1. Fix all packages to properly use update-rc.d and invoke-rc.d ONLY, and
   to never run the /etc/init.d file directly  (this is transparent to
   the user).  All maintainers should be changing their packages to use
   invoke-rc.d already, if they invoke initscripts.

2. Write and package a policy-rc.d script that explicitly requires that
   the user has reviewed a package before it can start its services
   (otherwise, the service will be started at package install, even if
   it is not started at boot).   

3. Write a pretty service manager thing that:
 1. Manages the rc.d/file-rc service/runlevels stuff
 2. Tells the policy-rc.d in (2) wether services are to be
active or not on package installs/upgrades.

(1) will be taken care for, but it might take a while untill all packages
do it.  New packages already do this right.

(2) is very easy to write, and I volunteer to do it.

(3) takes some effort.  Any volunteers?  A good tcl/tk coder can get this
thing ready in about 4 hours, I think.

THIS solution has the following advantages:

 1.  NO DEBCONF POLUTION OR ANNOYANCES
 2.  It does NOT touch the packages themselves
 3.  It won't face much opposition, since it is non-intrusive, and
 it is also technically sound.
 4.  It doesn't require any policy changes.

 M Make sure you just delete the start links, not the stop ones. That
 M should last forever. If you delete all they will be regenerated during
 M the next update.

This is correct.  Anyone that has read (and paid close attention to) the
update-rc.d manpage (in unstable) knows that.  But it also means you can't
use update-rc.d to do local administrator changes to the links (changes
made by update-rc.d ARE lost in the next update), and THAT gets people
confused.

-- 
  One disk to rule them all, One disk to find them. One disk to bring
  them all and in the darkness grind them. In the Land of Redmond
  where the shadows lie. -- The Silicon Valley Tarot
  Henrique Holschuh

Re: Init.d script, preventing start of one service

[Henrique de Moraes Holschuh]

On Tue, 11 Nov 2003, Sylvain LE GALL wrote:
 In one of the package i maitain i have a config script which begin by
 asking if the service attached to this package need to be run. I use a
 variable ( stored in /etc/default/mldonkey -- LAUNCH_AT_STARTUP=yes )
 to determine if i need to run the service or not.
 
 If the variable is set to yes, the init script launch the service,
 otherwise it does nothing. 
 
 The user ask me if i can use update-rc.d to create/remove symlink
 depending on the former LAUNCH_AT_STARTUP value.
 
 What is the standard solution for doing this in debian ?

1. leave update-rc.d alone. Register the init script and be done with it.
2. setup the init script to source /etc/default/mldonkey, and block the
start (return ok status BTW) if LAUNCH_AT_STARTUP is not true.

This is not the best solution, but it is the current best-practice.

 ps : i know ssh use a file to launch or not sshd, is it a good solution
 ?

No.

-- 
  One disk to rule them all, One disk to find them. One disk to bring
  them all and in the darkness grind them. In the Land of Redmond
  where the shadows lie. -- The Silicon Valley Tarot
  Henrique Holschuh

Bug#208010: [PROPOSAL] init script LSB 1.3 compliance (revised)

[Henrique de Moraes Holschuh]

On Mon, 01 Sep 2003, Stefan Gybas wrote:
 Andrew Suffield wrote:
 You can't make it mandatory before you implement it.
 
 I'll implement status for the init script and the changes to the 
 maintainer scripts in my packages with the next upload. What else should 
 I implement?

Tested patches against all init-script using packages to the BTS.

-- 
  One disk to rule them all, One disk to find them. One disk to bring
  them all and in the darkness grind them. In the Land of Redmond
  where the shadows lie. -- The Silicon Valley Tarot
  Henrique Holschuh

Re: Status of UTF-8 Debian changelogs

[Henrique de Moraes Holschuh]

On Sun, 08 Jun 2003, Wouter Verhelst wrote:
 [EMAIL PROTECTED]:~$ echo $LANG
 nl_BE.UTF-8

Is it in locale.gen? Otherwise, you will NOT have the locale information...

 which means that uxterm manually ensures that $LANG is set to
 something.UTF-8, since I set my $LANG to nl_BE.

Ick.

-- 
  One disk to rule them all, One disk to find them. One disk to bring
  them all and in the darkness grind them. In the Land of Redmond
  where the shadows lie. -- The Silicon Valley Tarot
  Henrique Holschuh

Re: Status of UTF-8 Debian changelogs

[Henrique de Moraes Holschuh]

Hi Colin!

On Mon, 09 Jun 2003, Colin Walters wrote:

 On Mon, 2003-06-09 at 12:05, Henrique de Moraes Holschuh wrote:
  On Sun, 08 Jun 2003, Wouter Verhelst wrote:
   [EMAIL PROTECTED]:~$ echo $LANG
   nl_BE.UTF-8
  
  Is it in locale.gen? Otherwise, you will NOT have the locale information...
 
 Ah, good call.  We should have that in the default locale.gen.

You'd need to add UTF8 locales for every locale, then. And they're often
unsupported. I know for a fact pt_BR.UTF8 is unsupported (even if localegen
claim it managed to generate it).

-- 
  One disk to rule them all, One disk to find them. One disk to bring
  them all and in the darkness grind them. In the Land of Redmond
  where the shadows lie. -- The Silicon Valley Tarot
  Henrique Holschuh

Bug#191036: create /run for programs that run before /var is mounted

[Henrique de Moraes Holschuh]

Hi Bill!

On Mon, 28 Apr 2003, Bill Allombert wrote:

 On Mon, Apr 28, 2003 at 11:56:24AM +0200, Santiago Vila wrote:
   As per the discussion on debian-devel, I am filing this bug with patch
   to have base-files create the /run directory.  To summarise the
   discussion, we need to move program state out of /etc but for some
   programs that run early on during the boot process, /var is not mounted
   and so /var/run is unavailable.  Thus Debian will be enhancing the FHS
   by demonstrating it is possible to leave /etc totally under the admin's
   control.  A proposed addition to the FHS will be forthcoming once we can
   show that /run is useful.
 
 I second this proposal.

There is no proposal made yet. Where is the text you are seconding? :-)

 I am absolutly neutral w.r.t the name of the directory, but I am
 positive we need it.

There is the / read-only crowd too. We need the *text* of the proposal to
either second or refuse it.

-- 
  One disk to rule them all, One disk to find them. One disk to bring
  them all and in the darkness grind them. In the Land of Redmond
  where the shadows lie. -- The Silicon Valley Tarot
  Henrique Holschuh

Bug#191036: create /run for programs that run before /var is mounted

[Henrique de Moraes Holschuh]

Hi Bill!

On Mon, 28 Apr 2003, Bill Allombert wrote:

 On Mon, Apr 28, 2003 at 01:51:31PM -0300, Henrique de Moraes Holschuh wrote:
  Hi Bill!
 As per the discussion on debian-devel, I am filing this bug with patch
 to have base-files create the /run directory.  To summarise the
 discussion, we need to move program state out of /etc but for some
 programs that run early on during the boot process, /var is not 
 mounted
 and so /var/run is unavailable.  Thus Debian will be enhancing the FHS
 by demonstrating it is possible to leave /etc totally under the 
 admin's
 control.  A proposed addition to the FHS will be forthcoming once we 
 can
 show that /run is useful.
   
   I second this proposal.
  
  There is no proposal made yet. Where is the text you are seconding? :-)
 
 The proposal is to have base-files creating the /run directory,
 since base-files maintainer has reassigned the bug to debian-policy.
 
 If you something more formal, maybe
 
 As an extension to the FHS, the Debian filesystem has a /run directory
 intended to hold program state file for programs that run early during
 the boot process when /var is not yet mounted.

/run must be in the root filesystem, or it must be made available at the
time the root filesystem would be mounted in read-write mode. It must be
writeable.

Or something to that effect. Isn't that what you guys want?

-- 
  One disk to rule them all, One disk to find them. One disk to bring
  them all and in the darkness grind them. In the Land of Redmond
  where the shadows lie. -- The Silicon Valley Tarot
  Henrique Holschuh

Bug#191036: create /run for programs that run before /var is mounted

[Henrique de Moraes Holschuh]

Hi Bas!

On Mon, 28 Apr 2003, Bas Zoetekouw wrote:

 Hi Bill!
 
 You wrote:
 
  Thanks a lot! I will try to improve it again:
  
As an extension to the FHS, the Debian filesystem has a /run directory
intended to hold program state file for programs that run early during
the boot process when /var is not yet mounted.

/run must be in the root filesystem, or it must be made available at the
time the root filesystem would be mounted in read-write mode. It must be
writeable. It is not required that its content survives system reboot.
 
 Should't the distinction between /run and /var/run be made more
 explicit?  Something like:
 
   State files must go into /var/run unless they are needed/created before
   /var is mounted rw, in which case they must go into /run.

Well, /run is completely ephemeral as specified so far, while /var/run
*might* retain directories across reboots.  Do we want a fully ephemeral
/var/run (this *will* break most packages that have subdirs in there, I have
already fixed mine to recreate the dirs in the initscripts due to user
requests, but...)?

If we do want an ephermeral /var/run, just symlink it to /run and be done
with it ;-)

-- 
  One disk to rule them all, One disk to find them. One disk to bring
  them all and in the darkness grind them. In the Land of Redmond
  where the shadows lie. -- The Silicon Valley Tarot
  Henrique Holschuh

Bug#190753: [PROPOSAL] frown on programs in PATH with language extentions

[Henrique de Moraes Holschuh]

On Fri, 25 Apr 2003, Joey Hess wrote:
 I suggest we add the following to policy section 11.4.
 (Wording by Bill Allombert.)
 
  When scripts are installed into into a directory in the system PATH,
  the script name should not include an extension such as .sh or .pl
  that denotes the scripting language currently used to implement it.
 
 This was previously discussed on the thread entited 
 policy should frown on programs in PATH with language extentions (ie, .pl)
 on the debian-policy list. I will leave off the full rationalle, which
 is in the first message of that thread. The short version is that using
 this sort of name seems to be becoming more prevelant, and that it
 asks for problems when a program is reimplemented, and makes it harder to
 type command names.
 
 I am looking for seconds to this proposal.

Seconded.

-- 
  One disk to rule them all, One disk to find them. One disk to bring
  them all and in the darkness grind them. In the Land of Redmond
  where the shadows lie. -- The Silicon Valley Tarot
  Henrique Holschuh


pgpZPMrfCULjz.pgp
Description: PGP signature

Re: Versioned Symbols

[Henrique de Moraes Holschuh]

On Thu, 20 Mar 2003, Junichi Uekawa wrote:
 I consider the following portion may be suitable for inclusion in the
 policy; if it is more precisely worded:
 
  If library or application dlopens a module, that module and its chain of
  dependencies have a chance of being loaded in two versions at the same
  time. Unless RTDL_GROUP option for dlopen gets implemented and gets used,
  there are basically two options:
 
 * Uniquely name symbols, differently between different SONAMES
 * Version the symbols using symbol versioning as described in Chapter 14

Looks good to me.  It can't go into policy yet, though. Not enough
machinery, and we really need to have all core libs converted and working to
whatever policy we choose before we propose it.

-- 
  One disk to rule them all, One disk to find them. One disk to bring
  them all and in the darkness grind them. In the Land of Redmond
  where the shadows lie. -- The Silicon Valley Tarot
  Henrique Holschuh

Re: Versioned Symbols

[Henrique de Moraes Holschuh]

On Tue, 11 Mar 2003, Anthony Towns wrote:
 On Mon, Mar 10, 2003 at 10:47:40AM -0300, Henrique de Moraes Holschuh wrote:
  Agreed.  As far as programs build on Debian systems won't run elsewhere,
  it is just a matter of pushing the versioning of said core libraries to the
  LSB, which shouldn't be too difficult if we do it right and send in patches.
 
 Uh, no, the LSB doesn't standardise every library that is shipped by every
 distribution other than Debian.

It doesn't need to, either. Whatever isn't in the LSB doesn't matter as far
as interoperatibility is concerned [if the LSB is done right].  And it is
NOT like the programs fail to run. You get annoying warnings (that could
even be removed from ld.so, for that matter).

-- 
  One disk to rule them all, One disk to find them. One disk to bring
  them all and in the darkness grind them. In the Land of Redmond
  where the shadows lie. -- The Silicon Valley Tarot
  Henrique Holschuh

Re: Versioned Symbols

[Henrique de Moraes Holschuh]

On Wed, 12 Mar 2003, Anthony Towns wrote:
 On Tue, Mar 11, 2003 at 10:47:34AM -0300, Henrique de Moraes Holschuh wrote:
  It doesn't need to, either. Whatever isn't in the LSB doesn't matter as far
  as interoperatibility is concerned [if the LSB is done right].  
 
 Uh, libqt isn't standardised by the LSB, and probably won't be.

Yuck. Big hole in the LSB, then (IMHO).

Anyway, patch ld.so, then.

-- 
  One disk to rule them all, One disk to find them. One disk to bring
  them all and in the darkness grind them. In the Land of Redmond
  where the shadows lie. -- The Silicon Valley Tarot
  Henrique Holschuh

Re: Versioned Symbols

[Henrique de Moraes Holschuh]

On Wed, 12 Mar 2003, Junichi Uekawa wrote:
 That is caused by dlopen used by PAM, which I assume is caused by

Or dlopen used by glibc (nss modules), or dlopen used by anything else.
Apache modules can kill apache that way too, for example (afaik anyway).

 dlopening with RTDL_GLOBAL, where there is an option to 
 dlopen with RTDL_LOCAL.

hmm... how does that behaves when the conflict is two or more libs down the
chain from the PoV of the stuff being dlopened?

-- 
  One disk to rule them all, One disk to find them. One disk to bring
  them all and in the darkness grind them. In the Land of Redmond
  where the shadows lie. -- The Silicon Valley Tarot
  Henrique Holschuh

Re: Versioned Symbols

[Henrique de Moraes Holschuh]

On Sun, 09 Mar 2003, Sam Hartman wrote:
  I think that we should implement versioned symbols.
 Anthony Uhh, versioned symbols means that programs built on
 Anthony Debian systems won't run elsewhere. That's not something
 Anthony we should be doing, except in very specific cases where
 Anthony the gain outweighs the drawback.
 
 I believe that the gain outweighs the drawback in any core library
 that can drag in plugins unrelated to the application.  In particular,
 I believe that versioned symbols should be used at a minimum for
 dependencies of SASL plugins, PAM modules and NSS modules.

Agreed.  As far as programs build on Debian systems won't run elsewhere,
it is just a matter of pushing the versioning of said core libraries to the
LSB, which shouldn't be too difficult if we do it right and send in patches.

 Certainly in cases where we want to add versioned symbols we should
 work as hard as possible with the upstreams to accept these changes.

Indeed.  Here's a plan of things to do for that to happen (based on my
experience with SASL upstream):

1. Write an autoconf macro that handles detection on the availability
   of symbol versioning in a platform.  Document the procedure so that
   we can send the algorithm instead for upstream not using autoconf.

2. Write an autoconf macro that changes the libtool variables needed
   to version something.

3. Write an autoconf macro that sets the linker/cc options needed to
   version something.

4. Send a full patch upstream that is plug-and-play, and defaults to
   versioning enabled where available.

5. Always use a non-dumb version prefix of IDmajor such as SASL2
   in the proposed patch (or ID_major, or minor variations of that),
   using a proper ID that won't cause headaches later. CMUSASL2 would
   be another example of a good ID for Cyrus SASL versioning.

6. Send email to d-d-a with a url where we document all the issues
   with versioning, their workarounds, and our sample scripts. Send
   email to contacts in other linux distributions with said url.
   Push it at the LSB mailing lists, with a proposal of the core libraries
   that need versioning first and foremost.

-- 
  One disk to rule them all, One disk to find them. One disk to bring
  them all and in the darkness grind them. In the Land of Redmond
  where the shadows lie. -- The Silicon Valley Tarot
  Henrique Holschuh

Re: Versioned Symbols

[Henrique de Moraes Holschuh]

On Fri, 07 Mar 2003, Wichert Akkerman wrote:
 Previously Stephen Frost wrote:
We need to make a decision on how to properly handle multiple library
versions ending up linked into the same process.
 
 I think what we should do is simple: 'do not do that'.

We have been very bad on that regard.  Certain... not-so-nice measures would
have to be taken to keep up with the 'do not do that' solution.

I consider that non-workable for core libraries (SASL, LDAP, glibc/nss
modules, libX* and unfortunately, part of the kde and gnome bloat).

As an example: for SASL (which currently causes breakage encompassing LDAP
(and through it, glibc nss modules), we would have to force-feed upstream a
SASL2 enabled source of postfix and sendmail, for example. We would also
have to drop our old openldap 2.0 and somehow get 2.1 ready.

- Implement versioned symbols
  - May cause binary compatibility issues
  - Doesn't follow LSB (I believe..)
  - Could be difficult to do correctly

After we fix the @[EMAIL PROTECTED] cretin problems with the dynamic loader 
adding
static crap to libraries in certain archs [that must not be versioned], it
is actually trivial to do correctly, GIVEN a proper build environment (i.e.
not massively braindamaged makefiles, etc).

 Very hard to implement and will result in non-trivial patches that
 upstream sources will probably never merge.

Indeed.  But it is actually useful for Solaris as well, so you might find
some of upstream quite willing to take the patches.  We already do so for
libdb, and upstream for libsasl already said they would accept patches that
did it right.  It is difficult to know how many would be willing, if there
is a hard enough shove (with ready-to-apply patches, obviously).

- Conflict between library versions
  - Wouldn't allow valid setups where the versions aren't linked into
the same process
  - Lots of packages would end up uninstallable for certain library
upgrades
 
 Those two reasons make it obvious we should not do that I think.

It is actually not doable. Libraries conflict only inside a process boundary
(unless they have been extremely badly designed and have an external
dependency on a file or something like that), so we must allow conflicting
libraries installed in the system.

 I challenge you to implement it for a few versions of a few different
 non-trivial libraries.

We just need it for libraries that are themselves linked by other
libraries, and that change too much.  E.g. libz doesn't need it (thank
god!), but SASL and openldap most definately do, and glibc and libdb already
have it.

 I think a different solution: check for this problem when build a
 package and abort if you hit it. That is trivial to implement as

Won't work 100% of the time. dlopen makes this also a runtime problem.

 a linda check or standalone tool you can call from debian/rules. In
 fact I think dpkg-scanlibs already does that.

Well, either linda or lintian is indeed trapping illegal linkage of two
different versions of libraries in the same binary. But this catches only
a part of the problem, and the easy one to fix, at that :(

-- 
  One disk to rule them all, One disk to find them. One disk to bring
  them all and in the darkness grind them. In the Land of Redmond
  where the shadows lie. -- The Silicon Valley Tarot
  Henrique Holschuh