FreeBSD 11.3-RELEASE-p5 amd64
When using poudriere, I am unable to build 'mail/fetchmail', regardless of which 'GSSAPI Security API Support" option is chosen if "DEFAULT_VERSIONS+=ssl=openssl111" exists in the "/usr/local/etc/poudriere.d/make.conf" file. If I comment out that entry, fetchmail builds fine.
This is the error message emitted by poudriere.
"Ignoring mail/fetchmail | fetchmail-6.4.1_1: You are using OpenSSL from ports and have selected GSSAPI from base, please select another GSSAPI value"
If I select "NONE" for the GSSAPI options, the problem still remains. That makes no sense. If I comment out the entry in 'make.conf", the port builds fine.
Fetchmail pleads "not guilty", as this error is propagating up from gssapi.mk in the ports framework. See https://svnweb.freebsd.org/ports/head/Mk/Uses/gssapi.mk?view=markup#l89
However, DEFAULT_VERSIONS+=ssl=openssl111 was specifically tested with mail/fetchmail in poudriere on 11.3 by adding the following to poudriere's make.conf:
How are you selecting your GSSAPI option? If you are running `make config` in the port directory, then you are setting the options that will be used to build the port directly on the host, NOT the options that poudriere will see. To set options for poudriere, you will need to use either `poudriere options` or edit poudriere's make.conf.
(In reply to Corey Halpin from comment #1)
I was using the poudriere "make.conf" file. I added the two additional 'options'. I will test it out later today.
You might want to add that to the packaged message.
Created attachment 209366 [details]
poudriere error log for fetchmail build
I may have spoken too soon. I just tried to build 'fetchmail' using the options you showed, without success. I have 'fetchmail' configured to not use GSSAPI: GSSAPI_NONE=off: Disable GSSAPI support
What else could be wrong?
The error shown in your log is:
====> You must select one and only one option from the GSSAPI single
=====> No option was selected (and one must be)
This is what I would expect to see if you added OPTIONS_UNSET+= GSSAPI_BASE to your make.conf without also adding OPTIONS_SET+= GSSAPI_NONE
And indeed, the included make.conf in the log shows:
(note that the GSSAPI_NONE option is smashed into WITH_CCACHE. Since GSSAPI_NONEWITH_CCACHE_BUILD=yes is not the name of any valid option, it has no effect.)
(In reply to Corey Halpin from comment #4)
I have no idea where this is coming from:
It is not in the make.conf file.
This is the poudriere make.conf file:
# Possible values: 9.3, 9.4, 9.5, 9.6, 10, 11
# Possible values: 4.8, 410
# Possible values: base, openssl, openssl111, libressl, libressl-devel
# Possible values: 5.5, 5.6, 5.7, 8.0, 5.5m, 10.0m, 10.1m, 10.2m, 10.3m, 5.5p, 5.6p, 5.7p, 5.6w
# Needed for 'fetchmail'
Is it possible that there is no newline after OPTIONS_SET+= GSSAPI_NONE in your make.conf? If so, that file is not a valid POSIX text file (cf. https://stackoverflow.com/questions/729692/why-should-text-files-end-with-a-newline) and poudriere could quite easily be having trouble processing it.
It would have erased the line break by mistake.
It can be divided into OPTIONS_SET+= GSSAPI_NONE and WITH_CCACHE_BUILD=yes.
There are usually 4 options for gssapi.
GSSAPI_BASE, GSSAPI_HEIMDAL, GSSAPI_MIT and GSSAPI_NONE.
We should write all 4.
OPTIONS_UNSET= GSSAPI_BASE GSSAPI_HEIMDAL GSSAPI_MIT
HEIMDAL is similar to that of BASE.
SET/UNSET can be applied only to mail/fetchmail as follows.
mail_fetchmail_UNSET= GSSAPI_BASE GSSAPI_HEIMDAL GSSAPI_MIT
# I am doing something similar at bug 241797 :)
ooo, OPTIONS_SET+= GSSAPI_NONEWITH_CCACHE_BUILD=yes is concatenated from /usr/local/etc/poudriere.d/make.conf
Tatsuki, since mail/fetchmail is already using the standard GSSAPI options I'm not really following how this bug is similar to 241797. Could you clarify?
Sorry, my comment #7 and #8 follows how to change options in make.conf.
Regarding how to write make.conf, I wrote bug 241797 about wireshark combined with ports openssl, so I thought it would be useful for fetchmail.
(In reply to Corey Halpin from comment #6)
I can confirm that the lack of a 'newline' was the cause of the problem.
Given comment #11, I am closing this problem report.