python-backports_abc-0.5-1.aix6.1.noarch.rpm issue

[Teej]

Came across a weird behavior for python-backports_abc-0.5-1.aix6.1.noarch.rpm package installation:

Code: [Select]

$ sudo rpm -Uvh python-backports_abc-0.5-1.aix6.1.noarch.rpm
Preparing...                          ################################# [100%]
Updating / installing...
   1:python-backports_abc-0.5-1       warning: user ravi does not exist - using root
warning: user ravi does not exist - using root
warning: user ravi does not exist - using root
warning: user ravi does not exist - using root
warning: user ravi does not exist - using root
warning: user ravi does not exist - using root
warning: user ravi does not exist - using root
warning: user ravi does not exist - using root
warning: user ravi does not exist - using root
warning: user ravi does not exist - using root
warning: user ravi does not exist - using root
warning: user ravi does not exist - using root
warning: user ravi does not exist - using root
warning: user ravi does not exist - using root
warning: user ravi does not exist - using root
warning: user ravi does not exist - using root
warning: user ravi does not exist - using root
warning: user ravi does not exist - using root
################################# [100%]Who is Ravi, and why do we need that account?  Is it possible the package should be fixed?

Thanks.

[Michael]

Hi! Thanks for trying aixtools!

My packages are only installp - one reason being RPM packages and installp packages bite each other.

As to your questions: my guesses:

Who is ravi? I guess he/she was the person packaging it as an rpm.

[Teej]

Re: Installp - I downloaded everything from here:

https://www.ibm.com/developerworks/aix/library/aix-toolbox/alpha.html

From the FAQ linked to on that page: 

  5. Q:  Why aren't the tools in installp format?
     A:  RPM is a common packaging system on Linux platforms
     (though it is not on every Linux platform) and most popular open source
     projects are available as source RPMS (SRPMS), making it relatively
     straightforward to build new packages for the Toolbox.

Is that FAQ outdated?  Should we be undoing what we did, and redo using installp instead?  How exactly would that work with RPM packages?

Thanks.

[Teej]

I just realized that I was pinging the wrong forum for RPM-built issues.

My apologies for the confusion.

[Michael]

a) regarding python.abc - builtin in my packaging.

Code: [Select]

root@x070:[/]python -m test test_abc
Run tests sequentially
0:00:00 [1/1] test_abc
1 test OK.

Total duration: 58 ms
Tests result: SUCCESS
root@x070:[/]python -m test -v test_abc
== CPython 2.7.15 (default, May 7 2018, 16:04:01) [C]
==   AIX-1-00C291F54C00-powerpc-64bit big-endian
==   /tmp/test_python_7143560
== CPU count: 2
Run tests sequentially
0:00:00 [1/1] test_abc
test_abstractmethod_basics (test.test_abc.TestABC) ... ok
test_abstractmethod_integration (test.test_abc.TestABC) ... ok
test_abstractproperty_basics (test.test_abc.TestABC) ... ok
test_all_new_methods_are_called (test.test_abc.TestABC) ... ok
test_cache_leak (test.test_abc.TestABC) ... ok
test_isinstance_class (test.test_abc.TestABC) ... ok
test_isinstance_invalidation (test.test_abc.TestABC) ... ok
test_register_non_class (test.test_abc.TestABC) ... ok
test_registration_basics (test.test_abc.TestABC) ... ok
test_registration_builtins (test.test_abc.TestABC) ... ok
test_registration_edge_cases (test.test_abc.TestABC) ... ok
test_registration_transitiveness (test.test_abc.TestABC) ... ok
test_subclass_oldstyle_class (test.test_abc.TestABC) ... ok

----------------------------------------------------------------------
Ran 13 tests in 0.018s

OK
1 test OK.

Total duration: 167 ms
Tests result: SUCCESS

As to the FAQ - no, that is still current. And IBM AIX say they are going to continue with it - even added yum for AIX 7.2. However, their yum ONLY works with the bits they package.

So, RPM is still current on RedHat, Centos and I believe SLES. RH and Centos also use yum, while SLES uses zypper. Debian amd Ubuntu use a different (from RPM and installp) package manager. The program family apt are their package managers.

For AIX, the base package manager is "installp". As I frequently experienced issues such as you are having I taught myself how to package - and share what I use via http://www.aixtools.net

Bottom line: use what works best for you. If you use my packaging, and something is not working I try to get it fixed within a couple of days.

There are things in the Toolbox that I do not have. If you need something, and you would like it in installp format rather than RPM - ask, and I'll research it. In principle, RPM packages that work should not be broken by my packages nor v.v.. Most RPMs put their key files in /opt/freeware/* while I use either /opt/* or /opt/aixtools/*

Michael

[Michael]

Re: Installp - I downloaded everything from here:

https://www.ibm.com/developerworks/aix/library/aix-toolbox/alpha.html

From the FAQ linked to on that page: 

Is that FAQ outdated?  Should we be undoing what we did, and redo using installp instead?  How exactly would that work with RPM packages?

Thanks.

No problem. You can try my packaging - no charge. Same "service" level - aka "ASIS".

[Michael]

I just realized that I was pinging the wrong forum for RPM-built issues.

My apologies for the confusion.

I was never confused.

And, now a few days later - being curious, would you please say whether you got as quick a response from them as you got from me?

And, is your problem solved? (aka, what are you actually trying to get installed. If it is cloud-init I do have an installp for taht as well!)

[Teej]

They were somewhat helpful.

We are attempting to get a number of Python modules installed on AIX (on Power) as we have them on Linux (on x86/x64).  Some of those modules include SciPy.  Unfortunately, even with the efforts we took, I am still getting a "no lapack/blas resources found" error, despite installing their R package which includes that.

One of the major cause of the issue is having OpenSSL RPM package installed, which we should not be doing, apparently.

This is part of an internal project, so I can't really share much further on this forum.  However, for this particular issue, it is resolved as is noted here:

https://www.ibm.com/developerworks/community/forums/html/topic?id=d6b6ef3a-3f4b-49eb-b052-88b5efde2164&ps=25

Thanks.

[Michael]

Did you verify that the R package has both 32-bit and 64-bit libraries (assuming that is what is missing).

It has been a long while since I tried to package R. 32-bit went okay, but 64-bit continued to fail - around issues of compressing libraries (I forget which one, gz or xz from memory). 32-bit just had too little memory for the task envisioned - even after using LDR_CNTRL to maximize MAXDATA to 2.5 GByte (0xa0000000).

Maybe I need to look at R again. Keeps coming up indirectly.

[Teej]

Unfortunately, the R package utilizes Lapack/BLAS in a custom format, and does not include cBLAS, which SciPy requires.  Right now I shifted focus to trying to get OpenBLAS working on AIX, as I believe a native GCC build for that would be far more compatible than what is provided by the R package.

Thank you for asking.

[Michael]

Thx for the update.

Curious - why use gcc for compiler (as that is not 'native' compiler for AIX)? More specifically, why not use xlc - which the runt-time environment AIX provides and updates continually.

[Teej]

The vast majority of packages that we are depending on for Python are highly dependent on GCC for compilation and installation.  I just completed an installation of 180+ Python modules, with most of it source code being compiled on AIX.

Before we switched to GCC, we had a constant issue of updating the make file to be compatible with AIX's make; updating C files to be compatible with xlC, and so on forth.  With the switch to GCC, we only encountered 3 individual issues, all with tickets opened to the respective developers to improve compatibility.

We just simply do not have the time to figure everything out on AIX using xlC.

[Michael]

Thx for the update. Sad to read about it though.

I have run into similar issues - where OSS developers considered themselves portable, by definition, because they use gcc. I suppose it is a way to define portable, but not the way I was "taught" over 30 years ago.

From experience I know relying on gcc on AIX creates new issues, but smaller than you are facing atm. And issues that will never go away because noone bothers to confront people about the non-existent port-ability of certain blocks of code (usually there are ifdef's et al in the code for windows, but not for "UNIX"/"POSIX").

Glad you have been/are successful with your goals!