Package: debian-policy
Version: 4.7.0.1
Severity: normal
X-Debbugs-Cc: r...@debian.org
Policy defines configuration files as:
A file that affects the operation of a program, or provides site- or
host-specific information, or otherwise customizes the behavior of a
program. Typically, c
itored by humans. For concrete user issues, prefer bug reports
> against the 'git-debpush' package. For miscellaneous queries, write
> to .
I agree with the request for this mailing list. An archived place to send
these notices will help considerably with any later security
I blame it on network gear that has only
ever been tested with HTTP traffic and has no idea what to do with
long-lived persistent TCP connections that don't have constant traffic.
--
Russ Allbery (r...@debian.org) <https://www.eyrie.org/~eagle/>
implications (I think the
permissions are more precautionary, and it's also fairly unlikely that
anyone will have installed krb5-wallet before krb5-kdc), although Sam,
please let me know if you think I'm wrong.
krb5-wallet has never been in a stable release, so no worries about stable
fixes.
--
Russ Allbery (r...@debian.org) <https://www.eyrie.org/~eagle/>
Package: wnpp
Severity: normal
X-Debbugs-Cc: gn...@packages.debian.org, r...@debian.org
Control: affects -1 + src:gnubg
I intend to orphan the gnubg package. The package is in good shape, but
I rarely use it and am not the best person to continue to maintain it.
The package description is:
GNU B
Russ Allbery writes:
> Sure, no problem. I'll file a bug against dash.
#1007263 had already been filed and was on a very similar topic, so I have
added some supplemental information to that bug report.
--
Russ Allbery (r...@debian.org) <https://www.eyrie.org/~eagle/>
Package: dash
Version: 0.5.12-9
Followup-For: Bug #1007263
X-Debbugs-Cc: r...@debian.org
This topic came up in Policy bug #1074014. It sounds like there is a plan
to document the transition in the release notes, but, going forward, the
mechanism to change the shell underlying /bin/sh sounds like i
f files in the data.tar of a .deb. All of the protective
> diversions that we ever installed for DEP17 are managed in maintainer
> scripts and dh_movetousr does not touch maintainer scripts at all.
Ah! Thank you.
> Your reasoning makes sense to me. I do not intend to work on this
> matter, b
il dpkg can gain full understanding of the path aliasing.
--
Russ Allbery (r...@debian.org) <https://www.eyrie.org/~eagle/>
int to bash directly.
--
Russ Allbery (r...@debian.org) <https://www.eyrie.org/~eagle/>
ere are two occasions where this could be seen as having been vetted.
> One is elaborate discussions on d-devel with consensus summaries that
> have not been objected to. The other is a transition bug that has been
> acknowledged by the release team. In any case, I do not think w
at needs to be
analyzed and appropriately addressed, but in the typical case, no, the
files in the packages should move so that we get to the more predictable
and easier-to-reason-about end state that was the goal of the migration
fix adopted by the CTTE.
--
Russ Allbery (r...@debian.org) <https://www.eyrie.org/~eagle/>
x27;m guessing that you're anticipating some problem related to
diversions, but I can't put the pieces together without some more details.
--
Russ Allbery (r...@debian.org) <https://www.eyrie.org/~eagle/>
you're using any
mechanism other than the simple password ones. See Authen::SASL::Perl:
As for server support, only *PLAIN*, *LOGIN* and *DIGEST-MD5* are
supported at the time of this writing.
--
Russ Allbery (r...@debian.org) <https://www.eyrie.org/~eagle/>
one aspect of the
lifecycle, but still does not achieve the semantics you're arguing for in
the abstract.
--
Russ Allbery (r...@debian.org) <https://www.eyrie.org/~eagle/>
Simon McVittie writes:
> On Fri, 02 Aug 2024 at 09:07:12 -0700, Russ Allbery wrote:
>> Luca Boccassi writes:
>>> It is correct as-is. VERSION_ID is meant to identify a release, not
>>> updates or point releases. A release as in, Debian Bookworm, or Fedora
>>
ling release with very
substantial caveats and limitations.
I do agree that it's often useful to be able to quickly determine if an
image is pointing to testing or to unstable.
> On Fri, 2 Aug 2024 at 04:00, Russ Allbery wrote:
>> Well, it's related to your example of the zoom
e use codenames in the archive structure and I am probably
overthinking this.
> What do you mean?!! It's right there!
> https://www.freedesktop.org/software/systemd/man/devel/os-release.html#RELEASE_TYPE=
> ...ok, ok, it's there now because I just merged it and regenerated the
> docs :-P
Thanks! This looks good to me.
--
Russ Allbery (r...@debian.org) <https://www.eyrie.org/~eagle/>
Right now, it
requires substantial effort to read any thread that you have replied to
because I have to brace myself for judgmental, emotionally loaded, and
hostile-sounding language that gets in the way of understanding the root
disagreement and having a cordial and constructive collaboration.
--
Russ Allbery (r...@debian.org) <https://www.eyrie.org/~eagle/>
ssion.
I did review the discussion #1021663 in the hope that I would find a
detailed technical proposal there, but your messages to that bug seemed to
focus on criticisms of the current behavior mixed with insults. I wasn't
able to find a proposal, but it's entirely possible I missed it.
Package: dh-debputy
Version: 0.1.43
Severity: normal
X-Debbugs-Cc: r...@debian.org
Module::Build, one of the common build systems for Perl modules, defaults
to installing Perl modules under /usr/share/perl5 read-only (mode 0444).
With debhelper, this could be ignored for Debian packaging, since
dh
NULL)
> +return errno;
> +
> +while ((entry = readdir(d)) != NULL) {
> (...)
readdir ordering is probably bad. I think that's essentially random on a
lot of file systems, and I'm not sure it's even guaranteed to be stable.
Is there any chance we could get that
and there's still the
basic problem that we can't guarantee that the include directive is
present.
> I was thinking about a breaks, as in, new krb5-config would break old
> heimdal.
Ah, yes, that makes sense. And then packages that need configuration
snippets can depend on the
not required to solve my problem in a separate
package. :) I was just hoping that it would.
--
Russ Allbery (r...@debian.org) <https://www.eyrie.org/~eagle/>
ly before including
them, so that there's some predictable order for which fragments override
each other? We'll want to document the ordering.
--
Russ Allbery (r...@debian.org) <https://www.eyrie.org/~eagle/>
c Kerberos
implementation, so I don't know how to represent this as a dependency.
And what dependency should a package that wants to use included
fragments have to ensure that those included fragments are loaded?
--
Russ Allbery (r...@debian.org) <https://www.eyrie.org/~eagle/>
uot; specifically:
https://docs.python.org/3/library/fractions.html
--
Russ Allbery (r...@debian.org) <https://www.eyrie.org/~eagle/>
t work is a level of complexity that we don't
need, and it doesn't, so far as I know, have a strong technical
justification.
--
Russ Allbery (r...@debian.org) <https://www.eyrie.org/~eagle/>
re ends up being disagreement, the TC should use its policy making
> powers and put this to bed.
I forgot about the TC involvement. This is a better answer than mine.
--
Russ Allbery (r...@debian.org) <https://www.eyrie.org/~eagle/>
. Given earlier disagreement on this matter, should we discuss this
> matter in a wider setting such as d-devel?
You certainly can, but at this late stage I don't think it would change
anything. We're already into mass-bug-filing territory and it's going to
be an RC bug,
princ_dns.html#openldap-ldapsearch-etc
(at the bottom of the page), which is not under the control of the
Kerberos libraries. It's a very long-standing issue in Cyrus SASL that
some of us used to patch locally.
--
Russ Allbery (r...@debian.org) <https://www.eyrie.org/~eagle/>
7;t, so we might be making those buggy if
> we just ban network access for all non-free packages. How about you?
Yup, let's go with Bill's change since it's a bit more conservative. I
think it accomplishes the same goal.
--
Russ Allbery (r...@debian.org) <https://www.eyrie.org/~eagle/>
y, which may be sufficient. Builds that use the network
seem like a bad idea even in non-free packages because it means we may not
be able to rebuild them since all of the relevant data is not in the
Debian source package.
--
Russ Allbery (r...@debian.org) <https://www.eyrie.org/~eagle/>
te outside of the unpacked
>> source package tree. There are two exceptions. Firstly, the binary
> LGTM, Seconded.
Also looks good to me. Seconded.
--
Russ Allbery (r...@debian.org) <https://www.eyrie.org/~eagle/>
should really be doing from Perl and the rest of it remains
somewhat useful, but given that upstream has archived the project, I would
go ahead and remove it.
Maybe someday I'll dust off and finish a proper Kerberos Perl module that
uses the modern C API. In my copius free time. :
Package: libarchive13t64
Version: 3.7.2-1.1
Severity: important
X-Debbugs-Cc: r...@debian.org
So far it looks like no one has been able to figure out an obvious way
for this to be exploitable, but I wanted to make sure that you were
aware of this upstream issue:
https://github.com/libarchive/liba
ch is the real heart of the disagreement that at
some point we need to confront.
(I know, I know, I'm one to talk given that I dropped all my Policy work
on the floor and disappeared for six months. But still, I would give
myself the same advice.)
--
Russ Allbery (r...@debian.org) <https://www.eyrie.org/~eagle/>
ll ecosystem of packaging tools fits together. I
think the only way out for the /usr-merge transition specifically is
through, and until we finish that we're probably not in a good position to
absorb those lessons in a more comprehensive way, but I hope we don't skip
that step.
--
Russ
ntirely unsupported since July of 2017. I think one can make a good
argument that both the Lintian tag description and xymon should just drop
all support for Apache versions prior to 2.4. Hopefully no one is still
running it, since it almost certainly has significant unfixed security
vulnerabi
dy
been consumed and hashed with the default hash algorithm, and the correct
hash is no longer available.
I believe what hash algorithm GnuPG uses by default is controlled by local
GnuPG configuration, and it may well default to SHA-256 these days.
Also, all of these modules should swi
to put this metadata and thus it is always
lost.
perl-nocem itself doesn't seem to care and just copies the whole input
into a temporary file for GnuPG. What's the nature of the failure? Is
GnuPG failing to validate the resulting file if the hash algorithm is
omitted?
--
Russ All
or Debian packages. As soon as DAK doesn't
require it, I'm happy to make it optional (and indeed it would arguably be
a bug in Policy if it's optional in the archive but Policy claims it's
mandatory).
--
Russ Allbery (r...@debian.org) <https://www.eyrie.org/~eagle/>
gregor herrmann writes:
> On Wed, 06 Sep 2023 08:21:24 -0700, Russ Allbery wrote:
>> gregor herrmann writes:
>>> According to https://github.com/rra/docknot/issues/6 fixed upstream
>>> (in git, not released yet).
>> Yeah, I'm sorry about the delay here.
also explicitly says that it's non-breaking (I believe that's
the case, although please tell me if I got that wrong) and is more
(perhaps excessively) explicit about distinguishing it from "-" because of
all the confusion about this.
--
Russ Allbery (r...@debian.org) <https://www.eyrie.org/~eagle/>
aphy (the hyphen-minus is one of 25 dashes in Unicode), you may want
to say that explicitly in addition to saying that it's the character used
in UNIX command-line options (and, arguably as importantly, in UNIX
command names).
--
Russ Allbery (r...@debian.org) <https://www.eyrie.org/~eagle/>
at have been turned
into \-. People will have to rewrite them using proper Unicode hyphens to
get proper formatting.
--
Russ Allbery (r...@debian.org) <https://www.eyrie.org/~eagle/>
Bastian Germann writes:
> Am 14.10.23 um 21:41 schrieb Russ Allbery:
>> Upstream specifically says that the Gtk-3 support is buggy, does not
>> work, and should not be used. How thoroughly did you test it?
> I have played a round against the computer and have not seen a prob
horoughly did you test it?
--
Russ Allbery (r...@debian.org) <https://www.eyrie.org/~eagle/>
gram. This bug would have caused the type of corruption that I saw in
> Russ's database, so I'm pretty sure it will go away in 4.2.
I installed 4.2 locally and then did an apt upgrade and everything worked
correctly, so I am also hopeful. 4.2 is on its way to experimental now.
Package: apt-listchanges
Version: 4.1
Severity: normal
X-Debbugs-Cc: r...@debian.org
As of apt-listchanges 4.1, if I suspend the less command showing the
report with Ctrl-Z and then resume with fg or %, the terminal state
is incorrect. The report screen is not refreshed, Ctrl-L doesn't work,
and q
I need to see yours.
I'm sending you this via direct mail. I'm now seeing the problem with
each apt upgrade (in other words, I feel like 4.1 might be worse than 4.0,
which seemed to exhibit the problem only with some packages).
--
Russ Allbery (r...@debian.org) <https://www.eyrie.org/~eagle/>
Package: apt-listchanges
Version: 4.1
Severity: normal
X-Debbugs-Cc: r...@debian.org
Looks like some variation of this bug still exists in 4.1, although I'm
not sure if it's the same bug. But the following upgrades:
Unpacking golang-1.21-doc (1.21.3-1) over (1.21.2-1) ...
Unpacking golang-1.21-sr
Jonathan Kamens writes:
> Not the same bug. #1053696 only applies to changelog entries, not NEWS
> entries, since the latter can't be downloaded via apt.
> I am thus far unable to reproduce this. Still investigating.
Ah, whoops, sorry, I wasn't reading carefully enough.
e same problem.
--
Russ Allbery (r...@debian.org) <https://www.eyrie.org/~eagle/>
the network if
apt-listchanges exhausted the changelog shipped with the package and still
couldn't find the beginning of the entries it wanted to display.
--
Russ Allbery (r...@debian.org) <https://www.eyrie.org/~eagle/>
Package: apt-listchanges
Version: 4.0
Followup-For: Bug #1053696
X-Debbugs-Cc: r...@debian.org
Same thing happened with the following upgrades:
Unpacking gcc-12 (12.3.0-10) over (12.3.0-9) ...
Unpacking libgcc-12-dev:amd64 (12.3.0-10) over (12.3.0-9) ...
Unpacking cpp-12 (12.3.0-10) over (12.3.0-
Package: apt-listchanges
Version: 4.0
Severity: normal
X-Debbugs-Cc: r...@debian.org
An apt run that included the following upgrades:
Unpacking python3.11-dev (3.11.6-3) over (3.11.6-2) ...
Unpacking libpython3.11-dev:amd64 (3.11.6-3) over (3.11.6-2) ...
Unpacking libpython3.11:amd64 (3.11.6-3) o
chain have even less information
and are even less suited to making this decision. Of those two options,
having apt-listchanges do it would be less obscure (it's not immediately
obvious that apt could run less), although possibly surprising.
--
Russ Allbery (r...@debian.org) <https://www.eyrie.org/~eagle/>
EWS.Debian files, not the full changelog. Any new
NEWS.Debian file entry for a package that you have installed is generally
worth reading, and this is the supported way (other than the Release Notes
for the full stable release) that Debian communicates major breaking
changes like this to u
s is a problem created by the maintainer and overriding the
maintainer will not help. Someone will have to do this work, and it is
very far from trivial.
--
Russ Allbery (r...@debian.org) <https://www.eyrie.org/~eagle/>
Niels Thykier writes:
> Russ Allbery:
>> Ooo, this is a great framing of the problem. I have a lot of thoughts
>> about this. Unfortunately, I'm not sure if they're actionable thoughts
>> since my grand vision requires someone to sit down and do some serious
>
ion. I think
Policy should primarily have an audience of packagers, including packagers
who need to coordinate cross-package integrations, secondarily have an
audience of tool makers who need a reference manual for Debian's file
formats and integrations, and then have a deprioritized tertiary audience
of toolchain maintainers.
--
Russ Allbery (r...@debian.org) <https://www.eyrie.org/~eagle/>
similar directory, and then cruft could
just consume that database of registered paths to get attribution
information until such time as that can move into dpkg.
This design is just off the top of my head, and I'm probably missing some
problems and some details.
--
Russ Allbery (r...@debian.org) <https://www.eyrie.org/~eagle/>
hile (we have a special exception in the FHS for it because it's breaking
the FHS file system layout rules), and there have been a few attempts to
handle it some other way, but none of them so far have been successful.
--
Russ Allbery (r...@debian.org) <https://www.eyrie.org/~eagle/>
ns around /var being fixed and
> package-managed is already creating some headaches, and requiring
> workarounds.
Specifics! Specifics! My kingdom for specifics! :) Bug numbers for
these headaches would be helpful, or detailed descriptions, or
*something*. You're giving me nothing to work with here, which means that
I'm likely to go forward with requiring some of these empty directories be
registered with dpkg because that's the less invasive change and avoids a
regression.
--
Russ Allbery (r...@debian.org) <https://www.eyrie.org/~eagle/>
feel like we need to wait for the TC bug to be resolved,
since there is a standing TC decision to make /bin a symlink to /usr/bin
and we can always change our wording later if that decision changes, but
we need to wait for the buildd /usr-merge anyway, so either way I don't
think we'r
Bill Allombert writes:
> On Sun, Sep 17, 2023 at 10:41:55AM +0200, Marco d'Itri wrote:
>> On Sep 17, Russ Allbery wrote:
>>> (I am a little confused by this wording, but I think what you're
>>> saying is that /usr is encrypted and read-only, and /var is
that's great,
> and even more reasons not to change policy for something that would
> only be a temporary stop-gap.
I'm not going to assume that this is going to happen on any particular
time scale. dpkg has to gain a mechanism for registering transient files
first, which in my understanding depends on other significant dpkg
architectural work.
--
Russ Allbery (r...@debian.org) <https://www.eyrie.org/~eagle/>
ion. Does anyone know if that
integration has already been done to invoke systemd-tmpfiles during boot
on systems using sysvinit?
--
Russ Allbery (r...@debian.org) <https://www.eyrie.org/~eagle/>
iced was that the version number of Policy
in the left sidebar at the top is very difficult to read because it's
almost the same color as the background.
--
Russ Allbery (r...@debian.org) <https://www.eyrie.org/~eagle/>
the PATH stays
consistent from one build to the next.
--
Russ Allbery (r...@debian.org) <https://www.eyrie.org/~eagle/>
e the most about and would like to say
explicitly somewhere in Policy, even though that's beyond the scope of
Luca's original report.
I don't think Policy says anything about /usr-merge at all right now, and
once the buildds are merged and all Debian systems relevant to unstable
development are /usr-merged, we probably should.
--
Russ Allbery (r...@debian.org) <https://www.eyrie.org/~eagle/>
ame question about how to talk about those paths in Policy. I
therefore don't think resolution of this bug blocks on the TC bug.
--
Russ Allbery (r...@debian.org) <https://www.eyrie.org/~eagle/>
Luca Boccassi writes:
> On Wed, 13 Sept 2023 at 04:48, Russ Allbery wrote:
>> Simon pointed out that this bug is not yet ready to act on, which was
>> very helpful. Thank you. However, presumably the buildds will be
>> /usr-merged at some point in the not-too-distant f
e latter is my guess about where we're
headed based on previous discussions).
--
Russ Allbery (r...@debian.org) <https://www.eyrie.org/~eagle/>
Russ Allbery writes:
> Russ Allbery writes:
>> Maybe the right way to do this is just have two examples, one as the
>> default and another if you're using tmpfiles.d functionality added in a
>> specific version of systemd that's newer than the version shippe
Russ Allbery writes:
> Maybe the right way to do this is just have two examples, one as the
> default and another if you're using tmpfiles.d functionality added in a
> specific version of systemd that's newer than the version shipped with
> the stable version of Debian p
ete goal in mind for what that requirement or recommendation is going
to achieve.
--
Russ Allbery (r...@debian.org) <https://www.eyrie.org/~eagle/>
y 1024 and rounded up.
> +The disk space is given as the accumulated size of each regular file and
> +symlink rounded to 1 KiB used units, and a baseline of 1 KiB for any other
> +filesystem object type.
>
> .. _s-f-Files:
--
Russ Allbery (r...@debian.org) <https://www.eyrie.org/~eagle/>
since
they help explain to the reader how Debian is designed beyond just a
mechanical set of instructions.
If you have a chance, feel free to send a proposed diff to add this to the
DEB_BUILD_OPTIONS section.
--
Russ Allbery (r...@debian.org) <https://www.eyrie.org/~eagle/>
nse text because it varies. At least if I understand
what our goals would be.
(License texts that have portions that vary between packages they apply to
are a menace and make everything much harder, and I really wish people
would stop using them, but of course the world of software development is
not going to listen to me.)
--
Russ Allbery (r...@debian.org) <https://www.eyrie.org/~eagle/>
he debian/copyright file, though. If we
take this approach, we'll need to be very explicit that you can only use
whatever triggers the automatic inclusion of the license text if your
license text is word-for-word identical. Otherwise, you'll need to cut
and paste it into the fi
without using one of the force options).
(And while we're there, we don't document the Build-Essential field
either.)
--
Russ Allbery (r...@debian.org) <https://www.eyrie.org/~eagle/>
Sam Hartman writes:
>>>>>> "Luca" == Luca Boccassi writes:
> Luca> Thank you, looks good to me, seconded.
> LGTM too, seconded.
Thanks! This has now been merged for the next Policy release.
--
Russ Allbery (r...@debian.org) <https://www.eyrie.org/~eagle/>
Guillem Jover writes:
> Seconded.
Thanks! I think the wording changes subsequent to Sam's second are
informative and within the changes the Policy Editor can make without
seconds, so I'm proceeding with this and Sam's second and have merged this
change for the next Policy
ng long lines with
lots-of-words-that-are-all-conncted-by-hyphens, although that's somewhat
rare.
My opinion is that the world of documents that are handled by man do not
encode meaningful distinctions between - and \-, and man should therefore
unify those characters.
--
Russ Allbery (r...@debian.org) <https://www.eyrie.org/~eagle/>
is "here's a bunch of complex things you
need to do but if you follow these instructions instead of using debhelper
your package will be buggy." This is not ideal!
I think there's a lot of appeal of having a thorough specification for
what debhelper is supposed to be doing. It would enable future
competition around better packaging helpers (and I do think debhelper will
not be the last word). But I also want to be realistic about whether
we're really capable of maintaining that specification.
--
Russ Allbery (r...@debian.org) <https://www.eyrie.org/~eagle/>
Antoine Beaupré writes:
> On 2023-09-11 11:25:34, Russ Allbery wrote:
>> Antoine Beaupré writes:
>>> I get the argument against bad binaries not being in PATH but we have
>>> some tooling for that, don't we? /usr/libexec, no?
>> /usr/libexec isn't a
user's path but not
root's, which is a distinct use case.
Thanks, Simon and Bill. I had forgotten about that point even though it
has come up before (just not in this bug). I agree that's a more
compelling argument for keeping /usr/games.
--
Russ Allbery (r...@debian.org) <https://www.eyrie.org/~eagle/>
ompelling due to the increase in the size of disks (which is
only sort of keeping up with full commercial games, but is certainly
keeping up with the games packaged in Debian).
--
Russ Allbery (r...@debian.org) <https://www.eyrie.org/~eagle/>
or you based on the heading that you're linking to. (I think we are
excessively explicit in a bunch of places in Policy currently due to a
conversion artifact from DebianDoc-XML.)
--
Russ Allbery (r...@debian.org) <https://www.eyrie.org/~eagle/>
As usual, the things I notice only after I post text, even though I'd
already read it several times.
Russ Allbery writes:
> +Volatile and temporary files (``tmpfiles.d``)
> +-
> +
> +Some packages require empty directories, files wit
thing like that. Of course, the point may be
moot if upstream never ports GNU Backgammon to anything newer than Gtk+ 2,
and the chances of that port currently aren't looking great.
> But again, happy to shelve this for now, as it's a more complex topic.
Agreed, we don't
sts).
Thanks, that does seem like a good idea.
> But given that hard links in source packages do not seem prevalent at
> all, and that the tooling or linters can be improved in that direction I
> suppose it might make sense to lift this specific restriction.
Thank you for the revi
t. (Unfortunate, but oh well, too late now.)
Here is an updated patch that restructures this paragraph to try to make
this clearer.
--
Russ Allbery (r...@debian.org) <https://www.eyrie.org/~eagle/>
>From 516d0a327e247c35bd1bb95ff2a9bfc773f87c21 Mon Sep 17 00:00:00 2001
ecting that in source files, so it wouldn't know to include licenses
referenced in License stanzas without the license text included.
--
Russ Allbery (r...@debian.org) <https://www.eyrie.org/~eagle/>
e excessive. So maybe we
still need to do something with common-licenses?
--
Russ Allbery (r...@debian.org) <https://www.eyrie.org/~eagle/>
d, the script will need serious improvements.
That was something else I wanted to ask: I've invested all of a couple of
hours in this script, and would be happy to throw it away in favor of
something that tries to do a more proper job of classifying the licenses
referenced in debian/copyright
eview, and I might again have
> perhaps missed instances or similar.
All of these changes seem straightforward and uncontroversial to me, and
there are huge advantages to using consistent terminology between Policy
and dpkg. I have applied all of them for the next Policy release. Thank
you!
--
Russ Allbery (r...@debian.org) <https://www.eyrie.org/~eagle/>
Russ Allbery writes:
> It's now been about a year and it looks like this message didn't get a
> reply, so I'm going to go ahead and close this bug because I don't think
> we have enough information to act on it. If there are more details
> about my questions a
1 - 100 of 2617 matches
Mail list logo
