Re: [libvirt] [perl PATCH] Switch over to using Module::Build

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.