WIP: net/liblcrq - plist not correct
Hi, I would be grateful if someone can explain what I am not understanding about 'make update-plist'. I have this (attached) port where PLIST is always empty and I don't know why. $ make update-plist ===> Updating plist for liblcrq-0.1.2 Reading existing plist for liblcrq-0.1.2 Scanning /usr/ports/pobj/liblcrq-0.1.2/fake-amd64 Removing .debug artefacts Figuring out tie points Tieing loose objects Copying objects Can't put into any plist (no applicable prefix): /usr/ports /usr/ports/pobj /usr/ports/pobj/liblcrq-0.1.2 /usr/ports/pobj/liblcrq-0.1.2/fake-amd64 /usr/ports/pobj/liblcrq-0.1.2/fake-amd64/usr /usr/ports/pobj/liblcrq-0.1.2/fake-amd64/usr/local /usr/ports/pobj/liblcrq-0.1.2/fake-amd64/usr/local/include /usr/ports/pobj/liblcrq-0.1.2/fake-amd64/usr/local/include/lcrq.h /usr/ports/pobj/liblcrq-0.1.2/fake-amd64/usr/local/lib /usr/ports/pobj/liblcrq-0.1.2/fake-amd64/usr/local/lib/liblcrq.so /usr/ports/pobj/liblcrq-0.1.2/fake-amd64/usr/local/lib/liblcrq.so.0 /usr/ports/pobj/liblcrq-0.1.2/fake-amd64/usr/local/lib/liblcrq.so.0.0 /usr/ports/pobj/liblcrq-0.1.2/fake-amd64/usr/local/share /usr/ports/pobj/liblcrq-0.1.2/fake-amd64/usr/local/share/man /usr/ports/pobj/liblcrq-0.1.2/fake-amd64/usr/local/share/man/man3 /usr/ports/pobj/liblcrq-0.1.2/fake-amd64/usr/local/share/man/man3/rq_Al.3 /usr/ports/pobj/liblcrq-0.1.2/fake-amd64/usr/local/share/man/man3/rq_F.3 /usr/ports/pobj/liblcrq-0.1.2/fake-amd64/usr/local/share/man/man3/rq_K.3 /usr/ports/pobj/liblcrq-0.1.2/fake-amd64/usr/local/share/man/man3/rq_KP.3 /usr/ports/pobj/liblcrq-0.1.2/fake-amd64/usr/local/share/man/man3/rq_N.3 /usr/ports/pobj/liblcrq-0.1.2/fake-amd64/usr/local/share/man/man3/rq_T.3 /usr/ports/pobj/liblcrq-0.1.2/fake-amd64/usr/local/share/man/man3/rq_Z.3 /usr/ports/pobj/liblcrq-0.1.2/fake-amd64/usr/local/share/man/man3/rq_decode.3 /usr/ports/pobj/liblcrq-0.1.2/fake-amd64/usr/local/share/man/man3/rq_encode.3 /usr/ports/pobj/liblcrq-0.1.2/fake-amd64/usr/local/share/man/man3/rq_free.3 /usr/ports/pobj/liblcrq-0.1.2/fake-amd64/usr/local/share/man/man3/rq_init.3 /usr/ports/pobj/liblcrq-0.1.2/fake-amd64/usr/local/share/man/man3/rq_pid2esi.3 /usr/ports/pobj/liblcrq-0.1.2/fake-amd64/usr/local/share/man/man3/rq_pid2sbn.3 /usr/ports/pobj/liblcrq-0.1.2/fake-amd64/usr/local/share/man/man3/rq_pidset.3 /usr/ports/pobj/liblcrq-0.1.2/fake-amd64/usr/local/share/man/man3/rq_pidsetesi.3 /usr/ports/pobj/liblcrq-0.1.2/fake-amd64/usr/local/share/man/man3/rq_pidsetsbn.3 /usr/ports/pobj/liblcrq-0.1.2/fake-amd64/usr/local/share/man/man3/rq_query.3 /usr/ports/pobj/liblcrq-0.1.2/fake-amd64/usr/local/share/man/man3/rq_symbol.3 /usr/ports/pobj/liblcrq-0.1.2/fake-amd64/usr/local/share/man/man7 /usr/ports/pobj/liblcrq-0.1.2/fake-amd64/usr/local/share/man/man7/lcrq.7 Looking for unregistered conflicts $ ls -l pkg/PLIST -rw-r--r-- 1 holsta wsrc 0 Apr 10 08:38 pkg/PLIST -- Alex Holst liblcrq.tgz Description: application/gzip
Packaging non-hackage Haskell
Hi,
I would be grateful for any clues on how to package a Haskell program that has
version 9.0.x on hackage, but the latest version on GitHub is 11.2.x and the
project appears to not be interested in hackage going forward. This is what I
have so far.
If I use the 9.0.1 line, I can at least do 'make extract'.
┆ COMMENT = REST API for any Postgres database
┆
┆ MODCABAL_STEM = postgrest
┆ MODCABAL_VERSION= 11.2.0
┆ #MODCABAL_VERSION = 9.0.1
┆ MODCABAL_EXECUTABLE = postgrest
┆ PKGNAME = ${DISTNAME:L}
┆ CATEGORIES = www mystuff
┆ HOMEPAGE= https://postgrest.org/
┆
┆ # MIT
┆ PERMIT_PACKAGE = Yes
┆
┆ MODULES = devel/cabal
┆
┆ do-build:
┆ cabal v2-build
┆
┆ .include
--
Alex Holst
Re: Asterisk on Octeon
On Mon, Sep 11, 2023 at 11:55:05AM +0100, Stuart Henderson wrote: > > Has anyone had any success running Asterisk on Octeon (in my case, an > > EdgeRouter 6P, running OpenBSD 7.3)? > > [...] > No idea what's up on Octeon, but you could try building it with gcc > to check if that makes any difference. Thanks for the idea. I gave this a go, but the result is still the same. Alex
Asterisk on Octeon
Hi all, Has anyone had any success running Asterisk on Octeon (in my case, an EdgeRouter 6P, running OpenBSD 7.3)? If I try to build the port, it fails in the same way as the automated package builds, i.e.: http://build-failures.rhaalovely.net/mips64/2023-08-29/telephony/asterisk/20.log I don't know what's going on there, but if I run "make menuselect" and disable res_geolocation (and remove the corresponding bits from pkg/PLIST-main), it builds fine. Note that I'm building with all the no_* flavours enabled. However, some seconds after startup, it segfaults. I'm pretty sure this is down to the PJSIP bits, because if I stop Asterisk loading those, it seems to run fine. For my use case, however, I definitely need SIP. I've tried all three available Asterisk versions (16, 18, 20), and the result is exactly the same in all three cases. I could probably run Asterisk 16 which still has the old chan_sip module (removed in 18 and 20), but this seems like a dead-end solution. At this point, I'm just about ready to give up and run Asterisk elsewhere and a SIP proxy on my EdgeRouter, but I thought I'd ask in case anyone else has managed to find a way to make it work. Many thanks, Alex
Re: [UPDATE] misc/screen (4.9.0 => 4.9.1)
Thanks for review. Here is the new patch.
On Sat, Aug 19, 2023 at 12:40 AM Stuart Henderson
wrote:
> Something's wrong with your diff, it doesn't apply with patch.
>
> Rather than just removing from plist, please either @comment the file
> in plist so it doesn't get readded, or maybe better add a post-install
> target rm'ing the file with a comment saying why.
>
>
> On 2023/08/18 22:44, Alex Naumov wrote:
> > Greetings,
> >
> > This patch updates GNU Screen to version 4.9.1. Released yesterday.
> Please
> > review/test it.
> >
> > Screen is a full-screen window manager that multiplexes a physical
> terminal
> > between several processes (typically interactive shells).
> >
> > 'portcheck', 'port-lib-depends-check' and 'update-plist' returns 0.
> > Updated and tested on x86_64 and aarch64.
> >
> > All tests are OK:
> > * 'make test'
> > * manually started the screen and did some basic operation with it.
> >
> > I removed:
> > Info-file (texinfo, manpage still there) from the list of files
> (pkg/PLIST)
> > because it seems broken in this release.
> >
> > ChangeLog for 4.9.1:
> > * Support stop/parity bits on serial port
> > * Add needed system headers in checks and return values for implicit
> > function declarations
> > * Fixes:
> > - Avoid zombies after shell exit
> > - Missed signal sending permission check on failed query messages
> > (CVE-2023-24626)
> > - manpage fixes
> > - source code fixes during cleanup
> > - UTF-8 encoding can emit invalid UTF-8 sequences for out of range
> unicode
> > values
> >
> >
> > Cheers,
> > Alexander Naumov
>
> > Index: Makefile
> > ===
> > RCS file: /cvs/ports/misc/screen/Makefile,v
> > retrieving revision 1.77
> > diff -u -p -u -p -r1.77 Makefile
> > --- Makefile 11 Mar 2022 19:38:20 - 1.77
> > +++ Makefile 18 Aug 2023 19:58:48 -
> > @@ -1,10 +1,12 @@
> > COMMENT= multi-screen window manager
> >
> > -DISTNAME=screen-4.9.0
> > +DISTNAME=screen-4.9.1
> > CATEGORIES= misc
> > MASTER_SITES=${MASTER_SITE_GNU:=screen/}
> >
> > HOMEPAGE=https://www.gnu.org/software/screen/
> >
> > # GPLv3+
> > PERMIT_PACKAGE= Yes
> > Index: distinfo
> > ===
> > RCS file: /cvs/ports/misc/screen/distinfo,v
> > retrieving revision 1.14
> > diff -u -p -u -p -r1.14 distinfo
> > --- distinfo 5 Feb 2022 11:57:36 - 1.14
> > +++ distinfo 18 Aug 2023 19:58:48 -
> > @@ -1,2 +1,2 @@
> > -SHA256 (screen-4.9.0.tar.gz) =
> +TNSgbtNFTjtB433iiDC8506+aTpHFfQhCceAonHMPQ=
> > -SIZE (screen-4.9.0.tar.gz) = 798229
> > +SHA256 (screen-4.9.1.tar.gz) =
> Js7z48QlccDUhK1vrxEMXBUJH7+HKwb6eqR2bHQFrGk=
> > +SIZE (screen-4.9.1.tar.gz) = 1040785
> > Index: pkg/PLIST
> > ===
> > RCS file: /cvs/ports/misc/screen/pkg/PLIST,v
> > retrieving revision 1.25
> > diff -u -p -u -p -r1.25 PLIST
> > --- pkg/PLIST 11 Mar 2022 19:38:20 - 1.25
> > +++ pkg/PLIST 18 Aug 2023 19:58:48 -
> > @@ -1,5 +1,4 @@
> > @bin bin/screen
> > -@info info/screen.info
> > @man man/man1/screen.1
> > share/examples/screen/
> > share/examples/screen/screenrc
>
Index: Makefile
===
RCS file: /cvs/ports/misc/screen/Makefile,v
retrieving revision 1.77
diff -u -p -u -p -r1.77 Makefile
--- Makefile 11 Mar 2022 19:38:20 - 1.77
+++ Makefile 19 Aug 2023 00:50:16 -
@@ -1,6 +1,6 @@
COMMENT= multi-screen window manager
-DISTNAME= screen-4.9.0
+DISTNAME= screen-4.9.1
CATEGORIES= misc
MASTER_SITES= ${MASTER_SITE_GNU:=screen/}
@@ -38,5 +38,8 @@ post-install:
${INSTALL_DATA_DIR} ${PREFIX}/share/examples/screen
${INSTALL_DATA} ${WRKSRC}/etc/etcscreenrc \
${PREFIX}/share/examples/screen/screenrc
+
+ #screen 4.9.1 has broken info file
+ @rm ${PREFIX}/info/screen.info
.include
Index: distinfo
===
RCS file: /cvs/ports/misc/screen/distinfo,v
retrieving revision 1.14
diff -u -p -u -p -r1.14 distinfo
--- distinfo 5 Feb 2022 11:57:36 - 1.14
+++ distinfo 19 Aug 2023 00:50:16 -
@@ -1,2 +1,2 @@
-SHA256 (screen-4.9.0.tar.gz) = +TNSgbtNFTjtB433iiDC8506+aTpHFfQhCceAonHMPQ=
-SIZE (screen-4.9.0.tar.gz) = 798229
+SHA256 (screen-4.9.1.tar.gz) = Js7z48QlccDUhK1vrxEMXBUJH7+HKwb6eqR2bHQFrGk=
+SIZE (screen-4.9.1.tar.gz) = 1040785
[UPDATE] misc/screen (4.9.0 => 4.9.1)
Greetings,
This patch updates GNU Screen to version 4.9.1. Released yesterday. Please
review/test it.
Screen is a full-screen window manager that multiplexes a physical terminal
between several processes (typically interactive shells).
'portcheck', 'port-lib-depends-check' and 'update-plist' returns 0.
Updated and tested on x86_64 and aarch64.
All tests are OK:
* 'make test'
* manually started the screen and did some basic operation with it.
I removed:
Info-file (texinfo, manpage still there) from the list of files (pkg/PLIST)
because it seems broken in this release.
ChangeLog for 4.9.1:
* Support stop/parity bits on serial port
* Add needed system headers in checks and return values for implicit
function declarations
* Fixes:
- Avoid zombies after shell exit
- Missed signal sending permission check on failed query messages
(CVE-2023-24626)
- manpage fixes
- source code fixes during cleanup
- UTF-8 encoding can emit invalid UTF-8 sequences for out of range unicode
values
Cheers,
Alexander Naumov
Index: Makefile
===
RCS file: /cvs/ports/misc/screen/Makefile,v
retrieving revision 1.77
diff -u -p -u -p -r1.77 Makefile
--- Makefile 11 Mar 2022 19:38:20 - 1.77
+++ Makefile 18 Aug 2023 19:58:48 -
@@ -1,10 +1,12 @@
COMMENT= multi-screen window manager
-DISTNAME= screen-4.9.0
+DISTNAME= screen-4.9.1
CATEGORIES= misc
MASTER_SITES= ${MASTER_SITE_GNU:=screen/}
HOMEPAGE= https://www.gnu.org/software/screen/
# GPLv3+
PERMIT_PACKAGE= Yes
Index: distinfo
===
RCS file: /cvs/ports/misc/screen/distinfo,v
retrieving revision 1.14
diff -u -p -u -p -r1.14 distinfo
--- distinfo 5 Feb 2022 11:57:36 - 1.14
+++ distinfo 18 Aug 2023 19:58:48 -
@@ -1,2 +1,2 @@
-SHA256 (screen-4.9.0.tar.gz) = +TNSgbtNFTjtB433iiDC8506+aTpHFfQhCceAonHMPQ=
-SIZE (screen-4.9.0.tar.gz) = 798229
+SHA256 (screen-4.9.1.tar.gz) = Js7z48QlccDUhK1vrxEMXBUJH7+HKwb6eqR2bHQFrGk=
+SIZE (screen-4.9.1.tar.gz) = 1040785
Index: pkg/PLIST
===
RCS file: /cvs/ports/misc/screen/pkg/PLIST,v
retrieving revision 1.25
diff -u -p -u -p -r1.25 PLIST
--- pkg/PLIST 11 Mar 2022 19:38:20 - 1.25
+++ pkg/PLIST 18 Aug 2023 19:58:48 -
@@ -1,5 +1,4 @@
@bin bin/screen
-@info info/screen.info
@man man/man1/screen.1
share/examples/screen/
share/examples/screen/screenrc
[UPDATE] misc/screen (4.8.0 => 4.9.0)
Greetings,
This patch updates GNU Screen to version 4.9.0.
'portcheck', 'port-lib-depends-check' and 'update-plist' returns 0.
Updated and tested on aarch64 (SoftIron Overdrive 1000).
All tests are OK:
* 'make test'
* manually started a screen(1) and did some basic operation with it.
I removed:
* patches/patch-osdef_h_in because it's in upstream
* patches/patch-acconfig_h upstream includes fix for CVE-2021-26937, so I
"defined" UTF-8 back
I also updated patches/patch-pty_c because of a typo in upstream...
Changelog:
Version 4.9.0 (30/01/2022):
* Hardstatus option for used encoding (escape string '%e')
* OpenBSD uses native openpty() from its util.h
* Fixes:
- fix combining char handling that could lead to a segfault
- CVE-2021-26937: possible denial of service via a crafted UTF-8 character
sequence (bug #60030)
- make screen exit code be 0 when checking --help
- session names limit is 80 symbols (bug #61534)
- option -X ignores specified user in multiuser env (bug #37437)
- a lot of reformations/fixes/cleanups (man page and source code)
Cheers,
Alexander Naumov
Index: Makefile
===
RCS file: /cvs/ports/misc/screen/Makefile,v
retrieving revision 1.75
diff -u -p -u -p -r1.75 Makefile
--- Makefile 9 Feb 2021 20:17:22 - 1.75
+++ Makefile 2 Feb 2022 21:58:36 -
@@ -2,7 +2,7 @@
COMMENT= multi-screen window manager
-DISTNAME= screen-4.8.0
+DISTNAME= screen-4.9.0
REVISION= 0
CATEGORIES= misc
MASTER_SITES= ${MASTER_SITE_GNU:=screen/}
Index: distinfo
===
RCS file: /cvs/ports/misc/screen/distinfo,v
retrieving revision 1.13
diff -u -p -u -p -r1.13 distinfo
--- distinfo 6 Feb 2020 16:17:20 - 1.13
+++ distinfo 2 Feb 2022 21:58:36 -
@@ -1,2 +1,2 @@
-SHA256 (screen-4.8.0.tar.gz) = bhGxPYSJkl/eJd+wk1v27XH560fv8jOhgeB4/eVlWqE=
-SIZE (screen-4.8.0.tar.gz) = 854854
+SHA256 (screen-4.9.0.tar.gz) = +TNSgbtNFTjtB433iiDC8506+aTpHFfQhCceAonHMPQ=
+SIZE (screen-4.9.0.tar.gz) = 798229
Index: patches/patch-acconfig_h
===
RCS file: patches/patch-acconfig_h
diff -N patches/patch-acconfig_h
--- patches/patch-acconfig_h 9 Feb 2021 20:17:22 - 1.1
+++ /dev/null 1 Jan 1970 00:00:00 -
@@ -1,16 +0,0 @@
-$OpenBSD: patch-acconfig_h,v 1.1 2021/02/09 20:17:22 sthen Exp $
-
-https://lists.gnu.org/archive/html/screen-devel/2021-02/msg0.html
-
-Index: acconfig.h
acconfig.h.orig
-+++ acconfig.h
-@@ -157,7 +157,7 @@
- # define FONT
- # define DW_CHARS
- # define ENCODINGS
--# define UTF8
-+// # define UTF8
- # define COLORS16
- # define ZMODEM
- # define BLANKER_PRG
Index: patches/patch-osdef_h_in
===
RCS file: patches/patch-osdef_h_in
diff -N patches/patch-osdef_h_in
--- patches/patch-osdef_h_in 5 Sep 2019 17:35:06 - 1.1
+++ /dev/null 1 Jan 1970 00:00:00 -
@@ -1,14 +0,0 @@
-$OpenBSD: patch-osdef_h_in,v 1.1 2019/09/05 17:35:06 sthen Exp $
-
-Index: osdef.h.in
osdef.h.in.orig
-+++ osdef.h.in
-@@ -111,7 +111,7 @@ extern int setsid __P((void));
- extern int setpgid __P((int, int));
- extern int tcsetpgrp __P((int, int));
- #endif
--extern int ioctl __P((int, int, char *));
-+extern int ioctl __P((int, unsigned long, char *));
-
- extern int kill __P((int, int));
-
Index: patches/patch-pty_c
===
RCS file: /cvs/ports/misc/screen/patches/patch-pty_c,v
retrieving revision 1.4
diff -u -p -u -p -r1.4 patch-pty_c
--- patches/patch-pty_c 5 Sep 2019 17:35:06 - 1.4
+++ patches/patch-pty_c 2 Feb 2022 21:58:36 -
@@ -1,15 +1,14 @@
-$OpenBSD: patch-pty_c,v 1.4 2019/09/05 17:35:06 sthen Exp $
-
-for openpty()
+$OpenBSD: patch-pty_c,v 1.5 2022/02/02 17:36:07 anaumov Exp $
Index: pty.c
--- pty.c.orig
+++ pty.c
-@@ -30,6 +30,7 @@
- #include
- #include
+@@ -32,7 +32,7 @@
#include
-+#include
+
+ #if defined(__OpenBSD__)
+-#include /* for openpty() */
++#include /* for openpty() */
+ #endif
#include "config.h"
- #include "screen.h"
NEW: graphics/basis_universal
Here is version 1.15 of Bionominal's supercompressed GPU texture compression system. >From the DESCR: Basis Universal is a "supercompressed" GPU texture compression system that outputs a highly compressed intermediate file format (.basis) that can be quickly transcoded to a very wide variety of GPU compressed and uncompressed pixel formats: ASTC 4x4 L/LA/RGB/RGBA, PVRTC1 4bpp RGB/RGBA, PVRTC2 RGB/RGBA, BC7 mode 6 RGB, BC7 mode 5 RGB/RGBA, BC1-5 RGB/RGBA/X/XY, ETC1 RGB, ETC2 RGBA, ATC RGB/RGBA, ETC2 EAC R11 and RG11, FXT1 RGB, and uncompressed raster image formats /565/. -- Alex Holst basis_universal-1.15.tgz Description: Binary data
Re: NEW: devel/tea - cli client for Gitea
> Tests pass and runs OK on amd64. Other tests welcome. Felix Kronlage-Dammers has tested this on arm64. Any additional tests or input? Otherwise, this seems ready for commit. -- Alex Holst
Re: UPDATE: syncthing-1.17.0
> Tests passing on amd64. I'll be use testing it over the next few days. > > Commments or OKs? It has been running for 24 hours here without issue (on amd64). -- Alex Holst
NEW: devel/tea - cli client for Gitea
tea is a productivity helper for Gitea. It can be used to manage most entities on one or multiple Gitea instances and provides local helpers like 'tea pull checkout'. tea makes use of context provided by the repository in $PWD if available, but is still usable independently of $PWD. Configuration is persisted in $XDG_CONFIG_HOME/tea. Tests pass and runs OK on amd64. Other tests welcome. -- Alex Holst tea-0.7.0.tgz Description: Binary data
Re: NEW: devel/skalibs and sysutils/execline
Ping
On Thu, May 06, 2021 at 01:39:43PM +0200, Alex Raschi wrote:
> Ping
>
> New bugfix versions and etsh patch attached (skalibs-2.10.0.3 and
> execline-2.8.0.1).
>
> Index: pkg/PLIST
> ===
> RCS file: /cvs/ports/shells/etsh/pkg/PLIST,v
> retrieving revision 1.2
> diff -u -p -r1.2 PLIST
> --- pkg/PLIST 30 Mar 2019 18:14:32 - 1.2
> +++ pkg/PLIST 6 May 2021 09:30:23 -
> @@ -1,5 +1,6 @@
> @comment $OpenBSD: PLIST,v 1.2 2019/03/30 18:14:32 bcallah Exp $
> @conflict osh-*
> +@conflict execline-*
> @pkgpath shells/osh
> @shell bin/etsh
> @shell bin/tsh
>
> On Wed, Mar 31, 2021 at 03:35:40PM +0200, Alex Raschi wrote:
> > Ping
> >
> > On Thu, Mar 11, 2021 at 03:05:14PM +0100, Alex Raschi wrote:
> > > Ping
> > >
> > > Ports and patch reattached for convenience.
> > >
> > > On Mon, Feb 22, 2021 at 09:16:52PM +0100, Alex Raschi wrote:
> > > > On Mon, Feb 22, 2021 at 01:35:38PM +, Stuart Henderson wrote:
> > > > > On 2021/02/22 14:05, Alex Raschi wrote:
> > > > > > I attached the new versions of skalibs (2.10.0.2) and execline
> > > > > > (2.8.0.0), these fixes a few bugs and change backtick(1) options
> > > > > > slightly.
> > > > > >
> > > > > > I also attached a new port of the newly created mdoc(7) ports of the
> > > > > > execline HTML documentation. With this one i get:
> > > > > >
> > > > > > Warning: execline-man-pages-2.8.0.0.1 conflicts with etsh-5.4.0v0
> > > > > > (shells/etsh):/usr/local/man/man1/if.1
> > > > > >
> > > > > > However shells/etsh does not seem to provide a real if(1) command, i
> > > > > > checked the PLIST of etsh and the if command seems to be an internal
> > > > > > shell command (execline provides an if command but does not conflict
> > > > > > with etsh). Any suggestion to fix this?
> > > > >
> > > > > either register the conflict with @conflict markers (in both ports),
> > > > > or install docs to a different dir. conflict markers seems ok to me.
> > > > >
> > > > > it might be better to just include the manuals in the main package.
> > > > > you can use multiple DISTFILES.
> > > > >
> > > > > > As said in the previous emails i get these with execline too:
> > > > > >
> > > > > > in default FLAVOR: the following libraries in WANTLIB look like
> > > > > > masked by RUN_DEPENDS: skarnet
> > > > > > in FLAVOR "static": the following libraries in WANTLIB look like
> > > > > > masked by RUN_DEPENDS: skarnet
> > > > > >
> > > > > > I have also checked that these ports work with -fno-common.
> > > > > >
> > > > > > Any comments and/or OKs?
> > > > >
> > > > > SHARED_LIBS = execline2.8
> > > > > SHARED_LIBS = skarnet 2.10
> > > > >
> > > > > start with 0.0. if the build system doesn't produce a library with the
> > > > > right name to match this, patch or pass in via make(1) variables until
> > > > > it does.
> > > > >
> > > > > https://www.openbsd.org/faq/ports/specialtopics.html#SharedLibs
> > > > >
> > > > > @so lib/libexecline.so
> > > > > @lib lib/libexecline.so.${LIBexecline_VERSION}
> > > > > @bin lib/libexecline.so.2.8.0.0
> > > > >
> > > > > @so lib/libskarnet.so
> > > > > @lib lib/libskarnet.so.${LIBskarnet_VERSION}
> > > > > @bin lib/libskarnet.so.2.10.0.2
> > > > >
> > > > > there should just be "@lib lib/libxyz.so.${LIBxyz}" lines, no
> > > > > symlinks etc.
> > > > >
> > > > > these are probably what's responsible for portcheck's "masked by"
> > > > > warning.
> > > > >
> > > > > pkg/DESCR says "has no security issues"
> > > > >
> > > > > a bold claim! I don't think it's a good idea to include that bit.
> > > > >
> > > > > I would drop the static flavours unless there's a really good reason
> > > > > for it (usually "it's helpful to run in a chroot for a webserver").
> > > > >
> > > >
> > > > The reason for the static flavor is basically the same as for example
> > > > shells/dash: it can be really useful in a chroot since it acts
> > > > functionally the same as a shell. Anyway i will remove it in case.
> > > >
> > > > I modified the ports to match your suggestions, below there is the diff
> > > > to add @conflict to etsh. Thanks!
UPDATE: sysutils/simple-mtpfs
Hi,
Here is an update to simple-mtpfs to 0.4.0. The new version requires a
macro from devel/autoconf-archive and the two patches are upstream so
they can be removed.
Tested briefly with some rm/cp operations. More testing/feedback is
appreciated!
Index: Makefile
===
RCS file: /cvs/ports/sysutils/simple-mtpfs/Makefile,v
retrieving revision 1.12
diff -u -p -r1.12 Makefile
--- Makefile12 Jul 2019 20:49:51 - 1.12
+++ Makefile6 May 2021 09:27:19 -
@@ -2,12 +2,10 @@
COMMENT= MTP device filesystem
-V= 0.3.0
+V= 0.4.0
GH_ACCOUNT=phatina
GH_PROJECT=simple-mtpfs
-GH_TAGNAME=simple-mtpfs-${V}
-DISTNAME= ${GH_PROJECT}-0.3.0
-REVISION= 1
+GH_TAGNAME=v${V}
CATEGORIES=sysutils
@@ -21,6 +19,7 @@ COMPILER =base-clang ports-gcc
CONFIGURE_STYLE= autoreconf
+BUILD_DEPENDS= devel/autoconf-archive
LIB_DEPENDS= devel/libmtp
MAKE_FILE= makefile
Index: distinfo
===
RCS file: /cvs/ports/sysutils/simple-mtpfs/distinfo,v
retrieving revision 1.2
diff -u -p -r1.2 distinfo
--- distinfo7 Jan 2017 19:14:49 - 1.2
+++ distinfo6 May 2021 09:27:19 -
@@ -1,2 +1,2 @@
-SHA256 (simple-mtpfs-0.3.0.tar.gz) =
VVbK5EFCVLBx15zmVszoZrQv17pAzkgKv8O6TjV81JE=
-SIZE (simple-mtpfs-0.3.0.tar.gz) = 36655
+SHA256 (simple-mtpfs-0.4.0.tar.gz) =
HQEd8/oJrQpcCdSNhMA+bN34Y5CvnrTgwXgZPzLw4vw=
+SIZE (simple-mtpfs-0.4.0.tar.gz) = 36234
Index: patches/patch-src_simple-mtpfs-fuse_cpp
===
RCS file: patches/patch-src_simple-mtpfs-fuse_cpp
diff -N patches/patch-src_simple-mtpfs-fuse_cpp
--- patches/patch-src_simple-mtpfs-fuse_cpp 2 Jul 2015 21:31:44 -
1.1.1.1
+++ /dev/null 1 Jan 1970 00:00:00 -
@@ -1,12 +0,0 @@
-$OpenBSD: patch-src_simple-mtpfs-fuse_cpp,v 1.1.1.1 2015/07/02 21:31:44
ajacoutot Exp $
src/simple-mtpfs-fuse.cpp.orig Mon Jun 29 17:27:26 2015
-+++ src/simple-mtpfs-fuse.cpp Mon Jun 29 17:27:31 2015
-@@ -19,7 +19,7 @@
- #include
- extern "C" {
- # include
--# include
-+# include
- # include
- # include
- }
Index: patches/patch-src_simple-mtpfs-fuse_h
===
RCS file: patches/patch-src_simple-mtpfs-fuse_h
diff -N patches/patch-src_simple-mtpfs-fuse_h
--- patches/patch-src_simple-mtpfs-fuse_h 2 Jul 2015 21:31:44 -
1.1.1.1
+++ /dev/null 1 Jan 1970 00:00:00 -
@@ -1,12 +0,0 @@
-$OpenBSD: patch-src_simple-mtpfs-fuse_h,v 1.1.1.1 2015/07/02 21:31:44
ajacoutot Exp $
src/simple-mtpfs-fuse.h.orig Mon Jun 29 17:26:18 2015
-+++ src/simple-mtpfs-fuse.hMon Jun 29 17:26:25 2015
-@@ -23,7 +23,7 @@
- #include
- #include
- extern "C" {
--# include
-+# include
- }
- #include "simple-mtpfs-mtp-device.h"
- #include "simple-mtpfs-tmp-files-pool.h"
Re: NEW: devel/skalibs and sysutils/execline
Ping
New bugfix versions and etsh patch attached (skalibs-2.10.0.3 and
execline-2.8.0.1).
Index: pkg/PLIST
===
RCS file: /cvs/ports/shells/etsh/pkg/PLIST,v
retrieving revision 1.2
diff -u -p -r1.2 PLIST
--- pkg/PLIST 30 Mar 2019 18:14:32 - 1.2
+++ pkg/PLIST 6 May 2021 09:30:23 -
@@ -1,5 +1,6 @@
@comment $OpenBSD: PLIST,v 1.2 2019/03/30 18:14:32 bcallah Exp $
@conflict osh-*
+@conflict execline-*
@pkgpath shells/osh
@shell bin/etsh
@shell bin/tsh
On Wed, Mar 31, 2021 at 03:35:40PM +0200, Alex Raschi wrote:
> Ping
>
> On Thu, Mar 11, 2021 at 03:05:14PM +0100, Alex Raschi wrote:
> > Ping
> >
> > Ports and patch reattached for convenience.
> >
> > On Mon, Feb 22, 2021 at 09:16:52PM +0100, Alex Raschi wrote:
> > > On Mon, Feb 22, 2021 at 01:35:38PM +, Stuart Henderson wrote:
> > > > On 2021/02/22 14:05, Alex Raschi wrote:
> > > > > I attached the new versions of skalibs (2.10.0.2) and execline
> > > > > (2.8.0.0), these fixes a few bugs and change backtick(1) options
> > > > > slightly.
> > > > >
> > > > > I also attached a new port of the newly created mdoc(7) ports of the
> > > > > execline HTML documentation. With this one i get:
> > > > >
> > > > > Warning: execline-man-pages-2.8.0.0.1 conflicts with etsh-5.4.0v0
> > > > > (shells/etsh):/usr/local/man/man1/if.1
> > > > >
> > > > > However shells/etsh does not seem to provide a real if(1) command, i
> > > > > checked the PLIST of etsh and the if command seems to be an internal
> > > > > shell command (execline provides an if command but does not conflict
> > > > > with etsh). Any suggestion to fix this?
> > > >
> > > > either register the conflict with @conflict markers (in both ports),
> > > > or install docs to a different dir. conflict markers seems ok to me.
> > > >
> > > > it might be better to just include the manuals in the main package.
> > > > you can use multiple DISTFILES.
> > > >
> > > > > As said in the previous emails i get these with execline too:
> > > > >
> > > > > in default FLAVOR: the following libraries in WANTLIB look like
> > > > > masked by RUN_DEPENDS: skarnet
> > > > > in FLAVOR "static": the following libraries in WANTLIB look like
> > > > > masked by RUN_DEPENDS: skarnet
> > > > >
> > > > > I have also checked that these ports work with -fno-common.
> > > > >
> > > > > Any comments and/or OKs?
> > > >
> > > > SHARED_LIBS = execline2.8
> > > > SHARED_LIBS = skarnet 2.10
> > > >
> > > > start with 0.0. if the build system doesn't produce a library with the
> > > > right name to match this, patch or pass in via make(1) variables until
> > > > it does.
> > > >
> > > > https://www.openbsd.org/faq/ports/specialtopics.html#SharedLibs
> > > >
> > > > @so lib/libexecline.so
> > > > @lib lib/libexecline.so.${LIBexecline_VERSION}
> > > > @bin lib/libexecline.so.2.8.0.0
> > > >
> > > > @so lib/libskarnet.so
> > > > @lib lib/libskarnet.so.${LIBskarnet_VERSION}
> > > > @bin lib/libskarnet.so.2.10.0.2
> > > >
> > > > there should just be "@lib lib/libxyz.so.${LIBxyz}" lines, no
> > > > symlinks etc.
> > > >
> > > > these are probably what's responsible for portcheck's "masked by"
> > > > warning.
> > > >
> > > > pkg/DESCR says "has no security issues"
> > > >
> > > > a bold claim! I don't think it's a good idea to include that bit.
> > > >
> > > > I would drop the static flavours unless there's a really good reason
> > > > for it (usually "it's helpful to run in a chroot for a webserver").
> > > >
> > >
> > > The reason for the static flavor is basically the same as for example
> > > shells/dash: it can be really useful in a chroot since it acts
> > > functionally the same as a shell. Anyway i will remove it in case.
> > >
> > > I modified the ports to match your suggestions, below there is the diff
> > > to add @conflict to etsh. Thanks!
skalibs.tar.gz
Description: application/tar-gz
execline.tar.gz
Description: application/tar-gz
Re: NEW: devel/skalibs and sysutils/execline
Ping
On Thu, Mar 11, 2021 at 03:05:14PM +0100, Alex Raschi wrote:
> Ping
>
> Ports and patch reattached for convenience.
>
> On Mon, Feb 22, 2021 at 09:16:52PM +0100, Alex Raschi wrote:
> > On Mon, Feb 22, 2021 at 01:35:38PM +, Stuart Henderson wrote:
> > > On 2021/02/22 14:05, Alex Raschi wrote:
> > > > I attached the new versions of skalibs (2.10.0.2) and execline
> > > > (2.8.0.0), these fixes a few bugs and change backtick(1) options
> > > > slightly.
> > > >
> > > > I also attached a new port of the newly created mdoc(7) ports of the
> > > > execline HTML documentation. With this one i get:
> > > >
> > > > Warning: execline-man-pages-2.8.0.0.1 conflicts with etsh-5.4.0v0
> > > > (shells/etsh):/usr/local/man/man1/if.1
> > > >
> > > > However shells/etsh does not seem to provide a real if(1) command, i
> > > > checked the PLIST of etsh and the if command seems to be an internal
> > > > shell command (execline provides an if command but does not conflict
> > > > with etsh). Any suggestion to fix this?
> > >
> > > either register the conflict with @conflict markers (in both ports),
> > > or install docs to a different dir. conflict markers seems ok to me.
> > >
> > > it might be better to just include the manuals in the main package.
> > > you can use multiple DISTFILES.
> > >
> > > > As said in the previous emails i get these with execline too:
> > > >
> > > > in default FLAVOR: the following libraries in WANTLIB look like masked
> > > > by RUN_DEPENDS: skarnet
> > > > in FLAVOR "static": the following libraries in WANTLIB look like masked
> > > > by RUN_DEPENDS: skarnet
> > > >
> > > > I have also checked that these ports work with -fno-common.
> > > >
> > > > Any comments and/or OKs?
> > >
> > > SHARED_LIBS = execline2.8
> > > SHARED_LIBS = skarnet 2.10
> > >
> > > start with 0.0. if the build system doesn't produce a library with the
> > > right name to match this, patch or pass in via make(1) variables until
> > > it does.
> > >
> > > https://www.openbsd.org/faq/ports/specialtopics.html#SharedLibs
> > >
> > > @so lib/libexecline.so
> > > @lib lib/libexecline.so.${LIBexecline_VERSION}
> > > @bin lib/libexecline.so.2.8.0.0
> > >
> > > @so lib/libskarnet.so
> > > @lib lib/libskarnet.so.${LIBskarnet_VERSION}
> > > @bin lib/libskarnet.so.2.10.0.2
> > >
> > > there should just be "@lib lib/libxyz.so.${LIBxyz}" lines, no
> > > symlinks etc.
> > >
> > > these are probably what's responsible for portcheck's "masked by" warning.
> > >
> > > pkg/DESCR says "has no security issues"
> > >
> > > a bold claim! I don't think it's a good idea to include that bit.
> > >
> > > I would drop the static flavours unless there's a really good reason
> > > for it (usually "it's helpful to run in a chroot for a webserver").
> > >
> >
> > The reason for the static flavor is basically the same as for example
> > shells/dash: it can be really useful in a chroot since it acts
> > functionally the same as a shell. Anyway i will remove it in case.
> >
> > I modified the ports to match your suggestions, below there is the diff
> > to add @conflict to etsh. Thanks!
> >
> > Index: shells/etsh/pkg/PLIST
> > ===
> > RCS file: /cvs/ports/shells/etsh/pkg/PLIST,v
> > retrieving revision 1.2
> > diff -u -p -r1.2 PLIST
> > --- shells/etsh/pkg/PLIST 30 Mar 2019 18:14:32 - 1.2
> > +++ shells/etsh/pkg/PLIST 22 Feb 2021 19:55:45 -
> > @@ -1,5 +1,6 @@
> > @comment $OpenBSD: PLIST,v 1.2 2019/03/30 18:14:32 bcallah Exp $
> > @conflict osh-*
> > +@conflict execline-*
> > @pkgpath shells/osh
> > @shell bin/etsh
> > @shell bin/tsh
>
>
>
> Index: shells/etsh/pkg/PLIST
> ===
> RCS file: /cvs/ports/shells/etsh/pkg/PLIST,v
> retrieving revision 1.2
> diff -u -p -r1.2 PLIST
> --- shells/etsh/pkg/PLIST 30 Mar 2019 18:14:32 - 1.2
> +++ shells/etsh/pkg/PLIST 22 Feb 2021 19:55:45 -
> @@ -1,5 +1,6 @@
> @comment $OpenBSD: PLIST,v 1.2 2019/03/30 18:14:32 bcallah Exp $
> @conflict osh-*
> +@conflict execline-*
> @pkgpath shells/osh
> @shell bin/etsh
> @shell bin/tsh
Re: NEW: devel/skalibs and sysutils/execline
Ping
Ports and patch reattached for convenience.
On Mon, Feb 22, 2021 at 09:16:52PM +0100, Alex Raschi wrote:
> On Mon, Feb 22, 2021 at 01:35:38PM +, Stuart Henderson wrote:
> > On 2021/02/22 14:05, Alex Raschi wrote:
> > > I attached the new versions of skalibs (2.10.0.2) and execline
> > > (2.8.0.0), these fixes a few bugs and change backtick(1) options
> > > slightly.
> > >
> > > I also attached a new port of the newly created mdoc(7) ports of the
> > > execline HTML documentation. With this one i get:
> > >
> > > Warning: execline-man-pages-2.8.0.0.1 conflicts with etsh-5.4.0v0
> > > (shells/etsh):/usr/local/man/man1/if.1
> > >
> > > However shells/etsh does not seem to provide a real if(1) command, i
> > > checked the PLIST of etsh and the if command seems to be an internal
> > > shell command (execline provides an if command but does not conflict
> > > with etsh). Any suggestion to fix this?
> >
> > either register the conflict with @conflict markers (in both ports),
> > or install docs to a different dir. conflict markers seems ok to me.
> >
> > it might be better to just include the manuals in the main package.
> > you can use multiple DISTFILES.
> >
> > > As said in the previous emails i get these with execline too:
> > >
> > > in default FLAVOR: the following libraries in WANTLIB look like masked by
> > > RUN_DEPENDS: skarnet
> > > in FLAVOR "static": the following libraries in WANTLIB look like masked
> > > by RUN_DEPENDS: skarnet
> > >
> > > I have also checked that these ports work with -fno-common.
> > >
> > > Any comments and/or OKs?
> >
> > SHARED_LIBS = execline2.8
> > SHARED_LIBS = skarnet 2.10
> >
> > start with 0.0. if the build system doesn't produce a library with the
> > right name to match this, patch or pass in via make(1) variables until
> > it does.
> >
> > https://www.openbsd.org/faq/ports/specialtopics.html#SharedLibs
> >
> > @so lib/libexecline.so
> > @lib lib/libexecline.so.${LIBexecline_VERSION}
> > @bin lib/libexecline.so.2.8.0.0
> >
> > @so lib/libskarnet.so
> > @lib lib/libskarnet.so.${LIBskarnet_VERSION}
> > @bin lib/libskarnet.so.2.10.0.2
> >
> > there should just be "@lib lib/libxyz.so.${LIBxyz}" lines, no
> > symlinks etc.
> >
> > these are probably what's responsible for portcheck's "masked by" warning.
> >
> > pkg/DESCR says "has no security issues"
> >
> > a bold claim! I don't think it's a good idea to include that bit.
> >
> > I would drop the static flavours unless there's a really good reason
> > for it (usually "it's helpful to run in a chroot for a webserver").
> >
>
> The reason for the static flavor is basically the same as for example
> shells/dash: it can be really useful in a chroot since it acts
> functionally the same as a shell. Anyway i will remove it in case.
>
> I modified the ports to match your suggestions, below there is the diff
> to add @conflict to etsh. Thanks!
>
> Index: shells/etsh/pkg/PLIST
> ===
> RCS file: /cvs/ports/shells/etsh/pkg/PLIST,v
> retrieving revision 1.2
> diff -u -p -r1.2 PLIST
> --- shells/etsh/pkg/PLIST 30 Mar 2019 18:14:32 - 1.2
> +++ shells/etsh/pkg/PLIST 22 Feb 2021 19:55:45 -
> @@ -1,5 +1,6 @@
> @comment $OpenBSD: PLIST,v 1.2 2019/03/30 18:14:32 bcallah Exp $
> @conflict osh-*
> +@conflict execline-*
> @pkgpath shells/osh
> @shell bin/etsh
> @shell bin/tsh
skalibs.tar.gz
Description: application/tar-gz
execline.tar.gz
Description: application/tar-gz
Index: shells/etsh/pkg/PLIST
===
RCS file: /cvs/ports/shells/etsh/pkg/PLIST,v
retrieving revision 1.2
diff -u -p -r1.2 PLIST
--- shells/etsh/pkg/PLIST 30 Mar 2019 18:14:32 - 1.2
+++ shells/etsh/pkg/PLIST 22 Feb 2021 19:55:45 -
@@ -1,5 +1,6 @@
@comment $OpenBSD: PLIST,v 1.2 2019/03/30 18:14:32 bcallah Exp $
@conflict osh-*
+@conflict execline-*
@pkgpath shells/osh
@shell bin/etsh
@shell bin/tsh
NEW: graphics/basis_universal
Version 1.12 never went in, so here is version 1.13 of Bionominal's supercompressed GPU texture compression system. >From the DESCR: Basis Universal is a "supercompressed" GPU texture compression system that outputs a highly compressed intermediate file format (.basis) that can be quickly transcoded to a very wide variety of GPU compressed and uncompressed pixel formats: ASTC 4x4 L/LA/RGB/RGBA, PVRTC1 4bpp RGB/RGBA, PVRTC2 RGB/RGBA, BC7 mode 6 RGB, BC7 mode 5 RGB/RGBA, BC1-5 RGB/RGBA/X/XY, ETC1 RGB, ETC2 RGBA, ATC RGB/RGBA, ETC2 EAC R11 and RG11, FXT1 RGB, and uncompressed raster image formats /565/. basisu.tgz Description: application/compressed-tar
Re: games/egoboo: abortive update to 2.8.1
Hi On Tue, Mar 02, 2021 at 01:50:45AM +0100, Christian Weisgerber wrote: > I tried to update games/egoboo to 2.8.1 but failed. > > It builds. > It requires the included libenet. The API is not compatible with > the version in our net/enet port. > I packaged it. > I fixed a crash on startup in some code that roots around in SDL > bitmaps. > > Now I can't properly control the character. The cursor keys only > allow movement in two directions. I found a patch for this here: http://egoboo.sourceforge.net/phpBB3/viewtopic.php?f=3&t=1177&start=15#p61333 Tested briefly and movement seem ok now. Can you confirm? I never played this game before i might be missing something. Patch attached. > I give up. > > The upstream repository on GitHub has been rototilled several times, > making it hard to find anything, and once you do, it's sweeping > changes. > > I'm attaching the patch from as far as I got, in case somebody ever > wants to take it from there. The patch is very large due to many > changes in the giant PLIST. > > -- > Christian "naddy" Weisgerber na...@mips.inka.de egoboo.patch.gz Description: application/gunzip
Re: NEW: devel/skalibs and sysutils/execline
On Mon, Feb 22, 2021 at 01:35:38PM +, Stuart Henderson wrote:
> On 2021/02/22 14:05, Alex Raschi wrote:
> > I attached the new versions of skalibs (2.10.0.2) and execline
> > (2.8.0.0), these fixes a few bugs and change backtick(1) options
> > slightly.
> >
> > I also attached a new port of the newly created mdoc(7) ports of the
> > execline HTML documentation. With this one i get:
> >
> > Warning: execline-man-pages-2.8.0.0.1 conflicts with etsh-5.4.0v0
> > (shells/etsh):/usr/local/man/man1/if.1
> >
> > However shells/etsh does not seem to provide a real if(1) command, i
> > checked the PLIST of etsh and the if command seems to be an internal
> > shell command (execline provides an if command but does not conflict
> > with etsh). Any suggestion to fix this?
>
> either register the conflict with @conflict markers (in both ports),
> or install docs to a different dir. conflict markers seems ok to me.
>
> it might be better to just include the manuals in the main package.
> you can use multiple DISTFILES.
>
> > As said in the previous emails i get these with execline too:
> >
> > in default FLAVOR: the following libraries in WANTLIB look like masked by
> > RUN_DEPENDS: skarnet
> > in FLAVOR "static": the following libraries in WANTLIB look like masked by
> > RUN_DEPENDS: skarnet
> >
> > I have also checked that these ports work with -fno-common.
> >
> > Any comments and/or OKs?
>
> SHARED_LIBS = execline2.8
> SHARED_LIBS = skarnet 2.10
>
> start with 0.0. if the build system doesn't produce a library with the
> right name to match this, patch or pass in via make(1) variables until
> it does.
>
> https://www.openbsd.org/faq/ports/specialtopics.html#SharedLibs
>
> @so lib/libexecline.so
> @lib lib/libexecline.so.${LIBexecline_VERSION}
> @bin lib/libexecline.so.2.8.0.0
>
> @so lib/libskarnet.so
> @lib lib/libskarnet.so.${LIBskarnet_VERSION}
> @bin lib/libskarnet.so.2.10.0.2
>
> there should just be "@lib lib/libxyz.so.${LIBxyz}" lines, no
> symlinks etc.
>
> these are probably what's responsible for portcheck's "masked by" warning.
>
> pkg/DESCR says "has no security issues"
>
> a bold claim! I don't think it's a good idea to include that bit.
>
> I would drop the static flavours unless there's a really good reason
> for it (usually "it's helpful to run in a chroot for a webserver").
>
The reason for the static flavor is basically the same as for example
shells/dash: it can be really useful in a chroot since it acts
functionally the same as a shell. Anyway i will remove it in case.
I modified the ports to match your suggestions, below there is the diff
to add @conflict to etsh. Thanks!
Index: shells/etsh/pkg/PLIST
===
RCS file: /cvs/ports/shells/etsh/pkg/PLIST,v
retrieving revision 1.2
diff -u -p -r1.2 PLIST
--- shells/etsh/pkg/PLIST 30 Mar 2019 18:14:32 - 1.2
+++ shells/etsh/pkg/PLIST 22 Feb 2021 19:55:45 -
@@ -1,5 +1,6 @@
@comment $OpenBSD: PLIST,v 1.2 2019/03/30 18:14:32 bcallah Exp $
@conflict osh-*
+@conflict execline-*
@pkgpath shells/osh
@shell bin/etsh
@shell bin/tsh
skalibs.tar.gz
Description: application/tar-gz
execline.tar.gz
Description: application/tar-gz
Re: NEW: devel/skalibs and sysutils/execline
I attached the new versions of skalibs (2.10.0.2) and execline (2.8.0.0), these fixes a few bugs and change backtick(1) options slightly. I also attached a new port of the newly created mdoc(7) ports of the execline HTML documentation. With this one i get: Warning: execline-man-pages-2.8.0.0.1 conflicts with etsh-5.4.0v0 (shells/etsh):/usr/local/man/man1/if.1 However shells/etsh does not seem to provide a real if(1) command, i checked the PLIST of etsh and the if command seems to be an internal shell command (execline provides an if command but does not conflict with etsh). Any suggestion to fix this? As said in the previous emails i get these with execline too: in default FLAVOR: the following libraries in WANTLIB look like masked by RUN_DEPENDS: skarnet in FLAVOR "static": the following libraries in WANTLIB look like masked by RUN_DEPENDS: skarnet I have also checked that these ports work with -fno-common. Any comments and/or OKs? skalibs.tar.gz Description: application/tar-gz execline.tar.gz Description: application/tar-gz execline-man-pages.tar.gz Description: application/tar-gz
Re: NEW: devel/skalibs and sysutils/execline
I attached the two bugfix releases 2.10.0.1 and 2.7.0.1, these fixes various bugs related to elgetpositionals, trap and emptyenv commands. Any comments, ok and/or clarifications on the two doubts in the previous email? skalibs.tar.gz Description: application/tar-gz execline.tar.gz Description: application/tar-gz
NEW: devel/skalibs and sysutils/execline
Hi,
I made a port for execline (and skalibs which is a dependency), a
scripting language like sh but implemented in a really different way.
Once the parser has read the script it exits and leaves a chain of
commands running, each of these do something and exec in the next
command.
skalibs is a general-purpose library, used by the skarnet.org software.
I tested them on amd64 and i386.
I have a few doubts, when i run portcheck on sysutils/execline i get the
following and i haven't found a way to fix it:
in default FLAVOR: the following libraries in WANTLIB look like masked by
RUN_DEPENDS: skarnet
in FLAVOR "static": the following libraries in WANTLIB look like masked by
RUN_DEPENDS: skarnet
skalibs offer a default PATH (for example when executing into another
command) when one is not set in the environment, this is configurable at
compile time, i have set the system default one:
/usr/bin:/bin:/usr/sbin:/sbin:/usr/X11R6/bin:${LOCALBASE}/bin:${LOCALBASE}/sbin
Is this correct?
Comments, suggestions and/or testing?
Thanks in advance!
skalibs.tar.gz
Description: application/tar-gz
execline.tar.gz
Description: application/tar-gz
[UPDATE] devel/rcs-fast-import (1.0 -> 1.1)
This patch updates rcs-fast-import to version 1.1. There are no tests for this port until now. 'portcheck', 'port-lib-depends-check' and 'update-plist' are OK. ChanegeLog: 1.1: 2020-03-07::Ported to Python 3Rehosted at GitLab. Cheers, Alex Index: Makefile === RCS file: /cvs/ports/devel/rcs-fast-import/Makefile,v retrieving revision 1.4 diff -u -p -u -p -r1.4 Makefile --- Makefile 12 Jul 2019 20:45:57 - 1.4 +++ Makefile 14 Jan 2021 14:39:26 - @@ -2,7 +2,7 @@ COMMENT = unpack git fast-import streams into RCS file tree -DISTNAME = rcs-fast-import-1.0 +DISTNAME = rcs-fast-import-1.1 REVISION = 0 CATEGORIES = devel Index: distinfo === RCS file: /cvs/ports/devel/rcs-fast-import/distinfo,v retrieving revision 1.1.1.1 diff -u -p -u -p -r1.1.1.1 distinfo --- distinfo 30 Nov 2014 17:03:32 - 1.1.1.1 +++ distinfo 14 Jan 2021 14:39:26 - @@ -1,2 +1,2 @@ -SHA256 (rcs-fast-import-1.0.tar.gz) = V7sncezFNPceR5rwy8tKm0t10Qaz/nJZGR6tjCYfBgQ= -SIZE (rcs-fast-import-1.0.tar.gz) = 14899 +SHA256 (rcs-fast-import-1.1.tar.gz) = 3s6jBM7aIQPUkgqSY1FltiBaL031nh+OKmrqbscTkOU= +SIZE (rcs-fast-import-1.1.tar.gz) = 14970
Libraries error by trying to build port
Hello, by trying to 'make build' and 'make test' some ports, I get problem with libraries. I tried to 'make update-plist' and 'make port-lib-depends-check' like described in faq/ports/guide.html, but every time get the same error: ===> Verifying install for gdbm-* in databases/gdbm `/usr/ports/pobj/gdbm-1.18.1/fake-aarch64/.fake_done' is up to date. ===> Building package for gdbm-1.18.1p0 Create /usr/ports/packages/aarch64/all/gdbm-1.18.1p0.tgz Error: Libraries in packing-lists in the ports tree and libraries from installed packages don't match --- /tmp/dep_cache.xvEEohwvP/portstree-gdbm-1.18.1p0 Thu Jan 14 14:29:49 2021 +++ /tmp/dep_cache.xvEEohwvP/inst-gdbm-1.18.1p0Thu Jan 14 14:29:49 2021 Can somebody explain how to solve this problem. Do I need just to update my current version or is there something else? Thanks, Alex
[UPDATE] fonts/inter (3.13 -> 3.15)
this patch updates inter to version 3.15. 'portcheck', 'port-lib-depends-check' and 'update-plist' returns OK. Port has no tests, so 'make test' also returns OK. Updated/Tested on x86_64. ChangeLog: v3.15: * Fixes an issue with the variable font, where some software would not list the various weights correctly. * Fixes an issue with rendering on Windows with ClearType where some glyphs using advanced OpenType features (component transformations) would render incorrectly, with a slight vertical offset. * Improvements to Elfdalian, improving the /yogonek and /eth glyphs * Improvements to /eth U+00F0 glyph f7924a2#commitcomment-41610142 v3.14: * Fixes position of ring at bottom of /Aringbelow U+1E00. * Fixes interpolation issues with /omegatitlocyrillic /omega and /pisymbolgreek. * Fixes an issue with /dotmacroncomb.cn used by glyphs like /Adotmacron. * Adds /bitcoin glyph U+20BF. * Adds /insertionsymbol U+2380. * Adds specialized glyphs /Aringogonek, /aringogonek, /Yogonek and /yogonek to fully support Elfdalian script. * Adds U+EE01, a vertically-centered colon used by Android on the lock screen * Improves kerning of /quotedblright,/quoteright and /period,/comma. * Improves design of "Theta" U+03F4, U+0398 and "Fita" U+0472, U+0473. * Improves design of /yhook and use /ucyrillic in /Ukcyrillic /ukcyrillic. * Improves design of /dzaltone and /dzcurl. * Improves design of /percent, /perthousand and /pertenthousand glyphs. * Improves variable-font metadata (STAT table). * Improves (tunes) calt case substitutions, e.g. "x -X". * Changes codepoint mapping of /q.sups from U+146B to private-area U+E163. Cheers, Alex Index: Makefile === RCS file: /cvs/ports/fonts/inter/Makefile,v retrieving revision 1.6 diff -u -p -u -p -r1.6 Makefile --- Makefile 25 May 2020 05:02:57 - 1.6 +++ Makefile 13 Jan 2021 21:39:52 - @@ -2,7 +2,7 @@ COMMENT = typeface carefully crafted & designed for computer screens -V = 3.13 +V = 3.15 DISTNAME = Inter-$V PKGNAME = inter-$V Index: distinfo === RCS file: /cvs/ports/fonts/inter/distinfo,v retrieving revision 1.5 diff -u -p -u -p -r1.5 distinfo --- distinfo 25 May 2020 05:02:57 - 1.5 +++ distinfo 13 Jan 2021 21:39:52 - @@ -1,2 +1,2 @@ -SHA256 (Inter-3.13.zip) = eJ00IQIp2BSvxb19C0Yju4nI2Ac/vnsKJPv3ckhWTaY= -SIZE (Inter-3.13.zip) = 18484208 +SHA256 (Inter-3.15.zip) = FTQojrWZ9XrL8sWsABDalJXC7lMRbgjXmVVcb47iIVY= +SIZE (Inter-3.15.zip) = 22090616 Index: pkg/PLIST === RCS file: /cvs/ports/fonts/inter/pkg/PLIST,v retrieving revision 1.3 diff -u -p -u -p -r1.3 PLIST --- pkg/PLIST 25 May 2020 05:02:57 - 1.3 +++ pkg/PLIST 13 Jan 2021 21:39:52 - @@ -39,4 +39,3 @@ share/fonts/inter/Inter-Thin.otf share/fonts/inter/Inter-Thin.ttf share/fonts/inter/Inter-ThinItalic.otf share/fonts/inter/Inter-ThinItalic.ttf -share/fonts/inter/Inter-V.otf
[UPDATE] devel/check (0.12.0 -> 0.15.2)
Greetings, this patch updates check (Unit Testing Framework for C) to version 0.15.2. 'portcheck', 'port-lib-depends-check' and 'update-plist' returns 0. Updated and tested on aarch64 (SoftIron Overdrive 1000). All tests are OK: ===> Regression tests for check-0.15.2 Making check in lib Making check in src Making check in doc Making check in . Making check in checkmk make check-TESTS PASS: test/check_checkmk Testsuite summary for Check 0.15.2 # TOTAL: 1 # PASS: 1 # SKIP: 0 # XFAIL: 0 # FAIL: 0 # XPASS: 0 # ERROR: 0 Making check in tests make check-TESTS PASS: check_check_export PASS: check_check PASS: test_output.sh PASS: test_check_nofork.sh PASS: test_check_nofork_teardown.sh PASS: test_xml_output.sh PASS: test_log_output.sh PASS: test_set_max_msg_size.sh PASS: test_tap_output.sh Testsuite summary for Check 0.15.2 # TOTAL: 9 # PASS: 9 # SKIP: 0 # XFAIL: 0 # FAIL: 0 # XPASS: 0 # ERROR: 0 Changelog 0.12.0 -> 0.15.2: Fri Aug 7, 2020: Released Check 0.15.2 * Fix fail* APIs, regression from 0.15.1 Sun July 19, 2020: Released Check 0.15.1 * Fix warning in ptr macros with pointer to integer cast * Fix various warnings in Check's unit tests * Replace gnu_printf with printf in format __attribute__ * Fix warnings from Check's macros: "warning: too many arguments for format" * Fix format specifiers that do not match the argument types Sun June 21, 2020: Released Check 0.15.0 * Define CK_ATTRIBUTE_FORMAT for GCC >= 2.95.3, to make use of ‘gnu_printf’ format attribute * Refactor tests to fix signed - unsigned conversions * Refactor some Check internals to use proper interger types * Implement missing mutual exclusion for Windows hosts Sun Jan 26, 2020: Released Check 0.14.0 * Add support for FetchContent in CMake * Rename CMake project from 'check' to 'Check' * Fix for checking for wrong tool when building docs in Autotools * Fix compiler warning with printf format Sat Oct 20, 2019: Released Check 0.13.0 * configure: optional build documentation * missing in some files * Various documentation improvements * END_TEST is now optional, as how START_TEST works has been redone * Various CMake related changes: - Support exporting Check to other projects with CMake 3 - Shared library support for Visual Studio - Fix wrong library filename - Add support for CMake package registry - CMake build type can now be debug or release - Add checkmk to CMake build. Cheers, Alexander Naumov ? check-0.15.2.patch Index: Makefile === RCS file: /cvs/ports/devel/check/Makefile,v retrieving revision 1.16 diff -u -p -u -p -r1.16 Makefile --- Makefile 12 Jul 2019 20:44:05 - 1.16 +++ Makefile 12 Jan 2021 17:34:37 - @@ -2,7 +2,7 @@ COMMENT = unit test framework for C programs -V = 0.12.0 +V = 0.15.2 DISTNAME = check-$V SHARED_LIBS += check3.1 # unknown Index: distinfo === RCS file: /cvs/ports/devel/check/distinfo,v retrieving revision 1.10 diff -u -p -u -p -r1.10 distinfo --- distinfo 20 May 2019 21:36:54 - 1.10 +++ distinfo 12 Jan 2021 17:34:37 - @@ -1,2 +1,2 @@ -SHA256 (check-0.12.0.tar.gz) = RkIBCYvuAOkPXEvfqUpdPq2NZB+QJbVgondVqDuCQjQ= -SIZE (check-0.12.0.tar.gz) = 764043 +SHA256 (check-0.15.2.tar.gz) = qN5OC6z7TXbdHGGN7SY1I7U7hdkqFG2INesaUpMvogo= +SIZE (check-0.15.2.tar.gz) = 774985 Index: patches/patch-Makefile_in === RCS file: patches/patch-Makefile_in diff -N patches/patch-Makefile_in --- patches/patch-Makefile_in 20 May 2019 21:36:54 - 1.6 +++ /dev/null 1 Jan 1970 00:00:00 - @@ -1,21 +0,0 @@ -$OpenBSD: patch-Makefile_in,v 1.6 2019/05/20 21:36:54 sthen Exp $ Makefile.in.orig Sun Aug 2 21:31:55 2015 -+++ Makefile.in Mon Aug 24 08:23:07 2015 -@@ -386,7 +386,7 @@ top_build_prefix = @top_build_prefix@ - top_builddir = @top_builddir@ - top_srcdir = @top_srcdir@ - SUBDIRS = lib src doc . checkmk tests --AM_MAKEINFOFLAGS = -I$(top_srcdir)/doc/example -+AM_MAKEINFOFLAGS = -I$(top_srcdir)/doc/example/check - CLEANFILES = *~\ - $(PACKAGE)-$(VERSION).tar.gz\ - ChangeLog.bak -@@ -913,7 +913,7 @@ info: info-recursive - - info-am: - --install-data-am: install-docDATA install-includeHEADERS \ -+install-data-am: install-includeHEADERS \ - install-m4dataDATA install-pcdataDATA - - install-dvi: install-dvi-recursive Index: pkg/PLIST === RCS file: /c
Re: UPDATE: net/dino, 0.1.0 -> 0.2.0
using Gee;
-
- namespace Xmpp.Xep.ServiceDiscovery {
-
--private const string NS_URI = "http://jabber.org/protocol/disco";;
-+public const string NS_URI = "http://jabber.org/protocol/disco";;
- public const string NS_URI_INFO = NS_URI + "#info";
- public const string NS_URI_ITEMS = NS_URI + "#items";
-
Index: net/dino/pkg/PLIST
===
RCS file: /cvs/ports/net/dino/pkg/PLIST,v
retrieving revision 1.1.1.1
diff -u -p -r1.1.1.1 PLIST
--- net/dino/pkg/PLIST 13 Feb 2020 11:58:55 - 1.1.1.1
+++ net/dino/pkg/PLIST 13 Dec 2020 16:56:32 -
@@ -30,6 +30,9 @@ share/locale/ar/LC_MESSAGES/dino.mo
share/locale/ca/LC_MESSAGES/dino-omemo.mo
share/locale/ca/LC_MESSAGES/dino-openpgp.mo
share/locale/ca/LC_MESSAGES/dino.mo
+share/locale/cs/LC_MESSAGES/dino-omemo.mo
+share/locale/cs/LC_MESSAGES/dino-openpgp.mo
+share/locale/cs/LC_MESSAGES/dino.mo
share/locale/de/LC_MESSAGES/dino-omemo.mo
share/locale/de/LC_MESSAGES/dino-openpgp.mo
share/locale/de/LC_MESSAGES/dino.mo
@@ -43,6 +46,7 @@ share/locale/es/LC_MESSAGES/dino.mo
share/locale/eu/LC_MESSAGES/dino-omemo.mo
share/locale/eu/LC_MESSAGES/dino-openpgp.mo
share/locale/eu/LC_MESSAGES/dino.mo
+share/locale/fa/LC_MESSAGES/dino.mo
share/locale/fi/LC_MESSAGES/dino-omemo.mo
share/locale/fi/LC_MESSAGES/dino-openpgp.mo
share/locale/fi/LC_MESSAGES/dino.mo
@@ -55,17 +59,26 @@ share/locale/gl/LC_MESSAGES/dino.mo
share/locale/hu/LC_MESSAGES/dino-omemo.mo
share/locale/hu/LC_MESSAGES/dino-openpgp.mo
share/locale/hu/LC_MESSAGES/dino.mo
+share/locale/ie/
+share/locale/ie/LC_MESSAGES/
+share/locale/ie/LC_MESSAGES/dino-omemo.mo
+share/locale/ie/LC_MESSAGES/dino-openpgp.mo
+share/locale/ie/LC_MESSAGES/dino.mo
share/locale/it/LC_MESSAGES/dino-omemo.mo
share/locale/it/LC_MESSAGES/dino-openpgp.mo
share/locale/it/LC_MESSAGES/dino.mo
share/locale/ja/LC_MESSAGES/dino-omemo.mo
share/locale/ja/LC_MESSAGES/dino-openpgp.mo
share/locale/ja/LC_MESSAGES/dino.mo
+share/locale/ko/LC_MESSAGES/dino.mo
share/locale/lb/
share/locale/lb/LC_MESSAGES/
share/locale/lb/LC_MESSAGES/dino-omemo.mo
share/locale/lb/LC_MESSAGES/dino-openpgp.mo
share/locale/lb/LC_MESSAGES/dino.mo
+share/locale/lt/LC_MESSAGES/dino-omemo.mo
+share/locale/lt/LC_MESSAGES/dino-openpgp.mo
+share/locale/lt/LC_MESSAGES/dino.mo
share/locale/nb/LC_MESSAGES/dino-omemo.mo
share/locale/nb/LC_MESSAGES/dino-openpgp.mo
share/locale/nb/LC_MESSAGES/dino.mo
@@ -77,10 +90,15 @@ share/locale/nl_BE/LC_MESSAGES/
share/locale/nl_BE/LC_MESSAGES/dino-omemo.mo
share/locale/nl_BE/LC_MESSAGES/dino-openpgp.mo
share/locale/nl_BE/LC_MESSAGES/dino.mo
+share/locale/oc/LC_MESSAGES/dino-omemo.mo
+share/locale/oc/LC_MESSAGES/dino-openpgp.mo
share/locale/oc/LC_MESSAGES/dino.mo
share/locale/pl/LC_MESSAGES/dino-omemo.mo
share/locale/pl/LC_MESSAGES/dino-openpgp.mo
share/locale/pl/LC_MESSAGES/dino.mo
+share/locale/pt/LC_MESSAGES/dino-omemo.mo
+share/locale/pt/LC_MESSAGES/dino-openpgp.mo
+share/locale/pt/LC_MESSAGES/dino.mo
share/locale/pt_BR/LC_MESSAGES/dino-omemo.mo
share/locale/pt_BR/LC_MESSAGES/dino-openpgp.mo
share/locale/pt_BR/LC_MESSAGES/dino.mo
@@ -93,6 +111,11 @@ share/locale/ru/LC_MESSAGES/dino.mo
share/locale/sv/LC_MESSAGES/dino-omemo.mo
share/locale/sv/LC_MESSAGES/dino-openpgp.mo
share/locale/sv/LC_MESSAGES/dino.mo
+share/locale/ta/LC_MESSAGES/dino.mo
+share/locale/tr/LC_MESSAGES/dino-omemo.mo
+share/locale/tr/LC_MESSAGES/dino-openpgp.mo
+share/locale/tr/LC_MESSAGES/dino.mo
+share/locale/uk/LC_MESSAGES/dino.mo
share/locale/zh_CN/LC_MESSAGES/dino-omemo.mo
share/locale/zh_CN/LC_MESSAGES/dino-openpgp.mo
share/locale/zh_CN/LC_MESSAGES/dino.mo
--
Alex Holst
UPDATE: net/dino, 0.1.0 -> 0.2.0
eu/LC_MESSAGES/dino-omemo.mo share/locale/eu/LC_MESSAGES/dino-openpgp.mo share/locale/eu/LC_MESSAGES/dino.mo +share/locale/fa/LC_MESSAGES/dino.mo share/locale/fi/LC_MESSAGES/dino-omemo.mo share/locale/fi/LC_MESSAGES/dino-openpgp.mo share/locale/fi/LC_MESSAGES/dino.mo @@ -55,17 +60,26 @@ share/locale/gl/LC_MESSAGES/dino.mo share/locale/hu/LC_MESSAGES/dino-omemo.mo share/locale/hu/LC_MESSAGES/dino-openpgp.mo share/locale/hu/LC_MESSAGES/dino.mo +share/locale/ie/ +share/locale/ie/LC_MESSAGES/ +share/locale/ie/LC_MESSAGES/dino-omemo.mo +share/locale/ie/LC_MESSAGES/dino-openpgp.mo +share/locale/ie/LC_MESSAGES/dino.mo share/locale/it/LC_MESSAGES/dino-omemo.mo share/locale/it/LC_MESSAGES/dino-openpgp.mo share/locale/it/LC_MESSAGES/dino.mo share/locale/ja/LC_MESSAGES/dino-omemo.mo share/locale/ja/LC_MESSAGES/dino-openpgp.mo share/locale/ja/LC_MESSAGES/dino.mo +share/locale/ko/LC_MESSAGES/dino.mo share/locale/lb/ share/locale/lb/LC_MESSAGES/ share/locale/lb/LC_MESSAGES/dino-omemo.mo share/locale/lb/LC_MESSAGES/dino-openpgp.mo share/locale/lb/LC_MESSAGES/dino.mo +share/locale/lt/LC_MESSAGES/dino-omemo.mo +share/locale/lt/LC_MESSAGES/dino-openpgp.mo +share/locale/lt/LC_MESSAGES/dino.mo share/locale/nb/LC_MESSAGES/dino-omemo.mo share/locale/nb/LC_MESSAGES/dino-openpgp.mo share/locale/nb/LC_MESSAGES/dino.mo @@ -77,10 +91,15 @@ share/locale/nl_BE/LC_MESSAGES/ share/locale/nl_BE/LC_MESSAGES/dino-omemo.mo share/locale/nl_BE/LC_MESSAGES/dino-openpgp.mo share/locale/nl_BE/LC_MESSAGES/dino.mo +share/locale/oc/LC_MESSAGES/dino-omemo.mo +share/locale/oc/LC_MESSAGES/dino-openpgp.mo share/locale/oc/LC_MESSAGES/dino.mo share/locale/pl/LC_MESSAGES/dino-omemo.mo share/locale/pl/LC_MESSAGES/dino-openpgp.mo share/locale/pl/LC_MESSAGES/dino.mo +share/locale/pt/LC_MESSAGES/dino-omemo.mo +share/locale/pt/LC_MESSAGES/dino-openpgp.mo +share/locale/pt/LC_MESSAGES/dino.mo share/locale/pt_BR/LC_MESSAGES/dino-omemo.mo share/locale/pt_BR/LC_MESSAGES/dino-openpgp.mo share/locale/pt_BR/LC_MESSAGES/dino.mo @@ -93,6 +112,11 @@ share/locale/ru/LC_MESSAGES/dino.mo share/locale/sv/LC_MESSAGES/dino-omemo.mo share/locale/sv/LC_MESSAGES/dino-openpgp.mo share/locale/sv/LC_MESSAGES/dino.mo +share/locale/ta/LC_MESSAGES/dino.mo +share/locale/tr/LC_MESSAGES/dino-omemo.mo +share/locale/tr/LC_MESSAGES/dino-openpgp.mo +share/locale/tr/LC_MESSAGES/dino.mo +share/locale/uk/LC_MESSAGES/dino.mo share/locale/zh_CN/LC_MESSAGES/dino-omemo.mo share/locale/zh_CN/LC_MESSAGES/dino-openpgp.mo share/locale/zh_CN/LC_MESSAGES/dino.mo -- Alex Holst
Re: [MAINTAINER UPDATE] net/xl2tpd (1.3.14 -> 1.3.15)
Here is the xl2tpd-1.3.15 Changelog: https://github.com/xelerance/xl2tpd/blob/master/CHANGES v1.3.15 (October 13, 2019) * Fix spacing of CONTRIBUTION.md [Samir Hussain] * Add CONTRIBUTION.md [Samir Hussain] * Specify missing log arguments [Patch by github user: 川島和津実] * Use matrix for .travis.yaml to test for multiple Linux distro [Samir Hussain] * Fixing .travis.yaml spacing warning [Samir Hussain] * Sockopt bug fix for multiple IP's [JDTX] * Add Clang as compiler test for travis [Samir Hussain] * Add info on building and installing xl2tpd [Samir Hussain] On Sat, Oct 3, 2020 at 1:35 AM Alex Naumov wrote: > This patch updates xl2tpd to version 1.3.15. > > What was done: > - make makesum > - make test > - /usr/ports/infrastructure/bin/portcheck > - make port-lib-depends-check > - make update-plist > > 'portcheck' reports some problems for 1.3.14 version: > * trailing whitespace in pkg/README > * 2 line(s) longer than 80 chars in pkg/README > It's fixed now. > > Package was built/tested/installed on x86_64 and aarch64 (SoftIron 1000) > machines. > > Like before > $ echo c l2tp > /var/run/xl2tpd/l2tp-control > lets communicate with peer npppd(8) via l2tp (7001/udp). > > There is no maintainer for xl2tpd. > I can take responsibilities for this port. > > Cheers, > Alex >
[MAINTAINER UPDATE] net/xl2tpd (1.3.14 -> 1.3.15)
This patch updates xl2tpd to version 1.3.15. What was done: - make makesum - make test - /usr/ports/infrastructure/bin/portcheck - make port-lib-depends-check - make update-plist 'portcheck' reports some problems for 1.3.14 version: * trailing whitespace in pkg/README * 2 line(s) longer than 80 chars in pkg/README It's fixed now. Package was built/tested/installed on x86_64 and aarch64 (SoftIron 1000) machines. Like before $ echo c l2tp > /var/run/xl2tpd/l2tp-control lets communicate with peer npppd(8) via l2tp (7001/udp). There is no maintainer for xl2tpd. I can take responsibilities for this port. Cheers, Alex Index: Makefile === RCS file: /cvs/ports/net/xl2tpd/Makefile,v retrieving revision 1.20 diff -u -p -u -p -r1.20 Makefile --- Makefile 12 Jul 2019 20:48:52 - 1.20 +++ Makefile 1 Oct 2020 20:03:33 - @@ -4,11 +4,13 @@ COMMENT= l2tp client/server GH_ACCOUNT= xelerance GH_PROJECT= xl2tpd -GH_TAGNAME= v1.3.14 +GH_TAGNAME= v1.3.15 CATEGORIES= net -HOMEPAGE= http://www.xelerance.com/services/software/xl2tpd/ +HOMEPAGE= https://github.com/xelerance/xl2tpd + +MAINTAINER= Alexander Naumov # GPLv2 PERMIT_PACKAGE= Yes Index: distinfo === RCS file: /cvs/ports/net/xl2tpd/distinfo,v retrieving revision 1.8 diff -u -p -u -p -r1.8 distinfo --- distinfo 18 Apr 2019 17:30:45 - 1.8 +++ distinfo 1 Oct 2020 20:03:33 - @@ -1,2 +1,2 @@ -SHA256 (xl2tpd-1.3.14.tar.gz) = /1oIBv7MWMe5y8YlEXpFIcBUZSKl9ZUf+27r2rmYYQ8= -SIZE (xl2tpd-1.3.14.tar.gz) = 523992 +SHA256 (xl2tpd-1.3.15.tar.gz) = DRSb+dL32DiAbmo2/XpnbQO/JG0reGnhbJRTMOE7ki4= +SIZE (xl2tpd-1.3.15.tar.gz) = 524960 Index: pkg/README === RCS file: /cvs/ports/net/xl2tpd/pkg/README,v retrieving revision 1.8 diff -u -p -u -p -r1.8 README --- pkg/README 4 Sep 2018 12:46:19 - 1.8 +++ pkg/README 1 Oct 2020 20:03:33 - @@ -26,7 +26,7 @@ Control mechanisms == When xl2tpd is started, it does not automatically connect. Instead it is controlled by writing simple commands to a fifo (you may be familiar with -this style from isakmpd), e.g.: +this style from isakmpd), e.g.: echo '[command] [config_name]' > /var/run/xl2tpd/l2tp-control @@ -100,8 +100,10 @@ And confirm that the tunnel does actuall # ipsecctl -sa FLOWS: -flow esp in proto udp from $server port l2tp to $me peer $server srcid $myhostname dstid $server/32 type use -flow esp out proto udp from $me to $server port l2tp peer $server srcid $myhostname dstid $server/32 type require +flow esp in proto udp from $server port l2tp to $me peer $server \ +srcid $myhostname dstid $server/32 type use +flow esp out proto udp from $me to $server port l2tp peer $server \ +srcid $myhostname dstid $server/32 type require SAD: esp transport from $me to $server spi 0x1037c0f2 auth hmac-sha1 enc aes
Re: ok? [NEW] emulators/minivmac : classic mac emu (6 flavors!)
> Sent: Tuesday, June 09, 2020 at 2:18 AM > From: "Alex Free" > To: "ports@openbsd.org" > Subject: ok? [NEW] emulators/minivmac : classic mac emu (6 flavors!) > > Hello ports, attached is a Mini vMac port for the latest version with 6 > total flavors. Each flavor emulates a different Mac model, such as the M > acintosh 128k, 512Ke, SE, Classic, SEFDHD, or II. The Macintosh Plus is > emulated by default. This single port can emulate 7 different machines. > > Everything here except sound emulation works. OpenBSD has actually been > officially supported for some time now, but sound still isn't implemente > d. > > I've included a pkg/README with some quick start style information. It a > lso mentions that sound emulation is not currently supported. > > This port has been tested on OpenBSD 6.7 Current macppc and works perfec > tly. This is a great surprise since powerpc OpenBSD was never a confirme > d supported OS. I've set this up to work on i386 and amd64 as well, whic > h are officially supported by Mini vMac. However I am unable to verify t > hey work at the moment. If you have time to test this port on amd64 or i > 386 that would be great. > > I did have to patch 2 files, just to specify cc instead of gcc. > > The homepage for Mini vMac is at https://gryphel.com/c/minivmac/ . I've > emulated System 1 and System 6 so far. > > The build system is like nothing I've ever seen before, but ports made i > t easy to work with. Let me know if you can help get this emulator into > ports, if you have any suggestions, or improvements to how I've made thi > s work. > > Besides testing amd64 and i386 I belive this is ready to be committed. > > Everything passes portcheck as well! > Anyone interested in this?
ok? [NEW] emulators/minivmac : classic mac emu (6 flavors!)
Hello ports, attached is a Mini vMac port for the latest version with 6 total flavors. Each flavor emulates a different Mac model, such as the M acintosh 128k, 512Ke, SE, Classic, SEFDHD, or II. The Macintosh Plus is emulated by default. This single port can emulate 7 different machines. Everything here except sound emulation works. OpenBSD has actually been officially supported for some time now, but sound still isn't implemente d. I've included a pkg/README with some quick start style information. It a lso mentions that sound emulation is not currently supported. This port has been tested on OpenBSD 6.7 Current macppc and works perfec tly. This is a great surprise since powerpc OpenBSD was never a confirme d supported OS. I've set this up to work on i386 and amd64 as well, whic h are officially supported by Mini vMac. However I am unable to verify t hey work at the moment. If you have time to test this port on amd64 or i 386 that would be great. I did have to patch 2 files, just to specify cc instead of gcc. The homepage for Mini vMac is at https://gryphel.com/c/minivmac/ . I've emulated System 1 and System 6 so far. The build system is like nothing I've ever seen before, but ports made i t easy to work with. Let me know if you can help get this emulator into ports, if you have any suggestions, or improvements to how I've made thi s work. Besides testing amd64 and i386 I belive this is ready to be committed. Everything passes portcheck as well! minivmac.tgz Description: GNU Zip compressed data
Re: curl with libidn
> Sent: Friday, June 05, 2020 at 1:03 AM > From: "Stuart Henderson" > To: "Alex Free" > Cc: "f.holop" , ports@openbsd.org > Subject: Re: curl with libidn > > On 2020/06/05 00:21, Alex Free wrote: > > > Sent: Friday, June 05, 2020 at 12:05 AM > > > From: "Stuart Henderson" > > > To: "Alex Free" > > > Cc: "f.holop" , ports@openbsd.org > > > Subject: Re: curl with libidn > > > > > > On 2020/06/04 22:39, Alex Free wrote: > > > > > Sent: Thursday, June 04, 2020 at 4:53 PM > > > > > From: "f.holop" > > > > > To: ports@openbsd.org > > > > > Subject: curl with libidn > > > > > > > > > > hi, > > > > > > > > > > atm curl is unable to open non ascii domains. > > > > > is there a reason why it's not compiled with libidn? > > > > > (same goes for lynx) > > > > > > > > > > -f > > > > > -- > > > > > > > > > > > > > > > > > > If it compiles fine a flavor should be added to both. > > > > > > hahaha no. > > > > > > > > > > Your right it should just be a dependency to both. > > If it's readded at all then it should just be a dependency (flavours > in common libraries are a big problem). (it would be libidn2 not libidn, > they are different codebases and supporting different IDNA specs). > > When IDN support was removed from the curl port before, upstream had > hurriedly switched from libidn to libidn2 (despite at the time libidn > being fairly well updated, and libidn2 having been mostly dead for > about 5 years). IIRC this was to avoid problems with differences > between the two IDNA specs (afaik both of which are still in use, > though I have some recollection of at least some TLDs disallowing > domains which conflict between the two? not sure..). > > Adding it would add more code to something that is quite a common > dependency. Maybe it's useful enough to be worth it (being from a > country with mostly 7-bit charset I don't get much of a vote in this ;) > but along with the upside of support IDNs, there is a downside to > pulling in (historically a bit buggy) code to all ports using the > library. > > FWIW here are some of the more important libidn2 bugs. > > CVE-2019-12290 > > GNU libidn2 before 2.2.0 fails to perform the roundtrip checks specified > in RFC3490 Section 4.2 when converting A-labels to U-labels. This makes > it possible in some circumstances for one domain to impersonate another. > By creating a malicious domain that matches a target domain except for > the inclusion of certain punycoded Unicode characters (that would be > discarded when converted first to a Unicode label and then back to an > ASCII label), arbitrary domains can be impersonated. > > CVE-2019-18224 > > idn2_to_ascii_4i in lib/lookup.c in GNU libidn2 before 2.1.1 has a > heap-based buffer overflow via a long domain string. > > CVE-2017-14062 > > Integer overflow in the decode_digit function in puny_decode.c in > Libidn2 before 2.0.4 allows remote attackers to cause a denial of > service or possibly have unspecified other impact. > > CVE-2017-14061 > > Integer overflow in the _isBidi function in bidi.c in Libidn2 before > 2.0.4 allows remote attackers to cause a denial of service or possibly > have unspecified other impact. > Why are flavors in common libraries a big problem putting aside the security issues and quality of code in this case?
Re: curl with libidn
> Sent: Friday, June 05, 2020 at 12:05 AM > From: "Stuart Henderson" > To: "Alex Free" > Cc: "f.holop" , ports@openbsd.org > Subject: Re: curl with libidn > > On 2020/06/04 22:39, Alex Free wrote: > > > Sent: Thursday, June 04, 2020 at 4:53 PM > > > From: "f.holop" > > > To: ports@openbsd.org > > > Subject: curl with libidn > > > > > > hi, > > > > > > atm curl is unable to open non ascii domains. > > > is there a reason why it's not compiled with libidn? > > > (same goes for lynx) > > > > > > -f > > > -- > > > > > > > > > > If it compiles fine a flavor should be added to both. > > hahaha no. > > Your right it should just be a dependency to both.
ok? [new] sysutils/cdirip
Extracts the proprietary DiscJugglar .cdi format. New versions of this software are under GPL but not compatible with big endian so version 0.6.2 is used instead. cdirip.tgz Description: GNU Zip compressed data
Re: curl with libidn
> Sent: Thursday, June 04, 2020 at 4:53 PM > From: "f.holop" > To: ports@openbsd.org > Subject: curl with libidn > > hi, > > atm curl is unable to open non ascii domains. > is there a reason why it's not compiled with libidn? > (same goes for lynx) > > -f > -- > > If it compiles fine a flavor should be added to both.
Re: does a new port have to be the latest version?
> Sent: Wednesday, June 03, 2020 at 4:05 PM > From: "Stuart Henderson" > To: "Alex Free" > Cc: "Renaud Allard" , ports@openbsd.org > Subject: Re: does a new port have to be the latest version? > > On 2020/06/03 14:58, Alex Free wrote: > > > Sent: Wednesday, June 03, 2020 at 2:24 PM > > > From: "Stuart Henderson" > > > To: "Renaud Allard" > > > Cc: ports@openbsd.org > > > Subject: Re: does a new port have to be the latest version? > > > > > > On 2020/06/03 14:17, Renaud Allard wrote: > > > > > > > > > > > > On 6/3/20 2:11 PM, Stuart Henderson wrote: > > > > > On 2020/06/03 13:54, Alex Free wrote: > > > > > > > > > > > > > > What is the program? > > > > > > > > > > > > > > > > > > > CDIrip, the current GitHub is at https://github.com/jozip/cdirip . > > > > > > > > > > > > > > > > yes 0.6.3 looks to be a bit of a step backwards there. looking at the > > > > > diff > > > > > it did also remove a duplicate write of &aCommSize though. > > > > > > > > > > Note that it doesn't have proper licensing so will need to be marked > > > > > as > > > > > PERMIT_PACKAGE/PERMIT_DISTFILES=no license (some mention of "version > > > > > developed on sourceforge under gpl" isn't a valid license grant). > > > > > > > > > https://github.com/jozip/cdirip/blob/master/LICENSE > > > > > > > > Mentions GPLV2 > > > > > > > > > > That is just a file in the distribution of the version on github. There's > > > no > > > indication that it was added by the original author of the code and the > > > "How > > > to Apply These Terms to Your New Programs" section hasn't been followed > > > in particular there is no "Copyright XXX you can redistribute it" etc. > > > The only valid copyright information I see in the whole distribution is > > > the one in https://github.com/jozip/cdirip/blob/master/audio.c which says > > > > > > /* Copyright (C) 1988-1991 Apple Computer, Inc. > > > * All rights reserved. > > > > > > and does not grant redistribution. > > > > > > > > > > Previous versions were not under the GPL, but the > > original author released 0.6.3 under the GPL. > > Just saying "released under GPL" without doing other steps isn't enough. > It needs at least a copyright line with a license grant somewhere > preferably on each file, that's why the license goes to some lengths to > explain how to do it. > > Also releasing some version under GPL doesn't mean that previous versions > are also automatically released under GPL. > > > Source for all previous versions were always > > available, and still are on the wayback machine of > > the original homepage. > > > > Essentially pre 0.6.3 is just source available. > > > > Dist file mirroring is okay right? Besides the > > I don't think it is OK for OpenBSD to do this (as in PERMIT_* etc can't > be set to Yes and it would need building from ports not installing from > packages). If you want to mirror the distfile yourself that would be your > responsibility. > > > wayback machine there is exactly one place I can > > find 0.6.2, and it’s on a gnome related mirror > > and in zip format. Right now I have the port’s > > master site set to my own with a .tar.gz of the > > source. > > I found it at > https://nold.in/lib/exe/fetch.php?media=projects:consoles:dreamcast:cdirip-0.6.2-linux.tar.bz2 > (a path like this requires certain fiddling to use as a source in ports, > should be possible but is annoying!). > > ... > > > Is the code actually invalid GPL due to the Apple code? NetBSD is > > hosting dist files containing the Apple code so is it ok? License > > newbie, thanks for your patience. > > IANAL and it may vary between jurisdictions anyway but my understanding > is "if you don't include a Copyright line and grant some specific rights > to allow redistribution then it can't be redistributed". Some OS care > more about this for things in packages than others (Debian in particular > usually get this right) some others seem to rely on "meh nobody's really > going to complain are they". > > Does everything look ok on the email I sent to ports? https://marc.info/?l=openbsd-ports&m=159123552330253&w=2
Re: *new* sysutils/cdirip - need i386/amd64 testers and ok
The original Makefile contained DOS line endings in it, which although
my patches could deal with fine they got lost in the original posting
and rendered the original patch unusable.
So i just decided to fix the problem at the source and modify the actual
distfile Makefile and remove the Makefile patch all together. Below (and
in the attachment) are the new diffs.
Now portcheck also completes with no issues.
Index: sysutils/cdirip/Makefile
===
RCS file: sysutils/cdirip/Makefile
diff -N sysutils/cdirip/Makefile
--- /dev/null 1 Jan 1970 00:00:00 -
+++ sysutils/cdirip/Makefile4 Jun 2020 01:39:31 -
@@ -0,0 +1,25 @@
+# $OpenBSD: Makefile,v 1.0 2020/06/02 04:36:48 alexfree Exp $
+
+ONLY_FOR_ARCHS = i386 amd64 macppc
+COMMENT = maniplulate and extract .cdi files
+DISTNAME = cdirip-0.6.2
+COMPILER = base-clang base-gcc ports-gcc
+CATEGORIES = sysutils
+HOMEPAGE = https://github.com/jozip/cdirip/
+
+MAINTAINER = Alex Free
+
+PERMIT_PACKAGE = No | not stated in copyright
+PERMIT_DISTFILES = No | not stated in copyright
+
+MASTER_SITES = https://home.macintosh.garden/~alexfree/distfiles/
+
+USE_GMAKE =Yes
+
+MAKE_FILE =Makefile.linux
+
+BUILD_DEPENDS =devel/gmake
+
+do-install:
+ ${INSTALL_SCRIPT} ${WRKSRC}/cdirip ${PREFIX}/bin/cdirip
+.include
Index: sysutils/cdirip/distinfo
===
RCS file: sysutils/cdirip/distinfo
diff -N sysutils/cdirip/distinfo
--- /dev/null 1 Jan 1970 00:00:00 -
+++ sysutils/cdirip/distinfo4 Jun 2020 01:39:31 -
@@ -0,0 +1,2 @@
+SHA256 (cdirip-0.6.2.tar.gz) = 1wg7niqZePOR4UqXNPbxdD57/mTLi1oyMjreSGRjFkA=
+SIZE (cdirip-0.6.2.tar.gz) = 11424
Index: sysutils/cdirip/pkg/DESCR
===
RCS file: sysutils/cdirip/pkg/DESCR
diff -N sysutils/cdirip/pkg/DESCR
--- /dev/null 1 Jan 1970 00:00:00 -
+++ sysutils/cdirip/pkg/DESCR 4 Jun 2020 01:39:31 -
@@ -0,0 +1 @@
+Extract DiscJugglar .cdi files for use with other burning software.
Index: sysutils/cdirip/pkg/PLIST
===
RCS file: sysutils/cdirip/pkg/PLIST
diff -N sysutils/cdirip/pkg/PLIST
--- /dev/null 1 Jan 1970 00:00:00 -
+++ sysutils/cdirip/pkg/PLIST 4 Jun 2020 01:39:31 -
@@ -0,0 +1,2 @@
+@comment $OpenBSD: PLIST,v$
+@bin bin/cdirip
final
Description: Binary data
*new* sysutils/cdirip - need i386/amd64 testers and ok
CDIrip allows you to extract the proprietary DoscJugglar format for use
in open source burning software. I’m porting 0.6.2 and not the latest
0.6.4 because 0.6.3 and above broke big endian.
With this software, I’ve been able to burn a bootable home brew CD-R
for an unmodified Sega Dreamcast with a Mac mini G4 running just OpenBSD.
This port has been only tested on macppc current, I’d really
appreciate if someone could verify that it works fine on i386 and amd64
as I have access to neither at the moment.
If I did anything wrong, let me know as this is my first port. Thanks!
Index: sysutils/cdirip/pkg/DESCR
===
RCS file: sysutils/cdirip/pkg/DESCR
diff -N sysutils/cdirip/pkg/DESCR
--- /dev/null 1 Jan 1970 00:00:00 -
+++ sysutils/cdirip/pkg/DESCR 3 Jun 2020 22:15:14 -
@@ -0,0 +1 @@
+Extract DiscJugglar .cdi files for use with other burning software.
Index: sysutils/cdirip/distinfo
===
RCS file: sysutils/cdirip/distinfo
diff -N sysutils/cdirip/distinfo
--- /dev/null 1 Jan 1970 00:00:00 -
+++ sysutils/cdirip/distinfo3 Jun 2020 22:11:58 -
@@ -0,0 +1,2 @@
+SHA256 (cdirip-0.6.2) = hzbUgwGzzXkXD8IU+19cMlTR74nMqzSHoDJElmk8c+A=
+SIZE (cdirip-0.6.2) = 11425
Index: sysutils/cdirip/Makefile
===
RCS file: sysutils/cdirip/Makefile
diff -N sysutils/cdirip/Makefile
--- /dev/null 1 Jan 1970 00:00:00 -
+++ sysutils/cdirip/Makefile3 Jun 2020 22:08:54 -
@@ -0,0 +1,32 @@
+# $OpenBSD: Makefile,v 1.0 2020/06/02 01:32:48 alexfree Exp $
+
+COMMENT= maniplulate and extract .cdi files
+ONLY_FOR_ARCHS = i386 amd64 macppc
+
+PKGNAME = cdirip-0.6.2
+
+CATEGORIES = sysutils
+
+HOMEPAGE = https://github.com/jozip/cdirip/
+
+MAINTAINER = Alex Free
+
+PERMIT_PACKAGE = No | not explicitly permitted
+PERMIT_DISTFILES = No | not explicitly permitted
+
+MASTER_SITES = https://home.macintosh.garden/~alexfree/distfiles/
+
+DISTFILES =cdirip-0.6.2
+
+COMPILER = base-clang ports-gcc base-gcc
+
+BUILD_DEPENDS =devel/gmake
+
+USE_GMAKE =Yes
+
+MAKE_FILE =Makefile.linux
+
+do-install:
+ ${INSTALL_SCRIPT} ${WRKSRC}/cdirip ${PREFIX}/bin/cdirip
+
+.include
Index: sysutils/cdirip/patches/patch-Makefile_linux
===
RCS file: sysutils/cdirip/patches/patch-Makefile_linux
diff -N sysutils/cdirip/patches/patch-Makefile_linux
--- /dev/null 1 Jan 1970 00:00:00 -
+++ sysutils/cdirip/patches/patch-Makefile_linux3 Jun 2020 22:13:47
-
@@ -0,0 +1,23 @@
+$OpenBSD$
+
+Index: Makefile.linux
+--- Makefile.linux.orig
Makefile.linux
+@@ -7,7 +7,7 @@
+
+
+ # Compiler
+-CC=gcc
++CC=cc
+ # Parameters given to the compiler
+ CFLAGS=-s -O1 -I/usr/include -I/include
+ # Output filename (*.exe)
+@@ -22,7 +22,7 @@ OBJS=cdirip.o buffer.o cdi.o common.o audio.o
+
+ all: compile_res
+ $(CC) -c $(SRCS) $(CFLAGS)
+- $(CC) -o $(OUTPUT) $(OBJS) $(CFLAGS)
++ $(CC) -o $(OUTPUT) $(OBJS) -lm $(CFLAGS)
+
+ compile_res:
+
Index: sysutils/cdirip/pkg/PLIST
===
RCS file: sysutils/cdirip/pkg/PLIST
diff -N sysutils/cdirip/pkg/PLIST
--- /dev/null 1 Jan 1970 00:00:00 -
+++ sysutils/cdirip/pkg/PLIST 3 Jun 2020 22:15:39 -
@@ -0,0 +1,2 @@
+@comment $OpenBSD: PLIST,v$
+@bin bin/cdirip
Re: does a new port have to be the latest version?
> Just saying "released under GPL" without doing other steps isn't enough. > It needs at least a copyright line with a license grant somewhere > preferably on each file, that's why the license goes to some lengths to > explain how to do it. > > Also releasing some version under GPL doesn't mean that previous versions > are also automatically released under GPL. > > > Source for all previous versions were always > > available, and still are on the wayback machine of > > the original homepage. > > > > Essentially pre 0.6.3 is just source available. > > > > Dist file mirroring is okay right? Besides the > > I don't think it is OK for OpenBSD to do this (as in PERMIT_* etc can't > be set to Yes and it would need building from ports not installing from > packages). If you want to mirror the distfile yourself that would be your > responsibility. > > > wayback machine there is exactly one place I can > > find 0.6.2, and it’s on a gnome related mirror > > and in zip format. Right now I have the port’s > > master site set to my own with a .tar.gz of the > > source. > > I found it at > https://nold.in/lib/exe/fetch.php?media=projects:consoles:dreamcast:cdirip-0.6.2-linux.tar.bz2 > (a path like this requires certain fiddling to use as a source in ports, > should be possible but is annoying!). > > ... > > > Is the code actually invalid GPL due to the Apple code? NetBSD is > > hosting dist files containing the Apple code so is it ok? License > > newbie, thanks for your patience. > > IANAL and it may vary between jurisdictions anyway but my understanding > is "if you don't include a Copyright line and grant some specific rights > to allow redistribution then it can't be redistributed". Some OS care > more about this for things in packages than others (Debian in particular > usually get this right) some others seem to rely on "meh nobody's really > going to complain are they". > > I just changed the permit values to no. I just checked your link and that build is indeed broken on big endian. The only version not broken is the one I found on that mirror. Another thing about that Nold guy, he seems to be throwing on his own license to version 0.6.2? https://github.com/Nold360/mksdiso/blob/master/COPYRIGHT Can I proceed with version 0.6.2? Just want to make sure everything is in order and correct. I’ll host it on my own site and have that ftp as a second master since it’s soo slow. Original site is below if you want to take a look. https://web.archive.org/web/20051127193031/http://cdirip.cjb.net:80/
Re: does a new port have to be the latest version?
> > > Note that it doesn't have proper licensing so will need to be marked as > > > PERMIT_PACKAGE/PERMIT_DISTFILES=no license (some mention of "version > > > developed on sourceforge under gpl" isn't a valid license grant). > > > > > https://github.com/jozip/cdirip/blob/master/LICENSE > > > > Mentions GPLV2 > > > > That is just a file in the distribution of the version on github. There's no > indication that it was added by the original author of the code and the "How > to Apply These Terms to Your New Programs" section hasn't been followed > in particular there is no "Copyright XXX you can redistribute it" etc. > The only valid copyright information I see in the whole distribution is > the one in https://github.com/jozip/cdirip/blob/master/audio.c which says > > /* Copyright (C) 1988-1991 Apple Computer, Inc. > * All rights reserved. > > and does not grant redistribution. > > So should I try to patch 0.6.3 to work on big endian? I’d rather not but if we can’t proceed with 0.6.2 I guess I have to try. Is the code actually invalid GPL due to the Apple code? NetBSD is hosting dist files containing the Apple code so is it ok? License newbie, thanks for your patience. Here is where I found cdirip 0.6.2 originally on that gnome related mirror https://ftp.gnome.org/mirror/archive/ftp.sunet.se/pub/mac/fink/?C=M;O=A (warning very slow) . Here’s the original site on archive.org https://web.archive.org/web/20050706012759/http://cdirip.cjb.net:80/ The original SourceForge page https://sourceforge.net/projects/cdimagetools/files/CDIRip/
Re: does a new port have to be the latest version?
> Sent: Wednesday, June 03, 2020 at 2:24 PM > From: "Stuart Henderson" > To: "Renaud Allard" > Cc: ports@openbsd.org > Subject: Re: does a new port have to be the latest version? > > On 2020/06/03 14:17, Renaud Allard wrote: > > > > > > On 6/3/20 2:11 PM, Stuart Henderson wrote: > > > On 2020/06/03 13:54, Alex Free wrote: > > > > > > > > > > What is the program? > > > > > > > > > > > > > CDIrip, the current GitHub is at https://github.com/jozip/cdirip . > > > > > > > > > > yes 0.6.3 looks to be a bit of a step backwards there. looking at the diff > > > it did also remove a duplicate write of &aCommSize though. > > > > > > Note that it doesn't have proper licensing so will need to be marked as > > > PERMIT_PACKAGE/PERMIT_DISTFILES=no license (some mention of "version > > > developed on sourceforge under gpl" isn't a valid license grant). > > > > > https://github.com/jozip/cdirip/blob/master/LICENSE > > > > Mentions GPLV2 > > > > That is just a file in the distribution of the version on github. There's no > indication that it was added by the original author of the code and the "How > to Apply These Terms to Your New Programs" section hasn't been followed > in particular there is no "Copyright XXX you can redistribute it" etc. > The only valid copyright information I see in the whole distribution is > the one in https://github.com/jozip/cdirip/blob/master/audio.c which says > > /* Copyright (C) 1988-1991 Apple Computer, Inc. > * All rights reserved. > > and does not grant redistribution. > > Previous versions were not under the GPL, but the original author released 0.6.3 under the GPL. Source for all previous versions were always available, and still are on the wayback machine of the original homepage. Essentially pre 0.6.3 is just source available. Dist file mirroring is okay right? Besides the wayback machine there is exactly one place I can find 0.6.2, and it’s on a gnome related mirror and in zip format. Right now I have the port’s master site set to my own with a .tar.gz of the source.
Re: does a new port have to be the latest version?
> > What is the program? > CDIrip, the current GitHub is at https://github.com/jozip/cdirip .
Re: does a new port have to be the latest version?
> > Version 0.6.2 works on big endian, which is what I’ll be using this > > software on a lot. > If you worked on a 0.6.2 port and 0.6.3 gets out before your port > submission, this is by no means any blocker. > This isn’t the case. 0.6.2 was released in 2002 and the latest version in 2018. However there was only one release in between the 2, in 2004 and there have not been massive changes to the core program. If there was a currently supported option for what this software does I would use it instead however this is the only option for big endian. > We encourage using the latest versions where possible, but if known > breakage is on the roadmap, there's little point in updating until > upstream fixed it - afterall, I even consider it a good sign that you > spotted the regression and hold back on updating it. > > On the other hand, ports stuck at a specific version without updates in > sight tend to be removed after longer periods of time without updates. > Even if they work 100% fine this is the case? > > NetBSD has a port of the newest version of this software. It looks like > > it wasn’t properly tested because they use no patches in their port > > yet produce PowerPC binaries. This is unconfirmed however because I > > don’t use NetBSD. > Reach out to them and ask. > > I’ve emailed NetBSD on this and am waiting for a response, I almost did so before writing this email to ports.
Re: does a new port have to be the latest version?
> I guess this depend of the port and how old the release you want to > include is. For a network daemon it's better if it's up to date but for > a game or non network tool, I think it's possible to have an older > version. > Well that’s good news. Version 0.6.2 is from 2002. Version 0.6.3 is from 2004, and 0.6.4 is the latest from 2018. This is a non network tool to extract a specific file type. A program like this doesn’t need constant updates.
Re: games/ioquake3 cvs current diffs adding ppc support
>
> You're right.
>
> > other than that it also looks good to me.
> >
>
>
> Index: Makefile
> ===
> RCS file: /cvs/ports/games/ioquake3/Makefile,v
> retrieving revision 1.25
> diff -u -p -u -p -r1.25 Makefile
> --- Makefile 12 Jul 2019 20:46:19 - 1.25
> +++ Makefile 1 Jun 2020 07:58:25 -
> @@ -1,7 +1,7 @@
> # $OpenBSD: Makefile,v 1.25 2019/07/12 20:46:19 sthen Exp $
>
> BROKEN-i386= need to free up a register
> -ONLY_FOR_ARCHS= amd64 i386
> +ONLY_FOR_ARCHS= amd64 i386 macppc
>
> COMMENT= clone of the original Quake III Arena
>
> @@ -33,7 +33,7 @@ ALL_TARGET= "release"
> USE_GMAKE= Yes
> NO_TEST= Yes
>
> -QUAKE_ARCH= ${ARCH:S/amd64/x86_64/:S/i386/x86/}
> +QUAKE_ARCH= ${ARCH:S/amd64/x86_64/:S/i386/x86/:S/macppc/ppc/}
> SUBST_VARS+= QUAKE_ARCH
>
> do-install:
> Index: patches/patch-Makefile
> ===
> RCS file: /cvs/ports/games/ioquake3/patches/patch-Makefile,v
> retrieving revision 1.2
> diff -u -p -u -p -r1.2 patch-Makefile
> --- patches/patch-Makefile16 Apr 2018 13:12:22 - 1.2
> +++ patches/patch-Makefile1 Jun 2020 07:58:25 -
> @@ -3,7 +3,16 @@ $OpenBSD: patch-Makefile,v 1.2 2018/04/1
> Index: Makefile
> --- Makefile.orig
> +++ Makefile
> -@@ -743,16 +743,16 @@ ifeq ($(PLATFORM),openbsd)
> +@@ -4,7 +4,7 @@
> + # GNU Make required
> + #
> + COMPILE_PLATFORM=$(shell uname | sed -e 's/_.*//' | tr '[:upper:]'
> '[:lower:]' | sed -e 's/\//_/g')
> +-COMPILE_ARCH=$(shell uname -m | sed -e 's/i.86/x86/' | sed -e
> 's/^arm.*/arm/')
> ++COMPILE_ARCH=$(shell uname -m | sed -e 's/i.86/x86/' | sed -e
> 's/macppc/ppc/' | sed -e 's/^arm.*/arm/')
> +
> + ifeq ($(COMPILE_PLATFORM),sunos)
> + # Solaris uname and GNU uname differ
> +@@ -769,16 +769,16 @@ ifeq ($(PLATFORM),openbsd)
> -pipe -DUSE_ICON -DMAP_ANONYMOUS=MAP_ANON
> CLIENT_CFLAGS += $(SDL_CFLAGS)
>
> @@ -23,7 +32,7 @@ Index: Makefile
> OPTIMIZE = $(OPTIMIZEVM) -ffast-math
> HAVE_VM_COMPILED=true
> else
> -@@ -1525,7 +1525,6 @@ Q3CPPOBJ = \
> +@@ -1562,7 +1562,6 @@ Q3CPPOBJ = \
> $(B)/tools/cpp/eval.o \
> $(B)/tools/cpp/include.o \
> $(B)/tools/cpp/hideset.o \
> Index: patches/patch-code_qcommon_q_platform_h
> ===
> RCS file: patches/patch-code_qcommon_q_platform_h
> diff -N patches/patch-code_qcommon_q_platform_h
> --- /dev/null 1 Jan 1970 00:00:00 -
> +++ patches/patch-code_qcommon_q_platform_h 1 Jun 2020 07:58:25 -
> @@ -0,0 +1,14 @@
> +$OpenBSD$
> +
> +Index: code/qcommon/q_platform.h
> +--- code/qcommon/q_platform.h.orig
> code/qcommon/q_platform.h
> +@@ -223,6 +223,8 @@ Foundation, Inc., 51 Franklin St, Fifth Floor, Boston,
> +
> + #ifdef __i386__
> + #define ARCH_STRING "x86"
> ++#elif defined __ppc__
> ++#define ARCH_STRING "ppc"
> + #elif defined __amd64__
> + #undef idx64
> + #define idx64 1
> Index: pkg/README
> ===
> RCS file: /cvs/ports/games/ioquake3/pkg/README,v
> retrieving revision 1.5
> diff -u -p -u -p -r1.5 README
> --- pkg/README4 Sep 2018 12:46:13 - 1.5
> +++ pkg/README1 Jun 2020 07:58:25 -
> @@ -19,3 +19,44 @@ rcctl enable ioq3ded && rcctl set ioq3de
>
> For more information on the dedicated server see here:
> http://wiki.ioquake3.org/Sys_Admin_Guide#Configuration_Files
> +
> +Macppc specifics
> +
> +
> +Additional configuration may be required, as noted below.
> +
> +OpenGL renderer
> +---
> +
> +The opengl2 renderer is not available on many of the supported graphics cards
> +and will prevent ioquake3 from starting with the default configuration.
> +Specifiying seta cl_renderer "opengl1" in the config file will allow use of
> the
> +opengl1 renderer.
> +
> +16-bit textures
> +---
> +
> +Graphical issues occur when using 16-bit textures on the Radeon 9200, 9600,
> and
> +9700. 32-bit textures should be used if this happens.
> +
> +Radeon 9700
> +---
> +
> +Weapons and fonts will not appear without specifying seta r_hdr "0" in the
> +config file. The Radeon 9200 and 9600 do not have this issue.
> +
> +Extensions should also be turned off by specifying seta r_allowExtensions "0"
> +in the config file.
> +
> +Radeon 9200
> +---
> +
> +Fullscreen requires the X11 resolution to match the one specified in the
> +ioquake3 config file. This has been tested in FVWM and Window Maker, and only
> +Window Maker displays fullscreen correctly out of the 2.
> +
> +The fastest graphics preset should be used in ioquake3. Resolution can then
> be
> +modified from there for a playable game.
> +
> +The main menu in ioquake3 has poor performance that other parts of the game
> do
> +not suffer from.
>
>
>
>
Excellent, thank you @charlene!
Re: games/ioquake3 cvs current diffs adding ppc support
> Sent: Sunday, May 31, 2020 at 10:43 AM > From: "Charlene Wendling" > To: "Kirill Bychkov" > Cc: "Alex Free" , "Landry Breuil" , > ports@openbsd.org, abie...@openbsd.org > Subject: Re: games/ioquake3 cvs current diffs adding ppc support > > Huh, looks my mail never made it to ports@ :D > > On Sun, 31 May 2020 09:43:46 +0300 > Kirill Bychkov wrote: > > > On Sun, May 31, 2020 02:28, Alex Free wrote: > > >> Sent: Saturday, May 30, 2020 at 9:45 PM > > >> From: "Charlene Wendling" > > >> To: "Landry Breuil" > > >> Cc: "Alex Free" , ports@openbsd.org, > > >> abie...@openbsd.org Subject: Re: games/ioquake3 cvs current diffs > > >> adding ppc support > > >> > > >> Hi, > > >> > > >> On Sat, 30 May 2020 09:36:25 +0200 > > >> Landry Breuil wrote: > > >> > > >> > On Sat, May 30, 2020 at 09:09:13AM +0200, Alex Free wrote: > > >> > > Successfully built and tested against current. > > >> > > > > >> > > Let me know if I can do anything else to make this happen. > > >> > > > > >> > > A new file named patch-code_qcommon_q_platform_h contains the > > >> > > following immediately below. > > >> > > > >> > note that you can do a cvs add of that new file, and cvs diff > > >> > will show it. > > >> > > > >> > > Below are the CVS diffs. > > >> > > > >> > usually, when sending a diff for a port, you to the cvs diff > > >> > from the port directory, otherwise the person applying it will > > >> > have to cd to /usr or use patch -p2 in that case. > > >> > > > >> > those are not strong remarks, your diff itself is fine, it's just > > >> > 'best practice to get used to' if you plan to send more diffs > > >> > (which are always welcome!) > > >> > > >> ^ Agreed :) > > >> > > >> It builds fine on macppc indeed, there are font glitches, but i > > >> don't have much time to fiddle with q3config.cfg since i can't > > >> read options. It requires to disable HDR at least to have proper > > >> weapons/font textures with my Radeon 9700. > > > > Hi, > > I see weapons, main menu (when option is highlighted) and console on > > my G5 with Radeon 9600 Pro. > > ok kirby@ > > > > >> > > >> Alex, if you had the issue and know what is needed to make glitches > > >> disappear, we should add it to pkg/README :) > > >> > > >> OK cwen@ either way, here is the diff as we usually expect it by > > >> the way. > > >> > > >> Charl?ne. > > >> > > >> > > [diff was here] > > > > Thank you all for informing me of how to submit things correctly. I > > > greatly appreciate the correct format for the patches submitted > > > here. > > > > > > As for the font issues, I only have one powerpc machine with > > > graphics acceleration support in OpenBSD 6.7. Mach64 DRI was > > > dropped years ago. > > > > > > My one machine has a Radeon 9200 32MB graphics card so I had to > > > change the renderer to opengl1 in q3cfg.cfg using the text below. > > > > > > seta cl_renderer "opengl1" > > > > > > Also, fullscreen is scaled incorrectly on my card, it is in the > > > corner of the screen and not completely visible. Windowed mode > > > works fine, I have it set in q3cfg.cfg using the text below. > > > > > > seta r_fullscreen "0" > > > > > > As I believe we are using different renderers (9700 supports > > > OpenGL2.0 AFAIK), maybe the opengl1 renderer will work better? I > > > haven?t had any font issues on my OpenGL 1.3 card, just the > > > fullscreen one which I work around by setting xrandr -s 640x480. > > > > > > Another thing I think might be important, on my radeon 9200 I have > > > to use the fastest preset for a playable game. Resolution can be > > > then be changed. > > > > > > Is this good to include in the readme? I can submit a new patch for > > > an updated readme if that is what should be done next. > > I think we should add a subsection that details that. See > /usr/ports/infrastructure/templates/README.template for the
Re: games/ioquake3 cvs current diffs adding ppc support
> Sent: Sunday, May 31, 2020 at 8:43 AM > From: "Kirill Bychkov" > To: "Alex Free" > Cc: "Charlene Wendling" , "Landry Breuil" > , ports@openbsd.org, abie...@openbsd.org > Subject: Re: games/ioquake3 cvs current diffs adding ppc support > > On Sun, May 31, 2020 02:28, Alex Free wrote: > >> Sent: Saturday, May 30, 2020 at 9:45 PM > >> From: "Charlene Wendling" > >> To: "Landry Breuil" > >> Cc: "Alex Free" , ports@openbsd.org, abie...@openbsd.org > >> Subject: Re: games/ioquake3 cvs current diffs adding ppc support > >> > >> Hi, > >> > >> On Sat, 30 May 2020 09:36:25 +0200 > >> Landry Breuil wrote: > >> > >> > On Sat, May 30, 2020 at 09:09:13AM +0200, Alex Free wrote: > >> > > Successfully built and tested against current. > >> > > > >> > > Let me know if I can do anything else to make this happen. > >> > > > >> > > A new file named patch-code_qcommon_q_platform_h contains the > >> > > following immediately below. > >> > > >> > note that you can do a cvs add of that new file, and cvs diff will > >> > show it. > >> > > >> > > Below are the CVS diffs. > >> > > >> > usually, when sending a diff for a port, you to the cvs diff from the > >> > port directory, otherwise the person applying it will have to cd to > >> > /usr or use patch -p2 in that case. > >> > > >> > those are not strong remarks, your diff itself is fine, it's just > >> > 'best practice to get used to' if you plan to send more diffs (which > >> > are always welcome!) > >> > >> ^ Agreed :) > >> > >> It builds fine on macppc indeed, there are font glitches, but i don't > >> have much time to fiddle with q3config.cfg since i can't read options. > >> It requires to disable HDR at least to have proper weapons/font > >> textures with my Radeon 9700. > > Hi, > I see weapons, main menu (when option is highlighted) and console on my G5 > with Radeon 9600 Pro. > ok kirby@ > > > > > > > Thank you all for informing me of how to submit things correctly. I > > greatly appreciate the correct format for the patches submitted here. > > > > As for the font issues, I only have one powerpc machine with graphics > > acceleration support in OpenBSD 6.7. Mach64 DRI was dropped years ago. > > > > My one machine has a Radeon 9200 32MB graphics card so I had to change > > the renderer to opengl1 in q3cfg.cfg using the text below. > > > > seta cl_renderer "opengl1" > > > > Also, fullscreen is scaled incorrectly on my card, it is in the corner > > of the screen and not completely visible. Windowed mode works fine, I > > have it set in q3cfg.cfg using the text below. > > > > seta r_fullscreen "0" > > > > As I believe we are using different renderers (9700 supports OpenGL2.0 > > AFAIK), maybe the opengl1 renderer will work better? I haven?t had any > > font issues on my OpenGL 1.3 card, just the fullscreen one which I work > > around by setting xrandr -s 640x480. > > > > Another thing I think might be important, on my radeon 9200 I have to > > use the fastest preset for a playable game. Resolution can be then be > > changed. > > > > Is this good to include in the readme? I can submit a new patch for an > > updated readme if that is what should be done next. > > > > > > > I’m jealous of all of you with OpenGL 2.0 cards... How’s the performance, what kind of FPS have you been seeing? Fullscreen is actually not broken at all on Radeon 9200 using the opengl1 renderer. FVWM will not do proper fullscreen no matter what I try, and that is my main window manager, hence my initial thoughts. However I have found a way to use real fullscreen with Window Maker. For fullscreen to work on this card, the current resolution has to match the one set in the Quake 3 config. The 9200 32MB can not do 1024x768 at an acceptable frame rate, but I can use 640x480 by executing xrandr -s 640x480 and then ioquake3 (with 640x480 in config). Thank you all for testing and helping in the process. What’s the next step to get this into ports? Everything works as expected, some graphics cards just need a few tweaks in the config file that should be documented.
Re: games/ioquake3 cvs current diffs adding ppc support
> Sent: Saturday, May 30, 2020 at 9:45 PM
> From: "Charlene Wendling"
> To: "Landry Breuil"
> Cc: "Alex Free" , ports@openbsd.org, abie...@openbsd.org
> Subject: Re: games/ioquake3 cvs current diffs adding ppc support
>
> Hi,
>
> On Sat, 30 May 2020 09:36:25 +0200
> Landry Breuil wrote:
>
> > On Sat, May 30, 2020 at 09:09:13AM +0200, Alex Free wrote:
> > > Successfully built and tested against current.
> > >
> > > Let me know if I can do anything else to make this happen.
> > >
> > > A new file named patch-code_qcommon_q_platform_h contains the
> > > following immediately below.
> >
> > note that you can do a cvs add of that new file, and cvs diff will
> > show it.
> >
> > > Below are the CVS diffs.
> >
> > usually, when sending a diff for a port, you to the cvs diff from the
> > port directory, otherwise the person applying it will have to cd to
> > /usr or use patch -p2 in that case.
> >
> > those are not strong remarks, your diff itself is fine, it's just
> > 'best practice to get used to' if you plan to send more diffs (which
> > are always welcome!)
>
> ^ Agreed :)
>
> It builds fine on macppc indeed, there are font glitches, but i don't
> have much time to fiddle with q3config.cfg since i can't read options.
> It requires to disable HDR at least to have proper weapons/font
> textures with my Radeon 9700.
>
> Alex, if you had the issue and know what is needed to make glitches
> disappear, we should add it to pkg/README :)
>
> OK cwen@ either way, here is the diff as we usually expect it by the way.
>
> Charlène.
>
>
> Index: Makefile
> ===
> RCS file: /cvs/ports/games/ioquake3/Makefile,v
> retrieving revision 1.25
> diff -u -p -u -p -r1.25 Makefile
> --- Makefile 12 Jul 2019 20:46:19 - 1.25
> +++ Makefile 30 May 2020 18:22:36 -
> @@ -1,7 +1,7 @@
> # $OpenBSD: Makefile,v 1.25 2019/07/12 20:46:19 sthen Exp $
>
> BROKEN-i386= need to free up a register
> -ONLY_FOR_ARCHS= amd64 i386
> +ONLY_FOR_ARCHS= amd64 i386 macppc
>
> COMMENT= clone of the original Quake III Arena
>
> @@ -33,7 +33,11 @@ ALL_TARGET="release"
> USE_GMAKE= Yes
> NO_TEST= Yes
>
> +.if ${MACHINE_ARCH} == "powerpc"
> +QUAKE_ARCH= ppc
> +.else
> QUAKE_ARCH= ${ARCH:S/amd64/x86_64/:S/i386/x86/}
> +.endif
> SUBST_VARS+= QUAKE_ARCH
>
> do-install:
> Index: patches/patch-Makefile
> ===
> RCS file: /cvs/ports/games/ioquake3/patches/patch-Makefile,v
> retrieving revision 1.2
> diff -u -p -u -p -r1.2 patch-Makefile
> --- patches/patch-Makefile16 Apr 2018 13:12:22 - 1.2
> +++ patches/patch-Makefile30 May 2020 18:22:36 -
> @@ -3,7 +3,16 @@ $OpenBSD: patch-Makefile,v 1.2 2018/04/1
> Index: Makefile
> --- Makefile.orig
> +++ Makefile
> -@@ -743,16 +743,16 @@ ifeq ($(PLATFORM),openbsd)
> +@@ -4,7 +4,7 @@
> + # GNU Make required
> + #
> + COMPILE_PLATFORM=$(shell uname | sed -e 's/_.*//' | tr '[:upper:]'
> '[:lower:]' | sed -e 's/\//_/g')
> +-COMPILE_ARCH=$(shell uname -m | sed -e 's/i.86/x86/' | sed -e
> 's/^arm.*/arm/')
> ++COMPILE_ARCH=$(shell uname -m | sed -e 's/i.86/x86/' | sed -e
> 's/macppc/ppc/' | sed -e 's/^arm.*/arm/')
> +
> + ifeq ($(COMPILE_PLATFORM),sunos)
> + # Solaris uname and GNU uname differ
> +@@ -769,16 +769,16 @@ ifeq ($(PLATFORM),openbsd)
> -pipe -DUSE_ICON -DMAP_ANONYMOUS=MAP_ANON
> CLIENT_CFLAGS += $(SDL_CFLAGS)
>
> @@ -23,7 +32,7 @@ Index: Makefile
> OPTIMIZE = $(OPTIMIZEVM) -ffast-math
> HAVE_VM_COMPILED=true
> else
> -@@ -1525,7 +1525,6 @@ Q3CPPOBJ = \
> +@@ -1562,7 +1562,6 @@ Q3CPPOBJ = \
> $(B)/tools/cpp/eval.o \
> $(B)/tools/cpp/include.o \
> $(B)/tools/cpp/hideset.o \
> Index: patches/patch-code_qcommon_q_platform_h
> ===
> RCS file: patches/patch-code_qcommon_q_platform_h
> diff -N patches/patch-code_qcommon_q_platform_h
> --- /dev/null 1 Jan 1970 00:00:00 -
> +++ patches/patch-code_qcommon_q_platform_h 30 May 2020 18:22:36 -
> @@ -0,0 +1,14 @@
> +$OpenBSD$
> +
> +Index: code/qcommon/q_platform.h
> +--- code/qcommon/q_platform.h.orig
> code/qcommon/q_platform.h
> +@@ -223,6 +223,8 @@ Foundation, Inc., 51 Franklin St, Fifth Floor, Boston,
> +
> + #ifdef __i38
games/ioquake3 cvs current diffs adding ppc support
Successfully built and tested against current.
Let me know if I can do anything else to make this happen.
A new file named patch-code_qcommon_q_platform_h contains the following
immediately below.
$OpenBSD$
Index: code/qcommon/q_platform.h
--- code/qcommon/q_platform.h.orig
+++ code/qcommon/q_platform.h
@@ -223,6 +223,8 @@ Foundation, Inc., 51 Franklin St, Fifth Floor, Boston,
#ifdef __i386__
#define ARCH_STRING "x86"
+#elif defined __ppc__
+#define ARCH_STRING "ppc"
#elif defined __amd64__
#undef idx64
#define idx64 1
Below are the CVS diffs.
Index: ports/games/ioquake3/patches/patch-Makefile
===
RCS file: /cvs/ports/games/ioquake3/patches/patch-Makefile,v
retrieving revision 1.2
diff -u -p -u -r1.2 patch-Makefile
--- ports/games/ioquake3/patches/patch-Makefile 16 Apr 2018 13:12:22 -
1.2
+++ ports/games/ioquake3/patches/patch-Makefile 30 May 2020 05:39:01 -
@@ -3,7 +3,16 @@ $OpenBSD: patch-Makefile,v 1.2 2018/04/1
Index: Makefile
--- Makefile.orig
+++ Makefile
-@@ -743,16 +743,16 @@ ifeq ($(PLATFORM),openbsd)
+@@ -4,7 +4,7 @@
+ # GNU Make required
+ #
+ COMPILE_PLATFORM=$(shell uname | sed -e 's/_.*//' | tr '[:upper:]'
'[:lower:]' | sed -e 's/\//_/g')
+-COMPILE_ARCH=$(shell uname -m | sed -e 's/i.86/x86/' | sed -e 's/^arm.*/arm/')
++COMPILE_ARCH=$(shell uname -m | sed -e 's/i.86/x86/' | sed -e 's/macppc/ppc/'
| sed -e 's/^arm.*/arm/')
+
+ ifeq ($(COMPILE_PLATFORM),sunos)
+ # Solaris uname and GNU uname differ
+@@ -769,16 +769,16 @@ ifeq ($(PLATFORM),openbsd)
-pipe -DUSE_ICON -DMAP_ANONYMOUS=MAP_ANON
CLIENT_CFLAGS += $(SDL_CFLAGS)
@@ -23,7 +32,7 @@ Index: Makefile
OPTIMIZE = $(OPTIMIZEVM) -ffast-math
HAVE_VM_COMPILED=true
else
-@@ -1525,7 +1525,6 @@ Q3CPPOBJ = \
+@@ -1562,7 +1562,6 @@ Q3CPPOBJ = \
$(B)/tools/cpp/eval.o \
$(B)/tools/cpp/include.o \
$(B)/tools/cpp/hideset.o \
Index: ports/games/ioquake3/Makefile
===
RCS file: /cvs/ports/games/ioquake3/Makefile,v
retrieving revision 1.25
diff -u -p -u -r1.25 Makefile
--- ports/games/ioquake3/Makefile 12 Jul 2019 20:46:19 - 1.25
+++ ports/games/ioquake3/Makefile 30 May 2020 05:35:47 -
@@ -1,7 +1,7 @@
# $OpenBSD: Makefile,v 1.25 2019/07/12 20:46:19 sthen Exp $
BROKEN-i386= need to free up a register
-ONLY_FOR_ARCHS= amd64 i386
+ONLY_FOR_ARCHS= amd64 i386 macppc
COMMENT= clone of the original Quake III Arena
@@ -33,7 +33,11 @@ ALL_TARGET= "release"
USE_GMAKE= Yes
NO_TEST= Yes
+.if ${MACHINE_ARCH} == "powerpc"
+QUAKE_ARCH=ppc
+.else
QUAKE_ARCH=${ARCH:S/amd64/x86_64/:S/i386/x86/}
+.endif
SUBST_VARS+= QUAKE_ARCH
do-install:
Re: what is the proper procedure for submitting changes to existing ports?
> > Are these diffs in the links below in proper format? Thanks for the help > > as I’ve > > never done this before. > > No - please send "cvs diff -u" or "git diff" depending on where you got your > ports tree from. > > > > The AltiVec patches are crucial to playing 360p > > x264 MP4 files on my 1.42GHz G4, as well as speeding up file conversion. > > The IOQuake3 patches are the first to support any PowerPC BSD, and were > > pretty straight forward to figure out. > > > > https://marc.info/?l=openbsd-ports&m=159072101614301&w=2 > > > > https://marc.info/?l=openbsd-ports&m=159071707413348&w=2 > > The altivec patch forces CC=gcc which is the old base-system gcc > which generally shouldn't be used any more. Since there is a problem > with clang then you can try setting COMPILER=ports-gcc to use a more > modern version of gcc from ports. > > Thank you very much for setting me on the right path. I will see if ports-gcc has the same bugs. I will also change all the patches to the correct format.
Re: what is the proper procedure for submitting changes to existing ports?
> Sent: Saturday, May 30, 2020 at 12:35 AM > From: "Stuart Henderson" > To: "Alex Free" > Cc: ports@openbsd.org > Subject: Re: what is the proper procedure for submitting changes to existing > ports? > > On 2020/05/30 00:23, Alex Free wrote: > > What is the proper procedure for sending changes and patches to existing > > ports? I have modified 3 ports and would like my changes to be commuted. > > My modifications are to: > > > > games/ioquake3 (adds PowerPC support for OpenBSD. IOQuake3 does > > currently support any PowerPC *BSD OS, I had to add support myself. > > x11/mplayer (adds an altivec flavor, crucial for good video playback) > > graphics/ffmpeg (adds an altivec flavor for increased performance and > > more) > > > > I have submitted patches for FFmpeg and IOQuake3 to this mailing list. I > > have also sent patches for Mplayer, FFmpeg, and IOQuake3 directly to > > the maintainers. Is this the proper way? > > > > Either mail to maintainer, or to list + maintainer, is good. > Please send unified diffs (preferably cvs diff -u or git diff > against either the main repository or the conversion on > github.com/openbsd). > > Re the altivec one, if it works, using ports-gcc would be better > than hardcoding CC=gcc to use the old base compiler that hasn't > been removed yet but afaik nothing should be using. > > Are these diffs in the links below in proper format? Thanks for the help as I’ve never done this before. The AltiVec patches are crucial to playing 360p x264 MP4 files on my 1.42GHz G4, as well as speeding up file conversion. The IOQuake3 patches are the first to support any PowerPC BSD, and were pretty straight forward to figure out. https://marc.info/?l=openbsd-ports&m=159072101614301&w=2 https://marc.info/?l=openbsd-ports&m=159071707413348&w=2
what is the proper procedure for submitting changes to existing ports?
What is the proper procedure for sending changes and patches to existing ports? I have modified 3 ports and would like my changes to be commuted. My modifications are to: games/ioquake3 (adds PowerPC support for OpenBSD. IOQuake3 does currently support any PowerPC *BSD OS, I had to add support myself. x11/mplayer (adds an altivec flavor, crucial for good video playback) graphics/ffmpeg (adds an altivec flavor for increased performance and more) I have submitted patches for FFmpeg and IOQuake3 to this mailing list. I have also sent patches for Mplayer, FFmpeg, and IOQuake3 directly to the maintainers. Is this the proper way?
powerpc support for port games/ioquake3
IOQuake3 does not not support PowerPC on any *BSD. In just 3 patches I
got it working on OpenBSD 6.7/macppc, graphics acceleration and all.
I do plan on sending this to IOQuake3 as well.
Makefile
4c4
< ONLY_FOR_ARCHS= amd64 i386
---
> ONLY_FOR_ARCHS= amd64 i386 macppc
35a36,38
> .if ${MACHINE_ARCH} == "powerpc"
> QUAKE_ARCH= ppc
> .else
36a40
> .endif
(Updated) patches/patch-Makefile
$OpenBSD: patch-Makefile,v 1.2 2018/04/16 13:12:22 abieber Exp $
Index: Makefile
--- Makefile.orig
+++ Makefile
@@ -4,7 +4,7 @@
# GNU Make required
#
COMPILE_PLATFORM=$(shell uname | sed -e 's/_.*//' | tr '[:upper:]' '[:lower:]'
| sed -e 's/\//_/g')
-COMPILE_ARCH=$(shell uname -m | sed -e 's/i.86/x86/' | sed -e 's/^arm.*/arm/')
+COMPILE_ARCH=$(shell uname -m | sed -e 's/i.86/x86/' | sed -e 's/macppc/ppc/'
| sed -e 's/^arm.*/arm/')
ifeq ($(COMPILE_PLATFORM),sunos)
# Solaris uname and GNU uname differ
@@ -769,16 +769,16 @@ ifeq ($(PLATFORM),openbsd)
-pipe -DUSE_ICON -DMAP_ANONYMOUS=MAP_ANON
CLIENT_CFLAGS += $(SDL_CFLAGS)
- OPTIMIZEVM = -O3
+ OPTIMIZEVM =
OPTIMIZE = $(OPTIMIZEVM) -ffast-math
ifeq ($(ARCH),x86_64)
-OPTIMIZEVM = -O3
+OPTIMIZEVM =
OPTIMIZE = $(OPTIMIZEVM) -ffast-math
HAVE_VM_COMPILED = true
else
ifeq ($(ARCH),x86)
-OPTIMIZEVM = -O3 -march=i586
+OPTIMIZEVM = -march=i586
OPTIMIZE = $(OPTIMIZEVM) -ffast-math
HAVE_VM_COMPILED=true
else
@@ -1562,7 +1562,6 @@ Q3CPPOBJ = \
$(B)/tools/cpp/eval.o \
$(B)/tools/cpp/include.o \
$(B)/tools/cpp/hideset.o \
- $(B)/tools/cpp/getopt.o \
$(B)/tools/cpp/unix.o
$(B)/tools/cpp/%.o: $(Q3CPPDIR)/%.c
(New) patch-code_qcommon_q_platform_h
$OpenBSD$
Index: code/qcommon/q_platform.h
--- code/qcommon/q_platform.h.orig
+++ code/qcommon/q_platform.h
@@ -223,6 +223,8 @@ Foundation, Inc., 51 Franklin St, Fifth Floor, Boston,
#ifdef __i386__
#define ARCH_STRING "x86"
+#elif defined __ppc__
+#define ARCH_STRING "ppc"
#elif defined __amd64__
#undef idx64
#define idx64 1
Update FFmpeg Makefile To Include AltiVec Flavor
Makefile diff
89,90d88
< --cc=${CC} \
< --disable-altivec \
129a128,138
>
> FLAVORS=altivec
> FLAVOR?=
>
> .if !${FLAVOR:Maltivec}
> CONFIGURE_ARGS+=--cc=${CC}
> CONFIGURE_ARGS+=--disable-altivec
> .else
> CONFIGURE_ARGS+=--cc=gcc
> CONFIGURE_ARGS+=--enable-altivec
> .endif
Due to some buggy AltiVec code present in FFmpeg 4.2.2, base clang can
not successfully build. Base gcc however has no issues in doing so.
I have tried patches linked at this URL
https://trac.ffmpeg.org/ticket/7861 . This allows base clang to build
a broken FFmpeg that gives a floating point exception error when
converting a file. For these reasons, I believe using base gcc is the
best solution.
Only tested on OpenBSD 6.7 macppc.
NEW: graphics/basis_universal
This is a new "supercompressed" GPU texture compression system. I'm grateful for any feedback. basis.tgz Description: application/tar-gz
Re: Update net/libsignal-protocol-c 2.3.2->3
Awesome. Test runs here too and Dino tested on amd64. Other Dino users, please yell about problems -- otherwise ok maintainer. 0001-Update-net-libsignal-protocol-c-2.3.2-3.patch.gz Description: application/gzip
[UPDATE] security/kpcli (3.2 -> 3.3)
This patch updates kpcli to version 3.3. Changelog: 2019-Aug-16 v3.3 - Allow open and save with key-only authentication, as requested in SF bug #35. - Prevent "multiple entries titled" warning in the /_found/ area, as reports in SF bug #36. - Fix two bugs affecting Windows, as reported in SourceForge patch #11. - Mark /_found entries as "*OLD" when listed, if they reside in a group named old. Addresses an issue where searches turn up "old" accounts. What I changed: There are no patches for this port. Only version in Makefile and checksums in distinfo. What I did/tested: * make test (No regression tests for kpcli-3.3) * /usr/ports/infrastructure/bin/portcheck * make port-lib-depends-check * make update-plist Everything looks ok for me. Tested on amd64. Also tested basic functionality of kpcli, like print version information, creating new DB, restarting kpcli, trying to open old DB, etc: $ kpcli KeePass CLI (kpcli) v3.3 is ready for operation. Type 'help' for a description of available commands. Type 'help ' for details on individual commands. kpcli:/> vers VERSIONS * kpcli: 3.3 * Perl: v5.30.1 * File::KeePass: 2.03 * Term::ShellUI: 0.92 * Term::ReadKey: 2.38 * Term::ReadLine: 1.17 * Capture::Tiny: 0.48 * Clipboard: 0.13 * Term::ReadLine::Gnu: 1.36 * Math::Random::ISAAC: not installed (optional) * Sub::Install: not installed (optional) ReadLine being used: Term::ReadLine::Gnu Operating system: openbsd kpcli:/> saveas password_database.kdbx Please provide the master password: * Retype to verify: * kpcli:/> open password_database.kdbx Please provide the master password: * Cheers, Alexander Index: Makefile === RCS file: /cvs/ports/security/kpcli/Makefile,v retrieving revision 1.10 diff -u -p -u -p -r1.10 Makefile --- Makefile 12 Jul 2019 20:49:04 - 1.10 +++ Makefile 27 Mar 2020 00:06:22 - @@ -2,7 +2,7 @@ COMMENT = cli browser for keepassx databases -DISTNAME = kpcli-3.2 +DISTNAME = kpcli-3.3 CATEGORIES = security EXTRACT_SUFX = .pl EXTRACT_ONLY = Index: distinfo === RCS file: /cvs/ports/security/kpcli/distinfo,v retrieving revision 1.4 diff -u -p -u -p -r1.4 distinfo --- distinfo 31 Jan 2018 07:56:52 - 1.4 +++ distinfo 27 Mar 2020 00:06:22 - @@ -1,2 +1,2 @@ -SHA256 (kpcli-3.2.pl) = YVobrhntDBMgdqgJsWKmbqDcIsHZkqjG4fLhqu365oc= -SIZE (kpcli-3.2.pl) = 197369 +SHA256 (kpcli-3.3.pl) = BN6YTWt5veuEaJv46qDi46qHVrfMqf/fNuGp0cDxzfw= +SIZE (kpcli-3.3.pl) = 199249
Re: [UPDATE] net/xl2tpd (1.3.14 -> 1.3.15)
On Sat, Feb 22, 2020 at 10:18 PM Alex Naumov wrote: > This patch updates xl2tpd to version 1.3.15. > > 'portcheck' reports some problems for 1.3.14 version: > * trailing whitespace in pkg/README > * 2 line(s) longer than 80 chars in pkg/README > > It's fixed now. > ok? > Cheers, > Alex > > >
Re: [UPDATE] devel/libev (4.27 -> 4.31)
On Wed, Mar 18, 2020 at 10:55 AM Stuart Henderson
wrote:
> On 2020/03/18 10:02, Alex Naumov wrote:
> > this patche updates GNU libev to version 4.31.
>
> Around 350 ports depend on this, what testing has been done?
>
>
Only ports itself stuff that described on
https://www.openbsd.org/faq/ports/testing.html
make test
/usr/ports/infrastructure/bin/portcheck
make port-lib-depends-check
No combinations with new packages/ports was tested.
> Also note the "p5-EV should probably be kept in sync" comment - the two
> ports use the same distfile and most of the changelog entries you show
> only relate to p5-EV (the "EV only" ones) ... (actually the word
> "probably" should probably be removed from the comment)
>
>
> > Changelog:
> >
> > 4.31 Fri Dec 20 21:58:29 CET 2019
> > - handle backends with minimum wait time a bit better by not
> > waiting in the presence of already-expired timers
> > (behaviour reported by Felipe Gasper).
> > - new feature: use timerfd to detect timejumps quickly,
> > can be disabled with the new EVFLAG_NOTIMERFD loop flag.
> > - document EV_USE_SIGNALFD feature macro.
> >
> > 4.30 (EV only)
> > - change non-autoconf test for __kernel_rwf_t by testing
> > LINUX_VERSION_CODE, the most direct test I could find.
> > - fix a bug in the io_uring backend that polled the wrong
> > backend fd, causing it to not work in many cases.
> >
> > 4.29 (EV only)
> > - add io uring autoconf and non-autoconf detection.
> > - disable io_uring when some header files are too old.
> >
> > 4.28 (EV only)
> > - linuxaio backend resulted in random memory corruption
> > when loop is forked.
> > - linuxaio backend might have tried to cancel an iocb
> > multiple times (was unable to trigger this).
> > - linuxaio backend now employs a generation counter to
> > avoid handling spurious events from cancelled requests.
> > - io_cancel can return EINTR, deal with it. also, assume
> > io_submit also returns EINTR.
> > - fix some other minor bugs in linuxaio backend.
> > - ev_tstamp type can now be overriden by defining EV_TSTAMP_T.
> > - cleanup: replace expect_true/false and noinline by their
> > libecb counterparts.
> > - move syscall infrastructure from ev_linuxaio.c to ev.c.
> > - prepare io_uring integration.
> > - tweak ev_floor.
> > - epoll, poll, win32 Sleep and other places that use millisecond
> > reslution now all try to round up times.
> > - solaris port backend didn't compile.
> > - abstract time constants into their macros, for more
> flexibility.
> >
> >
> >
> > Cheers,
> > Alex
>
> > Index: Makefile
> > ===
> > RCS file: /cvs/ports/devel/libev/Makefile,v
> > retrieving revision 1.25
> > diff -u -p -u -p -r1.25 Makefile
> > --- Makefile 31 Aug 2019 17:21:33 - 1.25
> > +++ Makefile 18 Mar 2020 08:57:17 -
> > @@ -3,7 +3,7 @@
> > COMMENT =high-performance event loop library
> >
> > # p5-EV should probably be kept in sync
> > -DISTNAME = libev-4.27
> > +DISTNAME = libev-4.31
> > CATEGORIES = devel
> >
> > SHARED_LIBS= ev 3.1 # 4.0
> > Index: distinfo
> > ===
> > RCS file: /cvs/ports/devel/libev/distinfo,v
> > retrieving revision 1.13
> > diff -u -p -u -p -r1.13 distinfo
> > --- distinfo 31 Aug 2019 17:21:33 - 1.13
> > +++ distinfo 18 Mar 2020 08:57:17 -
> > @@ -1,2 +1,2 @@
> > -SHA256 (libev-4.27.tar.gz) =
> LVUm/I2k8HLdXHPhj7sWZvXvjteLc7uhLhlc/dgQNE4=
> > -SIZE (libev-4.27.tar.gz) = 556658
> > +SHA256 (libev-4.31.tar.gz) =
> 7YVdK1IRjjLAwaajK9GMl/nmcRylEfXuEt47nszGblo=
> > +SIZE (libev-4.31.tar.gz) = 565540
> > Index: pkg/PLIST
> > ===
> > RCS file: /cvs/ports/devel/libev/pkg/PLIST,v
> > retrieving revision 1.3
> > diff -u -p -u -p -r1.3 PLIST
> > --- pkg/PLIST 23 Apr 2013 18:59:53 - 1.3
> > +++ pkg/PLIST 18 Mar 2020 08:57:17 -
> > @@ -1,7 +1,7 @@
> > @comment $OpenBSD: PLIST,v 1.3 2013/04/23 18:59:53 dcoppa Exp $
> > include/ev++.h
> > include/ev.h
> > -lib/libev.a
> > +@static-lib lib/libev.a
> > lib/libev.la
> > @lib lib/libev.so.${LIBev_VERSION}
> > @man man/man3/ev.3
>
>
[UPDATE] devel/libev (4.27 -> 4.31)
this patche updates GNU libev to version 4.31.
Changelog:
4.31 Fri Dec 20 21:58:29 CET 2019
- handle backends with minimum wait time a bit better by not
waiting in the presence of already-expired timers
(behaviour reported by Felipe Gasper).
- new feature: use timerfd to detect timejumps quickly,
can be disabled with the new EVFLAG_NOTIMERFD loop flag.
- document EV_USE_SIGNALFD feature macro.
4.30 (EV only)
- change non-autoconf test for __kernel_rwf_t by testing
LINUX_VERSION_CODE, the most direct test I could find.
- fix a bug in the io_uring backend that polled the wrong
backend fd, causing it to not work in many cases.
4.29 (EV only)
- add io uring autoconf and non-autoconf detection.
- disable io_uring when some header files are too old.
4.28 (EV only)
- linuxaio backend resulted in random memory corruption
when loop is forked.
- linuxaio backend might have tried to cancel an iocb
multiple times (was unable to trigger this).
- linuxaio backend now employs a generation counter to
avoid handling spurious events from cancelled requests.
- io_cancel can return EINTR, deal with it. also, assume
io_submit also returns EINTR.
- fix some other minor bugs in linuxaio backend.
- ev_tstamp type can now be overriden by defining EV_TSTAMP_T.
- cleanup: replace expect_true/false and noinline by their
libecb counterparts.
- move syscall infrastructure from ev_linuxaio.c to ev.c.
- prepare io_uring integration.
- tweak ev_floor.
- epoll, poll, win32 Sleep and other places that use millisecond
reslution now all try to round up times.
- solaris port backend didn't compile.
- abstract time constants into their macros, for more flexibility.
Cheers,
Alex
Index: Makefile
===
RCS file: /cvs/ports/devel/libev/Makefile,v
retrieving revision 1.25
diff -u -p -u -p -r1.25 Makefile
--- Makefile 31 Aug 2019 17:21:33 - 1.25
+++ Makefile 18 Mar 2020 08:57:17 -
@@ -3,7 +3,7 @@
COMMENT = high-performance event loop library
# p5-EV should probably be kept in sync
-DISTNAME = libev-4.27
+DISTNAME = libev-4.31
CATEGORIES = devel
SHARED_LIBS= ev 3.1 # 4.0
Index: distinfo
===
RCS file: /cvs/ports/devel/libev/distinfo,v
retrieving revision 1.13
diff -u -p -u -p -r1.13 distinfo
--- distinfo 31 Aug 2019 17:21:33 - 1.13
+++ distinfo 18 Mar 2020 08:57:17 -
@@ -1,2 +1,2 @@
-SHA256 (libev-4.27.tar.gz) = LVUm/I2k8HLdXHPhj7sWZvXvjteLc7uhLhlc/dgQNE4=
-SIZE (libev-4.27.tar.gz) = 556658
+SHA256 (libev-4.31.tar.gz) = 7YVdK1IRjjLAwaajK9GMl/nmcRylEfXuEt47nszGblo=
+SIZE (libev-4.31.tar.gz) = 565540
Index: pkg/PLIST
===
RCS file: /cvs/ports/devel/libev/pkg/PLIST,v
retrieving revision 1.3
diff -u -p -u -p -r1.3 PLIST
--- pkg/PLIST 23 Apr 2013 18:59:53 - 1.3
+++ pkg/PLIST 18 Mar 2020 08:57:17 -
@@ -1,7 +1,7 @@
@comment $OpenBSD: PLIST,v 1.3 2013/04/23 18:59:53 dcoppa Exp $
include/ev++.h
include/ev.h
-lib/libev.a
+@static-lib lib/libev.a
lib/libev.la
@lib lib/libev.so.${LIBev_VERSION}
@man man/man3/ev.3
[UPDATE] devel/help2man (1.47.12 -> 1.47.13)
Hey,
this patch updates GNU help2man to version 1.47.13.
Changelog since 1.47.12 says:
help2man (1.47.13) unstable; urgency=medium
* Merge change from Po-Chuan Hsieh to suppress creation of an empty
pkglibdir when nls is disabled.
* Remove install_dirs target entirely, add explicit $(MKINSTALLDIRS)
before each $(INSTALL_{DATA,PROGRAM}) call.
* Update parsing of --version to allow multi-word programs when
constructing the placeholder NAME paragraph (thanks to Jarno Suni).
Cheers,
Alex
Index: Makefile
===
RCS file: /cvs/ports/devel/help2man/Makefile,v
retrieving revision 1.29
diff -u -p -u -p -r1.29 Makefile
--- Makefile 21 Jan 2020 08:15:19 - 1.29
+++ Makefile 18 Mar 2020 08:06:00 -
@@ -2,7 +2,7 @@
COMMENT= generates simple manual pages from program output
-DISTNAME= help2man-1.47.12
+DISTNAME= help2man-1.47.13
EXTRACT_SUFX= .tar.xz
CATEGORIES= devel
MASTER_SITES= ${MASTER_SITE_GNU:=help2man/}
Index: distinfo
===
RCS file: /cvs/ports/devel/help2man/distinfo,v
retrieving revision 1.18
diff -u -p -u -p -r1.18 distinfo
--- distinfo 21 Jan 2020 08:15:19 - 1.18
+++ distinfo 18 Mar 2020 08:06:00 -
@@ -1,2 +1,2 @@
-SHA256 (help2man-1.47.12.tar.xz) = fQumTPnRbsl8wRqvtlm1Wqe97JkHL/Kuxfzs8PvqsWA=
-SIZE (help2man-1.47.12.tar.xz) = 202252
+SHA256 (help2man-1.47.13.tar.xz) = t/i7rR8sQF23R+P1pNXh7dxjs2AiHIJL95dI8ntWBSM=
+SIZE (help2man-1.47.13.tar.xz) = 202480
[UPDATE] net/libircclient (1.9 -> 1.10)
this patch updates libircclient to version 1.10. 'make test' and 'make port-lib-depends-check' and 'portcheck' are OK. Cheers, Alex Index: Makefile === RCS file: /cvs/ports/net/libircclient/Makefile,v retrieving revision 1.10 diff -u -p -u -p -r1.10 Makefile --- Makefile 12 Jul 2019 20:48:30 - 1.10 +++ Makefile 25 Feb 2020 21:56:51 - @@ -1,7 +1,7 @@ # $OpenBSD: Makefile,v 1.10 2019/07/12 20:48:30 sthen Exp $ COMMENT = library which implements the IRC protocol -DISTNAME = libircclient-1.9 +DISTNAME = libircclient-1.10 CATEGORIES = net HOMEPAGE = http://www.ulduzsoft.com/linux/libircclient/ Index: distinfo === RCS file: /cvs/ports/net/libircclient/distinfo,v retrieving revision 1.3 diff -u -p -u -p -r1.3 distinfo --- distinfo 29 Jan 2018 00:04:23 - 1.3 +++ distinfo 25 Feb 2020 21:56:51 - @@ -1,2 +1,2 @@ -SHA256 (libircclient-1.9.tar.gz) = gcOX7uYYZnvM/olgNSul+CnIwum63CcFlLkRKM2JwGQ= -SIZE (libircclient-1.9.tar.gz) = 291086 +SHA256 (libircclient-1.10.tar.gz) = u7JvOvNIslLFIEkXp/kc/fFy8bavv03x5WGwPiBQPC0= +SIZE (libircclient-1.10.tar.gz) = 288863
[UPDATE] emulators/fuse (1.5.2 -> 1.5.7)
this patch updates FUSE to version 1.5.7. 'portcheck' and 'make test' are OK. Cheers, Alex Index: Makefile === RCS file: /cvs/ports/emulators/fuse/Makefile,v retrieving revision 1.45 diff -u -p -u -p -r1.45 Makefile --- Makefile 12 Jul 2019 20:46:08 - 1.45 +++ Makefile 25 Feb 2020 20:43:47 - @@ -1,7 +1,7 @@ # $OpenBSD: Makefile,v 1.45 2019/07/12 20:46:08 sthen Exp $ COMMENT= Free Unix Spectrum Emulator -DISTNAME= fuse-1.5.2 +DISTNAME= fuse-1.5.7 CATEGORIES= emulators HOMEPAGE= http://fuse-emulator.sourceforge.net/ Index: distinfo === RCS file: /cvs/ports/emulators/fuse/distinfo,v retrieving revision 1.23 diff -u -p -u -p -r1.23 distinfo --- distinfo 2 May 2018 20:51:14 - 1.23 +++ distinfo 25 Feb 2020 20:43:47 - @@ -1,2 +1,2 @@ -SHA256 (fuse-1.5.2.tar.gz) = FBVQ4u0nDYADBzM7Hj1YirddklIkNM+ClIdV6zj/vVo= -SIZE (fuse-1.5.2.tar.gz) = 1626746 +SHA256 (fuse-1.5.7.tar.gz) = 8OJYPyZCzcOypzeRDSTiidRuT34VGAXjsIJwJLK0Xk0= +SIZE (fuse-1.5.7.tar.gz) = 1634568 Index: pkg/PLIST === RCS file: /cvs/ports/emulators/fuse/pkg/PLIST,v retrieving revision 1.10 diff -u -p -u -p -r1.10 PLIST --- pkg/PLIST 22 Dec 2017 13:52:10 - 1.10 +++ pkg/PLIST 25 Feb 2020 20:43:47 - @@ -1,6 +1,5 @@ @comment $OpenBSD: PLIST,v 1.10 2017/12/22 13:52:10 fcambus Exp $ !%%gtk%% -%%gtk%% @bin bin/fuse @man man/man1/fuse.1 share/fuse/ @@ -9,6 +8,7 @@ share/fuse/128-1.rom share/fuse/48.rom share/fuse/cassette.bmp share/fuse/disciple.rom +%%gtk%% share/fuse/keyboard.scr share/fuse/microdrive.bmp share/fuse/plus2-0.rom
[UPDATE] fonts/inter (3.11 -> 3.12)
this patch updates inter to version 3.12. 'portcheck' returns OK. Port has no tests, so 'make test' also returns OK. Cheers, Alex Index: Makefile === RCS file: /cvs/ports/fonts/inter/Makefile,v retrieving revision 1.4 diff -u -p -u -p -r1.4 Makefile --- Makefile 8 Nov 2019 21:43:22 - 1.4 +++ Makefile 25 Feb 2020 00:59:38 - @@ -2,7 +2,7 @@ COMMENT = typeface carefully crafted & designed for computer screens -V = 3.11 +V = 3.12 DISTNAME = Inter-$V PKGNAME = inter-$V Index: distinfo === RCS file: /cvs/ports/fonts/inter/distinfo,v retrieving revision 1.3 diff -u -p -u -p -r1.3 distinfo --- distinfo 8 Nov 2019 21:43:22 - 1.3 +++ distinfo 25 Feb 2020 00:59:38 - @@ -1,2 +1,2 @@ -SHA256 (Inter-3.11.zip) = RUlbLCwKZKXeGoemzuMia5KwkDnMFEU0tWJHvpuLBok= -SIZE (Inter-3.11.zip) = 18676371 +SHA256 (Inter-3.12.zip) = rRjcCV4jMBzh6D97B45QhV0RDupGaXZW1y6w723C5vE= +SIZE (Inter-3.12.zip) = 18521697
python 2.7.16p1 is broken? (-current, aarch64)
Hey ports@, I'm asking just to be sure that I'm not the only one who has this problem. By trying to build ports/packages dependent on python 2.7 on my arm64 machine I get this error: ... ===> Building package for python-2.7.16p1 Create /usr/packages/aarch64/all/python-2.7.16p1.tgz Creating package python-2.7.16p1 checksumming|***| 6% Error: /usr/obj/ports/Python-2.7.16/fake-arm64/usr/local/lib/libpython2.7.so.0.0 does not exist pkg_create: can't continue By trying to install python 2.7 on the same machine I also get error: # pkg_add python quirks-3.232 signed on 2020-02-14T23:21:22Z Ambiguous: choose package for python a 0: 1: python-2.7.17p1 2: python-3.7.6p1 3: python-3.8.1 Your choice: 1 Can't install python-2.7.17p1 because of libraries |library sqlite3.37.10 not found | /usr/local/lib/libsqlite3.so.37.7 (sqlite3-3.29.0): minor is too small Direct dependencies for python-2.7.17p1 resolve to bzip2-1.0.8 libffi-3.2.1p5 sqlite3-3.29.0 gettext-runtime-0.20.1p0 Full dependency tree is sqlite3-3.29.0 gettext-runtime-0.20.1p0 libffi-3.2.1p5 bzip2-1.0.8 libiconv-1.16p0 Couldn't install python-2.7.17p1 # I don't have this problem on my -current amd64 systems. Can somebody reproduce this problem on arm64 or just tell me why I get this errors? Thanks, Alex
[UPDATE] security/libassuan (2.5.1 -> 2.5.3)
Greetings, this patch updates GNU libassuan to version 2.5.3. Patches should be removed, since they were added to the upstream code base. 'portcheck ' returns 0. All tests are OK: $ make test ===> Regression tests for libassuan-2.5.3 Making check in m4 Making check in src make check-am Making check in doc Making check in tests make check-am make check-TESTS PASS: version Received data `Your lucky number is 3552664958674928. Watch for it everywhere.' PASS: pipeconnect fdpassing[323]: chan_6 -> OK Pleased to meet you, process 43202 fdpassing[323]: chan_6 <- # descriptor 6 is in flight fdpassing[323]: chan_6 <- INPUT FD fdpassing[323]: chan_6 -> OK fdpassing[323]: chan_6 <- ECHO fdpassing[323]: chan_6 -> OK fdpassing[323]: chan_6 <- # descriptor 6 is in flight fdpassing[323]: chan_6 <- INPUT FD fdpassing[323]: chan_6 -> OK fdpassing[323]: chan_6 <- ECHO fdpassing[323]: chan_6 -> OK fdpassing[323]: chan_6 <- # descriptor 6 is in flight fdpassing[323]: chan_6 <- INPUT FD fdpassing[323]: chan_6 -> OK fdpassing[323]: chan_6 <- ECHO fdpassing[323]: chan_6 -> OK fdpassing[323]: chan_6 <- # descriptor 6 is in flight fdpassing[323]: chan_6 <- INPUT FD fdpassing[323]: chan_6 -> OK fdpassing[323]: chan_6 <- ECHO fdpassing[323]: chan_6 -> OK fdpassing[323]: chan_6 <- # descriptor 6 is in flight fdpassing[323]: chan_6 <- INPUT FD fdpassing[323]: chan_6 -> OK fdpassing[323]: chan_6 <- ECHO fdpassing[323]: chan_6 -> OK fdpassing[323]: chan_6 <- # descriptor 6 is in flight fdpassing[323]: chan_6 <- INPUT FD fdpassing[323]: chan_6 -> OK fdpassing[323]: chan_6 <- ECHO fdpassing[323]: chan_6 -> OK fdpassing[323]: chan_6 <- BYE fdpassing[323]: chan_6 -> OK closing connection PASS: fdpassing == All 3 tests passed == Have a nice weekend, Alex Index: Makefile === RCS file: /cvs/ports/security/libassuan/Makefile,v retrieving revision 1.22 diff -u -p -u -p -r1.22 Makefile --- Makefile 12 Jul 2019 20:49:04 - 1.22 +++ Makefile 23 Feb 2020 10:04:46 - @@ -2,8 +2,7 @@ COMMENT= IPC library used by GnuPG and gpgme -DISTNAME= libassuan-2.5.1 -REVISION= 0 +DISTNAME= libassuan-2.5.3 SHARED_LIBS += assuan2.1 # 8.1 Index: distinfo === RCS file: /cvs/ports/security/libassuan/distinfo,v retrieving revision 1.11 diff -u -p -u -p -r1.11 distinfo --- distinfo 10 Jan 2018 10:59:50 - 1.11 +++ distinfo 23 Feb 2020 10:04:46 - @@ -1,2 +1,2 @@ -SHA256 (libassuan-2.5.1.tar.bz2) = R/lsN7TyqsKJ8LwbrPqL2LSyCaSI09FeIinLbMmyZEk= -SIZE (libassuan-2.5.1.tar.bz2) = 564857 +SHA256 (libassuan-2.5.3.tar.bz2) = kbywQDhmtOfEvBzFLtTDZKm1QUs5lPcYxwMD9/dl5wI= +SIZE (libassuan-2.5.3.tar.bz2) = 572348
[UPDATE] net/xl2tpd (1.3.14 -> 1.3.15)
This patch updates xl2tpd to version 1.3.15. 'portcheck' reports some problems for 1.3.14 version: * trailing whitespace in pkg/README * 2 line(s) longer than 80 chars in pkg/README It's fixed now. Cheers, Alex ? xl2tpd-1.3.15.diff Index: Makefile === RCS file: /cvs/ports/net/xl2tpd/Makefile,v retrieving revision 1.20 diff -u -p -u -p -r1.20 Makefile --- Makefile 12 Jul 2019 20:48:52 - 1.20 +++ Makefile 22 Feb 2020 21:13:42 - @@ -4,7 +4,7 @@ COMMENT= l2tp client/server GH_ACCOUNT= xelerance GH_PROJECT= xl2tpd -GH_TAGNAME= v1.3.14 +GH_TAGNAME= v1.3.15 CATEGORIES= net Index: distinfo === RCS file: /cvs/ports/net/xl2tpd/distinfo,v retrieving revision 1.8 diff -u -p -u -p -r1.8 distinfo --- distinfo 18 Apr 2019 17:30:45 - 1.8 +++ distinfo 22 Feb 2020 21:13:42 - @@ -1,2 +1,2 @@ -SHA256 (xl2tpd-1.3.14.tar.gz) = /1oIBv7MWMe5y8YlEXpFIcBUZSKl9ZUf+27r2rmYYQ8= -SIZE (xl2tpd-1.3.14.tar.gz) = 523992 +SHA256 (xl2tpd-1.3.15.tar.gz) = DRSb+dL32DiAbmo2/XpnbQO/JG0reGnhbJRTMOE7ki4= +SIZE (xl2tpd-1.3.15.tar.gz) = 524960 Index: pkg/README === RCS file: /cvs/ports/net/xl2tpd/pkg/README,v retrieving revision 1.8 diff -u -p -u -p -r1.8 README --- pkg/README 4 Sep 2018 12:46:19 - 1.8 +++ pkg/README 22 Feb 2020 21:13:42 - @@ -26,7 +26,7 @@ Control mechanisms == When xl2tpd is started, it does not automatically connect. Instead it is controlled by writing simple commands to a fifo (you may be familiar with -this style from isakmpd), e.g.: +this style from isakmpd), e.g.: echo '[command] [config_name]' > /var/run/xl2tpd/l2tp-control @@ -100,8 +100,10 @@ And confirm that the tunnel does actuall # ipsecctl -sa FLOWS: -flow esp in proto udp from $server port l2tp to $me peer $server srcid $myhostname dstid $server/32 type use -flow esp out proto udp from $me to $server port l2tp peer $server srcid $myhostname dstid $server/32 type require +flow esp in proto udp from $server port l2tp to $me peer $server \ +srcid $myhostname dstid $server/32 type use +flow esp out proto udp from $me to $server port l2tp peer $server \ +srcid $myhostname dstid $server/32 type require SAD: esp transport from $me to $server spi 0x1037c0f2 auth hmac-sha1 enc aes
[UPDATE] devel/src (1.18 -> 1.28)
This patch updates devel/src from 1.18 to 1.28.
Unfortunately there are a couple of tests failing, which are either related
to 'fast-export roundtrip' or 'fast-import roundtrip'. I'm not sure if
these failures are related to OpenBSD, although the code in srctest looks
sane.
Maybe somebody from the community can help to improve this patch. The
faling tests are disabled by commenting out two 'check's. All other tests
are OK.
Cheers,
Alex
diff --git Makefile Makefile
index 0217634b4a3..3646bcb5c82 100644
--- Makefile
+++ Makefile
@@ -2,8 +2,7 @@
COMMENT = Simple Revision Control
-DISTNAME = src-1.18
-REVISION = 0
+DISTNAME = src-1.28
CATEGORIES = devel
@@ -27,7 +26,8 @@ TEST_DEPENDS = devel/git \
USE_GMAKE = Yes
NO_BUILD = Yes
-TEST_ENV = PYLINTHOME=${WRKSRC}/.pylint.d
+TEST_ENV = MAKE_PROGRAM=${MAKE_PROGRAM} \
+ PYLINTHOME=${WRKSRC}/.pylint.d
TEST_TARGET = check
post-extract:
diff --git distinfo distinfo
index 77223a25a1e..300602c05aa 100644
--- distinfo
+++ distinfo
@@ -1,2 +1,2 @@
-SHA256 (src-1.18.tar.gz) = zAiXwXY/V+Zif9kSoxXeVVTku1P6CVjIV4Ij5TecGlg=
-SIZE (src-1.18.tar.gz) = 52692
+SHA256 (src-1.28.tar.gz) = 7kSPF+DeB+7XSRiL8rl3IR/GCTFLB56+bCNIWscvebo=
+SIZE (src-1.28.tar.gz) = 56805
diff --git patches/patch-Makefile patches/patch-Makefile
new file mode 100644
index 000..2ecb699b15b
--- /dev/null
+++ patches/patch-Makefile
@@ -0,0 +1,14 @@
+$OpenBSD$
+
+Index: Makefile
+--- Makefile.orig
Makefile
+@@ -13,7 +13,7 @@ SOURCES = README INSTALL COPYING NEWS TODO src srctest
+ all: src.1
+
+ check: pylint
+- make pylint
++ ${MAKE_PROGRAM} pylint
+ ./srctest -b rcs -p python2
+ ./srctest -b sccs -p python2
+ ./srctest -b rcs -p python3
diff --git patches/patch-srctest patches/patch-srctest
index 56bba19b61b..49342e7835b 100644
--- patches/patch-srctest
+++ patches/patch-srctest
@@ -5,7 +5,25 @@ See upstream merge request https://gitlab.com/esr/src/merge_requests/20
Index: srctest
--- srctest.orig
+++ srctest
-@@ -1492,7 +1492,10 @@ author Eric Sunshine 1509732
+@@ -299,7 +299,7 @@ test_export () {
+ cat $srcfi | (cd foo >/dev/null; git init --quiet; git fast-import --quiet)
+ (cd foo >/dev/null; git fast-export --all) >$gitfi
+ diff $DIFFOPTS $srcfi $gitfi
+-check "fast-export roundtrip: $testname"
++#check "fast-export roundtrip: $testname"
+ rm -fr foo
+ }
+
+@@ -343,7 +343,7 @@ else
+
+ $src $TESTOPTS fast-export testfile1 >testfile1.fi &&
+ diff -u filename-git.fi testfile1.fi
+-check "fast-import roundtrip"
++#check "fast-import roundtrip"
+ fi
+
+ $src $TESTOPTS move testfile1 newname1
+@@ -1510,7 +1510,10 @@ author Eric Sunshine 1509732
committer Roy G. Biv 1511228715 +
EOF
Re: [UPDATE] net/ipcheck (207 -> 222)
On Mon, Feb 17, 2020 at 9:33 PM Björn Ketelaars < bjorn.ketela...@hydroxide.nl> wrote: > On Mon 17/02/2020 20:36, Alex Naumov wrote: > > REVISION should be removed as version has been bumped. > > Thank you, Björn. > > > > > > > > On Sun, Feb 16, 2020 at 11:55 PM Alex Naumov < > alexander_nau...@opensuse.org> > > wrote: > > > > > Hi, > > > > > > this is the diff to update ipcheck to the latest release (207 -> 222). > > I had another look at ipcheck: > > http://ipcheck.sourceforge.net/releases/old.html lists two versions that > are newer than 222, and https://sourceforge.net/projects/ipcheck/files/ > hosts an even newer version: 251. The latter btw has been released in > 2013. > The homepage of ipcheck was last updated in 2011. > > Is there a reason that you want to update this port to 222? Version 222 comes from portroach. It's my first experience with ports/packaging. I just took something simple, what has no dependencies. etc. I probably would have to check the latest version twice. Thank you for check! Do you know > if there is a changelog of some sort? Is this tool still > useful/relevant? >
Re: [UPDATE] net/ipcheck (207 -> 222)
REVISION should be removed as version has been bumped.
Thank you, Björn.
On Sun, Feb 16, 2020 at 11:55 PM Alex Naumov
wrote:
> Hi,
>
> this is the diff to update ipcheck to the latest release (207 -> 222).
>
> Ok?
>
> Cheers,
> Alex
>
? ipcheck-222.diff
Index: Makefile
===
RCS file: /cvs/ports/net/ipcheck/Makefile,v
retrieving revision 1.28
diff -u -p -u -p -r1.28 Makefile
--- Makefile 12 Jul 2019 20:48:28 - 1.28
+++ Makefile 17 Feb 2020 19:38:38 -
@@ -3,9 +3,8 @@
COMMENT= fully compliant DynDNS.org client
MV= 0
-V= 207
+V= 222
PKGNAME= ipcheck-${MV}.${V}
-REVISION= 5
DISTNAME= ipcheck.${V}
CATEGORIES= net
Index: distinfo
===
RCS file: /cvs/ports/net/ipcheck/distinfo,v
retrieving revision 1.7
diff -u -p -u -p -r1.7 distinfo
--- distinfo 18 Jan 2015 03:14:40 - 1.7
+++ distinfo 17 Feb 2020 19:38:38 -
@@ -1,2 +1,2 @@
-SHA256 (ipcheck.207) = uHilc5bud2ojAS7kzY6XwAasmQU+vn2yqiCqR1TmhJc=
-SIZE (ipcheck.207) = 158838
+SHA256 (ipcheck.222) = elHyD9NwLIYlDyyMnQyp9EkZizZShU8CwdOpw+KDEoc=
+SIZE (ipcheck.222) = 170268
[UPDATE] net/ipcheck (207 -> 222)
Hi,
this is the diff to update ipcheck to the latest release (207 -> 222).
Ok?
Cheers,
Alex
Index: Makefile
===
RCS file: /cvs/ports/net/ipcheck/Makefile,v
retrieving revision 1.28
diff -u -p -u -p -r1.28 Makefile
--- Makefile 12 Jul 2019 20:48:28 - 1.28
+++ Makefile 16 Feb 2020 22:57:58 -
@@ -3,7 +3,7 @@
COMMENT= fully compliant DynDNS.org client
MV= 0
-V= 207
+V= 222
PKGNAME= ipcheck-${MV}.${V}
REVISION= 5
DISTNAME= ipcheck.${V}
Index: distinfo
===
RCS file: /cvs/ports/net/ipcheck/distinfo,v
retrieving revision 1.7
diff -u -p -u -p -r1.7 distinfo
--- distinfo 18 Jan 2015 03:14:40 - 1.7
+++ distinfo 16 Feb 2020 22:57:58 -
@@ -1,2 +1,2 @@
-SHA256 (ipcheck.207) = uHilc5bud2ojAS7kzY6XwAasmQU+vn2yqiCqR1TmhJc=
-SIZE (ipcheck.207) = 158838
+SHA256 (ipcheck.222) = elHyD9NwLIYlDyyMnQyp9EkZizZShU8CwdOpw+KDEoc=
+SIZE (ipcheck.222) = 170268
Re: [PATCH] net/libsignal-protocol-c to use upstream commit
Quoting Greg Steuck (g...@nest.cx): > I'm looking for feedback about the trade-offs of such changes. [..] Hi. This seems like needless churn to me. Upstream should be nudged to do a new release instead.
Missing curly brackets in postgresql/pkg/README-server
This made my disaster recovery test slightly easier.
Index: pkg/README-server
===
RCS file: /cvs/ports/databases/postgresql/pkg/README-server,v
retrieving revision 1.26
diff -u -p -r1.26 README-server
--- pkg/README-server 8 Mar 2019 11:48:00 - 1.26
+++ pkg/README-server 11 Apr 2019 10:50:39 -
@@ -171,7 +171,7 @@ Examine your old file for local changes
6) Temporarily support connecting without a password for local users by
editing pg_hba.conf to include "local all postgres trust"
-# vi /var/postgresql/data{,-${PREV_MAJOR}/pg_hba.conf
+# vi /var/postgresql/data{,-${PREV_MAJOR}}/pg_hba.conf
7) Run pg_upgrade:
# su _postgresql -c "cd /var/postgresql && \
@@ -179,7 +179,7 @@ Examine your old file for local changes
-U postgres -d /var/postgresql/data-${PREV_MAJOR}/ -D /var/postgresql/data"
8) Remove "local all postgres trust" line from pg_hba.conf
-# vi /var/postgresql/data{,-${PREV_MAJOR}/pg_hba.conf
+# vi /var/postgresql/data{,-${PREV_MAJOR}}/pg_hba.conf
9) Start PostgreSQL:
# rcctl start postgresql
Re: WIP: net/libsignal-protocol-c
Quoting Anthony J. Bentley (anth...@anjbe.name): > > > Is there a reason not to build the shared lib? > > > > Makes sense to me. > > > > Attached tarball builds shared lib, sets BUILD_DEPENDS properly, > > removes executable bit from files in the port directory. > > Is this version ready for import? Any oks? Works for me. Import would be great.
Re: WIP: net/libsignal-protocol-c
Hi, Thanks for your input. It should all be adopted into this port except for the 'test' target which I couldn't get working otherwise. Any additional comments at this point? libsignal-protocol-c.tgz Description: application/tar-gz
WIP: net/libsignal-protocol-c
This is a WIP of the library used by the Signal messenger. Two tests are currently failing, but they seem fixable. Anyone else interested in the full Signal suite? libsignal-protocol-c.tgz Description: application/tar-gz
Re: UPDATE: net/syncthing
Hey Edd. Thanks for working on this. Comments below.
Quoting Edd Barrett (e...@theunixzoo.co.uk):
> RCS file: /cvs/ports/net/syncthing/pkg/PLIST,v
> retrieving revision 1.4
> diff -u -p -r1.4 PLIST
> --- pkg/PLIST 4 Sep 2018 12:46:19 - 1.4
> +++ pkg/PLIST 5 Feb 2019 22:07:02 -
> @@ -1,6 +1,13 @@
> @comment $OpenBSD: PLIST,v 1.4 2018/09/04 12:46:19 espie Exp $
> @newgroup _syncthing:768
> @newuser _syncthing:768:_syncthing:daemon:Syncthing
> user:${VARBASE}/syncthing:/sbin/nologin
> +@rcscript ${RCDIR}/syncthing
> +@owner _syncthing
> +@group _syncthing
> +@sample ${VARBASE}/syncthing/
> +@extraunexec rm -rf ${VARBASE}/syncthing/{.,}*
> +@owner
> +@group
I am pretty sure those blank @owner and @group need to go.
I have also been running with a diff that includes the stcli command in
the package, which I need for most of my remote Syncthing systems.
I'll follow up with that diff.
x11/freerdp updates?
Hello, My skills with C and porting are not that strong yet but I am looking to see if anyone is able to help update the freerdp port to version 2.x? I have some niche purposes I need this for and version 1 is not supported, the current port is 1.2. Thank you
libmatemixer volume slider bug
Hello, I was curious if anyone else has an issue with this? I saw the post from the other day and applied the patch and it only partially fixed the issue. All I have to test with is primarily Firefox which has its own issues. Problem is it does not use the OSS audio hardware and as such will do nothing. You have to adjust the volume using mixerctl directly instead. I currently do not have the skills to resolve this, but am hoping others have a similar issue and can help get it fixed. Patch I found was testing on the Feb 10, 2018 build of -current. Thank you
Re: samba4 and ACL's
Can you post your smb.conf? Are you using acl_tdb / xattr_tdb?
Re: Munin-node listen only on ipv6 with "host *"
with a snapshot from 26 June 2016 I have the following problem: With "host *": # fstat | grep 4949 root perl 260945* internet6 stream tcp 0x80398008 *:4949 telnet works as expected but I all histogramms in the browser are empty for this host With "host 127.0.0.1": # fstat | grep 4949 root perl 113395* internet stream tcp 0x80398008 127.0.0.1:4949 telnet works as expected and all histogramms are fine So for me, with the 26 June 2016 snapshot I only have to change "host *" to "host 127.0.0.1" and then it is OK. I have not tries a newer snapshot yet. here are my package versions: # pkg_info | grep -e p5 -e munin munin-node-2.0.25p1 flexible network host monitoring, client munin-server-2.0.25p1 flexible network host monitoring, server p5-Cache-Cache-1.08 perl cache interface p5-Capture-Tiny-0.30 capture STDOUT and STDERR p5-Clipboard-0.13 Perl extension to access the x11 clipboard p5-Clone-0.38 recursively copy Perl datatypes p5-Crypt-Rijndael-1.13 interface to the rijndael encryption algorithm aka AES p5-DBD-Pg-3.5.3 access to PostgreSQL databases through the DBI p5-DBI-1.633unified perl interface for database access p5-Data-Password-1.12 module for assessing password quality p5-DateManip-6.39 manipulate dates in perl p5-Digest-SHA1-2.13p4 module to calculate SHA1 digests p5-Encode-Locale-1.05 determine the locale encoding p5-Error-0.17024error/exception handling in an OO-ish way p5-File-Copy-Recursive-0.38p1 recursive copy of files and directories p5-File-KeePass-2.03p1 interface to KeePass V1 and V2 database files p5-File-Listing-6.04 parse directory listing p5-FreezeThaw-0.5001 module for converting structures to strings and back p5-HTML-Parser-3.72 modules to parse and extract information from HTML p5-HTML-Tagset-3.20p1 data tables useful for parsing HTML p5-HTML-Template-2.9 use HTML Templates from CGI scripts p5-HTTP-Cookies-6.01 HTTP Cookie jars p5-HTTP-Daemon-6.01 a simple http server class p5-HTTP-Date-6.02 date conversion routines p5-HTTP-Message-6.11 HTTP Style Messages p5-HTTP-Negotiate-6.01 choose a variant to serve p5-IO-HTML-1.001open an HTML file with automatic charset detection p5-IO-Socket-INET6-2.72 object interface for AF_INET and AF_INET6 domain sockets p5-IPC-ShareLite-0.17p4 simple interface to access shared memory p5-LWP-MediaTypes-6.02 Guess url media type p5-LWP-UserAgent-Determined-1.03p0 virtual browser that retries on errors p5-Log-Log4perl-1.40p0 Log4j implementation for Perl p5-MLDBM-2.05 store multi-level hash structure in single-level tied hash p5-Math-Base-Convert-0.08 very fast base to base conversion p5-Module-Runtime-0.014 runtime module handling p5-Net-CIDR-0.17manipulate IPv4/IPv6 netblocks in CIDR notation p5-Net-Daemon-0.48p0 extension for portable daemons p5-Net-HTTP-6.09Perl HTTP connection client p5-Net-Server-2.008 extensible framework for Perl server engines p5-Params-Util-1.07p1 utility to make parameter checking easier p5-PlRPC-0.2020 module for writing rpc servers and clients p5-SQL-Statement-1.407 SQL parsing and processing engine p5-Socket6-0.27 Perl defines relating to AF_INET6 sockets p5-Sort-Naturally-1.03 sort lexically, but sort numeral parts numerically p5-Term-ReadLine-Gnu-1.28 GNU Readline Library Wrapper Module p5-Term-ShellUI-0.92 fully-featured shell-like command line environment p5-URI-1.71 library to parse Uniform Resource Identifiers p5-WWW-RobotRules-6.02 database of robots.txt-derived permissions p5-XML-Parser-2.44 perl module for parsing XML documents p5-libwww-6.15 library for WWW access in Perl Ragards ALex. On Thu, Jul 21, 2016 at 02:30:07PM +0200, Sol??ne RAPENNE wrote: > Hello, > > On -current munin-node listens only on ipv6 addresses when using "host *", I > have to use "host 127.0.0.1" to be able to use it from localhost on ipv4. I > didn't change anything on munin configuration, I had no problem on 5.9. > > my config file > > log_level 4 > log_file /var/log/munin/munin-node.log > pid_file /var/run/munin/munin-node.pid > background 1 > setsid 1 > user root > group wheel > ignore_file [\#~]$ > ignore_file DEADJOE$ > ignore_file \.bak$ > ignore_file %$ > ignore_file \.dpkg-(tmp|new|old|dist)$ > ignore_file \.rpm(save|new)$ > ignore_file \.pod$ > allow ^127\.0\.0\.1$ > allow ^::1$ > host 127.0.0.1 > port 4949 > > > With "host *", there is only ipv6 > > fstat | grep 4949 > root perl 552635* internet6 stream tcp 0x811db260 > *:4949 > > With "host 127.0.0.1" > > fstat | grep 4949 > root perl 132325* internet stream tcp 0x811db260 > 127.0.0.1:4949 > > > Is it something related to my system or somebody else can reproduce it ? > > Regards >
Re: editors/emacs gtk3 flavor is unusable
still the same problem here... $ dmesg | head -n 2 OpenBSD 6.0-beta (GENERIC.MP) #2163: Wed Jun 1 18:31:49 MDT 2016 dera...@amd64.openbsd.org:/usr/src/sys/arch/amd64/compile/GENERIC.MP $ pkg_info | grep emacs emacs-24.5p3-gtk3 GNU editor: extensible, customizable, self-documenting Alex. On Sun, Apr 10, 2016 at 12:22:36PM +0200, Matthieu Herrb wrote: > On Tue, Mar 29, 2016 at 07:50:52PM +0200, Jeremie Courreges-Anglas wrote: > > Sol?ne Rapenne writes: > > > > > Hello, > > > > > > I have the package emacs-24.5p2-gtk3 installed and emacs is unusable > > > when started in graphical mode. > > > > > > dmesg | head -n 2 > > > OpenBSD 5.9-current (GENERIC.MP) #1970: Mon Mar 28 17:02:06 MDT 2016 > > > dera...@amd64.openbsd.org:/usr/src/sys/arch/amd64/compile/GENERIC.MP > > > > > > > > > If I start "emacs myfile.txt" I get emacs started in graphical mode, the > > > window is displayed, the file also but _the buffer_ doesn't respond to > > > any keyboard/mouse input BUT the menu and the icons of the toolbar > > > responds. The scrollbar on the right is displayed and can be moved but > > > don't scroll the text displayed in the buffer. I can quit the window > > > without problem from the desktop environment (while sometimes you have > > > to kill the process to close the window). After closing, no core file. > > > When starting the graphical mode from console, I don't have any error > > > displayed. > > > > > > When starting emacs with -nw in console, everything work as expected. > > > > > > I tried the gtk2 flavor and this one is working. I found updates of gtk3 > > > lib the 24th march, maybe it is related ? > > > > > > I updated my ports tree and recompiled emacs with gtk3 from there, the > > > same behaviour is happening. > > > > > > Kind regards > > > > I can reproduce it here after installing the gtk3 flavor - I use no_x11. > > Are there emacs-gtk3 users here that can reproduce this issue? > > > > Yes same problem here. Since I upgraded after the last libc bump. So > the list of packages updated is huge, and it hard to find a list of > possible guilty candidates... > > -- > Matthieu Herrb
Re: net/iodine add rc script
On 20.10.2015 20:20, Antoine Jacoutot wrote:
Index: pkg/iodined.rc
===
RCS file: pkg/iodined.rc
diff -N pkg/iodined.rc
--- /dev/null 1 Jan 1970 00:00:00 -
+++ pkg/iodined.rc 20 Oct 2015 13:31:47 -
@@ -0,0 +1,12 @@
+#!/bin/sh
+#
+# $OpenBSD$
+
+daemon="${TRUEPREFIX}/sbin/iodined"
+
+. /etc/rc.d/rc.subr
+
+pexp="${daemon} .*"
>>>
>>> The default pexp does not match?
>>
>> The default pexp does not match, because iodined change its cmdline in
>> order to hide the password given with -P.
>
> Passing password on the command line, sigh.
> Anyway that makes sense. Does it strip the all args or just `-P ...' ?
>
Only the option argument is stripped, so "iodined ... -P secret ..."
becomes "iodined ... -P ..." (note the two spaces after -P) and
"iodined ... -Psecret ..." becomes "iodined ... -P ..." (one space after
-P).
Re: net/iodine add rc script
On 10/20/2015 04:56 PM, Antoine Jacoutot wrote:
> On Tue, Oct 20, 2015 at 03:36:54PM +0200, Alexandre Perrin wrote:
>> Attached patch add a rc script for iodined and README to describe the
>> rc script configuration. Tested on 5.8-stable amd64.
>>
>> Ok?
>>
>> Regards,
>> Alexandre Perrin.
>
>> Index: Makefile
>> ===
>> RCS file: /cvs/ports/net/iodine/Makefile,v
>> retrieving revision 1.14
>> diff -u -p -r1.14 Makefile
>> --- Makefile 19 Jun 2014 22:45:56 - 1.14
>> +++ Makefile 20 Oct 2015 13:31:47 -
>> @@ -4,6 +4,7 @@ COMMENT= tunnel IPv4 data through DNS
>>
>> DISTNAME= iodine-0.7.0
>> CATEGORIES= net
>> +REVISION= 0
>>
>> HOMEPAGE= http://code.kryo.se/iodine/
>>
>> Index: pkg/PLIST
>> ===
>> RCS file: /cvs/ports/net/iodine/pkg/PLIST,v
>> retrieving revision 1.3
>> diff -u -p -r1.3 PLIST
>> --- pkg/PLIST30 Mar 2009 09:17:45 - 1.3
>> +++ pkg/PLIST20 Oct 2015 13:31:47 -
>> @@ -4,3 +4,5 @@
>> @man man/man8/iodine.8
>> @bin sbin/iodine
>> @bin sbin/iodined
>> +share/doc/pkg-readmes/${FULLPKGNAME}
>> +@rcscript ${RCDIR}/iodined
>> Index: pkg/README
>> ===
>> RCS file: pkg/README
>> diff -N pkg/README
>> --- /dev/null1 Jan 1970 00:00:00 -
>> +++ pkg/README 20 Oct 2015 13:31:47 -
>> @@ -0,0 +1,16 @@
>> +$OpenBSD$
>> +
>> ++---
>> +| Running ${FULLPKGNAME} on OpenBSD
>> ++---
>> +
>> +Starting iodined at boot time
>> +=
>> +An rc.d(8) script is provided, so you can add "iodined" to the pkg_scripts
>> +line in /etc/rc.conf.local.
>> +
>> +The iodine server must be configured through the command line, see
>> iodined(8)
>> +for options. Do _not_ modify the ${RCDIR}/iodined script, but instead add a
>> +line to /etc/rc.conf.local using the format of the following example:
>> +
>> +iodined_flags="-u _iodine -t /var/empty -c -P secret 192.168.53.1
>> t1.mydomain.com"
>
> You could also do this to append to pkg_scripts and set the flags:
> # rcctl set iodine status on
> # rcctl set iodine flags -u _iodine -t /var/empty -c -P secret 192.168.53.1
> t1.mydomain.com
Thank you. After a quick test it seems that it should be "rcctl set
iodined ..." though. I've attached an updated version of the patch.
>> Index: pkg/iodined.rc
>> ===
>> RCS file: pkg/iodined.rc
>> diff -N pkg/iodined.rc
>> --- /dev/null1 Jan 1970 00:00:00 -
>> +++ pkg/iodined.rc 20 Oct 2015 13:31:47 -
>> @@ -0,0 +1,12 @@
>> +#!/bin/sh
>> +#
>> +# $OpenBSD$
>> +
>> +daemon="${TRUEPREFIX}/sbin/iodined"
>> +
>> +. /etc/rc.d/rc.subr
>> +
>> +pexp="${daemon} .*"
>
> The default pexp does not match?
The default pexp does not match, because iodined change its cmdline in
order to hide the password given with -P.
>
>> +rc_reload=NO
>> +
>> +rc_cmd $1
>
>
Index: Makefile
===
RCS file: /cvs/ports/net/iodine/Makefile,v
retrieving revision 1.14
diff -u -p -r1.14 Makefile
--- Makefile 19 Jun 2014 22:45:56 - 1.14
+++ Makefile 20 Oct 2015 15:24:41 -
@@ -4,6 +4,7 @@ COMMENT= tunnel IPv4 data through DNS
DISTNAME= iodine-0.7.0
CATEGORIES= net
+REVISION= 0
HOMEPAGE= http://code.kryo.se/iodine/
Index: pkg/PLIST
===
RCS file: /cvs/ports/net/iodine/pkg/PLIST,v
retrieving revision 1.3
diff -u -p -r1.3 PLIST
--- pkg/PLIST 30 Mar 2009 09:17:45 - 1.3
+++ pkg/PLIST 20 Oct 2015 15:24:41 -
@@ -4,3 +4,5 @@
@man man/man8/iodine.8
@bin sbin/iodine
@bin sbin/iodined
+share/doc/pkg-readmes/${FULLPKGNAME}
+@rcscript ${RCDIR}/iodined
Index: pkg/README
===
RCS file: pkg/README
diff -N pkg/README
--- /dev/null 1 Jan 1970 00:00:00 -
+++ pkg/README 20 Oct 2015 15:24:41 -
@@ -0,0 +1,13 @@
+$OpenBSD$
+
++---
+| Running ${FULLPKGNAME} on OpenBSD
++---
+
+Starting iodined at boot time
+=
+The iodine server must be configured through the command line, see iodined(8)
+for options. An rc.d(8) script is provided, to start iodined at boot time:
+
+# rcctl set iodined status on
+# rcctl set iodined flags -u _iodine -t /var/empty -c -P secret 192.168.53.1 t1.mydomain.com
Index: pkg/iodined.rc
===
RCS file: pkg/iodined.rc
diff -N pkg/iodined.rc
--- /dev/null 1 Jan 1970 00:00:00 -
+++ pkg
Erlang/OTP R17
Hello, Just checking if anyone is working on Erlang R17 port? Thanks, Alex
Input needed: www/roundup
I'm trying to create a port of www.roundup-tracker.org but I get the following errors at build and fake. I have been unable to find the cause so I'd like input on what I'm doing wrong: /usr/ports/www/roundup$ make clean fake ===> Cleaning for roundup-1.5.0 [..] ===> Building for roundup-1.5.0 usage: setup.py [global_opts] cmd1 [cmd1_opts] [cmd2 [cmd2_opts] ...] or: setup.py --help [cmd1 cmd2 ...] or: setup.py --help-commands or: setup.py cmd --help error: invalid command 'egg_info' running build creating build creating build/share creating build/share/locale [..] copying roundup/scripts/__init__.py -> /usr/ports/pobj/roundup-1.5.0/roundup-1.5.0/lib/roundup/scripts running build_scripts creating /usr/ports/pobj/roundup-1.5.0/roundup-1.5.0/scripts-2.7 ===> Faking installation for roundup-1.5.0 usage: setup.py [global_opts] cmd1 [cmd1_opts] [cmd2 [cmd2_opts] ...] or: setup.py --help [cmd1 cmd2 ...] or: setup.py --help-commands or: setup.py cmd --help error: option --single-version-externally-managed not recognized *** Error 1 in /usr/ports/www/roundup (/usr/ports/lang/python/python.port.mk:177 'do-install': @cd /usr/ports/pobj/roundup-1.5.0/roundup-1.5...) *** Error 1 in . (/usr/ports/infrastructure/mk/bsd.port.mk:2729 '/usr/ports/pobj/roundup-1.5.0/fake-i386/.fake_done') *** Error 1 in /usr/ports/www/roundup (/usr/ports/infrastructure/mk/bsd.port.mk:2383 'fake') -- I prefer the dark of the night, after midnight and before four-thirty, when it's more bare, more hollow.http://a.mongers.org roundup.shar Description: Unix shell archive
Re: x11/openmotif building package problem - MWM Title BUG
Forgot to post into OpenBSD mail list about this. If somebody still uses MWM (Motif Window Manager) and has a problem with seeing Russian in window titles, there is stupidity that can fix that. http://www.motifzone.net/forum/xterm-title-some-russian-text post num.4. Hi, Can anyone reproduce that? # cd /usr/ports/x11/openmotif&& cvs -q up -PAd # make show=USE_SYSTRACE Yes # make show=FLAVOR # make show=PKGNAMES openmotif-demos-2.1.30.5p0 openmotif-debuglibs-2.1.30.5p0 openmotif-2.1.30.5p2 # make build [...] # make fake [...] rm -f mwm cc -o mwm -O2 -fno-strict-aliasing -Wall -Wpointer-arith -Wundef -L../../exports/lib -L/usr/X11R6/lib -L/usr/local/lib -L../../imports/x11/lib WmCDInfo.o WmCDecor.o WmCEvent.o WmCPlace.o WmCmd.o WmColormap.oWmError.o WmEvent.o WmFeedback.oWmFunction.oWmGraphics.oWmIDecor.o WmIPlace.o WmIconBox.o WmImage.o WmInitWs.o WmKeyFocus.o WmMain.oWmManage.o WmMenu.oWmProperty.oWmProtocol.o WmResCvt.o WmResParse.oWmResource.oWmSignal.o WmWinConf.o WmWinInfo.o WmWinList.o WmWinState.oWmWsm.o WmXSMP.oversion.o ./WmWsmLib/libWsm.a -lXm -lXt -lSM -lICE -lXp -lXext -lX11 -L/usr/X11R6/lib -lm -Wl,-rpath-link,../../exports/lib cc: ./WmWsmLib/libWsm.a: No such file or directory *** Error code 1 Stop in /usr/ports/x11/openmotif/w-motif/motif/clients/mwm (line 1236 of Makefile). *** Error code 1 Stop in /usr/ports/x11/openmotif/w-motif/motif/clients (line 1267 of Makefile). *** Error code 1 Stop in /usr/ports/x11/openmotif/w-motif/motif (line 1391 of xmakefile). *** Error code 1 Stop in /usr/ports/x11/openmotif/w-motif/motif (line 201 of Makefile). *** Error code 1 Stop in /usr/ports/x11/openmotif (line 2111 of /usr/ports/infrastructure/mk/bsd.port.mk).
Re: gtk+1 deprecation
14.10.2010 18:16, Alex Vladimirovich wrote: Has the issue Stuart mentioned here been fixed? No. But it doesn't touch the gui version of PuTTY, for which Stuart done this GTK2 port.
Re: gtk+1 deprecation
Has the issue Stuart mentioned here been fixed? No.
Re: gtk+1 deprecation
Make gtk2 putty build on 4.8-current with gcc4. Shut up "warning: missing sentinel in function call" that cames from unix/dtkdlg.c (http://www.linuxonly.nl/docs/2/2_Sentinel_warning_missing_sentinel_in_function_call.html) Fix from espie@ (ignore "the address of ... will never be NULL") for unix/gtkwin.c and and landy@'s "warning: 'struct in_addr' declared inside parameter list" fix (when building on 4.8-cur with -Wsystem-heade rs, similar to https://trac.torproject.org/projects/tor/ticket/1848) that are in tree are also included. I've included tarball of port files to save your time. 26.03.2010 1:43, Stuart Henderson wrote: net/putty,-gui (there is a gtk2 port available) .. their snapshots have gtk2 support; this port diff gets it building and it mostly runs ok, but I noticed some strange pauses in plink when I started sending large amounts of text (e.g. ls -lR /) then interrupting with ^C. I don't have time to look further into that at the moment, so I'll send what I have for now to at least try and avoid duplicated work. putty-gtk2_port.tar.gz Description: application/gzip
Re: [new port] games/supertuxkart: OpenAL skipping sounds
06.10.2010 6:42, BSD wrote: The openal's patch works for me. -current i386. The game is running fine now. -luis Meanwhile i'm enjoying very hard "skippings" of sound and music with OpenAL and supertuxkart partially. If i disable music, sound skips a bit lesser, but all the same it's unacceptable. My codec is ac97, the old Avance Logic ALC203 to be exact. Direct audio works well (for example mplayer which has --disable-openal flag by default). Machine arch is i386. I've checked other OpenAL-depended games. There is no such problem in OpenArena. There is something similar in Warzone2100, but sounds much better. Any thoughts? Is it just poor audio codec or something else? I think that OpenAL should work on high level while utilizing audio device via OpenBSD's sound driver, so i don't believe that audio codec quality influences on this.
Re: No Metalink clients in ports...
Is anyone going to add aria2 or any other metalink client to the ports tree? I'm planning to put up some OpenBSD-related mirrors down the road, and using metalink can go a long way to increasing download speed and fault tolerance. -- Alex Libman, http://AlexLibman.com
Re: OpenBSD Vim Programming FAQ
I'd like to express my support a good vim howto / FAQ, particularly one that is focused on OpenBSD. Have you considered setting up this writing effort through something like a wiki? Then people would be able to contribute tips, fixes, feedback, translations, etc with almost no organizational overhead. I think a lot of people use vim for the same reason they use OpenBSD: minimalism, power, textual orientation, and relative licensing freedom. (My search for another good copyFREE-ish code editor came up short - see http://tinyurl.com/vimalt) I am particularly interested in PHP-related features and add-ons. The OpenBSD vim port could use some improvements as well, like enabling the perl interpreter (since we're stuck with it installed by default) as well as "flavors" for python, etc. It could also use cooler defaults, like "set nocompatible", "syntax enable", "set backspace=2", and maybe "set number". Also, how long before 7.3 makes it into -stable ports? -- Alex Libman, http://AlexLibman.com
net/irssi-0.8.15
Hello Wiktor, hello list.
I wonder that the "@rm -rf ${PREFIX}/include" is still in
the Makefile (came with 1.26 revision far in the past:
http://www.openbsd.org/cgi-bin/cvsweb/ports/net/irssi/Makefile.diff?r1=1.25;r2=1.26;f=h).
Any real reason to still remove includes?
Build of some of plugins are rely on them. For example there is
Jabber plugin called irssi-xmpp. I made a port of it far
in the past. It requires irssi API (these includes) to be
build. It's not in the ports since it's unstable and freshy, so
i never even interested to send it as NEW to port maillist.
I include this draft just to show that there is at least one
plugin that requires these includes.
P.S.: Included version is 0.50, because there is a bug in more
recent version 0.51 where auto-away on startup doesn't work.
If anybody interested in 0.51 port it can be founded at
http://cvs.linklevel.net/index.cgi/ports/net/irssi-xmpp/
irssi-xmpp_port-0.50.tar.gz
Description: application/gzip
Re: OpenBSD Vim Programming FAQ
> I've decided to write Vim Programming FAQ. I'm not breaking here to make any holy war of text editors, but i'm *very* interesting did or will someone work on similar guide for Emacs? > "OpenBSD and nvi" quote: "vim is replacing nvi, since nvi does not have a pure BSD license, and vim also works better." Didn't that happen prior to 2.0 release? :) > "OpenBSD and mg" quote from man page: "editor for people who can't (or don't want to) run emacs for one reason or another". This is not my case. another quote "Since it is written completely in C, there is currently no language in which you can write extensions". That's not good for me. So please if anybody is emacs-skilled and happily uses it on OpenBSD as an instrument tell me your experience and/or send your configs.
Re: update: devel/fossil-20101005035549
My bad for making it sound as if it installed tcl by default, I was
mostly speaking in generalities. Thank you once again for the work you
do on the ports.
On Thu, 7 Oct 2010 12:51:41 -0400, "James Turner" said:
> You are correct, gnupg is not required, if it's installed however you
> can use it to sign your commits. Also why comment out REGRESS_DEPENDS?
> tcl shouldn't get installed unless you run make regress if I'm not
> mistaken. A normal user running make install or pkg_add will never get
> tcl installed.
>
> On Thu, Oct 07, 2010 at 12:36:32PM -0400, Alex Libman wrote:
> > Thank you for the update, James.
> >
> > FYI, I comment out the following Makefile lines to reduce
> > dependencies, and it seems to work fine (4.7-stable):
> >
> > # MODULES = lang/tcl
> >
> > # RUN_DEPENDS = :gnupg-*:security/gnupg
> >
> > # REGRESS_DEPENDS = ${MODTCL_RUN_DEPENDS}
> >
> > # do-regress:
> >
> > # @cd ${WRKSRC} && ${MODTCL_BIN} test/tester.tcl fossil
> >
> > Perhaps down the road it might make sense to use additional
> > "flavors" to simplify disabling those? I think a lot of OpenBSD
> > users, particularly those who choose Fossil, might be trying to
> > reduce their dependencies on GNU components (i.e. gnupg), or avoid
> > installing a zillion different scripting languages (i.e. tcl).
Best regards,
Alex Libman
--
http://www.fastmail.fm - Does exactly what it says on the tin
Re: update: devel/fossil-20101005035549
Thank you for the update, James.
FYI, I comment out the following Makefile lines to reduce dependencies,
and it seems to work fine (4.7-stable):
# MODULES = lang/tcl
# RUN_DEPENDS = :gnupg-*:security/gnupg
# REGRESS_DEPENDS = ${MODTCL_RUN_DEPENDS}
# do-regress:
# @cd ${WRKSRC} && ${MODTCL_BIN} test/tester.tcl fossil
Perhaps down the road it might make sense to use additional "flavors" to
simplify disabling those? I think a lot of OpenBSD users, particularly
those who choose Fossil, might be trying to reduce their dependencies on
GNU components (i.e. gnupg), or avoid installing a zillion different
scripting languages (i.e. tcl).
Best regards,
Alex Libman
--
http://www.fastmail.fm - Access your email from home and the web
NEW: orthos 0.2-master
Hello list. This is a draft port of X11 DM called Orthos. It was inspired by SLiM (which is already in the ports.) and have some code of the very early version of slim (althought it was totally rewritten in latest -master, but i didn't check it's state yet and so didn't use it for porting yet. There is stable 0.2 version also, but it provides only demo theme and is very outdated). It's a very lightweight like slim, but contrast to it and many other managers, Orthos uses *animated* OpenGL-rendered themes, which actually are dynamic libs by themselves. If you're using card supported by intel(4) or radeon(4) with working DRM and 3D acceleration this is very candy-eye looking thing. I hope you'll enjoy. You have some options that can be used in your config file to change theme looking, but most of customization can be done via source editing and recompilation of the theme file. What was implemented: - setlogin() was added to bypass software that do getlogin() to decide the user name. Sample of such software is OpenCVS (behaviour can be seen when trying sudoing cvs commands from user for example). Came from patch for slim (http://marc.info/?l=openbsd-ports&m=127870796517767&w=2) ; - Feed MIT magic cookie into xauth via pipe, not via shell args. Use new algorithm of magic cookie generation. Came from http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=529306 Caveats of this dirty draft: - It's an almost a WIP project (latest stable version doesn't contain anything interesting, so i didn't port it). Just for your try; - It uses python-based Scons system for building when the main software written in C++ (almost non-OO code although) (and latest -master sources requires bunch of tools (libtooliz from libtool and autoconf)). Both of solutions are quite ugly, it's better to use plain Makefiles and build by BSD make; - Don't do make plist. Included PLIST is custom, because most of customization of the themes and orthos settings are done via source modifications, so i install settings, binary and themes files and binaries as example files! Hi all, here's an updated version of slim, a lightweight replacement for xdm (http://marc.info/?l=openbsd-ports&m=117414110820888&w=2), which finally works fine for me (no more tty conflicts with getty, it uses vt05 like xdm). I'd like some user-level feedback, report weird behaviour and breakages. Tom, can you test this one ? Do you still want to be MAINTAINER ? A subpackage with themes is being worked too :) Landry orthos_port-0.2m.tar.gz Description: application/gzip
Re: [new port] games/supertuxkart
Be note, that 0.6.2a version still uses plib as 3D engine, while more recent SuperTuxKart starting from 0.7alpha1 uses new engine - irrLicht, that means that new stable release of the game will be probably uses irrLicht too as a replace of outdated plib. So should we port Irrlicht too? > Howdy. This is my first port, the 3D kart racing game SuperTuxKart. > Tested on current, amd64. Please give some feedback if it works for > you/doesn't work for you, any advice you might have for a novice > porter > etc. Some information about performance and video hardware would be > nice too. :-) > > Cheers, > Pascal
