CVS: cvs.openbsd.org: ports
CVSROOT:/cvs Module name:ports Changes by: gkoeh...@cvs.openbsd.org2024/04/01 23:11:50 Modified files: graphics/decker: Makefile distinfo Log message: update graphics/decker to 1.41, from Jag Talon (maintainer) https://internet-janitor.itch.io/decker/devlog/698201/decker-141
Re: [maintainer update] graphics/decker 1.41
On Mon, 01 Apr 2024 19:10:46 +0800 "Jag Talon" wrote: > Bumping this diff for review! ty I committed it. Thanks for keeping decker up to date.
Re: lang/gbc write overflow
On Mon, 1 Apr 2024 08:36:08 -0400 "Ivan \"Rambius\" Ivanov" wrote: > Ok from me. I committed the patch. My subject was wrong; port is math/gbc, not lang/gbc.
CVS: cvs.openbsd.org: ports
CVSROOT:/cvs Module name:ports Changes by: rsadow...@cvs.openbsd.org 2024/04/01 22:47:10 Modified files: x11/qt6/qttools: Makefile Log message: Regen WANTLIB with llvm16
CVS: cvs.openbsd.org: ports
CVSROOT:/cvs Module name:ports Changes by: gkoeh...@cvs.openbsd.org2024/04/01 22:45:17 Modified files: math/gbc : Makefile Added files: math/gbc/patches: patch-bc_scan_l Log message: patch math/gbc for write overflow bc/scan.c wrote 8 bytes to a 4-byte int on LP64_ARCHS. This broke the build on big-endian powerpc64, which was reading the wrong end of the oversize value. It might have caused a bus error on sparc64. ok Ivan Ivanov (maintainer)
CVS: cvs.openbsd.org: ports
CVSROOT:/cvs Module name:ports Changes by: bl...@cvs.openbsd.org 2024/04/01 15:50:38 Modified files: textproc/xmlwf : Makefile distinfo Log message: Update expat to 2.6.2, keep xmlwf in sync with base libexpat. Set roach sites and url, maybe portroach finds the correct update.
CVS: cvs.openbsd.org: ports
CVSROOT:/cvs Module name:ports Changes by: na...@cvs.openbsd.org 2024/04/01 14:52:56 Modified files: multimedia/libmediainfo: Makefile distinfo multimedia/mediainfo: Makefile distinfo Log message: mediainfo: maintenance update to 24.03
CVS: cvs.openbsd.org: ports
CVSROOT:/cvs
Module name:ports
Changes by: na...@cvs.openbsd.org 2024/04/01 13:35:46
Modified files:
net/curl : Makefile distinfo
net/curl/pkg : PLIST
Removed files:
net/curl/patches: patch-lib_curl_ntlm_wb_c
Log message:
net/curl: security update to 8.7.1
Changes:
* CURLINFO_USED_PROXY: return bool whether the proxy was used
* digest: support SHA-512/256
* DoH: add trace configuration
* write-out: add '%{proxy_used}'
Includes fixes for
CVE-2024-2004: Usage of disabled protocol
CVE-2024-2398: HTTP/2 push headers memory-leak
Also install zsh and fish shell completions.
CVS: cvs.openbsd.org: ports
CVSROOT:/cvs Module name:ports Changes by: fcam...@cvs.openbsd.org 2024/04/01 13:29:32 Modified files: net/dbip : Makefile.inc net/dbip/asn : distinfo net/dbip/city : distinfo net/dbip/country: distinfo Log message: Update dbip to 2024.04.
CVS: cvs.openbsd.org: ports
CVSROOT:/cvs Module name:ports Changes by: pas...@cvs.openbsd.org 2024/04/01 13:03:54 Modified files: lang/gcc/8 : Makefile distinfo Log message: Update adastrap for powerpc.
[maintainer update] math/flintlib 3.0.1 -> 3.1.2
Updates to latest release and lets us drop a local patch to fix the
.pc file.
ok?
---
commit 4d05f8932bbac940cd5ebd42b0bcfbe3936259ee (flint_3.1.2)
from: Josh Rickmar
date: Mon Apr 1 16:07:05 2024 UTC
Update math/flintlib to 3.1.2
diff ea4f9dd253a362877e4c6058de04dbefc2206751
4d05f8932bbac940cd5ebd42b0bcfbe3936259ee
commit - ea4f9dd253a362877e4c6058de04dbefc2206751
commit + 4d05f8932bbac940cd5ebd42b0bcfbe3936259ee
blob - 4756265fba1a3c3cde91d3aa6ef76f33bf25702b
blob + 5590a52d8c4ab6429fec5a0805aacfcdae42c230
--- math/flintlib/Makefile
+++ math/flintlib/Makefile
@@ -2,17 +2,17 @@ COMMENT = fast library for number theory
DPB_PROPERTIES = parallel
-V =3.0.1
+V =3.1.2
PKGNAME = flintlib-${V}
DISTNAME = flint-${V}
-SHARED_LIBS = flint 0.0 # 18.0.1
+SHARED_LIBS = flint 1.0 # 19.0.0
CATEGORIES = math
HOMEPAGE = https://flintlib.org/
MAINTAINER = Josh Rickmar
-# LGPLv2
+# LGPLv3
PERMIT_PACKAGE = Yes
WANTLIB = m pthread gmp mpfr
blob - 73c2a747dead49117fb57144f013a444ef27b831
blob + a725f08337fb34d10c1d2a786a247e3b954ef4a0
--- math/flintlib/distinfo
+++ math/flintlib/distinfo
@@ -1,2 +1,2 @@
-SHA256 (flint-3.0.1.tar.gz) = ezEaAFA6hjiB64F32+uEMi8pOZ89fXLzsaTJuh1XlLQ=
-SIZE (flint-3.0.1.tar.gz) = 8162288
+SHA256 (flint-3.1.2.tar.gz) = /bOkMaN0ZINKz/O9wUX0/o0PlR3VMnxMb5P0y6xcJwA=
+SIZE (flint-3.1.2.tar.gz) = 8098136
blob - 79be49229c55fa8ae335b3ae269545e58a19d987
blob + 4cea7442ad09c81f7b3a7762a0e43261deb2419b
--- math/flintlib/patches/patch-Makefile_in
+++ math/flintlib/patches/patch-Makefile_in
@@ -1,159 +1,186 @@
Index: Makefile.in
--- Makefile.in.orig
+++ Makefile.in
-@@ -87,7 +87,7 @@ LIBS2:=-lflint $(LIBS)
- PIC_FLAG:=@PIC_FLAG@
+@@ -104,7 +104,7 @@ arith_CFLAGS:=-funroll-loops
+ endif
LDFLAGS:=@LDFLAGS@
--EXTRA_SHARED_FLAGS:=@EXTRA_SHARED_FLAGS@ $(foreach path, $(GMP_LIB_PATH)
$(MPFR_LIB_PATH) $(BLAS_LIB_PATH) $(GC_LIB_PATH) $(NTL_LIB_PATH),
@WL@-rpath,$(path))
-+EXTRA_SHARED_FLAGS:=-Wl,-soname,$(FLINT_LIB_FULL) $(foreach path,
$(GMP_LIB_PATH) $(MPFR_LIB_PATH) $(BLAS_LIB_PATH) $(GC_LIB_PATH)
$(NTL_LIB_PATH), @WL@-rpath,$(path))
- EXE_LDFLAGS:=$(LDFLAGS) $(foreach path, $(ABS_FLINT_DIR) $(GMP_LIB_PATH)
$(MPFR_LIB_PATH) $(BLAS_LIB_PATH) $(GC_LIB_PATH) $(NTL_LIB_PATH),
@WL@-rpath,$(path))
+-EXTRA_SHARED_FLAGS:=@EXTRA_SHARED_FLAGS@ $(foreach path, $(sort
$(GMP_LIB_PATH) $(MPFR_LIB_PATH) $(BLAS_LIB_PATH) $(GC_LIB_PATH)
$(NTL_LIB_PATH)), @WL@-rpath,$(path))
++EXTRA_SHARED_FLAGS:=-Wl,-soname,$(FLINT_LIB_FULL) $(foreach path, $(sort
$(GMP_LIB_PATH) $(MPFR_LIB_PATH) $(BLAS_LIB_PATH) $(GC_LIB_PATH)
$(NTL_LIB_PATH)), @WL@-rpath,$(path))
+ EXE_LDFLAGS:=$(LDFLAGS) $(foreach path, $(sort $(ABS_FLINT_DIR)
$(GMP_LIB_PATH) $(MPFR_LIB_PATH) $(BLAS_LIB_PATH) $(GC_LIB_PATH)
$(NTL_LIB_PATH)), @WL@-rpath,$(path))
-
-@@ -370,7 +370,7 @@ MERGED_LOBJS:=$(foreach dir, $(DIRS),$(BUILD_DIR)/$(di
+ # Obtain level of parallel
+@@ -427,11 +427,11 @@ MERGED_LOBJS:=$(foreach dir, $(DIRS),$(BUILD_DIR)/$(di
+
$(FLINT_DIR)/$(FLINT_LIB_FULL): $(MERGED_LOBJS)
- $(CC) $(CFLAGS) -shared $(EXTRA_SHARED_FLAGS) $(MERGED_LOBJS) -o
$(FLINT_LIB_FULL) $(LDFLAGS) $(LIBS)
- ifneq ($(FLINT_SOLIB), 0)
-- $(LDCONFIG) -n .
-+# $(LDCONFIG) -n .
+ @echo "Building $(FLINT_LIB_FULL)"
+- @$(CC) $(CFLAGS) -shared $(EXTRA_SHARED_FLAGS) $(MERGED_LOBJS) -o
$(FLINT_LIB_FULL) $(LDFLAGS) $(LIBS)
+- @$(RM_F) $(FLINT_LIB)
+- @$(RM_F) $(FLINT_LIB_MAJOR)
+- @$(LN_S) $(FLINT_LIB_FULL) $(FLINT_LIB)
+- @$(LN_S) $(FLINT_LIB_FULL) $(FLINT_LIB_MAJOR)
++ $(CC) $(CFLAGS) -shared $(EXTRA_SHARED_FLAGS) $(MERGED_LOBJS) -o
$(FLINT_LIB_FULL) $(LDFLAGS) $(LIBS)
++ $(RM_F) $(FLINT_LIB)
++ $(RM_F) $(FLINT_LIB_MAJOR)
++ $(LN_S) $(FLINT_LIB_FULL) $(FLINT_LIB)
++ $(LN_S) $(FLINT_LIB_FULL) $(FLINT_LIB_MAJOR)
endif
- $(RM_F) $(FLINT_LIB)
- $(RM_F) $(FLINT_LIB_MAJOR)
-@@ -511,8 +511,7 @@ endif
+
ifneq ($(STATIC), 0)
+@@ -582,14 +582,12 @@ endif
+ ifneq ($(STATIC), 0)
define xxx_OBJS_rule
$(BUILD_DIR)/$(1)/%.o: $(SRC_DIR)/$(1)/%.c | $(BUILD_DIR)/$(1)
-- @echo " CC $$(@:$(BUILD_DIR)/%=%)"
-- @$(CC) $(CFLAGS) $(CPPFLAGS) $(LIB_CPPFLAGS) -c $$< -o $$@ -MMD -MF
$$(@:%=%.d)
-+ $(CC) $(CFLAGS) $(CPPFLAGS) $(LIB_CPPFLAGS) -c $$< -o $$@ -MMD -MF
$$(@:%=%.d)
+- @echo " CC $$(<:$(SRC_DIR)/%=%)"
+- @$(CC) $(CFLAGS) $($(1)_CFLAGS) $(CPPFLAGS) $(LIB_CPPFLAGS) -c $$< -o
$$@ $$(DEPFLAGS)
++ $(CC) $(CFLAGS) $($(1)_CFLAGS) $(CPPFLAGS) $(LIB_CPPFLAGS) -c $$< -o
$$@ $$(DEPFLAGS)
endef
+ ifeq ($(WANT_ADX_ASSEMBLY),1)
+ %.o: %.s
+- @echo " CC $(<:$(BUILD_DIR)/%.s=%.asm)"
+- @$(CC) $(ASM_OBJ_FLAGS) -c $< -o $@
++
opensmtpd-filter-dkimsign: high memory usage
Hi, I am running an OpenSMTPD server with opensmtpd-filter-dkimsign-0.5p2 on OpenBSD 7.4 (amd64). I noticed recently that the dkimsign program was using a lot of memory: $ ps ax -orss,command | grep dkimsign 110920 /usr/local/libexec/smtpd/filter-dkimsign -d wsb.onl -s viper1 -k /etc/mai 304 grep dkimsign I am not a C programmer so maybe I am wrong, but it seems to me that over 100 MB is a lot for the simple program. And of course the relevant line in my smtpd.conf is the following: filter "dkimsign" proc-exec "filter-dkimsign -d wsb.onl -s viper1 \ -k /etc/mail/dkim/private.key" user _dkimsign group _dkimsign I am not sure if this memory usage is related to how long the program is being ran (server’s uptime is over 100 days), so I didn’t restart the dkimsign program to investigate. But I will be happy to provide more information if needed. Thanks, -- Songbo Wang
Re: [UPDATE]: security/kc - enable YubiKey support, add -yubikey flavor
Ping? Original Message On 27/03/2024 16:33, Lévai, Dániel wrote: > > Hi all, > > > > This is a patch to enable YubiKey support with a new -yubikey flavor. > > I invite anyone to test it; it works for me(tm), but requires some > fiddling with the USB device files - hence the package message. > > > > Any ideas, suggestions are welcome, > > Daniel > > Barring any objections, issues, what do you think about committing? > > Daniel signature.asc Description: OpenPGP digital signature
Re: lang/gbc write overflow
Ok from me.
On Wed, Mar 27, 2024, 7:04 PM George Koehler wrote:
> Here's a diff to fix GNU bc 1.07.1 in OpenBSD ports.
>
> Wrong code in bc/scan.c was using (yy_size_t *) to write to an
> int. This was an overflow on LP64_ARCHS, by writing 8 bytes to a
> 4-byte int. The problem was more obvious when big-endian.
>
> If we would read 51 bytes,
> - a little-endian amd64 would write (int []){51, 0}, so result = 51
>was correct, but the extra 0 clobbered 4 bytes of other memory.
> - my big-endian powerpc64 wrote (int []){0, 51}, so result = 0 caused
>an early end of file. This broke my powerpc64 build when bc tried
>to compile its math library, but the compiled code was empty.
>
> The new patch does "result = ...", so the C compiler writes the
> correct size. Now my powerpc64 can package and run gbc.
>
> The patch causes flex(1) to remake scan.c from scan.l. OpenBSD's
> flex changes result from int to yy_size_t, but "result = ..." should
> work with either type. (When I tried (int *), I built a broken
> bc that wrote 4 bytes to an 8-byte size.)
>
> Also delete BROKEN-sparc64, but I don't have a sparc64. I suspect
> that (yy_size_t *) was not a multiple of 8 and raised a SIGBUS
> for misalignment on sparc64, but I don't know.
>
> ok?
>
> Index: Makefile
> ===
> RCS file: /cvs/ports/math/gbc/Makefile,v
> diff -u -p -r1.6 Makefile
> --- Makefile27 Sep 2023 09:27:54 - 1.6
> +++ Makefile27 Mar 2024 22:04:45 -
> @@ -1,9 +1,7 @@
> -BROKEN-sparc64 = Bus error during build
> -
> COMMENT = GNU version of the arbitrary precision calculators bc and
> dc
> DISTNAME = bc-1.07.1
> PKGNAME = g${DISTNAME}
> -REVISION = 0
> +REVISION = 1
> CATEGORIES = math
>
> HOMEPAGE = https://www.gnu.org/software/bc/
> Index: patches/patch-bc_scan_l
> ===
> RCS file: patches/patch-bc_scan_l
> diff -N patches/patch-bc_scan_l
> --- /dev/null 1 Jan 1970 00:00:00 -
> +++ patches/patch-bc_scan_l 27 Mar 2024 22:04:45 -
> @@ -0,0 +1,74 @@
> +The cast (yy_size_t *) was wrong, because result was an int in
> +upstream's flex; this caused an overflow on LP64_ARCHS (by writing 8
> +bytes to a 4-byte int), which broke the build on powerpc64.
> +
> +This patch causes the build to run flex(1), overwriting scan.c from
> +upstream. OpenBSD's flex changes result from int to yy_size_t.
> +
> +Index: bc/scan.l
> +--- bc/scan.l.orig
> bc/scan.l
> +@@ -59,7 +59,7 @@ int yywrap (void);
> + /* Have input call the following function. */
> + #undef YY_INPUT
> + #define YY_INPUT(buf,result,max_size) \
> +- bcel_input((char *)buf, (yy_size_t *), max_size)
> ++ result = bcel_input((char *)buf, max_size)
> +
> + /* Variables to help interface editline with bc. */
> + static const char *bcel_line = (char *)NULL;
> +@@ -70,10 +70,11 @@ static int bcel_len = 0;
> +stdin, use editline. Otherwise, just read it.
> + */
> +
> +-static void
> +-bcel_input (char *buf, yy_size_t *result, int max)
> ++static int
> ++bcel_input (char *buf, int max)
> + {
> + ssize_t rdsize;
> ++ int result;
> + if (!edit || yyin != stdin)
> + {
> + while ( (rdsize = read( fileno(yyin), buf, max )) < 0 )
> +@@ -82,8 +83,7 @@ bcel_input (char *buf, yy_size_t *result, int max)
> + yyerror( "read() in flex scanner failed" );
> + bc_exit (1);
> + }
> +- *result = (yy_size_t) rdsize;
> +- return;
> ++ return rdsize;
> + }
> +
> + /* Do we need a new string? */
> +@@ -92,9 +92,8 @@ bcel_input (char *buf, yy_size_t *result, int max)
> + bcel_line = el_gets(edit, _len);
> + if (bcel_line == NULL) {
> + /* end of file */
> +- *result = 0;
> + bcel_len = 0;
> +- return;
> ++ return 0;
> + }
> + if (bcel_len != 0)
> + history (hist, , H_ENTER, bcel_line);
> +@@ -104,16 +103,17 @@ bcel_input (char *buf, yy_size_t *result, int max)
> + if (bcel_len <= max)
> + {
> + strncpy (buf, bcel_line, bcel_len);
> +- *result = bcel_len;
> ++ result = bcel_len;
> + bcel_len = 0;
> + }
> + else
> + {
> + strncpy (buf, bcel_line, max);
> +- *result = max;
> ++ result = max;
> + bcel_line += max;
> + bcel_len -= max;
> + }
> ++ return result;
> + }
> + #endif
> +
>
Re: archivers/pixz: new port (1.0.7)
Thomas Dettbarn wrote: > I know sir. > My apologies. > > What I actually meant to say was > > "Please, Sirs, somebody check the port! I am not qualified enough to > do so myself." That is why it was mailed out. So that people could review it. The peanut gallery who isn't going to review, has no right to make such a request or demand. It's quite simply very rude to assume all the people who will review aren't already doing so.
Re: archivers/pixz: new port (1.0.7)
I know sir. My apologies. What I actually meant to say was "Please, Sirs, somebody check the port! I am not qualified enough to do so myself." Thomas On 4/1/24 13:47, Theo de Raadt wrote: Thomas Dettbarn wrote: Hello. Yeah... You know how the social engineering part of this xz backhole was done? Somebody pressured the Maintainer, that he needs to add new features. Afterwards, the maintainers of distributions were pressured to update, because there were some "NEW FEATURES" available. Your post sounded eerie similar. As do some of the gitlog entries. Just my two cents... (I am sure that I have not yet earned the privilege to post it on this list, but I felt like I had to say something. Blame it on poor impulse control!) I think that is an uneducated take on the situation. It sounds like: "I can't really tell, but I'm very suspicious, I'm not going to put any effort into justifying my suspiciouns, but in the meantime maybe it is better if everyone stop all open source work of any sort immediately. Just my pointless two cents." On 4/1/24 12:55, Kirill A. Korinsky wrote: Folks, Despite of current security issue with xz/lzma the algortihm itself provides great compression, and the existing XZ Utils provide great compression in the .xz file format, but they produce just one big block of compressed data. Here, a new port which is called archivers/pixz which produces a collection of smaller blocks which makes random access to the original data possible. This is especially useful for large tarballs. This can be used as seprated application or via tar, that described on homepage: https://github.com/vasi/pixz -- wbr, Kirill
Re: archivers/pixz: new port (1.0.7)
Thomas Dettbarn wrote: > Hello. > > > Yeah... You know how the social engineering part of this xz > backhole was done? > > Somebody pressured the Maintainer, that he needs to add new > features. > > Afterwards, the maintainers of distributions were pressured to > update, because there were some "NEW FEATURES" available. > > Your post sounded eerie similar. As do some of the gitlog entries. > > > Just my two cents... > (I am sure that I have not yet earned the privilege to post it on this list, > but I felt like I had to say something. Blame it on poor impulse control!) I think that is an uneducated take on the situation. It sounds like: "I can't really tell, but I'm very suspicious, I'm not going to put any effort into justifying my suspiciouns, but in the meantime maybe it is better if everyone stop all open source work of any sort immediately. Just my pointless two cents." > On 4/1/24 12:55, Kirill A. Korinsky wrote: > > Folks, > > > > Despite of current security issue with xz/lzma the algortihm itself provides > > great compression, and the existing XZ Utils provide great compression in > > the .xz file format, but they produce just one big block of compressed data. > > > > Here, a new port which is called archivers/pixz which produces a collection > > of smaller blocks which makes random access to the original data possible. > > This is especially useful for large tarballs. > > > > This can be used as seprated application or via tar, that described on > > homepage: https://github.com/vasi/pixz > > > > -- > > wbr, Kirill >
Re: archivers/pixz: new port (1.0.7)
Hello. Yeah... You know how the social engineering part of this xz backhole was done? Somebody pressured the Maintainer, that he needs to add new features. Afterwards, the maintainers of distributions were pressured to update, because there were some "NEW FEATURES" available. Your post sounded eerie similar. As do some of the gitlog entries. Just my two cents... (I am sure that I have not yet earned the privilege to post it on this list, but I felt like I had to say something. Blame it on poor impulse control!) Thomas On 4/1/24 12:55, Kirill A. Korinsky wrote: Folks, Despite of current security issue with xz/lzma the algortihm itself provides great compression, and the existing XZ Utils provide great compression in the .xz file format, but they produce just one big block of compressed data. Here, a new port which is called archivers/pixz which produces a collection of smaller blocks which makes random access to the original data possible. This is especially useful for large tarballs. This can be used as seprated application or via tar, that described on homepage: https://github.com/vasi/pixz -- wbr, Kirill
Re: [maintainer update] graphics/decker 1.41
Bumping this diff for review! ty On Mon Mar 25, 2024 at 10:36 AM PST, Jag Talon wrote: > Bump version from 1.40 to 1.41. Changelog can be found here: > > https://internet-janitor.itch.io/decker/devlog/698201/decker-141 > > Tested on i386. Ok? -- Jag Talon (he/him) https://jagtalon.net/ https://weirder.earth/@jag 2F17E7825E755F08.asc Description: application/pgp-keys signature.asc Description: PGP signature
archivers/pixz: new port (1.0.7)
Folks, Despite of current security issue with xz/lzma the algortihm itself provides great compression, and the existing XZ Utils provide great compression in the .xz file format, but they produce just one big block of compressed data. Here, a new port which is called archivers/pixz which produces a collection of smaller blocks which makes random access to the original data possible. This is especially useful for large tarballs. This can be used as seprated application or via tar, that described on homepage: https://github.com/vasi/pixz -- wbr, Kirill pixz-1.0.7.tgz Description: Binary data
[Update from Maintainer] games/mvdsv v1.00
Hi,
Below is a diff to update games/mvdsv from 0.36 to 1.00.
Changelog:
Improvements
Reduce memory during loadmap (dsvensson)
Enable pm_bunnyspeedcap cvar (ceeeKay)
DOWNLOAD: bump download speed (qqshka)
DEMO: add epoch time to fullserverinfo (ciscon)
Bugfixes
laststats connectionless command responds with invalid json (vikpe)
Patch line numbers slightly updated but aside from that no changes to
the port.
Thanks,
Tom
Index: Makefile
===
RCS file: /cvs/ports/games/mvdsv/Makefile,v
diff -u -p -u -p -r1.10 Makefile
--- Makefile12 Nov 2023 17:58:31 - 1.10
+++ Makefile1 Apr 2024 10:11:10 -
@@ -3,7 +3,7 @@ COMMENT = QuakeWorld server
CATEGORIES = games
QUAKE_COMMIT = bf4ac424ce754894ac8f1dae6a3981954bc9852d
-DIST_TUPLE += github QW-Group mvdsv 0.36 .
+DIST_TUPLE += github QW-Group mvdsv v1.00 .
DIST_TUPLE += github QW-Group qwprot 53af547d0608a1507895fc1629cdc3f4820fc0af
src/qwprot
DIST_TUPLE += github id-software Quake ${QUAKE_COMMIT} .
Index: distinfo
===
RCS file: /cvs/ports/games/mvdsv/distinfo,v
diff -u -p -u -p -r1.5 distinfo
--- distinfo12 Nov 2023 17:58:31 - 1.5
+++ distinfo1 Apr 2024 10:11:10 -
@@ -1,6 +1,6 @@
-SHA256 (QW-Group-mvdsv-0.36.tar.gz) =
jyoHILfjcMyqejVQTA59165akFGzbpS3jWUlbzTpuOk=
+SHA256 (QW-Group-mvdsv-v1.00.tar.gz) =
Lon/SIERCWIpompgImcB5yQfQ6vI6/6YWmwmaqs39MM=
SHA256 (QW-Group-qwprot-53af547d0608a1507895fc1629cdc3f4820fc0af.tar.gz) =
+nkEALY4D495qX9h2LdciMAwR3CWcT6ewRLjBUsuxFA=
SHA256 (id-software-Quake-bf4ac424ce754894ac8f1dae6a3981954bc9852d.tar.gz) =
+5joyZdAEj8/rIMME4dYTsH2hNuJCMv0K3GH0G05kBM=
-SIZE (QW-Group-mvdsv-0.36.tar.gz) = 551595
+SIZE (QW-Group-mvdsv-v1.00.tar.gz) = 552652
SIZE (QW-Group-qwprot-53af547d0608a1507895fc1629cdc3f4820fc0af.tar.gz) = 8815
SIZE (id-software-Quake-bf4ac424ce754894ac8f1dae6a3981954bc9852d.tar.gz) =
2958901
Index: patches/patch-src_sv_ccmds_c
===
RCS file: /cvs/ports/games/mvdsv/patches/patch-src_sv_ccmds_c,v
diff -u -p -u -p -r1.3 patch-src_sv_ccmds_c
--- patches/patch-src_sv_ccmds_c24 Aug 2022 03:24:32 - 1.3
+++ patches/patch-src_sv_ccmds_c1 Apr 2024 10:11:10 -
@@ -5,7 +5,7 @@ at: https://github.com/deurk/mvdsv/pull/
Index: src/sv_ccmds.c
--- src/sv_ccmds.c.orig
+++ src/sv_ccmds.c
-@@ -741,54 +741,6 @@ void SV_ChmodFile_f (void)
+@@ -744,54 +744,6 @@ void SV_ChmodFile_f (void)
}
#endif //_WIN32
@@ -60,7 +60,7 @@ Index: src/sv_ccmds.c
/*
==
SV_Kick_f
-@@ -1847,8 +1799,6 @@ void SV_InitOperatorCommands (void)
+@@ -1853,8 +1805,6 @@ void SV_InitOperatorCommands (void)
Cmd_AddCommand ("chmod", SV_ChmodFile_f);
#endif //_WIN32
//<-
devel/qcoro: qt6 flavor
Simple flavor to install either qt5 and qt6 or both.
Works out of box. OK?
Rafael Sadowski
diff --git a/devel/qcoro/Makefile b/devel/qcoro/Makefile
index d2aa7d94930..bd9c2d193d6 100644
--- a/devel/qcoro/Makefile
+++ b/devel/qcoro/Makefile
@@ -1,8 +1,9 @@
COMMENT = C++ coroutines for Qt
+V =0.10.0
GH_ACCOUNT = danvratil
GH_PROJECT = qcoro
-GH_TAGNAME = v0.10.0
+GH_TAGNAME = v${V}
CATEGORIES = devel
@@ -13,16 +14,25 @@ MAINTAINER =Rafael Sadowski
# MIT
PERMIT_PACKAGE = Yes
+FLAVORS= qt6
+FLAVOR ?=
+
# Coroutines are part of C++ 20 and implemented in GCC 10
COMPILER = base-clang ports-clang
-MODULES = devel/cmake \
- x11/qt5
+MODULES = devel/cmake
-BUILD_DEPENDS =x11/qt5/qtwebsockets
+.if ${FLAVOR:Mqt6}
+FULLPKGNAME= qcoro-qt6-${V}
+MODULES += x11/qt6
+BUILD_DEPENDS =x11/qt6/qtwebsockets
+.else
+MODULES += x11/qt5
+BUILD_DEPENDS =x11/qt5/qtwebsockets
-CONFIGURE_ARGS = -DCMAKE_DISABLE_FIND_PACKAGE_Qt6=ON \
- -DUSE_QT_VERSION=5
+CONFIGURE_ARGS =-DCMAKE_DISABLE_FIND_PACKAGE_Qt6=ON \
+ -DUSE_QT_VERSION=5
+.endif
TEST_IS_INTERACTIVE = X11
diff --git a/devel/qcoro/pkg/PFRAG.no-qt6 b/devel/qcoro/pkg/PFRAG.no-qt6
new file mode 100644
index 000..cc975529b7a
--- /dev/null
+++ b/devel/qcoro/pkg/PFRAG.no-qt6
@@ -0,0 +1,138 @@
+include/qcoro5/
+include/qcoro5/QCoro/
+include/qcoro5/QCoro/QCoro
+include/qcoro5/QCoro/QCoroAbstractSocket
+include/qcoro5/QCoro/QCoroAsyncGenerator
+include/qcoro5/QCoro/QCoroCore
+include/qcoro5/QCoro/QCoroDBus
+include/qcoro5/QCoro/QCoroDBusPendingCall
+include/qcoro5/QCoro/QCoroDBusPendingReply
+include/qcoro5/QCoro/QCoroFuture
+include/qcoro5/QCoro/QCoroFwd
+include/qcoro5/QCoro/QCoroGenerator
+include/qcoro5/QCoro/QCoroIODevice
+include/qcoro5/QCoro/QCoroImageProvider
+include/qcoro5/QCoro/QCoroLocalSocket
+include/qcoro5/QCoro/QCoroNetwork
+include/qcoro5/QCoro/QCoroNetworkReply
+include/qcoro5/QCoro/QCoroProcess
+include/qcoro5/QCoro/QCoroQml
+include/qcoro5/QCoro/QCoroQmlTask
+include/qcoro5/QCoro/QCoroSignal
+include/qcoro5/QCoro/QCoroTask
+include/qcoro5/QCoro/QCoroTcpServer
+include/qcoro5/QCoro/QCoroTest
+include/qcoro5/QCoro/QCoroThread
+include/qcoro5/QCoro/QCoroTimer
+include/qcoro5/QCoro/QCoroWebSocket
+include/qcoro5/QCoro/QCoroWebSocketServer
+include/qcoro5/QCoro/QCoroWebSockets
+include/qcoro5/QCoro/Task
+include/qcoro5/qcoro/
+include/qcoro5/qcoro/concepts_p.h
+include/qcoro5/qcoro/config.h
+include/qcoro5/qcoro/coroutine.h
+include/qcoro5/qcoro/impl/
+include/qcoro5/qcoro/impl/connect.h
+include/qcoro5/qcoro/impl/isqprivatesignal.h
+include/qcoro5/qcoro/impl/task.h
+include/qcoro5/qcoro/impl/taskawaiterbase.h
+include/qcoro5/qcoro/impl/taskfinalsuspend.h
+include/qcoro5/qcoro/impl/taskpromise.h
+include/qcoro5/qcoro/impl/taskpromisebase.h
+include/qcoro5/qcoro/impl/waitfor.h
+include/qcoro5/qcoro/macros_p.h
+include/qcoro5/qcoro/qcoro.h
+include/qcoro5/qcoro/qcoroabstractsocket.h
+include/qcoro5/qcoro/qcoroasyncgenerator.h
+include/qcoro5/qcoro/qcorocore.h
+include/qcoro5/qcoro/qcorocore_export.h
+include/qcoro5/qcoro/qcorodbus.h
+include/qcoro5/qcoro/qcorodbus_export.h
+include/qcoro5/qcoro/qcorodbuspendingcall.h
+include/qcoro5/qcoro/qcorodbuspendingreply.h
+include/qcoro5/qcoro/qcorofuture.h
+include/qcoro5/qcoro/qcorofwd.h
+include/qcoro5/qcoro/qcorogenerator.h
+include/qcoro5/qcoro/qcoroimageprovider.h
+include/qcoro5/qcoro/qcoroiodevice.h
+include/qcoro5/qcoro/qcorolocalsocket.h
+include/qcoro5/qcoro/qcoronetwork.h
+include/qcoro5/qcoro/qcoronetwork_export.h
+include/qcoro5/qcoro/qcoronetworkreply.h
+include/qcoro5/qcoro/qcoroprocess.h
+include/qcoro5/qcoro/qcoroqml.h
+include/qcoro5/qcoro/qcoroqml_export.h
+include/qcoro5/qcoro/qcoroqmltask.h
+include/qcoro5/qcoro/qcoroquick_export.h
+include/qcoro5/qcoro/qcorosignal.h
+include/qcoro5/qcoro/qcorotask.h
+include/qcoro5/qcoro/qcorotcpserver.h
+include/qcoro5/qcoro/qcorotest.h
+include/qcoro5/qcoro/qcorothread.h
+include/qcoro5/qcoro/qcorotimer.h
+include/qcoro5/qcoro/qcorowebsocket.h
+include/qcoro5/qcoro/qcorowebsockets.h
+include/qcoro5/qcoro/qcorowebsockets_export.h
+include/qcoro5/qcoro/qcorowebsocketserver.h
+include/qcoro5/qcoro/task.h
+include/qcoro5/qcoro/waitoperationbase_p.h
+lib/cmake/
+lib/cmake/QCoro5/
+lib/cmake/QCoro5/QCoro5Config.cmake
+lib/cmake/QCoro5/QCoro5ConfigVersion.cmake
+lib/cmake/QCoro5Core/
+lib/cmake/QCoro5Core/QCoro5CoreConfig.cmake
+lib/cmake/QCoro5Core/QCoro5CoreConfigVersion.cmake
+lib/cmake/QCoro5Core/QCoro5CoreTargets${MODCMAKE_BUILD_SUFFIX}
+lib/cmake/QCoro5Core/QCoro5CoreTargets.cmake
+lib/cmake/QCoro5Coro/
+lib/cmake/QCoro5Coro/QCoro5CoroConfig.cmake
+lib/cmake/QCoro5Coro/QCoro5CoroConfigVersion.cmake
+lib/cmake/QCoro5Coro/QCoro5CoroTargets.cmake
+lib/cmake/QCoro5Coro/QCoroMacros.cmake
+lib/cmake/QCoro5DBus/
+lib/cmake/QCoro5DBus/QCoro5DBusConfig.cmake
Re: NEW: multimedia/phonon-qt6 and multimedia/phonon-backend/vlc-qt6
Can anyone look at it? On Fri Mar 22, 2024 at 07:36:45PM +0100, Rafael Sadowski wrote: > ping ;) > > On Thu Mar 14, 2024 at 09:43:20PM +0100, Rafael Sadowski via ports wrote: > > Now with attachment... > > > > On Thu Mar 14, 2024 at 09:42:07PM +0100, Rafael Sadowski via ports wrote: > > > I would like to import multimedia/phonon-backend/vlc-qt6 > > > multimedia/phonon-qt6. Please find tarball attached. This import does > > > not create any conflicts but it needs a simple adjustment > > > > > > Looking for post-lock import OKs. > > > > > > Rafael > > > > > > ? vlc-qt6 > > > Index: Makefile.inc > > > === > > > RCS file: /cvs/ports/multimedia/phonon-backend/Makefile.inc,v > > > diff -u -p -r1.10 Makefile.inc > > > --- Makefile.inc 6 Jan 2024 15:21:43 - 1.10 > > > +++ Makefile.inc 14 Mar 2024 20:40:07 - > > > @@ -2,5 +2,3 @@ CATEGORIES += multimedia > > > > > > # LGPL 2.1 > > > PERMIT_PACKAGE = Yes > > > - > > > -LIB_DEPENDS += multimedia/phonon>=4.12.0 > > > Index: gstreamer/Makefile > > > === > > > RCS file: /cvs/ports/multimedia/phonon-backend/gstreamer/Makefile,v > > > diff -u -p -r1.33 Makefile > > > --- gstreamer/Makefile6 Jan 2024 15:21:43 - 1.33 > > > +++ gstreamer/Makefile14 Mar 2024 20:40:07 - > > > @@ -21,7 +21,8 @@ RUN_DEPENDS = multimedia/gstreamer1/plug > > > multimedia/gstreamer1/plugins-libav \ > > > x11/gtk+4,-guic > > > > > > -LIB_DEPENDS =multimedia/gstreamer1/core \ > > > +LIB_DEPENDS =multimedia/phonon>=4.12.0 \ > > > + multimedia/gstreamer1/core \ > > > multimedia/gstreamer1/plugins-base \ > > > x11/qt5/qtx11extras > > > > > > Index: vlc/Makefile > > > === > > > RCS file: /cvs/ports/multimedia/phonon-backend/vlc/Makefile,v > > > diff -u -p -r1.17 Makefile > > > --- vlc/Makefile 6 Jan 2024 15:21:43 - 1.17 > > > +++ vlc/Makefile 14 Mar 2024 20:40:07 - > > > @@ -12,7 +12,8 @@ MODULES = devel/kf5 > > > > > > BUILD_DEPENDS = devel/gettext,-tools > > > > > > -LIB_DEPENDS =x11/vlc > > > +LIB_DEPENDS =multimedia/phonon>=4.12.0 \ > > > + x11/vlc > > > > > > NO_TEST =Yes > > > > > > > >
