On Tue, 2018-05-15 at 20:47 +0100, Daniel P. Berrangé wrote:
> On Tue, May 15, 2018 at 08:17:09PM +0200, Andrea Bolognani wrote:
> > + /usr/bin/perl Build.PL installdirs=vendor
> > Created MYMETA.yml and MYMETA.json
> > Creating new 'Build' script for 'Sys-Virt' version 'v4.4.0'
> > + ./Build
> > Building Sys-Virt
> > ExtUtils::Mkbootstrap::Mkbootstrap('blib/arch/auto/Sys/Virt/Virt.bs')
> > gcc -lpthread -shared -Wl,-z,relro -Wl,-z,now -specs=/usr/lib/rpm/redhat/redhat-hardened-ld -L/usr/local/lib -fstack-protector-strong -lperl -o blib/arch/auto/Sys/Virt/Virt.so lib/Sys/Virt.o -L/home/test/build/lib
> > virt/lib -lvirt
>
> This is suspect - on mine it is much longer - in particular it has
> the -g flag for creating debuginfo packages
>
>
> + /usr/bin/perl Build.PL installdirs=vendor
> Created MYMETA.yml and MYMETA.json
> Creating new 'Build' script for 'Sys-Virt' version 'v4.4.0'
> + ./Build
> Building Sys-Virt
> gcc -I/usr/lib64/perl5/CORE -DVERSION="v4.4.0" -DXS_VERSION="v4.4.0" -fPIC -I/home/berrange/src/virt/libvirt/include -c -D_REENTRANT -D_GNU_SOURCE -O2 -g -pipe -Wall -Werror=format-security -Wp,-D_FORTIFY_SOURCE=2 -Wp,-D_GLIBCXX_ASSERTIONS -fexceptions -fstack-protector-strong -grecord-gcc-switches -specs=/usr/lib/rpm/redhat/redhat-hardened-cc1 -specs=/usr/lib/rpm/redhat/redhat-annobin-cc1 -m64 -mtune=generic -fasynchronous-unwind-tables -fstack-clash-protection -mcet -fcf-protection -fwrapv -fno-strict-aliasing -I/usr/local/include -D_LARGEFILE_SOURCE -D_FILE_OFFSET_BITS=64 -g -o lib/Sys/Virt.o lib/Sys/Virt.c
> ExtUtils::Mkbootstrap::Mkbootstrap('blib/arch/auto/Sys/Virt/Virt.bs')
> gcc -lpthread -shared -Wl,-z,relro -Wl,-z,now -specs=/usr/lib/rpm/redhat/redhat-hardened-ld -L/usr/local/lib -fstack-protector-strong -lperl -o blib/arch/auto/Sys/Virt/Virt.so lib/Sys/Virt.o -L/home/berrange/src/virt/libvirt/src/.libs -lvirt
Okay, I think I'm getting closer to understanding the problem
The CI build steps for Module::Build packages, with irrelevant
details omitted, look like
perl Build.PL install_base=...
perl Build
perl Build manifest
perl Build install
perl Build test
perl Build dist
rpmbuild -ta *.tar.gz
These are the steps I'm following. The prepare-release.sh script,
however, is slightly different:
perl Build.PL install_base=..
./Build
./Build test
./Build install
./Build dist
rpmbuild -ta *.tar.gz
The critical difference is that CI calls 'perl Build manifest',
while prepare-release.sh doesn't. If I remove that line from the
CI steps, the build suddenly succeeds on Fedora.
This is how the manifest is changed by the call, with both the
initial file and the updated one filtered through 'sort -u' to
remove the noise caused by some items changing position:
--- MANIFEST.old 2018-05-16 08:35:17.568120131 +0000
+++ MANIFEST.new 2018-05-16 08:35:12.246110781 +0000
@@ -31,10 +31,10 @@
examples/vol-upload-all.pl
examples/vol-upload-nonblock.pl
examples/vol-upload.pl
-.gitignore
.gitpublish
HACKING
INSTALL
+lib/Sys/Virt.c
lib/Sys/Virt/Domain.pm
lib/Sys/Virt/DomainSnapshot.pm
lib/Sys/Virt/Error.pm
@@ -43,6 +43,7 @@
lib/Sys/Virt/Network.pm
lib/Sys/Virt/NodeDevice.pm
lib/Sys/Virt/NWFilter.pm
+lib/Sys/Virt.o
lib/Sys/Virt.pm
lib/Sys/Virt/Secret.pm
lib/Sys/Virt/StoragePool.pm
@@ -51,6 +52,7 @@
lib/Sys/Virt.xs
LICENSE
Makefile.PL
+MANIFEST
META.json
META.yml
perl-Sys-Virt.spec
Interestingly, CentOS 7 is perfectly fine with the updated manifest;
only Fedora is bothered by it.
Another interesting fact is that libvirt-tck doesn't track its
manifest in git, and generates it a build time by calling the same
command as above. I'm not sure if that would be appropriate, but
perhaps a good solution would be to start tracking the manifest in
git for libvirt-tck too and stop calling 'perl Build manifest' as
part of the build procedure altogether.
--
Andrea Bolognani / Red Hat / Virtualization
--
libvir-list mailing list
libvir-list@xxxxxxxxxx
https://www.redhat.com/mailman/listinfo/libvir-list
