Re: INSTALL_TARGET=install-strip runs into "permission denied"

2015-01-19 Thread Tijl Coosemans 
On Sun, 18 Jan 2015 23:13:56 +0100 (CET) Gerald Pfeifer  
wrote:
> On Sunday 2015-01-18 13:01, Tijl Coosemans wrote:
>>> Here is the build log:
>>> 
>>> install   -m 555 fixinc.sh 
>>> .../prefix/gcc5/libexec/gcc5/gcc/i386-portbld-freebsd10.1/5.0.0/install-tools/fixinc.sh
>>> install  -s  -m 555 fixincl 
>>> .../prefix/gcc5/libexec/gcc5/gcc/i386-portbld-freebsd10.1/5.0.0/install-tools/fixincl
>>> install   -m 555 mkheaders 
>>> .../prefix/gcc5/libexec/gcc5/gcc/i386-portbld-freebsd10.1/5.0.0/install-tools/mkheaders
>>> test -z 'strip' || strip 
>>> .../prefix/gcc5/libexec/gcc5/gcc/i386-portbld-freebsd10.1/5.0.0/install-tools/fixincl
>>> strip: unable to copy file 
>>> '.../prefix/gcc5/libexec/gcc5/gcc/i386-portbld-freebsd10.1/5.0.0/install-tools/fixincl';
>>>  reason: Permission denied
>>> Makefile:191: recipe for target 'install-strip' failed
>>> gmake[3]: *** [install-strip] Error 1
>> This strip command seems redundant.  Isn't fixincl already stripped by
>> the "install -s" command above?
> 
> Good point.
> 
>> What does this piece of the log look like outside the ports framework?
> 
> /usr/bin/install -c fixinc.sh 
> .../gcc-ref8-amd64/libexec/gcc/x86_64-unknown-freebsd8.4/5.0.0/install-tools/fixinc.sh
> /usr/bin/install -c fixincl 
> .../gcc-ref8-amd64/libexec/gcc/x86_64-unknown-freebsd8.4/5.0.0/install-tools/fixincl
> /usr/bin/install -c mkheaders 
> .../gcc-ref8-amd64/libexec/gcc/x86_64-unknown-freebsd8.4/5.0.0/install-tools/mkheaders
> test -z 'strip' || strip 
> .../gcc-ref8-amd64/libexec/gcc/x86_64-unknown-freebsd8.4/5.0.0/install-tools/fixincl
> gmake[2]: Leaving directory '.../OBJ-0118-1528/fixincludes'
> 
> (I also tried setting STRIP_CMD to true, alas that is not used by GCC.)

Try adding BINMODE=755 to the port Makefile or STRIP=true to CONFIGURE_ARGS
___
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

2015-01-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/lwjgl | 2.9.1   | 2.9.3
+-+


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"

Net-SNMP 5.7.3 with Perl support fails at configure stage

2015-01-19 Thread Sevan / Venture37 
Hi,
I posted this question to the net-snmp-users list but didn't hear any
response back, if you try to configure v5.7.3 with Perl support
enabled, it fails requesting that --enable-shared is specified, even
when it's specified.
Observed on FreeBSD/AMD64 10.1-RELEASE with Perl installed form via pkg.
My original post to the net-snmp-users list with perl -V output &
snippet from config.log
https://www.marc.info/?l=net-snmp-users&m=142082652512936&w=2


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

Re: Poudriere Timeout

2015-01-19 Thread Torsten Zuehlsdorff 

Hi,


Has anyone seen this before?

print/texlive-texmf texlive-texmf-20140525_4 package/timeout runaway_process


Yes, i have. I've solved this problem by moving the build-jails of 
poudriere to an memory disk. This make poudriere no longer io-bund and 
incredibly fast. And solve this issue ;)


Greetings,
Torsten

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

Fail to kill children

2015-01-19 Thread Michael Jung 

FreeBSD 10.1-RELEASE #0 r276896:
pkg 1.4.4 or pkg 1.4.6
poudriere 3.1.1 under 11.0-CURRENT r275419

On i386 only pkg complains with "Fail to kill 
children". I have checked some but not all packages

and they appear to be updated as expected so this
is a heads up.

I do not see this behaviour with pkg on amd64 clients. I see this 
behaviour on more than one i386 client.


Anything further I can provide?

--mikej


[root@jackson /usr/home/mikej]# pkg upgrade
Updating 0_local repository catalogue...
0_local repository is up-to-date.
All repositories are up-to-date.
Checking for upgrades (6 candidates): 100%
Processing candidates (6 candidates): 100%
The following 6 packages will be affected (of 0 checked):

Installed packages to be UPGRADED:
unzip: 6.0_2 -> 6.0_3
pciids: 20150105 -> 20150117
openssl: 1.0.1_17 -> 1.0.1_18
duo: 1.9.13 -> 1.9.13_1
ccache: 3.2.1 -> 3.2.1_1
bash: 4.3.30_1 -> 4.3.33

The process will require 1 KB more space.
4 MB to be downloaded.

Proceed with this action? [y/N]: y
Fetching unzip-6.0_3.txz: 100%  121 KB 123.9k/s00:01
Fetching pciids-20150117.txz: 100%  185 KB 189.4k/s00:01
Fetching openssl-1.0.1_18.txz: 100%2 MB 851.7k/s00:03
Fetching duo-1.9.13_1.txz: 100%   70 KB  71.2k/s00:01
Fetching ccache-3.2.1_1.txz: 100%   80 KB  81.8k/s00:01
Fetching bash-4.3.33.txz: 100%1 MB 594.3k/s00:02
Checking integrity... done (0 conflicting)
[1/6] Upgrading unzip from 6.0_2 to 6.0_3...
pkg: Fail to kill children
[1/6] Extracting unzip-6.0_3: 100%
pkg: Fail to kill children
[2/6] Upgrading pciids from 20150105 to 20150117...
pkg: Fail to kill children
[2/6] Extracting pciids-20150117: 100%
pkg: Fail to kill children
[3/6] Upgrading openssl from 1.0.1_17 to 1.0.1_18...
pkg: Fail to kill children
pkg: Fail to kill children
[3/6] Extracting openssl-1.0.1_18: 100%
pkg: Fail to kill children
[4/6] Upgrading duo from 1.9.13 to 1.9.13_1...
You may need to manually remove /usr/local/etc/login_duo.conf if it's no 
longer needed.

pkg: Fail to kill children
[4/6] Extracting duo-1.9.13_1: 100%
pkg: Fail to kill children
[5/6] Upgrading ccache from 3.2.1 to 3.2.1_1...
pkg: Fail to kill children
[5/6] Extracting ccache-3.2.1_1: 100%
Create compiler links...
create symlink for cc
create symlink for cc (world)
create symlink for c++
create symlink for c++ (world)
create symlink for CC
create symlink for CC (world)
create symlink for gcc
create symlink for gcc (world)
create symlink for g++
create symlink for g++ (world)
create symlink for gcc48
create symlink for gcc48 (world)
create symlink for g++48
create symlink for g++48 (world)
pkg: Fail to kill children
[6/6] Upgrading bash from 4.3.30_1 to 4.3.33...
pkg: Fail to kill children
[6/6] Extracting bash-4.3.33: 100%
pkg: Fail to kill children
Message for openssl-1.0.1_18:
 Copy /usr/local/openssl/openssl.cnf.sample to 
/usr/local/openssl/openssl.cnf

and edit it to fit your needs.
Message for duo-1.9.13_1:
 =
Configuration file /usr/local/etc/login_duo.conf was created.
You must edit it to add your Duo integration and secret keys.

If you are using the PAM module, a line similar to the following
should be added to your service(s) of choice in /etc/pam.d:
authrequired/usr/local/lib/security/pam_duo.so

Additionally, you must edit /usr/local/etc/pam_duo.conf

duo headers have been installed to /usr/local/include/duo
=
Message for ccache-3.2.1_1:
 NOTE:
Please read /usr/local/share/doc/ccache/ccache-howto-freebsd.txt for
information on using ccache with FreeBSD ports and src.
Message for bash-4.3.33:
 ==

bash requires fdescfs(5) mounted on /dev/fd

If you have not done it yet, please do the following:

mount -t fdescfs fdesc /dev/fd

To make it permanent, you need the following lines in /etc/fstab:

fdesc   /dev/fd fdescfs rw  0   0

==
[root@jackson /usr/home/mikej]#


So ccache for example did get upgraded.

[root@jackson /usr/home/mikej]# ccache -V
ccache version 3.2.1

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

Re: Net-SNMP 5.7.3 with Perl support fails at configure stage

2015-01-19 Thread Ryan Steinmetz 

Sevan,

I'm currently working on an update for the port to get it to 5.7.3.  In
the interim, you should install 5.7.2 from the ports tree:

To install the port: cd /usr/ports/net-mgmt/net-snmp/ && make install clean
To add the package: pkg install net-mgmt/net-snmp

-r

On (01/19/15 12:06), Sevan / Venture37 wrote:

Hi,
I posted this question to the net-snmp-users list but didn't hear any
response back, if you try to configure v5.7.3 with Perl support
enabled, it fails requesting that --enable-shared is specified, even
when it's specified.
Observed on FreeBSD/AMD64 10.1-RELEASE with Perl installed form via pkg.
My original post to the net-snmp-users list with perl -V output &
snippet from config.log
https://www.marc.info/?l=net-snmp-users&m=142082652512936&w=2


Sevan / Venture37


--
Ryan Steinmetz
PGP: 9079 51A3 34EF 0CD4 F228  EDC6 1EF8 BA6B D028 46D7
___
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: Fail to kill children

2015-01-19 Thread Ben Woods 
On face value, that is quite a shocking mailing list topic!


--
From: Benjamin Woods
woods...@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"

PKG - Fail to kill children

2015-01-19 Thread Michael Jung 

On 2015-01-19 09:20, Michael Jung wrote:

FreeBSD 10.1-RELEASE #0 r276896:
pkg 1.4.4 or pkg 1.4.6
poudriere 3.1.1 under 11.0-CURRENT r275419

On i386 only pkg complains with "Fail to kill children". I have
checked some but not all packages
and they appear to be updated as expected so this
is a heads up.

I do not see this behaviour with pkg on amd64 clients. I see this
behaviour on more than one i386 client.

Anything further I can provide?

--mikej


[root@jackson /usr/home/mikej]# pkg upgrade
Updating 0_local repository catalogue...
0_local repository is up-to-date.
All repositories are up-to-date.
Checking for upgrades (6 candidates): 100%
Processing candidates (6 candidates): 100%
The following 6 packages will be affected (of 0 checked):

Installed packages to be UPGRADED:
unzip: 6.0_2 -> 6.0_3
pciids: 20150105 -> 20150117
openssl: 1.0.1_17 -> 1.0.1_18
duo: 1.9.13 -> 1.9.13_1
ccache: 3.2.1 -> 3.2.1_1
bash: 4.3.30_1 -> 4.3.33

The process will require 1 KB more space.
4 MB to be downloaded.

Proceed with this action? [y/N]: y
Fetching unzip-6.0_3.txz: 100%  121 KB 123.9k/s00:01
Fetching pciids-20150117.txz: 100%  185 KB 189.4k/s00:01
Fetching openssl-1.0.1_18.txz: 100%2 MB 851.7k/s00:03
Fetching duo-1.9.13_1.txz: 100%   70 KB  71.2k/s00:01
Fetching ccache-3.2.1_1.txz: 100%   80 KB  81.8k/s00:01
Fetching bash-4.3.33.txz: 100%1 MB 594.3k/s00:02
Checking integrity... done (0 conflicting)
[1/6] Upgrading unzip from 6.0_2 to 6.0_3...
pkg: Fail to kill children
[1/6] Extracting unzip-6.0_3: 100%
pkg: Fail to kill children
[2/6] Upgrading pciids from 20150105 to 20150117...
pkg: Fail to kill children
[2/6] Extracting pciids-20150117: 100%
pkg: Fail to kill children
[3/6] Upgrading openssl from 1.0.1_17 to 1.0.1_18...
pkg: Fail to kill children
pkg: Fail to kill children
[3/6] Extracting openssl-1.0.1_18: 100%
pkg: Fail to kill children
[4/6] Upgrading duo from 1.9.13 to 1.9.13_1...
You may need to manually remove /usr/local/etc/login_duo.conf if it's
no longer needed.
pkg: Fail to kill children
[4/6] Extracting duo-1.9.13_1: 100%
pkg: Fail to kill children
[5/6] Upgrading ccache from 3.2.1 to 3.2.1_1...
pkg: Fail to kill children
[5/6] Extracting ccache-3.2.1_1: 100%
Create compiler links...
create symlink for cc
create symlink for cc (world)
create symlink for c++
create symlink for c++ (world)
create symlink for CC
create symlink for CC (world)
create symlink for gcc
create symlink for gcc (world)
create symlink for g++
create symlink for g++ (world)
create symlink for gcc48
create symlink for gcc48 (world)
create symlink for g++48
create symlink for g++48 (world)
pkg: Fail to kill children
[6/6] Upgrading bash from 4.3.30_1 to 4.3.33...
pkg: Fail to kill children
[6/6] Extracting bash-4.3.33: 100%
pkg: Fail to kill children
Message for openssl-1.0.1_18:
 Copy /usr/local/openssl/openssl.cnf.sample to 
/usr/local/openssl/openssl.cnf

and edit it to fit your needs.
Message for duo-1.9.13_1:
 =
Configuration file /usr/local/etc/login_duo.conf was created.
You must edit it to add your Duo integration and secret keys.

If you are using the PAM module, a line similar to the following
should be added to your service(s) of choice in /etc/pam.d:
authrequired/usr/local/lib/security/pam_duo.so

Additionally, you must edit /usr/local/etc/pam_duo.conf

duo headers have been installed to /usr/local/include/duo
=
Message for ccache-3.2.1_1:
 NOTE:
Please read /usr/local/share/doc/ccache/ccache-howto-freebsd.txt for
information on using ccache with FreeBSD ports and src.
Message for bash-4.3.33:
 ==

bash requires fdescfs(5) mounted on /dev/fd

If you have not done it yet, please do the following:

mount -t fdescfs fdesc /dev/fd

To make it permanent, you need the following lines in /etc/fstab:

fdesc   /dev/fd fdescfs rw  0   0

==
[root@jackson /usr/home/mikej]#


So ccache for example did get upgraded.

[root@jackson /usr/home/mikej]# ccache -V
ccache version 3.2.1

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


___
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: Net-SNMP 5.7.3 with Perl support fails at configure stage

2015-01-19 Thread Sevan / Venture37 
On 19 January 2015 at 14:33, Ryan Steinmetz  wrote:
> Sevan,
>
> I'm currently working on an update for the port to get it to 5.7.3.  In
> the interim, you should install 5.7.2 from the ports tree:
>
> To install the port: cd /usr/ports/net-mgmt/net-snmp/ && make install clean
> To add the package: pkg install net-mgmt/net-snmp
>
> -r
Hi Ryan,
Sure thing, for the sake of technical discussion, what's the cause of
the issue, autoconf??


Sevan
___
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: Net-SNMP 5.7.3 with Perl support fails at configure stage

2015-01-19 Thread Ryan Steinmetz 


On (01/19/15 15:22), Sevan / Venture37 wrote:

On 19 January 2015 at 14:33, Ryan Steinmetz  wrote:

Sevan,

I'm currently working on an update for the port to get it to 5.7.3.  In
the interim, you should install 5.7.2 from the ports tree:

To install the port: cd /usr/ports/net-mgmt/net-snmp/ && make install clean
To add the package: pkg install net-mgmt/net-snmp

-r

Hi Ryan,
Sure thing, for the sake of technical discussion, what's the cause of
the issue, autoconf??



Sevan,

Sorry, I don't want to dive in to try to figure out the specific issue.
This why we have the ports tree! :)

-r



Sevan


--
Ryan Steinmetz
PGP: 9079 51A3 34EF 0CD4 F228  EDC6 1EF8 BA6B D028 46D7
___
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"

Port upgrade issue

2015-01-19 Thread Leander Schäfer 

Hi,

I have optimized the current rsyncd rc script some time ago. Added 
features are e.g.:


 * run multiple instances - as known eg. by OpenVPN rc-script
 * pid & lock files cleaned up nicely under
   /var/run/rsync/{instance}.{pid,lock}
 * added rc.conf variables for better control
 o NAME_pidfile="/var/run/rsync/NAME.pid" # Where to write process id
 o NAME_lockfile="/var/run/rsync/NAME.lock" # Support for the lqmax
   connectionsrq parameter

This way the FreeBSD user can change pid and lock file without screwing 
up rc-script expectations.


The port maintainer offered to apply the changes if I would provide them 
to him as diff patch.




Emanuel Haupt said:

   [...] You're the first one to ask for such a feature ever since I
   maintain this port. But tell you what, If you can fabricate a clean,
   well tested (poudriere logs) patch I will commit it. [...]


Well I did so (a couple of times) via email but unfortunately he never 
replied or made any other move. Eventually I decided to open up a commit 
request as described in the 
Handbook_https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=195232_


Unfortunately nothing has changed since ever then. I don't know if 
something happened to the port maintainer or if he simply doesn't have 
internet access anymore?! Now my question is what can I do / Who can I 
ask to apply this patch?


Thank you
--- ./rsyncd-current2015-01-19 14:04:33.0 +0100
+++ /usr/local/etc/rc.d/rsyncd  2014-10-30 13:44:51.0 +0100
@@ -8,39 +8,83 @@
 # BEFORE:  securelevel
 # KEYWORD: shutdown
 
-# Add the following lines to /etc/rc.conf to enable `rsyncd':
+# -
 #
-# rsyncd_enable="YES"
-# rsyncd_flags=""
+# This script supports running multiple instances of rsyncd.
+# To run additional instances link this script to something like
+# % ln -s rsyncd rsyncd_foo
+# and define additional rsyncd_foo_* variables in one of
+# /etc/rc.conf, /etc/rc.conf.local or /etc/rc.conf.d/openvpn_foo
 #
-# See rsync(1) for rsyncd_flags
+# Below NAME should be substituted with the name of this script. By default
+# it is rsyncd, so read as rsyncd_enable. If you linked the script to
+# rsyncd_foo, then read as rsyncd_foo_enable etc.
 #
+# The following variables are supported (defaults are shown).
+# You can place them in any of
+# /etc/rc.conf, /etc/rc.conf.local or /etc/rc.conf.d/NAME
+#
+# NAME_enable="NO"  # set to YES to enable rsyncd
+#
+# # optional:
+# NAME_configfile="/usr/local/etc/rsync/NAME.conf"  # Where to look for config 
file
+# NAME_pidfile="/var/run/rsync/NAME.pid"# Where to write process id
+# NAME_lockfile="/var/run/rsync/NAME.lock"  # Support for the lqmax 
connectionsrq parameter
+# NAME_flags=""  # See rsync(1) for 
NAME_flags
+#
+# -
 
 . /etc/rc.subr
 
-name="rsyncd"
-rcvar=rsyncd_enable
+case "${0}" in
+/etc/rc*)
+# during boot (shutdown) ${0} is /etc/rc (/etc/rc.shutdown),
+# so get the name of the script from $_file
+name="${_file}"
+;;
+*)
+name="${0}"
+;;
+esac
+
+name="${name##*/}"
+rcvar=${name}_enable
+
 
 command="/usr/local/bin/rsync"
 start_precmd="rsyncd_precmd"
-pidfile="/var/run/$name.pid"
+stop_postcmd="rsyncd_postcmd"
 
 # read configuration and set defaults
-load_rc_config "$name"
-: ${rsyncd_enable="NO"}
-: ${rsyncd_configfile:=/usr/local/etc/rsync/$name.conf}
-
-required_files="${rsyncd_configfile}"
-
-command_args="--daemon --config ${rsyncd_configfile}"
-
-rsyncd_precmd()
-{
-   if [ -f "/usr/local/etc/$name.conf" ] && [ ! -L 
"/usr/local/etc/$name.conf" ]; then
-   echo "Found /usr/local/etc/$name.conf in old location. 
Migrating to /usr/local/etc/rsync/$name.conf."
-   mv /usr/local/etc/$name.conf /usr/local/etc/rsync/$name.conf
-   ln -s /usr/local/etc/rsync/$name.conf /usr/local/etc/$name.conf
-   fi
+load_rc_config "${name}"
+eval ": \${${name}_enable:=\"NO\"}"
+eval ": \${${name}_configfile:=\"/usr/local/etc/rsync/${name}.conf\"}"
+eval ": \${${name}_pidfile:=\"/var/run/rsync/${name}.pid\"}"
+eval ": \${${name}_lockfile:=\"/var/run/rsync/${name}.lock\"}"
+
+configfile="$(eval echo \${${name}_configfile} )"
+pidfile="$(eval echo \${${name}_pidfile})"
+lockfile="$(eval echo \${${name}_lockfile})"
+
+required_files="${configfile}"
+
+command_args="--daemon --config ${configfile} --dparam=pidfile=${pidfile} 
--dparam=lockfile=${lockfile}"
+
+rsyncd_precmd () {
+mkdir -p -m 0755 "$(dirname ${pidfile})"
+mkdir -p -m 0755 "$(dirname ${lockfile})"
+if [ -f "/usr/local/etc/${name}.conf" ] && [ ! -L 
"/usr/local/etc/${name}.conf" ]; then
+echo "Found /usr/local/etc/${name}.conf in old location. Migrating to 
${configfile}."
+mv /usr/local/etc/${name}.conf ${configfile}
+ln -s ${configfile} /usr/local/etc/${name}.conf
+fi
 }
 
-run

Re: Poudriere Timeout

2015-01-19 Thread Torsten Zuehlsdorff 

Hi,


Has anyone seen this before?



print/texlive-texmf texlive-texmf-20140525_4 package/timeout runaway_process


Yes, i have. I've solved this problem by moving the build-jails of
poudriere to an memory disk. This make poudriere no longer io-bund and
incredibly fast. And solve this issue ;)


How did you do this ? I want to try this myself 8-}


I've hacked poudriere to run within a jail. Therefore its slightly 
modified and you must checked the paths for your configuration.


When you run "poudriere bulk" you can view with "jls" the path were it 
creates the build-jails. Stop it right there.


In my case the path is:
/usr/local/jail/poudriere/poudriere/data/.m

(It is possible that you must create the path)

I do before execution:

# mdmfs -s 20gb -S -o async md1 /usr/local/jail/poudriere/poudriere/data/.m

This creates an memory disk of 20 GB and mounts it to the given path. 
Please be careful that the size is not greater than you RAM + free SWAP. 
Otherwise you could kill some programs.


After this, launch poudriere. Invoke it with -J and choose a small 
number for testing. With 20 GB memory disk it works best for me with "-J 
6". With less RAM use less jails. After building finished unmount the 
path and free the ram:


# umount /usr/local/jail/poudriere/poudriere/data/.m
# mdconfig -d -u 1

Everything can be scripted easily. In my case this speeds up the 
complete build for the packages of my Laptop (around 800 packages, 
involving X, Firefox, Thunderbird, LibreOffice) from 20 hours to 4,5 hour.


Memory disk is a very good choice, because most of the IO - creating 
jail, building dependencies, compiling, etc. - is thrown away at the 
end. At least we just want the final package.


I can write a more detailed description if needed.

Greetings from Germany,
Torsten
___
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"

Protégez votre famille quoi qu'il arrive

2015-01-19 Thread Assurances Obsèques 2015 
Cliquez ici pour lire cet e-mail dans votre navigateur.


 

 

 

 



--

 This message was sent to freebsd-ports@freebsd.org by ad...@ma-mutuelle.tk

 To forward this message, please do not use the forward button of your
email application, because this message was made specifically for you only.
Instead use the forward page

in our newsletter system.

 To change your details and to choose which lists to be subscribed to,
visit your personal preferences page


 Or you can opt-out completely

from all future mailings.

 


-- powered by phpList, www.phplist.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"

Au revoir de notre bulletin d'information

2015-01-19 Thread My email 

  
  Goodbye from our Newsletter, sorry to see you go.

  You have been unsubscribed from our newsletters.

  This is the last email you will receive from us. Our newsletter system,
phpList,
  will refuse to send you any further messages, without manual intervention
by our administrator.

  If there is an error in this information, you can re-subscribe:
  please go to http://www.ma-mutuelle.tk/obseque/?p=subscribe and follow
the steps.

  Thank you
  
  

___
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: PKG - Fail to kill children

2015-01-19 Thread Baptiste Daroussin 
January 19 2015 4:15 PM, "Michael Jung"  wrote: 
> On 2015-01-19 09:20, Michael Jung wrote:
> 
>> FreeBSD 10.1-RELEASE #0 r276896:
>> pkg 1.4.4 or pkg 1.4.6
>> poudriere 3.1.1 under 11.0-CURRENT r275419
>> 
>> On i386 only pkg complains with "Fail to kill children". I have
>> checked some but not all packages
>> and they appear to be updated as expected so this
>> is a heads up.
>> 
I do not understand your setting, but that means you have an old kernel running 
a more recent userland (which is something unsupported btw :))

So when building pkg is discovering it is being built on head (aka it support 
the acquiring the reaper via procctl(2)) and assume it can use it. But your 
kernel does not have support for that, hence the failure.

Basically your host must always be newer that your jails

Best regards,
Bapt
___
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: PKG - Fail to kill children

2015-01-19 Thread Konstantin Belousov 
On Mon, Jan 19, 2015 at 05:06:34PM +, Baptiste Daroussin wrote:
> January 19 2015 4:15 PM, "Michael Jung"  wrote: 
> > On 2015-01-19 09:20, Michael Jung wrote:
> > 
> >> FreeBSD 10.1-RELEASE #0 r276896:
> >> pkg 1.4.4 or pkg 1.4.6
> >> poudriere 3.1.1 under 11.0-CURRENT r275419
> >> 
> >> On i386 only pkg complains with "Fail to kill children". I have
> >> checked some but not all packages
> >> and they appear to be updated as expected so this
> >> is a heads up.
> >> 
> I do not understand your setting, but that means you have an old kernel 
> running a more recent userland (which is something unsupported btw :))
> 
> So when building pkg is discovering it is being built on head (aka it support 
> the acquiring the reaper via procctl(2)) and assume it can use it. But your 
> kernel does not have support for that, hence the failure.
> 
> Basically your host must always be newer that your jails

Would be useful for pkg to print the failed syscall name/basic mode and errno
in addition to its interpretation of the events.
___
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: PKG - Fail to kill children

2015-01-19 Thread Baptiste Daroussin 
January 19 2015 6:20 PM, "Konstantin Belousov"  wrote: 
> On Mon, Jan 19, 2015 at 05:06:34PM +, Baptiste Daroussin wrote:
> 
>> January 19 2015 4:15 PM, "Michael Jung"  wrote:
>>> On 2015-01-19 09:20, Michael Jung wrote:
>>> 
 FreeBSD 10.1-RELEASE #0 r276896:
 pkg 1.4.4 or pkg 1.4.6
 poudriere 3.1.1 under 11.0-CURRENT r275419
 
 On i386 only pkg complains with "Fail to kill children". I have
 checked some but not all packages
 and they appear to be updated as expected so this
 is a heads up.
 
>> I do not understand your setting, but that means you have an old kernel 
>> running a more recent
>> userland (which is something unsupported btw :))
>> 
>> So when building pkg is discovering it is being built on head (aka it 
>> support the acquiring the
>> reaper via procctl(2)) and assume it can use it. But your kernel does not 
>> have support for that,
>> hence the failure.
>> 
>> Basically your host must always be newer that your jails
> 
> Would be useful for pkg to print the failed syscall name/basic mode and errno
> in addition to its interpretation of the events.

Yes I will make that in pkg 1.4.7

Best regards,
Bapt
___
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: Net-SNMP 5.7.3 with Perl support fails at configure stage

2015-01-19 Thread Ryan Steinmetz 

Sevan,

I've updated the port to 5.7.3.

-r

On (01/19/15 15:22), Sevan / Venture37 wrote:

On 19 January 2015 at 14:33, Ryan Steinmetz  wrote:

Sevan,

I'm currently working on an update for the port to get it to 5.7.3.  In
the interim, you should install 5.7.2 from the ports tree:

To install the port: cd /usr/ports/net-mgmt/net-snmp/ && make install clean
To add the package: pkg install net-mgmt/net-snmp

-r

Hi Ryan,
Sure thing, for the sake of technical discussion, what's the cause of
the issue, autoconf??


Sevan


--
Ryan Steinmetz
PGP: 9079 51A3 34EF 0CD4 F228  EDC6 1EF8 BA6B D028 46D7
___
freebsd-ports@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-ports
To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org"

Re: Poudriere Timeout

2015-01-19 Thread Kurt Jaeger 
Hi!

> >> Yes, i have. I've solved this problem by moving the build-jails of
> >> poudriere to an memory disk. This make poudriere no longer io-bund and
> >> incredibly fast. And solve this issue ;)

> > How did you do this ? I want to try this myself 8-}

> I've hacked poudriere to run within a jail.

Aha, the .m mountpoint. My test host has 32 GB, so 20 GB should not be
a problem.

Testport: www/p5-Selenium-Remote-Driver on 10.1-amd64, 9.3-amd64 and 8.4-i386.

Results:

old: 00:05:43
new: 00:05:11

old: 00:01:56
new: 00:00:12

old: 00:02:11
new: 00:00:14

Nice!

-- 
p...@opsec.eu+49 171 3101372 5 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: Poudriere Timeout

2015-01-19 Thread olli hauer 
On 2015-01-19 20:18, Kurt Jaeger wrote:
> Hi!
> 
 Yes, i have. I've solved this problem by moving the build-jails of
 poudriere to an memory disk. This make poudriere no longer io-bund and
 incredibly fast. And solve this issue ;)
> 
>>> How did you do this ? I want to try this myself 8-}
> 
>> I've hacked poudriere to run within a jail.
> 
> Aha, the .m mountpoint. My test host has 32 GB, so 20 GB should not be
> a problem.
> 
> Testport: www/p5-Selenium-Remote-Driver on 10.1-amd64, 9.3-amd64 and 8.4-i386.
> 
> Results:
> 
> old: 00:05:43
> new: 00:05:11
> 
> old: 00:01:56
> new: 00:00:12
> 
> old: 00:02:11
> new: 00:00:14
> 
> Nice!
> 

Hi Kurt,

are you running PD also in a jail?

If not PD can be tuned by setting MFSSIZE *or* USE_TMPFS in poudriere.conf.

On my system I have good results with 8 concurrent builds and MFSSIZE=6G or 
'USE_TMPFS=all'.
Fine tuning can be done with an additional SSD (look at `systat -iostat' during 
a build)

poudriere.conf:

# When building packages, a memory device can be used to speedup the build.
# Only one of MFSSIZE or USE_TMPFS is supported. TMPFS is generally faster
# and will expand to the needed amount of RAM. MFS is a bit slower, but is
# more mature and can have its memory usage capped.

# If set WRKDIRPREFIX will be mdmfs of the given size (mM or gG)
#MFSSIZE=4G

# Use tmpfs(5)
...
# all   - Run the entire build in memory, including builder jails.
USE_TMPFS=all

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