nk that's happened, and the correct thing happened when I
overrode $USER (and $LOGNAME) and then did the same thing again with
otherwise the same environment variables.
--
Russ Allbery (r...@debian.org) <https://www.eyrie.org/~eagle/>
st
some surprising behavior here in Emacs. Blindly using USER when HOME is
set correctly is pretty unusual (and, for whatever it's worth, contrary to
the BaseDir specification, not that Emacs is currently following that).
Generally HOME should override USER when used to locate the current user's
home
nd upgraded again
with USER and LOGNAME set to root, and now everything works fine. (Well,
my laptop gets extremely hot the first time I start the new Emacs, but I
assume that's expected for the new compilation system.)
--
Russ Allbery (r...@debian.org) <https://www.eyrie.org/~eagle/>
d have assumed it must be something in my startup files that is
incompatible with the latest release of Emacs, except I thought -q
--no-site-file should completely disable loading anything from my local
configuration.
--
Russ Allbery (r...@debian.org) <https://www.eyrie.org/~eagle/>
Package: emacs-lucid
Version: 1:28.1+1-1
Severity: grave
X-Debbugs-Cc: r...@debian.org
The 28.1 version of emacs-lucid fails on startup with a cryptic error
message:
% emacs
Cannot find suitable directory for output in ‘comp-native-load-path’.
Running emacs -q allows it to start, but it still
E for the dropped symbol,
or add an rk_closefrom wrapper around the glibc closefrom to keep the same
ABI. (Or break the ABI without changing the SONAME on the grounds that
only a few packages use it, but I'm pretty hesitant to recommend doing
that since who knows what outside of Debian might break and w
it's never made it into a release.
--
Russ Allbery (r...@debian.org) <https://www.eyrie.org/~eagle/>
kewise, him is apparently now
in 639-5.
The conclusion I'd draw from that is that there's probably no need to add
639-2 if you include both 639-3 and 639-5, and it may be simpler to just
ignore it.
--
Russ Allbery (r...@debian.org) <https://www.eyrie.org/~eagle/>
to your solution. :)
(Maybe all of this can be captured in comments for the next poor
maintainer who has to try to understand what's going on.)
--
Russ Allbery (r...@debian.org) <https://www.eyrie.org/~eagle/>
of the group rather than being coded to
the 639-5 language group code. I think Lintian should still continue to
use 639-3.
That said, I'll leave it to you to decide if you want to hang on to the
bug or not. :)
--
Russ Allbery (r...@debian.org) <https://www.eyrie.org/~eagle/>
Russ Allbery writes:
> Fabio Fantoni writes:
>> Hi, on a lintian output I saw:
>> W: xapps-common: unknown-locale-code ber [usr/share/locale/ber/]
>> but ber locale exists:
>> https://www.loc.gov/standards/iso639-2/php/langcodes_name.php?code_ID=54
> Thanks
ing this bug to iso-codes for further investigation and cc'ing
the maintainer.
--
Russ Allbery (r...@debian.org) <https://www.eyrie.org/~eagle/>
ning.
For the record (since I'm not sure this is obvious when you're new to
Lintian), the best way to run Lintian is on the *.changes file generated
as part of the package build. That will check everything that will be
included in the upload.
--
Russ Allbery (r...@debian.org) <https://www.eyrie.org/~eagle/>
so we can err on the side of
convenience to let proposers rewrite the options to whatever they want.
If that makes previously acceptable options unacceptable, other TC members
can always propose new options or reinstate versions of the previous
options.)
--
Russ Allbery (r...@debi
ed systems even if Debian itself will no
longer support such systems, and I don't think it would be *too*
challenging to do so. There's also just some super-minor stuff like tabs
vs. spaces, formatting of function signatures, etc., that I'm happy to
help clean up to smooth the path.)
--
Russ Allbery (
re, to start discussing and analyzing.
--
Russ Allbery (r...@debian.org) <https://www.eyrie.org/~eagle/>
ntation design that could get some consensus, and flush out the
remaining problems. (To be clear, others have been doing more of that
than I have, but I think it's a bit inaccurate to say that I've only been
complaining and not trying to help arrive at a proper fix.)
--
Russ Allbery (r.
Josh Triplett writes:
> On Thu, 24 Mar 2022 10:35:10 -0700 Russ Allbery wrote:
>> That said, I personally am disappointed that the folks who have been
>> pushing merged-/usr forward are willing to leave dpkg in a known-buggy
>> state without attempting to patch it to fix
x
edge cases and maintain a high level of consistency and correctness.
--
Russ Allbery (r...@debian.org) <https://www.eyrie.org/~eagle/>
I have no opinion about whether Lintian should mark it as a spelling
mistake, but I would recommend avoiding it in favor of the more standard
subtract spelling.
--
Russ Allbery (r...@debian.org) <https://www.eyrie.org/~eagle/>
Sam Hartman writes:
>>>>>> "Russ" == Russ Allbery writes:
> Russ> Switching terminology to completely leave behind the terms
> Russ> with ambiguous meanings isn't a bad idea, but if so we really
> Russ> need a term that captures "
till possible?
If the relevant people required to implement a decision are willing to
tackle it that way, I am certainly willing to participate from the Policy
side.
--
Russ Allbery (r...@debian.org) <https://www.eyrie.org/~eagle/>
official declaration from Debian as
a project that their system configuration is unsupported, while
simultaneously this is the default installation mode for new systems and
something that we have elsewhere said is a correct system configuration.
--
Russ Allbery (r...@debian.org)
Felix Lechner writes:
> On Tue, Mar 15, 2022 at 9:33 PM Russ Allbery wrote:
>> We should define native and non-native packages in terms of version
>> numbers, and allow both native and non-native packages to use
>> single-tarball source package formats.
> I co-mai
(quilt) format that are unrelated to the native vs.
non-native package distinction. I have no useful opinions to add on that
topic.
--
Russ Allbery (r...@debian.org) <https://www.eyrie.org/~eagle/>
fprintf (stderr, "%s: line %d: chown
> failed\n",
This specific example is a false positive, though, correct? I think you
want to filter out hits that include a parenthesis, since those are likely
to be calls to the C library function, which
it into a transitional dummy
> package depending on libperl-critic-community-perl? I guess yes,
> otherwise the 11 users (popcon votes) minus Russ will miss this change
> :)
Yes, that seems right to me (and that looks like what you did; thank you
for that as well).
--
Russ Allbery (r...
Package: ftp.debian.org
Severity: normal
X-Debbugs-Cc: r...@debian.org
I'm the former maintainer of the webauth package, which provides an
Apache-based web single sign-on system. I maintained the software as
upstream when I worked for Stanford University.
Stanford chose to replace the software
Package: libperl-critic-freenode-perl
Version: 0.033-1
Severity: normal
X-Debbugs-Cc: r...@debian.org
Perl::Critic::Freenode has become Perl::Critic::Community, which
also means that all of the policies that it installs have been
renamed to Community::* from Freenode::*.
Unfortunately,
but I think this is also a good idea. We used
libinnhist for the name of the history library from the start and I think
that was wiser.
--
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/>
nt as
the replacement string, and thus will probably do nothing.
--
Russ Allbery (r...@debian.org) <https://www.eyrie.org/~eagle/>
upports the syntax of both.
--
Russ Allbery (r...@debian.org) <https://www.eyrie.org/~eagle/>
the same basic tool.
--
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/>
whole perl + shell + makefile has also lot of duct tape included.
> I’ll either fix this directly in dh-php or provide the affected packages
> with a patch.
> 1. I don’t think missing dependency on PHP is a serious bug, it doesn’t
> prevent usage of the extension, it just doesn’t pul
doing anything
as a package maintainer, or is this expected? Should it be a serious bug?
--
Russ Allbery (r...@debian.org) <https://www.eyrie.org/~eagle/>
Control: reassign -1 python3-typed-ast
Control: severity -1 serious
Matthias Klose writes:
> On 11/8/21 21:34, Russ Allbery wrote:
>> Python 3.9.8 breaks python3-typed-ast:
>>
>> % python3 -c 'from typed_ast import _ast3'
>> Traceback (most recent call
Package: python3.9
Version: 3.9.8-1
Severity: important
Control: affects -1 python3-typed-ast
Python 3.9.8 breaks python3-typed-ast:
% python3 -c 'from typed_ast import _ast3'
Traceback (most recent call last):
File "", line 1, in
ImportError:
Thank you for implementing that!
> Yes, the exception is probably warranted. If it's okay with you,
> however, I will postpone the decision until the cruft check, which
> issues the offending tag, is fixed. It is currently malfunctioning. [2]
> Thank you!
Yes, absolutely, this is a lo
Package: lintian
Version: 2.109.0
Severity: wishlist
libpam-krb5 4.11-1 (just now uploaded and also available from Salsa)
produced the following new Lintian pedantic tags:
N:
P: libpam-krb5 source: very-long-line-length-in-source-file configure line
13223 is 704 characters long (>512)
N:
N:
nd apologies for the delay in fixing this! There
was a test suite change that requires an additional file from the source
tree be available and I need to fix the test configuration. Will fix this
shortly.
Thank you so much for generating these bug reports. They're incredibly
helpful!
--
Rus
tility and is interested
in handling bug reports and requests concerning it.
--
Russ Allbery (r...@debian.org) <https://www.eyrie.org/~eagle/>
Package: release.debian.org
Severity: normal
User: release.debian@packages.debian.org
Usertags: binnmu
X-Debbugs-Cc: 994...@bugs.debian.org
tripwire now segfaults when it tries to read information about a file.
Rebuilding the package from source makes the problem go away. The
problem
Package: tripwire
Version: 2.4.3.7-3+b3
Followup-For: Bug #994910
Reproduced here following a libc6 upgrade. I suspect this is because
tripwire is statically linked and there has been a new release of libc6,
so I suspect the nsswitch interface has broken (which is a standard
problem with
e machines.
We should not enable people who control the local network but not the
Debian system to dynamically change security-relevant configuration of
that system, which I believe includes apt sources, without explicit
permission.
--
Russ Allbery (r...@debian.org) <https://www.eyrie.org/~eagle/>
t may well be that I had
> forgotten this.
Different st_dev is fine. It would be nice if the snapshot preserved the
inode number, but I have no idea if it would.
--
Russ Allbery (r...@debian.org) <https://www.eyrie.org/~eagle/>
hich
means the messages will only happen once after each reboot.
I assume ZFS can't be changing them constantly without a reboot or a
remounting of the file system, since presumably that would break lots of
other software.
--
Russ Allbery (r...@debian.org) <https://www.eyrie.org/~eagle/>
definitely in favor of documenting these files in a format designed to
do so.
--
Russ Allbery (r...@debian.org) <https://www.eyrie.org/~eagle/>
s.
Yes. For example, the approach used by apt-cacher-ng works fine.
Explicitly opting in to a local cache seems desirable.
--
Russ Allbery (r...@debian.org) <https://www.eyrie.org/~eagle/>
no values.
That seems vaguely broken to me, but I'm not sure if anything guarantees
that behavior.
--
Russ Allbery (r...@debian.org) <https://www.eyrie.org/~eagle/>
r. But that's clearly a
> lot of work, and this change wouldn't preclude it.
This does seem like clearly the right solution in the long run for all
problems of this sort, though. I wouldn't want to add many statically
allocated UIDs. (But if anything qualifies for one, _apt is a reasonable
candidate
is kind of
a mess for various reasons and on shaky ground inside Debian. The next
major release of INN will have a SQLite backend, which is probably the
most equivalent replacement, although tradindexed does fine for most
people.
--
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/>
Felix Lechner writes:
> On Mon, Apr 5, 2021 at 1:10 PM Russ Allbery wrote:
>> See also Debian Policy 8.4, which explicitly requires this:
> Thanks for throwing that into the mix. Obviously, I accept policy and
> will implement it, but the approach reminds me of the Goldsbo
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
this:
If the package provides Ada Library Information (*.ali) files for use
with GNAT, these files must be installed read-only (mode 0444) so that
GNAT will not attempt to recompile them. This overrides the normal
file mode requirements given in Permissions and owners.
--
Russ Allber
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
Package: wnpp
Severity: wishlist
Owner: Russ Allbery
X-Debbugs-Cc: debian-de...@lists.debian.org
* Package name: libpod-thread-perl
Version : 2.00
Upstream Author : Russ Allbery
* URL : https://www.eyrie.org/~eagle/software/pod-thread/
* License : MIT
; urgency=medium
+
+ * Apply upstream patch to avoid a double free if calling
+krb5_cc_get_principal on the new cache fails.
+
+ -- Russ Allbery Sun, 14 Mar 2021 12:31:39 -0700
+
libpam-krb5 (4.9-1) unstable; urgency=high
* New upstream release.
diff -Nru
libpam-krb5-4.9/debian/patches/0001
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/>
xing that
upstream and get this fix into Debian in the meantime for the release.
--
Russ Allbery (r...@debian.org) <https://www.eyrie.org/~eagle/>
ion (aka "keysigning")
> - trust models other than direct (and always)?
None of this is used by the Usenet machinery.
--
Russ Allbery (ea...@eyrie.org) <https://www.eyrie.org/~eagle/>
Package: apt-cacher-ng
Version: 3.6-1
Severity: normal
I have a fairly generic apt-cacher-ng configuration that I use for
sbuild. (The only configuration I've changed is to add BindAddress:
localhost and change the Debian backend to https://deb.debian.org/debian/)
Relatively recently I've
Adrian Bunk writes:
> Source: docknot
> Version: 4.00-1
> Severity: serious
> https://ci.debian.net/data/autopkgtest/testing/amd64/d/docknot/10221864/log.gz
Thank you for relaying those results! I forgot to go explicitly check.
Will fix shortly.
--
Russ Allbery (r..
Russ Allbery writes:
> YABUKI Yukiharu writes:
>> I use yadm with bash. I use yadm command frequency. Once a day, yadm
>> works fine with bash. But nowadays, yadm does not do completions with
>> bash. I just switch in zsh. It look yadm completion is fine.
> This wo
been fixed, or at least it's not still happening
for me.
--
Russ Allbery (r...@debian.org) <https://www.eyrie.org/~eagle/>
her, both with the same
version of yadm, so I think something changed in bash. On the working
system, I have bash 5.1~rc2-1, and on the broken system, I have bash
5.1-2. Both have the same version of bash-completion.
I haven't yet tracked down what the change was.
--
Russ Allbery (r...@d
project who are not at fault for any
of the historical init system hostility.
--
Russ Allbery (r...@debian.org) <https://www.eyrie.org/~eagle/>
ts or a conversion utility to satisfy that dependency.
That's where the "project supports the efforts of developers working on
such technologies" part of the GR result comes in.
Just to be extremely clear, the dependency structure for logind feels
different to me and I don't have an opinion on that.
--
Russ Allbery (r...@debian.org) <https://www.eyrie.org/~eagle/>
dation. In those cases, these words describe decisions that are
truly optional and at the maintainer's discretion.
This was intended to reflect the result of the GR.
The dependency structure for indicating a logind requirement is a more
complicated question and I don't personally have any opinion ab
Package: wnpp
Severity: wishlist
Owner: Russ Allbery
X-Debbugs-Cc: debian-de...@lists.debian.org
* Package name: docknot
Version : 4.0.0
Upstream Author : Russ Allbery
* URL : https://www.eyrie.org/~eagle/software/docknot/
* License : Expat
Programming Lang
Joachim Reichel writes:
> The first and third issue are fixed in the upstream master branch. For
> the second issue, upstream asked for a separate bug report which is at
> https://trac.cppcheck.net/ticket/10062#ticket .
Awesome, thank you so much!
--
Russ Allbery (r...@d
(I should retest
some of my previous false positives that I've been suppressing and see if
others are fixed; they probably are.)
--
Russ Allbery (r...@debian.org) <https://www.eyrie.org/~eagle/>
Joachim Reichel writes:
> On 14.12.20 01:23, Russ Allbery wrote:
>> In the second case, something about adding retval to the test messes up
>> its understanding of the data flow.
> Removing retval from the if() condition does not change anything for
> me. Could you do
Package: cppcheck
Version: 2.3-1
Severity: normal
Thank you for packaging cppcheck 2.3! I'm pleased to confirm that the
bugs that I reported in #943463 were indeed fixed in that release.
Unfortunately, it appears to have introduced a few more false positives
in this general area. Here is a
Russ Allbery writes:
> Lintian now emits the following pedantic tag for packages using
> X-DhRuby-Root:
Sorry, forgot to mention: you will be able to see this behavior with the
3.17-1 version of remctl that I'm about to upload, and I'm fairly sure
that you'll see the same with 3.16-4,
Package: lintian
Version: 2.104.0
Severity: wishlist
Given that you want a reference to a package showing the problem on
all Lintian bug reports, based on recent responses, could you consider
including reportbug configuration in the package to prompt for this? A
presubj file would probably do
Package: lintian
Version: 2.104.0
Severity: normal
Lintian now emits the following pedantic tag for packages using
X-DhRuby-Root:
P: remctl source: cute-field debian/control@ruby-remctl X-DhRuby-Root vs
X-Dhruby-Root
N:
P: cute-field
N:
N: The named field uses a free-style form of
Package: python3-virtualenv
Version: 20.2.1+ds-1
Severity: important
Since the upgrade to Python 3.9, creating new virtualenvs sporadically
fails with error messages like this:
% virtualenv tmp/test -p /usr/bin/python3
RuntimeError: failed to build image setuptools because:
Traceback (most
admit I have no idea on how
> to report a bug outside reportbug.
To add additional information to a bug, you can just send mail directly to
976...@bugs.debian.org with a regular mail client if you want. (reportbug
is very useful for getting all the right bits in place to open a new bug,
tho
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/>
201 - 300 of 6053 matches
Mail list logo
