[update] geo/traccar 5.10
Hello,
Here is a diff to update geo/traccar to 5.10
Tested on amd64
Beest RegardsIndex: Makefile
===
RCS file: /cvs/ports/geo/traccar/Makefile,v
retrieving revision 1.34
diff -u -p -r1.34 Makefile
--- Makefile 26 Sep 2023 10:52:59 - 1.34
+++ Makefile 22 Nov 2023 07:18:31 -
@@ -1,5 +1,5 @@
COMMENT = modern GPS tracking platform
-V = 5.9
+V = 5.10
PKGNAME = traccar-${V}
DISTNAME = traccar-other-${V}
EXTRACT_SUFX = .zip
Index: distinfo
===
RCS file: /cvs/ports/geo/traccar/distinfo,v
retrieving revision 1.21
diff -u -p -r1.21 distinfo
--- distinfo 6 Sep 2023 08:42:58 - 1.21
+++ distinfo 22 Nov 2023 07:18:31 -
@@ -1,2 +1,2 @@
-SHA256 (traccar-other-5.9.zip) = OOufXh+x4ggUOCeYXwi+fO8wTmyX39EC2Tpc9ld9ax0=
-SIZE (traccar-other-5.9.zip) = 141437334
+SHA256 (traccar-other-5.10.zip) = XPOQSduoAuizHT+h4vW5JKUlNiQgY27JfYMQkyWRgxw=
+SIZE (traccar-other-5.10.zip) = 142083005
Index: pkg/PLIST
===
RCS file: /cvs/ports/geo/traccar/pkg/PLIST,v
retrieving revision 1.24
diff -u -p -r1.24 PLIST
--- pkg/PLIST 6 Sep 2023 08:42:58 - 1.24
+++ pkg/PLIST 22 Nov 2023 07:18:31 -
@@ -991,26 +991,25 @@ share/traccar/legacy/simple/
share/traccar/legacy/simple/app.js
share/traccar/legacy/simple/index.html
share/traccar/lib/
-share/traccar/lib/HikariCP-5.0.1.jar
+share/traccar/lib/HikariCP-5.1.0.jar
share/traccar/lib/SparseBitSet-1.2.jar
-share/traccar/lib/accessors-smart-2.4.9.jar
-share/traccar/lib/activation-1.1.1.jar
-share/traccar/lib/amqp-client-5.18.0.jar
+share/traccar/lib/accessors-smart-2.4.11.jar
+share/traccar/lib/amqp-client-5.20.0.jar
share/traccar/lib/animal-sniffer-annotations-1.23.jar
share/traccar/lib/annotations-16.0.3.jar
share/traccar/lib/annotations-4.1.1.4.jar
share/traccar/lib/aopalliance-1.0.jar
share/traccar/lib/aopalliance-repackaged-3.0.4.jar
share/traccar/lib/api-common-2.12.0.jar
-share/traccar/lib/asm-9.5.jar
+share/traccar/lib/asm-9.3.jar
share/traccar/lib/asm-analysis-9.2.jar
-share/traccar/lib/asm-commons-9.5.jar
-share/traccar/lib/asm-tree-9.5.jar
+share/traccar/lib/asm-commons-9.2.jar
+share/traccar/lib/asm-tree-9.2.jar
share/traccar/lib/asm-util-9.2.jar
share/traccar/lib/auto-value-annotations-1.10.1.jar
-share/traccar/lib/aws-java-sdk-core-1.12.532.jar
-share/traccar/lib/aws-java-sdk-sns-1.12.532.jar
-share/traccar/lib/aws-java-sdk-sqs-1.12.532.jar
+share/traccar/lib/aws-java-sdk-core-1.12.592.jar
+share/traccar/lib/aws-java-sdk-sns-1.12.592.jar
+share/traccar/lib/aws-java-sdk-sqs-1.12.592.jar
share/traccar/lib/cache-api-1.1.1.jar
share/traccar/lib/caffeine-2.9.3.jar
share/traccar/lib/checker-qual-3.32.0.jar
@@ -1030,7 +1029,7 @@ share/traccar/lib/commons-pool2-2.11.1.j
share/traccar/lib/commons-text-1.10.0.jar
share/traccar/lib/commons-validator-1.7.jar
share/traccar/lib/conscrypt-openjdk-uber-2.5.2.jar
-share/traccar/lib/content-type-2.2.jar
+share/traccar/lib/content-type-2.3.jar
share/traccar/lib/curvesapi-1.07.jar
share/traccar/lib/dagger-2.27.jar
share/traccar/lib/encoder-1.2.3.jar
@@ -1057,6 +1056,7 @@ share/traccar/lib/google-http-client-app
share/traccar/lib/google-http-client-gson-1.43.1.jar
share/traccar/lib/google-http-client-jackson2-1.43.1.jar
share/traccar/lib/google-oauth-client-1.34.1.jar
+share/traccar/lib/googleauth-1.5.0.jar
share/traccar/lib/groovy-3.0.17.jar
share/traccar/lib/groovy-dateutil-3.0.17.jar
share/traccar/lib/grpc-alts-1.55.1.jar
@@ -1079,14 +1079,14 @@ share/traccar/lib/guava-31.1-jre.jar
share/traccar/lib/guice-7.0.0.jar
share/traccar/lib/guice-bridge-3.0.4.jar
share/traccar/lib/guice-servlet-7.0.0.jar
-share/traccar/lib/h2-2.2.220.jar
-share/traccar/lib/hivemq-mqtt-client-1.3.1.jar
+share/traccar/lib/h2-2.2.224.jar
+share/traccar/lib/hivemq-mqtt-client-1.3.3.jar
share/traccar/lib/hk2-api-3.0.4.jar
share/traccar/lib/hk2-locator-3.0.4.jar
share/traccar/lib/hk2-utils-3.0.4.jar
share/traccar/lib/httpclient-4.5.14.jar
share/traccar/lib/httpcore-4.4.16.jar
-share/traccar/lib/ical4j-3.2.12.jar
+share/traccar/lib/ical4j-3.2.14.jar
share/traccar/lib/ion-java-1.0.2.jar
share/traccar/lib/j2objc-annotations-1.3.jar
share/traccar/lib/jackson-annotations-2.15.2.jar
@@ -1105,7 +1105,6 @@ share/traccar/lib/jakarta.inject-api-2.0
share/traccar/lib/jakarta.json-2.0.1.jar
share/traccar/lib/jakarta.json-api-2.1.1.jar
share/traccar/lib/jakarta.mail-2.0.1.jar
-share/traccar/lib/jakarta.transaction-api-2.0.0.jar
share/traccar/lib/jakarta.validation-api-3.0.2.jar
share/traccar/lib/jakarta.ws.rs-api-3.1.0.jar
share/traccar/lib/jakarta.xml.bind-api-4.0.0.jar
@@ -1115,9 +1114,9 @@ share/traccar/lib/javax.annotation-api-1
share/traccar/lib/javax.inject-1.jar
share/traccar/lib/jaxb-api-2.3.1.jar
share/traccar/lib/jcip-annotations-1.0-1.jar
-share/traccar/lib/jcl-over-slf4j-1.7.36.jar
+share/traccar/lib/jcl-over-slf4j-2.0.7.jar
Re: GZDoom update, next attempt
Stefan Hagen wrote (2023-11-22 07:36 CET):
> Thomas Frohwein wrote (2023-11-22 03:47 CET):
> > On Tue, Nov 21, 2023 at 08:20:16AM +0100, Stefan Hagen wrote:
> >
> > [...]
> >
> > > - added more details about supported games (the ones I know that work)
> > > - added ~/.config/gzdoom as wad installation dir
> > > - updated sha256 for doom-1.8 wad (what the heck happened there?)
> > > - added reference to games/freedoom
> > > - added information about GL backends and how to change them in case of
> > > a crash/freeze.
> >
> > see below for comments.
> >
> > > +Supported are data files from:
> > > +- Doom 1 (doom1.wad) and 2 (doom2.wad)
> > > +- Freedoom (freedoom1.wad, freedoom2.wad)
> > > +- Heretic (heretic.wad)
> > > +- Hexen (hexen.wad)
> > > +- Vomitoreum (vomitoreum.ipk3)
> > > +- Apocalyptic Vibes (AVBuild.ipk3)
> >
> > There are way more and I don't think the README is the right place to
> > try to enumerate them all, especially as those are actively being
> > released, including probably dozens in 2023 alone. I'm okay with a
> > limited selection of something like Doom 1&2, Freedoom, Heretic, and
> > Hexen - that is pretty much the original content plus Freedoom which
> > is useful for testing given its license/availability.
>
> Fair point. I thought it's useful to add some that are not ending in .wad.
> But there's official documentation for that. I removed the last two and
> added a link to the official documentation.
>
> > > +If you do not possess any of those, you can install the freedoom
> > > +package or use the shareware IWAD which is available at:
> > >
> > >
> > > ftp://ftp.fu-berlin.de/pc/msdos/games/idgames/idstuff/doom/doom-1.8.wad.gz
> > > -SHA256 (doom-1.8.wad.gz) = WM9qVjtjGkdWFjCvpidthTwnB5NC95aewwBpZdqFV6E=
> > > +SHA256 (doom-1.8.wad.gz) =
> > > 58cf6a563b631a47561630afa6276d853c27079342f7969ec3006965da8557a1
> > > +
> > > +Rename the file as "doom.wad" to one of the mentioned locations.
> >
> > "Rename" is strange here, what about:
> > Rename the file to "doom.wad" and move it to one of the above-mentioned
> > locations.
>
> Yes, that's better.
>
> > > +[GlobalSettings]
> > > +vid_preferbackend=1
> > > +
> > > +Supported values are: 0 (OpenGL), 1 (Vulkan) or 2 (OpenGL ES)
> >
> > I'm not sure that's correct. Looking at the documentation at [1], it
> > seems to me that 3 is GL ES, and 2 seems to be for a Direct3D Windows-
> > related backend.
> >
> > [1] https://zdoom.org/wiki/CVARs:Display
>
> I'm seeing the documentation - but the mentioned values are correct on
> my system. Value 3 lets the game start, but the backend option in game
> shows "Unknown".
>
> On OpenBSD (Posix System) only the left column is relevant. I think we
> don't build with GLES2, and the documentation mentiones 0 and 2 as
> "OpenGL". The latter one is probably OpenGL ES.
>
> So I think the values in the README are correct for OpenBSD. But if
> you're uneasy with this, we can also write something like:
>
> "Valid backenend values are 0-3, play around with them until you find one
> that works."
>
> Diff with updated README below.
I just found your earlier comment:
> I'm on an Intel Tigerlake system and OpenGL (vid_preferbackend=0) and
> GLES2 (vid_preferbackend=3) work, but vulkan segfaults.
So appearently, GLES2 is available on intel based machines. I added the
value to the list.
Index: games/gzdoom/Makefile
===
RCS file: /cvs/ports/games/gzdoom/Makefile,v
diff -u -p -u -p -r1.17 Makefile
--- games/gzdoom/Makefile 18 Jul 2022 08:27:45 - 1.17
+++ games/gzdoom/Makefile 22 Nov 2023 06:49:27 -
@@ -6,11 +6,10 @@ ONLY_FOR_ARCHS = i386 amd64
COMMENT = OpenGL engine for idTech 1 games like
doom,hexen,heretic...
-V =4.8.2
-GH_ACCOUNT = coelckers
-GH_PROJECT = gzdoom
-GH_TAGNAME = g${V}
-DISTNAME = gzdoom-${V}
+V =4.11.3
+
+DIST_TUPLE = github ZDoom gzdoom g${V} .
+PKGNAME = gzdoom-${V}
CATEGORIES=games
@@ -21,8 +20,8 @@ MAINTAINER = Timo Myyra https://github.com/coelckers/gzdoom/pull/1665
-
-Index: src/d_main.cpp
src/d_main.cpp.orig
-+++ src/d_main.cpp
-@@ -3534,6 +3534,8 @@ static int D_DoomMain_Internal (void)
-
- std::set_new_handler(NewFailure);
- const char *batchout = Args->CheckValue("-errorlog");
-+
-+ D_DoomInit();
-
- // [RH] Make sure zdoom.pk3 is always loaded,
- // as it contains magic stuff we need.
-@@ -3567,8 +3569,6 @@ static int D_DoomMain_Internal (void)
- }
-
- if (!batchrun) Printf(PRINT_LOG, "%s version %s\n", GAMENAME,
GetVersionString());
--
-- D_DoomInit();
-
- extern void D_ConfirmSendStats();
- D_ConfirmSendStats();
Index: games/gzdoom/pkg/README
===
RCS file: /cvs/ports/games/gzdoom/p
Re: GZDoom update, next attempt
Thomas Frohwein wrote (2023-11-22 03:47 CET):
> On Tue, Nov 21, 2023 at 08:20:16AM +0100, Stefan Hagen wrote:
>
> [...]
>
> > - added more details about supported games (the ones I know that work)
> > - added ~/.config/gzdoom as wad installation dir
> > - updated sha256 for doom-1.8 wad (what the heck happened there?)
> > - added reference to games/freedoom
> > - added information about GL backends and how to change them in case of
> > a crash/freeze.
>
> see below for comments.
>
> > +Supported are data files from:
> > +- Doom 1 (doom1.wad) and 2 (doom2.wad)
> > +- Freedoom (freedoom1.wad, freedoom2.wad)
> > +- Heretic (heretic.wad)
> > +- Hexen (hexen.wad)
> > +- Vomitoreum (vomitoreum.ipk3)
> > +- Apocalyptic Vibes (AVBuild.ipk3)
>
> There are way more and I don't think the README is the right place to
> try to enumerate them all, especially as those are actively being
> released, including probably dozens in 2023 alone. I'm okay with a
> limited selection of something like Doom 1&2, Freedoom, Heretic, and
> Hexen - that is pretty much the original content plus Freedoom which
> is useful for testing given its license/availability.
Fair point. I thought it's useful to add some that are not ending in .wad.
But there's official documentation for that. I removed the last two and
added a link to the official documentation.
> > +If you do not possess any of those, you can install the freedoom
> > +package or use the shareware IWAD which is available at:
> >
> > ftp://ftp.fu-berlin.de/pc/msdos/games/idgames/idstuff/doom/doom-1.8.wad.gz
> > -SHA256 (doom-1.8.wad.gz) = WM9qVjtjGkdWFjCvpidthTwnB5NC95aewwBpZdqFV6E=
> > +SHA256 (doom-1.8.wad.gz) =
> > 58cf6a563b631a47561630afa6276d853c27079342f7969ec3006965da8557a1
> > +
> > +Rename the file as "doom.wad" to one of the mentioned locations.
>
> "Rename" is strange here, what about:
> Rename the file to "doom.wad" and move it to one of the above-mentioned
> locations.
Yes, that's better.
> > +[GlobalSettings]
> > +vid_preferbackend=1
> > +
> > +Supported values are: 0 (OpenGL), 1 (Vulkan) or 2 (OpenGL ES)
>
> I'm not sure that's correct. Looking at the documentation at [1], it
> seems to me that 3 is GL ES, and 2 seems to be for a Direct3D Windows-
> related backend.
>
> [1] https://zdoom.org/wiki/CVARs:Display
I'm seeing the documentation - but the mentioned values are correct on
my system. Value 3 lets the game start, but the backend option in game
shows "Unknown".
On OpenBSD (Posix System) only the left column is relevant. I think we
don't build with GLES2, and the documentation mentiones 0 and 2 as
"OpenGL". The latter one is probably OpenGL ES.
So I think the values in the README are correct for OpenBSD. But if
you're uneasy with this, we can also write something like:
"Valid backenend values are 0-3, play around with them until you find one
that works."
Diff with updated README below.
Index: games/gzdoom/Makefile
===
RCS file: /cvs/ports/games/gzdoom/Makefile,v
diff -u -p -u -p -r1.17 Makefile
--- games/gzdoom/Makefile 18 Jul 2022 08:27:45 - 1.17
+++ games/gzdoom/Makefile 22 Nov 2023 06:32:27 -
@@ -6,11 +6,10 @@ ONLY_FOR_ARCHS = i386 amd64
COMMENT = OpenGL engine for idTech 1 games like
doom,hexen,heretic...
-V =4.8.2
-GH_ACCOUNT = coelckers
-GH_PROJECT = gzdoom
-GH_TAGNAME = g${V}
-DISTNAME = gzdoom-${V}
+V =4.11.3
+
+DIST_TUPLE = github ZDoom gzdoom g${V} .
+PKGNAME = gzdoom-${V}
CATEGORIES=games
@@ -21,8 +20,8 @@ MAINTAINER = Timo Myyra https://github.com/coelckers/gzdoom/pull/1665
-
-Index: src/d_main.cpp
src/d_main.cpp.orig
-+++ src/d_main.cpp
-@@ -3534,6 +3534,8 @@ static int D_DoomMain_Internal (void)
-
- std::set_new_handler(NewFailure);
- const char *batchout = Args->CheckValue("-errorlog");
-+
-+ D_DoomInit();
-
- // [RH] Make sure zdoom.pk3 is always loaded,
- // as it contains magic stuff we need.
-@@ -3567,8 +3569,6 @@ static int D_DoomMain_Internal (void)
- }
-
- if (!batchrun) Printf(PRINT_LOG, "%s version %s\n", GAMENAME,
GetVersionString());
--
-- D_DoomInit();
-
- extern void D_ConfirmSendStats();
- D_ConfirmSendStats();
Index: games/gzdoom/pkg/README
===
RCS file: /cvs/ports/games/gzdoom/pkg/README,v
diff -u -p -u -p -r1.2 README
--- games/gzdoom/pkg/README 11 Mar 2022 19:04:32 - 1.2
+++ games/gzdoom/pkg/README 22 Nov 2023 06:32:27 -
@@ -1,14 +1,53 @@
-You will need an IWAD for gzdoom to be fully functional. An IWAD is
-the main data file containing the graphics and levels for Doom. If
-you have a copy of one of the original Doom games, simply copy your
-Doom, Doom 2, Ultimate Doom, or Final Doom IWAD (doom.wad, doom
Re: GZDoom update, next attempt
On Tue, Nov 21, 2023 at 08:20:16AM +0100, Stefan Hagen wrote:
[...]
> Attached the same diff, but I rewrote the README.
>
> - add usual readme header
I think that's a good thing.
> - added more details about supported games (the ones I know that work)
> - added ~/.config/gzdoom as wad installation dir
> - updated sha256 for doom-1.8 wad (what the heck happened there?)
> - added reference to games/freedoom
> - added information about GL backends and how to change them in case of
> a crash/freeze.
see below for comments.
> Portwise OK sdk@
>
> Index: games/gzdoom/Makefile
[...]
> Index: games/gzdoom/pkg/README
> ===
> RCS file: /cvs/ports/games/gzdoom/pkg/README,v
> diff -u -p -u -p -r1.2 README
> --- games/gzdoom/pkg/README 11 Mar 2022 19:04:32 - 1.2
> +++ games/gzdoom/pkg/README 21 Nov 2023 07:15:51 -
> @@ -1,14 +1,55 @@
> -You will need an IWAD for gzdoom to be fully functional. An IWAD is
> -the main data file containing the graphics and levels for Doom. If
> -you have a copy of one of the original Doom games, simply copy your
> -Doom, Doom 2, Ultimate Doom, or Final Doom IWAD (doom.wad, doom2.wad,
> -tnt.wad, and plutonia.wad respectively) to ${PREFIX}/share/doom/.
> -If you do not possess any of those, you can use the shareware IWAD
> -which is available at:
> ++---
> +| Running ${PKGSTEM} on OpenBSD
> ++---
> +
> +Installing Data Files
> +=
> +
> +You will need an IWAD for gzdoom to be fully functional. An IWAD is
> +the main data file containing the graphics and levels for Doom. If
> +you have a copy of one of the original Doom games, or any other game,
> +based on the same engine, you can copy them to the following locations
> +for gzdoom to find:
> +
> +- System wide: ${PREFIX}/share/doom/
> +- User wide: ~/.config/gzdoom/
> +
> +Supported are data files from:
> +- Doom 1 (doom1.wad) and 2 (doom2.wad)
> +- Freedoom (freedoom1.wad, freedoom2.wad)
> +- Heretic (heretic.wad)
> +- Hexen (hexen.wad)
> +- Vomitoreum (vomitoreum.ipk3)
> +- Apocalyptic Vibes (AVBuild.ipk3)
There are way more and I don't think the README is the right place to
try to enumerate them all, especially as those are actively being
released, including probably dozens in 2023 alone. I'm okay with a
limited selection of something like Doom 1&2, Freedoom, Heretic, and
Hexen - that is pretty much the original content plus Freedoom which
is useful for testing given its license/availability.
> +
> +If you do not possess any of those, you can install the freedoom
> +package or use the shareware IWAD which is available at:
>
> ftp://ftp.fu-berlin.de/pc/msdos/games/idgames/idstuff/doom/doom-1.8.wad.gz
> -SHA256 (doom-1.8.wad.gz) = WM9qVjtjGkdWFjCvpidthTwnB5NC95aewwBpZdqFV6E=
> +SHA256 (doom-1.8.wad.gz) =
> 58cf6a563b631a47561630afa6276d853c27079342f7969ec3006965da8557a1
> +
> +Rename the file as "doom.wad" to one of the mentioned locations.
"Rename" is strange here, what about:
Rename the file to "doom.wad" and move it to one of the above-mentioned
locations.
> -Install it to ${PREFIX}/share/doom as "doom.wad".
> +Optional Dependencies
> +=
>
> In case fluidsynth backend is needed the user needs to setup soundfont for
> it.
> +
> +Known Problems
> +==
> +
> +Gzdoom supports three GL backends (OpenGL, OpenGL ES, Vulkan). Some work
> +better than others depending on the graphic hardware in the system.
> +
> +In case gzdoom freezes or crashes before you can reach the in-game menu
> +to select a different backend, you can modify ~/.config/gzdoom/gzdoom.ini
> +manually and change the vid_preferbackend value:
> +
> +[GlobalSettings]
> +vid_preferbackend=1
> +
> +Supported values are: 0 (OpenGL), 1 (Vulkan) or 2 (OpenGL ES)
I'm not sure that's correct. Looking at the documentation at [1], it
seems to me that 3 is GL ES, and 2 seems to be for a Direct3D Windows-
related backend.
[1] https://zdoom.org/wiki/CVARs:Display
Re: Fix comments longer than 80 column
Sorry, I sent the email to the wrong address. 2023年11月22日(水) 10:44 ASOU Masato : > > ok? > -- > ASOU Masato > > Index: sys/kern/kern_physio.c > === > RCS file: /cvs/src/sys/kern/kern_physio.c,v > diff -u -p -r1.47 kern_physio.c > --- sys/kern/kern_physio.c 20 Feb 2020 16:26:01 - 1.47 > +++ sys/kern/kern_physio.c 22 Nov 2023 00:47:34 - > @@ -113,8 +113,8 @@ physio(void (*strategy)(struct buf *), d > /* > * Because iov_len is size_t (unsigned) but b_bcount > is > * long (signed), an overflow is possible. Therefore > -* limit b_bcount to LONG_MAX before calling > the provided > -* minphys. > +* limit b_bcount to LONG_MAX before calling the > +* provided minphys. > */ > if (iovp->iov_len > LONG_MAX) > bp->b_bcount = LONG_MAX;
Fix comments longer than 80 column
ok? -- ASOU Masato Index: sys/kern/kern_physio.c === RCS file: /cvs/src/sys/kern/kern_physio.c,v diff -u -p -r1.47 kern_physio.c --- sys/kern/kern_physio.c 20 Feb 2020 16:26:01 - 1.47 +++ sys/kern/kern_physio.c 22 Nov 2023 00:47:34 - @@ -113,8 +113,8 @@ physio(void (*strategy)(struct buf *), d /* * Because iov_len is size_t (unsigned) but b_bcount is * long (signed), an overflow is possible. Therefore -* limit b_bcount to LONG_MAX before calling the provided -* minphys. +* limit b_bcount to LONG_MAX before calling the +* provided minphys. */ if (iovp->iov_len > LONG_MAX) bp->b_bcount = LONG_MAX;
Re: Port for bazel-6.3.2
Antoine Jacoutot writes: > On Tue, Nov 21, 2023 at 09:32:03AM -0800, Greg Steuck wrote: > Archival? > I think it would be a welcome addition to ports@ if you care to maintain it. Sure, any OKs then?
Re: Port for bazel-6.3.2
On Tue, Nov 21, 2023 at 09:32:03AM -0800, Greg Steuck wrote: > Stuart Henderson writes: > > > some tweaks for consideration, > > > > - drop rcs id > > - no point restricting untested archs > > - unzip is already auto-added to BDEPs > > - no need to set MODPY_VERSION to what's already the default > > - verbose builds are often helpful to figure out any issues in > > bulk builds > > - use DIST_TUPLE (also needs "make makesum" to regen distinfo) > > Very cool, thanks for the tips. The updated port is attached for > archival purposes. Archival? I think it would be a welcome addition to ports@ if you care to maintain it. -- Antoine
[update] devel/py-multitasking
The diff below updates devel/py-multitasking to the most recent
version.
Changelog:
* Added get_list_of_tasks()
Thanks.
Index: Makefile
===
RCS file: /cvs/ports/devel/py-multitasking/Makefile,v
retrieving revision 1.5
diff -u -p -u -r1.5 Makefile
--- Makefile26 Nov 2022 15:02:53 - 1.5
+++ Makefile21 Nov 2023 18:34:02 -
@@ -1,9 +1,8 @@
COMMENT= non-blocking Python methods using decorators
-MODPY_EGG_VERSION= 0.0.10
+MODPY_EGG_VERSION= 0.0.11
DISTNAME= multitasking-${MODPY_EGG_VERSION}
PKGNAME= py-multitasking-${MODPY_EGG_VERSION}
-REVISION= 1
CATEGORIES=devel
Index: distinfo
===
RCS file: /cvs/ports/devel/py-multitasking/distinfo,v
retrieving revision 1.2
diff -u -p -u -r1.2 distinfo
--- distinfo14 Nov 2021 19:53:11 - 1.2
+++ distinfo21 Nov 2023 18:34:02 -
@@ -1,2 +1,2 @@
-SHA256 (multitasking-0.0.10.tar.gz) =
gQZA+mZwvkH0pxKyh9kwehSthJ2WbwahfSzxWTtmw80=
-SIZE (multitasking-0.0.10.tar.gz) = 8152
+SHA256 (multitasking-0.0.11.tar.gz) =
TWvDzGX5stynL7Wnh4UKiNro9iDCs2rptVJI5RvNYCY=
+SIZE (multitasking-0.0.11.tar.gz) = 8150
[update] print/py-pylatex
The diff below updates print/py-pylatex to the latest version.
Changelog:
- Add `.Chapter` in ``__init__.py``
- Fix installation on Python 3.12
- Update tooling (use black and isort and remove custom flake8 stuff)
I get a warning that description-file in setup.cfg should be named
description_file. I don't know if that would be something to patch
away.
Thanks.
Index: Makefile
===
RCS file: /cvs/ports/print/py-pylatex/Makefile,v
retrieving revision 1.4
diff -u -p -r1.4 Makefile
--- Makefile13 Nov 2022 20:31:00 - 1.4
+++ Makefile21 Nov 2023 18:40:42 -
@@ -1,9 +1,8 @@
COMMENT= Python interface for LaTeX
-MODPY_EGG_VERSION= 1.4.1
+MODPY_EGG_VERSION= 1.4.2
DISTNAME= PyLaTeX-${MODPY_EGG_VERSION}
PKGNAME= py-pylatex-${MODPY_EGG_VERSION}
-REVISION= 1
CATEGORIES=print
Index: distinfo
===
RCS file: /cvs/ports/print/py-pylatex/distinfo,v
retrieving revision 1.1.1.1
diff -u -p -r1.1.1.1 distinfo
--- distinfo20 Nov 2021 08:20:05 - 1.1.1.1
+++ distinfo21 Nov 2023 18:40:42 -
@@ -1,2 +1,2 @@
-SHA256 (PyLaTeX-1.4.1.tar.gz) = 08Eu+4smB3EmBEPc540ekInAn50LkuYnPfygv15zAvs=
-SIZE (PyLaTeX-1.4.1.tar.gz) = 84976
+SHA256 (PyLaTeX-1.4.2.tar.gz) = u3shvsV+zbo/b0TIVuvr32VJ/W6AZhvUT9UJQjZykkI=
+SIZE (PyLaTeX-1.4.2.tar.gz) = 59710
Index: pkg/PLIST
===
RCS file: /cvs/ports/print/py-pylatex/pkg/PLIST,v
retrieving revision 1.3
diff -u -p -r1.3 PLIST
--- pkg/PLIST 13 Nov 2022 20:31:00 - 1.3
+++ pkg/PLIST 21 Nov 2023 18:40:42 -
@@ -1,4 +1,5 @@
lib/python${MODPY_VERSION}/site-packages/PyLaTeX-${MODPY_EGG_VERSION}.dist-info/
+lib/python${MODPY_VERSION}/site-packages/PyLaTeX-${MODPY_EGG_VERSION}.dist-info/LICENSE
lib/python${MODPY_VERSION}/site-packages/PyLaTeX-${MODPY_EGG_VERSION}.dist-info/METADATA
lib/python${MODPY_VERSION}/site-packages/PyLaTeX-${MODPY_EGG_VERSION}.dist-info/RECORD
lib/python${MODPY_VERSION}/site-packages/PyLaTeX-${MODPY_EGG_VERSION}.dist-info/WHEEL
Re: NEW: devel/py-icecream
On Thu, Nov 2, 2023 at 12:57 PM Miguel Landaeta wrote: > > [...] > > I attached a new revision addressing the comments above. > Ping. -- Miguel Landaeta, miguel at miguel.cc secure email with PGP 0x6E608B637D8967E9 available at http://keyserver.pgp.com/ "Faith means not wanting to know what is true." -- Nietzsche
Re: Port for bazel-6.3.2
Stuart Henderson writes: > some tweaks for consideration, > > - drop rcs id > - no point restricting untested archs > - unzip is already auto-added to BDEPs > - no need to set MODPY_VERSION to what's already the default > - verbose builds are often helpful to figure out any issues in > bulk builds > - use DIST_TUPLE (also needs "make makesum" to regen distinfo) Very cool, thanks for the tips. The updated port is attached for archival purposes. bazel.tgz Description: Binary data
Re: salt-3006.3, py3-setproctitle and rc.d(8) on -stable
Hi. Same seems to be for salt-master. I don't have usage for other salt daemons, like salt_api, salt_proxy or salt_syndic, so I didn't test them. ks2# pgrep -lf salt-master 46264 python3.10: /usr/local/bin/python3.10 /usr/local/bin/salt-master -d ReqServer MWorker-4 72386 python3.10: /usr/local/bin/python3.10 /usr/local/bin/salt-master -d ReqServer MWorker-3 88457 python3.10: /usr/local/bin/python3.10 /usr/local/bin/salt-master -d ReqServer MWorker-2 4147 python3.10: /usr/local/bin/python3.10 /usr/local/bin/salt-master -d ReqServer MWorker-1 80424 python3.10: /usr/local/bin/python3.10 /usr/local/bin/salt-master -d ReqServer MWorker-0 80969 python3.10: /usr/local/bin/python3.10 /usr/local/bin/salt-master -d ReqServer MWorkerQueue 50108 python3.10: /usr/local/bin/python3.10 /usr/local/bin/salt-master -d FileServerUpdate 16955 python3.10: /usr/local/bin/python3.10 /usr/local/bin/salt-master -d ReqServer ReqServer_ProcessManager 79792 python3.10: /usr/local/bin/python3.10 /usr/local/bin/salt-master -d Maintenance 79559 python3.10: /usr/local/bin/python3.10 /usr/local/bin/salt-master -d EventPublisher 58072 python3.10: /usr/local/bin/python3.10 /usr/local/bin/salt-master -d PubServerChannel._publish_daemon 6693 python3.10: /usr/local/bin/python3.10 /usr/local/bin/salt-master -d MainProcess On Tue, Nov 21, 2023 at 09:45:49AM +, Mikolaj Kucharski wrote: > Hi all, > > What I am reporting here, was tested on -stable and on -current. Below > details are from -stable, because I discovered it first there and have > the notes from that machine. > > One of my OpenBSD 7.4 machines, because of package unrelated to salt, > had py3-setproctitle installed on that machine and that resuled in > following problem: > > ks3# rcctl check salt_minion > salt_minion(failed) > > It seems that pexp from /etc/rc.d/salt_minion doesn't match the process > when salt minion is started with py3-setproctitle package available. > > Here are more details: > > ks3# sysctl -n kern.version > OpenBSD 7.4 (GENERIC.MP) #0: Sun Oct 22 12:13:42 MDT 2023 > > r...@syspatch-74-amd64.openbsd.org:/usr/src/sys/arch/amd64/compile/GENERIC.MP > > ks3# cat /etc/installurl > https://cdn.openbsd.org/pub/OpenBSD/ > > ks3# pkg_info -qI salt > salt-3006.3 > > No py3-setproctitle installed: > > ks3# ls -1 /var/db/pkg/ | grep -ci proc > 0 > > ks3# pkg_add -a -i py3-setproctitle > quirks-6.160 signed on 2023-11-19T13:55:25Z > py3-setproctitle-1.3.2p1: ok > > ks3# rcctl restart salt_minion > salt_minion(ok) > salt_minion(ok) > > ks3# pgrep -lf salt > 8102 python3.10: /usr/local/bin/python3.10 /usr/local/bin/salt-minion -d > MainProcess > > ks3# rcctl check salt_minion > salt_minion(failed) > > If we wait for random_startup_delay: > > ks3# grep -e ^random_startup_delay /etc/salt/minion > random_startup_delay: 180 > > then proc title changes again: > > ks3# pgrep -lf salt > 8102 python3.10: /usr/local/bin/python3.10 /usr/local/bin/salt-minion -d > MultiMinionProcessManager MinionProcessManager > > ks3# pkg_delete -c py3-setproctitle > py3-setproctitle-1.3.2p1: ok > Read shared items: ok > > ks3# rcctl restart salt_minion > salt_minion(ok) > > ks3# pgrep -lf salt > 78929 /usr/local/bin/python3.10 /usr/local/bin/salt-minion -d > 8102 python3.10: /usr/local/bin/python3.10 /usr/local/bin/salt-minion -d > MultiMinionProcessManager MinionProcessManager > > We see above orphaned previous instance of salt-minion which had > setproctitle loaded. > > ks3# kill 8102 > ks3# pgrep -lf salt > 78929 /usr/local/bin/python3.10 /usr/local/bin/salt-minion -d > > ks3# rcctl check salt_minion > salt_minion(ok) > -- Regards, Mikolaj
mips64 bulk build report
bulk build on octeon.ports.openbsd.org started on Sun Nov 5 14:34:01 UTC 2023 finished at Mon Nov 20 23:14:45 UTC 2023 lasted 16D08h40m done with kern.version=OpenBSD 7.4-current (GENERIC.MP) #1402: Sat Nov 4 01:47:58 MDT 2023 built packages:9108 Nov 5:1909 Nov 6:864 Nov 7:692 Nov 8:162 Nov 9:472 Nov 10:359 Nov 11:2586 Nov 12:725 Nov 13:514 Nov 14:235 Nov 16:169 Nov 17:107 Nov 18:150 Nov 19:146 Nov 20:17 build failures: 73 http://build-failures.rhaalovely.net/mips64/2023-11-05/audio/zmusic.log http://build-failures.rhaalovely.net/mips64/2023-11-05/databases/postgresql-pllua.log http://build-failures.rhaalovely.net/mips64/2023-11-05/devel/arm-none-eabi/gcc,aarch64.log http://build-failures.rhaalovely.net/mips64/2023-11-05/devel/clang-tools-extra.log http://build-failures.rhaalovely.net/mips64/2023-11-05/devel/objfw.log http://build-failures.rhaalovely.net/mips64/2023-11-05/devel/py-thrift,python3.log http://build-failures.rhaalovely.net/mips64/2023-11-05/devel/py-unicorn,python3.log http://build-failures.rhaalovely.net/mips64/2023-11-05/devel/sdcc.log http://build-failures.rhaalovely.net/mips64/2023-11-05/emulators/desmume.log http://build-failures.rhaalovely.net/mips64/2023-11-05/emulators/openmsx.log http://build-failures.rhaalovely.net/mips64/2023-11-05/emulators/spike.log http://build-failures.rhaalovely.net/mips64/2023-11-05/games/astromenace.log http://build-failures.rhaalovely.net/mips64/2023-11-05/games/cataclysm-dda.log http://build-failures.rhaalovely.net/mips64/2023-11-05/games/gnukem.log http://build-failures.rhaalovely.net/mips64/2023-11-05/games/goldberg_emulator.log http://build-failures.rhaalovely.net/mips64/2023-11-05/games/hyperrogue.log http://build-failures.rhaalovely.net/mips64/2023-11-05/games/wesnoth.log http://build-failures.rhaalovely.net/mips64/2023-11-05/games/witchblast.log http://build-failures.rhaalovely.net/mips64/2023-11-05/geo/gpstk.log http://build-failures.rhaalovely.net/mips64/2023-11-05/graphics/openvdb.log http://build-failures.rhaalovely.net/mips64/2023-11-05/inputmethods/ibus.log http://build-failures.rhaalovely.net/mips64/2023-11-05/lang/STk.log http://build-failures.rhaalovely.net/mips64/2023-11-05/lang/gambit.log http://build-failures.rhaalovely.net/mips64/2023-11-05/lang/gforth.log http://build-failures.rhaalovely.net/mips64/2023-11-05/lang/librep.log http://build-failures.rhaalovely.net/mips64/2023-11-05/lang/pfe.log http://build-failures.rhaalovely.net/mips64/2023-11-05/mail/opensmtpd-filters/rspamd.log http://build-failures.rhaalovely.net/mips64/2023-11-05/math/gbc.log http://build-failures.rhaalovely.net/mips64/2023-11-05/math/lean.log http://build-failures.rhaalovely.net/mips64/2023-11-05/math/lrs.log http://build-failures.rhaalovely.net/mips64/2023-11-05/math/mlpack,-main.log http://build-failures.rhaalovely.net/mips64/2023-11-05/math/ntl.log http://build-failures.rhaalovely.net/mips64/2023-11-05/misc/remind.log http://build-failures.rhaalovely.net/mips64/2023-11-05/multimedia/assimp.log http://build-failures.rhaalovely.net/mips64/2023-11-05/net/eduvpn/vpn-daemon.log http://build-failures.rhaalovely.net/mips64/2023-11-05/net/gtk-gnutella.log http://build-failures.rhaalovely.net/mips64/2023-11-05/net/icinga/core2.log http://build-failures.rhaalovely.net/mips64/2023-11-05/net/minio/client.log http://build-failures.rhaalovely.net/mips64/2023-11-05/net/minio/server.log http://build-failures.rhaalovely.net/mips64/2023-11-05/net/powerdns_recursor.log http://build-failures.rhaalovely.net/mips64/2023-11-05/net/syncthing.log http://build-failures.rhaalovely.net/mips64/2023-11-05/net/utox.log http://build-failures.rhaalovely.net/mips64/2023-11-05/plan9/drawterm.log http://build-failures.rhaalovely.net/mips64/2023-11-05/security/botan2.log http://build-failures.rhaalovely.net/mips64/2023-11-05/security/gpgme.log http://build-failures.rhaalovely.net/mips64/2023-11-05/security/nuclei.log http://build-failures.rhaalovely.net/mips64/2023-11-05/security/step-cli.log http://build-failures.rhaalovely.net/mips64/2023-11-05/security/vault.log http://build-failures.rhaalovely.net/mips64/2023-11-05/shells/elvish.log http://build-failures.rhaalovely.net/mips64/2023-11-05/shells/nsh.log http://build-failures.rhaalovely.net/mips64/2023-11-05/sysutils/amazon-ecs-cli.log http://build-failures.rhaalovely.net/mips64/2023-11-05/sysutils/beats/filebeat.log http://build-failures.rhaalovely.net/mips64/2023-11-05/sysutils/beats/heartbeat.log http://build-failures.rhaalovely.net/mips64/2023-11-05/sysutils/beats/metricbeat.log http://build-failures.rhaalovely.net/mips64/2023-11-05/sysutils/beats/packetbeat.log http://build-failures.rhaalovely.net/mips64/2023-11-05/sysutils/dep.log http://build-failures.rhaalovely.net/mips64/2023-11-05/sysutils/direnv.log http://build-failures.rhaalovely.net/mips64/2023-11-05/sysutils/gitlab-runner.log http://build-failures.rhaalovely.net/mips64/2023-11-05/sysutils/kubectl.log http://build-failures.rhaalovely.net/mips64/2023-11-05/sysutils/libvirt.log htt
Re: libffi: fix arm64 bti
On Tue, Nov 21, 2023 at 04:48:29PM +0100, Mark Kettenis wrote: > > Date: Tue, 21 Nov 2023 16:08:13 +0100 > > From: Tobias Heider > > > > On Tue, Nov 21, 2023 at 12:23:08PM +0100, Mark Kettenis wrote: > > > > Date: Tue, 21 Nov 2023 12:04:42 +0100 > > > > From: Tobias Heider > > > > > > > > On Tue, Nov 21, 2023 at 11:56:18AM +0100, Mark Kettenis wrote: > > > > > > Date: Tue, 21 Nov 2023 00:16:40 +0100 > > > > > > From: Tobias Heider > > > > > > > > > > > > Diff below fixes make regress for libffi with arm64 BTI enabled. > > > > > > The tricky part were two jump tables in ffi.c and sysV.S. > > > > > > > > > > > > ok? > > > > > > > > > > I think you missed the "computed goto" in ffi_closure_SYSV. > > > > > > > > > > Maybe we shouldn't add a "bti j" for the unused slots? > > > > > > > > Functionally yes, that should also work and makes more sense. > > > > But then the brks would be a bit redundant. I wasn't sure if there > > > > are tests or something that expects those breaks to be reachable. > > > > > > The brks still need to be there for those poor CPUs that don't > > > implement BTI. > > > > > > > Here is an updated diff where all reserved and unused entries > > don't get bti j. make regress still passes. > > Looks like you missed my comment about ffi_closure_SYSV. urgh yes, missed that. fixed in diff below > Is the closures stuff not tested as part of make regress? it seems like a lot of tests are skipped in our port. I'll see if I can force it to run a few more. # of expected passes5822 # of unsupported tests 209 Index: Makefile === RCS file: /cvs/ports/devel/libffi/Makefile,v retrieving revision 1.48 diff -u -p -r1.48 Makefile --- Makefile21 Sep 2023 09:49:57 - 1.48 +++ Makefile21 Nov 2023 16:07:43 - @@ -1,6 +1,7 @@ COMMENT= Foreign Function Interface V= 3.4.4 +REVISION= 0 DISTNAME= libffi-$V SHARED_LIBS += ffi 2.0 # 9.2 CATEGORIES=devel Index: patches/patch-src_aarch64_ffi_c === RCS file: patches/patch-src_aarch64_ffi_c diff -N patches/patch-src_aarch64_ffi_c --- /dev/null 1 Jan 1970 00:00:00 - +++ patches/patch-src_aarch64_ffi_c 21 Nov 2023 16:07:43 - @@ -0,0 +1,76 @@ +Index: src/aarch64/ffi.c +--- src/aarch64/ffi.c.orig src/aarch64/ffi.c +@@ -390,47 +390,59 @@ extend_hfa_type (void *dest, void *src, int h) + "adr%0, 0f\n" + " add %0, %0, %1\n" + " br %0\n" +-"0: ldp s16, s17, [%3]\n" /* S4 */ ++"0: bti j\n"/* S4 */ ++" ldp s16, s17, [%3]\n" + " ldp s18, s19, [%3, #8]\n" + " b 4f\n" +-" ldp s16, s17, [%3]\n" /* S3 */ ++" bti j\n"/* S3 */ ++" ldp s16, s17, [%3]\n" + " ldr s18, [%3, #8]\n" + " b 3f\n" +-" ldp s16, s17, [%3]\n" /* S2 */ ++" bti j\n"/* S2 */ ++" ldp s16, s17, [%3]\n" + " b 2f\n" + " nop\n" +-" ldr s16, [%3]\n"/* S1 */ ++" bti j\n"/* S1 */ ++" ldr s16, [%3]\n" + " b 1f\n" + " nop\n" +-" ldp d16, d17, [%3]\n" /* D4 */ ++" bti j\n"/* D4 */ ++" ldp d16, d17, [%3]\n" + " ldp d18, d19, [%3, #16]\n" + " b 4f\n" +-" ldp d16, d17, [%3]\n" /* D3 */ ++" bti j\n"/* D3 */ ++" ldp d16, d17, [%3]\n" + " ldr d18, [%3, #16]\n" + " b 3f\n" +-" ldp d16, d17, [%3]\n" /* D2 */ ++" bti j\n"/* D2 */ ++" ldp d16, d17, [%3]\n" + " b 2f\n" + " nop\n" +-" ldr d16, [%3]\n"/* D1 */ ++" bti j\n"/* D1 */ ++" ldr d16, [%3]\n" + " b 1f\n" + " nop\n" +-" ldp q16, q17, [%3]\n" /* Q4 */ ++" bti j\n"/* Q4 */ ++" ldp q16, q17, [%3]\n" + " ldp q18, q19, [%3, #32]\n" + " b 4f\n" +-" ldp q16, q17, [%3]\n" /* Q3 */ ++" bti j\n"/* Q3 */ ++" ldp q16, q17, [%3]\n" + " ldr q18, [%3, #32]\n" + " b 3f\n" +-" ldp q16, q17, [%3]\n" /* Q2 */ ++" bti j\n"/* Q2 */ ++" ldp q16, q17, [%3]\n" + " b 2f\n" + " nop\n" +-" ldr q16, [%3]\n"/* Q1 */ ++" bti j\n"/* Q1 */ ++" ldr q16, [%3]\n" + " b 1f\n" + "4: str q19, [%2, #48]\n" + "3: str q18, [%2, #32]\n" + "2: str q17, [%2, #16]\n" + "1: str q16, [%2]" + : "=&r"(x0) +-: "r"(f * 12), "r"(dest), "r"(src) ++: "r"(f * 16), "r"(dest), "r"(src) +
Re: libffi: fix arm64 bti
> Date: Tue, 21 Nov 2023 16:08:13 +0100 > From: Tobias Heider > > On Tue, Nov 21, 2023 at 12:23:08PM +0100, Mark Kettenis wrote: > > > Date: Tue, 21 Nov 2023 12:04:42 +0100 > > > From: Tobias Heider > > > > > > On Tue, Nov 21, 2023 at 11:56:18AM +0100, Mark Kettenis wrote: > > > > > Date: Tue, 21 Nov 2023 00:16:40 +0100 > > > > > From: Tobias Heider > > > > > > > > > > Diff below fixes make regress for libffi with arm64 BTI enabled. > > > > > The tricky part were two jump tables in ffi.c and sysV.S. > > > > > > > > > > ok? > > > > > > > > I think you missed the "computed goto" in ffi_closure_SYSV. > > > > > > > > Maybe we shouldn't add a "bti j" for the unused slots? > > > > > > Functionally yes, that should also work and makes more sense. > > > But then the brks would be a bit redundant. I wasn't sure if there > > > are tests or something that expects those breaks to be reachable. > > > > The brks still need to be there for those poor CPUs that don't > > implement BTI. > > > > Here is an updated diff where all reserved and unused entries > don't get bti j. make regress still passes. Looks like you missed my comment about ffi_closure_SYSV. Is the closures stuff not tested as part of make regress? > Index: Makefile > === > RCS file: /cvs/ports/devel/libffi/Makefile,v > retrieving revision 1.48 > diff -u -p -r1.48 Makefile > --- Makefile 21 Sep 2023 09:49:57 - 1.48 > +++ Makefile 21 Nov 2023 15:05:33 - > @@ -1,6 +1,7 @@ > COMMENT= Foreign Function Interface > > V= 3.4.4 > +REVISION=0 > DISTNAME=libffi-$V > SHARED_LIBS += ffi 2.0 # 9.2 > CATEGORIES= devel > Index: patches/patch-src_aarch64_ffi_c > === > RCS file: patches/patch-src_aarch64_ffi_c > diff -N patches/patch-src_aarch64_ffi_c > --- /dev/null 1 Jan 1970 00:00:00 - > +++ patches/patch-src_aarch64_ffi_c 21 Nov 2023 15:05:33 - > @@ -0,0 +1,76 @@ > +Index: src/aarch64/ffi.c > +--- src/aarch64/ffi.c.orig > src/aarch64/ffi.c > +@@ -390,47 +390,59 @@ extend_hfa_type (void *dest, void *src, int h) > + "adr%0, 0f\n" > + " add %0, %0, %1\n" > + " br %0\n" > +-"0: ldp s16, s17, [%3]\n" /* S4 */ > ++"0: bti j\n"/* S4 */ > ++" ldp s16, s17, [%3]\n" > + " ldp s18, s19, [%3, #8]\n" > + " b 4f\n" > +-" ldp s16, s17, [%3]\n" /* S3 */ > ++" bti j\n"/* S3 */ > ++" ldp s16, s17, [%3]\n" > + " ldr s18, [%3, #8]\n" > + " b 3f\n" > +-" ldp s16, s17, [%3]\n" /* S2 */ > ++" bti j\n"/* S2 */ > ++" ldp s16, s17, [%3]\n" > + " b 2f\n" > + " nop\n" > +-" ldr s16, [%3]\n"/* S1 */ > ++" bti j\n"/* S1 */ > ++" ldr s16, [%3]\n" > + " b 1f\n" > + " nop\n" > +-" ldp d16, d17, [%3]\n" /* D4 */ > ++" bti j\n"/* D4 */ > ++" ldp d16, d17, [%3]\n" > + " ldp d18, d19, [%3, #16]\n" > + " b 4f\n" > +-" ldp d16, d17, [%3]\n" /* D3 */ > ++" bti j\n"/* D3 */ > ++" ldp d16, d17, [%3]\n" > + " ldr d18, [%3, #16]\n" > + " b 3f\n" > +-" ldp d16, d17, [%3]\n" /* D2 */ > ++" bti j\n"/* D2 */ > ++" ldp d16, d17, [%3]\n" > + " b 2f\n" > + " nop\n" > +-" ldr d16, [%3]\n"/* D1 */ > ++" bti j\n"/* D1 */ > ++" ldr d16, [%3]\n" > + " b 1f\n" > + " nop\n" > +-" ldp q16, q17, [%3]\n" /* Q4 */ > ++" bti j\n"/* Q4 */ > ++" ldp q16, q17, [%3]\n" > + " ldp q18, q19, [%3, #32]\n" > + " b 4f\n" > +-" ldp q16, q17, [%3]\n" /* Q3 */ > ++" bti j\n"/* Q3 */ > ++" ldp q16, q17, [%3]\n" > + " ldr q18, [%3, #32]\n" > + " b 3f\n" > +-" ldp q16, q17, [%3]\n" /* Q2 */ > ++" bti j\n"/* Q2 */ > ++" ldp q16, q17, [%3]\n" > + " b 2f\n" > + " nop\n" > +-" ldr q16, [%3]\n"/* Q1 */ > ++" bti j\n"/* Q1 */ > ++" ldr q16, [%3]\n" > + " b 1f\n" > + "4: str q19, [%2, #48]\n" > + "3: str q18, [%2, #32]\n" > + "2: str q17, [%2, #16]\n" > + "1: str q16, [%2]" > + : "=&r"(x0) > +-: "r"(f * 12), "r"(dest), "r"(src) > ++: "r"(f * 16), "r"(dest), "r"(src) > + : "memory", "v16", "v17", "v18", "v19"); > + } > + #endif > Index: patches/patch-src_aarch64_sysv_S > === > RCS file: patches/patch-src_aarch64_sysv_S > diff -N patches/patch-src_aarch64_sysv_S > --- /dev/null 1 Jan 1970 00:00:00 - > +++
Re: libffi: fix arm64 bti
I think it is funny how exceedingly precise we are being in .S files to not place *one extra dangerous bti* instruction. Meanwhile, the C compilers don't know what will happen, so they slam unused bti all over the place! But that's why we hope purging these at link time, as "mold" now does, is going to show up in other linkers.
Re: libffi: fix arm64 bti
On Tue, Nov 21, 2023 at 12:23:08PM +0100, Mark Kettenis wrote: > > Date: Tue, 21 Nov 2023 12:04:42 +0100 > > From: Tobias Heider > > > > On Tue, Nov 21, 2023 at 11:56:18AM +0100, Mark Kettenis wrote: > > > > Date: Tue, 21 Nov 2023 00:16:40 +0100 > > > > From: Tobias Heider > > > > > > > > Diff below fixes make regress for libffi with arm64 BTI enabled. > > > > The tricky part were two jump tables in ffi.c and sysV.S. > > > > > > > > ok? > > > > > > I think you missed the "computed goto" in ffi_closure_SYSV. > > > > > > Maybe we shouldn't add a "bti j" for the unused slots? > > > > Functionally yes, that should also work and makes more sense. > > But then the brks would be a bit redundant. I wasn't sure if there > > are tests or something that expects those breaks to be reachable. > > The brks still need to be there for those poor CPUs that don't > implement BTI. > Here is an updated diff where all reserved and unused entries don't get bti j. make regress still passes. Index: Makefile === RCS file: /cvs/ports/devel/libffi/Makefile,v retrieving revision 1.48 diff -u -p -r1.48 Makefile --- Makefile21 Sep 2023 09:49:57 - 1.48 +++ Makefile21 Nov 2023 15:05:33 - @@ -1,6 +1,7 @@ COMMENT= Foreign Function Interface V= 3.4.4 +REVISION= 0 DISTNAME= libffi-$V SHARED_LIBS += ffi 2.0 # 9.2 CATEGORIES=devel Index: patches/patch-src_aarch64_ffi_c === RCS file: patches/patch-src_aarch64_ffi_c diff -N patches/patch-src_aarch64_ffi_c --- /dev/null 1 Jan 1970 00:00:00 - +++ patches/patch-src_aarch64_ffi_c 21 Nov 2023 15:05:33 - @@ -0,0 +1,76 @@ +Index: src/aarch64/ffi.c +--- src/aarch64/ffi.c.orig src/aarch64/ffi.c +@@ -390,47 +390,59 @@ extend_hfa_type (void *dest, void *src, int h) + "adr%0, 0f\n" + " add %0, %0, %1\n" + " br %0\n" +-"0: ldp s16, s17, [%3]\n" /* S4 */ ++"0: bti j\n"/* S4 */ ++" ldp s16, s17, [%3]\n" + " ldp s18, s19, [%3, #8]\n" + " b 4f\n" +-" ldp s16, s17, [%3]\n" /* S3 */ ++" bti j\n"/* S3 */ ++" ldp s16, s17, [%3]\n" + " ldr s18, [%3, #8]\n" + " b 3f\n" +-" ldp s16, s17, [%3]\n" /* S2 */ ++" bti j\n"/* S2 */ ++" ldp s16, s17, [%3]\n" + " b 2f\n" + " nop\n" +-" ldr s16, [%3]\n"/* S1 */ ++" bti j\n"/* S1 */ ++" ldr s16, [%3]\n" + " b 1f\n" + " nop\n" +-" ldp d16, d17, [%3]\n" /* D4 */ ++" bti j\n"/* D4 */ ++" ldp d16, d17, [%3]\n" + " ldp d18, d19, [%3, #16]\n" + " b 4f\n" +-" ldp d16, d17, [%3]\n" /* D3 */ ++" bti j\n"/* D3 */ ++" ldp d16, d17, [%3]\n" + " ldr d18, [%3, #16]\n" + " b 3f\n" +-" ldp d16, d17, [%3]\n" /* D2 */ ++" bti j\n"/* D2 */ ++" ldp d16, d17, [%3]\n" + " b 2f\n" + " nop\n" +-" ldr d16, [%3]\n"/* D1 */ ++" bti j\n"/* D1 */ ++" ldr d16, [%3]\n" + " b 1f\n" + " nop\n" +-" ldp q16, q17, [%3]\n" /* Q4 */ ++" bti j\n"/* Q4 */ ++" ldp q16, q17, [%3]\n" + " ldp q18, q19, [%3, #32]\n" + " b 4f\n" +-" ldp q16, q17, [%3]\n" /* Q3 */ ++" bti j\n"/* Q3 */ ++" ldp q16, q17, [%3]\n" + " ldr q18, [%3, #32]\n" + " b 3f\n" +-" ldp q16, q17, [%3]\n" /* Q2 */ ++" bti j\n"/* Q2 */ ++" ldp q16, q17, [%3]\n" + " b 2f\n" + " nop\n" +-" ldr q16, [%3]\n"/* Q1 */ ++" bti j\n"/* Q1 */ ++" ldr q16, [%3]\n" + " b 1f\n" + "4: str q19, [%2, #48]\n" + "3: str q18, [%2, #32]\n" + "2: str q17, [%2, #16]\n" + "1: str q16, [%2]" + : "=&r"(x0) +-: "r"(f * 12), "r"(dest), "r"(src) ++: "r"(f * 16), "r"(dest), "r"(src) + : "memory", "v16", "v17", "v18", "v19"); + } + #endif Index: patches/patch-src_aarch64_sysv_S === RCS file: patches/patch-src_aarch64_sysv_S diff -N patches/patch-src_aarch64_sysv_S --- /dev/null 1 Jan 1970 00:00:00 - +++ patches/patch-src_aarch64_sysv_S21 Nov 2023 15:05:33 - @@ -0,0 +1,209 @@ +Index: src/aarch64/sysv.S +--- src/aarch64/sysv.S.orig src/aarch64/sysv.S +@@ -78,6 +78,7 @@ SOFTWARE OR THE USE OR OTHER DEALINGS IN THE SOFTWARE. + + cfi_startproc + CNAME(ffi_call_SYSV): ++
Re: new ports needed for spyder 5.5.0
On 2023/11/21 06:41, Daniel Dickman wrote:
> Spyder 5.5.0 needs something like 40 new ports.
>
> Here are the first 10 simpler ones.
>
> These are all standalone with no dependencies among themselves, except
> that exceptiongroup has a BDEP on flit_scm.
>
> The rest are all mostly dependencies needed to import other ports, or
> update the jupyter stack to what the new spyder version needs.
>
> ok to import these to start?
py-exceptiongroup should use MODPY_PYBUILD=flit_core not flit.
Alternatively we could add this to python.port.mk and set
MODPY_PYBUILD=flit_scm and use that instead.
Rest are all ok.
Index: python.port.mk
===
RCS file: /cvs/ports/lang/python/python.port.mk,v
retrieving revision 1.179
diff -u -p -r1.179 python.port.mk
--- python.port.mk 20 Sep 2023 13:41:38 - 1.179
+++ python.port.mk 21 Nov 2023 12:33:10 -
@@ -209,6 +209,8 @@ BUILD_DEPENDS +=devel/py-build${MODPY_F
devel/py-installer${MODPY_FLAVOR}
. if ${MODPY_PYBUILD} == flit_core
BUILD_DEPENDS += devel/py-flit_core${MODPY_FLAVOR}
+. elif ${MODPY_PYBUILD} == flit_scm
+BUILD_DEPENDS += devel/py-flit_scm${MODPY_FLAVOR}
. elif ${MODPY_PYBUILD} == flit
BUILD_DEPENDS += devel/py-flit${MODPY_FLAVOR}
. elif ${MODPY_PYBUILD} == hatchling
@@ -224,7 +226,7 @@ BUILD_DEPENDS +=devel/py-setuptools${MO
BUILD_DEPENDS += devel/py-setuptools_scm${MODPY_FLAVOR}
.endif
. elif !${MODPY_PYBUILD:L:Myes}
-ERRORS += "Fatal: unknown MODPY_PYBUILD value (flit_core, flit,
hatchling, hatch-vcs, poetry-core, setuptools, setuptools_scm)"
+ERRORS += "Fatal: unknown MODPY_PYBUILD value (flit_core,
flit_scm, flit, hatchling, hatch-vcs, poetry-core, setuptools, setuptools_scm)"
. endif
.else
# Try to detect the case where a port will build regardless of setuptools
new ports needed for spyder 5.5.0
Spyder 5.5.0 needs something like 40 new ports. Here are the first 10 simpler ones. These are all standalone with no dependencies among themselves, except that exceptiongroup has a BDEP on flit_scm. The rest are all mostly dependencies needed to import other ports, or update the jupyter stack to what the new spyder version needs. ok to import these to start? py-whatthepatch.tgz Description: Binary data py-rtree.tgz Description: Binary data py-python-lsp-jsonrpc.tgz Description: Binary data py-pylint-venv.tgz Description: Binary data py-nest-asyncio.tgz Description: Binary data py-inflection.tgz Description: Binary data py-flit_scm.tgz Description: Binary data py-exceptiongroup.tgz Description: Binary data py-docstring-to-markdown.tgz Description: Binary data py-comm.tgz Description: Binary data
Re: [update, add pledge/unveil] net/iperf3 3.14 -> 3.15
Thanks, fixed. On 2023/11/20 22:06, Alexander Bluhm wrote: > This breaks iperf3 in my setup. > > root@ot50:.../~# iperf3 -sD > Abort trap (core dumped) > > iperf3[72726]: pledge "proc", syscall 2 > > Program terminated with signal SIGABRT, Aborted. > #0 _thread_sys_fork () at /tmp/-:2 > 2 /tmp/-: No such file or directory. > (gdb) bt > #0 _thread_sys_fork () at /tmp/-:2 > #1 0x6b01f3ff9bf18acf in ?? () > #2 0x04b673981f86 in daemon (nochdir=0, noclose=0) > at /usr/src/lib/libc/gen/daemon.c:41 > #3 0x04b3c8078629 in ?? () > #4 0x04b3c8078423 in ?? () > #5 0x04b3c8078131 in ?? () > #6 0x in ?? () > > Pledge should be done after initialization, but before running phase. > Call it after daemon(3). > > bluhm > > On Sat, Oct 21, 2023 at 07:28:06PM +0100, Stuart Henderson wrote: > > ...also as was as syscalls, socket options could do with checking over too. > > > > If everything is in order then there's not much point adding a configure > > flag really, just check for pledge > > > > -- > > Sent from a phone, apologies for poor formatting. > > > > On 21 October 2023 19:01:33 Stuart Henderson wrote: > > > > > It hasn't been properly reviewed to check if there are any syscalls which > > > aren't covered by the pledge. I found the diskfile one which you missed, > > > but haven't checked over nm output to look for more. > > > > > > -- > > > Sent from a phone, apologies for poor formatting. > > > > > > On 21 October 2023 18:57:55 Mikhail wrote: > > > > > >> On Sat, Oct 21, 2023 at 06:38:57PM +0100, Stuart Henderson wrote: > > >>> Err, sending that upstream is a bit premature. > > >> > > >> Reasons? It works fine in my testing, also it's enabled only with > > >> --enable-openbsd-sandbox, so if something arise it's very easy for the > > >> users to check without this code. And during review the devs can point > > >> to improvements. > > >> > > >> I can close the PR, it's not a problem. >
Re: libffi: fix arm64 bti
> Date: Tue, 21 Nov 2023 12:04:42 +0100 > From: Tobias Heider > > On Tue, Nov 21, 2023 at 11:56:18AM +0100, Mark Kettenis wrote: > > > Date: Tue, 21 Nov 2023 00:16:40 +0100 > > > From: Tobias Heider > > > > > > Diff below fixes make regress for libffi with arm64 BTI enabled. > > > The tricky part were two jump tables in ffi.c and sysV.S. > > > > > > ok? > > > > I think you missed the "computed goto" in ffi_closure_SYSV. > > > > Maybe we shouldn't add a "bti j" for the unused slots? > > Functionally yes, that should also work and makes more sense. > But then the brks would be a bit redundant. I wasn't sure if there > are tests or something that expects those breaks to be reachable. The brks still need to be there for those poor CPUs that don't implement BTI. > > > Index: Makefile > > > === > > > RCS file: /cvs/ports/devel/libffi/Makefile,v > > > retrieving revision 1.48 > > > diff -u -p -r1.48 Makefile > > > --- Makefile 21 Sep 2023 09:49:57 - 1.48 > > > +++ Makefile 20 Nov 2023 23:14:17 - > > > @@ -1,6 +1,7 @@ > > > COMMENT= Foreign Function Interface > > > > > > V= 3.4.4 > > > +REVISION=0 > > > DISTNAME=libffi-$V > > > SHARED_LIBS += ffi 2.0 # 9.2 > > > CATEGORIES= devel > > > Index: patches/patch-src_aarch64_ffi_c > > > === > > > RCS file: patches/patch-src_aarch64_ffi_c > > > diff -N patches/patch-src_aarch64_ffi_c > > > --- /dev/null 1 Jan 1970 00:00:00 - > > > +++ patches/patch-src_aarch64_ffi_c 20 Nov 2023 23:14:17 - > > > @@ -0,0 +1,76 @@ > > > +Index: src/aarch64/ffi.c > > > +--- src/aarch64/ffi.c.orig > > > src/aarch64/ffi.c > > > +@@ -390,47 +390,59 @@ extend_hfa_type (void *dest, void *src, int h) > > > + "adr%0, 0f\n" > > > + " add %0, %0, %1\n" > > > + " br %0\n" > > > +-"0: ldp s16, s17, [%3]\n" /* S4 */ > > > ++"0: bti j\n"/* S4 */ > > > ++" ldp s16, s17, [%3]\n" > > > + " ldp s18, s19, [%3, #8]\n" > > > + " b 4f\n" > > > +-" ldp s16, s17, [%3]\n" /* S3 */ > > > ++" bti j\n"/* S3 */ > > > ++" ldp s16, s17, [%3]\n" > > > + " ldr s18, [%3, #8]\n" > > > + " b 3f\n" > > > +-" ldp s16, s17, [%3]\n" /* S2 */ > > > ++" bti j\n"/* S2 */ > > > ++" ldp s16, s17, [%3]\n" > > > + " b 2f\n" > > > + " nop\n" > > > +-" ldr s16, [%3]\n"/* S1 */ > > > ++" bti j\n"/* S1 */ > > > ++" ldr s16, [%3]\n" > > > + " b 1f\n" > > > + " nop\n" > > > +-" ldp d16, d17, [%3]\n" /* D4 */ > > > ++" bti j\n"/* D4 */ > > > ++" ldp d16, d17, [%3]\n" > > > + " ldp d18, d19, [%3, #16]\n" > > > + " b 4f\n" > > > +-" ldp d16, d17, [%3]\n" /* D3 */ > > > ++" bti j\n"/* D3 */ > > > ++" ldp d16, d17, [%3]\n" > > > + " ldr d18, [%3, #16]\n" > > > + " b 3f\n" > > > +-" ldp d16, d17, [%3]\n" /* D2 */ > > > ++" bti j\n"/* D2 */ > > > ++" ldp d16, d17, [%3]\n" > > > + " b 2f\n" > > > + " nop\n" > > > +-" ldr d16, [%3]\n"/* D1 */ > > > ++" bti j\n"/* D1 */ > > > ++" ldr d16, [%3]\n" > > > + " b 1f\n" > > > + " nop\n" > > > +-" ldp q16, q17, [%3]\n" /* Q4 */ > > > ++" bti j\n"/* Q4 */ > > > ++" ldp q16, q17, [%3]\n" > > > + " ldp q18, q19, [%3, #32]\n" > > > + " b 4f\n" > > > +-" ldp q16, q17, [%3]\n" /* Q3 */ > > > ++" bti j\n"/* Q3 */ > > > ++" ldp q16, q17, [%3]\n" > > > + " ldr q18, [%3, #32]\n" > > > + " b 3f\n" > > > +-" ldp q16, q17, [%3]\n" /* Q2 */ > > > ++" bti j\n"/* Q2 */ > > > ++" ldp q16, q17, [%3]\n" > > > + " b 2f\n" > > > + " nop\n" > > > +-" ldr q16, [%3]\n"/* Q1 */ > > > ++" bti j\n"/* Q1 */ > > > ++" ldr q16, [%3]\n" > > > + " b 1f\n" > > > + "4: str q19, [%2, #48]\n" > > > + "3: str q18, [%2, #32]\n" > > > + "2: str q17, [%2, #16]\n" > > > + "1: str q16, [%2]" > > > + : "=&r"(x0) > > > +-: "r"(f * 12), "r"(dest), "r"(src) > > > ++: "r"(f * 16), "r"(dest), "r"(src) > > > + : "memory", "v16", "v17", "v18", "v19"); > > > + } > > > + #endif > > > Index: patch
Re: Port for bazel-6.3.2
On 2023/11/20 17:02, Greg Steuck wrote:
> The Google polyglot build tool at https://bazel.build/ turned out to be
> a bit more trouble to port than usual, but it is somewhat functional
> with the preliminary port below.
>
> The effort is losely based on the previous attempt by Matt Hildebrand
> from 2020 (thanks Matt!).
>
> I'm not yet sure if I want this in the tree. I'll keep it around until
> somebody else wants to put it in.
>
> I still haven't figured out how to configure the packaged bazel to
> rebuild bazel from the source tree. The toolchain mechanism is just too
> much for me to grasp. If somebody figures out the magic, do let me know.
>
> Thanks
> Greg
>
some tweaks for consideration,
- drop rcs id
- no point restricting untested archs
- unzip is already auto-added to BDEPs
- no need to set MODPY_VERSION to what's already the default
- verbose builds are often helpful to figure out any issues in
bulk builds
- use DIST_TUPLE (also needs "make makesum" to regen distinfo)
--- Makefile.orig Tue Nov 21 10:56:58 2023
+++ MakefileTue Nov 21 11:08:04 2023
@@ -1,8 +1,3 @@
-# $OpenBSD: Makefile,v$
-
-# Haven't tested anything else yet.
-ONLY_FOR_ARCHS = amd64
-
VERSION = 6.3.2
COMMENT = polyglot build tool
@@ -14,7 +9,7 @@ EXTRACT_CASES =*.zip) ${UNZIP} -Laq
${FULLDISTDIR}/$
CATEGORIES = devel
-# Apache 2.0 license.
+# Apache 2.0
PERMIT_PACKAGE = Yes
WANTLIB += ${COMPILER_LIBCXX} c m
@@ -24,15 +19,12 @@ SITES =
https://github.com/bazelbuild/bazel/releases
EXTRACT_SUFX = -dist.zip
ABSEIL_VER = 20230802.1
-DISTFILES.abseil = abseil-{}${ABSEIL_VER}.tar.gz
-SITES.abseil = https://github.com/abseil/abseil-cpp/archive/refs/tags/
+DIST_TUPLE = github abseil abseil-cpp 20230802.1 .
MODULES = java lang/python
MODJAVA_VER = 17
-MODPY_VERSION =${MODPY_DEFAULT_VERSION_3}
BUILD_DEPENDS =archivers/zip \
- archivers/unzip \
shells/bash
EXTRACT_ONLY = ${DISTFILES}
@@ -41,12 +33,15 @@ EXTRACT_ONLY = ${DISTFILES}
# stripping the binary removes this zip file, breaking the binary.
INSTALL_STRIP =
+MAKE_ENV = VERBOSE=yes
+
# The bundled verison of abseil is from 2021 and isn't compatible with
clang-16.
post-patch:
- cp ${FULLDISTDIR}/abseil-${ABSEIL_VER}.tar.gz
${WRKSRC}/derived/distdir/${ABSEIL_VER}.tar.gz
+ cp ${FULLDISTDIR}/abseil-abseil-cpp-${ABSEIL_VER}.tar.gz \
+ ${WRKSRC}/derived/distdir/${ABSEIL_VER}.tar.gz
do-build:
- cd ${WRKSRC} && ${SETENV} \
+ cd ${WRKSRC} && ${SETENV} ${MAKE_ENV} \
EMBED_LABEL="${VERSION}" \
EXTRA_BAZEL_ARGS="--tool_java_runtime_version=local_jdk_${MODJAVA_VER}" \
BAZEL_WRKDIR=${WRKDIR}/tmp \
Re: libffi: fix arm64 bti
On Tue, Nov 21, 2023 at 11:56:18AM +0100, Mark Kettenis wrote: > > Date: Tue, 21 Nov 2023 00:16:40 +0100 > > From: Tobias Heider > > > > Diff below fixes make regress for libffi with arm64 BTI enabled. > > The tricky part were two jump tables in ffi.c and sysV.S. > > > > ok? > > I think you missed the "computed goto" in ffi_closure_SYSV. > > Maybe we shouldn't add a "bti j" for the unused slots? Functionally yes, that should also work and makes more sense. But then the brks would be a bit redundant. I wasn't sure if there are tests or something that expects those breaks to be reachable. > > > Index: Makefile > > === > > RCS file: /cvs/ports/devel/libffi/Makefile,v > > retrieving revision 1.48 > > diff -u -p -r1.48 Makefile > > --- Makefile21 Sep 2023 09:49:57 - 1.48 > > +++ Makefile20 Nov 2023 23:14:17 - > > @@ -1,6 +1,7 @@ > > COMMENT= Foreign Function Interface > > > > V= 3.4.4 > > +REVISION= 0 > > DISTNAME= libffi-$V > > SHARED_LIBS += ffi 2.0 # 9.2 > > CATEGORIES=devel > > Index: patches/patch-src_aarch64_ffi_c > > === > > RCS file: patches/patch-src_aarch64_ffi_c > > diff -N patches/patch-src_aarch64_ffi_c > > --- /dev/null 1 Jan 1970 00:00:00 - > > +++ patches/patch-src_aarch64_ffi_c 20 Nov 2023 23:14:17 - > > @@ -0,0 +1,76 @@ > > +Index: src/aarch64/ffi.c > > +--- src/aarch64/ffi.c.orig > > src/aarch64/ffi.c > > +@@ -390,47 +390,59 @@ extend_hfa_type (void *dest, void *src, int h) > > + "adr%0, 0f\n" > > + " add %0, %0, %1\n" > > + " br %0\n" > > +-"0: ldp s16, s17, [%3]\n" /* S4 */ > > ++"0: bti j\n"/* S4 */ > > ++" ldp s16, s17, [%3]\n" > > + " ldp s18, s19, [%3, #8]\n" > > + " b 4f\n" > > +-" ldp s16, s17, [%3]\n" /* S3 */ > > ++" bti j\n"/* S3 */ > > ++" ldp s16, s17, [%3]\n" > > + " ldr s18, [%3, #8]\n" > > + " b 3f\n" > > +-" ldp s16, s17, [%3]\n" /* S2 */ > > ++" bti j\n"/* S2 */ > > ++" ldp s16, s17, [%3]\n" > > + " b 2f\n" > > + " nop\n" > > +-" ldr s16, [%3]\n"/* S1 */ > > ++" bti j\n"/* S1 */ > > ++" ldr s16, [%3]\n" > > + " b 1f\n" > > + " nop\n" > > +-" ldp d16, d17, [%3]\n" /* D4 */ > > ++" bti j\n"/* D4 */ > > ++" ldp d16, d17, [%3]\n" > > + " ldp d18, d19, [%3, #16]\n" > > + " b 4f\n" > > +-" ldp d16, d17, [%3]\n" /* D3 */ > > ++" bti j\n"/* D3 */ > > ++" ldp d16, d17, [%3]\n" > > + " ldr d18, [%3, #16]\n" > > + " b 3f\n" > > +-" ldp d16, d17, [%3]\n" /* D2 */ > > ++" bti j\n"/* D2 */ > > ++" ldp d16, d17, [%3]\n" > > + " b 2f\n" > > + " nop\n" > > +-" ldr d16, [%3]\n"/* D1 */ > > ++" bti j\n"/* D1 */ > > ++" ldr d16, [%3]\n" > > + " b 1f\n" > > + " nop\n" > > +-" ldp q16, q17, [%3]\n" /* Q4 */ > > ++" bti j\n"/* Q4 */ > > ++" ldp q16, q17, [%3]\n" > > + " ldp q18, q19, [%3, #32]\n" > > + " b 4f\n" > > +-" ldp q16, q17, [%3]\n" /* Q3 */ > > ++" bti j\n"/* Q3 */ > > ++" ldp q16, q17, [%3]\n" > > + " ldr q18, [%3, #32]\n" > > + " b 3f\n" > > +-" ldp q16, q17, [%3]\n" /* Q2 */ > > ++" bti j\n"/* Q2 */ > > ++" ldp q16, q17, [%3]\n" > > + " b 2f\n" > > + " nop\n" > > +-" ldr q16, [%3]\n"/* Q1 */ > > ++" bti j\n"/* Q1 */ > > ++" ldr q16, [%3]\n" > > + " b 1f\n" > > + "4: str q19, [%2, #48]\n" > > + "3: str q18, [%2, #32]\n" > > + "2: str q17, [%2, #16]\n" > > + "1: str q16, [%2]" > > + : "=&r"(x0) > > +-: "r"(f * 12), "r"(dest), "r"(src) > > ++: "r"(f * 16), "r"(dest), "r"(src) > > + : "memory", "v16", "v17", "v18", "v19"); > > + } > > + #endif > > Index: patches/patch-src_aarch64_sysv_S > > === > > RCS file: patches/patch-src_aarch64_sysv_S > > diff -N patches/patch-src_aarch64_sysv_S > > --- /dev/null 1 Jan 1970 00:00:00 - > > +++ patches/patch-src_aarch64_sysv_S20 Nov 2023 23:14:17 - > > @@ -0,0 +1,220 @@ > > +Index: src/aarch64/sysv.S > > +--- src/aarch64/sysv.S.orig > > src/aarch64/sysv.S > > +@@ -78,6 +78,7 @@ SOFTWARE OR THE USE OR OTHER DEALINGS IN THE SOFTWARE. > > + > > + cfi_startproc > > + CNAME(ffi_call_SYSV): > > ++ bti c > > + /* Sign the lr with x1 since that is where it will be stored */ > > + SIGN_LR_WITH_REG(x1) > > + > > +@@ -138,78 +139,142 @@ CNAME(ffi_call
Re: libffi: fix arm64 bti
> Date: Tue, 21 Nov 2023 00:16:40 +0100 > From: Tobias Heider > > Diff below fixes make regress for libffi with arm64 BTI enabled. > The tricky part were two jump tables in ffi.c and sysV.S. > > ok? I think you missed the "computed goto" in ffi_closure_SYSV. Maybe we shouldn't add a "bti j" for the unused slots? > Index: Makefile > === > RCS file: /cvs/ports/devel/libffi/Makefile,v > retrieving revision 1.48 > diff -u -p -r1.48 Makefile > --- Makefile 21 Sep 2023 09:49:57 - 1.48 > +++ Makefile 20 Nov 2023 23:14:17 - > @@ -1,6 +1,7 @@ > COMMENT= Foreign Function Interface > > V= 3.4.4 > +REVISION=0 > DISTNAME=libffi-$V > SHARED_LIBS += ffi 2.0 # 9.2 > CATEGORIES= devel > Index: patches/patch-src_aarch64_ffi_c > === > RCS file: patches/patch-src_aarch64_ffi_c > diff -N patches/patch-src_aarch64_ffi_c > --- /dev/null 1 Jan 1970 00:00:00 - > +++ patches/patch-src_aarch64_ffi_c 20 Nov 2023 23:14:17 - > @@ -0,0 +1,76 @@ > +Index: src/aarch64/ffi.c > +--- src/aarch64/ffi.c.orig > src/aarch64/ffi.c > +@@ -390,47 +390,59 @@ extend_hfa_type (void *dest, void *src, int h) > + "adr%0, 0f\n" > + " add %0, %0, %1\n" > + " br %0\n" > +-"0: ldp s16, s17, [%3]\n" /* S4 */ > ++"0: bti j\n"/* S4 */ > ++" ldp s16, s17, [%3]\n" > + " ldp s18, s19, [%3, #8]\n" > + " b 4f\n" > +-" ldp s16, s17, [%3]\n" /* S3 */ > ++" bti j\n"/* S3 */ > ++" ldp s16, s17, [%3]\n" > + " ldr s18, [%3, #8]\n" > + " b 3f\n" > +-" ldp s16, s17, [%3]\n" /* S2 */ > ++" bti j\n"/* S2 */ > ++" ldp s16, s17, [%3]\n" > + " b 2f\n" > + " nop\n" > +-" ldr s16, [%3]\n"/* S1 */ > ++" bti j\n"/* S1 */ > ++" ldr s16, [%3]\n" > + " b 1f\n" > + " nop\n" > +-" ldp d16, d17, [%3]\n" /* D4 */ > ++" bti j\n"/* D4 */ > ++" ldp d16, d17, [%3]\n" > + " ldp d18, d19, [%3, #16]\n" > + " b 4f\n" > +-" ldp d16, d17, [%3]\n" /* D3 */ > ++" bti j\n"/* D3 */ > ++" ldp d16, d17, [%3]\n" > + " ldr d18, [%3, #16]\n" > + " b 3f\n" > +-" ldp d16, d17, [%3]\n" /* D2 */ > ++" bti j\n"/* D2 */ > ++" ldp d16, d17, [%3]\n" > + " b 2f\n" > + " nop\n" > +-" ldr d16, [%3]\n"/* D1 */ > ++" bti j\n"/* D1 */ > ++" ldr d16, [%3]\n" > + " b 1f\n" > + " nop\n" > +-" ldp q16, q17, [%3]\n" /* Q4 */ > ++" bti j\n"/* Q4 */ > ++" ldp q16, q17, [%3]\n" > + " ldp q18, q19, [%3, #32]\n" > + " b 4f\n" > +-" ldp q16, q17, [%3]\n" /* Q3 */ > ++" bti j\n"/* Q3 */ > ++" ldp q16, q17, [%3]\n" > + " ldr q18, [%3, #32]\n" > + " b 3f\n" > +-" ldp q16, q17, [%3]\n" /* Q2 */ > ++" bti j\n"/* Q2 */ > ++" ldp q16, q17, [%3]\n" > + " b 2f\n" > + " nop\n" > +-" ldr q16, [%3]\n"/* Q1 */ > ++" bti j\n"/* Q1 */ > ++" ldr q16, [%3]\n" > + " b 1f\n" > + "4: str q19, [%2, #48]\n" > + "3: str q18, [%2, #32]\n" > + "2: str q17, [%2, #16]\n" > + "1: str q16, [%2]" > + : "=&r"(x0) > +-: "r"(f * 12), "r"(dest), "r"(src) > ++: "r"(f * 16), "r"(dest), "r"(src) > + : "memory", "v16", "v17", "v18", "v19"); > + } > + #endif > Index: patches/patch-src_aarch64_sysv_S > === > RCS file: patches/patch-src_aarch64_sysv_S > diff -N patches/patch-src_aarch64_sysv_S > --- /dev/null 1 Jan 1970 00:00:00 - > +++ patches/patch-src_aarch64_sysv_S 20 Nov 2023 23:14:17 - > @@ -0,0 +1,220 @@ > +Index: src/aarch64/sysv.S > +--- src/aarch64/sysv.S.orig > src/aarch64/sysv.S > +@@ -78,6 +78,7 @@ SOFTWARE OR THE USE OR OTHER DEALINGS IN THE SOFTWARE. > + > + cfi_startproc > + CNAME(ffi_call_SYSV): > ++bti c > + /* Sign the lr with x1 since that is where it will be stored */ > + SIGN_LR_WITH_REG(x1) > + > +@@ -138,78 +139,142 @@ CNAME(ffi_call_SYSV): > + /* Save the return value as directed. */ > + adr x5, 0f > + and w4, w4, #AARCH64_RET_MASK > +-add x5, x5, x4, lsl #3 > ++add x5, x5, x4, lsl #4 > + br x5 > + > +-/* Note that each table entry is 2 insns, and thus 8 bytes. > ++/* Note that each table entry is 4 insns, and thus 16 bytes. > +For integer data, note that we're storing into ffi_arg > +and therefore we want
salt-3006.3, py3-setproctitle and rc.d(8) on -stable
Hi all, What I am reporting here, was tested on -stable and on -current. Below details are from -stable, because I discovered it first there and have the notes from that machine. One of my OpenBSD 7.4 machines, because of package unrelated to salt, had py3-setproctitle installed on that machine and that resuled in following problem: ks3# rcctl check salt_minion salt_minion(failed) It seems that pexp from /etc/rc.d/salt_minion doesn't match the process when salt minion is started with py3-setproctitle package available. Here are more details: ks3# sysctl -n kern.version OpenBSD 7.4 (GENERIC.MP) #0: Sun Oct 22 12:13:42 MDT 2023 r...@syspatch-74-amd64.openbsd.org:/usr/src/sys/arch/amd64/compile/GENERIC.MP ks3# cat /etc/installurl https://cdn.openbsd.org/pub/OpenBSD/ ks3# pkg_info -qI salt salt-3006.3 No py3-setproctitle installed: ks3# ls -1 /var/db/pkg/ | grep -ci proc 0 ks3# pkg_add -a -i py3-setproctitle quirks-6.160 signed on 2023-11-19T13:55:25Z py3-setproctitle-1.3.2p1: ok ks3# rcctl restart salt_minion salt_minion(ok) salt_minion(ok) ks3# pgrep -lf salt 8102 python3.10: /usr/local/bin/python3.10 /usr/local/bin/salt-minion -d MainProcess ks3# rcctl check salt_minion salt_minion(failed) If we wait for random_startup_delay: ks3# grep -e ^random_startup_delay /etc/salt/minion random_startup_delay: 180 then proc title changes again: ks3# pgrep -lf salt 8102 python3.10: /usr/local/bin/python3.10 /usr/local/bin/salt-minion -d MultiMinionProcessManager MinionProcessManager ks3# pkg_delete -c py3-setproctitle py3-setproctitle-1.3.2p1: ok Read shared items: ok ks3# rcctl restart salt_minion salt_minion(ok) ks3# pgrep -lf salt 78929 /usr/local/bin/python3.10 /usr/local/bin/salt-minion -d 8102 python3.10: /usr/local/bin/python3.10 /usr/local/bin/salt-minion -d MultiMinionProcessManager MinionProcessManager We see above orphaned previous instance of salt-minion which had setproctitle loaded. ks3# kill 8102 ks3# pgrep -lf salt 78929 /usr/local/bin/python3.10 /usr/local/bin/salt-minion -d ks3# rcctl check salt_minion salt_minion(ok) -- Regards, Mikolaj
Re: UPDATE: x11/qt6
> diff --git > a/x11/qt6/qtbase/patches/patch-src_network_ssl_qsslsocket_openssl_symbols_cpp > b/x11/qt6/qtbase/patches/patch-src_network_ssl_qsslsocket_openssl_symbols_cpp > index a845b21c71e..b6cf19f47c5 100644 > --- > a/x11/qt6/qtbase/patches/patch-src_network_ssl_qsslsocket_openssl_symbols_cpp > +++ > b/x11/qt6/qtbase/patches/patch-src_network_ssl_qsslsocket_openssl_symbols_cpp > @@ -1,20 +1,19 @@ > Index: src/plugins/tls/openssl/qsslsocket_openssl_symbols.cpp > --- src/plugins/tls/openssl/qsslsocket_openssl_symbols.cpp.orig > +++ src/plugins/tls/openssl/qsslsocket_openssl_symbols.cpp > -@@ -112,23 +112,37 @@ DEFINEFUNC(const BIO_METHOD *, BIO_s_mem, void, DUMMYA > +@@ -112,7 +112,11 @@ DEFINEFUNC(const BIO_METHOD *, BIO_s_mem, void, DUMMYA > DEFINEFUNC2(int, BN_is_word, BIGNUM *a, a, BN_ULONG w, w, return 0, return) > DEFINEFUNC(int, EVP_CIPHER_CTX_reset, EVP_CIPHER_CTX *c, c, return 0, > return) > DEFINEFUNC(int, EVP_PKEY_up_ref, EVP_PKEY *a, a, return 0, return) > +#ifdef OPENSSL_NO_DEPRECATED_3_0 > DEFINEFUNC2(EVP_PKEY_CTX *, EVP_PKEY_CTX_new, EVP_PKEY *pkey, pkey, ENGINE > *e, e, return nullptr, return) > +DEFINEFUNC2(EVP_PKEY_CTX *, EVP_PKEY_CTX_new, EVP_PKEY *pkey, pkey, ENGINE > *e, e, return nullptr, return) This entire hunk looks wrong. Is this a git merge accident? It makes no sense to duplicate the DEFINEFUNC2 line for EVP_PKEY_CTX_new(). The function isn't deprecated in OpenSSL 3, so it shouldn't be wrapped in #ifdef OPENSSL_NO_DEPRECATED_3_0 in the first place. > - DEFINEFUNC(int, EVP_PKEY_param_check, EVP_PKEY_CTX *ctx, ctx, return 0, > return) > - DEFINEFUNC(void, EVP_PKEY_CTX_free, EVP_PKEY_CTX *ctx, ctx, return, return) > +#endif // OPENSSL_NO_DEPRECATED_3_0 > +#ifndef LIBRESSL_VERSION_NUMBER > + DEFINEFUNC(int, EVP_PKEY_param_check, EVP_PKEY_CTX *ctx, ctx, return 0, > return) > + DEFINEFUNC(void, EVP_PKEY_CTX_free, EVP_PKEY_CTX *ctx, ctx, return, return) Both these functions are available in LibreSSL, so the #ifndef should go after them. The OPENSSL_sk_*() functions aren't available and we should use sk_* instead. > DEFINEFUNC(int, OPENSSL_sk_num, OPENSSL_STACK *a, a, return -1, return) > - DEFINEFUNC2(void, OPENSSL_sk_pop_free, OPENSSL_STACK *a, a, void > (*b)(void*), b, return, DUMMYARG) > - DEFINEFUNC(OPENSSL_STACK *, OPENSSL_sk_new_null, DUMMYARG, DUMMYARG, return > nullptr, return) > +@@ -121,14 +125,24 @@ DEFINEFUNC(OPENSSL_STACK *, OPENSSL_sk_new_null, DUMMY > DEFINEFUNC2(void, OPENSSL_sk_push, OPENSSL_STACK *a, a, void *b, b, return, > DUMMYARG) > DEFINEFUNC(void, OPENSSL_sk_free, OPENSSL_STACK *a, a, return, DUMMYARG) > DEFINEFUNC2(void *, OPENSSL_sk_value, OPENSSL_STACK *a, a, int b, b, return > nullptr, return) > @@ -25,7 +24,7 @@ Index: > src/plugins/tls/openssl/qsslsocket_openssl_symbols.cpp > +DEFINEFUNC2(void, sk_push, _STACK *a, a, void *b, b, return, DUMMYARG) > +DEFINEFUNC(void, sk_free, _STACK *a, a, return, DUMMYARG) > +DEFINEFUNC2(void *, sk_value, STACK *a, a, int b, b, return nullptr, return) > -+#endif // LIBRESSL_VERSION_NUMBER > ++#endif // LIBRESSL_VERSION_NUMBE typo The entire patch looks like it needs some love, but I can deal with that once you landed it.
Re: aarch64 bulk build report
I removed the entries that are either already fixed, or a fix is incoming. On 2023 Nov 20 (Mon) at 22:58:51 -0700 (-0700), phess...@openbsd.org wrote: :http://build-failures.rhaalovely.net/aarch64/2023-11-18/net/nheko.log FAILED: CMakeFiles/nheko.dir/nheko_autogen/mocs_compilation.cpp.o /usr/obj/ports/nheko-0.11.3/bin/c++ -DFMT_SHARED -DGSTREAMER_AVAILABLE -DNHEKO_DBUS_SYS -DQAPPLICATION_CLASS=QApplication -DQT_CONCURRENT_LIB -DQT_CORE_LIB -DQT_DBUS_LIB -DQT_GUI_LIB -DQT_MULTIMEDIA_LIB -DQT_NETWORK_LIB -DQT_NO_DEBUG -DQT_QMLMODELS_LIB -DQT_QML_LIB -DQT_QUICKCONTROLS2_LIB -DQT_QUICKWIDGETS_LIB -DQT_QUICK_LIB -DQT_SVG_LIB -DQT_WIDGETS_LIB -DSPDLOG_COMPILED_LIB -DSPDLOG_SHARED_LIB -DXCB_AVAILABLE -I/usr/obj/ports/nheko-0.11.3/build-aarch64 -I/usr/obj/ports/nheko-0.11.3/nheko-0.11.3 -I/usr/obj/ports/nheko-0.11.3/build-aarch64/nheko_autogen/include -I/usr/obj/ports/nheko-0.11.3/nheko-0.11.3/src -I/usr/obj/ports/nheko-0.11.3/nheko-0.11.3/includes -I/usr/obj/ports/nheko-0.11.3/nheko-0.11.3/third_party/cpp-httplib-0.5.12 -I/usr/obj/ports/nheko-0.11.3/nheko-0.11.3/third_party/blurhash -I/usr/obj/ports/nheko-0.11.3/nheko-0.11.3/third_party/SingleApplication-3.3.2 -isystem /usr/local/include/X11/qt5 -isystem /usr/local/include/X11/qt5/QtDBus -isystem /usr/local/include/X11/qt5/QtCore -isystem /usr/local/lib/qt5/./mkspecs/openbsd-clang -isystem /usr/local/include -isystem /usr/local/include/X11/qt5/QtWidgets -isystem /usr/local/include/X11/qt5/QtGui -isystem /usr/X11R6/include -isystem /usr/local/include/X11/qt5/QtSvg -isystem /usr/local/include/X11/qt5/QtConcurrent -isystem /usr/local/include/X11/qt5/QtMultimedia -isystem /usr/local/include/X11/qt5/QtNetwork -isystem /usr/local/include/X11/qt5/QtQml -isystem /usr/local/include/X11/qt5/QtQuickControls2 -isystem /usr/local/include/X11/qt5/QtQuick -isystem /usr/local/include/X11/qt5/QtQmlModels -isystem /usr/local/include/X11/qt5/QtQuickWidgets -isystem /usr/local/include/gstreamer-1.0 -isystem /usr/local/include/orc-0.4 -isystem /usr/local/include/glib-2.0 -isystem /usr/local/lib/glib-2.0/include -O2 -pipe -Wall -Wextra -pedantic -fsized-deallocation-fdiagnostics-color=always -Wunreachable-code -Wno-attributes -Wshadow -DNDEBUG -std=gnu++20 -fPIE -fPIC -pthread -Winvalid-pch -Xclang -include-pch -Xclang /usr/obj/ports/nheko-0.11.3/build-aarch64/CMakeFiles/nheko.dir/cmake_pch.hxx.pch -Xclang -include -Xclang /usr/obj/ports/nheko-0.11.3/build-aarch64/CMakeFiles/nheko.dir/cmake_pch.hxx -MD -MT CMakeFiles/nheko.dir/nheko_autogen/mocs_compilation.cpp.o -MF CMakeFiles/nheko.dir/nheko_autogen/mocs_compilation.cpp.o.d -o CMakeFiles/nheko.dir/nheko_autogen/mocs_compilation.cpp.o -c /usr/obj/ports/nheko-0.11.3/build-aarch64/nheko_autogen/mocs_compilation.cpp In file included from /usr/obj/ports/nheko-0.11.3/build-aarch64/nheko_autogen/mocs_compilation.cpp:2: In file included from /usr/obj/ports/nheko-0.11.3/build-aarch64/nheko_autogen/UVLADIE3JM/moc_AliasEditModel.cpp:10: In file included from /usr/obj/ports/nheko-0.11.3/build-aarch64/nheko_autogen/UVLADIE3JM/../../../nheko-0.11.3/src/AliasEditModel.h:8: In file included from /usr/local/include/X11/qt5/QtCore/QAbstractListModel:1: In file included from /usr/local/include/X11/qt5/QtCore/qabstractitemmodel.h:43: In file included from /usr/local/include/X11/qt5/QtCore/qvariant.h:44: In file included from /usr/local/include/X11/qt5/QtCore/qbytearray.h:50: /usr/include/stdarg.h:27:9: error: reference to '__builtin_va_list' is ambiguous typedef __builtin_va_list __gnuc_va_list; ^ note: candidate found by name lookup is '__builtin_va_list' note: candidate found by name lookup is '__builtin_va_list' :http://build-failures.rhaalovely.net/aarch64/2023-11-18/sysutils/cdrtools.log Hung for more than 9 hours while building cc -o OBJ/aarch64-openbsd-cc/avoffset OBJ/aarch64-openbsd-cc/avoffset.o -L../libs/aarch64-openbsd-cc -L../libs/aarch64-openbsd-cc -L/opt/schily/lib ==> GENERATING include file "../incs/aarch64-openbsd-cc/avoffset.h" The hang did not happen before clang16. -- The only way to get rid of a temptation is to yield to it. -- Oscar Wilde
Re: error on quirks
Hi, I forgot to do a "make clean" into /usr/ports/devel/quirks after each new package built. Finally, quirks build correctly with the following update.list: moo-1.5p0:@name moo-1.5p0 moo-1.5p0:@version 10 moo-1.5p0:@comment pkgpath=math/moo ftp=yes moo-1.5p0:@arch amd64 moo-1.5p0:@wantlib c.97.1 colorls-7.4:@name colorls-7.4 colorls-7.4:@version 10 colorls-7.4:@comment pkgpath=sysutils/colorls ftp=yes colorls-7.4:@arch amd64 colorls-7.4:@wantlib c.97.1 colorls-7.4:@wantlib curses.15.0 colorls-7.4:@wantlib util.17.0 colortree-1.8.0:@name colortree-1.8.0 colortree-1.8.0:@version 10 colortree-1.8.0:@comment pkgpath=sysutils/colortree ftp=yes colortree-1.8.0:@arch amd64 colortree-1.8.0:@wantlib c.97.1 entr-5.5:@name entr-5.5 entr-5.5:@version 10 entr-5.5:@comment pkgpath=sysutils/entr ftp=yes entr-5.5:@arch amd64 entr-5.5:@wantlib c.97.1 cpuid-20231115:@name cpuid-20231115 cpuid-20231115:@version 10 cpuid-20231115:@comment pkgpath=sysutils/cpuid ftp=yes cpuid-20231115:@arch amd64 cpuid-20231115:@wantlib c.97.1 mpack-1.6p3:@name mpack-1.6p3 mpack-1.6p3:@version 10 mpack-1.6p3:@comment pkgpath=converters/mpack ftp=yes mpack-1.6p3:@arch amd64 mpack-1.6p3:@wantlib c.97.1 wtf-20230906:@name wtf-20230906 wtf-20230906:@comment pkgpath=games/wtf ftp=yes wtf-20230906:@arch * obsdfreqd-1.2.1:@name obsdfreqd-1.2.1 obsdfreqd-1.2.1:@version 10 obsdfreqd-1.2.1:@comment pkgpath=sysutils/obsdfreqd ftp=yes obsdfreqd-1.2.1:@arch amd64 obsdfreqd-1.2.1:@wantlib c.97.1 obsdfreqd-1.2.1:@wantlib m.10.1 crashme-2.4p1:@name crashme-2.4p1 crashme-2.4p1:@version 10 crashme-2.4p1:@comment pkgpath=sysutils/crashme ftp=yes crashme-2.4p1:@arch amd64 crashme-2.4p1:@wantlib c.97.1 -- Manuel Giraud
