Description of problem:
Bitlbee requires a package update, current package available on repo is
1.0.4-1, current stable source is 1.2
On April 2nd yahoo accounts will not connect without an update contained in 1.2
- see closed bug at http://bugs.bitlbee.org/bitlbee/ticket/370.
Version-Release number of selected component (if applicable):
Steps to Reproduce:
Rob, I won't fix this for Fedora Core 6, because it already reached the end of
life time. I'll work on this for Rawhide, maybe Fedora 7 and 8 are getting an
update, depending on how it changed.
Scratch build is available at
Robert, I think I have resolved couple of issue building bitlbee has. Hopefully
you will make it with bitlbee to F9 ;-).
Are you able to put the changed spec file somewhere as well?
What is the reason to depend now on libbind.so.4 by getting bind-devel into?
I had to remove this e.g. at eggdrop because the bind downstream maintainer was
advising me there to do so.
BTW, do you have any IM contact? I am ceplma in domain jabber.cz
(In reply to comment #4)
> What is the reason to depend now on libbind.so.4 by getting bind-devel into?
> I had to remove this e.g. at eggdrop because the bind downstream maintainer was
> advising me there to do so.
theoretically glibc should cover everything what libbind does. Unfortunately it
is not completely true and without changing dependency on libbind (where
original functions happily live) you get references to GLIBC_STATIC -- which you
In order to get BitlBee 1.2 working on EPEL 4, I addressed upstream #375 with
a patch: http://bugs.bitlbee.org/bitlbee/ticket/375
libbind.so.4 is not available on EPEL. Only libbind9.so.XX exists on EPEL and
Fedora, but I don't know whether there is a difference and whether it's clever
to link against -lbind9.
Maybe Adam Tkac, the BIND maintainer, has an idea for this. Will we get libbind
for EPEL or should we link against -lbind9 or would even some static linking to
glibc better here?
(In reply to comment #7)
> In order to get BitlBee 1.2 working on EPEL 4, I addressed upstream #375 with
> a patch: http://bugs.bitlbee.org/bitlbee/ticket/375
> libbind.so.4 is not available on EPEL. Only libbind9.so.XX exists on EPEL and
> Fedora, but I don't know whether there is a difference and whether it's clever
> to link against -lbind9.
You cannot link it against libbind9, it is completely different library.
> Maybe Adam Tkac, the BIND maintainer, has an idea for this. Will we get libbind
> for EPEL or should we link against -lbind9 or would even some static linking to
> glibc better here?
Best should be link against -lresolv because system header <arpa/nameser.h> are
from glibc (libbind's is in <isc/arpa/nameser.h>). Let me check why glibc
doesn't export ns_initparse and ns_parserr functions. As far as I know they
should be exported and I don't see any reason why they aren't.
Adam, any update from you?
(In reply to comment #9)
> Adam, any update from you?
I asked Ulrich Drepper (glibc upstream maintainer) and he says that he doesn't
want be responsible for maintaining ns_* interfaces and for this reason they are
not visible. So two ways how solve this problem are rewrite bitlbee to not use
ns_* functions or import libbind to EPEL (I'm not sure but isn't sufficient that
libbind is in RHEL?)
Sorry, I can't see libbind in RHEL - at least not in RHEL 4 and 5. Or am I
blind somehow? Maybe you can remove the tomatoes from my eyes...
On RHEL4 libbind is not shipped. On RHEL5 libbind is part of bind-libs and
development package is called bind-libbind-devel.
I forgot mention since F7 is bind-libbind-devel and bind-devel merged together
and all is in bind-devel
Will we get libbind for RHEL 4 or for EPEL 4?
(In reply to comment #14)
> Will we get libbind for RHEL 4 or for EPEL 4?
Hm, EPEL 4 seems better for me because RHEL4 comes into later stage so only
bugfixes should go there. Best way will be rebuild RHEL5 bind for EPEL4 and
distribute libbind. But I'm not member of EPEL project so I'm not sure how do it.
Adam, just the same like Fedora. Request a branch for EL-4 and handle it
similar as RHEL 4, that's all. Is it just building the whole the whole bind
and ripping out everything except libbind after? Maybe we can work on it
together to get it into?
I added a Review Request for a bind-libbind package in bug #442009. Maybe you
also could have a look to it. Hopefully a Fedora or EPEL maintainer is going
soon to review this, as my package works for me on RHEL 4 with another bitlbee
rebuild to catch up the new bind-libbind package.
Actually, if I may chime in -- I have investigated this issue, and it seems that
the only problem we have is function srv_lookup in lib/misc.c. If this is
reimplemented using libresolv instead of libbind by somebody knowledgeable in
the matter (Adam? ;-)), then all this issue would go away.
Alternatively, you may just remove my hack with libbind replacing libresolv. In
such case bitlbee will build, except it won't be able to use SRV records for
locating Jabber servers. It sucks, but you would have perfectly buildable
bitlbee on RHEL4.
(In reply to comment #19)
> Alternatively, you may just remove my hack with libbind replacing libresolv. In
> such case bitlbee will build, except it won't be able to use SRV records for
> locating Jabber servers. It sucks, but you would have perfectly buildable
> bitlbee on RHEL4.
I think this will be the best way how fix this. Or simply copy needed functions
Adam, why not getting libbind into EPEL 4 as I prepared? I think, there are
other packages out there which could depend on libbind as well?!
Created attachment 302473 [details]
Attempt to remedy the situation
My attempt to remedy the situation. Adam, can I ask for the review of the
bitlbee-1.2-1.fc8 has been submitted as an update for Fedora 8
bitlbee-1.2-1.fc7 has been submitted as an update for Fedora 7
Build Result: 38769 - bitlbee on fedora-5-epel
Package: bitlbee-1.2-1.fc7 Tag: dist-fc7-updates-candidate Status: complete
Package: bitlbee-1.2-1.fc8 Tag: dist-f8-updates-candidate Status: complete
Package: bitlbee-1.2-1.fc9 Tag: dist-f9 Status: complete
Once bind-libbind is reviewed, EPEL 4 will get the update as well. Having libbind
there is helpful for other applications as it turned out for me these days.
(In reply to comment #22)
> Created an attachment (id=302473) 
> Attempt to remedy the situation
> My attempt to remedy the situation. Adam, can I ask for the review of the
> patch, please?
Patch looks fine for me. It can be used temporarily before libbind gets into EPEL 4.
bitlbee-1.2-1.fc7 has been pushed to the Fedora 7 stable repository. If problems still persist, please make note of it in this bug report.
bitlbee-1.2-1.fc8 has been pushed to the Fedora 8 stable repository. If problems still persist, please make note of it in this bug report.
(In reply to comment #26)
> Patch looks fine for me. It can be used temporarily before libbind gets
> into EPEL 4.
Actually, I don't think using libbind is a great idea at all -- although bitlbee
worked with libbind for me, it broke pretty quickly in the moment I tried adding
file-transfer patch on its top, because because of libbind apparently *ALL*
symbols which are synonyms between glibc and libbind came from libbind, which
made some nasty surprises when for example getaddrinfo from libbind returned
different error codes than getaddrinfo from glibc.
Unless glibc will officially accept the defeat and remove all synonymous symbols
(or bind begins to rely on glibc), I am afraid we cannot force upstream authors
to rewrite their application for all possible versions of gettaddrinfo ;-(.
Good catch. Headers $(includedir)/netdb.h and $(includedir)/bind/netdb.h are
different. I already started discussion about this topic on
38910 (bitlbee): Build on target fedora-4-epel succeeded.