Bayonne is old, stale and broken. Voicetronix is broken. Fix: Remove/mark as broken the Bayonne support because the only card vendor Voicetronix has said: "I have not compiled it yet, Still need to build A BSD BOX." unittest for voicetronix is broken and blamed the compile error on the firmware not being updated. Happy to share the e-mails documenting this with the PR people who need to do the marking. How-To-Repeat: phone# cd /usr/ports/comms phone# cd bayonne phone# make
State Changed From-To: open->feedback I have commmitted some alternative download locations for this port. Have you asked the Maintainer (David Sugar <dyfet@gnu.org>) about the port? Since you are one of the few people with this exotic Hardware, you are a good candidate to unbreak the port and update it to a more recent version.
Responsible Changed From-To: freebsd-ports-bugs->arved This looks like a challenge for me :)
* Marc Rassbach <marc@milestonerdl.com> [Thu, 23 Jan 2003 16:40:57 -0600 (CST)]: [CCed to David Sugar] > > Synopsis: update bayonne, mark as broken or remove > > > > State-Changed-From-To: open->feedback > > State-Changed-By: arved > > State-Changed-When: Thu Jan 23 14:35:46 PST 2003 > > State-Changed-Why: > > I have commmitted some alternative download locations for this port. > > > > Have you asked the Maintainer (David Sugar <dyfet@gnu.org>) about the port? > > Yes. He's stated that he's looking for someone to take over the FreeBSD > port. He's also been correcting the bugs I've found. Mr. Sugar is good > people. Huh? I remember he held a talk about bayonne on last years EuroBSDcon, so i thought he is still interested in supporting FreeBSD (I didn't attend it). > Which is all fine and good. (And I think his 1.1.6 code works. But the > code needs Automake1.7.2 and Autoconf 2.5.0+ to work and these are held > up by a different port maintainer. If the person in charge of 1.7.2 > automake and 2.5.7 autoconf can't be moved....not much I can do.) Okay, didn't know that. Hopefully we get them soon. But shouldn't it be possible to use the original configure script, so we don't have to recreate the configure script and Makefile.in's? I can try to tweak the ports, but i have neither the hardware nor knowledge about the software. > But the purpose of the bayonne software is to talk to telco cards. To the > best of my knowledge, the only hardware 'supported' (According to the web > sites) is Voicetronix. But one of the developers claimes they don't > even have a FreeBSD box to TEST the code, and (a real gem here) I was told > that > the reason the code didn't COMPILE is I didn't have the latest version of > the firmware loaded to the card. No plans on 5.0 support that I am > aware of, so its a dead end. I would like to get that statement from David. > The Voicetronix answer in the last e-mail? - Try RedHat 7.3 > At least they didn't say 'use windows'. *sigh* > > > Since you are one of the few people with this exotic Hardware, you are a > > good > > candidate to unbreak the port and update it to a more recent version. > > Serial Number 101. > > Mark it as broken. Eventually you can remove it. You might want to hold > off to Wednesday, as Mr. Sugar, Voicetronix, Cylogics (they sell the card > as a FreeBSD supported protuct) > are all at Linuxworld, and are busy selling stuff to Linux users. Okay, I have CCed this to him, hopefully he can give a statement. I will leave this PR in state feedback until end of the month, if there is no answer from him, I will mark the port as broken. regards tilman
Welcome to the thread Mr. Witt. On Thu, 23 Jan 2003, David Sugar wrote: > This is a long discussion, I will comment within... Thanks for your vision on this....and I shall do the same. > On Thursday 23 January 2003 18:26, Tilman Linneweh wrote: > > * Marc Rassbach <marc@milestonerdl.com> [Thu, 23 Jan 2003 16:40:57 -0600 > > (CST)]: > > > > [CCed to David Sugar] > > > > > > Synopsis: update bayonne, mark as broken or remove > > > > > > > > State-Changed-From-To: open->feedback > > > > State-Changed-By: arved > > > > State-Changed-When: Thu Jan 23 14:35:46 PST 2003 > > > > State-Changed-Why: > > > > I have commmitted some alternative download locations for this port. > > > > > > > > Have you asked the Maintainer (David Sugar <dyfet@gnu.org>) about the > > > > port? > > > > > > Yes. He's stated that he's looking for someone to take over the FreeBSD > > > port. He's also been correcting the bugs I've found. Mr. Sugar is > > > good people. > > > > Huh? I remember he held a talk about bayonne on last years EuroBSDcon, > > so i thought he is still interested in supporting FreeBSD (I didn't > > attend it). > > I am very much interested in supporting xBSD systems (including FreeBSD) for > all my packages. However, I am not entirely interested in being the person And I'm interested in SEEING it supported. > that maintains the ports. Long ago I maintained every target os package we And I would have taken over the port LONG ago, if I had a working system. (one year of wait and counting) > supported personally, and this meant I had to do building and testing to > verify and distribute builds on each platform for each and every point > release. In the case of debian, we have a debian maintainer who does this > for us. Similarly, I would like to have someone to do this for the xBSD > ports. I built up the original port entries for my packages, so there is > plenty of material to start from. It is mostly a matter of making sure they > continue to correctly build with each new release. In fact, reading the method Mr. Sugar set up is how I got the latest sets of code running. Go David! > > > Which is all fine and good. (And I think his 1.1.6 code works. But the > > > code needs Automake1.7.2 and Autoconf 2.5.0+ to work and these are held > > > up by a different port maintainer. If the person in charge of 1.7.2 > > > automake and 2.5.7 autoconf can't be moved....not much I can do.) > This resulted from some specific needs in Debian which were incompatible with > older versions of libtool, and other strange issues in the older versions of > autoconf/automake that are standard with older releases of xBSD which tended > to build broken libraries there. Our best solution was to have the port > regenerate autoconf/automake/libtool directly on the FreeBSD host when the > port is built rather than depend on the one the tarball was originally > distributed with. So that madness was my doing. But you are not alone in the madness Mr. Sugar. The autoconf257 is marked as broken. And the tool needed to build the tool you use called commoncpp2 can't portsbuild because autoconf257 is labeled thus: server# make ===> autoconf254-2.54 is marked as broken: DON'T EVEN THINK ABOUT IT.. server# pwd /usr/ports/devel/autoconf257 server# The internal label of 2.54 VS the external 257 and the comment about needing to change a template tells me that it will be a LONG time before it will get fixed. > > Okay, didn't know that. Hopefully we get them soon. > > But shouldn't it be possible to use the original configure script, so we > > don't have to recreate the configure script and Makefile.in's? > > I can try to tweak the ports, but i have neither the hardware nor knowledge > > about the software. > > > > > But the purpose of the bayonne software is to talk to telco cards. To > > > the best of my knowledge, the only hardware 'supported' (According to the > > > web sites) is Voicetronix. But one of the developers claimes they don't > > > even have a FreeBSD box to TEST the code, and (a real gem here) I was > > > told that > > > the reason the code didn't COMPILE is I didn't have the latest version of > > > the firmware loaded to the card. No plans on 5.0 support that I am > > > aware of, so its a dead end. > It is a bit worse than that. The Voicetronix driver, from what I can > personally tell, had not been activily maintained for FreeBSD since around > 4.4. Evidence: Voicetronix tech support does not respond. John Kostogiannis (john@voicetronix.com.au) He claimed a compile problem of unittest was due to old firmware. [Ok. Explain to me slowly how firmware is used by g++?] Peter Wintulich (peter@voicetronix.com.au) Has said they do not have a BSD box to test on. The build documentation shows config and not make buildkernel. (buildkernel is the perefered method, as I understand) The build documentation ALSO shows: TESTING Created 11/3/02 David Rowe www.voicetronix.com.au This file contains suggested test plans to follow when modifying the driver. playrec.cpp ----------- - tbufthread - all tests in tplayrec - tload - playwav --dial - ctserver playrec.pl, dialout.pl - openh323 client-gateway gateway-client & gateway-gateway David Rowe seems to have moved on. ctserver won't compile on FreeBSD. Hard to claim they are working on FreeBSD when the test suite doesn't work. So yea, for all the claims 'supports FreeBSD', the evidence says 'nope'. No working self-test - not a good sign. And 5.0 support? Hahahahahahahahaha. > There is quicknet hardware which has an unofficial driver supported for > xBSD, and soundcard support, which is more useful for demonstration than > function. However, we are working on h323 stack support, which would make > Bayonne very useful again under any xBSD related system, and we are looking > for hardware vendors that do also provide CTI hardware for xBSD systems. If there was other hardware that would be 'vendor supported' on xBSD, great, I'd be there. > > I would like to get that statement from David. > > > The Voicetronix answer in the last e-mail? - Try RedHat 7.3 > > > At least they didn't say 'use windows'. *sigh* > > > > Since you are one of the few people with this exotic Hardware, you are > > > > a good > > > > candidate to unbreak the port and update it to a more recent version. > > > Serial Number 101. > > > Mark it as broken. Eventually you can remove it. You might want to > > > hold off to Wednesday, as Mr. Sugar, Voicetronix, Cylogics (they sell the > > > card as a FreeBSD supported protuct) > > > are all at Linuxworld, and are busy selling stuff to Linux users. > > Okay, I have CCed this to him, hopefully he can give a statement. > I had been aware that FreeBSD Mall had been selling Voicetronix hardware, and > I had been curious about this once I became aware that Voicetronix does not > supply any drivers which will build under any current FreeBSD release. So was I. So I emailed FreeBSD Mall. And I'm going to be rude and post the response: From: Don Witt <witt@cylogistics.com> To: Marc@milestonerdl.com Subject: Re: Anyone have Voicetronix cards working on FreeBSD? [M#6312] There are a number of people using the voicetronix card with freebsd. It works very well. Subject: Re: Anyone have Voicetronix cards working on FreeBSD? [M#6312] I will have to check with some of the people. I am at LinuxWorld in Ny and I may not be able to respond right away. Actually, some of the Voicetronix people will be here. I will ask them. So Mr. Witt what was the response at LinuxWorld? If Voicetronix going to support FreeBSD as they claim to? > Perhaps they are maintaining a driver fork which does built successfully? If > so, I would be happy to support such a forked driver/api in Bayonne as an > interum solution. And I'd be happy to help move a WORKING driver to 5.0 if Voicetronix is willing to make the licence so it can be included in /usr/src/contrib. > > I will leave this PR in state feedback until end of the month, if there is > > no answer from him, I will mark the port as broken. > > regards > > tilman
Hi, Ok, two replies did not reach me, I will try comment on the quoted text. * Marc Rassbach [Freitag, 24. Januar 2003 06:04] : > On Thu, 23 Jan 2003, David Sugar wrote: > > > > Yes. He's stated that he's looking for someone to take over the > > > > FreeBSD port. He's also been correcting the bugs I've found. Mr. > > > > Sugar is good people. > > > > > > Huh? I remember he held a talk about bayonne on last years EuroBSDcon, > > > so i thought he is still interested in supporting FreeBSD (I didn't > > > attend it). > > > > I am very much interested in supporting xBSD systems (including FreeBSD) > > for all my packages. However, I am not entirely interested in being the > > person > > And I'm interested in SEEING it supported. > > And I would have taken over the port LONG ago, if I had a working system. Good to see, so we will try to resolve the current situation (None of the ports build on either 4.7 and 5.0 and are horrible out of Date) > > supported personally, and this meant I had to do building and testing to > > verify and distribute builds on each platform for each and every point > > release. In the case of debian, we have a debian maintainer who does > > this for us. Similarly, I would like to have someone to do this for the > > xBSD ports. I built up the original port entries for my packages, so > > there is plenty of material to start from. It is mostly a matter of > > making sure they continue to correctly build with each new release. So a start would be to set the MAINTAINER= from dyfet@gnu.org to ports@FreeBSD.org, so that volunteers see, that this port is looking for a Maintainer. Is that okay for you David? > In fact, reading the method Mr. Sugar set up is how I got the latest sets > of code running. Go David! Okay, If there is some Information, patches code, please dump it into this GNATS PR (freebsd-gnats-submit@FreeBSD.org with ports/47416 in the subject) and I will look at them. > > > > Which is all fine and good. (And I think his 1.1.6 code works. But > > > > the code needs Automake1.7.2 and Autoconf 2.5.0+ to work and these > > > > are held up by a different port maintainer. If the person in charge > > > > of 1.7.2 automake and 2.5.7 autoconf can't be moved....not much I can > > > > do.) > > > > This resulted from some specific needs in Debian which were incompatible > > with older versions of libtool, and other strange issues in the older > > versions of autoconf/automake that are standard with older releases of > > xBSD which tended to build broken libraries there. Our best solution was > > to have the port regenerate autoconf/automake/libtool directly on the > > FreeBSD host when the port is built rather than depend on the one the > > tarball was originally distributed with. So that madness was my doing. If there are issues that can be resolved easily, I can forward patches, suggestions to the autoconf/libtool Maintainers. > The autoconf257 is marked as broken. And the tool needed to build the > tool you use called commoncpp2 can't portsbuild because autoconf257 is > labeled thus: > server# make > ===> autoconf254-2.54 is marked as broken: DON'T EVEN THINK ABOUT IT.. > server# pwd > /usr/ports/devel/autoconf257 > server# This issue will probably resolve until 4.8 there are patches in the PR Database to solve it (e.g. PR 47203), We are currently testing them with all the 8000 Software Packages available under the FreeBSD ports collection. There are so many broken autoconf scripts circulating around, that this is not an easy task. Unfortunately the auto* tools are all incompatible with other versions. > > > > But the purpose of the bayonne software is to talk to telco cards. > > > > To the best of my knowledge, the only hardware 'supported' (According > > > > to the web sites) is Voicetronix. But one of the developers claimes > > > > they don't even have a FreeBSD box to TEST the code, and (a real gem > > > > here) I was told that > > > > the reason the code didn't COMPILE is I didn't have the latest > > > > version of the firmware loaded to the card. No plans on 5.0 > > > > support that I am aware of, so its a dead end. > > > > It is a bit worse than that. The Voicetronix driver, from what I can > > personally tell, had not been activily maintained for FreeBSD since > > around 4.4. So perhaps it would be nice to add a disclaimer on the websites, that the status of the driver is unknown. It's probably easy to get it running on 4.8 again. 5.0 is a different story. Can someone supply me with a _short_ note, that i can add to the bayonne port with David Sugars approval? > This file contains suggested test plans to follow when modifying the > driver. > > playrec.cpp > ----------- > - tbufthread > - all tests in tplayrec > - tload > - playwav --dial > - ctserver playrec.pl, dialout.pl > - openh323 client-gateway gateway-client & gateway-gateway > > > David Rowe seems to have moved on. > ctserver won't compile on FreeBSD. Hard to claim they are working > on FreeBSD when the test suite doesn't work. What's the errormessage? > > > > Mark it as broken. Eventually you can remove it. You might want to > > > > hold off to Wednesday, as Mr. Sugar, Voicetronix, Cylogics (they sell > > > > the card as a FreeBSD supported protuct) > > > > are all at Linuxworld, and are busy selling stuff to Linux users. > > > > > > Okay, I have CCed this to him, hopefully he can give a statement. > > > > I had been aware that FreeBSD Mall had been selling Voicetronix hardware, > > and I had been curious about this once I became aware that Voicetronix > > does not supply any drivers which will build under any current FreeBSD > > release. > > So was I. So I emailed FreeBSD Mall. > From: Don Witt <witt@cylogistics.com> > There are a number of people using the voicetronix card with freebsd. > It works very well. > Subject: Re: Anyone have Voicetronix cards working on FreeBSD? [M#6312] > I will have to check with some of the people. I am at LinuxWorld in Ny > and I may not be able to respond right away. Actually, some of the > Voicetronix people will be here. I will ask them. > > So Mr. Witt what was the response at LinuxWorld? If Voicetronix going to > support FreeBSD as they claim to? > > Perhaps they are maintaining a driver fork which does built successfully? > > If so, I would be happy to support such a forked driver/api in Bayonne > > as an interum solution. > > And I'd be happy to help move a WORKING driver to 5.0 if Voicetronix is > willing to make the licence so it can be included in /usr/src/contrib. Of course if the driver is integrated into the main FreeBSD tree, it is probably easier to maintain, but first we need to get it working. > > > I will leave this PR in state feedback until end of the month, if there > > > is no answer from him, I will mark the port as broken. regards tilman
This is a long discussion, I will comment within... On Thursday 23 January 2003 18:26, Tilman Linneweh wrote: > * Marc Rassbach <marc@milestonerdl.com> [Thu, 23 Jan 2003 16:40:57 -060= 0 > (CST)]: > > [CCed to David Sugar] > > > > Synopsis: update bayonne, mark as broken or remove > > > > > > State-Changed-From-To: open->feedback > > > State-Changed-By: arved > > > State-Changed-When: Thu Jan 23 14:35:46 PST 2003 > > > State-Changed-Why: > > > I have commmitted some alternative download locations for this port= =2E > > > > > > Have you asked the Maintainer (David Sugar <dyfet@gnu.org>) about t= he > > > port? > > > > Yes. He's stated that he's looking for someone to take over the Fre= eBSD > > port. He's also been correcting the bugs I've found. Mr. Sugar is > > good people. > > Huh? I remember he held a talk about bayonne on last years EuroBSDcon, > so i thought he is still interested in supporting FreeBSD (I didn't > attend it). I am very much interested in supporting xBSD systems (including FreeBSD) = for=20 all my packages. However, I am not entirely interested in being the pers= on=20 that maintains the ports. Long ago I maintained every target os package = we=20 supported personally, and this meant I had to do building and testing to=20 verify and distribute builds on each platform for each and every point=20 release. In the case of debian, we have a debian maintainer who does thi= s=20 for us. Similarly, I would like to have someone to do this for the xBSD=20 ports. I built up the original port entries for my packages, so there is= =20 plenty of material to start from. It is mostly a matter of making sure t= hey=20 continue to correctly build with each new release.=20 > > > Which is all fine and good. (And I think his 1.1.6 code works. But= the > > code needs Automake1.7.2 and Autoconf 2.5.0+ to work and these are he= ld > > up by a different port maintainer. If the person in charge of 1.7.2 > > automake and 2.5.7 autoconf can't be moved....not much I can do.) This resulted from some specific needs in Debian which were incompatible = with =20 older versions of libtool, and other strange issues in the older versions= of=20 autoconf/automake that are standard with older releases of xBSD which ten= ded=20 to build broken libraries there. Our best solution was to have the port=20 regenerate autoconf/automake/libtool directly on the FreeBSD host when th= e=20 port is built rather than depend on the one the tarball was originally=20 distributed with. So that madness was my doing. > Okay, didn't know that. Hopefully we get them soon. > But shouldn't it be possible to use the original configure script, so w= e > don't have to recreate the configure script and Makefile.in's? > I can try to tweak the ports, but i have neither the hardware nor knowl= edge > about the software. > > > But the purpose of the bayonne software is to talk to telco cards. T= o > > the best of my knowledge, the only hardware 'supported' (According to= the > > web sites) is Voicetronix. But one of the developers claimes they d= on't > > even have a FreeBSD box to TEST the code, and (a real gem here) I was > > told that > > the reason the code didn't COMPILE is I didn't have the latest versio= n of > > the firmware loaded to the card. No plans on 5.0 support that I am > > aware of, so its a dead end. It is a bit worse than that. The Voicetronix driver, from what I can=20 personally tell, had not been activily maintained for FreeBSD since aroun= d=20 4.4. There is quicknet hardware which has an unofficial driver supported= for=20 xBSD, and soundcard support, which is more useful for demonstration than=20 function. However, we are working on h323 stack support, which would mak= e=20 Bayonne very useful again under any xBSD related system, and we are looki= ng=20 for hardware vendors that do also provide CTI hardware for xBSD systems. > > I would like to get that statement from David. > > > The Voicetronix answer in the last e-mail? - Try RedHat 7.3 > > At least they didn't say 'use windows'. *sigh* > > > > > Since you are one of the few people with this exotic Hardware, you = are > > > a good > > > candidate to unbreak the port and update it to a more recent versio= n. > > > > Serial Number 101. > > > > Mark it as broken. Eventually you can remove it. You might want to > > hold off to Wednesday, as Mr. Sugar, Voicetronix, Cylogics (they sell= the > > card as a FreeBSD supported protuct) > > are all at Linuxworld, and are busy selling stuff to Linux users. > > Okay, I have CCed this to him, hopefully he can give a statement. I had been aware that FreeBSD Mall had been selling Voicetronix hardware,= and=20 I had been curious about this once I became aware that Voicetronix does n= ot=20 supply any drivers which will build under any current FreeBSD release. =20 Perhaps they are maintaining a driver fork which does built successfully?= If=20 so, I would be happy to support such a forked driver/api in Bayonne as an= =20 interum solution. > > I will leave this PR in state feedback until end of the month, if there= is > no answer from him, I will mark the port as broken. > > regards > tilman
On Fri, 24 Jan 2003, Tilman Linneweh wrote: > Hi, > > Ok, two replies did not reach me, I will try comment on the quoted text. > > > Marc R > > In fact, reading the method Mr. Sugar set up is how I got the latest sets > > of code running. Go David! > > Okay, If there is some Information, patches code, please dump it into this > GNATS PR (freebsd-gnats-submit@FreeBSD.org with ports/47416 in the subject) > and I will look at them. Steps: Untared and compiled autoconf257 Untared and compiled automake172 P bayonne-1.1.6.tar.gz ccaudio-1.0.5.tar.gz ccrtp-1.0pre1.tar.gz ccscript-2.4.2.tar.gz commoncpp2-1.0.6.tar.gz Ycommoncpp2-1.0.7.tar.gz ctserver-0.4.tar.gz ctserver-0.5.tar.gz libhoard-2.1.0.tar.gz vpb-driver-2.2.20.tar.gz vpb-driver-2.2.25.tar.gz > > > > > > Which is all fine and good. (And I think his 1.1.6 code works. But > > > > > the code needs Automake1.7.2 and Autoconf 2.5.0+ to work and these > > > > > are held up by a different port maintainer. If the person in charge > > > > > of 1.7.2 automake and 2.5.7 autoconf can't be moved....not much I can > > > > > do.) > > > > > > This resulted from some specific needs in Debian which were incompatible > > > with older versions of libtool, and other strange issues in the older > > > versions of autoconf/automake that are standard with older releases of > > > xBSD which tended to build broken libraries there. Our best solution was > > > to have the port regenerate autoconf/automake/libtool directly on the > > > FreeBSD host when the port is built rather than depend on the one the > > > tarball was originally distributed with. So that madness was my doing. > > If there are issues that can be resolved easily, I can forward patches, > suggestions to the autoconf/libtool Maintainers. > > > The autoconf257 is marked as broken. And the tool needed to build the > > tool you use called commoncpp2 can't portsbuild because autoconf257 is > > labeled thus: > > server# make > > ===> autoconf254-2.54 is marked as broken: DON'T EVEN THINK ABOUT IT.. > > server# pwd > > /usr/ports/devel/autoconf257 > > server# > > This issue will probably resolve until 4.8 there are patches in the PR > Database to solve it (e.g. PR 47203), We are currently testing them with all > the 8000 Software Packages available under the FreeBSD ports collection. > There are so many broken autoconf scripts circulating around, that this is not > an easy task. Unfortunately the auto* tools are all incompatible with other > versions. > > > > > > But the purpose of the bayonne software is to talk to telco cards. > > > > > To the best of my knowledge, the only hardware 'supported' (According > > > > > to the web sites) is Voicetronix. But one of the developers claimes > > > > > they don't even have a FreeBSD box to TEST the code, and (a real gem > > > > > here) I was told that > > > > > the reason the code didn't COMPILE is I didn't have the latest > > > > > version of the firmware loaded to the card. No plans on 5.0 > > > > > support that I am aware of, so its a dead end. > > > > > > It is a bit worse than that. The Voicetronix driver, from what I can > > > personally tell, had not been activily maintained for FreeBSD since > > > around 4.4. > > So perhaps it would be nice to add a disclaimer on the websites, that the > status of the driver is unknown. > It's probably easy to get it running on 4.8 again. 5.0 is a different story. > > Can someone supply me with a _short_ note, that i can add to the bayonne port > with David Sugars approval? > > > This file contains suggested test plans to follow when modifying the > > driver. > > > > playrec.cpp > > ----------- > > - tbufthread > > - all tests in tplayrec > > - tload > > - playwav --dial > > - ctserver playrec.pl, dialout.pl > > - openh323 client-gateway gateway-client & gateway-gateway > > > > > > David Rowe seems to have moved on. > > ctserver won't compile on FreeBSD. Hard to claim they are working > > on FreeBSD when the test suite doesn't work. > > What's the errormessage? > > > > > > Mark it as broken. Eventually you can remove it. You might want to > > > > > hold off to Wednesday, as Mr. Sugar, Voicetronix, Cylogics (they sell > > > > > the card as a FreeBSD supported protuct) > > > > > are all at Linuxworld, and are busy selling stuff to Linux users. > > > > > > > > Okay, I have CCed this to him, hopefully he can give a statement. > > > > > > I had been aware that FreeBSD Mall had been selling Voicetronix hardware, > > > and I had been curious about this once I became aware that Voicetronix > > > does not supply any drivers which will build under any current FreeBSD > > > release. > > > > So was I. So I emailed FreeBSD Mall. > > > From: Don Witt <witt@cylogistics.com> > > There are a number of people using the voicetronix card with freebsd. > > It works very well. > > Subject: Re: Anyone have Voicetronix cards working on FreeBSD? [M#6312] > > I will have to check with some of the people. I am at LinuxWorld in Ny > > and I may not be able to respond right away. Actually, some of the > > Voicetronix people will be here. I will ask them. > > > > So Mr. Witt what was the response at LinuxWorld? If Voicetronix going to > > support FreeBSD as they claim to? > > > > Perhaps they are maintaining a driver fork which does built successfully? > > > If so, I would be happy to support such a forked driver/api in Bayonne > > > as an interum solution. > > > > And I'd be happy to help move a WORKING driver to 5.0 if Voicetronix is > > willing to make the licence so it can be included in /usr/src/contrib. > > Of course if the driver is integrated into the main FreeBSD tree, it is > probably easier to maintain, but first we need to get it working. > > > > > I will leave this PR in state feedback until end of the month, if there > > > > is no answer from him, I will mark the port as broken. > > regards > tilman > >
On Fri, 24 Jan 2003, Tilman Linneweh wrote: > Hi, > > Ok, two replies did not reach me, I will try comment on the quoted text. > > > Marc R > > In fact, reading the method Mr. Sugar set up is how I got the latest sets > > of code running. Go David! > > Okay, If there is some Information, patches code, please dump it into this > GNATS PR (freebsd-gnats-submit@FreeBSD.org with ports/47416 in the subject) > and I will look at them. Steps: Untared and compiled autoconf257 Untared and compiled automake172 Untared and compiled commoncpp2-1.0.7.tar.gz Found feature, got CVS of 1.0.8 and found it was feature reduced and therefore useable. eventually figued out if I ran ./reconfig then ran ./config, I was good to go. Rinse, lather repeat on the other tarballs ccscript-2.4.2.tar.gz ccaudio-1.0.5.tar.gz ccrtp-1.0pre1.tar.gz after the tools were built bayonne-1.1.6.tar.gz I can't tell if the resulting bayonne works or not, because of the suspect Voicetronix issue. > This issue will probably resolve until 4.8 there are patches in the PR > Database to solve it (e.g. PR 47203), We are currently testing them with all > the 8000 Software Packages available under the FreeBSD ports collection. > There are so many broken autoconf scripts circulating around, that this is not > an easy task. Unfortunately the auto* tools are all incompatible with other > versions. Another idea would be mark it with a warning, to the effect new version(s) await a working autoconf/automake. And how the driver state is unknown. > So perhaps it would be nice to add a disclaimer on the websites, that the > status of the driver is unknown. > It's probably easy to get it running on 4.8 again. 5.0 is a different story. It would have to be added to at least these places: http://www.gnu.org/software/bayonne http://savannah.gnu.org/projects/bayonne http://sourceforge.net/projects/bayonne/ www.voxilla.org ostel's site FreeBSD Mall's site > > ctserver won't compile on FreeBSD. Hard to claim they are working > > on FreeBSD when the test suite doesn't work. > > What's the errormessage? A sample: $ make c++ -O -pipe ctserver.cpp -o ctserver ctserver.cpp: In function `void * rec_thread(void *)': ctserver.cpp:987: warning: large integer implicitly truncated to unsigned type /tmp/ccsuwliR.o: In function `main': /tmp/ccsuwliR.o(.text+0x25): undefined reference to `pthread_mutex_init' /tmp/ccsuwliR.o(.text+0x32): undefined reference to `vpb_seterrormode(int)' /tmp/ccsuwliR.o(.text+0x24d): undefined reference to `verbose_file(int, char *)' /tmp/ccsuwliR.o(.text+0x27a): undefined reference to `vpb_open(unsigned int, unsigned int)' That goes on for pages and pages. Before I decide to take a stab at fixing it, I want the vendor who said they were selling a FreeBSD supported card a chance to make the card work. > > And I'd be happy to help move a WORKING driver to 5.0 if Voicetronix is > > willing to make the licence so it can be included in /usr/src/contrib. > > Of course if the driver is integrated into the main FreeBSD tree, it is > probably easier to maintain, but first we need to get it working. And its under a GPL and LGPL.
State Changed From-To: feedback->closed With help from "Sergey A. Osokin" <osa@freebsd.org.ru> Commoncpp and ccscript were update to the latest version. If someone submits diffs, ccaudio and ccrtp can be updated too. I have marked bayonne broken because of the issues with the Hardware.