[scl.org] Question about generating RPMs that depend on SCLs (like python27)

[Alan Robertson]

Next error - not sure what to do about this one...


+ scl enable python27 
'/usr/lib/rpm/redhat/brp-python-bytecompile-with-scl-python 
/usr/bin/python 1 %{_scl_root}'
Compiling 
/rpmbuild/BUILDROOT/assimilation-cma-0.1.4-0.30.x86_64/opt/rh/python27/root/usr/lib64/python2.7/site-packages/assimilation/assimcli.py 
...
SyntaxError: ('invalid syntax', 
('/opt/rh/python27/root/usr/lib64/python2.7/site-packages/assimilation/assimcli.py', 
157, 22, "options = {'language', 'format'}\n"))

Compiling 
/rpmbuild/BUILDROOT/assimilation-cma-0.1.4-0.30.x86_64/opt/rh/python27/root/usr/lib64/python2.7/site-packages/assimilation/cmaconfig.py 
...
SyntaxError: ('invalid syntax', 
('/opt/rh/python27/root/usr/lib64/python2.7/site-packages/assimilation/cmaconfig.py', 
42, 53, " {'linkdiscovery',       # listens for CMA/LLDP packets\n"))

*[This syntax is >= 2.7 python only]*

error: Bad exit status from /var/tmp/rpm-tmp.FIkESm (%install)
     Bad exit status from /var/tmp/rpm-tmp.FIkESm (%install)

> scl enable python27 
> '/usr/lib/rpm/redhat/brp-python-bytecompile-with-scl-python 
> /usr/bin/python 1 %{_scl_root

It is using /usr/bin/python to compile my python 2.7 programs. What's up 
with that?


On 07/18/2014 11:15 AM, Alan Robertson wrote:
> Next error:
>
> extracting debug info from 
> /rpmbuild/BUILDROOT/assimilation-cma-0.1.4-0.30.x86_64/usr/sbin/nanoprobe
> 1376 blocks
> + /usr/lib/rpm/check-buildroot
> + /usr/lib/rpm/brp-scl-compress '%{_scl_root}'
> + /usr/lib/rpm/redhat/brp-strip /usr/bin/strip
> + /usr/lib/rpm/redhat/brp-strip-comment-note /usr/bin/strip 
> /usr/bin/objdump
> + /usr/lib/rpm/redhat/brp-strip-static-archive /usr/bin/strip
> + scl enable %scl 
> '/usr/lib/rpm/redhat/brp-python-bytecompile-with-scl-python 
> /usr/bin/python 1 %{_scl_root}'
> Unable to open /etc/scl/prefixes/%scl!
> error: Bad exit status from /var/tmp/rpm-tmp.eqUbD6 (%install)
>     Bad exit status from /var/tmp/rpm-tmp.eqUbD6 (%install)
>
> I'm guessing need to define %scl.
>
> It looks to me like these macros expect that you're *defining* a 
> package, not using one.  Good thing I don't need more than one, or I'd 
> be in a world of hurt (which is how it feels now anyway).
>
>
> On 07/18/2014 11:10 AM, Alan Robertson wrote:
>> On 07/16/2014 02:30 AM, Bohuslav Kabrda wrote:
>>> That's correct. The problem here is, I think, that the package 
>>> places it's files into sitearch of the SCL, but it's not actually an 
>>> SCL package. One of the results of having it as non-SCL package 
>>> means, that %scl_package_override() function, present in the 
>>> python27-build subpackage doesn't get invoked. This function looks 
>>> like this (you need to 's/@scl@/python27/'):
>>>
>>> # override __os_install_post for this collection
>>> # the python27_os_install_post macro is defined in 
>>> macros.python2.python27 in python27-python-devel
>>> # the name is intentionally hardcoded to always provide the same name
>>> %scl_package_override() %{expand:%{?@scl at _os_install_post:%global 
>>> __os_install_post %@scl at _os_install_post}
>>> %global __python_requires %@scl at _python_requires
>>> %global __python_provides %@scl at _python_provides
>> This looks like it has a typo in it.
>>
>> If @scl@ is python27, then
>>
>>     %global __python_requires %@scl at _python_requires
>> becomes
>>     %global __python_requires python27_python_requires
>> and
>>     %global __python_provides %@scl at _python_provides
>> becomes
>>     %global __python_provides python27_python_provides
>>
>> Why is the original spelled with two underscores 
>> ("__python_requires") but the replacement name 
>> ("python27_python_requires") only has one underscore?
>>
>> This seems a bit inconsistent...  It looks correct, but inconsistent...
>>
>>
>> I see that the python27_python_requires macro is defined in 
>> /etc/rpm/macros.python2.python27.  I see that __python_requires is 
>> defined in the file /usr/lib/rpm/macros.
>> The definition of python27_python_requires is:
>> %python27_python_provides /usr/lib/rpm/pythondeps-scl.sh --provides 
>> %{?scl_prefix}
>> %python27_python_requires /usr/lib/rpm/pythondeps-scl.sh --requires 
>> %{?scl_prefix}
>>
>> So, it expects you to set scl_prefix.  I set it to "python27-" From 
>> what I can see in the macro definitions, that's what I expect it 
>> would want.
>>
>> Well, at least now I get different problems!
>>
>> + install -p -D -m0755 
>> /rpmbuild/BUILDROOT/assimilation-cma-0.1.4-0.30.x86_64/etc/init.d/cma 
>> /rpmbuild/BUILDROOT/assimilation-cma-0.1.4-0.30.x86_64/etc/rc.d/init.d/assimilation-cma 
>>
>> + install -p -D -m0755 
>> /rpmbuild/BUILDROOT/assimilation-cma-0.1.4-0.30.x86_64/etc/init.d/nanoprobe 
>> /rpmbuild/BUILDROOT/assimilation-cma-0.1.4-0.30.x86_64/etc/rc.d/init.d/assimilation-nanoprobe 
>>
>> + rm -f 
>> /rpmbuild/BUILDROOT/assimilation-cma-0.1.4-0.30.x86_64/etc/init.d/cma 
>> /rpmbuild/BUILDROOT/assimilation-cma-0.1.4-0.30.x86_64/etc/init.d/nanoprobe 
>>
>> + mkdir -p 
>> /rpmbuild/BUILDROOT/assimilation-cma-0.1.4-0.30.x86_64/var/run/assimilation
>> + mkdir -p 
>> /rpmbuild/BUILDROOT/assimilation-cma-0.1.4-0.30.x86_64/var/run/nanoprobe
>> + mkdir -p 
>> /rpmbuild/BUILDROOT/assimilation-cma-0.1.4-0.30.x86_64/usr/lib64
>> + mkdir -p 
>> /rpmbuild/BUILDROOT/assimilation-cma-0.1.4-0.30.x86_64/opt/rh/python27/root//usr/lib64/python2.7/site-packages/assimilation/testcode
>> + /usr/lib/rpm/brp-scl-compress '%{_scl_root}'
>> /var/tmp/rpm-tmp.uQBlOW: line 59: /usr/lib/rpm/brp-scl-compress: No 
>> such file or directory
>> error: Bad exit status from /var/tmp/rpm-tmp.uQBlOW (%install)
>>     Bad exit status from /var/tmp/rpm-tmp.uQBlOW (%install)
>>
>> Looks like that should come from scl-utils-build...
>>
>
>


-- 
     Alan Robertson <alanr at unix.sh> - @OSSAlanR

"Openness is the foundation and preservative of friendship...  Let me claim from you at all times your undisguised opinions." - William Wilberforce

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://listman.redhat.com/archives/sclorg/attachments/20140718/0704f9f9/attachment.htm>