Re: Making rpm5 work with dnf

[Jeffrey Johnson]

> On Nov 24, 2016, at 8:50 AM, Alexander Kanavin 
> <alexander.kana...@linux.intel.com> wrote:
> 
> On 11/22/2016 06:10 PM, Jeffrey Johnson wrote:
> 
>> Again: I cannot do much more than suggest porting approaches unless I can 
>> attempt reproducers.
>> Please try to expose your git repositories somehow, either publicly or 
>> privately.
> 
> Here it is:
> 
> https://github.com/kanavin/libhif/commits/master
> 

Good. I will take a look at your libhif efforts. Note that libhif is only
one of several repositories that are going to be needed.

FWIW, your invitation expired or is otherwise unusable (but at least
I can read your code, todo++).

(aside)
Before we go too much further here:

What is the intent of this collaboration?

You have chosen to fork libhif from
rpm-software-management/libhif 
<https://github.com/rpm-software-management/libhif>
rather than a fork (of a fork) from
https://github.com/rpm5/libhif

That forces our coordination to be pulled from the only common
root at
rpm-software-management/libhif 
<https://github.com/rpm-software-management/libhif>
which almost certainly precludes any participation from me and rpm5.org
for various reasons.

Note that there are several other efforts attempting a dnf->…->rpm5 tool chain 
that I
am aware of. Which is why I attempted RPM5 repositories to permit 
collaboration, and
am perfectly willing to give write access to anyone who wishes.

I am also perfectly willing to let someone other than rpm5.org administrate the 
mess if that
is what is desired. I do encourage all of you to collaborate early and work 
forward from
working tools. There’s a fair amount of subtle work that will be needed imho.

What is your intent: collaboration with rpm5.org or collaboration with 
rpm-software-management?

> I've fixed what I could by adding rpm5 includes, but the remaining build 
> issues are all caused by actual API incompatibilities between 4 and 5. I can 
> file them as separate github issues if you want.
> 

Um rpm5.org and rpm.org have different API’s, and are most definitely different
implementations these days. Its not just include files, and more than libhif is 
going to
be needed to build a working dnf->…->rpm5 tool chain.

I’ll take a look at your libhif this weekend.

73 de Jeff
> Alex
> 
> __
> RPM Package Managerhttp://rpm5.org
> User Communication List rpm-users@rpm5.org

Re: Making rpm5 work with dnf

[Jeffrey Johnson]

> On Nov 22, 2016, at 11:20 AM, Alexander Kanavin 
> <alexander.kana...@linux.intel.com> wrote:
> 
> On 11/22/2016 06:10 PM, Jeffrey Johnson wrote:
> 
>> Again: I cannot do much more than suggest porting approaches unless I can 
>> attempt reproducers.
>> Please try to expose your git repositories somehow, either publicly or 
>> privately.
> 
> I'll push those to somewhere public after running the unit tests and fixing 
> any resulting trivial issues.
> 

I suggest we start trying to work from the same repositories:

https://github.com/rpm5

and use github forks/issues rather than e-mnail to coordinate efforts.

73 de Jeff__
RPM Package Managerhttp://rpm5.org
User Communication List rpm-users@rpm5.org

Re: Making rpm5 work with dnf

[Jeffrey Johnson]

> On Nov 22, 2016, at 10:39 AM, Alexander Kanavin 
>  wrote:
> 
> On 11/22/2016 05:16 PM, Alexander Kanavin wrote:
>> AttributeError: 'module' object has no attribute 'RPMTRANS_FLAG_NOCONTEXTS'
> 
> There's a similar issue with RPMTRANS_FLAG_NOFILEDIGEST. If I patch these out 
> from dnf, then dnf is at least able to start - I haven't run any of its unit 
> tests yet.
> 

Both NOFILEDIGEST and NOCONTEXTS are disablers unnecessary to dnf execution,
with alternative means to enable/disable other than through python bindings.

Note that the RPM5 SELinux implementation does not include or permit loadable 
modules.
A SELinux port is much more than exposing a NOCONTEXTS bit. NOFILEDIGEST also 
has
a slightly different  effect between rpm.org and rpm5.org.

Disabling SELinux is still common functionality however: setting 
NOCONTEXTS/NOFILEDIGEST to 0
is one way to achieve.

The fundamental porting problem (in both python modules) is how symbols are 
exposed.

The better way going forward is to set global values in __init__.py as needed.

Again: I cannot do much more than suggest porting approaches unless I can 
attempt reproducers.
Please try to expose your git repositories somehow, either publicly or 
privately.

73 de Jeff
> Alex
> 
> __
> RPM Package Managerhttp://rpm5.org
> User Communication List rpm-users@rpm5.org

__
RPM Package Managerhttp://rpm5.org
User Communication List rpm-users@rpm5.org

Re: Rpm5 will switch to python3 ?

[Jeffrey Johnson]

> On Nov 15, 2016, at 7:23 AM, Alexander Kanavin 
>  wrote:
> 
>> 
>> Which of those packages is of interest to you?
>> 
>> Offhand, I don’t see any important applications there that MUST have
>> rpm-python3.
> 
> The usage case is that Yocto Project is replacing smartpm with dnf.
> 
> Dnf can (still) be configured to use Python 2, but we strongly prefer to use 
> Python 3 from the beginning.
> 

The first step is still to get DNF “working” with RPM5 using python2: there are 
multiple ports involved.

If you expose you git repositories, I can try to help.

I have already forked all the relevant repositories and done some of the 
necessary porting
back in August:

https://github.com/orgs/rpm5/dashboard

Meanwhile, rpm-python3 is just a small piece of a much larger puzzle.

Until DNF is ported to use rpm5 (with test cases and coverage), rpm—python3 is
a NICETOHAVE answer in search of a question.

Functioning DNF with RPM5 is MUST’VE.

73 de Jeff

__
RPM Package Managerhttp://rpm5.org
User Communication List rpm-users@rpm5.org

Re: Rpm5 will switch to python3 ?

[Jeffrey Johnson]

> On Nov 14, 2016, at 10:32 AM, Alexander Kanavin 
>  wrote:
> 
>> rpm-python was converted to python3 (and generally blue-printed against
>> the rpm.org python module) at least 1 year ago afaik.
>> 
>> Meanwhile, no one has tried to compile/use rpm-python with python3. 
>> There’s surely some bugs.
>> 
>> hth
>> 
>> 73 de Jeff
> 
> I have tried this just now, and unfortunately I am getting compile errors 
> when trying to build against Python 3 (this is an excerpt, the whole thing is 
> longer):
> 
> | ../../rpm-5.4.15/python/rpmfts-py.c: In function ‘rpmfts_debug’:
> | ../../rpm-5.4.15/python/rpmfts-py.c:79:57: error: ‘rpmftsObject {aka struct 
> rpmftsObject_s}’ has no member named ‘ob_refcnt’
> |   fprintf(stderr, " %u %d ftsp %p fts %p\n", (unsigned) s->ob_refcnt, 
> s->active, s->ftsp, s->fts);
> |  ^~
> | ../../rpm-5.4.15/python/rpmfts-py.c: At top level:
> | ../../rpm-5.4.15/python/rpmfts-py.c:504:3: error: ‘cmpfunc’ undeclared here 
> (not in a function)
> |   (cmpfunc)0,   /* tp_compare */
> |^~~
> | ../../rpm-5.4.15/python/rpmfts-py.c:504:11: error: expected ‘}’ before 
> numeric constant
> |   (cmpfunc)0,   /* tp_compare */
> |^
> | ../../rpm-5.4.15/python/rpmdebug-py.c: In function ‘lbl’:
> | ../../rpm-5.4.15/python/rpmdebug-py.c:38:24: error: ‘PyBuffer_Type’ 
> undeclared (first use in this function)
> |  if (o->ob_type == _Type) return "Buffer";
> | ^
> | ../../rpm-5.4.15/python/rpmdebug-py.c:38:24: note: each undeclared 
> identifier is reported only once for each function it appears in
> | ../../rpm-5.4.15/python/rpmdebug-py.c:40:24: error: ‘PyCObject_Type’ 
> undeclared (first use in this function)
> |  if (o->ob_type == _Type) return "CObject";
> | ^~
> | ../../rpm-5.4.15/python/rpmdebug-py.c:42:24: error: ‘PyClass_Type’ 
> undeclared (first use in this function)
> |  if (o->ob_type == _Type) return "Class";
> | ^~~~
> | ../../rpm-5.4.15/python/rpmmodule.c:460:13: error: ‘PyTypeObject {aka 
> struct _typeobject}’ has no member named ‘ob_type’; did you mean ‘ob_base’?
> |  hdr_Type.ob_type = _Type;
> |  ^
> 

You were warned:

>> Meanwhile, no one has tried to compile/use rpm-python with python3. 
>> There’s surely some bugs.

Meanwhile — in order to finish rpm-python3 — there needs to be some usage case.

On a random Fedora 24 installation, I see the following packages using 
rpm-python3:

$ rpm -q --whatrequires rpm-python3
rpmconf-1.0.16-2.fc24.noarch
python3-dnf-1.1.10-1.fc24.noarch
rpmlint-1.9-3.fc24.noarch
setroubleshoot-server-3.3.11-1.fc24.x86_64
mock-1.2.21-1.fc24.noarch

Which of those packages is of interest to you?

Offhand, I don’t see any important applications there that MUST have 
rpm-python3.

73 de Jeff

Re: Rpm5 will switch to python3 ?

[Jeffrey Johnson]

> On Sep 21, 2016, at 5:23 AM, Fan Xin  wrote:
> 
> Hi
> 
> I am a Yotco Project user and rpm5 is used in Yocto Project.
> As I known, now rpm5 is dependent on python 2.x.
> 
> I want to know that whether the rpm5 community has a plan to switch to Python 
> 3.x .
> 

rpm-python was converted to python3 (and generally blue-printed against
the rpm.org python module) at least 1 year ago afaik.

Meanwhile, no one has tried to compile/use rpm-python with python3. There’s 
surely some bugs.

hth

73 de Jeff

__
RPM Package Managerhttp://rpm5.org
User Communication List rpm-users@rpm5.org

Re: RPM sqlite3 support

[Jeffrey Johnson]

> On Jan 12, 2016, at 6:39 PM, Tim Mooney <tim.moo...@ndsu.edu> wrote:
> 
> In regard to: Re: RPM sqlite3 support, Jeffrey Johnson said (at 4:40pm on...:
> 
>>> With Oracle's license change on BDB 6.x (or 12.x, or whatever they're
>>> calling it) to AGPL, does that impact rpm5's long-term use of BDB?
>>> 
>> 
>> No impact for the project, but there’s always users who want/need different.
>> 
>> BDB been doing the job for RPM (and many many other projects) since forever.
>> There’s little engineering reason to change.
> 
> Agreed, but then outside factors override a lot of technology design
> decisions in software design, for better or worse.
> 
> My main reason for asking relates to the fact that a lot of other projects
> have abandoned BDB, again likely not for engineering reasons.  I can
> envision a day when the "cool kids" look at software that relies on BDB
> and, not understanding the history, decide to write their own "better"
> alternative that uses the cool database of the current time.  If I hear
> anyone say MongoDB, I will almost certainly commit some type of crime.
> 

(aside)
You do realize that RPM5 has the mongo-c-driver embedded inside, batteries 
included,
for the past 5 years?

Seriously: most rpm users have nearly identical configurations and the
days where each and every client PC need their own speshul copy
of changelogs and descriptions and identical blobs of header metadata
are clearly numbered.

Note that rpm5 has also embedded sqlite (i.e so that sql updates can be
distributed through %post, and so that multiple copies of installed software
metadata in schema-du-jour can be used as one wishes).

*shrug* My job is to make implementations exist, not honk my warez. 

> The other concern is obviously the additional maintenance burden of having
> to also maintain the 5.x BDB codebase.  That base is pretty mature, so
> there shouldn't be a lot of need for fixes or security patches, but
> maintaining that will eventually become unpalatable.
> 

BDB has done an excellent job maintaining a consistent backward compatible API:
there is nothing whatsoever wrong with BDB 5.x as used by RPM.

Bundle BDB into RPM if you don’t want the added package monkey task maintaining
older versions of BDB as a package, license and batteries included.

73 de Jeff


> Tim
> -- 
> Tim Mooney tim.moo...@ndsu.edu
> Enterprise Computing & Infrastructure  701-231-1076 (Voice)
> Room 242-J6, Quentin Burdick Building  701-231-8541 (Fax)
> North Dakota State University, Fargo, ND 58105-5164

__
RPM Package Managerhttp://rpm5.org
User Communication List rpm-users@rpm5.org

Re: RPM sqlite3 support

[Jeffrey Johnson]

> On Jan 12, 2016, at 11:25 AM, Jate Sujjavanich  wrote:
> 
> I am using rpm 5.4.9 as my package manager on an embedded system, and I am 
> running into some bottlenecks with the Berkeley database. I am using an SD 
> Card as my root file system.
> 
> The rpm transactions from a kernel upgrade take an hour or so. Using the 
> --stats option, I found that rpm was spending 15 or so seconds total per 
> package in dbadd, dbget, etc. An strace revealed that many fsyncdata calls 
> were happening. It appears this is due to ACID-ity of transactions.
> 

Yes: fsync is especially costly on an SD card, and is measurably  slower
on other media as well. ACID doesn’t come for free.

A performance fix is usually to stub out sync (and all its variants) in the
vectors used by Berkeley DB to make OS calls when opening the
dbenv.

> I found some posts saying that sqlite could be used as the database backend, 
> so I tried this. I tried using configure to activate sqlite without success.
> 

Those posts were from years ago: transactional support was added in ~2010.

> I can compile with sqlite support, but so far, I can't get RPM to create any 
> sqlite files. I've tried database conversion, initializing an empty RPM 
> database, and setting _dbapi to 4 in /usr/lib/rpm/macros.
> 

There are significant changes for transactional support that have not been 
implemented
in the rpm sqlite3 code.

> I discovered that within configure.ac , DBAPI is hard 
> coded to 3 (Berkeley DB).
> 

Yes.

> I would like to know if sqlite3 as a backend is supported by RPM these days 
> in 5.4.9 or any other versions. I want to find out if some of the patches 
> within yocto/poky are breaking sqlite support.
> 

The sqlite3 code (and support) in rpm5 was abandoned in favor of
Berkeley DB ACID transactional support quite some years ago

I don’t know what patches are in poky/yocto specifically, but it should not
be too hard to find patches related to database functionality.

Try filing a bug report with poky/yocto, which will likely trigger a support 
request to me.

The performance on an SD card rather than the choice of backend database is
the issue in need of fixing.

hth

73 de Jeff


> Jate
> 

Re: RPM sqlite3 support

[Jeffrey Johnson]

> On Jan 12, 2016, at 3:06 PM, Tim Mooney <tim.moo...@ndsu.edu> wrote:
> 
> In regard to: Re: RPM sqlite3 support, Jeffrey Johnson said (at 12:46pm on...:
> 
>> The sqlite3 code (and support) in rpm5 was abandoned in favor of
>> Berkeley DB ACID transactional support quite some years ago
> 
> I've been meaning to ask about this for a while, and this provides a
> good segue...
> 
> With Oracle's license change on BDB 6.x (or 12.x, or whatever they're
> calling it) to AGPL, does that impact rpm5's long-term use of BDB?
> 

No impact for the project, but there’s always users who want/need different.

BDB been doing the job for RPM (and many many other projects) since forever.
There’s little engineering reason to change.

(aside since its sure to be mentioned)
MDB could be adapted to RPM. The usage cases for OpenLDAP and RPM
are rather different, where OpenLDAP is a “lightweight” well defined schema 
server,
while rpm saves a header blob under an index with secondary lookup.

The sqlite code wasn’t very difficult and could be resurrected. The problem 
is/was one of design:
the sqlite3 code mimicked the BDB vectors with a primitive schema. What users 
are
expecting with SQL is a much richer schema. There was a very clever 
implementation
done at carb.org years ago that built schema du jour indices by internalizing 
rpm —query
in postgres and rebuilding tables as needed. The usage case there was web 
queries,
which are a very different application than doing install/remove (which are 
essentially just bulk
upgrades)

From an engineering POV, remapping the Packages store to a heap, possibly 
remote, or
possibly into an offset in the original package, might be useful if secondary 
lookup is
continued.

The next step to alternative Package stores would be to switch the package 
index from uint32_t
to 128 buts and use a UUID instead.

hah

73 de Jeff


> Tim
> -- 
> Tim Mooney tim.moo...@ndsu.edu
> Enterprise Computing & Infrastructure  701-231-1076 (Voice)
> Room 242-J6, Quentin Burdick Building  701-231-8541 (Fax)
> North Dakota State University, Fargo, ND 58105-5164
> __
> RPM Package Managerhttp://rpm5.org
> User Communication List rpm-users@rpm5.org

__
RPM Package Managerhttp://rpm5.org
User Communication List rpm-users@rpm5.org

Re: rpm fatal error on osx el capitan

[Jeffrey Johnson]

> On Sep 24, 2015, at 9:40 AM, Jacques Knipper  
> wrote:
> 
> 
> When we tried to install any rpm with "sudo rpm -ivh ...", the command crash 
> with an error "error: db3cput:db3.c:1461: dbcursor->put(-30973): BDB0087 
> DB_RUNRECOVERY: Fatal error, run database recovery”.
This is the on;y trpotyrd retort msg.

Unfortunately, the problem in need of solving happened on the previous rpm
invocation, not this invocation.

Note that rpm-5.4.15 already automates the fixup necessary for “… run database 
recovery.”
so there is something else systematically (i.e. like configuration) that 
prevented the
automatic mixup from succeeding.

hth

73 de Jeff

Re: rpm fatal error on osx el capitan

[Jeffrey Johnson]

>> 
>> When we tried to install any rpm with "sudo rpm -ivh ...", the command crash 
>> with an error "error: db3cput:db3.c:1461: dbcursor->put(-30973): BDB0087 
>> DB_RUNRECOVERY: Fatal error, run database recovery”.
> This is the on;y trpotyrd retort msg.

This is the only reported error msg.

> 
> Unfortunately, the problem in need of solving happened on the previous rpm
> invocation, not this invocation.
> 
> Note that rpm-5.4.15 already automates the fixup necessary for “… run 
> database recovery.”
> so there is something else systematically (i.e. like configuration) that 
> prevented the
> automatic mixup from succeeding.
> 
> hth
> 
> 73 de Jeff

Re: rpm fatal error on osx el capitan

[Jeffrey Johnson]

> On Sep 30, 2015, at 4:32 PM, Anders F Björklund  wrote:
> 
> Jacques Knipper wrote:
> 
>> Indeed I'm talking about v5.4.15.
>> I didn't try with the --rpmdbdebug yet but I will, thanks.
>> The problem happen with every rpm.
>> I am able to rebuild our rpms with the rpmbuild, but I cannot install them, 
>> an I think it's because of an issue with Berkeley DB.
> 
> FWIW, the issue was reproducible on Mavericks too. You need to install 
> something to see it, though...
> 
> So the default test case a) looks a bit broken and b) doesn't actually test 
> installing and erasing ?
> 
> %_topdir  #{testpath}/var/lib/rpm
> 
> I think it is something with the (lack of) configuration, that is getting the 
> rpmdb in a sad state.
> 

Hmmm … I’d likely concur lack of configuration (and that rpmdb is overly 
complex).

Meanwhile:

Is this a segfault or an assertion failure using rpm?

I haven’t seen the exact error message ….

If the problem is a segfault, then there may be an assertion missing someplace.

And if some assertion exit is common (which is likely the case imho)
to an out-of-box misconfigured experience, perhaps an exit by invoking an
opaque script to display a per-platform tuned message might assist.

Of course the opaque script generation through AutoFu may just introduce
Yet Mode Configuration failures, sigh.

Is the problem a segfault or an assertion failure?

73 de Jeff
> --anders__
> RPM Package Managerhttp://rpm5.org
> User Communication List rpm-users@rpm5.org

__
RPM Package Managerhttp://rpm5.org
User Communication List rpm-users@rpm5.org

Re: MD5 BAD Expected : extended by two extra zeros

[Jeffrey Johnson]

> On Sep 23, 2015, at 1:55 PM, Divya Vyas  wrote:
> 
> 
> Hi,
> 
> root@host:~# gpg --list-keys
> gpg: /home/root/.gnupg/trustdb.gpg: trustdb created
> 
> root@host:~#  rpm -q gpg-pubkey --qf '%{name}-%{version}-%{release} --> 
> %{summary}\n'
> package gpg-pubkey is not installed
> 
> I dont have the keys installed on my host. Why rpm command is saying 
> 
> root@host:~# rpm -K -v pth-2.0.7-r3.1.x86_64.rpm
> pth-2.0.7-r3.1.x86_64.rpm:
> Header V4 RSA/SHA1 signature: OK, key ID 8b5cccb3
> Header SHA1 digest: OK (c326a31810f026daac89aa4fd7928c3b574671ea)
> MD5 digest: BAD Expected(bdaefdc3ddfd1c4ab4fabdd48c117fb800) != 
> (bdaefdc3ddfd1c4ab4fabdd48c117fb8)
> 
> I am signing my rpms ( rpm --addsign) on target with key id 8b5cccb3 and 
> copying to host. How md5 appended to extended zeros.
> 
> @target
> 
> rpm -K -v pth-2.0.7-r3.1.x86_64.rpm
> pth-2.0.7-r3.1.x86_64.rpm:
> Header V4 RSA/SHA1 Signature, key ID 8b5cccb3: OK
> Header SHA1 digest: OK (
> c326a31810f026daac89aa4fd7928c3b574671ea)
> V4 RSA/SHA1 Signature, key ID 8b5cccb3: OK
> MD5 digest: OK (bdaefdc3ddfd1c4ab4fabdd48c117fb8)
> 
> Target is rpm 4.9 and host is rpm 5.4
> 
> Why two extra zeros 
> 

(as described privately)

There was a subtle alignment/padding problem that manifested itself
with the size of the MD5 header+payload digest ending up as 17 bytes
with additional signature tags added to the signature header.

Fixed ~1.5y ago in rpm-5.4.15.

73 de Jeff__
RPM Package Managerhttp://rpm5.org
User Communication List rpm-users@rpm5.org

Re: rpm did not remove previous version

[Jeffrey Johnson]

Did you type "rpm -Uvh ..." 
or "rpm -ivh ..."?

In almost all circumstances (kernels being the major exception), "rpm -Uvh ... 
" should be used.

hth

73 de Jeff

Sent from my iPhone

> On Sep 10, 2015, at 5:35 PM, Matt Hall  wrote:
> 
> 
> We had a bit of a mis-naming snafu that we’re trying to sort out how to fix. 
> 
> First rpm was 
> 
> Name: rpmone
> Version: 1.1.branchname-352
> Release: 1
> 
> We later fixed the versioning, because it caused issues / was not upgrading 
> when a new version was installed. 
> 
> Second rpm was
> 
> Name: rpmone
> Version: 1.2.branchname
> Release: 381
> 
> The second one increments the Release field at build time. The first one was 
> incrememting the Version field. 
> 
> When we install the second one, it installs, but does not remove the first 
> one. 
> So now we’re left with systems that have two rpms of the same name, but 
> different version/releases.
> 
> Is there anything we can do in the creation/install of the 1.2 rpm to clear 
> out or remove any 1.1? We tried Obsoletes,
> but that seems to be mainly for rpm name changes, not this version/release 
> issue we have. 
> 
> These were built/installed on CentOS 5.8, with rpm version 4.4.2.3
> 
> Any pointers or docs to look at would be helpful or google keywords to search 
> on, 
> 
> Thanks, 
> 
> 
> 
> 
> 
> 
> 
> This email and any attachments may contain confidential and privileged 
> material for the sole use of the intended recipient. Any review, copying, or 
> distribution of this email (or any attachments) by others is prohibited. If 
> you are not the intended recipient, please contact the sender immediately and 
> permanently delete this email and any attachments. No employee or agent of 
> TiVo Inc. is authorized to conclude any binding agreement on behalf of TiVo 
> Inc. by email. Binding agreements with TiVo Inc. may only be made by a signed 
> written agreement.

Re: Need information on RPM signing

[Jeffrey Johnson]

 On Apr 14, 2015, at 4:07 AM, srinivasan j v srinivasanj...@gmail.com wrote:
 
 Hello All
 I need to sign RPM using X509 Certificate and save the signatures (signature 
 file ) along with the RPM package .
 
1. Is there any way  can i do that ?
2. How can i save the these signature and any other certificates (X 
 509)  and  being not part of  CPIO archive ?
 

I have answered this before, but here are the answers again.

The easiest approach is to sign the entire *.rpm package using openssl/nss or
other X.509 tool.

Then prepend or append the X.509 signature (and any other certs you wish to 
include)
to the existing *.rpm package.

You will need to write your own sign/verify scripts using existing tools to
create/extract the prepended/appended signature (and certificates) and
sign/verify the original *.rpm file.

You can do the same operation on just the cpio payload instead of the entire
*.rpm package if you wish by using rpm2cpio (or rpm2cpio.sh) to extract the
just the cpio payload of the *.rpm package.

If you wish RPM itself to support X.509 formatted signatures/certificates, 
there are
two choices:
1) convert existing GPG signature/pubkeys used in *.rpm to X.509 format 
that
can be used by tools like openssl/nss outside of rpm.
2) implement X.509 directly in RPM.

The conversion of GPG signatures/pubkeys has been done: e.g. see pgp.com 
http://pgp.com/
implementations.

Direct support for X.509 signatures is a month (or so) of effort to implement
and test using system(3) invocations of existing tools in openssl/nss. External
tool invocations add an unacceptable (to many, including me) and complex 
dependency on
existing crypto toolkits: rpm is expected to Just Work installing in chroot’s 
and
on empty disks.

A direct implementation in RPM to parse X.509 certificates and validate 
certificate
chains to (at least partially) remove the crypto toolkit dependency is 
considerably
more complex.

Meanwhile you have been asking for signed cpio payloads in the past. The easy
approach outlined above, using existing tools like openssl/rpm2cpio to write
a 2 scripts for signing/verifying the cpio payload outside of rpm is by far the
easiest approach.

hth

73 de Jeff

 Thanks in advance
 
 regards
 srinivasan

Re: Need information on RPM signing

[Jeffrey Johnson]

 On Apr 14, 2015, at 12:37 PM, srinivasan j v srinivasanj...@gmail.com wrote:
 
 Hi Jeffrey
 Thanks for the information. It was really helpful
 I'm planning to go with the first approach (Signing Entire *.rpm  Package and 
 prepending the signature to rpm).
 
 Yes , I will sign and verify  CPIO payload outside of RPM .
 
 Is there any way that i can prepend/append  information to Built RPM file ? 
 Thanks in advance
 

I’m just suggesting using cat(1) to merge 2 files. There are magic numbers
for the rpm headers that can be used to find the end of the 
signature/certificates
while parsing.

I’d duggest prepending so that a package can be handled in a single pass
(but that may not be as useful in scripting as it is in rpm itself: a package
can be read and installed in a single “streaming” pass because the signature
is prepended rather than appended).

hth

73 de Jeff
 regards
 srinivasan
 
 regards
 srini
 
 On Tue, Apr 14, 2015 at 8:47 PM, Jeffrey Johnson n3...@me.com 
 mailto:n3...@me.com wrote:
 
 On Apr 14, 2015, at 4:07 AM, srinivasan j v srinivasanj...@gmail.com 
 mailto:srinivasanj...@gmail.com wrote:
 
 Hello All
 I need to sign RPM using X509 Certificate and save the signatures (signature 
 file ) along with the RPM package .
 
1. Is there any way  can i do that ?
2. How can i save the these signature and any other certificates (X 
 509)  and  being not part of  CPIO archive ?
 
 
 I have answered this before, but here are the answers again.
 
 The easiest approach is to sign the entire *.rpm package using openssl/nss or
 other X.509 tool.
 
 Then prepend or append the X.509 signature (and any other certs you wish to 
 include)
 to the existing *.rpm package.
 
 You will need to write your own sign/verify scripts using existing tools to
 create/extract the prepended/appended signature (and certificates) and
 sign/verify the original *.rpm file.
 
 You can do the same operation on just the cpio payload instead of the entire
 *.rpm package if you wish by using rpm2cpio (or rpm2cpio.sh) to extract the
 just the cpio payload of the *.rpm package.
 
 If you wish RPM itself to support X.509 formatted signatures/certificates, 
 there are
 two choices:
   1) convert existing GPG signature/pubkeys used in *.rpm to X.509 format 
 that
   can be used by tools like openssl/nss outside of rpm.
   2) implement X.509 directly in RPM.
 
 The conversion of GPG signatures/pubkeys has been done: e.g. see pgp.com 
 http://pgp.com/
 implementations.
 
 Direct support for X.509 signatures is a month (or so) of effort to implement
 and test using system(3) invocations of existing tools in openssl/nss. 
 External
 tool invocations add an unacceptable (to many, including me) and complex 
 dependency on
 existing crypto toolkits: rpm is expected to Just Work installing in chroot’s 
 and
 on empty disks.
 
 A direct implementation in RPM to parse X.509 certificates and validate 
 certificate
 chains to (at least partially) remove the crypto toolkit dependency is 
 considerably
 more complex.
 
 Meanwhile you have been asking for signed cpio payloads in the past. The easy
 approach outlined above, using existing tools like openssl/rpm2cpio to write
 a 2 scripts for signing/verifying the cpio payload outside of rpm is by far 
 the
 easiest approach.
 
 hth
 
 73 de Jeff
 
 Thanks in advance
 
 regards
 srinivasan
 
 

Re: Embed signatures in rpm (RPM tags)

[Jeffrey Johnson]

On Mar 10, 2015, at 2:15 AM, srinivasan j v wrote:

 hello all
 
 I'm supposed to you use X509 format for signing .
 
 I'm trying to sign the  CPIO archive of a rpm  . I need to package this 
 signature inside the RPM. I can't add this part of CPIO archive as the 
 generated signature varies from the signature of newly formed CPIO archive .
 

The easiest way to do this is with a detached (or concatenated) X509 signature 
outside of RPM.

  I Tried adding the signature to the Signature tags in the Spec file (for 
 testing purpose) but it did not work , Do i need to use any arbitary tag for 
 this ?
 

Note that signing the CPIO payload has never been done by rpm, and that the
header+payload signing/verification was deprecated in 2007 and is not generated
by current RPM5, and that X509 format has never been supported by RPM.

Much more than a Signature: tag is needed.

 Is there any way that i keep these signatures as part of RPM but not as part 
 of its CPIO archive  ?
 

You can attempt rewriting the *.rpm and adding whatever you wish as additional 
tag content
in the signature header.

I'd again suggest that signing the entire *.rpm package, including the cpio 
payload, and prepending
the signature to the *.rpm, and then writing the verification and public key 
retrieval tool as the best
way to achieve your goal of X509 format for signing.

73 de Jeff
 thanks in advance
 
 regards
 srinivasan

__
RPM Package Managerhttp://rpm5.org
User Communication List rpm-users@rpm5.org

Re: RPM support for x509 format

[Jeffrey Johnson]

 On Feb 2, 2015, at 6:51 AM, srinivasan j v srinivasanj...@gmail.com wrote:
 
 Hello all,
 
 Does RPM supports x509 format ?
 

Short answer: No.

All depends on what is meant by “support”.

RPM crypto is/was based on BeeCrypt which has no dependency on format.
(These days NSS/OpenSSL/libgcyrpt/libtomcrypt are also used algorithmically
with no dependence on format, either OpenPGP/C509).

There is a parser for OpenPGP format that extracts parameters from
pubkeys and signatures, can calculate a fingerprint given OpenPGP
public key packets, and can handle base64 armor with cry checks.

Equivalently functional parser/fingerprint/armor  would be needed for
X509 certificates and signatures.

The harder problems have to do with verifying pubkey certification signatures
and revocations and keyservers and CA certs and other associated semantics.

The underlying signature algorithms are of course identical.

 RPM has signatures in PGP format, is there any conversion utilities available 
 between X509 and PGP formats ?
 

Inter-converting OpenPGP - X509 signatures is non-trivial because
of differences of how the pubkey fingerprint (in the signature) is
defined. There isn’t a one-to-one mapping of the data items within
the differing pubkey formats, and so fingerprints (which are digests on 
plaintext)
cannot be trivially interconverted.

The monkeysphere project likely has some certificate interconversion utilities 
too.

There have been attempts to do X509 - OpenPGP conversions
on pubkeys/privkeys. E.g. PGP (but not gnupg) can do the conversions
since 2005. So one could redefine the macro that invokes an external
helper to use PGP and achieve some semblance of “support” (caveat: untested).

However these days RPM generates a non-repudiable signature
on every package in every build using 5 different libraries. The
format happens to be OpenPGP, but the non-repudiable signature
need not be imported/exported/configured outside of RPM itself.

The better approach to using X509 (and also OpenPGP) tools
external to RPM would be generating/verifying a certification signature
on the non-repudiable pubkey/signature material that RPM generates,
rather than implementing X509 parallel to OpenPGP throughout RPM.

JMHO, YMMV.

73 de Jeff__
RPM Package Managerhttp://rpm5.org
User Communication List rpm-users@rpm5.org

Re: Can't install RPM because I get an error with system.h

[Jeffrey Johnson]

 On Aug 23, 2014, at 9:25 AM, andrejfa...@ml1.net wrote:
 
 This software: http://www.astromatic.net/software/sextractor
 

The RPM package is for linux, not OS X.

You may be able to build from source on OS X.

Otherwise you may be able to  use parallels or vmfusion
to run linux on OS X, and then install the rpm within the
linux virtual machine.

 
 the installation directions said to use rpm (the easy way).
 
 well it didn't work, so I've been trying to install rpm so that I could
 do what the directions told me to do.
 
 Why do you say not to use rpm on a Mac?
 

I didn’t say not to use rpm on a mac.

 Also I had issues with Homebrew because it broke my gcc compiler and I
 had to re-install the Xcode command line tools.
 

Sorry to hear.

 
 But it doesn't matter. I just want to know why I'm getting that error
 message.
 

RPM has many prerequisites: the error message indicates
something is missing.

73 de Jeff

 
 - Original message -
 From: Jeffrey Johnson n3...@me.com
 To: rpm-users@rpm5.org
 Subject: Re: Can't install RPM because I get an error with system.h
 Date: Fri, 22 Aug 2014 10:18:00 -0500
 
 
 On Aug 20, 2014, at 8:32 AM, andrejfa...@ml1.net wrote:
 
 GREETINGS AGAIN.
 
 It has now been one month and I have not yet received a response to my
 inquiry on why the directions to install rpm don't work.
 
 
 What software are you trying to install?
 
 Almost certainly (if on Mac Os X), you should be using
 MacPorts or HomeBrew to install software, not rpm.
 
 73 de Jeff
 
 Can someone help me?
 
 
 - Original message -
 From: andrejfa...@ml1.net
 To: rpm-users@rpm5.org
 Subject: Can't install RPM because I get an error with system.h
 Date: Sat, 19 Jul 2014 22:44:48 -0400
 
 Greetings.
 I am in the long process of learning how to install software using UNIX
 so that I can use a particular program. I am running Mac OS X 10.9.4. I
 know almost nothing about UNIX and have just been following directions.
 
 I am in the process of installing the RPM package manager. However, I am
 having trouble getting the software to work.
 
 In the installation directions, I am able to get through the
 ./autogen.sh and ./configure commands fine, with the appropriate flags.
 However, when I run make, I receive the following error messages:
 
 In file included from fts.c:64:0:
 ../system.h:123:3: error: expected identifier or '(' before '{' token
  { if ((__progname = strrchr(pn, '/')) != NULL) __progname++;^
 make[2]: *** [fts.lo] Error 1
 make[1]: *** [all-recursive] Error 1
 make: *** [all] Error 2
 
 
 What's going on?
 __
 RPM Package Managerhttp://rpm5.org
 User Communication List rpm-users@rpm5.org
 __
 RPM Package Managerhttp://rpm5.org
 User Communication List rpm-users@rpm5.org
 
 __
 RPM Package Managerhttp://rpm5.org
 User Communication List rpm-users@rpm5.org
 __
 RPM Package Managerhttp://rpm5.org
 User Communication List rpm-users@rpm5.org

__
RPM Package Managerhttp://rpm5.org
User Communication List rpm-users@rpm5.org

Re: Can't install RPM because I get an error with system.h

[Jeffrey Johnson]

 On Aug 20, 2014, at 8:32 AM, andrejfa...@ml1.net wrote:
 
 GREETINGS AGAIN.
 
 It has now been one month and I have not yet received a response to my
 inquiry on why the directions to install rpm don't work.
 

What software are you trying to install?

Almost certainly (if on Mac Os X), you should be using
MacPorts or HomeBrew to install software, not rpm.

73 de Jeff

 Can someone help me?
 
 
 - Original message -
 From: andrejfa...@ml1.net
 To: rpm-users@rpm5.org
 Subject: Can't install RPM because I get an error with system.h
 Date: Sat, 19 Jul 2014 22:44:48 -0400
 
 Greetings.
 I am in the long process of learning how to install software using UNIX
 so that I can use a particular program. I am running Mac OS X 10.9.4. I
 know almost nothing about UNIX and have just been following directions.
 
 I am in the process of installing the RPM package manager. However, I am
 having trouble getting the software to work.
 
 In the installation directions, I am able to get through the
 ./autogen.sh and ./configure commands fine, with the appropriate flags.
 However, when I run make, I receive the following error messages:
 
 In file included from fts.c:64:0:
 ../system.h:123:3: error: expected identifier or '(' before '{' token
   { if ((__progname = strrchr(pn, '/')) != NULL) __progname++;^
 make[2]: *** [fts.lo] Error 1
 make[1]: *** [all-recursive] Error 1
 make: *** [all] Error 2
 
 
 What's going on?
 __
 RPM Package Managerhttp://rpm5.org
 User Communication List rpm-users@rpm5.org
 __
 RPM Package Managerhttp://rpm5.org
 User Communication List rpm-users@rpm5.org

__
RPM Package Managerhttp://rpm5.org
User Communication List rpm-users@rpm5.org

Re: RPMTAG_FILENAMES tag still needed

[Jeffrey Johnson]

On Jan 30, 2014, at 10:54 AM, Mark Hatle wrote:

 On 1/30/14, 7:41 AM, Apparao Urla (aurla) wrote:
 Hi,
 
 I am implementing one API to get the list of files using RPMTAG_FILENAMES.
 
 I found that  RPMTAG_FILENAMES is removed in 5.1.9.
 
 Please correct me if I am wrong,
 
 there is no other option to to get the list of files in a rpm rather than
 parsing the directories(RPMTAG_DIRNAMES) ,
 
 dir indexes(DIRINDEXES) and basenames(BASENAMES) tags.
 
 That is the correct way to do it.  The FILENAMES has been deprecated for 
 years, and was finally removed.
 

Technically RPMTAG_FILENAMES hasn't been a tag, but rather a header tag 
extension
all this century.

The only way to complete the transition fromn tag to extension is to eliminate 
RPMTAG_FILENAMES,
which behaves in at least 3 different ways in various versions of rpm.

Accessing RPMTAG_{DIRNAMES,BASENAMES,INDICES} is one way to
attempt portability: there are other approaches coding access in
different ways that can be done as well.

 I've got something I put together back in about 2002 that might help you 
 visualize the structures:
 
 http://gate.crashing.org/~fray/rpm/rpm-xml-desc.jpg
 

Meanwhile the current headerGet() can access both tags and extensions 
transparently.

The replacement extension (iirc, all this was done years ago) is 
RPMTAG_FILELISTS.

73 de Jeff

__
RPM Package Managerhttp://rpm5.org
User Communication List rpm-users@rpm5.org

Re: functionality opposite to --excludepath

[Jeffrey Johnson]

On Jan 21, 2014, at 2:21 AM, Rajul Bhavsar rajulbhav...@gmail.com wrote:

 Hi,
 
 Does rpm5 provides selective installation of files that begins with a certain 
 path?
 e.g. I want to install files beginning with /usr/lib. I am not able to find 
 option for this functionality.
 

RPM doesn’t provide —include path because the goal is to manage
packages, not files.

Easiest way to extract some files is likely to use cpio(1) options.

E.g.
rpm2cpio somepackage.rpm | cpio -dim
will extract all files.

hth

73 de Jeff
 I am aware of --excludepath but the list can become huge in future. 
 
 Thanks,
 Rajul

__
RPM Package Managerhttp://rpm5.org
User Communication List rpm-users@rpm5.org

Re: hard-linked files handling by rpm

[Jeffrey Johnson]

On Jan 21, 2014, at 3:03 AM, Rajul Bhavsar rajulbhav...@gmail.com wrote:

 Hi,
 
 In my build root directory, I have created a file (say temp.txt) and then I 
 created a hard-link to it (say temp1.txt). After this, I created rpm out of 
 build root directory. On installing this rpm I see that i-node numbers of 
 both files are same; that means rpm is aware of this hard-link and creating 
 the same on rpm installation. 
 
 But, I am not able to understand how rpm has treated this hard-link with a 
 .rpm file.
 For example, I have a file with 5k size. On duplicating it, rpm size 
 increased by ~2.5k but with hard-link it increased by 1.9k. What is this 
 1.9k? Is this totally a metadata about hard-link or something else?
 
 Please help me in understanding this hard-link handling.
 

The size change is likely in the cpio payload in a *.rpm package because
rpm doesn’t track hard links directly, uses the inode info to infer hard links.

You can see all metadata with
rpm -qp —yaml  somepackage.rpm
There is also —xml if you prefer the eye-scratchy angle bracket syntax.

hth

73 de Jeff
 Thanks,
 Rajul 

__
RPM Package Managerhttp://rpm5.org
User Communication List rpm-users@rpm5.org

Re: functionality opposite to --excludepath

[Jeffrey Johnson]

On Jan 21, 2014, at 9:42 PM, Rajul Bhavsar rajulbhav...@gmail.com wrote:

 
 Easiest way to extract some files is likely to use cpio(1) options.
 
 E.g.
 rpm2cpio somepackage.rpm | cpio -dim
 will extract all files.
  Is this extraction can be specified as part of rpm installation? If it is 
  not then it will be of less use for current functionality we are looking 
  for, as we want to query rpmdb for various information about installed 
  packages. 

RPM is a package, not a file, manager.

The idea of “partial packages” using either —exclude or—include based
on prefixes (or *RE patterns) leads to complexities such as

Should the “partial package” specification be persistent?

Instead of asking for file management, split the files into sub-packages, and
install compete sub-packages instead of asking for “partial package” management.

Sure I understand your need.

Do you understand the difference between package and file management?

73 de Jeff

Re: hard-linked files handling by rpm

[Jeffrey Johnson]

On Jan 21, 2014, at 9:49 PM, Rajul Bhavsar rajulbhav...@gmail.com wrote:

 
 
 
 On Tue, Jan 21, 2014 at 10:23 PM, Jeffrey Johnson n3...@me.com wrote:
 
  If hard-links are treated as just another files (for inclusion in .rpm) 
  then why difference in size of payload - when same file is duplicated and 
  hard-linked?

Read about cpio headers: there needs to be some way to specify
what foe path to link to, a search across a file system for a specific
inode is quite performance intensive, so the path to the file to be linked
to is included in the cpio payload.

  
 You can see all metadata with
 rpm -qp —yaml  somepackage.rpm
 There is also —xml if you prefer the eye-scratchy angle bracket syntax.
 

Or compare the metadata with and without the hardline using —yaml. All the
metadata is displayed with —yaml.

You asked to understand why the *.rpm package was larger. One (or both)
of the above answers should provide an answer to you.

73 de Jeff

Re: Information on patch available on rpm5

[Jeffrey Johnson]

On Jan 3, 2014, at 8:38 AM, bishwajit goswami wrote:

 Hi,
 
 I was checking on a few rpm patches available.
 I found patch as below:
 -#define  PLD_CHROOT
   -#ifdef PLD_CHROOT
   -   if (rpmdb-db_chrootDone)
   -   xx = dbenv-set_data_dir(dbenv, dbhome);
   -#endif
   rpmdb-db_opens++;
 
 I was not able to figure out the context for which this patch was required.

The PLD_CHROOT patch was added more than 6y ago:
http://rpm5.org/community/rpm-cvs/1536.html

It was likely blindly added just in case before releasing rpm-5.0 (iirc):
PLD patches are usually correct.

Meanwhile there are *lots* of changes in RPM (and Berkeley DB) since that patch 
was added,
I'm not sure any context related to PLD_CHROOT is meaningful.


 Could someone let me know the issue which needed this patch.

You seem to be looking for explanations for why an rpmdb is being accessed
outside of a chroot (as you reported earlier).

However, solaris and a rather old rpm-5.1.x make it difficult to diagnose
from the info you have provided.

73 de Jeff
 
 Thanks and Regards,
 Bishwajit

__
RPM Package Managerhttp://rpm5.org
User Communication List rpm-users@rpm5.org

Re: rpmdb not updated with installed packages

[Jeffrey Johnson]

On Dec 12, 2013, at 12:34 PM, bishwajit goswami wrote:

 Hi,
 
 I have a partition up and running with a set of RPMs. Now I want to prepare a 
 backup partition with the same set of rpms. The installation goes through 
 properly and the corresponding files are available on the alternate partition.
 The problem comes when querying the rpmdb of the created partition. The rpmdb 
 do not seem to be updated with all the packages which were installed. A 
 sample snapshot is below:
 [sysadmin-vm:0_RP0:/mnt/rpm/calvados]$ rpm -ivh --nodeps --root /partprep 
 ncs6k-sysadmin-boot.*
 Preparing...##
 ncs6k-sysadmin-boot.sc  ##
 ncs6k-sysadmin-boot.all ##
 ncs6k-sysadmin-boot.lc  ##
 ncs6k-sysadmin-boot.rp  ##
 [sysadmin-vm:0_RP0:/mnt/rpm/calvados]$ rpm -qa --root /partprep
 ncs6k-sysadmin-boot.rp-5.2.0.01I-Default.x86_64
 ncs6k-sysadmin-boot.lc-5.2.0.01I-Default.x86_64
 [sysadmin-vm:0_RP0:/mnt/rpm/calvados]$
 
 When I check the double verbose output, I simply see that a few packages got 
 remove from addition to corresponding rpmdb files.
 D: removing ncs6k-sysadmin-boot.sc from Name index.
 D: removing 19 entries from Basenames index.
 D: removing 
 Calvados/ncs6k-sysadmin-boot/ncs6k-sysadmin/sc/Default/mandatory/PII
 
 Any suggestion would be helpful in this regard. If needed, I could attach the 
 verbose output.
 Also, the rpmdb do not seem to be corrupt since rpm verification runs 
 smoothly.
 

If you actually used -i (rather than -U), then rpm should _NOT_ have
removed anything.

The likeliest explanation is that there is an Obsoletes: in some package
that is causing a package to be removed.

Examine the -vv output ... everything that rpm does is logged in -vv output
(but there isn't enough information to guess the cause from what you provided).

73 de Jeff

 
 -- 
 Bishwajit Goswami
 

Re: RPM C API

[Jeffrey Johnson]

On Oct 22, 2013, at 6:48 AM, Shardul Thaker (sthaker) wrote:

 Hello RPM Community,
  
 I am looking for list of C api’s, definition and implementation reference, 
 for RPM version 5.1.9.
  
 I tried to search for wiki/ref guide etc. but couldn’t find.
  
 Can you please help?
  

rpm uses doxygen to document the API.

Build rpm-5.1.9 including the doxygen generated documentation.

hth

73 de Jeff
 Thanks,
 Shardul Thaker
  
  

Re: rpm spec: clearing Prefix: to create a non-relocatable subpackage (of a relocatable package)?

[Jeffrey Johnson]

On Oct 7, 2013, at 8:02 AM, Andreas Luik wrote:

 Hello,
  
   I'm trying to create a non-relocatable subpackage from a spec file, where 
 the
 main package is relocatable, i.e. has a Prefix: tag.  It is possible to use 
 Prefix:
 for subpackages, e.g. to use a different value as for the main package, but I
 have not been able to clear the main package's prefix setting.  Using the 
 following
 spec file:
  
 
 Name: xxx
 Version: 1.0
 ...
 Prefix: /usr/local
 %description
 test
  
 %package sub
 Summary: subpackage
 Prefix:
 %description sub
 subpackage test
 ...
  
  
 (Prefix: without a value) generates the error message
  
 error: line xx: Empty tag: Prefix:
  
 Thanks in advance for any suggestions.
  
 

The real problem here is in the assumed goal of create a non-relocatable 
subpackage.

Every path in every package can be relocated by --relocate /old/path=/newpath. 
The
only restriction is that only full directory/file paths, not partial paths, can 
be relocated.
E.g. given a path like /A/B/C/abc, one cannot relocate with a file prefix (or 
pattern) like
--relocate /A/B/C/a=/somewhere/else

The only current usage for a Prefix: (and multiple Prefix:'s or Prefixes: are 
permitted) is
to automatically disable a warning/error message that can be overridden by 
another option.

If you want to use Prefix:, then specify all relocations in all subpackages. 
The behavior
for a non-relocateable subpackage will always depend on what options were used
to install that package, and there is no way (nor should there be: only the 
end-user,
not the builder, can determine what paths are useful/needed in general) to 
prevent
--relocate from being used with appropriate overrides.

Note that the modestly serious design flaw with relocateable paths in *.rpm 
packages is that
the relocations are not remembered persistently. So if you decide to relocate 
some
path, then you also need to add --relocate on every future install.

The other flaw is that relocations are per-transaction (or CLI invocation), not 
per-package.
This means that if you have two packages with an identical path which you want 
to
relocate in one package but not the other, then the 2 package installations 
MUST be
in in different transactions and installed separately.

hth

73 de Jeff

 Kind regards,
 -- 
 i. A. Andreas Luik
 in - innovative navigation GmbH
 phone: +49 7154 807171
 fax: +49 7154 807154
 email: andreas.l...@innovative-navigation.de
 
 in - innovative navigation GmbH, Leibnizstrasse 11, D-70806 Kornwestheim
 Geschäftsführer/Managing Directors:
 Dr. Thomas Gern, Dr. Martin Sandler, Dr. Reinhard Zimmermann, Uwe Vögele
 Handelsregister: Stuttgart HRB 205770
 
 in - innovative navigation GmbH is ISO 9001:2008 certified. 

Re: cpiobin macro

[Jeffrey Johnson]

On Mar 5, 2013, at 12:01 AM, ark ph wrote:

 Is this what defines the format of the archive that rpm will use? Can I set
 the path with option to cpio, e.g. from
  http://www.gnu.org/software/cpio/manual/cpio.html if I use cpio --format=tar
  the maximum size of archive can be 8589934591 bytes? For creating a very 
 large
  rpm, cpio limits the size of the archive, would this solve the issue?

Actually its these two macros that set the payload format:

#   Archive formats to use for source/binary package payloads.
#   cpio  cpio archive (default)
#   ustar tar archive
#
#%_source_payload_formatcpio
#%_binary_payload_formatcpio

I'm not at all sure what the cpiobin macro is or does: its not in @rpm5.org 
sources.

Meanwhile its unlikely that you could/would be able to fix a cpio 
file/payload limit problem by
changing a macro or the payload format in any version of rpm.

 
 [I m building a large package, size is large primarily due to large numpy 
 array
  object, and get cpio:bad magic error; as of now cannot
  deploy it as service hence package it with rpm; any suggestions on best
 approach?]


The best approach is to rethink how you wish to distribute large archives: there
are many performance issues downloading/uncompressing a single _HUGE_
archive; you are often better off by spitting into smaller packages, 
particularly
if some of the content changes less often the rest (and one would only have
to distribute the delta change rather than *everything*).

73 de Jeff

Re: Which distros are using rpm5

[Jeffrey Johnson]

On Jan 15, 2013, at 12:58 PM, Sriram Narayanan wrote:

 I've wanted to use rpm5 for belenix, but the other devs want to consider 
 pacman feeling that it's lighter.
 
 

Hmmm ... rpm5 isn't exactly heavy, just maximally featured: the fundamental 
basics
are still quite lean-and-mean.

If you can itemize the details of (not) lighter, I'm quite sure
I can beat the crap out of (wrto any performance metrics, and
even memory size tunables) any other package manager on the planet.

Assuming a fair engineering bake-off however: most complaints are all anecdotal
and opinionated, often irrelevant and surreal, these days.
 I use rpm5 on my Dev boxes, and it's working fine for me.
 
 

Good.

73 de Jeff

Re: Requires/Provides issue with re-packaging a complex product (endeca)

[Jeffrey Johnson]

On Jan 6, 2013, at 12:52 PM, Mykel Alvis wrote:

 Just to clarify, this package is NOT for public consumption.  The software is 
 distributed via installer, to be run by humans.  Since we're doing automation 
 using puppet, an RPM of the code reduces the complexity of the installation 
 substantially and generates a repeatably installable artifact into an 
 existing artifact repository (RH Satellite, in this case).
 

Most linux distros are development dog food aimed at enthusiasts.
Whether one wishes to call that piublic is a matter of taste and de facto.

 There actually IS a reason to believe that the ELF data can is, while not 
 wrong, producing undesirable output.  The problem isn't that the dependencies 
 aren't correct.  It's that the package itself supplies those dependencies 
 internally and very specifically doesn't want to external system to interfere 
 with its deployment of the shared libraries.
 

There is no reason that you have pointed out to suspect that ELF data is wrong.

There are reasosn to suspect that you aren't adding -Wl,soname,YOUR_SONAME_HERE
when building and I asked whether the libraries had DT_SONAME (and give you the 
readelf
command to verify.

 The package builds very well without turning off the internal dependency 
 generator.  The issue arises when I try to install it and rpm looks at it's 
 huge list of requirements and notes that apparently not all of them are 
 satisfied internally or it would rather I use the packages that it purports 
 work best.  The problem is that they ARE supplied internally and that rpm, 
 during the packaging step, didn't understand that.  I'm not terrible at 
 writing spec files, at least for private consumption, but this seems like it 
 might be something that the rpm developers didn't expect to have to handle as 
 often as I seem to.
 

THe buils is entirely in the eye of the beholder. RPM extracts info from ELF 
files:
if the build doesn't put the correct data into the ELF header, you can blame 
RPM
all you wish, but its the buikld that needs to be fixed.

 The quantity of software that I've had to install using the various 
 shell/executable installer systems is growing, not shrinking.  I attribute 
 this to laziness on the part of the distributor/developer.  They don't take 
 the time to ensure compatibility with various distributions.
 In all fairness, there are an awfully large number of distros to deal with 
 and many/most of them don't take wider-ranging compatibility into account, at 
 least not as a primary element, when getting their (frequently volunteer) 
 packagers to produce their native-level packaging.
 

Life's tough ... have a kleenex and my sympathies.

 Thus, in this case, this solution is (probably) the only viable one short of 
 writing more code to filter more packages, essentially by hand.  I can't have 
 compatibility with this package because if I stripped out all the perl 
 binaries and used the native perl executables, I might not get what I 
 expected.  Perl has a way of changing across versions and this is a pretty 
 complicated piece of code.  
 

You may supply whatever reasoning you wish for how you choose to solve your 
problem.

That won't solve my problem: supply reasonable support for unknown RPM 
problems.

 Because the developers saw fit to package a modified version of code that 
 exists generally in the wild (JDK, perl, probably something that I'm 
 missing), this entire piece of software can either be viewed as a black box 
 (install it all and let it sort itself out) or it would have to be 
 hand-engineered to extract all the pieces that are different and use those as 
 alternates to the ones supplied by standard OS packaging.  I don't have the 
 insight into the product to do the latter, so the former has to suffice.
 
 Thus, I package it like it was a Big Pile of Obfuscated Code(tm), and it 
 works like a champ.  Scripts inside the code modify library paths to point ot 
 specific versions of specific things and I get a running server.  Woot!
 

So Ship It!

 Do I think this is a good idea?  No. 
 Do I think that packaging frankenserver versions of perl and the JDK are good 
 ideas?  Definitely not.
 Do I think that software should be written towards wider compatibility with 
 existing packages?  Definitely yes.  
 Do most enterprise software developers seem to agree with me/us?  It doesn't 
 look that way.
 
 I'm actually speaking at a conference in a few weeks about this specific 
 issue (not the rpm problem, but the stop writing stuff that's hard to 
 deliver problem).
 

Good for you!

Now can you tell me whether your libraries have a DT_SONAME using
readelf -a /path/to/some/lib/libfoo*.so | grep SONAME
please?

73 de Jeff

__
RPM Package Managerhttp://rpm5.org
User Communication List rpm-users@rpm5.org

Re: Requires/Provides issue with re-packaging a complex product (endeca)

[Jeffrey Johnson]

On Jan 6, 2013, at 3:34 PM, Mykel Alvis wrote:

 
 I think it's OK to do this, but I'm going to do so directly to your personal 
 email so that I don't display piles of potentially litigious data in a public 
 forum.  
 

Please reply with readelf output publically: the output is not that large if you
grep out only the SONAME (i.e. the Provides:) and the NEEDED (i.e the
Requires:) for a couple of libraries and executables.

There are also specific options to display exactly DT_SONAME/DT_NEEDED
if you wish to read man readelf: I deliberately gave you the easier to 
understand
readelf -a ... | grep SONAME
as something that an average RPM packager faced with a similar problem using
Google search might find useful, comprehensible, and perhaps easier to 
remember. YMMV.

Most users with RPM problems now use Google search first, you included.

This leads to a preponderance of problem (but not solution) reports.

For something like RPM w 15y of serachable information, searching can and will 
find
just about every answer you want to hear, with many answers that 
implictly/contextually
appropriate and generally foolish. If one is smart enough, one can sometimes 
find the best
solution. But generally, the deluge of possibile answers and No time! 
precludes best
or even thoughtful.

Yes I respond to requests out of good will, formerly out of some misplaced 
sense of duty
and obligation to assist with information on software I wrote and happen to 
know quite well.

The specific parts of your problem that have only to do with RPM are the 
metadata in
*.rpm package headers. The parts of this problem that I cannot help directly 
with are
what the packages are used for, how the software is to be built, how to setup 
yum repositories,
and why yum on RHEL (more likely CentOS) is reporting a dependency failure. The
other issues are implicitly related to the (non-)existence of metadata, as well 
as coupled
into the root causes for your specific issue, and cannot be ignored (or solved 
by RPM).

73 de Jeff
__
RPM Package Managerhttp://rpm5.org
User Communication List rpm-users@rpm5.org

Re: Requires/Provides issue with re-packaging a complex product (endeca)

[Jeffrey Johnson]

On Jan 5, 2013, at 4:02 PM, Mykel Alvis wrote:

 
 devzero2000 over on the rpm-users list suggested
 %define _use_internal_dependency_generator 0
 
 
 This did exactly what I needed.
 
 

Yes but … there are profound changes to the *.rpm package
format that are coupled to setting %_use_internal_dependency_generator to 0.

That macro was _NEVER_ designed to be flipped around on a per-package basis
by package monkeys.

For starter, your package is not multilib ready (which will cause issues on 
path collisions,
particularly for ELF libraries), and is generally
The Wrong Fix

You also cannot use --filerequire to see which files generated which 
dependencies.

The better fix examines the dependencies and finds out why they
dependencies don't match.

There is no reason at all -- EIGHT YEARS LATER -- to believe that
the dependency extraction based on ELF data is incorrect. In gafact it
is both correct and well tested, just5 that packagers have lost whatever
knowledge about how to compile programs they might once have had
because of the insane complexity of GNU tools like autoconf/automake.

Hint: Run
readelf -a libfoo.so | grep SONAME
I'll bet your libraries do not have an soname. the string SONAME aka DT_SONAME
is mapped into a Provides, the NEEDED string aka DT_NEEDED is mapped into a 
Requires:.

Including a DT_SONAME in the library is now harder than passing a
singlr option to the linker like
-WL,so name,THIS_IS_MY_SONAME

73 de Jeff
 
 On Sat, Jan 5, 2013 at 12:26 PM, Jeffrey Johnson n3...@me.com wrote:
 
 On Jan 5, 2013, at 1:07 PM, Mykel Alvis mal...@restorationhardware.com 
 wrote:
 
 Responses inline below:
 
 
 On Sat, Jan 5, 2013 at 11:10 AM, Jeffrey Johnson n3...@me.com wrote:
 
 
 Second, you're right, I'm using rpm 4.8 from RHEL.  It's the only choice I 
 have.
   
 
 OK.
 
 FYI: there's not enough difference to worry about between @rpm.org - 
 @rpm5.org.
 
 The goals are more different than the code is: RHEL support is a deadly 
 sea-anchor
 to change. So @rpm5.org has more -- and more aggresive -- features.
 
 
 Unfortunately, enterprise customers generally have artificial requirements 
 that force them to use tools that have support.  Without RHEL, they almost 
 certainly would have gone Microsoft.
  
 
 (aside)
 If enterprise customers used microsoft instead of RHEL, they would have
 saved oodles of money: RHEL pricing is obscenely expensive. *shrug*
 
 Note that I've used M$ Windows for perhaps 3 months over 30 years of uglix: 
 just saying.
 
 Next, at least in my case, setting the -x flag doesn't change anything.  
 
 
 I have the following line in the %install section
 
 find $RPM_BUILD_ROOT -name \*.so\* -exec chmod -x {} \;
 
 prior to packaging, no shared libraries have the executable bit set.  I 
 think this is what you meant. 
 
 
 Best is to verify the end result that is actually in the *.rpm package.
 
 Using --xml is WYSIWYG for everything: there are also query formats for
 a tag displayed in octal that can be substituted (untested, from memory):
 
   rpm -qp --qf '[%{FILENAMES}: %{FILEMODES:oct}\n]' foo*.rpm
 
 As for the dependencies, you're correct in that there is no reason to 
 suspect that they aren't required.  The problem I'm experiencing is that 
 all the dependencies that are required are being supplied by the local 
 package, but RPM is generating external dependencies because it sees the 
 need for a Requires and isn't noticing that it was supplied as a Provides.
 
 
 Note that there may be a typo: note the extra '/' character within 
 parentheses:
 
 Error: Package: endeca-toolsandframeworks-3.1.1-1.el6.x86_64 
 (/endeca-toolsandframeworks-3.1.1-1.el6.x86_64)
Requires: endeca-mdex=6.4.0
 
 See if that is in the package requirements
  rpm -qp --requires endeca-toolsandframeworks-3.1.1-1.el6.x86_64.rpm
 
 That is interesting.  I'm building a multi-subpackage RPM, and endeca-mdex 
 is a requirement for endeca-toolsandframeworks.
 
 If a replacement, then you need a Provides: with the other name as well.
 
 Here is the relevant package section from my spec
 --- snip ---
 %package mdex
 Version:%{mdex_version}
 Group:  Servers/Indexing
 Summary:Endeca MDex %{version}
 %description mdex
 Endeca is an index engine
 This is the MDex portion
 
 %package presentationapi
 Version:%{mdex_version}
 Group:  Servers/Indexing
 Summary:Endeca MDex Presentation API %{version}
 Requires:   endeca-mdex=%{version}
 %description presentationapi
 Endeca is an index engine
 This is the Presentation API found in the MDex installer
 
 %package platformservices
 Version:%{pfs_version}
 Group:  Servers/Indexing
 Summary:Endeca PlatformServices %{version}
 Requires:   endeca-mdex=%{mdex_version}
 %description platformservices
 Endeca is an index engine
 This is the Platform Services
 
 %package toolsandframeworks
 Version:%{tfw_version}
 Group:  Servers

Re: determine package arch without/before building package?

[Jeffrey Johnson]

On Jul 11, 2012, at 12:13 PM, Tim Mooney wrote:

 
 Given a spec file foo.spec, is there a way use rpmbuild or rpm to
 determine what the package architecture will be without (or before)
 actually building the package?
 
 I know I could use sed or grep on the spec file looking for BuildArch,
 but I'm wondering if there's a way to essentially run the equivalent of
 a macro --eval query against a spec file.
 

The recommended way is this

./rpm -q --qf '%{arch}\n' --specsrpm rpm.spec
x86_64

Yes: SRPM's have a RPMTAG_ARCH associated.
And yes sed/grep/awk can all be used if the *.spec file isn't
all b00gered up with macro magic.

The functionality is kinda tweaky and backward because ultimately the
arch is determined by configuration and how rpm is invoked which
are all mostly known a priori (noarch being the important exception,
cross-building and multilib builds have never been directly supported
by rpmbuild itself meaningfully).

(aside)
It wouldn't be too hard to add some sugary automatic syntax to all of the above
to hide the gory details. All that stops the implementation is consensus on the 
option
(technically the popt alias) name to be used and supported.

I'm not going to hold my breath waiting for consensus to appear wrto rpmbuild 
however.

hth

73 de Jeff

__
RPM Package Managerhttp://rpm5.org
User Communication List rpm-users@rpm5.org

Re: determine package arch without/before building package?

[Jeffrey Johnson]

On Jul 11, 2012, at 4:54 PM, Tim Mooney wrote:

 In regard to: Re: determine package arch without/before building package?,...:
 
 Given a spec file foo.spec, is there a way use rpmbuild or rpm to
 determine what the package architecture will be without (or before)
 actually building the package?
 
 I know I could use sed or grep on the spec file looking for BuildArch,
 but I'm wondering if there's a way to essentially run the equivalent of
 a macro --eval query against a spec file.
 
 
 The recommended way is this
 
  ./rpm -q --qf '%{arch}\n' --specsrpm rpm.spec
  x86_64
 
 Thanks Jeff, that worked perfectly, at least with RPM 5.x.
 

Yes --specsrpm is unique to rpm5 (SRPM, not binary, headers are queried).

But also works with --specfile everywhere, just watch out for
1) you will get multiple replies, one for each binary subpkg (head -n 1 
solves instantly)
2) all modern rpm permits noarch subpkgs, older (like 3y old) legacy 
rpm does not.

73 de Jeff
__
RPM Package Managerhttp://rpm5.org
User Communication List rpm-users@rpm5.org

Re: uninstalling old RPM 5.1 from Mac

[Jeffrey Johnson]

On Apr 27, 2012, at 1:49 AM, Nicholas Chubrich nchubr...@gmail.com wrote:

 I have an old RPM 5.1 installation (most of it seems to be in /usr/local) 
 that I need to remove.  I believe it was installed using a DMG installer.  
 Can anyone suggest a way to cleanly and completely uninstall it?  
 
 Parts of it that I have been able to find so far are in /usr/local/lib, 
 /usr/bin/pkg-config, and /usr/local/src.  
 
 I need to uninstall it in order to do homebrew.
 

Every file installed through *.rpm packages can be seen with
rpm -qal
Redirect that output  to a file, examine, and remove file by file.

You can also remove package-by-package. The list of installed
packages is
rpm -qa
Again redirect that output to a file, examine, and remove package by package 
using
rpm -q PKG
for each PKG listed.

hth

73 de Jeff

__
RPM Package Managerhttp://rpm5.org
User Communication List rpm-users@rpm5.org

Re: uninstalling old RPM 5.1 from Mac

[Jeffrey Johnson]

On Apr 27, 2012, at 2:39 AM, Jeffrey Johnson n3...@me.com wrote:

 
 Again redirect that output to a file, examine, and remove package by package 
 using
   rpm -q PKG
--^^ -e or --erase of course: its 3am here.

 for each PKG listed.
 

73 de Jeff

__
RPM Package Managerhttp://rpm5.org
User Communication List rpm-users@rpm5.org

Re: uninstalling old RPM 5.1 from Mac

[Jeffrey Johnson]

On Apr 27, 2012, at 2:46 AM, Nicholas Chubrich nchubr...@gmail.com wrote:

 Jeff---
 
 Thanks!  I tried this but my installation (which has been through three 
 different laptops and three Mac OS upgrades) is pretty broken:
 
 rpm -qal 
 -- error: cannot open Packages(0) index using db3 - No such file or 
 directory (2)
  error: cannot open Packages database in /var/local/lib/rpm
 

Then you likely only need to remove rpm.

I haven't any idea what --prefix was passed into rpm
or where this version comes from.

But with --prefix=/usr, the main directories in use by rpm are
/usr/lib/rpm/
/var/lib/rpm/
Development directories/files with --prefix=/usr are
/usr/include/rpm/
/usr/lib/librpm*
Executables are
/bin/rpm
/usr/bin/rpm*
There's man pages and locales and python/perl modules which will have rpm in 
name like
find /usr/local -name '*rpm*'
which is likely a good information gathering starting point.

RPM (and likely nothing else) uses libbeecrypt.

hth

73 de Jeff
 at this point I'm not even sure if I actually installed any RPMs.  
 Regardless, I need to get rid of any such packages and RPM itself.
 
 On Thu, Apr 26, 2012 at 11:41 PM, Jeffrey Johnson n3...@me.com wrote:
 
 On Apr 27, 2012, at 2:39 AM, Jeffrey Johnson n3...@me.com wrote:
 
 
  Again redirect that output to a file, examine, and remove package by 
  package using
rpm -q PKG
 --^^ -e or --erase of course: its 3am here.
 
  for each PKG listed.
 
 
 73 de Jeff
 
 __
 RPM Package Managerhttp://rpm5.org
 User Communication List rpm-users@rpm5.org
 

Re: 5.4.8 release

[Jeffrey Johnson]

On Apr 4, 2012, at 4:34 PM, Henri Gomez wrote:

 No worries: I happen to have a fair number of Lion boxes
 doing nothing more than BOINC cobblestone accumulation atm.
 
 :-)
 
 I will create and maintain a builds lave for you as soon as you tell me what 
 build
 options you desire with RPM.
 
 The one we used :
 
 DB 5.3 as system
 RPM in static mode

The static linked native build with external db-5.3.15 is now in
the LION_for_henri waterfall at
http://harwicth.jbj.org:8010/waterfall

The same tweaks to achieve the build:

1) db-5.3.15 installed into /usr/{include,lib}/db53 and
cd /usr/lib
ln -s db53/* .

The better approach would be to specify include/library paths using
--with-db=/usr/lib/db53:/usr/include/db53
but its easier to create the symlinks then chase all possible 
installations
of Berkeley DB.


2) Latest AutoFu tools from MacPorts are used by symlinking into 
${HOME}/bin
and used for ./devtool static like this in devtool.conf:
...
%static
PATH=${HOME}/bin:/usr/bin:/bin:/usr/sbin:/sbin
export PATH
%autogen
%configure \
--verbose \
--prefix=/usr \
--disable-shared \
…

The better approach would be to upgrade
autoconf/automake/libtool/gettext
with --prefix=/usr instead of symlink'ing into MacProts /opt/local. 
Again
it is easier to create symlinks into ${HOME}/bin then to try to deal 
with the
consequences of the AutoFu upgrade.

hth

73 de Jeff

__
RPM Package Managerhttp://rpm5.org
User Communication List rpm-users@rpm5.org

Re: Requires/Provides

[Jeffrey Johnson]

On Apr 4, 2012, at 3:29 PM, Anders F Björklund wrote:

 
 A slight problem is that nobody is maintaining the python at rpm5.org.
 

Yet.

73 de Jeff

__
RPM Package Managerhttp://rpm5.org
User Communication List rpm-users@rpm5.org

Re: 5.4.8 release

[Jeffrey Johnson]

On Apr 4, 2012, at 4:07 PM, Henri Gomez wrote:

 
 Henri MBP is traveling often, not a good candidate as slave for a build farm 
 :)

No worries: I happen to have a fair number of Lion boxes
doing nothing more than BOINC cobblestone accumulation atm.

I will create and maintain a builds lave for you as soon as you tell me what 
build
options you desire with RPM.

73 de Jeff
__
RPM Package Managerhttp://rpm5.org
User Communication List rpm-users@rpm5.org

Re: rpm on OSX Lion

[Jeffrey Johnson]

On Mar 28, 2012, at 12:50 AM, Henri Gomez wrote:

 I removed everything in /usr/local and changed PATH to hide contents in 
 /opt/local 
 

Good.

 So question about pcre used with --with-pcre=Internal is still opened. 
 

I cannot diagnose your error until you add --miredebug.

There are 2 plausible causes:
1) you are using a macro in Version: in your maven.spec
2) you build with pcre isn't correct somehow.

Since rpm-5.4.7 runs fine on Lion (for me), and there are many
dialects in use for *.spec in Mandriva, I'm almost certain 2) is the
answer.

But I need to see --miredebug output in order to confirm.


 Otool reported a shared lib pcre in /usr/local/lib 
 

OK.

 Using Internal change pcre func name isnt'it ? 
 

Instead go guessing, I'd rather place friendly wagers.
What odds would you like on the testable hypothesis
The internally changed pcreposix name disambiguation isn't functional.

I can/will give you good odds (before you looksto see whether
pcre_regcomp is actually a defined symbol in librpmmisc.a ;-)

hth

73 de Jeff
'

__
RPM Package Managerhttp://rpm5.org
User Communication List rpm-users@rpm5.org

Re: rpm on OSX Lion

[Jeffrey Johnson]

On Mar 26, 2012, at 10:49 AM, Henri Gomez wrote:

 Hi to all,
 
 I success in building rpm 5.4.7 on OSX (from tarball)
 
 First step was to build and install bee crypt 4.2.1, popt 1.1.6,
 db-5.3.15, sqlite 3.7.11, pcre 8.30, zlib 1.2.6 libraries under
 /usr/local (nothing in)

Good. Careful about sqlite, its rather tricky. Preferred is
building/using the sqlite layer in Berkeley DB (which is
exactly sqlite with a Berkeley DB storage).

 
 For configure I forced dual arch :
 
 ./configure --prefix=/usr/local CC=/usr/bin/clang 'CFLAGS=-pipe -O2
 -arch x86_64' 'LDFLAGS=-L/usr/local/lib -arch x86_64'
 CPPFLAGS=-I/usr/local/include CXX=/usr/bin/clang++ 'CXXFLAGS=-pipe -O2
 -arch x86_64'
 
 For beecrypt, I disabled some options with :
 
 --disable-openmp --without-cplusplus --without-java --without-python
 

Yes OpenMP is problematic on Mac OS X because of LLVM != GCC.
You might want to look at --with-java: it was rather nice.

 rpm is only using system or prebuilt libraries :
 
 
 otool -L /usr/local/bin/rpm
 /usr/local/bin/rpm:
   /usr/local/lib/librpmbuild-5.4.dylib (compatibility version 0.0.0,
 current version 0.0.0)
   /usr/local/lib/librpm-5.4.dylib (compatibility version 0.0.0, current
 version 0.0.0)
   /usr/local/lib/librpmdb-5.4.dylib (compatibility version 0.0.0,
 current version 0.0.0)
   /usr/local/lib/librpmio-5.4.dylib (compatibility version 0.0.0,
 current version 0.0.0)
   /usr/local/lib/librpmmisc-5.4.dylib (compatibility version 0.0.0,
 current version 0.0.0)
   /usr/lib/libSystem.B.dylib (compatibility version 1.0.0, current
 version 159.1.0)
   /usr/local/lib/libpcreposix.0.dylib (compatibility version 1.0.0,
 current version 1.0.0)
   /usr/local/lib/libdb-5.3.dylib (compatibility version 0.0.0, current
 version 0.0.0)
   /usr/local/lib/libbeecrypt.7.dylib (compatibility version 8.0.0,
 current version 8.0.0)
   /usr/lib/libbz2.1.0.dylib (compatibility version 1.0.0, current version 
 1.0.5)
   /usr/local/lib/libz.1.dylib (compatibility version 1.0.0, current
 version 1.2.6)
   /usr/local/lib/libpopt.0.dylib (compatibility version 1.0.0, current
 version 1.0.0)
   /usr/lib/libiconv.2.dylib (compatibility version 7.0.0, current version 
 7.0.0)
   /usr/local/lib/libpcre.1.dylib (compatibility version 2.0.0, current
 version 2.0.0)
 

You likely should add neon to that mix.

 Question :
 
 What should I do now, I noticed a cpu-os-macros.tar.gz bundled in
 source RPM but not macros available for OSX inside.
 

The very first thing you should do is
cd tests
make -k clean test
and examine that output for serious flaws.

The cpu-os-macros.tar.gz is likely of little use on Mac OS X: what is
inside is the thundering herd of platforms that RPM used to attempt
to provide a default configuration for. There's too many dialects
from distro vendors for any one-size-fits-all default RPM configuration.

hth

73 de Jeff

 Cheers
 __
 RPM Package Managerhttp://rpm5.org
 User Communication List rpm-users@rpm5.org

__
RPM Package Managerhttp://rpm5.org
User Communication List rpm-users@rpm5.org

Re: rpm on OSX Lion

[Jeffrey Johnson]

On Mar 26, 2012, at 11:53 AM, Henri Gomez wrote:

 rpm-test-results


Quick drive-by browse:

--14: __gpg %{_bindir}/gpg2

That is used by make test to generate a pub key for testing.
That is these failures:
sh genpgp.sh  genpgp.h
genpgp.sh: line 15: gpg2: command not found
hint: You will see the %{_bindir} change to an actual path
if/when the executable is found in the usual places.

wget -nv http://rpm5.org/files/popt/popt-1.14-1.src.rpm
make: wget: No such file or directory

There is tools/wget that is good enuf (when I'm paying attention, not yet)
to replace system wget for simple downloads. But you need
--with-neon
first.

This error looks moderately serious (you can comment out the patterns
in macros/* if you must: but pattern matching looks fubar):
error: ^[A-Za-z0-9+._]+$: regexec failed: regexec() failed to match(1)

Because -lpcreposix and the system regexec(3) routines have
identical symbols, there's a high risk of collision. I've re-added
--with-pcre=internal
in order to avoid some issues on RHEL6.

Hint: If you add --miredebug to the command in the makefile you will
get pattern matching debugging sewage. This is generally true for
all 30-40 RPM objects: you will at least get a ctor/dtor message which
is often enough to get sufficient context to identify what is wrong. But
in this case, you likely have broken pattern matching in you build everywhere.

There's a fair number of tests that were not run because packages
failed to build. See the
http://harwich.jbj.org:8010
waterfall, look for the test: stage, to see what SHOULD be happening.

hth

73 de Jeff

Re: rpm on OSX Lion

[Jeffrey Johnson]

On Mar 26, 2012, at 12:31 PM, Henri Gomez wrote:

 Use noarch. What would be kinda spiffy is to automate lipo
 under RPM control and strip out the unused architectures
 in universal executables (and if one trusts the automated dependencies
 are accurate) the libraries.
 
 I've also been waiting (like 8 years now, sigh) to internalize MACH-O
 like ELF in RPM. Using helper scripts like find-requires/find-provides
 is fine of now, but an implementation in C is precise and accurate
 and maintainable in a way that scripts will never be.
 
 We should stay careful about architecture.

Well my mantra is this:
RPMTAG_ARCH needs to DIE! DIE! DIE!
Seriously: in the real world (i.e. not linux) there are several
important identifying attributes that need to be controlled for.

And there are some seriopus pending changes in order to handle
ARM platforms, which have features that are disabled/enabled.
Already there is serious confusions attempting using architecture
for Linux/ARM. Each variant feature leads to a new architecture
forcing some compatibility chains that are simply fictions (i.e. there
is more compatibility than promised by choices for RPM arch compatibility).

 
 Apple moved from 68k to PowerPC, and then to x86 (32 and 64 bits).
 And who knows what future processor they could bring in desktop :)
 

It will more than likely be an A6 ;-)

 Also, Xcode build tools may stop supporting PowerPC in a near future,
 so packages will lost their 'universal' architecture.

(aside)
If you have Xcode skills, I'd like to see RPM build under Xcode.
I'm still in denial there however ;-)

 I recall some packages who need to go up to Assembly level and I'm not
 sure OSX build tools could embed many builds in a single binary.
 
 But for now, x86 (32/64bits) is a general consensus

No iPads for you eh?

73 de Jeff

__
RPM Package Managerhttp://rpm5.org
User Communication List rpm-users@rpm5.org

Re: rpm on OSX Lion

[Jeffrey Johnson]

On Mar 26, 2012, at 12:39 PM, Henri Gomez wrote:

 I'll add gpg, neon and wget, and redo tests.
 
 About pcre, I build rpm with 8.30 (as seen in otool log).
 Should I disable it ?

PCRE is MANDATORY (because RPM has compiled in patterns
written in the PCRE dialect).

8.30 was what I used when I  re-enabled
--with-pcre=internal

Meanwhile the issue is symbol collision because of -lpcreposix.
Everything must be linked consistently You miss, you die.

The internal version of PCRE adds these defines to avoid
symbol pollution at the end of pcreposx.h

/* The functions */

PCREPOSIX_EXP_DECL int pcre_regcomp(regex_t *, const char *, int);
PCREPOSIX_EXP_DECL int pcre_regexec(const regex_t *, const char *, size_t,
 regmatch_t *, int);
PCREPOSIX_EXP_DECL size_t pcre_regerror(int, const regex_t *, char *, size_t);
PCREPOSIX_EXP_DECL void pcre_regfree(regex_t *);

#define regcomp pcre_regcomp
#define regexec pcre_regexec
#define regerror pcre_regerror
#define regfree pcre_regfree

Most linux distros (but not Red Hat) are doing similar for many years.

hth

73 de Jeff

 
 2012/3/26 Jeffrey Johnson n3...@me.com:
 
 On Mar 26, 2012, at 11:53 AM, Henri Gomez wrote:
 
 rpm-test-results
 
 
 
 Quick drive-by browse:
 
 --14: __gpg %{_bindir}/gpg2
 
 That is used by make test to generate a pub key for testing.
 That is these failures:
 sh genpgp.sh  genpgp.h
 genpgp.sh: line 15: gpg2: command not found
 hint: You will see the %{_bindir} change to an actual path
 if/when the executable is found in the usual places.
 
 wget -nv http://rpm5.org/files/popt/popt-1.14-1.src.rpm
 make: wget: No such file or directory
 
 There is tools/wget that is good enuf (when I'm paying attention, not yet)
 to replace system wget for simple downloads. But you need
 --with-neon
 first.
 
 This error looks moderately serious (you can comment out the patterns
 in macros/* if you must: but pattern matching looks fubar):
 error: ^[A-Za-z0-9+._]+$: regexec failed: regexec() failed to match(1)
 
 Because -lpcreposix and the system regexec(3) routines have
 identical symbols, there's a high risk of collision. I've re-added
 --with-pcre=internal
 in order to avoid some issues on RHEL6.
 
 Hint: If you add --miredebug to the command in the makefile you will
 get pattern matching debugging sewage. This is generally true for
 all 30-40 RPM objects: you will at least get a ctor/dtor message which
 is often enough to get sufficient context to identify what is wrong. But
 in this case, you likely have broken pattern matching in you build
 everywhere.
 
 There's a fair number of tests that were not run because packages
 failed to build. See the
 http://harwich.jbj.org:8010
 waterfall, look for the test: stage, to see what SHOULD be happening.
 
 hth
 
 73 de Jeff
 
 
 
 __
 RPM Package Managerhttp://rpm5.org
 User Communication List rpm-users@rpm5.org

__
RPM Package Managerhttp://rpm5.org
User Communication List rpm-users@rpm5.org

Re: rpm on OSX Lion

[Jeffrey Johnson]

On Mar 26, 2012, at 4:54 PM, Henri Gomez wrote:

 What's devtool.conf ?
 

This is the file where various build option stanzas are kept.

Building from CVS, the workflow goes like
cvs co rpm
./devtool checkout
./devtool falmouth  # -- the build options I use on Lion server

There is another bootstrapping stanza (i.e. all build prerequisites
are downloaded/built and rpm is linked against those builds)
in a %standalone stanza.

I personally don't use %standalone because I need to see
a maximally configured rpm to prevent bit rot while developing.

But the %standalone stanza is very useful for testing builds across a
variety of platforms without installing anything whatsoever on that machine
(which is what aft was referring to).

All that is in devtool (and devtool.conf) is a series of %foo shell stanzas.

Think portable shell functions and you will figure out what is being done
with
./devtool checkout
./devtool falmouth

and also
./devtool standalone

73 de Jeff

__
RPM Package Managerhttp://rpm5.org
User Communication List rpm-users@rpm5.org

Re: rpm on OSX Lion

[Jeffrey Johnson]

On Mar 26, 2012, at 4:57 PM, Henri Gomez wrote:

 
 MacPorts team did a tremendous works and duplicating effort may not be 
 mandatory. 
 

I should explain the fundamental disconnect between RPM - MacPorts
(and more generally *BSD) here.

There are build dependencies and there are install dependencies.

These sets are quite different.

RPM is all about install dependencies and binary packaging.

MacPorts (and *BSD) is all about build dependencies.

RPM confuses things further because (in fact) the build - install
dependencies are essentially the same because of dog food
and creating build systems using binary packages.

MacPorts confuses things further with +variants in build recipes
that are actually attributes on edges between package nodes
in the dependency graph. The closest similar analogue in linux
is flavors (iirc) usined by Conary from rPath (but there are other
attempts at +foo variants in linux, just none are worth a damn,
including bonds in RPM using --with and --without).

Which comes to what has been attempted with RPM binary
packages built by Portfile recipes but creating *.rpm binary packages.

The port implementation attempted to map make world build dependencies
out of port(1) Portfile recipe builds directly into a *.spec template using
Requires: …
and
Provides: …
with some modest filtering.

At the same time RPM is/was automating what are essentially
install dependencies and also adding those to *.rpm packages.

This leads to rather a snarly mess because
build != install
dependencies: the graphs are quite different.

Instead of explaining this Yet Again, its literally (for me anyways) to
embed a tcl interpreter, dink a bit with how the port cli arguments
are passed into tcl, and just hijack all the recipes, and rely on
FULLY automated (rather package manual goo) dependency extraction
by rule to fill in binary package metadata without all the associated
discussions that MacPorts volunteers continue to voice.

MacPorts is nicely done. Just they haven't yet the experience
with dependency graphs and binary packaging because of
cultural (like make world and *.dmg and bundles) issues.

Short answer:
I don't think there is sufficient interest in MacPorts in using RPM 
intelligently.

JMHO, YMMV.

73 de Jeff__
RPM Package Managerhttp://rpm5.org
User Communication List rpm-users@rpm5.org

Re: rpm on OSX Lion

[Jeffrey Johnson]

On Mar 25, 2012, at 2:59 AM, Henri Gomez wrote:

 Jenkins is spiffy, buildbot -- particularly with older python-2.4 --
 is a bit of wrestling match.
 
 I set up both on the same machine. Jenkins/Hudson needed
 500 Mb and filled /var/log within a week with useless messages.
 
 Yep, Jenkins could be very verbose, but well, it fit well Continuous
 Integration need (more than just a build engine).
 And I'm pretty experienced with it :)
 

Either Jenkins/Hudson or buildbot are adequate to my usage case.

Yes more than a build engine is needed. Note that de facto CI in
RPM is currently using OWL2/OWL3/IDMS (because those
distros are small and the packaging has few errors), installing into
a chroot, and undertaking packaging QA (and explicit code coverage
of common production RPM code paths).

 Buildbot is lighter weight and sooner or later one figures
 out the double half nelson hammerlock to pin buildbot in
 the wrestling match of CI.
 
 
 You want a full distro on Mac OS X based on RPM? Count me in …
 
 I'd like to. May be it's covered by OpenPKG project ?

Yes OpenPKG runs on Mac OS X. But the OpenPKG approach
is running on multiple platforms reliably in a *BSD jail. That's
very different than a MacPorts or Homebrew replacement.

 BTW, we are many tired to see MacPorts or Brew requiring to download
 all internet and build it locally.
 There is a strong interest for RPMs on OSX.

Well … maybe. There is interest in RPM on Mac OS X this week, not
just from you. The interest historically has been in binary packages,
not in RPM (which has been available in MacPorts and *BSD thanks
to Anders Bjorkland for years).

 
 I tried to build various versions of rpm but they required beecrypt and 
 popt.
 
 Yes: neither bee crypt nor popt is optional. Both are distributed with
 RPM batteries included.
 
 What do you means by RPM batteries included ?

I meant 2 things:

1) This is a whole lot of batteries (i.e. libraries) linked into
an ELF executable:
$ ldd .libs/rpm | wc -l 92 

2) The AutoFu is unusual because RPM supports -with-foo=internal
for libraries that are problematic. All of the build problems you reported
Berkeley DB
BeeCrypt
popt
are problematic for different reasons. When RPM is built batteries included,
your problems building RPM pre-requisites case to exist: those libraries
are built with RPM and are installed with RPM in -lrpmmisc.

 beecrypt and popt are reported mandatory in 5.x release (from what I
 see in configure).
 

Yes: common digests are computed by BeeCrypt and option processing
is perfumed by popt. RPM has used bee crypt and popt since forever.

 My Lion machine is using 64bits kernel and I can't succeed build
 beecrypt in universal mode (32/64 bits) ;(
 
 
 Beecrypt ends up in -lrpmmisc if building
--with-beecrypt=internal
 
 beecrypt internal means it will be build statically in rpm ?

Not statically but otherwise yes.

 So beecrypt lib sources should be included somewhere I guess
 

Beecrypt (and popt) sources are added to RPM's build tree by
./devtool checkout
when building from CVS. And a concept of a tar ball release isn't
all that useful because on set of files needs to be chosen for distribution.

E.g. Berkeley DB isn't (currently) being distributed within RPM tar balls
largely because I got tired of hearing Bloat! Bloat! Bloat!. The cost
of a smaller tar ball is that the build is harder: detecting/linking all 
possible
versions on all possible platforms for BDB is exactly one of the problems that
you (and others) are reporting.

So the choice in RPM is

1) distribute RPM+BDB and build internally and users complain about Bloat!
2) target a single version of Berkeley DB external installed one specific way
and users complain about hard to build.

 So I'd like to avoid requiring MacPorts but it seems we need many
 bootstrap libraries like popt/beecrypt (and in Universal Format).
 
 Only if you choose to build against external libraries. E.g. Berkeley DB
 can be built and distributed with RPM as well. In fact that is what I
 would do if the decision was mine: writing AutoFu tests for all possible
 versions of Berkeley DB is much harder than just bundling Berkeley DB
 within RPM (as was done for years).
 
 +1 for embebed Berkeley DB inside RPM, there is just too many versions
 on BDB around and it could be a nightmare.
 

Sadly votes and opinions and engineering do not matter: building RPM
with BDB externally (and cutting the size of the distributed rpm-X.Y.Z.tar.gz
by more than 50%) was hugely popular.

Meanwhile, if you untar  db-5.3.15.tar.gz in the top level directory,
and rename to db, you likely have a pretty good chance that
internal Just Works (but there are other and more complex issues
with embedded sqlite3)

 What is involved with Universal Format for you?
 
 OSX could build it binaries including many formats, aka x86 32bits and
 x86 64bits.
 Take a look here, I detail build process for mod_jk in dual model mode :
 
 

Re: rpm on OSX Lion

[Jeffrey Johnson]

On Mar 25, 2012, at 11:18 AM, Henri Gomez wrote:

 First thing I'd like to do is building RPM 5.x from tarball or SCM with no 
 dependencies on MacPorts. 

Here's the build incantations:
$ cvs -d ':pserver:anonym...@rpm5.org:/v/rpm/cvs' get -r rpm-5_4 -d wdj54 
rpm
$ cd wdj54
$ ./devtool checkout
$ ./devtool falmouth
$ make
$ cd tests
$ make clean test

You WILL need (on Lion) to install db-5.3.15  (I'm told that a db53 port was 
just added).

I do this one expedient hack with db-5.,3.15 (because its a PITA to fix 
properly):

cd /opt/local/lib
ln -s db53/* .

Change the %falmouth stanza to lose any build prerequisites
(mostly bog standard MacPorts but I do what is needed to
enable _EVERYTHING_ for RPM development) that you do not wish to fight with.

 
 Advices very welcomed :-)
 
 If build scripts are available I'll study them closely. 
 

The build scripts above are all that is needed. What is harder is ensuring
all the build prerequisites are in place and choosing the build options.

The above is essentially what is running in the LION_rpm_rpm54 waterfall.
Examine those builds to see what is needed.

Building RPM is _NOT_ as simple as doing
./configure --prefix=/usr
which everyone expects.

The ./devtool … paradigm is based on GNU shtool.

Another piece of RPM's build puzzle is a very slick
RPM_CHECK_LIB()
m4 macro that Just Works in most cases (note: that it took me
more than a year to learn how to use RPM_CHECK_LIB() and 
'm still learning tricks and twists even today …)

Both devtool and RPM_CHECK_LIB are from Ralf S Engelschall
at OpenPKG: _REALLY_ nicely done engineering imho.

hth

73 de Jeff

 Le 25 mars 2012 à 14:33, Jeffrey Johnson n3...@me.com a écrit :
 
 
 On Mar 25, 2012, at 2:59 AM, Henri Gomez wrote:
 
 Jenkins is spiffy, buildbot -- particularly with older python-2.4 --
 is a bit of wrestling match.
 
 I set up both on the same machine. Jenkins/Hudson needed
 500 Mb and filled /var/log within a week with useless messages.
 
 Yep, Jenkins could be very verbose, but well, it fit well Continuous
 Integration need (more than just a build engine).
 And I'm pretty experienced with it :)
 
 
 Either Jenkins/Hudson or buildbot are adequate to my usage case.
 
 Yes more than a build engine is needed. Note that de facto CI in
 RPM is currently using OWL2/OWL3/IDMS (because those
 distros are small and the packaging has few errors), installing into
 a chroot, and undertaking packaging QA (and explicit code coverage
 of common production RPM code paths).
 
 Buildbot is lighter weight and sooner or later one figures
 out the double half nelson hammerlock to pin buildbot in
 the wrestling match of CI.
 
 
 You want a full distro on Mac OS X based on RPM? Count me in …
 
 I'd like to. May be it's covered by OpenPKG project ?
 
 Yes OpenPKG runs on Mac OS X. But the OpenPKG approach
 is running on multiple platforms reliably in a *BSD jail. That's
 very different than a MacPorts or Homebrew replacement.
 
 BTW, we are many tired to see MacPorts or Brew requiring to download
 all internet and build it locally.
 There is a strong interest for RPMs on OSX.
 
 Well … maybe. There is interest in RPM on Mac OS X this week, not
 just from you. The interest historically has been in binary packages,
 not in RPM (which has been available in MacPorts and *BSD thanks
 to Anders Bjorkland for years).
 
 
 I tried to build various versions of rpm but they required beecrypt and 
 popt.
 
 Yes: neither bee crypt nor popt is optional. Both are distributed with
 RPM batteries included.
 
 What do you means by RPM batteries included ?
 
 I meant 2 things:
 
 1) This is a whole lot of batteries (i.e. libraries) linked into
 an ELF executable:
   $ ldd .libs/rpm | wc -l 92 
 
 2) The AutoFu is unusual because RPM supports -with-foo=internal
 for libraries that are problematic. All of the build problems you reported
   Berkeley DB
   BeeCrypt
   popt
 are problematic for different reasons. When RPM is built batteries 
 included,
 your problems building RPM pre-requisites case to exist: those libraries
 are built with RPM and are installed with RPM in -lrpmmisc.
 
 beecrypt and popt are reported mandatory in 5.x release (from what I
 see in configure).
 
 
 Yes: common digests are computed by BeeCrypt and option processing
 is perfumed by popt. RPM has used bee crypt and popt since forever.
 
 My Lion machine is using 64bits kernel and I can't succeed build
 beecrypt in universal mode (32/64 bits) ;(
 
 
 Beecrypt ends up in -lrpmmisc if building
  --with-beecrypt=internal
 
 beecrypt internal means it will be build statically in rpm ?
 
 Not statically but otherwise yes.
 
 So beecrypt lib sources should be included somewhere I guess
 
 
 Beecrypt (and popt) sources are added to RPM's build tree by
   ./devtool checkout
 when building from CVS. And a concept of a tar ball release isn't
 all that useful because on set of files needs to be chosen for distribution

Re: rpm on OSX Lion

[Jeffrey Johnson]

On Mar 24, 2012, at 9:12 AM, Henri Gomez wrote:

 Excellent.
 
 I now well Jenkins but not Waterfall, seems interesting.
 

Jenkins is spiffy, buildbot -- particularly with older python-2.4 --
is a bit of wrestling match.

I set up both on the same machine. Jenkins/Hudson needed
500 Mb and filled /var/log within a week with useless messages.

Buildbot is lighter weight and sooner or later one figures
out the double half nelson hammerlock to pin buildbot in
the wrestling match of CI.

 I build the latest rpm-5_4 from CVS on Lion Server using a buildbot here:
http://harwich.jbj.org:8010/waterfall
 
 Both Lion Server (and Leopard) are there in the waterfalls.
 
 (aside)
 Both are broken atm just because I haven't bothered fixing bleeding edge 
 functionality
 on Mac OS X quite yet.
 
 Note that bleeding edge is currently attempting to use an embedded
 perl interpreter to load a perl-URPM CPAN module that isn't installed.
 i.e. no one but me needs/uses this RPM functionality yet.
 
 But there are older successful logs which show the build options in
 use and the results of buildbot testing on both Lion and Leopard
 (and if you want Snow Leopard or Mountain Lion, I can likely
 attempt that too).
 
 The majority of the packages in use are bog standard installs from
 MacPorts port(1). There's a few packages (like db-5.3.15) that aren't in 
 MacPorts
 yet that I build manually.
 
 The really hard part of building RPM is figuring out the build options.
 Its not as simple as just doing
./configure --prefix=/opt/local
make
make install
 
 But feel free to make suggestions on what you want to see. I'd love
 to see RPM in use on Mac OS X.
 
 My goal was to bring RPM natively to OSX and see if it would be
 possible to set a RPM distribution like one available from MacPorts or
 Brew but without requiring to build it.
 

You want a full distro on Mac OS X based on RPM? Count me in …

 I tried to build various versions of rpm but they required beecrypt and popt.

Yes: neither bee crypt nor popt is optional. Both are distributed with
RPM batteries included.

 My Lion machine is using 64bits kernel and I can't succeed build
 beecrypt in universal mode (32/64 bits) ;(
 

Beecrypt ends up in -lrpmmisc if building
--with-beecrypt=internal

 So I'd like to avoid requiring MacPorts but it seems we need many
 bootstrap libraries like popt/beecrypt (and in Universal Format).

Only if you choose to build against external libraries. E.g. Berkeley DB
can be built and distributed with RPM as well. In fact that is what I
would do if the decision was mine: writing AutoFu tests for all possible
versions of Berkeley DB is much harder than just bundling Berkeley DB
within RPM (as was done for years).

What is involved with Universal Format for you?

73 de Jeff

 __
 RPM Package Managerhttp://rpm5.org
 User Communication List rpm-users@rpm5.org

__
RPM Package Managerhttp://rpm5.org
User Communication List rpm-users@rpm5.org

Re: rpm on OSX Lion

[Jeffrey Johnson]

On Mar 23, 2012, at 7:41 PM, Henri Gomez wrote:

 Hi to all,
 
 I'm a long time rpm user and packager and I'd like to experiment it on
 OSX (10.7.3) and Xcode 4.3.2.
 

Good.

snip

 
 Did someone succeed to build rpm 5.x on OSX Lion ?
 Advices more than welcomed.
 

I build the latest rpm-5_4 from CVS on Lion Server using a buildbot here:
http://harwich.jbj.org:8010/waterfall

Both Lion Server (and Leopard) are there in the waterfalls.

(aside)
Both are broken atm just because I haven't bothered fixing bleeding edge 
functionality
on Mac OS X quite yet.

Note that bleeding edge is currently attempting to use an embedded
perl interpreter to load a perl-URPM CPAN module that isn't installed.
i.e. no one but me needs/uses this RPM functionality yet.

But there are older successful logs which show the build options in
use and the results of buildbot testing on both Lion and Leopard
(and if you want Snow Leopard or Mountain Lion, I can likely
attempt that too).

The majority of the packages in use are bog standard installs from
MacPorts port(1). There's a few packages (like db-5.3.15) that aren't in 
MacPorts
yet that I build manually.

The really hard part of building RPM is figuring out the build options.
Its not as simple as just doing
./configure --prefix=/opt/local
make
make install

But feel free to make suggestions on what you want to see. I'd love
to see RPM in use on Mac OS X.

hth

73 de Jeff
__
RPM Package Managerhttp://rpm5.org
User Communication List rpm-users@rpm5.org

Re: rpm5 compilation on rhel6.

[Jeffrey Johnson]

On Feb 15, 2012, at 3:59 PM, Maruthi Devulapalli wrote:

 Hi All,
  
 Need your help with this,
  
 make[3]: Entering directory xmlFreeParserCtxt'
 /tmp/rpm/rpm-5.3.5/misc/.libs/librpmmisc.so: undefined reference to 
 xmlCreatePushParserCtxt'
 /tmp/rpm/rpm-5.3.5/misc/.libs/librpmmisc.so: undefined reference to 
 /tmp/rpm/rpm-5.3.5/rpmconstant'
 make[2]: *** [all] Error 2
 make[2]: Leaving directory /tmp/rpm/rpm-5.3.5'
 make: *** [all] Error 2
  

Hmmm … I don't recall this issue.

One thing to try is a clean build from scratch
make distclean
or (at a minimum) rebuild the misc directory:
cd misc
make clean all
The misc directory has some subtle problems with missing Makefile 
pre-requisites.
A proper solution is quite difficult because of the need to build RPM both with
internal - external trees. Some problems are not worth solving imho.

RPM itself doesn't depend on libxml2: the usual need is from
rpm - neon - libxml2
where the necessary additional libraries are brought in from neon's pkgconfig.

So librpmmisc is a collection point for most external library linkages, and
a container for most internal (i.e. built when RPM is built) objects. That
is why rebuilding misc manually somethings needs to be attempted.

  
 configured with  ./configure --with-openssl=/usr/local/ssl/ 
 --with-db=/usr/include/db51
  

You might need additional options (if those are the only two options you passed 
to configure).

Examine the %system stanza in the top-level devtool.conf file. Those options are
what I typically use on Red Hat derived systems (but note that for development
I configure *EVERYTHING*: you almost certainly need/want to be more selective
than what is in the %system stanza).

hth

73 de Jeff
  
 Best Regards
 Maruthi Devulapalli
 NASD – Unix
 201-743-6585
  
 
 This email originates from AXA Technology Services UK Limited (reg. no. 
 1854856) which has its registered office at 5 Old Broad Street, London EC2N 
 1AD, England.
 This message and any files transmitted with it are confidential and intended 
 solely for the individual or entity to whom they are addressed. If you have 
 received this in error, you should not disseminate or copy this email. Please 
 notify the sender immediately and delete this email from your system.
 
 Please also note that any opinions presented in this email are solely those 
 of the author and do not necessarily represent those of The AXA UK Plc Group.
 
 Email transmission cannot be guaranteed to be secure, or error free as 
 information could be intercepted, corrupted, lost, destroyed, late in 
 arriving or incomplete as a result of the transmission process. The sender 
 therefore does not accept liability for any errors or omissions in the 
 contents of this message which arise as a result of email transmission.
 
 Finally, the recipient should check this email and any attachments for 
 viruses. The AXA UK Plc Group accept no liability for any damage caused by 
 any virus transmitted by this email.
 

Re: MD5 digest: BAD

[Jeffrey Johnson]

On Feb 13, 2012, at 2:23 PM, PuttaReddy Challa wrote:

 Hi,
 
  
 I am trying to install an RPM on RH AS 3 (32bit) machine, the RPM was created 
 on 64bit RH AS 4 machine and getting the following error.
 
 
 
 
 MD5 digest: BAD Expected(64280bc31a50e2f9364080bae1113538) != 
 (ab4411706ca18bdfc9a20006c18d2f69)^M
 
  
 
 same RPM install used to work previously when the build machine was RH AS3  
 (32bit) and the RPM size was 3.6 GB. RPM install worked on all RH AS 3 and RH 
 AS 4  RH AS 5 servers. Now the RPM size has gone upto 4.2GB and started 
 having failures with MD5 digest: BAD error.
 
 
 
 
 switched the build machine to RH AS 4 X64 bit and the RPM install was OK on 
 all machines except RH AS 3 (32bit).
 
 I would really appreciate if anyone can give some pointers on why it fails 
 with MD5 digest error on RH AS 3 (32bit) and any workarounds available.
 

I'd need to know all the versions of RPM involved, as well as some
details to determine the root cause.

But I can hazard a guess:

I believe you are packaging a binary library that has been prelinked on the
failing system.

Try disabling file digest checking while installing:  --nofdigests is the
current disabler, the previous disabler was --md5sums or something.

(this is from 5+ year old memory)

Does your package install if file digest checking is disabled?

73 de Jeff
  
 Thanks,
 
 Putta
 
  
 Original
 

Re: MD5 digest: BAD

[Jeffrey Johnson]

On Feb 13, 2012, at 4:44 PM, PuttaReddy Challa wrote:

 Thanks Jeff for taking a look at the issue. here are the versions of RPMs 
 involved.
 
 1) RH AS 4 x86-64 build machine where RPM is created
 [rh4as-x86-64 ~]$ rpm --version
 RPM version 4.3.3
 
 2) RH AS 3 32 build machine where RPM is created
 rh3as-x86 ~]$ rpm --version
 RPM version 4.2.3
 [buildusr@rh3as-x86 ~]$
 
 
 3) Machine i was trying to install the RPM created on RH AS4 x86-64
 rpm --version
 RPM version 4.2.3
 

OK.

 RPMs created using step (2) used to work before the size of the RPM is 
 increased from 3.6 to 4.2GB (when i removed some of the files that are part 
 of this RPM and reduced the size back to 3.6GB rpm installed worked without 
 MD5 digest error)

So the error is tracking with the files that you removed.

Note that there is an upper limit on both the package payload and each file
contained in a package in older versions of RPM (if you are truly creating
packages that are 3.6Gb and larger).

My guess is that one of those files is a shared library (like lib*.so.*).

You need to run
prelink --undo
(see man pre link) on the shared library before putting attempting to include
in a *.rpm package.

 
 The RPM consists of set of tar_gz files.
 

Does the above make more sense? If not, tell me the paths
of the files that you removed that fixed the issue?

hth

73 de Jeff
__
RPM Package Managerhttp://rpm5.org
User Communication List rpm-users@rpm5.org

Re: MD5 digest: BAD

[Jeffrey Johnson]

On Feb 13, 2012, at 7:15 PM, PuttaReddy Challa wrote:

 
 Jeff,
 
 There are no lib*.so.* files included in the RPM pkg.  The following is the 
 list of files when not INCLUDED in the RPM, rpm install works without issues. 
 These are around 460 MB before adding these files the RPM size is about 3.6GB 
 once these are added it is coming around 4.2 GB.
 

The limit is the largest integer that fits in 32 bits:

$ dc
16 i
 p
4294967295

or ~4.2Gb.

Note that there may be certain places where the sign bit is used, where the 
limit is

7FFF p
2147483647

or ~2.1Gb.

But you have already shown that that the sign bit isn't used
on the unpacking code path because your previous pkg was 3.6Gb.

 I would like to know what the max size of the RPM that i can create/install 
 on RH AS 32 without issues.
 
 
 rpm -q -filesbypkg -p TESTpatch-40.0.0.4301.0-0.noarch.rpm | grep -i 
 TESThttpsProxy
 TESTpatch 
 /opt/TESTare/patch/TESTpatch/Linux/3AS/TESThttpsProxy-40.0.0.0.20.6-1.tar.gz
 TESTpatch 
 /opt/TESTare/patch/TESTpatch/Linux/4AS-X86_64/TESThttpsProxy-40.0.0.0.20.1-1.tar.gz
 TESTpatch 
 /opt/TESTare/patch/TESTpatch/Linux/4AS/TESThttpsProxy-40.0.0.0.20.0-1.tar.gz
 TESTpatch 
 /opt/TESTare/patch/TESTpatch/Linux/5SERVER-X86_64/TESThttpsProxy-40.0.0.0.20.4-1.tar.gz
 TESTpatch 
 /opt/TESTare/patch/TESTpatch/Linux/TESThttpsProxy-40.0.0.0.20.6-1.tar.gz
 TESTpatch 
 /opt/TESTare/patch/TESTpatch/Linux/SLES-10-X86_64/TESThttpsProxy-40.0.0.0.20.2-1.tar.gz
 TESTpatch 
 /opt/TESTare/patch/TESTpatch/SunOS/5.10/TESThttpsProxy-40.0.0.0.20.7-1.tar.gz
 TESTpatch 
 /opt/TESTare/patch/TESTpatch/SunOS/5.8/TESThttpsProxy-40.0.0.0.20.5-1.tar.gz
 TESTpatch 
 /opt/TESTare/patch/TESTpatch/SunOS/5.9/TESThttpsProxy-40.0.0.0.20.3-1.tar.gz
 TESTpatch 
 /opt/TESTare/patch/TESTpatch/SunOS/TESThttpsProxy-40.0.0.0.20.7-1.tar.gz
 

So your issue is the size of your package.

My guess about pre linking is/was a known problem: what I missed
was the size of the *.rpm package you are producing.

In fact, you now have the record for the largest known *.rpm package ever 
attempted
using rpm-4.3 and older.

The previous record was held by Nils Philippsen @redhat.com with an Oracle 
database.

Congratulations!

(and apologies for the humor ;-)

Split the package into two packages is the easiest path forward.

hth

73 de Jeff
__
RPM Package Managerhttp://rpm5.org
User Communication List rpm-users@rpm5.org

Re: question about Mac OS X support

[Jeffrey Johnson]

On Dec 21, 2011, at 3:02 PM, John Ford wrote:

 Hi!
 
 I am working on setting up some tooling for our Mac OS X build farm.  We are 
 using RHEL and Fedora in many parts of our installation and as a result there 
 is lots of knowledge around rpm and yum.  Our current deployment strategy is 
 to create Mac package (.pkg/.mpkg) files that are put into a disk image 
 (.dmg) file.  We have a puppet resource type that understands how to mount 
 the disk image and install the package file.  This works, but makes software 
 removal difficult and is effectively a heavyweight tarball.
 
 I am evaluating different technologies to better deploy our software to our 
 slaves.  I have been browsing your site, but I have a couple questions.  If 
 there are published answers, please feel free to point me towards me.
 
 1) Is Mac OS X supported? Does it work?  Does it require spec file magic?
 

Yes. Yes. Depends:
if you expect to compile Fedora pkgs and run on OS X, Yes changes are 
needed.

 2) Does rpm5.org code play well with yum? Do I need a specific or special 
 version of yum?
 

The @rpm.org code plays better with yum then yum plays with @rpm5.org:

   I use yum daily with @rpm5.org code. Yum developers have stated that they
will never support @rpm5,org code repeatedly.

Yum doesn't promise compatibility, so each distro release has a different 
version.

The version I use changes a single line: so Yes you will need to modify yum, and
will need a special version of yum.

 3) The production/stable/development versions links on the front page don't 
 point to the latest version in the directory for each branch.  What is the 
 actual development version?
 

Yes: Releases are not announced (by me) nor is the web site updated.
The next version will be rpm-5.4.5, following this release
http://rpm5.org/files/rpm/rpm-5.4/rpm-5.4.4-0.2006.src.rpm
 4) for versions  5.3.5 and = 5.3.11, source is distributed as src.rpm.  Is 
 there suggested method of building it for Darwin?  I could use rpm2cpio + 
 cpio to extract the tarball, but I wonder if there is something better.
 

There's a rpm2cpio.sh script that will extract the needed tar ball(s) from the 
*.src.rpm.
You can also extract on any system that already has rpm2cpio.

 5) Is rpm5 still under active development?  The last code drop I see is from 
 June, but previously there were code drops approximately monthly.
 

Yes, No: rpm-5,4,4 was released November 6th,

Yes monthly releases are mostly still in place (when
I'm not snoring through contract administrivia).

hth

73 de Jeff
 Thanks for your help!
 
 John__
 RPM Package Managerhttp://rpm5.org
 User Communication List rpm-users@rpm5.org

Re: rpm-5.0.0 and ftp / http support

[Jeffrey Johnson]

On Dec 10, 2011, at 2:21 PM, Per Øyvind Karlsen wrote:

...
 
 I changed the behavior a few years back (I've forgot why, there is/was a
 reason).
 

BTW, I remembered the reason for the change.

Network transport has always been opt-in rather than opt-out.
I changed from
%_rpmgio %{nil}
to
%_rpmgio .ufdio
because it seemed awkwardly arcane to commit to a opt-in syntax
specified by setting a switch to %{nil}.

Meanwhile the end-point is opt-out behavior, not opt-in. Noone
ever bothers configuring RPM unless they have to. So opt-in
is equivalent to not implmented at all in most cases (like this thread shows).

 Here's the comment (and tested with first URL at the bug report on mdv2011)
 I added to bz#64914
 
 If you configure a macro, then ftp/http transport will be re-enabled.
 
 This can be done on the CLI by adding
-D '_rpmgio .ufdio'
 of done persistently by doing
   echo '%_rpmgio .ufdio'  /etc/rpm/macros
 
 Note that this is unsupported (by Mandriva) functionality in RPM.
 Well, we're just using the default as defined in /usr/lib/rpm/macros,
 but if there's no
 specific drawbacks I shold be aware of beyond the limitations of this
 support you mention,
 I'd be happy to change the default to enable this in our
 /usr/lib/rpm/macros.d/mandriva.. :)
 

Well there aren't any specific drawbacks or there would have been
multiple RFE's to enable network transport in mdv2011 already, and
that did not happen, so the usage case is quite small.

So you likely can re-enable by adding
%_rpmgio.ufdio
somewhere and everyone will continue to not notice
or use RPM network transport in mdv2011.

A more serious effort to achieve opt-out behavior and reliability in RPM
would involve fixing some of the deficiencies.

The ability to resume from an interrupted download is perhaps the next most 
useful
functionality. Its little more than a stat(2) call and (if there is
a partial i.e. use Content-Length: to tell download that exists, seek to
end and add the necessary byte range marker to resume the transfer in the 
middle).

The No support for HTTP 30x redirects. isn't impossibly hard: the URL
needs to be substituted, and the open restarted. But there's a
lot of trash code and debugging that should be hauled out first.

The No support for certs. is deeply complex because a certificate
store would be needed and that's fairly painful to get right and deploy.

To maintain network transport in RPM, there needs to be a test harness
setup to exercise a reasonable functionality. Anything else will
become wild hacks for obscure corner cases, and I really don't
wish to spend the next few years chasing obscure corner cases in
real time: its just simpler/saner to setup a test harness up front
in order to define supported functionality.

Make sense?

73 de Jeff__
RPM Package Managerhttp://rpm5.org
User Communication List rpm-users@rpm5.org