Many of the WWW are overwritten later which means the wrong value
is used. This did not happen before where the children were either
a) just using the pkg-descr from the parents
b) or had their own separate pkg-descr with custom WWW
Use WWW?= in parents when the child's WWW is different.
Children that use the same WWW as the parent can just inherit it,
i.e., the child WWW can be removed.
Approved by: portmgr (implicit)
Commit b7f05445c0 has added WWW entries to port Makefiles based on
WWW: lines in pkg-descr files.
This commit removes the WWW: lines of moved-over URLs from these
pkg-descr files.
Approved by: portmgr (tcberner)
It has been common practice to have one or more URLs at the end of the
ports' pkg-descr files, one per line and prefixed with "WWW:". These
URLs should point at a project website or other relevant resources.
Access to these URLs required processing of the pkg-descr files, and
they have often become stale over time. If more than one such URL was
present in a pkg-descr file, only the first one was tarnsfered into
the port INDEX, but for many ports only the last line did contain the
port specific URL to further information.
There have been several proposals to make a project URL available as
a macro in the ports' Makefiles, over time.
This commit implements such a proposal and moves one of the WWW: entries
of each pkg-descr file into the respective port's Makefile. A heuristic
attempts to identify the most relevant URL in case there is more than
one WWW: entry in some pkg-descr file. URLs that are not moved into the
Makefile are prefixed with "See also:" instead of "WWW:" in the pkg-descr
files in order to preserve them.
There are 1256 ports that had no WWW: entries in pkg-descr files. These
ports will not be touched in this commit.
The portlint port has been adjusted to expect a WWW entry in each port
Makefile, and to flag any remaining "WWW:" lines in pkg-descr files as
deprecated.
Approved by: portmgr (tcberner)
WOLFSSL is a GPLv2+ licensed SSL library with OpenSSL compatibility
layer. This is to permit shipping fetchmail under a clean GPLv2+
license with OpenSSL 1.1.1.
Now really 6.4.24 and not a 6.4.25 WIP.
fetchmail cannot legally be linked with LibreSSL,
because there is no GPLv2 clause 2b exemption for
LibreSSL, only for OpenSSL.
Correct LICENSE and remove LICENSE_COMB.
Add comment on FSF dynamic linking dynamically
suggested by Corey Halpin in the approval.
Remove LibreSSL patch.
Related to:
PR: 259214
Update:
PR: 259945
MFH: 2021Q4
Approved by: chalpin@cs.wisc.edu (maintainer)
fetchmail cannot legally be linked with LibreSSL,
because there is no GPLv2 clause 2b exemption for
LibreSSL, only for OpenSSL.
Correct LICENSE and remove LICENSE_COMB.
Remove LibreSSL patch.
Add FSF comment suggested by Corey Halpin in PR.
Related to:
PR: 259214
Update:
PR: 259945
MFH: 2021Q4
Approved by: chalpin@cs.wisc.edu (maintainer)
The RUN_DEPENDS+=BUILD_DEPENDS may pull ccache in as run-time requisite,
so let's flip the assignments and make BUILD_DEPENDS use RUN_DEPENDS to
avoid just this pollution.
PR: 256242
Approved by: Corey Halpin (maintainer)
Authors: CH = Corey Halpin, MA = Matthias Andree
- fetchmail's rc script now queries the daemon interval from the
configuration, and falls back to the rc.conf value if given. [CH]
- Similarly, the logging facility will be taken from the configuration [MA]
- Add documentation to the rcfile's header comments. [MA]
- Drop support for fetchmail_home_prefix in rc.conf, and query the
respective users' home directories with getent instead. [MA]
- In the rc scripts, redirect input from /dev/null so it will not ask
for passwords. [MA]
- Add support for the typical 12.1 rc.conf ${name}_... keywords. [MA]
- Make script execution easier to follow by simplifying if...else logic. [CH]
- Fix rcscript's exit code to be 1 if one of the per-user calls fails. [CH]
- Add relevant notes to UPDATING. [MA]
PR: 249860
Submitted by: Corey Halpin (maintainer)
Reported by: Chris James (on fetchmail-users mailing list)
Approved by: Corey Halpin (maintainer)
while here, switch distfile back to xz format and update
the > 2^31 "long long" fix so it patches the right place of the NEWS file.
- adds Romanian translation
- minor manual page fix to add "MD5" hash to sslfingerprint documentation
PR: 248954
Approved by: Corey Halpin (maintainer)
Add a patch to document --sslproto tls1.3+ and tls1.3 through the manpage,
which hasn't made 6.4.3-rc2 but works since 6.4.0 assuming that the SSL library
supports TLSv1.3.
Remove fetchmailconf patch that is now part of the upstream code.
Switch to .lz downloads, a tiny bit smaller.
Upstream changelog:
## BUGFIXES:
* Plug memory leaks when parts of the configuration (defaults, rcfile, command
line) override one another.
* fetchmail terminated the placeholder command string too late and included
garbage from the heap at the end of the string. Workaround: don't use place-
holders %h or %p in the --plugin string. Bug added in 6.4.0 when merging
Gitlab merge request !5 in order to fix an input buffer overrun.
Faulty commit 418cda65f752e367fa663fd13884a45fcbc39ddd.
Reported by Stefan Thurner, Gitlab issue #16.
* Fetchmail now checks for errors when trying to read the .idfile,
Gitlab issue #3.
## CHANGES:
* Fetchmail documentation was updated to require OpenSSL 1.1.1.
OpenSSL 1.0.2 reached End Of Life status at the end of the year 2019.
Fetchmail will tolerate, but warn about, 1.0.2 for now on the assumption that
distributors backport security fixes as the need arises.
Fetchmail will also warn if another SSL library that is API-compatible
with OpenSSL lacks TLS v1.3 support.
* If the trust anchor is missing, fetchmail refers the user to README.SSL.
PR: 245187
Submitted by: mandree@
Approved by: Corey Halpin (maintainer)
Fetchmail updated to new revision 6.4.2
- one bugfix
- manual page updates
- update of Chinese (simplified) translation
- massive fetchmailconf overhaul
+ Python 3 compatible (requires py-future)
+ Supports IPv6 and SSL probing
- remove two patches for fetchmail that are in the upstream release
- add a smoke test to fetchmailconf's post-install,
and a patch to support that running without X11 $DISPLAY.
PR: 244130
Submitted by: mandree@
Reviewed by: Corey Halpin <chalpin@cs.wisc.edu> (maintainer)
Approved by: Corey Halpin <chalpin@cs.wisc.edu> (maintainer)
MFH: 2020Q1 (bugfixes and fetchmailconf update and Python3 compat.)
The file has been re-uploaded and sourceforge.net is dealing out the same
file to its mirrors. This should be fixed soon.
Else restrict mastersites to FreeBSD's distcache, this will then be solved
with the 6.4.2 update from https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=244130
When the fetchmailconf port was split off from fetchmail, it inherited
some python version detection logic that had been intended to let
fetchmail be installed with or without python and work either way.
However, this logic 1) no longer works with current python packaging,
and 2) doesn't really make sense in the context of a 'fetchmailconf'
port that already depends on python.
This patch simplifies out that logic.
PR: 239248
Submitted by: Corey Halpin <chalpin@cs.wisc.edu> (maintainer)
Reported by: gerard_seibert@outlook.com
* Bring back SNI (server name indication) support for TLS connections,
lost in 6.3.26_10 (PORTREVISION=10) as a regression over _9.
Pointy hat: mandree@
* Drop the X11 option, remove the Python dependency, and create a new
mail/fetchmailconf slave port/package that installs the fetchmailconf
configurator. Note that the _DEPENDS of the ports reflects a technical
dependence (fetchmailconf needs fetchmail), and we cannot keep an
X11 option that depends on fetchmailconf, since that would create
a circular dependency, which we must avoid.
* Patch configure instead of configure.ac with Cy's Kerberos fix, drop
autoreconf from USES, and add a new configure check directly to set
HAVE_DECL_SSLV3_CLIENT_METHOD to cover the various TLS providers
(currently five, base, openssl, openssl111, libressl, libressl-devel)
* Add -Wl,--as-needed to LDFLAGS so as not to pull in unneeded .so
libraries, for instance, libcom_err when compiling under GSSAPI_NONE.
* Bump PORTREVISION.
Very fruitful and nice collaboration with and
Approved by: chalpin@cs.wisc.edu (maintainer)
