On Tue 2019-03-05 18:48:11 +0100, Santiago Vila wrote:
> https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=907191
ugh :(
> I'll take a look at the kernel feature to see if it's better than this.
fwiw, the change isn't in the kernel -- it's in how userspace talks to
the kernel to get its
Re: https://bugs.debian.org/850269:
I'm closing this bug report against gpgme because the underlying problem
was solved in libgcrypt. There isn't really a version of gpgme which
fixes the problem (the tests do apparently use --debug-quick-random in
1.8.1, but with the updated gcrypt that won't
On Thu 2019-01-24 15:12:24 -0500, Daniel Kahn Gillmor wrote:
> re: https://bugs.debian.org/841208 --
>
> entropy exhaustion should no longer be an issue on debian buster, since
> the gcrypt started using getrandom() as of gcrypt 1.8.4 (see upstream
> https://dev.gnupg.org/T389
Hi Jim--
On Fri 2019-03-01 18:01:52 -0500, Jim Popovitch wrote:
> Daniel, The problem (and I know this isn't Debian specific, but it does
> affect Debian users of dirmngr) is that the servers in hkps.pool.sks-
> keyservers.net exist in Europe, whereas ha.pool and na.pool have greater
> access.
Hi Jim--
On Thu 2019-02-28 14:51:07 -0500, Jim Popovitch wrote:
> When a client uses HKPS keyservers dirmngr fails hard due to TLS
> certificate validation errors:
what pool are you using in particular? it looks to me like you're using
"ha.pool.sks-keyservers.net"
However,
Package: dmarc-cat
Version: 0.9.2-1
Severity: normal
https://tools.ietf.org/html/rfc7489#section-7.2.1.1 says:
--
filename = receiver "!" policy-domain "!" begin-timestamp
"!" end-timestamp [ "!" unique-id ] "." extension
unique-id = 1*(ALPHA / DIGIT)
--
But:
Package: dmarc-cat
Version: 0.9.2-1
Severity: normal
0 dkg@alice:~/tmp$ man dmarc-cat
No manual entry for dmarc-cat
See 'man 7 undocumented' for help when manual pages are not available.
16 dkg@alice:~/tmp$ dmarc-cat --help
Usage of dmarc-cat:
-DDebug mode
-NDo not resolve IPs
-S
On Fri 2019-03-01 16:54:45 +0100, fulvio ciriaco wrote:
> I opened another session from VT with startx and
> exec dbus-launch awesome
> and the delay reappeared.
>
> The delay does not reappear with
> exec awesome
ok, so it works without "dbus-launch". in the scenario where you are
*not* using
On Thu 2019-02-28 16:13:27 +0100, fulvio ciriaco wrote:
>> gpg-connect-agent 'get_confirmation abc123' /bye
>>
>> does it have a delay on the system in question?
>
> Yes, it has the same long delay.
Ok, i think this identifies that the hang is happening in gpg-agent
itself.
>> do you have
Hi Felix--
On Wed 2019-02-27 13:07:20 -0800, Felix Lechner wrote:
> I wrote a Debian tool to create a shipping manifest with file-based
> hashes. Would it help to include that at the time of packaging? If the
> manifest is signed, we could do away with tarball signatures.
I think what you're
Control: severity 920695 important
On Thu 2019-02-28 22:06:09 -0500, Daniel Kahn Gillmor wrote:
> So i'm marking #920695 as fixed in 3.2.1-1 with the hope of getting all
> of these migrations to move forward.
I've tagged the shared git repo for both knot-dns and for knot-resolver
source p
Control: 920695 fixed 3.2.1-1
I'm able to rebuild knot-resolver just fine on stretch, when i build
3.2.1-1 against a backported knot 2.7.6-2. I'll be uploading those to
stretch-backports shortly, but they can't go in until they've reached
testing.
But knot won't go into testing untlik
On Tue 2019-02-26 16:36:05 -0500, Chris Lamb wrote:
> I'm afraid it would, and would not be visible on lintian.d.o, and
> would also give different results in different environments. Whilst
> there is no strict written policy about this anywhere, this just
> feels "kinda" wrong, alas.
gotcha,
Control: reassign 923068 gpg-agent 2.2.12-1
On Wed 2019-02-27 07:30:39 +0100, fulvio ciriaco wrote:
> the delay does not happen when getpin is called directly as in
> echo getpin | pinentry-gtk2
ok, so that means that the issue isn't in pinentry itself. It's
probably in gpg-agent or elsewhere.
Control: tags 843568 + patch
On Mon 2016-11-07 14:57:10 -0500, Daniel Kahn Gillmor wrote:
> With no ~/.TinyCA at all, try running:
>
> tinyca2
>
> hit cancel in the "Create a new CA" dialog box which pops up, and then
> click the "Quit"
On Tue 2019-02-26 14:24:11 +, Chris Lamb wrote:
> [ dkg wrote: ]
>> Ideally, lintian would verify that there exists a signed tag in the git
>> repo found at Vcs-Git: (from d/control) […]
>
> Lintian "cannot" talk to external sources, so this is out alas…
How about talking to the local git
On Mon 2018-11-05 13:02:33 +0100, Guido Günther wrote:
> the release file at
>
> http://security.debian.org/debian-security/dists/buster/updates/
>
> is signed by wheezy's key 8B48AD6246925553 which is no longer in
> debian-archive-keyring. This makes new installations fail that already
> enable
Package: xapers
Version: 0.8.2-1.1
Severity: normal
https://ci.debian.net/packages/x/xapers/unstable/amd64/ shows that
there are intermittent failures in the autopkgtest.
I suspect that the issue is when XAPERS_ROOT contains an underscore,
then the filtering (sed "s|$XAPERS_ROOT|XAPERS_ROOT|")
Control: tags 920763 - moreinfo
Hi Chris--
On Tue 2019-01-29 09:29:50 +0100, Chris Lamb wrote:
> Probably a silly question for this time in the morning but what is
> stopping you extracting the associated signature and calling it
> $origname.asc?
the signature matches the git commit, but not
Control: tags 923068 + moreinfo
Hi fc--
On Sat 2019-02-23 20:16:03 +0100, fc wrote:
> When pinentry-gtk2 is started, the input window appears after more
> than twenty seconds. For comparison pinentry-gnome3 and pinentry-qt
> appear in less than two seconds for the same request.
Can you take a
On Mon 2019-02-25 13:33:57 +0100, Werner Koch wrote:
> On Sun, 24 Feb 2019 16:56, joshud...@gmail.com said:
>
>> gpg-agent --server or directly from .profile (ssh sessions) by
>> gpg-agent --daemon.
>
> FWIW, actually gpg-agent is started on-demand from all tools requiring
> it. To explicitly
Control: forwarded 922006
https://code.launchpad.net/~dkimpy-milter-dev/dkimpy-milter/+git/dkimpy-milter/+ref/dkg/python3
On Mon 2019-02-11 03:02:30 -0500, Scott Kitterman wrote:
> I think the code changes are probably very small. I just did an SPF milter
> using pyspf and the python3 pymilter
Control: forwarded 922048
https://code.launchpad.net/~dkimpy-milter-dev/dkimpy-milter/+git/dkimpy-milter/+ref/dkg/socket-activation
On Mon 2019-02-11 17:15:53 -0500, Scott Kitterman wrote:
> In the near-term, I think we need to have two ways to start: one with systemd
> (socket activation) and
hon.
? -> Introduction and overview of IPython's features.
%quickref -> Quick reference.
help -> Python's own help system.
object? -> Details about 'object', use 'object??' for extra details.
In [1]: import Milter.utils
In [2]: M
Package: irqbalance
Version: 1.5.0-3
Severity: normal
irqbalance apparently now depends on runit-helper.
For systems without runit installed, that is a strange additional
dependency.
Would it be possible to remove that dependency (or move it to a
Recommends: or something) to help make simpler
Package: runit-helper
Version: 2.8.5
Severity: minor
runit-helper's Description claims to be an implementation detail of
dh-sysuser, but then only talks about dh-runit. I assume that
dh-sysuser is an entirely different thing than dh-runit, so i'm
confused.
Is this just a copy/paste error?
Control: clone 922353 -2
Control: reassign -2 dpkg
Control: retitle -2 start-stop-daemon should support socket-activation via the
sd_listen_fds(3) convention
Control: severity -2 wishlist
On Fri 2019-02-15 04:34:47 +0100, Guillem Jover wrote:
> Another option would be to implement this in
On Tue 2019-02-12 09:10:57 +0100, Ansgar wrote:
> Maybe a separate implementation (like opentmpfiles for tmpfiles) would
> be a better approach?
Yep, i see your point. I've now filed https://bugs.debian.org/922353 --
an ITP of a simple python3 implementation of the sd_listen_fds(3)
convention
Package: wnpp
Severity: wishlist
Owner: Daniel Kahn Gillmor
* Package name: socket-activate
Version : 0.1
Upstream Author : Daniel Kahn Gillmor
* URL : https://gitlab.com/dkg/socket-activate
* License : GPL
Programming Lang: Python
Description : Run
Control: clone 736859 -2
Control: retitle -2 dput-ng: Please set the default transport to use ssh-upload
On Wed 2019-02-13 12:15:33 -0500, micah anderson wrote:
> Daniel Kahn Gillmor writes:
>> So perhaps this bug report can be closed, since ssh.upload.debian.org
>> does appear to
On Mon 2019-02-11 17:15:53 -0500, Scott Kitterman wrote:
> I can see advantages to this approach. I took the path I did since I was
> implementing an opendkim replacement and that's how it's done there.
>
> I think the milter would have to do something obnoxious like fail to start if
> it had
On Mon 2019-02-11 10:31:12 -0500, Scott Kitterman wrote:
> The one trick I don't think that can be managed this way is that currently
> dkimpy-milter reads the private key files as root and then drops privileges
> so
> that it doesn't have access to the key while running (it's only in memory).
Package: src:systemd
Version: 240-5
Severity: wishlist
More daemons are beginning to offer systemd-style socket activation,
which is a very nice feature for security and isolation.
However, those daemons are difficult to run on non-systemd systems, so
most upstream daemon authors continue to
On Mon 2019-02-11 10:25:48 -0500, Daniel Kahn Gillmor wrote:
> The default dupload target for debian is described this way in
> /etc/dupload.conf:
>
> $cfg{'ftp-master'} = {
> fqdn => 'ssh.upload.debian.org',
> method => 'scpb',
> incoming => '/srv
On https://bugs.debian.org/922006 Mon 2019-02-11 03:02:30 -0500, Scott
Kitterman wrote:
> It may be as little as using io.BytesIO vice StringIO.StringIO. Given it
> wasn't a bother for the SPF milter, I'll probably go ahead with it soon.
great, thanks! I'm happy to help test if you like.
Control: clone 736859 -2
Control: retitle -2 ftp.debian.org
Control: severity -2 wishlist
Control: retitle -2 Please grant DMs sftp/scpb access to ssh.upload.debian.org
On Sun 2019-02-10 18:38:48 +1100, Ben Finney wrote:
> On 27-Nov-2018, Daniel Kahn Gillmor wrote:
>> On 2018-11-2
Package: dkimpy-milter
Severity: wishlist
Version: 1.0.0-1
When running dkimpy-milter on a system that runs systemd, it would be
great to have it be socket-activated.
This would allow dkimpy-milter to avoid needing to drop privileges
(because systemd could start the daemon with privileges
Package: dkimpy-milter
Version: 1.0.0-1
Hi Scott--
I see that python3-milter exists now. it would be great to move
dkimpy-milter to python3 as well, so that mailserver administrators
using dkimpy-milter don't need to have python2 installed.
If you want a hand with the transition, i'd be happy
Package: xapers
Version: 0.8.2-1.1
Severity: normal
Using --file sometimes fails hard, even when the --source is supplied
that points to a source that knows how to pull files.
For example:
0 dkg@alice:~$ xapers add --source=arxiv:1809.00623 --file
Source 'arxiv:1809.00623' found in database.
g without a TTY (Closes: #913614)
+
+ -- Daniel Kahn Gillmor Thu, 07 Feb 2019 15:57:27 -0500
+
gnupg2 (2.1.18-8~deb9u3) stretch; urgency=medium
* block trivial access to scdaemon memory (Closes: #878952)
diff -Nru gnupg2-2.1.18/debian/patches/0094-gpg-Avoid-superfluous-sig-check-info-duri
On Wed 2019-02-06 17:11:16 +0100, Cyril Brulebois wrote:
> Hi,
>
> Adam D. Barratt (2019-02-04):
>> Control: tags -1 + confirmed d-i
>>
>> On Sun, 2018-11-18 at 12:38 -0500, Daniel Kahn Gillmor wrote:
>> > When fixing #906545 (GnuPG rejects some malfo
On Sun 2017-01-29 22:05:36 +, James Clarke wrote:
> I have attached a patch which hopefully fixes this. I have only tested
> it by extracting the new function to a separate perl script; it may or
> may not function incorrectly as-is, so beware!
It's really great to see a patch here.
This gap
On https://bugs.debian.org/914032, Daniel Kahn Gillmor wrote:
> Package: release.debian.org
> User: release.debian@packages.debian.org
> Usertags: pu
> Tags: stretch
> Severity: normal
> Control: affects -1 src:gnupg2
> Control: block 913614 by -1
>
> When fixing
Package: lintian
Version: 2.5.124
Severity: normal
Control: affects -1 src:wireguard
In wireguard's debian/watch, we have:
opts=mode=git,pgpmode=gittag
So we don't use an "upstream tarball" other than the git repo, which
has a signed tag in it. But lintian complains:
W:
looks like what's happening is that the parent bash process doesn't
invoke the process substitution itself. Rather, the subprocess that
will exec the command itself *first* spawns a grandchild process for the
process execution, before execing the expected command.
that means that wait(-1) of
re: https://bugs.debian.org/841208 --
entropy exhaustion should no longer be an issue on debian buster, since
the gcrypt started using getrandom() as of gcrypt 1.8.4 (see upstream
https://dev.gnupg.org/T3894)
--dkg
signature.asc
Description: PGP signature
Control: tags 920038 + help
On Mon 2019-01-21 21:10:04 +0100, Paul Gevers wrote:
> Since 2019-01-15 the autopkgtest of your package times out (after 5:33h)
> on ci.debian.net.
Thanks for the heads-up, Paul. Looking at this more closely:
> autopkgtest [02:55:29]: test command1:
Package: postfix
Version: 3.3.2-1
Severity: minor
Looks like the pointer from the lmtp manpage to the smtp manpage is
missing the "postfix" prefix:
0 dkg@alice:~$ man lmtp
man: can't open /usr/share/man/man8/smtp.8: No such file or directory
No manual entry for lmtp
16 dkg@alice:~$ zcat
Package: gnutls-bin
Version: 3.6.5-2
Severity: minor
In certtool(1), it says:
--key-type=string
Specify the key type to use on key generation.
This option can be combined with --generate-privkey, to specify
the key type to be generated. Valid
On Sat 2019-01-19 18:53:28 +0100, Sascha Steinbiss wrote:
> as you may not have noticed, I have prepared packaging for 1.0.0 in the
> gnome-keysign repo on Salsa [1]. It took some work because I had to
> switch everything to Python 3 due to dependency requirements (some
> Python modules newly
Package: gnome-keysign
Version: 0.9.8-1
Severity: wishlist
gnome-keysign 1.0.0 was released by upstream 11 days ago:
https://github.com/gnome-keysign/gnome-keysign/releases/tag/1.0.0
It would be great if we could have it in debian!
thanks for maintaining gnome-keysign,
--dkg
-- System
Package: emacs-common
Version: 1:26.1+1-3
Severity: normal
Tags: patch
Attached is an OpenPGP certificate (d...@aclu.org.key) which has three
User IDs, one of which is "d...@aclu.org" but another has no e-mail
address at all (it's just "Daniel Kahn Gillmor").
>From a new
Package: pelican
Version: 4.0.1+dfsg-1
Severity: normal
With a simple pelican installation with Atom category feeds enabled,
running "make publish" yields:
0 dkg@alice:/tmp/cdtemp.afhJme$ make publish
pelican /tmp/cdtemp.afhJme/content -o /tmp/cdtemp.afhJme/output -s
On Wed 2019-01-16 18:40:06 -0800, Sunil Mohan Adapa wrote:
> tags 656750 + patch
Thanks for this, Sunil! I'll try to review it soon. Feel free to ping
if i haven't moved on it in a few days.
--dkg
signature.asc
Description: PGP signature
On Thu 2019-01-17 07:07:02 +0100, Xavier wrote:
> Is this better?
>
> diff --git a/scripts/salsa.pl b/scripts/salsa.pl
> index 6cc9a234..e1084b20 100755
> --- a/scripts/salsa.pl
> +++ b/scripts/salsa.pl
> @@ -43,11 +43,17 @@ or
>
>SALSA_TOKEN_FILE=~/.dpt.conf
>
> -If you choose to link another
On Tue 2019-01-15 18:54:19 +0100, Xavier wrote:
> this feature allows one to use another file that contains one of this
> fields. This permits compatibility with dpt(1) tool (from
> pkg-perl-tools) which uses a ~/.dpt.conf that contains
>
> DPT_SALSA_PRIVATE_TOKEN=
>
> So this is not a bug ;-).
Package: inkscape
Version: 0.92.3-7+b1
Severity: normal
when i use "File»Import Clip Art…", inkscape creates the following
tree of directories with fixed names:
0 dkg@alice:~$ find $TMPDIR/openclipart -ls
3043836 0 drwxr-xr-x 4 dkg dkg80 Jan 16 10:33
Package: devscripts
Version: 2.19.2
Severity: minor
from "man salsa", i see:
-
If you choose to link another file, it must contain a line with
something like:
SALSA_PRIVATE_TOKEN=
SALSA_TOKEN=
-
But nothing else anywhere about
On Mon 2019-01-14 23:50:47 +, Chris Lamb wrote:
> Chris Lamb wrote:
>
>> > The gnupg2 source package version 2.2.9-1 has this mismatch because i
>> > was sloppy.
>>
>> So, debian/copyright contains:
>>
>>Files: debian/org.gnupg.scdaemo
On Sun 2019-01-13 20:40:08 +0100, Laurent Bigonville wrote:
> The problem is that if nothing is pulling the new package in the default
> installation, nobody will ever use it.
hm, this is true, but it's also likely to be true for a non-default
debconf choice as well, right? most people keep
On Sun 2019-01-13 19:07:42 +0100, Andreas Metzler wrote:
> The coding would be straightforward afaict.
>
> https://salsa.debian.org/gnutls-team/p11-kit/commits/tmp-704180-divertnss
I like the looks of this, though perhaps we want to name the new package
p11-kit-trust to be more in line with the
On Fri 2019-01-11 18:17:26 +0100, Laurent Bigonville wrote:
> The problem is what/who will decide if this package is installed? If
> that package is being pulled by on other package for some reason, that
> means that the local administrator will not be able to revert the
> decision of the
On Thu 2019-01-10 21:48:22 +, David Woodhouse wrote:
> On Thu, 2019-01-10 at 15:53 -0500, Daniel Kahn Gillmor wrote:
>> what's the advantage of using alternatives instead of a package-
>> specific displacement?
>
> None really, as long as you put it in a separate p
On Fri 2019-01-11 08:09:02 +, David Woodhouse wrote:
> Looking back, I see this bug was opened with the comment "With the
> recent switch of wheezy-security's iceweasel to using the
> embedded copy of nss..."
>
> That was 2014 though. Is it no longer the case?
i can confirm that it is no
On Thu 2019-01-10 19:14:06 +0100, Laurent Bigonville wrote:
> If I'm searching for a file called libnssckbi.so in the archive, the
> only other occurrence is in package libapache2-mod-nss.
afaict, that's just a symlink:
etc/apache2/nssdb/libnssckbi.so ->
On Wed 2019-01-09 22:57:03 -0500, Daniel Kahn Gillmor wrote:
> Please either drop Type=forking, or pass -B. Of those too choices, i
> think it's better to pass -B on the command line, so that the daemon
> has some mechanism of indicating readiness to systemd (detaching and
Package: hostapd
Version: 2:2.7-2
Severity: normal
Control: found -1 2:2.6-21
I'm running hostapd on a machine that is pure systemd.
I'm using the hostapd@.service generator.
when i do:
systemctl start hostapd@wlp1s0.service
it hangs for a while and then fails. This is because the
On Wed 2019-01-09 16:39:36 +0100, Laurent Bigonville wrote:
> So what is the status of this?
>
> In RHEL 7 they made the switch to p11-kit and libnssckbi.so is an
> alternative between the file shipped by nss and p11-kit-trust.so shipped
> by p11-kit (with p11-kit version being the default).
>
>
Control: clone 918318 -2
Control: reassign -2 hyphen-pl
Control: retitle -2 hyphen-pl: please provide symlinks for generic language
hyphenation dictionaries
On Mon 2019-01-07 18:25:08 +0100, Mattia Rizzolo wrote:
> On Fri, Jan 04, 2019 at 06:45:18PM -0500, Daniel Kahn Gillmor wrote:
&g
hyphenation dictionaries
On Mon 2019-01-07 18:30:32 +0100, Mattia Rizzolo wrote:
> On Fri, Jan 04, 2019 at 06:45:18PM -0500, Daniel Kahn Gillmor wrote:
>> ru → ru_RU (hyphen-ru)
>
> and this (from src:hyphen-ru)
>
>> te → te_IN (hyphen-te)
>
> and this (from src:hyphen-ind
Control: clone 918318 -2
Control: reassign -2 hyphen-lv
Control: retitle -2 hyphen-lv: please provide symlinks for generic language
hyphenation dictionaries
On Mon 2019-01-07 18:22:16 +0100, Mattia Rizzolo wrote:
> On Fri, Jan 04, 2019 at 06:45:18PM -0500, Daniel Kahn Gillmor wrote:
&g
Package: openconnect
Version: 7.08-3
Severity: wishlist
on the mailing list, i see that openconnect 8.01 is available
upstream. it's also tagged in the upstream git repository.
please package the new version for debian!
--dkg
-- System Information:
Debian Release: buster/sid
APT
Re: https://bugs.debian.org/913723:
i've always thought that sections were effectively impossible to have a
clear "correct" answer for some packages. hyphenation and spellcheck
dictionaries are quite clearly packages for localization (they are
meaningful in the context of, and necessary for,
Package: myspell-et
Version: 1:20030606-29
Severity: wishlist
as seen in #918318 and #918305, we're trying to get language-generic
symlinks added to hyphenation packages for the purposes of getting
pyphen packaged without shipping duplicate hyphenation dictionaries.
To acheive this, myspell-et
On Fri 2019-01-04 17:47:20 -0500, Daniel Kahn Gillmor wrote:
> Control: tags 918305 + patch
attached is a revised patch, which includes a en_Latn_US.dic symlink.
the merge request has already been updated.
regards,
--dkg
>From f8f0902e757b65b2bfcc6e2e3faaa844e9c00780 Mon Sep 17
Package: src:libreoffice-dictionaries
Version: 6.1.3-1
In the course of looking into pyphen packaging with Scott Kitterman, i
noticed that it expects symlinks from hyphenation files like hyph_af.dic
to hyph_af_ZA.dic. I filed https://bugs.debian.org/918305 against
hyphen-en-us for that package.
Package: src:hyphen
Version: 2.8.8-5
Severity: wishlist
the hyphen package hasn't had a release in several years.
however, there are several useful-looking changes (including cleanup in
the build scripts) in git (upstream uses
https://github.com/hunspell/hyphen for hosting, afaict).
It might be
From: Daniel Kahn Gillmor
Date: Fri, 4 Jan 2019 17:00:29 -0500
Subject: [PATCH 2/7] hyphen-en-us: provide fallback symlink for hyph_en.dic
(Closes: #918305)
---
debian/control| 1 +
debian/hyphen-en-us.links | 1 +
2 files changed, 2 insertions(+)
create mode 100644 debian/hyphen-en
Package: lintian
Version: 2.5.119
when checking the hyphen source package, lintian claims:
I: hyphen-en-us: wrong-section-according-to-package-name hyphen-en-us =>
localization
but all hyphen-* packages are Section: text, as hyphen-en-us is. (see
the source for libreoffice-dictionaries, which
Package: hyphen-en-us
Version: 2.8.8-5
Severity: wishlist
Some tools, like pyphen's test suite (see RFP
https://bugs.debian.org/917039) expect a fallback symlink from a
generic language to a region-specific language.
Please provide a fallback symlink from hyph_en.dic to hyph_en_US.dic
in
Package: debmirror
Version: 1:2.30
Severity: normal
sid is apparently currently signed by three keys -- automatic signing
keys for wheezy, jessie, and stretch. I can't justify this (i have no
idea why it should be signed by the wheezy signing key, for example),
but that shouldn't matter for
Control: reassign 918248 knot-resolver
Control: affects 918248 + hddemux
Control: forwarded 918248
https://gitlab.labs.nic.cz/knot/knot-resolver/issues/426
Hi Steve--
On Fri 2019-01-04 18:19:27 +, Steve McIntyre wrote:
> When building your package, I've found a bus error (aka alignment
>
On Tue 2019-01-01 08:24:51 +0100, Johannes Schauer wrote:
> I uploaded a NMU to DELAYED/10. Debdiff attached. Please cancel this upload in
> case you don't like it. :)
thank you for taking care of this, Johannes!
--dkg
signature.asc
Description: PGP signature
On Wed 2019-01-02 19:40:43 -0600, Rob Browning wrote:
> Daniel Kahn Gillmor writes:
>
>> Control: found 916012 1:26.1+1-2
>>
>> running emacs-gtk 26.1 from unstable, I still get crashes on U+2728
>> SPARKLES . I'm also seeing a crash when trying to render U+26C4 SNO
Control: found 916012 1:26.1+1-2
running emacs-gtk 26.1 from unstable, I still get crashes on U+2728
SPARKLES . I'm also seeing a crash when trying to render U+26C4 SNOWMAN
WITHOUT SNOW.
interestingly, U+1F332 EVERGREEN TREE gives no problems :)
A stderr transcript from one such crash:
X
Package: wnpp
Severity: wishlist
* Package name: pyphen
Version : 0.9.5
Upstream Author : Guillaume Ayoub
* URL : https://pyphen.org/
* License : GPL 2.0+/LGPL 2.1+/MPL 1.1
Programming Lang: Python
Description : Python hyphenation module
Pyphen is a
Package: wnpp
Severity: wishlist
* Package name: weasyprint
Version : 43
Upstream Author : Simon Sapin
* URL : https://weasyprint.org/
* License : BSD
Programming Lang: Python
Description : Visual rendering engine for HTML and CSS that can export to
Control: affects 911768 - gpg-agent
Control: affects 911768 + gcr
On Fri 2018-12-21 07:28:22 -0500, Theodore Y. Ts'o wrote:
> On Thu, Dec 20, 2018 at 03:17:03PM -0500, Daniel Kahn Gillmor wrote:
>>
>> I wonder whether we can rule out any interaction with gpg-agent itself
>>
Package: devscripts
Version: 2.18.10
Severity: normal
if i run uscan multiple times in a single source directory, each time
the signature gets *appended* to the appropriate *.asc file, rather
than replacing it. below is a transcript -- note that the *.asc grows
each time uscan is run:
0
Control: close 643341 1.33-3
hi all--
libgpg-error 1.33 is now in unstable, and it ships a pkg-config file.
Thanks to NIIBE for all his work on this!
as of 1.33-3, i'vem also added an autopkgtest that uses the pkg-config
file to ensure that a simple build works as expected.
Could any of the
On Mon 2018-12-10 00:16:06 +, J. Smith wrote:
> See https://debbugs.gnu.org/30045 and similar.
Thanks for this pointer, J. Smith. i agree that looks like the same
thing.
This is a pretty serious bug, including risks of data loss -- i've lost
draft e-mail messages simply from searching in my
Package: ekiga
Version: 4.0.1-9+b1
Severity: minor
man ekiga says:
-
DOCUMENTATION
More documentation is available in the manual available through Ekiga's
Help menu. There is also a FAQ at: http://www.ekiga.org
GETTING HELP
Feel free to join #ekiga on irc.gnome.org
Package: emacs-gtk
Version: 1:25.2+1-11
Severity: normal
Control: affects -1 + notmuch-emacs
I'm running emacs-gtk under X11.
When i try to open the attached file (sparkles.txt), emacs-gtk crashes
with the following backtrace. Sorry for it not being well-annotated,
i have emacs-gtk-dbg and
Package: wnpp
Severity: wishlist
* Package name: zlint
Version : 0.0.20181123
Upstream Author : Regents of the University of Michigan
* URL : https://github.com/zmap/zlint
* License : Apache 2.0
Programming Lang: Go
Description : X.509 certificate
Control: found 907060 4.18.20-2
On Thu 2018-08-23 12:31:29 -0400, Daniel Kahn Gillmor wrote:
> root@test:~# cat /proc/cmdline
> BOOT_IMAGE=/boot/vmlinuz-4.17.0-3-amd64
> root=UUID=44659876-4a68-4a3a-b3fa-0403eeb0c6ca
> ro console=ttyS0,115200n8
> root@test:~# dmesg | tail -n 3
Package: dpkg-dev
Version: 1.19.2
Severity: normal
Control: affects -1 libdnssec6
libdnssec.so.6.0.0 links against pthread, and uses pthread_once.
but dpkg-shlibdeps complains that it is found in none of the
libraries.
I think this is a bug in dpkg-shlibdeps. If not, please let me know
what
Control: forcemerge 913614 914944
Thanks for noting this, Lucas.
On Thu 2018-11-29 00:12:05 +0100, Lucas Nussbaum wrote:
> Importing the attached key fails when there's no tty.
This is the same as #913614, merging.
Note that #914032 proposes an update to stretch that fixes this
regression.
Control: reassign 911568 python3-gpg 1.12.0-4
Control: affects 911568 + impass
Control: forwarded 911568 https://dev.gnupg.org/T4271
Joey wrote:
> a) impass used to work despite that (it displated a red warning in the gui),
>and has for some reason stopped working due to a dependency upgrade,
On Tue 2018-11-27 13:07:12 +0100, Paride Legovini wrote:
> On Mon, 27 Jan 2014 Micah Anderson wrote:>
>> It would be nice if ssh-upload were the default transport for
>> uploading files in debian. Is there a particular reason why it isn't
>> set as the default now?
> While ssh-upload is clearly
Please remember to supply --batch whenever you invoke gpg from a script
or other automated tooling!
On Mon 2018-09-17 16:06:40 +0800, Paul Wise wrote:
> For keys only:
>
> gpg --home $(mktemp -d) file
Please don't use this form, it's broken and unsupported by upstream.
There is no explicit
801 - 900 of 4324 matches
Mail list logo
