As part of an ongoing effort to reduce the number of problems in
the FreeBSD ports system, we periodically notify users of ports
that are marked as broken in their Makefiles. In many cases
these ports are failing to compile on some subset of the FreeBSD
build environments. The most common
As part of an ongoing effort to reduce the number of problems in
the FreeBSD ports system, we periodically notify users of ports
that are marked as broken in their Makefiles. In many cases
these ports are failing to compile on some subset of the FreeBSD
build environments. The most common
As part of an ongoing effort to reduce the number of problems in
the FreeBSD ports system, we periodically schedule removal of ports
that have been judged to have outlived their usefulness. Often,
this is due to a better alternative having become available and/or
the cessation of development on
As part of an ongoing effort to reduce the number of problems in
the FreeBSD ports system, we periodically schedule removal of ports
that have been judged to have outlived their usefulness. Often,
this is due to a better alternative having become available and/or
the cessation of development on
As part of an ongoing effort to reduce the number of problems in the
FreeBSD ports system, we periodically notify users about
ports that are marked as forbidden in their Makefiles. Often,
these ports are so marked due to security concerns, such as known
exploits.
An overview of each port,
Whatever, just fix it, please.
Thanks, Herby
Doug Barton wrote:
On 01/19/2012 07:39, Herby Vojčík wrote:
The couchdb_prestart function gets run (I put echos in there), but its
couchdb_flags is not taken into account.
The proper solution here is almost certainly to change couchdb_flags to
Can you test the fix that I proposed and let us know if it works?
Thanks,
Doug
On 01/21/2012 01:30 AM, Herby Vojčík wrote:
Whatever, just fix it, please.
Thanks, Herby
Doug Barton wrote:
On 01/19/2012 07:39, Herby Vojčík wrote:
The couchdb_prestart function gets run (I put echos in
It works. With command_args, not commands_args, of course :-)
The rc script has another flaw: it can run start multiple times
(but I'd like to have the commands_args fix being published regardless
of multi-start, that is different thing).
Thanks, Herby
Doug Barton wrote:
Can you test the
When was arlib fixed with clang? does anyone know?
this pr submission takes out the test:
.if defined(WITH_ARLIB)
-. if ${CC} == clang
-BROKEN= ARLIB option does not compile with clang
-. endif
http://www.freebsd.org/cgi/query-pr.cgi?pr=ports/163984
but, if arlib WAS broken, and is
Due to the 'IS_INTERACTIVE' in Makefile, and, in fact, in the ports/src
Makefile, this won't package, which means this won't
tinderbox (and PH will complain). I have seen pr's in the past that tried to
fix this issue, but it never went away.
(you install this, and it goes to tripwire web site,
On Thu, Jan 19, 2012 at 08:58:04AM +, Matthew Seaman wrote:
By my calculations there are 28 ports that set 'BROKEN' because of
architecture incompatibility on my amd64 system
IMHO these Makefiles are broken and should be fixed.
mcl
___
On Fri, Jan 20, 2012 at 10:20:05AM +, Matthew Seaman wrote:
Actually I take your point, that it should be possible to distinguish
between ports that permanently won't work on some architectures by
design, and ports that temporarily don't work because of mistakes or
broken dependencies or
Christer Edwards wrote on 20.01.2012 19:09:
On Thu, Jan 19, 2012 at 8:12 PM, Doug Bartondo...@freebsd.org wrote:
I've been evaluating salt, and would prefer not to deploy prior to the
msgpack update in 0.9.5.
I am hoping to get the port updated today, yes. Thanks for the
additional nudge to
On Fri, Jan 20, 2012 at 12:53:23PM +, Chris Rees wrote:
Occasionally someone runs an exp- for sparc64 (lol) etc.
You're conflating two different ideas. The arch is orthogonal to
TRYBROKEN.
They use TRYBROKEN to test packages marked BROKEN, but ONLY_FOR_ARCHS
sets IGNORE.
This part is
On Fri, Jan 20, 2012 at 05:16:08AM -0800, Doug Barton wrote:
On 01/20/2012 04:53, Chris Rees wrote:
Occasionally someone runs an exp- for sparc64 (lol) etc.
... which given the overwhelming lack of users for this platform is
almost certainly a waste of resources.
When we switch to
On 21 Jan 2012 19:51, Mark Linimon lini...@lonesome.com wrote:
On Fri, Jan 20, 2012 at 12:53:23PM +, Chris Rees wrote:
Occasionally someone runs an exp- for sparc64 (lol) etc.
You're conflating two different ideas. The arch is orthogonal to
TRYBROKEN.
Perhaps I didn't phrase it
On 21/01/2012 19:33, Mark Linimon wrote:
On Thu, Jan 19, 2012 at 08:58:04AM +, Matthew Seaman wrote:
By my calculations there are 28 ports that set 'BROKEN' because of
architecture incompatibility on my amd64 system
IMHO these Makefiles are broken and should be fixed.
Actually,
I reached out to a high level sr engineer at VMware and told him there
was a lot of companies using FreeBSD on VMware, and a lot more that
would, if just VMware gave us some love (fixed, or helped us fix some
device drivers).
He asked how many?
Well, I sure can't go back to him and tell him
Dear all,
I've stumbled across a weird issue with building the databases/mysql-
workbench52 port on a brandnew / fresh FreeBSD 9 RELEASE machine:
/usr/ports/databases/mysql-workbench52# make install
=== mysql-workbench-oss52-5.2.1_5 cannot install: does not work with MySQL
version 55 (MySQL
On 1/21/12 3:00 PM, t...@diogunix.com wrote:
Dear all,
I've stumbled across a weird issue with building the databases/mysql-
workbench52 port on a brandnew / fresh FreeBSD 9 RELEASE machine:
its in the makefile for mysql-workbench51
DEFAULT_MYSQL_VER= 51
IGNORE_WITH_MYSQL= 41 55
On Fri, Jan 20, 2012 at 10:20:05AM +, Matthew Seaman wrote:
Actually I take your point, that it should be possible to distinguish
between ports that permanently won't work on some architectures by
design, and ports that temporarily don't work because of mistakes or
broken dependencies or
If I build a port that uses USE_FORTRAN, then the variable ${LDFLAGS}
has an extra space in it. For example
%cd /usr/ports/math/lapack
%make -V LDFLAGS
-Wl,-rpath=/usr/local/lib/gcc46
%make -V MAKE_ENV
LDFLAGS= -Wl,-rpath=/usr/local/lib/gcc46 ...
I am trying to create a port in which
On Sat, 21 Jan 2012 15:12:53 -0500
Michael Scheidell articulated:
I reached out to a high level sr engineer at VMware and told him
there was a lot of companies using FreeBSD on VMware, and a lot more
that would, if just VMware gave us some love (fixed, or helped us fix
some device drivers).
On сб, 21 січ 2012 22:22:50 Michael Scheidell wrote:
On 1/21/12 3:00 PM, t...@diogunix.com wrote:
Dear all,
I've stumbled across a weird issue with building the databases/mysql-
workbench52 port on a brandnew / fresh FreeBSD 9 RELEASE machine:
its in the makefile for mysql-workbench51
On Sat, Jan 21, 2012 at 12:42 PM, Ruslan Mahmatkhanov cvs-...@yandex.ru wrote:
JFYI. There is 0.9.6 already.
The core Salt team is in LA at SCaLE this weekend and getting a lot of
attention. We rolled 0.9.6 last night in the hotel lobby, but I've
been so busy with conference stuff I haven't
On Thu, 19 Jan 2012 19:00:04 +0100
Thomas Zander thomas.e.zan...@googlemail.com wrote:
But the takeaway is that we can't expect the PR submitters, or even
port maintainers, to get anything right. It sure makes life easier
when they do, but we can't take it for granted.
As committers, we
Hi,
I wonder why I should run FreeBSD under VMware.
On Sunday 22 January 2012 04:10:24 Jerry wrote:
On Sat, 21 Jan 2012 15:12:53 -0500
Michael Scheidell articulated:
I reached out to a high level sr engineer at VMware and told him
there was a lot of companies using FreeBSD on VMware, and
On 01/21/2012 03:02 PM, Stephen Montgomery-Smith wrote:
If I build a port that uses USE_FORTRAN, then the variable ${LDFLAGS}
has an extra space in it. For example
%cd /usr/ports/math/lapack
%make -V LDFLAGS
-Wl,-rpath=/usr/local/lib/gcc46
%make -V MAKE_ENV
LDFLAGS=
On Sat, 21 Jan 2012 14:12:53 -0600, Michael Scheidell
scheid...@freebsd.org wrote:
I reached out to a high level sr engineer at VMware and told him there
was a lot of companies using FreeBSD on VMware, and a lot more that
would, if just VMware gave us some love (fixed, or helped us fix
.. maybe the correct(er) solution would be We've got a couple of companies
who would love to take on the responsibility of hacking on and testing the
vmware driver support for FreeBSD, please consider negotiating an NDA to
get whatever source opened up?
Adrian
On 21 January 2012 12:12, Michael
30 matches
Mail list logo
