Re: [NEW/wip]: compiledb —— tool for generating Clang's JSON Compilation Database

[Mikhail Pchelin]

On Wed, Jul 10, 2024 at 10:43:29PM +0100, Stuart Henderson wrote:
> On 2024/07/10 21:23, Fabien Romano wrote:
> > Please see previous thread.
> > 
> > https://marc.info/?l=openbsd-ports&m=171472517500931&w=2
> > 
> > Same tgz attached. Maybe it also need your patches/patch-setup_py.
> 
> I think this one is slightly closer to being ready to import, so I'll
> comment on this one but some of the bits from Artsiom's port would be
> good to bring in.
[...]

Ping.


compiledb_v3.tgz
Description: application/gtar-compressed

Re: [NEW/wip]: compiledb —— tool for generating Clang's JSON Compilation Database

[Mikhail Pchelin]

On Thu, Jul 11, 2024 at 09:04:22AM +0100, Fabien Romano wrote:
> 
> What about this one ?
> 
> Tool for generating Clang's JSON Compilation Database file for GNU make-based
> build systems. The generated compile_commands.json in combination with clangd
> (devel/clang-tools-extra) language server provides IDE-like features to 
> editors
> such as code completion, compile errors, go-to-definition and more.

Thank you for picking this up.

New tarball with two README additions, first one from your previous mail
(about increasing the limits) second one to not scary new LSP users
about huge resources usage. Maybe they belong to clangd port, but I
think they have more chances to be noted here.

Reviews, thoughts, oks?

--- compiledb.orig/pkg/README   2024-07-11 17:27:58.549502000 +0300
+++ compiledb/pkg/README2024-07-11 17:33:38.993127000 +0300
@@ -6,6 +6,13 @@
 but you can try to feed usual make output to it through a pipe, or --parse
 option.

+Running big project with clangd will require a lot of memory, you may consider
+increasing 'datasize' capabilities for you login class in /etc/login.conf.
+
+When you first run LSP enabled editor with fresh compile_commands.json, clangd
+will start building cache, it is required only for the first time and
+consequent startups will be much faster and less cpu intensive.
+
 Examples:

 1) To make compile_commands.json file for OpenBSD kernel use:



compiledb_v3.tgz
Description: application/gtar-compressed

comms/hackrf: remove myself as maintainer

[Mikhail]

diff --git a/comms/hackrf/Makefile b/comms/hackrf/Makefile
index bc56ed6e6..5e3ecd660 100644
--- a/comms/hackrf/Makefile
+++ b/comms/hackrf/Makefile
@@ -10,8 +10,6 @@ CATEGORIES =  comms
 
 HOMEPAGE = https://greatscottgadgets.com/hackrf/
 
-MAINTAINER =   Mikhail 
-
 # GPLv2+ (tools), 3-clause BSD (library)
 PERMIT_PACKAGE =   Yes
 

Re: [new] devel/compiledb: compile_commands.json generator (also works with the kernel)

[Mikhail]

Up.

Tests pass.

On Fri, 3 May 2024 at 11:35, Mikhail Pchelin  wrote:

> I wasn't able to google how to generate compile_commands.json file for
> the kernel to make clangd/LSP/vim work.
>
> It looks like the most used tool is a bear
> (https://github.com/rizsotto/Bear), but during initial porting efforts I
> found out that it doesn't work, I got constant crashes and pinsyscalls
> messages in dmesg.
>
> compiledb is a much simpler python tool which parses gmake logs and
> generates compile_commands.json file, it also works fine with the
> OpenBSD kernel, which was the main motivation, I also tried jumping
> around emacs sources - works fine, using option 3 from the README.
>
> Fail of option 2 for emacs is documented in make.py file of the
> distribution, but I wasn't able to make the workaround fix it, given the
> option 3, which works, seems not a bid deal?
>
> Thoughts?
>
> $ pkg_info compiledb-0.10.1
> Information for inst:compiledb-0.10.1
>
> Comment:
> compile_commands.json generator
>
> Description:
> Tool for generating Clang's JSON Compilation Database file for GNU
> make-based
> build systems.
>
> Maintainer: The OpenBSD ports mailing-list 
>
> WWW: https://github.com/nickdiego/compiledb
>
> $ cat /usr/local/share/doc/pkg-readmes/compiledb
>
> +---
> | Running compiledb on OpenBSD
>
> +---
>
> compiledb supports only gmake for native compile_commands.json file
> generation,
> but you can try to feed usual make output to it through a pipe, or --parse
> option.
>
> Examples:
>
> 1) To make compile_commands.json file for OpenBSD kernel use:
>
> cd /sys/arch/$(machine)/compile/GENERIC.MP
> make -n | compiledb
> mv compile_commands.json /sys
>
> 2) To get compilation db for another software, which uses gmake pass -c
> option
> for make subcommand:
>
> cd ~/work/software
> compiledb -n make -c gmake
>
> 3) Above command runs 'gmake -Bnwk' and parses output, if your software
> uses
> autotools and enters endless ./configure stage, try removing -B switch and
> pipe
> the output without it:
>
> gmake -nwk | compiledb
>
>

Re: [maintainer update] sysutils/fzf 0.51.0

[Mikhail Pchelin]

On Wed, May 01, 2024 at 03:06:18PM +0200, Laurent Cheylus wrote:
> Hi,
> 
> a simple update for sysutils/fzf version 0.51.0
> Changelog: https://github.com/junegunn/fzf/releases/tag/0.51.0
> 
> - update Makefile and modules.inc for this version
> 
> Build and tests OK on current/amd64.
> 
> Please tests welcome and commit if OK.

built and tested on latest -current/amd64

zsh, vim and emacs integration works ok

[new] devel/compiledb: compile_commands.json generator (also works with the kernel)

[Mikhail Pchelin]

I wasn't able to google how to generate compile_commands.json file for
the kernel to make clangd/LSP/vim work.

It looks like the most used tool is a bear
(https://github.com/rizsotto/Bear), but during initial porting efforts I
found out that it doesn't work, I got constant crashes and pinsyscalls
messages in dmesg.

compiledb is a much simpler python tool which parses gmake logs and
generates compile_commands.json file, it also works fine with the
OpenBSD kernel, which was the main motivation, I also tried jumping
around emacs sources - works fine, using option 3 from the README.

Fail of option 2 for emacs is documented in make.py file of the
distribution, but I wasn't able to make the workaround fix it, given the
option 3, which works, seems not a bid deal?

Thoughts?

$ pkg_info compiledb-0.10.1
Information for inst:compiledb-0.10.1

Comment:
compile_commands.json generator

Description:
Tool for generating Clang's JSON Compilation Database file for GNU make-based
build systems.

Maintainer: The OpenBSD ports mailing-list 

WWW: https://github.com/nickdiego/compiledb

$ cat /usr/local/share/doc/pkg-readmes/compiledb
+---
| Running compiledb on OpenBSD
+---

compiledb supports only gmake for native compile_commands.json file generation,
but you can try to feed usual make output to it through a pipe, or --parse
option.

Examples:

1) To make compile_commands.json file for OpenBSD kernel use:

cd /sys/arch/$(machine)/compile/GENERIC.MP
make -n | compiledb
mv compile_commands.json /sys

2) To get compilation db for another software, which uses gmake pass -c option
for make subcommand:

cd ~/work/software
compiledb -n make -c gmake

3) Above command runs 'gmake -Bnwk' and parses output, if your software uses
autotools and enters endless ./configure stage, try removing -B switch and pipe
the output without it:

gmake -nwk | compiledb



compiledb.tgz
Description: application/gtar-compressed

[patch (kind of)] sysutils/gitlab-cli: terminal input doesn't work properly on OpenBSD

[Mikhail Pchelin]

[cc'ing maintainer]

Currently glab port doesn't properly handle terminal input, for example,
after 'glab auth login' (setup wizard) you won't be able to type
properly or choose the options, you will get ^[[B^[[A etc stuff.

This happens because survey library on which whole interface is based
still uses syscall.* interface, which was removed in OpenBSD.

The library (https://github.com/AlecAivazis/survey/) was abandoned by
the author:

> This project is no longer maintained. For an alternative, please check
> out: https://github.com/charmbracelet/bubbletea 

Inlined patch for this library fixes everything for me, but I must admit
that I've spent only couple hours with Go, and even if the patch looks
simple it can contain stupid mistakes, I'd be appreciated if someone
more proficient in Go can take a look at it (especially this 'unsafe'
stuff).

What would be the best way to bring the fix into the ports tree?

To understand what I'm talking about here is the steps for reproduction:

# build original gitlab-cli
cd /tmp
export GOPATH=/tmp/go
git clone https://gitlab.com/gitlab-org/cli
cd cli
gmake
./bin/glab auth login


reset
 
# clone the library with the patch
cd /tmp
git clone https://github.com/bsdmp/survey
 
# make go use patched library
cd /tmp/cli
go mod edit -replace github.com/AlecAivazis/survey/v2=/tmp/survey
gmake
./bin/glab auth login


diff --git a/go.mod b/go.mod
index 4837ce7..cc04509 100644
--- a/go.mod
+++ b/go.mod
@@ -10,6 +10,7 @@ require (
github.com/mattn/go-isatty v0.0.8
github.com/mgutz/ansi v0.0.0-20170206155736-9520e82c474b
github.com/stretchr/testify v1.6.1
+   golang.org/x/sys v0.0.0-20220722155257-8c9f86f7a55f
golang.org/x/term v0.0.0-20210927222741-03fcf44c2211
golang.org/x/text v0.4.0
 )
diff --git a/terminal/runereader_posix.go b/terminal/runereader_posix.go
index 563a081..4c1e88a 100644
--- a/terminal/runereader_posix.go
+++ b/terminal/runereader_posix.go
@@ -14,7 +14,7 @@ import (
"bytes"
"fmt"
"syscall"
-   "unsafe"
+   "golang.org/x/sys/unix"
 )
 
 const (
@@ -23,7 +23,7 @@ const (
 )
 
 type runeReaderState struct {
-   term   syscall.Termios
+   termunix.Termios
reader *bufio.Reader
buf*bytes.Buffer
 }
@@ -45,19 +45,20 @@ func (rr *RuneReader) Buffer() *bytes.Buffer {
 
 // For reading runes we just want to disable echo.
 func (rr *RuneReader) SetTermMode() error {
-   if _, _, err := syscall.Syscall6(syscall.SYS_IOCTL, 
uintptr(rr.stdio.In.Fd()), ioctlReadTermios, 
uintptr(unsafe.Pointer(&rr.state.term)), 0, 0, 0); err != 0 {
+   termios, err := unix.IoctlGetTermios((int)(rr.stdio.In.Fd()), 
ioctlReadTermios)
+   if err != nil {
return err
}
 
-   newState := rr.state.term
-   newState.Lflag &^= syscall.ECHO | syscall.ECHONL | syscall.ICANON | 
syscall.ISIG
+   rr.state.term = *termios
+   termios.Lflag &^= syscall.ECHO | syscall.ECHONL | syscall.ICANON | 
syscall.ISIG
// Because we are clearing canonical mode, we need to ensure VMIN & 
VTIME are
// set to the values we expect. This combination puts things in standard
// "blocking read" mode (see termios(3)).
-   newState.Cc[syscall.VMIN] = 1
-   newState.Cc[syscall.VTIME] = 0
+   termios.Cc[syscall.VMIN] = 1
+   termios.Cc[syscall.VTIME] = 0
 
-   if _, _, err := syscall.Syscall6(syscall.SYS_IOCTL, 
uintptr(rr.stdio.In.Fd()), ioctlWriteTermios, 
uintptr(unsafe.Pointer(&newState)), 0, 0, 0); err != 0 {
+   if err = unix.IoctlSetTermios((int)(rr.stdio.In.Fd()), 
ioctlWriteTermios, termios); err != nil {
return err
}
 
@@ -65,7 +66,7 @@ func (rr *RuneReader) SetTermMode() error {
 }
 
 func (rr *RuneReader) RestoreTermMode() error {
-   if _, _, err := syscall.Syscall6(syscall.SYS_IOCTL, 
uintptr(rr.stdio.In.Fd()), ioctlWriteTermios, 
uintptr(unsafe.Pointer(&rr.state.term)), 0, 0, 0); err != 0 {
+   if err := unix.IoctlSetTermios((int)(rr.stdio.In.Fd()), 
ioctlWriteTermios, &rr.state.term); err != nil {
return err
}
return nil

[crash] feh: illegal hardware instruction (core dumped)

[Mikhail]

core:~$ sysctl kern.version
kern.version=OpenBSD 7.5-beta (GENERIC.MP) #22: Fri Feb 23 19:29:07 MST 2024
dera...@amd64.openbsd.org:/usr/src/sys/arch/amd64/compile/GENERIC.MP

Latest packages.

core:~/Downloads$ feh openbsd\ \(1\).jpg
zsh: illegal hardware instruction (core dumped)  feh openbsd\ \(1\).jpg

core:~/Downloads$ egdb feh feh.core
GNU gdb (GDB) 9.2
Copyright (C) 2020 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later 
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law.
Type "show copying" and "show warranty" for details.
This GDB was configured as "x86_64-unknown-openbsd7.5".
Type "show configuration" for configuration details.
For bug reporting instructions, please see:
.
Find the GDB manual and other documentation resources online at:
.

For help, type "help".
Type "apropos word" to search for commands related to "word"...
Reading symbols from feh...
(No debugging symbols found in feh)
[New process 123074]
Core was generated by `feh'.
Program terminated with signal SIGILL, Illegal instruction.
#0  0x009c63a03e20 in jsimd_h2v2_merged_upsample_avx2 () from 
/usr/local/lib/libjpeg.so.70.2
(gdb) bt
#0  0x009c63a03e20 in jsimd_h2v2_merged_upsample_avx2 () from 
/usr/local/lib/libjpeg.so.70.2
#1  0x009c63a4b9e2 in merged_2v_upsample () from 
/usr/local/lib/libjpeg.so.70.2
#2  0x009c63a45124 in process_data_simple_main () from 
/usr/local/lib/libjpeg.so.70.2
#3  0x009c63a3e469 in jpeg_read_scanlines () from 
/usr/local/lib/libjpeg.so.70.2
#4  0x009c068f6596 in _load () from /usr/local/lib/imlib2/loaders/jpeg.so
#5  0x009b9eb9f0d3 in __imlib_LoadImage () from 
/usr/local/lib/libImlib2.so.9.0
#6  0x009b9eb86631 in imlib_load_image_with_error_return () from 
/usr/local/lib/libImlib2.so.9.0
#7  0x009985fc88d4 in feh_load_image ()
#8  0x009985fe20f1 in winwidget_create_from_file ()
#9  0x009985fda4c1 in init_slideshow_mode ()
#10 0x009985fd08f6 in main ()

Re: [update, add pledge/unveil] net/iperf3 3.14 -> 3.15

[Mikhail]

On Sat, Oct 21, 2023 at 08:57:33PM +0300, 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.

Ok, as always good thought comes last - openbsd users will use the port
version anyway...

Re: [update, add pledge/unveil] net/iperf3 3.14 -> 3.15

[Mikhail]

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: [update, add pledge/unveil] net/iperf3 3.14 -> 3.15

[Mikhail]

On Wed, Oct 18, 2023 at 10:28:47PM +0100, Stuart Henderson wrote:
> On 2023/10/18 22:19, Mikhail wrote:
> > [cc'ing maintainer]
> > 
> > Inlined patch updates iperf3 to 3.15 (3 bug fixes, details here -
> > https://github.com/esnet/iperf/releases/tag/3.15).
> > 
> > I run iperf on public server with unfirewalled ports, so I'd like it to
> > be pledged/unveiled, -I and --logfile options are working fine.
> > 
> > Probably we could drop privs more granularly, but for I'd like to keep
> > things simple.
> > 
> 
> Diff below for a few things I noticed. There may be others.

Here is a try to push this upstream:
https://github.com/esnet/iperf/pull/1586

Worth waiting a little bit for their comments.

[update, add pledge/unveil] net/iperf3 3.14 -> 3.15

[Mikhail]

[cc'ing maintainer]

Inlined patch updates iperf3 to 3.15 (3 bug fixes, details here -
https://github.com/esnet/iperf/releases/tag/3.15).

I run iperf on public server with unfirewalled ports, so I'd like it to
be pledged/unveiled, -I and --logfile options are working fine.

Probably we could drop privs more granularly, but for I'd like to keep
things simple.

diff refs/heads/master refs/heads/iperf3
commit - de754ab24f5686d70c44225d7fe12704063ff1de
commit + 5bdda7a75b52879eba6e0f671c5f3c95701254f7
blob - 1c29e29d94370a9345b58f34cdd29525f0fb9e53
blob + 1693ea4aab9e9051e306c4069736b501aa811193
--- net/iperf3/Makefile
+++ net/iperf3/Makefile
@@ -1,6 +1,6 @@
 COMMENT=   tool to measure maximum achievable bandwidth on IP networks
 
-V= 3.14
+V= 3.15
 PKGNAME=   iperf3-${V}
 DISTNAME=  iperf-${V}
 
@@ -15,6 +15,7 @@ MAINTAINER=   Lawrence Teo 
 # BSD 3-clause
 PERMIT_PACKAGE=Yes
 
+# uses pledge unveil
 WANTLIB += c m
 
 SITES= https://downloads.es.net/pub/iperf/
blob - aee4720c9e7a7c01d458ad75fa6ffacc4f3c5bcc
blob + 5e78d43fb08210550fb72de43ea73eb845202b01
--- net/iperf3/distinfo
+++ net/iperf3/distinfo
@@ -1,2 +1,2 @@
-SHA256 (iperf-3.14.tar.gz) = cj/MQwoCe8aVJij6KjrHdYSh0L0ygnXlc/ybIGwVUAQ=
-SIZE (iperf-3.14.tar.gz) = 647944
+SHA256 (iperf-3.15.tar.gz) = vbd8EfcrzpAhSIMVlXf6JEEgE+YrIIPPX1Q5HXmx2P8=
+SIZE (iperf-3.15.tar.gz) = 649330
blob - b14f7a1e19110d400b65c7d78c413e1d1136b36d
blob + ed586e35ac74ce8929882aac0e6c4c619fbebca9
--- net/iperf3/patches/patch-src_iperf_api_c
+++ net/iperf3/patches/patch-src_iperf_api_c
@@ -3,7 +3,7 @@ Default to IPv4.
 Index: src/iperf_api.c
 --- src/iperf_api.c.orig
 +++ src/iperf_api.c
-@@ -2860,7 +2860,7 @@ iperf_defaults(struct iperf_test *testp)
+@@ -2884,7 +2884,7 @@ iperf_defaults(struct iperf_test *testp)
  testp->stats_interval = testp->reporter_interval = 1;
  testp->num_streams = 1;
  
blob - /dev/null
blob + 0596ef57b03120c490a2cac6fafbd8e529f03807 (mode 644)
--- /dev/null
+++ net/iperf3/patches/patch-src_main_c
@@ -0,0 +1,65 @@
+Add pledge and unveil
+
+Index: src/main.c
+--- src/main.c.orig
 src/main.c
+@@ -59,6 +59,18 @@ main(int argc, char **argv)
+ {
+ struct iperf_test *test;
+ 
++#if defined(__OpenBSD__)
++if (pledge("stdio tmppath rpath cpath wpath inet unveil", NULL) == -1) {
++  fprintf(stderr, "pledge: %s\n", strerror(errno));
++  exit(1);
++}
++
++if (unveil("/dev/urandom", "r") == -1) {
++  fprintf(stderr, "unveil urandom: %s\n", strerror(errno));
++  exit(1);
++}
++#endif
++
+ // XXX: Setting the process affinity requires root on most systems.
+ //  Is this a feature we really need?
+ #ifdef TEST_PROC_AFFINITY
+@@ -104,6 +116,40 @@ main(int argc, char **argv)
+ usage();
+ exit(1);
+ }
++
++#if defined(__OpenBSD__)
++int needwr = 0;
++
++/* Check for the features which require wpath and cpath */
++if (test->pidfile) {
++  if (unveil(test->pidfile, "cw") == -1) {
++  fprintf(stderr, "uneveil pidfile: %s\n", strerror(errno));
++  exit(1);
++  } else
++  needwr = 1;
++}
++
++if (test->logfile) {
++  if (unveil(test->logfile, "cwr") == -1) {
++  fprintf(stderr, "uneveil logfile: %s\n", strerror(errno));
++  exit(1);
++  } else
++ needwr = 1;
++}
++
++/* Drop wpath and cpath if we can */
++if (needwr == 0) {
++  if (pledge("stdio tmppath rpath inet unveil", NULL) == -1) {
++  fprintf(stderr, "pledge needwr: %s\n", strerror(errno));
++  exit(1);
++  }
++}
++
++if (unveil(NULL, NULL) == -1) {
++  fprintf(stderr, "unveil NULL: %s\n", strerror(errno));
++  exit(1);
++}
++#endif
+ 
+ if (run(test) < 0)
+ iperf_errexit(test, "error - %s", iperf_strerror(i_errno));

Re: sysutils/rofi sometimes coredumps in __vfprintf (+ similar crash in fvwm3)

[Mikhail]

On Sat, Sep 30, 2023 at 11:00:10AM +0200, Omar Polo wrote:
> I managed to reproduce it.  It doesn't seem to fail with CWM, so I run
> fvwm3 inside Xephyr.
> 
> The issue seems to be in source/xcb.c:
> 
> (gdb) p wtitle.strings
> $2 = 0xf9d9ce2ce30 "FVWM", '\004' , '\337'  times>, ...
> 
> wtitle.strings is not NUL terminated, so it later crashes in strlen
> (via __vfprintf) after it goes out of the bounds.
> 
> This seems to fix it, but I'm not knowledgable enough to tell whether
> this is a FVWM3 issue.  (i assume so tho since it's intermittent.)
> 
> Can you give this diff a spin?  I don't use nor rofi anymore nor
> fvwm3.

No crash in 100 iterations, thanks for the fix.

sysutils/rofi sometimes coredumps in __vfprintf (+ similar crash in fvwm3)

[Mikhail]

[cc'ing maintainer]

kern.version=OpenBSD 7.4 (GENERIC.MP) #1382: Wed Sep 27 10:51:31 MDT 2023
dera...@amd64.openbsd.org:/usr/src/sys/arch/amd64/compile/GENERIC.MP

$ rofi -show combi -modes combi -combi-modes "window,ssh,run" -terminal sterm
$ rofi -show combi -modes combi -combi-modes "window,ssh,run" -terminal sterm
$ rofi -show combi -modes combi -combi-modes "window,ssh,run" -terminal sterm
$ rofi -show combi -modes combi -combi-modes "window,ssh,run" -terminal sterm
$ rofi -show combi -modes combi -combi-modes "window,ssh,run" -terminal sterm
$ rofi -show combi -modes combi -combi-modes "window,ssh,run" -terminal sterm
$ rofi -show combi -modes combi -combi-modes "window,ssh,run" -terminal sterm
Segmentation fault (core dumped)
$ rofi -show combi -modes combi -combi-modes "window,ssh,run" -terminal sterm
$ rofi -show combi -modes combi -combi-modes "window,ssh,run" -terminal sterm
$ rofi -show combi -modes combi -combi-modes "window,ssh,run" -terminal sterm
$ rofi -show combi -modes combi -combi-modes "window,ssh,run" -terminal sterm
$ rofi -show combi -modes combi -combi-modes "window,ssh,run" -terminal sterm
Segmentation fault (core dumped)
$ rofi -show combi -modes combi -combi-modes "window,ssh,run" -terminal sterm
Segmentation fault (core dumped)
$ rofi -show combi -modes combi -combi-modes "window,ssh,run" -terminal sterm
$ rofi -show combi -modes combi -combi-modes "window,ssh,run" -terminal sterm
$ rofi -show combi -modes combi -combi-modes "window,ssh,run" -terminal sterm
$ rofi -show combi -modes combi -combi-modes "window,ssh,run" -terminal sterm
$ rofi -show combi -modes combi -combi-modes "window,ssh,run" -terminal sterm
Segmentation fault (core dumped)

Core was generated by `rofi'.
Program terminated with signal SIGSEGV, Segmentation fault.
#0  strlen () at /usr/src/lib/libc/arch/amd64/string/strlen.S:125
125 movq(%rax),%rdx /* get bytes to check */
(gdb) bt
#0  strlen () at /usr/src/lib/libc/arch/amd64/string/strlen.S:125
#1  0x0c011b001558 in __vfprintf (fp=, fmt0=, 
ap=) at /usr/src/lib/libc/stdio/vfprintf.c:877
#2  0x0c011affa5a5 in _libc_vasprintf (str=0x76d393e72e40, 
fmt=0xbfe638afa35 "Found window manager: |%s|", ap=0x76d393e73030) at 
/usr/src/lib/libc/stdio/vasprintf.c:43
#3  0x0c010a1f0ac7 in g_vasprintf () from 
/usr/local/lib/libglib-2.0.so.4201.10
#4  0x0c010a1b512d in g_strdup_vprintf () from 
/usr/local/lib/libglib-2.0.so.4201.10
#5  0x0c010a197b3b in g_logv () from /usr/local/lib/libglib-2.0.so.4201.10
#6  0x0c010a197a55 in g_log () from /usr/local/lib/libglib-2.0.so.4201.10
#7  0x0bfe638f8a5e in display_setup ()
#8  0x0bfe638d8c8f in main ()

I also built rofi from git, same there, but less often:

~/work/rofi/build$ ./rofi -show combi -modes combi -combi-modes 
"window,ssh,run" -terminal sterm
~/work/rofi/build$ ./rofi -show combi -modes combi -combi-modes 
"window,ssh,run" -terminal sterm
~/work/rofi/build$ ./rofi -show combi -modes combi -combi-modes 
"window,ssh,run" -terminal sterm
~/work/rofi/build$ ./rofi -show combi -modes combi -combi-modes 
"window,ssh,run" -terminal sterm
~/work/rofi/build$ ./rofi -show combi -modes combi -combi-modes 
"window,ssh,run" -terminal sterm
~/work/rofi/build$ ./rofi -show combi -modes combi -combi-modes 
"window,ssh,run" -terminal sterm
~/work/rofi/build$ ./rofi -show combi -modes combi -combi-modes 
"window,ssh,run" -terminal sterm
~/work/rofi/build$ ./rofi -show combi -modes combi -combi-modes 
"window,ssh,run" -terminal sterm
~/work/rofi/build$ ./rofi -show combi -modes combi -combi-modes 
"window,ssh,run" -terminal sterm
~/work/rofi/build$ ./rofi -show combi -modes combi -combi-modes 
"window,ssh,run" -terminal sterm
~/work/rofi/build$ ./rofi -show combi -modes combi -combi-modes 
"window,ssh,run" -terminal sterm
~/work/rofi/build$ ./rofi -show combi -modes combi -combi-modes 
"window,ssh,run" -terminal sterm
~/work/rofi/build$ ./rofi -show combi -modes combi -combi-modes 
"window,ssh,run" -terminal sterm
~/work/rofi/build$ ./rofi -show combi -modes combi -combi-modes 
"window,ssh,run" -terminal sterm
~/work/rofi/build$ ./rofi -show combi -modes combi -combi-modes 
"window,ssh,run" -terminal sterm
~/work/rofi/build$ ./rofi -show combi -modes combi -combi-modes 
"window,ssh,run" -terminal sterm
~/work/rofi/build$ ./rofi -show combi -modes combi -combi-modes 
"window,ssh,run" -terminal sterm
~/work/rofi/build$ ./rofi -show combi -modes combi -combi-modes 
"window,ssh,run" -terminal sterm
~/work/rofi/build$ ./rofi -show combi -modes combi -combi-modes 
"window,ssh,run" -terminal sterm
~/work/rofi/build$ ./rofi -show combi -modes combi -combi-modes 
"window,ssh,run" -terminal sterm
~/work/rofi/build$ ./rofi -show combi -modes combi -combi-modes 
"window,ssh,run" -terminal sterm
~/work/rofi/build$ ./rofi -show combi -modes combi -combi-modes 
"window,ssh,run" -terminal sterm
~/work/rofi/build$ ./rofi -show combi -modes combi -combi-modes 
"window,ssh,run" -terminal st

Re: [new] misc/vim-fzf

[Mikhail Pchelin]

On Mon, Sep 25, 2023 at 11:42:53AM +0100, Stuart Henderson wrote:
> Not sure I really want to go down the route of adding packages for vim
> plugins to OpenBSD ports, there are so many, and I think most
> people
> making much use of plugins will already be using a manager so I don't
> see much benefit to having them in packages (and there are some
> downsides).

https://cvsweb.openbsd.org/ports/devel/vim-taglist/ was the reason for
the port, but I understand your arguments, I drop the tar.

[new] misc/vim-fzf

[Mikhail Pchelin]

I find this plugin very useful, especially :Buffers and :Files commands,
I propose to add it as a port for easier installation.

Information for inst:vim-fzf-0.0.20230917

Comment:
vim plugin for sysutils/fzf

Description:
Plugin for integrating vim with sysutils/fzf, with some useful bindings.

Maintainer: Mikhail Pchelin 

WWW: https://github.com/junegunn/fzf.vim


vim-fzf.tgz
Description: application/gtar-compressed

Re: emacs and textroc/tree-sitter: drop tree-sittter cli program?

[Mikhail]

On Wed, Aug 02, 2023 at 08:49:10PM +0200, Jeremie Courreges-Anglas wrote:
> 
> So emacs-29.1 introduced a tree-sitter backend to parse source code,
> instead of the traditional bag of ugly regexes.  I'd like to add
> tree-sitter as a dep to the emacs port but the non-optional rust
> dependency is in the way.  rust isn't supported on all architectures but
> emacs--no_x11 should be available everywhere.  I initially went with
> a PFRAG.rust, but thinking about it some more, I don't want people to
> yell at me when they spot rust on the build dep list of emacs--no_x11. ;)
> 
> Upstream says that "tree-sitter aims to be dependency-free so that the
> runtime library (which is written in pure C) can be embedded in any
> application.
> 
> I propose to zap the rust build-dependency. Paco, you did the inital
> import.  Do you still care about shipping this tree-sitter program?
> Edd, the only consumer of tree-sitter so far is neovim, which seems to
> build/package without the tree-sitter cli program being available.
> runtime/doc/treesitter.txt doesn't mention a requirement on the cli
> tool.  Maybe you'll want to check again?
> 
> If people actually use and need the tree-sitter program, we can create
> an additional tree-sitter-cli port (and maybe move the library to a
> textproc/tree-sitter/tree-sitter subdirectory, etc).
> 
> ok?

> -
> -.include "crates.inc"
> -

crates.inc is removed from Makefile, but not rm'ed from the port dir -
is it intentional?

> -SEPARATE_BUILD = Yes

Mostly for educational purposes -
https://www.openbsd.org/faq/ports/guide.html
point 13 says "Try setting SEPARATE_BUILD" - is there a reason to remove
it?

[security] net/iperf3 update from 3.13 to 3.14

[Mikhail]

This update fixes server and client crash if connected to malicious
process, details are here:

https://downloads.es.net/pub/iperf/esnet-secadv-2023-0001.txt.asc

Full changelog is here:

https://github.com/esnet/iperf/blob/master/RELNOTES.md

Tested on amd64.

diff /home/build/usr/ports
commit - f7b4d3d8f3ae0f3c4ba5a7e9def772c58999d69d
path + /home/build/usr/ports
blob - 201e85786e6b826e37e68fa5d40f65f2854b7ad1
file + net/iperf3/Makefile
--- net/iperf3/Makefile
+++ net/iperf3/Makefile
@@ -1,6 +1,6 @@
 COMMENT=   tool to measure maximum achievable bandwidth on IP networks
 
-V= 3.13
+V= 3.14
 PKGNAME=   iperf3-${V}
 DISTNAME=  iperf-${V}
 
blob - 0bb87a47de19c18109e5f7b38363da3ea3ff6cfb
file + net/iperf3/distinfo
--- net/iperf3/distinfo
+++ net/iperf3/distinfo
@@ -1,2 +1,2 @@
-SHA256 (iperf-3.13.tar.gz) = vuQnrrE9ai7iIHPyMmH2NxLYK++qg6yMtNtdpMK9yGU=
-SIZE (iperf-3.13.tar.gz) = 646508
+SHA256 (iperf-3.14.tar.gz) = cj/MQwoCe8aVJij6KjrHdYSh0L0ygnXlc/ybIGwVUAQ=
+SIZE (iperf-3.14.tar.gz) = 647944
blob - 83a4e07d0e88ab3fd3b7e88870fe1fd0e6aa8bfe
file + net/iperf3/patches/patch-src_iperf_api_c
--- net/iperf3/patches/patch-src_iperf_api_c
+++ net/iperf3/patches/patch-src_iperf_api_c
@@ -3,7 +3,7 @@ Index: src/iperf_api.c
 Index: src/iperf_api.c
 --- src/iperf_api.c.orig
 +++ src/iperf_api.c
-@@ -2813,7 +2813,7 @@ iperf_defaults(struct iperf_test *testp)
+@@ -2860,7 +2860,7 @@ iperf_defaults(struct iperf_test *testp)
  testp->stats_interval = testp->reporter_interval = 1;
  testp->num_streams = 1;
  

Re: [new] security/paperkey

[Mikhail]

On Sat, Mar 04, 2023 at 09:10:46AM +0100, Omar Polo wrote:
> Still ok op@ to import.  

Last ping, last hope...

Information for inst:paperkey-1.6

Comment:
OpenPGP private key backup utility suitable for printing

Description:
Due to metadata and redundancy, OpenPGP secret keys are significantly larger
than just the "secret bits". The secret key contains a complete copy of the
public key. Since the public key generally doesn't need to be escrowed, only
archiving the secret parts can be a real advantage.

Paperkey extracts just those secret bytes and prints them. To reconstruct, you
re-enter those bytes (whether by hand, OCR, QR code, or the like) and paperkey
can use them to transform your existing public key into a secret key.

Maintainer: The OpenBSD ports mailing-list 

WWW: https://www.jabberwocky.com/software/paperkey/


paperkey.tgz
Description: application/tar-gz

Re: [new] security/paperkey

[Mikhail]

On Thu, Mar 16, 2023 at 03:42:51PM +, Stuart Henderson wrote:
> Imports are on hold until we're done with release.
> 
> -- 
>  Sent from a phone, apologies for poor formatting.
> 
> On 16 March 2023 14:45:04 Mikhail  wrote:
> 
> > On Sat, Mar 04, 2023 at 09:10:46AM +0100, Omar Polo wrote:
> > > On 2023/03/04 09:00:25 +0300, Mikhail  wrote:
> > > > On Fri, Mar 03, 2023 at 10:11:01PM +0100, Omar Polo wrote:
> > > > > Otherwise it looks good to me; ok op@ to import it
> > > >
> > > > Thanks for the review, next attempt attached.
> > > 
> > > Still ok op@ to import.  The license marker needs a "+", but no need
> > > to send an updated tarball.
> > 
> > Ping.

Ping.

Re: [new] security/paperkey

[Mikhail]

On Sat, Mar 04, 2023 at 09:10:46AM +0100, Omar Polo wrote:
> On 2023/03/04 09:00:25 +0300, Mikhail  wrote:
> > On Fri, Mar 03, 2023 at 10:11:01PM +0100, Omar Polo wrote:
> > > Otherwise it looks good to me; ok op@ to import it
> > 
> > Thanks for the review, next attempt attached.
> 
> Still ok op@ to import.  The license marker needs a "+", but no need
> to send an updated tarball.

Ping.

Re: [new] security/paperkey

[Mikhail]

On Fri, Mar 03, 2023 at 10:11:01PM +0100, Omar Polo wrote:
> few nits on the Makefile:
> 
>  - please use https:// for the HOMEPAGE
Done

>  - it's actually GPLv2+ (not *that* important)

I got GPLv2 from COPYING, I searched for word 'later', but no matches
which are significant. Where do you see that it's 'gplv2 or later'?

>  - I'd avoid setting SEPARATE_BUILD for autotools, it doesn't gain
>anything really.
Done (got this hint from https://www.openbsd.org/faq/ports/guide.html)

> less important, but I'd also reword the COMMENT to something along the
> lines of "OpenPGP private key backup utility suitable for printing".
Done

> Otherwise it looks good to me; ok op@ to import it

Thanks for the review, next attempt attached.



paperkey.tgz
Description: application/tar-gz

[new] security/paperkey

[Mikhail]

This port makes suitable for printing backups of gnupg private keys, the
format of the default backup file is:

  1: 00 04 14 7A 2E F2 2E 5C CA 00 F5 C4 D9 3C A9 83 EF F8 7C 2A 54 4B ADF25B
  2: 03 CB 00 0B FF 51 E2 FE 8B 9B 51 EC BA E5 02 7D A2 FB 55 DC C0 63 0EB985
  3: 7C AE 4E 44 B9 82 0A 46 23 8F E0 87 A1 FC C9 62 9D 6D FA 07 53 11 41FCBB
  4: 7B 11 DC 9B 13 EB CD C2 15 1A 11 0A 69 72 71 0B 2C 75 6B 48 74 C4 12D73F
  [...]

It's bytes with CRC at the end, a person can OCR it or ask the
program for raw ouput, which (as the homepage says) can be feed to QR
generation.

Comparing to printing and OCR'ing armored private keys from gpg I see
CRC checksums as advantage, with which the software can give you useful
hints like this:

CRC on line 1 does not match (AA!=BB)

Comment:
gpg private key backups, suitable for printing

Description:
Due to metadata and redundancy, OpenPGP secret keys are significantly larger
than just the "secret bits". The secret key contains a complete copy of the
public key. Since the public key generally doesn't need to be escrowed, only
archiving the secret parts can be a real advantage.

Paperkey extracts just those secret bytes and prints them. To reconstruct, you
re-enter those bytes (whether by hand, OCR, QR code, or the like) and paperkey
can use them to transform your existing public key into a secret key.

Maintainer: The OpenBSD ports mailing-list 

WWW: http://www.jabberwocky.com/software/paperkey/


paperkey.tgz
Description: application/tar-gz

Re: GNS3 port

[Mikhail]

On Tue, Feb 07, 2023 at 10:48:09PM +0300, Mikhail wrote:
> 
> I'd like to port GNS3 (GUI for dynamips [Cisco hardware emulator]; dynamips
> only mode for now, fancy QEMU things are untested) to OpenBSD, it requires one
> port updates (emulators/dynamips) and two new ports as a dependencies
> (devel/py-aiofiles and www/py-aiohttp-cors), not counting GNS3 suite itself,
> which consists of gns3-server, gns3-gui, ubridge and vpcs.
> 
> I plan to separate this to three steps in hope that it will be easier for
> committers to review the patches and new ports:
> 
> - update for emulators/dynamips
> 
> - new port for devel/py-aiofiles
> - new port for www/py-aiohttp-cors
> 
> - new ports for the gns3 suite (gns3-server, gns3-gui, ubridge, vpcs)
> 
> Link to the whole patch: https://freebsd.org/~misha/gns3.patch
> 
> Testing and comments are appreciated.

Ping (in hope interested parties use threaded view)

Re: GNS3 port [new port net/gns3-server]

[Mikhail]

$ pkg_info gns3-server
Information for inst:gns3-server-2.2.37

Comment:
GNS3 server

Description:
The GNS3 server manages emulators such as Dynamips, VirtualBox or
Qemu/KVM.
Clients like the GNS3 GUI and the GNS3 Web UI control the server using
an HTTP
REST API.

Maintainer: The OpenBSD ports mailing-list 

WWW: https://github.com/GNS3/gns3-server


gns3-server.tgz
Description: application/tar-gz

Re: GNS3 port [new port net/gns3-gui]

[Mikhail]

$ pkg_info gns3-gui
Information for inst:gns3-gui-2.2.37

Comment:
GNS3 GUI

Description:
GNS3 GUI

Maintainer: The OpenBSD ports mailing-list 

WWW: https://github.com/GNS3/gns3-gui


gns3-gui.tgz
Description: application/tar-gz

Re: GNS3 port [new port net/ubridge]

[Mikhail]

$ pkg_info ubridge
Information for inst:ubridge-0.9.18

Comment:
bridge for UDP tunnels, Ethernet, TAP and VMnet interfaces

Description:
uBridge is a simple application to create user-land bridges between various
technologies. Currently, bridging between UDP tunnels, Ethernet and TAP
interfaces is supported. Packet capture is also supported.

Maintainer: The OpenBSD ports mailing-list 

WWW: https://github.com/GNS3/ubridge



ubridge.tgz
Description: application/tar-gz

Re: GNS3 port [new port net/vpcs]

[Mikhail]

Patches were upstreamed.

$ pkg_info vpcs
Information for inst:vpcs-0.8.2

Comment:
simple Virtual PC Simulator

Description:
This is a continuation of VPCS, based on the last development version and
improved with patches wrote by various people from the community. The original
VPCS code, which is unfortunately not maintained anymore, can be viewed on
https://sourceforge.net/p/vpcs/code/

Maintainer: The OpenBSD ports mailing-list 

WWW: https://github.com/GNS3/vpcs



vpcs.tgz
Description: application/tar-gz

Re: GNS3 port [new port www/py-aiohttp-cors]

[Mikhail]

Needed by gns3-server, fixes from sthen@ were taken into account.

Tests are passed.

$ pkg_info  py3-aiohttp-cors
Information for inst:py3-aiohttp-cors-0.7.0

Comment:
CORS support for aiohttp

Description:
aiohttp_cors library implements Cross Origin Resource Sharing (CORS) support
for aiohttp asyncio-powered asynchronous HTTP server

Maintainer: The OpenBSD ports mailing-list 

WWW: https://pypi.python.org/pypi/aiohttp-cors



py-aiohttp-cors.tgz
Description: application/tar-gz

Re: GNS3 port [new port devel/py-aiofiles]

[Mikhail]

Needed by gns3-server, fixes from sthen@ were taken into account.

$ pkg_info py3-aiofiles
Information for inst:py3-aiofiles-22.1.0

Comment:
handling local disk files in asyncio applications

Description:
aiofiles is an Apache2 licensed library, written in Python, for handling local
disk files in asyncio applications.

Ordinary local file IO is blocking, and cannot easily and portably made
asynchronous. This means doing file IO may interfere with asyncio applications,
which shouldn't block the executing thread. aiofiles helps with this by
introducing asynchronous versions of files that support delegating operations
to a separate thread pool.

Maintainer: The OpenBSD ports mailing-list 

WWW: https://pypi.python.org/pypi/aiofiles


py-aiofiles.tgz
Description: application/tar-gz

Re: GNS3 port [dynamips update]

[Mikhail]

Update to the latest version and update for the patches, tested only on
amd64.

emulators/dynagen (depends on python2.7) briefly tested

diff refs/heads/master refs/heads/gns3
commit - 37e0f4d6fac927ffe838b99ae6a1cd263e2d1b09
commit + dcaa6820e1d4cc6fecd85dcf2ec9dc05450ca695
blob - 3b1bdf0941e37e307178c1c617e2c0ebadcf4e19
blob + be5fa7166f110294be29bef9cc3797d66dd13864
--- emulators/dynamips/Makefile
+++ emulators/dynamips/Makefile
@@ -2,13 +2,13 @@ DISTNAME= dynamips-0.2.8-RC2
 
 USE_WXNEEDED=  Yes
 
-DISTNAME=  dynamips-0.2.8-RC2
-PKGNAME=   ${DISTNAME:S/-RC/rc/}
-REVISION=  9
+GH_ACCOUNT=GNS3
+GH_PROJECT=dynamips
+GH_TAGNAME=v0.2.23
+
 CATEGORIES=emulators
 
 HOMEPAGE=  http://www.gns3.net/dynamips/
-MASTER_SITES=  ${MASTER_SITE_SOURCEFORGE:=gns-3/}
 
 # GPL
 PERMIT_PACKAGE=Yes
@@ -16,8 +16,8 @@ MAKE_ENV= DYNAMIPS_ARCH=${DYNAMIPS_ARCH}
 WANTLIB=   c elf>=2 pcap pthread
 
 MAKE_ENV=  DYNAMIPS_ARCH=${DYNAMIPS_ARCH}
+MODULES=   devel/cmake
 
-USE_GMAKE= Yes
 NO_TEST=   Yes
 
 .if ${MACHINE_ARCH} == "i386"
@@ -28,9 +28,11 @@ post-install:
 DYNAMIPS_ARCH= "nojit"
 .endif
 
+CONFIGURE_ARGS += -DDYNAMIPS_ARCH=${DYNAMIPS_ARCH}
+
 post-install:
${INSTALL_DATA_DIR} ${PREFIX}/share/doc/dynamips
-.for i in ChangeLog README README.hypervisor TODO
+.for i in ChangeLog README.md README.hypervisor TODO
${INSTALL_DATA} ${WRKSRC}/$i ${PREFIX}/share/doc/dynamips
 .endfor
 
blob - d3ccc77190bfc33262364943d97662c531d0c859
blob + b2913e7fd7237e89c613fd570c20eb5b5d977116
--- emulators/dynamips/distinfo
+++ emulators/dynamips/distinfo
@@ -1,2 +1,2 @@
-SHA256 (dynamips-0.2.8-RC2.tar.gz) = 
qLN3zmMRGeKFxAH9t8tNC8xgChVQi9/88zdUaVfiUt4=
-SIZE (dynamips-0.2.8-RC2.tar.gz) = 578935
+SHA256 (dynamips-0.2.23.tar.gz) = UDu7UsA/kZAOqNvovQuAS3bi4o0LckJiTg08Ut2kQaE=
+SIZE (dynamips-0.2.23.tar.gz) = 835736
blob - c0d41858e45dac99b393fc209a3048b14ed64a58 (mode 644)
blob + /dev/null
--- emulators/dynamips/patches/patch-Makefile
+++ /dev/null
@@ -1,116 +0,0 @@
-Index: Makefile
 Makefile.orig
-+++ Makefile
-@@ -35,8 +35,8 @@ LEX=flex
- MIPS64_ARCH_INC_FILE=\"mips64_$(DYNAMIPS_ARCH)_trans.h\"
- PPC32_ARCH_INC_FILE=\"ppc32_$(DYNAMIPS_ARCH)_trans.h\"
- 
--CFLAGS+=-g -Wall -O3 -fomit-frame-pointer \
--  -DJIT_ARCH=\"$(DYNAMIPS_ARCH)\" -DJIT_CPU=CPU_$(DYNAMIPS_ARCH) \
-+CFLAGS?=-g -O3 -fomit-frame-pointer
-+CFLAGS+=-Wall -DJIT_ARCH=\"$(DYNAMIPS_ARCH)\" -DJIT_CPU=CPU_$(DYNAMIPS_ARCH) \
-   -DMIPS64_ARCH_INC_FILE=$(MIPS64_ARCH_INC_FILE) \
-   -DPPC32_ARCH_INC_FILE=$(PPC32_ARCH_INC_FILE) \
-   -DDYNAMIPS_VERSION=\"$(VERSION)\" \
-@@ -47,6 +47,12 @@ CFLAGS+=-g -Wall -O3 -fomit-frame-pointer \
- #PCAP_LIB=/usr/local/lib/libpcap.a
- PCAP_LIB=-lpcap
- 
-+ifeq ($(shell uname), OpenBSD)
-+   PTHREAD_LIBS?=-pthread
-+   PCAP_LIB=-lpcap
-+   CFLAGS+=$(PTHREAD_CFLAGS)
-+   LIBS=-L. -lelf $(PTHREAD_LIBS)
-+else
- ifeq ($(shell uname), FreeBSD)
-PTHREAD_LIBS?=-pthread
-LOCALBASE?=/usr/local
-@@ -85,6 +91,7 @@ endif
- endif
- endif
- endif
-+endif
- 
- PROG=dynamips$(BIN_EXT)
- PACKAGE=$(PROG)-$(VERSION)
-@@ -217,20 +224,20 @@ all: $(PROG) nvram_export
- 
- $(PROG): mips64_microcode_dump.inc ppc32_microcode_dump.inc \
-   $(LEX_C) $(C_OBJS) $(A_OBJS)
--  @echo "Linking $@"
--  @$(CC) -o $@ $(C_OBJS) $(A_OBJS) $(LIBS)
-+  @#echo "Linking $@"
-+  $(CC) -o $@ $(C_OBJS) $(A_OBJS) $(LIBS)
- 
- udp_send$(BIN_EXT): udp_send.c net.c crc.c
--  @echo "Linking $@"
--  @$(CC) -Wall $(CFLAGS) -o $@ udp_send.c net.c crc.c $(LIBS)
-+  @#echo "Linking $@"
-+  $(CC) -Wall $(CFLAGS) -o $@ udp_send.c net.c crc.c $(LIBS)
- 
- udp_recv$(BIN_EXT): udp_recv.c net.c crc.c
--  @echo "Linking $@"
--  @$(CC) -Wall $(CFLAGS) -o $@ udp_recv.c net.c crc.c $(LIBS)
-+  @#echo "Linking $@"
-+  $(CC) -Wall $(CFLAGS) -o $@ udp_recv.c net.c crc.c $(LIBS)
- 
- rom2c$(BIN_EXT): rom2c.c
--  @echo "Linking $@"
--  @$(CC) -Wall $(CFLAGS) -o $@ rom2c.c $(LIBS)
-+  @#echo "Linking $@"
-+  $(CC) -Wall $(CFLAGS) -o $@ rom2c.c $(LIBS)
- 
- mips64_microcode_dump.inc: rom2c$(BIN_EXT) mips64_microcode
-   @./rom2c mips64_microcode mips64_microcode_dump.inc 0xbfc0
-@@ -239,24 +246,24 @@ ppc32_microcode_dump.inc: rom2c$(BIN_EXT) ppc32_microc
-   @./rom2c ppc32_microcode ppc32_microcode_dump.inc 0xfff0
- 
- asmdefs$(BIN_EXT): asmdefs.c mips64.h
--  @echo "Linking $@"
--  @$(CC) -Wall $(CFLAGS) -o $@ asmdefs.c
-+  @#echo "Linking $@"
-+  $(CC) -Wall $(CFLAGS) -o $@ asmdefs.c
- 
- asmdefs.h: asmdefs$(BIN_EXT)
--  @echo "Building assembly definitions header file"
-+  @#echo "Building assembly definitions header file"
-   @./asmdefs
- 
- nvram_export$(BIN_EXT): nvram_export.c
--  @echo "Linking $@"
--  @$(CC) -Wall $(CFLAGS) -o $@ nvram_export.c
-+  @#ec

GNS3 port

[Mikhail]

I'd like to port GNS3 (GUI for dynamips [Cisco hardware emulator]; dynamips
only mode for now, fancy QEMU things are untested) to OpenBSD, it requires one
port updates (emulators/dynamips) and two new ports as a dependencies
(devel/py-aiofiles and www/py-aiohttp-cors), not counting GNS3 suite itself,
which consists of gns3-server, gns3-gui, ubridge and vpcs.

I plan to separate this to three steps in hope that it will be easier for
committers to review the patches and new ports:

- update for emulators/dynamips

- new port for devel/py-aiofiles
- new port for www/py-aiohttp-cors

- new ports for the gns3 suite (gns3-server, gns3-gui, ubridge, vpcs)

Link to the whole patch: https://freebsd.org/~misha/gns3.patch

Testing and comments are appreciated.

[update] games/fheroes2 0.9.18 -> 0.9.21

[Mikhail]

[ cc'ing maintainer ]

Inlined patch updates fheroes2 game - builds and runs fine on
current/amd64 with resources from demo version.

The patch also adds audio/timidity as RUN_DEPENDS, with it you're able
to hear game music.

patch-Makefile should be rm'ed

diff /usr/ports
commit - f2ea66a16674d866fb6e818ad75e4e519e7728bd
path + /usr/ports
blob - 6780219353dc8ec58ea40a74dd41b6a1fa0cdbbb
file + games/fheroes2/Makefile
--- games/fheroes2/Makefile
+++ games/fheroes2/Makefile
@@ -2,7 +2,7 @@ GH_TAGNAME =0.9.18
 
 GH_ACCOUNT =   ihhub
 GH_PROJECT =   fheroes2
-GH_TAGNAME =   0.9.18
+GH_TAGNAME =   0.9.21
 CATEGORIES =   games
 HOMEPAGE = https://ihhub.github.io/fheroes2/
 MAINTAINER =   Thomas Frohwein 
@@ -18,6 +18,7 @@ MAKE_FLAGS += FHEROES2_DATA=${PREFIX}/share/fheroes2
 BUILD_DEPENDS =devel/gettext,-tools \
textproc/gsed
 LIB_DEPENDS =  devel/sdl2-mixer
+RUN_DEPENDS =  audio/timidity
 MAKE_FLAGS +=  FHEROES2_DATA=${PREFIX}/share/fheroes2
 USE_GMAKE =Yes
 NO_TEST =  Yes
blob - 153a2f4b460f919a7e8f4f07c81dc4db522edcfb
file + games/fheroes2/distinfo
--- games/fheroes2/distinfo
+++ games/fheroes2/distinfo
@@ -1,2 +1,2 @@
-SHA256 (fheroes2-0.9.18.tar.gz) = vNmvznuGljD5fP23E2aPD33M9p/Gsx2xynSsL2NSSo0=
-SIZE (fheroes2-0.9.18.tar.gz) = 5117381
+SHA256 (fheroes2-0.9.21.tar.gz) = hj54zSObV3BolXhD1ZJvzPcsi/0FMVIswkIEDzEINBw=
+SIZE (fheroes2-0.9.21.tar.gz) = 10914492
blob - 70ac159dc9ca898a41c69d6c49adbcd9934d8799
file + /dev/null
--- games/fheroes2/patches/patch-Makefile
+++ /dev/null
@@ -1,13 +0,0 @@
-also build translation files (*.mo)
-
-Index: Makefile
 Makefile.orig
-+++ Makefile
-@@ -37,6 +37,7 @@ PROJECT_VERSION := $(file < version.txt)
- 
- all:
-   $(MAKE) -C src
-+  $(MAKE) -C files/lang
- ifndef FHEROES2_MACOS_APP_BUNDLE
-   @cp src/dist/$(TARGET) .
- endif

Re: math/ministat segmentation fault

[Mikhail]

On Thu, Nov 10, 2022 at 06:21:52PM +0100, Jeremie Courreges-Anglas wrote:
> On Thu, Nov 10 2022, Mikhail  wrote:
> > On Thu, Nov 10, 2022 at 09:35:18AM +0100, Jeremie Courreges-Anglas wrote:
> >> On Thu, Nov 10 2022, Ross L Richardson  wrote:
> >> > Reported upstream (by me) as
> >> >  https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=267684
> >> >
> >> > math/ministat has a silly bug in which the code assumes that "-" will be
> >> > specified no more than once at invocation:
> >> >
> >> > $ jot 3 | ministat - - 
> >> > Segmentation fault (core dumped) 
> >> >
> >> > The problem is in the port-patched code at:
> >> >643   if (argc > (MAX_DS - 1))
> >> >644   usage("Too many datasets.");
> >> >645   nds = argc;
> >> >646   for (i = 0; i < nds; i++) {
> >> >647   setfilenames[i] = argv[i];
> >> >648   if (!strcmp(argv[i], "-"))
> >> >649   setfiles[0] = stdin;
> >> >650   else
> >> >651   setfiles[i] = fopen(argv[i], 
> >> > "r");
> >> >652   if (setfiles[i] == NULL)
> >> >653   err(2, "Cannot open %s", 
> >> > argv[i]);
> >> >654   }
> >> >
> >> > On line 649, the index is fixed at 0, eventually leading to fgets()
> >> > attempting to read from an uninitialised stream.
> >> >
> >> > The simplest fix is change the index:
> >> >649   setfiles[i] = stdin;
> >> 
> >> Indeed.
> >> 
> >> > That way, ministat will error out complaining that, on the second 
> >> > reading,
> >> > stdin has fewer than 3 data points.
> >> > (A more logical fix would be to check explicitly for more than 1
> >> > occurrence of "-".)
> >> 
> >> A lot of tools that can use stdin don't explicitely check for it being
> >> specified twice.  As far as this port is concerned, I think it's fine.
> >> 
> >> Thanks for your report.  Do you want to take it to upstream FreeBSD?
> >> 
> >> Here's the diff for our ports tree.
> >
> > FreeBSD version doesn't crash:
> >
> > [freefall ~] ministat - -
> > ministat: Cannot open -: No error: 0
> >
> > It's because on line 652 (see code snippet above) we check if array
> > element is set to NULL, and before that we either use 0 index for stdin
> > or don't set any element if we see any more -), so, I'd suggest to fail
> > the same way as FreeBSD does, for this we need to explicitly set all
> > array elements to NULL.
> >
> > So, how about such approach?
> 
> Setting the array to NULL prevents the crash - FreeBSD sems to be more
> forgiving here - but IMO the intended semantics are really to set
> setfiles[i].  I think that the proposal from Ross should be preferred,
> for the ports tree but also for an upstream fix.

I created differential revision for Ross' patch:
https://reviews.freebsd.org/D37346

If it won't be handled by FreeBSD in reasonable time, I think we can
proceed with your patch without upstream then.

Re: math/ministat segmentation fault

[Mikhail]

On Thu, Nov 10, 2022 at 09:35:18AM +0100, Jeremie Courreges-Anglas wrote:
> On Thu, Nov 10 2022, Ross L Richardson  wrote:
> > Reported upstream (by me) as
> > https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=267684
> >
> > math/ministat has a silly bug in which the code assumes that "-" will be
> > specified no more than once at invocation:
> >
> > $ jot 3 | ministat - - 
> > Segmentation fault (core dumped) 
> >
> > The problem is in the port-patched code at:
> >643  if (argc > (MAX_DS - 1))
> >644  usage("Too many datasets.");
> >645  nds = argc;
> >646  for (i = 0; i < nds; i++) {
> >647  setfilenames[i] = argv[i];
> >648  if (!strcmp(argv[i], "-"))
> >649  setfiles[0] = stdin;
> >650  else
> >651  setfiles[i] = fopen(argv[i], 
> > "r");
> >652  if (setfiles[i] == NULL)
> >653  err(2, "Cannot open %s", 
> > argv[i]);
> >654  }
> >
> > On line 649, the index is fixed at 0, eventually leading to fgets()
> > attempting to read from an uninitialised stream.
> >
> > The simplest fix is change the index:
> >649  setfiles[i] = stdin;
> 
> Indeed.
> 
> > That way, ministat will error out complaining that, on the second reading,
> > stdin has fewer than 3 data points.
> > (A more logical fix would be to check explicitly for more than 1
> > occurrence of "-".)
> 
> A lot of tools that can use stdin don't explicitely check for it being
> specified twice.  As far as this port is concerned, I think it's fine.
> 
> Thanks for your report.  Do you want to take it to upstream FreeBSD?
> 
> Here's the diff for our ports tree.

FreeBSD version doesn't crash:

[freefall ~] ministat - -
ministat: Cannot open -: No error: 0

It's because on line 652 (see code snippet above) we check if array
element is set to NULL, and before that we either use 0 index for stdin
or don't set any element if we see any more -), so, I'd suggest to fail
the same way as FreeBSD does, for this we need to explicitly set all
array elements to NULL.

So, how about such approach?

idea:~$ ministat - -

ministat: Cannot open -: Undefined error: 0

diff /usr/ports
commit - 3dc099815c186e4b5eef9648d2e4013c689addbd
path + /usr/ports
blob - 757012eb733c5369eb84fd5f9f9c7802b03ff003
file + math/ministat/Makefile
--- math/ministat/Makefile
+++ math/ministat/Makefile
@@ -1,6 +1,7 @@
 COMMENT=   statistics utility
 
 DISTNAME=  ministat-0.0.20211218
+REVISION=  0
 
 CATEGORIES=math
 
blob - 82421e27351ffc2918e2d7791636ad3c709d76f6
file + math/ministat/patches/patch-ministat_c
--- math/ministat/patches/patch-ministat_c
+++ math/ministat/patches/patch-ministat_c
@@ -1,5 +1,8 @@
 Remove FBSDID and replace capsicum with pledge
 
+Safety belt for 'ministat - -' invocation see FreeBSD bugzilla
+https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=267684
+
 Index: ministat.c
 --- ministat.c.orig
 +++ ministat.c
@@ -19,17 +22,21 @@ Index: ministat.c
  #include 
  #include 
  #include 
-@@ -569,6 +566,9 @@ main(int argc, char **argv)
+@@ -569,6 +566,13 @@ main(int argc, char **argv)
int termwidth = 74;
int suppress_plot = 0;
  
++  /* Safety belt for 'ministat - -' invocation */
++  for (i = 0; i < MAX_DS; i++)
++  setfiles[i] = NULL;
++
 +  if (pledge("stdio rpath tty", NULL) == -1)
 +  err(1, NULL);
 +
if (isatty(STDOUT_FILENO)) {
struct winsize wsz;
  
-@@ -579,6 +579,9 @@ main(int argc, char **argv)
+@@ -579,6 +583,9 @@ main(int argc, char **argv)
termwidth = wsz.ws_col - 2;
}
  
@@ -39,7 +46,7 @@ Index: ministat.c
ci = -1;
while ((c = getopt(argc, argv, "AC:c:d:snqw:")) != -1)
switch (c) {
-@@ -651,23 +654,14 @@ main(int argc, char **argv)
+@@ -651,23 +658,14 @@ main(int argc, char **argv)
}
}
  

Re: emacs crash

[Mikhail]

On Wed, Nov 09, 2022 at 02:47:25PM -0800, Nam Nguyen wrote:
> Mikhail writes:
> > No crashes are observed when I run "emacs .emacs" outside of tmux. I
> > also have old laptop with latest current amd64 and I can't reproduce
> > crash there.
> 
> Try moving .tmux.conf out of the way (or post your .tmux.conf). That
> seems to be something not tested yet.

tmux -f /dev/null -L test
emacs .emacs
no crash

cat tmux.conf   
   
set -g default-terminal screen-256color

tmux -f tmux.conf -L test 
emacs .emacs
same crash

emacs crash

[Mikhail]

I installed emacs on latest amd64 current and it crashes for me when I try to
edit .emacs file in home directory, particularly such commands crash it
reliably:

idea:~$ cd ~
idea:~$ emacs .emacs
Fatal error 11: Segmentation fault
Backtrace:
0x4a6aaba9317  at emacs
0x4a6aab8bab8  at emacs
0x4a6aabaab4e  at emacs
0x4a6aabaabd2  at emacs
0x4a6aaba8ff9  at emacs
Segmentation fault (core dumped) 

if I use full path, like

emacs /home/misha/.emacs

then it works fine.

Also if I replace this string in the file:
(setq scroll-step 1)
with
;(setq scroll-step 1)

then I also can do "emacs .emacs" without problem, but I suspect the
crash has something with synatx coloring, and not with scroll-step,
because if I replace some other lines, like

;;(require 'smex)
with
(require 'smex)

there is also no crash.

emacs -Q .emacs and emacs -q .emacs also work.

I tried to compile latest emacs git and emacs-28.2 from sources and they work
fine.

I did some jungling, like moving .emacs to /tmp and trying the same
command "emacs .emacs" - it worked fine too. I can't reproduce crashes
when running as other user.

No crashes are observed when I run "emacs .emacs" outside of tmux. I
also have old laptop with latest current amd64 and I can't reproduce
crash there.

The .emacs file located here: http://freebsd.org/~misha/.emacs

Does anyone has an idea how to dig this further?

here is bt:

(gdb) bt
#0  thrkill () at /tmp/-:3
#1  0x0edee8705ae5 in terminate_due_to_signal (sig=11, 
backtrace_limit=) at emacs.c:437
#2  0x0edee8724b4e in handle_fatal_signal (sig=0) at sysdep.c:1762
#3  0x0edee8724bd2 in deliver_thread_signal (sig=11, handler=) at sysdep.c:1754
#4  0x0edee8722ff9 in deliver_fatal_thread_signal (sig=0) at sysdep.c:1774
#5  0x0edee8724c1a in handle_sigsegv (sig=11, siginfo=, 
arg=) at sysdep.c:1867
#6  
#7  tty_defined_color (f=, color_name=0xee11b417178 , color_def=0x7f7c0638, 
alloc=, _makeIndex=) at xfaces.c:1055
#8  0x0edee86fdab8 in load_color2 (f=0xee12b2c9000, face=0xee16a7d0200, 
name=0xee1b224f784, target_index=, color=) at xfaces.c:1200
#9  load_color (f=0xee12b2c9000, face=0xee16a7d0200, name=0xee1b224f784, 
target_index=) at 
xfaces.c:1263
#10 map_tty_color (f=0xee12b2c9000, face=0xee16a7d0200, idx=, defaulted=) at 
xfaces.c:6201
#11 realize_tty_face (cache=0xee13a049c00, attrs=0x7f7c0730) at 
xfaces.c:6275
#12 realize_face (cache=0xee13a049c00, attrs=0x7f7c0730, 
former_face_id=) at xfaces.c:5840
#13 0x0edee870262c in realize_named_face (f=0xee12b2c9000, 
symbol=, id=10) at xfaces.c:5809
#14 0x0edee86f9eb2 in realize_basic_faces (f=0xee12b2c9000) at xfaces.c:5624
#15 0x0edee86fcc3b in update_face_from_frame_parameter (f=0xee12b2c9000, 
param=, new_value=0xee1b224f784) at xfaces.c:3673
#16 0x0edee866865f in Fmodify_frame_parameters (frame=, 
alist=) at frame.c:3451
#17 0x0edee879b941 in Ffuncall (nargs=, args=) at eval.c:3023
#18 0x0edee87e5b46 in exec_byte_code (bytestr=, 
vector=0xee1dde8c2f5, maxdepth=, args_template=, 
nargs=, args=) at bytecode.c:632
#19 0x0edee879b8c1 in Ffuncall (nargs=, args=) at eval.c:3038
#20 0x0edee87e5b46 in exec_byte_code (bytestr=, 
vector=0xee0faaa6005, maxdepth=, args_template=, 
nargs=, args=) at bytecode.c:632
#21 0x0edee879b8c1 in Ffuncall (nargs=, args=) at eval.c:3038
#22 0x0edee87e67e4 in bcall0 (f=0xee1b7edfec5) at bytecode.c:340
#23 0x0edee8796b0c in unbind_to (count=, value=0x0) at 
eval.c:3841
#24 0x0edee87e6097 in exec_byte_code (bytestr=, 
vector=0xee1dde9469d, maxdepth=, args_template=, 
nargs=, args=) at bytecode.c:652
#25 0x0edee879b1c5 in apply_lambda (fun=0xee1ddd44520, args=, count=) at eval.c:3172
#26 0x0edee8796f94 in eval_sub (form=) at eval.c:2869
#27 0x0edee879aeb8 in Feval (form=0xee1de279d93, lexical=) 
at eval.c:2327
#28 0x0edee8799b79 in internal_condition_case (bfun=0x42a391c29780d636, 
handlers=, hfun=0xedee8707a60 ) at eval.c:1450
#29 0x0edee87179ab in top_level_1 (ignore=) at 
keyboard.c:1150
#30 0x0edee87992be in internal_catch (tag=, 
func=0xe4958413794725e4, arg=0x0) at eval.c:1181
#31 0x0edee8705e02 in command_loop () at keyboard.c:1110
#32 0x0edee8705caf in recursive_edit_1 () at keyboard.c:720
#33 0x0edee870601c in Frecursive_edit () at keyboard.c:803
#34 0x0edee8704ae3 in main (argc=, argv=0x7f7c19a8) at 
emacs.c:2358

Re: new: games/zelda3

[Mikhail]

On Tue, Nov 01, 2022 at 05:56:26PM +0100, Stefan Sperling wrote:
> This is a reverse engineered clone of Zelda 3 - A Link to the Past.
> 
> It's around 70-80kLOC of C code, and reimplements all parts of the
> original game. The game is playable from start to end.
> 
> A bunch of features have been added that are not supported by the
> original game. Some of them are:
> - Support for pixel shaders.
> - Support for enhanced aspect ratios of 16:9 or 16:10.
> - Higher quality world map.
> - Support for MSU audio tracks.
> - Secondary item slot on button X (Hold X in inventory to select).
> - Switching current item with L/R keys.
> 
> A proprietary ROM file of the original game is required to compile.
> This file is handled by the zelda3-data port to keep things simple,
> thanks to espie@ for suggesting this.
> 
> ok?

Works fine for me on current/amd64, one remark is that in README, in
this paragraph:

The game reads the configuration file zelda3.ini, which must be placed
in the current working directory where the game is started.
An example can be found at /usr/local/share/examples/zelda3.ini.

Path should be changed to /usr/local/share/examples/zelda3/zelda3.ini

Re: [new] math/ministat: small statistic utility

[Mikhail]

On Sat, Oct 29, 2022 at 09:43:28AM +0100, Stuart Henderson wrote:
> On 2022/10/29 11:02, Mikhail wrote:
> > On Sat, Oct 29, 2022 at 09:37:08AM +0200, Omar Polo wrote:
> > > 
> > > Port-wise, the only thing that needs to be adjusted is CFLAGS, as
> > > it uses the hardcoded ones '-O2 -pipe -Werror' and not the ones
> > > provided by the port infrastructure; it's very easy to fix:
> > 
> > Fixed, new archive attached, also the diff between vanilla and this
> > ministat.c:
> 
> imho it would be better for the distfile to be exactly the standard
> FreeBSD version, then apply any changes by patching it in the port

Such way it looks cleaner indeed. Distfile updated, new archive
attached.


ministat.tgz
Description: application/tar-gz

Re: [new] math/ministat: small statistic utility

[Mikhail]

On Sat, Oct 29, 2022 at 09:37:08AM +0200, Omar Polo wrote:
> 
> Port-wise, the only thing that needs to be adjusted is CFLAGS, as
> it uses the hardcoded ones '-O2 -pipe -Werror' and not the ones
> provided by the port infrastructure; it's very easy to fix:

Fixed, new archive attached, also the diff between vanilla and this
ministat.c:

--- /home/misha/work/freebsd/usr.bin/ministat/ministat.c2022-06-04 
17:00:56.36211 +0300
+++ ministat.c  2022-10-28 21:49:38.156442000 +0300
@@ -11,15 +11,12 @@
  */
 
 #include 
-__FBSDID("$FreeBSD$");
 
-#include 
 #include 
 #include 
 #include 
 
 #include 
-#include 
 #include 
 #include 
 #include 
@@ -569,6 +566,9 @@
int termwidth = 74;
int suppress_plot = 0;
 
+   if (pledge("stdio rpath tty", NULL) == -1)
+   err(1, NULL);
+
if (isatty(STDOUT_FILENO)) {
struct winsize wsz;
 
@@ -579,6 +579,9 @@
termwidth = wsz.ws_col - 2;
}
 
+   if (pledge("stdio rpath", NULL) == -1)
+   err(1, NULL);
+
ci = -1;
while ((c = getopt(argc, argv, "AC:c:d:snqw:")) != -1)
switch (c) {
@@ -651,23 +654,14 @@
}
}
 
-   if (caph_limit_stdio() < 0)
-   err(2, "capsicum");
-
-   for (i = 0; i < nds; i++)
-   if (caph_limit_stream(fileno(setfiles[i]), CAPH_READ) < 0)
-   err(2, "unable to limit rights for %s",
-   setfilenames[i]);
-
-   /* Enter Capsicum sandbox. */
-   if (caph_enter() < 0)
-   err(2, "unable to enter capability mode");
-
for (i = 0; i < nds; i++) {
ds[i] = ReadSet(setfiles[i], setfilenames[i], column, delim);
if (setfiles[i] != stdin)
fclose(setfiles[i]);
}
+
+   if (pledge("stdio", NULL) == -1)
+   err(1, NULL);
 
if (!flag_q) {
for (i = 0; i < nds; i++)


ministat.tgz
Description: application/tar-gz

[new] math/ministat: small statistic utility

[Mikhail]

Simple utility from FreeBSD base[1], it is used for getting statistics,
for example, from benchmarks data.

Capsicum has been replaced with pledge().

[1] - https://cgit.freebsd.org/src/tree/usr.bin/ministat

$ pkg_info ministat
Information for inst:ministat-0.1

Comment:
statistics utility

Description:
The ministat command calculates fundamental statistical properties of numeric
data in the specified files or, if no file is specified, standard input.

This is a port of FreeBSD native ministat utility, which is included in FreeBSD
distribution.

Maintainer: The OpenBSD ports mailing-list 



ministat.tgz
Description: application/tar-gz

[maintainer update] net/epic5: from 2.1.11 to 2.1.12

[Mikhail]

Changes in this release:

- renaming of reconnect.orig to reconnect.old, so we can remove
  PATCHORIG from the Makefile
- taming SEPARATE_BUILD (using @builddir@ instead of @srcdir@ in
  info.c.sh.in script, fixing stringify target replacing straight naming
  with $< and $@ vars)
- fixing a crash with >1000 windows
- other minor code improvements

Ok from the maintainer (cc'ed).

diff --git a/net/epic5/Makefile b/net/epic5/Makefile
index 670ed0f347e..38f21e48ef9 100644
--- a/net/epic5/Makefile
+++ b/net/epic5/Makefile
@@ -1,6 +1,6 @@
 COMMENT=   enhanced programmable ircII client 5th generation
 
-VERSION=   2.1.11
+VERSION=   2.1.12
 DISTNAME=  epic5-${VERSION}
 CATEGORIES=net
 HOMEPAGE=  http://www.epicsol.org/
@@ -34,8 +34,7 @@ WANTLIB+= ${MODPY_WANTLIB} intl pthread util
 
 NO_TEST=   Yes
 
-# scripts/reconnect.orig
-PATCHORIG= .orig.port
+SEPARATE_BUILD=Yes
 
 post-install:
${INSTALL_DATA_DIR} ${PREFIX}/share/doc/epic5/
diff --git a/net/epic5/distinfo b/net/epic5/distinfo
index fd79cb9c733..210a8be3ed8 100644
--- a/net/epic5/distinfo
+++ b/net/epic5/distinfo
@@ -1,2 +1,2 @@
-SHA256 (epic5-2.1.11.tar.gz) = HSSF8DlQeZCtgZFz67/N8E3OP8HRbWljFEpwjV7fGXA=
-SIZE (epic5-2.1.11.tar.gz) = 1184253
+SHA256 (epic5-2.1.12.tar.gz) = faNLY0AuUTrh8aZbS559xHmkskTsk85c7vF50y+ehrc=
+SIZE (epic5-2.1.12.tar.gz) = 1186984
diff --git a/net/epic5/pkg/PLIST b/net/epic5/pkg/PLIST
index 33a3e64d797..94059f67d68 100644
--- a/net/epic5/pkg/PLIST
+++ b/net/epic5/pkg/PLIST
@@ -1,5 +1,5 @@
 bin/epic5
-@bin bin/epic5-2071
+@bin bin/epic5-2078
 @bin libexec/epic5-wserv4
 @man man/man1/epic5.1
 share/doc/epic5/
@@ -75,7 +75,7 @@ share/epic5/script/paste
 share/epic5/script/pipe
 share/epic5/script/python
 share/epic5/script/reconnect
-share/epic5/script/reconnect.orig
+share/epic5/script/reconnect.old
 share/epic5/script/rejoin
 share/epic5/script/renumber
 share/epic5/script/revdcc

Re: ports: pkg/SCREENSHOTS proposal

[Mikhail]

On Sat, Jun 18, 2022 at 06:11:49PM +0200, Thomas Dettbarn wrote:
> Hello.
> 
> Hopefully this is the correct mailinglist for a proposal like this.
> And hopefully you have not already had this discussion before.
> In which case, I would like to apologize.
> 
> Anyways, I have a proposal, to make OpenBSD, the OS that
> I love, maybe a little bit cuter.

I think people usually know what software do they need (it means they
know how it looks like, or the look doesn't matter to them), and making
Apple Store from the ports tree don't worth the time spent.

Re: [new] net/epic5 - irc client with pledge/unveil

[Mikhail]

On Mon, Jun 06, 2022 at 10:39:52AM +0100, Stuart Henderson wrote:
> On 2022/06/06 11:12, Omar Polo wrote:
> > some tweaks are needed:
> 
> I agree with all your tweaks. Generally ok to import (as long as
> MAINTAINER really is correct). The pledge/unveil stuff mentioned in
> README does not really nice though, this is not something users should
> have to fiddle with for basic operation, I would drop that section from
> the readme and leave it for advanced users to find for themselves if
> they want to be responsible for keeping it up to date/fixing things.

I've applied tweaks from Omar, added epicrc.sample to files/ and install
it to ${PREFIX}/share/epic5/script instead of embedding in README, also
removed pledge/unveil example from this file as Stuart suggested, left
only a note, that further information about the syscalls usage is in
UPDATES document.

Regarding maintainer - Joey will be the "official" one, so the variable
is set correctly, but we both will take care of this port.

Appreciated for the review.


epic5.tar.gz
Description: application/tar-gz

Re: [new] net/epic5 - irc client with pledge/unveil

[Mikhail]

On Sat, May 28, 2022 at 04:58:59PM +0300, Mikhail wrote:
> On Sun, Apr 24, 2022 at 09:36:02PM +0300, Mikhail wrote:
> > Friendly weekly ping.
> 
> New version 2.1.10 has been released, new port is attached. The
> developer has made changes, which allows to build epic5 with -O2,
> INSTALL document also updated, I've been testing this for several weeks
> and there were no crashes.

2.1.11 version is attached, also friendly weekly ping

ChangeLog:

* Always call alists 'alist's instead of 'array's
* Add a #define UINTMAX_HEX_FORMAT for pointers
* Change (List)s to have a data pointer rather than inheritance
* This removes a major remaining type punning issue
* Remove '_window_list_end' from screens.  Determine it on the fly.
* Add get_screen_bottom_window() to replace '_window_list_end'
* Change (Crypt) from a (List) type to a data object for List
* Change various crypt.c functions to take a straight (List).
* Change various crypt.c functions to create and store a (Crypt) in (List)
* Make (WNickList) private to window.c, use ordinary (List)s ordinarily
* Change window's 'waiting_chans' and 'nicks' ordinary (List)s
* Add ARAs - "automatically resizable arrays"; directly addressable arrays
* Comment out bucket_(var|cmd)_alias and bucket_builtin_* to avoid warnings
* Except bucket_builtin_variables() which is the only one actually used!
* Convert (Ignore) from a (List) type to a data object for List
* If a panic() happens during shutdown, then just go ahead and exit.
* Convert (Binding) from a (List) type to a data object for List
* Convert (Logfile) to use a plain old (List) to hold target names.
* Rename 'invislble_list' to '_invisible_list' for future deprecation
* Make everything using invisible list go through a function.
* Split 'delete_window' into 'unlink_window' and 'delete_window_contents'
* And make those two take refnums instead of a window ptr.
* /fe ("" .) foo {echo $foo} with /xdebug dword (rb ce)
* Fix /window swap_others (skered)
* Un-break $unveil() with no arguments (rb zlonix)
* Remove configure checks for sysctlbyname(), 
* Fix warnings from raspbian (rb zlonix)
* Don't include  (not used) (rb zlonix)
* Do #define _GNU_SOURCE 1 for slackware (BAH!)
* Begin untangling the "signed pointer mess"
* Generally this means:
* - (char *), not (unsigned char *) is the "generic type" in C params
* - Pointer parameters have to have *equivalent* types, not just *compatible* 
types.
* - The type of "a bunch of bytes" is always (char *), not (unsigned char *)
*   - Even though (char *) is not 8 bit clean.
* - Type type of literals is always (char *), not (unsigned char *)
* - So don't use (unsigned char *) for params unless the thing is NOT a BoBs.
* - So DO use (char *) and cast it on both sides of the call.
* - Don't have (const unsigned char **) params to modify a pointer
*   - Prefer (const unsigned char *) and return a (ptrdiff_t)
* Change (Crypt) 'passwd' to unsigned because OpenSSL wants it that way.
* Eliminate all warnings from -Wpointer-sign
* - Mostly by eliminating nearly all uses of (unsigned char *)
* Eliminate all warnings from -Wunused
* - But not from -Wno-unused-functions or -Wno-unused-parameter
* Remove many spurious casts to and from (void *) (c99-ism)
* Fix warnings found by wider testing


epic5.tar.gz
Description: application/tar-gz

Re: [new] net/epic5 - irc client with pledge/unveil

[Mikhail]

On Sun, Apr 24, 2022 at 09:36:02PM +0300, Mikhail wrote:
> Friendly weekly ping.

New version 2.1.10 has been released, new port is attached. The
developer has made changes, which allows to build epic5 with -O2,
INSTALL document also updated, I've been testing this for several weeks
and there were no crashes.


epic5.tar.gz
Description: application/tar-gz

Re: NEW: databases/postgresql-ip4r

[Mikhail]

On Fri, Apr 29, 2022 at 06:12:00PM +0100, Stuart Henderson wrote:
> ok to import this?
> 
> -
> IP4R is a PostgreSQL extension which supports 6 data types allowing
> you to store IPv4 & IPv6 addresses in a PostgreSQL table:
> 
>   ip4   - a single IPv4 address
>   ip4r  - an arbitrary range of IPv4 addresses
>   ip6   - a single IPv6 address
>   ip6r  - an arbitrary range of IPv6 addresses
>   ipaddress  - a single IPv4 or IPv6 address
>   iprange- an arbitrary range of IPv4 or IPv6 addresses
> 
> While PostgreSQL already has builtin types 'inet' and 'cidr', the
> authors of this module found that they had a number of requirements
> that were not addressed by the builtin types.
> -

I did light testing, "create extension" works fine for my installation.

Re: [new] net/epic5 - irc client with pledge/unveil

[Mikhail]

Friendly weekly ping.

On Mon, Apr 18, 2022 at 10:15:47AM +0300, Mikhail wrote:
> On Sat, Apr 16, 2022 at 07:18:47AM -0600, Daniel Dickman wrote:
> > 
> > 
> > > On Apr 14, 2022, at 11:49 AM, Stuart Henderson  
> > > wrote:
> > > 
> > > My thinking is that, if the code has behaviour which is considered
> > > undefined by the C standard assumed by the compiler, no level of
> > > optimization is safe. Maybe now you get lucky and -O works (on whichever
> > > architecture you've tested) but I don't think it's reasonable to assume
> > > that this is the case everywhere, or will be the case following compiler
> > > updates.
> > 
> > I haven't looked very deeply at epic but if the note is referring to
> > strict aliasing then I would follow the advice about sticking to -O.
> > 
> > John Regehr wrote up a nice piece on this a few years ago:
> > 
> > https://blog.regehr.org/archives/1307
> 
> We have a decade or even more when we didn't hear any random crashes
> reports with '-O', and FreeBSD has it as a default flag.
> 
> Epic developer takes crash reports seriously, when I had "openbsd only
> crash" he helped me with it. Also, he wasn't against adding unveil and
> pledge.
> 
> Anyway, if there is a proposition not to take any risk - probably it
> worth it, performance isn't critical thing for an IRC client.
>

Re: [new] net/epic5 - irc client with pledge/unveil

[Mikhail]

On Sat, Apr 16, 2022 at 07:18:47AM -0600, Daniel Dickman wrote:
> 
> 
> > On Apr 14, 2022, at 11:49 AM, Stuart Henderson  wrote:
> > 
> > My thinking is that, if the code has behaviour which is considered
> > undefined by the C standard assumed by the compiler, no level of
> > optimization is safe. Maybe now you get lucky and -O works (on whichever
> > architecture you've tested) but I don't think it's reasonable to assume
> > that this is the case everywhere, or will be the case following compiler
> > updates.
> 
> I haven't looked very deeply at epic but if the note is referring to
> strict aliasing then I would follow the advice about sticking to -O.
> 
> John Regehr wrote up a nice piece on this a few years ago:
> 
> https://blog.regehr.org/archives/1307

We have a decade or even more when we didn't hear any random crashes
reports with '-O', and FreeBSD has it as a default flag.

Epic developer takes crash reports seriously, when I had "openbsd only
crash" he helped me with it. Also, he wasn't against adding unveil and
pledge.

Anyway, if there is a proposition not to take any risk - probably it
worth it, performance isn't critical thing for an IRC client.

Re: [new] net/epic5 - irc client with pledge/unveil

[Mikhail]

On Sat, Apr 16, 2022 at 11:05:53AM +0100, Stuart Henderson wrote:
> You know you can just do "CFLAGS += -O0" rather than this?

Fixed, new archive attached.

> It really seems strange though, are any other OS packages of epic4/5 built
> that way?

At least FreeBSD builds epic5 with substitute of CFLAGS:
https://github.com/freebsd/freebsd-ports/blob/main/irc/epic5/Makefile#L16

Debian seem not to change default user CFLAGS.


epic5.tar.gz
Description: application/tar-gz

Re: [new] net/epic5 - irc client with pledge/unveil

[Mikhail]

On Thu, Apr 14, 2022 at 06:49:12PM +0100, Stuart Henderson wrote:
> On 2022/04/08 22:14, Mikhail wrote:
> > On Fri, Apr 08, 2022 at 08:03:14PM +0100, Stuart Henderson wrote:
> > > It's too late for 7.1 release.
> > > 
> > > Re: the -O2 issue, does setting -std=c89 fix the problem?
> > 
> > I think epic developers won't take the risk, the software has very old
> > history and we didn't receive any random crashes reports while being
> > simply with '-O' (epic4 and epic5 are still actively maintained, all
> > efforts are on the later, though).
> > 
> > I've plans to submit net/epic5 port, because it has gained pledge/unveil
> > support, does -O will be considered as an issue by committers?
> 
> - don't set MODPY_MAJOR_VERSION

Thanks for review. Fixed.

> - my previous comments about the CFLAGS handing stand:
> 
> # You must not try to compile epic with "gcc -O2" because -O2 will
> # generate bad code that leads to random crashes.  When you use -O2, gcc
> # assumes the source is conformant to ISO C99's requirements about
> # alias-safety, and EPIC, being a C90 program, does not conform, so the
> # result is undefined behavior (which means it crashes randomly.)
> CFLAGS:=${CFLAGS:C/-O2/-O/g}
> 
> --snip--
> My thinking is that, if the code has behaviour which is considered
> undefined by the C standard assumed by the compiler, no level of
> optimization is safe. Maybe now you get lucky and -O works (on whichever
> architecture you've tested) but I don't think it's reasonable to assume
> that this is the case everywhere, or will be the case following compiler
> updates.
> 
> (Of course on many OpenBSD architectures the relevant compiler is not
> GCC anyway).
> --snip--

I've changed -O to -O0.

> and your proposal doesn't work if the user builds from ports with CFLAGS=-O3

Such change has to go to net/epic4 too, because currently it builds with
-O2, so I added such lines to Makefile:
CFLAGS:=${CFLAGS:C/-O1/-O0/g}
CFLAGS:=${CFLAGS:C/-O2/-O0/g}
CFLAGS:=${CFLAGS:C/-O3/-O0/g}
CFLAGS:=${CFLAGS:C/-O4/-O0/g}
CFLAGS:=${CFLAGS:C/-Ofast/-O0/g}
CFLAGS:=${CFLAGS:C/-Os/-O0/g}
CFLAGS:=${CFLAGS:C/-Oz/-O0/g}

New tgz is attached.


epic5.tar.gz
Description: application/gzip

[new] net/epic5 - irc client with pledge/unveil

[Mikhail]

Hello, this is proposal to add net/epic5 irc client to the ports tree,
currently we have net/epic4, but it's previous generation of the client,
all development activity and users long ago had moved to epic5.

The client distinguishes itself by extremely high ability to customize
IRC experience with ircII scripting language.

EPIC5 also has gained pledge/unveil support in master branch recently,
the patches are included in current port, because next software update
won't be released soon.

More info about the software and pledge/unveil usage is in pkg/README.

The port will be maintained by me and Joey (cc'ed).

Comments, suggestions and testing are welcome.


epic5.tar.gz
Description: application/tar-gz

Re: net/epic4 update

[Mikhail]

On Thu, Jan 13, 2022 at 12:51:53AM -0500, Daniel Dickman wrote:
> On Mon, Oct 4, 2021 at 6:35 AM Mikhail  wrote:
> >
> > On Thu, Sep 16, 2021 at 12:18:36PM +0300, Mikhail wrote:
> > > On Wed, Sep 15, 2021 at 11:48:18PM -0400, Daniel Dickman wrote:
> > > > On Tue, Sep 14, 2021 at 6:39 AM Mikhail  wrote:
> > > > >
> > > > > On Mon, Sep 13, 2021 at 09:34:54PM +0300, Mikhail wrote:
> > > > > > Hello, this is update for net/epic4 port from 2.10.5 to 2.10.10.
> > > > > >
> > > > > > patch-include_irc_h and patch-source_irc_c were incorporated 
> > > > > > upstream
> > > > > > and should be rm'ed
> > > > > >
> > > > >
> > > > > On IRC I was advised to remove REVISION, new patch is inline.
> > > > >
> > > > > The maintainer has been contacted, seem he ignores the updates.
> > > >
> > > > sometimes people take vacations or life comes up. I'd say wait at
> > > > least a week or two to see if they will reply.
> > > >
> > > > If no reply in a week or two, they could be removed.
> > >
> > > He was contacted in 2019, he replied in 2020 and the reply was that he
> > > would update the port, but he never did.
> > >
> > > Today the mail server reports that there is no such email address.
> > >
> > > New patch with MAINTAINER removed.
> >
> > ping
> >
> 
> I looked at doing this update again, but reading INSTALL it says the 
> following:
> 
>  You must not try to compile epic with "gcc -O2" because -O2 will
>  generate bad code that leads to random crashes.  When you use -O2,
>  gcc assumes the source is conformant to ISO C99's requirements about
>  alias-safety, and EPIC, being a C90 program, does not conform, so the
>  result is undefined behavior (which means it crashes randomly.)  This
>  is not a bug in EPIC.  You must only compile epic with -O.
> 
> The current port *does* build with -O2 although the warning seems a
> bit... concerning? Doing the update may be no worse than the current
> situation. Still, it might be good to verify if the comment is stale
> and -O2 is ok, or whether we should switch to using -O.
> 
> Also looking at WANTLIB following the update, is pthread still needed?
> 
> For now, I've dropped MAINTAINER as we haven't heard from them in a few 
> months.


I missed this email while being unsubscribed from the list, it
looks like Gmail filters archived it silently, because it contained
'ports@openbsd.org'.

The comment is correct, inlined patch updates Makefile to use -O, and
also removes pthread. Two patches are incorporated in upstream and have
to be rm'ed.

This release also fixes
https://www.openwall.com/lists/oss-security/2021/03/24/2 (the client
isn't listed there, but it has roots in ircii and share the same ctcp
codebase).

diff --git a/net/epic4/Makefile b/net/epic4/Makefile
index 1969933283d..7bfb4d9956b 100644
--- a/net/epic4/Makefile
+++ b/net/epic4/Makefile
@@ -1,19 +1,18 @@
 COMMENT=   (E)nhanced (P)rogrammable (I)RC-II (C)lient
 
-VERSION=   2.10.5
-REVISION=  3
+VERSION=   2.10.10
 HELP_DATE= 20050315
 DISTNAME=  epic4-${VERSION}
 CATEGORIES=net
 MASTER_SITES=  http://ftp.epicsol.org/pub/epic/EPIC4-PRODUCTION/
-DISTFILES= epic4-${VERSION}.tar.bz2 epic4-help-${HELP_DATE}.tar.bz2
+DISTFILES= epic4-${VERSION}.tar.xz epic4-help-${HELP_DATE}.tar.bz2
 
 HOMEPAGE=  http://www.epicsol.org/
 
 # BSD
 PERMIT_PACKAGE=Yes
 
-WANTLIB=   c crypto m curses perl pthread ssl
+WANTLIB=   c crypto m curses perl ssl
 
 FAKE_FLAGS=INSTALL_PROGRAM="${INSTALL_PROGRAM}" \
INSTALL_DATA="${INSTALL_DATA}"
@@ -27,6 +26,13 @@ CONFIGURE_ENV=   ac_cv_header_sys_sysctl_h=no
 
 INSTALL_TARGET=install installhelp
 
+# You must not try to compile epic with "gcc -O2" because -O2 will
+# generate bad code that leads to random crashes.  When you use -O2, gcc
+# assumes the source is conformant to ISO C99's requirements about
+# alias-safety, and EPIC, being a C90 program, does not conform, so the
+# result is undefined behavior (which means it crashes randomly.)
+CFLAGS:=   ${CFLAGS:C/-O2/-O/g}
+
 NO_TEST=   Yes
 
 SUBST_VARS=VERSION
diff --git a/net/epic4/distinfo b/net/epic4/distinfo
index bcabd3b06db..b00b971e5d9 100644
--- a/net/epic4/distinfo
+++ b/net/epic4/distinfo
@@ -1,4 +1,4 @@
-SHA256 (epic4-2.10.5.tar.bz2) = /KexeIveUmh/0BwzxedNDhb8xlanazh94YUE7adk/4A=
+SHA256 (epic4-2.10.10.tar.xz) = 0SJxvL/YJ+nnWcMrumDs6AWul40z7ZHZIH3kNtBx+8U=
 SHA256 (epic4-help-20050315.ta

Re: [patch] textproc/par: use pledge()

[Mikhail]

On Thu, Mar 10, 2022 at 05:53:55PM +0300, Mikhail wrote:
> Inlined patch adds support for pledge() in par formatter. It's rather
> complicated program, but in that cost, it provides more eyes-pleasant
> results than fmt from the base, and has much more options. Because of
> its complexity I think pledge()'ing it makes sense.
> 
> I've tested it with english and utf8 texts - it behaves like before.
> 
> Tests, comments, objections?

Got private ok from the maintainer for that change.

[patch] textproc/par: use pledge()

[Mikhail]

Inlined patch adds support for pledge() in par formatter. It's rather
complicated program, but in that cost, it provides more eyes-pleasant
results than fmt from the base, and has much more options. Because of
its complexity I think pledge()'ing it makes sense.

I've tested it with english and utf8 texts - it behaves like before.

Tests, comments, objections?

diff --git a/textproc/par/Makefile b/textproc/par/Makefile
index 238299d2229..fb4da25b775 100644
--- a/textproc/par/Makefile
+++ b/textproc/par/Makefile
@@ -5,7 +5,7 @@ COMMENT=paragraph reflow for email
 VERSION=   1.52
 DISTNAME=  Par${VERSION:S/.//}
 PKGNAME=   par-${VERSION}
-REVISION=  1
+REVISION=  2
 CATEGORIES=textproc
 FIX_EXTRACT_PERMISSIONS=Yes
 
diff --git a/textproc/par/patches/patch-par_c b/textproc/par/patches/patch-par_c
new file mode 100644
index 000..4e33f79063a
--- /dev/null
+++ b/textproc/par/patches/patch-par_c
@@ -0,0 +1,25 @@
+Index: par.c
+--- par.c.orig
 par.c
+@@ -20,6 +20,7 @@
+ #include 
+ #include 
+ #include 
++#include 
+ 
+ #undef NULL
+ #define NULL ((void *) 0)
+@@ -730,6 +731,13 @@ int main(int argc, const char * const *argv)
+ /* Set the current locale from the environment: */
+ 
+   setlocale(LC_ALL,"");
++
++/* setlocale() needs "rpath", so do the syscall after it */
++
++  if (pledge("stdio", NULL) == -1) {
++wcscpy(errmsg, L"pledge\n");
++goto parcleanup;
++  }
+ 
+ /* Process environment variables: */
+ 

errors on 'pkg_add -u' after 7.0/amd64 upgrade

[Mikhail]

Hello, I was suggested to mail these errors to the list, so they can be
cleaned up:

cdparanoia-3.a9.8p4->3.a9.8p4: ok   
   
chromium-93.0.4577.82:libxkbcommon-1.1.0->1.3.0: ok 
   
install-info: warning: no entries found for `/usr/local/info/gpgrt.info'; 
nothing deleted  
install-info: menu item `libgpg-error' already exists, for file `gnupg'
system(/usr/bin/install-info, --info-dir=/usr/local/info, --, 
/usr/local/info/gpgrt.info) failed: exit(1)  
chromium-93.0.4577.82:libgpg-error-1.42->1.42: ok
[...]
chromium-93.0.4577.82:desktop-file-utils-0.26->0.26: ok
gtk+3-3.24.28p1->3.24.30 forward dependencies:
| Dependency of gtk+3-cups-3.24.28 on gtk+3-=3.24.28 doesn't match
Merging gtk+3-cups-3.24.28->3.24.30 (ok)
chromium-93.0.4577.82:gtk+3-3.24.28p1+gtk+3-cups-3.24.28->gtk+3+gtk+3-cups-3.24.30:
 ok

Re: net/epic4 update

[Mikhail]

On Thu, Sep 16, 2021 at 12:18:36PM +0300, Mikhail wrote:
> On Wed, Sep 15, 2021 at 11:48:18PM -0400, Daniel Dickman wrote:
> > On Tue, Sep 14, 2021 at 6:39 AM Mikhail  wrote:
> > >
> > > On Mon, Sep 13, 2021 at 09:34:54PM +0300, Mikhail wrote:
> > > > Hello, this is update for net/epic4 port from 2.10.5 to 2.10.10.
> > > >
> > > > patch-include_irc_h and patch-source_irc_c were incorporated upstream
> > > > and should be rm'ed
> > > >
> > >
> > > On IRC I was advised to remove REVISION, new patch is inline.
> > >
> > > The maintainer has been contacted, seem he ignores the updates.
> > 
> > sometimes people take vacations or life comes up. I'd say wait at
> > least a week or two to see if they will reply.
> > 
> > If no reply in a week or two, they could be removed.
> 
> He was contacted in 2019, he replied in 2020 and the reply was that he
> would update the port, but he never did.
> 
> Today the mail server reports that there is no such email address.
> 
> New patch with MAINTAINER removed.

ping

diff --git a/net/epic4/Makefile b/net/epic4/Makefile
index 4fab14b1dc7..63f43c6a867 100644
--- a/net/epic4/Makefile
+++ b/net/epic4/Makefile
@@ -2,18 +2,15 @@
 
 COMMENT=   (E)nhanced (P)rogrammable (I)RC-II (C)lient
 
-VERSION=   2.10.5
-REVISION=  2
+VERSION=   2.10.10
 HELP_DATE= 20050315
 DISTNAME=  epic4-${VERSION}
 CATEGORIES=net
 MASTER_SITES=  http://ftp.epicsol.org/pub/epic/EPIC4-PRODUCTION/
-DISTFILES= epic4-${VERSION}.tar.bz2 epic4-help-${HELP_DATE}.tar.bz2
+DISTFILES= epic4-${VERSION}.tar.xz epic4-help-${HELP_DATE}.tar.bz2
 
 HOMEPAGE=  http://www.epicsol.org/
 
-MAINTAINER=Adam Jeanguenat 
-
 # BSD
 PERMIT_PACKAGE=Yes
 
diff --git a/net/epic4/distinfo b/net/epic4/distinfo
index bcabd3b06db..b00b971e5d9 100644
--- a/net/epic4/distinfo
+++ b/net/epic4/distinfo
@@ -1,4 +1,4 @@
-SHA256 (epic4-2.10.5.tar.bz2) = /KexeIveUmh/0BwzxedNDhb8xlanazh94YUE7adk/4A=
+SHA256 (epic4-2.10.10.tar.xz) = 0SJxvL/YJ+nnWcMrumDs6AWul40z7ZHZIH3kNtBx+8U=
 SHA256 (epic4-help-20050315.tar.bz2) = 
p7cCbs/ACrcEDvXkNdcv00fUj6sShyLU4hPboZTNW74=
-SIZE (epic4-2.10.5.tar.bz2) = 636364
+SIZE (epic4-2.10.10.tar.xz) = 587056
 SIZE (epic4-help-20050315.tar.bz2) = 238390

Re: net/epic4 update

[Mikhail]

On Wed, Sep 15, 2021 at 11:48:18PM -0400, Daniel Dickman wrote:
> On Tue, Sep 14, 2021 at 6:39 AM Mikhail  wrote:
> >
> > On Mon, Sep 13, 2021 at 09:34:54PM +0300, Mikhail wrote:
> > > Hello, this is update for net/epic4 port from 2.10.5 to 2.10.10.
> > >
> > > patch-include_irc_h and patch-source_irc_c were incorporated upstream
> > > and should be rm'ed
> > >
> >
> > On IRC I was advised to remove REVISION, new patch is inline.
> >
> > The maintainer has been contacted, seem he ignores the updates.
> 
> sometimes people take vacations or life comes up. I'd say wait at
> least a week or two to see if they will reply.
> 
> If no reply in a week or two, they could be removed.

He was contacted in 2019, he replied in 2020 and the reply was that he
would update the port, but he never did.

Today the mail server reports that there is no such email address.

New patch with MAINTAINER removed.

diff --git a/net/epic4/Makefile b/net/epic4/Makefile
index 4fab14b1dc7..63f43c6a867 100644
--- a/net/epic4/Makefile
+++ b/net/epic4/Makefile
@@ -2,18 +2,15 @@
 
 COMMENT=   (E)nhanced (P)rogrammable (I)RC-II (C)lient
 
-VERSION=   2.10.5
-REVISION=  2
+VERSION=   2.10.10
 HELP_DATE= 20050315
 DISTNAME=  epic4-${VERSION}
 CATEGORIES=net
 MASTER_SITES=  http://ftp.epicsol.org/pub/epic/EPIC4-PRODUCTION/
-DISTFILES= epic4-${VERSION}.tar.bz2 epic4-help-${HELP_DATE}.tar.bz2
+DISTFILES= epic4-${VERSION}.tar.xz epic4-help-${HELP_DATE}.tar.bz2
 
 HOMEPAGE=  http://www.epicsol.org/
 
-MAINTAINER=Adam Jeanguenat 
-
 # BSD
 PERMIT_PACKAGE=Yes
 
diff --git a/net/epic4/distinfo b/net/epic4/distinfo
index bcabd3b06db..b00b971e5d9 100644
--- a/net/epic4/distinfo
+++ b/net/epic4/distinfo
@@ -1,4 +1,4 @@
-SHA256 (epic4-2.10.5.tar.bz2) = /KexeIveUmh/0BwzxedNDhb8xlanazh94YUE7adk/4A=
+SHA256 (epic4-2.10.10.tar.xz) = 0SJxvL/YJ+nnWcMrumDs6AWul40z7ZHZIH3kNtBx+8U=
 SHA256 (epic4-help-20050315.tar.bz2) = 
p7cCbs/ACrcEDvXkNdcv00fUj6sShyLU4hPboZTNW74=
-SIZE (epic4-2.10.5.tar.bz2) = 636364
+SIZE (epic4-2.10.10.tar.xz) = 587056
 SIZE (epic4-help-20050315.tar.bz2) = 238390

Re: net/epic5 new port

[Mikhail]

On Mon, Sep 13, 2021 at 10:51:30PM +0300, Mikhail wrote:
> Extremely customizable IRC client, evolution of net/epic4. 

Updated port with REVISION removed.


epic5.tar.gz
Description: application/tar-gz

Re: net/epic4 update

[Mikhail]

On Mon, Sep 13, 2021 at 09:34:54PM +0300, Mikhail wrote:
> Hello, this is update for net/epic4 port from 2.10.5 to 2.10.10.
> 
> patch-include_irc_h and patch-source_irc_c were incorporated upstream
> and should be rm'ed
> 

On IRC I was advised to remove REVISION, new patch is inline.

The maintainer has been contacted, seem he ignores the updates.


diff --git a/net/epic4/Makefile b/net/epic4/Makefile
index 4fab14b1dc7..46b792ee41f 100644
--- a/net/epic4/Makefile
+++ b/net/epic4/Makefile
@@ -2,13 +2,12 @@
 
 COMMENT=   (E)nhanced (P)rogrammable (I)RC-II (C)lient
 
-VERSION=   2.10.5
-REVISION=  2
+VERSION=   2.10.10
 HELP_DATE= 20050315
 DISTNAME=  epic4-${VERSION}
 CATEGORIES=net
 MASTER_SITES=  http://ftp.epicsol.org/pub/epic/EPIC4-PRODUCTION/
-DISTFILES= epic4-${VERSION}.tar.bz2 epic4-help-${HELP_DATE}.tar.bz2
+DISTFILES= epic4-${VERSION}.tar.xz epic4-help-${HELP_DATE}.tar.bz2
 
 HOMEPAGE=  http://www.epicsol.org/
 
diff --git a/net/epic4/distinfo b/net/epic4/distinfo
index bcabd3b06db..b00b971e5d9 100644
--- a/net/epic4/distinfo
+++ b/net/epic4/distinfo
@@ -1,4 +1,4 @@
-SHA256 (epic4-2.10.5.tar.bz2) = /KexeIveUmh/0BwzxedNDhb8xlanazh94YUE7adk/4A=
+SHA256 (epic4-2.10.10.tar.xz) = 0SJxvL/YJ+nnWcMrumDs6AWul40z7ZHZIH3kNtBx+8U=
 SHA256 (epic4-help-20050315.tar.bz2) = 
p7cCbs/ACrcEDvXkNdcv00fUj6sShyLU4hPboZTNW74=
-SIZE (epic4-2.10.5.tar.bz2) = 636364
+SIZE (epic4-2.10.10.tar.xz) = 587056
 SIZE (epic4-help-20050315.tar.bz2) = 238390

net/epic5 new port

[Mikhail]

Extremely customizable IRC client, evolution of net/epic4. 


epic5.tar.gz
Description: application/tar-gz

net/epic4 update

[Mikhail]

Hello, this is update for net/epic4 port from 2.10.5 to 2.10.10.

patch-include_irc_h and patch-source_irc_c were incorporated upstream
and should be rm'ed


diff --git a/net/epic4/Makefile b/net/epic4/Makefile
index 4fab14b1dc7..9b8e93e3448 100644
--- a/net/epic4/Makefile
+++ b/net/epic4/Makefile
@@ -2,13 +2,13 @@
 
 COMMENT=   (E)nhanced (P)rogrammable (I)RC-II (C)lient
 
-VERSION=   2.10.5
-REVISION=  2
+VERSION=   2.10.10
+REVISION=  0
 HELP_DATE= 20050315
 DISTNAME=  epic4-${VERSION}
 CATEGORIES=net
 MASTER_SITES=  http://ftp.epicsol.org/pub/epic/EPIC4-PRODUCTION/
-DISTFILES= epic4-${VERSION}.tar.bz2 epic4-help-${HELP_DATE}.tar.bz2
+DISTFILES= epic4-${VERSION}.tar.xz epic4-help-${HELP_DATE}.tar.bz2
 
 HOMEPAGE=  http://www.epicsol.org/
 
diff --git a/net/epic4/distinfo b/net/epic4/distinfo
index bcabd3b06db..b00b971e5d9 100644
--- a/net/epic4/distinfo
+++ b/net/epic4/distinfo
@@ -1,4 +1,4 @@
-SHA256 (epic4-2.10.5.tar.bz2) = /KexeIveUmh/0BwzxedNDhb8xlanazh94YUE7adk/4A=
+SHA256 (epic4-2.10.10.tar.xz) = 0SJxvL/YJ+nnWcMrumDs6AWul40z7ZHZIH3kNtBx+8U=
 SHA256 (epic4-help-20050315.tar.bz2) = 
p7cCbs/ACrcEDvXkNdcv00fUj6sShyLU4hPboZTNW74=
-SIZE (epic4-2.10.5.tar.bz2) = 636364
+SIZE (epic4-2.10.10.tar.xz) = 587056
 SIZE (epic4-help-20050315.tar.bz2) = 238390