FreeBSD ports which are currently marked broken

2014-08-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:   archivers/rpm5
broken because: Does not package
build errors:   none.
overview:   
http://portsmon.FreeBSD.org/portoverview.py?category=archivers&portname=rpm5


portname:   audio/audacious-dumb
broken because: Does not work with audacious 3.5 or later
build errors:   none.
overview:   
http://portsmon.FreeBSD.org/portoverview.py?category=audio&portname=audacious-dumb


portname:   audio/aureal-kmod
broken because: does not build
build errors:   none.
overview:   
http://portsmon.FreeBSD.org/portoverview.py?category=audio&portname=aureal-kmod


portname:   audio/cowbell
broken because: No more public distfiles
build errors:   none.
overview:   
http://portsmon.FreeBSD.org/portoverview.py?category=audio&portname=cowbell


portname:   audio/lastfm-desktop
broken because: Does not build
build errors:   none.
overview:   
http://portsmon.FreeBSD.org/portoverview.py?category=audio&portname=lastfm-desktop


portname:   audio/liquidsoap
broken because: Fails to link
build errors:
http://beefy2.isc.freebsd.org/bulk/93amd64-RELENG_9_3/latest/logs/errors/liquidsoap-1.0.0_3.log
overview:   
http://portsmon.FreeBSD.org/portoverview.py?category=audio&portname=liquidsoap


portname:   audio/qmidinet
broken because: Fails to configure
build errors:   none.
overview:   
http://portsmon.FreeBSD.org/portoverview.py?category=audio&portname=qmidinet


portname:   audio/raproxy
broken because: Unfetchable
build errors:   none.
overview:   
http://portsmon.FreeBSD.org/portoverview.py?category=audio&portname=raproxy


portname:   audio/wmauda
broken because: Does not work with audacious 3.5 or later
build errors:   none.
overview:   
http://portsmon.FreeBSD.org/portoverview.py?category=audio&portname=wmauda


portname:   audio/x11amp
broken because: hangs at start with gtk and linker errors
build errors:   none.
overview:   
http://portsmon.FreeBSD.org/portoverview.py?category=audio&portname=x11amp


portname:   audio/xmms-openspc
broken because: does not build on FreeBSD 10.x and later
build errors:   none.
overview:   
http://portsmon.FreeBSD.org/portoverview.py?category=audio&portname=xmms-openspc


portname:   biology/blast
broken because: Mark as broken: no checksum provided
build errors:   none.
overview:   
http://portsmon.FreeBSD.org/portoverview.py?category=biology&portname=blast


portname:   biology/embassy
broken because: does not fetch
build errors:   none.
overview:   
http://portsmon.FreeBSD.org/portoverview.py?category=biology&portname=embassy


portname:   cad/alliance
broken because: Does not compile
build errors:   none.
overview:   
http://portsmon.FreeBSD.org/portoverview.py?category=cad&portname=alliance


portname:   cad/cider
broken because: Will not build with bmake and USES=fmake will not
solve the issue
build errors:
http://beefy1.isc.freebsd.org/bulk/10i386-quarterly/latest/logs/errors/cider-1.b1_7.log
overview:   
http://portsmon.FreeBSD.org/portoverview.py?category=cad&portname=cider


portname:   chinese/big5con
broken because: 
build

FreeBSD unmaintained ports which are currently marked broken

2014-08-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:   audio/cowbell
broken because: No more public distfiles
build errors:   none.
overview:   
http://portsmon.FreeBSD.org/portoverview.py?category=audio&portname=cowbell


portname:   audio/liquidsoap
broken because: Fails to link
build errors:
http://beefy2.isc.freebsd.org/bulk/93amd64-RELENG_9_3/latest/logs/errors/liquidsoap-1.0.0_3.log
overview:   
http://portsmon.FreeBSD.org/portoverview.py?category=audio&portname=liquidsoap


portname:   audio/raproxy
broken because: Unfetchable
build errors:   none.
overview:   
http://portsmon.FreeBSD.org/portoverview.py?category=audio&portname=raproxy


portname:   audio/wmauda
broken because: Does not work with audacious 3.5 or later
build errors:   none.
overview:   
http://portsmon.FreeBSD.org/portoverview.py?category=audio&portname=wmauda


portname:   audio/x11amp
broken because: hangs at start with gtk and linker errors
build errors:   none.
overview:   
http://portsmon.FreeBSD.org/portoverview.py?category=audio&portname=x11amp


portname:   biology/blast
broken because: Mark as broken: no checksum provided
build errors:   none.
overview:   
http://portsmon.FreeBSD.org/portoverview.py?category=biology&portname=blast


portname:   biology/embassy
broken because: does not fetch
build errors:   none.
overview:   
http://portsmon.FreeBSD.org/portoverview.py?category=biology&portname=embassy


portname:   cad/alliance
broken because: Does not compile
build errors:   none.
overview:   
http://portsmon.FreeBSD.org/portoverview.py?category=cad&portname=alliance


portname:   cad/cider
broken because: Will not build with bmake and USES=fmake will not
solve the issue
build errors:
http://beefy1.isc.freebsd.org/bulk/10i386-quarterly/latest/logs/errors/cider-1.b1_7.log
overview:   
http://portsmon.FreeBSD.org/portoverview.py?category=cad&portname=cider


portname:   chinese/big5con
broken because: 
build errors:   none.
overview:   
http://portsmon.FreeBSD.org/portoverview.py?category=chinese&portname=big5con


portname:   chinese/hztty
broken because: 
build errors:   none.
overview:   
http://portsmon.FreeBSD.org/portoverview.py?category=chinese&portname=hztty


portname:   chinese/miniChinput
broken because: Hard code make, gcc, g++ and more everywhere
build errors:   none.
overview:   
http://portsmon.FreeBSD.org/portoverview.py?category=chinese&portname=miniChinput


portname:   chinese/msttf
broken because: no distinfo provided
build errors:   none.
overview:   
http://portsmon.FreeBSD.org/portoverview.py?category=chinese&portname=msttf


portname:   databases/firebird21-client
broken because: Does not respect CC and hardcode gcc at some places
build errors:
http://beefy1.isc.freebsd.org/bulk/10i386-quarterly/latest/logs/errors/firebird21-client-2.1.5_1.log
overview:   
http://portsmon.FreeBSD.org/portoverview.py?category=databases&portname=firebird21-client


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

FreeBSD unmaintained ports which are currently marked forbidden

2014-08-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:   net-p2p/cdonkey
forbidden because:  distfile got re-rolled
build errors:   none.
overview:   
http://portsmon.FreeBSD.org/portoverview.py?category=net-p2p&portname=cdonkey
___
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 which are currently marked forbidden

2014-08-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:   audio/linux-f10-libaudiofile
forbidden because: 

http://www.freshports.org/vuxml.php?vid=09f47c51-c1a6-11e3-a5ac-001b21614864
build errors:   none.
overview:   
http://portsmon.FreeBSD.org/portoverview.py?category=audio&portname=linux-f10-libaudiofile


portname:   audio/linux-f10-nas-libs
forbidden because: 

http://www.freshports.org/vuxml.php?vid=bf7912f5-c1a8-11e3-a5ac-001b21614864
build errors:   none.
overview:   
http://portsmon.FreeBSD.org/portoverview.py?category=audio&portname=linux-f10-nas-libs


portname:   chinese/acroread8-zh_CN
forbidden because:  No longer maintained upstream since 2011-11-03
build errors:   none.
overview:   
http://portsmon.FreeBSD.org/portoverview.py?category=chinese&portname=acroread8-zh_CN


portname:   chinese/acroread8-zh_TW
forbidden because:  No longer maintained upstream since 2011-11-03
build errors:   none.
overview:   
http://portsmon.FreeBSD.org/portoverview.py?category=chinese&portname=acroread8-zh_TW


portname:   devel/linux-f10-dbus-glib
forbidden because: 

http://www.freshports.org/vuxml.php?vid=77bb0541-c1aa-11e3-a5ac-001b21614864
build errors:   none.
overview:   
http://portsmon.FreeBSD.org/portoverview.py?category=devel&portname=linux-f10-dbus-glib


portname:   french/acroread8
forbidden because:  No longer maintained upstream since 2011-11-03
build errors:   none.
overview:   
http://portsmon.FreeBSD.org/portoverview.py?category=french&portname=acroread8


portname:   french/acroread9
forbidden because:  No longer maintained upstream since 2013-06-26
build errors:   none.
overview:   
http://portsmon.FreeBSD.org/portoverview.py?category=french&portname=acroread9


portname:   ftp/linux-f10-curl
forbidden because: 

http://www.freshports.org/vuxml.php?vid=9aecb94c-c1ad-11e3-a5ac-001b21614864
build errors:   none.
overview:   
http://portsmon.FreeBSD.org/portoverview.py?category=ftp&portname=linux-f10-curl


portname:   german/acroread8
forbidden because:  No longer maintained upstream since 2011-11-03
build errors:   none.
overview:   
http://portsmon.FreeBSD.org/portoverview.py?category=german&portname=acroread8


portname:   german/acroread9
forbidden because:  No longer maintained upstream since 2013-06-26
build errors:   none.
overview:   
http://portsmon.FreeBSD.org/portoverview.py?category=german&portname=acroread9


portname:   graphics/linux-f10-png
forbidden because: 

http://www.freshports.org/vuxml.php?vid=262b92fe-81c8-11e1-8899-001ec9578670
build errors:   none.
overview:   
http://portsmon.FreeBSD.org/portoverview.py?category=graphics&portname=linux-f10-png


portname:   graphics/linux-f10-tiff
forbidden because: 

http://www.freshports.org/vuxml.php?vid=8816bf3a-7929-11df-bcce-0018f3e2eb82
build errors:   none.
overview:   
http://portsmon.FreeBSD.org/portoverview.py?category=graphics&portname=linux-f10-tiff


portname:   japanese/acroread8
forbidden because:  No longer maintained upstream since 2011-11-03
build errors:   none.
overview:   
http://portsmon.FreeBSD.org/portoverview.py?category=japanese&portname=acroread8


portname:   japanese/acroread9
forbidden because:  No longer maintained upstream since 2013-06-26
build errors:   none.
overview:   
http://portsmon.FreeBSD.org/portoverview.py?category=japanese&portname=acroread9


portname:   korean/acroread8
forbidden because:  No longer maintained upstream since 2011-11-03
build errors:   none.
overview:   
http://portsmon.FreeBSD.org/portoverview.py?category=korean&portname=acroread8


portname:   net-p2p/cdonkey
forbidden because:  distfile got re-rolled
build errors:   none.
overview:   
http://portsmon.FreeBSD.org/portoverview.py?category=net-p2p&portname=cdonkey


portname:   net/dante
forbidden because:  Building on 10+ triggers a nasty bug with unix domain
sockets
build errors:   none.
overview:   
http://portsmon.FreeBSD.org/portoverview.py?category=net&portname=dante


portname:   net/linux-f10-openldap
forbidden because: 

http://www.freshports.org/vuxml.php?vid=abad20bf-c1b4-11e3-a5ac-001b21614864
build errors:   none.
overview:   
http://portsmon.FreeBSD.org/portoverview.py?category=net&portname=l

Re: devel/doxygen woes

2014-08-21 Thread Kurt Jaeger 
Hi!

> So I've been getting a lot of issues being directed at me due to the 
> recent devel/doxygen update to 1.8.7. While I'm not sure why these 
> issues only cropped up after that update and not before, I would like to 
> try addressing a few things.

Those discussions always pop up if something changes, even if it is not
related 8-}

> doxygen has a bit of an issue in that it uses itself to build its own 
> documentation.

Let me state this a bit more general:

doxygen has the issue that if you use it, it brings in a huge
amount of dependencies. And currently, this process is not
thought-through.

> As a result of this, the HTMLDOCS and PDFDOCS options 
> will only pull in what is needed to allow doxygen to be built in such a 
> way to be able to build its own documentation. Because of this, if those 
> options are left out, then doxygen will be left in a state where it can 
> no longer build HTML docs fully (because of the lack of graphviz) and 
> cannot build PDF docs (because of the lack of a LaTeX distribution).

What might be a use case for doxygen, if it is not used for html
and pdf docs ? What other formats are supported ?

> Because of this, consumers of doxygen, whether they be other FreeBSD 
> ports or just users of doxygen in general, would need to have graphviz 
> and LaTeX installed to get all of doxygen's features. I recently had 
> someone that wanted to build doxygen without the LaTeX dependency, 
> though. So I think ideally, the dependencies for graphviz and LaTeX 
> should becomes separate options, and the HTMLDOCS and PDFDOCS options 
> should only be allowed if graphviz and LaTeX, respectively, are enabled.

The problem is: If a port has options to use doxygen, those
options should also include BUILD_DEPENDS for graphviz etc.
The ports that use doxygen normally do not know about those
BUILD_DEPENDS.

One idea was to provide a /usr/ports/Mk/Uses/doxygen.mk which
provides the necessary "glue" by USES += doxygen.

> All in all, it basically boils down to needing to find a way to include 
> graphviz and LaTeX in a way that doesn't cause too many problems but 
> also allows doxygen to still have the option of building its own 
> documentation.

It's either in or out 8-}

-- 
p...@opsec.eu+49 171 3101372 6 years to go !
___
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

2014-08-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
+-+
textproc/apertium   | 3.2.0   | 3.3.0
+-+


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

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: [CFT] SSP Package Repository available

2014-08-21 Thread Mark Martinec 

Bryan Drewery wrote:

Ports now support enabling Stack Protector [1] support on FreeBSD 10
i386 and amd64, and older releases on amd64 only currently.

Support may be added for earlier i386 releases once all ports properly
respect LDFLAGS.

To enable, just add WITH_SSP=yes to your make.conf and rebuild all 
ports.


The default SSP_CLFAGS is -fstack-protector, but -fstack-protector-all
may optionally be set instead.


That's probably SSP_CFLAGS, not SSP_CLFAGS.


Does clang (in 10-STABLE or CURRENT) support also the
option -fstack-protector-strong ?

Is 'world' by default compiled with -fstack-protector
(and if not, why not).

  Mark
___
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: devel/doxygen woes

2014-08-21 Thread Naram Qashat 

On 08/21/14 05:17, Kurt Jaeger wrote:

Hi!


So I've been getting a lot of issues being directed at me due to the
recent devel/doxygen update to 1.8.7. While I'm not sure why these
issues only cropped up after that update and not before, I would like to
try addressing a few things.


Those discussions always pop up if something changes, even if it is not
related 8-}


doxygen has a bit of an issue in that it uses itself to build its own
documentation.


Let me state this a bit more general:

doxygen has the issue that if you use it, it brings in a huge
amount of dependencies. And currently, this process is not
thought-through.


As a result of this, the HTMLDOCS and PDFDOCS options
will only pull in what is needed to allow doxygen to be built in such a
way to be able to build its own documentation. Because of this, if those
options are left out, then doxygen will be left in a state where it can
no longer build HTML docs fully (because of the lack of graphviz) and
cannot build PDF docs (because of the lack of a LaTeX distribution).


What might be a use case for doxygen, if it is not used for html
and pdf docs ? What other formats are supported ?


As far as I can tell from looking at a Doxyfile, it can generate HTML, Docset 
files for Xcode, Microsoft HTML help (.chm files), Qt compressed help (.qch 
files), Eclipse help plugin, LaTeX (which I believe creates a PDF), RTF, man 
pages, XML, AutoGen definitions, and perlmod. A lot of these are disabled by 
default in Doxyfile, though. I think that doxygen's documentation states that 
only the HTML and LaTeX generators require external dependencies, and dot from 
graphviz is only really needed for HTML if the Doxyfile says it wants to use it.



Because of this, consumers of doxygen, whether they be other FreeBSD
ports or just users of doxygen in general, would need to have graphviz
and LaTeX installed to get all of doxygen's features. I recently had
someone that wanted to build doxygen without the LaTeX dependency,
though. So I think ideally, the dependencies for graphviz and LaTeX
should becomes separate options, and the HTMLDOCS and PDFDOCS options
should only be allowed if graphviz and LaTeX, respectively, are enabled.


The problem is: If a port has options to use doxygen, those
options should also include BUILD_DEPENDS for graphviz etc.
The ports that use doxygen normally do not know about those
BUILD_DEPENDS.

One idea was to provide a /usr/ports/Mk/Uses/doxygen.mk which
provides the necessary "glue" by USES += doxygen.


All in all, it basically boils down to needing to find a way to include
graphviz and LaTeX in a way that doesn't cause too many problems but
also allows doxygen to still have the option of building its own
documentation.


It's either in or out 8-}


Well, I'd already put in a bug for this:

https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=192732

It does mean that, yes, by default, it'll pull in a lot of dependencies. I'm not 
sure if having a uses for doxygen really makes much sense, though. The only 
thing that I can think of that would really need work is probably figuring out 
just what parts of TexLive are actually needed by doxygen instead of trying to 
pull in the full distribution.

___
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: [CFT] SSP Package Repository available

2014-08-21 Thread Ronald Klop 
On Wed, 20 Aug 2014 18:34:22 +0200, Bryan Drewery   
wrote:



On 9/21/2013 5:49 AM, Bryan Drewery wrote:

Ports now support enabling Stack Protector [1] support on FreeBSD 10
i386 and amd64, and older releases on amd64 only currently.

Support may be added for earlier i386 releases once all ports properly
respect LDFLAGS.

To enable, just add WITH_SSP=yes to your make.conf and rebuild all  
ports.


The default SSP_CLFAGS is -fstack-protector, but -fstack-protector-all
may optionally be set instead.

Please help test this on your system. We would like to eventually enable
this by default, but need to identify any major ports that have run-time
issues due to it.

[1] https://en.wikipedia.org/wiki/Buffer_overflow_protection



We have not had any feedback on this yet and want to get it enabled by
default for ports and packages.

We now have a repository that you can use rather than the default to
help test. We need your help to identify any issues before switching the
default.

This repository is available for:

head
10.0
9.1,9.2,9.3

It is not available for 8.4. If someone is willing to test on 8.4 I will
build a repository for it.

Place this in /usr/local/etc/pkgs/repos/FreeBSD_ssp.conf:

FreeBSD: { enabled: no }
FreeBSD_ssp: {
  url: "pkg+http://pkg.FreeBSD.org/${ABI}/ssp";,
  mirror_type: "srv",
  signature_type: "fingerprints",
  fingerprints: "/usr/share/keys/pkg",
  enabled: yes
}

Once that is done you should force reinstall packages from this  
repository:


  pkg update
  pkg upgrade -f

Thanks for your help!
Bryan Drewery
On behalf of portmgr.




Hi,

Is it necessary to upgrade all packages at once or can I just enable  
WITH_SSP and upgrade ports as they are updated in the ports tree?


Ronald.
___
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: [CFT] SSP Package Repository available

2014-08-21 Thread Nikolai Lifanov 
On 08/20/14 12:34, Bryan Drewery wrote:
> On 9/21/2013 5:49 AM, Bryan Drewery wrote:
>> Ports now support enabling Stack Protector [1] support on FreeBSD 10
>> i386 and amd64, and older releases on amd64 only currently.
>>
>> Support may be added for earlier i386 releases once all ports properly
>> respect LDFLAGS.
>>
>> To enable, just add WITH_SSP=yes to your make.conf and rebuild all ports.
>>
>> The default SSP_CLFAGS is -fstack-protector, but -fstack-protector-all
>> may optionally be set instead.
>>
>> Please help test this on your system. We would like to eventually enable
>> this by default, but need to identify any major ports that have run-time
>> issues due to it.
>>
>> [1] https://en.wikipedia.org/wiki/Buffer_overflow_protection
>>
> 
> We have not had any feedback on this yet and want to get it enabled by
> default for ports and packages.
> 
> We now have a repository that you can use rather than the default to
> help test. We need your help to identify any issues before switching the
> default.
> 
> This repository is available for:
> 
> head
> 10.0
> 9.1,9.2,9.3
> 
> It is not available for 8.4. If someone is willing to test on 8.4 I will
> build a repository for it.
> 
> Place this in /usr/local/etc/pkgs/repos/FreeBSD_ssp.conf:
> 
> FreeBSD: { enabled: no }
> FreeBSD_ssp: {
>   url: "pkg+http://pkg.FreeBSD.org/${ABI}/ssp";,
>   mirror_type: "srv",
>   signature_type: "fingerprints",
>   fingerprints: "/usr/share/keys/pkg",
>   enabled: yes
> }
> 
> Once that is done you should force reinstall packages from this repository:
> 
>   pkg update
>   pkg upgrade -f
> 
> Thanks for your help!
> Bryan Drewery
> On behalf of portmgr.
> 

I have been doing a full tree build with WITH_SSP_PORTS enabled and
several partial tree builds for different machines since the initial
inclusion. I had exactly one problem port with it (I can't remember what
it was anymore), but the port was fixed almost immediately.

- Nikolai Lifanov
___
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.freebsd.org

2014-08-21 Thread Wimin Yang 

Hi,

 I found your contact over the web and wanted to send you a quick note. With
the help of Search Engine Optimization and Web Development, your business
can achieve better ranking on prominent search engines like Google, Bing &
others to generate more leads/sales.

This may look like one of those spurious foreign emails you get in your
inbox every day that promise big but delivers nothing. Just to be upfront
we are happy to discuss your requirements.

So, let me know if you are interested in receiving further
information/quote with no strings attached from our team of SEO & Web
experts.

Best regards,   Wimin Yang

   Web Expert / Specialist





BrandRoot SEO LTD.
Hong Kong | China | Australia | New Zealand | US
Disclaimer: This e-mail is private and confidential. If you are not the
intended recipient, please advise us by return e-mail immediately, and
delete the e-mail and any attachments without using or disclosing the
contents in any way. The views expressed in this e-mail are those of the
author, and do not represent those of this company unless this is clearly
indicated. You should scan this e-mail and any attachments for viruses.
This company accepts no liability for any direct or indirect damage or loss
resulting from the use of any attachments to this e-mail. All quotes
received from BrandRoot by email are informal and not binding until a
formal quote is agreed upon by both the parties.
___
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: [CFT] SSP Package Repository available

2014-08-21 Thread Mathias Picker 
On Mi, 2014-08-20 at 11:34 -0500, Bryan Drewery wrote:
> On 9/21/2013 5:49 AM, Bryan Drewery wrote:
> > Ports now support enabling Stack Protector [1] support on FreeBSD 10
> > i386 and amd64, and older releases on amd64 only currently.
> > 
> > Support may be added for earlier i386 releases once all ports properly
> > respect LDFLAGS.
> > 
> > To enable, just add WITH_SSP=yes to your make.conf and rebuild all ports.
> > 
> > The default SSP_CLFAGS is -fstack-protector, but -fstack-protector-all
> > may optionally be set instead.
> > 
> > Please help test this on your system. We would like to eventually enable
> > this by default, but need to identify any major ports that have run-time
> > issues due to it.
> > 
> > [1] https://en.wikipedia.org/wiki/Buffer_overflow_protection
> > 
> 
> We have not had any feedback on this yet and want to get it enabled by
> default for ports and packages.
> 
> We now have a repository that you can use rather than the default to
> help test. We need your help to identify any issues before switching the
> default.
> 
> This repository is available for:
> 
> head
> 10.0
> 9.1,9.2,9.3
> 
> It is not available for 8.4. If someone is willing to test on 8.4 I will
> build a repository for it.
> 
> Place this in /usr/local/etc/pkgs/repos/FreeBSD_ssp.conf:
> 
> FreeBSD: { enabled: no }
> FreeBSD_ssp: {
>   url: "pkg+http://pkg.FreeBSD.org/${ABI}/ssp";,
>   mirror_type: "srv",
>   signature_type: "fingerprints",
>   fingerprints: "/usr/share/keys/pkg",
>   enabled: yes
> }
> 
> Once that is done you should force reinstall packages from this repository:
> 
>   pkg update
>   pkg upgrade -f

This wants me to downgrade pkg to 1.2.7, so I didn't try...

Cheers, Mathias
> 
> Thanks for your help!
> Bryan Drewery
> On behalf of portmgr.
> 



___
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: [CFT] SSP Package Repository available

2014-08-21 Thread Jerry 
On Thu, 21 Aug 2014 16:05:46 +0200, Mathias Picker stated:

>On Mi, 2014-08-20 at 11:34 -0500, Bryan Drewery wrote:
>> On 9/21/2013 5:49 AM, Bryan Drewery wrote:
>> > Ports now support enabling Stack Protector [1] support on FreeBSD 10
>> > i386 and amd64, and older releases on amd64 only currently.
>> > 
>> > Support may be added for earlier i386 releases once all ports properly
>> > respect LDFLAGS.
>> > 
>> > To enable, just add WITH_SSP=yes to your make.conf and rebuild all ports.
>> > 
>> > The default SSP_CLFAGS is -fstack-protector, but -fstack-protector-all
>> > may optionally be set instead.
>> > 
>> > Please help test this on your system. We would like to eventually enable
>> > this by default, but need to identify any major ports that have run-time
>> > issues due to it.
>> > 
>> > [1] https://en.wikipedia.org/wiki/Buffer_overflow_protection

I always build my own ports, I don't use pre-compiled packages. If I place
"WITH_SSP=yes" in the /etc/make.conf" file, do I still have to rebuild all
the ports on my system? I am running FreeBSD-10 amd64.

-- 
Jerry


signature.asc
Description: PGP signature

Re: [FreeBSD-Ports-Announce] Happy 20th birthday FreeBSD ports tree!

2014-08-21 Thread Julian H. Stacey 
Reference:
> From: Frederic Culot 
> Date: Thu, 21 Aug 2014 07:06:46 +0200

Hi,

Frederic Culot wrote:
> [1] http://youtu.be/LiFq5D-zmBs

There's no sound !  I thought my sound had failed, but as a test
there Is sound on adjacent unrelated:
https://www.youtube.com/watch?v=DRsE93FahGA


Should the mailman robot set an automatic
Reply-to: freebsd-ports@freebsd.org
for stuff sent to
Reply-to: ports-annou...@freebsd.org
?  As clicking reply currently replies to low traffic announce only list.

Cheers,
Julian
-- 
Julian Stacey, BSD Linux Unix C Sys Eng Consultant Munich http://berklix.com
Interleave replies Below, like a play script.
Government net spies (technical):
 http://lists.gnupg.org/pipermail/gnupg-users/2014-August/050694.html
 http://www.heise.de/ct/artikel/NSA-GCHQ-The-HACIENDA-Program-for-Internet-Colo
nization-2292681.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: devel/doxygen woes

2014-08-21 Thread Matthias Andree 
Am 21.08.2014 um 13:27 schrieb Naram Qashat:

> Well, I'd already put in a bug for this:
> 
> https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=192732
> 
> It does mean that, yes, by default, it'll pull in a lot of dependencies.
> I'm not sure if having a uses for doxygen really makes much sense,
> though. The only thing that I can think of that would really need work
> is probably figuring out just what parts of TexLive are actually needed
> by doxygen instead of trying to pull in the full distribution.

The unfortunate part about that is that the texlive install comes in
large chunks...

___
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: [CFT] SSP Package Repository available

2014-08-21 Thread Bryan Drewery 
On 8/21/2014 5:34 AM, Mark Martinec wrote:
> Bryan Drewery wrote:
>> Ports now support enabling Stack Protector [1] support on FreeBSD 10
>> i386 and amd64, and older releases on amd64 only currently.
>>
>> Support may be added for earlier i386 releases once all ports properly
>> respect LDFLAGS.
>>
>> To enable, just add WITH_SSP=yes to your make.conf and rebuild all ports.
>>
>> The default SSP_CLFAGS is -fstack-protector, but -fstack-protector-all
>> may optionally be set instead.
> 
> That's probably SSP_CFLAGS, not SSP_CLFAGS.

Nice find.

> 
> 
> Does clang (in 10-STABLE or CURRENT) support also the
> option -fstack-protector-strong ?

Not sure if clang 3.4 has it, but I found a patch for it here:
https://github.com/archlinuxarm/PKGBUILDs/blob/master/extra/llvm/clang-3.4-fstack-protector-strong.patch

> 
> Is 'world' by default compiled with -fstack-protector
> (and if not, why not).

World has been built with -fstack-protector by default since 2008. At
least in 8.0+.


> 
>   Mark
> ___
> freebsd-curr...@freebsd.org mailing list
> http://lists.freebsd.org/mailman/listinfo/freebsd-current
> To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"


-- 
Regards,
Bryan Drewery



signature.asc
Description: OpenPGP digital signature

Re: [CFT] SSP Package Repository available

2014-08-21 Thread Bryan Drewery 
On 8/21/2014 6:56 AM, Ronald Klop wrote:
> On Wed, 20 Aug 2014 18:34:22 +0200, Bryan Drewery 
> wrote:
> 
>> On 9/21/2013 5:49 AM, Bryan Drewery wrote:
>>> Ports now support enabling Stack Protector [1] support on FreeBSD 10
>>> i386 and amd64, and older releases on amd64 only currently.
>>>
>>> Support may be added for earlier i386 releases once all ports properly
>>> respect LDFLAGS.
>>>
>>> To enable, just add WITH_SSP=yes to your make.conf and rebuild all
>>> ports.
>>>
>>> The default SSP_CLFAGS is -fstack-protector, but -fstack-protector-all
>>> may optionally be set instead.
>>>
>>> Please help test this on your system. We would like to eventually enable
>>> this by default, but need to identify any major ports that have run-time
>>> issues due to it.
>>>
>>> [1] https://en.wikipedia.org/wiki/Buffer_overflow_protection
>>>
>>
>> We have not had any feedback on this yet and want to get it enabled by
>> default for ports and packages.
>>
>> We now have a repository that you can use rather than the default to
>> help test. We need your help to identify any issues before switching the
>> default.
>>
>> This repository is available for:
>>
>> head
>> 10.0
>> 9.1,9.2,9.3
>>
>> It is not available for 8.4. If someone is willing to test on 8.4 I will
>> build a repository for it.
>>
>> Place this in /usr/local/etc/pkgs/repos/FreeBSD_ssp.conf:
>>
>> FreeBSD: { enabled: no }
>> FreeBSD_ssp: {
>>   url: "pkg+http://pkg.FreeBSD.org/${ABI}/ssp";,
>>   mirror_type: "srv",
>>   signature_type: "fingerprints",
>>   fingerprints: "/usr/share/keys/pkg",
>>   enabled: yes
>> }
>>
>> Once that is done you should force reinstall packages from this
>> repository:
>>
>>   pkg update
>>   pkg upgrade -f
>>
>> Thanks for your help!
>> Bryan Drewery
>> On behalf of portmgr.
>>
> 
> 
> Hi,
> 
> Is it necessary to upgrade all packages at once or can I just enable
> WITH_SSP and upgrade ports as they are updated in the ports tree?
> 

You can let them update on their own if you wish. Of course SSP won't be
in the binaries until they are rebuilt.

-- 
Regards,
Bryan Drewery



signature.asc
Description: OpenPGP digital signature

Re: [CFT] SSP Package Repository available

2014-08-21 Thread Bryan Drewery 
On 8/21/2014 8:32 AM, Nikolai Lifanov wrote:
> On 08/20/14 12:34, Bryan Drewery wrote:
>> On 9/21/2013 5:49 AM, Bryan Drewery wrote:
>>> Ports now support enabling Stack Protector [1] support on FreeBSD 10
>>> i386 and amd64, and older releases on amd64 only currently.
>>>
>>> Support may be added for earlier i386 releases once all ports properly
>>> respect LDFLAGS.
>>>
>>> To enable, just add WITH_SSP=yes to your make.conf and rebuild all ports.
>>>
>>> The default SSP_CLFAGS is -fstack-protector, but -fstack-protector-all
>>> may optionally be set instead.
>>>
>>> Please help test this on your system. We would like to eventually enable
>>> this by default, but need to identify any major ports that have run-time
>>> issues due to it.
>>>
>>> [1] https://en.wikipedia.org/wiki/Buffer_overflow_protection
>>>
>>
>> We have not had any feedback on this yet and want to get it enabled by
>> default for ports and packages.
>>
>> We now have a repository that you can use rather than the default to
>> help test. We need your help to identify any issues before switching the
>> default.
>>
>> This repository is available for:
>>
>> head
>> 10.0
>> 9.1,9.2,9.3
>>
>> It is not available for 8.4. If someone is willing to test on 8.4 I will
>> build a repository for it.
>>
>> Place this in /usr/local/etc/pkgs/repos/FreeBSD_ssp.conf:
>>
>> FreeBSD: { enabled: no }
>> FreeBSD_ssp: {
>>   url: "pkg+http://pkg.FreeBSD.org/${ABI}/ssp";,
>>   mirror_type: "srv",
>>   signature_type: "fingerprints",
>>   fingerprints: "/usr/share/keys/pkg",
>>   enabled: yes
>> }
>>
>> Once that is done you should force reinstall packages from this repository:
>>
>>   pkg update
>>   pkg upgrade -f
>>
>> Thanks for your help!
>> Bryan Drewery
>> On behalf of portmgr.
>>
> 
> I have been doing a full tree build with WITH_SSP_PORTS enabled and
> several partial tree builds for different machines since the initial
> inclusion. I had exactly one problem port with it (I can't remember what
> it was anymore), but the port was fixed almost immediately.
> 
> - Nikolai Lifanov

My own feedback is that I've been using ports SSP since at least 2009
without issues.

-- 
Regards,
Bryan Drewery



signature.asc
Description: OpenPGP digital signature

Re: [CFT] SSP Package Repository available

2014-08-21 Thread Bryan Drewery 
On 8/21/2014 9:31 AM, Jerry wrote:
> On Thu, 21 Aug 2014 16:05:46 +0200, Mathias Picker stated:
> 
>> On Mi, 2014-08-20 at 11:34 -0500, Bryan Drewery wrote:
>>> On 9/21/2013 5:49 AM, Bryan Drewery wrote:
 Ports now support enabling Stack Protector [1] support on FreeBSD 10
 i386 and amd64, and older releases on amd64 only currently.

 Support may be added for earlier i386 releases once all ports properly
 respect LDFLAGS.

 To enable, just add WITH_SSP=yes to your make.conf and rebuild all ports.

 The default SSP_CLFAGS is -fstack-protector, but -fstack-protector-all
 may optionally be set instead.

 Please help test this on your system. We would like to eventually enable
 this by default, but need to identify any major ports that have run-time
 issues due to it.

 [1] https://en.wikipedia.org/wiki/Buffer_overflow_protection
> 
> I always build my own ports, I don't use pre-compiled packages. If I place
> "WITH_SSP=yes" in the /etc/make.conf" file, do I still have to rebuild all
> the ports on my system? I am running FreeBSD-10 amd64.
> 

Only things built after adding WITH_SSP_PORTS=yes will have SSP enabled.
(WITH_SSP works too but is not the official name anymore).

-- 
Regards,
Bryan Drewery



signature.asc
Description: OpenPGP digital signature

Re: HEADS UP: Pkg 1.3.7 will require rebuilding all packages and manual commands on clients recommended

2014-08-21 Thread Bryan Drewery 
To clarify:

Only people serving packages for distribution need to rebuild so that
their users have fixed packages. If you are running
Poudriere/Tinderbox/Custom and are serving packages to other people or
machines, you should rebuild them on the build system AFTER 1.3.7 is
out. Running pkg check -Ba on the end systems (after upgrading to 1.3.7)
will then prevent needing to reinstall anything.

If you are building from ports then you do not need to rebuild all. You
do not need to reinstall all.

The goal of this announcement is to avoid anyone needing to reinstall
anything unneeded.

Sorry for the inconvenience.

On 8/20/2014 11:27 AM, Bryan Drewery wrote:
> There are 2 parts to this notice. One is strictly for those who build
> their own packages with poudriere or other means. The other part is for
> client-side users of Pkg (including ports users [1]).
> 
> Regardless of which version of Pkg you are on now (1.0, 1.1, 1.2, ...,
> 1.3.4, 1.3.6) it is recommended you follow these steps once upgrading to
> 1.3.7 or later.
> 
> Note that following these directions should only be followed once 1.3.7
> is released in a few days.
> 
> 
> Impact of doing nothing:
> 
> 'pkg upgrade' will suggest reinstalling packages due to 'needed shared
> library changed'. This can result in wasted bandwidth, time and IO on
> your systems. It should eventually work itself out though, but may cause
> various 'pkg upgrade' issues.
> 
> 
> Background:
> 
> Pkg tracks shared libraries that are both required and provided by
> packages. It determines these when building or installing the package.
> This is also true for using ports since it just registers a new package
> on install.
> 
> Before 1.3.0 Pkg would often incorrectly register a shared library with
> the wrong name internally rather than the official SONAME of the
> library. This could result in a library dependency as libname.so.1.2.3
> and the package providing the library advertising libname.so.1. Due to
> packages built from 1.3.0 onwards registering the proper name, the
> upgrade solver had difficulty in finding the proper packages for needed
> shared libraries. A workaround put in place for 1.3.6 was to ignore the
> shlib versions. This was not adequate though. In 1.3.7 we are removing
> the workaround from 1.3.6. There is also a fix in 1.3.7 for Pkg
> sometimes incorrectly registering a package as requiring its own shared
> libraries. This also causes solver confusion.
> 
> 
> Package builders:
> 
> For the sake of your users having proper packages available you should
> remove all existing packages and rebuild them once 1.3.7 is released.
> Poudriere can accomplish this with the '-c' flag to bulk. Or you can
> just remove All/* from your package repository. If your repository is
> using WITH_PKGNG=devel then you can do this now as alpha11 has the fixes.
> 
> 
> Pkg users:
> 
> It is recommended, but not required, to follow these steps once Pkg
> 1.3.7 is available.
> 
> 1. Upgrade Pkg to 1.3.7. Only upgrade Pkg, nothing else.
> 2. As root run 'pkg check -Ba'. This will analyze all of your installed
> packages and fix their registered required/provided shared library
> names. It may take anywhere between 1-15 minutes to complete.
> 3. Proceed with normal upgrade.
> 
> Example automated script:
>   pkg update
>   pkg_local_ver=`pkg query %v ports-mgmt/pkg`
>   pkg_remote_ver=`pkg rquery -U %v ports-mgmt/pkg`
>   # Special handling needed for upgrading <=1.3.6 to 1.3.7+
>   if [ "`pkg version -t ${pkg_local_ver} 1.3.7)`" = "<" ]; then
> pkg install -Uy ports-mgmt/pkg
> pkg check -Ba
>   fi
> 
>   # Normal upgrade can proceed...
>   pkg upgrade -Uy
> 
> 
> You might wonder why we do not just force the 1.3.7 upgrade to auto run
> 'pkg check -Ba'. The problem is that 1.3.0-1.3.6 self-upgrade is not
> properly running the new Pkg as it did in 1.2. Thus after 'pkg upgrade'
> self-upgrades to 1.3.7 it would still be running 1.3.6 until you reran
> 'pkg upgrade'. We may still add an automatic check, or periodic scrub
> script, in future versions.
> 
> 
> [1] Ports users:
> 
> If you strictly use ports and not remote packages then it is not
> required that you do anything. However if you do ever decide to switch
> to packages you will face the same 'needed shared library changed'
> message. It is recommend you also run 'pkg check -Ba' after upgrading to
> 1.3.7. It is possible tools such as portmaster may utilize this
> information some day, so it is good to ensure it is recorded properly.
> 

-- 
Regards,
Bryan Drewery



signature.asc
Description: OpenPGP digital signature

Re: [CFT] SSP Package Repository available

2014-08-21 Thread Bryan Drewery 
On 8/21/2014 10:53 AM, Bryan Drewery wrote:
> On 8/21/2014 5:34 AM, Mark Martinec wrote:
>> Bryan Drewery wrote:
>>> Ports now support enabling Stack Protector [1] support on FreeBSD 10
>>> i386 and amd64, and older releases on amd64 only currently.
>>>
>>> Support may be added for earlier i386 releases once all ports properly
>>> respect LDFLAGS.
>>>
>>> To enable, just add WITH_SSP=yes to your make.conf and rebuild all ports.
>>>
>>> The default SSP_CLFAGS is -fstack-protector, but -fstack-protector-all
>>> may optionally be set instead.
>>
>> That's probably SSP_CFLAGS, not SSP_CLFAGS.
> 
> Nice find.
> 
>>
>>
>> Does clang (in 10-STABLE or CURRENT) support also the
>> option -fstack-protector-strong ?
> 
> Not sure if clang 3.4 has it, but I found a patch for it here:

I'm told that clang 3.5 has support for it. We do not (yet) have 3.5 in
CURRENT.

-- 
Regards,
Bryan Drewery



signature.asc
Description: OpenPGP digital signature

HEADS UP: Berkeley DB 4...4.7 port removals/upgrades may require manual preparation

2014-08-21 Thread Matthias Andree 
Greetings,

The time has now come to remove these db4* ports, Berkeley DB versions
4.0 to 4.7, inclusively.  Most of their dependent ports can cope with
upgrades to db48, db5, or db6, most of the others could be patched to work.

I will wait a few hours after this announcement has appeared on the
lists before committing the change.

I had marked most of the Berkeley DB ports in databases/db4* (db4o-mono
is part of this group) deprecated many months ago.  Released between
2001 and 2008, all have fallen out of the upstream's support many years
ago, too -- and the db5 API is mostly compatible.

IMPORTANT: for some of the ports that use advanced Berkeley DB features
such as the built-in locking, transactional or replication features, the
applications that use Berkeley DB may require special handling
 ... BEFORE YOU UPGRADE BERKELEY DB OR REBUILD THE APPLICATION!

Usually these can be recognized from storing log.* and __db.* files next
to the actual *.db database files.

You must make sure that the applications shut down with a consistent
database state, and wherever possible see to it that you have the data
exported to a format that can later be reimported with the new
BerkeleyDB version, just to be on the safe side.

The exact steps to be taken are too diverse to describe here, because
they depend on the exact version that you are upgrading from, and how
exactly some application is using Berkeley DB.

I have created a Wiki page that contains instructions, and points to
SleepyCat's or Oracle's upgrading documentation, at
.

Please be sure to check these BEFORE upgrading Berkeley DB or your
applications.

When, among the upgrade steps on the WIki, you have reached the point
where it is safe to upgrade the Berkeley DB and applications, there is a
helper script in Tools/scripts/BDB-upgrade-helper.sh uses portmaster or
portupgrade to rebuild the applications to use a newer Berkeley DB, and
then offer to delete the old Berkeley DB ports.

Corresponding upgrade documentation will be committed to ports/UPDATING
along with the relevant changes once this becomes effective.

The binary package upgrades will follow on their regular rebuild
schedule and pick db5 (actually db5.3) by default; I have chosen to pick
db6 only for from-source builds on systems that already have db6
installed because db6 switched to the less liberal Affero GNU General
Public License v3 that requires its users to open-source software
offered as a service, too.

If you have further questions, please ask them on the freebsd-ports@
mailing list, and feel free to Cc: me, but do make sure your mailer does
not break threading, and do keep the Subject line intact.


Thanks for your attention.

Matthias Andree


(*) The exception is mail/popular which will lose its BDB4 plugin along
the way because fixing goes beyond the scope of the ports mailing list.
___
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-udf-preg

2014-08-21 Thread Dave Hayes 
I've been trying to figure out why this port was marked broken then 
removed. The claim is that there were no public distfiles. However...



http://www.goodhumans.com/Misc/lib_mysqludf/lib_mysqludf_preg-LATEST.tar.gz

appears to exist and is downloadable.

Can someone clarify what is going on? Thanks.
--
Dave Hayes - Consultant - Altadena CA, USA - d...@jetcafe.org
 *The opinions expressed above are entirely my own* 

Do not take life too seriously; you will never get out of it
alive.
___
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: ImageMagic + Webp

2014-08-21 Thread Jos Chrispijn 

Jos Chrispijn:

After I installed ImageMagic port, I got stuck at the installation of
Webp:
Just installed ImageMagic again and the installation went perfect - 
thanks for your support!


BR, Jos Chrispijn

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

portupgrade hash error message: HASH: Out of overflow pages. Increase page size

2014-08-21 Thread Kurt Jaeger 
Hi!

If I run 

portupgrade -arR -m BATCH=yes

I currently get this error on 10.0-amd64:

[Updating the portsdb  in /usr/ports ... - 24478 port entries 
found 
.1000.2000.3000.4000.5000.6000.7000.8000.9000.1.11000.12000.13000.14000.15000.16000.17000.18000.19000.2.21000.22000.23000.24000..HASH:
 Out of overflow pages.  Increase page size
/usr/ports/INDEX-10:24206:dbm_store failed
.. . done]

Any ideas on how to fix this ?

-- 
p...@opsec.eu+49 171 3101372 6 years to go !
___
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: portupgrade hash error message: HASH: Out of overflow pages. Increase page size

2014-08-21 Thread Bryan Drewery 
On 8/21/2014 3:12 PM, Kurt Jaeger wrote:
> Hi!
> 
> If I run 
> 
> portupgrade -arR -m BATCH=yes
> 
> I currently get this error on 10.0-amd64:
> 
> [Updating the portsdb  in /usr/ports ... - 24478 port 
> entries found 
> .1000.2000.3000.4000.5000.6000.7000.8000.9000.1.11000.12000.13000.14000.15000.16000.17000.18000.19000.2.21000.22000.23000.24000..HASH:
>  Out of overflow pages.  Increase page size
> /usr/ports/INDEX-10:24206:dbm_store failed
> .. . done]
> 
> Any ideas on how to fix this ?
> 

Try portsdb -FU first.

-- 
Regards,
Bryan Drewery



signature.asc
Description: OpenPGP digital signature

Re: portupgrade hash error message: HASH: Out of overflow pages. Increase page size

2014-08-21 Thread Kurt Jaeger 
Hi!

> > portupgrade -arR -m BATCH=yes
> > 
> > I currently get this error on 10.0-amd64:
> > 
> > [Updating the portsdb  in /usr/ports ... - 24478 port 
> > entries found 
> > .1000.2000.3000.4000.5000.6000.7000.8000.9000.1.11000.12000.13000.14000.15000.16000.17000.18000.19000.2.21000.22000.23000.24000..HASH:
> >  Out of overflow pages.  Increase page size
> > /usr/ports/INDEX-10:24206:dbm_store failed
> > .. . done]
> > 
> > Any ideas on how to fix this ?
> > 
> 
> Try portsdb -FU first.

I tried it, same error.

-- 
p...@opsec.eu+49 171 3101372 6 years to go !
___
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: portupgrade hash error message: HASH: Out of overflow pages. Increase page size

2014-08-21 Thread Matthias Andree 
Am 21.08.2014 um 22:36 schrieb Kurt Jaeger:
> Hi!
> 
>>> portupgrade -arR -m BATCH=yes
>>>
>>> I currently get this error on 10.0-amd64:
>>>
>>> [Updating the portsdb  in /usr/ports ... - 24478 port 
>>> entries found 
>>> .1000.2000.3000.4000.5000.6000.7000.8000.9000.1.11000.12000.13000.14000.15000.16000.17000.18000.19000.2.21000.22000.23000.24000..HASH:
>>>  Out of overflow pages.  Increase page size
>>> /usr/ports/INDEX-10:24206:dbm_store failed
>>> .. . done]
>>>
>>> Any ideas on how to fix this ?
>>>
>>
>> Try portsdb -FU first.
> 
> I tried it, same error.
> 

Why is it using dbm_hash for you?
bdb_btree works for me OOTB.
___
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: portupgrade hash error message: HASH: Out of overflow pages. Increase page size

2014-08-21 Thread Bryan Drewery 
On 8/21/2014 3:36 PM, Kurt Jaeger wrote:
> Hi!
> 
>>> portupgrade -arR -m BATCH=yes
>>>
>>> I currently get this error on 10.0-amd64:
>>>
>>> [Updating the portsdb  in /usr/ports ... - 24478 port 
>>> entries found 
>>> .1000.2000.3000.4000.5000.6000.7000.8000.9000.1.11000.12000.13000.14000.15000.16000.17000.18000.19000.2.21000.22000.23000.24000..HASH:
>>>  Out of overflow pages.  Increase page size
>>> /usr/ports/INDEX-10:24206:dbm_store failed
>>> .. . done]
>>>
>>> Any ideas on how to fix this ?
>>>
>>
>> Try portsdb -FU first.
> 
> I tried it, same error.
> 

What version of ruby do you have?

Do you have ruby-bdb installed? (May be ruby19-bdb or ruby20-bdb)

-- 
Regards,
Bryan Drewery



signature.asc
Description: OpenPGP digital signature

[PATCH] x11-fm/mate-file-manager and x11-fm/caja

2014-08-21 Thread Tomasz Sowa 
Hi

There is a problem in caja with default manual sort order option,
I have mentioned it here:
http://forums.mate-desktop.org/viewtopic.php?f=2&t=3093

Applying:
# cd /usr/ports/x11-fm/caja/files
# fetch http://tmp.ttmath.org/patch-src_file-manager_fm-icon-view.c
# cd ..
# make all reinstall clean

The same patch can be applied to caja 1.6 (x11-fm/mate-file-manager)

-- 
Tomasz Sowa

--- src/file-manager/fm-icon-view.c.orig2014-08-22 04:45:24.0 
+0200
+++ src/file-manager/fm-icon-view.c 2014-08-22 04:43:44.0 +0200
@@ -865,6 +865,22 @@
 {
 const SortCriterion *default_sort_criterion;
 default_sort_criterion = get_sort_criterion_by_sort_type 
(get_default_sort_order (file, NULL));
+
+   if( default_sort_criterion == NULL )
+   {
+/*
+ * default_sort_criterion will be NULL if default sort order is set to:
+ * 'directory' or 'atime'
+ * get_sort_criterion_by_sort_type() enumerates through 
'sort_criteria' table
+ * but this table doesn't have 'directory' and 'atime' items
+ *
+ * may 'sort_criteria' table should have those two items too?
+ *
+ * temporarily changing it to 'sort by display name'
+ */
+default_sort_criterion = &sort_criteria[0];
+   }
+
 g_return_val_if_fail (default_sort_criterion != NULL, NULL);
 
 return caja_file_get_metadata
@@ -994,6 +1010,35 @@
  keep_aligned);
 }
 
+
+/* maintainence of auto layout boolean
+ * it will be changed in default_sort_order_changed_callback()
+ */
+static gboolean default_directory_manual_layout = FALSE;
+
+static gboolean
+get_default_directory_manual_layout (void)
+{
+static gboolean auto_storaged_added = FALSE;
+
+if (auto_storaged_added == FALSE)
+{
+auto_storaged_added = TRUE;
+int default_sort_order_enum = 0;
+
+/* only read the value here, it will be changed in
+ * default_sort_order_changed_callback() callback in the future
+ */
+default_sort_order_enum = g_settings_get_enum(caja_preferences,
+  
CAJA_PREFERENCES_DEFAULT_SORT_ORDER);
+
+default_directory_manual_layout = (default_sort_order_enum == 0);
+}
+
+return default_directory_manual_layout;
+}
+
+
 static gboolean
 fm_icon_view_get_directory_auto_layout (FMIconView *icon_view,
 CajaFile *file)
@@ -1017,10 +1062,8 @@
 fm_icon_view_real_get_directory_auto_layout (FMIconView *icon_view,
 CajaFile *file)
 {
-
-
 return caja_file_get_boolean_metadata
-   (file, CAJA_METADATA_KEY_ICON_VIEW_AUTO_LAYOUT, TRUE);
+   (file, CAJA_METADATA_KEY_ICON_VIEW_AUTO_LAYOUT, 
!get_default_directory_manual_layout ());
 }
 
 static void
@@ -1050,7 +1093,7 @@
 
 caja_file_set_boolean_metadata
 (file, CAJA_METADATA_KEY_ICON_VIEW_AUTO_LAYOUT,
- TRUE,
+ !get_default_directory_manual_layout (),
  auto_layout);
 }
 /* maintainence of tighter layout boolean */
@@ -1950,6 +1993,15 @@
 
 caja_icon_container_sort (icon_container);
 
+/* Switch to manual layout of the default calls for it.
+ * This needs to happen last for the sort order menus
+ * to be in sync.
+ */
+if (get_default_directory_manual_layout ())
+{
+switch_to_manual_layout (icon_view);
+}
+
 update_layout_menus (icon_view);
 
 fm_icon_view_restore_default_zoom_level (view);
@@ -2722,19 +2774,42 @@
 CajaFile *file;
 char *sort_name;
 CajaIconContainer *icon_container;
+int default_sort_order_local;
 
 g_return_if_fail (FM_IS_ICON_VIEW (callback_data));
 
 icon_view = FM_ICON_VIEW (callback_data);
-
 file = fm_directory_view_get_directory_as_file (FM_DIRECTORY_VIEW 
(icon_view));
-sort_name = fm_icon_view_get_directory_sort_by (icon_view, file);
-set_sort_criterion (icon_view, get_sort_criterion_by_metadata_text 
(sort_name));
-g_free (sort_name);
-
 icon_container = get_icon_container (icon_view);
 g_return_if_fail (CAJA_IS_ICON_CONTAINER (icon_container));
 
+default_sort_order_local = g_settings_get_enum (caja_preferences,
+   
CAJA_PREFERENCES_DEFAULT_SORT_ORDER);
+
+default_sort_order = (CajaFileSortType)default_sort_order_local;
+
+if( default_sort_order == 0 )
+   {
+/* default sort order is set as 'manually' */
+default_directory_manual_layout = TRUE;
+
+caja_icon_container_set_auto_layout (
+icon_container,
+fm_icon_view_get_directory_auto_layout(icon_view, file) );
+}
+else
+{
+default_directory_manual_layout = FALSE;
+
+caja_icon_container_set_auto_layout (
+icon_container,
+fm_icon_view_get_directory_auto_layout(icon_view, file) );
+
+sort_name = fm_icon_view_get_directory_sort_by (icon_view, file);
+set_sort_criterion (ic

Re: portupgrade hash error message: HASH: Out of overflow pages. Increase page size

2014-08-21 Thread Kurt Jaeger 
Hi!

> What version of ruby do you have?
> 
> Do you have ruby-bdb installed? (May be ruby19-bdb or ruby20-bdb)

pkg info | grep ruby

ruby-2.1.2,1   Object-oriented interpreted scripting language
ruby19-1.9.3.547,1 Object-oriented interpreted scripting language
ruby19-bdb-0.6.6_3 Ruby interface to Oracle Berkeley DB revision 2 
or later

-- 
p...@opsec.eu+49 171 3101372 6 years to go !
___
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"