Menu
▾
▴
devil-linux-develop
|
From: Heiko Z. <hz...@pr...> - 2003-06-23 13:41:41
|
On 06/23/2003 09:18:31 AM Friedrich Lobenstock wrote: >Bruce Smith wrote: >> At my local LUG, we're currently building an Asterisk PBX box. >> >> One thing that would be useful on our firewall would be a >"gatekeeper", >> for handling incoming H.323/VoIP connections. >> >> Does DL currently have anything like that? > >Not that I know of, but IIRC the last time when I added support >for a selection of netfilter extra patches I think I enabled >the H323 nat/conntrack patch. > >See scripts/config/config-netfilter-extra an then look up the >description at >http://www.netfilter.org/documentation/pomlist/pom-extra.html > >Yes the extra/h323-conntrack-nat patch is enabled, see >http://www.netfilter.org/documentation/pomlist/pom-extra.html#h323-con= nt >rack-nat > >Does that help for now? Yes you added it. But for "bigger" setups a H.323 proxy server is bette= r. Heiko = |
|
From: Heiko Z. <hz...@pr...> - 2003-06-23 13:41:42
|
On 06/23/2003 09:02:32 AM Bruce Smith wrote: >At my local LUG, we're currently building an Asterisk PBX box. > >One thing that would be useful on our firewall would be a "gatekeeper"= , >for handling incoming H.323/VoIP connections. > >Does DL currently have anything like that? > >If not, any objections to me adding something like "gnugk" to DL? No objections here, I actually *want* to have it as one of our functionalities. cya Heiko = |
|
From: Bruce S. <bw...@ar...> - 2003-06-27 13:00:11
|
> >One thing that would be useful on our firewall would be a "gatekeeper", > >for handling incoming H.323/VoIP connections. > > > > ... any objections to me adding something like "gnugk" to DL? > > No objections here, I actually *want* to have it as one of our > functionalities. I have a question about adding this optional package. The GNU-Gatekeeper (gnugk) requires PWLib and the OpenH323 library, which are two separate packages/tar-files. Should I make one menu_add selection for gnugk which selects all three packages? Or should I make three separate menu_add items? (If so, is there any way to require the two libraries if gnugk is selected?) - BS |
|
From: Heiko Z. <hz...@pr...> - 2003-06-27 14:37:59
|
On 06/27/2003 08:59:50 AM Bruce Smith wrote: >> >One thing that would be useful on our firewall would be a >"gatekeeper", >> >for handling incoming H.323/VoIP connections. >> > >> > ... any objections to me adding something like "gnugk" to DL? >> >> No objections here, I actually *want* to have it as one of our >> functionalities. > >I have a question about adding this optional package. > >The GNU-Gatekeeper (gnugk) requires PWLib and the OpenH323 library, >which are two separate packages/tar-files. > >Should I make one menu_add selection for gnugk which selects all three= >packages? > >Or should I make three separate menu_add items? (If so, is there any >way to require the two libraries if gnugk is selected?) You have to create an menuconfig entry for every optional piece and mak= e them dependend on eachother. Check out how I did it with the DJB stuff (daemontools, djbdns). You also have to create one script per tar file. Heiko = |
|
From: Bruce S. <bw...@ar...> - 2003-06-27 14:49:11
|
> >The GNU-Gatekeeper (gnugk) requires PWLib and the OpenH323 library, > >which are two separate packages/tar-files. > > > >Should I make one menu_add selection for gnugk which selects all three > >packages? > > > >Or should I make three separate menu_add items? (If so, is there any > >way to require the two libraries if gnugk is selected?) > > You have to create an menuconfig entry for every optional piece and make > them dependend on eachother. > Check out how I did it with the DJB stuff (daemontools, djbdns). > > You also have to create one script per tar file. OK. Another problem I found, pwlib requires a patch to a bison config file for it to compile (/usr/share/bison/yacc.c - outside of the build tree). How do we handle something like that? - BS |
|
From: Heiko Z. <hz...@pr...> - 2003-06-27 15:22:30
|
On 06/27/2003 10:48:59 AM Bruce Smith wrote: >> >The GNU-Gatekeeper (gnugk) requires PWLib and the OpenH323 library,= >> >which are two separate packages/tar-files. >> > >> >Should I make one menu_add selection for gnugk which selects all >three >> >packages? >> > >> >Or should I make three separate menu_add items? (If so, is there a= ny >> >way to require the two libraries if gnugk is selected?) >> >> You have to create an menuconfig entry for every optional piece and >make >> them dependend on eachother. >> Check out how I did it with the DJB stuff (daemontools, djbdns). >> >> You also have to create one script per tar file. > >OK. > >Another problem I found, pwlib requires a patch to a bison config file= >for it to compile (/usr/share/bison/yacc.c - outside of the build tree= ). > >How do we handle something like that? > I would suggest adding bison to our build system. Compile and install it in the "build" section and put the execution of = the script below 100. cya Heiko = |
|
From: Bruce S. <bw...@ar...> - 2003-06-27 15:40:16
|
> >Another problem I found, pwlib requires a patch to a bison config file > >for it to compile (/usr/share/bison/yacc.c - outside of the build tree). > > > >How do we handle something like that? > > I would suggest adding bison to our build system. > Compile and install it in the "build" section and put the execution of the > script below 100. Do a "make install" in the build system, and install it in the LFS base? And don't copy anything to the DL CD? One potential problem is we're currently running the latest _stable_ version of bison, so I'd have to install the latest _beta_ release. Are we brave enough to install a beta release of bison in the LFS, considering it is probably used to compile many of our packages? It may be safer to create a build script to copy (or patch) the new /usr/share/bison/yacc.c file into our current release of bison. What do you think? - BS |
|
From: Friedrich L. <fl...@fl...> - 2003-06-27 15:43:54
|
Bruce Smith wrote: >>>Another problem I found, pwlib requires a patch to a bison config file >>>for it to compile (/usr/share/bison/yacc.c - outside of the build tree). >>> >>>How do we handle something like that? >> >>I would suggest adding bison to our build system. >>Compile and install it in the "build" section and put the execution of the >>script below 100. > > > Do a "make install" in the build system, and install it in the LFS base? > And don't copy anything to the DL CD? > > One potential problem is we're currently running the latest _stable_ > version of bison, so I'd have to install the latest _beta_ release. > > Are we brave enough to install a beta release of bison in the LFS, > considering it is probably used to compile many of our packages? > > It may be safer to create a build script to copy (or patch) the new > /usr/share/bison/yacc.c file into our current release of bison. How about creating a package for the stable bison, extracting the patch from pwlib and letting the bison build script do the patching. -- MfG / Regards Friedrich Lobenstock ____________________________________________________________________ Friedrich Lobenstock Linux Services Lobenstock URL: http://www.lsl.at/ Email: fl...@fl... ____________________________________________________________________ |
|
From: Bruce S. <bw...@ar...> - 2003-06-27 15:49:16
|
> >>I would suggest adding bison to our build system. > >>Compile and install it in the "build" section and put the execution of the > >>script below 100. > > > > Do a "make install" in the build system, and install it in the LFS base? > > And don't copy anything to the DL CD? > > > > One potential problem is we're currently running the latest _stable_ > > version of bison, so I'd have to install the latest _beta_ release. > > > > Are we brave enough to install a beta release of bison in the LFS, > > considering it is probably used to compile many of our packages? > > > > It may be safer to create a build script to copy (or patch) the new > > /usr/share/bison/yacc.c file into our current release of bison. > > How about creating a package for the stable bison, extracting the patch > from pwlib and letting the bison build script do the patching. We could, but I don't see what that gains us. The file that needs to be patched is a text file (not a binary), so a re-compile is not necessary. - BS |
|
From: Friedrich L. <fl...@fl...> - 2003-06-27 16:01:34
|
Bruce Smith wrote: >>How about creating a package for the stable bison, extracting the patch >>from pwlib and letting the bison build script do the patching. > > We could, but I don't see what that gains us. The file that needs to be > patched is a text file (not a binary), so a re-compile is not necessary. Just my 2 euro cents. -- MfG / Regards Friedrich Lobenstock ____________________________________________________________________ Friedrich Lobenstock Linux Services Lobenstock URL: http://www.lsl.at/ Email: fl...@fl... ____________________________________________________________________ |
|
From: Bruce S. <bw...@ar...> - 2003-07-07 18:39:51
|
> How about creating a package for the stable bison, extracting the patch > from pwlib and letting the bison build script do the patching. OK, I'm looking into recompiling bison on the DL system. Using gcc as an example, I guess I should make & "make install" bison during the build phase, right after gcc is compiled? (003bison)? During the install phase, should I make it an optional package to install, like gcc? Or just skip it ... - BS |
|
From: Heiko Z. <hz...@pr...> - 2003-07-07 18:49:44
|
On 07/07/2003 02:39:36 PM Bruce Smith wrote: >> How about creating a package for the stable bison, extracting the >patch >> from pwlib and letting the bison build script do the patching. > >OK, I'm looking into recompiling bison on the DL system. > >Using gcc as an example, I guess I should make & "make install" bison >during the build phase, right after gcc is compiled? (003bison)? > >During the install phase, should I make it an optional package to >install, like gcc? Or just skip it ... I don't think we need bison on the DL ISO, so I vote for skipping it. Heiko = |
|
From: Bruce S. <bw...@ar...> - 2003-07-07 18:55:39
|
> >> How about creating a package for the stable bison, extracting the > >patch > >> from pwlib and letting the bison build script do the patching. > > > >OK, I'm looking into recompiling bison on the DL system. > > > >Using gcc as an example, I guess I should make & "make install" bison > >during the build phase, right after gcc is compiled? (003bison)? I'll assume I'm correct there. > >During the install phase, should I make it an optional package to > >install, like gcc? Or just skip it ... > > I don't think we need bison on the DL ISO, so I vote for skipping it. Yeah! That makes it much easier! :-) I need to apply a patch to bison. Which directory should I upload the patch file to? I thought I could find it, but I'm having trouble locating an example. - BS |
|
From: Bruce S. <bw...@ar...> - 2003-07-07 19:06:00
|
> Which directory should I upload the patch file to? Never mind ... I see they are in the src directory. - BS |
|
From: Heiko Z. <hz...@pr...> - 2003-07-07 19:12:52
|
On 07/07/2003 02:55:27 PM Bruce Smith wrote: >> >> How about creating a package for the stable bison, extracting the= >> >patch >> >> from pwlib and letting the bison build script do the patching. >> > >> >OK, I'm looking into recompiling bison on the DL system. >> > >> >Using gcc as an example, I guess I should make & "make install" bis= on >> >during the build phase, right after gcc is compiled? (003bison)? > >I'll assume I'm correct there. > >> >During the install phase, should I make it an optional package to >> >install, like gcc? Or just skip it ... >> >> I don't think we need bison on the DL ISO, so I vote for skipping it= . > >Yeah! That makes it much easier! :-) > >I need to apply a patch to bison. >Which directory should I upload the patch file to? > >I thought I could find it, but I'm having trouble locating an example.= I can't look it up right now, but try a " grep -i patch build/scripts/*= ". You place the patch as a bz2 in build/src cya Heiko = |
