Re: Fwd: Heads-up on rpm 4.14 coming to rawhide, incl. soname bump

2017-08-14 Thread Panu Matilainen

On 08/13/2017 06:24 PM, Orion Poplawski wrote:

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 
To: devel-annou...@lists.fedoraproject.org, Development discussions 
related to Fedora 



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=0x3fff945826d8>timeout=172800user='mockbuild'printOutput=Falseenv={'SHELL': 
'/bin/bash', 'HOME': '/builddir', 'PROMPT_COMMAND': 'printf 
"\\033]0;\\007"', 'PATH': 
'/usr/bin:/bin:/usr/sbin:/sbin', 'LANG': 'en_US.UTF-8', 'TERM': 
'vt100', 'PS1': ' \\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;\\007"', 'PATH': 
'/usr/bin:/bin:/usr/sbin:/sbin', 'LANG': 'en_US.UTF-8', 'TERM': 
'vt100', 'PS1': ' \\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/dou

Re: Fwd: Heads-up on rpm 4.14 coming to rawhide, incl. soname bump

2017-08-13 Thread Orion Poplawski

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 
To: devel-annou...@lists.fedoraproject.org, Development discussions 
related to Fedora 



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=0x3fff945826d8>timeout=172800user='mockbuild'printOutput=Falseenv={'SHELL': 
'/bin/bash', 'HOME': '/builddir', 'PROMPT_COMMAND': 'printf 
"\\033]0;\\007"', 'PATH': 
'/usr/bin:/bin:/usr/sbin:/sbin', 'LANG': 'en_US.UTF-8', 'TERM': 
'vt100', 'PS1': ' \\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;\\007"', 'PATH': 
'/usr/bin:/bin:/usr/sbin:/sbin', 'LANG': 'en_US.UTF-8', 'TERM': 
'vt100', 'PS1': ' \\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'

Re: Fwd: Heads-up on rpm 4.14 coming to rawhide, incl. soname bump

2017-08-13 Thread Panu Matilainen

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 
To: devel-annou...@lists.fedoraproject.org, Development discussions 
related to Fedora 



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=0x3fff945826d8>timeout=172800user='mockbuild'printOutput=Falseenv={'SHELL': 
'/bin/bash', 'HOME': '/builddir', 'PROMPT_COMMAND': 'printf 
"\\033]0;\\007"', 'PATH': '/usr/bin:/bin:/usr/sbin:/sbin', 
'LANG': 'en_US.UTF-8', 'TERM': 'vt100', 'PS1': ' \\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;\\007"', 'PATH': 
'/usr/bin:/bin:/usr/sbin:/sbin', 'LANG': 'en_US.UTF-8', 'TERM': 'vt100', 
'PS1': ' \\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

Re: Fwd: Heads-up on rpm 4.14 coming to rawhide, incl. soname bump

2017-08-12 Thread Orion Poplawski

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 
To: devel-annou...@lists.fedoraproject.org, Development discussions 
related to Fedora 



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=0x3fff945826d8>timeout=172800user='mockbuild'printOutput=Falseenv={'SHELL': 
'/bin/bash', 'HOME': '/builddir', 'PROMPT_COMMAND': 'printf 
"\\033]0;\\007"', 'PATH': '/usr/bin:/bin:/usr/sbin:/sbin', 
'LANG': 'en_US.UTF-8', 'TERM': 'vt100', 'PS1': ' \\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;\\007"', 'PATH': 
'/usr/bin:/bin:/usr/sbin:/sbin', 'LANG': 'en_US.UTF-8', 'TERM': 'vt100', 
'PS1': ' \\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.

--
Orion Poplawski
Technical Manager 303-415-9701 x222
NWRA/CoRA DivisionFAX: 303-415-9702
3380 Mitchell Lane  or...@cora.nwra.com
Boulder, CO 80301  http://www.cora.nwra.com
_

Re: Fwd: Heads-up on rpm 4.14 coming to rawhide, incl. soname bump

2017-08-11 Thread Kevin Fenzi
On 08/11/2017 02:02 AM, Panu Matilainen wrote:
> 
> 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 :-/

No problem, it happens. ;)

Thanks for looking into this quickly and pushing a fix.

kevin




signature.asc
Description: OpenPGP digital signature
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org


Re: Fwd: Heads-up on rpm 4.14 coming to rawhide, incl. soname bump

2017-08-11 Thread Panu Matilainen

On 08/11/2017 03:44 AM, Kevin Fenzi wrote:

Sadly we ran into a problem...

as soon as the new rpm was in the rawhide buildroot and builds were made with 
it, things started piling up in f27-pending (the tag things land in after build 
so the autosigner can sign them and move them to f27).

It seems old rpm cannot read headers of rpms made with the new version, 
resulting in no signing. ;(

Patrick filed:
https://bugzilla.redhat.com/show_bug.cgi?id=1480407

and untagged rpm 4.14 and all the things built after it landed in the 
buildroot. Those things will need to be built again now. ;(


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 :-/

- Panu -
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org


Re: Fwd: Heads-up on rpm 4.14 coming to rawhide, incl. soname bump

2017-08-10 Thread Kevin Fenzi
Sadly we ran into a problem... 

as soon as the new rpm was in the rawhide buildroot and builds were made with 
it, things started piling up in f27-pending (the tag things land in after build 
so the autosigner can sign them and move them to f27). 

It seems old rpm cannot read headers of rpms made with the new version, 
resulting in no signing. ;( 

Patrick filed:
https://bugzilla.redhat.com/show_bug.cgi?id=1480407

and untagged rpm 4.14 and all the things built after it landed in the 
buildroot. Those things will need to be built again now. ;( 

Build Tag   Built by
    
anaconda-27.19-5.fc27 f27-pending   ignatenkobrain
apt-0.5.15lorg3.95-29.git522.fc27 f27-pending   ignatenkobrain
deltarpm-3.6-23.fc27  f27-pending   ignatenkobrain
drpm-0.3.0-10.fc27f27-pending   ignatenkobrain
e2fsprogs-1.43.5-1.fc27   f27-pending   sandeen
git-2.14.1-1.fc27 f27-pending   tmz
gnome-shell-3.25.90-1.fc27f27-pending   fmuellner
gnome-shell-extensions-3.25.90-1.fc27 f27-pending   fmuellner
gnome-software-3.25.4-5.fc27  f27-pending   ignatenkobrain
grub2-2.02-5.fc27 f27-pending   kevin
initscripts-9.76-1.fc27   f27-pending   zbyszek
libappstream-glib-0.7.1-3.fc27f27-pending   ignatenkobrain
libextractor-1.4-6.fc27   f27-pending   ignatenkobrain
libqb-1.0.2-4.fc27f27-pending   jpokorny
libsolv-0.6.28-7.fc27 f27-pending   ignatenkobrain
libsoup-2.59.90.1-1.fc27  f27-pending   kalev
mingw-libsoup-2.59.90.1-1.fc27f27-pending   kalev
mingw-postgresql-9.6.4-1.fc27 f27-pending   mooninite
net-snmp-5.7.3-24.fc27f27-pending   ignatenkobrain
nodejs-vows-0.8.1-8.fc27  f27-pending   tomh
open-vm-tools-10.1.10-1.fc27  f27-pending   ravindrakumar
openscap-1.2.14-6.fc27f27-pending   ignatenkobrain
perl-RPM-VersionCompare-0.1.1-22.fc27 f27-pending   ignatenkobrain
rpmreaper-0.2.0-11.fc27   f27-pending   ignatenkobrain
rpmreaper-0.2.0-12.fc27   f27-pending   ignatenkobrain
satyr-0.23-4.fc27 f27-pending   ignatenkobrain
satyr-0.23-5.fc27 f27-pending   ignatenkobrain
scl-utils-2.0.1-18.fc27   f27-pending   ignatenkobrain
scl-utils-2.0.1-19.fc27   f27-pending   ignatenkobrain
seafile-client-6.1.0-1.fc27   f27-pending   jujens
serd-0.28.0-1.fc27f27-pending   tartina
systemtap-3.2-0.20170515gitc67d8f274b21.fc27  f27-pending   
ignatenkobrain
totem-pl-parser-3.25.90-1.fc27f27-pending   kalev



signature.asc
Description: OpenPGP digital signature
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org


Fwd: Heads-up on rpm 4.14 coming to rawhide, incl. soname bump

2017-08-10 Thread Panu Matilainen


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 
To: devel-annou...@lists.fedoraproject.org, Development discussions 
related to Fedora 



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.


From packagers POV, one of the bigger changes - debuginfo overhaul - 
has been backported to 4.13 in rawhide for a while now, so there 
shouldn't be any surprises on that front.


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.


Other than that, there are fairly massive changes to package reading and 
signature checking, signal handling and whatnot, but they're mostly 
under the hood. For details see http://rpm.org/wiki/Releases/4.14.0 (WIP 
as of now).


As usual, we'll be baby-sitting it closely for the first days and weeks 
and try to resolve any issues ASAP, whether it's a bug in rpm or macros 
needing updating to work with the new rules etc. Thank you for your 
patience and understanding.


On behalf of the rpm-team,

- Panu -
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org