on/review, and I might again have
> perhaps missed instances or similar.
Will take a look soon!
--
Russ Allbery (r...@debian.org) <https://www.eyrie.org/~eagle/>
Policy work, but am unlikely to be able to really get
started until after Christmas. I can aim for uploading the current next
branch sometime during that week.
I have no objections to uploading it before then; I just probably won't
have time personally.
--
Russ Allbery (r...@debian.org)
Russ Allbery writes:
> The fact that this has gone unnoticed in a source package in an existing
> release makes a pretty strong argument that nothing in Debian cares and
> we should just remove the constraint.
Here is a patch dropping the restriction on hard links in source packag
Wouter Verhelst writes:
> On Tue, Sep 20, 2022 at 07:17:17PM -0700, Russ Allbery wrote:
>> Wouter Verhelst writes:
>>> Thanks, yeah, I missed that. I'll have a stab at a patch some time soon
>>> (probably after debconf though)
>> Here, a couple of
nfusing. It was also using two terms for the same concept in the same
section, since earlier the same construction was referred to as a
"portion." I've fixed this to use "portion" consistently in this section.
--
Russ Allbery (r...@debian.org) <https://www.eyrie.org/~eagle/>
Guillem Jover writes:
> On Sun, 2022-09-18 at 20:27:46 -0700, Russ Allbery wrote:
>> Helmut Grohne writes:
>>> […] It can be made explicit in section 3.8 quite easily:
>>> Since dpkg will not prevent upgrading of other packages while an
>>> ``essential``
Russ Allbery writes:
> Here is a patch that I believe implements that, and which I think is
> ready for seconds.
Thanks for the review, both. This has now been applied for the next
release.
--
Russ Allbery (r...@debian.org) <https://www.eyrie.org/~eagle/>
Russ Allbery writes:
> I considered whether instead of starting with a priority of 40, we
> should instead bump the priority if the window manager supports the
> desktop specification, but I think this is a place where the structure
> of X environments has changed over the yea
the definition was internally
> inconsistent. I think the only thing missing is policy clarifying that
> this field is only mandatory on non-source-only uploads.
Here is a patch to fix this wording in Policy. I think it's ready for
seconds.
--
Russ Allbery (r...@deb
s, but are they
likely and important enough to have it be worth retaining a section
talking about this, as opposed to using the "not every bug is a Policy
violation" rule? We do pay a (small) complexity cost for each additional
requirement we put in Policy, so I'm tempted to just drop this
on of the Files field
implies that the section may just be - in some cases.
The current documentation certainly seems inadequate, although I'd like to
understand what the behavior of Debian software is before proposing
alternative wording.
--
Russ Allbery (r...@debian.org) <https://www.eyrie.org/~eagle/>
Wouter Verhelst writes:
> On Tue, Aug 11, 2020 at 10:05:42AM -0700, Russ Allbery wrote:
>> Wouter Verhelst writes:
>>> -policy: this is a question that has come up before
>>> (https://lists.debian.org/debian-devel/2016/12/msg00470.html is
>>> another example
failed-upgrade
> Please, update the relevant section to mention those new arguments.
Here is a patch that I believe implements that, and which I think is ready
for seconds.
--
Russ Allbery (r...@debian.org) <https://www.eyrie.org/~eagle/>
>From 2260f7a3aafe93282860aad07b7d8c
Cyril Brulebois writes:
> Russ Allbery (2022-09-19):
>> but I suspect that, to the extent that this is a Policy issue, the problem
>> was that a source package is not itself a udeb and therefore it wasn't clear
>> whether Policy applies to source packages that only p
ne. (Additionally, not
> sure why this would need to go to debian-devel -- seems like a Policy
> team-internal thing.)
Yes, good point, I'm not sure why I was thinking that we needed to discuss
it on debian-devel first.
Okay, not sure when I will get around to kicking it off, but I have
by them.
> If I were to redo such a specification from scratch, I would ask
> non-European language speakers their opinion too.
I'm definitely interested in that opinion from anyone who is listening in!
--
Russ Allbery (r...@debian.org) <https://www.eyrie.org/~eagle/>
? If people do think this is a good idea, I'll
bring it up on debian-devel for further discussion (and then, if we
adopted it, it would be a debian-devel-announce post).
--
Russ Allbery (r...@debian.org) <https://www.eyrie.org/~eagle/>
readers. But that's a fix for another day.
> I've gone one by one, but please review carefully as I might have
> perhaps switched in excess!
Reviewed, and also checked for remaining uses of "paragraph." Everything
looked good.
--
Russ Allbery (r...@debian.org) <https://www.eyrie.org/~eagle/>
Holger Levsen writes:
> On Mon, Sep 19, 2022 at 09:29:36PM -0700, Russ Allbery wrote:
>> I'm fine with this change, but as Sam points out, the deeper point here
>> is that Policy doesn't apply to udebs. This is the whole point of
>> udebs.
> When you say it like this, i
his paragraph in 1.1 (Scopes):
udebs (stripped-down binary packages used by the Debian Installer) do
not comply with all of the requirements discussed here. See the Debian
Installer internals manual for more information about them.
That could be as simple as saying "udebs (...) and source packages that
produce only udebs do not comply"
--
Russ Allbery (r...@debian.org) <https://www.eyrie.org/~eagle/>
I feel like we should stress that
you may put your system into a surprising state by removing required
packages, and may have difficulties recovering because standard tools are
missing, even though dpkg should continue to wrok.
Do you have any suggestions for what an accurate statement would be?
--
Russ Allbery (r...@debian.org) <https://www.eyrie.org/~eagle/>
nk it's up to you whether you think that is important or
not. I would be inclined to say that it's *safe* to add DPKG_ROOT to
paths even on upgrade actions, but you only *must* do so for maintainer
script actions that run during initial installation.
Thank you very much for starting th
tely open to patches here, and I agree that the
current Policy specification for Maintainer is both underspecified and
somewhat obsolete, but I think the patches should be conservative and not
introduce the stuff that RFC 5322 allows in headers but that we currently
don't support.
--
Russ Allbery (r...@debian.org) <https://www.eyrie.org/~eagle/>
Russ Allbery writes:
> The killer features of YAML for the purposes of the copyright format are
> the > and | symbols after a key, which let you write paragraphs of text
> afterwards with normal structural indentation and full editor support
> for wrapping and the like, and
ing to look entirely invalid.
I knew the backward compatibility issues were going to be a whole can of
worms.
--
Russ Allbery (r...@debian.org) <https://www.eyrie.org/~eagle/>
Wouter Verhelst writes:
> On Sun, Sep 18, 2022 at 06:01:38PM -0700, Russ Allbery wrote:
>> Yes, we should distinguish between formatted text with synopsis and
>> formatted text without synopsis more clearly. Or, you know, just
>> propose a new YAML format which would make i
are you thinking of some sort of
container or other type of restricted system?
Also, in this case, how does this work? Is the path somehow remapped at
the kernel level? (If so, I'm wondering if that would qualify as "made
available" for the purposes of Policy anyway.)
--
Russ Allbery (r...@debian.org) <https://www.eyrie.org/~eagle/>
In the case of a sponsored upload, the uploader signs the files, but
> the changelog maintainer name and address are those of the person who
> ]]]
--
Russ Allbery (r...@debian.org) <https://www.eyrie.org/~eagle/>
her way, we should
address this in the Policy wording, and then encode that in
dh_installtmpfiles if needed.
--
Russ Allbery (r...@debian.org) <https://www.eyrie.org/~eagle/>
e more second. Ideally, I'd like this to be someone else who
has a lot of understanding of the semantics of essential packages
(Guillem, for instance). Alas, due to the ordering of the BTS actions,
you may have to hunt down the cloned bug against debian-policy to second
it.
--
Russ Allbery (r..
gement. Old-school window managers that don't use a desktop
environment (fvwm2, for instance) may implement support for desktop files,
or for the Debian menu system for that matter; newer ones are likely to
not handle menus at all and expect some other component to deal with that.
--
Russ Allbery (r...@debian.org) <https://www.eyrie.org/~eagle/>
mething else entirely will
happen. This is really outside of our control.
--
Russ Allbery (r...@debian.org) <https://www.eyrie.org/~eagle/>
oticed that this formatting is technically incorrect.
I think it would be fine to leave them and have this be fixed by a future
format change, even if it takes a while.
--
Russ Allbery (r...@debian.org) <https://www.eyrie.org/~eagle/>
Guillem Jover writes:
> On Sun, 2022-09-18 at 22:56:16 +0200, Guillem Jover wrote:
>> On Sun, 2022-09-18 at 10:58:20 -0700, Russ Allbery wrote:
>>> Russ Allbery writes:
>>>> I would happily apply a version of 0002 that only changes Files and
>>>> leave
ne wrapping
semantics for line-based lists, which adds yet more irritating ugliness to
the deb822 format. Probably just "if the line is indented by more than
one space, it's a continuation for the previous line" I guess.
--
Russ Allbery (r...@debian.org) <https://www.eyrie.org/~eagle/>
ackage paragraph» and «binary package paragraph»
> (of the «template control file») sound instead?
As mentioned in the other thread, I think source package stanza and binary
package stanza (of the template control file) sound great.
Obviously a patch to Policy would be delightful, but it's not
or Policy to do.
I vote for switching to stanza. Paragraph is going to be confusing when
talking about package descriptions, which often have multiple paragraphs
in the normal English meaning of the term.
--
Russ Allbery (r...@debian.org) <https://www.eyrie.org/~eagle/>
Guillem Jover writes:
> Another minor patch I had laying around, switching references to the
> OpenPGP specification instead of to the specific PGP implementation.
Thanks, applied.
--
Russ Allbery (r...@debian.org) <https://www.eyrie.org/~eagle/>
Russ Allbery writes:
> I would happily apply a version of 0002 that only changes Files and
> leaves Copyright alone.
Or, perhaps even better, one that changes Copyright the way that you did,
but just adds an extra space. I think that's the simplest compromise
between what you're
gaps.)
I would happily apply a version of 0002 that only changes Files and leaves
Copyright alone.
--
Russ Allbery (r...@debian.org) <https://www.eyrie.org/~eagle/>
ut I'm happy to convert these to some
> of the UTF-8 ones if you prefer.
Thank you! Applied for the next release.
I have a minor bias against the UTF-8 quotes only because they're more
annoying to type with a typical US keyboard, while agreeing that they're
typographically more correct.
--
o aligning with them, but SPDX
still has a ton of work to do to absorb all of the licenses in Fedora,
which will help us when we're ready to do a switch. (But I would
definitely use SPDX identifiers where there isn't a Debian standard to
follow, since it will make that switch easier.)
--
Russ Allbery (r...@debian.org) <https://www.eyrie.org/~eagle/>
g about this jumps
out as a problem, so seconded. This seems like an appropriate use of a
virtual package because this is a fairly broad-ranging interface that will
require coordination between separate packaging teams (such as the GNOME
and KDE teams).
--
Russ Allbery (r...@debian.org) <https://www.eyrie.org/~eagle/>
think we should prefer:
Package: libdbus-1-3
Description: simple interprocess messaging system (library)
The runtime D-Bus library for use by applications.
.
D-Bus is a message bus, used for sending messages between applications.
[the real Description goes into more de
synopsis and using the same long description is all that
bad or something we should worry about discouraging.
--
Russ Allbery (r...@debian.org) <https://www.eyrie.org/~eagle/>
paragraph explaining
that source packages may have descriptions as well, but are not required
to.
--
Russ Allbery (r...@debian.org) <https://www.eyrie.org/~eagle/>
ke that: the package metadata says to build it as non-root,
which means that if it doesn't build as non-root, that's a FTBFS bug.
Anyway, it all seems to be sorted out now, and I suspect the root problem
was some benign misunderstanding of the root cause Vincent's bug report.
--
Russ Allbery (r.
re must be some difference in
the build environment for Daniel and Vincent or postfix would have always
refused to build, but I'm not sure what that is.
(In any case, I'm fairly convinced this isn't a Policy bug, although it
sounds like the wording for R³ in Policy could be improved somewhat.)
--
Russ
Vincent Lefevre writes:
> On 2021-12-25 14:48:33 -0800, Russ Allbery wrote:
>> Vincent Lefevre writes:
>>> Here, the build via "debuild" is failing even when fakeroot is
>>> available (installed on the machine). Note that Rules-Requires-Root
>>> has
quot;, being root or using fakeroot should not be required.
It does already.
no: Declares that neither root nor fakeroot is required. Package
builders (e.g. dpkg-buildpackage) may choose to invoke any target in
debian/rules with an unprivileged user.
Am I missing som
is bug (with a
documentation patch).
--
Russ Allbery (r...@debian.org) <https://www.eyrie.org/~eagle/>
sts, because this should be handled external to adduser.
If a user should have a nonexistent home directory, --home /nonexistent
should be passed to adduser.
--
Russ Allbery (r...@debian.org) <https://www.eyrie.org/~eagle/>
/lib64``
> +or in a subdirectory of it.
> The requirement for C and C++ headers files to be accessible through
> the search path ``/usr/include/`` is amended, permitting files to be
Seconded. Thanks, Sean.
--
Russ Allbery (r...@debian.org) <https://www.eyrie.org/~eagle/>
a subtlety that I had completely failed to grasp and didn't
realize this was way the rule was worded the way it was. Sorry for that
mistake; we should revert it.
If we separately want to drop this in favor of pure multiarch, that's
great and we can always reflect that later, but we shouldn't make that
on), since I want to try to dig through the Policy backlog for places
where we're blocking progress (which I don't think is true here). But
even if we don't tackle this soon, I think this is a great statement of
the issues.
--
Russ Allbery (r...@debian.org) <https://www.eyrie.org/~eagle/>
Sam Hartman writes:
>>>>>> "Russ" == Russ Allbery writes:
> Russ> Here is an updated diff that documents the most
> Russ> well-understood version conventions in the Debian archive.
> Russ> More could certainly be added; this is
David Bremner writes:
> Russ Allbery writes:
>> Currently, Debian Policy is silent on when it's appropriate to use a
>> native package, but there may be a project consensus aganist using
>> native packages when the software has an existence outside of Debian.
> Persona
Package: debian-policy
Version: 4.5.1.0
Severity: wishlist
Currently, Debian Policy is silent on when it's appropriate to use a
native package, but there may be a project consensus aganist using
native packages when the software has an existence outside of Debian.
Even if that consensus does not
Attached is a proposed
diff. This is on top of the diff for #682347; it's separable, but I'd
prefer to get that seconded and merged first.
Note that, based on your research, this will make e3 RC-buggy. (Obviously
this wouldn't be RC for this upcoming release.)
--
Russ Allbery (r...@debian.org)
is a bit out of scope.
I'll therefore propose that we move the discussion of whether to give
stronger advice on when to use native packages to a separate bug. Once
this is merged, there will be some text in Policy defining native
packages, so it will be easier to work on that.
Sound good?
his. I wasn't aware this convention existed.
Here's a new draft, which is unfortunately quite a bit longer because it's
hard to make this clear. I also added the +really convention explicitly,
since it's mentioned immediately above, and noted that the stable update
and backport conventions can, in
think this change is ready for seconds.
--
Russ Allbery (r...@debian.org) <https://www.eyrie.org/~eagle/>
diff --git a/policy/ch-controlfields.rst b/policy/ch-controlfields.rst
index a21a510..cd7daaa 100644
--- a/policy/ch-controlfields.rst
+++ b/policy/ch-controlfiel
NG, COPYING OR OTHERWISE
USING UNICODE INC
and only found 26 packages. I'm not sure that's enough to warrant
inclusion in common-licenses.
--
Russ Allbery (r...@debian.org) <https://www.eyrie.org/~eagle/>
Russ Allbery writes:
> 2. Document editor and recommend everyone implement it properly. Since
>we're going to allow packages to depend on editor, I think providing
>it would need to be a should, so that's going to be a lot of buggy
>(but not RC-buggy) editor packages.
documented in policy.
Reminder that this proposed patch needs one more second to be merged into
the next release of Policy.
--
Russ Allbery (r...@debian.org) <https://www.eyrie.org/~eagle/>
diff --git a/policy/ch-controlfields.rst b/policy/ch-controlfields.rst
index a21a510..
Russ Allbery writes:
> In attempting to revise recent GRs to use the same terminology as
> Policy, I got frustrated again by the lack of precision of our current
> language. This is an attempt to make a minor improvement. It doesn't
> go all the way to using all-caps terms the
well.
> +Manual pages for protocols and other auxiliary things are optional.
>
> If no manual page is available, this is considered as a bug and should
> be reported to the Debian Bug Tracking System (the maintainer of the
Seconded.
--
Russ Allbery (r...@debian.org) <https://www.eyrie.org/~eagle/>
ne.)
Here's the circular from the US Copyright Office on notices, for whatever
it's worth:
https://www.copyright.gov/circs/circ03.pdf
--
Russ Allbery (r...@debian.org) <https://www.eyrie.org/~eagle/>
worth, I've never assumed we can coalesce years in a way
that drops gaps, and never have done so myself, so it's obvious that we
should write something down since two people who have both worked in
Debian for a very long time had different understandings of what was
allowed. :)
--
Russ Allbery (r..
of
silly.
Therefore, where I personally land is that we should try to make the
Policy guidance correct (but as simple as possible), and then we should
not care if people don't exactly follow it because in truth it's not going
to matter.
--
Russ Allbery (r...@debian.org) <https://www.eyrie.org/~eagle/>
u're allowed to coalesce copyright
statements from multiple files into a single copyright notice as long as
all of the listed authors and years are covered.
--
Russ Allbery (r...@debian.org) <https://www.eyrie.org/~eagle/>
rominant (and make it clear that it's normative), and tweak the
wording.
--
Russ Allbery (r...@debian.org) <https://www.eyrie.org/~eagle/>
Guillem Jover writes:
> On Tue, 2020-08-04 at 13:56:45 -0700, Russ Allbery wrote:
>> I assume this is in support of systems, containers, or jails where UID
>> 0 may not have CAP_FOWNER?
> If that's the reason, it certainly was not clear from the original
> report. :)
It s
n strategy coordinated across multiple
packages, since this behavior is encoded in a lot of places. Maybe it
would make sense for Guillem to weigh in first and indicate whether this
would be a problem on the dpkg side and if he sees any concerns. Copying
debian-dpkg@lists for that.
--
Russ Allbery
maintainer view consistent (such as dgit). I suspect
it is therefore not the solution Ian is looking for.
--
Russ Allbery (r...@debian.org) <https://www.eyrie.org/~eagle/>
Debian-Uploaders` as well.
Similarly this seems to be entirely a question for Ubuntu (and Lintian, of
course).
--
Russ Allbery (r...@debian.org) <https://www.eyrie.org/~eagle/>
, in:
If punctuation is desired between the date components, remember that
hyphen (``-``) cannot be used in native package versions.
the "cannot" is not a normative Policy requirement, just a description of
a logical consequence of a definition stated earlier.
--
Russ Allbery (r...@debian.org) <https://www.eyrie.org/~eagle/>
uses a common
shell utility declare a dependency on coreutils, despite being a nice way
to remove some special cases and make the dependency structure more
explicit, may be a bit too tedious to want to endure.)
--
Russ Allbery (r...@debian.org) <https://www.eyrie.org/~eagle/>
strong sense.
Do you have a suggestion for alternative wording? I think we still need
to say something about matching the name of the init script if any, and if
upstream doesn't provide a service unit, it seems reasonable to use the
name of the package (but maybe that should be encouraged rather
plicit exception for users starting with systemd-*, since we're
unlikely to rename those and it seems reasonable to reserve that namespace
for the systemd project (which is somewhat unique in the number of
low-level users that it wants to create). But we can deal with that in a
separate bug
"""
> The Perl code is invalid. There is missing a 0 after "==" and before
> "or die(...)".
Thanks! Fixed for the next release.
--
Russ Allbery (r...@debian.org) <https://www.eyrie.org/~eagle/>
lly no chance whatsoever that Debian will pursue formal
POSIX validation. Among other things, it costs substantial amounts of
money (since this is how the relevant organization supports itself), which
Debian is highly unlikely to spend on that purpose.
--
Russ Allbery (r...@debian.org)
on that list. There's more information here:
https://unix.stackexchange.com/questions/522413/why-are-most-linux-distributions-not-posix-compliant
--
Russ Allbery (r...@debian.org) <https://www.eyrie.org/~eagle/>
s a bit far afield of this specific change.
Please file a separate bug against debian-policy if you think this is a
good idea so that we can track it. Thanks!
--
Russ Allbery (r...@debian.org) <https://www.eyrie.org/~eagle/>
the
> netplan allocation? Yes, it's a bit arbitrary, but also not really all
> that stingy, and base-passwd's allocations are meant to be permanent
> even if the package has been removed (since we can never guarantee that
> it's been removed from users' systems).
This sounds goo
he ranges specified in ``adduser.conf``.
>> +based on the ranges specified in ``adduser.conf``. Usernames in this
>> +range should be prefixed with an underscore.
I think this is too strong, since it implies that all packages that
already create users should change, and I don't think we've thought
through the implications of that yet.
--
Russ Allbery (r...@debian.org) <https://www.eyrie.org/~eagle/>
d will change this in my draft
version to "The Release Team can".
--
Russ Allbery (r...@debian.org) <https://www.eyrie.org/~eagle/>
ersion. Other folks
reviewing this patch, please consider that change as made when deciding
whether to second (and let me know if you object to that change).
Thank you for the review!
--
Russ Allbery (r...@debian.org) <https://www.eyrie.org/~eagle/>
mendation was added don't need to change
the name of that user (until we figure out a migration strategy).
--
Russ Allbery (r...@debian.org) <https://www.eyrie.org/~eagle/>
Package: debian-policy
Version: 4.4.1.2
Severity: important
Per recent (non-BTS) discussion, this patch is a first draft at
reconciling Policy with the recent GR result. Summary of changes:
* Change section headings and anchors to reflect the more general topic
* Add recommended naming
ke saying this straightforward, but I'm
taking a look now and will create a bug with a patch for discussion and
review.
--
Russ Allbery (r...@debian.org) <https://www.eyrie.org/~eagle/>
irements to
recommendations.
--
Russ Allbery (r...@debian.org) <https://www.eyrie.org/~eagle/>
Russ Allbery writes:
> I agree, but let's also fix existing incorrect wording. I reviewed
> every instance of may and optional in Policy, and I think this larger
> diff will make wording (mostly) consistent. I've tried not to change
> the sense of any of these Policy statements
Sean Whitton writes:
> On Sun 17 Nov 2019 at 05:48PM -08, Russ Allbery wrote:
>> is being used.) You must not include the ``/etc/rcn.d`` directories
>> -themselves in the archive either. (Only the ``sysvinit`` package may do
>> -so.)
>> +themselves in the archive eith
em would require changes to dpkg, apt, and aptitude; I don't think
package dependencies, even used creatively, will quite work here.
--
Russ Allbery (r...@debian.org) <https://www.eyrie.org/~eagle/>
Stephen Kitt writes:
> I’m attaching a revert and an update to the footnote (against the next
> branch):
Thanks! Applied for the next release.
--
Russ Allbery (r...@debian.org) <https://www.eyrie.org/~eagle/>
f a version string:
> >>> apt_pkg.version_compare('1~', '1~0')
> 0
That's also a good thing to mention. There are some oddities with -0 as a
Debian revision too, if I remember correctly.
Could someone open a bug against debian-policy for this so that we don't
lose track and can hash out some of
I believe
> it could be avoided by having it as a policy and changing uscan to
> follow it.
I'd have to hear more about the specific use case you had in mind. uscan
already supports @DEB_EXT@ and dversionmangle=auto, which I think does a
lot of what you want.
--
Russ Allbery (r...@debian.org) <https://www.eyrie.org/~eagle/>
Russ Allbery writes:
> Right, what I think is in scope for Policy is advising packagers on
> which readiness signaling mechanism to use if upstream supports several.
> If one is relatively new to packaging daemons, this may not be something
> on one's radar to look at, but there are
Simon McVittie writes:
> On Sun, 29 Dec 2019 at 10:47:44 -0800, Russ Allbery wrote:
>>We probably also want to recommend Type=notify where possible and
>>Type=exec where not, over Type=forking, when the daemon supports
>>that.
> I'm not sure what you mean by
101 - 200 of 2062 matches
Mail list logo
