p the
server side,
I'd love the excuse to hack a bit on rpmio.
Ralf: btw, I still owe you modern proxy support in rpmio. All I need is
a proxy to bounce against for a while. And I'm a lazy schmuck ;-)
73 de Jeff
---------
attempting
per-platform packaging.
73 de Jeff
-------------
From: "Ralf S. Engelschall" <[EMAIL PROTECTED]>
Date: Sun, 27 May 2007 11:22:03 +0200
On Sat, May 26, 2007, Jeff Johnson wrote:
> (from a #rpm conversation with rsc)
>
> One very easy way to prepar
On Mon, May 28, 2007, Ralf S. Engelschall wrote:
> [...]
> OK. Basically what I see is a XML format that can be used for parsing.
>
> That same XML format could be used as import to create a database if
> you wish.
>
> Name a database (presumably sqlite), define a schema, a
tree. But in a sub-directory it would have to
be -I../beecrypt, etc. The solution is to use Autoconf's @top_srcdir@
variable, i.e. place into Makefile.in [EMAIL PROTECTED]@/beecrypt
Ralf S. Engelschall
[EMAIL PROTECTED]
On Mon, May 28, 2007, Ralf S. Engelschall wrote:
> On Mon, May 28, 2007, Olivier Thauvin wrote:
>
> > Le lundi 28 mai 2007, Jeff Johnson a écrit :
> > > > Do you agree with that ?
> > >
> > > In general, I believe that adjusting -I paths is superior to
rg CVS seems to be from 2005.
Or was the updating already at this time?
Ralf S. Engelschall
[EMAIL PROTECTED]
www.engelscha
UTOMAKE([foreign])
> >
> > +LDFLAGS=""
> > +
> > dnl Check for programs.
> > AC_PROG_CC
> > AC_PROG_LIBTOOL
>
> Okay, that's scary. Those lines should read:
>
> +LDFLAGS="$(echo $LDFLAGS | sed 's/-pie//g')&q
y 6 months or so for years and years.
IMHO as long as POPT is available as RPMs and Tarballs in its own
http://rpm5.org/files/popt/ this should be really fully sufficient.
Ralf S. Engelschall
ust for POPT currently ;-) I really would
like to see a _LATEST_ 1.10.x tarball and SRPMS available under
http://rpm5.org/files/popt/. Can you upload this, Jeff?
Ralf S. Engelschall
ally never a good idea with an underlying CVS
repository. Better to think about the final location already at the
first attempt.
Just a few cents of a "burnt CVS child"... ;-)
Ralf S. Engelschall
[EMAIL
7;ed by a recovering cvs addict.
;-)
PS: If we have to touch the CVS repository on the server side,
be either extremely careful yourself or better tell me what
rearrangements are wished and I will try to take care of the job.
d
here a public discussion is usually already dead before it started...
;-) That's why we decided to first continue with the original (and just
partly cleaned up) original CVS of RPM and once the dust settled after
RPM 4.5 one can perhaps think about alternatives again...
int: pthread__np(3) functions are non-portable and not
standard Pthread API additions. If you want to use them and not break
on lots of platforms you at least have to wrap their usage with some
Autoconf-based #ifdef/#endif glue. Except their use is within a larger
code block which is alrea
correct thing
here (from a bare ISO C API point of view) is to really use a "void *".
Go for it, it is the right solution in ISO C.
Ralf S. Engelschall
[EMAIL PROTECTED]
sk because early next week I plan to
start playing (for OpenPKG) with the pre-RPM-5.0 code we now have on
the trunk. So I'm wondering what state it currently is in and what is
planned according to the rpm-4.5 changes.
D is the likely
> entry point afaict, the reverse of what would expect with devel on HEAD.
> [...]
Yes, vendor specifics which were now introduced into 4.5 certainly
should be not merged back to HEAD for 5.0, of course.
on 5.0 and if the trunk is broken then better
to be forced to fix it than moving around it via another branch.
Ralf S. Engelschall
[EMAIL PROTECTED]
BZh) dd if="$pkg" ibs=$o skip=1 2>/dev/null | bunzip2 ;;
"$gz"*) dd if="$pkg" ibs=$o skip=1 2>/dev/null | gunzip ;;
-# no magic in old lzma format, if unknown we assume that's lzma for now
-*)dd if="$pkg" ibs=$o skip=1
hatever branch from HEAD, hack wild there and after the 4-6 weeks you
merge the complete changes of the branch back to HEAD. This certainly
makes sense. Thanks for clarification, Jeff.
Ralf S. Engelschall
other future
compression) and then fail to output the payload at all or better
_always_ output the payload even if in the case of (the unrecognizeable)
LZMA it might be still compressed? I personally would prefer to
always output a payload even if
On Mon, Jun 11, 2007, Jeff Johnson wrote:
> plug the other memory leaks too.
Thanks, Jeff. That's exactly what I hoped you will do ;-)
Ralf S. Engelschall
[EMAIL P
le sh/m4 based Autoconf macro
"RPM_CHECK_LIBRARY" and which is then used in "configure.ac" to
improve the current checks for the external libraries. The above
approach especially tries hard to be maximum backward compatible
to the currently present defaults. But it
On Tue, Jun 12, 2007, Jeff Johnson wrote:
> [...]
>
On this topic just wait a few hours more. We've already coded
the m4 macro and will shortly post it for review.
Ralf S. Engelschall
[EMAI
On Tue, Jun 12, 2007, Ralf S. Engelschall wrote:
> On Tue, Jun 12, 2007, Jeff Johnson wrote:
>
> > [...]
> >
>
> On this topic just wait a few hours more. We've already coded
> the m4 macro and will shortly post it for review.
After 6 additional hours Thomas and
of
local modifications. "popt" for the well known reason. And all three are
checked out to the RPM source tree explicitly from their CVS top-level
module.
More feedback?
Ralf S. Engelschall
[EMAIL PROTECTED]
www.eng
y library linking. Currently
configure.ac contains lots of specific hacks for linking each library
differently and the hacks theirself are too unflexible. Packagers
who want to build against external libraries currently have to hack
configure.ac and this IMHO should be avoided. B
On Tue, Jun 12, 2007, Ralf S. Engelschall wrote:
> [...]
> The prepared "HEAD Source Tree Pruning" procedure now looks like this:
> [...]
Latest revised procedure based on Jeff's latest feedback:
1. Server-Side: move third-party subdirs to top-level by just remo
On Tue, Jun 12, 2007, Ralf S. Engelschall wrote:
> On Tue, Jun 12, 2007, Ralf S. Engelschall wrote:
>
> > [...]
> > The prepared "HEAD Source Tree Pruning" procedure now looks like this:
> > [...]
> [...]
Ok, the server-side cleanup of the RPM CVS repository
On Wed, Jun 13, 2007, Jeff Johnson wrote:
> Omit popt, add lua, to the "essential" checkouts.
I'm just curious: Does this mean you want RPM 5.0 to _always_ build
against an external POPT and that Lua always should be shipped with RPM
5.0, Jeff?
On Wed, Jun 13, 2007, Jeff Johnson wrote:
> On Jun 13, 2007, at 12:00 PM, Ralf S. Engelschall wrote:
>
>> On Wed, Jun 13, 2007, Jeff Johnson wrote:
>>
>>> Omit popt, add lua, to the "essential" checkouts.
>>
>> I'm just curious: Does this
flexibly base _their_ packages on RPM 5.0
and for this the tarball is the central piece of distribution. And a
christmas-tarball (containing dozend of third-party libs) here is not
really what others might expect and like. Your example of TLD is here
just a
e we're on the same page?
Yes, of course. I was just not aware of the fact that the our Lua copy
was not a stock one. I was under the impression it contains _NO_ local
modifications. Thanks for clarification, Jeff. Then it makes sense to
keep Lua connected to RPM and obviously even che
le is globally chronologic and easier to read.
Remains just one question: is it really necessary that _each_ commit
leads to a new record in CHANGES? I personally would expect that CHANGES
_summarizes_ the major changes but each of those changes at least
_might_ correspond to _multiple_ commits (and t
metimes:
#if (HAVE_FOO + HAVE_BAR + 0) > 0
But even this one usually better write as:
#if defined(HAVE_FOO) || defined(HAVE_BAR)
Ralf S. Engelschall
[EMAIL PROTECTED]
o extend the %fire-and-forget target now on
devtool.conf the way you need it.
Ralf S. Engelschall
[EMAIL PROTECTED]
www.engelschall.com
_
did I overlook something in RPM where the db RPC stuff is
really used?
Ralf S. Engelschall
[EMAIL PROTECTED]
www.engelschall.com
___
On Thu, Jun 14, 2007, Jeff Johnson wrote:
> On Jun 14, 2007, at 1:41 PM, Ralf S. Engelschall wrote:
>
>> Do we really need the RPC functionality of Berkele-DB in RPM?
>
> I'd like to keep, if for no other reason, that sunrpc -> rpmdb is
> an alternative (and rel
On Thu, Jun 14, 2007, Ralf S. Engelschall wrote:
> [...]
> BUT WHEN I LOOK AT db/dist/aclocal/rpc.m4 I SEE THAT THE PROBLEM IS
> NOT THE FREEBSD rpcgen! Seems like Berkeley-DB's configure stuff is
> post-adjusting the generated files. Perhaps the problem is already
> there.
ection: allowing us to easy opt-in
with an --enable-rpc in the top-level which is passed to db3/configure
internally.
> [...]
> Truly, sunrpc->rpmdb is likely no more than a private fetish of mine.
> [...]
Ralf S.
On Fri, Jun 15, 2007, Ralf S. Engelschall wrote:
> On Thu, Jun 14, 2007, Jeff Johnson wrote:
>
> > [...]
> >> Ah, good idea. Yes, pre-generating the file would be one option or/and
> >> we can add some Autoconf glue which allows one to disable the RPC stuff
tering, as well as *BSD vs. GNU sed tab/space handling, are the usual
> failure cases to watch out for when messing with db3/configure.
Ok, thanks for the hint. I'll check the sed fiddling against those
issues before comitting.
Ralf S. Engelschall
ng for review and
commit. Once those were resolved we are certainly ready for a 5.0-0.1.
After this I would like to concentrate on the RPM_CHECK_LIB issue for
5.0-0.2...
Ralf S. Engelschall
[EM
not break the portability
of POPT here. BTW, what is currently at the top of rpmio/rpmlog.c
is unfortunately not sufficient. Furtunately, I've already coded a
sufficiently complete enough Autoconf glue once in the past. I'll fix
it.
Ralf S
On Fri, Jun 15, 2007, Jeff Johnson wrote:
> On Jun 15, 2007, at 10:32 AM, Ralf S. Engelschall wrote:
>
>> $ cvs diff -u -r1.3 -r1.4 strtolocale.c
>> --- rpm/rpmio/strtolocale.c15 Jun 2007 09:14:03 - 1.3
>> +++ rpm/rpmio/strtolocale.c15
On Fri, Jun 15, 2007, Jeff Johnson wrote:
> On Jun 15, 2007, at 12:09 PM, Ralf S. Engelschall wrote:
>
>> Ok, thanks for the hint.
>
> You've likely seen
> foo = xmalloc(...)
> ...
> foo = _free(foo)
> habits of mine. Feel free to suggest better. _fr
On Fri, Jun 15, 2007, Michael Jennings wrote:
> On Wednesday, 13 June 2007, at 18:39:43 (+0200),
> Ralf S. Engelschall wrote:
>
> > Perhaps we are also just talking about differnent things: perhaps
> > you just want to checkout the third-party libs for _convenience_
> >
ect troubling
things. IMHO this drawback of potential side-effects is less horrible
than having dozend of _free definitions floating around, isn't it?
Ralf S. Engelschall
[EMAIL PROTECTED]
www.enge
e.ac by leveraging
the RPM_CHECK_LIB macro and at the same time allow us to even more
flexibly build RPM 5 against the various third-party libraries. Will not
commit until I reached a rather complete state and then I will post a
patch for review first.
On Fri, Jun 15, 2007, Michael Jennings wrote:
> On Friday, 15 June 2007, at 19:06:17 (+0200),
> Ralf S. Engelschall wrote:
>
> > CVSROOT/modules' versioning is a global one, but one has to version
> > the checking out of sub-modules differently on each RPM
> > bra
discovered) and some doxygen-based RPM API documentation Jeff
recently generated.
Ralf S. Engelschall
[EMAIL PROTECTED]
On Mon, Jun 18, 2007, Jeff Johnson wrote:
> On Jun 18, 2007, at 3:21 PM, Ralf S. Engelschall wrote:
>
>> For your information: The RPM online documentation under
>> http://rpm5.org/docs.php was now finally extended with Jeff's 2005
>> HTML/PDF version of Maxi
t;libxslt" to convert the material from DocBook/XML
into XHTML and XSL-FO (and then via FOP or PDFTeX into PDF). There is
also a frontend "xmlto" which drives such a toolchain automatically.
Ralf S. En
e configure command line for the _build system_ via
"CHMOD=/obscure/target/path/to/chmod CP=/path/to/somewhere/cp
./configure ...". Those environment variables are honored by
AC_CHECK_PATH and more should be not needed IMHO.
Find attached the patch which achi
On Tue, Jun 19, 2007, Ralf S. Engelschall wrote:
> [...]
> gcc -Wall -fPIC -DPIC -D_GNU_SOURCE -D_REENTRANT -Wall -Wpointer-arith
> -Wstrict-prototypes -Wmissing-prototypes -Wno-char-subscripts -o rpmdeps
> rpmdeps.o -L/d2/u/rse/prj/rpm/src/rpm/../sqlite-3.3.17/.libs
> -L/d2/u/
On Tue, Jun 19, 2007, Jeff Johnson wrote:
> On Jun 19, 2007, at 2:42 AM, Ralf S. Engelschall wrote:
>
>> RPM Package Manager, CVS Repository
>> http://rpm5.org/cvs/
>>
>> ___
ing to the proposed change or do you
better wish to keep it the way it was?
Ralf S. Engelschall
[EMAIL PROTECTED]
www.engelschall.com
__
RPM Pa
On Tue, Jun 19, 2007, Jeff Johnson wrote:
> On Jun 19, 2007, at 12:01 PM, Ralf S. Engelschall wrote:
>>
>> Your feedback is welcome!
>
> You do really nice "stuff". Thank you! I'm quite sure it was hours of work.
Well, just don't ask about the actual
n.org: - (RPM4,newest?)
Seems like we really have to investigate on this confusion.
Ralf S. Engelschall
[EMAIL PROTECTED]
www.engelschall.com
work loose.
Yes, of course. But please take care about those merges yourself.
You know best whether the change also has to be in RPM 5, too.
Ralf S. Engelschall
[EMAIL PROTECTED]
is a structure in between which
already requires the definition. So, I've moved up the "extern C" stuff.
Ralf S. Engelschall
[EMAIL PROTECTED]
ff working on non-Linux...
Many thanks for catching this, Jeff. I really very much like clean and
concise commits. Unrelated things always should be committed separately.
Thanks.
Ralf S. Engelschall
On Tue, Jun 19, 2007, Ralf S. Engelschall wrote:
> [...]
We investigated another workday and now have the changes bug fixed,
polished up and also tested on a number of non-Linux platforms. We are
still testing under Solaris, but once we have a green light also there
the changeset is ready to
On Wed, Jun 20, 2007, Ralf S. Engelschall wrote:
> [...]
> Migrate RPM build environment's support for building against third-party
> libraries from an evolutionary and practically too constrained
> approach to a more flexible approach based on a centr
On Wed, Jun 20, 2007, Jay Soffian wrote:
> On Jun 20, 2007, at 3:06 PM, Ralf S. Engelschall wrote:
>
>> + [external:internal:none], [beecrypt],
>> + [], [ AC_ERROR([mandatory BeeCrypt library not found]) ])
> ...
>> + [external:internal:none], [file:src:src],
>
On Wed, Jun 20, 2007, Ralf S. Engelschall wrote:
> On Wed, Jun 20, 2007, Ralf S. Engelschall wrote:
>
> [...]
One more hint before I got asked: I switched all third-partly libs over
to RPM_CHECK_LIB except for the nasty elfutils stuff. This I've still
excluded as it needs spec
rning.
> configure: error: unable to find available File (magic) library
>
> The same for file package :-)
Sure, same code, same problem.
Ralf S. Engelschall
[EMAIL PROTECTED]
www.engelschall.com
anup after it is run in case it adds a dounle-entry.
Also: do we intentionally ship with the intl/* stuff? In POPT we are not
shipping a local copy of libintl. Do we intentionally want to ship a
local copy in RPM? I personally would prefer to keep it external in RPM,
too.
On Thu, Jun 21, 2007, Arkadiusz Miskiewicz wrote:
> Try different (documented in info file) gettext approach.
Ah, cool. I was not aware about autopoint(1). Nice catch! Thanks.
Ralf S. Engelschall
[EMAIL PROTEC
On Thu, Jun 21, 2007, Arkadiusz Miskiewicz wrote:
> 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:
&
On Thu, Jun 21, 2007, Arkadiusz Miskiewicz wrote:
> On Thursday 21 of June 2007, Ralf S. Engelschall wrote:
> > On Wed, Jun 20, 2007, Arkadiusz Miskiewicz wrote:
> > > po/ and m4/ really shouldn't be here. gettextize adds these.
> > > [...]
> > > -
nst a BeeCrypt in default system locations. I've
still not tried it myself under Linux, but let's see whether it now
works for you.
Ralf S. Engelschall
[EMAIL PROTECTED]
ines);
+ if (! strncmp(cp, "%setup", sizeof("%setup")-1)) {
+ res = doSetupMacro(spec, cp);
+ } else if (! strncmp(cp, "%patch", sizeof("%patch")-1)) {
+ res = doPatchMacro(spec, cp);
} else {
this is confusing as the
INSTALL document should reflect the technical implementation IMHO.
I've tried to clear things up a little bit in INSTALL now.
> [...]
> If noone else cares, then I will cease to care and shut up too.
No, no, it's a good
ct statvfs" we also still not
have any define available and coding an extra Autoconf check for this
single case I wanted to avoid. But for the "d_off" issue I think we
really should code a dedicated Autoconf check. Anybody volunteering?
he hi-res timer under BSD.
Ralf S. Engelschall
[EMAIL PROTECTED]
www.engelschall.com
__
RPM Packag
.
>
> So wiring up mergesort rather than quicksort where appropriate is
> the real fix.
Yes, the code chooses quicksort only under glibc and RPM's own mergesort
on all other platforms. So, this should be just fine.
Ralf S. Engelschall
("-p")-1)) {
/* unfortunately, we must support -pX */
if (! strchr(" \t\n", s[2])) {
@@ -556,14 +588,14 @@
/* All args processed */
if (! opt_P) {
- s = doPatch(spec, 0, opt_p, opt_b, opt_R, opt_E, opt_F);
+ s = doPatch(spec, 0, o
rder
> accomplishment is not reading rpmrc was completed in rpm-4.4.7.
> [...]
Yes, I fully agree: please nuke it completely as soon as possible!
Ralf S. Engelschall
ead of "foo" across the RPM internals a macro like
this and a call like rpmExpandTool("foo")?
#define rpmExpandTool(name) \
rpmExpand("%{?" name "}%{?!" name ":" name "}", NULL)
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 practice by an RPM distribution I
as
> %{?=_foo}
> by rule, and then there is no need for macros.path baggage whatsoever.
We should be carefully and not introduce too much magic here
or nobody else will ever understand it ;-)
Ralf S. Engelschall
On Thu, Jun 21, 2007, 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:
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. ;-)
> [.
x checks imho.
Ah, I see your point now. Well, we really could change this and fully
pass through simply everything to patch(1), yes. I see no reason why
not. Sounds reasonable. Well, Jeff, then just do it, please.
Ralf S. Engelschall
; I have at least 4 opinions of my own. My goal atm is to make %patch
> a configuration, rather than a compile, element for rpmbuild.
Yes, this is reasonable. No need to hard-code %patch into the C code any
longer.
Ralf S. Engelschall
pmlua.lo rpmmalloc.lo rpmpgp.lo rpmrpc.lo rpmsq.lo
| rpmsw.lo strcasecmp.lo strtolocale.lo stubs.lo url.lo ugid.lo
| LzmaDecode.lo -lsqlite3 -lpopt -lmagic -lneon -lbeecrypt -lpthread -lbz2
| -lz -lssl -lcrypto -lm -L/tmp/rpm/lib -ldb -
On Fri, Jun 22, 2007, Jeff Johnson wrote:
> On Jun 22, 2007, at 11:50 AM, Ralf S. Engelschall wrote:
>
>> Log:
>> allow people like Jeff to build with more internal stuff (although I
>> personally think we shouldn't do this ;-)
>>
>
> We agree.
&
t=external:internal but during the "external" search
BeeCrypt was not found as it is in a standard system location.
Unfortunately, the current logic aborts too early in this special case
of "library in 'external'" but the last s
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
_
o
this MARK64 stuff, please feel free to jump in and kick it out...
Ralf S. Engelschall
[EMAIL PROTECTED]
www.engelschall.com
__
RPM Package Mana
stuff should be grouped together (perhaps even in the new
librpmmisc.la which is some sort of a container for remaining and
dynamically selected stuff anyway). I'll look what I can do for us...
Watch out for more commi
ies are _still_ those built against RPM's internal Berkeley-DB. I
just install the ones in db3/ and not the re-linked ones in rpmdb/. But
as librpmdb contained just copies of the objects from db3/ the effective
resulting db_xxx tools are exactly the same.
On Wed, Jun 27, 2007, Ralf S. Engelschall wrote:
> [...]
> 2. Although we finally have a sophisticated way to link against
>the third-party libraries, we still have a related problem: the
>internal copies of third-party libraries are linked differently
>against RPM.
cial 'GEOM is in the tree' speech" he
said: "Road-construction is never a nice thing, at least not until it
is done and over with, but it is a necessary part of the lifecycle."
H... ;-)
Ralf S. Engel
sibility in
Bourne-Shell: to use a "for" loop to iterate over the arguments and then
re-construct the stuff in a quoted way.
Ralf S. Engelschall
[EMAIL PROTECTED]
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
ce RPM: (none)
| Size: 0License: pubkey
| Signature : (none)
| Summary : gpg(Jeff Johnson (ARS N3NPQ) <[EMAIL PROTECTED]>)
| [...]
Yours,
Ralf S. Engelschall
; the other format. (I don't remember the order it looks in.)
> [...]
Yes, according to the code it looks that if __dbapi is set to -1 is sets
it to 5 and decrements to 1 until it finds an implementation. So SQLite
would be preferred here and if not found it would use Berkeley-
ake the _dbi_tags variable depending on the configuration?
> And we need ot be sure that Depends never gets used on sqlite.
Done: http://rpm5.org/cvs/chngview?cn=7575
But I would like to see "temporary" support for SQLite based RPM DB.
Perhaps via the ":memory
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
1 - 100 of 753 matches
Mail list logo
