packages need at runtime have
to be installed outside of /usr/share/doc, with links to /usr/share/doc if
appropriate.
--
Russ Allbery (r...@debian.org) <https://www.eyrie.org/~eagle/>
e inverse case (moving the docs to /usr/share/doc and
> linking them back to where the software expects them)?
If the files are used at runtime, Policy requires installing the files
outside of /usr/share/doc and linking them to /usr/share/doc. See Policy
12.3, second-to-last par
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/>
Russ Allbery writes:
> Adrian Bunk writes:
>> ...
>> lib/network/server..MISSED 34-42 (killed by signal 14)
>> ...
>> Failed Set Fail/Total (%) Skip Stat Failing Tests
>> -- -- -
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/>
dopt new strategies for
packaging that make life simpler and easier for packagers and allow us to
keep pace with more upstream packages than to reduce scope to only the
things we already know we're good at.
--
Russ Allbery (r...@debian.org) <https://www.eyrie.org/~eagle/>
ks who picked 7).
--
Russ Allbery (r...@debian.org) <https://www.eyrie.org/~eagle/>
Package: libnss3
Version: 2:3.58-1
Severity: important
Control: affects -1 pidgin
libnss3 since 2:3.58-1 has broken TLS negotiation in Pidgin. There are
several reports (see the latest message in #790610 and the #973566 report
against pidgin). This is probably severity: serious against Pidgin,
sts=3631, 12.90 seconds (2.43 usr + 1.92 sys = 4.35 CPU)
> make[2]: *** [Makefile:38: test] Error 1
I'm working on a fix. It's unfortunately rather complicated because the
assumption that binding on any address will provide two sockets ran fairly
deep.
I think the problem only affects the
Package: libnss3
Version: 2:3.58-1
Followup-For: Bug #972713
I'm seeing the same problem when connecting to a stock buster ejabberd server
with a Let's Encrypt certificate and no special TLS configuration. Something
definitely changed between 2:3.56-1 and 2:3.58-1 and I'm dubious it's poor TLS
the buildds with only IPv6
addresses. Working on a fix, will try to get it uploaded soon since I
know a Python transition is coming.
--
Russ Allbery (r...@debian.org) <https://www.eyrie.org/~eagle/>
Russ Allbery writes:
> I had a package with control fields:
> Vcs-Git: https://salsa.debian.org/rra/libpgp-sign-perl.git
> Vcs-Browser: https://salsa.debian.org/rra/libpgp-sign-perl
Argh, sorry, that should have been:
Vcs-Git: https://salsa.debian.org/rra/libpgp-sign-perl
Vcs-Brows
Package: lintian
Version: 2.94.0
Severity: minor
I had a package with control fields:
Vcs-Git: https://salsa.debian.org/rra/libpgp-sign-perl.git
Vcs-Browser: https://salsa.debian.org/rra/libpgp-sign-perl
This produces the following Lintian diagnosis:
I: libpgp-sign-perl source:
rominant (and make it clear that it's normative), and tweak the
wording.
--
Russ Allbery (r...@debian.org) <https://www.eyrie.org/~eagle/>
Package: lintian
Version: 2.88.0
Severity: minor
Lintian produces a false-positive pedantic repeated-path-segment tag
for Perl modules that use File::ShareDir (a Perl mechanism to provide
static data files for a Perl module in a location that Perl can find
at runtime across all supported
nted format.
If we did that, I would probably ship this information in YAML rather than
in the somewhat ad hoc format of Lintian's data file (which was my fault
originally).
--
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
debhelper if you want to build the
unstable version of krb5.
--
Russ Allbery (r...@debian.org) <https://www.eyrie.org/~eagle/>
would be ideal if the tag were specific to the
underlying problem, but I would consider it reasonable to complain that
one cannot extract the section from that .TH line since groff cannot
either.
--
Russ Allbery (r...@debian.org) <https://www.eyrie.org/~eagle/>
Felix Lechner writes:
> On Wed, Jul 1, 2020 at 8:16 PM Russ Allbery wrote:
>> I'm puzzled by why you would have changed Lintian in response to that
>> bug, given that the reported problem was only with Lintian and was
>> fixed sixteen years ago.
> I am just working thro
with Lintian and was fixed
sixteen years ago.
What problem is this tag trying to address?
--
Russ Allbery (r...@debian.org) <https://www.eyrie.org/~eagle/>
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/>
/facts.d
> /etc/puppetlabs/facter/facts.d
> /opt/puppetlabs/facter/facts.d
Yup, confirmed that works. Thank you!
--
Russ Allbery (r...@debian.org) <https://www.eyrie.org/~eagle/>
Package: facter
Version: 3.11.0-4.1
Severity: grave
facter no longer works at all on amd64. When invoked, it dies with
an invalid pointer error:
% facter
free(): invalid pointer
Aborted (core dumped)
gdb backtrace:
#0 __GI_raise (sig=sig@entry=6) at ../sysdeps/unix/sysv/linux/raise.c:50
#1
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/>
ork given your follow-up message. Hopefully OpenSSL
will eventually release under an Apache 2.0 license, and then this can be
resolved by using OpenSSL directly.
--
Russ Allbery (r...@debian.org) <https://www.eyrie.org/~eagle/>
Russ Allbery writes:
> Sebastian Humenda writes:
>> It would be great if the properly maintained fork of TF could be
>> packaged. It is available here:
>> https://github.com/ingwarsw/tinyfugue
>> I would like to see Python support as a default feature, hence my
&g
o DELAYED/15, closing this
> bug. Please let me know if I should delay or cancel that upload.
Oh, whoops, sorry. Thank you for letting me know! I'll do the source
upload myself, since that way it's easy for me to keep the Git history
consistent. I can do that this evening.
--
Russ Allbery (
is that the
classification system is more fine-grained than the users of Lintian care
about, so maintaining it is to some extent wasted effort.
--
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/>
Dmitry Shachnev writes:
> On Sun, Nov 17, 2019 at 11:11:37AM -0800, Russ Allbery wrote:
>> Sphinx uses Python's standard textwrap module to wrap text output. That
>> class has an option, break_on_hyphens, which defaults to True but can be
>> set to False. For Policy, we wa
ersion of the package when you get a
chance! If I end up with a moment to do it instead, I'll update this
thread before starting to avoid duplicate work.
--
Russ Allbery (r...@debian.org) <https://www.eyrie.org/~eagle/>
. I will be able to
get to that in the next couple of days, or happy for someone else to do
it.
--
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
Marco d'Itri writes:
> On Jan 20, Russ Allbery wrote:
>> This also implies that there is arguably an SONAME issue with this library
>> given that two versions of the library with the same SONAME don't provide
>> the same symbols, but I suspect there were really
me (but now I wonder if I have other
> leftover files like this…).
This also implies that there is arguably an SONAME issue with this library
given that two versions of the library with the same SONAME don't provide
the same symbols, but I suspect there were really, really good reasons to
not ch
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
Package: yadm
Followup-For: Bug #948316
I've built a package of 2.3.0 for my personal use that's now available
from archives.eyrie.org/debian. Let me know if you'd like me to push
the changes to Salsa and/or upload it to Debian as well.
Since I was starting fresh, I haven't dealt with the
"""
> 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/>
trying the mkdir from that
open session. Try newgrp user2 in user1's session after the usermod, or
log out and log back in to refresh your supplemental groups.
(This has always been Debian's, and indeed UNIX's, behavior so far as I
know.)
--
Russ Allbery (r...@debian.org) <https://www.eyrie.org/~eagle/>
Andreas Beckmann writes:
> Followup-For: Bug #932351
> Control: tag -1 pending
> buster-pu request: https://bugs.debian.org/948796
Oh, thank you! I was going to get to that and then didn't. Much
appreciated and let me know if I can help in any way.
--
Russ Allbery (r...@d
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)
Package: yadm
Version: 1.12.0-2
Severity: normal
I was looking for good home directory dotfile managers, and yadm looks
like the best currently packaged in Debian, but the Debian version is
out of date. The current upstream version is 2.3.0 and seems to have
substantial improvements in how the
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/>
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/>
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
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
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/>
when that's done. Once that's complete, we can do a reconciliation.
I'm inclined to downgrade Policy musts that the release team does not
consider likely to be release-critical in the future, for instance.
--
Russ Allbery (r...@debian.org) <https://www.eyrie.org/~eagle/>
?
Sure, yes, please go ahead. After thinking about this some more, I agree
with your reasoning.
--
Russ Allbery (r...@debian.org) <https://www.eyrie.org/~eagle/>
tting in the
/etc/default file, that would have no effect and the default would still
be used. If you reverse the order of EnvironmentFile, it avoids that
problem, but now the legacy setting with $(hostname) will be used if it
hasn't been changed, and that will result in a literal $(hostname) in t
Tobias Frost writes:
> Am Samstag, den 07.12.2019, 17:12 -0800 schrieb Russ Allbery:
>> A Policy should means that if there is some stronger reason (such as
>> that adding a unit file would introduce new bugs), there is nothing
>> requiring you to do so. It indicates that n
.
That said, if you'd like help with this, I or someone else following this
thread may be willing to take a look and figure out a way to replicate the
init script behavior. It's normally possible to handle /etc/default
conffiles in systemd units, although it can be a little complicated.
--
Rus
th dedicated configuration than with trying to run sysvinit
scripts for some of the same reasons as systemd. For instance, it would
much prefer if services didn't background themselves and instead stayed in
the foreground so that they could be more easily monitored.
--
Russ Allbery (r..
Policy and we could hold the next release until January. What do you
think, Sean?
--
Russ Allbery (r...@debian.org) <https://www.eyrie.org/~eagle/>
Bastian Blank writes:
> On Fri, Nov 29, 2019 at 10:35:04AM -0800, Russ Allbery wrote:
>> Procedurally in Debian neither of these are justifications for setting
>> the severity to serious. This is not a Policy requirement that has
>> reached consensus, and the release team
are approaches that might satisfy both goals at the same time, such
as dpkg using systemd's native services and configuration files to
integrate with systemd-using systems.
--
Russ Allbery (r...@debian.org) <https://www.eyrie.org/~eagle/>
intainers are not respecting something that you think is
obvious, but I don't think that fighting over the bug severity is the
right way to approach this disagreement in Debian. If you feel that
you've reached an impasse in this discussion, this is what the Technical
Committee is for.
--
Russ A
temd-sysusers is another matter and a bit more obviously doable with
dpkg, although if Sam's option three wins, I'd ask everyone in the
project, including you as dpkg maintainer, to consider the possible
benefits of using cross-distribution mechanisms instead of Debian-specific
mechanisms.)
--
Russ
sh out wording (just
based on past experience), and there's no reason not to start that now,
and by that point we may be pretty near a vote anyway.
--
Russ Allbery (r...@debian.org) <https://www.eyrie.org/~eagle/>
l be on a different machine from the client.
Argh, you are of course entirely correct, so I think this change may be
wrong. I just tested and indeed traditional bitmap fonts are still loaded
from the X server, not from the client. I had thought I'd tested that
before but tested it incorrectly.
-
work on it, though, and I'd be very
happy to see specific proposed language in this bug that we can consider
once the GR makes it clear how the project wants us to proceed with
facilities like this.
--
Russ Allbery (r...@debian.org) <https://www.eyrie.org/~eagle/>
fication seemed very awkward.
/usr/lib64 is for 64-bit architecture support the Red Hat way (instead of
the Debian multiarch approach), so no 32-bit package would ever
legitimately install files there.
--
Russ Allbery (r...@debian.org) <https://www.eyrie.org/~eagle/>
Sean Whitton writes:
> On Sun 17 Nov 2019 at 10:10AM -08, Russ Allbery wrote:
>> +* The term *may* and the adjective *optional* are sometimes used to
>> + clarify cases where it may otherwise appear that Policy is specifying a
>> + requirement or recommendation. These wor
Russ Allbery writes:
> I think the current approach in the entirety of 9.11 no longer makes
> sense, but there are two possible alternative approaches and which to
> pick will depend on the results of the current GR. Therefore, I think
> we should for the results of the GR rathe
ackaging init systems intended for use inside containers or other
special-purpose environments that do not need to support arbitrary
Debian packages. But any alternate init system should make clear which
of those use cases it's aiming at.)
--
Russ Allbery (r...@debian.org) <https://www.eyrie.org/~eagle/>
up`` or
``/etc/gshadow``.
I added "directly" since of course adduser modifies /etc/passwd
indirectly, as does every package that calls adduser in its maintainer
scripts.
--
Russ Allbery (r...@debian.org) <https://www.eyrie.org/~eagle/>
Bastian Blank writes:
> On Sun, Nov 17, 2019 at 10:10:11AM -0800, Russ Allbery wrote:
>> +The Release Team may, at their discretion, downgrade a Policy requirement
>> +to a Policy recommendation for a given release of the Debian distribution.
>> +This may be done for on
fields of the package), the first line of
> `---
> source:
> ,---
> :ref:```Maintainer`` <#s-f-Maintainer` or
> ```Uploaders`` ` control fields of the package),
> `---
Thanks, fixed.
--
Russ Allbery (r...@debian.org) <https://www.eyrie.org/~eagle/>
,---
> This wording allows the development files to be split into
> several packages, such as a separate architecture-independent
> libraryname- headers, provided that the development package
> `---
> - chapter 8, footnote [13], rendered as:
> ,---
>
hinx, but it's really an upstream feature
request.
--
Russ Allbery (r...@debian.org) <https://www.eyrie.org/~eagle/>
se or DFSG
requirements to retain the referenced source package. It should not
be added solely as a way to locate packages that need to be rebuilt
against newer versions of their build dependencies.
--
Russ Allbery (r...@debian.org) <https://www.eyrie.org/~eagle/>
Package: debian-policy
Version: 4.4.1.1
Severity: normal
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
ow
off-hand how to do that and haven't yet done any research.)
--
Russ Allbery (r...@debian.org) <https://www.eyrie.org/~eagle/>
and how to download
it, put download information in debian/watch.
--
Russ Allbery (r...@debian.org) <https://www.eyrie.org/~eagle/>
ething into Policy and
hopefully would speed up resolution of the bug.
v9 and v10 are still not deprecated, so support for v12 isn't urgent
(yet). If this bug is still unfixed by the time that v9 and v10 are
deprecated, that would probably warrant more urgency.
--
Russ Allbery (r...@debi
Now fixed, although I got the changelog message wrong because I still
didn't understand properly. Ugh. I could have sworn that Debian buildds
didn't allow network access. I'll fix the changelog message in a future
upload.
Thank you!
--
Russ Allbery (r...@debian.org) <ht
Now fixed, although I got the changelog message wrong because I still
didn't understand properly. Ugh. I could have sworn that Debian buildds
didn't allow network access. I'll fix the changelog message in a future
upload.
Thank you!
--
Russ Allbery (r...@debian.org) <ht
thought setuptools was much smarter than apparently it
actually is. I'll look at this tonight; I may fix this upstream instead
of only in the Debian package if it doesn't take too long to do.
--
Russ Allbery (r...@debian.org) <https://www.eyrie.org/~eagle/>
s (I thought it would know that an unversioned dependency on typing was
already satisfied by Python 3 stdlib). Will fix tonight.
--
Russ Allbery (r...@debian.org) <https://www.eyrie.org/~eagle/>
Package: vim-nox
Version: 2:8.1.2244-1
Severity: normal
I have "set noesckeys" in my .vimrc because I don't like the delay after
pressing ESC under the normal configuration. When I upgraded to
2:8.1.2244-1, this broke handling of capital letters in insert mode.
Specifically, after entering
ckages that include daemons for system
+services should place scripts in ``/etc/init.d`` to start or stop those
+services at boot time or during a change of runlevel. These scripts should
+be named ``/etc/init.d/package``, and they should accept one argument,
+saying what to do:
``start``
start
Ansgar writes:
> Russ Allbery writes:
>> Ansgar writes:
>> I think we can proceed to add a Policy "should" for including a systemd
>> unit file unless someone raises objections pretty soon here. So far, I
>> haven't seen any objections to the basic idea.
o be that conservative here, mostly because
we're long-overdue for saying something, and I think the should is fairly
mild in this case.
--
Russ Allbery (r...@debian.org) <https://www.eyrie.org/~eagle/>
conftestval`,
+inn_cv_macro_iov_max=error,
+16)
+ AS_IF([test x"$inn_cv_macro_iov_max" = xerror],
+[AC_MSG_WARN([probe failure, assuming 16])
+ inn_cv_macro_iov_max=16])])
+ AC_DEFINE_UNQUOTED([IOV_MAX], [$inn_cv_macr
Sean Whitton writes:
> On Sat 26 Oct 2019 at 03:54PM -07, Russ Allbery wrote:
>> For what it's worth, I also always follow a practice of running dgit
>> sbuild before dgit push-source, so dgit could have detected the binary
>> packages that way in theory, but I'm not
Package: dgit
Version: 9.9
Followup-For: Bug #903090
For the purposes of tracking interest, I just ran into this problem with
a package that introduced a new binary package, and would also like dgit
to be able to detect this situation and warn me before doing a
push-source. Parsing
Package: dh-python
Version: 4.20190722
Severity: normal
I: dh_python3 pydist:228: Cannot find package that provides typing. Please add
package that provides it to Build-Depends or add "typing python3-typing" line
to debian/py3dist-overrides or add proper dependency to Depends by hand and
of signed
> artefacts in a single batch, and provide a way to retry the delivery of
> the objects to remote places. That would also make it more convenient
> to work around a dput failure.
That sounds like an even better fix if it's possible.
--
Russ Allbery (r...@debian.org) <https://www.eyrie.org/~eagle/>
orrect that it doesn't help with keeping the directory in the
source package; it just makes sure it's created by the build step before
anything might use it.
--
Russ Allbery (r...@debian.org) <https://www.eyrie.org/~eagle/>
Package: cppcheck
Version: 1.89-4
Severity: normal
cppcheck has a couple of new false positives in one of my packages
(remctl) that seem to be related to losing track of possible
modifications of variables via passing a pointer to that variable to
another function.
First false positive:
Package: debhelper
Version: 12.7
Severity: important
gnubg 1.06.002-2 no longer builds with the latest debhelper, producing the
following error message:
dh_installman
dh_installman: mv debian/gnubg/usr/share/man/man6/makeweights.6.gz.dh-new
debian/gnubg/usr/share/man/man6/makeweights.6: No
ng syntax::
+
+ [ " -b " ]
+
+This is interpreted the same way as the Git syntax except a path
+within the repository is not supported.
A package control file must not have more than one ``Vcs-``
field. If the package is maintained in multple version control
--
Russ Allbery (r...@debian.org) <https://www.eyrie.org/~eagle/>
Wed 23 Oct 2019 05:24:46 PM PDT
gpg:using RSA key D73934B49674CF5CCD9AC2787D80315C5736DE75
gpg: Good signature from "Russ Allbery " [ultimate]
gpg: aka "Russ Allbery " [ultimate]
gpg: aka "Russ Allbery " [ultimate]
gpg:
301 - 400 of 6053 matches
Mail list logo
