While test-driving 5.1.8 I see FIXME outputs:
| [...]
| Processing files: ncurses-5.7.20090411-20090412
| Wrote:
/usr/opkg/RPM/PKG/ncurses-5.7.20090411-20090412.amd64-debian5.0-opkg.rpm
| Executing(%clean): env -i /usr/opkg/lib/openpkg/bash --norc --noprofile
--posix -e
On Apr 13, 2009, at 9:46 AM, Jeff Johnson wrote:
Lemme see if I can reproduce the issue. Fixing is usually minutes
using --rpmfidebug and --hdrdebug to show the link/unlink locations.
Heh, well I can't build rpm-5.1.8 any more because of PCRE - LUA,
so much for fixing.
I'd like to hear the
On Apr 13, 2009, at 10:06 AM, Ralf S. Engelschall wrote:
On Mon, Apr 13, 2009, Jeff Johnson wrote:
On Apr 13, 2009, at 9:38 AM, Ralf S. Engelschall wrote:
| == FIXME: pool fi: made 4 count 3
| == FIXME: pool h: made 5 count 4
These are just memory leaks seen while tearing
down memory
On Apr 13, 2009, at 10:30 AM, Ralf S. Engelschall wrote:
I'm still investigating on this. What is your _CURRENT_ error you get
with the latest code base status quo, Jeff?
I get the same message you reported, most of the lua symbols missing:
(cd .libs rm -f librpmio.la ln -s
On Apr 13, 2009, at 10:36 AM, Jeff Johnson wrote:
On Apr 13, 2009, at 10:30 AM, Ralf S. Engelschall wrote:
I'm still investigating on this. What is your _CURRENT_ error you get
with the latest code base status quo, Jeff?
I get the same message you reported, most of the lua symbols
On Mon, Apr 13, 2009, Jeff Johnson wrote:
[...]
But here's the failure mode after make clean, duplicated
symbols because libpcreposix.a becuase libpcre.a has been
bundled in because of s/lib_/noinst_/ in pcre/Makefile.am.
Ah, ok, better. This _IS_ the problem I'm not investigating.
The Lua
On Apr 13, 2009, at 11:03 AM, Ralf S. Engelschall wrote:
H.. this is interesting. It is not really exactly my original
problem. Instead your rpmmisc is linked in just fine, but although you
are building with a local Lua (I guess) you are not getting any Lua
symbols. Also I see that in
On Apr 13, 2009, at 11:12 AM, Ralf S. Engelschall wrote:
On Mon, Apr 13, 2009, Jeff Johnson wrote:
[...]
But here's the failure mode after make clean, duplicated
symbols because libpcreposix.a becuase libpcre.a has been
bundled in because of s/lib_/noinst_/ in pcre/Makefile.am.
Ah, ok,
On Mon, Apr 13, 2009, Jeff Johnson wrote:
On Apr 13, 2009, at 11:12 AM, Ralf S. Engelschall wrote:
On Mon, Apr 13, 2009, Jeff Johnson wrote:
[...]
But here's the failure mode after make clean, duplicated
symbols because libpcreposix.a becuase libpcre.a has been
bundled in because of
On Mon, Apr 13, 2009, Jeff Johnson wrote:
[...]
As long as lua is being extended internally, then linkage issues are
going to continue to manifest themselves.
I looked at extending lua already through the usual means and
it looked like a disastrous end-point. The lua/local usual
means of
On Apr 13, 2009, at 11:42 AM, Ralf S. Engelschall wrote:
So shall we try for extending LUA through rpm specific
conventional load paths instead of wrestling with the octopus?
Hmmm... yes, it certainly would be better if Lua extensions would be
loaded via dlopen(3) and friends instead of
On Mon, Apr 13, 2009, Ralf S. Engelschall wrote:
On Mon, Apr 13, 2009, Jeff Johnson wrote:
On Apr 13, 2009, at 11:12 AM, Ralf S. Engelschall wrote:
On Mon, Apr 13, 2009, Jeff Johnson wrote:
[...]
But here's the failure mode after make clean, duplicated
symbols because
On Mon, Apr 13, 2009, Jeff Johnson wrote:
Ok, I'm finished from my side. All issues I've seen are at least
resolved for _me_. Remains just your issues, Jeff. Are those now also
resolved with my latest changes for RPM 5.1? If no, I've to
investigate
once again. If yes, I'll proceed with some
On Apr 13, 2009, at 12:45 PM, Ralf S. Engelschall wrote:
Fixing now ...
Thanks. Does RPM 5.1 now finally build for you again, Jeff?
BTW, there's a flaw (on Fedora) if UUID is eanbled.
I've been hand editing lua/Makefile and rpmio/Makefile
to comment out -I/usr/include/uuid that is
On Mon, Apr 13, 2009, Jeff Johnson wrote:
[...]
BTW, there's a flaw (on Fedora) if UUID is eanbled.
I've been hand editing lua/Makefile and rpmio/Makefile
to comment out -I/usr/include/uuid that is being added
by AutoFu for quite some months.
This is totally a Fedora packaging problem,
On Mon, Apr 13, 2009, Jeff Johnson wrote:
On Apr 13, 2009, at 12:55 PM, Jeff Johnson wrote:
But if you could figger the AutoFu to fox the issue (by
not including -I/usr/include/uuid on Fedora) I'd be grateful.
Actually, changing devtool.conf from
--with-uuid=external \
to
On Apr 13, 2009, at 1:08 PM, Ralf S. Engelschall wrote:
On Mon, Apr 13, 2009, Jeff Johnson wrote:
On Apr 13, 2009, at 12:55 PM, Jeff Johnson wrote:
But if you could figger the AutoFu to fox the issue (by
not including -I/usr/include/uuid on Fedora) I'd be grateful.
Actually, changing
On Mon, Apr 13, 2009, Jeff Johnson wrote:
On Apr 13, 2009, at 1:08 PM, Ralf S. Engelschall wrote:
On Mon, Apr 13, 2009, Jeff Johnson wrote:
On Apr 13, 2009, at 12:55 PM, Jeff Johnson wrote:
But if you could figger the AutoFu to fox the issue (by
not including -I/usr/include/uuid on
On Mon, Apr 13, 2009, Jeff Johnson wrote:
[...]
$ rpm -qf /usr/include/uuid.h /usr/include/uuid /usr/include/uuid/uuid.h
uuid-devel-1.6.1-3.fc9.i386
e2fsprogs-devel-1.41.3-2.fc10.i386
e2fsprogs-devel-1.41.3-2.fc10.i386
Ah, ok: understood. As I said, Fedora has two UUID implementations:
the
19 matches
Mail list logo
