Re: portmaster new development

[Michael Grimm]

Hi

> On 28. Dec 2020, at 21:41, Stefan Esser  wrote:
> 
> Poudriere works best on sufficiently powerful build servers and it
> often requires rebuilding dependencies over hours when I just want to
> test a new port before committing it.

Excuse me, but that is not true in this generality. I do run poudriere on ZFS 
in a cloud instance with 7G of memory and a CPU of 2.1 MHz. Never had to wait 
for more then one hour for recompiling *all* of my 240+ ports for STABLE-12. 
YMMV, yes, but stating that in that totality is nonsense, at least IMHO.

Regards,
Michael

___
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: portmaster new development

[Michael Grimm]

Matthias Apitz  wrote:
> El día domingo, diciembre 27, 2020 a las 09:22:42a. m. +0100, Kurt Jaeger 
> escribió:

>> That works as well. I have a checkout of the ports tree, use
>> make config to define non-default port options. This stores the
>> selected OPTIONs in /var/db/ports/, and poudriere uses those options
>> just fine.

> Re/ the options, I copy them into the jail with something like this
> procedure:
> 
> # cd /usr/ports/mail/mutt
> # make config
> 
> # mkdir -p /usr/local/etc/poudriere.d/freebsd-head-options/mail_mutt
> # cp /var/db/ports/mail_mutt/options 
> /usr/local/etc/poudriere.d/freebsd-head-options/mail_mutt
> 
> 'freebsd-head' is the name of the poudriere jail (I have some of them)
> and the ports options stay there, as well the make.conf options in
> /usr/local/etc/poudriere.d/freebsd-head-make.conf


I am following stable, and my jail's name has been set to stable.

All of poudriere's settings/configs are kept in:

/usr/local/etc/poudriere.d

Whenever I do feel the need for non-default port options, I do use poudriere's 
functionality to define and store those options:

poudriere options -n -j stable mail/postfix

These non-default options are then put into:

/usr/local/etc/poudriere.d/stable-options/mail_postfix

This way one can keep separate options for different jails in one space. But, 
there are obviously different approaches possible ;-)

Regards,
Michael

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

postfix-current marked erroneously broken for 12.1-STABLE and OpenSSL 1.1.1g

[Michael Grimm]

Hi,

postfix-current has been marked broken recently:

BROKEN_FreeBSD_11= error: OpenSSL-1.1.1 is the minimum supported 
version
 

My system:

root>   uname -v
FreeBSD 12.1-STABLE r363443 CUSTOM 

root>   openssl version
OpenSSL 1.1.1g  21 Apr 2020

root>   grep openssl /usr/local/etc/poudriere.d/stable-make.conf 
DEFAULT_VERSIONS+= ssl=openssl


The patch applied fixed it for me, but I am not sure whether it fixes it in all 
thinkable combinations of OSVERION and openssl version, though.

Regards,
Michael




Makefile-postfix-curretn.patch
Description: Binary data
___
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"

latest Makefile breaks compilation of security/clamav if base is lacking sendmail

[Michael Grimm]

Hi,

I am running 12.1-STABLE (r362940), ports head (541271) and compile all my 
ports with poudriere-devel

My /etc/src.conf contains …

WITHOUT_SENDMAIL=yes

… thus I do not have /usr/lib/libmilter.so in base.

The recent modification of security/clamav/Makefile breaks my setup (again [1], 
see 
https://lists.freebsd.org/pipermail/freebsd-ports/2018-December/115116.html).

Error message ...

checking for mi_stop in -lmilter… no
configure: error: Cannot find libmilter
...
*** Error code 1

… and after having that fixed another error:

checking for mi_stop in -lmilter… yes
checking libmilter/mfapi.h usability… no
checking libmilter/mfapi.h presence… no
checking for libmilter/mfapi.h… no
configure: error: Please install mfapi.h from the sendmail distribution
===>  Script "configure" failed unexpectedly.
...
*** Error code 1


I managed to get compilation working with the attached, surely crude and dirty 
hack (due to my lack of knowledge regarding ports Makefiles), by adding 
'MILTER_LDFLAGS= -L${LOCALBASE}/lib' and 'MILTER_CFLAGS= 
-I${LOCALBASE}/include'  in order to help finding relevant files from port 
mail/libmilter.

What worries my somehow, although clamav is working as usual, is the following 
part in poudrier's log:

checking for mi_stop in -lmilter… yes
checking libmilter/mfapi.h usability… yes
checking libmilter/mfapi.h presence… no
configure: WARNING: libmilter/mfapi.h: accepted by the compiler, 
rejected by the preprocessor!
configure: WARNING: libmilter/mfapi.h: proceeding with the compiler's 
result
checking for libmilter/mfapi.h... yes


Here my question: Is this the right way to fix this issue?

Thanks and regards,
Michael

[1] no pun intended



patch
Description: Binary data
___
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: Recent wordpress, huge compiling effort, needed?

[Michael Grimm]

Kurt Jaeger  wrote:

>> The recent update of www/wordpress ended in a compilation 'nightmare', 
>> because this port newly depends on ImageMagick:
> [...]
>> 1) Why does one need this dependency?
> 
> The wordpress install script checks if imagemagick is available, and
> I'm not sure it's still optional.


The only option available currently is whether to build/install the 
documentation

> Does your blog do lots of picture resizings etc ?

No. I am running a rather static website, only. No blog.

>> 3) If 2) is a safe way to use wordpress remotely from a web browser, then 
>> would it possible to remove the dependency by an option? (CC'd this mail to 
>> maintainer)
> 
> Give it a try to use wordpress without that RUN_DEPENDS. If it
> can be installed without it, and you don't need it...

I did install it successfully, already, and everything is working as usual. But 
I wonder if this might break something I didn't run about my tests a couple of 
minutes ago.

Regards,
Michael

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

Recent wordpress, huge compiling effort, needed?

[Michael Grimm]

Hi

I am running 12.1-STABLE (r362720), ports (head, revison 540950) and 
poudriere-devel for ports compilations.

The recent update of www/wordpress ended in a compilation 'nightmare', because 
this port newly depends on ImageMagick:

MWN> cat diff-wordpress 
2c2
< # $FreeBSD: head/www/wordpress/Makefile 534850 2020-05-10 13:51:37Z joneum $
---
> # $FreeBSD: head/www/wordpress/Makefile 540837 2020-06-29 22:24:46Z joneum $
5c5
< DISTVERSION=  5.3.3
---
> DISTVERSION=  5.4.2
20c20,21
< USE_PHP=  curl ftp gd hash json mysqli pcre tokenizer xml zip zlib
---
> USE_PHP=  curl exif fileinfo ftp gd hash json mysqli pcre tokenizer xml 
> zip zlib
> RUN_DEPENDS=  
> ${LOCALBASE}/lib/php/${PHP_EXT_DIR}/imagick.so:graphics/pecl-imagick@${PHP_FLAVOR}

Due to this dependeny the following ports need tp be compiled:

devel/llvm80
devel/gobject-introspection
graphics/ImageMagick6-nox11
graphics/cairo
graphics/mesa-libs
graphics/pecl-imagick 
net/avahi-app 
print/cups 
print/ghostscript9-agpl-base 
print/harfbuzz 
print/libraqm

(BTW: llvm80 runs into an error after 2.5 hours compilation time)

Here is my questions:

1) Why does one need this dependency?
2) I could compile and install the updated port by removing RUN_DEPENDS within 
a couple of minutes. 
   Is this a safe approach, though?
3) If 2) is a safe way to use wordpress remotely from a web browser, then would 
it possible to remove the dependency by an option? (CC'd this mail to 
maintainer)

Thanks and regards,
Michael

___
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: WITH_META_MODE and poudriere: *.meta files, where?

[Michael Grimm]

matt...@freebsd.org  wrote:
> On 23/06/2020 12:08, Michael Grimm wrote:

>> Hmm, but that information doesn't help me regarding my question above:
>> Where does poudriere store .meta files during compilations?
>> META_MODE doesn't make sense, IMHO, if this information isn't stored 
>> somewhere before being reused in subsequent compilations of a given port. Or 
>> am I mistaken?
> 
> META_MODE is a feature of building FreeBSD itself, not for building ports.  
> So, unless you're using the rather bleeding edge poudriere(1) work to be able 
> to build base system packages, poudriere is simply not going to be dealing 
> with .meta files.

Thanks, that's what I have "feared": I misunderstood the scope of bdrewery's 
commit regarding /etc/src-env.conf

> What you can do for poudriere is enable CCACHE -- as described in the 
> referenced article.  This makes quite a bit of difference to recompiling some 
> of the bigger ports like LLVM, but will have very little effect on the 
> majority of ports that only take a matter of a few seconds to compile.  Even 
> so, it's well worth doing overall.

My first reaction after anticipating increase in compilation times has been: 
activating CCACHE ;-) 
And thanks again, you clarified yet another "fear" of mine, namely, that it 
will only speed-up larger ports.

Thanks to all,
Michael

___
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: WITH_META_MODE and poudriere: *.meta files, where?

[Michael Grimm]

[restored crossposting to ML]

David Wolfskill  wrote:
> On Tue, Jun 23, 2020 at 01:08:30PM +0200, Michael Grimm wrote:

>> ...
>> Hmm, but that information doesn't help me regarding my question above:
>> 
>> Where does poudriere store .meta files during compilations?
> 
> At this point, I'm very confused.
> 
> I use META_MODE for building FreeBSD -- that's why 'WITH_META_MODE=yes'
> is in /etc/src-env.conf.
> 
> I use poudriere for building packages from the ports tree (in a clean
> environment).
> 
> There's no point in the dependency-tracking that META_MODE provides
> when using poudriere, as far as I know.  (poudriere's "granularity"
> is at the port/package level: if a package is outdated, it's removed,
> and a new one built, recursively.)
> 
> I am completely failing to understand how META_MODE and poudriere are
> involved in the same discussion.

Yeah, me as well ;-) 

That's why I want to understand, how this is supposed to work.

I cam across https://github.com/freebsd/poudriere/issues/457 recently:

"Since we stopped pulling in /etc/src-env.conf to poudriere builds, we can't 
benefit from features like WITH_META_MODE. Please implement 
poudriere.d/jail-set-src-env.conf functionality."

And bdrewery reimplemented in 
https://github.com/freebsd/poudriere/commit/1191f9f1356beaa481df9d5db3e8567449840d07

Again, I want to understand how this is supposed to work, or if I have 
misunderstood that commit completey?

Thanks, and regards,
Michael
___
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: WITH_META_MODE and poudriere: *.meta files, where?

[Michael Grimm]

Torfinn Ingolfsen  wrote:
> On Mon, Jun 22, 2020 at 8:56 PM Michael Grimm  wrote:

>> I do have activated 'WITH_META_MODE=yes' in > to>/poudriere.d/src-env.conf [1].
>> 
>> Now, I would like to double-check if poudriere is following my "advice". For 
>> buildworld I do find *.meta files in /usr/obj/…, but I do not have any clue 
>> where poudriere would keep this information for subsequent compilations?
>> 
> 
> The is some information here
> https://xmj.github.io/articles/sysadmin/builds_ccache_memcached.html
> and link to a presentation with more about (among otter things)  metamode.

Hmm, but that information doesn't help me regarding my question above:

Where does poudriere store .meta files during compilations?

META_MODE doesn't make sense, IMHO, if this information isn't stored somewhere 
before being reused in subsequent compilations of a given port. Or am I 
mistaken?

Regards,
Michael


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

WITH_META_MODE and poudriere: *.meta files, where?

[Michael Grimm]

Hi,

I do have activated 'WITH_META_MODE=yes' in /poudriere.d/src-env.conf 
[1].

Now, I would like to double-check if poudriere is following my "advice". For 
buildworld I do find *.meta files in /usr/obj/…, but I do not have any clue 
where poudriere would keep this information for subsequent compilations?

Any help in understanding this is highly appreciated.

Thanks,
Michael

[1] according 
https://github.com/freebsd/poudriere/commit/1191f9f1356beaa481df9d5db3e8567449840d07
___
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: replacement of security/ipsec-tools

[Michael Grimm]

Victor Sudakov  wrote:
> Michael Grimm wrote:

First of all, I'd like to thank all of you for your input, which helped a lot.

>> I am running ipsec-tools to implement a VPN tunnel (esp) between two hosts 
>> for years now.
>> 
>> But this statement on http://ipsec-tools.sourceforge.net makes me think 
>> about an alternative:
>>  The development of ipsec-tools has been ABANDONED. 
>>  ipsec-tools has security issues, and you should not use it. Please 
>> switch to a secure alternative! 
>> 
>> Could you provide me with links where I could find more details about the 
>> above mentioned 'security issues'? I want to find out, if my specific setup 
>> has security issues at all. Thanks.

Well, now I do know that security patches have been applied to 
security/ipsec-tools. Thus one can ignore "Please switch to a secure 
alternative!"

>> What would be a secure alternative if one is needed? 
>>  #) security/racoon2
>>  #) security/strongswan
>>  #) something else?
> 
> There was also security/isakmpd but is marked as BROKEN now.
> 
> I've been told that strongswan works on FreeBSD. I've tried installing
> strongswan, but it looks too complex and tricky in comparison with
> racoon.
> 
> If you ever find good documentation/howto  for strongswan on FreeBSD,
> please share with me.

Sorry, but I never tried strongswan as a replacement, mainly due to the reasons 
you mentioned as well: I couldn't get it running. Thus I used racoon instead.

Kurt mentioned wireguard. I could get the tunnel running, but I failed in 
getting the routing at both sites running (in my preliminary tests).

Then this mail made my day:

>> What do I need?
>>  #) a VPN tunnel between two hosts
>>  #) both local networks reachable from the remote host
> 
> That is what kernel IPSec is for, you can even do it on static keys
> without any ISAKMP daemon like racoon. See an example in if_ipsec(4).

I did install my IPSEC/racoon tunnel many years ago and missed the recent 
implementation of if_ipsec completely. 

Victor, thank you very, very much for pointing me to this interface. Now, my 
tunnel is far less complicated to implement[1], and I will no longer need 
security/ipsec-tools at all! 

[1] Following if_ipsec(4) and 
https://github.com/opnsense/core/issues/2332#issuecomment-379181820, because 
the example with "right" and "left" notation helped to understand if_ipsec(4) 
better (for me).

Thanks and regards,
Michael 


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

replacement of security/ipsec-tools

[Michael Grimm]

[X-posted, please chose the relevant ML for such a thread]

Hi,

I am running ipsec-tools to implement a VPN tunnel (esp) between two hosts for 
years now.

But this statement on http://ipsec-tools.sourceforge.net makes me think about 
an alternative:
The development of ipsec-tools has been ABANDONED. 
ipsec-tools has security issues, and you should not use it. Please 
switch to a secure alternative! 

Could you provide me with links where I could find more details about the above 
mentioned 'security issues'? I want to find out, if my specific setup has 
security issues at all. Thanks.

What would be a secure alternative if one is needed? 
#) security/racoon2
#) security/strongswan
#) something else?

What do I need?
#) a VPN tunnel between two hosts
#) both local networks reachable from the remote host

Thanks and regards,
Michael

___
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: [patch] security/ipsec-tools is broken

[Michael Grimm]

Kurt Jaeger  wrote:

>> the recent renaming of security/openssl111 to security/openssl breaks 
>> security/ipsec-tools.
>> 
>> Have a look at https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=232169 for 
>> details.
> 
> Any reason you attach a patch to a closed/fix bug from Feb. 2019 ?

I am not very familiar with bugzilla. I believed, that this would reopen the 
old bug with my old patch.

> This is a sure way to loose track of it…

Should I file a new bug report? 
Ups, just realised that you reopened bug 232169.

Thanks and regards,
Michael

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

[patch] security/ipsec-tools is broken

[Michael Grimm]

FYI,

the recent renaming of security/openssl111 to security/openssl breaks 
security/ipsec-tools.

Have a look at https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=232169 for 
details.

Regards,
Michael

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

mariadb10x-server Makefile "oddity"?

[Michael Grimm]

Hi,

I came across the following "oddity" in the Makefiles of mariadb-10x-server 
ports

mwn> grep SLAVEDIRS /usr/ports/databases/mariadb*/Makefile
/usr/ports/databases/mariadb101-server/Makefile:SLAVEDIRS=  
databases/mariadb101-client
/usr/ports/databases/mariadb102-server/Makefile:SLAVEDIRS=  
databases/mariadb102-client
/usr/ports/databases/mariadb103-server/Makefile:SLAVEDIRS=  
databases/mariadb102-client
/usr/ports/databases/mariadb104-server/Makefile:SLAVEDIRS=  
databases/mariadb102-client

I do not have enough knowledge about this ports Makefiles, but this looks odd 
to me starting at mariadb103-server, although databases/mariadb103-client and 
databases/mariadb104-client directories exist.

Thus my question: Bug or feature. If feature, why?

Regards,
Michael



___
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: security/clamav-milter fails to compile (preliminary patch included)

[Michael Grimm]

Yasuhiro KIMURA  wrote:

> Thank you for checking patch. Then I'll submit this patch to
> Bugzilla. I may take for a while but will be committed to ports
> repository.

Thanks.

"One more thing" ;-)

Your patch will work, and thinking about the maturity of libmilter, your patch 
will be an appropriate one.

I am thinking about a more "future safe" solution for security/clamav-milter:

#) add an OPTION to security/clamav-milter's Makefile whether to use 
libmilter from base or ports
#) make the default to use port mail/libmilter
#) because the latter will allow to automatically follow newest 
developments of libmilter and clamav ports

Don't get me wrong, you are the maintainer, thus, it is completely up to you!

Thanks again and kind regards,
Michael
___
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: security/clamav-milter fails to compile (preliminary patch included)

[Michael Grimm]

Yasuhiro KIMURA  wrote:
> From: Michael Grimm 

>> If I do set the option to create the milter interface (sp?) in 
>> security/clamav I do run into the same error "Cannot find libmilter".
> 
> Thank you for replay. Then please try following patch. With it
> security/clamav (and security/clamav-milter) should depend on
> mail/libmilter only when there isn't sendmail in base system.

Thank you very, very much, your patch works in my case (lacking sendmail in 
base).

mike> poudriere bulk -j stable -C security/clamav-milter

… will run to completion, see:

===>   clamav-milter-0.100.2,1 depends on shared library: libmilter.so 
- not found
===>   Installing existing package /packages/All/libmilter-8.15.2_1.txz
[stable-default-job-01] Installing libmilter-8.15.2_1...
[stable-default-job-01] Extracting libmilter-8.15.2_1: .. done
===>   clamav-milter-0.100.2,1 depends on shared library: libmilter.so 
- found (/usr/local/lib/libmilter.so)
===>   Returning to build of clamav-milter-0.100.2,1

Thank you very much. Your patch is much more elegant then my one ;-)

With kind regards,
Michael

___
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: security/clamav-milter fails to compile (preliminary patch included)

[Michael Grimm]

Yasuhiro KIMURA  wrote:
> 
> From: Michael Grimm 

>> See my last mail. I do not have sendmail compiled for base, thus I am 
>> lacking libmilter.so.X in my poudriere jail.
>> Yes, that is non-default ;-) My port has default settings.
> 
> Sorry, I read only first mail.

No need to be sorry, really.

> Then I have another question. Does build of security/clamav, master
> port of security/clamav-milter, also fail on your environment?

If I do set the option to create the milter interface (sp?) in security/clamav 
I do run into the same error "Cannot find libmilter".

I didn't try to build security/clamav without milter support, though. Due to 
obvious reasons, because I do need the milter support for postfix.

BTW: Please have a look at the mail/spamass-milter port. This port builds 
against the libmilter port as well.

Thanks and regards,
Michael

___
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: security/clamav-milter fails to compile (preliminary patch included)

[Michael Grimm]

Yasuhiro KIMURA  wrote:

> And build of security/clamav-milter succeeded with all cases.
> 
> Do you use any non-default setting about clamav-milter itself or any
> of its dependencies?

See my last mail. I do not have sendmail compiled for base, thus I am lacking 
libmilter.so.X in my poudriere jail.

Yes, that is non-default ;-) My port has default settings.

Regards,
Michael

___
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: security/clamav-milter fails to compile (preliminary patch included)

[Michael Grimm]

Carmel NY  wrote:
> On Sat, 22 Dec 2018 20:23:39 +0100, Michael Grimm stated:

>> Hmm, I do get the feeling that you misunderstand what I am telling you.

See, below.

>> Next, that poudriere jail keeps a copy of a resulting "make buildworld" run
>> of base. This jail is lacking any binary/library of ports running on my
>> machine. Thus, libmilter.so is missing as well:
>> 
>>  mike> find /usr/home/poudriere/jails/stable -name "libmilter.so*" -ls
>>  mike>  
> 
> Michael, I am certainly not a guru regarding poudriere, or system updating.

Sorry, I didn't want you to believe I am getting "personal". Sorry.

> I just now what I was told. Perhaps Matthew Seaman  or
> somebody with more knowledge about this than I can assist you.
> 
> All I know for certain is that I was told to update the poudriere jail, I
> actually deleted the old one and created a new one, and then do a forced
> rebuild of all installed ports. The following worked for me, after I created
> a new jail. Obviously, the jail name here is mine.
> 
>  portmaster --list-origins | sort -d | tee "~/portlist.txt"
>  poudriere bulk -c -f "~/portlist.txt" -j "12amd64"
>  pkg upgrade -y
> 
> ~ $ poudriere jail -l
> JAILNAME VERSION ARCH  METHOD TIMESTAMP   PATH
> 12amd64  12.0-RELEASE-p1 amd64 ftp2018-12-21 18:25:41 
> /usr/local/poudriere/jails/12amd64
> 
> ~ $ locate libmilter.so
> /usr/lib/libmilter.so
> /usr/lib/libmilter.so.6
> /usr/lib32/libmilter.so
> /usr/lib32/libmilter.so.6
> /usr/local/poudriere/jails/12amd64/usr/lib/libmilter.so
> /usr/local/poudriere/jails/12amd64/usr/lib/libmilter.so.6
> /usr/local/poudriere/jails/12amd64/usr/lib32/libmilter.so
> /usr/local/poudriere/jails/12amd64/usr/lib32/libmilter.so.6

See, that is what I was describing. You do have sendmail installed in base, and 
thus, the libmilter library will make it into your poudriere build jail, and 
security/clamav-milter will find a libmilter library -in base!- during 
compilation and will link this library. Thus, this port will compile in your 
case, because it is using libmilter.so from base, not from the mail/libmilter 
port!

FYI: I did trigger this bug because I do compile base without sendmail 
(WITHOUT_SENDMAIL=yes in /etc/src.conf)! Thus, no "chance finding" of 
/usr/lib/libmilter.so.X in base aka my poudriere jail during my compilation.

Regards,
Michael
___
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: security/clamav-milter fails to compile (preliminary patch included)

[Michael Grimm]

Carmel NY  wrote:
> On Sat, 22 Dec 2018 18:13:51 +0100, Michael Grimm stated:
>> Michael Grimm  wrote:

>>> I am using poudriere to build my ports. Within a poudriere jail used to
>>> compile the clamav-libmilter port no libmilter.so can be found by
>>> configure (see error message above) unless you tellclamav-libmilter's
>>> Makefile to depend on it and thus pre-install it in this jail.  
>> 
>> Sorry, s/clamav-libmilter/clamav-milter/g
> 
> Did you update the poudriere jail to 12.0? I had a similar problem until I
> undated it and did a forced rebuild of everything. In fact, I found it easier
> and quicker to simple delete the existing jail and create a new one.

Hmm, I do get the feeling that you misunderstand what I am telling you.

My poudriere's jail follows /usr/src. Thus at every rebuild of my OS (I do that 
every other week because I am following STABLE-12) my jail gets upgraded as 
well:

mike> poudriere jail -l
JAILNAME VERSION ARCH  METHOD   TIMESTAMP   PATH
stable   12.0-STABLE 1200500 amd64 src=/usr/src 2018-12-22 18:19:50 
/usr/home/poudriere/jails/stable

Next, that poudriere jail keeps a copy of a resulting "make buildworld" run of 
base. This jail is lacking any binary/library of ports running on my machine. 
Thus, libmilter.so is missing as well:

mike> find /usr/home/poudriere/jails/stable -name "libmilter.so*" -ls
mike>

Now, poudriere will create (cpdup) as many jails from 
/usr/home/poudriere/jails/stable as told to use builders. This "OS copy" is 
lacking the needed libmilter library as well, when poudriere is trying to build 
security/clamav-milter. And it will fail without indicating that there is a 
dependency for yet another port, namely mail/libmilter. My proposed patch will 
deal with that dependency.

YMMV, but IMHO, a port shouldn't rely on pre-installed libraries from base or 
other ports. Thus it shouldn't need a "forced rebuild of everything".

Correct me if I am mistaken, but IIRC the libmilter library used to be part of 
sendmail in base. This has been modified in FBSD 12, again IIRC [1].

Regards,
Michael


[1] https://svnweb.freebsd.org/ports?view=revision=473663
___
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: security/clamav-milter fails to compile (preliminary patch included)

[Michael Grimm]

Michael Grimm  wrote:

> I am using poudriere to build my ports. Within a poudriere jail used to 
> compile the clamav-libmilter port no libmilter.so can be found by configure 
> (see error message above) unless you tellclamav-libmilter's Makefile to 
> depend on it and thus pre-install it in this jail.

Sorry, s/clamav-libmilter/clamav-milter/g

___
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: security/clamav-milter fails to compile (preliminary patch included)

[Michael Grimm]

Carmel NY  wrote:
> On Sat, 22 Dec 2018 17:14:11 +0100, Michael Grimm stated:

>> after upgrading from STABLE-11 to STABLE-12 security/clamav-milter failed to
>> compile:
>> 
>>  configure: error: Cannot find libmilter
>>  ===>  Script "configure" failed unexpectedly.  
>>  Please report the problem to y...@utahime.org [maintainer] and
>>  attach the
>>  
>> "/wrkdirs/usr/ports/security/clamav-milter/work/clamav-0.100.2/config.log"
>>  including the output of the failure of your make command. Also, it
>>  might be a good idea to provide an overview of all packages
>>  installed on your system (e.g. a /usr/local/sbin/pkg-static info -g
>>  -Ea). *** Error code 1
>> 
>>  Stop.

This happens when compiled by poudriere.

> Clamav-milter updated fine for me once I updated all of the installed ports
> on my system. I am assuming that you did update your ports tree and then
> update all of the ports on your system. If you don't, clamav-milter, and
> several other ports, will fail.

I am not quite sure if I do understand you correctly.

I am using poudriere to build my ports. Within a poudriere jail used to compile 
the clamav-libmilter port no libmilter.so can be found by configure (see error 
message above) unless you tell clamav-libmilter's Makefile to depend on it and 
thus pre-install it in this jail.

Regards,
Michael

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

security/clamav-milter fails to compile (preliminary patch included)

[Michael Grimm]

Hi,

after upgrading from STABLE-11 to STABLE-12 security/clamav-milter failed to 
compile:

configure: error: Cannot find libmilter
===>  Script "configure" failed unexpectedly.
Please report the problem to y...@utahime.org [maintainer] and attach 
the

"/wrkdirs/usr/ports/security/clamav-milter/work/clamav-0.100.2/config.log"
including the output of the failure of your make command. Also, it 
might be
a good idea to provide an overview of all packages installed on your 
system
(e.g. a /usr/local/sbin/pkg-static info -g -Ea).
*** Error code 1

Stop.

It looks to me that starting STABLE-12 one needs to add library dependency to 
mail/libmilter:

___ patch _
--- security/clamav/Makefile.old2018-12-22 16:43:04.91388 +0100
+++ security/clamav/Makefile2018-12-22 16:51:53.618789000 +0100
@@ -13,7 +13,8 @@
 LICENSE_FILE=  ${WRKSRC}/COPYING
 
 LIB_DEPENDS=   libltdl.so:devel/libltdl \
-   libcurl.so:ftp/curl
+   libcurl.so:ftp/curl \
+   libmilter.so:mail/libmilter
 
 USES=  cpe gmake gnome libtool ncurses pathfix pkgconfig ssl
 USE_RC_SUBR=   clamav-clamd clamav-freshclam
___ patch _

This patch works for me. 

BUT: I do not know if this is the right way to fix it, because this patch is 
applied to security/clamav which in turn is used from security/clamav-milter by 
simply adding OPTIONS_SLAVE+=  MILTER. Thus a libmilter dependency will be 
added to users of plain security/clamav port as well. 

Regards,
Michael

___
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: HOWTO automatically follow PHP default versions switches?

[Michael Grimm]

Mathieu Arnold  wrote:
> On Sun, Nov 04, 2018 at 05:40:35PM +0100, Michael Grimm wrote:

>> Question: Is there a way to automatically follow default version switches of 
>> PHP without having to touch those definitions above?
>> 
>> I cannot find something like meta-ports of lang/php-default and 
>> land/php-extensions-default, thus I do believe that it cannot be done. 
>> Correct?
> 
> It would not be appropriate for a port inside the ports tree, but you
> can simply replace all occurrences of 72 by ${PHP_DEFAULT}.

Thank you very much! That was a very helpful hint, indeed, and it works 
perfectly well, great.

Regards,
Michael

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

HOWTO automatically follow PHP default versions switches?

[Michael Grimm]

Hi,

I am using poudriere for compiling ports, and I do have the following setting 
in my corresponding make.conf:

DEFAULT_VERSIONS+=php=72

In addition I do have two local meta-ports with PHP definitions installed in 
order to provide PHP and PHP depending ports in service jails:

PORTNAME=   local-www
CATEGORIES= local
[snip]
RUN_DEPENDS+=   roundcube-php72>0:${PORTSDIR}/mail/roundcube@php72
RUN_DEPENDS+=   
roundcube-sieverules-php72>0:${PORTSDIR}/mail/roundcube-sieverules@php72

and

PORTNAME=   local-www2
CATEGORIES= local
[snip]
RUN_DEPENDS+=   php72-extensions>0:${PORTSDIR}/lang/php72-extensions


Question: Is there a way to automatically follow default version switches of 
PHP without having to touch those definitions above?

I cannot find something like meta-ports of lang/php-default and 
land/php-extensions-default, thus I do believe that it cannot be done. Correct?

Thanks in advance and regards,
Michael

___
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: beadm-1.2.8: erroneous beadm create

[Michael Grimm]

Bryan Drewery  wrote:
> 
> On 7/8/2018 8:21 AM, Michael Grimm wrote:

>> FYI: The author of beadm has fixed this issue, and he will include his fix 
>> in the upcoming beadm-1.2.9 release.
> 
> Updated.

FYI: The author has fixed the version string in 1.2.9, thus SHA256 has changed!

Regards,
Michael



___
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: beadm-1.2.8: erroneous beadm create

[Michael Grimm]

Michael Grimm  wrote:

> Well, I do see the point of embedding variables with ", but I do also believe 
> that checking for a null string and removing that resulting …
>   -o =""
> … before applying the final 'zfs clone' command with it would be a much 
> better patch. 

FYI: The author of beadm has fixed this issue, and he will include his fix in 
the upcoming beadm-1.2.9 release.

Regards,
Michael


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

beadm-1.2.8: erroneous beadm create

[Michael Grimm]

Hi --

I happen to run a boot environment with two zfs filesystems without any zfs 
property defined that trigger an error with the latest beadm-1.2.8.

Example BE of mine:
zp0/ROOT/11r33605613.5G463M 95.1M  27.2G972M  
2.15x  /
zp0/ROOT/11r336056/_jails  672M672M 0  1.09G   1.09G  
1.75x  /usr/home/jails
zp0/ROOT/11r336056/usr11.7G   6.42G 3.40G  24.2G   13.7G  
2.22x  /usr
zp0/ROOT/11r336056/usr/local   321M299M 21.8M   505M484M  
1.77x  /usr/local
zp0/ROOT/11r336056/usr/src1.60G   1.51G 96.2M  2.91G   2.82G  
2.13x  /usr/src
zp0/ROOT/11r336056/var 586M577M 8.64M   779M764M  
1.33x  /var

Both zp0/ROOT/11r336056/usr/local and zp0/ROOT/11r336056/usr/src do not have 
any zfs property defined, thus the new beadm-1.2.8 will run into an error when 
trying to create a new BE:
root> beadm create B1
cannot create 'zp0/ROOT/B1/usr/local': invalid property ''

Ok, after adding some debugging code and a comparison with the previous version 
I found the cause:
root> ./beadm-1.2.8-patched create B1
zp0/ROOT/11r336056  |  -o snapdir="hidden" -o mountpoint="/"
zp0/ROOT/11r336056  |  -o mountpoint="/usr/home/jails"
zp0/ROOT/11r336056  |  -o snapdir="hidden" -o setuid="on" -o 
mountpoint="/usr"
zp0/ROOT/11r336056  |  -o =""
cannot create 'zp0/ROOT/B1/usr/local': invalid property ''

The previous version didn't trigger missing zfs properties because it doesn't 
add an empty string "" to '-o':
root> ./beadm-1.2.8-patched create B1
zp0/ROOT/11r336056  |  -o snapdir=hidden -o mountpoint=/
zp0/ROOT/11r336056  |  -o mountpoint=/usr/home/jails
zp0/ROOT/11r336056  |  -o snapdir=hidden -o setuid=on -o mountpoint=/usr
zp0/ROOT/11r336056  |  -o =
zp0/ROOT/11r336056  |  -o mountpoint=/usr/src
zp0/ROOT/11r336056  |  -o snapdir=hidden -o mountpoint=/var
Created successfully

Workaround to me is the following patch (beadm-1.2.7 approach):

[snip]
root> diff -u beadm-1.2.8 beadm-1.2.8-patched
--- beadm-1.2.8 2018-07-07 16:17:19.231902000 +0200
+++ beadm-1.2.8-patched 2018-07-07 22:00:19.740611000 +0200
@@ -213,7 +213,7 @@
 local OPTS=""
 while read NAME PROPERTY VALUE
 do
-  local OPTS="-o ${PROPERTY}=\"${VALUE}\" ${OPTS}"
+  local OPTS="-o ${PROPERTY}=${VALUE} ${OPTS}"
 done << EOF
 $( zfs get -o name,property,value -s local,received -H all ${FS} | awk '!/[\t 
]canmount[\t ]/' )
 EOF
[snap]

Well, I do see the point of embedding variables with ", but I do also believe 
that checking for a null string and removing that resulting …
-o =""
… before applying the final 'zfs clone' command with it would be a much better 
patch. 

Regards,
Michael

___
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: py-fail2ban turned silent after syslogd rollout (r335059, stable/11)

[Michael Grimm]

On 22. Jun 2018, at 22:28, Ed Schouten  wrote:
> 2018-06-22 22:06 GMT+02:00 Michael Grimm :

>> After applying your patch:
>>Jun 22 21:22:01 HOSTNAME  [31033]: NOTICE [JAILNAME] 
>> Unban x.x.x.x
>> 
>> Watch: 'fail2ban.actions' -the service- is missing.
> 
> That's likely due to the fact that it now interprets the first word in
> the message as the remote hostname, which gets discarded.
> 
> Attached is a somewhat refined patch that only tries to parse the
> hostname in remote messages if they are preceded by a timestamp. If
> the timestamp is missing, it assumes the entire payload is the
> message. Can you give this one a try? Thanks!

Great, you fixed it again in very short time, and I really do appreciate this!

Now with patch v2:
Jun 22 22:39:59 HOSTNAME  fail2ban.actions [72605]: 
NOTICE [JAILNAME] Restore Ban x.x.x.x

Thank you very, very much,
Michael

___
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: py-fail2ban turned silent after syslogd rollout (r335059, stable/11)

[Michael Grimm]

On 22. Jun 2018, at 21:26, Michael Grimm  wrote:
> On 22. Jun 2018, at 21:11, Ed Schouten  wrote:

>> Michael, Marek, could you please give this patch a try? Thanks!
> 
> Recompiled world (FreeBSD 11.2-STABLE r335532), substituted syslogd with the 
> re-compiled one, and:
> 
> Thank you! Your patch is working w.r.t. fail2ban logging to SYSLOG. Perfect!

Now I realised that there is a minor glitch:

logfile+logger:
Jun 22 19:01:48 HOSTNAME  fail2ban.filter: 2018-06-22 
19:01:48,637 fail2ban.actions[85544]: NOTICE  [JAILNAME] Unban x.x.x.x

Old syslogd before MFC:
May 30 15:39:41  HOSTNAME fail2ban.actions [929]: NOTICE 
[JAILNAME] Unban x.x.x.x

After applying your patch:
Jun 22 21:22:01 HOSTNAME  [31033]: NOTICE [JAILNAME] 
Unban x.x.x.x

Watch: 'fail2ban.actions' -the service- is missing.

Regards,
Michael

___
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: py-fail2ban turned silent after syslogd rollout (r335059, stable/11)

[Michael Grimm]

On 22. Jun 2018, at 21:11, Ed Schouten  wrote:

> Gleb, what are your thoughts on the attached patch? It alters syslogd
> to let the 'legacy' RFC 3164 parser also accept messages without a
> timestamp. The time on the syslogd server will be used instead.
> 
> Michael, Marek, could you please give this patch a try? Thanks!

Recompiled world (FreeBSD 11.2-STABLE r335532), substituted syslogd with the 
re-compiled one, and:

Thank you! Your patch is working w.r.t. fail2ban logging to SYSLOG. Perfect!

Thank you very much for this fast fix, and regards,
Michael


___
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: py-fail2ban turned silent after syslogd rollout (r335059, stable/11)

[Michael Grimm]

On 22. Jun 2018, at 17:59, Marek Zarychta  wrote:

> Could you please give any advice or workaround for this issue?

I switched to a workaround for the time being which you might use as well in a 
similar way:

#) configure fail2ban to use /var/log/faillog
#) run something like that in the background:

nohup tail -q -F /var/log/fail2ban.log | logger -t fail2ban.filter -p 
daemon.notice &

#) to let this workaround survive a reboot you need to use a script fired up 
from /etc/rc.d

Regards,
Michael

___
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: py-fail2ban turned silent after syslogd rollout (r335059, stable/11)

[Michael Grimm]

Marek Zarychta  wrote:
> On Fri, Jun 22, 2018 at 03:12:05PM +0200, Michael Grimm wrote:

>> Hi,
>> 
>> this is 11.2-STABLE (r335532), and I am referring to the recent MFC of 
>> syslogd modifications [1]. 
>> 
>> Because I cannot judge whether fail2ban lacks support for the renewed 
>> syslogd or syslogd has an issue in receiving fail2ban messages I do 
>> crosspost this mail to ports and stable.
>> 
>> I do have fail2ban configured to report to SYSLOG:
>> 
>>  logtarget = SYSLOG
>>  syslogsocket = auto
>> 
>> But now, after upgrading to the new syslogd fail2ban refuses to report to 
>> syslogd; no single message gets recorded [2].
>> 
>> I did try to modify the syslogsocket setting to /var/run/log without 
>> success. Pointing logtarget to a regular files tells me that fail2ban is 
>> running as expected, it only lacks reporting to SYSLOG.
>> 
>> #) Does anyone else has running py-fail2ban at >= r335059 and can confirm my 
>> observations? 
>> #) Any ideas how to debug this issue?
>> 
>> Thank you in advance and regards,
>> Michael
>> 
>> 
>> [1] 
>> https://svnweb.freebsd.org/base/stable/11/usr.sbin/syslogd/Makefile?revision=335059=markup=file
>> [2] both syslogd and fail2ban are running at the host, thus another issue 
>> with syslogd fixed in 
>>https://svnweb.freebsd.org/base?view=revision=file=335314 
>> does not apply
>> 
> 
> This is probably connected with the lack of handling of non-RFC
> compliant timestamps. 
> 
> My syslog server also suffers from this issue. It stopped logging
> messages from old Cisco equipment and some newer Netgear switches.
> Running it in debug mode gives some clue:
> 
> Failed to parse TIMESTAMP from x.x.x.x: 12403: Jun 22 17:31:38 CEST:
> %LINEPROTO-5-UPDOWN: Line protocol on Interface FastEthernet0/17,
> changed state to down

Ah, yes! Haven't thought about running syslogd in debugging mode:

Failed to parse TIMESTAMP from x.x.x.x: fail2ban.filter [79598]: INFO 
[…]

> Could you please give any advice or workaround for this issue?

I cannot answer whether it might be possible to either tell syslogd to accept 
legacy timestamps [1] or configure fail2ban (or your applications) to switch to 
using RFC5424 compliant timestamps.

[1] I did try to set '-O rfc3164' starting syslogd to no avail

Anyone?

Regards,
Michael



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

py-fail2ban turned silent after syslogd rollout (r335059, stable/11)

[Michael Grimm]

Hi,

this is 11.2-STABLE (r335532), and I am referring to the recent MFC of syslogd 
modifications [1]. 

Because I cannot judge whether fail2ban lacks support for the renewed syslogd 
or syslogd has an issue in receiving fail2ban messages I do crosspost this mail 
to ports and stable.

I do have fail2ban configured to report to SYSLOG:

logtarget = SYSLOG
syslogsocket = auto

But now, after upgrading to the new syslogd fail2ban refuses to report to 
syslogd; no single message gets recorded [2].

I did try to modify the syslogsocket setting to /var/run/log without success. 
Pointing logtarget to a regular files tells me that fail2ban is running as 
expected, it only lacks reporting to SYSLOG.

#) Does anyone else has running py-fail2ban at >= r335059 and can confirm my 
observations? 
#) Any ideas how to debug this issue?

Thank you in advance and regards,
Michael


[1] 
https://svnweb.freebsd.org/base/stable/11/usr.sbin/syslogd/Makefile?revision=335059=markup=file
[2] both syslogd and fail2ban are running at the host, thus another issue with 
syslogd fixed in 
https://svnweb.freebsd.org/base?view=revision=file=335314 
does not apply


___
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 11.1-STABLE #0 r331865: geomWatch compilation fails

[Michael Grimm]

Dimitry Andric <d...@freebsd.org> wrote:
> On 3 Apr 2018, at 21:23, Michael Grimm <trash...@ellael.org> wrote:
>> 
>> Dimitry Andric <d...@freebsd.org> wrote:
>>> On 3 Apr 2018, at 19:34, Michael Grimm <trash...@ellael.org> wrote:

>>>> Well, this time, after adding "USE_CXXSTD=gnu++98" into that port's 
>>>> Makefile, poudriere has not been able to compile that port. Sadly. But 
>>>> thank you anyway.
>>> 
>>> Please try the patches in <https://bugs.freebsd.org/227209>.
>> 
>> I did apply your patch "Make geomWatch obey USE_CXXSTD=gnu++98 option" to 
>> sysutils/geomWatch/files/patch-Makefile and "USE_CXXSTD=gnu++98" to 
>> sysutils/geomWatch/Makefile, and it compiles successfully. Thanks.
>> 
>> P.S. Do you want me to apply Harald's patch "zfs-sysevent.h: Insert 
>> whitespaces for C++11 compile werror." in addition and/or as well?
> 
> Either Harald's patch, or mine, both is superfluous.

I did apply both patches to vanilla sysutils/geomWatch ports, respectively.
Both patches are compiling this port successfully.

Congratulations and regards,
Michael


___
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 11.1-STABLE #0 r331865: mariadb102-server-10.2.14 compilation fails

[Michael Grimm]

Dimitry Andric <d...@freebsd.org> wrote
> On 3 Apr 2018, at 21:27, Michael Grimm <trash...@ellael.org> wrote:
>> 
>> Dimitry Andric <d...@freebsd.org> wrote:
>>>> On 3 Apr 2018, at 19:34, Michael Grimm <trash...@ellael.org> wrote:

>>>> With "USE_CXXSTD=gnu++98" added into that port's Makefile poudriere has 
>>>> been able to compile that port. Thank you.
>>> 
>>> Alternatively, please try the patch in <https://bugs.freebsd.org/227209>.
>> 
>> But that patch addresses geomWatch and not mariadb102-server, right?
> 
> Sorry, pasted the wrong link.  Try this instead: 
> <https://bugs.freebsd.org/227244>.

Ok, I did apply both patches, either "USE_CXXSTD=gnu++98" to Makefile, or your 
patch creating files/patch-storage_connect_tabjson.cpp, only. 
Both patches were applied to vanilla databases/mariadb102-server ports, 
respectively.
And each patch is compiling this port successfully.

Congratulations and regards,
Michael
___
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 11.1-STABLE #0 r331865: mariadb102-server-10.2.14 compilation fails

[Michael Grimm]

Dimitry Andric <d...@freebsd.org> wrote:
>> On 3 Apr 2018, at 19:34, Michael Grimm <trash...@ellael.org> wrote:

>> With "USE_CXXSTD=gnu++98" added into that port's Makefile poudriere has been 
>> able to compile that port. Thank you.
> 
> Alternatively, please try the patch in <https://bugs.freebsd.org/227209>.

But that patch addresses geomWatch and not mariadb102-server, right?

Regards,
Michael

___
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 11.1-STABLE #0 r331865: geomWatch compilation fails

[Michael Grimm]

Dimitry Andric <d...@freebsd.org> wrote:
> On 3 Apr 2018, at 19:34, Michael Grimm <trash...@ellael.org> wrote:

>> Well, this time, after adding "USE_CXXSTD=gnu++98" into that port's 
>> Makefile, poudriere has not been able to compile that port. Sadly. But thank 
>> you anyway.
> 
> Please try the patches in <https://bugs.freebsd.org/227209>.

I did apply your patch "Make geomWatch obey USE_CXXSTD=gnu++98 option" to 
sysutils/geomWatch/files/patch-Makefile and "USE_CXXSTD=gnu++98" to 
sysutils/geomWatch/Makefile, and it compiles successfully. Thanks.

P.S. Do you want me to apply Harald's patch "zfs-sysevent.h: Insert whitespaces 
for C++11 compile werror." in addition and/or as well?

Regards,
Michael

___
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 11.1-STABLE #0 r331865: mariadb102-server-10.2.14 compilation fails

[Michael Grimm]

Dimitry Andric <d...@freebsd.org> wrote:
> On 2 Apr 2018, at 21:40, Michael Grimm <trash...@ellael.org> wrote:

>> since the recent upgrade of llvm et al in STABLE-11.1 
>> mariadb102-server-10.2.14  fails to compile (poudriere):
>> 
>> --- storage/connect/CMakeFiles/connect.dir/all ---
>> --- storage/connect/CMakeFiles/connect.dir/table.cpp.o ---
>> --- storage/connect/CMakeFiles/connect.dir/tabjson.cpp.o ---
>> /wrkdirs/usr/ports/databases/mariadb102-server/work/mariadb-10.2.14/storage/connect/tabjson.cpp:198:10:
>>  error: cannot initialize return object of type 'int' with an rvalue of type 
>> 'nullptr_t'
>>   return NULL;
>>  ^~~~
> 
> The code is likely buggy, but you can try adding USE_CXXSTD=gnu++98 in
> the port Makefile as a workaround.

With "USE_CXXSTD=gnu++98" added into that port's Makefile poudriere has been 
able to compile that port. Thank you.

Regards,
Michael

___
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 11.1-STABLE #0 r331865: geomWatch compilation fails

[Michael Grimm]

Dimitry Andric <d...@freebsd.org> wrote:
> On 2 Apr 2018, at 21:33, Michael Grimm <trash...@ellael.org> wrote:

>> since the recent upgrade of llvm et al in STABLE-11.1 geomWatch fails to 
>> compile (poudriere):
>> 
>> In file included from geomWatch.cpp:41:
>> In file included from ./zpool.hpp:35:
>> In file included from 
>> zfs/v28/cddl/contrib/opensolaris/lib/libzfs/common/libzfs.h:38:
>> In file included from 
>> zfs/v28/sys/cddl/contrib/opensolaris/uts/common/fs/zfs/sys/zfs_ioctl.h:30:
>> In file included from 
>> zfs/v28/sys/cddl/contrib/opensolaris/uts/common/fs/zfs/sys/zio.h:29:
>> In file included from 
>> zfs/v28/cddl/contrib/opensolaris/lib/libzpool/common/sys/zfs_context.h:83:
>> zfs/v28/sys/cddl/contrib/opensolaris/uts/common/sys/sysevent.h:79:37: error: 
>> invalid suffix on literal; C++11 requires a space between literal and 
>> identifier [-Wreserved-user-defined-literal]
>> #define SUNW_KERN_PUB   SUNW_VENDOR":"SE_KERN_PUB
>> ^
>> zfs/v28/sys/cddl/contrib/opensolaris/uts/common/sys/sysevent.h:80:36: error: 
>> invalid suffix on literal; C++11 requires a space between literal and 
>> identifier [-Wreserved-user-defined-literal]
>> #define SUNW_USR_PUBSUNW_VENDOR":"SE_USR_PUB
>> ^
> 
> This can be fixed either by adding spaces before the double quotes, or
> it can be worked around by adding USE_CXXSTD=gnu++98 in the port
> Makefile.

Well, this time, after adding "USE_CXXSTD=gnu++98" into that port's Makefile, 
poudriere has not been able to compile that port. Sadly. But thank you anyway.

Regards,
Michael

___
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 11.1-STABLE #0 r331865: mariadb102-server-10.2.14 compilation fails

[Michael Grimm]

Hi,

since the recent upgrade of llvm et al in STABLE-11.1 mariadb102-server-10.2.14 
 fails to compile (poudriere):



--- storage/connect/CMakeFiles/connect.dir/all ---
--- storage/connect/CMakeFiles/connect.dir/table.cpp.o ---
--- storage/connect/CMakeFiles/connect.dir/tabjson.cpp.o ---
/wrkdirs/usr/ports/databases/mariadb102-server/work/mariadb-10.2.14/storage/connect/tabjson.cpp:198:10:
 error: cannot initialize return object of type 'int' with an rvalue of type 
'nullptr_t'
return NULL;
   ^~~~
/usr/include/sys/_null.h:35:14: note: expanded from macro 'NULL'
#define NULLnullptr
^~~
/wrkdirs/usr/ports/databases/mariadb102-server/work/mariadb-10.2.14/storage/connect/tabjson.cpp:246:11:
 error: cannot initialize return object of type 'int' with an rvalue of type 
'nullptr_t'
return NULL;
   ^~~~
/usr/include/sys/_null.h:35:14: note: expanded from macro 'NULL'
#define NULLnullptr
^~~
/wrkdirs/usr/ports/databases/mariadb102-server/work/mariadb-10.2.14/storage/connect/tabjson.cpp:253:12:
 error: cannot initialize return object of type 'int' with an rvalue of type 
'nullptr_t'
return NULL;
   ^~~~
/usr/include/sys/_null.h:35:14: note: expanded from macro 'NULL'
#define NULLnullptr
^~~
/wrkdirs/usr/ports/databases/mariadb102-server/work/mariadb-10.2.14/storage/connect/tabjson.cpp:272:12:
 error: cannot initialize return object of type 'int' with an rvalue of type 
'nullptr_t'
return NULL;
   ^~~~
/usr/include/sys/_null.h:35:14: note: expanded from macro 'NULL'
#define NULLnullptr
^~~
/wrkdirs/usr/ports/databases/mariadb102-server/work/mariadb-10.2.14/storage/connect/tabjson.cpp:279:12:
 error: cannot initialize return object of type 'int' with an rvalue of type 
'nullptr_t'
return NULL;
   ^~~~
/usr/include/sys/_null.h:35:14: note: expanded from macro 'NULL'
#define NULLnullptr
^~~
--- storage/spider/CMakeFiles/spider.dir/all ---
--- storage/spider/CMakeFiles/spider.dir/ha_spider.cc.o ---
In file included from 
/wrkdirs/usr/ports/databases/mariadb102-server/work/mariadb-10.2.14/storage/spider/ha_spider.cc:28:
In file included from 
/wrkdirs/usr/ports/databases/mariadb102-server/work/mariadb-10.2.14/sql/sql_class.h:4913:
/wrkdirs/usr/ports/databases/mariadb102-server/work/mariadb-10.2.14/include/myisam.h:376:48:
 warning: 'register' storage class specifier is deprecated and incompatible 
with C++17 [-Wdeprecated-register]
  int (*write_keys)(struct st_mi_sort_param *, register uchar **,
   ^
/wrkdirs/usr/ports/databases/mariadb102-server/work/mariadb-10.2.14/include/myisam.h:386:30:
 warning: 'register' storage class specifier is deprecated and incompatible 
with C++17 [-Wdeprecated-register]
int chk_del(HA_CHECK *param, register MI_INFO *info, ulonglong test_flag);
 ^
/wrkdirs/usr/ports/databases/mariadb102-server/work/mariadb-10.2.14/include/myisam.h:390:32:
 warning: 'register' storage class specifier is deprecated and incompatible 
with C++17 [-Wdeprecated-register]
int mi_repair(HA_CHECK *param, register MI_INFO *info,
   ^
/wrkdirs/usr/ports/databases/mariadb102-server/work/mariadb-10.2.14/include/myisam.h:392:36:
 warning: 'register' storage class specifier is deprecated and incompatible 
with C++17 [-Wdeprecated-register]
int mi_sort_index(HA_CHECK *param, register MI_INFO *info, char * name);
   ^
/wrkdirs/usr/ports/databases/mariadb102-server/work/mariadb-10.2.14/include/myisam.h:393:40:
 warning: 'register' storage class specifier is deprecated and incompatible 
with C++17 [-Wdeprecated-register]
int mi_repair_by_sort(HA_CHECK *param, register MI_INFO *info,
   ^
/wrkdirs/usr/ports/databases/mariadb102-server/work/mariadb-10.2.14/include/myisam.h:395:41:
 warning: 'register' storage class specifier is deprecated and incompatible 
with C++17 [-Wdeprecated-register]
int mi_repair_parallel(HA_CHECK *param, register MI_INFO *info,
^
In file included from 
/wrkdirs/usr/ports/databases/mariadb102-server/work/mariadb-10.2.14/storage/spider/ha_spider.cc:28:
In file included from 
/wrkdirs/usr/ports/databases/mariadb102-server/work/mariadb-10.2.14/sql/sql_class.h:4916:
/wrkdirs/usr/ports/databases/mariadb102-server/work/mariadb-10.2.14/include/maria.h:369:44:
 warning: 'register' storage class specifier is deprecated and incompatible 
with C++17 [-Wdeprecated-register]
int maria_repair_parallel(HA_CHECK *param, register MARIA_HA *info,

FreeBSD 11.1-STABLE #0 r331865: geomWatch compilation fails

[Michael Grimm]

Hi,

since the recent upgrade of llvm et al in STABLE-11.1 geomWatch fails to 
compile (poudriere):

In file included from geomWatch.cpp:41:
In file included from ./zpool.hpp:35:
In file included from 
zfs/v28/cddl/contrib/opensolaris/lib/libzfs/common/libzfs.h:38:
In file included from 
zfs/v28/sys/cddl/contrib/opensolaris/uts/common/fs/zfs/sys/zfs_ioctl.h:30:
In file included from 
zfs/v28/sys/cddl/contrib/opensolaris/uts/common/fs/zfs/sys/zio.h:29:
In file included from 
zfs/v28/cddl/contrib/opensolaris/lib/libzpool/common/sys/zfs_context.h:83:
zfs/v28/sys/cddl/contrib/opensolaris/uts/common/sys/sysevent.h:79:37: error: 
invalid suffix on literal; C++11 requires a space between literal and 
identifier [-Wreserved-user-defined-literal]
#define SUNW_KERN_PUB   SUNW_VENDOR":"SE_KERN_PUB
  ^
   
zfs/v28/sys/cddl/contrib/opensolaris/uts/common/sys/sysevent.h:80:36: error: 
invalid suffix on literal; C++11 requires a space between literal and 
identifier [-Wreserved-user-defined-literal]
#define SUNW_USR_PUBSUNW_VENDOR":"SE_USR_PUB
  ^
   
1 warning and 2 errors generated.
*** [geomWatch] Error code 1

make[1]: stopped in /wrkdirs/usr/ports/sysutils/geomWatch/work/geomWatch-1.3.0
1 error

Regards,
Michael

___
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: Logitechmediaserver fails to build

[Michael Grimm]

Eric Masson  wrote:

> Seems Logitech Media Server doesn't build on 11-STABLE (I had to rebuild
> it after perl5 defaults from 5.24 to 5.26).
> 
> root@newsrv:/usr/ports/audio/logitechmediaserver # make
[…]
> cd: 
> /storage/work/ports/build/usr/ports/audio/logitechmediaserver/work/slimserver-vendor-1463b00/CPAN/build:
>  No such file or directory
> *** Error code 2
> 
> Stop.
> make[1]: stopped in /usr/ports/audio/logitechmediaserver
> *** Error code 1
> 
> Stop.
> make: stopped in /usr/ports/audio/logitechmediaserver
> root@newsrv:/usr/ports/audio/logitechmediaserver #

FYI: Same here, starting a couple of days ago.

Regarda,
Michael

___
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: perl5.24 build failing on a new 11.1-STABLE install

[Michael Grimm]

Bob Willcox  wrote:
> On Wed, Mar 28, 2018 at 12:45:27PM +, Antoine Brodin wrote:

>> svn merge -c -331551 .

Thanks. Done that ...

> I've done the above svn command and am now rebuilding world on
> my system. Should be able to give it a try this evening when I get home.

… rebuilt world and could rebuilt all ports successfully.

Thanks to all that helped here or off-line,
Michael

P.S. I just saw that r331551 has been reverted officially.

___
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: perl5.24 build failing on a new 11.1-STABLE install

[Michael Grimm]

Antoine Brodin <anto...@freebsd.org> wrote:

> On Wed, Mar 28, 2018 at 12:04 PM, Michael Grimm <trash...@ellael.org> wrote:

>> FreeBSD 11.1-STABLE #0 r331660: Wed Mar 28 08:36:15 CEST 2018 
>> root@mer-waases:/usr/obj/usr/src/sys/CUSTOM

> You can try to revert https://svnweb.freebsd.org/changeset/base/331551

Please excuse my ignorance, but I haven't done that before. After a quick scan 
in svn help I came up with:

svn merge -r 331660:331551

Is this correct?
What I want to achieve is keeping all commits besides 331551

Thanks and regards,
Michael

___
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: perl5.24 build failing on a new 11.1-STABLE install

[Michael Grimm]

Bob Willcox  wrote:

> --- perl ---
> cc -o perl -lpthread -Wl,-E  -fstack-protector-strong -L/usr/local/lib 
> -Wl,-R/usr/local/lib/perl5/5.24/mach/CORE maindtrace/perlmain.o dtrace_main.o 
>  libperl.so.5.24.3 `cat ext.libs` -lpthread -lm -lcrypt -lutil
> maindtrace/perlmain.o: In function `main':
> perlmain.c:(.text+0xa4): undefined reference to `perl_parse'
> perlmain.c:(.text+0xb4): undefined reference to `perl_run'
> perlmain.c:(.text+0x128): undefined reference to `perl_destruct'
> cc: error: linker command failed with exit code 1 (use -v to see invocation)
> *** [perl] Error code 1

I did run into this issue as well using poudriere to rebuild all ports. 
Same error message. 
Both FBSD systems of mine are hit by the very same error.

> The system 'uname -a' is:
> 
> FreeBSD exar.immure.com 11.1-STABLE FreeBSD 11.1-STABLE #0 r331606: Tue Mar 
> 27 07:27:39 CDT 2018

FreeBSD 11.1-STABLE #0 r331660: Wed Mar 28 08:36:15 CEST 2018 
root@mer-waases:/usr/obj/usr/src/sys/CUSTOM 


> Anyone have any idea as to what may be wrong with or missing on this system?

Sadly, so.

Regards,
Michael

___
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: 'pkg upgrade -f spamassassin' stops but doesn't restart spamd

[Michael Grimm]

Kevin Oberman  wrote:
> On Sun, Jan 7, 2018 at 7:10 AM, Miroslav Lachman <000.f...@quip.cz> wrote:

>> There are no consensus about what services should do on deinstall or
>> upgrade. That's why there is such a mess in ports / packages.
>> Some did nothing (my preferred way), some stop (but did not start) the
>> service,
[…]
> Beg pardon, but I am aware of this being discussed twice on this list and
> both times there was a clear consensus in both cases that it was
> unacceptable or a port/package upgrade to touch running daemons.  There
> were arguments that some port might make changes in underlying files that
> could break a daemon in some way, though I can't recall any actual examples.
> 
> The only real argument was that leaving a daemon with a serious
> vulnerability running was not acceptable. A competent admin should never
> let this happen, but I'm sure it has.

FTR: I have filed PR 225030 on this.

Thanks and regards,
Michael


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

'pkg upgrade -f spamassassin' stops but doesn't restart spamd

[Michael Grimm]

Hi,

I am following 11-STABLE and therefore upgrading my system quite frequently. 
During that process I do recompile all ports installed by poudriere and upgrade 
all ports after reboot.

Today I stumbled over an IMHO weird behaviour of the spamassassin's 
installation process, that stops a running spamd daemon without restarting. 
Even worse, the user will not be informed about that procedure:

mail> /usr/local/etc/rc.d/sa-spamd status
spamd is running as pid 13859.

mail> pkg upgrade -fy spamassassin
Updating poudriere repository catalogue...
poudriere repository is up to date.
All repositories are up to date.
Checking integrity... done (0 conflicting)
The following 1 package(s) will be affected (of 0 checked):

Installed packages to be REINSTALLED:
spamassassin-3.4.1_11 [poudriere]

Number of packages to be reinstalled: 1
[mail] [1/1] Reinstalling spamassassin-3.4.1_11...
===> Creating groups.
Using existing group 'spamd'.
===> Creating users
Using existing user 'spamd'.
[mail] [1/1] Extracting spamassassin-3.4.1_11: 100%
[*] Stopping spamd.
Waiting for PIDS: 13859, 13859.
You may need to manually remove 
/usr/local/etc/mail/spamassassin/local.cf if it is no longer needed.
Message from spamassassin-3.4.1_11:


==

You should complete the following post-installation tasks:

1) Read /usr/local/share/doc/spamassassin/INSTALL
   and /usr/local/share/doc/spamassassin/UPGRADE
   BEFORE enabling SpamAssassin for important changes

2) Edit the configuration in /usr/local/etc/mail/spamassassin,
   in particular /usr/local/etc/mail/spamassassin/init.pre
   You may get lots of annoying (but harmless) error messages
   if you skip this step.

3) To run spamd, add the following to /etc/rc.conf:
   spamd_enable="YES"

4) If this is a new installation, you should run sa-update
   and sa-compile. If this isn't a new installation, you
   should probably run those commands on a regular basis
   anyway.

5) Install mail/spamass-rules if you want some third-party
   spam-catching rulesets

SECURITY NOTE:
By default, spamd runs as root (the AS_ROOT option). If you wish
to change this, add the following to /etc/rc.conf:

spamd_flags="-u spamd -H /var/spool/spamd"


==

mail> /usr/local/etc/rc.d/sa-spamd status
spamd is not running.

Ok, one might notice that the daemon has been stopped [*], but section "You 
should complete …" fails to mention, that one needs to restart the daemon after 
upgrading.


Please correct me if I am wrong but I have always been under the impression 
that stopping a daemon whilst upgrading violates conventions?

Thanks and with kind regards,
Michael





___
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: audio/logitechmediaserver fails to compile

[Michael Grimm]

Jan Beich <jbe...@freebsd.org> wrote:
> Michael Grimm <trash...@ellael.org> writes:

>> uspoof.cpp:369:22: error: ordered comparison between pointer and zero 
>> ('int32_t *' (aka 'int *') and 'int')
>>if (position > 0) {
>> ^ ~
>> 1 warning and 1 error generated.
>> 
>> Any ideas on how to fix this?
> 
> See https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=218407

Thanks! I did google for an issue with logitechmediaserver, but I didn't search 
for icu instead :-(

Regards,
Michael


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

audio/logitechmediaserver fails to compile

[Michael Grimm]

Hi —

This is FreeBSD 11.0-STABLE #0 r316610.

IIRC, starting with the recent upgrade to ...

poudriere> clang --version
FreeBSD clang version 4.0.0 (tags/RELEASE_400/final 297347) (based on 
LLVM 4.0.0)

... audio/logitechmediaserver fails to compile (poudriere run):

gmake[2]: Entering directory 
'/wrkdirs/usr/ports/audio/logitechmediaserver/work/slimserver-vendor-14cc392/CPAN/icu/source/i18n'
[...]
uspoof.cpp:369:22: error: ordered comparison between pointer and zero 
('int32_t *' (aka 'int *') and 'int')
if (position > 0) {
 ^ ~
1 warning and 1 error generated.
gmake[2]: *** [../config/mh-bsd-gcc:41: uspoof.ao] Error 1
gmake[2]: Leaving directory 
'/wrkdirs/usr/ports/audio/logitechmediaserver/work/slimserver-vendor-14cc392/CPAN/icu/source/i18n'
gmake[1]: *** [Makefile:119: all-recursive] Error 2
gmake[1]: Leaving directory 
'/wrkdirs/usr/ports/audio/logitechmediaserver/work/slimserver-vendor-14cc392/CPAN/icu/source'
make failed

Any ideas on how to fix this?

Thanks in advance,
Michael

___
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: poudriere / logitechmediaserver: License SDL needs confirmation, but BATCH is defined

[Michael Grimm]

Don Lewis <truck...@freebsd.org> wrote:
> On  8 Oct, Michael Grimm wrote:
>> Don Lewis <truck...@freebsd.org> wrote:
>>> 
>>> On  8 Oct, Michael Grimm wrote:

>>>>| >> Ignoring audio/logitechmediaserver: License SDL needs 
>>>> confirmation, but BATCH is defined
>>>> 
>>>> Is there a way to get that port packed by poudriere?
>>> 
>>> Add
>>> LICENSES_ACCEPTED=SDL
>>> to /usr/local/etc/poudriere.d/make.conf.  You are still responsible for
>>> following the license terms.
>> 
>> I am asking myself where should one look for such kind of information?
> 
> It's documented here:
> <https://wiki.freebsd.org/PortsLicenseInfrastructure>
> 
> It took me a long time to find this info when I needed it.  I might have
> come across it first by digging around in /usr/ports/Mk/*.

Thanks for your link, now I know what the infrastructure regarding licenses 
looks like.

But I do have to admit, that I wouldn't have found that information by myself. 
The error message made me rather look for a way to run poudriere in an 
interactive way to answer the question about accepting that license (as 
presented while running a "make" in "/usr/ports/audio/logitechmediaserver").

Thansk again and kind regards,
Michael

___
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: poudriere / logitechmediaserver: License SDL needs confirmation, but BATCH is defined

[Michael Grimm]

Don Lewis <truck...@freebsd.org> wrote:
> 
> On  8 Oct, Michael Grimm wrote:

>> as audio/squeezeboxserver has gone, I need to migrate to
>> audio/logitechmediaserver. 
>> 
>> But I am failing to get this port compiled by poudriere (3.2-pre):
>> 
>>  | ?
>>  | ---End make.conf—
>>  | >> Ignoring audio/logitechmediaserver: License SDL needs 
>> confirmation, but BATCH is defined
>>  | ?
>> 
>> I did try to run ?
>> 
>>  poudriere testport -j stable -c -i audio/logitechmediaserver
>>  poudriere testport -j stable -c -I audio/logitechmediaserver
>> 
>> ? without success.
>> 
>> Is there a way to get that port packed by poudriere?
> 
> Add
>   LICENSES_ACCEPTED=SDL
> to /usr/local/etc/poudriere.d/make.conf.  You are still responsible for
> following the license terms.

Thank you very much! That did the trick. 

I am asking myself where should one look for such kind of information?

Again, thank you, and with kind regards,
Michael


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

poudriere / logitechmediaserver: License SDL needs confirmation, but BATCH is defined

[Michael Grimm]

Hi —

as audio/squeezeboxserver has gone, I need to migrate to 
audio/logitechmediaserver. 

But I am failing to get this port compiled by poudriere (3.2-pre):

| …
| ---End make.conf—
| >> Ignoring audio/logitechmediaserver: License SDL needs 
confirmation, but BATCH is defined
| …

I did try to run …

poudriere testport -j stable -c -i audio/logitechmediaserver
poudriere testport -j stable -c -I audio/logitechmediaserver

… without success.

Is there a way to get that port packed by poudriere?

Thanks and regards,
Michael

___
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: Clamd core dumps

[Michael Grimm]

Kubilay Kocak  wrote:

> On 9/08/2016 11:07 AM, Dima Panov wrote:
>> 09.08.16 10:05, Doug Hardie пишет:

>>> I just upgraded a mail server from 9.3 to 11.0-BETA4.  clamav worked fine 
>>> on 9.3.  However, after upgrading it and reinstalling the package clamd 
>>> core dumps just after reading all the signatures.  
[…]
>> Let me guess. ClamAV was built with LLVM/Jit support? It's broken for
>> now as Clamav can use only LLVM <3.7 and base system provide llvm 3.8.
>> 
>> Try to rebuild without LLVM/Jit, this solved crashdumps for me.

> Dima,
> 
> Should we set BROKEN on OSVERSION > X with that option?

ClamAV is widely used, thus many will run into this issue after upgrading to 11 
(as I did as well). 

I am not that much familiar with possible implications if set to BROKEN, and I 
do not know why one would need Jit support either, but I do recommend that this 
needed modification to an option should be mentioned in /usr/ports/UPDATING.

Regards,
Michael
 

___
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: mariadb101-server vulnerability?

[Michael Grimm]

On 2016-08-08 12:02, Bernard Spil wrote:


The CVE's mention MariaDB where applicable.

Added versions where these vulns were fixed for MariaDB. PerconaDB
follows the MySQL release numbering and has also received updates so I
added version checks there as well.

See https://svnweb.freebsd.org/ports?view=revision=419813

Cheers,
Bernard.


I'd like to thank everyone involved in getting this issue solved.

Thanks and regards,
Michael

___
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: poudriere: howto build ports with 'make -j x'?

[Michael Grimm]

Christian Schwarz  wrote:

> From my poudriere.conf:
> 
>  # By default MAKE_JOBS is disabled to allow only one process per cpu
>  # Use the following to allow it anyway
>  ALLOW_MAKE_JOBS=no
> 
>  # List of packages that will always be allowed to use MAKE_JOBS
>  # regardless of ALLOW_MAKE_JOBS. This is useful for allowing ports
>  # which holdup the rest of the queue to build more quickly.
>  ALLOW_MAKE_JOBS_PACKAGES="pkg ccache py* perl5.20"
> 
> Hope this helps!

Yes, it helped. Especially me being blind to find that in the first place :-(

Thanks to all who helped me finding these knobs.

Regards,
Michael

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

poudriere: howto build ports with 'make -j x'?

[Michael Grimm]

Hi,

I am used to build my ports by poudriere in parallel (-J x). But I do want to 
build specific ports in parallel per se (make -j x) just to speed up build 
times of huge ports like mariadb101-server.

I did try to add an MAKEOPTS="-j8" into poudriere's specific jailname-make.conf 
file, and I did try to use a jailname-setfile-make.conf as well. But that 
didn't work for me.

What would be the correct way to achieve what I want?

Thanks and regards,
Michael

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

mariadb101-server vulnerability? (was: tiff vulnerability in ports?)

[Michael Grimm]

Hi —

Kubilay Kocak  wrote:

> Unfortunately you are yet one more example of a user that's been left in
> the lurch without information or recourse wondering (rightfully) how
> they can resolve or mitigate this vulnerability. Our apologies.

While we are that topic, I am wondering about that 14 days old warning, as well:

mariadb101-server-10.1.16 is vulnerable:
MySQL -- Multiple vulnerabilities
CVE: CVE-2016-3452
[long list of CVEs snipped]
CVE: CVE-2016-3477

https://vuxml.FreeBSD.org/freebsd/ca5cb202-4f51-11e6-b2ec-b499baebfeaf.html

I really do not know how serious this report is. Every feedback is highly 
appreciated.

Thanks and with kind regards,
Michael

___
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: pkg-1.7.0 is an order of magnitude slower than pkg-1.6.4

[Michael Grimm]

Baptiste Daroussin <b...@freebsd.org> wrote:
> 
> On Sat, Apr 02, 2016 at 02:59:06PM +0200, Michael Grimm wrote:
>> Baptiste Daroussin <b...@freebsd.org> wrote:
>>> On Sat, Apr 02, 2016 at 02:42:06PM +0200, Michael Grimm wrote:

>>>> 26 seconds for 74 ports within a jail and pkg-1.6.4:
>> […]
>>>> 309 seconds for the very same 74 ports within the very same jail and 
>>>> pkg-1.7.0:
>> […]
>>>> Is this an expected slow-down? /usr/ports/UPGRADE and 
>>>> https://svnweb.freebsd.org/ports/head/ports-mgmt/pkg/?view=log are not 
>>>> indicating that behavior.
>>>> But I might have missed something.
>>>> 
>>>> Any feedback is highly appriciated, thanks, and regards,
>>> 
>>> pkg 1.7 is IO intensive that may explain.
>> 
>> Ok, understood.
>> 
>> JFTR: perl (24s), python27 (44s), and ruby (125s) take the longest time to 
>> reinstall.
>> 
>>> I plan to readd some improvements on this side before 1.8
>> 
>> Good to know, thanks for your feedback.
> 
> Just to follow up on the performance issue, there is a regression that 
> happened
> on FreeBSD 10.3-RELEASE (also HEAD) that causes pkg extraction process to be 
> 10
> times slower as it should. r297626 fixes it in head. We are working on 
> bringing
> that into the 10 branch:
> https://svnweb.freebsd.org/base?view=revision=297626

Thanks. I added the relevant patch [1] to 10.3-STABLE (r297721) and I can 
confirm that that fixed the performance issue. 

Now, with pkg-1.7.2 for the very same 74 ports and jail reinstallation is back 
to 26 seconds:

Apr  8 20:04:42  pkg: indexinfo reinstalled: 0.2.4 -> 
0.2.4 
...
Apr  8 20:05:08  pkg: pkg reinstalled: 1.7.2 -> 1.7.2 


Up to now, 10.3-STABLE runs rock solid. I will report if that might change.

Thanks for your engagement and with kind regards,
Michael


[1] 
https://svnweb.freebsd.org/base/head/lib/libc/db/hash/hash.c?view=patch=297626=297625=297626
 

___
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: pkg-1.7.0 is an order of magnitude slower than pkg-1.6.4

[Michael Grimm]

Baptiste Daroussin <b...@freebsd.org> wrote:
> 
> On Sat, Apr 02, 2016 at 02:42:06PM +0200, Michael Grimm wrote:

>> 26 seconds for 74 ports within a jail and pkg-1.6.4:
[…]
>> 309 seconds for the very same 74 ports within the very same jail and 
>> pkg-1.7.0:
[…]
>> Is this an expected slow-down? /usr/ports/UPGRADE and 
>> https://svnweb.freebsd.org/ports/head/ports-mgmt/pkg/?view=log are not 
>> indicating that behavior.
>> But I might have missed something.
>> 
>> Any feedback is highly appriciated, thanks, and regards,
> 
> pkg 1.7 is IO intensive that may explain.

Ok, understood.

JFTR: perl (24s), python27 (44s), and ruby (125s) take the longest time to 
reinstall.

> I plan to readd some improvements on this side before 1.8

Good to know, thanks for your feedback.

Regards,
Michael

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

pkg-1.7.0 is an order of magnitude slower than pkg-1.6.4

[Michael Grimm]

Hi —

This is 10.3-PRERELEASE (r297387).

I did upgrade ports-mgmt/pkg today and ever since, I do observe a significant 
slow-down when it comes to reinstalling ports from my poudriere repository:

26 seconds for 74 ports within a jail and pkg-1.6.4:

Mar 29 18:19:56  pkg: indexinfo reinstalled: 0.2.4 -> 
0.2.4 
…
Mar 29 18:20:22  pkg: pkg reinstalled: 1.6.4_1 -> 1.6.4_1


309 seconds for the very same 74 ports within the very same jail and pkg-1.7.0:
---
Apr 2 14:09:55  pkg: indexinfo reinstalled: 0.2.4 -> 0.2.4
…
Apr 2 14:15:04  pkg: pkg reinstalled: 1.7.0 -> 1.7.0

This is reproducible, this is true for all my ports in all my jails and on the 
host.

Is this an expected slow-down? /usr/ports/UPGRADE and 
https://svnweb.freebsd.org/ports/head/ports-mgmt/pkg/?view=log are not 
indicating that behavior.
But I might have missed something.

Any feedback is highly appriciated, thanks, and regards,
Michael

___
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: openntpd-5.7p4_2,2 depends on libressl-2.2.6 ?!

[Michael Grimm]

Walter Schwarzenfeld  wrote:

> Makefile
> OPTIONS_DEFAULT=RESSL
> 
> RESSL_LIB_DEPENDS=  libtls.so:${PORTSDIR}/security/libressl
> 
> 
> turn option RESSL to off.

Ok, thanks, and that was easy ;-) Sorry, I should have found that myself.

Regards,
Michael


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

openntpd-5.7p4_2,2 depends on libressl-2.2.6 ?!

[Michael Grimm]

Hi —

A couple of days ago, poudriere started complaining about openntpd:

| pkg-static: libressl-2.2.6 conflicts with openssl-1.0.2_11 (installs 
files into the same place).  
| Problematic file: /usr/local/bin/openssl
|
| Failed to install the following 1 package(s): 
/packages/All/openntpd-5.7p4_2,2.txz

I cannot find any remarks in /usr/ports/UPDATING about openntpd depending on 
libressl, and I really do not want to switch my system to libressl just 
pleasing openntpd.

Question: any chance to get around that dependency?

Thanks and regards,
Michael

___
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: postfix-current is marked broken w.r.t SPF support, why?

[Michael Grimm]

Hi Olli —

On 14.02.2016, at 22:37, olli hauer <oha...@gmx.de> wrote:
> On 2016-02-08 20:13, Michael Grimm wrote:

>> I am wondering why postfix-current is still marked broken regarding SPF 
>> support:
>> 
>> | poudriere build log file excerpt:
>> |Finished build of mail/postfix-current: Ignored: is marked as broken: 
>> At the moment, SPF support is unavailable for postfix-3.0-20151003
>> 
>> Thus, I made a custom port removing this restriction in the Makefile, and 
>> that custom port compiles including SPF support:
>> 
>> | mail> pkg query %do postfix-custom
>> | security/openssl
>> | devel/icu
>> | mail/dovecot2
>> | mail/libspf2
>> | devel/pcre
>> 
>> | mail> pkg info | grep libspf
>> | libspf2-1.2.10_2   Sender Rewriting Scheme 2 C Implementation
>> 
>> | mail> ldd `which postfix`
>> | /usr/local/sbin/postfix:
>> |...
>> |libspf2.so.2 => /usr/local/lib/libspf2.so.2 (0x8024a8000)
>> |...
> 
> 
> Hi Michael,
> 
> until now the patch will not apply clean and there is no new patch available.
> If we remove the BROKEN message users getting perhaps no notification if 
> current will become the new default postfix
> 
> 
> ===> Fetching all distfiles required by postfix-current-3.0.20151003_1,4 for 
> building
> => SHA256 Checksum OK for postfix/postfix-3.0.3.tar.gz.
> => SHA256 Checksum OK for postfix/postfix-2.8.0-libspf2-1.2.x-0.patch.gz.
> ===> Patching for postfix-current-3.0.20151003_1,4
> ===> Applying distribution patches for postfix-current-3.0.20151003_1,4
> 1 out of 2 hunks failed--saving rejects to src/global/mail_params.c.rej
> 1 out of 7 hunks failed--saving rejects to src/smtpd/smtpd.c.rej
> 1 out of 3 hunks failed--saving rejects to src/smtpd/smtpd_check.c.rej
> *** Error code 1


Oh, I see. I didn't realize before that this SPF support will patch postfix and 
add functionality to deal with SPF in smptd, directly.

But that patch is old and made for a postfix version 2.8.x no longer supported 
upstream, and in addition, the author of postfix, Wietse, clearly states [1] 
that:

| Note: Postfix already ships with SPF support, in the form of a plug-in 
| policy daemon. This is the preferred integration model, at least until 
| SPF is mandated by standards. 

And in postfix source's examples/smtpd-policy directory the README.SPF states:

| See http://www.openspf.org/Software for the current version of the
| SPF policy daemon for Postfix.
|
| SPF support is also available via MILTER plugins, such as sid-milter
| at http://sourceforge.net/projects/sid-milter/ which implements both
| SenderID and SPF.

Hmm, please don't get me wrong, but wouldn't it be "better" to create a 
postfix28 port including that SPF patch for those in need of a smtpd built-in 
SPF functionality and create a stable postfix port (next week it will be 3.1) 
with just including libspf2 library and advise users to go with Wietse's 
recommendations to leave that SPF part for policy delegation? Especially with 
two ports available (postfix-policyd-spf-perl-2.010_1 and 
py27-postfix-policyd-spf-python-1.3.2_1), already.
 
Again, that's just my personal opinion, you are the maintainer, and: I might 
have missed reasons why that might be a bad idea of mine. And, as mentioned 
above, I don't even use SPF. I was only wondering, why postfix stable is still 
2.11 and came across postfix-current port with the BROKEN issue.

Thanks for all your work and regards,
Michael


[1] http://www.postfix.org/addon.html

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

postfix-current is marked broken w.r.t SPF support, why?

[Michael Grimm]

Hi —

I am wondering why postfix-current is still marked broken regarding SPF support:

| poudriere build log file excerpt:
|   Finished build of mail/postfix-current: Ignored: is marked as broken: 
At the moment, SPF support is unavailable for postfix-3.0-20151003

Thus, I made a custom port removing this restriction in the Makefile, and that 
custom port compiles including SPF support:

| mail> pkg query %do postfix-custom
| security/openssl
| devel/icu
| mail/dovecot2
| mail/libspf2
| devel/pcre

| mail> pkg info | grep libspf
| libspf2-1.2.10_2   Sender Rewriting Scheme 2 C Implementation

| mail> ldd `which postfix`
| /usr/local/sbin/postfix:
|   ...
|   libspf2.so.2 => /usr/local/lib/libspf2.so.2 (0x8024a8000)
|   ...

I do not have a demand in using SPF at the moment, but I am only wondering 
whether this is a bug or feature.

Any feedback is highly appreciated,
Michael
___
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: python27-2.7.9_1

[Michael Grimm]

On 02.07.2015, at 18:11, Kubilay Kocak ko...@freebsd.org wrote:
 On 3/07/2015 1:28 AM, Albert Gabàs | Astabis wrote:

 Please, could you update the port to the latest version (2.7.10)??
 
 It's in progress :)
 
 https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=201088
 https://reviews.freebsd.org/D2637

Great news! This will enable my servers to become migrated to libressl.

Thanks,
Michael

___
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/unison240 depends on lang/ocaml-nox11

[Michael Grimm]

 On 21.03.2015, at 15:50, Guido Falsi madpi...@freebsd.org wrote:
 On 03/21/15 14:50, Michelle Sullivan wrote:


 Which means that if unsetting X11 on in the port and not globally ocaml
 is built with X11 and unison without - which poudriere will fail on when
 it tries to find the dependencies...  which means my thoughts were
 exactly the opposite ... poudriere scans the dependency tree on startup
 which picks up the -nox11 package as a dependency then builds with x11
 when it builds ocaml...
 
 Exactly.
 
 There are four cases:
 
 one asks for both with or without X11, works fine, in both.
 
 one asks for ocaml without X11 and unison with X11, this is wrong and
 cannot obviously work.
 
 last case is asking for ocaml with X11 and unison without. This could
 work in theory, and will work on a live system, but will not work in
 poudriere at present, due to ocaml changing it's package name
 dynamically. I don't know how to make it work with the present ports system.
 
 This fourth case anyway makes little sense to me anyway, once you have
 pulled in the X11 dependency why not use it in all ports which can take
 advantage of it?


I recently (after last upgrade of poudriere-devel, although I do not know if 
that is the cause) ran into a comparable issue with unison without X11 :

| MWN cat /usr/local/etc/poudriere.d/stable10-make.conf
| WITHOUT_X11=yes
[...]

| MWN pkg info | grep unison
| unison-nox11-2.48.3_1  User-level file synchronization tool 
(without x11 stuff)

poudriere's build failed with:

| MWN cat  /.../logs/ocaml-nox11-4.01.0_4.log
| ---Begin OPTIONS List---
| === The following configuration options are available for 
ocaml-nox11-4.01.0_4:
|  DOCS=on: Build and/or install documentation
|  EXAMPLES=on: Build and/or install examples
|  THREADS=on: Threading support
   |  TK=on: LablTk library (requires X11 support)
|  X11=off: X11 (graphics) support
| === Use 'make config' to modify these settings
| ---End OPTIONS List---
[...]
| ---End make.conf---
|  Ignoring lang/ocaml: requires X11 support to build TK bindings
| build of lang/ocaml ended at Sat Mar 21 17:08:37 CET 2015

That's weird, ocaml-nox11 defaults to TK=on which requires X11 support. Bug 
or feature?

I explicitly had to to unset LablTk library (requires X11 support) to get 
this issue solved.

Regards,
Michael

___
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/unison240 depends on lang/ocaml-nox11

[Michael Grimm]

On 21.03.2015, at 19:10, Guido Falsi m...@madpilot.net wrote:
 On 03/21/15 17:55, Michael Grimm wrote:

 I recently (after last upgrade of poudriere-devel, although I do not know if 
 that is the cause) ran into a comparable issue with unison without X11 :
 
  | MWN cat /usr/local/etc/poudriere.d/stable10-make.conf
  | WITHOUT_X11=yes
  [...]
 
 I don't think old style WITH_/WITHOUT_ flags are supported anymore.
 Looking at the code you should in fact get a warning about this.

Hmm, not that I am aware of. But I will have a closer look. But! Commenting 
that WITHOUT_X11=yes has been recognized by poudriere: the unison-nox11 port 
could be compiled successfully with default ocaml settings.

 You really should move to the new style OPTIONS_UNSET/OPTIONS_SET.
 You can find some documentation in /usr/ports/Mk/bsd.options.mk

Thanks for that pointer.

  | MWN pkg info | grep unison
  | unison-nox11-2.48.3_1  User-level file synchronization tool 
 (without x11 stuff)
 
 poudriere's build failed with:
 
  | MWN cat  /.../logs/ocaml-nox11-4.01.0_4.log
  | ---Begin OPTIONS List---
  | === The following configuration options are available for 
 ocaml-nox11-4.01.0_4:
  |  DOCS=on: Build and/or install documentation
  |  EXAMPLES=on: Build and/or install examples
  |  THREADS=on: Threading support
 |  TK=on: LablTk library (requires X11 support)
  |  X11=off: X11 (graphics) support
  | === Use 'make config' to modify these settings
  | ---End OPTIONS List---
  [...]
  | ---End make.conf---
  |  Ignoring lang/ocaml: requires X11 support to build TK bindings
  | build of lang/ocaml ended at Sat Mar 21 17:08:37 CET 2015
 
 That's weird, ocaml-nox11 defaults to TK=on which requires X11 support. 
 Bug or feature?
 
 You sure you have no option directory with per port options enabling TK?

Yes, I'm sure that I haven't had an option directory with per port options 
en/disabling TK set.

 Options activate per port do override WITH_/WITHOUT_ and
 OPTIONS_UNSET/OPTIONS_SET.

Only, *after* setting OPTIONS_FILE_UNSET+=TK in lang_ocaml/options, I was 
able to get unison-nox11 port compiled by poudriere successfully. *Before* I 
haven't had any lang_ocaml/options settings at all. And because the default 
setting of ocaml-nox11 is OPTIONS_FILE_SET+=TK -which requires X11 support 
(!)- poudriere fails compiling ocaml-nox11 port. (If I am not mistaken 
miserably.)

Regards,
Michael

___
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: roundcube and php 5.4.33: fgets(): SSL read operation timed out

[Michael Grimm]

JFTR:

On 20.09.2014, at 13:17, Michael Grimm trash...@odo.in-berlin.de wrote:

 My setup: roundcube-1.0.2 + nginx-1.6.2 in a FreeBSD-10 jail. RC will connect 
 to a recent dovecot server in another jail at the same host.
 
 Recently, after upgrading php from 5.4.32 to 5.4.33 roundcube will refuse to 
 connect to dovecot:
 
 | roundcube: PHP Warning:  fgets(): SSL read operation timed out in \
 | /...path2rc.../roundcube/program/lib/Roundcube/rcube_imap_generic.php 
 on line 200
 
 Recompiling every port involved and restarting both involved jails hasn't 
 been successful. Only, reverting back to php 5.4.32 made RC work again.
 
 Is anyone running into this as well?
 Any idea how to debug this?

Someone at the RC mailing list directed me to 
https://bugs.php.net/bug.php?id=41631
Reading all those related comments, it seems to me rather a PHP and not a RC 
issue:
http://news.php.net/php.bugs/187641

(I did try to apply that patch, but failed on its second trunk :-( That might 
be beyond my capabilities, though.)

Regards,
Michael
___
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

roundcube and php 5.4.33: fgets(): SSL read operation timed out

[Michael Grimm]

Hi --

My setup: roundcube-1.0.2 + nginx-1.6.2 in a FreeBSD-10 jail. RC will connect 
to a recent dovecot server in another jail at the same host.

Recently, after upgrading php from 5.4.32 to 5.4.33 roundcube will refuse to 
connect to dovecot:

|   roundcube: PHP Warning:  fgets(): SSL read operation timed out in \
|   /...path2rc.../roundcube/program/lib/Roundcube/rcube_imap_generic.php 
on line 200

Recompiling every port involved and restarting both involved jails hasn't been 
successful. Only, reverting back to php 5.4.32 made RC work again.

Is anyone running into this as well?
Any idea how to debug this?

Thanks and regards,
Michael

___
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::DNS 0.77 / resolv.conf with comments (was: FreeBSD Port: spamassassin-3.4.0_11)

[Michael Grimm]

On 25.06.2014, at 17:21, Michael Grimm trash...@odo.in-berlin.de wrote:
 On 24.06.2014, at 12:57, Dirk-Willem van Gulik di...@webweaving.org wrote:
 Op 24 jun. 2014, om 12:07 heeft Kurt Jaeger li...@opsec.eu het volgende 
 geschreven:

 If you still see the problem, can you provide more details ?
 What did you test ? What was the output ?
 
 
 The symptom is all DNS failing within Spam Assassin in the default FreeBSD 
 10-p3 with latest packages situations; logs will show:
 
  Jun 24 12:02:04 weser spamd[78829]: plugin: eval failed: 
 available_nameservers: No DNS servers available! 
  Jun 24 12:02:04 weser spamd[78829]:  (available_nameservers: [...] No 
 DNS servers available!) 
  
 and the solution is to apply the patch from above SA link (below) -OR- go to 
 a version from apache.org = revision 1603518; for which 
 there is not yet a release/tag 
 (http://svn.apache.org/viewvc?view=revisionrevision=1603518).
 
 I ran into the same issue (10-STABLE, recent ports), and JFTR: I had to 
 downgrade p5-Net-DNS-0.77 back to p5-Net-DNS-0.76 to get 
 spamassassin-3.4.0_11 running again, no patches applied.

 spamassassin-3.4.0

spamassassin-3.4.0_11 and p5-Net-DNS-0.76 worked as expected. After upgrading 
to p5-Net-DNS-0.77 I ran into an issue that looked similar to the one reported 
above. spamd couldn't be daemonized at start-up (timed out). After some 
investigations I found the reason why spamd didn't start after upgrading to 
p5-Net-DNS-0.77:

/etc/resolv.conf
nameserver  1.2.3.4 # some comment
nameserver  8.8.8.8 # another comment

That has been accepted by p5-Net-DNS-0.76, but for p5-Net-DNS-0.77 I had to 
remove the comments:

/etc/resolv.conf
nameserver  1.2.3.4
nameserver  8.8.8.8

After removing those comments spamassassin-3.4.0_11 and p5-Net-DNS-0.77 run as 
expected.

Is this a bug or a feature?

Thanks and regards,
Michael


___
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::DNS 0.77 / resolv.conf with comments (was: FreeBSD Port: spamassassin-3.4.0_11)

[Michael Grimm]

On 28.06.2014, at 15:50, Michael Grimm trash...@odo.in-berlin.de wrote:

 spamassassin-3.4.0_11 and p5-Net-DNS-0.76 worked as expected. After upgrading 
 to p5-Net-DNS-0.77 I ran into an issue that looked similar to the one 
 reported above. spamd couldn't be daemonized at start-up (timed out). After 
 some investigations I found the reason why spamd didn't start after upgrading 
 to p5-Net-DNS-0.77:
 
 /etc/resolv.conf
   nameserver  1.2.3.4 # some comment
   nameserver  8.8.8.8 # another comment
 
 That has been accepted by p5-Net-DNS-0.76, but for p5-Net-DNS-0.77 I had to 
 remove the comments:
 
 /etc/resolv.conf
   nameserver  1.2.3.4
   nameserver  8.8.8.8
 
 After removing those comments spamassassin-3.4.0_11 and p5-Net-DNS-0.77 run 
 as expected.
 
 Is this a bug or a feature?

Well, it seems to be a feature :-(

--- /usr/local/lib/perl5/site_perl/5.16/mach/Net/DNS/Resolver/Base.pm   
2014-06-13 23:02:31.0 +0200
+++ Base.pm--0.76-way-to-read-resov.conf2014-06-28 18:31:06.492446355 
+0200
@@ -234,6 +234,10 @@
local $_;
 
while (FILE) {
+   s/\s*[;#].*$//; # strip comment
+   next unless m/\S/;  # skip empty 
line
+   s/^\s+//;   # strip leading 
space
+
/^nameserver/  do {
my ( $keyword, @ip ) = split;
push @ns, map { $_ eq '0' ? '0.0.0.0' : $_ } @ip;

Applying this patch, and p5-Net-DNS-0.77 will deal with trailing comments in 
resolv.conf keywords.

Regards,
Michael
___
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: spamassassin-3.4.0_11

[Michael Grimm]

On 24.06.2014, at 12:57, Dirk-Willem van Gulik di...@webweaving.org wrote:
 Op 24 jun. 2014, om 12:07 heeft Kurt Jaeger li...@opsec.eu het volgende 
 geschreven:

 If you still see the problem, can you provide more details ?
 What did you test ? What was the output ?
 
 
 The symptom is all DNS failing within Spam Assassin in the default FreeBSD 
 10-p3 with latest packages situations; logs will show:
 
   Jun 24 12:02:04 weser spamd[78829]: plugin: eval failed: 
 available_nameservers: No DNS servers available! 
   Jun 24 12:02:04 weser spamd[78829]:  (available_nameservers: [...] No 
 DNS servers available!) 
   
 and the solution is to apply the patch from above SA link (below) -OR- go to 
 a version from apache.org = revision 1603518; for which 
 there is not yet a release/tag 
 (http://svn.apache.org/viewvc?view=revisionrevision=1603518).

I ran into the same issue (10-STABLE, recent ports), and JFTR: I had to 
downgrade p5-Net-DNS-0.77 back to p5-Net-DNS-0.76 to get spamassassin-3.4.0_11 
running again, no patches applied.

Regards,
Michael

___
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: r356789 breaks rkhunter

[Michael Grimm]

On 09.06.2014, at 14:00, Frank Seltzer fran...@bellsouth.net wrote:
 On Sun, 8 Jun 2014, Frank Seltzer wrote:

 I just upgraded rkhunter and the installer splatted the sample file over my 
 .conf file.
 
 Running 'rkhunter --propupd' now quits with the error message
 
 The SCRIPTDIR configuration option has not been set by the installer.
 
 Some additional info.  I ran rkhunter -C on the default .conf file.
 
 -C Check the configuration file(s), then exit
 
 The SCRIPTDIR configuration option has not been set by the installer.
 Invalid INSTALLDIR configuration option - no installation directory specified.
 The default temporary directory will be used: /lib/rkhunter/tmp
 Temporary directory does not exist: /lib/rkhunter/tmp
 The default database directory will be used: /lib/rkhunter/db
 Database directory does not exist: /lib/rkhunter/db
 The internationalisation directory does not exist: /lib/rkhunter/db/i18n
 Invalid SCRIPTWHITELIST configuration option: Non-existent pathname: 
 /usr/local/bin/GET

Same issue here. Could you solve it? If so, how?

Thanks and kind regards,
Michael

___
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: r356789 breaks rkhunter

[Michael Grimm]

On 25.06.2014, at 19:53, Frank Seltzer fran...@bellsouth.net wrote:
 On Wed, 25 Jun 2014, Michael Grimm wrote:
 On 09.06.2014, at 14:00, Frank Seltzer fran...@bellsouth.net wrote:
 On Sun, 8 Jun 2014, Frank Seltzer wrote:

 I just upgraded rkhunter and the installer splatted the sample file over 
 my .conf file.
 
 Running 'rkhunter --propupd' now quits with the error message
 
 The SCRIPTDIR configuration option has not been set by the installer.
 
 Some additional info.  I ran rkhunter -C on the default .conf file.
 
 -C Check the configuration file(s), then exit
 
 The SCRIPTDIR configuration option has not been set by the installer.
 Invalid INSTALLDIR configuration option - no installation directory 
 specified.
 The default temporary directory will be used: /lib/rkhunter/tmp
 Temporary directory does not exist: /lib/rkhunter/tmp
 The default database directory will be used: /lib/rkhunter/db
 Database directory does not exist: /lib/rkhunter/db
 The internationalisation directory does not exist: /lib/rkhunter/db/i18n
 Invalid SCRIPTWHITELIST configuration option: Non-existent pathname: 
 /usr/local/bin/GET
 
 Same issue here. Could you solve it? If so, how?
 
 I had to create all the missing directories and add INSTALLDIR=/usr/local to 
 the .conf file.

Thanks and JFTR:

1. created /usr/local/etc/rkhunter.conf.local and added (copied from the 1.4.0 
version config file):
INSTALLDIR=/usr/local
DBDIR=/usr/local/var/lib/rkhunter/db
TMPDIR=/usr/local/var/lib/rkhunter/tmp
SCRIPTDIR=/usr/local/lib/rkhunter/scripts
USER_FILEPROP_FILES_DIRS=/usr/local/etc/rkhunter.conf

   Didn't need to create those directories, though.

2. Needed to decativate in /usr/local/etc/rkhunter.conf:
#SCRIPTWHITELIST=/usr/local/bin/GET 
#SCRIPTWHITELIST=/usr/local/sbin/pkgdb 

 Took me a bit and some head scratching to figure it out.

Thanks again.

Regards,
Michael


___
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: amavis[12345]: (12345-02) (!)file utility failed: exit 1

[Michael Grimm]

Hi --

On 04.03.2014, at 14:04, Scot Hetzel swhet...@gmail.com wrote:
 On Mon, Mar 3, 2014 at 10:39 AM, Michael Grimm trash...@odo.in-berlin.de 
 wrote:

 amavisd-new requires sysutils/file which throws an error

[...]

 I checked the Magdir/windows file and the bug is still there.  You
 will need to apply the patch that is in PR 183257 to get rid of the
 error.
 
 http://www.freebsd.org/cgi/query-pr.cgi?pr=183257
 
 Could someone commit this patch to the sysutils/file port.

Oh, I see. I was just curious whether I might have missed something obvious.

Regarding amavisd-new there is a workaround, I am using /usr/bin/file for the 
time beeing.

Thanks for looking into that and with kind regards,
Michael

___
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: amavis[12345]: (12345-02) (!)file utility failed: exit 1

[Michael Grimm]

Hi --

I'd like to come back on an issue reported last October (see thread ending in 
http://lists.freebsd.org/pipermail/freebsd-ports/2013-October/087175.html).

amavisd-new requires sysutils/file which throws an error like ...

| test /usr/local/bin/file ascii.txt
| ascii.txt: ERROR: line 163: regex error 17, (illegal byte sequence)

... whereas the system file utility acts as expected:

| test /usr/bin/file ascii.txt
| ascii.txt: ASCII text

I did notice it for the first time with file-5.15. Today I did upgrade to 
file-5.17, and I do still see that error.

According the message obove (see link) that bug should have been fixed already, 
correct or am I mistaken?

Thanks and with kind regards,
Michael
 
___
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

from stable/9 to stable/10: some questions

[Michael Grimm]

Hi --

I recently upgraded one of my servers from stable/9 to stable/10 which worked 
pretty well.

But, there are some questions left:

1) ezjail/jails
---
I am using ezjail to administrate my jails. During jail startup I will get 
warnings like:

| WARNING: Per-jail configuration via jail_* variables is obsolete.
| Please consider to migrate to /etc/jail.conf.

I did read the corresponding section in /usr/src/UPDATING, but I do have to 
admit that I do not understand clearly whether it is save to wait for a 
modified ezjail port, or better get that fixed by myself. All jails are running 
as expected, though.

2) portaudit/jailaudit
--
poudriere tells me that the portaudit port is obsolete now, and that I should 
use pkg audit instead. Well that's ok, but now the jailaudit port is skipped 
because it depends on portaudit.

Well, I did find /usr/local/etc/periodic/security/410.pkg-audit, but that lacks 
the functionality to check security vulnerabilities of my ports running in 
jails.

3) /usr/local/etc/periodic/daily/490.status-pkg-changes
---
Again, this script lacks the functionality to monitor changes in installed 
packages in jails.



Regarding 2) and 3) I hacked two scripts to deal with jails. Actually, I 
stole code from the portaudit, jailaudit, and 490.status-pkg-changes. Both 
scripts are kept in /usr/local/etc/periodic/daily and 
/usr/local/etc/periodic/security respectively and are triggered by specific 
configuration variables in /etc/periodic.conf

IMHO it would be better to deal with jails within 410.pkg-audit and 
490.status-pkg-changes, preferably triggered by configuration variables on 
demand, only.

Doing that professionally for FreeBSD is far beyond my own scripting 
capabilities, sorry. But if someone is willing to add monitoring of 
vulnerabilities of ports installed in jails and monitoring changes in installed 
packages in jails, and if that person will be interested in getting my dirty 
hacked scripts, just let me know.

Regards and thanks to all persons involved in getting FBSD 10 done,
Michael

___
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

amavis[12345]: (12345-02) (!)file utility failed: exit 1

[Michael Grimm]

Hi --

This is FreeBSD (9.2-STABLE, r256062), amavisd-new 2.8.0, and file 5.15. 
Mailserver including amavisd is running in a service jail.

After a recent port upgrade of file to 5.15, I do get warnings like shown in 
the subject line. In order to debug that issue I did replace the file 5.15 by 
the file 5.11 executable, and well, now those warning messages disappeared.

Here my questions:

1. Do others see those warning messages as well, running the combination 
amavisd-new 2.8.0 and file 5.15?
2. Can one safely ignore those messages?
3. May $file = '/usr/bin/file'; in amavisd.conf function as a valid 
workaround for the time being?
  (I have to admit that I didn't dare testing that, yet)

Thanks and with kind regards,
Michael
___
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: amavis[12345]: (12345-02) (!)file utility failed: exit 1

[Michael Grimm]

Hi Marc --

On 23.10.2013, at 16:49, Mark Martinec mark.martinec+free...@ijs.si wrote:

 amavis[12345]: (12345-02) (!)file utility failed: exit 1
 
 1. Do others see those warning messages as well, running the combination
 amavisd-new 2.8.0 and file 5.15? 2. Can one safely ignore those messages?
 
 If it occurs on a rare occasion, it is probably safe to ignore,
 otherwise it would be worth investigating.

It is happening on every single mail passing amavisd. 

 Other option is to enable debug logging (e.g. '# amavisd debug'),
 and grep for 'result line from file' in the log.

Here is the log file's excerpt for a plain ASCII mail message with 1000 'x' 
in the body, sent to an echo mailer:

| (50329-01) Issued a new file name: p001
| (50329-01) Charging 1000 bytes to remaining quota 792500 (out of 792500, 
(0%)) - by mime_decode
| (50329-01) p001 1 Content-Type: text/plain, size: 1000 B, name: 
| (50329-01) get_deadline mime_decode - deadline in 270.0 s, set to 189.000 s
| (50329-01) prolong_timer mime_decode: timer 189, was 189, deadline in 270.0 s
| (50329-01) get_deadline mime_decode-1 - deadline in 270.0 s, set to 189.000 s
| (50329-01) prolong_timer mime_decode-1: timer 189, was 189, deadline in 270.0 
s
| (50329-01) inspect_dsn: parts: text/plain
| (50329-01) inspect_dsn: not a bounce
| (50329-01) get_deadline dsn_parse - deadline in 270.0 s, set to 189.000 s
| (50329-01) prolong_timer dsn_parse: timer 189, was 189, deadline in 270.0 s
| (50329-01) decode_parts: level=1, #parts=1 : p001
| (50329-01) running file(1) on 1 files, arglist size 24
| (50329-01) run_command: [3984] /usr/local/bin/file p001 /dev/null 21
| (50329-01) result line from file(1): p001: ERROR: line 163: regex error 17, 
(illegal byte sequence)\n
| (50329-01) lookup_re(ERROR: line 163: regex error 17, (illegal byte 
sequence)) matches key (?^:^ERROR:), result=dat
| (50329-01) lookup [map_full_type_to_short_type] = true,  ERROR: line 163: 
regex error 17, (illegal byte sequence) matches, result=dat, 
matching_key=(?^:^ERROR:)
| (50329-01) File-type of p001: ERROR: line 163: regex error 17, (illegal byte 
sequence); (dat)
| (50329-01) (!)file utility failed: exit 1

Well, I have to admit: The interpretation of those lines are far beyond my 
scope ...

Questions:

1) Is the file utility to blame?
2) My setup?
3) What else might I do to investigate this issue?

 3. May $file = '/usr/bin/file'; in amavisd.conf function as a valid
 workaround for the time being? (I have to admit that I didn't dare testing
 that, yet)
 
 Yes, that is certainy a viable option.

After activating that option, and testing with amavisd debug as outlined
above, I'll get:

| (71656-01) Issued a new file name: p001
| (71656-01) Charging 1000 bytes to remaining quota 792500 (out of 792500, 
(0%)) - by mime_decode
| (71656-01) p001 1 Content-Type: text/plain, size: 1000 B, name: 
| (71656-01) get_deadline mime_decode - deadline in 270.0 s, set to 189.000 s
| (71656-01) prolong_timer mime_decode: timer 189, was 189, deadline in 270.0 s
| (71656-01) get_deadline mime_decode-1 - deadline in 270.0 s, set to 189.000 s
| (71656-01) prolong_timer mime_decode-1: timer 189, was 189, deadline in 270.0 
s
| (71656-01) inspect_dsn: parts: text/plain
| (71656-01) inspect_dsn: not a bounce
| (71656-01) get_deadline dsn_parse - deadline in 270.0 s, set to 189.000 s
| (71656-01) prolong_timer dsn_parse: timer 189, was 189, deadline in 270.0 s
| (71656-01) decode_parts: level=1, #parts=1 : p001
| (71656-01) running file(1) on 1 files, arglist size 18
| (71656-01) run_command: [71668] /usr/bin/file p001 /dev/null 21
| (71656-01) result line from file(1): p001: ASCII text\n

JYFI and with kind regards,
Michael 


___
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: amavis[12345]: (12345-02) (!)file utility failed: exit 1

[Michael Grimm]

Hi --

On 23.10.2013, at 20:03, Mark Martinec mark.martinec+free...@ijs.si wrote:

 The text ERROR: line 163: regex error 17, (illegal byte sequence)
 comes from the file utility, unmodified.
 
 1) Is the file utility to blame?
 
 Yes.
 
 2) My setup?
 
 Possibly (e.g. broken magic database).
 
 Looks like a known bug in the file utility, already fixed upstream:
 
  http://bugs.gw.com/my_view_page.php
(search for: illegal byte sequence)
 
 Should be reproducible by running the file(1) from a command line
 (in the same/similar environment as amavisd is running, just in case).

Confirmed, it's throwing the same error message[1]:

| mail /usr/local/bin/file zzz
| zzz: ERROR: line 163: regex error 17, (illegal byte sequence)

Thank you for helping me understand that issue. Now, I will wait for
a corrected file port.

With kind regards,
Michael


[1] Sorry, I should have tested it this way already.
___
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: Berkeley DB 4.1

[Michael Grimm]

On 12.09.2013, at 13:34, Ivan Voras ivo...@freebsd.org wrote:

 Yes, I've had WITH_BDB_VER?=48 in my standard /etc/make.conf

Please excuse my ignorance, but I couldn't find the meaning of 
that '?'. Does that stand for *at least* version db48? Or?

Thanks in advance,
Michael

___
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: Berkeley DB 4.1

[Michael Grimm]

On 13.09.2013, at 21:56, Pietro Cerutti g...@gahr.ch wrote:
 On 13-set-2013, at 21:01, Michael Grimm trash...@odo.in-berlin.de wrote:
 On 12.09.2013, at 13:34, Ivan Voras ivo...@freebsd.org wrote:

 Yes, I've had WITH_BDB_VER?=48 in my standard /etc/make.conf
 
 Please excuse my ignorance, but I couldn't find the meaning of 
 that '?'. Does that stand for *at least* version db48? Or?
 
 Set the variable if it's not set already, so if a port specify
 its own preference via WITH_BDB_VER, it's respected.

Thanks to all who answered (including offlist).

If I would like to force all ports to become compiled with db48,
I would use WITH_BDB_VER=48, instead. Understood.

But, is there a way to define something like use at least db48
and ignore whatever is specified by the port, except, if the port
specifies a version  db48.

Sorry, that might be a dumb question of mine, but I just want to 
learn more about those knobs.

Regards,
Michael
   
___
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] creation/update of jails failing

[Michael Grimm]

Hi -

On 23.08.2013, at 23:49, Andrei Brezan andrei...@gmail.com wrote:
 On 08/23/13 22:28, Michael Grimm wrote:

 I do have two jails compiling packages for release and stable created some 
 time ago by:
 
 | poudriere jail -c stable  -c -v stable/9   -m svn -J 6
 | poudriere jail -c release -c -v releng/9.2 -m svn -J 6

 What does the second -c stand for? I presume it's a typo.

Yes, that is a typo and should have been -j stable and -j release 
respectively.

 releng/9.2 can be fetched with -m ftp (which is default) instead of building 
 it with buildworld unless you need the custom build which might be the cause 
 of the update failing then.
 
 poudriere jail -c -j release -v 9.2-RC2

As mentioned before: I am a newbie regarding poudriere. I must have failed to 
understand the jail concept from the beginning. I always believed that the 
method to chose for creation and updating my poudriere jails should be the same 
I use following FBSD at my target machines (svn and compiling from source).

Now, the creation of both 9.2-PRERELEASE and 9.2-RC2 jails by -m ftp has been 
successful and BTW very much faster as well ;-). Thanks for pointing me into 
that direction.

 Starting yesterday I have to deal with failing updates:
 
 | poudriere jail -c stable  -u -J 6
 | poudriere jail -c release -u -J 6

 Can you try without -J 6? Just a shot in the dark.

JFTR: No, that didn't help. I did run into the same error.


Anyway, I will stick to the default method from now on.

Thanks,
Michael
___
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

[poudriere] creation/update of jails failing

[Michael Grimm]

Hi --

Disclaimer: I have to admit that I am still very unexperienced with poudriere 
even though using it for a couple of month now.

I do have two jails compiling packages for release and stable created some time 
ago by:

| poudriere jail -c stable  -c -v stable/9   -m svn -J 6
| poudriere jail -c release -c -v releng/9.2 -m svn -J 6 

Starting yesterday I have to deal with failing updates:

| poudriere jail -c stable  -u -J 6
| poudriere jail -c release -u -J 6

Error message from creation of both jails:

| gzip -cn texinfo.info  texinfo.info.gz
| [...]
| === lib/clang/include (all)
| 1 error
| *** [everything] Error code 2
| 1 error
| *** [buildworld] Error code 2
| 1 error
|  Error: Fail to build world
|  Error while creating jail, cleaning up.
|  Removing stable jail... done

Those errors are reproducible even after removing every zfs filesystem 
dedicated to poudriere jails and starting from scratch (poudriere jail -c ...).

Any hint/recommendation is highly appreciated, thanks,
Michael

___
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: openssl broken

[Michael Grimm]

Jerry je...@seibercom.net wrote:

 I updated openssl on my system and ran into this bug:

 As noted numerous times on the openssl-dev list, OpenSSL 1.0.1d is
 broken.  You need to grab 
 http://git.openssl.org/gitweb/?p=openssl.git;a=commitdiff;h=32cc247
 and apply it to the 1.0.1d source to fix it.

 Will this patch be applied to the port version?

I'd like to second that. I ran into this issue as well, breaking
dovecot, postfix and nginx. Thanks to zfs snapshots I've been able 
to recover within seconds ;-)

Regards,
Michael
___
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: openssl broken

[Michael Grimm]

Jerry je...@seibercom.net wrote:
 
 Usually I never update any software to a new version until it has been
 in use for a while. However, since this was not a major update, but
 just a minor letter, I figured how badly could I get burnt.

Hmm, I did follow the advice in my daly security report:
| Affected package: openssl-1.0.1_5
| Type of problem: OpenSSL -- TLS 1.1  1.2 denial of service.
| Reference: 
http://portaudit.FreeBSD.org/00b0d8cd-7097-11e2-98d9-003067c2616f.html

 Hopefully something will be done to correct the problem.

I'm very confident, that this issue will be resolved very soon, really.
Shit happens. Thus, I do not complain.

Regards,
Michael
___
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: inn-2.4.5

[Michael Grimm]

Hi, again -

On 17.01.2009, at 10:38, Michael Grimm wrote:

I'm running FBSD 7.1-p2 and inn-2.4.5 with largefile support and  
ovdb overview in a jail without any difficulties sofar.


The recent Perl-upgrade to 5.8.9 crashes innd (core dump) at start- 
up, reproducible. I did re-compile all ports including inn, same  
result. Then I removed Perl support during configuration, re- 
compiled, and now innd starts and runs as expected.


I just want to bring this to your attention, if you won't know this  
already. I couldn't find reports at the ports-mailing list sofar.


Hope that this isn't to difficult to fix. Let me know if you need  
help in further debugging.


This bug can be solved by applying the following patch:

--- inn-2.4.5/lib/perl.c2008-06-29 19:56:57.0 +0200
+++ inn-2.4.5-1/lib/perl.c  2009-01-21 19:36:03.0 +0100
@@ -110,14 +110,18 @@
if (PerlCode == NULL) {
/* Perl waits on standard input if not called with '-e'. */
int argc = 3;
-const char *argv[] = { innd, -e, 0, NULL };
-char *env[]  = { NULL };
+const char *argv_innd[] = { innd, -e, 0, NULL };
+char **argv = (char **)argv_innd; /* Cast required by Perl  
5.10. */

+char **env  = { NULL };
#ifdef PERL_SYS_INIT3
PERL_SYS_INIT3(argc, argv, env);
#endif
PerlCode = perl_alloc();
perl_construct(PerlCode);
-perl_parse(PerlCode, xs_init, argc, (char **)argv, env) ;
+#ifdef PERL_EXIT_DESTRUCT_END
+PL_exit_flags |= PERL_EXIT_DESTRUCT_END;
+#endif
+perl_parse(PerlCode, xs_init, argc, argv, env) ;
}

if (startupfile != NULL  filterfile != NULL) {

This patch has been proposed by the current main developer of INN  
(Julien Élie),

see Usenet thread at:

http://groups.google.com/group/news.software.nntp/browse_frm/thread/42238dc9237b5a81?q=

It did work for me after applying this patch to inn's vanilla tarfile,  
putting the
patches tarfile into /usr/ports/distfiles/, modifying news/inn/ 
distinfo to cover

the new size and checksums, and re-installing with portmaster.

Regards,
Michael

___
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 Port: inn-2.4.5

[Michael Grimm]

Hi -

I'm running FBSD 7.1-p2 and inn-2.4.5 with largefile support and ovdb  
overview in a jail without any difficulties sofar.


The recent Perl-upgrade to 5.8.9 crashes innd (core dump) at start-up,  
reproducible. I did re-compile all ports including inn, same result.  
Then I removed Perl support during configuration, re-compiled, and now  
innd starts and runs as expected.


I just want to bring this to your attention, if you won't know this  
already. I couldn't find reports at the ports-mailing list sofar.


Hope that this isn't to difficult to fix. Let me know if you need help  
in further debugging.


Thanks and regards,
Michael

___
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

inn-2.4.5 and Berkeley DB 4.x: compilation fails

[Michael Grimm]

Hi -

I'm running a inn-2.4.3 (with ovdb) using Berkeley db40 on a 6.3- 
RELEASE-p5,

and I'm trying to upgrade to the recent inn-2.4.5.

A 'portmaster -v inn' fails with (snipped to the relevant information):

	gmake[1]: Entering directory `/usr/ports/news/inn/work/inn-2.4.5/ 
storage'

[...]
	cc -O2 -fno-strict-aliasing -pipe -DNO_IDEA -I../include  - 
D_LARGEFILE_SOURCE -D_FILE_OFFSET_BITS=64 -I. -I/usr/local/include/ 
db40 -c -o ovdb/ovdb.o ovdb/ovdb.c

In file included from ovdb/ovdb.c:99:
	ovdb/ovdb-private.h:11:2: #error Need BerkeleyDB 2.6.x, 2.7.x, 3.x  
or 4.x

In file included from ovdb/ovdb.c:99:
ovdb/ovdb-private.h:88: error: syntax error before '*' token
	ovdb/ovdb-private.h:88: warning: data definition has no type or  
storage class

ovdb/ovdb-private.h:98: error: syntax error before numeric constant
[...]

Well, I do have db41 installed (due to please netatalk's  
dependencies). Therefore

I tried to use db41 to compile inn-2.4.5:

1) cd /usr/ports/news/inn
2) make config
3) make configure
4) modify all db40 and db4 in work/inn-2.4.5/Makefile.global into db41
5) make

And, it compiled successfully, but I haven't tried to install  
inn-2.4.5, yet.




Well, then I installed db44, db46, and db47, modified work/inn-2.4.5/ 
Makefile.global

accordingly, but failed miserably:

gmake[1]: Entering directory `/usr/ports/news/inn/work/inn-2.4.5/innd'
[...]
/usr/bin/ld: cannot find -ldb44
gmake[1]: *** [innd] Fehler 1
gmake[1]: Leaving directory `/usr/ports/news/inn/work/inn-2.4.5/innd'
gmake: *** [all-innd] Fehler 2
*** Error code 2
Stop in /usr/ports/news/inn.
*** Error code 1
Stop in /usr/ports/news/inn.

Hmm, even if I modify work/inn-2.4.5/Makefile.global in order to find  
the
libraries in /usr/local/lib/db4x instead of /usr/local/lib, the  
compilation

failes with the same error messages.

I do have the following questions:
1) Any ideas what's going on here?
2) How could I use the recent db47?
	3) Why does /usr/ports/news/inn/files/patch-configure remove the  
reverse

   search for installed db4x (like db47 db46 db45 ...)?

Thanks and regards,
Michael








___
freebsd-ports@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-ports
To unsubscribe, send any mail to [EMAIL PROTECTED]

freebsd-uucp: rmail fails on email addresses with leading dashes

[Michael Grimm]

Hi - 
 
I recently subscribed to this ML, although reading it quite some time 
at Usenet. The background for this mail has its origin in a thread in
comp.unix.bsd.freebsd.misc, see [1]. 

I'm receiving my mail via UUCP, thus '/bin/rmail' will be called by
'/usr/local/libexec/uucp/uuxqt', and I'm receiving a lot of spam from
dumb spammers using guessed email addresses with leading '-' like
'[EMAIL PROTECTED]'. (If I'm not mistaken, then localparts with
leading dashes are valid ones.)
 
This will result in an uuxqt call ...
/bin/rmail [EMAIL PROTECTED]
... with an UUCP error, which is absolutely correct, because rmail 
doesn't know of any parameter '[EMAIL PROTECTED]'.
 
Workaround is a wrapper script calling 'rmail -- $*'.
 
This has been considered a security issue in [1], and the recommendation
was fixing uuxqt to call 'rmail --', instead.

Although I volunteered to fix it myself, I have to admit that this would
be far beyond my abilities. UUCP looks a rather complicated system to
me. I could't find the call to rmail in uuxqt's sourcecode. 

But, I realized that a so-called 'execute file' is used to tell uuxqt
what to do. I tried to modify an example file in a way that rmail might
have been called the way I need:

'execute file' example:
U mail somename
F D.somenameC4X7W
I D.somenameC4X7W
R [EMAIL PROTECTED]
C rmail [EMAIL PROTECTED]
Z

I tried to modify it to ...
C rmail -- [EMAIL PROTECTED]
C rmail '-- [EMAIL PROTECTED]'
C rmail -- [EMAIL PROTECTED]
... without success:
ERROR: Execution: Exit status 64

Well, but ...
C rmail '[EMAIL PROTECTED]'
... worked. uux is generating those 'execute files', but now I'm stuck.
I can't find where I could patch the sourcecode. And, more importantly,
I can't oversee what will break if I could fix it the way I want ... :-(
 
Anyone out there who could help me? This is ld software, I know ;-) 

This is all on 6.3-RELEASE, but I'm quite sure its the same with 7.x and
8.x.

Regards, 
Michael

[1] 
http://groups.google.com/group/comp.unix.bsd.freebsd.misc/msg/b653a6cbf387f971
-- 
to let


___
freebsd-ports@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-ports
To unsubscribe, send any mail to [EMAIL PROTECTED]