On Mon 2024-04-22 20:17:54 +, Holger Levsen wrote:
> fixed in git.
thanks! I've just uninstalled the octopus, but i'll consider
reinstalling it later if this and some of the performance issues can be
ironed out (or maybe to help iron out the performance issues, visible
upstream at
Package: libsequoia-octopus-librnp
Version: 1.8.1-3
Severity: grave
X-Debbugs-Cc: Daniel Kahn Gillmor
Trying to install libsequoia-octopus-librnp:
/var/lib/dpkg/tmp.ci/preinst: 12: Syntax error: "fi" unexpected (expecting
"then")
dpkg: error processing archive
/tmp/apt-d
Control: reopen 1069202
Control: found 1069202 0.8.0-3
The symlinks in the gpg-from-sq and gpgv-from-sq packages appear to
point in the wrong direction. That is, gpg-from-sq installs a symlink
at /usr/bin/gpg-sq, which refers to gpg. Instead, gpg-from-sq should
install a symlink at
Package: gpg-from-sq
Version: 0.8.0-1
Severity: grave
X-Debbugs-Cc: Daniel Kahn Gillmor
I did:
apt install gpg-from-sq
and i expected to run `gpg --version` and see the resultant info from
the chameleon.
Instead, i see:
bash: gpg: command not found
I'm seeing the same issue
Source: rust-sequoia-chameleon-gnupg
Version: 0.8.0-1
Severity: grave
X-Debbugs-Cc: Daniel Kahn Gillmor
trying to upgrade from sequoia-chameleon-gnupg 0.5.1-1 to
sequoia-chameleon-gnupg 0.8.0-1, i see this:
```
Selecting previously unselected package gpg-sq.
Preparing to unpack .../gpg
On Sat 2024-04-06 16:20:33 +0800, Sean Whitton wrote:
> Thanks! Just to note that I also had to add python3-gssapi as a b-d.
That sounds reasonable. thanks for taking care of that, Sean!
--dkg
signature.asc
Description: PGP signature
On Sat 2024-04-06 11:40:14 +0800, Sean Whitton wrote:
> On Thu 04 Apr 2024 at 06:37pm -04, Daniel Kahn Gillmor wrote:
>
>> On Wed 2024-04-03 13:03:19 +0800, Sean Whitton wrote:
>>> Thanks, but can you sign this off? Ty!
>>
>> Sure, attached. Let me know if you ne
On Wed 2024-04-03 13:03:19 +0800, Sean Whitton wrote:
> Thanks, but can you sign this off? Ty!
Sure, attached. Let me know if you need anything different.
--dkg
From b522c1cc6201f75ab6103954016bbb719d4dd2fa Mon Sep 17 00:00:00 2001
From: Daniel Kahn Gillmor
Date: Tue, 30 Jan 2024 15
tch is worth applying generally, but given the flux around mypy
typing, i would also be fine with just recording the output of mypy
--strict instead of failing hard on it.
--dkg
From b522c1cc6201f75ab6103954016bbb719d4dd2fa Mon Sep 17 00:00:00 2001
From: Daniel Kahn Gillmor
Date: Tue, 30
Hi Salvatore--
On Fri 2023-06-02 21:20:50 +0200, Salvatore Bonaccorso wrote:
> Thanks for having a closer look and for your assessment. Then I
> believe we can have a fix scheduled via respective point releases, I
> do not see an urgency for it requiring a DSA. Initially I was not
> completely
t i intend to send to
bullseye-security:
From: Daniel Kahn Gillmor
Date: Thu, 1 Jun 2023 16:12:50 -0400
Subject: Resolve CVE-2023-30570
see https://libreswan.org/security/CVE-2023-30570/CVE-2023-30570.txt
This patch was ported from
https://libreswan.org/security/CVE-2023-30570/CVE-2023-30570-l
Control: clone 1034065 -1
Control: reassign -1 python3-argparse-manpage
Control: affects -1 src:sasl-xoauth2
Control: retitle -1 argparse-manpage doesn't run unless python3-setuptools is
installed
On Fri 2023-04-07 22:14:44 +0200, Andreas Beckmann wrote:
> sasl-xoauth2/experimental FTBFS on all
On Wed 2023-05-24 07:32:31 +0200, Salvatore Bonaccorso wrote:
> Thanks! Note the deadline for unblock requests will be on 28th. So the
> unblock needs to be granted by then so we have the fixes in bookworm.
The associated unblock request for 1034558 is #1036721
--dkg
signature.asc
In https://bugs.debian.org/1034558, Salvatore Bonaccorso wrote:
> Source: rnp
> Version: 0.16.2-1
> Severity: grave
> Tags: security upstream
> Justification: user security hole
> X-Debbugs-Cc: car...@debian.org, Debian Security Team
>
Thanks for tracking this in the BTS, Salvatore.
I aim to
Hi Andreas--
Thank you for addressing this problem, it is much appreciated!
--dkg
On Sun 2023-03-26 14:00:17 +0200, Andreas Metzler wrote:
> On 2023-03-18 Jonathan Wiltshire wrote:
>> Source: gnupg2
>> Version: 2.2.40-1
>> Severity: important
>> Tags: patch
>> X-Debbugs-Cc:
On Wed 2022-11-23 16:27:43 +0100, Andreas Metzler wrote:
> Unless kgpg maintainers/upstream has a strong opinion against using
> pkg-config the obvious choice would be to drop cmake/FindGpgme.cmake
> and simply use FindPkgConfig. - Attached patch seems to work for me,
> i.e. build including
Hi Timo--
On Tue 2022-11-22 15:58:21 +0100, Timo Röhling wrote:
> I have built neomutt with your patch and can confirm that the GPGme
> integration works as expected.
Thanks for confirming! It'd be great to clear the decks for the gpgme
transition, so please let me know if you'd like me to NMU
s also on salsa at
https://salsa.debian.org/mutt-team/neomutt/-/merge_requests/8 if that's
useful.
Please let me know if you'd like me to NMU it.
--dkg
From a9d3c0fe8c8e678311ad7a4810df6db519abc798 Mon Sep 17 00:00:00 2001
From: Daniel Kahn Gillmor
Date: Mon, 21 Nov 2022 19:10:20 -0500
Control: severity 1023601 important
Control: reassign 1023601 src:libgpg-error 1.46-1
Control: affects 1023601 + src:gpgme1.0 src:rust-libgpg-error-sys
src:rust-libgpgme-sys
Thanks Vincent for identifying the confusing and misdirected
documentation upstream, and thanks Andreas for triaging this
On Wed 2022-10-26 18:17:11 +0200, Andreas Metzler wrote:
> On 2022-10-26 Andreas Metzler wrote:
> [...]
>> Which has been promptly fixed. Find attached debdiffs for a proposed
>> upload. - I can also massage this into a mergew-request or push
>> directly to https://salsa.debian.org/debian/gpgme
Hi Andreas--
Thanks for this. I'm wrapping this up with a few other lintian fixes
and i should have a released version in unstable by later today or
tomorrow.
Thanks for helping out here!
--dkg
On Tue 2022-11-01 14:10:36 +0100, Andreas Metzler wrote:
> On 2022-10-23 Andreas Metzler
Control: reassign 1022783 librust-spin-dev 0.9.4-1
Control: affects 1022783 + librust-curl-dev
On Tue 2022-10-25 21:28:38 +0200, Jonas Smedegaard wrote:
> Package is impossible to install:
>
> # apt install librust-curl-dev
> Reading package lists... Done
> Building dependency tree... Done
>
On Mon 2022-10-17 22:16:15 +0200, Salvatore Bonaccorso wrote:
> Thanks for the offer. Andreas did already handle the bullseye-security
> update (DSA was just released) and Markus will handle the LTS upload.
great, many thanks to Andreas and Markus for taking care of this, and to
you Salvatore for
debian.net
> https://alioth-lists.debian.net/cgi-bin/mailman/listinfo/pkg-gnutls-maint
diff -Nru libksba-1.5.0/debian/changelog libksba-1.5.0/debian/changelog
--- libksba-1.5.0/debian/changelog 2020-12-24 02:06:58.0 -0500
+++ libksba-1.5.0/debian/changelog 2022-10-17 14:15:08.0 -04
On Mon 2022-10-03 08:51:05 +, Debian Bug Tracking System wrote:
> linphone (5.0.37-6) unstable; urgency=medium
> .
>* Import upstream fix for crashes on PUBLISH messages without
> SIP-Etags (Closes: #1021043).
Dennis, thanks for this prompt fix!
To confirm: I've upgraded to
Hi Dennis--
Thank you very much for the prompt response!
On Sat 2022-10-01 09:15:39 +0200, Dennis Filder wrote:
> It would help a lot to know the exact time when those crashes started.
> Can you try narrowing it down, e.g. by looking at the ctime of
> files/directories you created in reaction to
Package: linphone-desktop
Version: 4.3.2-2
Severity: grave
Justification: renders package unusable
X-Debbugs-Cc: d...@fifthhorseman.net
I've used linphone for years. Recently (i think with the upgrade to
4.3.2-2) it no longer works for me, crashing with a range of errors.
Working with my
Version: 0.25.0-1
On Wed 2021-03-10 10:43:38 +0100, Andreas Beckmann wrote:
> the binary packages built from src:rust-libsqlite3-sys depend on several no
> longer available packages, e.g.
>
> The following packages have unmet dependencies:
>librust-libsqlite3-sys+bindgen-dev : Depends:
>
Control: reassign 1010821 pypdf2/2.4.2-1
Control: forwarded 1010821 https://github.com/py-pdf/PyPDF2/issues/
Control: retitle 1010821 PyPDF2 fails to read a PDF file with a beginbfchar
entry with an empty second element
Control: affects 1010821 + src:xml2rfc src:weasyprint
On Tue 2022-05-10
Control: forwarded 1008573 https://dev.gnupg.org/T5935
Control: tags 1008573 + upstream
Control: severity 1008573 important
This bug report was tagged severity "serious"
https://www.debian.org/Bugs/Developer#severities says that severity
level means:
> is a severe violation of Debian policy
Hi Michael and Santiago--
I've now uploaded ldns 1.7.1-3 with the associated fix for 1009385. I'm
reviewing Michael's changes for 1.8.1, and they're looking good to me.
Thank you for all that work, Michael! I think we should consider
uploading 1.8.1 into experimental while we wait for 1.7.1-3
Thanks both Michael and Santiago for sorting this out!
I agree that backporting
https://github.com/NLnetLabs/ldns/commit/4d2057f0b5220487882be1b19c302833b84cffe3
to 1.7.1 is the most reasonable/conservative fix. We want that to
propagate into testing as soon as possible without risking being
Control: reassign 1009385 libldns3 1.7.1-2.1
Control: retitle 1009385 libldns3 1.7.1-2.1 changes output of ldns-key2ds,
causing FTBFS on dns-root-data
Control: affects 1009385 + dns-root-data
X-Debbugs-Cc: Michael Tokarev
Control: tags 1009385 + help
Lucas, thanks for flagging this!
The build
On Tue 2022-03-29 19:09:50 +0100, Simon McVittie wrote:
> Major GNOME components are expected to be upgraded together, except for
> when that's unnecessary. That is an unsatisfying answer, but unfortunately
> it's the only true answer.
Thanks for the clarification, Simon, even if it's
On Mon 2022-03-28 21:26:16 -0400, Jeremy Bicha wrote:
> This fix is pending
Thanks for the pending fix, Jeremy. I can't help noticing that this
failure looks like a classic backward-incompatible API change. The API
happens to be across a gsettings schema instead of a C library,
Version: 0.15.2-4
rnp upstream version 0.15 fixed the timestamp issues that were causing
https://bugs.debian.org/983770 on 32-bit architectures.
0.15.2-4 is the latest version of rnp in debian; if the builds are
successful, it should not be prohibited from migration to testing.
Version: 0.15.2-1
The RNP test suite no longer fails on test_key_add_userid as of version
0.15.2-1.
There are new failures on armel and armhf with
test_sym_encryption__rnp_aead, sigh, but i'll try to diagnose those in a
separate bug report.
--dkg
On Tue 2021-09-07 05:52:14 +0300, Adrian
Control: severity 989406 normal
Control: retitle 989406 wireguard-dkms is unneeded for stock kernels > 5.6
I'm downgrading the severity to keep wireguard-dkms in bullseye -- we
can increase it again once bullseye is released to keep wireguard-dkms
out of bookworm.
Adrian or others, if you would
On Thu 2021-06-03 01:37:25 +0300, Adrian Bunk wrote:
> Overall it feels like a package with high CVE risk and 0 users
> in bullseye.
I agree with Jason that some people may use non-standard, older kernels
with bullseye, so there is some value in continuing to provide
wireguard-dkms in bullseye to
Package: rnp
Version: 0.14.0-5
Severity: critical
Control: forwarded -1 https://github.com/rnpgp/rnp/issues/1436
RNP's test suites are failing on all of the 32-bit platforms in debian.
I've reported this upstream so that hopefully it can be resolved.
It should not migrate into testing in this
Thanks Paul for reviewing this, and Robert for looking into it further.
I think my conclusions differ a little bit from Robert's.
On Thu 2021-02-11 22:22:18 -0500, Robert Edmonds wrote:
> I have investigated this report. The purpose of the dns-root-data
> package is to ship, as static content,
Control: affects 975480 debcargo
On Sun 2020-11-22 19:21:45 +0100, Paul Gevers wrote:
> autopkgtest [09:47:16]: test librust-bzip2-sys-dev:
> /usr/share/cargo/bin/cargo-auto-test bzip2-sys 0.1.9+1.0.8 --all-targets
> --no-default-features
> autopkgtest [09:47:16]: test librust-bzip2-sys-dev:
Package: rust-sha1collisiondetection
Version: 0.2.2-1
Severity: critical
Control: forwarded -1
https://gitlab.com/sequoia-pgp/sha1collisiondetection/-/issues/1
Looks like rust-sha1collisiondetection code isn't as portable as
upstream expected it to be. It is failing on platforms with an
close 971105
thanks
sequoia dependencies are all sorted in unstable now that
rust-dyn-clone propagated out of NEW. See #971099 and #971717.
On Sun 2020-09-27 20:38:38 +0200, Lucas Nussbaum wrote:
> Source: rust-sequoia-openpgp
> Version: 0.18.0-1
> Severity: serious
> Justification: FTBFS on amd64
> Tags: bullseye sid ftbfs
> Usertags: ftbfs-20200926 ftbfs-bullseye
rust-dyn-clone made it out of NEW on 2020-10-09, so
On Sun 2020-09-27 20:38:50 +0200, Lucas Nussbaum wrote:
> Source: rust-sequoia-sqv
> Version: 0.18.0-2
> Severity: serious
> Justification: FTBFS on amd64
> Tags: bullseye sid ftbfs
> Usertags: ftbfs-20200926 ftbfs-bullseye
rust-sequoia-openpgp 0.18.0-1 is now in unstable, and rust-sequoia-sqv
close 971119
close 971124
thanks
These two FTBFS bug reports (for rust-nettle and rust-nettle-sys) were
happening because of #971139 on rust-bindgen.
When #971139 was resolved by rust-bindgen 0.51.1-5 (Sylvestre patched
the depenedencies in Cargo.toml), these other FTBFS bugs got solved as
Version: 0.17.2-5
On Sun 2020-09-27 20:38:00 +0200, Lucas Nussbaum wrote:
>> The following packages have unmet dependencies:
>> sbuild-build-depends-main-dummy : Depends:
>> librust-itertools-0.8+default-dev but it is not installable
>> E: Unable to correct problems, you have held broken
On Sun 2020-06-21 21:50:35 +0200, Lucas Nussbaum wrote:
> Source: rust-structopt-derive
> Version: 0.4.8-1
> Severity: serious
> Justification: FTBFS on amd64
> Tags: bullseye sid ftbfs
> Usertags: ftbfs-20200620 ftbfs-bullseye
>
> Hi,
>
> During a rebuild of all packages in sid, your package
On Sun 2020-06-21 21:50:37 +0200, Lucas Nussbaum wrote:
> Source: rust-structopt
> Version: 0.3.15-1
> Severity: serious
> Justification: FTBFS on amd64
> Tags: bullseye sid ftbfs
> Usertags: ftbfs-20200620 ftbfs-bullseye
[…]
>> The following packages have unmet dependencies:
>>
Control: found 953800 1.13.1-6
If checky2106 will always fail on 32-bit systems, that's a clear
indication that GnuPG will fail on those systems when it encounters
objects that have a timestamp that lands about 86 years out from now.
For example, an OpenPGP certificate with a 100-year expiration
On Fri 2020-03-06 10:16:13 +0100, Paul Gevers wrote:
> PS: these kind of timeouts are bad for our infrastructure. If this bug
> doesn't get fixed in a timely manner, I may add your package to our
> ignore-list.
Sorry about the delay in getting this fixed, Paul.
I believe the test suite will no
Control: tag -1 pending
Hello,
Bug #953230 in balsa reported by you has been fixed in the
Git repository and is awaiting an upload. You can see the commit
message below and you can check the diff of the fix at:
Control: severity 951025 normal
On Sun 2020-02-09 23:27:39 +, Matthew Wakeling wrote:
> I am justifying the severity marking of this bug report, because it
> does prevent gnupg working correctly in the majority of its use
> cases. If there is a nice simple on/off switch that makes it behave
>
Control: severity 951157 normal
Control: tags 951157 + unreproducible moreinfo
Hi Carlos--
On Thu 1970-01-01 00:00:00 +, carlosnewmusic wrote:
>* What led up to the situation?
> wireguard metapackage installation
>* What exactly did you do (or not do) that was effective (or
>
Version: 0.13.0-1
On Sun 2019-12-15 08:29:58 +0100, in #946747, Paul Gevers wrote:
> autopkgtest [03:58:52]: test command5:
> /usr/share/cargo/bin/cargo-auto-test buffered-reader 0.12.0
> --all-targets --features compression-deflate
> autopkgtest [03:58:52]: test command5:
Control: tags 943555 + help moreinfo
Control: severity 943555 important
Control: affects 943555 + linux-headers-5.3.0-1-arm64 gcc-9
Hi Chris--
Thanks for the report!
On Sat 2019-10-26 12:51:47 +, Chris. wrote:
> on Raspberry Pi3 kernel module stops building since updating to kernel
>
close 909994 0.5.2-2
thanks
python-pgpy 0.5.2-2 builds fine on the build daemons.
I suspect that the problem in #909994 was due to some breakage with
gpgme.
Hi Willem--
On Tue 2019-10-01 06:50:29 +0200, Willem van den Akker wrote:
> I offer by help for maintaining packaging WG.
Thank you, happy to have help!
> Please let me know how I can help.
Please make sure you can build the package from the debian/master branch
at
Version: 0.0.20190905-1
Over in 849...@bugs.debian.org, Daniel Kahn Gillmor wrote:
> I do plan for putting wireguard into buster-backports, since i expect
> the upstream inclusion issues to be resolved one way or another by the
> time of bullseye release. If anyone wants to help out
On Tue 2019-08-20 22:36:07 +0200, Martin Höfling wrote:
> first of all, my bananapi 2 died and I will replace it, probably with a
> newer arm board.
ouch, sorry to hear that.
> Package: linux-headers-4.19.0-5-armmp-lpae
> Version: 4.19.37-5+deb10u1
>
> Package: linux-headers-4.19.0-5-common
>
Control: tags 932015 + moreinfo
Hi Martin--
On Sun 2019-07-14 02:26:05 +0200, Martin Hoefling wrote:
> Package: wireguard-dkms
> Version: 0.0.20190702-1
> Severity: serious
> Tags: ftbfs
> Justification: fails to build from source (but built successfully in the past)
> Dear Maintainer,
>
>*
Hi Paul--
On Sat 2019-06-22 20:51:00 +0200, Paul Gevers wrote:
> On Tue, 14 May 2019 06:18:31 +0000 Daniel Kahn Gillmor
> wrote:
>> gnupg2 (2.2.13-2) unstable; urgency=medium
>> .
>>* Correct gpg-wks-server manpage (Closes: #927431) Thanks, ju xor!
>>
On Mon 2019-06-03 06:26:28 +0200, Salvatore Bonaccorso wrote:
> Source: libreswan
> Version: 3.27-4
> Severity: grave
> Tags: patch security upstream fixed-upstream
> Justification: user security hole
> Forwarded: https://github.com/libreswan/libreswan/issues/246
> Control: fixed -1 3.28-1
>
> The
Hi Debian buildd maintainers for our 64-bit big-endian platforms!
monkeysphere 0.43-3 FTBFS on ppc64, s390x, and sparc64. I traced the
problem down to https://bugs.debian.org/928963 in GnuPG, which is now
fixed upstream (https://dev.gnupg.org/T4501) and patched in debian
unstable.
This was a
resolves the issue when i test it on
zelenka.debian.org (s390x), and should also work on the other two
platforms.
--dkg
From e4a158faacd67e15e87183fb48e8bd0cc70f90a8 Mon Sep 17 00:00:00 2001
From: Daniel Kahn Gillmor
Date: Tue, 14 May 2019 00:05:42 -0400
Subject: [PATCH] agent: correct length for
Control: unarchive 909700
Control: forcemerge 909700 928684
Control: severity 909700 grave
Hi Andrei--
On Wed 2019-05-08 20:45:24 +, Andrei Morgan wrote:
> # monkeysphere-host import-key /etc/ssh/ssh_host_rsa_key
> ssh://server.example.net
> RSA.xs:194: OpenSSL error: no start line at
Package: powerpc-utils
Version: 1.3.2-1.1
Severity: grave
Justification: renders package unusable
Control: affects -1 grub-ieee1275
powerpc-utils Depends: pmac-utils, but pmac-utils is no longer in
debian.
This makes powerpc-utils uninstallable, which in turn makes
grub-ieee1275 uninstallatble.
On Fri 2019-04-12 09:41:11 -0400, Jamie McClelland wrote:
> Is it possible to back port this fix to debian stretch, stretch backports?
I've uploaded trac-tags 0.9-3~bpo9+1 to stretch-backports just now. I
think it has to go through the backports NEW queue before it's easily
available.
I've also
Control: tag -1 pending
Hello,
Bug #925596 in irssi-plugin-xmpp reported by you has been fixed in the
Git repository and is awaiting an upload. You can see the commit
message below and you can check the diff of the fix at:
Package: 2.8.0-1
Severity: serious
Flagging as serious because it's a policy violation.
autotools files, and install-sh, in various directories not accounted
for in d/copyright.
distro/deb presumably is GPL-3+ without the SSL exception.
contrib/ does not have the OpenSSL exception either ...
Package: irssi-plugin-xmpp
Version: 0.54-2.1
Severity: grave
Justification: renders package unusable
I get the following warnings from irssi when trying to use it with
irssi-plugin-xmpp:
10:49 -!- Irssi: xmpp/core is ABI version 13 but Irssi is version 20,
cannot
load
close 925374 2019031302
thanks
Package: dns-root-data
Version: 2018091102
Severity: serious
Control: found -1 2014060201+2 2017072601~deb8u1 2017072601~deb8u2
2017072601~deb9u1 2017072601~deb9u1
Control: fixed -1 2019031302
The versions of dns-root-data marked as "found" above ship a hash for a
root zone key that was retired
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:
>
>
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
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:
>
>
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
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: 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: 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 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: 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
>>
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.
ss.html
I'm not convinced that this is a change in unstable -- it appears to be
a bug in the test suite, which is fixed by the attached patch.
--dkg
From 3e6b1fa16887f105adf35599c922b452f8af0af4 Mon Sep 17 00:00:00 2001
From: Daniel Kahn Gillmor
Date: Tue, 27 Nov 2018 02:46:30 -0500
Subject: [PATCH 1
On Wed 2018-11-21 17:12:23 +0200, Adrian Bunk wrote:
> Fails:
> LC_ALL=C dpkg-buildpackage
>
> Builds:
> LC_ALL=C.UTF-8 dpkg-buildpackage
>
> Python 3.7 has a workaround for C locale.
>
> In debian/rules add:
> export LC_ALL=C.UTF-8
thank you, Adrian!
I've lost count of how many beers i owe you,
Control: tags 914269 + confirmed help
I see this error in my cowbuilder instance as well, but i don't see the
error when i build by hand on a buster/sid system.
more confusingly, this error crops up in python3.6, but not when
using python3.7 -- so i don't understand what the issue is, or how to
Control: tags 913614 + patch
The attached patch resolves the issue, and also introduces a test to
ensure that the problem is (and remains) fixed.
--dkg
>From 2e3b6845ea6c4762e86d281bcf83bf0e84315d8c Mon Sep 17 00:00:00 2001
From: Daniel Kahn Gillmor
Date: Fri, 16 Nov 2018 00:38:40 -0
I ran into the same issue on a powerpc installation.
On Mon 2018-11-12 17:16:10 +0100, Christoph Martin wrote:
> please try for me to change the value in line 271 from 65536 to a higher
> value which is high enough for your sources.list .
When i changed from 65536 to 655360, the
On Wed 2018-10-03 17:20:02 +0200, Moritz Mühlenhoff wrote:
> This is dead upstream and broken even in ESR, let's remove it
> from the archive?
agreed, i've just filed a RM/ROM bug report (#913215) on
custom-tab-width.
--dkg
Hi Tiziano--
thanks for following up here! I'm closing the bug report as you
recommended, but i wanted to add a little more followup in case someone
else reads this.
On Thu 2018-10-25 13:03:12 +0200, Tiziano Zito wrote:
> It has nothing to do with pinentry. Given that I have a system with
Hi Tiziano--
On Wed 2018-10-24 17:24:33 +0200, Tiziano Zito wrote:
> pinentry-gnome3 (but also pinentry-gtk-2) does not open a window anymore to
> ask for a passphrase. If run from terminal it shows:
>
> No Gcr System Prompter available, falling back to curses
> OK Pleased to meet you
>
> It was
Control: clone 909000 -2
Control: retitle -2 apt: error message "apt install enigmail" failure is
misleading
Control: reassign -2 apt 1.4.8
Control: severity -2 minor
On Mon 2018-10-22 08:28:50 -0400, Fabián Rodríguez wrote:
> This also fails in a clean Stretch install:
>
> # apt install
On Tue 2018-10-16 12:05:33 +0200, Carsten Schoenert wrote:
> yes, the problem here is Enigmail, not Thunderbird! But I don't see that
> this as a vulnerability per se from a security perspective.
> And you still can install the Mozilla AddOns manually into FF and TB.
> It's a loosing of comfort
forwarded 909837 https://github.com/libreswan/libreswan/issues/206
close 909837 3.27-1
thanks
On Fri 2018-10-12 12:36:12 +0200, Sven Joachim wrote:
> Control: tags -1 + patch
thank you, Sven and Helmut for your attention to this kind of detail.
I'm preparing an upload with these changes.
Y'all rock!
--dkg
On Wed 2018-10-10 17:30:33 +0200, Narcis Garcia wrote:
> The good solution for this is to move Thunderbird 60 to
> stretch-backports instead of being at normal repository.
>
> Normal users will keep current Enigmail 2:1.9 , current Thunderbird 1:52
> and current GnuPG 2.1 and not unstable
On Mon 2018-10-08 16:05:39 +0200, W. Martin Borgert wrote:
>> In the meantime, for enigmail, i've pushed a debian/stretch branch into
>> salsa with commit id b6e978d64af1defdfed876b09c8a57acb796ad72 as
>
> Did you push? I can't find the id. I would like to test.
thanks for testing! it appears
On Tue 2018-10-02 14:31:13 -0500, Daniel Kahn Gillmor wrote:
> I'm now working on figuring out what updates are needed to GnuPG in
> debian stable (stretch) to be able to get the enigmail test suite to
> pass. Hopefully they'll be minor, and comprehensible.
Turns out there were a h
1 - 100 of 450 matches
Mail list logo
