Re: Bug#835465: [Reproducible-builds] Bug#835465: python-apt: FTBFS: AptKeyError: recv from 'hkp://localhost:19191' failed for '0xa1bD8E9D78F7FE5C3E65D8AF8B48AD6246925553'
On Tue 2016-08-30 10:31:50 -0400, Julian Andres Klode wrote: > On Tue, Aug 30, 2016 at 10:18:33AM -0400, Daniel Kahn Gillmor wrote: >> Can you point me to a report about that? I'm not seeing it in my scan >> of the bts at https://bugs.debian.org/src:software-properties > > There is none. And it does not seem to be that annoying. While it now only > shows key ids and no names, you can at least still remove them. So it > basically > works, but without it showing names, it's kind of useless for the target > audience. ok, i'm not going to worry about marking software-properties with a Breaks: unless i hear otherwise from you. thanks for giving me a heads-up, though. It does look like there's code in there that should probably be pulled out just have it use python-apt directly. > APT uses gpgv and then parses the output of [GNUPG:] VALIDSIG to > determine the key id used to sign (and forgets to include the > subkey field). > > If a list of allowed keys has been specified for the source via a > Signed-By field in the sources.list or the Release file, it then > checks that the key it parsed from GPG is in that list. > > If nobody specifies a Signed-By field (which is the default > right now), that of course does not affect anyone. I do want > to roll out the Release-file Signed-By field at some point > though, as it (very) slightly improves security. Huh, i was unaware of the Signed-By field, actually, but i'm happy to see it. I'm not sure what i think about a primary key being listed there by fingerprint while the Release file being signed by a subkey. I could see a (fairly weak) argument that rejecting that signature is "working as it should", but i think you're probably right that this might be better considered as a bug. at least it's a bug that fails closed rather than failing open though :) --dkg signature.asc Description: PGP signature ___ Reproducible-builds mailing list Reproducible-builds@lists.alioth.debian.org http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/reproducible-builds
Re: Bug#835465: [Reproducible-builds] Bug#835465: python-apt: FTBFS: AptKeyError: recv from 'hkp://localhost:19191' failed for '0xa1bD8E9D78F7FE5C3E65D8AF8B48AD6246925553'
On Tue, Aug 30, 2016 at 10:18:33AM -0400, Daniel Kahn Gillmor wrote: > On Tue 2016-08-30 09:47:34 -0400, Julian Andres Klode wrote: > > On Tue, Aug 30, 2016 at 09:32:15AM -0400, Daniel Kahn Gillmor wrote: > >> On Tue 2016-08-30 08:49:20 -0400, Julian Andres Klode wrote: > >> >> apt/auth.py appears to want to force gnupg to store its secret key > >> >> material in secring.gpg. This isn't a best practice, and modern > >> >> versions of gpg do not do so by default. I'd recommend dropping > >> >> tmp_secret_keyring entirely. > >> > > >> > Hmm, there should not even be any secret key material, as apt only > >> > deals with public keys. > >> > >> agreed, all the more reason to strip out those extra directives ;) > > > > I assume that might change behavior if used with gpg1, so I'd rather > > keep it in if it does no harm. > > There should be no behavior that changes based on secret keys if secret > keys are never used. I'd rather not have spare directives floating > around that we don't need -- i've been doing triage on things that try > to manipulate gnupg programmatically, and the simpler we can make them > the easier it will be to fix any problems that come up in GnuPG itself, > i think. There's a lot of cruft, and it would help my sanity to > minimize the cruft. Mmh, okay. > > > I don't really care. More important are probably Breaks for > > software-properties, > > it's Authentication tab is fairly broken now. I think that's also where > > apt.auth > > was split off from, but I'm not entirely sure... > > Can you point me to a report about that? I'm not seeing it in my scan > of the bts at https://bugs.debian.org/src:software-properties There is none. And it does not seem to be that annoying. While it now only shows key ids and no names, you can at least still remove them. So it basically works, but without it showing names, it's kind of useless for the target audience. > > >> > Maybe there's also an option to display fingerprints instead of keyids > >> > in --with-colons --list-keys? > >> > >> sure! > >> > >> gpg --fixed-list-mode --with-fingerprint --with-fingerprint > >> --with-colons --list-keys > >> > >> will produce lines of the form: > >> > >> fpr:0EE5BE979282D80B9F7540F1CCD2ED94D21739E9: > > > > How awful. There should be a way to integrate this into the pub output > > To be clear, the output has pub:, then fpr:, then uid: lines in a row. > it's pretty straightforward to track as you read the lines linearly. > for any uid line, it is associated with the most recent fpr line, which > itself is associated with the most recent pub line. Yes. > > the uid line is split out because you can have multiple uids associated > with each pub+fpr. > > For the fields we're interested in, this is the same output across all > versions. > > > (and with all the other breaks, it should have just gone fingerprint > > by default everywhere). > > i'm working on that, but there are internal data structure > considerations that make it more costly to display the fingerprint > (unfortunately, the datastructures in the keyring are 64-bit keyids, not > full fingerprints). > > > APT's subkey handling is fairly broken anyway (it's gpg verification > > does not consider subkeys at all, so if you specify a list signed-by > > of master key ids, APT would fail to validate a repo signed with a > > subkey, unless the subkey is in the list itself...) > > interesting -- how is this done? i thought apt was using gpgv to verify > the signatures, and if there are subkeys in the keyrings gpgv knows > about gpgv will be willing to accept those subkeys. Are you saying apt > itself parses the output of gpgv and the fingprints in it to some > internal list of acceptable fingerprints? If you could point to the > right spot in the source, i'd be happy to look into it further. APT uses gpgv and then parses the output of [GNUPG:] VALIDSIG to determine the key id used to sign (and forgets to include the subkey field). If a list of allowed keys has been specified for the source via a Signed-By field in the sources.list or the Release file, it then checks that the key it parsed from GPG is in that list. If nobody specifies a Signed-By field (which is the default right now), that of course does not affect anyone. I do want to roll out the Release-file Signed-By field at some point though, as it (very) slightly improves security. -- Debian Developer - deb.li/jak | jak-linux.org - free software dev When replying, only quote what is necessary, and write each reply directly below the part(s) it pertains to (`inline'). Thank you. ___ Reproducible-builds mailing list Reproducible-builds@lists.alioth.debian.org http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/reproducible-builds
Processed: Re: Bug#836075: libfile-stripnondeterminism-perl: hard-link is destroyed after normalization
Processing commands for cont...@bugs.debian.org: > tags 836075 + pending Bug #836075 [libfile-stripnondeterminism-perl] libfile-stripnondeterminism-perl: hard-link is destroyed after normalization Added tag(s) pending. > thanks Stopping processing here. Please contact me if you need assistance. -- 836075: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=836075 Debian Bug Tracking System Contact ow...@bugs.debian.org with problems ___ Reproducible-builds mailing list Reproducible-builds@lists.alioth.debian.org http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/reproducible-builds
Re: Bug#836075: libfile-stripnondeterminism-perl: hard-link is destroyed after normalization
tags 836075 + pending thanks AYANOKOUZI, Ryuunosuke wrote: > Current file handlers is considering file mode, but other file attributes > (Ex. user ID, group ID, inode number, link counts, ...) are not considered. […] > I would like someone to request review the patch and merge it to the branch. Thanks so much; applied. Regards, -- ,''`. : :' : Chris Lamb `. `'` la...@debian.org / chris-lamb.co.uk `- ___ Reproducible-builds mailing list Reproducible-builds@lists.alioth.debian.org http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/reproducible-builds
Re: Bug#835465: [Reproducible-builds] Bug#835465: python-apt: FTBFS: AptKeyError: recv from 'hkp://localhost:19191' failed for '0xa1bD8E9D78F7FE5C3E65D8AF8B48AD6246925553'
On Tue 2016-08-30 09:47:34 -0400, Julian Andres Klode wrote: > On Tue, Aug 30, 2016 at 09:32:15AM -0400, Daniel Kahn Gillmor wrote: >> On Tue 2016-08-30 08:49:20 -0400, Julian Andres Klode wrote: >> >> apt/auth.py appears to want to force gnupg to store its secret key >> >> material in secring.gpg. This isn't a best practice, and modern >> >> versions of gpg do not do so by default. I'd recommend dropping >> >> tmp_secret_keyring entirely. >> > >> > Hmm, there should not even be any secret key material, as apt only >> > deals with public keys. >> >> agreed, all the more reason to strip out those extra directives ;) > > I assume that might change behavior if used with gpg1, so I'd rather > keep it in if it does no harm. There should be no behavior that changes based on secret keys if secret keys are never used. I'd rather not have spare directives floating around that we don't need -- i've been doing triage on things that try to manipulate gnupg programmatically, and the simpler we can make them the easier it will be to fix any problems that come up in GnuPG itself, i think. There's a lot of cruft, and it would help my sanity to minimize the cruft. > I don't really care. More important are probably Breaks for > software-properties, > it's Authentication tab is fairly broken now. I think that's also where > apt.auth > was split off from, but I'm not entirely sure... Can you point me to a report about that? I'm not seeing it in my scan of the bts at https://bugs.debian.org/src:software-properties >> > Maybe there's also an option to display fingerprints instead of keyids >> > in --with-colons --list-keys? >> >> sure! >> >> gpg --fixed-list-mode --with-fingerprint --with-fingerprint --with-colons >> --list-keys >> >> will produce lines of the form: >> >> fpr:0EE5BE979282D80B9F7540F1CCD2ED94D21739E9: > > How awful. There should be a way to integrate this into the pub output To be clear, the output has pub:, then fpr:, then uid: lines in a row. it's pretty straightforward to track as you read the lines linearly. for any uid line, it is associated with the most recent fpr line, which itself is associated with the most recent pub line. the uid line is split out because you can have multiple uids associated with each pub+fpr. For the fields we're interested in, this is the same output across all versions. > (and with all the other breaks, it should have just gone fingerprint > by default everywhere). i'm working on that, but there are internal data structure considerations that make it more costly to display the fingerprint (unfortunately, the datastructures in the keyring are 64-bit keyids, not full fingerprints). > APT's subkey handling is fairly broken anyway (it's gpg verification > does not consider subkeys at all, so if you specify a list signed-by > of master key ids, APT would fail to validate a repo signed with a > subkey, unless the subkey is in the list itself...) interesting -- how is this done? i thought apt was using gpgv to verify the signatures, and if there are subkeys in the keyrings gpgv knows about gpgv will be willing to accept those subkeys. Are you saying apt itself parses the output of gpgv and the fingprints in it to some internal list of acceptable fingerprints? If you could point to the right spot in the source, i'd be happy to look into it further. --dkg signature.asc Description: PGP signature ___ Reproducible-builds mailing list Reproducible-builds@lists.alioth.debian.org http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/reproducible-builds
Re: Bug#835465: [Reproducible-builds] Bug#835465: python-apt: FTBFS: AptKeyError: recv from 'hkp://localhost:19191' failed for '0xa1bD8E9D78F7FE5C3E65D8AF8B48AD6246925553'
On Tue, Aug 30, 2016 at 09:32:15AM -0400, Daniel Kahn Gillmor wrote:
> On Tue 2016-08-30 08:49:20 -0400, Julian Andres Klode wrote:
> >> apt/auth.py appears to want to force gnupg to store its secret key
> >> material in secring.gpg. This isn't a best practice, and modern
> >> versions of gpg do not do so by default. I'd recommend dropping
> >> tmp_secret_keyring entirely.
> >
> > Hmm, there should not even be any secret key material, as apt only
> > deals with public keys.
>
> agreed, all the more reason to strip out those extra directives ;)
I assume that might change behavior if used with gpg1, so I'd rather
keep it in if it does no harm.
>
> >> I'll be releasing a new version of gnupg shortly that will explicitly
> >> declare that it Breaks: python-apt (<= 1.1.0~beta4).
> >
> > I think that's a bit overkill. While this part of python-apt is broken
> > with the new gnupg, the rest works fine; and nobody uses the apt.auth
> > module. Not to mention that I'm deprecating it, as we deprecated the gpg
> > stuff in apt-key.
>
> If you want me to remove the Breaks: i can do so -- my goal was to
> address the concerns raised in https://bugs.debian.org/835349.
>
> If you'd rather that i not provide a Breaks: or a Conflicts: for
> python-apt, i can avoid it -- speak up though, i'm hoping to release the
> next version of gnupg2 to unstable shortly :)
I don't really care. More important are probably Breaks for software-properties,
it's Authentication tab is fairly broken now. I think that's also where apt.auth
was split off from, but I'm not entirely sure...
>
> >> Ideally, the next version of python-apt can have these bugs fixed and it
> >> will work cleanly with the modern version of gnupg.
> >
> > Sure. But we should really support both old and new gpg versions, otherwise
> > it gets a bit annoying.
> >
> > Maybe there's also an option to display fingerprints instead of keyids
> > in --with-colons --list-keys?
>
> sure!
>
> gpg --fixed-list-mode --with-fingerprint --with-fingerprint --with-colons
> --list-keys
>
> will produce lines of the form:
>
> fpr:0EE5BE979282D80B9F7540F1CCD2ED94D21739E9:
How awful. There should be a way to integrate this into the pub output (and with
all the other breaks, it should have just gone fingerprint by default
everywhere).
But oh well, it's better than nothing.
>
> The hex string shows up in $10 for "awk -F:", fields[9] in python after
> fields = line.split(":").
>
> providingn --with-fingerprint twice ensures that you get fingerprints
> for both primary keys and subkeys -- if that's what you want.
Hmm, I don't know. APT's subkey handling is fairly broken anyway (it's
gpg verification does not consider subkeys at all, so if you specify a list
signed-by of master key ids, APT would fail to validate a repo signed with
a subkey, unless the subkey is in the list itself...)
>
> >> However, if your next upload of python-apt can't be built or run against
> >> modern versions of GnuPG
> >
> > That would be silly :)
>
> i'm glad it will be straightforward to sort it out ;)
>
> Thanks for your work on this,
>
> --dkg
--
Debian Developer - deb.li/jak | jak-linux.org - free software dev
When replying, only quote what is necessary, and write each reply
directly below the part(s) it pertains to (`inline'). Thank you.
___
Reproducible-builds mailing list
Reproducible-builds@lists.alioth.debian.org
http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/reproducible-builds
Re: Bug#835465: [Reproducible-builds] Bug#835465: python-apt: FTBFS: AptKeyError: recv from 'hkp://localhost:19191' failed for '0xa1bD8E9D78F7FE5C3E65D8AF8B48AD6246925553'
On Tue 2016-08-30 08:49:20 -0400, Julian Andres Klode wrote:
>> apt/auth.py appears to want to force gnupg to store its secret key
>> material in secring.gpg. This isn't a best practice, and modern
>> versions of gpg do not do so by default. I'd recommend dropping
>> tmp_secret_keyring entirely.
>
> Hmm, there should not even be any secret key material, as apt only
> deals with public keys.
agreed, all the more reason to strip out those extra directives ;)
>> I'll be releasing a new version of gnupg shortly that will explicitly
>> declare that it Breaks: python-apt (<= 1.1.0~beta4).
>
> I think that's a bit overkill. While this part of python-apt is broken
> with the new gnupg, the rest works fine; and nobody uses the apt.auth
> module. Not to mention that I'm deprecating it, as we deprecated the gpg
> stuff in apt-key.
If you want me to remove the Breaks: i can do so -- my goal was to
address the concerns raised in https://bugs.debian.org/835349.
If you'd rather that i not provide a Breaks: or a Conflicts: for
python-apt, i can avoid it -- speak up though, i'm hoping to release the
next version of gnupg2 to unstable shortly :)
>> Ideally, the next version of python-apt can have these bugs fixed and it
>> will work cleanly with the modern version of gnupg.
>
> Sure. But we should really support both old and new gpg versions, otherwise
> it gets a bit annoying.
>
> Maybe there's also an option to display fingerprints instead of keyids
> in --with-colons --list-keys?
sure!
gpg --fixed-list-mode --with-fingerprint --with-fingerprint --with-colons
--list-keys
will produce lines of the form:
fpr:0EE5BE979282D80B9F7540F1CCD2ED94D21739E9:
The hex string shows up in $10 for "awk -F:", fields[9] in python after
fields = line.split(":").
providingn --with-fingerprint twice ensures that you get fingerprints
for both primary keys and subkeys -- if that's what you want.
>> However, if your next upload of python-apt can't be built or run against
>> modern versions of GnuPG
>
> That would be silly :)
i'm glad it will be straightforward to sort it out ;)
Thanks for your work on this,
--dkg
signature.asc
Description: PGP signature
___
Reproducible-builds mailing list
Reproducible-builds@lists.alioth.debian.org
http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/reproducible-builds
Bug#836075: libfile-stripnondeterminism-perl: hard-link is destroyed after normalization
Package: libfile-stripnondeterminism-perl Version: 0.023-2 Severity: normal Tags: patch User: reproducible-builds@lists.alioth.debian.org Usertags: toolchain X-Debbugs-Cc: reproducible-builds@lists.alioth.debian.org Dear maintainer, Current file handlers is considering file mode, but other file attributes (Ex. user ID, group ID, inode number, link counts, ...) are not considered. It means that a file with same file name before and after normalization could have different file attributes except for file mode. This would cause some problem. Suppose that we have a debian package which is packaged by "debhelper" and that "debian/rule" execute "rdfind -makehardlinks true" in "override_dh_auto_install" target to reduce package size using hard-link of duplicated files in the package [1]. [1] https://wiki.debian.org/dedup.debian.net "dh_strip_nondeterminism" target is executed after "override_dh_auto_install" (hard-linking). In the target, File::StripNondeterminism module create new normalized file which has different inode number from target file and rename() the normalized file to the target file it data has changed. Because inode number has changed after rename(). hard-link status of files by "rdfind" could be changed [2]. This cause duplicated files in final package in spite of "rdfind" invocation in "dh_strip_nondeterminism" target. [2] hard-link status could be changed. $ (umask 0006; convert xc:none /tmp/preserve_file_attributes.v1YRi3/ln_target.png) $ ln /tmp/preserve_file_attributes.v1YRi3/ln_target.png /tmp/preserve_file_attributes.v1YRi3/ln_hardlink.png $ stat /tmp/preserve_file_attributes.v1YRi3/ln_hardlink.png /tmp/preserve_file_attributes.v1YRi3/ln_target.png File: ‘/tmp/preserve_file_attributes.v1YRi3/ln_hardlink.png’ Size: 272 Blocks: 8 IO Block: 4096 regular file Device: fe01h/65025dInode: 498297 Links: 2 Access: (0660/-rw-rw) Uid: ( 1000/) Gid: ( 1000/) Access: 2016-08-30 21:53:27.562341916 +0900 Modify: 2016-08-30 21:53:27.558341948 +0900 Change: 2016-08-30 21:53:27.558341948 +0900 Birth: - File: ‘/tmp/preserve_file_attributes.v1YRi3/ln_target.png’ Size: 272 Blocks: 8 IO Block: 4096 regular file Device: fe01h/65025dInode: 498297 Links: 2 Access: (0660/-rw-rw) Uid: ( 1000/) Gid: ( 1000/) Access: 2016-08-30 21:53:27.562341916 +0900 Modify: 2016-08-30 21:53:27.558341948 +0900 Change: 2016-08-30 21:53:27.558341948 +0900 Birth: - $ perl -I lib/ bin/strip-nondeterminism /tmp/preserve_file_attributes.v1YRi3/ln_hardlink.png $ stat /tmp/preserve_file_attributes.v1YRi3/ln_hardlink.png /tmp/preserve_file_attributes.v1YRi3/ln_target.png File: ‘/tmp/preserve_file_attributes.v1YRi3/ln_hardlink.png’ Size: 155 Blocks: 8 IO Block: 4096 regular file Device: fe01h/65025dInode: 498310 Links: 1 Access: (0660/-rw-rw) Uid: ( 1000/) Gid: ( 1000/) Access: 2016-08-30 21:53:27.850341897 +0900 Modify: 2016-08-30 21:53:27.846341898 +0900 Change: 2016-08-30 21:53:27.846341898 +0900 Birth: - File: ‘/tmp/preserve_file_attributes.v1YRi3/ln_target.png’ Size: 272 Blocks: 8 IO Block: 4096 regular file Device: fe01h/65025dInode: 498297 Links: 1 Access: (0660/-rw-rw) Uid: ( 1000/) Gid: ( 1000/) Access: 2016-08-30 21:53:27.850341897 +0900 Modify: 2016-08-30 21:53:27.558341948 +0900 Change: 2016-08-30 21:53:27.846341898 +0900 Birth: - To fix this issue and to preserve as much file attribute information of target file as possible, I prepared a patch to "master" branch of official repository [3]. I would like someone to request review the patch and merge it to the branch. [3] https://anonscm.debian.org/git/reproducible/strip-nondeterminism.git/log/?h=master -- System Information: Debian Release: stretch/sid APT prefers unstable APT policy: (500, 'unstable') Architecture: amd64 (x86_64) Kernel: Linux 3.16.0-4-amd64 (SMP w/2 CPU cores) Locale: LANG=C, LC_CTYPE=C (charmap=ANSI_X3.4-1968) Shell: /bin/sh linked to /bin/dash Init: unable to detect Versions of packages libfile-stripnondeterminism-perl depends on: ii libarchive-zip-perl 1.59-1 ii perl 5.22.2-3 libfile-stripnondeterminism-perl recommends no packages. libfile-stripnondeterminism-perl suggests no packages. -- no debconf information Sincerely yours, Ryuunosuke Ayanokouzi -- AYANOKOUZI, Ryuunosuke 0001-Preserve-file-attribute-information-of-target-file.patch Description: Binary data pgppFYCSLH8qx.pgp Description: OpenPGP Digital Signature ___ Reproducible-builds mailing list Reproducible-builds@lists.alioth.debian.org http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/reproducible-builds
Re: [Reproducible-builds] Deprecating plain dpkg-buildpackage
On Sat, Aug 27, 2016 at 07:29:13AM +, Mattia Rizzolo wrote: > > It could be argued that "We are mainly interested in the > > reproducibility issue, the FTBFS bugs are just a side effect". > > Indeed. > I'm fully open to such tests, but imho they would need to be on a > different project. > Besides, atm we don't really have spare resources around… That. -- cheers, Holger signature.asc Description: Digital signature ___ Reproducible-builds mailing list Reproducible-builds@lists.alioth.debian.org http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/reproducible-builds
Re: Bug#835465: [Reproducible-builds] Bug#835465: python-apt: FTBFS: AptKeyError: recv from 'hkp://localhost:19191' failed for '0xa1bD8E9D78F7FE5C3E65D8AF8B48AD6246925553'
On Tue, Aug 30, 2016 at 06:35:07AM -0400, Daniel Kahn Gillmor wrote:
> Control: affects 835465 + gnupg2
>
> Hi python-apt folks--
>
> On Thu 2016-08-25 20:55:27 -0400, Chris Lamb wrote:
> > Source: python-apt
> > Version: 1.1.0~beta4
> > Severity: serious
> > Justification: fails to build from source
> > User: reproducible-builds@lists.alioth.debian.org
> > Usertags: ftbfs
> > X-Debbugs-Cc: reproducible-builds@lists.alioth.debian.org
> >
> > Dear Maintainer,
> >
> > python-apt fails to build from source in unstable/amd64:
> >
> > set -e; for python in python2.7 python3.5 ; do \
> > $python tests/test_all.py -q || [ "linux" = "hurd" ]; \
> > done;
> > Warning: apt-key output should not be parsed (stdout is not a terminal)
> > Warning: apt-key output should not be parsed (stdout is not a terminal)
> > Warning: apt-key output should not be parsed (stdout is not a terminal)
> > Warning: apt-key output should not be parsed (stdout is not a terminal)
> > Warning: apt-key output should not be parsed (stdout is not a terminal)
> > Warning: apt-key output should not be parsed (stdout is not a terminal)
>
> this warning is advice about one of the things that might be going wrong
> in some places in the test suite ;) I see that in upstream
> 7a9a292fd604bc164eed3d3fee1dc9167141d88c you're deprecating this, but i
> strongly caution against this.
>
> > [tests] Running on 2.7.12+ (default, Aug 4 2016, 20:04:34) [GCC 6.1.1
> > 20160724]
> > Using library_dir:
> > '/home/lamby/temp/cdt.20160826014142.YuAeJNcC8b.db.python-apt/python-apt-1.1.0~beta4/build/lib.linux-x86_64-2.7'WARNING:
> > Failed to read mirror file
> > WARNING: Failed to read mirror file
> > WARNING: Failed to read mirror file
> > WARNING: Failed to read mirror file
> > WARNING: Failed to read mirror file
> > WARNING: Failed to read mirror file
> > WARNING: Failed to read mirror file
> > WARNING: Failed to read mirror file
> > ==
> > ERROR: testAddKeyFromServer (test_auth.TestAuthKeys)
> > Install a GnuPG key from a remote server.
> > --
> > Traceback (most recent call last):
> > File
> > "/home/lamby/temp/cdt.20160826014142.YuAeJNcC8b.db.python-apt/python-apt-1.1.0~beta4/tests/test_auth.py",
> > line 220, in testAddKeyFromServer
> > "hkp://localhost:%d" % self.keyserver_port)
> > File
> > "/home/lamby/temp/cdt.20160826014142.YuAeJNcC8b.db.python-apt/python-apt-1.1.0~beta4/build/lib.linux-x86_64-2.7/apt/auth.py",
> > line 128, in add_key_from_keyserver
> > _add_key_from_keyserver(keyid, keyserver, tmp_keyring_dir)
> > File
> > "/home/lamby/temp/cdt.20160826014142.YuAeJNcC8b.db.python-apt/python-apt-1.1.0~beta4/build/lib.linux-x86_64-2.7/apt/auth.py",
> > line 156, in _add_key_from_keyserver
> > keyserver, keyid))
> > AptKeyError: recv from 'hkp://localhost:19191' failed for
> > '0xa1bD8E9D78F7FE5C3E65D8AF8B48AD6246925553'
>
> apt/auth.py appears to want to force gnupg to store its secret key
> material in secring.gpg. This isn't a best practice, and modern
> versions of gpg do not do so by default. I'd recommend dropping
> tmp_secret_keyring entirely.
Hmm, there should not even be any secret key material, as apt only
deals with public keys.
>
> furthermore, recent versions of gnupg (>= 2.1) do not fetch things from
> keyservers directly -- if you want modern gpg to talk to the network,
> you'll need to ensure that dirmngr is installed.
>
> If you prefer to keep this test intact, you might want to build-depend
> on dirmngr.
>
> > ==
> > FAIL: testAddAndExportKey (test_auth.TestAuthKeys)
> > Add an example key.
> > --
> > Traceback (most recent call last):
> > File
> > "/home/lamby/temp/cdt.20160826014142.YuAeJNcC8b.db.python-apt/python-apt-1.1.0~beta4/tests/test_auth.py",
> > line 157, in testAddAndExportKey
> > WHEEZY_KEY.split("\n")[2:])
> > AssertionError: Lists differ: ['mQINBE+a7rUBEADQiEKtLOgqiq8Y... != ['',
> > 'mQINBE+a7rUBEADQiEKtLOgq...
> >
> > First differing element 0:
> > 'mQINBE+a7rUBEADQiEKtLOgqiq8YY/p7IFODMqGPR+o1vtXaksie8iTOh3Vxab38'
> > ''
> >
> > Second list contains 1 additional elements.
> > First extra element 81:
> > '-END PGP PUBLIC KEY BLOCK-'
> >
> > Diff is 5698 characters long. Set self.maxDiff to None to see it.
>
> This change is due to the fact that upstream has stopped emitting the
> Version: pseudoheader at all as of 2.1.14. Perhaps your build-dependency on
> gnupg should be (>= 2.1.14) and you should strike the Version:
> pseudoheader in WHEEZY_KEY in tests/test_auth.py
>
> > ==
> > FAIL: testAddAndListKey (test_auth.TestAuthKe
Re: [Reproducible-builds] Bug#835075: libmail-gnupg-perl: FTBFS: Failed 1/10 test programs. 0/4 subtests failed.
Control: affects 835075 src:gnupg2 On Mon 2016-08-22 03:20:05 -0400, Chris Lamb wrote: > Source: libmail-gnupg-perl > Version: 0.22-1 > Severity: serious > Justification: fails to build from source > User: reproducible-builds@lists.alioth.debian.org > Usertags: ftbfs > X-Debbugs-Cc: reproducible-builds@lists.alioth.debian.org > > Dear Maintainer, > > libmail-gnupg-perl fails to build from source in unstable/amd64: > > [..] > > > > ** > ** Starting build > ** > > ** > >Package: libmail-gnupg-perl >Version: 0.22-1 >Build architecture: amd64 >Date: Mon, 22 Aug 2016 08:12:30 +0100 >Hostname: 0ca47040 >Uname:Linux 0ca47040 4.6.0-1-amd64 #1 SMP Debian > 4.6.4-1 (2016-07-18) x86_64 GNU/Linux >/etc/timezone:Europe/London > > > ** > ** Installing build dependencies > ** > > ** > > dh_testdir > dh_testroot > dh_prep > dh_testdir > dh_testroot > dh_install > dh_installdocs > dh_installchangelogs > dh_compress > dh_fixperms > dh_installdeb > dh_gencontrol > dh_md5sums > dh_builddeb > dpkg-deb: building package 'libmail-gnupg-perl-build-deps' in > '../libmail-gnupg-perl-build-deps_0.22-1_all.deb'. > > The package has been created. > Attention, the package has been created in the current directory, > not in ".." as indicated by the message above! > Selecting previously unselected package libmail-gnupg-perl-build-deps. > (Reading database ... 23244 files and directories currently installed.) > Preparing to unpack libmail-gnupg-perl-build-deps_0.22-1_all.deb ... > Unpacking libmail-gnupg-perl-build-deps (0.22-1) ... > Reading package lists... > Building dependency tree... > Reading state information... > Correcting dependencies... Done > The following additional packages will be installed: > libclass-method-modifiers-perl libconvert-binhex-perl libdata-perl-perl > libdevel-globaldestruction-perl libgnupg-interface-perl > libimport-into-perl > libmime-tools-perl libmodule-build-perl libmodule-runtime-perl libmoo-perl > libmoox-handlesvia-perl libmoox-late-perl libparams-classify-perl > librole-tiny-perl libstrictures-perl libsub-exporter-progressive-perl > libtest-pod-perl libtype-tiny-perl > Suggested packages: > libscalar-number-perl libbareword-filehandles-perl libindirect-perl > libmultidimensional-perl libdevel-stacktrace-perl > Recommended packages: > libmodule-signature-perl libpod-readme-perl libsoftware-license-perl > libclass-xsaccessor-perl libdevel-lexalias-perl libtype-tiny-xs-perl > The following NEW packages will be installed: > libclass-method-modifiers-perl libconvert-binhex-perl libdata-perl-perl > libdevel-globaldestruction-perl libgnupg-interface-perl > libimport-into-perl > libmime-tools-perl libmodule-build-perl libmodule-runtime-perl libmoo-perl > libmoox-handlesvia-perl libmoox-late-perl libparams-classify-perl > librole-tiny-perl libstrictures-perl libsub-exporter-progressive-perl > libtest-pod-perl libtype-tiny-perl > 0 upgraded, 18 newly installed, 0 to remove and 0 not upgraded. > 1 not fully installed or removed. > Need to get 1148 kB of archives. > After this operation, 2785 kB of additional disk space will be used. > Get:1 http://httpredir.debian.org/debian sid/main amd64 > libmodule-build-perl all 0.421800-2 [259 kB] > Get:2 http://httpredir.debian.org/debian sid/main amd64 > libclass-method-modifiers-perl all 2.12-1 [18.6 kB] > Get:3 http://httpredir.debian.org/debian sid/main amd64 > libsub-exporter-progressive-perl all 0.001011-1 [7748 B] > Get:4 http://httpredir.debian.org/debian sid/main amd64 > libdevel-globaldestruction-perl all 0.13-1 [8676 B] > Get:5 http://httpredir.debian.org/debian sid/main amd64 > libparams-classify-perl amd64 0.013-6 [24.2 kB] > Get:6 http://httpredir.debian.org/debian sid/main amd64 > libmodule-runtime-perl all 0.014-2 [18.0 kB] > Get:7 http://httpredir.debian.org/debian sid/main amd64 libimport-into-perl > all 1.002005-1 [11.6 kB] > Get:8 http://httpredir.debian.org/debian sid/main amd64 librole-tiny-perl > all 2.03-1 [19.0 kB] > Get:9 http://httpredir.debian.org/debian sid/main amd64 libstrictures-perl > all 2.03-1 [18.1 kB] > Get:10 http://httpredir.debian.org/debian sid/main amd64 libmoo-perl all > 2.002004-1 [66.8 kB] > Get:11 http://httpredir.debian.org/debian sid/main amd64 libdata-perl-
Re: Bug#835592: php-crypt-gpg: FTBFS: Tests: 286, Assertions: 514, Errors: 77, Failures: 8, Skipped: 8
Hi Daniel, Daniel Kahn Gillmor wrote: > On Tue 2016-08-30 06:49:30 -0400, Axel Beckert wrote: > > Daniel Kahn Gillmor wrote: > >> However, if your next upload of php-crypt-gpg can't be built or run > >> against modern versions of GnuPG, then you probably need to state this > >> package's dependency on gnupg as gnupg (<= 2.1). > > > > Shouldn't "gnupg1" be used then nowadays? > > that would involve a fix of forcing php-crypt-gpg to use and look for > /usr/bin/gpg1. Correct. > that would make me sad, because it would mean that the users of > php-crypt-gpg would be unable to benefit from the work happening on > GnuPG's modern branch. Well, I consider that to be a temporary workaround, not a permanent solution. Like with libgnupg-interface-perl or python-gnupg. > So yeah, it's possible to do it that way but i really hope it doesn't > come to that. Well, if you (build-)depend on "gnupg (<= 2.1)" and upload to unstable, the package will no more be installable on Unstable nor buildable on Unstable due to unsatisfiable (build-)dependencies as the gnupg package in Unstable is already at a version >> 2.1. So I don't see how depending on "gnupg (<= 2.1)" could be considered a solution at all. Regards, Axel -- ,''`. | Axel Beckert , http://people.debian.org/~abe/ : :' : | Debian Developer, ftp.ch.debian.org Admin `. `' | 4096R: 2517 B724 C5F6 CA99 5329 6E61 2FF9 CD59 6126 16B5 `-| 1024D: F067 EA27 26B9 C3FC 1486 202E C09E 1D89 9593 0EDE ___ Reproducible-builds mailing list Reproducible-builds@lists.alioth.debian.org http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/reproducible-builds
Bug#836070: r-cran-sem: FTBFS: ERROR: dependencies 'MASS', 'boot' are not available for package 'sem'
Source: r-cran-sem Version: 3.1.7-3 Severity: serious Justification: fails to build from source User: reproducible-builds@lists.alioth.debian.org Usertags: ftbfs X-Debbugs-Cc: reproducible-builds@lists.alioth.debian.org Dear Maintainer, r-cran-sem fails to build from source in unstable/amd64: [..] Selecting previously unselected package libpango-1.0-0:amd64. Preparing to unpack .../34-libpango-1.0-0_1.40.1-1_amd64.deb ... Unpacking libpango-1.0-0:amd64 (1.40.1-1) ... Selecting previously unselected package libgraphite2-3:amd64. Preparing to unpack .../35-libgraphite2-3_1.3.8-1_amd64.deb ... Unpacking libgraphite2-3:amd64 (1.3.8-1) ... Selecting previously unselected package libharfbuzz0b:amd64. Preparing to unpack .../36-libharfbuzz0b_1.2.7-1+b1_amd64.deb ... Unpacking libharfbuzz0b:amd64 (1.2.7-1+b1) ... Selecting previously unselected package libpangoft2-1.0-0:amd64. Preparing to unpack .../37-libpangoft2-1.0-0_1.40.1-1_amd64.deb ... Unpacking libpangoft2-1.0-0:amd64 (1.40.1-1) ... Selecting previously unselected package libpangocairo-1.0-0:amd64. Preparing to unpack .../38-libpangocairo-1.0-0_1.40.1-1_amd64.deb ... Unpacking libpangocairo-1.0-0:amd64 (1.40.1-1) ... Selecting previously unselected package libsm6:amd64. Preparing to unpack .../39-libsm6_2%3a1.2.2-1+b1_amd64.deb ... Unpacking libsm6:amd64 (2:1.2.2-1+b1) ... Selecting previously unselected package libtcl8.6:amd64. Preparing to unpack .../40-libtcl8.6_8.6.6+dfsg-1_amd64.deb ... Unpacking libtcl8.6:amd64 (8.6.6+dfsg-1) ... Selecting previously unselected package libjbig0:amd64. Preparing to unpack .../41-libjbig0_2.1-3.1_amd64.deb ... Unpacking libjbig0:amd64 (2.1-3.1) ... Selecting previously unselected package libtiff5:amd64. Preparing to unpack .../42-libtiff5_4.0.6-2_amd64.deb ... Unpacking libtiff5:amd64 (4.0.6-2) ... Selecting previously unselected package libxft2:amd64. Preparing to unpack .../43-libxft2_2.3.2-1_amd64.deb ... Unpacking libxft2:amd64 (2.3.2-1) ... Selecting previously unselected package libxss1:amd64. Preparing to unpack .../44-libxss1_1%3a1.2.2-1_amd64.deb ... Unpacking libxss1:amd64 (1:1.2.2-1) ... Selecting previously unselected package libtk8.6:amd64. Preparing to unpack .../45-libtk8.6_8.6.6-1_amd64.deb ... Unpacking libtk8.6:amd64 (8.6.6-1) ... Selecting previously unselected package libxt6:amd64. Preparing to unpack .../46-libxt6_1%3a1.1.5-1_amd64.deb ... Unpacking libxt6:amd64 (1:1.1.5-1) ... Selecting previously unselected package openssl. Preparing to unpack .../47-openssl_1.0.2h-1_amd64.deb ... Unpacking openssl (1.0.2h-1) ... Selecting previously unselected package ca-certificates. Preparing to unpack .../48-ca-certificates_20160104_all.deb ... Unpacking ca-certificates (20160104) ... Selecting previously unselected package r-base-core. Preparing to unpack .../49-r-base-core_3.3.1-1+b1_amd64.deb ... Unpacking r-base-core (3.3.1-1+b1) ... Selecting previously unselected package libgfortran-6-dev:amd64. Preparing to unpack .../50-libgfortran-6-dev_6.2.0-1_amd64.deb ... Unpacking libgfortran-6-dev:amd64 (6.2.0-1) ... Selecting previously unselected package gfortran-6. Preparing to unpack .../51-gfortran-6_6.2.0-1_amd64.deb ... Unpacking gfortran-6 (6.2.0-1) ... Selecting previously unselected package gfortran. Preparing to unpack .../52-gfortran_4%3a6.1.1-1_amd64.deb ... Unpacking gfortran (4:6.1.1-1) ... Selecting previously unselected package libblas-dev. Preparing to unpack .../53-libblas-dev_3.6.1-2_amd64.deb ... Unpacking libblas-dev (3.6.1-2) ... Selecting previously unselected package liblapack-dev. Preparing to unpack .../54-liblapack-dev_3.6.1-2_amd64.deb ... Unpacking liblapack-dev (3.6.1-2) ... Selecting previously unselected package libtinfo-dev:amd64. Preparing to unpack .../55-libtinfo-dev_6.0+20160625-1_amd64.deb ... Unpacking libtinfo-dev:amd64 (6.0+20160625-1) ... Selecting previously unselected package libncurses5-dev:amd64. Preparing to unpack .../56-libncurses5-dev_6.0+20160625-1_amd64.deb ... Unpacking libncurses5-dev:amd64 (6.0+20160625-1) ... Selecting previously unselected package libreadline6-dev:amd64. Preparing to unpack .../57-libreadline6-dev_6.3-8+b4_amd64.deb ... Unpacking libreadline6-dev:amd64 (6.3-8+b4) ... Selecting previously unselected package libreadline-dev:amd64. Preparing to unpack .../58-libreadline-dev_6.3-8+b4_amd64.deb ... Unpacking libreadline-dev:amd64 (6.3-8+b4) ... Selecting previously unselected package libjpeg62-turbo-dev:amd64. Preparing to unpack .../59-libjpeg62-turbo-dev_1%3a1.5.0-1_amd64.deb ... Unpacking libjpeg62-turbo-dev:amd64 (1:1.5.0-1) ... Selecting previously unselected package libjpeg-dev. Preparing to unpack .../60-libjpeg-dev_1%3a1.5.0-1_all.deb ... Unpacking libjpeg-dev (1:1.5.0-1) ... Selecting previously unselected package libpcre16-3:amd64. Preparing to unpack .../61-libpc
Re: Bug#835592: php-crypt-gpg: FTBFS: Tests: 286, Assertions: 514, Errors: 77, Failures: 8, Skipped: 8
On Tue 2016-08-30 06:49:30 -0400, Axel Beckert wrote: > Daniel Kahn Gillmor wrote: >> However, if your next upload of php-crypt-gpg can't be built or run >> against modern versions of GnuPG, then you probably need to state this >> package's dependency on gnupg as gnupg (<= 2.1). > > Shouldn't "gnupg1" be used then nowadays? that would involve a fix of forcing php-crypt-gpg to use and look for /usr/bin/gpg1. that would make me sad, because it would mean that the users of php-crypt-gpg would be unable to benefit from the work happening on GnuPG's modern branch. and the fixes available in gcrypt itself. So yeah, it's possible to do it that way but i really hope it doesn't come to that. --dkg signature.asc Description: PGP signature ___ Reproducible-builds mailing list Reproducible-builds@lists.alioth.debian.org http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/reproducible-builds
Re: Bug#835592: php-crypt-gpg: FTBFS: Tests: 286, Assertions: 514, Errors: 77, Failures: 8, Skipped: 8
Hi, Daniel Kahn Gillmor wrote: > However, if your next upload of php-crypt-gpg can't be built or run > against modern versions of GnuPG, then you probably need to state this > package's dependency on gnupg as gnupg (<= 2.1). Shouldn't "gnupg1" be used then nowadays? Regards, Axel -- ,''`. | Axel Beckert , http://people.debian.org/~abe/ : :' : | Debian Developer, ftp.ch.debian.org Admin `. `' | 4096R: 2517 B724 C5F6 CA99 5329 6E61 2FF9 CD59 6126 16B5 `-| 1024D: F067 EA27 26B9 C3FC 1486 202E C09E 1D89 9593 0EDE ___ Reproducible-builds mailing list Reproducible-builds@lists.alioth.debian.org http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/reproducible-builds
Re: [Reproducible-builds] Bug#835465: python-apt: FTBFS: AptKeyError: recv from 'hkp://localhost:19191' failed for '0xa1bD8E9D78F7FE5C3E65D8AF8B48AD6246925553'
Control: affects 835465 + gnupg2
Hi python-apt folks--
On Thu 2016-08-25 20:55:27 -0400, Chris Lamb wrote:
> Source: python-apt
> Version: 1.1.0~beta4
> Severity: serious
> Justification: fails to build from source
> User: reproducible-builds@lists.alioth.debian.org
> Usertags: ftbfs
> X-Debbugs-Cc: reproducible-builds@lists.alioth.debian.org
>
> Dear Maintainer,
>
> python-apt fails to build from source in unstable/amd64:
>
> set -e; for python in python2.7 python3.5 ; do \
> $python tests/test_all.py -q || [ "linux" = "hurd" ]; \
> done;
> Warning: apt-key output should not be parsed (stdout is not a terminal)
> Warning: apt-key output should not be parsed (stdout is not a terminal)
> Warning: apt-key output should not be parsed (stdout is not a terminal)
> Warning: apt-key output should not be parsed (stdout is not a terminal)
> Warning: apt-key output should not be parsed (stdout is not a terminal)
> Warning: apt-key output should not be parsed (stdout is not a terminal)
this warning is advice about one of the things that might be going wrong
in some places in the test suite ;) I see that in upstream
7a9a292fd604bc164eed3d3fee1dc9167141d88c you're deprecating this, but i
strongly caution against this.
> [tests] Running on 2.7.12+ (default, Aug 4 2016, 20:04:34) [GCC 6.1.1
> 20160724]
> Using library_dir:
> '/home/lamby/temp/cdt.20160826014142.YuAeJNcC8b.db.python-apt/python-apt-1.1.0~beta4/build/lib.linux-x86_64-2.7'WARNING:
> Failed to read mirror file
> WARNING: Failed to read mirror file
> WARNING: Failed to read mirror file
> WARNING: Failed to read mirror file
> WARNING: Failed to read mirror file
> WARNING: Failed to read mirror file
> WARNING: Failed to read mirror file
> WARNING: Failed to read mirror file
> ==
> ERROR: testAddKeyFromServer (test_auth.TestAuthKeys)
> Install a GnuPG key from a remote server.
> --
> Traceback (most recent call last):
> File
> "/home/lamby/temp/cdt.20160826014142.YuAeJNcC8b.db.python-apt/python-apt-1.1.0~beta4/tests/test_auth.py",
> line 220, in testAddKeyFromServer
> "hkp://localhost:%d" % self.keyserver_port)
> File
> "/home/lamby/temp/cdt.20160826014142.YuAeJNcC8b.db.python-apt/python-apt-1.1.0~beta4/build/lib.linux-x86_64-2.7/apt/auth.py",
> line 128, in add_key_from_keyserver
> _add_key_from_keyserver(keyid, keyserver, tmp_keyring_dir)
> File
> "/home/lamby/temp/cdt.20160826014142.YuAeJNcC8b.db.python-apt/python-apt-1.1.0~beta4/build/lib.linux-x86_64-2.7/apt/auth.py",
> line 156, in _add_key_from_keyserver
> keyserver, keyid))
> AptKeyError: recv from 'hkp://localhost:19191' failed for
> '0xa1bD8E9D78F7FE5C3E65D8AF8B48AD6246925553'
apt/auth.py appears to want to force gnupg to store its secret key
material in secring.gpg. This isn't a best practice, and modern
versions of gpg do not do so by default. I'd recommend dropping
tmp_secret_keyring entirely.
furthermore, recent versions of gnupg (>= 2.1) do not fetch things from
keyservers directly -- if you want modern gpg to talk to the network,
you'll need to ensure that dirmngr is installed.
If you prefer to keep this test intact, you might want to build-depend
on dirmngr.
> ==
> FAIL: testAddAndExportKey (test_auth.TestAuthKeys)
> Add an example key.
> --
> Traceback (most recent call last):
> File
> "/home/lamby/temp/cdt.20160826014142.YuAeJNcC8b.db.python-apt/python-apt-1.1.0~beta4/tests/test_auth.py",
> line 157, in testAddAndExportKey
> WHEEZY_KEY.split("\n")[2:])
> AssertionError: Lists differ: ['mQINBE+a7rUBEADQiEKtLOgqiq8Y... != ['',
> 'mQINBE+a7rUBEADQiEKtLOgq...
>
> First differing element 0:
> 'mQINBE+a7rUBEADQiEKtLOgqiq8YY/p7IFODMqGPR+o1vtXaksie8iTOh3Vxab38'
> ''
>
> Second list contains 1 additional elements.
> First extra element 81:
> '-END PGP PUBLIC KEY BLOCK-'
>
> Diff is 5698 characters long. Set self.maxDiff to None to see it.
This change is due to the fact that upstream has stopped emitting the
Version: pseudoheader at all as of 2.1.14. Perhaps your build-dependency on
gnupg should be (>= 2.1.14) and you should strike the Version:
pseudoheader in WHEEZY_KEY in tests/test_auth.py
> ==
> FAIL: testAddAndListKey (test_auth.TestAuthKeys)
> Add an example key and test if it is correctly returned by
> --
> Traceback (most recent call last):
> File
> "/home/lamby/temp/cdt.20160826014142.YuAeJNcC8b.db.python-apt/python-apt-1.1.0~beta4/tests/test_auth.py",
> line 168, in testAddAndListKey
> "Debian Archive Automatic S
Re: Bug#835592: php-crypt-gpg: FTBFS: Tests: 286, Assertions: 514, Errors: 77, Failures: 8, Skipped: 8
Control: affects 835592 src:gnupg2 Hi php maintainers-- over on https://bugs.debian.org/835592 , Chris Lamb wrote: > Source: php-crypt-gpg > Version: 1.4.1-1 > Severity: serious > Justification: fails to build from source > User: reproducible-builds@lists.alioth.debian.org > Usertags: ftbfs > X-Debbugs-Cc: reproducible-builds@lists.alioth.debian.org > > Dear Maintainer, > > php-crypt-gpg fails to build from source in unstable/amd64: > > [..] > > +'_hasPrivate' => false > > @@ @@ >'_usage' => 1 > -'_hasPrivate' => true > +'_hasPrivate' => false >'_isRevoked' => false >) >) >) >) > > > /home/lamby/temp/cdt.20160827100527.NHNbg5FUA3.db.php-crypt-gpg/php-crypt-gpg-1.4.1/Crypt_GPG-1.4.1/tests/GetKeysTest.php:297 > > 7) KeyGeneratorTestCase::testSetExpirationDate_string > Setting expiration date by string failed. > Failed asserting that 196400 matches expected 20. > > > /home/lamby/temp/cdt.20160827100527.NHNbg5FUA3.db.php-crypt-gpg/php-crypt-gpg-1.4.1/Crypt_GPG-1.4.1/tests/KeyGeneratorTest.php:240 > > 8) SubKeyTestCase::testParseCreationDateIso > Failed asserting that two objects are equal. > --- Expected > +++ Actual > @@ @@ >Crypt_GPG_SubKey Object ( >'_id' => '8C37DBD2A01B7976' >'_algorithm' => 16 >'_fingerprint' => '' >'_length' => 2048 > -'_creationDate' => 1221442255 > +'_creationDate' => 1221438655 >'_expirationDate' => 0 >'_usage' => 1 >'_hasPrivate' => false >'_isRevoked' => false >) > > > /home/lamby/temp/cdt.20160827100527.NHNbg5FUA3.db.php-crypt-gpg/php-crypt-gpg-1.4.1/Crypt_GPG-1.4.1/tests/SubKeyTest.php:209 > > ERRORS! > Tests: 286, Assertions: 514, Errors: 77, Failures: 8, Skipped: 8. > debian/rules:7: recipe for target 'override_dh_auto_test' failed > make[1]: *** [override_dh_auto_test] Error 2 > make[1]: Leaving directory > '/home/lamby/temp/cdt.20160827100527.NHNbg5FUA3.db.php-crypt-gpg/php-crypt-gpg-1.4.1' > debian/rules:3: recipe for target 'build' failed > make: *** [build] Error 2 > > [..] I suspect that many of these 77 failures are the result of php-crypt-gpg not working properly with gnupg 2.1.x. (though some of them do appear to be timestamp variations that might be worth unravelling separately) I'll be releasing a new version of gnupg shortly that will explicitly declare that it Breaks: php-crypt-gpg (<= 1.4.1-1). Ideally, the next version of php-crypt-gpg can have this bug fixed and it will work cleanly with the modern version of gnupg. However, if your next upload of php-crypt-gpg can't be built or run against modern versions of GnuPG, then you probably need to state this package's dependency on gnupg as gnupg (<= 2.1). Regards, --dkg signature.asc Description: PGP signature ___ Reproducible-builds mailing list Reproducible-builds@lists.alioth.debian.org http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/reproducible-builds
