Re: Updating to newest sway, wlroots, and libdrm
Okay so I was able to get it to start on auto with the following diff
(the xf86drm.h header has been established as already (sort of) merged,
but I hadn't included the "renderD" change in my own tree):
diff --git xf86drm.c xf86drm.c
index 2e76f0ea..6d29184f 100644
--- xf86drm.c
+++ xf86drm.c
@@ -3517,8 +3517,11 @@ static char *drmGetMinorNameForFD(int fd, int type)
if (!dev_name)
return NULL;
-
+#ifdef __OpenBSD__
+n = snprintf(buf, sizeof(buf), dev_name, DRM_DIR_NAME, min+128);
+#else
n = snprintf(buf, sizeof(buf), dev_name, DRM_DIR_NAME, min);
+#endif
if (n == -1 || n >= sizeof(buf))
return NULL;
@@ -4585,6 +4588,7 @@ drm_public int drmGetDeviceFromDevId(dev_t find_rdev,
uint32_t flags, drmDeviceP
const char *dev_name;
int node_type, subsystem_type;
int maj, min, n, ret;
+struct stat sbuf;
if (device == NULL)
return -EINVAL;
diff --git xf86drm.h xf86drm.h
index 2cb14156..6254d912 100644
--- xf86drm.h
+++ xf86drm.h
@@ -77,10 +77,10 @@ extern "C" {
#define DRM_DEV_MODE(S_IRUSR|S_IWUSR|S_IRGRP|S_IWGRP)
#ifdef __OpenBSD__
-#define DRM_DIR_NAME "/dev"
-#define DRM_PRIMARY_MINOR_NAME "drm"
+#define DRM_DIR_NAME "/dev/dri"
+#define DRM_PRIMARY_MINOR_NAME "card"
#define DRM_CONTROL_MINOR_NAME "drmC" /* deprecated */
-#define DRM_RENDER_MINOR_NAME "drmR"
+#define DRM_RENDER_MINOR_NAME "renderD"
#else
#define DRM_DIR_NAME "/dev/dri"
#define DRM_PRIMARY_MINOR_NAME "card"
On Thu, Jan 04, 2024 at 09:20:18AM -0700, Chris Waddey wrote:
> I forgot that I needed to add this diff. There is an "#ifdef __OpenBSD__" just
> above this and a comment that looks a bit dated in the latest drm code.
>
> diff --git xf86drm.c xf86drm.c
> index 2e76f0ea..7c4f5cf0 100644
> --- xf86drm.c
> +++ xf86drm.c
> @@ -4585,6 +4585,7 @@ drm_public int drmGetDeviceFromDevId(dev_t find_rdev,
> uint32_t flags, drmDeviceP
> const char *dev_name;
> int node_type, subsystem_type;
> int maj, min, n, ret;
> +struct stat sbuf;
>
> if (device == NULL)
> return -EINVAL;
>
> On Thu, Jan 04, 2024 at 11:07:56AM +0100, Matthieu Herrb wrote:
> > On Wed, Jan 03, 2024 at 07:52:56PM -0700, Chris Waddey wrote:
> > > Hello.
> >
> > Hi,
> >
> > > I was able to get the latest version of sway working on my box after
> > > getting the latest version of wlroots to work, which was after applying
> > > the following patch to the latest version of libdrm (source obtained
> > > from https://gitlab.freedesktop.org/mesa/drm.git). I don't know if we
> > > have some patches somewhere else that handle this, but I figured I
> > > would send it your way in case it would save some effort.
> >
> > Does this include the removal of the wlr_drm protocol which was
> > committed to sway/wlroots a few hours ago ?
>
> So I just did a fresh pull/build/install of libdrm, wlroots, and
> sway. Still working with the caveats below.
>
> > I wasn't sure if OpenBSD libdrm / mesa supports linux-dmabuf which is
> > supposed to replace it.
> >
> > If it works with linux-dmabuf, that's great news. I don't think there
> > are any other significant changes since the released versions packaged
> > in ports that could impact OpenBSD.
> >
> > > I also had to do
> > >
> > > doas chmod $USER:$USER /dev/dri/* && env WLR_RENDERER=pixman
> > > startsway.sh
> >
> > Normally if you log in on the text console where you want to run sway,
> > the /dev/dri/* owndership is taken care of by fbtab(5).
>
> Yeah, I don't know why I included the chown bit. Off-topic I think.
>
> > I think setting WLR_RENDERER to pixman means that you don't use the
> > new linux-dmabuf protocol. What happens if you leave that variable
> > undefined (defaults to 'auto') ?
>
> It only works with WLR_RENDERER=pixman both before and after the
> recompile this morning. I've tried auto (which tries gles2) as well as
> vulkan. Sorry if this is just noise.
>
> > > to get everything just right. And of course I applied the patches I
> > > found in ports to sway and wlroots, but nothing else that I can
> > > think of.
> >
> > This diff is present in the /usr/xenocara/lib/libdrm tree. (not
> > exactly the same though: the whole #ifdef __OpenBSD__ part can be
> > removed now).
>
> I think I see this now. I figured it lived somewhere in there.
>
> > >
> > > ~ 0$ pkg-config --modversion libdrm
> > > 2.4.119
> > > ~ 0$ pkg-config --modversion wlroots
> > > 0.18.0-dev
> > > ~ 0$ sway --version
> > > sway version 1.9-dev-52eaa5be (Jan 3 2024, branch 'master')
> > >
> > > diff --git xf86drm.h xf86drm.h
> > > index 2cb14156..c91f157b 100644
> > > --- xf86drm.h
> > > +++ xf86drm.h
> > > @@ -77,8 +77,8 @@ extern "C" {
> > > #define DRM_DEV_MODE (S_IRUSR|S_IWUSR|S_IRGRP|S_IWGRP)
> > >
> > > #ifdef __OpenBSD__
> > > -#define DRM_DIR_NAME "/dev"
> > > -#define DRM_PRIMARY_MINOR_NAME "drm"
> > > +#define DRM_DIR_NAME "/dev/dri"
> > > +#
Re: [new] sysutils/cloud-init (again)
> > Hi folks, > > > > I'm writing to the list to add a new port. > > This is the second attempt (I'm aware of) to add this > > port. My work is based on the first attempt. > > See https://marc.info/?l=openbsd-ports&m=165239608209610 > > and https://marc.info/?l=openbsd-ports&m=165364771409636 > > > > I am one of the main contributors of BSD (mostly FreeBSD) > > patches to cloud-init, and I spent the last couple of weeks > > fixing OpenBSD issues. > > > > You can find the current state of my port here: > > https://codeberg.org/meena/openbsd-ports/src/branch/add/cloud-init/sysutils/cloud-init > > > > This is a snapshot of what the final thing will look like. > > Most importantly, you'll notice that it's using > > > > GH_ACCOUNT = igalic > > > > instead of > > > > GH_ACCOUNT = canonical > > > > because two of my Pull requests haven't been merged yet. > > After the holidays (next year), but especially with the > > next cloud-init release (in about 3 months), I expect to > > not need any extra patches. > > > > Please use the default GH_ACCOUNT and add your changes as patches, this > make it easier to keep track of what has changed. > > Will test out tonight and let you know more. > Now that the holidays are over, and cloud-init developers are back to merging my very good patches, I have switched this port back to canonical's GH_ACCOUNT and declare it finished. Browse, https://codeberg.org/meena/openbsd-ports/src/branch/add/cloud-init/sysutils/cloud-init see patch: https://codeberg.org/meena/openbsd-ports/commit/b671f56ebadb601b13385750b84018603e96bfe3 download and apply patch: https://codeberg.org/meena/openbsd-ports/commit/b671f56ebadb601b13385750b84018603e96bfe3.patch > Thanks, > Aisha > > > This is a bit ambitious, because currently there are 19 > > failing tests. (On FreeBSD we're down to 0) (I have not gotten around to this yet) Thank you all in advance, Kind regards, Mina http://www.unicode-symbol.com/u/0107.html Galić
UPDATE: lang/dmd 2.106.0 => 2.106.1 + i386 package
Hi ports --
Attached is an update for dmd. It also enables a dmd package for i386.
Tests good on my i386 netbook.
The new bootstrap should hopefully be more resilient against libc and
other library bumps.
Additionally, dmd should no longer need any hacks for nobtcfi. But as my
laptop doesn't support it, I can't test directly. Reports welcome.
OK?
~BrianIndex: Makefile
===
RCS file: /cvs/ports/lang/dmd/Makefile,v
retrieving revision 1.16
diff -u -p -r1.16 Makefile
--- Makefile19 Dec 2023 22:34:04 - 1.16
+++ Makefile4 Jan 2024 23:19:47 -
@@ -1,10 +1,6 @@
-# i386 forthcoming
-ONLY_FOR_ARCHS = amd64
+ONLY_FOR_ARCHS = amd64 i386
-# No BT CFI yet.
-USE_NOBTCFI = Yes
-
-V =2.106.0
+V =2.106.1
COMMENT = reference compiler for the D programming language
DISTFILES =dmd-${V}{v${V}}.tar.gz
DISTFILES.boot=dmd-${V}-bootstrap.tar.gz
@@ -26,8 +22,7 @@ SITES.phobos =https://github.com/dlang/
USE_GMAKE =Yes
MAKE_ENV = HOST_CXX="${CXX}" \
- HOST_DMD="${WRKDIR}/dmd-bootstrap/openbsd/bin${MODEL}/dmd" \
- LD_LIBRARY_PATH="${WRKSRC}/dmd-bootstrap/openbsd/bin${MODEL}"
+ HOST_DMD="${WRKDIR}/dmd-bootstrap/openbsd/bin${MODEL}/dmd"
MAKE_FILE =posix.mak
NO_TEST = Yes
@@ -43,8 +38,6 @@ MODEL = 32
post-extract:
mv ${WRKSRC}/dmd-${V} ${WRKSRC}/dmd
mv ${WRKSRC}/phobos-${V} ${WRKSRC}/phobos
- chmod 644 ${WRKDIR}/dmd-bootstrap/openbsd/bin64/lib*.so* # XXX
- cp /usr/lib/libc.so.98.* ${WRKDIR}/dmd-bootstrap/openbsd/bin64/ # XXX
# We need to do this manually.
# Yes, this is all really correct.
Index: distinfo
===
RCS file: /cvs/ports/lang/dmd/distinfo,v
retrieving revision 1.11
diff -u -p -r1.11 distinfo
--- distinfo18 Dec 2023 22:20:58 - 1.11
+++ distinfo4 Jan 2024 23:19:47 -
@@ -1,6 +1,6 @@
-SHA256 (dmd-2.106.0-bootstrap.tar.gz) =
lSsGN+CaT80zcTbEuUQHbFV0wL5DXikDGWFepL7/nbY=
-SHA256 (dmd-2.106.0.tar.gz) = EHlknEGpuODT6BxXPILYTNaHOzr8lbN9b1IGhCztx8k=
-SHA256 (phobos-2.106.0.tar.gz) = P5Ju4mkFwvb+RX560v5P6sjK2DxXGnCt6jC2zUpDZrY=
-SIZE (dmd-2.106.0-bootstrap.tar.gz) = 10233808
-SIZE (dmd-2.106.0.tar.gz) = 5936389
-SIZE (phobos-2.106.0.tar.gz) = 2761012
+SHA256 (dmd-2.106.1-bootstrap.tar.gz) =
kTaydzarj0/h54XfnTYRJ8G11ukH/DCilVEPc6EYcJw=
+SHA256 (dmd-2.106.1.tar.gz) = KY4pM6TPh5M/c+jO1Sw09L6X6ISky2+V4xdU5iuhD8s=
+SHA256 (phobos-2.106.1.tar.gz) = rPKie7N/GK/zALXziHXCrx27cgPe3cp/hws9aaeR8zM=
+SIZE (dmd-2.106.1-bootstrap.tar.gz) = 19821871
+SIZE (dmd-2.106.1.tar.gz) = 5932908
+SIZE (phobos-2.106.1.tar.gz) = 2760300
Index: patches/patch-dmd-bootstrap_openbsd_bin32_dmd_conf
===
RCS file: patches/patch-dmd-bootstrap_openbsd_bin32_dmd_conf
diff -N patches/patch-dmd-bootstrap_openbsd_bin32_dmd_conf
--- /dev/null 1 Jan 1970 00:00:00 -
+++ patches/patch-dmd-bootstrap_openbsd_bin32_dmd_conf 4 Jan 2024 23:19:47
-
@@ -0,0 +1,12 @@
+Use the bootstrap libphobos2.a when linking the initially built dmd.
+
+Index: dmd-bootstrap/openbsd/bin32/dmd.conf
+--- dmd-bootstrap/openbsd/bin32/dmd.conf.orig
dmd-bootstrap/openbsd/bin32/dmd.conf
+@@ -1,5 +1,5 @@
+ [Environment32]
+-DFLAGS=-I${TRUEPREFIX}/include/dmd/phobos
-I${TRUEPREFIX}/include/dmd/druntime/import -L-L/usr/lib -L-L${TRUEPREFIX}/lib
-L--export-dynamic -fPIC
++DFLAGS=-I%@P%/../../../dmd/druntime/src -I%@P%/../../../phobos
-L-L%@P%/../../../phobos/generated/openbsd/release/32 -L--export-dynamic -fPIC
-L-L%@P%/../../../dmd-bootstrap/openbsd/lib32
+
+ [Environment64]
+ DFLAGS=-I${TRUEPREFIX}/include/dmd/phobos
-I${TRUEPREFIX}/include/dmd/druntime/import -L-L/usr/lib -L-L${TRUEPREFIX}/lib
-L--export-dynamic -fPIC
Index: patches/patch-dmd_compiler_src_dmd_libmach_d
===
RCS file: patches/patch-dmd_compiler_src_dmd_libmach_d
diff -N patches/patch-dmd_compiler_src_dmd_libmach_d
--- /dev/null 1 Jan 1970 00:00:00 -
+++ patches/patch-dmd_compiler_src_dmd_libmach_d4 Jan 2024 23:19:47
-
@@ -0,0 +1,20 @@
+This is always 64-bit.
+
+Index: dmd/compiler/src/dmd/libmach.d
+--- dmd/compiler/src/dmd/libmach.d.orig
dmd/compiler/src/dmd/libmach.d
+@@ -484,7 +484,14 @@ struct MachObjModule
+ uint length; // in bytes
+ uint offset; // offset from start of library
+ const(char)[] name; // module name (file name) with terminating 0
++version (OpenBSD)
++{
++long file_time; // file time
++}
++else
++{
+ c_long file_time; // file time
++}
+ uint user_id;
+ uint group_id;
+ uint file_mode;
Index: patches/patch-dmd_compiler_src_dmd_link_d
===
RCS file: patches/patch-dmd_compiler_src_dmd_link_d
diff -N patches/patch-dmd_compile
[new/wip] sysutils/apmtop
Hi ports@, this is my next little project, after sysutils/lsblk. apmtop is a simple utility for measuring power consumption and statistics related to it, in a little TUI interface. There is still some work to do, but I wanted to see if anyone would be interested in using/testing this project. Obviously, this is not (yet) commit-ready, so: Comments and Suggestions are _very_ welcome! WWW: https://got.stuerz.xyz/?action=summary&path=apmtop.git PS: The keybindings are in the README.md, until I write a man page. Happy new year, Benjamin Stürz apmtop.tgz Description: Binary data
Re: UPDATE: net/tailscale
Hi! Similar diff here.
On 1/4/24 12:57, Adriano Barbosa wrote:
Hi!
This is a diff for net/tailscale v1.56.1
Changelogs:
https://github.com/tailscale/tailscale/releases/tag/v1.50.1
https://github.com/tailscale/tailscale/releases/tag/v1.52.0
https://github.com/tailscale/tailscale/releases/tag/v1.52.1
https://github.com/tailscale/tailscale/releases/tag/v1.54.0
https://github.com/tailscale/tailscale/releases/tag/v1.54.1
https://github.com/tailscale/tailscale/releases/tag/v1.56.0
https://github.com/tailscale/tailscale/releases/tag/v1.56.1
Obrigado!
--
Adriano
Index: Makefile
===
RCS file: /cvs/ports/net/tailscale/Makefile,v
retrieving revision 1.26
diff -u -p -r1.26 Makefile
--- Makefile27 Sep 2023 00:51:08 - 1.26
+++ Makefile4 Jan 2024 19:49:37 -
@@ -2,7 +2,7 @@ BROKEN-i386 = unix.EPROTO not defined
COMMENT = modern overlay-like VPN built on top of WireGuard
-V = 1.50.0
+V =1.56.1
MODGO_MODNAME = tailscale.com
MODGO_VERSION = v${V}
Index: pkg/PLIST
===
RCS file: /cvs/ports/net/tailscale/pkg/PLIST,v
retrieving revision 1.7
diff -u -p -r1.7 PLIST
--- pkg/PLIST 27 Sep 2023 00:51:08 - 1.7
+++ pkg/PLIST 4 Jan 2024 19:49:39 -
@@ -1,9 +1,11 @@
@rcscript ${RCDIR}/tailscaled
@comment bin/addlicense
+@bin bin/build-webclient
@comment bin/cloner
@bin bin/derper
@bin bin/derpprobe
@comment bin/dist
+@bin bin/generate
@comment bin/get-authkey
@comment bin/gitops-pusher
@comment bin/hello
@@ -26,4 +28,5 @@
@comment bin/testcontrol
@comment bin/testwrapper
@comment bin/tsconnect
+@bin bin/tsidp
@comment bin/viewer
These new entries should probably be "@comment"'d out.
HEADS-UP: quirks + cache
I've committed code to dissociate quirks from the pkg update-cache. It is actually fairly transparent: it just handles quirks like other packages (it can have dependencies!) If you don't update, quirks may not install properly, along with the future updatedb. If you're running snapshots, hopefully this will trickle down on all architectures SOON (within a week or two). I do intend to commit the actual split in a week or so. Technically, this makes it much easier for people to test quirks changes WITHOUT having to rebuild a full ports tree and create the updatedb, since it's going to be a separate package (and quirks depends on it). Also technically: I added an @option updatedb to tag the actual package that contains the updatedb near the end of 2023. I've waited a few weeks before actually adding @option updatedb to quirks (this is current, right, so you're supposed to update). The actual split is going to be way more silent: if your base snapshot is not uptodate, all that's gonna happen is that you're going to lose quirks+updatedb for a few updates... It's not a big change, so I'm taking my time, but it's definitely helpful for developers who want to test things. Kudoes to the guy (sorry, didn't note down your name) who brought that specific issue to my attention. Very soon, your problem will be solved !
Re: Updating to newest sway, wlroots, and libdrm
I forgot that I needed to add this diff. There is an "#ifdef __OpenBSD__" just
above this and a comment that looks a bit dated in the latest drm code.
diff --git xf86drm.c xf86drm.c
index 2e76f0ea..7c4f5cf0 100644
--- xf86drm.c
+++ xf86drm.c
@@ -4585,6 +4585,7 @@ drm_public int drmGetDeviceFromDevId(dev_t find_rdev,
uint32_t flags, drmDeviceP
const char *dev_name;
int node_type, subsystem_type;
int maj, min, n, ret;
+struct stat sbuf;
if (device == NULL)
return -EINVAL;
On Thu, Jan 04, 2024 at 11:07:56AM +0100, Matthieu Herrb wrote:
> On Wed, Jan 03, 2024 at 07:52:56PM -0700, Chris Waddey wrote:
> > Hello.
>
> Hi,
>
> > I was able to get the latest version of sway working on my box after
> > getting the latest version of wlroots to work, which was after applying
> > the following patch to the latest version of libdrm (source obtained
> > from https://gitlab.freedesktop.org/mesa/drm.git). I don't know if we
> > have some patches somewhere else that handle this, but I figured I
> > would send it your way in case it would save some effort.
>
> Does this include the removal of the wlr_drm protocol which was
> committed to sway/wlroots a few hours ago ?
So I just did a fresh pull/build/install of libdrm, wlroots, and
sway. Still working with the caveats below.
> I wasn't sure if OpenBSD libdrm / mesa supports linux-dmabuf which is
> supposed to replace it.
>
> If it works with linux-dmabuf, that's great news. I don't think there
> are any other significant changes since the released versions packaged
> in ports that could impact OpenBSD.
>
> > I also had to do
> >
> > doas chmod $USER:$USER /dev/dri/* && env WLR_RENDERER=pixman
> > startsway.sh
>
> Normally if you log in on the text console where you want to run sway,
> the /dev/dri/* owndership is taken care of by fbtab(5).
Yeah, I don't know why I included the chown bit. Off-topic I think.
> I think setting WLR_RENDERER to pixman means that you don't use the
> new linux-dmabuf protocol. What happens if you leave that variable
> undefined (defaults to 'auto') ?
It only works with WLR_RENDERER=pixman both before and after the
recompile this morning. I've tried auto (which tries gles2) as well as
vulkan. Sorry if this is just noise.
> > to get everything just right. And of course I applied the patches I
> > found in ports to sway and wlroots, but nothing else that I can
> > think of.
>
> This diff is present in the /usr/xenocara/lib/libdrm tree. (not
> exactly the same though: the whole #ifdef __OpenBSD__ part can be
> removed now).
I think I see this now. I figured it lived somewhere in there.
> >
> > ~ 0$ pkg-config --modversion libdrm
> > 2.4.119
> > ~ 0$ pkg-config --modversion wlroots
> > 0.18.0-dev
> > ~ 0$ sway --version
> > sway version 1.9-dev-52eaa5be (Jan 3 2024, branch 'master')
> >
> > diff --git xf86drm.h xf86drm.h
> > index 2cb14156..c91f157b 100644
> > --- xf86drm.h
> > +++ xf86drm.h
> > @@ -77,8 +77,8 @@ extern "C" {
> > #define DRM_DEV_MODE(S_IRUSR|S_IWUSR|S_IRGRP|S_IWGRP)
> >
> > #ifdef __OpenBSD__
> > -#define DRM_DIR_NAME "/dev"
> > -#define DRM_PRIMARY_MINOR_NAME "drm"
> > +#define DRM_DIR_NAME "/dev/dri"
> > +#define DRM_PRIMARY_MINOR_NAME "card"
> > #define DRM_CONTROL_MINOR_NAME "drmC" /* deprecated */
> > #define DRM_RENDER_MINOR_NAME "drmR"
> > #else
> >
>
Re: dnscrypt-proxy: Unable to set the close on exec flag: [function not implemented]
Hi, Unfortunately many such cases lately in Go software. I think it's due to the syscall removal thing introduced with https://marc.info/?l=openbsd-ports-cvs&m=170057559813269&w=2 because it still works if you build it with a previous revision of Go. On 1/3/24 17:14, Florian Obser wrote: Hi there, dnscrypt-proxy fails thusly on -current: Jan 3 17:07:29 x395 dnscrypt-proxy[54029]: dnscrypt-proxy 2.1.5 Jan 3 17:07:29 x395 dnscrypt-proxy[54029]: Network connectivity detected Jan 3 17:07:29 x395 dnscrypt-proxy[54029]: Dropping privileges Jan 3 17:07:29 x395 dnscrypt-proxy[54029]: Unable to set the close on exec flag: [function not implemented]
Re: sparc64 bulk build report
Folks Sorry for not picking this up sooner I will fix nsh by the end of January ... sorry for the delay in getting back to you on this Tom Smyth On Wed, 20 Dec 2023 at 09:30, wrote: > Bulk build on sparc64-0a.ports.openbsd.org > > Started : Sun Dec 17 01:48:55 MST 2023 > Finished: Wed Dec 20 02:23:35 MST 2023 > Duration: 3 Days 0 hours 35 minutes > > Built using OpenBSD 7.4-current (GENERIC.MP) #1963: Fri Dec 15 16:52:31 > MST 2023 > > Built 8470 packages > > Number of packages built each day: > Dec 17: 7222 > Dec 18: 1235 > Dec 19: 4 > Dec 20: 9 > > > > Critical path missing pkgs: > http://build-failures.rhaalovely.net/sparc64/2023-12-17/summary.log > > Build failures: 41 > > http://build-failures.rhaalovely.net/sparc64/2023-12-17/audio/libsmackerdec.log > http://build-failures.rhaalovely.net/sparc64/2023-12-17/audio/ncmpc.log > http://build-failures.rhaalovely.net/sparc64/2023-12-17/audio/xmms2.log > > http://build-failures.rhaalovely.net/sparc64/2023-12-17/databases/ruby-amalgalite,ruby31.log > > http://build-failures.rhaalovely.net/sparc64/2023-12-17/devel/arm-none-eabi/gdb.log > http://build-failures.rhaalovely.net/sparc64/2023-12-17/devel/avr/gcc.log > http://build-failures.rhaalovely.net/sparc64/2023-12-17/devel/jdk/1.8.log > http://build-failures.rhaalovely.net/sparc64/2023-12-17/devel/mtxclient.log > > http://build-failures.rhaalovely.net/sparc64/2023-12-17/devel/py-debugpy,python3.log > > http://build-failures.rhaalovely.net/sparc64/2023-12-17/devel/py-thrift,python3.log > > http://build-failures.rhaalovely.net/sparc64/2023-12-17/devel/vim-command-t.log > http://build-failures.rhaalovely.net/sparc64/2023-12-17/devel/xsd.log > http://build-failures.rhaalovely.net/sparc64/2023-12-17/devel/yder.log > > http://build-failures.rhaalovely.net/sparc64/2023-12-17/emulators/libretro-pcsx-rearmed.log > > http://build-failures.rhaalovely.net/sparc64/2023-12-17/games/cataclysm-dda,no_x11.log > http://build-failures.rhaalovely.net/sparc64/2023-12-17/games/choria.log > http://build-failures.rhaalovely.net/sparc64/2023-12-17/games/emptyclip.log > http://build-failures.rhaalovely.net/sparc64/2023-12-17/games/ezquake.log > http://build-failures.rhaalovely.net/sparc64/2023-12-17/games/fheroes2.log > http://build-failures.rhaalovely.net/sparc64/2023-12-17/games/gnukem.log > http://build-failures.rhaalovely.net/sparc64/2023-12-17/games/scid.log > http://build-failures.rhaalovely.net/sparc64/2023-12-17/games/widelands.log > > http://build-failures.rhaalovely.net/sparc64/2023-12-17/graphics/spirv-tools.log > > http://build-failures.rhaalovely.net/sparc64/2023-12-17/graphics/tesseract/tesseract.log > http://build-failures.rhaalovely.net/sparc64/2023-12-17/lang/rust.log > > http://build-failures.rhaalovely.net/sparc64/2023-12-17/mail/rspamd,hyperscan.log > http://build-failures.rhaalovely.net/sparc64/2023-12-17/math/flintlib.log > http://build-failures.rhaalovely.net/sparc64/2023-12-17/math/gunits.log > http://build-failures.rhaalovely.net/sparc64/2023-12-17/math/openfst.log > http://build-failures.rhaalovely.net/sparc64/2023-12-17/net/iperf3.log > http://build-failures.rhaalovely.net/sparc64/2023-12-17/shells/nsh.log > > http://build-failures.rhaalovely.net/sparc64/2023-12-17/sysutils/borgmatic.log > > http://build-failures.rhaalovely.net/sparc64/2023-12-17/sysutils/flashrom.log > > http://build-failures.rhaalovely.net/sparc64/2023-12-17/sysutils/libvirt.log > http://build-failures.rhaalovely.net/sparc64/2023-12-17/sysutils/pftop.log > > http://build-failures.rhaalovely.net/sparc64/2023-12-17/sysutils/u-boot-asahi.log > > http://build-failures.rhaalovely.net/sparc64/2023-12-17/textproc/libmarisa,,-main.log > > http://build-failures.rhaalovely.net/sparc64/2023-12-17/textproc/rapidjson.log > > http://build-failures.rhaalovely.net/sparc64/2023-12-17/textproc/redland-bindings,-main.log > http://build-failures.rhaalovely.net/sparc64/2023-12-17/wayland/wlroots.log > http://build-failures.rhaalovely.net/sparc64/2023-12-17/x11/polybar.log > > -- Kindest regards, Tom Smyth.
Re: [UPDATE] security/rbw 1.9.0
> As it happens, a new 1.9.0 version of rbw has just been released - it > contains the aforementioned fix, as well as some other improvements[0]. Committed, thanks. The ring dependency was updated to 0.17, which has support for powerpc64 and riscv64 and supports xonly and branch-target landing pads natively. So I adjusted the NOT_FOR_ARCHS and dropped the bdep on security/rust-ring. > -MODCARGO_CRATES += ring0.16.20 # LICENSE [..] > +MODCARGO_CRATES += ring0.17.7 # LICENSE
[UPDATE] security/rbw 1.9.0
Hello, First of all, many thanks to tb@ for committing the fix for version 1.8.3 to both -current and -stable last month! As it happens, a new 1.9.0 version of rbw has just been released - it contains the aforementioned fix, as well as some other improvements[0]. Inlined below is a diff that updates rbw to said version. [0] https://github.com/doy/rbw/releases/tag/1.9.0 Regards, Raf P.S. I'm not subscribed to ports@ mailing list so please CC me if need be. Index: security/rbw/Makefile === RCS file: /cvs/ports/security/rbw/Makefile,v retrieving revision 1.21 diff -u -p -r1.21 Makefile --- security/rbw/Makefile 1 Jan 2024 09:02:16 - 1.21 +++ security/rbw/Makefile 4 Jan 2024 11:37:55 - @@ -3,8 +3,7 @@ NOT_FOR_ARCHS = powerpc64 riscv64 sparc6 COMMENT = command line BitWarden client -DISTNAME = rbw-1.8.3 -REVISION = 1 +DISTNAME = rbw-1.9.0 CATEGORIES = security Index: security/rbw/crates.inc === RCS file: /cvs/ports/security/rbw/crates.inc,v retrieving revision 1.4 diff -u -p -r1.4 crates.inc --- security/rbw/crates.inc 6 Sep 2023 17:36:47 - 1.4 +++ security/rbw/crates.inc 4 Jan 2024 11:37:55 - @@ -1,267 +1,282 @@ -MODCARGO_CRATES += addr2line 0.20.0 # Apache-2.0 OR MIT +MODCARGO_CRATES += addr2line 0.21.0 # Apache-2.0 OR MIT MODCARGO_CRATES += adler 1.0.2 # 0BSD OR MIT OR Apache-2.0 MODCARGO_CRATES += aes 0.8.3 # MIT OR Apache-2.0 -MODCARGO_CRATES += ahash 0.7.6 # MIT OR Apache-2.0 -MODCARGO_CRATES += aho-corasick1.0.2 # Unlicense OR MIT -MODCARGO_CRATES += anstream0.3.2 # MIT OR Apache-2.0 -MODCARGO_CRATES += anstyle 1.0.1 # MIT OR Apache-2.0 -MODCARGO_CRATES += anstyle-parse 0.2.1 # MIT OR Apache-2.0 -MODCARGO_CRATES += anstyle-query 1.0.0 # MIT OR Apache-2.0 -MODCARGO_CRATES += anstyle-wincon 1.0.1 # MIT OR Apache-2.0 -MODCARGO_CRATES += anyhow 1.0.72 # MIT OR Apache-2.0 -MODCARGO_CRATES += argon2 0.5.1 # MIT OR Apache-2.0 +MODCARGO_CRATES += aho-corasick1.1.2 # Unlicense OR MIT +MODCARGO_CRATES += anstream0.6.5 # MIT OR Apache-2.0 +MODCARGO_CRATES += anstyle 1.0.4 # MIT OR Apache-2.0 +MODCARGO_CRATES += anstyle-parse 0.2.3 # MIT OR Apache-2.0 +MODCARGO_CRATES += anstyle-query 1.0.2 # MIT OR Apache-2.0 +MODCARGO_CRATES += anstyle-wincon 3.0.2 # MIT OR Apache-2.0 +MODCARGO_CRATES += anyhow 1.0.78 # MIT OR Apache-2.0 +MODCARGO_CRATES += argon2 0.5.2 # MIT OR Apache-2.0 MODCARGO_CRATES += arrayvec0.7.4 # MIT OR Apache-2.0 -MODCARGO_CRATES += async-trait 0.1.71 # MIT OR Apache-2.0 +MODCARGO_CRATES += async-trait 0.1.76 # MIT OR Apache-2.0 MODCARGO_CRATES += autocfg 1.1.0 # Apache-2.0 OR MIT -MODCARGO_CRATES += backtrace 0.3.68 # MIT OR Apache-2.0 +MODCARGO_CRATES += backtrace 0.3.69 # MIT OR Apache-2.0 MODCARGO_CRATES += base32 0.4.0 # MIT OR Apache-2.0 -MODCARGO_CRATES += base64 0.21.2 # MIT OR Apache-2.0 +MODCARGO_CRATES += base64 0.21.5 # MIT OR Apache-2.0 MODCARGO_CRATES += base64ct1.6.0 # Apache-2.0 OR MIT MODCARGO_CRATES += bitflags1.3.2 # MIT/Apache-2.0 +MODCARGO_CRATES += bitflags2.4.1 # MIT OR Apache-2.0 MODCARGO_CRATES += blake2 0.10.6 # MIT OR Apache-2.0 MODCARGO_CRATES += block 0.1.6 # MIT MODCARGO_CRATES += block-buffer0.10.4 # MIT OR Apache-2.0 MODCARGO_CRATES += block-padding 0.3.3 # MIT OR Apache-2.0 -MODCARGO_CRATES += bumpalo 3.13.0 # MIT/Apache-2.0 -MODCARGO_CRATES += byteorder 1.4.3 # Unlicense OR MIT -MODCARGO_CRATES += bytes 1.4.0 # MIT +MODCARGO_CRATES += bumpalo 3.14.0 # MIT OR Apache-2.0 +MODCARGO_CRATES += byteorder 1.5.0 # Unlicense OR MIT +MODCARGO_CRATES += bytes 1.5.0 # MIT +MODCARGO_CRATES += calloop 0.12.3 # MIT +MODCARGO_CRATES += calloop-wayland-source 0.2.0 # MIT MODCARGO_CRATES += cbc 0.1.2 # MIT OR Apache-2.0 -MODCARGO_CRATES += cc 1.0.79 # MIT OR Apache-2.0 +MODCARGO_CRATES += cc 1.0.83 # MIT OR Apache-2.0 MODCARGO_CRATES += cfg-if 1.0.0 # MIT/Apache-2.0 MODCARGO_CRATES += cipher 0.4.4 # MIT OR Apache-2.0 -MODCARGO_CRATES += clap4.3.15 # MIT OR Apache-2.0 -MODCARGO_CRATES += clap_builder4.3.15 # MIT OR Apache-2.0 -MODCARGO_CRATES += clap_complete 4.3.2 # MIT OR Apache-2.0 -MODCARGO_CRATES += clap_derive 4.3.12 # MIT OR Apache-2.0 -MODCARGO_CRATES += clap_lex0.5.0 # MIT OR Apache-2.0 +MODCARGO_CRATES += clap4.4.12 # MIT OR Apache-2.0 +MODCARGO_CRATES += clap_builder4.4.12 # MIT OR Apache-2.0 +MODCARGO_CRATES += clap_complete 4.4.5 # MIT OR Apache-2.0
Re: Updating to newest sway, wlroots, and libdrm
On Thu, Jan 04, 2024 at 11:07:56AM +0100, Matthieu Herrb wrote: > On Wed, Jan 03, 2024 at 07:52:56PM -0700, Chris Waddey wrote: > > Hello. > > Hi, > > > I was able to get the latest version of sway working on my box after > > getting the latest version of wlroots to work, which was after applying > > the following patch to the latest version of libdrm (source obtained > > from https://gitlab.freedesktop.org/mesa/drm.git). I don't know if we > > have some patches somewhere else that handle this, but I figured I > > would send it your way in case it would save some effort. > > Does this include the removal of the wlr_drm protocol which was > committed to sway/wlroots a few hours ago ? > > I wasn't sure if OpenBSD libdrm / mesa supports linux-dmabuf which is > supposed to replace it. > > If it works with linux-dmabuf, that's great news. I don't think there > are any other significant changes since the released versions packaged > in ports that could impact OpenBSD. > > > I also had to do > > > > doas chmod $USER:$USER /dev/dri/* && env WLR_RENDERER=pixman > > startsway.sh > > Normally if you log in on the text console where you want to run sway, > the /dev/dri/* owndership is taken care of by fbtab(5). > > I think setting WLR_RENDERER to pixman means that you don't use the > new linux-dmabuf protocol. What happens if you leave that variable > undefined (defaults to 'auto') ? > > > to get everything just right. And of course I applied the patches I > > found in ports to sway and wlroots, but nothing else that I can > > think of. > > This diff is present in the /usr/xenocara/lib/libdrm tree. (not > exactly the same though: the whole #ifdef __OpenBSD__ part can be > removed now). attempts to merge the patches upstream stalled years ago https://gitlab.freedesktop.org/mesa/drm/-/merge_requests/119
Re: Updating to newest sway, wlroots, and libdrm
On Wed, Jan 03, 2024 at 07:52:56PM -0700, Chris Waddey wrote:
> Hello.
Hi,
> I was able to get the latest version of sway working on my box after
> getting the latest version of wlroots to work, which was after applying
> the following patch to the latest version of libdrm (source obtained
> from https://gitlab.freedesktop.org/mesa/drm.git). I don't know if we
> have some patches somewhere else that handle this, but I figured I
> would send it your way in case it would save some effort.
Does this include the removal of the wlr_drm protocol which was
committed to sway/wlroots a few hours ago ?
I wasn't sure if OpenBSD libdrm / mesa supports linux-dmabuf which is
supposed to replace it.
If it works with linux-dmabuf, that's great news. I don't think there
are any other significant changes since the released versions packaged
in ports that could impact OpenBSD.
> I also had to do
>
> doas chmod $USER:$USER /dev/dri/* && env WLR_RENDERER=pixman
> startsway.sh
Normally if you log in on the text console where you want to run sway,
the /dev/dri/* owndership is taken care of by fbtab(5).
I think setting WLR_RENDERER to pixman means that you don't use the
new linux-dmabuf protocol. What happens if you leave that variable
undefined (defaults to 'auto') ?
> to get everything just right. And of course I applied the patches I
> found in ports to sway and wlroots, but nothing else that I can
> think of.
This diff is present in the /usr/xenocara/lib/libdrm tree. (not
exactly the same though: the whole #ifdef __OpenBSD__ part can be
removed now).
>
> ~ 0$ pkg-config --modversion libdrm
> 2.4.119
> ~ 0$ pkg-config --modversion wlroots
> 0.18.0-dev
> ~ 0$ sway --version
> sway version 1.9-dev-52eaa5be (Jan 3 2024, branch 'master')
>
> diff --git xf86drm.h xf86drm.h
> index 2cb14156..c91f157b 100644
> --- xf86drm.h
> +++ xf86drm.h
> @@ -77,8 +77,8 @@ extern "C" {
> #define DRM_DEV_MODE (S_IRUSR|S_IWUSR|S_IRGRP|S_IWGRP)
>
> #ifdef __OpenBSD__
> -#define DRM_DIR_NAME "/dev"
> -#define DRM_PRIMARY_MINOR_NAME "drm"
> +#define DRM_DIR_NAME "/dev/dri"
> +#define DRM_PRIMARY_MINOR_NAME "card"
> #define DRM_CONTROL_MINOR_NAME "drmC" /* deprecated */
> #define DRM_RENDER_MINOR_NAME "drmR"
> #else
>
Re: UPDATE: Nono-0.6.4
On 2024/01/03 15:08:44 +0100, "Gonzalo L. Rodriguez" wrote: > Hello, > > Update for Nono to 0.6.4: > > http://www.pastel-flower.jp/~isaki/nono/ > > OK? Comments? ok op@ Thanks, Omar Polo
