Re: end of life sysutils/zap
Hello! On Sun, Jul 24, 2005 at 08:21:29PM -0400, Ian Darwin wrote: Hannah Schroeter and tedu both spoke up in favor of keeping it, so I'll leave it be. Many thanks. Ian Kind regards, Hannah.
Re: SECURITY UPDATE: fetchmail-6.2.5.2
On Mon, Jul 25, 2005 at 10:28:45AM +0200, Bernd Ahlers wrote: Hi! Attached is an update to fetchmail-6.2.5.2. This includes an important security fix! Works for me on i386 and amd64. port changes: - update MASTER_SITES and HOMEPAGE (fetchmail moved to belios.de) - patch-driver_c not needed anymore (fixed in upstream) ChangeLog: http://developer.berlios.de/project/shownotes.php?release_id=6617 Security: CAN-2005-2335. http://fetchmail.berlios.de/fetchmail-SA-2005-01.txt Please test and comment. Bernd Works for me on 3.7-release i386, thanks. Alf
Re: koffice-1.4.0
Hi, I have a port of koffice 1.4 ready to go. I'm just really annoyed at a bug in, of all things, ld.so, which actually prevents karbon from working at all... I was hoping to fix it, but I may end committing this. Hi marc, Thanks for your fast reply. What was your opinion with comitting to -stable also? Best reguards Edd
Re: NEW : sane-backends-1.0.15
Hello, I tried staticaly linked sane-backends-1.0.15. OpenBSD 3.7 GENERIC#0 i386 # dmesg | grep uscanner uscanner0 at uhub0 port 2 uscanner0: UMAX Data Systems Astra 1220U, rev 1.00/1.00, addr 2 # sane-find-scanner # No SCSI scanners found. If you expected something different, make sure that # you have loaded a SCSI driver for your SCSI adapter. found USB scanner (UNKNOWN vendor and product) at device /dev/uscanner0 # Your USB scanner was detected. It may or may not be supported by # SANE. Try scanimage -L and read the backend's manpage. # `UNKNOWN vendor and product' means that there seems to be a scanner at this # device file but the vendor and product ids couldn't be identified. # Currently identification only works with Linux versions = 2.4.8. You may # need to configure your backend manually, see the backend's manpage. # Not checking for parallel port scanners. # Most Scanners connected to the parallel port or other proprietary ports # can't be detected by this program. # scanimage -L device `test:0' is a Noname frontend-tester virtual device device `test:1' is a Noname frontend-tester virtual device # scanimage -d umax1220u:/dev/uscanner0 scanimage: open of device umax1220u:/dev/uscanner0 failed: Operation not supported ... [dll] sane_open: trying to open `umax1220u:/dev/uscanner0' [dll] init: initializing backend `umax1220u' [dll] init: backend `umax1220u' is version 1.0.1 scanimage: open of device umax1220u:/dev/uscanner0 failed: Operation not supported [dll] sane_exit: exiting [dll] sane_exit: calling backend `umax1220u's exit function [dll] sane_exit: finished Where could be the problem? --- http://www.one.lv - Tavs mobilais e-pasts! Tagad lasi savu e-pastu ar mobilo telefonu - wap.one.lv!
Re: kismet-port
On (25/07/05 08:41), Matthias Kilian wrote: If the (inofficial) kismet-2005-07-BSD will stay available for download on the kismet site, this port can IMHO be committed. No. We will use the offical release. Otherwise, some additional effort is needed, since the brand-new kismet-2005-07-R1 failed to build tomorrow (I'm very short of time, so no details for now). Yes, they placed a wrong #endif in pcapsource.cc. I've included a patch which fixes the problem. So with my modifications we can use kismet-2005-07-R1. The port is attached. kismet.tar.gz Description: application/tar-gz
Re: NEW: devel/automake/1.9
Andreas Vögele dixit: automake-1.9: automake-1.9: ## Internal Error ## automake-1.9: automake-1.9: unrequested trace `include' Ah, I fixed that long ago. From the MirPorts patch-automake_in: @@ -4651,6 +4653,7 @@ sub scan_autoconf_traces ($) _LT_AC_TAGCONFIG = 0, m4_include = 1, m4_sinclude = 1, + include = 1, sinclude = 1, ); PS: Thanks for metaauto ;) bye, //mirabile -- I believe no one can invent an algorithm. One just happens to hit upon it when God enlightens him. Or only God invents algorithms, we merely copy them. If you don't believe in God, just consider God as Nature if you won't deny existence. -- Coywolf Qi Hunt
SECURITY UPDATE: security/clamav
hi, http://www.security.nnov.ru/Jdocument282.html update for clamav 0.86.2 Have fun! --mpech clamav_update.patch Description: Binary data
Re: Create my own shell?
On 25/07/05, Jon Drews [EMAIL PROTECTED] wrote: On 7/25/05, Abel Talaversn Estevez [EMAIL PROTECTED] wrote: Hi all, I need to create a particular but simple shell for a firewall running OpenBSD 3.6. The idea is create a user whose shell is a very limited one. This shell or command line interpreter (CLI) must have permissions only in the home directory. Hi: Operating ksh in restricted mode may fulfill your needs. Here from the man page for ksh (this is the public domain Korn Shell in OpenBSD): -r Restricted shell. A shell is ``restricted'' if this option is used or if either the basename the shell was invoked with or the SHELL parameter match the pattern ``*r*sh'' (e.g. rsh, rksh, rpdksh). The following restrictions come into effect after the shell processes any profile and ENV files: o The cd command is disabled. o The SHELL, ENV, and PATH parameters cannot be changed. o Command names can't be specified with absolute or relative paths. o The -p option of the built-in command command can't be used. o Redirections that create files can't be used (i.e. `', `|', `', `'). -- Kind regards, Jonathan Hi, If you want to create your own shell (although I'm sure you don't have to), then this book will tell you how. http://www.amazon.com/exec/obidos/tg/sim-explorer/explore-items/-/0131411543/0/101/1/none/purchase/ref%3Dpd%5Fsxp%5Fr0/104-3894848-1007109 It's a good read too. Best Regards Edd
building mplayer with no_x11 flavor
Hi building mplayer with no_x11 seems to have a dependency of lame, which seems to be trying to install lame, but requiring the gtk and gdk stuff. I presume the dependency of mplayer with flavor no_x11 should be lame with flavor no_x11? I presume that can be specified/fixed in the mplayer port, I'm not an expert at the ports system otherwise I'd submit a patch. Sorry also, second question - shouldn't mplayer be under /usr/ports/multimedia instead of /usr/ports/x11 since it's not always ran as an X app? === Returning to build of lame-3.96.1p0 === lame-3.96.1p0 depends on: gtk.1.2,gdk.1.2 (gtk+-*) - gtk.1.2 missing... gdk.1.2 missing... gtk.1.2 missing... gdk.1.2 missing... === Verifying install for gtk.1.2,gdk.1.2 (gtk+-*) in x11/gtk+ === gtk+-1.2.10p3 uses X11, but /usr/X11R6 not found. === Returning to build of lame-3.96.1p0 Dependency check failed *** Error code 1 thanks b Start your day with Yahoo! - make it your home page http://www.yahoo.com/r/hs
UPDATE: x11/fvwm2
hi, Initial fun from [EMAIL PROTECTED] Have fun. --mpech fvwm2_update.patch Description: Binary data
Re: building mplayer with no_x11 flavor
* steven mestdagh [2005-07-25]: why don't you just fetch the mplayer...-no_x11.tgz package and install it with pkg_add(1) ? And how would that help? The package still depends on lame which in turn depends on X11. Nikolay
Re: building mplayer with no_x11 flavor
* b h [2005-07-25]: building mplayer with no_x11 seems to have a dependency of lame, which seems to be trying to install lame, but requiring the gtk and gdk stuff. I Does this mean you asked the port's maintainer and he didn't answer your question? presume the dependency of mplayer with flavor no_x11 should be lame with flavor no_x11? I presume that can Yes. be specified/fixed in the mplayer port, I'm not an expert at the ports system otherwise I'd submit a patch. Sorry That's what maintainers are for. also, second question - shouldn't mplayer be under /usr/ports/multimedia instead of /usr/ports/x11 since it's not always ran as an X app? We don't move ports around. multimedia/ wasn't around when mplayer was imported. Nikolay
Re: kismet-port
Robert Nagy [Mon Jul 25, 2005 at 03:41:12PM +0200] wrote: Yes, they placed a wrong #endif in pcapsource.cc. I've included a patch which fixes the problem. So with my modifications we can use kismet-2005-07-R1. The port is attached. Works for me on i386 with an ural(4) wifi card. I've applied a small fix for the default kismet.conf. Updated port attached. Please test. Bernd kismet.tgz Description: application/tar-gz
Re: SECURITY UPDATE: fetchmail-6.2.5.2
On Mon, Jul 25, 2005 at 10:28:45AM +0200, Bernd Ahlers wrote: Hi! Attached is an update to fetchmail-6.2.5.2. This includes an important security fix! Works for me on i386 and amd64. commited. thanks, f.-
Re: SECURITY UPDATE: security/clamav
On Mon, Jul 25, 2005 at 05:21:59PM +0300, Mike Pechkin wrote: http://www.security.nnov.ru/Jdocument282.html update for clamav 0.86.2 Working fine on i386 and sparc64, thanks. Regards, Simon
Re: kismet-port
Bernd Ahlers [EMAIL PROTECTED] wrote: Works for me on i386 with an ural(4) wifi card. My ral(4) doesn't see any networks other than the one it was already associated with. It's the same for ifconfig -M, though. Is this a known driver limitation? iwi(4) is fine. -- Christian naddy Weisgerber [EMAIL PROTECTED]
Re: kismet-port
On Mon, Jul 25, 2005 at 07:02:40PM +0200, Bernd Ahlers wrote: Robert Nagy [Mon Jul 25, 2005 at 03:41:12PM +0200] wrote: Yes, they placed a wrong #endif in pcapsource.cc. I've included a patch which fixes the problem. So with my modifications we can use kismet-2005-07-R1. The port is attached. Works for me on i386 with an ural(4) wifi card. I've applied a small fix for the default kismet.conf. Updated port attached. Please test. Works fine on i386-current with iwi.
NEW: graphics/pstoedit
hello, Here is a port for pstoedit. from DESCR: - pstoedit translates PostScript and PDF graphics into other vector formats. - Works fine on i386, dumps core on sparc64 after an abort trap error. If anyone knows how to fix that... Also, if anyone knows a nicer fix than the post-install part to have pstoedit use the libp2edrvstd.so.0.0 library, I would like to hear it. please test/comment. thanks, steven. pstoedit.tgz Description: application/tar-gz
Re: UPDATE: lang/gprolog
Let me add that lang/gprolog is currently broken in the tree (doesn't compile). This should fix that but gprolog will be a bit unstable. It would be nice if someone could test it on stable to see if it's another bug(s) revealed by the new malloc with mmap. Cheers, -- nuno
