Re: update py-tornado
On 2021/01/18 02:52, Daniel Dickman wrote: > Below diff updates py-tornado to the latest version which is now > python3-only. > > This update is needed so jupyter-notebook can be updated to the latest > version. This broke www/apertium-apy; AttributeError: module 'tornado.web' has no attribute 'asynchronous' https://github.com/apertium/apertium-apy/pull/169
Re: Add MODOCAML_RUNDEP to ocaml.port.mk
On 2021/01/21 06:43, Bjorn Ketelaars wrote:
> On Wed 20/01/2021 21:42, Jeremie Courreges-Anglas wrote:
> > On Wed, Jan 20 2021, Bjorn Ketelaars wrote:
> > > (Maintainer timeout)
> > >
> > > ocaml is currently a RDEP for all ports that are build with it. This is
> > > unnecessary for a couple of them, i.e. net/unison.
> >
> > As far as I know, programs written in OCaml should run without the OCaml
> > runtime installed on ${OCAML_NATIVE_ARCHS}, currently i386 and amd64.
> > Except for OCaml programs that make direct use of the OCaml runtime, of
> > course... But the rundep is still needed on non-native archs.
> >
> > > I would like to
> > > propose the addition of MODOCAML_RUNDEP and MODOCAML_BUILDDEP, which are
> > > modelled on python.port.mk.
> > >
> > > Default behaviour is not changed. Setting MODOCAML_RUNDEP=No in a
> > > Makefile excludes ocaml as RDEP.
> > >
> > > OK?
> >
> > Your diff makes sense I think, but you can't just use it to
> > disable the run-dep in net/unison: you'd break unison installs on
> > non-native archs.
>
> Oops, I didn't think about the above.
>
> I will look further for a fitting, clean solution that serves all
> arches.
>
Maybe allow MODOCAML_RUNDEP=yes/no/nonative or some similar thing?
It would be nice to handle the arch detection in ocaml.port.mk rather
than in any port using this.
Re: NEW: devel/py-bsdauth
ping From: Stuart Henderson Sent: Monday, 18 January 2021 5:23 PM To: ricardo baylon Cc: ports@openbsd.org Subject: Re: NEW: devel/py-bsdauth On 2021/01/18 01:43, ricardo baylon wrote: > Hi all, > > Greetings! > > I've written a python library for authenticating python code with OpenBSD > system. Is someone working on similar port? If not, attached is the port I > made and hopefully someone can OK this one. Tweaked version attached, ok with me for someone to import. I have changed: - move from devel to sysutils - don't hardcode MODPY_VERSION, use FLAVOR=python3/FLAVORS=python3 instead - add missing build dep on pathlib - reformat DESCR (line wrap, shorten the example - DESCR isn't the best place for docs but since it's so simple to use it will do, but best kept as short as possible)
Re: profanity: update to 0.10.0
Am Sun, 17 Jan 2021 18:09:02 +0100 schrieb Klemens Nanni : > On Sun, Jan 17, 2021 at 02:12:19PM +, Lucas wrote: > > As such, I propose the following patch, dropping MAINTAINER and > > removing version constraint for glib2 and sqlite3. > Thanks, I've committed the update without any version requirements and > removed you as maintainer. > If no one wants to step in, I'll take maintainership. I use profanity regularly and I do not want to see it fall into disrepair. -- greetings, Florian Viehweger
Re: [clang+ld.bfd] Unbreak devel/fmt
Charlene,
Thanks. This looks good to me (maintainer).
Cheers,
Ash
On Tue, 19 Jan 2021 at 10:14, Charlene Wendling wrote:
>
> Hi,
>
> > http://build-failures.rhaalovely.net/mips64/2021-01-12/devel/fmt.log
> (and the same in the current bulk for the other clang+ld.bfd arch,
> macppc)
>
> As often '-Wl,--as-needed' causes undefined reference errors with
> ld.bfd. Surprisingly gcc archs are not impacted.
>
> target_link_libraries() takes precedence over our LDFLAGS, so i could
> not use them.
>
> Sadly cmake has not meson's 'b_asneeded' out of the box, so i've added
> an AS_NEEDED option, which is ON by default, bringing no change
> to clang+ld.lld archs, and turn it OFF on clang+ld.bfd archs.
>
> That also means no REVISION bump is needed (fmt has never been built on
> impacted archs).
>
> With the below diff i can build fmt and pass its tests on macppc [0].
> mips64 seems to have further problems, i'm not 100% positive it would
> fix the build there.
>
> I would be happy to upstream this, but it seems they preferred an OS
> centric approach which doesn't play nice with our situation.
>
> Comments and feedback are welcome,
>
> Charlène.
>
>
> [0] https://bin.charlenew.xyz/fmt.log
>
>
> Index: Makefile
> ===
> RCS file: /cvs/ports/devel/fmt/Makefile,v
> retrieving revision 1.1.1.1
> diff -u -p -u -p -r1.1.1.1 Makefile
> --- Makefile2 Jan 2021 21:51:19 - 1.1.1.1
> +++ Makefile19 Jan 2021 14:59:19 -
> @@ -23,4 +23,11 @@ WANTLIB+=${COMPILER_LIBCXX}
>
> CONFIGURE_ARGS+= -DBUILD_SHARED_LIBS=on
>
> +# Fix undefined references to pthread_* symbols on clang+ld.bfd archs by
> +# disabling -Wl,--as-needed.
> +.include
> +.if !${PROPERTIES:Mlld} && ${PROPERTIES:Mclang}
> +CONFIGURE_ARGS+= -DAS_NEEDED=off
> +.endif
> +
> .include
> Index: patches/patch-CMakeLists_txt
> ===
> RCS file: patches/patch-CMakeLists_txt
> diff -N patches/patch-CMakeLists_txt
> --- /dev/null 1 Jan 1970 00:00:00 -
> +++ patches/patch-CMakeLists_txt19 Jan 2021 14:59:19 -
> @@ -0,0 +1,26 @@
> +$OpenBSD$
> +
> +Allow linking without '-Wl,--as-needed', fix the build on clang+ld.bfd archs.
> +It's needed to do it like this since target_link_libraries takes preference
> +over LDFLAGS.
> +
> +Index: CMakeLists.txt
> +--- CMakeLists.txt.orig
> CMakeLists.txt
> +@@ -59,6 +59,7 @@ set_verbose(FMT_INC_DIR ${CMAKE_INSTALL_INCLUDEDIR} CA
> + option(FMT_PEDANTIC "Enable extra warnings and expensive tests." OFF)
> + option(FMT_WERROR "Halt the compilation with an error on compiler warnings."
> +OFF)
> ++option(AS_NEEDED "Use -Wl,--as-needed for linking." ON)
> +
> + # Options that control generation of various targets.
> + option(FMT_DOC "Generate the doc target." ${MASTER_PROJECT})
> +@@ -233,7 +234,7 @@ endif ()
> +
> + if (BUILD_SHARED_LIBS)
> + if (UNIX AND NOT APPLE AND NOT ${CMAKE_SYSTEM_NAME} MATCHES "SunOS" AND
> +- NOT EMSCRIPTEN)
> ++ NOT EMSCRIPTEN AND AS_NEEDED)
> + # Fix rpmlint warning:
> + # unused-direct-shlib-dependency /usr/lib/libformat.so.1.1.0
> /lib/libm.so.6.
> + target_link_libraries(fmt -Wl,--as-needed)
Re: update py-tornado
On Thu 21/01/2021 14:46, Stuart Henderson wrote:
> On 2021/01/18 02:52, Daniel Dickman wrote:
> > Below diff updates py-tornado to the latest version which is now
> > python3-only.
> >
> > This update is needed so jupyter-notebook can be updated to the latest
> > version.
>
> This broke www/apertium-apy;
>
> AttributeError: module 'tornado.web' has no attribute 'asynchronous'
>
> https://github.com/apertium/apertium-apy/pull/169
sthen@ found that www/apertium has been broken because of a recent
py-tornado update. A fix is available [0], which - at least - fixes the
build issue.
'make test' fails two tests (see attachment), one of which is related to
tornado. I'm not sure if these failures are new.
Comments/OK?
[0] https://github.com/apertium/apertium-apy/pull/149
diff --git Makefile Makefile
index 83769d98e18..933d60fef78 100644
--- Makefile
+++ Makefile
@@ -5,7 +5,7 @@ COMMENT = apertium text translation API in Python
DISTNAME = apertium-apy-${MODPY_EGG_VERSION}
MODPY_EGG_VERSION =0.11.6
-REVISION = 0
+REVISION = 1
CATEGORIES = www
diff --git patches/patch-apertium_apy_gateway_py
patches/patch-apertium_apy_gateway_py
new file mode 100644
index 000..f125693caa4
--- /dev/null
+++ patches/patch-apertium_apy_gateway_py
@@ -0,0 +1,43 @@
+$OpenBSD$
+
+tornado6 deprecated web.asynchronous; use gen.coroutine. Taken from
+https://github.com/apertium/apertium-apy/pull/149
+
+Index: apertium_apy/gateway.py
+--- apertium_apy/gateway.py.orig
apertium_apy/gateway.py
+@@ -14,6 +14,7 @@ from collections import OrderedDict
+ import tornado
+ import tornado.httpclient
+ import tornado.httpserver
++import tornado.gen
+ import tornado.web
+ from tornado.options import enable_pretty_logging # type: ignore
+ from tornado.web import RequestHandler
+@@ -42,7 +43,7 @@ class RedirectRequestHandler(RequestHandler):
+ def initialize(self, balancer):
+ self.balancer = balancer
+
+-@tornado.web.asynchronous
++@tornado.gen.coroutine
+ def get(self):
+ path = self.request.path
+ mode, lang_pair, per_word_modes = [None] * 3
+@@ -106,7 +107,7 @@ class RedirectRequestHandler(RequestHandler):
+ self.set_header(hname, hvalue)
+ self.finish()
+
+-@tornado.web.asynchronous
++@tornado.gen.coroutine
+ def post(self):
+ self.get()
+
+@@ -120,7 +121,7 @@ class ListRequestHandler(apy.BaseHandler):
+ if callbacks:
+ self.callback = callbacks[0]
+
+-@tornado.web.asynchronous
++@tornado.gen.coroutine
+ def get(self):
+ logging.info('Overriding list call: %s %s', self.request.path,
self.get_arguments('q'))
+ if self.request.path != '/listPairs' and self.request.path != '/list':
diff --git patches/patch-apertium_apy_handlers_base_py
patches/patch-apertium_apy_handlers_base_py
new file mode 100644
index 000..98bc3dc00ca
--- /dev/null
+++ patches/patch-apertium_apy_handlers_base_py
@@ -0,0 +1,28 @@
+$OpenBSD$
+
+tornado6 deprecated web.asynchronous; use gen.coroutine. Taken from
+https://github.com/apertium/apertium-apy/pull/149
+
+Index: apertium_apy/handlers/base.py
+--- apertium_apy/handlers/base.py.orig
apertium_apy/handlers/base.py
+@@ -5,6 +5,7 @@ import sys
+ from datetime import datetime
+
+ import tornado
++import tornado.gen
+ import tornado.web
+ from tornado.escape import utf8
+ from tornado.locks import Semaphore
+@@ -180,9 +181,9 @@ class BaseHandler(tornado.web.RequestHandler):
+ self.set_header('Access-Control-Allow-Methods', 'GET,POST,OPTIONS')
+ self.set_header('Access-Control-Allow-Headers', 'accept,
cache-control, origin, x-requested-with, x-file-name, content-type')
+
+-@tornado.web.asynchronous
++@tornado.gen.coroutine
+ def post(self):
+-self.get()
++yield self.get()
+
+ def options(self):
+ self.set_status(204)
diff --git patches/patch-apertium_apy_handlers_list_modes_py
patches/patch-apertium_apy_handlers_list_modes_py
new file mode 100644
index 000..30d4782687a
--- /dev/null
+++ patches/patch-apertium_apy_handlers_list_modes_py
@@ -0,0 +1,22 @@
+$OpenBSD$
+
+tornado6 deprecated web.asynchronous; use gen.coroutine. Taken from
+https://github.com/apertium/apertium-apy/pull/149
+
+Index: apertium_apy/handlers/list_modes.py
+--- apertium_apy/handlers/list_modes.py.orig
apertium_apy/handlers/list_modes.py
+@@ -1,11 +1,11 @@
+-import tornado.web
++import tornado.gen
+
+ from apertium_apy.handlers.base import BaseHandler
+ from apertium_apy.utils import to_alpha2_code
+
+
+ class ListHandler(BaseHandler):
+-@tornado.web.asynchronous
++@tornado.gen.coroutine
+ def get(self):
+ query = self.get_argument('q', default='pairs')
+
diff --git patches/patch-apertium_apy_handlers_stats_py
patches/patch-apertium_apy_handlers_stats_py
new file mode 100644
index 000..a8affc16feb
--- /dev/null
+++ patches/patch-apertium_apy_h
Re: huge performance jump for package
On Sun, Jan 17, 2021 at 12:02:49AM +0200, Mihai Popescu wrote: > Hello, > > I am running since a few months this package endless-sky-0.9.12, always on > snapshots. A month ago, this game was very slow and sluggish. There is some > meter inside the game, showing CPU and GPU utilization. They were something > like CPU: 10% and GPU: 290% (yes, huge). > > I installed the snapshot from 13.01.2021, same game package (no version > change) and the game runs very smoothly. The markers are CPU: 3% and GPU: > 8%. Out of curiosity I wonder what is the "reason" for this: recent jump to > clang, maybe some port dependencies upgrade (SDL?) or maybe some radeondrm > improvements since I run on radeondrm. Please send in some hint. I believe there have been lots of dri2 changes and fixes recently. Might explain a lot.
Re: devel/sdl2: enable real GUID-based controller mapping
On Sat, Jan 09, 2021 at 10:46:17AM -0700, Thomas Frohwein wrote:
> Hi,
>
> The next stepping stone in my project to improve out-of-the-box
> gamecontroller support.
Haven't gotten much feedback since I sent this out. Below is a slightly
adjusted diff that generates the GUID in BSD_JoystickOpen rather than
BSD_JoystickInit, avoiding a duplicate open(2) - close(2) dance.
Some testing would be appreciated - I tested it on 4 controllers, but
it would be good to see that this works with some more controllers.
Here the Cliff notes of the diff:
- Enables using GUID to get joystick mapping from the included (or
game-specific) controller mapping.
- This replaces the prior workaround that was much more primitive, with
a fallback to standard XBox360 mapping and customization with a hand-
crafter SDL_GAMECONTROLLERCONFIG environment variable.
- The entire patch for SDL_gamecontroller.c can now be dropped.
- This gets us much closer to what's done on other platforms (Linux,
MacOS) to appropriately map a large number of gamecontrollers.
- The solution is functional, though not yet 100% ideal in regards to
the creation and storage of the GUID, as it's stored as the string
which results in conversion to the numerical and then back to the
string. We will figure out the solution to this eventually, but I
don't think this should hold up the transition as the current
solution does not adversely affect performance.
More details in the original email.
Any of {testing,feedback,oks} would be appreciated.
>
> Background: On other platforms (Linux, MacOSX), SDL2 uses a GUID for
> gamecontrollers combined with a database [1] to provide the default
> button/axis mappings. This hasn't worked on OpenBSD (or apparently any
> *BSD) and the SDL2 code resorts to simply converting the first 16 chars
> of the device name to the GUID, which doesn't help with making use of
> the gamecontrollerdb [2]. Therefore, the way we have been handling this
> so far is that the env var SDL_GAMECONTROLLERCONFIG was available to
> hold a mapping string [3]. This poses a significant barrier, as users
> have to learn the syntax of the mapping strings and find one fitting
> their controller by trial and error mostly.
>
> This diff fixes the issue. To accomplish that, a couple of tasks are
> added:
>
> - Calculate and store the GUID (Credit goes to brynet@ for finding the
> GUID calculation and writing the initial proof-of-concept code).
> - Remove the workaround code in SDL_gamecontroller.c that would either
> read the mapping from SDL_GAMECONTROLLERCONFIG if present, or
> otherwise default to the (commonly used) XBox 360 controller layout.
> - Enable the mappings in SDL_gamecontrollerdb.h for OpenBSD.
> - Assign buttons correctly - not in the order that they appear in the
> HID report, but based on their numbering in the HID report descriptor.
> - Invert Y/Ry axes for the newer XInput-type gamecontrollers. This has
> been a particularly annoying problem, as USB standards recommend the
> positive directions to be left to right and far to near, but these
> controllers just use near-to-far as the positive direction. [4]
>
> The problem with the last bullet point is that the Y/Ry axis inversion
> needs to be applied *only* to the XInput devices, and *not* to the
> older DInput devices. I can't check for XBox360 and other interface
> subclasses (as used by the kernel in uhidev.c), as
> USB_GET_INTERFACE_DESC is not exposed in the uhid(4) driver (see
> uhid_do_ioctl() in uhid.c).
> The solution I came up with is admittedly a (minor) hack. It turns out
> that the old DInput devices report their axis values as an unsigned
> 8bit integer, while the newer ones use a signed 16bit integer. With my
> collection of gamecontrollers, checking if hitem.logical_maximum is
> greater than 255 allows to reliably pick the correct handling of the
> Y/Ry axes.
>
> Other caveats:
>
> - With the newly enabled GUID detection, SDL2 checks for a matching
> controller in gamecontrollerdb.txt in the application directory.
> I found that with one game (Cryptark), this contained bogus mappings
> for the XBox One controller (see the post on tech@), so some buttons
> and the Dpad didn't work until I removed that file.
> - For some reason, the GUID for DInput devices matches the MACOSX
> entries in SDL_gamecontrollerdb.h, but the XInput devices match the
> LINUX entries. It's gonna take me a bit of time to get to the bottom
> of this; in the meantime just allowing both sets of GUID mappings
> works for the devices here on my testing
> - The BSD_JoystickGetDeviceGUID() is not ideal at this point, as it
> takes the GUID stored as a string in char **joyguids and converts it
> into the raw numerical. I haven't figured out how to do the GUID
> calculation to avoid this additional transformation step yet. In the
> meantime, I don't notice performance issues and I don't think it's
> worth holding up the GUID mapping support over th
[update] graphics/scrot 0.8 to 1.4
Hello, I noticed that the screenshot utility graphics/scrot is pretty old and missing some options people on IRC were asking for. So I looked at it. The upstream site vanished. There is an active github repository run by volunteers and that's where scrot seems to be maintained now. Scrots new home: https://github.com/resurrecting-open-source-projects/scrot # Port changes: - changed upstream to github - bump version to 1.4 - removed revision - switched configure style from gnu to autoreconf - removed wantlib: Xext freetype z - added wantlib: Xcomposite Xfixes - new build_dep: devel/autoconf-archive - two patches removed (included upstream) - fixed memset(sizeof(ptr)) in patches/patch-src_options_c The old scrot has put the README, AUTHORS, TODO and Changelog files in the doc directory. The upstream install target is not doing so anymore. This is fine for me. Besides the changelog, there's nothing of value in those files. Q: The AUTOMAKE_VERSION and AUTOCONF_VERSION are guesswork. I know that the oldest autoconf version that works is 2.63. What version is advisable to set in ports when upstream does not specify one? (The porter handbook sais this should be obvious when looking at the configure[.ac?] file. Not obvious to me... any pointers?) # Tests performed: - portcheck: ok - port-lib-depends-check: ok - Builds on amd64 There is no test suite, so I did some screenshots and tested the -s and -o flag as well as the more complex examples in the manpage. My tests all worked. One more person on IRC did some tests as well and found it working. # Changelog: (only code related changes here) Version 1.4 * Fix SIGSEGV, if running without DISPLAY environment variable. * Removed libXcursor references. * Using create-man.sh 2.0 from txt2man package from Debian. * Call XCloseDisplay on exit. This is the right thing in every X server program, to release acquired resources. * Fixed autoselect. * Fixed capturing partially hidden windows on the edge of the desktop. * Fixed required number. * Fixed SIGSEGV, option --note. * Minor fix: variable is assigned that is never used. * New Feature: capture stack/overlapping windows. Depends of libXcomposite (X11). New option: --stack or -k. * Stack windows: client list spec EWMH. Version 1.3 * Added delay option to autoselect. * Fixed bug #39, mouse pointer not captured with -a -p options. * Added -D option to specify the display to use. Version 1.2 * Changed the cursor to indicate the selection mode. * Fixed GCC >=8.0 warning: -Wstringop-truncation. * Evaluate return of strftime. * Fixes ambiguous else warning by providing proper braces for if in src/getopt.c. * Fixed missing warnings. Version 1.1 * Added (-n, --note) to draw a text. * Added (-l, --line) to define the line to use to select an area to capture. * Added a specifier ($a) to embed hostname in output file. * Added a check for autoconf-archive presence in configure.ac. * Adjusted Makefile.am to remove src/scrot_config.h when distclean. Version 1.0 * Added EXIT_FAILURE when are no arguments required by some options. Fix Debian bug #685173. * Added option: --overwrite or -o. Now, by default do not overwrite the file. Fix Debian bug #807139. * Added support to grab mouse pointer (-p option). Fix Ubuntu bug #1698375. * Added support to freeze the screen when selection is activated (-f option). * Do not use gib_eprintf in calls to X11 functions. Fix Ubuntu bug #1523212. * Fix: scrot can't save files without extension. Fix Ubuntu bug #148659. * Fix: scrot don't complain about invalid numeric argument. Fix Ubuntu bug #371784. * Fixed some compiling warnings. OK? Best Regards, Stefan Index: graphics/scrot/Makefile === RCS file: /cvs/ports/graphics/scrot/Makefile,v retrieving revision 1.17 diff -u -p -u -p -r1.17 Makefile --- graphics/scrot/Makefile 12 Jul 2019 20:47:10 - 1.17 +++ graphics/scrot/Makefile 21 Jan 2021 21:49:00 - @@ -2,25 +2,28 @@ COMMENT= commandline screen capture util -DISTNAME= scrot-0.8 -REVISION = 4 -CATEGORIES=graphics +GH_ACCOUNT = resurrecting-open-source-projects +GH_PROJECT = scrot +GH_TAGNAME = 1.4 -HOMEPAGE= http://www.linuxbrit.co.uk/scrot/ +CATEGORIES = graphics + +HOMEPAGE= https://github.com/resurrecting-open-source-projects/scrot # BSD PERMIT_PACKAGE=Yes -WANTLIB= X11 Xext c freetype m z \ - giblib>=1 Imlib2>=1 - -MASTER_SITES= http://www.linuxbrit.co.uk/downloads/ +WANTLIB = c m Imlib2 giblib X11 Xcomposite Xfixes -LIB_DEPENDS=devel/giblib \ +LIB_DEPENDS = devel/giblib \ graphics/imlib2 -CONFIGURE_STYLE= gnu +AUTOMAKE_VERSION = 1.16 +AUTOCONF_VERSION = 2.69
Re: Add MODOCAML_RUNDEP to ocaml.port.mk
On Thu, Jan 21 2021, Stuart Henderson wrote:
> On 2021/01/21 06:43, Bjorn Ketelaars wrote:
>> On Wed 20/01/2021 21:42, Jeremie Courreges-Anglas wrote:
>> > On Wed, Jan 20 2021, Bjorn Ketelaars wrote:
>> > > (Maintainer timeout)
>> > >
>> > > ocaml is currently a RDEP for all ports that are build with it. This is
>> > > unnecessary for a couple of them, i.e. net/unison.
>> >
>> > As far as I know, programs written in OCaml should run without the OCaml
>> > runtime installed on ${OCAML_NATIVE_ARCHS}, currently i386 and amd64.
>> > Except for OCaml programs that make direct use of the OCaml runtime, of
>> > course... But the rundep is still needed on non-native archs.
>> >
>> > > I would like to
>> > > propose the addition of MODOCAML_RUNDEP and MODOCAML_BUILDDEP, which are
>> > > modelled on python.port.mk.
>> > >
>> > > Default behaviour is not changed. Setting MODOCAML_RUNDEP=No in a
>> > > Makefile excludes ocaml as RDEP.
>> > >
>> > > OK?
>> >
>> > Your diff makes sense I think, but you can't just use it to
>> > disable the run-dep in net/unison: you'd break unison installs on
>> > non-native archs.
>>
>> Oops, I didn't think about the above.
>>
>> I will look further for a fitting, clean solution that serves all
>> arches.
>>
>
> Maybe allow MODOCAML_RUNDEP=yes/no/nonative or some similar thing?
Hmm, so "nonative" would be for ports that produce bytecode-only
programs, even on native archs? (No idea how many ports are affected.)
We could call it "bytecode" then, that would seem a bit more descriptive
than a plain MODOCAML_RUNDEP=Yes in a port Makefile.
And then MODOCAML_RUNDEP=Yes would be useful for ports that always
use lang/ocaml programs/files at runtime?
> It would be nice to handle the arch detection in ocaml.port.mk rather
> than in any port using this.
Here's the simple diff I had in mind yesterday, on top of Bjorn's diff.
It probably helps Bjorn with unison but it would require testing all
other OCaml programs, and bumping REVISION for a bunch of them.
Maybe not the easiest or safest approach.
I suspect that most people caring about OCaml in ports have thought
about this before, hopefully they can share their ideas. :)
Index: ocaml.port.mk
===
--- ocaml.port.mk.orig
+++ ocaml.port.mk
@@ -37,9 +37,15 @@ MODOCAML_RUN_DEPENDS=lang/ocaml
MODOCAML_BUILD_DEPENDS=lang/ocaml
# Assume that we want to automatically add ocaml to BUILD_DEPENDS
-# and RUN_DEPENDS unless the port specifically requests not to.
+# unless the port specifically requests not to.
+# Automatically add ocaml to RUN_DEPENDS on non-native archs
+# unless the port specifically requests not to.
MODOCAML_BUILDDEP?=Yes
+.if ${MODOCAML_NATIVE} == Yes
+MODOCAML_RUNDEP?= No
+.else
MODOCAML_RUNDEP?= Yes
+.endif
.if ${NO_BUILD:L} == no && ${MODOCAML_BUILDDEP:L} == yes
BUILD_DEPENDS+=${MODOCAML_BUILD_DEPENDS}
--
jca | PGP : 0x1524E7EE / 5135 92C1 AD36 5293 2BDF DDCC 0DFA 74AE 1524 E7EE
Re: Add MODOCAML_RUNDEP to ocaml.port.mk
On Thu, Jan 21, 2021 at 5:30 PM Jeremie Courreges-Anglas wrote: > > > I suspect that most people caring about OCaml in ports have thought > about this before, hopefully they can share their ideas. :) > Back in 2012, there was this idea from avsm and chrisz I believe: https://marc.info/?l=openbsd-ports&m=135177285703781&w=2 https://marc.info/?l=openbsd-ports&m=135307318613580&w=2 Maybe worth looking into reviving it? Not sure if it helps the unison case, but thought I'd at least point to the thread in case there are some useful ideas there. My request is that it doesn't make it harder for me to test coq and compcert updates on various platforms (i386, amd64, powerpc and aarch64 are the main ones of interest to me)
UPDATE mail/s-nail
Hello again. Well, unfortunately, yes. I apologise for the inconvenience of yet another bugfix release. Also one security related SMTP fix. Index: Makefile === RCS file: /cvs/ports/mail/s-nail/Makefile,v retrieving revision 1.30 diff -u -p -r1.30 Makefile --- Makefile30 Dec 2020 14:25:09 - 1.30 +++ Makefile21 Jan 2021 23:34:25 - @@ -2,7 +2,7 @@ COMMENT= SysV mail/BSD Mail/POSIX mailx: send and receive mail -DISTNAME= s-nail-14.9.20 +DISTNAME= s-nail-14.9.21 CATEGORIES=mail HOMEPAGE= https://www.sdaoden.eu/code.html\#s-mailx Index: distinfo === RCS file: /cvs/ports/mail/s-nail/distinfo,v retrieving revision 1.22 diff -u -p -r1.22 distinfo --- distinfo30 Dec 2020 14:25:09 - 1.22 +++ distinfo21 Jan 2021 23:34:25 - @@ -1,2 +1,2 @@ -SHA256 (s-nail-14.9.20.tar.gz) = 3uKTILgc9Ti2myKz/54wmkf1xo2Xhlgfd26jrLMneAo= -SIZE (s-nail-14.9.20.tar.gz) = 1089331 +SHA256 (s-nail-14.9.21.tar.gz) = U9dfAYj1v6v+uw5JyhCqpoJAHv0viJskxCDg6Lb0cZc= +SIZE (s-nail-14.9.21.tar.gz) = 1091097 --steffen | |Der Kragenbaer,The moon bear, |der holt sich munter he cheerfully and one by one |einen nach dem anderen runter wa.ks himself off |(By Robert Gernhardt)
Re: Add MODOCAML_RUNDEP to ocaml.port.mk
On Thu, Jan 21 2021, Daniel Dickman wrote: > On Thu, Jan 21, 2021 at 5:30 PM Jeremie Courreges-Anglas > wrote: >> >> >> I suspect that most people caring about OCaml in ports have thought >> about this before, hopefully they can share their ideas. :) >> > > Back in 2012, there was this idea from avsm and chrisz I believe: > > https://marc.info/?l=openbsd-ports&m=135177285703781&w=2 > https://marc.info/?l=openbsd-ports&m=135307318613580&w=2 > > Maybe worth looking into reviving it? > > Not sure if it helps the unison case, but thought I'd at least point > to the thread in case there are some useful ideas there. IIUC Christopher's proposal would make all OCaml ports depend on ocamlrun, on all archs. But on native archs, some OCaml ports are built with ocamlopt, and thus don't need ocamlrun. Combining both proposals, unison--no_x11 could be standalone on native archs, and depend only on ocaml-run on non-native archs. > My request is that it doesn't make it harder for me to test coq and > compcert updates on various platforms (i386, amd64, powerpc and > aarch64 are the main ones of interest to me) Less RUN_DEPENDS on native archs means that native archs hit missing deps problems first, which is good (most people test on a fast amd64 machine first). -- jca | PGP : 0x1524E7EE / 5135 92C1 AD36 5293 2BDF DDCC 0DFA 74AE 1524 E7EE
Re: remove devel/p5-Regexp-Copy
On Tue, Jan 19, 2021 at 05:45:47PM +0100, Alexander Bluhm wrote: > Hi, > > I would like to remove devel/p5-Regexp-Copy. > > - OpenBSD make test fails: > > http://bluhm.genua.de/portstest/results/2021-01-19T06%3A17%3A03Z/logs/devel/p5-Regexp-Copy/make.log > - Uptream tests are broken since Perl 5.11: > http://matrix.cpantesters.org/?dist=Regexp-Copy+0.06 > - Last upstream commit is from 2003. > - Port has no reverse dependencies. > > ok? These seem like good reasons to me, OK afresh1@ > Do I need any quirks for a simple remove? This I don't know, but I think there's an "obsolete_reason" section for that sort of thing.
Alpine mail client. Fresh install of 6.8. "Mail" works but Alpine problems
Just set up a brand new ASUS desktop with 6.8, so as to replace my old mail
server,
which died after 15 years or so (but well backed up and have 20 odd years of
emails
saved on it). I have a few local users on it, and we are used to using good
old alpine.
The basic "Mail" client works fine, both sending and receiving, however, having
installed
the Alpine client, which seems to work fine for handling incoming mail, I was
surprised to find
that newly composed outgoing email, or replies to ones received cause Alpine to
hand endlessly,
I actually have to close the X-window to get out of it -- even so it is still
running so I
have to issue a kill -9 to stop it.
Feels to me that somehow there is a lock on some file that Alpine wants to use,
but I can't see
anything like mbox.lock or whatever. Whoops, above paragraph: s/hand/hang
Here's my /etc/main/smtp.conf
# This is the smtpd server system-wide configuration file.
# See smtpd.conf(5) for more information.
table aliases file:/etc/mail/aliases
listen on socket
# To accept external mail, replace with: listen on all
#
# listen on lo0
listen on all
action "local_mail" mbox alias
action "outbound" relay
# Uncomment the following to accept external mail for domain "example.org"
#
# match from any for domain "example.org" action "local_mail"
match from any for domain "computershop.ca" action "local_mail"
match from any for domain "hook.org" action "local_mail"
match from any for domain "mrdoctors.ca" action "local_mail"
match from local for local action "local_mail"
match from local for any action "outbound"
--
Here's text from the hanging outgoing test message:
To : aus...@hook.org
Cc :
Attchmnt:
Subject : Re: test message from gmail to cs...@computershop.ca
- Message Text -
replying to test message below from cshop
On Thu, 21 Jan 2021, Austin Hook wrote:
> test message from gmail to cs...@computershop.ca
>
[Sending mail |<= This line incomplete says something like 0%
---
Am behind our firewall so here's an extract of the rules:
emailports = "{ smtp, pop3, imap, imap3, imaps, pop3s }"
...
### Externally originated mail traffic redirected to our internal mailserver
match in on $ext_if proto tcp to $ext_if port $emailports rdr-to $emailserver
### Stop mail from Local net from IPs where no mail should come from
block in quick on $int_if proto tcp from { $hp $wlrouter $dynamic $accounting }
port $emailports
...
### Local net will need help accessing the mailserver ###
match in on $int_if inet proto tcp from $int_if:network to $ext_if \
port $emailports rdr-to $emailserver
match out on $int_if proto tcp from $int_if:network to $emailserver \
port $emailports nat-to $int_if
pass out on $ext_if from $localnet to any nat-to $ext_if
--
Getting pretty rusty here... set it up 10 years ago and it's taken me a week
of being down ,so far,
to deal with dozens of gotchas, like forgetting our last nameserver was down as
well, and the ns2 location
went away a year ago, and I should have covered that problem at the time.
Still have to set up our
web pages again. etc. etc.
I wonder if alpine used new mail ports I never heard of back then and probably
gave too much info here,
Except what really is needed. Here's a few basic questions perhaps some can
answer top of their head:
1) Anyone still running Alpine in this era of 6.8?
2) Any reason why the new pseudo-Sendmail wouldn't handle Apline as well as
the old one did?
In general, kudos, to the OpenBSD folks who bring so much basic functionality
into OpenBSD itself. I'll
be delighted if I can just use this simplified framework successfully.
3) Any further comments?
Austin
Re: Add MODOCAML_RUNDEP to ocaml.port.mk
On Thu 21/01/2021 23:29, Jeremie Courreges-Anglas wrote:
> On Thu, Jan 21 2021, Stuart Henderson wrote:
> > On 2021/01/21 06:43, Bjorn Ketelaars wrote:
> >> On Wed 20/01/2021 21:42, Jeremie Courreges-Anglas wrote:
> >> > On Wed, Jan 20 2021, Bjorn Ketelaars wrote:
> >> > > (Maintainer timeout)
> >> > >
> >> > > ocaml is currently a RDEP for all ports that are build with it. This is
> >> > > unnecessary for a couple of them, i.e. net/unison.
> >> >
> >> > As far as I know, programs written in OCaml should run without the OCaml
> >> > runtime installed on ${OCAML_NATIVE_ARCHS}, currently i386 and amd64.
> >> > Except for OCaml programs that make direct use of the OCaml runtime, of
> >> > course... But the rundep is still needed on non-native archs.
> >> >
> >> > > I would like to
> >> > > propose the addition of MODOCAML_RUNDEP and MODOCAML_BUILDDEP, which
> >> > > are
> >> > > modelled on python.port.mk.
> >> > >
> >> > > Default behaviour is not changed. Setting MODOCAML_RUNDEP=No in a
> >> > > Makefile excludes ocaml as RDEP.
> >> > >
> >> > > OK?
> >> >
> >> > Your diff makes sense I think, but you can't just use it to
> >> > disable the run-dep in net/unison: you'd break unison installs on
> >> > non-native archs.
> >>
> >> Oops, I didn't think about the above.
> >>
> >> I will look further for a fitting, clean solution that serves all
> >> arches.
> >>
> >
> > Maybe allow MODOCAML_RUNDEP=yes/no/nonative or some similar thing?
>
> Hmm, so "nonative" would be for ports that produce bytecode-only
> programs, even on native archs? (No idea how many ports are affected.)
> We could call it "bytecode" then, that would seem a bit more descriptive
> than a plain MODOCAML_RUNDEP=Yes in a port Makefile.
>
> And then MODOCAML_RUNDEP=Yes would be useful for ports that always
> use lang/ocaml programs/files at runtime?
>
> > It would be nice to handle the arch detection in ocaml.port.mk rather
> > than in any port using this.
>
> Here's the simple diff I had in mind yesterday, on top of Bjorn's diff.
> It probably helps Bjorn with unison but it would require testing all
> other OCaml programs, and bumping REVISION for a bunch of them.
> Maybe not the easiest or safest approach.
>
> I suspect that most people caring about OCaml in ports have thought
> about this before, hopefully they can share their ideas. :)
I'm not particular fond of testing all other OCaml programs.
What do you think of the diff below; lang/ocaml is added to
BUILD_DEPENDS and RUN_DEPENDS unless native-code compilation is possible
*and* the port specifically requests not to.
lang/ocaml is always added in cases of ! ${OCAML_NATIVE_ARCHS}, and
'make show=MODOCAML_RUNDEP' would show 'Ignored as native-code
compilation is not supported on this platform'.
diff --git ocaml.port.mk ocaml.port.mk
index bda7f1fc763..b5e9c863089 100644
--- ocaml.port.mk
+++ ocaml.port.mk
@@ -33,8 +33,27 @@ MODOCAML_OCAMLDOC?=ocamldoc
PKG_ARGS+=-Ddynlink=0
.endif
-RUN_DEPENDS += lang/ocaml
-BUILD_DEPENDS += lang/ocaml
+MODOCAML_RUN_DEPENDS= lang/ocaml
+MODOCAML_BUILD_DEPENDS=${MODOCAML_RUN_DEPENDS}
+
+# Add lang/ocaml to BUILD_DEPENDS and RUN_DEPENDS unless native-code
+# compilation is possible (OCAML_NATIVE_ARCHS) and the port
+# specifically requests not to.
+.if ${PROPERTIES:Mocaml_native}
+MODOCAML_BUILDDEP?=Yes
+MODOCAML_RUNDEP?= Yes
+.else
+MODOCAML_BUILDDEP:=Ignored as native-code compilation is not supported on
this platform
+MODOCAML_RUNDEP:= ${MODOCAML_BUILDDEP}
+.endif
+
+.if ${NO_BUILD:L} == no && ${MODOCAML_BUILDDEP:L} != no
+BUILD_DEPENDS+=${MODOCAML_BUILD_DEPENDS}
+.endif
+.if ${MODOCAML_RUNDEP:L} != no
+RUN_DEPENDS+= ${MODOCAML_RUN_DEPENDS}
+.endif
+
MAKE_ENV +=OCAMLFIND_DESTDIR=${DESTDIR}${TRUEPREFIX}/lib/ocaml \
OCAMLFIND_COMMANDS="ocamldoc=${MODOCAML_OCAMLDOC}"
Re: Add MODOCAML_RUNDEP to ocaml.port.mk
On Fri, Jan 22 2021, Bjorn Ketelaars wrote:
> On Thu 21/01/2021 23:29, Jeremie Courreges-Anglas wrote:
>> On Thu, Jan 21 2021, Stuart Henderson wrote:
>> > On 2021/01/21 06:43, Bjorn Ketelaars wrote:
>> >> On Wed 20/01/2021 21:42, Jeremie Courreges-Anglas wrote:
>> >> > On Wed, Jan 20 2021, Bjorn Ketelaars wrote:
>> >> > > (Maintainer timeout)
>> >> > >
>> >> > > ocaml is currently a RDEP for all ports that are build with it. This
>> >> > > is
>> >> > > unnecessary for a couple of them, i.e. net/unison.
>> >> >
>> >> > As far as I know, programs written in OCaml should run without the OCaml
>> >> > runtime installed on ${OCAML_NATIVE_ARCHS}, currently i386 and amd64.
>> >> > Except for OCaml programs that make direct use of the OCaml runtime, of
>> >> > course... But the rundep is still needed on non-native archs.
>> >> >
>> >> > > I would like to
>> >> > > propose the addition of MODOCAML_RUNDEP and MODOCAML_BUILDDEP, which
>> >> > > are
>> >> > > modelled on python.port.mk.
>> >> > >
>> >> > > Default behaviour is not changed. Setting MODOCAML_RUNDEP=No in a
>> >> > > Makefile excludes ocaml as RDEP.
>> >> > >
>> >> > > OK?
>> >> >
>> >> > Your diff makes sense I think, but you can't just use it to
>> >> > disable the run-dep in net/unison: you'd break unison installs on
>> >> > non-native archs.
>> >>
>> >> Oops, I didn't think about the above.
>> >>
>> >> I will look further for a fitting, clean solution that serves all
>> >> arches.
>> >>
>> >
>> > Maybe allow MODOCAML_RUNDEP=yes/no/nonative or some similar thing?
>>
>> Hmm, so "nonative" would be for ports that produce bytecode-only
>> programs, even on native archs? (No idea how many ports are affected.)
>> We could call it "bytecode" then, that would seem a bit more descriptive
>> than a plain MODOCAML_RUNDEP=Yes in a port Makefile.
>>
>> And then MODOCAML_RUNDEP=Yes would be useful for ports that always
>> use lang/ocaml programs/files at runtime?
>>
>> > It would be nice to handle the arch detection in ocaml.port.mk rather
>> > than in any port using this.
>>
>> Here's the simple diff I had in mind yesterday, on top of Bjorn's diff.
>> It probably helps Bjorn with unison but it would require testing all
>> other OCaml programs, and bumping REVISION for a bunch of them.
>> Maybe not the easiest or safest approach.
>>
>> I suspect that most people caring about OCaml in ports have thought
>> about this before, hopefully they can share their ideas. :)
>
> I'm not particular fond of testing all other OCaml programs.
>
> What do you think of the diff below; lang/ocaml is added to
> BUILD_DEPENDS and RUN_DEPENDS unless native-code compilation is possible
> *and* the port specifically requests not to.
>
> lang/ocaml is always added in cases of ! ${OCAML_NATIVE_ARCHS}, and
> 'make show=MODOCAML_RUNDEP' would show 'Ignored as native-code
> compilation is not supported on this platform'.
>
>
> diff --git ocaml.port.mk ocaml.port.mk
> index bda7f1fc763..b5e9c863089 100644
> --- ocaml.port.mk
> +++ ocaml.port.mk
> @@ -33,8 +33,27 @@ MODOCAML_OCAMLDOC?=ocamldoc
> PKG_ARGS+=-Ddynlink=0
> .endif
>
> -RUN_DEPENDS += lang/ocaml
> -BUILD_DEPENDS += lang/ocaml
> +MODOCAML_RUN_DEPENDS=lang/ocaml
> +MODOCAML_BUILD_DEPENDS= ${MODOCAML_RUN_DEPENDS}
> +
> +# Add lang/ocaml to BUILD_DEPENDS and RUN_DEPENDS unless native-code
> +# compilation is possible (OCAML_NATIVE_ARCHS) and the port
> +# specifically requests not to.
> +.if ${PROPERTIES:Mocaml_native}
> +MODOCAML_BUILDDEP?= Yes
> +MODOCAML_RUNDEP?=Yes
> +.else
> +MODOCAML_BUILDDEP:= Ignored as native-code compilation is not supported on
> this platform
You still need ocaml at build time, to build the bytecode and other things.
> +MODOCAML_RUNDEP:=${MODOCAML_BUILDDEP}
Should still use ?= I think.
> +.endif
> +
> +.if ${NO_BUILD:L} == no && ${MODOCAML_BUILDDEP:L} != no
> +BUILD_DEPENDS+= ${MODOCAML_BUILD_DEPENDS}
> +.endif
> +.if ${MODOCAML_RUNDEP:L} != no
> +RUN_DEPENDS+=${MODOCAML_RUN_DEPENDS}
> +.endif
> +
> MAKE_ENV += OCAMLFIND_DESTDIR=${DESTDIR}${TRUEPREFIX}/lib/ocaml \
> OCAMLFIND_COMMANDS="ocamldoc=${MODOCAML_OCAMLDOC}"
>
--
jca | PGP : 0x1524E7EE / 5135 92C1 AD36 5293 2BDF DDCC 0DFA 74AE 1524 E7EE
