Re: To sendmail or to postfix that is the question?

2010-03-12 Thread Matthias Andree

Dag-Erling Smørgrav wrote on 2010-03-11:


Matthias Andree  writes:

sendmail's configuration was never a black art unless you needed
features beyond what the m4 macro set supported.


The m4 macro set is a fairly recent development.


If "more than a decade" is a "fairly recent development", then you're  
right.


--
Matthias Andree
___
freebsd-hackers@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to "freebsd-hackers-unsubscr...@freebsd.org"


Re: [RFC] Saving the latest errno from syscalls.

2010-03-12 Thread Kostik Belousov
On Thu, Mar 11, 2010 at 06:15:07PM -0500, Jung-uk Kim wrote:
> On Thursday 11 March 2010 04:55 pm, Marcel Moolenaar wrote:
> > On Mar 11, 2010, at 1:24 PM, Jung-uk Kim wrote:
> > > While I was debugging syscalls, I found a very useful field in
> > > struct thread, td_errno.  It seems it was added for dtrace but it
> > > is only populated on amd64 and i386.  Is the attached patch
> > > acceptable for maintainers of other platforms?
> >
> > Isn't it better to do it in cpu_set_syscall_retval()?
> > That way you catch all cases, plus you can save the
> > translated error as well...
> 
> I just took amd64/i386 as an example and I was not sure whether it was 
> meant to store translated error or not.  Does anyone with DTrace 
> internal knowledge answer the question?

I do not know that much about DTrace, but it seems that setting td_errno
in cpu_set_syscall_retval() is too late. Dtrace has a probe after the
syscall return, and it is called right before cpu_set_syscall_retval()
can be reasonably called. The probe only issued for syscall that goes
into sysent.


pgp6tE7BxzKMz.pgp
Description: PGP signature


Re: To sendmail or to postfix that is the question?

2010-03-12 Thread Dag-Erling Smørgrav
"Matthias Andree"  writes:
> Dag-Erling Smørgrav  writes:
> > Matthias Andree  writes:
> > > sendmail's configuration was never a black art unless you needed
> > > features beyond what the m4 macro set supported.
> > The m4 macro set is a fairly recent development.
> If "more than a decade" is a "fairly recent development",

Well, yes, actually.  I remember having to edit sendmail.cf even for
trivial stuff like setting the sender domain and the outgoing smtp
relay, what, fifteen years ago?  Definitely less than fifteen.  I still
have the first edition of the bat book; it's almost as thick as my
single-volume paperback edition of The Lord of the Rings, and has larger
pages.

More importantly, if you raise your eyes a few centimeters, you'll
notice the word "never" which I think we can all agree is patently
untrue.

DES
-- 
Dag-Erling Smørgrav - d...@des.no
___
freebsd-hackers@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to "freebsd-hackers-unsubscr...@freebsd.org"


Re: [RFC] Saving the latest errno from syscalls.

2010-03-12 Thread Jung-uk Kim
On Friday 12 March 2010 04:29 am, Kostik Belousov wrote:
> On Thu, Mar 11, 2010 at 06:15:07PM -0500, Jung-uk Kim wrote:
> > On Thursday 11 March 2010 04:55 pm, Marcel Moolenaar wrote:
> > > On Mar 11, 2010, at 1:24 PM, Jung-uk Kim wrote:
> > > > While I was debugging syscalls, I found a very useful field
> > > > in struct thread, td_errno.  It seems it was added for dtrace
> > > > but it is only populated on amd64 and i386.  Is the attached
> > > > patch acceptable for maintainers of other platforms?
> > >
> > > Isn't it better to do it in cpu_set_syscall_retval()?
> > > That way you catch all cases, plus you can save the
> > > translated error as well...
> >
> > I just took amd64/i386 as an example and I was not sure whether
> > it was meant to store translated error or not.  Does anyone with
> > DTrace internal knowledge answer the question?
>
> I do not know that much about DTrace, but it seems that setting
> td_errno in cpu_set_syscall_retval() is too late. Dtrace has a
> probe after the syscall return, and it is called right before
> cpu_set_syscall_retval() can be reasonably called. The probe only
> issued for syscall that goes into sysent.

Ah, I can see that now.  So, if/when we implement DTrace SYSCALL 
provider for other arches, this is the right place. :-)

Thanks!

Jung-uk Kim
___
freebsd-hackers@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to "freebsd-hackers-unsubscr...@freebsd.org"


device_t, resource, and softc

2010-03-12 Thread Cole
Hi.

Im busy implementing a kernel module to enable me to read/write
certain control registers for a PCI card. I do not wish to modify the
existing driver, merely create an add-on module that can be loaded to
accomplish what I need.

I can easily get the device_t structure of the device, and I know I
can use device_get_softc, to get the softc of the structure. I also
see there used to be a bus_get_resource function that no longer seems
to be documented or has a man page on FreeBSD. So I was wondering if
there is a way to get the resource for the device using the device_t
structure, which would allow me to easily use the rman_get_bustag, and
rman_get_bushandle functions to get the bus_tag and bus_handle values
for the device and its resouce.

Regards
/Cole
___
freebsd-hackers@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to "freebsd-hackers-unsubscr...@freebsd.org"


SSV '10 Call for Papers Now Available

2010-03-12 Thread Lionel Garth Jones

On behalf of the 5th International Workshop on Systems Software
Verification (SSV '10) program committee, we'd like to invite you to
contribute papers that focus on finding real, applicable solutions to
systems software verification problems. Paper registration and abstracts
are due Friday, May 28, 2010, 11:59 p.m. Samoan time (UTC-11).

Industrial-strength software analysis and verification has advanced in
recent years through the introduction of model checking, automated and
interactive theorem proving, and static analysis techniques, as well as
correctness by design, correctness by contract, and model-driven
development. However, many techniques are working under restrictive
assumptions that are invalidated by complex embedded systems software
such as operating system kernels, low-level device drivers, or
microcontroller code.

The aim of this workshop is to bring together researchers and developers
from both academia and industry who are facing real software and real
problems with the goal of finding real, applicable solutions. By "real"
we mean problems such as time-to-market or reliability that the industry
is facing. A real solution is one that is applicable to the problem in
industry and not one that only applies to an abstract, academic, toy
version of it. In this workshop we will discuss software analysis and
development techniques and tools; this forum will serve as a platform to
discuss open problems and future challenges in dealing with existing and
upcoming systems-level code.

Topics include but are not limited to:

* Model checking
* Automated and interactive theorem proving
* Static analysis
* Automated testing
* Model-driven development
* Embedded systems development
* Programming languages
* Verifying compilers
* Software certification
* Software tools
* Experience reports

Paper registration and abstracts are due Friday, May 28, 2010, 11:59
p.m. Samoan time (UTC-11).

For more details on the submission process, please see the complete
Call for Papers at:
http://www.usenix.org/ssv10/cfpa/

SSV '10 will be held immediately following the 9th USENIX Symposium on
Operating Systems Design and Implementation (OSDI '10), which will take
place October 4-6, 2010.

We look forward to receiving your submissions!

Ralf Huuck, NICTA and University of New South Wales, Australia
Gerwin Klein, NICTA and University of New South Wales, Australia
Bastian Schlich, RWTH Aachen University, Germany
SSV '10 Program Co-Chairs
ssv10cha...@usenix.org

P.S. We'd like to thank our sponsors NICTA and Microsoft Research for
their support.
-
Call for Papers
5th International Workshop on Systems Software Verification
October 6-7, 2010
Vancouver, BC, Canada
http://www.usenix.org/ssv10/cfpa/
Paper registration and abstracts due: Friday, May 28, 2010, 11:59 p.m.
Samoan time (UTC-11) 
___

freebsd-hackers@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to "freebsd-hackers-unsubscr...@freebsd.org"


Re: How to slow down SATA to 1.5 GBit/s ?

2010-03-12 Thread Juergen Lock
In article <10609484503...@192.168.2.69> you write:
>Hi,
>
>Andrey V. Elsukov wrote:
>> Can you show `pciconf -l` output?
>
># pciconf -l
>hos...@pci0:0:0:0:  class=0x06 card=0x50001458 chip=0x79111002 
>rev=0x00 hdr=0x00
>pc...@pci0:0:1:0:   class=0x060400 card=0x79121002 chip=0x79121002 
>rev=0x00 hdr=0x01
>pc...@pci0:0:6:0:   class=0x060400 card=0x50001458 chip=0x79161002 
>rev=0x00 hdr=0x01
>atap...@pci0:0:17:0:class=0x010601 card=0xb0021458 chip=0x43911002 
>rev=0x00 hdr=0x00

That looks like an SB700 aka ATI IXP700 which should be supported by
ahci(4) on FreeBSD >= 8.0 and then hopefully will slow down to sata150
if you set
hint.ahcich.X.sata_rev=1
in /boot/device.hints (see man ahci.)  The controller doesn't like scsi
commands sent to non-atapi devices like ada(4) tho (they cause the bus
to hang), so if your burning app does things like `cdrecord -scanbus'
and you are on 8.0 release (as opposed to stable/8 or head where I think
this condition is catched now) you might want to try the patch in this
posting:
http://docs.freebsd.org/cgi/mid.cgi?4B6358F3.7080908
(Click on the `Raw E-Mail' link at the top to grab the patch, I hope it
applies to 8.0 release too...)

 More about ahci(4) is here:
http://ivoras.sharanet.org/blog/tree/2009-11-17.trying-ahci-in-8.0.html

 As mentioned there disks will rename from adX to adaY, another option
to cope with that if you don't want to adjust fstab each time you
dis/enable ahci(4) is to mount them by using /dev/ufsid/ device nodes
at least if you still use ufs; you can find the device node to use by doing:

dumpfs /dev/adXsYa | sed -n '/id/{s-^.*\[ \(.*\) \(.*\) 
\]$-/dev/ufsid/\1\2-;p;q;}'

(you still have to take care of swap manually then tho, and dumpdev in
rc.conf if you have it set explicitly.)

 Once fstab is fixed, have ahci.ko loaded via loader.conf and reboot:
ahci_load="YES"
- or if you want to try it only temporary at first you can also escape
to the loader prompt from the beastie menu and then type:
load ahci
boot -v
or:
load ahci
boot -v -s
if you want to try it in single user mode first.

 Oh and with ahci the burner will appear as a cd(4) device automatically
so you also don't need atapicam anymore.

 And you may be able to change ahci(4) sata speed at runtime too using
camcontrol,
http://docs.freebsd.org/cgi/mid.cgi?4B18DDDA.3050608
tho I don't know whether 8.0 release has that part of the code yet.

 HTH, :)
Juergen
___
freebsd-hackers@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to "freebsd-hackers-unsubscr...@freebsd.org"


Something rotten in ports (was Re: package building failure irritation)

2010-03-12 Thread xorquewasp
This is a complete lot of how to reproduce the various errors I've
seen with 'make package-recursive'. I've checked the pointyhat logs
and there are no errors logged for the packages involved here. There
seems to be a bug somewhere in ports. I've used inkscape as a scapegoat
here but the errors occur with many, many ports.

There is no ZFS or nullfs involved here (apart from the read-only nullfs
mount that ezjail uses to share /usr/bin and the like).

I've used ezjail-admin to create jails.

$ sudo ezjail-admin create 8.0-amd64-pkg_viper-2 127.1.0.11
$ sudo ezjail-admin onestart 8.0-amd64-pkg_viper-2
$ sudo jexec `jls | grep pkg_viper-2 | awk '{print $1}'` sh

jail# mkdir /var/ports/work
jail# mkdir /var/ports/tree
jail# mkdir /var/ports/packages
jail# mkdir /var/ports/distfiles
jail# vi /etc/make.conf
DISTDIR=   /var/ports/distfiles
PACKAGES=  /var/ports/packages
WRKDIRPREFIX=  /var/ports/work
PORTSDIR=  /var/ports/tree

jail# vi /etc/profile
FTP_PASSIVE_MODE=yes
HTTP_PROXY=10.1.3.3:8080
export FTP_PASSIVE_MODE
export HTTP_PROXY
jail# . /etc/profile

jail# portsnap -p /var/ports/tree fetch extract
Looking up portsnap.FreeBSD.org mirrors... 3 mirrors found.
Fetching public key from portsnap2.FreeBSD.org... done.
Fetching snapshot tag from portsnap2.FreeBSD.org... done.
Fetching snapshot metadata... done.
Fetching snapshot generated at Fri Mar 12 00:22:12 UTC 2010:
d67bd7a10044c70dc705b2c5b05db32b07ab8bd2262c3e  1% of   61 MB  161 kBps
...

jail# cd /var/ports/tree/graphics/inkscape
jail# make config-recursive
jail# make fetch-recursive
jail# make package-recursive 2>&1 | tee /tmp/inkscape.log

Of course, at the end of inkscape.log:

Creating package /var/ports/packages/All/docbook-4.1_4.tbz
Registering depends: iso8879-1986_2 xmlcatmgr-2.2.
Creating bzip'd tar ball in '/var/ports/packages/All/docbook-4.1_4.tbz'
rmdir: /var/ports/work/var/ports/tree/textproc/docbook-410/work: Directory not 
empty
*** Error code 1 (ignored)
Creating package /var/ports/packages/All/eggdbus-0.6.tbz
Registering depends: dbus-glib-0.84 gio-fam-backend-2.22.4 gamin-0.1.10_3 
glib-2.22.4 gettext-0.17_1 dbus-1.2.16_1 libxml2-2.7.6_1 libiconv-1.13.1_1 
libX11-1.2.1_1,1 libxcb-1.5 libpthread-stubs-0.3_3 pcre-8.00 libXau-1.0.4 
libXdmcp-1.0.2_1 xproto-7.0.15 pkg-config-0.23_1 perl-5.10.1 python26-2.6.4 
gnome_subr-1.0 expat-2.0.1_1 kbproto-1.0.3.
Creating bzip'd tar ball in '/var/ports/packages/All/eggdbus-0.6.tbz'
rmdir: /var/ports/work/var/ports/tree/devel/eggdbus/work: Directory not empty
*** Error code 1 (ignored)
===>   Generating temporary packing list
tar: share/sgml/docbook/4.2/ChangeLog: Cannot stat: No such file or directory
tar: share/sgml/docbook/4.2/calstblx.dtd: Cannot stat: No such file or directory
tar: share/sgml/docbook/4.2/catalog: Cannot stat: No such file or directory
tar: share/sgml/docbook/4.2/catalog.xml: Cannot stat: No such file or directory
tar: share/sgml/docbook/4.2/dbcentx.mod: Cannot stat: No such file or directory
tar: share/sgml/docbook/4.2/dbgenent.mod: Cannot stat: No such file or directory
tar: share/sgml/docbook/4.2/dbhierx.mod: Cannot stat: No such file or directory
tar: share/sgml/docbook/4.2/dbnotnx.mod: Cannot stat: No such file or directory
tar: share/sgml/docbook/4.2/dbpoolx.mod: Cannot stat: No such file or directory
tar: share/sgml/docbook/4.2/docbook.cat: Cannot stat: No such file or directory
tar: share/sgml/docbook/4.2/docbook.dcl: Cannot stat: No such file or directory
tar: share/sgml/docbook/4.2/docbook.dtd: Cannot stat: No such file or directory
tar: share/sgml/docbook/4.2/docbookx.dtd: Cannot stat: No such file or directory
tar: share/sgml/docbook/4.2/soextblx.dtd: Cannot stat: No such file or directory
tar: share/sgml/docbook/4.2/README: Cannot stat: No such file or directory
tar: Error exit delayed from previous errors.
pkg_create: make_dist: tar command failed with code 256
Creating package /var/ports/packages/All/docbook-4.2.tbz
Registering depends: iso8879-1986_2 xmlcatmgr-2.2.
Creating bzip'd tar ball in '/var/ports/packages/All/docbook-4.2.tbz'
*** Error code 1

Stop in /var/ports/tree/textproc/docbook-420.
*** Error code 1

Stop in /var/ports/tree/textproc/docbook-420.
*** Error code 1

Stop in /var/ports/tree/graphics/inkscape.

The full log is here:

  http://coreland.ath.cx/tmp/inkscape.log

xw
___
freebsd-hackers@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to "freebsd-hackers-unsubscr...@freebsd.org"


RE: How to slow down SATA to 1.5 GBit/s ?

2010-03-12 Thread Dirk Engling


Sent from my HTC
___
freebsd-hackers@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to "freebsd-hackers-unsubscr...@freebsd.org"


Re: Something rotten in ports (was Re: package building failure irritation)

2010-03-12 Thread Greg Larkin
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

xorquew...@googlemail.com wrote:
[...]
> DISTDIR=   /var/ports/distfiles
> PACKAGES=  /var/ports/packages
> WRKDIRPREFIX=  /var/ports/work
> PORTSDIR=  /var/ports/tree
> 
> jail# vi /etc/profile
> FTP_PASSIVE_MODE=yes
> HTTP_PROXY=10.1.3.3:8080
> export FTP_PASSIVE_MODE
> export HTTP_PROXY
> jail# . /etc/profile
> 
> jail# portsnap -p /var/ports/tree fetch extract
> Looking up portsnap.FreeBSD.org mirrors... 3 mirrors found.
> Fetching public key from portsnap2.FreeBSD.org... done.
> Fetching snapshot tag from portsnap2.FreeBSD.org... done.
> Fetching snapshot metadata... done.
> Fetching snapshot generated at Fri Mar 12 00:22:12 UTC 2010:
> d67bd7a10044c70dc705b2c5b05db32b07ab8bd2262c3e  1% of   61 MB  161 kBps
> ...
> 
> jail# cd /var/ports/tree/graphics/inkscape
> jail# make config-recursive
> jail# make fetch-recursive
> jail# make package-recursive 2>&1 | tee /tmp/inkscape.log
> 
> Of course, at the end of inkscape.log:
> 
[...]
> rmdir: /var/ports/work/var/ports/tree/devel/eggdbus/work: Directory not empty
> *** Error code 1 (ignored)
[...]

Hi xw,

I noticed something strange here.  How is WRKDIR (in this case
"/var/ports/work/var/ports/tree/devel/eggdbus/work") defined?  It looks
like bsd.port.mk combined your WRKDIRPREFIX and PORTSDIR to create that
path, but skimming the code, I can't figure out how it's doing that.
How many levels of that directory tree exist on your system?

If you look at the package-noinstall target in bsd.port.mk, you'll see
the line:

-...@${rmdir} ${WRKDIR}

and I believe that's the one that throws the "Directory not empty" error.

Have you tried just setting PORTSDIR and letting bsd.port.mk set the
rest of the paths with their defaults that are relative to PORTSDIR?  If
that works, then we can start hunting for places that are not handling
absolute vs. relative paths correctly in bsd.port.mk.

Hope that helps,
Greg
- --
Greg Larkin

http://www.FreeBSD.org/   - The Power To Serve
http://www.sourcehosting.net/ - Ready. Set. Code.
http://twitter.com/sourcehosting/ - Follow me, follow you
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.7 (MingW32)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/

iD8DBQFLmwhW0sRouByUApARArf3AJ41IkBVHYDmWcDH+JIMSpf15HrvogCgg10O
igt2EmedReaASRFsCyn1a3A=
=EgS8
-END PGP SIGNATURE-

___
freebsd-hackers@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to "freebsd-hackers-unsubscr...@freebsd.org"


Re: Something rotten in ports (was Re: package building failure irritation)

2010-03-12 Thread xorquewasp
On 2010-03-12 22:36:54, Greg Larkin wrote:
> Hi xw,
> 
> I noticed something strange here.  How is WRKDIR (in this case
> "/var/ports/work/var/ports/tree/devel/eggdbus/work") defined?  It looks
> like bsd.port.mk combined your WRKDIRPREFIX and PORTSDIR to create that
> path, but skimming the code, I can't figure out how it's doing that.
> How many levels of that directory tree exist on your system?

'Lo.

Not sure I understand what you're asking me to check, but things have basically
laid themselves out like this:

# ls /var/ports/work/var/ports/tree/devel/eggdbus/work/eggdbus-0.6/
AUTHORS   MakefileREADMEconfig.h.in   configure.ac  
eggdbus-1.pc.in missing
COPYING   Makefile.am aclocal.m4config.logconfigure.bak 
gtk-doc.makesrc
ChangeLog Makefile.in compile   config.status depcomp   install-sh  
stamp-h1
HACKING   Makefile.in.bak config.guess  config.subdocs  libtool
INSTALL   NEWSconfig.h  configure eggdbus-1.pc  ltmain.sh

> Have you tried just setting PORTSDIR and letting bsd.port.mk set the
> rest of the paths with their defaults that are relative to PORTSDIR?  If
> that works, then we can start hunting for places that are not handling
> absolute vs. relative paths correctly in bsd.port.mk.

Will try that now. In the original setup, I did specifically want to keep
these directories separate (as PORTSDIR was a read-only nullfs mount), but
that's obviously not the case for this example setup.

xw
___
freebsd-hackers@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to "freebsd-hackers-unsubscr...@freebsd.org"


Re: Something rotten in ports (was Re: package building failure irritation)

2010-03-12 Thread xorquewasp
> Have you tried just setting PORTSDIR and letting bsd.port.mk set the
> rest of the paths with their defaults that are relative to PORTSDIR?  If
> that works, then we can start hunting for places that are not handling
> absolute vs. relative paths correctly in bsd.port.mk.

Now, with only:

  PORTSDIR=/var/ports/tree

.. in make.conf, the error is:

Creating package /var/ports/tree/devel/eggdbus/eggdbus-0.6.tbz
Registering depends: dbus-glib-0.84 gio-fam-backend-2.22.4 gamin-0.1.10_3 
glib-2.22.4 gettext-0.17_1 dbus-1.2.16_1 libxml2-2.7.6_1 libiconv-1.13.1_1 
libX11-1.2.1_1,1 libxcb-1.5 libpthread-stubs-0.3_3 pcre-8.00 libXau-1.0.4 
libXdmcp-1.0.2_1 xproto-7.0.15 pkg-config-0.23_1 perl-5.10.1 python26-2.6.4 
gnome_subr-1.0 expat-2.0.1_1 kbproto-1.0.3.
Creating bzip'd tar ball in '/var/ports/tree/devel/eggdbus/eggdbus-0.6.tbz'
rmdir: /var/ports/tree/devel/eggdbus/work: Directory not empty
*** Error code 1 (ignored)
===>   Generating temporary packing list
Creating package /var/ports/tree/textproc/docbook-420/docbook-4.2.tbz
Registering depends: iso8879-1986_2 xmlcatmgr-2.2.
Creating bzip'd tar ball in 
'/var/ports/tree/textproc/docbook-420/docbook-4.2.tbz'
tar: share/sgml/docbook/4.2/ChangeLog: Cannot stat: No such file or directory
tar: share/sgml/docbook/4.2/calstblx.dtd: Cannot stat: No such file or directory
tar: share/sgml/docbook/4.2/catalog: Cannot stat: No such file or directory
tar: share/sgml/docbook/4.2/catalog.xml: Cannot stat: No such file or directory
tar: share/sgml/docbook/4.2/dbcentx.mod: Cannot stat: No such file or directory
tar: share/sgml/docbook/4.2/dbgenent.mod: Cannot stat: No such file or directory
tar: share/sgml/docbook/4.2/dbhierx.mod: Cannot stat: No such file or directory
tar: share/sgml/docbook/4.2/dbnotnx.mod: Cannot stat: No such file or directory
tar: share/sgml/docbook/4.2/dbpoolx.mod: Cannot stat: No such file or directory
tar: share/sgml/docbook/4.2/docbook.cat: Cannot stat: No such file or directory
tar: share/sgml/docbook/4.2/docbook.dcl: Cannot stat: No such file or directory
tar: share/sgml/docbook/4.2/docbook.dtd: Cannot stat: No such file or directory
tar: share/sgml/docbook/4.2/docbookx.dtd: Cannot stat: No such file or directory
tar: share/sgml/docbook/4.2/soextblx.dtd: Cannot stat: No such file or directory
tar: share/sgml/docbook/4.2/README: Cannot stat: No such file or directory
tar: Error exit delayed from previous errors.
pkg_create: make_dist: tar command failed with code 256
*** Error code 1

Stop in /var/ports/tree/textproc/docbook-420.
*** Error code 1

Stop in /var/ports/tree/textproc/docbook-420.
*** Error code 1

Stop in /var/ports/tree/graphics/inkscape.

Regards,
xw
___
freebsd-hackers@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to "freebsd-hackers-unsubscr...@freebsd.org"