Re: NEW: fonts/recursive 1.085
> > Renato Aguiar writes: > > > Recursive Sans & Mono is a variable type family built for better > > > code & UI. > > > > > > https://www.recursive.design/ > > > > > > https://github.com/arrowtype/recursive > > > > > > Port attached. Imported. Thanks!
CVS: cvs.openbsd.org: ports
CVSROOT:/cvs Module name:ports Changes by: bent...@cvs.openbsd.org 2023/09/11 23:35:49 Modified files: fonts : Makefile Log message: +recursive
CVS: cvs.openbsd.org: ports
CVSROOT:/cvs Module name:ports Changes by: bent...@cvs.openbsd.org 2023/09/11 23:34:43 Log message: Import recursive-1.085. Recursive Sans & Mono is a variable type family built for better code & UI. It is inspired by casual script signpainting, but designed primarily to meet the needs of programming environments and application interfaces. From Renato Aguiar; thanks! ok op@ Status: Vendor Tag: bentley Release Tags: bentley_20230911 N ports/fonts/recursive/Makefile N ports/fonts/recursive/distinfo N ports/fonts/recursive/pkg/PLIST N ports/fonts/recursive/pkg/DESCR No conflicts created by this import
Re: UPDATE: objfw-1.0.2
On Mon, Sep 11 2023, Jonathan Schleifer wrote: > Am 11.09.23 um 13:01 schrieb Jeremie Courreges-Anglas: > >> This diff and the previous one were likely mangled by your MUA. There >> are hints available: >> https://www.kernel.org/doc/html/latest/process/email-clients.html >> Or you may just send diffs as attachments (inline is still preferred). > > Ah, sorry about that. I'll double check next time. > >> Using /usr/src/lib/check_sym I can spot: >> /usr/local/lib/libobjfwtls.so.0.0 --> >> /usr/obj/pobj/objfw-1.0.2/fake-amd64/usr/local/lib/libobjfwtls.so.0.0 >> Dynamic export changes: >> added: >> .objc_sel_nameof_isWaitingForDelimiter >> Applying blindly our rules for shared libraries, this would warrant >> a minor bump because of the additional interface. But maybe the initial >> '.' in the name means it's a local, private symbol? nm -g tells me it's >> a weak symbol so with public visibility. Insights welcome. > > Nope, this shouldn't be a bump. libobjfwtls.so.0.0 subclasses > OFTLSStream from libobjfw.so.0.0 as OFOpenSSLTLSStream. What's new is > that it overrides the private method of_isWaitingForDelimiter. It > shouldn't override a private method, yes, but for now, that is the fix > without changing the API/ABI and can be done since I control both libs. > This works due to the dynamic dispatch. The > .objc_sel_nameof_isWaitingForDelimiter is merely a new symbol that > provides the string for the selector that gets registered with the > runtime so it can be overridden. It's references by the > .objc_method_list that is in turn referenced by the class structure that > is in turn referenced by the ObjC module that is passed to __objc_exec > via a constructor to register all classes, categories and selectors in > the module with the runtime. > > libobjfwtls in turn sets the global variable OFTLSStreamImplementation > in libobjfw via the +load method of OFOpenSSLTLSStream, which in turn > gets called by the runtime via this chain started by __objc_exec, at > which point libobjfw knows to use OFOpenSSLTLSStream when an OFTLSStream > is requested. The only way someone interfaces with libobjfwtls is by > linking it in and not referencing any symbols from it. > > Hope that explains :). All these structures are emitted by the compiler > automatically. You can find a declaration of those structs emitted by > the compiler here: > https://objfw.nil.im/file?name=src/runtime/private.h=trunk > > Or, tl;dr: A method that existed before was overridden in a subclass. > Because ObjC uses dynamic dispatch, this symbol is never referenced, as > all method calls are dispatched via the runtime. But the metadata > changes so the runtime knows this method is now overridden - without > accessing that symbol. Thanks for the long explanation, I'll take your word about this. Update committed, thanks! -- jca | PGP : 0x1524E7EE / 5135 92C1 AD36 5293 2BDF DDCC 0DFA 74AE 1524 E7EE
CVS: cvs.openbsd.org: ports
CVSROOT:/cvs Module name:ports Changes by: j...@cvs.openbsd.org2023/09/11 22:59:02 Modified files: devel/objfw: Makefile distinfo Removed files: devel/objfw/patches: patch-buildsys_mk_in Log message: Update to objfw-1.0.2 >From maintainer Jonathan Schleifer
CVS: cvs.openbsd.org: ports
CVSROOT:/cvs Module name:ports Changes by: dan...@cvs.openbsd.org 2023/09/11 22:00:10 Modified files: devel/py-rope : Makefile distinfo Log message: update to py-rope 1.0.0
ipython 8.8.0 -> 8.13.2
spyder 5.4.5 requires a newer version of ipython, claiming that a number
of releases in the 8.x series are buggy.
All reverse deps for ipython still build after this update.
ok?
Index: Makefile
===
RCS file: /cvs/ports/devel/ipython/Makefile,v
retrieving revision 1.76
diff -u -p -u -r1.76 Makefile
--- Makefile4 Jan 2023 10:02:31 - 1.76
+++ Makefile12 Sep 2023 03:35:45 -
@@ -1,6 +1,6 @@
COMMENT = enhanced interactive Python shell
-MODPY_EGG_VERSION =8.8.0
+MODPY_EGG_VERSION =8.13.2
DISTNAME = ipython-${MODPY_EGG_VERSION}
PKGNAME = ipython${MODPY_MAJOR_VERSION}-${MODPY_EGG_VERSION}
@@ -26,11 +26,11 @@ RUN_DEPENDS = databases/py-pickleshare$
devel/py-decorator${MODPY_FLAVOR} \
devel/py-jedi${MODPY_FLAVOR}>=0.16 \
devel/py-pexpect${MODPY_FLAVOR}>=4.3 \
-
devel/py-prompt_toolkit${MODPY_FLAVOR}>=2.0.0v1,<3.1.0v1 \
+
devel/py-prompt_toolkit${MODPY_FLAVOR}>=3.0.30v1,<3.1.0v1 \
devel/py-stack_data${MODPY_FLAVOR} \
- devel/py-traitlets${MODPY_FLAVOR}>=4.2 \
+ devel/py-traitlets${MODPY_FLAVOR}>=5 \
graphics/py-matplotlib-inline${MODPY_FLAVOR} \
- textproc/py-pygments${MODPY_FLAVOR}
+ textproc/py-pygments${MODPY_FLAVOR}>=2.4.0
# Note that if you have pdb++ installed, tests will fail.
TEST_DEPENDS = devel/py-ipykernel${MODPY_FLAVOR} \
Index: distinfo
===
RCS file: /cvs/ports/devel/ipython/distinfo,v
retrieving revision 1.37
diff -u -p -u -r1.37 distinfo
--- distinfo4 Jan 2023 10:02:31 - 1.37
+++ distinfo12 Sep 2023 03:35:45 -
@@ -1,2 +1,2 @@
-SHA256 (ipython-8.8.0.tar.gz) = 878sCFBa0sP07VxGrgMxqFR9Nr9LIaRR6K6AwHkduVs=
-SIZE (ipython-8.8.0.tar.gz) = 5341086
+SHA256 (ipython-8.13.2.tar.gz) = ff8/rTK5f2SI4C+HuXDzCdCC91jXt/wlLjsZ7g5DLbs=
+SIZE (ipython-8.13.2.tar.gz) = 5467542
Index: patches/patch-IPython_core_tests_test_interactiveshell_py
===
RCS file:
/cvs/ports/devel/ipython/patches/patch-IPython_core_tests_test_interactiveshell_py,v
retrieving revision 1.10
diff -u -p -u -r1.10 patch-IPython_core_tests_test_interactiveshell_py
--- patches/patch-IPython_core_tests_test_interactiveshell_py 4 Jan 2023
10:02:31 - 1.10
+++ patches/patch-IPython_core_tests_test_interactiveshell_py 12 Sep 2023
03:35:45 -
@@ -1,7 +1,7 @@
Index: IPython/core/tests/test_interactiveshell.py
--- IPython/core/tests/test_interactiveshell.py.orig
+++ IPython/core/tests/test_interactiveshell.py
-@@ -620,7 +620,7 @@ class TestSystemRaw(ExitCodeChecks):
+@@ -646,7 +646,7 @@ class TestSystemRaw(ExitCodeChecks):
def test_1(self):
"""Test system_raw with non-ascii cmd
"""
Index: pkg/PLIST
===
RCS file: /cvs/ports/devel/ipython/pkg/PLIST,v
retrieving revision 1.30
diff -u -p -u -r1.30 PLIST
--- pkg/PLIST 4 Jan 2023 10:02:31 - 1.30
+++ pkg/PLIST 12 Sep 2023 03:35:46 -
@@ -518,8 +518,6 @@ lib/python${MODPY_VERSION}/site-packages
lib/python${MODPY_VERSION}/site-packages/IPython/terminal/${MODPY_PYCACHE}prompts.${MODPY_PYC_MAGIC_TAG}pyc
lib/python${MODPY_VERSION}/site-packages/IPython/terminal/${MODPY_PYCACHE}ptutils.${MODPY_PYC_MAGIC_TAG}${MODPY_PYOEXTENSION}
lib/python${MODPY_VERSION}/site-packages/IPython/terminal/${MODPY_PYCACHE}ptutils.${MODPY_PYC_MAGIC_TAG}pyc
-lib/python${MODPY_VERSION}/site-packages/IPython/terminal/${MODPY_PYCACHE}shortcuts.${MODPY_PYC_MAGIC_TAG}${MODPY_PYOEXTENSION}
-lib/python${MODPY_VERSION}/site-packages/IPython/terminal/${MODPY_PYCACHE}shortcuts.${MODPY_PYC_MAGIC_TAG}pyc
lib/python${MODPY_VERSION}/site-packages/IPython/terminal/console.py
lib/python${MODPY_VERSION}/site-packages/IPython/terminal/debugger.py
lib/python${MODPY_VERSION}/site-packages/IPython/terminal/embed.py
@@ -563,7 +561,20 @@ lib/python${MODPY_VERSION}/site-packages
lib/python${MODPY_VERSION}/site-packages/IPython/terminal/pt_inputhooks/tk.py
lib/python${MODPY_VERSION}/site-packages/IPython/terminal/pt_inputhooks/wx.py
lib/python${MODPY_VERSION}/site-packages/IPython/terminal/ptutils.py
-lib/python${MODPY_VERSION}/site-packages/IPython/terminal/shortcuts.py
+lib/python${MODPY_VERSION}/site-packages/IPython/terminal/shortcuts/
+lib/python${MODPY_VERSION}/site-packages/IPython/terminal/shortcuts/__init__.py
+${MODPY_COMMENT}lib/python${MODPY_VERSION}/site-packages/IPython/terminal/shortcuts/${MODPY_PYCACHE}/
+lib/python${MODPY_VERSION}/site-packages/IPython/terminal/shortcuts/${MODPY_PYCACHE}__init__.${MODPY_PYC_MAGIC_TAG}${MODPY_PYOEXTENSION}
update ocamlbuild to 0.14.2
The latest ocamlbuild claims support for ocaml 5.x. Reverse deps still build. ok? Index: Makefile === RCS file: /cvs/ports/devel/ocaml-ocamlbuild/Makefile,v retrieving revision 1.14 diff -u -p -u -r1.14 Makefile --- Makefile24 Jul 2023 12:12:55 - 1.14 +++ Makefile12 Sep 2023 02:39:51 - @@ -3,8 +3,7 @@ CATEGORIES =devel GH_ACCOUNT = ocaml GH_PROJECT = ocamlbuild -GH_TAGNAME = 0.14.0 -REVISION = 5 +GH_TAGNAME = 0.14.2 # LGPLv2.1+ PERMIT_PACKAGE = Yes Index: distinfo === RCS file: /cvs/ports/devel/ocaml-ocamlbuild/distinfo,v retrieving revision 1.3 diff -u -p -u -r1.3 distinfo --- distinfo19 Jun 2019 09:18:18 - 1.3 +++ distinfo12 Sep 2023 02:39:51 - @@ -1,2 +1,2 @@ -SHA256 (ocamlbuild-0.14.0.tar.gz) = h7Kc6WlYCWwKGo7q/rYmgHey0R4b8rPeD168nPjULng= -SIZE (ocamlbuild-0.14.0.tar.gz) = 198267 +SHA256 (ocamlbuild-0.14.2.tar.gz) = YtLatgN3lMcCqDrFhKcGbQGM8WRTcNHz1XZMK0WHkbE= +SIZE (ocamlbuild-0.14.2.tar.gz) = 199293 Index: patches/patch-Makefile === RCS file: /cvs/ports/devel/ocaml-ocamlbuild/patches/patch-Makefile,v retrieving revision 1.2 diff -u -p -u -r1.2 patch-Makefile --- patches/patch-Makefile 11 Mar 2022 18:50:53 - 1.2 +++ patches/patch-Makefile 12 Sep 2023 02:39:51 - @@ -2,11 +2,11 @@ Index: Makefile --- Makefile.orig +++ Makefile @@ -93,7 +93,7 @@ INSTALL_LIB=\ - src/ocamlbuildlib.cma \ - src/ocamlbuild.cmo \ + plugin-lib/ocamlbuildlib.cma \ + bin/ocamlbuild.cmo \ src/ocamlbuild_pack.cmi \ - $(EXTRA_CMO:.cmo=.cmi) + $(EXTRA_CMO) $(EXTRA_CMO:.cmo=.cmi) INSTALL_LIB_OPT=\ - src/ocamlbuildlib.cmxa src/ocamlbuildlib$(EXT_LIB) \ + plugin-lib/ocamlbuildlib.cmxa plugin-lib/ocamlbuildlib$(EXT_LIB) \
CVS: cvs.openbsd.org: ports
CVSROOT:/cvs Module name:ports Changes by: i...@cvs.openbsd.org2023/09/11 18:49:30 Modified files: cad: Makefile Log message: Link prusaslicer.
CVS: cvs.openbsd.org: ports
CVSROOT:/cvs Module name:ports Changes by: i...@cvs.openbsd.org2023/09/11 18:46:56 Log message: Import PrusaSlicer 2.5.1. Port from Renato Aguiar. Tested & tweaks by Johannes Tishman; tested & OK ian@ jcs@ Status: Vendor Tag: ian Release Tags: ian_20230911 N ports/cad/prusaslicer/Makefile N ports/cad/prusaslicer/distinfo N ports/cad/prusaslicer/patches/patch-CMakeLists_txt N ports/cad/prusaslicer/patches/patch-src_CMakeLists_txt N ports/cad/prusaslicer/patches/patch-src_PrusaSlicer_cpp N ports/cad/prusaslicer/patches/patch-src_avrdude_libavrdude_h N ports/cad/prusaslicer/patches/patch-src_hints_HintsToPot_cpp N ports/cad/prusaslicer/patches/patch-src_libslic3r_CMakeLists_txt N ports/cad/prusaslicer/patches/patch-src_libslic3r_Thread_cpp N ports/cad/prusaslicer/patches/patch-src_occt_wrapper_CMakeLists_txt N ports/cad/prusaslicer/patches/patch-src_slic3r_CMakeLists_txt N ports/cad/prusaslicer/patches/patch-src_slic3r_GUI_GLCanvas3D_cpp N ports/cad/prusaslicer/patches/patch-src_slic3r_GUI_GUI_App_cpp N ports/cad/prusaslicer/patches/patch-tests_fff_print_test_data_cpp N ports/cad/prusaslicer/patches/patch-src_slic3r_GUI_InstanceCheck_cpp N ports/cad/prusaslicer/patches/patch-src_slic3r_GUI_Mouse3DController_cpp N ports/cad/prusaslicer/patches/patch-src_slic3r_GUI_OpenGLManager_cpp N ports/cad/prusaslicer/pkg/DESCR N ports/cad/prusaslicer/pkg/PLIST No conflicts created by this import
Re: REMOVE games/prboom-plus
On Sat, Sep 09, 2023 at 06:12:36AM -0300, Lucas de Sena wrote: > PrBoom+ development had long moved from SourceForge to Github[1][2], > so the ports include an old version of the source engine. > > The development, however has been discontinued in June this year; a > last maintainer version (v2.6.66) has been released; and the Github > repository has been archived:[3] Hey, $MAINTAINER here. This arose from me asking in an OpenBSD-relating gaming IRC channel if it was worth hanging on to prboom-plus anymore, as I couldn't find a reason. Lucas seemed to doublecheck everything and agree. Lucas, thanks for starting this thread. I am fine with moving this to the attic. Thanks, -Ryan > > > Hey people, > > > > I'd like to announce that I just tagged the PrBoom+ 2.6.66 release! > > > > https://github.com/coelckers/prboom-plus/releases/tag/v2.6.66 > > > > This is just a maintenance release to make the changes that have > > accumulated over the past 1.5 years available to all users who > > cannot build the sources themselves. Please do not mistake this > > as a sign of active development! > > > > Future development will continue to take place in DSDA-Doom [1]. > > Or, for those who like to stay closer to the original code base, > > check out JadingTsunami's PrBoomX [2]. > > > > [1] https://github.com/kraflab/dsda-doom > > [2] https://github.com/JadingTsunami/prboomX > > Quoting from the DoomWiki[4]: > > > The last update of active development was version 2.6.2, released on > > February 11, 2022. On June 20, 2023, maintenance version 2.6.66 was > > released which collects all changes committed after development > > discontinued. Three days later, the GitHub repository was archived. > > DSDA-Doom, a source engine based on PrBoom+ which has already been > ported to OpenBSD, is PrBoom+'s spiritual successor. Debian, for > example, changed prboom-plus into a transitional dummy package to > dsda-doom.[5] > > Therefore, since prboom-plus has been discontinued, should we remove > it from the ports? And recommend people to install dsda-doom instead? > > There is also PrBoomX[6], which is closer to the original code base, > although it seems to not have the new features dsda-doom adds on top > of PrBoom+. (I have never tried it, tho). > > [1]: https://www.doomworld.com/forum/topic/106866-prboom-2666-jun-20-2023/ > [2]: https://github.com/coelckers/prboom-plus > [3]: https://www.doomworld.com/forum/post/2662145 > [4]: https://doomwiki.org/wiki/PrBoom%2B > [5]: https://packages.debian.org/sid/games/prboom-plus > [6]: https://doomwiki.org/wiki/PrBoomX >
next update toward reviving spyder3
Smaller follow-on diff for the previous updates:
ipykernel 5.1.3 -> 5.3.0
spyder-kernels 1.8.1 -> 1.10.2
This gets us up to the minimum versions needed spyder 4.2.5.
Once these updates are in we can start importing a number of new ports
needed by spyder 4.x.
ok?
Index: devel/py-ipykernel/Makefile
===
RCS file: /cvs/ports/devel/py-ipykernel/Makefile,v
retrieving revision 1.17
diff -u -p -u -r1.17 Makefile
--- devel/py-ipykernel/Makefile 11 Sep 2023 21:00:04 - 1.17
+++ devel/py-ipykernel/Makefile 11 Sep 2023 22:49:10 -
@@ -1,6 +1,6 @@
COMMENT = IPython kernel for Jupyter
-MODPY_EGG_VERSION =5.1.3
+MODPY_EGG_VERSION =5.3.0
DISTNAME = ipykernel-${MODPY_EGG_VERSION}
PKGNAME = py-${DISTNAME}
Index: devel/py-ipykernel/distinfo
===
RCS file: /cvs/ports/devel/py-ipykernel/distinfo,v
retrieving revision 1.6
diff -u -p -u -r1.6 distinfo
--- devel/py-ipykernel/distinfo 11 Sep 2023 21:00:04 - 1.6
+++ devel/py-ipykernel/distinfo 11 Sep 2023 22:49:10 -
@@ -1,2 +1,2 @@
-SHA256 (ipykernel-5.1.3.tar.gz) = s2itE+23H6LbNnoB51WpJdf3XtXgn70/Bsheeo7xCKg=
-SIZE (ipykernel-5.1.3.tar.gz) = 103924
+SHA256 (ipykernel-5.3.0.tar.gz) = cxrbPyxOvK/1LhCoVd3IdnA1monJx4TXEeYtZvzNr64=
+SIZE (ipykernel-5.3.0.tar.gz) = 110977
Index: devel/py-ipykernel/pkg/PLIST
===
RCS file: /cvs/ports/devel/py-ipykernel/pkg/PLIST,v
retrieving revision 1.8
diff -u -p -u -r1.8 PLIST
--- devel/py-ipykernel/pkg/PLIST11 Sep 2023 21:00:04 - 1.8
+++ devel/py-ipykernel/pkg/PLIST11 Sep 2023 22:49:10 -
@@ -54,6 +54,8 @@ lib/python${MODPY_VERSION}/site-packages
lib/python${MODPY_VERSION}/site-packages/ipykernel/${MODPY_PYCACHE}pickleutil.${MODPY_PYC_MAGIC_TAG}pyc
lib/python${MODPY_VERSION}/site-packages/ipykernel/${MODPY_PYCACHE}serialize.${MODPY_PYC_MAGIC_TAG}${MODPY_PYOEXTENSION}
lib/python${MODPY_VERSION}/site-packages/ipykernel/${MODPY_PYCACHE}serialize.${MODPY_PYC_MAGIC_TAG}pyc
+lib/python${MODPY_VERSION}/site-packages/ipykernel/${MODPY_PYCACHE}trio_runner.${MODPY_PYC_MAGIC_TAG}${MODPY_PYOEXTENSION}
+lib/python${MODPY_VERSION}/site-packages/ipykernel/${MODPY_PYCACHE}trio_runner.${MODPY_PYC_MAGIC_TAG}pyc
lib/python${MODPY_VERSION}/site-packages/ipykernel/${MODPY_PYCACHE}zmqshell.${MODPY_PYC_MAGIC_TAG}${MODPY_PYOEXTENSION}
lib/python${MODPY_VERSION}/site-packages/ipykernel/${MODPY_PYCACHE}zmqshell.${MODPY_PYC_MAGIC_TAG}pyc
lib/python${MODPY_VERSION}/site-packages/ipykernel/_eventloop_macos.py
@@ -201,5 +203,6 @@ lib/python${MODPY_VERSION}/site-packages
lib/python${MODPY_VERSION}/site-packages/ipykernel/tests/test_start_kernel.py
lib/python${MODPY_VERSION}/site-packages/ipykernel/tests/test_zmq_shell.py
lib/python${MODPY_VERSION}/site-packages/ipykernel/tests/utils.py
+lib/python${MODPY_VERSION}/site-packages/ipykernel/trio_runner.py
lib/python${MODPY_VERSION}/site-packages/ipykernel/zmqshell.py
lib/python${MODPY_VERSION}/site-packages/ipykernel_launcher.py
Index: devel/spyder/py-spyder-kernels/Makefile
===
RCS file: /cvs/ports/devel/spyder/py-spyder-kernels/Makefile,v
retrieving revision 1.11
diff -u -p -u -r1.11 Makefile
--- devel/spyder/py-spyder-kernels/Makefile 11 Sep 2023 21:04:55 -
1.11
+++ devel/spyder/py-spyder-kernels/Makefile 11 Sep 2023 22:49:10 -
@@ -1,6 +1,6 @@
COMMENT= kernels used by spyder on its ipython console
-MODPY_EGG_VERSION= 1.8.1
+MODPY_EGG_VERSION= 1.10.2
DISTNAME= spyder-kernels-${MODPY_EGG_VERSION}
PKGNAME= ${MODPY_PY_PREFIX}${DISTNAME}
@@ -12,10 +12,11 @@ FLAVORS = python3
FLAVOR = python3
RUN_DEPENDS = devel/py-cloudpickle${MODPY_FLAVOR} \
- devel/py-ipykernel${MODPY_FLAVOR}>=5.1.3 \
+ devel/ipython${MODPY_FLAVOR}>=7.6.0 \
+ devel/py-ipykernel${MODPY_FLAVOR}>=5.3.0 \
devel/py-jupyter_client${MODPY_FLAVOR}>=5.3.4 \
devel/py-wurlitzer${MODPY_FLAVOR}>=1.0.3 \
- net/py-zmq${MODPY_FLAVOR}
+ net/py-zmq${MODPY_FLAVOR}>=17
NO_TEST = Yes
Index: devel/spyder/py-spyder-kernels/distinfo
===
RCS file: /cvs/ports/devel/spyder/py-spyder-kernels/distinfo,v
retrieving revision 1.3
diff -u -p -u -r1.3 distinfo
--- devel/spyder/py-spyder-kernels/distinfo 11 Sep 2023 21:04:55 -
1.3
+++ devel/spyder/py-spyder-kernels/distinfo 11 Sep 2023 22:49:10 -
@@ -1,2 +1,2 @@
-SHA256 (spyder/spyder-kernels-1.8.1.tar.gz) =
p4L8WWGp3UjVIN3ByGi5YNVLjtsRFsIfwuPDR/5aRHQ=
-SIZE (spyder/spyder-kernels-1.8.1.tar.gz) = 52588
+SHA256 (spyder/spyder-kernels-1.10.2.tar.gz) =
CVS: cvs.openbsd.org: ports
CVSROOT:/cvs Module name:ports Changes by: dan...@cvs.openbsd.org 2023/09/11 16:43:09 ports/math/py-PyWavelets/patches Update of /cvs/ports/math/py-PyWavelets/patches In directory cvs.openbsd.org:/tmp/cvs-serv71224/math/py-PyWavelets/patches Log Message: Directory /cvs/ports/math/py-PyWavelets/patches added to the repository
Re: [update] www/py-httpbin to 0.10.1
On Sun, Sep 03, 2023 at 04:59:42PM +, Lucas Raab wrote:
> Hello,
>
> Here's an update for www/py-httpbin. This has been make test-ed with its two
> deps: devel/py-test-httpbin and devel/py-treq.
>
> Switching to a new upstream which has adopted it after no contact from the
> prior upstream.
>
> changelog since fork:
> https://github.com/psf/httpbin/releases
>
> Comments?
>
> Thanks,
> Lucas
alrighty, now that www/py-flasgger is in, this update is ready for review...
Feedback?
diff refs/heads/master refs/heads/httpbin
commit - a12677c96068efb4853bf1d30ce2533ae9bd2098
commit + 6f6d072fbb3518d06299f58447a56e32f7e3ffba
blob - f746e5c3dab07922dbc03b49b9b59807bd4c4383
blob + 5e6e6d3c26d27edc0d9cff1ada52083b10722b98
--- www/py-httpbin/Makefile
+++ www/py-httpbin/Makefile
@@ -1,15 +1,14 @@
COMMENT = HTTP request and response service
-MODPY_EGG_VERSION =0.7.0
+MODPY_EGG_VERSION =0.10.0
DISTNAME = httpbin-${MODPY_EGG_VERSION}
PKGNAME = py-${DISTNAME}
-REVISION = 0
CATEGORIES = www
-HOMEPAGE = https://github.com/postmanlabs/httpbin
+HOMEPAGE = https://github.com/psf/httpbin
-# MIT
+# MIT, ISC
PERMIT_PACKAGE = Yes
MODULES = lang/python
@@ -18,12 +17,15 @@ MODPY_PI = Yes
MODPY_PYBUILD =setuptools
#MODPY_PYTEST_ARGS = test_httpbin.py
-RUN_DEPENDS = www/py-flask${MODPY_FLAVOR} \
- textproc/py-MarkupSafe${MODPY_FLAVOR} \
+RUN_DEPENDS = archivers/py-brotli${MODPY_FLAVOR} \
devel/py-decorator${MODPY_FLAVOR} \
- www/py-itsdangerous${MODPY_FLAVOR} \
+ devel/py-gevent${MODPY_FLAVOR} \
devel/py-six${MODPY_FLAVOR} \
- archivers/py-brotli${MODPY_FLAVOR} \
+ textproc/py-MarkupSafe${MODPY_FLAVOR} \
+ www/py-flasgger${MODPY_FLAVOR} \
+ www/py-flask${MODPY_FLAVOR} \
+ www/py-itsdangerous${MODPY_FLAVOR} \
+ www/py-jinja2${MODPY_FLAVOR} \
www/py-werkzeug${MODPY_FLAVOR}
# also wanted "raven" but it's only used for sending app errors to a
# web service, and does nothing unless SENTRY_DSN is set in the environment,
blob - b3aebdbcdcb0190b140ceba731d0ae979683411c
blob + e4b17ea77ec8fb5beecc61413ba83be67be16781
--- www/py-httpbin/distinfo
+++ www/py-httpbin/distinfo
@@ -1,2 +1,2 @@
-SHA256 (httpbin-0.7.0.tar.gz) = y7N3kMkVdfTxV1f0KtQdn3KesifV7b6J5OwXVIbbjfo=
-SIZE (httpbin-0.7.0.tar.gz) = 92613
+SHA256 (httpbin-0.10.0.tar.gz) = 2iapImNrzdGgezDHJll8xL6F0WDuOH4Ph7tRnP/smhw=
+SIZE (httpbin-0.10.0.tar.gz) = 103729
blob - eecb292ca7420ae605e08d08756a9bf882757587 (mode 644)
blob + /dev/null
--- www/py-httpbin/patches/patch-httpbin_core_py
+++ /dev/null
@@ -1,37 +0,0 @@
-BaseResponse -> Response as of werkzeug 2.0
-
-see: https://github.com/postmanlabs/httpbin/pull/674
-
-Index: httpbin/core.py
httpbin/core.py.orig
-+++ httpbin/core.py
-@@ -19,9 +19,8 @@ from flask import Flask, Response, request, render_tem
- from six.moves import range as xrange
- from werkzeug.datastructures import WWWAuthenticate, MultiDict
- from werkzeug.http import http_date
--from werkzeug.wrappers import BaseResponse
-+from werkzeug.wrappers import Response as WzResponse
- from werkzeug.http import parse_authorization_header
--from raven.contrib.flask import Sentry
-
- from . import filters
- from .helpers import get_headers, status_code, get_dict, get_request_range,
check_basic_auth, check_digest_auth, \
-@@ -48,17 +47,13 @@ def jsonify(*args, **kwargs):
- return response
-
- # Prevent WSGI from correcting the casing of the Location header
--BaseResponse.autocorrect_location_header = False
-+WzResponse.autocorrect_location_header = False
-
- # Find the correct template folder when running from a different location
- tmpl_dir = os.path.join(os.path.dirname(os.path.abspath(__file__)),
'templates')
-
- app = Flask(__name__, template_folder=tmpl_dir)
- app.debug = bool(os.environ.get('DEBUG'))
--
--# Send app errors to Sentry.
--if 'SENTRY_DSN' in os.environ:
--sentry = Sentry(app, dsn=os.environ['SENTRY_DSN'])
-
- # Set up Bugsnag exception tracking, if desired. To use Bugsnag, install the
- # Bugsnag Python client with the command "pip install bugsnag", and set the
blob - /dev/null
blob + 2029504b0471f8311a49e7ccbb3095055a69db9c (mode 644)
--- /dev/null
+++ www/py-httpbin/patches/patch-httpbin_filters_py
@@ -0,0 +1,15 @@
+Index: httpbin/filters.py
+--- httpbin/filters.py.orig
httpbin/filters.py
+@@ -10,7 +10,10 @@ This module provides response filter decorators.
+ import gzip as gzip2
+ import zlib
+
+-import brotlicffi as _brotli
++try:
++import brotlicffi as _brotli
++except ImportError:
++import brotli as _brotli
+
+ from six import BytesIO
+ from decimal import Decimal
blob -
Re: Switch sysutils/borgbackup/2.0 to openssl-3.0
On Mon, Sep 11, 2023 at 10:14:30PM +0100, Stuart Henderson wrote: > On 2023/09/11 22:12, Theo Buehler wrote: > > On Mon, Sep 11, 2023 at 08:49:13PM +0100, Stuart Henderson wrote: > > > On 2023/09/11 21:48, Theo Buehler wrote: > > > > On Mon, Sep 11, 2023 at 09:41:39PM +0200, Bjorn Ketelaars wrote: > > > > > Diff below switches sysutils/borgbackup/2.0 from OpenSSL-1.1 to > > > > > OpenSSL-3.0. Reason to switch is the EOL status of OpenSSL-1.1.1. > > > > > > > > If you land this, please also update the comments regarding bumps at the > > > > top of the openssl/1.1 and openssl/3.0 Makefiles. > > > > > > > > Has anyone ever tested borgbackup on BTI/IBT machines? > > > > > > > > > > Works fine with borgbackup/1.2, but I don't think that uses OCB. > > > > My understanding is that only 2.0 links against OpenSSL, so 1.2 should > > be fine anyway. > > > > The rason I'm asking is that I am still unclear to what extent OpenSSL > > and its consumers are affected by BTI. robert hit some things with node > > and thus switched it to 3.1 because of its native BTI/IBT support. > > > > For borgbackup/2.0 it is not entirely obvious what parts are routed > > through hashlib/LibreSSL and which parts are directly pulled in from > > the statically linked openssl. It might be worth running regress tests > > on a capable machine and if there are issues use 3.1 instead. > > Seems OK as long as the test suite is enough to exercise this. Thanks. 3.0 is fine with me then. Hard to be 100% sure here...
Re: Switch sysutils/borgbackup/2.0 to openssl-3.0
On 2023/09/11 22:12, Theo Buehler wrote: > On Mon, Sep 11, 2023 at 08:49:13PM +0100, Stuart Henderson wrote: > > On 2023/09/11 21:48, Theo Buehler wrote: > > > On Mon, Sep 11, 2023 at 09:41:39PM +0200, Bjorn Ketelaars wrote: > > > > Diff below switches sysutils/borgbackup/2.0 from OpenSSL-1.1 to > > > > OpenSSL-3.0. Reason to switch is the EOL status of OpenSSL-1.1.1. > > > > > > If you land this, please also update the comments regarding bumps at the > > > top of the openssl/1.1 and openssl/3.0 Makefiles. > > > > > > Has anyone ever tested borgbackup on BTI/IBT machines? > > > > > > > Works fine with borgbackup/1.2, but I don't think that uses OCB. > > My understanding is that only 2.0 links against OpenSSL, so 1.2 should > be fine anyway. > > The rason I'm asking is that I am still unclear to what extent OpenSSL > and its consumers are affected by BTI. robert hit some things with node > and thus switched it to 3.1 because of its native BTI/IBT support. > > For borgbackup/2.0 it is not entirely obvious what parts are routed > through hashlib/LibreSSL and which parts are directly pulled in from > the statically linked openssl. It might be worth running regress tests > on a capable machine and if there are issues use 3.1 instead. Seems OK as long as the test suite is enough to exercise this. ===> Regression tests for borgbackup-2.0.0b6p3 = test session starts == platform openbsd7 -- Python 3.10.12, pytest-7.1.3, pluggy-1.2.0 benchmark: 4.0.0 (defaults: timer=time.perf_counter disable_gc=False min_rounds=5 min_time=0.05 max_time=1.0 calibration_precision=10 warmup=False warmup_iterations=10) Tests enabled: root, symlinks, hardlinks, atime/mtime, modes Tests disabled: BSD flags, fuse2, fuse3 rootdir: /usr/obj/ports/borgbackup-2.0.0b6/borgbackup-2.0.0b6, configfile: setup.cfg plugins: xdist-3.3.1, benchmark-4.0.0 collected 1695 items build/lib.openbsd-7.3-amd64-cpython-310/borg/testsuite/archive.py .. [ 0%] [ 2%] build/lib.openbsd-7.3-amd64-cpython-310/borg/testsuite/benchmark.py [ 2%] [ 5%] build/lib.openbsd-7.3-amd64-cpython-310/borg/testsuite/cache.py [ 5%] [ 10%] [ 10%] build/lib.openbsd-7.3-amd64-cpython-310/borg/testsuite/checksums.py .. [ 10%] build/lib.openbsd-7.3-amd64-cpython-310/borg/testsuite/chunker.py .. [ 10%] ... [ 10%] build/lib.openbsd-7.3-amd64-cpython-310/borg/testsuite/chunker_pytest.py s [ 10%] sss..[ 11%] build/lib.openbsd-7.3-amd64-cpython-310/borg/testsuite/chunker_slow.py . [ 12%] [ 12%] build/lib.openbsd-7.3-amd64-cpython-310/borg/testsuite/compress.py . [ 12%] ... [ 14%] build/lib.openbsd-7.3-amd64-cpython-310/borg/testsuite/crypto.py ... [ 15%] .[ 15%] build/lib.openbsd-7.3-amd64-cpython-310/borg/testsuite/efficient_collection_queue.py . [ 15%] .. [ 15%] build/lib.openbsd-7.3-amd64-cpython-310/borg/testsuite/file_integrity.py . [ 15%] .. [ 16%] build/lib.openbsd-7.3-amd64-cpython-310/borg/testsuite/hashindex.py [ 17%] ... [ 19%] build/lib.openbsd-7.3-amd64-cpython-310/borg/testsuite/hashindex_pytest.py s [ 19%] .s [ 19%] build/lib.openbsd-7.3-amd64-cpython-310/borg/testsuite/helpers.py .. [ 19%] [ 24%] .. [ 27%] build/lib.openbsd-7.3-amd64-cpython-310/borg/testsuite/item.py . [ 28%] [ 28%] build/lib.openbsd-7.3-amd64-cpython-310/borg/testsuite/key.py .. [ 29%] [ 32%] build/lib.openbsd-7.3-amd64-cpython-310/borg/testsuite/locking.py .. [ 32%] ... [ 33%] build/lib.openbsd-7.3-amd64-cpython-310/borg/testsuite/logger.py [ 33%] build/lib.openbsd-7.3-amd64-cpython-310/borg/testsuite/lrucache.py ..[ 33%] build/lib.openbsd-7.3-amd64-cpython-310/borg/testsuite/nanorst.py
CVS: cvs.openbsd.org: ports
CVSROOT:/cvs Module name:ports Changes by: dan...@cvs.openbsd.org 2023/09/11 15:04:55 Modified files: devel/spyder/py-spyder-kernels: Makefile distinfo devel/spyder/py-spyder-kernels/patches: patch-spyder_kernels_customize_spydercustomize_py devel/spyder/py-spyder-kernels/pkg: PLIST Log message: update to py-spyder-kernels 1.8.1 Requires the just updated py-ipykernel 5.1.3. ok sthen@
CVS: cvs.openbsd.org: ports
CVSROOT:/cvs Module name:ports Changes by: dan...@cvs.openbsd.org 2023/09/11 15:00:04 Modified files: devel/py-ipykernel: Makefile distinfo devel/py-ipykernel/patches: patch-setup_py devel/py-ipykernel/pkg: PLIST Log message: update to py-ipykernel 5.1.3 Needed so that py-spyder-kernels can be updated. With tweaks and ok sthen@
CVS: cvs.openbsd.org: ports
CVSROOT:/cvs Module name:ports Changes by: ki...@cvs.openbsd.org 2023/09/11 14:51:24 Modified files: devel/mygui: Makefile distinfo devel/mygui/patches: patch-Common_Base_Ogre_BaseManager_cpp devel/mygui/pkg: PLIST Log message: Update MyGUI to 3.4.1. Needed for OpenMW update. Reminded by lraab@. Ogre rendering is dropped because nothing uses it and it brings in updateing ogre itself and all its consumers. Idea from Lucas. Also stop building demos which are not installed by default anyway. Hints, tests and OK from lraab@, thanks!
CVS: cvs.openbsd.org: ports
CVSROOT:/cvs Module name:ports Changes by: lr...@cvs.openbsd.org 2023/09/11 14:17:45 Modified files: www: Makefile Log message: hook www/py-flasgger up to the build
CVS: cvs.openbsd.org: ports
CVSROOT:/cvs Module name:ports Changes by: lr...@cvs.openbsd.org 2023/09/11 14:15:37 Log message: import www/py-flasgger $ cat pkg/DESCR Flask extension to extract OpenAPI-Specification from all Flask views registered in your API. feedback from daniel@/sthen@, ok daniel@/landry@/sthen@ Status: Vendor Tag: lraab Release Tags: lraab_20230911 N ports/www/py-flasgger/Makefile N ports/www/py-flasgger/distinfo N ports/www/py-flasgger/pkg/PLIST N ports/www/py-flasgger/pkg/DESCR No conflicts created by this import
Re: Switch sysutils/borgbackup/2.0 to openssl-3.0
On Mon, Sep 11, 2023 at 08:49:13PM +0100, Stuart Henderson wrote: > On 2023/09/11 21:48, Theo Buehler wrote: > > On Mon, Sep 11, 2023 at 09:41:39PM +0200, Bjorn Ketelaars wrote: > > > Diff below switches sysutils/borgbackup/2.0 from OpenSSL-1.1 to > > > OpenSSL-3.0. Reason to switch is the EOL status of OpenSSL-1.1.1. > > > > If you land this, please also update the comments regarding bumps at the > > top of the openssl/1.1 and openssl/3.0 Makefiles. > > > > Has anyone ever tested borgbackup on BTI/IBT machines? > > > > Works fine with borgbackup/1.2, but I don't think that uses OCB. My understanding is that only 2.0 links against OpenSSL, so 1.2 should be fine anyway. The rason I'm asking is that I am still unclear to what extent OpenSSL and its consumers are affected by BTI. robert hit some things with node and thus switched it to 3.1 because of its native BTI/IBT support. For borgbackup/2.0 it is not entirely obvious what parts are routed through hashlib/LibreSSL and which parts are directly pulled in from the statically linked openssl. It might be worth running regress tests on a capable machine and if there are issues use 3.1 instead.
CVS: cvs.openbsd.org: ports
CVSROOT:/cvs Module name:ports Changes by: jer...@cvs.openbsd.org 2023/09/11 14:04:47 Modified files: databases/postgresql: Makefile Added files: databases/postgresql/patches: patch-src_bin_initdb_initdb_c Log message: Have initdb recommend use of rcctl if appropriate Requested by espie@ OK sthen@, espie@
Re: [new] www/py-flasgger
On Mon, Sep 11, 2023 at 05:49:21PM +0100, Stuart Henderson wrote: > On 2023/09/03 17:15, Lucas Raab wrote: > > Hello, > > > > Here's a new port for py-flasgger which is a new dep for a www/py-httpbin > > update and possibly of interest for those who have APIs implemented in > > Flask. > > > > pkg/DESCR: > > Flask extension to extract OpenAPI-Specification from all Flask > > views registered in your API. > > > > https://github.com/flasgger/flasgger > > > > Comments? > > > > Thanks, > > Lucas > > It has RUN_DEPENDS on sysutils/py-packaging and www/py-werkzeug > but I don't see any relevant imports in the installed files (there > are some "use...from werkzeug" in examples/demo_app files but not > installed). It would be nice to drop those if not really needed. Fair point. I took requirements.txt at its word and didn't check where/how the imports were used. I'll drop them. > > Looks like the default set of tests picked by pytest require some > things we don't have (e.g. test_examples.py requires swagger-flex > pypi.org/project/flex) causing it to stop in the 'collect' phase; > adding this allows the other test to run: > > # avoid tests with deps that we don't have > MODPY_PYTEST_ARGS = --ignore tests/test_examples.py tests > > (or we could set use MODPY_PYTEST_ARGS=tests/test_base.py, but > the above will still let it pick up anything newly added in > future versions). The former sounds good to me, I'll commit with ignoring the examples and picking up the remainder. > > With those dep/s removed if possible and MODPY_PYTEST_ARGS, I'm > ok with this. > thanks!
CVS: cvs.openbsd.org: ports
CVSROOT:/cvs Module name:ports Changes by: jer...@cvs.openbsd.org 2023/09/11 13:59:04 Modified files: lang/ruby : ruby.port.mk Log message: Further simplify ruby.port.mk * Remove variables not used by any ports in the tree: * MODRUBY_LIBDIR * MODRUBY_RELDOCDIR * MODRUBY_DOCDIR * MODRUBY_EXAMPLEDIR * MODRUBY_ADJ_REPLACE * MODRUBY_TEST_DIR * Prefix internal variables with an underscore. Any variable not currently used by any ports in the tree has been made internal. * Consolidate all SUBST_VARS and UPDATE_PLIST_ARGS setting to a single case. Tested by building all ports using lang/ruby module.
Re: Switch sysutils/borgbackup/2.0 to openssl-3.0
On 2023/09/11 21:48, Theo Buehler wrote: > On Mon, Sep 11, 2023 at 09:41:39PM +0200, Bjorn Ketelaars wrote: > > Diff below switches sysutils/borgbackup/2.0 from OpenSSL-1.1 to > > OpenSSL-3.0. Reason to switch is the EOL status of OpenSSL-1.1.1. > > If you land this, please also update the comments regarding bumps at the > top of the openssl/1.1 and openssl/3.0 Makefiles. > > Has anyone ever tested borgbackup on BTI/IBT machines? > Works fine with borgbackup/1.2, but I don't think that uses OCB.
Re: Switch sysutils/borgbackup/2.0 to openssl-3.0
On Mon, Sep 11, 2023 at 09:41:39PM +0200, Bjorn Ketelaars wrote: > Diff below switches sysutils/borgbackup/2.0 from OpenSSL-1.1 to > OpenSSL-3.0. Reason to switch is the EOL status of OpenSSL-1.1.1. If you land this, please also update the comments regarding bumps at the top of the openssl/1.1 and openssl/3.0 Makefiles. Has anyone ever tested borgbackup on BTI/IBT machines?
Switch sysutils/borgbackup/2.0 to openssl-3.0
Diff below switches sysutils/borgbackup/2.0 from OpenSSL-1.1 to
OpenSSL-3.0. Reason to switch is the EOL status of OpenSSL-1.1.1.
It should be noted that OpenSSL is used for EVP_aes_256_ocb, and is
linked statically to avoid conflicting with shared libcrypto from the
base OS pulled in via dependencies.
Passes all tests, and run tested on amd64.
Comments/OK?
Index: Makefile
===
RCS file: /cvs/ports/sysutils/borgbackup/2.0/Makefile,v
retrieving revision 1.14
diff -u -p -r1.14 Makefile
--- Makefile11 Sep 2023 17:59:47 - 1.14
+++ Makefile11 Sep 2023 19:34:04 -
@@ -4,11 +4,11 @@ USE_NOEXECONLY= Yes
.endif
MODPY_EGG_VERSION =2.0.0b6
-REVISION = 2
+REVISION = 3
# OpenSSL used for EVP_aes_256_ocb. It is linked statically to avoid
conflicting
# with shared libcrypto from the base OS pulled in via dependencies.
-BUILD_DEPENDS =security/openssl/1.1
+BUILD_DEPENDS =security/openssl/3.0
RUN_DEPENDS = security/py-argon2-cffi${MODPY_FLAVOR} \
sysutils/py-platformdirs${MODPY_FLAVOR}>=3.8.1
Index: patches/patch-setup_py
===
RCS file: patches/patch-setup_py
diff -N patches/patch-setup_py
--- /dev/null 1 Jan 1970 00:00:00 -
+++ patches/patch-setup_py 11 Sep 2023 19:34:04 -
@@ -0,0 +1,14 @@
+Index: setup.py
+--- setup.py.orig
setup.py
+@@ -161,8 +161,8 @@ if not on_rtd:
+ # Use openssl (not libressl) because we need AES-OCB via EVP api. Link
+ # it statically to avoid conflicting with shared libcrypto from the
base
+ # OS pulled in via dependencies.
+-crypto_ext_lib = {"include_dirs": ["/usr/local/include/eopenssl11"]}
+-crypto_extra_objects += ["/usr/local/lib/eopenssl11/libcrypto.a"]
++crypto_ext_lib = {"include_dirs": ["/usr/local/include/eopenssl30"]}
++crypto_extra_objects += ["/usr/local/lib/eopenssl30/libcrypto.a"]
+ else:
+ crypto_ext_lib = lib_ext_kwargs(pc, "BORG_OPENSSL_PREFIX", "crypto",
"libcrypto", ">=1.1.1")
+
CVS: cvs.openbsd.org: ports
CVSROOT:/cvs Module name:ports Changes by: ajacou...@cvs.openbsd.org 2023/09/11 12:34:31 Modified files: mail/cyrus-imapd: Makefile distinfo mail/cyrus-imapd/patches: patch-imap_cyr_cd_sh mail/cyrus-imapd/pkg: PLIST Log message: Update to cyrus-imapd-3.8.1.
CVS: cvs.openbsd.org: ports
CVSROOT:/cvs Module name:ports Changes by: b...@cvs.openbsd.org2023/09/11 11:59:47 Modified files: sysutils/borgbackup: Makefile.inc sysutils/borgbackup/1.2: Makefile sysutils/borgbackup/2.0: Makefile Log message: sysutils/borgbackup: cleanup Makefiles Changes are cosmetical, no bump needed
Re: update spyder-kernels
On 2023/09/11 00:59, Daniel Dickman wrote:
> Index: Makefile
> ===
> RCS file: /cvs/ports/devel/py-ipykernel/Makefile,v
> retrieving revision 1.16
> diff -u -p -u -r1.16 Makefile
> --- Makefile 13 Nov 2022 15:28:15 - 1.16
> +++ Makefile 11 Sep 2023 04:55:26 -
> @@ -1,24 +1,27 @@
> COMMENT =IPython kernel for Jupyter
>
> -MODPY_EGG_VERSION = 4.10.0
> +MODPY_EGG_VERSION = 5.1.3
> DISTNAME = ipykernel-${MODPY_EGG_VERSION}
> PKGNAME =py-${DISTNAME}
> -REVISION = 5
>
> -PORTROACH= limit:^4
> +PORTROACH= limit:^5
>
> CATEGORIES = devel
>
> HOMEPAGE = https://ipython.org/
>
> -RUN_DEPENDS += devel/py-jupyter_client${MODPY_FLAVOR} \
> +BUILD_DEPENDS = devel/ipython${MODPY_FLAVOR} \
> + devel/py-jupyter_core${MODPY_FLAVOR}>=4.2 \
> + devel/py-jupyter_client${MODPY_FLAVOR}
> +
> +RUN_DEPENDS =devel/py-jupyter_client${MODPY_FLAVOR} \
> devel/py-traitlets${MODPY_FLAVOR}>=4.1.0 \
> - www/py-tornado${MODPY_FLAVOR}>=4.0 \
> - devel/ipython${MODPY_FLAVOR}>=4.0.0
> + www/py-tornado${MODPY_FLAVOR}>=4.2 \
> + devel/ipython${MODPY_FLAVOR}>=5.0.0
>
> TEST_DEPENDS = devel/py-nose${MODPY_FLAVOR} \
> devel/py-nose-warnings-filters${MODPY_FLAVOR} \
> - devel/py-test${MODPY_FLAVOR} \
> + devel/py-flaky${MODPY_FLAVOR} \
> devel/py-test-cov${MODPY_FLAVOR} \
> graphics/py-matplotlib${MODPY_FLAVOR} \
> math/py-numpy${MODPY_FLAVOR}
> @@ -28,6 +31,8 @@ PERMIT_PACKAGE =Yes
>
> MODULES =lang/python
> MODPY_PI = Yes
> +MODPY_PYBUILD = setuptools
> +MODPY_PYTEST = Yes
For py-ipykernel:
MODPY_PYTEST is set to Yes by default when MODPY_PYBUILD is used,
so no need to list it separately.
I'd prefer to remove do-test and use the pytest runner instead if
you don't mind; you'll need to set PORTHOME=${WRKDIR} or similar
to avoid it writing to a nonexistent dir.
otherwise both are OK with me.
CVS: cvs.openbsd.org: ports
CVSROOT:/cvs Module name:ports Changes by: lan...@cvs.openbsd.org 2023/09/11 11:02:56 Modified files: www/mozilla-firefox: Tag: OPENBSD_7_3 Makefile www/mozilla-firefox/files: Tag: OPENBSD_7_3 unveil.content unveil.main Log message: www/mozilla-firefox: MFC unveil configs fixes merges unveil.content r1.11 from gkoehler@: Unveil /etc/localtime r in firefox's content process This fixes dst (daylight saving time, summer time) in JavaScript. Firefox turns off dst in libc, then applies its dst rules. It fails to apply dst if it can't realpath(3) /etc/localtime. This failure might cause local times to be off by an hour. merges unveil.main r1.17 from kn@: Unveil AT SPI2 path to enable screen readers In there is a D-Bus socket used to communicate with tools like orca(1), e.g. 'orca -s' and ticking the 'Speak object under mouse' box would read out text and elements in programs except our pledged+unveiled browsers. /etc/localtime issue on 7.3-stable reported by John Kaiser who also confirmed that the unveil addition fixed the problem for him.
Re: [new] www/py-flasgger
On 2023/09/03 17:15, Lucas Raab wrote: > Hello, > > Here's a new port for py-flasgger which is a new dep for a www/py-httpbin > update and possibly of interest for those who have APIs implemented in Flask. > > pkg/DESCR: > Flask extension to extract OpenAPI-Specification from all Flask > views registered in your API. > > https://github.com/flasgger/flasgger > > Comments? > > Thanks, > Lucas It has RUN_DEPENDS on sysutils/py-packaging and www/py-werkzeug but I don't see any relevant imports in the installed files (there are some "use...from werkzeug" in examples/demo_app files but not installed). It would be nice to drop those if not really needed. Looks like the default set of tests picked by pytest require some things we don't have (e.g. test_examples.py requires swagger-flex pypi.org/project/flex) causing it to stop in the 'collect' phase; adding this allows the other test to run: # avoid tests with deps that we don't have MODPY_PYTEST_ARGS = --ignore tests/test_examples.py tests (or we could set use MODPY_PYTEST_ARGS=tests/test_base.py, but the above will still let it pick up anything newly added in future versions). With those dep/s removed if possible and MODPY_PYTEST_ARGS, I'm ok with this.
Re: [new] editors/litexl v2.1.1
Le Mon, Sep 11, 2023 at 04:43:29PM +0200, Sebastien Marie a écrit :
> On Mon, Sep 11, 2023 at 04:17:33PM +0200, Denis Fondras wrote:
> > Lite XL is derived from Lite. It is a lightweight text editor written
> > mostly in
> > Lua — it aims to provide something practical, pretty, small and fast easy to
> > modify and extend, or to use without doing either.
> >
> > The aim of Lite XL compared to lite is to be more user friendly, improve the
> > quality of font rendering, and reduce CPU usage.
> >
> > https://lite-xl.com/
>
> - missing c and m in WANTLIB
>
> - it seems to doesn't start without invocation with full path:
>
> $ lite-xl
> Error: [string "local core..."]:5: attempt to index a nil value (local
> 'exedir')
> stack traceback:
> [string "local core..."]:2: in main chunk
>
> $ /usr/local/bin/lite-xl
> [work]
>
> as it is installed at a know place, it could be patched to fallback to
> /usr/local:
>
> --- /dev/null Mon Sep 11 16:42:08 2023
> +++ patches/patch-src_main_c Mon Sep 11 16:41:17 2023
> @@ -0,0 +1,15 @@
> +Index: src/main.c
> +--- src/main.c.orig
> src/main.c
> +@@ -205,7 +205,10 @@ init_lua:
> + lua_pushstring(L, exename);
> + } else {
> + // get_exe_filename failed
> +-lua_pushstring(L, argv[0]);
> ++if (strchr(argv[0], '/') != NULL)
> ++ lua_pushstring(L, argv[0]);
> ++else
> ++ lua_pushstring(L, "/usr/local/bin/lite-xl");
> + }
> + lua_setglobal(L, "EXEFILE");
> +
>
> ok semarie@ with the two points corrected.
>
Thank you for the review Sebastien.
> --
> Sebastien Marie
CVS: cvs.openbsd.org: ports
CVSROOT:/cvs Module name:ports Changes by: de...@cvs.openbsd.org 2023/09/11 10:18:50 Modified files: editors: Makefile Log message: + litexl
CVS: cvs.openbsd.org: ports
CVSROOT:/cvs Module name:ports Changes by: de...@cvs.openbsd.org 2023/09/11 10:16:44 Log message: Import litexl v2.1.1 input and OK semarie@ Status: Vendor Tag: denis Release Tags: denis_20230911 N ports/editors/litexl/Makefile N ports/editors/litexl/distinfo N ports/editors/litexl/patches/patch-meson_build N ports/editors/litexl/patches/patch-src_main_c N ports/editors/litexl/pkg/DESCR N ports/editors/litexl/pkg/PLIST No conflicts created by this import
CVS: cvs.openbsd.org: ports
CVSROOT:/cvs Module name:ports Changes by: rob...@cvs.openbsd.org 2023/09/11 09:57:51 Modified files: devel/llvm : Makefile.inc devel/llvm/13 : Makefile devel/llvm/13/patches: patch-lld_CMakeLists_txt patch-lld_tools_lld_CMakeLists_txt patch-lld_tools_lld_lld_cpp devel/llvm/16 : Makefile devel/llvm/16/patches: patch-lld_tools_lld_lld_cpp Added files: devel/llvm/16/patches: patch-lld_CMakeLists_txt patch-lld_tools_lld_CMakeLists_txt Log message: ports clang needs wasm support in lld, but base will not, so introduce cmake options for them
CVS: cvs.openbsd.org: ports
CVSROOT:/cvs Module name:ports Changes by: t...@cvs.openbsd.org2023/09/11 09:26:54 Modified files: sysutils/borgbackup/2.0: Makefile Log message: borgbackup: bump revision after openssl update (static link)
CVS: cvs.openbsd.org: ports
CVSROOT:/cvs Module name:ports Changes by: t...@cvs.openbsd.org2023/09/11 09:26:17 Modified files: security/sslscan: Makefile Log message: sslscan: bump after openssl update (static link)
CVS: cvs.openbsd.org: ports
CVSROOT:/cvs Module name:ports Changes by: t...@cvs.openbsd.org2023/09/11 09:24:39 Modified files: security/openssl/1.1: Makefile distinfo Log message: Update to OpenSSL 1.1.1w Last public update. From now on you get to pay or have to live with OpenSSL 3. This release plugs some memleaks compared with 1.1.1v and has a patch for perlasm to avoid XMM register corruption on Windows.
Re: Asterisk on Octeon
On Mon, Sep 11, 2023 at 11:55:05AM +0100, Stuart Henderson wrote: > > Has anyone had any success running Asterisk on Octeon (in my case, an > > EdgeRouter 6P, running OpenBSD 7.3)? > > [...] > No idea what's up on Octeon, but you could try building it with gcc > to check if that makes any difference. Thanks for the idea. I gave this a go, but the result is still the same. Alex
CVS: cvs.openbsd.org: ports
CVSROOT:/cvs Module name:ports Changes by: es...@cvs.openbsd.org 2023/09/11 08:45:35 Modified files: misc/portroach : Makefile Added files: misc/portroach/patches: patch-portroach_pod Log message: fix postgres instructions by allowing the portroach user to own its own db. Thanks jeremy@
CVS: cvs.openbsd.org: ports
CVSROOT:/cvs Module name:ports Changes by: bl...@cvs.openbsd.org 2023/09/11 08:45:14 Modified files: misc/open62541 : Makefile distinfo Log message: update p5-open62541 to 1.3.7
Re: [new] editors/litexl v2.1.1
On Mon, Sep 11, 2023 at 04:17:33PM +0200, Denis Fondras wrote:
> Lite XL is derived from Lite. It is a lightweight text editor written mostly
> in
> Lua — it aims to provide something practical, pretty, small and fast easy to
> modify and extend, or to use without doing either.
>
> The aim of Lite XL compared to lite is to be more user friendly, improve the
> quality of font rendering, and reduce CPU usage.
>
> https://lite-xl.com/
- missing c and m in WANTLIB
- it seems to doesn't start without invocation with full path:
$ lite-xl
Error: [string "local core..."]:5: attempt to index a nil value (local 'exedir')
stack traceback:
[string "local core..."]:2: in main chunk
$ /usr/local/bin/lite-xl
[work]
as it is installed at a know place, it could be patched to fallback to
/usr/local:
--- /dev/null Mon Sep 11 16:42:08 2023
+++ patches/patch-src_main_cMon Sep 11 16:41:17 2023
@@ -0,0 +1,15 @@
+Index: src/main.c
+--- src/main.c.orig
src/main.c
+@@ -205,7 +205,10 @@ init_lua:
+ lua_pushstring(L, exename);
+ } else {
+ // get_exe_filename failed
+-lua_pushstring(L, argv[0]);
++if (strchr(argv[0], '/') != NULL)
++ lua_pushstring(L, argv[0]);
++else
++ lua_pushstring(L, "/usr/local/bin/lite-xl");
+ }
+ lua_setglobal(L, "EXEFILE");
+
ok semarie@ with the two points corrected.
--
Sebastien Marie
cad/xtrkcad: fix build with gettext 0.22
I'm preparing to update devel/gettext to 0.22. The gettext tools have
become more strict and no longer accept various dodgy input.
/usr/obj/xtrkcad-5.2.2/xtrkcad-source-5.2.2GA/app/i18n/fi.po:12820: 'msgstr' is
not a valid C format string, unlike 'msgid'. Reason: In the directive number 1,
the argument size specifier is invalid.
/usr/local/bin/msgfmt: found 1 fatal error
msgfmt complains specifically about the Finnish translation because
"% j" is not a valid printf(3) format specifier, while the "% a" of
the English text as well as those of the other translations accidentally
are.
As far as I can tell, this one and related texts strings aren't
intended as C format strings at all. They are extracted from .xtr
files and only dumped into a custmsg.h file for the translation
tools to pick up.
In short, the briefest, if hacky fix is to remove the "c format"
marker from the rejected string in fi.po.
OK?
---
commit fdc89cfeea676b8c04373147ab8138681168fc7a (gettext)
from: Christian Weisgerber
date: Mon Sep 11 14:20:32 2023 UTC
cad/xtrkcad: fix build with gettext 0.22
M cad/xtrkcad/Makefile
A cad/xtrkcad/patches/patch-app_i18n_fi_po
diff 0bb98a17accf9c882a24b2e40736c997021f03f9
fdc89cfeea676b8c04373147ab8138681168fc7a
commit - 0bb98a17accf9c882a24b2e40736c997021f03f9
commit + fdc89cfeea676b8c04373147ab8138681168fc7a
blob - c0f2ea2809c11faa6dac4a3358219b751d61f193
blob + f32b845ab0687ecf926df09d7ecca0438694f21c
--- cad/xtrkcad/Makefile
+++ cad/xtrkcad/Makefile
@@ -39,4 +39,7 @@ CONFIGURE_ARGS += -DXTRKCAD_USE_GETTEXT=on
CONFIGURE_ENV += CFLAGS=-I${PREFIX}/include \
LDFLAGS="-pthread -L/usr/X11R6/lib -L${PREFIX}/lib -liconv
-lintl"
+# patches/patch-app_i18n_fi_po
+FIX_CRLF_FILES=${WRKSRC}/app/i18n/fi.po
+
.include
blob - /dev/null
blob + 4d0df4291446ad49274a95a35b717f849425707e (mode 644)
--- /dev/null
+++ cad/xtrkcad/patches/patch-app_i18n_fi_po
@@ -0,0 +1,13 @@
+Erroneously marked as a C format string and flagged as invalid by msgfmt.
+
+Index: app/i18n/fi.po
+--- app/i18n/fi.po.orig
app/i18n/fi.po
+@@ -12813,7 +12813,6 @@ msgstr ""
+
+ #. i18n: C:/Users/mf/Documents/XTrackCAD/src/work/app/lib/demos/dmhelix.xtr:28
+ #: ../../../../build/work/app/i18n/custmsg.h:627
+-#, c-format
+ msgid ""
+ "We will be creating a helix with a Elevation Difference of 12\", Grade of "
+ "1.5% and limit the Vertical Separation to at least 2\".\n"
--
Christian "naddy" Weisgerber na...@mips.inka.de
CVS: cvs.openbsd.org: ports
CVSROOT:/cvs Module name:ports Changes by: fcam...@cvs.openbsd.org 2023/09/11 08:33:25 Modified files: audio/libopenmpt: Makefile distinfo Log message: Update libopenmpt to 0.7.3.
Re: [new] editors/litexl v2.1.1
Nevermind, sent too early :) Le Mon, Sep 11, 2023 at 04:17:33PM +0200, Denis Fondras a écrit : > Lite XL is derived from Lite. It is a lightweight text editor written mostly > in > Lua — it aims to provide something practical, pretty, small and fast easy to > modify and extend, or to use without doing either. > > The aim of Lite XL compared to lite is to be more user friendly, improve the > quality of font rendering, and reduce CPU usage. > > https://lite-xl.com/
[new] editors/litexl v2.1.1
Lite XL is derived from Lite. It is a lightweight text editor written mostly in Lua — it aims to provide something practical, pretty, small and fast easy to modify and extend, or to use without doing either. The aim of Lite XL compared to lite is to be more user friendly, improve the quality of font rendering, and reduce CPU usage. https://lite-xl.com/ litexl-2.1.1.tgz Description: application/tar-gz
CVS: cvs.openbsd.org: ports
CVSROOT:/cvs Module name:ports Changes by: de...@cvs.openbsd.org 2023/09/11 08:03:53 Modified files: databases/timescaledb: Makefile distinfo databases/timescaledb/pkg: PLIST Log message: Update to v2.11.2 Thanks to Renato Aguiar (renato at renatoaguiar net) for the diff
CVS: cvs.openbsd.org: ports
CVSROOT:/cvs Module name:ports Changes by: b...@cvs.openbsd.org2023/09/11 08:03:20 Modified files: sysutils/borgbackup: Makefile sysutils/borgbackup/1.2: Makefile sysutils/borgbackup/1.2/pkg: PLIST Removed files: sysutils/borgbackup/1.1: Makefile distinfo sysutils/borgbackup/1.1/pkg: DESCR PLIST Log message: Remove sysutils/borgbackup/1.1 The 1.1 branch is considered EOL by upstream. The 1.2 branch, which we have in ports as well, is actively maintained, and upgrading from 1.1.x to 1.2.x is possible as detailed by https://github.com/borgbackup/borg/blob/1.2.6/docs/changes.rst#borg-11x-to-12x. Added @pkgpath markers to the PLIST of sysutils/borgbackup/1.2 so that pkg_add -u will update borgbackup-1.1.x to borgbackup-1.2.x. Bumped REVISION of 1.2. OK kn@
CVS: cvs.openbsd.org: ports
CVSROOT:/cvs Module name:ports Changes by: st...@cvs.openbsd.org 2023/09/11 07:46:21 Modified files: cad/kicad : Makefile Log message: kicad: set USE_NOBTCFI; coroutine code using libcontext doesn't have all the landing pads needed. https://marc.info/?t=16943920001=1=2
Re: KiCad exits with "illegal instruction"
On 2023/09/10 20:25, Isaac Meerwarth wrote:
> I wanted to report that KiCad exits with "illegal instruction" when you try
> to launch a project.
> cpu0: 12th Gen Intel(R) Core(TM) i5-1240P, 4390.58 MHz, 06-9a-03, patch
> 042c
> cpu0:
> FPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CFLUSH,DS,ACPI,MMX,FXSR,SSE,SSE2,SS,HTT,TM,PBE,SSE3,PCLMUL,DTES64,MWAIT,DS-CPL,VMX,SMX,EST,TM2,SSSE3,SDBG,FMA3,CX16,xTPR,PDCM,PCID,SSE4.1,SSE4.2,x2APIC,MOVBE,POPCNT,DEADLINE,AES,XSAVE,AVX,F16C,RDRAND,NXE,PAGE1GB,RDTSCP,LONG,LAHF,ABM,3DNOWP,PERF,ITSC,FSGSBASE,TSC_ADJUST,BMI1,AVX2,SMEP,BMI2,ERMS,INVPCID,RDSEED,ADX,SMAP,CLFLUSHOPT,CLWB,PT,SHA,UMIP,PKU,WAITPKG,PKS,MD_CLEAR,IBT,IBRS,IBPB,STIBP,L1DF,SSBD,SENSOR,ARAT,IBRS_ALL,SKIP_L1DFL,MDS_NO,IF_PSCHANGE,TAA_NO,MISC_PKG_CT,ENERGY_FILT,DOITM,SBDR_SSDP_N,FBSDP_NO,PSDP_NO,RRSBA,OVERCLOCK,XSAVEOPT,XSAVEC,XGETBV1,XSAVES
Machine with IBT. Here's a backtrace and disasm which suggests that it
is related to this (i.e. missing an 'endbr64' landing pad at the program
counter location) though there are other endbr64 in the disasm.
Looks like this is coming from the coroutine code in kicad which uses
a copy of libcontext
https://gitlab.com/kicad/code/kicad/-/blob/master/include/tool/coroutine.h
https://gitlab.com/kicad/code/kicad/-/blob/master/thirdparty/libcontext/libcontext.cpp
I'll try a build with USE_NOBTCFI which should help, I'll commit that
if it works. (That doesn't stop someone delving into the asm if they
want).
Core was generated by `kicad'.
Program terminated with signal SIGILL, Illegal instruction.
#0 0x0078f0173cda in COROUTINE::jumpIn(COROUTINE::INVOCATION_ARGS*) ()
[Current thread is 1 (process 437269)]
(gdb) bt
#0 0x0078f0173cda in COROUTINE::jumpIn(COROUTINE::INVOCATION_ARGS*) ()
#1 0x0078f01748b1 in COROUTINE::doCall(COROUTINE::INVOCATION_ARGS*, TOOL_EVENT
const&) ()
#2 0x0078f0170b23 in COROUTINE::Call(TOOL_EVENT
const&) ()
#3 0x0078f016d07b in TOOL_MANAGER::dispatchInternal(TOOL_EVENT&) ()
#4 0x0078f016893b in TOOL_MANAGER::processEvent(TOOL_EVENT const&) ()
#5 0x0078f016ee18 in TOOL_MANAGER::ProcessEvent(TOOL_EVENT const&) ()
#6 0x0078eff77381 in wxEventFunctorFunctor,
PANEL_KICAD_LAUNCHER::CreateLaunchers()::$_0::operator()(TOOL_ACTION const&,
wxBitmap const&, wxString const&)
const::{lambda(wxEvent&)#1}>::operator()(wxEvtHandler*, wxEvent&) ()
#7 0x007b046b1a22 in wxEvtHandler::ProcessEventIfMatchesId (entry=...,
handler=0x7534b25c5230, event=...)
at ./src/common/event.cpp:1431
#8 wxEvtHandler::SearchDynamicEventTable (this=0x7bafaca300, event=...) at
./src/common/event.cpp:1901
#9 0x007b046b1686 in wxEvtHandler::TryHereOnly (this=0x7bafaca300,
event=...) at ./src/common/event.cpp:1624
#10 wxEvtHandler::TryBeforeAndHere (this=0x7bafaca300, event=...) at
./include/wx/event.h:4007
#11 wxEvtHandler::ProcessEventLocally (this=0x7bafaca300, event=...) at
./src/common/event.cpp:1561
#12 0x007b046b14d6 in wxEvtHandler::ProcessEvent (this=0x7bafaca300,
event=...) at ./src/common/event.cpp:1534
#13 0x0078effcdaa5 in
wxAsyncMethodCallEventFunctor::Execute()
()
#14 0x007b046b175f in wxEvtHandler::TryHereOnly (this=0x7bafaca300,
event=...) at ./src/common/event.cpp:1636
#15 wxEvtHandler::TryBeforeAndHere (this=0x7bafaca300, event=...) at
./include/wx/event.h:4007
#16 wxEvtHandler::ProcessEventLocally (this=0x7bafaca300, event=...) at
./src/common/event.cpp:1561
#17 0x007b046b14d6 in wxEvtHandler::ProcessEvent (this=0x7bafaca300,
event=...) at ./src/common/event.cpp:1534
#18 0x007b046b1006 in wxEvtHandler::ProcessPendingEvents
(this=0x7bafaca300) at ./src/common/event.cpp:1398
#19 0x007b0455fd6a in wxAppConsoleBase::ProcessPendingEvents
(this=0x7b90b17c80) at ./src/common/appbase.cpp:570
#20 0x007b68e07452 in wxApp::DoIdle (this=0x7b90b17c80) at
./src/gtk/app.cpp:151
#21 0x007b68e09275 in wxapp_idle_callback () at ./src/gtk/app.cpp:101
#22 0x007b40c643ef in g_main_context_dispatch () from
/usr/local/lib/libglib-2.0.so.4201.10
#23 0x007b40c64757 in g_main_context_iterate () from
/usr/local/lib/libglib-2.0.so.4201.10
#24 0x007b40c64b6a in g_main_loop_run () from
/usr/local/lib/libglib-2.0.so.4201.10
#25 0x007bbb7ee1ec in gtk_main () from /usr/local/lib/libgtk-3.so.2201.0
#26 0x007b68e23bd5 in wxGUIEventLoop::DoRun (this=0x7afde71ec0) at
./src/gtk/evtloop.cpp:61
#27 0x007b04598da2 in wxEventLoopBase::Run (this=0x7afde71ec0) at
./src/common/evtloopcmn.cpp:87
#28 0x007b0455efef in wxAppConsoleBase::MainLoop (this=0x7b90b17c80) at
./src/common/appbase.cpp:381
#29 0x0078eff8083a in APP_KICAD::OnRun() ()
#30 0x007b045de789 in wxEntry (argc=, argv=)
at ./src/common/init.cpp:508
#31 0x0078eff7fa4e in main ()
(gdb) disassemble
Dump of assembler code for function
_ZN9COROUTINEIiRK10TOOL_EVENTE6jumpInEPNS3_15INVOCATION_ARGSE:
0x0078f0173af0 <+0>: endbr64
0x0078f0173af4 <+4>: mov
CVS: cvs.openbsd.org: ports
CVSROOT:/cvs Module name:ports Changes by: st...@cvs.openbsd.org 2023/09/11 06:28:43 Modified files: net/eduvpn/vpn-user-portal: Makefile distinfo net/eduvpn/vpn-user-portal/patches: patch-src_OpenVpn_ServerConfig_php net/eduvpn/vpn-user-portal/pkg: PLIST Added files: net/eduvpn/vpn-user-portal/patches: patch-tests_OpenVpn_ServerConfigTest_php Log message: update to eduvpn vpn-user-portal-3.4.0
CVS: cvs.openbsd.org: ports
CVSROOT:/cvs Module name:ports Changes by: st...@cvs.openbsd.org 2023/09/11 06:28:20 Modified files: net/eduvpn/vpn-ca: Makefile distinfo net/eduvpn/vpn-ca/patches: patch-Makefile Log message: update to eduvpn vpn-ca-4.0.2
CVS: cvs.openbsd.org: ports
CVSROOT:/cvs Module name:ports Changes by: dan...@cvs.openbsd.org 2023/09/11 06:16:05 Modified files: lang/pcc : Makefile.inc lang/pcc/pcc-libs: distinfo Log message: missed in previous
Re: UPDATE: objfw-1.0.2
Am 11.09.23 um 13:01 schrieb Jeremie Courreges-Anglas: This diff and the previous one were likely mangled by your MUA. There are hints available: https://www.kernel.org/doc/html/latest/process/email-clients.html Or you may just send diffs as attachments (inline is still preferred). Ah, sorry about that. I'll double check next time. Using /usr/src/lib/check_sym I can spot: /usr/local/lib/libobjfwtls.so.0.0 --> /usr/obj/pobj/objfw-1.0.2/fake-amd64/usr/local/lib/libobjfwtls.so.0.0 Dynamic export changes: added: .objc_sel_nameof_isWaitingForDelimiter Applying blindly our rules for shared libraries, this would warrant a minor bump because of the additional interface. But maybe the initial '.' in the name means it's a local, private symbol? nm -g tells me it's a weak symbol so with public visibility. Insights welcome. Nope, this shouldn't be a bump. libobjfwtls.so.0.0 subclasses OFTLSStream from libobjfw.so.0.0 as OFOpenSSLTLSStream. What's new is that it overrides the private method of_isWaitingForDelimiter. It shouldn't override a private method, yes, but for now, that is the fix without changing the API/ABI and can be done since I control both libs. This works due to the dynamic dispatch. The .objc_sel_nameof_isWaitingForDelimiter is merely a new symbol that provides the string for the selector that gets registered with the runtime so it can be overridden. It's references by the .objc_method_list that is in turn referenced by the class structure that is in turn referenced by the ObjC module that is passed to __objc_exec via a constructor to register all classes, categories and selectors in the module with the runtime. libobjfwtls in turn sets the global variable OFTLSStreamImplementation in libobjfw via the +load method of OFOpenSSLTLSStream, which in turn gets called by the runtime via this chain started by __objc_exec, at which point libobjfw knows to use OFOpenSSLTLSStream when an OFTLSStream is requested. The only way someone interfaces with libobjfwtls is by linking it in and not referencing any symbols from it. Hope that explains :). All these structures are emitted by the compiler automatically. You can find a declaration of those structs emitted by the compiler here: https://objfw.nil.im/file?name=src/runtime/private.h=trunk Or, tl;dr: A method that existed before was overridden in a subclass. Because ObjC uses dynamic dispatch, this symbol is never referenced, as all method calls are dispatched via the runtime. But the metadata changes so the runtime knows this method is now overridden - without accessing that symbol. -- Jonathan
CVS: cvs.openbsd.org: ports
CVSROOT:/cvs Module name:ports Changes by: st...@cvs.openbsd.org 2023/09/11 06:06:50 Modified files: net/eduvpn/documentation: Makefile distinfo net/eduvpn/documentation/pkg: PLIST Log message: update eduvpn-documentation
CVS: cvs.openbsd.org: ports
CVSROOT:/cvs Module name:ports Changes by: t...@cvs.openbsd.org2023/09/11 05:32:20 Modified files: security/c2sp-testvectors: Makefile distinfo Log message: Update c2sp-testvectors to 20230910
CVS: cvs.openbsd.org: ports
CVSROOT:/cvs Module name:ports Changes by: st...@cvs.openbsd.org 2023/09/11 05:21:24 Modified files: security/gopass: Makefile distinfo modules.inc Log message: update to gopass-1.15.7
Re: Asterisk on Octeon
-cc misc@ On Mon, Sep 11 2023, Alex Frolkin wrote: > Hi all, > > Has anyone had any success running Asterisk on Octeon (in my case, an > EdgeRouter 6P, running OpenBSD 7.3)? > > If I try to build the port, it fails in the same way as the automated > package builds, i.e.: > > > http://build-failures.rhaalovely.net/mips64/2023-08-29/telephony/asterisk/20.log > > I don't know what's going on there, but if I run "make menuselect" and > disable res_geolocation (and remove the corresponding bits from > pkg/PLIST-main), it builds fine. Note that I'm building with all the > no_* flavours enabled. The build log has this: --8<-- cc -g -Wl,-znoexecstack -nostartfiles -nodefaultlibs -nostdlib -r -Wl,-b,binary -o res_geolocation/pidf_lo_test.o res_geolocation/pidf_lo_test.xml cc -g -Wl,-znoexecstack -nostartfiles -nodefaultlibs -nostdlib -r -Wl,-b,binary -o res_geolocation/pidf_to_eprofile.o res_geolocation/pidf_to_eprofile.xslt cc -g -Wl,-znoexecstack -nostartfiles -nodefaultlibs -nostdlib -r -Wl,-b,binary -o res_geolocation/eprofile_to_pidf.o res_geolocation/eprofile_to_pidf.xslt -->8-- and later: --8<-- /usr/bin/ld: res_geolocation/pidf_lo_test.o: warning: linking PIC files with non-PIC files /usr/bin/ld: res_geolocation/pidf_lo_test.o: linking 32-bit code with 64-bit code /usr/bin/ld: failed to merge target specific data of file res_geolocation/pidf_lo_test.o /usr/bin/ld: res_geolocation/pidf_to_eprofile.o: warning: linking PIC files with non-PIC files /usr/bin/ld: res_geolocation/pidf_to_eprofile.o: linking 32-bit code with 64-bit code /usr/bin/ld: failed to merge target specific data of file res_geolocation/pidf_to_eprofile.o /usr/bin/ld: res_geolocation/eprofile_to_pidf.o: warning: linking PIC files with non-PIC files /usr/bin/ld: res_geolocation/eprofile_to_pidf.o: linking 32-bit code with 64-bit code /usr/bin/ld: failed to merge target specific data of file res_geolocation/eprofile_to_pidf.o -->8-- It's a strange way to call ld -r -b binary IMO. I suspect that it results in cc(1) not passing the proper ABI flags to ld(1). You could run cc(1) -v using both the command above and a dummy ''cc -v main.c'' to see the difference in the ld(1) call. -- jca | PGP : 0x1524E7EE / 5135 92C1 AD36 5293 2BDF DDCC 0DFA 74AE 1524 E7EE
Re: UPDATE: objfw-1.0.2
On Mon, Sep 11 2023, Jonathan Schleifer wrote: > And here's an update to the just released 1.0.2 instead. This is 1.0.1 > with some additional fixes for macOS, so not important for OpenBSD. But > when updating anyway, why not update to the latest version :). This diff and the previous one were likely mangled by your MUA. There are hints available: https://www.kernel.org/doc/html/latest/process/email-clients.html Or you may just send diffs as attachments (inline is still preferred). Using /usr/src/lib/check_sym I can spot: /usr/local/lib/libobjfwtls.so.0.0 --> /usr/obj/pobj/objfw-1.0.2/fake-amd64/usr/local/lib/libobjfwtls.so.0.0 Dynamic export changes: added: .objc_sel_nameof_isWaitingForDelimiter Applying blindly our rules for shared libraries, this would warrant a minor bump because of the additional interface. But maybe the initial '.' in the name means it's a local, private symbol? nm -g tells me it's a weak symbol so with public visibility. Insights welcome. -- jca | PGP : 0x1524E7EE / 5135 92C1 AD36 5293 2BDF DDCC 0DFA 74AE 1524 E7EE
Re: Asterisk on Octeon
On 2023/09/11 10:39, Alex Frolkin wrote:
> Hi all,
>
> Has anyone had any success running Asterisk on Octeon (in my case, an
> EdgeRouter 6P, running OpenBSD 7.3)?
>
> If I try to build the port, it fails in the same way as the automated
> package builds, i.e.:
>
>
> http://build-failures.rhaalovely.net/mips64/2023-08-29/telephony/asterisk/20.log
>
> I don't know what's going on there, but if I run "make menuselect" and
> disable res_geolocation (and remove the corresponding bits from
> pkg/PLIST-main), it builds fine. Note that I'm building with all the
> no_* flavours enabled.
>
> However, some seconds after startup, it segfaults. I'm pretty sure this
> is down to the PJSIP bits, because if I stop Asterisk loading those, it
> seems to run fine. For my use case, however, I definitely need SIP.
>
> I've tried all three available Asterisk versions (16, 18, 20), and the
> result is exactly the same in all three cases.
>
> I could probably run Asterisk 16 which still has the old chan_sip module
> (removed in 18 and 20), but this seems like a dead-end solution.
>
> At this point, I'm just about ready to give up and run Asterisk
> elsewhere and a SIP proxy on my EdgeRouter, but I thought I'd ask in
> case anyone else has managed to find a way to make it work.
No idea what's up on Octeon, but you could try building it with gcc
to check if that makes any difference.
Index: Makefile.inc
===
RCS file: /cvs/ports/telephony/asterisk/Makefile.inc,v
retrieving revision 1.19
diff -u -p -r1.19 Makefile.inc
--- Makefile.inc25 May 2023 10:46:26 - 1.19
+++ Makefile.inc11 Sep 2023 10:54:17 -
@@ -34,7 +34,7 @@ DPB_PROPERTIES= parallel
# Asterisk requires either nested functions (gcc extension), or -fblocks
(clang).
# Keep telephony/asterisk-g729 in sync.
-COMPILER= base-clang ports-gcc
+COMPILER= ports-gcc
# XXX bsd.port.arch.mk is included below, before compiler.port.mk can set
# ONLY_FOR_ARCHS
ONLY_FOR_ARCHS=${CLANG_ARCHS} ${GCC49_ARCHS}
@@ -168,7 +168,7 @@ CFLAGS += -DHAVE_OPENSSL_BIO_METHOD
.include
-.if ${PROPERTIES:Mclang}
+.if 0 && ${PROPERTIES:Mclang}
LDFLAGS += -lBlocksRuntime
BLOCKSLIBDEP = devel/libdispatch
BLOCKSWANTLIB =BlocksRuntime
CVS: cvs.openbsd.org: ports
CVSROOT:/cvs Module name:ports Changes by: st...@cvs.openbsd.org 2023/09/11 04:50:43 Modified files: www/p5-libwww : Makefile distinfo Log message: update to p5-libwww-6.72
CVS: cvs.openbsd.org: ports
CVSROOT:/cvs Module name:ports Changes by: st...@cvs.openbsd.org 2023/09/11 04:49:23 Modified files: lang/go: go.port.mk Log message: # increment _MODGO_SYSTEM_VERSION in go.port.mk after updating to a new # version, to trigger updates of go-compiled ports
Asterisk on Octeon
Hi all, Has anyone had any success running Asterisk on Octeon (in my case, an EdgeRouter 6P, running OpenBSD 7.3)? If I try to build the port, it fails in the same way as the automated package builds, i.e.: http://build-failures.rhaalovely.net/mips64/2023-08-29/telephony/asterisk/20.log I don't know what's going on there, but if I run "make menuselect" and disable res_geolocation (and remove the corresponding bits from pkg/PLIST-main), it builds fine. Note that I'm building with all the no_* flavours enabled. However, some seconds after startup, it segfaults. I'm pretty sure this is down to the PJSIP bits, because if I stop Asterisk loading those, it seems to run fine. For my use case, however, I definitely need SIP. I've tried all three available Asterisk versions (16, 18, 20), and the result is exactly the same in all three cases. I could probably run Asterisk 16 which still has the old chan_sip module (removed in 18 and 20), but this seems like a dead-end solution. At this point, I'm just about ready to give up and run Asterisk elsewhere and a SIP proxy on my EdgeRouter, but I thought I'd ask in case anyone else has managed to find a way to make it work. Many thanks, Alex
CVS: cvs.openbsd.org: ports
CVSROOT:/cvs Module name:ports Changes by: o...@cvs.openbsd.org2023/09/11 04:24:20 Modified files: www/smarc : Makefile distinfo Log message: update www/smarc to 0.2 changelog: - smingest: terminate CSV records with CRLF - msearchd(8): fixed database path typo in the FILES section - msearchd: show excerpt of search results - minor improvements to smarc(7)
CVS: cvs.openbsd.org: ports
CVSROOT:/cvs Module name:ports Changes by: lan...@cvs.openbsd.org 2023/09/11 04:18:58 Modified files: x11/xfce4/xfce4-notifyd: Makefile Log message: x11/xfce4/xfce4-notifyd: make sure canberra-gtk3 isnt detected should fix a hidden dep issue reported by edd@
CVS: cvs.openbsd.org: ports
CVSROOT:/cvs Module name:ports Changes by: bl...@cvs.openbsd.org 2023/09/11 03:44:38 Modified files: misc/open62541 : Makefile misc/open62541/patches: patch-plugins_crypto_openssl_ua_pki_openssl_c Log message: Use legacy verifier for open62541. The way the OPC UA standard requires certificates and how open62541 uses the OpenSSL API causes self signed certificates to fail. Until LibreSSL fixes this, set X509_V_FLAG_LEGACY_VERIFY flag as workaround. from Anton Borowka; OK tb@
CVS: cvs.openbsd.org: ports
CVSROOT:/cvs Module name:ports Changes by: fcam...@cvs.openbsd.org 2023/09/11 02:25:46 Modified files: audio/schismtracker: Makefile distinfo audio/schismtracker/patches: patch-configure_ac Log message: Update schismtracker to 20230906.
Re: CVS: cvs.openbsd.org: ports
On Sun, Sep 10, 2023 at 08:49:15PM -0600, Daniel Dickman wrote: > CVSROOT: /cvs > Module name: ports > Changes by: dan...@cvs.openbsd.org 2023/09/10 20:49:15 > > Modified files: > lang/pcc/pcc : Makefile distinfo > lang/pcc/pcc/patches: patch-arch_powerpc_local2_c > patch-arch_powerpc_local_c > patch-arch_powerpc_macdefs_h > patch-arch_powerpc_table_c > Added files: > lang/pcc/pcc/patches: patch-arch_powerpc_code_c > Removed files: > lang/pcc/pcc/patches: patch-arch_i386_code_c > patch-arch_i386_local_c > > Log message: > update to pcc 20230830 > > As usual, big thanks to gkoehler@ for the PowerPC patches $ make ===> Building from scratch pcc-1.1.0.20230817 ===> Verifying specs: c ===> found c.97.1 ===> Checking files for pcc-1.1.0.20230817 >> No size recorded for pcc-20230817.tgz *** Error 1 in . (/usr/ports/infrastructure/mk/bsd.port.mk:3275 '/usr/ports/distfiles/pcc-20230817.tgz': @lock=pcc-20230817.tgz.dist; doas -...) -- Antoine
CVS: cvs.openbsd.org: ports
CVSROOT:/cvs Module name:ports Changes by: fcam...@cvs.openbsd.org 2023/09/11 02:09:01 Modified files: textproc/yq: Makefile distinfo Log message: Update yq to 3.2.3.
CVS: cvs.openbsd.org: ports
CVSROOT:/cvs Module name:ports Changes by: fcam...@cvs.openbsd.org 2023/09/11 02:00:46 Modified files: devel/perltidy : Makefile distinfo devel/perltidy/pkg: PLIST Log message: Update perltidy to 20230909.
CVS: cvs.openbsd.org: ports
CVSROOT:/cvs Module name:ports Changes by: rob...@cvs.openbsd.org 2023/09/11 02:00:22 Modified files: sysutils/salt : Makefile distinfo Log message: update to 3006.3
enable -fstack-clash-protection in llvm ports
hi,
currently building mozillas, i get tons of this on stderr:
warning: clang-13: warning: argument unused during compilation:
'-fstack-clash-protection' [-Wunused-command-line-argument]
filed an upstream issue about it
(https://bugzilla.mozilla.org/show_bug.cgi?id=1852202) to realize its an
llvm feature that was originally added in llvm 11
(https://reviews.llvm.org/D68720), but only enabled on
linux, and later on (14 or 15) in FreeBSD
(https://github.com/llvm/llvm-project/blob/b0ea2790c41db65b3c283f78a5f534bc26fc6f8f/clang/lib/Driver/ToolChains/Clang.cpp#L3476)
- according to
https://reviews.llvm.org/D68720#2415629 it should have been enabled
everywhere. In mozilla-land of course the flag is added if clang > 11 is
found on non-osx/non-windows, which includes OpenBSD, which triggers the
-Wunused-command-line-argument warning.
it's to protect against
https://www.qualys.com/2017/06/19/stack-clash/stack-clash.txt
the attached patch enables it in both ports llvm flavors. Been able to
build firefox with way less noise on stderr with that.
ofc, this can/should also be enabled in base llvm.
Landry
Index: 13/Makefile
===
RCS file: /cvs/ports/devel/llvm/13/Makefile,v
retrieving revision 1.6
diff -u -p -r1.6 Makefile
--- 13/Makefile 8 Sep 2023 14:11:33 - 1.6
+++ 13/Makefile 11 Sep 2023 06:44:34 -
@@ -2,7 +2,7 @@ LLVM_MAJOR =13
LLVM_VERSION = ${LLVM_MAJOR}.0.0
LLVM_PKGSPEC = >=13,<14
-REVISION-main =11
+REVISION-main =12
REVISION-lldb =4
REVISION-python = 3
Index: 13/patches/patch-clang_lib_Driver_ToolChains_Clang_cpp
===
RCS file:
/cvs/ports/devel/llvm/13/patches/patch-clang_lib_Driver_ToolChains_Clang_cpp,v
retrieving revision 1.1.1.1
diff -u -p -r1.1.1.1 patch-clang_lib_Driver_ToolChains_Clang_cpp
--- 13/patches/patch-clang_lib_Driver_ToolChains_Clang_cpp 3 Sep 2023
15:59:27 - 1.1.1.1
+++ 13/patches/patch-clang_lib_Driver_ToolChains_Clang_cpp 11 Sep 2023
06:44:34 -
@@ -39,6 +39,7 @@
- Turn on pointer-authentication on arm64 as well by default. This means
we effectively enable -mbranch-protection=standard on arm64 now.
- Make sure -msign-return-address doesn't disable BTI support.
+- Enable -fstack-clash-protection on OpenBSD
Index: clang/lib/Driver/ToolChains/Clang.cpp
--- clang/lib/Driver/ToolChains/Clang.cpp.orig
@@ -80,6 +81,15 @@ Index: clang/lib/Driver/ToolChains/Clang
MipsTargetFeature = llvm::StringSwitch(Value)
.Case("-mips1", "+mips1")
+@@ -3180,7 +3194,7 @@ static void RenderSCPOptions(const ToolChain , cons
+ ArgStringList ) {
+ const llvm::Triple = TC.getEffectiveTriple();
+
+- if (!EffectiveTriple.isOSLinux())
++ if (!EffectiveTriple.isOSOpenBSD() && !EffectiveTriple.isOSLinux())
+ return;
+
+ if (!EffectiveTriple.isX86() && !EffectiveTriple.isSystemZ() &&
@@ -4943,9 +4957,12 @@ void Clang::ConstructJob(Compilation , const JobActi
OFastEnabled ? options::OPT_Ofast : options::OPT_fstrict_aliasing;
// We turn strict aliasing off by default if we're in CL mode, since MSVC
Index: 16/Makefile
===
RCS file: /cvs/ports/devel/llvm/16/Makefile,v
retrieving revision 1.7
diff -u -p -r1.7 Makefile
--- 16/Makefile 8 Sep 2023 14:11:33 - 1.7
+++ 16/Makefile 11 Sep 2023 06:44:34 -
@@ -2,7 +2,7 @@ LLVM_MAJOR =16
LLVM_VERSION = ${LLVM_MAJOR}.0.6
LLVM_PKGSPEC = >=16,<17
-REVISION-main =5
+REVISION-main =6
REVISION-lldb =1
REVISION-python = 0
Index: 16/patches/patch-clang_lib_Driver_ToolChains_Clang_cpp
===
RCS file:
/cvs/ports/devel/llvm/16/patches/patch-clang_lib_Driver_ToolChains_Clang_cpp,v
retrieving revision 1.1.1.1
diff -u -p -r1.1.1.1 patch-clang_lib_Driver_ToolChains_Clang_cpp
--- 16/patches/patch-clang_lib_Driver_ToolChains_Clang_cpp 3 Sep 2023
16:00:03 - 1.1.1.1
+++ 16/patches/patch-clang_lib_Driver_ToolChains_Clang_cpp 11 Sep 2023
06:44:34 -
@@ -27,7 +27,17 @@ Index: clang/lib/Driver/ToolChains/Clang
MipsTargetFeature = llvm::StringSwitch(Value)
.Case("-mips1", "+mips1")
-@@ -5289,9 +5301,12 @@ void Clang::ConstructJob(Compilation , const JobActi
+@@ -3363,7 +3375,8 @@ static void RenderSCPOptions(const ToolChain , cons
+ ArgStringList ) {
+ const llvm::Triple = TC.getEffectiveTriple();
+
+- if (!EffectiveTriple.isOSFreeBSD() && !EffectiveTriple.isOSLinux())
++ if (!EffectiveTriple.isOSFreeBSD() && !EffectiveTriple.isOSOpenBSD() &&
++ !EffectiveTriple.isOSLinux())
+ return;
+
+ if (!EffectiveTriple.isX86() && !EffectiveTriple.isSystemZ()
