rpm 4.4.9 missing neon support in Solaris 9 - build issue?

[David Halik]

Hello all,

Let me first say that archived list mail from all of you was extremely
helpful in enabling me to build rpm 4.4.9 for Solaris 9 sparc as we move
off of 4.1. Almost every issue I ran into had already been address by
Tim Mooney or Jeff Johnson at some point. Thank you very much!

Now that I have it built there is an issue. After succesfully building
4.4.9 against neon 0.26.2 (it didn't seem to like 0.27, so I used a 0.26
I already had) we've noticed that even though the build looked good,
neon support (I guess that's the issue) seems to be mysteriously missing
when we actually go to use it.

For example:

$> rpm -Uvh
ftp://rpm.rutgers.edu/solaris/solaris9-sparc64/helium/RPMS.main/wget-1.10.2-3.solaris2.9-sparc64.rpm
Retrieving
ftp://rpm.rutgers.edu/solaris/solaris9-sparc64/helium/RPMS.main/wget-1.10.2-3.solaris2.9-sparc64.rpm
error: skipping
ftp://rpm.rutgers.edu/solaris/solaris9-sparc64/helium/RPMS.main/wget-1.10.2-3.solaris2.9-sparc64.rpm
- transfer failed - Unknown or unexpected error

Since I'm sucking off our own server we know the files exist and can
download them any other way I try, so I began investigating and noticed
this after a quick truss of the process:

Retrieving
ftp://rpm.rutgers.edu/solaris/solaris9-sparc64/helium/RPMS.main/wget-1.10.2-3.solaris2.9-sparc64.rpm
write(1, " R e t r i e v i n g f".., 112) = 112
getpid() = 2426 [2425]
sysconfig(_CONFIG_MAXPID) = 30000
lstat64("rpm-xfer.ubaqVe", 0xFFBFF880) Err#2 ENOENT
open64("ftp://rpm.rutgers.edu/solaris/solaris9-sparc64/helium/RPMS.main/wget-1.10.2-3.solaris2.9-sparc64.rpm",
O_RDONLY) Err#2 ENOENT
fstat64(2, 0xFFBFF578) = 0
error: write(2, " e r r o r : ", 7) = 7
skipping
ftp://rpm.rutgers.edu/solaris/solaris9-sparc64/helium/RPMS.main/wget-1.10.2-3.solaris2.9-sparc64.rpm
- transfer failed - Unknown or unexpected error

Hmm, that looks like it doesn't understand it's not a local file. So I
looked a little bit farther:

$> strings -a /usr/local/bin/rpm | grep ftp
ftpStrerror
ftpStrerror
ftpFileDoneNeeded
ftpFileDoneNeeded
ftpFileDoneNeeded
ftpFileDoneNeeded
ftpFileDoneNeeded
ftpFileDoneNeeded
&ftpStrerror
$> strings -a /usr/local/bin/rpm | grep http
httpVersion
$>

That didn't seem right either. Way too little in the way of http/ftp,
especially when you compare it against our rpm 4.1 binary that is
currently working. The build definitely thought it was making neon
support, and an ldd of rpm shows libneon.so.26 =>
/usr/local/lib/libneon.so.26, so it wants and finds it... yet it doesn't
look like it was actually built in. Maybe I'm going in the wrong
direction, but I'm stumped.

Any advice here? I'd greatly appreciate it.
Thank you,
-Dave
//////

[Tim Mooney]

Now that I have it built there is an issue. After succesfully building 4.4.9
against neon 0.26.2 (it didn't seem to like 0.27, so I used a 0.26 I already
had) we've noticed that even though the build looked good, neon support (I
guess that's the issue) seems to be mysteriously missing when we actually go
to use it.

I just tested the fetch-and-install functionality, and I'm seeing the exact
same issue you're seeing, on x86_64-sun-solaris2.10.

My libneon was built statically so it won't show up via ldd, but if I

nm -p /local/lib/64/librpmio-4.4.so | egrep 'ne_'

there are lots of neon-related matches, so librpmio definitely has the
necessary neon functions.

Retrieving
ftp://rpm.rutgers.edu/solaris/solaris9-sparc64/helium/RPMS.main/wget-1.10.2-3.solaris2.9-sparc64.rpm
write(1, " R e t r i e v i n g f".., 112) = 112
getpid() = 2426 [2425]
sysconfig(_CONFIG_MAXPID) = 30000
lstat64("rpm-xfer.ubaqVe", 0xFFBFF880) Err#2 ENOENT
open64("ftp://rpm.rutgers.edu/solaris/solaris9-sparc64/helium/RPMS.main/wget-1.10.2-3.solaris2.9-sparc64.rpm",
O_RDONLY) Err#2 ENOENT
fstat64(2, 0xFFBFF578) = 0
error: write(2, " e r r o r : ", 7) = 7
skipping
ftp://rpm.rutgers.edu/solaris/solaris9-sparc64/helium/RPMS.main/wget-1.10.2-3.solaris2.9-sparc64.rpm
- transfer failed - Unknown or unexpected error

I get pretty much the same truss output, but it's probably more useful to
do library-level tracing too, something like

truss -rall -wall -u a.out -u 'libneon::' -u 'librpm-4.4::' -u
'librpmio-4.4::' rpm -Uvh ftp://foo/bar/file.rpm

When I do that, I can see that urlGetFile() is being called, the urlPath()
call is returning 3, but Fopen is returning 0 and that basically ends our
fun.

$> strings -a /usr/local/bin/rpm | grep ftp
ftpStrerror
ftpStrerror
ftpFileDoneNeeded
ftpFileDoneNeeded
ftpFileDoneNeeded
ftpFileDoneNeeded
ftpFileDoneNeeded
ftpFileDoneNeeded
&ftpStrerror
$> strings -a /usr/local/bin/rpm | grep http
httpVersion
$>

That may not necessarily prove anything, as rpm might be invoking a
different program like $prefix/lib/rpm/rpmi.

In any case, I'm seeing the same issue as you. I don't know when I would
have much time to help track down what's going on, especially since
it's functionality I just don't use much.

Tim

[David Halik]

Post by Tim Mooney
I just tested the fetch-and-install functionality, and I'm seeing the exact
same issue you're seeing, on x86_64-sun-solaris2.10.

Ok, so there's definitely an issue across Solaris 9 and Solaris 10
platforms. I'm not extremely familiar with the inner workings of rpm,
but maybe some poking around will tip up the issue.

Post by Tim Mooney
My libneon was built statically so it won't show up via ldd, but if I
nm -p /local/lib/64/librpmio-4.4.so | egrep 'ne_'
there are lots of neon-related matches, so librpmio definitely has the
necessary neon functions.

Agreed. It's looking more like neon is ok, but rpm's handling of it is
bad somewhere. Which version of neon are you building with by the way? I
was using 0.26.2 since 4.4.9 doesn't seem to support 0.27 yet (or at
least it doesn't want to on my setup) and it was already lying around.

Post by Tim Mooney
I get pretty much the same truss output, but it's probably more useful to
do library-level tracing too, something like
truss -rall -wall -u a.out -u 'libneon::' -u 'librpm-4.4::' -u
'librpmio-4.4::' rpm -Uvh ftp://foo/bar/file.rpm
When I do that, I can see that urlGetFile() is being called, the urlPath()
call is returning 3, but Fopen is returning 0 and that basically ends our
fun.

Same thing here, so this must be a coding issue that Solaris is tipping
up rather than at build time.

Post by Tim Mooney

Post by David Halik
$> strings -a /usr/local/bin/rpm | grep ftp
ftpStrerror
ftpStrerror
ftpFileDoneNeeded
ftpFileDoneNeeded
ftpFileDoneNeeded
ftpFileDoneNeeded
ftpFileDoneNeeded
ftpFileDoneNeeded
&ftpStrerror
$> strings -a /usr/local/bin/rpm | grep http
httpVersion
$>

That may not necessarily prove anything, as rpm might be invoking a
different program like $prefix/lib/rpm/rpmi.

I hadn't thought of that, point taken.

Post by Tim Mooney
In any case, I'm seeing the same issue as you. I don't know when I would
have much time to help track down what's going on, especially since
it's functionality I just don't use much.
Tim

Any help would be appreciated. This isn't a critical feature that we
need working, but obviously it's a broken feature that we would
occasionally find useful. I'll see if we can track it down any farther,
but anyone with experience in this area of rpm's code would be a great
help. Tim, I've got another question for you but it's unrelated so I'm
going to break it out into a separate email.

Thanks,
-Dave

[Jeff Johnson]

Post by David Halik
Hello all,
Let me first say that archived list mail from all of you was extremely
helpful in enabling me to build rpm 4.4.9 for Solaris 9 sparc as we move
off of 4.1. Almost every issue I ran into had already been address by
Tim Mooney or Jeff Johnson at some point. Thank you very much!
Now that I have it built there is an issue. After succesfully building
4.4.9 against neon 0.26.2 (it didn't seem to like 0.27, so I used a 0.26
I already had) we've noticed that even though the build looked good,
neon support (I guess that's the issue) seems to be mysteriously missing
when we actually go to use it.

First of all, neon is _NOT_ used for ftp transport.

Second, adding --ftpdebug will display the FTP protocol on
the wire. There is also --rpmiodebug which will display args
to almost every rpmio operation if needed.

Post by David Halik
From 6+ year old memory, there are ftp server differences on solaris that

cause pain. Likely easy fixing if there is need.

73 de Jeff

Post by David Halik
$> rpm -Uvh
ftp://rpm.rutgers.edu/solaris/solaris9-sparc64/helium/RPMS.main/wget-
1.10.2-3.solaris2.9-sparc64.rpm
Retrieving
ftp://rpm.rutgers.edu/solaris/solaris9-sparc64/helium/RPMS.main/wget-
1.10.2-3.solaris2.9-sparc64.rpm
error: skipping
ftp://rpm.rutgers.edu/solaris/solaris9-sparc64/helium/RPMS.main/wget-
1.10.2-3.solaris2.9-sparc64.rpm
- transfer failed - Unknown or unexpected error
Since I'm sucking off our own server we know the files exist and can
download them any other way I try, so I began investigating and noticed
Retrieving
ftp://rpm.rutgers.edu/solaris/solaris9-sparc64/helium/RPMS.main/wget-
1.10.2-3.solaris2.9-sparc64.rpm
write(1, " R e t r i e v i n g f".., 112) = 112
getpid() = 2426 [2425]
sysconfig(_CONFIG_MAXPID) = 30000
lstat64("rpm-xfer.ubaqVe", 0xFFBFF880) Err#2 ENOENT
open64("ftp://rpm.rutgers.edu/solaris/solaris9-sparc64/helium/RPMS
.main/wget-1.10.2-3.solaris2.9-sparc64.rpm",
O_RDONLY) Err#2 ENOENT
fstat64(2, 0xFFBFF578) = 0
error: write(2, " e r r o r : ", 7) = 7
skipping
ftp://rpm.rutgers.edu/solaris/solaris9-sparc64/helium/RPMS.main/wget-
1.10.2-3.solaris2.9-sparc64.rpm
- transfer failed - Unknown or unexpected error
Hmm, that looks like it doesn't understand it's not a local file. So I
$> strings -a /usr/local/bin/rpm | grep ftp
ftpStrerror
ftpStrerror
ftpFileDoneNeeded
ftpFileDoneNeeded
ftpFileDoneNeeded
ftpFileDoneNeeded
ftpFileDoneNeeded
ftpFileDoneNeeded
&ftpStrerror
$> strings -a /usr/local/bin/rpm | grep http
httpVersion
$>
That didn't seem right either. Way too little in the way of http/ftp,
especially when you compare it against our rpm 4.1 binary that is
currently working. The build definitely thought it was making neon
support, and an ldd of rpm shows libneon.so.26 =>
/usr/local/lib/libneon.so.26, so it wants and finds it... yet it doesn't
look like it was actually built in. Maybe I'm going in the wrong
direction, but I'm stumped.
Any advice here? I'd greatly appreciate it.
Thank you,
-Dave
//////
--
=================================
David Halik
Systems Programmer
OSS/NBCS - OIT Rutgers University
=================================
_______________________________________________
Rpm-list mailing list
https://www.redhat.com/mailman/listinfo/rpm-list

[David Halik]

Post by Jeff Johnson
First of all, neon is _NOT_ used for ftp transport.
Second, adding --ftpdebug will display the FTP protocol on
the wire. There is also --rpmiodebug which will display args
to almost every rpmio operation if needed.

Post by David Halik
From 6+ year old memory, there are ftp server differences on solaris that

cause pain. Likely easy fixing if there is need.
73 de Jeff

These Solaris ftp issues are definitely appearing then. When I run it
with --ftpdebug there is no extra info displayed which I immediately
found strange:

# rpm -ivvh --ftpdebug ftp://rpm.rutgers.edu/foo.rpm
Retrieving
ftp://rpm.rutgers.edu/foo.rpm
D: ... as /var/local/tmp/rpm-xfer.6Xaq8f
D: failed to open
ftp://rpm.rutgers.edu/foo.rpm:
No such file or directory
error: skipping
ftp://rpm.rutgers.edu/foo.rpm
- transfer failed - Unknown or unexpected error

--rpmiodebug definitely gives more info:

# rpm -ivvh --rpmiodebug ftp://rpm.rutgers.edu/foo.rpm
*** Fopen ufdio path /etc/rpm/platform fmode r.ufdio
*** ufdOpen(/etc/rpm/platform,0x0,0666)
*** Fopen ufdio path /usr/local/lib/rpm/macros fmode r.fpio
*** ufdOpen(/usr/local/lib/rpm/macros,0x0,0666)
--> fd cec30 ++ 1 open (fdOpen) at rpmio.c:524 | UFD -1 fp 0
==> fdOpen("/usr/local/lib/rpm/macros",0,0666) | UFD 3 fp 0
==> Fileno(cec30) rc 3 | UFD 3 fp 0
==> ufdOpen("/usr/local/lib/rpm/macros",0,0666) | UFD 3 fp 0
*** Fdopen(cec30,r.fpio) | UFD 3 fp 0
==> Fileno(cec30) rc 3 | UFD 3 fp 0
*** Fdopen fpio fp fe7c0234
==> Fdopen(cec30,"r.fpio") returns fd cec30 | FP fe7c0234(3) fdno 3 |
UFD 3 fp fe7c0234
==> Ferror(cec30) rc 0 | FP fe7c0234(3) fdno 3 | UFD 3 fp fe7c0234
==> Fclose(cec30) | FP fe7c0234(3) fdno 3 | UFD 3 fp fe7c0234
--> fd cec30 ++ 2 Fclose at rpmio.c:3238 | FP fe7c0234(3) fdno 3 |
UFD 3 fp fe7c0234
==> fdClose(cec30) rc ffffffff | UFD -1 fp fe7c0234
--> fd cec30 -- 2 open (fdClose) at rpmio.c:507 | UFD -1 fp
fe7c0234
--> fd cec30 -- 1 Fclose at rpmio.c:3316 | UFD -1 fp fe7c0234
*** Fopen ufdio path /usr/local/lib/rpm/sun4u-solaris2.9/macros fmode
r.fpio
*** ufdOpen(/usr/local/lib/rpm/sun4u-solaris2.9/macros,0x0,0666)
*** Glob(/usr/local/etc/rpm/macros.*,0x1000,fee89730,ffbfe700)
*** Fopen ufdio path /usr/local/etc/rpm/macros fmode r.fpio
*** ufdOpen(/usr/local/etc/rpm/macros,0x0,0666)
*** Fopen ufdio path /usr/local/etc/rpm/sun4u-solaris2.9/macros fmode
r.fpio
*** ufdOpen(/usr/local/etc/rpm/sun4u-solaris2.9/macros,0x0,0666)
*** Glob(~/.rpmmacros,0x1000,fee89730,ffbfe700)
*** Stat(/usr/local/lib/rpm/init.lua,ffbff740)
*** Access(/usr/local/etc/rpm/sysinfo,4)
*** rpmioAccess("/usr/local/etc/rpm/sysinfo", 0x4) rc 1
Retrieving ftp://rpm.rutgers.edu/foo.rpm
D: ... as /var/local/tmp/rpm-xfer.C4aa9f
*** Fopen fdio path ftp://rpm.rutgers.edu/foo.rpm fmode r
D: failed to open ftp://rpm.rutgers.edu/foo.rpm:
No such file or directory
error: skipping ftp://rpm.rutgers.edu/foo.rpm
- transfer failed - Unknown or unexpected error

Hmmm, still not very specific as to why it's failing. Any ideas? I'm
guessing Tim is probably going to see similar if not the same output.

Thanks Jeff,
-Dave

[Jeff Johnson]

Post by David Halik
Retrieving ftp://rpm.rutgers.edu/foo.rpm
D: ... as /var/local/tmp/rpm-xfer.C4aa9f
*** Fopen fdio path ftp://rpm.rutgers.edu/foo.rpm fmode r

This should have been opened using "ufdio" not "fdio" (my guess).

I'll take a look this evening.

Post by David Halik
D: failed to open ftp://rpm.rutgers.edu/foo.rpm: No such file or
directory
error: skipping ftp://rpm.rutgers.edu/foo.rpm - transfer failed -
Unknown or unexpected error
Hmmm, still not very specific as to why it's failing. Any ideas? I'm
guessing Tim is probably going to see similar if not the same output.

rpm is attempting to open the path literally. truss will likely verify
that indeed, the url is being passed to open(2) as if it were a
relative file name.

Creating the URL as a local file is another way to verify.

73 de Jeff

[David Halik]

Post by Jeff Johnson
rpm is attempting to open the path literally. truss will likely verify
that indeed, the url is being passed to open(2) as if it were a
relative file name.
Creating the URL as a local file is another way to verify.
73 de Jeff

A quick truss cut out:

open64("ftp://rpm.rutgers.edu/foo.rpm", O_RDONLY) Err#2 ENOENT

If you want to see more of the truss output let me know, but yeah, I think
you're on to it and essentially rpm doesn't understand that it's not a
local file. By the way, our current rpm 4.1 Solaris 9 production systems
do take ftp and http files without any issue, so the change must have
taken place afterwards (not that it narrows it down at all ;). Judging by
what Tim said you should see the same issue on Solaris 10.

Thank you very much for looking into this Jeff.
-Dave

[David Halik]

Post by Jeff Johnson

Post by David Halik
Retrieving ftp://rpm.rutgers.edu/foo.rpm
D: ... as /var/local/tmp/rpm-xfer.C4aa9f
*** Fopen fdio path ftp://rpm.rutgers.edu/foo.rpm fmode r

This should have been opened using "ufdio" not "fdio" (my guess).
I'll take a look this evening.

Hi Jeff, I was just wondering if you've had any luck with this so far.
Thanks,
-Dave

[Jeff Johnson]

Post by David Halik

Post by Jeff Johnson

Post by David Halik
Retrieving ftp://rpm.rutgers.edu/foo.rpm
D: ... as /var/local/tmp/rpm-xfer.C4aa9f
*** Fopen fdio path ftp://rpm.rutgers.edu/foo.rpm fmode r

This should have been opened using "ufdio" not "fdio" (my guess).
I'll take a look this evening.

Hi Jeff, I was just wondering if you've had any luck with this so far.

I looked, but otherwise totally spaced the problem.

The internal ftp client is likely a rpm5.org specific development issue now
that rpm.org has decided to use curl instead, so I'm gonna add a CC line
there.

Feel free to poke at me politely until I fix the issue.

73 de Jeff

--

Post by David Halik
================================
David Halik
Systems Programmer
OSS/NBCS - OIT Rutgers
================================
_______________________________________________
Rpm-list mailing list
https://www.redhat.com/mailman/listinfo/rpm-list

[David Halik]

Post by David Halik

Post by Jeff Johnson

Post by David Halik
Retrieving ftp://rpm.rutgers.edu/foo.rpm
D: ... as /var/local/tmp/rpm- xfer.C4aa9f
*** Fopen fdio path ftp://rpm.rutgers.edu/foo.rpm fmode r

This should have been opened using "ufdio" not "fdio" (my guess).
I'll take a look this evening.

Hi Jeff, I was just wondering if you've had any luck with this so far.
I looked, but otherwise totally spaced the problem.
The internal ftp client is likely a rpm5.org <http://rpm5.org>
specific development issue now that rpm.org <http://rpm.org> has
decided to use curl instead, so I'm gonna add a CC line there.
Feel free to poke at me politely until I fix the issue.
73 de Jeff

Consider yourself poked ;-)