[Maintainer Update]devel/p5-CPAN-Perl-Releases: Update to 5.20230220.
Hi, ports@: Here is a simple patch for devel/p5-CPAN-Perl-Releases to update to 5.20230220. It build well and pass all tests on amd64-current system. No other ports depend on it. Cheers ! wenIndex: Makefile === RCS file: /cvs/ports/devel/p5-CPAN-Perl-Releases/Makefile,v retrieving revision 1.3 diff -u -p -r1.3 Makefile --- Makefile14 Feb 2023 09:24:39 - 1.3 +++ Makefile21 Feb 2023 06:34:18 - @@ -1,6 +1,6 @@ COMMENT = mapping Perl releases to the location of the tarballs -DISTNAME = CPAN-Perl-Releases-5.20230120 +DISTNAME = CPAN-Perl-Releases-5.20230220 CATEGORIES = devel Index: distinfo === RCS file: /cvs/ports/devel/p5-CPAN-Perl-Releases/distinfo,v retrieving revision 1.2 diff -u -p -r1.2 distinfo --- distinfo14 Feb 2023 09:24:39 - 1.2 +++ distinfo21 Feb 2023 06:34:18 - @@ -1,2 +1,2 @@ -SHA256 (CPAN-Perl-Releases-5.20230120.tar.gz) = j6LL2nok4YqhvCDyykZo5hWhK8lZghjHGM4Bpv+GUoQ= -SIZE (CPAN-Perl-Releases-5.20230120.tar.gz) = 22526 +SHA256 (CPAN-Perl-Releases-5.20230220.tar.gz) = XdMNV2+FkzdqiV/UiHEIFhF3jTpsWega0ZGvnPlCuks= +SIZE (CPAN-Perl-Releases-5.20230220.tar.gz) = 22538
[Maintainer update]mail/p5-Mail-AuthenticationResults: Update to 2.20230112
Hi, ports@: Here is simple patch for mail/p5-Mail-AuthenticationResults to update to 2.20230112. It build well and pass all tests on amd64-current system. Only 1 port depends on it: mail/p5-Mail-DKIM. It build well and pass all tests with this patch. Comments ? wenIndex: Makefile === RCS file: /cvs/ports/mail/p5-Mail-AuthenticationResults/Makefile,v retrieving revision 1.7 diff -u -p -r1.7 Makefile --- Makefile11 Mar 2022 19:34:48 - 1.7 +++ Makefile21 Feb 2023 06:25:55 - @@ -1,6 +1,6 @@ COMMENT = object oriented Authentication-Results headers -DISTNAME = Mail-AuthenticationResults-2.20210915 +DISTNAME = Mail-AuthenticationResults-2.20230112 CATEGORIES = mail Index: distinfo === RCS file: /cvs/ports/mail/p5-Mail-AuthenticationResults/distinfo,v retrieving revision 1.5 diff -u -p -r1.5 distinfo --- distinfo20 Dec 2021 14:46:41 - 1.5 +++ distinfo21 Feb 2023 06:25:55 - @@ -1,2 +1,2 @@ -SHA256 (Mail-AuthenticationResults-2.20210915.tar.gz) = wpe8m7GvKjcgHbmSDhy14vWBAkcT9cWxNfQUAuyU4Q8= -SIZE (Mail-AuthenticationResults-2.20210915.tar.gz) = 31535 +SHA256 (Mail-AuthenticationResults-2.20230112.tar.gz) = wtFEyuAiX4vJ0PX60cPxOdJ89TT85+rHB2T79m/SI0E= +SIZE (Mail-AuthenticationResults-2.20230112.tar.gz) = 32438
CVS: cvs.openbsd.org: ports
CVSROOT:/cvs Module name:ports Changes by: phess...@cvs.openbsd.org2023/02/20 23:56:30 Modified files: lang/pypy : Makefile Log message: set parallel build, accelerates the building of this port. been in the arm64 package bulk builds for months and months, before it broke OK edd@ (MAINTAINER)
Re: [update] openttd to 13.0 and update openttd-data
Hi,
> Thank you for the feedback. Updated diffs attached. While there, take
> Maintainership of openttd-data.
friendly ping.
Diffs attached again for convenience.
Thanks!
--
greetings,
Florian Viehweger
Index: Makefile
===
RCS file: /daten/openbsdmirror/cvs/mirror/ports/games/openttd/Makefile,v
retrieving revision 1.79
diff -u -p -u -p -r1.79 Makefile
--- Makefile 24 Jul 2022 07:30:00 - 1.79
+++ Makefile 12 Feb 2023 21:41:21 -
@@ -1,6 +1,6 @@
COMMENT= open source clone of the game Transport Tycoon Deluxe
-V = 12.2
+V = 13.0
DISTNAME = openttd-$V-source
PKGNAME = openttd-$V
@@ -13,9 +13,10 @@ HOMEPAGE= https://www.openttd.org/
# GPLv2 only
PERMIT_PACKAGE= Yes
-WANTLIB += ${COMPILER_LIBCXX}
-WANTLIB += SDL2 c fluidsynth fontconfig freetype icudata icui18n icuuc
-WANTLIB += lzma lzo2 m png pthread z
+WANTLIB += ${COMPILER_LIBCXX}
+WANTLIB += X11 Xcursor Xext Xfixes Xi Xrandr Xss c fluidsynth fontconfig
+WANTLIB += freetype icudata icui18n icuuc lzma lzo2 m png pthread samplerate
+WANTLIB += sndio usbhid z
COMPILER = base-clang ports-gcc base-gcc
@@ -28,7 +29,7 @@ MODULES = devel/cmake
LIB_DEPENDS= archivers/lzo2 \
audio/fluidsynth \
- devel/sdl2 \
+ audio/libsamplerate \
graphics/png \
textproc/icu4c \
archivers/xz
Index: distinfo
===
RCS file: /daten/openbsdmirror/cvs/mirror/ports/games/openttd/distinfo,v
retrieving revision 1.42
diff -u -p -u -p -r1.42 distinfo
--- distinfo 24 Jul 2022 07:30:00 - 1.42
+++ distinfo 12 Feb 2023 21:41:21 -
@@ -1,2 +1,2 @@
-SHA256 (openttd/openttd-12.2-source.tar.xz) = gVCPDek6DCZLIW71agX4OB//e/+m0BASGiFJC02s6Vw=
-SIZE (openttd/openttd-12.2-source.tar.xz) = 7377496
+SHA256 (openttd/openttd-13.0-source.tar.xz) = M5344OCCcIfIOv54+O/GpzsKPYqVCgtTE3zm6KrXq2c=
+SIZE (openttd/openttd-13.0-source.tar.xz) = 7422316
Index: pkg/PLIST
===
RCS file: /daten/openbsdmirror/cvs/mirror/ports/games/openttd/pkg/PLIST,v
retrieving revision 1.35
diff -u -p -u -p -r1.35 PLIST
--- pkg/PLIST 24 Jul 2022 07:30:00 - 1.35
+++ pkg/PLIST 12 Feb 2023 21:41:21 -
@@ -66,6 +66,7 @@ share/openttd/ai/compat_1.7.nut
share/openttd/ai/compat_1.8.nut
share/openttd/ai/compat_1.9.nut
share/openttd/ai/compat_12.nut
+share/openttd/ai/compat_13.nut
share/openttd/baseset/
share/openttd/baseset/no_music.obm
share/openttd/baseset/no_sound.obs
@@ -93,6 +94,7 @@ share/openttd/game/compat_1.7.nut
share/openttd/game/compat_1.8.nut
share/openttd/game/compat_1.9.nut
share/openttd/game/compat_12.nut
+share/openttd/game/compat_13.nut
share/openttd/lang/
share/openttd/lang/afrikaans.lng
share/openttd/lang/arabic_egypt.lng
@@ -184,8 +186,6 @@ share/openttd/media/baseset/openttd/char
share/openttd/media/baseset/openttd/chars.png
share/openttd/media/baseset/openttd/elrails.nfo
share/openttd/media/baseset/openttd/elrails.png
-share/openttd/media/baseset/openttd/flags.nfo
-share/openttd/media/baseset/openttd/flags.png
share/openttd/media/baseset/openttd/foundations.nfo
share/openttd/media/baseset/openttd/foundations.png
share/openttd/media/baseset/openttd/mono.nfo
@@ -224,6 +224,8 @@ share/openttd/media/baseset/orig_extra/c
share/openttd/media/baseset/orig_extra/chars_orig_extra.nfo
share/openttd/media/baseset/orig_extra/fix_graphics.nfo
share/openttd/media/baseset/orig_extra/fix_graphics.png
+share/openttd/media/baseset/orig_extra/fix_gui_icons.nfo
+share/openttd/media/baseset/orig_extra/fix_gui_icons.png
share/openttd/media/baseset/orig_extra/orig_extra.nfo
share/openttd/media/baseset/orig_extra/rivers/
share/openttd/media/baseset/orig_extra/rivers/arctic.nfo
Index: Makefile.inc
===
RCS file: /daten/openbsdmirror/cvs/mirror/ports/games/openttd-data/Makefile.inc,v
retrieving revision 1.4
diff -u -p -u -p -r1.4 Makefile.inc
--- Makefile.inc 11 Mar 2022 19:04:47 - 1.4
+++ Makefile.inc 14 Feb 2023 20:51:34 -
@@ -7,7 +7,7 @@ CATEGORIES += games
HOMEPAGE ?= https://www.openttd.org/en/
-MAINTAINER ?= Anthony J. Bentley
+MAINTAINER ?= Florian Viehweger
# GPLv2 only
PERMIT_PACKAGE= Yes
@@ -24,3 +24,6 @@ NO_TEST ?= Yes
PKG_ARCH ?= *
WRKDIST ?= ${WRKDIR}/${OPENTTD_PROJECT}-$V
+
+post-extract:
+ cd ${WRKDIR} && ${TAR} xf ${DISTNAME:S/-all//}.tar
Index: opengfx/Makefile
===
RCS file: /daten/openbsdmirror/cvs/mirror/ports/games/openttd-data/opengfx/Makefile,v
retrieving revision 1.5
diff -u -p -u -p -r1.5 Makefile
--- opengfx/Makefile 11 Mar 2022 19:04:47 - 1.5
+++ opengfx/Makefile 14 Feb 2023 20:51:34 -
@@ -1,10 +1,7 @@
COMMENT = graphics data for OpenTTD
OPENTTD_PROJECT = opengfx
-V = 0.6.1
-
-post-extract:
- cd ${WRKDIR} && ${TAR} xf opengfx-$V.tar
+V = 7.1
do-install:
${INSTALL_DATA_DIR}
CVS: cvs.openbsd.org: ports
CVSROOT:/cvs Module name:ports Changes by: t...@cvs.openbsd.org2023/02/20 19:30:32 Modified files: devel/abseil-cpp: Makefile Log message: abseil-cpp: Remove special casing for sparc64. The addition of scoped_mock_log added an LDEP on gtest and WANTLIB += gtest gmock, so the port could not be built on sparc64. ok kn for sparc64 fix, rest is obvious
Re: gtk+4 slow application startup
On Mon, Feb 20, 2023 at 08:17:35PM +0100, Robert Nagy wrote: > On 20/02/23 14:56 +0100, Landry Breuil wrote: > > Le Tue, Feb 21, 2023 at 12:00:06AM +1100, Jonathan Gray a écrit : > > > On Mon, Feb 20, 2023 at 11:31:23AM +0100, Antoine Jacoutot wrote: > > > > On Mon, Feb 20, 2023 at 02:06:34PM +1100, Jonathan Gray wrote: > > > > > On Sun, Feb 19, 2023 at 01:34:41PM +0100, Antoine Jacoutot wrote: > > > > > > Hi. > > > > > > > > > > > > There seems to be a regression with mesa that makes gtk+4 > > > > > > application very slow > > > > > > to start. > > > > > > By default the GSK renderer uses OpenGL. > > > > > > As a workaround, you can temporarily use this to go back to the > > > > > > cairo renderer > > > > > > which makes gtk+4 applications fast again: > > > > > > > > > > > > export GSK_RENDERER=cairo > > > > > > > > > > What hardware is this on? Is there a Mesa or gtk bug for it? > > > > > > > > See dmesg below. > > > > > > > > > When did this behaviour start? Before the gtk update that recently > > > > > went in? Does it occur with GSK_RENDERER=vulkan? > > > > > GSK_RENDERER described in > > > > > https://docs.gtk.org/gtk4/running.html#gsk_renderer > > > > > > > > It did not happen on my previous amd ryzen. > > > > As soon as I switched to the new intel laptop, I was that bug (exact > > > > same > > > > installation, I rsync'd everything). > > > > > > > > It does *not* appear with GSK_RENDERER=vulkan but that renderer is > > > > buggy (not > > > > built by default) and segfaults on a regular basis. > > > > > > > > > There is > > > > > https://gitlab.freedesktop.org/mesa/mesa/-/issues/5113 > > > > > which briefly touches on shader cache. We disable the shader > > > > > cache to be able to uses pledge(2). > > > > > > > > Yes, that is the bug I was looking into. > > > > > > Here is a xenocara diff to enable the shader cache. > > > It is created in ~/.cache/mesa_shader_cache/ > > > > > > On an Intel system (x250 with Broadwell) launching gtk4-demo results in > > > a 1.6M cache. The time to a window appearing is noticeably shorter > > > running it again after that. > > > > > > The various firefox and chromium ports will need to change > > > unveil/pledge policies to use it. Chromium at least still runs but > > > there are multiple warnings that directories can't be created. > > This just needs an unveil of that directory in the gpu process and > an flock pledge for chromium to use it. Seems okay to me. I think > this should go in. So chromium and firefox commits go in first, then the Mesa part a few days later?
Firefox won't run under 7.2-current (GENERIC.MP) #1059
warning: libcairo.so.13.2: minor version >= 3 expected, using it anyway warning: libcairo.so.13.2: minor version >= 3 expected, using it anyway warning: libcairo.so.13.2: minor version >= 3 expected, using it anyway warning: libcairo.so.13.2: minor version >= 3 expected, using it anyway msyscall 3279032b000 a7000 error Segmentation fault (core dumped) dmesg below -- Edward Ahlsen-Girard Ft Walton Beach, FL OpenBSD 7.2-current (GENERIC.MP) #1059: Sun Feb 19 22:39:56 MST 2023 dera...@amd64.openbsd.org:/usr/src/sys/arch/amd64/compile/GENERIC.MP real mem = 4174688256 (3981MB) avail mem = 4028768256 (3842MB) random: good seed from bootblocks mpath0 at root scsibus0 at mpath0: 256 targets mainbus0 at root bios0 at mainbus0: SMBIOS rev. 2.8 @ 0xec530 (36 entries) bios0: vendor AMI version "80.06" date 04/01/2015 bios0: Hewlett-Packard 550-036 efi0 at bios0: UEFI 2.3.1 efi0: American Megatrends rev 0x4028e acpi0 at bios0: ACPI 5.0 acpi0: sleep states S0 S3 S4 S5 acpi0: tables DSDT FACP APIC FPDT FIDT MSDM SSDT SSDT MCFG HPET SSDT SSDT DBGP acpi0: wakeup devices RP01(S4) PXSX(S4) PXSX(S4) PXSX(S4) RP04(S4) PXSX(S4) PXSX(S4) RP06(S4) PXSX(S4) RP07(S4) PXSX(S4) PXSX(S4) GLAN(S4) EHC1(S3) EHC2(S3) XHC_(S3) [...] acpitimer0 at acpi0: 3579545 Hz, 24 bits acpimadt0 at acpi0 addr 0xfee0: PC-AT compat cpu0 at mainbus0: apid 0 (boot processor) cpu0: Intel(R) Core(TM) i3-4170 CPU @ 3.70GHz, 3691.55 MHz, 06-3c-03 cpu0: FPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CFLUSH,DS,ACPI,MMX,FXSR,SSE,SSE2,SS,HTT,TM,PBE,SSE3,PCLMUL,DTES64,MWAIT,DS-CPL,VMX,EST,TM2,SSSE3,SDBG,FMA3,CX16,xTPR,PDCM,PCID,SSE4.1,SSE4.2,MOVBE,POPCNT,DEADLINE,AES,XSAVE,AVX,F16C,RDRAND,NXE,PAGE1GB,RDTSCP,LONG,LAHF,ABM,PERF,ITSC,FSGSBASE,TSC_ADJUST,BMI1,AVX2,SMEP,BMI2,ERMS,INVPCID,SRBDS_CTRL,MD_CLEAR,IBRS,IBPB,STIBP,L1DF,SSBD,SENSOR,ARAT,XSAVEOPT,MELTDOWN cpu0: 32KB 64b/line 8-way D-cache, 32KB 64b/line 8-way I-cache, 256KB 64b/line 8-way L2 cache, 3MB 64b/line 12-way L3 cache cpu0: smt 0, core 0, package 0 mtrr: Pentium Pro MTRR support, 10 var ranges, 88 fixed ranges cpu0: apic clock running at 99MHz cpu0: mwait min=64, max=64, C-substates=0.2.1.2.4, IBE cpu1 at mainbus0: apid 2 (application processor) cpu1: Intel(R) Core(TM) i3-4170 CPU @ 3.70GHz, 3691.63 MHz, 06-3c-03 cpu1: FPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CFLUSH,DS,ACPI,MMX,FXSR,SSE,SSE2,SS,HTT,TM,PBE,SSE3,PCLMUL,DTES64,MWAIT,DS-CPL,VMX,EST,TM2,SSSE3,SDBG,FMA3,CX16,xTPR,PDCM,PCID,SSE4.1,SSE4.2,MOVBE,POPCNT,DEADLINE,AES,XSAVE,AVX,F16C,RDRAND,NXE,PAGE1GB,RDTSCP,LONG,LAHF,ABM,PERF,ITSC,FSGSBASE,TSC_ADJUST,BMI1,AVX2,SMEP,BMI2,ERMS,INVPCID,SRBDS_CTRL,MD_CLEAR,IBRS,IBPB,STIBP,L1DF,SSBD,SENSOR,ARAT,XSAVEOPT,MELTDOWN cpu1: 32KB 64b/line 8-way D-cache, 32KB 64b/line 8-way I-cache, 256KB 64b/line 8-way L2 cache, 3MB 64b/line 12-way L3 cache cpu1: smt 0, core 1, package 0 cpu2 at mainbus0: apid 1 (application processor) cpu2: Intel(R) Core(TM) i3-4170 CPU @ 3.70GHz, 3691.70 MHz, 06-3c-03 cpu2: FPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CFLUSH,DS,ACPI,MMX,FXSR,SSE,SSE2,SS,HTT,TM,PBE,SSE3,PCLMUL,DTES64,MWAIT,DS-CPL,VMX,EST,TM2,SSSE3,SDBG,FMA3,CX16,xTPR,PDCM,PCID,SSE4.1,SSE4.2,MOVBE,POPCNT,DEADLINE,AES,XSAVE,AVX,F16C,RDRAND,NXE,PAGE1GB,RDTSCP,LONG,LAHF,ABM,PERF,ITSC,FSGSBASE,TSC_ADJUST,BMI1,AVX2,SMEP,BMI2,ERMS,INVPCID,SRBDS_CTRL,MD_CLEAR,IBRS,IBPB,STIBP,L1DF,SSBD,SENSOR,ARAT,XSAVEOPT,MELTDOWN cpu2: 32KB 64b/line 8-way D-cache, 32KB 64b/line 8-way I-cache, 256KB 64b/line 8-way L2 cache, 3MB 64b/line 12-way L3 cache cpu2: smt 1, core 0, package 0 cpu3 at mainbus0: apid 3 (application processor) cpu3: Intel(R) Core(TM) i3-4170 CPU @ 3.70GHz, 3691.85 MHz, 06-3c-03 cpu3: FPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CFLUSH,DS,ACPI,MMX,FXSR,SSE,SSE2,SS,HTT,TM,PBE,SSE3,PCLMUL,DTES64,MWAIT,DS-CPL,VMX,EST,TM2,SSSE3,SDBG,FMA3,CX16,xTPR,PDCM,PCID,SSE4.1,SSE4.2,MOVBE,POPCNT,DEADLINE,AES,XSAVE,AVX,F16C,RDRAND,NXE,PAGE1GB,RDTSCP,LONG,LAHF,ABM,PERF,ITSC,FSGSBASE,TSC_ADJUST,BMI1,AVX2,SMEP,BMI2,ERMS,INVPCID,SRBDS_CTRL,MD_CLEAR,IBRS,IBPB,STIBP,L1DF,SSBD,SENSOR,ARAT,XSAVEOPT,MELTDOWN cpu3: 32KB 64b/line 8-way D-cache, 32KB 64b/line 8-way I-cache, 256KB 64b/line 8-way L2 cache, 3MB 64b/line 12-way L3 cache cpu3: smt 1, core 1, package 0 ioapic0 at mainbus0: apid 8 pa 0xfec0, version 20, 24 pins acpimcfg0 at acpi0 acpimcfg0: addr 0xf800, bus 0-63 acpihpet0 at acpi0: 14318179 Hz acpiprt0 at acpi0: bus 0 (PCI0) acpiprt1 at acpi0: bus 1 (RP01) acpiprt2 at acpi0: bus 2 (RP04) acpiprt3 at acpi0: bus 3 (RP06) acpiprt4 at acpi0: bus 4 (RP07) acpiprt5 at acpi0: bus -1 (PEG0) acpiec0 at acpi0: not present acpipci0 at acpi0 PCI0: 0x 0x0011 0x0001 acpicmos0 at acpi0 acpibtn0 at acpi0: PWRB "PNP0C14" at acpi0 not configured "PNP0C0B" at acpi0 not configured "PNP0C0B" at acpi0 not configured "PNP0C0B" at acpi0 not configured "PNP0C0B" at acpi0 not configured "PNP0C0B" at acpi0 not configured
keepassxc will not run under OpenBSD 7.2-current (GENERIC.MP) #1059
warning: libzstd.so.6.1: minor version >= 2 expected, using it anyway ld.so: keepassxc: can't load library 'libdouble-conversion.so.1.0' Killed Only libdouble-conversion shred object found is libdouble-conversion.so.0.0 dmesg below -- Edward Ahlsen-Girard Ft Walton Beach, FL OpenBSD 7.2-current (GENERIC.MP) #1059: Sun Feb 19 22:39:56 MST 2023 dera...@amd64.openbsd.org:/usr/src/sys/arch/amd64/compile/GENERIC.MP real mem = 4174688256 (3981MB) avail mem = 4028768256 (3842MB) random: good seed from bootblocks mpath0 at root scsibus0 at mpath0: 256 targets mainbus0 at root bios0 at mainbus0: SMBIOS rev. 2.8 @ 0xec530 (36 entries) bios0: vendor AMI version "80.06" date 04/01/2015 bios0: Hewlett-Packard 550-036 efi0 at bios0: UEFI 2.3.1 efi0: American Megatrends rev 0x4028e acpi0 at bios0: ACPI 5.0 acpi0: sleep states S0 S3 S4 S5 acpi0: tables DSDT FACP APIC FPDT FIDT MSDM SSDT SSDT MCFG HPET SSDT SSDT DBGP acpi0: wakeup devices RP01(S4) PXSX(S4) PXSX(S4) PXSX(S4) RP04(S4) PXSX(S4) PXSX(S4) RP06(S4) PXSX(S4) RP07(S4) PXSX(S4) PXSX(S4) GLAN(S4) EHC1(S3) EHC2(S3) XHC_(S3) [...] acpitimer0 at acpi0: 3579545 Hz, 24 bits acpimadt0 at acpi0 addr 0xfee0: PC-AT compat cpu0 at mainbus0: apid 0 (boot processor) cpu0: Intel(R) Core(TM) i3-4170 CPU @ 3.70GHz, 3691.55 MHz, 06-3c-03 cpu0: FPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CFLUSH,DS,ACPI,MMX,FXSR,SSE,SSE2,SS,HTT,TM,PBE,SSE3,PCLMUL,DTES64,MWAIT,DS-CPL,VMX,EST,TM2,SSSE3,SDBG,FMA3,CX16,xTPR,PDCM,PCID,SSE4.1,SSE4.2,MOVBE,POPCNT,DEADLINE,AES,XSAVE,AVX,F16C,RDRAND,NXE,PAGE1GB,RDTSCP,LONG,LAHF,ABM,PERF,ITSC,FSGSBASE,TSC_ADJUST,BMI1,AVX2,SMEP,BMI2,ERMS,INVPCID,SRBDS_CTRL,MD_CLEAR,IBRS,IBPB,STIBP,L1DF,SSBD,SENSOR,ARAT,XSAVEOPT,MELTDOWN cpu0: 32KB 64b/line 8-way D-cache, 32KB 64b/line 8-way I-cache, 256KB 64b/line 8-way L2 cache, 3MB 64b/line 12-way L3 cache cpu0: smt 0, core 0, package 0 mtrr: Pentium Pro MTRR support, 10 var ranges, 88 fixed ranges cpu0: apic clock running at 99MHz cpu0: mwait min=64, max=64, C-substates=0.2.1.2.4, IBE cpu1 at mainbus0: apid 2 (application processor) cpu1: Intel(R) Core(TM) i3-4170 CPU @ 3.70GHz, 3691.63 MHz, 06-3c-03 cpu1: FPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CFLUSH,DS,ACPI,MMX,FXSR,SSE,SSE2,SS,HTT,TM,PBE,SSE3,PCLMUL,DTES64,MWAIT,DS-CPL,VMX,EST,TM2,SSSE3,SDBG,FMA3,CX16,xTPR,PDCM,PCID,SSE4.1,SSE4.2,MOVBE,POPCNT,DEADLINE,AES,XSAVE,AVX,F16C,RDRAND,NXE,PAGE1GB,RDTSCP,LONG,LAHF,ABM,PERF,ITSC,FSGSBASE,TSC_ADJUST,BMI1,AVX2,SMEP,BMI2,ERMS,INVPCID,SRBDS_CTRL,MD_CLEAR,IBRS,IBPB,STIBP,L1DF,SSBD,SENSOR,ARAT,XSAVEOPT,MELTDOWN cpu1: 32KB 64b/line 8-way D-cache, 32KB 64b/line 8-way I-cache, 256KB 64b/line 8-way L2 cache, 3MB 64b/line 12-way L3 cache cpu1: smt 0, core 1, package 0 cpu2 at mainbus0: apid 1 (application processor) cpu2: Intel(R) Core(TM) i3-4170 CPU @ 3.70GHz, 3691.70 MHz, 06-3c-03 cpu2: FPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CFLUSH,DS,ACPI,MMX,FXSR,SSE,SSE2,SS,HTT,TM,PBE,SSE3,PCLMUL,DTES64,MWAIT,DS-CPL,VMX,EST,TM2,SSSE3,SDBG,FMA3,CX16,xTPR,PDCM,PCID,SSE4.1,SSE4.2,MOVBE,POPCNT,DEADLINE,AES,XSAVE,AVX,F16C,RDRAND,NXE,PAGE1GB,RDTSCP,LONG,LAHF,ABM,PERF,ITSC,FSGSBASE,TSC_ADJUST,BMI1,AVX2,SMEP,BMI2,ERMS,INVPCID,SRBDS_CTRL,MD_CLEAR,IBRS,IBPB,STIBP,L1DF,SSBD,SENSOR,ARAT,XSAVEOPT,MELTDOWN cpu2: 32KB 64b/line 8-way D-cache, 32KB 64b/line 8-way I-cache, 256KB 64b/line 8-way L2 cache, 3MB 64b/line 12-way L3 cache cpu2: smt 1, core 0, package 0 cpu3 at mainbus0: apid 3 (application processor) cpu3: Intel(R) Core(TM) i3-4170 CPU @ 3.70GHz, 3691.85 MHz, 06-3c-03 cpu3: FPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CFLUSH,DS,ACPI,MMX,FXSR,SSE,SSE2,SS,HTT,TM,PBE,SSE3,PCLMUL,DTES64,MWAIT,DS-CPL,VMX,EST,TM2,SSSE3,SDBG,FMA3,CX16,xTPR,PDCM,PCID,SSE4.1,SSE4.2,MOVBE,POPCNT,DEADLINE,AES,XSAVE,AVX,F16C,RDRAND,NXE,PAGE1GB,RDTSCP,LONG,LAHF,ABM,PERF,ITSC,FSGSBASE,TSC_ADJUST,BMI1,AVX2,SMEP,BMI2,ERMS,INVPCID,SRBDS_CTRL,MD_CLEAR,IBRS,IBPB,STIBP,L1DF,SSBD,SENSOR,ARAT,XSAVEOPT,MELTDOWN cpu3: 32KB 64b/line 8-way D-cache, 32KB 64b/line 8-way I-cache, 256KB 64b/line 8-way L2 cache, 3MB 64b/line 12-way L3 cache cpu3: smt 1, core 1, package 0 ioapic0 at mainbus0: apid 8 pa 0xfec0, version 20, 24 pins acpimcfg0 at acpi0 acpimcfg0: addr 0xf800, bus 0-63 acpihpet0 at acpi0: 14318179 Hz acpiprt0 at acpi0: bus 0 (PCI0) acpiprt1 at acpi0: bus 1 (RP01) acpiprt2 at acpi0: bus 2 (RP04) acpiprt3 at acpi0: bus 3 (RP06) acpiprt4 at acpi0: bus 4 (RP07) acpiprt5 at acpi0: bus -1 (PEG0) acpiec0 at acpi0: not present acpipci0 at acpi0 PCI0: 0x 0x0011 0x0001 acpicmos0 at acpi0 acpibtn0 at acpi0: PWRB "PNP0C14" at acpi0 not configured "PNP0C0B" at acpi0 not configured "PNP0C0B" at acpi0 not configured "PNP0C0B" at acpi0 not configured "PNP0C0B" at acpi0 not configured "PNP0C0B" at acpi0 not configured acpicpu0 at acpi0: C2(200@148 mwait.1@0x33), C1(1000@1 mwait.1), PSS acpicpu1 at acpi0: C2(200@148 mwait.1@0x33), C1(1000@1 mwait.1), PSS
CVS: cvs.openbsd.org: ports
CVSROOT:/cvs Module name:ports Changes by: patr...@cvs.openbsd.org 2023/02/20 19:06:32 Modified files: sysutils/dtb/pkg: PLIST Log message: Update PLIST for linux 6.2, which I forgot to commit. Caught by jsg@, thanks!
CVS: cvs.openbsd.org: ports
CVSROOT:/cvs Module name:ports Changes by: patr...@cvs.openbsd.org 2023/02/20 18:53:21 Modified files: sysutils/dtb : Makefile distinfo sysutils/dtb/patches: patch-arch_arm64_boot_dts_qcom_sc8280xp-lenovo-thinkpad-x13s_dts patch-arch_arm64_boot_dts_qcom_sc8280xp-pmics_dtsi patch-arch_arm64_boot_dts_rockchip_rk3399_dtsi sysutils/firmware/arm64-qcom-dtb: Makefile Removed files: sysutils/dtb/patches: patch-arch_arm64_boot_dts_qcom_sc8280xp_dtsi Log message: update dtb to linux 6.2, which allows us to drop most of our qcom patchset
CVS: cvs.openbsd.org: ports
CVSROOT:/cvs Module name:ports Changes by: e...@cvs.openbsd.org2023/02/20 15:03:42 Modified files: sysutils/fzf : Makefile distinfo Log message: sysutils/fzf: easy update to version 0.38.0 Diff from Laurent Cheylus, thanks!
CVS: cvs.openbsd.org: ports
CVSROOT:/cvs Module name:ports Changes by: e...@cvs.openbsd.org2023/02/20 14:53:19 Modified files: editors/neovim : Makefile distinfo Log message: editors/neovim: easy update to version 0.8.3 Diff from Laurent Cheylus, thanks!
CVS: cvs.openbsd.org: ports
CVSROOT:/cvs Module name:ports Changes by: ai...@cvs.openbsd.org 2023/02/20 14:50:14 Modified files: devel/py-llvmlite: Makefile distinfo devel/py-llvmlite/pkg: PLIST Log message: update to 0.39.1 ok sthen@
is anyone using pypy?
Hi, This is a quick mail to ask: do we have any (serious) users of PyPy on OpenBSD? I ask because: - It's currently marked broken. - It currently targets Python2. - Historically it breaks regularly due to libressl flux and causes tb@ hassle. - It BUILD_DEPENDS lang/python/2.7 (and probably always will). I had a half-working port of pypy3 from before execonly was introduced. I'm also aware that something stopped the old pypy2 port from building recently, even with `USE_NOEXECONLY` set. Maybe that's not an issue with pypy3, I don't know. So, is anyone using it? Or is it time to let it go? If they are, I might be motivated to work on it... [Don't let my doom and gloom detract from PyPy's achievements. It's an impressive piece of software, just it's awkward to maintain a port for] -- Best Regards Edd Barrett https://www.theunixzoo.co.uk
CVS: cvs.openbsd.org: ports
CVSROOT:/cvs Module name:ports Changes by: gne...@cvs.openbsd.org 2023/02/20 14:17:49 Modified files: lang/ghc : Makefile Log message: Suppress clang warnings about unused arguments in lang/ghc OK kili@
NEW: devel/p5-OpenAI-API
This is not used by anything, yet. Comment: A Perl module for accessing the OpenAI API Feedback? If OK, please commit, I don't have commit access since I fell off the radar. Thanks, -- Todd T. Fries . http://todd.fries.net/pgp.txt . @unix2mars . github:toddfries
CVS: cvs.openbsd.org: ports
CVSROOT:/cvs Module name:ports Changes by: bl...@cvs.openbsd.org 2023/02/20 13:53:54 Modified files: devel/p5-Data-Validate-Struct: Makefile distinfo devel/p5-Data-Validate-Struct/patches: patch-t_run_t Added files: devel/p5-Data-Validate-Struct/patches: patch-Struct_pm Log message: update p5-Data-Validate-Struct to 0.11
Re: wxWidgets update fallout
On Sat, February 18, 2023 17:52, Antoine Jacoutot wrote: > Hi folks. Hi, > > I addition to my previous mail regarding p5-Alien-wxWidgets and p5-Wx here are > some ports that are now broken with our new wxWidgets: > > * audio/pykaraoke > old py2-only stuff, there is a pyKaraoke on pypi but it's a different > -> I would like to rm -rf > > * comms/wammu > old py2-only stuff > -> kirby@ there seems to be some update available if you want to have a look wammu is not maintained (https://github.com/gammu/wammu/issues/78). I guess we can switch to py3-gammu as many Linux distributions already did and drop this GUI part. I'll take care about this. > * graphics/sk1 > py2-only; dead upstream > -> I would like to rm -rf Original author died in 2021 and there is no much activity atm. ok for rm. > > * databases/pgadmin3 > will not build with new wxWidgets > there's pgadmin4 but its an totally entire beast > -> pea@ what should we do, rm -rf ? > > * devel/rapidsvn > will not build with new wxWidgets > unmaintained > -> I would like to rm -rf > > * misc/rocrail > will not build with new wxWidgets > -> sebastia@ they seem to provide daily packages, maybe updating is possible? > > Thoughts? > >
CVS: cvs.openbsd.org: ports
CVSROOT:/cvs Module name:ports Changes by: sebas...@cvs.openbsd.org2023/02/20 12:57:54 Modified files: security/exploitdb: Makefile distinfo security/exploitdb/patches: patch-_searchsploit_rc patch-searchsploit security/exploitdb/pkg: PLIST Log message: update to 2023-02-16 project moved to Gitlab
Re: De-noise ghc
Hi Greg,
On Sun, Feb 19, 2023 at 07:16:01PM -0800, Greg Steuck wrote:
> We get this annoying line all over the place now in Haskell ports logs:
>
> cc: warning: -Wl,--no-execute-only: 'linker' input unused
> [-Wunused-command-line-argument]
>
> I don't know of a simple way to stick the --no-execute-only flag only
> into the link and not the compiler line of ghc/settings. So I propose
> we suppress this with a simple patch, OK?
Yes, thanks.
Ciao,
Kili
> diff --git a/lang/ghc/Makefile b/lang/ghc/Makefile
> index 27c1ed025e9..ba8e4943682 100644
> --- a/lang/ghc/Makefile
> +++ b/lang/ghc/Makefile
> @@ -12,6 +12,7 @@ NO_CCACHE = Yes
> USE_NOEXECONLY = Yes
>
> GHC_VERSION =9.2.6
> +REVISION = 0
> DISTNAME = ghc-${GHC_VERSION}
> CATEGORIES = lang devel
> HOMEPAGE = https://www.haskell.org/ghc/
> @@ -113,7 +114,7 @@ CONFIGURE_ARGS +=
> --with-ffi-includes=${LOCALBASE}/include \
>
> CONFIGURE_ENV += SPHINXBUILD=${LOCALBASE}/bin/sphinx-build${MODPY_BIN_SUFFIX}
>
> -GHC_CC_OPTS =-Wl,--no-execute-only
> +GHC_CC_OPTS =-Wl,--no-execute-only -Qunused-arguments
> CONFIGURE_ENV += CONF_GCC_LINKER_OPTS_STAGE0="${GHC_CC_OPTS}" \
> CONF_GCC_LINKER_OPTS_STAGE1="${GHC_CC_OPTS}" \
> CONF_GCC_LINKER_OPTS_STAGE2="${GHC_CC_OPTS}" \
>
CVS: cvs.openbsd.org: ports
CVSROOT:/cvs Module name:ports Changes by: st...@cvs.openbsd.org 2023/02/20 12:56:03 Modified files: www/tomcat/v10 : Tag: OPENBSD_7_2 Makefile distinfo www/tomcat/v10/pkg: Tag: OPENBSD_7_2 PLIST-examples PLIST-main Log message: update to tomcat-10.1.5 (CVE-2023-24998, FileUpload DoS with excessive parts)
CVS: cvs.openbsd.org: ports
CVSROOT:/cvs Module name:ports Changes by: st...@cvs.openbsd.org 2023/02/20 12:55:58 Modified files: www/tomcat/v9 : Tag: OPENBSD_7_2 Makefile distinfo www/tomcat/v9/pkg: Tag: OPENBSD_7_2 PLIST-examples Log message: update to tomcat-9.0.71 (CVE-2023-24998, FileUpload DoS with excessive parts)
CVS: cvs.openbsd.org: ports
CVSROOT:/cvs Module name:ports Changes by: st...@cvs.openbsd.org 2023/02/20 12:55:53 Modified files: www/tomcat/v8 : Tag: OPENBSD_7_2 Makefile distinfo www/tomcat/v8/pkg: Tag: OPENBSD_7_2 PLIST-examples Log message: update to tomcat-8.5.85 (CVE-2023-24998, FileUpload DoS with excessive parts)
CVS: cvs.openbsd.org: ports
CVSROOT:/cvs Module name:ports Changes by: st...@cvs.openbsd.org 2023/02/20 12:55:15 Modified files: www/tomcat/v10 : Makefile distinfo www/tomcat/v10/pkg: PLIST-examples PLIST-main Log message: update to tomcat-10.1.5
CVS: cvs.openbsd.org: ports
CVSROOT:/cvs Module name:ports Changes by: st...@cvs.openbsd.org 2023/02/20 12:55:07 Modified files: www/tomcat/v8 : Makefile distinfo www/tomcat/v8/pkg: PLIST-examples Log message: update to tomcat-8.5.85
CVS: cvs.openbsd.org: ports
CVSROOT:/cvs Module name:ports Changes by: st...@cvs.openbsd.org 2023/02/20 12:55:11 Modified files: www/tomcat/v9 : Makefile distinfo www/tomcat/v9/pkg: PLIST-examples Log message: update to tomcat-9.0.71
CVS: cvs.openbsd.org: ports
CVSROOT:/cvs Module name:ports Changes by: st...@cvs.openbsd.org 2023/02/20 12:41:51 Modified files: comms/chirp: Makefile comms/chirp/pkg: PLIST Added files: comms/chirp/patches: patch-chirp_wxui___init___py patch-chirp_wxui_report_py Log message: disable phone-home
Re: gtk+4 slow application startup
On 20/02/23 14:56 +0100, Landry Breuil wrote: > Le Tue, Feb 21, 2023 at 12:00:06AM +1100, Jonathan Gray a écrit : > > On Mon, Feb 20, 2023 at 11:31:23AM +0100, Antoine Jacoutot wrote: > > > On Mon, Feb 20, 2023 at 02:06:34PM +1100, Jonathan Gray wrote: > > > > On Sun, Feb 19, 2023 at 01:34:41PM +0100, Antoine Jacoutot wrote: > > > > > Hi. > > > > > > > > > > There seems to be a regression with mesa that makes gtk+4 application > > > > > very slow > > > > > to start. > > > > > By default the GSK renderer uses OpenGL. > > > > > As a workaround, you can temporarily use this to go back to the cairo > > > > > renderer > > > > > which makes gtk+4 applications fast again: > > > > > > > > > > export GSK_RENDERER=cairo > > > > > > > > What hardware is this on? Is there a Mesa or gtk bug for it? > > > > > > See dmesg below. > > > > > > > When did this behaviour start? Before the gtk update that recently > > > > went in? Does it occur with GSK_RENDERER=vulkan? > > > > GSK_RENDERER described in > > > > https://docs.gtk.org/gtk4/running.html#gsk_renderer > > > > > > It did not happen on my previous amd ryzen. > > > As soon as I switched to the new intel laptop, I was that bug (exact same > > > installation, I rsync'd everything). > > > > > > It does *not* appear with GSK_RENDERER=vulkan but that renderer is buggy > > > (not > > > built by default) and segfaults on a regular basis. > > > > > > > There is > > > > https://gitlab.freedesktop.org/mesa/mesa/-/issues/5113 > > > > which briefly touches on shader cache. We disable the shader > > > > cache to be able to uses pledge(2). > > > > > > Yes, that is the bug I was looking into. > > > > Here is a xenocara diff to enable the shader cache. > > It is created in ~/.cache/mesa_shader_cache/ > > > > On an Intel system (x250 with Broadwell) launching gtk4-demo results in > > a 1.6M cache. The time to a window appearing is noticeably shorter > > running it again after that. > > > > The various firefox and chromium ports will need to change > > unveil/pledge policies to use it. Chromium at least still runs but > > there are multiple warnings that directories can't be created. This just needs an unveil of that directory in the gpu process and an flock pledge for chromium to use it. Seems okay to me. I think this should go in.
CVS: cvs.openbsd.org: ports
CVSROOT:/cvs Module name:ports Changes by: t...@cvs.openbsd.org2023/02/20 12:16:05 Modified files: security/rust-openssl-tests: Makefile crates.inc distinfo security/rust-openssl-tests/pkg: PLIST Log message: Update to rust-openssl-tests 20230220
CVS: cvs.openbsd.org: ports
CVSROOT:/cvs Module name:ports Changes by: j...@cvs.openbsd.org2023/02/20 11:27:15 Modified files: net/syncthing : Makefile distinfo net/syncthing/patches: patch-build_go Added files: net/syncthing/patches: patch-lib_build_build_go Log message: Unbreak syncthing, update to 1.23.2rc1, disable phone-home With help from kn@
CVS: cvs.openbsd.org: ports
CVSROOT:/cvs Module name:ports Changes by: ajacou...@cvs.openbsd.org 2023/02/20 11:06:15 Modified files: devel : Makefile Removed files: devel/py-attrdict: Makefile distinfo devel/py-attrdict/patches: patch-attrdict_default_py patch-attrdict_mapping_py patch-attrdict_merge_py patch-attrdict_mixins_py devel/py-attrdict/pkg: DESCR PLIST Log message: Remove py-attrdict, nothing uses it. No entry in quirks since it was there only for about 48h.
CVS: cvs.openbsd.org: ports
CVSROOT:/cvs Module name:ports Changes by: ajacou...@cvs.openbsd.org 2023/02/20 11:05:41 Modified files: x11/py-wxPython: Makefile x11/py-wxPython/pkg: PLIST-main Added files: x11/py-wxPython/patches: patch-build_py patch-buildtools_config_py Log message: Patch out requirement for devel/py-attrdict; it's only useful on windows. Use plain sh(1) instead of bash.
CVS: cvs.openbsd.org: ports
CVSROOT:/cvs Module name:ports Changes by: bl...@cvs.openbsd.org 2023/02/20 10:55:54 Added files: net/p5-Net-Patricia/patches: patch-t_01everything_t Log message: Perl 5.36.0 Socket changed inet_aton(). Adjust Net::Patricia test. OK afresh1@ benoit@
CVS: cvs.openbsd.org: ports
CVSROOT:/cvs Module name:ports Changes by: j...@cvs.openbsd.org2023/02/20 10:34:32 Modified files: net/knot : Makefile Log message: Remove myself from MAINTAINER I'm not using net/knot since a long time so there's no reason left for me to maintain this. Discussed with Aisha (now current sole MAINTAINER).
shorten/shntool homepage
The etree.org page is apparently dead, but the freeshell.org sites exist and have the tarballs. Jan Index: shntool/Makefile === RCS file: /cvs/ports/audio/shntool/Makefile,v retrieving revision 1.6 diff -u -p -r1.6 Makefile --- shntool/Makefile11 Mar 2022 18:20:30 - 1.6 +++ shntool/Makefile20 Feb 2023 16:54:22 - @@ -5,7 +5,7 @@ REVISION = 1 CATEGORIES = audio -HOMEPAGE = http://www.etree.org/shnutils/shntool/ +HOMEPAGE = http://shnutils.freeshell.org/shntool/ # GPLv2+ PERMIT_PACKAGE = Yes Index: shorten/Makefile === RCS file: /cvs/ports/audio/shorten/Makefile,v retrieving revision 1.16 diff -u -p -r1.16 Makefile --- shorten/Makefile8 Mar 2022 14:27:52 - 1.16 +++ shorten/Makefile20 Feb 2023 16:54:22 - @@ -2,7 +2,7 @@ COMMENT=fast compression for waveform f DISTNAME= shorten-3.6.1 CATEGORIES=audio archivers -HOMEPAGE= http://www.etree.org/shnutils/shorten/ +HOMEPAGE= http://shnutils.freeshell.org/shorten/ MAINTAINER=Christian Weisgerber
CVS: cvs.openbsd.org: ports
CVSROOT:/cvs
Module name:ports
Changes by: k...@cvs.openbsd.org2023/02/20 10:22:28
Modified files:
devel/abseil-cpp: Makefile
Log message:
Clarify that tests do not build dynamic libs
pre-test symlinks *.so.* from the build phase into one directory so that
test programs use that in LD_LIBRARY_PATH (alternative would be to
TEST_DEPENDS += ${PKGPATH}, i.e. install abseil between build and test).
Tests only need libs from the build phase and do not build dynamic ones
themselves, so collect *.so.* first and then build tests to make it clear.
No test result change.
CVS: cvs.openbsd.org: ports
CVSROOT:/cvs Module name:ports Changes by: k...@cvs.openbsd.org2023/02/20 10:13:40 Modified files: devel/abseil-cpp: Makefile Added files: devel/abseil-cpp/patches: patch-absl_base_internal_raw_logging_cc Log message: disable syscall(2) usage; from robert
CVS: cvs.openbsd.org: ports
CVSROOT:/cvs Module name:ports Changes by: k...@cvs.openbsd.org2023/02/20 09:48:41 Modified files: devel/mtxclient: Makefile Log message: do not build unpackaged examples
CVS: cvs.openbsd.org: ports
CVSROOT:/cvs Module name:ports Changes by: ajacou...@cvs.openbsd.org 2023/02/20 09:39:49 Added files: textproc/enchant2/patches: patch-src_Makefile_in Log message: Use mandoc instead of groff.
CVS: cvs.openbsd.org: ports
CVSROOT:/cvs Module name:ports Changes by: k...@cvs.openbsd.org2023/02/20 09:35:25 Modified files: audio/mumble : Makefile audio/taglib : Makefile devel/abseil-cpp: Makefile devel/bullet : Makefile devel/ccache : Makefile devel/cjson: Makefile devel/cmocka : Makefile devel/cpputest : Makefile devel/epoll-shim: Makefile devel/flatbuffers: Makefile devel/gflags : Makefile devel/glog : Makefile devel/gtest: Makefile devel/json-c : Makefile devel/libcrossguid: Makefile devel/libdispatch: Makefile devel/msgpack : Makefile devel/qjson: Makefile geo/geos : Makefile net/libtorrent-rasterbar: Makefile security/keepassxc: Makefile Log message: Drop hand-rolled do-build targets in cmake ports for ALL_TARGET support cmake.port.mk now honours the variale and produces the identical target.
CVS: cvs.openbsd.org: ports
CVSROOT:/cvs Module name:ports Changes by: rsadow...@cvs.openbsd.org 2023/02/20 09:15:26 Modified files: multimedia/mkvtoolnix: Makefile distinfo multimedia/mkvtoolnix/patches: patch-Rakefile Log message: Update mkvtoolnix to 74.0.0
CVS: cvs.openbsd.org: ports
CVSROOT:/cvs Module name:ports Changes by: k...@cvs.openbsd.org2023/02/20 09:07:40 Modified files: devel/cmake: cmake.port.mk Log message: Reinstate ALL_TARGET support *_TARGET support got dropped in r1.76 2022/09/02 "Modernize CMake Module". Use it if and only if it has been set explicitly. Pass it in do-build so MODCMAKE_BUILD_TARGET can still be used manually. Hand-rolled do-build targets in cmake ports to honour ALL_TARGET can now be dropped; the final target is identical. OK rsadowski Bulk-tested by tb
CVS: cvs.openbsd.org: ports
CVSROOT:/cvs Module name:ports Changes by: k...@cvs.openbsd.org2023/02/20 09:04:06 Modified files: devel/clang-tools-extra: Makefile Log message: Remove *_TARGET variables cmake.port.mk currently ignores them and a future change enabling support for them would break fake/package if it picked up those outdated values. Noticed by tb in a bulk test (libLLVMFuzzMutate.a and others not built). This can be revisited later to cut down this monster port which currently builds its own clang... OK rsadowski "no objection" tb
CVS: cvs.openbsd.org: ports
CVSROOT:/cvs
Module name:ports
Changes by: sema...@cvs.openbsd.org 2023/02/20 08:43:10
Modified files:
lang/rust : Makefile
Log message:
lang/rust: switch back sparc64 to llvm13 from ports
rustc with llvm13 (from ports) doesn't work well for some ports ("error: failed
to parse bitcode for LTO module: Explicit gep type does not match pointee type
of pointer operand").
but rustc with llvm15 (embedded) fails to build librsvg ("error: internal
compiler error: unexpected panic") when compiling 'typenum' or 'os_str_bytes'
crates.
as librsvg takeout a large portion of the ports tree, prefer llvm13 for now,
while still debugging the problem.
with help from tb@
ok tb@
CVS: cvs.openbsd.org: ports
CVSROOT:/cvs Module name:ports Changes by: ki...@cvs.openbsd.org 2023/02/20 08:42:02 Modified files: net/owncloudclient: Makefile distinfo Log message: update owncloudclient to 3.2.0.10193
Re: [update] (unbreak) syncthing 1.23.2rc1
Please cc maintainer on updates. 20.02.2023 10:56, Job Snijders пишет: > People did the needful > > https://github.com/syncthing/syncthing/issues/8768 Great, I watched the issues but missed the rc release. You missed 'make update-patches'. This turns up in 'syncthing serve --no-browser' output, I don't like it, can you disable it? [2QRYX] 2023/02/20 19:36:45 INFO: Anonymous usage reporting is \ always enabled for candidate releases. Otherwise builds and runs for me with go 1.20.1 on amd64, thanks.
Re: [update] coeurl, mtxclient & nheko
Le Sun, Feb 19, 2023 at 06:03:41PM +, Klemens Nanni a écrit : > coeurl: OK > > mtxclient: > - examples are built but not packaged -> `-DLIB_BUILD_EXAMPLES=OFF' > (still takes awfully long to build 118 -> 106 targets) > - needs major bump as per check_sym > - uses c++20 -> COMPILER comment bump > - "14: responses(83527) in free(): bogus pointer (double free?) > 0xdbdbdbdbdbdbdbdb" > seen in test output > - last test seems to stalls on > 79675 _pbuild 105 1828K 9460K sleep/0 nanoslp 0:00 0.00% > /usr/ports/pobj/mtxclient-0.9.1/build-amd64/device > > nheko: > - uses gnu++20 -> COMPILER comment bump > - I see this on startup: > > QStandardPaths: XDG_RUNTIME_DIR not set, defaulting to '/tmp/runtime-kn' > [2023-02-19 21:59:08.272] [ui] [info] Restoring window size 1366x741 > [2023-02-19 21:59:08.351] [ui] [info] WebRTC: initialised GStreamer 1.22.0 > nheko:/usr/local/lib/libv4l2.so.0.0: undefined symbol '__syscall' > [2023-02-19 21:59:08.563] [ui] [info] jdenticon plugin not found. > [2023-02-19 21:59:10.619] [qml] [warning] load glyph failed err=7 > face=0xd3157303000, glyph=883 (:0, ) > [2023-02-19 21:59:10.619] [qml] [warning] load glyph failed err=7 > face=0xd3157303000, glyph=883 (:0, ) > Segmentation fault (core dumped) > > I see no commit in multimedia/libv4l to treat syscall(2) usage, so that > needs to be done -- taking a look now. > > Until then I can't run-test nheko... i have the same failure and i dont think it's related to the libv4l thing, because the backtrace points at qtquick. nheko:/usr/local/lib/libv4l2.so.0.0: undefined symbol '__syscall' [2023-02-20 16:27:25.700] [ui] [info] jdenticon plugin not found. [2023-02-20 16:27:28.178] [qml] [warning] load glyph failed err=7 face=0x18bdc6e, glyph=883 (:0, ) [2023-02-20 16:27:28.178] [qml] [warning] load glyph failed err=7 face=0x18bdc6e, glyph=883 (:0, ) Segmentation fault (core dumped) [16:27] daytona:~/ $egdb /usr/local/bin/nheko (gdb) core nheko.core [New process 534433] [New process 293776] [New process 239536] [New process 277412] [New process 206781] [New process 540244] [New process 539973] [New process 507896] [New process 616132] Core was generated by `nheko'. Program terminated with signal SIGSEGV, Segmentation fault. #0 0x018ba54588e7 in QQuickTextPrivate::setupTextLayout(double*) () from /usr/local/lib/qt5/./libQt5Quick.so.5.0 [Current thread is 1 (process 534433)] (gdb) bt #0 0x018ba54588e7 in QQuickTextPrivate::setupTextLayout(double*) () from /usr/local/lib/qt5/./libQt5Quick.so.5.0 #1 0x018ba5454bbd in QQuickTextPrivate::updateSize() () from /usr/local/lib/qt5/./libQt5Quick.so.5.0 #2 0x018ba5456de4 in QQuickTextPrivate::updateLayout() () from /usr/local/lib/qt5/./libQt5Quick.so.5.0 #3 0x018ba545f742 in QQuickText::componentComplete() () from /usr/local/lib/qt5/./libQt5Quick.so.5.0 #4 0x018c0a6ec740 in QQmlObjectCreator::finalize(QQmlInstantiationInterrupt&) () from /usr/local/lib/qt5/./libQt5Qml.so.3.3 #5 0x018c0a677ed2 in QQmlComponentPrivate::complete(QQmlEnginePrivate*, QQmlComponentPrivate::ConstructionState*) () from /usr/local/lib/qt5/./libQt5Qml.so.3.3 #6 0x018c0a677e4c in QQmlComponentPrivate::completeDeferred(QQmlEnginePrivate*, QQmlComponentPrivate::DeferredState*) () from /usr/local/lib/qt5/./libQt5Qml.so.3.3 #7 0x018c39e8d050 in QtQuickPrivate::completeDeferred(QObject*, QString const&) () from /usr/local/lib/qt5/libQt5QuickTemplates2.so.2.0 #8 0x018c39e885b9 in QQuickControlPrivate::executeContentItem(bool) () from /usr/local/lib/qt5/libQt5QuickTemplates2.so.2.0 #9 0x018c39e8b770 in QQuickControl::componentComplete() () from /usr/local/lib/qt5/libQt5QuickTemplates2.so.2.0 #10 0x018c0a6ec740 in QQmlObjectCreator::finalize(QQmlInstantiationInterrupt&) () from /usr/local/lib/qt5/./libQt5Qml.so.3.3 #11 0x018c0a67c3c3 in QQmlIncubatorPrivate::incubate(QQmlInstantiationInterrupt&) () from /usr/local/lib/qt5/./libQt5Qml.so.3.3 #12 0x018c0a67c114 in QQmlEnginePrivate::incubate(QQmlIncubator&, QQmlContextData*) () from /usr/local/lib/qt5/./libQt5Qml.so.3.3 #13 0x018bb1d9a357 in QQmlDelegateModelPrivate::object(QQmlListCompositor::Group, int, QQmlIncubator::IncubationMode) () from /usr/local/lib/qt5/./libQt5QmlModels.so.0.0 #14 0x018ba54fc7de in QQuickItemViewPrivate::createItem(int, QQmlIncubator::IncubationMode) () from /usr/local/lib/qt5/./libQt5Quick.so.5.0 #15 0x018ba54ead53 in QQuickGridViewPrivate::addVisibleItems(double, double, double, double, bool) () from /usr/local/lib/qt5/./libQt5Quick.so.5.0 #16 0x018ba54fd23c in QQuickItemViewPrivate::refill(double, double) () from /usr/local/lib/qt5/./libQt5Quick.so.5.0 #17 0x018ba54fbc12 in QQuickItemView::componentComplete() () from /usr/local/lib/qt5/./libQt5Quick.so.5.0 #18 0x018c0a6ec740 in QQmlObjectCreator::finalize(QQmlInstantiationInterrupt&) () from /usr/local/lib/qt5/./libQt5Qml.so.3.3 #19
CVS: cvs.openbsd.org: ports
CVSROOT:/cvs Module name:ports Changes by: k...@cvs.openbsd.org2023/02/20 08:22:51 Modified files: textproc : Makefile Log message: +re2
CVS: cvs.openbsd.org: ports
CVSROOT:/cvs Module name:ports Changes by: k...@cvs.openbsd.org2023/02/20 08:21:26 Log message: Import textproc/re2 --- Google's regular expression library New dependency for the devel/mtxclient 0.9.1 update Initial port by, OK landry Status: Vendor Tag: kn Release Tags: kn_20230220 N ports/textproc/re2/Makefile N ports/textproc/re2/distinfo N ports/textproc/re2/pkg/DESCR N ports/textproc/re2/pkg/PLIST No conflicts created by this import
gnucobol-3.2
Dear OpenBSD-ports team, I recently managed to compile gnucobol-3.2-rc2 (fully) in OpenBSD, which will probably be released the coming week. How to I provide info on how to compile it for you. How do I create a package (including dependency tree). kind regards Lars -- -- Prof.(FH) DI DR. Lars Mehnen University of Applied Science Technikum Wien A-1200 Vienna +43 1 333 40 77 - 5868 https://scholar.google.com/citations?hl=en=o_QHx6gJ https://orcid.org/my-orcid?orcid=-0002-2228-0213
CVS: cvs.openbsd.org: ports
CVSROOT:/cvs Module name:ports Changes by: ai...@cvs.openbsd.org 2023/02/20 08:02:05 Modified files: net/py-libknot : Makefile distinfo Log message: update to 3.2.5 ok abieber@
CVS: cvs.openbsd.org: ports
CVSROOT:/cvs Module name:ports Changes by: ai...@cvs.openbsd.org 2023/02/20 08:01:50 Modified files: net/knot : Makefile distinfo Log message: update to 3.2.5 ok abieber@
CVS: cvs.openbsd.org: ports
CVSROOT:/cvs Module name:ports Changes by: st...@cvs.openbsd.org 2023/02/20 07:59:53 Modified files: textproc/exempi: Makefile distinfo Removed files: textproc/exempi/patches: patch-exempi_Makefile_in patch-samples_source_Makefile_in patch-samples_source_common_DumpFile_cpp Log message: update to exempi-2.6.3
Re: gtk+4 slow application startup
Le Tue, Feb 21, 2023 at 12:00:06AM +1100, Jonathan Gray a écrit : > On Mon, Feb 20, 2023 at 11:31:23AM +0100, Antoine Jacoutot wrote: > > On Mon, Feb 20, 2023 at 02:06:34PM +1100, Jonathan Gray wrote: > > > On Sun, Feb 19, 2023 at 01:34:41PM +0100, Antoine Jacoutot wrote: > > > > Hi. > > > > > > > > There seems to be a regression with mesa that makes gtk+4 application > > > > very slow > > > > to start. > > > > By default the GSK renderer uses OpenGL. > > > > As a workaround, you can temporarily use this to go back to the cairo > > > > renderer > > > > which makes gtk+4 applications fast again: > > > > > > > > export GSK_RENDERER=cairo > > > > > > What hardware is this on? Is there a Mesa or gtk bug for it? > > > > See dmesg below. > > > > > When did this behaviour start? Before the gtk update that recently > > > went in? Does it occur with GSK_RENDERER=vulkan? > > > GSK_RENDERER described in > > > https://docs.gtk.org/gtk4/running.html#gsk_renderer > > > > It did not happen on my previous amd ryzen. > > As soon as I switched to the new intel laptop, I was that bug (exact same > > installation, I rsync'd everything). > > > > It does *not* appear with GSK_RENDERER=vulkan but that renderer is buggy > > (not > > built by default) and segfaults on a regular basis. > > > > > There is > > > https://gitlab.freedesktop.org/mesa/mesa/-/issues/5113 > > > which briefly touches on shader cache. We disable the shader > > > cache to be able to uses pledge(2). > > > > Yes, that is the bug I was looking into. > > Here is a xenocara diff to enable the shader cache. > It is created in ~/.cache/mesa_shader_cache/ > > On an Intel system (x250 with Broadwell) launching gtk4-demo results in > a 1.6M cache. The time to a window appearing is noticeably shorter > running it again after that. > > The various firefox and chromium ports will need to change > unveil/pledge policies to use it. Chromium at least still runs but > there are multiple warnings that directories can't be created. I'm a bit puzzled... i thought the issue only affected gtk4 apps ? Or gtk3 apps use that shader cache too ?
CVS: cvs.openbsd.org: ports
CVSROOT:/cvs Module name:ports Changes by: ajacou...@cvs.openbsd.org 2023/02/20 06:19:28 Modified files: textproc/chordpro: Makefile Log message: Bump.
CVS: cvs.openbsd.org: ports
CVSROOT:/cvs Module name:ports Changes by: ajacou...@cvs.openbsd.org 2023/02/20 06:09:00 Modified files: x11/p5-Wx : Makefile Added files: x11/p5-Wx/pkg : DESCR PLIST Removed files: x11/p5-Wx/pkg : DESCR-main DESCR-media DESCR-webkit PLIST-main PLIST-media PLIST-webkit Log message: Merge everything back to one package. x11/wxWidgets,-media is required by p5-Wx and wxchordro anyway. No need to complicate things as this is the only dependency.
CVS: cvs.openbsd.org: ports
CVSROOT:/cvs Module name:ports Changes by: ajacou...@cvs.openbsd.org 2023/02/20 06:07:26 Modified files: devel/p5-Alien-wxWidgets: Makefile Added files: devel/p5-Alien-wxWidgets/patches: patch-inc_My_Build_Any_wx_config_pm Log message: Don't enforce dependency on x11/wxWidgets,-webkit for consumers. Only p5-Wx depends on this port and only textproc/chordpro,-wx depends on p5-Wx and does not require webkit functionality.
Re: gtk+4 slow application startup
On Mon, Feb 20, 2023 at 11:31:23AM +0100, Antoine Jacoutot wrote: > On Mon, Feb 20, 2023 at 02:06:34PM +1100, Jonathan Gray wrote: > > On Sun, Feb 19, 2023 at 01:34:41PM +0100, Antoine Jacoutot wrote: > > > Hi. > > > > > > There seems to be a regression with mesa that makes gtk+4 application > > > very slow > > > to start. > > > By default the GSK renderer uses OpenGL. > > > As a workaround, you can temporarily use this to go back to the cairo > > > renderer > > > which makes gtk+4 applications fast again: > > > > > > export GSK_RENDERER=cairo > > > > What hardware is this on? Is there a Mesa or gtk bug for it? > > See dmesg below. > > > When did this behaviour start? Before the gtk update that recently > > went in? Does it occur with GSK_RENDERER=vulkan? > > GSK_RENDERER described in > > https://docs.gtk.org/gtk4/running.html#gsk_renderer > > It did not happen on my previous amd ryzen. > As soon as I switched to the new intel laptop, I was that bug (exact same > installation, I rsync'd everything). > > It does *not* appear with GSK_RENDERER=vulkan but that renderer is buggy (not > built by default) and segfaults on a regular basis. > > > There is > > https://gitlab.freedesktop.org/mesa/mesa/-/issues/5113 > > which briefly touches on shader cache. We disable the shader > > cache to be able to uses pledge(2). > > Yes, that is the bug I was looking into. Here is a xenocara diff to enable the shader cache. It is created in ~/.cache/mesa_shader_cache/ On an Intel system (x250 with Broadwell) launching gtk4-demo results in a 1.6M cache. The time to a window appearing is noticeably shorter running it again after that. The various firefox and chromium ports will need to change unveil/pledge policies to use it. Chromium at least still runs but there are multiple warnings that directories can't be created. Index: lib/mesa/src/util/disk_cache.c === RCS file: /cvs/xenocara/lib/mesa/src/util/disk_cache.c,v retrieving revision 1.13 diff -u -p -r1.13 disk_cache.c --- lib/mesa/src/util/disk_cache.c 28 Jan 2023 08:56:53 - 1.13 +++ lib/mesa/src/util/disk_cache.c 20 Feb 2023 12:42:45 - @@ -80,11 +80,6 @@ disk_cache_create(const char *gpu_name, uint8_t cache_version = CACHE_VERSION; size_t cv_size = sizeof(cache_version); -#ifdef __OpenBSD__ - /* default to no disk shader cache to avoid pledge violations in chromium */ - return NULL; -#endif - if (!disk_cache_enabled()) return NULL;
CVS: cvs.openbsd.org: ports
CVSROOT:/cvs Module name:ports Changes by: ajacou...@cvs.openbsd.org 2023/02/20 05:20:38 Modified files: meta/gnome : Makefile Log message: totem should be part of core (as are music and photos).
CVS: cvs.openbsd.org: ports
CVSROOT:/cvs Module name:ports Changes by: ajacou...@cvs.openbsd.org 2023/02/20 04:57:51 Modified files: x11/p5-Wx : Makefile Log message: Nope, cannot use COMPILER_LINKS in this context; add a hack.
CVS: cvs.openbsd.org: ports
CVSROOT:/cvs Module name:ports Changes by: st...@cvs.openbsd.org 2023/02/20 04:53:54 Modified files: sysutils/glances: Makefile Added files: sysutils/glances/patches: patch-glances_standalone_py Log message: glances: disable network check for latest version
CVS: cvs.openbsd.org: ports
CVSROOT:/cvs Module name:ports Changes by: rsadow...@cvs.openbsd.org 2023/02/20 04:48:38 Modified files: devel/kf5 : kf5.port.mk devel/kf5/attica: distinfo devel/kf5/baloo: distinfo devel/kf5/bluez-qt: distinfo devel/kf5/breeze-icons: distinfo devel/kf5/extra-cmake-modules: distinfo devel/kf5/frameworkintegration: distinfo devel/kf5/kactivities: distinfo devel/kf5/kactivities-stats: distinfo devel/kf5/kapidox: distinfo devel/kf5/karchive: Makefile distinfo devel/kf5/karchive/pkg: PLIST devel/kf5/kauth: distinfo devel/kf5/kbookmarks: distinfo devel/kf5/kcalendarcore: distinfo devel/kf5/kcalendarcore/pkg: PLIST devel/kf5/kcmutils: distinfo devel/kf5/kcodecs: distinfo devel/kf5/kcompletion: distinfo devel/kf5/kconfig: distinfo devel/kf5/kconfigwidgets: Makefile distinfo devel/kf5/kcontacts: distinfo devel/kf5/kcoreaddons: distinfo devel/kf5/kcrash: distinfo devel/kf5/kdav : distinfo devel/kf5/kdbusaddons: distinfo devel/kf5/kdbusaddons/pkg: PLIST devel/kf5/kdeclarative: distinfo devel/kf5/kded : distinfo devel/kf5/kdelibs4support: distinfo devel/kf5/kdesignerplugin: distinfo devel/kf5/kdesu: distinfo devel/kf5/kdewebkit: distinfo devel/kf5/kdnssd: distinfo devel/kf5/kdoctools: distinfo devel/kf5/kemoticons: distinfo devel/kf5/kfilemetadata: distinfo devel/kf5/kglobalaccel: distinfo devel/kf5/kguiaddons: distinfo devel/kf5/kholidays: distinfo devel/kf5/khtml: distinfo devel/kf5/ki18n: distinfo devel/kf5/kiconthemes: distinfo devel/kf5/kidletime: distinfo devel/kf5/kimageformats: distinfo devel/kf5/kinit: distinfo devel/kf5/kio : Makefile distinfo devel/kf5/kio/patches: patch-src_core_slave_cpp devel/kf5/kio/pkg: PLIST devel/kf5/kirigami2: distinfo devel/kf5/kirigami2/pkg: PLIST devel/kf5/kitemmodels: distinfo devel/kf5/kitemviews: distinfo devel/kf5/kjobwidgets: distinfo devel/kf5/kjs : distinfo devel/kf5/kjsembed: distinfo devel/kf5/kmediaplayer: distinfo devel/kf5/knewstuff: distinfo devel/kf5/knewstuff/pkg: PLIST devel/kf5/knotifications: Makefile distinfo devel/kf5/knotifyconfig: distinfo devel/kf5/kpackage: distinfo devel/kf5/kparts: Makefile distinfo devel/kf5/kpeople: distinfo devel/kf5/kplotting: distinfo devel/kf5/kpty : distinfo devel/kf5/kquickcharts: distinfo devel/kf5/kross: distinfo devel/kf5/krunner: distinfo devel/kf5/kservice: distinfo devel/kf5/ktexteditor: distinfo devel/kf5/ktextwidgets: distinfo devel/kf5/kunitconversion: distinfo devel/kf5/kwallet: distinfo devel/kf5/kwayland: distinfo devel/kf5/kwidgetsaddons: distinfo devel/kf5/kwindowsystem: distinfo devel/kf5/kxmlgui: distinfo devel/kf5/kxmlrpcclient: distinfo devel/kf5/oxygen-icons: distinfo devel/kf5/plasma-framework: Makefile distinfo devel/kf5/plasma-framework/pkg: PLIST devel/kf5/prison: distinfo devel/kf5/purpose: distinfo devel/kf5/qqc2-desktop-style: distinfo devel/kf5/solid: distinfo devel/kf5/sonnet: distinfo devel/kf5/syndication: distinfo devel/kf5/syntax-highlighting: distinfo devel/kf5/threadweaver: distinfo Log message: Update KDE Frameworks to 5.103.0 https://kde.org/announcements/frameworks/5/5.103.0/
CVS: cvs.openbsd.org: ports
CVSROOT:/cvs Module name:ports Changes by: st...@cvs.openbsd.org 2023/02/20 04:45:44 Modified files: devel/py-future: Makefile distinfo Log message: update to py-future-0.18.3
CVS: cvs.openbsd.org: ports
CVSROOT:/cvs Module name:ports Changes by: rob...@cvs.openbsd.org 2023/02/20 04:41:01 Modified files: mail/grommunio/dav/patches: patch-log4php_xml Log message: adjust default log level to INFO
CVS: cvs.openbsd.org: ports
CVSROOT:/cvs Module name:ports Changes by: rob...@cvs.openbsd.org 2023/02/20 04:40:49 Modified files: mail/grommunio/sync/patches: patch-config_php Log message: adjust default log level to INFO
CVS: cvs.openbsd.org: ports
CVSROOT:/cvs Module name:ports Changes by: st...@cvs.openbsd.org 2023/02/20 04:39:41 Modified files: devel/py-dulwich: Makefile distinfo devel/py-dulwich/pkg: PLIST Log message: update to py3-dulwich-0.21.3
WIP protobuf 22.0 (was Re: RFC: merge py-protobuf into protobuf)
On Mon, Feb 20, 2023 at 11:22:55AM +, Stuart Henderson wrote:
> As mentioned elsewhere it might still be better to keep the Python
> parts in a separate port so it can use the standard python.port.mk
> infrastructure (we're going to run into this with mail/notmuch's
> CFFI bindings too though I think in that case it may be trickier).
> Also this may makes it simpler for other language bindings added
> later as they too can use their own ports MODULES.
Right. I'm happy to avoid all the complexity and live with a bit of
duplication. It would be nice to have them in a common directory to
share a Makefile.inc, but the duplication isn't that bad. I can try
to solve that another day.
Thanks for all the other helpful explanations and feedback - it was an
instructive exercise.
Keeping them separate is fortunately straightforward. This works for me.
I'll put that through a bulk:
Index: devel/protobuf/Makefile
===
RCS file: /cvs/ports/devel/protobuf/Makefile,v
retrieving revision 1.66
diff -u -p -r1.66 Makefile
--- devel/protobuf/Makefile 19 Feb 2023 11:50:53 - 1.66
+++ devel/protobuf/Makefile 20 Feb 2023 11:35:39 -
@@ -1,18 +1,21 @@
COMMENT = c++ protocol buffers
-CPPMAJOR = 3
-PROTOBUF_VERSION = 21.12
+CPPMAJOR = 4
+PROTOBUF_VERSION = 22.0
V =${CPPMAJOR}.${PROTOBUF_VERSION}
TAG = v${PROTOBUF_VERSION:S/rc-/rc/}
-DISTNAME = protobuf-cpp-${V}
+DISTNAME = protobuf-${PROTOBUF_VERSION}
PKGNAME = protobuf-${V:S/-//g}
-REVISION = 0
+DISTFILES =protobuf-${PROTOBUF_VERSION}.tar.gz
-WRKDIST = ${WRKDIR}/protobuf-${V}
-
-SHARED_LIBS += protobuf-lite 19.0# 32.12
-SHARED_LIBS += protobuf21.0# 32.12
-SHARED_LIBS += protoc 23.0# 32.12
+# Not devel/gtest since the build system expects sources.
+GOOGLETEST_VERSION = 1.13.0
+MASTER_SITES0 =
https://github.com/google/googletest/archive/refs/tags/
+DISTFILES += gtest-{}v${GOOGLETEST_VERSION}.tar.gz:0
+
+SHARED_LIBS += protobuf-lite 20.0# 33.0
+SHARED_LIBS += protobuf22.0# 33.0
+SHARED_LIBS += protoc 24.0# 33.0
CATEGORIES = devel
@@ -21,7 +24,30 @@ HOMEPAGE = https://github.com/protocolb
# New BSD
PERMIT_PACKAGE = Yes
-WANTLIB += c m pthread ${COMPILER_LIBCXX} z
+WANTLIB += ${COMPILER_LIBCXX} absl_bad_optional_access absl_bad_variant_access
+WANTLIB += absl_base absl_city absl_civil_time absl_cord absl_cord_internal
+WANTLIB += absl_cordz_functions absl_cordz_handle absl_cordz_info
+WANTLIB += absl_crc32c absl_crc_cord_state absl_crc_cpu_detect
+WANTLIB += absl_crc_internal absl_debugging_internal absl_demangle_internal
+WANTLIB += absl_die_if_null absl_examine_stack absl_exponential_biased
+WANTLIB += absl_flags absl_flags_commandlineflag
absl_flags_commandlineflag_internal
+WANTLIB += absl_flags_config absl_flags_internal absl_flags_marshalling
+WANTLIB += absl_flags_private_handle_accessor absl_flags_program_name
+WANTLIB += absl_flags_reflection absl_graphcycles_internal absl_hash
+WANTLIB += absl_hashtablez_sampler absl_int128 absl_log_entry
+WANTLIB += absl_log_globals absl_log_initialize absl_log_internal_check_op
+WANTLIB += absl_log_internal_conditions absl_log_internal_format
+WANTLIB += absl_log_internal_globals absl_log_internal_log_sink_set
+WANTLIB += absl_log_internal_message absl_log_internal_nullguard
+WANTLIB += absl_log_internal_proto absl_log_severity absl_log_sink
+WANTLIB += absl_low_level_hash absl_malloc_internal absl_raw_hash_set
+WANTLIB += absl_raw_logging_internal absl_spinlock_wait absl_stacktrace
+WANTLIB += absl_status absl_statusor absl_str_format_internal
+WANTLIB += absl_strerror absl_strings absl_strings_internal absl_symbolize
+WANTLIB += absl_synchronization absl_throw_delegate absl_time
+WANTLIB += absl_time_zone c m z
+
+LIB_DEPENDS += devel/abseil-cpp
MASTER_SITES =
https://github.com/protocolbuffers/protobuf/releases/download/${TAG}/
@@ -29,7 +55,15 @@ COMPILER = base-clang ports-gcc
MODULES = devel/cmake
+CONFIGURE_ARGS += -Dprotobuf_ABSL_PROVIDER=package
+CONFIGURE_ARGS += -DABSL_ROOT_DIR=${LOCALBASE}/include/absl
CONFIGURE_ARGS += -Dprotobuf_BUILD_SHARED_LIBS=ON
-CONFIGURE_ARGS += -Dprotobuf_BUILD_TESTS=OFF
+
+# Tests have been broken for a long time. May want to disable them.
+#CONFIGURE_ARGS += -Dprotobuf_BUILD_TESTS=OFF
+
+post-extract:
+ rm -rf ${WRKSRC}/third_party/googletest
+ mv ${WRKDIR}/googletest-${GOOGLETEST_VERSION}
${WRKSRC}/third_party/googletest
.include
Index: devel/protobuf/distinfo
===
RCS file: /cvs/ports/devel/protobuf/distinfo,v
Re: new: productivity/xournalpp: handwriting notetaking and PDF annotation
ping with patch & tarball reattached :)
On 23/02/11 03:45AM, Yifei Zhan wrote:
> Hi,
>
> xournalpp (Xournal++) is a handwriting notetaking software with PDF
> annotation
> support. It has good balance in terms of lightweightness and feature and has
> been part of my notetaking workflow.
>
> Tested on amd64, audio recording needs extra steps to enable and has been
> documented in README, PDF annotation with text and images also works fine.
>
> This port requires cxx binding to be enabled for audio/portaudio-svn, a patch
> is
> included for that.
>
> Both xournalpp and patched portaudio-svn passed portcheck and
> port-lib-depends-check. Builtin testing is not ported but any help is
> welcomed.
>
> any comments?
Index: Makefile
===
RCS file: /cvs/ports/audio/portaudio-svn/Makefile,v
retrieving revision 1.22
diff -u -p -u -r1.22 Makefile
--- Makefile11 Mar 2022 18:20:26 - 1.22
+++ Makefile11 Feb 2023 03:24:31 -
@@ -6,19 +6,23 @@ CATEGORIES= audio
MASTER_SITES = http://files.portaudio.com/archives/
EXTRACT_SUFX = .tgz
-SHARED_LIBS = portaudio 1.2
+SHARED_LIBS += portaudio 1.2
+SHARED_LIBS += portaudiocpp0.12
HOMEPAGE= http://www.portaudio.com/
# MIT
PERMIT_PACKAGE=Yes
-WANTLIB= m pthread sndio
+WANTLIB += ${COMPILER_LIBCXX} m sndio
+
+COMPILER = base-clang ports-gcc
USE_GMAKE= Yes
AUTOCONF_VERSION = 2.69
CONFIGURE_STYLE= autoconf no-autoheader
-CONFIGURE_ARGS=--without-alsa --without-oss --without-jack
+CONFIGURE_ARGS=--without-alsa --without-oss --without-jack \
+ --enable-cxx
# builds non-automated, interactive tests in ${WRKBUILD}/bin
TEST_TARGET= tests
Index: pkg/PLIST
===
RCS file: /cvs/ports/audio/portaudio-svn/pkg/PLIST,v
retrieving revision 1.5
diff -u -p -u -r1.5 PLIST
--- pkg/PLIST 11 Mar 2022 18:20:27 - 1.5
+++ pkg/PLIST 11 Feb 2023 03:24:31 -
@@ -1,5 +1,29 @@
include/portaudio.h
+include/portaudiocpp/
+include/portaudiocpp/AutoSystem.hxx
+include/portaudiocpp/BlockingStream.hxx
+include/portaudiocpp/CFunCallbackStream.hxx
+include/portaudiocpp/CallbackInterface.hxx
+include/portaudiocpp/CallbackStream.hxx
+include/portaudiocpp/CppFunCallbackStream.hxx
+include/portaudiocpp/Device.hxx
+include/portaudiocpp/DirectionSpecificStreamParameters.hxx
+include/portaudiocpp/Exception.hxx
+include/portaudiocpp/HostApi.hxx
+include/portaudiocpp/InterfaceCallbackStream.hxx
+include/portaudiocpp/MemFunCallbackStream.hxx
+include/portaudiocpp/PortAudioCpp.hxx
+include/portaudiocpp/SampleDataFormat.hxx
+include/portaudiocpp/Stream.hxx
+include/portaudiocpp/StreamParameters.hxx
+include/portaudiocpp/System.hxx
+include/portaudiocpp/SystemDeviceIterator.hxx
+include/portaudiocpp/SystemHostApiIterator.hxx
@static-lib lib/libportaudio.a
lib/libportaudio.la
@lib lib/libportaudio.so.${LIBportaudio_VERSION}
+@lib lib/libportaudiocpp.so.${LIBportaudiocpp_VERSION}
+@static-lib lib/libportaudiocpp.a
+lib/libportaudiocpp.la
lib/pkgconfig/portaudio-2.0.pc
+lib/pkgconfig/portaudiocpp.pc
xournalpp.tar
Description: Unix tar archive
CVS: cvs.openbsd.org: ports
CVSROOT:/cvs Module name:ports Changes by: st...@cvs.openbsd.org 2023/02/20 04:37:48 Modified files: devel/py-funcy : Makefile distinfo Log message: update to py-funcy-1.18
CVS: cvs.openbsd.org: ports
CVSROOT:/cvs Module name:ports Changes by: st...@cvs.openbsd.org 2023/02/20 04:34:34 Modified files: devel/py-frozenlist: Makefile distinfo Log message: update to py3-frozenlist-1.3.3
CVS: cvs.openbsd.org: ports
CVSROOT:/cvs Module name:ports Changes by: st...@cvs.openbsd.org 2023/02/20 04:34:35 Modified files: devel/py-frozendict: Makefile distinfo devel/py-frozendict/pkg: PLIST Log message: update to py3-frozendict-2.3.5
CVS: cvs.openbsd.org: ports
CVSROOT:/cvs Module name:ports Changes by: st...@cvs.openbsd.org 2023/02/20 04:32:31 Modified files: databases/openldap: Makefile distinfo databases/openldap/patches: patch-configure_ac Log message: update to openldap-client-2.6.4
CVS: cvs.openbsd.org: ports
CVSROOT:/cvs Module name:ports Changes by: st...@cvs.openbsd.org 2023/02/20 04:31:52 Modified files: math/calc : Makefile distinfo Log message: update to calc-2.14.1.3
CVS: cvs.openbsd.org: ports
CVSROOT:/cvs Module name:ports Changes by: ajacou...@cvs.openbsd.org 2023/02/20 04:23:53 Modified files: x11/p5-Wx : Makefile x11/p5-Wx/pkg : PLIST-main Log message: Use COMPILER_LINKS instead of forcing port-gcc to unbreak runtime. wxchordpro runs fine with this. More fixes to come...
Re: RFC: merge py-protobuf into protobuf
As mentioned elsewhere it might still be better to keep the Python
parts in a separate port so it can use the standard python.port.mk
infrastructure (we're going to run into this with mail/notmuch's
CFFI bindings too though I think in that case it may be trickier).
Also this may makes it simpler for other language bindings added
later as they too can use their own ports MODULES.
But if that doesn't work out (sometimes it can be a pain to use
those subcomponents with a system library rather than a built tree
for the main part of the software) then here are comments on the
diff as-is:
> How do I correctly set an RDEP on python for the -python package?
One way is to remove MODPY_RUNDEP=No, explicitly override
RUN_DEPENDS-main (set to empty), and let -python inherit the default.
Another is RUN_DEPENDS-python=${MODPY_RUN_DEPENDS}.
> Do I need to do the FLAVORS/FLAVOR thing? If so, how exactly?
Flavours apply to the whole build rather than subpackages so I don't
think it makes sense to use them. Just need to remove the ${MODPY_FLAVOR}
from deps.
> I assume that all dependencies of devel/py-protobuf${MODPY_FLAVOR}
> will need adjusting and a bump. Some handholding here would also be
> appreciated.
Yes, simple change of RUN_DEPENDS plus REVISION bump, that's all.
The @pkgpath changes are correct.
> +test:
btw do-test
[update] (unbreak) syncthing 1.23.2rc1
People did the needful
https://github.com/syncthing/syncthing/issues/8768
OK?
Kind regards,
Job
Index: net/syncthing/Makefile
===
RCS file: /cvs/ports/net/syncthing/Makefile,v
retrieving revision 1.46
diff -u -p -r1.46 Makefile
--- net/syncthing/Makefile 15 Feb 2023 17:18:09 - 1.46
+++ net/syncthing/Makefile 20 Feb 2023 10:55:26 -
@@ -1,7 +1,7 @@
-BROKEN = needs update - vendored quic-go does not support Go 1.20
COMMENT = open decentralized synchronization utility
-V =1.23.0
+PKGNAME = syncthing-1.23.2rc1
+V =1.23.2-rc.1
DISTNAME = syncthing-${V}
DISTFILES =syncthing-source-v${V}${EXTRACT_SUFX}
Index: net/syncthing/distinfo
===
RCS file: /cvs/ports/net/syncthing/distinfo,v
retrieving revision 1.31
diff -u -p -r1.31 distinfo
--- net/syncthing/distinfo 18 Jan 2023 14:11:38 - 1.31
+++ net/syncthing/distinfo 20 Feb 2023 10:55:26 -
@@ -1,2 +1,2 @@
-SHA256 (syncthing-source-v1.23.0.tar.gz) =
D2bT3Sp5FabzymdzwdwCNFREsmRKUzIRzh7lezca5Fg=
-SIZE (syncthing-source-v1.23.0.tar.gz) = 13936173
+SHA256 (syncthing-source-v1.23.2-rc.1.tar.gz) =
0EFtYwoh1pGmkJLCeQA/9PX32pvc107Egq9lZqfDPgA=
+SIZE (syncthing-source-v1.23.2-rc.1.tar.gz) = 14447129
Re: new: multimedia/karlyriceditor: synchronize music lyrics editor
On 23/02/17 12:55PM, Omar Polo wrote: > > plist needs to be re-generated, share/applications is owned by > desktop-file-utils: > plist regen-ed for the attached port: @bin bin/karlyriceditor share/applications/karlyriceditor.desktop share/pixmaps/ share/pixmaps/karlyriceditor.png @tag update-desktop-database > > not really runtested, I just opened the GUI and clicked around, but > seems to work and ports looks fine to me. With plist fixed, ok op@ > for import if someone wants to :) Thanks :) karlyriceditor.tar Description: Unix tar archive
CVS: cvs.openbsd.org: ports
CVSROOT:/cvs Module name:ports Changes by: st...@cvs.openbsd.org 2023/02/20 03:40:57 Modified files: net/librsync : Makefile distinfo Log message: update to librsync-2.3.4
CVS: cvs.openbsd.org: ports
CVSROOT:/cvs Module name:ports Changes by: st...@cvs.openbsd.org 2023/02/20 03:40:54 Modified files: mail/msmtp : Makefile distinfo mail/msmtp/patches: patch-doc_msmtp_texi mail/msmtp/pkg : PLIST Log message: update to msmtp-1.8.23
CVS: cvs.openbsd.org: ports
CVSROOT:/cvs Module name:ports Changes by: st...@cvs.openbsd.org 2023/02/20 03:40:51 Modified files: devel/py-jaraco-path: Makefile distinfo Log message: update to py3-jaraco.path-3.4.1
CVS: cvs.openbsd.org: ports
CVSROOT:/cvs Module name:ports Changes by: st...@cvs.openbsd.org 2023/02/20 03:40:48 Modified files: devel/py-isort : Makefile distinfo devel/py-isort/pkg: PLIST Log message: update to py3-isort-5.12.0
Re: gtk+4 slow application startup
On Mon, Feb 20, 2023 at 02:06:34PM +1100, Jonathan Gray wrote: > On Sun, Feb 19, 2023 at 01:34:41PM +0100, Antoine Jacoutot wrote: > > Hi. > > > > There seems to be a regression with mesa that makes gtk+4 application very > > slow > > to start. > > By default the GSK renderer uses OpenGL. > > As a workaround, you can temporarily use this to go back to the cairo > > renderer > > which makes gtk+4 applications fast again: > > > > export GSK_RENDERER=cairo > > What hardware is this on? Is there a Mesa or gtk bug for it? See dmesg below. > When did this behaviour start? Before the gtk update that recently > went in? Does it occur with GSK_RENDERER=vulkan? > GSK_RENDERER described in > https://docs.gtk.org/gtk4/running.html#gsk_renderer It did not happen on my previous amd ryzen. As soon as I switched to the new intel laptop, I was that bug (exact same installation, I rsync'd everything). It does *not* appear with GSK_RENDERER=vulkan but that renderer is buggy (not built by default) and segfaults on a regular basis. > There is > https://gitlab.freedesktop.org/mesa/mesa/-/issues/5113 > which briefly touches on shader cache. We disable the shader > cache to be able to uses pledge(2). Yes, that is the bug I was looking into. > At the moment, -current has Mesa 22.3.4. Mesa 22.3.5 is already > available and 22.3.6 is scheduled to be released in a few days. > https://docs.mesa3d.org/release-calendar.html OpenBSD 7.2-current (GENERIC.MP) #1056: Sat Feb 18 16:36:46 MST 2023 dera...@amd64.openbsd.org:/usr/src/sys/arch/amd64/compile/GENERIC.MP real mem = 16856313856 (16075MB) avail mem = 16326029312 (15569MB) random: good seed from bootblocks mpath0 at root scsibus0 at mpath0: 256 targets mainbus0 at root bios0 at mainbus0: SMBIOS rev. 3.4 @ 0x8e7f6000 (80 entries) bios0: vendor LENOVO version "N3CET52W (1.33 )" date 12/28/2022 bios0: LENOVO 21BNCTO1WW efi0 at bios0: UEFI 2.7 efi0: Lenovo rev 0x1330 acpi0 at bios0: ACPI 6.3 acpi0: sleep states S0 S3 S4 S5 acpi0: tables DSDT FACP SSDT SSDT SSDT SSDT SSDT TPM2 HPET APIC MCFG ECDT SSDT SSDT SSDT SSDT SSDT SSDT LPIT WSMT SSDT DBGP DBG2 NHLT POAT SSDT BATB DMAR SSDT SSDT SSDT ASF! BGRT PHAT UEFI FPDT acpi0: wakeup devices PEG0(S4) PEGP(S4) PEGP(S4) PEG2(S4) PEGP(S4) XHCI(S3) XDCI(S4) HDAS(S4) CNVW(S4) RP01(S4) PXSX(S4) RP02(S4) PXSX(S4) RP03(S4) PXSX(S4) RP04(S4) [...] acpitimer0 at acpi0: 3579545 Hz, 24 bits acpihpet0 at acpi0: 1920 Hz acpimadt0 at acpi0 addr 0xfee0: PC-AT compat cpu0 at mainbus0: apid 0 (boot processor) cpu0: 12th Gen Intel(R) Core(TM) i5-1245U, 1587.96 MHz, 06-9a-04 cpu0: FPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CFLUSH,DS,ACPI,MMX,FXSR,SSE,SSE2,SS,HTT,TM,PBE,SSE3,PCLMUL,DTES64,MWAIT,DS-CPL,VMX,SMX,EST,TM2,SSSE3,SDBG,FMA3,CX16,xTPR,PDCM,PCID,SSE4.1,SSE4.2,x2APIC,MOVBE,POPCNT,DEADLINE,AES,XSAVE,AVX,F16C,RDRAND,NXE,PAGE1GB,RDTSCP,LONG,LAHF,ABM,3DNOWP,PERF,ITSC,FSGSBASE,TSC_ADJUST,BMI1,AVX2,SMEP,BMI2,ERMS,INVPCID,RDSEED,ADX,SMAP,CLFLUSHOPT,CLWB,PT,SHA,UMIP,PKU,WAITPKG,PKS,MD_CLEAR,IBRS,IBPB,STIBP,L1DF,SSBD,SENSOR,ARAT,XSAVEOPT,XSAVEC,XGETBV1,XSAVES cpu0: 48KB 64b/line 12-way D-cache, 32KB 64b/line 8-way I-cache, 1MB 64b/line 10-way L2 cache, 12MB 64b/line 12-way L3 cache cpu0: smt 0, core 0, package 0 mtrr: Pentium Pro MTRR support, 10 var ranges, 88 fixed ranges cpu0: apic clock running at 38MHz cpu0: mwait min=64, max=64, C-substates=0.2.0.2.0.1.0.1, IBE cpu1 at mainbus0: apid 1 (application processor) cpu1: 12th Gen Intel(R) Core(TM) i5-1245U, 1878.15 MHz, 06-9a-04 cpu1: FPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CFLUSH,DS,ACPI,MMX,FXSR,SSE,SSE2,SS,HTT,TM,PBE,SSE3,PCLMUL,DTES64,MWAIT,DS-CPL,VMX,SMX,EST,TM2,SSSE3,SDBG,FMA3,CX16,xTPR,PDCM,PCID,SSE4.1,SSE4.2,x2APIC,MOVBE,POPCNT,DEADLINE,AES,XSAVE,AVX,F16C,RDRAND,NXE,PAGE1GB,RDTSCP,LONG,LAHF,ABM,3DNOWP,PERF,ITSC,FSGSBASE,TSC_ADJUST,BMI1,AVX2,SMEP,BMI2,ERMS,INVPCID,RDSEED,ADX,SMAP,CLFLUSHOPT,CLWB,PT,SHA,UMIP,PKU,PKS,MD_CLEAR,IBRS,IBPB,STIBP,L1DF,SSBD,SENSOR,ARAT,XSAVEOPT,XSAVEC,XGETBV1,XSAVES cpu1: 48KB 64b/line 12-way D-cache, 32KB 64b/line 8-way I-cache, 1MB 64b/line 10-way L2 cache, 12MB 64b/line 12-way L3 cache cpu1: smt 1, core 0, package 0 cpu2 at mainbus0: apid 8 (application processor) cpu2: 12th Gen Intel(R) Core(TM) i5-1245U, 1533.83 MHz, 06-9a-04 cpu2: FPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CFLUSH,DS,ACPI,MMX,FXSR,SSE,SSE2,SS,HTT,TM,PBE,SSE3,PCLMUL,DTES64,MWAIT,DS-CPL,VMX,SMX,EST,TM2,SSSE3,SDBG,FMA3,CX16,xTPR,PDCM,PCID,SSE4.1,SSE4.2,x2APIC,MOVBE,POPCNT,DEADLINE,AES,XSAVE,AVX,F16C,RDRAND,NXE,PAGE1GB,RDTSCP,LONG,LAHF,ABM,3DNOWP,PERF,ITSC,FSGSBASE,TSC_ADJUST,BMI1,AVX2,SMEP,BMI2,ERMS,INVPCID,RDSEED,ADX,SMAP,CLFLUSHOPT,CLWB,PT,SHA,UMIP,PKU,PKS,MD_CLEAR,IBRS,IBPB,STIBP,L1DF,SSBD,SENSOR,ARAT,XSAVEOPT,XSAVEC,XGETBV1,XSAVES cpu2: 48KB 64b/line 12-way D-cache, 32KB 64b/line 8-way I-cache, 1MB 64b/line 10-way L2 cache, 12MB 64b/line 12-way L3 cache cpu2: smt 0, core 4, package 0
RFC: merge py-protobuf into protobuf
As of protobuf 22.0, upstream no longer provides language-specific
tarballs. As a consequence, we will need to build the protobuf packages
from the same tarball. To reduce the churn in the actual update, I'd
like to fold py-protobuf into protobuf first.
It would probably be acceptable and easier to merge py3-protobuf into
the C++ protobuf package. I tried to use MULTI_PACKAGES to keep the
current status quo. I think we want MULTI_PACKAGES if we should ever
need to ship other language bindings.
I don't really like the post-build and post-install steps, but since the
python module and the cmake module need to use different ${WRKSRC}
(which isn't MULTI_PACKAGES-aware as far as I can see), it seems
unavoidable to handroll a few things. As an aside, I'm not entirely sure
how much the loading of the Python module buys me here...
The update paths from protobuf-3.21.12p0 -> protobuf-3.21.12p1 and
py3-protobuf-4.21.12 py3-protobuf-4.21.12p0 work in my testing.
I have a few questions:
First off, are there better ideas or approaches?
Are the @pkgpath annotations in the PLISTs sensible?
How do I correctly set an RDEP on python for the -python package?
Do I need to do the FLAVORS/FLAVOR thing? If so, how exactly?
I assume that all dependencies of devel/py-protobuf${MODPY_FLAVOR}
will need adjusting and a bump. Some handholding here would also be
appreciated.
Once this is in proper shape, I will of course run it through a bulk
before commit.
Index: Makefile
===
RCS file: /cvs/ports/devel/protobuf/Makefile,v
retrieving revision 1.66
diff -u -p -r1.66 Makefile
--- Makefile19 Feb 2023 11:50:53 - 1.66
+++ Makefile20 Feb 2023 10:01:54 -
@@ -1,14 +1,24 @@
-COMMENT = c++ protocol buffers
+COMMENT-main = c++ protocol buffers (Google data interchange format)
+COMMENT-python = python bindings to the Google data interchange format
+
+MULTI_PACKAGES = -main -python
-CPPMAJOR = 3
PROTOBUF_VERSION = 21.12
-V =${CPPMAJOR}.${PROTOBUF_VERSION}
+CMAJOR = 3
+CVERSION = ${CMAJOR}.${PROTOBUF_VERSION}
+PMAJOR = 4
+PVERSION = ${PMAJOR}.${PROTOBUF_VERSION}
+
+SUBST_VARS += CVERSION PVERSION
+UPDATE_PLIST_ARGS += -i CVERSION -i PVERSION
+
TAG = v${PROTOBUF_VERSION:S/rc-/rc/}
-DISTNAME = protobuf-cpp-${V}
-PKGNAME = protobuf-${V:S/-//g}
-REVISION = 0
-WRKDIST = ${WRKDIR}/protobuf-${V}
+DISTNAME = protobuf-all-${PROTOBUF_VERSION}
+FULLPKGNAME-main = protobuf-${CVERSION:S/-//g}
+FULLPKGNAME-python = py3-protobuf-${PVERSION:S/-//g}
+REVISION-main =1
+REVISION-python = 0
SHARED_LIBS += protobuf-lite 19.0# 32.12
SHARED_LIBS += protobuf21.0# 32.12
@@ -21,15 +31,45 @@ HOMEPAGE = https://github.com/protocolb
# New BSD
PERMIT_PACKAGE = Yes
+WRKDIST = ${WRKDIR}/protobuf-${PROTOBUF_VERSION}
+
+FIX_EXTRACT_PERMISSIONS = Yes
+
WANTLIB += c m pthread ${COMPILER_LIBCXX} z
MASTER_SITES =
https://github.com/protocolbuffers/protobuf/releases/download/${TAG}/
COMPILER = base-clang ports-gcc
-MODULES = devel/cmake
+MODULES = devel/cmake \
+ lang/python
+
+# XXX need RDEP on python for -python package...
+# Do I need FLAVORS = python3 / FLAVOR = python3 ?
+MODPY_RUNDEP = No
+MODPY_PYBUILD =No
+MODPY_SETUPTOOLS = Yes
CONFIGURE_ARGS += -Dprotobuf_BUILD_SHARED_LIBS=ON
CONFIGURE_ARGS += -Dprotobuf_BUILD_TESTS=OFF
+
+pre-configure:
+ ln -sf ${MODPY_BIN} ${WRKDIR}/bin/python
+
+PROTO_PY_CMD = cd ${WRKSRC}/python && \
+ ${SETENV} ${MAKE_ENV} PROTOC=${WRKBUILD}/protoc \
+ python
+
+post-build:
+ ${PROTO_PY_CMD} -O -sBm build -w --no-isolation
+
+post-install:
+ ${INSTALL_DATA_DIR} ${WRKINST}${MODPY_LIBDIR}; \
+ ${PROTO_PY_CMD} -O -m installer -d ${WRKINST}
${WRKSRC}/python/dist/*.whl
+
+TEST_DEPENDS +=math/py-numpy${MODPY_FLAVOR}
+
+test:
+ cd ${WRKSRC}/python && ${_PBUILD} env ${MAKE_ENV} python setup.py test
.include
Index: distinfo
===
RCS file: /cvs/ports/devel/protobuf/distinfo,v
retrieving revision 1.40
diff -u -p -r1.40 distinfo
--- distinfo14 Dec 2022 17:22:42 - 1.40
+++ distinfo19 Feb 2023 20:46:45 -
@@ -1,2 +1,2 @@
-SHA256 (protobuf-cpp-3.21.12.tar.gz) =
TqubUkqlkTxv/7ILKoq/Xvf5WoC8BwHzptu0xgf3NGA=
-SIZE (protobuf-cpp-3.21.12.tar.gz) = 4842303
+SHA256 (protobuf-all-21.12.tar.gz) =
LGo2x7WlWsyuBjZn7zxV8mQuZ0dtltNV/wrLE9u0fwk=
+SIZE (protobuf-all-21.12.tar.gz) = 7649074
Index: pkg/DESCR
===
RCS
CVS: cvs.openbsd.org: ports
CVSROOT:/cvs Module name:ports Changes by: ajacou...@cvs.openbsd.org 2023/02/20 03:15:06 Modified files: devel/p5-Alien-wxWidgets: Makefile Removed files: devel/p5-Alien-wxWidgets/patches: patch-Build_PL Log message: Fix dependencies to unbreak p5-Wx.
Re: [new] graphics/libjxl for jpeg-xl support
Le Sat, Feb 18, 2023 at 02:57:06PM +0100, Landry Breuil a écrit :
> Hi,
>
> here's a new port for libjxl (https://jpegxl.info/,
> https://jpegxl.info/why-jxl.html) and its dependency
> (https://github.com/google/highway).
>
> event if jpegxl support is being dropped from chromium, and was never
> enabled in firefox, it is supported by many other things in the
> ecosystem. Cf https://cloudinary.com/blog/the-case-for-jpeg-xl for
> arguments. My personal usecase is for geo/gdal.
>
> highway's tests all pass on i386/amd64, and for jpegxl it's "not so
> bad":
> test-0.7.0-amd64.log:80% tests passed, 384 tests failed out of 1957
> test-0.8.1-amd64.log:76% tests passed, 824 tests failed out of 3488
> test-0.8.1-i386.log:76% tests passed, 825 tests failed out of 3488
>
> i've looked in the portstree for potential consumers, based on the ports
> depending on it in freebsd's portstree:
>
> - graphics/libvips: supported since 8.11, our port is at 8.9
> - graphics/imlib2: has a plugin to support the format
> - multimedia/aom: disabled by default, behind -DCONFIG_TUNE_BUTTERAUGLI=1
> - gimp/snapshot: already force-disabled via -Djpeg-xl=disabled
> - gimp/stable: uses it if found (checking for libjxl >= 0.6.1... yes)
> - graphics/darktable: needs 4.2
> (https://github.com/darktable-org/darktable/issues/10866)
> - sdl2-image: support added in 2.6
> - graphics/ffmpeg: disabled by default
> (https://github.com/FFmpeg/FFmpeg/blob/master/configure#L244)
> - graphics/ImageMagick: needs --with-jxl, not active by default ?
> - graphics/GraphicsMagick uses it if found (JPEG-XL --with-jxl=yes yes)
> - graphics/gthumb: uses it if found
> (https://gitlab.gnome.org/GNOME/gthumb/-/blob/master/meson_options.txt#L61)
> - graphics/geeqie: already force-disabled via -Djpegxl=disabled
> - geo/gdal: uses it if found, only as a plain driver and sadly not
> available for tiff compression ( Cannot build JXL as a TIFF codec as
> it requires building with -DGDAL_USE_TIFF_INTERNAL=ON)
attached are 3 diffs to enable jxl support in gimp/stable, gdal &
graphicsmagick (without REVISION bump for readability, but will be
included if commited). I can also disable support for jxl by default in
those until maintainer decides what to do with it :)
Landry
Index: Makefile
===
RCS file: /cvs/ports/graphics/GraphicsMagick/Makefile,v
retrieving revision 1.69
diff -u -r1.69 Makefile
--- Makefile31 Oct 2022 23:14:54 - 1.69
+++ Makefile18 Feb 2023 17:18:52 -
@@ -19,6 +19,7 @@
WANTLIB += ${COMPILER_LIBCXX} ICE SM X11 Xau Xdmcp Xext aom bz2 c
WANTLIB += dav1d de265 freetype heif iconv jasper jbig jpeg lcms2
WANTLIB += ltdl lzma m png tiff webp webpmux wmflite-0.2 x265 xcb
+WANTLIB += brotlicommon brotlidec brotlienc hwy jxl jxl_threads
WANTLIB += xml2 z zstd
WANTLIB += perl # uses perl ABI
@@ -34,6 +35,7 @@
graphics/jbigkit \
graphics/lcms2 \
graphics/libwebp \
+ graphics/libjxl \
graphics/libwmf \
graphics/png \
graphics/tiff \
Index: pkg/PLIST
===
RCS file: /cvs/ports/graphics/GraphicsMagick/pkg/PLIST,v
retrieving revision 1.27
diff -u -r1.27 PLIST
--- pkg/PLIST 24 Apr 2022 21:08:29 - 1.27
+++ pkg/PLIST 18 Feb 2023 17:18:52 -
@@ -159,6 +159,8 @@
@so lib/GraphicsMagick/modules-Q16/coders/jp2.so
lib/GraphicsMagick/modules-Q16/coders/jpeg.la
@so lib/GraphicsMagick/modules-Q16/coders/jpeg.so
+lib/GraphicsMagick/modules-Q16/coders/jxl.la
+@so lib/GraphicsMagick/modules-Q16/coders/jxl.so
lib/GraphicsMagick/modules-Q16/coders/label.la
@so lib/GraphicsMagick/modules-Q16/coders/label.so
lib/GraphicsMagick/modules-Q16/coders/locale.la
? 2.3-configure
? 2.4-configure
? 3.4.raster.formats
? 3.4.vector.formats
? 3.5.raster.formats
? 3.5.vector.formats
? Makefile.internaltiff
? Makefile.rc
? configure
? configure.log
? files
? gdal-3.6.1-libgdal.so.45.0
? gdal-3.6.1rc1-libgdal.so.44.0
? gdal-3.6.2-libgdal.so.45.0
? patch-swig_python_setup_py_in
Index: Makefile
===
RCS file: /cvs/ports/geo/gdal/Makefile,v
retrieving revision 1.121
diff -u -r1.121 Makefile
--- Makefile8 Jan 2023 16:25:09 - 1.121
+++ Makefile18 Feb 2023 17:18:41 -
@@ -48,6 +48,7 @@
print/poppler \
graphics/png \
graphics/giflib \
+ graphics/libjxl \
graphics/libwebp \
graphics/jpeg \
graphics/openjp2 \
@@ -56,7 +57,7 @@
devel/geotiff>=1.5.0
WANTLIB-main = c crypto curl expat freexl geos_c geotiff \
- gif hdf5 iconv jpeg json-c lzma lz4 m \
+
CVS: cvs.openbsd.org: ports
CVSROOT:/cvs Module name:ports Changes by: ajacou...@cvs.openbsd.org 2023/02/20 02:45:33 Modified files: textproc/enchant2: Makefile distinfo textproc/enchant2/pkg: PLIST Log message: Update to enchant2-2.3.4.
CVS: cvs.openbsd.org: ports
CVSROOT:/cvs Module name:ports Changes by: ajacou...@cvs.openbsd.org 2023/02/20 02:39:04 Modified files: security/gnutls: Makefile distinfo security/gnutls/pkg: PLIST Log message: Update to gnutls-3.8.0. Survived an amd64 bulk.
CVS: cvs.openbsd.org: ports
CVSROOT:/cvs Module name:ports Changes by: ajacou...@cvs.openbsd.org 2023/02/20 02:36:04 Modified files: textproc/chordpro: Makefile Log message: Missed bumps.
CVS: cvs.openbsd.org: ports
CVSROOT:/cvs Module name:ports Changes by: ajacou...@cvs.openbsd.org 2023/02/20 02:34:27 Modified files: x11/py-wxPython: Makefile Log message: Missing BDEP+RDEP on devel/py-six.
Re: [proposal] Add a note about unveil and localized directories in www/firefox-i18n
Le Sun, Feb 19, 2023 at 07:18:35PM +0100, Joel Carnat a écrit : > Hi, > > Recently, I drag and dropped an HTML file from my localized ~/Downloads > directory to Firefox ; to render this local file. And it wouldn't open even > though that directory was listed in /etc/firefox/unveil.main. I can save > files to it when I download stuff but the directory can not be listed and > files can't be loaded by Firefox. I'm perfectly aware of the issue, and wouldnt really know where to document the workarounds, but i'm pretty sure this isnt supposed to work in localized environments, even if the XDG stuff is properly setupped there's https://github.com/openbsd/ports/blob/master/www/mozilla-firefox/patches/patch-toolkit_components_downloads_DownloadIntegration_sys_mjs to make sure we end up in ~/Downloads. Cf https://bugzilla.mozilla.org/show_bug.cgi?id=1696958 for the rationale at the time.. so even if you have a localized environment, that patch should make sure that your downloads end up in ~/Downloads (if it exists, which is another problem with pledge). Granted, maybe that's not what user wants, and i'm fine dropping that patch as long as users having opted-in for localization are aware one way or the other that they **have** to modify the unveil config. Maybe MESSAGE is the way.. > After a bit of try & fail, I identified that this particular directory also > has to be referenced in /etc/firefox/unveil.content. Since then, I can open > the files from this directory. This also solves the error when you use > "file://home//Downloads" in the URL bar. > > As this is not straight forward and limited to the cases when you want a > localized environment, what about adding a note to www/firefox-i18n MESSAGE > file? > > Attached is a MESSAGE patch proposal. Not a bad idea, but sadly in my experience users often ignore MESSAGEs :) Landry
[update] sysutils/fzf 0.38.0
Hi,
a simple patch to update sysutils/fzf for the latest version 0.38.0.
Build with go 1.20.1 and tests OK on current/amd64.
Laurent
Index: Makefile
===
RCS file: /cvs/ports/sysutils/fzf/Makefile,v
retrieving revision 1.17
diff -u -p -r1.17 Makefile
--- Makefile 26 Jan 2023 14:14:38 - 1.17
+++ Makefile 20 Feb 2023 09:04:04 -
@@ -1,9 +1,9 @@
COMMENT = command-line fuzzy finder
MODGO_MODNAME = github.com/junegunn/fzf
-MODGO_VERSION = v0.0.0-20230124131114-2023012408ff
+MODGO_VERSION = v0.0.0-20230215142442-352ea072269d
-V = 0.37.0
+V = 0.38.0
DISTNAME = fzf-${V}
CATEGORIES = sysutils
Index: distinfo
===
RCS file: /cvs/ports/sysutils/fzf/distinfo,v
retrieving revision 1.10
diff -u -p -r1.10 distinfo
--- distinfo 26 Jan 2023 14:14:38 - 1.10
+++ distinfo 20 Feb 2023 09:04:04 -
@@ -1,4 +1,4 @@
-SHA256 (fzf-0.37.0.zip) = M05y9OzI4yaWaUKxcb1D+bihHo6CuTLq2gIAsmnunpA=
+SHA256 (fzf-0.38.0.zip) = 85D9ETJJ4MuCNC79v1PQwwYstswayeICJdk0q3RrOfQ=
SHA256 (go_modules/github.com/gdamore/encoding/@v/v1.0.0.mod) = pJgRJVFfDy3yU8LeOjrBlwx0Q+W2adlH6HTnezaBtuU=
SHA256 (go_modules/github.com/gdamore/encoding/@v/v1.0.0.zip) = Y4qYMuL2LRGNfFEdhr2uFiKlHzMd5IoB2Sn9JOvmoqY=
SHA256 (go_modules/github.com/gdamore/tcell/v2/@v/v2.5.4.mod) = 4zhutrVn0oD6CGHqAr93IkVDVuXmzBVThvjmX/RGQ5E=
@@ -52,7 +52,7 @@ SHA256 (go_modules/golang.org/x/tools/@v
SHA256 (go_modules/golang.org/x/tools/@v/v0.1.12.zip) = SxIuDkcDvEAUyxz4wBT8+T6n1y8B2nlJk2U0b1TLuFE=
SHA256 (go_modules/golang.org/x/xerrors/@v/v0.0.0-20190717185122-a985d3407aa7.mod) = ql4+ybt7n2gWCe+sAZ2d4ae6dxkkj/Hqon54iC2z1/U=
SHA256 (go_modules/golang.org/x/xerrors/@v/v0.0.0-20190717185122-a985d3407aa7.zip) = xOnwY8/tVGyQ8AqWV96sT5FaiZT4y+bb0/GOeeuDAs8=
-SIZE (fzf-0.37.0.zip) = 273480
+SIZE (fzf-0.38.0.zip) = 276043
SIZE (go_modules/github.com/gdamore/encoding/@v/v1.0.0.mod) = 77
SIZE (go_modules/github.com/gdamore/encoding/@v/v1.0.0.zip) = 19867
SIZE (go_modules/github.com/gdamore/tcell/v2/@v/v2.5.4.mod) = 308
Re: help creating new port: x11/xfce4/xfce4-docklike
Hi, I’ve spend part of the weekend trying to solve the Firefox / Thunderbird issue. In details, those applications can’t be docked and don’t get their icon displayed. Long story short: I couldn’t solve it. I tried docklike on a couple of Linux distro and could reproduce the bug. Only MX Linux doesn’t get the bug. But when getting its source and compile on OpenBSD, the bug is still there. I’ll continue digging and let you know if I can find a solution. Regards, Joel C. > Le 18 févr. 2023 à 15:02, Landry Breuil a écrit : > > Le Sat, Feb 18, 2023 at 01:44:20PM +, Klemens Nanni a écrit : >> 2/18/23 13:16, Landry Breuil пишет: >>> i havent tested it yet, but here's a port of the latest git commit, with >>> a simplified Makefile. >> >> Do you intend to upstream the local patches? I was surprised to see >> them given your use of XFCE4_COMMIT. > > i think joel wanted to upstream them :) > >> COMMENT must not start with articles or end in a full stop, I think. > > Right > >> Should this be hooked up to one of the xfce meta packages? > > Maybe, if it works and is useful.. >
Re: [new] re2, required for mtxclient/nheko update
Le Sun, Feb 19, 2023 at 04:51:46PM +, Klemens Nanni a écrit : > 19.02.2023 16:46, Klemens Nanni пишет: > > Newest version builds and packages the .pc file on its own, > > mtxclient finds it. > > > > Feel free to commit this cmake version or provide an OK. > > > > I went with re-20230201, i.e. without 0. dances in the PKGNAME. > > We do this in net/tg_owt and some other ports, but I doubt upstream will > > actually change their version scheme, so stick with simpler versioning. > > Now with missing WANTLIB, sorry for the noise. > > All 97 targets build quickly, tests included. > They take a long time to run, though (programs are aptly called > exhaustive_test*). i had seen the newest release but went with 2022-04-01 just because that's what mtxclient 'bundles' via https://github.com/Nheko-Reborn/mtxclient/blob/master/subprojects/re2.wrap (and adds a patch to build it with meson on top) but great if latest works and installs the .pc file for mtxclient. i didnt use the GH_ bits because there was a direct /archive/ link in re2.wrap but i might have mixed things with autogenerated tarballs.. thanks for finishing it up :) OK for me. Landry
CVS: cvs.openbsd.org: ports
CVSROOT:/cvs Module name:ports Changes by: rob...@cvs.openbsd.org 2023/02/20 01:47:39 Modified files: devel/libusb1 : Makefile Added files: devel/libusb1/patches: patch-libusb_os_threads_posix_c Log message: call getthrid() directly instead of going through syscall()
Re: gtk+4 slow application startup
Le Mon, Feb 20, 2023 at 02:06:34PM +1100, Jonathan Gray a écrit : > On Sun, Feb 19, 2023 at 01:34:41PM +0100, Antoine Jacoutot wrote: > > Hi. > > > > There seems to be a regression with mesa that makes gtk+4 application very > > slow > > to start. > > By default the GSK renderer uses OpenGL. > > As a workaround, you can temporarily use this to go back to the cairo > > renderer > > which makes gtk+4 applications fast again: > > > > export GSK_RENDERER=cairo > > What hardware is this on? Is there a Mesa or gtk bug for it? Fwiw i could reproduce this slowness on a T495s (amdgpu), an optiplex 960(old radeondrm) with gtk4-demo and a T480 (inteldrm) starting gnome-calculator.
CVS: cvs.openbsd.org: ports
CVSROOT:/cvs Module name:ports Changes by: rsadow...@cvs.openbsd.org 2023/02/20 01:40:42 Modified files: x11/kde-plasma : Makefile.inc x11/kde-plasma/breeze: distinfo x11/kde-plasma/breeze/pkg: PLIST x11/kde-plasma/breeze-grub: distinfo x11/kde-plasma/breeze-gtk: distinfo x11/kde-plasma/breeze-gtk/pkg: PLIST x11/kde-plasma/kdecoration: Makefile distinfo x11/kde-plasma/oxygen: Makefile distinfo Log message: Update KDE Plasma to 5.27.0
CVS: cvs.openbsd.org: ports
CVSROOT:/cvs Module name:ports Changes by: rob...@cvs.openbsd.org 2023/02/20 01:26:48 Modified files: mail/grommunio/dav/patches: patch-config_php patch-vendor_composer_autoload_classmap_php patch-vendor_composer_autoload_files_php patch-vendor_composer_autoload_static_php mail/grommunio/sync/patches: patch-config_php patch-lib_grommunio_grommunio_php patch-lib_grommunio_listfolders_php patch-vendor_composer_autoload_classmap_php patch-vendor_composer_autoload_static_php Added files: mail/grommunio/dav/patches: patch-lib_GLogger_php patch-vendor_autoload_php mail/grommunio/sync/patches: patch-vendor_autoload_php Log message: set some globals only once in the autoloader to avoid warnings in the logs
CVS: cvs.openbsd.org: ports
CVSROOT:/cvs Module name:ports Changes by: rob...@cvs.openbsd.org 2023/02/20 01:26:26 Modified files: mail/grommunio/gromox: Makefile distinfo Removed files: mail/grommunio/gromox/patches: patch-mda_delivery_app_main_cpp Log message: remove upstreamed patch
mail/p5-Log-Procmail: Update to 0.14
Hi, ports@:
Here is a simple patch for mail/p5-Log-Procmail to update to 0.14,
it build well and pass all tests on amd64-current system.
No other ports depend on it.
Cheers !
wenIndex: Makefile
===
RCS file: /cvs/ports/mail/p5-Log-Procmail/Makefile,v
retrieving revision 1.16
diff -u -p -r1.16 Makefile
--- Makefile11 Mar 2022 19:34:47 - 1.16
+++ Makefile20 Feb 2023 07:41:16 -
@@ -1,8 +1,7 @@
COMMENT= perl module for reading procmail logs
-DISTNAME= Log-Procmail-0.12
+DISTNAME= Log-Procmail-0.14
CATEGORIES=mail textproc
-REVISION= 1
# GPL/Artistic
PERMIT_PACKAGE=Yes
Index: distinfo
===
RCS file: /cvs/ports/mail/p5-Log-Procmail/distinfo,v
retrieving revision 1.3
diff -u -p -r1.3 distinfo
--- distinfo3 Nov 2014 09:35:54 - 1.3
+++ distinfo20 Feb 2023 07:41:16 -
@@ -1,2 +1,2 @@
-SHA256 (Log-Procmail-0.12.tar.gz) =
j+e9xa4YHC1BtkLJw5+j5MUD4svYWsRcoMwdleaUeI0=
-SIZE (Log-Procmail-0.12.tar.gz) = 18631
+SHA256 (Log-Procmail-0.14.tar.gz) =
aYILuRkHw6qCHFIS5lKsRevboYPeuY+IaRn9XrViKtI=
+SIZE (Log-Procmail-0.14.tar.gz) = 26785
Index: pkg/PLIST
===
RCS file: /cvs/ports/mail/p5-Log-Procmail/pkg/PLIST,v
retrieving revision 1.2
diff -u -p -r1.2 PLIST
--- pkg/PLIST 11 Mar 2022 19:34:47 - 1.2
+++ pkg/PLIST 20 Feb 2023 07:41:16 -
@@ -1,5 +1,3 @@
-bin/mailstat.pl
${P5SITE}/Log/
${P5SITE}/Log/Procmail.pm
-@man man/man1/mailstat.pl.1
@man man/man3p/Log::Procmail.3p
CVS: cvs.openbsd.org: ports
CVSROOT:/cvs Module name:ports Changes by: lan...@cvs.openbsd.org 2023/02/20 01:09:29 Modified files: security/nss : Tag: OPENBSD_7_2 Makefile Added files: security/nss/patches: Tag: OPENBSD_7_2 patch-nss_lib_pkcs12_p12d_c patch-nss_lib_pkcs12_p12t_h patch-nss_lib_pkcs12_p12tmpl_c Log message: security/nss: backport fix from 3.88.1 CVE-2023-0767: Arbitrary memory write via PKCS 12 in NSS
