GnuPG Made Easy (GPGME) is a C library designed to make access to GnuPG
easier for applications. It provides a High-Level Crypto API for encryption,
decryption, signing, signature verification and key management. Currently it
uses GnuPG as its backend.
===> The following configuration options are available for gpgme-2.1.2:
DOCS=on: Build and/or install documentation
TEST=off: Build and/or run tests
UISERVER=on: GnuPG UI server support
====> GNU Privacy Guard support: you have to select exactly one of them
GNUPG1=off: Build gpgme library for GnuPG 1.x
GNUPG2=on: Build gpgme library for GnuPG 2.x
===> Use 'make config' to modify these settings
security/gpgme: Update to 2.1.2
Remove CFLAGS cruft that was only meant for Qt before the split.
Update pre-build-TEST-on target with the current tests subdirs.
Changes: https://dev.gnupg.org/T8269
security/gpgme: Update to 2.0.0
Upstream has split most of the bindings out into separate projects with
this release, so the child ports that were previously providing various
bindings are now autonomous and have new origins. The python bindings
should have been called py-gpg for many years now, since 'gpg' is the
actual module name, so this also corrects that issue.
security/gpgme-cpp -> security/gpgmepp
security/gpgme-qt -> security/qgpgme
security/py-gpgme -> security/py-gpg
gpgmepp and qgpgme have been converted to CMake. py-gpg is now a "fun"
autotools and FreeBSD ports system hybrid. Gpgme, itself, still uses
autotools, but with much less parenting (patching) to do for its
emancipated children.
Adjust several ports to fix API incompatibility with upstream patches
and with some of my own. Adjust all consumers to use the new port
origins of the former child ports.
https://dev.gnupg.org/T7673
security/*gpgme*: Update to 1.24.0
Remove security/gpgme-qt-headers. The Qt headers have been folded back
into security/gpgme-qt since they no longer conflict.
https://dev.gnupg.org/T7376
security/gpgme: Use gpgrt-config for configure
Prefer gpgrt-config in the configure stage over the old individual
*-config scripts from the various gnupg-related libraries.
security/*gpgme*: Update to 1.22.0
gpgme-qt: Fix COMMENT when FLAVOR is not explicitly set and use just
one PORTREVISION line to avoid confusing bumping tools.
https://dev.gnupg.org/T6668
devel/py-setuptools: convert individual consumers to ${PY_SETUPTOOLS}
Currently a no-op, but in the future outputs the correct setuptools
port depending on whether USES_PYTHON=distutils is specified.
With hat: python
PR: 270510, 270358
security/*gpgme*: Update to 1.21.0
Split out the headers shared between the qt5 and qt6 flavors of
security/gpgme-qt to security/gpgme-qt-headers so that they no longer
conflict.
https://dev.gnupg.org/T6585
all: remove explicit versions in USES=python for "3.x+"
The logic in USES=python will automatically convert this to 3.8+ by
itself.
Adjust two ports that only had Python 3.7 mentioned but build fine
on Python 3.8 too.
finance/quickfix: mark BROKEN with PYTHON
libtool: compile: c++ -DHAVE_CONFIG_H -I. -I../.. -I -I. -I.. -I../.. -I../C++
-DLIBICONV_PLUG -DPYTHON_MAJOR_VERSION=3 -Wno-unused-variable
-Wno-maybe-uninitialized -O2 -pipe -DLIBICONV_PLUG -fstack-protector-strong
-fno-strict-aliasing -DLIBICONV_PLUG -Wall -ansi
-Wno-unused-command-line-argument -Wpointer-arith -Wwrite-strings
-Wno-overloaded-virtual -Wno-deprecated-declarations -Wno-deprecated -std=c++0x
-MT _quickfix_la-QuickfixPython.lo -MD -MP -MF
.deps/_quickfix_la-QuickfixPython.Tpo -c QuickfixPython.cpp -fPIC -DPIC -o
.libs/_quickfix_la-QuickfixPython.o
warning: unknown warning option '-Wno-maybe-uninitialized'; did you mean
'-Wno-uninitialized'? [-Wunknown-warning-option]
QuickfixPython.cpp:175:11: fatal error: 'Python.h' file not found
^~~~~~~~~~
1 warning and 1 error generated.
Reviewed by: portmgr, vishwin, yuri
Differential Revision: <https://reviews.freebsd.org/D40568>
security/gpgme-qt: Flavorize for new Qt6 bindings
Rename security/gpgme-qt5 to security/gpgme-qt and flavorize to
allow building qt5 and qt6 flavors.
Adjust dependencies and bump PORTREVISION on consumers.
Fix installation of optional Doxgen docs.
Mk/Uses: always use colon for build/run suffix
Most USES use a colon for build/run(/test) suffixes. Change kde.mk,
qt.mk and pyqt.mk to do the same, and update all ports using that.
Document in CHANGES.
PR: 266034
Exp-run by: antoine
Approved by: tcberner (mentor)
Differential Revision: https://reviews.freebsd.org/D36349
Remove WWW entries moved into port Makefiles
Commit b7f05445c00f 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)
Add WWW entries to port Makefiles
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.
(Only the first 15 lines of the commit message are shown above )
security: remove 'Created by' lines
A big Thank You to the original contributors of these ports:
* <ports@c0decafe.net>
* Aaron Dalton <aaron@FreeBSD.org>
* Adam Weinberger <adamw@FreeBSD.org>
* Ade Lovett <ade@FreeBSD.org>
* Aldis Berjoza <aldis@bsdroot.lv>
* Alex Dupre <ale@FreeBSD.org>
* Alex Kapranoff <kappa@rambler-co.ru>
* Alex Samorukov <samm@freebsd.org>
* Alexander Botero-Lowry <alex@foxybanana.com>
* Alexander Kriventsov <avk@vl.ru>
* Alexander Leidinger <netchild@FreeBSD.org>
(Only the first 15 lines of the commit message are shown above )
security/*gpgme*: Update to 1.7.1
This release only fixes an ABI compatibility issue with gpgme 1.6.0
for security/gpgme-qt5.
Bump PORTREVISION on consumers of security/gpgme-qt5 due to the
shared library bump.
Changes: https://dev.gnupg.org/T5872
Reported by: portscout
security/gpgme-cpp: Fix constness
The 1.15.0 release of gpgme-cpp adds a `Signature::operator<` which is missing
a const. In 6a6d2a27648, Signature got an operator< . This is used in
*security/libkleo*, for instance, to sort the signatures for display.
The build failure looks like this (trimmed for brevity, on 13-):
===
/usr/include/c++/v1/algorithm:715:71: error: invalid operands to binary
expression ('const GpgME::UserID::Signature' and 'const
GpgME::UserID::Signature')
bool operator()(const _T1& __x, const _T1& __y) const {return __x < __y;}
/wrkdirs/usr/ports/security/libkleo/work/libkleo-20.12.0/src/models/
useridlistmodel.cpp:203:14: note: in instantiation of function template
specialization 'std::__1::sort<GpgME::UserID::Signature>' requested here
std::sort(sigs.begin(), sigs.end());
===
PR: 252283
Submitted by: adridg
Bump PORTREVISION for ports depending on the canonical version of GCC
as defined in Mk/bsd.default-versions.mk which has moved from GCC 8.3
to GCC 9.1 under most circumstances now after revision 507371.
This includes ports
- with USE_GCC=yes or USE_GCC=any,
- with USES=fortran,
- using Mk/bsd.octave.mk which in turn features USES=fortran, and
- with USES=compiler specifying openmp, nestedfct, c11, c++0x, c++11-lang,
c++11-lib, c++14-lang, c++17-lang, or gcc-c++11-lib
plus, everything INDEX-11 shows with a dependency on lang/gcc9 now.
PR: 238330
Bump PORTREVISION for ports depending on the canonical version of GCC
defined via Mk/bsd.default-versions.mk which has moved from GCC 7.4 t
GCC 8.2 under most circumstances.
This includes ports
- with USE_GCC=yes or USE_GCC=any,
- with USES=fortran,
- using Mk/bsd.octave.mk which in turn features USES=fortran, and
- with USES=compiler specifying openmp, nestedfct, c11, c++0x, c++11-lang,
c++11-lib, c++14-lang, c++17-lang, or gcc-c++11-lib
plus, as a double check, everything INDEX-11 showed depending on lang/gcc7.
PR: 231590
Install texinfo files (GNU info) into ${PREFIX}/share/info
After a discussion on the mailing list on moving manpages to
${PREFIX}/share/man for consistency with base where it is
installed in usr/share/man, it appeared the same should happen
to GNU info files which were installed under share in base and
not in ports.
Now texinfo is not in base on any of the supported version of FreeBSD
it is possible to proceed to this move and it is easier to do than
the manpage change.
Other benefit than consistency are less patching: all build tools but
cmake are expecting info files to be under share/info and cmake (patched here)
was having an exception for BSD so the patch makes FreeBSD case less
specific for them
Bump revision of all impacted ports
PR: 232907
exp-run by: antoine
Differential Revision: https://reviews.freebsd.org/D17816
Bump PORTREVISION for ports depending on the canonical version of GCC
in the ports tree (via Mk/bsd.default-versions.mk and lang/gcc) which
has now moved from GCC 6 to GCC 7 by default.
This includes ports
- featuring USE_GCC=yes or USE_GCC=any,
- featuring USES=fortran,
- using Mk/bsd.octave.mk which in turn features USES=fortran, and those
- with USES=compiler specifying one of openmp, nestedfct, c11, c++0x,
c++11-lib, c++11-lang, c++14-lang, c++17-lang, or gcc-c++11-lib.
PR: 222542
Replace bsd.qt.mk by Uses/qt.mk and Uses/qt-dist.mk
From now on, ports that depend on Qt4 will have to set
USES= qt:4
USE_QT= foo bar
ports depending on Qt5 will use
USES= qt:5
USE_QT= foo bar
PR: 229225
Exp-run by: antoine
Reviewed by: mat
Approved by: portmgr (antoine)
Differential Revision: -https://reviews.freebsd.org/D15540
security/gpgme:
- Add some magic to support the regression tests in the case where the test
build directory path length exceeds the maximum socket path length.
- Fix shebang in the pinentry test script. At long last, the real reason some
of the tests were failing has been discovered!
- Remove files/patch-tests_gpg_Makefile.in now that the pinentry script is
fixed.
- Move USES upward.
security/gpgme-cpp:
- Remove workaround for Bug 193528 (fixed in GCC 6+)
security/gpgme-qt5:
- Add full test support.
- QT5 testlib only needed for tests at build time.
- Add DOXYGEN option to install the API documentation. Prevent the
automatic building of the docs if doxygen happens to be installed.
- Bump PORTREVISION due to added options / dependency change
security/py-gpgme:
- Add full test support.
- Revert flavor logic move from r460759. The logic being below
<bsd.port.options.mk> was the reason it wasn't previously working.
- Bump PORTREVISION due to added option
Add a TEST option to toggle in-build testing as it was causing trouble when
the test build directory path length was longer than the maximum socket path
length. A workaround to this problem is noted in the Makefile. [1]
Prevent the GNUPG1 option and the TEST option from being enabled simultaneously
since the tests mainly revolve around the programs supplied with GnuPG 2.x.
Disable in-build tests for slave ports for now.
Move the flavor logic for the python slave port into the slave port Makefile
as it was not being evaluated correctly when in the master port Makefile.
Reported by: tijl (via private mail) [1]
Convert Python ports to FLAVORS.
Ports using USE_PYTHON=distutils are now flavored. They will
automatically get flavors (py27, py34, py35, py36) depending on what
versions they support.
There is also a USE_PYTHON=flavors for ports that do not use distutils
but need FLAVORS to be set. A USE_PYTHON=noflavors can be set if
using distutils but flavors are not wanted.
A new USE_PYTHON=optsuffix that will add PYTHON_PKGNAMESUFFIX has been
added to cope with Python ports that did not have the Python
PKGNAMEPREFIX but are flavored.
USES=python now also exports a PY_FLAVOR variable that contains the
(Only the first 15 lines of the commit message are shown above )
Bump PORTREVISION for ports depending on the canonical version of GCC
(via Mk/bsd.default-versions.mk and lang/gcc) which has moved from
GCC 5.4 to GCC 6.4 under most circumstances.
This includes ports
- with USE_GCC=yes or USE_GCC=any,
- with USES=fortran,
- using Mk/bsd.octave.mk which in turn features USES=fortran, and
- with USES=compiler specifying openmp, nestedfct, c++11-lib, c++11-lang,
c++14-lang, c++0x, c11, or gcc-c++11-lib.
PR: 219275
Update security/gpgme and friends to 1.9.0 [1]
Fix LICENSE
Add regression test support for master port. Slave port tests are not working
properly and need further investigation.
PR: 218316 (based on) [1]
Submitted by: gahr [1]
Changes: https://lists.gnupg.org/pipermail/gnupg-users/2017-March/057963.html
Bump PORTREVISIONs for ports depending on the canonical version of GCC and
lang/gcc which have moved from GCC 4.9.4 to GCC 5.4 (at least under some
circumstances such as versions of FreeBSD or platforms).
This includes ports
- with USE_GCC=yes or USE_GCC=any,
- with USES=fortran,
- using using Mk/bsd.octave.mk which in turn has USES=fortran, and
- with USES=compiler specifying openmp, nestedfct, c++11-lib, c++14-lang,
c++11-lang, c++0x, c11, or gcc-c++11-lib.
PR: 216707
Rename python setuptools ports to better match other python ports
Reviewed by: mat, sunpoet
With hat: portmgr
Differential Revision: https://reviews.freebsd.org/D9983
Update security/gpgme-* to 1.8.0
In this version, libgpgme-pthread.so has been removed in favor of just
using libgpgme.so as the thread-safe library. PORTREVISION has been
bumped on all ports depending on security/gpgme so that any that may have
linked to -lgpgme-pthread will link to -lgpgme instead.
The Python module provided by security/py-gpgme has been renamed upstream
from pyme3 to gpg. This removes the conflict with security/py-pyme,
although security/py-gpgme is still the direct replacement of that
module.
Fix conflict between libqgpgme from deskutils/kdepimlibs4 and
security/qgpgme-qt5
Install the kde4 version of libqgpgme as libqgpgme4.
* Bump revision in affected dependencies -- not all ports using USE_KDE=pimlibs
actually link against libqgpgme.
* Remove conflict from security/gpgme-qt5
* Drop KDE3 hunks from patch-cmake__modules__FindQGpgme.cmake
PR: 212886
Reviewed by: rakuco
Approved by: rakuco (mentor)
Fix build of security/gpgme-qt5 with gcc49
In file included from qgpgmebackend.cpp:42:0:
../../../lang/cpp/src/engineinfo.h: In constructor
'GpgME::EngineInfo::Version::Version(const string&)':
../../../lang/cpp/src/engineinfo.h:47:17: error: 'sscanf' is not a
member of 'std'
std::sscanf(version.c_str(), "%d.%d.%d", &major, &minor, &patch) != 3) {
PR: 214687
Submitted by: tcberner
Using ports libc++ on non-leaf ports is problematic, as the requirement
basically flows to all ports that depend on gpgme-{cpp,qt5}. In particular,
sysutils/kf5-kwallet was breaking in FreeBSD 9.x because mismatches between
libc++ and libstdc++ from gcc48 were causing a gpgme symbol not to be found:
backendpersisthandler.cpp:(.text+0xf61): undefined reference to
`GpgME::Context::encrypt(std::vector<GpgME::Key, std::allocator<GpgME::Key> >
const&, GpgME::Data const&, GpgME::Data&, GpgME::Context::EncryptionFlags)'
Switch the build of both ports to lang/gcc on FreeBSD 9 and the system compiler
on FreeBSD 10:
* Use USES:compiler-c++11-lib instead of compiler-c++11-lang, as we do need a
C++11-compatible standard library. This causes the right compiler to be chosen
as described above.
* Set _GLIBCXX_USE_C99 so that gpgme-cpp builds with GCC 4.8 (std::to_string()
is not exposed by default on FreeBSD). Several other ports need to do the same.
* Add a few patches to fix the gpgme-qt5:
** patch-git_b4658f6a1 is a backport from an upstream commit to make the port
build with GCC 4.8 without errors.
** patch-lang_qt_src_qgpgmeencryptjob.cpp is a local workaround for the
std::bind() bug mentioned in ports r424451.
PR: 214575
Submitted by: rakuco
Fix build of the Qt interface on FreeBSD 10.2 and 10.3. On FreeBSD 10.1, it
builds without issue (and thats what I originally tested this on and assumed
it would work on later releases), but there seems to be a regression in the
c++ headers that appears to have happend in r278724, so use libc++ from ports.
libtool: compile: c++ -std=c++11 -DHAVE_CONFIG_H -I. -I../../..
-I../../../lang/cpp/src -I../../../src -I/usr/local/include/qt5/QtCore
-I/usr/local/include/qt5 -fpic -I/usr/local/include -I/usr/local/include
-DBUILDING_QGPGME -isystem /usr/local/include -O2 -pipe -fstack-protector
-isystem /usr/local/include -fno-strict-aliasing -isystem /usr/local/include
-MT qgpgmeencryptjob.lo -MD -MP -MF .deps/qgpgmeencryptjob.Tpo -c
qgpgmeencryptjob.cpp -fPIC -DPIC -o .libs/qgpgmeencryptjob.o
qgpgmeencryptjob.cpp:133:9: error: no matching function for call to 'bind'
run(std::bind(&encrypt,
^~~~~~~~~
(Only the first 15 lines of the commit message are shown above )
- Update security/gpgme to 1.7.0
- Convert to master port and add several slave ports for the newly added
c++, Qt5, and python bindings (security/gpgme-cpp, security/gpgme-qt5,
and security/py-gpgme, respectively)
- The Qt bindings currently provided by deskutils/kdepimlibs4
cannot currently coexist with these new bindings, but will be phased out
in the future
- The python bindings are an updated version of the ones provided by
security/py-pyme and are now being maintained as part of the gpgme project.
They work with both python 2.x and 3.x.
PR: 212886
security/gpgme: put header back in normal location.
This used to cause a conflict with security/gpgme03 but this port has been
removed many years ago now.
Approved by: jhale (maintainer)
- Update security/gpgme to 1.4.3
- Use USE_GNOME= ltverhack to correct the library version number
to what the author intended. This effectively rolls the version
number backwards, but should prevent future unneccesary version
bumps.
- Support staging
- Use options helpers
- Use new LIB_DEPENDS syntax
- Bump PORTREVISION on dependent ports
Fix the shared library version number for libassuan to reflect what
the authors intended by adding:
USE_AUTOTOOLS= libtool
USE_GNOME= ltverhack
to security/libassuan/Makefile.
Update the libassuan shared library version number and/or bump
PORTREVISION in the dependent ports.
Requested by: ale
Feature safe: yes
Update libassuan to version 2.0.1:
* Input and output notification handler can now really access the
parsed fd as stated in the manual.
* Cleaned up the logging.
Bump PORTREVISION and libassuan version number in related ports
- Update security/gpgme to version 1.3.0.
- No shlib bump.
- This version works with libassuan 2.x and is needed to fix the build of
security/gpa due to dependency conflicts.
- Add LICENSE
PR: ports/148061
- Fix the build of security/gpa with libassuan 2.x
- Patch for server.c taken from gpa svn.
- Add LICENSE while here.
PR: ports/148062
Submitted by: Jason E. Hale <bsdkaffee@gmail.com> (maintainer)
Feature safe: yes
-Repocopy devel/libtool15 -> libtool22 and libltdl15 -> libltdl22.
-Update libtool and libltdl to 2.2.6a.
-Remove devel/libtool15 and devel/libltdl15.
-Fix ports build with libtool22/libltdl22.
-Bump ports that depend on libltdl22 due to shared library version change.
-Explain what to do update in the UPDATING.
It has been tested with GNOME2, XFCE4, KDE3, KDE4 and other many wm/desktop
and applications in the runtime.
With help: marcus and kwm
Pointyhat-exp: a few times by pav
Tested by: pgollucci, "Romain Tartière" <romain@blogreen.org>, and
a few MarcusCom CVS users. Also, I might have missed a few.
Repocopy by: marcus
Approved by: portmgr
Update CONFIGURE_ARGS for how we pass CONFIGURE_TARGET to configure script.
Specifically, newer autoconf (> 2.13) has different semantic of the
configure target. In short, one should use --build=CONFIGURE_TARGET
instead of CONFIGURE_TARGET directly. Otherwise, you will get a warning
and the old semantic may be removed in later autoconf releases.
To workaround this issue, many ports hack the CONFIGURE_TARGET variable
so that it contains the ``--build='' prefix.
To solve this issue, under the fact that some ports still have
configure script generated by the old autoconf, we use runtime detection
in the do-configure target so that the proper argument can be used.
Changes to Mk/*:
- Add runtime detection magic in bsd.port.mk
(Only the first 15 lines of the commit message are shown above )
Number of commits found: 161 (showing only 100 on this page)