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): How reproducible: Steps to Reproduce: 1. 2. 3. Actual results: Expected results: Additional info:
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 http://koji.fedoraproject.org/koji/taskinfo?taskID=547190 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.
http://mcepl.fedorapeople.org/rpms/ 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 don't want.
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 from libbind.
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 patch, please?
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) [edit] > 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 https://www.redhat.com/archives/fedora-devel-list/2008-April/msg01466.html
38910 (bitlbee): Build on target fedora-4-epel succeeded.