On 2025/06/01 13:00, Christoph Liebender wrote:
> Alright, sign me up then.
done.
it... At least that's what the
> > code seems to be doing.
> >
> > I haven't added client restrictions as I'm not using that on OpenBSD
> > right now.
> >
> > Fortunately, there is a crate that makes unveil(2) somewhat comforable
> > to use
hing, the usage pattern of unveil is thought to be along the
lines of
if (unveil(path, perm) == -1)
err(1, "unveil");
and your unveil binding is lacking the error checking. I think you
should bubble up the errors returned by unveil(2) and call log.Fatal if
they fail, as upstre
more. Getting
> > go.port.mk to build with this vendored tarball was already complicated
> > enough, imho.
> >
> > > second thing, the usage pattern of unveil is thought to be along the
> > > lines of
> > >
> > > if (unveil(path, perm) == -1)
> > >
th, perm) == -1)
err(1, "unveil");
and your unveil binding is lacking the error checking. I think you
should bubble up the errors returned by unveil(2) and call log.Fatal if
they fail, as upstream already does for other failing points.
Yes, it makes sense to be pedantic about unveil call
OpenBSD
right now.
Fortunately, there is a crate that makes unveil(2) somewhat comforable
to use in rust, which is an additional dependency now.
Running with bad args gets you:
# wstunnel server ws://0.0.0.0: --restrict-config /asdf/jk.l
thread 'main' panicked at wstunnel-cli/s
rate that makes unveil(2) somewhat comforable
to use in rust, which is an additional dependency now.
Running with bad args gets you:
# wstunnel server ws://0.0.0.0: --restrict-config /asdf/jk.l
thread 'main' panicked at wstunnel-cli/src/main.rs:122:69:
unveil(/asdf/jk.l, r) failed:
");
and your unveil binding is lacking the error checking. I think you
should bubble up the errors returned by unveil(2) and call log.Fatal if
they fail, as upstream already does for other failing points.
Yes, it makes sense to be pedantic about unveil calls failing. After
all, it indicates mis
Christoph Liebender wrote:
> Hi ports@,
>
> this patch adds unveil(2) sandboxing to www/anubis. I think it is
> probably a good idea in this case, as anubis is intended to "take the
> beating" in a reverse-proxy setup. Because of this and the fact that the
> daemon
Hi ports@,
this patch adds unveil(2) sandboxing to www/anubis. I think it is
probably a good idea in this case, as anubis is intended to "take the
beating" in a reverse-proxy setup. Because of this and the fact that the
daemon runs as the www user (which is not a daemon user),
CXX}
>
> This should be added. Previously we had COMPILER_LANGS=c but that broke
> some configure tests. numpy 2 now actually uses C++, so it will need
> that.
That's already a problem with 1.26.4:
py3-numpy-1.26.4p6(math/py-numpy):
Missing: c++.10
(/usr/loca
On sparc64 I ran into a weird build error.
../numpy/_core/src/umath/string_buffer.h:40:45: error: macro "getchar" passed 2
arguments, but takes just 0
getchar(const unsigned char *buf, int *bytes);
^
../numpy/_core/src/umath/string_buf
broke
some configure tests. numpy 2 now actually uses C++, so it will need
that.
87 I think it's a good time to update numpy to the 2.x series. The
> > diff below gets us to 2.0.2.
> >
> > I have fixes for these which are all fairly straightforward and I can
> > commit once numpy is at the 2.x series:
> > astro/py-erfa (update 2.0.1.1 -
x in the tree is a blocker for updating quite a few ports.
> > > >
> > > > The main blocker for the update used to be boost. But now that we have
> > > > boost 1.87 I think it's a good time to update numpy to the 2.x series.
> > > > The
> &g
On 2025/05/08 10:09, Theo Buehler wrote:
> On Wed, May 07, 2025 at 07:38:29PM -0400, Daniel Dickman wrote:
> > The main blocker for the update used to be boost. But now that we have
> > boost 1.87 I think it's a good time to update numpy to the 2.x series. The
> > d
The main blocker for the update used to be boost. But now that we have
> > > boost 1.87 I think it's a good time to update numpy to the 2.x series.
> > > The
> > > diff below gets us to 2.0.2.
> > >
> > > I have fixes for these which are all fairly
ave
> > boost 1.87 I think it's a good time to update numpy to the 2.x series. The
> > diff below gets us to 2.0.2.
> >
> > I have fixes for these which are all fairly straightforward and I can
> > commit once numpy is at the 2.x series:
> > astro/p
87 I think it's a good time to update numpy to the 2.x series.
> > > The
> > > diff below gets us to 2.0.2.
> >
> > Hits an ICE on aarch64:
> >
> > ../numpy/_core/src/umath/loops_autovec.dispatch.c.src:107:43: internal
> > compiler error:
On Wed, May 07, 2025 at 07:38:29PM -0400, Daniel Dickman wrote:
> The main blocker for the update used to be boost. But now that we have
> boost 1.87 I think it's a good time to update numpy to the 2.x series. The
> diff below gets us to 2.0.2.
Hits an ICE on aarch64:
../numpy/_
On Wed, May 07, 2025 at 07:38:29PM -0400, Daniel Dickman wrote:
> numpy 1.x in the tree is a blocker for updating quite a few ports.
>
> The main blocker for the update used to be boost. But now that we have
> boost 1.87 I think it's a good time to update numpy to the 2.x se
x27;ll find the changelog at:
https://github.com/jggimi/transmission/blob/main/news/news-4.1.0-beta.2.md
transmission-4.1.0-beta.2.tgz
Description: application/tar-gz
ok
On 2025/02/16 16:40, SASANO Takayoshi wrote:
> Hi,
>
> > mtools-4.0.27 have a problem that creating disk image with -C option.
> > I found it creating SvarDOS's floppy disk image.
> > The bug looks solved at 4.0.30 but I suggest modernize 4.0.47.
>
> The problem (garbage at last sector) is st
Hi,
> mtools-4.0.27 have a problem that creating disk image with -C option.
> I found it creating SvarDOS's floppy disk image.
> The bug looks solved at 4.0.30 but I suggest modernize 4.0.47.
The problem (garbage at last sector) is still remain in 4.0.47
and I reported the problem at
https://list
-- devel/Makefile21 Jan 2025 08:08:56 - 1.2470
> +++ devel/Makefile2 Feb 2025 19:37:33 -
> @@ -1233,7 +1233,6 @@
> SUBDIR += p5-Test-YAML-Valid
> SUBDIR += p5-Test-utf8
> SUBDIR += p5-Test2-Plugin-NoWarnings
> - SUBDIR += p5-Test2-Sui
devel/Makefile
===
RCS file: /cvs/ports/devel/Makefile,v
diff -u -p -u -r1.2470 Makefile
--- devel/Makefile 21 Jan 2025 08:08:56 - 1.2470
+++ devel/Makefile 2 Feb 2025 19:37:33 -
@@ -1233,7 +1233,6 @@
S
On 2024/12/04 01:51, James Cook wrote:
> Currently when I run "make" in math/py-scypi, I see something like this:
>
> * Getting build dependencies for wheel...
>
> ERROR Missing dependencies:
> pythran<0.16.0,>=0.14.0
> gast~=0.5.0
> pythran<0
N}
-REVISION = 1
+REVISION = 2
CATEGORIES = lang
blob - /dev/null
file + lang/pythran/patches/patch-requirements_txt (mode 644)
--- /dev/null
+++ lang/pythran/patches/patch-requirements_txt
@@ -0,0 +1,10 @@
+Index: requirements.txt
+--- requirements.txt.orig
requirements.txt
+@@ -1,
extract semantic information about static Python code
-MODPY_EGG_VERSION =0.4.1
+MODPY_EGG_VERSION =0.4.2.post1
DISTNAME = beniget-${MODPY_EGG_VERSION}
PKGNAME = py-${DISTNAME}
-REVISION = 2
CATEGORIES = devel
blob - c76e2fe24fc56c2ff74b96104d574b657d6d2c60
file +
Hi,
On Sun, Oct 27, 2024 at 01:52:06PM +, Klemens Nanni wrote:
> Feedback? Objection? OK?
Looks decent to me.
I'll run with it for a few days and check all is well.
--
Best Regards
Edd Barrett
https://www.theunixzoo.co.uk
@@
+use unveil(2) to limit execution to
+- restarting itself
+- xdg-open(1) aka. to open the web interface
+
+Index: cmd/syncthing/main.go
+--- cmd/syncthing/main.go.orig
cmd/syncthing/main.go
+@@ -29,6 +29,8 @@ import (
+ "syscall"
+ "time"
g_cmsg_cloexec)
-
- if get_option('libraries')
-- if host_machine.system() == 'freebsd'
-+ if host_machine.system() in ['freebsd', 'openbsd']
- # When building for FreeBSD, epoll(7) is provided by a userspace
- # wrapper around kqu
Hello,
Here is the patch again after the update to 1.116.0
Best Regards
Index: Makefile
===
RCS file: /cvs/ports/net/synapse/Makefile,v
diff -u -p -r1.86 Makefile
--- Makefile15 Oct 2024 15:47:03 - 1.86
+++ Makefile
On Wed, 17 Jul 2024, Stuart Henderson wrote:
> > + devel/pre-commit${MODPY_FLAVOR} \
>
> hmmm, FLAVOR=python3 on a port which doesn't have a py- prefix in the
> package name isn't ideal...
>
>
There's a few more of these. bpython, ipython, ...
> + devel/pre-commit${MODPY_FLAVOR} \
hmmm, FLAVOR=python3 on a port which doesn't have a py- prefix in the
package name isn't ideal...
On Tue 16/07/2024 23:25, Daniel Dickman wrote:
> Here are the final new ports needed to update jupyter_server and then see
> inline below for the update of jupyter_server itself from the 1.x series
> to the 2.x.
>
> Once this goes in we can import jupyterlab, and then finally up
Here are the final new ports needed to update jupyter_server and then see
inline below for the update of jupyter_server itself from the 1.x series
to the 2.x.
Once this goes in we can import jupyterlab, and then finally update
jupyter notebook.
Would appreciate an ok to import the attached 2
Hi ports@,
As you know, mailman-2 still uses Python 2.7.18p11. Any plans to add
a Mailman 3 (core) port?
Thanks,
--Kor
On Fri, Dec 24, 2021 at 1:10 PM Okan Demirmen wrote:
>
> Hi,
>
> Update to 2.1.39; I've been running everything inbetween and this latest
> 2.1.39 on a li
Am Fri, Apr 19, 2024 at 08:42:41AM +0200 schrieb Martin Ziemer:
> Am Fri, Apr 12, 2024 at 09:18:02AM +0200 schrieb Martin Ziemer:
> > Am Thu, Apr 04, 2024 at 08:57:51AM +0200 schrieb Martin Ziemer:
> > > This patch updates remind from 4.3.3 to 4.3.6.
> > >
> > > Tested on amd64.
Index: Makefile
=
Am Fri, Apr 19, 2024 at 08:43:37AM +0200 schrieb Martin Ziemer:
> Am Fri, Apr 12, 2024 at 10:52:42AM +0200 schrieb Martin Ziemer:
> > There is a bug in nnn 4.9 which prevents it from creating new files.
> > (It uses none of the required modes to open a file)
> >
> > The Fix is committed Upstream
On 2/23/2024 8:29 AM, Jeremie Courreges-Anglas wrote:
> Le Thu, Feb 22, 2024 at 11:48:10PM +, Brian Callahan a écrit :
>>>
>>>> - lang/flang and lang/cparser (bcallah@ may have a plan)
>>>
>>> flang seems to be out of sync with LLVM versions any
Le Thu, Feb 22, 2024 at 11:48:10PM +, Brian Callahan a écrit :
> >
> >> - lang/flang and lang/cparser (bcallah@ may have a plan)
> >
> > flang seems to be out of sync with LLVM versions anyway.
> > cparser doesn't use python at all?
> >
>
> Flang I have updated to the latest version but som
>
>> - lang/flang and lang/cparser (bcallah@ may have a plan)
>
> flang seems to be out of sync with LLVM versions anyway.
> cparser doesn't use python at all?
>
Flang I have updated to the latest version but something else is subtly
broken; I am working on it.
CParser should work with python3
> On Feb 22, 2024, at 1:32 AM, Bryan Linton wrote:
>
> On 2024-02-17 11:51:05, Daniel Dickman wrote:
>> I would like to propose retiring these Python 2 ports:
>>
>> mail/archivemail
>>
>
> FWIW, I use archivemail semi-regularly (3-4 times a year, t
On 2024-02-17 11:51:05, Daniel Dickman wrote:
> I would like to propose retiring these Python 2 ports:
>
> mail/archivemail
>
FWIW, I use archivemail semi-regularly (3-4 times a year, to
compact and archive old mail out of my MBOXes), but if its
continued presence in the p
On 2024/02/21 20:30, Theo Buehler wrote:
> > - a few source control things (cvs2svn and py-rcparse consumers)
>
> cvs2svn is used by libressl portable for the cvs to git conversion of
> the openbsd repository. To my knowledge it's the only such tool that
> understands cvs tags and converts them to
bytes_read = xmms_xform_read (xform,
--(gchar *) (data->buffer +
data->buffer_length),
-- data->buffer_size -
data->buffer_length,
--
;
-+ gint bytes_read;
-
-- bytes_read = xmms_xform_read (xform,
--(gchar *) (data->buffer +
data->buffer_length),
--
> - a few source control things (cvs2svn and py-rcparse consumers)
cvs2svn is used by libressl portable for the cvs to git conversion of
the openbsd repository. To my knowledge it's the only such tool that
understands cvs tags and converts them to git branches.
Its main deficit of randomly reorde
sysutils/conky
> - net/mininet, our version seems to be based on an openbsd-specific fork
> of 2.2.0, but upstream 2.3.0 has python3 support now.
> - 2 emulators (dynagen, gambatte)
>
> Apart from these there a few easy updates to py3 left and the rest may
> just need to be re
On Wed, Feb 21, 2024 at 06:38:35PM +, Stuart Henderson wrote:
> > - a few pygame games I happen to like and have been slowly porting to
> > python3
>
> btw fretsonfire (py2) doesn't seem to work at all. that's the only user
> of py2 graphics/py-opengl and py2-Pillow.
I don't think fretsonf
---
>
> i'd be ok with removing this and cvs20hg and making py-rcsparse py3-only.
>
> > - sysutils/conky
>
> doesn't use python?
The xmms2 flavor depends on audio/xmms2 which uses python2. I guess we
could remove the xmms2 flavor from conky instead of updating.
&
mport. [...]
Strangely if I use "git log ." instead of "git log", the extra commit isn't
shown.
---
i'd be ok with removing this and cvs20hg and making py-rcsparse py3-only.
> - sysutils/conky
doesn't use python?
> - net/mininet, our version seems to be
e games I happen to like and have been slowly porting to
python3
- a few source control things (cvs2svn and py-rcparse consumers)
- sysutils/conky
- net/mininet, our version seems to be based on an openbsd-specific fork
of 2.2.0, but upstream 2.3.0 has python3 support now.
- 2 emulators (dy
7 Feb 2024 21:32:53 -
> @@ -1,8 +1,5 @@
> Cooledit is a suite of programs consisting of the following:
> - cooledit - a GUI based editor which allows you to call external programs
> (for instance LaTeX on a LaTeX file)
> - - s
On Sun, 18 Feb 2024 16:10:04 +0100,
Daniel Dickman wrote:
>
> >
> > I've tried FontForge not that long ago with hope that I can convert some
> > used
> > TTF fonts into bitmap fonts with huge DPI, but it crashes on start.
>
> I did try to update fontforge to almost every version of fontforge re
> On Feb 18, 2024, at 5:51 AM, Kirill A. Korinsky wrote:
>
> On Sun, 18 Feb 2024 07:57:25 +0100,
> Brian Callahan wrote:
>>
>> However, one of its dependencies is:
>> audio/solfege -> print/lilypond -> print/mftrace -> print/fontforge
>>
>> Font Forge is what has the Py2 dep. I suppose it m
On Sun, 18 Feb 2024 07:57:25 +0100,
Brian Callahan wrote:
>
> However, one of its dependencies is:
> audio/solfege -> print/lilypond -> print/mftrace -> print/fontforge
>
> Font Forge is what has the Py2 dep. I suppose it makes the most sense to
> update fontforge. Unfortunately, I don't have the
On 2/17/2024 11:51 AM, Daniel Dickman wrote:
> audio/solfege
This isn't a Python 2 port. It was converted to Python 3 by jca@ back in
2020: https://marc.info/?l=openbsd-ports-cvs&m=160485114510586&w=2
However, one of its dependencies is:
audio/solfege -> print/lilypo
7 Feb 2024 21:32:53 -
> @@ -1,8 +1,5 @@
> Cooledit is a suite of programs consisting of the following:
> - cooledit - a GUI based editor which allows you to call external programs
> (for instance LaTeX on a LaTeX file)
> - - s
-FLAVOR=python
- turns it into a programmable editor, must have Python 2.
Index: pkg/PLIST
===
RCS file: /cvs/ports/editors/cooledit/pkg/PLIST,v
diff -u -p -u -r1.9 PLIST
--- pkg/PLIST 11 Mar 2022 18:58:28 - 1.9
+++ pkg/PL
On Sat, Feb 17, 2024 at 11:51:05AM -0500, Daniel Dickman wrote:
> I would like to propose retiring these Python 2 ports:
>
> audio/mkplaylist
> audio/solfege
> editors/cooledit
> mail/archivemail
> textproc/yould
>
> These are ports that haven't s
I would like to propose retiring these Python 2 ports:
audio/mkplaylist
audio/solfege
editors/cooledit
mail/archivemail
textproc/yould
These are ports that haven't seen updates in years and have no reverse
consumers in the ports tree.
I did see a thread for archivemail where
On Thu, Feb 08, 2024 at 12:55:19PM +, Lucas Gabriel Vuotto wrote:
> Bumping sthen@ version.
I'm OK with this. This is already fixed upstream but there is no release
with that change yet.
> diff 0897d281ca8fb751c1244e4656dbb7b3c401cdfa
> 5c3506b9909b5fe2a23c821ef12030b7c422
> commit - 0
Bumping sthen@ version.
diff 0897d281ca8fb751c1244e4656dbb7b3c401cdfa
5c3506b9909b5fe2a23c821ef12030b7c422
commit - 0897d281ca8fb751c1244e4656dbb7b3c401cdfa
commit + 5c3506b9909b5fe2a23c821ef12030b7c422
blob - f2926a220810d15825049f192edcb3cb44016426
blob + 98bbf7e2f275914df615c34fb1369d
=
RCS file: /cvs/ports/sysutils/node_exporter/Makefile,v
diff -u -p -r1.20 Makefile
--- Makefile22 Dec 2023 23:42:38 - 1.20
+++ Makefile2 Feb 2024 18:19:14 -
@@ -2,6 +2,7 @@ COMMENT = prometheus exporter for hardw
MODGO_MODNAME =
Hi ports, Claudio,
I noticed my for some time already that my -current node_exporters were
returning no data for node_filesystem_* metrics. There has been a PR [0]
that updates x/sys dep to a version that doesn't issue direct syscalls.
I backported it, given that node_exporter releases are quite s
OK
On Wed, Dec 06, 2023 at 07:01:28PM +0100, Marc Espie wrote:
> With glib-2.78, gimp has become more or less unusable in large directories.
>
> The culprit is gtk+2 which is end of life.
>
> I found a backport from gtk+3 that fixes the issue.
>
> See comments
With glib-2.78, gimp has become more or less unusable in large directories.
The culprit is gtk+2 which is end of life.
I found a backport from gtk+3 that fixes the issue.
See comments in patches.
okay ?
Index: Makefile
===
RCS
> OK, I'll have some patience :-). Do note that one issue in boost::threads
> that clang16 trips on is solved by 1.83.
Boost 1.83 is committed now. Thanks to Brad for doing the heavy lifting.
> Also attached is another patch to fix the issue shown by mapnik. That's been
> around for a
> few Boost releases but upstream still has not commited a proper fix.
Ah good. That should fix freeorion as well. prusaslicer is unrelated,
and postgis (also unrelated) was fixed.
Let's see what the cl
On Fri, Nov 17, 2023 at 01:39:01PM -0500, Brad Smith wrote:
> On Fri, Nov 17, 2023 at 12:11:14PM +0100, Theo Buehler wrote:
> > On Wed, Nov 15, 2023 at 12:01:15PM +, Stuart Henderson wrote:
> > > On 2023/11/15 08:26, Otto Moerbeek wrote:
> > > > Any reason to not commit this?
> > >
> > > I did
On Fri, Nov 17, 2023 at 12:11:14PM +0100, Theo Buehler wrote:
> On Wed, Nov 15, 2023 at 12:01:15PM +, Stuart Henderson wrote:
> > On 2023/11/15 08:26, Otto Moerbeek wrote:
> > > Any reason to not commit this?
> >
> > I didn't manage to get a bulk done before the llvm 16 carnage - here's
> > an
On Fri, Nov 17, 2023 at 03:04:02PM +0900, ASOU Masato wrote:
> ping
>
> I confermed the operation using snapshot created onfNovember 16th.
> --
> ASOU Masato
>
> -- Forwarded message -
> From: 朝生正人
> Date: 2023年11月2日(木) 10:45
> Subject: devel/val
On Wed, Nov 15, 2023 at 12:01:15PM +, Stuart Henderson wrote:
> On 2023/11/15 08:26, Otto Moerbeek wrote:
> > Any reason to not commit this?
>
> I didn't manage to get a bulk done before the llvm 16 carnage - here's
> an updated diff against -current, but it will be hard to get good
> testing
ping
I confermed the operation using snapshot created onfNovember 16th.
--
ASOU Masato
-- Forwarded message -
From: 朝生正人
Date: 2023年11月2日(木) 10:45
Subject: devel/valgrind: removal syscall(2)
To:
I have moved my email address from a...@soum.co.jp to
takeasou.mas...@gmail.com
On Wed, Nov 15, 2023 at 04:34:01PM -0500, Brad Smith wrote:
> On 11/15/2023 2:26 AM, Otto Moerbeek wrote:
> > On Tue, Nov 07, 2023 at 11:55:55AM +0100, Otto Moerbeek wrote:
> >
> > > On Sat, Nov 04, 2023 at 09:45:01PM +0100, Otto Moerbeek wrote:
> > >
> >
On 11/15/2023 2:26 AM, Otto Moerbeek wrote:
On Tue, Nov 07, 2023 at 11:55:55AM +0100, Otto Moerbeek wrote:
On Sat, Nov 04, 2023 at 09:45:01PM +0100, Otto Moerbeek wrote:
On Sat, Nov 04, 2023 at 03:50:33PM -0400, Brad Smith wrote:
On 2023-11-04 4:07 a.m., Otto Moerbeek wrote:
On Fri, Nov
r copy at
+ http://www.boost.org/LICENSE_1_0.txt)
+*/
+
+/
+ *
*
+ *
--
*
+ * |0|1|
On Tue, Nov 07, 2023 at 11:55:55AM +0100, Otto Moerbeek wrote:
> On Sat, Nov 04, 2023 at 09:45:01PM +0100, Otto Moerbeek wrote:
>
> > On Sat, Nov 04, 2023 at 03:50:33PM -0400, Brad Smith wrote:
> >
> > > On 2023-11-04 4:07 a.m., Otto Moerbeek wrote:
> > >
> > > > On Fri, Nov 03, 2023 at 09:03:2
50:25 -0800
Subject: [PATCH] Upgrade happy to 1.20.1.1 to work with ghc-9.6.3
---
devel/happy/Makefile | 3 +--
devel/happy/distinfo | 4 ++--
2 files changed, 3 insertions(+), 4 deletions(-)
diff --git a/devel/happy/Makefile b/devel/happy/Makefile
index 29cc27850cc..6d3fb7fda12 100644
--- a/
Completely machine-generated, OK?
>From b6a2b6e7c8f36852406b5284c39236aff8d2f469 Mon Sep 17 00:00:00 2001
From: Greg Steuck
Date: Fri, 10 Nov 2023 11:50:25 -0800
Subject:
---
devel/happy/Makefile | 3 +--
devel/happy/distinfo | 4 ++--
devel/happy/pkg/PLIST | 16 +++-
3 files c
On Tue Nov 07, 2023 at 11:55:55AM +0100, Otto Moerbeek wrote:
> On Sat, Nov 04, 2023 at 09:45:01PM +0100, Otto Moerbeek wrote:
>
> > On Sat, Nov 04, 2023 at 03:50:33PM -0400, Brad Smith wrote:
> >
> > > On 2023-11-04 4:07 a.m., Otto Moerbeek wrote:
> > >
> > > > On Fri, Nov 03, 2023 at 09:03:20P
On Sat, Nov 04, 2023 at 09:45:01PM +0100, Otto Moerbeek wrote:
> On Sat, Nov 04, 2023 at 03:50:33PM -0400, Brad Smith wrote:
>
> > On 2023-11-04 4:07 a.m., Otto Moerbeek wrote:
> >
> > > On Fri, Nov 03, 2023 at 09:03:20PM -0400, Brad Smith wrote:
> > >
> > > > On Sun, Oct 29, 2023 at 08:13:45AM
I inquired upstream
(https://github.com/dani-garcia/vaultwarden/discussions/4033)
if adding pledge(2) and unveil(2) into Vaultwarden would be accepted,
and they replied that it would so long as it was "self-contained". I am
currently running Vaultwarden with SQLite on OpenBSD 7.4-sta
file: patches/patch-src_cmd_link_internal_ld_config_go
diff -N patches/patch-src_cmd_link_internal_ld_config_go
--- /dev/null 1 Jan 1970 00:00:00 -
+++ patches/patch-src_cmd_link_internal_ld_config_go2 Nov 2023 23:24:43
-
@@ -0,0 +1,12 @@
+Index: src/cmd/link/internal/ld/config.go
+--- src
On Sat, Nov 04, 2023 at 03:50:33PM -0400, Brad Smith wrote:
> On 2023-11-04 4:07 a.m., Otto Moerbeek wrote:
>
> > On Fri, Nov 03, 2023 at 09:03:20PM -0400, Brad Smith wrote:
> >
> > > On Sun, Oct 29, 2023 at 08:13:45AM -0400, Brad Smith wrote:
> > > > On Sun, Oct 29, 2023 at 10:52:39AM +, St
On 2023-11-04 4:07 a.m., Otto Moerbeek wrote:
On Fri, Nov 03, 2023 at 09:03:20PM -0400, Brad Smith wrote:
On Sun, Oct 29, 2023 at 08:13:45AM -0400, Brad Smith wrote:
On Sun, Oct 29, 2023 at 10:52:39AM +, Stuart Henderson wrote:
Doesn't hurt but we probably don't need #ifdef around SYS_ge
On amd64, this makes no sense because we don't use stack protector.
It is retguard. So something smells, it is like their handwritten
context switcher wasn't handling the full context before. But that
might only matter if it unrolls via two seperate methods, or if a
new function above has become
On Sun, Oct 29, 2023 at 08:13:43AM -0400, Brad Smith wrote:
> On Sun, Oct 29, 2023 at 10:52:39AM +, Stuart Henderson wrote:
> > Doesn't hurt but we probably don't need #ifdef around SYS_getrandom tbh.
> >
> > Has anyone looked at updating boost recently? It would be a good time in our
> > rel
On Sun, Oct 29, 2023 at 10:52:39AM +, Stuart Henderson wrote:
> Doesn't hurt but we probably don't need #ifdef around SYS_getrandom tbh.
>
> Has anyone looked at updating boost recently? It would be a good time in our
> release cycle and I can do an i386 bulk if anyone has a diff handy.
>
> -
tober 2023 11:16:36 Rafael Sadowski wrote:
Here is a diff to remove syscall(2) in boost. I have deliberately worked
with defined(__OpenBSD__) so that this can also push to upstream.
OK?
diff --git a/devel/boost/Makefile b/devel/boost/Makefile
index 91f25cb5c9e..2eec1a35b88 100644
--- a/devel/boos
Simple diff to remove syscall(2) in afl++. Feedback, ok?
diff --git a/devel/afl++/Makefile b/devel/afl++/Makefile
index a2fdee6fd1a..bb07eef88d0 100644
--- a/devel/afl++/Makefile
+++ b/devel/afl++/Makefile
@@ -6,7 +6,7 @@ GH_PROJECT =AFLplusplus
GH_TAGNAME = 4.05c
PKGNAME = afl
On Sun Oct 29, 2023 at 07:35:40AM +0100, Theo Buehler wrote:
> On Sun, Oct 29, 2023 at 07:21:00AM +0100, Rafael Sadowski wrote:
> > Simple diff to remove sysvall(2), feedback, ok?
>
> > ++ int err = futex(reinterpret_cast(&state_),
> > FUT
On Sun, Oct 29, 2023 at 07:21:00AM +0100, Rafael Sadowski wrote:
> Simple diff to remove sysvall(2), feedback, ok?
> ++ int err = futex(reinterpret_cast(&state_),
> FUTEX_WAIT | FUTEX_PRIVATE_FLAG,
> ++kLockedContended, nullptr, nullptr)
Why do you cast to
Simple diff to remove syscall(2). Feedback, ok?
diff --git a/x11/qt6/qtwebengine/Makefile b/x11/qt6/qtwebengine/Makefile
index a6c248a35be..bef97fa5491 100644
--- a/x11/qt6/qtwebengine/Makefile
+++ b/x11/qt6/qtwebengine/Makefile
@@ -11,6 +11,7 @@ DPB_PROPERTIES += lonesome
QT6NAME
Simple diff to remove sysvall(2), feedback, ok?
diff --git a/x11/qt5/qtwebengine/Makefile b/x11/qt5/qtwebengine/Makefile
index 1e0eb265f29..e12acdac3cf 100644
--- a/x11/qt5/qtwebengine/Makefile
+++ b/x11/qt5/qtwebengine/Makefile
@@ -15,7 +15,7 @@ COMMENT = Chromium-based web engine
OK.
On 2023-10-28 6:16 a.m., Rafael Sadowski wrote:
Here is a diff to remove syscall(2) in boost. I have deliberately worked
with defined(__OpenBSD__) so that this can also push to upstream.
OK?
diff --git a/devel/boost/Makefile b/devel/boost/Makefile
index 91f25cb5c9e..2eec1a35b88 100644
Here is a diff to remove syscall(2) in boost. I have deliberately worked
with defined(__OpenBSD__) so that this can also push to upstream.
OK?
diff --git a/devel/boost/Makefile b/devel/boost/Makefile
index 91f25cb5c9e..2eec1a35b88 100644
--- a/devel/boost/Makefile
+++ b/devel/boost/Makefile
> @@ -0,0 +1,14 @@
> +It is *ONLY* Linux that does special shit in fork(2)
just drop this comment because it is not true at all,
and then it is ok to be commited
1 - 100 of 989 matches
Mail list logo
