Re: foomatic-db -= MESSAGE

[Antoine Jacoutot]

On Sun, 14 Dec 2008, Jacob Meuser wrote:
> well, I looked at the MESSAGE files as well as DESCR, and for all but
> the foomatic-db-gutenprint, the info in MESSAGE seemed just as
> appropriate in DESCR, and didn't make DESCR overly long.
> 
> but yes, a "plan" or "guideline" would be nice.  I mostly did this
> because I didn't want to drop them "in a messy state", and because
> I thought it made sense, regardless.

I'd say let's not touch it for now.
Personnaly, I like the /usr/local/share/README.OpenBSD/pkgname approach 
with a small warning at the end of pkg_add+pkg_info to point people to 
these files.

-- 
Antoine

gnome-commander

[Markus Bergkvist]

Hi

Before I start, is anyone else working on gnome-commander?
http://www.nongnu.org/gcmd/

/Markus

Re: foomatic-db -= MESSAGE

[Stuart Henderson]

On 2008/12/14 23:40, Jacob Meuser wrote:
> On Sun, Dec 14, 2008 at 11:30:04PM +, Jacob Meuser wrote:
> > On Sun, Dec 14, 2008 at 11:13:14PM +, Stuart Henderson wrote:
> 
> > > The problem with putting this in DESCR is that people who already know
> > > what the software does are unlikely to read it, and historically we 
> > > haven't
> > > put much really useful information there, so people aren't trained to look
> > > there.
> > 
> > based on the original "complaint", I disagree.
> 
> and of course, your suggestion to mention the message files in plain
> pkg_info, which seemed popular ...

well, I like it obviously ... even if it's just as a stopgap until
MESSAGEs are clean enough to display by default (it's not too big a
job, it may be pushing it for 4.5 unless there's a lot of help,
but I think 4.6 would be a realistic target).

Re: foomatic-db -= MESSAGE

[Stuart Henderson]

On 2008/12/14 23:30, Jacob Meuser wrote:
> On Sun, Dec 14, 2008 at 11:13:14PM +, Stuart Henderson wrote:
> > On 2008/12/14 22:47, Jacob Meuser wrote:
> > > On Sun, Dec 14, 2008 at 12:04:54PM +0100, Antoine Jacoutot wrote:
> > > > On Sun, 14 Dec 2008, Jacob Meuser wrote:
> > > > 
> > > > > 
> > > > > ok?
> > > > 
> > > > Well... does this mean that now we have 3 different places to look for 
> > > > info ?
> > > > DESCR, MESSAGE and README.OpenBSD?
> > > > 
> > > > It seems even worse now and I think it shouldn't be touched before we 
> > > > come up with some kind of consensus over this.
> > > 
> > > well, I looked at the MESSAGE files as well as DESCR, and for all but
> > > the foomatic-db-gutenprint, the info in MESSAGE seemed just as
> > > appropriate in DESCR, and didn't make DESCR overly long.
> > 
> > The problem with putting this in DESCR is that people who already know
> > what the software does are unlikely to read it, and historically we haven't
> > put much really useful information there, so people aren't trained to look
> > there.
> 
> based on the original "complaint", I disagree.

If you're looking to fix a problem, I agree it's one of the first places
you'll look, but at first installation ...? Isn't that just making people
do extra work for something which is shown automatically now?

> > I'd quite like to have MESSAGE separated from updates somehow...what is
> > useful at installation time is rarely useful at update time, and vice-versa.
> 
> well, for the case of cups, I kind of disagree.  updating base will
> overwrite the cups "replacement" files.  usually a package update
> is preceeded by an update of base.  but that is of course a special
> case.

indeed, but in those few cases you could list the information in both
places. Separating them would give less spam at update time (like the
various subtly different recommendations for inclusion in rc.local
which *are* helpful initially, but you don't need to know later).
Then the more important information would be easier to notice.

> otoh, if there is one or two easy places to look (pkg_info foo
> or a README.OpenBSD), then there is no need for another place.

If I install OpenBSD I get some basic information showing me where
to look to learn more about using it. Shouldn't I get something similar
when I install a package if it's at all non-obvious? Even if it just
points me at a readme, a good introductory manual page, or some
docs (even on the web) I think this is a good thing.

> I just really don't find MESSAGE files useful.  and it seems lots
> of long time users don't even know about them,

they surely know things are sometimes displayed at pkg_add time,
and it's reasonable to assume that they're stored somewhere..

> or go digging in /var/db/pkg to find them.

Even knowing that there's a pkg_info option to display it, I never
remember the letter (and the old one is listed as deprecated and the
new one is pages down the man page) so I find it's easier to just
look in /var/db/pkg where I know for sure I'll find it...

NEW: games/quake3-data

[Ryan Freeman]

hello,

attached is a port that assists in the installation of required
quake3 data files. it fetches the latest point release and also
instructs to copy the main pak0 datafile from your original
installation media. also contained is the option to install the
team arena missionpack; i haven't yet tested that it works as i
don't feel like going out in the snow into storage to find that 
disc but it should work great!

comments/suggestions?

-ryan


quake3-data.tgz
Description: application/tar-gz

NEW: games/ioquake3

[Ryan Freeman]

hello,

attached is a port of the icculus.org quake3 engine, builds a
reasonable default engine including client, server, and game
libraries for the original game and missionpack. works excellent
with the soon-to-be-posted quake3-data port as well.

one note, i built from a svn snapshot which i have made into a tarball
and am hosting locally, so fetching the distfile won't be insanely fast.

i've been running this for ages, including another q3a mod, urban terror,
without any problems.

comments/suggestions?

-ryan


ioquake3.tgz
Description: application/tar-gz

Re: foomatic-db -= MESSAGE

[Jacob Meuser]

On Sun, Dec 14, 2008 at 11:30:04PM +, Jacob Meuser wrote:
> On Sun, Dec 14, 2008 at 11:13:14PM +, Stuart Henderson wrote:

> > The problem with putting this in DESCR is that people who already know
> > what the software does are unlikely to read it, and historically we haven't
> > put much really useful information there, so people aren't trained to look
> > there.
> 
> based on the original "complaint", I disagree.

and of course, your suggestion to mention the message files in plain
pkg_info, which seemed popular ...

-- 
jake...@sdf.lonestar.org
SDF Public Access UNIX System - http://sdf.lonestar.org

Re: foomatic-db -= MESSAGE

[Jacob Meuser]

On Sun, Dec 14, 2008 at 11:13:14PM +, Stuart Henderson wrote:
> On 2008/12/14 22:47, Jacob Meuser wrote:
> > On Sun, Dec 14, 2008 at 12:04:54PM +0100, Antoine Jacoutot wrote:
> > > On Sun, 14 Dec 2008, Jacob Meuser wrote:
> > > 
> > > > 
> > > > ok?
> > > 
> > > Well... does this mean that now we have 3 different places to look for 
> > > info ?
> > > DESCR, MESSAGE and README.OpenBSD?
> > > 
> > > It seems even worse now and I think it shouldn't be touched before we 
> > > come up with some kind of consensus over this.
> > 
> > well, I looked at the MESSAGE files as well as DESCR, and for all but
> > the foomatic-db-gutenprint, the info in MESSAGE seemed just as
> > appropriate in DESCR, and didn't make DESCR overly long.
> 
> The problem with putting this in DESCR is that people who already know
> what the software does are unlikely to read it, and historically we haven't
> put much really useful information there, so people aren't trained to look
> there.

based on the original "complaint", I disagree.

> I'd quite like to have MESSAGE separated from updates somehow...what is
> useful at installation time is rarely useful at update time, and vice-versa.

well, for the case of cups, I kind of disagree.  updating base will
overwrite the cups "replacement" files.  usually a package update
is preceeded by an update of base.  but that is of course a special
case.  otoh, if there is one or two easy places to look (pkg_info foo
or a README.OpenBSD), then there is no need for another place.

I just really don't find MESSAGE files useful.  and it seems lots
of long time users don't even know about them, or go digging in
/var/db/pkg to find them.

-- 
jake...@sdf.lonestar.org
SDF Public Access UNIX System - http://sdf.lonestar.org

Re: foomatic-db -= MESSAGE

[Stuart Henderson]

On 2008/12/14 22:47, Jacob Meuser wrote:
> On Sun, Dec 14, 2008 at 12:04:54PM +0100, Antoine Jacoutot wrote:
> > On Sun, 14 Dec 2008, Jacob Meuser wrote:
> > 
> > > 
> > > ok?
> > 
> > Well... does this mean that now we have 3 different places to look for 
> > info ?
> > DESCR, MESSAGE and README.OpenBSD?
> > 
> > It seems even worse now and I think it shouldn't be touched before we 
> > come up with some kind of consensus over this.
> 
> well, I looked at the MESSAGE files as well as DESCR, and for all but
> the foomatic-db-gutenprint, the info in MESSAGE seemed just as
> appropriate in DESCR, and didn't make DESCR overly long.

The problem with putting this in DESCR is that people who already know
what the software does are unlikely to read it, and historically we haven't
put much really useful information there, so people aren't trained to look
there.

I'd quite like to have MESSAGE separated from updates somehow...what is
useful at installation time is rarely useful at update time, and vice-versa.

Re: foomatic-db -= MESSAGE

[Jacob Meuser]

On Sun, Dec 14, 2008 at 12:04:54PM +0100, Antoine Jacoutot wrote:
> On Sun, 14 Dec 2008, Jacob Meuser wrote:
> 
> > 
> > ok?
> 
> Well... does this mean that now we have 3 different places to look for 
> info ?
> DESCR, MESSAGE and README.OpenBSD?
> 
> It seems even worse now and I think it shouldn't be touched before we 
> come up with some kind of consensus over this.

well, I looked at the MESSAGE files as well as DESCR, and for all but
the foomatic-db-gutenprint, the info in MESSAGE seemed just as
appropriate in DESCR, and didn't make DESCR overly long.

but yes, a "plan" or "guideline" would be nice.  I mostly did this
because I didn't want to drop them "in a messy state", and because
I thought it made sense, regardless.

> On a side note, I can take maintainership for foomaric-* and gutenprint 
> if you want to drop them.

that would be great, thanks!

-- 
jake...@sdf.lonestar.org
SDF Public Access UNIX System - http://sdf.lonestar.org

Re: usr/ports as a symlink?

[Jacob Meuser]

On Sun, Dec 14, 2008 at 05:39:21PM +0100, Pierre Riteau wrote:

> This seems to be fixed by rev. 1.61 of PackageRepository.pm.
> Thank you Marc.
> 
> Jason, Jacob, can you confirm?

yes, it seems to have fixed the problems I was having.

-- 
jake...@sdf.lonestar.org
SDF Public Access UNIX System - http://sdf.lonestar.org

UPDATE: lang/scheme48

[Aaron W. Hsu]

Update Email address for Maintainer.

-- 
Aaron W. Hsu  | 
"Government is the great fiction, through which everybody endeavors to
live at the expense of everybody else." -- Frederic Bastiat
+++ ((lambda (x) (x x)) (lambda (x) (x x))) ++

Index: Makefile
===
RCS file: /cvs/ports/lang/scheme48/Makefile,v
retrieving revision 1.3
diff -u -r1.3 Makefile
--- Makefile19 Aug 2008 22:20:40 -  1.3
+++ Makefile14 Dec 2008 20:27:50 -
@@ -2,13 +2,13 @@
 
 COMMENT=   Scheme Underground's implementation of R5RS
 
-V= 1.8
+V= 1.8p0
 DISTNAME=  scheme48-$V
 CATEGORIES=lang
 
 HOMEPAGE=  http://www.s48.org/
 
-MAINTAINER=Aaron Hsu 
+MAINTAINER=Aaron Hsu 
 
 # 3-clause BSD
 PERMIT_PACKAGE_CDROM=  Yes

Re: pear packages

[Stuart Henderson]

On 2008/12/14 19:20, LÉVAI Dániel wrote:
> On Sunday 14 December 2008 19.11.50 you wrote:
> > * LÉVAI Dániel wrote:
> > > Hi!
> > >
> > > What is the way of handling pear package upgrades? Is it safe to
> > > use pear upgrade-all, or should one stay with ports, and wait for
> > > an update there?
> >
> > I'd suggest to stay with packages.  For which packages would you need
> > an update, btw?
> >
> I was just trying to use Fileinfo, which is not in ports, so I had to 
> mess around with pecl (what is completely new for me), and noticed the 
> upgrade parameter. I was just simply wondering...

In _most_ cases they're fairly simple to port.

Re: pear packages

[LÉVAI Dániel]

On Sunday 14 December 2008 19.11.50 you wrote:
> * LÉVAI Dániel wrote:
> > Hi!
> >
> > What is the way of handling pear package upgrades? Is it safe to
> > use pear upgrade-all, or should one stay with ports, and wait for
> > an update there?
>
> I'd suggest to stay with packages.  For which packages would you need
> an update, btw?
>
I was just trying to use Fileinfo, which is not in ports, so I had to 
mess around with pecl (what is completely new for me), and noticed the 
upgrade parameter. I was just simply wondering...

Daniel

-- 
LEVAI Daniel
PGP key ID = 0x4AC0A4B1
Key fingerprint = D037 03B9 C12D D338 4412  2D83 1373 917A 4AC0 A4B1

Re: pear packages

[Marc Balmer]

* LÉVAI Dániel wrote:
> Hi!
> 
> What is the way of handling pear package upgrades? Is it safe to use 
> pear upgrade-all, or should one stay with ports, and wait for an update 
> there?

I'd suggest to stay with packages.  For which packages would you need an
update, btw?
 
> 
> Daniel
> 
> -- 
> LEVAI Daniel
> PGP key ID = 0x4AC0A4B1
> Key fingerprint = D037 03B9 C12D D338 4412  2D83 1373 917A 4AC0 A4B1
> 
-- 
Marc Balmer, Micro Systems, Wiesendamm 2a, Postfach, CH-4019 Basel, Switzerland
http://www.msys.ch/ http://www.vnode.ch/   "In God we trust, in C we code."

pear packages

[LÉVAI Dániel]

Hi!

What is the way of handling pear package upgrades? Is it safe to use 
pear upgrade-all, or should one stay with ports, and wait for an update 
there?

Daniel

-- 
LEVAI Daniel
PGP key ID = 0x4AC0A4B1
Key fingerprint = D037 03B9 C12D D338 4412  2D83 1373 917A 4AC0 A4B1

Re: usr/ports as a symlink?

[Pierre Riteau]

On Thu, Dec 11, 2008 at 12:21:24AM +0100, Pierre Riteau wrote:
> On Tue, Dec 02, 2008 at 09:29:35PM -0500, Jason Beaudoin wrote:
> > On Tue, Dec 2, 2008 at 11:34 AM, Marc Espie  wrote:
> > > On Tue, Dec 02, 2008 at 04:26:26AM +, Jacob Meuser wrote:
> > >> I've had /usr/ports as a symlink for years too.  I started noticing
> > >> the 0 byte packages fairly recently.  figured it was transient.
> > >>
> > >> if it's now true that using a symlink for PORTSDIR is a problem,
> > >> it needs to be documented somethere.
> > >
> > > No, it needs to error out in a sensible way, like not creating 0 bytes
> > > packages, but displaying an error message.
> > >
> > > I haven't noticed anything, I surmised it's probably tied to the recent 
> > > (?)
> > > work to uniformize pkgpaths... I'll test it at some point.
> > >
> > >
> > apologies for the last (rogue) message, thank gmail. I was just
> > acknowledging that I am willing to run tests for you .
> > 
> > regards,
> > ~Jason
> > 
> 
> I can easily reproduce the problem on -current, but without using
> anything special like chroot or a /usr/ports symlink.
> 
> # cd /usr/ports/print/cups
>  
> # cat /etc/mk.conf
>  
> PKG_PATH=http://obsd.cec.mtu.edu/pub/OpenBSD/snapshots/packages/amd64/
> FETCH_PACKAGES=Yes
> # make install
> ===>  Looking for cups-1.2.7p14.tgz in $PKG_PATH - found
> Link to /usr/ports/packages/amd64/ftp/cups-1.2.7p14.tgz
> Link to /usr/ports/packages/amd64/cdrom/cups-1.2.7p14.tgz
> ===>  cups-1.2.7p14 depends on: desktop-file-utils-* - not found
> ===>  Verifying install for desktop-file-utils-* in devel/desktop-file-utils
> `/usr/ports/packages/amd64/cache//desktop-file-utils-0.15.tgz' is up to date.
> Link to /usr/ports/packages/amd64/ftp/desktop-file-utils-0.15.tgz
> Link to /usr/ports/packages/amd64/cdrom/desktop-file-utils-0.15.tgz
> ===>  desktop-file-utils-0.15 depends on: glib2-* - not found
> ===>  Verifying install for glib2-* in devel/glib2
> `/usr/ports/packages/amd64/cache//glib2-2.18.3.tgz' is up to date.
> Link to /usr/ports/packages/amd64/ftp/glib2-2.18.3.tgz
> Link to /usr/ports/packages/amd64/cdrom/glib2-2.18.3.tgz
> ===>  Looking for glib2-docs-2.18.3.tgz in $PKG_PATH - found
> Link to /usr/ports/packages/amd64/all/glib2-docs-2.18.3.tgz
> Link to /usr/ports/packages/amd64/ftp/glib2-docs-2.18.3.tgz
> Link to /usr/ports/packages/amd64/cdrom/glib2-docs-2.18.3.tgz
> ===>  Looking for glib2-fam-2.18.3.tgz in $PKG_PATH - not found
> *** Error code 1
> 
> Stop in /usr/ports/devel/glib2 (line 1419 of 
> /usr/ports/infrastructure/mk/bsd.port.mk).
> ===>  Checking files for glib-2.18.3
> >> glib-2.18.3.tar.bz2 doesn't seem to exist on this system.
> >> Fetch 
> >> ftp://ftp.no.gnome.org/pub/GNOME/sources/glib/2.18/glib-2.18.3.tar.bz2.
> 100% |**|  4722 KB00:13   
>  
> >> Size matches for /usr/ports/distfiles/glib-2.18.3.tar.bz2
> >> (SHA256) glib-2.18.3.tar.bz2: OK
> ===>  glib2-2.18.3 depends on: pcre->=7.2 - not found
> ===>  Verifying install for pcre->=7.2 in devel/pcre
> `/usr/ports/packages/amd64/cache//pcre-7.8.tgz' is up to date.
> Link to /usr/ports/packages/amd64/ftp/pcre-7.8.tgz
> Link to /usr/ports/packages/amd64/cdrom/pcre-7.8.tgz
> ===>  Installing pcre-7.8 from /usr/ports/packages/amd64/all/
> Can't find /usr/ports/packages/amd64/all/pcre-7.8.tgz
> /usr/sbin/pkg_add: /usr/ports/packages/amd64/all/pcre-7.8.tgz:Fatal error
> *** Error code 1
> 
> Stop in /usr/ports/devel/pcre (line 1455 of 
> /usr/ports/infrastructure/mk/bsd.port.mk).
> *** Error code 1
> 
> Stop in /usr/ports/devel/glib2 (line 1604 of 
> /usr/ports/infrastructure/mk/bsd.port.mk).
> *** Error code 1
> 
> Stop in /usr/ports/devel/glib2 (line 2001 of 
> /usr/ports/infrastructure/mk/bsd.port.mk).
> *** Error code 1
> 
> Stop in /usr/ports/devel/glib2 (line 1427 of 
> /usr/ports/infrastructure/mk/bsd.port.mk).
> *** Error code 1
> 
> Stop in /usr/ports/devel/glib2 (line 1427 of 
> /usr/ports/infrastructure/mk/bsd.port.mk).
> *** Error code 1
> 
> Stop in /usr/ports/devel/glib2 (line 1427 of 
> /usr/ports/infrastructure/mk/bsd.port.mk).
> *** Error code 1
> 
> Stop in /usr/ports/devel/glib2 (line 1427 of 
> /usr/ports/infrastructure/mk/bsd.port.mk).
> *** Error code 1
> 
> Stop in /usr/ports/devel/glib2 (line 1964 of 
> /usr/ports/infrastructure/mk/bsd.port.mk).
> *** Error code 1
> 
> Stop in /usr/ports/devel/glib2 (line 1455 of 
> /usr/ports/infrastructure/mk/bsd.port.mk).
> *** Error code 1
> 
> Stop in /usr/ports/devel/desktop-file-utils (line 1604 of 
> /usr/ports/infrastructure/mk/bsd.port.mk).
> *** Error code 1
> 
> Stop in /usr/ports/devel/desktop-file-utils (line 1455 of 
> /usr/ports/infrastructure/mk/bsd.port.mk).
> *** Error code 1
> 
> Stop in /usr/ports/print/cups (line 1604 of 
> /usr/ports/infrastructure/mk/bsd.port.mk).
> *** Error code 1
> 
> Stop in /usr/ports/print/cups (line 1455 

4.4-stable honeyd security update

[Ian McWilliam]

Security update for CVE-2008-3928.

http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2008-3928

http://secunia.com/advisories/31658

Most advisories I have read on this one only talk about the file 
'scripts/test.sh'. 'scripts/web.sh' seems vulnerable too, so I have 
patched for that case accordingly.


Ian McWilliamIndex: Makefile
===
RCS file: /cvs/ports/net/honeyd/Makefile,v
retrieving revision 1.21
diff -u -r1.21 Makefile
--- Makefile14 Feb 2008 21:36:27 -  1.21
+++ Makefile13 Dec 2008 01:26:24 -
@@ -4,7 +4,7 @@
 
 COMMENT=   utility to create virtual hosts on a network
 DISTNAME=  honeyd-1.5c
-PKGNAME=   ${DISTNAME}p2
+PKGNAME=   ${DISTNAME}p3
 CATEGORIES=net
 MASTER_SITES=  http://www.citi.umich.edu/u/provos/honeyd/ \
http://niels.xtdnet.nl/honeyd/
Index: patches/patch-scripts_test_sh
===
RCS file: patches/patch-scripts_test_sh
diff -N patches/patch-scripts_test_sh
--- /dev/null   1 Jan 1970 00:00:00 -
+++ patches/patch-scripts_test_sh   13 Dec 2008 01:26:24 -
@@ -0,0 +1,19 @@
+$OpenBSD$
+--- scripts/test.sh.orig   Sat Dec 13 11:52:43 2008
 scripts/test.shSat Dec 13 12:05:09 2008
+@@ -1,8 +1,13 @@
+ DATE=`date`
+-echo "$DATE: Started From $1 Port $2" >> /tmp/log
++TMPFILE=`mktemp -q -t honeyd_test_log.XX`
++if [ $? -ne 0 ]; then
++  echo "test.sh: Unable to create log file. mktemp failed: $?"
++  exit 1;
++fi
++echo "$DATE: Started From $1 Port $2" >> $TMPFILE
+ echo SSH-1.5-2.40
+ while read name
+ do
+-  echo "$name" >> /tmp/log
++  echo "$name" >> $TMPFILE
+ echo "$name"
+ done
Index: patches/patch-scripts_web_sh
===
RCS file: patches/patch-scripts_web_sh
diff -N patches/patch-scripts_web_sh
--- /dev/null   1 Jan 1970 00:00:00 -
+++ patches/patch-scripts_web_sh13 Dec 2008 01:26:24 -
@@ -0,0 +1,23 @@
+$OpenBSD$
+--- scripts/web.sh.origSat Dec 13 12:06:02 2008
 scripts/web.sh Sat Dec 13 12:08:17 2008
+@@ -1,5 +1,10 @@
+ #!/bin/sh
+ REQUEST=""
++TMPFILE=`mktemp -q -t honeyd_web_log.XX`
++if [ $? -ne 0 ]; then
++  echo "web.sh: Unable to create log file. mktemp failed: $?"
++  exit 1;
++fi
+ while read name
+ do
+   LINE=`echo "$name" | egrep -i "[a-z:]"`
+@@ -7,7 +12,7 @@ do
+   then
+   break
+   fi
+-  echo "$name" >> /tmp/log
++  echo "$name" >> $TMPFILE
+   NEWREQUEST=`echo "$name" | grep "GET .scripts.*cmd.exe.*dir.* HTTP/1.0"`
+   if [ ! -z "$NEWREQUEST" ] ; then
+   REQUEST=$NEWREQUEST

4.4-stable ClamAV 0.94.2 update

[kaosagnt]

Back port from current for Clamav 0.94.2

Ian McWilliamIndex: Makefile
===
RCS file: /cvs/ports/security/clamav/Makefile,v
retrieving revision 1.38
retrieving revision 1.41
diff -u -a -r1.38 -r1.41
--- Makefile8 Jul 2008 22:38:12 -   1.38
+++ Makefile13 Dec 2008 10:19:09 -  1.41
@@ -1,11 +1,11 @@
-# $OpenBSD: Makefile,v 1.38 2008/07/08 22:38:12 sthen Exp $
+# $OpenBSD: Makefile,v 1.41 2008/12/13 10:19:09 mbalmer Exp $
 
 COMMENT=   virus scanner
-DISTNAME=  clamav-0.93.3
+DISTNAME=  clamav-0.94.2
 CATEGORIES=security
-SHARED_LIBS=   clamav 8.0 \
-   clamunrar 0.0 \
-   clamunrar_iface 0.0
+SHARED_LIBS=   clamav 10.0 \
+   clamunrar 1.0 \
+   clamunrar_iface 1.0
 
 HOMEPAGE=  http://www.clamav.net/
 
@@ -19,6 +19,8 @@
 
 WANTLIB=   c milter pthread wrap z
 
+BUILD_DEPENDS= ::devel/check
+
 LIB_DEPENDS=   gmp.>=6::devel/gmp \
bz2.>=10::archivers/bzip2 \
iconv.>=4::converters/libiconv
@@ -45,7 +47,7 @@
 --disable-cr \
--with-dbdir=/var/db/clamav
 
-NO_REGRESS=Yes
+REGRESS_TARGET=check
 
 CONFIGURE_ENV+=LDFLAGS="-pthread -L/usr/lib 
-L../libclamav/.libs -L${LOCALBASE}/lib" \
CPPFLAGS="-I/usr/include -I${LOCALBASE}/include"
Index: distinfo
===
RCS file: /cvs/ports/security/clamav/distinfo,v
retrieving revision 1.26
retrieving revision 1.29
diff -u -a -r1.26 -r1.29
--- distinfo8 Jul 2008 22:38:12 -   1.26
+++ distinfo13 Dec 2008 10:19:09 -  1.29
@@ -1,5 +1,5 @@
-MD5 (clamav-0.93.3.tar.gz) = Bth/vs4GLlwGYe4HcDIIyQ==
-RMD160 (clamav-0.93.3.tar.gz) = g3kUh5DMVFyAFwnUa324djT0P2c=
-SHA1 (clamav-0.93.3.tar.gz) = ASQGE7Y5FE+o+mVYJfZYfgRKHBw=
-SHA256 (clamav-0.93.3.tar.gz) = eqmHlmcd/j21og4lZpQExORGHSpsd941Lt+Z8smJ5QA=
-SIZE (clamav-0.93.3.tar.gz) = 18242568
+MD5 (clamav-0.94.2.tar.gz) = EYHm1iNBuEcI8SbMNT9+vw==
+RMD160 (clamav-0.94.2.tar.gz) = rnXl9Ub5a3/Q923Pn0l37JW6Tbo=
+SHA1 (clamav-0.94.2.tar.gz) = gjc9JduLg2/YiyQU30O7DHGSzO0=
+SHA256 (clamav-0.94.2.tar.gz) = Gux/7P83WVjQZ6zuuXgtP/C+fBO+0O7PYkD7CJ+NJow=
+SIZE (clamav-0.94.2.tar.gz) = 22107637
Index: systrace.filter
===
RCS file: systrace.filter
diff -N systrace.filter
--- /dev/null   1 Jan 1970 00:00:00 -
+++ systrace.filter 14 Sep 2008 15:00:43 -  1.1
@@ -0,0 +1,3 @@
+# $OpenBSD: systrace.filter,v 1.1 2008/09/14 15:00:43 sthen Exp $
+# fdpass check in configure script (from m4/fdpassing.m4) uses this
+native-sendmsg: sockaddr eq "" then permit
Index: patches/patch-clamav_milter-clamav_milter_c
===
RCS file: 
/cvs/ports/security/clamav/patches/patch-clamav_milter-clamav_milter_c,v
retrieving revision 1.9
retrieving revision 1.11
diff -u -a -r1.9 -r1.11
--- patches/patch-clamav_milter-clamav_milter_c 8 Jul 2008 22:38:12 -   
1.9
+++ patches/patch-clamav_milter-clamav_milter_c 7 Nov 2008 22:33:06 -   
1.11
@@ -1,6 +1,6 @@
 clamav-milter/clamav-milter.c.orig Tue May 27 04:40:29 2008
-+++ clamav-milter/clamav-milter.c  Thu Jun 12 17:31:16 2008
-@@ -1134,7 +1134,7 @@ main(int argc, char **argv)
+--- clamav-milter/clamav-milter.c.orig Thu Oct 16 09:29:55 2008
 clamav-milter/clamav-milter.c  Fri Nov  7 02:29:18 2008
+@@ -1204,7 +1204,7 @@ main(int argc, char **argv)
 * uid == 0 for that
 */
on = 1;
@@ -9,7 +9,7 @@
perror("setsockopt");
return EX_UNAVAILABLE;
}
-@@ -1157,7 +1157,7 @@ main(int argc, char **argv)
+@@ -1227,7 +1227,7 @@ main(int argc, char **argv)
memset(&ifr, '\0', sizeof(struct ifreq));
strncpy(ifr.ifr_name, iface, sizeof(ifr.ifr_name) - 1);
ifr.ifr_name[sizeof(ifr.ifr_name)-1]='\0';
Index: patches/patch-clamd_Makefile_in
===
RCS file: /cvs/ports/security/clamav/patches/patch-clamd_Makefile_in,v
retrieving revision 1.7
retrieving revision 1.9
diff -u -a -r1.7 -r1.9
--- patches/patch-clamd_Makefile_in 16 Apr 2008 19:46:01 -  1.7
+++ patches/patch-clamd_Makefile_in 7 Nov 2008 22:33:06 -   1.9
@@ -1,10 +1,10 @@
-$OpenBSD: patch-clamd_Makefile_in,v 1.7 2008/04/16 19:46:01 mbalmer Exp $
 clamd/Makefile.in.orig Wed Apr  9 17:55:29 2008
-+++ clamd/Makefile.in  Mon Apr 14 18:44:26 2008
-@@ -144,7 +144,9 @@ INSTALL_DATA = @INSTALL_DATA@
- INSTALL_PROGRAM = @INSTALL_PROGRAM@
- INSTALL_SCRIPT = @INSTALL_SC

new: misc/omconsole

[Matthieu Herrb]

omconsole is a small utility I wrote during h2k8 to get access to the
OpenMoko's serial console. It is wired on the 2nd serial port of an FTDI
 FT232C chip on the debug board, which need to attach as ugen so that
the other debugging tools can be used at the same time.

It uses the libftdi port that I sent earlier.

-- 
Matthieu Herrb


omconsole.tar.gz
Description: GNU Zip compressed data

NEW: devel/libftdi

[Matthieu Herrb]

libftdi is a library (using libusb) to talk to FTDI's FT2232C,
FT232BM and FT245BM type chips including the popular bitbang mode.

This port was originally done by dr...@.
-- 
Matthieu Herrb


libftdi.tar.gz
Description: GNU Zip compressed data

Re: foomatic-db -= MESSAGE

[Antoine Jacoutot]

On Sun, 14 Dec 2008, Jacob Meuser wrote:

> 
> ok?

Well... does this mean that now we have 3 different places to look for 
info ?
DESCR, MESSAGE and README.OpenBSD?

It seems even worse now and I think it shouldn't be touched before we 
come up with some kind of consensus over this.

On a side note, I can take maintainership for foomaric-* and gutenprint 
if you want to drop them.

Cheers!

-- 
Antoine

Re: sndio for esound

[Antoine Jacoutot]

On Sun, 14 Dec 2008, Jacob Meuser wrote:
> probably.  someone who actualy uses esound for other than testing
> if esound works want to take care of that?  thanks.

I do use esound on all my workstations.

Here's an update to latest version with your sndio backend.
It works for me...


Index: Makefile
===
RCS file: /cvs/ports/audio/esound/Makefile,v
retrieving revision 1.44
diff -u -r1.44 Makefile
--- Makefile31 Mar 2008 01:05:54 -  1.44
+++ Makefile14 Dec 2008 12:45:04 -
@@ -3,7 +3,7 @@
 
 COMMENT=   sound library for Enlightenment
 
-DISTNAME=  esound-0.2.38
+DISTNAME=  esound-0.2.41
 PKGNAME=   ${DISTNAME}v0
 SHARED_LIBS += esd  2.40 # .2.38
 CATEGORIES=audio
@@ -18,7 +18,7 @@
 PERMIT_PACKAGE_FTP=Yes
 PERMIT_DISTFILES_CDROM=Yes
 PERMIT_DISTFILES_FTP=  Yes
-WANTLIB=   c m wrap
+WANTLIB=   c m sndio wrap
 
 FLAVORS=   arts
 FLAVOR?=
@@ -47,10 +47,9 @@
esdconfdir=${PREFIX}/share/examples/esound
 
 post-extract:
-   @cp -f ${FILESDIR}/audio_sun.c ${WRKSRC}
+   @cp -f ${FILESDIR}/audio_sndio.c ${WRKSRC}
 
 pre-configure:
-   @perl -pi -e 's|_LOCALBASE_|${LOCALBASE}|' \
-   ${WRKSRC}/test-script
+   ${SUBST_CMD} ${WRKSRC}/test-script
 
 .include 
Index: distinfo
===
RCS file: /cvs/ports/audio/esound/distinfo,v
retrieving revision 1.9
diff -u -r1.9 distinfo
--- distinfo31 Mar 2008 01:05:54 -  1.9
+++ distinfo14 Dec 2008 12:45:04 -
@@ -1,5 +1,5 @@
-MD5 (esound-0.2.38.tar.gz) = d8TpgFoBf7oGVSSH3zxmYg==
-RMD160 (esound-0.2.38.tar.gz) = OwL3H38UZcIECjzwETbzHWJnfmE=
-SHA1 (esound-0.2.38.tar.gz) = QFQ9y1sVcsdwKwuwt1aEQEY1G6U=
-SHA256 (esound-0.2.38.tar.gz) = SKOU83d2M2JmBnlKUpTwHilOERTWzD54lMapDyImsGc=
-SIZE (esound-0.2.38.tar.gz) = 519964
+MD5 (esound-0.2.41.tar.gz) = PYlz7YcFPXrMH01EryxGiA==
+RMD160 (esound-0.2.41.tar.gz) = 6TxjJLSj6DIFcCsGLcFKwQ2Kxso=
+SHA1 (esound-0.2.41.tar.gz) = sq9p63wKBpdyCqGrkoXBbcvYvIY=
+SHA256 (esound-0.2.41.tar.gz) = KjLev/636gdKZlckHwIq8CrF6xYPiyepmr+qXWnOI84=
+SIZE (esound-0.2.41.tar.gz) = 518632
Index: files/audio_sndio.c
===
RCS file: files/audio_sndio.c
diff -N files/audio_sndio.c
--- /dev/null   1 Jan 1970 00:00:00 -
+++ files/audio_sndio.c 14 Dec 2008 12:45:04 -
@@ -0,0 +1,134 @@
+/* $OpenBSD$ */
+
+/*
+ * Copyright (c) 2008 Jacob Meuser 
+ *
+ * Permission to use, copy, modify, and distribute this software for any
+ * purpose with or without fee is hereby granted, provided that the above
+ * copyright notice and this permission notice appear in all copies.
+ *
+ * THE SOFTWARE IS PROVIDED "AS IS" AND THE AUTHOR DISCLAIMS ALL WARRANTIES
+ * WITH REGARD TO THIS SOFTWARE INCLUDING ALL IMPLIED WARRANTIES OF
+ * MERCHANTABILITY AND FITNESS. IN NO EVENT SHALL THE AUTHOR BE LIABLE FOR
+ * ANY SPECIAL, DIRECT, INDIRECT, OR CONSEQUENTIAL DAMAGES OR ANY DAMAGES
+ * WHATSOEVER RESULTING FROM LOSS OF USE, DATA OR PROFITS, WHETHER IN AN
+ * ACTION OF CONTRACT, NEGLIGENCE OR OTHER TORTIOUS ACTION, ARISING OUT OF
+ * OR IN CONNECTION WITH THE USE OR PERFORMANCE OF THIS SOFTWARE.
+ */
+
+#include "config.h"
+
+#include 
+
+struct sio_hdl *hdl = NULL;
+
+#define ARCH_esd_audio_close
+void esd_audio_close()
+{
+if (hdl != NULL) {
+sio_close(hdl);
+hdl = NULL;
+}
+}
+
+#define ARCH_esd_audio_open
+int esd_audio_open()
+{
+char *device;
+struct sio_par par;
+int mode = SIO_PLAY;
+
+if (hdl != NULL) {
+fprintf(stderr, "sndio already opened\n");
+return(1);
+}
+
+sio_initpar(&par);
+
+if ((esd_audio_format & ESD_MASK_FUNC) == ESD_RECORD)
+mode |= SIO_REC;
+
+device = esd_audio_device ? esd_audio_device : getenv("AUDIODEVICE");
+if ((hdl = sio_open(device, mode, 0)) == NULL) {
+fprintf(stderr, "sio_open failed\n");
+goto bad;
+}
+
+par.le = (BYTE_ORDER == 4321) ? 0 : 1;
+if ((esd_audio_format & ESD_MASK_BITS) == ESD_BITS16) {
+par.bits = 16;
+par.sig = 1;
+} else {
+par.bits = 8;
+par.sig = 0;
+}
+
+par.pchan = (((esd_audio_format & ESD_MASK_CHAN) == ESD_STEREO) ? 2 : 1);
+if (mode & SIO_REC)
+par.rchan = par.pchan;
+
+par.bufsz = ESD_BUF_SIZE;
+
+par.rate = esd_audio_rate;
+
+if (!sio_setpar(hdl, &par)) {
+fprintf(stderr, "sio_setpar failed\n");
+goto bad;
+}
+
+if (!sio_getpar(hdl, &par)) {
+fprintf(stderr, "sio_getpar failed\n");
+goto bad;
+}
+
+/* check that the actual parameters are what we asked for */
+if (fabs(par.rate - esd_audio_rate) > esd_audio_rate * 0.05) {
+fprintf(stderr, "Unsupported rate: %i Hz\n", esd_audio_rate);
+goto bad;
+}
+if ((esd_audio_format & ESD_MASK_BITS) == ESD_B

Re: cups-enable

[Thilo Pfennig]

One other thing: There is no man cups-enable. Also one cant get help.
Personally I like to use it in /etc/rc.local to do this if links are not
set, but I could
 not get any infos about any options - also not via cups-enable -h or
cups-enable --help.

regards,
Thilo

Re: pkg_info message display [Re: cups-enable]

[Marc Espie]

On Sat, Dec 13, 2008 at 10:38:10AM -0700, Theo de Raadt wrote:
> >  .It Fl M
> >  Show the install-message file (if any) for each package.
> > +If any step not documented in the manual must be taken before a package
> > +can be used, this file will often mention it.
> 
> That is an attempt to entirely push the problem under the table.
> 
> The default message should be relevant.  Noone will use special
> options to go look for relevant information.  As an option, it would
> be much more realistic if -M did not EXIST.
> 
> The basics + by-hand-setup information for most things is 2 lines
> long, because it points at a file.  That is what should be printed
> everytime.  Making people go dig for the important information they
> need is retarded.

Yeah, you're right, and that corresponds to what I was thinking. Giving
further messages to people such as "oh, you also need to look there" is
stupid.

I'm of the opinion I'm going to consider INSTALL messages as part of the
description (a part that gets shown during installation), and show them
whenever we ask for the description (unless we're in the "special" programmer's
mode that shows stuff in a way not suitable for humans).

That said, as we discussed already, I'm quite aware that package tools are
often too wordy, and I hope to be able to address that in the not so distant
future.

One thing people can definitely do to help is track down useless verbiage:
DESCR don't have to mention obvious things. Neither do MESSAGES. If you can
remove useless stuff, then USEFUL things will jump at the face of the user,
and that's always a good thing. ;-)

Re: dropping maintainership of some ports

[Antoine Jacoutot]

On Sun, 14 Dec 2008, Jacob Meuser wrote:

> 
> I have decided to focus more or less completely on audio.  it should
> keep me plenty busy.
> 
> I have already dropped graphics/ffmpeg.  upstream has fixed some stuff,
> but they are silent about the library inter-dependency mess, which is
> probably one of the bigger annoyances with this port.  and of course
> they don't make actual releases, which is annoying as well.  I am
> sad to give this one up, but I have to ... I hope it will find a good
> home.
> 
> I'm also dropping all the printing related ports I maintain(ed).

I can take those.

-- 
Antoine

Re: cups-enable

[Antoine Jacoutot]

On Sun, 14 Dec 2008, Jacob Meuser wrote:
> 
> I think it would also be nice if README.OpenBSD were in pkg/ dirs
> and handled automatically, kinda like MESSAGE is now.  adding files/
> dirs seems like a waste.

I like this.

-- 
Antoine

dropping maintainership of some ports

[Jacob Meuser]

I have decided to focus more or less completely on audio.  it should
keep me plenty busy.

I have already dropped graphics/ffmpeg.  upstream has fixed some stuff,
but they are silent about the library inter-dependency mess, which is
probably one of the bigger annoyances with this port.  and of course
they don't make actual releases, which is annoying as well.  I am
sad to give this one up, but I have to ... I hope it will find a good
home.

I'm also dropping all the printing related ports I maintain(ed).
I know I said I would update gutenprint when they made a release.
well, they made a release, and I still don't have a printer ...
some things just don't work out as planned.

-- 
jake...@sdf.lonestar.org
SDF Public Access UNIX System - http://sdf.lonestar.org

Re: sndio for esound

[Jacob Meuser]

On Sat, Dec 13, 2008 at 11:41:50AM +0100, Antoine Jacoutot wrote:
> On Fri, 12 Dec 2008, Jacob Meuser wrote:
> 
> > On Thu, Dec 11, 2008 at 08:44:10PM +, Jacob Meuser wrote:
> > > 
> > > please test ... and notice how much simpler this is than what it
> > > replaces, even though esound prefers to use a fd for audio access.
> > 
> > new version based on some feedback.
> 
> Latest esound version is 0.2.41, maybe we could also update it in the 
> meantime. That would probably simplify getting patches upstream.

probably.  someone who actualy uses esound for other than testing
if esound works want to take care of that?  thanks.

-- 
jake...@sdf.lonestar.org
SDF Public Access UNIX System - http://sdf.lonestar.org

gutenprint -= MESSAGE * 2

[Jacob Meuser]

ok?

-- 
jake...@sdf.lonestar.org
SDF Public Access UNIX System - http://sdf.lonestar.org

Index: Makefile
===
RCS file: /home2/cvs/OpenBSD/ports/print/gutenprint/Makefile,v
retrieving revision 1.7
diff -u -r1.7 Makefile
--- Makefile11 Sep 2008 19:24:23 -  1.7
+++ Makefile14 Dec 2008 09:25:18 -
@@ -6,9 +6,9 @@
 
 V= 5.0.1
 DISTNAME=  gutenprint-${V}
-PKGNAME-main=  ${DISTNAME}p4
-PKGNAME-foomatic=  foomatic-db-${DISTNAME}
-PKGNAME-gimp=  gutenprint-gimp-${V}p1
+PKGNAME-main=  ${DISTNAME}p5
+PKGNAME-foomatic=  foomatic-db-${DISTNAME}p0
+PKGNAME-gimp=  gutenprint-gimp-${V}p2
 CATEGORIES=print
 
 EXTRACT_SUFX=  .tar.bz2
@@ -17,8 +17,6 @@
 
 HOMEPAGE=  http://gimp-print.sourceforge.net/
 
-MAINTAINER=Jacob Meuser 
-
 # GPL
 PERMIT_PACKAGE_CDROM=  Yes
 PERMIT_PACKAGE_FTP=Yes
@@ -87,5 +85,10 @@
 MAKE_FLAGS=INTLLIBS="\$${LTLIBINTL}"
 
 PKG_ARCH-foomatic= *
+
+post-install:
+   ${INSTALL_DATA_DIR} ${PREFIX}/share/doc/foomatic-db-gutenprint
+   ${INSTALL_DATA} ${FILESDIR}/README.OpenBSD-foomatic \
+   ${PREFIX}/share/doc/foomatic-db-gutenprint/README.OpenBSD
 
 .include 
Index: files/README.OpenBSD-foomatic
===
RCS file: files/README.OpenBSD-foomatic
diff -N files/README.OpenBSD-foomatic
--- /dev/null   1 Jan 1970 00:00:00 -
+++ files/README.OpenBSD-foomatic   14 Dec 2008 09:25:18 -
@@ -0,0 +1,15 @@
+This package only installs the gutenprint data for Foomatic, not the
+PPD files.  PPD files can be created using foomatic-ppdfile(1) from the
+foomatic-db-engine package as in the following example for an Epson
+Stylus C64:
+
+% foomatic-ppdfile -P C64
+Epson Stylus C64 Id='Epson-Stylus_C64' Driver='gutenprint' 
CompatibleDrivers='gutenprint gutenprint-ijs-simplified.5.0 gutenprint-ijs.5.0 '
+% foomatic-ppdfile -p 'Epson-Stylus_C64' -d 'gutenprint-ijs.5.0' > C64.ppd
+
+C64.ppd can then be used with CUPS or with lpd(8) and foomatic-rip(1) as
+the input filter.
+
+Note that the 'gutenprint' driver must be compiled into Ghostscript to
+work; as this is not the case under OpenBSD, you're advised to use the
+ijs driver which will communicate with Ghostscript using libijs.
Index: pkg/DESCR-main
===
RCS file: /home2/cvs/OpenBSD/ports/print/gutenprint/pkg/DESCR-main,v
retrieving revision 1.1.1.1
diff -u -r1.1.1.1 DESCR-main
--- pkg/DESCR-main  1 Oct 2007 10:32:57 -   1.1.1.1
+++ pkg/DESCR-main  14 Dec 2008 09:25:18 -
@@ -4,3 +4,12 @@
 gutenprint project, and which can be used by other printing programs. It
 may be used with most common UNIX print spooling systems, including
 CUPS, lpr, LPRng, or others.
+
+This package only contains the gutenprint libraries and ijs driver.  To
+get more use of this package, install the corresponding package(s):
+
+* foomatic-db-gutenprint: foomatic PPD files, which allows the
+  foomatic-filters to use the gutenprint drivers with your favorite
+  print spooler 
+
+* gutenprint-gimp: printing plugin for gimp
Index: pkg/MESSAGE-foomatic
===
RCS file: pkg/MESSAGE-foomatic
diff -N pkg/MESSAGE-foomatic
--- pkg/MESSAGE-foomatic1 Oct 2007 10:32:57 -   1.1.1.1
+++ /dev/null   1 Jan 1970 00:00:00 -
@@ -1,15 +0,0 @@
-This package only installs the gutenprint data for Foomatic, not the
-PPD files.  PPD files can be created using foomatic-ppdfile(1) from the
-foomatic-db-engine package as in the following example for an Epson
-Stylus C64:
-
-% foomatic-ppdfile -P C64
-Epson Stylus C64 Id='Epson-Stylus_C64' Driver='gutenprint' 
CompatibleDrivers='gutenprint gutenprint-ijs-simplified.5.0 gutenprint-ijs.5.0 '
-% foomatic-ppdfile -p 'Epson-Stylus_C64' -d 'gutenprint-ijs.5.0' > C64.ppd
-
-C64.ppd can then be used with CUPS or with lpd(8) and foomatic-rip(1) as
-the input filter.
-
-Note that the 'gutenprint' driver must be compiled into Ghostscript to
-work; as this is not the case under OpenBSD, you're advised to use the
-ijs driver which will communicate with Ghostscript using libijs.
Index: pkg/MESSAGE-main
===
RCS file: pkg/MESSAGE-main
diff -N pkg/MESSAGE-main
--- pkg/MESSAGE-main31 Aug 2008 16:06:11 -  1.2
+++ /dev/null   1 Jan 1970 00:00:00 -
@@ -1,5 +0,0 @@
-This package only contains the gutenprint libraries and ijs driver.  To
-use gutenprint with your favorite spooler, install the corresponding
-package(s):
- * foomatic (lpr, cups, LPRng) -> foomatic-db-gutenprint
- * gimp (print plugin) -> gutenprint-gimp
Index: pkg/PLIST-foomatic
===
RCS file: /home2/cvs/OpenBSD/ports/print/gutenp

foomatic-db-engine -= MESSAGE

[Jacob Meuser]

and add @bin markers

ok?

-- 
jake...@sdf.lonestar.org
SDF Public Access UNIX System - http://sdf.lonestar.org

Index: Makefile
===
RCS file: /home2/cvs/OpenBSD/ports/print/foomatic-db-engine/Makefile,v
retrieving revision 1.4
diff -u -r1.4 Makefile
--- Makefile18 Sep 2008 13:37:41 -  1.4
+++ Makefile14 Dec 2008 09:13:18 -
@@ -4,12 +4,10 @@
 
 V= 20070919
 DISTNAME=  foomatic-db-engine-3.0-${V}
-PKGNAME=   foomatic-db-engine-3.0.${V}
+PKGNAME=   foomatic-db-engine-3.0.${V}p0
 CATEGORIES=print
 
 HOMEPAGE=  
http://www.linux-foundation.org/en/OpenPrinting/Database/Foomatic
-
-MAINTAINER=Jacob Meuser 
 
 # GPL
 PERMIT_PACKAGE_CDROM=  Yes
Index: pkg/DESCR
===
RCS file: /home2/cvs/OpenBSD/ports/print/foomatic-db-engine/pkg/DESCR,v
retrieving revision 1.1.1.1
diff -u -r1.1.1.1 DESCR
--- pkg/DESCR   9 Sep 2007 14:42:02 -   1.1.1.1
+++ pkg/DESCR   14 Dec 2008 09:13:18 -
@@ -1,3 +1,9 @@
 Foomatic's database engine generates PPD files from the data in
 Foomatic's XML database. It also contains scripts to directly generate
 print queues and handle jobs.
+
+If you use CUPS and want it to generate Foomatic PPDs on demand, create
+a symlink from foomatic-ppdfile(1) to the CUPS PPD generator directory:
+
+# ln -sf ${PREFIX}/bin/foomatic-ppdfile \
+   ${LOCALBASE}/libexec/cups/driver/foomatic
Index: pkg/MESSAGE
===
RCS file: pkg/MESSAGE
diff -N pkg/MESSAGE
--- pkg/MESSAGE 26 Sep 2007 08:25:34 -  1.1
+++ /dev/null   1 Jan 1970 00:00:00 -
@@ -1,5 +0,0 @@
-If you use CUPS and want it to generate Foomatic PPDs on demand, create
-a symlink from foomatic-ppdfile(1) to the CUPS PPD generator directory:
-
-# ln -sf ${PREFIX}/bin/foomatic-ppdfile \
-   ${LOCALBASE}/libexec/cups/driver/foomatic
Index: pkg/PLIST
===
RCS file: /home2/cvs/OpenBSD/ports/print/foomatic-db-engine/pkg/PLIST,v
retrieving revision 1.2
diff -u -r1.2 PLIST
--- pkg/PLIST   26 Sep 2007 08:25:34 -  1.2
+++ pkg/PLIST   14 Dec 2008 09:13:18 -
@@ -1,9 +1,9 @@
 @comment $OpenBSD: PLIST,v 1.2 2007/09/26 08:25:34 ajacoutot Exp $
-bin/foomatic-combo-xml
+...@bin bin/foomatic-combo-xml
 bin/foomatic-compiledb
 bin/foomatic-configure
 bin/foomatic-datafile
-bin/foomatic-perl-data
+...@bin bin/foomatic-perl-data
 bin/foomatic-ppd-options
 bin/foomatic-ppdfile
 bin/foomatic-printjob

foomatic-filters -= MESSAGE

[Jacob Meuser]

ok?

-- 
jake...@sdf.lonestar.org
SDF Public Access UNIX System - http://sdf.lonestar.org

Index: Makefile
===
RCS file: /home2/cvs/OpenBSD/ports/print/foomatic-filters/Makefile,v
retrieving revision 1.7
diff -u -r1.7 Makefile
--- Makefile23 Nov 2008 22:35:33 -  1.7
+++ Makefile14 Dec 2008 09:07:33 -
@@ -3,12 +3,10 @@
 COMMENT=   Foomatic PPD print filters
 
 DISTNAME=  foomatic-filters-3.0.2
-PKGNAME=   ${DISTNAME}p3
+PKGNAME=   ${DISTNAME}p4
 CATEGORIES=print
 
 HOMEPAGE=  
http://www.linuxfoundation.org/en/OpenPrinting/Database/Foomatic
-
-MAINTAINER=Jacob Meuser 
 
 # GPLv2
 PERMIT_PACKAGE_CDROM=  Yes
Index: pkg/DESCR
===
RCS file: /home2/cvs/OpenBSD/ports/print/foomatic-filters/pkg/DESCR,v
retrieving revision 1.1.1.1
diff -u -r1.1.1.1 DESCR
--- pkg/DESCR   9 Sep 2007 14:40:29 -   1.1.1.1
+++ pkg/DESCR   14 Dec 2008 09:07:33 -
@@ -1,3 +1,16 @@
 Filter scripts used by the printer spoolers to convert the incoming
 PostScript data into the printer's native format using a printer/driver
 specific, but spooler-independent PPD file.
+
+To use foomatic-rip(1) as the input filter for lpd(8), create a
+printcap(5) entry similar to the following:
+
+C64|Epson Stylus C64:\
+   :lp=/dev/ulpt0:\
+   :af=${SYSCONFDIR}/foomatic/C64.ppd:\
+   :if=${PREFIX}/bin/foomatic-rip:\
+   :sd=/var/spool/output:\
+   :lf=/var/log/lpd-errs:
+
+There are PPD files in the foomatic-db package.  foomatic-ppdfile(1)
+from the foomatic-db-engine package can be used to generate PPD files.
Index: pkg/MESSAGE
===
RCS file: pkg/MESSAGE
diff -N pkg/MESSAGE
--- pkg/MESSAGE 19 Oct 2007 09:12:03 -  1.2
+++ /dev/null   1 Jan 1970 00:00:00 -
@@ -1,12 +0,0 @@
-To use foomatic-rip(1) as the input filter for lpd(8), create a
-printcap(5) entry similar to the following:
-
-C64|Epson Stylus C64:\
-   :lp=/dev/ulpt0:\
-   :af=${SYSCONFDIR}/foomatic/C64.ppd:\
-   :if=${PREFIX}/bin/foomatic-rip:\
-   :sd=/var/spool/output:\
-   :lf=/var/log/lpd-errs:
-
-There are PPD files in the foomatic-db package.  foomatic-ppdfile(1)
-from the foomatic-db-engine package can be used to generate PPD files.

foomatic-db -= MESSAGE

[Jacob Meuser]

ok?

-- 
jake...@sdf.lonestar.org
SDF Public Access UNIX System - http://sdf.lonestar.org

Index: Makefile
===
RCS file: /home2/cvs/OpenBSD/ports/print/foomatic-db/Makefile,v
retrieving revision 1.4
diff -u -r1.4 Makefile
--- Makefile18 Sep 2008 13:37:41 -  1.4
+++ Makefile14 Dec 2008 08:55:20 -
@@ -4,12 +4,10 @@
 
 V= 20070708
 DISTNAME=  foomatic-db-3.0-${V}
-PKGNAME=   foomatic-db-3.0.${V}
+PKGNAME=   foomatic-db-3.0.${V}p0
 CATEGORIES=print
 
 HOMEPAGE=  
http://www.linux-foundation.org/en/OpenPrinting/Database/Foomatic
-
-MAINTAINER=Jacob Meuser 
 
 # GPL
 PERMIT_PACKAGE_CDROM=  Yes
Index: pkg/DESCR
===
RCS file: /home2/cvs/OpenBSD/ports/print/foomatic-db/pkg/DESCR,v
retrieving revision 1.1.1.1
diff -u -r1.1.1.1 DESCR
--- pkg/DESCR   9 Sep 2007 14:41:26 -   1.1.1.1
+++ pkg/DESCR   14 Dec 2008 08:55:20 -
@@ -1,2 +1,11 @@
 The collected knowledge about printers, drivers, and driver options in
 XML files, used by foomatic-db-engine to generate PPD files.
+
+If you are using or plan to use CUPS, you can make the PPD files
+available to CUPS by creating a symbolic link as in the following
+command:
+
+# ln -sf ${PREFIX}/share/foomatic/db/source/PPD \
+   ${LOCALBASE}/share/cups/model/foomatic-db-ppds
+
+cupsd will need to be restarted to register the new PPDs.
Index: pkg/MESSAGE
===
RCS file: pkg/MESSAGE
diff -N pkg/MESSAGE
--- pkg/MESSAGE 9 Sep 2007 14:41:29 -   1.1.1.1
+++ /dev/null   1 Jan 1970 00:00:00 -
@@ -1,8 +0,0 @@
-If you are using or plan to use CUPS, you can make the PPD files
-available to CUPS by creating a symbolic link as in the following
-command:
-
-# ln -sf ${PREFIX}/share/foomatic/db/source/PPD \
-   ${LOCALBASE}/share/cups/model/foomatic-db-ppds
-
-cupsd will need to be restarted to register the new PPDs.

Re: cups-enable

[Jacob Meuser]

On Sat, Dec 13, 2008 at 09:15:46PM -0500, Steve Shockley wrote:
> On 12/12/2008 2:40 PM, Jacob Meuser wrote:
>>> Who knows about -M?  I'm serious.  I've never used that option before,
>>> and it's totally nonobvious that I should look through the man page to
>>> find it.
>>
>> uh, you're saying it's totally nonobvious that people should read the
>> manuals of tools they are using?
>
> In my case, I didn't know it existed, I always just looked at the +  
> files in /var/db/pkg (which is far less intuitive than -M, but I already  
> knew they were there).
>
> Perhaps pkg_info packagename should note the existence of a  
> README.OpenBSD if one exists?

imo having them under PREFIX/share/doc/pkgname makes them hard to
find, whereas PREFIX/share/README.OpenBSD/pkgname (where pkgname is
the actual file of info) would be imo easy enough to find that we
wouldn't have to say whether it exists and where to find it if so.

I think it would also be nice if README.OpenBSD were in pkg/ dirs
and handled automatically, kinda like MESSAGE is now.  adding files/
dirs seems like a waste.

unfortnately, I have already mailed my wishlist to Santa ... got
some audio stuff and a uvideo, but no pkg patches :(

-- 
jake...@sdf.lonestar.org
SDF Public Access UNIX System - http://sdf.lonestar.org