Re: [CVS] RPM: rpm/ CHANGES configure.ac rpm/macros/ macros.in
The AutoFu is perfectly okay, but there's deeper design problems here.
First of, there's additional configuration that needs to be automated.
There are 2 usage cases, one for files, the other for package scriptlets,
for bash --rpm-requires
1) for files
The files have only %_foo_requires, there is no %_foo_provides. The
reason there is that
Requires: executable(whatever)
is a run-time probe modeled on which(1) (and uglix PATH envvar):
The executable(whatever) dependency is TRUE iff
a) the executable is found on PATH (or is absolute path)
b) access(2) claims the object on path is executable.
I.e. The semantic for executable(whatever) is defined as a run-time
condition, not as a dependency assertion string match from package metadata.
The enabling for this extractor follows the usual conventions for disabling
by undefining or setting to %{nil}. The sad reality is that almost all
distros
I'm aware of are choosing opt-in behavior akin to Waiting for Godot
The implementation has been done since forever.
2) for package scriptlets
The automated scriptlet dependencies also have no provides, again because
executable(whatever) is a run-time probe that checks a condition not
an essertion string.
The enabling for automating scriptlet dependencies is OR'ing in 0x2 to
%_use_internal_dependency_generator
(0x1 enables ELF extraction and disables %_find_requires for ELF, 0x4 was
used to prepare LSB packages until lack of interest from LSB in their
own chosen format prevented finishing the implementation).
Both of the above configuration changes need to be tied into AutoFu if you
choose to automate from configure.ac (or no problem has really been automated
or solved).
I personally think that it isn't worth adding AutoFu for complex features that
are routinely disabled (or rendered as default opt-in which is de facto
disabled).
hth
73 de Jeff
On Jun 7, 2011, at 8:35 AM, Pinto Elia wrote:
RPM Package Manager, CVS Repository
http://rpm5.org/cvs/
Server: rpm5.org Name: Pinto Elia
Root: /v/rpm/cvs Email: devzero2...@rpm5.org
Module: rpm Date: 07-Jun-2011 14:35:30
Branch: HEAD Handle: 2011060712352900
Modified files:
rpm CHANGES configure.ac
rpm/macros macros.in
Log:
define the scriplet_requires macro
as /bin/bash --rpm-requires only if bash have the
required patch.
Submitted by: Elia Pinto
Summary:
RevisionChanges Path
1.3652 +3 -0 rpm/CHANGES
2.497 +16 -0 rpm/configure.ac
1.57+2 -2 rpm/macros/macros.in
patch -p0 '@@ .'
Index: rpm/CHANGES
$ cvs diff -u -r1.3651 -r1.3652 CHANGES
--- rpm/CHANGES 27 May 2011 13:47:29 - 1.3651
+++ rpm/CHANGES 7 Jun 2011 12:35:29 - 1.3652
@@ -8,6 +8,9 @@
- afb: yaml: use !!timestamp for timestamps
5.4.0 - 5.4.1:
+- devzero2000: define the scriplet_requires macro
+ as /bin/bash --rpm-requires only if bash have the
+ required patch.
- devzero2000: In fpLookupSubdir, data returned by hash should be of
type
struct rpmffi_s ** instead of struct rpmffi_s * to avoid
segfault. Patch by Qing He.
@@ .
patch -p0 '@@ .'
Index: rpm/configure.ac
$ cvs diff -u -r2.496 -r2.497 configure.ac
--- rpm/configure.ac 26 May 2011 14:26:26 - 2.496
+++ rpm/configure.ac 7 Jun 2011 12:35:29 - 2.497
@@ -390,6 +390,22 @@
AC_DEFINE([RPMVERCMP_DIGITS_BEAT_ALPHA],[1],[Permit in RPM version
comparison that digits beat alpha])
])
+dnl # Check if bash have the --rpm-requires patch
+dnl # If so define the scriptlet_requires output variable
+dnl # to bash --rpm-requires
+dnl # and BASH_RPM_REQUIRES to the bash absolute path
+AC_CACHE_CHECK([for bash if supports --rpm-requires],
[ac_cv_path_BASH_RPM_REQUIRES],
+ [AC_PATH_PROGS_FEATURE_CHECK([BASH_RPM_REQUIRES], [bash],
+[[ bash_rpm_requires_out=`echo ls | $ac_path_BASH_RPM_REQUIRES
--rpm-requires | grep executable(ls)`
+ test x$bash_rpm_requires_out != x \
+ ac_cv_path_BASH_RPM_REQUIRES=$ac_path_BASH_RPM_REQUIRES
scriptlet_requires=$ac_path_BASH_RPM_REQUIRES --rpm-requires
+]],
+[[ scriptlet_requires=%{nil} ]], [$PATH]
+)])
+AS_IF([test x$ac_cv_path_BASH_RPM_REQUIRES != x],
+ [AC_SUBST([BASH_RPM_REQUIRES],[$ac_cv_path_BASH_RPM_REQUIRES])],
+
Re: [CVS] RPM: rpm/ CHANGES configure.ac rpm/macros/ macros.in
On Tue, Jun 7, 2011 at 4:03 PM, Jeff Johnson n3...@mac.com wrote:
The AutoFu is perfectly okay, but there's deeper design problems here.
First of, there's additional configuration that needs to be automated.
There are 2 usage cases, one for files, the other for package scriptlets,
for bash --rpm-requires
1) for files
The files have only %_foo_requires, there is no %_foo_provides. The
reason there is that
Requires: executable(whatever)
is a run-time probe modeled on which(1) (and uglix PATH envvar):
The executable(whatever) dependency is TRUE iff
a) the executable is found on PATH (or is absolute path)
b) access(2) claims the object on path is executable.
I.e. The semantic for executable(whatever) is defined as a run-time
condition, not as a dependency assertion string match from package
metadata.
The enabling for this extractor follows the usual conventions for
disabling
by undefining or setting to %{nil}. The sad reality is that almost all
distros
I'm aware of are choosing opt-in behavior akin to Waiting for Godot
The implementation has been done since forever.
Setting to %nil what ? I am sorry, i have read all the code(lib/rpmfc.c in
particular), but i have not found nothing
(Aside) ./scripts/executabledeps.sh is not more used right ?
2) for package scriptlets
The automated scriptlet dependencies also have no provides, again
because
executable(whatever) is a run-time probe that checks a condition not
an essertion string.
The enabling for automating scriptlet dependencies is OR'ing in 0x2 to
%_use_internal_dependency_generator
(0x1 enables ELF extraction and disables %_find_requires for ELF, 0x4
was
used to prepare LSB packages until lack of interest from LSB in their
own chosen format prevented finishing the implementation).
If have thought that putting %__scriptlet_requires to %{nil} was the right
disabler: my toy patch do this. Was i wrong then ? No problem,
it is sufficient to know where to look better.
Both of the above configuration changes need to be tied into AutoFu if you
choose to automate from configure.ac (or no problem has really been
automated or solved).
I personally think that it isn't worth adding AutoFu for complex features
that
are routinely disabled (or rendered as default opt-in which is de facto
disabled).
Thanks, IMHO the truly solution is to have a deps shell generator
indipendent from a patch not upstream. Yes, i remember
that this is something to discuss.
hth
73 de Jeff
On Jun 7, 2011, at 8:35 AM, Pinto Elia wrote:
RPM Package Manager, CVS Repository
http://rpm5.org/cvs/
Server: rpm5.org Name: Pinto Elia
Root: /v/rpm/cvs Email: devzero2...@rpm5.org
Module: rpm Date: 07-Jun-2011 14:35:30
Branch: HEAD Handle: 2011060712352900
Modified files:
rpm CHANGES configure.ac
rpm/macros macros.in
Log:
define the scriplet_requires macro
as /bin/bash --rpm-requires only if bash have the
required patch.
Submitted by: Elia Pinto
Summary:
RevisionChanges Path
1.3652 +3 -0 rpm/CHANGES
2.497 +16 -0 rpm/configure.ac
1.57+2 -2 rpm/macros/macros.in
patch -p0 '@@ .'
Index: rpm/CHANGES
$ cvs diff -u -r1.3651 -r1.3652 CHANGES
--- rpm/CHANGES 27 May 2011 13:47:29 - 1.3651
+++ rpm/CHANGES 7 Jun 2011 12:35:29 - 1.3652
@@ -8,6 +8,9 @@
- afb: yaml: use !!timestamp for timestamps
5.4.0 - 5.4.1:
+- devzero2000: define the scriplet_requires macro
+ as /bin/bash --rpm-requires only if bash have the
+ required patch.
- devzero2000: In fpLookupSubdir, data returned by hash should be
of type
struct rpmffi_s ** instead of struct rpmffi_s * to avoid
segfault. Patch by Qing He.
@@ .
patch -p0 '@@ .'
Index: rpm/configure.ac
$ cvs diff -u -r2.496 -r2.497 configure.ac
--- rpm/configure.ac 26 May 2011 14:26:26 - 2.496
+++ rpm/configure.ac 7 Jun 2011 12:35:29 - 2.497
@@ -390,6 +390,22 @@
AC_DEFINE([RPMVERCMP_DIGITS_BEAT_ALPHA],[1],[Permit in RPM version
comparison that digits beat alpha])
])
+dnl # Check if bash have the --rpm-requires patch
+dnl # If so define the scriptlet_requires output variable
+dnl # to bash --rpm-requires
+dnl # and BASH_RPM_REQUIRES to the bash absolute path
Re: [CVS] RPM: rpm/ CHANGES configure.ac rpm/macros/ suse.in
On Mon, May 23, 2011 at 11:30, Jeff Johnson n3...@mac.com wrote: In general, its gonna be easier to exchange info if you build @rpm5.org code from cvs, not from tarballs and patches. I do :D We do monthly releases, tick,tock, next release of rpm-5.3.whatever is on June 1st, and likely rpm-5.4.1 will also be attempted this month. So the starting point (rpm-5_4 is development, rpm-5_3 is production, rpm-5_2 and rpm-5_1 are legacy branches) is cvs -d ':pserver:anonym...@rpm5.org:/v/rpm/cvs' get -r rpm-5_4 rpm Since rpm-5_4 is coming up anyway, I'll probably stick to that branch then. I've been checking out from MASTER AFAIK. So I'll finish up the patches then switch to that branch. See rpm/INSTALL.developer to get oriented on what to do next. Your workflow SHOULD be something similar to cd rpm ./devtool checkout ./devtool opensuse ... install build pre-requsites and/or adjust the %opensuse build options ... make cd tests make clean check hm... yea, I've just been patching right now. ^_^ Post any patches and or questions here and I can likely help instantly because I will have sufficient context from cvs to answer precisely. I can also easily send along rpm -qa from my opensuse VM if you need help finding build prerequsites (I forget when I set it up, last October iirc). the current spec file shouldn't be that different from the rpm5 one I will make. On your openSUSE Buildbot, I'm guessing you run install prerequisites cd rpm ./devtool checkout ./devtool opensuse make cd tests make clean check through, right? Once I'm ready, I can share what I have of the spec file. It would be easy then to probably run rpmbuild -bi through to make sure it works... -- later, Robert Xu __ RPM Package Managerhttp://rpm5.org Developer Communication Listrpm-devel@rpm5.org
Re: [CVS] RPM: rpm/ CHANGES configure.ac rpm/rpmio/ Makefile.am rpm/ruby/ ...
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Yippie, my first actual usuful CVS commit to RPM5! *celebrate*
On Friday 10 September 2010, Eric Veith eve...@rpm5.org wrote:
+WITH_RUBY_CPPFLAGS=
RPM_CHECK_LIB(
[Ruby], [ruby],
[ruby], [ruby_init], [ruby.h],
[no,external:none], [],
-[ AC_DEFINE(WITH_RUBYEMBED, 1, [Define to 1 if you want embedded
Ruby]) - WITH_RUBY_SUBDIR=ruby
+[
+AC_DEFINE(WITH_RUBYEMBED, 1, [Define to 1 if you want embedded
Ruby]) +WITH_RUBY_SUBDIR=ruby
+
+WITH_RUBY_CPPFLAGS=-I`ruby -rrbconfig -e 'puts
RbConfig::expand(RbConfig::CONFIG[[\rubyhdrdir\]])'` -I`ruby
-rrbconfig -e 'puts
RbConfig::expand(\#{RbConfig::CONFIG[\rubyhdrdir\]}/$(arch)\)'` ],
[])
AC_SUBST(WITH_RUBY_SUBDIR)
+AC_SUBST(WITH_RUBY_CPPFLAGS)
Fun aside: Could somebody with real AutoFu experience and knowledge please
have a look at that and tell me whether it's the best/most elegant way to
solve this problem? Currently it only WORKSFORME.
Ok, now on to rpmio/rpmruby fun. Already gcc complains that the ruby folks
have a xmalloc/xcalloc/xfree, too. *sigh*
Eric
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.9 (GNU/Linux)
iEYEARECAAYFAkyKbiYACgkQhS0drJ3goJKgawCeKlrEZdiOtHjHR1YDXd+ptgKH
U9QAn1uBckLkUktQUl1E5umJ/f69sVkI
=ddRg
-END PGP SIGNATURE-
__
RPM Package Managerhttp://rpm5.org
Developer Communication Listrpm-devel@rpm5.org
Re: [CVS] RPM: rpm/ CHANGES configure.ac rpm/rpmio/ Makefile.am rpm/ruby/ ...
On Sep 10, 2010, at 1:43 PM, Eric MSP Veith wrote:
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Yippie, my first actual usuful CVS commit to RPM5! *celebrate*
Hehe ... congrats!
On Friday 10 September 2010, Eric Veith eve...@rpm5.org wrote:
+WITH_RUBY_CPPFLAGS=
RPM_CHECK_LIB(
[Ruby], [ruby],
[ruby], [ruby_init], [ruby.h],
[no,external:none], [],
-[ AC_DEFINE(WITH_RUBYEMBED, 1, [Define to 1 if you want embedded
Ruby]) - WITH_RUBY_SUBDIR=ruby
+[
+AC_DEFINE(WITH_RUBYEMBED, 1, [Define to 1 if you want embedded
Ruby]) +WITH_RUBY_SUBDIR=ruby
+
+WITH_RUBY_CPPFLAGS=-I`ruby -rrbconfig -e 'puts
RbConfig::expand(RbConfig::CONFIG[[\rubyhdrdir\]])'` -I`ruby
-rrbconfig -e 'puts
RbConfig::expand(\#{RbConfig::CONFIG[\rubyhdrdir\]}/$(arch)\)'` ],
[])
AC_SUBST(WITH_RUBY_SUBDIR)
+AC_SUBST(WITH_RUBY_CPPFLAGS)
Fun aside: Could somebody with real AutoFu experience and knowledge please
have a look at that and tell me whether it's the best/most elegant way to
solve this problem? Currently it only WORKSFORME.
todo++. Feel free to make the call about ruby 1.8.x - 1.9.x
and minimum necessary version etc as you progress. I haven't
a clue which ruby version is best to target.
Ok, now on to rpmio/rpmruby fun. Already gcc complains that the ruby folks
have a xmalloc/xcalloc/xfree, too. *sigh*
Mind if I write up a blueprint for rpm-embed-ruby at http://launchpad.net/rpm
to describe
some of the details? Its your work, so I ask first.
You are more than welcome to change/delete/ignore/whatever
the blueprint.
But with a blueprint I can target a milestone (aka an rpm release) and attach
dependencies and bugs and more. Just process scheduling administrivia,
chlorox-ing
my neurons nightly is getting to be a chore ;-)
For starters, there's global - instance that needs worrying about (I'd
suggest targeting/using global initially: multiple interpreters have
all sorts of weird surprises).
There's also deciding on some mechanism for what modules get automagically
loaded (and from where) as a side effect of calling rpmrubyNew().
I likely did the minimimum necessary change to capture stdout in a buffer to
return as the
%{ruby OPTS ARGS: BODY}
expansion value, using whatever seemed like a reasonable Rubyesque way
to redirect a stream. If I looked, I'd remember why I did whatever I did.
And there's some toy *.spec test cases that should be written to exercise both
macro/scriptlet syntaxes attached to embedded ruby.
Then there's the whole messiness of exception and signal handling in embedded
ruby as well as
threading that need to start to be worked through. There's some utterly
simple things that could/should be done to display diagnostics while
trying to devise a real world framework not only for ruby, but all the
embeddings.
hth
73 de Jeff
__
RPM Package Managerhttp://rpm5.org
Developer Communication Listrpm-devel@rpm5.org
Re: [CVS] RPM: rpm/ CHANGES configure.ac rpm/rpmio/ Makefile.am rpm/ruby/ ...
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On Friday 10 September 2010, Jeff Johnson n3...@mac.com wrote:
todo++. Feel free to make the call about ruby 1.8.x - 1.9.x
and minimum necessary version etc as you progress. I haven't
a clue which ruby version is best to target.
I'll make 1.9 mandatory. 1.8 has only been around to make the Rails folks
happy, and with rails-3.0 out of the door, there's no need for 1.8
compatiblity. And do not worry about any distro yet. It's still not a
feature marked as stable, so nobody should expect backwards compatibility
IMHO.
Mind if I write up a blueprint for rpm-embed-ruby at
http://launchpad.net/rpm to describe some of the details? Its your work,
so I ask first.
Yeah, sure, go on. And, to be honest, it's mostly your work right now. I
spent the last days mainly with (re-) writing some docs, finding out whether
there's a way to make more than one interpreter instance possible, and,
above all, finding a way around Ruby's #include quirks.
Btw, RPM5 is a nice place to get to know more of the really cool and nifty C
stuff. ;-)
You are more than welcome to change/delete/ignore/whatever
the blueprint.
I'm going to register with Launchpad then... Ok, waiting for the mail to
come in.
For starters, there's global - instance that needs worrying about (I'd
suggest targeting/using global initially: multiple interpreters have
all sorts of weird surprises).
Since Ruby cannot support multiple interpreters right now, I'm about to
change the default to a new interpreter init for each expanding. I don't
like the idea of carrying one interpreter around through the whole runtime.
That might bring all sorts of surprises people don't expect.
It's a policy decision, basically, that needs to be documented. Whatta you
think?
There's also deciding on some mechanism for what modules get
automagically loaded (and from where) as a side effect of calling
rpmrubyNew().
Modules == Ruby Modules? (The term module exists for Ruby, too; I'm asking
to make sure.)
I likely did the minimimum necessary change to capture stdout in a buffer
to return as the %{ruby OPTS ARGS: BODY}
expansion value, using whatever seemed like a reasonable Rubyesque way
to redirect a stream. If I looked, I'd remember why I did whatever I did.
Yes, you already did a lot of good stuff. Using StringIO is a neat way to
capture stuff for expansion. The other way would be using tempfiles, but I
don't think that people will create more output than what's fitting into
their RAM... just now. Switching to tempfiles is dirt easy from the Ruby
perspective, and doesn't make any difference.
And there's some toy *.spec test cases that should be written to exercise
both macro/scriptlet syntaxes attached to embedded ruby.
That's something I wanted to talk about anyways: Do you have objections if I
pull in a unit testing framework? (Yeah, dire shot, I know.)
Then there's the whole messiness of exception and signal handling in
embedded ruby as well as threading that need to start to be worked
through. There's some utterly simple things that could/should be done to
display diagnostics while trying to devise a real world framework not
only for ruby, but all the embeddings.
With Ruby, it's quite simple, because the C API has mechanisms of taking
care of Ruby exceptions and other failures triggered by the Ruby code. I
don't know for the rest, though. Gimme some function pointer for that, and
I'll wire it up. :-)
Gotta fix the xmalloc co warnings first, without breaking things, though.
Uhm, any suggestions?
Eric
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.9 (GNU/Linux)
iEYEARECAAYFAkyKjV4ACgkQhS0drJ3goJKw4gCePLApcpuu6P1pEoSnhNQBIDEd
2kAAn1T+6D3Kym9TYAWhk8tC9aNGD5VY
=AqeM
-END PGP SIGNATURE-
__
RPM Package Managerhttp://rpm5.org
Developer Communication Listrpm-devel@rpm5.org
Re: [CVS] RPM: rpm/ CHANGES configure.ac rpm/rpmio/ Makefile.am rpm/ruby/ ...
On Sep 10, 2010, at 5:36 PM, Eric MSP Veith wrote:
I'm going to register with Launchpad then... Ok, waiting for the mail
to come in.
Okay, I'm registered. I'm Eric MSP Veith eve...@wwweb-library.net, just
as with the ML, if you need to add me to something or grant permissions
or...
You're now added to the rpm.org team.
Hint: You might want to disable bug notifications and other nag mail
from Launchpad while I'm gathering bugs and setting up trackers
and other administrivia.
Ah, if ruby supports only a global interpreter, well, there's nothing
else that can be done.
It's likely to change in the future.
Yes. E.g. the embedded perl/python interpreters automagically
load the rpm bindings.
I didn't expact that when I first used the embedded Lua. Aside from that, I
wouldn't auto-require anything in Ruby.
OK. There's still a need for macro configgert to insert additional
requires aven if the default value is undefined or %{nil}. I'll
get that wired up with a default of undefined/%{nil} eventually,
likely needs to be done for all embedded interpreters to get
the macro names more or less consistently named.
And there's some toy *.spec test cases that should be written to
exercise both macro/scriptlet syntaxes attached to embedded ruby.
That's something I wanted to talk about anyways: Do you have objections
if I pull in a unit testing framework? (Yeah, dire shot, I know.)
Do what you want, I'm open to suggestions.
I've come to like Check (http://check.sf.net), because it protect's the
original address space and does other useful things. But yes, it's just
another JUnit clone.
At least for Ruby, I'm trying to draw a line between the C and the actual
Ruby stuff. That is, test with Ruby what should work from the Ruby
perspective, and test in C the gory binding details. Because it's easier to
corner flaws when testing with actual C code than to just know that
somewhere in the code that belongs to the Ruby highlevel function
do_what_i_mean() something fails. :-)
The problem that I always see with your favorite JUnit-like clone here
is that each one spins the units tests slightly differently and
that's a huge PITA to maintain.
If there is already a default testing procedure, I'll of course adapt to
this.
This is likely what I was doing:
cd ruby ./trb
And I *think* I wired that into
cd ruby make check
at some point. If not its utterly simple to add.
The problem is that the ruby interpreter is gonna exit and take
all of the RPM executable down with it. So there's a need to
set better default exception handlers, some of ruby's default
beahviors won't make sense when embedded.
Yeah, ruby_exec()/ruby_run() have become deprecated in Ruby 1.9 for exact
that reason. And the Ruby C API now does provide some callback mechanisms in
case the Ruby code fails.
ditto signal handlers (issues which can be ignored until needed imho).
I still don't know what happens if RPM gets a SIGTERM and relays that to the
embedded ruby interpreter. That's on my TODO list, too.
The behavior will depend on whether the rpmdb is open (or not).
The signal handlers are lazily instantiated as a side effect
of the first rpmdb open.
All that the signal handler does is set a bit that can be tested
at say rpmrubyFoo() entry/exit. That means the signal will be delayed
slightly which likely doesn't matter a bit.
However if ruby is also setting up signal handlers, than I'll have to chain
the handler into ruby's environment with a programming caveat
Ruby signal handlers should NEVER exit, must ALWAYS return.
Gotta fix the xmalloc co warnings first, without breaking things,
though. Uhm, any suggestions?
Sure, easy pie:
#include system.h
#undef xmalloc
#undef xcalloc
#undef xrealloc
#include rubygunk.h
Uh, I won't screw internal RPM code that way?
Not if done in rpmio/rpmruby.c.
Try and see. The behavior will depend on whether ruby is doing
something fancy with its wrappers, not just calling malloc/free.
But I doubt that is the case. And at worst, the RPM macros (in system.h)
can be inlined and renamed to some other name that doesn't collide
with ruby.
hth
73 de Jeff
__
RPM Package Managerhttp://rpm5.org
Developer Communication Listrpm-devel@rpm5.org
Re: [CVS] RPM: rpm/ CHANGES configure.ac
This patch appears to need some fiddling: --- generate files via GNU autoconf (aclocal, autoheader) configure.ac:11: error: m4_defn: undefined macro: _m4_divert_diversion configure.ac:11: the top level autom4te: /usr/bin/m4 failed with exit status: 1 aclocal: autom4te failed with exit status: 1 configure.ac:11: error: m4_defn: undefined macro: _m4_divert_diversion configure.ac:11: the top level autom4te: /usr/bin/m4 failed with exit status: 1 autoheader: '/usr/bin/autom4te' failed with exit status: 1 --- generate files via GNU automake (automake) configure.ac:11: error: m4_defn: undefined macro: _m4_divert_diversion configure.ac:11: the top level autom4te: /usr/bin/m4 failed with exit status: 1 automake: autoconf failed with exit status: 1 --- generate files via GNU autoconf (autoconf) configure.ac:11: error: m4_defn: undefined macro: _m4_divert_diversion configure.ac:11: the top level autom4te: /usr/bin/m4 failed with exit status: 1 hth 73 de Jeff On Nov 26, 2009, at 9:12 AM, Bernhard Rosenkraenzer wrote: RPM Package Manager, CVS Repository http://rpm5.org/cvs/ Server: rpm5.org Name: Bernhard Rosenkraenzer Root: /v/rpm/cvs Email: b...@rpm5.org Module: rpm Date: 26-Nov-2009 15:12:54 Branch: HEAD Handle: 2009112614125300 Modified files: rpm CHANGES configure.ac Log: Fix configure.ac:11: error: m4_divert_push: cannot change diversion to `GROW' inside m4_expand configure.ac:11: the top level when using autoconf = 2.65 Summary: RevisionChanges Path 1.3166 +1 -0 rpm/CHANGES 2.411 +1 -1 rpm/configure.ac patch -p0 '@@ .' Index: rpm/CHANGES $ cvs diff -u -r1.3165 -r1.3166 CHANGES --- rpm/CHANGES 22 Nov 2009 14:33:03 - 1.3165 +++ rpm/CHANGES 26 Nov 2009 14:12:53 - 1.3166 @@ -1,5 +1,6 @@ 5.2b1 - 5.3a1 +- bero: Fix generation of configure script with autoconf 2.65 - jbj: rpmdb: don't recurse within dbiFindByLabel. - jbj: rpmdb: use PCRE patterns on Name index for package queries. - devzero2000: don't permit using b0rken configure option @@ . patch -p0 '@@ .' Index: rpm/configure.ac $ cvs diff -u -r2.410 -r2.411 configure.ac --- rpm/configure.ac 20 Nov 2009 13:46:15 - 2.410 +++ rpm/configure.ac 26 Nov 2009 14:12:53 - 2.411 @@ -8,7 +8,7 @@ AC_PREREQ(2.63) AC_DEFUN([PACKAGE_BUGREPORT_DEFAULT], [rpm-de...@rpm5.org]) -AC_INIT([rpm],[5.3.DEVEL],[PACKAGE_BUGREPORT_DEFAULT]) +AC_INIT([rpm],[5.3.DEVEL],PACKAGE_BUGREPORT_DEFAULT) PACKAGE_TIMESTAMP=2009 dnl # [-MM[-DD[ HH[:MM AC_MSG_TITLE([RPM Package Manager (RPM)], [$PACKAGE_VERSION]) @@ . __ RPM Package Managerhttp://rpm5.org CVS Sources Repositoryrpm-...@rpm5.org __ RPM Package Managerhttp://rpm5.org Developer Communication Listrpm-devel@rpm5.org
Re: [CVS] RPM: rpm/ CHANGES configure.ac
Nice.
Thanks.
73 de Jeff
On Nov 20, 2009, at 8:46 AM, Pinto Elia wrote:
RPM Package Manager, CVS Repository
http://rpm5.org/cvs/
Server: rpm5.org Name: Pinto Elia
Root: /v/rpm/cvs Email: devzero2...@rpm5.org
Module: rpm Date: 20-Nov-2009 14:46:16
Branch: HEAD Handle: 2009112013461500
Modified files:
rpm CHANGES configure.ac
Log:
don't permit configure option that produce unusable rpm5, see
http://rpm5.org/community/rpm-users/0346.html
Summary:
RevisionChanges Path
1.3164 +1 -0 rpm/CHANGES
2.410 +20 -0 rpm/configure.ac
patch -p0 '@@ .'
Index: rpm/CHANGES
$ cvs diff -u -r1.3163 -r1.3164 CHANGES
--- rpm/CHANGES 19 Nov 2009 20:19:33 - 1.3163
+++ rpm/CHANGES 20 Nov 2009 13:46:15 - 1.3164
@@ -1,5 +1,6 @@
5.2b1 - 5.3a1
+- devzero2000: don't permit using b0rken configure option
- jbj: rpmdb: fix: ensure Seqno h# counter is initialized to 1 when
created.
- proyvind: add %distepoch back to provideversion, leave legacy
compatibility for adopters to care about.
@@ .
patch -p0 '@@ .'
Index: rpm/configure.ac
$ cvs diff -u -r2.409 -r2.410 configure.ac
--- rpm/configure.ac 19 Nov 2009 00:34:21 - 2.409
+++ rpm/configure.ac 20 Nov 2009 13:46:15 - 2.410
@@ -1167,6 +1167,7 @@
[yes,external], [],
[], [AC_MSG_ERROR([mandatory POPT library not found])])
+HAVE_RPM_COMPRESSION=no
dnl # ZLib
RPM_CHECK_LIB(
[ZLib], [zlib],
@@ -1178,12 +1179,18 @@
fi
], [])
+if test .$WITH_ZLIB = .yes; then
+HAVE_RPM_COMPRESSION=yes
+fi
dnl # GNU BZip2
RPM_CHECK_LIB(
[GNU BZip2], [bzip2],
[bz2], [BZ2_bzread], [bzlib.h],
[no,external:none], [],
[], [])
+if test .$WITH_BZIP2 = .yes; then
+HAVE_RPM_COMPRESSION=yes
+fi
dnl # libLZMA
WITH_XZ_INTERNAL=false
@@ -1196,13 +1203,22 @@
AC_DEFINE(HAVE_LZMA_H, 1, [Define to 1 if you have lzma.h])
fi
], [])
+if test .$WITH_XZ = .yes; then
+HAVE_RPM_COMPRESSION=yes
+fi
+if test .$HAVE_RPM_COMPRESSION = .no; then
+ AC_MSG_ERROR([you have passed --without-{xz,bzip2,zlib} together but
it isn't possible to build rpm without any form of compression library. At a
minimum, i suggest adding --with-zlib if you want to actually build and
install a *.rpm package])
+fi
dnl # BeeCrypt
RPM_CHECK_LIB(
[BeeCrypt], [beecrypt],
[beecrypt], [mpfprintln], [beecrypt/api.h],
[yes,external], [],
[], [ AC_MSG_ERROR([mandatory BeeCrypt library not found]) ])
+if test .$WITH_BEECRYPT = .no; then
+ AC_MSG_ERROR([BEECRYPT is mandatory])
+fi
dnl # GCrypt
RPM_CHECK_LIB(
@@ -1572,6 +1588,10 @@
WITH_LUA_SUBDIR_DEF=$WITH_LUA_SUBDIR_DEF -DLUA_USE_PCRE
fi
], [])
+dnl # check PCRE
+if test .$WITH_PCRE = .no; then
+ AC_MSG_ERROR([PCRE is mandatory. If you don't have libpcre then
--with-pcre=internal could be used])
+fi
dnl # OSSP uuid
RPM_CHECK_LIB(
@@ .
__
RPM Package Managerhttp://rpm5.org
CVS Sources Repositoryrpm-...@rpm5.org
smime.p7s
Description: S/MIME cryptographic signature
Re: [CVS] RPM: rpm/ CHANGES configure.ac
Instead of more AutoFu, you might just want to add to default GCC CFLAGS. BTW, clang is Really Nice Stuff, found several minor issues when I ran clang across RPM a couple of weeks ago. hth 73 de Jeff On Sep 28, 2009, at 10:38 AM, Pinto Elia wrote: RPM Package Manager, CVS Repository http://rpm5.org/cvs/ Server: rpm5.org Name: Pinto Elia Root: /v/rpm/cvs Email: devzero2...@rpm5.org Module: rpm Date: 28-Sep-2009 16:38:50 Branch: HEAD Handle: 2009092814385000 Modified files: rpm CHANGES configure.ac Log: add -fno-delete-null-pointer-checks: http://patchwork.kernel.org/patch/36060/ Summary: RevisionChanges Path 1.3131 +1 -0 rpm/CHANGES 2.404 +9 -0 rpm/configure.ac patch -p0 '@@ .' Index: rpm/CHANGES = = = = = = == $ cvs diff -u -r1.3130 -r1.3131 CHANGES --- rpm/CHANGES24 Sep 2009 12:21:47 - 1.3130 +++ rpm/CHANGES28 Sep 2009 14:38:50 - 1.3131 @@ -1,5 +1,6 @@ 5.2b1 - 5.3a1 +- devzero2000: add rpm-genenerate-loop-test-harness.sh - devzero2000: add INSTALL.developer - jbj: order: fix: check current package for files/dirs before other packages. - jbj: order: fix: avoid self-looping for man-pages (and pkgs w no requires) @@ . patch -p0 '@@ .' Index: rpm/configure.ac = = = = = = == $ cvs diff -u -r2.403 -r2.404 configure.ac --- rpm/configure.ac 19 Sep 2009 23:12:03 - 2.403 +++ rpm/configure.ac 28 Sep 2009 14:38:50 - 2.404 @@ -187,6 +187,15 @@ fi fi ]) +AC_ARG_ENABLE(build-optimization, +AS_HELP_STRING([--enable-build-optimization], [build RPM instrumented for extra optimization/security (GCC only)]), [dnl +if test .$enableval = .yes; then +if test .`$CC --version 21 | grep 'GCC'` != .; then +dnl # GNU GCC (usually gcc) +CFLAGS=$CFLAGS -fno-delete-null-pointer-checks +fi +fi +]) AC_ARG_ENABLE(build-gcov, AS_HELP_STRING([--enable-build-gcov], [build RPM instrumented for gcov]), [dnl if test .$enableval = .yes; then @@ . __ RPM Package Managerhttp://rpm5.org CVS Sources Repositoryrpm-...@rpm5.org __ RPM Package Managerhttp://rpm5.org Developer Communication Listrpm-devel@rpm5.org
Re: [CVS] RPM: rpm/ CHANGES configure.ac rpm/lib/ rpmds.c rpmrc.c rpm/ sys...
Lest it be forgotten:
You are trying to automate switching between different
platform compatibility patterns based on a luser
configuration chose for what they think their platform is.
The patterns being chosen should be in flat external files,
not compiled into lib/rpmrpc.c
And the choice should be done by using the elements
that compose %{_target_platfrom} aka CPU-VENDOR-OS-GNU
in a macro expanded include path encountered while
reading /etc/rpm/platform.
There's no need for -lcpuinfo baggage to do that
switch.
And the flaw is compiling the logic into lib/rpmrc.c,
not whether -lcpuinfo is used (or not). The choice
and logic could/should be done flexibly outside of rpm code.
73 de Jeff
On May 2, 2009, at 9:29 AM, Per Øyvind Karlsen wrote:
RPM Package Manager, CVS Repository
http://rpm5.org/cvs/
Server: rpm5.org Name: Per Øyvind Karlsen
Root: /v/rpm/cvs Email: pkarl...@rpm5.org
Module: rpm Date: 02-May-2009 15:29:34
Branch: HEAD Handle: 2009050213293301
Modified files:
rpm CHANGES configure.ac system.h
rpm/lib rpmds.c rpmrc.c
Log:
cpuinfo: allow to enable from configure again since it's usable
now.
(although still room for improvements...)
Summary:
RevisionChanges Path
1.2961 +2 -0 rpm/CHANGES
2.371 +5 -5 rpm/configure.ac
2.153 +2 -2 rpm/lib/rpmds.c
2.273 +4 -4 rpm/lib/rpmrc.c
2.116 +0 -9 rpm/system.h
patch -p0 '@@ .'
Index: rpm/CHANGES
=
=
=
=
=
=
==
$ cvs diff -u -r1.2960 -r1.2961 CHANGES
--- rpm/CHANGES29 Apr 2009 23:53:32 - 1.2960
+++ rpm/CHANGES2 May 2009 13:29:33 - 1.2961
@@ -1,5 +1,7 @@
5.2a4 - 5.2b1:
+- proyvind: cpuinfo: allow to enable from configure again
since it's usable
+ now. (although still room for improvements...)
- jbj: ruby: stub-in the minimal necessary AutoFu to attempt
ruby bindings.
- jbj: add AutoFu to detect fallocate(2) and posix_fallocate(3).
- jbj: js: add rpmMCExpand() for per-context macro expansion.
@@ .
patch -p0 '@@ .'
Index: rpm/configure.ac
=
=
=
=
=
=
==
$ cvs diff -u -r2.370 -r2.371 configure.ac
--- rpm/configure.ac 29 Apr 2009 23:53:32 - 2.370
+++ rpm/configure.ac 2 May 2009 13:29:33 - 2.371
@@ -1431,11 +1431,11 @@
# later..
dnl # CPUInfo
-#RPM_CHECK_LIB(
-#[CPUInfo], [cpuinfo],
-#[cpuinfo], [cpuinfo_new], [cpuinfo.h],
-#[no,external:none], [],
-#[AC_MSG_WARN([CPUInfo support is under development])], [])
+RPM_CHECK_LIB(
+[CPUInfo], [cpuinfo],
+[cpuinfo], [cpuinfo_new], [cpuinfo.h],
+[no,external:none], [],
+[AC_MSG_WARN([CPUInfo support is under development])], [])
dnl ##
dnl ## INSTALLATION PARAMETERS
@@ .
patch -p0 '@@ .'
Index: rpm/lib/rpmds.c
=
=
=
=
=
=
==
$ cvs diff -u -r2.152 -r2.153 rpmds.c
--- rpm/lib/rpmds.c17 Apr 2009 16:10:22 - 2.152
+++ rpm/lib/rpmds.c2 May 2009 13:29:34 - 2.153
@@ -3,7 +3,7 @@
*/
#include system.h
-#if defined(SUPPORT_LIBCPUINFO)
+#if defined(WITH_CPUINFO)
#include cpuinfo.h
#endif
@@ -1192,7 +1192,7 @@
ds = NULL;
}
-#if defined(SUPPORT_LIBCPUINFO)
+#if defined(WITH_CPUINFO)
int rpmdsCpuinfo(rpmds *dsp, const char * fn)
{
const char * NS = cpuinfo;
@@ .
patch -p0 '@@ .'
Index: rpm/lib/rpmrc.c
=
=
=
=
=
=
==
$ cvs diff -u -r2.272 -r2.273 rpmrc.c
--- rpm/lib/rpmrc.c6 Apr 2009 15:26:28 - 2.272
+++ rpm/lib/rpmrc.c2 May 2009 13:29:34 - 2.273
@@ -502,7 +502,7 @@
}
/*...@=onlytrans@*/
-#if defined(SUPPORT_LIBCPUINFO)
+#if defined(WITH_CPUINFO)
static inline int rpmCpuinfoMatch(const char * feature, const char
* EVR, rpmds cpuinfo)
{
rpmds cpufeature = rpmdsSingle(RPMTAG_REQUIRENAME, feature,
EVR, RPMSENSE_PROBE);
@@ -712,7 +712,7 @@
if (cp == NULL || cp[0] == '\0')
cp = _platform;
if (rpmPlatform(cp) == RPMRC_OK) {
-#elif defined(SUPPORT_LIBCPUINFO)
+#elif defined(WITH_CPUINFO)
if (rpmPlatform(_platform) == RPMRC_OK || rpmCpuinfo() ==
RPMRC_OK) {
#else
if (rpmPlatform(_platform) == RPMRC_OK) {
@@ -853,7 +853,7 @@
if (name) *name = canon-short_name;
} else {
if (num) *num = 255;
-#if defined(SUPPORT_LIBCPUINFO)
+#if defined(WITH_CPUINFO)
if
Re: [CVS] RPM: rpm/ CHANGES configure.ac devtool.conf rpm/rpmio/ rpmjs.c
Took a bit to figger (and I still haven't a clue ;-),
but javascript is now embedded:
[...@fedora10 wdj]$ rpm -E '%{js:Hello World!}'
-- js 0xa07fe10 ++ 1 rpmjsNew at rpmjs.c:115
== rpmjsRun(0xa07fe10,Hello World!)
-- js 0xa07fe10 -- 1 expandMacro at macro.c:1931
Hello World!
[...@fedora10 wdj]$ rpm -E '%{js: 1 + 1}'
-- js 0x9c9b460 ++ 1 rpmjsNew at rpmjs.c:115
== rpmjsRun(0x9c9b460, 1 + 1)
-- js 0x9c9b460 -- 1 expandMacro at macro.c:1931
2
73 de Jeff
On Apr 17, 2009, at 6:42 PM, Jeff Johnson wrote:
RPM Package Manager, CVS Repository
http://rpm5.org/cvs/
Server: rpm5.org Name: Jeff Johnson
Root: /v/rpm/cvs Email: j...@rpm5.org
Module: rpm Date: 18-Apr-2009 00:42:14
Branch: HEAD Handle: 2009041722421101
Modified files:
rpm CHANGES configure.ac devtool.conf
rpm/rpmio rpmjs.c
Log:
- ficl: permit external ficl too.
- js: simplify the embedding to the JSAPI examples, not the js
shell.
Summary:
RevisionChanges Path
1.2944 +1 -0 rpm/CHANGES
2.367 +1 -1 rpm/configure.ac
2.291 +1 -1 rpm/devtool.conf
1.3 +34 -286rpm/rpmio/rpmjs.c
patch -p0 '@@ .'
Index: rpm/CHANGES
=
=
=
=
=
=
==
$ cvs diff -u -r1.2943 -r1.2944 CHANGES
--- rpm/CHANGES17 Apr 2009 18:42:32 - 1.2943
+++ rpm/CHANGES17 Apr 2009 22:42:11 - 1.2944
@@ -1,5 +1,6 @@
5.2a4 - 5.2b1:
+- jbj: js: simplify the embedding to the JSAPI examples, not
the js shell.
- jbj: ficl: capture stdout from ficl vm.
- jbj: ficl: wire-up %post -p ficl.
- jbj: ficl: wire-up %{ficl:...}. capturing stdout todo++ ...
@@ .
patch -p0 '@@ .'
Index: rpm/configure.ac
=
=
=
=
=
=
==
$ cvs diff -u -r2.366 -r2.367 configure.ac
--- rpm/configure.ac 17 Apr 2009 16:10:22 - 2.366
+++ rpm/configure.ac 17 Apr 2009 22:42:11 - 2.367
@@ -1276,7 +1276,7 @@
RPM_CHECK_LIB(
[FICL], [ficl],
[ficl], [ficlSystemCreate], [ficl.h],
-[no,internal:none], [ficl],
+[no,external:internal:none], [ficl],
[ if test .$RPM_CHECK_LIB_LOCATION = .internal; then
AC_DEFINE(HAVE_FICL_H, 1, [Define to 1 if you have
ficl.h])
AC_DEFINE(HAVE_LIBFICL, 1, [Define to 1 if you have the 'ficl'
library (-lficl).])
@@ .
patch -p0 '@@ .'
Index: rpm/devtool.conf
=
=
=
=
=
=
==
$ cvs diff -u -r2.290 -r2.291 devtool.conf
--- rpm/devtool.conf 17 Apr 2009 16:10:22 - 2.290
+++ rpm/devtool.conf 17 Apr 2009 22:42:11 - 2.291
@@ -92,7 +92,7 @@
--with-pthreads \
--with-libelf \
--with-selinux \
- --with-ficl=internal \
+ --with-ficl=/usr/lib:/usr/include/ficl \
--with-js=internal \
--with-python \
--with-pythonembed=/usr/lib:/usr/include/python2.5 \
@@ .
patch -p0 '@@ .'
Index: rpm/rpmio/rpmjs.c
=
=
=
=
=
=
==
$ cvs diff -u -r1.2 -r1.3 rpmjs.c
--- rpm/rpmio/rpmjs.c 17 Apr 2009 12:41:56 - 1.2
+++ rpm/rpmio/rpmjs.c 17 Apr 2009 22:42:12 - 1.3
@@ -30,270 +30,27 @@
#include debug.h
/*...@unchecked@*/
-int _rpmjs_debug = 1;
+int _rpmjs_debug = 0;
/*...@unchecked@*/ /*...@relnull@*/
rpmjs _rpmjsI = NULL;
#if defined(WITH_JS)
-
-typedef enum JSShellExitCode {
-EXITCODE_RUNTIME_ERROR = 3,
-EXITCODE_FILE_NOT_FOUND = 4,
-EXITCODE_OUT_OF_MEMORY = 5
-} JSShellExitCode;
-
-static size_t gStackChunkSize = 8192;
-static size_t gMaxStackSize = 50;
-static jsuword gStackBase;
-static size_t gScriptStackQuota = JS_DEFAULT_SCRIPT_STACK_QUOTA;
-static JSBool gEnableBranchCallback = JS_FALSE;
-static uint32 gBranchCount;
-static uint32 gBranchLimit;
-static int gExitCode = 0;
-
-static FILE *gErrFile = NULL;
-static FILE *gOutFile = NULL;
-
-static JSBool reportWarnings = JS_TRUE;
-
-/* We use a mix of JS_FS and JS_FN to test both kinds of natives. */
-static JSFunctionSpec shell_functions[] = {
-JS_FS_END
-};
-
-static JSBool
-global_enumerate(JSContext *cx, JSObject *obj)
-{
-#ifdef LAZY_STANDARD_CLASSES
-return JS_EnumerateStandardClasses(cx, obj);
-#else
-return JS_TRUE;
-#endif
-}
-
-static JSBool
-global_resolve(JSContext *cx, JSObject *obj, jsval id, uintN flags,
- JSObject **objp)
-{
-#ifdef LAZY_STANDARD_CLASSES
-if ((flags JSRESOLVE_ASSIGNING) == 0) {
-
Re: [CVS] RPM: rpm/ CHANGES configure.ac devtool.conf rpm/rpmio/ .cvsignor...
Jeff Johnson wrote: Log: - ruby: add --with-ruby for embedding ruby. Shouldn't that be --with-rubyembed then, like the others ? (Or maybe --with-embedded-ruby like you mentioned earlier.) --with-ruby should be for building the ruby bindings, yes ? (like the ones available from http://ruby-rpm.rubyforge.org/) --anders __ RPM Package Managerhttp://rpm5.org Developer Communication Listrpm-devel@rpm5.org
Re: [CVS] RPM: rpm/ CHANGES configure.ac devtool.conf rpm/rpmio/ .cvsignor...
On Apr 8, 2009, at 1:58 PM, Anders F Björklund wrote: Jeff Johnson wrote: Log: - ruby: add --with-ruby for embedding ruby. Shouldn't that be --with-rubyembed then, like the others ? (Or maybe --with-embedded-ruby like you mentioned earlier.) --with-ruby should be for building the ruby bindings, yes ? (like the ones available from http://ruby-rpm.rubyforge.org/) No clue atm. I do expect that, say, --with-perl checking for ExtUtils::Embed as a side effect is more consistent with how Ralf has done the existing rpm AutoFu (and he has already pointed that out) than the easy-to-remove and orthogonal --with-perlembed that I created^Whacked-up instead. I still haven't a clue whether (or how) embedding script interpreters is a good idea or not. All I've been doing so far is looking at feasibility, and the answer so far is Hmmm, feasible, yes, seeing is believing. 73 de Jeff__ RPM Package Managerhttp://rpm5.org Developer Communication Listrpm-devel@rpm5.org
Re: [CVS] RPM: rpm/ CHANGES configure.ac devtool.conf rpm/rpmio/ .cvsignor...
Jeff Johnson wrote: Shouldn't that be --with-rubyembed then, like the others ? (Or maybe --with-embedded-ruby like you mentioned earlier.) I still haven't a clue whether (or how) embedding script interpreters is a good idea or not. All I've been doing so far is looking at feasibility, and the answer so far is Hmmm, feasible, yes, seeing is believing. Just looked odd next to the other two, but by all means don't let that get in the way of the experimentation... I'm thinking that Tcl is about as heavy as I want myself, but that's another story. (i.e. Perl/Python/Ruby too much) --anders __ RPM Package Managerhttp://rpm5.org Developer Communication Listrpm-devel@rpm5.org
Re: [CVS] RPM: rpm/ CHANGES configure.ac devtool.conf rpm/rpmio/ .cvsignor...
Jeff Johnson wrote: I'm thinking that Tcl is about as heavy as I want myself, but that's another story. (i.e. Perl/Python/Ruby too much) If you grep WITH_TCL in rpm code (and look at rpmio/rpmtcl.[ch]), the manifestation of tcl-rpm is quite small and reasonable. [...] But I wholeheartedly agree, embedding interpreters is *VERY* conceptually heavy aven if the implementation(s) are quite straight forward. Right, I didn't meant the number of lines of interfacing code but more like the size of the interpreter requirements or the cost of invoking the interpreter (or even to keep it running) and there is the what would you need all that power for ? I can see how Lua/Tcl scriptlets could have a lower overhead than forking a shell, and how a full scripting language is better than having to jump through hoops in spec or make shell scripts when *building* the packages. But at runtime ? I'm not sure. --anders __ RPM Package Managerhttp://rpm5.org Developer Communication Listrpm-devel@rpm5.org
Re: [CVS] RPM: rpm/ CHANGES configure.ac devtool.conf rpm/rpmio/ .cvsignor...
On Apr 8, 2009, at 3:33 PM, Anders F Björklund wrote: I can see how Lua/Tcl scriptlets could have a lower overhead than forking a shell, and how a full scripting language is better than having to jump through hoops in spec or make shell scripts when *building* the packages. But at runtime ? I'm not sure. FYI: one of the data points I discovered while figgering embedding (for perl? ruby? I fergit) was a comparison between # of instantiations/sec for multiply embedded interpreters in C++ or something:. The numbers I remember (and I can/will dig out the ref if needed, but I always benchmark using rpm --stats because its easier than trying to decipher how I'm being lied to w some benchmark ... ymmv) was lua:~150 instatntiations/sec ruby~100 instantiations/sec python: ~40 intstantiations/sec I would expect that perl, which tends to have more modules to load than python, is gonna be no faster than python. And tcl was the original embedded scripting language (after forth) and so I'd expect something similar to lua for tcl interpreter instantiations. Note: instantiations/sec is meaningless if you have a persistent global interpreter. Duh. So the original choice of lua for embedding in rpm is/was quite sound if performance (and memory footprint) is/was the primary criteria. It is/was. ;-) Again, YMMV, everyone's does. But now you can __CHOOSE__ in RPM ;-) 73 de Jeff__ RPM Package Managerhttp://rpm5.org Developer Communication Listrpm-devel@rpm5.org
Re: [CVS] RPM: rpm/ CHANGES configure.ac devtool.conf rpm/rpmio/ .cvsignor...
Note that libperl.so can't be found atm because
of where it is located.
I'm working around by doing
cd /usr/lib
ln -s /usr/lib/perl5/5.10.0/i386-linux-thread-multi/CORE/libperl.so
while waiting to discover a better solution.
73 de Jeff
On Apr 7, 2009, at 1:17 PM, Jeff Johnson wrote:
RPM Package Manager, CVS Repository
http://rpm5.org/cvs/
Server: rpm5.org Name: Jeff Johnson
Root: /v/rpm/cvs Email: j...@rpm5.org
Module: rpm Date: 07-Apr-2009 19:17:22
Branch: HEAD Handle: 2009040717172100
Added files:
rpm/rpmio rpmperl.c rpmperl.h tperl.c
Modified files:
rpm CHANGES configure.ac devtool.conf
rpm/rpmio .cvsignore Makefile.am librpmio.vers
rpmio.c
rpmtcl.c rpmtcl.h
Log:
- jbj: perl: add --with-perlembed for embedding perl.
Summary:
RevisionChanges Path
1.2903 +1 -0 rpm/CHANGES
2.356 +10 -2 rpm/configure.ac
2.276 +1 -0 rpm/devtool.conf
1.35+2 -1 rpm/rpmio/.cvsignore
1.220 +8 -4 rpm/rpmio/Makefile.am
2.105 +4 -1 rpm/rpmio/librpmio.vers
1.181 +4 -0 rpm/rpmio/rpmio.c
2.1 +94 -0 rpm/rpmio/rpmperl.c
2.1 +93 -0 rpm/rpmio/rpmperl.h
2.4 +0 -1 rpm/rpmio/rpmtcl.c
2.3 +2 -2 rpm/rpmio/rpmtcl.h
2.1 +67 -0 rpm/rpmio/tperl.c
patch -p0 '@@ .'
Index: rpm/CHANGES
=
=
=
=
=
=
==
$ cvs diff -u -r1.2902 -r1.2903 CHANGES
--- rpm/CHANGES6 Apr 2009 23:43:17 - 1.2902
+++ rpm/CHANGES7 Apr 2009 17:17:21 - 1.2903
@@ -1,5 +1,6 @@
5.2a3 - 5.2a4:
+- jbj: perl: add --with-perlembed for embedding perl.
- jbj: tcl: wire-up %post -p tcl. arg1/arg2, persistent
interp, todo++.
- jbj: tcl: wire-up %{tcl:...} with a string result.
- jbj: tcl: add --with-tcl for embedding tcl.
@@ .
patch -p0 '@@ .'
Index: rpm/configure.ac
=
=
=
=
=
=
==
$ cvs diff -u -r2.355 -r2.356 configure.ac
--- rpm/configure.ac 7 Apr 2009 14:39:42 - 2.355
+++ rpm/configure.ac 7 Apr 2009 17:17:21 - 2.356
@@ -918,8 +918,8 @@
fi
AC_ARG_WITH(perl, AS_HELP_STRING([--with-perl], [build with RPM
Perl language bindings]), [
if test .$withval != .no; then
- PERL_INSTALLDIRS=
- if test $withval == vendor; then
+ PERL_INSTALLDIRS=
+ if test $withval == vendor; then
PERL_INSTALLDIRS='INSTALLDIRS'= 'vendor',
fi
if test $withval == site; then
@@ -1240,6 +1240,14 @@
])
AC_SUBST(DBAPI)
+dnl # Perl ExtUtils::Embed
+RPM_CHECK_LIB(
+[Perl ExtUtils::Embed], [perlembed],
+[perl], [perl_alloc], [perl.h],
+[no,external:none], [],
+[
+], [])
+
dnl # Tcl
RPM_CHECK_LIB(
[Tcl], [tcl],
@@ .
patch -p0 '@@ .'
Index: rpm/devtool.conf
=
=
=
=
=
=
==
$ cvs diff -u -r2.275 -r2.276 devtool.conf
--- rpm/devtool.conf 6 Apr 2009 20:34:09 - 2.275
+++ rpm/devtool.conf 7 Apr 2009 17:17:21 - 2.276
@@ -94,6 +94,7 @@
--with-selinux \
--with-python \
--with-perl \
+--with-perlembed=/usr/lib/perl5/5.10.0/i386-linux-thread-
multi/CORE \
--with-build-extlibdep \
--with-build-maxextlibdep \
--enable-build-pic \
@@ .
patch -p0 '@@ .'
Index: rpm/rpmio/.cvsignore
=
=
=
=
=
=
==
$ cvs diff -u -r1.34 -r1.35 .cvsignore
--- rpm/rpmio/.cvsignore 6 Apr 2009 20:34:10 - 1.34
+++ rpm/rpmio/.cvsignore 7 Apr 2009 17:17:21 - 1.35
@@ -42,8 +42,9 @@
tmacro
tmagic
tmire
-tpw
+tperl
tput
+tpw
tring
trpmio
tsw
@@ .
patch -p0 '@@ .'
Index: rpm/rpmio/Makefile.am
=
=
=
=
=
=
==
$ cvs diff -u -r1.219 -r1.220 Makefile.am
--- rpm/rpmio/Makefile.am 6 Apr 2009 20:34:10 - 1.219
+++ rpm/rpmio/Makefile.am 7 Apr 2009 17:17:21 - 1.220
@@ -18,7 +18,7 @@
rpmgenbasedir rpmgenpkglist rpmgensrclist rpmgpg \
rpmpbzip2 rpmpigz rpmtar rpmz \
tdir tfts tget tglob thkp thtml tinv tkey tmacro tmagic tmire \
- tput tpw trpmio tsw ttcl dumpasn1 lookup3
+ tperl tput tpw trpmio tsw ttcl dumpasn1 lookup3
bin_PROGRAMS =
Re: [CVS] RPM: rpm/ CHANGES configure.ac devtool.conf rpm/rpmio/ .cvsignor...
On Tue, Apr 07, 2009, Jeff Johnson wrote:
Note that libperl.so can't be found atm because
of where it is located.
I'm working around by doing
cd /usr/lib
ln -s /usr/lib/perl5/5.10.0/i386-linux-thread-multi/CORE/libperl.so
while waiting to discover a better solution.
You can use Perl's Config module to figure out this directory:
$ perl -e 'use Config; print $Config{installarchlib}/CORE;'
For newer Perl's (5.8 and 5.10 at least AFAIK) ExtUtils::Embed is
available for figuring out the right way to embed Perl, too. For
instance:
$ perl -MExtUtils::Embed -e ldopts
Ralf S. Engelschall
r...@engelschall.com
www.engelschall.com
__
RPM Package Managerhttp://rpm5.org
Developer Communication Listrpm-devel@rpm5.org
Re: [CVS] RPM: rpm/ CHANGES configure.ac devtool.conf rpm/rpmio/ .cvsignor...
On Tue, Apr 07, 2009, Jeff Johnson wrote: [...] - jbj: perl: add --with-perlembed for embedding perl. An extra option is not necessary. A simple --with-perl is sufficient. Everything else can be correctly and more conveniently figured out via Config or ExtUtils::Embed. Also notice that for portably embedding Perl one might need more -lfoo's and only Perl itself knows about all this. Ralf S. Engelschall r...@engelschall.com www.engelschall.com __ RPM Package Managerhttp://rpm5.org Developer Communication Listrpm-devel@rpm5.org
Re: [CVS] RPM: rpm/ CHANGES configure.ac devtool.conf rpm/rpmio/ .cvsignor...
On Apr 7, 2009, at 5:53 PM, Ralf S. Engelschall wrote:
On Tue, Apr 07, 2009, Jeff Johnson wrote:
Note that libperl.so can't be found atm because
of where it is located.
I'm working around by doing
cd /usr/lib
ln -s /usr/lib/perl5/5.10.0/i386-linux-thread-multi/CORE/libperl.so
while waiting to discover a better solution.
You can use Perl's Config module to figure out this directory:
$ perl -e 'use Config; print $Config{installarchlib}/CORE;'
For newer Perl's (5.8 and 5.10 at least AFAIK) ExtUtils::Embed is
available for figuring out the right way to embed Perl, too. For
instance:
$ perl -MExtUtils::Embed -e ldopts
The issue is LD_LIBRARY_PATH when executing, not anything to
do with building.
Sure /etc/ld.so.conf is there, just an annoyance atm.
73 de Jeff
__
RPM Package Managerhttp://rpm5.org
Developer Communication Listrpm-devel@rpm5.org
Re: [CVS] RPM: rpm/ CHANGES configure.ac devtool.conf rpm/rpmio/ .cvsignor...
On Apr 7, 2009, at 5:59 PM, Ralf S. Engelschall wrote: On Tue, Apr 07, 2009, Jeff Johnson wrote: [...] - jbj: perl: add --with-perlembed for embedding perl. An extra option is not necessary. A simple --with-perl is sufficient. Everything else can be correctly and more conveniently figured out via Config or ExtUtils::Embed. Also notice that for portably embedding Perl one might need more -lfoo's and only Perl itself knows about all this. I considered but ... Up till now --with-perl meant build with perl bindings, not embed a perl interpreter. I chose a new --with-perlembed option because I still haven't a clue where this embedding is headed. The bloatery associated with embedding lua+tcl+perl+python+... terrifies me still. 73 de Jeff __ RPM Package Managerhttp://rpm5.org Developer Communication Listrpm-devel@rpm5.org
Re: [CVS] RPM: rpm/ CHANGES configure.ac devtool.conf rpm/rpmio/ .cvsignor...
In order to work around the '.' which
is not (yet ;-) handled by RPM_CHECK_LIB(),
I had to do this
cd /usr/lib
ln -s libpython2.5.so.1.0 libpython.so
For consistent hacks-R-us!, I also did
cd /usr/include
ln -s python2.5 python
hth
73 de Jeff
On Apr 7, 2009, at 6:57 PM, Jeff Johnson wrote:
RPM Package Manager, CVS Repository
http://rpm5.org/cvs/
Server: rpm5.org Name: Jeff Johnson
Root: /v/rpm/cvs Email: j...@rpm5.org
Module: rpm Date: 08-Apr-2009 00:57:48
Branch: HEAD Handle: 2009040722574701
Added files:
rpm/rpmio rpmpython.c rpmpython.h tpython.c
Modified files:
rpm CHANGES configure.ac devtool.conf
rpm/rpmio .cvsignore Makefile.am librpmio.vers
poptIO.c
rpmio.c ttcl.c
Log:
- python: add --with-pythonembed for embedding python.
Summary:
RevisionChanges Path
1.2906 +1 -0 rpm/CHANGES
2.357 +8 -1 rpm/configure.ac
2.277 +1 -0 rpm/devtool.conf
1.36+1 -0 rpm/rpmio/.cvsignore
1.221 +6 -3 rpm/rpmio/Makefile.am
2.106 +4 -0 rpm/rpmio/librpmio.vers
1.39+13 -1 rpm/rpmio/poptIO.c
1.182 +4 -0 rpm/rpmio/rpmio.c
2.1 +99 -0 rpm/rpmio/rpmpython.c
2.1 +104 -0 rpm/rpmio/rpmpython.h
2.1 +54 -0 rpm/rpmio/tpython.c
2.3 +0 -1 rpm/rpmio/ttcl.c
patch -p0 '@@ .'
Index: rpm/CHANGES
=
=
=
=
=
=
==
$ cvs diff -u -r1.2905 -r1.2906 CHANGES
--- rpm/CHANGES7 Apr 2009 17:57:04 - 1.2905
+++ rpm/CHANGES7 Apr 2009 22:57:47 - 1.2906
@@ -1,5 +1,6 @@
5.2a3 - 5.2a4:
+- jbj: python: add --with-pythonembed for embedding python.
- jbj: perl: wire-up %post -p perl. arg1/arg2, persistent
interp, todo++.
- jbj: perl: wire-up %{perl:...} with a string result.
- jbj: perl: add --with-perlembed for embedding perl.
@@ .
patch -p0 '@@ .'
Index: rpm/configure.ac
=
=
=
=
=
=
==
$ cvs diff -u -r2.356 -r2.357 configure.ac
--- rpm/configure.ac 7 Apr 2009 17:17:21 - 2.356
+++ rpm/configure.ac 7 Apr 2009 22:57:47 - 2.357
@@ -1248,6 +1248,14 @@
[
], [])
+dnl # Python embedding
+RPM_CHECK_LIB(
+[Python embedding], [pythonembed],
+[python], [Py_Initialize], [Python.h],
+[no,external:none], [],
+[
+], [])
+
dnl # Tcl
RPM_CHECK_LIB(
[Tcl], [tcl],
@@ -1794,7 +1802,6 @@
dnl # determine whether to build using a specific vendor's changes
or not
AC_MSG_CHECKING([if building for a specfic vendor])
-
AC_ARG_WITH(
[vendor],
AS_HELP_STRING([--with-vendor=VENDOR], [build with a supported
vendor's specific set of changes: mandriva, ark, fedora]),
@@ .
patch -p0 '@@ .'
Index: rpm/devtool.conf
=
=
=
=
=
=
==
$ cvs diff -u -r2.276 -r2.277 devtool.conf
--- rpm/devtool.conf 7 Apr 2009 17:17:21 - 2.276
+++ rpm/devtool.conf 7 Apr 2009 22:57:47 - 2.277
@@ -93,6 +93,7 @@
--with-libelf \
--with-selinux \
--with-python \
+--with-pythonembed=/usr/lib:/usr/include/python \
--with-perl \
--with-perlembed=/usr/lib/perl5/5.10.0/i386-linux-thread-
multi/CORE \
--with-build-extlibdep \
@@ .
patch -p0 '@@ .'
Index: rpm/rpmio/.cvsignore
=
=
=
=
=
=
==
$ cvs diff -u -r1.35 -r1.36 .cvsignore
--- rpm/rpmio/.cvsignore 7 Apr 2009 17:17:21 - 1.35
+++ rpm/rpmio/.cvsignore 7 Apr 2009 22:57:48 - 1.36
@@ -45,6 +45,7 @@
tperl
tput
tpw
+tpython
tring
trpmio
tsw
@@ .
patch -p0 '@@ .'
Index: rpm/rpmio/Makefile.am
=
=
=
=
=
=
==
$ cvs diff -u -r1.220 -r1.221 Makefile.am
--- rpm/rpmio/Makefile.am 7 Apr 2009 17:17:21 - 1.220
+++ rpm/rpmio/Makefile.am 7 Apr 2009 22:57:48 - 1.221
@@ -18,7 +18,7 @@
rpmgenbasedir rpmgenpkglist rpmgensrclist rpmgpg \
rpmpbzip2 rpmpigz rpmtar rpmz \
tdir tfts tget tglob thkp thtml tinv tkey tmacro tmagic tmire \
- tperl tput tpw trpmio tsw ttcl dumpasn1 lookup3
+ tperl tpython tput tpw trpmio tsw ttcl dumpasn1 lookup3
bin_PROGRAMS =
man_MANS =
@@ -66,7 +66,7 @@
salsa10.h salsa20.h tiger.h
Re: [CVS] RPM: rpm/ CHANGES configure.ac
On Monday, 16 March 2009, at 22:47:04 (+0100),
Per ?yvind Karlsen wrote:
patch -p0 '@@ .'
Index: rpm/configure.ac
$ cvs diff -u -r2.344 -r2.345 configure.ac
--- rpm/configure.ac11 Mar 2009 22:03:06 - 2.344
+++ rpm/configure.ac16 Mar 2009 21:47:03 - 2.345
@@ -1632,7 +1632,7 @@
dnl # determine RPM buildroot directory path
AC_MSG_CHECKING([for RPM buildroot directory])
-BUILDROOTDIR_MACRO=%{_tmppath}
+BUILDROOTDIR_MACRO=%{_topdir}/BUILDROOT
AC_ARG_WITH(
[path-buildroot],
AS_HELP_STRING([--with-path-buildroot=ARG], [build with RPM buildroot
path (or macro)]),
@@ .
Please don't do this. A temporary directory, not something under
$HOME, really is the correct default for this.
Michael
--
Michael Jennings (a.k.a. KainX) http://www.kainx.org/ m...@kainx.org
Linux Server/Cluster Admin, LBL.gov Author, Eterm (www.eterm.org)
---
Love, like a road that never ends. How it leads me back again to
heartache, I don't understand.
-- Peter Cetera and Amy Grant, Next Time I Fall
__
RPM Package Managerhttp://rpm5.org
Developer Communication Listrpm-devel@rpm5.org
Re: [CVS] RPM: rpm/ CHANGES configure.ac rpm/perl/ Makefile.PL.in
2009/3/12 Ralf S. Engelschall rse+rpm-de...@rpm5.orgrse%2brpm-de...@rpm5.org On Wed, Mar 11, 2009, Per Øyvind Karlsen wrote: perl: make sure to link against all required libraries to fix build with --no-undefined. (probably room for improval..) Yes, and it has to be improved because linking -lpthread breaks on platforms where Pthreads are part of libc and no extra libpthread is existing! So, this really fixes your particular situation and unfortunately breaks others... The correct solution is to improve the --with-pthread handling itself and then use just its results. Ah, I suck at with autoconf, I already spent some time on figuring out how to best deal with this, especially since I noted that it also might link against a libthread library if present.. I ended up figuring that it at least would always link against pthread and that wouldn't break any stuff by always linking perl module against, but I see now that the check for pthread library doesn't make it mandatory.. I'll try do better. :) -- Regards, Per Øyvind
Re: [CVS] RPM: rpm/ CHANGES configure.ac rpm/perl/ Makefile.PL.in
On Mar 14, 2009, at 12:07 PM, Per Øyvind Karlsen wrote: 2009/3/12 Ralf S. Engelschall rse+rpm-de...@rpm5.org On Wed, Mar 11, 2009, Per Øyvind Karlsen wrote: perl: make sure to link against all required libraries to fix build with --no-undefined. (probably room for improval..) Yes, and it has to be improved because linking -lpthread breaks on platforms where Pthreads are part of libc and no extra libpthread is existing! So, this really fixes your particular situation and unfortunately breaks others... The correct solution is to improve the --with-pthread handling itself and then use just its results. Ah, I suck at with autoconf, I already spent some time on figuring out how to best deal with this, especially since I noted that it also might link against a libthread library if present.. I ended up figuring that it at least would always link against pthread and that wouldn't break any stuff by always linking perl module against, but I see now that the check for pthread library doesn't make it mandatory.. FWIW, pthreads (or lack thereof) needs to be buried opaquely in yarn.c, with -lpthreads (or not) attached to -lrpmio linkage with pkgconfig or (any other means of discovering what compile/linkage flags are needed like librpmio.la) to use -lrpmio. There's a hugely complicated combinatorial failure if AutoFu alone is used to distribute configuration flags across various attached meta-components like rpm-perl and rpm-python that won't ever work well if/when components (like rpm-perl and rpm-python) are built outside of the rpm tarball/tree itself. hth 73 de Jeff
Re: [CVS] RPM: rpm/ CHANGES configure.ac rpm/perl/ Makefile.PL.in
On Wed, Mar 11, 2009, Per Øyvind Karlsen wrote: perl: make sure to link against all required libraries to fix build with --no-undefined. (probably room for improval..) Yes, and it has to be improved because linking -lpthread breaks on platforms where Pthreads are part of libc and no extra libpthread is existing! So, this really fixes your particular situation and unfortunately breaks others... The correct solution is to improve the --with-pthread handling itself and then use just its results. Ralf S. Engelschall r...@engelschall.com www.engelschall.com __ RPM Package Managerhttp://rpm5.org Developer Communication Listrpm-devel@rpm5.org
Re: [CVS] RPM: rpm/ CHANGES configure.ac
On Sat, Nov 01, 2008, Jeff Johnson wrote: If you want better doco, then write better doco on how to use rpm5.org on Mandriva. Adding --with-vendor does nothing except what CPPFLAGS=-DRPM_VENDOR_MANDRIVA already does. [...] But I don't see how adding Yet More AutoFu changes much of anything at all. I agree. We even intentionally added no such Autoconf option initially, because the vendor stuff in the RPM 5 source tree is not meant to be official or something from the rpm5.org point of view. We just carry the vendor changes with us so they are not lost and we see what is required. But I personally also think CPPFLAGS=-DRPM_VENDOR_ is the right approach as all this stuff is not intended for regular end-users. It is really intended for the vendor's developers only and they are just fine with CPPFLAGS=-DRPM_VENDOR_. So, I personally would like to see a backout of this change... Ralf S. Engelschall [EMAIL PROTECTED] www.engelschall.com __ RPM Package Managerhttp://rpm5.org Developer Communication Listrpm-devel@rpm5.org
Re: [CVS] RPM: rpm/ CHANGES configure.ac
What is wrong with CPPFLAGS=-DRPM_VENDOR_MANDRIVA Its insane to have Yet More Ways to configure stuff imho. 73 de Jeff On Nov 1, 2008, at 6:41 PM, Per Øyvind Karlsen wrote: RPM Package Manager, CVS Repository http://rpm5.org/cvs/ Server: rpm5.org Name: Per Øyvind Karlsen Root: /v/rpm/cvs Email: [EMAIL PROTECTED] Module: rpm Date: 01-Nov-2008 23:41:44 Branch: HEAD Handle: 2008110122414300 Modified files: rpm CHANGES configure.ac Log: add --with-vendor configure option to define RPM_VENDOR_*. Summary: RevisionChanges Path 1.2640 +1 -0 rpm/CHANGES 2.319 +28 -0 rpm/configure.ac patch -p0 '@@ .' Index: rpm/CHANGES = = = = = = == $ cvs diff -u -r1.2639 -r1.2640 CHANGES --- rpm/CHANGES1 Nov 2008 19:32:04 - 1.2639 +++ rpm/CHANGES1 Nov 2008 22:41:43 - 1.2640 @@ -1,5 +1,6 @@ 5.2a2 - 5.2a3: +- proyvind: add --with-vendor configure option to define RPM_VENDOR_*. - proyvind: Mandriva: make loglevel for dependency loop detection overridable, debug-level by default. (loop-detection-optional- loglevel) - jbj: fix: __OpenBSD__ insque(3) needs rpmsq rock initialized. @@ . patch -p0 '@@ .' Index: rpm/configure.ac = = = = = = == $ cvs diff -u -r2.318 -r2.319 configure.ac --- rpm/configure.ac 19 Oct 2008 07:46:48 - 2.318 +++ rpm/configure.ac 1 Nov 2008 22:41:43 - 2.319 @@ -1636,6 +1636,34 @@ AC_SUBST(RPMLUAFILES) AC_MSG_RESULT([$RPMLUAFILES]) +dnl # determine whether to build using a specific vendor's changes or not +AC_MSG_CHECKING([if building for a specfic vendor]) + +AC_ARG_WITH( +[vendor], +AS_HELP_STRING([--with-vendor=VENDOR], [build with a supported vendor's specific set of changes: openpkg, rpm4darwin, fedora, mandriva or windriver]), +if test .$withval != .no; then + if test $withval == openpkg; then + AC_DEFINE([RPM_VENDOR_OPENPKG], 1, Vendor is OpenPKG) + fi + if test $withval == rpm4darwin; then + AC_DEFINE([RPM_VENDOR_RPM4DARWIN], 1, Vendor is RPM for Darwin) + fi + if test $withval == fedora; then + AC_DEFINE([RPM_VENDOR_FEDORA], 1, Vendor is Fedora) + fi + if test $withval == mandriva; then + AC_DEFINE([RPM_VENDOR_MANDRIVA], 1, Vendor is Mandriva) + fi + if test $withval == windriver; then + AC_DEFINE([RPM_VENDOR_WINDRIVER], 1, Vendor is Windriver) + fi + AC_MSG_RESULT([$withval]) +else + AC_MSG_RESULT(no) +fi +) + testdir=`pwd`/tests AC_SUBST(testdir) @@ . __ RPM Package Managerhttp://rpm5.org CVS Sources Repository[EMAIL PROTECTED] __ RPM Package Managerhttp://rpm5.org Developer Communication Listrpm-devel@rpm5.org
Re: [CVS] RPM: rpm/ CHANGES configure.ac
2008/11/1 Jeff Johnson [EMAIL PROTECTED] What is wrong with CPPFLAGS=-DRPM_VENDOR_MANDRIVA Its insane to have Yet More Ways to configure stuff imho. 73 de Jeff It's hidden from regular user who'd like to build rpm himself for that specific vendor. Maybe not such an important thing for rpm devels, but I know that if I were to build rpm5 myself for ie. Mandriva without being involved in rpm development nor reading through source just for fun, I'd like to easily find and use the suitable option to pick what to be considered the most proper adaptions using './configure --help'. Moreover, personally, I just find it nicer and more intuitive than passing either CPPFLAGS, or adding it to config.h.. ;)
Re: [CVS] RPM: rpm/ CHANGES configure.ac
On Nov 1, 2008, at 7:19 PM, Per Øyvind Karlsen wrote: 2008/11/1 Jeff Johnson [EMAIL PROTECTED] What is wrong with CPPFLAGS=-DRPM_VENDOR_MANDRIVA Its insane to have Yet More Ways to configure stuff imho. 73 de Jeff It's hidden from regular user who'd like to build rpm himself for that specific vendor. Hidden? Adding another option is no substitute for identifying exactly the functionality desired in Mandriva. If you want better doco, then write better doco on how to use rpm5.org on Mandriva. Adding --with-vendor does nothing except what CPPFLAGS=-DRPM_VENDOR_MANDRIVA already does. I don't see any additional benefit from adding an enumeration for vendors that are, in fact, hardly likely to adopt rpm5.org any time soon. Not that Mandriva uses rpm5.org, nor is Mandriva expected to change from rpm.org. So what purpose is served? If --with-vendor=mandriva did anything useful, like identifying specific components that should be included when building, I might be saying something else. But there is already devtool, which can add an entire collection of configure options when invoking rpm5.org ./configure. Try adding a %mandriva stanza to devtool.conf. Maybe not such an important thing for rpm devels, but I know that if I were to build rpm5 myself for ie. Mandriva without being involved in rpm development nor reading through source just for fun, I'd like to easily find and use the suitable option to pick what to be considered the most proper adaptions using './configure -- help'. I couldn't care less about yjr AutoFu. But adding --with-vendor=fedora is hardly the same thing as claiming Fedora support. Fedora has most definitely said that rpm5.org is not permitted in the Fedora distro without being crippled. I see no reason to pretend support --with-vendor=fedora for a distro that wants to cripple rpm5.org functionality. And I'm quite sure that rpm5.org would not be permitted in Fedora no matter what. The criteria would just change to Now that we've crippled rpm5.org so that its useless, do we really need to include in Fedora? Moreover, personally, I just find it nicer and more intuitive than passing either CPPFLAGS, or adding it to config.h.. ;) So have at. But I don't see how adding Yet More AutoFu changes much of anything at all. 73 de Jeff
Re: [CVS] RPM: rpm/ CHANGES configure.ac rpm/misc/ Makefile.am asprintf.h ...
On Jul 29, 2008, at 7:24 AM, devzero2000 wrote: On Mon, Jul 28, 2008 at 4:53 PM, Jeff Johnson [EMAIL PROTECTED] wrote: This likely needs some context ... rpmmtree derived from BSD still has some *BSD peculier API usages, strtouq(), asprintf() and strvis() just to mention some of the portability issues. Normally I'd just rewrite rpmmtree.c to avoid the portability issues, and will likely do that with rpmmtree(8) somewhen soon as well. However, rpm.org is making heavy usage of something called rasprintf, so some sort of malloc'ing printf simplifies stealing code from rpm.org. I prefer the well known asprintf(3) API, which is often present in system libraries, to a home rolled custom malloc'ing printf gadget API. strtouq(3) is almost certainly going to have some portability issues somewhere (my guess). Dunno the best answer, time to find out. http://mirbsd.org/htman/i386/man3/strtoul.htm So it is possibile to use strtoul(3) in place of strouq. And strtoul is more portable , standard (C99) compliant The problem reported needs solving on QNX, which either does not have strtoul, or (more likely) that the sizeof(unsigned long) sizeof(off_t). The strtouq() is being used to convert st-st_size in a stat(2) structure. But yes strtoul() is likely more portable than strtouq(). And I still don't know what to do with the strvis(3) usages in rpmmtree. Internal to rpmmtree a while longer hurts little for now. Perhaps it is necessary to introduce libedit, that have the implementation of strvis, internal to RPM - for portabilty. Or, perhaps better, to use internal only the strvis function of vis.c in libedit http://koji.fedoraproject.org/packages/libedit/2.11/1.20080712cvs.fc10/src/libedit-2.11-1.20080712cvs.fc10.src.rpm Yes, libedit is the library where where strvis() is usually found on Linux. But there's portability to other non-linux platforms needed too, and tying rpmmtree = -ledit in order to use strvis() limits where rpmmtree can be compiled. Personally, strvis(3) does not seem to be a very useful function imho. I would have rewritten rpmmtree to eliminate strvis(3) usage already if strvis(3) were used directly in rpm code paths. Interoperability with system mtree(8) on Mac OS X and *BSD is what caused me to leave strvis(3) within rpmmtree. So there's lots of solutions, just no clear indication of which solution is best yet. hth 73 de Jeff
Re: [CVS] RPM: rpm/ CHANGES configure.ac rpm/misc/ Makefile.am asprintf.h ...
This likely needs some context ...
rpmmtree derived from BSD still has some *BSD peculier API usages,
strtouq(), asprintf() and strvis()
just to mention some of the portability issues.
Normally I'd just rewrite rpmmtree.c to avoid the portability issues,
and will likely do that with
rpmmtree(8) somewhen soon as well.
However, rpm.org is making heavy usage of something called
rasprintf, so some sort
of malloc'ing printf simplifies stealing code from rpm.org. I prefer
the well known asprintf(3) API,
which is often present in system libraries, to a home rolled custom
malloc'ing printf gadget API.
strtouq(3) is almost certainly going to have some portability issues
somewhere (my guess). Dunno
the best answer, time to find out.
And I still don't know what to do with the strvis(3) usages in
rpmmtree. Internal to rpmmtree
a while longer hurts little for now.
hth
73 de Jeff
On Jul 28, 2008, at 10:35 AM, Jeff Johnson wrote:
RPM Package Manager, CVS Repository
http://rpm5.org/cvs/
__
__
Server: rpm5.org Name: Jeff Johnson
Root: /v/rpm/cvs Email: [EMAIL PROTECTED]
Module: rpm Date: 28-Jul-2008
16:35:27
Branch: HEAD Handle: 2008072814352501
Added files:
rpm/miscasprintf.h
Modified files:
rpm CHANGES configure.ac
rpm/miscMakefile.am
rpm/rpmdb rpmdb.c sqlite.c
rpm/tools rpmmtree.c
Log:
- QNX: use strtouq() instead of strtoul() in rpmmtree.
- QNX: retrofit asprintf.h (from XAR) for the deprived.
rpmmtree uses
(rewrite to eliminate asprintf is an alternative).
- QNX: supply missing typedef's for uint32_t.
Summary:
RevisionChanges Path
1.2509 +4 -0 rpm/CHANGES
2.305 +1 -1 rpm/configure.ac
1.34+1 -1 rpm/misc/Makefile.am
1.1 +92 -0 rpm/misc/asprintf.h
1.253 +1 -1 rpm/rpmdb/rpmdb.c
1.34+1 -1 rpm/rpmdb/sqlite.c
2.3 +10 -2 rpm/tools/rpmmtree.c
__
__
patch -p0 '@@ .'
Index: rpm/CHANGES
==
==
$ cvs diff -u -r1.2508 -r1.2509 CHANGES
--- rpm/CHANGES 20 Jul 2008 00:04:51 - 1.2508
+++ rpm/CHANGES 28 Jul 2008 14:35:25 - 1.2509
@@ -1,5 +1,9 @@
5.1.0 - 5.2a0:
+- jbj: QNX: use strtouq() instead of strtoul() in rpmmtree.
+- jbj: QNX: retrofit asprintf.h (from XAR) for the deprived.
rpmmtree uses
+ (rewrite to eliminate asprintf is an alternative).
+- jbj: QNX: supply missing typedef's for uint32_t.
- jbj: add alternative %{sparcx} macro shorthand (bz #455972).
- jbj: rpmio: add new link/unlink methods to loader map.
- jbj: python: add rpm.Keyring/rpm.Pubkey subtype methods
for rpmkeyring.
@@ .
patch -p0 '@@ .'
Index: rpm/configure.ac
==
==
$ cvs diff -u -r2.304 -r2.305 configure.ac
--- rpm/configure.ac 15 Jul 2008 18:57:09 - 2.304
+++ rpm/configure.ac 28 Jul 2008 14:35:25 - 2.305
@@ -686,7 +686,7 @@
dnl checks for library functions (generic)
AC_CHECK_FUNCS([dnl
-basename getaddrinfo getcwd getnameinfo getwd iconv
inet_aton confstr dnl
+asprintf basename getaddrinfo getcwd getnameinfo getwd iconv
inet_aton confstr dnl
mtrace putenv realpath setenv clearenv stpcpy stpncpy
strcspn strdup dnl
strndup strerror strtol strtoul strspn strstr sighold
sigrelse sigpause dnl
sigprocmask sigemptyset sigaddset sigdelset sigsuspend
madvise dnl
@@ .
patch -p0 '@@ .'
Index: rpm/misc/Makefile.am
==
==
$ cvs diff -u -r1.33 -r1.34 Makefile.am
--- rpm/misc/Makefile.am 28 Apr 2008 16:40:28 - 1.33
+++ rpm/misc/Makefile.am 28 Jul 2008 14:35:26 - 1.34
@@ -7,7 +7,7 @@
-I$(top_srcdir)
EXTRA_DIST = \
- librpmmisc.vers \
+ librpmmisc.vers asprintf.h \
alloca.cbasename.c err.c error.c \
fakefork.c fnmatch.c getcwd.cgetmntent.c \
getwd.c glob.c memcmp.c\
@@ .
patch -p0 '@@ .'
Index: rpm/misc/asprintf.h
==
==
$ cvs diff -u -r0 -r1.1 asprintf.h
--- /dev/null 2008-07-28 16:33:00 +0200
+++ asprintf.h2008-07-28 16:35:26 +0200
@@ -0,0 +1,92 @@
+//
==
Re: [CVS] RPM: rpm/ CHANGES configure.ac rpm/misc/ Makefile.am asprintf.h ...
On Jul 28, 2008, at 11:10 AM, Ralf S. Engelschall wrote:
On Mon, Jul 28, 2008, Jeff Johnson wrote:
[...]
@@ -0,0 +1,92 @@
+//
=
=
+//
+// Copyright (C) 2005 Jason Evans [EMAIL PROTECTED]. All
rights reserved.
+//
[...]
You are sure we already want C++/C99-style comments in the RPM code
base?
I'm quite sure that we dinna want the original patch as sent:
--- tools/rpmmtree.c.orig 2008-07-24 15:03:04.0 +0200
+++ tools/rpmmtree.c2008-07-24 15:06:55.0 +0200
@@ -53,6 +53,10 @@
#definest_mtimespecst_mtim
#endif
+#if defined(__QNXNTO__)
+#definest_mtimespecst_mtime
+#endif
+
#include rpmio_internal.h/* XXX fdInitDigest() et al */
#include fts.h
#include ugid.h
@@ -69,6 +73,11 @@
#include rpmts.h
#endif
+#include config.h
+#ifndef HAVE_ASPRINTF
+#include ../xar/lib/asprintf.h
+#endif
+
#defineRPM_LIST_HEAD(name, type) \
struct name { struct type *lh_first; }
#defineRPM_LIST_ENTRY(type) \
@@ -1015,7 +1024,7 @@
/*==*/
/* XXX *BSD systems already have getmode(3) and setmode(3) */
-#if defined(__linux__) || defined(__LCLINT__)
+#if defined(__linux__) || defined(__LCLINT__) || defined(__QNXNTO__)
#if !defined(HAVE_GETMODE) || !defined(HAVE_SETMODE)
#defineSET_LEN 6 /* initial # of bitcmd
struct to malloc */
@@ -1500,7 +1509,7 @@
/[EMAIL PROTECTED]@*/ break;
case MTREE_KEYS_SIZE:
/[EMAIL PROTECTED]@*/
- ip-sb.st_size = strtouq(val, ep, 10);
+ ip-sb.st_size = strtoul(val, ep, 10);
/[EMAIL PROTECTED]@*/
if (*ep != '\0')
mtree_error(invalid size %s, val);
todo++, thanks for noticing.
73 de Jeff
Ralf S. Engelschall
[EMAIL PROTECTED]
www.engelschall.com
__
RPM Package Managerhttp://rpm5.org
Developer Communication Listrpm-devel@rpm5.org
__
RPM Package Managerhttp://rpm5.org
Developer Communication Listrpm-devel@rpm5.org
Re: [CVS] RPM: rpm/ CHANGES configure.ac rpm/rpmio/ md4.c rmd128.c rmd160....
On Jul 19, 2007, at 3:40 PM, Jeff Johnson wrote: Run-time, not compile-time, endian detection please. Never mind. Those crypto digests are following beecrypt, not rpm, programming practice. So the beecr5ypt programming paradigm is #if WORDS_BIGENDIAN 73 de Jeff __ RPM Package Managerhttp://rpm5.org Developer Communication Listrpm-devel@rpm5.org
Re: [CVS] RPM: rpm/ CHANGES configure.ac rpm/rpmio/ md4.c rmd128.c rmd160....
On Thu, Jul 19, 2007, Jeff Johnson wrote: On Jul 19, 2007, at 3:40 PM, Jeff Johnson wrote: Run-time, not compile-time, endian detection please. Never mind. Those crypto digests are following beecrypt, not rpm, programming practice. So the beecr5ypt programming paradigm is #if WORDS_BIGENDIAN Yes, I know. I've explicitly checked beforehand from where WORDS_BIGENDIAN came and have seen that is an Autoconf check present in BeeCrypt's configure but which was missing on our side. As a side-effect our side was broken although the code itself followed just fine the BeeCrypt coding practice. But as it is compiled outside the BeeCrypt build environment we have to provide the missing pieces ourself... Ralf S. Engelschall [EMAIL PROTECTED] www.engelschall.com __ RPM Package Managerhttp://rpm5.org Developer Communication Listrpm-devel@rpm5.org
Re: [CVS] RPM: rpm/ CHANGES configure.ac rpm/rpmio/ md4.c rmd128.c rmd160....
On Jul 19, 2007, at 3:50 PM, Ralf S. Engelschall wrote: On Thu, Jul 19, 2007, Jeff Johnson wrote: On Jul 19, 2007, at 3:40 PM, Jeff Johnson wrote: Run-time, not compile-time, endian detection please. Never mind. Those crypto digests are following beecrypt, not rpm, programming practice. So the beecr5ypt programming paradigm is #if WORDS_BIGENDIAN Yes, I know. I've explicitly checked beforehand from where WORDS_BIGENDIAN came and have seen that is an Autoconf check present in BeeCrypt's configure but which was missing on our side. As a side- effect our side was broken although the code itself followed just fine the BeeCrypt coding practice. But as it is compiled outside the BeeCrypt build environment we have to provide the missing pieces ourself... Ah, like missing HAVE_MMAP. My apologies for the noise. How do you notice these things btw? ;-) 73 de Jeff __ RPM Package Managerhttp://rpm5.org Developer Communication Listrpm-devel@rpm5.org
Re: [CVS] RPM: rpm/ CHANGES configure.ac rpm/rpmdb/ Makefile.am
On Jun 29, 2007, at 12:44 PM, Tim Mooney wrote: Why don't you include an rpm-bug-report script, a la bashbug, that automates much of that, including relevant information about how rpm was configured, the environment, etc, and then update the docs and begin to encourage users to use that for bug reporting? The problem with diagnosing rpm problems is capturing sufficient data. Most bug reports go something like blah blah 800 pkgs blah blah upgrade blah blah doesn't work. But that's not a reason not to add a means to report bugs. 73 de Jeff Tim -- Tim Mooney[EMAIL PROTECTED] Information Technology Services (701) 231-1076 (Voice) Room 242-J6, IACC Building(701) 231-8541 (Fax) North Dakota State University, Fargo, ND 58105-5164 __ RPM Package Managerhttp://rpm5.org Developer Communication Listrpm-devel@rpm5.org __ RPM Package Managerhttp://rpm5.org Developer Communication Listrpm-devel@rpm5.org
Re: [CVS] RPM: rpm/ CHANGES configure.ac rpm/rpmdb/ Makefile.am
On Wed, Jun 27, 2007, Jeff Johnson wrote: On Jun 27, 2007, at 6:44 PM, Ralf S. Engelschall wrote: Simplify internal Berkeley-DB handling in rpmdb/ even further and as a wished side-effect allow (at least in an clearly unsupported way to make Jeff not panic ;-) the use of --with-db=external. It's not a question of panic, but rather support and feature regression. [...] I *really* don't want to diagnose these problems again and again and again because lusers want choice until it hurts. Fair enough! It certainly is a difficult balance between avoiding the trouble with lusers and still allowing packagers to build RPM with an external Berkeley-DB _without_ having to patch the RPM sources. But we can even go one step further: on --version or --help GNU tools often output Report bugs to [EMAIL PROTECTED].. We could use this with rpm-devel@rpm5.org and in case someone wants to use an option like --with-db=external he _FIRST_ has to specifiy something like --with-bugreport=email-address in his packaging or an Autoconf error will occur. This way the packager also is _FORCED_ to take action (and this way has to know what he is doing) _AND_ the end user is also informed explicitly who to contact for support. For instance in OpenPKG I would like to use --with-bugreport=[EMAIL PROTECTED] to make sure the OpenPKG users do not directly contact rpm5.org. Now implemented: http://rpm5.org/cvs/chngview?cn=7567 I hope this is a reasonable compromise, isn't it? Ralf S. Engelschall [EMAIL PROTECTED] www.engelschall.com __ RPM Package Managerhttp://rpm5.org Developer Communication Listrpm-devel@rpm5.org
Re: [CVS] RPM: rpm/ CHANGES configure.ac rpm/rpmdb/ Makefile.am
On Jun 28, 2007, at 2:06 AM, Ralf S. Engelschall wrote: Fair enough! It certainly is a difficult balance between avoiding the trouble with lusers and still allowing packagers to build RPM with an external Berkeley-DB _without_ having to patch the RPM sources. The only patch is the robust mutexes. There's likely a vector in Berkeley DB that can be overridden, and the POSIX shared mutex locking can be carried privately within rpm if external db is absolutely desired. Associating a version of locking with a version of Berkeley DB at run time to maintain the fiction of external hardly seems worth the effort for what is a rather trivial patch. SO far, I know of no effort by anyone other than myself to even look at robust mutexes. But we can even go one step further: on --version or --help GNU tools often output Report bugs to [EMAIL PROTECTED].. We could use this with rpm-devel@rpm5.org and in case someone wants to use an option like --with-db=external he _FIRST_ has to specifiy something like --with-bugreport=email-address in his packaging or an Autoconf error will occur. This way the packager also is _FORCED_ to take action (and this way has to know what he is doing) _AND_ the end user is also informed explicitly who to contact for support. For instance in OpenPKG I would like to use --with-bugreport=[EMAIL PROTECTED] to make sure the OpenPKG users do not directly contact rpm5.org. Now implemented: http://rpm5.org/cvs/chngview?cn=7567 I hope this is a reasonable compromise, isn't it? You are more than reasonable. The amount of support pain inflicted upon me by Berkeley DB has made me twitchy on the subject however. I'll try to control my tics for a bit, until we can see what types of support issues arise. There's always engineering issues available if rpm can actually be distributed and upgraded, a far more important goal. __ RPM Package Managerhttp://rpm5.org Developer Communication Listrpm-devel@rpm5.org
Re: [CVS] RPM: rpm/ CHANGES configure.ac rpm/rpmdb/ Makefile.am
On Thursday 28 of June 2007, Jeff Johnson wrote: On Jun 28, 2007, at 2:06 AM, Ralf S. Engelschall wrote: Fair enough! It certainly is a difficult balance between avoiding the trouble with lusers and still allowing packagers to build RPM with an external Berkeley-DB _without_ having to patch the RPM sources. The only patch is the robust mutexes. There's likely a vector in Berkeley DB that can be overridden, and the POSIX shared mutex locking can be carried privately within rpm if external db is absolutely desired. Where is that patch? We at PLD don't like internal libs, we prefer to patch external ones. -- Arkadiusz MiśkiewiczPLD/Linux Team arekm / maven.plhttp://ftp.pld-linux.org/ __ RPM Package Managerhttp://rpm5.org Developer Communication Listrpm-devel@rpm5.org
Re: [CVS] RPM: rpm/ CHANGES configure.ac rpm/rpmdb/ Makefile.am
On Thu, Jun 28, 2007, Arkadiusz Miskiewicz wrote: On Thursday 28 of June 2007, Jeff Johnson wrote: On Jun 28, 2007, at 2:06 AM, Ralf S. Engelschall wrote: Fair enough! It certainly is a difficult balance between avoiding the trouble with lusers and still allowing packagers to build RPM with an external Berkeley-DB _without_ having to patch the RPM sources. The only patch is the robust mutexes. There's likely a vector in Berkeley DB that can be overridden, and the POSIX shared mutex locking can be carried privately within rpm if external db is absolutely desired. Where is that patch? We at PLD don't like internal libs, we prefer to patch external ones. CVSTrac is your friend here: http://rpm5.org/cvs/chngview?cn=6633 But keep in mind that this is _NOT_ portable as it uses the Non-Portable (NP) part of the POSIX Pthread API. So, this is unfinished as the necessary Autoconf glue is missing or at least some #if defined(__linux__)... Ralf S. Engelschall [EMAIL PROTECTED] www.engelschall.com __ RPM Package Managerhttp://rpm5.org Developer Communication Listrpm-devel@rpm5.org
Re: [CVS] RPM: rpm/ CHANGES configure.ac macros.in rpm/rpmdb/ db_emu.h dbc...
On Jun 28, 2007, at 11:52 AM, Ralf S. Engelschall wrote: RPM Package Manager, CVS Repository http://rpm5.org/cvs/ __ __ Server: rpm5.org Name: Ralf S. Engelschall Root: /v/rpm/cvs Email: [EMAIL PROTECTED] Module: rpm Date: 28-Jun-2007 17:52:05 Branch: HEAD Handle: 2007062816520500 Modified files: rpm CHANGES configure.ac macros.in rpm/rpmdb db_emu.h dbconfig.c rpmdb.h Log: .open Peril Sensitive Sunglasses .load Armor Maximum .strike Argumentation-Flag half-mast Based on all the recent cleanup and streamline efforts on the RPM 5 build environment, it is now possible to surgically teach RPM 5 one remaining (officially unsupported but) technically very interesting feature: Out-of-the-box building RPM without Berkeley-DB at all. Another data point in the trajectory computation. 73 de Jeff __ RPM Package Managerhttp://rpm5.org Developer Communication Listrpm-devel@rpm5.org
Re: [CVS] RPM: rpm/ CHANGES configure.ac rpm/rpmdb/ Makefile.am
On Jun 28, 2007, at 12:06 PM, Arkadiusz Miskiewicz wrote: On Thursday 28 of June 2007, Jeff Johnson wrote: On Jun 28, 2007, at 2:06 AM, Ralf S. Engelschall wrote: Fair enough! It certainly is a difficult balance between avoiding the trouble with lusers and still allowing packagers to build RPM with an external Berkeley-DB _without_ having to patch the RPM sources. The only patch is the robust mutexes. There's likely a vector in Berkeley DB that can be overridden, and the POSIX shared mutex locking can be carried privately within rpm if external db is absolutely desired. Where is that patch? We at PLD don't like internal libs, we prefer to patch external ones. The patch is likely harmless, but is not generally acceptable. One cannot just inherit a previously locked mutex/futex without cleaning up side- effects of the lock. For rpmdb accesses, the side-effects are sufficiently predictable, and with --rebuilddb in place, the risk is acceptable for the gain of not having to reboot a machine to clear a stale futex. Generally those conditiions do not apply. There is a db-4_5_20 tag in cvs, the patch can be generated from a checkout,. The patch was also posted on [EMAIL PROTECTED] like last November. A better patch, overloading runtime vectors from within rpm, is likely better than just whacking into libdb. But a global enabler in system db is also easily achieved. 73 de Jeff __ RPM Package Managerhttp://rpm5.org Developer Communication Listrpm-devel@rpm5.org
Re: [CVS] RPM: rpm/ CHANGES configure.ac rpm/rpmdb/ Makefile.am
On Thursday 28 of June 2007, Jeff Johnson wrote: # rpm -qa rpmdb: unable to initialize mutex: Operation not supported rpmdb: PANIC: Operation not supported You have misbuilt rpm. There is autoconfiggery necessary and the build system must be setup +NPTL. The setup always has been nptl ready (glibc 2.6; = 2.6.16 kernels) +1 for support problems with external Berkeley DB. Looks like these new things from robustness patch require kernel = 2.6.17 (because the problem is not visible on such kernels with exactly the same userspace environment). I've dropped robustness patch from our system db. PLD lived for a very (very) long time with external db and without the patch btw :) 73 de Jeff -- Arkadiusz MiśkiewiczPLD/Linux Team arekm / maven.plhttp://ftp.pld-linux.org/ __ RPM Package Managerhttp://rpm5.org Developer Communication Listrpm-devel@rpm5.org
Re: [CVS] RPM: rpm/ CHANGES configure.ac rpm/rpmdb/ Makefile.am
On Thursday 28 of June 2007, Jeff Johnson wrote: On Jun 28, 2007, at 3:13 PM, Arkadiusz Miskiewicz wrote: On Thursday 28 of June 2007, Jeff Johnson wrote: The setup always has been nptl ready (glibc 2.6; = 2.6.16 kernels) NPTL ready is not sufficient, there are explicit autoconf tests in Berkeley DB that will misbuild if the build system is not set up correctly. checking for mutexes... POSIX/pthreads/library is the good one afaik. Specifically, if nptl-devel is not installed, you will fail with exactly the above system. nptl-devel - looks like some very ancient Linux distribution. Starting from glibc 2.4 there is no other option than NPTL (linuxthreads not even supported). Robustness adds the missing property, but is not in 2.6.17 AFAIK. 2.6.16 actually. 2.6.17 works fine. So my problem is kernel related problem only. 73 de Jeff -- Arkadiusz MiśkiewiczPLD/Linux Team arekm / maven.plhttp://ftp.pld-linux.org/ __ RPM Package Managerhttp://rpm5.org Developer Communication Listrpm-devel@rpm5.org
Re: [CVS] RPM: rpm/ CHANGES configure.ac rpm/rpmdb/ Makefile.am
On Jun 28, 2007, at 3:45 PM, Arkadiusz Miskiewicz wrote: On Thursday 28 of June 2007, Jeff Johnson wrote: On Jun 28, 2007, at 3:13 PM, Arkadiusz Miskiewicz wrote: On Thursday 28 of June 2007, Jeff Johnson wrote: The setup always has been nptl ready (glibc 2.6; = 2.6.16 kernels) NPTL ready is not sufficient, there are explicit autoconf tests in Berkeley DB that will misbuild if the build system is not set up correctly. checking for mutexes... POSIX/pthreads/library is the good one afaik. Specifically, if nptl-devel is not installed, you will fail with exactly the above system. nptl-devel - looks like some very ancient Linux distribution. Starting from glibc 2.4 there is no other option than NPTL (linuxthreads not even supported). Yep, RHEL4 based CentOS4.5. Robustness adds the missing property, but is not in 2.6.17 AFAIK. 2.6.16 actually. 2.6.17 works fine. So my problem is kernel related problem only. Could you supply details please? I don't understand why a EOWNERDEAD driven patch should fail in the manner described. EOWNERDEAD should not be returned by a kernel that does not support robust mutexes, and so the code paths in the patch should never have been traversed. If there is a path that is traversed by a kernel that does not support robust mutexes, than that needs to be fixed for the (duh!) obvious reasons. 73 de Jeff __ RPM Package Managerhttp://rpm5.org Developer Communication Listrpm-devel@rpm5.org
Re: [CVS] RPM: rpm/ CHANGES configure.ac rpm/rpmdb/ Makefile.am
On Jun 27, 2007, at 6:44 PM, Ralf S. Engelschall wrote: RPM Package Manager, CVS Repository http://rpm5.org/cvs/ __ __ Server: rpm5.org Name: Ralf S. Engelschall Root: /v/rpm/cvs Email: [EMAIL PROTECTED] Module: rpm Date: 28-Jun-2007 00:44:56 Branch: HEAD Handle: 2007062723445500 Modified files: rpm CHANGES configure.ac rpm/rpmdb Makefile.am Log: Simplify internal Berkeley-DB handling in rpmdb/ even further and as a wished side-effect allow (at least in an clearly unsupported way to make Jeff not panic ;-) the use of --with-db=external. It's not a question of panic, but rather support and feature regression. Let's say someone wants to us db-4.1.25. rpm compiles fine. the default db configuration breaks because not tuned to that version, i.e. no stale lock removal. Then there is the select poll in db-4.1.25, which is an order of magnitude slower with a 5000 item test db than either the previous or the next verrsion of Berkeley DB. I *really* don't want to diagnose these problems again and again and again because lusers want choice until it hurts. 73 de Jeff __ RPM Package Managerhttp://rpm5.org Developer Communication Listrpm-devel@rpm5.org
Re: [CVS] RPM: rpm/ CHANGES configure.ac
On Monday 25 of June 2007, Andy Green wrote: Arkadiusz Miskiewicz wrote: Log: allow one to control/override the /usr/lib64 use via Autoconf option --enable-build-lib64 Usually this is done by ./configure --libdir=/usr/lib64. Possibly I misunderstand, but is that true? I believe --libdir just sets where make install is going to place built libraries, Correct. --enable-build-lib64 sets MARK64=64 which is used somewhere so looks like it's needed and --libdir=/usr/lib64 will not help here too much. Unless doing detection in such way: case $libdir in *64*) MARK=64 it doesn't build against libs in the root filesystem /usr/lib64, which I understood Ralf's comment to mean (like LDFLAGS=-L/usr/lib64 would). -- Arkadiusz MiśkiewiczPLD/Linux Team arekm / maven.plhttp://ftp.pld-linux.org/ __ RPM Package Managerhttp://rpm5.org Developer Communication Listrpm-devel@rpm5.org
Re: [CVS] RPM: rpm/ CHANGES configure.ac
Arkadiusz Miskiewicz wrote: Log: allow one to control/override the /usr/lib64 use via Autoconf option --enable-build-lib64 Usually this is done by ./configure --libdir=/usr/lib64. Possibly I misunderstand, but is that true? I believe --libdir just sets where make install is going to place built libraries, it doesn't build against libs in the root filesystem /usr/lib64, which I understood Ralf's comment to mean (like LDFLAGS=-L/usr/lib64 would). -Andy __ RPM Package Managerhttp://rpm5.org Developer Communication Listrpm-devel@rpm5.org
Re: [CVS] RPM: rpm/ CHANGES configure.ac
On Mon, Jun 25, 2007, Arkadiusz Miskiewicz wrote: On Monday 25 of June 2007, Andy Green wrote: Arkadiusz Miskiewicz wrote: Log: allow one to control/override the /usr/lib64 use via Autoconf option --enable-build-lib64 Usually this is done by ./configure --libdir=/usr/lib64. Possibly I misunderstand, but is that true? I believe --libdir just sets where make install is going to place built libraries, Correct. --enable-build-lib64 sets MARK64=64 which is used somewhere so looks like it's needed and --libdir=/usr/lib64 will not help here too much. Set's the reason why I haven't nuked it at all. MARK64 is used for both extending LDFLAGS and for setting libdir. Nevertheless this is a cruel hack and hence I've added the --enable possibility to optionally at least be able to get rid of it at all. Ralf S. Engelschall [EMAIL PROTECTED] www.engelschall.com __ RPM Package Managerhttp://rpm5.org Developer Communication Listrpm-devel@rpm5.org
Re: [CVS] RPM: rpm/ CHANGES configure.ac
In my environments, I setup the compiler and CFLAGS before calling configure w/ the right information to build 32, or 64 bit binaries. Having configure try to guess and pass in additional values is a royal pain. Passing in --libdir=/usr/lib64 (or equiv) is really the right answer. There shouldn't be any MARK64 or similar checks in configure or other components. If they care about type sizes, then they should use the size types, i.e. uint32 instead of long, or they should check sizes using the autoconf variables and adjust things based on that. (One rare example. There is a mips64 target that comes back 32-bit in all of the tests. If the system checks for 64 in the arch name it WILL do the wrong thing. It needs to look at type sizes to determine what to do. Most software gets this right.) --Mark Ralf S. Engelschall wrote: On Mon, Jun 25, 2007, Arkadiusz Miskiewicz wrote: On Monday 25 of June 2007, Andy Green wrote: Arkadiusz Miskiewicz wrote: Log: allow one to control/override the /usr/lib64 use via Autoconf option --enable-build-lib64 Usually this is done by ./configure --libdir=/usr/lib64. Possibly I misunderstand, but is that true? I believe --libdir just sets where make install is going to place built libraries, Correct. --enable-build-lib64 sets MARK64=64 which is used somewhere so looks like it's needed and --libdir=/usr/lib64 will not help here too much. Set's the reason why I haven't nuked it at all. MARK64 is used for both extending LDFLAGS and for setting libdir. Nevertheless this is a cruel hack and hence I've added the --enable possibility to optionally at least be able to get rid of it at all. Ralf S. Engelschall [EMAIL PROTECTED] www.engelschall.com __ RPM Package Managerhttp://rpm5.org Developer Communication Listrpm-devel@rpm5.org __ RPM Package Managerhttp://rpm5.org Developer Communication Listrpm-devel@rpm5.org
Re: [CVS] RPM: rpm/ CHANGES configure.ac
On Mon, Jun 25, 2007, Mark Hatle wrote: In my environments, I setup the compiler and CFLAGS before calling configure w/ the right information to build 32, or 64 bit binaries. Having configure try to guess and pass in additional values is a royal pain. Passing in --libdir=/usr/lib64 (or equiv) is really the right answer. There shouldn't be any MARK64 or similar checks in configure or other components. If they care about type sizes, then they should use the size types, i.e. uint32 instead of long, or they should check sizes using the autoconf variables and adjust things based on that. (One rare example. There is a mips64 target that comes back 32-bit in all of the tests. If the system checks for 64 in the arch name it WILL do the wrong thing. It needs to look at type sizes to determine what to do. Most software gets this right.) I fully second your statements. As I said, from my POV the whole MARK64 is an ugly hack and really should be removed at all. But as it is mainly a Linux thing and I (as a cross-platform Unix hacker) do not care very much about the single Linux platform myself, it would have been rude if _I_ just removed it. So, I just worked around its problems by at least allowing us to disable it manually. But if we can get rid of it at all -- even better! So, anybody who is able to fully understand all Linux issues related to this MARK64 stuff, please feel free to jump in and kick it out... Ralf S. Engelschall [EMAIL PROTECTED] www.engelschall.com __ RPM Package Managerhttp://rpm5.org Developer Communication Listrpm-devel@rpm5.org
