On 01/15/2017 04:03 PM, Neal Gompa (ニール・ゴンパ) wrote:
I'm not sure how true it is, but it seems to bear out with the number of
previously BDB users now being LMDB users.
Unless a different DB offers substantial advantages over BDB to RPM,
which does not endanger or destabilize rpm, I do not
On 09/03/2009 05:56 PM, Stanislav Brabec wrote:
Mark Hatle wrote:
I believe conflicts has been used for this purpose in the past. While it's not
an automatic replacement, it does alert the admin to remove the custom package,
and replace it with the distro package that is conflicting.
It does
Tom spot Callaway wrote:
On 04/02/2009 01:27 PM, Jeremy Katz wrote:
On Thursday, April 02 2009, Tom spot Callaway said:
When we updated the Fedora SPARC buildsystems to rpm 4.6.0, sparcv9v
packages were no longer installable. The attached patch resolves the
issue. Unfortunately, the sanest way
Tom spot Callaway wrote:
On 04/03/2009 02:10 AM, Ralf Corsepius wrote:
Tom spot Callaway wrote:
On 04/02/2009 01:27 PM, Jeremy Katz wrote:
On Thursday, April 02 2009, Tom spot Callaway said:
When we updated the Fedora SPARC buildsystems to rpm 4.6.0, sparcv9v
packages
On Wed, 2008-11-26 at 22:55 +0100, Jan Engelhardt wrote:
LZIP is the new stable lzma compression utility
Pardon, but what is your legitimation to claim lzip to be
the new stable lzma compression utility?
No doubt, it is yet one another lzma compression utility.
(
On Mon, 2008-08-04 at 14:58 +0100, Richard W.M. Jones wrote:
On Mon, Aug 04, 2008 at 07:56:31AM -0500, Mark Hatle wrote:
You will want to probably define _strip as true or provide a custom
__os_install_post. This is a necessity if you are creating a cross
compiler with binaries for
On Thu, 2008-07-17 at 17:09 +0200, Stanislav Brabec wrote:
Hallo.
%build
Packagers are encouraged to call autoreconf whenever possible. It
guarantees correct build of packages on platforms, that was not
supported by autotools in the time of the source release.
autoreconf -f -i
I
On Thu, 2008-02-14 at 18:25 +0200, Panu Matilainen wrote:
On Thu, 14 Feb 2008, Ralf Corsepius wrote:
On Thu, 2008-02-14 at 12:05 +0200, Panu Matilainen wrote:
Something I've been occasionally thinking of, and was again reminded by
looking at the gcc __attribute__() compatibility macros
On Thu, 2007-11-29 at 11:21 +0100, Joachim Worringen wrote:
Ralf Corsepius schrieb:
On Tue, 2007-11-27 at 17:30 +0100, Joachim Worringen wrote:
I've seen that rpath is considered evil.
When being used correctly, there is nothing wrong with using rpath (When
installing libs
On Tue, 2007-11-27 at 17:30 +0100, Joachim Worringen wrote:
Tom spot Callaway wrote:
On Mon, 2007-11-26 at 22:57 +0100, Joachim Worringen wrote:
-prefix=$RPM_BUILD_ROOT%{disdir}
You're embedding $RPM_BUILD_ROOT in your prefix. This is almost
certainly the cause of your problem, as it
Hi,
The patch below contains a couple of minor bug fixes, which are supposed
to render currently non-buildable test programs buildable again.
Ralf
diff -r 425cce5ee453 rpmdb/tdbi.c
--- a/rpmdb/tdbi.c Sun Aug 05 11:30:55 2007 +0300
+++ b/rpmdb/tdbi.c Mon Aug 06 09:36:34 2007 +0200
@@ -25,7 +25,7
... and the next patch:
It addresses 2 related issues
* $(mkinstalldirs) in Makefile.ams is an anachronism.
Modern Makefile.ams should use $(MKDIR_P) instead.
* There is one direct call to mkdir -p inside of the toplevel
Makefile.am - mkdir -p is non-portable. Portable Makefile.ams should use
On Mon, 2007-08-06 at 12:17 +0300, Panu Matilainen wrote:
On Mon, 6 Aug 2007, Ralf Corsepius wrote:
Hi,
The patch below contains a couple of minor bug fixes, which are supposed
to render currently non-buildable test programs buildable again.
This + MKDIR_P and python patches all
.. and yet another one:
Use PACKAGE_BUGREPORT in rpmrc.c's error messages.
Background: autoconf supplies a define (PACKAGE_BUGREPORT) which can be
used to provide an email-address for bug reporting. So far, rpmrc.c
sources used a hard-coded addresses instead.
This had caused i18n'ed strings
... today's flood continues ...
The patch below removes AC_CANONICAL_TARGET from configure.ac and
changes $target to $host.
Background: AC_CANONICAL_TARGET is supposed to take the target of a
cross-tool, not the target of cross-compiling a package
(== a configure script's --host).
Older
On Mon, 2007-08-06 at 09:02 -0500, Mark Hatle wrote:
Umm... yes it is.
I use RPM to cross-compile software ever day. I also cross compile RPM
from one target to another routinely. You need to keep the $target
references or you will make the rpm.org version of RPM unable to be
cross
On Mon, 2007-08-06 at 09:26 -0500, Mark Hatle wrote:
Ralf Corsepius wrote:
On Mon, 2007-08-06 at 09:02 -0500, Mark Hatle wrote:
Umm... yes it is.
I use RPM to cross-compile software ever day. I also cross compile RPM
from one target to another routinely. You need to keep the $target
Him
rpm.org's rpm's configure fails to build python/ if python-devel isn't
installed.
Fixing this issue is not too difficult, but to be able to do so, I'd
need to know what the nominal desired behavior is supposed to be.
Question: Are rpm's python binding considered mandatory or optional?
Hi,
Panu asked me to assist rpm.org on rpm's autotool-usage/configuration.
To be able to getting deeper into cleaning up rpm's auto*-configuration,
I'd propose to get rid of several auto*-anachronisms rpm currently uses.
As an initial step, the patch below contains a few more or less cosmetic
19 matches
Mail list logo
