On Jul 25, 2007, at 4:02 PM, Ralf S. Engelschall wrote:
On Wed, Jul 25, 2007, Jeff Johnson wrote:
These days its easier to have multi-threaded scripts than thread-safe
libraries.
So rpmlib gets put on threads even though the library is not, and
has never
claimed, to be thread safe
On Jul 25, 2007, at 4:35 PM, Ralf S. Engelschall wrote:
On Wed, Jul 25, 2007, Jeff Johnson wrote:
On Jul 25, 2007, at 4:02 PM, Ralf S. Engelschall wrote:
On Wed, Jul 25, 2007, Jeff Johnson wrote:
These days its easier to have multi-threaded scripts than thread-
safe
libraries.
So rpmlib
On Jul 25, 2007, at 4:25 PM, Ralf S. Engelschall wrote:
On Wed, Jul 25, 2007, Jeff Johnson wrote:
On Jul 25, 2007, at 3:59 PM, Ralf S. Engelschall wrote:
Ralf: We again are at cross purposes, sigh. You know where I
would do the
dirty ...
I'm just fine with such a, say tool/db_tool.c
On Jul 25, 2007, at 3:59 PM, Ralf S. Engelschall wrote:
Ralf: We again are at cross purposes, sigh. You know where I would
do the
dirty ...
I'm just fine with such a, say tool/db_tool.c, which integrates
all the db_xxx.c into a single tool. Let me investigate, perhaps
I can hack
Please examine the RPMTAG_DBINSTANCE patch. Adding a header extension
does not come any simpler than this, and attaching meta-meta-data
with, rather than in,
a package header is increasingly an important implementation paradigm
for rpm
Meanwhile, the reason for the implementation (aside
On Jul 23, 2007, at 4:27 PM, Ralf S. Engelschall wrote:
I'll look at what is needed to make both --foo=bar and --foo bar
work with
popt alias/exec this evening.
This would be cool. It is rather confusing that one cannot use the
--foo=bar notation, especially as the native POPT options
In order to minimize file conflicts with existing vendor packaging,
traditional
rpm configuration has been moved into a rpm-common package containing
what used to be installed in /usr/lib/rpm, while almost everything
specific to
rpm-4.5 has been pushed into /usr/lib/rpm/4.5.
All in order to
In order to continue to control rpm versioning, its time to get an
rpm-4.5 release finalized imho.
Most of the changes necessary to install rpm-4.5 side-by-side with
vendor rpm
have already been accomplished in June.
Meanwhile, stabilizing rpm-5.0 builds has been the recent priority. I'm
Sigh, its alwaus somethin:
[EMAIL PROTECTED] wdj]$ rpm -qa
error: cannot open Packages index using db3 - Invalid argument (22)
error: cannot open Packages database in /var/lib/rpm
[EMAIL PROTECTED] wdj]$ sudo rpm -q popt
rpmdb: /var/lib/rpm/Packages: unsupported hash version: 9
error: cannot
On Jul 26, 2007, at 2:05 PM, Michael Jennings wrote:
On Thursday, 26 July 2007, at 11:43:12 (-0400),
Jeff Johnson wrote:
In order to continue to control rpm versioning, its time to get an
rpm-4.5 release finalized imho.
rpm-4.5-0.4 does not build on x86_64 at present. I worked around
I'm looking at bloatery removal with /usr/lib/rpm/db_foo, each one
of those executables currently contains Its Own Private Berkeley DB.
All those utilities can be combined into one executable, thereby
eliminating
multiple copies of Berkeley DB included in utilities.
Doing something like
On Jul 25, 2007, at 3:30 PM, Jason Corley wrote:
Could the AC_MSG_ERROR dump a URL to the online archive of the commit
message (or discussion of issue or whatever) about removal or
something similar? Not sure how much details you can put into the
standard auto-fu.
Hehe, Inquiring Minds
Hmmm, on a rpm-4_5 checkout, I'm seeing this
$ ./devtool prepare
=== db (cvs co HEAD)
Enter passphrase for key '/home/jbj/.ssh/id_dsa':
cvs checkout: Updating db
U db/LICENSE
U db/README
cvs checkout: Updating db/btree
even though I'm trying to check out on the
On Jul 27, 2007, at 3:16 AM, Ralf S. Engelschall wrote:
Does anyone mind if I rework it completly ?
Go for it! I guess everyone is happy if you investigate on the perl/
subdir and make it working out-of-the-box under --with-perl. I even
would suggest that you _merge in_ your RPM4 API into
On Jul 27, 2007, at 11:22 AM, Ralf S. Engelschall wrote:
I've sync'ed the devtool stuff with HEAD and I don't see why this
happens?
I can easily live with
for d in db file lua zlib; do cd $d cvs up -r rpm-4.5 -d -P;
cd ..; done
for building rpm-4.5 packages. rpm.spec hackery is
On Jul 27, 2007, at 12:21 PM, Jeff Johnson wrote:
Digging ...
My brain fart, too many windows, too many versions, too many
machines ...
73 de Jeff
__
RPM Package Managerhttp://rpm5
Because I get tired of looking at same old rpm -qa sopew, I usually
run a tricked up queryformat that looks much like a package file name.
One of the consequences of that is I end up looking at different
rpm -qa spewage than y'all.
So I just noticed
libXinerama-devel-1.0.2-1.fc7.i386
Now that I actually have my brain fart under control, db-4.6.18 is
headed
back onto HEAD this weekend.
I can trivially bundle that into rpm-4.5 and expect no problems.
The reason for doing so is to avoid doing so is the
tedious flip-flopping between Berkeley DB versions.
Any reservations on
On Jul 27, 2007, at 2:17 PM, Michael Jennings wrote:
On Thursday, 26 July 2007, at 11:55:35 (-0400),
Jeff Johnson wrote:
Read rpmrc files or not?
Not. It's a minimal compatibility gain for a big step backward. We
should try to get as close as possible out-of-the-box in terms of
platform
On Jul 27, 2007, at 2:01 PM, Robert Scheck wrote:
On Fri, 27 Jul 2007, Jeff Johnson wrote:
Any reservations on bundling db-4.6.18 into db-4.5?
Assuming you mean rpm-4.5 rather db-4.5, otherwise this sentence
doesn't
make sense to me.
Yes. Watch for me to type db-2.6 rather than db-4.6
On Jul 27, 2007, at 4:44 PM, Michael Jennings wrote:
On Wednesday, 11 July 2007, at 11:40:15 (+0200),
Michael Schroeder wrote:
Uh, not 002 please, 022 is the standard. Make it configurable if you
really need to do something like that.
Wouldn't this prevent the creation of group-writable
On Jul 27, 2007, at 7:15 PM, Michael Jennings wrote:
Something to turn instroot tarballs/images into RPM's?
Been on my todo list since November 2005, no worry.
Adding tar payloads was just proof-of-concept ...
73 de Jeff
On Jul 27, 2007, at 7:20 PM, Michael Jennings wrote:
On Friday, 27 July 2007, at 16:46:43 (-0400),
Jeff Johnson wrote:
But 0022 is the default setting, certainly choosing the uglix
standard default is the least surprising choice that meets the
largest number of expectations.
On systems
On Jul 24, 2007, at 4:47 PM, Ralf S. Engelschall wrote:
On Tue, Jul 24, 2007, Jeff Johnson wrote:
On Jul 24, 2007, at 4:21 PM, Ralf S. Engelschall wrote:
Just go for it: upgrade the db/ subdir to DB 4.6.18!
You've seen my (ahem) cvs methods.
Ohh, well, yes, seems like I've
I've also done
cd /v/rpm/cvs
mv db db-ORIG
mv db46 db
HEAD builds fine, rpm-4_5 not quite, with db-4.6.18.
73 de Jeff
On Jul 28, 2007, at 10:23 PM, Jeff Johnson wrote:
On Jul 24, 2007, at 4:47 PM, Ralf S. Engelschall wrote:
On Tue, Jul 24, 2007, Jeff Johnson wrote:
On Jul 24
Not setting the return code from pthread_mutexattr_setrobust_np()
is likely the fix for interoperability with glibc/kernel that does not
support robust mutexes but does define EOWNERDEAD:
+#if defined(EOWNERDEAD)
RET_SET((pthread_mutexattr_init(mutexattr)), ret);
+
On Jul 29, 2007, at 11:42 AM, Ralf S. Engelschall wrote:
Jeff, can you investigate on this remaining issue, please?
Already investigated.
Guaranteeing that a rpmdb is closed gracefully under all possible
conditions is a fool's implementation.
Consider segfaults, kill -9, reboot, more.
| $ /tmp/rpm/bin/rpm -e gpg-pubkey-2039b291-3dbaae72
| error: ^2039b291$: regcomp failed:
| error: package gpg-pubkey-2039b291-3dbaae72 is not installed
| $ /tmp/rpm/bin/rpm -qa
| Freeing locks for locker 0xe: 22298/0
| Freeing locks for locker 0xf: 22298/0
| Freeing locks for locker 0x10:
On Jul 29, 2007, at 12:47 PM, Ralf S. Engelschall wrote:
On Sun, Jul 29, 2007, Jeff Johnson wrote:
Jeff, can you investigate on this remaining issue, please?
Already investigated.
Guaranteeing that a rpmdb is closed gracefully under all possible
conditions is a fool's implementation
A reminder: rpm man pages are in docbook under max-rpm ...
73 de Jeff
On Jul 29, 2007, at 2:47 PM, Ralf S. Engelschall wrote:
RPM Package Manager, CVS Repository
http://rpm5.org/cvs/
__
__
Server: rpm5.org
The dbenv is stateful, and per-instance. Why are you copying __db*
files around, they are useless, as you have seen, out of context.
73 de Jeff
On Jul 29, 2007, at 3:13 PM, Ralf S. Engelschall wrote:
Just a heads up for those of you who create the RPM DB in a temporary
location (like DESTDIR)
The option has been unnecessary in all but an obscure --root corner
case since Berkeley DB has been used.
Shall we finally eliminate the option?
73 de Jeff
__
RPM Package Manager
But then there is the other direction, lusers are surprised
that lazy mkdirs are done, with lazy rpmdb creattion as well:
rpm -qa --dbpath /tmp/XyZ
ls -al /tmp/XyZ
I've been going in booth legacy compatible strict and forward
looking loose
directions for years simultaneously.
Make
On Jul 29, 2007, at 5:00 PM, Jeff Johnson wrote:
Can we attempt run-time rather than compile time?
Truly, 3 ways in the API to open an rpmdb, none of which
take a path to the rpmdb, is rather odd.
I'd go radically the other way as well. Aside from path (and too
many options to ever manage
On Jul 30, 2007, at 7:44 AM, Thomas Lotterer wrote:
Please keep. I recently succeeded with my personal BDB example case
(will post details of my failures later) but one issue remains. It
seems
to me all the locking stuff does not work reliably for DB_CREATE. If
multiple processes try this
On Jul 30, 2007, at 11:20 AM, Jeff Johnson wrote:
Phasing out support for header+payload signatures needs to happen.
Attached is a the start of the patch to nuke RPMv3 signature support.
Yes, certain things, like preserving tag names/values in rpmlib.h,
needs to be
done more carefully
I've built rpm-4.5-0.5 packages at
http://wraptastic.org/pub/i386-linux
Aside from adjusting package spec files, I was mainly interested in
finalizing
1) @USRLIBRPM/@VERSION@ aka /usr/lib/rpm/4.5 contents
2) creating a rpm-common package to carry contents like CPU-OS/
macros
My first goal will be to strip 2 items that XAR does not have, the
rpm lead and
signature header. The lead will be discarded, the signature tags will be
appended to the metadata header (which is what currently happens now
when a *.rpm package is read, see headerMergeLegacySigs in lib/
On Jul 30, 2007, at 2:58 PM, Thomas Lotterer wrote:
Call for rpm5.org architectural decision.
On Saturday, 28. July 2007 at 10:49 pm, Thomas Lotterer wrote:
I want to suggest we create and maintain a document describing
architectural decisions of rpm5.org. [...]
- one decision I'd like to
On Jul 31, 2007, at 5:02 AM, Thomas Lotterer wrote:
On Monday, 30. July 2007 at 9:26 pm, Jeff Johnson [EMAIL PROTECTED]
wrote:
On Jul 30, 2007, at 2:58 PM, Thomas Lotterer wrote:
Decision:
- exclusively use Berkeley DB
I'd change exclusively to primarily. Otherwise we have an
external
On Jul 31, 2007, at 9:04 AM, Jeff Johnson wrote:
I believe fcntl locking is fine, but have not investigated. We
could flip to fcntl
locking on HEAD for a month or so to insure there are no surprises.
I do
think NPTL locking, when available, is the better implementation going
forward
On Jul 31, 2007, at 3:32 PM, Thomas Lotterer wrote:
On Tuesday, 31. July 2007 at 3:04 pm, Jeff Johnson wrote:
On Jul 31, 2007, at 5:02 AM, Thomas Lotterer wrote:
On Monday, 30. July 2007 at 9:26 pm, Jeff Johnson wrote:
On Jul 30, 2007, at 2:58 PM, Thomas Lotterer wrote:
Decision
On Jul 31, 2007, at 6:18 PM, Mark Hatle wrote:
Jeff Johnson wrote:
There is also the existing %_solve_dbpath. There is a need for a
per-rpmts
database for headers passed to rpmtsAddInstallElement that could/
should
be used to eliminate the nasty code with a largish in-memory
footprint
On Jul 31, 2007, at 6:34 PM, Mark Hatle wrote:
Jeff Johnson wrote:
On Jul 31, 2007, at 2:40 PM, Mark Hatle wrote:
From a brief reading of the thread, the one item that popped up that
would be nice to figure out a solution for is in:
https://www.redhat.com/archives/fedora-devel-list/2007
On Jul 31, 2007, at 6:39 PM, Mark Hatle wrote:
Thomas Lotterer wrote:
On Tuesday, 31. July 2007 at 3:04 pm, Jeff Johnson wrote:
On Jul 31, 2007, at 5:02 AM, Thomas Lotterer wrote:
On Monday, 30. July 2007 at 9:26 pm, Jeff Johnson wrote:
On Jul 30, 2007, at 2:58 PM, Thomas Lotterer wrote
On Aug 1, 2007, at 10:23 AM, Ralf S. Engelschall wrote:
On Wed, Aug 01, 2007, Jeff Johnson wrote:
hack-a-round to make __FUNCTION__ useful on linux.
Jeff, can you provide details of what problem you were faced with?
Because under Linux you usually always have GCC and GCC provides
On Aug 1, 2007, at 11:07 AM, Ralf S. Engelschall wrote:
On Wed, Aug 01, 2007, Jeff Johnson wrote:
On Aug 1, 2007, at 10:23 AM, Ralf S. Engelschall wrote:
On Wed, Aug 01, 2007, Jeff Johnson wrote:
hack-a-round to make __FUNCTION__ useful on linux.
Jeff, can you provide details
On Aug 1, 2007, at 11:11 AM, Jeff Johnson wrote:
Sure, entirely and trivially fixable. I just want debugging msgs
today, the pedantry
is important too.
FWIW, changing the handful of debugging msgs, possibly eliminating
the debugging
entirely, to change
fprintf(stderr, %s
If we're gonna link PCRE, its perfectly predicatble that flavors of
regex's will be desired. Extending mire.c with a new type of matching
is what I suggest.
rpmsx is doomed and should be ripped, libselinux now exposes
a better API.
73 de Jeff
On Aug 1, 2007, at 11:55 AM, Ralf S. Engelschall
On Aug 1, 2007, at 12:10 PM, Ralf S. Engelschall wrote:
On Wed, Aug 01, 2007, Jeff Johnson wrote:
If we're gonna link PCRE, its perfectly predicatble that flavors of
regex's will be desired.
Yes, this was my second intention, too.
The first intentation was to just make PCRE available
On Aug 1, 2007, at 12:52 PM, Jeff Johnson wrote:
rpmmire started off life as a way to support query's with patterns.
The functionality is entirely undocumented but quite general.
E.g.
rpm -qa 'arch=!i[3456]86'
will list everything but the platforms that match.
There are several flaws
On Aug 1, 2007, at 4:03 PM, Mark Hatle wrote:
SQLite has a locking mechanism that will work on shared filesystems
(w/
proper locking.) Ignore NFS.. thats just one way to get a shared
filesystem, but not the only way.) The assumption here is we have a
shared filesystem w/ proper file
On Aug 1, 2007, at 5:38 PM, Thomas Lotterer wrote:
On Wednesday, 1. August 2007 at 11:11 pm, Jeff Johnson wrote:
what is this abstraction layer
In order to support an alternative DB the following approaches
came to
my mind:
1.) find a replacement that offers exactly the same API
On Aug 1, 2007, at 6:22 PM, Olivier Thauvin wrote:
I ask here just in case someone have an idea.
On mandriva, we're using rpm 4.4.8. Just after a fresh install
(cooker), when
trying to install a package, we get, sometimes, this message:
rpmdb: Requirename: bad page number #
The same for
On Aug 2, 2007, at 7:40 AM, Thomas Lotterer wrote:
On Thursday, 2. August 2007 at 12:22 am, Jeff Johnson wrote:
On Aug 1, 2007, at 5:38 PM, Thomas Lotterer wrote:
On Wednesday, 1. August 2007 at 11:11 pm, Jeff Johnson wrote:
what is this abstraction layer
Now thanks to your explanations
On Jul 30, 2007, at 12:26 PM, Jeff Johnson wrote:
On Jul 30, 2007, at 11:20 AM, Jeff Johnson wrote:
Phasing out support for header+payload signatures needs to happen.
Attached is a the start of the patch to nuke RPMv3 signature support.
I've heard nothing regarding this patch, which
On Aug 6, 2007, at 8:55 AM, Olivier Thauvin wrote:
Le lundi 6 août 2007, Ralf S. Engelschall a écrit :
RPM Package Manager, CVS Repository
http://rpm5.org/cvs/
- perl/typemap \
+ perl/MANIFEST perl/META.yml perl/Makefile.PL.in perl/Makefile.am
perl/Makefile.in \ +
On Aug 7, 2007, at 4:45 PM, Jay Soffian wrote:
What say ye?
This is against 4.5, correct? Will v3 packages still be installable
with 4.5 using --nosignature?
Likely against rpm-4_5, but the change is generic.
Signatures != installing. No --nosignature option will be necessary,
the
On Aug 8, 2007, at 12:53 PM, Mark Hatle wrote:
I'm trying to use lua to implement some complex transaction scripts..
specifically adduser, addgroup and chkconfig functionalities. Due
to my
cross compile environment, I can't actually execute the adduser,
addgroup or chkconfig command line
On Aug 8, 2007, at 5:26 PM, Olivier Thauvin wrote:
I just understood the real issue:
rpmdsNext() does now more things than rpmdsSetIx(), eg rpmdsNext
set the
internal rpmns struct into ds but rpmdsSetIx only set ds-i.
The result is when you're using SetIx() you never get next
On Aug 8, 2007, at 6:06 PM, Jeff Johnson wrote:
anymore: rpm-2.2.0 was released in 1997.
Actually, the 2.2.0 is likely from @VERSION@ pollution
from internal beecrypt, I dimly remember that 5+ yearold problem.
The package was definitely produced by rpm-3.0.4 or later
because files
On Aug 8, 2007, at 4:41 PM, Olivier Thauvin wrote:
I was trying to write some test over my perl module and so I likelly
do:
dep = rpmdsNew(a_header);
dep2 = rpmdsNew(a_header);
rpmdsCompare(dep, dep2);
But then I get:
rpmds.c:3635: rpmdsCompare: l'assertion « (rpmdsFlags(B) 0x0e) ==
On Aug 10, 2007, at 2:32 PM, Anders F Björklund wrote:
There seems to be a power struggle between beecrypt and rpm,
in who gets first to typedef the declaration of a byte...
Yep, been there ...
Nuking byte everywhere in rpm (there are some hash's in rpmio that
should
follow beecrypt,
On Aug 10, 2007, at 5:23 PM, Anders F Björklund wrote:
I wonder if I shouldn't turn %_repackage_all_erasures off too, or if
it
offers any advantages I'm unaware of to the casual RPM user on Mac
OS X ?
All depends on perception of advantage.
That's why the behavior can be cahnged
On Aug 11, 2007, at 5:45 PM, Robert Scheck wrote:
Evening folks,
it looks like that 4.5-0.5 is a bit broken regarding the use of --
force:
Not broken, but not functional either. This fixes, so does using --
replacepkgs instead of --force
--- rpmpopt.in 10 Jun 2007 23:09:05 -
Robert Scheck asked why dependencies in a spec file were not being
displayed
in Requires: after a build.
The patch below displays Requires: that are also in the spec file.
In all cases the dependencies are in the binary package, the issue is
choosing which Requires: to display.
I'm not gonna
Be careful of the side effect.
If an rpmdb is open'ed manually, that disables lazy opens.
73 de Jeff
On Aug 14, 2007, at 11:28 AM, Olivier Thauvin wrote:
RPM Package Manager, CVS Repository
http://rpm5.org/cvs/
__
As threatened here
https://lists.dulug.duke.edu/pipermail/rpm-devel/2007-May/
002677.html
I've marked RPMv3 header+payload signing code and defaulted to not
compile.
The next issue will be to secure the header+payload MD5 digest by
including
in the signed metadata header, not as a
:emm get a subject line on the previous ...
73 de Jeff
On Aug 14, 2007, at 2:07 PM, Jeff Johnson wrote:
As threatened here
https://lists.dulug.duke.edu/pipermail/rpm-devel/2007-May/
002677.html
I've marked RPMv3 header+payload signing code and defaulted to not
compile.
The next issue
On Aug 16, 2007, at 10:18 AM, Jason Corley wrote:
I'm trying to get on the devtool bandwagon with a variation of the
standalone target for my own nefarious purposes. Would there be any
objection to a patch like the attached that splits out all of the
dependency software version and dist
In case you missed the significance, I've added db-4.6.19 to rpm HEAD,
and changed rpm-4.5 to use, in the last 24 hours.
Enjoy!
73 de Jeff
smime.p7s
Description: S/MIME cryptographic signature
On Aug 17, 2007, at 4:05 PM, Robert Scheck wrote:
As far as I can see, the Fedora guys don't have this problem after
they
applied an own (non-upstream) patch to the spec file of zlib, see:
http://cvs.fedoraproject.org/viewcvs/devel/zlib/zlib.spec?view=markup
Is there anything which would
On Aug 17, 2007, at 4:05 PM, Robert Scheck wrote:
As far as I can see, the Fedora guys don't have this problem after
they
applied an own (non-upstream) patch to the spec file of zlib, see:
http://cvs.fedoraproject.org/viewcvs/devel/zlib/zlib.spec?view=markup
Is there anything which would
On Aug 17, 2007, at 9:51 PM, Olivier Thauvin wrote:
After a short discussion on irc with Jeff, I decide to work on the
part I know
the best: build/.
My goal is to provide a way to cleanly build a packages (so many
packages) for
many architectures (--target foo --target bar) in
On Aug 19, 2007, at 3:28 AM, Andy Green wrote:
Hi Jeff -
OK. So you want a build system tool able to build package(s) for
multiple target platforms.
You need to look at the fundamental design issue first:
Multiple target platforms (in general) is more than i[3456]86
targets,
and
On Aug 19, 2007, at 1:45 PM, Andy Green wrote:
There are many reasons to attempt remote execution of build
scriptlets, not
just to have %{_target_cpu} on remote != local.
Well I can't say anything about these other uses because they are
out of
scope for my experience.
I was
Let's say you have a tree of packages that you want to check signatures:
rpm -Kvv --ftswalk /path/to/tree
Signing/verofying all *.rpm packages found in a tree should now be
functional on HEAD.
The --ftswalk,-W option has been available with queries for quite a
while.
Sure to be some
On Aug 20, 2007, at 11:53 AM, Mark Hatle wrote:
One bit of advice to folks doing this.. use the %build and %install
override macros and seed your environment w/ CC, LD, etc values
there...
Override the %configure macro w/ one that specifies the correst build
and target.. and many things
On Aug 24, 2007, at 4:28 PM, Ralf S. Engelschall wrote:
On Sat, Aug 18, 2007, Jeff Johnson wrote:
add -Wall to automake options to see problems.
use the implict automake generated rule for librpmz.la, no
need to override.
librpmz_la_LDFLAGS =
-librpmz.la
On Aug 24, 2007, at 4:58 PM, Dmitry V. Levin wrote:
On Fri, Aug 24, 2007 at 10:45:29PM +0200, Ralf S. Engelschall wrote:
On Sun, Aug 12, 2007, Dmitry V. Levin wrote:
We probably need this change, too:
http://hg.rpm.org/rpm-4.4.x?cs=1a3109298938
We cannot generally assume that the tar(1)
On Aug 25, 2007, at 1:52 PM, Anders F Björklund wrote:
When I am building a program against rpm libraries,
I get an error due to WITH_DB not being defined...
/usr/local/include/rpm/rpmdb.h:16:20:
error: db_emu.h: No such file or directory
If those are supposed to be known, shouldn't they
be
On Aug 25, 2007, at 2:04 PM, Anders F Björklund wrote:
When building/using RPM with an static/internal popt,
is it OK to include the required popt.h in rpm/ ?
Several of the RPM headers requires popt.h, so I will
need to install it (somewhere) for them to work...
I could of course copy it
On Aug 25, 2007, at 2:07 PM, Anders F Björklund wrote:
When I am building a program against rpm libraries,
I get an error due to WITH_DB not being defined...
/usr/local/include/rpm/rpmdb.h:16:20:
Is this an external or internal program that needs
#include rpmdb.h
The fixing is different
On Aug 28, 2007, at 10:51 AM, Anders F Björklund wrote:
Jeff Johnson wrote:
I'm also interested in using the Mac OS X keyring in ways similar
to how keyutils
is going to be used. Does anyone have a ptr to a reasonable
implementation
in some non-interpreted language?
The only pointer I
One of the yet unsolved collisions with rpm.org - rpm5.org
coexistence is
the i18n domain rpm.
So far, I've begged the question by waving my hands and dumping *.gmo
files into a rpm-common contyainer.
A better solution using a FUSE mount -bind at run time to overlay
rpm.org's
On Aug 31, 2007, at 10:57 AM, Anders F Björklund wrote:
Jeff Johnson wrote:
My personal preference (today expect quixotic behavior) would be to
replace
the test-harness driver with devtool, and add some additional
stanzas to generate
test manifests using the globs from trpm.
But I'd
On Sep 5, 2007, at 3:24 PM, Ralf S. Engelschall wrote:
With the latest RPM 5 as of this evening:
| $ rm -rf /tmp/rpm/var/rpm/db/*
| $ /tmp/rpm/bin/rpm --initdb
| $ /tmp/rpm/bin/rpm -qa
| $ /tmp/rpm/bin/rpm --import pubkeys/JBJ-GPG-KEY
| $ /tmp/rpm/bin/rpm -qa
|
On Sep 8, 2007, at 3:24 AM, Ralf S. Engelschall wrote:
Ah, sorry, I overlooked that this is on the RPM_4_5 branch.
Ok, sorry, there it might make sense, of course.
No sense, but expedient, just like the make %{smpflags} changes.
73 de Jeff
that I would like a professional and
maintainable
implementation.
73 de Jeff
On Aug 28, 2007, at 10:40 AM, Jeff Johnson wrote:
I finally got back to figuring keyutils last week.
HEAD now uses keyutils to get the cached gpg (and eventually pgp/pgp5)
signing password out of rpm's process address
Berkeley DB 4.6.19 appears to be caching (and using) paths
within a dbenv, which breaks lazy table opens using rpm --root in
rather complicated ways. The fundamental cause is simply that
sometimes file paths need prefixing, and sometimes not.
The quick-n-dirty workaround if you are making
OK, its time to change the rationale for continuing to carry --initdb.
Please show me a usage case for continuing to carry --initdb, which
I will likely fix in other ways immediately.
If I don't hear a plausible usage case in the next couple of weeks,
I will zap --initdb.
Note: I don't
Begin forwarded message:
From: Jeff Johnson [EMAIL PROTECTED]
Date: September 30, 2007 12:02:30 PM EDT
To: Arkadiusz Patyk [EMAIL PROTECTED]
Cc: rpm-devel@rpm5.org
Subject: Re: LUA script in preun - upgrade/uninstall detect problem
On Sep 30, 2007, at 10:38 AM, Arkadiusz Patyk wrote
On Sep 30, 2007, at 10:38 AM, Arkadiusz Patyk wrote:
On Sun, 30 Sep 2007 09:38:17 -0400, you wrote:
On Sep 29, 2007, at 6:48 PM, Arkadiusz Patyk wrote:
Hi,
I'am trying to change sh script into lua in pdksh.spec
http://cvs.pld-linux.org/cgi-bin/cvsweb.cgi/SPECS/pdksh.spec
How I can
On Oct 1, 2007, at 9:52 PM, Olivier Thauvin wrote:
I will sync perl module with latest API changes ASAP.
Be lazy. ;-) I'm trying to remove the need to pass ts into librpmdb and
librpmio if possible. There's sure to be more breakge.
73 de Jeff
I'll have this fixed shortly:
==9862==
==9862== Invalid write of size 1
==9862==at 0x4976E39: pgpPrtPkts (rpmpgp.c:1293)
==9862==by 0x488C7F8: rpmReadPackageFile (package.c:393)
==9862==by 0x48B1878: rpmgiReadHeader (rpmgi.c:142)
==9862==by 0x48B19EE: rpmgiLoadReadHeader
PLD has a patch adding a macro to specify patterns to filter internally
generated soname dependencies.
Basically
%define _noautorequires libA.so libB.so
with some regex gunk in lib/rpmfc.c to do essentially grep -v.
Should it be added?
My personal opinion is that per-pkg filtering of
On Oct 2, 2007, at 11:28 AM, Jason Corley wrote:
$ /usr/local/bin/rpm -qpl ecj-3.3-1jpp.noarch.rpm
warning: ecj-3.3-1jpp.noarch.rpm: Verify signature: BAD PARAMETERS
__
Stoopid brain fart fixed (as you know). Kinda helps to add, not delete,
the signature elements before attempting
On Oct 4, 2007, at 12:56 PM, Mark Hatle wrote:
Arkadiusz Miskiewicz wrote:
Does the filtering affect the internal per-file dependencies or
just the
overall package dependencies once they are rolled together?
PLD patch applies to overall deps for entire spec. So it's not per-
pkg. It's
On Oct 5, 2007, at 2:25 AM, Arkadiusz Miskiewicz wrote:
On Friday 05 of October 2007, Jeff Johnson wrote:
On Oct 4, 2007, at 12:52 PM, Arkadiusz Miskiewicz wrote:
Note that -x binary is not a option since it has some other
autogenerated deps
that we want to have.
Not true. chmod -x
On Oct 5, 2007, at 7:56 AM, Arkadiusz Miskiewicz wrote:
On Friday 05 of October 2007, Jeff Johnson wrote:
On Oct 5, 2007, at 2:25 AM, Arkadiusz Miskiewicz wrote:
Sucks is a different mtter.
How many packages need this functionality? Acroread, which isn't
built correctly. How many other
201 - 300 of 1739 matches
Mail list logo
