Re: RPM not returning a failure code on some operations?!
On 15.03.11 22:48, Jeff Johnson wrote: [...] Yes a known problem. There are code paths throughout RPM which cannot return error codes properly without breaking API/ABI or because its work-in-progress. The above 2 cases seem pretty innocent, but its not going to surprise me to see more serious problems under a rpmgi also returning 0. IIRC, there was discussion (from Mark Hatle? arekm?) abt 2 rpmgi failure cases on rpm-devel@ here like August 2007. cvs annotate lib/rpmgi.c should show the time frame. I can wire up error codes (or find details why not) for those two error cases if you wish. With -i (and -q and -K) using the rpmgi iterator, its a bit more complex than just coding up if (open() 0) return errno because of the interlocked state in the rpmgi (Generalized Iterator). Ok, understood. I can look at rpm-5.1.9 (and all later versions) tonight if you want. I need to revisit the rpmgi pretty soon anyways, because hdlists-as-used-by-mandriva aren't the same as hdlists-as-used-by-rpm and its almost time to fix (Mandriva's not rpm's) divergence. But lemme ask first: Does openpkg need/use status returned from rpm? Is it ok to switch to EXIT_FAILURE instead of (what rpm has traditionally done) return no of failing packages Drilling EXIT_FAILURE everywhere has been on my todo++ list for abt 2 years, just, well, its gonna be messy and tedious (but returning no. of pkgs in 8 bits started to become silly in ~2001). OpenPKG itself doesn't use the RPM return code, but users of OpenPKG try to rely on the RPM return code for their deployment automatisms. Currently they have to use slow workarounds (query the RPM database after each RPM operation to see whether it succeeded, for instance) because they cannot rely on a !=0 return code from RPM. So, I think a general EXIT_FAILURE would be fully sufficient. It is just important that a !=0 return code exists in case of failures. If the !=0 return code can be more specific (various numbers for various failure cases) would be even cooler, but this is not really required. But a !=0 exit code in case of any errors really would be required. Currently I've to still keep OpenPKG at 5.1.9, so I even would need a patch or at least some hints how I can fix this error code for 5.1.9. If you fix it in HEAD with a single commit I also can try to backport this to 5.1.9. Although I've to confess that I've not hacked on RPM internals for many months now (and had to code in Java, Scala, etc) and certainly need some support from you, Jeff ;-) So, I really appreciate help from you, Jeff. Many thanks. Ralf S. Engelschall r...@engelschall.com www.engelschall.com __ RPM Package Managerhttp://rpm5.org Developer Communication Listrpm-devel@rpm5.org
RPM not returning a failure code on some operations?!
I got a report that RPM (here the older version 5.1.9) does not return a failure code (!= 0) on some operations where a failure code is strongly expected (and where RPM 4.x still returned a failure code). From the report: # openpkg rpm -i /tmp/asdf.rpm error: open of /tmp/asdf.rpm failed: No such file or directory # echo 0 0 # touch /tmp/asdf.rpm # openpkg rpm -i /tmp/asdf.rpm # echo 0 0 You can just ignore here the openpkg run-time wrapper in the report as the same problem occurs also when calling the rpm(1) executable directly. Before I investigate and jump deeper into the sources myself, is this a known problem (perhaps already fixed in versions 5.1.9)? Does anybody have a clue why RPM still returns just 0 on those errors? Any hints welcome... Thanks! Ralf S. Engelschall r...@engelschall.com www.engelschall.com __ RPM Package Managerhttp://rpm5.org Developer Communication Listrpm-devel@rpm5.org
Re: [CVS] RPM: rpm/ configure.ac
On Mon, Sep 28, 2009, Pinto Elia wrote: -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 -]) +dnl # build RPM instrumented for extra optimization/security (GCC only) +dnl # -fno-delete-null-pointer as the kernel does http://patchwork.kernel.org/patch/36060/ +if test .`$CC --version 21 | grep 'GCC'` != .; then +dnl # GNU GCC (usually gcc) +CFLAGS=$CFLAGS -fno-delete-null-pointer-checks -D_FORTIFY_SOURCE=2 -fexceptions -fstack-protector +fi AC_ARG_ENABLE(build-gcov, AS_HELP_STRING([--enable-build-gcov], [build RPM instrumented for gcov]), [dnl if test .$enableval = .yes; then @@ . Errr.. no, I don't think it is reasonable to enable all those flags just because one compiles with GCC. Please place all this again under an AC_ARG_ENABLE so that one has to explicitly enable the stuff. Just one example: things liks -fstack-protector is not available on all platforms where GCC exists, etc. Ralf S. Engelschall r...@engelschall.com www.engelschall.com __ RPM Package Managerhttp://rpm5.org Developer Communication Listrpm-devel@rpm5.org
Re: [CVS] RPM: popt/ popt.pc.in
On Tue, Aug 11, 2009, Pinto Elia wrote:
[...]
Drop -L from popt.pc : it cause problem - ref novelbz#529921
Err, no: sure, the /usr/lib64 fiddling of Linux distributions is a
problem, but just removing -L${libdir} in general is not the right
thing. Even for those Linux distros, the right thing is to _KEEP_
-L${libdir} _IF_ ${libdir} is _not_ /usr/lib, /usr/lib32 or /usr/lib64.
Else if you install POPT into non-system locations POPT will not link
at all. Second, POPT is a _platform unspecific_ C library and hence
always should use -L${libdir} as it is correct to do this. If a Linux
distro has any problems they have to patch it out theirself. But in the
upstream POPT distribution it has to be kept, please. Hence, please
backout the change or add Autoconf magic for particular platforms.
Ralf S. Engelschall
r...@engelschall.com
www.engelschall.com
__
RPM Package Managerhttp://rpm5.org
Developer Communication Listrpm-devel@rpm5.org
Re: m4-1.4.13: compilation errors for QNX
On Fri, Aug 07, 2009, Michael Baudisch wrote: Hi, when trying to compile the lastest m4 (1.4.13) in a QNX environment i get this compilation error: fseeko.c: In function 'rpl_fseeko': fseeko.c:82: error: '_MWRITE' undeclared (first use in this function) fseeko.c:82: error: (Each undeclared identifier is reported only once fseeko.c:82: error: for each function it appears in.) make[4]: *** [fseeko.o] Error 1 Any ideas? Problem occures for QNX6.4.0 and the latest QNX6.4.1. m4-1.4.12 is okay. For QNX you need a small patch: http://cvs.openpkg.org/chngview?cn=45918 Ralf S. Engelschall r...@engelschall.com www.engelschall.com __ RPM Package Managerhttp://rpm5.org Developer Communication Listrpm-devel@rpm5.org
endian.h not portable enough
The recently introduced message digest functions include the endian.h header. This one exists mainly on Linux only. It is not existing under BSD, Solaris, MacOS X, etc. So some Autoconf glue is necessary. Unfortunately I'm currenting moving with my family, so I have no time to investigate myself. Hence, I just wanted to let you know the issue... Ralf S. Engelschall r...@engelschall.com www.engelschall.com __ RPM Package Managerhttp://rpm5.org Developer Communication Listrpm-devel@rpm5.org
Re: [CVS] RPM: rpm-5_2: js/src/ jsprf.c jsstddef.h rpm/ configure.ac
On Thu, Jul 23, 2009, Per Øyvind Karlsen wrote: [...] fix va_list autofoo stuff breaking libjs build I'm wondering: 1. Why is HAVE_VA_LIST_AS_ARRAY defined but never used in the code? 2. Why are such changes committed directly to 5.2 and not to HEAD first? Ralf S. Engelschall r...@engelschall.com www.engelschall.com __ RPM Package Managerhttp://rpm5.org Developer Communication Listrpm-devel@rpm5.org
Nested RPM operations now lead to DB region error detected in 5.1.x
Although we've not changed the underlying DB version in RPM 5, since recently with 5.1.9 I see at the end of the OpenPKG bootstrap package upgrade: | rpmdb: PANIC: fatal region error detected; run recovery | error: db4 error(-30974) from db-cursor: DB_RUNRECOVERY: Fatal error, run database recovery | [...] | rpmdb: File handles still open at environment close | rpmdb: Open file handle: /v/gmbh/sw/RPM/DB/__db.001 | rpmdb: Open file handle: /v/gmbh/sw/RPM/DB/Packages | rpmdb: Open file handle: /v/gmbh/sw/RPM/DB/Basenames | rpmdb: Open file handle: /v/gmbh/sw/RPM/DB/Name | rpmdb: Open file handle: /v/gmbh/sw/RPM/DB/Sha1header | rpmdb: Open file handle: /v/gmbh/sw/RPM/DB/Triggername | rpmdb: Open file handle: /v/gmbh/sw/RPM/DB/Group | rpmdb: Open file handle: /v/gmbh/sw/RPM/DB/Providename | rpmdb: Open file handle: /v/gmbh/sw/RPM/DB/Requirename | rpmdb: Open file handle: /v/gmbh/sw/RPM/DB/Dirnames | rpmdb: Open file handle: /v/gmbh/sw/RPM/DB/Requireversion | rpmdb: Open file handle: /v/gmbh/sw/RPM/DB/Provideversion | rpmdb: Open file handle: /v/gmbh/sw/RPM/DB/Installtid | rpmdb: Open file handle: /v/gmbh/sw/RPM/DB/Sigmd5 | rpmdb: Open file handle: /v/gmbh/sw/RPM/DB/Filedigests | rpmdb: Open file handle: /v/gmbh/sw/RPM/DB/Packagecolor | rpmdb: Open file handle: /v/gmbh/sw/RPM/DB/Nvra | rpmdb: Open file handle: /v/gmbh/sw/RPM/DB/Filepaths | rpmdb: Open file handle: /v/gmbh/sw/RPM/DB/BuildEnvironment | rpmdb: PANIC: fatal region error detected; run recovery | error: db4 error(-30974) from dbenv-close: DB_RUNRECOVERY: Fatal error, run database recovery The reason is that because in %pre and %post a few rpm -q operations are performed. Those seem to be still work fine as before, but at the end of the outer rpm -U operation RPM seems to detect the above problem now. Nothing seems to be actually broken afterwards, but the above errors make me feel bad and also confuse users. Two questions come up for me: 1. Why were no such errors in the past with 5.0.x and = 5.1.[7-9] (approximately)? 2. What can we do to workaround this problem? Perhaps run the rpm -q operations in a special RPMDB read-only mode or something like this? Perhaps --define '__dbi_private yes'? Ralf S. Engelschall r...@engelschall.com www.engelschall.com __ RPM Package Managerhttp://rpm5.org Developer Communication Listrpm-devel@rpm5.org
Re: Nested RPM operations now lead to DB region error detected in 5.1.x
On Sun, Jul 19, 2009, devzero2000 wrote: [...] Hmm, perhaps the issue is that rpm died while in middle of Berkeley DB call which is something that obviously should not happen and this is a situation which doesn't get automatically cleaned up, almost if something abnormal happen, Can you try - if it is important do a backup first :=) - a manual 'rm -f /var/lib/rpm/__*' and see if this solve the issue ? The interesting point is that before the operation the region files (__db*) are just fine (before and even once again after all these errors). The problem exists just during the rpm -U call as it looks. Before and after everything is fine. I'll now retry by setting %__db_private during the %post processing. We'll see whether it helps... Ralf S. Engelschall r...@engelschall.com www.engelschall.com __ RPM Package Managerhttp://rpm5.org Developer Communication Listrpm-devel@rpm5.org
platform compatibility
Short question: if I have a ix86-centos5.0 platform where I build an RPM binary package (with RPM 5.1) and want to deploy it onto a ix86-centos5.2 platform (also with same RPM 5.1), I have to use --ignoreos. With RPM 4 we could have used the old rpmrc mechanism to configure a compatibility mapping as far as I can remember. What is the _configuration_ solution for RPM 5? Ralf S. Engelschall r...@engelschall.com www.engelschall.com __ RPM Package Managerhttp://rpm5.org Developer Communication Listrpm-devel@rpm5.org
Re: platform compatibility
On Fri, Jul 10, 2009, Anders F Björklund wrote: Ralf S. Engelschall wrote: Short question: if I have a ix86-centos5.0 platform where I build an RPM binary package (with RPM 5.1) and want to deploy it onto a ix86-centos5.2 platform (also with same RPM 5.1), Why is the .0 and .2 part of the platform OS, by the way ? OpenPKG uses GNU shtool's platform command and not RPM's built-in stripping and hence the OS string has the minor parts with them. Ralf S. Engelschall r...@engelschall.com www.engelschall.com __ RPM Package Managerhttp://rpm5.org Developer Communication Listrpm-devel@rpm5.org
Re: platform compatibility
On Fri, Jul 10, 2009, Jeff Johnson wrote: On Jul 10, 2009, at 3:26 AM, Ralf S. Engelschall wrote: Short question: if I have a ix86-centos5.0 platform where I build an RPM binary package (with RPM 5.1) and want to deploy it onto a ix86-centos5.2 platform (also with same RPM 5.1), I have to use --ignoreos. With RPM 4 we could have used the old rpmrc mechanism to configure a compatibility mapping as far as I can remember. What is the _configuration_ solution for RPM 5? The analogue to rpmrc (with arch and os comapt tables) is *RE's in /etc/rpm/platform with CPU-VENDOR-OS-GNU compatibility. Ah, right: I totally forgot that the platform file is able to contain regular expressions. Thanks for the hint, Jeff. Ralf S. Engelschall r...@engelschall.com www.engelschall.com __ RPM Package Managerhttp://rpm5.org Developer Communication Listrpm-devel@rpm5.org
Re: platform compatibility
On Fri, Jul 10, 2009, Jeff Johnson wrote:
On Jul 10, 2009, at 12:17 PM, Ralf S. Engelschall wrote:
The analogue to rpmrc (with arch and os comapt tables) is *RE's in
/etc/rpm/platform with CPU-VENDOR-OS-GNU compatibility.
Ah, right: I totally forgot that the platform file is able to contain
regular expressions. Thanks for the hint, Jeff.
While you're in the neighborhood ...
What is needed is a means to generate /etc/rpm/platform
in a disciplined and canonical way. For hysterical reasons,
RPM owns the mechanism, but distros own the strings,
and so deadlock ensues.
Since Consensus is Futile with OSS, well, the mechanism
is never used correctly, and new implementations (like libcpuinfo)
sprout and wither quite predictably repeatedly.
I know of no issues with the current /etc/rpm/platform
*RE mechanism, just noone wants to dirty their hands writing
*RE's.
But if you could whack out a scriptie framework for populating
/etc/rpm/platform, I'd be grateful. So would proyvind,
and PLD and Unity and ...
Well, for OpenPKG I use GNU shtool's platform command since about 9
years now and it always worked quite well. But it doesn't provide as
precise architecture identification as libcpuinfo as for OpenPKG such
precise information is not necessary. It is even the other way round:
in OpenPKG we use ix86 instead of i386, i586, i686, etc. And GNU shtool
consistently uses amd64 instead of x86_64 under Linux and amd64 under
Solaris, etc.
But I agree, a framework for populating the platform information sounds
reasonable. Best would be if such a framework can both use GNU shtool
as a backend, libcpuinfo as a backend, and possible others, too.
Hmmm... ad-hoc I would say that we should expand macros and then one
can do whatever a distro requires. For OpenPKG it can be something like
%(shtool platform ...), for others it could be %{lua: cpuinfo.get(...)},
etc.
Ralf S. Engelschall
r...@engelschall.com
www.engelschall.com
__
RPM Package Managerhttp://rpm5.org
Developer Communication Listrpm-devel@rpm5.org
Re: Using --with-tcl=external passed to db/dist/configure
On Sun, May 10, 2009, Jeff Johnson wrote: [...] Should I filter in db3/configure or change to --with-tclembed? IMHO use --with-tclembed here, but in general we really should filter in db3/configure all options as there are always conflict possibilities. Ralf S. Engelschall r...@engelschall.com www.engelschall.com __ RPM Package Managerhttp://rpm5.org Developer Communication Listrpm-devel@rpm5.org
Re: Implementing EVR comparisons using *RE's ?
On Wed, May 06, 2009, Jeff Johnson wrote:
While muddling through how to add rpmvercmp to JavaScript,
I find myself thinking Yet Again about how silly and feeble
and fragile and deficient rpmvercmp actually is.
So I ask the question:
Can *RE patterns that match newer but not older
packages be devised?
The general answer is boring: No, of course not.
Yes. RE's are good for _parsing_ individual versions into their parts,
but _comparing_ two versions should be done by comparing the parts
theirself after an RE parsing step. And this comparison is indepenent of
the RE parsing step itself.
So, IMHO what RPM should do is this:
1. There should be a PCRE-based version parsing macros defined
similar in spirit to what __VER__ expands to in vcheck(1) but which
has the focus on parsing a version into its _parts_:
%__rpm_version_part_parse(\d+|[^\d]+)
%__rpm_version_part_map (?g)[._-]+ \
(?i)^(?:d|dev(?:el)?)$ 0 \
(?i)^(?:s|snapshot)$ 1 \
(?i)^(?:a|alpha)$ 2 \
(?i)^(?:b|beta)$ 3 \
(?i)^(?:rc|candidate)$ 4 \
(?i)^(?:|r|release)$ 5 \
(?i)^(?:pl|patch)$ 6
This maps 0.9a7 to [0,5,9,2,7], 1.2.3 to [1,5,2,5,3], etc.
2. Then RPM should have a default implementation for comparison
which just compares the numbers of those result arrays, similar to
what rpmvercmp() does: first the first numbers, then the second
numbers, etc. Once one array is exhausted the comparison stops, too.
Additionally RPM should allow this comparison to be implemented
in an arbitrary embedded language via a macro:
%__rpm_version_compare %{...: }
This macro receives the two arrays and has to return -1, 0, +1.
This way the whole version comparing stuff is fully pluggable, as one
can define how a version is parsed into its chunks and second how those
chunks are compared.
But %track (and /usr/lib/rpm/vcheck.pl) are based
on *RE's and Get It Right! (i.e. detecting newer
upstream versions of tarballs) sufficiently often
that newer EVR comnparisons might be done with *RE's
rather than the usual slice-n-dice of alpha/digit/other
character sets and using strcmp(3).
The slice-n-dice is still present in my above RE solution, of course.
I don't think one can get rid of this. Even vcheck(1) internally does
something like this. Its __VER__ regex is just for matching the whole
version, not for comparison.
Perhaps a better (as in easier to answer) question is
How many types of versioning pattern templates would
need to recognized for rpmvercmp to be done
using *RE's instead?
I think the above two macros and their REs are suffcient. The first one
is applied repeateadly to determine the parts, the second ones REs are
applied in sequence on each resulting part for canoncalization/filter
purposes. The result always should be an array of numerically (and this
way easily) comparable parts.
Ralf S. Engelschall
r...@engelschall.com
www.engelschall.com
__
RPM Package Managerhttp://rpm5.org
Developer Communication Listrpm-devel@rpm5.org
Re: Implementing EVR comparisons using *RE's ?
On Fri, May 08, 2009, Jeff Johnson wrote: On May 8, 2009, at 12:29 PM, Jeff Johnson wrote: RPM versions are inequalities represented as half-planes, not points. half-planes is of course neither precise nor correct. But RPM EVR inequalities do not always have measure == 0 like points do. Can you be a little bit more specific here, Jeff, please? Because I'm not sure I understand why the result of -1/0/+1 is such unreasonable. From my personal point of view, version identifiers (I intentionally avoid the term number here, as those strings are not really numbers) are text-representations of _points_ in time on particular product _branches_. Comparing two versions means to decide whether they are equal or which one is the _successor_ of the other -- while _successor_ here is defined based on the particular product evolution process and the used branching scheme. This means that if the branching scheme is well known and the text-representations of versions in this scheme are precisely defined (as in: N.M.X correspond to the trunk at the N-th generation, there is a branch N.M forked off the trunk and a point X on this N.M branch, etc) then one can do a reasonable version comparison (even across branches) with the results -1/0/+1. If the scheme is not known or the text-representations of versions less precisely used, I agree: one can only return true/false. 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 rpm/rpmio/ librpmio.vers macro.c rpmmacro.h
On Tue, Apr 28, 2009, Jeff Johnson wrote: [...] Ralf: Your AutoFu testing for va_copy(0 is wonderful. But some problems are best avoided, not solved, if at all possible imho. [...] Sure, avoiding is always better then healing. Ralf S. Engelschall r...@engelschall.com www.engelschall.com __ RPM Package Managerhttp://rpm5.org Developer Communication Listrpm-devel@rpm5.org
Re: [CVS] RPM: rpm/js/ rpmmacro-js.c rpmmacro-js.h rpmps-js.c tjs.c rpm/js...
On Tue, Apr 28, 2009, Jeff Johnson wrote: - js: Macro: add a macro.expand() method. Cool... ;-) Ralf S. Engelschall r...@engelschall.com www.engelschall.com __ RPM Package Managerhttp://rpm5.org Developer Communication Listrpm-devel@rpm5.org
Re: [CVS] RPM: rpm/js/ rpmts-js.c tjs.c
On Thu, Apr 23, 2009, Jeff Johnson wrote: Arrays ... wotta concept! [...@fedora10 js]$ cat ts.js var ts = new Ts(); print(ts.NVRA[0], ts.NVRA[1]); print(ts.NVRA); print(JSON.stringify(ts.NVRA)); print(=== for (var keyval in Iterator(ts.NVRA))); for (var keyval in Iterator(ts.NVRA)) print(keyval); print(=== for (var key in Iterator(ts.NVRA,true))); for (var key in Iterator(ts.NVRA,true)) print(key); print(=== for each (var val in ts.NVRA)); for each (var val in ts.NVRA) print(val); print(=== for (var key in ts.NVRA)); for (var key in ts.NVRA) print(key); Now to figger a RESTful Iterator object with a yield ... I'm mebbe a week or two away from attempting random tag cloud mashups of NVRA's from rpmdb's. Tree maps for dependencies too. Scary, idn't it? Cool, seems like you are mutating to a JavaScript hacker with light speed, Jeff... ;-) I really like to see all this JavaScript stuff in RPM. If you proceed even further I can start converting my rather comprehensive RPM Lua stuff (which I never liked, but really worked well -- compare http://trainofthoughts.org/blog/2007/09/16/lua-popularity/) to RPM JS stuff (which certainly I would like a lot more because JavaScript is a really really good language, even if it also has a few rough edges). Ralf S. Engelschall r...@engelschall.com www.engelschall.com __ RPM Package Managerhttp://rpm5.org Developer Communication Listrpm-devel@rpm5.org
Re: [CVS] RPM: ACCESS DENIED: Jeff Johnson
On Mon, Apr 20, 2009, Jeff Johnson wrote: ATTENTION: ACCESS DENIED RPM Package Manager, CVS Repository denied IMPORT access for user Jeff Johnson j...@rpm5.org on files: Access now granted. Just retry. Ralf S. Engelschall r...@engelschall.com www.engelschall.com __ RPM Package Managerhttp://rpm5.org Developer Communication Listrpm-devel@rpm5.org
Re: [CVS] RPM: ACCESS DENIED: Jeff Johnson
On Mon, Apr 20, 2009, Jeff Johnson wrote: [...] OK, Thanks. Could you add ficl too? I'd like to just finish and forget Forth ... Done. BTW, you are way better at OO design than I. Do you have time to stub out a JavaScript object abstraction? Currently I've mostly no time available for any hackings at all. But there are two projects which do a lot of third-party library embedding into JavaScript (via SpiderMonkey API!) and which certainly can provide a few good hints: http://jsext.sourceforge.net/ http://code.google.com/p/jslibs/ As least those projects seem to have experiences in mapping existing stuff into JavaScript objects. Ralf S. Engelschall r...@engelschall.com www.engelschall.com __ RPM Package Managerhttp://rpm5.org Developer Communication Listrpm-devel@rpm5.org
RPM 5.1.9 released
We now released RPM 5.1.9, a distribution tarball bugfix release from the stable RPM 5.1 branch. Find it under: http://rpm5.org/files/rpm/rpm-5.1/ 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 VENDOR rpm/lib/ poptALL.c rpm/rpmio/ macro.c p...
On Sat, Apr 18, 2009, Jeff Johnson wrote: [...] The whole point of pushing into popt was less code that could be more generally used, not multiple implementations rotting under #ifdef's. Not that OpenPKG code is rotten by any means, but you know what I mean ... Sure, I fully agree to completely get rid of the whole duplicated code, of course. I just had to resurrect this old code chunks because it was the only possibilit to resurrect the reasonable warnings. As long as it can be achieved again with POPT 1.16 I'm happy to see the duplicated code chunks completely killed... 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 rpm/rpmio/ rpmjs.c
On Sat, Apr 18, 2009, Jeff Johnson wrote:
load() is gonna be needed, the others are largely useless:
[...@fedora10 wdj]$ rpm -E '%{js:version()}'
-- js 0x901d460 ++ 1 rpmjsNew at rpmjs.c:407
== rpmjsRun(0x901d460,version())
== Version(0x901ac98,0x9039000,0x9042020[0],0xbf7e8a90)
-- js 0x901d460 -- 1 expandMacro at macro.c:1931
== rpmjsFini(0x901d460) glob 0x9039000 cx 0x901ac98 rt 0x9021280
180
[...@fedora10 wdj]$ rpm -E '%{js:options()}'
-- js 0x8290460 ++ 1 rpmjsNew at rpmjs.c:407
== rpmjsRun(0x8290460,options())
== Options(0x828dc98,0x82ac000,0x82b5020[0],0xbf906090)
-- js 0x8290460 -- 1 expandMacro at macro.c:1931
== rpmjsFini(0x8290460) glob 0x82ac000 cx 0x828dc98 rt 0x8294280
j...@fedora10 wdj]$ rpm -E '%{js:load(p.js)}'
-- js 0x9d83de8 ++ 1 rpmjsNew at rpmjs.c:407
== rpmjsRun(0x9d83de8,load(p.js))
== Load(0x9d81850,0x9d9d000,0x9da6020[1],0xbfa07180)
== Print(0x9d81850,0x9d9d000,0x9da602c[1],0xbfa06840)
Hello World!
-- js 0x9d83de8 -- 1 expandMacro at macro.c:1931
== rpmjsFini(0x9d83de8) glob 0x9d9d000 cx 0x9d81850 rt 0x9d85280
undefined
[...@fedora10 wdj]$ cat p.js
print(Hello World!)
Really nice: JavaScript for RPM! I like it.
Please also don't forget the hack in the JavaScript equivalents of the
Lua rpm.query and rpm.expand functions. These are the driving horses
in most of the more complex RPM macros I know about...
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 rpm/rpmio/ poptIO.c
On Tue, Apr 14, 2009, Jeff Johnson wrote: On Apr 14, 2009, at 7:17 AM, Anders F Björklund wrote: Jeff Johnson wrote: This isn't the right fix because it ties the existence of a global symbol to whether bzip2 is configured. The global symbol needs to be exposed in spite of whether bzip2 is configured. It matches what is being done on the symbol side, which is likely to be equally wrong - but anyway. http://rpm5.org/cvs/chngview?cn=11885 It should probably check WITH_BZIP2 rather than HAVE_BZLIB_H, right ? Or provide the symbol always... Yes multiple wrongs aren't gonna fix this issue. The patch is consistent with what was previously done but that wasn't done correctly either. Agreed, HAVE_BZLIB_H checks should actually be WITH_BZIP2. I just used HAVE_BZLIB_H to be consistent with the code, but I'll now refactor this. [...] Dunno HAVE_BZLIB_H - WITH_BZIP2, rpm AutoFu is evolving. Done. Same for HAVE_LZMA_H - WITH_XZ... Ralf S. Engelschall r...@engelschall.com www.engelschall.com __ RPM Package Managerhttp://rpm5.org Developer Communication Listrpm-devel@rpm5.org
Re: Embedding bash/rc in RPM-5.2
On Wed, Apr 15, 2009, Jeff Johnson wrote:
Heh, that ratio between the size of bash and rc
the last time I checked was 5:1, now 10:1.
[...@fedora10 rc-1.7.1]$ ls -al rc
-rwxrwxr-x 1 jbj jbj 73688 2009-04-14 03:54 rc
[...@fedora10 rc-1.7.1]$ ls -al /bin/bash
-rwxr-xr-x 1 root root 756040 2008-10-28 17:37 /bin/bash
IIRC rc used to be 78K now 73K. But thats just a dim memory ...
As much as I'd like to roll a custom embedding for
a shell interpreter in RPM (and I would enjoy the hack, and I think
there's a need),
I cannot justify the effort until the concept of embedding interpreters
in RPM
is proven.
E.g. LUA has been embedded in RPM for years with hardly any use.
Part of that is perhaps that LUA is a minor language,
but the learning curve with LUA really isn't (and wasn't) bad.
Which means that there's very limited general interest in using
embedded interpreters for either of the reasons 1) or 2) listed at
http://rpm5.org/community/rpm-devel/3583.html
Embedded shell makes little sense (to me) for templating as in 3)
and no sense (to me) for 4) code development within RPM itself.
Feel free to convince me otherwise. Using the functionality
that already is implemented is quite sufficiently convincing.
Having a _builtin_ Bourne-Shell would increase the performance of %(...)
macros. For OpenPKG the lots of forking of /bin/sh due to many many
%(...) constructs lead to be rewrite many of them into %{lua:...}. With
a builtin Bourne-Shell one gets %(...) at higher speed, too.
Ralf S. Engelschall
r...@engelschall.com
www.engelschall.com
__
RPM Package Managerhttp://rpm5.org
Developer Communication Listrpm-devel@rpm5.org
Re: Embedding bash/rc in RPM-5.2
On Wed, Apr 15, 2009, devzero2000 wrote:
On Wed, Apr 15, 2009 at 2:20 PM, Ralf S. Engelschall rse+rpm-de...@rpm5.org
wrote:
On Wed, Apr 15, 2009, Jeff Johnson wrote:
Heh, that ratio between the size of bash and rc
the last time I checked was 5:1, now 10:1.
[...@fedora10 rc-1.7.1]$ ls -al rc
-rwxrwxr-x 1 jbj jbj 73688 2009-04-14 03:54 rc
[...@fedora10 rc-1.7.1]$ ls -al /bin/bash
-rwxr-xr-x 1 root root 756040 2008-10-28 17:37 /bin/bash
IIRC rc used to be 78K now 73K. But thats just a dim memory ...
As much as I'd like to roll a custom embedding for
a shell interpreter in RPM (and I would enjoy the hack, and I think
there's a need),
I cannot justify the effort until the concept of embedding interpreters
in RPM
is proven.
E.g. LUA has been embedded in RPM for years with hardly any use.
Part of that is perhaps that LUA is a minor language,
but the learning curve with LUA really isn't (and wasn't) bad.
Which means that there's very limited general interest in using
embedded interpreters for either of the reasons 1) or 2) listed at
http://rpm5.org/community/rpm-devel/3583.html
Embedded shell makes little sense (to me) for templating as in 3)
and no sense (to me) for 4) code development within RPM itself.
Feel free to convince me otherwise. Using the functionality
that already is implemented is quite sufficiently convincing.
Having a _builtin_ Bourne-Shell would increase the performance of %(...)
macros. For OpenPKG the lots of forking of /bin/sh due to many many
%(...) constructs lead to be rewrite many of them into %{lua:...}. With
a builtin Bourne-Shell one gets %(...) at higher speed, too.
Remains the choice of shell. Dash or ash? I prefer the dash
https://wiki.ubuntu.com/DashAsBinSh
Well, for RPM itself I would vote for Dash, but in OpenPKG we use Bash
everywhere. So, from my personal point of view, I would like to see
support for both in RPM... ;-) OTOH, for 99% if all %(...) macros Dash
is fully sufficient anyway, so I will be happy with just Dash, too.
Ralf S. Engelschall
r...@engelschall.com
www.engelschall.com
__
RPM Package Managerhttp://rpm5.org
Developer Communication Listrpm-devel@rpm5.org
Re: 5.1.8 Build Failure
On Wed, Apr 15, 2009, Jeff Johnson wrote: [...] Thank you! Don't forget the decimal in python2.5. No hury whatsoever, I don't care much as long as I can build. But others will care. This is now also implemented in RPM_CHECK_LIB... Ralf S. Engelschall r...@engelschall.com www.engelschall.com __ RPM Package Managerhttp://rpm5.org Developer Communication Listrpm-devel@rpm5.org
Re: Embedding interpreters: FICL?
On Wed, Apr 15, 2009, Jeff Johnson wrote: Unlike bash/rc embedding, FICL has a a rather simple API to embed and (unlike bash) is lean mean. But also unlike bash embedding, FICL has only 2 usage cases that I can think of: 1) FreeBSD boot loaders (dunno current state) 2) Mac OS X hardware/firmware fiddling There's perhaps a 3rd usage case within embedded systems that I'm (blissfully!) unaware of. The usage of Forth is so bleeping arcane that the arcaneness starts to justify embedding FICL into a more usable syntax to remove some of the arcaneness (jmho). And its quite conceivable that bootl oading and firmware fiddling need a packaging solution other than custom crafted deep dark chocolate that is likely currently being done. Should I embed FICL? I may do it anyways, the work is less effort than the discussion ... grin Well, I don't think anybody seriously will use FICL for anything inside RPM, but it would not hurt to have this option. For a more realistic thing: Having JavaScript available for scripting within RPM would have much more impact! Why? Because 1. JavaScript is a very very good language, even if it is one of the most underestimated ones and 2. JavaScript is known by many many people from all the Web stuff. Mozilla Spidermonkey has a nice API embedding, too. Ralf S. Engelschall r...@engelschall.com www.engelschall.com __ RPM Package Managerhttp://rpm5.org Developer Communication Listrpm-devel@rpm5.org
Re: Embedded interpreters: What AutoFU?
On Wed, Apr 15, 2009, Jeff Johnson wrote: The first is largely a name space choice Should the current WITH_FOOEMBED be redone as an option within a WITH_FOO hierarchy or left as an orthogonal --with-fooembed option choice? I think we should detach two things: currently --with-nameembed is an RPM_CHECK_LIB thing. I think we should make --with-name the generic RPM_CHECK_LIB thing to _locate_ the name library -- independent(!) what we then _DO_ with it! And then a --with-embed-name can select name for embedding (a prerequisite certainly is that --with-name was specified and name also found by RPM_CHECK_LIB, of course). This way all embeddings are under the prefix --with-embed and this way recognizeable. In the code we then do just the simple #if defined(WITH_name_EMBED), of course. Because Autoconf already ensured that name is available... Ralf S. Engelschall r...@engelschall.com www.engelschall.com __ RPM Package Managerhttp://rpm5.org Developer Communication Listrpm-devel@rpm5.org
Re: Embedding interpreters: FICL?
On Wed, Apr 15, 2009, Jeff Johnson wrote: [...] I know where the FICL API lives. Got a pointer to JavaScipt embedding API? Mozilla's JavaScript C implementation is named Spidermonkey and can be found under http://www.mozilla.org/js/spidermonkey/. Unfortunately, Mozilla does provide stand-alone distributions of Spidermonkey under http://ftp.mozilla.org/pub/mozilla.org/js/ but it usually cannot be easily be built. That's why in the past I created OSSP js: http://www.ossp.org/pkg/lib/js/ This is a Autoconf-enabled and portability enhanced version of SpiderMonkey 1.6. Once I find time and motivation I'll update this to the newer 1.7 and 1.8 versions. But the API is mostly the same since years. So, for your development you can even just install an arbitrary Linux package of Firefox and link against its libmozjs. But OSSP js is certainly less heavy than a whole Firefox installation... 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 rpm/rpmio/ macro.c poptIO.c rpmio.c rpmperl.c ...
On Wed, Apr 15, 2009, Jeff Johnson wrote: I've also started removing much of the #ifdef WITH_FOO_BAR_BAZ fluff for the reasons I've stated previously. I do not quite understand what you are approaching, but at least the TCL stuff is not finished: rj/rpm/src/3rd/bin/ix86-freebsd6.4/beecrypt-4.1.2/.libs/libbeecrypt.a -llzma -lbz2 /d2/u/rse/prj/rpm/src/3rd/bin/ix86-freebsd6.4/popt-1.15/.libs/libpopt.a -lssl -lcrypto /d2/u/rse/prj/rpm/src/3rd/bin/ix86-freebsd6.4/libxml2-2.7.3/.libs/libxml2.a -lz -lm -Wl,-rpath -Wl,/d2/u/rse/prj/rpm/src/3rd/bin/ix86-freebsd6.4/xar-1.5.2/lib/.libs -Wl,-rpath -Wl,/usr/local/lib ../rpmio/.libs/librpmio.a(poptIO.o):(.data+0x684): undefined reference to `_rpmtcl_debug' ../rpmio/.libs/librpmio.a(rpmio.o): In function `rpmioClean': /u/rse/prj/rpm/src/rpm/rpmio/rpmio.c:3162: undefined reference to `_rpmtclI' /u/rse/prj/rpm/src/rpm/rpmio/rpmio.c:3162: undefined reference to `_rpmtclI' /u/rse/prj/rpm/src/rpm/rpmio/rpmio.c:3163: undefined reference to `_rpmtclPool' /u/rse/prj/rpm/src/rpm/rpmio/rpmio.c:3163: undefined reference to `_rpmtclPool' collect2: ld returned 1 exit status make[3]: *** [rpm2cpio] Error 1 make[3]: Leaving directory `/d2/u/rse/prj/rpm/src/rpm/tools' Ralf S. Engelschall r...@engelschall.com www.engelschall.com __ RPM Package Managerhttp://rpm5.org Developer Communication Listrpm-devel@rpm5.org
Re: Embedding bash/rc in RPM-5.2
On Wed, Apr 15, 2009, Jeff Johnson wrote: On Apr 15, 2009, at 8:51 AM, Ralf S. Engelschall wrote: Well, for RPM itself I would vote for Dash, but in OpenPKG we use Bash everywhere. So, from my personal point of view, I would like to see support for both in RPM... ;-) OTOH, for 99% if all %(...) macros Dash is fully sufficient anyway, so I will be happy with just Dash, too. There is another approach to avoiding the fork/exec overhead of popen(3) tied to %(...) macro syntax. What could be done is run a single shell process persistently as a coroutine. Then, e.g. the construct %(ls -1 /) could be fed to the persistent co-routine shell as RESULT=`ls -1 /` echo $RESULT There's likely some detail that I'm overlooking that would make this much harder than it sounds, but I haven't been able to figger that yet. What do I miss? Sure traps/signals, but ... At least for most %() constructs I can image that a popen(3) approach would work... Ralf S. Engelschall r...@engelschall.com www.engelschall.com __ RPM Package Managerhttp://rpm5.org Developer Communication Listrpm-devel@rpm5.org
The twisted LUA - PCRE and rpmio/rpmmisc??!!
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 fixed here and additionally the patch is partly broken and causes new problems. Not even to mention that the introduced extra twist via rpmio and rpmmisc got the whole story even more complicated and without understanding me the necessarity. For me, Jeff, you had two problems: 1. PCRE vs. PCREPOSIX. Ok, the _source_ of this problem (why for you PCREPOSIX _contains_ PCRE) is unclear, but I understand your problem. You want to link just against PCREPOSIX now. Unfortunately your change to configure.ac now means that for platforms where PCREPOSIX does NOT contain PCRE we now miss to link against PCRE at all. So, here we at least have to fix configure.ac but then we can keep your workaround. 2. The library dependencies. This is the part of your dependency changes I do not understand. I see what you have done, but I do not understand what the problem is which should be fixed. Instead I see new problems caused by this (currently building fails because Lua symbols are no longer seen under at least FreeBSD and Solaris). This part of your change I really would like to reverse. If then there _IS_ still a second problem beside (1) above we can attempt a new fix from scratch. Would this be acceptable for you, Jeff? Ralf S. Engelschall r...@engelschall.com www.engelschall.com __ RPM Package Managerhttp://rpm5.org Developer Communication Listrpm-devel@rpm5.org
Re: The twisted LUA - PCRE and rpmio/rpmmisc??!!
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 still do _not_ understand what actual problem is fixed here and additionally the patch is partly broken and causes new problems. Not even to mention that the introduced extra twist via rpmio and rpmmisc got the whole story even more complicated and without understanding me the necessarity. For me, Jeff, you had two problems: 1. PCRE vs. PCREPOSIX. Ok, the _source_ of this problem (why for you PCREPOSIX _contains_ PCRE) is unclear, but I understand your problem. You want to link just against PCREPOSIX now. Unfortunately your change to configure.ac now means that for platforms where PCREPOSIX does NOT contain PCRE we now miss to link against PCRE at all. So, here we at least have to fix configure.ac but then we can keep your workaround. 2. The library dependencies. This is the part of your dependency changes I do not understand. I see what you have done, but I do not understand what the problem is which should be fixed. Instead I see new problems caused by this (currently building fails because Lua symbols are no longer seen under at least FreeBSD and Solaris). This part of your change I really would like to reverse. If then there _IS_ still a second problem beside (1) above we can attempt a new fix from scratch. Would this be acceptable for you, Jeff? 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. Ok, I'm now doing the following: 1. I partly reversing Jeff's recent Lua/PCRE library dependency twist and then 2. try to fix the Lua/PCRE dependency issues in a less twisted way by using the approach from previous ages but with the PCRE issues fixed. Hopefully I'm successful. Let's see... Ralf S. Engelschall r...@engelschall.com www.engelschall.com __ RPM Package Managerhttp://rpm5.org Developer Communication Listrpm-devel@rpm5.org
Ops? RPM 5.1 FIXME outputs...
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 /usr/opkg/RPM/TMP/rpm-tmp.33785 | + cd /usr/opkg/RPM/TMP | + cd ncurses-5.7 | + rm -rf /usr/opkg/RPM/TMP/ncurses-5.7.20090411-20090412-buildroot | + rm -rf /usr/opkg/RPM/TMP/ncurses-5.7.20090411-20090412-buildroot | Executing(--clean): env -i /usr/opkg/lib/openpkg/bash --norc --noprofile --posix -e /usr/opkg/RPM/TMP/rpm-tmp.18778 | + cd /usr/opkg/RPM/TMP | + rm -rf ncurses-5.7 | == FIXME: pool fi: made 4 count 3 | == FIXME: pool h: made 5 count 4 | Preparing...### [100%] |1:ncurses### [100%] | [...] | Processing files: pcre-7.9-20090411 | Wrote: /usr/opkg/RPM/PKG/pcre-7.9-20090411.amd64-debian5.0-opkg.rpm | Executing(%clean): env -i /usr/opkg/lib/openpkg/bash --norc --noprofile --posix -e /usr/opkg/RPM/TMP/rpm-tmp.80888 | + cd /usr/opkg/RPM/TMP | + cd pcre-7.9 | + rm -rf /usr/opkg/RPM/TMP/pcre-7.9-20090411-buildroot | + rm -rf /usr/opkg/RPM/TMP/pcre-7.9-20090411-buildroot | Executing(--clean): env -i /usr/opkg/lib/openpkg/bash --norc --noprofile --posix -e /usr/opkg/RPM/TMP/rpm-tmp.80888 | + cd /usr/opkg/RPM/TMP | + rm -rf pcre-7.9 | == FIXME: pool fi: made 4 count 3 | == FIXME: pool h: made 5 count 4 | Preparing...### [100%] |1:pcre ### [100%] Jeff, any clue? At least it looks that the build and install went just fine. Perhaps this is just debug outputs remaining? Or do we have a problem? Ralf S. Engelschall r...@engelschall.com www.engelschall.com __ RPM Package Managerhttp://rpm5.org Developer Communication Listrpm-devel@rpm5.org
Re: The twisted LUA - PCRE and rpmio/rpmmisc??!!
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 Sorry, but despite our previous short discussion I still do _not_ understand what actual problem is fixed here and additionally the patch is partly broken and causes new problems. Not even to mention that the introduced extra twist via rpmio and rpmmisc got the whole story even more complicated and without understanding me the necessarity. For me, Jeff, you had two problems: The problem I'm solving is rather sumple: ./devtool jbj ... make doesn't for me on Fedora (where -lpcre is not patched). Ok, I'll try this with HEAD once we have RPM 5.1 stable again and rolled out of the door. Ralf S. Engelschall r...@engelschall.com www.engelschall.com __ RPM Package Managerhttp://rpm5.org Developer Communication Listrpm-devel@rpm5.org
Re: Ops? RPM 5.1 FIXME outputs...
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 issue confused me, as I was sure I've correctly fixed the linking of Lua. Ok, now to this issue. To me looks not that libpcre.a is bundled into libpcreposix.a. Instead it looks that libpcreposix is bundled into liblua.a!! Ralf S. Engelschall r...@engelschall.com www.engelschall.com __ RPM Package Managerhttp://rpm5.org Developer Communication Listrpm-devel@rpm5.org
Re: Ops? RPM 5.1 FIXME outputs...
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 s/lib_/noinst_/ in pcre/Makefile.am. Ah, ok, better. This _IS_ the problem I'm not investigating. The Lua issue confused me, as I was sure I've correctly fixed the linking of Lua. Ok, now to this issue. To me looks not that libpcre.a is bundled into libpcreposix.a. Instead it looks that libpcreposix is bundled into liblua.a!! I'll bet its the same issue w static helper libraries using libtool. Meanwhile, lets back up a bit ... Ok, I've restored to the status quo was worked just fine in the past. Jeff, please do a fresh build (make distclean first, please). Let's see whether it finally build for you again, too. Ralf S. Engelschall r...@engelschall.com www.engelschall.com __ RPM Package Managerhttp://rpm5.org Developer Communication Listrpm-devel@rpm5.org
Re: Ops? RPM 5.1 FIXME outputs...
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 extending is quite elegant and nicely done, with byte code and everything. But the bloaty/hacky addition of chkconfig et al shows the insanity of this approach. Note that I've promised to supply a means to run cross-platform scripts at the functionality level of what has been embedded into lua. But the way that this is done currently in lua/chkconfig/ is just sad and sick, No time. mea culpa, but I've been trying since last September to devise better, embedding tcl/python/perl/ruby is just original goal evolved ... 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 linked directly into Lua. This especially would allow one to reasonably use an external Lua (and still get RPM functionality), of course. But I'm not sure whether this can be easily achieved. With the current 5.1 issues we see how fragile all this link-time stuff is. Just small changes cause major trouble. Ralf S. Engelschall r...@engelschall.com www.engelschall.com __ RPM Package Managerhttp://rpm5.org Developer Communication Listrpm-devel@rpm5.org
Re: Ops? RPM 5.1 FIXME outputs...
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 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 issue confused me, as I was sure I've correctly fixed the linking of Lua. Ok, now to this issue. To me looks not that libpcre.a is bundled into libpcreposix.a. Instead it looks that libpcreposix is bundled into liblua.a!! I'll bet its the same issue w static helper libraries using libtool. Meanwhile, lets back up a bit ... Ok, I've restored to the status quo was worked just fine in the past. Jeff, please do a fresh build (make distclean first, please). Let's see whether it finally build for you again, too. 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 additional platform tests and then roll 5.1.8 Ralf S. Engelschall r...@engelschall.com www.engelschall.com __ RPM Package Managerhttp://rpm5.org Developer Communication Listrpm-devel@rpm5.org
Re: Ops? RPM 5.1 FIXME outputs...
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 additional platform tests and then roll 5.1.8 I've got some pesky loader map churn: [...] Ah, ok. These might be from the 5.1.3 to 5.1.4 upgrade of the past. Fixing now ... Thanks. Does RPM 5.1 now finally build for you again, Jeff? Ralf S. Engelschall r...@engelschall.com www.engelschall.com __ RPM Package Managerhttp://rpm5.org Developer Communication Listrpm-devel@rpm5.org
Re: [CVS] RPM: rpm/ devtool.conf
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 forgotten for %macosx. Ralf S. Engelschall r...@engelschall.com www.engelschall.com __ RPM Package Managerhttp://rpm5.org Developer Communication Listrpm-devel@rpm5.org
Re: Ops? RPM 5.1 FIXME outputs...
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, and is inevitable imho when there is more than a single file for #include uuid.h But if you could figger the AutoFu to fox the issue (by not including -I/usr/include/uuid on Fedora) I'd be grateful. What UUID implementation is under /usr/include/uuid? I guess it is not OSSP uuid, right? Hence the problem. But where is OSSP uuid's uuid.h then? Just under /usr/include/ in Fedora? Ralf S. Engelschall r...@engelschall.com www.engelschall.com __ RPM Package Managerhttp://rpm5.org Developer Communication Listrpm-devel@rpm5.org
Re: Ops? RPM 5.1 FIXME outputs...
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 --with-uuid=/usr/lib:/usr/include is likely all I need to do. I'm still learning how to use RPM_CHECK_LIB() ... ;-) Yes, RPM_CHECK_LIB certainly is worth half a book. BTW, what does the commands uuid-config --cflags and pkg-config uuid --cflags output under Fedora? Ralf S. Engelschall r...@engelschall.com www.engelschall.com __ RPM Package Managerhttp://rpm5.org Developer Communication Listrpm-devel@rpm5.org
Re: Ops? RPM 5.1 FIXME outputs...
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 Fedora) I'd be grateful. Actually, changing devtool.conf from --with-uuid=external \ to --with-uuid=/usr/lib:/usr/include is likely all I need to do. I'm still learning how to use RPM_CHECK_LIB() ... ;-) Yes, RPM_CHECK_LIB certainly is worth half a book. BTW, what does the commands uuid-config --cflags and pkg-config uuid --cflags output under Fedora? j...@fedora10 wdj51]$ uuid-config --cflags -I/usr/include [...@fedora10 wdj51]$ pkg-config uuid --cflags -I/usr/include/uuid Ops? This looks strange to me. RPM_CHECK_LIB prefers pkg-config(1), so it is clear why you get -I/usr/include/uuid into your Makefiles. But why are the two outputs different? OSSP uuid uses a consistent include path. Seems like Fedora is patching something here and perhaps even forgot to patch uuid-config. Or the uuid-config is from a different package than OSSP uuid? IIRC, Fedorable changed its mind on what they do. So what else is new? Can you check who owns /usr/include/uuid.h, /usr/include/uuid and /usr/include/uuid/uuid.h? To me it looks like there is a mixture of OSSP uuid and Ext2Utils's libuuid in Fedora. Ralf S. Engelschall r...@engelschall.com www.engelschall.com __ RPM Package Managerhttp://rpm5.org Developer Communication Listrpm-devel@rpm5.org
RPM 5.1.8 released
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 www.engelschall.com __ RPM Package Managerhttp://rpm5.org Developer Communication Listrpm-devel@rpm5.org
Re: Ops? RPM 5.1 FIXME outputs...
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 old libuuid stuff from e2fsprogs and the OSSP uuid stuff. The /usr/include/uuid.h is from OSSP uuid while the libuuid stuff is in /usr/include/uuid/uuid.h/. Unfortunately, libuuid provides a uuid.pc pkg-config(1) script which RPM_CHECK_LIB prefers over uuid-config. Hmmm... strange, usually OSSP uuid provides uuid.pc and libuuid has no such uuid.pc. Seems like the Fedora people manually remove OSSP uuid's uuid.pc and manually install a uuid.pc for libuuid instead. So, it is clear that this invervention breaks us. Hmmm... I see out-of-the-box solution here as it could be also vice-versa: Fedora could provide a uuid-config for libuuid. So, I still don't see a generic solution to the problem. I think Fedora should provide a ossp-uuid.pc and a e2fsprogs-uuid.pc instead... Ralf S. Engelschall r...@engelschall.com www.engelschall.com __ RPM Package Managerhttp://rpm5.org Developer Communication Listrpm-devel@rpm5.org
Re: 5.1.8 Build Failure
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 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 don't think we really have to immediately release a fixed 5.1.9 because one still can build with the external versions just fine and even 5.1.7 already missed a few subdirs, too. --with-xz=internal worked in 5.1.7... Err... no, I don't think this is true. 5.1.7 was also broken as it looks: $ gunzip rpm-5.1.7.tar.gz | tar tvf - | egrep '(lzma|xz)' -rw-r--r-- rpm/rpm2119 2007-10-14 10:22 rpm-5.1.7/xar/lib/lzmaxar.h -rw-r--r-- rpm/rpm9832 2008-05-23 22:44 rpm-5.1.7/xar/lib/lzmaxar.c Ralf S. Engelschall r...@engelschall.com www.engelschall.com __ RPM Package Managerhttp://rpm5.org Developer Communication Listrpm-devel@rpm5.org
Re: 5.1.8 Build Failure
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 don't think we really have to immediately release a fixed 5.1.9 because one still can build with the external versions just fine and even 5.1.7 already missed a few subdirs, too. 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 like to wait a few days until everything settled. The problem is not a the version is totally broken issue and hence an immediate rush in the release of 5.1.9 is not reasonable IMHO. Let's wait a few days and if no more such bugs occur I'll release 5.1.9 with this (and perhaps other) fixes in a few days (at last on Friday). Ralf S. Engelschall r...@engelschall.com www.engelschall.com __ RPM Package Managerhttp://rpm5.org Developer Communication Listrpm-devel@rpm5.org
Re: 5.1.8 Build Failure
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. Well, one possibility could be to provide _TWO_ release tarballs for a RPM version: rpm-M.N.P.tar.gz and (for instance) rpm-deps-M.N.P.tar.gz. In rpm-M.N.P.tar.gz the bare RPM sources are while in rpm-deps-M.N.P.tar.gz all third-party dependency libraries are located. OTOH, I personally would completely kick out all local stuff except those which have RPM-specific modifications (like Lua or DB) and delegate it to the distribution vendors to take care of the dependencies theirself... Ralf S. Engelschall r...@engelschall.com www.engelschall.com __ RPM Package Managerhttp://rpm5.org Developer Communication Listrpm-devel@rpm5.org
Re: [CVS] RPM: rpm-5_1: rpm/ INSTALL devtool.conf
On Sun, Apr 12, 2009, Jeff Johnson wrote: Hmmm, poptReadFile() likely goes AWOL w/o popt-1.15. Which breaks the new wiring for --queryformat /usr/lib/rpm/qf/mumble So, we should require POPT 1.15 also in RPM 5.1 because of run-time issues? At least RPM 5.1 _builds_ just fine against POPT 1.15 as far as I see it currently... Ralf S. Engelschall r...@engelschall.com www.engelschall.com __ RPM Package Managerhttp://rpm5.org Developer Communication Listrpm-devel@rpm5.org
Re: A (very minor) RPM_CHECK_LIB() flaw
On Thu, Apr 09, 2009, Jeff Johnson wrote: On Apr 9, 2009, at 1:46 PM, Jeff Johnson wrote: Here's a snippet from #rpm (pogma == Peter O'Gorman) that likely explains how to solve the s/./_/ issue in RPM_CHECK_LIB() using M4: pogma jbj: Hi, AS_TR_SH should translate . to _ etc for configure. http://www.gnu.org/software/autoconf/manual/autoconf.html#Programming-in-M4sh OK. I've tried AS_TR_SH() voo-doo and I appear to have succeeeded both in replacing a . with an _ (here's the expansion, note no . and properly quoted): I'll look at this in more detail and try to figure out what the correct solution is which hopefully does not break other use cases... Ralf S. Engelschall r...@engelschall.com www.engelschall.com __ RPM Package Managerhttp://rpm5.org Developer Communication Listrpm-devel@rpm5.org
Re: Embedding interpreters in RPM: on beyond LUA
On Thu, Apr 09, 2009, Jeff Johnson wrote: [...] missing from the above is shell. Go figger, /bin/sh is the great granddaddy of all other interpreters and yet there are no embedded shell script implementations that I'm aware of. I will likely attempt a custom embedding of Plan9 rc(1) if I can't find a better alternative for an embedded shell interpreter. During build of GNU bash 4.0 I see that a nice libsh.a/libbuiltins.a pair is used internally. Those libs are not installed, just used for internal building. As I think GNU Bash is both one of the most rock solid and featureful Bourne-Shell implementations, I think you should have a peek into this libsh.a/libbuiltins.a from Bash first. Plan 9's rc certainly is small, but less portable. For Plan 9's rc, at least use the version 1.7.1 which in the past was at http://www.star.le.ac.uk/~tjg/rc/ to get a decent portable variant. I currently have no clue where it went to and where its new homepage is... Ralf S. Engelschall r...@engelschall.com www.engelschall.com __ RPM Package Managerhttp://rpm5.org Developer Communication Listrpm-devel@rpm5.org
Re: Embedding issue #1: global interpreter persistence
On Fri, Apr 10, 2009, Jeff Johnson wrote:
[...]
How hard should I work at having multiple interpreters with
luser enabled selectable criteria for global persistence (or not)?
Note: that embedded lua has it both ways already, and its really not
hard code. The issue for me is Should I do this? not How to do this
...?
Hmmm... for %post -p lang they certainly most of the time expect
new interpreter, every time while for %{lang:...} this usually can
hurt very much (as one has no variables at hand). But I see situations
where it can be exactly vice versa: if one wants to share details
between %build and %install one needs a shared interpreter and even
for %{lang:...} sometimes it can be useful to get a fresh new
interpreter. So, h... yes, I would say: you SHOULD ALLOW PEOPLE TO
CHOOSE THE MODE (with an option?), in both situations.
Ralf S. Engelschall
r...@engelschall.com
www.engelschall.com
__
RPM Package Managerhttp://rpm5.org
Developer Communication Listrpm-devel@rpm5.org
Re: A (very minor) RPM_CHECK_LIB() flaw
On Tue, Apr 07, 2009, Michael Jennings wrote:
On Tuesday, 07 April 2009, at 18:03:43 (-0400),
Jeff Johnson wrote:
./configure: line 57086: .${ac_cv_lib_python2.5_Py_Initialize}: bad
substitution
checking whether to build with Python embedding library... /usr/lib:/
usr/include/python2.5
++ executing failure action
configure: error: unable to find usable Python embedding library
Any hints? I can hardly see any difference between perl - python
other than the extra with-arg-location : with-arg-location
Could it be the '.' in python2.5?
Yes, that's the problem. The dot in the library name cannot be directly
used as a part in a shell variable name. Hence the shell complains.
We have to convert the dots to underscores, for instance.
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 rpm/lib/ poptALL.c
On Mon, Apr 06, 2009, Jeff Johnson wrote:
Ralf: I lasted almost 30 minutes attempting to do
rpm --eval %{lua:xx = syck.load(\`cat popt.yaml`\);
print(syck.dump(xx));}
will all the bleeping sugary syntactical wrapping before deciding
There *HAS* to be a better way.
I have no idea how you withstood the pain of rpm+lua ;-)
Well, you're right: the escaping is a little bit nasty.
But, at least it all the time is exactly the same problem.
So, during hacking on RPM Lua scripts one gets used to this ;-)
So I've added
rpm --eval /path/to/lua
which does the %{lua:...} wrapping automagically around file contents.
Ah, ok. But what you are doing now is the same as:
$ rpm --eval %{lua: `cat /path/to/lua`}
Why I would have expected:
$ rpm --eval %{lua: rpm.source(\/path/to/lua\) }
Because the rpm.source() uses the internal luaL_loadfile() C function
and hence it does not require any escapings to be inside /path/to/lua.
While in your approach to me looks like one still has to apply escaping
for RPM macros within /path/to/lua...
(aside)
I'd really like to make popt-1.15 mandatory so I don't have to
carry around 5+ more copies of poptReadFile() for portability.
Sure, I see no problem here...
Ralf S. Engelschall
r...@engelschall.com
www.engelschall.com
__
RPM Package Managerhttp://rpm5.org
Developer Communication Listrpm-devel@rpm5.org
Re: A (very minor) RPM_CHECK_LIB() flaw
On Tue, Apr 07, 2009, Jeff Johnson wrote: I'm chasing Perl ExtUtils::Embed -lperl and perl.h using this configure switch in devtool.conf: ... --with-perl \ --with-perlembed=/usr/lib/perl5/5.10.0/i386-linux-thread- multi/CORE \ --with-build-extlibdep \ ... I'm seeing (and reporting as instructed ;-) this spewage during configure: ... ++ executing success action ++ searching location: /usr/lib/perl5/5.10.0/i386-linux-thread-multi/ CORE -- extending CPPFLAGS: -I/usr/lib/perl5/5.10.0/i386-linux-thread-multi/ CORE -- extending LDFLAGS: -L/usr/lib/perl5/5.10.0/i386-linux-thread-multi/ CORE checking perl.h usability... no checking perl.h presence... yes configure: WARNING: perl.h: present but cannot be compiled configure: WARNING: perl.h: check for missing prerequisite headers? configure: WARNING: perl.h: see the Autoconf documentation configure: WARNING: perl.h: section Present But Cannot Be Compiled configure: WARNING: perl.h: proceeding with the preprocessor's result configure: WARNING: perl.h: in the future, the compiler will take precedence configure: WARNING: ## - ## configure: WARNING: ## Report this to rpm-devel@rpm5.org ## configure: WARNING: ## - ## checking for perl.h... yes checking for perl_alloc in -lperl... yes checking whether to build with Perl ExtUtils::Embed library... yes (external: directory /usr/lib/perl5/5.10.0/i386-linux-thread-multi/CORE) ++ executing success action ++ searching location: external checking tcl.h usability... yes checking tcl.h presence... yes checking for tcl.h... yes checking for Tcl_CreateInterp in -ltcl... yes checking whether to build with Tcl library... yes (external: implicitly) ... No worries, I'll hack around or fix, its my insanity ;-) Yes, this happens AFAIK if for #include perl.h one first has to #include some pre-requisite headers (like sys/types.h or something). It is harmless but nasty to see, of course. 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:
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: file/ mkinstalldirs rpm/ acinclude.m4 configure.ac
On Tue, Apr 07, 2009, Pinto Elia wrote: devzero2000: Update autoconf version in AC_PREREQ in configure.ac - use the same as in autoconf. Replace via autoupdate the obsolete macros AC_TRY_RUN and AC_HELP_STRING. Do the same on acinclude.m4. [...] Err.. what is the reason for all those reformattings related to AC_HELP_STRING? Ralf S. Engelschall r...@engelschall.com www.engelschall.com __ RPM Package Managerhttp://rpm5.org Developer Communication Listrpm-devel@rpm5.org
Re: Compilation errors for QNX640 due to __mutex_lock
On Fri, Mar 20, 2009, Jeff Johnson wrote: [...] Note that the patch is almost certainly going to get blown away when internal Berkeley DB is upgraded down the road. Apologies for losing the patch in advance ;-) If done through the correct cvs import and followed by a correct conflict resultion commit it should not really get lost ;-) But it usually helps to annotate the change with an RPM-related tag (e.g. /* RPM workaround */) so on the conflict resolution step it is not too easily overlooked... Ralf S. Engelschall r...@engelschall.com www.engelschall.com __ RPM Package Managerhttp://rpm5.org Developer Communication Listrpm-devel@rpm5.org
Re: Adding lua to -lrpmio to change how PCRE is attached.
On Wed, Mar 18, 2009, Jeff Johnson wrote: Last chance to suggest a better alternative, todo++. Hmmm... I've still not alternative at hand, because I still do not quite understands the problem. RPM conditionally requires PCRE for the regex stuff. And Lua conditionally also requires PCRE for the regex stuff. What does currently prevent building RPM just with PCRE and just with LUA only? Is there an understanding of the LUA - PCRE problem? Those library dependencies are always subtle issues, of course. I'm still not convinced what the best approach is. Let me check this this evening once again in more detail. I really would like to avoid introducing new problems by fixing one old problem. Expect a reply from me soon. Ralf S. Engelschall r...@engelschall.com www.engelschall.com __ RPM Package Managerhttp://rpm5.org Developer Communication Listrpm-devel@rpm5.org
Re: [CVS] RPM: rpm-5_1: rpm/ CHANGES rpm/lib/ psm.c rpm/rpmio/ librpmio.ve...
On Sun, Mar 15, 2009, Jeff Johnson wrote: I have the rest of the needed XZ changes pending, but cvs seems to have gone south. Check-in pending tomorrow ... Yes, there was a server problem this night. But it is already fixed. Feel free to commit again... 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 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
Build error: yarn pthreads
The latest yarn stuff seems to unconditionally use Pthreads. Can we make this optional so RPM still can be built without any threading stuff at all? /bin/ix86-freebsd6.4/xar-1.5.2/lib/.libs -Wl,-rpath -Wl,/usr/local/lib ../rpmio/.libs/librpmio.a(yarn.o): In function `yarnReenter': /u/rse/prj/rpm/src/rpm/rpmio/yarn.c:330: undefined reference to `pthread_equal' ../rpmio/.libs/librpmio.a(yarn.o): In function `yarnIgnition': /u/rse/prj/rpm/src/rpm/rpmio/yarn.c:361: undefined reference to `pthread_cleanup_push' /u/rse/prj/rpm/src/rpm/rpmio/yarn.c:372: undefined reference to `pthread_cleanup_pop' ../rpmio/.libs/librpmio.a(yarn.o): In function `yarnLaunch': /u/rse/prj/rpm/src/rpm/rpmio/yarn.c:406: undefined reference to `pthread_attr_init' /u/rse/prj/rpm/src/rpm/rpmio/yarn.c:406: undefined reference to `pthread_attr_setdetachstate' /u/rse/prj/rpm/src/rpm/rpmio/yarn.c:406: undefined reference to `pthread_create' /u/rse/prj/rpm/src/rpm/rpmio/yarn.c:406: undefined reference to `pthread_attr_destroy' ../rpmio/.libs/librpmio.a(yarn.o): In function `yarnJoin': /u/rse/prj/rpm/src/rpm/rpmio/yarn.c:431: undefined reference to `pthread_join' ../rpmio/.libs/librpmio.a(yarn.o): In function `yarnJoinAll': /u/rse/prj/rpm/src/rpm/rpmio/yarn.c:488: undefined reference to `pthread_join' ../rpmio/.libs/librpmio.a(yarn.o): In function `yarnDestruct': /u/rse/prj/rpm/src/rpm/rpmio/yarn.c:509: undefined reference to `pthread_cancel' collect2: ld returned 1 exit status Ralf S. Engelschall r...@engelschall.com www.engelschall.com __ RPM Package Managerhttp://rpm5.org Developer Communication Listrpm-devel@rpm5.org
RPM 5.1: two rpmVersionCompare?
On RPM 5.1 branch we now have to rpmVersionCompare: [...]eebsd6.4/xar-1.5.2/lib/.libs -Wl,-rpath -Wl,/usr/local/lib ../rpmdb/.libs/librpmdb.a(rpmevr.o): In function `rpmVersionCompare': /u/rse/prj/rpm/src/rpm.51/rpmdb/rpmevr.c:424: multiple definition of `rpmVersionCompare' ../lib/.libs/librpm.a(psm.o):/u/rse/prj/rpm/src/rpm.51/lib/psm.c:63: first defined here collect2: ld returned 1 exit status make[3]: *** [rpm2cpio] Error 1 One in lib/psm.c and one in a new rpmdb/rpmevr.c. Seems like the lib/psm.c has to be kicked out, but I'm not quite sure. Jeff, can you check 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-5_1: rpm/lib/ rpmfi.h
On Fri, Mar 06, 2009, Jeff Johnson wrote: -extern int rpmfiSetFAction(rpmfi, int) - /*...@*/; +extern int rpmfiSetFAction(rpmfi fi, int action) + /*...@modifies fi @*/; Thanks, Jeff. 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 rpm/rpmdb/ rpmevr.c
On Sat, Jan 10, 2009, Jeff Johnson wrote: [...] Since I don't wish to be supporting different and competing RPM implementations, I will proceed pushing the changes all the way back to the -r rpm-4_5 branch over the next week/month. But at least do not rush with this. Instead please let the current code on HEAD by settle for some more time. We especially should provide an 5.2 alpha for testing and before merging onto 5.1 branch we should release another 5.1.X release before. In short: RPM - PCRE just got hitched up. I hope its a happy and prolific marriage. PCRE is a good piece of code and never made any trouble for me, so it certainly will not harm RPM... Ralf S. Engelschall r...@engelschall.com www.engelschall.com __ RPM Package Managerhttp://rpm5.org Developer Communication Listrpm-devel@rpm5.org
Re: GID-0 disliked by rpm -V?
On Sun, Jan 04, 2009, Jeff Johnson wrote:
On Jan 4, 2009, at 11:07 AM, Ralf S. Engelschall wrote:
snipped, will study
So, I think we have a problem in veryfying GID-0 based files or
directories...
I suspect the problem is with wheel - 0 gid mapping, not with the
gid 0 verification per-se. Its kinda hard to screw an integer comparison
subtly (but I've managed that too on occaisions, sigh).
See if priming (as in compiling into rpm) the gname cache
in rpmio/ugid.c whith group wheel fixes:
--- rpmio/ugid.c-ORIG 2009-01-04 12:39:17.0 -0500
+++ rpmio/ugid.c 2009-01-04 12:39:56.0 -0500
@@ -72,6 +72,9 @@
} else if (strcmp(thisGname, root) == 0) {
*gid = 0;
return 0;
+} else if (strcmp(thisGname, wheel) == 0) {
+ *gid = 0;
+ return 0;
}
thisGnameLen = strlen(thisGname);
Otherwise I'll dig out the flaw.
Ok, I've applied your patch and tested even on the particular
installation (to avoid that my test case is wrong) and unfortunately the
patch has not caused any difference:
| # /usr/opkg/bin/openpkg rpm -V sasl
| ..G./usr/opkg/var/sasl/log
So, unfortunately the bug seems to be somewhere else...
Ralf S. Engelschall
r...@engelschall.com
www.engelschall.com
__
RPM Package Managerhttp://rpm5.org
Developer Communication Listrpm-devel@rpm5.org
Re: GID-0 disliked by rpm -V?
On Mon, Jan 05, 2009, Jeff Johnson wrote:
On Jan 5, 2009, at 12:43 PM, Ralf S. Engelschall wrote:
On Sun, Jan 04, 2009, Jeff Johnson wrote:
On Jan 4, 2009, at 11:07 AM, Ralf S. Engelschall wrote:
snipped, will study
So, I think we have a problem in veryfying GID-0 based files or
directories...
I suspect the problem is with wheel - 0 gid mapping, not with the
gid 0 verification per-se. Its kinda hard to screw an integer
comparison
subtly (but I've managed that too on occaisions, sigh).
See if priming (as in compiling into rpm) the gname cache
in rpmio/ugid.c whith group wheel fixes:
--- rpmio/ugid.c-ORIG 2009-01-04 12:39:17.0 -0500
+++ rpmio/ugid.c2009-01-04 12:39:56.0 -0500
@@ -72,6 +72,9 @@
} else if (strcmp(thisGname, root) == 0) {
*gid = 0;
return 0;
+} else if (strcmp(thisGname, wheel) == 0) {
+ *gid = 0;
+ return 0;
}
thisGnameLen = strlen(thisGname);
Otherwise I'll dig out the flaw.
Ok, I've applied your patch and tested even on the particular
installation (to avoid that my test case is wrong) and unfortunately
the
patch has not caused any difference:
| # /usr/opkg/bin/openpkg rpm -V sasl
| ..G./usr/opkg/var/sasl/log
So, unfortunately the bug seems to be somewhere else...
The patch I gave you will do wheel - 0 gid mappings.
There's another inverse priming (i.e. compiled in gid - gname mapping)
that may be confusing your display output:
[...]
Note that RPM needs generally to commit to a
user/group name lookup mechanism, the issue being whether
/etc/passwd (and other lookups) are inside a chroot
jail (or not). The above hackery is quite feeble.
Ah, ok, this finally _FIXED_ the problem! Now just remains the question
what the _right_ fix is. For stock RPM 5 the current Linux-specific
hard-coded root and other values are nasty, but perhaps still
acceptable. For OpenPKG's RPM 5 variant I definitely don't want anything
hard-coded assumptions about uid/gids here, of course. For OpenPKG I
really can rely on lookups via /etc/passwd and /etc/group as I don't
have to support special Linux-specific or chroot-specific bootstrap
cases, etc. So, I've applied my final patch to HEAD, which I use with
RPM 5.1.6 for now to solve this problem. Many thanks for the immediate
help, Jeff! You rock...
Ralf S. Engelschall
r...@engelschall.com
www.engelschall.com
__
RPM Package Managerhttp://rpm5.org
Developer Communication Listrpm-devel@rpm5.org
Re: Generalizing EVR comparison precedence, preliminaries
On Thu, Jan 01, 2009, Jeff Johnson wrote: On Jan 1, 2009, at 1:04 PM, Ralf S. Engelschall wrote: A little help vetting the RE's please ;-) My eyes are already tired from writing the toy script, RE's are more effective than XML at eye gouging. I propose the following three entries in macros... # STEP 1: Match the string and capture regex parts # 1 2 3 4 # X : X-X :X %evr_tuple_match ^(?:([^:-]+):)?([^:-]+)(?:-([^:-]+))?(?::([^:-] +))?$ A little more help please. I'm using POSIX extended RE's. Oh, sorry. I silemtly assumed PCRE! But ok, a non-PCRE version is also possible: we just have to replace the non-capturing parenthesis (?:..) with regular ones and then just ignore them in the selection phase: # STEP 1: Match the string and capture regex parts # 2 3 5 7 # X : X-X :X %evr_tuple_match ^(([^:-]+):)?([^:-]+)(-([^:-]+))?(:([^:-]+))?$ # STEP 2: Assemble E,V,R,D tuple from regex parts # E,V,R,D case 1: case 2: case 3: case 4: case 5: case 6: # X:X-X:X X:X-XX:X X: X-X X %evr_tuple_select 2357 237_ 23__ 2___ _23_ __5_ # STEP 3: Configure the comparison order of the E,V,R,D tuple elements %evr_tuple_order EVRD This should do the trick with regular POSIX regular expressions, too. Ralf S. Engelschall r...@engelschall.com www.engelschall.com __ RPM Package Managerhttp://rpm5.org Developer Communication Listrpm-devel@rpm5.org
Re: Generalizing EVR comparison precedence, preliminaries
On Fri, Jan 02, 2009, Jeff Johnson wrote: On Jan 2, 2009, at 8:04 AM, Jeff Johnson wrote: Hmmm, the PCRE posix emulation seems to *ahem* extend POSIX syntax slightly then. A spot check with --miredebug seems to hint at a PCRE extension to POSIX emulation, the values in the output are what I would expect if using POSIX ERE's even though the pattern is PCRE: [...@wellfleet wdj]$ rpm -Va --nofiles --miredebug -- mireRegcomp(0xb9caeea0, i386-redhat-linux-gnu) rc 0 -- mireRegcomp(0xb9d9df30, ^(?:([^:-]+):)?([^:-]+)(?:-([^:-]+))?(?:: ([^:-]+))?$) rc 0 -- mireRegexec(0xb9d9df30, 0xb9cef036[7]) rc 0 mode 2 3.0.4-1 -- mireRegexec(0xb9d9df30, 0xb9d9de60[7]) rc 0 mode 2 3.0.4-1 -- mireRegexec(0xb9d9df30, 0xb9cef03e[5]) rc 0 mode 2 4.0-1 -- mireRegexec(0xb9d9df30, 0xb9d9de94[5]) rc 0 mode 2 4.0-1 -- mireRegexec(0xb9d9df30, 0xb9ceebfb[7]) rc 0 mode 2 3.0.4-1 -- mireRegexec(0xb9d9df30, 0xb9d9de60[7]) rc 0 mode 2 3.0.4-1 -- mireRegexec(0xb9d9df30, 0xb9ceec03[5]) rc 0 mode 2 4.0-1 -- mireRegexec(0xb9d9df30, 0xb9d9de94[5]) rc 0 mode 2 4.0-1 -- mireRegexec(0xb9d9df30, 0xb9ce1201[13]) rc 0 mode 2 2.13.0-2.fc10 -- mireRegexec(0xb9d9df30, 0xb9cf028d[6]) rc 0 mode 2 2.10.3 Works is all I really care. And I do appreciate any/all assistance with RE writing. Well, the PCRE emulation of the POSIX regex API indeed is mainly about the API and not the supported patterns. Nevertheless, it means RPM then depends on the PCRE library and no longer can use a the POSIX regex API of any other regex library (as those usually provide just the standard POSIX patterns!). So, for me personally a fixed PCRE dependency is harmless, as I always build RPM 5 with PCRE in OpenPKG. But I don't know whether it is acceptable for others. OTOH, PCRE is a harmless little library and it should not really harm if RPM has a mandatory dependency to it IMHO... Ralf S. Engelschall r...@engelschall.com www.engelschall.com __ RPM Package Managerhttp://rpm5.org Developer Communication Listrpm-devel@rpm5.org
Re: Generalizing EVR comparison precedence, preliminaries
On Fri, Jan 02, 2009, Jeff Johnson wrote:
On Jan 2, 2009, at 4:46 AM, Ralf S. Engelschall wrote:
# STEP 2: Assemble E,V,R,D tuple from regex parts
# E,V,R,D case 1: case 2: case 3: case 4: case 5: case
6:
# X:X-X:X X:X-XX:X X: X-X X
%evr_tuple_select 2357 237_ 23__ 2___ _23_ __5_
This macro determines the mapping from sub-patterns to the tuple
{E,V,R,D}.
Right.
The scatter/gather operation in the mapping is necessary for more
general support than what is currently implemented, where E=1, V=2,
R=3, D=4 is assumed.
This I don't quite understand, I think. The idea is that the
%evr_tuple_select contains one or more four-character strings. Each
string's character represents one element of tuple E,V,R,D (and
in this order!). The character is either 1..9 (meaning that the
capturing parenthesis with the same number should be used to derive
the value) or _ (meaning that the corresponding element of the tuple
should be set to undefined (or NULL in C). The program has to walk
through the %evr_tuple_select strings. The first string where _not
a single_ 1...9 reference results in an empty/undefined result
(meaning the regex capturing parenthesis really matched) stops the whole
selection process.
AFAIK this scheme is fully generic. It allows an arbitrary complex regex
(to match whatever EVRD syntax we want) and still allows us to create
the E,V,R,D tuple from it. So, what more general support do you
think of, Jeff?
But perhaps an alternative syntax, using the implicit position to hide
the sub-pattern index, and having an explicit (and opaque, there's
nothing particularly holy about E, V, R, and D tokens as long
as the same characters appear in the %evr_tuple_order precedence
permutation) single character identifier for a sub-pattern match.
Here's an explicit example, permutations, like daylight savings time,
is difficult to discuss unambiguously (implicit positional example based
on 1 rather than 0 as first index):
# STEP 2: Assemble E,V,R,D tuple from regex parts
# E,V,R,D case 1: case 2: case 3: case 4: case 5: case
6:
# X:X-X:X X:X-XX:X X: X-X X
%evr_tuple_select _EV_R_D _EV___R _EV_ _E_ __VR___
__V
This I do not understand. Your %evr_tuple_select strings are 7
characters long but your tuple still seems to be just a 4-element tuple
E,V,R,D. Why? What are you trying to achieve. It is still not clear to
me.
Hmmm, case 5 _23_ might be incorrect, I would have naively expected
E in position 2. Not looked (you likely have), will check and
correct.
Ah, yes, you're right. Here is the fixed version:
# STEP 1: Match the string and capture regex parts
# 2 3 5 7
# X : X-X :X
%evr_tuple_match ^(([^:-]+):)?([^:-]+)(-([^:-]+))?(:([^:-]+))?$
# STEP 2: Assemble E,V,R,D tuple from regex parts
# E,V,R,D case 1: case 2: case 3: case 4: case 5: case 6:
# X:X-X:X X:X-XX:X X: X-X X
%evr_tuple_select 2357 235_ 23__ 2___ _35_ __5_
# STEP 3: Configure the comparison order of the E,V,R,D tuple elements
%evr_tuple_order EVRD
There's also a (possible) ambiguity in case 3 X:X or a missing case 7
candidate as X::X. yawn ...
Yes, X:X is actually E:V, the X::X for E::D (if this is wished
by you to be supported) then has to be case 7. Here it is:
# STEP 1: Match the string and capture regex parts
# 2 3 5 7
# X : X-X :X
%evr_tuple_match ^(([^:-]+):)?([^:-]+)(-([^:-]+))?(:([^:-]+))?$
# STEP 2: Assemble E,V,R,D tuple from regex parts
# E,V,R,D case 1: case 2: case 3: case 4: case 5: case 6:
case 7:
# X:X-X:X X:X-XX:X X: X-X XX::X
%evr_tuple_select 2357 235_ 23__ 2___ _35_ __5_ 2__7
# STEP 3: Configure the comparison order of the E,V,R,D tuple elements
%evr_tuple_order EVRD
This is now the non-PCRE, case-5-fixed and case-7-added version.
Please take this one now...
Ralf S. Engelschall
r...@engelschall.com
www.engelschall.com
__
RPM Package Managerhttp://rpm5.org
Developer Communication Listrpm-devel@rpm5.org
Re: Generalizing EVR comparison precedence, preliminaries
On Thu, Jan 01, 2009, Jeff Johnson wrote:
On Thu, Jan 01, 2009, Jeff Johnson wrote:
[...]
However a framework that permits extending the {E,V,R} triple as a
tuple, and permuting the precedence order of the tuple members (in
case left-to-right implicit precedence ordering is unsatisfying) is
feasible within RPM.
[...]
I fully second this approach!
For instance for OpenPKG I usually need to ignore E (as it is not
used) and compare R _before_ V -- as the R in OpenPKG follows
a strict and consistent scheme while the V is mostly arbitrary and
build/install decisions hence usually depend on R only. If something
like this permutation and filtering could be achieved via some little
macro settings this would be great ;-)
A little help vetting the RE's please ;-) My eyes are already tired
from writing the toy script, RE's are more effective than XML at eye
gouging.
I propose the following three entries in macros...
# STEP 1: Match the string and capture regex parts
# 1 2 3 4
# X : X-X :X
%evr_tuple_match ^(?:([^:-]+):)?([^:-]+)(?:-([^:-]+))?(?::([^:-]+))?$
# STEP 2: Assemble E,V,R,D tuple from regex parts
# E,V,R,D case 1: case 2: case 3: case 4: case 5: case 6:
# X:X-X:X X:X-XX:X X: X-X X
%evr_tuple_select 1234 123_ 12__ 1___ _12_ __2_
# STEP 3: Configure the comparison order of the E,V,R,D tuple elements
%evr_tuple_order EVRD
...plus the corresponding C code which takes %evr_tuple_match,
compiles it, matches it against the string, uses the %evr_tuple_select
alternatives (first one which results in no undefined captured regex
parts wins and stop the tuple selection) to create the tuple and then
%evr_tuple_order is used to configure the order on how the tuple
elements are compared.
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 rpm/build/ files.c pack.c parsePreamble.c rpm/...
On Tue, Dec 23, 2008, Per Øyvind Karlsen wrote: 2008/12/23 Ralf S. Engelschall rse+rpm-de...@rpm5.org On Tue, Dec 23, 2008, Jeff Johnson wrote: Put the under a RPM_VENDOR_FOO (or any other AutoFu enabler, default behavior is disabled). I do not see __ANY__ consensus @rpm5.org that the patch is desired, in fact quite the opposite, you have 2 negative comments on your proposal. I'm strongly opposed to the patch because I have __ALREADY__ seen Epoch: and then Arch: and Disttag: and Repotag: being added to packaging for identification purposes (I did the implementations) and no problem was usefully solved. Noone (until now, yes you are using Disttag:, but you are still only a single person) finds the functionality useful. The homily Build and they shall use. does not apply in this case there is no consensus on the intended identification. I also think the change is too intrusive and hence should be placed under RPM_VENDOR_XXX until more experience exists with it and consensus exists that it should be a default functionality. So, please place it under RPM_VENDOR_XXX... My thought behind commiting this change was that I considered it quite non-intrusive and only affecting those using it while encouraging use, discussion and improvement rather than the several different usages of RELEASE for same purpose. It also made it for me easier to maintain of course since it modifies several files, so would you be okay with the tag itself staying and only the comparision being under #ifdef RPM_VENDOR_XXX? Yes, IMHO the tag definition itself might be ok (that's Jeff's task to decide), but the tag comparison and its related code should be under RPM_VENDOR_XXX for now, please. We really have to investigate more on this stuff before it should be enabled in the main-line of RPM... Ralf S. Engelschall r...@engelschall.com www.engelschall.com __ RPM Package Managerhttp://rpm5.org Developer Communication Listrpm-devel@rpm5.org
Re: [CVS] RPM: rpm/lib/ fsm.c
On Sat, Dec 20, 2008, Per Øyvind Karlsen wrote: [...] fsm.c: In function 'fsmMapFContext': fsm.c:772: warning: unused variable 'st' This one? Yes, exactly! I get it on linux as well, but I never figured out why it complained about st being unused since it seemingly did get used two lines below, but my ignorance prolly' can't really debate much with technical details.. Could you clarify on why? :) The point is that the variable is used on the matchpathcon() function call only. But matchpathcon() is a _macro_ which is defined only for Linux's SELINUX situation. On non-Linux (or as in your case, Linux but not SELINUX-enabled platform) the matchpathcon() macro expands to nothing which in turn leads to the unused variable situation. Ralf S. Engelschall r...@engelschall.com www.engelschall.com __ RPM Package Managerhttp://rpm5.org Developer Communication Listrpm-devel@rpm5.org
Re: Two deep flaws with macro expansions
On Thu, Dec 18, 2008, Jeff Johnson wrote:
[...]
OpenPKG is using %{expand: ...}, and that is a lot closer to Doing the
Right Thing than the Mandriva patch, but both accomplish essentially
the same goal, adding one more expansion to a parameterized macro
argument.
[...]
Yes, and initially I even thought this could became horrible, because
it could be necessary at lots of places. But practice showed that it is
fully harmless. It required it in just a few places:
| $ wc -l rpmmacros
| 979 rpmmacros
| $ grep %{expand rpmmacros | wc -l
| 25
So, sure, one has to _KNOW_ that %{expand:...} has to be used, but once
known it is really OK and especially (because of no implicit extra
expansions) doesn't lead to any surprises at other macro expansion
places.
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
On Tue, Dec 16, 2008, Anders F Björklund wrote: Ralf S. Engelschall wrote: - proyvind: add support for xz for all tools shipped with rpm. - proyvind: lzdio: add support for xz format. (removes liblzma 4.999.3 support) [...] Where can this new xz stuff be found on the net? Google shows me just a few mail postings but where is the homepage of xz? The LZMA_Alone format, as known from LZMA SDK, is now lzma (.lzma) The new LZMA-with-magic format, from LZMA Utils, is now xz (.xz) So it can still be found under LZMA Utils, at http://tukaani.org/lzma/ Before, there were two different formats with the same suffix/mime-type. Oh, I see! Thank you very much for the clarification... 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
On Mon, Dec 15, 2008, Per Øyvind Karlsen wrote: - proyvind: add support for xz for all tools shipped with rpm. - proyvind: lzdio: add support for xz format. (removes liblzma 4.999.3 support) [...] Where can this new xz stuff be found on the net? Google shows me just a few mail postings but where is the homepage of xz? Ralf S. Engelschall r...@engelschall.com www.engelschall.com __ RPM Package Managerhttp://rpm5.org Developer Communication Listrpm-devel@rpm5.org
Re: [CVS] RPM: lua/local/ lposix.c rpm/ CHANGES configure.ac rpm/rpmio/ ma...
On Sun, Nov 09, 2008, Jeff Johnson wrote:
- jbj: lua: bind mkdtemp(3) in lposix.c
- jbj: macros: add %{mkdtemp:...} primitive (consistent leading
whitespace too).
[...]
Index: lua/local/lposix.c
$ cvs diff -u -r1.10 -r1.11 lposix.c
--- lua/local/lposix.c 27 Oct 2008 23:57:34 - 1.10
+++ lua/local/lposix.c 9 Nov 2008 16:12:36 - 1.11
@@ -538,6 +538,24 @@
return pushresult(L, mkdir(path, 0777), path);
}
+static int Pmkdtemp(lua_State *L) /** mkdtemp(template) */
+ /[EMAIL PROTECTED] fileSystem @*/
+ /[EMAIL PROTECTED] L, fileSystem @*/
+{
+ const char *template = luaL_checkstring(L, 1);
+ const char *path;
+ char buf[MYBUFSIZ];
+ (void) strncpy(buf, template, sizeof(buf));
+ buf[sizeof(buf)-1] = '\0';
+ if ((path = mkdtemp(buf)) == NULL)
+ return pusherror(L, template);
+ else
+ {
+ lua_pushstring(L, path);
+ return 1;
+ }
+}
+
In rpmio/macro.c you are using HAVE_MKDTEMP for portability reasons, but
here in lposix.c you are not using it. This let's lposix.c to break on
some platforms as mkdtemp(3) is a BSD/Linux thing. It for instance is
not available under Solaris...
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
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
RPM 5.1.6 released
We've today released RPM 5.1.6, another maintenance release from the stable RPM 5.1 branch. A detailed changelog you can find under http://rpm5.org/cvs/fileview?f=rpm/CHANGESv=1.2288.2. The source you can find under http://rpm5.org/files/rpm/rpm-5.1/. The RPM 5.1 series is intended to be used in production environments. Yours, Ralf S. Engelschall [EMAIL PROTECTED] www.engelschall.com __ RPM Package Managerhttp://rpm5.org Developer Communication Listrpm-devel@rpm5.org
Re: [CVS] RPM: rpm-5_1: lua/ Makefile.am
On Fri, Oct 17, 2008, Jeff Johnson wrote: - fix: enumerate files to be included with make dist. This finally has fixed the problem. I'll do some final tests on Saturday morning and then release 5.1.6 from the 5.1 branch. Please do not touch the 5.1 branch in the meantime. Ralf S. Engelschall [EMAIL PROTECTED] www.engelschall.com __ RPM Package Managerhttp://rpm5.org Developer Communication Listrpm-devel@rpm5.org
Re: [CVS] RPM: rpm-5_1: lua/ Makefile.am
On Thu, Oct 16, 2008, Jeff Johnson wrote: - jbj: add lua chkconfig/shadow modules to lua EXTRA_DIST. Summary: RevisionChanges Path 1.17.2.4+3 -1 lua/Makefile.am patch -p0 '@@ .' Index: lua/Makefile.am $ cvs diff -u -r1.17.2.3 -r1.17.2.4 Makefile.am --- lua/Makefile.am 21 Aug 2008 13:19:23 - 1.17.2.3 +++ lua/Makefile.am 16 Oct 2008 19:04:23 - 1.17.2.4 @@ -5,7 +5,9 @@ EXTRA_DIST = \ COPYRIGHT \ HISTORY \ - local/llocal.lua + local/chkconfig \ + local/llocal.lua \ + local/shadow AM_CPPFLAGS = \ -I$(top_srcdir) \ No, unfortunately not suffcient under non-Linux: $ atool -l rpm-5.1.DEVEL.tar.gz | grep shadow -rw-r--r-- rse/rse3584 2008-08-20 09:08 rpm-5.1.DEVEL/lua/local/lshadow.c -rw-r--r-- rse/rse 98 2008-08-17 20:49 rpm-5.1.DEVEL/lua/local/lshadow.h Perhaps all files have to be listed explicitly? Ralf S. Engelschall [EMAIL PROTECTED] www.engelschall.com __ RPM Package Managerhttp://rpm5.org Developer Communication Listrpm-devel@rpm5.org
Re: [CVS] RPM: rpm/rpmio/ digest.c
On Tue, Oct 14, 2008, Anders F. Björklund wrote: unbreak build when using older zlib (without combine) +#if !defined(WITH_ZLIB) || defined(HAVE_ZLIB_CRC32_COMBINE) mp-combine = (rpmuint32_t (*)(rpmuint32_t, rpmuint32_t, size_t)) crc32_combine; +#endif I do not understand the !defined(WITH_ZLIB) part here. If would have expected either... #if defined(HAVE_ZLIB_CRC32_COMBINE) ...or.. #if defined(WITH_ZLIB) defined(HAVE_ZLIB_CRC32_COMBINE) ...but not the above variant. Can you shed some light onto this, please. Thanks. Ralf S. Engelschall [EMAIL PROTECTED] www.engelschall.com __ RPM Package Managerhttp://rpm5.org Developer Communication Listrpm-devel@rpm5.org
RPM 5.1 now freezed for release
Please let us freeze the RPM 5.1 branch now (no more commits please until I tell you that the branch is open again for hacking), so that I can do the final test-driving for 5.1 and then release RPM 5.1.5. Ralf S. Engelschall [EMAIL PROTECTED] www.engelschall.com __ RPM Package Managerhttp://rpm5.org Developer Communication Listrpm-devel@rpm5.org
Re: [CVS] RPM: rpm-5_1: rpm/ CHANGES rpm/lib/ fsm.c librpm.vers rpminstall...
On Mon, Oct 06, 2008, Jeff Johnson wrote: This was the last fix stopping rpm-5.1.5 release afaik. Cool. I'll try to release 5.1.5 at the weekend -- once I was able to first perform my usual amount of portability and run-time tests. I'll drop a note once I'll start with the testing. Until this time feel free to still commit more fixes to the 5.1 branch... Ralf S. Engelschall [EMAIL PROTECTED] www.engelschall.com __ RPM Package Managerhttp://rpm5.org Developer Communication Listrpm-devel@rpm5.org
Re: [CVS] RPM: rpm-5_1: rpm/ CHANGES rpm/rpmio/ lzdio.c
On Sat, Oct 04, 2008, Per Øyvind Karlsen wrote: [...] +lzma_stream tmp = +#if LZMA_VERSION == 49990030 + LZMA_STREAM_INIT_VAR; +#else + LZMA_STREAM_INIT; +#endif What happens on the next versions? Wouldn't be a LZMA_VERSION = 49990030 better here? Ralf S. Engelschall [EMAIL PROTECTED] www.engelschall.com __ RPM Package Managerhttp://rpm5.org Developer Communication Listrpm-devel@rpm5.org
HEAD broken after reject NVRA changes
When trying to build HEAD with Lua enabled, these days I get: libtool: compile: gcc -DHAVE_CONFIG_H -I. -I.. -I. -I.. -I../build -I../lib -I../lib -I../rpmdb -I../rpmio -I../misc -DRPM_OS_FREEBSD=060300 -I/d2/u/rse/prj/rpm/src/3rd/bin/ix86-freebsd6.3/popt-1.14 -I/d2/u/rse/prj/rpm/src/3rd/bin/ix86-freebsd6.3/zlib-1.2.3 -I/d2/u/rse/prj/rpm/src/3rd/bin/ix86-freebsd6.3/bzip2-1.0.5 -I/d2/u/rse/prj/rpm/src/3rd/bin/ix86-freebsd6.3/lzma-4.999.3alpha -I/d2/u/rse/prj/rpm/src/3rd/bin/ix86-freebsd6.3/beecrypt-4.1.2 -I/d2/u/rse/prj/rpm/src/3rd/bin/ix86-freebsd6.3/openssl-0.9.8i/include -I/d2/u/rse/prj/rpm/src/3rd/bin/ix86-freebsd6.3/neon-0.28.1/src -I/d2/u/rse/prj/rpm/src/3rd/bin/ix86-freebsd6.3/file-4.26/src -I/d2/u/rse/prj/rpm/src/3rd/bin/ix86-freebsd6.3/db-4.7.25/build_unix -I/d2/u/rse/prj/rpm/src/3rd/bin/ix86-freebsd6.3/sqlite-3.6.3 -I/d2/u/rse/prj/rpm/src/3rd/bin/ix86-freebsd6.3/lua-5.1.4/src -I/d2/u/rse/prj/rpm/src/3rd/bin/ix86-freebsd6.3/pcre-7.8 -I/d2/u/rse/prj/rpm/src/3rd/bin/ix86-freebsd6.3/uuid-1.6.2 -I/d2/u/rse/prj/rpm/src/3rd/bin/ix86-freebsd6.3/xar-1.5.2/include -Wall -W -Wpointer-arith -Wstrict-prototypes -Wmissing-prototypes -Wno-char-subscripts -Wno-missing-field-initializers -Wno-unused-parameter -O0 -g3 -D_GNU_SOURCE -D_REENTRANT -MT psm.lo -MD -MP -MF .deps/psm.Tpo -c psm.c -o psm.o psm.c: In function 'runLuaScript': psm.c:492: error: 'struct rpmpsm_s' has no member named 'NVRA' psm.c: In function 'runScript': psm.c:626: error: 'struct rpmpsm_s' has no member named 'NVRA' psm.c:627: error: 'struct rpmpsm_s' has no member named 'IPhe' psm.c:662: error: 'struct rpmpsm_s' has no member named 'NVRA' psm.c: In function 'rpmpsmFree': psm.c:1499: error: 'struct rpmpsm_s' has no member named 'IPhe' psm.c:1499: error: 'struct rpmpsm_s' has no member named 'IPhe' psm.c:1500: error: 'struct rpmpsm_s' has no member named 'IPhe' psm.c:1500: error: 'struct rpmpsm_s' has no member named 'IPhe' psm.c:1501: error: 'struct rpmpsm_s' has no member named 'NVRA' psm.c:1501: error: 'struct rpmpsm_s' has no member named 'NVRA' psm.c: In function 'rpmpsmNew': psm.c:1531: error: 'struct rpmpsm_s' has no member named 'NVRA' psm.c:1532: error: 'struct rpmpsm_s' has no member named 'IPhe' psm.c:1532: error: 'struct rpmpsm_s' has no member named 'IPhe' make[4]: *** [psm.lo] Error 1 I've currently no time to digg myself, but I guess this is related to some refactorings which happended recently and the WITH_LUA wrapped code was just overlooked. Ralf S. Engelschall [EMAIL PROTECTED] www.engelschall.com __ RPM Package Managerhttp://rpm5.org Developer Communication Listrpm-devel@rpm5.org
Re: Support of non-Linux/*BSD platforms?
On Wed, Sep 10, 2008, Frank Fegert wrote: Thanks to everyones work on rpm5 the built went much better compared to my last attempt with 4.4.7. Only rpmmtree seems a bit too Linux/*BSD-ish with its strtouq, asprintf and st_mtimespec usage. Yes, rpmmtree originally comes from BSD's mtree program and hence contains lots of BSD stuff. But keep in mind that for the regular RPM operation you don't need rpmmtree anyway... Luckily CVS already had some fixes. This brought up the question if the rpm5 development is now only targeted towards Linux/*BSD-ish platforms, or if its just that no non-Linux/*BSD build problems have been reported? IOW, are there plans on dropping other platforms? (No offense intended!) Well, RPM historically is rooted in the Linux camp, of course. And RPM 4 was only partially portable to non-Linux platforms. At least for OpenPKG in the past I had to patch RPM 4 to a larger extend to get it running on all major platforms (including AIX). All(!) of OpenPKG's portability changes are now incorporated into the RPM 5 code base and hence RPM 5 should build out-of-the-box on mostly all major Unix platforms. The rpmmtree is an exception because this piece of code came into RPM 5 just recently and _after_ the last full portability checks were performed by me for RPM 5. But this one should be really a major exception. As of RPM 5.0.0 and 5.1.0 the code base really was building and working fine on all major Unix platforms. And I do not plan to give up on this goal -- at least that's one of my major personal objectives here in the RPM5 project ;-) So you can expect that RPM5 in the long-term really will works across all major Unix platforms... Ralf S. Engelschall [EMAIL PROTECTED] www.engelschall.com __ RPM Package Managerhttp://rpm5.org Developer Communication Listrpm-devel@rpm5.org
Re: [CVS] RPM: rpm-5_1: rpm/ CHANGES rpm/lib/ psm.c
On Sun, Sep 07, 2008, Jeff Johnson wrote: WIth this change, the wrs.useradd lua module is now functional. Which means the the rather large patch integration is complete imho. Shall we attempt to release rpm-5.1.5? There's several additional fixes that are needed, but I should be able to get to the fixing shortly. If you kick in the additional fixes within the next week, I will take care of testing and releasing RPM 5.1.5 next weekend. Ralf S. Engelschall [EMAIL PROTECTED] www.engelschall.com __ RPM Package Managerhttp://rpm5.org Developer Communication Listrpm-devel@rpm5.org
Re: RPM_CHECK_LIB: Adding .../lib64/... searches
On Tue, Aug 19, 2008, Jeff Johnson wrote: On Aug 19, 2008, at 1:37 PM, Jeff Johnson wrote: $ CPPFLAGS=-I/path/to/foo/include \ LDFLAGS=-L/path/to/foo/lib64 \ ./configure --with-foo=external This way the libfoo.* should be happily picked up from /path/to/foo/lib64, too. Let me whack at this approach some. Thanks. This approach will mostly work. However, I will need to fix libtool within python/Makefile.am somewhat, there's an issue with libdir != -rpath path using libtool to install using current conventions for WITH_PYTHON_LIBDIR search and value passed. Which leads me to the discovery of AM_PATH_PYTHON as used by rpm.org. Any objections to attempting AM_PATH_PYTHON on HEAD? I've never used AM_PATH_PYTHON but if it is better than the historical stuff we have in configure.ac, just use AM_PATH_PYTHON, of course. Ralf S. Engelschall [EMAIL PROTECTED] www.engelschall.com __ RPM Package Managerhttp://rpm5.org Developer Communication Listrpm-devel@rpm5.org
Re: [CVS] RPM: lua/ Makefile.am lua/shadow/ commonio.c config.h copydir.c ...
On Mon, Aug 18, 2008, Jeff Johnson wrote:
On Aug 18, 2008, at 2:27 PM, Ralf S. Engelschall wrote:
On Mon, Aug 18, 2008, Jeff Johnson wrote:
I'm gonna try to merge out the dueling AutoFu in the lua/shadow code.
I should have most of the merge comp;leted, and onto the rpm-5_1
branch,
in next 48 hours (likely sooner).
Sound like a plan?
As rpm-5_1 is currently broken on non-Linux platforms anway, you can
even merge immediately, of course. The branch state should only become
better ;-)
OK, lua/{chconfig,shadow} backport should be gud enuf to build
rpm-5.1.4+ afaict. If not, holler at me and I'll fix whatever.
There is still an issue left:
../misc/.libs/librpmmisc.a(liblua_la-lwrs.o): In function `wrs_groupadd':
/u/rse/prj/rpm/src/rpm.51/lua/local/lwrs.c:68: undefined reference to
`useradd_main'
../misc/.libs/librpmmisc.a(liblua_la-lwrs.o): In function `wrs_useradd':
/u/rse/prj/rpm/src/rpm.51/lua/local/lwrs.c:91: undefined reference to
`useradd_main'
../misc/.libs/librpmmisc.a(liblua_la-lwrs.o): In function `wrs_chkconfig':
/u/rse/prj/rpm/src/rpm.51/lua/local/lwrs.c:114: undefined reference to
`chkconfig_main'
Ralf S. Engelschall
[EMAIL PROTECTED]
www.engelschall.com
__
RPM Package Managerhttp://rpm5.org
Developer Communication Listrpm-devel@rpm5.org
Re: RPM_CHECK_LIB: Adding .../lib64/... searches
On Tue, Aug 19, 2008, Jeff Johnson wrote: I have this linux multilib peculier patch below to integrate (or leave as per-vendor private). Ralf: What say ye? Integrate or leave as private per-vendor patch? Hmmm... although I understand the wish for automatic and out-of-the-box testing for more than just lib, in practice there can be lib, lib32 and lib64 and whatever else even more obscure directories. And which one we have to pick up actually depends on the used compiler flags which in turn select the used ABI. So, if we here just also check for lib64, this solves the problem of this particular vendor, but for others this could be just plain wrong -- as their _compiler_ uses lib64 only if the 64-bit ABI was explicitly selected. So, if we would attempt a _REAL_ solution we would have to actually _COMPILE_ and _LINK_ a test program against all of lib, lib32 and lib64 and choose the one which actually _WORKS_. And even in this case if someone has a lib42 ;-) we would reach game over again. That's why I intentionally checked for just the single _CANONICAL_ lib and instead have explicitly implemented for our RPM_CHECK_LIB macro the support for _implicitly_ locating a library through the supplied built-time flags (see acinclude.m4 lines 285-299). So, instead of using... $ ./configure --with-foo=/path/to/foo ...and relying on RPM_CHECK_LIB to know about all possible good and bad libXX subdirs (which too easily can go wrong), one just can use the fully equivalent, more flexible and especially more precise... $ CPPFLAGS=-I/path/to/foo/include \ LDFLAGS=-L/path/to/foo/lib64 \ ./configure --with-foo=external This way the libfoo.* should be happily picked up from /path/to/foo/lib64, too. I guess, either the vendor who supplied this lib64 patch overlooked the fact that this approach is possible and equivalent or our support for this approach in RPM_CHECK_LIB is broken for him (and we then should fix this, of course). But I recommend to _not_ simply add lib64 to the list of directories to check... Ralf S. Engelschall [EMAIL PROTECTED] www.engelschall.com __ RPM Package Managerhttp://rpm5.org Developer Communication Listrpm-devel@rpm5.org
strange RPMDB problem: messed up entries (regularily)
Now that it happended to me multiple times and subsequently, I think it might be more a real bug than just an unusual accident. The symptom is the following: I've dozen of OpenPKG/RPM5 (RPM 5.1.4) based software stacks on production machines. They all work just fine and I'm very happy about RPM 5.1.4 as it works perfectly with all over 1200 OpenPKG RPM packages during intallation, upgrading, etc. But after some time (between a few days and 1-3 weeks as it looks) the following can be seen in multiple OpenPKG instances (not all which exist on the same machine, but usually at least on more than one on the same machine in parallel): | # /usr/opkg/bin/openpkg rpm -qa | make-3.81-20080101 | m4-1.4.11-20080403 | binutils-2.18-20080101 | grep-2.5.3-20080101 | autoconf-2.62-20080409 | automake-1.10-20080101 | libiconv-1.12-20080101 | gettext-0.17-20080101 | less-418-20080103 | perl-openpkg-5.10.0-20080409 | procmail-3.22-20080101 | pkgconfig-0.23-20080117 | flex-2.5.35-20080227 | flowtools-0.68-20080101 | perl-stats-5.10.0-20080101 | libart-2.3.20-20080130 | fsl-1.7.0-20080101 | perl-term-5.10.0-20080208 | bzip2-1.0.5-20080318 | zlib-1.2.3-20080101 | diffutils-2.8.7-20080101 | w3m-0.5.2-20080101 | screen-4.0.3-20080101 | sed-4.1.5-20080101 | flow2rrd-0.9.1-20080101 | cfg-0.9.11-20080101 | gc-6.8-20080101 | expat-2.0.1-20080101 | gzip-1.3.12-20080101 | pcre-7.7-20080508 | lzo-2.03-20080430 | bash-3.2.39-20080502 | texinfo-4.12-20080421 | readline-5.2.12-20080502 | png-1.2.29-20080508 | lsof-4.80-20080518 | gcc-4.2.4-20080521 | openssl-0.9.8h-20080528 | rrdtool-1.2.27-20080521 | lftp-3.7.3-20080524 | error: rpmdb: skipping h# 42 blob size(4140): BAD, 8 + 16 * il(959996723) + dl(825374516) | error: db4 error(-30986) from dbcursor-get: DB_PAGE_NOTFOUND: Requested page not found Notice the error at the end. I can easily recover from this problem by just running openpkg rpm --rebuilddb. This then once again shows the same error but at least results in no more errors during the next openpkg rpm -qa. BUT! The problem then is still not gone: openpkg rpm -qi openpkg then shows: | # /usr/opkg/bin/openpkg rpm -qi openpkg | package openpkg is not installed Woohooo... openpkg is our RPM root package and usually never can be missing (or the instance would be gone as it removes all artefacts of an OpenPKG instance with it during package erasure). It is really gone from the database only. Ok, I can also recover from this problem by running openpkg rpm -Uvh --justdb openpkg*.rpm. Then everything is just fine again. But this now occurred about the 5th time now for me and it is always exactly the same symptom. I do not understand why entries (here the openpkg packae) get garbled in the RPMDB from time to time -- even without any administrative RPM actions in between (no write to the RPMDB from commands like openpkg rpm -i, etc). There are just openpkg rpm -q openpkg commands running regularily via crond(8) on all OpenPKG instances. How can those mess up the database? Hmmm... any clues? Can I do anything reasonably here next time this occurs? Perhaps preserve and share the garbled RPMDB for manual inspection? Ralf S. Engelschall [EMAIL PROTECTED] www.engelschall.com __ RPM Package Managerhttp://rpm5.org Developer Communication Listrpm-devel@rpm5.org
Re: [CVS] RPM: rpm-5_1: lua/ Makefile.am lua/chkconfig/ chkconfig.c leveld...
On Sun, Aug 17, 2008, Jeff Johnson wrote: [...] Added files: (Branch: rpm-5_1) lua/chkconfig chkconfig.c leveldb.c leveldb.h lua/local lshadow.c lshadow.h lwrs.c lwrs.h lua/shadow chkname.h commonio.c commonio.h config.h copydir.c defines.h faillog.h fputsx.c getdate.c getdate.h getdef.c getdef.h groupadd.c groupio.c groupio.h gshadow.c gshadow_.h list.c nscd.h prototypes.h pwauth.h pwio.c pwio.h sgetgrent.c sgetpwent.c sgroupio.c sgroupio.h shadowio.c shadowio.h strtoday.c useradd.c xmalloc.c Modified files: (Branch: rpm-5_1) lua Makefile.am rpm CHANGES rpm/rpmio rpmlua.c Log: - WR: add shadow/chkconfig internal lua modules. [...] Hmmm.. why such a hurry in the merging of really *non-trivial* changes from HEAD? IMHO only trivial changes can be immediately merged from HEAD to a branch. Everything else should be first tested in HEAD. At least for proper building in the major platforms. And, especially, changes which already from their topic clearly indicate portability trouble like any Linux-specific chkconfig and shadow stuff. As a result, RPM 5.1 branch today not even compiles under non-Linux (here FreeBSD): | libtool: compile: gcc -DHAVE_CONFIG_H -I. -I.. -I.. -I./local -I./local -I./chkconfig -I./chkconfig -I./shadow -I./shadow -I. -DRPM_VENDOR_OPENPKG -DRPM_INTEGRITY_FP=\7971E0F1F694CABDF8EAEF534F64D9D856BE2BA6\ -DRPM_INTEGRITY_MV=\0.9.0\ -DRPM_OS_FREEBSD=060300 -I/d2/u/rse/prj/rpm/src/3rd/bin/ix86-freebsd6.3/popt-1.14 -I/d2/u/rse/prj/rpm/src/3rd/bin/ix86-freebsd6.3/zlib-1.2.3 -I/d2/u/rse/prj/rpm/src/3rd/bin/ix86-freebsd6.3/bzip2-1.0.5 -I/d2/u/rse/prj/rpm/src/3rd/bin/ix86-freebsd6.3/lzma-4.999.3alpha -I/d2/u/rse/prj/rpm/src/3rd/bin/ix86-freebsd6.3/beecrypt-4.1.2 -I/d2/u/rse/prj/rpm/src/3rd/bin/ix86-freebsd6.3/openssl-0.9.8g/include -I/d2/u/rse/prj/rpm/src/3rd/bin/ix86-freebsd6.3/neon-0.28.1/src -I/d2/u/rse/prj/rpm/src/3rd/bin/ix86-freebsd6.3/file-4.24/src -I/d2/u/rse/prj/rpm/src/3rd/bin/ix86-freebsd6.3/db-4.7.25/build_unix -I/d2/u/rse/prj/rpm/src/3rd/bin/ix86-freebsd6.3/sqlite-3.5.9 -I/d2/u/rse/prj/rpm/src/3rd/bin/ix86-freebsd6.3/pcre-7.7 -I/d2/u/rse/prj/rpm/src/3rd/bin/ix86-freebsd6.3/uuid-1.6.1 -I/d2/u/rse/prj/rpm/src/3rd/bin/ix86-freebsd6.3/xar-1.5.2/include -DLUA_USE_DLOPEN -DLUA_USE_POSIX -DLUA_USE_PCRE -DLUA_USE_UUID -DLUA_USE_POSIX -Wall -W -Wpointer-arith -Wstrict-prototypes -Wmissing-prototypes -Wno-char-subscripts -Wno-missing-field-initializers -Wno-unused-parameter -O0 -g3 -D_GNU_SOURCE -D_REENTRANT -MT liblua_la-commonio.lo -MD -MP -MF .deps/liblua_la-commonio.Tpo -c shadow/commonio.c -o liblua_la-commonio.o | In file included from shadow/commonio.c:12: | shadow/defines.h:25:22: error: libintl.h: No such file or directory | shadow/defines.h:113:20: error: shadow.h: No such file or directory | shadow/commonio.c: In function 'commonio_lock': | shadow/commonio.c:295: warning: implicit declaration of function 'lckpwdf' | shadow/commonio.c:302: warning: implicit declaration of function 'ulckpwdf' | make[1]: *** [liblua_la-commonio.lo] Error 1 | make[1]: Leaving directory `/d2/u/rse/prj/rpm/src/rpm.51/lua' | make: *** [install-recursive] Error 1 I think both the chkconfig and shadow stuff has to be wrapped with proper Autoconf glue and be disabled by default. On Linux it can be enabled manually... Ralf S. Engelschall [EMAIL PROTECTED] www.engelschall.com __ RPM Package Managerhttp://rpm5.org Developer Communication Listrpm-devel@rpm5.org
Re: strange RPMDB problem: messed up entries (regularily)
On Mon, Aug 18, 2008, Ralf S. Engelschall wrote: [...] | error: rpmdb: skipping h# 42 blob size(4140): BAD, 8 + 16 * il(959996723) + dl(825374516) | error: db4 error(-30986) from dbcursor-get: DB_PAGE_NOTFOUND: Requested page not found Notice the error at the end. I can easily recover from this problem by just running openpkg rpm --rebuilddb. This then once again shows the same error but at least results in no more errors during the next openpkg rpm -qa. BUT! The problem then is still not gone: openpkg rpm -qi openpkg then shows: | # /usr/opkg/bin/openpkg rpm -qi openpkg | package openpkg is not installed It now happened just again on a different instance. Interesting aspect I found out this time: | # /v/en/sw/bin/openpkg rpm -qa | [...] | error: rpmdb: skipping h# 30 blob size(3940): BAD, 8 + 16 * il(75) + dl(2952) | error: rpmdb: skipping h# 37 blob size(4768): BAD, 8 + 16 * il(81) + dl(9152) | error: rpmdb: skipping h# 39 blob size(122300): BAD, 8 + 16 * il(825308978) + dl(929380405) | error: rpmdb: skipping h# 40 blob size(4164): BAD, 8 + 16 * il(825374516) + dl(1647719268) | error: db4 error(-30986) from dbcursor-get: DB_PAGE_NOTFOUND: Requested page not found | en# /v/en/sw/bin/openpkg rpm --db-rebuild | rpmdb: REBUILDING NEW FROM OLD RPM DATABASE (/v/en/sw/RPM/DB) | rpmdb: cleaning up RPM database DB files | rpmdb: making sure RPM database are of the correct type | rpmdb: dumping and reloading RPM database DB file contents | rpmdb: rebuilding RPM database (built-in RPM procedure) | rpmdb: making sure RPM database files have consistent attributes | rpmdb: performing read/write operation on RPM database | # /v/en/sw/bin/openpkg rpm -qa | make-3.81-20080101 | m4-1.4.11-20080403 | binutils-2.18-20080101 | grep-2.5.3-20080101 | [...] | # /v/en/sw/bin/openpkg rpm -q openpkg | openpkg-4.0b5-20080726 Notice the --db-rebuild instead of --rebuildb here and the fact that with --rebuilddb I usually loose the openpkg entry while with --db-rebuild I do not. To explain: --db- are RPM aliases to OpenPKG's rpmdb addon script and its --db-rebuild actually does a full dump and restore with the Berkeley-DB tool (for details see the attached script) while --rebuildb is RPM-internal. Very interesting that the full dump/restore via external tools is able to resurrect the database without information loss while RPM's --rebuilddb seems to kick away data. Hmm... Ralf S. Engelschall [EMAIL PROTECTED] www.engelschall.com ## ## rpmdb -- OpenPKG RPM Database Administration Utility ## Copyright (c) 2000-2008 OpenPKG GmbH http://openpkg.com/ ## ## This software is property of the OpenPKG GmbH, DE MUC HRB 160208. ## All rights reserved. Licenses which grant limited permission to use, ## copy, modify and distribute this software are available from the ## OpenPKG GmbH. ## ## THIS SOFTWARE IS PROVIDED AS IS AND ANY EXPRESSED OR IMPLIED ## WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE IMPLIED WARRANTIES OF ## MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE ARE DISCLAIMED. ## IN NO EVENT SHALL THE AUTHORS AND COPYRIGHT HOLDERS AND THEIR ## CONTRIBUTORS BE LIABLE FOR ANY DIRECT, INDIRECT, INCIDENTAL, ## SPECIAL, EXEMPLARY, OR CONSEQUENTIAL DAMAGES (INCLUDING, BUT NOT ## LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS OR SERVICES; LOSS OF ## USE, DATA, OR PROFITS; OR BUSINESS INTERRUPTION) HOWEVER CAUSED AND ## ON ANY THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT LIABILITY, ## OR TORT (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY OUT ## OF THE USE OF THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF ## SUCH DAMAGE. ## # program information progname=rpmdb # configuration defaults help= prefix=/usr/opkg dbpath= dbapi= tmpdir= rpm= musr=opkg mgrp=opkg mode= force=no verbose=2 ## ## PARSE COMMAND LINE ## # iterate over argument line args= for opt do case $opt in -*=*) arg=`echo $opt | sed 's/^[-_a-zA-Z0-9]*=//'` ;; *) arg='' ;; esac case $opt in -h|--help ) help=Usage ;; -B|--build ) mode=build;; -M|--migrate ) mode=migrate ;; -R|--rebuild ) mode=rebuild ;; -C|--cleanup ) mode=cleanup ;; -F|--fixate) mode=fixate ;; -L|--list ) mode=list ;; -f|--force ) force=yes ;; -q|--quiet ) verbose=0 ;; -v|--verbose ) verbose=`expr $verbose + 1` ;; --prefix=* ) prefix=$arg ;; --dbpath=* ) dbpath=$arg ;; --dblib=* ) dblib=$arg;; --tmpdir=* ) tmpdir=$arg ;; --rpm=*) rpm=$arg ;; --musr=* ) musr=$arg ;; --mgrp=* ) mgrp=$arg ;; -- ) ;; -* ) help=Invalid option \`$opt'; break ;; * ) args=$args \$opt
Re: [CVS] RPM: lua/ Makefile.am lua/shadow/ commonio.c config.h copydir.c ...
On Mon, Aug 18, 2008, Jeff Johnson wrote: I'm gonna try to merge out the dueling AutoFu in the lua/shadow code. I should have most of the merge comp;leted, and onto the rpm-5_1 branch, in next 48 hours (likely sooner). Sound like a plan? As rpm-5_1 is currently broken on non-Linux platforms anway, you can even merge immediately, of course. The branch state should only become better ;-) Ralf S. Engelschall [EMAIL PROTECTED] www.engelschall.com __ RPM Package Managerhttp://rpm5.org Developer Communication Listrpm-devel@rpm5.org
Re: - jbj: replace stdint.h with private typedefs.
On Thu, Aug 07, 2008, Alexey Tourbin wrote: On Thu, Aug 07, 2008 at 08:40:26PM +0200, Ralf S. Engelschall wrote: On Thu, Aug 07, 2008, Alexey Tourbin wrote: [...] - jbj: replace stdint.h with private typedefs. Why private typedefs are any better? For instance because the private ones are available everywhere while the stdint.h ones require at least a C99 environment which in turn unnecessarily increases the entry barrier for a bootstrapping tool like RPM when it comes to non-Linux platforms. Arguably a better approach is to define uint32_t etc. on systems that miss them instead of introducing rpmuint32_t. Can be done when building RPM itself, but is a larger problem for the RPM header files when built outside the RPM source tree (where RPM's own Autoconf results are not available). Sure, can be also solved by in-place providing the Autoconf results directly in the headers, but Jeff decided to go the way of own typedefs and I personally see no major drawback there. It at least avoids all the trouble related to building RPM headers outside the RPM source tree rather easily. My $EDITOR can highlight uint32_t but knows nothing about rpmuint32_t. As a developer, I'm disappointed about reading the code made harder. Ah, ok, your $EDITOR seems to be at least not Vim, because in my $EDITOR everything matching /[a-zA-Z_][a-zA-Z_0-9]*_t/ seems to be correctly syntax highlighted as a type symbol (either by default or I configured it somewhere to to this and just forgot). But your $EDITOR certainly also can be told to recognize rpmuint32_t, can't it? Ralf S. Engelschall [EMAIL PROTECTED] www.engelschall.com __ RPM Package Managerhttp://rpm5.org Developer Communication Listrpm-devel@rpm5.org
