Ok, I'm still in the process of fixing RPM 5.1 for the release of 5.1.8
and finally I'm now forced to deeper understand this change:
http://www.mail-archive.com/rpm-...@rpm5.org/msg04548.html
Sorry, but despite our previous short discussion I still do _not_
understand what actual problem is
On Mon, Apr 13, 2009, Ralf S. Engelschall wrote:
Ok, I'm still in the process of fixing RPM 5.1 for the release of 5.1.8
and finally I'm now forced to deeper understand this change:
http://www.mail-archive.com/rpm-...@rpm5.org/msg04548.html
Sorry, but despite our previous short discussion I
On Apr 13, 2009, at 4:54 AM, Ralf S. Engelschall wrote:
Ok, I'm still in the process of fixing RPM 5.1 for the release of
5.1.8
and finally I'm now forced to deeper understand this change:
http://www.mail-archive.com/rpm-...@rpm5.org/msg04548.html
Sorry, but despite our previous short
On Apr 13, 2009, at 5:27 AM, Ralf S. Engelschall wrote:
Ok, building with --with-pcre=internal seems to be broken since a
longer time as mostly everybody seems to build with an external PCRE
today. rpmsx.h uses PCRE and hence we need the PCRE CPPFLAGS mostly
everywhere, too.
Well we have
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 Mon, Apr 13, 2009, Jeff Johnson wrote:
On Apr 13, 2009, at 4:54 AM, Ralf S. Engelschall wrote:
Ok, I'm still in the process of fixing RPM 5.1 for the release of
5.1.8
and finally I'm now forced to deeper understand this change:
http://www.mail-archive.com/rpm-...@rpm5.org/msg04548.html
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
Careful, there have been some sqlite issues reported
on fedora-de...@ I've never bothered to see whether
the root cause was gcc/packaging or actually sqlite3 itself.
73 de Jeff
On Apr 13, 2009, at 11:53 AM, Ralf S. Engelschall wrote:
RPM Package Manager, CVS Repository
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
This config change probably went to the wrong devtool target,
%macosx instead of %standalone ? (needed in both, though...)
--anders
RPM Package Manager, CVS Repository
http://rpm5.org/cvs/
__
__
Server:
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, Anders F Björklund wrote:
This config change probably went to the wrong devtool target,
%macosx instead of %standalone ? (needed in both, though...)
No, I intentionally changed both %standalone and %macosx because it is
needed in both and I don't wanted that it 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
Ralf S. Engelschall wrote:
This config change probably went to the wrong devtool target,
%macosx instead of %standalone ? (needed in both, though...)
No, I intentionally changed both %standalone and %macosx because it is
needed in both and I don't wanted that it is forgotten for %macosx.
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
We now released RPM 5.1.8, a maintenance version from the stable
RPM 5.1 branch. Find it under: http://rpm5.org/files/rpm/rpm-5.1/
Ralf S. Engelschall
r...@engelschall.com
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
On Mon, Apr 13, 2009, Ralf S. Engelschall wrote:
On Mon, Apr 13, 2009, Michael Jennings wrote:
-- skipping not existing local sub-directory: xz
configure: error: unable to find internal XZ libLZMA library
Was something omitted from the release tarball?
Yes, the XZ, PCRE and Syck were
On Mon, Apr 13, 2009, Michael Jennings wrote:
[...]
Yes, the XZ, PCRE and Syck were added to RPM 5.1 recently but a
corresponding entry in the top-level Makefile.am's EXTRA_DIST was
forgotten and hence those subdirs were not picked up into the
release tarball. Already fixed in CVS. But I
On Mon, Apr 13, 2009, Jeff Johnson wrote:
[...]
My only interest in internal stuff is to prevent
rpm development from coming full-stop for years
because distros choose not to say, distribute xar,
or change system Berkeley DB. Other than that,
internal is a huge waste of time and energy.
On Apr 13, 2009, at 3:10 PM, Ralf S. Engelschall wrote:
Unfortunately, building with the external libraries is not an option
for me. So I guess I'm stuck with 5.1.7 unless I decide to build
myself a new 5.1.8 tarball from CVS
Ok, 5.2a4 will have this fixed. But for 5.1.9 I really would
33 matches
Mail list logo
