On Thursday 21 of June 2007, Ralf S. Engelschall wrote:
On Wed, Jun 20, 2007, Arkadiusz Miskiewicz wrote:
On Wednesday 20 of June 2007, Arkadiusz Miskiewicz wrote:
Right now from config.log:
configure:27985: error: unable to find available BeeCrypt library
but why it told so, you
On Jun 21, 2007, at 4:59 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
On Thursday 21 of June 2007, Jeff Johnson wrote:
On Jun 21, 2007, at 4:59 AM, Ralf S. Engelschall wrote:
RPM Package Manager, CVS Repository
http://rpm5.org/cvs/
__
__
Server: rpm5.org
On Thu, Jun 21, 2007, Jeff Johnson wrote:
There's a much deeper issue here.
quicksort has known worst case performance, and rpm
usage is often near that worst case behavior point.
You mean if the set is already pre-sorted or the pivot element is
choosen badly? Sure, then quicksort's optimal
On Jun 21, 2007, at 9:08 AM, Ralf S. Engelschall wrote:
Although %setup and %patch look like regular RPM macros on the first
spot they are not real macros, of course. Instead they are parsed and
treated very special by RPM internally.
Unfortunately, this internal handling didn't allow for any
On Jun 21, 2007, at 9:29 AM, Ralf S. Engelschall wrote:
On Thu, Jun 21, 2007, Jeff Johnson wrote:
Are there hi-resolution timers available on *BSD w/o a gettimeofday
system call? Just curious. rdtsc has its own problems, but does make
examining strace more pleasant, gettimeofday gets really
On Jun 21, 2007, at 9:27 AM, Ralf S. Engelschall wrote:
On Thu, Jun 21, 2007, Jeff Johnson wrote:
As I watch the vendor defines proliferate, I wonder whether
#if defined(HAVE_DIRENT_D_OFF)
might not be a better approach.
Yes, in general we always have to prefer feature tests instead of
Le jeudi 21 juin 2007, Jeff Johnson a écrit :
On Jun 21, 2007, at 9:08 AM, Ralf S. Engelschall wrote:
Objections?
No objection. Both %setup and %patch (what I call implemented-in-C
macros)
have been known deficient since 1998. I don't believe any reasonable
change will
help or harm.
This thread makes me kinda sad
https://www.redhat.com/archives/fedora-devel-list/2007-June/
msg02196.html
The gist of the thread is that some *really* smart hackers are no
longer capable
of changing what is ultimately a trivial call in rpmlib to
strcmp(i586, i686)
And no one seems
On Jun 21, 2007, at 12:12 PM, Ralf S. Engelschall wrote:
This certainly is confusing at the first spot, but OTOH better to
keep it this way than to automatically expand to an empty string. The
%{?bar}%{?!bar:bar} construct is handy enough and even the
expansion of
%foo to %foo is used in
On Jun 21, 2007, at 12:27 PM, Jeff Johnson wrote:
On Jun 21, 2007, at 12:12 PM, Ralf S. Engelschall wrote:
This certainly is confusing at the first spot, but OTOH better to
keep it this way than to automatically expand to an empty string. The
%{?bar}%{?!bar:bar} construct is handy enough
On Jun 21, 2007, at 12:35 PM, Jeff Johnson wrote:
That way all path macros can be defined trivially as
%__mv %{?=_mv}
Another nice touch. All undefined %__foo macros could be default
initialized as
%{?=_foo}
by rule, and then there is no need for macros.path baggage
This brings up something we've discussed here at Wind River. Would it
be possible to make %setup and/or %patch into macros (perhaps using
lua?) (I'm thinking for rpm5 - HEAD, not 4_5.)
The reason we're interested is that we have mechanisms that track
patches being applied (think quilt), and
On Jun 21, 2007, at 12:42 PM, Mark Hatle wrote:
This brings up something we've discussed here at Wind River. Would it
be possible to make %setup and/or %patch into macros (perhaps using
lua?) (I'm thinking for rpm5 - HEAD, not 4_5.)
Why ask for a buttload of legacy pain? Just use names
On Thu, Jun 21, 2007, Jeff Johnson wrote:
On Jun 21, 2007, at 12:35 PM, Jeff Johnson wrote:
That way all path macros can be defined trivially as
%__mv %{?=_mv}
Another nice touch. All undefined %__foo macros could be default
initialized as
%{?=_foo}
by rule, and then there
On Jun 21, 2007, at 1:32 PM, Ralf S. Engelschall wrote:
So as a short-hand I personally would expect something like
%{?__bar:-bar}
Noted. I 'spose I can figger a 2 character token lexer in the year
2007 ;-)
(similar to the Bourne-Shell construct) or if this breaks the usual
syntax
On Jun 21, 2007, at 1:33 PM, Ralf S. Engelschall wrote:
On Thu, Jun 21, 2007, Jeff Johnson wrote:
On Jun 21, 2007, at 12:35 PM, Jeff Johnson wrote:
That way all path macros can be defined trivially as
%__mv %{?=_mv}
Another nice touch. All undefined %__foo macros could be
On Thu, Jun 21, 2007, Jeff Johnson wrote:
On Jun 21, 2007, at 1:33 PM, Ralf S. Engelschall wrote:
[...]
We should be carefully and not introduce too much magic here
or nobody else will ever understand it ;-)
I bow to the autoconf master's fu. ;-)
[...]
Ops, accepted! I retract my wording
While there's nothing wrong withe your patch, there's simply
no reason not to just pass *all* patch options directly to
patch. That dumps a bunch of silly code from rpmbuild.
The reason for the parsePrep.c jiggery pokery is transparently remapping
ancient patch's CLI option change that was
On Jun 21, 2007, at 2:11 PM, Ralf S. Engelschall wrote:
On Thu, Jun 21, 2007, Jeff Johnson wrote:
On Jun 21, 2007, at 1:33 PM, Ralf S. Engelschall wrote:
[...]
We should be carefully and not introduce too much magic here
or nobody else will ever understand it ;-)
I bow to the autoconf
On Thu, Jun 21, 2007, Jeff Johnson wrote:
While there's nothing wrong withe your patch, there's simply
no reason not to just pass *all* patch options directly to
patch. That dumps a bunch of silly code from rpmbuild.
The reason for the parsePrep.c jiggery pokery is transparently remapping
On Jun 21, 2007, at 4:20 AM, Ralf S. Engelschall wrote:
Ok, please retry with the latest incarnation of RPM_CHECK_LIB in HEAD.
You should be now able to build with a simple --with-beecrypt[=yes] in
order to build against a BeeCrypt in default system locations. I've
still not tried it myself
22 matches
Mail list logo
