On Thu 2021-05-13 03:14:23 +, Paul Wise wrote:
> On Wed, 12 May 2021 23:00:52 -0400 Daniel Kahn Gillmor wrote:
>
>> This and zlint (#915788) are apparently the two dominant X.509
>> certificate checkers
>
> A third one by a Debian person is x509lint:
>
> https
On Thu 2021-05-13 10:47:55 +0800, Paul Wise wrote:
> Control: forcemerge 915788 988435
>
> On Wed, 12 May 2021 22:43:51 -0400 Daniel Kahn Gillmor wrote:
>
>> * Package name: zlint
>
> On Thu, 06 Dec 2018 22:41:03 +0300 Daniel Kahn Gillmor wrote:
>
>> * Pa
Package: wnpp
Severity: wishlist
* Package name: certlint
Version : 1.3.0
Upstream Author : Rob Stradling
* URL : https://github.com/certlint/certlint
* License : Apache 2.0
Programming Lang: Ruby, C
Description : X.509 certificate linter
This linter
Package: wnpp
Severity: wishlist
* Package name: zlint
Version : 3.1.0
Upstream Author : ZMap team (University of Michigan)
* URL : https://github.com/zmap/zlint
* License : Apache 2.0
Programming Lang: Go
Description : X.509 certificate linter
ZLint
Package: rust-hashbrown
Version: 0.9.1-2
Control: forwarded -1 https://github.com/kyren/hashlink/issues/6
I'm trying to build the hashlink crate, which is needed by a transitive
dependency of future work on Sequoia (https://sequoia-pgp.org).
However, the build of hashlink 0.6.0 fails with an
Package: src:rnp
Version: 0.14.0-6
Control: forwarded -1 https://github.com/rnpgp/rnp/issues/1281
rnp currently accepts signatures over weak or untrustworthy
cryptographic primitives.
At the moment, there is no API for adjusting which mechanisms are
acceptable, and all implemented algorithms are
Package: rust-coreutils
Version: 0.0.4-1~exp2
Thanks for rust-coreutils. Very interesting project.
A few thoughts about how to improve the documentation (manual pages in
particular):
- the manpages seem to be generated with help2man. that's cool, but i
recommend supplying the --no-info
Package: debcargo
Version: 2.4.4
Control: affects -1 src:rust-sequoia-openpgp
I'm updating sequoia-openpgp's debcargo.toml to currently contain the
following:
---
# sequoia always needs at least one crypto backend and nettle is
# currently the only crypto-backend available on debian systems.
#
Package: debcargo
Version: 2.4.4
Control: affects -1 src:rust-sequoia-openpgp
in rust-sequoia-openpgp 1.0.0-1 (generated with debcargo 2.4.3), we see
this example test of the "compression-deflate" feature:
Test-Command: /usr/share/cargo/bin/cargo-auto-test sequoia-openpgp 1.0.0
Package: src:rust-regex
Version: 1.3.7-1
Control: forwarded -1 https://gitlab.com/sequoia-pgp/sequoia/-/issues/694
Control: affects -1 src:rust-sequoia-openpgp
Control: clone -1 -2
Control: reassign -2 src:rust-regex-syntax 0.6.17-1
In the above-mentioned report for Sequoia's OpenPGP crate, we
On Fri 2021-03-05 10:21:37 -0500, Daniel Kahn Gillmor wrote:
> It's not clear to me that the proposed upstream API is particularly easy
> to use, but maybe it's better to drop the remaining patch and align with
> upstream expectations, because:
>
> - the test suite already has d
librust-bindgen-0.54-dev |
librust-bindgen-0.53-dev (>= 0.53.1-~~) ,
librust-pkg-config-0.3+default-dev ,
librust-vcpkg-0.2+default-dev (>= 0.2.9-~~) ,
nettle-dev (>= 3.5.1~~) ,
llvm
Maintainer: Debian Rust Maintainers
Uploaders:
Daniel Kahn Gillmor ,
kpcyrd
Standards-Version: 4.5.
Package: src:gpgme1.0
Version: 1.13.1-2
Control: affects -1 gpg1
In gpgme 1.13.1-2, I added
debian/patches/0006-gpg-Send-with-keygrip-when-listing-keys.patch in an
attempt to fix https://dev.gnupg.org/T4820.
Upstream's alternative fix was instead to not test the output that
breaks with older,
Package: impass
Version: 0.12.2-1
After transitioned to a new key (but failing to update ~/.impass/keyid),
i tried to use impass to create a new password (yes, i saw the red
warning message about being unable to verify the signature). Clicking
"Create" in the gui after entering the new context
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
On Fri 2021-02-26 04:48:50 -0800, Felix Lechner wrote:
> That's a great idea! As a first step, I would like to show a
> classification tag with the hash algorithm. (It could be used for
> statistics.) Can 'gpgv' output such signature characteristics?
sure, we have several different tools (like
On Sun 2021-02-07 20:19:19 +, Dominic Hargreaves wrote:
> In the discussion at [1] it was suggested that perhaps gnupg1 could be
> updated to explicitly remove support for operations other than
> decrypting old messages.
that discussion suggests that the only two things that people are likely
On Tue 2020-10-27 07:52:16 +0100, Konstantinos Dalamagkidis wrote:
> currently dpkg-sig uses MD5/SHA1 for the digest. Both are insufficient
> for integrity protection and according to the Debian Wiki SHA-1 is being
> phased out.
This is really not acceptable. It's 2021, we've known that both MD5
Package: thunderbird
Version: 1:78.7.1-1
In Thunderbird, i went to Preferences » Privacy and Security » Manage
Certificates » Authorities and selected "COMODO RSA Certification
Authority".
Then i clicked "View". in the viewer, there are different attributes of
the X.509 certificate. Two of
Package: lintian
Version: 2.104.0
Control: clone -1 -2
Control: reassign -2 devscripts
Control: retitle -2 [uscan] deprecate upstream signatures made using weak
hashes like MD5, SHA1, or RIPEMD160
Some upstream packages are signed with OpenPGP using old, deprecated
digest algorithms.
See for
Package: src:xml2rfc
Version: 2.47.0-1
upstream version 3.5.0 is available upstream in xml2rfc:
https://pypi.org/project/xml2rfc/
I'm working on packaging this new version for debian.
If it works cleanly, I'll likely put it in experimental for now due to
the freeze, but if other people have
Package: ruby-kramdown-rfc2629
Version: 1.3.28-1
I would have expected "kramdown-rfc2629 --version" to report either the
upstream version (1.3.28) or the debian revision (1.3.28-1), but instead
i get "unknown-version":
0 dkg@alice:~$ kramdown-rfc2629 --version
kramdown-rfc2629
Package: ruby-kramdown-rfc2629
Version: 1.3.28-1
Upstream has released version 1.3.34, which contains a helpful
transformation for a document i'm working on. updating the debian
packaging to that version would be great!
(i note that 1.3.28 is a day away from transitioning to testing, so
maybe
On Sun 2021-02-14 06:28:54 +0100, de...@sumpfralle.de wrote:
> In fact the problem disappeared - probably around the time when I migrated my
> 32bit system to 64bit (just the Debian packages; not hardware).
Good to know, thanks for noting it here.
> Thus if my "32 bit theory" does not trigger
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,
Package: knot-resolver
Version: 5.2.1-1
Severity: normal
Control: blocks -1 979840
Control: affects -1 dns-root-data
When i "apt install knot-resolver" on an otherwise clean system running
systemd, the default configuration should start a listener on port 53 on
127.0.0.1.
However, that listener
Thanks for the rapid followup, Felix! I really appreciate your ongoing
attention to detail with lintian. It's a very useful tool.
On Fri 2021-02-12 19:21:39 +, Felix Lechner wrote:
> Based on the information we have, the unversioned /usr/bin/python is
> going away in the upcoming 'bullseye'
On Fri 2021-02-12 11:47:07 -0500, Daniel Kahn Gillmor wrote:
> When GnuPG was upgraded to 2.2.27-1, schleuder's autopkgtests broke:
I've applied the proposed patch and uploaded it as an NMU for 3.6.0-1.1.
I pushed the relevant changes (and a tag) to a fork of the salsa repo,
and submitted a me
Package: lintian
Version: 2.104.0
Control: affects -1 python3-gpg
This is a peculiar error message: lintian seems confused about what the
interpreter is for an example python script shipped in python3-gpg:
$ lintian python3-gpg_1.14.0-1+b2_amd64.deb | head -n1
P: python3-gpg:
Package: schleuder
Version: 3.6.0-1
Control: tags -1 + patch upstream
Control: affects -1 + gpg src:gnupg2
Forwarded: https://0xacab.org/schleuder/schleuder/-/merge_requests/358
When GnuPG was upgraded to 2.2.27-1, schleuder's autopkgtests broke:
Back in 2016, in https://bugs.debian.org/840642, i wrote:
> we also have several remaining copies of GPGME bindings in
> debian, and it would be good to reduce their number. This will save the
> sanity of our users; will provide better focus for upstream developers;
> and will be easier for us
Control: tags 944914 + moreinfo unreproducible
Hi Lars--
On Sun 2019-11-17 16:53:33 +0100, Lars Kruse wrote:
> I am using the claws-mail package for handling emails (Debian testing
> on i386).
>
> Due to repeated crashes, I started to collect stack traces.
Are you still having these problems?
Control: affects 945537 src:thunderbird
Hi Debian Thunderbird devs--
Thanks very much for your work maintaining Thunderbird in Debian!
I just wanted to give you a heads-up that i've prepared a debian package
rnp. The packaging source can be found at
https://salsa.debian.org/debian/rnp. It
Package: ncmpc
Version: 0.43-1
Tags: patch
Severity: important
Control: forwarded -1 https://github.com/MusicPlayerDaemon/ncmpc/issues/93
After upgrading to 0.43-1 on debian testing/unstable, ncmpc no longer
offers a useful connection to my mpd server, instead showing Unknown tag
type in red.
Hi Christoph and gniibe--
Many thanks to you both for preparing and proposing fixes for the GnuPG
packaging in debian.
I've done some review and cleanup and just uploaded 2.2.27-1 to unstable
based on your work. In particular, i pulled from gniibe's git
repository (which included Christoph's
Package: bash-completion
Version: 1:2.11-2
Control: affects -1 + man-db git sq libreswan
Control: forwarded -1 https://github.com/scop/bash-completion/issues/495
bash-completion ships tab completion for /usr/bin/man that identifies
specific manpages.
However, recent versions of man are clever
Package: man-db
Version: 2.9.3-2
Severity: wishlist
Control: affects -1 + sq
It's great that /usr/bin/man can Do The Right Thing™ when a manpage is
requested for a subcommand like "man git tag".
Some utilities these days have sub-subcommands, though, with manpages to
match, and man doesn't
Control: tags 855653 + moreinfo
On Sat 2017-11-18 08:02:34 +0800, Daniel Kahn Gillmor wrote:
> Great, i'm glad to hear it. Do you have a patch to provide for the
> debian packaging? I've already offered to review such a patch (in the
> text that you quoted above).
Just following up o
Package: lintian
Version: 2.104.0
Control: affects -1 src:faketime
faketime's debian/rules contains:
%:
PREFIX=/usr dh $@
this is due to an idiosyncracy of the upstream build system, which sets
PREFIX to /usr/local by default unless it is set explicitly in the
environment. I
Control: affects 965349 + src:faketime
On Mon 2020-07-20 12:56:33 -0400, Nicholas D Steeves wrote:
> dh_missing: warning: changelog exists in debian/tmp but is not installed to
> anywhere
[…]
> I am explicitly installing it in rules with 'dh_installchangelogs
> debian/tmp/changelog' and have
Package: fontconfig
Version: 2.13.1-4.2
Severity: normal
Control: affects -1 src:fonts-dejavu
DejaVu Sans Mono font variants "Bold" and "Oblique" don't get
appropriately pruned when the user searches fontconfig for a "monospace"
font.
if i use `fc-match --all monospace` i see all Bitstream Vera
Package: ttf-bitstream-vera
Version: 1.10-8.1
Control: affects -1 chromium fontconfig python-matplotlib-data src:fonts-dejavu
Textual tables drawn with standard UTF-8 box drawing characters
(U+2500…U+25FF) are being mis-rendered by Chromium in a common default
configuration.
On Fri 2021-01-29 12:47:53 +0800, Shengjing Zhu wrote:
> It doesn't support global completion files yet. Author just says he will
> consider this after 0.15.
OK, thanks for the heads-up!
When you know where the global completion files are likely to be looked
for (even if the upstream version is
Package: src:ruby-kramdown-rfc2629
Version: 1.3.9-1
Looks like ruby-kramdown-rfc2629 upstream version 1.3.24 is available,
with a series of fairly minor bugfixes. It'd be great to have that
up-to-date in debian.
I can NMU it if necessary, but i'd also be happy not to :)
--dkg
signature.asc
Package: src:elvish
Version: 0.15.0~rc3-1
Control: affects -1 src:rust-sequoia-sq src:rust-sequoia-sqv
I'm packaging a few rust binaries built using the "clap" crate, which
auto-generates completion files for bash, fish, zsh, elvish, and
powershell.
I know how to ship the bash, fish, and zsh tab
Control: retitle 947258 lintian: spare-manual-page is too strict (false
positives for subcommand man pages)
Control: affects 947258 + sq
Just noticed that manpage-without-executable was renamed to
spare-manual-page, so i'm updating the title of this bug report to
match.
I also noticed the same
Package: ncmpc
Version: 0.42-1
Severity: important
running ncmpc to connect to an mpd server, i get a crash with a
warning about "Assertion failed:
ncmpc: ../src/FileListPage.cxx:492: virtual void
FileListPage::PaintListItem(WINDOW*, unsigned int, unsigned int, unsigned int,
bool) const:
Control: reassign 980723 debcargo
Control: retitle 980723 debcargo-built binary crates have no way to run
upstream tests
Control: affects 980723 + rust-sequoia-sqv rust-sequoia-sop
rust-sequoia-keyring-linter
On Wed 2021-01-20 20:14:45 -0500, Daniel Kahn Gillmor wrote:
> I think this is beca
Package: rust-sequoia-sqv
Version: 1.0.0-1
Looks like the autopkgtests are not being run for rust-sequoia-sqv (or
for sq-keyring-linter or sqop). I think this is because some rust
packages needed specifically for testing are not available in the
archive.
We should add them to the archive so
On Tue 2021-01-12 18:33:55 +0100, Eduardo Barretto wrote:
> Feel free to correct me at any point, but here is what I've experienced.
>
> It seems like this issue appeared after Launchpad builders started to
> recognize the needs-internet restriction, and it seems that
> needs-internet is not
Version: 4.1-1
Control: tags 934327 + moreinfo
On Fri 2019-09-27 20:50:33 +, Ray Klassen wrote:
> Further on this. It seems to relate to having esp= in the default
> 'conn' and overriding it with phase2alg= in a specific 'conn.' I had
> that crash again on another router and after using
Control: tags 969057 + moreinfo
Hi Eduardo--
Both of these tests are already marked as "needs-internet" -- shouldn't
that be sufficient for autopkgtest runners to know to skip them if
regular internet access is not available?
I'm not sure why we should use the skippable feature as well. Can
Control: affects 947258 + libreswan
On Fri 2020-05-22 10:46:29 -0700, Felix Lechner wrote:
> So far, I learned that 'man' interprets two commands by default as a
> sub-command [1]
[…]
> [1] https://stackoverflow.com/a/32750157
Thanks for this pointer, interesting!
> but I do not know how to
Hi all--
GnuPG is team-maintained -- i've uploaded most of the recent uploads,
but i'm definitely not intending to be the sole maintainer, and i would
be happy to have more active contributors to the team:
https://wiki.debian.org/Teams/GnuPG
Thanks Gniibe and Christoph for your work on
Package: hopenpgp-tools
Version: 0.23.5-1
similar to #978991, ECDH subkeys now say:
algo/size: ECDH 256
where ECDH is in yellow (presumably a warning).
ECDH isn't limited to curve25519 -- it could also use the NIST curves or
the Brainpool curves. so i think you'll want to keep a size check
Package: hopenpgp-tools
Version: 0.23.1-1+b1
"hokey lint" provides a red "256" next to the algorithm/size notes about
ed25519 and cv25519 keys.
I don't think it should warn about this size -- these asymmetric
cryptographic sizes are widely considered to have roughly the same
cryptographic
Preferred hash algorithms: [SHA-512, SHA-256]
Key expiration times: [2y11m26d59400s = Sun Dec 24 16:22:55 UTC 2023]
Key usage flags: [[certify-keys]]
Daniel Kahn Gillmor:
Self-sig hash algorithms: [SHA-512]
Preferred hash algorithms: [SHA-512, SHA-256]
Key expiration times: [
but it seems to be using git-dpm,
and i don't really understand git-dpm well enough to try)
--dkg
From 90177d7f12d25e403abc6f1bdf242aed308a7bb8 Mon Sep 17 00:00:00 2001
From: Daniel Kahn Gillmor
Date: Fri, 18 Jan 2019 03:12:07 -0500
Subject: [PATCH] Avoid elisp crash for OpenPGP User IDs wi
On Thu 2020-12-24 09:37:46 -0400, Joey Hess wrote:
> Daniel Kahn Gillmor wrote:
>> thanks for the diagnosis, Joey! this looks like a change between the
>> ctypes module between python 3.8 and 3.9. I'll fix it in python3-xdo,
>> and hopefully that will resolve your pro
Control: affects 976637 + impass python3-xdo
I just noticed #976637 after working on resolving #977894 in
impass/python3-xdo.
I'm working around the problem by using "c" instead of "libc" in libxdo,
but just wanted to note the relationship between the two issues in the
BTS.
--dkg
Control: forwarded 977894 https://bugs.python.org/issue42580
On Thu 2020-12-24 08:24:19 -0500, Daniel Kahn Gillmor wrote:
> thanks for the diagnosis, Joey! this looks like a change between the
> ctypes module between python 3.8 and 3.9. I'll fix it in python3-xdo,
> and
Control: reassign 977894 python3-xdo
Control: affects 977894 + impass
Control: severity critical
Control: retitle 977894 python3-xdo: fails with python3.9 due to bad libc
linkage
thanks for the diagnosis, Joey! this looks like a change between the
ctypes module between python 3.8 and 3.9. I'll
Control: affects 977894 python3-xdo
On Wed 2020-12-23 15:50:43 -0400, Joey Hess wrote:
> Ok, this is super weird, and I'm afraid also likely a security hole.
ugh, thanks for digging around on this with us, Joey.
it looks to me like the liblibc.a business is happening due to gobject
On Tue 2020-12-22 10:13:43 -0400, Joey Hess wrote:
> I do have that recommends installed. I did try to reinstall
> it in case it was somehow broken. Real problem is that the gui does
> not appear, I don't know if that's due to whatever the problem
> is with python3-xdo.
this is odd, and it makes
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: librust-block-buffer-dev
Version: 0.9.0-3
Control: affects -1 debcargo src:rust-sha3
In an attempt to avoid creating an empty "feature" package, the
packaging for rust-block-buffer removed the optionalness of
block-buffer's dependency on block-padding.
The result is that the
Package: debcargo
Version: 2.4.3-3+b1
I'm looking at the sha1collisiondetection crate. this crate produces a
library and a binary ("sha1cdsum").
The binary needs to build against the structopt crate, but the library
doesn't need it.
Upstream represents this as the library having a structopt
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
Hi Gürkan--
thanks for the followup, and sorry for the delay.
On Wed 2020-04-29 08:03:22 +0200, Gürkan Myczko wrote:
> The tutorial says for me Settings -> Preferences, then browse path, I
> tried /usr/lib64/
> and then hit Scan, it found 22 effects for me:
> http://bootes.ethz.ch/zytrax.png
Version: 0.3.15-1
Control: tags 973836 - moreinfo
On Sun 2020-11-08 16:25:56 +, Simon McVittie wrote:
> I think this may have been a regression in 0.3.14 that was fixed in 0.3.15
> (pipewire's experimental PulseAudio server reimplementation was enabled by
> default, but shouldn't have been).
Package: src:pipewire
Version: 0.3.14-1
Severity: important
Control: notfound -1 0.3.12-1
I'm running debian unstable on a (fairly old) Sony Vaio laptop, with
what a standard GNOME desktop.
I often run "pavucontrol" to get into detailed fiddling with my audio.
When pipewire upgraded to
On Wed 2020-10-28 16:29:14 -0400, Robert Edmonds wrote:
> OK, I made a patch incorporating those fixes recommended by upstream and
> sent them to #962459. Looks like that doesn't work at all.
thanks for doing that, Robert. Bummer that it didn't work.
> I'm not sure picking a random 1.9.x
Hi Robert--
thanks for the followup!
On Wed 2020-10-28 02:56:55 -0400, Robert Edmonds wrote:
> I've never been able to reproduce this bug, but your branch looks good
> to me as far as backporting this commit to 1.9.0. It's commit
> 225534e5ab22d16ab32fa1011733f3c69c7b28ba in the upstream repo
I've pushed the patch in #973052 to a new branch named bug-973052 in the
https://salsa.debian.org/dns-team/unbound repo (on top of
branches/1.9.0-2_deb10).
Hopefully one of the other DNS folks will review it and merge it if it
looks reasonable. Not sure whether we should release a new version
Control: forcemerge 973052 962459
Hi Kebert--
On Mon 2020-06-08 12:28:46 +0200, Kebert Martin wrote:
> unbound constantly crashing with:
> [err] evmap.c:381: Assertion nread >= 0 failed in evmap_io_del_
>
> The issue is fixed in unbound 1.9.2 but this version is not available in
> debian
Package: unbound
Version: 1.9.0-2
Control: forwarded -1 https://www.nlnetlabs.nl/bugs-script/show_bug.cgi?id=4227
Control: tags -1 + patch
On a debian buster amd64 system running unbound 1.9.0-2, i see unbound
crash with the following error:
unbound[193]: [err] evmap.c:381: Assertion nread
Package: ncal
Version: 12.1.7
Severity: normal
Earlier versions of ncal used to highlight the current day when
invoked as "cal", i believe.
now, the current day is highlighted when invoked as "ncal" but it is
not highlighted when invoked as "cal".
--dkg
-- System Information:
Debian
gp-stateless-cli/-/issues/28
In the meantime, here's a patch to libbsd 0.10.0 that at least resolves
the out-of-date certificates and the single-keyring-blob issue.
--dkg
From 6bde48deb1d35cbb010b55e6fb8cb92037378b5b Mon Sep 17 00:00:00 2001
From: Daniel Kahn Gillmor
Date: Fri, 16 Oct 202
On Fri 2020-10-16 12:05:48 +0200, Justus Winter wrote:
> And in general, the expectation that you can join two files does not
> hold. Concatenating two photos doesn't yield a slideshow, etc. So my
> position on the matter is that concatenating two binary certificates
> yielding a keyring is a
On Thu 2020-10-15 16:44:00 -0400, Daniel Kahn Gillmor wrote:
> Are there design constraints or goals that this approach doesn't solve?
Hm, Guillem pointed me toward https://bugs.debian.org/901827 which
identifies non-contiguous ranges of dependencies due to "transitive
dependencies on
On Thu 2020-10-01 14:05:59 +0200, Sascha Wilde wrote:
> so far I haven't received any reply to either my pull request or my
> questions in the bug report issue from Fri, 11 Sep 2020 15:38:13 +0200.
>
> I would still appreciate input on my work, especially if there is
> anything I need to do to
On Thu 2020-10-15 14:51:45 -0400, Daniel Kahn Gillmor wrote:
> On Wed 2020-08-12 13:59:05 +0100, peter green wrote:
>> The proper fix IMO would be to add support for version ranges to
>> dependencies in dpkg
>
> I agree that this seems promising -- we'd then need to have debc
On Thu 2020-10-15 14:51:45 -0400, Daniel Kahn Gillmor wrote:
> Judging by a conversation on #debian-buildd, that seems to be correct
> (though there are of course many other ways for non-determinism to
> potentially sneak in, not least of which are different versions of
> build-dep
On Wed 2020-08-12 13:59:05 +0100, peter green wrote:
> It has been said in the past by the release team that the current
> autobuilder behaviour of only considering the first option for a
> build-dependency is by design to improve the determinism of the
> autobuilding process. I don't think you
Just to clarify why this is a concern:
- this behavior on the buildds is deliberate. It's an explicit
feature of sbuild.
- it is intended to ensure more-deterministic builds
- it is also mentioned in debian-policy, in the first footnote of §7.1:
>While Build-Depends,
On Sat 2020-09-05 17:09:06 +0200, Guillem Jover wrote:
> I was trying out sqv, to potentially add native support for it into
> dpkg-dev, but either it does not work as expected or I'm confused by
> the docs. :)
>
> $ apt source libbsd
> $ sqv -v --keyring
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
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
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
Package: debcargo
Version: 2.4.2-1
Severity: normal
Control: affects -1 + rust-buffered-reader
Looking at buffered-reader version 0.18.0, upstream lists dependencies
in Cargo.toml including:
[dependencies.flate2]
version = ">= 1.0.1, < 1.0.16"
optional = true
debcargo 2.4.2 converts this to a
Package: wnpp
Severity: wishlist
Owner: Daniel Kahn Gillmor
* Package name: gosop
Version : 0.17.0
Upstream Author : Proton Technologies AG
* URL : https://github.com/ProtonMail/gosop
* License : MIT
Programming Lang: Go
Description : Stateless
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
Package: ruby-kramdown-rfc2629
Version: 1.2.12-0.1
When running kramdown-rfc2629 against ruby 1:2.7+1, i see this warning
multiple times:
/usr/lib/ruby/vendor_ruby/kramdown-rfc2629.rb:454: warning: calling URI.open
via Kernel#open is deprecated, call URI.open directly or use URI#open
Perhaps
Version: 2.6.1-1
Control: notfound 961792 2.5.6-2
Control: notfound 961792 2.4.12-3+b1
On Thu 2020-06-25 10:18:54 +0100, Simon McVittie wrote:
> On Fri, 29 May 2020 at 11:24:06 +0100, Simon McVittie wrote:
>> If I'm reading https://gitlab.gnome.org/GNOME/glib-networking/-/issues/135
>> and
.
I'm attaching a patch to dpkg which (i think) reflects the fix proposed
by Guillem Jover (in cc):
From 8d01f1419c62e24b662abc2e1ec708a7c63fbbfe Mon Sep 17 00:00:00 2001
From: Daniel Kahn Gillmor
Date: Wed, 1 Jul 2020 17:00:02 -0400
Subject: [PATCH] Use +self_spec: instead of *self_spec:
After
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:
>>
Package: nautilus
Version: 3.36.3-1
Severity: wishlist
I had a running Debian unstable system (amd64) with a fairly minimalist
non-GNOME OS installed. originally it had APT::Install-Recommends set
to 0, but as i wanted to move toward a more standard install, i set it
back to the default of
Hi Ian--
I don't know what the current status of the failing tests suites is for
dgit -- last i heard, you had to have major, clunky workarounds to avoid
problems with concurrent access to gpg-agent, or else gpg-agent would
(intermittently, unpredictably) fail on some requests.
Please correct me
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
Control: fixed 952797 1.13.1-7
This was fixed in gpgme 1.13.1-7, but failed to be closed correctly due
to a typo in debian/changelog. My bad!
On Tue 2020-03-10 09:06:24 -0400, Daniel Kahn Gillmor wrote:
> On Tue 2020-03-10 06:23:57 +0100, Helmut Grohne wrote:
>> So even if the pa
301 - 400 of 4321 matches
Mail list logo
