CVS: cvs.openbsd.org: ports
CVSROOT:/cvs Module name:ports Changes by: ajacou...@cvs.openbsd.org 2024/02/04 00:47:32 Modified files: net/gssdp : Makefile net/gssdp/pkg : PLIST Log message: Don't build man pages: it requires textproc/pandoc which does not build on the exopi cluster. And when using a package built from somewhere else, it just fails with illegal instruction.
Remove: x11/qt5/qtwebkit preparations
Hi ports@, hi ports hackers, I would like to get rid of 'x11/qt5/qtwebkit'. Here is a short list with ports using qtwebkit with some comments. All $MAINTAINER CC'd. - geo/qgis: I can't imagine that such an active project would still use it. - x11/py-qt5: Easy to remove - x11/qt5/docs: Easy to remove - x11/qt5/qttools: Easy to remove - x11/smtube: Upstream dead? Nobody package is anymore: https://repology.org/project/smtube/versions - devel/zeal: I have an WIP update. - www/ruby-capybara-webkit: Sent to ports for removal - textproc/goldendict: I know, there is an issue with qt6 goldendict. I think that is the same issue as it is in zeal. - databases/recoll: Needs an update, upstream switched to qt5-webengine - productivity/libalkimia: Needs an update, upstream switched to qt5-webengine - databases/kexi: On my list, remove the dependency - devel/kreport: On my list, remove the dependency - multimedia/upplay: Needs an update, ping maintainer - net/qsyncthingtray: dead upstream? - misc/subsurface: dead upstream? - meta/qt5: On my list - mail/trojita: Already removed I would be delighted if the maintainers could take a look at this. Grateful for any support! Rafael
Remove: www/ruby-capybara-webkit
Ok to remove www/ruby-capybara-webkit? It still use qt5/qtwebkit. Nothing depends on it. IMO it's better to not package such an insecure webkit package. Rafael
sparc64 bulk build report
Bulk build on sparc64-0a.ports.openbsd.org Started : Thu Feb 1 01:28:04 MST 2024 Finished: Sat Feb 3 22:32:17 MST 2024 Duration: 2 Days 21 hours 4 minutes Built using OpenBSD 7.4-current (GENERIC.MP) #3: Wed Jan 31 22:51:31 MST 2024 Built 9456 packages Number of packages built each day: Feb 1: 7046 Feb 2: 1944 Feb 3: 466 Critical path missing pkgs: http://build-failures.rhaalovely.net/sparc64/2024-02-01/summary.log Build failures: 116 http://build-failures.rhaalovely.net/sparc64/2024-02-01/audio/libcanberra.log http://build-failures.rhaalovely.net/sparc64/2024-02-01/audio/ncmpc.log http://build-failures.rhaalovely.net/sparc64/2024-02-01/audio/ruby-vorbis_comment,ruby33.log http://build-failures.rhaalovely.net/sparc64/2024-02-01/audio/solfege.log http://build-failures.rhaalovely.net/sparc64/2024-02-01/audio/xmms2.log http://build-failures.rhaalovely.net/sparc64/2024-02-01/comms/gnuradio.log http://build-failures.rhaalovely.net/sparc64/2024-02-01/databases/ruby-amalgalite,ruby31.log http://build-failures.rhaalovely.net/sparc64/2024-02-01/databases/ruby-ldap,ruby33.log http://build-failures.rhaalovely.net/sparc64/2024-02-01/databases/ruby-mysql2,ruby33.log http://build-failures.rhaalovely.net/sparc64/2024-02-01/databases/ruby-pg,ruby33.log http://build-failures.rhaalovely.net/sparc64/2024-02-01/databases/ruby-sqlite3,ruby33.log http://build-failures.rhaalovely.net/sparc64/2024-02-01/databases/ruby-tiny_tds,ruby33.log http://build-failures.rhaalovely.net/sparc64/2024-02-01/databases/ruby-trilogy,ruby33.log http://build-failures.rhaalovely.net/sparc64/2024-02-01/devel/arm-none-eabi/gdb.log http://build-failures.rhaalovely.net/sparc64/2024-02-01/devel/avr/gcc.log http://build-failures.rhaalovely.net/sparc64/2024-02-01/devel/difftastic.log http://build-failures.rhaalovely.net/sparc64/2024-02-01/devel/mtxclient.log http://build-failures.rhaalovely.net/sparc64/2024-02-01/devel/py-debugpy,python3.log http://build-failures.rhaalovely.net/sparc64/2024-02-01/devel/py-thrift,python3.log http://build-failures.rhaalovely.net/sparc64/2024-02-01/devel/qcoro.log http://build-failures.rhaalovely.net/sparc64/2024-02-01/devel/ruby-ffi,ruby33.log http://build-failures.rhaalovely.net/sparc64/2024-02-01/devel/ruby-idn,ruby33.log http://build-failures.rhaalovely.net/sparc64/2024-02-01/devel/ruby-kgio,ruby33.log http://build-failures.rhaalovely.net/sparc64/2024-02-01/devel/ruby-narray,ruby33.log http://build-failures.rhaalovely.net/sparc64/2024-02-01/devel/ruby-ncurses,ruby33.log http://build-failures.rhaalovely.net/sparc64/2024-02-01/devel/ruby-nio4r,ruby33.log http://build-failures.rhaalovely.net/sparc64/2024-02-01/devel/ruby-rbtree,ruby33.log http://build-failures.rhaalovely.net/sparc64/2024-02-01/devel/ruby-subset_sum,ruby33.log http://build-failures.rhaalovely.net/sparc64/2024-02-01/devel/ruby-yajl,ruby33.log http://build-failures.rhaalovely.net/sparc64/2024-02-01/devel/vim-command-t.log http://build-failures.rhaalovely.net/sparc64/2024-02-01/devel/xsd.log http://build-failures.rhaalovely.net/sparc64/2024-02-01/devel/yder.log http://build-failures.rhaalovely.net/sparc64/2024-02-01/emulators/libretro-pcsx-rearmed.log http://build-failures.rhaalovely.net/sparc64/2024-02-01/emulators/snes9x.log http://build-failures.rhaalovely.net/sparc64/2024-02-01/games/bugdom.log http://build-failures.rhaalovely.net/sparc64/2024-02-01/games/bugdom2.log http://build-failures.rhaalovely.net/sparc64/2024-02-01/games/cataclysm-dda,no_x11.log http://build-failures.rhaalovely.net/sparc64/2024-02-01/games/choria.log http://build-failures.rhaalovely.net/sparc64/2024-02-01/games/colobot/colobot.log http://build-failures.rhaalovely.net/sparc64/2024-02-01/games/devilutionx.log http://build-failures.rhaalovely.net/sparc64/2024-02-01/games/emptyclip.log http://build-failures.rhaalovely.net/sparc64/2024-02-01/games/fheroes2.log http://build-failures.rhaalovely.net/sparc64/2024-02-01/games/gnukem.log http://build-failures.rhaalovely.net/sparc64/2024-02-01/games/godot4,-editor.log http://build-failures.rhaalovely.net/sparc64/2024-02-01/games/libgdx/1.9.11.log http://build-failures.rhaalovely.net/sparc64/2024-02-01/games/nblood.log http://build-failures.rhaalovely.net/sparc64/2024-02-01/games/ottomatic.log http://build-failures.rhaalovely.net/sparc64/2024-02-01/games/pioneers.log http://build-failures.rhaalovely.net/sparc64/2024-02-01/games/scid.log http://build-failures.rhaalovely.net/sparc64/2024-02-01/games/widelands.log http://build-failures.rhaalovely.net/sparc64/2024-02-01/geo/osm2pgrouting.log http://build-failures.rhaalovely.net/sparc64/2024-02-01/graphics/nomacs.log http://build-failures.rhaalovely.net/sparc64/2024-02-01/graphics/rawstudio.log http://build-failures.rhaalovely.net/sparc64/2024-02-01/graphics/ruby-rmagick,ruby33.log http://build-failures.rhaalovely.net/sparc64/2024-02-01/graphics/spirv-tools.log http://build-failures.rhaalovely.net/sparc64/2024-02-01/graphics/tesseract/tesseract.log
Re: update x11/picom to v11
El Sat, 03 Feb 2024 12:25:31 +0100
Omar Polo escribió:
> On 2024/01/24 11:07:12 +0100, Omar Polo wrote:
> > the changelog is available here:
> >
> > https://github.com/yshui/picom/releases/tag/v11-rc1
> >
> > picom now tries to set itself as real-time. I've commented out that
> > part since it uses a function we don't seem to provide
> > (sched_setscheduler), but it's not a big deal.
> >
> > However, I had again issues with the visibility of OpenGL symbols.
> > This time the 'usual' workaround didn't work. See the two diffs
> > below. It's ugly, but at least I can confirm that the glx backend
> > works for me (amdgpu if it matters.) Any help understanding this
> > is welcome :)
>
> diff updated for 11.1, still no idea regarding the
> glGetQueryObjectui64v symbol issue.
>
Update, I have successfully managed to compile and run picom-v11.1 with
the following changes. Take a look and feedback is welcome!
--
*
Dios en su cielo, todo bien en la Tierra
Index: Makefile
===
RCS file: /cvs/ports/x11/picom/Makefile,v
retrieving revision 1.11
diff -u -p -u -r1.11 Makefile
--- Makefile 24 Apr 2023 11:42:49 - 1.11
+++ Makefile 4 Feb 2024 04:35:52 -
@@ -1,19 +1,16 @@
COMMENT = lightweight compositor for X11
-GH_ACCOUNT = yshui
-GH_PROJECT = picom
-GH_TAGNAME = v10.2
-REVISION = 0
+DIST_TUPLE = github yshui picom v11.1 .
CATEGORIES = x11
# MPL 2.0
PERMIT_PACKAGE = Yes
-WANTLIB += EGL GL X11 X11-xcb c config dbus-1 ev m pcre pixman-1
-WANTLIB += xcb-composite xcb-damage xcb-glx xcb-image xcb-present
+WANTLIB += EGL GL X11 X11-xcb c config dbus-1 ev m pcre2-8 pixman-1
+WANTLIB += pthread xcb-composite xcb-damage xcb-glx xcb-image xcb-present
WANTLIB += xcb-randr xcb-render-util xcb-render xcb-shape xcb-sync
-WANTLIB += xcb-xfixes xcb-xinerama xcb
+WANTLIB += xcb-xfixes xcb-util xcb
MODULES = devel/meson
@@ -29,7 +26,7 @@ RUN_DEPENDS = x11/gtk+4,-guic \
LIB_DEPENDS = devel/libconfig \
devel/libev \
- devel/pcre \
+ devel/pcre2 \
x11/dbus
CONFIGURE_ARGS += -Dwith_docs=true \
Index: distinfo
===
RCS file: /cvs/ports/x11/picom/distinfo,v
retrieving revision 1.7
diff -u -p -u -r1.7 distinfo
--- distinfo 24 Dec 2022 16:35:26 - 1.7
+++ distinfo 4 Feb 2024 04:35:52 -
@@ -1,2 +1,2 @@
-SHA256 (picom-10.2.tar.gz) = l0FXffATbYor5IAFyiuT7cFZE1KOGbzreYU1ykaDNBw=
-SIZE (picom-10.2.tar.gz) = 287166
+SHA256 (yshui-picom-v11.1.tar.gz) = lvKjOpMGSnS1V5QtAwCirHeshT9Q77v2RmhJ/MdULsg=
+SIZE (yshui-picom-v11.1.tar.gz) = 308617
Index: patches/patch-src_backend_gl_gl_common_c
===
RCS file: patches/patch-src_backend_gl_gl_common_c
diff -N patches/patch-src_backend_gl_gl_common_c
--- /dev/null 1 Jan 1970 00:00:00 -
+++ patches/patch-src_backend_gl_gl_common_c 4 Feb 2024 04:35:52 -
@@ -0,0 +1,13 @@
+--- src/backend/gl/gl_common.c.orig Sat Feb 3 23:35:29 2024
src/backend/gl/gl_common.c Sat Feb 3 23:35:04 2024
+@@ -1186,8 +1186,8 @@ bool gl_last_render_time(backend_t *base, struct times
+ return false;
+ }
+
+- GLuint64 time;
+- glGetQueryObjectui64v(gd->frame_timing[gd->current_frame_timing ^ 1],
++ GLuint time;
++ glGetQueryObjectuiv(gd->frame_timing[gd->current_frame_timing ^ 1],
+ GL_QUERY_RESULT, );
+ ts->tv_sec = (long)(time / 10);
+ ts->tv_nsec = (long)(time % 10);
Index: patches/patch-src_picom_c
===
RCS file: patches/patch-src_picom_c
diff -N patches/patch-src_picom_c
--- /dev/null 1 Jan 1970 00:00:00 -
+++ patches/patch-src_picom_c 4 Feb 2024 04:35:52 -
@@ -0,0 +1,38 @@
+--- src/picom.c.orig Sat Feb 3 23:35:20 2024
src/picom.c Sat Feb 3 23:34:40 2024
+@@ -2550,28 +2550,30 @@ err:
+ /// Make picom realtime to reduce latency, and make rendering times more predictable to
+ /// help pacing.
+ ///
+-/// This requires the user to set up permissions for the real-time scheduling. e.g. by
+-/// setting `ulimit -r`, or giving us the CAP_SYS_NICE capability.
+ void set_rr_scheduling(void) {
+ int priority = sched_get_priority_min(SCHED_RR);
+
++ int old_policy;
+ int ret;
+ struct sched_param param;
+
+- ret = sched_getparam(0, );
++ ret = pthread_getschedparam(pthread_self(), _policy, );
+ if (ret != 0) {
+ log_debug("Failed to get old scheduling priority");
+ return;
+ }
+
+ param.sched_priority = priority;
+- ret = sched_setscheduler(0, SCHED_RR, );
++ ret = pthread_setschedparam(pthread_self(), SCHED_RR, );
+ if (ret != 0) {
+- log_info("Failed to set real-time scheduling priority to %d.", priority);
++ log_info("Failed to set real-time scheduling priority to %d. Consider "
++ "giving picom the CAP_SYS_NICE capability",
++ priority);
+ return;
+ }
+
Re: NEW: x11/emwm-utils
On Fri, 19 Jan 2024 13:17:40 -0600 izder456 wrote: > Hey ports@, > > I want to import the utils portion of EMWM, which i worked on porting > earlier this week. > > This includes a session manager for > emwm and a toolchest-like app for launching applications. > > It is packaged with example configurations as well too in lib/X11 > > the project page is here: > http://fastestcode.org/emwm.html > > Port is attached > > Comments, or OK to merge? > Following up on my x11/emwm port's thread, i version bumped it to 1.2 as 1.2 was released from upstream as of the 28th of January. I also used the upstream mirror over the github, thanks to naddy@'s recommend. It is attached Thoughts? -- -iz emwm-utils-1.2.tgz Description: application/compressed-tar
Re: NEW: games/ottomatic
On Sat, 3 Feb 2024 21:15:49 -0600 izder456 wrote: > On Sun, 28 Jan 2024 10:26:32 +0100 > "Sebastian Reitenbach" wrote: > > > Hi, > > > > On Thursday, January 25, 2024 06:02 CET, izder456 > > wrote: > > > > > Heyo ports@ nerds, > > > > > > I want to import my port of OttoMatic, which is yet another Pangea > > > Software title originally for the PPC macs. > > > > > > I have done light patchwork to allow the binary to be ran from > > > anywhere so core files can be properly dumped again. (referencing > > > Omar's patch of Nanosaur2) > > > > > > Attached is the port, OK to import? > > > > port looks good to me. However, I had to update the PLIST. Port > > re-attached. Didn't yet got to the end of Level 1, but so far it's > > quite fun ;) > > > > Anyone else? > > > > Sebastian > > > > > > > > > > -- > > > -iz > > > > > > > If something is shit and no one likes it, > > > you just put out another one the next month. > > > > > > Stu > > Following up on my x11/emwm port's thread, i version bumped it to 1.2 > as 1.2 was released from upstream as of the 28th of January. I also > used the upstream mirror over the github, thanks to naddy@'s > recommend. > > It is attached > > Thoughts? > Sorry, wrong thread. Please ignore. -- -iz
Re: NEW: x11/emwm-utils
On Fri, 19 Jan 2024 13:17:40 -0600 izder456 wrote: > Hey ports@, > > I want to import the utils portion of EMWM, which i worked on porting > earlier this week. > > This includes a session manager for > emwm and a toolchest-like app for launching applications. > > It is packaged with example configurations as well too in lib/X11 > > the project page is here: > http://fastestcode.org/emwm.html > > Port is attached > > Comments, or OK to merge? > UPDATE: following the thread on my x11/emwm port, naddy@ sent me recommends. summary of changes: use upstream mirror instead of github. upstream version-bumped a point release to 1.2, on the 28th of January. this port now targets 1.2 it is attached. thoughts? -- -iz emwm-utils-1.2.tgz Description: application/compressed-tar
Re: NEW: games/ottomatic
On Sun, 28 Jan 2024 10:26:32 +0100 "Sebastian Reitenbach" wrote: > Hi, > > On Thursday, January 25, 2024 06:02 CET, izder456 > wrote: > > > Heyo ports@ nerds, > > > > I want to import my port of OttoMatic, which is yet another Pangea > > Software title originally for the PPC macs. > > > > I have done light patchwork to allow the binary to be ran from > > anywhere so core files can be properly dumped again. (referencing > > Omar's patch of Nanosaur2) > > > > Attached is the port, OK to import? > > port looks good to me. However, I had to update the PLIST. Port > re-attached. Didn't yet got to the end of Level 1, but so far it's > quite fun ;) > > Anyone else? > > Sebastian > > > > > > -- > > -iz > > > > > If something is shit and no one likes it, > > you just put out another one the next month. > > > > Stu Following up on my x11/emwm port's thread, i version bumped it to 1.2 as 1.2 was released from upstream as of the 28th of January. I also used the upstream mirror over the github, thanks to naddy@'s recommend. It is attached Thoughts? -- -iz emwm-utils-1.2.tgz Description: application/compressed-tar
Re: NEW: x11/emwm
On Sat, 3 Feb 2024 22:14:36 +0100 Christian Weisgerber wrote: > Omar Polo: > > > Here's an updated tarball with a few more tweaks on top: > > > > - use DIST_TUPLE instead of GH_* (takes less lines :-) > > - don't need to patch the makefile; just override the variables > > using MAKE_FLAGS and FAKE_FLAGS > > - use tabs for indenting the values > > I've been wanting to look at this for months, well before the port > was submitted here, but I can never find the time, so just some > quick remarks: > > If it uses the 1.1 release anyway, it should just use the release > tarball > https://fastestcode.org/dl/emwm-src-1.1.tar.xz > instead of GitHub. > > This is advertised as an mwm fork "without changing the way the > window manager looks and behaves". Well, it _looks_ different, > even after neutering app-defaults/Emwm. What's up with that? Also, > aren't those app-defaults intended as an example, rather than actual > defaults? > > Resizing xterm is a crapshoot, because their is a size mismatch > between emwm and xterm. A default 80x24 xterm is "81x26" or some > such. This is a showstopper, IMO. I don't know whether it also > affects pixel-dimensioned windows. > > On the plus side, it interops better with Firefox in at least two > regards: > * Maximizing the Firefox window correctly maximizes it. > (With mwm its extended to twice the screen height/width.) > * The PiP window can be moved. > I also found this plays better with multiple X11 heads. On smaller screens, this isn't an issue but on larger screens IIRC, around 720p and up, the vetical/horizonal maximize and fullscreen maximize is broken. Emwm seems to also fix this. The default Xterm size is gross. that is yucky. you should check my x11/emwm-utils port too, this is probably the killer feature that this project provides IMHO. I should use the tarball from fastestcode.org, thats a good idea, thanks. It looks like upstream had a point release bump to 1.2 as of the 28th. I fixed that too. It is attached. I plan to reply to the thread for my x11/emwm-utils port with the version bumped and the above suggestions. Thoughts? -- -iz emwm-1.2.tgz Description: application/compressed-tar
Re: update x11/picom to v11
El Sat, 03 Feb 2024 12:25:31 +0100 Omar Polo escribió: > On 2024/01/24 11:07:12 +0100, Omar Polo wrote: > > the changelog is available here: > > > > https://github.com/yshui/picom/releases/tag/v11-rc1 > > > > picom now tries to set itself as real-time. I've commented out that > > part since it uses a function we don't seem to provide > > (sched_setscheduler), but it's not a big deal. > > > > However, I had again issues with the visibility of OpenGL symbols. > > This time the 'usual' workaround didn't work. See the two diffs > > below. It's ugly, but at least I can confirm that the glx backend > > works for me (amdgpu if it matters.) Any help understanding this > > is welcome :) > > diff updated for 11.1, still no idea regarding the > glGetQueryObjectui64v symbol issue. > Hi! I'm working on this too (using v11.1). Searching the issue with glGetQueryObjectui64v, I found this: nm /usr/X11R6/lib/libGL* | grep glGetQueryObjectui __indirect_glGetQueryObjectuiv fc50 T __indirect_glGetQueryObjectuiv 00061fc0 t __indirect_glGetQueryObjectuiv 0008c520 T glGetQueryObjectuiv 0008c570 T glGetQueryObjectuivARB 2fd0 T glGetQueryObjectuiv df50 T glGetQueryObjectuiv 3510 T glGetQueryObjectuiv U __indirect_glGetQueryObjectuiv d810 T __indirect_glGetQueryObjectuiv glGetQueryObjectui64v don't exist in OpenBSD GL libs ¿¿?? -- * Dios en su cielo, todo bien en la Tierra
Re: NEW: x11/emwm
Omar Polo: > Here's an updated tarball with a few more tweaks on top: > > - use DIST_TUPLE instead of GH_* (takes less lines :-) > - don't need to patch the makefile; just override the variables using >MAKE_FLAGS and FAKE_FLAGS > - use tabs for indenting the values I've been wanting to look at this for months, well before the port was submitted here, but I can never find the time, so just some quick remarks: If it uses the 1.1 release anyway, it should just use the release tarball https://fastestcode.org/dl/emwm-src-1.1.tar.xz instead of GitHub. This is advertised as an mwm fork "without changing the way the window manager looks and behaves". Well, it _looks_ different, even after neutering app-defaults/Emwm. What's up with that? Also, aren't those app-defaults intended as an example, rather than actual defaults? Resizing xterm is a crapshoot, because their is a size mismatch between emwm and xterm. A default 80x24 xterm is "81x26" or some such. This is a showstopper, IMO. I don't know whether it also affects pixel-dimensioned windows. On the plus side, it interops better with Firefox in at least two regards: * Maximizing the Firefox window correctly maximizes it. (With mwm its extended to twice the screen height/width.) * The PiP window can be moved. -- Christian "naddy" Weisgerber na...@mips.inka.de
CVS: cvs.openbsd.org: ports
CVSROOT:/cvs Module name:ports Changes by: rsadow...@cvs.openbsd.org 2024/02/03 13:52:09 Modified files: devel/quirks : Makefile devel/quirks/files: Quirks.pm Log message: Register trojita removal
CVS: cvs.openbsd.org: ports
CVSROOT:/cvs Module name:ports Changes by: rsadow...@cvs.openbsd.org 2024/02/03 13:48:20 Modified files: mail : Makefile Removed files: mail/trojita : Makefile distinfo mail/trojita/patches: patch-CMakeLists_txt patch-src_Gui_Spinner_h patch-src_Gui_Window_cpp patch-src_Imap_Network_FileDownloadManager_cpp patch-tests_Imap_test_Imap_BodyParts_cpp mail/trojita/pkg: DESCR PLIST Log message: Remove trojita Dead upstream and it still use x11/qt5/qtwebkit (insecure and also dead upstream) OK caspar@ (maintainer), solene@
CVS: cvs.openbsd.org: ports
CVSROOT:/cvs Module name:ports Changes by: rsadow...@cvs.openbsd.org 2024/02/03 13:37:47 Modified files: devel/doxygen : Makefile Added files: devel/doxygen/patches: patch-src_dirdef_cpp Log message: Re-add patch-src_dirdef_cpp (lost in an earlier update) Doxygen encodes the source directory path into some of the output filenames. This is problematic in a ports context as it means WRKDIR pathnames can appear in generated filenames.
CVS: cvs.openbsd.org: ports
CVSROOT:/cvs Module name:ports Changes by: rsadow...@cvs.openbsd.org 2024/02/03 13:35:06 Modified files: telephony/linphone/liblinphone: Makefile telephony/linphone/liblinphone/pkg: PLIST net/signond: Makefile net/signond/pkg: PLIST graphics/orthanc/server: Makefile graphics/orthanc/server/pkg: PLIST graphics/ipe : Makefile graphics/ipe/pkg: PLIST net/libaccounts-qt: Makefile net/libaccounts-qt/pkg: PLIST Log message: Regen PLIST with Doxygen 1.10.0
CVS: cvs.openbsd.org: ports
CVSROOT:/cvs Module name:ports Changes by: rsadow...@cvs.openbsd.org 2024/02/03 13:34:49 Modified files: devel/doxygen-gui: Makefile distinfo devel/doxygen : Makefile distinfo devel/doxygen/patches: patch-doc_CMakeLists_txt Log message: Update Doxygen to 1.10.0
CVS: cvs.openbsd.org: ports
CVSROOT:/cvs Module name:ports Changes by: rsadow...@cvs.openbsd.org 2024/02/03 13:13:46 Added files: math/fftw3/files: FFTW3LibraryDepends.cmake.in Log message: Add missing files/FFTW3LibraryDepends.cmake.in Forgotten in the previous commit
CVS: cvs.openbsd.org: ports
CVSROOT:/cvs Module name:ports Changes by: rsadow...@cvs.openbsd.org 2024/02/03 13:10:18 Modified files: graphics/krita : Makefile distinfo graphics/krita/pkg: PLIST Log message: Update krita to 5.2.2
CVS: cvs.openbsd.org: ports
CVSROOT:/cvs Module name:ports Changes by: rsadow...@cvs.openbsd.org 2024/02/03 13:09:07 Modified files: math/fftw3 : Makefile math/fftw3/pkg : PFRAG.double-main PFRAG.float-main Log message: fix the missing FFTW3LibraryDepends.cmake This file would normally be generated by cmake, but we are using the more feature-complete and stable autotools configure. https://github.com/FFTW/fftw3/issues/130 - Split cmake files in fftw3 and fftw3f depending on the FLAVOR. - Subst FFTW3LibraryDepends.cmake - With this approach we could introduce "--enable-long-double" (l) and "--enable-quad-precision" (q) if we need it.
CVS: cvs.openbsd.org: ports
CVSROOT:/cvs Module name:ports Changes by: rsadow...@cvs.openbsd.org 2024/02/03 12:58:37 Modified files: devel : Makefile Log message: Hook up devel/zug devel/immer devel/lager (new krita depedencies)
CVS: cvs.openbsd.org: ports
CVSROOT:/cvs Module name:ports Changes by: rsadow...@cvs.openbsd.org 2024/02/03 12:53:44 Log message: Import lager-0.1.1, tweak and ok semarie@ Comment: redux for C++ Description: ilager is a C++ library to assist value-oriented design by implementing the unidirectional data-flow architecture. It is heavily inspired by Elm and Redux, and enables composable designs by promoting the use of simple value types and testable application logic via pure functions. Maintainer: The OpenBSD ports mailing-list WWW: https://sinusoid.es/lager Status: Vendor Tag: rsadowski Release Tags: rsadowski_20240203 N ports/devel/lager/Makefile N ports/devel/lager/distinfo N ports/devel/lager/pkg/DESCR N ports/devel/lager/pkg/PLIST N ports/devel/lager/patches/patch-CMakeLists_txt No conflicts created by this import
CVS: cvs.openbsd.org: ports
CVSROOT:/cvs Module name:ports Changes by: rsadow...@cvs.openbsd.org 2024/02/03 12:52:00 Log message: Import zug-0.1.1, tweak and ok semarie@ Comment: C++ library providing transducers. Description: zug is a C++ library providing transducers. Transducers are composable sequential transformations independent of the source. They are extremely lightweight, and can be used to express algorithms over pull-based sequences (iterators, files) but also push based sequences (signals, events, asynchronous streams) in a generic way. Maintainer: The OpenBSD ports mailing-list WWW: https://sinusoid.es/zug Status: Vendor Tag: rsadowski Release Tags: rsadowski_20240203 N ports/devel/zug/Makefile N ports/devel/zug/distinfo N ports/devel/zug/pkg/DESCR N ports/devel/zug/pkg/PLIST No conflicts created by this import
CVS: cvs.openbsd.org: ports
CVSROOT:/cvs Module name:ports Changes by: rsadow...@cvs.openbsd.org 2024/02/03 12:50:53 Log message: Import immer-0.8.1, tweak and ok semarie@ Comment: immutable and persistent data structures for C++ Description: immer is a library of persistent and immutable data structures written in C++. These enable whole new kinds of architectures for interactive and concurrent programs of striking simplicity, correctness, and performance. Maintainer: The OpenBSD ports mailing-list WWW: https://sinusoid.es/immer Status: Vendor Tag: rsadowski Release Tags: rsadowski_20240203 N ports/devel/immer/Makefile N ports/devel/immer/distinfo N ports/devel/immer/pkg/DESCR N ports/devel/immer/pkg/PLIST No conflicts created by this import
NEW: games/mightymike
Hey ports@ Yes again, I am back with another pangea soft port. This concludes all of Iliyas Jorio's Pangea games. I can't wait till 7.5. Viva la iMac :) Port is attached. Comments or OK? -- -iz mightymike-3.0.2.tgz Description: Binary data
CVS: cvs.openbsd.org: ports
CVSROOT:/cvs Module name:ports Changes by: dan...@cvs.openbsd.org 2024/02/03 11:43:46 Modified files: devel/py-gitpython: Makefile distinfo Log message: update gitpython to 3.1.41
NEW: games/billyfrontier
Hey ports@ Yes again, I am back with another pangea soft port. Port is attached. Comments or OK? -- -iz billyfrontier-1.1.1.tgz Description: application/compressed-tar
CVS: cvs.openbsd.org: ports
CVSROOT:/cvs Module name:ports Changes by: o...@cvs.openbsd.org2024/02/03 11:14:34 Modified files: graphics/imlib2: Makefile distinfo Log message: graphics/imlib2: update to 1.12.2 fixes a number of loader/saver bugs.
CVS: cvs.openbsd.org: ports
CVSROOT:/cvs Module name:ports Changes by: dan...@cvs.openbsd.org 2024/02/03 11:05:15 Modified files: www/py-yarl: Makefile distinfo www/py-yarl/pkg: PLIST Log message: update py-yarl to 1.9.2 so aiohttp can be updated
Re: Remove: mail/trojita
Hi, On Fri, Feb 02, 2024 at 10:55:37PM +0100, Rafael Sadowski wrote: > Hi Caspar, Hi ports@, > > I'm trying to remove x11/qt5/qtwebkit. It's an very outdated and > unsecure web engine. Which is also dead upstream. Other distributors > have already got rid of it. Let's go the way too! > > First trojita, it looks dead upstream and no one has it in their package > catalog anymore. I hope that people will not use it to read their e-mail. > > Anyway, Caspar, ports@, are we ready to get rid of it? A bit sad but it makes sense indeed. OK caspar@ Caspar > > Rafael >
CVS: cvs.openbsd.org: ports
CVSROOT:/cvs Module name:ports Changes by: k...@cvs.openbsd.org2024/02/03 06:12:32 Modified files: security/qdigidoc4: Makefile distinfo Log message: config.json rerolled
CVS: cvs.openbsd.org: ports
CVSROOT:/cvs Module name:ports Changes by: k...@cvs.openbsd.org2024/02/03 05:39:41 Modified files: x11/remmina: Makefile distinfo x11/remmina/patches: patch-CMakeLists_txt Log message: update to remmina 1.4.33
CVS: cvs.openbsd.org: ports
CVSROOT:/cvs Module name:ports Changes by: jas...@cvs.openbsd.org 2024/02/03 05:15:05 Modified files: devel/avr32: Makefile.inc devel/avr32/binutils: Makefile devel/avr32/gcc: Makefile devel/avr32/gcc-bootstrap: Makefile devel/avr32/headers: Makefile devel/avr32/newlib: Makefile Log message: remove dead HOMEPAGE/SITES and provide a working mirror
CVS: cvs.openbsd.org: ports
CVSROOT:/cvs Module name:ports Changes by: jas...@cvs.openbsd.org 2024/02/03 05:03:18 Modified files: sysutils/smbldap-tools: Makefile Log message: homepage moved to github an interested party might want to update it though
CVS: cvs.openbsd.org: ports
CVSROOT:/cvs Module name:ports Changes by: jas...@cvs.openbsd.org 2024/02/03 04:57:24 Modified files: net/fpdns : Makefile Log message: remove defunct google code homepage and fallback to github
CVS: cvs.openbsd.org: ports
CVSROOT:/cvs Module name:ports Changes by: jas...@cvs.openbsd.org 2024/02/03 04:49:55 Modified files: infrastructure/db: network.conf Log message: replace defunct kddilabs GNU mirror with another Japanese mirror (JAIST). kddilabs has been removed from the GNU mirror list some time ago as well.
CVS: cvs.openbsd.org: ports
CVSROOT:/cvs Module name:ports Changes by: jas...@cvs.openbsd.org 2024/02/03 04:46:27 Modified files: net/uhttpmock : Makefile Log message: use HTTPS for SITES
Re: update x11/picom to v11
On 2024/01/24 11:07:12 +0100, Omar Polo wrote:
> the changelog is available here:
>
> https://github.com/yshui/picom/releases/tag/v11-rc1
>
> picom now tries to set itself as real-time. I've commented out that
> part since it uses a function we don't seem to provide
> (sched_setscheduler), but it's not a big deal.
>
> However, I had again issues with the visibility of OpenGL symbols. This
> time the 'usual' workaround didn't work. See the two diffs below. It's
> ugly, but at least I can confirm that the glx backend works for me
> (amdgpu if it matters.) Any help understanding this is welcome :)
diff updated for 11.1, still no idea regarding the glGetQueryObjectui64v
symbol issue.
Index: Makefile
===
RCS file: /home/cvs/ports/x11/picom/Makefile,v
diff -u -p -r1.11 Makefile
--- Makefile24 Apr 2023 11:42:49 - 1.11
+++ Makefile3 Feb 2024 10:36:48 -
@@ -1,19 +1,16 @@
COMMENT = lightweight compositor for X11
-GH_ACCOUNT = yshui
-GH_PROJECT = picom
-GH_TAGNAME = v10.2
-REVISION = 0
+DIST_TUPLE = github yshui picom v11.1 .
CATEGORIES = x11
# MPL 2.0
PERMIT_PACKAGE = Yes
-WANTLIB += EGL GL X11 X11-xcb c config dbus-1 ev m pcre pixman-1
-WANTLIB += xcb-composite xcb-damage xcb-glx xcb-image xcb-present
-WANTLIB += xcb-randr xcb-render-util xcb-render xcb-shape xcb-sync
-WANTLIB += xcb-xfixes xcb-xinerama xcb
+WANTLIB += EGL GL X11 X11-xcb c config dbus-1 ev m pcre2-8 pixman-1
+WANTLIB += pthread xcb xcb-composite xcb-damage xcb-dpms xcb-glx
+WANTLIB += xcb-image xcb-present xcb-randr xcb-render xcb-render-util
+WANTLIB += xcb-shape xcb-sync xcb-xfixes
MODULES = devel/meson
@@ -29,7 +26,7 @@ RUN_DEPENDS = x11/gtk+4,-guic \
LIB_DEPENDS = devel/libconfig \
devel/libev \
- devel/pcre \
+ devel/pcre2 \
x11/dbus
CONFIGURE_ARGS += -Dwith_docs=true \
Index: distinfo
===
RCS file: /home/cvs/ports/x11/picom/distinfo,v
diff -u -p -r1.7 distinfo
--- distinfo24 Dec 2022 16:35:26 - 1.7
+++ distinfo3 Feb 2024 10:36:53 -
@@ -1,2 +1,2 @@
-SHA256 (picom-10.2.tar.gz) = l0FXffATbYor5IAFyiuT7cFZE1KOGbzreYU1ykaDNBw=
-SIZE (picom-10.2.tar.gz) = 287166
+SHA256 (yshui-picom-v11.1.tar.gz) =
lvKjOpMGSnS1V5QtAwCirHeshT9Q77v2RmhJ/MdULsg=
+SIZE (yshui-picom-v11.1.tar.gz) = 308617
Index: patches/patch-src_backend_gl_egl_c
===
RCS file: patches/patch-src_backend_gl_egl_c
diff -N patches/patch-src_backend_gl_egl_c
--- /dev/null 1 Jan 1970 00:00:00 -
+++ patches/patch-src_backend_gl_egl_c 24 Jan 2024 09:51:34 -
@@ -0,0 +1,27 @@
+ugly ugly ugly workaround
+
+Index: src/backend/gl/egl.c
+--- src/backend/gl/egl.c.orig
src/backend/gl/egl.c
+@@ -37,6 +37,7 @@ struct egl_data {
+ };
+
+ static PFNGLEGLIMAGETARGETTEXSTORAGEEXTPROC glEGLImageTargetTexStorage = NULL;
++PFNGLGETQUERYOBJECTUI64VEXTPROC glEGLGetQueryObjectui64v = NULL;
+ static PFNEGLCREATEIMAGEKHRPROC eglCreateImageProc = NULL;
+ static PFNEGLDESTROYIMAGEKHRPROC eglDestroyImageProc = NULL;
+ static PFNEGLGETPLATFORMDISPLAYPROC eglGetPlatformDisplayProc = NULL;
+@@ -248,6 +249,13 @@ static backend_t *egl_init(session_t *ps, xcb_window_t
+
"torageEXT");
+ if (glEGLImageTargetTexStorage == NULL) {
+ log_error("Failed to get glEGLImageTargetTexStorageEXT.");
++ goto end;
++ }
++
++ glEGLGetQueryObjectui64v =
++
(PFNGLGETQUERYOBJECTUI64VPROC)eglGetProcAddress("glGetQueryObjectui64vEXT");
++ if (glGetQueryObjectui64v == NULL) {
++ log_error("Failed to get glGetQueryObjectui64vEXT.");
+ goto end;
+ }
+
Index: patches/patch-src_backend_gl_gl_common_c
===
RCS file: patches/patch-src_backend_gl_gl_common_c
diff -N patches/patch-src_backend_gl_gl_common_c
--- /dev/null 1 Jan 1970 00:00:00 -
+++ patches/patch-src_backend_gl_gl_common_c24 Jan 2024 09:51:29 -
@@ -0,0 +1,23 @@
+ugly ugly ugly workaround
+
+Index: src/backend/gl/gl_common.c
+--- src/backend/gl/gl_common.c.orig
src/backend/gl/gl_common.c
+@@ -22,6 +22,8 @@
+ #include "backend/backend_common.h"
+ #include "backend/gl/gl_common.h"
+
++extern PFNGLGETQUERYOBJECTUI64VEXTPROC glEGLGetQueryObjectui64v;
++
+ void gl_prepare(backend_t *base, const region_t *reg attr_unused) {
+ auto gd = (struct gl_data *)base;
+ glBeginQuery(GL_TIME_ELAPSED,
gd->frame_timing[gd->current_frame_timing]);
+@@ -1187,7 +1189,7 @@ bool gl_last_render_time(backend_t *base, struct times
+ }
+
+ GLuint64 time;
+-
CVS: cvs.openbsd.org: ports
CVSROOT:/cvs Module name:ports Changes by: t...@cvs.openbsd.org2024/02/03 04:03:15 Modified files: security/py-openssl: Makefile Log message: py-openssl: fix comment: shutdown test is no longer disabled
Re: NEW: wayland/wmenu
On Sat, Jan 27, 2024 at 10:09:50PM +0100, Matthieu Herrb wrote: > Hi, > > wmenu is a dynamic menu for sway and other wlroot based Wayland > compositors. > Starting with sway 1.9 it will be the default menu in the sway > configuration. > > I've added a basic shell script to list available programs (upstream > uses dmenu_path from x11/dmenu, but I wanted to avoid the dependency) > > Comments? ok? > > -- > Matthieu Herrb Ping ? -- Matthieu Herrb
Re: [UPDATE] devel/msgpack-6.0.0
(added neovim/neovim-qt maintainer)
Hi,
> It will need doing sometime. It's probably easier to do it sooner rather
> than later before more other ports start using it.
>
> These ports will need changes to adapt:
>
> editors/neovim
> editors/neovim-qt
> sysutils/tmate
well, here is (simply fixed version that you pointed out in previous mail)
new msgpack 5 -> 6 diff and neovim/neovim-qt/tmate diff.
devel/msgpack
Index: Makefile
===
RCS file: /cvs/ports/devel/msgpack/Makefile,v
diff -u -p -r1.18 Makefile
--- Makefile21 Sep 2023 09:50:01 - 1.18
+++ Makefile3 Feb 2024 06:57:19 -
@@ -1,10 +1,10 @@
COMMENT = MessagePack implementation for C and C++
-V =5.0.0
+V =6.0.0
DISTNAME = msgpack-c-${V}
PKGNAME = msgpack-${V}
-SHARED_LIBS += msgpackc 2.0 # 2.0
+SHARED_LIBS += msgpack-c 0.0 # 2.0
CATEGORIES = devel
@@ -21,7 +21,7 @@ BUILD_DEPENDS = devel/gtest>=1.11.0pl20
TEST_DEPENDS = devel/gtest>=1.11.0pl20220208
# evertyhing except tests
-ALL_TARGET = msgpackc msgpackc-static
+ALL_TARGET = msgpack-c msgpack-c-static
# build whatever is left (ca. 22 C++ test files)
pre-test:
Index: distinfo
===
RCS file: /cvs/ports/devel/msgpack/distinfo,v
diff -u -p -r1.6 distinfo
--- distinfo2 Sep 2023 11:10:13 - 1.6
+++ distinfo3 Feb 2024 06:57:19 -
@@ -1,2 +1,2 @@
-SHA256 (msgpack-c-5.0.0.tar.gz) = 62138y26qukXTZbKz+Aq8wvx6jKcRQGAdM2VrG5vpuU=
-SIZE (msgpack-c-5.0.0.tar.gz) = 69275
+SHA256 (msgpack-c-6.0.0.tar.gz) = NlT14sZS3FLgqZPicLtX1XArJicD8DdxwVK7pRYCrro=
+SIZE (msgpack-c-6.0.0.tar.gz) = 69341
Index: pkg/PLIST
===
RCS file: /cvs/ports/devel/msgpack/pkg/PLIST,v
diff -u -p -r1.6 PLIST
--- pkg/PLIST 2 Sep 2023 11:10:13 - 1.6
+++ pkg/PLIST 3 Feb 2024 06:57:19 -
@@ -19,11 +19,11 @@ include/msgpack/vrefbuffer.h
include/msgpack/zbuffer.h
include/msgpack/zone.h
lib/cmake/
-lib/cmake/msgpackc/
-lib/cmake/msgpackc/msgpackc-config-version.cmake
-lib/cmake/msgpackc/msgpackc-config.cmake
-lib/cmake/msgpackc/msgpackc-targets${MODCMAKE_BUILD_SUFFIX}
-lib/cmake/msgpackc/msgpackc-targets.cmake
-@static-lib lib/libmsgpackc.a
-@lib lib/libmsgpackc.so.${LIBmsgpackc_VERSION}
-lib/pkgconfig/msgpack.pc
+lib/cmake/msgpack-c/
+lib/cmake/msgpack-c/msgpack-c-config-version.cmake
+lib/cmake/msgpack-c/msgpack-c-config.cmake
+lib/cmake/msgpack-c/msgpack-c-targets${MODCMAKE_BUILD_SUFFIX}
+lib/cmake/msgpack-c/msgpack-c-targets.cmake
+@static-lib lib/libmsgpack-c.a
+@lib lib/libmsgpack-c.so.${LIBmsgpack-c_VERSION}
+lib/pkgconfig/msgpack-c.pc
editors/neovim
Index: Makefile
===
RCS file: /cvs/ports/editors/neovim/Makefile,v
diff -u -p -r1.42 Makefile
--- Makefile17 Jan 2024 14:17:59 - 1.42
+++ Makefile3 Feb 2024 07:16:28 -
@@ -17,6 +17,7 @@ DIST_TUPLE = github neovim neovim v0.9.5
USE_NOBTCFI = Yes
CATEGORIES = editors devel
+REVISION = 0
HOMEPAGE = https://neovim.io
MAINTAINER = Edd Barrett
@@ -40,7 +41,7 @@ PERMIT_PACKAGE = Yes
DEBUG_PACKAGES = ${BUILD_PACKAGES}
-WANTLIB += c iconv intl m msgpackc pthread termkey
+WANTLIB += c iconv intl m msgpack-c pthread termkey
WANTLIB += tree-sitter unibilium util uv vterm
.if ${EMBED_LUAJIT} != "Yes"
editors/neovim-qt
Index: Makefile
===
RCS file: /cvs/ports/editors/neovim-qt/Makefile,v
diff -u -p -r1.9 Makefile
--- Makefile14 Dec 2023 12:20:32 - 1.9
+++ Makefile3 Feb 2024 07:48:42 -
@@ -3,6 +3,7 @@ COMMENT = Qt5 GUI front-end for neovim
GH_ACCOUNT = equalsraf
GH_PROJECT = neovim-qt
GH_TAGNAME = v0.2.18
+REVISION = 0
CATEGORIES = editors
@@ -14,7 +15,7 @@ MAINTAINER = Laurence Tratt https://github.com/tmate-io/tmate/commit/
PATCHFILES.p =
tmate-bad-fingerprint{cbec43f56dfb48c2fb6e00faa2cb85443d4b7d8f}.patch \
@@ -18,7 +18,7 @@ PERMIT_PACKAGE = Yes
# uses pledge()
-WANTLIB = c curses event_core event_extra execinfo msgpackc ssh util
+WANTLIB = c curses event_core event_extra execinfo msgpack-c ssh util
LIB_DEPENDS = devel/libevent2 \
devel/msgpack \
Index: patches/patch-configure-ac
===
RCS file: patches/patch-configure-ac
diff -N patches/patch-configure-ac
--- /dev/null 1 Jan 1970 00:00:00 -
+++ patches/patch-configure-ac 3 Feb 2024 09:29:58 -
@@ -0,0 +1,20 @@
+--- configure.ac.orig Sun Nov 17 07:09:38 2019
configure.ac Sat Feb 3 15:47:48 2024
+@@ -201,7 +201,7 @@ fi
+
+ PKG_CHECK_MODULES(
+ MSGPACK,
+- msgpack >=
CVS: cvs.openbsd.org: ports
CVSROOT:/cvs Module name:ports Changes by: sema...@cvs.openbsd.org 2024/02/03 01:18:44 Modified files: lang/zig : Makefile lang/zig/patches: patch-lib_std_debug_zig patch-lib_std_os_zig Log message: lang/zig: unbreak the build msync() might return EPERM now. https://github.com/ziglang/zig/pull/18701
CVS: cvs.openbsd.org: ports
CVSROOT:/cvs Module name:ports Changes by: k...@cvs.openbsd.org2024/02/03 01:06:25 Modified files: security/clamav: Makefile Log message: Mark BROKEN-sparc64 This hasn't built in some time because the rust part doesn't build. The memory safe language part dies with a SIGSEGV
