quests/1
Regards,
--dkg
From 0fc8d1c532f5720c7f5a58f48b7b6eb2cc44c62e Mon Sep 17 00:00:00 2001
From: Daniel Kahn Gillmor
Date: Wed, 20 Mar 2019 13:57:11 -0400
Subject: [PATCH] set use_pty by default (Closes: #657784)
---
debian/sudoers | 1 +
1 file changed, 1 insertion(+)
diff --git
Package: devscripts
Version: 2.19.3
Severity: normal
libassuan has only Werner Koch's key listed as a potential signing key
in debian/upstream/signing-key.asc.
libassuan upstream released a new tarball that is signed by *both*
Werner and NIIBE Yutaka (another assuan developer).
uscan complains a
On Tue 2019-03-19 17:54:30 -0400, Daniel Kahn Gillmor wrote:
> 4) (optionally) confirm that the tag commit message matches some
> pattern. For example, if i think i'm verifying version 1.17 of the
> Foo project, i might want to confirm that the first line of the
> m
On Wed 2019-03-20 09:41:02 +0100, Guido Günther wrote:
> This sounds all good to me. To add some bikeshedding I'd do it like
>
> --upstream-vcs-tag-check=
>
> so we can have things like:
>
> --upstream-vcs-tag-check=signature,format
That sounds totally reasonable to me. The concreteness of my
Package: git-buildpackage
Severity: wishlist
Hi gbp folks--
I use gbp with upstream-vcs-tag to keep my debian packaging in sync with
upstream repositories. It's really great!
I'd like to automate my workflow a little bit more, though: one of the
common things that i do is to verify the upstream
Package: posh
Severity: wishlist
Currently posh creates heredocs in the filesystem. This means that
heredoc contents will unnecessarily touch the disks, and it also means
dealing with risky juggling of tempfile names.
It would be nicer, on platforms that support it, if posh could use
memfd_creat
On Mon 2019-03-18 10:55:44 +0100, Tim Rühsen wrote:
> Libiconv 1.15 itself from tarball.
>
> If you are interested in the details, have a look at our CI Dockerfile
> where we build/install the dependencies needed for testing:
>
> https://gitlab.com/gnuwget/build-images/blob/master/docker-debian-min
On Sun 2019-03-17 13:14:54 +0100, Tim Rühsen wrote:
> Fixed it by building my own libiconv on MinGW systems. It really is
> straight forward and possibly no extra Debian package is needed.
Thanks for the feedback, Tim. For your fix, are you building libiconv
itself, or win-iconv for MinGW systems
1-3) unstable; urgency=medium
+
+ * knot-resolver-module-http is arch: all, not arch: any
+ * Explicitly list all non-arm64 architectures
+
+ -- Daniel Kahn Gillmor Fri, 08 Mar 2019 00:56:09
-0500
+
+knot-resolver (3.2.1-2) unstable; urgency=medium
+
+ * Standards-Version: move to 4.3.0 (no
Control: affects 874029 + src:notmuch
On Sat 2017-12-30 15:12:14 +0900, Mike Hommey wrote:
> I can't tell you how many, but I can tell you that's how Mozilla does it
> too, so this applies to firefox, thunderbird, nspr and nss:
notmuch does it as well:
https://notmuchmail.org/releases/
https:
Package: release.debian.org
Severity: normal
Tags: stretch
User: release.debian@packages.debian.org
Usertags: pu
Control: affects -1 src:publicsuffix
Please consider an update to publicsuffix in debian stretch.
This package reflects the state of the network, and keeping it current
is useful f
Hi GNU Mailutils developers--
Are you aware of this report in debian about mail discarding stdin when
being used to send an e-mail with an attachment?
https://bugs.debian.org/918806
I can confirm that it's happening with mailutils 3.5, but have not
tested 3.6 against it, and i see no mention
Mailutils 3.5)
Message-Id: <20190313144838.daaf420...@fifthhorseman.net>
Date: Wed, 13 Mar 2019 10:48:38 -0400 (EDT)
From: Daniel Kahn Gillmor
--225007733-1552488518=:22450
Content-Type: text/plain; charset=UTF-8
Content-Disposition: attachment
Content-ID: <20190313104838.2245...@alice.f
Control: tags 921904 + help
On Sat 2019-02-09 23:50:03 +, Santiago Vila wrote:
> Package: src:win-iconv
> Version: 0.0.8-2
> Severity: serious
> Tags: ftbfs
>
> Dear maintainer:
>
> I tried to build this package in buster but it failed:
>
> -
On Tue 2019-03-12 15:01:26 +, Simon McVittie wrote:
> If I understand their position correctly, the Debian systemd maintainers
> would consider that to be a misconfiguration, because
> Depends: libpam-systemd is the official way for a package to say "I need
> a fully working systemd-logind and
Control: severity 911768 normal
Hi Simon --
Thanks for this detailed triage!
On Sun 2019-03-10 14:35:04 +, Simon McVittie wrote:
> I think this should be considered to be a pinentry-gnome3 bug rather than
> nfs-kernel-server. I think the plausible routes forward are to either
> escalate dbus
Hi Mika--
On Thu 2019-03-07 16:16:40 +0100, Michael Prokop wrote:
> So sadly wireguard didn't make it into buster. :(
yep, frustrating. but that was by design -- it isn't clear to me that
the ecosystem will be happy with having a wide distribution of an
outdated (2019) version running in 2021 :/
Package: src:knot-resolver
Version: 3.2.1-3
Control: block -1 with 840619
Control: clone -1 -2
Control: retitle -1 knot-resolver: Avoid embedding a copy of the Epoch
javascript library
Control: reassign -2 src:libminion-perl 9.09+dfsg-1
Control: retitle -2 libminion-perl: Avoid embedding a copy of
Package: ftp.debian.org
Severity: normal
Control: affects -1 src:knot-resolver libkres9 libkres-dev
NOTE: this is just a request for removal of the libkres9 and libkres-dev
binary packages on arm64. please do *not* remove the knot-resolver
source package, or the knot-resolver binary package on an
Package: src:knot-resolver
Version: 3.2.1-2
Control: block -1 with 749603
Control: user p...@debian.org
Control: usertag + embed
Control: clone -1 -2 -3 -4
Control: retitle -1 knot-resolver: Avoid embedding a copy of dygraphs
Control: reassign -2 src:r-cran-dygraphs 1.1.1.6+dfsg-1
Control: retitle
On Thu 2019-03-07 21:37:30 +0100, Daniel Baumann wrote:
> i've verified this with another vanilla system that wasn't upgraded and
> i can reproduce it there: 3.2.0-1 fixed it.
Weird! This bug was reported against 3.2.0-1 in the first place, so i'm
pretty confused :/ But at least it's gone away :
Package: libkres-dev
Version: 3.2.1-1
Severity: grave
Justification: renders package unusable
A little over half of the header files shipped in libkres-dev contain
an #include line that refers to other files in "lib/…", for example:
#include "lib/defines.h"
You can see these with:
grep -n '
Control: tags 922120 + moreinfo
Hi Daniel--
On Tue 2019-02-12 11:54:55 +0100, Daniel Baumann wrote:
> thank you so much for maintaining knot-resolver, it's wonderful.
Glad you find it useful!
> Unfortunately, whenever *any* service is reladed on my system (vanilla
> debian with 'apt install kno
On Tue 2019-03-05 10:57:03 -0800, Felix Lechner wrote:
> With source format 3.0 (git) that logic even found a way into the packaging
> system. Let's flip it around for a moment: Why not validate upstream
> signatures when the package is built?
sorry, i think i'm still not following. I *do* valida
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 entropy.
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 ma
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/T3894)
I
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. Ide
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, https://sks-keyserver
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 str
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 db
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 db
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 desc
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-resolve
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 knot-resol
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, than
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" bu
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 repo
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 th
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|") do
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 the
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 lo
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 star
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 o
? -> 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]:
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 sy
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?
here
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 start-s
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 tha
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 a
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 wr
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 ship
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',
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 already
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 t
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. Up
n importing 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
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 malforme
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: orig-tarball-missi
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 the
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: MONKEYSPHERE_TEST
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 /usr/shar
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 requi
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
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
/tmp/cdtemp.afhJme/publishco
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 ;-). M
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
/home/dkg/tmp/openc
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 SALSA_PRIVATE_TOKEN
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 thei
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 na
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 packag
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 longe
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 -> /usr/lib/$ARCH_TRIPLET/nss/libnssckbi
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 .service
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 pref
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, some
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 sh
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.
801 - 900 of 4350 matches
Mail list logo
