Re: security/gpgme -qt6
This needs something more, the qt-headers package needs to be knocked out
unless one of the qt versions is built.
--
Sent from a phone, apologies for poor formatting.
On 14 March 2024 20:09:15 "Rafael Sadowski via ports"
wrote:
Based on the fantastic work of jca@, below is a diff to add -qt6 flavor
support in gpgme. I have added the cmake qt6 tweak that we can see in
-qt5.
The diff needs a simple MODQT_ENV_SETUP tweak in qt6 and qt5. (Diff in a
different mail)
Looking for OKs after the look.
Rafael
diff --git a/security/gpgme/Makefile b/security/gpgme/Makefile
index 67bbcb43657..9ebd69008d9 100644
--- a/security/gpgme/Makefile
+++ b/security/gpgme/Makefile
@@ -1,16 +1,26 @@
COMMENT-main = GnuPG Made Easy
+COMMENT-qt-headers = Qt headers for GPGme
COMMENT-qt =Qt bindings for GPGme
+COMMENT-qt6 = Qt6 bindings for GPGme
VERSION = 1.23.2
+REVISION-main =0
+REVISION-qt = 0
+
DISTNAME = gpgme-${VERSION}
PKGNAME-main = gpgme-${VERSION}
+PKGNAME-qt-headers = gpgme-qt-headers-${VERSION}
PKGNAME-qt =gpgme-qt-${VERSION}
+PKGNAME-qt6 = gpgme-qt6-${VERSION}
+
+PKG_ARCH-qt-headers = *
CATEGORIES =security devel
SHARED_LIBS += gpgme24.2 # 43.0
SHARED_LIBS += gpgmepp 3.3 # 26.0
SHARED_LIBS += qgpgme 3.2 # 20.0
+SHARED_LIBS += qgpgmeqt60.0 # 20.0
HOMEPAGE = https://www.gnupg.org/software/gpgme/
@@ -20,44 +30,80 @@ EXTRACT_SUFX = .tar.bz2
# GPLv2 - LGPLv2.1
PERMIT_PACKAGE= Yes
-WANTLIB = assuan gpg-error iconv intl
-WANTLIB-main = ${WANTLIB} c m
-WANTLIB-qt = ${COMPILER_LIBCXX} ${WANTLIB} Qt5Core double-conversion
-WANTLIB-qt += execinfo glib-2.0 gpgme gthread-2.0 icudata icui18n icuuc
-WANTLIB-qt += m pcre2-8 pcre2-16 z zstd
+WANTLIB-main = ${COMPILER_LIBCXX} assuan c gpg-error iconv intl m
+WANTLIB-qt-headers =
+WANTLIB-qt += ${COMPILER_LIBCXX} Qt5Core assuan double-conversion
+WANTLIB-qt += execinfo glib-2.0 gpg-error gpgme gpgmepp gthread-2.0
+WANTLIB-qt += iconv icudata icui18n icuuc intl m pcre2-16 pcre2-8
+WANTLIB-qt += z zstd
+WANTLIB-qt6 += ${COMPILER_LIBCXX} Qt6Core assuan b2 double-conversion
+WANTLIB-qt6 += execinfo glib-2.0 gpg-error gpgme gpgmepp gthread-2.0
+WANTLIB-qt6 += iconv icudata icui18n icuuc intl m pcre2-16 pcre2-8
+WANTLIB-qt6 += z zstd
COMPILER = base-clang ports-gcc
-MULTI_PACKAGES = -main -qt
-PSEUDO_FLAVORS = no_qt
-FLAVOR ?=
+MULTI_PACKAGES = -main -qt-headers -qt -qt6
+# XXX we forcefully set either no_qt or no_qt6,
+# is "bootstrap" doing anything useful?
+PSEUDO_FLAVORS = no_qt no_qt6 bootstrap qt6
+FLAVOR ?= no_qt6 bootstrap
+
+.if ${FLAVOR:Mqt6}
+# Cannot build both qt5 and qt6 at the same time
+# FLAVOR="qt6 no_qt6" makes no sense
+FLAVOR := no_qt ${FLAVOR:Nno_qt6}
+.elif !${FLAVOR:Mno_qt*} && !${FLAVOR:Mqt6}
+# XXX will portcheck STFU?!?
+FLAVOR += no_qt6
+.endif
-# don't depend on Qt5 on arches where it's known to fail
+# don't depend on Qt on arches where it's known to fail
+# XXX needs MODQT_NOT_FOR_ARCHS?
NOT_FOR_ARCHS-qt = alpha mips64 sh
+NOT_FOR_ARCHS-qt6 =alpha mips64 sh
CONFIGURE_STYLE = gnu
BUILD_DEPENDS = security/gnupg>=2.2.23p1
RUN_DEPENDS = security/gnupg>=2.2.23p1
-LIB_DEPENDS-main = ${LIB_DEPENDS:N*qt*} \
- devel/gettext,-runtime \
+LIB_DEPENDS-main = devel/gettext,-runtime \
security/libgpg-error>=1.4 \
security/libassuan
+LIB_DEPENDS-qt-headers =
+RUN_DEPENDS-qt-headers =
+# XXX WIP: not accurate enough, should handle REVISION
+LIB_DEPENDS-qt += ${MODQT5_LIB_DEPENDS} \
+ gpgme-=${VERSION}:${BUILD_PKGPATH},-main
+RUN_DEPENDS-qt =
gpgme-qt-headers-=${VERSION}:${BUILD_PKGPATH},-qt-headers
+LIB_DEPENDS-qt6 += ${MODQT6_LIB_DEPENDS} \
+ gpgme-=${VERSION}:${BUILD_PKGPATH},-main
+RUN_DEPENDS-qt6 =
gpgme-qt-headers-=${VERSION}:${BUILD_PKGPATH},-qt-headers
CONFIGURE_ENV +=CPPFLAGS="-I${LOCALBASE}/include" \
LDFLAGS="-L${LOCALBASE}/lib" \
ac_cv_prog_DOXYGEN=false
-.include
+MODQT_DEPS = No
+MODQT_ENV_SETUP = No
-.if ${BUILD_PACKAGES:M-qt}
-MODULES += x11/qt5
+.include
+.if ${BUILD_PACKAGES:M-qt} && ${BUILD_PACKAGES:M-qt6}
+ERRORS += "Cannot build Qt and Qt6 support at the same time."
+.elif ${BUILD_PACKAGES:M-qt}
+MODULES += x11/qt5 \
+ x11/qt6
+MODQT5_DEPS = Yes
+MODQT5_ENV_SETUP = Yes
CONFIGURE_ARGS += --enable-languages='cpp qt'
-LIB_DEPENDS-qt += ${LIB_DEPENDS} \
- gpgme-=${VERSION}:${BUILD_PKGPATH},-main
+.elif ${BUILD_PACKAGES:M-qt6}
+MODULES += x11/qt6 \
+ x11/qt5
+MODQT6_DEPS = Yes
+MODQT6_ENV_SETUP = Yes
+CONFIGURE_ARGS +=
Re: HOTFIX games/{bugdom,bugdom2,nanosaur,mightymike,ottomatic,billyfrontier} on sparc64
On 2024/03/13 19:36, Tobias Heider via ports wrote: > > > On March 13, 2024 7:24:26 PM GMT+01:00, Stuart Henderson via ports > wrote: > >On 2024/03/13 12:31, izder456 via ports wrote: > >> Hey ports@- > >> > >> Looks like these ports I take MAINTAINER on fail on sparc64 with the > >> same u8string error, which AFAIK is a C++20 thing. > >> > >> From what it looks like, sparc64 doesn't have a C++20 compiler, so they > >> unfortunately will be broken on that arch. > >> > >> Attached are diffs that adds BROKEN-sparc64 to those ports. > > > >I think something like this would be preferable > > > ># requires C++20 > >COMPILER = base-clang > > > > but then you could also add ports clang and ports gcc right? > they should also support newer c++ versions Could try it, but it seems fairly doubtful that they'll be good enough, c++20 support in gcc 8 was pretty limited (and uses -std=c++2a not -std=c++20), and ports-clang on base-gcc archs uses libestdc++ from gcc 8. (gcc/11 is in the ports tree but can't be used in bulks unless all c++ ports on whichever arch are switched from 8 to 11 otherwise there will be build conflicts).
Re: HOTFIX games/{bugdom,bugdom2,nanosaur,mightymike,ottomatic,billyfrontier} on sparc64
On 2024/03/13 12:31, izder456 via ports wrote: > Hey ports@- > > Looks like these ports I take MAINTAINER on fail on sparc64 with the > same u8string error, which AFAIK is a C++20 thing. > > From what it looks like, sparc64 doesn't have a C++20 compiler, so they > unfortunately will be broken on that arch. > > Attached are diffs that adds BROKEN-sparc64 to those ports. I think something like this would be preferable # requires C++20 COMPILER = base-clang
Re: [UPDATE] emulators/dosbox-x-2024.03.01
On 2024/03/08 21:58, SASANO Takayoshi wrote: > Hi, > > here is the diff for dosbox-x 2023.10.06 -> 2024.03.01. This broke the build on i386, esfmu/esfm.c:1849:5: error: inline assembly requires more registers than available "movzbl %b[wave], %%eax \n\t" ^ It's too late to fix for release now.
Re: UPDATE FIX: devel/fast_float distinfo
On 2024/03/13 13:33, Jose Maldonado wrote:
>
> Hi list!
>
> I've seen a new update to fast_float (library required for the new
> libplacebo and mpv) that could affect the 7.5 and -current package
> builds due to a change in the project's Github.
Unimportant for release, it's on the bulk build machines already, and
is on one of the fallback distfiles sites.
> The change has been added through a commit [1] that fixes a typo in the
> version of the project in CmakeList.txt, but from upstream instead of
> creating a new version (6.1.1), they have decided to include the change
> and keep calling the version as 6.1.0, breaking the old distinfo.
That's a nuisance, it would be helpful if projects wouldn't do that.
That's not the only change - float_common.h was modified too, so it will
also need a REVISION bump.
https://github.com/fastfloat/fast_float/commit/55a5b3c8e136a6f55cbb13829f284bdc7150567c
#include
#include
#ifdef __has_include
- #if __has_include()
+ #if __has_include() && (__cplusplus > 202002L || _MSVC_LANG >
202002L)
#include
#endif
#endif
> This patch solves the problem and unlocks the port build.
The distfile needs to be renamed via the filename{url}sufx mechanism
if the contents have changed. Builds are done from machines with
varying states of the ports tree (it's common to have the build machine
for one arch on one ports checkout and another on a newer one - except
for the special case of release builds, this is the normal situation).
For the main build machines there's a common distfiles directory shared
over NFS, so it's a problem if one machine fetches a new file to match
what it needs, while another is still building and expecting an old
version.
A diff something like this will work, though if there's a new version
upstream before we're ready to reopen commits we might as well just
change to that instead.
Index: Makefile
===
RCS file: /cvs/ports/devel/fast-float/Makefile,v
diff -u -p -r1.1.1.1 Makefile
--- Makefile13 Feb 2024 19:45:52 - 1.1.1.1
+++ Makefile13 Mar 2024 18:00:59 -
@@ -2,9 +2,11 @@ COMMENT = fast and exact implementation
V =6.1.0
PKGNAME = fast-float-${V}
+REVISION = 0
GH_TAGNAME = v${V}
GH_ACCOUNT = fastfloat
GH_PROJECT = fast_float
+DISTFILES =fast_float-{v}${V}-0.tar.gz
CATEGORIES = devel
Index: distinfo
===
RCS file: /cvs/ports/devel/fast-float/distinfo,v
diff -u -p -r1.1.1.1 distinfo
--- distinfo13 Feb 2024 19:45:52 - 1.1.1.1
+++ distinfo13 Mar 2024 18:00:59 -
@@ -1,2 +1,2 @@
-SHA256 (fast_float-6.1.0.tar.gz) = qcjKjKfWjC27E0Q0BE+cZs/Uw4PV6Fw2twTTD2voJQY=
-SIZE (fast_float-6.1.0.tar.gz) = 95974
+SHA256 (fast_float-6.1.0-0.tar.gz) =
WmKeHxjwN60AFsQerWMOpHHMy832AjntNGbEkdjnyQg=
+SIZE (fast_float-6.1.0-0.tar.gz) = 96104
