Bug 198364 - Package gaim lacks IPv6 support
Summary: Package gaim lacks IPv6 support
Status: CLOSED NOTABUG
Alias: None
Product: Fedora
Classification: Fedora
Component: gaim   
(Show other bugs)
Version: rawhide
Hardware: All
OS: Linux
medium
medium
Target Milestone: ---
Assignee: Warren Togami
QA Contact:
URL:
Whiteboard:
Keywords:
Depends On:
Blocks: IPv6Blocker
TreeView+ depends on / blocked
 
Reported: 2006-07-11 10:16 UTC by Peter Vrabec
Modified: 2007-11-30 22:11 UTC (History)
7 users (show)

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2006-07-17 17:38:09 UTC
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)

Description Peter Vrabec 2006-07-11 10:16:41 UTC
This bug was reported automaticaly in connection with IPv6 project.
Our aim is to support IPv6 in all Fedora Core packages so FC6 and RHEL5 will be ready for IPv6.
			
This package seems to lack IPv6 support as is illustrated in attached log.
	
Here follows part of scanning log (grep -r F_INET *)/up to 30 lines: 

/gaim-1.5.0/src/protocols/msn/directconn.c:132:	fd = socket(AF_INET, SOCK_STREAM, 0);
/gaim-1.5.0/src/protocols/msn/directconn.c:144:	sockin.sin_family = AF_INET;
/gaim-1.5.0/src/protocols/msn/servconn.c:457:	fd = socket(AF_INET, SOCK_STREAM, 0);
/gaim-1.5.0/src/protocols/msn/servconn.c:469:	sockin.sin_family = AF_INET;
/gaim-1.5.0/src/protocols/trepia/trepia.c:164:	sin.sin_family = AF_INET;
/gaim-1.5.0/src/protocols/trepia/trepia.c:174:	if ((sockfd = socket(AF_INET, SOCK_DGRAM, 0)) == -1) {
/gaim-1.5.0/src/protocols/gg/common.c:173:	if ((sock = socket(AF_INET, SOCK_STREAM, IPPROTO_TCP)) == -1) {
/gaim-1.5.0/src/protocols/gg/common.c:186:	sin.sin_family = AF_INET;
/gaim-1.5.0/src/protocols/rendezvous/mdns.c:351:	/* What's the difference between AF_INET and PF_INET? */
/gaim-1.5.0/src/protocols/rendezvous/mdns.c:352:	if ((fd = socket(AF_INET, SOCK_DGRAM, 0)) < 0) {
/gaim-1.5.0/src/protocols/rendezvous/mdns.c:361:	addr.sin_family = AF_INET;
/gaim-1.5.0/src/protocols/rendezvous/mdns.c:425:	addr.sin_family = AF_INET;
/gaim-1.5.0/src/protocols/oscar/ft.c:67: * OS X sets all connections as "AF_INET6/PF_INET6," even if there is
/gaim-1.5.0/src/protocols/oscar/ft.c:72: * to use PF_INET6 but it isn't defined.  --Mark Doliner
/gaim-1.5.0/src/protocols/oscar/ft.c:74:#ifndef PF_INET6
/gaim-1.5.0/src/protocols/oscar/ft.c:75:#define PF_INET6 PF_INET
/gaim-1.5.0/src/protocols/oscar/ft.c:197:	if ((addr.sa_family != PF_INET) && (addr.sa_family != PF_INET6)) {
/gaim-1.5.0/src/protocols/oscar/aim.h:50:#define gethostbyname(x) gethostbyname2(x, AF_INET) 
/gaim-1.5.0/src/protocols/zephyr/ZhmStat.c:36:    sin.sin_family = AF_INET;
/gaim-1.5.0/src/protocols/zephyr/ZOpenPort.c:30:    if ((__Zephyr_fd = socket(AF_INET, SOCK_DGRAM, 0)) < 0) {

Comment 1 Ethan Blanton 2006-07-11 13:40:36 UTC
To our knowledge, Gaim does support IPv6 where appropriate.  As someone actually
*looking* at the above trace can tell, there is even code specifically to handle
IPv6 in the above Oscar code, for example.  IRC and Jabber are both IPv6 safe,
at least to my knowledge (I have used Gaim IRC over IPv6, for example).  For
several of the protocols above, it doesn't *matter* whether or not Gaim
"supports" IPv6, because the servers do not (e.g., MSN, gg).

I think you can generally remove Gaim from your list, unless you have an actual
use case where Gaim does not support IPv6 in an environment which should.  (The
Bonjour (nee rendezvous) case above may in fact be such an example; I'm not sure
if it's well-defined over IPv6 or not.  I would tend to assume it is.)

If IPv6 ever becomes relevant, as unlikely as that seems right now, I think Gaim
is actually one of the programs in *better* shape.  ;-)

Ethan

Comment 2 David Woodhouse 2006-07-17 18:11:18 UTC
Thanks for the assessment. The bug was automatically filed by a script, and the
script could possibly do with a little refinement.


Note You need to log in before you can comment on or make changes to this bug.