Re: Debugging ports

2017-10-17 Thread Jan Beich 
Kubilay Kocak  writes:

> On 10/18/17 8:29 AM, Jan Beich wrote:
>
>> Guido Falsi  writes:
>> 
>>> On 10/17/2017 23:11, Guido Falsi wrote:
>>>
>
> Thing is, recompiling with WITH_DEBUG doesn't help (I only get
> memory addresses in gdb), nor does -DCMAKE_BUILD_TYPE=Debug to
> CMAKE_ARGS (the port uses CMake).
>>>
>>> Sorry, I clearly did not parse your message correctly.
>>>
>>> Looks strange though, WITH_DEBUG always worked for me... Usually I
>>> compile the whole set in poudriere with WITH_DEBUG, to make sure all
>>> libraries have symbols too.
>> 
>> WITH_DEBUG doesn't disable vendor optimizations like -fomit-frame-pointer
>> which may hinder stack unwinding, doesn't enable debug symbols for ports
>> not respecting CFLAGS, often a nop for non-C/C++ ports, etc.
>
> Could the framework WITH_DEBUG block remove this (and potentially) other
> relevant flags from C*FLAGS if present with variable modifiers?

Only for what make(1) inherits when Mk/bsd.port.mk is parsed. A lot more
ports pass the option via makefiles under WRKSRC that cannot be altered
short of patching or overriding all CFLAGS.

To get accurate list of offenders an -exp run WITH_DEBUG=1 is required
then grep(1) build logs for -fomit-frame-pointer and -O* flags. This can
result in bugs against ports that fail to properly respect CFLAGS, so the
port maintainers can help with patches.
___
freebsd-ports@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-ports
To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org"

Re: Debugging ports

2017-10-17 Thread Kubilay Kocak 
On 10/18/17 8:29 AM, Jan Beich wrote:
> Guido Falsi  writes:
> 
>> On 10/17/2017 23:11, Guido Falsi wrote:
>>

 Thing is, recompiling with WITH_DEBUG doesn't help (I only get
 memory addresses in gdb), nor does -DCMAKE_BUILD_TYPE=Debug to
 CMAKE_ARGS (the port uses CMake).
>>
>> Sorry, I clearly did not parse your message correctly.
>>
>> Looks strange though, WITH_DEBUG always worked for me... Usually I
>> compile the whole set in poudriere with WITH_DEBUG, to make sure all
>> libraries have symbols too.
> 
> WITH_DEBUG doesn't disable vendor optimizations like -fomit-frame-pointer
> which may hinder stack unwinding, doesn't enable debug symbols for ports
> not respecting CFLAGS, often a nop for non-C/C++ ports, etc.

Could the framework WITH_DEBUG block remove this (and potentially) other
relevant flags from C*FLAGS if present with variable modifiers?

> Without an example it's hard to guess.


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

RE: Openfire 4.1.6 compile failed

2017-10-17 Thread Doug Sampson 
> During upgrade of openfire from 4.1.5 to 4.16 the following error was
> observed:
> 
> ===>  Installing for openfire-4.1.6,1
> ===>  Checking if openfire already installed
> ===>   Registering installation for openfire-4.1.6,1
> Installing openfire-4.1.6,1...
> ===> Creating groups.
> Using existing group 'openfire'.
> ===> Creating users
> Using existing user 'openfire'.
> pkg-static: Fail to rename /usr/local/share/java/openfire/.logs.a8He9zi58mQv
> -> /usr/local/share/java/openfire/logs:Is a directory
> *** Error code 70
> 
> Stop.
> make[1]: stopped in /usr/ports/net-im/openfire
> *** Error code 1
> 
> Stop.
> make: stopped in /usr/ports/net-im/openfire
> 
> ===>>> A backup package for openfire-4.1.5,1 should
>be located in /usr/ports/packages/portmaster-backup
> 
> ===>>> Installation of openfire-4.1.6,1 (net-im/openfire) failed
> ===>>> Aborting update
> 
> ===>>> Update for net-im/openfire failed
> ===>>> Aborting update
> 
> ===>>> There are messages from installed ports to display,
>but first take a moment to review the error messages
>above.  Then press Enter when ready to proceed.
> 
> 

# ll /usr/local/share/java/openfire
total 36
lrwxr-xr-x  1 openfire  openfire17 Aug 29 17:32 .logs.CB0BLDkFGJLs -> 
/var/log/openfire
lrwxr-xr-x  1 openfire  openfire23 Aug 29 17:32 conf -> 
/usr/local/etc/openfire
lrwxr-xr-x  1 openfire  openfire16 Aug 29 17:32 embedded-db -> 
/var/db/openfire
drwxr-xr-x  3 openfire  openfire   512 Aug 31 12:13 enterprise
drwxr-xr-x  2 openfire  openfire   512 Aug 30 15:08 fastpath
drwxr-xr-x  2 openfire  openfire   512 Aug 31 12:45 index
drwxr-xr-x  2 root  openfire  1024 Oct 17 18:01 lib
drwxr-xr-x  2 openfire  openfire   512 Oct 17 17:40 logs
drwxr-xr-x  3 openfire  openfire   512 Aug 30 15:08 monitoring
drwxr-xr-x  2 openfire  openfire   512 Aug 30 15:08 nodejs
drwxr-xr-x  5 openfire  openfire  2048 Oct 17 18:01 plugins
drwxr-xr-x  4 root  openfire   512 Oct 17 18:01 resources
#
___
freebsd-ports@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-ports
To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org"

Openfire 4.1.6 compile failed

2017-10-17 Thread Doug Sampson 
During upgrade of openfire from 4.1.5 to 4.16 the following error was observed:

===>  Installing for openfire-4.1.6,1
===>  Checking if openfire already installed
===>   Registering installation for openfire-4.1.6,1
Installing openfire-4.1.6,1...
===> Creating groups.
Using existing group 'openfire'.
===> Creating users
Using existing user 'openfire'.
pkg-static: Fail to rename /usr/local/share/java/openfire/.logs.a8He9zi58mQv -> 
/usr/local/share/java/openfire/logs:Is a directory
*** Error code 70

Stop.
make[1]: stopped in /usr/ports/net-im/openfire
*** Error code 1

Stop.
make: stopped in /usr/ports/net-im/openfire

===>>> A backup package for openfire-4.1.5,1 should
   be located in /usr/ports/packages/portmaster-backup

===>>> Installation of openfire-4.1.6,1 (net-im/openfire) failed
===>>> Aborting update

===>>> Update for net-im/openfire failed
===>>> Aborting update

===>>> There are messages from installed ports to display,
   but first take a moment to review the error messages
   above.  Then press Enter when ready to proceed.


~Doug


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

requesting policy for Apache module installation (LoadModule manipulation)

2017-10-17 Thread Miroslav Lachman 

Hello,
I would like to ask some changes in how Apache modules are installed.
There are many maintainers and many different sources for Apache 
modules. Some modules are installing sample files, some are modifying 
httpd.conf (LoadModule line) after each install / deinstall.


The modification after each deinstall is really a mess. If I installed 
mod_xsendfile, enabled it in httpd.conf and later will use pkg upgrade 
it will modify my httpd.conf in unwanted way - the mod_xsendfile will be 
disabled. Same applies to many other modules.


Some modules (mod_php) is installed and enabled by default. (different 
behaviour for different modules? Why?)


Can this behaviour be changed (unified) for all Apache modules to not 
touch these lines (modules enabled by user)?


If some port install some config file and user did some changes, this 
file must not be deleted by deinstalling the port so why Apache modules 
can remove / comment out lines touched by users?


Broken Apache webserver after each pkg upgrade is really annoying.


Making all ports use the same script post-install / post-deinstall would 
be nice too.


For example mod_php uses

   "scripts":{
  "post-install":"/usr/local/sbin/apxs -e -a -n php5 libphp5.so",
  "pre-deinstall":"/usr/local/sbin/apxs -e -A -n php5 libphp5.so"
   },

mod_xsendfile uses

   "scripts":{
  "post-install":"/usr/local/sbin/apxs -e -A -n xsendfile 
/usr/local/libexec/apache24/mod_xsendfile.so",
  "post-deinstall":"/usr/bin/sed -i '' -E 
'/LoadModule[[:blank:]]+xsendfile_module/d' 
/usr/local/etc/apache24/httpd.conf\necho \"Don't forget to remove all 
mod_xsendfile-related directives in your httpd.conf\""

   }

to achieve the same results (broken httpd.conf)

mod_php uses pre-deinstall
mod_xsendfile uses post-deinstall

mod_php enables mod_php on installation by apxs -e -a
mod_xsendfile adds commented line by apxs -e -A

This is just example of two modules. I looked at more modules and they 
are almost unique - each using different targets, different apxs options 
etc.


I am proposing not touching httpd.conf on deinstall at all and just 
printing the warning that the corresponding LoadModule line should be 
removed if it is no longer necessary. (by running apxs command?)


Also use "apxs -e -A -n moduleName" on install only if there is no 
LoadModule line for this module:


"post-install":"/usr/bin/grep -E '^#?LoadModule.*php5_module' 
/usr/local/etc/apache24/httpd.conf || /usr/local/sbin/apxs -e -A -n php5 
libphp5.so"


Another way to achieve this can be separate file in apache24/modules.d/ 
installed as sample and if user wants to enable it, just rename it to 
moduleName.conf. Then it will not be touched by pkg upgrade / deinstall 
phase.


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

Re: Debugging ports

2017-10-17 Thread Piotr Kubaj via freebsd-ports 

I think I got it. It turns out that it's our gdb in base that can't read the 
debug info. lldb and gdb from ports do it just fine.

I also thought about recompiling library dependecies, but something didn't fit 
in, because not only the libraries calls were not there, but the calls from the 
port itself as well.

Thanks anyway!

On 17-10-17 23:29:47, Jan Beich wrote:

Guido Falsi  writes:


On 10/17/2017 23:11, Guido Falsi wrote:



Thing is, recompiling with WITH_DEBUG doesn't help (I only get
memory addresses in gdb), nor does -DCMAKE_BUILD_TYPE=Debug to
CMAKE_ARGS (the port uses CMake).


Sorry, I clearly did not parse your message correctly.

Looks strange though, WITH_DEBUG always worked for me... Usually I
compile the whole set in poudriere with WITH_DEBUG, to make sure all
libraries have symbols too.


WITH_DEBUG doesn't disable vendor optimizations like -fomit-frame-pointer
which may hinder stack unwinding, doesn't enable debug symbols for ports
not respecting CFLAGS, often a nop for non-C/C++ ports, etc.

Without an example it's hard to guess.

--
This message has been scanned for viruses and
dangerous content by MailScanner, and is
believed to be clean.



--
_ 
/ If a camel is a horse designed by a \

| committee, then a consensus forecast is |
| a camel's behind.   |
| |
\ -- Edgar R. Fiedler /
- 
   \   ^__^

\  (oo)\___
   (__)\   )\/\
   ||w |
   || ||


signature.asc
Description: PGP signature

Re: Debugging ports

2017-10-17 Thread Jan Beich 
Guido Falsi  writes:

> On 10/17/2017 23:11, Guido Falsi wrote:
>
>>>
>>> Thing is, recompiling with WITH_DEBUG doesn't help (I only get
>>> memory addresses in gdb), nor does -DCMAKE_BUILD_TYPE=Debug to
>>> CMAKE_ARGS (the port uses CMake).
>
> Sorry, I clearly did not parse your message correctly.
>
> Looks strange though, WITH_DEBUG always worked for me... Usually I
> compile the whole set in poudriere with WITH_DEBUG, to make sure all
> libraries have symbols too.

WITH_DEBUG doesn't disable vendor optimizations like -fomit-frame-pointer
which may hinder stack unwinding, doesn't enable debug symbols for ports
not respecting CFLAGS, often a nop for non-C/C++ ports, etc.

Without an example it's hard to guess.
___
freebsd-ports@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-ports
To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org"

Re: Debugging ports

2017-10-17 Thread Guido Falsi 

On 10/17/2017 23:11, Guido Falsi wrote:



Thing is, recompiling with WITH_DEBUG doesn't help (I only get memory 
addresses in gdb), nor does -DCMAKE_BUILD_TYPE=Debug to CMAKE_ARGS 
(the port uses CMake).


Sorry, I clearly did not parse your message correctly.

Looks strange though, WITH_DEBUG always worked for me... Usually I 
compile the whole set in poudriere with WITH_DEBUG, to make sure all 
libraries have symbols too.


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

Re: Debugging ports

2017-10-17 Thread Jan Beich 
Piotr Kubaj via freebsd-ports  writes:

> Hi all,
>
> I am preparing a new port. However, I hit an assertion fail when
> starting the binary. The developer is willing to help me, provided
> that I send him backtrace and values from the structure that hits
> assertion failure.
>
> Thing is, recompiling with WITH_DEBUG doesn't help (I only get memory
> addresses in gdb), nor does -DCMAKE_BUILD_TYPE=Debug to CMAKE_ARGS
> (the port uses CMake).
>
> What should I do to get necessary date?

Recompile library dependencies (look up which via ldd(1) and strings(1))
with debugging symbols as well. That may include not only ports but some
of the base e.g., lib/libc, lib/libthr, libexec/rtld-elf.
___
freebsd-ports@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-ports
To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org"

Re: Debugging ports

2017-10-17 Thread Guido Falsi 

On 10/17/2017 18:04, Piotr Kubaj via freebsd-ports wrote:

Hi all,

I am preparing a new port. However, I hit an assertion fail when 
starting the binary. The developer is willing to help me, provided that 
I send him backtrace and values from the structure that hits assertion 
failure.


Thing is, recompiling with WITH_DEBUG doesn't help (I only get memory 
addresses in gdb), nor does -DCMAKE_BUILD_TYPE=Debug to CMAKE_ARGS (the 
port uses CMake).


What should I do to get necessary date?

You should add "WITH_DEBUG=yes" in your make.conf file, then recompile 
any port in which you need debugging symbols. It will automatically 
disable optimizations, add -g to CFLAGS and add many other common knobs 
for any port. Most ports needing special care to get debugging binaries 
have extra directives in their Makefiles, enabled by that same flag.


Be aware that compiling a debugging version requires more memory than a 
normal version, for big ports it could get REALLY big. I was not able to 
compile a debugging version of llvm40 with 16 GiB RAM (one poudriere 
jail using make jobs, maybe without parallelization it could be done).


If you're using poudriere to build a whole set of ports you could use 
something like this (verbatim from my machine):


WITH_DEBUG= yes

.if ${.CURDIR:M*lang/ruby*} || ${.CURDIR:M*devel/llvm*} || 
${.CURDIR:M*lang/gcc*} || ${.CURDIR:M*devel/gdb*} || 
${.CURDIR:M*www/webkit*}

.undef WITH_DEBUG
.endif

(obviously I'm not debugging any of those which are quite memory hungry 
when building debugging versions, but I'm debugging other things 
depending on them)


Hope this helps.

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

Re: svn commit: r424112 - in head/www/fcgiwrap: . files

2017-10-17 Thread Xin LI 
Hi, Mathieu,

Sorry for catching this late, but is there any reason not to simply
run the daemon under the desired credentials, instead of doing this
chown/chmod dance afterward?

Not all systems start fcgiwrap daemon quick enough for the socket to
show up (a race condition, with potential of not setting it correctly,
which is observed about 3/5 times on my server).  Moreover, this will
also encourage using unneeded privileges (assuming fcgiwrap runs under
root credentials, which is the default fcgiwrap_user).

Cheers,

On Mon, Oct 17, 2016 at 5:03 AM, Mathieu Arnold  wrote:
> Author: mat
> Date: Mon Oct 17 12:03:08 2016
> New Revision: 424112
> URL: https://svnweb.freebsd.org/changeset/ports/424112
>
> Log:
>   Add changing the owner/group/mode for the socket.
>
>   PR:   213385
>   Submitted by: mat
>   Approved by:  maintainer
>   Sponsored by: Absolight
>
> Modified:
>   head/www/fcgiwrap/Makefile   (contents, props changed)
>   head/www/fcgiwrap/files/fcgiwrap.in
>
> Modified: head/www/fcgiwrap/Makefile
> ==
> --- head/www/fcgiwrap/Makefile  Mon Oct 17 12:03:03 2016(r424111)
> +++ head/www/fcgiwrap/Makefile  Mon Oct 17 12:03:08 2016(r424112)
> @@ -2,7 +2,7 @@
>
>  PORTNAME=  fcgiwrap
>  PORTVERSION=   1.1.0
> -PORTREVISION=  3
> +PORTREVISION=  4
>  CATEGORIES=www
>  MASTER_SITES=  http://www.skysmurf.nl/comp/FreeBSD/distfiles/
>
>
> Modified: head/www/fcgiwrap/files/fcgiwrap.in
> ==
> --- head/www/fcgiwrap/files/fcgiwrap.in Mon Oct 17 12:03:03 2016
> (r424111)
> +++ head/www/fcgiwrap/files/fcgiwrap.in Mon Oct 17 12:03:08 2016
> (r424112)
> @@ -19,6 +19,9 @@
>  # - tcp6:[ipv6_addr]:port (for ipv6)
>  # fcgiwrap_flags=
>  # Use fcgiwrap_user to run fcgiwrap as user
> +# Use fcgiwrap_socket_mode to change the mode of the socket
> +# Use fcgiwrap_socket_owner to change the owner of the socket
> +# Use fcgiwrap_socket_group to change the group of the socket
>
>  # fcgiwrap rc.d script supports multiple profiles (a-la rc.d/nginx)
>  # When profiles are specified, the non-profile specific parameters become 
> defaults.
> @@ -29,10 +32,12 @@
>  # fcgiwrap_enable="YES"
>  # fcgiwrap_profiles="myserver myotherserver"
>  # fcgiwrap_flags="-c 4"
> +# fcgiwrap_socket_owner="www"
>  # fcgiwrap_myserver_socket="unix:/var/run/fcgiwrap.myserver.socket"
>  # fcgiwrap_myserver_user="myuser"
>  # fcgiwrap_myotherserver_socket="unix:/var/run/fcgiwrap.myotherserver.socket"
>  # fcgiwrap_myotherserver_user="myotheruser"
> +# fcgiwrap_myserver_socket_mode="0775"
>  # fcgiwrap_myotherserver_flags=""  # No flags for this profile.
>
>  . /etc/rc.subr
> @@ -62,6 +67,26 @@ fcgiwrap_precmd() {
> install -d -o root -g wheel -m 1777 /var/run/fcgiwrap
>  }
>
> +fcgiwrap_postcmd() {
> +   # This is only for unix sockets
> +   case "${fcgiwrap_socket}" in
> +   unix:*)
> +   ;;
> +   *)
> +   return
> +   ;;
> +   esac
> +   if [ -n "${fcgiwrap_socket_mode}" ]; then
> +   chmod ${fcgiwrap_socket_mode} ${fcgiwrap_socket#unix:}
> +   fi
> +   if [ -n "${fcgiwrap_socket_owner}" ]; then
> +   chown ${fcgiwrap_socket_owner} ${fcgiwrap_socket#unix:}
> +   fi
> +   if [ -n "${fcgiwrap_socket_group}" ]; then
> +   chgrp ${fcgiwrap_socket_group} ${fcgiwrap_socket#unix:}
> +   fi
> +}
> +
>  fcgiwrap_cleansocket() {
> # Workaround the fact that fcgiwrap doesn't cleanup his socket at 
> stopping
> case ${fcgiwrap_socket} in
> @@ -78,6 +103,7 @@ pidfile="${pidprefix}.pid"  # May be a d
>  procname="%%PREFIX%%/sbin/${name}"
>  command="/usr/sbin/daemon"
>  start_precmd="fcgiwrap_precmd"
> +start_postcmd="fcgiwrap_postcmd"
>  stop_postcmd="fcgiwrap_cleansocket"
>
>  load_rc_config $name
> @@ -86,6 +112,9 @@ load_rc_config $name
>  fcgiwrap_enable=${fcgiwrap_enable:-"NO"}
>  fcgiwrap_user=${fcgiwrap_user:-"root"}
>  fcgiwrap_socket=${fcgiwrap_socket:-"unix:/var/run/fcgiwrap/fcgiwrap.sock"}
> +fcgiwrap_socket_mode=${fcgiwrap_socket_mode:-"0755"}
> +fcgiwrap_socket_owner=${fcgiwrap_socket_owner:-"root"}
> +fcgiwrap_socket_group=${fcgiwrap_socket_group:-"wheel"}
>
>  # This handles profile specific vars.
>  if [ -n "$2" ]; then
> @@ -96,6 +125,9 @@ if [ -n "$2" ]; then
> eval 
> fcgiwrap_fib="\${fcgiwrap_${profile}_fib:-${fcgiwrap_fib}}"
> eval 
> fcgiwrap_user="\${fcgiwrap_${profile}_user:-${fcgiwrap_user}}"
> eval fcgiwrap_socket="\${fcgiwrap_${profile}_socket:?}"
> +   eval 
> fcgiwrap_socket_mode="\${fcgiwrap_${profile}_socket_mode:-${fcgiwrap_socket_mode}}"
> +   eval 
> fcgiwrap_socket_owner="\${fcgiwrap_${profile}_socket_owner:-${fcgiwrap_socket_owner}}"
> +   eval 
>

Re: FreeBSD Port: py27-fail2ban-0.10.1

2017-10-17 Thread Janky Jay, III 
Hi Alex,

On 10/17/2017 10:35 AM, Alex V. Petrov wrote:
> What should be in pf.conf?
> 

Something as simple has the below should work (edit to however you see
fit):

# define macros for each network interface
ext_if = "em0"

icmp_types = "echoreq"
allproto = "{ tcp, udp, ipv6, icmp, esp, ipencap }"
privnets = "{ 127.0.0.0/8, 192.168.0.0/16, 172.16.0.0/12, 10.0.0.0/8 }"

set loginterface $ext_if
scrub in on $ext_if no-df random-id

> 
> 17.10.2017 23:15, Janky Jay, III пишет:
>> In the new 0.10 version, the action rule creates the tables for you
>> based on the jail configuration. If you look at the jail files, you'll
>> see that you now call pfctl using additional arguments such as ports
>> that are affected and a suffix to add to the default "f2b-" table name.
>>
>>  So, essentially, there is no reason to create tables in the
>> pf.conf/pf.rules file anymore. They are automatically created when a
>> fail2ban filter is triggered and the IP is then added to it.
> 



signature.asc
Description: OpenPGP digital signature

Re: PR looking for committer

2017-10-17 Thread Kurt Jaeger 
Hi!

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

If I look at x11-wm/lxsession/Makefile, it already has a LIB_DEPENDS on
libck-connector.so:sysutils/consolekit2 -- so what is needed for
this to be done ?

-- 
p...@opsec.eu+49 171 3101372 3 years to go !
___
freebsd-ports@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-ports
To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org"

PR looking for committer

2017-10-17 Thread Mikaël Urankar 
Hi,
Can a committer have a look at these PR?
I will close them at the end of the month if nothing happens.

https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=221589
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=218870
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=221858

Thanks in advance

Please CC me, I'm not subscribed to this list.
___
freebsd-ports@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-ports
To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org"

Hosted PBX/Cloud PBX Updated User List Including Emails

2017-10-17 Thread flora . collins 
style="background-image:initial;background-position:initial;background-size:initial;background-repeat:initial;background-origin:initial;background-clip:initial">Hello,




style="background-image:initial;background-position:initial;background-size:initial;background-repeat:initial;background-origin:initial;background-clip:initial">We  
have the new Hosted PBX/Cloud PBX User
List, including email addresses and complete contact data for your  
business

leads.

style="background-image:initial;background-position:initial;background-size:initial;background-repeat:initial;background-origin:initial;background-clip:initial">If  
you are seeking out specific titles, please

let me know and I will provide you with additional data.

style="background-image:initial;background-position:initial;background-size:initial;background-repeat:initial;background-origin:initial;background-clip:initial">We  
also have client records for other

applications, such as: VoiP, PSTN,
Hosted PBX, PBX, Sip Trunking, WebEx, Zoom, RingCentral, Skype, Shortel, IBM
Sametime, Avaya Scopia and many more!

style="background-image:initial;background-position:initial;background-size:initial;background-repeat:initial;background-origin:initial;background-clip:initial">If  
Cloud

PBX Users are not applicable to you, please respond with your specific
criteria and the enterprises youd prefer to focus on in your  
advertising

effort. We have all kinds of marketing information available.

style="background-image:initial;background-position:initial;background-size:initial;background-repeat:initial;background-origin:initial;background-clip:initial">Thank  
you. I look forward to hearing from you.


style="background-image:initial;background-position:initial;background-size:initial;background-repeat:initial;background-origin:initial;background-clip:initial">Much

obliged,

style="background-image:initial;background-position:initial;background-size:initial;background-repeat:initial;background-origin:initial;background-clip:initial">Flora  
Collins
style="background-image:initial;background-position:initial;background-size:initial;background-repeat:initial;background-origin:initial;background-clip:initial">Information  
Specialist


style="color:rgb(124,124,124);background-image:initial;background-position:initial;background-size:initial;background-repeat:initial;background-origin:initial;background-clip:initial">To  
quit, please respond with Remove.id="DAB4FAD8-2DD7-40BB-A1B8-4E2AA1F9FDF2">



href="https://www.avast.com/sig-email?utm_medium=emailutm_source=linkutm_campaign=sig-emailutm_content=webmail;  
target="_blank">src="https://ipmcdn.avast.com/images/icons/icon-envelope-tick-round-orange-animated-no-repeat-v1.gif;  
alt="" width="46" height="29" style="width: 46px; height: 29px;">
		style="width:470px;padding-top:12px;color:#41424e;font-size:13px;font-family:Arial,Helvetica,sans-serif;line-height:18px">Virus-free.  
href="https://www.avast.com/sig-email?utm_medium=emailutm_source=linkutm_campaign=sig-emailutm_content=webmail;  
target="_blank" style="color:#4453ea">www.avast.com



height="1">
powered by GSM. Free mail merge and  
email marketing software for Gmail.

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

Re: FreeBSD Port: py27-fail2ban-0.10.1

2017-10-17 Thread Alex V. Petrov 
What should be in pf.conf?


17.10.2017 23:15, Janky Jay, III пишет:
> In the new 0.10 version, the action rule creates the tables for you
> based on the jail configuration. If you look at the jail files, you'll
> see that you now call pfctl using additional arguments such as ports
> that are affected and a suffix to add to the default "f2b-" table name.
> 
>   So, essentially, there is no reason to create tables in the
> pf.conf/pf.rules file anymore. They are automatically created when a
> fail2ban filter is triggered and the IP is then added to it.

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

Re: FreeBSD Port: py27-fail2ban-0.10.1

2017-10-17 Thread Janky Jay, III 
Hello,

In the new 0.10 version, the action rule creates the tables for you
based on the jail configuration. If you look at the jail files, you'll
see that you now call pfctl using additional arguments such as ports
that are affected and a suffix to add to the default "f2b-" table name.

So, essentially, there is no reason to create tables in the
pf.conf/pf.rules file anymore. They are automatically created when a
fail2ban filter is triggered and the IP is then added to it.

On 10/17/2017 07:16 AM, Alex V. Petrov wrote:
> In the old version I did so.
> 
> 
> 17.10.2017 19:47, Tommy Scheunemann пишет:
>> Hi,
>>
>> a simple setup that does the job for me:
>>
>> In /etc/pf.conf (bge0 is my external interface)
>>
>> --- SNIP ---
>> int_ext="bge0"
>> ...
>> table 
>> ...
>> block in quick on $int_ext from  to any
>> ...
>> --- SNIP ---
>>
>> And in ${PREFIX}/fail2ban/action.d defining a new "pf" action, e.g. pf.conf
>>
>> --- SNIP ---
>> [Definition]
>> actionban = /usr/local/bin/drop_ban 
>> actionunban = /usr/local/bin/drop_unban 
>> actioncheck =
>> actionstart =
>> actionstop =
>>
>> [Init]
>> --- SNIP ---
>>
>> And the "drop_ban" and "drop_unban" scripts:
>>
>> for ban:
>>
>> --- SNIP ---
>> #!/bin/sh
>> IP=$1
>> /sbin/pfctl -t badhosts -T add $IP
>> --- SNIP ---
>>
>> for unban
>>
>> --- SNIP ---
>> #!/bin/sh
>> IP=$1
>> /sbin/pfctl -t badhosts -T del $IP
>> --- SNIP ---
>>
>> I'm using scripts instead of directly using actionban / actionunban to
>> do some additional things like running a tcpdrop, having some better
>> logging.
>>
>> Once done with all this, you can use "action = pf" in your jail.conf file.
>>
>> Apart this I'd highly recommend to put all this into some configuration
>> system (Ansible, Puppet, Cfengine etc.).
>> Updating the package / port will overwrite your local changes !
>>
>> Have fun & good luck
>>
>> On Tue, 17 Oct 2017, Alex V. Petrov wrote:
>>
>>> Need a working sample for the new version of the port for pf.
>>>
>>> -
>>> Alex.
>>> ___
>>> freebsd-ports@freebsd.org mailing list
>>> https://lists.freebsd.org/mailman/listinfo/freebsd-ports
>>> To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org"
>>>
>>
>>
> 



signature.asc
Description: OpenPGP digital signature

Debugging ports

2017-10-17 Thread Piotr Kubaj via freebsd-ports 

Hi all,

I am preparing a new port. However, I hit an assertion fail when starting the 
binary. The developer is willing to help me, provided that I send him backtrace 
and values from the structure that hits assertion failure.

Thing is, recompiling with WITH_DEBUG doesn't help (I only get memory addresses 
in gdb), nor does -DCMAKE_BUILD_TYPE=Debug to CMAKE_ARGS (the port uses CMake).

What should I do to get necessary date?

--
__ 
/ The three best things about going to \

\ school are June, July, and August.   /
-- 
   \   ^__^

\  (oo)\___
   (__)\   )\/\
   ||w |
   || ||


signature.asc
Description: PGP signature

Re: FreeBSD Port: py27-fail2ban-0.10.1

2017-10-17 Thread Alex V. Petrov 
In the old version I did so.


17.10.2017 19:47, Tommy Scheunemann пишет:
> Hi,
> 
> a simple setup that does the job for me:
> 
> In /etc/pf.conf (bge0 is my external interface)
> 
> --- SNIP ---
> int_ext="bge0"
> ...
> table 
> ...
> block in quick on $int_ext from  to any
> ...
> --- SNIP ---
> 
> And in ${PREFIX}/fail2ban/action.d defining a new "pf" action, e.g. pf.conf
> 
> --- SNIP ---
> [Definition]
> actionban = /usr/local/bin/drop_ban 
> actionunban = /usr/local/bin/drop_unban 
> actioncheck =
> actionstart =
> actionstop =
> 
> [Init]
> --- SNIP ---
> 
> And the "drop_ban" and "drop_unban" scripts:
> 
> for ban:
> 
> --- SNIP ---
> #!/bin/sh
> IP=$1
> /sbin/pfctl -t badhosts -T add $IP
> --- SNIP ---
> 
> for unban
> 
> --- SNIP ---
> #!/bin/sh
> IP=$1
> /sbin/pfctl -t badhosts -T del $IP
> --- SNIP ---
> 
> I'm using scripts instead of directly using actionban / actionunban to
> do some additional things like running a tcpdrop, having some better
> logging.
> 
> Once done with all this, you can use "action = pf" in your jail.conf file.
> 
> Apart this I'd highly recommend to put all this into some configuration
> system (Ansible, Puppet, Cfengine etc.).
> Updating the package / port will overwrite your local changes !
> 
> Have fun & good luck
> 
> On Tue, 17 Oct 2017, Alex V. Petrov wrote:
> 
>> Need a working sample for the new version of the port for pf.
>>
>> -
>> Alex.
>> ___
>> freebsd-ports@freebsd.org mailing list
>> https://lists.freebsd.org/mailman/listinfo/freebsd-ports
>> To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org"
>>
> 
> 

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

Re: FreeBSD Port: py27-fail2ban-0.10.1

2017-10-17 Thread Tommy Scheunemann 

Hi,

a simple setup that does the job for me:

In /etc/pf.conf (bge0 is my external interface)

--- SNIP ---
int_ext="bge0"
...
table 
...
block in quick on $int_ext from  to any
...
--- SNIP ---

And in ${PREFIX}/fail2ban/action.d defining a new "pf" action, e.g. 
pf.conf


--- SNIP ---
[Definition]
actionban = /usr/local/bin/drop_ban 
actionunban = /usr/local/bin/drop_unban 
actioncheck =
actionstart =
actionstop =

[Init]
--- SNIP ---

And the "drop_ban" and "drop_unban" scripts:

for ban:

--- SNIP ---
#!/bin/sh
IP=$1
/sbin/pfctl -t badhosts -T add $IP
--- SNIP ---

for unban

--- SNIP ---
#!/bin/sh
IP=$1
/sbin/pfctl -t badhosts -T del $IP
--- SNIP ---

I'm using scripts instead of directly using actionban / actionunban to do 
some additional things like running a tcpdrop, having some better logging.


Once done with all this, you can use "action = pf" in your jail.conf file.

Apart this I'd highly recommend to put all this into some configuration 
system (Ansible, Puppet, Cfengine etc.).

Updating the package / port will overwrite your local changes !

Have fun & good luck

On Tue, 17 Oct 2017, Alex V. Petrov wrote:


Need a working sample for the new version of the port for pf.

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



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

Re: Makefile cannot download from Sourceforge

2017-10-17 Thread blubee blubeeme 
This is it, although I needed to change portname from zipios++ to zipios
since the working directory lacked the ++ suffix.

Thanks for the help!

On Tue, Oct 17, 2017 at 8:12 PM, Tijl Coosemans  wrote:

> On Tue, 17 Oct 2017 00:32:26 +0800 blubee blubeeme 
> wrote:
> > I'm trying to download some files from sourceforge but it fails
> constantly.
> >
> > PORTNAME= zipios++
> > PORTVERSION=  2.1.1
> > MASTER_SITES= SF/zipios/
>
> It looks like this should be SF/zipios/${PORTNAME}/${PORTVERSION}
>
> > DISTFILES=zipios-2.1.1.tar.gz
>
___
freebsd-ports@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-ports
To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org"

Re: FreeBSD Port: py27-fail2ban-0.10.1

2017-10-17 Thread Christoph Theis 

Am 17.10.2017 um 14:20 schrieb Alex V. Petrov:

Need a working sample for the new version of the port for pf.


Sorry, I'm not using pf and I'm not familiar with it. I'm even looking 
for a small sample /etc/pf.conf, so I can start playing around with it 
myself.


Have a look in the discussion on fail2ban, esp. issue 1915
https://github.com/fail2ban/fail2ban/issues/1915

It is still ongoing and if you are a pf user you can contribute.


Best regards

Christoph

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

FreeBSD Port: py27-fail2ban-0.10.1

2017-10-17 Thread Alex V. Petrov 
Need a working sample for the new version of the port for pf.

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

Re: Makefile cannot download from Sourceforge

2017-10-17 Thread Tijl Coosemans 
On Tue, 17 Oct 2017 00:32:26 +0800 blubee blubeeme  wrote:
> I'm trying to download some files from sourceforge but it fails constantly.
> 
> PORTNAME= zipios++
> PORTVERSION=  2.1.1
> MASTER_SITES= SF/zipios/

It looks like this should be SF/zipios/${PORTNAME}/${PORTVERSION}

> DISTFILES=zipios-2.1.1.tar.gz
___
freebsd-ports@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-ports
To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org"

Re: gnu ltdl and FreeBSD

2017-10-17 Thread blubee blubeeme 
The error seems related to libudev. I tried adding libudev to the
lib_dependencies like this below
LIB_DEPENDS= libltdl.so:devel/libltdl libudev.so:devel/libudev-devd

but the compilation still fails with this compilation error below, any tips
on getting past this issue?

gmake[4]: *** Waiting for unfinished jobs
libtool: compile:  c++ -DHAVE_CONFIG_H -I.. -pthread -I/usr/local/include
-DPKGLIBEXECDIR=\"/usr/local/libexec/utsushi\"
-DPKGLIBDIR=\"/usr/local/lib/utsushi\"
-DPKGDATADIR=\"/usr/local/share/utsushi\"
-DLOCALEDIR=\"/usr/local/share/locale\"
-DPKGSYSCONFDIR=\"/usr/local/etc/utsushi\" -DPKGCONFFILE=\"utsushi.conf\"
-DCOMBOCONFFILE=\"combo.conf\" -isystem /usr/local/include
-I/usr/local/include -I/usr/local/include -Wall -Werror
-I/usr/local/include -O2 -pipe -fstack-protector -isystem
/usr/local/include -fno-strict-aliasing -isystem /usr/local/include -MT
stream.lo -MD -MP -MF .deps/stream.Tpo -c stream.cpp  -fPIC -DPIC -o
.libs/stream.o
1 error generated.
gmake[4]: *** [Makefile:667: run-time.lo] Error 1
In file included from scanner.cpp:35:
../utsushi/log.hpp:155:36: error: instantiation of variable
'utsushi::log::basic_logger::os_'
required here,
  but no definition is available [-Werror,-Wundefined-var-template]
  basic_logger::os_ << *this;
   ^
../utsushi/log.hpp:265:23: note: in instantiation of member function
'utsushi::log::basic_message::~basic_message' requested here
  expand_named_ctors (fatal, FATAL);
  ^
../utsushi/log.hpp:49:47: note: forward declaration of template entity is
here
static std::basic_ostream& os_;
  ^
In file included from monitor.cpp:40:
../utsushi/log.hpp:155:36: error: instantiation of variable
'utsushi::log::basic_logger::os_'
required here,
  but no definition is available [-Werror,-Wundefined-var-template]
  basic_logger::os_ << *this;
   ^
../utsushi/log.hpp:265:23: note: in instantiation of member function
'utsushi::log::basic_message::~basic_message' requested here
  expand_named_ctors (fatal, FATAL);
  ^
../utsushi/log.hpp:49:47: note: forward declaration of template entity is
here
static std::basic_ostream& os_;
  ^
1 error generated.
1 error generated.
gmake[4]: *** [Makefile:667: scanner.lo] Error 1
gmake[4]: *** [Makefile:667: monitor.lo] Error 1
In file included from buffer.cpp:26:
../utsushi/log.hpp:155:36: error: instantiation of variable
'utsushi::log::basic_logger::os_'
required here,
  but no definition is available [-Werror,-Wundefined-var-template]
  basic_logger::os_ << *this;
   ^
../utsushi/log.hpp:265:23: note: in instantiation of member function
'utsushi::log::basic_message::~basic_message' requested here
  expand_named_ctors (fatal, FATAL);
  ^
../utsushi/log.hpp:49:47: note: forward declaration of template entity is
here
static std::basic_ostream& os_;
  ^
In file included from device.cpp:31:
../utsushi/log.hpp:155:36: error: instantiation of variable
'utsushi::log::basic_logger::os_'
required here,
  but no definition is available [-Werror,-Wundefined-var-template]
  basic_logger::os_ << *this;
   ^
../utsushi/log.hpp:265:23: note: in instantiation of member function
'utsushi::log::basic_message::~basic_message' requested here
  expand_named_ctors (fatal, FATAL);
  ^
../utsushi/log.hpp:49:47: note: forward declaration of template entity is
here
static std::basic_ostream& os_;
  ^
1 error generated.
gmake[4]: *** [Makefile:667: buffer.lo] Error 1



On Mon, Oct 16, 2017 at 6:16 PM, blubee blubeeme 
wrote:

> I had an idea that maybe the port was failing because of Clang compiler,
> so I looked through the porters handbook and found
> USE_GCC
>
> this prompted me to install gcc 6.2 which i think is a little overkill
> plus it also installed a few other packages as well. The build went through
> and failed at this step trying to install
>
> how can I control which version of gcc to use? I think this project should
> build fine with gcc 4.8
>
> install -m 0644 ./iconv.3 /usr/ports/converters/
> libiconv/work/stage/usr/local/man/man3/iconv.3
> install -m 0644 ./iconv_close.3 /usr/ports/converters/
>

Re: [ports]: GH_TAGNAME: how to figure out this tagname on downloadable archives?

2017-10-17 Thread blubee blubeeme 
I expanded how to get the most up to date hash that works without going
through the hassle of cloning the repo.

Best

On Tue, Oct 17, 2017, 13:01 Yuri  wrote:

> On 10/16/17 07:46, Mathieu Arnold wrote:
> > The first 7 digits may, or may not be sufficient. 7 is a magic number,
> > and should not be used. You should, instead, ask git directly what the
> > abbreviation should be with, for instance, `git log --abbrev-commit`.
> > It may give you a number that seven digits long, but it may very well
> > give you a longer one. I repeat, do not simply truncate a hash to its
> > first 7 digits, it may not be enough.
>
> `git log --abbrev-commit` solution has two shortcomings. It only protects
> against preexisting hash collisions and not from future collisions. So, the
> port's fetch can still spontaneously fail in the future as a result of a
> future commit that introduces a collision. Secondly, it requires the manual
> clone of the repository which is inconvenient. IMO, it's more practical to
> just use 7 digits, and switch to the full hash in an unlikely event when 7
> digits fail. So far, this method virtually always worked.
>
> Yuri
>
> ___
> freebsd-ports@freebsd.org mailing list
> https://lists.freebsd.org/mailman/listinfo/freebsd-ports
> To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org"
>
___
freebsd-ports@freebsd.org mailing list
https://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

2017-10-17 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
+-+
devel/aws-sdk-cpp   | 1.2.5   | 1.2.15
+-+
sysutils/racktables | 0.20.14 | 0.21.0
+-+


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

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

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