--specfile --specedit pacth [Was: Re: error: ‘struct FDIO_s’ has no member named ‘_open’]
On Sunday 02 January 2011 18:42:23 Jeff Johnson wrote:
Your patch NEEDS --specedit.
Can you describe the usage case so I can figure out a replacement?
Sorry for the late reply, to get a preprocessed specfile output we just use:
rpm -q --specfile --specedit gcc.spec
Where --specedit could be replaced by a more correct option name like, --
specdump or --preparse, --preprocess or anything that sounds better...
(aside)
The --specedit option was added to rip i18n out of *.spec 10 years ago
and hasn't had any usage case till now.
Yes, I recall that it was printing multiple times the whole specfile for each
language defined with e.g. using Summary(it), that's why, I think, I avoided
using printNewSpecfile. We never used it in that way as well.
--- rpm-4.4.9.orig//build/parseSpec.c 2010-08-03 15:57:18.740342061 +0200
+++ rpm-4.4.9/build/parseSpec.c 2010-08-03 15:58:02.071216551 +0200
@@ -402,6 +402,12 @@
if (! spec-readStack-reading) {
spec-line[0] = '\0';
+} else {
+if (specedit) {
+ printf(%s,spec-line);
+ if (strchr(spec-line, '\n') == NULL spec-line[strlen(spec-
line)-1] != '\n')
+ printf(\n);
+ }
}
/*@-compmempass@*/ /* FIX: spec-readStack-next should be dependent */
--- rpm-4.4.9.orig//build/spec.c2010-08-03 15:57:20.203092007 +0200
+++ rpm-4.4.9/build/spec.c 2010-08-03 15:56:45.128341759 +0200
@@ -724,7 +724,7 @@
res = 0;
if (specedit) {
- printNewSpecfile(spec);
+// printNewSpecfile(spec);
goto exit;
}
Silvan
--
mambaSoft di Calarco Silvan
Web: http://www.mambasoft.it
mambaSoft Store @ http://www.mambastore.it
openmamba GNU/Linux development @ http://www.openmamba.org
__
RPM Package Managerhttp://rpm5.org
Developer Communication Listrpm-devel@rpm5.org
Re: error: ‘struct FDIO_s’ has no member named ‘_open’
On Thursday 30 December 2010 16:58:43 Jeff Johnson wrote:
Two asides:
1) I have the start of a functionally equivalent replacement for
genpkglist/gensrcpkglist written in C. I can finish writing those
two tools (in C using POPT) with c couple of days of work if there's
interest. My interest at the time was studying what Debian uses
for repository markup as well as fro POPT development (I also maintain
POPT).
I have a plan to include genpkglist/gensrcpkglist in the openmamba tool
distromatic because it would be natural as it is done to generate all
repository output files needed. It has already all repository data structures
in memory, so just the output code needs to be ported.
BTW with the attached patch I workarounded the build and segfault with apt-
repo-tools. The segfault was around some LUA code in the rpmReadConfigFiles()
call, which by evidence I don't need.
2) RPM has something called queryformat templates in /usr/lib/rpm/qf/*
that can be used to generate markup based on package metadata.
Interesting.
I don't know if a template could be used to do this, but we have patched rpm
(patch attached), to have a function that produces a preprocessed specfile:
rpm -q --specedit --specfile gcc.spec --define=inputvar inputvalue
This is not a good upstream patch, it changes the meaning of an existing
undocumented option, but we did it to quickly fix our automatic update
processes which where weak in specfile variable resolution. Maybe this can be
done in other ways or this might just be a feature request :) (BTW we are
currently fine with our patch).
Silvan
--
mambaSoft di Calarco Silvan
Web: http://www.mambasoft.it
mambaSoft Store @ http://www.mambastore.it
openmamba GNU/Linux development @ http://www.openmamba.org
diff -ru apt-repo-tools-0.6.0.12/configure.ac apt-repo-tools-0.6.0.12.orig//configure.ac
--- apt-repo-tools-0.6.0.12/configure.ac 2010-12-23 01:56:37.0 +0100
+++ apt-repo-tools-0.6.0.12.orig//configure.ac 2010-12-30 15:26:36.964134888 +0100
@@ -6,7 +6,7 @@
AC_PROG_LIBTOOL
AC_MSG_CHECKING(for RPM version)
-RPM_VERSION_RAW=`LANG=C LC_ALL=C rpm --version | sed 's/^RPM version //'`
+RPM_VERSION_RAW=`LANG=C LC_ALL=C rpm --version | sed 's/^.* //'`
RPM_VERSION_MAJOR=`echo $RPM_VERSION_RAW | cut -d. -f1`
RPM_VERSION_MINOR=`echo $RPM_VERSION_RAW | cut -d. -f2`
RPM_VERSION_MICRO=`echo $RPM_VERSION_RAW | cut -d. -f3`
diff -ru apt-repo-tools-0.6.0.12/rapt-compat.h apt-repo-tools-0.6.0.12.patched//rapt-compat.h
--- apt-repo-tools-0.6.0.12/rapt-compat.h 2010-12-23 01:56:37.0 +0100
+++ apt-repo-tools-0.6.0.12.patched//rapt-compat.h 2010-12-30 15:43:33.381675277 +0100
@@ -1,7 +1,7 @@
-typedef int raptInt;
-typedef int raptTag;
-typedef int raptTagType;
-typedef int raptTagCount;
+typedef int_32 raptInt;
+typedef int_32 raptTag;
+typedef int_32 raptTagType;
+typedef int_32 raptTagCount;
typedef void * raptTagData;
diff -Nru apt-repo-tools-0.6.0.12.orig//genutil.h apt-repo-tools-0.6.0.12/genutil.h
--- apt-repo-tools-0.6.0.12.orig//genutil.h 2010-12-31 02:26:03.769077340 +0100
+++ apt-repo-tools-0.6.0.12/genutil.h 2010-12-31 02:26:21.074237381 +0100
@@ -59,7 +59,6 @@
#if RPM_VERSION = 0x040100
static rpmts ts = NULL;
if (ts == NULL) {
- rpmReadConfigFiles(NULL, NULL);
ts = rpmtsCreate();
assert(ts);
rpmtsSetVSFlags(ts, (rpmVSFlags_e)-1);
diff -ru rpm-4.4.9.orig//build/parseSpec.c rpm-4.4.9/build/parseSpec.c
--- rpm-4.4.9.orig//build/parseSpec.c 2010-08-03 15:57:18.740342061 +0200
+++ rpm-4.4.9/build/parseSpec.c 2010-08-03 15:58:02.071216551 +0200
@@ -402,6 +402,12 @@
if (! spec-readStack-reading) {
spec-line[0] = '\0';
+} else {
+if (specedit) {
+ printf(%s,spec-line);
+ if (strchr(spec-line, '\n') == NULL spec-line[strlen(spec-line)-1] != '\n')
+ printf(\n);
+ }
}
/*...@-compmempass@*/ /* FIX: spec-readStack-next should be dependent */
--- rpm-4.4.9.orig//build/spec.c 2010-08-03 15:57:20.203092007 +0200
+++ rpm-4.4.9/build/spec.c 2010-08-03 15:56:45.128341759 +0200
@@ -724,7 +724,7 @@
res = 0;
if (specedit) {
- printNewSpecfile(spec);
+// printNewSpecfile(spec);
goto exit;
}
--- rpm-4.4.9.orig/build/parsePreamble.c 2007-05-15 02:39:25.0 +0200
+++ rpm-4.4.9/build/parsePreamble.c 2010-08-03 18:24:43.614092066 +0200
@@ -951,7 +951,7 @@
}
if (handlePreambleTag(spec, pkg, tag, macro, lang))
return RPMRC_FAIL;
- if (spec-BANames !spec-recursing spec-toplevel)
+ if (spec-BANames !spec-recursing spec-toplevel !specedit)
return PART_BUILDARCHITECTURES;
}
if ((rc =
Re: error: ‘struct FDIO_s’ has no member named ‘_open’
On Jan 2, 2011, at 12:21 PM, Silvan Calarco wrote:
On Thursday 30 December 2010 16:58:43 Jeff Johnson wrote:
Two asides:
1) I have the start of a functionally equivalent replacement for
genpkglist/gensrcpkglist written in C. I can finish writing those
two tools (in C using POPT) with c couple of days of work if there's
interest. My interest at the time was studying what Debian uses
for repository markup as well as fro POPT development (I also maintain
POPT).
I have a plan to include genpkglist/gensrcpkglist in the openmamba tool
distromatic because it would be natural as it is done to generate all
repository output files needed. It has already all repository data structures
in memory, so just the output code needs to be ported.
BTW with the attached patch I workarounded the build and segfault with apt-
repo-tools. The segfault was around some LUA code in the rpmReadConfigFiles()
call, which by evidence I don't need.
If you want, I'll carry genpkglist/gensrcpkglist in tools/* @rpm5.org.
The rationale for integrating into RPM sources is easy maintenance of
the RPM bottom-side API. OTOH, if the output spewage markup is changing
actively, then integrating @rpm5.org just creates Yet Another Maintenance Task.
I can go either way @rpm5.org dependent on circumstances. But having
python/perl/ruby/js
in tree permits rapid detection/porting of any changes (usually deep, not
API/ABI
related) in RPM code.
2) RPM has something called queryformat templates in /usr/lib/rpm/qf/*
that can be used to generate markup based on package metadata.
Interesting.
I don't know if a template could be used to do this, but we have patched rpm
(patch attached), to have a function that produces a preprocessed specfile:
rpm -q --specedit --specfile gcc.spec --define=inputvar inputvalue
Hmmm ,,, --specedit needs to DIE! DIE! DIE! someday.
The replacement is (for full macro expansion)
rpm -D 'inputvar inputvalue' -E `cat gcc.spec`
or (for single tag NVRA query, i.e. the default if no --qf was used)
rpm -D 'inputvar inputvalue' --qf '%{___NVRA}\n' --specfile gcc.spec
Note that there's both --specsrpm and --specfile, the first queries only the
SRPM header.
This is not a good upstream patch, it changes the meaning of an existing
undocumented option, but we did it to quickly fix our automatic update
processes which where weak in specfile variable resolution. Maybe this can be
done in other ways or this might just be a feature request :) (BTW we are
currently fine with our patch).
Thanks for the patch. I'll try to integrate (for rpm-5.4.1, backports to
rpm-5.3.x/rpm-5.2.x
are possible) in the next day or two.
hth
73 de Jeff
Silvan
--
mambaSoft di Calarco Silvan
Web: http://www.mambasoft.it
mambaSoft Store @ http://www.mambastore.it
openmamba GNU/Linux development @ http://www.openmamba.org
apt-repo-tools-0.6.0.12-rpm-5.patchrpm-5.2.1-spec_preprocessed_output.patch
__
RPM Package Managerhttp://rpm5.org
Developer Communication Listrpm-devel@rpm5.org
Re: Using Fopen() [Was: Re: error: ‘struct FDIO_s’ has no member named ‘_open’]
On Wednesday 29 December 2010 15:37:35 Per Øyvind Karlsen wrote: try: fd = Fopen(headerFile, r); ;) Obvious :) Thanks. Silvan -- Regards, Per Øyvind __ RPM Package Managerhttp://rpm5.org Developer Communication Listrpm-devel@rpm5.org -- mambaSoft di Calarco Silvan Web: http://www.mambasoft.it mambaSoft Store @ http://www.mambastore.it openmamba GNU/Linux development @ http://www.openmamba.org __ RPM Package Managerhttp://rpm5.org Developer Communication Listrpm-devel@rpm5.org
Re: error: ‘struct FDIO_s’ has no member named ‘_open’
On Tuesday 28 December 2010 18:10:43 Jeff Johnson wrote:
SO instead of headerGetEntry() the replacement becomes
something like this (this is my paradigm anyways, adjust to tate
if you dislike using alloca):
HE_t he = memset(alloca(sizeof(*he)), 0, sizeof(*he));
he-tag = RPMTAG_NAME;
if (headerGet(h, he, 0) he-t == RPM_STRING_TYPE he-c == 1)
*np = xstrdup(he-p.str);
else
*np = NULL;
he-p.ptr = _free(he-p.ptr);
Ok, this implementation looks more clear than before about data allocation.
I replaced all the calls to headerGetEntry with a call to each of the
following per-type functions:
char *
headerGetStringEntry(Header h, const int tag)
{
char *st = NULL;
HE_t he = memset(alloca(sizeof(*he)), 0, sizeof(*he));
he-tag = tag;
if (headerGet(h, he, 0) he-t == RPM_STRING_TYPE he-c == 1)
st = xstrdup(he-p.str);
else
st = NULL;
he-p.ptr = _free(he-p.ptr);
return st;
}
char **
headerGetStringArrayEntry(Header h, const int tag, int* count)
{
char **st;
HE_t he = memset(alloca(sizeof(*he)), 0, sizeof(*he));
he-tag = tag;
if (headerGet(h, he, 0) he-t == RPM_STRING_ARRAY_TYPE he-c = 1)
{
*count = he-c;
st = dupnargv(he-p.ptr, he-c);
} else {
*count = 0;
st = NULL;
}
he-p.ptr = _free(he-p.ptr);
return st;
}
long long headerGetUIntEntry(Header h, const int tag) {
HE_t he = memset(alloca(sizeof(*he)), 0, sizeof(*he));
unsigned long long ret = -1;
he-tag = tag;
if (headerGet(h, he, 0) he-c == 1) {
switch (he-t) {
case RPM_UINT8_TYPE:
ret = *he-p.ui8p;
break;
case RPM_UINT16_TYPE:
ret = *he-p.ui16p;
break;
case RPM_UINT32_TYPE:
ret = *he-p.ui32p;
break;
case RPM_UINT64_TYPE:
ret = *he-p.ui64p;
break;
default:
ret = -1;
break;
}
}
he-p.ptr = _free(he-p.ptr);
return ret;
}
void *headerGetUIntArrayEntry(Header h, const int tag, int *count) {
HE_t he = memset(alloca(sizeof(*he)), 0, sizeof(*he));
unsigned long long *ret = NULL;
he-tag = tag;
if (headerGet(h, he, 0) he-c = 1) {
*count = he-c;
switch (he-t) {
case RPM_UINT8_TYPE:
ret = memndup(he-p.ui8p, he-c * sizeof(he-p.ui8p));
break;
case RPM_UINT16_TYPE:
ret = memndup(he-p.ui16p, he-c * sizeof(he-p.ui16p));
break;
case RPM_UINT32_TYPE:
ret = memndup(he-p.ui32p, he-c * sizeof(he-p.ui32p));
break;
case RPM_UINT64_TYPE:
ret = memndup(he-p.ui64p, he-c * sizeof(he-p.ui64p));
break;
default:
ret = NULL;
break;
}
}
he-p.ptr = _free(he-p.ptr);
return ret;
}
Not perfect but it apparently works without regressions (tested with the whole
openmamba repository), anyway I'll consider doing a valgrind check later.
Next came apt 0.5.15lorg porting. Though openmamba is using smart which works
without changes because it uses python-rpm, apt libraries are still used e.g.
for repository tools. I've built version 0.5.15lorg3.94a using a couple of
patches I found, one for rpm5 and the other to fix a crash around lua code.
Well apt-get doesn't do anything yet, but I can go on with porting its
dependant packages and test them later.
The last one was apt-repo-tools (http://sisyphus.ru/en/srpm/Sisyphus/apt-repo-
tools) which I use to replace genpkglist and gensrcpkglist from apt, just
ported with some fixes. Now I'm ready for a test of the whole thing on the
repository side...
Thanks.
Silvan
The above snippet is in rpmdb/hdrnvr.c and is a bit more anal
about checking type and count than necessary.
But do note the final
he-p.ptr = _free(he-p.ptr);
(the _free is just a static inline so I don't have to worry about
NULL pointers passed to free, and the assignment is just so that
the original pointer cannot be accidentally reused == just my
coding fetishes, use free(3) however you wish).
The programming rule (and the single biggest change with rpm-5.x) is
All data returned by headerGet() must be free'd.
Is that a headers problem or is it intended that I should use a
different approach?
Different approach. But you can call through the FDIO_s vector to
_fopen still if necessary, I don't recall any changes there.
Ok. I'm just doing a blind port for now and will see if it works.
To avoid patching a lot of sources and autotools I've also made a symlink
/usr/include/rpm/rpmlib.h pointing to /usr/include/rpm/rpm4compat.h,
quite ugly but it worked.
rpm4compat.h works surprisngly well (imho). But I'll
be happy to assist getting rid of the need for
Re: error: ‘struct FDIO_s’ has no member named ‘_open’
On Dec 30, 2010, at 10:17 AM, Silvan Calarco wrote: On Tuesday 28 December 2010 18:10:43 Jeff Johnson wrote: SO instead of headerGetEntry() the replacement becomes something like this (this is my paradigm anyways, adjust to tate if you dislike using alloca): HE_t he = memset(alloca(sizeof(*he)), 0, sizeof(*he)); he-tag = RPMTAG_NAME; if (headerGet(h, he, 0) he-t == RPM_STRING_TYPE he-c == 1) *np = xstrdup(he-p.str); else *np = NULL; he-p.ptr = _free(he-p.ptr); Ok, this implementation looks more clear than before about data allocation. Yep, clear was the goal, and to remove headerFreeData(). I replaced all the calls to headerGetEntry with a call to each of the following per-type functions: snip Yes that works. (aside) The design problem is that a data type isn't too useful for RPM. Sure all the primitive string and integer and octet (and scalar/array) data types exist in RPM. But (with one hysterical exception -- RPMTAG_ARCH/RPMTAG_OS, which have morphed integer - string) -- the data types have never been used in RPM because the tag name implies its type. You've also seen the segfault pain from RPM_CHAR_TYPE - RPM_UINT8_TYPE (which is hardly an interesting or important change). So you might want to rethink your API down the road. Not perfect but it apparently works without regressions (tested with the whole openmamba repository), anyway I'll consider doing a valgrind check later. Good. Note that rpm-5.2.1 has private memory pools, which required some annotations to use valgrind, so you likely want to make sure that rpm is built --with-valgrind. Next came apt 0.5.15lorg porting. Though openmamba is using smart which works without changes because it uses python-rpm, apt libraries are still used e.g. for repository tools. I've built version 0.5.15lorg3.94a using a couple of patches I found, one for rpm5 and the other to fix a crash around lua code. You might want to talk to Andre Guerreiro at Caixa Magica. Per Oyvind (who also wrote rpm4compat.h) has a git repository somewhere with apt-rpm ported to @rpm5.org code. It sure would be nice (for support) if you all started using the same version of apt-rpm and otherwise shared development efforts. Well apt-get doesn't do anything yet, but I can go on with porting its dependant packages and test them later. The last one was apt-repo-tools (http://sisyphus.ru/en/srpm/Sisyphus/apt-repo- tools) which I use to replace genpkglist and gensrcpkglist from apt, just ported with some fixes. Now I'm ready for a test of the whole thing on the repository side... Two asides: 1) I have the start of a functionally equivalent replacement for genpkglist/gensrcpkglist written in C. I can finish writing those two tools (in C using POPT) with c couple of days of work if there's interest. My interest at the time was studying what Debian uses for repository markup as well as fro POPT development (I also maintain POPT). 2) RPM has something called queryformat templates in /usr/lib/rpm/qf/* that can be used to generate markup based on package metadata. E.g rpm -qq --yum:primary.xml is essentially the XML that YUM uses. There's some Debian derived markup there too. Note that I have no usage case for Debian package markup in RPM. I was interested in seeing whether --queryformat templates can be used for real world markup spewage. My answer: Yes, queryformat templates will work for markup. hth 73 de Jeff __ RPM Package Managerhttp://rpm5.org Developer Communication Listrpm-devel@rpm5.org
Using Fopen() [Was: Re: error: ‘struct FDIO_s’ has no member named ‘_open’]
Hi,
On Tuesday 28 December 2010 17:01:50 Jeff Johnson wrote:
The solution here is to use Fopen(), not fdOpen().
I'm testing this in a function but it doesn't work:
FD_t fd;
int rc;
fd = Fopen(headerFile, O_RDONLY);
if (Fileno(fd) 0) {
return 1;
}
rc = rpmReadPackageFile(ts, fd, headerFile, h);
Fopen() returns always 0 for fd. I've tried with different existing full paths
or rpm and src.rpm files. E.g. my application prints:
Warning: reading
/var/ftp/pub/openmamba/devel/SRPMS.base/54321-1.0.2001.11.16-3mamba.src.rpm
Warning: 54321-1.0.2001.11.16-3mamba.src.rpm: unable to read header (No such
file or directory); skipping.
headerFile in Fopen is the path shown and No such file or directory is the
string conversion of errno.
Currently I don't have a lot of ideas about what is wrong with this code, am I
using Fopen and rpmReadPackageFile correctly or do I have to change approach
here as well?
Thanks.
Silvan
Looking inside rpmio.h I see this:
/**
*/
/*...@null@*/ FD_t fdOpen(const char *path, int flags, mode_t mode)
/*...@globals errno, fileSystem, internalState @*/
/*...@modifies errno, fileSystem, internalState @*/;
#define fdOpen(_path, _flags, _mode)fdio-_open((_path), (_flags),
(_mode))
but fdio-_open is not defined, infact FDIO_s contains:
/** \ingroup rpmio
*/
struct FDIO_s {
fdio_read_function_t read;
fdio_write_function_t write;
fdio_seek_function_t seek;
fdio_close_function_t close;
/*...@null@*/
fdio_fopen_function_t _fopen;
/*...@null@*/
fdio_fdopen_function_t_fdopen;
/*...@null@*/
fdio_flush_function_t _flush;
};
Is that a headers problem or is it intended that I should use a different
approach?
Different approach. But you can call through the FDIO_s vector to
_fopen still if necessary, I don't recall any changes there.
The intent is a stdio-like interface, with Fopen instead of fopen, Fread
instead of fread.
Note that the first argument to Fopen can be a URI too. That works for
full content reads on ftp:// and (mostly, no redirects, no proxies, ...)
on http:// in rpm-5.2.1.
Try tools/*wget to see what works and what doesn't.
Thanks for your help!
np. I can/will help with any porting issues.
73 de Jeff
Silvan
__
RPM Package Managerhttp://rpm5.org
Developer Communication Listrpm-devel@rpm5.org
--
mambaSoft di Calarco Silvan
Web: http://www.mambasoft.it
mambaSoft Store @ http://www.mambastore.it
openmamba GNU/Linux development @ http://www.openmamba.org
__
RPM Package Managerhttp://rpm5.org
Developer Communication Listrpm-devel@rpm5.org
Re: Using Fopen() [Was: Re: error: ‘struct FDIO_s ’ has no member named ‘_open’]
2010/12/29 Silvan Calarco silvan.cala...@mambasoft.it: Hi, On Tuesday 28 December 2010 17:01:50 Jeff Johnson wrote: The solution here is to use Fopen(), not fdOpen(). I'm testing this in a function but it doesn't work: FD_t fd; int rc; fd = Fopen(headerFile, O_RDONLY); try: fd = Fopen(headerFile, r); ;) -- Regards, Per Øyvind __ RPM Package Managerhttp://rpm5.org Developer Communication Listrpm-devel@rpm5.org
Re: error: ‘struct FDIO_s’ has no member named ‘_open’
On Dec 28, 2010, at 10:38 AM, Silvan Calarco wrote:
Hi,
I'm trying to port to rpm 5.2.1 an application that was previously made for
rpm 4.4.9.
The application used to read the header with the following code:
FD_t fd;
fd = fdOpen(headerFile, O_RDONLY, 0);
but with rpm 5.2.1 build stops with the error in the subject.
The solution here is to use Fopen(), not fdOpen().
Looking inside rpmio.h I see this:
/**
*/
/*...@null@*/ FD_t fdOpen(const char *path, int flags, mode_t mode)
/*...@globals errno, fileSystem, internalState @*/
/*...@modifies errno, fileSystem, internalState @*/;
#define fdOpen(_path, _flags, _mode)fdio-_open((_path), (_flags),
(_mode))
but fdio-_open is not defined, infact FDIO_s contains:
/** \ingroup rpmio
*/
struct FDIO_s {
fdio_read_function_t read;
fdio_write_function_t write;
fdio_seek_function_t seek;
fdio_close_function_t close;
/*...@null@*/
fdio_fopen_function_t _fopen;
/*...@null@*/
fdio_fdopen_function_t_fdopen;
/*...@null@*/
fdio_flush_function_t _flush;
};
Is that a headers problem or is it intended that I should use a different
approach?
Different approach. But you can call through the FDIO_s vector to
_fopen still if necessary, I don't recall any changes there.
The intent is a stdio-like interface, with Fopen instead of fopen, Fread
instead of fread.
Note that the first argument to Fopen can be a URI too. That works for full
content reads on ftp:// and (mostly, no redirects, no proxies, ...) on http://
in rpm-5.2.1.
Try tools/*wget to see what works and what doesn't.
Thanks for your help!
np. I can/will help with any porting issues.
73 de Jeff
Silvan
--
mambaSoft di Calarco Silvan
Web: http://www.mambasoft.it
mambaSoft Store @ http://www.mambastore.it
openmamba GNU/Linux development @ http://www.openmamba.org
__
RPM Package Managerhttp://rpm5.org
Developer Communication Listrpm-devel@rpm5.org
__
RPM Package Managerhttp://rpm5.org
Developer Communication Listrpm-devel@rpm5.org
Re: error: ‘struct FDIO_s’ has no member named ‘_open’
On Tuesday 28 December 2010 17:01:50 Jeff Johnson wrote: On Dec 28, 2010, at 10:38 AM, Silvan Calarco wrote: Hi, I'm trying to port to rpm 5.2.1 an application that was previously made for rpm 4.4.9. The application used to read the header with the following code: FD_t fd; fd = fdOpen(headerFile, O_RDONLY, 0); but with rpm 5.2.1 build stops with the error in the subject. The solution here is to use Fopen(), not fdOpen(). Ok, I replaced also a fdFileno() with Fileno() and the build completed successfully. Now I just have to fix a list of warnings like these: rpmfunctions.c:124:21: warning: pointer targets in passing argument 3 of ‘headerGetEntry’ differ in signedness /usr/include/rpm/rpmlib.h:119:19: note: expected ‘hTYP_t’ but argument is of type ‘int *’ rpmfunctions.c:124:21: warning: pointer targets in passing argument 5 of ‘headerGetEntry’ differ in signedness /usr/include/rpm/rpmlib.h:119:19: note: expected ‘hCNT_t’ but argument is of type ‘int *’ Is that a headers problem or is it intended that I should use a different approach? Different approach. But you can call through the FDIO_s vector to _fopen still if necessary, I don't recall any changes there. Ok. I'm just doing a blind port for now and will see if it works. To avoid patching a lot of sources and autotools I've also made a symlink /usr/include/rpm/rpmlib.h pointing to /usr/include/rpm/rpm4compat.h, quite ugly but it worked. The intent is a stdio-like interface, with Fopen instead of fopen, Fread instead of fread. Note that the first argument to Fopen can be a URI too. That works for full content reads on ftp:// and (mostly, no redirects, no proxies, ...) on http:// in rpm-5.2.1. Good. Thanks for your help! np. I can/will help with any porting issues. Thank you also for helping in 4.4.9 - 5.2.1 upgrade. Next step will be upgrading to 5.3.6 and possibly integrating some openmamba patches upstream. Silvan 73 de Jeff Silvan __ RPM Package Managerhttp://rpm5.org Developer Communication Listrpm-devel@rpm5.org -- mambaSoft di Calarco Silvan Web: http://www.mambasoft.it mambaSoft Store @ http://www.mambastore.it openmamba GNU/Linux development @ http://www.openmamba.org __ RPM Package Managerhttp://rpm5.org Developer Communication Listrpm-devel@rpm5.org
Re: error: ‘struct FDIO_s’ has no member named ‘_open’
On Dec 28, 2010, at 11:43 AM, Silvan Calarco wrote:
On Tuesday 28 December 2010 17:01:50 Jeff Johnson wrote:
On Dec 28, 2010, at 10:38 AM, Silvan Calarco wrote:
Hi,
I'm trying to port to rpm 5.2.1 an application that was previously made
for rpm 4.4.9.
The application used to read the header with the following code:
FD_t fd;
fd = fdOpen(headerFile, O_RDONLY, 0);
but with rpm 5.2.1 build stops with the error in the subject.
The solution here is to use Fopen(), not fdOpen().
Ok, I replaced also a fdFileno() with Fileno() and the build completed
successfully. Now I just have to fix a list of warnings like these:
rpmfunctions.c:124:21: warning: pointer targets in passing argument 3 of
‘headerGetEntry’ differ in signedness
/usr/include/rpm/rpmlib.h:119:19: note: expected ‘hTYP_t’ but argument is of
type ‘int *’
rpmfunctions.c:124:21: warning: pointer targets in passing argument 5 of
‘headerGetEntry’ differ in signedness
/usr/include/rpm/rpmlib.h:119:19: note: expected ‘hCNT_t’ but argument is of
type ‘int *’
Hmmm ... that's some really old code ...
hTYP_t/hCNT_t were an early attempt at typedef's in RPM.
In rpm-5.x there's a union (what used to be the 4th arg in headerGetEntry as a
void **)
contained in rpmdb/rpmtag.h:
union rpmDataType_u {
/*...@null@*/
void * ptr;
rpmuint8_t * ui8p; /*! RPM_UINT8_TYPE | RPM_CHAR_TYPE */
rpmuint16_t * ui16p;/*! RPM_UINT16_TYPE */
rpmuint32_t * ui32p;/*! RPM_UINT32_TYPE */
rpmuint64_t * ui64p;/*! RPM_UINT64_TYPE */
/*...@relnull@*/
const char * str; /*! RPM_STRING_TYPE */
unsigned char * blob; /*! RPM_BIN_TYPE */
const char ** argv; /*! RPM_STRING_ARRAY_TYPE */
HE_t he;
};
and hTYP_t (the 3rd arg to headerGetEntry) and hCNT_t (the 5th argument) have
all
been bundled into a structure
struct _HE_s {
rpmTag tag;
rpmTagType t;
/*...@owned@*/ /*...@null@*/
rpmTagData p;
rpmTagCount c;
int ix;
unsigned int freeData : 1;
unsigned int avail : 1;
unsigned int append : 1;
};
Note: the ix and the bit fields are only used by headerPut().
SO instead of headerGetEntry() the replacement becomes
something like this (this is my paradigm anyways, adjust to tate
if you dislike using alloca):
HE_t he = memset(alloca(sizeof(*he)), 0, sizeof(*he));
he-tag = RPMTAG_NAME;
if (headerGet(h, he, 0) he-t == RPM_STRING_TYPE he-c == 1)
*np = xstrdup(he-p.str);
else
*np = NULL;
he-p.ptr = _free(he-p.ptr);
The above snippet is in rpmdb/hdrnvr.c and is a bit more anal
about checking type and count than necessary.
But do note the final
he-p.ptr = _free(he-p.ptr);
(the _free is just a static inline so I don't have to worry about
NULL pointers passed to free, and the assignment is just so that
the original pointer cannot be accidentally reused == just my
coding fetishes, use free(3) however you wish).
The programming rule (and the single biggest change with rpm-5.x) is
All data returned by headerGet() must be free'd.
Is that a headers problem or is it intended that I should use a different
approach?
Different approach. But you can call through the FDIO_s vector to
_fopen still if necessary, I don't recall any changes there.
Ok. I'm just doing a blind port for now and will see if it works.
To avoid patching a lot of sources and autotools I've also made a symlink
/usr/include/rpm/rpmlib.h pointing to /usr/include/rpm/rpm4compat.h, quite
ugly but it worked.
rpm4compat.h works surprisngly well (imho). But I'll
be happy to assist getting rid of the need for using
rpm4compat.h in any code. I can do RPM ports in my sleep,
and I're _REALLY_ like not to have to carry around an ancient
API forevermore.
The intent is a stdio-like interface, with Fopen instead of fopen, Fread
instead of fread.
Note that the first argument to Fopen can be a URI too. That works for
full content reads on ftp:// and (mostly, no redirects, no proxies, ...)
on http:// in rpm-5.2.1.
Good.
Thanks for your help!
np. I can/will help with any porting issues.
Thank you also for helping in 4.4.9 - 5.2.1 upgrade. Next step will be
upgrading to 5.3.6 and possibly integrating some openmamba patches upstream.
Cool. You might want to watch Per Oyvind's success/failures in Mandriva Cooker.
AFAICT most of the pieces are in place for a rpm-4.6.1 - rpm-5.3.6 upgrade.
The jump from rpm-5.2.1 - rpm-5.3.6 is a bit easier, but still has
the _rpmmi_usermem and mmap PROT_READ issue. Unlike rpm-5.2.1, rpm-5.3.6
has removed the signature/digest check when reading rpmdb header's, and
so disabling PROT_READ gets snarled up with security issues.
(aside)
The RPM
