Package: lintian
Version: 2.5.99
Severity: normal
In #878609, xfonts packages were reclassified to be in the x11 section,
resulting in the wrong-section-according-to-package-name tag being
issued if they go to the fonts section. This was based on the text in
https://packages.debian.org/en/sid/,
k that's all we'll have unless someone else decides to
extend all of that hard work.
> (Also note: moon-letters may not be visible until viewed under
> starlight or moonlight. This is not a bug.)
:)
--
Russ Allbery (r...@debian.org) <http://www.eyrie.org/~eagle/>
rator configuration. Does that sound
right?
--
Russ Allbery (r...@debian.org) <http://www.eyrie.org/~eagle/>
Package: wnpp
Severity: normal
I intend to orphan the krb5-sync package. I no longer use the package and
it doesn't seem likely that I will again soon, so I'm no longer a good
maintainer for it.
The package builds two binary packages. krb5-sync-plugin's description:
This plugin synchronizes
Package: wnpp
Severity: normal
I intend to orphan the libpam-afs-session package. I no longer use the
package and it doesn't seem likely that I will again soon, so I'm no
longer a good maintainer for it.
The package description is:
AFS is a distributed network file system. It uses in-kernel
t
necessarily correct.
--
Russ Allbery (r...@debian.org) <http://www.eyrie.org/~eagle/>
shouldn't* be deleted when the package
*isn't* purged.
--
Russ Allbery (r...@debian.org) <http://www.eyrie.org/~eagle/>
es should be removed by the postrm script on purge (we
sort of say this, but not as clearly as we could, at least in a quick
check).
--
Russ Allbery (r...@debian.org) <http://www.eyrie.org/~eagle/>
hat this application happens to run without
even necessarily knowing it's written in Perl. It seems better to ensure
that this sort of pattern just works.
--
Russ Allbery (r...@debian.org) <http://www.eyrie.org/~eagle/>
.
That's apparently the approach Python took.
Certainly we should avoid making every packager carry a bunch of diffs or
something to fix this if we decide to standardize and can make their lives
easier! I totally agree with that.
--
Russ Allbery (r...@debian.org) <http://www.eyrie.org/~eagle/>
never liked command interposition in maintainer scripts,
although I admit that it lets one do some things as a local sysadmin that
are otherwise quite irritating to do. But apart from one's preferences on
both, it feels like we have a foundational inconsistency here.
--
Russ Allbery (r..
necessary modules are
installed, following much the same logic as for not using full paths to
commands in maintainer scripts). But picking one or the other essentially
at random (from the perspective of the user) sounds awful.
--
Russ Allbery (r...@debian.org) <http://www.eyrie.org/~eagle/>
Russ Allbery writes:
> Did Lintian have some special case that was allowing /usr/bin/env perl
> previously and then Lintian changed based on Policy? That would be
> unfortunate, since we thought we were changing to match Lintian
Sigh. Yes, indeed.
* checks/scripts.pm:
+ [C
Russ Allbery writes:
> Norbert Preining writes:
>> If a user/system admin wants to replace Perl by prepending the path to
>> a self compiled Perl to the PATH, it is his right to do so, and Perl
>> scripts are expected to follow this decision. It is the obligation of
>&g
is the obligation of
> the one doing the change to ensure proper availability of modules and
> support files.
There were literally zero packages in Debian that did this that Lintian
could find. Did we miss something?
--
Russ Allbery (r...@debian.org) <http://www.eyrie.org/~eagle/>
Ian Jackson writes:
> Russ Allbery writes:
>> Very belatedly, thank you, this makes a lot of sense. I hadn't thought
>> about the angle of the most likely vendor to be used in a
>> vendor-specific series file deciding whether they want this feature to
>> be used at al
ght
about the angle of the most likely vendor to be used in a vendor-specific
series file deciding whether they want this feature to be used at all.
When you point that out, it makes perfect sense to me that Ubuntu should
be able to decide via their own project governance methods if this is a
featur
breaking backwards
compatibility. That's what MIME ended up doing.
But I don't think our install base is so large as to require that, and I
do think it's feasible to fix all the parsers. The reason MIME went down
that path is because it was not reasonable to fix all the parsers.
--
Russ Allbery (r..
Wouter Verhelst writes:
> On Sat, Jul 28, 2018 at 01:51:12PM -0700, Russ Allbery wrote:
>> One remaining question in my mind is whether we should take the
>> opportunity of a format change to achieve a few other goals. The most
>> obvious one would be to reconcile our shor
Control: forcemerge 905235 -1
David Bremner writes:
> Russ Allbery writes:
>> Setting up emacs-goodies-el (40.0) ...
>> Install emacsen-common for emacs25
>> emacsen-common: Handling install of emacsen flavor emacs25
>> Install emacs-goodies-el for emacs25
>> i
Package: emacs-goodies-el
Version: 40.0
Severity: important
Setting up emacs-goodies-el (40.0) ...
Install emacsen-common for emacs25
emacsen-common: Handling install of emacsen flavor emacs25
Install emacs-goodies-el for emacs25
install/emacs-goodies-el: Handling emacs25, logged in
changed their mind on this without getting in touch with
you.
--
Russ Allbery (r...@debian.org) <http://www.eyrie.org/~eagle/>
olunteer project and sometimes people
just don't have time to think about things until they're farther along.
It happens.
--
Russ Allbery (r...@debian.org) <http://www.eyrie.org/~eagle/>
o be sure. (that's probably the discussion
> in #904729)
Even if he agrees with you, that doesn't change my position, just for the
record. So I'm not sure this is going to achieve what you want it to
achieve. :)
--
Russ Allbery (r...@debian.org) <http://www.eyrie.org/~eagle/>
e aware
of.
> Please also read what Joerg Jaspert has written in
> https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=883950#80
> again. Even the ftp-masters prefer a keep it simple solution and they
> support our proposal to reduce boilerplate.
I don't think Joerg recognized the backwar
(possibly with some other name) to adduser that *requires* the name start
with whatever chosen prefix we use and, of course, doesn't complain that's
a bad name. Or maybe even just make --system be that flag, although
that's not backward-compatible with packages that use other prefixes.
--
Russ Allbery (r...@debian.org) <http://www.eyrie.org/~eagle/>
ything uncertain. I'd much rather make
that decision openly and clearly so that people understand it and can rely
on it.
--
Russ Allbery (r...@debian.org) <http://www.eyrie.org/~eagle/>
-devel, Policy and the BTS,
dpkg maintenance discussions, the Technical Committee, and so forth. I
admit that it would be rather nice to have the discussion tied directly to
patches against Policy in a mergeable form, though, rather than sometimes
awkwardly sending around diffs.
--
Russ Allb
hange it except for major changes. This is a backward-incompatible
change for at least validating parsers, which seems like it's the basic
purpose of a version number.
> (The brackets, however, remain unnecessary.)
Yup, agreed.
--
Russ Allbery (r...@debian.org) <http://www.eyrie.org/~eagle/>
identifiers we define to mean something different than they do).
Hopefully not.
Anyway, that's just an aside -- SPDX convergence will be a separate bug
and discussion if we decided to go down that path.
--
Russ Allbery (r...@debian.org) <http://www.eyrie.org/~eagle/>
ar field whose definition is
a pointer to a file with supplemental information about how licenses are
handled in that distribution.
--
Russ Allbery (r...@debian.org) <http://www.eyrie.org/~eagle/>
other outcome that I wanted.
--
Russ Allbery (r...@debian.org) <http://www.eyrie.org/~eagle/>
ow this existed. I'll take a look.
--
Russ Allbery (r...@debian.org) <http://www.eyrie.org/~eagle/>
n the get-orig-source target, specifically Files-Excluded in
debian/copyright. See the documentation of Files-Excluded in uscan(1).
--
Russ Allbery (r...@debian.org) <http://www.eyrie.org/~eagle/>
presenting this in dgit's repository: the experimental
upload is based on all the unstable history, and then the later unstable
upload is a descendent of the experimental packages (much of the time,
although not always).
--
Russ Allbery (r...@debian.org) <http://www.eyrie.org/~eagle/>
generation and I think that's where most of the fonts are coming from.
--
Russ Allbery (r...@debian.org) <http://www.eyrie.org/~eagle/>
UI machinery, but
I'm sure life is short for upstream and they haven't had an obvious reason
to bother with this.
--
Russ Allbery (r...@debian.org) <http://www.eyrie.org/~eagle/>
depends on hicolor-icon-theme
anyway).
I kind of want to rewrite them in dot, which I personally much prefer, but
eh.
--
Russ Allbery (r...@debian.org) <http://www.eyrie.org/~eagle/>
rectory. Generic header names are only a
>> problem at the top level of the include hierarchy.
> But of course. Almost confused why you thought an explanation was needed ;)
You're right -- that was obvious. Sorry! :) I should have just made a
patch instead.
--
Russ Allbery (r...@debian.org) <http://www.eyrie.org/~eagle/>
bdirectory. Generic header names are only a
problem at the top level of the include hierarchy.
--
Russ Allbery (r...@debian.org) <http://www.eyrie.org/~eagle/>
Paul Wise <p...@debian.org> writes:
> On Mon, 2018-05-07 at 19:27 -0700, Russ Allbery wrote:
>> I just now checked, and the packages currently diagnosed with this
>> tag [1] are 100% false positives, which makes me wonder if this tag
>> should just be dele
should be warned about).
> Retitling to clarify. (Still, "SSIA" comes across as a little... lazy! :p)
Oh, ack, I'm sorry. I should have done a bit more investigation to
understand how this tag works before I replied and added noise. My fault,
and thank you for the explanation!
--
Mattia Rizzolo <mat...@debian.org> writes:
> SSIA.
Could you say more? www.gnu.org redirects to https for me, so it seems
like one can use https when referencing www.gnu.org URLs. (I would be
surprised if that weren't the case given the goals of the FSF.)
--
Russ Allbery (r...@d
icked one out of a hat (although I admit
the lack of documentation in Policy for how to declare this dependency
doesn't help). In contrast, add-ons for one specific MTA, or management
interfaces that only know how to configure one specific MTA, are fairly
common.
[1]
https://lintian.debian.org/tags/d
erimental is for. Pedantic is for best-practice
advice that's controversial, that is correct but may not be fixable (no
upstream changelog, for instance), or that is minor
quality-of-implementation details that a lot of maintainers aren't
interested in messing with (upstream/metadata, for inst
Benjamin Kaduk <ka...@mit.edu> writes:
> On Sun, May 06, 2018 at 07:05:56PM -0700, Russ Allbery wrote:
>> This seems trivial enough that the krb5-kdc package could just ship
>> this service for now and gauge interest. I think all you'd need is a
>> program that called
l you'd need is a program
that called getrandom() and then exited when it returned, run via systemd
as a Type=oneshot service that krb5-kdc depends on and with a reasonable
timeout.
--
Russ Allbery (r...@debian.org) <http://www.eyrie.org/~eagle/>
making it do nothing would be friendlier.
lintian --suggestions, maybe?
--
Russ Allbery (r...@debian.org) <http://www.eyrie.org/~eagle/>
're using Lintian wrong doesn't
seem to be working.
--
Russ Allbery (r...@debian.org) <http://www.eyrie.org/~eagle/>
I'm not sure how one could possibly be more clear. If one's definition of
lintian-clean includes --pedantic, one's definition of lintian-clean is,
well, wrong.
--
Russ Allbery (r...@debian.org) <http://www.eyrie.org/~eagle/>
Paul Gevers <elb...@debian.org> writes:
> On 05-05-18 23:55, Russ Allbery wrote:
>> In other words, I would like to run the merger of the tests in
>> debian/tests/control plus the tests corresponding to any
>> autopkgtest-pkg-* entries in the Testsuite control fi
Package: autopkgtest
Version: 5.3.1
Severity: wishlist
I have a package (remctl) that provides both Perl and Python bindings with
corresonding binary packages. I want to run autopkgtest-pkg-perl and
autopkgtest-pkg-python tests on the corresponding binary packages.
autodep8 can't see how to run
be some bug in Lintian. Not that you had somehow done something horribly
wrong with your package.
--
Russ Allbery (r...@debian.org) <http://www.eyrie.org/~eagle/>
umber of free software distribution sites that currently
use FTP but would support FTP + TLS is at most a rounding error away from
zero.
--
Russ Allbery (r...@debian.org) <http://www.eyrie.org/~eagle/>
:
-gpg_output = gpg_output.decode(encoding='UTF-8')
-
if gpg_output.count('[GNUPG:] GOODSIG'):
pass
elif gpg_output.count('[GNUPG:] BADSIG'):
--
Russ Allbery (r...@debian.org) <http://www.eyrie.org/~eagle/>
. It will also
remove any self-dependency (in fact it will remove any dependency
which evaluates to true given the current version of the package as
installed).
So this is purely a nit in the debian/control file in the source package.
I think this is Lintian's role, not Policy.
--
moving it outside
the scope of Policy, such as how to document dependencies required for
running the get-orig-source target.
--
Russ Allbery (r...@debian.org) <http://www.eyrie.org/~eagle/>
Package: dput-ng
Version: 1.18
Severity: normal
dput-ng Recommends python-paramiko, but has been converted to Python 3,
so I believe the correct package is now python3-paramiko. With
python-paramiko installed, the scp upload method still results in the
error:
failed to resolve path
Package: dput-ng
Version: 1.18
Severity: normal
dput-ng throws an exception when reporting the output from a
post_upload_command and does not show the output. The exception is:
Traceback (most recent call last):
File "/usr/bin/dput", line 124, in
upload_package(changes, args)
File
libsystemd0, libpam-systemd, and
libnss-resolve to the updated version. I can confirm that IPv6 is still
working fine on that system on a network that doesn't advertise an MTU,
and I'm not seeing the errors in my logs.
--
Russ Allbery (r...@debian.org) <http://www.eyrie.org/~eagle/>
d
assume?
I think my personal maintainer page is probably more typical.
--
Russ Allbery (r...@debian.org) <http://www.eyrie.org/~eagle/>
e
> something like:
> """
> This is the lintian report for Russ Allbery, who maintains 20 packages.
> Possible issues found by lintian:
> E: 10 (of which 3 are certain)
> W: 3
> Style suggestions / nits:
> I: 12
> P: 255 (of which 120 of these are file-contains-tr
eless and add a ton of space because even entirely Lintian-clean
packages have several of them. Maybe just suppress those from the
maintainer report and see what things look like then?
--
Russ Allbery (r...@debian.org) <http://www.eyrie.org/~eagle/>
The workaround is to call setuid(0) in the parent program before you call
modprobe, or otherwise arrange for euid == uid.
--
Russ Allbery (r...@debian.org) <http://www.eyrie.org/~eagle/>
Javier Serrano Polo <jav...@jasp.net> writes:
> El dc 07 de 02 de 2018 a les 08:40 -0800, Russ Allbery va escriure:
>> Why would you not use the existing *-doc package construction, which
>> seems to accomplish exactly the same goal and is already fairly
>> sta
ght file, and would need
a more comprehensive solution. So this doesn't really help one way or the
other.
--
Russ Allbery (r...@debian.org) <http://www.eyrie.org/~eagle/>
Russ Allbery <r...@debian.org> writes:
> I'll be open about this: I think that there's a deep mismatch between
> how we like to discuss things, which is why I'm trying to avoid getting
> into a back and forth. I think you're just trying to be clear and
> precise, but I find
previously, I'm happy to let the active Lintian
maintainers make the final call on this, since I'm not active.
--
Russ Allbery (r...@debian.org) <http://www.eyrie.org/~eagle/>
ctly contrary to the entire reason I created this bug. :)
--
Russ Allbery (r...@debian.org) <http://www.eyrie.org/~eagle/>
file.
What makes you confident that the process you propose would continue to
satisfy the license going forward during normal upstream updates?
How much energy would you want to spend on defending your interpretation
of this in order to avoid installing this file in the documentation area
of t
sue entirely rather than carefully analyzing the
situation or remembering to resync copies of the upstream file.
--
Russ Allbery (r...@debian.org) <http://www.eyrie.org/~eagle/>
subdirectories should have permissions 2775
>> (group-writable and set-group-id) and be owned by "root:staff".
> SGTM. (AKA "seconded".)
Seconded.
Thank you for bringing this back to life, Santiago! I've been wanting to
resolve this for some time.
--
Russ Allbery (r...@debian.org) <http://www.eyrie.org/~eagle/>
Package: elpa-org
Version: 9.1.6+dfsg-1
Severity: minor
This last stanza in /usr/share/doc/elpa-org/README.Debian:
To enable contributed extensions to org-mode, simply add
"/usr/share/org-mode/lisp" to your load-path, for instance in your
.emacs with:
(setq load-path (cons
Package: elpa-org
Version: 9.1.6+dfsg-1
Severity: minor
I have org-mode archive completed items into a separate file,
configured with:
(setq org-archive-location "~/data/org/archive/%s::")
org-mode used to save that archive file after each archived item.
When upgrading from 9.1.2 to 9.1.5, this
ill die down a bit.
--
Russ Allbery (r...@debian.org) <http://www.eyrie.org/~eagle/>
t to diverge from upstream behavior for a package
as central as coreutils and a command as central as ls.
--
Russ Allbery (r...@debian.org) <http://www.eyrie.org/~eagle/>
although
normal Debian best practices with debian/changelog would satisfy it.)
Free software licenses have a lot more restrictions and specific
requirements than a lot of people realize they do, and there are a *lot*
of technical violations of free software licenses out there.
--
R
Vincent Bernat <ber...@debian.org> writes:
> ❦ 2 janvier 2018 10:42 -0800, Russ Allbery <r...@debian.org> :
>> We currently allow distribution of a binary-package-only Debian image
>> along with a written offer of source or, for non-commercial
>> distributio
Vincent Bernat <ber...@debian.org> writes:
> ❦ 22 décembre 2017 19:58 -0800, Russ Allbery <r...@debian.org> :
>> Apache 2.0 requires distributing any NOTICE file along with derivative
>> works, but this is easy to forget. In many cases, we have effectively
>&g
ng Git, or that, at this point,
this isn't because of a conscious and intentional choice seems extremely
low. So you're basically warning the maintainer about something they have
already intentionally chosen to do, and that's almost never going to go
over well.
--
Russ Allbery (r...@d
Chris Lamb <la...@debian.org> writes:
> libpam-krb5 which was actually being caught by a "libfoo1" => "libs" entry
> designed for regular libraries. Fixed in Git with a testcase:
Ah! That didn't even occur to me, but that makes much more sense. Thank
you!
Package: lintian
Version: 2.5.66
Severity: normal
Lintian now wants me to change the section of my PAM module packages
to libs based on the package name. It looks like common practice in
the archive is a bit all over the place, and standardizing would be
great, but libs seems wrong to me. In
far,
they've either seen /etc/motd or know enough about Debian to know where to
look for things.
(I see it all the time, but I run Debian on servers.)
--
Russ Allbery (r...@debian.org) <http://www.eyrie.org/~eagle/>
e is
that a bunch of generated files are checked into the repository but then
deleted on clean, which makes the checkout dirty. It would be nice to get
rid of the committed generated files so that cleaning the source tree
doesn't result in a dirty tree, if you (or anyone else) has some free
time
Package: clang
Version: 1:4.0-40
Severity: normal
When run, scan-view reports:
Traceback (most recent call last):
File "/usr/bin/scan-view", line 144, in
main()
File "/usr/bin/scan-view", line 141, in main
run(port, args, args.root)
File "/usr/bin/scan-view", line 71, in run
ay something
very short like:
References to one of these licenses with a + appended, such as
"GPL-2+", indicate the choice of the named license file or any later
version of the same license.
--
Russ Allbery (r...@debian.org) <http://www.eyrie.org/~eagle/>
y the package. Maybe it would be worth explicitly saying that how to
repack new upstream source should be documented in README.source if it's
not obvious how to do so?
--
Russ Allbery (r...@debian.org) <http://www.eyrie.org/~eagle/>
Markus Koschany <a...@debian.org> writes:
> Am 29.12.2017 um 23:35 schrieb Russ Allbery:
>> Policy does not require that. ftpmaster might, which is not quite the
>> same thing.
> That's a bold claim.
> "Every package must be accompanied by a verbatim cop
does not require that. ftpmaster might, which is not quite the
same thing.
> However upstream could simply state that all software is GPL-2+ licensed
> because the Expat license grants them the right to sublicense parser.c.
The Expat license grants *anyone* the right to do that, so the Debian
pa
Package: wnpp
Severity: normal
I am orphaning the lbcd package.
The package description is:
lbcd is a daemon that answers UDP queries for system load information and
returns such information as uptime, load, number of logged-in users,
percentage free of /tmp and /var/tmp, and whether there is
Package: wnpp
Severity: normal
I no longer use this software and won't for the forseeable future, so
I can't test or properly maintain the packaging.
Note for any potential adopters: this software has also been orphaned
upstream. Stanford seems uninterested in any future development or
even
See https://bugs.debian.org/284340.
--
Russ Allbery (r...@debian.org) <http://www.eyrie.org/~eagle/>
Sean Whitton <spwhit...@spwhitton.name> writes:
> On Wed, Dec 27 2017, Russ Allbery wrote (to 601...@bugs.debian.org):
>> Tiny formatting nit: I usually prefer to put the double-colon at the
>> end of the previous paragraph when the literal text is introduced
>>
LaTeX PPL 1.3c 34
MPL 1.1 224
MPL 2.0 176
SIL OFL 1.0 12
SIL OFL 1.1 159
Total number of packages: 30676
--
Russ Allbery (r...@debian.org) <http://www.eyrie.org/~eagle/>
a the historic criteria of more usage than the least popular license
already in common-licenses (GFDL 1.3 at 138 packages).
--
Russ Allbery (r...@debian.org) <http://www.eyrie.org/~eagle/>
n with a few other licenses already in
common-licenses:
AGPL 3 189
Apache 2.0 2672
Artistic 3804
Artistic 2.0200
GFDL 1.2314
GFDL 1.3138
MPL 1.1 224
MPL 2.0 176
It seems reasonable to
3
CC-BY-SA 2.0 44
CC-BY-SA 2.5 14
CC-BY-SA 3.0285
CC-BY-SA 4.0 61
Looks like both CC-BY 3.0 and CC-BY-SA 3.0 would warrant inclusion. Note
that the regexes in license-count may not be perfect; I'm not completely
familiar with all the variations
0 44
CC-BY-SA 2.5 14
CC-BY-SA 3.0285
CC-BY-SA 4.0 61
4.0 is a pretty niche license right now. Maybe that's expected to grow at
the cost of 3.0, though
--
Russ Allbery (r...@debian.org) <http://www.eyrie.org/~eagle/>
Russ Allbery <r...@debian.org> writes:
> Ole Streicher <oleb...@debian.org> writes:
>> triggered by the discussion in debian-project [1]: was there any
>> progress made here? Is Russ' software still actual?
> I still use it periodically (although rarely at the momen
e maintainers may see it and just document that approach if
they get questions from users about disabling their service.
--
Russ Allbery (r...@debian.org) <http://www.eyrie.org/~eagle/>
501 - 600 of 6053 matches
Mail list logo
