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
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
> 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
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
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
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
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
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
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
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
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
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,
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
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
style="background-image:initial;background-position:initial;background-size:initial;background-repeat:initial;background-origin:initial;background-clip:initial">Hello,
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
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.
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
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 ---
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 ---
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
>
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
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"
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
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
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,
> >
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,
27 matches
Mail list logo