Re: NOT_FOR_ARCHS considered harmful [was: with the cvs history? trying to help INDEX builds.]

2012-01-22 Thread Chris Rees
On 21 Jan 2012 20:46, Mark Linimon lini...@lonesome.com wrote:

 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 so forth, and that are expected to be fixed
  sooner rather than later.

 There's a secondary problem which I keep meaning to write up a rant
 on.  This thread seems as good a place as any.

 Warning: the following is only my own opinion, not portmgr's.

 We made a design mistake by allowing in NOT_FOR_ARCHS as an alternative
 to ONLY_FOR_ARCHS.  This has always been a shortcut to say doesn't
 build on !(amd64!i386).  As long as the archs were (alpha|amd64|i386|
 sparc64) this was merely annoying.

 The problem comes when we start up package builds on new archs.   The
 primary utility of package builds for tier-2s has arguably been to QA
 whether the ports build at all.  The secondary utility, in order:

  - test that the arch's srcbase has't regressed to the point where it's
   too unstable to build packages

  - flag ports (and infrastructure) with bad assumptions about wordlength
   and endianness

  - create usable packages (really, only the most fundamental ports will
   have packages that are timely, due to the  1 month cycle times)

 In general, I claim if a port already has some kind of NOT_FOR_ARCH
 entry, it's unlikely to build on a new arch.  This was clearly demonstrated
 a couple of years ago when I first started powerpc builds once we had a
 machine donated (note: powerpc = 32-bit).  The errors were correlated to
 sparc64, but only roughly.

 sparc64 builds tend to trip up on the following, in order of which I
 think we should care:

  - 64-bit issues (which have a high correlation to amd64 build failures),

  - lack of arch-specific build stanzas (which have a high correlation to
   powerpc),

  - endianness issues.

 The powerpc build also pointed out that many ports assumed that 32bit  i386.
 On occasion, I fix notable occurences of this (e.g. python).

 So, why does this matter?  Surely our sparc64 and powerpc/Mac userbases
 are tiny.

 The reason to do this work is that there is demand for arm and mips builds
 for embedded systems[1], and once these are turned on, we're going to have
 a bazillion build errors to sort through.

 To the extent that our first attempts include only ports that don't have
 the NOT_FOR stanzas, IMHO we're going to make more progress more quickly.

 Now, for mips, only the fundamental ports are ever going to matter,
 since there are no viable mips desktops to worry about.  But, for
 embedded, getting a subset of things in net/ and sysutils/ (and to
 some extent things like lang/perl) is going to be useful -- again, not
 so much for uploadable packages, but to ensure buildability when vendors
 try to use these in their products.

 (I'm told that people are speculating about running desktop stuff on
 native arm, so that's why I picked mips for the use-case.  I have no
 idea if that's anything but blue-sky.)

 So IMHO we should do a sweep:

  - move all the true cases of NOT_FOR_ARCHS to ONLY_FOR_ARCHS

  - move all the false cases of NOT_FOR_ARCHS to BROKEN

 and then drop support for NOT_FOR_ARCHS.

 If anyone is interested in coming up with patches, I'll do the -exp
 run (on amd64 :-) ) to prove that there are no regressions on that
 arch at least.

 Finally, for those willing to investigate how messed-up the metadata
 currently are, pull up the following page:

  http://pointyhat.freebsd.org/errorlogs/packagestats.html

 You'll find a column marked skipped.  That contains URLs to files
 called duds.verbose for each buildenv.  This file is the output of
 'make ignorelist-verbose' called from the top of the tree.

 The reason that we decided to archive these per-pointyhat-run is so
 that you can tell _exactly_ why pointyhat believed that it did not have
 to try to build that package at that exact point in time.  In the past,
 you had to impute it from whatever the state of the tree was.  Since
 the tree evolves so quickly, it was impossible to tell.  (There are
 also a very small handful of degenerate cases where things don't
 build on pointyhat due to its build environment.  I've worked on getting
 these down to  10 over the past few years.)

 tl;dr: I want to switch the default assumption we're making.

 IMHO when new ports come into the tree, we should make our default
 assumption that we will try to build them on amd64 and i386.  For cases
 that this does not hold, we consider this Bad and committer-must-fix.
 For the tier-2s, we shift the default assumption to only set it to
 buildable once it has been shown to be so.  So, the burden of proof
 shifts the other way: to a user of a tier-2 to claim I tried this and
 it works, rather than portmgr saying we tried this and it doesn't work.

 (Of course, 

Re: NOT_FOR_ARCHS considered harmful [was: with the cvs history? trying to help INDEX builds.]

2012-01-22 Thread Matthew Seaman
On 21/01/2012 20:46, Mark Linimon wrote:
 tl;dr: I want to switch the default assumption we're making.
 
 IMHO when new ports come into the tree, we should make our default
 assumption that we will try to build them on amd64 and i386.  For cases
 that this does not hold, we consider this Bad and committer-must-fix.
 For the tier-2s, we shift the default assumption to only set it to
 buildable once it has been shown to be so.  So, the burden of proof
 shifts the other way: to a user of a tier-2 to claim I tried this and
 it works, rather than portmgr saying we tried this and it doesn't work.

Doesn't your proposed change in semantics of the 'FOR_ARCHS' stuff mean
that over time, as other architectures become more popular, most ports
will have to have an explicit 'ONLY_FOR_ARCHS' setting?  If the default
effectively becomes 'ONLY_FOR_ARCHS= i386 amd64' then as ports are shown
to work on different platforms they will need an ONLY_FOR_ARCHS line in
their Makefiles listing where they are known to work?  Or else the ports
becomes effectively i386 / amd64 only?

 (Of course, for things like p5-* it doesn't really matter; if perl
 builds, to a first approximation they'll build as well.  I'm talking
 about the things like biology/, deskutils/, games/, math/, science,
 x11*/, and so forth.)
 
 What do people think?

There are a lot of ports where the distinction between CPU architectures
is pretty much irrelevant.  I can't see portmaster(8) (for example)
failing to work anywhere the base system works.

I was thinking about this a while back.  Test the contents of packages
to see if they install any object code -- ports/129210 -- and mark the
ones that don't as arch-independent in some way (CATEGORIES+= arch-indep
perhaps?)

Cheers,

Matthew

-- 
Dr Matthew J Seaman MA, D.Phil.   7 Priory Courtyard
  Flat 3
PGP: http://www.infracaninophile.co.uk/pgpkey Ramsgate
JID: matt...@infracaninophile.co.uk   Kent, CT11 9PW



signature.asc
Description: OpenPGP digital signature


Is there an unofficial graphics/gimp 2.7.4 port?

2012-01-22 Thread Tobias Rehbein
Hi all,

I will participate in a GIMP workshop this wednesday. GIMP 2.7.4 will be used in
this workshop. As this is a development snapshot and therefore not in the ports 
tree I
wondered if anyone on this list has an unofficial port of GIMP 2.7.4 I could
use?

gn...@freebsd.org, being the maintainer of graphics/gimp(-app) is in CC. I am
not subscribed to gn...@freebsd.org so please keep me in CC.

Kind regards,

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


Re: What is the best way to _not_ install licenses?

2012-01-22 Thread Chris Rees
On 22 January 2012 13:13, Da Rock
freebsd-po...@herveybayaustralia.com.au wrote:
 I'm back to resolve some issues with my new port ports/164113.

 I have to not install license as per instructions in the porters handbook
 (which I wasn't aware it was doing). What is the best way to achieve this?

Huh? Why don't you want to install the licence?

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


Re: What is the best way to _not_ install licenses?

2012-01-22 Thread Da Rock

On 01/22/12 23:44, Chris Rees wrote:

On 22 January 2012 13:13, Da Rock
freebsd-po...@herveybayaustralia.com.au  wrote:

I'm back to resolve some issues with my new port ports/164113.

I have to not install license as per instructions in the porters handbook
(which I wasn't aware it was doing). What is the best way to achieve this?

Huh? Why don't you want to install the licence?
According to the handbook there is enough copies to go around and the 
system doesn't need to be overloaded with license copies (GPL only). 
Meh... I'll comply.


http://www.freebsd.org/doc/en_US.ISO8859-1/books/porters-handbook/dads-misc.html
___
freebsd-ports@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-ports
To unsubscribe, send any mail to freebsd-ports-unsubscr...@freebsd.org


Re: so, FreeBSD on VMware is dead, right?

2012-01-22 Thread Matthias Andree
Am 22.01.2012 02:15, schrieb Erich Dollansky:
 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 a lot more
 that would, if just VMware gave us some love (fixed, or helped us fix
 some device drivers).

 He asked how many?

 I do not know anybody who runs FreeBSD in a VM. All run it native on their 
 machines.

I dual-boot FreeBSD, either bare-bones, or into a virtual machine - BUT
that is VirtualBox with the PUEL'ed extension pack, on a 64-bit Linux
amd64 host.

And I don't care about VMWare at all since they took VMWare server 1.x
off the market.
  I've seen their pricing policies since the early days of VMWare
Workstation 1.X many a year ago, and it's ridiculous (meaning way
overpriced), and there are more reasons...

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


Re: What is the best way to _not_ install licenses?

2012-01-22 Thread Chris Rees
On 22 January 2012 13:55, Da Rock
freebsd-po...@herveybayaustralia.com.au wrote:
 On 01/22/12 23:44, Chris Rees wrote:

 On 22 January 2012 13:13, Da Rock
 freebsd-po...@herveybayaustralia.com.au  wrote:

 I'm back to resolve some issues with my new port ports/164113.

 I have to not install license as per instructions in the porters handbook
 (which I wasn't aware it was doing). What is the best way to achieve
 this?

 Huh? Why don't you want to install the licence?

 According to the handbook there is enough copies to go around and the system
 doesn't need to be overloaded with license copies (GPL only). Meh... I'll
 comply.

 http://www.freebsd.org/doc/en_US.ISO8859-1/books/porters-handbook/dads-misc.html

Ah, that refers to people sticking the GPL in to pkg-descr.

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


Re: What is the best way to _not_ install licenses?

2012-01-22 Thread Alexander Leidinger
On Sun, 22 Jan 2012 13:44:25 + Chris Rees cr...@freebsd.org wrote:

 On 22 January 2012 13:13, Da Rock
 freebsd-po...@herveybayaustralia.com.au wrote:
  I'm back to resolve some issues with my new port ports/164113.
 
  I have to not install license as per instructions in the porters
  handbook (which I wasn't aware it was doing). What is the best way
  to achieve this?
 
 Huh? Why don't you want to install the licence?

Seems there's a little bit of confusion around. The port itself is
fine, the version in ports does not install any license. The redports
log he looked at was based upon what he submitted, but it is not what I
committed. So for the port there's nothing to do ATM.

The problem with the licenses framework and the linuxulator ports is,
that the licenses framework assumes, that PREFIX/share does not need to
be removed (it needs to be removed in the linuxulator case). My
workaround was to specify NO_LICENSES_INSTALL=yes.

Another problem is probably, that the licenses framework writes the
license to WRKDIR/license_name and the linuxulator ports install
everything from WRKDIR except WRKDIR/.*. This way we get
PREFIX/license_name, again without a PLIST entry like the PREFIX/share
directory. My workaround was to do a RM PREFIX/license_name in
post-install.

I submitted a PR regarding the deficits of the licenses framework when
used in linuxulator ports.

Bye,
Alexander.

-- 
http://www.Leidinger.netAlexander @ Leidinger.net: PGP ID = B0063FE7
http://www.FreeBSD.org   netchild @ FreeBSD.org  : PGP ID = 72077137
___
freebsd-ports@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-ports
To unsubscribe, send any mail to freebsd-ports-unsubscr...@freebsd.org


Re: What is the best way to _not_ install licenses?

2012-01-22 Thread Da Rock

On 01/23/12 00:54, Chris Rees wrote:

On 22 January 2012 13:55, Da Rock
freebsd-po...@herveybayaustralia.com.au  wrote:

On 01/22/12 23:44, Chris Rees wrote:

On 22 January 2012 13:13, Da Rock
freebsd-po...@herveybayaustralia.com.auwrote:

I'm back to resolve some issues with my new port ports/164113.

I have to not install license as per instructions in the porters handbook
(which I wasn't aware it was doing). What is the best way to achieve
this?

Huh? Why don't you want to install the licence?

According to the handbook there is enough copies to go around and the system
doesn't need to be overloaded with license copies (GPL only). Meh... I'll
comply.

http://www.freebsd.org/doc/en_US.ISO8859-1/books/porters-handbook/dads-misc.html

Ah, that refers to people sticking the GPL in to pkg-descr.
That probably could be clearer... but if it complains about the GPL file 
not being removed from the system on deinstall, what then? It 
specifically mentions plist as well. So what is it supposed to do? Is 
there another linux port that shows how it should be handled correctly 
that I could check out?

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


Re: What is the best way to _not_ install licenses?

2012-01-22 Thread Da Rock

On 01/23/12 01:13, Alexander Leidinger wrote:

On Sun, 22 Jan 2012 13:44:25 + Chris Reescr...@freebsd.org  wrote:


On 22 January 2012 13:13, Da Rock
freebsd-po...@herveybayaustralia.com.au  wrote:

I'm back to resolve some issues with my new port ports/164113.

I have to not install license as per instructions in the porters
handbook (which I wasn't aware it was doing). What is the best way
to achieve this?

Huh? Why don't you want to install the licence?

Seems there's a little bit of confusion around. The port itself is
fine, the version in ports does not install any license. The redports
log he looked at was based upon what he submitted, but it is not what I
committed. So for the port there's nothing to do ATM.

The problem with the licenses framework and the linuxulator ports is,
that the licenses framework assumes, that PREFIX/share does not need to
be removed (it needs to be removed in the linuxulator case). My
workaround was to specify NO_LICENSES_INSTALL=yes.

Another problem is probably, that the licenses framework writes the
license to WRKDIR/license_name and the linuxulator ports install
everything from WRKDIR except WRKDIR/.*. This way we get
PREFIX/license_name, again without a PLIST entry like the PREFIX/share
directory. My workaround was to do a RM PREFIX/license_name in
post-install.
I tried that, but it came up error again. I haven't yet tried with the 
rm in post-extract, but I thought I'd check in first to see if I was on 
the right track.


The other issues I mentioned are a bit of a worry as well. Sorry, I'm a 
bit pedantic :)


Also, what exactly is QATty in reports? It goes with a bang...
___
freebsd-ports@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-ports
To unsubscribe, send any mail to freebsd-ports-unsubscr...@freebsd.org


Re: databases/mysql-workbench52

2012-01-22 Thread t...@diogunix.com
  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
 
 the maintainer thinks it won't work with mysql55
 
 you can delete that line and see what happens.  

Thanks for the hint, Michael.

Unfortunately, I get an error then:

In file included from ./my_global.h:383,
 from mysys_priv.h:17,
 from charset-def.cpp:17:
/usr/include/sys/timeb.h:42:2: warning: #warning this file includes 
sys/timeb.h which is deprecated
In file included from mysys_priv.h:17,
 from charset-def.cpp:17:
./my_global.h:1017: error: redeclaration of C++ built-in type 'bool'
*** Error code 1

Stop in /usr/ports/databases/mysql-workbench52/work/mysql-workbench-
oss-5.2.1/library/sql-parser/source.
*** Error code 1

Stop in /usr/ports/databases/mysql-workbench52/work/mysql-workbench-
oss-5.2.1/library/sql-parser.
*** Error code 1

Stop in /usr/ports/databases/mysql-workbench52/work/mysql-workbench-
oss-5.2.1/library.
*** Error code 1

Stop in /usr/ports/databases/mysql-workbench52/work/mysql-workbench-
oss-5.2.1.
*** Error code 1

Stop in /usr/ports/databases/mysql-workbench52/work/mysql-workbench-
oss-5.2.1.
*** Error code 1

Stop in /usr/ports/databases/mysql-workbench52.
*** Error code 1

Stop in /usr/ports/databases/mysql-workbench52.

 if it works, open a pr
 with a patch.  if you can get it to work, open a pr with a patch.

I could not figure out what's actually up there.

@Maxim:
Is that the reason why you excluded MySQL 55 from that Makefile ?

@all
Is there any chance to somehow get the build working with MySQL 55 ?

kind regards
Tom
___
freebsd-ports@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-ports
To unsubscribe, send any mail to freebsd-ports-unsubscr...@freebsd.org


databases/mysql-workbench52

2012-01-22 Thread t...@diogunix.com
I now tried to build the same port on an older machine ruunning
- FreeBSD 8 / KDE
- MySQL 5.1


Result:

The build was successful in so far as I did not get any compile errors.

But when trying to start the Workbench, it just crashes (needs to get 
killed). There's not even a splash screen. 

Did not do any further investigations so far.

It somehow seems, there are major issues with the Workbench port(s)
which is sad as the Workbench might be seen as an important tool for MySQL 
users on FreeBSD :-(

kind regards
Tom


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


Re: databases/mysql-workbench52

2012-01-22 Thread Chris Rees
On 22 Jan 2012 15:25, t...@diogunix.com t...@diogunix.com wrote:

   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
 
  the maintainer thinks it won't work with mysql55
 
  you can delete that line and see what happens.

 Thanks for the hint, Michael.

 Unfortunately, I get an error then:

 In file included from ./my_global.h:383,
 from mysys_priv.h:17,
 from charset-def.cpp:17:
 /usr/include/sys/timeb.h:42:2: warning: #warning this file includes
 sys/timeb.h which is deprecated
 In file included from mysys_priv.h:17,
 from charset-def.cpp:17:
 ./my_global.h:1017: error: redeclaration of C++ built-in type 'bool'
 *** Error code 1

 Stop in /usr/ports/databases/mysql-workbench52/work/mysql-workbench-
 oss-5.2.1/library/sql-parser/source.
 *** Error code 1

 Stop in /usr/ports/databases/mysql-workbench52/work/mysql-workbench-
 oss-5.2.1/library/sql-parser.
 *** Error code 1

 Stop in /usr/ports/databases/mysql-workbench52/work/mysql-workbench-
 oss-5.2.1/library.
 *** Error code 1

 Stop in /usr/ports/databases/mysql-workbench52/work/mysql-workbench-
 oss-5.2.1.
 *** Error code 1

 Stop in /usr/ports/databases/mysql-workbench52/work/mysql-workbench-
 oss-5.2.1.
 *** Error code 1

 Stop in /usr/ports/databases/mysql-workbench52.
 *** Error code 1

 Stop in /usr/ports/databases/mysql-workbench52.

  if it works, open a pr
  with a patch.  if you can get it to work, open a pr with a patch.

 I could not figure out what's actually up there.

 @Maxim:
 Is that the reason why you excluded MySQL 55 from that Makefile ?

Looks like some incompatibility; perhaps it reimplements something now
included by mysql.

Let's assume that was the reason, and let's not ask Maxim any more
questions on it directly-- he's resigned as maintainer and can chose to
answer questions on ports@ if he chooses :)

 @all
 Is there any chance to somehow get the build working with MySQL 55 ?

Have you contacted upstream?

 kind regards
 Tom
___
freebsd-ports@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-ports
To unsubscribe, send any mail to freebsd-ports-unsubscr...@freebsd.org


Re: Is there an unofficial graphics/gimp 2.7.4 port?

2012-01-22 Thread Olivier Duchateau
2012/1/22 Tobias Rehbein tobias.rehb...@web.de:
 Hi all,

 I will participate in a GIMP workshop this wednesday. GIMP 2.7.4 will be used 
 in
 this workshop. As this is a development snapshot and therefore not in the 
 ports tree I
 wondered if anyone on this list has an unofficial port of GIMP 2.7.4 I could
 use?

 gn...@freebsd.org, being the maintainer of graphics/gimp(-app) is in CC. I am
 not subscribed to gn...@freebsd.org so please keep me in CC.

 Kind regards,

     Tobias


When Gimp 2.7.3 was released, I have done an unofficial port, but not
with 2.7.4.
You can try this one, be careful, I use an old version of poppler-gtk.

You can clone my mercurial repository:
hg clone https://code.google.com/p/olivier-freebsd-ports/

The Gimp is found in graphics/gimp.



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


Re: so, FreeBSD on VMware is dead, right?

2012-01-22 Thread Andriy Gapon
on 22/01/2012 16:12 Matthias Andree said the following:
 Am 22.01.2012 02:15, schrieb Erich Dollansky:
 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 a lot more
 that would, if just VMware gave us some love (fixed, or helped us fix
 some device drivers).

 He asked how many?

 I do not know anybody who runs FreeBSD in a VM. All run it native on their 
 machines.
 
 I dual-boot FreeBSD, either bare-bones, or into a virtual machine - BUT
 that is VirtualBox with the PUEL'ed extension pack, on a 64-bit Linux
 amd64 host.
 
 And I don't care about VMWare at all since they took VMWare server 1.x
 off the market.
   I've seen their pricing policies since the early days of VMWare
 Workstation 1.X many a year ago, and it's ridiculous (meaning way
 overpriced), and there are more reasons...

I appreciate your and Erich's urge to speak out in this thread, but the
thread-starter asked about something different.

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


Re: so, FreeBSD on VMware is dead, right?

2012-01-22 Thread Olli Hauer
On 2012-01-21 21:12, Michael Scheidell 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 some device drivers).
 
 He asked how many?
 
 Well, I sure can't go back to him and tell him that there was only one 
 company who contacted me back who said that they used VMware in production 
 systems, with FreeBSD guest os.
 
 If there isn't anyone else with VMware problems, and I really want to be 
 clear:  VMware is a 'for profit' company, so, small numbers won't impress 
 them, but if there are any companies (aside from the one that contacted me.. 
 you don't have to again, I have your email).
 
 If no one else, I'll call him back on the phone and apologize for bothering 
 him.
 
 I was really hoping to get some of the virtual nic issues, and hgfs issues 
 worked out, but, I guess there isn't enough commercial interest.


count +1 from me.
Except my private test/build machine I run everything on ESX clusters
___
freebsd-ports@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-ports
To unsubscribe, send any mail to freebsd-ports-unsubscr...@freebsd.org


Re: so, FreeBSD on VMware is dead, right?

2012-01-22 Thread Olli Hauer
On 2012-01-22 15:12, Matthias Andree wrote:
 Am 22.01.2012 02:15, schrieb Erich Dollansky:
 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 a lot more
 that would, if just VMware gave us some love (fixed, or helped us fix
 some device drivers).

 He asked how many?

 I do not know anybody who runs FreeBSD in a VM. All run it native on their 
 machines.
 
 I dual-boot FreeBSD, either bare-bones, or into a virtual machine - BUT
 that is VirtualBox with the PUEL'ed extension pack, on a 64-bit Linux
 amd64 host.
 
 And I don't care about VMWare at all since they took VMWare server 1.x
 off the market.
   I've seen their pricing policies since the early days of VMWare
 Workstation 1.X many a year ago, and it's ridiculous (meaning way
 overpriced), and there are more reasons...

Private and enterprise are two different things (also in prising)
If our devs need a machine for testing or a project I can deploy a new machine 
in short time at one of our data-centers which is not doable with bare metal.

For private you can use the free ESXi and small corporates can use the 
foundation version ( less then 1000,- for three servers including VCenter ).
Most companies I know run everything virtual, one of the big plus is having all 
servers the same (virtual) HW platform, load balancing, failover 
___
freebsd-ports@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-ports
To unsubscribe, send any mail to freebsd-ports-unsubscr...@freebsd.org


Re: so, FreeBSD on VMware is dead, right?

2012-01-22 Thread Vinny Abello
On 1/22/2012 9:12 AM, Matthias Andree wrote:
 Am 22.01.2012 02:15, schrieb Erich Dollansky:
 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 a lot more
 that would, if just VMware gave us some love (fixed, or helped us fix
 some device drivers).

 He asked how many?

 I do not know anybody who runs FreeBSD in a VM. All run it native on their 
 machines.
 
 I dual-boot FreeBSD, either bare-bones, or into a virtual machine - BUT
 that is VirtualBox with the PUEL'ed extension pack, on a 64-bit Linux
 amd64 host.
 
 And I don't care about VMWare at all since they took VMWare server 1.x
 off the market.
   I've seen their pricing policies since the early days of VMWare
 Workstation 1.X many a year ago, and it's ridiculous (meaning way
 overpriced), and there are more reasons...

FWIW, I have around a dozen FreeBSD machines in production under VMWare
ESXi for network telemetry and caching name servers.

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


Re: so, FreeBSD on VMware is dead, right?

2012-01-22 Thread Rich Winkel
FWIW, we're running a number of fbsd servers under vmware here at 
missouri.edu.  Aside from ntpd issues, remedied by running ntpdate from 
cron, there have been no problems that I'm aware of.  I can forward a 
8.2 kernel config to anyone who's interested.  It's nothing

special though.

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


Re: so, FreeBSD on VMware is dead, right?

2012-01-22 Thread Peter Beckman

On Sun, 22 Jan 2012, Erich Dollansky wrote:


I wonder why I should run FreeBSD under VMware.


 There is some Dell Blade Hardware that I could not get to run FreeBSD 8.
 So I installed ESXi and installed FreeBSD as a VM so I didn't have to
 switch providers.  It works OK.


I do not know anybody who runs FreeBSD in a VM. All run it native on their 
machines.


 I run two.  But I use ESXi (the free version); I only have paid for VMware
 Fusion.

---
Peter Beckman  Internet Guy
beck...@angryox.com http://www.angryox.com/
---
___
freebsd-ports@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-ports
To unsubscribe, send any mail to freebsd-ports-unsubscr...@freebsd.org


Re: databases/mysql-workbench52

2012-01-22 Thread t...@diogunix.com

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
   
   you can delete that line and see what happens.
  
  Thanks for the hint, Michael.
  
  Unfortunately, I get an error then:
  
  In file included from ./my_global.h:383,
  
  from mysys_priv.h:17,
  
  from charset-def.cpp:17:
  /usr/include/sys/timeb.h:42:2: warning: #warning this file includes
  sys/timeb.h which is deprecated
  In file included from mysys_priv.h:17,
  
  from charset-def.cpp:17:
  ./my_global.h:1017: error: redeclaration of C++ built-in type 'bool'
  *** Error code 1
  
  Stop in /usr/ports/databases/mysql-workbench52/work/mysql-workbench-
  oss-5.2.1/library/sql-parser/source.
  *** Error code 1
  
  Stop in /usr/ports/databases/mysql-workbench52/work/mysql-workbench-
  oss-5.2.1/library/sql-parser.
  *** Error code 1
  
  Stop in /usr/ports/databases/mysql-workbench52/work/mysql-workbench-
  oss-5.2.1/library.
  *** Error code 1
  
  Stop in /usr/ports/databases/mysql-workbench52/work/mysql-workbench-
  oss-5.2.1.
  *** Error code 1
  
  Stop in /usr/ports/databases/mysql-workbench52/work/mysql-workbench-
  oss-5.2.1.
  *** Error code 1
  
  Stop in /usr/ports/databases/mysql-workbench52.
  *** Error code 1
  
  Stop in /usr/ports/databases/mysql-workbench52.
  
  I could not figure out what's actually up there.
  
 Looks like some incompatibility; perhaps it reimplements something now
 included by mysql.
 
 Let's assume that was the reason

  @all
  Is there any chance to somehow get the build working with MySQL 55 ?
 
 Have you contacted upstream?

I'm terribly sorry but I'm not familiar with the term upstream.

Do you mean the MySQL team at Sun/Oracle ?
Then the answer is no. The list here is my only contact so far.

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


acroread8/9 cups support (Re: acroead8 and libcups dependencies)

2012-01-22 Thread Hiroki Sato
Da Rock freebsd-po...@herveybayaustralia.com.au wrote
  in 4f139c43.1050...@herveybayaustralia.com.au:

fr I'm trying to contact the maintainer of the acroread ports to see if
fr they can put in a dependency on linux-f10-cups-libs for the ease of
fr use by general users, and to enable acceptance by the graphics
fr industry niche.

Cejka Rudolf cej...@fit.vutbr.cz wrote
  in 2002110904.ga...@fit.vutbr.cz:

ce   do you have plans to add support for cups printing from acroread9-9.4.2?

 I added CUPS support into both acroread8 and acroread9.  It seems
 working as far as I can check all versions in the ports tree, but
 please test them.  Thank you.

-- Hiroki


pgpBi2Ilo8Ev4.pgp
Description: PGP signature


Re: acroread8/9 cups support (Re: acroead8 and libcups dependencies)

2012-01-22 Thread Da Rock

On 01/23/12 16:28, Hiroki Sato wrote:

Da Rockfreebsd-po...@herveybayaustralia.com.au  wrote
   in4f139c43.1050...@herveybayaustralia.com.au:

fr  I'm trying to contact the maintainer of the acroread ports to see if
fr  they can put in a dependency on linux-f10-cups-libs for the ease of
fr  use by general users, and to enable acceptance by the graphics
fr  industry niche.

Cejka Rudolfcej...@fit.vutbr.cz  wrote
   in2002110904.ga...@fit.vutbr.cz:

cedo you have plans to add support for cups printing from acroread9-9.4.2?

  I added CUPS support into both acroread8 and acroread9.  It seems
  working as far as I can check all versions in the ports tree, but
  please test them.  Thank you.

-- Hiroki

Will do.

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


Re: acroread8/9 cups support (Re: acroead8 and libcups dependencies)

2012-01-22 Thread Rainer Hurling

Am 23.01.2012 07:28 (UTC+1) schrieb Hiroki Sato:

Da Rockfreebsd-po...@herveybayaustralia.com.au  wrote
   in4f139c43.1050...@herveybayaustralia.com.au:

fr  I'm trying to contact the maintainer of the acroread ports to see if
fr  they can put in a dependency on linux-f10-cups-libs for the ease of
fr  use by general users, and to enable acceptance by the graphics
fr  industry niche.

Cejka Rudolfcej...@fit.vutbr.cz  wrote
   in2002110904.ga...@fit.vutbr.cz:

cedo you have plans to add support for cups printing from acroread9-9.4.2?

  I added CUPS support into both acroread8 and acroread9.  It seems
  working as far as I can check all versions in the ports tree, but
  please test them.  Thank you.


I can confirm that acroread9 does work with CUPS for a longer time now 
and it works well.


Rainer


-- Hiroki

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