The full story is in https://bugzilla.redhat.com/show_bug.cgi?id=1480407 but to summarize, this is actually a bug in rpm 4.13.x which is not ignoring unknown signature header tag like it should, older rpm versions are not affected. Also the bug only affects signature checking with rpmkeys -K, packages can still be installed and even signed without problems. Rpm 4.13 needs to be updated in all active Fedora versions to correctly cope with it but that's going to take time and is not something I want to rush. So for the time being, I've disabled generation of the troublesome SHA256 header-only digest in 4.14 to be able to move on with it. We'll re-enable it once the updates to older versions have been completed, but there's no urgency to that now. Apologies for the entirely unexpected hickup :-/

On 08/10/2017 01:47 PM, Panu Matilainen wrote: > > Resending to devel@, some mishap in earlier... > > -------- Forwarded Message -------- > Subject: Heads-up on rpm 4.14 coming to rawhide, incl. soname bump > Date: Thu, 10 Aug 2017 20:50:30 +0300 > From: Panu Matilainen <pmatilai(a)redhat.com&gt; > To: devel-announce(a)lists.fedoraproject.org, Development discussions > related to Fedora <devel(a)lists.fedoraproject.org&gt; > > > Rpm 4.14 alpha is about to hit rawhide as per > https://fedoraproject.org/wiki/Changes/RPM-4.14. I realize we're a bit > late to the schedule, and much much later in the cycle than I'd like, > but lets try to get by. There's a soname bump involved so related > packages will need to be rebuilt, but Igor Gnatenko kindly promised to > take care of that. > > The other thing is the rpm macro engine which has seen by far its > biggest in the last 10+ years: > - Macro scoping is simplified, only macros %define'd inside parametric > macros are local, everything else is in global scope. This isn't as > big a change as is it may sound, because this is the way scoping only > ever really worked in previous versions. > - %{lua:} macros are scoped similarly to everything else. Previously > they could appear to be higher in the callchain than they are, causing > strange side-effects in already hard to debug complex macro constructs. > - Visibility is enforced per scope for automatic macros (ie %* %1 etc > that are created for parametric macros). In other words, nested macro > "calls" are more reliable as arguments from previous calls are not > visible. > - Arguments to parametric macros are now expanded before execution. > - Arguments to parametric macros now support quoting (single and double) > > For the average trivial macro usage, none of that will make a > difference. But I'd be almost shocked if nothing at all broke because > of this - former limitations and bugs might have necessiated tricks > and kludges that no longer work but also are not required any more > etc. So owners of complex macros, keep your eyes open. Okay, so this has hit the octave macro set, probably not unexpectedly. I'd appreciate some help with what I'm doing wrong, if anything: ENTER ['do'](['bash', '--login', '-c', '/usr/bin/rpmbuild -bb --target noarch --nodeps /builddir/build/SPECS/octave-statistics.spec'], logger=<mockbuild.trace_decorator.getLog object at 0x3fff945826d8>timeout=172800user='mockbuild'printOutput=Falseenv={'SHELL': '/bin/bash', 'HOME': '/builddir', 'PROMPT_COMMAND': 'printf "\\033]0;<mock-chroot>\\007"', 'PATH': '/usr/bin:/bin:/usr/sbin:/sbin', 'LANG': 'en_US.UTF-8', 'TERM': 'vt100', 'PS1': '<mock-chroot> \\s-\\v\\$ ', 'HOSTNAME': 'mock'}gid=425uid=1000shell=FalsechrootPath='/var/lib/mock/f27-build-9511079-776071/root'nspawn_args=[]) Executing command: ['bash', '--login', '-c', '/usr/bin/rpmbuild -bb --target noarch --nodeps /builddir/build/SPECS/octave-statistics.spec'] with env {'SHELL': '/bin/bash', 'HOME': '/builddir', 'PROMPT_COMMAND': 'printf "\\033]0;<mock-chroot>\\007"', 'PATH': '/usr/bin:/bin:/usr/sbin:/sbin', 'LANG': 'en_US.UTF-8', 'TERM': 'vt100', 'PS1': '<mock-chroot> \\s-\\v\\$ ', 'HOSTNAME': 'mock'} and shell False octave_cmd: invalid option -- 'n' error: Unknown option n in octave_cmd() error: line 31: %octave_pkg_install %install %octave_pkg_install %octave_pkg_install \ mkdir -p %{buildroot}%{octprefix} \ mkdir -p %{buildroot}%{octarchprefix} \ %octave_cmd pkg("prefix","%{buildroot}%{octprefix}","%{buildroot}%{octarchprefix}");pkg("global_list",fullfile("%{buildroot}%{octshareprefix}","octave_packages"));pkg("local_list",fullfile("%{buildroot}%{octshareprefix}","octave_packages"));pkg("install","-nodeps","-verbose","%{_builddir}/%{buildsubdir}/build/%{octpkg}-%{version}-%{octave_tar_suffix}.tar.gz");unlink(pkg("local_list"));unlink(pkg("global_list")); \ if [ -e %{buildroot}%{octpkgdir}/packinfo/on_uninstall.m ] \ then \ mv %{buildroot}%{octpkgdir}/packinfo/on_uninstall.m %{buildroot}%{octpkgdir}/packinfo/on_uninstall.m.orig \ fi \ echo "function on_uninstall (desc)" > %{buildroot}%{octpkgdir}/packinfo/on_uninstall.m \ echo " error ('Can not uninstall %s installed by the redhat package manager', desc.name);" >> %{buildroot}%{octpkgdir}/packinfo/on_uninstall.m \ echo "endfunction" >> %{buildroot}%{octpkgdir}/packinfo/on_uninstall.m \ if [ -e %{_builddir}/%{buildsubdir}/build/%{octpkg}-%{version}/octave-%{octpkg}.metainfo.xml ] \ then \ echo "Found octave-%{octpkg}.metainfo.xml" \ mkdir -p %{buildroot}/%{_datadir}/appdata \ cp -p %{_builddir}/%{buildsubdir}/build/%{octpkg}-%{version}/octave-%{octpkg}.metainfo.xml %{buildroot}/%{_datadir}/appdata/ \ appstream-util validate-relax --nonet %{buildroot}/%{_datadir}/appdata/octave-%{octpkg}.metainfo.xml \ fi \ %{nil} %octave_cmd() octave -H -q --no-window-system --no-site-file --eval '%*'; Somehow I think it's grabbing onto the "-nodeps" as an option.

On 08/13/2017 04:09 AM, Panu Matilainen wrote: > On 08/12/2017 06:29 PM, Orion Poplawski wrote: >> On 08/10/2017 01:47 PM, Panu Matilainen wrote: >>> >>> Resending to devel@, some mishap in earlier... >>> >>> -------- Forwarded Message -------- >>> Subject: Heads-up on rpm 4.14 coming to rawhide, incl. soname bump >>> Date: Thu, 10 Aug 2017 20:50:30 +0300 >>> From: Panu Matilainen <pmatilai(a)redhat.com&gt; >>> To: devel-announce(a)lists.fedoraproject.org, Development discussions >>> related to Fedora <devel(a)lists.fedoraproject.org&gt; >>> >>> >>> Rpm 4.14 alpha is about to hit rawhide as per >>> https://fedoraproject.org/wiki/Changes/RPM-4.14. I realize we're a >>> bit late to the schedule, and much much later in the cycle than I'd >>> like, but lets try to get by. There's a soname bump involved so >>> related packages will need to be rebuilt, but Igor Gnatenko kindly >>> promised to take care of that. >>> >>> The other thing is the rpm macro engine which has seen by far its >>> biggest in the last 10+ years: >>> - Macro scoping is simplified, only macros %define'd inside >>> parametric macros are local, everything else is in global scope. >>> This isn't as big a change as is it may sound, because this is the >>> way scoping only ever really worked in previous versions. >>> - %{lua:} macros are scoped similarly to everything else. Previously >>> they could appear to be higher in the callchain than they are, >>> causing strange side-effects in already hard to debug complex macro >>> constructs. >>> - Visibility is enforced per scope for automatic macros (ie %* %1 >>> etc that are created for parametric macros). In other words, nested >>> macro "calls" are more reliable as arguments from previous calls are >>> not visible. >>> - Arguments to parametric macros are now expanded before execution. >>> - Arguments to parametric macros now support quoting (single and >>> double) >>> >>> For the average trivial macro usage, none of that will make a >>> difference. But I'd be almost shocked if nothing at all broke >>> because of this - former limitations and bugs might have necessiated >>> tricks and kludges that no longer work but also are not required any >>> more etc. So owners of complex macros, keep your eyes open. >> >> Okay, so this has hit the octave macro set, probably not >> unexpectedly. I'd appreciate some help with what I'm doing wrong, if >> anything: >> >> ENTER ['do'](['bash', '--login', '-c', '/usr/bin/rpmbuild -bb >> --target noarch --nodeps >> /builddir/build/SPECS/octave-statistics.spec'], >> logger=<mockbuild.trace_decorator.getLog object at >> 0x3fff945826d8>timeout=172800user='mockbuild'printOutput=Falseenv={'SHELL': >> '/bin/bash', 'HOME': '/builddir', 'PROMPT_COMMAND': 'printf >> "\\033]0;<mock-chroot>\\007"', 'PATH': >> '/usr/bin:/bin:/usr/sbin:/sbin', 'LANG': 'en_US.UTF-8', 'TERM': >> 'vt100', 'PS1': '<mock-chroot> \\s-\\v\\$ ', 'HOSTNAME': >> 'mock'}gid=425uid=1000shell=FalsechrootPath='/var/lib/mock/f27-build-9511079-776071/root'nspawn_args=[]) >> >> Executing command: ['bash', '--login', '-c', '/usr/bin/rpmbuild -bb >> --target noarch --nodeps >> /builddir/build/SPECS/octave-statistics.spec'] with env {'SHELL': >> '/bin/bash', 'HOME': '/builddir', 'PROMPT_COMMAND': 'printf >> "\\033]0;<mock-chroot>\\007"', 'PATH': >> '/usr/bin:/bin:/usr/sbin:/sbin', 'LANG': 'en_US.UTF-8', 'TERM': >> 'vt100', 'PS1': '<mock-chroot> \\s-\\v\\$ ', 'HOSTNAME': 'mock'} and >> shell False >> octave_cmd: invalid option -- 'n' >> error: Unknown option n in octave_cmd() >> error: line 31: %octave_pkg_install >> >> %install >> %octave_pkg_install >> >> %octave_pkg_install \ >> mkdir -p %{buildroot}%{octprefix} \ >> mkdir -p %{buildroot}%{octarchprefix} \ >> %octave_cmd >> pkg("prefix","%{buildroot}%{octprefix}","%{buildroot}%{octarchprefix}");pkg("global_list",fullfile("%{buildroot}%{octshareprefix}","octave_packages"));pkg("local_list",fullfile("%{buildroot}%{octshareprefix}","octave_packages"));pkg("install","-nodeps","-verbose","%{_builddir}/%{buildsubdir}/build/%{octpkg}-%{version}-%{octave_tar_suffix}.tar.gz");unlink(pkg("local_list"));unlink(pkg("global_list")); >> \ >> if [ -e %{buildroot}%{octpkgdir}/packinfo/on_uninstall.m ] \ >> then \ >> mv %{buildroot}%{octpkgdir}/packinfo/on_uninstall.m >> %{buildroot}%{octpkgdir}/packinfo/on_uninstall.m.orig \ >> fi \ >> echo "function on_uninstall (desc)" > >> %{buildroot}%{octpkgdir}/packinfo/on_uninstall.m \ >> echo " error ('Can not uninstall %s installed by the redhat package >> manager', desc.name);" >> >> %{buildroot}%{octpkgdir}/packinfo/on_uninstall.m \ >> echo "endfunction" >> %{buildroot}%{octpkgdir}/packinfo/on_uninstall.m \ >> if [ -e >> %{_builddir}/%{buildsubdir}/build/%{octpkg}-%{version}/octave-%{octpkg}.metainfo.xml >> ] \ >> then \ >> echo "Found octave-%{octpkg}.metainfo.xml" \ >> mkdir -p %{buildroot}/%{_datadir}/appdata \ >> cp -p >> %{_builddir}/%{buildsubdir}/build/%{octpkg}-%{version}/octave-%{octpkg}.metainfo.xml >> %{buildroot}/%{_datadir}/appdata/ \ >> appstream-util validate-relax --nonet >> %{buildroot}/%{_datadir}/appdata/octave-%{octpkg}.metainfo.xml \ >> fi \ >> %{nil} >> >> >> %octave_cmd() octave -H -q --no-window-system --no-site-file --eval >> '%*'; >> >> >> Somehow I think it's grabbing onto the "-nodeps" as an option. >> > > Right, based on a quick look it seems to be caused by the recently > added single/double quoting support for macro arguments. > > IIRC there's no support for escaping the quoting currently, on the > notion that if you need to pass single quotes you use double quotes > and vice versa. But this seems to require both... > > + octave -H -q --no-window-system --no-site-file --eval 'pkg build > "-verbose" "-nodeps" /var/tmp/octave-statistics-1.3.0-5.fc25.x86_64 > /home/pmatilai/rpmbuild/BUILD/octave-statistics-1.3.0' > > I'll have a closer look tomorrow but please file a bug so it gets > properly tracked. Thanks, > > - Panu - Thanks, filed https://bugzilla.redhat.com/show_bug.cgi?id=1481025