Re: cpuminer mines only on one core regardless of "--threads" option

2014-02-19 Thread Martin Matuska 
On 2014-02-18 15:24, Andrey Chernov wrote:
> On 14.01.2014 17:55, Volodymyr Kostyrko wrote:
>> 14.01.2014 15:01, Alexander:
>>> on Freebsd 9.2 x64 on 5 different PCs I installed net-p2p/cpuminer
>>> from ports and by "pkg install" - result is the same - minerd mines
>>> only on one core regardless of "--threads" option.
> The patch to solve this problem attached.
>
Patch committed.
It would be cool if cpuminer was compilable with clang, too.
___
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: Dovecot

2014-02-19 Thread Andrei Brezan 

On 02/18/14 18:54, Jos Chrispijn wrote:

Hi Andrei,

Andrei Brezan:
You can check /var/db/ports/postfix/options to see what options you 
have for postfix. I think it's easier if you can tell us the output 
of "uname -a" plus the exact command you try when you get this error. 
I'm not sure what you want to achieve, I only see that something 
wants to pull dovecot2 while you have dovecot-1 installed.


Just checked my /var/db/ports/mail_postfix/options:

OPTIONS_FILE_UNSET+=DOVECOT
OPTIONS_FILE_SET+=DOVECOT2

So perhaps that would be the problem (having dovecot2 set instead of 
dovecot?)


Best regards,
Jos



Yes, most likely postfix is trying to install dovecot2. I still don't 
know what command are you issuing when you get this error.


There are several scenarios, do you have a running mail server with 
postfix/dovecot? If yes changing to dovecot2 will involve some 
configuration changes as things have changed in dovecot2. You can switch 
the config setting back to dovecot with "make config" in 
/usr/ports/mail/postfix if you don't want to move to dovecot2 yet.


Regards,
Andrei
___
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-02-19 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
+-+
games/doomsday  | 1.12.2  | 
1.14.0-build1144
+-+
lang/bigloo | 4.0b| 4.1a
+-+


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"

RFC: bsd.port.mk needs some changes around plist processing

2014-02-19 Thread Matthias Andree 
Greetings,

we've recently seen that the docbook ports were broken, and while the
ports now build, they still cause leftover directories;

Details in PR 186882:


Sample log from Tinderbox:


Background: the ports - by way of textproc/docbook/bsd.docbook.mk -
add port documentation to TMPPLIST, and adds a few @dirrm-like instances
to TMPPLIST, too.  In practice, this does not work due to several
ordering issues in bsd.port.mk:


1. TMPPLIST stuff added from do-install is *not* subject to the
@dirrmtry and related processing that generate-plist does.  Stuff added
from pre-install would be, however.

This processing, for instance, changes @dirrmtry D to @unexec rmdir D ||
: for pre-pkgNG hosts.

The cause is that generate-plist runs between pre-install and do-install.


2. post-stage stuff is currently executed *after* stage-qa, so stage-qa
does not check the final state of the stagedir, but an intermediate
state.  In particular, if post-stage were used to fix TMPPLIST, stage-qa
would already have complained about plist problems that are no longer
present when the overall "stage" target is reached.

Consequence: The port in fact cannot add @dirrm to TMPPLIST without
reimplementing several bsd.port.mk targets or without causing bogus
warnings.

It is certainly possible to work around all this with a POST-DEINSTALL
target, but I propose that we fix the framework instead.


I propose that bsd.port.mk:

F1. moves stage-qa until after post-stage so that stage-qa validates the
final STAGEDIR contents.

F2. adds a late-plist target so that a port can add clean-up material to
TMPPLIST *after* everything that is derived from variables such as
PORTDOCS, PORTEXAMPLES.  This should be really late in the process,
possibly only before the fix-plist-sequence.

F3. the postprocessing with REINPLACE_CMD that, for instance, translates
@dirrmtry, be
(a) split out from generate-plist and
(b) run *after* late-plist,

so that ports can just start using the pkgNG directives (such as
@dirrmtry) that pkg_create does not understand.  Possibly before the
fix-plist-sequence target.

F3 is particularly important so that we don't add backwards kludges (as
mat@ had to do for the docbook/bsd.docbook.mk) that we will have to
clean up later when pkgNG is the only supported tool.


Now, I've tried to figure out how the whole bsd.port.mk rigging works,
took a few stabs at it, and have found myself lost, so I cannot propose
code or provide patches; someone who is more acquainted with the
bsd.port.mk sequencing and target innards should do that.

I'll be happy to help with testing, and fixing the docbook ports, on
pkgNG as well as on pkg_create/pkg_add systems.

Any takers?

Cheers,
Matthias
___
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: cpuminer mines only on one core regardless of "--threads" option

2014-02-19 Thread Andrey Chernov 
On 19.02.2014 12:42, Martin Matuska wrote:
> Patch committed.

Thanx. BTW, it is accepted in the upstream too.

> It would be cool if cpuminer was compilable with clang, too.

Running included in the sources ./nomacro.pl before ./configure supposed
to fix clang, but I don't check it.

-- 
http://ache.vniz.net/
___
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: Error build the port devel/glib20

2014-02-19 Thread Tijl Coosemans 
On Fri, 14 Feb 2014 16:47:55 + Mark Knight wrote:
> Ah, okay thanks. I just tried that but cups-base still blew up. I'll
> wait patiently for the PRs to be actioned since I have a workaround.
> Thanks for all of your help!

I had another look at it and it turns out to be problem during
installation, not during compilation.  It should be fixed now in
r345090.
___
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: [patch] sysutils/beadm

2014-02-19 Thread Bryan Drewery 
On 2/13/2014 4:19 PM, Andrew Hotlab wrote:
> First of all, thank you very much for the good work with this port. I'm sure 
> it's changing the life of a lot FreeBSD system administrators!
> 
> In my setup I have the following layout (several datasets for /usr, /var, 
> etc.):
> 
> NAME   USED  AVAIL  REFER  MOUNTPOINT
> sys   1.55G  18.0G31K  none
> sys/ROOT   532M  18.0G31K  none
> sys/ROOT/default   114K  18.0G   250M  /
> sys/ROOT/default/tmp22K  18.0G38K  /tmp
> sys/ROOT/default/usr 1K  18.0G   245M  /usr
> sys/ROOT/default/var  48.5K  18.0G  36.4M  /var
> sys/swap  1.03G  19.0G16K  -
> 
> At this moment the utility does not seems to be able to manage this scheme, 
> since it sets the mountpoint property as "legacy" for all datasets under the 
> root, thus preventing to automatically mount any subdirectory at boot.
> I've tested this simple solution (to let do the job to the canmount 
> property), and it seems to solve the problem without affecting the behavior 
> when all system folders are located under a single root dataset (please see 
> the patch below). I'd be glad if you'll include it in the next port revision.
> 
> I'm at your disposal for any further detail.
> 
> Best regards.
> 
> Andrew
> 
> 
> --- ./beadm 2014-01-11 17:08:31.112384992 +0100
> +++ /usr/local/sbin/beadm 2014-01-11 17:06:38.620706860 +0100
> @@ -505,7 +505,7 @@
> if [ ${MOUNT} -eq 0 ]
> then
> zfs umount ${POOL}/${BEDS}/${2}
> - zfs set mountpoint=legacy ${POOL}/${BEDS}/${2}
> + zfs set mountpoint=/ ${POOL}/${BEDS}/${2}
> fi
> fi
> if ! zpool set bootfs=${POOL}/${BEDS}/${2} ${POOL} 1> /dev/null 2> /dev/null
> @@ -518,6 +518,7 @@
> ZFS_LIST=$( zfs list -H -o name -r ${POOL}/${BEDS} )
> # disable automatic mount on all inactive boot environments
> echo "${ZFS_LIST}" \
> + | grep -v "^${POOL}/${BEDS}$" \
> | grep -v "^${POOL}/${BEDS}/${2}$" \
> | grep -v "^${POOL}/${BEDS}/${2}/" \
> | while read NAME   
> 

ACK on this. CC'ing upstream maintainer too.

I run the same setup but I specifically set /usr /var and /tmp mntpoints
to /usr,/var/,/tmp to avoid this issue. I am not sure if mntpoint=/ is
proper. I recall there being an issue with it. I would much prefer your
patch though if it is safe.

Does beadm mount still work with this to mount a new BE into /tmp?

Ie,

beadm create newbe
beadm mount newbe

Does it go and remount / or only touch /tmp?

How about activating? Does it blow away / right away or wait until reboot?

-- 
Regards,
Bryan Drewery



signature.asc
Description: OpenPGP digital signature

Re: GSSAPI and Heimdal in Base

2014-02-19 Thread Bryan Drewery 
On 2/17/2014 5:23 PM, Robert Simmons wrote:
> Actually both port and base are 1.5.2. Base was updated in Apr 2012:
> http://svnweb.freebsd.org/base?view=revision&revision=234027
> 
> Both 9.x and 10.0 have Heimdal 1.5.2, same version in ports.
> 
> The Heimdal project's current stable version is actually 1.5.3. They
> have forgotten to update their main website, but the Git repository
> speaks the truth:
> https://github.com/heimdal/heimdal/blob/master/NEWS
> 
> Also, they are pushing out 1.6 release candidates at the moment, so I
> think 1.6 should arrive shortly.
> 
> I will give the project a poke and see if they can update their
> website, but security/openssh-portable should build fine against
> heimdal base or the  heimdal port since they are identical.


I will take another look, however I could not get it to build with the
base heimdal so I marked it broken.

> 
> On Mon, Feb 17, 2014 at 7:43 AM, Dewayne Geraghty
>  wrote:
>> Robert,
>> There's a couple of versions different.  Heimdal from ports is 1.5.2.
>> I'm writing personally because I don't build any systems with the
>> heimdal in base, but I recall it being around 1.0.1 on 9.X.
>>
>> As an aside I recall the openssh developer mentioning somewhere that
>> gssapi wasn't supported in openssh 6.5, but if it builds for you then
>> you're probably running an earlier version of the ports system?  It's
>> also helpful to let folks know what FreeBSD version you're discussing ;)
>>
>> Cheers, Dewayne
>>
>> On 17/02/2014 5:14 PM, Robert Simmons wrote:
>>> When building openssh-portable, and enabling kerb_gssapi, but using
>>> the heimdal that is in base, it gives the error:
>>> KERB_GSSAPI Requires either MIT or HEMIDAL, does not build with base
>>> Heimdal currently
>>>
>>> What is the difference between base and the port of Heimdal?
>>> ___
>>> 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@freebsd.org mailing list
> http://lists.freebsd.org/mailman/listinfo/freebsd-ports
> To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org"
> 


-- 
Regards,
Bryan Drewery



signature.asc
Description: OpenPGP digital signature

Re: misc/186883: last update of docbook broke building kdelibs

2014-02-19 Thread Sergio de Almeida Lenzi 
Em Qua, 2014-02-19 às 13:58 +0100, Antoine Brodin escreveu:

> Please try patch below
> Kdelibs expects to find docbookx.dtd in
> share/xml/docbook/${DOCBOOKXML_CURRENTDTD_VERSION} , not in a subdir
> 
> Index: textproc/docbook-xml/Makefile
> ===
> --- textproc/docbook-xml/Makefile   (revision 345083)
> +++ textproc/docbook-xml/Makefile   (working copy)
> @@ -3,7 +3,7 @@
> 
>  PORTNAME=  docbook-xml
>  PORTVERSION=   4.2
> -PORTREVISION=  3
> +PORTREVISION=  4
>  MASTER_SITES=  http://www.docbook.org/xml/${PORTVERSION}/ \
> 
> http://www.oasis-open.org/committees/docbook/xml/${PORTVERSION}/
> 
> @@ -13,6 +13,7 @@
>  NO_ISOCAT= yes
>  XML_DTD=   yes
>  HAS_MANUAL_CATALOG_FILE=   yes
> +NO_DTD_SUBDIR= yes
> 
>  DTD_NAME?= ${PORTNAME:S/-xml//}


YES!!!
it fix for me here...

I think we can close the PR

Waiting for more tests (9.X, 8.X)

For me it is done...

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: misc/186883: last update of docbook broke building kdelibs

2014-02-19 Thread Chad J. Milios 

On 2/19/2014 8:37 AM, Sergio de Almeida Lenzi wrote:

Em Qua, 2014-02-19 às 13:58 +0100, Antoine Brodin escreveu:


Please try patch below
Kdelibs expects to find docbookx.dtd in
share/xml/docbook/${DOCBOOKXML_CURRENTDTD_VERSION} , not in a subdir

Index: textproc/docbook-xml/Makefile
===
--- textproc/docbook-xml/Makefile   (revision 345083)
+++ textproc/docbook-xml/Makefile   (working copy)
@@ -3,7 +3,7 @@

  PORTNAME=  docbook-xml
  PORTVERSION=   4.2
-PORTREVISION=  3
+PORTREVISION=  4
  MASTER_SITES=  http://www.docbook.org/xml/${PORTVERSION}/ \
 
http://www.oasis-open.org/committees/docbook/xml/${PORTVERSION}/

@@ -13,6 +13,7 @@
  NO_ISOCAT= yes
  XML_DTD=   yes
  HAS_MANUAL_CATALOG_FILE=   yes
+NO_DTD_SUBDIR= yes

  DTD_NAME?= ${PORTNAME:S/-xml//}


YES!!!
it fix for me here...

I think we can close the PR

Waiting for more tests (9.X, 8.X)

For me it is done...

Thanks
That worked perfectly for me on 9.2-RELEASE as well. I was going to say, 
"Can we get kdelibs4 to find it in the dtd directory instead?" but I see 
the way docbook-xml is now installing files after the above patch 
matches the way it was doing it a few days ago so this seems acceptable 
to me.

___
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] r345043: 5x success, 2x configure_error, 1x leftovers, 1x coredump, 2x depend (configure_error in www/seamonkey), 1x depend (coredump in www/seamonkey)

2014-02-19 Thread Ports-QAT 
Update to 2.24

Submitted by:   Jan Beich
Security:   
http://www.vuxml.org/freebsd/1753f0ff-8dd5-11e3-9b45-b4b52fce4ce8.html
-

  Build ID:  20140219092600-15858
  Job owner: b...@freebsd.org
  Buildtime: 5 hours
  Enddate:   Wed, 19 Feb 2014 14:46:36 GMT

  Revision:  r345043
  Repository:
https://svnweb.freebsd.org/ports?view=revision&revision=345043

-

Port:www/linux-seamonkey 2.24

  Buildgroup: 8.4-QAT/amd64
  Buildstatus:   SUCCESS
  Log: 
https://qat.redports.org//~b...@freebsd.org/20140219092600-15858-281072/linux-seamonkey-2.24.log

  Buildgroup: 8.4-QAT/i386
  Buildstatus:   SUCCESS
  Log: 
https://qat.redports.org//~b...@freebsd.org/20140219092600-15858-281073/linux-seamonkey-2.24.log

  Buildgroup: 9.2-QAT/amd64
  Buildstatus:   SUCCESS
  Log: 
https://qat.redports.org//~b...@freebsd.org/20140219092600-15858-281074/linux-seamonkey-2.24.log

  Buildgroup: 9.2-QAT/i386
  Buildstatus:   SUCCESS
  Log: 
https://qat.redports.org//~b...@freebsd.org/20140219092600-15858-281075/linux-seamonkey-2.24.log

-

Port:www/seamonkey 2.24

  Buildgroup: 8.4-QAT/amd64
  Buildstatus:   CONFIGURE_ERROR
  Log: 
https://qat.redports.org//~b...@freebsd.org/20140219092600-15858-281076/seamonkey-2.24.log

  Buildgroup: 8.4-QAT/i386
  Buildstatus:   CONFIGURE_ERROR
  Log: 
https://qat.redports.org//~b...@freebsd.org/20140219092600-15858-281077/seamonkey-2.24.log

  Buildgroup: 9.2-QAT/amd64
  Buildstatus:   SUCCESS
  Log: 
https://qat.redports.org//~b...@freebsd.org/20140219092600-15858-281078/seamonkey-2.24.log

  Buildgroup: 9.2-QAT/i386
  Buildstatus:   COREDUMP
  Log: 
https://qat.redports.org//~b...@freebsd.org/20140219092600-15858-281079/seamonkey-2.24.log

-

Port:www/seamonkey-i18n 2.24

  Buildgroup: 8.4-QAT/amd64
  Buildstatus:   DEPEND (CONFIGURE_ERROR IN WWW/SEAMONKEY)
  Log: 
https://qat.redports.org//~b...@freebsd.org/20140219092600-15858-281080/seamonkey-2.24.log

  Buildgroup: 8.4-QAT/i386
  Buildstatus:   DEPEND (CONFIGURE_ERROR IN WWW/SEAMONKEY)
  Log: 
https://qat.redports.org//~b...@freebsd.org/20140219092600-15858-281081/seamonkey-2.24.log

  Buildgroup: 9.2-QAT/amd64
  Buildstatus:   LEFTOVERS
  Log: 
https://qat.redports.org//~b...@freebsd.org/20140219092600-15858-281082/seamonkey-i18n-2.24.log

  Buildgroup: 9.2-QAT/i386
  Buildstatus:   DEPEND (COREDUMP IN WWW/SEAMONKEY)
  Log: 
https://qat.redports.org//~b...@freebsd.org/20140219092600-15858-281083/seamonkey-2.24.log


--
Buildarchive URL: 
redports 
___
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: Ports revision bump?

2014-02-19 Thread Mathieu Arnold 
+--On 18 février 2014 19:53:45 +0100 Jos Chrispijn  wrote:
|Dear group,
|Just ran into a ports issue for Docbook 4.x.x
|Can you tell me how to solve this?

I'm not exactly sure what was the problem, but it should be fixed in
r345097.

Regards,

-- 
Mathieu Arnold
___
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: last update of docbook broke KDE4

2014-02-19 Thread Mathieu Arnold 
+--On 18 février 2014 19:17:35 -0500 "Chad J. Milios" 
wrote:
| On 2/18/2014 2:13 PM, Sergio de Almeida Lenzi wrote:
|> FreeBSD freebsd10.toontown 10.0-RELEASE FreeBSD 10.0-RELEASE #0
|> r261076M: Thu Jan 23 21:21:09 BRST 2014
|> 
|> -- The following REQUIRED packages have not been found:
|> 
|>   * DocBookXML , DocBook XML ,
|> 
|> Required by the KDE help system to process DocBook XML
|> 
|> CMake Error at /usr/local/share/cmake/Modules/FeatureSummary.cmake:430
|> (message):
|>feature_summary() Error: REQUIRED package(s) are missing, aborting
|> CMake
|>run.
|> Call Stack (most recent call first):
|>CMakeLists.txt:397 (feature_summary)
|> 
|> 
|> -- Configuring incomplete, errors occurred!
| 
| I have the exact same error on 9.2-RELEASE-p3 as well. Furthermore,

It should be fixed with r345097.

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

What should be in scripts shebangs for python2?

2014-02-19 Thread Lev Serebryakov 
Hello, Freebsd-ports.

 My port uses some pythons scripts to configure (it is not pythonn-related
by itself, only authors of this software use python scripts on build
stage).

 How should I patch these scripts to work? It looks like
/usr/local/bin/python2 is installed by devel/python2 port, and
USE_PYTHON_BUILD=yes doesn't depends on this port, but on python27, which
could be changed in future or by users's request, so I don't want to
hardcode /usr/local/bin/python2.7, too...

-- 
// Black Lion AKA Lev Serebryakov 

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

Re: What should be in scripts shebangs for python2?

2014-02-19 Thread Serpent7776 
On Wed, 19 Feb 2014 19:02:01 +0400
Lev Serebryakov  wrote:

> Hello, Freebsd-ports.
> 
>  My port uses some pythons scripts to configure (it is not pythonn-related
> by itself, only authors of this software use python scripts on build
> stage).
> 
>  How should I patch these scripts to work? It looks like
> /usr/local/bin/python2 is installed by devel/python2 port, and
> USE_PYTHON_BUILD=yes doesn't depends on this port, but on python27, which
> could be changed in future or by users's request, so I don't want to
> hardcode /usr/local/bin/python2.7, too...
> 

I think it would be 

#!/usr/bin/env python2

-- 
//
// Serpent7776
//

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

Re: What should be in scripts shebangs for python2?

2014-02-19 Thread Marcus von Appen 


Lev Serebryakov :


Hello, Freebsd-ports.

 My port uses some pythons scripts to configure (it is not pythonn-related
by itself, only authors of this software use python scripts on build
stage).

 How should I patch these scripts to work? It looks like
/usr/local/bin/python2 is installed by devel/python2 port, and
USE_PYTHON_BUILD=yes doesn't depends on this port, but on python27, which


USE_PYTHON_BUILD=yes indicates that the port supports any python  
version, no matter,

if the user chooses python2.X or python3.x as the default for the system.

If your port is compatible with any python version and only uses  
python for configuring
some bits, but does *not* need python at run-time, you should patch  
the scripts to
use ${PYTHON_CMD},  via a ${REINPLACE_CMD} or the proper python_CMD=  
${PYTHON_CMD} command

for the shebang USES.

If your port is only compatible for a specific branch (either 2.x OR  
3.x), use the proper
major number for USE_PYTHON_BUILD, e.g. USE_PYTHON_BUILD=2. If the  
port is only compatible
with a specific release (e.g. 3.2), use USE_PYTHON_BUILD=X.Y. For  
those cases, you also can
rely on ${PYTHON_CMD}, which points to whatever is the most  
appropriate version.


In short:
* Use ${PYTHON_CMD} to replace the shebang lines or references of the  
python command
* Use the proper supported python version (yes for any, 2 or 3 for a  
branch, X.Y for a release)

  for USE_PYTHON_BUILD


could be changed in future or by users's request, so I don't want to
hardcode /usr/local/bin/python2.7, too...


Indeed, do not do this.

Cheers
Marcus

___
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: [patch] sysutils/beadm

2014-02-19 Thread Andrew Hotlab 

> Date: Wed, 19 Feb 2014 07:27:45 -0600
> From: bdrew...@freebsd.org
> To: andrew.hot...@hotmail.com
> CC: po...@freebsd.org; verma...@interia.pl
> Subject: Re: [patch] sysutils/beadm
>
> On 2/13/2014 4:19 PM, Andrew Hotlab wrote:
>> First of all, thank you very much for the good work with this port. I'm sure 
>> it's changing the life of a lot FreeBSD system administrators!
>>
>> In my setup I have the following layout (several datasets for /usr, /var, 
>> etc.):
>>
>> NAME USED AVAIL REFER MOUNTPOINT
>> sys 1.55G 18.0G 31K none
>> sys/ROOT 532M 18.0G 31K none
>> sys/ROOT/default 114K 18.0G 250M /
>> sys/ROOT/default/tmp 22K 18.0G 38K /tmp
>> sys/ROOT/default/usr 1K 18.0G 245M /usr
>> sys/ROOT/default/var 48.5K 18.0G 36.4M /var
>> sys/swap 1.03G 19.0G 16K -
>>
>> At this moment the utility does not seems to be able to manage this scheme, 
>> since it sets the mountpoint property as "legacy" for all datasets under the 
>> root, thus preventing to automatically mount any subdirectory at boot.
>> I've tested this simple solution (to let do the job to the canmount 
>> property), and it seems to solve the problem without affecting the behavior 
>> when all system folders are located under a single root dataset (please see 
>> the patch below). I'd be glad if you'll include it in the next port revision.
>>
>
> ACK on this. CC'ing upstream maintainer too.
>
> I run the same setup but I specifically set /usr /var and /tmp mntpoints
> to /usr,/var/,/tmp to avoid this issue. I am not sure if mntpoint=/ is
> proper. I recall there being an issue with it. I would much prefer your
> patch though if it is safe.
>
> Does beadm mount still work with this to mount a new BE into /tmp?
>
> Ie,
>
> beadm create newbe
> beadm mount newbe
>
> Does it go and remount / or only touch /tmp?
>

It seems to behave correctly, as you can see in the attached transcript.

> How about activating? Does it blow away / right away or wait until reboot?

Since beadm changes only the "canmount" ZFS property to set the active 
environment for the next reboot, there is no implications for the running 
environment.

Regards

Andrewroot@BETEST:~ # zfs list -t all
NAMEUSED  AVAIL  REFER  MOUNTPOINT
sys1.55G  18.0G31K  none
sys/ROOT535M  18.0G31K  none
sys/ROOT/RELENG_9_2 535M  18.0G   251M  /
sys/ROOT/RELENG_9_2/tmp  36K  18.0G36K  /tmp
sys/ROOT/RELENG_9_2/usr 247M  18.0G   247M  /usr
sys/ROOT/RELENG_9_2/usr/obj  31K  18.0G31K  /usr/obj
sys/ROOT/RELENG_9_2/usr/ports31K  18.0G31K  /usr/ports
sys/ROOT/RELENG_9_2/usr/src  31K  18.0G31K  /usr/src
sys/ROOT/RELENG_9_2/var35.8M  18.0G  35.8M  /var
sys/swap   1.03G  19.0G16K  -
root@BETEST:~ # beadm list
BE Active Mountpoint  Space Created
RELENG_9_2 NR /  533.9M 2014-01-13 12:38
root@BETEST:~ # beadm create test
Created successfully
root@BETEST:~ # zfs list -t all
NAMEUSED  AVAIL  REFER  
MOUNTPOINT
sys1.55G  18.0G31K  none
sys/ROOT535M  18.0G31K  none
sys/ROOT/RELENG_9_2 535M  18.0G   251M  /
sys/ROOT/RELENG_9_2@2014-02-19-17:03:490  -   251M  -
sys/ROOT/RELENG_9_2/tmp  36K  18.0G36K  /tmp
sys/ROOT/RELENG_9_2/tmp@2014-02-19-17:03:490  -36K  -
sys/ROOT/RELENG_9_2/usr 247M  18.0G   247M  /usr
sys/ROOT/RELENG_9_2/usr@2014-02-19-17:03:490  -   247M  -
sys/ROOT/RELENG_9_2/usr/obj  31K  18.0G31K  /usr/obj
sys/ROOT/RELENG_9_2/usr/obj@2014-02-19-17:03:490  -31K  -
sys/ROOT/RELENG_9_2/usr/ports31K  18.0G31K  
/usr/ports
sys/ROOT/RELENG_9_2/usr/ports@2014-02-19-17:03:49  0  -31K  -
sys/ROOT/RELENG_9_2/usr/src  31K  18.0G31K  /usr/src
sys/ROOT/RELENG_9_2/usr/src@2014-02-19-17:03:490  -31K  -
sys/ROOT/RELENG_9_2/var35.8M  18.0G  35.8M  /var
sys/ROOT/RELENG_9_2/var@2014-02-19-17:03:490  -  35.8M  -
sys/ROOT/test 7K  18.0G   251M  /
sys/ROOT/test/tmp 1K  18.0G36K  /tmp
sys/ROOT/test/usr 4K  18.0G   247M  /usr
sys/ROOT/test/usr/obj 1K  18.0G31K  /usr/obj
sys/ROOT/test/usr/ports   1K  18.0G31K  
/usr/ports
sys/ROOT/test/usr/src 1K  18.0G31K  /usr/src
sys/ROOT/test/var 1K  18.0G  35.8M  /var
sys/swap   1

Re: Issues with postmaster after freebsd-update

2014-02-19 Thread LuKreme 
On 13 Feb 2014, at 22:46 , Kevin Oberman  wrote:
> pkg_libchk -o | grep icu | cut -d: -f1 | sort | uniq > ~/reinstall-ports
> portmaster -D `cat ~/reinstall-ports`
> 
> When all of the ports reported have been re-installed:
> rm ~/reinstall-ports
> pkg_libchk -o

Thanks, I will give that a try if this continues to fail. I did remove python 
2.6 completely, and that seems to have skipped past this problem for now.

Of course, there's another problem.

I'm having to do this remote and something in the postmaster -af seems to have 
made it impossible for me to ssh in via key-exchange and password ssh is 
disabled, so I need to drive to the server and fix that.

Yay! :)

-- 
I always take life with a grain of salt, plus a slice of lime and a
shot of tequila.

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

dns/djbdns [do-package] Error code 1

2014-02-19 Thread Chad J. Milios 
there seems to be a timing issue. can anyone else please confirm this 
problem is happening? I haven't gone ahead and tried any non-default 
values of vfs.timestamp_precision.


make package
fails 26/30 times

make && sleep 1 && make package
succeeds 50/50 times

Thanks in advance.

here is the full output of a failed run:

===>  Found saved configuration for djbdns-1.05_14
===> Fetching all distfiles required by djbdns-1.05_17,1 for building
===>  Extracting for djbdns-1.05_17,1
=> SHA256 Checksum OK for djbdns-1.05.tar.gz.
=> SHA256 Checksum OK for djbdns-1.05-man-20031023.tar.gz.
===>  Patching for djbdns-1.05_17,1
===>  Applying FreeBSD patches for djbdns-1.05_17,1
===>  Configuring for djbdns-1.05_17,1
===>  Building for djbdns-1.05_17,1
cat warn-auto.sh dnstracesort.sh  | sed s}HOME}"`head -1 conf-home`"}g  
> dnstracesort

cat warn-auto.sh rts.sh  | sed s}HOME}"`head -1 conf-home`"}g  > rts
( cat warn-auto.sh;  echo 'main="$1"; shift';  echo exec "`head -1 
conf-ld`"  '-o "$main" "$main".o ${1+"$@"}'  ) > load
( cat warn-auto.sh;  echo exec "`head -1 conf-cc`" '-c ${1+"$@"}'  ) > 
compile

chmod 755 dnstracesort
chmod 755 compile
chmod 755 load
chmod 755 rts
( cat warn-auto.sh;  echo CC=\'`head -1 conf-cc`\';  echo LD=\'`head -1 
conf-ld`\';  cat find-systype.sh;  ) | sh > systype

cat warn-auto.sh choose.sh  | sed s}HOME}"`head -1 conf-home`"}g > choose
./compile alloc.c
./compile alloc_re.c
chmod 755 choose
./compile auto-str.c
auto-str.c:8: warning: conflicting types for built-in function 'puts'
./compile axfrdns-conf.c
./compile buffer.c
./compile buffer_1.c
./compile buffer_2.c
./compile buffer_copy.c
./compile buffer_get.c
./compile buffer_put.c
./compile buffer_read.c
./compile buffer_write.c
./compile byte_chr.c
./compile byte_copy.c
./compile byte_cr.c
./compile byte_diff.c
./compile byte_zero.c
./compile case_diffb.c
./compile case_diffs.c
./compile case_lowerb.c
./compile chkshsgr.c
./compile droproot.c
./compile env.c
./compile error.c
./compile error_str.c
./compile fmt_ulong.c
./compile generic-conf.c
./compile getln.c
./compile getln2.c
./compile hier.c
./compile install.c
./compile instcheck.c
./compile ip4_fmt.c
./compile ip4_scan.c
./compile ndelay_off.c
./compile ndelay_on.c
./compile okclient.c
./compile open_read.c
./compile open_trunc.c
./compile openreadclose.c
./compile pickdns-conf.c
./compile qlog.c
./compile rbldns-conf.c
./compile readclose.c
./compile scan_ulong.c
./compile seek_set.c
./compile sgetopt.c
./compile socket_accept.c
./compile socket_bind.c
./compile socket_conn.c
./compile socket_listen.c
./compile socket_recv.c
./compile socket_send.c
./compile socket_tcp.c
./compile socket_udp.c
./compile str_chr.c
./compile str_diff.c
./compile str_len.c
./compile str_rchr.c
./compile str_start.c
./compile stralloc_cat.c
./compile stralloc_catb.c
./compile stralloc_cats.c
./compile stralloc_copy.c
./compile stralloc_eady.c
./compile stralloc_num.c
./compile stralloc_opyb.c
./compile stralloc_opys.c
./compile stralloc_pend.c
./compile strerr_die.c
./compile strerr_sys.c
./compile subgetopt.c
./compile tinydns-conf.c
./compile uint16_pack.c
./compile uint16_unpack.c
./compile utime.c
./compile walldns-conf.c
( ( ./compile trylsock.c &&  ./load trylsock -lsocket -lnsl ) >/dev/null 
2>&1  && echo -lsocket -lnsl || exit 0 ) > socket.lib
( ( ./compile tryulong32.c && ./load tryulong32 && ./tryulong32 ) 
>/dev/null 2>&1  && cat uint32.h2 || cat uint32.h1 ) > uint32.h

./choose c trydrent direntry.h1 direntry.h2 > direntry.h
rm -f trylsock.o trylsock
./choose clr trypoll iopause.h1 iopause.h2 > iopause.h
./choose c trysysel select.h1 select.h2 > select.h
./choose clr tryulong64 uint64.h1 uint64.h2 > uint64.h
rm -f tryulong32.o tryulong32
( case "`cat systype`" in  sunos-5.*) cat hasdevtcp.h2 ;;  *) cat 
hasdevtcp.h1 ;;  esac ) > hasdevtcp.h
( cat warn-auto.sh;  echo 'main="$1"; shift';  echo 'rm -f "$main"';  
echo 'ar cr "$main" ${1+"$@"}';  case "`cat systype`" in sunos-5.*) ;;  
unix_sv*) ;;  irix64-*) ;;  irix-*) ;;  dgux-*) ;; hp-ux-*) ;;  sco*) 
;;  *) echo 'ranlib "$main"' ;;  esac  ) > makelib

./load chkshsgr
chmod 755 makelib
./compile cdb.c
./compile cdb_hash.c
./compile cdb_make.c
./compile rbldns-data.c
./compile uint32_pack.c
./compile uint32_unpack.c
./makelib alloc.a alloc.o alloc_re.o getln.o getln2.o stralloc_cat.o 
stralloc_catb.o stralloc_cats.o  stralloc_copy.o stralloc_eady.o 
stralloc_num.o  stralloc_opyb.o stralloc_opys.o stralloc_pend.o
./makelib buffer.a buffer.o buffer_1.o buffer_2.o  buffer_copy.o 
buffer_get.o buffer_put.o strerr_die.o  strerr_sys.o

./makelib env.a env.o
./makelib getopt.a sgetopt.o subgetopt.o
./makelib unix.a buffer_read.o buffer_write.o error.o  error_str.o 
ndelay_off.o ndelay_on.o open_read.o  open_trunc.o openreadclose.o 
readclose.o seek_set.o  socket_accept.o socket_bind.o socket_conn.o 
socket_listen.o  socket_recv.o socket_send.o socket_tcp.o socket_udp.o

./chkshsgr || ( cat warn-shsgr; exit 1 )
./choose clr tryshsgr hass

Re: dns/djbdns [do-package] Error code 1

2014-02-19 Thread David Thiel 
Interesting, I can't seem to replicate it here. It doesn't seem like
MAKE_JOBS_UNSAFE would apply, but perhaps try that?

On 02/19, Chad J. Milios wrote:
> there seems to be a timing issue. can anyone else please confirm this 
> problem is happening? I haven't gone ahead and tried any non-default 
> values of vfs.timestamp_precision.
> 
> make package
> fails 26/30 times
> 
> make && sleep 1 && make package
> succeeds 50/50 times
> 
> Thanks in advance.
> 
> here is the full output of a failed run:
> 
> ===>  Found saved configuration for djbdns-1.05_14
> ===> Fetching all distfiles required by djbdns-1.05_17,1 for building
> ===>  Extracting for djbdns-1.05_17,1
> => SHA256 Checksum OK for djbdns-1.05.tar.gz.
> => SHA256 Checksum OK for djbdns-1.05-man-20031023.tar.gz.
> ===>  Patching for djbdns-1.05_17,1
> ===>  Applying FreeBSD patches for djbdns-1.05_17,1
> ===>  Configuring for djbdns-1.05_17,1
> ===>  Building for djbdns-1.05_17,1
> cat warn-auto.sh dnstracesort.sh  | sed s}HOME}"`head -1 conf-home`"}g  
>  > dnstracesort
> cat warn-auto.sh rts.sh  | sed s}HOME}"`head -1 conf-home`"}g  > rts
> ( cat warn-auto.sh;  echo 'main="$1"; shift';  echo exec "`head -1 
> conf-ld`"  '-o "$main" "$main".o ${1+"$@"}'  ) > load
> ( cat warn-auto.sh;  echo exec "`head -1 conf-cc`" '-c ${1+"$@"}'  ) > 
> compile
> chmod 755 dnstracesort
> chmod 755 compile
> chmod 755 load
> chmod 755 rts
> ( cat warn-auto.sh;  echo CC=\'`head -1 conf-cc`\';  echo LD=\'`head -1 
> conf-ld`\';  cat find-systype.sh;  ) | sh > systype
> cat warn-auto.sh choose.sh  | sed s}HOME}"`head -1 conf-home`"}g > choose
> ./compile alloc.c
> ./compile alloc_re.c
> chmod 755 choose
> ./compile auto-str.c
> auto-str.c:8: warning: conflicting types for built-in function 'puts'
> ./compile axfrdns-conf.c
> ./compile buffer.c
> ./compile buffer_1.c
> ./compile buffer_2.c
> ./compile buffer_copy.c
> ./compile buffer_get.c
> ./compile buffer_put.c
> ./compile buffer_read.c
> ./compile buffer_write.c
> ./compile byte_chr.c
> ./compile byte_copy.c
> ./compile byte_cr.c
> ./compile byte_diff.c
> ./compile byte_zero.c
> ./compile case_diffb.c
> ./compile case_diffs.c
> ./compile case_lowerb.c
> ./compile chkshsgr.c
> ./compile droproot.c
> ./compile env.c
> ./compile error.c
> ./compile error_str.c
> ./compile fmt_ulong.c
> ./compile generic-conf.c
> ./compile getln.c
> ./compile getln2.c
> ./compile hier.c
> ./compile install.c
> ./compile instcheck.c
> ./compile ip4_fmt.c
> ./compile ip4_scan.c
> ./compile ndelay_off.c
> ./compile ndelay_on.c
> ./compile okclient.c
> ./compile open_read.c
> ./compile open_trunc.c
> ./compile openreadclose.c
> ./compile pickdns-conf.c
> ./compile qlog.c
> ./compile rbldns-conf.c
> ./compile readclose.c
> ./compile scan_ulong.c
> ./compile seek_set.c
> ./compile sgetopt.c
> ./compile socket_accept.c
> ./compile socket_bind.c
> ./compile socket_conn.c
> ./compile socket_listen.c
> ./compile socket_recv.c
> ./compile socket_send.c
> ./compile socket_tcp.c
> ./compile socket_udp.c
> ./compile str_chr.c
> ./compile str_diff.c
> ./compile str_len.c
> ./compile str_rchr.c
> ./compile str_start.c
> ./compile stralloc_cat.c
> ./compile stralloc_catb.c
> ./compile stralloc_cats.c
> ./compile stralloc_copy.c
> ./compile stralloc_eady.c
> ./compile stralloc_num.c
> ./compile stralloc_opyb.c
> ./compile stralloc_opys.c
> ./compile stralloc_pend.c
> ./compile strerr_die.c
> ./compile strerr_sys.c
> ./compile subgetopt.c
> ./compile tinydns-conf.c
> ./compile uint16_pack.c
> ./compile uint16_unpack.c
> ./compile utime.c
> ./compile walldns-conf.c
> ( ( ./compile trylsock.c &&  ./load trylsock -lsocket -lnsl ) >/dev/null 
> 2>&1  && echo -lsocket -lnsl || exit 0 ) > socket.lib
> ( ( ./compile tryulong32.c && ./load tryulong32 && ./tryulong32 ) 
>  >/dev/null 2>&1  && cat uint32.h2 || cat uint32.h1 ) > uint32.h
> ./choose c trydrent direntry.h1 direntry.h2 > direntry.h
> rm -f trylsock.o trylsock
> ./choose clr trypoll iopause.h1 iopause.h2 > iopause.h
> ./choose c trysysel select.h1 select.h2 > select.h
> ./choose clr tryulong64 uint64.h1 uint64.h2 > uint64.h
> rm -f tryulong32.o tryulong32
> ( case "`cat systype`" in  sunos-5.*) cat hasdevtcp.h2 ;;  *) cat 
> hasdevtcp.h1 ;;  esac ) > hasdevtcp.h
> ( cat warn-auto.sh;  echo 'main="$1"; shift';  echo 'rm -f "$main"';  
> echo 'ar cr "$main" ${1+"$@"}';  case "`cat systype`" in sunos-5.*) ;;  
> unix_sv*) ;;  irix64-*) ;;  irix-*) ;;  dgux-*) ;; hp-ux-*) ;;  sco*) 
> ;;  *) echo 'ranlib "$main"' ;;  esac  ) > makelib
> ./load chkshsgr
> chmod 755 makelib
> ./compile cdb.c
> ./compile cdb_hash.c
> ./compile cdb_make.c
> ./compile rbldns-data.c
> ./compile uint32_pack.c
> ./compile uint32_unpack.c
> ./makelib alloc.a alloc.o alloc_re.o getln.o getln2.o stralloc_cat.o 
> stralloc_catb.o stralloc_cats.o  stralloc_copy.o stralloc_eady.o 
> stralloc_num.o  stralloc_opyb.o stralloc_opys.o stralloc_pend.o
> ./makelib buffer.a buffer.o buffer_1.o buffer_2.o  buffer_copy.o 
> buffer_get.o buffer_p

Re: dns/djbdns [do-package] Error code 1

2014-02-19 Thread Chad J. Milios 
Oh yeah, I probably should have mentioned I'm on 9.2-RELEASE/amd64 with 
all ZFS file systems (except tmpfs /tmp). I'll give that a shot and 
report back, usually woulda been my first stab at it but i too had a 
feeling that just didnt seem to be applicable in this case. I'll have to 
try it out tonight, that box is close to pegged most of the day, I was 
doing the experimenting at 3:30 am this morning.


On 2/19/2014 1:50 PM, David Thiel wrote:

Interesting, I can't seem to replicate it here. It doesn't seem like
MAKE_JOBS_UNSAFE would apply, but perhaps try that?

On 02/19, Chad J. Milios wrote:

there seems to be a timing issue. can anyone else please confirm this
problem is happening? I haven't gone ahead and tried any non-default
values of vfs.timestamp_precision.

make package
fails 26/30 times

make && sleep 1 && make package
succeeds 50/50 times

Thanks in advance.


___
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] r345133: 4x leftovers

2014-02-19 Thread Ports-QAT 
Disable gnome-panel 2.x support. It will go away in the GNOME 3 import.
-

  Build ID:  20140219190800-32433
  Job owner: k...@freebsd.org
  Buildtime: 6 minutes
  Enddate:   Wed, 19 Feb 2014 19:14:28 GMT

  Revision:  r345133
  Repository:
https://svnweb.freebsd.org/ports?view=revision&revision=345133

-

Port:net/tsclient 0.150_10

  Buildgroup: 8.4-QAT/amd64
  Buildstatus:   LEFTOVERS
  Log: 
https://qat.redports.org//~k...@freebsd.org/20140219190800-32433-281420/tsclient-0.150_10.log

  Buildgroup: 8.4-QAT/i386
  Buildstatus:   LEFTOVERS
  Log: 
https://qat.redports.org//~k...@freebsd.org/20140219190800-32433-281421/tsclient-0.150_10.log

  Buildgroup: 9.2-QAT/amd64
  Buildstatus:   LEFTOVERS
  Log: 
https://qat.redports.org//~k...@freebsd.org/20140219190800-32433-281422/tsclient-0.150_10.log

  Buildgroup: 9.2-QAT/i386
  Buildstatus:   LEFTOVERS
  Log: 
https://qat.redports.org//~k...@freebsd.org/20140219190800-32433-281423/tsclient-0.150_10.log


--
Buildarchive URL: 
redports 
___
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: FreeBSD Port: strongswan-5.1.1_1

2014-02-19 Thread Clemens Schrimpe 
Hello Dewayne -

>> 21[KNL] adding PF_ROUTE route failed: Invalid argument
>> 21[KNL] installing route failed: 192.68.1.1/32 via (null) src %any dev vtnet1
> 
> Clemens,
> I only use FreeBSD 9.2Stable and Strongswan 5.1.1 performs nicely. 
> After setting knl=4 in charon debug, I received this:
> 
> # grep -i route /var/log/auth.log |tail -n1
> Feb 20 06:17:24 admin2 charon: 11[KNL] installing route: 10.130.30.17/32
> via 172.16.200.6 src 10.16.200.47 dev vga1
> 
> which seems to be what you're after.

Yep, this is exactly what I had expected - instead, I get:

21[KNL] adding PF_ROUTE route failed: Invalid argument
21[KNL] installing route failed: 192.68.1.1/32 via (null) src %any dev vtnet1

where the "(null)" and "%any" parts seem very odd to me!


> So the issue doesn't appear to reside with strongswan?

Ok. Maybe the PF_ROUTE interface changed in FreeBSD 10 - let me look into 
that...


> There are two tricks with using enc0 - firstly it must be enabled
> (ifconfig enc0 up)

Darn! I forgot to "re-up" it after the last reboot. Thanks for reminding me!
(I had used it with Raccoon a while ago but had rebooted since ...)


> and there are some tricks to getting it to reveal
> exactly what you're after, the "man 4 enc" is quite helpful.

Yep, those I know.

Thanks -

Clemens




smime.p7s
Description: S/MIME cryptographic signature

RE: [patch] sysutils/beadm

2014-02-19 Thread vermaden 
Hi,

I will try to test that patch then, I will reply when I'm done with info about 
issues or info about commit ;)

Regards,
vermaden

Od: "Andrew Hotlab" 
Do: "Bryan Drewery" ; 
Wysłane: 17:18 Środa 2014-02-19
Temat: RE: [patch] sysutils/beadm

> 
> > Date: Wed, 19 Feb 2014 07:27:45 -0600
> > From: bdrew...@freebsd.org
> > To: andrew.hot...@hotmail.com
> > CC: po...@freebsd.org; verma...@interia.pl
> > Subject: Re: [patch] sysutils/beadm
> >
> > On 2/13/2014 4:19 PM, Andrew Hotlab wrote:
> >> First of all, thank you very much for the good work with this port. I'm 
> >> sure it's changing the life of a lot FreeBSD system administrators!
> >>
> >> In my setup I have the following layout (several datasets for /usr, /var, 
> >> etc.):
> >>
> >> NAME USED AVAIL REFER MOUNTPOINT
> >> sys 1.55G 18.0G 31K none
> >> sys/ROOT 532M 18.0G 31K none
> >> sys/ROOT/default 114K 18.0G 250M /
> >> sys/ROOT/default/tmp 22K 18.0G 38K /tmp
> >> sys/ROOT/default/usr 1K 18.0G 245M /usr
> >> sys/ROOT/default/var 48.5K 18.0G 36.4M /var
> >> sys/swap 1.03G 19.0G 16K -
> >>
> >> At this moment the utility does not seems to be able to manage this 
> >> scheme, since it sets the mountpoint property as "legacy" for all datasets 
> >> under the root, thus preventing to automatically mount any subdirectory at 
> >> boot.
> >> I've tested this simple solution (to let do the job to the canmount 
> >> property), and it seems to solve the problem without affecting the 
> >> behavior when all system folders are located under a single root dataset 
> >> (please see the patch below). I'd be glad if you'll include it in the next 
> >> port revision.
> >>
> >
> > ACK on this. CC'ing upstream maintainer too.
> >
> > I run the same setup but I specifically set /usr /var and /tmp mntpoints
> > to /usr,/var/,/tmp to avoid this issue. I am not sure if mntpoint=/ is
> > proper. I recall there being an issue with it. I would much prefer your
> > patch though if it is safe.
> >
> > Does beadm mount still work with this to mount a new BE into /tmp?
> >
> > Ie,
> >
> > beadm create newbe
> > beadm mount newbe
> >
> > Does it go and remount / or only touch /tmp?
> >
> 
> It seems to behave correctly, as you can see in the attached transcript.
> 
> > How about activating? Does it blow away / right away or wait until reboot?
> 
> Since beadm changes only the "canmount" ZFS property to set the active 
> environment for the next reboot, there is no implications for the running 
> environment.
> 
> 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: GSSAPI and Heimdal in Base

2014-02-19 Thread Dewayne Geraghty 

On 20/02/2014 12:29 AM, Bryan Drewery wrote:
> On 2/17/2014 5:23 PM, Robert Simmons wrote:
>> Actually both port and base are 1.5.2. Base was updated in Apr 2012:
>> http://svnweb.freebsd.org/base?view=revision&revision=234027
>>
>> Both 9.x and 10.0 have Heimdal 1.5.2, same version in ports.
>>
>> The Heimdal project's current stable version is actually 1.5.3. They
>> have forgotten to update their main website, but the Git repository
>> speaks the truth:
>> https://github.com/heimdal/heimdal/blob/master/NEWS
>>
>> Also, they are pushing out 1.6 release candidates at the moment, so I
>> think 1.6 should arrive shortly.
>>
>> I will give the project a poke and see if they can update their
>> website, but security/openssh-portable should build fine against
>> heimdal base or the  heimdal port since they are identical.
>
> I will take another look, however I could not get it to build with the
> base heimdal so I marked it broken.
>
>> On Mon, Feb 17, 2014 at 7:43 AM, Dewayne Geraghty
>>  wrote:
>>> Robert,
>>> There's a couple of versions different.  Heimdal from ports is 1.5.2.
>>> I'm writing personally because I don't build any systems with the
>>> heimdal in base, but I recall it being around 1.0.1 on 9.X.
>>>
>>> As an aside I recall the openssh developer mentioning somewhere that
>>> gssapi wasn't supported in openssh 6.5, but if it builds for you then
>>> you're probably running an earlier version of the ports system?  It's
>>> also helpful to let folks know what FreeBSD version you're discussing ;)
>>>
>>> Cheers, Dewayne
>>>
>>> On 17/02/2014 5:14 PM, Robert Simmons wrote:
 When building openssh-portable, and enabling kerb_gssapi, but using
 the heimdal that is in base, it gives the error:
 KERB_GSSAPI Requires either MIT or HEMIDAL, does not build with base
 Heimdal currently

 What is the difference between base and the port of Heimdal?
 ___
 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@freebsd.org mailing list
>> http://lists.freebsd.org/mailman/listinfo/freebsd-ports
>> To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org"
>>
>
Bryan,
The base heimdal in 9.x is 1.1.0.   As suggested to me by John Marshall,
use:
svn cat svn://svn.freebsd.org/base/stable/9/kerberos5/include/version.h
| grep heimdal_version
svn cat svn://svn.freebsd.org/base/stable/10/kerberos5/include/version.h
| grep heimdal_version
svn cat svn://svn.freebsd.org/base/head/kerberos5/include/version.h |
grep heimdal_version

while head and 10.x use heimdal 1.5.2

Thanks for looking after openssh, I particularly appreciate the new key
storage mechanism (bcrypt KDF a GREAT improvement for keys at rest!). 
Unfortunately I don't use gssapi with ssh, though it heimdal 1.5.2 works
well with other ports.

Dewayne.
___
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: FreeBSD Port: strongswan-5.1.1_1

2014-02-19 Thread Dewayne Geraghty 

On 19/02/2014 2:31 AM, Clemens Schrimpe wrote:
> On 18.02.2014, at 16:12, Francois ten Krooden  wrote:
>
>> I will have a look on my test setup with FreeBSD to see if I can get the 
>> same error.
> Thank you. Watch for messages re: PF_ROUTE failed, like these:
>
> 21[KNL] adding PF_ROUTE route failed: Invalid argument
> 21[KNL] installing route failed: 192.68.1.1/32 via (null) src %any dev vtnet1
>
>
>> As far as I know there wasn’t any changes that would cause this issue.
> My suspicion is, that the PF_ROUTE interfaces vary between Linux, OpenBSD and 
> FreeBSD - and nobody really "ported" the code. Again: This is just a rough 
> suspicion - I need to familiarize myself with the respective interfaces 
> within Linux / OpenBSD.
>
>
>>  Just a question, did you recompile the standard FreeBSD kernel to include 
>> the support for IPsec, since the default kernel does not include the IPsec 
>> support.
> Of course. And Raccoon works fine - it just sucks in so many other ways, that 
> I'd rather use Strongswan :-)
>
> Thanks -
>
>   Clemens
>

Clemens,
I only use FreeBSD 9.2Stable and Strongswan 5.1.1 performs nicely. 
After setting knl=4 in charon debug, I received this:

# grep -i route /var/log/auth.log |tail -n1
Feb 20 06:17:24 admin2 charon: 11[KNL] installing route: 10.130.30.17/32
via 172.16.200.6 src 10.16.200.47 dev vga1

which seems to be what you're after.  So the issue doesn't appear to
reside with strongswan?

FYI: Downloaded and build on: FreeBSD 9.2-STABLE #0: Sun Jan 19 19:07:34
EST 2014  

There are two tricks with using enc0 - firstly it must be enabled
(ifconfig enc0 up) and there are some tricks to getting it to reveal
exactly what you're after, the "man 4 enc" is quite helpful.
Regards, Dewayne.
___
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"

[CFT] finance/grisbi: upgrade to 0.9.99

2014-02-19 Thread Thierry Thomas 
Hello,

This is a call for test: 0.9.99 is an unstable version of Grisbi, surely
the latest before 1.0.

There is no need for a finance/grisbi-devel, and I'm just pushing the
patch at .

I won't commit it - just waiting for the next stable version - but
please test it and report any problem, to me or upstream.

Warning! Back-up your .gsb file, just in case!

Thanks.
-- 
Th. Thomas.


pgpp0J7gwY2Vj.pgp
Description: PGP signature

VirtualBox & vim no longer building

2014-02-19 Thread Bryce Edwards 
Here's the build logs with details:

https://dl.dropboxusercontent.com/u/141097/virtualbox-ose-4.3.6.log

https://dl.dropboxusercontent.com/u/141097/vim-7.4.182.log
___
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"

textproc/docbook-utils fails to build

2014-02-19 Thread Kevin Oberman 
Now that everything has been committed, most of the docbook stuff builds,
but docbook-utils fails with what appears to be a typo with an errant \n in
a file name:
I get a huge number of near identical errors similar to these:
jade:/usr/local/share/xml/docbook/catalog:6:8:E: cannot open
"/usr/local/share/xml/docbook/4.5/docbook.cat
CATALOG " (No such file or directory)
jade:/usr/local/share/sgml/docbook/catalog:10:55:E: end of entity in literal
jade:/usr/local/share/sgml/docbook/catalog:2:8:E: cannot open
"/usr/local/share/sgml/docbook/2.4.1/docbook.cat
CATALOG " (No such file or directory)
jade:/usr/local/share/sgml/docbook/catalog:6:8:E: cannot open
"/usr/local/share/sgml/docbook/4.1/docbook.cat
CATALOG " (No such file or directory)
jade:/usr/local/share/sgml/docbook/catalog:10:8:E: cannot open
"/usr/local/share/sgml/docbook/4.5/docbook.cat
" (No such file or directory)

I can confirm that all of the cat files are present, but I suspect that the
attempt to open them includes a newline at the end of the filename that is
breaking the open attempt. Of course, it may just be an error in the
message formatting, but, in any case, I can't build the port on 9.2 or 10.0.

Any suggestions?
-- 
R. Kevin Oberman, Network Engineer, Retired
E-mail: rkober...@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: textproc/docbook-utils fails to build

2014-02-19 Thread Matthias Andree 
Am 20.02.2014 00:12, schrieb Kevin Oberman:
> Now that everything has been committed, most of the docbook stuff builds,
> but docbook-utils fails with what appears to be a typo with an errant \n in
> a file name:
> I get a huge number of near identical errors similar to these:
> jade:/usr/local/share/xml/docbook/catalog:6:8:E: cannot open
> "/usr/local/share/xml/docbook/4.5/docbook.cat
> CATALOG " (No such file or directory)
> jade:/usr/local/share/sgml/docbook/catalog:10:55:E: end of entity in literal
> jade:/usr/local/share/sgml/docbook/catalog:2:8:E: cannot open
> "/usr/local/share/sgml/docbook/2.4.1/docbook.cat
> CATALOG " (No such file or directory)
> jade:/usr/local/share/sgml/docbook/catalog:6:8:E: cannot open
> "/usr/local/share/sgml/docbook/4.1/docbook.cat
> CATALOG " (No such file or directory)
> jade:/usr/local/share/sgml/docbook/catalog:10:8:E: cannot open
> "/usr/local/share/sgml/docbook/4.5/docbook.cat
> " (No such file or directory)
> 
> I can confirm that all of the cat files are present, but I suspect that the
> attempt to open them includes a newline at the end of the filename that is
> breaking the open attempt. Of course, it may just be an error in the
> message formatting, but, in any case, I can't build the port on 9.2 or 10.0.
> 
> Any suggestions?
> 

Upgrade the ports tree and retry, I fixed this a few minutes ago.
___
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"

the docbook updates fisco continues...

2014-02-19 Thread Scott Bennett 
 The saga of the untested or inadequately test docbook updates of the last
___
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: textproc/docbook-utils fails to build

2014-02-19 Thread Kevin Oberman 
On Wed, Feb 19, 2014 at 3:14 PM, Matthias Andree wrote:

> Am 20.02.2014 00:12, schrieb Kevin Oberman:
> > Now that everything has been committed, most of the docbook stuff builds,
> > but docbook-utils fails with what appears to be a typo with an errant \n
> in
> > a file name:
> > I get a huge number of near identical errors similar to these:
> > jade:/usr/local/share/xml/docbook/catalog:6:8:E: cannot open
> > "/usr/local/share/xml/docbook/4.5/docbook.cat
> > CATALOG " (No such file or directory)
> > jade:/usr/local/share/sgml/docbook/catalog:10:55:E: end of entity in
> literal
> > jade:/usr/local/share/sgml/docbook/catalog:2:8:E: cannot open
> > "/usr/local/share/sgml/docbook/2.4.1/docbook.cat
> > CATALOG " (No such file or directory)
> > jade:/usr/local/share/sgml/docbook/catalog:6:8:E: cannot open
> > "/usr/local/share/sgml/docbook/4.1/docbook.cat
> > CATALOG " (No such file or directory)
> > jade:/usr/local/share/sgml/docbook/catalog:10:8:E: cannot open
> > "/usr/local/share/sgml/docbook/4.5/docbook.cat
> > " (No such file or directory)
> >
> > I can confirm that all of the cat files are present, but I suspect that
> the
> > attempt to open them includes a newline at the end of the filename that
> is
> > breaking the open attempt. Of course, it may just be an error in the
> > message formatting, but, in any case, I can't build the port on 9.2 or
> 10.0.
> >
> > Any suggestions?
> >
>
> Upgrade the ports tree and retry, I fixed this a few minutes ago.
>

All better now! Thanks!

-- 
R. Kevin Oberman, Network Engineer, Retired
E-mail: rkober...@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"

How do submit updates to ports?

2014-02-19 Thread Daniel Morante 

How do I send updates to ports that I created/maintain?



smime.p7s
Description: S/MIME Cryptographic Signature

Re: How do submit updates to ports?

2014-02-19 Thread A.J. 'Fonz' van Werven 
Daniel Morante wrote:

> How do I send updates to ports that I created/maintain?
 
Send a PR, either by using send-pr(1) or through the web interface at
http://www.freebsd.org/send-pr.html

If you are the maintainer, be sure to set the class to maintainer-update.

AvW

-- 
I'm not completely useless, I can be used as a bad example.


pgpYQhF9nU0UN.pgp
Description: PGP signature

Unable to build kfelibs (not docbook)

2014-02-19 Thread Kevin Oberman 
Well, I have gotten docbook updated. I now have five docbook ports and
docbook-utils builds correctly. But I still can't build kdelibs. It now
configures fine, but:
Scanning dependencies of target docbookl10nhelper
[  9%] Built target threadweaver
[  9%] Building CXX object
kdoctools/CMakeFiles/docbookl10nhelper.dir/docbookl10nhelper_automoc.o
Linking CXX executable ../bin/docbookl10nhelper
[  9%] Generating opcodes.h, opcodes.cpp, machine.cpp
 /usr/local/lib/compat/libstdc++.so.6: version GLIBCXX_3.4.11 required by
/usr/ports/x11/kdelibs4/work/.build/bin/icemaker not found
--- kjs/opcodes.h ---
*** [kjs/opcodes.h] Error code 1

make[4]: stopped in /usr/ports/x11/kdelibs4/work/.build
1 error

Any ideas? FreeBSD 10-Stable from last week. Only WITH_NEWXORG and WITH_KMS
in make.conf. I don't have any idea where GLIBCXX_3.4.11 would come from.
my libstdc++ is from compat9x.
-- 
R. Kevin Oberman, Network Engineer, Retired
E-mail: rkober...@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: Unable to build kfelibs (not docbook)

2014-02-19 Thread Scot Hetzel 
On Wed, Feb 19, 2014 at 9:45 PM, Kevin Oberman  wrote:
> Well, I have gotten docbook updated. I now have five docbook ports and
> docbook-utils builds correctly. But I still can't build kdelibs. It now
> configures fine, but:
> Scanning dependencies of target docbookl10nhelper
> [  9%] Built target threadweaver
> [  9%] Building CXX object
> kdoctools/CMakeFiles/docbookl10nhelper.dir/docbookl10nhelper_automoc.o
> Linking CXX executable ../bin/docbookl10nhelper
> [  9%] Generating opcodes.h, opcodes.cpp, machine.cpp
>  /usr/local/lib/compat/libstdc++.so.6: version GLIBCXX_3.4.11 required by
> /usr/ports/x11/kdelibs4/work/.build/bin/icemaker not found
> --- kjs/opcodes.h ---
> *** [kjs/opcodes.h] Error code 1
>
> make[4]: stopped in /usr/ports/x11/kdelibs4/work/.build
> 1 error
>
> Any ideas? FreeBSD 10-Stable from last week. Only WITH_NEWXORG and WITH_KMS
> in make.conf. I don't have any idea where GLIBCXX_3.4.11 would come from.
> my libstdc++ is from compat9x.

The problem most likely is caused by icemaker finding libstdc++.so.6
in /usr/local/lib/compat/.

Do you also have a libstdc++.so* in /usr/local/lib?

You might want to try removing /usr/local/lib/compat from your library
path, and then rebuild kdelibs4.


-- 
DISCLAIMER:

No electrons were maimed while sending this message. Only slightly bruised.
___
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"

docbook updates fiasco continues...

2014-02-19 Thread Scott Bennett 
 Wednesday's round of docbook updates broke all the docbook ports fixed
yesterday, plus other ports that depend upon docbook stuff.  On my system
the latter appear to include 

sysutils/polkit
graphics/colord
graphics/giflib
sysutils/policykit
devel/git

Most/all appear to be due to a file that was installed missing perhaps only
a single character.  Here's an example.

xmlto: 
/backups/s2A/portswork/usr/ports/devel/git/work/git-1.8.5.4/contrib/subtree/git-subtree.xml
 does not validate (status 3)
file:///usr/local/share/xml/catalog.ports:1: parser error : Start tag expected, 
'<' not found
PUBLIC "-//OASIS//DTD Entity Resolution XML Catalog V1.0//EN"
^
I/O error : Attempt to load network entity 
http://www.oasis-open.org/docbook/xml/4.5/docbookx.dtd
/backups/s2A/portswork/usr/ports/devel/git/work/git-1.8.5.4/contrib/subtree/git-subtree.xml:2:
 warning: failed to load external entity 
"http://www.oasis-open.org/docbook/xml/4.5/docbookx.dtd";
D DocBook XML V4.5//EN" "http://www.oasis-open.org/docbook/xml/4.5/docbookx.dtd";
   ^
I/O error : Attempt to load network entity 
http://www.oasis-open.org/docbook/xml/4.5/docbookx.dtd
warning: failed to load external entity 
"http://www.oasis-open.org/docbook/xml/4.5/docbookx.dtd";
validity error : Could not load the external subset 
"http://www.oasis-open.org/docbook/xml/4.5/docbookx.dtd";
Document 
/backups/s2A/portswork/usr/ports/devel/git/work/git-1.8.5.4/contrib/subtree/git-subtree.xml
 does not validate
gmake: *** [git-subtree.1] Error 13
*** [post-install] Error code 2

Stop in /usr/ports/devel/git.

 After the last couple of days, I have to wonder how the updates to the
docbook ports were tested.  Also, I note that the instructions in
/usr/ports/UPDATING said to delete the old packages, rather than to replace
them with "portmaster -o" or some other procedure that would update the
dependencies properly.


  Scott Bennett, Comm. ASMELG, CFIAG
**
* Internet:   bennett at sdf.org   *or*   bennett at freeshell.org   *
**
* "A well regulated and disciplined militia, is at all times a good  *
* objection to the introduction of that bane of all free governments *
* -- a standing army."   *
*-- Gov. John Hancock, New York Journal, 28 January 1790 *
**

___
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: Unable to build kfelibs (not docbook)

2014-02-19 Thread Kevin Oberman 
On Wed, Feb 19, 2014 at 8:54 PM, Scot Hetzel  wrote:

> On Wed, Feb 19, 2014 at 9:45 PM, Kevin Oberman 
> wrote:
> > Well, I have gotten docbook updated. I now have five docbook ports and
> > docbook-utils builds correctly. But I still can't build kdelibs. It now
> > configures fine, but:
> > Scanning dependencies of target docbookl10nhelper
> > [  9%] Built target threadweaver
> > [  9%] Building CXX object
> > kdoctools/CMakeFiles/docbookl10nhelper.dir/docbookl10nhelper_automoc.o
> > Linking CXX executable ../bin/docbookl10nhelper
> > [  9%] Generating opcodes.h, opcodes.cpp, machine.cpp
> >  /usr/local/lib/compat/libstdc++.so.6: version GLIBCXX_3.4.11 required by
> > /usr/ports/x11/kdelibs4/work/.build/bin/icemaker not found
> > --- kjs/opcodes.h ---
> > *** [kjs/opcodes.h] Error code 1
> >
> > make[4]: stopped in /usr/ports/x11/kdelibs4/work/.build
> > 1 error
> >
> > Any ideas? FreeBSD 10-Stable from last week. Only WITH_NEWXORG and
> WITH_KMS
> > in make.conf. I don't have any idea where GLIBCXX_3.4.11 would come from.
> > my libstdc++ is from compat9x.
>
> The problem most likely is caused by icemaker finding libstdc++.so.6
> in /usr/local/lib/compat/.
>
> Do you also have a libstdc++.so* in /usr/local/lib?
>
> You might want to try removing /usr/local/lib/compat from your library
> path, and then rebuild kdelibs4.
>
> Duh! I was staring right at it!

I re-built all ports after upgrading from 9.2 to 10.0-BETA and other things
linked to libs in compat9x including phonon, so I was doomed as long as
compat9x was present. I deleted all three ports dependent on compat9x,
deleted it  and re-built them. Now kdelibs gets further, but still fails,
segfaulting in: Generating index.cache.bz2.

I have three(?) core files in doc/kioslave/data, doc/kioslave/file, and
doc/kioslave/ftp, but I am not sure how I can use these files to debug. gdb
says that it does not recognize the format of the core file.

Any ideas on how to proceed?



-- 
R. Kevin Oberman, Network Engineer, Retired
E-mail: rkober...@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: How do submit updates to ports?

2014-02-19 Thread Fernando Apesteguía 
El 20/02/2014 02:28, "A.J. 'Fonz' van Werven" 
escribió:
>
> Daniel Morante wrote:
>
> > How do I send updates to ports that I created/maintain?
>
> Send a PR, either by using send-pr(1) or through the web interface at
> http://www.freebsd.org/send-pr.html
>
> If you are the maintainer, be sure to set the class to maintainer-update.
>

Also have a look at the porters handbook for good practices

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

> AvW
>
> --
> I'm not completely useless, I can be used as a bad example.
___
freebsd-ports@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-ports
To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org"

Re: What should be in scripts shebangs for python2?

2014-02-19 Thread Lev Serebryakov 
Hello, Marcus.
You wrote 19 февраля 2014 г., 19:55:00:


MvA> In short:
MvA> * Use ${PYTHON_CMD} to replace the shebang lines or references of the  
MvA> python command
  So, it is not possible to use "static" patch? It is pity :(

MvA> * Use the proper supported python version (yes for any, 2 or 3 for a  
MvA> branch, X.Y for a release)
MvA>for USE_PYTHON_BUILD
 I've hoped, that USE_PYTHON_BUILD=2 guarantee me, that here is
/usr/local/bin/python2 in system, but looks like it depends on something
else. On my system I get "lang/python2" dependency:

# make build-depends-list
/usr/ports/devel/gcc-arm-embedded
/usr/ports/devel/gmake
/usr/ports/lang/python2
/usr/ports/lang/python27
/usr/ports/ports-mgmt/pkg
#

 But port building cluster fails (it doesn't try to install python2 at all):

 ===>   libopencm3-0.0.20140213 depends on file: /usr/local/bin/python2.7 - not 
found
===>Verifying install for /usr/local/bin/python2.7 in 
/usr/ports/lang/python27
===>   Installing existing package /packages/All/python27-2.7.6_2.txz
Installing python27-2.7.6_2...Installing gettext-0.18.3.1... done
 done

Note that some of the standard modules are provided as separate
ports since they require extra dependencies:

bsddb   databases/py-bsddb
gdbmdatabases/py-gdbm
sqlite3 databases/py-sqlite3
tkinter x11-toolkits/py-tkinter

Install them as needed.

===>   Returning to build of libopencm3-0.0.20140213
===>   libopencm3-0.0.20140213 depends on executable: gmake - not found

===>  Building for libopencm3-0.0.20140213
  GENHDR  include/libopencm3/sam/3n/irq.json
env: python2: No such file or directory
gmake: *** [include/libopencm3/sam/3n/irq.json.genhdr] Error 127


-- 
// Black Lion AKA Lev Serebryakov 

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