-------
===> Extracting for qpage-3.2
>> Checksum OK for qpage-3.2.tar.Z.
/usr/bin/tar: archive /usr/ports/distfiles//qpage-3.2.tar.Z EOF not on block boundary
*** Error code 1
Stop.
# make package
>> qpage-3.2.tar.Z doesn't seem to exist on this system.
>> Attempting to fetch from http://www.qpage.org/download/.
Receiving qpage-3.2.tar.Z (149352 bytes): 100%
149357 bytes transfered in 24.5 seconds (5.95 Kbytes/s)
>> Checksum mismatch for qpage-3.2.tar.Z.
Make sure the Makefile and md5 file (/usr/ports/BROKEN/comms/qpage/files/md5)
are up to date. If you want to override this check, type
"make NO_CHECKSUM=yes [other args]".
*** Error code 1
Stop.
#
installs the version of the port that uses shared library number 9 and the
LIBRARY_VERSION set to the default. Normally this is against our policy
(bumping the version number for minor things), however due to the major
problems caused with the upgrade, Satoshi and I decided that this was best.
Approved by: asami
Creating package /usr/ports/packages/All/kdeutils-4.1b.tgz
Registering depends: giflib-3.0 jpeg-6b kdelibs-4.1b qt-1.31.
Creating gzip'd tar ball in '/usr/ports/packages/All/kdeutils-4.1b.tgz'
tar: can't add file share/applnk/Applications/kedit.kdelnk : No such file or directory
tar: can't add file share/apps/kjots/toolbar/OpenBook.xpm : No such file or directory
tar: can't add file share/apps/kjots/toolbar/filedel.xpm : No such file or directory
tar: can't add file share/apps/kljettool/pics/kljetlogo.xpm : No such file or directory
tar: can't add file share/doc/HTML/en/kjots/index.html : No such file or directory
tar: can't add file share/icons/kjots.xpm : No such file or directory
*** Error code 1
===> Patching for conserver-5.21
===> Applying FreeBSD patches for conserver-5.21
No file to patch. Skipping...
2 out of 2 hunks ignored--saving rejects to ./conserver/group.c.rej
*** Error code 2
but aren't in a tk virtual category from
awk -F\| '$9 ~ /tk-/ && $7 !~ /tk/ {print $1}' INDEX
I didn't do anything about the ports which depend on things which depend
on a tk revision. I'd be afraid that the depended-upon port might change
and thus outdate the virtual category in the depender.
(change made on 97dec)
comment from Lars follows:
Included is an updated patch-ab file for hylafax for current that
fixes the busywait that occurred once the fifo_poll() fix went into
the kernel in December.
The symptoms were that faxqetty and faxq would chew up an inordinate
amount of time waiting for input form their FIFOS. Basically the
kernel fix was to make select() return a 1 on EOF (in accordance
with POSIX) and for read() to keep returning 0 on EOF (which is
the state you are in if you open the fifo for reading in non-blocking
mode and there are no writers).
Reviewed by: asami
Submitted by: Lars Fredriksen <lars@fredriks-1.pr.mcs.net>
There is a later version of conserver, but it requires a rather extensive
build environment and set of tools to build it. This version works is
nice and stable though.
kdegames -> games/
kdenetwork -> net/
kdesupport -> converters/
kdeutils -> misc/
(Repository copy already done, dependency path and category name fixups
is being done in this commit.)
(2) Add a virtual category "kde" and add all six (incl. x11/kde{base,lib})
ports.
(3) Make package names follow the convention.
(4) Change "BUILD_DEPENDS=${X11R6}/bin/moc:..." to "...=moc:...".
There is no need to specify the full pathname if the target is an
executable in the standard path. (Actually, as the same port is
specified in LIB_DEPENDS, I think we can completely do away with
this line but since Stefan added this explicitly, I assume there
is a reason for it and left it alone.)
Approved by: se (all but 4)
the import message used when it was imported to ports/misc:
New port, qpage:
QuickPage sends messages to a paging terminal using the SNPP and IXO
(also known as TAP) protocols. It is normally used with no options
other than a recipient and the message text, in which case the message
is sent to the SNPP server where it is submitted to a page queue to be
sent by a separate daemon process.
PR: 4224
Submitted by: Joe Stein <joes@seaport.net>
