apache 2.2.8 authdbm woes
Hello, For the past few days, I've been migrating a bunch of apache-1.3.41 vhosts to apache-2.2.8 (on the same machine, 6.3-RELEASE i386). Many of directories are protected with AuthType directives and I want to reuse the existing .dat files. After working successfully for more than a day with the original .dat files, apache-2.2.8 suddenly decides that format is not supported. Here's what the error log says: This function has not been implemented on this platform: could not open dbm (type DB) auth file: /usr/local/etc/apache22/auth/admin-passwords.dat I'm fairly certain that the beginning of the error messages coincided with the first modifications I made to the .dat files after copying them from /usr/local/etc/apache to /usr/local/etc/apache22. The syntax I used to modify the files were: dbmmanage admin-groups.dat add newAdminUser newAdminGroup dbmmanage admin-passwords.dat adduser newAdminUser I compiled apache-2.2.8 with the following options: make -DWITH_BDB -DWITH_BDB_BASE And have the following directives in the conf file: AuthType Basic AuthName "Authorized Users" AuthBasicProvider dbm AuthDBMType DB AuthDBMUserFile etc/apache22/auth/admin-passwords.dat AuthDBMGroupFile etc/apache22/auth/admin-groups.dat require group newAdminGroup In the apache-1.3.41 httpd.conf file, I used: AuthName "Authorized Users" AuthType Basic AuthDBUserFile /usr/local/etc/apache/admin-passwords.dat AuthDBGroupFile /usr/local/etc/apache/admin-groups.dat require group newAdminGroup This change in apache's behavior is very strange indeed. I tried copying the original .dat files and restarting apache, but to no avail. I also must admit that I'm a little confused between AuthDBM/AuthDB and and all the DBM/BDB options in FreeBSD's Make infrastructure Many thanks for your consideration and assistance. -- Regards, Doug ___ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: apache 2.2.8 authdbm woes
On Sun, Feb 17, 2008 at 07:23:17AM -0600, Doug Poland wrote: > Hello, You're likely suffering from this: http://www.freebsd.org/cgi/query-pr.cgi?pr=119711 There were some recent changes to www/apache22 which specifically addressed the above: http://www.freebsd.org/cgi/cvsweb.cgi/ports/www/apache22/Makefile -- | Jeremy Chadwickjdc at parodius.com | | Parodius Networking http://www.parodius.com/ | | UNIX Systems Administrator Mountain View, CA, USA | | Making life hard for others since 1977. PGP: 4BD6C0CB | ___ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: obexftp - call for testers
Peter Jeremy пишет: On Fri, Feb 15, 2008 at 02:50:36PM +0100, Dierk Sacher wrote: This is a 'works for me' port. I've only been able to test it with 6.2-RELEASE on i386 with only one mobile over bluetooth. I did not test anything else (usb, IR ...). I wouldn't mind having obexftp to talk to my phone but unfortunately this port doesn't work for me on 6.3-PRERELEASE/amd64 over bluetooth, though that could be just that I'm not driving it correctly: turion# obexftp -b PeterPhone -v -x Scanning for PeterPhone ... Browsing PeterPhone ... Connecting...failed: connect Still trying to connect Connecting...failed: connect Still trying to connect Connecting...failed: connect Still trying to connect turion# And hcidump shows no data so I suspect it's not even trying BlueTooth. ktrace shows that it's not searching /etc/bluetooth/hosts but directly specifying the BD_ADDR has no improvement and the connect() is returning EINVAL. With - nokia-6085 - obexapp-1.4.8 work correct. But this port: ussr$ obexftp --bluetooth nokia-6085 -x Scanning for nokia-6085 ... Browsing nokia-6085 ... Connecting...failed: connect Still trying to connect Connecting...failed: connect Still trying to connect Connecting...failed: connect Still trying to connect ussr$ obexftp --bluetooth siemens-sl56 -x Scanning for siemens-sl56 ... Browsing siemens-sl56 ... Connecting...failed: connect Still trying to connect Connecting...failed: connect Still trying to connect Connecting...failed: connect Still trying to connect ussr$ obexftp --bluetooth siemens-sl56 -X Scanning for siemens-sl56 ... Browsing siemens-sl56 ... Connecting...failed: connect Still trying to connect Connecting...failed: connect Still trying to connect Connecting...failed: connect Still trying to connect ussr$ obexftp --bluetooth nokia-6085 -X Scanning for nokia-6085 ... Browsing nokia-6085 ... Connecting...failed: connect Still trying to connect Connecting...failed: connect Still trying to connect Connecting...failed: connect Still trying to connect ussr$ uname -a FreeBSD ussr.lissyara.int.otradno.ru 6.3-RELEASE FreeBSD 6.3-RELEASE #0: Sun Jan 20 09:47:57 MSK 2008 [EMAIL PROTECTED]:/usr/obj/usr/src/sys/color-console i386 ussr$ obexftp --bluetooth siemens-sl56 -p /usr/home/lissyara/Desktop/nokia_freebsd.txt Scanning for siemens-sl56 ... Browsing siemens-sl56 ... Connecting...failed: connect Still trying to connect Connecting...failed: connect Still trying to connect Connecting...failed: connect Still trying to connect ___ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to "[EMAIL PROTECTED]"
ntop does not compile on 7.0-RC2
Hi, ntop stops with: [...] then mv -f ".deps/iface.Tpo" ".deps/iface.Plo"; else rm -f ".deps/iface.Tpo"; exit 1; fi cc -DHAVE_CONFIG_H -I. -I. -I. -I. -I/usr -I/usr/include -DINET6 -O2 -Dfreebsd7 -DAPPLLIB_EXP=/usr/local/lib/perl5/5.8.8/BSDPAN -DHAS_FPSETMASK -DHAS_FLOATINGPOINT_H -fno-strict-aliasing -pipe -Wdeclaration-after-statement -I/usr/local/lib/perl5/5.8.8/mach/CORE -I. -I/usr/local/include -DFREEBSD -I/usr/local/include -I/usr/local/include -I/usr/include -g -O2 -fno-strict-aliasing -pipe -I/usr/local/include -g -Wshadow -Wpointer-arith -Wmissing-prototypes -Wmissing-declarations -Wnested-externs -fPIC -DPIC -MT iface.lo -MD -MP -MF .deps/iface.Tpo -c iface.c -fPIC -DPIC -o .libs/iface.o In file included from /usr/local/include/net-snmp/utilities.h:54, from /usr/local/include/net-snmp/net-snmp-includes.h:78, from iface.c:766: /usr/local/include/net-snmp/library/container.h: In function 'CONTAINER_FREE': /usr/local/include/net-snmp/library/container.h:416: error: lvalue required as left operand of assignment In file included from /usr/local/include/net-snmp/mib_api.h:24, from /usr/local/include/net-snmp/net-snmp-includes.h:81, from iface.c:766: /usr/local/include/net-snmp/library/parse.h:32:1: warning: "MAXLABEL" redefined In file included from /usr/include/arpa/nameser.h:579, from ntop.h:321, from iface.c:26: /usr/include/arpa/nameser_compat.h:104:1: warning: this is the location of the previous definition gmake[2]: *** [iface.lo] Error 1 gmake[2]: Leaving directory `/usr/ports/net/ntop/work/ntop-3.3' gmake[1]: *** [all-recursive] Error 1 gmake[1]: Leaving directory `/usr/ports/net/ntop/work/ntop-3.3' gmake: *** [all] Error 2 *** Error code 2 Stop in /usr/ports/net/ntop. *** Error code 1 Stop in /usr/ports/net/ntop. Bug or a local problem? Thanks, Helmut -- No Swen today, my love has gone away My mailbox stands for lorn, a symbol of the dawn ___ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: apache 2.2.8 authdbm woes
On Sun, February 17, 2008 08:19, Jeremy Chadwick wrote: > On Sun, Feb 17, 2008 at 07:23:17AM -0600, Doug Poland wrote: >> Hello, > > You're likely suffering from this: > > http://www.freebsd.org/cgi/query-pr.cgi?pr=119711 > > There were some recent changes to www/apache22 which specifically > addressed the above: > > http://www.freebsd.org/cgi/cvsweb.cgi/ports/www/apache22/Makefile > Thanks for the quick response. I've read the pr description (119711) but am still a little confused. I used the new Makefile options: make -DWITH_BDB -DWITH_BDB_BASE as mentioned in my OP. The really weird thing is apache-2.2.8 worked with AuthDBM for many tests, but then suddenly stopped working. Perhaps my base install of Berkeley DB is having issues reading .dat files generated from an earlier version? How would one diagnose this? Again, thanks for the help. -- Regards, Doug ___ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to "[EMAIL PROTECTED]"
tor-devel doesn't log
As far as I can see, tor-devel doesn't log to /var/log/tor as the rc.d
script means for it to do.
>From what I found out, Tor is called with
command_args="[...] --Log \"notice file ${tor_logfile}\""
But putting an 'echo' in front of the command, only "--Log notice" is
what I see. I.e. the command_args are cut short of "file
/var/log/tor":
/usr/local/bin/tor -f /usr/local/etc/tor/torrc --PidFile
/var/run/tor/tor.pid --RunAsDaemon 1 --DataDirectory /var/db/tor
--User _tor --Group _tor --Log notice
What gives?
___
freebsd-ports@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-ports
To unsubscribe, send any mail to "[EMAIL PROTECTED]"
What's a "good" way to handle installation of conflicting ports?
I've been asked to come up with at least an interim approach -- that can be implemented within a few days -- to allow the SAs at my new job to install conflicting ports on the same machine. I can think of some approaches, but I'd prefer to use one that doesn't suck too much, and that doesn't impede the transition to something better. I would also like to continue to be able to make use of the FreeBSD "ports" system, and be able to take advantage of the ports collection, such as dependency-tracking. Their (the SAs) stated preferred approach is to use GNU stow (sysutils/stow), though I've not used it previously, and I'm not quite clear on just how that would work in practice -- and still provide the benefits of the FreeBSD "ports" system as mentioned above. (They use it for the Linux machines; not sure about the Solaris machines.) The catalyst for the exercise is that we have some pools of machines for developers to use; some of the developers wish to use editors/xemacs; some wish to use editors/emacs -- on the same machine. (Given the requirement, it's OK for the affected folks to need to adjust search, library, and man paths.) (I haven't been in the new position long enough to know why folks can't just each use their own desktop/workstations, configured however each one sees fit. Even so, I suppose that there might be a developer out there who might want conflicting ports on his dektop -- I've had that request before ... or rather, a request that implied that: One of the developers at a previous place of employment was distressed when he determined that he was unable to install every port in the ports collection on his desktop machine. In that case, his local disk storage gave out before he ran into the "conflicts" issue, but I'm sure that would have come up eventually.) (I've subscribed to -ports@, at least for now, so there's no need to copy me on messages sent to the list.) Anyway, thanks in advance for suggestions -- even pointing out why a certain approach would be inadvisable would be helpful. Peace, david -- David H. Wolfskill [EMAIL PROTECTED] I submit that "conspiracy" would be an appropriate collective noun for cats. See http://www.catwhisker.org/~david/publickey.gpg for my public key. pgp3fCBc0boWS.pgp Description: PGP signature
Re: Asterisk-Addons 1.4.5 still wont build
Hello all. Unfortunatly i dont use h323 so i cannot test if all this really works. What are the last patches need to make asterisk-addons compile with the codec negotiation patch, that works? If all compiles ok, and you guys can confirm the patch really works, we could send a pr. Thanks! El mar, 12-02-2008 a las 10:07 +0800, Ganbold escribió: > However I was able to compile it after making some changes to > chan_h323.c and ooh323cDriver.c. ___ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: What's a "good" way to handle installation of conflicting ports?
On Sun, 2008-02-17 at 11:52 -0800, David Wolfskill wrote: > I've been asked to come up with at least an interim approach -- > that can be implemented within a few days -- to allow the SAs at > my new job to install conflicting ports on the same machine. > > I can think of some approaches, but I'd prefer to use one that doesn't > suck too much, and that doesn't impede the transition to something better. > I would also like to continue to be able to make use of the FreeBSD > "ports" system, and be able to take advantage of the ports collection, > such as dependency-tracking. > > Their (the SAs) stated preferred approach is to use GNU stow > (sysutils/stow), though I've not used it previously, and I'm not > quite clear on just how that would work in practice -- and still provide > the benefits of the FreeBSD "ports" system as mentioned above. (They > use it for the Linux machines; not sure about the Solaris machines.) > > The catalyst for the exercise is that we have some pools of machines > for developers to use; some of the developers wish to use > editors/xemacs; some wish to use editors/emacs -- on the same machine. > (Given the requirement, it's OK for the affected folks to need to adjust > search, library, and man paths.) > You can either edit the Makefile of the port to try and install it somewhere non-standard and hope there are no conflicting libraries, or you could implement a jail system. If you had a beefy enough machine, give each developer their own jail and let them run with it. http://www.freebsd.org/doc/en_US.ISO8859-1/books/handbook/jails.html > (I haven't been in the new position long enough to know why folks can't > just each use their own desktop/workstations, configured however each > one sees fit. Even so, I suppose that there might be a developer out > there who might want conflicting ports on his dektop -- I've had that > request before ... or rather, a request that implied that: One of the > developers at a previous place of employment was distressed when he > determined that he was unable to install every port in the ports > collection on his desktop machine. In that case, his local disk storage > gave out before he ran into the "conflicts" issue, but I'm sure that > would have come up eventually.) > > (I've subscribed to -ports@, at least for now, so there's no need to > copy me on messages sent to the list.) > > Anyway, thanks in advance for suggestions -- even pointing out why a > certain approach would be inadvisable would be helpful. > > Peace, > david ___ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: Problems with icu - 3.8
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 Atanas Gendov wrote: > Greetings to all from FreeBSD Ports!!! :) > I have some problems with icu - 3.8. After portupgrade of icu and some > others packages I can't start Gnome. Because of Gnome needs module from icu > - 3.6. Unfortunately there is no new port for gdm which doesn't have depends > on icu-3.6. Lots of people are getting bitten by the effects of the bump in the libicu* shlib ABI version numbers -- there really should be a note in UPDATING about it. It affects all sorts of different packages -- I've even got one system where it took out OpenLDAP. Anyhow, one solution is to rebuild all ports that depend on ICU. That's unfortunately going to be quite a lot of ports on a typical desktop system. # portupgrade -fr icu-3.8.1 will do the trick: alternatives using other ports management software are left as an exercise for the reader. This will fix gdm for you. Cheers, Matthew - -- Dr Matthew J Seaman MA, D.Phil. 7 Priory Courtyard Flat 3 PGP: http://www.infracaninophile.co.uk/pgpkey Ramsgate Kent, CT11 9PW -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.4 (FreeBSD) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFHuKOy8Mjk52CukIwRCOvkAJ453BrjXMrLGabXjTJZgDbzRMO2iwCdFwCx KdjSjvSia2Nu1f3/gUNL2Ts= =oIMR -END PGP SIGNATURE- ___ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Problems with icu - 3.8
Greetings to all from FreeBSD Ports!!! :) I have some problems with icu - 3.8. After portupgrade of icu and some others packages I can't start Gnome. Because of Gnome needs module from icu - 3.6. Unfortunately there is no new port for gdm which doesn't have depends on icu-3.6. Atanas ___ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: What's a "good" way to handle installation of conflicting ports?
David Wolfskill wrote: I've been asked to come up with at least an interim approach -- that can be implemented within a few days -- to allow the SAs at my new job to install conflicting ports on the same machine. I can think of some approaches, but I'd prefer to use one that doesn't suck too much, and that doesn't impede the transition to something better. I would also like to continue to be able to make use of the FreeBSD "ports" system, and be able to take advantage of the ports collection, such as dependency-tracking. Their (the SAs) stated preferred approach is to use GNU stow (sysutils/stow), though I've not used it previously, and I'm not quite clear on just how that would work in practice -- and still provide the benefits of the FreeBSD "ports" system as mentioned above. (They use it for the Linux machines; not sure about the Solaris machines.) The catalyst for the exercise is that we have some pools of machines for developers to use; some of the developers wish to use editors/xemacs; some wish to use editors/emacs -- on the same machine. (Given the requirement, it's OK for the affected folks to need to adjust search, library, and man paths.) (I haven't been in the new position long enough to know why folks can't just each use their own desktop/workstations, configured however each one sees fit. Even so, I suppose that there might be a developer out there who might want conflicting ports on his dektop -- I've had that request before ... or rather, a request that implied that: One of the developers at a previous place of employment was distressed when he determined that he was unable to install every port in the ports collection on his desktop machine. In that case, his local disk storage gave out before he ran into the "conflicts" issue, but I'm sure that would have come up eventually.) And what if someone wants more operating systems on one machine... I recommend you jails and run those conflicting applications in jail(s). Conflicting ports are... conflicting :) And even if you change Makefiles or use another PREFIX you could have some problems. Miroslav Lachman ___ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: Problems with icu - 3.8
On Sun, 2008-02-17 at 21:14 +, Matthew Seaman wrote: > -BEGIN PGP SIGNED MESSAGE- > Hash: SHA256 > > Atanas Gendov wrote: > > Greetings to all from FreeBSD Ports!!! :) > > I have some problems with icu - 3.8. After portupgrade of icu and some > > others packages I can't start Gnome. Because of Gnome needs module from icu > > - 3.6. Unfortunately there is no new port for gdm which doesn't have depends > > on icu-3.6. > > Lots of people are getting bitten by the effects of the bump in the > libicu* shlib ABI version numbers -- there really should be a note > in UPDATING about it. It affects all sorts of different packages -- > I've even got one system where it took out OpenLDAP. Do you know who to ask for the note? I was bitten by it, but fortunately there had just been a large thread in questions@ about it. It does seem to be a common issue. James ___ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: What's a "good" way to handle installation of conflicting ports?
On Sun, Feb 17, 2008 at 11:52:59AM -0800, David Wolfskill wrote: > The catalyst for the exercise is that we have some pools of machines > for developers to use; some of the developers wish to use > editors/xemacs; some wish to use editors/emacs -- on the same machine. > (Given the requirement, it's OK for the affected folks to need to adjust > search, library, and man paths.) Use a jailed environment for this (unless it's not possible due to low-level kernel building requirements (in which case they should have a machine for their own anyway)) Have a single jail for system-ports building which afterwards copies the package to /pkg directory which is via nullfs mapped on the /pkg directories of the other jails. Edwin -- Edwin Groothuis |Personal website: http://www.mavetju.org [EMAIL PROTECTED]| Weblog: http://www.mavetju.org/weblog/ ___ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to "[EMAIL PROTECTED]"
FreeBSD Port: sdl-1.2.11_2,2
hi, [please could you cc me as I'm not subscribed, thanks] I'm trying to install projectm (http://projectm.sourceforge.net/). Instructions say install sdl-1.3 due to some feature being necessary. Can I keep sdl-1.2 and install sdl-1.3 without them conflicting? Any pointers for how to do it, or an alternative approach? Thanks Chris ___ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: FreeBSD Port: sdl-1.2.11_2,2
Chris Whitehouse wrote: > hi, > > [please could you cc me as I'm not subscribed, thanks] > > I'm trying to install projectm (http://projectm.sourceforge.net/). > Instructions say install sdl-1.3 due to some feature being necessary. > Can I keep sdl-1.2 and install sdl-1.3 without them conflicting? Any > pointers for how to do it, or an alternative approach? > > Thanks > > Chris > ___ > freebsd-ports@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-ports > To unsubscribe, send any mail to "[EMAIL PROTECTED]" > Chris, You could get sdl-1.3 from www.libsdl.org (I think you need to use SVN to get it). Then, when you configure make sure you specify a special prefix, such as: cd sdl-1.3 ./configure --prefix=/usr/local/libsdl13-root ...other args... make make install Then, when you build mproject, make sure that you add "--with-sdl-prefix=/usr/local/libsdl13-root" to the configure arguments, to tell it where SDL 1.3 is located. When you run the program, make sure that you set the LD_LIBRARY_PATH environment variable to /usr/local/libsdl13-root/lib, so that it looks for the SDL libraries there before looking in the normal library path. HTH, -- Coleman Kane ___ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: What's a "good" way to handle installation of conflicting ports?
Interesting question... On Sunday 17 February 2008 20:52:59 David Wolfskill wrote: > I've been asked to come up with at least an interim approach -- > that can be implemented within a few days -- to allow the SAs at > my new job to install conflicting ports on the same machine. > > I can think of some approaches, but I'd prefer to use one that doesn't > suck too much, and that doesn't impede the transition to something better. > I would also like to continue to be able to make use of the FreeBSD > "ports" system, and be able to take advantage of the ports collection, > such as dependency-tracking. > > Their (the SAs) stated preferred approach is to use GNU stow > (sysutils/stow), though I've not used it previously, and I'm not > quite clear on just how that would work in practice -- and still provide > the benefits of the FreeBSD "ports" system as mentioned above. (They > use it for the Linux machines; not sure about the Solaris machines.) Say no to stow. You might get a working install but not working ports eventually. Stow essentially means many symlinks (a la appdirs). > > The catalyst for the exercise is that we have some pools of machines > for developers to use; some of the developers wish to use > editors/xemacs; some wish to use editors/emacs -- on the same machine. > (Given the requirement, it's OK for the affected folks to need to adjust > search, library, and man paths.) I don't think you're going to get a generic solution, because conflicting ports can have different reasons why they're conflicting. - installs (some) same files. In many cases one (certainly a developer!) can just take his chances and often it will only complain on deinstall at pkg-plist - conflicting binaries (names). Not nice, but could be changed on a case-by-case basis for example with a wrapper script - conflicting shared libraries (names and/or versions). Bad, but this too could be done case-by-case (ldconfig, path, ..) - conflicting headers. If this is a concern, fire them :) So, what I'm saying, it's much more likely that examining the actual conflicts that occur and dealing with them then (you also have the option of saying "don't do that" occasionally!) is easier and faster than trying to do some generic out-of-ports thing. You can trivially create local ports, or just rename official ones and change them and 'make install' them. If many of your devs do that, I suggest setting up one local repo for it (or just a NFS share...). So I would rather organize the case-by-case hacks that some devs may come up with in a way that they are somewhere central and useable and in sync for all (plus you offload the problem of solving their hack to them ;-) A generalized (e.g. stowed) circumvention of ports dealing with the very spots where the port maintainers concede that there's conflict (in other words: where the shit is known to hit the fan) is not going to be viable IMHO. > > (I haven't been in the new position long enough to know why folks can't > just each use their own desktop/workstations, configured however each > one sees fit. Even so, I suppose that there might be a developer out > there who might want conflicting ports on his dektop -- I've had that > request before ... or rather, a request that implied that: One of the > developers at a previous place of employment was distressed when he > determined that he was unable to install every port in the ports > collection on his desktop machine. In that case, his local disk storage > gave out before he ran into the "conflicts" issue, but I'm sure that > would have come up eventually.) > > (I've subscribed to -ports@, at least for now, so there's no need to > copy me on messages sent to the list.) > > Anyway, thanks in advance for suggestions -- even pointing out why a > certain approach would be inadvisable would be helpful. > > Peace, > david Just my thoughts. Cheers, Dan ___ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: ntop does not compile on 7.0-RC2
On Sun, 2008-02-17 at 17:20 +0100, Helmut Schneider wrote: > Hi, > > ntop stops with: > [...] > then mv -f ".deps/iface.Tpo" ".deps/iface.Plo"; else rm -f > ".deps/iface.Tpo"; exit 1; fi > cc -DHAVE_CONFIG_H -I. -I. -I. -I. -I/usr -I/usr/include -DINET6 -O2 > -Dfreebsd7 > -DAPPLLIB_EXP=/usr/local/lib/perl5/5.8.8/BSDPAN -DHAS_FPSETMASK > -DHAS_FLOATINGPOINT_H > -fno-strict-aliasing -pipe -Wdeclaration-after-statement > -I/usr/local/lib/perl5/5.8.8/mach/CORE > -I. -I/usr/local/include -DFREEBSD -I/usr/local/include -I/usr/local/include > -I/usr/include -g -O2 -fno-strict-aliasing -pipe -I/usr/local/include -g > -Wshadow > -Wpointer-arith -Wmissing-prototypes -Wmissing-declarations -Wnested-externs > -fPIC -DPIC -MT iface.lo -MD -MP -MF .deps/iface.Tpo -c > iface.c -fPIC -DPIC -o .libs/iface.o > In file included from /usr/local/include/net-snmp/utilities.h:54, > from /usr/local/include/net-snmp/net-snmp-includes.h:78, > from iface.c:766: > /usr/local/include/net-snmp/library/container.h: In function > 'CONTAINER_FREE': > /usr/local/include/net-snmp/library/container.h:416: error: lvalue required > as left operand of assignment > In file included from /usr/local/include/net-snmp/mib_api.h:24, > from /usr/local/include/net-snmp/net-snmp-includes.h:81, > from iface.c:766: > /usr/local/include/net-snmp/library/parse.h:32:1: warning: "MAXLABEL" > redefined > In file included from /usr/include/arpa/nameser.h:579, > from ntop.h:321, > from iface.c:26: > /usr/include/arpa/nameser_compat.h:104:1: warning: this is the location of > the previous definition > gmake[2]: *** [iface.lo] Error 1 > gmake[2]: Leaving directory `/usr/ports/net/ntop/work/ntop-3.3' > gmake[1]: *** [all-recursive] Error 1 > gmake[1]: Leaving directory `/usr/ports/net/ntop/work/ntop-3.3' > gmake: *** [all] Error 2 > *** Error code 2 > > Stop in /usr/ports/net/ntop. > *** Error code 1 > > Stop in /usr/ports/net/ntop. > > Bug or a local problem? > Local problem. I don'thave a net-snmp directory installed; looks like some library there is clobbering a needed definition. > Thanks, Helmut > ___ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: Asterisk-Addons 1.4.5 still wont build
Phillip N. wrote: Hello all. Unfortunatly i dont use h323 so i cannot test if all this really works. What are the last patches need to make asterisk-addons compile with the codec negotiation patch, that works? Here they are: http://lists.digium.com/pipermail/asterisk-dev/2008-February/031932.html You can also see Maxim's response on next message. If all compiles ok, and you guys can confirm the patch really works, we could send a pr. Yes, I'm waiting for Maxim's response. Ganbold Thanks! El mar, 12-02-2008 a las 10:07 +0800, Ganbold escribió: However I was able to compile it after making some changes to chan_h323.c and ooh323cDriver.c. ___ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to "[EMAIL PROTECTED]" -- Legalize free-enterprise murder: why should governments have all the fun? ___ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: Problems with icu - 3.8
On Sun, 17 Feb 2008 14:23:37 -0700 James <[EMAIL PROTECTED]> wrote: > > On Sun, 2008-02-17 at 21:14 +, Matthew Seaman wrote: > > -BEGIN PGP SIGNED MESSAGE- > > Hash: SHA256 > > > > Atanas Gendov wrote: > > > Greetings to all from FreeBSD Ports!!! :) > > > I have some problems with icu - 3.8. After portupgrade of icu and some > > > others packages I can't start Gnome. Because of Gnome needs module from > > > icu > > > - 3.6. Unfortunately there is no new port for gdm which doesn't have > > > depends > > > on icu-3.6. > > > > Lots of people are getting bitten by the effects of the bump in the > > libicu* shlib ABI version numbers -- there really should be a note > > in UPDATING about it. It affects all sorts of different packages -- > > I've even got one system where it took out OpenLDAP. > > Do you know who to ask for the note? I was bitten by it, but fortunately there > had just been a large thread in questions@ about it. It does seem to be a > common issue. > > James Why are so many people are bitten by this? Is that the jobs of port-upgrading tool to safe copy these libraries to compat so that all programs using the old libraries works? Hiro ___ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: obexftp - call for testers
Hello, thank you for your feedback. For doing obex over bluetooth, obexftp needs both the (1) BD_ADDR in raw format (it's _not_ resolving literal device names) (2) the Channel (by using the -B option) So, on my K750i, which has I do something like this (I will use long options for better understanding): # get the capability list: obexftp --bluetooth `bthost -b k750ieva` --channel 6 --capability Channel 6 is OBEX File Transfer on that phone. IrMC (8 for me) will also do. You won't be succesful doing this on OBEX Object Push. If you need to find out the proper channel for your mobile, do something like sdpcontrol -a k750ieva Browse The whole point of using obexftp over obexapp is (for me), that obexapp is not able to retrieve all the telecom/ nodes, which won't show up in filebrowsing and return an error if you try to traverse the path level by level. Thatswhy you have to specify the path as a whole in 'get' command blindly to successfully retrieve them. This is AFAIK only a restriction of some (including obviously all my) mobile phones. So this is where the -S (--nopath) parameter comes handy: obexftp --bluetooth `bthost -b k750ieva` --channel 6 --nopath \ --uuid SYNCH --get telecom/devinfo.txt (You may also try telecom/pb.vcf or telecom/cal.vcs and *PLEASE* backup your contacts first! It's perfectly possible to bust your databases so all your valuable contacts go down the drain and I won't be the one to be put in charge for that.) As you see, I also need to specify the SYNCH (IRMC will also do). Please look up the manpage, cause my understanding of this rather limited (in other words: I'm just using it). One final note: my mobiles firmware obviously left the drawing table a bit, uhm, early. You may have to reset your bluetooth devices and/or the whole mobile (by removing batteries in my case :-() after doing some transfers. This is *not* a problem specific to obexftp. Its happening with a lot of other peers and usage scenarios too. Gruss Dierk Zitiere Alex Keda vom Sun, Feb 17, 2008 at 06:01:22PM +0300: > Peter Jeremy ?: > >On Fri, Feb 15, 2008 at 02:50:36PM +0100, Dierk Sacher wrote: > > > >>This is a 'works for me' port. I've only been able to test it with > >>6.2-RELEASE on i386 with only one mobile over bluetooth. I did not test > >>anything else (usb, IR ...). > >> > > > >I wouldn't mind having obexftp to talk to my phone but unfortunately > >this port doesn't work for me on 6.3-PRERELEASE/amd64 over bluetooth, > >though that could be just that I'm not driving it correctly: > > > >turion# obexftp -b PeterPhone -v -x > >Scanning for PeterPhone ... > >Browsing PeterPhone ... > >Connecting...failed: connect > >Still trying to connect > >Connecting...failed: connect > >Still trying to connect > >Connecting...failed: connect > >Still trying to connect > >turion# > > > >And hcidump shows no data so I suspect it's not even trying BlueTooth. > >ktrace shows that it's not searching /etc/bluetooth/hosts but directly > >specifying the BD_ADDR has no improvement and the connect() is returning > >EINVAL. > > > With - nokia-6085 - obexapp-1.4.8 work correct. > But this port: > > ussr$ obexftp --bluetooth nokia-6085 -x > Scanning for nokia-6085 ... > Browsing nokia-6085 ... > Connecting...failed: connect > Still trying to connect > Connecting...failed: connect > Still trying to connect > Connecting...failed: connect > Still trying to connect > > ussr$ obexftp --bluetooth siemens-sl56 -x > Scanning for siemens-sl56 ... > Browsing siemens-sl56 ... > Connecting...failed: connect > Still trying to connect > Connecting...failed: connect > Still trying to connect > Connecting...failed: connect > Still trying to connect > > ussr$ obexftp --bluetooth siemens-sl56 -X > Scanning for siemens-sl56 ... > Browsing siemens-sl56 ... > Connecting...failed: connect > Still trying to connect > Connecting...failed: connect > Still trying to connect > Connecting...failed: connect > Still trying to connect > > ussr$ obexftp --bluetooth nokia-6085 -X > Scanning for nokia-6085 ... > Browsing nokia-6085 ... > Connecting...failed: connect > Still trying to connect > Connecting...failed: connect > Still trying to connect > Connecting...failed: connect > Still trying to connect > > ussr$ uname -a > FreeBSD ussr.lissyara.int.otradno.ru 6.3-RELEASE FreeBSD 6.3-RELEASE #0: > Sun Jan 20 09:47:57 MSK 2008 > [EMAIL PROTECTED]:/usr/obj/usr/src/sys/color-console > i386 > > ussr$ obexftp --bluetooth siemens-sl56 -p > /usr/home/lissyara/Desktop/nokia_freebsd.txt > Scanning for siemens-sl56 ... > Browsing siemens-sl56 ... > Connecting...failed: connect > Still trying to connect > Connecting...failed: connect > Still trying to connect > Connecting...failed: connect > Still trying to connect > > ___ > freebsd-ports@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-ports > To unsubscribe, send any mail to "[EMAIL PROTECTED]" -- |+
Automotive ERP Software
Dear Acc Manager, It my pleasure to introduce my most widely used Automotive ERP system to you and with all respecting for your attention. I’m inviting you to take a look of our indoor demo of the system on current period We have office in Dubai ,KSA and Kuwait I wish that system that serves 30% of automotive business in gulf region fits with your business needs For more information about the ERP and who use it in gulf please visit the link below and waiting for your soon feedback. The ERP Modules Financial Management Sys. Vehicle Management Sys. Inventory Management Sys. Service Management Sys Rental Management Sys. Asset Management Sys. Consumer Finance Sys. Insurance Management Sys. Treasury Management Sys. Project Management Sys. Best regards, Ahmad Samir Business Development Manager Dhow Information System W.L.L. Tel: +965 224-0808 Ext.6621 Mob: +965 9862-853 Fax: +965 434-2826 P.O. Box 485 Safat 13005 - Kuwait www.dhowsoft.com This email and any files transmitted with it are confidential and intended solely for the use of the individual or entity to which they are addressed. If you have received this email in error, please notify the system manager. This message contains confidential information and is intended only for the individual named. If you are not the named addressee you should not disseminate, distribute or copy this e-mail. ___ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: Automotive ERP Software
Hi, sounds good. Is there also a FreeBSD port available? Erich ahmed felfel wrote: Dear Acc Manager, It my pleasure to introduce my most widely used Automotive ERP system to you and with all respecting for your attention. I’m inviting you to take a look of our indoor demo of the system on current period We have office in Dubai ,KSA and Kuwait I wish that system that serves 30% of automotive business in gulf region fits with your business needs For more information about the ERP and who use it in gulf please visit the link below and waiting for your soon feedback. The ERP Modules Financial Management Sys. Vehicle Management Sys. Inventory Management Sys. Service Management Sys Rental Management Sys. Asset Management Sys. Consumer Finance Sys. Insurance Management Sys. Treasury Management Sys. Project Management Sys. Best regards, Ahmad Samir Business Development Manager Dhow Information System W.L.L. Tel: +965 224-0808 Ext.6621 Mob: +965 9862-853 Fax: +965 434-2826 P.O. Box 485 Safat 13005 - Kuwait www.dhowsoft.com This email and any files transmitted with it are confidential and intended solely for the use of the individual or entity to which they are addressed. If you have received this email in error, please notify the system manager. This message contains confidential information and is intended only for the individual named. If you are not the named addressee you should not disseminate, distribute or copy this e-mail. ___ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to "[EMAIL PROTECTED]" ___ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to "[EMAIL PROTECTED]"
