Bug 242174 - mail/fetchmail: fails to build if DEFAULT_VERSIONS+=ssl=openssl111 exists in make.conf file
Summary: mail/fetchmail: fails to build if DEFAULT_VERSIONS+=ssl=openssl111 exists in ...
Status: Closed Works As Intended
Alias: None
Product: Ports & Packages
Classification: Unclassified
Component: Individual Port(s) (show other bugs)
Version: Latest
Hardware: Any Any
: --- Affects Only Me
Assignee: freebsd-ports-bugs mailing list
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2019-11-23 12:00 UTC by Gerard Seibert
Modified: 2020-03-30 21:59 UTC (History)
3 users (show)

See Also:
chalpin: maintainer-feedback+


Attachments
poudriere error log for fetchmail build (7.89 KB, text/plain)
2019-11-23 19:37 UTC, Gerard Seibert
no flags Details

Note You need to log in before you can comment on or make changes to this bug.
Description Gerard Seibert 2019-11-23 12:00:46 UTC
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.
Comment 1 Corey Halpin 2019-11-23 15:02:48 UTC
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:

DEFAULT_VERSIONS+=ssl=openssl111
OPTIONS_UNSET+= GSSAPI_BASE
OPTIONS_SET+= GSSAPI_NONE


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.
Comment 2 Gerard Seibert 2019-11-23 17:42:29 UTC
(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.


Thanks!
Comment 3 Gerard Seibert 2019-11-23 19:37:36 UTC
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?
Comment 4 Corey Halpin 2019-11-23 19:45:45 UTC
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:
OPTIONS_SET+= GSSAPI_NONEWITH_CCACHE_BUILD=yes

(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.)
Comment 5 Gerard Seibert 2019-11-23 23:16:21 UTC
(In reply to Corey Halpin from comment #4)

I have no idea where this is coming from:
OPTIONS_SET+= GSSAPI_NONEWITH_CCACHE_BUILD=yes

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
DEFAULT_VERSIONS+=pgsql=11

# Possible values: 4.8, 410
DEFAULT_VERSIONS+=samba=410

# Possible values: base, openssl, openssl111, libressl, libressl-devel
DEFAULT_VERSIONS+=ssl=openssl111

# 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
DEFAULT_VERSIONS+=mysql=8.0

# Needed for 'fetchmail'
OPTIONS_UNSET+= GSSAPI_BASE
OPTIONS_SET+= GSSAPI_NONE
Comment 6 Corey Halpin 2019-11-24 01:17:08 UTC
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.
Comment 7 Tatsuki Makino 2019-11-24 04:37:01 UTC
OPTIONS_SET+= GSSAPI_NONEWITH_CCACHE_BUILD=yes
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_SET=   GSSAPI_NONE
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_SET=   GSSAPI_NONE
mail_fetchmail_UNSET= GSSAPI_BASE GSSAPI_HEIMDAL GSSAPI_MIT

# I am doing something similar at bug 241797 :)
Comment 8 Tatsuki Makino 2019-11-24 04:47:37 UTC
ooo, OPTIONS_SET+= GSSAPI_NONEWITH_CCACHE_BUILD=yes is concatenated from /usr/local/etc/poudriere.d/make.conf
Comment 9 Corey Halpin 2019-11-24 16:08:40 UTC
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?
Comment 10 Tatsuki Makino 2019-11-24 22:17:01 UTC
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.
Only it.
Comment 11 Gerard Seibert 2019-11-24 22:40:20 UTC
(In reply to Corey Halpin from comment #6)
I can confirm that the lack of a 'newline' was the cause of the problem.
Comment 12 Matthias Andree freebsd_committer 2020-03-30 21:59:12 UTC
Given comment #11, I am closing this problem report.