On Mon, 30 Oct 2006 21:59:52 +0100
Marcus von Appen [EMAIL PROTECTED] wrote:
sysutils/hal fails on install on my system whenever I have the docbook
related ports already installed. Removing all of them and letting them
install as dependency of hal works fine, but breaks hal upgrades, when
Hello,
0.9.5 releassed.
http://eaccelerator.net/wiki/Release-0.9.5
Changes in this version (from 0.9.4):
* This version brings full php 5.1 support, which has as
side-effect that eAccelerator won't work anymore with php 4 on
windows, but on other platforms this isn't a problem.
* The
Vasil Dimov writes:
is clearly truncated and is also precisely 128 characters long. While your
NFS mount point /mnt/files/ adds only 11 characters to the file name,
this may be enough to overflow a fixed 128 character buffer used by the
idlc. Try mounting the NFS file system at say /mnt or
Vasil Dimov wrote:
On Tue, Oct 31, 2006 at 12:06:55AM +, Bartosz Fabianowski wrote:
It seems that you have run into a know problem with the OpenOffice.org
build system - it does not work when file names become too long. In the
error message you posted,
I've run into similar problem
Hi,
I have described my problem in this thread
http://www.freebsdforums.org/forums/showthread.php?t=45034 ... My problem is
that when I use xmms-musepack plugin (which doesn't use libmpcdec library) from
ports and play with it some MPC song, my CPU usage is bigger than using MPC
decoder which
I have two ports that were recently accepted into the tree. *After* they
were accepted, someone involved with the project asked me to make the
following changes to the Makefiles:
I noticed that both sguil-server and sguil-sensor have this in the Makefile:
$ grep -i squil *
Makefile:COMMENT=
On Oct 28, 2006, at 2:39 AM, Andreas Klemm wrote:
At the moment I only found the variable WITHOUT_X11.
But its only for ports, that can be built optionally with and without
X11 support. It doesn't hinder directly to built x11 stuff using ports
collection.
I also find that you need to set
Submitter-Id: current-users
Originator:Norikatsu Shigemura
Organization: Ensure Technology LTD.
Confidential: no
Synopsis: make ports depending on sysutils/cdrtools* USE_GNOME=cdrtools
Severity: serious
Priority: medium
Category: ports
Class: sw-bug
Release:
On Tue, Oct 31, 2006 at 12:04:34PM -0600, Paul Schmehl wrote:
If I submit PRs for this, do I have to set PORTREVISION to 1? Or does it
matter for such a minor change?
Since it doesn't affect the package (install/deinstall), PORTREVISION
should not be bumped.
mcl
On Tue, Oct 31, 2006 at 12:04:34PM -0600, Paul Schmehl wrote:
I have two ports that were recently accepted into the tree. *After* they
were accepted, someone involved with the project asked me to make the
following changes to the Makefiles:
I noticed that both sguil-server and
On Tue, Oct 31, 2006 at 12:04:34PM -0600, Paul Schmehl wrote:
If I submit PRs for this, do I have to set PORTREVISION to 1? Or does it
matter for such a minor change?
Incrementing PORTREVISION would invite users to `upgrade' their port. A
change to COMMENT does not warrant users reinstalling
On Oct 31, 2006, at 8:59 AM, Norikatsu Shigemura wrote:
[ ... ]
Description:
Some ports depending on sysutils/cdrtools and some ports dependeing
on sysutils/cdrtools-cjk are conflicted. So I want to integrate to
USE_GNOME= cdrtools and OPTIONify WITH_CJK.
On 10/31/06, Chuck Swiger [EMAIL PROTECTED] wrote:
On Oct 31, 2006, at 8:59 AM, Norikatsu Shigemura wrote:
[ ... ]
Description:
Some ports depending on sysutils/cdrtools and some ports dependeing
on sysutils/cdrtools-cjk are conflicted. So I want to integrate to
USE_GNOME=
On Oct 31, 2006, at 3:36 PM, Scot Hetzel wrote:
With respect to this, I don't want dvd+rw-tools to depend on X11 or
GNOME.
Does cdrtools have a dependenacy on GNOME?
No, or not at the moment.
If it doesn't then it would be better to add a USE_CDRTOOLS knob to
bsd.port.mk
that would allow
On Tue, 31 Oct 2006 14:15:21 -0600, Chuck Swiger [EMAIL PROTECTED] wrote:
On Oct 31, 2006, at 8:59 AM, Norikatsu Shigemura wrote:
[ ... ]
Description:
Some ports depending on sysutils/cdrtools and some ports dependeing
on sysutils/cdrtools-cjk are conflicted. So I want to
** The following ports have a version number that sorts before a previous one **
For many package tools to work correctly, it is of utmost importance that
version numbers of a port form a monotonic increasing sequence over time.
Refer to the FreeBSD Porter's Handbook, 'Package Naming
I've rebuilt my pkgdb:
ns : 18:42:37 /root# pkgdb -fu
--- Updating the pkgdb
[Rebuilding the pkgdb format:bdb_btree in /var/db/pkg ... - 219 packages
found (-0 +219)
Lukashev Anton wrote:
Hi,
I'm having troubles almost the same as reported here:
http://portsmon.freebsd.org/portoverview.py?category=develportname=icuwildcard=
Under amd64 and i386, while trying to install or update icu I see the
following:
* cut *
/custrtrn/
---[OK]
Jona Joachim wrote:
Lukashev Anton wrote:
Hi,
I'm having troubles almost the same as reported here:
http://portsmon.freebsd.org/portoverview.py?category=develportname=icuwildcard=
Under amd64 and i386, while trying to install or update icu I see the
following:
* cut *
/custrtrn/
19 matches
Mail list logo
