po4a
BuILd-DePeNDs-Indep: doxygen
BuILd-CoNfLIctS: automake1.4
StANdaRdS-VErsIoN: 4.6.1
VcS-brOwSeR: https://salsa.debian.org/debian/xz-utils
VcS-giT: https://salsa.debian.org/debian/xz-utils
HoMEpaGe: https://tukaani.org/xz/
RuLEs-ReQuIRes-rOoT: no
Thanks for considering,
--
Steve Langasek
On Mon, Feb 13, 2023 at 09:03:34AM -0500, Marvin Renich wrote:
> * Steve Langasek [230212 00:03]:
> > FWIW I think that it's the wrong thing to do if the "circumstances" include
> > reverse-dependencies on the package which expect to interact with the
> > se
#x27;s postinst to exit 0 if:
- it ships a service,
- it is a new install or an upgrade on a system where the service was
previously started successfully, and
- the service fails to start in the postinst.
--
Steve Langasek Give me a lever long enough and a Free OS
Debian
ir associated .service; there is no need for a
> sysvinit script in these cases, but Policy requires it.)
In my mind, the intent of the current policy language is to require an init
script matching any .service units, not for .socket or .timer units.
Perhaps the text should be refined to be sy
f this requirement:
Ubuntu as a derivative was not consulted before ubuntu.series was inflicted
on us, but other derivatives who like this feature must be consulted before
upstream will un-break it for Ubuntu.
--
Steve Langasek Give me a lever long enough and a Free OS
Debian Dev
nother arch.
I don't see a reason to use the field definition to try to guard against
that. Policy also doesn't prohibit you declaring Architecture: amd64 for
packages that you have failed to port to other architectures. This is
correctly enforced as distro policy, not as debian/control sy
our patches downstream
in Ubuntu only, and handle new Debian package versions via a manual merge.
There is no need for a third workflow to accommodate improperly-upstreamed
patches and breaking the behavior of dpkg-source.
--
Steve Langasek Give me a lever long enough and a Free O
vendor series files. It's not how any
downstream is actually managing their delta from Debian.
> We are actively working on the relevant processes and tools right now.
> Let's see what things look like once we reach the end of that work
> before escalating this bug anywhere.
--
St
ointer to
/usr/share/common-licenses. If people feel that it's insufficiently obvious
that this is the correct usage of the field, by all means, let's document
that better; but let's not make a backwards-incompatible change to the
syntax that doesn't benefit users of the file
l not be fixed in stretch)
>
> (And the consequential lintian change.)
>
> I am not yet supplying patches for dpkg-source and for policy, because
> I think deprecating this feature will involve some discussion.
Seconded (the sentiment, and specifically the requested policy
loper community via the
debian-policy mailing list. Have you done this? If not, the work is not
"done".
But I would invite you to engage in this process and help to improve Policy.
--
Steve Langasek Give me a lever long enough and a Free OS
Debian Developer
TC resolution, and I (among others in this discussion) do not consider
this text to be in a state that's suitable for release as a new version of
policy.
--
Steve Langasek Give me a lever long enough and a Free OS
Debian Developer to set it on, and I can move t
m being when copyright information is
>too hard to find for review.
These review policies are also applied when packages go through binary NEW.
They are thus being applied inconsistently when new binary packages are
added, and are otherwise not enforced. This is problematic on several
levels
en go on to insist that Debian should make it easier to
install unauditable non-free drivers.
--
Steve Langasek Give me a lever long enough and a Free OS
Debian Developer to set it on, and I can move the world.
Ubuntu Developer
n making, and
not one that should cause more work for all Debian Developers to spend extra
time complying with a requirement which was never the intent of policy.
I will write more on this subject soon.
--
Steve Langasek Give me a lever long enough and a Free OS
Debian Developer
consistency.
In the specific case of smarty, the software appears to be under the LGPL.
So it's a violation of the license for Debian to redistribute this without
the complete source.
--
Steve Langasek Give me a lever long enough and a Free OS
Debian Developer
this point. It seems to me that
this should be dealt with by convention among the cooperating group of
packages, with hints from lintian, and doesn't require a statement in policy
itself.
Cheers,
--
Steve Langasek Give me a lever long enough and a Free OS
Debian Developer
ve this in collab-maint, I think it's probably important
to ensure that git commits are announced on debian-policy. Could someone
set this up?
Thanks,
--
Steve Langasek Give me a lever long enough and a Free OS
Debian Developer to se
> don't see it as there for the right reason.
I don't either, but I don't think it's for policy to forbid it.
> If this case isn't special enough to be in policy (which may be fair,
> given harden-*), we can get a specific ruling on it with another team.
Rather, I
4/msg00342.html
The consensus there is that we should use dh_autoreconf over
dh_autotools-dev.
--
Steve Langasek Give me a lever long enough and a Free OS
Debian Developer to set it on, and I can move the world.
Ubuntu Developer
not yet up to the ctte to decide this.
> What I understand that Russ is now saying is that if this was
> brought to the policy team, he would refer it to ctte. As
> delegate he can decide this on his own, but it would be nice
> that the other delegates didn't disagre
isted in
debian/copyright if they are not copyright holders.
--
Steve Langasek Give me a lever long enough and a Free OS
Debian Developer to set it on, and I can move the world.
Ubuntu Developerhttp://www
the
transition is already handled transparently by the mime-support package and
its triggers, such that no additional dependencies need to be added anywhere
(since /etc/mailcap is already owned by mime-support, clearly any package
which is consuming it should already be depending on it). In that
On Mon, Sep 16, 2013 at 11:45:48AM +0900, Charles Plessy wrote:
> Dear all,
> do you think it would make sense to remove the FHS exception for the /selinux
> directory in the next version of the Policy ?
> See the attached patch.
Seconded.
--
Steve Langasek Giv
n. So to the extent that this is an issue, I believe it only
applies to works that are GPLv2 only.
--
Steve Langasek Give me a lever long enough and a Free OS
Debian Developer to set it on, and I can move the world.
Ubuntu Developer
ts for udebs documented centrally where all
maintainers can refer to them.
--
Steve Langasek Give me a lever long enough and a Free OS
Debian Developer to set it on, and I can move the world.
Ubuntu Developer
same issue for proposed paragraphs about removed files.
There's no reason experimenting should be blocked. You can put anything you
want to in debian/copyright, in any format you like - you just can't call it
copyright-format 1.0. Changing the header to not claim that it *is*
copyrigh
o use the gcc
option `-Wl,-z,defs' when building a shared library. Since this
option enforces symbol resolution at build time, a missing library
reference will be caught early as a fatal build error.
--
Steve Langasek Give me a lever long enough and a
r debian decides to
> grant additional licensing alternatives, retroactively, after the package
> has already entered the archives. Does this mean the package should /
> must be updated to include this additional licence alternative(s)?
You're certainly allowed to... but there's
lt;http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=591791#294>.
Thanks,
--
Steve Langasek Give me a lever long enough and a Free OS
Debian Developer to set it on, and I can move the world.
Ubuntu Developer
ld like to suggest #591791 be added to this list. This is already
implemented in the archive in startpar/sysvinit/debhelper, so this is now a
matter of documenting existing practice and documenting the correct
constraints on the use of upstart jobs in packages, which I think meets your
criteria.
user debian-pol...@packages.debian.org
usertag 591791 seconded
thanks
If I understand the policy process correctly, the N=3 requirement for
patches includes the submitter; so with two other seconds, I think this is
ready to go.
--
Steve Langasek Give me a lever long enough and
package for data or
config files that are not removed until package purge will not be removed
*unless* the postrm does it. This is true whether the directory is shipped
in the package or created in the postinst.
--
Steve Langasek Give me a lever long enough and a Free OS
Debia
, while passwd doesn't. adduser
> is the logical place for Debianisms.
No, this is not a correct use of Priority: required. The functionality
*should* be in the adduser package, not in the passwd package; but that's
not a sound reason to raise the priority of adduser, and raising the
pr
ignificant_ burden IMO.
This should be configurable by the package maintainer using a --remove-home
flag. In the general case, admins should not use per-package directories
under /var/lib as a dumping ground for arbitrary files and then expect these
files to be retained when the package is purg
eady exists and
> its parameters are sufficiently similiar to the parameters requested
> by the maintainer script.
How is "sufficiently similar" defined, and where is it documented? It's not
in policy, and I don't see anything in the adduser manpage that explains
this.
rrect agreement elsewhere.)
Attached is a corrected patch, which fixes the verb agreement issue above
and makes a few other tweaks (e.g., not introducing passive tense where it's
not needed, which is worse than the original problem it aims to fix), and
also catches a few more gender-specifi
tical issue.
Maintainer script calls invoke-rc.d foo stop. invoke-rc.d looks for a 'foo'
upstart job and finds none running. So it calls /etc/init.d/foo stop, which
fails.
Does invoke-rc.d return success because there was no upstart job running, or
failure because the init script fail
grant the tech commitee the authority to
> override the policy process.
Er, it most certainly does.
6.1. Powers
The Technical Committee may:
1. Decide on any matter of technical policy.
--
Steve Langasek Give me a lever long enough and a Free OS
Debian Developer
his.
There are really two subquestions here:
- When a package adds support for other init systems, how does it ensure
that the override status for the service is applied to all init systems?
- How should an admin disable a service to make sure it's disabled for all
ini
, I don't think 'update-rc.d' is a sensible
tool to have as an admin-oriented, init-system-agnostic interface for
disabling services. 'service disable' would be much better.
--
Steve Langasek Give me a lever long enough
he
> right place to put this logic imho. Putting it in each and every sysv
> init script on the other hand looks wrong to me.
You didn't actually answer the question I posed here. How should
invoke-rc.d handle the exit code of /etc/init.d/foo to make this not suck in
the corner cases
ample if we expect the
init script to still handle the stop case, because the restart and
force-reload actions are so often implemented on top of start+stop.
--
Steve Langasek Give me a lever long enough and a Free OS
Debian Developer to set it on, and I
op as a fallback: how should invoke-rc.d handle the exit
code of /etc/init.d/foo?
All possible answers to that question are sufficiently irksome that I think
we should avoid putting the complexity in invoke-rc.d.
--
Steve Langasek Give me a lever long enough and a Free
the upstart discussion. Could we perhaps take this to the other
bug?
--
Steve Langasek Give me a lever long enough and a Free OS
Debian Developer to set it on, and I can move the world.
Ubuntu Developerhttp://www.debian.org
nfs-common.
I don't see any such hook script in nfs-common. I see a few hooks that
call *reload*, which is always safe to call regardless of any invoke-rc.d
or runlevel policy. But calling '/etc/init.d/$service start' directly from
a hook would be just as broken as calling i
tead.
I prefer the former because it respects policy's existing guidance about not
calling init scripts directly, but it also leaves a larger window when the
service will be down on upgrade - and the services that have bothered to use
'restart' in the postinst usually do so to pre
uot;service" behave?
'service' is not a policy interface. Why do you want to make it one as a
precondition of letting people ship upstart jobs in the archive?
The answer, in any case, is that service should automatically prefer the
native jobs for whichever init is running, as this sh
On Sun, Feb 26, 2012 at 04:00:11PM -0800, Russ Allbery wrote:
> Steve Langasek writes:
> > I think you've misunderstood the intent here. When upstart is
> > installed, it provides *commands* called "start", "restart", "reload",
> > and &
nt here. When upstart is installed, it
provides *commands* called "start", "restart", "reload", and "stop" in
/sbin. These are the commands that must not be called from maintainer
scripts. It has nothing to do with invocation of /etc/init.d/
scripts, whic
start job is available
> must query the output of the command initctl version for
> the string upstart and avoid running in favor of the native
> upstart job.
> I'd really like to see Policy provide some sample code for how to do that,
> since otherwise people are go
for
> that reason I think that it should be documented in the Policy.
Policy is for documenting what *SHOULD* be done. It doesn't matter if it's
10 or 1000 packages that are using Vcs-Git today; if the syntax is broken,
it shouldn't go in policy.
--
Steve Langasek
ime; but
some people might find it equally unpalatable to specify fields for
everything except git.
--
Steve Langasek Give me a lever long enough and a Free OS
Debian Developer to set it on, and I can move the world.
Ubuntu Developer
d and make
> sure the text specifies it unambiguously but use plain text so as to
> make the changes not too invasive.
It would be nice to have a formal grammar down the line, but that's also too
large of a change for 1.0.
--
Steve Langasek Give me a lever long enoug
On Sun, Jan 01, 2012 at 09:58:45AM -0800, Russ Allbery wrote:
> Comments, objections, seconds?
Seconded.
Thanks,
--
Steve Langasek Give me a lever long enough and a Free OS
Debian Developer to set it on, and I can move the world.
Ubuntu Develo
r “additional
> fields”, but the current patch uses both. The Policy's chapter 5 uses
> “additional”, so this is where my choice would go even if it will increase
> the difficulty to search for previous discussions on the topic.
That's fair. Updated patch attached.
--
Steve
e top pointing at a url that lintian
doesn't know about, it would be reasonable to skip the rest and simply note
that an unrecognized format is being used. But when the file says it's
using DEP-5, it should be DEP-5.
--
Steve Langasek Give me a lever long enough and
aragraph with an extra Files: field.
I don't think that should be legal either however; we allow "extra fields"
to be added to any paragraph, but I don't believe the intent is to allow
*defined* fields to be used in paragraphs where they are not specified to be
permitted - only t
hat's the intent at all. I think this is perfectly valid:
Files: *
Copyright: The Man in the Moon, 2007
License: GPL-2+ with OpenSSL exception
License: GPL-2+ with OpenSSL exception
This program is free software [...] as a special exception, [...]
On Debian systems, [...]
Perhaps the spec sh
uch as the MPL multiple times in a single file.
The second option is not acceptable first, because it's a substantial change
to the semantics of the DEP5 format, and that's not happening for 1.0;
second, because of the issue mentioned above about embedding logic in
parsers
rball.
> get-packaged-orig-source should be provided instead.
This is a bug filed against debian-policy, though, not against bzr-builddeb.
--
Steve Langasek Give me a lever long enough and a Free OS
Debian Developer to set it on, and I can move the world.
U
r any of /run, /var/run, or /var/lock?
--
Steve Langasek Give me a lever long enough and a Free OS
Debian Developer to set it on, and I can move the world.
Ubuntu Developerhttp://www.debian.org/
slanga...@ubuntu.com
On Sun, Nov 27, 2011 at 11:55:20AM +0900, Charles Plessy wrote:
> Le Sat, Jun 25, 2011 at 04:28:41PM -0500, Steve Langasek a écrit :
> > On Sat, Jun 11, 2011 at 10:58:02PM +0200, Julien Cristau wrote:
> > > On Sat, Jun 11, 2011 at 13:49:53 -0700, Russ Allbery wrote:
instead.
The GPL Font exception refers
to the text added to the license notice of each file as
--
Steve Langasek Give me a lever long enough and a Free OS
Debian Developer to set it on, and I can move the world.
Ubuntu Developer
propose that the DPN editors won't relay them
> without at least an internal consensus.
Did you mean to post this to debian-policy? Debian-policy is the mailing
list for discussions of Debian's *technical* policy; you seem to be
discussing some other sort of political po
d we at the same time clarify
that if more than one exception is in use, you need to use a custom
shortname instead of an ORed or ANDed list of licenses.
Is there a consensus for this position?
I think for future versions of the standard, it's worth covering this case
ev
2.0-with-bison-exception does not mean that there is a
> special exception to use the GPL-2 with a so-called ‘bison’ license.
That has not been proposed.
--
Steve Langasek Give me a lever long enough and a Free OS
Debian Developer
On Mon, Nov 14, 2011 at 07:24:21PM -0600, Jonathan Nieder wrote:
> Steve Langasek wrote:
> > I think merging such changes (which at a glance appear to include arbitrary
> > preferences of word choice) is a waste of everyone's time and I'm inclined
> > to ignore this
ing to spend overly long
discussing the options. Does anyone else have a preferred option that we
could quickly reach consensus on and enact?
I have a slight preference for:
GPL-2+ with OpenSSL and Font exceptions
because it's both easy to parse and reads natur
I think merging such changes (which at a glance appear to include arbitrary
preferences of word choice) is a waste of everyone's time and I'm inclined
to ignore this altogether in favor of working on the real problems with the
text.
--
Steve Langasek Give me a lever lon
out without doing anything. Don't fight with init(8).
> ii. Even if an equivalent job file for another init system is
> available, the sysvinit script should behave as advertised (and
> not be a no-op) when init is sysvinit.
I agree that these are the relevant princ
dded to the insserv configuration file. We should
> either require init implementations to allow providing the standardised
> facility names or we should put that information somewhere in a a
> neutral location and format so all init implementations can make use of
> it.
Does
e language in 2.4 should be clarified to explicitly state this
only applies to modules from the perl source package.
--
Steve Langasek Give me a lever long enough and a Free OS
Debian Developer to set it on, and I can move the world.
Ubuntu Developer
es will be given
preference, or that main packages will be given preference over non-free
ones, when resolving virtual packages?
In any case, you can't have versioned provides, so there are some use cases
where this would still not be sufficient.
--
Steve Langasek Give me a le
stream has weird opinions about such things)
> after asking the user to confirm this be allowed in Debian?
It would probably be allowed. However, it would still be buggy under
Policy.
--
Steve Langasek Give me a lever long enough and a Free OS
Debian Developer
ss or
on debian-policy makes no difference to me, but I for one am not happy to
see this integrated into policy as-is.
--
Steve Langasek Give me a lever long enough and a Free OS
Debian Developer to set it on, and I can move the world.
Ubuntu Developer
hat're meant
to be useful for *Debian* to make decisions.
Personally, if I've got a choice, I don't use licenses that are GPL
incompatible, eg, which the MPL certainly is.
--
Steve Langasek Give me a lever long enough and a Free OS
Debian Developer
file [or text] there in the first place, if you're not
> going to read all of it?
Because not everyone who cares to know what rights they have to the software
knows what the MPL is (or has its terms memorized) in the first place!
--
Steve Langasek Give me a lever long
On Tue, Jul 26, 2011 at 12:21:48AM +0200, Bill Allombert wrote:
> Any offline discussion about policy should be ignored, as a matter of
> principle. If Lucas want to say something, he can just post it there.
He did, that's what I was referring to.
--
Steve Langasek
y the "2 day" policy. Since this is contentious, I propose the
more conservative policy be applied, as per the attached patch.
Comments?
--
Steve Langasek Give me a lever long enough and a Free OS
Debian Developer to set it on, and I can mo
lso wouldn't have a problem with it if the maintainer were to replace
'1.1' with '1.2' in the license declaration, fwiw.
I don't know whether a clarification in policy is needed to cover this. (I
don't think it's a syntactic question, so doesn't really be
the upstream sources and letting users work out the
effective rights for themselves).
If someone cares about distinguishing between the upstream granted license
and the effective license, that's going to require much better tooling for
automating this than we have now.
--
Steve Langasek
of the sort), but have the license stanza contain the text of
LGPL-3? Or if that's not what you mean, could you please provide a concrete
example of the usage at issue?
--
Steve Langasek Give me a lever long enough and a Free OS
Debian Developer to set i
ling files into
> > /lib64 and /usr/lib64 in packages with architecture amd64.
> Sounds sensible to me.
I agree.
--
Steve Langasek Give me a lever long enough and a Free OS
Debian Developer to set it on, and I can move the world.
Ubuntu Developer
eir debian/rules targets already for the second case
would get immediate benefit from autodetection, with no further changes.
--
Steve Langasek Give me a lever long enough and a Free OS
Debian Developer to set it on, and I can move the world.
Ubuntu Dev
ach is "impossible"
are equivalent to FUD.
> Proposal 3 is the safest approach,
It is the most error-prone.
--
Steve Langasek Give me a lever long enough and a Free OS
Debian Developer to set it on, and I can move the world.
Ubuntu Developer
parator. Stop.
2
$
That's sufficient to let dpkg-buildpackage conclude "build-arch is not
supported", falling back to debian/rules build, without stirring up the old
arguments about whether we want to keep Policy 4.9.
--
Steve Langasek Give me a lever long enough and
te this.
> As a medium-term solution it would be great if GNU make could itself
> support querying whether or not a makefile supports a given target.
> Since make needs to parse all the includes etc., only make itself can
> do this 100% reliably. If it's not already done
uld likely be: 1, 2, 3, 5, 4. (I could be persuaded to rank 4
above FD if this were the only way to move forward; but that's indisputably
the most disruptive to the archive, so I would hope we could reach agreement
that some or all of the other options are better.)
Cheers,
--
Steve Langasek
ady, I'm not too worried
> about it).
That part is apparently trivial, as I seem to have written a patch for it 4
years ago :-)
--
Steve Langasek Give me a lever long enough and a Free OS
Debian Developer to set it on, and I ca
above, I would like to work
> with the maintainer to see the latest upstream version of "make"
> packaged in experimental, but for a while now the maintainer has been
> hard to reach.
I think it would be reasonable to let the MIA team know about Manoj's
protr
proach, because it will
> both provide backwards compatibility with all older source packages, and
> use the rules if present in new ones.
The patch is outstanding; the make maintainer is TTBOMK currently
unavailable for Debian work. If there's a consensus on
debian-policy/devel/ctte tha
an at least try to keep it from
rendering itself irrelevant.
Thanks,
--
Steve Langasek Give me a lever long enough and a Free OS
Debian Developer to set it on, and I can move the world.
Ubuntu Developerhttp://www.deb
I do object to telling maintainers they must not delete system users,
without also giving guidance on how and when to lock the accounts.
Sorry, no time at the moment to propose verbiage to reconcile this with your
concerns.
--
Steve Langasek Give me a lever long enough and a
On Sat, Apr 30, 2011 at 03:49:26PM -0700, Russ Allbery wrote:
> Steve Langasek writes:
> > (If one wishes to argue that /etc/sasldb2 is not a configuration file,
> > then it's also a policy violation for it to be under /etc.)
> It's basically similar to /etc/shad
On Sat, Apr 30, 2011 at 12:02:46PM +0200, Holger Levsen wrote:
> On Samstag, 30. April 2011, Steve Langasek wrote:
> > 10.7.3: If the existence of a [configuration] file is required for the
> > package to be sensibly configured it is the responsibility of the package
> >
e file and remove it on purge.
So I don't think anything is actually missing in Policy?
(If one wishes to argue that /etc/sasldb2 is not a configuration file, then
it's also a policy violation for it to be under /etc.)
--
Steve Langasek Give me a lever long enough and a
uld need a new config
file (debian/users?), but I'm not sure it could be done with a very
debhelper-like syntax.
--
Steve Langasek Give me a lever long enough and a Free OS
Debian Developer to set it on, and I can move the world.
Ubuntu Developer
-time error that requires the user to
upgrade to the current gcc on i386 to fix.
--
Steve Langasek Give me a lever long enough and a Free OS
Debian Developer to set it on, and I can move the world.
Ubuntu Developer
an interface to declare additional -I arguments. So I'm not
convinced putting this in policy adds much value.
Cheers,
--
Steve Langasek Give me a lever long enough and a Free OS
Debian Developer to set it on, and I can move the world.
Ubuntu Developer
1 - 100 of 407 matches
Mail list logo
