Re: UPDATE archivers/fuse-zip
On Sat 04/05/2019 20:54, Björn Ketelaars wrote: > Simple update to fuse-zip-0.6.0. Changelog can be found at > https://bitbucket.org/agalanin/fuse-zip/src/default/changelog. > > Tested on amd64 by adding, and removing some files to a fuse mounted > archive. 'make test' runs successfully on amd64. > > OK? Ping
Re: [update] sysutils/borgbackup 1.1.9 -> 1.1.10
On Sun 19/05/2019 07:54, Björn Ketelaars wrote: > Diff below brings borgbackup to 1.1.10, which is a bugfix release. > Noticeable change is that the latest supported msgpack-python release is > bundled. Changelog can be found at > https://github.com/borgbackup/borg/blob/1.1.10/docs/changes.rst#version-1110-2019-05-16 > > Switching to the bundled version of msgpack-python makes sense as the > version in ports is in need of an update: msgpack-python has been > renamed to msgpack by its upstream, and borgbackup was seemingly the > only port unable to cope with this renaming, thus blocking an update. > > Changes to the port: > - Remove py-msgpack as RDEP. See above; > - Remove py-test-xdist as TDEP. Although tests can be run parallel, they > are not. As such there is no need for it; > - pytest-benchmark is currently not picked up as plugin by pytest, as > result benchmarking fails during 'make test'. For now ignore > benchmarking (see MODPY_PYTEST_ARGS), and comment out > py-test-benchmark as TDEP; > - Set COMPILER as this is required for building the bundled > msgpack-python; > - Sync WANTLIB. > > Testing: > - 'make test' runs successfully on amd64; > - Run tested on several hosts (all amd64): listing and creating > snapshots, pruning old snapshots, and extracting files from a snaphot. > > OK? Ping
Re: [update] net/py-msgpack 0.5.6 -> 0.6.1
On Sun 19/05/2019 10:48, Björn Ketelaars wrote: > Enclosed diff brings py-msgpack to 0.6.1. Noticeable change is that > upstream has changed the package name from mspack-python to msgpack. > Changelog can be found at > https://github.com/msgpack/msgpack-python/blob/v0.6.1/ChangeLog.rst > > Of the consumers below only borgbackup does not like the name change. > This issue will be resolved by [0]. > > devel/py-test-expect > devel/py-test-expectython3 > editors/py-neovim > editors/py-neovimython3 > sysutils/borgbackup > sysutils/salt > > Changes to the port: > - Change DISTNAME to reflect package name change. > > Testing: > - 'make test' runs successfully for both flavors on amd64; > - Build tested all consumers (except sysutils/borgbackup). > > OK? > > [0] https://marc.info/?l=openbsd-ports=155824528218853=2 Ping
CVS: cvs.openbsd.org: ports
CVSROOT:/cvs Module name:ports Changes by: l...@cvs.openbsd.org2019/05/25 20:07:44 Modified files: security/ghidra: Makefile distinfo security/ghidra/pkg: PLIST Log message: Update to Ghidra 9.0.4. ok rpointel@
Re: Move lang/pcc to lang/pcc/pcc, update to 20190521 and add lang/pcc/pcc-libs
On 5/25/19 2:01 PM, Leonid Bobrov wrote:
On Sat, May 25, 2019 at 01:12:06PM -0400, Brian Callahan wrote:
On 5/25/19 11:58 AM, Leonid Bobrov wrote:
Index: Makefile.inc
===
RCS file: Makefile.inc
diff -N Makefile.inc
--- /dev/null 1 Jan 1970 00:00:00 -
+++ Makefile.inc25 May 2019 15:51:13 -
@@ -0,0 +1,17 @@
+# $OpenBSD: Makefile,v 1.17 2019/05/03 16:59:10 danj Exp $
+
+ONLY_FOR_ARCHS = i386 amd64 sparc64 mips64 mips64el powerpc
How did you come up with this list? Either it should be all archs with
backend code in pcc (in which case you're missing some archs) or it should
be all archs that are known to build (that would be amd64 i386 mips64
mips64el) or it should be all archs that are known to build and actually
work (amd64 i386). You should use the build and actually work list.
This list comes from configure scripts (and pkgsrc don't even have this
list in lang/pcc-current, while in lang/pcc they set it to arm*, i386,
mips*, powerpc, sparc64, vax and x86_64):
pcc configure (NetBSD has longer list)
```
openbsd*)
targos=openbsd
abi=elf
stabs=yes
case "$target_cpu" in
i?86) targmach=i386 ;;
vax) targmach=vax ;;
mips64el) targmach=mips64 ;;
mips64) targmach=mips64 endian=big ;;
powerpc) targmach=powerpc endian=big ;;
sparc64) targmach=sparc64 endian=big ;;
m68k) targmach=m68k endian=big ;;
x86_64) targmach=amd64 ;;
esac
;;
```
pcc-libs configure (NetBSD has longer list)
```
openbsd*)
targos=openbsd
case "$target_cpu" in
i?86) targmach=i386 ;;
mips64el) targmach=mips ;;
mips64) targmach=mips endian=big ;;
powerpc) targmach=powerpc endian=big ;;
sparc64) targmach=sparc64 endian=big ;;
vax) targmach=vax ;;
x86_64) targmach=amd64 ;;
esac
;;
```
I didn't add m68k and vax to this list because OpenBSD doesn't support
them (however OpenBSD supports m88k, but I don't know is it compatible
with m68k or not).
I didn't actually test that because I either need exotic hardwares or
need to setup virtual machines, so I choose to trust configure script
and to trust what NetBSD/pkgsrc already do.
The configure scripts are outdated. *shrug*
You should keep to ONLY_FOR_ARCHS=amd64 i386 with the comment explaining
why (which you also removed).
Index: pcc/Makefile
===
RCS file: pcc/Makefile
diff -N pcc/Makefile
--- /dev/null 1 Jan 1970 00:00:00 -
+++ pcc/Makefile25 May 2019 15:51:13 -
@@ -0,0 +1,21 @@
+# $OpenBSD: Makefile,v 1.17 2019/05/03 16:59:10 danj Exp $
+
+COMMENT = portable C compiler
+
+DISTNAME = pcc-${V}
This would make PKGNAME=pcc-${V}, which isn't ok. Likewise, the PKGNAME for
pcc-libs is pcc-libs-${V} which also isn't ok.
~Brian
That's what I was asking in the start of this topic: should I use
versioning like PKGNAME=pcc=1.1.0.${V}?
`pcc --version' will return 1.2.0.DEVEL ${V}. Which also isn't great.
1.1.0.${V} is certainly better.
~Brian
CVS: cvs.openbsd.org: ports
CVSROOT:/cvs Module name:ports Changes by: d...@cvs.openbsd.org2019/05/25 17:47:25 Modified files: astro/xworld : Makefile net/fmirror: Makefile Log message: Remove maintainer per their request
CVS: cvs.openbsd.org: ports
CVSROOT:/cvs Module name:ports Changes by: bcal...@cvs.openbsd.org 2019/05/25 16:25:01 Modified files: math/ebc : Makefile distinfo math/ebc/pkg : PLIST Log message: Update to ebc-2.0.0 Changelog: https://github.com/gavinhoward/bc/releases/tag/2.0.0
CVS: cvs.openbsd.org: ports
CVSROOT:/cvs Module name:ports Changes by: c...@cvs.openbsd.org2019/05/25 16:10:18 Modified files: shells/perlsh : Makefile Added files: shells/perlsh/patches: patch-lib_Psh_Strategy_Executable_pm patch-lib_Psh_pm Log message: perlsh: fix use of deprecated Perl features, use metacpan as HOMEPAGE and MASTER_SITES. OK afresh1@
CVS: cvs.openbsd.org: ports
CVSROOT:/cvs Module name:ports Changes by: es...@cvs.openbsd.org 2019/05/25 15:50:38 Modified files: infrastructure : README Log message: fix badly out-of-date stuff, should probably just finish manpages and GC this
Re: Missing file and Man page for out-of-date
As for the full story, this is a whole sequence of events. Committee decided ports/infrastructure/man didn't belong in default manpath, because it's not part of sacro-sanct base. Fine, let's move the man pages to base. And then, Theo said some of those names are way too generic, we can't have manpages with such names (and on that point, he is right). Fine, I renamed generic programs to port-something, or pkg_whatever. Sorry about the README, I plain forgot about that.
Re: Missing file and Man page for out-of-date
It was renamed to pkg_outdated. -- Patrick Harper paia...@fastmail.com On Sat, 25 May 2019, at 22:17, Michael Alaimo wrote: > The /usr/ports/infrastructure/bin/out-of-date program is missing. > > I remember it being in OpenBSD 6.3. > > It is still referenced in /usr/ports/infrastructure/README in OpenBSD 6.5. > > It is listed with description: > bin/out-of-date > Compare installed registered packages with INDEX, try to find out > of date ports. > > Is it possible to get the script back into ports for OpenBSD 6.5? > > Does anyone know what happened with it? > > Regards, > > Michael > > http://quantum-foam.org/ > >
Re: Missing file and Man page for out-of-date
Thank you I found the file and it is now working. On Sat, May 25, 2019 at 5:24 PM Andreas Kusalananda Kähäri wrote: > > On Sat, May 25, 2019 at 05:16:19PM -0400, Michael Alaimo wrote: > > The /usr/ports/infrastructure/bin/out-of-date program is missing. > > > > I remember it being in OpenBSD 6.3. > > > > It is still referenced in /usr/ports/infrastructure/README in OpenBSD 6.5. > > > > It is listed with description: > > bin/out-of-date > > Compare installed registered packages with INDEX, try to find out > > of date ports. > > > > Is it possible to get the script back into ports for OpenBSD 6.5? > > > > Does anyone know what happened with it? > > > > Regards, > > > > Michael > > > > http://quantum-foam.org/ > > On 2018/07/09 11:17:33 it was renamed "pkg_outdated" (same location as > before). > > https://marc.info/?l=openbsd-ports-cvs=153115666203853=2 > > -- > Kusalananda > Sweden
CVS: cvs.openbsd.org: ports
CVSROOT:/cvs Module name:ports Changes by: t...@cvs.openbsd.org2019/05/25 15:25:31 Modified files: infrastructure : README Log message: out-of-date was renamed to pkg_outdated
Re: Missing file and Man page for out-of-date
On Sat, May 25, 2019 at 05:16:19PM -0400, Michael Alaimo wrote: > The /usr/ports/infrastructure/bin/out-of-date program is missing. > > I remember it being in OpenBSD 6.3. > > It is still referenced in /usr/ports/infrastructure/README in OpenBSD 6.5. > > It is listed with description: > bin/out-of-date > Compare installed registered packages with INDEX, try to find out > of date ports. > > Is it possible to get the script back into ports for OpenBSD 6.5? > > Does anyone know what happened with it? > > Regards, > > Michael > > http://quantum-foam.org/ On 2018/07/09 11:17:33 it was renamed "pkg_outdated" (same location as before). https://marc.info/?l=openbsd-ports-cvs=153115666203853=2 -- Kusalananda Sweden
Missing file and Man page for out-of-date
The /usr/ports/infrastructure/bin/out-of-date program is missing. I remember it being in OpenBSD 6.3. It is still referenced in /usr/ports/infrastructure/README in OpenBSD 6.5. It is listed with description: bin/out-of-date Compare installed registered packages with INDEX, try to find out of date ports. Is it possible to get the script back into ports for OpenBSD 6.5? Does anyone know what happened with it? Regards, Michael http://quantum-foam.org/
CVS: cvs.openbsd.org: ports
CVSROOT:/cvs Module name:ports Changes by: k...@cvs.openbsd.org2019/05/25 14:42:32 Modified files: x11/arandr : Makefile distinfo x11/arandr/patches: patch-setup_py x11/arandr/pkg : DESCR PLIST Log message: Update to arandr-0.1.10 Switch to Python 3 and GTK3. Use TLS while here and adjust our manual gzip patch to cope with Python 3's byte type. OK edd
Re: [update] mariadb-10.3.14
Hi,
Thanks again for taking care of it!
> On Tue, May 14 2019, Jeremie Courreges-Anglas wrote:
> > On Mon, May 13 2019, Jeremie Courreges-Anglas
> > wrote:
> >> Now that 10.2 has been committed, here's an update to the latest.
> >> Upstream removed the example config file so I decided to create one
> >> based on
> >>
> >> https://mariadb.com/kb/en/library/configuring-mariadb-with-option-files/
> >>
> >> No symbol change in the SHARED_LIBS. The diff also includes a fix
> >> for the test target (mysql-test tests don't finish here).
> >>
> >> Looking for real use reports and oks.
> >
> > no_server doesn't build any more because my_global.h file is
> > missing, so I'm holding off for now. Test reports still welcome.
>
> bah, I'm not sure why breaking the no_server PSEUDO_FLAVOR would
> matter. The problem is known upstream and I worked around it in the
> diff below.
>
> https://jira.mariadb.org/browse/MDEV-19152
>
> Meanwhile, cwen@ reported that mariadb-10.2.23 doesn't build on
> powerpc because it's lacking __sync_* atomics. 10.3.x switched to
> __atomic_* builtins which are better supported by gcc-8.3.0, this
> fixes mariadb on powerpc according to cwen's tests (thanks!).
I've retested your diff and met no issues at all.
Please note that it also needs the infamous atomics block - they
provide proper atomics detection... but no -latomic flag test.
I'm sending a diff of the Makefile, but you know very well what i'm
talking about ;)
> So here's a refreshed diff. The test target is still kinda broken, so
> real use reports would be nice.
>
> Brad, still ok?
Charlène.
Index: Makefile
===
RCS file: /cvs/ports/databases/mariadb/Makefile,v
retrieving revision 1.77
diff -u -p -r1.77 Makefile
--- Makefile20 May 2019 10:31:23 - 1.77
+++ Makefile25 May 2019 20:29:02 -
@@ -7,7 +7,7 @@ COMMENT-main= multithreaded SQL database
COMMENT-server=multithreaded SQL database (server)
COMMENT-tests= multithreaded SQL database (regression test suite/benchmark)
-VERSION= 10.2.23
+VERSION= 10.3.14
DISTNAME= mariadb-${VERSION}
PKGNAME-main= mariadb-client-${VERSION}
PKGNAME-server=mariadb-server-${VERSION}
@@ -46,7 +46,7 @@ BUILD_DEPENDS=devel/bison
LIB_DEPENDS-main= ${LIB_DEPENDS} \
converters/libiconv
-RUN_DEPENDS-server=${BASE_PKGPATH},-main>=10.2v1,<10.3v1 \
+RUN_DEPENDS-server=${BASE_PKGPATH},-main>=10.3v1,<10.4v1 \
databases/p5-DBD-mysql
LIB_DEPENDS-server=${LIB_DEPENDS} \
archivers/bzip2 \
@@ -56,7 +56,7 @@ LIB_DEPENDS-server= ${LIB_DEPENDS} \
archivers/xz \
converters/libiconv \
devel/pcre
-RUN_DEPENDS-tests= ${BASE_PKGPATH},-main>=10.2v1,<10.3v1
+RUN_DEPENDS-tests= ${BASE_PKGPATH},-main>=10.3v1,<10.4v1
LIB_DEPENDS-tests= ${LIB_DEPENDS} \
converters/libiconv \
devel/pcre
@@ -115,6 +115,11 @@ CFLAGS+= -I${LOCALBASE}/include
CXXFLAGS+= -I${LOCALBASE}/include
LDFLAGS+= -L${LOCALBASE}/lib
+.if ${MACHINE_ARCH} == "powerpc"
+LDFLAGS += -latomic
+WANTLIB += atomic
+.endif
+
CONFIGURE_ENV= LDFLAGS="${LDFLAGS}"
MULTI_PACKAGES=-main -server -tests
@@ -143,10 +148,12 @@ post-install:
cd mysql && \
ln -sf libmariadb.so.${LIBmariadb_VERSION}
libmysqlclient.so.${LIBmysqlclient_VERSION} && \
ln -sf libmariadb.so.${LIBmariadb_VERSION}
libmysqlclient_r.so.${LIBmysqlclient_r_VERSION}
+ ${INSTALL_DATA} ${FILESDIR}/my.cnf ${PREFIX}/share/examples/mysql/
rm -Rf ${PREFIX}/share/mysql-test/plugin/rocksdb/
.if ${BUILD_PACKAGES:M-tests}
do-test:
+ (${MODCMAKE_TEST_TARGET}) || true # Keep on going even if regress tests
fail
@cd ${WRKBUILD}/mysql-test && ./mysql-test-run.pl --force --verbose
--max-test-fail=0
.else
NO_TEST= Yes
CVS: cvs.openbsd.org: ports
CVSROOT:/cvs Module name:ports Changes by: na...@cvs.openbsd.org 2019/05/25 13:54:45 Modified files: education/anki : Makefile Log message: Even if this is BROKEN, add a valid master site since dpb -F disregards BROKEN/IGNORE.
Re: [update] mariadb-10.3.14
On 5/25/2019 12:58 PM, Jeremie Courreges-Anglas wrote: On Tue, May 14 2019, Jeremie Courreges-Anglas wrote: On Mon, May 13 2019, Jeremie Courreges-Anglas wrote: Now that 10.2 has been committed, here's an update to the latest. Upstream removed the example config file so I decided to create one based on https://mariadb.com/kb/en/library/configuring-mariadb-with-option-files/ No symbol change in the SHARED_LIBS. The diff also includes a fix for the test target (mysql-test tests don't finish here). Looking for real use reports and oks. no_server doesn't build any more because my_global.h file is missing, so I'm holding off for now. Test reports still welcome. bah, I'm not sure why breaking the no_server PSEUDO_FLAVOR would matter. The problem is known upstream and I worked around it in the diff below. https://jira.mariadb.org/browse/MDEV-19152 Meanwhile, cwen@ reported that mariadb-10.2.23 doesn't build on powerpc because it's lacking __sync_* atomics. 10.3.x switched to __atomic_* builtins which are better supported by gcc-8.3.0, this fixes mariadb on powerpc according to cwen's tests (thanks!). So here's a refreshed diff. The test target is still kinda broken, so real use reports would be nice. Brad, still ok? Update to 10.3.15 before commiting. I have an update to 10.2.24 pending to cover three CVE but updating to .15 would cover that as well. OK. Thank you.
CVS: cvs.openbsd.org: ports
CVSROOT:/cvs Module name:ports Changes by: na...@cvs.openbsd.org 2019/05/25 13:43:03 Modified files: devel/quirks : Makefile devel/quirks/files: Quirks.pm Log message: update CVE entry for net/curl; reminded by danj@
CVS: cvs.openbsd.org: ports
CVSROOT:/cvs Module name:ports Changes by: na...@cvs.openbsd.org 2019/05/25 13:39:26 Modified files: net/curl : Tag: OPENBSD_6_5 Makefile Added files: net/curl/patches: Tag: OPENBSD_6_5 patch-lib_setopt_c patch-lib_tftp_c patch-lib_urlapi_c patch-lib_urldata_h Log message: Security fixes: CVE-2019-5435: Integer overflows in curl_url_set CVE-2019-5436: TFTP receive buffer overflow
CVS: cvs.openbsd.org: ports
CVSROOT:/cvs Module name:ports Changes by: es...@cvs.openbsd.org 2019/05/25 13:27:48 Modified files: sysutils/random_run: Makefile distinfo Log message: actually interface with sysconf to avoid execve E2BIG.
Re: [update] sysutils/nnn
Oops, forgot to send the actual diff, Sorry
On 5/25/19 11:04 PM, bijan wrote:
Hi ports,
The following diff is the update of nnn file manager.
Hope it helps.
B.E
diff --git a/sysutils/nnn/Makefile b/sysutils/nnn/Makefile
index eae01c6..334b358 100644
--- a/sysutils/nnn/Makefile
+++ b/sysutils/nnn/Makefile
@@ -1,37 +1,31 @@
# $OpenBSD: Makefile,v 1.1.1.1 2018/05/07 18:29:00 kn Exp $
-COMMENT = the missing terminal file browser for X
+COMMENT= snappy terminal file browser for X
-V = 1.8
-DISTNAME = nnn-v${V}
-PKGNAME = nnn-${V}
+V= 2.4
+DISTNAME= nnn-v${V}
+PKGNAME= nnn-${V}
-CATEGORIES = sysutils
+CATEGORIES= sysutils
-HOMEPAGE = https://github.com/jarun/nnn/
+GH_ACCOUNT= jarun
+GH_PROJECT= nnn
+GH_TAGNAME= v$(V)
-MAINTAINER = Ljuba Nedeljkovic
+HOMEPAGE= https://github.com/jarun/nnn/
-# BSD
-PERMIT_PACKAGE_CDROM = Yes
-
-WANTLIB = c curses readline
-
-MASTER_SITES = https://github.com/jarun/nnn/releases/download/v${V}/
+MAINTAINER= Ljuba Nedeljkovic
-RUN_DEPENDS = shells/bash
-
-USE_GMAKE = Yes
-NO_TEST = Yes
+# BSD
+PERMIT_PACKAGE_CDROM= Yes
-WRKDIST = ${WRKDIR}/nnn
+WANTLIB= c curses readline
-pre-configure:
- ${SUBST_CMD} ${WRKSRC}/nlay
+USE_GMAKE= Yes
+NO_TEST= Yes
do-install:
${INSTALL_PROGRAM} ${WRKSRC}/nnn ${PREFIX}/bin/
- ${INSTALL_SCRIPT} ${WRKSRC}/nlay ${PREFIX}/bin/
${INSTALL_MAN} ${WRKSRC}/nnn.1 ${PREFIX}/man/man1/
${INSTALL_DATA_DIR} ${PREFIX}/share/bash-completion/completions/
diff --git a/sysutils/nnn/distinfo b/sysutils/nnn/distinfo
index 7c6be06..47de0f5 100644
--- a/sysutils/nnn/distinfo
+++ b/sysutils/nnn/distinfo
@@ -1,2 +1,2 @@
-SHA256 (nnn-v1.8.tar.gz) = 5VioxbeEe8flfyPw3faQ0mbBXGNDDjbolVj69p+jkH8=
-SIZE (nnn-v1.8.tar.gz) = 42453
+SHA256 (nnn-v2.4.tar.gz) = hZulvUiSAWrtmkgw7h4bA+t06UxPG9gvAojcVZ9zJ+s=
+SIZE (nnn-v2.4.tar.gz) = 62510
diff --git a/sysutils/nnn/patches/patch-nlay b/sysutils/nnn/patches/patch-nlay
deleted file mode 100644
index 588d664..000
--- a/sysutils/nnn/patches/patch-nlay
+++ /dev/null
@@ -1,11 +0,0 @@
-$OpenBSD: patch-nlay,v 1.1.1.1 2018/05/07 18:29:00 kn Exp $
-
-Index: nlay
nlay.orig
-+++ nlay
-@@ -1,4 +1,4 @@
--#!/usr/bin/env bash
-+#!${LOCALBASE}/bin/bash
-
- # #
- # nlay: a customizable script to play files in different apps by file type
Update: archivers/innoextract - fixes extraction of GOG.com Windows archives
Hi,
When trying to download and extract Ultimate Doom to test the gzdoom
update, I couldn't extract the GOG.com file with our innoextract. Turns
out that GOG.com has moved forward to creating those with a snapshot
version of Inno Setup that is not supported by the last release of
innoextract.
This diff updates the port to the latest snapshot of innoextract that
specifically addresses the issues with GOG. Of note, this proposed
update switches from the distfiles of the Homepage to the GitHub
commit. I am usually against this where possible because of GH's track
record of changing their on-the-fly tarball creation without notice. I
looked at the relevant patch history since release to see if we could
stay with 1.7 and add a patch, but the changes are too complex and
would make next updates potentially confusing. Therefore, I propose to
temporarily switch to GH_COMMIT. I placed a comment to switch back when
possible.
I think this is justified by GOG.com downloads being the main use case
which is broken in the current state. This update fixes the extraction
of the Ultimate Doom file.
Is 1.7.20190228 acceptable as the update version number? Feb 28, 2019
is the date of the GH commit, and the next release will likely be 1.8.
I would like to take MAINTAINER of innoextract while here.
ok?
Index: Makefile
===
RCS file: /cvs/ports/archivers/innoextract/Makefile,v
retrieving revision 1.12
diff -u -p -r1.12 Makefile
--- Makefile16 Apr 2019 20:19:01 - 1.12
+++ Makefile25 May 2019 18:22:50 -
@@ -2,19 +2,22 @@
COMMENT= unpack Inno Setup installers
-DISTNAME= innoextract-1.7
-REVISION= 2
+DISTNAME= innoextract-1.7.20190228
+
+# revert to MASTER_SITES=${HOMEPAGE}files/ when releases have caught up
+GH_ACCOUNT=dscharrer
+GH_PROJECT=innoextract
+GH_COMMIT= 38ae68f393b2f3ed1862ec7f24b1d99bbbaacb19
CATEGORIES=archivers
HOMEPAGE= https://constexpr.org/innoextract/
-
-MASTER_SITES= ${HOMEPAGE}files/
+MAINTAINER=Thomas Frohwein
# zlib/libpng
PERMIT_PACKAGE_CDROM= Yes
WANTLIB= boost_filesystem-mt boost_iostreams-mt boost_program_options-mt
-WANTLIB+= c iconv lzma m pthread ${COMPILER_LIBCXX}
+WANTLIB+= boost_system-mt c iconv lzma m pthread ${COMPILER_LIBCXX}
COMPILER= base-clang ports-gcc
Index: distinfo
===
RCS file: /cvs/ports/archivers/innoextract/distinfo,v
retrieving revision 1.4
diff -u -p -r1.4 distinfo
--- distinfo24 Jun 2018 08:56:16 - 1.4
+++ distinfo25 May 2019 18:22:50 -
@@ -1,2 +1,2 @@
-SHA256 (innoextract-1.7.tar.gz) = we+3MvK8OoAGXF9RoNTqYCeuv1KMYJ0/M2rqIFXS8KQ=
-SIZE (innoextract-1.7.tar.gz) = 195123
+SHA256 (innoextract-1.7.20190228-38ae68f3.tar.gz) =
/qGU0dwlvZ/Wyau1lx/sf2C0Cp7QnJ75TWnI0vFR5sA=
+SIZE (innoextract-1.7.20190228-38ae68f3.tar.gz) = 194606
[update] sysutils/nnn
Hi ports, The following diff is the update of nnn file manager. Hope it helps. B.E
Re: Move lang/pcc to lang/pcc/pcc, update to 20190521 and add lang/pcc/pcc-libs
On Sat, May 25, 2019 at 01:12:06PM -0400, Brian Callahan wrote:
> On 5/25/19 11:58 AM, Leonid Bobrov wrote:
> > Index: Makefile.inc
> > ===
> > RCS file: Makefile.inc
> > diff -N Makefile.inc
> > --- /dev/null 1 Jan 1970 00:00:00 -
> > +++ Makefile.inc25 May 2019 15:51:13 -
> > @@ -0,0 +1,17 @@
> > +# $OpenBSD: Makefile,v 1.17 2019/05/03 16:59:10 danj Exp $
> > +
> > +ONLY_FOR_ARCHS = i386 amd64 sparc64 mips64 mips64el powerpc
>
> How did you come up with this list? Either it should be all archs with
> backend code in pcc (in which case you're missing some archs) or it should
> be all archs that are known to build (that would be amd64 i386 mips64
> mips64el) or it should be all archs that are known to build and actually
> work (amd64 i386). You should use the build and actually work list.
>
This list comes from configure scripts (and pkgsrc don't even have this
list in lang/pcc-current, while in lang/pcc they set it to arm*, i386,
mips*, powerpc, sparc64, vax and x86_64):
pcc configure (NetBSD has longer list)
```
openbsd*)
targos=openbsd
abi=elf
stabs=yes
case "$target_cpu" in
i?86) targmach=i386 ;;
vax) targmach=vax ;;
mips64el) targmach=mips64 ;;
mips64) targmach=mips64 endian=big ;;
powerpc) targmach=powerpc endian=big ;;
sparc64) targmach=sparc64 endian=big ;;
m68k) targmach=m68k endian=big ;;
x86_64) targmach=amd64 ;;
esac
;;
```
pcc-libs configure (NetBSD has longer list)
```
openbsd*)
targos=openbsd
case "$target_cpu" in
i?86) targmach=i386 ;;
mips64el) targmach=mips ;;
mips64) targmach=mips endian=big ;;
powerpc) targmach=powerpc endian=big ;;
sparc64) targmach=sparc64 endian=big ;;
vax) targmach=vax ;;
x86_64) targmach=amd64 ;;
esac
;;
```
I didn't add m68k and vax to this list because OpenBSD doesn't support
them (however OpenBSD supports m88k, but I don't know is it compatible
with m68k or not).
I didn't actually test that because I either need exotic hardwares or
need to setup virtual machines, so I choose to trust configure script
and to trust what NetBSD/pkgsrc already do.
> > Index: pcc/Makefile
> > ===
> > RCS file: pcc/Makefile
> > diff -N pcc/Makefile
> > --- /dev/null 1 Jan 1970 00:00:00 -
> > +++ pcc/Makefile25 May 2019 15:51:13 -
> > @@ -0,0 +1,21 @@
> > +# $OpenBSD: Makefile,v 1.17 2019/05/03 16:59:10 danj Exp $
> > +
> > +COMMENT = portable C compiler
> > +
> > +DISTNAME = pcc-${V}
>
> This would make PKGNAME=pcc-${V}, which isn't ok. Likewise, the PKGNAME for
> pcc-libs is pcc-libs-${V} which also isn't ok.
>
> ~Brian
>
That's what I was asking in the start of this topic: should I use
versioning like PKGNAME=pcc=1.1.0.${V}?
Ruby 2.6 Signal Handling Fix
This backports a patch I committed upstream (I'm now a Ruby commiter),
which fixes signal handling on OpenBSD. This allows us to remove a
couple patches which skipped tests that used to hang, which I thought
were related to the fifo pthread fdlock issue, but turned out to be due
to the signal handling bug. It also fixes an annoying issue in irb,
where Ctrl+C is ignored until another key is pressed.
This also removes another patch for skipping a thread test which hanged
due to the fifo pthread fdlock issue, which is no longer necessary now
that that issue has been fixed.
This fix is only needed on Ruby 2.6, as the issue does not affect
earlier Ruby versions.
Tested on amd64. Will be committing in a couple days unless I hear
objections.
Thanks,
Jeremy
Index: Makefile
===
RCS file: /cvs/ports/lang/ruby/2.6/Makefile,v
retrieving revision 1.4
diff -u -p -r1.4 Makefile
--- Makefile26 Apr 2019 15:46:28 - 1.4
+++ Makefile25 May 2019 17:30:04 -
@@ -5,6 +5,11 @@ DISTNAME = ruby-${VERSION}
SHARED_LIBS = ruby26 0.0
NEXTVER = 2.7
+REVISION-main =0
+MASTER_SITES0 =https://github.com/ruby/ruby/commit/
+PATCHFILES = 1ef39d8d099f145222b9352423af16a2bab6e05b.patch:0
+PATCH_DIST_STRIP = -p1
+
PSEUDO_FLAVORS=no_ri_docs bootstrap
# Do not build the RI docs on slow arches
.if ${MACHINE_ARCH:Malpha} || ${MACHINE_ARCH:Marm} || ${MACHINE_ARCH:Mhppa}
Index: distinfo
===
RCS file: /cvs/ports/lang/ruby/2.6/distinfo,v
retrieving revision 1.4
diff -u -p -r1.4 distinfo
--- distinfo26 Apr 2019 15:46:28 - 1.4
+++ distinfo25 May 2019 17:30:04 -
@@ -1,2 +1,4 @@
+SHA256 (1ef39d8d099f145222b9352423af16a2bab6e05b.patch) =
eiBIYlSeJXKklacgt8QHVE6arFAY9eCjWODxjNWBXVg=
SHA256 (ruby-2.6.3.tar.gz) = V3/TeV8iuNkcHU5nM2N7A5TUCC22WfzPIkx3Siscgvs=
+SIZE (1ef39d8d099f145222b9352423af16a2bab6e05b.patch) = 2584
SIZE (ruby-2.6.3.tar.gz) = 16784748
Index: patches/patch-test_ruby_test_process_rb
===
RCS file: patches/patch-test_ruby_test_process_rb
diff -N patches/patch-test_ruby_test_process_rb
--- patches/patch-test_ruby_test_process_rb 14 Jan 2019 16:13:05 -
1.1.1.1
+++ /dev/null 1 Jan 1970 00:00:00 -
@@ -1,25 +0,0 @@
-$OpenBSD: patch-test_ruby_test_process_rb,v 1.1.1.1 2019/01/14 16:13:05 jeremy
Exp $
-
-Skip hanging tests, potentially due to fifo fd locking.
-
-Index: test/ruby/test_process.rb
test/ruby/test_process.rb.orig
-+++ test/ruby/test_process.rb
-@@ -672,7 +672,7 @@ class TestProcess < Test::Unit::TestCase
- assert_equal("ok\n", io.read)
- }
- }
-- end unless windows? # does not support fifo
-+ end if false # fifo fdlock bug?
-
- def test_execopts_redirect_open_fifo_interrupt_print
- with_tmpchdir {|d|
-@@ -695,7 +695,7 @@ class TestProcess < Test::Unit::TestCase
- assert_equal("ok\n", io.read)
- }
- }
-- end unless windows? # does not support fifo
-+ end if false # fifo fdlock bug?
-
- def test_execopts_redirect_pipe
- with_pipe {|r1, w1|
Index: patches/patch-test_ruby_test_thread_rb
===
RCS file: patches/patch-test_ruby_test_thread_rb
diff -N patches/patch-test_ruby_test_thread_rb
--- patches/patch-test_ruby_test_thread_rb 14 Jan 2019 16:13:05 -
1.1.1.1
+++ /dev/null 1 Jan 1970 00:00:00 -
@@ -1,16 +0,0 @@
-$OpenBSD: patch-test_ruby_test_thread_rb,v 1.1.1.1 2019/01/14 16:13:05 jeremy
Exp $
-
-Skip hanging test.
-
-Index: test/ruby/test_thread.rb
test/ruby/test_thread.rb.orig
-+++ test/ruby/test_thread.rb
-@@ -976,7 +976,7 @@ _eom
- [s.exited?, s.signaled?, s.stopped?, s.termsig],
- "[s.exited?, s.signaled?, s.stopped?, s.termsig]")
- assert_include(0..2, t, bug5757)
-- end
-+ end if false # possible fifo fdlock bug?
-
- def test_thread_join_in_trap
- assert_separately [], <<-'EOS'
Re: Blender - no gui menu displayed
OK for this patch for now, will look at the update later.
On Fri, 24 May 2019 16:49:38 +0200, Jeremie Courreges-Anglas wrote:
>
> +cc Pascal (maintainer of blender)
>
> On Mon, May 20 2019, Mihai Popescu wrote:
> > Hello,
> >
> > Maybe it is already known, but blender is not able to display gui
> > menus. IT renders just a blank no menu and items window. I will send
> > some terminal errors and dmesg. More info can be sent later.
> >
> > search for unknown operator 'WM_OT_context_set_enum',
> > 'WM_OT_context_set_enum'
> > RNA_string_set: OperatorProperties.data_path not found.
> > RNA_string_set: OperatorProperties.value not found.
>
> [...]
>
> > uiItemStringO: 'WM_OT_url_open' unknown operator
> > search for unknown menutype USERPREF_MT_splash_footer
> >
> > Blender quit
> >
> > OpenBSD 6.5-current (GENERIC.MP) #35: Sat May 18 11:40:36 MDT 2019
> > dera...@amd64.openbsd.org:/usr/src/sys/arch/amd64/compile/GENERIC.MP
>
> [...]
>
> Rebuilding blender with
>
> MODPY_VERSION =3.6
>
> fixes the UI issue here, I guess this could be used as a workaround.
> (Is there any rush to get rid of 3.6?)
>
> Updating the port to 2.79b didn't help.
>
> This issue may be relevant:
>
> "Blender UI failed to render using Python 3.7"
> https://developer.blender.org/T56969
>
>
> Index: Makefile
> ===
> RCS file: /cvs/ports/graphics/blender/Makefile,v
> retrieving revision 1.91
> diff -u -p -r1.91 Makefile
> --- Makefile 28 Apr 2019 20:51:41 - 1.91
> +++ Makefile 24 May 2019 14:47:52 -
> @@ -5,7 +5,7 @@ ONLY_FOR_ARCHS = amd64 i386
> COMMENT =3D creation software
>
> DISTNAME = blender-2.79
> -REVISION = 5
> +REVISION = 6
>
> CATEGORIES = graphics
>
> @@ -32,7 +32,7 @@ MODULES = devel/cmake \
>
> COMPILER = base-clang ports-gcc
>
> -MODPY_VERSION = ${MODPY_DEFAULT_VERSION_3}
> +MODPY_VERSION = 3.6
>
> CONFIGURE_ARGS = -DPYTHON_INCLUDE_DIR="${MODPY_INCDIR}" \
> -DPYTHON_VERSION=${MODPY_VERSION} \
>
>
> --
> jca | PGP : 0x1524E7EE / 5135 92C1 AD36 5293 2BDF DDCC 0DFA 74AE 1524 E7EE
Re: Move lang/pcc to lang/pcc/pcc, update to 20190521 and add lang/pcc/pcc-libs
On 5/25/19 11:58 AM, Leonid Bobrov wrote:
On Thu, May 23, 2019 at 12:58:48PM -0400, Brian Callahan wrote:
On 5/23/19 8:35 AM, Leonid Bobrov wrote:
In do-test target replace "./cc/cc/pcc" with "./cc/cc/cc".
I don't understand this test target at all to be perfectly honest. All it
does it make sure the driver program can spit out a single line of text. It
doesn't initiate the preprocessor or the actual compiler, and ignores the
tests that actually ship with pcc.
There are preprocessor tests that ship with the pcc tree that could be run
with
do-test:
cd ${WRKBUILD}/cc/cpp && ${MAKE_PROGRAM} test
There are additional tests for pcc that live in a separate pcc cvs
repository. Doesn't seem necessary to grab them for the port. We should
either run the cpp tests or not bother with tests at all.
Also p++ is not a C++ compiler, it can't even compile hello world in C++
:(
Correct. The way to skip building cxxcom is to edit
${WRKBUILD}/cc/Makefile.in and remove cxxcom from ALL_SUBDIRS. And remove
p++ from DRIVERS in cc/cc/Makefile.in so as to not install the p++ driver.
Additionally, the port Makefile for pcc should have the environment variable
YACC set to yacc (or /usr/bin/yacc), otherwise configure will silently pick
up bison if bison is installed.
~Brian
Ok, I prefer not bothering with cpp tests. Also actually configure
environment needs YACC. And yeah, this time no cxxcom and p++:
Index: Makefile
===
RCS file: /cvs/ports/lang/pcc/Makefile,v
retrieving revision 1.17
diff -u -p -r1.17 Makefile
--- Makefile3 May 2019 16:59:10 - 1.17
+++ Makefile25 May 2019 15:51:13 -
@@ -1,33 +1,7 @@
# $OpenBSD: Makefile,v 1.17 2019/05/03 16:59:10 danj Exp $
-COMMENT = portable C compiler
+SUBDIR =
+SUBDIR += pcc
+SUBDIR += pcc-libs
-PCCVER = 1.0.0
-DISTNAME = pcc-${PCCVER}
-REVISION = 14
-EXTRACT_SUFX = .tgz
-
-CATEGORIES = lang
-
-HOMEPAGE = http://pcc.ludd.ltu.se/
-
-# Other architectures not fully supported yet
-ONLY_FOR_ARCHS = i386 amd64
-
-# BSD
-PERMIT_PACKAGE_CDROM = Yes
-
-WANTLIB += c
-
-MASTER_SITES = http://pcc.ludd.ltu.se/ftp/pub/pcc-releases/ \
- ftp://pcc.ludd.ltu.se/pub/pcc-releases/
-
-CONFIGURE_STYLE = gnu
-
-CONFIG = ${MACHINE_ARCH:S/amd64/x86_64/}-unknown-openbsd${OSREV}
-SUBST_VARS = PCCVER CONFIG
-
-do-test:
- cd ${WRKBUILD} && ./cc/cc/pcc --version
-
-.include
+.include
Index: Makefile.inc
===
RCS file: Makefile.inc
diff -N Makefile.inc
--- /dev/null 1 Jan 1970 00:00:00 -
+++ Makefile.inc25 May 2019 15:51:13 -
@@ -0,0 +1,17 @@
+# $OpenBSD: Makefile,v 1.17 2019/05/03 16:59:10 danj Exp $
+
+ONLY_FOR_ARCHS = i386 amd64 sparc64 mips64 mips64el powerpc
How did you come up with this list? Either it should be all archs with
backend code in pcc (in which case you're missing some archs) or it
should be all archs that are known to build (that would be amd64 i386
mips64 mips64el) or it should be all archs that are known to build and
actually work (amd64 i386). You should use the build and actually work list.
+
+V =20190521
+EXTRACT_SUFX = .tgz
+
+CATEGORIES ?= lang
+
+HOMEPAGE ?=http://pcc.ludd.ltu.se/
+
+# BSD
+PERMIT_PACKAGE_CDROM = Yes
+
+CONFIGURE_STYLE =gnu
+
+NO_TEST ?= Yes
Index: distinfo
===
RCS file: distinfo
diff -N distinfo
--- distinfo18 Jan 2015 03:14:19 - 1.2
+++ /dev/null 1 Jan 1970 00:00:00 -
@@ -1,2 +0,0 @@
-SHA256 (pcc-1.0.0.tgz) = WALbukbW6j+brapVuQRKBBa7QQAgwkpcKoouqvQRVss=
-SIZE (pcc-1.0.0.tgz) = 652308
Index: pcc/Makefile
===
RCS file: pcc/Makefile
diff -N pcc/Makefile
--- /dev/null 1 Jan 1970 00:00:00 -
+++ pcc/Makefile25 May 2019 15:51:13 -
@@ -0,0 +1,21 @@
+# $OpenBSD: Makefile,v 1.17 2019/05/03 16:59:10 danj Exp $
+
+COMMENT = portable C compiler
+
+DISTNAME = pcc-${V}
This would make PKGNAME=pcc-${V}, which isn't ok. Likewise, the PKGNAME
for pcc-libs is pcc-libs-${V} which also isn't ok.
~Brian
+
+CATEGORIES = lang
+
+# BSD
+PERMIT_PACKAGE_CDROM = Yes
+
+WANTLIB += c
+
+RUN_DEPENDS = lang/pcc/pcc-libs
+
+MASTER_SITES = http://pcc.ludd.ltu.se/ftp/pub/pcc/ \
+ ftp://pcc.ludd.ltu.se/pub/pcc/
+
+CONFIGURE_ENV =YACC=/usr/bin/yacc
+
+.include
Index: pcc/distinfo
===
RCS file: pcc/distinfo
diff -N pcc/distinfo
--- /dev/null 1 Jan 1970 00:00:00 -
+++ pcc/distinfo25 May 2019 15:51:13 -
@@ -0,0 +1,2 @@
+SHA256 (pcc-20190521.tgz) = Ndw5lkx8zbJnr+al/oIkdVaIpZavfzQLgPiy/n1BD1g=
+SIZE (pcc-20190521.tgz) = 943299
Index: pcc/patches/patch-cc_Makefile_in
===
RCS file:
[wip] Xfce 4.14pre1
Hi, since some years now i've been maintaining x11/xfce4 in the portstree, with an alternate repo at https://cgit.rhaalovely.net/xfce4/?h=next tracking upstream devel releases. This repo now contains all the bits composing 4.14pre1 (cf https://simon.shimmerproject.org/2019/05/19/xfce-4-14pre1-released/ for the details, the main thing being of course the complete port to Gtk+3), the final release being targeted at sometimes during the summer. as an upstream developer i've of course been running it during the development cycle on most of my boxes, but now would be a good time for other Xfce users on OpenBSD to give it a shot and eventually report some bugs to https://bugzilla.xfce.org. The main OpenBSD-specific change is https://bugzilla.xfce.org/show_bug.cgi?id=14722 (needs testing !) which will make the consolekit/policykit/messagebus dependency completely optional, allowing an user in the operator group to shutdown the machine (ie can run the shutdown binary), or suspend/hibernate if in the wheel group (ie has access to apmdev), instead of relying on 3 daemons running as root. The previous mode of needing messagebus running + spawning startxfce4 within consolekit should still work. amd64 -current packages for all core xfce pkgs (and some others i'm using) are available at https://packages.rhaalovely.net/wip/amd64/ (signed with https://packages.rhaalovely.net/landry-mozilla-pkg.pub) barring delays, this should make 6.6, but it's better if it's been "widely" tested before.. Landry
CVS: cvs.openbsd.org: ports
CVSROOT:/cvs Module name:ports Changes by: na...@cvs.openbsd.org 2019/05/25 10:09:26 Modified files: net/curl : Makefile distinfo net/curl/pkg : PLIST Log message: Update to 7.65.0. Includes security fixes for: CVE-2019-5435: Integer overflows in curl_url_set CVE-2019-5436: tftp: use the current blksize for recvfrom()
Re: Move lang/pcc to lang/pcc/pcc, update to 20190521 and add lang/pcc/pcc-libs
On Thu, May 23, 2019 at 12:58:48PM -0400, Brian Callahan wrote:
>
>
> On 5/23/19 8:35 AM, Leonid Bobrov wrote:
> > In do-test target replace "./cc/cc/pcc" with "./cc/cc/cc".
>
> I don't understand this test target at all to be perfectly honest. All it
> does it make sure the driver program can spit out a single line of text. It
> doesn't initiate the preprocessor or the actual compiler, and ignores the
> tests that actually ship with pcc.
>
> There are preprocessor tests that ship with the pcc tree that could be run
> with
> do-test:
> cd ${WRKBUILD}/cc/cpp && ${MAKE_PROGRAM} test
>
> There are additional tests for pcc that live in a separate pcc cvs
> repository. Doesn't seem necessary to grab them for the port. We should
> either run the cpp tests or not bother with tests at all.
>
> > Also p++ is not a C++ compiler, it can't even compile hello world in C++
> > :(
>
> Correct. The way to skip building cxxcom is to edit
> ${WRKBUILD}/cc/Makefile.in and remove cxxcom from ALL_SUBDIRS. And remove
> p++ from DRIVERS in cc/cc/Makefile.in so as to not install the p++ driver.
>
> Additionally, the port Makefile for pcc should have the environment variable
> YACC set to yacc (or /usr/bin/yacc), otherwise configure will silently pick
> up bison if bison is installed.
>
> ~Brian
>
Ok, I prefer not bothering with cpp tests. Also actually configure
environment needs YACC. And yeah, this time no cxxcom and p++:
Index: Makefile
===
RCS file: /cvs/ports/lang/pcc/Makefile,v
retrieving revision 1.17
diff -u -p -r1.17 Makefile
--- Makefile3 May 2019 16:59:10 - 1.17
+++ Makefile25 May 2019 15:51:13 -
@@ -1,33 +1,7 @@
# $OpenBSD: Makefile,v 1.17 2019/05/03 16:59:10 danj Exp $
-COMMENT = portable C compiler
+SUBDIR =
+SUBDIR += pcc
+SUBDIR += pcc-libs
-PCCVER = 1.0.0
-DISTNAME = pcc-${PCCVER}
-REVISION = 14
-EXTRACT_SUFX = .tgz
-
-CATEGORIES = lang
-
-HOMEPAGE = http://pcc.ludd.ltu.se/
-
-# Other architectures not fully supported yet
-ONLY_FOR_ARCHS = i386 amd64
-
-# BSD
-PERMIT_PACKAGE_CDROM = Yes
-
-WANTLIB += c
-
-MASTER_SITES = http://pcc.ludd.ltu.se/ftp/pub/pcc-releases/ \
- ftp://pcc.ludd.ltu.se/pub/pcc-releases/
-
-CONFIGURE_STYLE = gnu
-
-CONFIG = ${MACHINE_ARCH:S/amd64/x86_64/}-unknown-openbsd${OSREV}
-SUBST_VARS = PCCVER CONFIG
-
-do-test:
- cd ${WRKBUILD} && ./cc/cc/pcc --version
-
-.include
+.include
Index: Makefile.inc
===
RCS file: Makefile.inc
diff -N Makefile.inc
--- /dev/null 1 Jan 1970 00:00:00 -
+++ Makefile.inc25 May 2019 15:51:13 -
@@ -0,0 +1,17 @@
+# $OpenBSD: Makefile,v 1.17 2019/05/03 16:59:10 danj Exp $
+
+ONLY_FOR_ARCHS = i386 amd64 sparc64 mips64 mips64el powerpc
+
+V =20190521
+EXTRACT_SUFX = .tgz
+
+CATEGORIES ?= lang
+
+HOMEPAGE ?=http://pcc.ludd.ltu.se/
+
+# BSD
+PERMIT_PACKAGE_CDROM = Yes
+
+CONFIGURE_STYLE =gnu
+
+NO_TEST ?= Yes
Index: distinfo
===
RCS file: distinfo
diff -N distinfo
--- distinfo18 Jan 2015 03:14:19 - 1.2
+++ /dev/null 1 Jan 1970 00:00:00 -
@@ -1,2 +0,0 @@
-SHA256 (pcc-1.0.0.tgz) = WALbukbW6j+brapVuQRKBBa7QQAgwkpcKoouqvQRVss=
-SIZE (pcc-1.0.0.tgz) = 652308
Index: pcc/Makefile
===
RCS file: pcc/Makefile
diff -N pcc/Makefile
--- /dev/null 1 Jan 1970 00:00:00 -
+++ pcc/Makefile25 May 2019 15:51:13 -
@@ -0,0 +1,21 @@
+# $OpenBSD: Makefile,v 1.17 2019/05/03 16:59:10 danj Exp $
+
+COMMENT = portable C compiler
+
+DISTNAME = pcc-${V}
+
+CATEGORIES = lang
+
+# BSD
+PERMIT_PACKAGE_CDROM = Yes
+
+WANTLIB += c
+
+RUN_DEPENDS = lang/pcc/pcc-libs
+
+MASTER_SITES = http://pcc.ludd.ltu.se/ftp/pub/pcc/ \
+ ftp://pcc.ludd.ltu.se/pub/pcc/
+
+CONFIGURE_ENV =YACC=/usr/bin/yacc
+
+.include
Index: pcc/distinfo
===
RCS file: pcc/distinfo
diff -N pcc/distinfo
--- /dev/null 1 Jan 1970 00:00:00 -
+++ pcc/distinfo25 May 2019 15:51:13 -
@@ -0,0 +1,2 @@
+SHA256 (pcc-20190521.tgz) = Ndw5lkx8zbJnr+al/oIkdVaIpZavfzQLgPiy/n1BD1g=
+SIZE (pcc-20190521.tgz) = 943299
Index: pcc/patches/patch-cc_Makefile_in
===
RCS file: pcc/patches/patch-cc_Makefile_in
diff -N pcc/patches/patch-cc_Makefile_in
--- /dev/null 1 Jan 1970 00:00:00 -
+++ pcc/patches/patch-cc_Makefile_in25 May 2019 15:51:13 -
@@ -0,0 +1,14 @@
+$OpenBSD$
+
+Index: cc/Makefile.in
+--- cc/Makefile.in.orig
cc/Makefile.in
+@@ -5,7 +5,7 @@
+
+ @SET_MAKE@
+
+-ALL_SUBDIRS= cc cpp ccom cxxcom
++ALL_SUBDIRS= cc cpp ccom
+ DIST_SUBDIRS= $(ALL_SUBDIRS) driver
+
+ all install clean:
Index: pcc/patches/patch-cc_cc_Makefile_in
CVS: cvs.openbsd.org: ports
CVSROOT:/cvs Module name:ports Changes by: bcal...@cvs.openbsd.org 2019/05/25 09:49:40 Modified files: games/corsixth : Makefile distinfo games/corsixth/patches: patch-CorsixTH_Lua_app_lua games/corsixth/pkg: PLIST Log message: Update corsixth to 0.63 Changelog highlights: https://github.com/CorsixTH/CorsixTH/releases
Re: dpb doesn't forget invalid distfile
Marc Espie: > Yep, -F will try to fetch everything. > If you want an option to ignore BROKEN ports, that's do-able. No, I think the lesson is not to slap BROKEN on unfetchable ports. -- Christian "naddy" Weisgerber na...@mips.inka.de
Re: dpb doesn't forget invalid distfile
On Sat, May 25, 2019 at 05:01:08PM +0200, Marc Espie wrote: > On Sat, May 25, 2019 at 04:24:40PM +0200, Christian Weisgerber wrote: > > Christian Weisgerber: > > > > > E=education/anki:anki-2.0.52-source.tgz > > > > > > There is no such error on machines where dpb did not perform a fetch > > > run during the brief window when anki-2.0.52 was enabled. > > > > Actually, I think that's a misunderstanding on my part. I was > > comparing dpb -F2 runs on one host with dpb -a runs elsewhere. I > > guess when dpb _builds_ packages, it ignores the BROKEN port. When > > it purely _fetches_ packages, it doesn't. > > Yep, -F will try to fetch everything. > > If you want an option to ignore BROKEN ports, that's do-able. > > I think that, by this point, BROKEN all use BROKEN-arch for arch-dependent > breakage, so that would still get mirroring of used distfiles done correctly. Strike that... this would require changes to bsd.port.mk actually, since BROKEN gets encoded into IGNORE, so we would need to make a distinction in there, and pass it to dpb. Not sure that's worth it changing that.
Re: dpb doesn't forget invalid distfile
On Sat, May 25, 2019 at 04:24:40PM +0200, Christian Weisgerber wrote: > Christian Weisgerber: > > > E=education/anki:anki-2.0.52-source.tgz > > > > There is no such error on machines where dpb did not perform a fetch > > run during the brief window when anki-2.0.52 was enabled. > > Actually, I think that's a misunderstanding on my part. I was > comparing dpb -F2 runs on one host with dpb -a runs elsewhere. I > guess when dpb _builds_ packages, it ignores the BROKEN port. When > it purely _fetches_ packages, it doesn't. Yep, -F will try to fetch everything. If you want an option to ignore BROKEN ports, that's do-able. I think that, by this point, BROKEN all use BROKEN-arch for arch-dependent breakage, so that would still get mirroring of used distfiles done correctly.
Re: dpb doesn't forget invalid distfile
Marc Espie: > > E=education/anki:anki-2.0.52-source.tgz > > > > What do I need to delete to get rid of this persistent fetch error? > > How about some actual logs ? like what's in the lock ? locked=education/anki:anki-2.0.52-source.tgz dpb=23845 on ariolc.mips.inka.de > and what's in the dist/anki-2.0.52-source.tgz.log file ? >>> From education/anki ===> Trying https://apps.ankiweb.net/downloads/current/ /usr/bin/ftp -C -o /usr/ports/distfiles/anki-2.0.52-source.tgz.part -v https://apps.ankiweb.net/downloads/current/anki-2.0.52-source.tgz Trying 104.25.224.113... Requesting https://apps.ankiweb.net/downloads/current/anki-2.0.52-source.tgz ftp: Error retrieving file: 404 Not Found ===> Trying https://apps.ankiweb.net/downloads/beta/ /usr/bin/ftp -C -o /usr/ports/distfiles/anki-2.0.52-source.tgz.part -v https://apps.ankiweb.net/downloads/beta/anki-2.0.52-source.tgz Trying 104.25.224.113... Requesting https://apps.ankiweb.net/downloads/beta/anki-2.0.52-source.tgz ftp: Error retrieving file: 404 Not Found ===> Trying https://ftp.openbsd.org/pub/OpenBSD/distfiles/ /usr/bin/ftp -C -o /usr/ports/distfiles/anki-2.0.52-source.tgz.part -v https://ftp.openbsd.org/pub/OpenBSD/distfiles/anki-2.0.52-source.tgz Trying 129.128.5.191... Requesting https://ftp.openbsd.org/pub/OpenBSD/distfiles/anki-2.0.52-source.tgz ftp: Error retrieving file: 404 Not Found ===> Trying https://ftp.usa.openbsd.org/pub/OpenBSD/distfiles/ /usr/bin/ftp -C -o /usr/ports/distfiles/anki-2.0.52-source.tgz.part -v https://ftp.usa.openbsd.org/pub/OpenBSD/distfiles/anki-2.0.52-source.tgz Trying 129.21.208.172... Requesting https://ftp.usa.openbsd.org/pub/OpenBSD/distfiles/anki-2.0.52-source.tgz ftp: Error retrieving file: 404 Not Found ===> Trying https://ftp.fr.openbsd.org/pub/OpenBSD/distfiles/ /usr/bin/ftp -C -o /usr/ports/distfiles/anki-2.0.52-source.tgz.part -v https://ftp.fr.openbsd.org/pub/OpenBSD/distfiles/anki-2.0.52-source.tgz Trying 145.238.209.46... Requesting https://ftp.fr.openbsd.org/pub/OpenBSD/distfiles/anki-2.0.52-source.tgz ftp: Error retrieving file: 404 Not Found -- Christian "naddy" Weisgerber na...@mips.inka.de
Re: dpb doesn't forget invalid distfile
Christian Weisgerber: > E=education/anki:anki-2.0.52-source.tgz > > There is no such error on machines where dpb did not perform a fetch > run during the brief window when anki-2.0.52 was enabled. Actually, I think that's a misunderstanding on my part. I was comparing dpb -F2 runs on one host with dpb -a runs elsewhere. I guess when dpb _builds_ packages, it ignores the BROKEN port. When it purely _fetches_ packages, it doesn't. -- Christian "naddy" Weisgerber na...@mips.inka.de
Re: dpb doesn't forget invalid distfile
On Fri, May 24, 2019 at 10:28:31PM +0200, Christian Weisgerber wrote: > A while back, education/anki was updated to 2.0.52. dpb -F tried to > fetch it, but failed. Shortly afterwards, the anki port was marked > BROKEN. Ever since, dpb on this machine has kept reporting this > fetch error: > E=education/anki:anki-2.0.52-source.tgz > > It simply doesn't forget. > > There is no such error on machines where dpb did not perform a fetch > run during the brief window when anki-2.0.52 was enabled. > > Clearly, dpb remembers something, somewhere, but I can't find it. > What do I need to delete to get rid of this persistent fetch error? Well, now that I got more than five minutes. How about some actual logs ? like what's in the lock ? and what's in the dist/anki-2.0.52-source.tgz.log file ? you know, that might help.
CVS: cvs.openbsd.org: ports
CVSROOT:/cvs Module name:ports Changes by: es...@cvs.openbsd.org 2019/05/25 06:20:27 Modified files: sysutils/random_run: Makefile distinfo sysutils/random_run/pkg: DESCR Log message: lots more cleanup, probably all for today (better options for regexp, and ways more examples in the manpage)
CVS: cvs.openbsd.org: ports
CVSROOT:/cvs Module name:ports Changes by: na...@cvs.openbsd.org 2019/05/25 05:45:55 Modified files: multimedia/mediainfo: Makefile distinfo Log message: maintenance update to 19.04
CVS: cvs.openbsd.org: ports
CVSROOT:/cvs Module name:ports Changes by: ajacou...@cvs.openbsd.org 2019/05/25 04:47:00 Modified files: sysutils/google-cloud-sdk: Makefile distinfo sysutils/google-cloud-sdk/pkg: PLIST Log message: Update to google-cloud-sdk-247.0.0.
CVS: cvs.openbsd.org: ports
CVSROOT:/cvs Module name:ports Changes by: ajacou...@cvs.openbsd.org 2019/05/25 04:44:25 Modified files: net/py-botocore: Makefile distinfo net/py-botocore/pkg: PLIST Log message: Update to py-botocore-1.12.156.
CVS: cvs.openbsd.org: ports
CVSROOT:/cvs Module name:ports Changes by: ajacou...@cvs.openbsd.org 2019/05/25 04:44:41 Modified files: sysutils/awscli: Makefile distinfo sysutils/awscli/pkg: PLIST Log message: Update to awscli-1.16.166.
CVS: cvs.openbsd.org: ports
CVSROOT:/cvs Module name:ports Changes by: ajacou...@cvs.openbsd.org 2019/05/25 04:44:11 Modified files: net/py-boto3 : Makefile distinfo Log message: Update to py-boto3-1.9.156.
CVS: cvs.openbsd.org: ports
CVSROOT:/cvs Module name:ports Changes by: ajacou...@cvs.openbsd.org 2019/05/25 04:41:15 Modified files: sysutils/terraform/terraform: Makefile distinfo Log message: Update to terraform-0.12.0.
CVS: cvs.openbsd.org: ports
CVSROOT:/cvs Module name:ports Changes by: ajacou...@cvs.openbsd.org 2019/05/25 04:36:15 Modified files: x11/gnome/control-center: Makefile distinfo Removed files: x11/gnome/control-center/patches: patch-panels_display_cc-display-settings_c patch-panels_mouse_gnome-mouse-properties_ui patch-panels_power_cc-power-panel_ui patch-panels_region_cc-region-panel_c Log message: Update to gnome-control-center-3.32.2.
CVS: cvs.openbsd.org: ports
CVSROOT:/cvs Module name:ports Changes by: ajacou...@cvs.openbsd.org 2019/05/25 04:35:20 Modified files: sysutils/terraform/provider-alicloud: Makefile distinfo sysutils/terraform/provider-azurerm: Makefile distinfo sysutils/terraform/provider-exoscale: Makefile distinfo sysutils/terraform/provider-ovh: Makefile distinfo Log message: Update terraform providers.
Re: [maintainer update] gzdoom-4.1.2
timo.my...@bittivirhe.fi (Timo Myyrä) writes:
> Hi,
>
> Gzdoom seems to have few releases since last ports update.
> Is anyone interested in having legacy release of 3.8.0 which requires OpenGL
> 2.0+ or would it be best to use the current 4.2.1 version requiring OpenGL
> 3.3+?
>
> I'm leaning towards the latter, there are other doom ports for older hw so I'd
> say we could switch to using the modern branch.
>
> Here's update to 4.1.2 for review. Quickly tested on amd64 but I'm using the
> amdgpu which isn't stable yet so this could use some further testing with
> other hw.
>
> Timo
>
> Index: Makefile
> ===
> RCS file: /cvs/ports/games/gzdoom/Makefile,v
> retrieving revision 1.5
> diff -u -p -u -p -r1.5 Makefile
> --- Makefile 2 Apr 2019 13:56:40 - 1.5
> +++ Makefile 25 May 2019 08:43:16 -
> @@ -6,7 +6,7 @@ ONLY_FOR_ARCHS = i386 amd64
>
> COMMENT =OpenGL engine for idTech 1 games like
> doom,hexen,heretic...
>
> -V = 3.7.2
> +V = 4.1.2
> PKGNAME =gzdoom-${V}
> DISTNAME = gzdoom-src-g${V}
>
> Index: distinfo
> ===
> RCS file: /cvs/ports/games/gzdoom/distinfo,v
> retrieving revision 1.2
> diff -u -p -u -p -r1.2 distinfo
> --- distinfo 27 Feb 2019 23:35:17 - 1.2
> +++ distinfo 25 May 2019 08:43:16 -
> @@ -1,2 +1,2 @@
> -SHA256 (gzdoom-src-g3.7.2.zip) = BzdegCYKsjPC6VMhy4iWfaRvd2+DS+7tYKChCkxwAgU=
> -SIZE (gzdoom-src-g3.7.2.zip) = 12189731
> +SHA256 (gzdoom-src-g4.1.2.zip) = PlpypHGf8jEBwTGL+dSlZ0rWgj9s4GfDC/J/nuS1uPY=
> +SIZE (gzdoom-src-g4.1.2.zip) = 15297100
> Index: patches/patch-src_CMakeLists_txt
> ===
> RCS file: /cvs/ports/games/gzdoom/patches/patch-src_CMakeLists_txt,v
> retrieving revision 1.1.1.1
> diff -u -p -u -p -r1.1.1.1 patch-src_CMakeLists_txt
> --- patches/patch-src_CMakeLists_txt 6 Feb 2019 09:32:21 - 1.1.1.1
> +++ patches/patch-src_CMakeLists_txt 25 May 2019 08:43:16 -
> @@ -14,8 +14,8 @@ Index: src/CMakeLists.txt
> if( WIN32 )
> if( X64 )
> set( WIN_TYPE Win64 )
> -@@ -1301,7 +1305,13 @@ if(${CMAKE_SYSTEM_NAME} STREQUAL "SunOS")
> - set( ZDOOM_LIBS ${ZDOOM_LIBS} nsl socket)
> +@@ -1369,7 +1373,13 @@ if( UNIX )
> + endif()
> endif()
>
> +find_package( Backtrace )
> Index: patches/patch-src_scripting_vm_vmframe_cpp
> ===
> RCS file: /cvs/ports/games/gzdoom/patches/patch-src_scripting_vm_vmframe_cpp,v
> retrieving revision 1.1
> diff -u -p -u -p -r1.1 patch-src_scripting_vm_vmframe_cpp
> --- patches/patch-src_scripting_vm_vmframe_cpp12 Feb 2019 18:07:11
> - 1.1
> +++ patches/patch-src_scripting_vm_vmframe_cpp25 May 2019 08:43:16
> -
> @@ -1,14 +1,14 @@
> -$OpenBSD: patch-src_scripting_vm_vmframe_cpp,v 1.1 2019/02/12 18:07:11
> solene Exp $
> +$OpenBSD$
>
> disable JIT so it's W^X compatible
>
> Index: src/scripting/vm/vmframe.cpp
> --- src/scripting/vm/vmframe.cpp.orig
> +++ src/scripting/vm/vmframe.cpp
> -@@ -49,7 +49,7 @@
> - #endif
> +@@ -45,7 +45,7 @@
> + #include "version.h"
>
> - #ifdef ARCH_X64
> + #ifdef HAVE_VM_JIT
> -CUSTOM_CVAR(Bool, vm_jit, true, CVAR_NOINITCALL)
> +CUSTOM_CVAR(Bool, vm_jit, false, CVAR_NOINITCALL)
> {
> Index: patches/patch-src_sound_mididevices_music_fluidsynth_mididevice_cpp
> ===
> RCS file:
> /cvs/ports/games/gzdoom/patches/patch-src_sound_mididevices_music_fluidsynth_mididevice_cpp,v
> retrieving revision 1.1.1.1
> diff -u -p -u -p -r1.1.1.1
> patch-src_sound_mididevices_music_fluidsynth_mididevice_cpp
> --- patches/patch-src_sound_mididevices_music_fluidsynth_mididevice_cpp
> 6 Feb 2019 09:32:21 - 1.1.1.1
> +++ patches/patch-src_sound_mididevices_music_fluidsynth_mididevice_cpp
> 25 May 2019 08:43:16 -
> @@ -3,7 +3,7 @@ $OpenBSD: patch-src_sound_mididevices_mu
> Index: src/sound/mididevices/music_fluidsynth_mididevice.cpp
> --- src/sound/mididevices/music_fluidsynth_mididevice.cpp.orig
> +++ src/sound/mididevices/music_fluidsynth_mididevice.cpp
> -@@ -49,12 +49,11 @@
> +@@ -50,12 +50,11 @@
> // do this without including windows.h for this one single prototype
> extern "C" unsigned __stdcall GetSystemDirectoryA(char *lpBuffer, unsigned
> uSize);
>
> @@ -17,7 +17,7 @@ Index: src/sound/mididevices/music_fluid
> #endif
> #else
> #include
> -@@ -64,6 +63,15 @@ extern "C" unsigned __stdcall GetSystemDirectoryA(char
> +@@ -65,6 +64,15 @@ extern "C" unsigned __stdcall GetSystemDirectoryA(char
> #else // !__APPLE__
> #define FLUIDSYNTHLIB1 "libfluidsynth.so.1"
> #endif // __APPLE__
> Index: patches/patch-src_textures_animations_cpp
>
CVS: cvs.openbsd.org: ports
CVSROOT:/cvs Module name:ports Changes by: ajacou...@cvs.openbsd.org 2019/05/25 04:22:34 Modified files: security/p11-kit: Makefile distinfo Log message: Update to p11-kit-0.23.16.1.
[maintainer update] gzdoom-4.1.2
Hi,
Gzdoom seems to have few releases since last ports update.
Is anyone interested in having legacy release of 3.8.0 which requires OpenGL
2.0+ or would it be best to use the current 4.2.1 version requiring OpenGL 3.3+?
I'm leaning towards the latter, there are other doom ports for older hw so I'd
say we could switch to using the modern branch.
Here's update to 4.1.2 for review. Quickly tested on amd64 but I'm using the
amdgpu which isn't stable yet so this could use some further testing with other
hw.
Timo
Index: Makefile
===
RCS file: /cvs/ports/games/gzdoom/Makefile,v
retrieving revision 1.5
diff -u -p -u -p -r1.5 Makefile
--- Makefile2 Apr 2019 13:56:40 - 1.5
+++ Makefile25 May 2019 08:43:16 -
@@ -6,7 +6,7 @@ ONLY_FOR_ARCHS =i386 amd64
COMMENT = OpenGL engine for idTech 1 games like
doom,hexen,heretic...
-V =3.7.2
+V =4.1.2
PKGNAME = gzdoom-${V}
DISTNAME = gzdoom-src-g${V}
Index: distinfo
===
RCS file: /cvs/ports/games/gzdoom/distinfo,v
retrieving revision 1.2
diff -u -p -u -p -r1.2 distinfo
--- distinfo27 Feb 2019 23:35:17 - 1.2
+++ distinfo25 May 2019 08:43:16 -
@@ -1,2 +1,2 @@
-SHA256 (gzdoom-src-g3.7.2.zip) = BzdegCYKsjPC6VMhy4iWfaRvd2+DS+7tYKChCkxwAgU=
-SIZE (gzdoom-src-g3.7.2.zip) = 12189731
+SHA256 (gzdoom-src-g4.1.2.zip) = PlpypHGf8jEBwTGL+dSlZ0rWgj9s4GfDC/J/nuS1uPY=
+SIZE (gzdoom-src-g4.1.2.zip) = 15297100
Index: patches/patch-src_CMakeLists_txt
===
RCS file: /cvs/ports/games/gzdoom/patches/patch-src_CMakeLists_txt,v
retrieving revision 1.1.1.1
diff -u -p -u -p -r1.1.1.1 patch-src_CMakeLists_txt
--- patches/patch-src_CMakeLists_txt6 Feb 2019 09:32:21 - 1.1.1.1
+++ patches/patch-src_CMakeLists_txt25 May 2019 08:43:16 -
@@ -14,8 +14,8 @@ Index: src/CMakeLists.txt
if( WIN32 )
if( X64 )
set( WIN_TYPE Win64 )
-@@ -1301,7 +1305,13 @@ if(${CMAKE_SYSTEM_NAME} STREQUAL "SunOS")
- set( ZDOOM_LIBS ${ZDOOM_LIBS} nsl socket)
+@@ -1369,7 +1373,13 @@ if( UNIX )
+ endif()
endif()
+find_package( Backtrace )
Index: patches/patch-src_scripting_vm_vmframe_cpp
===
RCS file: /cvs/ports/games/gzdoom/patches/patch-src_scripting_vm_vmframe_cpp,v
retrieving revision 1.1
diff -u -p -u -p -r1.1 patch-src_scripting_vm_vmframe_cpp
--- patches/patch-src_scripting_vm_vmframe_cpp 12 Feb 2019 18:07:11 -
1.1
+++ patches/patch-src_scripting_vm_vmframe_cpp 25 May 2019 08:43:16 -
@@ -1,14 +1,14 @@
-$OpenBSD: patch-src_scripting_vm_vmframe_cpp,v 1.1 2019/02/12 18:07:11 solene
Exp $
+$OpenBSD$
disable JIT so it's W^X compatible
Index: src/scripting/vm/vmframe.cpp
--- src/scripting/vm/vmframe.cpp.orig
+++ src/scripting/vm/vmframe.cpp
-@@ -49,7 +49,7 @@
- #endif
+@@ -45,7 +45,7 @@
+ #include "version.h"
- #ifdef ARCH_X64
+ #ifdef HAVE_VM_JIT
-CUSTOM_CVAR(Bool, vm_jit, true, CVAR_NOINITCALL)
+CUSTOM_CVAR(Bool, vm_jit, false, CVAR_NOINITCALL)
{
Index: patches/patch-src_sound_mididevices_music_fluidsynth_mididevice_cpp
===
RCS file:
/cvs/ports/games/gzdoom/patches/patch-src_sound_mididevices_music_fluidsynth_mididevice_cpp,v
retrieving revision 1.1.1.1
diff -u -p -u -p -r1.1.1.1
patch-src_sound_mididevices_music_fluidsynth_mididevice_cpp
--- patches/patch-src_sound_mididevices_music_fluidsynth_mididevice_cpp 6 Feb
2019 09:32:21 - 1.1.1.1
+++ patches/patch-src_sound_mididevices_music_fluidsynth_mididevice_cpp 25 May
2019 08:43:16 -
@@ -3,7 +3,7 @@ $OpenBSD: patch-src_sound_mididevices_mu
Index: src/sound/mididevices/music_fluidsynth_mididevice.cpp
--- src/sound/mididevices/music_fluidsynth_mididevice.cpp.orig
+++ src/sound/mididevices/music_fluidsynth_mididevice.cpp
-@@ -49,12 +49,11 @@
+@@ -50,12 +50,11 @@
// do this without including windows.h for this one single prototype
extern "C" unsigned __stdcall GetSystemDirectoryA(char *lpBuffer, unsigned
uSize);
@@ -17,7 +17,7 @@ Index: src/sound/mididevices/music_fluid
#endif
#else
#include
-@@ -64,6 +63,15 @@ extern "C" unsigned __stdcall GetSystemDirectoryA(char
+@@ -65,6 +64,15 @@ extern "C" unsigned __stdcall GetSystemDirectoryA(char
#else // !__APPLE__
#define FLUIDSYNTHLIB1"libfluidsynth.so.1"
#endif // __APPLE__
Index: patches/patch-src_textures_animations_cpp
===
RCS file: patches/patch-src_textures_animations_cpp
diff -N patches/patch-src_textures_animations_cpp
--- patches/patch-src_textures_animations_cpp 6 Feb 2019 09:32:21 -
1.1.1.1
+++ /dev/null 1 Jan 1970 00:00:00 -
@@ -1,14 +0,0 @@
-$OpenBSD:
CVS: cvs.openbsd.org: ports
CVSROOT:/cvs Module name:ports Changes by: es...@cvs.openbsd.org 2019/05/25 02:42:24 Modified files: sysutils/random_run: Makefile distinfo Log message: minor bugfix
Re: NEW: Tacacs+ port - shrubbery.net version
Hi, tac_plus compiles and runs fine on octeon too. (Edge Router Lite, -current) Tested slightly with py_tacacs_plus. Encrypted and cleartext logins work, and authentication both to syslog and dedicated file. jvl On Fri, May 24, 2019 at 01:49:29PM +0200, Ampie Niemand wrote: > This does the trick and installs perfectly on macppc, will test i386 > and amd64 when I get home. > > My thoughts are that because all the TACACS+ ports were obsolete after > 6.2, the _tacacs user was sort of "deauthorized" in the infrastructure > userlist. > Reading the error message properly this time it confirms 100% what you > said so that even I can understand it. :-D > > Thanks, this is amazing. > > Regards > Ampie > >
