Re: UPDATE: libsamplerate
On May 03 20:03:43, h...@stare.cz wrote:
> > > > > > > On Apr 26 20:46:51, b...@comstyle.com wrote:
> > > > > > > > Implement SSE2 lrint() and lrintf() on amd64.
> > > > > > >
> > > > > > > I don't think this is worth the added complexity:
> > > > > > > seven more patches to have a different lrint()?
> > > > > > > Does it make the resampling noticably better/faster?
BTW, this is what libm/arch/amd64/s_lrint.S says:
ENTRY(lrint)
RETGUARD_SETUP(lrint, r11)
cvtsd2si %xmm0, %rax
RETGUARD_CHECK(lrint, r11)
ret
END(lrint)
So isn't that already used anyway?
If so, what's the point of replacing lrint
with _mm_cvtsd_si32(_mm_load_sd(&x)) ?
Jan
> > > > https://github.com/libsndfile/libsndfile/pull/663
> > > > -> https://quick-bench.com/q/OabKT-gEOZ8CYDriy1JEwq1lEsg
> > > > where there's a huge difference in clang builds.
> > >
> > > Sorry, I don't understand at all how this concerns
> > > the OpenBSD port of libsamplerate: the Benchmark does not
> > > mention an OS or an architecture, so what is this being run on?
> > >
> > > Anyway, just running it (Run Benchmark) gives the result
> > > of cpu_time of 722.537 for BM_d2les_array (using lrint)
> > > and cpu_time of 0 for BM_d2les_array_sse2 (using psf_lrint),
> > > reporting a speedup ratio of 200,000,000.
> > >
> > > That's not an example of what I have in mind: a simple application
> > > of libsamplerate, sped up by the usage of the new SSE2 lrint
>
> > OK, here is a test that's a modified version of what Stuart linked,
> > testing the performance of the lrint() itself (code below).
>
> A better test below, lrint()ing a random sequence.
> The SSE version is slower on every SSE2 machine I tried.
> Is that the case for you too?
>
> Jan
>
>
> #include
> #include
>
> static inline int
> psf_lrint(double const x)
> {
> return _mm_cvtsd_si32(_mm_load_sd(&x));
> }
>
> static void
> d2l(const double *src, long *dst, size_t len)
> {
> for (size_t i = 0; i < len; i++)
> dst[i] = lrint(src[i]);
> }
>
> static void
> d2l_sse(const double *src, long *dst, size_t len)
> {
> for (size_t i = 0; i < len; i++)
> dst[i] = psf_lrint(src[i]);
> }
>
> int
> main()
> {
> size_t i, len = 1000 * 1000 * 100;
> double *src = NULL;
> long *dst = NULL;
>
> src = calloc(len, sizeof(double));
> dst = calloc(len, sizeof(long));
>
> arc4random_buf(src, len * sizeof(double));
> d2l_sse(src, dst, len);
> /*d2l(src, dst, len);*/
>
> return 0;
> }
Re: NEW: autoconf 2.72
ping. On 2024-04-26 10:14 p.m., Brad Smith wrote: Here is a port for GNU autoconf 2.72. https://lists.gnu.org/archive/html/autotools-announce/2023-12/msg3.html
Re: UPDATE: OpenSubdiv 3.6.0
ping.
On 2024-04-18 6:03 p.m., Brad Smith wrote:
Here is an update to OpenSubdiv 3.6.0.
Release 3.6.0 - Sep 2023
==
Release 3.6.0 is a significant release with new features, several
configuration improvements, and bug fixes.
For more information on the following, see `Release 3.6 `__
**Changes**
- Updated Osd patch drawing shader source to exclude legacy shader
constructs to improve compatibility with Vulkan, DX12, etc. (GitHub #1320)
- Installed Osd patch evaluation headers to allow use from client shaders
and compute kernels (GitHub #1321)
- Updated CMake build to locate TBB using TBB's CMake config in order to
support oneTBB (GitHub #1319)
- Updated CMake FindOpenCL module to support parsing version information
from recent OpenCL headers (GitHub #1322)
- Removed obsolete .travis.yml (GitHub #1324)
**Bug Fixes**
- Fixed inconsistent warning levels for MSVC builds when using Ninja
(GitHub #1318)
- Fixed documentation build errors when using Ninja (GitHub #1323)
- Fixed build errors resulting from oneTBB API changes (GitHub #1317)
Index: Makefile
===
RCS file: /cvs/ports/graphics/opensubdiv/Makefile,v
retrieving revision 1.7
diff -u -p -u -p -r1.7 Makefile
--- Makefile20 Oct 2023 13:07:59 - 1.7
+++ Makefile18 Apr 2024 20:55:12 -
@@ -1,14 +1,13 @@
COMMENT= open-source subdivision surface library
-V= 3.5.0
+V= 3.6.0
GH_ACCOUNT= PixarAnimationStudios
GH_PROJECT= OpenSubdiv
GH_TAGNAME= v${V:S/./_/g}
DISTNAME= ${GH_PROJECT:L}-${V}
-REVISION= 0
-SHARED_LIBS += osdCPU 2.0 # 3.4.4
-SHARED_LIBS += osdGPU 2.0 # 3.4.4
+SHARED_LIBS += osdCPU 3.0 # 3.4.4
+SHARED_LIBS += osdGPU 3.0 # 3.4.4
CATEGORIES= graphics
@@ -30,8 +29,14 @@ BUILD_DEPENDS= graphics/glfw
LIB_DEPENDS= devel/tbb
-CONFIGURE_ARGS= -DNO_DOC=ON \
- -DNO_OMP=ON
+CONFIGURE_ARGS=-DNO_CLEW=ON \
+ -DNO_CUDA=ON \
+ -DNO_DOC=ON \
+ -DNO_OMP=ON \
+ -DNO_OPENCL=ON \
+ -DNO_PTEX=ON
+
+CXXFLAGS+= -I${X11BASE}/include
post-install:
rm -rf ${PREFIX}/bin/tutorials
Index: distinfo
===
RCS file: /cvs/ports/graphics/opensubdiv/distinfo,v
retrieving revision 1.3
diff -u -p -u -p -r1.3 distinfo
--- distinfo10 May 2023 08:48:59 - 1.3
+++ distinfo18 Apr 2024 20:55:12 -
@@ -1,2 +1,2 @@
-SHA256 (opensubdiv-3.5.0.tar.gz) = j1BE9FO5QWJ1UTH3fAgGkATyUwb9bcIZK21JiJ77gJU=
-SIZE (opensubdiv-3.5.0.tar.gz) = 40740801
+SHA256 (opensubdiv-3.6.0.tar.gz) = vr/WGrZlek9P8nhF+2ahZ9ADlXg7+9JTJU2HRH7R2Hk=
+SIZE (opensubdiv-3.6.0.tar.gz) = 40746688
Index: patches/patch-opensubdiv_osd_tbbEvaluator_cpp
===
RCS file: patches/patch-opensubdiv_osd_tbbEvaluator_cpp
diff -N patches/patch-opensubdiv_osd_tbbEvaluator_cpp
--- patches/patch-opensubdiv_osd_tbbEvaluator_cpp 11 Jun 2023 07:47:12
- 1.1
+++ /dev/null 1 Jan 1970 00:00:00 -
@@ -1,31 +0,0 @@
-Support oneTBB 2021
-
-Index: opensubdiv/osd/tbbEvaluator.cpp
opensubdiv/osd/tbbEvaluator.cpp.orig
-+++ opensubdiv/osd/tbbEvaluator.cpp
-@@ -25,7 +25,8 @@
- #include "../osd/tbbEvaluator.h"
- #include "../osd/tbbKernel.h"
-
--#include
-+#define TBB_PREVIEW_GLOBAL_CONTROL true
-+#include
-
- namespace OpenSubdiv {
- namespace OPENSUBDIV_VERSION {
-@@ -215,10 +216,11 @@ TbbEvaluator::Synchronize(void *) {
- /* static */
- void
- TbbEvaluator::SetNumThreads(int numThreads) {
--if (numThreads == -1) {
--tbb::task_scheduler_init init;
--} else {
--tbb::task_scheduler_init init(numThreads);
-+if (numThreads != -1) {
-+ tbb::global_control tbb_global_control(
-+ tbb::global_control::max_allowed_parallelism,
-+ numThreads
-+ );
- }
- }
-
Index: pkg/PLIST
===
RCS file: /cvs/ports/graphics/opensubdiv/pkg/PLIST,v
retrieving revision 1.3
diff -u -p -u -p -r1.3 PLIST
--- pkg/PLIST 10 May 2023 08:48:59 - 1.3
+++ pkg/PLIST 18 Apr 2024 20:55:12 -
@@ -62,8 +62,8 @@ include/opensubdiv/osd/glslPatchShaderSo
include/opensubdiv/osd/mesh.h
include/opensubdiv/osd/nonCopyable.h
include/opensubdiv/osd/opengl.h
-include/opensubdiv/osd/tbbEvaluator.h
-include/opensubdiv/osd/tbbKernel.h
+include/opensubdiv/osd/patchBasis.h
+include/opensubdiv/osd/patchBasisTypes.h
include/opensubdiv/osd/types.h
include/opensubdiv/sdc/
include/opensubdiv/sdc/bilinearScheme.h
Re: [update] editors/vis 0.8 -> 0.9
2024-05-03T19:06:51Z James Cook : > As far as I can tell, the problem is that SHELL is /sbin/nologin > for user _pbuild. (I have PORTS_PRIVSEP=Yes in /etc/mk.conf.) Hmm weird, I also use PORTS_PRIVSEP and had no issues with the tests. I'll have to take another look at it this weekend. I'll send a revision anyways because I missed that we can probably drop the post-extract rule by specifying the subdir with DIST_TUPLE.
Re: [update] editors/vis 0.8 -> 0.9
On Fri, May 03, 2024 at 07:06:45PM GMT, James Cook wrote: > On Fri, May 03, 2024 at 12:26:15PM GMT, Johannes Thyssen Tishman wrote: > > Please find below an update for editors/vis to version 0.9. The tests > > (which are hosted separately) didn't seem to get an update, but they all > > still pass. > > > > Cc'd maintainer. > > Thank you, this seems to work so far, but "make test" fails for me. > > As far as I can tell, the problem is that SHELL is /sbin/nologin > for user _pbuild. (I have PORTS_PRIVSEP=Yes in /etc/mk.conf.) > For example, the following command causes vis to correctly capitalize > the test file's content; without SHELL=/bin/sh the vis status bar > shows "Command failed" and the text in the file is not capitalized: > > doas -u _pbuild sh -c 'SHELL=/bin/sh VIS_PATH=. ../../vis > commands/filter-capitalize.in' Oops, forgot to specify that I'm running that in the directory vis-0.9/vis-0.9/test/sam under my pobj directory. -- James
Re: [update] editors/vis 0.8 -> 0.9
On Fri, May 03, 2024 at 12:26:15PM GMT, Johannes Thyssen Tishman wrote: > Please find below an update for editors/vis to version 0.9. The tests > (which are hosted separately) didn't seem to get an update, but they all > still pass. > > Cc'd maintainer. Thank you, this seems to work so far, but "make test" fails for me. As far as I can tell, the problem is that SHELL is /sbin/nologin for user _pbuild. (I have PORTS_PRIVSEP=Yes in /etc/mk.conf.) For example, the following command causes vis to correctly capitalize the test file's content; without SHELL=/bin/sh the vis status bar shows "Command failed" and the text in the file is not capitalized: doas -u _pbuild sh -c 'SHELL=/bin/sh VIS_PATH=. ../../vis commands/filter-capitalize.in' I pasted the end of the output of "make test" below my signature. -- James gmake[2]: Entering directory '/home/pobj/vis-0.9/vis-0.9/test/sam' /usr/local/plan9/bin/sam vis 0.9 +curses +lua +tre Running test ./addresses/columns with sam ... OK Running test ./addresses/columns with vis ... OK Running test ./addresses/first-last with sam ... OK Running test ./addresses/first-last with vis ... OK Running test ./addresses/lines with sam ... OK Running test ./addresses/lines with vis ... OK Running test ./addresses/second with sam ... OK Running test ./addresses/second with vis ... OK Running test ./commands/filter-capitalize with sam ... OK Running test ./commands/filter-capitalize with vis ... FAIL Running test ./commands/group with sam ... OK Running test ./commands/group with vis ... OK Running test ./commands/long-text with sam ... OK Running test ./commands/long-text with vis ... OK Running test ./commands/loop-lines1 with sam ... OK Running test ./commands/loop-lines1 with vis ... OK Running test ./commands/loop-lines2 with sam ... OK Running test ./commands/loop-lines2 with vis ... OK Running test ./commands/loop-lines3 with sam ... OK Running test ./commands/loop-lines3 with vis ... OK Running test ./commands/loop-lines4 with sam ... OK Running test ./commands/loop-lines4 with vis ... OK Running test ./commands/loop-lines5 with sam ... OK Running test ./commands/loop-lines5 with vis ... OK Running test ./commands/loop-lines6 with sam ... OK Running test ./commands/loop-lines6 with vis ... OK Running test ./commands/loop-lines7 with sam ... OK Running test ./commands/loop-lines7 with vis ... OK Running test ./commands/loop-lines8 with sam ... OK Running test ./commands/loop-lines8 with vis ... OK Running test ./commands/loop-lines9 with sam ... OK Running test ./commands/loop-lines9 with vis ... OK Running test ./commands/pipe-in with sam ... OK Running test ./commands/pipe-in with vis ... FAIL Running test ./commands/pipe-out with sam ... OK Running test ./commands/pipe-out with vis ... FAIL Running test ./commands/repeated-shell with sam ... OK Running test ./commands/repeated-shell with vis ... FAIL Running test ./commands/unicode-replace with sam ... OK Running test ./commands/unicode-replace with vis ... OK Running test ./errors/conflict with sam ... OK Running test ./errors/conflict with vis ... OK Running test ./errors/read with sam ... OK Running test ./errors/read with vis ... OK Running test ./errors/unbalanced-group with sam ... OK Running test ./errors/unbalanced-group with vis ... OK Running test ./examples/comment-functions with sam ... OK Running test ./examples/comment-functions with vis ... OK Running test ./examples/delete-empty-lines with sam ... OK Running test ./examples/delete-empty-lines with vis ... OK Running test ./examples/swap-words with sam ... OK Running test ./examples/swap-words with vis ... OK Tests ok 22/26 gmake[2]: *** [Makefile:2: test] Error 1 gmake[2]: Leaving directory '/home/pobj/vis-0.9/vis-0.9/test/sam' gmake[1]: *** [Makefile:5: test] Error 2 gmake[1]: Leaving directory '/home/pobj/vis-0.9/vis-0.9/test' gmake: *** [Makefile:156: test] Error 2 *** Error 2 in . (/usr/ports/infrastructure/mk/bsd.port.mk:3096 '/home/pobj/vis-0.9/.test_done': @cd /home/pobj/vis-0.9/vis-0.9 && exec 3>&1...) *** Error 2 in /usr/ports/editors/vis (/usr/ports/infrastructure/mk/bsd.port.mk:2704 'test': @lock=vis-0.9; export _LOCKS_HELD=" vis-0.9"; ...)
Re: update games/hyperrogue
On Fri, May 03, 2024 at 06:44:56PM +0200, Solene Rapenne wrote:
> On Thu, May 02, 2024 at 01:07:08PM GMT, Thomas Frohwein wrote:
> > On Fri, Apr 19, 2024 at 10:27:49PM +0200, Solene Rapenne wrote:
> > > our hyperrogue version is quite old of a dozen releases
> > >
> > > latest release adds a lot of changes
> > > https://github.com/zenorogue/hyperrogue/releases
> > >
> > > the Makefile patch had to be reworked a bit because the original
> > > Makefile differed from the patch, but it applies the same changes
> > > as before.
> > >
> > > update-plist removed some honeycomb files, I don't know if it's
> > > expected... the game plays fine
> >
> > Built it and it works as expected.
> >
> > Noticed that it save hyperrogue.log in $PWD which I find annoying, not
> > sure if that's how upstream designed it. It would make more sense to
> > have a location in the home directory for that. Might be worth checking
> > on, but either way this update is ok thfr@, provided Brian is okay with
> > it or timeout...
>
>
> it also saves settings in $PWD...This can be solved by compiling
> with -DFHS to have the files saved in $HOME/
>
> Not sure if the place I've put it into CXXFLAGS variable is ok?
>
> you can try quickly in game: open settings menu and choose "save"
Making this part of CXXFLAGS looks correct to me. With this, I can now
hear music (I don't think that was there before). The save/log file is
now at ~/.hyperrogue.log. I don't know where the settings
(hyperrogue.ini) are supposed to be; I can't find the file. And after
closing the game, it seems that my settings are set back to the
default.
I've looked if there is more documentation for -DFHS, but it's quite
obscure. It seems to be set by many of the linux build pathways. It's
also in sound.cpp and util.cpp, where it seems to make it look for
files in /usr/share/hyperrogue which of course doesn't exist in our
port and should be /usr/local/share/hyperrogue/...
>
> diff --git a/games/hyperrogue/Makefile b/games/hyperrogue/Makefile
> index 4c1a7417f10..3b211a563a9 100644
> --- a/games/hyperrogue/Makefile
> +++ b/games/hyperrogue/Makefile
> @@ -1,4 +1,4 @@
> -V = 12.0f
> +V = 13.0d
> COMMENT =roguelike game in a non-Euclidean world
> CATEGORIES = games x11
>
> @@ -24,7 +24,7 @@ LIB_DEPENDS = devel/sdl-gfx \
> graphics/glew \
> graphics/png
>
> -CXXFLAGS += -I${LOCALBASE}/include -I${X11BASE}/include \
> +CXXFLAGS += -I${LOCALBASE}/include -I${X11BASE}/include -DFHS\
> -DHYPERPATH="\\\"${LOCALBASE}/share/hyperrogue/\\\""
> LDFLAGS += -L${LOCALBASE}/lib -L${X11BASE}/lib
>
> diff --git a/games/hyperrogue/distinfo b/games/hyperrogue/distinfo
> index 835425d2f49..fe08e61d88c 100644
> --- a/games/hyperrogue/distinfo
> +++ b/games/hyperrogue/distinfo
> @@ -1,2 +1,2 @@
> -SHA256 (hyperrogue-12.0f.tar.gz) =
> ROeOk+0dMZg9680EeR1//Pz73EBpfnCaD2yi04wwID4=
> -SIZE (hyperrogue-12.0f.tar.gz) = 79946099
> +SHA256 (hyperrogue-13.0d.tar.gz) =
> 4ApHLRReh9u3dzH+FXCHyB2N5b0rBfogkbyQGFMIDoo=
> +SIZE (hyperrogue-13.0d.tar.gz) = 87765129
> diff --git a/games/hyperrogue/patches/patch-Makefile
> b/games/hyperrogue/patches/patch-Makefile
> index 1567a49854b..6d4afc867d8 100644
> --- a/games/hyperrogue/patches/patch-Makefile
> +++ b/games/hyperrogue/patches/patch-Makefile
> @@ -26,9 +26,9 @@ Index: Makefile
>
> -ifeq (${TOOLCHAIN},clang)
> - CXXFLAGS_STD = -std=c++11
> -- CXXFLAGS_EARLY += -march=native -fPIC
> -- CXXFLAGS_EARLY += -W -Wall -Wextra -Wsuggest-override -Werror -pedantic
> -- CXXFLAGS_EARLY += -Wno-unused-parameter -Wno-implicit-fallthrough
> -Wno-maybe-uninitialized -Wno-unknown-warning-option
> +- CXXFLAGS_EARLY += -fPIC
> +- CXXFLAGS_EARLY += -W -Wall -Wextra -Wsuggest-override -pedantic
> +- CXXFLAGS_EARLY += -Wno-unused-parameter -Wno-implicit-fallthrough
> -Wno-maybe-uninitialized -Wno-char-subscripts -Wno-unknown-warning-option
> - CXXFLAGS_EARLY += -Wno-invalid-offsetof
> -endif
> +CXXFLAGS_STD = -std=c++11
> @@ -39,23 +39,23 @@ Index: Makefile
>
> -ifeq (${TOOLCHAIN},gcc)
> - CXXFLAGS_STD = -std=c++11
> -- CXXFLAGS_EARLY += -march=native -fPIC
> -- CXXFLAGS_EARLY += -W -Wall -Wextra -Werror -pedantic
> +- CXXFLAGS_EARLY += -fPIC
> +- CXXFLAGS_EARLY += -W -Wall -Wextra -pedantic
> - CXXFLAGS_EARLY += -Wno-unused-parameter -Wno-implicit-fallthrough
> -Wno-maybe-uninitialized
> +- CXXFLAGS_EARLY += -Wno-invalid-offsetof
> -endif
> -
> -ifeq (${TOOLCHAIN},mingw)
> - CXXFLAGS_STD = -std=c++11
> -- CXXFLAGS_EARLY += -march=native
> -- CXXFLAGS_EARLY += -W -Wall -Wextra -Werror
> +- CXXFLAGS_EARLY += -W -Wall -Wextra
> - CXXFLAGS_EARLY += -Wno-unused-parameter -Wno-implicit-fallthrough
> -Wno-maybe-uninitialized
> +- CXXFLAGS_EARLY += -Wno-invalid-offsetof
> -endif
> -
> --
> - ## We have now finished OS-specific and TOOLCHAIN-specific computations.
> - ## Begin customization points for user-specifiable HYPERROGUE_USE_XXX
> m
Update: devel/sdl2 to latest release 2.30.3
Hi,
This diff catches up to the latest release of SDL, 2.30.3. No dynamic
export changes from our current version in ports (2.30.0). The release
notes (see [1]) show 2.30.1-2.30.3 are stable bugfix releases that also
add support for a few more game controllers.
I built and ran a handful of consumers without any breakage. Planning
to commit this in the next days if no concerns/issues, but feel free to
test!
[1] https://github.com/libsdl-org/SDL/releases
Index: Makefile
===
RCS file: /cvs/ports/devel/sdl2/Makefile,v
retrieving revision 1.57
diff -u -p -r1.57 Makefile
--- Makefile24 Feb 2024 17:34:36 - 1.57
+++ Makefile3 May 2024 18:04:32 -
@@ -1,9 +1,8 @@
COMMENT= cross-platform multimedia library
-V= 2.30.0
+V= 2.30.3
DISTNAME= SDL2-${V}
PKGNAME= sdl2-${V}
-REVISION= 1
CATEGORIES=devel
SITES= https://www.libsdl.org/release/
Index: distinfo
===
RCS file: /cvs/ports/devel/sdl2/distinfo,v
retrieving revision 1.23
diff -u -p -r1.23 distinfo
--- distinfo23 Feb 2024 20:33:55 - 1.23
+++ distinfo3 May 2024 18:04:32 -
@@ -1,2 +1,2 @@
-SHA256 (SDL2-2.30.0.tar.gz) = NuLkFVfg+koVGTFcD1lYqHzLJ+JcUXdr628SOVJkR7A=
-SIZE (SDL2-2.30.0.tar.gz) = 7428037
+SHA256 (SDL2-2.30.3.tar.gz) = ggRABy+PW1AYjB2uEE8q0lmE3iaHhb5AxBoJmlEPCuw=
+SIZE (SDL2-2.30.3.tar.gz) = 7425677
Index: patches/patch-configure
===
RCS file: /cvs/ports/devel/sdl2/patches/patch-configure,v
retrieving revision 1.2
diff -u -p -r1.2 patch-configure
--- patches/patch-configure 23 Feb 2024 20:33:55 - 1.2
+++ patches/patch-configure 3 May 2024 18:04:32 -
@@ -2,7 +2,7 @@ prevent from using linux/input.h if pres
Index: configure
--- configure.orig
+++ configure
-@@ -26476,7 +26476,7 @@ main (void)
+@@ -26412,7 +26412,7 @@ main (void)
_ACEOF
if ac_fn_c_try_compile "$LINENO"
then :
Index: patches/patch-src_joystick_SDL_gamecontrollerdb_h
===
RCS file:
/cvs/ports/devel/sdl2/patches/patch-src_joystick_SDL_gamecontrollerdb_h,v
retrieving revision 1.11
diff -u -p -r1.11 patch-src_joystick_SDL_gamecontrollerdb_h
--- patches/patch-src_joystick_SDL_gamecontrollerdb_h 24 Feb 2024 17:34:36
- 1.11
+++ patches/patch-src_joystick_SDL_gamecontrollerdb_h 3 May 2024 18:04:32
-
@@ -1,7 +1,7 @@
Index: src/joystick/SDL_gamecontrollerdb.h
--- src/joystick/SDL_gamecontrollerdb.h.orig
+++ src/joystick/SDL_gamecontrollerdb.h
-@@ -870,6 +870,7 @@ static const char *s_ControllerMappings[] = {
+@@ -871,6 +871,7 @@ static const char *s_ControllerMappings[] = {
"03004c05c4050001,PS4
Controller,a:b1,b:b2,back:b8,dpdown:h0.4,dpleft:h0.8,dpright:h0.2,dpup:h0.1,guide:b12,leftshoulder:b4,leftstick:b10,lefttrigger:a3,leftx:a0,lefty:a1,rightshoulder:b5,rightstick:b11,righttrigger:a4,rightx:a2,righty:a5,start:b9,x:b0,y:b3,",
"03004c05e60c0001,PS5
Controller,a:b1,b:b2,back:b8,dpdown:h0.4,dpleft:h0.8,dpright:h0.2,dpup:h0.1,guide:b12,leftshoulder:b4,leftstick:b10,lefttrigger:a3,leftx:a0,lefty:a1,rightshoulder:b5,rightstick:b11,righttrigger:a4,rightx:a2,righty:a5,start:b9,x:b0,y:b3,",
"03005e048e021001,Xbox 360
Controller,a:b0,b:b1,back:b6,dpdown:h0.4,dpleft:h0.8,dpright:h0.2,dpup:h0.1,guide:b10,leftshoulder:b4,leftstick:b8,lefttrigger:a2,leftx:a0,lefty:a1~,rightshoulder:b5,rightstick:b9,righttrigger:a5,rightx:a3,righty:a4~,start:b7,x:b2,y:b3,",
Re: UPDATE: libsamplerate
> > > > > > On Apr 26 20:46:51, b...@comstyle.com wrote:
> > > > > > > Implement SSE2 lrint() and lrintf() on amd64.
> > > > > >
> > > > > > I don't think this is worth the added complexity:
> > > > > > seven more patches to have a different lrint()?
> > > > > > Does it make the resampling noticably better/faster?
> > > > >
> > > https://github.com/libsndfile/libsndfile/pull/663
> > > -> https://quick-bench.com/q/OabKT-gEOZ8CYDriy1JEwq1lEsg
> > > where there's a huge difference in clang builds.
> >
> > Sorry, I don't understand at all how this concerns
> > the OpenBSD port of libsamplerate: the Benchmark does not
> > mention an OS or an architecture, so what is this being run on?
> >
> > Anyway, just running it (Run Benchmark) gives the result
> > of cpu_time of 722.537 for BM_d2les_array (using lrint)
> > and cpu_time of 0 for BM_d2les_array_sse2 (using psf_lrint),
> > reporting a speedup ratio of 200,000,000.
> >
> > That's not an example of what I have in mind: a simple application
> > of libsamplerate, sped up by the usage of the new SSE2 lrint
> OK, here is a test that's a modified version of what Stuart linked,
> testing the performance of the lrint() itself (code below).
A better test below, lrint()ing a random sequence.
The SSE version is slower on every SSE2 machine I tried.
Is that the case for you too?
Jan
#include
#include
static inline int
psf_lrint(double const x)
{
return _mm_cvtsd_si32(_mm_load_sd(&x));
}
static void
d2l(const double *src, long *dst, size_t len)
{
for (size_t i = 0; i < len; i++)
dst[i] = lrint(src[i]);
}
static void
d2l_sse(const double *src, long *dst, size_t len)
{
for (size_t i = 0; i < len; i++)
dst[i] = psf_lrint(src[i]);
}
int
main()
{
size_t i, len = 1000 * 1000 * 100;
double *src = NULL;
long *dst = NULL;
src = calloc(len, sizeof(double));
dst = calloc(len, sizeof(long));
arc4random_buf(src, len * sizeof(double));
d2l_sse(src, dst, len);
/*d2l(src, dst, len);*/
return 0;
}
Re: transmission_daemon silently freeze?
03.05.2024 20:21, Josh Grosse пишет: On Fri, May 03, 2024 at 05:31:16PM +0300, kasak wrote: OpenBSD 7.5 GENERIC.MP#82 amd64 There's not enough information here to understand either the cause or solution to your problem. I happen to have pre-built, unsigned debug-* packages for 7.5-release on amd64, for use with egdb (from devel/gdb). https://jggimi.net/transmission/debug-transmission-4.0.5p0.tgz https://jggimi.net/transmission/debug-transmission-qt-4.0.5p0.tgz https://jggimi.net/transmission/debug-transmission-gtk-4.0.5p0.tgz These may help you debug the problem. Thank you! I'll try it and report! It's kinda problem i need to wait couple of days to freeze it. That's why I suggested maybe this is some hardware problem. But prior 7.5 it was absolute stable, with 20-30 torrents serving for 2-3 month nonstop.
Re: transmission_daemon silently freeze?
On Fri, May 03, 2024 at 05:31:16PM +0300, kasak wrote: > OpenBSD 7.5 GENERIC.MP#82 amd64 There's not enough information here to understand either the cause or solution to your problem. I happen to have pre-built, unsigned debug-* packages for 7.5-release on amd64, for use with egdb (from devel/gdb). https://jggimi.net/transmission/debug-transmission-4.0.5p0.tgz https://jggimi.net/transmission/debug-transmission-qt-4.0.5p0.tgz https://jggimi.net/transmission/debug-transmission-gtk-4.0.5p0.tgz These may help you debug the problem.
TESTING NEEDED: emulators/melonds
hey ports@: I take MAINTAINER on the port for MelonDS. I usually fire up my emwm port when I run it, since a floating WM just makes more sense for a DS emulator (point n' click touchscreen input). Today, I tried MelonDS in my normal WM of choice, StumpWM. It ran fine, but as soon as I attempt split/restore the frame quickly with the MelonDS window active, the program segfaults with an error related to losing the X11 server connection. Looking at its running log before it crashes: ``` The X11 connection broke (error 1). Did the X11 server die? zsh: segmentation fault melonDS ``` It only seems to happen with a game running using the OpenGL gfx backend. I can't replicate this when using software gfx. I haven't tested with other tiling WMs, but I am curious if others are experiencing this as well, so I know its not just my machine being screwy. I am on: ``` OpenBSD Panasonic-OpenBaSeD.lan 7.5 GENERIC.MP#37 amd64 ``` and attached is my dmesg any idea? best- -- -iz (they/them) > i like to say mundane things, > there are too many uninteresting things > that go unnoticed. izder456 (dot) neocities (dot) org OpenBSD 7.5-current (GENERIC.MP) #37: Mon Apr 29 10:12:13 MDT 2024 dera...@amd64.openbsd.org:/usr/src/sys/arch/amd64/compile/GENERIC.MP real mem = 17030901760 (16241MB) avail mem = 16493510656 (15729MB) random: good seed from bootblocks mpath0 at root scsibus0 at mpath0: 256 targets mainbus0 at root bios0 at mainbus0: SMBIOS rev. 2.8 @ 0xdba32000 (35 entries) bios0: vendor American Megatrends Inc. version "V1.50L20" date 07/03/2019 bios0: Panasonic Corporation CFSX4-1 efi0 at bios0: UEFI 2.4 efi0: American Megatrends rev 0x5000a acpi0 at bios0: ACPI 5.0 acpi0: sleep states S0 S3 S4 S5 acpi0: tables DSDT FACP APIC FPDT FIDT MCFG HPET SSDT SSDT ASF! TCPA SLIC UEFI SSDT SSDT SSDT SSDT SSDT SSDT MSDM DMAR BGRT acpi0: wakeup devices PEG0(S4) PEGP(S4) PEG1(S4) PEGP(S4) PEG2(S4) PEGP(S4) XHC1(S3) EHC1(S3) HDEF(S3) GLAN(S4) RP03(S3) PXSX(S3) LID0(S4) 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) i5-5300U CPU @ 2.30GHz, 2693.88 MHz, 06-3d-04, patch 002f 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,HLE,AVX2,SMEP,BMI2,ERMS,INVPCID,RTM,RDSEED,ADX,SMAP,PT,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.1.1.1, IBE cpu1 at mainbus0: apid 2 (application processor) cpu1: Intel(R) Core(TM) i5-5300U CPU @ 2.30GHz, 2693.89 MHz, 06-3d-04, patch 002f 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,HLE,AVX2,SMEP,BMI2,ERMS,INVPCID,RTM,RDSEED,ADX,SMAP,PT,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) i5-5300U CPU @ 2.30GHz, 2693.88 MHz, 06-3d-04, patch 002f 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,HLE,AVX2,SMEP,BMI2,ERMS,INVPCID,RTM,RDSEED,ADX,SMAP,PT,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) i5-5300U CPU @ 2.30GHz, 2693.95 MHz, 06-3d-04, patch 002f 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,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,LAH
Re: update games/hyperrogue
On Thu, May 02, 2024 at 01:07:08PM GMT, Thomas Frohwein wrote:
> On Fri, Apr 19, 2024 at 10:27:49PM +0200, Solene Rapenne wrote:
> > our hyperrogue version is quite old of a dozen releases
> >
> > latest release adds a lot of changes
> > https://github.com/zenorogue/hyperrogue/releases
> >
> > the Makefile patch had to be reworked a bit because the original
> > Makefile differed from the patch, but it applies the same changes
> > as before.
> >
> > update-plist removed some honeycomb files, I don't know if it's
> > expected... the game plays fine
>
> Built it and it works as expected.
>
> Noticed that it save hyperrogue.log in $PWD which I find annoying, not
> sure if that's how upstream designed it. It would make more sense to
> have a location in the home directory for that. Might be worth checking
> on, but either way this update is ok thfr@, provided Brian is okay with
> it or timeout...
it also saves settings in $PWD...This can be solved by compiling
with -DFHS to have the files saved in $HOME/
Not sure if the place I've put it into CXXFLAGS variable is ok?
you can try quickly in game: open settings menu and choose "save"
diff --git a/games/hyperrogue/Makefile b/games/hyperrogue/Makefile
index 4c1a7417f10..3b211a563a9 100644
--- a/games/hyperrogue/Makefile
+++ b/games/hyperrogue/Makefile
@@ -1,4 +1,4 @@
-V =12.0f
+V =13.0d
COMMENT = roguelike game in a non-Euclidean world
CATEGORIES = games x11
@@ -24,7 +24,7 @@ LIB_DEPENDS = devel/sdl-gfx \
graphics/glew \
graphics/png
-CXXFLAGS +=-I${LOCALBASE}/include -I${X11BASE}/include \
+CXXFLAGS +=-I${LOCALBASE}/include -I${X11BASE}/include -DFHS\
-DHYPERPATH="\\\"${LOCALBASE}/share/hyperrogue/\\\""
LDFLAGS += -L${LOCALBASE}/lib -L${X11BASE}/lib
diff --git a/games/hyperrogue/distinfo b/games/hyperrogue/distinfo
index 835425d2f49..fe08e61d88c 100644
--- a/games/hyperrogue/distinfo
+++ b/games/hyperrogue/distinfo
@@ -1,2 +1,2 @@
-SHA256 (hyperrogue-12.0f.tar.gz) = ROeOk+0dMZg9680EeR1//Pz73EBpfnCaD2yi04wwID4=
-SIZE (hyperrogue-12.0f.tar.gz) = 79946099
+SHA256 (hyperrogue-13.0d.tar.gz) = 4ApHLRReh9u3dzH+FXCHyB2N5b0rBfogkbyQGFMIDoo=
+SIZE (hyperrogue-13.0d.tar.gz) = 87765129
diff --git a/games/hyperrogue/patches/patch-Makefile
b/games/hyperrogue/patches/patch-Makefile
index 1567a49854b..6d4afc867d8 100644
--- a/games/hyperrogue/patches/patch-Makefile
+++ b/games/hyperrogue/patches/patch-Makefile
@@ -26,9 +26,9 @@ Index: Makefile
-ifeq (${TOOLCHAIN},clang)
- CXXFLAGS_STD = -std=c++11
-- CXXFLAGS_EARLY += -march=native -fPIC
-- CXXFLAGS_EARLY += -W -Wall -Wextra -Wsuggest-override -Werror -pedantic
-- CXXFLAGS_EARLY += -Wno-unused-parameter -Wno-implicit-fallthrough
-Wno-maybe-uninitialized -Wno-unknown-warning-option
+- CXXFLAGS_EARLY += -fPIC
+- CXXFLAGS_EARLY += -W -Wall -Wextra -Wsuggest-override -pedantic
+- CXXFLAGS_EARLY += -Wno-unused-parameter -Wno-implicit-fallthrough
-Wno-maybe-uninitialized -Wno-char-subscripts -Wno-unknown-warning-option
- CXXFLAGS_EARLY += -Wno-invalid-offsetof
-endif
+CXXFLAGS_STD = -std=c++11
@@ -39,23 +39,23 @@ Index: Makefile
-ifeq (${TOOLCHAIN},gcc)
- CXXFLAGS_STD = -std=c++11
-- CXXFLAGS_EARLY += -march=native -fPIC
-- CXXFLAGS_EARLY += -W -Wall -Wextra -Werror -pedantic
+- CXXFLAGS_EARLY += -fPIC
+- CXXFLAGS_EARLY += -W -Wall -Wextra -pedantic
- CXXFLAGS_EARLY += -Wno-unused-parameter -Wno-implicit-fallthrough
-Wno-maybe-uninitialized
+- CXXFLAGS_EARLY += -Wno-invalid-offsetof
-endif
-
-ifeq (${TOOLCHAIN},mingw)
- CXXFLAGS_STD = -std=c++11
-- CXXFLAGS_EARLY += -march=native
-- CXXFLAGS_EARLY += -W -Wall -Wextra -Werror
+- CXXFLAGS_EARLY += -W -Wall -Wextra
- CXXFLAGS_EARLY += -Wno-unused-parameter -Wno-implicit-fallthrough
-Wno-maybe-uninitialized
+- CXXFLAGS_EARLY += -Wno-invalid-offsetof
-endif
-
--
- ## We have now finished OS-specific and TOOLCHAIN-specific computations.
- ## Begin customization points for user-specifiable HYPERROGUE_USE_XXX macros.
-
-@@ -139,19 +120,19 @@ override CXXFLAGS := $(CXXFLAGS_STD) $(CXXFLAGS_EARLY)
+ ifeq (${FONTCONFIG},1)
+ CXXFLAGS_EARLY += -DFONTCONFIG `pkg-config --cflags fontconfig`
+ LDFLAGS_EARLY += `pkg-config --libs fontconfig`
+@@ -144,19 +125,19 @@ override CXXFLAGS := $(CXXFLAGS_STD) $(CXXFLAGS_EARLY)
override LDFLAGS := $(LDFLAGS_EARLY) $(LDFLAGS) ${EXTRA_LDFLAGS}
hyperrogue$(EXE_EXTENSION): $(hyper_OBJS) $(hyper_RES)
@@ -78,8 +78,8 @@ Index: Makefile
+ $(CXX) $(CXXFLAGS) makeh.cpp $(LDFLAGS) -o $@
autohdr.h: makeh$(EXE_EXTENSION) language-data.cpp *.cpp
- ./makeh classes.cpp locations.cpp colors.cpp hyperpoint.cpp
geometry.cpp goldberg.cpp init.cpp floorshapes.cpp cell.cpp multi.cpp shmup.cpp
pattern2.cpp mapeditor.cpp graph.cpp textures.cpp hprint.cpp language.cpp
util.cpp complex.cpp *.cpp > autohdr.h
-@@ -160,10 +141,10 @@ language-data.cpp: langen$(EXE_EXTENSION)
+ ./makeh class
Re: UPDATE: x265 3.6
ping.
On 2024-04-24 5:28 a.m., Brad Smith wrote:
ping.
On 2024-04-05 4:19 p.m., Brad Smith wrote:
Here is an update to x265 3.6.
Version 3.6
===
Release date - 4th April, 2024.
New feature
---
1. Segment based Ratecontrol (SBRC) feature
2. Motion-Compensated Spatio-Temporal Filtering
3. Scene-cut aware qp - BBAQ (Bidirectional Boundary Aware Quantization)
4. Histogram-Based Scene Change Detection
5. Film-Grain characteristics as a SEI message to support Film Grain
Synthesis(FGS)
6. Add temporal layer implementation(Hierarchical B-frame
implementation)
Enhancements to existing features
-
1. Added Dolby Vision 8.4 Profile Support
API changes
---
1. Add Segment based Ratecontrol(SBRC) feature: "--[no-]sbrc".
2. Add command line parameter for mcstf feature: "--[no-]mctf".
3. Add command line parameters for the scene cut aware qp feature:
"--scenecut-aware-qp" and "--masking-strength".
4. Add command line parameters for Histogram-Based Scene Change
Detection: "--hist-scenecut".
5. Add film grain characteristics as a SEI message to the bitstream:
"--film-grain "
6. cli: add new option --cra-nal (Force nal type to CRA to all frames
expect for the first frame, works only with keyint 1)
Optimizations
-
ARM64 NEON optimizations:- Several time-consuming C functions have
been optimized for the targeted platform - aarch64. The overall
performance increased by around 20%.
SVE/SVE2 optimizations
Bug fixes
-
1. Linux bug to utilize all the cores
2. Crash with hist-scenecut build when source resolution is not
multiple of minCuSize
3. 32bit and 64bit builds generation for ARM
4. bugs in zonefile feature (Reflect Zonefile Parameters inside
Lookahead, extra IDR issue, Avg I Slice QP value issue etc..)
5. Add x86 ASM implementation for subsampling luma
6. Fix for abrladder segfault with load reuse level 1
7. Reorder miniGOP based on temporal layer hierarchy and add support
for more B frame
8. Add MacOS aarch64 build support
9. Fix boundary condition issue for Gaussian filter
Index: Makefile
===
RCS file: /cvs/ports/multimedia/x265/Makefile,v
retrieving revision 1.58
diff -u -p -u -p -r1.58 Makefile
--- Makefile 20 Feb 2024 10:05:00 - 1.58
+++ Makefile 5 Apr 2024 19:46:36 -
@@ -1,13 +1,12 @@
COMMENT= free H.265/HEVC encoder
-VER= 3.5
+VER= 3.6
DISTNAME= x265_${VER}
PKGNAME= x265-${VER}
-REVISION= 3
CATEGORIES= multimedia
SITES= https://bitbucket.org/multicoreware/x265_git/downloads/
-SHARED_LIBS= x265 23.0
+SHARED_LIBS= x265 24.0
HOMEPAGE= https://x265.org/
Index: distinfo
===
RCS file: /cvs/ports/multimedia/x265/distinfo,v
retrieving revision 1.26
diff -u -p -u -p -r1.26 distinfo
--- distinfo 24 Apr 2021 05:48:25 - 1.26
+++ distinfo 5 Apr 2024 19:46:36 -
@@ -1,2 +1,2 @@
-SHA256 (x265_3.5.tar.gz) = 5wozNcrKy7oLOiDsb+zWeDkyKI68gWOtdLzJYGR3yug=
-SIZE (x265_3.5.tar.gz) = 1537044
+SHA256 (x265_3.6.tar.gz) = ZjUx80HFOJ9GDXMOYuEKT8yjQoyiyhCWk4Z7xf4uKAc=
+SIZE (x265_3.6.tar.gz) = 1655889
Index: patches/patch-source_CMakeLists_txt
===
RCS file:
/cvs/ports/multimedia/x265/patches/patch-source_CMakeLists_txt,v
retrieving revision 1.7
diff -u -p -u -p -r1.7 patch-source_CMakeLists_txt
--- patches/patch-source_CMakeLists_txt 11 Mar 2022 19:39:29
- 1.7
+++ patches/patch-source_CMakeLists_txt 5 Apr 2024 19:46:36 -
@@ -1,7 +1,7 @@
Index: source/CMakeLists.txt
--- source/CMakeLists.txt.orig
+++ source/CMakeLists.txt
-@@ -485,7 +485,8 @@ if(POWER)
+@@ -523,7 +523,8 @@ if(POWER)
endif()
endif()
Index: patches/patch-source_common_aarch64_asm_S
===
RCS file:
/cvs/ports/multimedia/x265/patches/patch-source_common_aarch64_asm_S,v
retrieving revision 1.3
diff -u -p -u -p -r1.3 patch-source_common_aarch64_asm_S
--- patches/patch-source_common_aarch64_asm_S 17 Jun 2023 22:18:31
- 1.3
+++ patches/patch-source_common_aarch64_asm_S 5 Apr 2024 19:46:36
-
@@ -1,50 +1,7 @@
-- fix the compiling errors on MAC
- 0983cffc501e5279e7d9e9b2241b506cb332efcb
-- fix clang compile errors on linux
- 577b658105b90ec1c04b049e43a51384172fb8fc
-
Index: source/common/aarch64/asm.S
--- source/common/aarch64/asm.S.orig
+++ source/common/aarch64/asm.S
-@@ -25,23 +25,35 @@
-
- #ifdef PREFIX
- #define EXTERN_ASM _
-+#define HAVE_AS_FUNC 0
-+#elif defined __clang__
-+#define EXTERN_ASM
-+#define HAVE_AS_FUNC 0
-+#define PREFIX 1
- #else
- #define EXTERN_ASM
-+#define HAVE_AS_FUNC 1
- #endif
-
- #ifdef __ELF__
- #define ELF
- #else
-+#ifdef PREFIX
-+#define ELF #
-+#else
- #define ELF @
- #endif
-+#endif
-
--#define HAVE_AS_FUNC 1
--
- #if HAVE_AS_FUN
Re: [maintainer update] sysutils/fzf 0.51.0
On Wed, May 01, 2024 at 03:06:18PM +0200, Laurent Cheylus wrote: > Hi, > > a simple update for sysutils/fzf version 0.51.0 > Changelog: https://github.com/junegunn/fzf/releases/tag/0.51.0 > > - update Makefile and modules.inc for this version > > Build and tests OK on current/amd64. > > Please tests welcome and commit if OK. built and tested on latest -current/amd64 zsh, vim and emacs integration works ok
Re: update devel/fossil
On Fri, May 03, 2024 at 09:38:03AM +0100, Stuart Henderson wrote: > On 2024/05/03 09:22, Solene Rapenne wrote: > > this updates fossil to latest version, > > changelog available > > https://fossil-scm.org/home/doc/trunk/www/changes.wiki#v2_24 > > > > ok? > > > > diff --git a/devel/fossil/Makefile b/devel/fossil/Makefile > > index fb869e9fa31..1311dd4fd49 100644 > > --- a/devel/fossil/Makefile > > +++ b/devel/fossil/Makefile > > @@ -1,7 +1,6 @@ > > COMMENT = simple distributed software configuration management > > > > -DISTNAME = fossil-2.23 > > -EPOCH =0 > > EPOCH cannot be removed ok jturner@ with EPOCH staying > > > +DISTNAME = fossil-2.24 > > CATEGORIES = devel www > > > > MAINTAINER = James Turner > > diff --git a/devel/fossil/distinfo b/devel/fossil/distinfo > > index 6eaaf2a218f..eec4ebdd1f7 100644 > > --- a/devel/fossil/distinfo > > +++ b/devel/fossil/distinfo > > @@ -1,2 +1,2 @@ > > -SHA256 (fossil-2.23.tar.gz) = dfgI6BNRAYqXFnRtnvGh/huxkEcz6LQYZDiB04GYhZM= > > -SIZE (fossil-2.23.tar.gz) = 6798900 > > +SHA256 (fossil-2.24.tar.gz) = 7bXPKgf4FBDPUjl+DoQVWKp4qJFsYmin9xH2IXPYXMk= > > +SIZE (fossil-2.24.tar.gz) = 6798925 > >
Re: transmission_daemon silently freeze?
03.05.2024 15:30, Josh Grosse пишет: On Fri, May 03, 2024 at 11:26:00AM +0300, kasak wrote: i'm sorry for bothering. my transmission_daemon freezes for unknown reason, I wanted to know is this some bug or troubles with my hardware? I'm the maintainer for net/transmission. I'm aware of one previously reported issue with transmission-daemon, where it hangs on start when executed in a rtable other than the default rtable 0. (I know it's an issue with libcurl-multi, but as yet I have not determined the root cause.) Your problem appears to be different, since the daemon is able to operate on start, and hangs later. Are you running 7.5? -current? Are you on amd64? Another architecture? OpenBSD 7.5 GENERIC.MP#82 amd64 Freezes happens after day or so. rcctl and ps both show me that daemon is running, but i can't connect to web ui and torrents are not downloading or uploading this is frozen daemon: mx$ curl -v gw:9091 * Host gw:9091 was resolved. * IPv6: (none) * IPv4: 192.168.0.1 * Trying 192.168.0.1:9091... * Connected to gw (192.168.0.1) port 9091 GET / HTTP/1.1 Host: gw:9091 User-Agent: curl/8.7.1 Accept: */* * Request completely sent off ^C and after restarting it, it works as should: mx$ doas rcctl restart transmission_daemon transmission_daemon(ok) transmission_daemon(ok) mx$ curl -v gw:9091 * Host gw:9091 was resolved. * IPv6: (none) * IPv4: 192.168.0.1 * Trying 192.168.0.1:9091... * Connected to gw (192.168.0.1) port 9091 GET / HTTP/1.1 Host: gw:9091 User-Agent: curl/8.7.1 Accept: */* * Request completely sent off < HTTP/1.1 301 Moved Permanently < Server: Transmission < Access-Control-Allow-Origin: * < Location: /transmission/web/ < Date: Fri, 03 May 2024 08:03:26 GMT < Content-Length: 31 < Content-Type: text/html; charset=ISO-8859-1 < * Connection #0 to host gw left intact 301: Moved Permanentlymx$ i think this behavior appeared since 7.5. Am I alone with this or maybe someone hit this too? And I forgot to mention, no logs from transmission_daemon appearing before or after freeze
Re: transmission_daemon silently freeze?
On Fri, May 03, 2024 at 11:26:00AM +0300, kasak wrote: > i'm sorry for bothering. > > my transmission_daemon freezes for unknown reason, I wanted to know is this > some bug or troubles with my hardware? I'm the maintainer for net/transmission. I'm aware of one previously reported issue with transmission-daemon, where it hangs on start when executed in a rtable other than the default rtable 0. (I know it's an issue with libcurl-multi, but as yet I have not determined the root cause.) Your problem appears to be different, since the daemon is able to operate on start, and hangs later. Are you running 7.5? -current? Are you on amd64? Another architecture? > Freezes happens after day or so. rcctl and ps both show me that daemon is > running, but i can't connect to web ui and torrents are not downloading or > uploading > > this is frozen daemon: > > mx$ curl -v gw:9091 > * Host gw:9091 was resolved. > * IPv6: (none) > * IPv4: 192.168.0.1 > * Trying 192.168.0.1:9091... > * Connected to gw (192.168.0.1) port 9091 > > GET / HTTP/1.1 > > Host: gw:9091 > > User-Agent: curl/8.7.1 > > Accept: */* > > > * Request completely sent off > > ^C > > and after restarting it, it works as should: > > mx$ doas rcctl restart transmission_daemon > transmission_daemon(ok) > transmission_daemon(ok) > mx$ curl -v gw:9091 > * Host gw:9091 was resolved. > * IPv6: (none) > * IPv4: 192.168.0.1 > * Trying 192.168.0.1:9091... > * Connected to gw (192.168.0.1) port 9091 > > GET / HTTP/1.1 > > Host: gw:9091 > > User-Agent: curl/8.7.1 > > Accept: */* > > > * Request completely sent off > < HTTP/1.1 301 Moved Permanently > < Server: Transmission > < Access-Control-Allow-Origin: * > < Location: /transmission/web/ > < Date: Fri, 03 May 2024 08:03:26 GMT > < Content-Length: 31 > < Content-Type: text/html; charset=ISO-8859-1 > < > * Connection #0 to host gw left intact > 301: Moved Permanentlymx$ > > i think this behavior appeared since 7.5. > > Am I alone with this or maybe someone hit this too? > > And I forgot to mention, no logs from transmission_daemon appearing before > or after freeze >
Re: UPDATE: libsamplerate
On May 02 14:29:26, h...@stare.cz wrote:
> On May 02 13:04:54, s...@spacehopper.org wrote:
> > On 2024/05/01 21:04, Jan Stary wrote:
> > > On May 01 11:00:12, s...@spacehopper.org wrote:
> > > > On 2024/05/01 11:21, Jan Stary wrote:
> > > > > Hi,
> > > > >
> > > > > On Apr 26 20:46:51, b...@comstyle.com wrote:
> > > > > > Implement SSE2 lrint() and lrintf() on amd64.
> > > > >
> > > > > I don't think this is worth the added complexity:
> > > > > seven more patches to have a different lrint()?
> > > > > Does it make the resampling noticably better/faster?
> > > >
> > > > Playing with the benchmark mentioned in
> > > > https://github.com/libsndfile/libsamplerate/issues/187
> > > > suggests that it's going to be *hugely* faster with clang (and a bit
> > > > faster with gcc).
> > >
> > > This talks about a MSVC build compared to a MinGW64 build on windows.
> > > Is that also relevant to an AMD64 build on OpenBSD? I just rebuilt
> > > with the diff - what would be a good way to test the actual performance
> > > before and after?
> >
> > oh, actually it was the bench in the linked PR that I played with,
> >
> > https://github.com/libsndfile/libsndfile/pull/663
> > -> https://quick-bench.com/q/OabKT-gEOZ8CYDriy1JEwq1lEsg
> >
> > where there's a huge difference in clang builds.
>
> Sorry, I don't understand at all how this concerns
> the OpenBSD port of libsamplerate: the Benchmark does not
> mention an OS or an architecture, so what is this being run on?
>
> Anyway, just running it (Run Benchmark) gives the result
> of cpu_time of 722.537 for BM_d2les_array (using lrint)
> and cpu_time of 0 for BM_d2les_array_sse2 (using psf_lrint),
> reporting a speedup ratio of 200,000,000.
>
> That's not an example of what I have in mind: a simple application
> of libsamplerate, sped up by the usage of the new SSE2 lrint,
> as in Brad's diff.
>
> I am not sure my naive test is a test at all, as it operates on floats,
> so perhaps lrint() never even comes to play. That is libsamplerate's
> "simple API" - I will try to come up with something that actualy
> conevrts to ints while resampling. But maybe someone already has
> a good example of such a speedup.
OK, here is a test that's a modified version of what Stuart linked,
testing the performance of the lrint() itself (code below).
This is a current/amd64 PC, clang version 16.0.6
It is actualy _slower_ than the standard version.
With the standard lrint():
0m10.90s real 0m03.75s user 0m05.66s system
0m11.01s real 0m03.56s user 0m05.96s system
0m10.99s real 0m03.67s user 0m05.82s system
With the SSE2 lrint():
0m12.92s real 0m05.74s user 0m05.63s system
0m12.77s real 0m05.15s user 0m06.12s system
0m12.66s real 0m05.57s user 0m05.62s system
Can you please confirm it is also slower
on your clang machine with SSE2?
Jan
#include
#include
static inline int
psf_lrint(double const x)
{
return _mm_cvtsd_si32(_mm_load_sd(&x));
}
static void
d2l(const double *src, long *dst, size_t len)
{
for (size_t i = 0; i < len; i++)
dst[i] = lrint(src[i]);
}
static void
d2l_sse(const double *src, long *dst, size_t len)
{
for (size_t i = 0; i < len; i++)
dst[i] = psf_lrint(src[i]);
}
int
main()
{
size_t i, len = 5;
double *src = NULL;
long *dst = NULL;
src = calloc(len, sizeof(double));
dst = calloc(len, sizeof(long));
for (i = 0; i < len; i++) {
/*src[i] = sin(i);*/
src[i] = 0;
}
/*d2l(src, dst, len);*/
d2l_sse(src, dst, len);
return 0;
}
Re: [new] lnav 0.12.1
On Fri, Apr 26, 2024 at 10:41:46AM +0200, Landry Breuil wrote: > > On my machine it creates ~/.config/lnav, not ~/.lnav, and removing the > > ~/.config/lnav directory unfortunately doesn't change anything, it still > > crashes early at startup. > > it probably does funky things depending on $TERM. > > it works fine within tmux where TERM=screen, it crashes in > xfce4-terminal (where here TERM=xterm-256color) but works fine if i > manually set TERM=xterm. > > same thing with alacritty, it crashes if TERM=alacritty (the default) > but works fine with 'TERM=xterm lnav' > > you seem to be a guy with interest in low-level terminal stuff :) grep > -r TERM yields many things in lnav's code... and there seem to be > related issues upstream, cf https://github.com/tstack/lnav/issues/570 > and https://github.com/tstack/lnav/issues/1192 at least. But it shouldnt > crash like this :) > > in the meantime, here's a port of 0.12.2, still building here... it > might give better results, or not. This version does indeed solves the issues, it runs perfectly in the terminals I previously tested with, and it exits gracefully in case TERM is set to an unknown option: $ TERM=puffy lnav error: unable to open TUI reason: the terminfo database could not be found Looks good to me for import now, OK fcambus@.
[update] editors/vis 0.8 -> 0.9
Please find below an update for editors/vis to version 0.9. The tests
(which are hosted separately) didn't seem to get an update, but they all
still pass.
Cc'd maintainer.
Index: Makefile
===
RCS file: /cvs/ports/editors/vis/Makefile,v
retrieving revision 1.18
diff -u -p -r1.18 Makefile
--- Makefile5 Oct 2023 12:10:41 - 1.18
+++ Makefile3 May 2024 12:19:28 -
@@ -1,8 +1,7 @@
COMMENT = vi-like editor with sam-style structural regex support
-V =0.8
+V =0.9
DISTNAME = vis-${V}
-REVISION = 1
TEST_V = 0.5
TEST_DISTNAME =vis-test-${TEST_V}
@@ -18,9 +17,8 @@ PERMIT_PACKAGE = Yes
WANTLIB += c curses iconv intl m termkey tre ${MODLUA_WANTLIB}
-SITES =${HOMEPAGE}/releases/download/v${V}/
-SITES.test = ${HOMEPAGE}-test/releases/download/v${TEST_V}/
-DISTFILES.test = ${TEST_DISTNAME}${EXTRACT_SUFX}
+DIST_TUPLE += github martanne vis v${V} .
+DIST_TUPLE += github martanne vis-test v${TEST_V} .
MODULES = lang/lua
MODLUA_VERSION = 5.3
Index: distinfo
===
RCS file: /cvs/ports/editors/vis/distinfo,v
retrieving revision 1.5
diff -u -p -r1.5 distinfo
--- distinfo5 Nov 2022 13:03:00 - 1.5
+++ distinfo3 May 2024 12:19:28 -
@@ -1,4 +1,4 @@
-SHA256 (vis-0.8.tar.gz) = YbENQPFcTbLOFums8pHbt2LaTLzPDPKoCyjZrJmKOb0=
-SHA256 (vis-test-0.5.tar.gz) = AJitkz7B+Hu6Sy2p+oTgDKtWEuw2I2IsHlADokWux9E=
-SIZE (vis-0.8.tar.gz) = 404496
-SIZE (vis-test-0.5.tar.gz) = 99314
+SHA256 (martanne-vis-test-v0.5.tar.gz) =
AJitkz7B+Hu6Sy2p+oTgDKtWEuw2I2IsHlADokWux9E=
+SHA256 (martanne-vis-v0.9.tar.gz) =
vTf/ulU15mXB6IPCW6X04zB1abbTksYPPH1d7dLvz8o=
+SIZE (martanne-vis-test-v0.5.tar.gz) = 99314
+SIZE (martanne-vis-v0.9.tar.gz) = 456713
Index: patches/patch-configure
===
RCS file: /cvs/ports/editors/vis/patches/patch-configure,v
retrieving revision 1.7
diff -u -p -r1.7 patch-configure
--- patches/patch-configure 5 Oct 2023 12:10:41 - 1.7
+++ patches/patch-configure 3 May 2024 12:19:28 -
@@ -11,11 +11,11 @@ Index: configure
tryflag CFLAGS -ffunction-sections
tryflag CFLAGS -fdata-sections
tryldflag LDFLAGS_AUTO -Wl,--gc-sections
-@@ -443,7 +442,7 @@ int main(int argc, char *argv[]) {
+@@ -444,7 +443,7 @@ int main(int argc, char *argv[]) {
}
EOF
-- for liblua in lua lua5.4 lua5.3 lua5.2 lua-5.3 lua-5.2 lua54 lua53
lua52; do
+- for liblua in lua lua5.4 lua5.3 lua5.2 lua-5.4 lua-5.3 lua-5.2 lua54
lua53 lua52; do
+ for liblua in $LUA_VER; do
printf " checking for %s... " "$liblua"
Index: patches/patch-man_vis_1
===
RCS file: /cvs/ports/editors/vis/patches/patch-man_vis_1,v
retrieving revision 1.1
diff -u -p -r1.1 patch-man_vis_1
--- patches/patch-man_vis_1 20 Nov 2022 12:06:58 - 1.1
+++ patches/patch-man_vis_1 3 May 2024 12:19:28 -
@@ -3,7 +3,7 @@ Point at correct manual
Index: man/vis.1
--- man/vis.1.orig
+++ man/vis.1
-@@ -260,7 +260,7 @@ currently defers regular expression matching to the un
+@@ -265,7 +265,7 @@ currently defers regular expression matching to the un
It uses what POSIX refers to as
.Dq Extended Regular Expressions
as described in
Index: pkg/PLIST
===
RCS file: /cvs/ports/editors/vis/pkg/PLIST,v
retrieving revision 1.5
diff -u -p -r1.5 PLIST
--- pkg/PLIST 10 Mar 2022 12:03:31 - 1.5
+++ pkg/PLIST 3 May 2024 12:19:28 -
@@ -27,6 +27,7 @@ share/vis/lexers/apl.lua
share/vis/lexers/applescript.lua
share/vis/lexers/asm.lua
share/vis/lexers/asp.lua
+share/vis/lexers/autohotkey.lua
share/vis/lexers/autoit.lua
share/vis/lexers/awk.lua
share/vis/lexers/bash.lua
@@ -70,11 +71,13 @@ share/vis/lexers/gemini.lua
share/vis/lexers/gettext.lua
share/vis/lexers/gherkin.lua
share/vis/lexers/git-rebase.lua
+share/vis/lexers/gleam.lua
share/vis/lexers/glsl.lua
share/vis/lexers/gnuplot.lua
share/vis/lexers/go.lua
share/vis/lexers/groovy.lua
share/vis/lexers/gtkrc.lua
+share/vis/lexers/hare.lua
share/vis/lexers/haskell.lua
share/vis/lexers/html.lua
share/vis/lexers/icon.lua
@@ -84,6 +87,7 @@ share/vis/lexers/ini.lua
share/vis/lexers/io_lang.lua
share/vis/lexers/java.lua
share/vis/lexers/javascript.lua
+share/vis/lexers/jq.lua
share/vis/lexers/json.lua
share/vis/lexers/jsp.lua
share/vis/lexers/julia.lua
@@ -100,6 +104,7 @@ share/vis/lexers/makefile.lua
share/vis/lexers/man.lua
share/vis/lexers/markdown.lua
share/vis/lexers/matlab.lua
+share/vis/lexers/mediawiki.lua
share/vis/lexers/meson.lua
share/vis/lexers/moonscript.lua
share/vis/lexers/myrddin.lua
@@ -108,7 +1
Re: UPDATE: mail/mlmmj
Indeed.
This builds and installs ok.
I fixed the HOMEPAGE which has the same typo :-)
Makefile.am patch was removed because ... Makefile.in
ok to commit ?
May 3, 2024 11:49 AM, "Stuart Henderson" wrote:
> On 2024/05/02 21:27, gil...@poolp.org wrote:
>
>> Hello,
>>
>> Hopefully I didn't completely mess up this port, I'm a bit rusty.
>>
>> This bumps mlmmj from 1.3.0 to 1.4.5.
>>
>> Tested on the opensmtpd mailing list this afternoon.
>>
>> Gilles
>>
>> Index: Makefile
>> ===
>> RCS file: /cvs/ports/mail/mlmmj/Makefile,v
>> diff -u -p -r1.26 Makefile
>> --- Makefile 26 Sep 2023 12:28:13 - 1.26
>> +++ Makefile 2 May 2024 21:21:28 -
>> @@ -1,19 +1,27 @@
>> COMMENT= mailing list manager
>>
>> -DISTNAME= mlmmj-1.3.0
>> +V= 1.4.5
>> REVISION= 0
>
> drop REVISION for updates
>
>> +
>> +DISTNAME= mlmmj-${V}
>> +
>> CATEGORIES= mail
>>
>> -HOMEPAGE= http://mlmmj.org
>> +HOMEPAGE= htts://codeberg.org/mlmmj/mlmmj
>
> typo, htts -> https
>
>> # MIT
>> PERMIT_PACKAGE= Yes
>>
>> WANTLIB += c iconv
>>
>> -SITES= http://mlmmj.org/releases
>> +SITES=
>> https://codeberg.org/mlmmj/mlmmj/releases/download/RELEASE_${V:S/./_/g}
>> +
>> +BUILD_DEPENDS= devel/kyua-cli \
>> + devel/atf
>
> kyua-cli already depends on atf
>
>> LIB_DEPENDS= converters/libiconv
>> +
>> +AUTOCONF_VERSION= 2.69
>
> this isn't used with CONFIGURE_STYLE=gnu
>
> patch-include_mlmmj_h needs removing, PLIST needs an update too
> ("make update-plist"), and the patch filenames don't match what "make
> update-patches" gives you.
>
> Here's a version with those fixes. I don't run mlmmj but with this
> it should be ok.
>
> Index: Makefile
> ===
> RCS file: /cvs/ports/mail/mlmmj/Makefile,v
> diff -u -p -r1.26 Makefile
> --- Makefile 26 Sep 2023 12:28:13 - 1.26
> +++ Makefile 3 May 2024 09:47:33 -
> @@ -1,17 +1,21 @@
> COMMENT= mailing list manager
>
> -DISTNAME= mlmmj-1.3.0
> -REVISION= 0
> +V= 1.4.5
> +
> +DISTNAME= mlmmj-${V}
> +
> CATEGORIES= mail
>
> -HOMEPAGE= http://mlmmj.org
> +HOMEPAGE= htts://codeberg.org/mlmmj/mlmmj
>
> # MIT
> PERMIT_PACKAGE= Yes
>
> WANTLIB += c iconv
>
> -SITES= http://mlmmj.org/releases
> +SITES=
> https://codeberg.org/mlmmj/mlmmj/releases/download/RELEASE_${V:S/./_/g}
> +
> +BUILD_DEPENDS= devel/kyua-cli
>
> LIB_DEPENDS= converters/libiconv
>
> Index: distinfo
> ===
> RCS file: /cvs/ports/mail/mlmmj/distinfo,v
> diff -u -p -r1.12 distinfo
> --- distinfo 28 Nov 2017 03:43:07 - 1.12
> +++ distinfo 3 May 2024 09:47:33 -
> @@ -1,2 +1,2 @@
> -SHA256 (mlmmj-1.3.0.tar.gz) = dgnQ3YBPDAhMLkg+tYxgAStpi8dkZFN4UqHuH/nG8Ok=
> -SIZE (mlmmj-1.3.0.tar.gz) = 355298
> +SHA256 (mlmmj-1.4.5.tar.gz) = UluUL2mGZmdubon/3KbdvDBlSsNp3ux/z27RBVyH6Aw=
> +SIZE (mlmmj-1.4.5.tar.gz) = 465064
> Index: patches/patch-Makefile_am
> ===
> RCS file: patches/patch-Makefile_am
> diff -N patches/patch-Makefile_am
> --- /dev/null 1 Jan 1970 00:00:00 -
> +++ patches/patch-Makefile_am 3 May 2024 09:47:33 -
> @@ -0,0 +1,12 @@
> +Index: Makefile.am
> +--- Makefile.am.orig
> Makefile.am
> +@@ -30,7 +30,7 @@ tests_mlmmj_SOURCES = \
> + tests/mlmmj_tests.c
> + tests_mlmmj_LDADD = \
> + $(top_builddir)/src/libmlmmj.a \
> +- @ATF_LIBS@ -lrt
> ++ @ATF_LIBS@
> +
> + tests_fakesmtpd_SOURCES = \
> + tests/fakesmtpd.c
> Index: patches/patch-Makefile_in
> ===
> RCS file: patches/patch-Makefile_in
> diff -N patches/patch-Makefile_in
> --- /dev/null 1 Jan 1970 00:00:00 -
> +++ patches/patch-Makefile_in 3 May 2024 09:47:33 -
> @@ -0,0 +1,12 @@
> +Index: Makefile.in
> +--- Makefile.in.orig
> Makefile.in
> +@@ -420,7 +420,7 @@ SUBDIRS = src listtexts contrib
> +
> + @WANT_TESTS_TRUE@tests_mlmmj_LDADD = \
> + @WANT_TESTS_TRUE@ $(top_builddir)/src/libmlmmj.a \
> +-@WANT_TESTS_TRUE@ @ATF_LIBS@ -lrt
> ++@WANT_TESTS_TRUE@ @ATF_LIBS@
> +
> + @WANT_TESTS_TRUE@tests_fakesmtpd_SOURCES = \
> + @WANT_TESTS_TRUE@ tests/fakesmtpd.c
> Index: patches/patch-include_mlmmj_h
> ===
> RCS file: patches/patch-include_mlmmj_h
> diff -N patches/patch-include_mlmmj_h
> --- patches/patch-include_mlmmj_h 11 Mar 2022 19:34:42 - 1.2
> +++ /dev/null 1 Jan 1970 00:00:00 -
> @@ -1,24 +0,0 @@
> -Fix build with "-fno-common", from FreeBSD.
> -https://gitlab.com/mlmmj/mlmmj/-/merge_requests/2
> -
> -Index: include/mlmmj.h
> include/mlmmj.h.orig
> -+++ include/mlmmj.h
> -@@ -81,7 +81,7 @@ enum subtype {
> - SUB_NONE /* For when an address is not subscribed at all */
> - };
> -
> --char *subtype_strs[7]; /* count matches enum above; defined in
> subscriberfuncs.c */
> -+extern char *subtype_strs[7]; /* count matches enum above; defined in
> subscri
Re: [PATCH] update print/texinfo to 7.1
On 2024/05/03 11:21, Stuart Henderson wrote:
> On 2024/05/02 09:46, Dima Pasechnik wrote:
> > A straightforward update; it appears that the patch has been merged
> > upstream (with a subsequent refactoring - one can find patched lines, in
> > a different file).
>
> Last time I tried updating texinfo it wasn't straightforward,
> but maybe something changed in the newer upstream versions.
> I'll have a look over this and try building dependent ports.
>
> > REVISION - I commented it out - correct?
>
> Just remove that when updating to a newer version.
>
This is the diff I'm using. The thing you ran into which you
worked-around with USE_GMAKE is related to SEPARATE_BUILD. Even with
gmake it wasn't working properly with that (no lib/texinfo/*.so files in
your updated PLIST).
Index: Makefile
===
RCS file: /cvs/ports/print/texinfo/Makefile,v
diff -u -p -r1.17 Makefile
--- Makefile27 Sep 2023 14:32:03 - 1.17
+++ Makefile3 May 2024 11:19:43 -
@@ -1,7 +1,6 @@
COMMENT = official documentation format of the GNU project
-DISTNAME = texinfo-6.5
-REVISION = 4
+DISTNAME = texinfo-7.1
CATEGORIES = print
@@ -22,7 +21,6 @@ TEST_DEPENDS =${RUN_DEPENDS}
FAKE_FLAGS = TEXMF=${PREFIX}/share/texmf-local
-SEPARATE_BUILD = Yes
LIBTOOL_FLAGS =--tag=disable-static
CONFIGURE_STYLE = gnu
CONFIGURE_ARGS = --program-prefix=g
Index: distinfo
===
RCS file: /cvs/ports/print/texinfo/distinfo,v
diff -u -p -r1.5 distinfo
--- distinfo18 Sep 2017 07:59:40 - 1.5
+++ distinfo3 May 2024 10:15:37 -
@@ -1,2 +1,2 @@
-SHA256 (texinfo-6.5.tar.gz) = 00Jy5AQsRhht3NZr1dmAwMoU/3NERGhsz4Ex9uyLFCc=
-SIZE (texinfo-6.5.tar.gz) = 9311787
+SHA256 (texinfo-7.1.tar.gz) =
dd5710b3a53ac002644677a06145748e260592a35be182dc830ebebb79c5d5a0
+SIZE (texinfo-7.1.tar.gz) = 12118819
Index: patches/patch-tp_Texinfo_Parser_pm
===
RCS file: patches/patch-tp_Texinfo_Parser_pm
diff -N patches/patch-tp_Texinfo_Parser_pm
--- patches/patch-tp_Texinfo_Parser_pm 11 Mar 2022 19:51:09 - 1.2
+++ /dev/null 1 Jan 1970 00:00:00 -
@@ -1,17 +0,0 @@
-Index: tp/Texinfo/Parser.pm
tp/Texinfo/Parser.pm.orig
-+++ tp/Texinfo/Parser.pm
-@@ -5478,11 +5478,11 @@ sub _parse_special_misc_command()
- }
- } elsif ($command eq 'clickstyle') {
- # REMACRO
--if ($line =~ /^\s+@([[:alnum:]][[:alnum:]\-]*)({})?\s*/) {
-+if ($line =~ /^\s+@([[:alnum:]][[:alnum:]\-]*)(\{\})?\s*/) {
- $args = ['@'.$1];
- $self->{'clickstyle'} = $1;
- $remaining = $line;
-- $remaining =~
s/^\s+@([[:alnum:]][[:alnum:]\-]*)({})?\s*(\@(c|comment)((\@|\s+).*)?)?//;
-+ $remaining =~
s/^\s+@([[:alnum:]][[:alnum:]\-]*)(\{\})?\s*(\@(c|comment)((\@|\s+).*)?)?//;
- $has_comment = 1 if (defined($4));
- } else {
- $self->line_error (sprintf($self->__(
Index: pkg/PLIST
===
RCS file: /cvs/ports/print/texinfo/pkg/PLIST,v
diff -u -p -r1.8 PLIST
--- pkg/PLIST 11 Mar 2022 19:51:09 - 1.8
+++ pkg/PLIST 3 May 2024 10:39:08 -
@@ -8,15 +8,19 @@ bin/gtexi2dvi
bin/gtexi2pdf
bin/gtexindex
info/ginfo-stnd.info
+info/gtexi2any_api.info
+info/gtexi2any_internals.info
info/gtexinfo.info
info/gtexinfo.info-1
info/gtexinfo.info-2
info/gtexinfo.info-3
lib/texinfo/
@comment lib/texinfo/MiscXS.la
-lib/texinfo/MiscXS.so
+@so lib/texinfo/MiscXS.so
+@comment lib/texinfo/Parsetexi.la
+@so lib/texinfo/Parsetexi.so
@comment lib/texinfo/XSParagraph.la
-lib/texinfo/XSParagraph.so
+@so lib/texinfo/XSParagraph.so
@man man/man1/ginfo.1
@man man/man1/ginstall-info.1
@man man/man1/gmakeinfo.1
@@ -36,21 +40,18 @@ share/locale/ca/LC_MESSAGES/texinfo_docu
share/locale/cs/LC_MESSAGES/texinfo.mo
share/locale/cs/LC_MESSAGES/texinfo_document.mo
share/locale/da/LC_MESSAGES/texinfo.mo
-share/locale/da/LC_MESSAGES/texinfo_document.mo
share/locale/de.us-ascii/
share/locale/de.us-ascii/LC_MESSAGES/
share/locale/de.us-ascii/LC_MESSAGES/texinfo_document.mo
share/locale/de/LC_MESSAGES/texinfo.mo
share/locale/de/LC_MESSAGES/texinfo_document.mo
-share/locale/de_AT/
-share/locale/de_AT/LC_MESSAGES/
-share/locale/de_AT/LC_MESSAGES/texinfo.mo
share/locale/el/LC_MESSAGES/texinfo.mo
-share/locale/el/LC_MESSAGES/texinfo_document.mo
share/locale/eo/LC_MESSAGES/texinfo.mo
share/locale/eo/LC_MESSAGES/texinfo_document.mo
share/locale/es/LC_MESSAGES/texinfo.mo
share/locale/es/LC_MESSAGES/texinfo_document.mo
+share/locale/fi/LC_MESSAGES/texinfo.mo
+share/locale/fi/LC_MESSAGES/texinfo_document.mo
share/locale/fr/LC_MESSAGES/texinfo.mo
share/locale/fr/LC_MESSAGES/texinfo_document.mo
share/locale/he/LC_MESSAGES/texinfo.mo
@@ -62,17 +63,22 @@ share/l
Re: [PATCH] update print/texinfo to 7.1
On 2024/05/02 09:46, Dima Pasechnik wrote: > A straightforward update; it appears that the patch has been merged > upstream (with a subsequent refactoring - one can find patched lines, in > a different file). Last time I tried updating texinfo it wasn't straightforward, but maybe something changed in the newer upstream versions. I'll have a look over this and try building dependent ports. > REVISION - I commented it out - correct? Just remove that when updating to a newer version.
Re: UPDATE: mail/mlmmj
On 2024/05/02 21:27, gil...@poolp.org wrote:
> Hello,
>
> Hopefully I didn't completely mess up this port, I'm a bit rusty.
>
> This bumps mlmmj from 1.3.0 to 1.4.5.
>
> Tested on the opensmtpd mailing list this afternoon.
>
> Gilles
>
>
> Index: Makefile
> ===
> RCS file: /cvs/ports/mail/mlmmj/Makefile,v
> diff -u -p -r1.26 Makefile
> --- Makefile 26 Sep 2023 12:28:13 - 1.26
> +++ Makefile 2 May 2024 21:21:28 -
> @@ -1,19 +1,27 @@
> COMMENT= mailing list manager
>
> -DISTNAME=mlmmj-1.3.0
> +V= 1.4.5
> REVISION=0
drop REVISION for updates
> +
> +DISTNAME=mlmmj-${V}
> +
> CATEGORIES= mail
>
> -HOMEPAGE=http://mlmmj.org/
> +HOMEPAGE=htts://codeberg.org/mlmmj/mlmmj
typo, htts -> https
>
> # MIT
> PERMIT_PACKAGE= Yes
>
> WANTLIB += c iconv
>
> -SITES= http://mlmmj.org/releases/
> +SITES=
> https://codeberg.org/mlmmj/mlmmj/releases/download/RELEASE_${V:S/./_/g}/
> +
> +BUILD_DEPENDS= devel/kyua-cli \
> + devel/atf
kyua-cli already depends on atf
> LIB_DEPENDS= converters/libiconv
> +
> +AUTOCONF_VERSION=2.69
this isn't used with CONFIGURE_STYLE=gnu
patch-include_mlmmj_h needs removing, PLIST needs an update too
("make update-plist"), and the patch filenames don't match what "make
update-patches" gives you.
Here's a version with those fixes. I don't run mlmmj but with this
it should be ok.
Index: Makefile
===
RCS file: /cvs/ports/mail/mlmmj/Makefile,v
diff -u -p -r1.26 Makefile
--- Makefile26 Sep 2023 12:28:13 - 1.26
+++ Makefile3 May 2024 09:47:33 -
@@ -1,17 +1,21 @@
COMMENT= mailing list manager
-DISTNAME= mlmmj-1.3.0
-REVISION= 0
+V= 1.4.5
+
+DISTNAME= mlmmj-${V}
+
CATEGORIES=mail
-HOMEPAGE= http://mlmmj.org/
+HOMEPAGE= htts://codeberg.org/mlmmj/mlmmj
# MIT
PERMIT_PACKAGE=Yes
WANTLIB += c iconv
-SITES= http://mlmmj.org/releases/
+SITES=
https://codeberg.org/mlmmj/mlmmj/releases/download/RELEASE_${V:S/./_/g}/
+
+BUILD_DEPENDS= devel/kyua-cli
LIB_DEPENDS= converters/libiconv
Index: distinfo
===
RCS file: /cvs/ports/mail/mlmmj/distinfo,v
diff -u -p -r1.12 distinfo
--- distinfo28 Nov 2017 03:43:07 - 1.12
+++ distinfo3 May 2024 09:47:33 -
@@ -1,2 +1,2 @@
-SHA256 (mlmmj-1.3.0.tar.gz) = dgnQ3YBPDAhMLkg+tYxgAStpi8dkZFN4UqHuH/nG8Ok=
-SIZE (mlmmj-1.3.0.tar.gz) = 355298
+SHA256 (mlmmj-1.4.5.tar.gz) = UluUL2mGZmdubon/3KbdvDBlSsNp3ux/z27RBVyH6Aw=
+SIZE (mlmmj-1.4.5.tar.gz) = 465064
Index: patches/patch-Makefile_am
===
RCS file: patches/patch-Makefile_am
diff -N patches/patch-Makefile_am
--- /dev/null 1 Jan 1970 00:00:00 -
+++ patches/patch-Makefile_am 3 May 2024 09:47:33 -
@@ -0,0 +1,12 @@
+Index: Makefile.am
+--- Makefile.am.orig
Makefile.am
+@@ -30,7 +30,7 @@ tests_mlmmj_SOURCES = \
+ tests/mlmmj_tests.c
+ tests_mlmmj_LDADD = \
+ $(top_builddir)/src/libmlmmj.a \
+- @ATF_LIBS@ -lrt
++ @ATF_LIBS@
+
+ tests_fakesmtpd_SOURCES = \
+ tests/fakesmtpd.c
Index: patches/patch-Makefile_in
===
RCS file: patches/patch-Makefile_in
diff -N patches/patch-Makefile_in
--- /dev/null 1 Jan 1970 00:00:00 -
+++ patches/patch-Makefile_in 3 May 2024 09:47:33 -
@@ -0,0 +1,12 @@
+Index: Makefile.in
+--- Makefile.in.orig
Makefile.in
+@@ -420,7 +420,7 @@ SUBDIRS = src listtexts contrib
+
+ @WANT_TESTS_TRUE@tests_mlmmj_LDADD = \
+ @WANT_TESTS_TRUE@ $(top_builddir)/src/libmlmmj.a \
+-@WANT_TESTS_TRUE@ @ATF_LIBS@ -lrt
++@WANT_TESTS_TRUE@ @ATF_LIBS@
+
+ @WANT_TESTS_TRUE@tests_fakesmtpd_SOURCES = \
+ @WANT_TESTS_TRUE@ tests/fakesmtpd.c
Index: patches/patch-include_mlmmj_h
===
RCS file: patches/patch-include_mlmmj_h
diff -N patches/patch-include_mlmmj_h
--- patches/patch-include_mlmmj_h 11 Mar 2022 19:34:42 - 1.2
+++ /dev/null 1 Jan 1970 00:00:00 -
@@ -1,24 +0,0 @@
-Fix build with "-fno-common", from FreeBSD.
-https://gitlab.com/mlmmj/mlmmj/-/merge_requests/2
-
-Index: include/mlmmj.h
include/mlmmj.h.orig
-+++ include/mlmmj.h
-@@ -81,7 +81,7 @@ enum subtype {
- SUB_NONE /* For when an address is not subscribed at all */
- };
-
--char *subtype_strs[7]; /* count matches enum above; defined in
subscriberfuncs.c */
-+extern char *subtype_strs[7]; /* count matches enum above; defined in
subscriberfuncs.c */
-
- enum subreason {
- SUB_REQUEST,
-@@ -92,7 +92,7 @@ enum subreason {
- SUB_SWITCH
- };
-
--char * subreason_strs[6]; /* count matches enum above; defined in
subscrib
transmission_daemon silently freeze?
i'm sorry for bothering. my transmission_daemon freezes for unknown reason, I wanted to know is this some bug or troubles with my hardware? Freezes happens after day or so. rcctl and ps both show me that daemon is running, but i can't connect to web ui and torrents are not downloading or uploading this is frozen daemon: mx$ curl -v gw:9091 * Host gw:9091 was resolved. * IPv6: (none) * IPv4: 192.168.0.1 * Trying 192.168.0.1:9091... * Connected to gw (192.168.0.1) port 9091 > GET / HTTP/1.1 > Host: gw:9091 > User-Agent: curl/8.7.1 > Accept: */* > * Request completely sent off ^C and after restarting it, it works as should: mx$ doas rcctl restart transmission_daemon transmission_daemon(ok) transmission_daemon(ok) mx$ curl -v gw:9091 * Host gw:9091 was resolved. * IPv6: (none) * IPv4: 192.168.0.1 * Trying 192.168.0.1:9091... * Connected to gw (192.168.0.1) port 9091 > GET / HTTP/1.1 > Host: gw:9091 > User-Agent: curl/8.7.1 > Accept: */* > * Request completely sent off < HTTP/1.1 301 Moved Permanently < Server: Transmission < Access-Control-Allow-Origin: * < Location: /transmission/web/ < Date: Fri, 03 May 2024 08:03:26 GMT < Content-Length: 31 < Content-Type: text/html; charset=ISO-8859-1 < * Connection #0 to host gw left intact 301: Moved Permanentlymx$ i think this behavior appeared since 7.5. Am I alone with this or maybe someone hit this too? And I forgot to mention, no logs from transmission_daemon appearing before or after freeze
Re: update devel/fossil
On 2024/05/03 09:38, Stuart Henderson wrote: > On 2024/05/03 09:22, Solene Rapenne wrote: > > this updates fossil to latest version, > > changelog available > > https://fossil-scm.org/home/doc/trunk/www/changes.wiki#v2_24 > > > > ok? > > > > diff --git a/devel/fossil/Makefile b/devel/fossil/Makefile > > index fb869e9fa31..1311dd4fd49 100644 > > --- a/devel/fossil/Makefile > > +++ b/devel/fossil/Makefile > > @@ -1,7 +1,6 @@ > > COMMENT = simple distributed software configuration management > > > > -DISTNAME = fossil-2.23 > > -EPOCH =0 > > EPOCH cannot be removed you could say, it is fossilized... > > +DISTNAME = fossil-2.24 > > CATEGORIES = devel www > > > > MAINTAINER = James Turner > > diff --git a/devel/fossil/distinfo b/devel/fossil/distinfo > > index 6eaaf2a218f..eec4ebdd1f7 100644 > > --- a/devel/fossil/distinfo > > +++ b/devel/fossil/distinfo > > @@ -1,2 +1,2 @@ > > -SHA256 (fossil-2.23.tar.gz) = dfgI6BNRAYqXFnRtnvGh/huxkEcz6LQYZDiB04GYhZM= > > -SIZE (fossil-2.23.tar.gz) = 6798900 > > +SHA256 (fossil-2.24.tar.gz) = 7bXPKgf4FBDPUjl+DoQVWKp4qJFsYmin9xH2IXPYXMk= > > +SIZE (fossil-2.24.tar.gz) = 6798925 > >
Re: update devel/fossil
On 2024/05/03 09:22, Solene Rapenne wrote: > this updates fossil to latest version, > changelog available > https://fossil-scm.org/home/doc/trunk/www/changes.wiki#v2_24 > > ok? > > diff --git a/devel/fossil/Makefile b/devel/fossil/Makefile > index fb869e9fa31..1311dd4fd49 100644 > --- a/devel/fossil/Makefile > +++ b/devel/fossil/Makefile > @@ -1,7 +1,6 @@ > COMMENT =simple distributed software configuration management > > -DISTNAME = fossil-2.23 > -EPOCH = 0 EPOCH cannot be removed > +DISTNAME = fossil-2.24 > CATEGORIES = devel www > > MAINTAINER = James Turner > diff --git a/devel/fossil/distinfo b/devel/fossil/distinfo > index 6eaaf2a218f..eec4ebdd1f7 100644 > --- a/devel/fossil/distinfo > +++ b/devel/fossil/distinfo > @@ -1,2 +1,2 @@ > -SHA256 (fossil-2.23.tar.gz) = dfgI6BNRAYqXFnRtnvGh/huxkEcz6LQYZDiB04GYhZM= > -SIZE (fossil-2.23.tar.gz) = 6798900 > +SHA256 (fossil-2.24.tar.gz) = 7bXPKgf4FBDPUjl+DoQVWKp4qJFsYmin9xH2IXPYXMk= > +SIZE (fossil-2.24.tar.gz) = 6798925 >
[new] devel/compiledb: compile_commands.json generator (also works with the kernel)
I wasn't able to google how to generate compile_commands.json file for the kernel to make clangd/LSP/vim work. It looks like the most used tool is a bear (https://github.com/rizsotto/Bear), but during initial porting efforts I found out that it doesn't work, I got constant crashes and pinsyscalls messages in dmesg. compiledb is a much simpler python tool which parses gmake logs and generates compile_commands.json file, it also works fine with the OpenBSD kernel, which was the main motivation, I also tried jumping around emacs sources - works fine, using option 3 from the README. Fail of option 2 for emacs is documented in make.py file of the distribution, but I wasn't able to make the workaround fix it, given the option 3, which works, seems not a bid deal? Thoughts? $ pkg_info compiledb-0.10.1 Information for inst:compiledb-0.10.1 Comment: compile_commands.json generator Description: Tool for generating Clang's JSON Compilation Database file for GNU make-based build systems. Maintainer: The OpenBSD ports mailing-list WWW: https://github.com/nickdiego/compiledb $ cat /usr/local/share/doc/pkg-readmes/compiledb +--- | Running compiledb on OpenBSD +--- compiledb supports only gmake for native compile_commands.json file generation, but you can try to feed usual make output to it through a pipe, or --parse option. Examples: 1) To make compile_commands.json file for OpenBSD kernel use: cd /sys/arch/$(machine)/compile/GENERIC.MP make -n | compiledb mv compile_commands.json /sys 2) To get compilation db for another software, which uses gmake pass -c option for make subcommand: cd ~/work/software compiledb -n make -c gmake 3) Above command runs 'gmake -Bnwk' and parses output, if your software uses autotools and enters endless ./configure stage, try removing -B switch and pipe the output without it: gmake -nwk | compiledb compiledb.tgz Description: application/gtar-compressed
update devel/fossil
this updates fossil to latest version, changelog available https://fossil-scm.org/home/doc/trunk/www/changes.wiki#v2_24 ok? diff --git a/devel/fossil/Makefile b/devel/fossil/Makefile index fb869e9fa31..1311dd4fd49 100644 --- a/devel/fossil/Makefile +++ b/devel/fossil/Makefile @@ -1,7 +1,6 @@ COMMENT = simple distributed software configuration management -DISTNAME = fossil-2.23 -EPOCH =0 +DISTNAME = fossil-2.24 CATEGORIES = devel www MAINTAINER = James Turner diff --git a/devel/fossil/distinfo b/devel/fossil/distinfo index 6eaaf2a218f..eec4ebdd1f7 100644 --- a/devel/fossil/distinfo +++ b/devel/fossil/distinfo @@ -1,2 +1,2 @@ -SHA256 (fossil-2.23.tar.gz) = dfgI6BNRAYqXFnRtnvGh/huxkEcz6LQYZDiB04GYhZM= -SIZE (fossil-2.23.tar.gz) = 6798900 +SHA256 (fossil-2.24.tar.gz) = 7bXPKgf4FBDPUjl+DoQVWKp4qJFsYmin9xH2IXPYXMk= +SIZE (fossil-2.24.tar.gz) = 6798925
