Re: rpmio not compiling
On Aug 10, 2011, at 6:56 AM, Anders F Björklund wrote: Jeff Johnson: 6. Configure RPM: - # ./configure --prefix=/usr --libdir=/usr/lib64 --with-uuid=/usr/lib64 --with-xar=/usr/lib64 \ --enable-rpm-lua-extensions-based-on-rpmlib --enable-fast-install --enable-shared \ --enable-rpmvercmp-digits-beat-alpha --with-expat=/usr/lib64 --with-neon=/usr/lib64 \ Hmmm … I did not know there is a --enable-rpmvercmp-digits-beat-alpha or a --enable-rpm-lua-extensions-based-on-rpmlib option. I'm not at all sure what they are supposed to do or who added (its likely from RSE and OpenPKG several years back). It's sure to be some pretty arcane functionality ... Actually it's quite new... http://rpm5.org/cvs/chngview?cn=15680 optional-dirname-and-symlink-deps http://rpm5.org/cvs/chngview?cn=15735 rpm-lua-extensions-based-on-rpm-lib-functionality http://rpm5.org/cvs/chngview?cn=16017 old-comparision-behaviour It came from splitting vendor configuration into autotools configuration: https://blueprints.launchpad.net/rpm/+spec/rpm-split-vendor-config-in-autofu Actual config is the same. Not sure it's a good idea. Could you be a bit more specific about what isn't a good idea? Per-vendor configuration: an excuse to not work through the best solution. Its always based on a Not time, we know what we are doing … mind-set. I don't mind the divergence if we did not include me doing support and development. AutoFu: I've always believed that compiled in options need to become run-time options. The problem with compiled in options is the assumption that you can re-compile. That is often not the case any more. And its not as simple as adding a macro somewhere when there are deep semantic changes like version comparison, or removing colors and not attaching dependencies to files etc: configuration should be about file paths, or verbosity levels, and other UI issues, not fundamental changes to RPM. But somehow per-vendor configuration needs to be merged/dropped imho: blaming RPM (and me) for bugs and lack of support on code that isn't well used/tested, and where vendor support isn't an actuality, is, well, not such a good idea. 73 de Jeff __ RPM Package Managerhttp://rpm5.org User Communication List rpm-users@rpm5.org
Re: rpmio not compiling
On Aug 8, 2011, at 10:43 AM, Belal Salem wrote: Hi all, compiling the source for any rpm-5.x version doesn't success, I encounter the following error: rpmaug.c:650: error: 'POPT_ARG_MAINCALL' undeclared here (not in a function) POPT_ARG_MAINCALL is in popt-1.14 and later. Upgrade your version of popt. 73 de Jeff __ RPM Package Managerhttp://rpm5.org User Communication List rpm-users@rpm5.org
Re: rpmio not compiling
On Aug 8, 2011, at 11:37 AM, Belal Salem wrote: Great! Updating to popt-1.14 works. Now,rpmaug.c with POPT_ARG_MAINCALL has passed correctly, but I encounter the same error type different place: rpmzq.c:179: error: 'POPT_ARGFLAG_TOGGLE' undeclared here (not in a function) Are there any other packages that needs updating in addition to popt? All depends on how what build options you choose for rpm: RPM is *NOT* a build that you can just do ./configure --prefix=/usr and hope for the best. There's simply too many build options to even attempt the needed QA coverage explicitly. The prerequisites for RPM are in INSTALL where it says: POPTmandatory 1.151.16http://rpm5.org/files/popt/ INSTALL is maintained accurately for the most common build options, certainly the MANDATORY ones. There's also an internal popt distributed with rpm for most of the last year. hth 73 de Jeff __ RPM Package Managerhttp://rpm5.org User Communication List rpm-users@rpm5.org
Re: rpmio not compiling
On Aug 8, 2011, at 12:39 PM, Belal Salem wrote: Yes! The repository you give to me is a good place to compare the versions I have and to upgrade what needs upgrading. Thanks for your time. NP. If you catch some annoyance, its not personal: I maintain both RPM5 and POPT and yours isn't the first report of build failures. The problem isn't simple: RPM uses POPT in easy that no other program does. E.g.POPT_ARGFLAG_TOGGLE adds the ability to set/clear a set of flags from CLI options with both --thisoption --nothisoption Since RPM is chock full of disablers (like --nodeps etc) which are attempting to use POPT_ARGFLAG_TOGGLE in reasonable ways, well, the inability to upgrade POPT by distros in 3-4 years is, well, a tad bit disturbing. POPT is *NOT* a hard upgrade, nowhere near as complicated as upgrading RPM has become. Anyways holler at me (and ignore my mutterings) if you need help. I'll try to get you fixed up no matter what … (aside to Robert Xu): Getting there just buried … 73 de Jeff __ RPM Package Managerhttp://rpm5.org User Communication List rpm-users@rpm5.org
Re: rpmio not compiling
On Aug 9, 2011, at 12:54 AM, Belal Salem wrote: Thanks for the detailed explanation. So, here after I satisfied all the prerequisites, when compiling the RPM source, I encounter the following compilation errors: In file included from dbconfig.c:14: ./rpmdb.h:433: error: expected specifier-qualifier-list before 'DB_SEQUENCE' ./rpmdb.h:490: error: expected specifier-qualifier-list before 'DB_LOGC' ./rpmdb.h: In function 'dbiCopen': ./rpmdb.h:589: error: 'struct _dbiIndex' has no member named 'dbi_vec' ./rpmdb.h: In function 'dbiCclose': . . what do you think that is?! This is the same problem that is being reported multiple times. In order to do a release -- using --with-db=external as everyone wishes -- rpm has #include db51/db.h hardwired in the code. What everyone wishes is that rpm Just Works with whatever Berkeley DB happens to be installed *for all possible distros and versions*. The simplest fix is to build/install db-5.1.25 externally. The portable (in the sense you will have to edit to taste, the basic build is fine) that I used is available here cvs -d :pserver:anonym...@rpm5.org:/v/rpm/cvs get distro/db51 Add the official release of db-5.1.25 from Oracle, and the ancient db.1.85 tar ball, and build/install the db51 packages. 73 de Jeff __ RPM Package Managerhttp://rpm5.org User Communication List rpm-users@rpm5.org
Re: rpmio not compiling
DONE IT !!! [SOLVED] I passed out all the errors the last one was resolved by using db-5.1.19 instead of db-5.2.x Here is a quick reference on how I did it, may be some one stuck into it like me: Compiling and Installation: ___ === 1. Configure TCL: - # ./configure --prefix=/usr --libdir=/usr/lib64 --enable-shared --enable-threads --enable-64bit \ --enable-static 2. Configure the db-5.1.19: --- # cd build_unix # ../dist/configure --prefix=/usr --libdir=/usr/lib64 --enable-tcl --enable-shared --enable-sql \ --enable-dbm --with-tcl=/usr/lib64 # make # make install # cp db.h dbsql.h /usr/include/db51/ 3. Configure ncurses: - # ./configure --prefix=/usr --libdir=/usr/lib64 --with-shared --with-static --with-libtool 4. Configure expat: --- # ./configure --prefix=/usr --libdir=/usr/lib64 --with-shared --with-static 5. Configure the rest of the 3d-parties as follows: --- * Configure all of them as follows: #./configure --prefix=/usr --libdir=/usr/lib64 # make # make install Note: Some of them doesn't use a 'configure' script, so they don't have an option line to install libs to /usr/lib64, so, after installing them, do a symlink from them to /usr/lib64 6. Configure RPM: - # ./configure --prefix=/usr --libdir=/usr/lib64 --with-uuid=/usr/lib64 --with-xar=/usr/lib64 \ --enable-rpm-lua-extensions-based-on-rpmlib --enable-fast-install --enable-shared \ --enable-rpmvercmp-digits-beat-alpha --with-expat=/usr/lib64 --with-neon=/usr/lib64 \ --with-tcl=/usr/lib64 # make # make install # rpm --rebuilddb On Tue, 09 Aug 2011 00:54:30 -0400, Belal Salem be...@nothing-real.com wrote: Thanks for the detailed explanation. So, here after I satisfied all the prerequisites, when compiling the RPM source, I encounter the following compilation errors: In file included from dbconfig.c:14: ./rpmdb.h:433: error: expected specifier-qualifier-list before 'DB_SEQUENCE' ./rpmdb.h:490: error: expected specifier-qualifier-list before 'DB_LOGC' ./rpmdb.h: In function 'dbiCopen': ./rpmdb.h:589: error: 'struct _dbiIndex' has no member named 'dbi_vec' ./rpmdb.h: In function 'dbiCclose': . . what do you think that is?! On Mon, 08 Aug 2011 15:36:34 -0400, Jeff Johnson n3...@mac.com wrote: On Aug 8, 2011, at 1:19 PM, Belal Salem wrote: Actually, what I'm trying to do is the following, may be you have an advice for me: I'm running RHEL-5, I found it the most stable and secure Distro that runs smoothly almost all the high-end simulation and 3D applications that I'm using intensively, the problem is that there are dozens of simple but important applications/utilities that requires higher versions of glibc and python, those that where supplied as rpm packages that requires newer versions of the RPM to be installed! Yes, you aren't alone here either: most enterprise distros have such a ;one supported life that they become irrelevant. I'm not sure that ether's any enterprise distro with a solid upgrade path. Dag's repository is likeliest best both reputation ally and in in reality. Check there first imho. So, I decided to build a custom system installation that satisfies all my needs. I manually forced upgrade glibc with a version that gives 2.6 and 2.7 without breaking the system dependencies, and I compiled python-2.7.2, and now my system runs really great! and I can run those new applications smoothly. Upgrading REHL5 to python-2.7.2 is non-trivial: congratulations on success. The only one thing that I'm suffering from is that I have to manually extract and install them since they require higher signature of fileDegist, payload and rpm compressing... for that I decided to upgrade to RPM-5 to be able to install them regularly using the RPM Packager. Yes: distros have chosen to use SHA-256 file digests without bothering to release a compatible version of rpm. There is a way to disable file digests using --nofdigests (I've forgotten the older option, it has been 6 years or so: --nomd5sums? something like that). Sadly that *still* isn't enough because of the XZ! XZ! XZ! craziness. So there's often nothing one can do except extract the payload rpm2cpio.sh foo*.rpm | cpio -dim (there's a shell script that permits inserting a unxz where needed). There are back ports of XZ and SHA256 file digests to whatever RPM is in RHEL5 if needed: I can dig out the necessary patches if GOOG cannot find something that Just Works. Any advices about that! are there an easy way to let the RPM source compile both of the i686 and x86_64 bit. All depends on what is considered easy. FYI: rpm-4.4.7 (on which @rpm5.org is
