Re: DB_SECONDARY_BAD: Secondary index inconsistent with primary
Hi, >> /var/lib/rpm/Packages: DB_SECONDARY_BAD: Secondary index inconsistent >> with >> primary >> error: db4 error(-30973) from dbcursor->get: DB_SECONDARY_BAD: Secondary >> index inconsistent with primary >> rpm: rpmdb.c:2179: rpmmiNext: Assertion `0' failed. >> Aborted > > What sources are these? HEAD checkout from 4 days ago > Hmmm ... the fix for DB_SECONDARY_BAD is to regenerate > the secondary index. Which can be done by removing the > secondary index, the index will be regenerated on next > open. That's all that --rebuilddb is doing these days, > removing the secondary indices. Something seems to rebuild them and keep the mess in... This particular chroot jail has undergone all sorts of torture (including an rpm 4.x -> rpm 5.x upgrade, then 5.1 -> 5.2 -> various 5.3 snapshots including the various db updates that come with it), so I wouldn't be totally surprised if this is some corruption introduced earlier that is just showing up now. > Do you have a reproducer? No, it just happens when trying to install any package in this environment - if it helps, I can make a copy of /var/lib/rpm/Packages and friends available somewhere, but it's fairly huge (137 MB for just Packages). > Or can you supply more context > about what access was being attempted? rpm -r /build/arklinux/build-dockyard-devel -Uvh any.rpm Doing the same manually (cp any.rpm /build/arklinux/build-dockyard-devel ; chroot /build/arklinux/build-dockyard-devel rpm -Uvh /any.rpm) behaves somewhat differently: Freeing read locks for locker 0x1ab: 22269/140619924379520 Freeing read locks for locker 0x1ad: 22269/140619924379520 Freeing mutex for process: 22269/0 Freeing mutex for process: 22269/0 Freeing mutex for process: 22269/0 Freeing mutex for process: 22269/0 Freeing mutex for process: 22269/0 Freeing mutex for process: 22269/0 Freeing mutex for process: 22269/0 Freeing mutex for process: 22269/0 Freeing mutex for process: 22269/0 Freeing mutex for process: 22269/0 Freeing mutex for process: 22269/0 At that point, it seems to hang, rpm CPU usage goes to 100% and strace on the process doesn't show anything at all, so it seems to be in an infinite loop that doesn't make system calls. ttyl bero __ RPM Package Managerhttp://rpm5.org Developer Communication Listrpm-devel@rpm5.org
DB_SECONDARY_BAD: Secondary index inconsistent wi th primary
Hi, the chroot environment that was producing bogus dependency messages when checking BuildRequires last week has "moved on" to not installing binary packages anymore, saying /var/lib/rpm/Packages: DB_SECONDARY_BAD: Secondary index inconsistent with primary error: db4 error(-30973) from dbcursor->get: DB_SECONDARY_BAD: Secondary index inconsistent with primary rpm: rpmdb.c:2179: rpmmiNext: Assertion `0' failed. Aborted rpm --rebuilddb doesn't fix it. Probably it's db corruption after all... ttyl bero __ RPM Package Managerhttp://rpm5.org Developer Communication Listrpm-devel@rpm5.org
Re: Bogus dependency errors with HEAD from last week
Hi, > Here's two more ways: > > 1) dumping the index > cd /var/lib/rpm > db_dump -p Providename [r...@matterhorn rpm]# /usr/lib/rpm/bin/db_dump -p Providename |grep -A1 -B1 gdbm \00\00\03O gdbm \00\00\03\d9 gdbm-debug\ac \00\00\03T gdbm-devel\ac \00\00\04v gdbm-static\95 \00\00\08\b2 gdbm.so()(64bit) \00\00\00\1c gdbmmodule.so()(64bit) \00\00\08\ec -- \00\00\09| libgdbm.so.3()(64bit) \00\00\03\d9 libgdbm_compat.so.3()(64bit) \00\00\03\d9 > 2) add debug to the line in /usr/lib/rpm/macros that configures > the Providename table/index. [r...@matterhorn rpm]# rpm -q --provides gdbm-devel gdbm-devel = 1.8.3-5ark [r...@matterhorn rpm]# rpm -q --whatprovides gdbm-devel <-- db3open(0x21f9340,Providename,0x7fffd6f4d848) dbi 0x21fd590 rc 0 flags: 0x500 <-- db3associate(0x21fa780(Packages),0x21fd590(Providename),0x7f2e0e76af30,0x0) rc 0 flags: 0x0 --> rpmmiInit(0x21f9340, Providename, 0x21f9240[0]="gdbm-devel") dbi 0x21fd590 mi 0x21fe0e0 --> rpmmiNext(0x21fe0e0) dbi 0x21fd590(Providename) <-- db3copen(0x21fd590,(nil),0x21fe110,0x0) dbc 0x21fe210 rc 0 <-- db3cget(0x21fd590,0x21fe210,0x7fffd6f4d8d0,0x7fffd6f4d870,0x1b) rc -30988 flags: DB_SET key: 0x21fd570[10]0x0 "gdbm-devel" data: (nil)[0] 0x400 <-- rpmmiGet(0x21fd590(Providename),0x21fe210,0x7fffd6f4d8d0,0x7fffd6f4d870,0x1b) rc -30988 <-- db3close(0x21fd590,0x0) rc 0 > I'm at FOSDEM so its a bit awkward to check in code. Expect the fixes > early next week. Thanks, enjoy FOSDEM! ttyl bero __ RPM Package Managerhttp://rpm5.org Developer Communication Listrpm-devel@rpm5.org
Re: Bogus dependency errors with HEAD from last week
On Thu, 04 Feb 2010 10:53:04 -0500, Jeff Johnson wrote: > On Feb 4, 2010, at 9:36 AM, Bernhard Rosenkränzer wrote: > > So only BuildRequires: ? I'll look, so far I haven't > paid much attention to BuildRequires and so I may have missed something. Yes, so far it only happened when trying to install .src.rpms There's not much else going on in that particular chroot jail though. > BTW, this should recreate the Provides: index/table: > ls -al /var/lib/rpm/Providename > rm -f /var/lib/rpm/Providename > rpm -q --whatprovides gdbm-devel > ls -al /var/lib/rpm/Providename Already tried that -- the problem remains after recreating Providename. --whatprovides seems to be problematic too, so probably something is going wrong while creating Providename: [r...@matterhorn rpm]# ls -l Providename -rw-r--r-- 1 root root 819200 Feb 5 08:58 Providename [r...@matterhorn rpm]# rm -f Providename [r...@matterhorn rpm]# rpm -q --whatprovides gdbm-devel [r...@matterhorn rpm]# ls -l Providename -rw-r--r-- 1 root root 815104 Feb 5 10:07 Providename [r...@matterhorn rpm]# rpm -q gdbm-devel gdbm-devel-1.8.3-5ark.x86_64 [r...@matterhorn rpm]# rpm -q --provides gdbm-devel gdbm-devel = 1.8.3-5ark [r...@matterhorn rpm]# rpm -q --whatprovides gdbm-devel [r...@matterhorn rpm]# Another issue, but probably unrelated: rpmbuild --rebuild any.src.rpm segfaults (but -ivh --nodeps followed by -ba is ok) Starting program: /usr/bin/rpmbuild --rebuild /monotone-0.46-1ark.src.rpm [Thread debugging using libthread_db enabled] Installing /monotone-0.46-1ark.src.rpm [New Thread 0x7fffef40e710 (LWP 21972)] [New Thread 0x7fffeec0d710 (LWP 21973)] [New Thread 0x7fffee40c710 (LWP 21974)] Program received signal SIGSEGV, Segmentation fault. 0x7795b7d2 in rpmpsmStage (psm=0x7fffdd60, stage=) at psm.c:2643 2643xx = rpmtxnCommit(rpmtsGetRdb(ts)->db_txn); (gdb) bt #0 0x7795b7d2 in rpmpsmStage (psm=0x7fffdd60, stage=) at psm.c:2643 #1 0x7795c2a3 in rpmInstallSourcePackage (ts=0x640d20, _fd=, specFilePtr=, cookie=) at psm.c:202 #2 0x779750a9 in rpmInstallSource (ts=0x640d20, arg=0x7fffe4e8 "/monotone-0.46-1ark.src.rpm", specFilePtr=0x7fffe138, cookie=0x77ddf450) at rpminstall.c:833 #3 0x0040369f in main (argc=, argv=0x77ddf440) at ./rpmqv.c:792 ttyl bero __ RPM Package Managerhttp://rpm5.org Developer Communication Listrpm-devel@rpm5.org
Bogus dependency errors with HEAD from last week
This just started to happen inside a chroot environment with HEAD from last week: [r...@matterhorn ~]# rpm -ivh /openldap-2.4.19-1ark.src.rpm error: Failed dependencies: gdbm-devel is needed by openldap-2.4.19-1ark.src openssl-devel is needed by openldap-2.4.19-1ark.src pam-devel is needed by openldap-2.4.19-1ark.src tcp_wrappers-devel is needed by openldap-2.4.19-1ark.src libtool >= 1.4 is needed by openldap-2.4.19-1ark.src [Those dependencies are set in BuildRequires: in the spec file, so they're identified correctly] But all the packages it's complaining about are there, an rpm knows they are: [r...@matterhorn ~]# rpm -q gdbm-devel openssl-devel pam-devel tcp_wrappers-devel libtool gdbm-devel-1.8.3-5ark.x86_64 openssl-devel-1.0.0-0.beta4.2ark.x86_64 pam-devel-1.1.0-1ark.x86_64 tcp_wrappers-devel-7.6-36ark.x86_64 libtool-2.2.6b-1ark.x86_64 [r...@matterhorn rpm]# rpm -q --provides gdbm-devel openssl-devel pam-devel tcp_wrappers-devel libtool gdbm-devel = 1.8.3-5ark openssl-devel = 1.0.0-0.beta4.2ark pam-devel = 1.1.0-1ark tcp_wrappers-devel = 7.6-36ark libtool = 2.2.6b-1ark rpm --rebuilddb and db_recover -ev don't change anything about it. Same thing with some verbosity added: [r...@matterhorn ~]# rpm -vvv -ivh /openldap-2.4.19-1ark.src.rpm D: pool fd: created size 392 limit -1 flags 0 D: pool lua:created size 56 limit -1 flags 0 D: pool ts: created size 1216 limit -1 flags 0 D: pool gi: created size 160 limit -1 flags 0 D: pool dig:created size 408 limit -1 flags 0 D: pool h: created size 352 limit -1 flags 0 D: Expected size: 5588482 = lead(96)+sigs(920)+pad(0)+data(5587466) D: Actual size: 5588482 D: pool ctx:created size 104 limit -1 flags 0 D: /openldap-2.4.19-1ark.src.rpm: Header SHA1 digest: OK (27c54237e8e3044cc3d04d2eed3d8345f37 55ef2) D: pool te: created size 360 limit -1 flags 0 D: pool ds: created size 224 limit -1 flags 0 D: pool fi: created size 552 limit -1 flags 0 D: pool bf: created size 48 limit -1 flags 0 D: pool db: created size 320 limit -1 flags 0 D: pool dbi:created size 440 limit -1 flags 0 D: rpmdb: cpus 4 physmem 3950Mb D: opening db environment /var/lib/rpm/Packages thread:lock:log:mpool:txn D: opening db index /var/lib/rpm/Packages thread:rdonly:auto_commit mode=0x0 D: pool tsi:created size 40 limit -1 flags 0 D: == +++ openldap-2.4.19-1ark.src x86_64/linux 0x0 D: pool ps: created size 32 limit -1 flags 0 D: opening db index /var/lib/rpm/Providename thread:rdonly:auto_commit mode=0x0 D: pool mi: created size 144 limit -1 flags 0 D: Requires: gdbm-develNO D: package openldap-2.4.19-1ark.src has unsatisfied Requires: gdbm-devel D: Requires: openssl-devel NO D: package openldap-2.4.19-1ark.src has unsatisfied Requires: openssl-devel D: Requires: pam-devel NO D: package openldap-2.4.19-1ark.src has unsatisfied Requires: pam-devel D: Requires: perl YES (db provides) D: Requires: tcp_wrappers-develNO D: package openldap-2.4.19-1ark.src has unsatisfied Requires: tcp_wrappers-devel D: Requires: libtool >= 1.4NO D: package openldap-2.4.19-1ark.src has unsatisfied Requires: libtool >= 1.4 D: Requires: db-devel YES (db provides) D: pool mire: created size 128 limit -1 flags 0 D: Requires: rpmlib(PayloadIsLzma) <= 4.4.6-1 YES (rpmlib provides) D: opening db index /var/lib/rpm/Conflictname thread:rdonly:auto_commit mode=0x0 D: closed db index /var/lib/rpm/Conflictname D: closed db index /var/lib/rpm/Providename D: closed db index /var/lib/rpm/Packages D: closed db environment /var/lib/rpm/Packages error: Failed dependencies: gdbm-devel is needed by openldap-2.4.19-1ark.src openssl-devel is needed by openldap-2.4.19-1ark.src pam-devel is needed by openldap-2.4.19-1ark.src tcp_wrappers-devel is needed by openldap-2.4.19-1ark.src libtool >= 1.4 is needed by openldap-2.4.19-1ark.src D: == recording tsort relations D: == tsorting packages (order, #predecessors, #succesors, tree, Ldepth, Rbreadth) D: 000100 +openldap-2.4.19-1ark.src D: pool gi: reused 0, alloc'd 1, free'd 1 items. D: pool mi: reused 24, alloc'd 1, free'd 1 items. D: pool tsi:reused 13, alloc'd 1, free'd 1 items. D: pool ts: reused 0, alloc'd 1, free'd 1 items. D: pool te: reused 0, alloc'd 1, free'd 1 items. D: pool ps: reused 0, alloc'd 1, free'd 1 items. D: pool ds: reused 16, alloc'd 6, free'd 6 items. D: pool fi: reused 0, alloc'd 1, free'd 1 items. D: pool db: reused 0, alloc'd 1, free'd 1 items. D: pool dbi:reused 0, alloc'd 3, free'd 3 items. D: pool h: reused 2, a
Re: Segfault while removing a package with current HEAD
On Tue, 26 Jan 2010 08:23:30 -0500, Jeff Johnson wrote: > I can likely guess what needs to be done, but it would help if you > could send along the -vv spewage so I can confirm my guess. D: pool fd: created size 212 limit -1 flags 0 D: pool lua:created size 32 limit -1 flags 0 D: pool ts: created size 736 limit -1 flags 0 D: pool db: created size 184 limit -1 flags 0 D: pool dbi:created size 284 limit -1 flags 0 D: rpmdb: cpus 4 physmem 3279Mb D: opening db environment /var/lib/rpm/Packages thread:lock:log:mpool:txn D: opening db index /var/lib/rpm/Packages thread:rdonly:auto_commit mode=0x0 D: opening db index /var/lib/rpm/Nvra thread:rdonly:auto_commit mode=0x0 D: pool mi: created size 84 limit -1 flags 0 D: pool mire: created size 84 limit -1 flags 0 D: pool h: created size 216 limit -1 flags 0 D: pool bf: created size 24 limit -1 flags 0 D: pool te: created size 220 limit -1 flags 0 D: pool ds: created size 124 limit -1 flags 0 D: pool fi: created size 316 limit -1 flags 0 D: pool tsi:created size 24 limit -1 flags 0 D: == --- kdepim-4.4.0-0.1072537.1ark.i586 i586/linux 0x0 D: opening db index /var/lib/rpm/Requirename thread:rdonly:auto_commit mode=0x0 D: pool ps: created size 20 limit -1 flags 0 D: == recording tsort relations Segmentation fault > I expect to see something like an attempt to erase a package with > no files, or perhaps a pure erasure, with the parameters needed > for initializing the Bloom filter are tuned towards an upgrade > rather than a pure erasure. > > Does that sound like what you were attempting? Yes, the kdepim package doesn't contain any files, it just requires the correct versions of various subpackages (kmail, korganizer, ...) that make up kdepim. ttyl bero __ RPM Package Managerhttp://rpm5.org Developer Communication Listrpm-devel@rpm5.org
Re: Error when installing a new system with HEAD from a couple of days ago
On Tue, 26 Jan 2010 10:26:23 +0100, Bernhard Rosenkränzer
wrote:
> On Mon, 25 Jan 2010 23:42:37 -0500, Jeff Johnson wrote:
>> On Jan 25, 2010, at 3:22 PM, Bernhard Rosenkränzer wrote:
>>> trying to install a new system into a chroot jail currently fails:
>>> # rpm -r /mnt/dest -ivh /RPMS/*.rpm
>>> rpm: rpmdb.c:254:dbiOpen: Assertion `__dbapi == 3 || __dbapi == 4'
>>> failed.
>
> /usr/lib/rpm/macros and /usr/lib/rpm/macros.d are both there,
> /usr/lib/rpm/macros has %_dbapi 3 set, and rpm (same binary) looks into
> that file on an installed system.
Figured it out:
Recently,
%{load:%{_usrlibrpm}/macros.d/selinux}
was added to /usr/lib/rpm/macros
That file exists in the installed system, but not in the minimal bootstrap
system we're installing from.
Looks like rpm aborts parsing a macros file if it contains a load
statement referring to a nonexistant file, without giving an error message
about it.
It's a user error for leaving that load statement in, but an error message
(or better yet, a warning message plus continued parsing of the file) would
be nice...
ttyl
bero
__
RPM Package Managerhttp://rpm5.org
Developer Communication Listrpm-devel@rpm5.org
Segfault while removing a package with current HEAD
Possibly caused by a slightly corrupted rpmdb, it has gone through its
share of updates to HEAD snapshots...
Starting program: /bin/rpm -e kdepim
[Thread debugging using libthread_db enabled]
Freeing read locks for locker 0x21: 1542/140325654452096
Freeing read locks for locker 0x23: 1542/140325654452096
Freeing mutex for process: 1542/0
Freeing mutex for process: 1542/0
Freeing mutex for process: 1542/0
Freeing mutex for process: 1542/0
Freeing mutex for process: 1542/0
Freeing mutex for process: 1542/0
Freeing mutex for process: 1542/0
Freeing mutex for process: 1542/0
Freeing mutex for process: 1542/0
Freeing mutex for process: 1542/0
Freeing mutex for process: 1542/0
Program received signal SIGSEGV, Segmentation fault.
rpmbfChk (bf=0x0, _s=0x689750, ns=) at rpmbf.c:98
98 for (ns = 0; ns < bf->k; ns++) {
#0 rpmbfChk (bf=0x0, _s=0x689750, ns=) at rpmbf.c:98
#1 0x7794b70e in addRelation (ts=0x650c20, p=0x65d7a0,
selected=, requires=0x65e1b0) at depends.c:2149
#2 0x7794be09 in rpmtsOrder (ts=0x650c20) at depends.c:2432
#3 0x77975806 in rpmcliInstallOrder (ts=0xcf1a1ff5)
at rpminstall.c:320
#4 0x77975aff in rpmErase (ts=0x650c20, ia=0x77b97ea0,
argv=) at rpminstall.c:797
#5 0x00404a4a in main (argc=,
argv=) at ./rpmqv.c:905
__
RPM Package Managerhttp://rpm5.org
Developer Communication Listrpm-devel@rpm5.org
Re: Error when installing a new system with HEAD from a couple of days ago
On Mon, 25 Jan 2010 23:42:37 -0500, Jeff Johnson wrote: > On Jan 25, 2010, at 3:22 PM, Bernhard Rosenkränzer wrote: >> trying to install a new system into a chroot jail currently fails: >> # rpm -r /mnt/dest -ivh /RPMS/*.rpm >> rpm: rpmdb.c:254:dbiOpen: Assertion `__dbapi == 3 || __dbapi == 4' >> failed. > > The path to the macros file is usually the cause of the failure. Probably not in this particular case... /usr/lib/rpm/macros and /usr/lib/rpm/macros.d are both there, /usr/lib/rpm/macros has %_dbapi 3 set, and rpm (same binary) looks into that file on an installed system. ttyl bero __ RPM Package Managerhttp://rpm5.org Developer Communication Listrpm-devel@rpm5.org
Error when installing a new system with HEAD from a couple of days ago
Hi, trying to install a new system into a chroot jail currently fails: # rpm -r /mnt/dest -ivh /RPMS/*.rpm rpm: rpmdb.c:254:dbiOpen: Assertion `__dbapi == 3 || __dbapi == 4' failed. (The same thing works if I run the command from a proper system rather than a stripped down system that doesn't have an rpmdb by itself, so without looking into it deeply, I think it's trying to open the system rpmdb for some reason instead of creating the one in /mnt/dest). ttyl bero __ RPM Package Managerhttp://rpm5.org Developer Communication Listrpm-devel@rpm5.org
Re: A setup <-> filesystem loop because of parentdir ordering
On Tuesday 12 May 2009 21.18:48 Mark Hatle wrote: > We handle this by doing installs in the following order: > *) passwd/group (rpm2cpio) > *) filesystem/basesystem/setup > *) "Everything else" Our approach is rather similar -- 1. Install filesystem/basesystem 2. Install setup 3. rpm -Uvh --force filesystem/basesystem [to fix ownership, now that setup is there] 4. Everything else
Re: Build failures with rpm-5.2.0
Hi, On Wednesday 06 May 2009 20.56:42 Jeff Johnson wrote: > There's this build failure with embedded javascript > that's not yet handled in rpm/js/src/Makefile.am: try BUILT_SOURCES = jsautocfg.h jsautokw.h ttyl bero
Re: Assertion while building a package with current CVS
On Monday 16 February 2009 15.49:53 Jeff Johnson wrote: > Adding XZ (instead of LZMA) internal has fixed the assertion > failure reproducer for me on HEAD. Works for me here too, also with --with-xz=external > AFAIK, LZMA_Alone is still > well supported by XZ, and so there's no further need for LZMA, > but there's still some explicit verifcation steps that are > needed before pushing XZ back to rpm-5.1.7 (and earlier) branches. Anecdotal evidence: We've switched pretty much everything in Ark Linux over to use LZMA about half a year ago (man pages, info pages, rpm payloads, source tarballs of our own bits, ...) The switch to XZ hasn't caused any trouble, our old rpms still install after today's update, and we can still read man/info pages too. There may be some need to keep the LZMA format around (for interoperability with stuff built using the LZMA SDK), but there's no need to keep the old lzma-utils-libs around. ttyl bero __ RPM Package Managerhttp://rpm5.org Developer Communication Listrpm-devel@rpm5.org
Apt-rpm and rpm5 once more
Hi,
the attached patch makes current git apt-rpm build with
rpm5 again, and shouldn't have any bad side effects.
It doesn't work 100% though: It fails to resolve file
dependencies (e.g. it complains about "xauth: Depends:
/bin/sh but it is not installable" when rpm --whatprovides
/bin/sh knows it's bash-4.0-0.rc1.1ark).
Any ideas about that one?
ttyl
bero
--- apt/apt-pkg/rpm/aptcallback.cc.ark 2009-01-28 08:47:08.381260782 +0100
+++ apt/apt-pkg/rpm/aptcallback.cc 2009-01-28 08:48:26.161153245 +0100
@@ -1,6 +1,13 @@
#include
#include
+#include
+#include
+#ifdef HAVE_RPM_RPMLIB_H
#include
+#else
+#include
+#include
+#endif
#include
#include
--- apt/apt-pkg/rpm/raptheader.cc.ark 2009-01-28 08:39:39.296134841 +0100
+++ apt/apt-pkg/rpm/raptheader.cc 2009-01-28 08:42:56.331885802 +0100
@@ -117,8 +117,8 @@ bool raptHeader::getTag(raptTag tag, vec
return ret;
}
#else
-#if RPM_VERSION >= 0x04
-// No prototype from rpm after 4.0.
+#if RPM_VERSION >= 0x04 && RPM_VERSION < 0x05
+// No prototype from rpm 4.x after 4.0.
extern "C" {
int headerGetRawEntry(Header h, raptTag tag, raptTagType * type,
raptTagData p, raptTagCount *c);
@@ -133,7 +133,11 @@ bool raptHeader::getTag(raptTag tag, vec
raptTagCount count = 0;
raptTagType type = RPM_NULL_TYPE;
if (tag == RPMTAG_OLDFILENAMES) {
+#ifndef HAVE_RPM_RPM4COMPAT_H
rc = rpmHeaderGetEntry(Hdr, tag, &type, (void **) &val, &count);
+#else
+ rc = headerGetEntry(Hdr, tag, &type, (void **) &val, &count);
+#endif
} else if (raw) {
rc = headerGetRawEntry(Hdr, tag, &type, (void **) &val, &count);
} else {
--- apt/apt-pkg/rpm/raptheader.h.ark 2009-01-27 22:12:53.131137238 +0100
+++ apt/apt-pkg/rpm/raptheader.h 2009-01-27 22:35:11.182884829 +0100
@@ -9,8 +9,13 @@
#ifndef HAVE_RPM_RPMTAG_H
#include
#else
-#include
#include
+#ifdef HAVE_RPM_HEADER_H
+#include
+#elif defined(HAVE_RPM_RPM4COMPAT_H)
+#include
+#include
+#endif
#endif
using std::vector;
--- apt/apt-pkg/rpm/rapttypes.h.ark 2009-01-27 22:38:27.881015869 +0100
+++ apt/apt-pkg/rpm/rapttypes.h 2009-01-28 08:58:37.773256965 +0100
@@ -6,8 +6,15 @@
* C happily converts enum to int etc automatically, C++ doesn't...
*/
+#ifdef HAVE_RPM_RPMIOTYPES_H
+#include
+#include
+#include
+#endif
#ifdef HAVE_RPM_RPMTYPES_H
#include
+#endif
+#ifndef HAVE_RPM_RPM4COMPAT_H
#include
typedef rpm_data_t raptTagData;
typedef rpm_count_t raptTagCount;
@@ -19,7 +26,7 @@ typedef rpm_loff_t raptCallbackSize;
typedef uint32_t raptInt;
typedef uint32_t raptDbOffset;
#define RAPT_FILENAMES RPMTAG_FILENAMES
-#else
+#elif defined(HAVE_RPM_HEADER_H)
#include
typedef void * raptTagData;
typedef int_32 raptTagCount;
@@ -31,6 +38,17 @@ typedef long unsigned int raptCallbackSi
typedef int_32 raptInt;
typedef uint_32 raptDbOffset;
#define RAPT_FILENAMES RPMTAG_OLDFILENAMES
+#else
+typedef void * raptTagData;
+typedef rpmuint32_t raptTagCount;
+typedef rpmTag raptTag;
+typedef rpmuint32_t raptTagType;
+typedef rpmint32_t raptDepFlags;
+typedef rpmint32_t raptOffset;
+typedef rpmuint64_t raptCallbackSize;
+typedef rpmint32_t raptInt;
+typedef rpmuint32_t raptDbOffset;
+#define RAPT_FILENAMES RPMTAG_OLDFILENAMES
#endif
#if RPM_VERSION >= 0x040100
--- apt/apt-pkg/rpm/rpmhandler.cc.ark 2009-01-28 08:48:41.396884945 +0100
+++ apt/apt-pkg/rpm/rpmhandler.cc 2009-01-28 08:50:27.505027639 +0100
@@ -440,7 +440,13 @@ RPMFileHandler::RPMFileHandler(string Fi
{
_error->Error(_("could not open RPM package list file %s: %s"),
- File.c_str(), rpmErrorString());
+ File.c_str(),
+#ifdef HAVE_RPM_RPM4COMPAT_H
+ rpmlogMessage()
+#else
+ rpmErrorString()
+#endif
+ );
_error->Error(_("... do you need to run \"apt-get update\" first?"));
return;
}
--- apt/apt-pkg/rpm/rpmhandler.h.ark 2009-01-28 08:44:47.766259671 +0100
+++ apt/apt-pkg/rpm/rpmhandler.h 2009-01-28 08:46:35.138075511 +0100
@@ -21,7 +21,12 @@
#include "sqlite.h"
#endif
+#ifdef HAVE_RPM_RPMLIB_H
#include
+#else
+#include
+#include
+#endif
#include
#include "rapttypes.h"
--- apt/apt-pkg/rpm/rpmpackagedata.cc.ark 2009-01-28 08:51:40.667135806 +0100
+++ apt/apt-pkg/rpm/rpmpackagedata.cc 2009-01-28 08:52:16.487984426 +0100
@@ -12,7 +12,11 @@
#include
+#ifdef HAVE_RPM_RPMLIB_H
#include
+#else
+#include
+#endif
RPMPackageData::RPMPackageData()
:
--- apt/apt-pkg/rpm/rpmpm.h.ark 2009-01-28 08:53:24.890887452 +0100
+++ apt/apt-pkg/rpm/rpmpm.h 2009-01-28 08:53:45.823204225 +0100
@@ -11,7 +11,12 @@
#ifndef PKGLIB_rpmPM_H
#define PKGLIB_rpmPM_H
+#include
+#ifdef HAVE_RPM_RPMLIB_H
#include
+#else
+#include
+#endif
#if RPM_VERSION >= 0x040100
#include
#endif
--- apt/apt-pkg/rpm/rpmsystem.cc.ark 2009-01-28 08:59:56.368259894 +0100
+++ apt/apt-pkg/rpm/rpmsystem.cc 2009-01-28 09:00:11.405134971 +0100
@@ -34,7 +34,11 @@
#include
#include
#include
+#ifdef HAVE_RPM_RPMLIB_H
#include
+#else
+#i
Assertion while building a package with current CVS
I just hit an assertion while rebuilding a package with current rpm CVS: Checking for unpackaged file(s): /usr/lib/rpm/check-files /var/tmp/lzma-root rpm: ./rpmio_internal.h:318: fdGetFp: Assertion `fd != ((void*)0) && fd->magic == 0x04463138' failed. Aborted Any ideas? ttyl bero __ RPM Package Managerhttp://rpm5.org Developer Communication Listrpm-devel@rpm5.org
Re: Problems installing the entire OS with rpm5
On Monday 26 January 2009 22.50:16 Jeff Johnson wrote: > Note that I've also added a filter to give you some control > over new dependency loops. > > The basic idea is to count the number of '/' characters in > the parent directory path, and use the # of slashes as a > means to filter out relations of deep paths. I've set it to 5, to make sure /usr/lib/hotplug/firmware is still caught. The new sort order looks better to me, but there are a few new oddities in the install output: sudo-1.6.8p12-1ark.i586 /var/tmp/rpm-tmp.42950: line 1: /bin/chmod: No such file or directory fuse-2.7.2-1ark.i586 error: unpacking of archive failed on file /etc/init.d/fuse;497e5619: cpio: open failed - No such file or directory kdelibs-4.2.0-0.913433.1ark.i586 error: unpacking of archive failed on file /usr/share/config: cpio: rename failed - Is a directory The fuse one is caused by the fact that /etc/init.d is a symlink to /etc/rc.d/init.d and the new installation order caused the package containing that to be installed later --> fuse gets installed into a dangling symlink directory. kdelibs is the same issue we've had with /lib/hotplug initially, so I'm not sure why it doesn't work for that: /usr/share/config is a symlink to /etc/kde and seems to be implicitly created as a directory by something installed earlier. Not sure why sudo gets installed before coreutils now either, sudo doesn't own anything that matters. rpm -qlv sudo -rw-r--r--1 rootroot 278 Nov 22 2005 /etc/pam.d/sudo -r--r-1 rootroot 706 Nov 22 2005 /etc/sudoers ---s--x--x2 rootroot 102736 Nov 22 2005 /usr/bin/sudo ---s--x--x2 rootroot 102736 Nov 22 2005 /usr/bin/sudoedit -rw-r--r--1 rootroot 786 Nov 22 2005 /usr/libexec/sudo_noexec.la -rwxr-xr-x1 rootroot 4488 Nov 22 2005 /usr/libexec/sudo_noexec.so -rwxr-xr-x1 rootroot65168 Nov 22 2005 /usr/sbin/visudo drwxr-xr-x2 rootroot0 Nov 22 2005 /usr/share/doc/sudo-1.6.8p12 -rw-r--r--1 rootroot 1162 May 27 2004 /usr/share/doc/sudo-1.6.8p12/BUGS -rw-r--r--1 rootroot67152 Nov 8 2005 /usr/share/doc/sudo-1.6.8p12/CHANGES -rw-r--r--1 rootroot 1971 Aug 16 2004 /usr/share/doc/sudo-1.6.8p12/HISTORY -rw-r--r--1 rootroot 3858 Apr 2 2003 /usr/share/doc/sudo-1.6.8p12/README -rw-r--r--1 rootroot 9549 Sep 14 2004 /usr/share/doc/sudo-1.6.8p12/RUNSON -rw-r--r--1 rootroot 5466 Oct 28 2005 /usr/share/doc/sudo-1.6.8p12/TODO -rw-r--r--1 rootroot 8556 Feb 5 2005 /usr/share/doc/sudo-1.6.8p12/TROUBLESHOOTING -rw-r--r--1 rootroot18930 Nov 11 2004 /usr/share/doc/sudo-1.6.8p12/sudo.pod -rw-r--r--1 rootroot44838 Nov 28 2004 /usr/share/doc/sudo-1.6.8p12/sudoers.pod -rw-r--r--1 rootroot 7195 Sep 6 2004 /usr/share/doc/sudo-1.6.8p12/visudo.pod -r--r--r--1 rootroot16603 Nov 22 2005 /usr/share/man/man5/sudoers.5.xz -r--r--r--2 rootroot 8928 Nov 22 2005 /usr/share/man/man8/sudo.8.xz -r--r--r--2 rootroot 8928 Nov 22 2005 /usr/share/man/man8/sudoedit.8.xz -r--r--r--1 rootroot 5003 Nov 22 2005 /usr/share/man/man8/visudo.8.xz drwx--2 rootroot0 Nov 22 2005 /var/run/sudo __ RPM Package Managerhttp://rpm5.org Developer Communication Listrpm-devel@rpm5.org
Re: Problems installing the entire OS with rpm5
On Monday 26 January 2009 20.55:18 Jeff Johnson wrote: > Unsurprisingly, RPM "probe dependencies" were designed for > interoperating with a "native" package install, not for bootstrapping > from an empty chroot. That's what I thought -- but I do think it would make sense to look through what is being installed, given rpm5 will be used in both contexts, and ideally without rebuilding packages depending on system install vs. native package install. For now, I've solved the problem by changing the %post scripts etc. to invoke grep as /bin/grep, causing a file dependency instead of the executable(grep) one -- that works in both situations assuming grep doesn't live somewhere else in the path (which is a safe assumption when talking about packages that are part of the base OS and will be installed along with a grep package that puts it where I expect it). > Yes. There is no attempt (atm) to use parent directory dependencies > for ordering purposes. If you're ready to start using hierarchical > directory structure for ordering purposes, well, so am I (I've > been patiently waiting since rpm-4.4.7 for your bug report ;-) I sure am... And we're on 5.2 anyway, so there's no need to play with it on the 5.1 branch. > Ditto wrto filelinkto dependencies, i.e. forcing the end- point > of a symlink to be installed before the package that attempts > to create the symlink, aka "no dangling symlinks" install policy. Sounds good to me -- given the dependencies are already there (just not used for install order), the package set should be ready for it. ttyl bero __ RPM Package Managerhttp://rpm5.org Developer Communication Listrpm-devel@rpm5.org
Problems installing the entire OS with rpm5
Hi, we're finally at a point where we have all packages built with rpm5 - and just tried to do a test install. Basically it works, but we've spotted a few problems that appear to be rpm5 bugs. Our installer does mount /dev/something /mnt/dest # Before that, /dev/something has been freshly formatted rpm -iv --percent -r /mnt/dest -ivh /RPMS/*.rpm The first problem we're running into is executable() dependencies - a few packages complain about an executable(grep) dependency even though grep is being installed at the same time -- but for the executable(grep) dependency to be fulfilled, grep apparently has to exist in /mnt/dest/$SOMETHINGINPATH before trying to install any package that has the dependency. Similarily, the dependencies on directories introduced in rpm5 seem to be normal dependencies rather than prerequires-dependencies, causing the installation order to be wrong in a few cases -- e.g. we have $ rpm -qlv filesystem |grep firmware drwxr-xr-x2 rootroot0 Dec 28 19:28 /lib/firmware lrwxr-xr-x1 rootroot 13 Dec 28 19:28 /usr/lib/hotplug/firmware -> /lib/firmware and $ rpm -qlv firmware-iwlwifi3945 -rw-r--r--1 rootroot 149652 Jun 4 2008 /usr/lib/hotplug/firmware/iwlwifi-3945-1.ucode With both of these packages being installed at the same time using the command above, firmware-iwlwifi3945 is installed before filesystem -- causing /usr/lib/hotplug/firmware to exist as a directory when filesystem wants to create it as a symlink --> the filesystem package doesn't get installed, erroring out with error: unpacking of archive failed on file /usr/lib/hotplug/firmware: cpio: rename failed - Is a directory Of course the right thing to do for the latter is to just update all the old packages to put their firmware files in the right location, but I thought directory dependencies were there (partially) to sort out that sort of thing... Other than those 2 things (and the incomplete rpm5 support in apt-rpm), rpm5 has been doing great in this setup. ttyl bero __ RPM Package Managerhttp://rpm5.org Developer Communication Listrpm-devel@rpm5.org
Avoiding dependencies
I've just run into the old avoiding dependency problems again, and (unless I'm overlooking something and there already is a fix for this) I guess we need to add a new tag for it... In this particular case, a package containing a /proc/self/fd/0 -> /dev/stdin symlink is causing a dependency on /proc/self/fd/0, which (obviously) isn't provided by any package. The usual tricks of removing the executable bit doesn't apply here, so the best thing to do is %define __find_requires to a script that runs /usr/lib/rpm/find-requires |grep -v /proc That, however, turns off the internal dependency generator and all the features it brings. Any chance for a DoesntRequire: or FilterRequires: tag, or for calling the internal dependency generator from a __find_requires script? ttyl bero __ RPM Package Managerhttp://rpm5.org Developer Communication Listrpm-devel@rpm5.org
cpio: File digest mismatch with rpm 5.1.4
Hi, I know this error message usually indicates a corrupted download or somesuch -- but in this particular case, rebuilding the package doesn't help. Trying to install http://arklinux.osuosl.org/dockyard-devel/i586/libxml-static-2.6.32-1ark.i586.rpm always results in error: unpacking of archive failed on file /usr/lib/libxml2.a;489b3fda: cpio: File digest mismatch Rebuilding doesn't help, and rpm -qp --checksig libxml-static-2.6.32-1ark.i586.rpm agress that the file is ok. The source rpm is http://arklinux.osuosl.org/dockyard-devel/SPRMS/libxml-2.6.32-1ark.src.rpm Any ideas? thanks bero __ RPM Package Managerhttp://rpm5.org Developer Communication Listrpm-devel@rpm5.org
Re: [CVS] RPM: rpm/lib/ rpm4compat.h
On Friday 18 July 2008 17.12:31 Jeff Johnson wrote: > - rpm4compat: fix: rpmdsSingle() is a C, not a C++, routine. That was right before - the purpose of rpmdsSingle() in rpm4compat.h (intentionally in #ifdef __cplusplus) is a workaround for a difference between C and C++: In rpm4, rpmdsSingle was: rpmds rpmdsSingle(rpmTag tagN, const char *N, const char *EVR, int_32 Flags) in rpm5, it is: rpmds rpmdsSingle(rpmTag tagN, const char *N, const char *EVR, evrFlags Flags) In terms of C, those provide an identical API, in terms of C++, it means old code doesn't compile unless you add a cast to evrFlags for the last parameter. The purpose of the inline function in rpm4compat.h is to provide a function with the rpm4 conventions that just casts the last parameter and then calls the new function (in C++, you can have 2 functions with the same name as long as they take different parameters). The apt hang was caused by the missing #include I added earlier: Since the inline function didn't know about the "real" rpmdsSingle (because of the missing include), it just kept calling itself (a cast from an enum (such as evrFlags) to an int is automatic, while a cast from an enum to int is not). If the function knows about the real one (which it does after #include ), it sees that the real one is a better match for what it is calling, and therefore calls that as opposed to itself -- which is the intended behavior. __ RPM Package Managerhttp://rpm5.org Developer Communication Listrpm-devel@rpm5.org
rpm5 and apt-rpm: Almost working
Hi, I finally got around to fixing various problems with apt-rpm when used with rpm5 -- the last being "apt-get update" hanging because of a bug in rpm4compat.h. Now it gets the lists and starts resolving dependencies, but it complains about the rpm internal dependencies for loads of installed packages: The following packages have unmet dependencies: ImageMagick: Depends: VersionedDependencies (<= 3.0.3-1) but it is not installable Depends: PayloadFilesHavePrefix (<= 4.0-1) but it is not installable Depends: CompressedFileNames (<= 3.0.4-1) but it is not installable Depends: PayloadIsBzip2 (<= 3.0.5-1) but it is not installable apr: Depends: PayloadIsLzma (<= 4.4.6-1) but it is not installable [...] Of course, the crude hack approach to get it up and running is adding Provides: VersionedDependencies = 3.0.3-1 Provides: PayloadFilesHavePrefix = 4.0-1 to the rpm5 spec file, but I prefer to stay off junk like that. Before digging deeper, does anyone have any ideas why apt is seeing those bogus requirements instead of the correct rpmlib(PayloadIsBzip2) <= 3.0.5-1 type deps? (The packages are ok, rpm --requires shows the correct deps.) ttyl bero __ RPM Package Managerhttp://rpm5.org Developer Communication Listrpm-devel@rpm5.org
rpm5 incompatibility with old rpm: globs no longer include dangling symlinks
In older rpm versions, this spec fragment would cause %_bindir/someapp to be included: %install make install # consolehelper comes from a different package, therefore the symlink # being created here is dangling ln -s consolehelper $RPM_BUILD_ROOT%_bindir/someapp %files %_bindir/* In 5.1.4 (and probably older rpm5 versions), the dangling symlink is omitted and listed in "warning: Installed (but unpackaged) file(s) found". Probably an lstat() somewhere was changed to stat()... Listing %_bindir/someapp explicitly still packages it. Is this an intentional change (because dangling symlinks can be rather unwanted), or a bug? ttyl bero __ RPM Package Managerhttp://rpm5.org Developer Communication Listrpm-devel@rpm5.org
Re: rpm 5.1.3 fails to see a subpackage definition
On Thursday 19 June 2008 14:16:54 Jeff Johnson wrote: > Hmmm, here's a different issue with the package. LZMA payload > identification and/or decompression will need to be looked at as well: Weird, it installs just fine here. Maybe it's an incompatibility between different lzma-utils versions, the one I'm using is a fairly recent (June 12th) git snapshot. I've uploaded the package again (same address) with bzip2 compression. ttyl bero __ RPM Package Managerhttp://rpm5.org Developer Communication Listrpm-devel@rpm5.org
rpm 5.1.3 fails to see a subpackage definition
Trying to rebuild http://arklinux.org/~bero/kdelibs-4.1.0-0.822040.1ark.src.rpm with rpm 5.1.3 results in error: line 106: Package does not exist: %description -n kimgio-exr However, line 100 of the spec file does define that package unconditionally. The same package worked with older rpm versions. ttyl bero __ RPM Package Managerhttp://rpm5.org Developer Communication Listrpm-devel@rpm5.org
Re: rpm 5.1.2: apt-get crash with lua, and forgetting --target parameters
On Saturday 14 June 2008 16.44:57 Bernhard Rosenkränzer wrote:
> In the particular case of apt, there's another thing I just noticed -- both
> rpm and apt come with an internalized version of lua.
> Chances are the simple symbol clash caused by this is what causes the
> crash. Guess switching both over to using system lua (or at least making
> apt use rpm's version) is the best fix.
That did it -- if anyone is interested, here's a patch to link apt against
system lua 5.1.x, that makes it work with rpm5 if the latter is compiled with
external lua as well.
It doesn't fix genpkglist crashing though, so that must be a different
problem.
ttyl
bero
--- apt-0.5.15lorg3.94a/apt-pkg/luaiface.cc.lua~ 2008-01-12 10:45:07.0 +0100
+++ apt-0.5.15lorg3.94a/apt-pkg/luaiface.cc 2008-06-14 21:26:46.0 +0200
@@ -17,12 +17,12 @@
#ifdef APT_WITH_LUA
extern "C" {
-#include "lua.h"
-#include "lualib.h"
-#include "lauxlib.h"
-#include "lposix.h"
-#include "lrexlib.h"
-#include "linit.h"
+#include
+#include
+#include
+#if LUA_VERSION_NUM < 501
+#error lua 5.1 required
+#endif
}
#include
@@ -52,12 +52,9 @@ extern "C" {
} while (0)
#define checkudata(ctype, target, n) \
- do { \
- ctype *_tmp = (ctype *) luaL_checkudata(L, n, #ctype); \
- if (_tmp != NULL) \
- target = *_tmp; \
- else \
- target = NULL; \
+ do { ctype *_tmp; target = NULL; \
+ if ( !lua_isnil(L, n) && (_tmp = (ctype *) luaL_checkudata(L, n, #ctype)) ) \
+ target = *_tmp; \
} while (0)
Lua *_GetLuaObj()
@@ -78,26 +75,13 @@ Lua::Lua()
{
_config->CndSet("Dir::Bin::scripts", PKGDATADIR "/scripts");
- const luaL_reg lualibs[] = {
- {"base", luaopen_base},
- {"table", luaopen_table},
- {"io", luaopen_io},
- {"string", luaopen_string},
- {"math", luaopen_math},
- {"debug", luaopen_debug},
- {"loadlib", luaopen_loadlib},
- {"posix", luaopen_posix},
- {"rex", luaopen_rex},
- {"init", luaopen_init},
- {"apt", luaopen_apt},
- {NULL, NULL}
- };
L = lua_open();
- const luaL_reg *lib = lualibs;
- for (; lib->name; lib++) {
- lib->func(L); /* open library */
- lua_settop(L, 0); /* discard any results */
- }
+ luaL_openlibs(L);
+
+ lua_pushcfunction(L, luaopen_apt);
+ lua_pushstring(L, "apt");
+ lua_call(L, 1, 0);
+
luaL_newmetatable(L, "pkgCache::Package*");
lua_pushstring(L, "__eq");
lua_pushcfunction(L, AptLua_pkgcomp);
@@ -198,7 +182,7 @@ bool Lua::RunScripts(const char *ConfLis
lua_pushnil(L);
lua_rawset(L, LUA_GLOBALSINDEX);
- lua_pop(L, 1);
+ lua_settop(L, 0);
return true;
}
--- apt-0.5.15lorg3.94a/apt-pkg/Makefile.am.lua~ 2008-01-12 10:45:07.0 +0100
+++ apt-0.5.15lorg3.94a/apt-pkg/Makefile.am 2008-06-14 21:28:25.0 +0200
@@ -10,10 +10,9 @@ libapt_pkg_la_LDFLAGS = -version-info 3:
AM_CPPFLAGS = -DLIBDIR=\"$(libdir)\" -DPKGDATADIR=\"$(pkgdatadir)\"
AM_CPPFLAGS += -DLOCALEDIR=\"$(localedir)\" -DAPT_DOMAIN=\"$(PACKAGE)\"
-AM_CPPFLAGS += -I$(top_srcdir)/lua/include -I$(top_srcdir)/lua/local
if WITH_LUA
-libapt_pkg_la_LIBADD += $(top_builddir)/lua/liblua.la
+libapt_pkg_la_LIBADD += -llua
endif
libapt_pkg_la_SOURCES = \
--- apt-0.5.15lorg3.94a/configure.ac.lua~ 2008-01-12 11:11:39.0 +0100
+++ apt-0.5.15lorg3.94a/configure.ac 2008-06-14 21:27:50.0 +0200
@@ -311,7 +311,6 @@ dnl ah_GCC3DEP
AC_CONFIG_FILES([
Makefile
- lua/Makefile
apt-pkg/Makefile
apt-pkg/libapt-pkg.pc
methods/Makefile
--- apt-0.5.15lorg3.94a/Makefile.am.lua~ 2008-01-12 10:45:07.0 +0100
+++ apt-0.5.15lorg3.94a/Makefile.am 2008-06-14 21:28:01.0 +0200
@@ -1,5 +1,5 @@
-SUBDIRS = lua apt-pkg methods cmdline tools doc po
+SUBDIRS = apt-pkg methods cmdline tools doc po
SUBDIRS += test
ACLOCAL_AMFLAGS = -I m4 -I buildlib
Re: rpm 5.1.2: apt-get crash with lua, and forgetting --target parameters
On Saturday 14 June 2008 15.55:21 Jeff Johnson wrote: > There's a class of peculier issues with initializing under bindings > and applications because the code paths are rather different. I get > burned by the library <-> executable initialization differences > frequently. In the particular case of apt, there's another thing I just noticed -- both rpm and apt come with an internalized version of lua. Chances are the simple symbol clash caused by this is what causes the crash. Guess switching both over to using system lua (or at least making apt use rpm's version) is the best fix. > Guessing from "rpmSystem::Score" names: > If apt is attempting rpmPlatformScore(), then patterns need to be > added to /etc/rpm/platform. It isn't -- rpmSystem::Score simply checks if rpm is installed and returns a matching score to make sure rpmSystem::Score > dpkgSystem::Score, so rpm gets used over other low level package managers. ttyl bero __ RPM Package Managerhttp://rpm5.org Developer Communication Listrpm-devel@rpm5.org
