have time in the near future to do the necessary research. Patches
welcome!
--
Russ Allbery (r...@debian.org) <http://www.eyrie.org/~eagle/>
make me very nervous.
I think you'd at least want to put some sanity checks here. I could see a
local sysadmin changing the home directory of a system user to / or some
other catastrophic location.
--
Russ Allbery (r...@debian.org) <http://www.eyrie.org/~eagle/>
has been checked you must arrange for
> your package to create the user or group if necessary using
> adduser in the preinst or
> postinst script (again, the latter is to be
Seconded.
--
Russ Allbery (r...@debian.org) <http://www.eyrie.org/~eagle/>
e other bug reporter, very happy to have you
forward this upstream. I haven't had a lot of time recently to chase
things like this, and have a huge backlog, so happy to encourage others to
push such things forward. Everything in the patch looked good to me.
--
Russ Allbery (r...@debian.org) <http://www.eyrie.org/~eagle/>
Package: lintian
Version: 2.5.48
Severity: normal
The following paragraph in a debian/copyright file:
Files: build-aux/ltmain.sh
Copyright: 1996-2015 Free Software Foundation, Inc.
License: GPL-2+ with Libtool exception or Expat, and GPL-3+ with Libtool
exception or Expat, and GPL-3+
confuses
andle that as part
of this report?
--
Russ Allbery (r...@debian.org) <http://www.eyrie.org/~eagle/>
I have
vague memories of it coming up before.) But I don't think this was ever
documented (I just did a brief check of perlpod and perlpodspec), and it
appears to have changed.
Anyway, it doesn't seem to be serving any purpose here. It seems to just
be a simple mistake, and =pod was
gregor herrmann <gre...@debian.org> writes:
> On Tue, 06 Sep 2016 09:22:04 -0700, Russ Allbery wrote:
>> Russ Allbery <r...@debian.org> writes:
>>
>> > Bug in pod2man. [..]
>> Updated patch that actually passes tests. I'll put out a new release,
>&
an
letting it use its normal upgrade semantics. (Also, a general upgrade is
safer in that you'll always get security updates.)
--
Russ Allbery (r...@debian.org) <http://www.eyrie.org/~eagle/>
Josh Triplett <j...@joshtriplett.org> writes:
> On Sat, Sep 24, 2016 at 12:57:04PM -0700, Russ Allbery wrote:
>> Josh Triplett <j...@joshtriplett.org> writes:
>>> Based on some conversations on #debian-devel on the purpose of
>>> x-window-manager (as la
ger alternative to figure out what to start, so removing that
alternative would break such a setup.
--
Russ Allbery (r...@debian.org) <http://www.eyrie.org/~eagle/>
Package: pbuilder
Version: 0.226
Severity: important
pbuilder update has started failing when run from cron with the following
error:
tput: No value for $TERM and no -T specified
/usr/lib/pbuilder/pbuilder-modules: line 177: [: -ge: unary operator expected
The bug appears to be here:
Russ Allbery <r...@debian.org> writes:
> Bug in pod2man. This is the fix, although there's still something too
> fragile about the auto-detection of man page references that for some
> reason is still picking up a string that contains a space. I haven't
> figured out that part
\'\".?!,;] | \\*\(-- | \\[ ] | $ ) # (3)
+( ^ | [\s\(\"\'\`\[\{<>] | \\[ ] ) # (1)
+( [A-Z] [A-Z] (?: \s? [/A-Z+:\d_\$&] | \\- | [.,\"] )* ) # (2)
+(?= [\s>\}\]\(\)\'\".?!,;] | \\*\(-- | \\[ ] | $ )# (3)
} {
l hostname is listed before localhost
in /etc/hosts, so it's going to return that. That means my fix to check
against the value of `hostname` will fix the test.
--
Russ Allbery (r...@debian.org) <http://www.eyrie.org/~eagle/>
he test more robust against this by also checking for a
string containing $(hostname), but if you happen to know what the reverse
DNS is for 127.0.0.1 in the test environment, I'll make sure this is
caught.
Downgrading since this shouldn't be a problem for Debian proper; this
seems to work fine on al
g-check script, which it runs as part
of Lintian checks, and it build-depends as well as depends on it because
it runs the script as part of its test suite.
Is there a replacement source for that script?
--
Russ Allbery (r...@debian.org) <http://www.eyrie.org/~eagle/>
at this document does not presently exist except
insofar as the REJECT FAQ could be said to be that document.
--
Russ Allbery (r...@debian.org) <http://www.eyrie.org/~eagle/>
Josh Triplett <j...@joshtriplett.org> writes:
> On Mon, Aug 08, 2016 at 11:53:37AM -0700, Russ Allbery wrote:
>> I don't think this is a good idea. This license is extremely short,
>> and it has a ton of minor variations, so we'll get a lot of people
>> using it even t
the BSD license from
common-licenses on the same grounds.)
--
Russ Allbery (r...@debian.org) <http://www.eyrie.org/~eagle/>
Daniel Kahn Gillmor <d...@fifthhorseman.net> writes:
> On Fri 2016-07-22 17:31:15 -0400, Russ Allbery wrote:
>> I do think we should support reproducible builds for all packages, and
>> that our default build should be reproducible. I'm just not sure that
>> we should
Mattia Rizzolo <mat...@debian.org> writes:
> On Fri, Jul 22, 2016 at 12:14:56PM -0700, Russ Allbery wrote:
>> I think that's fine in this case, since not setting that variable
>> doesn't break the build. It just means the build isn't reproducible,
>> which is an o
nconditionally force a reproducible build.
In other words, I think this is more akin to DEB_BUILD_OPTIONS than it is
to DEB_HOST_ARCH.
--
Russ Allbery (r...@debian.org) <http://www.eyrie.org/~eagle/>
loves
hiding things like this.)
--
Russ Allbery (r...@debian.org) <http://www.eyrie.org/~eagle/>
Package: puppet-module-puppetlabs-apt
Version: 2.2.2-1
Severity: minor
Since the upgrade to Puppet 4 (or maybe it was an upgrade to facter?), the
apt module produces this warning on each run:
Warning: Unknown variable: '::lsbminordistrelease'. at
n't get Lintian warnings about just using the default behavior
(something that we would want to encourage so that we can fix this
globally in the correct place).
--
Russ Allbery (r...@debian.org) <http://www.eyrie.org/~eagle/>
if possible.
>> (Debian Bug#399001)
> Which PAM module and daemon are you referring to?
It's used internally at CMU, unfortunately. I'm not sure if I have the
link to the source; I would probably ask jhutz again.
--
Russ Allbery (r...@debian.org) <http://www.eyrie.org/~eagle/>
romised root anyway, since the attacker can then mint arbitrary
service tickets for that host and authenticate to any Kerberos service on
that host (such as ssh) as arbitrary users. So I don't think this really
helps significantly.
--
Russ Allbery (r...@debian.org) <http://www.eyrie.org/~eagle/>
Simon Ruderich <he29h...@stud.informatik.uni-erlangen.de> writes:
> On Fri, Jun 10, 2016 at 10:47:16AM -0700, Russ Allbery wrote:
>> I'm too nervous about the many possible attack approaches to setuid
>> binaries to be entirely comfortable with this approach. My tenta
ty concerns about setuid.
(It does mean some additional operational complexity to start and manage
the daemon, but the Debian package, at least, can easily take care of
that.)
--
Russ Allbery (r...@debian.org) <http://www.eyrie.org/~eagle/>
Package: python3.5
Version: 3.5.1-14
Severity: important
With the upgrade to 3.5.1-14, apparently something changed about the
module load path, and Python 3 no longer sees any modules in
/usr/lib/python3/dist-packages (maybe it expects /usr/lib/python3.5
instead?). This broke, at least, assword,
of its actions
>> are.
> Have you experienced this problem lately?
I haven't. I've mostly switched over to using apt, and haven't run into
any problems when I've used aptitude.
It's fine to close this bug from my perspective if you think it's probably
fixed.
--
Russ Allbery (r...@debian.org) <http://www.eyrie.org/~eagle/>
e Debian packaging and test an
actual Debian package using that code.
--
Russ Allbery (r...@debian.org) <http://www.eyrie.org/~eagle/>
Control: reassign 807756 gcc-5,gcc-6
Matthias Klose <d...@debian.org> writes:
> On 20.03.2016 20:12, Russ Allbery wrote:
>> Note, though, that there seems to be a substantial compiler regression
>> in GCC 5 in the optimizer that affects at least this package. When
>>
ut I don't see any way that
could be a bug in gnubg, as opposed to a regression in the compiler.
(This is bug #807756, which I filed as important and you lowered to
normal.)
--
Russ Allbery (r...@debian.org) <http://www.eyrie.org/~eagle/>
oduce new tested
releases, I'd consider switching to that for Debian packaging, but I think
this is a bit too much to maintain as a distro-specific patch.
--
Russ Allbery (r...@debian.org) <http://www.eyrie.org/~eagle/>
ly different flag. I find that behavior
really unintuitive and surprising.
Most people don't want to enter in random prefixes of flags. There are
usually specific things that they think to enter. For that, it feels
cleaner to just add them as explicit aliases.
--
Russ Allbery (r..
obably won't for the forseeable future.
Quite happy to have someone else pick it up if they have the inclination.
--
Russ Allbery (r...@debian.org) <http://www.eyrie.org/~eagle/>
ckage
> will FTBFS for anyone building it.
Thanks for the report! I won't get a chance to get to this until this
weekend, but I'll definitely take a look and try to get it fixed then.
--
Russ Allbery (r...@debian.org) <http://www.eyrie.org/~eagle/>
Carlos Alberto Lopez Perez <clo...@igalia.com> writes:
> Attackers usually don't start trying to probe exploit after exploit.
Of course they do. That is, *by far*, the most common attacker strategy
on the Internet. Just look at the logs of any Internet-facing service.
--
Russ A
pin matching a Package: google-chrome-stable entry.
>> 1 http://dl.google.com/linux/chrome/deb stable/main amd64 Packages
> This shows the pin value for that source, that is, Package: * pins.
Ah! Apologies -- I completely misread that. Thank you for the
information!
--
Russ A
Package: apt
Version: 1.2.3
Severity: normal
I have the following files in /etc/apt/preferences.d:
==> google-base.pref <==
Package: *
Pin: origin dl.google.com
Pin-Priority: 1
==> google-chrome.pref <==
Package: google-chrome-stable
Pin: origin dl.google.com
Pin-Priority: 100
The goal is to
inary-package" to help people who misplace the field)?
Yeah, that sounds good to me.
--
Russ Allbery (r...@debian.org) <http://www.eyrie.org/~eagle/>
ated things
with putting this field into separate binary package stanzas instead of
just in the source package stanza.
--
Russ Allbery (r...@debian.org) <http://www.eyrie.org/~eagle/>
forgot about that until just
after I uploaded it.
I'll open a bug against release.debian.org for the mini-transition.
--
Russ Allbery (r...@debian.org) <http://www.eyrie.org/~eagle/>
Package: release.debian.org
Severity: normal
User: release.debian@packages.debian.org
Usertags: transition
Mini-transition for log4shib. All of the packages that depend on it are
part of the shibboleth-sp2 suite. There will also be a transition for
opensaml2 along the way, which has to
og4shib propagates everywhere just in case.
--
Russ Allbery (r...@debian.org) <http://www.eyrie.org/~eagle/>
Ferenc Wagner <wf...@niif.hu> writes:
> Russ Allbery <r...@debian.org> writes:
>> I think I was just confused and everything is fine, since the
>> transition already happened after the previous NMU. There's still a
>> transition for opensaml2 and shibbol
Ferenc Wagner <wf...@niif.hu> writes:
> Please wait a little, I'm packaging the new upstream anyway and will
> introduce this change soon (I'll need a sponsor, though).
I should be able to help with sponsorship.
--
Russ Allbery (r...@debian.org) <http://www.eyrie.org/~eagle/>
em. I think it only
encrypts the control channel, if that.
--
Russ Allbery (r...@debian.org) <http://www.eyrie.org/~eagle/>
d a bunch of features, so some folks may just not have bothered to
ever set that up.
--
Russ Allbery (r...@debian.org) <http://www.eyrie.org/~eagle/>
7).>, __len=6,
> __len@entry= detected (257).>) at /usr/include/x86_64-linux-gnu/bits/string3.h:53
> 53
Hrm. Okay, so the compiler is doing something weird, and this isn't a
problem with libtasn1. Thanks for the additional information! I'm going
to reassign this to gcc-5, and
Matthias Klose <d...@debian.org> writes:
> On 14.12.2015 01:26, Russ Allbery wrote:
>> Now reassigning to the correct package. See the earlier messages in
>> the bug log for more information. The short version is that gnubg when
>> built with any optimization at
Control: reassign -1 gcc-5
Russ Allbery <r...@debian.org> writes:
> Hrm. Okay, so the compiler is doing something weird, and this isn't a
> problem with libtasn1. Thanks for the additional information! I'm
> going to reassign this to gcc-5, and might upload a package bui
work, but I could have sworn the
version I uploaded wasn't built with PIE.
I can reproduce this, trying to figure out what's going on right now.
--
Russ Allbery (r...@debian.org) <http://www.eyrie.org/~eagle/>
nstable and running gnubg. To get the above backtrace, I just
grabbed the source package, did apt-get build-dep gnubg, debian/rules
build, and installed the debugging packages for libgnutls and libtasn1.
--
Russ Allbery (r...@debian.org) <http://www.eyrie.org/~eagle/>
://www.openssh.com/legacy.html
It sounds like the remote host to which you're trying to connect only
offers ssh-dss keys, which are no longer supported by default (following
upstream) because they're not very secure.
This is unrelated to host key checking or IP checking. It's about the
ty
RCE_DATE_EPOCH support from podlators-4.00
> doesn't itself survive being build with SOURCE_DATE_EPOCH (or
> POD_MAN_DATE, for that matter) set. Patch attached.
podlators 4.03 released with this fix.
--
Russ Allbery (r...@debian.org) <http://www.eyrie.org/~eagle/>
rsion, probably this weekend.
--
Russ Allbery (r...@debian.org) <http://www.eyrie.org/~eagle/>
n of OpenAFS.
--
Russ Allbery (r...@debian.org) <http://www.eyrie.org/~eagle/>
, and this is also broken in
stable. I think it's arguably serious severity, since not being able to
check HTTPS URLs is a pretty major limitation. It's at least important
(upgrading now).
--
Russ Allbery (r...@debian.org) <http://www.eyrie.org/~eagle/>
n *_source.changes generated by the build inside pbuilder,
since that isn't bogus, but of course it's only generated if you do a
source-only build. (Otherwise, the changes file will have the binary
architecture in the name.)
--
Russ Allbery (r...@debian.org) <http://www.eyrie.org/~eagle/>
a level of false positives lead people to stop running a lint
program completely, which then significantly reduces its usefulness to the
project as a whole.
--
Russ Allbery (r...@debian.org) <http://www.eyrie.org/~eagle/>
em to do so, feel free. You already have all the
tools that you need to take this on personally. But this is not the
purpose of the Lintian tool.
--
Russ Allbery (r...@debian.org) <http://www.eyrie.org/~eagle/>
requently is the word intended. (For example,
consider intrusion detection systems designed to look for illegal activity
from one's local system.) The GNU usage recommendation is in a specific
context around actions in software, and Lintian is not bright enough to
read for context.
--
Russ
Package: golang-golang-x-tools
Version: 1:0.0~git20150716.0.87156cb+dfsg1-4
Severity: serious
Unpacking golang-golang-x-tools (1:0.0~git20150716.0.87156cb+dfsg1-4) ...
dpkg: error processing archive
/var/cache/apt/archives/golang-golang-x-tools_1%3a0.0~git20150716.0.87156cb+dfsg1-4_amd64.deb
Guido Günther <a...@sigxcpu.org> writes:
> I've applied the attached patch in git-buildpackage. Can this go
> upstream?
Merged in git-pbuilder 1.37 with a few minor changes, and now released.
Thank you!
--
Russ Allbery (r...@debian.org) <http://www.eyrie.org/~eagle/>
ing I should probably switch
to some new TrueType thing, but I've yet to find one that I like as well
as Neep.
--
Russ Allbery (r...@debian.org) <http://www.eyrie.org/~eagle/>
r version if you were planning on taking over
maintenance.)
--
Russ Allbery (r...@debian.org) <http://www.eyrie.org/~eagle/>
is would benefit from a broader discussion than just the
Policy list, but I'm not sure how to go about that, or what teams in
particular should weigh in.
--
Russ Allbery (r...@debian.org) <http://www.eyrie.org/~eagle/>
my brain sees four parts and really struggles with parsing it as a
date.
Plus sort of helps a little, but 9+2011.12.11 still looks rather confusing
to me. I expect that version to indicate a Git snapshot of development
following a version 9 release.
--
Russ Allbery (r...@debian.org) <http://www.eyrie.org/~eagle/>
f, just don't be too concerned about the fate of
> the current versions in unstable, expect new upstream versions after a
> couple of weeks.
If you're changing the SONAME anyway, you don't have to do the renaming
described here. That's actually an even cleaner solution.
--
Russ Allbery (
Arno Töll a...@debian.org writes:
we agreed that we should change Lintian to accommodate these
changes. The fix would be, to raise this Lintian error only if a package
depends on apache2-bin but not on apache2-api-MMNN.
Ah, yes, that would work.
--
Russ Allbery (r...@debian.org
an extension that
indicates they were intentionally encoded in some other encoding?
--
Russ Allbery (r...@debian.org) http://www.eyrie.org/~eagle/
You need a passphrase to unlock the secret key for
user: Russ Allbery ea...@eyrie.org
2048-bit RSA key, ID 7D80315C5736DE75, created 2010-09-17
(subkey on main key ID D15D313882004173)
gpg: gpg-agent is not available in this session
(for example). I do have one running:
mithrandir:~$ ps
Package: lintian
Version: 2.5.36.1
Severity: normal
The apache2-module-depends-on-real-apache2-package appears to either be
bogus or be pointing to a bug in dh_apache2. I get:
E: libapache2-mod-webauth: apache2-module-depends-on-real-apache2-package apache
2-bin
N:
N:The package is an
Russ Allbery r...@debian.org writes:
This is all made worse by the fact that the DEBSIGN_PROGRAM environment
variable is apparently ignored by debsign, so at least for me this
pretty much breaks my signature workflow for packages. I'll report that
bug separately.
Ah, never mind this. I
for it. After watching a lot of these threads, I'm increasingly
feeling like we've been too conservative in adding things to common
licenses and haven't been trading disk space for developer time in the
most efficient way. (That said, we still don't want to go wild with extra
licenses.)
--
Russ
not a native speaker of English.
As a native speaker, I wouldn't find this confusing due to context, but
indeed, day of the week is more correct.
--
Russ Allbery (r...@debian.org) http://www.eyrie.org/~eagle/
to get particularly excited about doing work to try to enable it, and
it feels really dubious to do it by breaking the command-line option
everyone is used to using.
--
Russ Allbery (r...@debian.org) http://www.eyrie.org/~eagle/
the user to run cowbuilder,
and since that gives the user root on the local host without a whole lot
of work, I'm not sure if it's something we want to set up by default.
--
Russ Allbery (r...@debian.org) http://www.eyrie.org/~eagle/
Just one more data point:
I just upgraded another system using assword, with a separate private key
that was generated on 2014-08-20, and everything worked fine with it. And
I don't get the legacy keys errors on that system either.
--
Russ Allbery (r...@debian.org) http
successfully imported. Just not that one.
do you know if there were more legacy key messages for the second
--import command?
Oh, yeah, there are tons every time I run that command. Basically one for
every key.
--
Russ Allbery (r...@debian.org) http://www.eyrie.org/~eagle/
D15D313882004173
gpg: using classic trust model
pub rsa4096/D15D313882004173 2009-05-29 [expires: 2017-09-17]
uid [ultimate] Russ Allbery ea...@eyrie.org
uid [ultimate] Russ Allbery r...@stanford.edu
uid [ultimate] Russ Allbery r...@debian.org
uid
change. See attached patch. Please consider.
This makes sense to me. Would you consider adding this to git-pbuilder
ustream?
Yup, sorry about the delay. Now done, and git-pbuilder 1.35 has been
released.
--
Russ Allbery (r...@debian.org) http://www.eyrie.org/~eagle/
Package: lintian
Version: 2.5.36.1
Severity: minor
I see:
X: libnet-duo-perl: perl-module-name-not-mentioned-in-description Net::Duo
However:
Package: libnet-duo-perl
Architecture: all
Depends: ${perl:Depends}, ${misc:Depends}, libjson-perl,
libperl6-slurp-perl, libsub-install-perl,
)= 0
write(2, Assword database error: Decrypti..., 59Assword database error:
Decryption error: Decryption failed) = 59
--
Russ Allbery (r...@debian.org) http://www.eyrie.org/~eagle/
[ultimate] Russ Allbery ea...@eyrie.org
uid [ultimate] Russ Allbery r...@stanford.edu
uid [ultimate] Russ Allbery r...@debian.org
uid [ revoked] Russ Allbery ea...@windlord.stanford.edu
uid [ultimate] Russ Allbery r...@cs.stanford.edu
sub 4096R
Package: assword
Version: 0.8-2
Severity: grave
assword can no longer decrypt any of my password stores. It fails with
the error:
mithrandir:~$ assword dump foo
Assword database error: Decryption error: Decryption failed
The data store is not corrupt; running GnuPG on it manually works fine.
noting that I have a somewhat different approach
on how fast to commit changes. I'm a huge believer in lazy consensus and
in the power of reverts, so I tend towards committing things and reverting
them if needed, rather than waiting on the first commit.
--
Russ Allbery (r...@debian.org
simplifies parsing mildly.
(Obviously, dpkg is free to be more generous, although it's convenient
when dpkg aligns with Debian Policy in a way that doesn't require writing
a separate Lintian rule.)
--
Russ Allbery (r...@debian.org) http://www.eyrie.org/~eagle/
--
To UNSUBSCRIBE
remctl_3.9-1.
Thanks for considering. Would be great if you can include the fix in
your next upload.
Will do! Sorry about the delay in getting to this. Work and apartment
moves and house guests have been devouring my brain.
--
Russ Allbery (r...@debian.org) http://www.eyrie.org/~eagle
moving to shorten my commute in the
hope to make it larger, but of course in the short term that makes it
smaller :)
I've not forgotten about this, and I'll try to get to it as soon as I can.
--
Russ Allbery (r...@debian.org) http://www.eyrie.org/~eagle/
--
To UNSUBSCRIBE, email
doesn't make me a
particularly unbiased judge of consensus.)
--
Russ Allbery (r...@debian.org) http://www.eyrie.org/~eagle/
--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Control: tags -1 pending
Andreas Schmidt p...@arcor.de writes:
ttf-dejavu is a dummy package. Please consider to let gnubg-data depend on
fonts-dejavu instead!
Thanks for letting me know. Queued up for the next upload.
--
Russ Allbery (r...@debian.org) http://www.eyrie.org
. :/
--
Russ Allbery (r...@debian.org) http://www.eyrie.org/~eagle/
--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
of the staleness of the
documentation and the recentness of the last release of the software.
While this isn't a huge deal, it does feel somewhat less than ideal to
lose that data. Replacing it with the last modification date of the
Debian package isn't perfect, but it's fairly reasonable.
--
Russ Allbery
on a new release (unfortunately slowly).
--
Russ Allbery (r...@debian.org) http://www.eyrie.org/~eagle/
--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
is that we'll eventually have some standard mechanism to
support this in the PAM configuration system, so that people who want to
use the method that you're using can select the alternate profile for how
the PAM module is configured.
--
Russ Allbery (r...@debian.org) http
and don't have any real defensible
reason to care about. Or carrying really tedious and hard-to-maintain
diffs.
I think we should just drop it.
However, copying Colin, as I think he should weigh in on this as man-db
maintainer and groff maintainer.
--
Russ Allbery (r...@debian.org) http
901 - 1000 of 6053 matches
Mail list logo
