Hi Guillem,
thanks for the quick answer.
> I think this is just git being missing in that chroot. And I see the
No, even with git it breaks the same way. But what I did is
# in the git repo
gbp buildpackage -us -uc -rfakeroot -S
# then
cowbuilder --build --buildre
On Mon, 2020-06-29 at 10:27:51 +0900, Norbert Preining wrote:
> > I assume you have the key found in the upstream/signing-key.asc in
> > your keyring,
>
> No, I don't have it. Is this a (new?) requirement?
No, was just a wild guess in case gpg was getting confused by seeing a
missing private key
Hi Guillem,
> I think this might have been fixed in git already (with the changes to
Sounds great!
> I assume you have the key found in the upstream/signing-key.asc in
> your keyring,
No, I don't have it. Is this a (new?) requirement?
> perhaps that's even your private key?
No, it is upstream
Hi!
On Mon, 2020-06-29 at 09:19:18 +0900, Norbert Preining wrote:
> Package: libdpkg-perl
> Version: 1.20.2
> Severity: serious
> Justification: breaks unrelated packages
> it seems that the bump to 1.20 changed the behaviour of building
> packages, i.e., dpkg-source -b . doesn't work anymore, ou
Package: libdpkg-perl
Version: 1.20.2
Severity: serious
Justification: breaks unrelated packages
Hi,
it seems that the bump to 1.20 changed the behaviour of building
packages, i.e., dpkg-source -b . doesn't work anymore, out of the blue,
due to signature/key import errors:
$ dpkg-source -b .
dpk
Control: clone -1 -2
Control: reassign -2 sbuild
Control: retitle -2 sbuild: Uses deprecated Dpkg::Build::Info function
Control: severity -2 important
[ Retrying with the correct control syntax this time. :) ]
On Sun, 2020-06-28 at 12:37:25 +0200, Guillem Jover wrote:
> [ Perhaps due to autopkgte
Control: clone -1 -2 sbuild
Control: retitle -2 sbuild: Uses deprecated Dpkg::Build::Info function
Control: severity -2 important
[ Perhaps due to autopkgtest failure this should be serious? I'm
leaving this up to the maintainers. :) ]
Hi!
On Sun, 2020-06-28 at 12:18:44 +0200, Sven Joachim wro
Processing control commands:
> clone -1 -2
Bug #963844 [libdpkg-perl] libdpkg-perl: unclear deprecation warning from
get_build_env_whitelist()
Bug 963844 cloned as bug 963845
> reassign -2 sbuild
Bug #963845 [libdpkg-perl] libdpkg-perl: unclear deprecation warning from
get_build_env_whitelist()
Processing control commands:
> tag 963844 pending
Bug #963844 [libdpkg-perl] libdpkg-perl: unclear deprecation warning from
get_build_env_whitelist()
Added tag(s) pending.
--
963844: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=963844
Debian Bug Tracking System
Contact ow...@bugs.debian.or
Processing control commands:
> tag 963839 pending
Bug #963839 [dpkg-dev] dpkg-dev: gpg tries to write in $HOME when verifying
signatures
Added tag(s) pending.
--
963839: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=963839
Debian Bug Tracking System
Contact ow...@bugs.debian.org with proble
Package: libdpkg-perl
Version: 1.20.2
Severity: normal
I have seen the following warning when running sbuild-update:
,
| use get_build_env_allowed() instead at /usr/share/perl5/Sbuild/Conf.pm line
1486.
`
Which gave me absolutely no clue: instead _of what_ (looking at
/usr/share/perl5/S
Package: dpkg-dev
Version: 1.20.2
Severity: normal
Dear Maintainer,
Since dpkg-dev 1.2O.1, dpkg-buildpackage tries to verify tarball signatures from
debian/upstream/signing-key.asc with gpg. When called, gpg tries to write a file
in $HOME/.gnupg. This is not allowed by default when building with
12 matches
Mail list logo
