FreeBSD unmaintained ports which are currently scheduled for deletion

2013-10-21 Thread linimon
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 the existing port.  In some cases,
ports are marked for removal because they fail to build and install
correctly from their sources, or otherwise fail in operation.

The ports, and the reason and date that they have been scheduled
for removal, are listed below.  If no one has stepped forward before
that time to propose a way to fix the problems (such as via a PR),
the ports will be deleted.



portname:   biology/dotter
description:A viewer for multiple sequence alignments
maintainer: po...@freebsd.org
status: BROKEN
deprecated because: Broken for more than 6 month
expiration date:2013-11-18
build errors:   none.
overview:   
http://portsmon.FreeBSD.org/portoverview.py?category=biologyportname=dotter


portname:   devel/libXGP
description:Yet another General Purpose library
maintainer: po...@freebsd.org
deprecated because: Broken for more than 6 month
expiration date:2013-11-18
build errors:   none.
overview:   
http://portsmon.FreeBSD.org/portoverview.py?category=develportname=libXGP


portname:   devel/libYGP
description:Yet another General Purpose library
maintainer: po...@freebsd.org
status: BROKEN
deprecated because: Broken for more than 6 month
expiration date:2013-11-18
build errors:   none.
overview:   
http://portsmon.FreeBSD.org/portoverview.py?category=develportname=libYGP


portname:   devel/ros_comm
description:Robot Operating System - communication-related
utilities
maintainer: po...@freebsd.org
status: BROKEN
deprecated because: Broken for more than 6 month
expiration date:2013-11-18
build errors:   none.
overview:   
http://portsmon.FreeBSD.org/portoverview.py?category=develportname=ros_comm


portname:   dns/opendd
description:A small DynDNS client
maintainer: po...@freebsd.org
status: BROKEN
deprecated because: Broken for more than 6 month
expiration date:2013-11-18
build errors:   none.
overview:   
http://portsmon.FreeBSD.org/portoverview.py?category=dnsportname=opendd


portname:   editors/mode-info
description:Functions to refer Manuals on Emacsen with describe-*
like interface
maintainer: po...@freebsd.org
status: BROKEN
deprecated because: Misbuilding since 2004, not maintained since 2008
expiration date:2013-11-20
build errors:   none.
overview:   
http://portsmon.FreeBSD.org/portoverview.py?category=editorsportname=mode-info


portname:   editors/xml2rfc-xxe
description:xml2rfc configuration for XMLMind XML editor
maintainer: po...@freebsd.org
deprecated because: Depends on editors/xxe, which is due to be removed due
to lack of maintainer
expiration date:2013-11-15
build errors:   none.
overview:   
http://portsmon.FreeBSD.org/portoverview.py?category=editorsportname=xml2rfc-xxe


portname:   editors/xxe
description:Validating XML editor featuring a word processor-like
view
maintainer: po...@freebsd.org
status: BROKEN
deprecated because: XXE becomes unfetchable every 3-4 months as distfile
is replaced with new version.  This high-maintenance
port requires a maintainer to avoid removal.
expiration date:2013-11-15
build errors:   none.
overview:   
http://portsmon.FreeBSD.org/portoverview.py?category=editorsportname=xxe


portname:   games/daimonin-music
description:Music for daimonin client
maintainer: po...@freebsd.org
status: BROKEN
deprecated because: Broken for more than 6 month
expiration date:2013-11-18
build errors:   none.
overview:   
http://portsmon.FreeBSD.org/portoverview.py?category=gamesportname=daimonin-music


portname:   japanese/mobileimap
description:An IMAP-based webmail system for mobile-phones
maintainer: po...@freebsd.org
status: BROKEN
deprecated because: Broken for more than 6 month
expiration date:2013-11-18
build errors:   none.
overview:   
http://portsmon.FreeBSD.org/portoverview.py?category=japaneseportname=mobileimap


portname:   lang/objc
description:Portable Object Compiler
maintainer: po...@freebsd.org
status: BROKEN
deprecated because: Broken for more than 6 month
expiration date:2013-11-18
build errors:   none.
overview:   
http://portsmon.FreeBSD.org/portoverview.py?category=langportname=objc



FreeBSD unmaintained ports which are currently marked broken

2013-10-21 Thread linimon
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 problem is that recent versions
of -CURRENT include gcc4.2, which is much stricter than older versions.
The next most common problem is that compiles succeed on the i386
architecture (e.g. the common Intel PC), but fail on one or more
of the other architectures due to assumptions about things such as
size of various types, byte-alignment issues, and so forth.

In occasional cases we see that the same port may have different
errors in different build environments.  The script that runs on the
build cluster uses heuristics to try to 'guess' the error type to
help you isolate problems, but it is only a rough guide.

One more note: on occasion, there are transient build errors seen
on the build farm.  Unfortunately, there is not yet any way for this
algorithm to tell the difference (humans are much, much better at
this kind of thing.)

The errors are listed below.  In the case where the same problem
exists on more than one build environment, the URL points to the
latest errorlog for that type.  (By 'build environment' here we
mean 'combination of 7.x/8.x/9.x/-current with target architecture'.)

(Note: the dates are included to help you to gauge whether or not
the error still applies to the latest version.  The program
that generates this report is not yet able to determine this
automatically.)

portname:   biology/dotter
broken because: checksum mismatch
build errors:   none.
overview:   
http://portsmon.FreeBSD.org/portoverview.py?category=biologyportname=dotter


portname:   biology/finchtv
broken because: fails to checksum
build errors:   none.
overview:   
http://portsmon.FreeBSD.org/portoverview.py?category=biologyportname=finchtv


portname:   chinese/big5con
broken because: fails to build with new utmpx
build errors:   none.
overview:   
http://portsmon.FreeBSD.org/portoverview.py?category=chineseportname=big5con


portname:   chinese/hztty
broken because: fails to build with new utmpx
build errors:   none.
overview:   
http://portsmon.FreeBSD.org/portoverview.py?category=chineseportname=hztty


portname:   converters/p5-Unicode-Lite
broken because: Overwrites bin/map from converters/p5-Unicode-Map
build errors:   none.
overview:   
http://portsmon.FreeBSD.org/portoverview.py?category=convertersportname=p5-Unicode-Lite


portname:   databases/grass
broken because: Does not build
build errors:   none.
overview:   
http://portsmon.FreeBSD.org/portoverview.py?category=databasesportname=grass


portname:   databases/msql
broken because: Broken on FreeBSD 9+
build errors:   none.
overview:   
http://portsmon.FreeBSD.org/portoverview.py?category=databasesportname=msql


portname:   deskutils/libopensync-plugin-python-devel
broken because: fails to build with recent libopensync
build errors:   none.
overview:   
http://portsmon.FreeBSD.org/portoverview.py?category=deskutilsportname=libopensync-plugin-python-devel


portname:   devel/bzr-grep
broken because: conflicts with dependency bzr
build errors:   none.
overview:   
http://portsmon.FreeBSD.org/portoverview.py?category=develportname=bzr-grep


portname:   devel/libYGP
broken because: Does not build with recent boost
build errors:   none.
overview:   
http://portsmon.FreeBSD.org/portoverview.py?category=develportname=libYGP


portname:   devel/lua50-dfui
broken because: Does not build
build errors:
http://pointyhat.freebsd.org/errorlogs/amd64-errorlogs/e.10.20130313090402.pointyhat/lua50-dfui-0.1.20050901.log
 (Mar 14 00:26:27 UTC 2013)
overview:   
http://portsmon.FreeBSD.org/portoverview.py?category=develportname=lua50-dfui


portname:   devel/mico
broken because: fails to build
build errors:   none.
overview:   
http://portsmon.FreeBSD.org/portoverview.py?category=develportname=mico


portname:   devel/ros_comm
broken because: does not build
build errors:   none.
overview:   
http://portsmon.FreeBSD.org/portoverview.py?category=develportname=ros_comm


portname:   dns/opendd
broken because: segfaults upon use
build errors:   none.
overview:   
http://portsmon.FreeBSD.org/portoverview.py?category=dnsportname=opendd


portname:   editors/mode-info
broken because: Requires make.info from gmake which has been gone
since 2004
build errors:   none.
overview:   
http://portsmon.FreeBSD.org/portoverview.py?category=editorsportname=mode-info


portname:   editors/xemacs-devel-mule
broken because:   

FreeBSD ports which are currently marked broken

2013-10-21 Thread linimon
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 problem is that recent versions
of -CURRENT include gcc4.2, which is much stricter than older versions.
The next most common problem is that compiles succeed on the i386
architecture (e.g. the common Intel PC), but fail on one or more
of the other architectures due to assumptions about things such as
size of various types, byte-alignment issues, and so forth.

In occasional cases we see that the same port may have different
errors in different build environments.  The script that runs on the
build cluster uses heuristics to try to 'guess' the error type to
help you isolate problems, but it is only a rough guide.

One more note: on occasion, there are transient build errors seen
on the build farm.  Unfortunately, there is not yet any way for this
algorithm to tell the difference (humans are much, much better at
this kind of thing.)

The errors are listed below.  In the case where the same problem
exists on more than one build environment, the URL points to the
latest errorlog for that type.  (By 'build environment' here we
mean 'combination of 7.x/8.x/9.x/-current with target architecture'.)

(Note: the dates are included to help you to gauge whether or not
the error still applies to the latest version.  The program
that generates this report is not yet able to determine this
automatically.)

portname:   accessibility/yasr
broken because: fails to build with new utmpx
build errors:   none.
overview:   
http://portsmon.FreeBSD.org/portoverview.py?category=accessibilityportname=yasr


portname:   biology/dotter
broken because: checksum mismatch
build errors:   none.
overview:   
http://portsmon.FreeBSD.org/portoverview.py?category=biologyportname=dotter


portname:   biology/finchtv
broken because: fails to checksum
build errors:   none.
overview:   
http://portsmon.FreeBSD.org/portoverview.py?category=biologyportname=finchtv


portname:   cad/salome-geom
broken because: fails to build
build errors:   none.
overview:   
http://portsmon.FreeBSD.org/portoverview.py?category=cadportname=salome-geom


portname:   cad/salome-kernel
broken because: Does not configure
build errors:   none.
overview:   
http://portsmon.FreeBSD.org/portoverview.py?category=cadportname=salome-kernel


portname:   cad/salome-med
broken because: Fails to fetch
build errors:   none.
overview:   
http://portsmon.FreeBSD.org/portoverview.py?category=cadportname=salome-med


portname:   cad/salome-yacs
broken because: fails to build
build errors:   none.
overview:   
http://portsmon.FreeBSD.org/portoverview.py?category=cadportname=salome-yacs


portname:   chinese/big5con
broken because: fails to build with new utmpx
build errors:   none.
overview:   
http://portsmon.FreeBSD.org/portoverview.py?category=chineseportname=big5con


portname:   chinese/hztty
broken because: fails to build with new utmpx
build errors:   none.
overview:   
http://portsmon.FreeBSD.org/portoverview.py?category=chineseportname=hztty


portname:   converters/p5-Unicode-Lite
broken because: Overwrites bin/map from converters/p5-Unicode-Map
build errors:   none.
overview:   
http://portsmon.FreeBSD.org/portoverview.py?category=convertersportname=p5-Unicode-Lite


portname:   converters/pdf2djvu
broken because: does not build
build errors:
http://pointyhat.freebsd.org/errorlogs/amd64-errorlogs/e.10.20130313090402.pointyhat/pdf2djvu-0.5.11_10.log
 (Mar 14 00:22:50 UTC 2013)
overview:   
http://portsmon.FreeBSD.org/portoverview.py?category=convertersportname=pdf2djvu


portname:   converters/py-svglib
broken because: Does not fetch
build errors:   none.
overview:   
http://portsmon.FreeBSD.org/portoverview.py?category=convertersportname=py-svglib


portname:   databases/drizzle
broken because: fails to build
build errors:   none.
overview:   
http://portsmon.FreeBSD.org/portoverview.py?category=databasesportname=drizzle


portname:   databases/gomysql
broken because: Does not compile with go1
build errors:   none.
overview:   
http://portsmon.FreeBSD.org/portoverview.py?category=databasesportname=gomysql


portname:   databases/grass
broken because: Does not build
build errors:   none.
overview:   
http://portsmon.FreeBSD.org/portoverview.py?category=databasesportname=grass


portname:   databases/ludia
broken because: Does not work with postgresql-9.0 or postgresql-8.4
build errors:   none.
overview:   

FreeBSD ports which are currently marked forbidden

2013-10-21 Thread linimon
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, including errors seen on the build farm,
is included below.

portname:   lang/ruby18
forbidden because:  Vulernerable,

http://vuxml.org/freebsd/ebd877b9-7ef4-4375-b1fd-c67780581898.html
build errors:   none.
overview:   
http://portsmon.FreeBSD.org/portoverview.py?category=langportname=ruby18
___
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: 10.0-hosted tinderbox: 8.4 builds broken?

2013-10-21 Thread Alexey Dokuchaev
On Sun, Oct 20, 2013 at 07:05:20PM +0100, Chris Rees wrote:
 On 2013-10-20 15:51, Alexey Dokuchaev wrote:
  However I've noticed another regression: doing chmod g+w
  /usr/ports/distfiles in the middle of the tinder run totally confuses
  it: all build attempts after chmod fail with identical tiny log files:
 
building lcms2-2.5 in directory /usr/home/danfe/tb/9.2-wip
make: cannot open /a/ports/Mk/bsd.port.mk.
cd: /usr/ports/graphics/lcms2: No such file or directory
 
 This annoys me for the same reason, and eventually I gave up doing make
 fetch without sudo :P
 
 I would very much like to fix that, so I shall try to see what I can do.

That would be much appreciated Chris!  And I have some more here: if plist
is broken for one of the dependent ports (not sure if it happens for staged
ports only or not), remaining ports also fail to build with two-line logs:

  building foobar-1.42 in directory /usr/home/danfe/tb/10.0-wip
  jexec: getpwnam: root: No such file or directory

./danfe
___
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


FreeBSD ports you maintain which are out of date

2013-10-21 Thread portscout
Dear port maintainer,

The portscout new distfile checker has detected that one or more of your
ports appears to be out of date. Please take the opportunity to check
each of the ports listed below, and if possible and appropriate,
submit/commit an update. If any ports have already been updated, you can
safely ignore the entry.

You will not be e-mailed again for any of the port/version combinations
below.

Full details can be found at the following URL:
http://portscout.freebsd.org/po...@freebsd.org.html


Port| Current version | New version
+-+
math/labplot| 2.0.0.alpha3| 2.0.0.beta1
+-+


If any of the above results are invalid, please check the following page
for details on how to improve portscout's detection and selection of
distfiles on a per-port basis:

http://portscout.freebsd.org/info/portscout-portconfig.txt

If wish to stop receiving portscout reminders, please contact
portsc...@freebsd.org

Thanks.
___
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: poudriere distfiles - explain the process

2013-10-21 Thread Lars Engels

Am 10.10.2013 13:56, schrieb Bryan Drewery:

On 10/10/2013 5:00 AM, Anton Shterenlikht wrote:

I've run poudriere distclean -n.
It took about an hour.
All the time /usr/ports/distfiles was empty,
which was confirmed at the end:

*skip*

OME}})
make: Fatal errors encountered -- cannot continue
clang: not found
make: /pdr/ports/lang/v8/Makefile line 24: warning: Couldn't read 
shell's output for clang --version | /usr/bin/head -1 | /usr/bin/sed 
-e 's/.*clang version \([0-9]\)\.\([0-9]\).*/\1\2/'
make: /pdr/ports/mail/p5-Sendmail-Milter/Makefile line 22: warning: 
Couldn't read shell's output for /usr/local/bin/perl5.16.3 
-V:usethreads | /usr/bin/awk '/define/ { print define; exit }'


 Gathering list of actual distfiles
 No stale distfiles to cleanup
#

So what was it doing all this time?
I think I probably misunderstand
the purpose of poudriere distclean.
It's not just checking all exising
files under /usr/ports/distfiles
to see which are outdated, is it?
It's traversing the whole of the
ports tree, right? Why?


It is looking at every port's Makefile you specify and then comparing 
to

the distfiles you have. Perhaps it can be optimized more.



Maybe that can be written to a sqlite database?
pkgng already uses them, so poudriere could do the same.
Add the distfiles on the first run of distclean and then update the 
database
every time portsnap update is run. Maybe even better if the database 
was part

of the ports tree, just like the INDEX files.
___
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: poudriere distfiles - explain the process

2013-10-21 Thread Matthew Seaman
On 10/21/13 11:39, Lars Engels wrote:
 Maybe that can be written to a sqlite database?
 pkgng already uses them, so poudriere could do the same.
 Add the distfiles on the first run of distclean and then update the
 database
 every time portsnap update is run. Maybe even better if the database
 was part
 of the ports tree, just like the INDEX files.

pkgng doesn't know anything about distfiles.  By the time pkgng gets
it's claws into a new package it's already been compiled and the whole
question of what distfiles it was compiled from is pretty much moot.

Adding tracking of distfiles to /var/db/pkg/local.sqlite isn't going to
be something we put into pkgng -- it's basically not what pkgng is all
about.

On the other hand, if you want to hack on poudriere to give it more
intelligent distfile tracking capabilities, possibly involving storing
data via sqlite in some other file under /var/db/pkg then I'm sure that
would be received with interest.  (Although maybe not the sqlite part --
poudriere is currently pure shell with minimal dependencies, which is a
good thing.)

Cheers,

Matthew






signature.asc
Description: OpenPGP digital signature


Current unassigned ports problem reports

2013-10-21 Thread FreeBSD bugmaster
(Note: an HTML version of this report is available at
http://www.freebsd.org/cgi/query-pr-summary.cgi?category=ports .)

The following is a listing of current problems submitted by FreeBSD users.
These represent problem reports covering all versions including
experimental development code and obsolete releases.


S Tracker  Resp.  Description

o ports/183149[maintainer update] www/glpi 0.84.2
f ports/183146[PATCH] Update net/ladvd to 1.0.4
o ports/183144x11-wm/compiz-plugins-main: compiz broken on 11-curren
o ports/183128[patch update] databases/cego 2.19.6 - 2.19.7
f ports/183127Update java/jakarta-struts to version 1.2.9
o ports/183125maintainer-update of mail/mutt
f ports/183124audio/alsa-plugins failed to build
o ports/183122graphics/sane-backends fails to build
o ports/183117New port: misc/flag - Produce a colourful flag from th
o ports/183115Resign maintainership or deprecate net-im/linux-ymesse
f ports/183112security/sguil-server broken Makefile
o ports/183111[patch update] textproc/htmltolatex: fix build, stagin
o ports/183109[patch update] devel/lfcbase 1.5.7 - 1.5.8, staging
o ports/183105new port: misc/ppiled controls leds connected to paral
f ports/183066security/libgcrypt builds on powerpc
f ports/183062[PATCH] graphics/squish: respect LOCALBASE, support st
o ports/183060[NEW PORT]  devel/thrift-cpp
f ports/183059[UPDATE]  net/scribe
o ports/183058[MAINTAINER]  devel/rubygem-thrift
o ports/183057[NEW PORT]  devel/thrift-c_glib
o ports/183056[MAINTAINER]  devel/fb303
o ports/183055[MAINTAINER]  devel/php5-thrift
o ports/183054[MAINTAINER]  devel/py-thrift
o ports/183053[MAINTAINER]  devel/thrift
o ports/183041devel/ioncube update to 4.4.4
f ports/183029net-mgmt/darkstat does not show graphs
o ports/183023Update to sysutils/copytape to fix compile errors
f ports/183017security/sssd won't compile
o ports/183009[MAINTAINER] devel/ChipmunkPhysics: update to 6.2.0
o ports/182997Package creation failure - stagedir startup script mis
o ports/182983New port: audio/icecast-kh Streaming audio server
o ports/182979audio/cantus: endless loop in configure
o ports/182973[PATCH] databases/mdbtools: update to 0.7.1
f ports/182958[update] devel/json-c to 0.11
o ports/182947www/apache22-peruser-mpm reload fix
o ports/182946[maintainer-update] devel/awscli - update to 1.1.2
o ports/182928[PATCH] Add stagedir support to x11/tint and cleanup
o ports/182923some ports still require WITH_PKGNG=1
o ports/182915net/proxychains - multiple issues
o ports/182913[MAINTAINER-UPDATE] Update games/stonesoup and games/s
o ports/182893multimedia/dv2sub - fix brokenness of package build wh
f ports/182892Make devel/atf create a tests user
f ports/182869minicron install error
f ports/182865fontconfig errors in x11-fonts/wqy
f ports/182853ports/textproc/urlview: regex - pcreregex
f ports/182848[maintainer update] [stagedir] multimedia/ffmpegthumbn
o ports/182843net-im/jabber crashes when compiled with clang 3.3
f ports/182840net-mgmt/smokeping build with perl 5.18 installed
f ports/182834ports/www/dummyflash/Makefile add BUILD_DEPENDS= gcc:p
o ports/182829sysutils/linux-afaapps: missing dependency (devel/linu
f ports/182826deskutils/fet update to 5.20.1
o ports/182802science/gwyddion: Update to version 2.32
o ports/182801emulators/mame: Update to version 0.150
o ports/182800science/qcl: Update to version 0.6.3
o ports/182797games/xdeblock: Fix build with clang
o ports/182796x11-wm/jwm: Update to version 2.1.0
a ports/182793Updating graphics/ImageMagick
o ports/182792dns/knot: knotd startup script no longer works
o ports/182791New port: multimedia/livestreamer pipe video streams i
f ports/182780Port sysutils/ddrescue version 1.17 upgrade [patch]
o ports/182774[MAINTAINER-UPDATE]: graphics/apvlv Link to pthread di
o ports/182771new port devel/gitlab_git
o ports/182770new port textproc/gitlab-grit
o ports/182769[patch] Update games/stockfish to version 4
o ports/182767new port www/gitlab-grack
o ports/182766new port net/gitlab_omniauth-ldap
o ports/182763new port devel/font-awesome-rails
o ports/182762new port www/jquery-atwho-rails
f ports/182758  

Re: iconv in base breaks multiple ports

2013-10-21 Thread Tilman Keskinöz
hi Ulrich,

* Ulrich Spörlein [Sun, 20 Oct 2013 20:27:23 +0200]:
 ever since that iconv thing replaced the ports version, I run into
 trouble with several ports that I have installed on a -CURRENT (now
 stable/10 system).
 
 These are not compile-time errors, but crashes or limited functionality
 where I blame iconv :)
 
 
 1. www/newsbeuter crashes during startup, somewhere in the stfl code
 that deals with wide char functions.
 

 Is my system hexed? I've rebuilt the ports/packages a dozen times now.
 Am I seeing ghosts?


I don't run Current, but according to the pkg-fallout mails i am
receiving, newsbeuter shouldn't even compile on CURRENT. Maybe there are
some stale files on your system?

There is also an update in the PR system, you might want to try,
http://www.freebsd.org/cgi/query-pr.cgi?pr=ports/182896






___
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


[QAT] r331130: 4x leftovers

2013-10-21 Thread Ports-QAT
devel/py-billiard: update to 3.3.0.0

- Update to 3.3.0.0
- Use autoplist
-

  Build ID:  20131021124800-15508
  Job owner: w...@freebsd.org
  Buildtime: 9 minutes
  Enddate:   Mon, 21 Oct 2013 12:57:20 GMT

  Revision:  r331130
  Repository:
https://svnweb.freebsd.org/ports?view=revisionrevision=331130

-

Port:devel/py-billiard 3.3.0.0

  Buildgroup: 8.4-QAT/amd64
  Buildstatus:   LEFTOVERS
  Log: 
https://qat.redports.org//~w...@freebsd.org/20131021124800-15508-210828/py27-billiard-3.3.0.0.log

  Buildgroup: 8.4-QAT/i386
  Buildstatus:   LEFTOVERS
  Log: 
https://qat.redports.org//~w...@freebsd.org/20131021124800-15508-210829/py27-billiard-3.3.0.0.log

  Buildgroup: 9.2-QAT/amd64
  Buildstatus:   LEFTOVERS
  Log: 
https://qat.redports.org//~w...@freebsd.org/20131021124800-15508-210830/py27-billiard-3.3.0.0.log

  Buildgroup: 9.2-QAT/i386
  Buildstatus:   LEFTOVERS
  Log: 
https://qat.redports.org//~w...@freebsd.org/20131021124800-15508-210831/py27-billiard-3.3.0.0.log


--
Buildarchive URL: https://qat.redports.org/buildarchive/20131021124800-15508
redports https://qat.redports.org/
___
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


[QAT] r331138: 4x leftovers

2013-10-21 Thread Ports-QAT
Switch to ffmpeg 0.x [1]. This should resolve building failures with ffmpeg 2.x.

Submitted by:   wg@ [1]
-

  Build ID:  20131021133400-60615
  Job owner: k...@freebsd.org
  Buildtime: 12 minutes
  Enddate:   Mon, 21 Oct 2013 13:46:23 GMT

  Revision:  r331138
  Repository:
https://svnweb.freebsd.org/ports?view=revisionrevision=331138

-

Port:net/opal 3.10.10_2

  Buildgroup: 8.4-QAT/amd64
  Buildstatus:   LEFTOVERS
  Log: 
https://qat.redports.org//~k...@freebsd.org/20131021133400-60615-210852/opal-3.10.10_2.log

  Buildgroup: 8.4-QAT/i386
  Buildstatus:   LEFTOVERS
  Log: 
https://qat.redports.org//~k...@freebsd.org/20131021133400-60615-210853/opal-3.10.10_2.log

  Buildgroup: 9.2-QAT/amd64
  Buildstatus:   LEFTOVERS
  Log: 
https://qat.redports.org//~k...@freebsd.org/20131021133400-60615-210854/opal-3.10.10_2.log

  Buildgroup: 9.2-QAT/i386
  Buildstatus:   LEFTOVERS
  Log: 
https://qat.redports.org//~k...@freebsd.org/20131021133400-60615-210855/opal-3.10.10_2.log


--
Buildarchive URL: https://qat.redports.org/buildarchive/20131021133400-60615
redports https://qat.redports.org/
___
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


pkg - stderr/stdout

2013-10-21 Thread Jason Hellenthal
Ref: pkg |less

Why should anyone need to  . . . 

pkg 21 |less

Just to page the help ?

-- 
 Jason Hellenthal
 Voice: +1 (616) 953-0176
 JJH48-ARIN

smime.p7s
Description: S/MIME cryptographic signature


ports/editors/libreoffice does not build on 10-CURRENT

2013-10-21 Thread Matthias Apitz

Hello,

This is with 10-CURRENT r255948 and ports r328930;

The 'nohup make install BATCH=yes' stops with:

...
[build CXX] jvmaccess/source/virtualmachine.cxx
[build ASM] bridges/source/cpp_uno/gcc3_linux_intel/call
[build CXX]
bridges/source/cpp_uno/gcc3_linux_intel/callvirtualmethod.cxx
clang: warning: argument unused during compilation: '-Wall'
clang: warning: argument unused during compilation: '-Wendif-labels'
clang: warning: argument unused during compilation: '-Wextra'
clang: warning: argument unused during compilation: '-fmessage-length=0'
clang: warning: argument unused during compilation: '-fno-common'
clang: warning: argument unused during compilation: '-fPIC'
clang: warning: argument unused during compilation:
'-Wdeclaration-after-statement'
clang: warning: argument unused during compilation: '-Wshadow'
clang: warning: argument unused during compilation:
'-fno-strict-aliasing'
clang: warning: argument unused during compilation: '-D LDAP_DEPRECATED'
clang: warning: argument unused during compilation:
'-fno-strict-aliasing'
clang: warning: argument unused during compilation: '-I
/usr/ports/editors/libreoffice/work/libreoffice-4.0.5.2/bridge
s/inc'
clang: warning: argument unused during compilation: '-I
/usr/ports/editors/libreoffice/work/solver/unxfbsdi.pro/inc/ex
ternal'
clang: warning: argument unused during compilation: '-I
/usr/ports/editors/libreoffice/work/solver/unxfbsdi.pro/inc'
clang: warning: argument unused during compilation: '-I
/usr/ports/editors/libreoffice/work/libreoffice-4.0.5.2/solenv
/inc'
clang: warning: argument unused during compilation: '-I
/usr/local/include'
clang: warning: argument unused during compilation: '-I
/usr/ports/editors/libreoffice/work/libreoffice-4.0.5.2/config
'
clang: warning: argument unused during compilation: '-I
/usr/ports/editors/libreoffice/work/workdir/unxfbsdi.pro/UnoAp
iHeadersTarget/udkapi/comprehensive'
[build CXX] bridges/source/cpp_uno/gcc3_linux_intel/cpp2uno.cxx
/usr/ports/editors/libreoffice/work/libreoffice-4.0.5.2/bridges/source/cpp_uno/gcc3_linux_intel/callvirtualmethod.cxx:
62:53: error: no member named 'dummy_can_throw_anything' in namespace
'gcc3'
if (! pAdjustedThisPtr)
CPPU_CURRENT_NAMESPACE::dummy_can_throw_anything(xxx); // address
something
^
1 error generated.
gmake[3]: ***
[/usr/ports/editors/libreoffice/work/workdir/unxfbsdi.pro/CxxObject/bridges/source/cpp_uno/gcc3_linux_in
tel/callvirtualmethod.o] Error 1
gmake[3]: *** Waiting for unfinished jobs



Please let me know if you need the full 'nohup.out'
Thx

matthias
-- 
E-mail: g...@unixarea.de |  \ / - No HTML/RTF in E-mail
WWW: http://www.unixarea.de/ |   X  - No proprietary attachments
phone: +49-170-4527211   |  / \ - Respect for open standards
___
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


[CORRECTION] Getting to know your portmgr@ -- Joe Marcus Clarke

2013-10-21 Thread FreeBSD Ports Management Team Secretary
This is the start of an ongoing series profiling members of the FreeBSD
Ports Management Team.  In this interview, we talk to longest serving
member of the team, Joe Marcus Clarke, aka marcus@

http://blogs.freebsdish.org/portmgr/2013/10/21/getting-to-know-your-portmgr-joe-marcus-clarke/
___
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: Compiling sguil-server on Release 9.2 i386

2013-10-21 Thread Paul Schmehl
--On October 21, 2013 7:48:59 AM +0200 John Marino 
freebsd.cont...@marino.st wrote:



On 10/21/2013 00:47, Paul Schmehl wrote:

--On October 20, 2013 9:34:36 AM +0200 John Marino

It is not a mystery what is wrong.
The RUN_DEPENDS is being executed as a shell command, not a make
definition.


You're wrong.  The RUN_DEPENDS does not have a shell command embedded in
it anywhere.


When you indent, it executes the command in the shell.  Notice that only
make targets are indented.



I discovered this on my own while working on the port this morning.




That was never correct, and the new bmake makes this much
more obvious.  Secondly, I'm pretty sure you can specify
databases/mysqltcl without having to execute a make command on that
port.


You're pretty sure?  Rather than hard code a version, which would break
the port the moment mysqltcl was updated, I chose to use the existing
port version, which would work no matter what version was current on any
particular box.


Yes, I am sure.  You can tell it that the port is the dependency
regardless of version.  If you absolutely wanted to specify a file, you
can specify a different one that the file name doesn't change.  Yes, you
can a RUN_DEPENDS without that line in ways that are robust.



The dependency is mysqltcl.  That port installs two files in 
${LOCALBASE}/lib/mysqltcl-${PORTVERSION}/.  How do you reference those 
files without using the portversion?





Thirdly, you use ${MYSQLTCL_VER}, but it's never defined.


Yes, and that is a problem.  I noticed that last night when I was
looking at the port.  Line 46 should read MYSQLTCL_VER=  @${ECHO_CMD}
$$(${MYSQLTCL_CMDS}).



Again, completely unnecessary.  Specify the *NON-INDENTED* RUN_DEPENDS
in a better way.



It looks like that port has changed, however, because it no longer
appends the version number to the name of the port, so I can probably
drop that entirely.  I won't know until I test it.


Apparently line 46 was intended to define it but does not.  Lastly, if
you were to use a shell command (which I highly discourage), it should
be something like this (not indented, and definitely not hardcoded to
${PORTSDIR}):
MYSQLT_VER!=  cd ${.CURDIR}/../../databases/mysqltcl  ${MAKE} -V
PORTVERSION



What do you suggest it be hardcoded to?  ${PORTSDIR} can be set to
anything on an individual system.  Using your construction forces it to
be in /usr/ports.  Although that's the default, it's by no means
guaranteed that the ports tree will exist there on any given system.
That's why we use macros in Makefiles - to avoid forcing users to stick
to the default structure.


I just showed you.  Replace ${PORTSDIR} with ${.CURDIR}/../../
I know you haven't believed a thing I've said so far, but using
${PORTSDIR} can break the build in specific configurations.  And yes,
we've been replacing it with .CURDIR in other ports.



When I work on my ports I create a new directory ${PORTNAME}-update.  Then 
I svn the port into that directory, which creates a subdirectory named 
${PORTNAME}.  With ${.CURDIR}../../../ the build will not descend to 
/usr/ports but to /usr/ports/security and the build will break.  I fail to 
see how that can be correct.  If I build ports anywhere other than the 
default location, the build will break.


Is this information documented somewhere?  And how do I overcome this 
obvious problem?





So that's like 4 or 5 errors right off the bat, problems that were
always present.  I suspect the legacy make simply didn't define
RUN_DEPENDS and continued building, so mysqltcl was never specified in
the package.



Because MYSQLTCL_VER is never defined, I think the RUN_DEPENDS should
fail. It didn't.  I can't explain why.  (I've slept since I last worked
on that port.)  I can assure you I tested the port with the option
enabled and it built and ran fine.


So you state previously that it *HAD* to be defined for RUN_DEPENDS to
work, and now state that it wasn't defined but RUN_DEPENDS did work?
Doubtful and easily verifiable.  Find an old platform where it worked
and type make -V RUN_DEPENDS and see if mysqltcl is in the list.  I
believe it simply wasn't defined which didn't prevent this build from
building (it was indented, remember?).  I think the error was masked
with the previous version of make.




But I doubt seriously that has anything to do with the error that the OP
reported.  It's probably related to the change to bmake, which I will
have to investigate, if I have to continue to define the port version
for mysqltcl.  It looks like I might not have to any more.

I'll also have to update the port to use the new STAGE syntax, so this
will take a little while.

In the future, I would appreciate it if you adopt a less smug attitude
about somebody else's work.  Or take over the port if you think you're
so much better.  There's three sguil ports.  You're welcome to take over
maintainership if you think you're God's gift to port building.


Sigh
I guess you still feel this way after what I just 

Re: Chromium and HEAD

2013-10-21 Thread Shawn Webb
Same for me. Built using Poudriere.


On Thu, Oct 3, 2013 at 10:30 AM, Lars Engels lars.eng...@0x20.net wrote:

 On Wed, Oct 02, 2013 at 10:10:24PM -0400, Sam Fourman Jr. wrote:
  using a recent FreeBSD amd64
  FreeBSD NewBSD 10.0-ALPHA4 FreeBSD 10.0-ALPHA4 #0 r255942: Sun Sep 29
  20:05:41 UTC 2013
 
 
  I am running chromium built with default options(clang33 from ports)
  when you use the address bar to search, chromium will coredump if the
 first
  letter you type is the letter a
 
  is anyone else seeing this?
 

 Same for me using the version from pkg-test.

___
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


Should /usr/bin/perl be a link to /usr/local/bin/perl ?

2013-10-21 Thread Yuri
I found that many ports specify /usr/bin/perl as an interpreter. This 
comes from Linux. Examples: valgrind-snapshot, windowmaker, enscript-a4, 
a2ps, svgalib

/usr/bin/perl isn't installed by perl port.

There are several solutions, in the order of increasing complexity of 
solution:
1. Install the link /usr/bin/perl (hackish, but it will fix many broken 
ports in one shot)
2. Make a package scripts check for interpreter and break the install of 
offending packages

3. Fix all offending packages

Which solution should be preferred in your opinion?

Yuri
___
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: Should /usr/bin/perl be a link to /usr/local/bin/perl ?

2013-10-21 Thread andrew clarke
On Mon 2013-10-21 09:47:29 UTC-0700, Yuri (y...@rawbw.com) wrote:

 I found that many ports specify /usr/bin/perl as an interpreter. This 
 comes from Linux. Examples: valgrind-snapshot, windowmaker, enscript-a4, 
 a2ps, svgalib
 /usr/bin/perl isn't installed by perl port.
 
 There are several solutions, in the order of increasing complexity of 
 solution:
 1. Install the link /usr/bin/perl (hackish, but it will fix many broken 
 ports in one shot)
 2. Make a package scripts check for interpreter and break the install of 
 offending packages
 3. Fix all offending packages
 
 Which solution should be preferred in your opinion?

Are you aware the Perl interpreter ports already have a make option to
create symlinks in /usr/bin?

$ pwd
/usr/ports/lang/perl5.14

$ make showconfig | grep USE_PERL
 USE_PERL=on: Rewrite links in /usr/bin

$ ls -l /usr/bin/perl
lrwxr-xr-x  1 root  wheel  25 10 Oct 14:04 /usr/bin/perl - 
/usr/local/bin/perl5.14.4

Regards
Andrew
___
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: Should /usr/bin/perl be a link to /usr/local/bin/perl ?

2013-10-21 Thread Freddie Cash
On Mon, Oct 21, 2013 at 9:47 AM, Yuri y...@rawbw.com wrote:

 I found that many ports specify /usr/bin/perl as an interpreter. This
 comes from Linux. Examples: valgrind-snapshot, windowmaker, enscript-a4,
 a2ps, svgalib
 /usr/bin/perl isn't installed by perl port.

 There are several solutions, in the order of increasing complexity of
 solution:
 1. Install the link /usr/bin/perl (hackish, but it will fix many broken
 ports in one shot)


​That's already there.  A least on all my FreeBSD machines (9.0, 9.1,
9-STABLE, 10-CURRENT).  I believe that's the default for the perl ports and
you have to manually uncheck that option when building the port to break
things.​



 2. Make a package scripts check for interpreter and break the install of
 offending packages
 3. Fix all offending packages

 Which solution should be preferred in your opinion?

 Yuri
 __**_
 freebsd-ports@freebsd.org mailing list
 http://lists.freebsd.org/**mailman/listinfo/freebsd-portshttp://lists.freebsd.org/mailman/listinfo/freebsd-ports
 To unsubscribe, send any mail to 
 freebsd-ports-unsubscribe@**freebsd.orgfreebsd-ports-unsubscr...@freebsd.org
 




-- 
Freddie Cash
fjwc...@gmail.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: Should /usr/bin/perl be a link to /usr/local/bin/perl ?

2013-10-21 Thread Yuri

On 10/21/2013 09:53, andrew clarke wrote:

Are you aware the Perl interpreter ports already have a make option to
create symlinks in /usr/bin?


Hm, I wasn't aware of this. And I do have this option set in port, never 
touched it, and still don't have /usr/bin/perl. Mistery.


Yuri
___
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: Compiling sguil-server on Release 9.2 i386

2013-10-21 Thread John Marino
On 10/21/2013 18:15, Paul Schmehl wrote:
 --On October 21, 2013 7:48:59 AM +0200 John Marino
 
 The dependency is mysqltcl.  That port installs two files in
 ${LOCALBASE}/lib/mysqltcl-${PORTVERSION}/.  How do you reference those
 files without using the portversion?

Look at section 5.8.9 of the Porters Handbook:
http://www.freebsd.org/doc/en/books/porters-handbook/makefile-depend.html

Something like this should work:
RUN_DEPENDS+= mysqltcl3:${PORTSDIR}/databases/mysqltcl

With that line, you can forgot the shell command above.  It means, use
any version of  mysqltcl 3.0 or greater.

 When I work on my ports I create a new directory ${PORTNAME}-update. 
 Then I svn the port into that directory, which creates a subdirectory
 named ${PORTNAME}.  With ${.CURDIR}../../../ the build will not descend
 to /usr/ports but to /usr/ports/security and the build will break.  I
 fail to see how that can be correct.  If I build ports anywhere other
 than the default location, the build will break.

it would be ${.CURDIR}/../../
(notice slash immediate following ${.CURDIR} and only two ../.  Really
only one is needed since since the port is in the same category.  But
this is unnecessary if you make the change above.

 
 Is this information documented somewhere?  And how do I overcome this
 obvious problem?

I don't know if it's documented or not.  The more common occurrence is
trying to include a file from another port, rather than trying to make
a port (which has forked bombed me when it ran into an unexpected error
which is why I hate make in a shell so much).


 There are multiple ways to point out problems.  One way is to point to
 the problem and say, Look - you screwed up here.  That's your way, and
 I can assure you it doesn't lend to a sense of cooperation and learning.

If you want to get pedantic, I never addressed you directly or by name.
 I said the option wasn't properly tested (obviously true) and that
there were multiple problems with it (again true).  I told the user to
open a PR and document it, and let the maintainer deal with it.  I'm a
bit perplexed about why you are so sensitive about it.  It's a honest
mistake, I think you learned from it, move on.  Nobody thinks less, this
kind of thing is discovered all the time.

 
 You know, you could have just said, Thank you as I've spent a
 considerable time on this topic when nobody else did.

 
 Yes, and you could have been a lot more pleasant.  Don't forget, port
 maintainers are volunteers.

What do you think I am?

 maintainers are volunteers.  I spend my personal time working on these
 problems, and the thanks I get from you is, hey, you screwed this up,
 you screwed that up, in fact, I can see five or six problems just from a
 brief look at your port instead of here's what the problem is, and
 here's a way to fix it.

1. I can't stress enough that you were never addressed directly or by name.
2. I only stated the truth
3. Do you really think I should do this for you?  Or spoon-feed you?  I
believe I gave you more than enough information to both understand the
problem and figure out the solution.  that's how people learn.

 
 It's not an attitude that makes me want to get to work on fixing the
 problems.


How about pride in a job well done?
Again, I think you should accept this in the spirit it was given.  If
you found it unpleasant, I'm sorry but that wasn't the intention.

John

___
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: Should /usr/bin/perl be a link to /usr/local/bin/perl ?

2013-10-21 Thread Oliver Heesakkers
Op ma 21 okt 2013 09:47:29 schreef Yuri:
 I found that many ports specify /usr/bin/perl as an interpreter. This
 comes from Linux. Examples: valgrind-snapshot, windowmaker, enscript-a4,
 a2ps, svgalib
 /usr/bin/perl isn't installed by perl port.
 
 There are several solutions, in the order of increasing complexity of
 solution:
 1. Install the link /usr/bin/perl (hackish, but it will fix many broken
 ports in one shot)
 2. Make a package scripts check for interpreter and break the install of
 offending packages
 3. Fix all offending packages
 
 Which solution should be preferred in your opinion?
 


3b. Teach upstream to write:

#!/usr/bin/env perl
___
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: Compiling sguil-server on Release 9.2 i386

2013-10-21 Thread Paul Schmehl
--On October 21, 2013 7:09:06 PM +0200 John Marino 
freebsd.cont...@marino.st wrote:



On 10/21/2013 18:15, Paul Schmehl wrote:

--On October 21, 2013 7:48:59 AM +0200 John Marino

The dependency is mysqltcl.  That port installs two files in
${LOCALBASE}/lib/mysqltcl-${PORTVERSION}/.  How do you reference those
files without using the portversion?


Look at section 5.8.9 of the Porters Handbook:
http://www.freebsd.org/doc/en/books/porters-handbook/makefile-depend.html

Something like this should work:
RUN_DEPENDS+= mysqltcl3:${PORTSDIR}/databases/mysqltcl



No, it won't.  You can't use that construction on libraries, which is what 
mysqltcl is.




What do you think I am?



I haven't the foggiest idea.  What you come across as is a guy who thinks 
he knows everything and everyone else is stupid.



3. Do you really think I should do this for you?  Or spoon-feed you?  I
believe I gave you more than enough information to both understand the
problem and figure out the solution.  that's how people learn.



No, you didn't.  You provided the information in drips and drabs.  It took 
several emails, during which time I had already figured out the problem 
myself before you posted what you could have posted initially.


As for your snarky do I want you to spoon-feed me, no thanks.  I'd starve 
to death waiting for you to feed me.  You could have simply posted, in your 
first reply, You cannot index commands under options.  Remove the tabs. 
Also, the ECHO line will probably generate a shell error anyway, so you're 
going to have to find a way to resolve that.  My suggestion would be to 
hardcode the version number, since you can't approximate libraries.




It's not an attitude that makes me want to get to work on fixing the
problems.



How about pride in a job well done?
Again, I think you should accept this in the spirit it was given.  If
you found it unpleasant, I'm sorry but that wasn't the intention.



How about I've always had pride in a job well done, and I resent you 
implicating that I did not?  My responses have been written the way they 
were in the hope that YOU would learn something, but it's apparent you 
haven't.


It's a moot point now.  I've fixed the problems and updated the port to use 
STAGE, and it's fixing to be sent in as a response to the PR.


--
Paul Schmehl, Senior Infosec Analyst
As if it wasn't already obvious, my opinions
are my own and not those of my employer.
***
It is as useless to argue with those who have
renounced the use of reason as to administer
medication to the dead. Thomas Jefferson
There are some ideas so wrong that only a very
intelligent person could believe in them. George Orwell

___
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: Compiling sguil-server on Release 9.2 i386

2013-10-21 Thread John Marino
On 10/21/2013 20:40, Paul Schmehl wrote:
 --On October 21, 2013 7:09:06 PM +0200 John Marino

 Look at section 5.8.9 of the Porters Handbook:
 http://www.freebsd.org/doc/en/books/porters-handbook/makefile-depend.html

 Something like this should work:
 RUN_DEPENDS+= mysqltcl3:${PORTSDIR}/databases/mysqltcl

 No, it won't.  You can't use that construction on libraries, which is
 what mysqltcl is.


Are you as certain about that as you were about the RUN_DEPENDS line not
being a shell command before?   As the handbook clearly states, you can
use that construction on RUN_DEPENDS.  The fact that you want a library
out of the port is not relevant.  It would install everything in the
mysqltcl port, including the library you desire.

The rest of your post doesn't merit a response.

John
___
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: iconv in base breaks multiple ports

2013-10-21 Thread Ulrich Spörlein
On Sun, 2013-10-20 at 23:20:10 +0200, Tijl Coosemans wrote:
 On Sun, 20 Oct 2013 20:27:23 +0200 Ulrich Spörlein wrote:
  ever since that iconv thing replaced the ports version, I run into
  trouble with several ports that I have installed on a -CURRENT (now
  stable/10 system).
  
  These are not compile-time errors, but crashes or limited functionality
  where I blame iconv :)
  
  1. www/newsbeuter crashes during startup, somewhere in the stfl code
  that deals with wide char functions.
  
  2. devel/git: when using git-svn, it'll segfault in the perl code, not
  sure how to get a backtrace here as gdb's follow-fork doesn't quite
  work.
  
  3. multimedia/xbmc is no longer able to decode unicode filenames and
  other things are broken. It spews an endless stream of 
  19:36:00 T:34594644992   ERROR: convert_checked iconv_open() failed from
  WCHAR_T to UTF-8, errno=22(Invalid argument)
  19:36:00 T:34594644992   ERROR: convert_checked iconv_open() failed from
  UTF-8 to WCHAR_T, errno=22(Invalid argument)
  19:37:00 T:34594644992   ERROR: Previous line repeats 9656 times.
  
  Is my system hexed? I've rebuilt the ports/packages a dozen times now.
  Am I seeing ghosts?
 
 Can you try the attached patch?  It includes the one from
 http://www.freebsd.org/cgi/query-pr.cgi?pr=182994


Sure, I fail to see however how this locking could cause the problems
with crashes and failures to convert strings. I've rebuild libc with
this and it does nothing for the newsbeuter or perl crashes :(

Thanks
Uli
___
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

take a look at ports/182540 (vulnerabilities)

2013-10-21 Thread Koichiro IWAO
Hello,

Would anyone please take a look at ports/182540?
This update fixes buffer overruns and other vulnerabilities [1].

[1] https://github.com/FreeRDP/xrdp/commits/v0.6

Regards,

-- 
`whois vmeta.jp | nkf -w`
meta m...@vmeta.jp
___
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


FreeBSD Port: jggtrans-2.2.4_2

2013-10-21 Thread Bartosz Mierzwiak ebITo.pl

Newest version 2.2.6 with very important fix:

https://github.com/Jajcus/jggtrans/releases

___
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


openvas-server build failure on 11-current

2013-10-21 Thread AN
FreeBSD FBSD11 11.0-CURRENT FreeBSD 11.0-CURRENT #1 r256799: Sun Oct 20 
14:58:19 CDT 2013 root@FBSD11:/usr/obj/usr/src/sys/MYKERNEL  amd64


# cc -v
FreeBSD clang version 3.3 (tags/RELEASE_33/final 183502) 20130610
Target: x86_64-unknown-freebsd11.0
Thread model: posix


openvas-server build fails with:

--- pluginscheduler.o ---
cc -Wall -I. 
-I/usr/ports/security/openvas-server/work/openvas-server-2.0.2/include 
-I/usr/local/include/openvas -I/usr/local/include/openvas 
-DOPENVASD_CONFDIR=\/usr/local/etc\ 
-DOPENVASD_STATEDIR=\/usr/local/openvas/lib/openvas\ 
-DOPENVASD_DATADIR=\/usr/local/etc/openvas\ 
-DOPENVASD_LIBDIR=\/usr/local/lib/openvas\ 
-DOPENVASD_PLUGINS=\/usr/local/lib/openvas/plugins\ 
-DOPENVASD_CACHE=\/usr/local/openvas/cache/openvas\ 
-DOPENVASD_REPORTS=\/usr/local/openvas/log/openvas/reports\ 
-DOPENVASD_SHAREDSTATEDIR=\/usr/local/openvas/lib/openvas\ 
-DOPENVASD_LOGDIR=\/usr/local/openvas/log/openvas\ 
-DOPENVASD_PIDDIR=\/var/run\ -O2 -pipe -I/usr/local/include 
-fno-strict-aliasing -I. 
-I/usr/ports/security/openvas-server/work/openvas-server-2.0.2/include 
-I/usr/local/include/glib-2.0 -I/usr/local/include  -I/usr/local/include 
-c pluginscheduler.c

--- plugs_hash.o ---
In file included from plugs_hash.c:32:
/usr/local/include/gcrypt.h:1353:2: warning: 'gcry_ac_data_read_cb_t' is 
deprecated [-Wdeprecated-declarations]

gcry_ac_data_read_cb_t cb;
^
/usr/local/include/gcrypt.h:1318:23: note: 'gcry_ac_data_read_cb_t' 
declared here

typedef gpg_error_t (*gcry_ac_data_read_cb_t) (void *opaque,
  ^
/usr/local/include/gcrypt.h:1367:2: warning: 'gcry_ac_data_write_cb_t' is 
deprecated [-Wdeprecated-declarations]

gcry_ac_data_write_cb_t cb;
^
/usr/local/include/gcrypt.h:1323:23: note: 'gcry_ac_data_write_cb_t' 
declared here

typedef gpg_error_t (*gcry_ac_data_write_cb_t) (void *opaque,
  ^
/usr/local/include/gcrypt.h:1402:3: warning: 'gcry_md_algo_t' is 
deprecated [-Wdeprecated-declarations]

  gcry_md_algo_t md;
  ^
/usr/local/include/gcrypt.h:1396:28: note: 'gcry_md_algo_t' declared here
typedef enum gcry_md_algos gcry_md_algo_t _GCRY_ATTR_INTERNAL;
   ^
/usr/local/include/gcrypt.h:1410:3: warning: 'gcry_md_algo_t' is 
deprecated [-Wdeprecated-declarations]

  gcry_md_algo_t md;
  ^
/usr/local/include/gcrypt.h:1396:28: note: 'gcry_md_algo_t' declared here
typedef enum gcry_md_algos gcry_md_algo_t _GCRY_ATTR_INTERNAL;
   ^
plugs_hash.c:193:13: warning: unused function 'plugins_send_md5_byname' 
[-Wunused-function]

static void plugins_send_md5_byname(struct arglist * globals)
^
--- shared_socket.o ---
cc -Wall -I. 
-I/usr/ports/security/openvas-server/work/openvas-server-2.0.2/include 
-I/usr/local/include/openvas -I/usr/local/include/openvas 
-DOPENVASD_CONFDIR=\/usr/local/etc\ 
-DOPENVASD_STATEDIR=\/usr/local/openvas/lib/openvas\ 
-DOPENVASD_DATADIR=\/usr/local/etc/openvas\ 
-DOPENVASD_LIBDIR=\/usr/local/lib/openvas\ 
-DOPENVASD_PLUGINS=\/usr/local/lib/openvas/plugins\ 
-DOPENVASD_CACHE=\/usr/local/openvas/cache/openvas\ 
-DOPENVASD_REPORTS=\/usr/local/openvas/log/openvas/reports\ 
-DOPENVASD_SHAREDSTATEDIR=\/usr/local/openvas/lib/openvas\ 
-DOPENVASD_LOGDIR=\/usr/local/openvas/log/openvas\ 
-DOPENVASD_PIDDIR=\/var/run\ -O2 -pipe -I/usr/local/include 
-fno-strict-aliasing -I. 
-I/usr/ports/security/openvas-server/work/openvas-server-2.0.2/include 
-I/usr/local/include/glib-2.0 -I/usr/local/include  -I/usr/local/include 
-c shared_socket.c

--- openvasd.o ---
1 warning generated.
--- plugs_hash.o ---
5 warnings generated.
--- openvasd ---
cc -L/usr/local/lib -I. 
-I/usr/ports/security/openvas-server/work/openvas-server-2.0.2/include 
-I/usr/local/include/glib-2.0 -I/usr/local/include  -I/usr/local/include 
auth.o  attack.o  comm.o  log.o  rules.o  sighand.o  processes.o  users.o 
utils.o  ntp_11.o  otp_1_0.o  parser.o  hosts.o  preferences.o  piic.o 
pluginload.o  nasl_plugins.o  nes_plugins.o  oval_plugins.o  plugs_req.o 
openvasd.o  save_tests.o  save_kb.o  pluginlaunch.o  locks.o  plugs_hash.o 
pluginscheduler.o  shared_socket.o  -o openvasd 
`/usr/local/bin/openvas-libnasl-config --libs` 
`/usr/local/bin/libopenvas-config --libs`  -lcompat 
-L/usr/local/lib -lglib-2.0 -lintl

/usr/bin/ld: ?: invalid DSO for symbol `gcry_md_close' definition
/usr/local/lib/libgcrypt.so.19: could not read symbols: Bad value
cc: error: linker command failed with exit code 1 (use -v to see 
invocation)

*** [openvasd] Error code 1

make[2]: stopped in 
/usr/ports/security/openvas-server/work/openvas-server-2.0.2/openvasd

1 error

make[2]: stopped in 
/usr/ports/security/openvas-server/work/openvas-server-2.0.2/openvasd

*** [server] Error code 2

make[1]: stopped in 
/usr/ports/security/openvas-server/work/openvas-server-2.0.2

1 error

make[1]: stopped in 
/usr/ports/security/openvas-server/work/openvas-server-2.0.2

=== Compilation failed unexpectedly.
Try 

Re: iconv in base breaks multiple ports

2013-10-21 Thread Ulrich Spörlein
On Mon, 2013-10-21 at 13:18:55 +0200, Tilman Keskinöz wrote:
 hi Ulrich,
 
 * Ulrich Spörlein [Sun, 20 Oct 2013 20:27:23 +0200]:
  ever since that iconv thing replaced the ports version, I run into
  trouble with several ports that I have installed on a -CURRENT (now
  stable/10 system).
  
  These are not compile-time errors, but crashes or limited functionality
  where I blame iconv :)
  
  
  1. www/newsbeuter crashes during startup, somewhere in the stfl code
  that deals with wide char functions.
  
 
  Is my system hexed? I've rebuilt the ports/packages a dozen times now.
  Am I seeing ghosts?
 
 
 I don't run Current, but according to the pkg-fallout mails i am
 receiving, newsbeuter shouldn't even compile on CURRENT. Maybe there are
 some stale files on your system?
 
 There is also an update in the PR system, you might want to try,
 http://www.freebsd.org/cgi/query-pr.cgi?pr=ports/182896

Right, I had to set USE_GCC=any and muck with -liconv flags of course to
get it to build. Lemme whip up a proper patch though, I got it to build
fine on -CURRENT with clang now, doesn't fix the crash though :(.

Here's a build with USE_GCC=any:
https://redports.org/buildarchive/20131021191400-36506/

Here is a more proper fix:
https://redports.org/buildarchive/20131021203201-51496/

Cheers,
Uli
___
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

FreeBSD Port: emulators/virtualbox-ose-additions

2013-10-21 Thread Mike Jakubik

Hello,

I am unable to compile this on FreeBSD 10. This is on a freshly 
installed FreeBSD 10.0-BETA1 #0 r256420.


kBuild: Linking VBoxControl
kBuild: Linking VBoxService
kBuild: Linking VBoxClient
/usr/bin/ld: cannot find -lsupc++
cc: error: linker command failed with exit code 1 (use -v to see invocation)
kmk: *** 
[/usr/ports/emulators/virtualbox-ose-additions/work/VirtualBox-4.2.18/out/freebsd.amd64/release/obj/VBoxClient/VBoxClient] 
Error 1

The failing command:
@cc  -m64   -o 
/usr/ports/emulators/virtualbox-ose-additions/work/VirtualBox-4.2.18/out/freebsd.amd64/release/obj/VBoxClient/VBoxClient 
/usr/ports/emulators/virtualbox-ose-additions/work/VirtualBox-4.2.18/out/freebsd.amd64/release/obj/VBoxClient/main.o 
/usr/ports/emulators/virtualbox-ose-additions/work/VirtualBox-4.2.18/out/freebsd.amd64/release/obj/VBoxClient/src/VBox/GuestHost/SharedClipboard/clipboard-helper.o 
/usr/ports/emulators/virtualbox-ose-additions/work/VirtualBox-4.2.18/out/freebsd.amd64/release/obj/VBoxClient/src/VBox/GuestHost/SharedClipboard/x11-clipboard.o 
/usr/ports/emulators/virtualbox-ose-additions/work/VirtualBox-4.2.18/out/freebsd.amd64/release/obj/VBoxClient/clipboard.o 
/usr/ports/emulators/virtualbox-ose-additions/work/VirtualBox-4.2.18/out/freebsd.amd64/release/obj/VBoxClient/seamless.o 
/usr/ports/emulators/virtualbox-ose-additions/work/VirtualBox-4.2.18/out/freebsd.amd64/release/obj/VBoxClient/seamless-host.o 
/usr/ports/emulators/virtualbox-ose-additions/work/VirtualBox-4.2.18/out/freebsd.amd64/release/obj/VBoxClient/seamless-x11.o 
/usr/ports/emulators/virtualbox-ose-additions/work/VirtualBox-4.2.18/out/freebsd.amd64/release/obj/VBoxClient/thread.o 
/usr/ports/emulators/virtualbox-ose-additions/work/VirtualBox-4.2.18/out/freebsd.amd64/release/obj/VBoxClient/display.o 
/usr/ports/emulators/virtualbox-ose-additions/work/VirtualBox-4.2.18/out/freebsd.amd64/release/obj/VBoxClient/hostversion.o 
-L/usr/X11R6/lib32  -L/usr/X11R6/lib  -L/usr/lib  -L/usr/X11R6/lib 
-L/usr/local/lib   -lX11   -lXrandr   -lXt   -lsupc++   -lgcc_eh 
-lXext   -lXmu 
/usr/ports/emulators/virtualbox-ose-additions/work/VirtualBox-4.2.18/out/freebsd.amd64/release/lib/additions/RuntimeGuestR3.a 
/usr/ports/emulators/virtualbox-ose-additions/work/VirtualBox-4.2.18/out/freebsd.amd64/release/lib/additions/VBoxGuestR3Lib.a 
/usr/ports/emulators/virtualbox-ose-additions/work/VirtualBox-4.2.18/out/freebsd.amd64/release/lib/additions/RuntimeGuestR3.a 
-lpthread

kmk: *** Waiting for unfinished jobs
kmk: *** Exiting with status 2
*** Error code 2

Thanks.
___
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


[Test] multimedia/xfce4-parole 0.5.90

2013-10-21 Thread Olivier Duchateau
Hi,

This week-end I worked on the next stable release (0.6.0) of 
multimedia/xfce4-parole.

If someone is interesting to test it, you must:
1. Update your ports tree (I made change in Mk/bsd.xfce.mk)
2. Upgrade x11/libxfce4menu (you must set GTK3 option, otherwise compilation 
will fail)
3. Upgrade multimedia/xfce4-parole

If you use libxfce4menu development release, you must also upgrade 
sysutils/xfce4-settings and x11-wm/xfce4-wm.

Patches are available here [1].

This release supports **only** x11-toolkits/gtk30. So you must install theme 
(e.g. x11-themes/greybird-theme), which supports this version of Gtk.

I patched Parole, because main developers prefer to use symbolic icons (not 
available in GNOME and Tango themes), so currently I strength to install 
misc/gnome/icon-theme, to be sure nothing is missing and works fine everywhere.

Mandatory screenshot, 
https://lh4.googleusercontent.com/-VcwtlGijK2g/UmWfuX21rgI/BnQ/Rng59p6naqI/w534-h542-no/parole-0.5.90.png

top image: Parole with elementary-xfce-icon-theme (not available in ports tree)

bottom image: Parole with icons-tango (default icons theme)

Enjoy

[1] https://people.freebsd.org/~olivierd/patches/

-- 
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


www/w3m broken after update

2013-10-21 Thread Kenta Suzumoto
Maintainer has ignored emails. Any ideas what's causing this to fail?

config.status: creating config.h
config.status: executing po-directories commands
config.status: creating po/POTFILES
config.status: creating po/Makefile
===  Building for w3m-0.5.3_2
(echo '#define DEFUN(x,y,z) x y'; sed -ne '/^DEFUN/{p;n;/^[ ]/p;}' ./main.c 
./menu.c) | clang-cpp - |  awk '$1 ~ /^[_A-Za-z]/ {  for (i=2;i=NF;i++) { 
print $i, $1}  }'  funcname.tab.tmp
funcname.tab updated
sort funcname.tab | /usr/bin/awk -f ./funcname1.awk  funcname1.h
clang  -I. -I. -O2 -pipe -Qunused-parameter -Qunused-arguments 
-fno-strict-aliasing -I./libwc  -I/usr/include/openssl -I/usr/local/include 
-I/usr/local/include -DHAVE_CONFIG_H -DAUXBIN_DIR=\/usr/local/libexec/w3m\  
-DCGIBIN_DIR=\/usr/local/libexec/w3m/cgi-bin\ 
-DHELP_DIR=\/usr/local/share/w3m\  -DETC_DIR=\/usr/local/etc\ 
-DCONF_DIR=\/usr/local/etc/w3m\  -DRC_DIR=\~/.w3m\  
-DLOCALEDIR=\/usr/local/share/locale\ -c main.c
main.c:836:23: error: assigning to 'GC_warn_proc' (aka 'void (*)(char *, 
GC_word)') from incompatible type 'void'
orig_GC_warn_proc = GC_set_warn_proc(wrap_GC_warn_proc);
  ^ ~~~
main.c:2264:37: warning: incompatible pointer types passing 'char **' to 
parameter of type 'wc_uchar **' (aka 'unsigned char **') 
[-Wincompatible-pointer-types]
return wc_any_to_ucs(wtf_parse1(p));
^~
./libwc/wtf.h:71:41: note: passing argument to parameter 'p' here
extern wc_wchar_t wtf_parse1(wc_uchar **p);
^
1 warning and 1 error generated.
*** [main.o] Error code 1

___
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: www/w3m broken after update

2013-10-21 Thread John Marino
On 10/22/2013 03:40, Kenta Suzumoto wrote:
 Maintainer has ignored emails. Any ideas what's causing this to fail?
 
 config.status: creating config.h
 config.status: executing po-directories commands
 config.status: creating po/POTFILES
 config.status: creating po/Makefile
 ===  Building for w3m-0.5.3_2
 (echo '#define DEFUN(x,y,z) x y'; sed -ne '/^DEFUN/{p;n;/^[ ]/p;}' 
 ./main.c ./menu.c) | clang-cpp - |  awk '$1 ~ /^[_A-Za-z]/ {  for 
 (i=2;i=NF;i++) { print $i, $1}  }'  funcname.tab.tmp
 funcname.tab updated
 sort funcname.tab | /usr/bin/awk -f ./funcname1.awk  funcname1.h
 clang  -I. -I. -O2 -pipe -Qunused-parameter -Qunused-arguments 
 -fno-strict-aliasing -I./libwc  -I/usr/include/openssl -I/usr/local/include 
 -I/usr/local/include -DHAVE_CONFIG_H -DAUXBIN_DIR=\/usr/local/libexec/w3m\  
 -DCGIBIN_DIR=\/usr/local/libexec/w3m/cgi-bin\ 
 -DHELP_DIR=\/usr/local/share/w3m\  -DETC_DIR=\/usr/local/etc\ 
 -DCONF_DIR=\/usr/local/etc/w3m\  -DRC_DIR=\~/.w3m\  
 -DLOCALEDIR=\/usr/local/share/locale\ -c main.c
 main.c:836:23: error: assigning to 'GC_warn_proc' (aka 'void (*)(char *, 
 GC_word)') from incompatible type 'void'
 orig_GC_warn_proc = GC_set_warn_proc(wrap_GC_warn_proc);
   ^ ~~~
 main.c:2264:37: warning: incompatible pointer types passing 'char **' to 
 parameter of type 'wc_uchar **' (aka 'unsigned char **') 
 [-Wincompatible-pointer-types]
 return wc_any_to_ucs(wtf_parse1(p));
 ^~
 ./libwc/wtf.h:71:41: note: passing argument to parameter 'p' here
 extern wc_wchar_t wtf_parse1(wc_uchar **p);
 ^
 1 warning and 1 error generated.
 *** [main.o] Error code 1
 


Yeah, I hit this in dports and patched it.  I didn't realize it was
broken in ports too.  Here's the patch I used to fix it:

http://gitweb.dragonflybsd.org/dports.git/blob_plain/HEAD:/www/w3m/dragonfly/patch-main.c

Regards,
John
___
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